Hi Justin,
Fedora 31's release is imminent. This means that some time ago Fedora passed the point where (F31 and later) i686 releases were still possible, doesn't it?
If so, could we please clean the kernel package's repository of all the things that are only relevant for i686? Because that would make my plans for the config generation [1] just a bit easier.
Thanks,
Paul Bolle
[1] See https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org...
On Mon, Oct 21, 2019 at 7:06 AM Paul Bolle pebolle@tiscali.nl wrote:
Hi Justin,
Fedora 31's release is imminent. This means that some time ago Fedora passed the point where (F31 and later) i686 releases were still possible, doesn't it?
If so, could we please clean the kernel package's repository of all the things that are only relevant for i686? Because that would make my plans for the config generation [1] just a bit easier.
Because of the way we do rebases, it makes sense to do this when F30 is
EOL. We don't build i686 in rawhide, but it is good to deal with the config options as they are added upstream so things are fresh.
Justin
Justin Forbes schreef op ma 21-10-2019 om 09:02 [-0500]:
Because of the way we do rebases, it makes sense to do this when F30 is EOL.
Of course. I could have thought this through myself.
I'll be patient for another seven or so months. And maybe then I'll resend this message.
Thanks,
Paul Bolle
Paul Bolle schreef op ma 21-10-2019 om 20:42 [+0200]:
Justin Forbes schreef op ma 21-10-2019 om 09:02 [-0500]:
Because of the way we do rebases, it makes sense to do this when F30 is EOL.
Of course. I could have thought this through myself.
I'll be patient for another seven or so months. And maybe then I'll resend this message.
Seven months became eleven months.
I noticed the i686 .config files in master are still generated. Moreover there are still references to i686 in kernel.spec. (Ans possibly other stuff I didn't check for.)
Why's that?
Paul Bolle
On Mon, Nov 16, 2020 at 2:49 PM Paul Bolle pebolle@tiscali.nl wrote:
Paul Bolle schreef op ma 21-10-2019 om 20:42 [+0200]:
Justin Forbes schreef op ma 21-10-2019 om 09:02 [-0500]:
Because of the way we do rebases, it makes sense to do this when F30 is EOL.
Of course. I could have thought this through myself.
I'll be patient for another seven or so months. And maybe then I'll resend this message.
Seven months became eleven months.
I noticed the i686 .config files in master are still generated. Moreover there are still references to i686 in kernel.spec. (Ans possibly other stuff I didn't check for.)
Why's that?
It never got high enough on the priority list to remove, we went from 3 fedora kernel maintainers to 1 in that 11 months. I probably should clean up i686 from ark at some point, and it will trickle down from there to stable Fedora as they move into that work flow.
Justin
Justin Forbes schreef op ma 16-11-2020 om 16:15 [-0600]:
It never got high enough on the priority list to remove, we went from 3 fedora kernel maintainers to 1 in that 11 months. I probably should clean up i686 from ark at some point, and it will trickle down from there to stable Fedora as they move into that work flow.
I tried to clone the ark repo some time ago. For some reason that took ages and I aborted the operation. Maybe I'll try again one of these days and see whether I could submit a patch to do this cleanup. OK with you?
Thanks,
Paul Bolle
On Mon, Nov 16, 2020 at 4:32 PM Paul Bolle pebolle@tiscali.nl wrote:
Justin Forbes schreef op ma 16-11-2020 om 16:15 [-0600]:
It never got high enough on the priority list to remove, we went from 3 fedora kernel maintainers to 1 in that 11 months. I probably should clean up i686 from ark at some point, and it will trickle down from there to stable Fedora as they move into that work flow.
I tried to clone the ark repo some time ago. For some reason that took ages and I aborted the operation. Maybe I'll try again one of these days and see whether I could submit a patch to do this cleanup. OK with you?
Absolutely!
Paul Bolle schreef op ma 16-11-2020 om 23:32 [+0100]:
I tried to clone the ark repo some time ago. For some reason that took ages and I aborted the operation. Maybe I'll try again one of these days and see whether I could submit a patch to do this cleanup. OK with you?
So I finally drafted a commit series that does this. These (lame) commit summaries show my approach (order reversed): configs: there's only x86_64 configs: remove everything i686 related scripts: remove i686 from a comment remove filter-i686.sh.* un-i686 kernel.spec.template
I'm pretty sure the first attempt or two will blow up (especially on the rhel side). And any changes to x86-config changes in HEAD will derail my series.
So what is the preferred way to push a disruptive series like this onto the virtual gremlins that run kernel-ark's CI for us?
Paul Bolle
On Fri, Apr 16, 2021 at 12:07 PM Paul Bolle pebolle@tiscali.nl wrote:
Paul Bolle schreef op ma 16-11-2020 om 23:32 [+0100]:
I tried to clone the ark repo some time ago. For some reason that took ages and I aborted the operation. Maybe I'll try again one of these days and see whether I could submit a patch to do this cleanup. OK with you?
So I finally drafted a commit series that does this. These (lame) commit summaries show my approach (order reversed): configs: there's only x86_64 configs: remove everything i686 related scripts: remove i686 from a comment remove filter-i686.sh.* un-i686 kernel.spec.template
I'm pretty sure the first attempt or two will blow up (especially on the rhel side). And any changes to x86-config changes in HEAD will derail my series.
The only thing that RHEL builds i686 at all is kernel-headers and kernel-cross headers. Those likely need to remain for 32bit userspace packages. For Fedora, kernel-headers is a separate package. 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. 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. 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.
So what is the preferred way to push a disruptive series like this onto the virtual gremlins that run kernel-ark's CI for us?
As I think kernel-headers and kernel-cross-headers are the only i686 things built now, and those probably need to continue, I don't think CI will be an issue.
Justin
Paul Bolle
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...)
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?
Thanks,
Paul Bolle
On Fri, Apr 16, 2021 at 3:57 PM Paul Bolle pebolle@tiscali.nl 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
Justin Forbes schreef op vr 16-04-2021 om 17:08 [-0500]:
The kernel-cross-headers package could definitely be noarch, but it wasn't added that way, and I had not bothered to fix it.
Thank you. This made zero sense to me (which most of the times means I don't actually understand the problem at hand).
I'll file this under "fun thing to look into on a rainy day or - more likely this spring - a night locked into my home for no obvious benefit".
Thanks again,
Paul Bolle
Paul Bolle schreef op za 17-04-2021 om 00:36 [+0200]:
I'll file this under "fun thing to look into on a rainy day or - more likely this spring - a night locked into my home for no obvious benefit".
It's way too late over here, but I think what's going on is that each architecture's kernel-cross-headers file ships its OWN kernel-headers six times. That's, well, rather odd.
For instance for powerpc I get: rpm -qpl kernel-cross-headers-5.12.0-0.rc7.git0.1.fc35.ppc64le.rpm | grep arm-linux-gnu | wc -l 975 [...] rpm -qpl kernel-cross-headers-5.12.0-0.rc7.git0.1.fc35.ppc64le.rpm | grep x86-linux-gnu | wc -l 975
While the source tarball shows: tar tf kernel-headers-5.12.0-0.rc7.git0.1.tar.xz | grep arch-powerpc | wc -l 976
(One off for some leading directory or so.)
This quick hack pushes things in the direction of sanity (first part is kernel-headers, second part is kernel-cross-headers):
diff --git a/kernel-headers.spec b/kernel-headers.spec index 46c9f293f458..d4f9e21a28b3 100644 --- a/kernel-headers.spec +++ b/kernel-headers.spec @@ -142,21 +142,15 @@ esac
cd arch-$ARCH/include mkdir -p $RPM_BUILD_ROOT%{_includedir} -cp -a asm-generic $RPM_BUILD_ROOT%{_includedir} - -# Copy all the architectures we care about to their respective asm directories -for arch in $ARCH_LIST; do - mkdir -p $RPM_BUILD_ROOT%{_prefix}/${arch}-linux-gnu/include - cp -a asm-generic $RPM_BUILD_ROOT%{_prefix}/${arch}-linux-gnu/include/ -done +cp -a * $RPM_BUILD_ROOT%{_includedir}/
-# Remove what we copied already -rm -rf asm-generic +cd ../..
-# Copy the rest of the headers over -cp -a * $RPM_BUILD_ROOT%{_includedir}/ for arch in $ARCH_LIST; do -cp -a * $RPM_BUILD_ROOT%{_prefix}/${arch}-linux-gnu/include/ + cd arch-${arch} + mkdir -p $RPM_BUILD_ROOT%{_prefix}/${arch}-linux-gnu/ + cp -a include $RPM_BUILD_ROOT%{_prefix}/${arch}-linux-gnu/ + cd .. done
%files
Thanks,
Paul Bolle
Paul Bolle schreef op ma 19-04-2021 om 02:45 [+0200]:
each architecture's kernel-cross-headers file ships its OWN kernel-headers six times.
My point got obscured by the verbosity of my message. In short: Fedora ships clearly broken kernel-cross-headers!
In the mean time I figured out it does so since October 2019. F31 and all later releases never came with correct kernel-cross-headers. Perhaps this package should be dropped.
Paul Bolle
On Thu, Apr 22, 2021 at 5:47 AM Paul Bolle pebolle@tiscali.nl wrote:
Paul Bolle schreef op ma 19-04-2021 om 02:45 [+0200]:
each architecture's kernel-cross-headers file ships its OWN kernel-headers six times.
My point got obscured by the verbosity of my message. In short: Fedora ships clearly broken kernel-cross-headers!
In the mean time I figured out it does so since October 2019. F31 and all later releases never came with correct kernel-cross-headers. Perhaps this package should be dropped.
It can't be dropped, the package was created in response to a specific bug needing cross headers, and the package satisfied the needs of that bug. It is used, but you seem to be correct in that it is not building the way it really should. I am on vacation most of today and tomorrow, but I can take a look next week.
Justin
On Fri, Apr 16, 2021 at 10:57:44PM +0200, Paul Bolle 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...)
We can't make headers noarch: even if x86_64 and i686 headers package contents are the same, the other arches should be different, so how you will differentiate binary packages for other arches.
About building the i686 packages, we think we still need them for koji/brew dependency solving, eg. when building glibc i686 there (i686 repos are used). RHEL uses the headers provided by the kernel package, so it must still provide kernel-headers and kernel-cross-headers for i686, but other than that, everything else i686 related can be dropped I think.
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?
Thanks,
Paul Bolle
Herton R. Krzesinski schreef op vr 16-04-2021 om 19:08 [-0300]:
We can't make headers noarch: even if x86_64 and i686 headers package contents are the same, the other arches should be different, so how you will differentiate binary packages for other arches.
I was only referring to i686 and x86_64 here. Anyhow, probably not worth the trouble, but something like this might do the trick: rpm -qp --provides kernel-headers-x86.whatever.noarch.rpm [...] kernel-headers(x86-32) kernel-headers(x86-64) [...]
About building the i686 packages, we think we still need them for koji/brew dependency solving, eg. when building glibc i686 there (i686 repos are used). RHEL uses the headers provided by the kernel package, so it must still provide kernel-headers and kernel-cross-headers for i686, but other than that, everything else i686 related can be dropped I think.
Thanks for your feedback. Really appreciated.
I think I'll just slowly pump merge requests for each single step into kernel- ark. If I mess up I can count on the CI and on the large pool of reviewers to firmly remind me of my flaws.
Regards,
Paul Bolle
kernel@lists.fedoraproject.org
-
Herton R. Krzesinski -
Justin Forbes -
Justin Forbes -
Paul Bolle