Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 708810

Summary: >=sys-apps/shadow-4.7-r2 with <sys-kernel/linux-headers-4.19 - configure: error: One of sys/statfs.h linux/magic.h linux/btrfs_tree.h is missing
Product: Gentoo Linux Reporter: Jan-Matthias Braun <jan_braun>
Component: Current packagesAssignee: Gentoo's Team for Core System packages <base-system>
Status: RESOLVED FIXED    
Severity: normal CC: ap, hydrapolic, Ikonta
Priority: Normal Keywords: PATCH
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Introduce a btrfs use-flag (+btrfs for compatiblity with current ebuild)

Description Jan-Matthias Braun 2020-02-09 11:33:30 UTC
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
Comment 1 Jan-Matthias Braun 2020-02-09 11:34:46 UTC
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 2 Jeroen Roovers gentoo-dev 2020-02-09 11:50:43 UTC
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?
Comment 3 Jan-Matthias Braun 2020-02-09 12:18:20 UTC
(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.
Comment 4 Jan-Matthias Braun 2020-02-09 12:18:50 UTC
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.
Comment 5 Mike Gilbert gentoo-dev 2020-02-09 16:20:34 UTC
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.
Comment 6 Jan-Matthias Braun 2020-02-16 18:35:17 UTC
(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. :-)
Comment 7 Jan-Matthias Braun 2020-02-16 18:36:58 UTC
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.)
Comment 8 Mike Gilbert gentoo-dev 2020-02-16 21:28:18 UTC
(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.
Comment 9 Andreas Prieß 2020-03-12 00:15:55 UTC
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).
Comment 10 Larry the Git Cow gentoo-dev 2020-03-12 02:56:19 UTC
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(-)
Comment 11 Lars Wendler (Polynomial-C) gentoo-dev 2020-03-12 09:22:20 UTC
*** Bug 712214 has been marked as a duplicate of this bug. ***
Comment 12 Joakim Tjernlund 2020-03-12 09:33:03 UTC
(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.
Comment 13 Mike Gilbert gentoo-dev 2020-03-12 10:01:09 UTC
Please open bug reports if/when that happens.
Comment 14 Tomáš Mózes 2020-03-12 12:09:33 UTC
(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.
Comment 15 Mark Davies 2020-03-17 20:30:20 UTC
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.
Comment 16 Larry the Git Cow gentoo-dev 2020-03-17 21:02:18 UTC
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(-)
Comment 17 Mike Gilbert gentoo-dev 2020-03-17 21:03:08 UTC
(In reply to Mark Davies from comment #15)

Thanks for testing that.