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.
Is anything happening with introducing MPFR 4 into Fedora? I found these:
but they indicate that efforts to update have come to a halt. I ask
because I have had to patch 2 of my packages to keep them working with
MPFR 3, and I've got more that are said to work with either version 3
or version 4.
I am willing to put some effort into making the update happen. I
agree with the previous assessments that we will probably have to make
the two versions parallel installable for awhile, possibly for quite
awhile, until everything can be migrated to version 4.
This is the list of source packages in Fedora 30 that depend on
libmpfr, with asterisks by the ones I maintain, comaintain, or just
tend to meddle with:
Wow, I didn't realize how many packages I work with that consume mpfr.
That makes 16 out of 41, so I can manage moving 40% of the mpfr-using
packages over to version 4 all by myself. And, truth be told, there
are 4 more on that list that I've committed changes to at one point or
another, so I've had my fingers on 50% of them. Good grief.
Is somebody working on this already, and if so, what have you
accomplished so far, and what are your future plans? How can I help?
We're just over a month away from Hacktoberfest, a month-long event
where people can earn a t-shirt by contributing to open source
projects (or at least ones hosted on GitHub). It occurs to me that we
could have a post on the Community Blog (or maybe Fedora Magazine)
that directs folks toward Fedora or Fedora-adjacent projects on
GitHub. This is a good opportunity to get meaningful drive-by
contributions and perhaps add a few consistent contributors.
So if you were going to point the Fedora community at a GitHub-hosted
project, what would you choose?
He / Him / His
Fedora Program Manager