IRC channel logs

<jmes>I'm using Guix Home and I want to test adding Shepherd services to the home Shepherd instance from a REPL (for real time testing/development), how to I accomplish this?

<jmes>Basically I'm not quite sure how to get connected with a specific instance of Shepherd

<mange>I don't know how to connect with a REPL, but "herd doc root list-actions" documents a "load" action to load a file, and an "eval" action to evaluate an expression.

<jmes>mange: Neat, I might be able to [ab]use that, thanks :)

<nathan-web>I cannot load any https://issues.guix.gnu.org/ pages. Is this an issue for others, or just me?

<jmes>nathan-web: I can't either, also savannah has been giving me 429 for a few days also.

<mange>Savannah could be due to cgit being disabled at the moment (https://hostux.social/@fsfstatus/113845788160755310).

<mange>The Guix issues site shouldn't be affected by that, but might be having other issues.

<lfam>I can confirm that Issues don't rely on Savannah

<lfam>You can look up Guix issues on bugs.gnu.org too. It's actually faster and more reliable

<lfam>For example, <https://bugs.gnu.org/72040>

<jmes>mange: Yup, I was trying to use cgit, that makes sense.

<podiki>well all of savannah seems to be down right now (gitweb is what i tried)

<podiki>or rather all of git.savannah

<lfam>It's a shame, but Savannah is frequently targeted by DDoS attacks

<lfam>I think that actual Git server is still online

<acrow>I can't reliably acquire substitutes all day today... What has Savannah done to attract all the DDOS attacks?

<vagrantc>substitutes are not on savannah

<acrow>Yes, I know, but if it's my ISP -- it's hopeless... :(

<nathan-web>When using `inherit` is it possible to modify `arguments` `#:configure-flags`, or must the be overwritten?

<mirai>best to use modify-arguments

<nathan-web>mirai: Do you have a link to documentation? I don't see it in source, and google isn't finding it when searching `"guix" "modify-arguments"`

<lfam>nathan-web: They may have meant to write 'modify-phases'

<lfam>Although, that doesn't help with configure-flags

<mirai>oh, my bad

<lfam>nathan-web: I would take a look at 'substitute-keyword-arguments'

<mirai>but package is a record-type so there has to be a getter for the arguments variable

<lfam>There are examples in the codebase of this being used to alter configure flags

<mirai>or yeah, the substitute-… thing

<mirai> https://git.savannah.gnu.org/gitweb/?p=guix.git;a=blob;f=gnu/packages/docbook.scm;h=990e0a38fd5a6a675a82846c3e88712bef92e4de;hb=HEAD#l134

<cdb-bugman>guix is failing to "compute derivations for guix", im using nonguix though so im wondering if i should submit a bug report like it says or ask for help in the nonguix irc? afaik im not allowed to talk about nonguix

<cdb-bugman>more concisely: am i allowed to report issues to the guix mailing list if im using nonguix

<cdb-bugman>the log for anyone interested https://0x0.st/8Hwg.txt

<jaft_r>cdb-bugman: I ran into the same; I've already submitted, that aspect not occuring to me until now.

<podiki>guix issues should be reported to guix, other channels to other channels :)

<podiki>so if there is an issue with (gnu packages guile) that should be reported to guix

<podiki>(whatever other channels you use doesn't matter for reporting a bug, unless it is due to that channel of course, then it should be reported to them)

<cdb-bugman>makes sense, thank you

<podiki>anyway, yes seems there is an issue in guix, something broke guix pull/building guix

<podiki>i'm guessing last commit made a circular dependency

<apteryx>ah, I see the 'guix pull' issue I just hit is already being discussed

<cdb-bugman> ]

<apteryx>cdb-bugman: the issue appears to be in guix proper, if I can trust 'guix pull -q'

<cdb-bugman>goddamnit dropped my headset on my keyboard and broke my mic

<apteryx>but perhaps not, since 'make as-derivation' succeeds

<podiki>any idea what the actual culprit is apteryx? reverting the last commit i think fixes it, not sure what cicrcular dependency it is

<podiki>(still building guix to check and will do a local pull)

<podiki>CI failed to evaluate on last commit so that is my guess

<apteryx>the last pass I see for the 'guix' CI job is https://ci.guix.gnu.org/jobset/guix?border-low=1984006

<apteryx>everything after 12th of Jan fails... hm.

<podiki>i meant just the failure to evaluate on the master jobset

<hako>Introduced by (gnu packages profiling) it seems?

<podiki>well reverting last commit you can then do make in a checkout, but does not fix guix pull

<podiki>yet CI did evaluate the previous commit fine...

<podiki>5d46903 that is

<podiki>oh wait, weird, it keeps trying to pull from the previous commit not the revert

<apteryx>removing the 'vv' commit seems to work for me; test it with 'make as-derivation'

<hako>You can try `guix time-machine --no-channel-files --url=$(pwd)` btw

<podiki>yeah i just forgot to specify local checkout, thought just pre-inst-env was enough

<hako>I can confirm it's introduced by dependency on tracy-wayland

<podiki>will do the revert shortly to at least unbreak for now

<podiki>hako: fix with a lazy resolve then?

<apteryx>podiki: I already pushed a revert for the breaking commit

<podiki>oh thanks

<apteryx>why this commit broke 'guix pull' is still a mystery

<podiki>apteryx: see hako message above

<lfam>What is the actual dependency cycle though?

<apteryx>I think it's perhaps make-scorep that violates top level laziness

<apteryx>it pulls openmpi at the top level, undelayed

<apteryx>which is from a different module

<apteryx>ACTION tries commenting out the scorep-openmpi line to see

<apteryx>yep, seems to be that

<apteryx>let's move this generator/package next to openmpi in the same module

<iyzsong>oh, thanks for the fix!

<apteryx>see info '(guix) Cyclic Module Dependencies' for a read on that

<apteryx>did someone work on Mumi recently? it's also crashing

<apteryx>always*

<apteryx>I opened an issue for it on the bug-mumi tracker

<podiki>maybe related to savanah problems? though that was only cgit i thought

<apteryx>doesn't look like,it's crashing in some element->html call, with some SVG

<apteryx>maybe it's trying to parse a SVG image for the first time ^^'

<podiki>weird, something wants to build i686 python-cryptography, but that is not a supported system

<apteryx>I've reinstated 'vv', with the scorep-openmpi relocation fix

<podiki>(3rd party channel)

<podiki>which means it first wants rust on i686, maybe python merge altered a supported-system somewhere?

<hako>apteryx: Some module imports are missing for make-scorep

<apteryx>ACTION must have dreamt 'make as-derivation' succeeding, ugh

<lfam>It's easy to get the tree in a weird state where `make et al` succeeds but it's not actually building what you think it's building

<apteryx>got the modules back; substitutes are so slow it's hampering validating it builds but at least it doesn't throw right away

<lfam>Amazing we didn't notice this since 2017

<podiki>i guess the vv package addition added in the module dependency cycle to surface this problem

<apteryx>yes, it's when these problematic modules get *used* that all hell break loose

<podiki>we don't have some test that just tries to import all modules? (or filtered on what have actual circular dependencies?)

<apteryx>circular dependencies are everywhere, which is fine as long as their references are delayed. there shouldn't be top level (module) circular dependencies though

<apteryx>a way to catch these is by running 'make as-derivation', which essentially does what 'guix pull' does

<podiki>hmm...i think from python-team merge something has pulled in rust now, which means a bunch of packages won't build for i686-linux (as in not a supported-system anymore)

<podiki>in other words, running guix pull on local checkout should catch these things, but "make" does not?

<apteryx>hako: neat tip (guix time-machine --no-channel-files --url=$(pwd)). I've now pushed a fixup commit that should fix 'guix pull' again

<podiki>is that equivalent to just guix pull --url -q ? or does time-machine here do something else?

<podiki>oh i guess you don't need to specify a separate profile then

<podiki>i think gtk+ now doesn't support i686-linux, something in the dependency chain depends on rust now (post python-team merge?)

<podiki>guix graph isn't proving very helpful as rust isn't on i686-linux so it won't show a path

<podiki>ok, must be gtk+ to rest, libsoup-minimal, samba, python-dnspython and finally python-cryptography

<podiki>ah, python-dnspython added python-cryptography as an input in 1ebc72c32316f50ccdb43557b3fe8cfdcef7702d

<podiki>i think it is optional so we can include that input only on supported systems, and hopefully that means no 2k rebuilds

<efraim>python-cryptography is optional or python-dnspython is optional?

<podiki>cryptography is optional in dnspython

<podiki>but might need to explicitly disable the feature in the build too?

<apteryx>'guix pull' should be fixed, if it's not for you, let me know

<podiki> https://dnspython.readthedocs.io/en/stable/whatsnew.html

<podiki>second line

<efraim>yeah, sounds like it's optional

<podiki> https://github.com/rthalley/dnspython/blob/main/pyproject.toml dnssec feature

<podiki>so i guess that needs to be turned off in that case

<efraim>looks like that's not the only spot that pulls in rust

<podiki>darn

<podiki>for gtk+?

<efraim>yeah

<efraim>looks like python-aioquic also, I'm going through the inputs of python-dnspython to see what else

<podiki>i see python-dnspython for others like imgui, pulseaudio

<podiki>thanks efraim

<podiki>i'm up past my alleged bedtime yet again

<efraim>I'll work it from here

<podiki>hopefully it is just via python-dnspython though, at least for gtk+ seems like it and that gets back a lot

<efraim>removing python-dnspython from samba fixed the dependency, but broke samba

<podiki>well hopefully dnsypython without dnssec doesn't break stuff. or else just keep an older dnspython too?

<efraim>also an option. and certainly easier for debugging

<efraim>asuming it builds

<apteryx>lilyp: the best for the gnome manifest would probably be to parse the versions from the releng json manifest that their release team puts out, and use that?

<apteryx>we could fetch and parse these in the manifest file

<efraim>python-trio also depends on rust now

<efraim>looks like everything for dnspython is optional, so there at least we have options

<podiki>thanks for looking into it, will check in tomorrow to help out

<podiki>night guix!

<futurile>night podiki - morning all

<efraim>ok, I have samba and therefore gtk+@3 good, but I'd like to adjust some of the inputs for the other python packages before pushing to enable more python packages not dependant on rust without as many rebuilds multiple pushes would cause

<paul_j`>Morning futerile!

<efraim>it looks like some of the packages I wanted to fix were already not available on i686, so I pushed what I had

<rekado>apteryx: the mumi issue you reported looks like aborted connections only.

<rekado>when a connection disappears fibers has nowhere to write and that triggers the backtrace.

<rekado>it's no accident that the reported cause is somewhere in the rendering code, because that's what's writing XML/HTML to the port.

<janneke>sneek: seen graywolf?

<sneek>graywolf was in #guile 5 days ago, saying: Thanks :).

<janneke>sneek: botsnack

<sneek>:)

<apteryx>ouf: 4 470,7 Mo seront téléchargés

<apteryx>oh, no rust substitutes?

<apteryx>what happened here?

<janneke>python branch was pushed?

<apteryx>ah, nevermind, I think there are substitutes; the grafts derivation were what confused me

<janneke>phew

<apteryx>seeing a derivation for each rust of the rust toolchain in the build plan is startling ;-)

<Kabouik>Did anyone have success with OBS Virtual Camera to stream their desktop in Guix Wayland? I was trying to share some document in a video conference and it didn't work because of Wayland, which I knew, but I thought I had the OBS Virtual Camera as a fallback. I'm probably missing some codecs but am not sure which packages to install.

<Kabouik>obs-wlrobs is already installed.

<Rutherther>Kabouik: are your OBS_PLUGINS_DIRECTORY and OBS_PLUGINS_DATA_DIRECTORY env vars set to path under the profile with obs wlrobs?

<Kabouik>Probably not. Is this supposed to be set manually?

<Rutherther>no

<Kabouik>Actually yes, they are set.

<Rutherther>okay, good

<Kabouik>To ~/.guix-profile/libs/obs-plugins and ~/.guix-profile/share/obs/obs-plugins, respectively

<Kabouik>I'm trying to upgrade obs-wlrobs

<Rutherther>I don't actually know how obs wlrobs is supposed to work, so this is as far as I can help

<Kabouik>Thanks for trying Rutherther!

<Kabouik>Screensharing in Wayland has been broken for so long now (independently from Guix), it really is an issue for work machines.

<Rutherther>screensharing is mostly working with xdg desktop portals. Also, now that I am trying, I can see my screen in obs with Wayland output source (coming from the wlrobs plugin), but I don't really know how that maps to the obs virtual camera

<Kabouik>I can see it in OBS preview too, but upon pressing the Virtual Camera button (which comes with a plugin as far as I remember), I get this: https://0x0.st/8HY8.png

<ferocious_iguana>Hi! I was configuring the newly installed Guix system and I have multiple issues. First, theprofiles are messed up: when I execute `guix package --list-profiles` it only outputs `~/.config/guix/current`. I know it should also include `~/.guix-profile`. How can I fix it?

<Rutherther>ferocious_iguana: did you install anything yet with guix install/guix package?

<ferocious_iguana>no, I was only doing `sudo guix reconfigure`

<Rutherther>okay. If you haven't then it is fine. The profile is not created as long as you don't install anything

<ferocious_iguana>OK, good to know thanks! My second issue is more serious, any subsequent invocatios of `guix system reconfigure` end with this error: https://paste.debian.net/1346113/

<Rutherther>ferocious_iguana: that signifies a disk corruption. Try "guix gc --verify="contents,repair"". It will at least tell you what paths are broken, and possibly repair them. For the ones it won't be able to repair, you will want to remove those paths - with "guix gc -D", you might have to also delete other paths referring to them

<ferocious_iguana>Rutherther: I would never have known, thanks a lot! I'll try that.

<Rutherther>also if there wasn't a power outage, I would suggest to also test your disk for any problems, disk corruptions normally shouldn't happen

<ferocious_iguana>So the `guix gc --verify="contents,repair"` indeed showed a bunch of paths that are corrupt https://paste.debian.net/plain/1346115 . However trying to delete them gives me `guix gc: error: cannot delete path `/gnu/store/1fdy5p2bn08a7qg79zl7d9hv7v052c35-kexec-load-system.scm' since it is still alive`

<Rutherther>yeah, they are still referred to by some other paths. You can use guix gc --referrers to see what paths refer to them. Also, if you are fine with just doing full gc now, you could also do that and bypass this process of removing just some paths

<ferocious_iguana>Sure, I'll be fine doing full GC as well! Rebooting to trying it out..

<Rutherther>hm, does that reboot have any relation to that? you don't need to reboot to do gc

<ferocious_iguana>Rutherther: thank you for your help, in the end just doing `guix gc` fixed it. Now system reconfigure results in a clean system.

<sleepy60>Hi! just installed guix via the binary tarball and all seemed to go well but when I try to install e.g. emacs I get many warnings like "compilation of /gnu/store/.../blah.scm, no such language scheme"

<sleepy60>anyone hit this before?

<Rutherther>sleepy60: what exactly prints these warnings?

<sleepy60>Rutherther: hello again! when i run `guix install emacs` I get the following messages (truncated):

<sleepy60>;;; compiling /gnu/store/<some id>/share/guile/3.0/language/tree-il.scm

<sleepy60>;;; WARNING: compilation of /gnu/store/<some id>/share/guile/3.0/language/tree-il.scm failed:

<sleepy60>;;; no such language scheme

<Rutherther>that's curious

<sleepy60>weird right! i think i will try a reinstall from source just thought id see if anyone had seen this before

<Rutherther>I haven't seen that. My guess would be that the installation somehow went wrong at some point.

<sleepy60>yeah seems likely

<Rutherther>you can also try guix pull to get newer guix, but my guess is that it's going to end up with same errors

<sleepy60>ok ill try that, thanks

<janneke>sleepy60: could you see if find /gnu/store/<some-id> tree-il.go exists?

<janneke>and if so, what the time-signatures are of tree-il.scm and tree-il.go?

<sleepy60>no .go file but the .scm exists

<janneke>sleepy60: to state the obvious, the .go file should exist in another directory, under <some-prefix>/lib/...

<sleepy60>oh sorry haha not obvious but lemme check

<janneke>(y)

<sleepy60>ok it does exist, same time signature as the .scm

<janneke>sleepy60: and at EPOCH I hope (with --ful-time) 1970-01-01 00:00:01.000000000 +0000

<sleepy60>ah good point i remember that bit in the docs, no they are recent timestamps janneke

<janneke>sleepy60: right. then the tool you used to extract the tarball is broken and doesn't respect the timestamps in the tarball

<sleepy60>ahhhhhh

<sleepy60>interesting

<sleepy60>weird because just using default tar in arch

<janneke>wow

<sleepy60>hehe

<sleepy60>yeah

<Rutherther>isn't an argument needed to preserve timestamps?

<janneke>(well, or something else happened after extracting, of course)

<janneke>Rutherther: nope

<sleepy60>something else happening seems more likely

<sleepy60>ok well thanks for your help both of you i will try a reinstall

<janneke>in any case, this is most probably the cause of the error

<apteryx>is someone looking at python-strict-rfc3339 test failure?

<peanuts>"RFC 3339 - Date and Time on the Internet: Timestamps" https://datatracker.ietf.org/doc/html/rfc3339

<janneke>everything in /gnu/store should be at EPOCH (sources) or EPOCH + 1(s), built stuff

<sleepy60>ok noted i will remember that for next time janneke

<janneke>sleepy60: better luck next time!

<sleepy60>thank you!

<rekado>apteryx: I don't see a build/test failure on commit 69d657f9c4ffa59d708356baacbefafb58f09308

<klm`>hi! `herd start myservice` just says "failed to start service". where can I find more details? no #:log-file shows up ... is there a verbose flag somewhere?

<Rutherther>klm: so there is nothing in the shepherd log?

<klm`>Rutherther: where is the shepherd log?

<klm`>Rutherther: /var/log/messages just shows the same short "failed" message as the invokation

<klm`>oh gosh, I didn't read that thourougly enough

<klm`>/var/log/messages says "shepherd[1]: Service nebula is currently disabled".

<klm`>now, I wonder, what does that mean. restarting my service yields the same error message.

<lockbox____>klm`: did you try enabling it?

<dariqq>klm`: it probably got disabled because shepherd tried to restart it too many times. try 'herd enable myserver' and then start it again

<klm`>ah, great, thank you!

<klm`>you're right, it's respawning too fast and getting itself disabled.

<klm`>there's still no other output than "Service nebula (PID 15922) exited with 1." I can't see any other logs.

<klm`>if I run the process manually, I'm getting some more error messages on stderr. How do I get shepherd to show me those?

<Rutherther>klm: if that is the case and you haven't set log-file of make-forkexec-constructor, then it seems it doesn't log anything to stdout when started from shepherd

<Rutherther>because stdout goes to the shepherd log by default - so /var/log/messages

<klm`>Rutherther: ah, ok, so I need #:log-file is I want to be able to monitor the process, got it.

<klm`>there it is, /var/log/nebula.log is now telling me what the problem is. thank you.

<klm`>could it perhaps be a good idea to change the error message when you're trying to start a disabled service?

<klm`>the "herd start muservice" tells me "failed to start service", but /var/log/messages is telling me why (it's disabled)

<klm`>I think it would be really helpful if the immediate feedback from "herd start ..." would let you know whats going on, eg. "myservice is currently disabled. re-enable it with `herd enable myservice`"

<klm`>thanks to all of you for helping me out

<Rutherther>is there a reason why one cannot easily add something to /etc/profile? the content is just hardcoded string going directly to etc-service-type. Would it make sense to make a patch, either with possibility to add directly to it, or with sourcing files in /etc/profile.d like on other distros, so then users can put their files into there with etc-service-type?

<Deltafire>i think that would go against the idea that /etc is dynamically generated

<Rutherther>huh?

<Rutherther>it is generated from what you have in etc-service-type

<Rutherther>or rather, symlinked

<dajole>Running a program, I get `gcc-11.4.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found`. My best guess is that I'm missing some sort of c++ dependency. I do have `gcc-toolchain` installed. How do I figure out what package I'm missing?

<dajole>Apologies for the awkward formatting, there must have been backticks in the pasted parts.

<ieure>dajole, Looks like you have the wrong version of the right package. Message indicates it's the lib output of gcc.

<dajole>Would I need to install `gccc-toolchain@some-version`?

<Rutherther>dajole: do you have LD_LIBRARY_PATH set?

<Rutherther>(environment variable)

<dajole>@Rutherther doesn't seem to be set. What should it be set to, and how did you know it's needed?

<Rutherther>it is not needed, it shouldn't be set

<Rutherther>what executable is giving you this error? is it one from guix package or not?

<Rutherther>or to be more correct - it is usually not needed to be set, and it usually shouldn't be set, as it can mean wrong libraries are loaded. It is the first guess to have if something starts misbehaving like this, that LD_LIBRARY_PATH (or even worse LD_PRELOAD) is loading wrong versions. Since you don't have it set, it is not the cause of the issue

<dajole>The error pops up when running an Elixir Livebook (sort of like a Jupyter notebook)

<dajole>`Failed to load NIF library: '/gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/dajole/.cache/mix/installs/elixir-1.18.1-erts-15.2/fb7db726a367f088020909df8770bf0a/_build/dev/lib/exla/priv/libexla.so)'`

<Rutherther>so it's a random executable downloaded from somewhere

<dajole>I suppose

<dajole>(and also thank you regarding the detailed response w/r/t LD_LIBRARY_PATH, still trying to wrap my head around lots of things)

<Rutherther>you cannot run executables like that on guix easily. You have to either package it, or use a workaround to start it, ie. by using a shell container with correct dependency versions and emulated fhs, or by going into a shell and giving it ld library path pointed to the profile lib folder

<Rutherther>unfortunately there is a lot of programs that just download their dependencies and those are built for fhs environments

<dajole>Ah, I see, that's helpful thanks. I may have to switch back to asdf for managing my Elixir versions then for the moment until I can figure out the details. Thank you for your help.

<singpolyma>can I easily write something like `echo blah | doit` in a guix build step? I know how to use invoke but I think I can't set the stdin that way?

<Rutherther>singpolyma: you might be looking for open-pipe (or more specifically open-output-pipe)

<singpolyma>cool, I'll check the docs for that

<singpolyma>ok, so this seems like what I want. Is there any way to close only the input side of the port so that the command knows to finish but still let me read the output?

<Rutherther>as far as I know the program knows to finish when stdin puts in end of file

<singpolyma>right. so how do I put that in?

<Rutherther>singpolyma: just close the pipe (close-pipe) procedure

<ieure>singpolyma, What are you actually trying to accomplish? You're pretty deep in the weeds here, maybe there's a better way to do what you want.

<singpolyma>ieure: i want to `echo blah | doit` and get the output of the command

<ieure>singpolyma, For what reason? What command do you want the output of?

<singpolyma>ieure: in this case `echo "(./file.dhall).keytoextract" | dhall text`

<singpolyma>Rutherther: I can't read after I close though. That's why I asked about half-close

<ieure>singpolyma, If you want to read the output of dhall, that's a separate pipe from the one providing it stdin.

<Rutherther>oh, I thought open-pipe gives you two pipes, not just one

<ieure>Not sure about the Guile API for this stuff.

<singpolyma>hmm https://www.gnu.org/software/guile/manual/html_node/Pipes.html seems to show it returns one bidirectional thing but maybe I'm just reading it wrong and there's a second one somewhere

<Rutherther>are you sure you cannot just call read / get-string-all on it and only then call close-pipe? or does that indeed hang?

<efraim>singpolyma: If you can't find a better way I found pipeline and made this monstrosity https://git.sr.ht/~efraim/guix-config/tree/master/item/efraim-home.scm#L232-245

<Rutherther>so (pipeline a b c) is something like "a | b | c" in shell?

<efraim>yeah, and then I wrapped the whole thing in read-line to get the final output

<singpolyma>Rutherther: yes, if i close first I get an error about it being closed when I read, even if I use close-output-port, if I close after it hangs

<ieure>singpolyma, So dhall doesn't print anything to stdout until stdin is closed?

<singpolyma>correct

<ieure>singpolyma, And there's no way to provide the stdin as an argument that it can read?

<singpolyma>I could make a temp file and give it a file

<lfam>Problems related to the device tree while building the kernel on x86_64! Weird, right?

<lfam> https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00172.html

<lfam>Please help

<singpolyma>hmm, so I got to https://paste.debian.net/1346175/ this use of receive and pipeline works in a simple guile script, but here in a guix recipe it gives me the error "Unbound variable: from" -- does guix have it's own thing named receive or something which may be interfering?

<singpolyma>switching to call-with-values seems to work in the guix context

<bonz060>Random. I know there's an underlying issues with savannah and git, since I'm getting a 443 when doing a pull. Related to this: https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00161.html ; Is there any agreed upon clones people might be using?

<h4>Zenity 3.43 was pushed on Guix with on 3c5394ca7bad960ee3dfe9a61332755b302d617d, yet I can't `guix shell zenity@3.43`, it just "guix shell: error: zenity: package not found for version 3.43"

<h4>And I can't use 3.44.1@9511488941abfb38d4e56e38273a83b17df5777a because it wants gLibC@2.38, yet only 2.39 is available

<janneke>git log --oneline | grep zenity

<janneke>9511488941 gnu: zenity: Update to 3.44.1.

<janneke>so no more 3.34

<janneke>*3.43

<h4>janneke: But I want that version, and what is the point of "@" concept if wa can't pick versions?

<Rutherther>h4: @ picks up the version from the packages that are available in the channels you are using

<Rutherther>it is just a more specific matcher for packages. zenity means look through all packages for the ones with name zenity, and choose the newest one. zenity@x means look for all packages with name zenity and choose the one which is newest among the x. versions, ie. if there was x.1 and x.2, it will choose x.2

<janneke>h4 to get 3.43, you could try something like guix time-machine --commit=3c5394ca7bad960ee3dfe9a61332755b302d617d -- shell zenity

<janneke>(or any commit before it was updated to 3.44)

<janneke>h4: fwiw, guix shell zenity works for me

<h4>janneke: Useful command! So I can stop worrying about versions here and there and just use Guix at a state where everyting was fine. I guess it behave like classic `shell`, like without `--container` it will pick up all system package and that would defeat the purpose, innit?

<h4>janneke: In some case it needs a gLibC version that seems to never have been in Guix (2.38)

<Rutherther>h4: the stuff you put after "--" is just what you would put after "guix" command normally, so it's like "guix shell", just with guix pointed to commit 3c5394ca7bad960ee3dfe9a61332755b302d617d

<peanuts>"gnu: zenity: Update to 3.43.0. - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3c5394ca7bad960ee3dfe9a61332755b302d617d

<janneke>h4: i'm not sure what you mean by that, but we had glibc-2.38 although i'm unsure how that could possibly help

<h4>Rutherther: So if it's the same it's supposed to grab system libraries, yet the command is supposed to put back Guix, but system libraries aren't "back"

<podiki>efraim: thanks for the python/i686 fixes! i saw successful builds for the broken (other channel) packages

<h4>janneke: Well that could help because "zenity: version `GLIBC_2.38' not found required by"

<Rutherther>h4: I have no idea what you are trying to say, there are no 'system libraries', there are just libraries used by a particular software, and all of those are hardcoded in the derivation's rpath

<Rutherther>h4: do you happen to have LD_LIBRARY_PATH set? also, what exactly does print this? just running zenity command or something specific?

<efraim>podiki: heh, took me 2 tries :)

<podiki>i saw :) glad i didn't try something last minute late at night

