4.15 release
hallyn opened this issue · 44 comments
I'm thinking of cutting a 4.15(-rc1) release. Please comment here if there are specific PRs or issues which should be addressed first.
Rationale: These fix soon-to-be compiler errors. If we fix them now, the 4.15 release series will see less build error reports. It's a preparation for GCC 14 and Clang 16, which become more aggressive regarding compiler errors.
CC: @thesamesam
- Any PR listed in #920.
Rationale: I'll be backporting those to 4.14.4. It would be better if 4.15 has them without a backport.
Rationale: It contains a typo fix that fixes incorrect CFLAGS in some tests. I expect that systems with pedantic build rules, like Gentoo, might have build problems without it.
Good to see that we have a list. I'll try to dedicate some time in the following days to review those PRs.
By the way, I may have a PR also, but I haven't posted it yet. If I have time it should go to 4.15, if not, well, it'll go to the next one.
Thanks!
This is the PR that I was talking about #927. Only in the end I didn't implement it myself.
I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.
I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.
I'm fine with delaying it a little bit, but I'd like to see this one (or a similar approach) merged.
I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.
I'm fine with delaying it a little bit, but I'd like to see this one (or a similar approach) merged.
It seems Tobias doesn't have concerns anymore, and to me, the code looks simple. So, for me it's ok.
It seems Tobias doesn't have concerns anymore, and to me, the code looks simple. So, for me it's ok.
Correct. I was just curious why a feature is added if another program already has it. But then I noticed the : issue with newusers, so there is clearly no objection anymore from my side.
Ok - I think everything is merged now, so we should be ready for a 4.15-pre1?
Yes, it looks like everything is ready, at least from my side.
I opened #939 now for the bug.
I didn't yet have time to check it more deeply but thought since we are short before a new stable release it might be time to fix it.
I had time today to try to build 4.15.0-rc1 and it looks good on my end. Unfortunately I can't push it to Fedora rawhide (what will become Fedora 40) because we are dealing with the provision of passwd binary from shadow and I'd like to give some time for things to settle before rebasing. I'll try to do that next week, once more automated tests are run and some people test that the change is working properly.
I think I've merged everything needed for -rc1. Are we missing anything else?
Before the release, we should probably fix #945. But since there are no patches for it yet, I think we're ready for -rc2.
Maybe the Georgian translation?
Hi @hallyn,
You haven't signed 4.15.0-rc2 :S
gpg -v shadow-4.15.0-rc2.tar.xz.asc
gpg: enabled compatibility flags:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: assuming signed data in 'shadow-4.15.0-rc2.tar.xz'
gpg: Signature made vie 16 feb 2024 01:07:14 CET
gpg: using RSA key 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: Can't check signature: No public key
Hi @hallyn,
You haven't signed 4.15.0-rc2 :S
Hi @hallyn,
If this is maybe a new (sub)key, maybe you forgot to push it to the keyserver?
$ gpg --verify shadow-4.15.0-rc1.tar.xz{.asc,}
gpg: Signature made Fri Feb 16 00:27:47 2024 CET
gpg: using RSA key 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: Can't check signature: No public key
$ gpg --recv-keys 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: keyserver receive failed: No data
Jinkeys! gpg is not treating me right. That is not how that subkey was supposed to be created+used.
@alejandro-colomar could you try again now? I pushed to ubuntu, not sure what keyservers the cool kids are using these days.
@alejandro-colomar could you try again now? I pushed to ubuntu, not sure what keyservers the cool kids are using these days.
I had similar problems a couple of weeks ago. I created my new subkey, and pushed to the default keyserver, but other people reported that my key wasn't in the keyservers. The ubuntu keyserver also had a few errors with my new subkey back then:
$ gpg --keyserver keyserver.ubuntu.com --recv-keys D57633D441E25BB5
gpg: keyserver receive failed: Server indicated a failure
(the above happened on Sun, 4 Feb 2024)
@alejandro-colomar could you try again now?
With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:
alx@debian:~$ gpg --list-key --keyid-format 0xlong hallyn
pub rsa2048/0xB175CFA98F192AF2 2012-05-07 [SC]
66D0387DB85D320F8408166DB175CFA98F192AF2
uid [ full ] Serge Hallyn <sergeh@kernel.org>
uid [ full ] Serge Hallyn (kernel.org) <serge@hallyn.com>
sub rsa2048/0x993087AF1E967E77 2019-10-20 [A]
sub rsa2048/0x345007B943143245 2019-10-20 [E]
sub rsa2048/0x3570DA17270ACE24 2019-10-20 [S]
sub rsa2048/0xD62F64D09CDDF031 2012-05-07 [E]
pub rsa2048/0xE9FEEA06A85E3F9D 2010-06-07 [SC]
F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
uid [ full ] Serge Hallyn <serge.hallyn@ubuntu.com>
sub rsa2048/0xC527609C7E1875BD 2010-06-07 [E]
alx@debian:~$ gpg --recv-keys --keyserver keyserver.ubuntu.com 66D0387DB85D320F8408166DB175CFA98F192AF2
gpg: key B175CFA98F192AF2: "Serge Hallyn <sergeh@kernel.org>" 1 new signature
gpg: key B175CFA98F192AF2: "Serge Hallyn <sergeh@kernel.org>" 1 new subkey
gpg: Total number processed: 1
gpg: new subkeys: 1
gpg: new signatures: 1
alx@debian:~$ gpg --recv-keys --keyserver keyserver.ubuntu.com F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
gpg: key E9FEEA06A85E3F9D: "Serge Hallyn <serge.hallyn@ubuntu.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
So now:
alx@debian:~$ gpg --list-key --keyid-format 0xlong hallyn
pub rsa2048/0xB175CFA98F192AF2 2012-05-07 [SC]
66D0387DB85D320F8408166DB175CFA98F192AF2
uid [ full ] Serge Hallyn <sergeh@kernel.org>
uid [ full ] Serge Hallyn (kernel.org) <serge@hallyn.com>
sub rsa2048/0x993087AF1E967E77 2019-10-20 [A]
sub rsa2048/0x345007B943143245 2019-10-20 [E]
sub rsa2048/0x3570DA17270ACE24 2019-10-20 [S]
sub rsa2048/0xD62F64D09CDDF031 2012-05-07 [E]
sub rsa4096/0x7DC24C36C3341D20 2024-02-04 [S]
pub rsa2048/0xE9FEEA06A85E3F9D 2010-06-07 [SC]
F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
uid [ full ] Serge Hallyn <serge.hallyn@ubuntu.com>
sub rsa2048/0xC527609C7E1875BD 2010-06-07 [E]
With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:
Which is your default keyserver? I'll push it to there, double my chances :)
With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:
Which is your default keyserver? I'll push it to there, double my chances :)
Whatever the default is, as I tend to not change defaults as much as I can. However, that keyserver seems to be failing more often than not, so I may change it for the ubuntu one some day (that one also proved to fail, but less often)...
It seems to be using hkps://keys.openpgp.org when I don't specify one.
Ok, I've pushed it to keys.openpgp.org as well.
fwiw the reason I created this subkey was because something was upset that my signing keys were not rsa4096. So this gives me a bigger, hardware-bound signing subkey. FTW I guess.
This is the only remaining thing, I think:
* [login and logoutd broken on systems with utmps #945](https://github.com/shadow-maint/shadow/issues/945)
Perhaps this can be reverted. Or maybe have utmpx unconditionally available?
It would be even better if utmps was supported (being a secure implementation for musl based distros), in case you didn't want to bring the entirety of utmp.
@alejandro-colomar It appears that #945 has been solved. Are there any other issues before the release of 4.15?
@alejandro-colomar It appears that #945 has been solved. Are there any other issues before the release of
4.15?
No. But @hallyn will do that release, not me. I only release from stable branches (currently, 4.14.x).
I plan to release 4.14.6 on 2024-03-02 (my birthday :). Maybe it would be a good idea to release 4.15 after that, as we will get a little bit more testing for these recent bug fixes, some of which are present in the stable branch. Serge, what are your plans? Maybe an -rc around the release of 4.14.6, and then 4.15.0 a few days later?
I'm just waiting for some go/no-gos from distro maintainers. If all's good, I'm happy to tag final 4.15.
I see - more has been merged into master since 4.15.0-rc2 than I thought. I can tag -rc3 around march 3 as @alejandro-colomar suggested, or i can tag one now if someone wants to test, and then tag an rc-4 in a week.
Well, if you want to -rc3 already... I don't expect anything else to go in, unless there are new bug reports, so maybe that helps.
and then tag an rc-4 in a week.
This Friday ends that week. Since/if nothing seems to be problematic, should we release final 4.15.0 on Friday?
I think that is phenomenal.
BTW, there seems to be a release draft called Draft. Is that a leftover?
Yes, let's release 4.15.0 on Friday.
yeah, the draft release was the first of the series which i had posted. I was sure I had published it, and when I noticed it sometime last week it still resisted being published... should probably delete it.