IRC channel logs


back to list of logs

<the_tubular>I have some batch script I'd like to adapt for guix, but I have no idea on where to start
<the_tubular>Should I put them into an alias ?
<the_tubular>bash *
<nckx>vivien: Megalol.
<nckx>ryblade: Does this mean that 'guix install irssi' doesn't work?
<nckx>There's also wgetpaste that might come in handy to share logs.
<luke-jr>btw 6113e0529d61df7... fails to unpack binutils because the guile xz doesn't like the data (normal xz works fine)
<nckx>Ooh, fun. /me » zzz
<apteryx>are procedures used to return a package (e.g.: (cross-gcc "x86_64-linux-gnu")) in inputs called during modules loading?
<apteryx>in other words, can they cause circular module dependency problems?
<lagash>I also cannot access, but no HTTP error, it just never loads.
<bumble>lagash: me too
<bumble>I wish there were a way to "bump" issues or in some way bring attention to certain issues that seem to be falling through the cracks
<bumble> <-- this issue is important to any CJK user (Chinese Japanese Korean)
<bumble>every few days I link to the ticket here but no one facilitates it
<bumble>guix pull and guix reconfigure commands have been extremely annoying for CJK users for the past two or three months since the progress messages became localized
<bumble>actually, I should specify that the link goes to a patch, not simply an issue
<bumble>there is a solution to the problem at that link
<apteryx>seems like Mumi needs a restart
<apteryx>seems a new version of Mumi is broken
<apteryx>I've restarted the service, it's up and running for now
<apteryx>bumble: it was reviewed 36 hours ago, a rev 2 posted 32 years ago
<apteryx>it'll probably be merged soon
<bumble>apteryx: thank you that is great news
<apteryx>32 hours ago*
<apteryx>lagash: I've restarted the service
<apteryx>(and opened an issue for the crash)
<apteryx>ACTION had to turn all the cross toolchains into procedures
<apteryx>to avoid the dreaded circular module dependency issues
<luke-jr>python automagically links to the system (not guix) libbz2 and liblzma, if chroot is disabled :/
<apteryx>sounds like a bug; probably it looks uder /usr/lib location that should be patched out in the source
<whereiseveryone>sneek: botsnack
<apteryx>has anyone tried 'mumi send' to create a multi-commit series on debbugs?
<lechner>not yet
<apteryx>ACTION tries it
<lechner>Hi, is qemu building on the substitute servers, please?
<apteryx>guix weather qemu
<apteryx>as answered on the mailing list :-)
<lechner>even if I run a custom version of Guix that may be looking for a different hash?
<lechner>i cannot locally build the version you updated recently, my eudev is different
<apteryx>if your derivations are different, then it won't help you
<apteryx>what is the failure?
<lechner>qcow2 test
<apteryx>it's been built successfully by the two servers
<lechner>ok, thanks
<apteryx>it could be load related or simply flaky
<apteryx>check upstream qemu bug reports to see if it was flagged already, if yes, we could simply disable it
<apteryx>if not and you reproduce, I'd report it
<apteryx>I'm not sure if it would work without passing multiple patches to mumi
<apteryx>(e.g. letting git send-email do format of patches by passing it a range)
<lechner>apteryx / thanks!
<janneke>vagrantc: loved your fossy talk!
<efraim>I downloaded it for later
<civodul>Hello Guix!
<bonz060>o/ o/ user_oreloznog
<user_oreloznog>Hi bonz060 o/
<Altadil>Hi, if a patch series was started by others and left unfinished, is it correct to send further patches to it on debbugs ? Or should I rather send them as a new series ?
<bonz060>Altadil: I think you should send a new series, close the original patch series and ping the relevant team. I'm green here so I'm curious to see what others here say.
<civodul>Altadil: picking up a patch series is definitely welcome; i wouldn’t necessarily open a new one, either way is fine
<civodul>you can keep the original author(s) in the loop so they can chime in
<Altadil>civodul: bonz060: Thanks!
<Guest86>Hi. I used guix a few years ago. I wanted to get back to it. I use fedora 37 and NSS has been removed from glibc in it. It seems to be required for installing guix.
<Guest86>Any way for me to use guix properly in fedora?
<janneke>Guest86: there has been a debian package to install guix for several years now, possibly meanwhile there's also a package in fedora by now?
<apteryx>ACTION discovers bug-reference-mode in Emacs, which highlights Guix bugs (or any Debbugs issue) marked with e.g. bug#65860
<apteryx>super useful to quickly navigate to the issue within Emacs
<civodul>apteryx: yep, it’s pretty cool
<apteryx>why don't we use it already? :-)
<civodul>now i realize i should enable it in ERC buffers
<civodul>i think we kinda do?
<civodul>in .dir-locals.el
<civodul>but the URL needs an update
<apteryx>ah! we should add mumi there yes
<apteryx>we can support both, maybe?
<apteryx>ACTION enables it in their ~/.gnus.el
<apteryx>ACTION then reads "For almost all of those modes, it’s enough to simply enable bug-reference-mode"
<civodul>then there’s ‘debbugs-browse-gnu-url-regexp’ too, to open use ‘debbugs.el’ when browsing an issue
<apteryx>for Gnus: (add-hook 'gnus-mode-hook #'bug-reference-mode)
<apteryx>for ERC: (add-hook 'erc-mode-hook #'bug-reference-mode)
<apteryx>perhaps to be documented in our "The Perfect Setup" section
<apteryx>I've put that in my ~/.emacs:
<apteryx>after having read: info '(emacs) Bug Reference'
<civodul>you also need something like (setq-local bug-reference-url-format "")
<apteryx>bug-reference-url-format can be a function, so we can support multiple URL, I think
<civodul>hmm #65860
<civodul>ACTION fiddles with ‘bug-reference-bug-regexp’
<civodul>how ’bout bug #65860
<civodul>apteryx: thanks for bringing it up :-)
<civodul>(the patch set above looks neat, too!)
<apteryx>my pleasure!
<lrustand>Hi, I have succesfully packaged a kernel module as a Guix package and installed it, but I'm having trouble modprobing it. I can find the module in /gnu/store, but it is not showing up anywhere recognized by modprobe
<lrustand>And apparently modprobe can not take a path as argument, and the /run/current-system which is where modprobe is looking is a read-only filesystem so I'm not able to put the module there
<apteryx>lrustand: you need to add it declaratively to your system, in the 'kernel-loadable-modules' field
<apteryx>(and reconfigure your system and reboot (?)e)
<apteryx>reboot may not be needed, I've never tried
<lrustand>apteryx: Yes, I wanted to do that, but it does not recognize my homemade package
<lrustand>How can I make my homemade package be recognized from my config file?
<apteryx>it should just work; something must be wrong with it?
<lrustand>To clarify, I made a package.scm containing my package definition, then installed it using "guix package --install-from-file package.scm"
<apteryx>the best would be to add it to the Guix tree where it should live, and use that tree to reconfigure your system from to test
<apteryx>the next best thing would be in a standalone guile module and adding that module to the Guile load path while reconfiguring your system, e.g.: 'guix system reconfigure -L path/to-your/modules' your-config.scm
<apteryx>s/tree/git checkout/
<Guest86>Oh. nice. Is there any where I can read up on this?
<Guest86>Since I am new to both guile and guix, any blog would be very helpful
<cbaines>wow, I think a full GC might have completed on bayfront...
<jpoiret>lrustand: you can totally add your package definition to your config.scm
<jpoiret>that's what I do for one off things, before contributing them to guix upstream
<jpoiret>then you can refer to it in your config
<jpoiret>that's the magic of using Guile for your configuration :)
<lrustand>I tried your second approach, but jpoiret: I tried that but it didn't work for some reason
<jpoiret>how did it not work?
<lrustand>Ignore the first part of that message, it was a previous message I started writing
<lrustand>Don't remember, can try again
<jpoiret>there's no reason it wouldn't work except for some missing imports and whatnot
<lrustand>jpoiret: seems to actually work this time
<apteryx>cbaines unless you have a good reason not too, you may want to more agressively run 'guix gc', like we do on berlin
<apteryx>to avoid this kind of "downtime"
<apteryx>it's run daily there
<cbaines>apteryx, yeah, I've changed the configuration to try to free more space, but I'll probably change it to do weekly full GC's
<lrustand>Does guix gc handle old vm, image, and container files?
<apteryx>everything that's in your store and doesn't have a GC 'root'
<apteryx>with roots being files under /var/guix/gcroots
<apteryx>(they are symbolic links)
<lrustand>What if I generate an image for a vm and pass "-r somefile" to make a gc root, then this image will not be GC'ed? Can I keep overwriting that same image file when regenerating or do I need to do something with the old file first?
<lrustand>And is this the correct way to do it? Say I have a VM that I want to always have available, but I might change the config and regenerate it. Then I make a gc root and keep generating new images passing the same gc root? And refer to the gc root location from qemu/libvirt?
<graywolf>There is a copy&paste bug at, "How to make advanced packages" is supposed to be session 4, not 1.
<graywolf>Just fyi
<jackhill>lrustand: what you propose (passing the same -r root location to guixcommand and libvirt) sounds like the right thing. If you need any data to stick around between VM reconfigurations, you'll need to arrange that separtately
<civodul>graywolf: oops, will fix, thanks!
<mirai>apteryx: what's the trick to determine which imports go unused?
<apteryx>guild compile -W3 your-file.scm
<apteryx>I used a Guile built from main
<apteryx>civodul: we have modules loaded at a recursive depth > 180 in Guix ^^'
<civodul>interesting :-)
<civodul>i can’t say i’m surprised because well, there’s a lot of them
<civodul>but it’s good to have concrete data on that!
<mirai>apteryx: is that what's making guix slow/resource hog?
<apteryx>in what context/usages are you refering to?
<mirai>guix pull
<apteryx>the most resource hog thing Guix does is build itself with 'guix pull'
<mirai>(not aware of others)
<mirai>unrelated, what's the criteria for using define-deprecated/public-alias for packages
<mirai>I'm planning on removing transfig and adding fig2dev (upstream renamed this since 2016)
<mirai>but save for one package that has a native-input on it (unnecessarily), nothing else uses transfig
<apteryx>mirai: I'd expect long modules to load slowly and short ones to load fast, so unless the module dependencies can be reduced I don't see how we could do speed things up in that regard
<apteryx>other than optimize Guile
<apteryx>does Guix set TMPDIR to something like /tmp/guix-build-$package-name-version.drv-0 in the build environment?
<apteryx>that's a bit long, sometimes causing the 109 characters limit on a socket path (Linux) to be hit
<apteryx>could it simply be '/tmp' in the build container?
<apteryx>nix daemon says it's for determinism. '/tmp' is determinist, me thinks
<apteryx>ah, but guix-daemon supports '--disable-chroot', hm.
<apteryx>mirai: what was the page for the 'client' control "server" of debbugs?
<mirai> <>
<apteryx>OK, the "request" server. I see, thanks.
<nckx>mirai: I'd say that depends on: why use d-d/p-a at all?
<nckx>I think I wouldn't, since the name fields will change too.
<lrustand>Trying to follow the docs for how to contribute packages, but hitting this error: "./pre-inst-env: line 55: exec: guix: cannot execute: Is a directory"
<lrustand>I did just as described in 22.2. First I cloned guix, then started a guix development shell, ran ./bootstrap and ./configure, and then I try to build my package like "./pre-inst-env guix build package-
<roptat>hi guix!
<efraim>lrustand: you'll want to run 'make' also inside that environment
<efraim>and make sure you used the correct flags with ./configure
<lrustand>efraim: okay, then that is missing from the docs
<lrustand>Also, the docs didn't mention any flags for ./configure
<graywolf>lrustand: It is not. It tells you to invoke guix shell and the run the commands (./bootstrap and others)
<lrustand>graywolf: I am looking directly at the docs as we speak. ./bootstrap and ./configure is mentioned, but make is not
<graywolf>22.1 section of the info manual gives './configure --localstatedir=/var --sysconfdir=/etc '
<vivien>What does the "Block" column mean in the QA output for a patch?
<graywolf>"Finally, you can build Guix and, if you feel so inclined"
<graywolf>Under there is make and make check no?
<vivien>"Blocked" sorry
<efraim>22.1 specifies running make and specifies configure flags, 22.2 assumes you've read 22.1 and remember everything from there
<lrustand>graywolf: Okay, I just wanted to make a package so I went to 22.4, which points to 22.2. Nowhere is make mentioned here or pointed to 22.1
<graywolf>Oh, I see. I read the 22 from the start, so I did not encounter that problem.
<efraim>perhaps something like: "the @code{./pre-inst-env script lives in the top build tree of Guix; it is generated while [building from guix](previous section)"
<lrustand>efraim: that would be nice
<cbaines>vivien, it's a count of builds that are blocked, that is there's some input that is blocked or has failed to be built
<vivien>cbaines, in my case, the build is marked "scheduled" (the link on says "state: pending") so I guess an input is failing. Does it tell me which dependency is failing?
<vivien>The patch number is
<vivien>Oh I did not read your explanation correctly
<vivien>So the problem is necessarily with an input, whether the input was itself blocked or the input itself failed to build
<lechner>Hi everyone, thanks for working on Guix!
<vivien>Anyway, thanks, I’ll wait and see
<vivien>Ah found it!
<vivien>The inputs failed on bordeaux
<vivien>In procedure mkdir: No space left on device
<vivien>I predict a quick acceleration of all CI jobs in the near future, if everything fails in the unpack phase
<Noisytoot>go-github-com-charmbracelet-glamour is currently failing to build because of failed tests. How can I add it as an input to a package with tests disabled?
<apteryx>lechner: o/
<oplitadinettuno>can I force the guix generated grub menu entry to use a filesystem label instead of an UUID as a root= kernel argument in Guix System?
<lrustand>I've submitted my first package to the ML
<lrustand>ACTION Crossing his fingers
<lrustand>ACTION is crossing his fingers
<vivien>lrustand, congratulations!
<minima>does `(file-append "bash-minimal" "/bin/ls")' return a guile record? how do i get `ls' path as a string?
<minima>i'm talking in the context of a config file that i'd use with `guix home reconfigure file.scm'
<vivien>The first argument to file-append must be a package, not a package name
<vivien>It returns a file-like object
<vivien>You would use it in a gexp
<minima>ooops sorry, yeah, i meant bash-minimal as opposed to the string
<vivien>And the package must be coreutils, not bash
<minima>sorry again :)
<minima>vivien: but i also see it use it here
<minima>2nd code block
<vivien>When in a gexp you do #$(file-append coreutils "/bin/ls"), it will write "/gnu/store/xxx-coreutils/bin/ls" as a string literal in the gexp
<minima>yeah, i've used it in some simple gexp before
<minima>but it's the way it's used at the link above that puzzles me a bit
<vivien>Maybe the home-environment-variables-service-type accepts file-likes as environment variable values
<vivien>As well as strings
<minima>that explains it
<minima>thanks vivien
<vivien>Looking at environment-variables->setup-environment-script in gnu/home/services.scm, line 304, it seems like the values end up in an ungexp form, so file-likes are built and their names are passed to the gexp to form the setup script
<vivien>You still end up calling file-append in an ungexp form, like the other gexp cases
<vivien>like the other examples of file-append rather
<vivien>This function is brillant, but it is mixing quasiquote/unquote and gexp/ungexp
<vivien>I would not dare do that
<cbaines>vivien, if you click through to the build page on the data service, you can see the blocking build
<cbaines>in this case, it looks like one of the build machines ran out of disk space, and caused the build to spuriously fail
<cbaines>I've submitted a new build for that derivation
<vivien>Thank you :)
<cbaines>ah, and I see you figured it out as well :)
<mirai>anyone here that uses emacs to give feedback/reply to the emails in the MLs, can you explain what/how to do so or how to get started?
<Noisytoot>Apparently Go module names are case-sensitive but the Guix Go importer will still generate (broken) packages if you give it the import path with the wrong case (and it lowercases package names)
<mitchell>hello guix. I am trying to run an Appimage inside a guix container emulating the FHS. The application in question wants a symbolic link from /proc/self/mounts -> /etc/mtab. Does anyone have any ideas on how I could go about creating this link? I enter the container as my own user so I don't have permissions to create this link manually
<ieugen>hello, I am trying to add a guix.scm definition to a guile project. how can I add library that contains (gnu packages) ?
<mitchell>ieugen: what do you mean?
<ieugen>@mitchell: I am trying to hack on .
<ieugen>I would like to run `guix shell` inside and have all dependencies
<ieugen>I am running guix on foreign distro (Debian)
<ieugen>I run the guix shell and I try to start ./ . I get "no code for module (gnu packages)"
<Noisytoot>guix import go generates broken texinfo (@ is escaped and needs to be manually unescaped)
<mitchell>How are you running guix shell? I don't see a guix.scm in this project. Are you using the manifest.scm? Your manifest does not include Guile which is what sets up the environment variables
<Noisytoot>It also generates the old (propagated-inputs `(("something" ,something))) rather than (propagated-inputs (list something))
<ieugen>@mitchell: I am creating the guix.scm from scratch
<mitchell>If you are calling `guix shell -m manifest.scm` you need to add guile to that list, other wise your GUILE_LOAD_PATH and friends won't be set and you won't find any packages
<ieugen>it dons not have a manifest.scm . how do I build one ?
<mitchell> is this not the repository in question?
<ieugen>thanks, I will check it out
<ieugen>what is the relation between guix.scm and manifest.scm ? any articles / docs ?
<ieugen>(I am new to this) :)
<mitchell>For the curious I solved my problem. I solution was to share /etc/mtab from the host system. The symlink will be correct in the container
<mitchell>guix.scm describes a package, including its dependencies. The manifest.scm describes an arbitrary list of packages. A guix.scm is more useful for package development because you can run `guix shell -D -f guix.scm` (or just `guix shell` if you set it up right) and it will bring in what you need to build/run it, even the implicit dependencies like gcc and
<mitchell>make. read this for a more interesting and detailed explaination
<ieugen>reading right now
<jpoiret>guix.scm and manifest.scm are just naming conventions, you can use any name you want
<crzjp>hey folks, what about emacs 29.1?
<jpoiret>crzjp: coming soon™
<crzjp>jpoiret: lol, thanks
<mono_>Hi, I'm using the alsa and pulseaudio service in my configuration, but I don't see any of those services listed
<mono_>and sound doesn't works
<jpoiret> crzjp
<mono_>I don't know how to troubleshoot that problem, any ideas?
<jpoiret>hmm, looks like QA hasn't processed the request to merge
<lilyp>others are free to contribute as well
<crzjp>thank all
<jpoiret>mono_: wdym you don't see them listed?
<mono_>when I run herd to see the list of services, I don't see anything related to audio
<lilyp>jpoiret is there a ritual to get QA started?
<jpoiret>yes, that's because they're not *shepherd* services
<mirai>mono_: they're not herd services
<jpoiret>lilyp: I don't know exactly, never used the branch merging systme
<mono_>Hmm... interesting, how can I see if those are running?
<mirai>the service generates configure files for them instead
<jpoiret>chris wrote a mail about it some time ago
<mono_>yeah, saw that about the config files in the docs
<jpoiret>mono_: alsa is part of Linux itself, and pulseaudio starts by itself because Why Not™
<mirai>pulseaudio generally starts automatically when some app runs something that uses it afaik
<jpoiret>it's not even managed by dbus
<mirai>jpoiret: I think it can be managed
<jpoiret>starting even just a sound mixer like pavucontrol is enough to bring it up
<jpoiret>mirai: by dbus?
<mirai>but that presumes shepherd would start it first
<jpoiret>it needs to be a user app, like pipewire
<mono_>weird, I'm not getting audio output on any application
<jpoiret>does pavucontrol work? mono_
<mirai>idk about dbus but if you have it started by shepherd in theory it should work
<alethkit>are there unofficial guidelines for packaging go modules? I know go-build-system only supports packages, but the build errors are completely nondescriptive
<mirai>though doing that in the operating-system would almost mean a systemwide pulse instance which is a bad idea ™
<jpoiret>yes, i think we used to do that somehow?
<lilyp>i mean, we could do user-managed pulseaudio via user shepherd, but that still requires us to write dbus code
<jpoiret>and that's not really supported for pipewire hence why i gave up
<oplitadinettuno>good evening guixers, how can one force grub to look for the guix system by filesystem label istead of UUID in its meu entry?
<mirai>I think fedora/systemd has it managed on a per user level
<jpoiret>systemd has dbus management baked in right?
<jpoiret>but once again iirc pulseaudio doesn't use dbus
<jpoiret>might be wrong on this
<lilyp>note that we have a working dbus too with guile-ac-d-bus
<jpoiret>it has its own magic "I'll just spawn myself then" machinery
<mono_>yeah, it seems that running pavucontrol makes sound work
<mono_>so should I start it on login to have audio on future sessions?
<mono_>or is there another workaround?
<mono_>as long as it works I'm happy, just want to see if someone else could overcome that issue
<apteryx>which application doesn't work without this workaround?
<apteryx>pulseaudio on Guix System is configure to autospawn itself
<apteryx>but this can be disabled per application
<apteryx>mono_: ^
<graywolf>Just to make sure, guix pull -C=channels.scm --profile=/tmp/foobar does the pull in completely isolated manner, so even if the channels are rubbish for some reason, my guix-home profile will not be affected. Is that correct?
<graywolf>As for the clean up, deleting /tmp/foobar will suffice or are there more steps?
<graywolf>And final question, can I assume that %default-channels will always have just one entry?
<Noisytoot>I found a non-free package in Guix: alex4's license only applies to the code, other data has no license. Source:,
<Noisytoot>It should be removed (or the data replaced with something free if there is a free replacement)