bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)
On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: > guix-comm...@gnu.org writes: > > > efraim pushed a change to branch core-updates > > in repository guix. > > > > from c8c6883398 gnu: dico: Add libxcrypt dependency. > > new 9804f8c149 gnu: coeurl: Update to 0.3.1. > > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. > > new 0e06c9697a gnu: Remove fontforge-20190801. > > > > The 3 revisions listed above as "new" are entirely new to this > > repository and will be described in separate emails. The revisions > > listed as "add" were already present in the repository and have only > > been added to this reference. > > These changes confused me as I was looking at the trying to work out why > they needed to be pushed to core-updates. Eventually I figured out that > Git is right, these commits are entirely new, but they duplicate > existing commits already pushed to master (e.g. 0e06c9697a is a > duplicate of 3d5f4b2d7dda). > > I know the new guidance says to "Avoid merging master in to the branch", > but one of the reasons for that is to avoid situations just like this > where merges are done incorrectly and commits are duplicated between > branches. > > To fix this, I think we should rebase core-updates on master and drop > these commits. I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0 failed on core-updates but a bump to 0.3.1 fixed the build, and it could go to master also. Similar story with working to remove fontforge-20190801 which no longer built on core-updates. I figured that applying the patch to both branches would make it easier to merge master into core-updates since there would be less drift between the two. What is the correct way to apply a patch to multiple branches? -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)
guix-comm...@gnu.org writes: > efraim pushed a change to branch core-updates > in repository guix. > > from c8c6883398 gnu: dico: Add libxcrypt dependency. > new 9804f8c149 gnu: coeurl: Update to 0.3.1. > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. > new 0e06c9697a gnu: Remove fontforge-20190801. > > The 3 revisions listed above as "new" are entirely new to this > repository and will be described in separate emails. The revisions > listed as "add" were already present in the repository and have only > been added to this reference. These changes confused me as I was looking at the trying to work out why they needed to be pushed to core-updates. Eventually I figured out that Git is right, these commits are entirely new, but they duplicate existing commits already pushed to master (e.g. 0e06c9697a is a duplicate of 3d5f4b2d7dda). I know the new guidance says to "Avoid merging master in to the branch", but one of the reasons for that is to avoid situations just like this where merges are done incorrectly and commits are duplicated between branches. To fix this, I think we should rebase core-updates on master and drop these commits. signature.asc Description: PGP signature
bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)
Efraim Flashner writes: > On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >> guix-comm...@gnu.org writes: >> >> > efraim pushed a change to branch core-updates >> > in repository guix. >> > >> > from c8c6883398 gnu: dico: Add libxcrypt dependency. >> > new 9804f8c149 gnu: coeurl: Update to 0.3.1. >> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. >> > new 0e06c9697a gnu: Remove fontforge-20190801. >> > >> > The 3 revisions listed above as "new" are entirely new to this >> > repository and will be described in separate emails. The revisions >> > listed as "add" were already present in the repository and have only >> > been added to this reference. >> >> These changes confused me as I was looking at the trying to work out why >> they needed to be pushed to core-updates. Eventually I figured out that >> Git is right, these commits are entirely new, but they duplicate >> existing commits already pushed to master (e.g. 0e06c9697a is a >> duplicate of 3d5f4b2d7dda). >> >> I know the new guidance says to "Avoid merging master in to the branch", >> but one of the reasons for that is to avoid situations just like this >> where merges are done incorrectly and commits are duplicated between >> branches. >> >> To fix this, I think we should rebase core-updates on master and drop >> these commits. > > I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0 > failed on core-updates but a bump to 0.3.1 fixed the build, and it could > go to master also. Similar story with working to remove > fontforge-20190801 which no longer built on core-updates. I figured that > applying the patch to both branches would make it easier to merge master > into core-updates since there would be less drift between the two. You're right regarding drift, but unfortunately I think this duplication of commits creates merge conflicts, or at least makes them much more likely. > What is the correct way to apply a patch to multiple branches? I'd frame the problem differently, we don't want multiple branches, we want everything on master. Unfortunately for some changes that is hard to test and creates too much churn, so for those changes they go to a branch where they can be built and tested prior to pushing/merging them to master. To avoid changes happening on a topic branch and master, I think it's important that any change that can be made on master, is made on master. That should avoid the problem where someone else comes along and doesn't realise a change has been made on core-updates, and duplicates that on master. In this instance, you pushed the changes to master, which is great. I realise it does require more up front effort, but if you see a failing build on a topic branch that's fixed by some change on master, the topic branch should be rebased to include those changes. Providing it's done correctly, merging should be fine as well, but the docs now say to avoid that and prefer rebasing (mostly because of how merging has introduced duplicate commits in to core-updates) This rebasing or merging will minimise the drift between the two branches as well, while avoiding Git conflicts and commit duplication. So I don't think we want to be applying patches to multiple branches. If it can be applied to master, it should be applied there, then all the branches should be rebased to include it. Does that make sense? This isn't really a "doing it wrong" thing, more that we need to try and optimise the process for managing branches. I haven't got a concise definition of what we're trying to optimise for, but in this instance we want to avoid Git issues like merge conflicts and avoid duplication and complexity by making changes that can be made on master, just on master. signature.asc Description: PGP signature
bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)
Christopher Baines writes: > Efraim Flashner writes: > >> On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >>> guix-comm...@gnu.org writes: >>> >>> > efraim pushed a change to branch core-updates >>> > in repository guix. >>> > >>> > from c8c6883398 gnu: dico: Add libxcrypt dependency. >>> > new 9804f8c149 gnu: coeurl: Update to 0.3.1. >>> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. >>> > new 0e06c9697a gnu: Remove fontforge-20190801. >>> > >>> > The 3 revisions listed above as "new" are entirely new to this >>> > repository and will be described in separate emails. The revisions >>> > listed as "add" were already present in the repository and have only >>> > been added to this reference. >>> >>> These changes confused me as I was looking at the trying to work out why >>> they needed to be pushed to core-updates. Eventually I figured out that >>> Git is right, these commits are entirely new, but they duplicate >>> existing commits already pushed to master (e.g. 0e06c9697a is a >>> duplicate of 3d5f4b2d7dda). >>> >>> I know the new guidance says to "Avoid merging master in to the branch", >>> but one of the reasons for that is to avoid situations just like this >>> where merges are done incorrectly and commits are duplicated between >>> branches. >>> >>> To fix this, I think we should rebase core-updates on master and drop >>> these commits. I've gone ahead and done this now. signature.asc Description: PGP signature
bug#71437: error: You found a bug: the program '/gnu/store/vbxf3hm2c0wsj2l37ms44k2isiw98ijq-compute-guix-derivation'
Hello, Today I installed `guix` on Ubuntu 24.04 LTS, and then issued `guix pull` as suggested on the installation page. Wheels turned for some time, but an error resulted. The error message encouraged me to email the full output of the command to this email address, which is why I am writing. Full output below. I'm happy to share additional information if it's helpful. Best, Anthony guixpull(base) ─╯ Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to bc8a41f (76,196 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git bc8a41f substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% bash-static-5.1.8 646KiB 1001KiB/s 00:01 [##] 100.0% glibc-2.33 8.2MiB 7.9MiB/s 00:01 [##] 100.0% bash-minimal-5.1.8 624KiB 8.8MiB/s 00:00 [##] 100.0% gcc-10.3.0-lib 4.6MiB 8.6MiB/s 00:01 [##] 100.0% libffi-3.3 67KiB 6.4MiB/s 00:00 [##] 100.0% libgc-8.0.4 214KiB 4.6MiB/s 00:00 [##] 100.0% libgpg-error-1.42 213KiB 4.3MiB/s 00:00 [##] 100.0% libunistring-0.9.10 492KiB 5.9MiB/s 00:00 [##] 100.0% libgcrypt-1.8.8 590KiB 3.1MiB/s 00:00 [##] 100.0% pkg-config-0.29.2 187KiB 5.4MiB/s 00:00 [##] 100.0% guile-gcrypt-0.3.0 143KiB 3.3MiB/s 00:00 [##] 100.0% guile-3.0.7 10.7MiB 9.4MiB/s 00:01 [##] 100.0% building /gnu/store/al0d6f30wj4f4w68v2gqdkb367v75f4x-config.scm.drv... building /gnu/store/60h4f5jy7x05bgwjxp41gg5wsypaixn6-git.scm.drv... building /gnu/store/n5w7gbkyyiav73f9yypafvw2n6z5jq8n-hash.scm.drv... building /gnu/store/6s71xgpxyr3n6j68613kh60bgw7bv1vv-module-import.drv... building /gnu/store/pcm2w68y4h2aq7xzxxw4zsidczsxplxs-module-import.drv... building /gnu/store/is3rlhy9aczi658by7qadyi3vf0k04i2-module-import-compiled.drv... building /gnu/store/j2673azlysfdcbrymqr1afrycnx0di7b-module-import-compiled.drv... building /gnu/store/53ndia9g3r2g41daa5x3fd59ky65xddx-compute-guix-derivation.drv... Computing Guix derivation for 'x86_64-linux'... /Backtrace: 16 (primitive-load "/gnu/store/vbxf3hm2c0wsj2l37ms44k2isiw98ijq-compute-guix-derivation") In ice-9/eval.scm:
bug#44877: [PATCH] gnu: grub: load lvm grub module.
From: Ashish SHUKLA * gnu/bootloader/grub.scm (make-grub-configuration): load lvm grub module when generating configuration for cryptodisks setup. Change-Id: I1dbb0c7dbf68a5f93db76dc29793a1f73be49ee2 --- Hi, I have a Guix setup which has a LUKS2 partition containing a LVM volume group on which kernels and initrds reside. I think this is one of the common setups in which folks uses disk-encryption on GNU/Linux. Since in Guix the kernels/initrd don't get copied to /boot it requires GRUB to be able to unlock the LUKS2 volume, and look inside the LVM partitions to find initrd, and kernel. The former part is already there, this patch enables the latter part, so folks like me who use LVM on top of LUKS be able to boot, otherwise it requires going to grub command-line, and running "insmod lvm" prior to selecting a boot option. Thanks, Ashish gnu/bootloader/grub.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm index 2723eda5f4..a4ca0bc217 100644 --- a/gnu/bootloader/grub.scm +++ b/gnu/bootloader/grub.scm @@ -445,7 +445,7 @@ (define* (make-grub-configuration grub config entries ;; Other type of devices aren't implemented. #~())) (let ((devices (map crypto-device->cryptomount store-crypto-devices)) - (modules #~(format port "insmod luks~%insmod luks2~%"))) + (modules #~(format port "insmod luks~%insmod luks2~%insmod lvm~%"))) (if (null? devices) devices (cons modules devices base-commit: 580d77d0fb12448ef1621699cc0c56e787e2aadb -- 2.45.2
bug#69891: QEMU image downloaded from website fails to reconfigure with current config
I also hit this same issue with the QEMU image and have made some progress: - Folks in IRC logs had mentioned that Shepherd added support for the "service" interface in 0.10 ( https://logs.guix.gnu.org/guix/2024-03-12.log#133456). I took a stab that maybe there was a 0.9 compatibility layer that was removed at some point between the release of 0.10 and the current day, so I did a `guix time-machine --commit=72a0d835 -- pull` and reconfigure. That did appear to get around the "service" interface Shepherd error that OP mentioned in their report. - For the magic number disk issue, it appears that the bootloader is mistakenly (???) configured to boot from /dev/vda1 with the grub-bootloader. When I changed it to /dev/vda2 (the root partition of the QEMU image) it booted successfully. /dev/vda1 appears to be an EFI partition, so maybe `grub-efi-bootloader` should be used instead? Hope this helps others, too! -Josh
bug#69891: QEMU image downloaded from website fails to reconfigure with current config
A couple of clarifications on the last update, sent it a bit quickly before
turning in for the night ^^;
The time-machine commit I arbitrarily chose as the Shepherd 0.10.2 release
commit:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=72a0d8350a5edfe7d9e4b9c2665069a16c1cfbfd
No idea if the issue is actually with one of the more recent Shepherd
versions or some other package, though. As I'd mentioned in the previous
comment, wondering if a more recent package is relying on the `service`
interface being defined without declaring a specific dependency on
Shepherd>0.10? Either way, running an incremental pull+reconfigure to
shortly after Shepherd 0.10's release, then a present-day pull+reconfigure
appeared to fix it.
For the bootloader issue, I copied /run/current-system/configuration.scm to
/etc/config.scm and made the following update to the `file-systems` section
before the above reconfigures:
```
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(targets '("/dev/vda"))
(terminal-outputs '(console
(file-systems (cons (file-system
(mount-point "/")
(device "/dev/vda2") ;; <- Updated from /dev/vda1
(type "ext4"))
%base-file-systems))
```
Again, I'm doubtful this is the _right_ fix, but worked for me! Happy to
have an updated Guix VM now :)
Cheers,
Josh
On Mon, Jun 3, 2024 at 12:36 AM Josh Simmons wrote:
> I also hit this same issue with the QEMU image and have made some progress:
>
> - Folks in IRC logs had mentioned that Shepherd added support for the
> "service" interface in 0.10 (
> https://logs.guix.gnu.org/guix/2024-03-12.log#133456). I took a stab that
> maybe there was a 0.9 compatibility layer that was removed at some point
> between the release of 0.10 and the current day, so I did a `guix
> time-machine --commit=72a0d835 -- pull` and reconfigure. That did appear to
> get around the "service" interface Shepherd error that OP mentioned in
> their report.
>
> - For the magic number disk issue, it appears that the bootloader is
> mistakenly (???) configured to boot from /dev/vda1 with the
> grub-bootloader. When I changed it to /dev/vda2 (the root partition of the
> QEMU image) it booted successfully. /dev/vda1 appears to be an EFI
> partition, so maybe `grub-efi-bootloader` should be used instead?
>
> Hope this helps others, too!
>
> -Josh
>
bug#71397: Issues with DJ app Mixxx
Hello, My apologies if this is not presented correctly. I ran a guix pull yesterday night (UK time) and now Mixxx is not working. I removed and reinstalled the app with no luck Adding a track to either deck locks the app. The track is not loaded either. I would ask on Mixxx's github but the current version is 2.4 while Guix only goes up to 2.3.6 happy to share any other settings or info needed --- MGD
bug#71426: Bug Report; Guix Pull
Guix System requested I send this backtrace/bug to the mailing list. Please see attached text file. guix_error_2024-06-07 Description: Binary data
bug#71444: sfeed: depends on curl, unspecified in inputs list
sfeed uses curl, but it is not in the list of inputs/dependencies in its package specification
bug#71397: Mixxx bug
I think I have found the cause of the problem but no solution yet. When creating a custom configuration (like a custom skin or keymap) you need to create a ~/.mixxx folder. When the program loads, it reads this directory and dumps files there like logs for example. Clearing this directory make the program usable again. I think this shows that the problem may not be Guix related after all MGD
bug#71458: wireplumber service fails to start in home-pipewire-service-type
Immediately after logging into an account with home-pipewire-service-type in the home environment, about 5 error messages appear about the wireplumber service failing and restarting. Eventually herd gives up trying to start wireplumber. Trying to start it manually using `herd start wireplumber` results in the message: herd: error: failed to start service wireplumber The other pipewire-related services appear to have started successfully. home-dbus-service-type is in the home environment also.
bug#71238: Installer image consistently fails to run system init due to TLS error
Hi all, On 29/05/2024 01:44, Richard Sent wrote: Richard Sent writes: > 1. There was a transient network issue for ~3 hours when I attempted to > install Guix ~4 times using different installation media that caused a > specific TLS handshake to fail. > > 2. A specific TLS handshake Guix undertakes during the installation > process fails to pass one of the built-in firewall rules shipped with > opnsense. > > 3. Some other odd aspect of my network messes things up for a specific > TLS handshake. > > My money is on 2 given how this is a seemingly common issue on > enterprise networks [1] and the rules I have added seem irrelevant. (I'd > rather not talk openly about my firewall rules in an archived public > forum, but can discuss off-list). However, there is another comment in > that thread that says IT didn't notice any firewall blocking. I ran the 1.4.0 installer again today behind my opnsense router and it completed successfully, which is horrifying. I was hoping starting from a constant image would make the error reproducible but that doesn't seem to be the case. Even with a consistent system image and network, it's only reproducible for somewhere between a few hours and one day. Perhaps server load plays a part? (Technically my process was a little bit different. Instead of fully completing the graphical installer I swapped to a TTY after activating the wired connection, mounted the root fs, and run $ guix system build /mnt/etc/config.scm, where config.scm was unmodified since initial installation. I'd be stunned if this caused the change in behavior but figured I'd mention for completeness.) I've mananged to reproduce this bug. First, I run `sudo guix gc delete-generations && guix gc -d 2w` to clear my store. Then I run `guix upgrade && sudo guix system -L /home/ada/dotfiles/guix/ reconfigure --fallback /home/ada/dotfiles/guix/ada/system/kissakoira.scm` to redownload all of those deleted store items. The process 9/10 will fail halfway through the upgrade process. Then, a retry will work without a hitch. Even re-gc-ing my system will not let me reproduce the bug - I need to restart my system. Then, the likelyhood it works is 7/10 until the next day (just my perception). By the way, this is on my university's network. I managed to capture the problem happening under strace using this command `strace -ff -tt -o log_up.strace -s 500 guix upgrade && sudo strace -ff -tt -o log_sr.strace -s 500 sudo guix system -L /home/ada/dotfiles/guix/ reconfigure --fallback /home/ada/dotfiles/guix/ada/system/kissakoira.scm`. I've uploaded the logs to my Google Drive[1]. You can use `strace-log-merge log_up.strace` to view to merged logs. As I can reproduce this error fairly consistently now, please let me know if you want me to run any more tools to capture more data. Warmly, Ada [1] https://drive.google.com/file/d/104DVqyMLGRi4imWzvFQ6TahAiRRKdR4_/view?usp=drive_link
