On Fri, Apr 16, 2021 at 3:57 PM Paul Bolle <pebolle@xxxxxxxxxx> wrote: > > Justin Forbes schreef op vr 16-04-2021 om 13:33 [-0500]: > > The only thing that RHEL builds i686 at all is kernel-headers and > > kernel-cross headers. For Fedora, kernel-headers is a separate package. > > Glad I asked, because I hadn't realized this. And apologies for yet another > email. In over a year I only delivered some messages... > > > Those likely need to remain for 32bit userspace packages. > > (More a note to self: dnf doesn't lists either kernel-headers.i686 or kernel- > cross-headers.i686. Perhaps that is because they appear to ship identical > files. But why bother building them for i686? And why is kernel-cross-headers > not a noarch file? Ie, what explains the differences between k-c-h.aarch64, k- > c-h.arm7hl, etc. Lot to learn here...) > While x86_64 and i686 were unified a little over 10 years ago (the kernel-headers files are identical), they can't be noarch because other architectures are different. Both rpm and dnf have really crap support for multilib. If we just build the x86_64, i386 builds cannot resolve kernel-headers as a dep. The kernel-cross-headers package could definitely be noarch, but it wasn't added that way, and I had not bothered to fix it. > > I haven't seen your patches, but it seems the first step would be to remove > > anything that builds/verifies the i686 configs, this can include the > > i686 config directories (but don't move x86_64 up to x86). I might > > also remove filter-i686* and stop it from being called as well. > > That was sort of my approach: first clean up the specfile, then remove > anything that has then become unreachable. > > > Once nothing is using those configs, we can look at rearranging x86/x86_64 > > to just be a single x86 directory in a separate change. > > This is what my "configs: there's only x86_64" commit does. That turned out to > be much simpler than I feared. > > > Doing it this way should make it a bit easier to get that patch through quickly > > without too much churn. It can also be better arranged around the > > merge window, which is when config options change the most. > > My English is letting me down here, but config churn is lowest at the end of > the dev. cycle, so config cleanup is best done around rc7 or rc8, right? > Yes, though there is no guarantee of an rc8, so the best time would be the weekend before rc7 to give people time to test and review before the merge window opens. Justin _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