<h4>So if it's all package derivation based, a package is misconfigured, because it calls dependencies that calls dependencies that aren't there, so some version was misconfigured

<janneke>h4: that doesn't sound like an error you should ever be able to get with guix

<h4>janneke: yet I'm here

<h4>Haven't received message after the one that stated that everything is derivated

<Rutherther>you can see the messages in the log https://logs.guix.gnu.org/guix/2025-01-21.log#193137

<h4>Like, prismLauncher@5 wants gLibC@2.35 but Zenity@latest wants gLibC@2.38

<h4>Outside `guix shell` "LD_LIBRARY_PATH" is not set, returns nothing

<Rutherther>outside? so inside of it, it is set?

<h4>`guix shell -- echo $LD_LIBRARY_PATH` returns nothing aswell

<janneke>ACTION looked in the zenity tarball for binaries

<janneke>but it seems to be fairly simple C program

<Rutherther>h4: that's wrong, that prints the variable from outside the shell. Ideally you should check this env var in the environment where you are actually starting the program, but unless you are setting this variable yourself somewhere, it's not set

<h4>Rutherther: I don't ever set that variable, I expect Guix to manage how it execute binaries, to what it links what, it's all Guix is about after all

<h4>I just use `guix shell` to tell him what I want, eventually `--container` to isolate from my system

