<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?
<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>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>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’.
<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>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.
<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?
<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>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?
<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’?