Hello Guix,
some updates related to the release. I think it is important to inform about this especially since the release candidate is out and hopefully the release will be out soon as well. I am not sure what date the release will be, but I am pretty sure I/we won't manage to do it tommorrow, being the first release target, see <https://codeberg.org/guix/release-planning/wiki/release-1.5.0-project> During the week the RC1 is out, couple of issues have been discovered. Some of them already do have a solution but some don't. Not all of these issues are completely critical, especially since some of the issues also presented in 1.4.0 and it seems there aren't really reports of them. But mostly, it all looks fine. We have a milestone, so up to date state can always be found there: <https://codeberg.org/guix/guix/milestone/26686>. I tried to order the issues by priority. I expect the last three issues to not be fixed in time for the release and I don't think they matter that much. - AArch64 boot issues It has been established based on previous e-mails to the mailing list that the AArch64 system artifacts are by no means satisfactory. They still do not boot on hardware that would definitely be a candidate for installation (ie. ThinkPad Snapdragon). Also, on headless systems, there is no shell started on the serial port, making installation possible only on systems with a display. I have already prepared to PRs that should hopefully resolve these issues. In case you're an owner of an UEFI AArch64 device, it would be helpful if you tried them out (pre-built images are published in the PRs). Ideally, the image should be bootable both from USB drives and SD cards (though these might be trickier and I expect there will be issues picked up over the coming months to make the system artifacts better for next release, bootable on more platforms). <https://codeberg.org/guix/guix/pulls/5320>, <https://codeberg.org/guix/guix/pulls/5346>, <https://codeberg.org/guix/guix/pulls/5359>. - Access to ftp.gnu.org Apart from technical problems, there is also still a pending problem of access to {alpha,ftp}.gnu.org. Unfortunately it's unclear how to proceed with publishing of the artifacts. I have requested access, but received no reply from Guix maintainers. Efraim wanted to request access, but I haven't heard from him in a long time. - Cannot log in to Gnome through SDDM <https://codeberg.org/guix/guix/issues/3629> This is a problem on AArch64, where SDDM is the default in %desktop-services. That means that users who use the installer to install Gnome, will end up with a system where they cannot log in to Gnome. It seems GDM is supported on AArch64 as well, so one workaround would be to change the default on AArch64 to GDM. However, this change seems a bit drastic to existing users who might get confused by it, it is a breaking change in the end. - NEWS <https://codeberg.org/guix/guix/issues/5165> There has been many changes since 1.4.0, but not many of them are documented in the NEWS. Changes worth mentioning have to be gathered and added to the file afterwards. In case you remember significant changes during the three years, do share them so they are not missed. - Cancellation of Guix System installation leads to 'corrupted' database <https://codeberg.org/guix/guix/issues/5324> When in the graphical installer, at the step that performs the system initialization, cancellation by C-c will keep the sqlite database in a wrong state, leading to `No such file or directory` on .drv files on subsequent runs of the installation. This can also be an issue in the manual installation, after stopping the cow-store service. As long as the cow-service is not stopped, it should all be fine. - QEMU not building on some machines on AArch64 <https://codeberg.org/guix/guix/issues/2447> This is a problem for us, since it affects machines on ci.guix.gnu.org. For this release, there is an effort to build the artifacts through CI. For the system images, qemu-minimal is necessary to generate the images. A workaround here could be reintroducing a patch that disabled migration-test. It has been removed, because on x86_64 there are no longer any issues. And neither on some AArch64 machines, but seems that not all. Still, even after this is fixed, it takes CI quite a large amount of time to build everything for AArch64. So while we've got the tarball few days after the build was handed to CI, the iso and qcow2 probably still could not have been biult (even if it wasn't for the QEMU build issues). This has been known beforehand since the AArch64 builds are behind. - Plasma not building on AArch64 This is fixed already, but in RC1, choosing plasma in the installer will lead to long build process only to meet with a failure. See <https://codeberg.org/guix/guix/pulls/4846> in case you're interested in details. Issues that I think we can leave if there is no time to fix them, follow. I will definitely discuss them with rest of the release-team to confirm they also don't think they're critical, though. - guix system switch-generation picks wrong bootloader on new system <https://codeberg.org/guix/guix/issues/5109> This is visible mainly on AArch64, where grub-pc is not supported and switch-generation is sometimes impossible, like from generation two to first one, failing on bootloader installation. - Shepherd (and the Guix Installer) hangs when date changes by more than a ~day <https://codeberg.org/guix/guix/issues/5115> This has been an issue also in 1.4.0 and I couldn't find any opened issues related to the installation itself. It can happen for example on systems that do not have hardware clock or if the hardware clock has been reset due to discharged battery. The date has to be set then, because otherwise sites do not load due to certificates not being valid. This is still done manually, though. The installer does not ship with NTP. So the user could be somewhat aware of this being caused by the date change they just did. It is unlikely this will be fixed in 1.5.0, I think. The issue is in Guile Fibers and it has been known for more than two years. While lately there has been activity in the issue, there is still no definitive fix published. - Generating source tarball with Guix and through CI <https://codeberg.org/guix/guix/issues/4769> As part of the effort of getting the artifacts generated through CI, it would be great if the source was also generated by it. There is a `dist-package` procedure in Guix. However, it has problems, currently it leaves in store paths, through the various patch phases. Moreover these patches are necessary for running `make`, so it's not as easy to get rid of them. We cannot tolerate having local store paths in the source tarball. I have started work on this <https://codeberg.org/guix/guix/pulls/4978>, but I was unable to finish it and had other more pressing issues to look at. It thus seems that for this release, we will be left with generation of the source manually through the Makefile's `dist` target, like was also the case with previous releases. Well still, it's a huge step forward in the other artifacts that are generated through CI. Phew, sorry for such a long e-mail. In case you are interested, definitely feel free to help with any of the mentioned issues, it wil be welcome. :) Let's align in the associated issues and/or PRs for the issue. Rutherther
