<Guest78>is it normal for custom package definitions to require a build of the dependencies instead of using substitutes? for my custom glib package, it used substitutes but for my custom gtk package it is building all dependencies
<attila_lendvai>any python+guix experts around? the check phase of python-daemon needs to invoke `make test` that in turn wants to use pip to install setuptools, even if i add it to the native-inputs. any hints?
<rekado>lucypoo: is it a copy or have you modified the existing package definition?
<attila_lendvai>i seem to vaguely remember reading something about this on the mailing list, that pip doesn't see the packages provided in the native-inputs...
<rekado>attila_lendvai: it’s probably because of the build backend
<ulfvonbelow>do we have any icecat / firefox experts here? I'm on a quest to build everything with maximum debugging, and icecat is resisting my efforts - even after removing --disable-debug, --disable-debug-symbols, and --enable-strip from configure flags (and specifying #:strip-binaries? #f), the debugging symbols still aren't making it in
<mirai>apteryx: Thanks! Must have been quite a rabbit hole there
<apteryx>yes, and the lack of resolution was painful to accept ^^'
<apteryx>I hope the emacs folks think about something I haven't
<adanska>does anyone know if theres any efforts to update the gnome shell on guix? gnome 42 is about a year old now, and with gnome 45 coming out it might be a good idea to try and update to gnome 44 or something like that. are there any mailing list threads that talk about this?
<ieugen>I fixed my issue, it was a typo in url - missing "v"
<vivien>lilyp, debugging the VM failure for gnome-team: dbus-daemon is running, elogind too, but I think there is a problem with the system session. Looking at the logs, gdm fails with: gdm: Gdm: Couldn’t connect to system bus: Could not connect: No such file or directory.
<vivien>OMG the problem is the dbus socket is in /var/run but it should be in /run
<vivien>It explains why upowerd neither works in host system nor in the vm
<vivien>Both have the socket in /var/run, but somehow it is expected in /run
<vivien>If I (symlink "/var/run/dbus" "/run/dbus") in the activation of the dbus service, gdm starts
<graywolf>apteryx: Would you know how to rebuild the python locally? I tried `guix build --no-offload --no-substitutes --check --rounds=3 python' but that just builds a graft I guess? How to actualy compile it to check the problem you describe?
<viaken>Kept running into weirdness that crashed shepherd.
<phf>Hello! I've gotten these commands to work: `./pre-inst-env guix build --no-substitutes -f elixir-kv.scm; ERL_LIBS=$GUIX_ERL_LIBS elixir -e 'import KV'`. Can anyone guide me on the next steps? For context, see: https://paste.debian.net/1293996/
<lilyp>vivien: it turns out to be a glib issue after all
<Gooberpatrol_66>is there a way to override guix_defconfig when using customize-linux? using #:defconfig and #:configs both causes "Mismatching configurations" error
<graywolf>My impression so far is that guix is not very fast with security patches
<nckhexen>Help in that regard is disproportionately appreciated.
<lilyp>the whole point of grafts is that we can roll out security patches faster, but that also means we have to be up-to-date with security news
<lilyp>that being said, is there a fix to glibc published yet?
<nckhexen>I'm dim. Is there a way to have an arbitrary list with therein contained a file-like object, and just say something like #~(do-stuff #$list) later on, and have Guix/magic/Guix magic take care of the gexps? I can't get that idea to do anything else but serialise to lists with broken #<junk> inside.
<nckhexen>Maybe it's a bad idea, but I'd like not to assume much about the list if possible.
<janneke>cbaines: nice, and good to "know"; we can always (re)try builds with less memory later
<lilyp>nckhexen: you could try #~(do-stuff #$@(map (lambda (x) (if (gexp? x) x (wrap-in-gexp x))) my-list)) – not sure what goes into wrap-in-gexp tho
<nckhexen>I think I tried that but eventually got lost in my own abomination. If you think it has a chance of succeeding, I'll try again. Thanks.
<lucypoo>Has anyone here in the past obtained a test environment for running gui tests in a headless manner using wayland, as a replacement for Xvfb? I have been looking into `WLR_BACKENDS=headless sway` but have encountered issues
<lilyp>lucypoo: gnome-team has a bunch of wayland tests, but they run on xvfb
<lucypoo>I was having issues with Xvfb but for my package i think it may be better to move away from x as gnome maintainers are seemingly only keeping x support around as long as gdk recieves no major changes