<Rutherther>exactly, and if you were to set ld library path you are making it impossible for guix to work like it should. That is why I am asking

<h4>When Guix bother me too much I just manually specify ldd to get things to work (like `exec /gnu/store/theLddIWant ./theBinary ...`). But I never touch such variable, and here I did neither of that

<Rutherther>yes, you don't need to repeat yourself

<h4>I know, I know... Just trying to fill space

<Rutherther>please share a reproducer

<janneke>ah, you're messing with LD_LIBRARY_PATH, yeah that's a great way to break things!

<Rutherther>they aren't

<h4>Every system seems different, so it's really crazy to reproduce lol, despite Guix being about reproduciveness... Anyway, `guix shell openjdk prismlauncher@5 qtwayland@5 -- prismlauncher`, then you launch latest snapshot

<h4>Rutherther: See, it's maybe important to repeat myself, janneke say that I mess with the variable despite me saying the contrary two times

<Rutherther>h4: and output of "guix describe -f channels"?

<janneke>there's no such thing as prismlauncher in guix

<h4>janneke: right, the problem maybe comes from here

<ajarara>should guix style -S inputs also update crate-inputs to the right input style (no input labels)?

<ajarara>sounds like the kind of thing that would be on a mailing list, but I see people doing it manually

<Rutherther>ajarara: no, since cargo inputs rely on labels

