IRC channel logs


back to list of logs

<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
<rekado>attila_lendvai: see python-inflect
<attila_lendvai>ACTION looks
<lucypoo>rekado i have modified the gtk package definition ( i am packaging the latest commit on the main branch)
<attila_lendvai>rekado, python daemon has no file with 'custom_build' or 'backend' in their names. does it still apply?
<rekado>attila_lendvai: or python-importlib-resources
<rekado>attila_lendvai: the problem lies with get_requires_for_build_wheel
<attila_lendvai>wait, the toml file has build-backend = "setuptools.build_meta"
<rekado>in these two packages we provide custom noop implementations to bypass the use of pip
<attila_lendvai>ACTION tries to mimic that
<attila_lendvai>oh well, the `requires = ...` line in this toml file is multiline. i can't just copy-paste the substitute... which means it's sleep time for me.
<lucypoo>just hopping out to switch clients
<attila_lendvai>ACTION waves goodbye, and will read the logs
<lucypoo>oh yeah logs
<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
<ulfvonbelow>here's what the configure phase output looks like:
<peanuts>"debian Pastezone"
<lucypoo>oh maybe my mailing list mails are failing as i am using attatchment-s
<gnucode>lucypoo: I might recommend the arc email client
<lucypoo>ah ok thanks
<peanuts>"Initial pre-release of aerc: an email client for your terminal"
<lucypoo>is it designed for mailing lists
<gnucode>lucypoo: yes
<gnucode>It is supposed to support guix
<gnucode>'s email driven workflow very well.
<lucypoo>ah nice!
<lucypoo>i like the vim binds
<Kolev>Hi Guix!
<Kolev>Thinking of putting Guix on my X200.
<apteryx>mirai: I wasn't able to fully understand the Debbugs/Gnus issue changing the Subject when replying, but I've X-Debbugs-CC'd you to a new bug report I've created with my findings.
<apteryx>Kolev: go for it!
<apteryx>I have one such machine around
<Kolev>Problem is, I'm used to Fedora, which has so much polish. Guix is rougher around the edges, and I'm not used to that.
<apteryx>it's not a big usability problem to me (more like "nice to have")
<apteryx>guix-ci at is useful
<apteryx>ulfvonbelow: if you are motivated you could try asking on their chat system (element) at
<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?
<janneke>adanska: dunno, have you looked at
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<adanska>yeah, i took a look
<adanska>the commits are polluted a little with merging main into it
<adanska>theres some updates to gnome apps but i cant see anything regarding the shell itself
<adanska>hence my asking here
<adanska>actually my bad, there appears to be a commit updating gnome to 44.2
<adanska>i guess it just hasnt been merged yet
<adanska>whats the timeline with merging gnome-team into main?
<adanska>i suppose theres a bunch of gnome apps that all need to be updated before things can get merged...
<janneke>sneek: later tell adanska, i don't know the specifics but there are several bugs marked [gnome team] so i expect those hold some information wrt the gnome-team merge
<sneek>Got it.
<janneke>sneek: botsnack
<cnx>any chance someone will take a look at my patchset adding senpai IRC client:
<peanuts>"[PATCH 0/4] Add senpai IRC client"
<adanska>hi guix!
<sneek>adanska, you have 1 message!
<sneek>adanska, janneke says: i don't know the specifics but there are several bugs marked [gnome team] so i expect those hold some information wrt the gnome-team merge
<ieugen>hi, is there a way to have url-fetch follow redirects ?
<ieugen>when I fetch a package it returns a "Location:" header that contains the actual package and guix build fails to download the file properly
<ieugen>with curl, I have to add "-L" option
<adanska>janneke, thats exactly what i was looking for))) noob mistake not looking at the issue tracker, haha!
<adanska>oh, forgot!
<adanska>sneek: botsnack
<graywolf>Hello Guix, do we have fix for CVE-2023-4911? Or at least a issue I could track?
<sneek>graywolf, you have 1 message!
<sneek>graywolf, abcdw says: I found this implementation of srfi-197 somewhere and it works fine in guile:
<peanuts>"~abcdw/guile-nrepl: src/srfi/srfi-197.scm - sourcehut git"
<peanuts>"SRFI 197: Pipeline Operators"
<graywolf>peanuts: The oficial one works, I just have to use the -syntax-case variant. :) But thanks anyway
<graywolf>sneek: later tell abcdw: The oficial one works, I just have to use the -syntax-case variant. :) But thanks anyway
<sneek>Got it.
<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
<vivien>And, the upower service works!
<vivien>Uuh I have a problem
<vivien>Could a moderator reject my email?
<vivien>It would be a lot better if it could be rejected
<vivien>Before someone accidently allows it ^.^
<vivien>Please I messed up
<mirai>cnx: have you investigated this `go-github-com-delthas-go-localeinfo' test issue?
<mirai>as for `senpai', I'd sent a patch upstream for the Makefile
<mirai>that either adds a install-man rule or augments install with the manpages (you can attempt to replicate how automake does this)
<sneek>adanska: Greetings :D
<adanska>vivien: good catch! i was reading the issue tracker regarding this - seems like the most infuriating type of bug to fix! super cool work :)
<mirai>Does hurd have commands like `ip'? (like iproute2)
<apteryx>when did our python regressed and stopped building reproducibly?
<apteryx>it used to be reproducible
<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?
<apteryx>you also need --no-grafts
<graywolf>ah, thank you, now it builds
<apteryx>also note that currently --check implies --no-offload
<apteryx>and if you want to inspect the differences with diffoscope for example, you should keep the failed builds around with --keep-failed (-K)
<apteryx>it's small changes in the byte compiled files for me (.pyc)
<apteryx>that sounds deja-vu, it's sad we've regressed there
<graywolf>guix challenge does confirm that, only listed differences are in .pyc
<graywolf>sidenote: guix challenge is really cool!
<apteryx>I wonder if we can have it just compare the two build farms, avoiding even building locally?
<apteryx>I think it's designed to challenge against what *you* build, so probably no
<apteryx>but we could teach it something new
<apteryx>our guile package also differs by only one file: /lib/guile/3.0/ccache/ice-9/ftw.go
<graywolf>That could be useful I guess
<graywolf>Hm, how do I download the differing files from the farms? Curl? Or is there a built in commant for that?
<apteryx>I just noticed you can simply 'guix build x' to put it in your store from e.g. and then run 'guix challenge x'
<apteryx>and it'll compare that against both berlin and bordeaux
<apteryx>graywolf: I don't think there's an interface for that yet
<apteryx>what I typically do is rebuild with 'guix build --check -K --no-grafts python' and then run diffoscope /gnu/store/xxx-python{,-check}
<graywolf>Hm, that seems simple enough. Thanks.
<graywolf>I have to admit, I am bit surprised diffoscope does nothing useful with .pyc files :/
<graywolf>Interesing, --rounds=3 do pass just fine locally.
<graywolf>(It would error out if the content differed, right?)
<mirai>increase the pain (rounds=30)
<graywolf>My poor laptop (sadly the python does not build on my server at all, tests fail) :/ Will do.
<apteryx>graywolf: are you sure it`s really building it full, with --no-grafts?
<graywolf>0:01:30 load avg: 10.02 [421/425] test_compileall passed -- running: test_multiprocessing_forkserver (1 min 13 sec), test_concurrent_futures (56.3 sec), test_multiprocessing_spawn (40.9 sec), test_asyncio (40.2 sec)
<graywolf>Current line in scrolling terminal
<apteryx>ok, yes. strange
<graywolf>seems to build *something*
<graywolf>I am trying the =30 now, will report once done
<apteryx>does calling 'guix package --roll-back' toggles between two generations, or goes way toward the past?
<Guest10>Hi, is the new package-input format as powerful as the old one?
<apteryx>it automates the labeling for you, so in some cases there could be multiple same labels
<Guest10>    (native-inputs
<Guest10>     `(("unzip" ,unzip)
<Guest10>       ("patch" ,patch)
<Guest10>       ("love-11.patch" ,(search-patch "mrrescue-support-love-11.patch"))))
<Guest10>I'd want to convert this (for exemple) to the new format
<Guest10>how can i do this
<Guest10>? (sry for the spam)
<apteryx>put search-path without the label
<lechner>hi, please consider using a pastebin like
<Guest10>ok got it thx
<apteryx>or better yet use it as a real patch in the origin
<mirai>apteryx: how can you “dereference” these non-package objects later?
<Guest10>well in my case that's not an option
<apteryx>mirai: you'd use search-input-file and friends usually; never tried finding a patch though
<mirai>say I want to do the equivalent of (assoc-ref inputs "the-patch-or-origin-thing") in some phase
<apteryx>when all else fails you can simply lower the object right into the build phases gexp
<mirai>arguably contrived but wouldn't it be liable to confusion? i.e. (inputs (list (whatever-resulting-in-catalog.xml) docbook-xsl))
<apteryx>Guest10: i'm curious; why is that not an option in your case? (to use the patch on the origin)
<mirai>(search-input-files inputs "catalog.xml") => docbook-xsl also has this file somewhere in its tree
<Guest10>because the origin of the package is supposed to be guix-agnostic whereas my patch is guix-specific
<apteryx>mirai: yes when the file is not unique then you must use something like (string-append #$(this-package-native-input "docbook-xsl") "/path/to/catalog.xml")
<mirai>Guest10: I think there's no big problem in using origin here (patch is reversible I think)
<Guest10>see comment in gnuzilla.scm, line 771
<mirai>The cases where origin can't be used is if you want to patch the source to something “dynamic”, like switching /usr/bin/bash with the path for guix bash package
<apteryx>is adding support to love-11 guix specific?
<Guest10>that was an exemple
<Guest10>my real use case if icecat
<mirai>apteryx: but that trick is only tenable if I'm referring to a package. What about the other case?
<apteryx>gexps can refer to files too, like patches
<apteryx>what are the other cases?
<mirai>say I have in a phase (let ((the-special-file (?? assoc-ref inputs "snowflake-1" ??))) …)
<mirai>or multiple inputs all with the same name
<mirai>for $reasons (inputs `( ("foo-manif" ,(download-foo-manifest.snowflake)) ("bar-manif" ,(download-bar-manifest.snowflake))))
<mirai>all are named manifest.snowflake
<mirai>and in a phase I need to preprocess each in a special way (so I need a specific way to disambiguate them)
<apteryx>I don`t know about the oddities, but lowering into the phases gexp seems it`d be easiest
<apteryx>so you can process them without an indirect reference in place directly
<mirai>so (add-after 'build 'whatever (lambda _ (some-proc #$(origin …)))) instead of specifying the (origin …) in the inputs?
<mirai>I've been thinking on doing a docbook unification for Docbook 4.x packages (in a separate series since the last one is already large)
<mirai>as I've read somewhere that many files in the SGML package are actually shared with the XML ones
<mirai>with a difference in the manifests/catalogs
<apteryx>mirai: a separate series sounds good :-D
<mirai>and some extra-files
<apteryx>especially with the current bug answering from Debbugs loosing the subject (patch number) it`ll hard to know what we`re replying to at patch number 60
<mirai>so I was thinking on something like docbook-4.2 providing both SGML and XML functionality though I'd likely need to fetch from “two” origins at least
<mirai>apteryx: yeah, and I have hourly limits on SMTP too 😅
<lucypoo>hope all are well today
<mirai>every revision to that one takes me 2 hours at least
<mirai>re debbugs: yeah, I've still yet to sort out & reply the SRFI-171 changes
<peanuts>"SRFI 171: Transducers"
<apteryx>mirai: did you get cc`d to the emacs bug I opened yesterday?
<apteryx>seems there's been some replies to it already
<apteryx>ACTION checks
<viaken>How do you add elogind to an install without including all of desktop-services?
<viaken>Oh, I just got it
<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:
<peanuts>"debian Pastezone"
<Guest10>so it seems with the new input syntax, there is no label anymore
<Guest10>or rather, the label is "_"
<Guest10>there should be a way to add a label
<phf>OK, apparently, it's done in
<graywolf>apteryx: So it is still building but I found ; we do not have the patch and it does not seem to be applied upstream. Would also explain why it builds the same on the same machine.
<peanuts>"1049186 python-3.6 packages do not build reproducibly"
<graywolf>Will let the --rounds=30 finish, but this lead is imho somewhat promising
<lechner>mirai / Hi, is your proposed solution re "Plan for NFS" really generalized enough? Should we differentiate between different file-system services instead?
<lechner>or maybe order them explicitly?
<mirai>ordering is done by dependencies
<mirai>which is handled by shepherd
<mirai>differentiate between file-systems makes it less general no?
<mirai>what scenario do you have in mind?
<lechner>actually, i think it's a problem of terminology. how about all-file-systems?
<lechner>and then file-system-/acct file-system-/srv or what the case may be
<denys>hello! the official mumi instance at seems stuck at Oct 01. is it a known issue? probably yes but i don't see anything on about it
<phf>For anyone interested, here how Guix makes Python to automatically load packages installed with Guix:
<peanuts>"debian Pastezone"
<lucypoo>hey there, i am new to autotools, mainly using meson where built file-s are contained within a single directory which can be ignored with .gitignore
<lucypoo>since autotools builds file-s in place in the directory tree, do people commonly use `make clean` before a commit, or are people specific with the `git add` command?
<Guest10>well you can either add those files to .gitignore (the best way imho) and then git add everything, or do specific git adds
<lilyp>vivien: if it got sent as v5, then sorry, it got sent :(
<vivien>lilyp, don’t worry about my mistake, it is of very little importance.
<vivien>The V5 is intentional!
<lilyp>Does v5 work in a vm?
<vivien>lilyp, if you """fix""" the dbus service with this hack
<peanuts>"debian Pastezone"
<graywolf>lucypoo: fyi I use something like this in most of my autotools projects:
<peanuts>"debian Pastezone"
<vivien>lilyp, and log in with XFCE (GNOME does not seem to load)
<lilyp>I think the gnome part is on us for not having vital system stuff ready yet.
<lilyp>Maybe instead of creating /var/run/dbus as above, we should just create /run/dbus now – have you tried that with xfce?
<vivien>I get booted off immediately when I log in
<vivien>So I guess not all dbus clients search in /run/dbus
<civodul>cbaines: looks like the bffe test occasionally fails:
<peanuts>"Build 2144510"
<lilyp>since this appears to be a glib thing, could we add a check there?
<lucypoo>@Guest10 ty
<civodul>rust-team x86_64 builds completed:
<efraim>civodul: looks like there's a few left
<civodul>not many
<efraim>gah computer froze again
<efraim>I'll have to see how it goes with so I can see the comparison vs master
<Noisytoot>Is there a fix for CVE-2023-4911 (Local Privilege Escalation in the glibc's in Guix?
<graywolf>Noisytoot: I am not aware of one (nothing commited that would seem to be related in gnu/packages/base.scm)
<nckhexen>(Seriously!? )
<peanuts>"IRC channel logs"
<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.
<ekaitz>efraim: ping
<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
<lilyp>cursed, i know
<lilyp>okay, what really confuses me about the glibc stuff is this:
<lilyp> GLIBC_TUNABLES is already considered unsafe for setuid binaries
<lilyp>how does it end up being used anyway?
<lilyp>like, surely, even without the buffer overrun, it's a hazard
<lucypoo>lilyp cheer
<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
<peanuts>"Consider dropping the X11 backend (#5004) · Issues · GNOME / gtk · GitLab"
<lilyp>can we graft glibc? it looks like a bunch of bootstrap packages are building regardless
<lilyp>ahh, but they're being substituted for now
<Guest10>if i want to find some token in a known file, with, say, some regexp, how can i do that in Scheme?
<lilyp>guile has (ice-9 regex)
<lilyp>alternatively, you can also use pegs
<civodul>lilyp: we can (and should) graft it
<civodul>are you looking into it?
<Guest10>thx lilyp
<civodul>another thing we could do is graft only setuid programs
<ulfvonbelow>what's a good way to find out "why" two derivations are different (that is, where they "diverge")?
<lilyp>guix graph maybe?
<lilyp>at some point, they have to point to different inputs
<lilyp>ludo: sent the mail, still building
<civodul>ulfvonbelow: one thing to keep in mind when you compare .drv is “fixed-output derivations”
<civodul>because of that several different .drvs can lead to the same output
<civodul>then, when i really need to diff them, i use Emacs + guix.el (for proper .drv formatting) + ediff
<ulfvonbelow>yeah, I've been using diff in emacs, but the different fixed-output derivations lead to a lot of false positives
<civodul>then it’s often clearer when you diff the *-builder files
<apteryx>could the data service help here?
<apteryx>assuming the package changes are already in master
<civodul>i don’t think it could be of any help
<civodul>rekado: hey! did you have a chance to look at kreuzberg?
<civodul>problem is we can’t “unplug” it from CI, so it keeps building things that eventually get thrown away
<nckhexen>Can't you bring down the wg tunnel?
<apteryx>mirai: if you 'guix pull', you'll get a fixed Emacs Debbugs with regards to preserving the subject on patches you review
<civodul>nckhexen: for just one host? i don’t think so (?)
<apteryx>civodul: I thought QA made comparing devirations possible graphically, but I don't know how to wield the tool much.
<Kolev>Should I install with the stable release or the dev. snapshot?
<graywolf>Kolev: usually you use the stable for installation and then upgrade to master right away.
<graywolf>Apparantly stables get more testing, so they are better for installations.
<graywolf>But they get no updates, which is why you update as a first thing
<podiki>lilyp: you have/testing a graft for glibc with (i'm guessing) this patch?;a=commitdiff;h=1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa
<peanuts>" Git - glibc.git/commitdiff";a=commitdiff;h=1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa
<mekeor>what justifies this emacs-related commit? i'd think patches are meant to make packages work. isn't this more like a personal preference?
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<graywolf>apteryx: just FYI:
<peanuts>"#66351 - Python build is not reproducible - GNU bug report logs"
<nckhexen>s/personal/project/ really. I'm not aware on any limitation on what patches may do.
<nckhexen>(The latter's more of an aside, I don't think anyone would deny this patch makes the package work.)