Orphaned rubygem-minitest-reporters
by Fabio Valentini
Hi everybody,
I just orphaned rubygem-minitest-reporters, because It's no longer
required by any of my other ruby packages. It's up to date with the
newest upstream release.
Usually, it can be removed from a package's test suite with a simple
patch / sed, since it only affects terminal output and not the test
executions themselves.
Fabio
4 years, 5 months
Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi
= Annobin Used By Bodhi =
== Summary ==
Use the annocheck program from the annobin package to produce an
analysis of the security hardening of a compiled package when
reviewing a Bodhi update.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: nickc(a)redhat.com
== Detailed Description ==
The annobin package provides two components, a plugin for gcc that
records details about how a program was compiled and an analyser that
uses this information to produce a report on the security hardening
status of the compiled program. Currently the plugin is being used as
part of the build process for Fedora packages (when they are built
using gcc), but the analysing program is not being run. This proposal
is to have the analyser (called annocheck) run when creating
information for review by the Bodhi update process, possibly allowing
an update to be delayed until the security issues are addressed.
The analyser currently looks for the following items:
* Lazy binding must not have been enabled via the linker option "-z
lazy". Instead the @option{-z now} option must have been used.
* The program must not have a stack in an executable region of memory.
* The relocations for the GOT table must be read only.
* No program segment should have all three of the read, write and
execute permission bits set.
* There should be no relocations against executable code.
* The runpath information used to locate shared libraries at runtime
must only include directories rooted at /usr.
* The program must have been compiled with the
-fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2
specified. It must also have been compiled at at least optimisation
level 2.
* Dynamic executables must have a dynamic segment.
* Shared libraries must have been compiled with -fPIC or-fPIE but not -static.
* Dynamic executables must have been compiled with -fPIE and linked with -pie.
* Program which use exception handling must have been compiled with
-fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.
* If available the -fstack-clash-protection must have been used.
* If available the -fcf-protection=full must have been used.
* For i686 binaries, the -mstackrealign option must have been specified.
* The program must have been compiled with the -D_FORTIFY_SOURCE=2
command line option specified.
* The program must have been compiled with at least -O2 optimisation enabled.
* The program must not have any relocations that are held in a writable section.
* For x86_64 binaries, check that -fcf-protection has been enabled.
Note - I do not know *how* to add a run of the annocheck program to
the Bodhi process. This change request is about asking that such a
thing be added.
== Benefit to Fedora ==
Establishing good security practices when building packages will help
Fedora remain a front running Linux distribution. By providing a way
to review the security hardening status of packages, this update will
help to ensure that these practices continue.
Note - the intention is that if this change is successful, and useful,
then a future change request would be made to include the security
checking as part of the actual package build process, and to have
packages fail to complete building if they do not pass the security
checks.
== Scope ==
* Proposal owners:
In theory there is very little that I can do personally. I do not
have the knowledge to change the Bodhi process myself, so I will have
to rely upon someone else to do that. I am familiar with the annobin
package however, so any changes that are needed to it I will be happy
to make.
* Other developers:
Add an invocation of the annocheck program to the Bodhi build approval
process and make its output available to reviewers.
Annocheck can be invoked simply as "annocheck <filename>" although
there are a set of command line options to extend and modify its
behaviour. Annocheck understands the rpm file format, as well as
shared and static libraries and executable binaries. It can also be
helpful to provide annocheck with access to the debug information for
a binary or rpm, if that has been placed into a separate file.
* Release engineering: https://pagure.io/fedora-ci/general/issue/78
No mass rebuild is required.
* Policies and guidelines:
It is desirable that the packaging guidelines be updated to describe
the security hardening features examined by annocheck. (If they are
not already mentioned in the guidelines).
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should have no effect on upgrading Fedora, nor should it
introduce any compatibility problems.
== How To Test ==
Submit a package for Bodhi review and see if the annocheck data is
added to the page.
No special hardware is needed for this test, but it might involve the
use of a dummy package or a dummy instance of Bodhi in order to test
the behaviour before going live.
== User Experience ==
This change should not be noticeable by users.
== Dependencies ==
No packages depend upon this change.
This change does depend upon the annobin package.
== Contingency Plan ==
Back out any changes made to Bodhi.
* Blocks release?
No releases are blocked by this change.
* Blocks product?
No products are blocked by this change.
== Documentation ==
The watermark specification explains the technology underlying annobin:
https://fedoraproject.org/wiki/Toolchain/Watermark#Proposed_Specification...
The annobin package includes its own documentation. On a system where
it is installed invoking "info annobin" should produce a searchable
information structure.
== Release Notes ==
An update to the Fedora Release Notes should not be needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 5 months
Call for testers: testing multi-builds gating for rawhide packages
in staging
by Pierre-Yves Chibon
Good Morning Everyone,
It has now been a few months since we launched the possibility to gate
single-builds in bodhi for rawhide updates, since then we have been working on
the step two to allow gating multi-builds updates in bodhi.
We are reaching completion on this work but before we push it to production, we
would like to solicit those of you who have the interest and time to test the
workflow in staging.
Basically, try to create a side-tag, build in it, create the update in bodhi see
if it goes through, if it gets stuck, if something is not nice to work with or
if something breaks.
How to test?
============
You can test staging very easily but you’ll need to adjust some of the commands
and tools you’re using.
* To get a kerberos ticket run: `kinit <fasusername>@STG.FEDORAPROJECT.ORG`
* To interact with dist-git use `fedpkg-stage` (provided by the package with the
same name)
* To interact with koji directly, use the command: `koji -p stg <the rest of
your command>`
For examples:
`koji -p stg buildinfo <nvr>`
`koji -p stg untag <side-tag> <nvr>`
To interact with bodhi’s CLI you’ll see that most commands have a `--staging`
option you can specify which will make it call the staging instance of bodhi
rather than the production one.
As a reminder, you can find here the different tools:
Koji: https://koji.stg.fedoraproject.org/koji
Dist-git: https://src.stg.fedoraproject.org/
Bodhi: https://bodhi.stg.fedoraproject.org/
How should the builds progress?
===============================
If you do a single build without side-tag the build should follow:
f32-updates-candidate (where you build it)
-> bodhi picks it up, creates the update and moves it to f32-signing-pending
-> robosignatory picks it up, signs it and moves it to
f32-updates-testing-pending
-> test run... if they pass:
-> bodhi picks the message about the tests passing and move the builds into f32
If you do an update involving several (or one) build in a side-tag, the build(s)
should follow:
-> f32-side-XXX where you build it
-> Once you're done you create the update in bodhi
-> bodhi picks the builds and moves them to f32-side-XXX-signing-pending
-> robosignatory picks them up, signs them and moves them to
f32-side-XXX-testing-pending
(Tests won't run for the moment, we're working on fixing this)
-> if everything is fine (waiving the missing tests will work), bodhi picks up
the notification, merge the side-tag into f32 and removes the side-tag.
If you need to remove a build from a side-tag, you'll have to use koji -p stg
untag <tag> <nevr>.
If you have added a build to a side-tag, you can edit the update in bodhi's UI
and click on the refresh button that will update the list of builds in the
update from what is in the side-tag.
Where to report issues?
=======================
For anything related to bodhi, please use bodhi’s issue tracker:
https://github.com/fedora-infra/bodhi/issues for everything else, please fill an
infra ticket: https://pagure.io/fedora-infrastructure/
In doubt, feel free to report to this thread or on #bodhi channel on freenode
and we’ll help you get oriented.
Looking forward for your feedback!
Pierre
-- For the rawhide package gating team
4 years, 5 months
Reminder: DevConf.CZ CfP open through 1 November
by Ben Cotton
You may have seen this posted in a few places, but the DevConf.CZ Call
for Proposals is open. As in years past, there is a dedicated Fedora
track in addition to tracks on Community, IoT, cloud/containers,
microservices, networking, desktop, and more. DevConf.CZ is 24–26
Jaunary 2020 in Brno, CZ.
Open TestCon's (30–31 March, 2020 in Beijing, CN) CfP is also open
through 31 October.
You can see more information about both conferences and links to
proposal submissions on the Community Blog post:
https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-...
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
4 years, 5 months
Defining the future of the packager workflow in Fedora
by Pierre-Yves Chibon
Good Morning Everyone,
At Flock, a few of us met to discuss a future vision of the packager workflow.
This discussion was triggered by the realization that a number of initiatives
are happening around packaging in Fedora but there is no real shared vision on
what we want the packager UX/workflow to be.
The lack of vision on the packager workflow means we could deploy something
today, thinking it is the improvement over the current workflow but would
prevent us from (or make it harder to) doing other changes afterwords that would
be even more beneficial..
So once that concern was raised, we took some time during the Fedora
Infrastructure hackfest to gather the people interested around a white board and
brainstorm on what a future packager workflow could look like.
We tried not to link this process to any tool in particular as well as focus on
the what and why rather than any how.
Here is what the vision we came to and that we would like to discuss:
○ Every changes to dist-git is done via pull-requests
○ Pull-requests are automatically tested
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
○ Every build in koji results automatically in an update in bodhi
○ Every update in bodhi is automatically tested
○ If the tests pass, the update is automatically pushed to the repository
For this workflow to work nicely we need to fix a few things first:
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
- We need to fine a place to insert the end-user information about an update (in
the PR description?)
- When a group of people want to collectively work on a change (involving one or
more packages), they’ll need a place to collaborate. This could be someone’s
fork or, preferably, a fork of the project collectively maintained by that
group.
For example: the python SIG would have a group with forks of the different
python packages they are working on
- We need to figure out how to enable opening a pull-request again multiple
branches at one.
Why should we agree now on a long term vision?
A concrete example to this, I have been playing with the idea to get ride of git
branches in dist-git for a while now. Basically use git as it is meant to be
used: have one branch for development (most often master) and branch of master
when you need to, not simply because a new version of Fedora happened.
However, if we implemented this, we would break the workflow described above as
suddenly there would be no way to specify that a given PR is meant to land in a
certain version of Fedora or another (Is this PR for rawhide? F31? F30? All of
them? Some of them?).
Having this idea of where we want to go should give us a goal as well as way to
reflect if changes we think are good in isolation would actually help achieving
this vision or not.
This proposal was based on the brainstorming session a few of us had at flock,
but before we can see how to implement it we need more inputs and this is where
you come in :)
Do you like this vision? Would you change some pieces of it? Would you change it
entirely?
In an ideal world, what would packaging software look like to you?
Looking forward to the discussion,
Pierre
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
4 years, 5 months
Projects in Copr muted on discussion.fedoraprojects.org
by Miroslav Suchý
I finally found how to mute "Projects in Copr" on discussion.fedoraprojects.org.
It is now muted for new users and all **existing** users as well.
This should suppress this category from Latest and RSS as many people requested.
If you want to follow this category or topic in this category, please enable following in WebUI once again. Your choice
will override the site defaults.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
4 years, 5 months
GNU IceCat Updates
by Alireza Hayati
Hello. I don't know if I'm right to ask this in this mailing list and if
I should post this elsewhere, please forgive me bothering you.
I believe GNU IceCat updates are not shipped to Fedora repositories and
we're still using 60.9 version. How can I ask for updates or just remind
maintainers about it?
Thanks and sorry I bothered.
4 years, 5 months