pre-releases (for systemd & co) in core-testing
Hello everybody, I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well... Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this. Of course this had not been detected before, because packages in testing were ok in that combination. So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better... Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf: [testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/ Feedback welcome! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On May 15, 2024 5:08:47 AM EDT, Christian Hesse <list@eworm.de> wrote:
Hello everybody,
I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well...
Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this.
Of course this had not been detected before, because packages in testing were ok in that combination.
So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better...
Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf:
[testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/
Feedback welcome!
The options that come to mind are either additional official -unstable repos or AUR packages with third-party repos. -- Best, Daniel <https://danielcapella.com>
On 5/15/24 11:08 AM, Christian Hesse wrote:
Hello everybody,
I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well...
Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this.
Of course this had not been detected before, because packages in testing were ok in that combination.
So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better...
Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf:
[testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/
Feedback welcome!
Hi Christian, Thanks for setting up a custom repo for such pre-releases. It directly paid off as we were able to discover a breaking change for mkinitcpio in the current systemd 256rc2 release (and thus in the future 256 stable one) [1]! For people trying out systemd 256rc2 via Christian's custom repo, be aware that running mkinitcpio to re-generate your initramfs (`mknitcpio -P`/`mkinitcpio -p **kernel_name**`) on a system that do *not* have the 'systemd' hook in the HOOKS array of the mkinitcpio.conf file will lead to an unbootable state where the root partition fails to mount at boot. If you already in such state, you can get back to a functional state by downgrading systemd{,-libs,-sysvcompat} to v255.6-1 and re-running `mkinitcpio -P` from a chroot. The cause of this issue is already identified and being brainstormed ;) (see the below issue for more details). [1] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/270 -- Regards, Robin Candau / Antiz
Robin Candau <antiz@archlinux.org> on Wed, 2024/05/15 15:25:
Thanks for setting up a custom repo for such pre-releases. It directly paid off as we were able to discover a breaking change for mkinitcpio in the current systemd 256rc2 release (and thus in the future 256 stable one) [1]!
For people trying out systemd 256rc2 via Christian's custom repo, be aware that running mkinitcpio to re-generate your initramfs (`mknitcpio -P`/`mkinitcpio -p **kernel_name**`) on a system that do *not* have the 'systemd' hook in the HOOKS array of the mkinitcpio.conf file will lead to an unbootable state where the root partition fails to mount at boot.
If you already in such state, you can get back to a functional state by downgrading systemd{,-libs,-sysvcompat} to v255.6-1 and re-running `mkinitcpio -P` from a chroot.
The cause of this issue is already identified and being brainstormed ;) (see the below issue for more details).
[1] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/270
Oh, forgot to mention here... I had pushed `mkinitcpio 39.1-1.1` to my custom repository, which adds my proposed fix [2]. With that in place we have no more known issues. [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_request... -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Christian Hesse <list@eworm.de> on Wed, 2024/05/15 11:08:
Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf:
[testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/
Feedback welcome!
Pushed systemd 256rc3-1 last night. All the same applies... Please keep testing! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Christian Hesse <list@eworm.de> on Thu, 2024/05/23 09:16:
Christian Hesse <list@eworm.de> on Wed, 2024/05/15 11:08:
Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf:
[testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/
Feedback welcome!
Pushed systemd 256rc3-1 last night. All the same applies... Please keep testing!
And just pushed systemd 256rc3-2, which does fast-forward to current git main (6448993a4b2897658d32c5ec423841e22aa14c68). Just two items are left for the milestone, so the final release should be imminent now. https://github.com/systemd/systemd/milestone/33 -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Christian Hesse <list@eworm.de> on Wed, 2024/05/29 12:19:
Just two items are left for the milestone, so the final release should be imminent now.
There had been some more intermediate milestone items, but finally it is cleared. For last verification 256-rc4 has been tagged, if all goes well the final version should have no more code changes. For even more testing I pushed this one to core-testing, though it will not move to core. I expect the final release early next week, so the risk of crazy build breakage should be fairly small. Have fun testing and enjoy the new features! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Am Thu, 6 Jun 2024 23:14:36 +0200 schrieb Christian Hesse <list@eworm.de>:
For even more testing I pushed this one to core-testing, though it will not move to core. I expect the final release early next week, so the risk of crazy build breakage should be fairly small.
Have fun testing and enjoy the new features!
Please don't push unreleased packages to -testing. There's no reason to make an exception just for your packages. -Andy
participants (4)
-
Andreas Radke
-
Christian Hesse
-
Daniel M. Capella
-
Robin Candau