IRC channel logs
2023-10-21.log
back to list of logs
<rekado>philip: users can specify a plugins by their absolute file names in /etc/asound.conf <rekado>I don’t know if there is a search path for that. <lechner->mirai / does the shepherd close the controlling terminal? <philip>rekado: maybe a contributing factor is that I'm on a foreign distro (Debian Bookworm). I tested via `guix shell`. <graywolf>Hi, I am writing a package that should provide a run script. The script basically consist of #$guile-3.0/bin/guile -e '(@ (foo) main)' ; However this fails to find the module unless I also explicitely install guile into the profile. What is correct approach to this problem? <sneek>Welcome back graywolf, you have 1 message! <graywolf>nckhexen: Little problem is that pack for example already has a -f flag, it just does something completely different :/ <graywolf>For my question: Is this what wrap-program and/or wrap-script is for? <graywolf>Aaand one more question: Some phases seem to explicitly place #t as last expression. Is there a reason for that? It does not seem to be done everywhere. <graywolf>ACTION just spent 30 minutes figuring out that wrap-program does not support /bin/sh as an interpreter... <zamfofex>graywolf: It used to be required (or at least there was an initial effort towards making it required) but it was decided against ultimately. <apteryx>hehe, exec sh -c 'if ! command -v guix; then . ./pre-inst-env; fi && guix repl --' --> guix repl: error: fport_write: Broken pipe <apteryx>without the quotes on $pre_inst_env_maybe <apteryx>yeah this seems to work pretty much anywhere <graywolf>apteryx: Maybe command -v guix >/dev/null || ... <nutcase>I'm (still) trying to figure out, what my %config-directory should be. Currently it is `/usr/local/etc/guix`, which is different from `/etc/guix`. Although I'm not facing any issure at the moment (anymore), I'm wondering, if this is, what my %config-directory should be. <nutcase>Maybe someone with a near fresh guix system installation (from 1.4.0 install medium) can issue `echo '(pk (@ (guix config) %config-directory))' | sudo guix repl` for me and post the output (line starting with $1) here? <nckhexen>nutcase: I'll try, but if this were a 1.4.0 bug it should not have taken this long to notice. It is *not* what it should be, Guix is usr-free. <nutcase>if there is something I could check, why I have /usr/, let me know. <nutcase>btw, I add a substitute-url and an authorized-key to my guix-configuration. <graywolf>nutcase: Any chance you compiled your own guix from the source code? <nckhexen>nutcase: Sharing can't hurt, but I'd be surprised if you did this. As for why you have /usr: Guix creates a /usr/bin/env compatibility link by default, but it doesn't ever *use* usr, and certainly not for itself. <nckhexen>The compat link is for scripts where #!/usr/bin/env is a popular 'portable' shebang. <graywolf>/usr/bin/env is reasonably portable in practice <nckhexen>Maybe I should try removing it again now that shell --fhs is a thing. <nutcase>graywolf: I did compile guix once, but did no installation of the compiled one, but ran with pre-inst-env <graywolf>I wonder it there could be an connection, the configure script by default uses /usr/local per GNU's standards <graywolf>For what it is worth, I also installed my system from 1.4.0 (yes, I am a new user :) ), and I have %config-directory in /etc/guix <nckhexen>graywolf: My hypothesis yesterday was that a foreign-distro maintainer had misbuilt their distro's guix package to use the ./configure defaults, but this was torpedoed by the fact that this is Guix System. Surely we know how to build Guix, if anything? One would hope… <nutcase>nckhexen: https://paste.debian.net/1295765/ this is my operating-system. I'm also happy about suggestions on how to improve, e.g. the `udev-rules-service 'logitech-unify`. Another issue: although, I have git:gui appended to my packages, the bin `gitk` isn't on my $PATH. <nckhexen>Grr, my installation ran out of space by 50MiB 😒 <nutcase>graywolf: thank you for the info about /etc/guix. So I guess, I should investigate further. snape mentioned yesterday that nvm may influence the location? Or did I misunderstand something? <nckhexen>nutcase: You're throwing away the output because of the way all of this is implemented (multiple return values, which can fuck with your brain if you're not used to them). When you map, you're only handling & keeping the first return value, which defaults back to the main :out-put. <nckhexen>The answer is something like (packages (map (compose list specification->package+output)) my-list-of-package+output-specs) <nckhexen>In your case the ‘(compose …)’ form would replace your ‘specification->package+output’. <nckhexen>You're definitely not doing anything that could cause Guix to be misbuilt (e.g., some weird custom guix package that yeets the 'configure phase). <nutcase>non volatile memory, /dev/nvme0n1 where my guix system is installed at. Although I think that it shouldn't be a difference, if I'm on /dev/hda /dev/sda or /dev/nvme0n1 <nckhexen>Ah, I've never heard it without the ‘express’ :) <graywolf>Should not be the cause, I am on nvme as well. <nckhexen>While NVMEs are (or were, when they were new) beyond anything that simply emulating a block device has any right to be, this would be news to me. <nutcase>ACTION unfortunately will need to leave again until tonight (CEST) <nutcase>nckhexen: regarding specification->package+output : I didn't fully understand what you suggest with the compose. What is my-list-of-package+output-specs in your example? is it my list of strings, I already have? Do I only have to add the (compose list... ? <nckhexen>nutcase: When you return, can you share the store file name of the guix that prints /usr/local? My newly-installed system has only one Guix, at /gnu/store/5kj8lyybjrdl7xd0fx9g9v…/bin/guix. It knows that /etc/guix is true. <nckhexen>nutcase: Actually, if you could test each /gnu/store/*-guix-*/bin/guix on your system in turn, I wonder what we'd learn. <phf_>Hi! Why this command: `guix shell -C bash-minimal glibc glibc-utf8-locales-2.29 -- bash -c 'export LC_ALL=en_US.UTF-8'' outputs: `warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory' ? <phf_>because it is 2.29 instead of 2.35... <phf_>I guess it would be nice if there were a package named glibc-utf8-locales compatible with glibc." <nckhexen>The problem with creating a ‘glibc-utf8-locales’ package (as I believe glibc-utf8-locales-2.29 used to be named) is that people install & otherwise use it. <nckhexen>Because hey, I want locales, I like UTF-8, obviously I should install this random package I found. <Rovanion>I think I found the source of the musescore cmake qt5 issue yesterday night. It was entirely unrelated to qt5, the cmake script just reported a non-issue. Instead it seems to have been a folder that a part of Guix's :before script removed. <phf_>nckhexen: that is perfectly accurate. <redacted>doing (use-modules (shepherd service)) inside the guix vm I'm building gives me "no code for module (fibers)" <redacted>I take that to mean something is not in the search path for that to work <redacted>I guess guile-fibers might not be installed, but that doesn't make sense to me if it's a dependency of shepherd <redacted>oh, but dependencies are inputs, so shepherd itself might have fibers bundled up with it, but *I* don't have it in my search path? <gabber>transmission-daemon refuses to take up work due to /var/lib/transmission-daemon/settings.json being read-only? am i missing something? <gabber>the web-interface complains it not being able to "connect to the server"... <gabber>meanwhile $(herd status transmission-daemon) reports everything being just fine.. am i doing it wrong or should i file a bug-report? <mirai>gabber: there's already an open report on it <mirai>I have been busy with other things in the meantime but it's on my queue <redacted>"The programming interface defined in this section may only be used within a shepherd process." <redacted>I take it I need to invoke herd from my script then. <redacted>trying to start nginx from my certbot deploy hook <mirai>redacted: I'd recommend you to just run the renew-certificates script (there's a message you get when you run a system reconfigure with details) <gabber>responsibly as i try to act i first checked issues.g.o but i don't see the issue i'm encountering? are you referring to #66290 ? <mirai>nginx complains the SSL certificates might be missing but that only happens when there's no certs <mirai>once you run renew-certificates.sh then nginx will be able to start without problems <mirai>since it will create the certificates if they don't exist (or renew them) <mirai>afterwards the mcron jobs should take care of it <redacted>mirai: I'll have to do that for now and revisit the dream of a config which Just Works(tm) later <redacted>since this is technically holding up more important work <gabber>isn't that different from my issue? the web-site is served neatly, but the functionality ain't there <gabber>in the meantime: can i still make use of the transmission-daemon somehow, e.g. through the CLI? <mirai>I was going to revisit the service definition of it <mirai>ACTION resumes the refactoring dovecot quest <gabber>ACTION figured out $(transmission-remote localhost:9091) works just fine <civodul>efraim: hey, ‘rust-team’ is at 77% right now (master is at 74%) <efraim>I'll turn on my computer and check it out <efraim>I had a power hiccup 15 minutes before shabbat and all my machines turned off <civodul>oh apologies, it’s not a good day for that <civodul>no rush, i was just checking was ci.guix had to say :-) <civodul>(turns out it’s not all that talkative) <futurile>oh gah I just worked out that I've been getting all my commit messages wrong by looking at efraim's commits on the rust-team branch <efraim>Oh no it's trying to tab complete on /gnu/store <efraim>I turned it off and on to try again. My store is 500 gb after btrfs compression and deduplication <futurile>ACTION starts writing himself a giant checklist to run through for each patch <cbaines>futurile, QA includes a small checklist which should be a good starting point <cbaines>we probably don't want a giant checklist for patch review, but do let me know if there's anything obviously missing <futurile>cbaines: cool, thanks. Yeah - I get distracted very easily (or people distract me) - so having steps for everything is my thing! <pkill9>why do i look at all jobs listed and it all feels like bs <efraim>unscheduled power loss corrupted the bootloader <RavenJoad>I have 2 questions about the modular TeXLive system. 1) A PDF built with texlive-scheme-medium & some packages has "fuzzier" fonts than when I manually compile it with texlive-scheme-full. Am I missing a font package? 2) texlive-scheme-full compiles significantly slower than the old texlive package. Is this expected? <nckhexen>Pity you don't have the same 5kj… one. You can do for i in /gnu/store/*-guix-*/bin/guix; do echo '(@ (guix config) %config-directory)' | $i repl; done <m-e-o>hmmm, after pull and home reconfigure the on-first-login script contains invalid scheme <nckhexen>for i in /gnu/store/*-guix-*/bin/guix; do echo === $i; echo '(@ (guix config) %config-directory)' | $i repl | tail -n1; done # more like. <m-e-o>something borky or did i screw up my home configuration <nutcase>I also don't know, why I have so many <nutcase>the loop does not return any config-directory <nutcase>well, the tail was wroing (needed -n2) <nutcase>btw: `readlink `which guix`` gives me /gnu/store/hq0aw7a4l1bzvk5nkg0nc65apk0m75d4-guix-command <nckhexen>Yep, sorry, ‘guix repl’ will still print a prompt even when non-interactive. <nckhexen>I was hoping we'd have some in common, and we do, but they are both ‘correct’ ones: i97b… and 0znv… <nckhexen>It's not unusual to have so many. I have 79. <nutcase>the last one seems to be the one, I am using: lrwxrwxrwx 1 root root 56 Jan 1 1970 /gnu/store/wbzlmv0rsh91pw6kxbl7kdv6izrv8sh1-guix-68fe73cf3/bin/guix -> /gnu/store/hq0aw7a4l1bzvk5nkg0nc65apk0m75d4-guix-command <nutcase>among your 79 ones, you also have some with /usr/ ? <nutcase>"not yet" sounds like you expect to have some soon <nckhexen>Sorry, I didn't mean to imply that, just that it's still running. <nckhexen>I don't actually expect it, but who knows. <nutcase>my next test could be: downloading the install image again, install a VM and reconfigure using my operating-system <nutcase>or is it the same to just do a guix system image? <nckhexen>(This should not be related to reconfigurations, only guix pull, but ‘should’ is dubious when something that shouldn't happen has already happened.) <nckhexen>for i in /var/guix/gcroots/profiles/per-user/$USER/current-guix-*-link/bin/guix; do echo -n "$i: "; echo '(@ (guix config) %config-directory)' | $i repl | tail -n2 | head -n1; done <nckhexen>If you can reproduce this in a VM, that could certainly be informative, although I can't tell you how. <nutcase>yes, until link-47 to link-49 is /etc. link-50 to link-56 is /usr <nckhexen>So it gets misconfigured once and then you're on a bad road forever. Hm. <nckhexen>So what does …link-50/bin/guix describe say? Maybe I can reproduce this with the exact same commit. <nutcase>is there a way to find out the date of link-50? <nckhexen>Maybe include …link-50/bin/guix describe for good measure. <nckhexen>nutcase: Yes, if you use ‘guix pull -l’. <nckhexen>* Maybe include …link-49/bin/guix describe for good measure. <nckhexen>But clearly indicate which is which, as you can see I'm already easily confused 😉 <nutcase>number 49 is from Sep, 29th and 50 is Oct, 6th. It could be that 50 was affected by some full disk issue <nckhexen>Could be… I'll try pulling your 49, then pull to your 50 with that Guix, but that will take a while. Don't expect a reply tonight. <nutcase>nckhexen: no problem, no hurry, my znc stays connected all the time, I'll check for messages tomorrow. Currently I'm building a VM image, hoping to be able to boot it. My expectation: It will also use the guix version that uses /usr <nutcase>you said "tonight". That makes me assume that you live in UTC+-2hrs? <nutcase>We're trying to figure out what that means <nckhexen>the_tubular: nutcase seems to have a miscompiled (or something) guix that thinks /usr/local is the place to be. <nutcase>my %config-directory points to /usr/local/etc/guix instead of /etc/guix <nutcase>-note: build failure may have been caused by lack of free disk space (while trying to create a vm image) <nckhexen>Make sure your /tmp is big enough if you use tmpfs. <nckhexen>nutcase: I also asked you a question in PM, answer at your leisure. <nutcase>well, my tmp is as big as my disk allows tmp to be <nckhexen>nutcase: How big is that? Guix prints that warning when it thinks you're running low, since it can't detect the true reason, that's why it's a note. <nckhexen>The build log should give the real reason, but ENOSPC is likely. <nutcase>sorry, I was wrong. /tmp has less disk free than my disk has <nckhexen>Guix uses /tmp by default, unless you explicitly changed that. <nckhexen>I don't see any mention of /tmp in your system configuration, so I'll assume it's a regular subdirectory of /. <nutcase>yes, then it applies, what I stated first, it's as big as / <nckhexen>I've had systems with less than that for an entire year :) <efraim>nutcase: did you do ./configure without setting --sysconfdir=/etc? <nutcase>nckhexen: no I didn't check back then and don't know how to find it now <nckhexen>If you rerun the same command with --log-file it should print it again, although option support is inconsistent. <euouae>Hello, when I use `guix system reconfigure /etc/config.scm` on a first install, I get an error about //boot not looking like an EFI path <nutcase>btw: when I do a guix `system vm config.scm` and start the created vm, my %config-directory is /etc/guix inside the vm <euouae>My ESP partition is on /boot, should I have it on /boot/efi instead? <nutcase>now I did guix system vm instead of guix system image <nckhexen>Your EFI System Partition partition should be at /boot/efi by default. <nutcase>nckhexen: you mean I should check the log of the failed image build minutes ago? or were you asking for the failed reconfigure some days/weeks ago? <nckhexen>nutcase: I meant the image build that failed with the low space warninig. <nckhexen>I didn't expect you to have week-old logs :) <nckhexen>Although Guix logs in /var/log/guix are timestamped, if you really wanted you could probably find it. <euouae>and in bootloader, targets should be '("/boot/efi") right? <nckhexen>euouae: According to the manual, yes. (I haven't used UEFI in years.) <nutcase>nckhexen: but the command gave me "-note: build failure *may* have been caused by lack of free disk space" <nckhexen>nutcase: 25835209k is more than 21G is all I can say. <nutcase>omg, just ran into another issue, by investigating the first issue <nckhexen>The corruption might be poor error detection by mke2fs. <nckhexen>You can remove a few packages from your configuration to get the image size under 15G or so. <nutcase>did you see, that I was able to start a vm with my operating-system and my %config-directory in it is /etc/guix? <nckhexen>I did, but I'm not sure what to do with that information at this time. <nutcase>maybe we know later, if it was useful :-) <nckhexen>I'm pulling to the 2 commits corresponding to your generation 50 now, using my pasted guix corresponding to your gen 49… <nckhexen>If that leads to a Guix that knows that /etc/guix is best, then… well, it's something local to your machine, and I'm not really sure what to say then :-/ <nutcase>but that does not deliver any new insight <nutcase>gen 50 is only produced, if the build did succeed, right? <nutcase>so injecting an error into your attempt to build -50 on top of -49 would not result in a somewhat broken, somewhat incomplete -50, right? <nckhexen>But yes, generations are only produced if the entire build does not throw an error. <nutcase>I'm just wondering what could have happened between -49 and -50 <nutcase>and just running out of disk space would probably not result in a -50 affected by this out of space <nckhexen>I'm missing an explanation of how an ENOSPC could lead to bad defaults but an otherwise successful build. <nutcase>right, that's why I was asking, if my assumption is right. <nutcase>so, I also don't have any explanation for an effect of ENOSPC on the build, even no idea for an explanation <nutcase>but well, we're (you're) now testing, if reproducible builds are really reproducible? <nutcase>no, you can't verify with it, but falsify? <nutcase>do any environment variables influence the build? <nutcase>however, thank you very much for your efforts! <nckhexen>Builds are isolated in a Linux container by the guix-daemon, the environment should be constant modulo the running kernel. <nckhexen>nutcase: Do you have /gnu/store/3mk85x0m7g9cghsgvif30zq6yja0lfyc-config.scm-builder or /gnu/store/f34k91qi9rhw3dqmmahi63bbib6c5x7h-config.scm-builder? <nckhexen>And if so, what do they define as %sysconfdir ? <nutcase>/gnu/store/f34k91qi9rhw3dqmmahi63bbib6c5x7h-config.scm-builder defines /etc <nutcase>/gnu/store/3mk85x0m7g9cghsgvif30zq6yja0lfyc-config.scm-builder does not exist <nckhexen>And /gnu/store/m3m40gf93g79mq5xmh6d76hinj733zc8-guix-daemon-builder's GUIX_CONFIGURATION_DIRECTORY? <nutcase>/gnu/store/m3m40gf93g79mq5xmh6d76hinj733zc8-guix-daemon-builder does not exist <nckhexen>/gnu/store/vpz79pf0qjbqqpn79br3f0rkrj03cnyx-guix-daemon-1.4.0-13.e863274-builder --sysconfdir= ? <nutcase>is there a way to inject GUIX_CONFIGURATION_DIRECTORY into the build container? <nutcase> (list "--with-channel-commit=e863274e67e2242b970845783172c9f4e49405ca" "--localstatedir=/var" "--sysconfdir=/etc" <nckhexen>Re: ‘injection’: I can think of horrible hacks like breaking into the builder with GDB and modifying its environment from under it, but the sane answer is no. <nckhexen>The way to do that is to redefine the package/builder, which would change the hash, so it's not the same thing anymore. <nckhexen>ACTION has to sign off for the evening, sorry that I wasn't of any help. <nutcase>if not, why is there this (or (getenv "GUIX_CONFIGURATION_DIRECTORY") (string-append %sysconfdir "/guix"))) <nutcase>ACTION wishes you a good night and thanks you a lot for your time <nckhexen>Yes, pulled from your 49 (which doesn't isolate all variables, but still). <nckhexen>nutcase: Builders can modify their own environment, but you can't ‘inject’ or modify stuff without filthy unsupported and frankly unnecessary hacks. <nutcase>I learned a lot, although I'm not sure if I won't forget most of it <the_tubular> error: aborting reconfiguration because commit 9fe5b490df83ff32e2e0a604bf636eca48b9e240 of channel 'guix' is not a descendant of c77978d6c8d28e34e656f5b22ae9f0927e2f2dec <nckhexen>the_tubular: c77978d6c8d28e34e656f5b22ae9f0927e2f2dec (where you're at) is *newer* than 9fe5b490df83ff32e2e0a604bf636eca48b9e240 (where you're trying to go). Guix won't downgrade without explicit permission. Did you ‘guix pull’, and are you using ~/.config/guix/current/bin/guix and not some other, older guix? In particular, you didn't accidentally ‘guix install guix’? <RavenJoad>the_tubular: guix describe will tell you that. <the_tubular>It tells me I'm on 9fe5b490df83ff32e2e0a604bf636eca48b9e240 <RavenJoad>Like nckhexen said, which Guix binary is being used? The one in ~/.config/guix/current/bin/guix? <Rovanion>Bah, Musescore from Guix doesn't detect any playback device and prints nothing to the terminal. Though it will segfault if you try to set a playback buffer size.