A tool I am trying to package is failing only on PPC somehow:
> make: Leaving directory '/builddir/build/BUILD/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb-openmpi/src'
> BUILDSTDERR: error.cc: In function 'void MUSIC::error()':
> BUILDSTDERR: error.cc:36:5: error: 'MPI' has not been declared
> BUILDSTDERR: 36 | MPI::COMM_WORLD.Abort (1);
> BUILDSTDERR: | ^~~
> BUILDSTDERR: error.cc: In function 'int MUSIC::getRank()':
> BUILDSTDERR: error.cc:70:9: error: 'MPI' has not been declared
> BUILDSTDERR: 70 | if (MPI::Is_initialized ())
> BUILDSTDERR: | ^~~
> BUILDSTDERR: error.cc:71:14: error: 'MPI' has not been declared
> BUILDSTDERR: 71 | return MPI::COMM_WORLD.Get_rank ();
> BUILDSTDERR: | ^~~
> BUILDSTDERR: make: *** [Makefile:739: libmusic_la-error.lo] Error 1
On all other arches, it builds just fine, so there's something different
with the openmpi package on ppc here. Any ideas?
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
Fedora Infrastructure currently has the majority of its hardware in a
datacenter in Arizona, USA. Red Hat leases this space for use by a number of
teams, including Fedora. However, they've been seeking a more modern and cost
effective location for some time and have decided on one:
So, we will be migrating to a new datacenter located in Ashburn, Virginia
FESCo has approved a 2 week window for the actual move to take place
( https://pagure.io/fesco/issue/2221 ): 2020-06-01 to 2020-06-15.
This window is after Fedora 32 is released, but before any major
Fedora 33 Milestones.
At a high level, our current plan is:
* Setup the new datacenter with networking/storage/management
* Populate the new datacenter with new hardware to replace old hardware that
either wouldn’t survive the shipping or is due to be refreshed
* Ship some small shipment of hardware from the old datacenter to the new
that are not easily duplicated like signing hardware,
alternative arch builders, etc.
* Setup and have by the early part of the outage window a
Minimum Viable Fedora Infrastructure (see below) using new hardware
and some old.
* Function in this minimal state as all the rest of the hardware is
shipped to the new datacenter.
* Re-add hardware to return to normal state.
We want to maintain continuity of service as best we can,
so we have defined a Minimal Viable Fedora which will move in advance
of the main hardware. Our intention is to reroute traffic to this setup
before moving the bulk of our hardware.
Our current list of what a Minimum Viable Fedora Infrastructure is:
* Mirroring fully functional. Users get metalinks, mirrors are crawled, etc
* The complete package lifecycle must work.
From commit to update installed on users machines.
We need this to push security and important bugfixes as well as to allow
maintainers to work toward Fedora 33.
* Our production openshift cluster must be up and running normally.
(This cluster has fas, bodhi and other important items in it)
* Builders will likely be constrained.
Ie, less of most arches.
Capacity will be re-added as soon as the hardware for it arrives.
* Rawhide composes take place as normal.
* Nameservers functional
* rabbitmq/fedora-messaging should be up and functional.
* Internal proxies must be functional (used by builders and other internal items)
* Mailing lists must be functional
* Backups must be functional
* OpenQA must be available to test updates/rawhide composes
* Wiki must be available for common bugs / qa
Other services not listed may or may not be up depending on capacity
and issues with more important services.
And explicitly some things will NOT be available during that window:
* Staging. There will be no staging, so no rolling out new services.
* Full capacity/number of builders
* External proxies in the new datacenter
* HA for some services.
We are sending this announcement not only to let you all be aware of this move,
but to help us plan. If you see some service that you think is critical
to Fedora and cannot be down for 2 weeks, and isn't listed above
please let us know so we can adjust our plans.
We want to make sure things that are critical keep running
smoothly for the Fedora community.
Feedback by next friday (2019-10-04) would be welcome.
Kevin for CPE and the Fedora Infrastructure team.
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://email@example.com...
== 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,