4.14.x oldstable releases
alejandro-colomar opened this issue · 11 comments
I'm wondering how much 4.14.x should live after 4.15.0. I'll keep here research about its users, and also use it to group issues about its releases.
-
Alpine Linux 3.19
- Package: https://pkgs.alpinelinux.org/packages?name=shadow&branch=v3.19&repo=&arch=&maintainer=
- EOL: 2025-11-01 https://endoflife.date/alpine
- Maintainer: @itoffshore
-
Fedora 39
- Package: https://packages.fedoraproject.org/pkgs/shadow-utils/shadow-utils/fedora-39-updates.html
- EOL: 2024-12-07 https://endoflife.date/fedora
- Maintainer: @ikerexxe
(Edited to add more distros:)
- nixpkgs stable 23.11
Releases:
Fedora 39 is using 4.14.0 and I don't plan to update to it, so you don't need to take it into account. Usually I only port patches that are requested by the community, and those requests don't happen very frequently.
Then maybe I'll reduce the amount of patches that I backport to this series. I expect that build problems will not worry Alpine, or they would have complained already. Maybe just behavior bugs from now on (but 4.14.4 will still contain build fixes, since 4.15 won't be ready yet).
I think that's the most sensible approach
I believe there is a mistake on master and on the 4.14.4 release.
Our build system reports:
[ 63s] /usr/bin/install -c -m 644 chpasswd chfn chsh groupmems login newusers passwd su chage chpasswd groupadd groupdel groupmod useradd userdel usermod '/home/abuild/rpmbuild/BUILDROOT/shadow-4.14.4-203.1.x86_64/etc/pam.d'
[ 63s] /usr/bin/install: will not overwrite just-created '/home/abuild/rpmbuild/BUILDROOT/shadow-4.14.4-203.1.x86_64/etc/pam.d/chpasswd' with 'chpasswd'
Reason most likely is here:
https://github.com/shadow-maint/shadow/pull/928/files#r1487687347
chpasswd
is present twice.
Since this is also on master I wonder whether we could guard against this in our CI?
I believe there is a mistake on master and on the 4.14.4 release.
Thanks!
Our build system reports:
[ 63s] /usr/bin/install -c -m 644 chpasswd chfn chsh groupmems login newusers passwd su chage chpasswd groupadd groupdel groupmod useradd userdel usermod '/home/abuild/rpmbuild/BUILDROOT/shadow-4.14.4-203.1.x86_64/etc/pam.d' [ 63s] /usr/bin/install: will not overwrite just-created '/home/abuild/rpmbuild/BUILDROOT/shadow-4.14.4-203.1.x86_64/etc/pam.d/chpasswd' with 'chpasswd'
Reason most likely is here: https://github.com/shadow-maint/shadow/pull/928/files#r1487687347
chpasswd
is present twice.
Hmm, yep, it looks like an accident. Cc: @DimStar77, @loqs, @dvzrv
Since this is also on master I wonder whether we could guard against this in our CI?
I would love to. Cc: @ikerexxe
Since this is also on master I wonder whether we could guard against this in our CI?
I would love to. Cc: @ikerexxe
FWIW, this was not caught by the CI as it seems to build --without-libpam
there.
Only the combination --with-libpam --enable-account-tools-setuid
would have triggered the CI to fail.
(the original reporter obviously tested --with-libpam --disable-account-tools-setuid
, which was also fine)
To catch all cases, this would call for a rather complete matrix of configure parameters switching on/off
FWIW, this was not caught by the CI as it seems to build
--without-libpam
there. Only the combination--with-libpam --enable-account-tools-setuid
would have triggered the CI to fail.(the original reporter obviously tested
--with-libpam --disable-account-tools-setuid
, which was also fine)To catch all cases, this would call for a rather complete matrix of configure parameters switching on/off
Well, then I guess packagers act as a test of combinations actually in use. Not ideal, but not fatal.
Maybe we could test the combinations that downstreams are using.
Since this is also on master I wonder whether we could guard against this in our CI?
I would love to. Cc: @ikerexxe
I don't think it's feasible to test all the configuration option combinations.
In any case, and from my perspective, it would be nice to include other distributions in our CI. Clearly we upstream maintainers cannot maintain all distributions, but if the downstream maintainers could do it, we would all win.
There's another stable distro using 4.14.x:
- nixpkgs stable 23.11
Fedora doesn't use this branch, Alpine hasn't upgraded since 4.14.2, and nixpkgs is EOL in a month.
I declare the 4.14.x branch EOL now, with its last release being 4.14.7
https://github.com/shadow-maint/shadow/releases/tag/4.14.7
@hallyn , I can't remove the branch due to its protection. Please remove it.