IRC channel logs

2021-11-15.log

back to list of logs

<podiki[m]>rekado: same as this report I think? https://issues.guix.gnu.org/51837
<KE0VVT>thanks vivien sadly no apps written in guile-gi
<vagrantc>what should go to core-updates-frozen vs. core-updates-frozen-batched-changes vs. core-updates ?
<vagrantc>looks like this would rebuild ~10k packages
<vagrantc>probably why it's in core-updates*
<vagrantc>but seems like you really want to have that before merging into master, otherwise you have to do another world-rebuild before making a release...
*phodina[m] posted a file: way (3KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/hzoWVjdEriXAsRESQyAneEIC >
*vagrantc guesses core-updates-frozen-batches-changes
<KE0VVT>Cannot run guix package 'nomad': https://paste.centos.org/view/82c1631b
<podiki[m]>vagrantc: don't think -batched-changes exists anymore, it was merged into -frozen
<podiki[m]>and -frozen should just be getting fixes to make it ready for master at this point; so unless it is a fix for that, probably needs to go into regular core-updates for the next cycle
<vagrantc>well, won't be able to release without fixing it, and not fixing it means waiting till *another* core-updates release to fix it ... so ...
<vivien>I can’t wait for core-updates-frozen to be merged into master :)
<vivien>Literally: I switched to core-updates-frozen
<vagrantc>given folks were talking about september for a 1.4 release ... i think it would be nice to release.
<vagrantc>well, there's plenty of material for new typo poems
<vivien>Thanks to apteryx, we now have -batched-changes merged into core-updates-frozen. This merge left a few GNOME packages to fix, but I see rekado is doing a great job there.
<vagrantc>there are things in core-updates-frozen-batched-changes that are not in core-updates-frozen
<vagrantc>216 patches, looks like...
<vivien>-batched-changes does not exist anymore upstream, does it?
<vagrantc>i'm not sure what you mean, all my recently updated git repositories have origin/core-updates-frozen-batched-changes
<vagrantc>and they contain patches not present in core-updates-frozen
<vivien> https://git.savannah.gnu.org/cgit/guix.git/refs/
<vivien>Maybe it was rebased before the merge?
<vivien>I do not see a merge commit, so I guess it was a rebase.
*vagrantc pushes to core-update-frozen-batched-changes
<vagrantc>hrm. git push ... resulted in ... remote: fatal: bad object 0000000000000000000000000000000000000000
<vagrantc>but, seems to have worked...
<vivien>Are you trying to revive core-updates-frozen-batched-changes?
<vivien>Ah yes
<vagrantc>vivien: i don't know what you mean by revive, it's there, it has changes not merged ...
<vivien>vagrantc, which one for instance?
<vivien>(except your new one)
<vagrantc>git log1 origin/core-updates-frozen..origin/core-updates-frozen-batched-changes shows 216 patches ...
<vivien>I think those were rebased on top of core-updates-frozen
<vivien>For instance, "gnu: conan: Update to 1.42.0." is on core-updates-frozen as ccebbaa5170dc250ceb8810d1baa331a7f0b9952
<vagrantc>ah, i see, yeah.
<vivien>So, maybe you want to push directly to core-updates-frozen
<vagrantc>i guess so ...
*vagrantc checks again
<nckx>vagrantc: I see you've recreated a new c-u-f-b-c branch.
<nckx>What's this one for?
<vagrantc>it was there, i swear
<nckx>Oh? Hmm…
<vagrantc>the top-level commit in it i'm working on checking if i can push it to core-updates-frozen, as all the other patches that were there are apparently present in core-updates-frozen as rebased patches
<vagrantc>sent a mail to the list about it, hopefully can follow-up with "i went ahead and pushed to core-updates-frozen, that's going to trigger ~10k rebuilds, wheee"
<nckx>If it existed you would have had to delete it first.
<nckx>IIUC.
<vagrantc>i never deleted anything.
<nckx>Savannah blocks force-pushes, no?
<vagrantc>so maybe someone else pushed it?
<vagrantc>and i just pushed on top of it
<brendyn>when i refresh some packages it tries to download a signature and then asks me if i want to add a key to a keyring but then it is not possible to enter 'y' so it just fails
<nckx>vagrantc: It was deleted on Thursday: https://lists.gnu.org/archive/html/guix-commits/2021-11/msg02220.html
<nckx>If it was recreated somehow there's no log of it, and at least Savannah thinks you created it from scratch: https://lists.gnu.org/archive/html/guix-commits/2021-11/msg02349.html
<vagrantc>nckx: i got it via git-fetch ...
<vagrantc>nckx: ... anyways ...
<vagrantc>weird.
<nckx>No big deal as long as it was deliberate, I was just surprised to see it resurrected.
<nckx>IWBN to start reducing the number of c-u branches soon ☺
<vagrantc>it wasn't deliberate to recreate it ... but i repeatedly checked that my branch was up-to-date with what was on savannah before trying to push
<vagrantc>nckx: agreed, there's no real reason for it if all the patches are merged
<nckx>Right.
<vagrantc>i checked from two different computers, actually :)
<vagrantc>very confusing.
<nckx>I believe that you saw what you saw, I'm just not sure what you saw ☺
<nckx>Git!
<vagrantc>time to switch back to RCS
<vivien>nckx, if you mean to merge core-updates-frozen into core-updates, that won’t be very exciting.
<vagrantc>core-updates has continued to have lots of updates, as i understand it?
<nckx>vivien: Should it be?
<drakonis>activity dwindled a whole lot inside core-updates
<vagrantc>lots, meaning maybe ~40
<drakonis>while the majority of work went into core-updates-frozen
<nckx>vagrantc: I don't know about a lot, but yes, that was the point of the (newish) c-u/c-u-f split. It being always summer in c-u proper, unlike previous releases.
<vagrantc>summer?
<vivien>Does that mean, not frozen?
<vagrantc>well, hopefully we've learned something...
<vagrantc>confusion is king!
<nckx>So whilst, yes, the ‘focus’ was to bang c-u-f into releasable shape and that took a lot of work (probably more than expected, which it always has, so that was expected), the usual routine c-u bumps would just go to c-u. Less chance of introducing new bugs that way.
<vagrantc>and people don't consistently run "guix lint" ... that was my real lesson for the day ... everything from typos to broken packages deep on the dependency chain
<nckx>Oh, is that not a common expression?
<nckx>“The article on the dot discussed the development process where "It's always Summer in trunk". I don't know who coined that expression, but it's a nice one. I think it appeared in the KDE circle in a blog by Sebastian Kügler: he asked the question "What if we never froze trunk?"”
<nckx>I know it mainly by whay of Exherbo back in the day, IIRC.
<vagrantc>i get it, but it required some explaining :)
<vagrantc>the contrast between frozen and summer, basically...
<nckx>I thought it was more common than it is.
<vagrantc>i might have nice rocks to hide under :)
<nckx>Yeah, it contrasts with our previous workflow, which was ‘sometimes c-u freezes, and everybody needs to be told this because it's very important, so we send (if that!) a mail to some ML, so a few people know this, so only a few keep pushing to c-u, which only creates a few head-aches; then after a while c-u unfreezes and we communicate that out-of-band in a very missable way, too, then repeat’. Doing it in-band in git just makes so much more sense.
<nckx>Which branch is frozen? Oh the one with frozen in the name. Is c-u frozen? No, it never is.
<vagrantc>what's unclear to me is what *can* go to frozen ... i think a "make dist" breaking change probably, so ... uh, i'll push soon :)
<vagrantc>ok, pushed ...
<nckx>vagrantc: They cannot go to frozen but someone forgot to tell the bug that. It happens. But it's the reason that ‘bump package x only because number go up’-style changes do *not* belong on c-u-f. Only bugfixes. These can introduce new bugs, as you found out, but hopefully fewer.
<nckx>vagrantc: Thanks!
<nckx>(And maybe it was broken before the freeze? I dunno.)
<vagrantc>it was broken by b20b45c6ce67593db9d446d066e02310671ad8d7
<vagrantc>timestamp from march
<vagrantc>so, probably broken a long time
<vagrantc>for things like patch file length, maybe we need that to go into the pre-push script too
<vagrantc>i think the guix lint check is more conservative than you can get away with .... it doesn't fail until you run "make dist"
<vagrantc>but if people respected the guix lint check ... it would be a non-issue
<nckx>So the pre-push hook should run guix lint and refuse to continue if there's output?
<vagrantc> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/lint-warnings?locale=en_US.UTF-8&package_query=&linter=patch-file-names&message_query=long&field=linter&field=message&field=location
<vagrantc>shows numerous ones that guix lint reports, but "make dist" still works
<vagrantc>nckx: guix lint has some false positives, so i don't think that would be good
<vagrantc>nckx: but maybe some checks are easy to be confident of, e.g. patch file length
<nckx>Heh, guix lint | grep stuff, go full unix.
<vagrantc>admittedly, i don't actually use the pre-push hook, i just manually run the commands as ... my "git push" environment is not the same as my guix development environment
<nckx>vagrantc: Why doesn't ‘make dist’ fail with false positives then? It's still running here.
<vagrantc>nckx: i suspect that the guix lint check has a smaller limit than, say, tar.
<nckx>It just died.
<nckx>Oh, it's tar.
<vagrantc>tohjy
<nckx>Huh.
<vagrantc>hah, keyboard shift ... i meant to say "right"
<nckx>I'd already tried rot13 and was at wit's end.
<nckx>I had no idea tar was so ridiculously fragile.
<kittyblam>Yo, I am trying to package Yafaray, ran into some issues and eventually just looked at a .nix of it and notice it has NIX_CFLAGS_COMPILE+=" -isystem ${ilmbase.dev}/include/OpenEXR"
<kittyblam>how could I go about doing that in guix?
<kittyblam>I feel this should be quite obvious so help would be appreciated xD
<vagrantc>nckx: maybe there are some tar extensions that could allow for longer filenames ... but who knows what compatibility issues that might bring
<brendyn>cant see why qgpgme fails t-encrypt test on core-updates-frozen now
<vagrantc>ok, so the whole problem that send me on this "make dist" rabbit hole ... was to check if newer versions of guix build ok on Debian's i386 ... which, not having luck so far.
*nckx throws some more wood on the fire, yawns apologetically, and wishes you all a warm night.
<vivien>I have an electric heater, the problem is it only works when there’s a world rebuild on guix.
<vagrantc>well, my push to core-updates-frozen ought to warm you up tehn
<vivien>Thank you :)
<vivien>Joke aside, getting make dist to work is a good thing.
<vivien>Did you try make distcheck?
<vagrantc>vivien: i haven't! :)
*vagrantc runs now
<apteryx>vagrantc: you may be interested in running 'git fetch --prune', to clear remote refs that no longer exists. My magit is configured to do so always.
<podiki[m]>I haven't dared guix pull on core-updates-frozen for a while, hoping I can do that soon (and report any bugs I hit :-))
<vagrantc>apteryx: ah, that sounds like a plausible issue
*apteryx would like to fix the pesky "> Warning: Could not resolve keysym XF86Macro20" xorg warnings
<apteryx>or xkbsomething
<apteryx>you'll see them when running the test suite of ibus, for example
<apteryx>(on core-updates-frozen)
<apteryx>vagrantc: I'll group some big changes for core-updates-frozen with yours; so I've cancelled the evaluation; it'll build together when I push
<vagrantc>apteryx: ok, hopefully i haven;t made a mess of things! :)
*apteryx is getting the mutter test suite to run
<vagrantc>oh lovely 70f619d8921e70ab0e4a61d336fa9c4332014b88 :)
<vagrantc>well, nice guixing with y'all ... i'm off!
*vagrantc waves
<steggy[m]>👋 I'm looking at fixing up the fish shell package, and I was curious what the protocol around using propagated-inputs is. I think it makes sense to add e.g. coreutils(for cat/ls/etc) and ncurses(for clear) to the inputs, especially as doing substitute*'s on the functions defined in fish can be hairy, but wanted to know if that would be generally acceptable or if I should put my regexp'ing hat on and get to work on that approach. Also open to
<steggy[m]>"both of those are wrong do this third thing"
<steggy[m]>To be clear, right now e.g. `clear` isn't packaged with fish, and so if you don't have ncurses installed as I didn't, you'll set a very sad message about not being able to find clear if you try to C-l. This is what I'm hoping to address by ^
<apteryx>does fish use clear internally?
<apteryx>if not, it should be up to the user to install it manually (put it on their PATH), as is currently the case for e.g., bash
<apteryx>but since you're mentioning patching fish, I guess it does refer to these internally
<steggy[m]>It does in the sense of "it binds control-l to a function which wants clear to be executable"
<apteryx>I see! Yeah, I think it makes sense then, as that must be a common thing people use there
<apteryx>but in Bash and other shell, isn't that taken care of by GNU readline already?
<jgart>steggy[m], apteryx http://issues.guix.gnu.org/51538#10
<apteryx>or I forgot whom
<jgart>see that thread also regarding ncurses and clear
<apteryx>C-l clears the screen without a need for 'clear' with Bash at least
<steggy[m]>Haven't dug much into the fish internals for why it strictly needs it, but e.g. https://github.com/fish-shell/fish-shell/blob/master/share/functions/__fish_shared_key_bindings.fish#L91 is it just calling on out to it
<jgart>yup it looks like that is a direct call to the `clear` binary
<steggy[m]>fwiw jgart not sure that applies? I kind of generally agree that I wouldn't put it in a general cookbook, but in this particular case it seems necessary for this to work as expected
<jgart>Ideally `clear` and Ctrl+L would just work like most distros
<jgart>s/Ctrl + l
<apteryx>steggy[m]: if you patch it in fish and 'it just works' as fish users would expect, then you don't need to document anything
<steggy[m]>jgart: Yeah that's my hope/intention here - I was pretty surprised when I saw it print a sad
<jgart>Yup no need to document clear because it'll just work as is expected
<steggy[m]>apteryx: okay so that's a reasonable/good use of propagated-inputs and I won't get my knuckles rapped if I submit that?
<apteryx>no propagation; it's better to refer to clear explicitly
<apteryx>propagated-inputs are susceptible to clash together
<apteryx>(in a profile)
<jgart>apteryx, inputs?
<apteryx>inputs yes + substitution in a phase (with substitute*)
<steggy[m]>I could pull it in inputs and put a lot of substitute*'s - that was my original plan though it got messy pretty quick
<jgart>and by string-appending a path to the `clear` executable in the store
<steggy[m]>gotcha, doing something like ```(substitute* "share/functions/__fish_shared_key_bindings.fish"
<steggy[m]> (("clear") (string-append (assoc-ref inputs "ncurses") "/bin/clear")))```
<apteryx>yeah
<jgart>yup
<steggy[m]>So, I can do that - I feel a little bad for not doing the same for e.g. coreutils(which I already have installed on my profile), because it's also explicitly referenced
<jgart>is that the only place it shows up?
<steggy[m]>but finding the right boundaries on those substitute*'s is making my head spin
<steggy[m]>for clear, thankfully, yes
<jgart>do you check them after the build in the store path?
<jgart>that way you can see what it patched
<steggy[m]>yep!
<steggy[m]>Here's what I've been looking at doing ```(let ((coreutils (assoc-ref inputs "coreutils"))... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/212d54c071477f64aa24605b46276cbec6e04c06)
<steggy[m]>(okay this feels like there has to be a better way to get a snippet out here)
<jgart>when I start getting a ton of these "newer than compiled /home/jgart/8dd9f159-8457-4c3a-921f-11b21e535d5d-guix/gnu/packages/python-build.go"
<jgart>what should I do?
<jgart>./bootstrap && ./configure --localstatedir=/var && make
<jgart>should I be doing all three steps again to clear up the guile object files?
<jgart>Or, is there something else I should do?
<jgart>guix build: error: derivation `/gnu/store/a7bqi8y0xsl5wqms3lp0ffvrspypi8db-fennel-1.0.0.drv' may not be deterministic: output `/gnu/store/il3vaqhy5m81186cp4v9b71z2b8j1ihk-fennel-1.0.0' differs
<jgart>what is that usually a sign of?
<lilyp>nondeterminism
<lilyp>use diffoscope to check what exactly is different
<lilyp>jgart: make clean-go cleans the go
<jgart>lilyp, thanks!
<jgart>lilyp, what do I do after running `make clean-go`?
<jgart>`make` again?
<jgart>or `make clean-go` takes care of rebuilding also...
<lilyp>either that or just add all as second target
<jgart>do I need to add some input to `guix shell` for that to work?
<dragestil>given we have icecat packaged is there a reason abrowser is not available as a package?
<jgart>warning: stray .go files: ./guix/build/po.go
<jgart>I get the above warning after running `make clean-go`
<jgart>should I just ignore?
<lilyp>it won't be used by the current guix build, but you might find it ugly remaining
<lilyp>just rm it if it nags you
<jgart>ok
<jgart>thnx
<lilyp>dragestil: probably no one doing the work of packaging some huge browser twice :P
<dragestil>hmm i wonder whether the definition of the two would be very different
<jgart>falkon might be nice to have
<jgart>I'd rather work on that than abrowser
<dragestil>but it's chromium
<jgart>I think trisquel packages it
<dragestil>yeah that's where abrowser comes from :)
<jgart>and it's way lighter than icecat
<jgart>falkon runs smoother/faster than chromium and icecat/firefox
<jgart>it's a lighter browser
<dragestil>but falkon uses webengine
<jgart> https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/applications/networking/browsers/falkon/default.nix#L51
<jgart>QtWebEngine based cross-platform web browser
<dragestil>it uses blink
<jgart>Does ungoogled-chromium use blink also?
<dragestil>probably
<jgart>I'd rather use falkon than ungoogled-chromium
<jgart>qutebrowser can be updated
<dragestil>i'd rather not use anything with blink / webkit
<jgart>maybe time is best spent on qutebrowser
<jgart>likewise, but if I need to use it then falkon might be better than the others
<dragestil>qutebrowser is also webkit / blink
<jgart>how about luakit?
<jgart>or nyxt?
<jgart>or surf?
<dragestil>nyxt too, webkit / blink. it's hard to degoogle, unfortunately
<dragestil>i'm using degoogle in a broad sense, as in not in any way contributing to google dominance in browser
*jgart launches lagrange and stares into the void
<jackhill>dragestil: this probably isn't the right forum for this discussion (we should package all free software for guix!), but I am curious to learn more about how webkit gives google more leverage? My impresion is that they're being pulled along in a game of catch-up like everyone else.
*jackhill worries about how quickly bug/security fixes can be backported to qtwebengine (in addition to the other problems)
<jackhill>I will say that my impression to this point of webkit has been good: project with multiple stakeholders, comparatively easy to build compared to the other browsing engines, and appears to be easier to build novel browsers on top of compared to gecko/servo.
<kittyblam>the web and the corporations that break it fundamentally need to die, but thats better for another chat at another time lol
<jackhill>kittyblam: yeah, I'm with jgart in staring off into the void :)
<kittyblam>yeah lol, I have a lot to say but it would get heavily into copyright and politics xD in other news I need to work more on trying to package that one thing ... I know it should be obvious but still can't figure out whatever the guix version of the thing being done in nix was...
<jgart>kittyblam, what are you working on?
<jackhill>kittyblam: I've only looked at it for about 30s, but it seems like it has to do with passing the path to get it to build with a packaged version of a library rather than a bundled one. Probably something with setting configure/make flags and (assoc-ref inputs …) would be my guess
<jgart>Interesting.... I just tried to install a package to my profile from within a guix container and it blew away my default profile
<kittyblam>jgart: Yafaray
<jgart>can you post a link?
<kittyblam> https://github.com/YafaRay/libYafaRay
<jackhill>jgart: that sounds like something we wouldn't want to happen without printing a warning. At least you can roll back the change :)
<jgart>jackhill, yup that's what I just did :)
*jgart rolls back like it's generation 1995
<dragestil>jackhill: thanks. maybe you are right. i gotta look more into it
<jgart>kittyblam, do you know what's missing from yafaray in guix?
<jgart> https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/graphics/yafaray-core/default.nix#L30
<kittyblam>jgart: the problem I am having seems to be coming from the lack of having the guix equivelant of
<kittyblam> preConfigure = ''
<kittyblam> NIX_CFLAGS_COMPILE+=" -isystem ${ilmbase.dev}/include/OpenEXR"
<kittyblam> '';
<jgart>jackhill, I'll send a bug report
<kittyblam>or I meant like
<kittyblam>lack of knowing what it is to have in my thing lol
<jgart>jackhill, https://issues.guix.gnu.org/51859 Any review/testing much appreciated
<jgart>s/review/code review
<jgart>kittyblam, have you tried " rg isystem -t lisp"
<jgart>or just grep -R
<jgart>there's a few hits
<jackhill>jgart: cool re: fennel update. I'll try to take a closer look tomorrow. Also cool that fennel's now at 1.0.0!
<kittyblam>I've never heard of this rg command
<jgart>jackhill, I just got some fennel in my editor: https://git.sr.ht/~jgart/dotfiles/tree/master/item/private_dot_config/vis
<jgart>rewrote a vis editor color theme in fennel also. I have to refactor it now to use (collect [k v (pairs styles) :into lexers] k v)
<jgart>kittyblam, ripgrep
<jgart>It's grep written in rust
*jgart YOLO
<jgart>It's quite nice actually
<jgart>I use it sometimes in emacs also via deadgrep
<kittyblam>ah
<jgart>kittyblam, would #:configure-flags not be enough?
<jgart>I think you might be able to add it there
<kittyblam>jgart: I'm extremely new to packaging, all I know is that
<kittyblam>hmm
<kittyblam>one momento
<jgart>grep for isystem to see examples
<jgart>I mean grep in the git checkout of guix's src code
<jgart>in case that is not clear
<jgart>Also, I host a Guix packaging meetup on the last Saturday of every month
<jgart>feel free to come by and package in a group setting
<jgart>I usually announce it on the guix devel mailing list
<jgart>We've been packaging stuff as a group since January.
<kittyblam>back
<kittyblam>jgart: ah thats quite neat, I've never really touched mailling lists before I will have to figure that out lol, i might have to check that out as even once I am done with figuring out this (I believe last) piece of the puzzle of packaging yafaray I def have a few more projects (especially rendering engines) I am wanting to work on lol
<jgart>if you want, post some pastes here of yafaray package as you work on it and we can give tips on it
<jgart>like that you don't get stuck on it for too long if it happens
<kittyblam>ye thanks uwu, I made that mistake already and have just been off and on coming back to this, pretty excited that recently its almost working and it now seems very easy to understand apart from still being a bit lost on this - if the nix package is of any indication - last signifigant change that needs to be done to get it working I imagine
<rekado>apteryx: commit 781f475bbac4e73848f68cb9f420a7283ec17c16 is problematic for installing Gnome systems because different variants of at-spi2-atk end up in the same profile.
<abrenon>good morning guix
<bitspook[m]>Morning!
<florhizome[m]><abrenon> "good morning guix" <- morning :)
<abrenon>: )
<rekado>the problem with vigra is this: https://elephly.net/paste/1636965610.bz2.html
<rekado>the tests fail because Boost Python argument types did not match C++ signature.
<rekado>there is no more recent version of vigra out there.
<civodul>Hello Guix!
<civodul>rekado: that's on core-update-frozen, right?
<rekado>apteryx: the vigra problem is likely due to the boost upgrade in 68ce9c38848982b53b41d1c6bb44eafb78d981b9
<rekado>civodul: yes
<rekado>my list of broken stuff: vigra (-> libreoffice), pdfpc, and python-notebook
<rekado>oh, and gnome due to a propagation conflict
<qzdlns[m]>hi guix!
<lenny>Hi, is anybody working on updating rust? guix lint rust says there is a possible cve in the version that is currently available
*civodul kills gc again on berlin
<civodul>lenny: i believe the "core-updates-frozen" branch, which should be merged "anytime now", has a newer version
<civodul>rekado: when does that propagation conflict arise?
<civodul>i remember vivien and/or jpoiret (?) reporting that GNOME works for them on core-updates-frozen
<jpoiret>very lightly tested on my part, but gnome 40 looked like it was working well (with wayland on though)
<civodul>ok, thanks
<jpoiret>lenny: Isn't that the trojan source cve? updating rust is quite costly
<vivien>It does not work right now
<vivien>There are problems due to the recent merge of c-u-f-b-c
<vivien>Hello guix :)
<civodul>o/
<civodul>oh so something broke?
<civodul>damnit
<vivien>I’d like to have gnome-tweaks, devhelp and vala-language-server fixed
<vivien>(at least, these are blocking my home reconfigure)
<vivien>(at least these 3, they are blocking my home reconfigure, I don’t know of others yet)
<vivien>That’s 51731, 51808 and 51812 in terms of guix issues :)
<civodul>didn't the gnome-tweaks changes you posted get pushed?
<civodul>ah
<civodul>thanks :-)
<vivien>(to be honest, vala-language-server is a recent addition, I don’t know if it worked before the -bc merge)
<lenny>jpoiret: cve description: "library/std/src/net/parser.rs in Rust before 1.53.0 does not properly consider extraneous zero characters at the beginning of an IP address string, which (in some situations) allows attackers to bypass access control that is based on IP addresses, because of unexpected octal interpretation."
<lenny>i think there were also some updates that make compilation faster (i don't know about compiling the compiler though)
<jpoiret>oh, alright! might be a candidate for grafting, but I am not knowledgeable on this front
<jpoiret>civodul: about what you told me yesterday, what exactly is blocking launching the installer image with `guix system vm`, apart from the fact that we need space at the end to use the store?
<jpoiret>the first part of the installer should work fine
<rekado>vivien: I had already fixed gnome-tweaks
<vivien>Oh?
<rekado>vivien: commit 4c4f982c339750c3da5a6073d6fd5874b33c1a3d
<rekado>civodul: it happens when building a gnome system. The conflict is between the gnome package and network-manager-applet
<rekado>they propagate different variants of the same package.
<rekado>I think we can fix this by not propagating the -minimal variant and carrying it where it’s needed manually
<vivien>rekado, you indeed fixed the build, but in order to run, it requires libhandy 1 and a wrapped python path, which is mostly the goal of my patches (plus, as a suggestion from lilyp, get rid of libhandy-0 where I can, which is in seahorse)
<civodul>vivien: i'm testing these gnome-tweaks patches
<civodul>will push shortly!
<civodul>well, looks like there's a whole bunch to build still...
<efraim>I proposed a patch to add librsvg-minimal, but I might be hunting down and creating rust-libfoo-0.x-frozen packages instead
<efraim>s/-minimal/-bootstrap/
<civodul>s,-frozen,/fixed, per existing convention :-)
<civodul>but yes, if it's feasible without duplicating tens of packages, that'd be great!
<rekado>oof, I made the mistake of rebooting. Now I get lots of crashes, GLIBC 2_33 version errors and all that.
<rekado>vivien: oh, thank you
<rekado>I’m not happy with webkitgtk-with-libsoup2; this shouldn’t exist.
<rekado>I wish we could get rid of propagation somehow :-/
<efraim>I really wanted -for-core-updates and not -for-librsvg and not -fixed-in-place
<vivien>rekado, GLIBC 2_33 errors happen to me when I’m running a c-u-f guix home on a master guix system
<efraim>that sounds not unexpected
<rekado>vivien: it’s odd because I thought that *was* a c-u-f system ¯\_(ツ)_/¯
<vivien>rekado, maybe you have a rogue unattended upgrade service?
<rekado>nah
<rekado>(for a long time I didn’t have enough disk space for that sort of thing, so I never set it up)
<rekado>but there’s a complication: I’m operating this librem 13 blindly during early boot.
<rekado>(the latest firmware causes the display to freeze until the disk has been unlocked and linux finishes booting)
<rekado>(the previous firmware causes the display to flicker and violently jump around…)
<rekado>so maybe I booted the wrong system
<pkill9>does anyone use the signal messenger flatpak?
<civodul>vivien, rekado: what GLIBC_2_33 messages do you get?
<rekado>I rebooted already (because I had to have a working chromium for a meeting), but I can provide the exact message later.
<vivien>As for me: I don’t remember exactly, and replicating the issue requires me to reboot, which is inconvenient at that time.
<rekado>something like this: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/px2h9zci8dmwi55xqbd732mbm8wpiims-libproxy-0.4.17/lib/libproxy.so.1)
<rekado>I think one of the problems might be that gnome-shell still sets LD_LIBRARY_PATH
<rekado>we have a bug report about this, and I should have removed LD_LIBRARY_PATH (because I added it years ago), …
<rekado>this is what gnome-shell sets up globally: LD_LIBRARY_PATH=/gnu/store/vpwvgnjzpnan4nzbl75lvwbi13nlkydv-gdk-pixbuf+svg-2.42.4/lib:/gnu/store/ml5njpw1ggdk28ix4hginh3bs9rpacw3-gnome-bluetooth-3.34.5/lib:/gnu/store/p4ljkxzc88xz666d795g8acgr7ij3yrn-librsvg-2.50.7/lib:/gnu/store/6xabiy5r3a84gh7nz8mvwr811abwkwh2-libgweather-40.0/lib
<rekado>it’s generally a bad idea.
<civodul>ah yes
<civodul>setting LD_LIBRARY_PATH voids your warranty :-)
<civodul>but yes, i remember gnome-shell had to do that
<civodul>i think i even tried to find another way to address it
<rekado>I’m not sure it’s still needed.
<civodul> https://issues.guix.gnu.org/37123
<rekado>not great that we void every gnome user’s warranty by default :)
<civodul>right :-)
<civodul>can we easily test whether removing it is fine?
<civodul>it = the LD_LIBRARY_PATH setting
<rekado>I guess we would just reconfigure with that change and see if it starts.
<rekado>I would do that if I could build my system on c-u-f
<rekado>which I can’t because of the collision between inputs of gnome and inputs of network-manager-applet.
<civodul>rekado: what if we make that change and try in "guix system vm"?
<civodul>how we would notice if it's broken?
<rekado>I think it was a very simple problem: gnome-shell just didn’t start at all.
<lenny>hi, i tried to update the package taskwarrior to the newest version. I used pre-inst-env from the git repo and modified the package definition. But if run task --version i still get 2.5.3. When building manually i don't get this. What could i have done wrong?
<rekado>it’s a cheap change; if it turns out to break things in unexpected ways I’d say we just address it then.
<rekado>bleh, I need a more recent matplotlib for a bioinfo package :-/
<rekado>I’ll go ahead and build a custom manifest for the user.
<rekado>can’t wait for c-u-f to be merged
<rekado>lenny: did you use “./pre-inst-env guix install taskwarrior”?
<lenny>yes
<vivien>lenny, you need to change the sha256 checksum for the input.
<vivien>Did you do that?
<lenny>I changed it to the output of guix download with the newest release tar
<lenny>Oh no! apparently i didn't. My editor must have overridden my clipboard when i removed the old hash. Still, i'm wondering why it didn't fail when the downloaded version did not match the hash. It simply installed the previous version
<vivien>lenny, yeah, if it sees a hash it already knows, guix won’t think twice about the version number
<civodul>efraim (+ zimoun): is this Julia patch on your radar? https://issues.guix.gnu.org/51243
<civodul>vivien: pushed https://issues.guix.gnu.org/51731! making progress...
<vivien>civodul, thanks!
<lenny>is there another way to get the latest rust version for development? Maybe a channel?
<cehteh>lenny: i created a debian VM for that :/
<florhizome[m]>oh cool there is a waydroid commit \o/ http://issues.guix.gnu.org/51737
<M6piz7wk[m]>+- 16 hours and it's still at 53%
<vivien>M6piz7wk[m], what are you building again?
<M6piz7wk[m]>guix pull after the initial installation on 1Ghz notebook
<M6piz7wk[m]>says it's doing guix-packages-base.drv
<vivien>Oh
<M6piz7wk[m]>i suspect it being stuck at 53% for some reason as the percentage should be moving right?
<M6piz7wk[m]>the load indicator is reacting though
<M6piz7wk[m]>so it seems to be doing something
<vivien>Guix got a faster compiler since 1.3.0
<M6piz7wk[m]>i got the latest guix installer
<M6piz7wk[m]>didn't see any version specified in it
<vivien>The installation image is pretty old
<vivien>I think you can recreate it
<M6piz7wk[m]>even latest?
<vivien>That’s section 3.9 Building the Installation Image in the manual
<vivien>I don’t know whether that will help you
<vivien>You still have to face the dilemma
<M6piz7wk[m]>How do i verify that making the installation image is beneficial for my situation
<vivien>Should you cancel 16 hours of compiling because some other method might speed it up?
<vivien>I don’t know
<vivien>If the installation fails, you could try with an updated iso
<vivien>I wouldn’t risk aborting now though
<M6piz7wk[m]>i am just uncomfortable thinking that it's doing something like fatal error message in an infinite loop
<M6piz7wk[m]>someone said that it took them 24h to build on similar device yesterday
<M6piz7wk[m]>bcs the percentage is not moving
<M6piz7wk[m]>but i guess the percentage is hard to implement to move when it's waiting for the non-guix compiler to do the work
<rekado>I’m getting an error with scanpy, which uses numba caching: “cannot cache function 'sparse_mean_var_minor_axis': no locator available for file”
<rekado>the internet tells me that I should disable zip compression when installing the package
<rekado>any ideas how to accomplish this for scanpy?
<roptat>M6piz7wk[m], I also noticed the progression bare on base-packages (and others) is stuck, but work is still happening in the background, it'll jump to a higher percentage later...
<roptat>bar*
<M6piz7wk[m]>roptat: thanks that mane me calmer
<roptat>as long as you can see in top it's doing something, you should be good
<roptat>although 16 hours is pretty long
<M6piz7wk[m]>we can't do anything about the progression bar right? There is no way to e.g. show how long it's assumed to take and more accurate percentages?
<roptat>the percentage is supposed to be related to the number of files
<M6piz7wk[m]>the scheduler is overwhelmed i can't log-in
<roptat>but like I said, it doesn't update frequently, I don't know why
***yewscion is now known as Guest2857
***yewscion98 is now known as yewscion
<roptat>oh, maybe you don't have enough memory?
<M6piz7wk[m]>possible
<M6piz7wk[m]>i tried TTY and entering my name results in blinking dot instead of request for password
<M6piz7wk[m]>so to me that looks like overwhelmed scheduler
<roptat>in that case I think it might actually be stuck
<M6piz7wk[m]>this is normal behavior for this system though
<roptat>ah?
<M6piz7wk[m]>assuming that guix comes with CFS scheduler
<M6piz7wk[m]>which sucks at handling 1 core operations
<efraim>civodul: yes, #51243 is probably necessary but I don't relish having to build out julia and some packages to make sure everything works afterward
<rekado>M6piz7wk[m]: out of memory perhaps and using swap?
<M6piz7wk[m]>rekado: the installer didn't create swap that i know of
<M6piz7wk[m]>it should have enough memory though i compiled firefox on it once
<M6piz7wk[m]>and like it's reacting to input so it's not halted
<jbv1[m]>efraim: (I wrote the patch) it is not super urgent, maybe it can be bundled with the update of julia to 1.6.4 (due soon) or with 1.7 that will arrive later
<roptat>never seen guile actually use swap when building guix...
<M6piz7wk[m]>is the guix-packages-base actually using guile compiler?
<roptat>but it also happily dies with 80GB of free RAM...
<M6piz7wk[m]>what's the failure mode then
<roptat>the guile GC is complaining about the heap size
<M6piz7wk[m]>o.o
<roptat>oh, it was a 32bits build (emulated), so it might have been limited to 4GB
<roptat>but even then, I don't think it uses that much
*M6piz7wk[m] confused
*roptat too
<roptat>anyway, I managed to build a more recent revision later, so I guess it's also a matter of luck...
<ASTO>hello
<bost>Hi. I'd like to a send a patch. (My very first one(!), with just a little doc improvement.) But the `git format-patch origin` created a patch-file with two lines "From ...". Is that ok?
<roptat>bost, I don't think that's ok, are you two persons? :)
<abrenon>not necessarily, one is for a commit's hash and the other for your commiter name, right ?
<roptat>ah
<roptat>maybe, in any case I think the commiter will be able to sort it out
<abrenon>at least, the patch I sent had this format (I didn't have the curiosity to look inside before sending it, I trusted git format-patch)
<roptat>or ask for clarification
<roptat>ah right, one of the From is not a header
<roptat>(not colon after it)
<abrenon>genau !
<abrenon>I hadn't noticed, thanks roptat
<bost>`cat 000.*` shows me:
<bost>From 851a25cd4ac0384b879c6d3d1178217c52b2ed70 Mon Sep 17 00:00:00 2001
<bost>From: Rostislav Svoboda <Rostislav.Svoboda@gmail.com>
<bost>Date: Mon, 15 Nov 2021 11:01:51 +0100
<bost>...
<civodul>efraim: we can push it on a branch and set up Cuirass if that helps you; WDYT?
<bost>
<roptat>bost, yeah that looks correct to me actually :)
<bost>abrenon: roptat: ah ok :) so yes actually I'm two.
<abrenon>and so was I apparently : )
<bost>Ok the patch is sent... thx guys.
*bost Now I deserve a proper lunch! :)
<civodul>i'm contemplating the idea of pushing the KDE updates at https://issues.guix.gnu.org/50862
<abrenon>everyone deserves lunch : )
<civodul>do you think these KDE updates are ok for core-updates-frozen?
<roptat>dunno, just had breakfast, it's a bit soon for lunch :)
<abrenon>bost: but it's no safe bet to call everyone here a "guy"
<civodul>+1
<abrenon>we're atually a very diverse community : )
<bost>abrenon: I guess you're a German right? Well a buddy of mine from London, once addressed a mixed crowd with "guys". Since that moment I feel safe using it, heh :)
<vivien>Are there people using the emacs vala-mode? If so, how did you patch it so that it compiles?
<vivien>I’m thinking about adding it to guix, but my solution is to kill the multi-line stuff altogether and maybe that’s not acceptable
<abrenon>bost: nearly ; ) yeah, I know it is actually pretty genderless for native speaker, I even have in mind several occurrences in TV shows for instance of a girl adressing her all-female group of friends "guys"
<vivien>I guess the opposite of GUYs is CLYs
<vivien>(I’m not sure that’s a good joke though)
<roptat>I laughed :)
<abrenon>it's just, the english spoken on the internet is seldom "proper english"®, you have to take into account the fact that many locutor don't understand this subtleties
<abrenon>you never know what people have in mind, especially with text only
<bost>vivien: what does CLY stand for?
<abrenon>vivien: I laughed so hard too
<roptat>in general, we adapt to avoid gendered nouns, which is not too hard with English: "hi guys" becomes "hi guix", "thanks guys" becomes "thanks all" or just "thanks", etc :)
<abrenon>I'm a CLY ! I'm so totally a CLY : )
<abrenon>bost: nothing, and that's the fun of it, it's just a pun on the parallel GUI/CLI
<singpolyma>roptat: I propose "thank the guix!"
<abrenon>roptat: wow ! "guix" as a gender-neutral term for "guys" Oo
<abrenon>you blew my mind :D
<roptat>^^
<singpolyma>Honestly, I think the biggest barrier to that is that no native English speaker who isn't "in" already can possibly pronounce "guix" correctly
<singpolyma>And "hi goo-ix" is less obvious ;)
<abrenon>^^
<singpolyma>In person I usually use "hello fellow humans" but people say it makes me sound like an alien invader
<abrenon>(bost: on top of that, it's a language habit that's been criticized by proeminent feminists in that it tends to erase feminity from public space and the asymetry is obvious when you think about calling "gals" an all-male group or even a group that you know includes men)
<rekado>singpolyma: I do the same, actually. It helps that I’m not actually from earth.
<singpolyma>rekado: 👍
<abrenon>singpolyma: "tremble in fear, puny humans !" (but why doesn't anyone talk to me ?…)
<rekado>too much trembling interferes with speech.
<rekado>upgrading python-notebook to 6.4.3 doesn’t fix the test failure on c-u-f.
<singpolyma>Could lean in on the communism and use "citizens"
<rekado>the problem remains with deleting files
<rekado>any ideas on how to fix this?
<rekado>vivien: I applied your fix to nautilus. I’ll close the issue soon; didn’t apply the upgrades, though.
<vivien>rekado, fair.
<roptat>one of my former classmates used "hello comrades" ^^
<abrenon>singpolyma: I think we scared the stalin of bost, comrade
<efraim>civodul: No, I can do it myself, my machine is powerful enough
<efraim>rig now I'm fighting pplacer, having trouble linking it with sqlite3
<efraim>certainly something I've seen come across IRC before
<rekado>efraim: roptat had a fix for pplacer
<rekado>or is this something different?
<efraim>on master?
<civodul>efraim: alright!
<roptat>efraim, on master
<rekado>efraim: https://issues.guix.gnu.org/51351
<darth-cheney>Hi all, I'm new to guix packaging. I'm trying to package a Guile module that I'm working on and I'm running into problems. I have one main dependency which is guile-json. When I try to install from the package file, I'm getting an error on the build side saying
<darth-cheney>ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<darth-cheney>no code for module (json)
<darth-cheney>I guess I'm not sure if I'm configuring the guile dependencies correctly
<darth-cheney>Here is my config: https://gist.github.com/darth-cheney/accca2d8d8df45601baa69629583fec2
<roptat>darth-cheney, (json) is not found because guile-json is not an input to your package
<darth-cheney>roptat: what's weird is that if I uncommet that line, I still get the same error
<roptat>are you sure? I think there's no guile-json in guix, but guile-json-{1,3,4}
<darth-cheney>Yeah I guess I'm a bit confused about where to find packages
<darth-cheney>If I run `guix install guile-json` it will install it correctly
<roptat>yes, because the package name for all versions is guile-json, so guix will select the greatest version for you
<darth-cheney>If I run `guix search guile-json` it tells me that guile-json is located in the guile package
<roptat>when you use the variable name though, we can only have one name per package, so we have guile-json-1, guile-json-3 and guile-json-4
<darth-cheney>Aha, so what I need to do is have something like `("guile-json" ,guile-json-4)`
<roptat>there's a difference between the variable name (used in package definitions) and the package name (the name field, used in the CLI)
<roptat>yes
<vivien>Are the different guile-json versions incompatible?
<roptat>yes
<roptat>at least -4 and -3
<darth-cheney>how can I see which version I have installed in my current system?
<darth-cheney>(or do I just assume it's the latest, if I did it like yesterday)
<vivien>darth-cheney, if you do ls -lah <the json.scm file in your guile load path>, it will tell you something like /gnu/store/xxx-guile-json-version/...
<darth-cheney>vivien: thanks
<abrenon>guix package -I also displays some relevant version information if you've installed it in your user profile
<darth-cheney>Thank you all, my package seems to be installing correctly now
<darth-cheney>PS - Is there some preferred way to test your packages from file using guix environment?
<abrenon>not sure what you mean but opening an environment (with guix environment or guix shell) for your package file with --pure is probably a good idea I guess ?
<roptat>darth-cheney, you can load a shell with your package with guix shell -f myfile.scm
<roptat>although since it's a guile package, it should actually be guix shell -f myfile.scm guile
<roptat>(so guix sets up environment variables correctly)
<vivien>civodul, did you get a chance to look at my openssh issue on master? Bumping https://issues.guix.gnu.org/51487
<vivien>(openssh service)
<lenny>Rust 1.56 also makes 2021 edition stable which adds many new features
<civodul>vivien: i had forgotten about it, thanks for pinging me
<darth-cheney>shoot, I have one more beginner question
<darth-cheney>if I'm including my guix package definition in the same repository as the package source, how can I get a reliable hash for the whole thing? Seems like a tautology
<darth-cheney>(Or perhaps I simply shouldn't include it there)
<vivien>darth-cheney, what I do is have a separate repo for the channel (guix package definition), and a git update hook to hash the source and add a commit to the channel.
<darth-cheney>vivien: I see, yes, that makes the most sense thakns
<darth-cheney>So really, make a channel repo with all my personal guix packages and then in my systems I just add that as a channel
<darth-cheney>Very cool, I'm liking this system more and more
<phodina[m]>Hi,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ad050b1b8ad0e865797b7f414243cb4dbc790217)
<roptat>phodina[m], on master I can only find one %outputs in glib.scm, and it's commented out
<jlicht>How can I get guix lint to check CVEs for a package that we gave a different name than upstream?
<roptat>there's a property for that
<roptat>upstream-name iirc
<jlicht>roptat: cool, thanks! I thought that only applied to updaters :)
<phodina[m]>roptat: This is on branch core-updates-frozen
<roptat>mh, right, maybe it's another property
<phodina[m]>* This is on branch core-updates-frozen
<phodina[m]>There's updated meson-build-system which supports cross-compilation
<roptat>then I don't know
<jlicht>'cpe-name is the answer :-)!
<jonsger>wanted to hint you to the icedove package, where it is used :P
<roptat>hey, sorry for the confusion then
<jlicht>np, thanks for the help nonetheless; Cunningham's law would have worked its magic either way
<jpoiret>civodul: ouch, apologies for the tabs. trust in my emacs shattered, will need several days to recover
<phodina[m]>Is there a way how to specify the output path during cross-compilation?
<phodina[m]>(assoc-ref %outputs "bin") gives an error
<rekado>phodina[m]: is there a “bin” output?
<rekado>the default output is called “out”.
<vivien>civodul, you should put your name/email on the ssh service patch, I didn’t do it because I was afraid to get it wrong
<jpoiret>code-formatting-wise, does the 80 character lines rule apply to guix as well?
<civodul>vivien: sure, if you want
<civodul>jpoiret: yup, it does
<jpoiret>just enabled whitespace-mode properly and whoops, seems like i have been inserting tabs everywhere
<jpoiret>but i also runaway lines (which aren't mine this time i swear!)
<jpoiret>s//see/
<vivien>jpoiret, when we have guix style, these problems will disappear.
<phodina[m]><rekado> "the default output is called “..." <- The glib defines besides out also bin, static and debug
<phodina[m]>When I change the code to out, the build runs. The checks fail latter.
<phodina[m]>This applies for cross-compilation to aarch64
<phodina[m]>On x86_64 bin works, tests pass
<phodina[m]>I'm suspecting the assoc-ref of not implementing this correctly
<jpoiret>looking again at the swap patch: how do we easily remind ourselves to remove support for the deprecated methods n months from now on?
<civodul>jpoiret: i don't know; for now i sometimes (rarely) remove old deprecated code i stumble upon, without really planning
<civodul>we'd need an alarm clock
<civodul>sneek: later tell vagrantc i think you inadvertently recreated the core-updates-frozen-batched-changes branch; could you delete it and use core-updates-frozen instead? :-)
<sneek>Okay.
<M6piz7wk[m]>Are there any package recommendations for emacs to work with guile
<M6piz7wk[m]>the manual just seems to mention paraedit
<M6piz7wk[m]>or like with guix in general
<jpoiret>there's geiser with guile support
<jpoiret>but the default scheme-mode is pretty good
<M6piz7wk[m]>is geiser like IDE for scheme?
<vdv>geiser is like an enhanced repl and a set of minor modes to improve emacs scheme major mode
<civodul>roptat: yay for the guile-netlink release! \o/
*M6piz7wk[m] > <@vdv:libera.chat> geiser is like an enhanced repl and a set of minor modes to improve emacs scheme major mode
*M6piz7wk[m] is too dumb with emacs to understand that..
<civodul>i'll retest the static-networking patches tonight
<M6piz7wk[m]>ehh dumb it down! >.<
<vdv>minor modes are like plugins, major mode is the scheme editing mode or c editing mode in emacs, you'll get live syntax evaluation and a completition and function lookup
<M6piz7wk[m]>oh, seems great trying
<vdv>but i'm a noob too, please add someone sth if i forget sth :D
<M6piz7wk[m]>ehh it's asking me for input of scheme implementation
*M6piz7wk[m] is nervously looking at the source code
<vdv>try guile :)
<M6piz7wk[m]>> MIT/GNU Scheme, via geiser-mit ?
<M6piz7wk[m]>vdv: tried x.x
<M6piz7wk[m]>says no match
<M6piz7wk[m]>oh Guile 2.2 or better, via geiser-guile
<M6piz7wk[m]>ehh still doesn't work
<M6piz7wk[m]>ah i need to have that installed
<vivien>vigra is broken on core-updates-frozen…
<notmaximed>sneek: later tell phodina: if from a build phase, you can use (assoc-ref outputs "bin") (without the %)
<sneek>Okay.
<notmaximed>sneek: later tell phodina: if from a build phase, you can use (assoc-ref outputs "bin") (without the \%)
<sneek>Okay.
<M6piz7wk[m]>hmm it doesn't seem to do anything
<notmaximed>sneek: later tell phodina: (grr autoemojification)
<sneek>Got it.
<notmaximed>sneek: later tell phodina: alternatively, use G-exps: `(#:configure-flags ,#~(bla bla (string-append #$output "/some/where)))
<sneek>Got it.
*M6piz7wk[m] figured it out
<notmaximed>sneek: later tell phodina: or re-introduce %outputs & friends when cross-compiling
<sneek>Got it.
<M6piz7wk[m]>ok that's pretty cool thanks
<M6piz7wk[m]>^-^
<Xe>if i have a git repo full of rust code and a cargo.toml file, what is the fastest way to get it into a user-defined package without having to involve code generation for the dependencies?
<Xe>the dependencies*
<civodul>Xe: if your code is on crates.io, you can run "guix import crates PKG"
<civodul>otherwise i don't think there's an easy way to do that currently
<Xe>civodul: my code is not on crates.io and is shipped as a git repo because it is my blog
<civodul>Xe: so as it stands, you'll probably have to write the package by hand, possibly using "guix import crates -r" for your dependencies
<abrenon>any convention on how to handle packages which do HTTP queries during the test phase ?
<abrenon>manually disable those tests ? is there a way to provide access to the network during the build ?
<M6piz7wk[m]>is guilemacs packages in guix?
<M6piz7wk[m]>ehh like that emacs fork that uses guile as it's compiler thing
*M6piz7wk[m] is trying to figure out how to integrate his repository for emacs so that it deploys standard environment
<phodina[m]><notmaximed> "sneek: later tell phodina: if..." <- Unfortunately it's part of the lamba phase so even without % it remains undefined
<nckx>Morning, Guix.
<nckx>abrenon: No networkies. Disabling such tests is fine! (And actually great, because it means you care about the other tests passing ☺)
<abrenon>so, a patch ?
<nckx>How depends on the situation.
<abrenon>(thanks for your perfectly-timed answer, I was just going to say I was leaving)
<abrenon>ok, I'll see how it's done
<nckx>Hah, I managed to mildly inconvenience you!
<abrenon>so, good morning to you
<abrenon>: )
<abrenon>and seeya
<nckx>o/
<Noisytoot>M6piz7wk[m], Yes, as 'guile-emacs'
<phodina[m]><notmaximed> "sneek: later tell phodina..." <- Thanks, the Gexpr builds. I have to adjust the path as it failed on compress documentation
<shtumf[m]>Hello, how to install Qt 6 opensource, I downloaded an installer ... but if I chmod +x installer.run , and then try to run it with ./installer.run it fails, how do you install Qt 6 is the question ?
<shtumf[m]>Should I do it in some sort of environment, what is the approach to such things
<phodina[m]>shtumf[m]: Just do guix install qtbase
<phodina[m]>Now defaults to Qt6
<jpoiret>shtumf[m]: as a general rule, don't expect installer scripts downloaded from the web to work on guix
<phodina[m]>You can install it in environment
<phodina[m]>guix environment --ad-hoc qtbase
<shtumf[m]>great, I am installing qtbase
<shtumf[m]>thank you
<vivien>phodina[m], guix environment is now replaced with guix shell, so guix shell qtbase
<shtumf[m]>ok, one question, why do we have guix shell ? this for development yes ?
<nckx>shtumf[m]: https://guix.gnu.org/en/manual/devel/en/guix.html#Invoking-guix-shell
<shtumf[m]>great thank you
<nckx>I'd have answered ‘no not particularly’, but seems the manual disagrees ☺
<nckx>‘Development’ is vague. Using your computer for anything else but browsing to Google to open Facebook is basically hacking anyway.
<lispmacs[work]>nckx: you still do your searching at Google instead of Facebook?
*lispmacs[work] files a report
<nckx>Oh god I'm sorry.
*nckx wildly likes things in a panic.
<nckx>Don't report me look I'm engaging.
<phodina[m]><vivien> "phodina, guix environment is now..." <- Thanks, didn't know that ... sound like Nix 😁
<phodina[m]>I'll check the documentation
<kozo[m]>phodina Ludo wrote up a nice blog about it as well
<lenny>Hi, i was hacking around a bit and i managed to create a build that worked, but then broke it again. Now i get the error guix build: error: derivation ... has incorrect output ... should be ...
<M6piz7wk[m]>> <@phodina:matrix.org> Thanks, didn't know that ... sound like Nix 😁
<M6piz7wk[m]>>
<M6piz7wk[m]>> I'll check the documentation
<M6piz7wk[m]>afaik nixos took this command from guix:p
<lenny>and i can't delete those because gnu store is read only.
<M6piz7wk[m]>What's the usecase of using guix as a package manager for emacs?
<M6piz7wk[m]>like it seems to just create an additional complexity for all usecases that i can think of
<M6piz7wk[m]>well i guess excluding guix-home to define a configuration for emacs but that then makes it implementation dependent
<M6piz7wk[m]>which is bad?
<M6piz7wk[m]>unless the generated guix implementation can be then redistributed as indepenent on guix
<kozo[m]>guix-home is coming in 1.4?
***PotentialUser-20 is now known as notmaximed
<singpolyma>kozo[m]: it's there now if you guix pull
<notmaximed>sneek: later tell phodina: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<sneek>Will do.
<notmaximed>sneek: later tell phodina[m]: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<sneek>Got it.
<notmaximed>sneek: later tell phodina[m]: not 100% sure if that exists
<sneek>Okay.
<kozo[m]>singpolyma Ah, thank you
<florhizome[m]>Personally so far I use it for those packages that need some outside library so I have them in one profile. vterm, notmuch and emacs guix f.e. Besides that I still have the same config as before with straight.el and it’s hard to imagine getting completely off of it since it’s very good at just installing things from github and even memorizes local patches.
<notmaximed>M6piz7wk[m]: If guix isn't used as package manager for emacs things, then you need to use something else, e.g. ELPA
<notmaximed>M6piz7wk[m]: so you would need to learn yet another package manager
<florhizome[m]>Elpa is just the repo :P
<notmaximed>the corresponding emacs mode then
<notmaximed>(ELPA + other repos + emacs' package manager)
<Noisytoot><M6piz7wk[m]> afaik nixos took this command from guix:p
<Noisytoot>No, nix-shell existed before guix environment was renamed to guix shell.
<notmaximed>Also, automatic tests, building info documentation, absolutising invocations of binaries, ...
<florhizome[m]>The thing is that you wouldn’t have to package stuff, since Elisp packages are native to emacs package managers.
<notmaximed>And guix reviewers verifying license, see if there malware, check everything is source code (no .elc), ...
<notmaximed>and a hypothetical ELPA compromise if you use guix to install emacs packages
<florhizome[m]>You just have to install stuff if it’s just emacs lisp.
<florhizome[m]>guix can shine when outside dependencies are required.
<florhizome[m]>I‘m actually wondering how convertible configuration macros like use–package are to guix?
<florhizome[m]>since I am still using my straight.el setup I have configured use–package to always use straight, which makes it unusable for guix emacs packages...
<notmaximed>Looking at ‘M-x package-show-package-list’, it appears Emacs' built-in package manager is easy to use. Personally, I'd use guix though (so I have the option of checking the source code for malware before installing, or trusting guix reviewers to have done at least a cursory check)
<florhizome[m]>Do guix reviewers check every update?
<notmaximed>florizhome[m]: I dunno, I always use guix to install things (well, actually Debian at the moment) and don't have an emacs configuration
<awb99_>My guix xfce desktop becomes unresponsive from time to time. I hear the CPU fan spinning crazy. It sometimes is so bad that I have to cut the power supply because nothing works. It typically starts with a few apps becoming unresponsive. Normally closing windows works (with some delay). Sometimes I can run htop but there is no cpu load really. This happens only on guix. Any idea what this could be?
<florhizome[m]>That would be an advance over elpa
<notmaximed>florhizome[m]: I don't think _every_ reviewers checks updates _completely_
<notmaximed>but personnally, I do a cursory check of the diff if it isn't super long
<notmaximed>E.g., checking diffs of different linux versions isn't realistic
<vivien>He he gnuzilla has a script to turn firefox into icecat, and there’s a sed script to replace "opensource" with "Free Software"
<notmaximed>but for small projects (which have a higher chance of having malware introduced without anyone noticing, so checking is more important there!), it's definitively feasible
<mitchell>Hello Guix! Can someone help me with how I would add new modify-phases to a package with inherits from a package with modified phases. Do I need to copy the modified phases from the parent package by hand and add my additional phases or is there a more elegant way to append new phases.
<florhizome[m]>icecat and librewolf should just merge -.-´
<mitchell>Because if I do something like (package (inherit hello) (arguments ...)) the (arguments) i provide will overwrite the parent arguments correct?
<notmaximed>mitchell: use inherit + modify-phases + package-arguments + (substitute-keyword-arguments ... #:phases ...)
<notmaximed>mitchell: yes, they will be overwritten
<notmaximed>I suggest searching for substitute-keyword-arguments in the source code for examples
<mitchell>thanks
<notmaximed>I don't have an example at hand.
<florhizome[m]>mitchell: In my experience, yep.
<florhizome[m]>for inputs you can do sth like (inputs (append (package–inputs emacs)) ....) though, so maybe doing something similar for arguments should be be possible. for committing upstream, probably not though :)
<florhizome[m]><notmaximed> "I suggest searching for substitu..." <- Is there something that lets me target specific package inputs?
<florhizome[m]>what i posted above is pretty unprecise
<M6piz7wk[m]><Noisytoot> "No, nix-shell existed before..." <- I didn't meant nix-shell, but nix shell.. https://github.com/NixOS/nixpkgs/issues/145125
<M6piz7wk[m]>different command that works more like guix shell
<M6piz7wk[m]>which is yet to be implemented in the new nix version
<M6piz7wk[m]>e.g. `guix shell package -- commands` being integrated in nix like `nix shell package -- commands`
<M6piz7wk[m]>or whatever they figure out in terms of use O.o
***xgqtd is now known as xgqt
<avp>Hello Guixers. I want to replace guile-ssh that is used by Guix with my version on a local machine. What is the proper way to accomplish that?
<yewscion>Hello All, I'm trying to package a piece of software that doesn't use autotools to configure, and has hardcoded directories in the install step of its Makefile. Is there a canonical way to fix something like this, or could someone point me towards an example of a package that does?
<yewscion>avp: You can write up a package definition and host it on Your own channel, which You can then use to install it. It's a long setup process, but it makes packaging other things very straightforward once it is complete.
<jgart>yewscion, I think you might have to modify gnu-build-system with custom phases and possibly substitute*'s to patch things
<jgart>what package is it?
<yewscion>jgart: https://gitlab.com/owl-lisp/owl A version of scheme I like to mess around with from time to time.
<yewscion>I'll have to dive into substitute*'s, I haven't used them before.
<jgart>Think of substitute* like sed as a scheme function, well kind of...
<jgart>would passing #:configure-flags to owl's Makefile now work to specify the store paths, etc...?
<jgart>Looks like it would be a simple package.
<jgart>See this nix definition for some ideas: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/compilers/owl-lisp/default.nix#L22
<yewscion>Awesome, thanks!
<jgart>Try just setting PREFIX= and CC= with #:configure-flags option that is a feature of the arguments field (package is a scheme record).
<avp>yewscion: Basically I need a test environment where only guile-ssh is replaced with my version, that should be enough for me. Should it be so complicated?
<nckx>yewscion: FOO = bar in a Makefile isn't (bad) ‘hard-coding’, it's fine: users can still modify those values on the make command line.
<yewscion>avp: I don't know if there is another way; It seems like this would be a use-case for `guix shell`, but I haven't learned how that really works yet. Sorry!
<jgart>yewscion, If you have owl packaged then you can use it with guix shell
<yewscion>nckx: I think my confusion mostly stems from not knowing how guix handles things such as env vars. I've been trying to avoid things like DESTDIR in my package definitions because of my lack of knowledge.
<jgart>yewscion, have you read this yet? https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/
<yewscion>jgart: I haven't, though it's now in my bookmarks!
<jgart>guix shell is like nix shell. It adds the packagese you specify to a temporary profile in which you can hack away and then exit when done
<jgart>s/packagese/packages
<nckx>yewscion: Not that #:make-flags are not environment variables! They are passed on the make command line and set variables inside the Makefile, nowhere else.
<nckx>DESTDIR is a ‘bad’ example because using it in Guix packages *is* usually a bad example, because it's meant for packaging workflows that are different from how Guix does things.
<yewscion>Ah, I see. That makes more sense. Thanks!
<nckx>Guix installs software directly to its final destination (often using something like PREFIX) whilst DESTDIR is meant to set a temporary staging area. These are just conventional names; technically they are exactly the same kind of variable. Some packages even get it wrong and that's why you'll see some DESTDIRs in Guix packages: the upstream author confused it with PREFIX ☺
<nckx>Or perhaps PREFIX is somehow buggy and DESTDIR happened to work.
<nckx>Etc.
<yewscion>I see, I see. So PREFIX and CC (like jgart suggested) would be a good way to go, then. And maybe setting them in #:make-flags will work, since there isn't a configure step?
<yewscion>Is there somewhere that would document all of the features of things like the arguments field of a package definition? The manual helps some, but it only has two examples.
<nckx>Yeah, #:configure was probably a typo, you want #:make-flags here.
<nckx>I'm not aware of such a doc but, well, I don't usually read the documentation.
<nckx>The usual catch-22.
<awb99>My guix system seems to have had a kernel panic, or somethign similar. What can I do? This is the log: https://paste.debian.net/1219640/
<nckx>I'd say ‘read the code’ but this part of the code isn't actually readable to newer users IMO. It's both repetitive and dense at the same time.
<nckx>If it's a panic, you can't do anything anymore, so… easy… yay.
<yewscion>nckx: Copy that, I'll still try I suppose. Once I know that I know what I'm talking about, maybe I can throw together some documentation as well.
<nckx>awb99: Since the culprit is cpuidle_enter_state, you could try booting with ‘cpuidle.off=1’ first.
<nckx>This is a total guess.
<awb99>Thanks nckx
<awb99>How would I deactivate this?
<nckx>Deactivate what?
<awb99>well, how do I start with this parameter?
<awb99>do I have to change my guix system config ?
<nckx>Add it to the (kernel-arguments (list "cpuidle.off=1" [stuff you might already have])).
<nckx>Yes.
<lilyp>vivien: if you're the same vivien as in the MLs, please send patches to guix-patches :)
<awb99>thanks nckx
<awb99>the /var/log/messages where I found this,
<awb99>this are the kernel log messages?
<florhizome[m]>So my build (gala, with meson) doesn’t find libmutter, although a suiting Mutter package is included ( actually just built for that! ;(). libmutter binarys are basically output under ./lib and they are really right there ....
<nckx>They are syslog logs, awb99, and the kernel ‘dmesg’ is one of the things that it logs.
<podiki[m]>anyone familiar with libsoup and our libsoup-minimal?
<jpoiret>avp: what is your exact use case? have a different guile-ssh in your environment when developing guix?
<nckx>awb99: This cpuidle_enter_state shows up in wildly different random bug reports over the decade (ZFS, …) where it's obviously not the culprit, but yours is interesting in that the call trace is rather short, and the idle subsystem may actually be to blame for once. This is still just a guess though. I'm not very familiar with that part of the kernel. This is not related to Guix, so be sure to ask other channels (maybe #linux, if that's any good) if disablin
<nckx>g cpuidle doesn't make a difference.
<phodina[m]><notmaximed> "sneek: later tell phodina: ‘..." <- Unfortunately the G-exp does not work even on native build
<sneek>phodina[m], you have 2 messages!
<sneek>phodina[m], notmaximed says: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<sneek>phodina[m], notmaximed says: not 100% sure if that exists
*phodina[m] posted a file: glib (4KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/UlYSKHgnGAcNJaIbvdQkSWnC >
<phodina[m]>phodina[m]: There's the diff + output from the build without and with the change
<avp>jpoiret: There might be a bug in Guile-SSH (https://github.com/artyom-poptsov/guile-ssh/issues/29), but this one is hard to fix without a setup where I can test my changes.
<jpoiret>so you want to build guile-ssh with debug symbols?
<jpoiret>well, with -DDEBUG iiuc
<jpoiret>i don't really understand what you want to do: do you want to use guix with your own guile-ssh?
<jpoiret>as in, guix-the-program™
<florhizome[m]><florhizome[m]> "So my build (gala, with meson..." <- What could be the reason here?
<nckx>awb99: Are you running the latest Linux kernel? If not, try a newer one, if yes, try an older one (5.10 or even 5.4 or evener 4.x if you're really desperate to try random things to gather more data).
<nckx>awb99: It's also possible there are more specific error messages in the kernel log before that point. The kernel logs ‘Linux version …’ every time it boots, everything between that & the stack trace you posted is from the same boot.
<awb99>the stacktrace is way longer.
<awb99>I just copied the first stacktrace line.
<awb99>I left my pc running for an hour, after it went unresponsive.
<awb99>its not the first time this thing happens.
<nckx>:-/
<nckx>Don't… do that please.
<nckx>Share randomly selected best-ofs.
<awb99>Nov 15 18:00:58 localhost -- MARK --
<awb99>Nov 15 18:20:58 localhost -- MARK --
<awb99>Nov 15 18:40:58 localhost -- MARK --
<awb99>the --MARK --
<awb99>this was there for days, about every 20 minutes.
<awb99>BEFORE the crash.
<nckx>Yes. That's just syslog logging that it's still alive but there's nothing to say.
<nckx>It's normal.
<nckx>By stack trace I meant the list of function+NNN/NNN lines you shared at https://paste.debian.net/1219640/
<nckx>You didn't remove arbitrary lines from that, did you?
*nckx has to go o/
<awb99>mo I didnt
<awb99>I copied the first few lines after ddays of --MARK--
<awb99>matched exactly the time when the system went unresponsive.
<awb99>uname -srm gives me: Linux 5.14.9-gnu x86_64
<awb99>so the kernel version is determined by guix ?
<awb99>depending on the snapshot where I am in, right?
<awb99>when I run guix upgrade, my system also becomes very unresponsive for a while.
<awb99>but with the guix upgrades, at least after they are finished, it works again.
<pkal>Can someone give me a hint how to download a patch together with a package source?
<phodina[m]><sneek> "phodina, notmaximed says: ‘..." <- Unfortunately the outputs are already part of the lambdas for install. I added them to patch-python-references after unpack, but there of course it has no effect
<sneek>Got it.
<phodina[m]><sneek> "phodina, notmaximed says: not 10..." <- Do you mean I have to overwrite some phase? Not mentioned in glib, but which is part of meson-build-system?
<notmaximed>sneek: later tell phodina[m]: (string-append #$output "-bin") isn't the "bin" output. For the bin output, try #$output:bin
<sneek>Will do.
<notmaximed>sneek: later tell phodina[m]: /gnu/store/4wg22h66i68qip2hpymb7ibzz1glz9dj-glib-2.70.0-bin != /gnu/store/xy5fsd2mb56hgrwbvjbrp7d0v7rrr1by-glib-2.70.0-bin
<sneek>Got it.
<notmaximed>sneek: later tell phodina[m]: I don't know what you mean with ‘unfortunately the lambdas are not part of ...’, given that you are modifying #:configure-flags, not a phase
<sneek>Got it.
<notmaximed>sneek: later tell phodina[m]: I thought you were replacing or adding a phase, hence my suggestion to use outputs instead of %outputs, adding the 'outputs' argument to the phase procedure
<sneek>Will do.
<notmaximed>sneek: later tell phodina[m]: Looking at (guix build-system meson), it appears #:outputs is already set, so no need to modify the build system, if that's what you mean
<sneek>Okay.
<notmaximed>sneek: later tell phodina[m]: Or maybe it's #$out:bin, I dunno
<sneek>Okay.
<rekado>pkal: add it to native-inputs and then apply it in a build phase. Or download it first and apply it in the source field.
<podiki[m]>I see flatpak fails on core-updates-frozen due to the newer libsoup (builds with libsoup-minimal-2, will submit patch)
<podiki[m]>found this list https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 in case that is of use
<pkal>r
<pkal>rekado: Thank you!
<jlicht>Is anyone using r-dot, r-brms or r-tidyposterior? These seem to depend on a venerable version of libnode
<jpoiret>sending a patch and immediately noticing a typo in a variable name: check 8)
<rekado>ouch, I shouldn’t have run ‘guix gc’. Now I need to rebuild ghc…
<jpoiret>aha yes
<jpoiret>someone should write a frontend to guix gc that would help with clearing junk and keeping what you're working on
<jpoiret>especially on core-updates-frozen, you don't want to delete the whole rust bootstrap do you
<podiki[m]>probably could use guix shell for that in a way? or some easy temporary profile that captures all builds
<notmaximed>guix build rust-stuff --root=oxygen?
<lilyp>would still gc native inputs tho
<notmaximed>Right. "guix shell -D rust-stuff --root=oxygen" then?
<podiki[m]>maybe some guix shell extension that would add to the profile everything built?
<notmaximed>podiki[m]: Like "guix install stuff"?
<lilyp>(packages->manifest (append-map package-transitive-inputs (list rust what ever you want)))
<notmaximed>lilyp: How about "guix build rust-stuff --root=oxygen" + --gc-keep-outputs + --gc-keep-derivations
<notmaximed>(the last two are options for "guix-daemon")
<podiki[m]>notmaximed: haha yes, but so you don't have to do that, e.g. if you need to build an intermediatary that didn't have a sub
<podiki[m]>so let's say I build a haskell package but ghc wasn't substituted (for whatever reason), I'd want ghc to not be gc'ed
<notmaximed>lilyp: That way, everything used in the derivation isn't GCed (assuming the output is reachable)
<podiki[m]>this is all why I don't run gc very often and have a bajillion /gnu/store/.links
<notmaximed>podiki[m]: I thin the --gc-keep-outputs + --gc-keep-derivations will help, though it isn't exactly what you were asking for
<notmaximed>* think
*notmaximed leaves
<lilyp>.links is a whole other beast
<podiki[m]>I seem to always have so many more than most people, no idea why
<vivien>lilyp, do you mean that the vala-mode package request should have been addressed to guix-patches@gnu.org instead of bug-guix@gnu.org?
<civodul>hey Emacs folks! git-rebase-mode no longer automatically fires for me, anyone experiencing that?
<civodul>(when editing a rebase file via Magit)
<jlicht>civodul: What does M-x magit-version give?
<civodul>Magit 3.2.1, Git 2.33.0, Emacs 27.2, gnu/linux
<jlicht>This seems to be about the built-in git-rebase-mode, right?
<civodul>yes
<civodul>or the auto-mode-alist or something
<civodul>(i can work around it with M-x git-rebase-mode in the buffer)
<ngz>civodul: what major mode do you get then?
<ngz>fundamental?
<jlicht>If I run `EDITOR="emacs -q" git rebase -i', it Just Works for me
***john__ is now known as gaqwas
<jlicht>I'm running Magit 3.3.0 FWIW
<civodul>ngz: fundamental, yes
<civodul>weird
<jlicht>civodul: in a freshly-pulled guix master, in a guix shell container, it also works for me; perhaps there is some stale state hidden somewhere?
<jlicht>e.g. guix shell --preserve=TERM --container emacs emacs-magit git
<civodul>jlicht: it must be something on my side then, but i have no idea why
<civodul>thanks for checking!
<jlicht>yw
<civodul>v2 of the static networking patches: https://issues.guix.gnu.org/51440#20
<civodul>if anyone's willing to test, they'll have all my recognition :-)
<phodina[m]><notmaximed> "sneek: later tell phodina: I..." <- Unfortunately not in this case. There are other packages, where I made the changes to cross-compile them. But glib with the bin output is though one as I'm not that skilled in Guile.
<sneek>Welcome back phodina[m], you have 6 messages!
<sneek>phodina[m], notmaximed says: (string-append #$output "-bin") isn't the "bin" output. For the bin output, try #$output:bin
<sneek>phodina[m], notmaximed says: /gnu/store/4wg22h66i68qip2hpymb7ibzz1glz9dj-glib-2.70.0-bin != /gnu/store/xy5fsd2mb56hgrwbvjbrp7d0v7rrr1by-glib-2.70.0-bin
<sneek>phodina[m], notmaximed says: I don't know what you mean with ‘unfortunately the lambdas are not part of ...’, given that you are modifying #:configure-flags, not a phase
<sneek>phodina[m], notmaximed says: I thought you were replacing or adding a phase, hence my suggestion to use outputs instead of %outputs, adding the 'outputs' argument to the phase procedure
<sneek>phodina[m], notmaximed says: Looking at (guix build-system meson), it appears #:outputs is already set, so no need to modify the build system, if that's what you mean
<sneek>phodina[m], notmaximed says: Or maybe it's #$out:bin, I dunno
<phodina[m]><notmaximed> "sneek: later tell phodina: Or..." <- Thanks. Unfortunately the #$out:bin is not recognized. I tried #$output:bin but then I got this error (after 20 mins of build):
<phodina[m]>/gnu/store/8024r543xzmi43qpsc1nm9rl4rpihfmk-glib-2.70.0-builder:1:7387: Unknown # object: "#<"
<jlicht>phodina[m]: I believe I might have sent an email to just you, forgetting to CC the ML: this was just me fumbling my keybindings :/