<Rutherther>altough wait, maybe they don't

<Rutherther>I thought they did but not I checked and it seems not everything has them

<ajarara>so I should feel fine pushing up a patch series that has them

<ajarara>if it gets incorporated into a style then it can just be applied then I'd imagine

<ajarara>if guix import -r comes up with a distinct version of a library than what's already in the store, then it's cool to chuck in the close-to-duplicate, right? Preference is updating if feasible but that can quickly get out of hand since I imagine the person updating has to build all transitive packages. But like that's the point of nix/guix, right? These two versions can exist side by side with no problems beyond it being ambiguous

<ajarara>source. And if that's a problem then it can just be solved in a separate 'reconcile these two' pass?

<ajarara>ah I see guix refresh --list-dependent

<lilyp>sneek later tell apteryx releng yaml file, but yeah

<sneek>Okay.

<lfam>Again, I'm looking for help / advice dealing with the device tree on x86_64: <https://issues.guix.gnu.org/75733>

<lfam>If that sounds weird... yes :)

<ieure>lfam, Looks like the error is from __sub-make, so I think it's using a Makefile other than the top-level one.

<lfam>Yeah... any way to figure out which? Or should we just figure it out "by hand" (i.e. follow the chain of logic by reading the Makefiles)

<lfam>There is a 'scripts/Makefile.dtbinst'

