Thu, Jul 20, 2023 at 5:07 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Demi Marie Obenour: > > > On 7/17/23 09:51, Florian Weimer wrote: > >> * Daniel P. Berrangé: > >> > >>>> But that still raises the question - why does it look like this > >>>> started to happen pretty suddenly around June 30? > >>>> The list of updates that were applied to builders in that timeframe > >>>> doesn't raise any alarm bells (except maybe the 6.3 kernel): > >>>> (see https://pagure.io/releng/issue/11531#comment-864471) > >>>> I read the release notes for the 6.3 kernel but didn't see any > >>>> mentions of BTRFS changes that could explain this. :( > >>> > >>> Or what 32-bit code is being run in the context of koji that is > >>> NOT compiled with LFS ? Is this something silly like configure > >>> script tests not enabling LFS, but the resulting applications > >>> correctly using LFS ? > >> > >> A dependency used during RPM file creation, libcap, is not fully built > >> in LFS mode. Once we fix that, we know that we'll run into issues with > >> chkconfig and update-alternatives. It's a never-ending source of bugs. > >> It's not a good use of maintainer time. > >> > >> We can't change the overall distribution flags with CFLAGS injection > >> because doing so has ABI implications. > > > > Can they be changed at the next mass rebuild? > > Not if we want to maintain compatibility with non-Fedora software. It > probably doesn't matter for most packages, but doing a per-package > analysis is a lot of work. While it's not a long-term solution, would it be possible to just "delay things for long enough until we can drop i686 entirely" by modifying specific packages? For example, in this case, libcap was not 64-bit inode aware, and shadow-utils failed to install in the default buildroot (I hope I summarize this right), but modifying libcap to build with support for 64-bit inodes would have solved this, if I understand correctly? -> Pro: Small changes to specific packages -> Con: Things might still fail later in the build process However, since the libcap/shadow-utils thing was the only failure that I saw that affected the default buildroot, at least this would (for now) completely solve the issue (or make much less likely to happen) for several workflows: - buildSRPMfromSCM tasks would no longer randomly fail if assigned to i686 builders - koschei builds would no longer randomly fail (even though they don't even build on i686) - noarch builds could only fail if assigned to i686 (unlucky case) - scratch builds that only include non-i686 architectures would no longer fail - EPEL builds would no longer fail (don't get built for i686) Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
