IRC channel logs


back to list of logs

<goldenshimmer>My ~/.config/guix is a git repository, so assuming it doesn't get deleted I expect it's OK; and ~/.guix-profile is a symlink into /var/guix.
<zimoun>nckx: Thank you for the explanations. It makes sense. What surprise (second times) is “guix build -h” does not say “–with-source=PACKAGE=SOURCE” but only “–with-source=SOURCE”. Which is confusing. Now, I rememenber the same discussion. Well, I am going to send a tiny patch. :-)
<nckx>zimoun: Oh, definitely a bug; thanks!
<nckx>goldenshimmer: Absolutely. If you back up /var/guix in addition to /gnu you're golden (...I'm so sorry.)
*nckx not really sorry.
<goldenshimmer>hah — great, thanks!
*nckx has had entirely too much wine.
<zimoun>nckx: done in #43436 :-)
<sys2>hi #guix! I'm having some trouble with xmonad. When I try to xmonad --recompile I see "Could not find module 'XMonad'", which makes sense because it's not in the list provided by 'ghc-pkg --list'. I noticed I have 2 ghc's installed in ~/.guix-profile (I have 1 user profile). How can I find out why? The older one (8.6.5) has the modules I expect... the other ghc is 8.8.3 (what runs when I use ghc --version)
<nckx>zimoun: 👍!
*nckx → 😴
<raghavgururajan>apteryx, nckx: So its not just my ssd that is dying. My ram too.
<raghavgururajan>oh nckx is asleep.
<bdju> looks like this issue is kinda stagnating... screenshots are still upside down when taken on my portrait monitor until sway gets upgraded. (or until I downgrade grim, I guess)
<sys2>is there a way (in a manifest) I can say "package1" "package2" "dep-of-both@version-they-should-share"? I think my xmonad issue is because ghc was upgraded but xmonad and ghc-pkg-xmonad's ghc version is older
<sys2>or should I just mangle $GHC_PACKAGE_PATH so they can both share it?
<sys2>fixed by pinning GHC at the version xmonad is using. couldn't find a way for them to share dependencies/GHC_PACKAGE_PATHs otherwise (setting that manually didn't fix it either)
<lfam>Urgh, just noticed a mistake I made in commit 105a037090d
<lfam>I truncated the wrong VERSION and broke fetching of the deblob scripts
<lfam>I'll fix it shortly
<str1ngs>rekado_: hello, just quickly looking at jack1 and gstreamer seems there is a 1.18.0 release. which also dovetails with some additions i have queued that adds webrtc support. is there particular branch this work should go on?
<goldenshimmer>How can I set the font for gtk3 to use? (Guix on foreign distribution). I found some suggestions online for other distributions to use a program called "gsettings" but there's no package called that in Guix... thanks!
<str1ngs>goldenshimmer: hello, what desktop environment do you use?
<goldenshimmer>None in Guix; just standalone apps. (The foreign distribution uses KDE, but Guix doesn't use the GTK3 settings that the foreign distribution uses)
<str1ngs>goldenshimmer: does installing gsettings-desktop-schemas help?
<str1ngs>you might have to restart your deskop after installing.
<str1ngs>logout and log back in.
<goldenshimmer>I'll see what it has, thanks!
<goldenshimmer>Hm, the glib package in the foreign distribution provides the gsettings binary... neither the gsettings-desktop-schemas nor the glib packages in Guix appears to include it though.
<str1ngs>goldenshimmer: does gnome-tweaks work with KDE. I assume KDE has a xsettings implimentation.
<goldenshimmer>KDE isn't involved in the Guix packages, as far as I can tell — KDE can configure the foreign distro's GTK packages fine. The ones from Guix don't see the host's GTK configuration (which is fine, I prefer to keep them separate). I'd prefer to configure Guix's GTK without affecting or depending on the host system's settings..
<str1ngs>it doesn't work that way
<goldenshimmer>I guess I'd need to install the fonts and themes that the host system configures GTK to use inside of Guix, so that the same configuration could work on both, then..
<str1ngs>possible. but it might have to do with how KDE handles xsettings
<str1ngs>I use xfce and it's settings daemon will change the fonts for guix install programs.
<goldenshimmer>That solved my issue for the record — making sure the host's configured gtk typeface got the Guix apps to use it. Thanks!
<bdju>I copied the lines for rtl882lce-linux-module from linux.scm into a new file and then edited the source url, hashes, description, name, etc. for rtl88x2bu, but now I'm not sure how to test it. Should I be somehow installing a modified linux.scm on my system, or installing this as its own file?
<bdju>if I install it as its own file, I'm not sure how I figure out what use-modules to use. I don't have any so far
<vits-n-guix>Hello Guix.
<str1ngs>bdju: do you plan to use this in a system config?
<bdju>str1ngs: well I want working wifi so I was going to try to make this work (on my machine with relevant hardware) and then submit a patch or something. not sure how to directly answer your question. I guess it would maybe have something to do with my system config
<bdju>I don't really know any of this stuff and I'm kinda just putting in the bare minimum effort
<bdju>I had tried guix package --install-from-file but I guess a kernel module would probably not be installed for just my user
<vits-n-guix>sneek tell milkman[bot] hello
<sneek>milkman[bot], vits-n-guix says: hello
<str1ngs>bdju: you are currently using guix system I assume?
<bdju>oh, yes
<str1ngs>bdju: if you plan to contribute this back upstream to guix I would clone the guix repo. and modify the linux.scm file directly
<str1ngs>then you can use ./pre-inst-env guix system build etc.
<str1ngs>and later reconfigure I assume might want to add rtl882lce-linux-module to your system configuration
<str1ngs>bdju: will walk you through the steps
<milkman[bot]>Contributing (GNU Guix Reference Manual)
<str1ngs>milkman[bot]: botsnack
<bdju>str1ngs: thanks
<xelxebar>milkman[bot]: kitten me
<xelxebar>Oh well.
<xelxebar>Lol. Took a while to acquire kitten.
<efraim>xelxebar: guix-1.1.0-25 failed to build for me so now I've upgraded and it's trying 1.1.0-27 and its on to the check phase now. hopefully we have the image ready today!
<brendyyn>looks like our qt 5 doesnt have the wayland or wayland-egl platforms supported
<zimoun>sneek later tell civodul: SWH reads sources.json see \o/
<milkman[bot]>Search software origins to browse &ndash; Software Heritage archive
<nckx>milkman[bot]: Really? <>?
<nckx>raghavgururajan: Bug report: ☝ milkman[bot] needs to return the first title element, not the last (or whatever it's doing).
<nckx>raghavgururajan: RAM alone would explain the heavy file system corruption. For all the painstaking care btrfs/ZFS/etc. take to journal/checksum/etc. your data, they assume RAM is completely reliable.
<nckx>So does everything else. It's a correct assumption to make, but it means all bets are off if your RAM is wonky. You can't debug anything else until you fix it.
<rekado_>the arm-none-eabi-7-2018-q2-update-1 cross-compiler’s libstdc++ seems to be unable to #include_next <math.h>
<rekado_>is there yet another env variable that needs to be set? Or one that may not be set?
<civodul>rekado_: oh that sounds like a CPLUS_INCLUDE_PATH kind of issue
<sneek>civodul, you have 1 message!
<sneek>civodul, zimoun says: SWH reads sources.json see \o/
<milkman[bot]>Search software origins to browse &ndash; Software Heritage archive
<civodul>rekado_: is this in "guix environment" or in a build environment?
<civodul>that has an impact on #include_next, unfortunately
<raghavgururajan>Hello Gu..Gu..Gu..Guix!!!
*raghavgururajan 's alarm didn't work, but nckx's two pings did the job \O/
<raghavgururajan>Yeah, milkman has some bugs. I have already reported that.
<raghavgururajan>nckx: Yeah, I overlooked RAM. My GNOME use to stutter whenever I play HQ videos in media-player or any video in IceCat. I thought it was GNOME's shenanigans. But now, I closed all the apps and started memtester. The stutter happened few seconds after that.
<raghavgururajan>nckx: Whenever stutter happens, I had to restart my system everytime. Even log-out and log-in didn't work. But I discovered something new today. When I close the lid, the system goes to sleep. When I reopen, the stutter is gone.
<raghavgururajan>nckx: I repeated this 3 times. [1] Close all apps [2] start memtester [3] stutter happens [4] stop memtester and stutter continues [5] close the lid and system goes to sleep [6] open the lid and unlock screen [7] stutter is gone.
<raghavgururajan>[8] start memterser [9] goes back to step 2.
<rekado_>civodul: it’s neither. The axoloti-patcher-next executable spawns the cross-compiler at run-time.
<rekado_>so the executable is wrapped in CROSS_CPATH, CROSS_CPLUS_INCLUDE_PATH, and CROSS_LIBRARY_PATH.
<rekado_>that used to work for axoloti-patcher with the 4.9 cross-compiler
<raghavgururajan>nckx: I also tried replacing memtester with playing hq videos on icecat, for step 2, 4 and 8.
<raghavgururajan>nckx: So cleary RAM issue right?
<nckx>raghavgururajan: memtester allocates *all* ‘free’ RAM in order to test it. You bet that causes stutter. You're not supposed to be watching videos while it's running. In fact you should close everything you can afford to, so memtester can allocate (and test) as much as possible.
<nckx>Unless memtester actually reports errors, it causing slowdowns is no indication of bad RAM whatsoever.
<raghavgururajan>nckx: No no, I closed all apps while running memtester.
<nckx>After it finishes, most things will have been swapped out. Paging them back in could cause stutter too.
<raghavgururajan>I replaced memtester with playing HQ videos on icecat to cause stutter.
<raghavgururajan>Also, memtester reports numerous "FAILURE"
<nckx>Bad RAM doesn't cause stutter or slower cat gifs; it causes bad data corruption and crashes. So worry about the failures; stutter is (here) irrelevant.
<raghavgururajan>I also repeated this 3 times. [1] Close all apps [2] play a video in IceCat or media-player [3] stutter happens [4] close icecat/media-player and stutter continues [5] close the lid and system goes to sleep [6] open the lid and unlock screen [7] stutter is gone [8] continue to [2].
<raghavgururajan>Ah I see.
<nckx>Stuttering video playback is certainly something to debug if it only happens sometimes. It's just not related to bad RAM. If you treat them as related you'll just make both harder to debug.
<raghavgururajan>I also use to get "Ah snap! [...]" webpage/tab crash on IceCat and ungoogled-chromium, often.
<raghavgururajan>> if it only happens sometimes
<raghavgururajan>No, *all the time*. :-) I never pay videos on browser. I had to use ytdl evertime.
<raghavgururajan>> If you treat them as related you'll just make both harder to debug.
<raghavgururajan>Yeah, I understand that.
<raghavgururajan>Just trying to see what other component of my system that I have to replace.
<raghavgururajan>If its CPU or GPU, I am gonna say "amen" and throw away my device. 😅
<nckx>If I were you, I'd run the other memtest86+ overnight. That will test only your RAM, and all of it, and you'll have a definitive answer.
<raghavgururajan>You read my mind.
<raghavgururajan>Are there any tools like memtest86+, for CPU and GPU?
<nckx>If it comes back clean, things get (unfortunately for you) interesting. If you still suspect hardware issues, you can use something like stress(1) (in Guix) to heat up your laptop.
<nckx>I don't know about GPU.
<raghavgururajan>I see. CPU should be okay though. I have built many packages. Including webkitgtk upto 50%.
<raghavgururajan>Let's see. Thanks nckx
<nckx>Good luck.
<nckx>raghavgururajan: And thanks for reporting milkman bugs! A #guix bot that can't parse our own issue links is unfortunate.
<civodul>rekado_: CROSS_CPATH is no longer used though, is it?
<civodul>i think you need C_INCLUDE_PATH instead
<civodul>ah looking at gcc-7-cross-environment-variables.patch, CROSS_CPATH is still honored
<civodul>but it conflicts with the others
<civodul>so can you try with CROSS_C_INCLUDE_PATH instead of CROSS_CPATH?
<rekado_>thanks, I’ll try thaht
<rekado_>I find this all very confusing
<civodul>it is :-/
*nckx , following along at home, ++.
<milkman[bot]>nckx has 1 point
<civodul>do you win a prize once you have 10 points?
<rekado_>sadly this didn’t help :9
<rekado_>it’s loading /gnu/store/gywf0ll6p5j4d9q3pbigsphg1cpmjwaw-libstdc++-arm-none-eabi-7-2018-q2-update-1.261907/arm-none-eabi/include/math.h
<rekado_>which includes <cmath>
<rekado_>and that in turn #include_next <math.h>
<rekado_>I’ve never understood how this works and what the intent here is
<rekado_>… something is wrong
<rekado_>the toolchain is the *nano* toolchain
<rekado_>and it’s built with newlib as the C library
<rekado_>so what’s the deal with defines like _GLIBCXX_INCLUDE_NEXT_C_HEADERS
<rekado_>I’m not using glibc
<civodul>_GLIBCXX_INCLUDE_NEXT_C_HEADERS is the thing apteryx & i fixed recently
<civodul>lemme see
<civodul>well, "fixed"
<civodul>yes, commit 12dc9f58c422c06bf9950f21c54ca3df1dc40af1
<civodul>we should improve on the title of mumi pages :-)
<civodul>rekado_: perhaps you can similarly add libstdc++-headers as an input?
<rekado_>civodul: thanks for the hint! I’ll see if I can apply this to the arm-none-eabi cross-compiler toolchains
<xelxebar>efraim: Sweet!
*xelxebar waits in intense anticipation
<rekado_>civodul: I think this is a problem with milkman. The title is fine, but the first anchor tag contains an SVG, which itself has a TITLE tag. I guess it’s taking the contents of *that* title rather than the title from the HEAD of the document. Weird.
<civodul>i'm not happy with the header search mess with gcc and all
<civodul>i hope we can find a better solution
<civodul>sneek: later tell zimoun re "make dist" failure, see
<sneek>Will do.
<janneke>sneek: later tell zimoun: the "make dist" is fixed on master, can you mark the bug as a duplicate of 43005?
<sneek>Got it.
<janneke>sneek: botsnack
<nckx>civodul: raghavgururajan has already reported it to milkman's upstream.
<nckx>(So, ...cows?)
***nlyy` is now known as nly
<cbaines>civodul, do you know if the berlin guix-daemon database is on an SSD or hard drive?
<rekado_>hmm, the report at says that GCC 7 is unaffected, yet the gcc-arm-none-eabi-7-2018-q2-update inherits from gcc-7.
<nckx>raghavgururajan: Can we toggle this feature until it is fixed? I don't know why but a bot shouting ‘Download!’ at every link gets under my skin.
<rekado_>cbaines: /var/guix is on the root file system, which is on two SSDs IIRC.
<rekado_>(it’s a RAID0)
<rekado_>nckx: to me it seems even more menacing without the punctuation
<cbaines>Cool, tthanks
<rekado_>milkman gives me the creeps
<jlicht>is the name milkman a reference to Psychonauts?
<leoprikler>A bot essentially repeating the link (as with github/gitlab links) is not very useful to me either
<jlicht>I can see some value in it for logging purposes (e.g. so old IRC logs have _some_ context if the links end up being dead)
<leoprikler>Fair enough
<nckx>rekado_: True.
<nckx>leoprikler: I think [one of] Raghav's impeti for adding such a bot was people being ‘tricked’ into clicking shortened /guix links leading to porns.
<nckx>Not that I'm convinced that having ‘[XXX] Innocent schoolgirl gets big, hard drive for installing Guix!!’ spewed into the logs is much better, but it would avoid the trickery.
*nckx is in a no-faith-in-the-Internet mood, apologies.
<alextee[m]>it's completely useless if you're on, it shows a quick view of the URL
<alextee[m]>i can be your human "it's porn" bot
*jlicht imagines alextee[m] watching every linked movie just to be certain it is SFW
<nckx>‘It's research!’
<nckx>alextee[m]: I don't mind being IRC-first, even if some services add such features on their own.
<nckx>But I'm not sure I like it yet either. 🤷
<leoprikler>I think part of the appeal of your human "It's porn" or even better "It's spam" bot, is that you don't have to read clickbaity titles like "Installed Windows! What Happened Next Will Surprise You"
<zimoun>rekado_: I just discovered Wof! a front-end to Org-mode bug tracker Does it make sense to add specific annotation, e.g., X-Mummi-Bug: release-critical or X-Mummi-Bug: connected to 123456?
<sneek>zimoun, you have 2 messages!
<sneek>zimoun, civodul says: re "make dist" failure, see
<sneek>zimoun, janneke says: the "make dist" is fixed on master, can you mark the bug as a duplicate of 43005?
<milkman[bot]>GitHub - bzg/woof: Watch Over Our Folders
<zimoun>civodul, janneke: thanks!
<civodul>cbaines, mothacehe: i think it would make sense to use the Build Coordinator on berlin, to address the scalability issues and poor resource usage we see on berlin
<mothacehe>civodul: what particular scalability issue makes you think that. The gc collection time ? Anything else ?
<cbaines>I think architecturally, the Guix Build Coordinator doesn't require built things to be in the store, which I think makes it easier to serve more substitutes without running in to the limitations of a large store on a single machine
<cbaines>nars/narinfo files can always be baked in advance, something that I've realised can take a significant amount of time for large nars, and this work is also done on the build nodes, rather than the coordinator which distributes the work and saves on network traffic
<civodul>yes, there's that, and also in terms of scheduling the offloading model is too static
<civodul>and so we run into the scheduling issue with 'build-paths'
<civodul>in short, i think the offloading model (star-shaped, centralized) is good for small clusters of a few machines ("pets")
<civodul>beyond that ("cattle"), the Coordinator makes more sense
<civodul>also, anyone's build machine could listen to events of berlin's coordinator, which could be useful
<mothacehe>Ok, however I think we need to think more about GBC and Cuirass coordination. It would be really nice for Cuirass to be aware of the different builds going on on slave machines.
<mothacehe>For the metrics stuff I'm working on in particular.
<civodul>also, we might want to keep two backends for Cuirass (direct guix-daemon + BC), if that's not too much effort
<civodul>i actually don't know the coordinator well enough :-)
<civodul>i guess cuirass would receive build completion events from build machines
<civodul>and you could feed that into the metrics database
<civodul>something like that
<cbaines>I also think there might be something in the offloading to the Guix Build Coordinator that civodul suggested. It occurred to me that this would be a cool way for the Guix Data Service to build things through the coordinator
<civodul>cbaines: indeed
<cbaines>Currently the Guix Data Service computes derivations for the guix channel, then builds them, then the Guix Build Coordinator notices the new derivations, and builds them again
<mothacehe>Yes it could work this way. In fact I would rather integrate the Guix Build Coordinator directly into Cuirass to have a single code base related to CI.
<cbaines>but if you had it work in a circle, the Guix Data Service could have the Guix Build Coordinator build things earlier, resulting in substitutes being available earlier
<mothacehe>But I'm not sure how :)
<civodul>another use case: Andreas discussed with colleagues about the possibility to use their Kubernetes stuff to have a dynamic set of build machines that come and go
<civodul>the offloading model clearly isn't suited
<wleslie>guix has a CI solution? you lot have thought of everything
<civodul>with the coordinator, it may work better: new machines just subscribe to the event stream and do their job
<civodul>wleslie: it's what's running at , inspired by Hydra (of Nix)
<mothacehe>I also ran into this, maybe it could help us
<milkman[bot]>free/sheepdog - sheepdog - Genenetwork
<wleslie>great idea
<civodul>mothacehe: that looks interesting! by Bonface, we should talk to them :-)
<cbaines>mothacehe, in terms of integrating Cuirass, the Guix Build Coordinator and Cuirass both have "builds"
<cbaines>The Cuirass builds bit could be swapped out for the Guix Build Coordinator builds bit
<zimoun>civodul: “event stream“ meaning?
<civodul>zimoun: a stream of events emitted by Cuirass/BC, such as: new derivation to build, build X completed, etc.
<civodul>« un flux d'événements » :-)
<zimoun>over http?
<civodul>could be
*zimoun says civodul French is really good :-)
<civodul>cbaines: re big store, i think the NixOS folks do that: there's no single big store; instead, there's a huge S3 thing that contains substitutes "forever"
<rekado_>I thought sheepdog was Pjotr’s thing; last time I checked it looked like an idea with build system files outweighing code.
<zimoun>I understand, and it could be eaiser to add/remove machine to the poll.
<rekado_>see for example
<milkman[bot]>free/sheepdog - sheepdog/monitor/monitor-error.scm at master - sheepdog - Genenetwork
<civodul>(ironically, part of their motivation for SWH is reducing disk usage on S3 :-))
<civodul>rekado_: that file looks interesting
<civodul>syntactically incorrect, but it lets the reader's imagination work freely
<cbaines>civodul, yeah, I'm using Wasabi which is S3 API compatable for I've uploaded ~1TB of nars so far.
<civodul>cbaines: neat!
<civodul>cbaines, mothacehe: i wonder how we could move forward on this
<civodul>clearly we're at the crossroads: either we go ahead and make crazy changes in the daemon, or we take the Coordinator route
<civodul>i feel that the latter would be more fruitful
<civodul>perhaps a first step would be to set up the coordinator on berlin and a few nodes?
<rekado_>do we want another node with a separate store for the coordinator?
<rekado_>I still have another public IP that’s not in use
<civodul>just so we get more familiar with it, understand what setup looks like, and see how it performs in practice
<civodul>rekado_: maybe, dunno
<cbaines>I think packaging it for Guix might be a thing to do before that, but yeah, I think that's a good idea
<civodul>we can let cbaines be the coordinator of this effort :-)
<rekado_>then we can leave cuirass be cuirass and leave it’s big store
<rekado_>the build coordinator coordinator?
<civodul>exactly, in person!
<mothacehe>civodul: Yes that would be a good idea to move forward. I plan to keep working on CI stuff once I'm done with metrics. I can help the coordinator coordinator :)
<civodul>i run "guix processes" several times a day on berlin, and sometimes "guix offload status", and it's always depressing
<cbaines>I was going to mess around with the Guix Build Coordinator database schema today, but maybe I can start writing a Guix package and service instead
<civodul>yes, a package + service(s) would be a good first step
<rekado_>mothacehe, cbaines: if you can prepare an os-config in maintenance I would apply it to one of the build nodes
<rekado_>(in maintenance.git)
<rekado_>public IP would be
<civodul>perhaps i could deploy it at work on a couple of machines too, as a test
<civodul>cbaines: does the Coordinator expect to be able to fetch .drv's as substitutes?
<civodul>if so, there'll be changes to make in 'guix publish'
<cbaines>civodul, if they're not available. I use for the substitutes for
<civodul>still it's nice if the thing is self-contained
<cbaines>currently, the way I'm scheduling builds is by querying as well
<rain1>i sthere a project to make a GUI for guix?
<leoprikler>there was a suggestion years ago to have a packagekit frontend
<leoprikler>(or rather a backend talking to guix)
<leoprikler>there is an Emacs UI, but calling it "graphical" would be a stretch
<zimoun>cbaines: why do you need to query for scheduling?
<cbaines>zimoun, to get the names of derivations to build
<milkman[bot]> « scripts - guix/build-coordinator - Guix
<rain1>so nobody is planning on making a GUI
<mothacehe>rain1: it's part of Pierre N schedule I think. See:
<milkman[bot]>Guix: &ldquo;Search & Discovery&rdquo; NLNet grant 2020
<rain1>> search and discovery of Guix packages
<rain1>oh cool like pkgfile
<rain1>i was asking about this feature for a while
<zimoun>cbaines: thanks. And what produces these derivations? I thought that the database of was fed by Cuirass
<rain1>is this person in IRC?
<mothacehe>rain1: don't think so
<mothacehe>you can contact him by email though
<cbaines>zimoun, so the Guix Data Service actually does something similar to Cuirass in that it fetches new Guix revisions and loads the derivations from them in to its database
<cbaines>So both Cuirass and the Guix Data Service fetch from the Guix git repository, and extract derivations
<cbaines>In the case of Cuirass, it also builds them
<zimoun>cbaines: ok. It makes senses, I did not know that the machine running the GDS is computing derivations too.
<civodul>cbaines: it would be nice if you could write about how you envision an ideal Cuirass/DS/BC integration
<civodul>there's overlap but also differences
<cbaines>zimoun, yeah, it's somewhat standalone. If you look at a job, you can see the bits where it does "debug: Starting getting derivations for "...
<milkman[bot]>Guix Data Service
<andreas-e>civodul, cbaines: Let us call this a whitepaper to add pomp to circumstances!
<civodul>the "Putting It All Together" whitepaper
<cbaines>So, I can talk about what the Guix Data Service and Guix Build Coordinator do, and how they complement each other when used together
<cbaines>civodul, you've done more thinking than me on what the Guix Build Coordinator could bring to Cuirass though, in terms of perhaps offloading Cuirass builds to the Guix Build Coordinator through the guix-daemon
<zimoun>cbaines: thanks for the link.
<cbaines>Either that, or mothacehe's thoughts about integrating Cuirass and the Guix Data Service code could work
<civodul>cbaines: well, let's all share what we think could be done!
<mothacehe>cbaines: If you can write something about the current state of GDS + GCS, then I'll add my thoughs on Cuirass integration.
<civodul>cbaines: your viewpoint is interesting to me because you're the one who knows these things best :-)
<civodul>mothacehe: yay!
<cbaines>mothacehe, cool, I can give that a go, I guess an email will work best
<zimoun>Where can I find the doc of ’load-in-vicinity’ (Guile) used by ‘guix repl’?
<mothacehe>You can have a look to (ice-9 boot-9) in Guile sources.
<zimoun>mothacehe: thank you
<civodul>zimoun: it's not documented i'm afraid
<civodul>so yes, boot-9
<tribals>Hi, folks! Complete newbie here (sorry in advance, huh :)
<zimoun>civodul: thanks. :-) Well, the question is: does (load-in-vicinity ‘.’ ‘foo.scm’) run with all the modules loaded say extended %load-path outside ’foo.scm’ or only execute ’foo.scm’ with the core modules. Because channels are not seen by ‘guix repl foo.scm’
<rekado_>unfortunately, adding libstd++-headers to the inputs of gcc-arm-none-eabi-7-2018-q2-update has had no effect.
<jlicht>zimoun: is that perhaps the very same issue as
<jlicht>zimoun: either way, the workaround described in that report should probably also help you for now ;)
<tribals>I'm trying to write system.scm for my ARM board: The first thing I need to do is to configure bootloader. Seems like there is no pre-defined package for my board (Khadas VIM3L). So, I'm trying to define my own. I checked mainline u-boot sources, seems like basic support for my board in place. But, according to docs:, I need some
<tribals>firmware in order to build working u-boot. This firmware is available at github, in vendor's fork of u-boot repository. How can I include it in my own u-boot package declaration?
<milkman[bot]>Guix on an ARM Board — 2019 — Blog — GNU Guix
<jlicht>FWIW, it seems guix repl can't load any channel code, not even from the interactively via the repl (without the GUILE_LOAD_PATH workaround) :/
<leoprikler>zimoun: it appears `guix repl` does not set up the load path in the same way e.g. `guix package` does
<civodul>jlicht: yeah there's a bug report for it, haven't investigated yet
<jlicht>I think it is also something that was 'a thing' with gwl when I first tried to use it _without_ installing guix into my profile :-)
<leoprikler>what happens if you try to evaluate (%package-module-path)?
<zimoun>jlicht, civodul, leoprikler: thanks. I am looking at
<zimoun>and yeah, it looks like really similar
<jlicht>leoprikler: that at allows me to load channel modules interactively on the repl. Spooky :D!
<jlicht>wow, typing problems galore today: s/at/at least/
<leoprikler>ahh, yeah, I think I've discussed that once before
<civodul>zimoun: great!
*civodul goes afk for a bit
***sneek_ is now known as sneek
<pierre-antoine-b>I do not understand what is going on with one of my attempt to create a guix package
<leoprikler>okay, I know now, why this fails
<leoprikler>`guix describe` does not care to resolve channels, because it doesn't think we're running guix
<leoprikler>this is caused by (set-program-arguments script). Since we are dealing with parameters here, one could probably parameterize them before that call
<jlicht>You meant `guix repl` then?
<leoprikler>Nope, `guix describe`, but through `guix repl`
<leoprikler>the logic to determine %package-module-path uses some `guix describe` magic, that gets confused by setting the program arguments
<jlicht>leoprikler: but that would still have nothing to do with guix not being able to find channel commands such as `guix workflow`?
<leoprikler>not finding guix workflow is due to a missing `guile` in your environment most likely
<leoprikler>but I was talking about something different here
<jlicht> it seems that `(guix ui)` bails when it can't find the guile module for the command, but since it hasn't called (%package-module-path) yet, the load-path hasn't been enhanced to be able to find modules in the 'union' of guix channels :/
<rekado_>‘guix workflow’ … as in gwl?
<jlicht>rekado_: the very same
<rekado_>that requires an addition to Guix: an env var for Guix extensions
<jlicht>Because of the extra dependencies such as wisp and what not?
<milkman[bot]>Extending Guix without using the Guile load path
<leoprikler>jlicht: `guix environment --ad-hoc guile gwl -- guix workflow ...`
<rekado_>the GWL isn’t supposed to be used as a channel because that precludes pre-compilation and makes handling other dependencies messy
<rekado_>leoprikler: yes, that’s one way around it, but I think it would be nicer to do without explicitly modifying GUILE_LOAD_PATH here
<jlicht>tangent, but why don't we pre-compile channel code?
<rekado_>‘guix pull’ compiles it
<wargreymon2020>Hi, i ran into error on emacs-guix when executing 'M-x guix' followed by 'c' which is 'guix shell command' on minibuffer.
<PotentialUser-90>hello, I installed guixsd 2 days ago and while tyring to install emacs today on i686 it fails with this message "build of /gnu/store/a6k8q4rgw8bin0pgcrfbpla3363af36k-mailutils-3.10.drv failed"
<wargreymon2020>Error in evaluating guile expression: ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<sneek>Welcome back PotentialUser-90, you have 1 message!
<sneek>PotentialUser-90, apteryx says:
<milkman[bot]>Group:Guix/Wishlist - LibrePlanet
<wargreymon2020>Error in evaluating guile expression: ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<wargreymon2020>In procedure scm_lreadr: /root/.config/guix/current/share/guile/site/3.0/guix/scripts/pack.scm:78:23: Unknown # object: #\~
<jlicht>wargreymon2020: it seems that the read-hash-extend for g-exps has not been loaded (yet)
<wargreymon2020>thought so, but how? I dont know if it is a new bug or my system is at fault.
<jlicht>wargreymon2020: you could run `(use-modules (guix gexp))', and see if that helps
<PotentialUser-90>does anyone have a successful install of emacs on i686? check phase for mailutils fails for me
<raghavgururajan>nckx: Hmm. Shall we kick him out for now? Because it won't be fixed anytime soon.
<wargreymon2020>jlicht, the command is supposed to fire up guix repl and everything including the modules.
<pancak3>PotentialUser-90: I'm doing a build on my x86_64 machine using this command 'guix build --system=i686-linux mailutils'. It fails just like you said
<jlicht>wargreymon2020: hmm, see it too
<PotentialUser-90>pancak3: thanks for looking into it. any idea on a potential fix?
<pancak3>hmmm... I've never debuged something that isn't for my native system. I can't promise anything but I'll take a look
<PotentialUser-90>pancak3: thank you!
<pancak3>what's "nc"? it tries to call "nc -h"
<pancak3>oh, I think it's netcat. I shouldv'e known that :P
<pancak3>I like having guix environment for getting build tools, but I also use guix environment --ad-hoc a lot. Unfortunately, I always forget to add --ad-hoc when I need it :P I think it'd be super helpful mentally to have a different alias for guix environment --ad-hoc. What would be a good name for it though?
<pancak3>guix use?
<leoprikler>imo --ad-hoc just needs a single-letter form
<pancak3>egh. I really forget it. I do the whole: guix environment, then wait "no executable?", then ls `guix build thing`/bin, ok so I have to right executable, what's going on?
<pancak3>Like it really doesn't register to me that they are two different things :P
<leoprikler>well, some do argue, that that should be the default
<leoprikler>maybe in Guix 2.0 ;)
<pancak3>add a guix build-environment to do the old thing. would make more sense in my mind. but also don't change defaults on a whim :P
<leoprikler>that would still count as "changing defaults" though
<pancak3>well ya. switching guix environment would. That's why I was suggesting something like a guix use alias
<leoprikler>use is a really bad word tho
<leoprikler>like, what does `use` even mean?
<leoprikler>environment is a much better metaphor regardless of the way you use it
<pancak3>I do agree with you there. my english no gud
<leoprikler>Well, you're not alone. In all of programming history, there hasn't been a better one yet
<pancak3>finally got to the actual error message for mailutils on i686
<pancak3> +sends: mu_mailer_open() failed: Network is unreachable
<pancak3>what am I even supposed to do with this?
<pancak3> +smtpsend: localhost:43687: Temporary failure in name resolution
<pancak3>just a bunch of random network errors
<efraim>I thought it was fixed with the aarch64 fix
<pancak3>when did the aarch64 fix happen? do I need to do a pull?
<efraim>Few days I think. I'm not at my computer atm
*pancak3 is rebuilding even though I think i did that yesterday
<pancak3>ok, exact same issue. That did not help
<pancak3>is there a way to skip phases from the command line? It'd be cool if you could something like guix install --without-phase=mailutils=check emacs
<civodul>pancak3: not possible yet, but definitely doable!
<civodul>rekado_: GUIX_EXTENSION_PATH sounds like a good idea! (somehow i had overlooked that message of yours)
<pancak3>PotentialUser-90: Sorry. I'm really not sure how to troubleshoot this. I tried building it from master but that would require some more work since we currently build from a release tar. Also I do have a few things I really should get done today :P
<pancak3>I do gotta ask, why do we prefer building from release tars when we have access to the git repo tag? If we did it from the repo, it'd be easier to use the latest release to check if our bugs are already fixed
<reepca>just realized I sent my patch to bug-guix and not guix-patches, welp
<pancak3>you can add the patch tag after the fact
<pancak3>I don't actually know what that does or if that would fix the problem. I just know you can
<reepca>more worrying though is that I didn't get any confirmation email, it hasn't shown up on, and I sent it around 20 hours ago
<reepca>I hope it's not related to using xoauth2 with gmail, it took me around 4 hours to get that set up...
<pancak3>forgive my ignorance because I've only bothered to learn a few nicks here, this isn't your first submission right?
<reepca>indeed it is not
<leoprikler>pancak3: easier how?
<pancak3>leoprikler: Well I wanted to do guix build --with-git-url=blah mailutils to see if that fixed the problem, but it didn't like that :/
<pancak3> command "tar" "xvf" "/gnu/store/5xydiblzc8rgnw60c2sjrgrxjwnix2b5-07rnywb4qwrz0vamsg2d7fwbld9gyyq0-mailutils.git" failed with status 2
<pancak3>but still better than last time. thanks for that nugget :)
<leoprikler>looks like you'll have to `make dist` locally first
<peanutbutterandc>Question: When the 'configure' phase of a package says something about an option package 'pkgconfig' not being found, it wants that in (native-inputs) as opposed to (inputs), I presume?
<peanutbutterandc>Thank you
<pancak3>does anyone have yubikeys working/ knows how to debug them? I added lubu2f-host to my udev rules, and have the pcscd service running. It even works on the yubico demo website. However, gmail in chromium and icedove really doesn't like it
<pancak3>I've done way to many searches on the internet and spent way to much of my time debugging this :P It's like the last thing I need to do before I can fully switch to guix
<peanutbutterandc>Question: This package I'm brushing up on wants qtwebkitwidgets so that it's users can log in to Do I put the optional dependency in or do I leave it out?
<peanutbutterandc>in the gnu distribution
<rekado_>sneek: later tell pancak3 I have a yubikey 5 nano and I’m only going to use it as a smartcard. I’m working on extending this guide for Guix:
<sneek>Got it.
<milkman[bot]>GitHub - drduh/YubiKey-Guide: Guide to using YubiKey for GPG and SSH
<alextee[m]>how do you build autotools projects?
<str1ngs>rekado_: hello, did you get my message about regarding gstreamer 1.80.0?
<alextee[m]>./ ./configure: /bin/sh: bad interpreter: No such file or directory
<alextee[m]>command "./" failed with status 126
<alextee[m]>(while packaging)
<rekado_>str1ngs: no, where?
<str1ngs>rekado_: ah I was while looking at using jack1 with gstreamer I noticed that gsteramer has a 1.80.0 release. which kinda dovetails with some other work I have been doing to add webrtc support to gstreamer. I have a working WIP for 1.80.0 but I was wondering if there was a branch I should work off instead of master. I would imagine this would produced quite a few rebuilds.
<rekado_>str1ngs: core-updates is the branch for world rebuilding
<rekado_>but you may also want to check wip-desktop
<rekado_>that’s where raghavgururajan upgrades and improves Gnome
<rekado_>it might include gstreamer upgrades as well
<str1ngs>rekado_: okay I'll user that. also the gstreamer:doc output no longer exists it now has its own source tarball. gstreamer-docs is there a mechanism to replace gstreamer:doc with say gstreamer-doc. or should I use multiple sources to replicate gstreamer:doc. the build/install for gstreamer-docs is a copy recursive.
<str1ngs>raghavgururajan: ^
*rekado_ doesn’t know
<rekado_>we have a deprecation mechanism but not for individual outputs
<str1ngs>okay I'll try to keep the docs output using multiple sources just need to find an example the use more then one source. I'll talk with raghavgururajan to avoid duplication of effort as well.
<rekado_>str1ngs: thank you!
<str1ngs>no problem.
<sneek>Welcome back leon, you have 3 messages!
<sneek>leon, lfam says: Krita should be working now, as of Guix Git commit 5f63905096e4560. See <>
<sneek>leon, lfam says: There was a problem with my fix for Krita so I reverted it
<sneek>leon, lfam says: Krita should be fixed for real now
<milkman[bot]>guix.git - GNU Guix and GNU Guix System
<luis-felipe>Hi, I recently did a Guix system reconfigure and package upgrade and since then I can't write diacritics in Emacs. Do you know anything about this?
*luis-felipe is using guix fb24a4d
<leoprikler>luis-felipe: this is likely a result of the 26.3 → 27.1 upgrade
<leoprikler>stuff in X11 changed and Emacs doesn't like it
<luis-felipe>For example, when trying to write ó, ò, ö, etc., I hear a beep, and Emacs says: "<dead-grave> is undifined", and so on.
<leoprikler>do you have emacs-leaf or don't you?
<luis-felipe>Oh, I see...
<luis-felipe>No, I don't know what that is
<leoprikler>it's a way of handling configuration
<leoprikler>it's fine if you don't
<leoprikler>try the following in your init.el:
<leoprikler>(require 'iso-transl)
<leoprikler>(define-key key-translation-map KEY DEF)
<leoprikler>where KEY DEF is e.g. [dead-cedilla c] "ç" and so on
<leoprikler>iso-transl comes with a lot of good definitions out of the gate, but it's lacking some
<luis-felipe>I'll try the defaults to see if it works, because defining them myself doesn't sound fun
<luis-felipe>leoprikler: It works, thanks.
*luis-felipe goes to read what's new on Emacs 27...
<leoprikler>defining keys is fairly simple with leaf, mine look like
<milkman[bot]>GNOME Pastebin
<leoprikler>yeah milkman ly2
<leon>Hello! I have a problem, maybe someone can help me? I installed rsync via the GUIX package manager. On my server as well as on my computer. And I have ssh keys all configured to connect to my server. And when I try to use rsync on my computer, bacsh says that the rsync command is not found. When I install rsync with the apt package manager, it works fine though. Anyone knows of a way to fix that?
<leon>If I use rsync locally it does work though. It's only when I use rsync between my computer and server, so via ssh. The same goes for unison, it's a file synchronization and backup tool.
<rekado_>leon: Guix installs packages to ~/.guix-profile, so you will need to have ~/.guix-profile/bin on the PATH that the SSH session uses.
<rekado_>leon: I don’t know how to make sure of that, unfortunately. SSH has an option to respect an environment file on the remote, but I think it’s disabled by default
<rekado_>one really crude way to make it work is to link ~/.guix-profile/bin/rsync to a location that is looked up by default (such as /usr/local/bin or the like)
<rekado_>but the details depend on the configuration of SSH
<leoprikler>Another solution would be to try starting bash (or zsh or whatever) as a login shell
<leoprikler>in your ssh invocation
<leon>OK, so in case we don't find a better solution, I can set up the symbolic link to make it work as a last resort. Before that, do you know how I could set up the SSH configuration to have the guix path in its PATH variable?
<darkpsi>hi there
<darkpsi>i am having some problems installing with encrypted root
<civodul>leon: you're using Guix on a "foreign" distro, right?
<darkpsi>nope running from the install
<civodul>leon: on Guix System, there's this trick in the default ~/.bashrc:
<milkman[bot]>shadow.scm\system\gnu - guix.git - GNU Guix and GNU Guix System
<darkpsi>i have wrote my config with the luks root defined in mapped-devices and added the mapped name in file-systems
<darkpsi>with the on the root file system set to dependencies mapped-devices
<civodul>darkpsi: hi, what problem exactly do you have?
<civodul>what do you observe?
<leon>civodul: yes. Debian on my server, and Ubuntu on my laptop (it's a new laptop, I couldn't make Debian work on it because of the USB-C port... -_- )
<alextee[m]>GNOME’s default web browser “GNOME Web” becomes a decent browser with this release. Web introduces tracking protection, audio and video blocking options, tab specific mute option, and easy import of bookmarks, setting from Chromium.
<alextee[m]>oh yeah
<alextee[m]>new gnome hype \o/
<str1ngs>awww yay!
<bavier[m]1>cool, I look forward to trying it out
<str1ngs>if you like Epiphany and looking for something extensible with scheme. you might like nomad
<str1ngs> recent screenshot of nomad.
<darkpsi>@civodal sorry for taking a long time to reply. once i have ran "guix system init" and reboot i get a message saying it can not find a the drive with the uuid of my unecrypted partition
<darkpsi>looking at the resaulting grub.cfg i can not see a GRUB_ENABLE_CRYPTODISK=y
<civodul>darkpsi: so you didn't use the graphical installer?
<darkpsi>@civodul nope i wrote the config. it installs but the bootloader installed does not try to find the /boot dir on the encrypted drive though cryptodisk
<civodul>darkpsi: i'd recommend comparing against the examples in the manual, and then posting your config so we can have a look
<darkpsi>@civodul compared agains the manual and thumbed though it quite a bit will upload my config to paste bin and give you the link just give me a second
<nckx>Good evening Guix.
<pancak3>how you doing nckx?
<sneek>pancak3, you have 1 message!
<sneek>pancak3, rekado_ says: I have a yubikey 5 nano and I’m only going to use it as a smartcard. I’m working on extending this guide for Guix:
<milkman[bot]>GitHub - drduh/YubiKey-Guide: Guide to using YubiKey for GPG and SSH
<nckx>darkpsi: GRUB_ENABLE_CRYPTODISK isn't a GRUB configuration option; you won't find it in (any) grub.cfg or in Guix. It's best not to compare too much to other distributions.
<pancak3>rekado_: nice guide, finally figured out my issue. I'm using some offbrand key that isn't actually a yubikey :'(. I've since used it to do stuff like sign into github with no issues. But my work gmail still won't accept it on Guix. It works on Arch and I'm very confused.
<nckx>raghavgururajan: I could kick it if we decided to, but I thought you had full control?
<rekado_>pancak3: what’s the actual device name? lsusb could help.
<rekado_>I haven’t done anything fancy with the yubikey yet
<nckx>Hullo pancak3. Can't complain. But the world owes us all a glorious 2021. 🤞
<rekado_>how does this “sign into github” thing work?
*rekado_ has to leave
<pancak3>redako_: take care :) it seem my key (Feitian ePass) kinda works on Guix. It's like webauthn works and fido u2f doesn't or maybe the other way around?
<darkpsi>i am going to reboot my machine i will be back in a second
<pancak3>nckx: Is taking care of bug 42816 still in your todo list? It's really not urgent, but I'd like to stay ontop of my submissions :)
<pancak3>nckx: also I don't know if I told you or not, but the guix debbugs alias is up and working now so we could start using user tags if we wanted
***stikonas_ is now known as stikonas
<darkpsi>hi there sorry about that pastebin of config
<milkman[bot]>(use-modules (gnu) (gnu system nss) (gnu packages certs))(use-service-mo -
<darkpsi>and paste bin of lsblk -f
<pancak3>wow. The services list is so bare. I once tried to step down to base-services from desktop-services, but I gave up
<darkpsi>@pancak3 just trying to get encrypted boot to work first then populate it
<pancak3>if you do what you're doing, and only have one partition, would you be able to only have to enter your password once or is the double password thing caused by something else?
<nckx>pancak3: Erm... My to-do list escaped during the night and hasn't returned yet. I suspect it found a new home somewhere else, and that I'll soon start receiving postcards with closed bug numbers.
<pancak3>nckx: All good man. I do wish I could help you guys and lighten the load, but I'm not knowledgeable enough, and now I'm a full time engineering student, working part time :/
<darkpsi>@pancak3 i am fine with having to enter the passphrase twise just want it to boot atm it complains that it can not find the unencrypted partition and not password prompt .
<pancak3>well other than the two vs one partition thing, the only other difference I see is that you point directly to a /dev/mapper device and I do this instead: (device (file-system-label "guix-root"))
<nckx>pancak3: Since you ask <> I'll take a closer look before merging. Expect mail.
<nckx>Shut up.
<nckx>pancak3: Tomorrow, I mean.
<darkpsi>@pancak3 worth i try i guess
<pancak3>nckx: There is really no rush. I just hate to see things forgotten.
<nckx>pancak3: There are hacks around the hard requirement for both GRUB and Linux to unlock the same partition, and there's no reason they couldn't be done on Guix, but they're not built-in ATM.
<nckx>But you can do literally anything in your Turing-complete system .scm, including stuffing a key file into the initrd.
*nckx → 😴, good night all.
<pancak3>nckx: Take care!
<mroh>sleep well nckx.