a new version rpkg-1.58 and fedpkg-1.37 is released.
Currently, Fedora 30 packages are in the stable repository, feel free to
try other waiting distributions in Bodhi.
Numerous features and improvements (as well as bugfixes) includes:
- Improvements for scratch module builds
- Allow passing arguments to “mbs-manager build_module_locally”
- Remove the ability to parse a module’s branch
- Permit setting arbitrary rpm macros during build
- Ignore specific files in a cloned repository
- Pass specific arguments to “mock”
- Added “depth” argument to "git clone"
- Watch multiple module builds
- Show module build links in output from command module-build
- Add the ability to configure multiple regex expressions
- Add “retire” command supporting both packages and modules
- Import srpm without uploading sources
- Ignore any specified profile when finding the Flatpak build target
- Added update-docs script
- And other fixes and small improvements
- Ignore files in a cloned repository
- Enable shell completion for module scratch builds
- Show hint when Pagure token expires
- Include possible distprefix in “–define dist” for Forge-based packages
- Other small fixes
More specific changelog (web documentation):
rpkg is available from PyPI.
Thanks to all contributors.
This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
there is still no F30 package with the right keys.
Can we *please* send out the FN+1 and FN+2 keys a month before branching,
to *all* releases of Fedora, so we can avoid this pointless scramble?
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs
to get it building again is to disable the gtk-doc generation...
I don't really want to own it, but I have dependent packages, so if no one
else does, I will claim it.
If you want it (or know of some reason it shouldn't be brought back),
please speak up.
== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwhalen(a)fedoraproject.org
* Responsible WG: ARM SIG
== Detailed Description ==
We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.
An initial set of supported devices:
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c
== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.
== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.
== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.
== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
All documentation will be added or updated via the ARM Landing Page.
He / Him / His
Fedora Program Manager
Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that
time) based on the Fedora Failed to Build From Source Policy . From various
reactions over several threads it seems this policy is not ideal. This is an
attempt to collect feedback and make the policy better serve Fedora's needs.
Fedora has a policy for a long time that can be simplified as:
1. Mass rebuild for Fedora N happens by releng
2. Packages that fail to build get open bugzillas by releng
3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
reminders by releng
4. A week before Fedora N+1 branching any packages which still have open
Fedora N FTBFS bug are retired by releng
However, 3 or 4 haven't happened since Fedora ~26, because the automation was
not working any more for various reasons I don't understand.
The policy was then updated by FESCo to allow anybody to step up and do 3. manually.
However it needs 2 e-mails to devel directed at the package owners and that may
be understood as a personal attack by some.
So nobody ever did that but me (twice) IIRC (and I got my share of shame for that).
Currently, the FTBFS retirement is problematic due to various things:
1) Bugzilla spam: Maintainers are spammed weekly by releng, some of them find
that annoying and simply switch the bug to ASSIGNED to make it stop.
The problem is, how do we both keep notifying the maintainers that action is
needed and not spam them with stuff that will make them filter all Fedora
e-mails to /dev/null.
2) Retirement out of the blue. When releng executes 4., packagers that stopped
the bugzilla spam by setting the bug to ASSIGNED are suddenly surprised the
package was retired. OTOH arguably they made a deliberate action to stop the
notifications. However, most importantly, any dependent packages were not
notified at all, which is **not fair**.
This state is broken mostly because there is no automatic orphaning of packages
that have NEW bugzillas and there is no orphaning at all for packages where the
bugzillas are ASSIGNED for months. For the second bit, everything indicates that
packagers are aware of the problem and will fix the bug in time before 4., but
they don't and things blow up.
3) Questionable importance of the FTBFS bug.
Repeatedly, it has been stated by some, the FTBFS bug is not important and we
should not retire packages at all based on the fact that they "simply" fail to
build. I personally don't agree with this for various reasons, but I can imagine
a situation, where it is reasonable to say so and delay the problem. Obvious
argument is: Better to have 1 package nonbuildable than have 100 packages
nonisntallable. So we need a way to opt-out from the retirement, however simply
setting the bugzilla to ASSIGNED is not it, because we will end up with packages
last built 6 years ago (and I believe this is not what we want).
I'm starting this thread to collect the ideas about how to make this better.
If you see more problems, share them. I promise I'll do my best to make the
policy work better for both Fedora and the people who make Fedora.