IRC channel logs
2023-10-04.log
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 <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 <rekado>in these two packages we provide custom noop implementations to bypass the use of pip <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. <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 <lucypoo>oh maybe my mailing list mails are failing as i am using attatchment-s <gnucode>lucypoo: I might recommend the arc email client <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. <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") <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? <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>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>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! <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! <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 <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>Could a bug-guix@gnu.org moderator reject my email? <vivien>It would be a lot better if it could be rejected <vivien>Before someone accidently allows it ^.^ <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) <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? <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>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>our guile package also differs by only one file: /lib/guile/3.0/ccache/ice-9/ftw.go <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. ci.guix.gnu.org 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>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>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> ("love-11.patch" ,(search-patch "mrrescue-support-love-11.patch")))) <Guest10>I'd want to convert this (for exemple) to the new format <lechner>hi, please consider using a pastebin like paste.debian.net <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? <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 <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 <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 😅 <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 <apteryx>mirai: did you get cc`d to the emacs bug I opened yesterday? <apteryx>seems there's been some replies to it already <viaken>How do you add elogind to an install without including all of desktop-services? <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/ <Guest10>so it seems with the new input syntax, there is no label anymore <Guest10>there should be a way to add a label <phf>OK, apparently, it's done in sitecustomize.py <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? <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 issues.guix.gnu.org seems stuck at Oct 01. is it a known issue? probably yes but i don't see anything on logs.guix.gnu.org about it <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>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 <lilyp>since this appears to be a glib thing, could we add a check there? <efraim>civodul: looks like there's a few left <efraim>I'll have to see how it goes with qa.guix.gnu.org so I can see the comparison vs master <Noisytoot>Is there a fix for CVE-2023-4911 (Local Privilege Escalation in the glibc's ld.so) in Guix? <graywolf>Noisytoot: I am not aware of one (nothing commited that would seem to be related in gnu/packages/base.scm) <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 <lilyp>okay, what really confuses me about the glibc stuff is this: <lilyp>how does it end up being used anyway? <lilyp>like, surely, even without the buffer overrun, it's a hazard <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 <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>alternatively, you can also use pegs <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>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>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 <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 <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.)