<lfam>I suspect that we just need to skip this part of the install phase if we are not on platforms that use the device tree, but now I'm wondering if x86_64 will start doing that, since CONFIG_OF is unconditionally enabled for 6.13

<ieure>Yeah, not sure. Seems like others would have encountered this problem, anything related to it on LKML?

<lfam>I mean... it's weird right?

<ieure>Yeah, feels a bit weird.

<lfam>I'll search LKML directly. Of course Google didn't find anything useful

<lfam>There could also be something about my system that makes the build process enable CONFIG_OF? It would be great if someone else could try configuring / building with it turned off

<ieure>Don't see anything related to this in https://kernelnewbies.org/Linux_6.13

<lfam>Yeah, I didn't see anything in the release notes or 3rd party sources like KN

<lfam>I'm going to check if the build of 6.12 creates any dtb files. I think it's likely that this part of the Guix packaging was never actually run on x86_64 previously

<lfam>But even if we adjust this Guix install phase properly, the whole thing seems fishy

<lfam>I have to go AFK but I'll be back later

<ieure>issues.guix.gnu.org isn't responding, anyone aware?

<lfam>Not sure if the right people are aware or not...

<lfam><bugs.gnu.org/$bugnumber> works still

<ieure>Yeah, but I want to see if CI processed my patchset.

