The build unconditionally enables --with-btrfs, but older linux-headers do not provide the requested headers. Thus, the merge fails with linux-headers-4.4 or 4.19. Reproducible: Always Steps to Reproduce: 1. emerge recent sys-apps/shadow on a machine with linux-headers-4.4 or 4.19
Created attachment 613048 [details, diff] Introduce a btrfs use-flag (+btrfs for compatiblity with current ebuild) Introduce a btrfs use-flag (+btrfs for compatiblity with current ebuild) to enable building with older linux-headers by disabling the btrfs USE.
Comment on attachment 613048 [details, diff] Introduce a btrfs use-flag (+btrfs for compatiblity with current ebuild) What did you plan to do after introducing the USE flag? Have people enable or disable it based on whether they find sys-kernel/linux-headers-4.4* or sys-kernel/linux-headers-4.19* or something else is installed?
(In reply to Jeroen Roovers from comment #2) > Comment on attachment 613048 [details, diff] [details, diff] > Introduce a btrfs use-flag (+btrfs for compatiblity with current ebuild) > > What did you plan to do after introducing the USE flag? Have people enable > or disable it based on whether they find sys-kernel/linux-headers-4.4* or > sys-kernel/linux-headers-4.19* or something else is installed? Yes. It is not the most elegant solution, but to install shadow with linux-headers-4.4* or 4.19*, you would have to use "-btrfs", while for current linux-headers releases the behaviour wouldn't change.
And sorry, I forgot to post the actual error message. :-) Actually, configure bails out with: configure: error: One of sys/statfs.h linux/magic.h linux/btrfs_tree.h is missing And linux/btrfs_tree.h is actually missing for those linux-headers releases.
It sounds like the ebuild needs DEPEND=">=sys-kernel/linux-headers-${VER}", where ${VER} is yet to be determined. I imagine linux-headers-5.4.x will be stabilized sometime soon, but we could add a "btrfs" USE flag to control the dependency if that doesn't happen soon enough.
(In reply to Mike Gilbert from comment #5) > It sounds like the ebuild needs DEPEND=">=sys-kernel/linux-headers-${VER}", > where ${VER} is yet to be determined. Actually, the requirement for ${VER} comes not from the shadow package, but from the ebuild unconditionally enabling btrfs support. Only with btrfs support, older versions of kernel headers are not supported anymore. But there was actually a type of mine, which I repeated with relentless stubbornness: 4.19 is not a problem, only 4.4 and 4.9 were tested. > I imagine linux-headers-5.4.x will be stabilized sometime soon, but we could > add a "btrfs" USE flag to control the dependency if that doesn't happen soon > enough. One could also call it old-kernel. :-) I personally have a few older machines which I am running on LTS-kernels, mostly due to the fact that I do not have easy access to the machines and want to keep basic things unchanged. While I am not happy with this arrangement myself, they are using supported LTS kernels. I.e., Gentoo has sys-kernel/gentoo-sources in versions down to 4.4, so it concerns at least the two oldest LTS families in tree. And on all these versions you can practically build sys-apps/shadow out of the box -- as long as you do not ask for btrfs support. :-)
Just to make this clear: kernel header versions affected: 4.4, 4.9. Kernel header versions unaffected: 4.19+ Untested: 4.14. (Of course, I did not test *every* linux-headers version above 4.19, but 4.19, 5.4 and 5.5 are definitely working. 5.3 I think too.)
(In reply to Jan-Matthias Braun from comment #6) > (In reply to Mike Gilbert from comment #5) > > It sounds like the ebuild needs DEPEND=">=sys-kernel/linux-headers-${VER}", > > where ${VER} is yet to be determined. > > Actually, the requirement for ${VER} comes not from the shadow package, but > from the ebuild unconditionally enabling btrfs support. My preference would be to continue enabling btrfs support unconditionally, and depend on an appropriate version of linux-headers. > > I imagine linux-headers-5.4.x will be stabilized sometime soon, but we could > > add a "btrfs" USE flag to control the dependency if that doesn't happen soon > > enough. > > One could also call it old-kernel. :-) You should be able to run an old kernel with new headers.
Same problem here with stable sys-apps/shadow-4.8-r3 and sys-kernel/linux-headers-4.9 I have sys-kernel/gentoo-sources-4.9.210 running on all systems since 4.9 is the current LTS kernel with longest lifetime (at least upstream).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4cbeec6df5defe71030e921b88876de2c992caf commit a4cbeec6df5defe71030e921b88876de2c992caf Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-03-12 02:55:43 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-03-12 02:55:43 +0000 sys-apps/shadow: depend on >=sys-kernel/linux-headers-4.19 Closes: https://bugs.gentoo.org/708810 Package-Manager: Portage-2.3.92_p3, Repoman-2.3.20_p118 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/shadow/shadow-4.7-r2.ebuild | 14 ++++++++------ sys-apps/shadow/shadow-4.8-r3.ebuild | 14 ++++++++------ sys-apps/shadow/shadow-4.8.1-r1.ebuild | 14 ++++++++------ 3 files changed, 24 insertions(+), 18 deletions(-)
*** Bug 712214 has been marked as a duplicate of this bug. ***
(In reply to Mike Gilbert from comment #8) > (In reply to Jan-Matthias Braun from comment #6) > > (In reply to Mike Gilbert from comment #5) > > > It sounds like the ebuild needs DEPEND=">=sys-kernel/linux-headers-${VER}", > > > where ${VER} is yet to be determined. > > > > Actually, the requirement for ${VER} comes not from the shadow package, but > > from the ebuild unconditionally enabling btrfs support. > > My preference would be to continue enabling btrfs support unconditionally, > and depend on an appropriate version of linux-headers. > > > > I imagine linux-headers-5.4.x will be stabilized sometime soon, but we could > > > add a "btrfs" USE flag to control the dependency if that doesn't happen soon > > > enough. > > > > One could also call it old-kernel. :-) > > You should be able to run an old kernel with new headers. That can be dangerous, user space may think new features are available then and do not have fallbacks. I have seen this twice(samba and NFS was involved) so now I never upgrade to newer headers than the kernel itself.
Please open bug reports if/when that happens.
(In reply to Andreas Prieß from comment #9) > Same problem here with stable sys-apps/shadow-4.8-r3 and > sys-kernel/linux-headers-4.9 > > I have sys-kernel/gentoo-sources-4.9.210 running on all systems since 4.9 is > the current LTS kernel with longest lifetime (at least upstream). That only means some big consumer is using it, but it's a pain to keep up the patching for older versions. Just switch to newer LTS as the Projected EOL will probably be prolonged (as was done before). Greg always suggests using the latest LTS for servers.
Probably too late but sys-apps/shadow-4.8-r[34] have no problem with sys-kernel/linux-headers-4.14-r1. I needed to use --nodeps to get r4 to emerge due to the new dependency. As with other above I try and keep my kernel and header in sync to avoid possible problems. I am currently sticking with the 4.14 kernel as it is LTS until 2024 I believe.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=24dc9ea5e7fda8ac045b3ded1e47e7841d68a2b5 commit 24dc9ea5e7fda8ac045b3ded1e47e7841d68a2b5 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-03-17 21:01:32 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-03-17 21:01:32 +0000 sys-apps/shadow: depend on >=sys-kernel/linux-headers-4.14 Bug: https://bugs.gentoo.org/708810 Package-Manager: Portage-2.3.92_p3, Repoman-2.3.20_p118 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/shadow/shadow-4.7-r2.ebuild | 2 +- sys-apps/shadow/shadow-4.8-r4.ebuild | 2 +- sys-apps/shadow/shadow-4.8.1-r2.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
(In reply to Mark Davies from comment #15) Thanks for testing that.
