shadow-maint/shadow

4.14.x oldstable releases

alejandro-colomar opened this issue · 11 comments

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:

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.