<rekado>I restarted it

<Guest16>hello

<ieure>rekado, Thank you.

<Guest16>i have installed exwm. After that, i deleted the ~/.emacs.el because i have my configuration in the .config/emacs directory. Than i realized, that the exwm package modified the .emacs.el file in the home directory. So i deleted the exwm package and installed it again. But that process doesnt recreate the .emacs.el file.

<Guest16>is there a way to get the proposed configuration from the package back?

<ieure>Guest16, I don't think the exwm package creates ~/.emacs.el

<divya>I have a stupid question, maybe I knew but forgot, how do you exactly create a shepherd-service that runs an executable bash script?

<meatus>Is there a way to "move" a running emacs instance to an environment created with "guix shell"? Otherwise how can I have emacs use the dev environment for a given project

<meatus>Also how do I make the right tree-sitter grammar available

<ieure>meatus, You need to change Emacs' exec-path, I'm not sure if emacs-guix has a thing for this, but direnv is similar to what you want. I'm not sure about tree-sitter grammar, those are .so files Emacs need to load. Those may have to be in your main profile.

<Rutherther>meatus: no, you have to either source the environment in emacs, or start emacs from that environment. See envrc/direnv packages for the first approach

<Rutherther>the envrc is superior imo since it is per buffer

<janneke>meatus: there is the somewhat crude M-x guix-set-emacs-environment,

