bug#72797: qt-tools is unnecessary optional dependency for monero
tag 72797 + notabug quit Hi Guillaume, Guillaume Le Vaillant writes: > Here's a corrected definition: > > (define-public monero-without-translations > (package > (inherit monero) > (name "monero-without-translations") > (native-inputs (modify-inputs (package-native-inputs monero) > (delete "qttools") > Thanks for providing the above tip for users who'd like rewrite the dependencies of monero. Guix will continue shipping translations in its stock package, so you should use the above. qt-tools is also a native dependency, so shouldn't end up in the closure of the built package. -- Thanks, Maxim
bug#73249: Recovering journal at boot time after reconfiguring the system with Sway
Hi! I'm running Guix with Sway (v1.9) and ext4. When guix system reconfigure is performed, a filesystem check is triggered on next boot, showing the message: "Recovering journal" and then "clean...". After this, the system boots just fine. I reboot/poweroff with loginctl reboot/poweroff (elogind). Another user in the help-guix mailing list confirmed the same behavior https://lists.gnu.org/archive/html/help-guix/2024-09/msg00042.html This issue does not occur with Gnome. The smartctl test on my device passes. Thanks in advance!
bug#72794: Bad kernel config
Hi,
Jorge Acereda writes:
> Hi,
>
> I noticed this looking at the linux.scm file:
>
> ,@(if (version>=? version "5.13")
> '(("BPF_UNPRIV_DEFAULT_OFF" . #t))
> '())
>
>
> Shouldn't that be "CONFIG_BPF_UNPRIV_DEFAULT_OFF" instead?
Indeed! Thanks for spotting that. It's now fixed, with commit
74c96e87a5.
--
Thanks,
Maxim
bug#72686: Impossible to remove all offload machines
Hi Ian, Ian Eure writes: > Ran into this issue last week. If you: > > - Configure some offload build machines in your operating-system > configuration. > - Reconfigure your system. > - Remove all offload build machines. > - Reconfigure your system again. > > ...then various guix operations will still try to connect to offload > machines, even if you reboot the affected client. > > This is caused by a bug in the `guix-activation' procedure: > > ;; ... and /etc/guix/machines.scm. > #$(if (null? (guix-configuration-build-machines config)) > #~#f > (guix-machines-files-installation > #~(list #$@(guix-configuration-build-machines > config > > If there are no build machines defined in the configuration, no > operation is performed (#f is returned), which leaves the previous > generation’s /etc/guix/machines.scm in place. > > The same issue appears to affect channels: > > ;; ... and /etc/guix/channels.scm... > #$(and channels (install-channels-file channels)) Interesting! > I’d be happy to take a stab at fixing this, but I’m not certain what > direction to go, or how much to refactor to get there. Should the > channels/machines files be removed (ignoring errors if they don’t > exist)? Should empty files be installed? Should that happen inline > in `guix-activation', or in another procedure? Should the filenames be > extracted to %variables to avoid duplicating between the two places > they’ll be used? > > If someone would like to provide answered, I would contribute a patch. I guess the simplest would be to attempt to remove the files when there are no offload machines or channels, in this already existing activation procedure. Extracting the file names to %variables sounds preferable yes, if there's a logical place to store them that is easily shared. A patch would be dandy! -- Thanks, Maxim
bug#72333: Magit/Transient error message
>From Liliana dmarie Prikler: > It is a bug unique to our handling in Guix – upstream uses hashes to > guard against it, but those break grafts. Do we need to remove the whole hash? The path hash would definitely break grafts, but why should the content hash break grafts? Having the content hash would also solve this issue. Here is the upstream explanation for the hash https://git.savannah.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4433 having two parts, path and content hash. Regards, Rutherther
bug#72333: Magit/Transient error message
Am Samstag, dem 14.09.2024 um 17:53 + schrieb Rutherther: > > From Liliana dmarie Prikler: > > It is a bug unique to our handling in Guix – upstream uses hashes > > to guard against it, but those break grafts. > > Do we need to remove the whole hash? The path hash would definitely > break grafts, but why should the content hash break grafts? Having > the content hash would also solve this issue. > > Here is the upstream explanation for the hash > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4433 > having two parts, path and content hash. Because the content hash also refers to stuff that we're grafting, e.g. program names that get compiled to store paths. It's sadly not that easy. Cheers
bug#73259: Manual page database generation broken
Man page database generation has been broken since the ‘core-updates’ merge it would seem: --8<---cut here---start->8--- Creating manual page database... [ 1/1422] building list of man-db entries... [...] [ 65/1422] building list of man-db entries...In thread: In procedure open-file: Too many open files: "/gnu/store/85hmpisfjayarpnzbw0ma4l02nncms5q-libxtst-1.2.3/share/man/man3/XTestCompareCurrentCursorWithWindow.3.zst" In thread: In procedure open-file: Too many open files: "/gnu/store/wxwv020jwxq9gr070vwy3fh8n028gwqg-libxau-1.0.10/share/man/man3/XauDisposeAuth.3.zst" In thread: In procedure open-file: Too many open files: "/gnu/store/wxwv020jwxq9gr070vwy3fh8n028gwqg-libxau-1.0.10/share/man/man3/XauDisposeAuth.3.zst" In thread: In procedure open-file: Too many open files: "/gnu/store/wxwv020jwxq9gr070vwy3fh8n028gwqg-libxau-1.0.10/share/man/man3/XauDisposeAuth.3.zst" 349 entries processed in 0.6 s --8<---cut here---end--->8--- Maybe something with commit 822455580273ea8b3c1059922e2b41a395103164? Ludo’.
bug#72686: Impossible to remove all offload machines
Hi Maxim, Maxim Cournoyer writes: Hi Ian, Ian Eure writes: Ran into this issue last week. If you: - Configure some offload build machines in your operating-system configuration. - Reconfigure your system. - Remove all offload build machines. - Reconfigure your system again. ...then various guix operations will still try to connect to offload machines, even if you reboot the affected client. This is caused by a bug in the `guix-activation' procedure: ;; ... and /etc/guix/machines.scm. #$(if (null? (guix-configuration-build-machines config)) #~#f (guix-machines-files-installation #~(list #$@(guix-configuration-build-machines config If there are no build machines defined in the configuration, no operation is performed (#f is returned), which leaves the previous generation’s /etc/guix/machines.scm in place. The same issue appears to affect channels: ;; ... and /etc/guix/channels.scm... #$(and channels (install-channels-file channels)) Interesting! I’d be happy to take a stab at fixing this, but I’m not certain what direction to go, or how much to refactor to get there. Should the channels/machines files be removed (ignoring errors if they don’t exist)? Should empty files be installed? Should that happen inline in `guix-activation', or in another procedure? Should the filenames be extracted to %variables to avoid duplicating between the two places they’ll be used? If someone would like to provide answered, I would contribute a patch. I guess the simplest would be to attempt to remove the files when there are no offload machines or channels, in this already existing activation procedure. Extracting the file names to %variables sounds preferable yes, if there's a logical place to store them that is easily shared. As I was putting together a patch for this, I realized there’s a problem: if a user is *manually* managing either /etc/guix/machines.scm or channels.scm, these files would be deleted, which likely isn’t what they want. The current code lets users choose to manage these files manually or declaritively, and there’s no way to know if the files on disk are the result of a previous system generation or a user’s creation. Since the channel management is a relatively new feature, I suspect there are quite a few folks with manually-managed channels that this would negatively impact. I know there was some disruption just moving to declaritive management of channels (but I can’t find the thread/s at the moment). I don’t see an elegant technical solution to this. I think the best option is probably to say that those files should *always* be managed through operating-system, and put a fat warning in the channel news to update your config if they’re still handled manually. The only other option I can see would be to keep the existing filenames for user configuration, and declaritively manage different files -- like declaritive-channels.scm. This comes with its own set of problems, like needing to update the Guix daemon to read and combine multiple files; and the inability to know whether a given `channels.scm' is declaritively- or manually-managed means a bumpy upgrade path (ex. should this preexisting channels.scm file be left as-is, or renamed to the new name?) I’m inclined to go with the fat-warning option, but am also thinking this likely needs some guix-devel discussion. What do you think? Thanks, — Ian
bug#72686: Impossible to remove all offload machines
Hi Maxim, Ian Eure writes: Hi Maxim, Maxim Cournoyer writes: Hi Ian, Ian Eure writes: Ran into this issue last week. If you: - Configure some offload build machines in your operating-system configuration. - Reconfigure your system. - Remove all offload build machines. - Reconfigure your system again. ...then various guix operations will still try to connect to offload machines, even if you reboot the affected client. This is caused by a bug in the `guix-activation' procedure: ;; ... and /etc/guix/machines.scm. #$(if (null? (guix-configuration-build-machines config)) #~#f (guix-machines-files-installation #~(list #$@(guix-configuration-build-machines config If there are no build machines defined in the configuration, no operation is performed (#f is returned), which leaves the previous generation’s /etc/guix/machines.scm in place. The same issue appears to affect channels: ;; ... and /etc/guix/channels.scm... #$(and channels (install-channels-file channels)) Interesting! I’d be happy to take a stab at fixing this, but I’m not certain what direction to go, or how much to refactor to get there. Should the channels/machines files be removed (ignoring errors if they don’t exist)? Should empty files be installed? Should that happen inline in `guix-activation', or in another procedure? Should the filenames be extracted to %variables to avoid duplicating between the two places they’ll be used? If someone would like to provide answered, I would contribute a patch. I guess the simplest would be to attempt to remove the files when there are no offload machines or channels, in this already existing activation procedure. Extracting the file names to %variables sounds preferable yes, if there's a logical place to store them that is easily shared. As I was putting together a patch for this, I realized there’s a problem: if a user is *manually* managing either /etc/guix/machines.scm or channels.scm, these files would be deleted, which likely isn’t what they want. The current code lets users choose to manage these files manually or declaritively, and there’s no way to know if the files on disk are the result of a previous system generation or a user’s creation. Since the channel management is a relatively new feature, I suspect there are quite a few folks with manually-managed channels that this would negatively impact. I know there was some disruption just moving to declaritive management of channels (but I can’t find the thread/s at the moment). I don’t see an elegant technical solution to this. I think the best option is probably to say that those files should *always* be managed through operating-system, and put a fat warning in the channel news to update your config if they’re still handled manually. The only other option I can see would be to keep the existing filenames for user configuration, and declaritively manage different files -- like declaritive-channels.scm. This comes with its own set of problems, like needing to update the Guix daemon to read and combine multiple files; and the inability to know whether a given `channels.scm' is declaritively- or manually-managed means a bumpy upgrade path (ex. should this preexisting channels.scm file be left as-is, or renamed to the new name?) I’m inclined to go with the fat-warning option, but am also thinking this likely needs some guix-devel discussion. What do you think? Disregard this, I continued thinking after sending the email (as one does) and realized that any managed file will be a link into the store -- so if the system is reconfigured with no build-machines or channels *and* the corresponding file is a store link, it should be removed; otherwise, it should remain untouched. I can work with this. Thanks, — Ian
bug#73263: sudo 1.9.16 i586-pc-gnu build error
guix cc9094d qkni57i95kvq7a7rx505hpc7gw6j9a-sudo-1.9.16.drv.gz Description: application/gzip
