Fedora rawhide has not had any kernel build available for i686 for a
week now. It was disabled in a rebase due to part of the build process
Author: Laura Abbott <labbott(a)redhat.com>
Date: Thu Jun 14 10:57:47 2018 -0700
Don't build for i686
There is a segfault on i686
+ ./process_configs.sh -n -c kernel 4.18.0
override: SPARSEMEM_MANUAL changes choice state
override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state
make: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core
No idea why but we don't want to stop other arches. Disable it
There is a message posted to the x86 SIG at the same time as it was
Now, i686 is an alternative architecture, so IIUC, it is currently allowed
by our package maint guidelines to disable packages on i686 when there are
The kernel, however, is a critical path component that is a dependancy of
many other RPMs in Fedora.
Personally I'm impacted by inability to build QEMU in rawhide, because
it needs systemtap and systemtap needs the kernel-devel package. The
same impacts libvirt.
The GFS userspace is showing similar problems
which again impacts parts of the virt stack.
IOW, the result of disabling i686 in the kernel has to be pass on pain
to countless downstream package maintainers who are now blocked unless
they also disable i686, which will in turn break further downstream
packages which depend on them, rinse repeat.
Based on this ripple effect, I think the package maint policy here is
flawed with respect to packages that are on the critical path.
We have a root cause here that's there's a i686 build issue to
be addressed. No debate there.
Simply disabling an architecture doesn't fix the problem - it actually
expands the problem out to more & more packages/maintainers, making it
worse than it was to start with.
IMHO for packages that are in the critical and/or an upstream dependancy
of many other packages in Fedora, we should *NOT* disable architectures
except as a last resort, and certainly not before giving time to identify
what has caused the problem & fix it.
The kernel change that introduced the i686 build problem was just a
rebase between 2 arbitrary pre-release git snapshots. I don't really
a compelling justification to rebase to a known broken snapshot,
without allowing time for x86 SIG to resolve it first. AFAIK there
was no prior warning or request for help - i686 was just disabled
immediately and other package maintainers left to deal with the
consequences of broken deps.
A more pragmatic approach would have been to report the problem to the
x86 SIG and then *not* do the rebase for some reasonable period of time
(perhaps 1 week grace period), to allow for the problem to be addressed.
Only disable the i686 build if there is no solution is forthcoming, thus
avoiding causing this pain for a whole chain of packages/maintainers in
Having said all this, the message about brokenness on x86 SIG mailing
list doesn't appear to be treated with the urgency I think it needs,
givin the ripple effect it has from a critical path package. There were
a few messages the day after it was reported, and then nothing until
For a package that is critical path like the kernel, I'd expect this
to be a top priority item to resolve with immediate effect because of
the broad impact it has on other maintainers. Maybe this has been
happening in the background, with no activity visible on the mailing
list, if so I apologize in advance.