<janneke>or you can use envrc.el, which together with direnv is amazing

<dariqq>sneek later tell lfam : i replaced your config with the linux-libre debian one (https://linux-libre.fsfla.org/pub/linux-libre/freesh/configs/6.13/x86-64) and had no issues building and has (among other differences) "# CONFIG_OF is not set"

<sneek>Got it.

<meatus>Rutherther: so the setup is to have direnv (the "shell" package) and envrc (the emacs package) installed in your user profile, and then write an .envrc in your project that calls 'guix shell ...'?

<meatus>otherwise how do I make sure /gnu/store/...-profile/etc/profile exists and it gets run

<janneke>yes, in .envrc you have something like: eval $(guix shell --search-paths)

<Deltafire>i tried gnu.repl today, it either crashed or doesn't accept keyboard input

<DeadlyMongoose2>Hi there. I've been having a problem with guix home: I set it up with guix home import ./src/home, but trying to reconfigure now, I get the message: guix home: error: canonicalize-path: No such file or directory: "/home/media/src/home/./src/home/.bashrc".

<DeadlyMongoose2>To be clear, I succeeded in reconfiguring once, and must have changed something, because trying to reconfigure again, I get this error^

<DeadlyMongoose2>and I haven't changed my home-configuration.scm at all

<ieure>DeadlyMongoose2, Huh, this is maybe a bug? Looks like it's failing because it can't find the local file to install in the home env, but presumably `guix home import' moved it away in the first place.

<Deltafire>you've also got src/home repeated

<DeadlyMongoose2>I know! I copied the error exactly.

<DeadlyMongoose2>It says No such file or directory: "/home/media/src/home/./src/home/.bashrc

<ieure>DeadlyMongoose2, Can you paste your home config somewhere?

<DeadlyMongoose2>:P

<DeadlyMongoose2>Sure

<ieure>DeadlyMongoose2, FWIW, I tried `guix home import' a couple times and was never pleased with the result, so ended up taking my (homegrown) dotfile repo and converting it to Guix Home. That's been working well for a year or so.

<ieure>Also has the benefit of being more understandable, since I did all the things in there.

<DeadlyMongoose2> https://pastebin.com/1MLTszxk

<ieure>DeadlyMongoose2, And you have no src/home/.bashrc or .bash_profile files?

<DeadlyMongoose2>I have src/home/.bashrc and /src/home/.bash_profile

<ieure>DeadlyMongoose2, Ohhhhh okay I know what's happening and it's unbelievably dumb. You're `guix home reconfigure'ing from src/home, and need to do it from $HOME.

<ieure>DeadlyMongoose2, That, or change your home config to remove the "./src/home/" prefix from the paths in home-bash-service-type.

<DeadlyMongoose2>I'm guix home reconfiguring from /home/media though!

<DeadlyMongoose2>ieure I'll give that a shot

<DeadlyMongoose2>I've changed it, but it still gives "guix home: error: canonicalize-path: No such file or directory: "/home/media/src/home/./src/home/.bashrc""

<DeadlyMongoose2>Strange, isn't it?

<DeadlyMongoose2>hold on one second

<DeadlyMongoose2>I'll report back in a few minutes as to whether or not that fixed it. Thank you so much for the advice.

<futurile>sneek later tell civodul Sent the second Guix survey post (#75471) - almost certainly fixed all the apostrophe's

<sneek>Okay.

<peanuts>"perl-gtk2 Failing Tests" https://issues.guix.gnu.org/75471

<futurile>and that's what you get for being tired - I swear I have some sort of arithmetic blindness for debbugs numbers

<decfed>so peanuts is useful after all ;)

<peanuts>decfed: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot

<futurile>heh, true - we've finally figured out what it's for decfed