IRC channel logs


back to list of logs

***rdrg109_ is now known as rdrg109
***alMalsamo is now known as lumberjack123
<Aurora_v_kosmose>-_- Well that test is a complete waste of write cycles then.
<Aurora_v_kosmose>substittues came back midway
<oriansj>Aurora_v_kosmose: you didn't turn off substitutes first?
<Aurora_v_kosmose>oriansj: I neglected to do so as I simply ran the command with --fallback after pull failed.
<Aurora_v_kosmose>I had yet to see why it had failed.
<oriansj>guix gc also will cause all of the binaries in the dependency tree to be garbage collected (and thus built again)
<Aurora_v_kosmose>Yeah but building back from bootstrap will take ages
<oriansj>Aurora_v_kosmose: you can selectively Garbage collect as well
<Aurora_v_kosmose>12m to build ffmpeg.
<Aurora_v_kosmose>And yeah apparently there's Rust in mpv's dependency graph for some reason.
***leonarth_ is now known as leonarth
<oriansj>Aurora_v_kosmose: that is because ffmpeg uses Rust if I remember correctly
<oriansj>actually multiple parts depend upon rust if you look: guix graph mpv | dot -Tpdf > dag.pdf
<Aurora_v_kosmose>jgart: Yeah, it's not great.
<zacque>Hi, how can I interact Guix with Emacs Lisp?
<zacque>That's, instead of invoking "guix hash -rx ." through the shell process, maybe I can sort of calling Guix's guile API from Emacs Lisp?
<zacque>Just an idea though
<Aurora_v_kosmose>You can probably make some remote repl daemon and send guile code to it in Emacs.
<Aurora_v_kosmose>Guile already has such utilities built-in.
<zacque>Ohh, can I know what are the built-in "utilities"?
<zacque>You meant the remote repl?
<Aurora_v_kosmose>(info "(guile) REPL Servers")
<Aurora_v_kosmose>zacque: Oh. Seems like (info "( Invoking guix repl") might also be relevant.
<Aurora_v_kosmose>It has a listening option directly.
<zacque>Hmmm, okay...
<zacque>Does it receive in sexp format?
<zacque>s/receive/receive code/
<zacque>Ah, I would try it out
<zacque>But right now I have no idea how to talk to an endpoint in Elisp
<zacque>Two things to do, thanks for the pointer!
<Aurora_v_kosmose>zacque: You can use ncat/netcat/nc to write to a TCP endpoint.
<Aurora_v_kosmose>zacque: (info "(elisp) Network") this would be of use.
<zacque>Ah, that's good to know!
***Xenguy_ is now known as Xenguy
***ChanServ changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***Xenguy_ is now known as Xenguy
<nouun>Hey, I'm trying to package Wezterm ( which is a terminal written in Rust. It requires libssh-rs which I've packaged and added to cargo-inputs but it's still trying to clone the git repo. The wezterm package is here and I can upload the libssh-rs package snippet if needed but that seems to be working properly.
<nouun>Tail of the build log is here:
<f1refly>So I've managed to upgrade alacritty to 0.10.1 and my git diff for the guix repo is 935 lines long. I would now partition all these packet changes into single patches and submit them one by one after following the steps in the guix packaging tutorial.
<f1refly>Do they all belong to the same patch set or should I treat each patch as a new thread?
<AwesomeAdam54321>f1refly: Would the patches be useful individually, because I think they belong in the same patch set
<f1refly>I updated some packages that other things depend on, but not many
<f1refly>maybe two or three
<AwesomeAdam54321>In that case the other package updates should be sent separately in separate threads and then the alacritty package updates in its own thread
<f1refly>the lisp indent script from the tutorial is not in etc, any idea where it's gone?
<nckx`>Just gone. It was removed in favour of 'guix style --styling'.
<f1refly>neato, thanks
<nckx`>Urw. Which the tutorial?
<f1refly>the video tutorial on the guix website
<nckx`>Ah, thanks. I have another uncommitted change to that (they still recommend joining Freenode, which I... don't). I'll add this one.
<f1refly>hmm, I wonder what freenode is like now
<f1refly>maybe i should rejoin it sometime to check it out
<nckx`>Mostly dead. Not even so bad it's good. I stopped popcornwatching a while ago.
***iyzsong-www is now known as iyzsong-w
<f1refly>by the way, do you know how I can get the pinentry program for gpg to display a prompt on the console? I'm currently using the default one, but it's bailing out when I try to commit things via ssh from my other computer :/
<nckx`>Yes. I put 'pinentry-program /home/nckx/.guix-profile/bin/pinentry-tty' in my gpg-agent.conf.
<f1refly>But won't that redirect all pinentries to the tty?
<f1refly>That way I can't open my gpg key with a gui to unlock my password manager
<f1refly>I think it's possible somehow to make it fall back to the tty version if the gtk version fails but I can't remember how
<nckx`>I can only answer the previous question. I don't use a GUI.
<f1refly>yeah no problem
<f1refly>not your fault i have special needs
<nckx`>If you know how other distros do it we might guixify their answer.
<nckx`>/me AFK.
***iyzsong-www is now known as iyzsong-w
<abrenon>hi guix
<civodul>Hello Guix!
<leinad>Hi Guix!
<abrenon>o/ civodul and leinad
<f1refly>can I somehow supress the info that the compiled versions of files in my local guix checkout are older than the files themselfes?
<abrenon>f1refly: I get that one all the time, but I don't know if there's a proper way to do it
<abrenon>when I get too annoyed I delete the compiled files with find : /
<roptat>hi guix!
<civodul>f1refly, abrenon: usually it's enough to run "make"
<civodul>howdy roptat!
<roptat>as we discussed, I'll document a threshold for inclusion of translations in Guix for the manual and cookbook
<civodul>the other day i published the Slovak cookbook because it was at 57%
<roptat>ludo said 10%, and I guess it's fine. I would like to add a threshold for removal that's below that. does 5% sound good?
<civodul>sure, or 15% and 10%
<roptat>similarly for the website, I think we should publish only languages that have a relatively high percentage, maybe 80%, and unpublish when they fall below maybe 60%?
<roptat>oh nice :)
<civodul>you think the threshold needs to be higher on the web site to it doesn't reflect poorly, right?
<civodul>sounds good
<roptat>to me the goal is different. The website is for advertising to new users, the manual/cookbook is to help users
*roptat needs to go now
<paul_j>Good morning guix! Quick question - If I wanted to have a play with xmonad, what is the recommended way to install it? I Installed it from guix, but the necessary haskell environment to enable recompiling the config file is not installed. I guess the general question is "What is the best approach for carrying out haskell development?" Guix, or stack/cabal?
<paul_j>Sorry - having asked the question I have been called away - I'll check up on the responses in about an hour!
<abrenon>paul_j: I no longer use it but my setup consisted in opening a shell with the appropriate compilation tools (ghc, xmonad, xmonad-contrib) and generate my custom version in ~/.xmonad
<abrenon>and have my DE point to that executable
<f1refly>it'd be pretty neat to tell guix to just not use the compiled units instead of having to recompile before every invokation just so it doesn't spam my term with info messages :/
<paul_j>abrenon: Thanks for the comment - I will have a look at that approach.
<abrenon>I no longer use it so I cannot check the exact configuration details I used but I hope the general idea is enough for you to make it work
<paul_j>That's fine - I will experiment. It's quite a challenge to get stuff done in guix, despite being a linux user since 1995. I think the documentation that is available is great, but it would be useful to have a wiki or similar to expand on aspects like this which are not linked to the core system design and operation. I am not (and have never been!) and arch user, but their wiki is a great source of information for "traditional"
<paul_j>distributions. I think I might start to document stuff on a web page myself, as a reminder to me, and possibly as an aid to others.
<paul_j>(thinking to myself) - I guess the cookbook is the correct place. I will look to see how I can add to it...
<abrenon>yeah, the cookbook is a less-known but very helpful resource
<civodul>mbakke: looking at 71ec85b2958798246fc2b5d84c40badf5f75668e, are you sure --with-lto alone was a source of non-reproducibility?
<civodul>(for Python)
<civodul>would be interesting to see if marking Python as tunable is worthwhile
<apteryx>civodul: it'd be best to ask in #python
<apteryx>it seems it should be workable, since --with-lto is now on by befault in 3.10, if I recall correctly
<apteryx>nevermind, --with-lto is disabled by default still in 3.11.0a6
<f1refly>how can i specify multiple outputs to be installed? I just installed git:sendemail but it seems like that overwrote the regular git:out that i still need
<f1refly>it's not decribed in the manual in the packages with multiple outputs manual section
<f1refly>wait, i just specify both packages independently
*f1refly buries himself
<civodul>f1refly: right, "guix install git git:send-email" for instance
<civodul>apteryx: good to know
<jonsger>f1refly: its strang that git:send-email "breaks" git itself :P
<f1refly>i think that's only because i had the git package installed via global system definition and the subselection git:send-email overrode that for my user
<phf-1>Hello Guix! I was wondering where was the Python python-build-system at. The Guix Day Conference 2022 gave some news :
<phf-1>But are there any plans to finish anytime soon?
<phf-1>How much work would be needed to complete it?
<civodul>phf-1: i'm not much into Python but i enjoyed the talk and found the arguments compelling
<civodul>would be nice to get this merged
<civodul>PurpleSym: what do you think could be the next steps?
<jonsger>guix refresh --list-dependent socat
<jonsger>Die folgenden 6733 Pakete zu erstellen, würde zur Folge haben, dass 13407 abhängige Pakete neu erstellt werden
<jonsger>^ can this be real?
<civodul>comrades, what's going on?
<civodul>i'm seeing Rust rebuilds and things like that
<jonsger>LLVM for me
<abrenon>Oo es klingt ein bißchen viel
<civodul>jonsger: try "guix graph -t reverse-package socat | xdot -f fdp -" :-)
<civodul>with -M2 maybe
<civodul>jonsger: yes, that's socat
<jonsger>grep socat gnu/packages/*.scm | wc -l => 10
<jonsger>seems not to occur often...
<gnucode>hello guix!
<civodul>jonsger: gnutls depends on socat...
<civodul>hi gnucode!
<cbaines>I've stopped the relevant revision being processed on to avoid lots of builds happening on
<cbaines>that's not a perfect solution, maybe these builds should happen, but just at a lower priority
<zimoun>what happens on for master? All is red and the last green is from March the 4th
<gnucode>civodul: joke of the day: Why does airline food always taste so bad? Because it's so plain/plane.
<f1refly>in sending a patch series, it says that subsequent patches of a series should be sent to, is NNN the ticket number? if yes, how do i get it after submitting the first patch?
<gnucode>f1refly: Yes. NNN is the ticket number.
<gnucode>It should email you the ticket number.
<f1refly>oh, okay. nice.
<gnucode>You can also potentially find said ticket number by search for it in
<zimoun>civodul: the red CI appears before the socat update. For instance from March 4th.
<gnucode>You will get it faster via email, but issues will have it. Or potentially you can use the emacs interface to debbugs.
<f1refly>time to send my first patch then :)
<gnucode>f1refly: good luck!
<f1refly>So i sent the thing five minutes ago and nothing happened
<f1refly>does that mean i did it wrong?
<gnucode>f1refly: I would look up the patch series in issues. eg:
<gnucode>That should show you if you correctly sent said patch series.
<gnucode>Note the truly awesome guix hackers use the Emacs interface to debbugs. The Guix manual contributing session shows you how to use it. :)
<gnucode>Also it may take issues, 15 minutes to sync up with the debbug server.
<civodul>zimoun: i tried to restart the damn evaluation but somehow it's failing me
<f1refly>I don't know how emacs works honestly, so I skipped the "use emacs plugin x for this" steps
<f1refly>It's somewhere on my list with learning go and erlang
<f1refly>But I'll get to it eventually!
<gnucode>f1refly: I am in the same camp. :) It's easier (in my opinion) to just use issues. I haven't actually learned how to use the debbugs in Emacs. In my opinion the debbugs Emacs interface is a little clunky. I always have to look up how to use it in the guix manual before I use it.
<gnucode>hmmm, so I have guix set up for full disc encryption (/boot in unencrypted). I just rebooted just now hoping to boot up guix in a previous state...I do not seem to be able to do so. At boot, grub requests the password to unlock /. Then linux seconds later asks for the same password to unlock /. Then it starts booting the latest generation of my computer. Where in this do I tell Guix System to boot the previous generation? Also not
<gnucode>that I am using Libreboot... and I am in a T400. I honestly not certain if I am using the libreboot's grub or the grub installed on the MBR in /dev/sda to boot...
<lfam>gnucode: Normally, the GRUB menu allows you to select earlier generations of Guix System
<sneek>lfam, you have 4 messages!
<sneek>lfam, phf-1 says: As promised, here is the tutorial to setup Cuirass with the remote build mecanism:
<sneek>lfam, phf-1 says: https and firewall configurations are still missing, I will add them shortly.
<sneek>lfam, apteryx says: I've removed the guix-days alias, you shouldn't receive mails anymore from it.
<sneek>lfam, phf-1 says: looking at the tests in `guix-cuirass/tests/remote.scm' we learn that the `(server "...")' field should be filled witht the ip and the port, not just the ip. I guess an example would help in the documentation like `(server "")'
<gnucode>lfam, I actually do not see a grub menu...I bet I am using libreboot's grub then. maybe...I never saw the graphical grub splash screen with guix's logo with potential entries to select which one to boot. My entire boot process is black and white.
<lfam>I guess it's something special with libreboot
<lfam>After you boot, you can select another generation with `guix system list-generations` and `guix system switch-generations`
<gnucode>lfam: It could be... or maybe I'm just not as experienced user or something. I could see the boot menus in libreboot before when I had unencrypted hard drive...
<gnucode>lfam: really? I did not know that was possible. I would probably need to reboot into that generation then...thanks!
<lfam>Yeah, using `guix system switch-generations` is the "correct" way to do this. If you only choose an earlier generation in the GRUB menu, your change will not persist after a reboot
<lfam>You have to use switch-generations to make the change permanent
<lfam>I would say that choosing generations at the GRUB menu is something I use when debugging, or if the latest generation fails to boot. But it's not the "Guix-y way" to change Guix System generations
<lfam>I hope it serves your needs
<lfam>RIP glibc-utf8-locales
<lfam>You served me well
<lfam>Weird. Some change in symlink handling: "ls: cannot access '/root/.guix-profile/etc/profile': No such file or directory"
<lfam>It was garbage collected. That seems unexpected
<zimoun>civodul: is cuirass still alive?
<gnucode>lfam: thanks. That's a good explanation. I hope I can get grub to show me the bootsplash screen again. I usually play with guix a lot...and I normally break it. Being able to choose a different generation at boot sure helps me a lot.
<AwesomeAdam54321>Does file-deduplication not calculated in guix size? because when I use `guix size glibc-locales` It still says it's size of 928.6MiB
<gnucode>lfam: # guix system list-generations ...shows generation one, but then shows a backtrace...warning unrecognized boot parameters...I must be using a deprecated syntax somewhere...
<lfam>Huh gnucode
<gnucode>probably in the boot parameters.
<lfam>It's weird, I would report it
<gnucode>ok. Will do....once I get email working again...
<gnucode>I just re-installed guix system with / encrypted. Still resetting up things.
<lfam>I guess not, AwesomeAdam54321
<lfam>Remember that deduplication in the store is optional
<djeis>Is it possible to do a reconfigure that will only take affect on the next boot? Something like, leave booted-system and current-system alone but do update the profile links and grub config?
<mbakke>civodul: I'm certain LTO made Python non-deterministic at the time (see the commits leading up to it :-)), although things may have changed in 3.9.9
<mbakke>I only later learned about -frandom-seed, and did not try it
<mbakke>also, hi Guix :-)
<nckx>djeis: booted-system is always left alone (that's its point), but otherwise, no I think not. I suspect that cursed is the use case that calls for that, though.
<nckx>(What is the use case, anyhow?)
<djeis>I want to cleanly shutdown all of the running services before starting all of them up again with their new configs.
<djeis>Including, e.g., the services that configure networking.
<lfam>I would do something like `guix system build`, then later `guix system reconfigure && reboot`
<djeis>Mostly I just don't want guix reconfigure to immediately load the new herd service defs or restart.
<djeis>*restart services
<djeis>Because I want to avoid a partial upgrade situation.
<lfam>Dealing with services during reconfiguring is definitely a weak spot
<lfam>It's not really something that can be done in a functional way
<djeis>Yea, there's too much state in the running services to always cleanly step to a new system config.
<lfam>You could always stop your services "by hand" before reconfiguring and rebooting
<djeis>Yeah but if I do that reconfigure will start some of those services back up again automatically.
<lfam>I see
<djeis>Only, it will do that before restarting the ones I couldn't stop before the reconfigure.
<djeis>And now I'm back to a partial upgrade scenario and hoping all of my daemons have sane failure states.
<djeis>Hence, reconfigure for next boot: then the normal restart process will cleanly shutdown and bring back up everything.
<apteryx>mbakke: according to nixpkgs, "enableLTO is a subset of the enableOptimizations flag that doesn't harm reproducibility" (c.f.:
<djeis>*reboot process
<lfam>I guess we could add something like `guix system reconfigure-and-reboot`, where init firsts kills all services, then adjusts the current-system symlinks and GRUB, and then reboots
<lfam>I would definitely use it
<mbakke>apteryx: it would be nice if that was the case, should be easy to test :-)
<lfam>I mean, not the current-system symlinks
<lfam>But, just what is necessary
<djeis>lfam: Yeah that would make a lot of sense to me.
<lfam>I wonder if it would be hard or not
<lfam>It would assume a sensible separation between what we think of as "services" and what is actually a service
<lfam>Like, it would be problematic if "mount the bootloader partition" is a "service"
<lfam>Anyways, I really have no idea
<lfam>I think this is probably on a lot of people's wishlists
<djeis>Would it really be that crazy to update the profile symlinks and install the bootloader like normal but then just reboot instead of activating the new profile?
<lfam>I am probably overthinking it
<djeis>Or, activating the new system.
<lfam>Updating the profile symlink may not achieve what you want, however
<lfam>Things may refer to /run/current-system at runtime, so if you change it will the system is running, then you don't get the desired property
<lfam>Anyways, it's probably not too hard
<djeis>My whole idea is that /run/current-system stays the same all the way to the reboot.
<lfam>That's my understanding too
<djeis>Just /var/guix/profiles/system gets updated, then the bootloader from that system is installed, then reboot and let the new initramfs set up /run/current-system however it wants.
<djeis>I'm actually relying on running stuff using the /run symlinks so that the shutdown process proceeds properly.
<lfam>Well, I think this feature is desirable and possible. If you can implement it yourself, awesome. If not, I recommend sending a message about it to <>
<lfam>I have to go
<unmatched-paren>hello guix
<unmatched-paren>how would i refer to $out in #:make-flags?
<unmatched-paren>#:make-flags '(,(string-append "PREFIX=" ???))
<unmatched-paren>PREFIX _should_ be set to $out by default in the gnu-build-system, but for some reason it isn't in this package i'm building...
<nckx>Use gexps: (arguments (list #:make-flags #~(list (string-append "prefix=" #$output))))
<unmatched-paren>nckx: thanks! i still haven't really looked into gexps...
<nckx>They are not as scary as they seem ;-) For completeness, you'll find the older-style (arguments `(#:make-flags (list (string-append "prefix=" %output)))) in the codebase but should consider that deprecated. It won't even work in all current build systems anymore.
<unmatched-paren>Are we just replacing all the %s with gexps? or will some of them stay?
<unmatched-paren>i think i get the basic concepts of gexps: #~(...) starts a block of code that's executed inside the store, and #$ allows you to substitute parts of the store block with variables from outside? that seems to be what they're used for in some package definitions i've seen
<unmatched-paren>and the #:phases (modify-phases ...) etc blocks seem to be implicitly run in the store but you can't use ungexp for them?
<unmatched-paren>unless you #~ the (modify-phases)
<unmatched-paren>is this /roughly/ correct?
***alMalsamo is now known as lumberjack123
<lilyp>unmatched-paren: no, it's not just %output, but yes, we replace all of them
<unmatched-paren>even %standard-phases?
<lilyp>no, %standard-phases remain %standard-phases
<lilyp>What I mean is that besides %build-inputs and %output, there are other patterns that we replace with gexps
<lilyp>for instance, origin inlining
<lilyp>yeah ik
<unmatched-paren>right, okay
<unmatched-paren>what's origin inlining?
<lilyp>if you haven't seen it yet, be happy to remain unknowing
<unmatched-paren>ah, ok
<phf-1>Is there a small Guile module considered very well written?
<phf-1>somewhere in the shepherd source code I guess?
<Aurora_v_kosmose>If one redefines a package A to remove input B they don't need, what happens to other installed packages C & D which depend on A?
<ngz>They need to be rebuilt.
<Guest6985>friends, I am new to guix; I installed gnome and exwm during the install, but now I want to add xmonad; to that end, i ran ```guix install xmonad``` in the terminal and I can see that the package successfully installed, but I cannot see it in the login screen session selector. What have I done wrong? I tried the same thing with xffce and I could
<Guest6985>see the little applets that come with it in the gnome app drawer. Thank you for helping or pointing me to the correct documentation ( i did try to search)
<Aurora_v_kosmose>ngz: So upgrading/installing the packages again would switch the references to the new definition?
<Aurora_v_kosmose>Good. Would it need to be specifically targeted or would something like "guix upgrade" suffice?
<ngz>guix upgrade would do the job