== 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.
I'm working on (learning modularity) and developing a module for my package
and created a not-so-great (super long) branch name in the dist-git rpm and
module repo before I realized that it would be the stream's name too. Also,
it seems that the incomplete module was picked up and included in F31;
someone was nice enough to open a BZ and tell me it's broken. There are
builds associated with the branch, so I probably can't delete it outright,
but is there a way for me to hide (or something) that branch and use the
correct one that I just requested? I think that `fedpkg retire` is the way
to do it, but wanted to ask first since I can't find any supporting
documentation. Or now that it's been included in F31 am I stuck with it
(even thought it doesn't work)?
The upstream QEMU community is raising the possibility of deprecating,
and subsequently deleting, support for running emulation guests on
32-bit *hosts*. Running 32-bit guests would *not* be affected.
See this thread:
IOW, if you have a armv7/i686/ppc *host* machine, you would no longer be
able to use QEMU for either full machine system emulation (TCG), nor linux
userspace emulators (TCG). Potentially KVM for 32-bit *host* would be
dropped too, but QEMU might deal with that separately, to align with
kernel support for KVM on 32-bit.
In simple terms, we're talking this proposed matrix for running virtual
machines or linux userspace with emulated CPU architectures:
| Host 32-bit | Host 64-bit
Guest 32-bit | dropped | supported
Guest 64-bit | dropped | supported
Given that i686 is no longer composed in Fedora, that leaves armv7 as the
Fedora host arch which would be affected.
If upstream goes ahead, we have 2 releases with deprecation, so the earliest
it would be deleted is the QEMU release in Aug 2020, which would be Fedora 33
timeframe IIUC. At that time any RPM with a dependancy on QEMU on 32-bit would
need some %ifarch, or ExclusiveArch magic.
I'm assuming there's nothing in Fedora infra that uses 32-bit hosts, as
IIUC, our armv7 koji builders are all on aarch64 hosts.
Does anyone know of, or have, any critical/important use cases that would
be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
here & I can forward feedback on. Or feel free to go direct to QEMU thread
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
We (the Anaconda installer team) want to solve multiple problems by one
solution and we want
In short we are proposing to use custom repo files when configuring
Anaconda for image creation instead of adding even more complexity to
the kickstart repo command. For more details see the link below.
Purpose of this mail is to give everyone interested in the topic a
place to discuss our proposal to find out if we didn't miss something
or better case, if you agree with it :). It could be that this is not
applicable for Lorax / Pungi / live-cd tool in that case please write a
response to the document.
You can read details here:
Please, all the relevant comments should stay in the document if
possible. If that solution won't work because of higher traffic then we
will find a better solution but the point is to have everything on one
Have a great day everyone,
Do anyone know how to subscribe to Bugzilla bugs for a particular
I'm trying to watch glib-networking bugs. I'm already watching issues
and PRs at https://src.fedoraproject.org/rpms/glib-networking, but that
only watches for Pagure issues, not Bugzilla.
I'm already watching webkit2gtk3 package issues on Bugzilla and this
works exactly as I would expect, but I think I configured that long ago
with pkgdb back when pkgdb still existed.
This seems pretty basic, so it shouldn't be hard. Any ideas?