IRC channel logs

2026-09-11.log

back to list of logs

<eikcaz>Hi all. I have two PR's that I think should be merged (I've been waiting for weeks), and one that needs advice (large define-configurations cause compile to timeout). I know reviewer time is scarse, so I can't complain about that last one, but the first two are quite simple, and one of them addresses several CVEs. Is there something I could do on my end as an "untrusted" contributor?
<ryanprior>Ping the maintainers mailing list (and for the one that addresses CVEs, maybe also the security mailing list?) You can't force any given timeline but sending it to the top of inbox periodically might help.
<eikcaz>Ok, I'll do that once. Since the problem seems to stem from lack of human resources, i.e. finite human attention, emailing about it seemed selfish (I avoided even mentioning it here for weeks for that reason).
<PotentialUser-21>Hi. Download links on https://guix.gnu.org are all broken, because 'https://ftpmirror.gnu.org/gnu/' points to wrong URLs. Those seem to be blindly generated from the pattern '//<MIRROR-DECLARED_UNCHECKED_ROOT>/gnu/'. E.g. ‘https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso’ points to
<PotentialUser-21> 'https://mirrors.nju.edu.cn/gnu//gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso' that is twice wrong: note the double slash and the wrong duplication of 'gnu' in the path (real URL is 'https://mirrors.nju.edu.cn/gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso'). Same goes with
<PotentialUser-21> 'https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso.sig' that points to 'https://gnuftp.uib.no//gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso.sig': there isnot even a 'gnu' directory on this server (actual URL is 'https://gnuftp.uib.no//guix/guix-system-install-1.5.0.x86_64-linux.iso.sig').
<PotentialUser-21>... (actual URL is 'https://gnuftp.uib.no/guix/guix-system-install-1.5.0.x86_64-linux.iso.sig'').
<PotentialUser-21>Etc.
<apteryx>noe: are the tests supposed to pass in the gnome-session-shepherd repo?
<apteryx>OK, only the last one is failing now (gnome-desktop); I was not in a pure environment and I think guile 3.0.9 was being picked up, maybe
<apteryx>noe: I've documented my findings here: https://gitlab.gnome.org/noe/gnome-session-shepherd/-/work_items/3
<apteryx>why do we clear the propagated-inputs for the current-guix package?
<apteryx>that breaks using e.g. (current-guix) instead of guix in a manifest, because guix at run time will require its propagated libraries
<bavier>is a PR approval from cuirass bot good enough to push, or better to get a personal approval?
<apteryx>if it's a small thing like a simple package update, I'd say go for it
<bavier>apteryx: yes, it is. Thanks!
<ryanprior>if you want to set configure flags with the value of store paths, what's the idiom for doing that?
<bavier>ryanprior: probably using gexp
<apteryx>how would I got to replace (rewrite) a particular package in the graph of a complete operating-system?
<apteryx>go*
<apteryx>ah, options->transformations
<apteryx>options->transformation (without s)
<apteryx>from (info "(guix) Defining Package Variants")
<cnx>see also https://codeberg.org/guix/guix/pulls/7968
<apteryx>is it sugar ontop of options->transformations? or what does it enable that the former can't do?
<apteryx>does --with-source affect recursively other packages these days?
<apteryx>(does it rewrite the whole package graph?)
<apteryx>hm, having a guix.scm at the root of a repo interferes with loading ,use (guix), it seems
<apteryx>(if your project's root is on the load path)
<apteryx>my attempt doesn't seem to have any effect: https://paste.guixotic.coop/magit-diff_gnome-session-shepherd-2517-5508.html
<moksh>hello is there a package with uses (search-input-file) in #:configure-flags
<moksh>I have cmake package that have <SOME>_EXECUTABLE as a flag, which needs to point to bin output of a package input
<moksh>I know I could patch the cmakelists file but I am wondering if there is a way to do it in #:configure-flags itself
<moksh>solved it
<mfg>How exactly does native-search-paths work? When exactly is it being set? I added it to one package, but including that poackage in a guix shell seems to not set it. Any ideas, where to look?
<mfg>I suppose this may happen when guix does not find any files in the list I specified, right? ... Ah, just writing this answers my question! I forgot to _install_ the relevant path, it is just built. Thanks :D
<untrusem>mfg: there should be info in the manual
<untrusem>you use emacs?
<untrusem>if yes, "C-h r -> guix" will take you to manual and then you just do isearch
<PotentialUser-83>hey everyone; I am trying to make guix, without X11 without Wayland, display tty2 after boot rather than tty1 where logs are also printed. It seems the best and cleanest way is using chvt 2 and AI produced the following script, which I'd like a human to vouch for! https://paste.debian.net/plainh/de5a0d95 IT'S VERY FEW LINES, ANYONE KEEN? (iF i
<PotentialUser-83>DISCONNECT IT'S BECAUSE i GO FOR LUNCH BUT WILL CHECK THE LOGS IMMEDIATELY AFTER LUNCH AND RECONNECT!)
<PotentialUser-83>Sorry the caps lock was unintended
<PotentialUser-83>that script seems unclean, I don't like the sleep command, I dont like the require command...
<mfg>untrusem: I do use emacs, but never got around to properly learn how to navigate info manuals with it. I usually use man pages and grep. I suppose I should learn this :)