IRC channel logs
2023-09-11.log
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 <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) <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 issues.guix.gnu.org, but no HTTP error, it just never loads. <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>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 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 <bumble>apteryx: thank you that is great news <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 <apteryx>has anyone tried 'mumi send' to create a multi-commit series on debbugs? <lechner>Hi, is qemu building on the substitute servers, please? <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>it's been built successfully by the two servers <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) <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 <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>now i realize i should enable it in ERC buffers <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>after having read: info '(emacs) Bug Reference' <apteryx>bug-reference-url-format can be a function, so we can support multiple URL, I think <civodul>ACTION fiddles with ‘bug-reference-bug-regexp’ <civodul>apteryx: thanks for bringing it up :-) <civodul>(the patch set above looks neat, too!) <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 <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 <lrustand>Ignore the first part of that message, it was a previous message I started writing <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 <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 <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? <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 <mirai>apteryx: what's the trick to determine which imports go unused? <apteryx>civodul: we have modules loaded at a recursive depth > 180 in Guix ^^' <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? <apteryx>the most resource hog thing Guix does is build itself with 'guix pull' <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>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? <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- <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" <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)" <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 bordeaux.guix.gnu.org says "state: pending") so I guess an input is failing. Does it tell me which dependency is failing? <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>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? <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 <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 <minima>ooops sorry, yeah, i meant bash-minimal as opposed to the string <vivien>And the package must be coreutils, not bash <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>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 <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 <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) ? <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 ./toys.sh . 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 ? <ieugen>what is the relation between guix.scm and manifest.scm ? any articles / docs ? <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 <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? <mono_>Hi, I'm using the alsa and pulseaudio service in my configuration, but I don't see any of those services listed <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 <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 <mirai>jpoiret: I think it can be managed <jpoiret>starting even just a sound mixer like pavucontrol is enough to bring it up <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 <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 <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 <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>It should be removed (or the data replaced with something free if there is a free replacement)