IRC channel logs


back to list of logs

<nckx>g_bor[m]: That makes sense, thanks.
<Mrtn[m]1>"Alternately, see `guix package --search-paths -p ~/.guix-profile"
<Mrtn[m]1>nckx: I think we got it cleared up .. whenever something happens to a package involving the search path or similar .. guix mentions that it is important the config is working, however it doesn't mean anything is necessarily wrong.
<Mrtn[m]1>Thank you guys for the help, nckx and g_bor
<nckx>Mrtn[m]1: Yep. It's not a warning or error based on some misconfiguration. It might be useless to run the suggested command but it will never hurt.
<Mrtn[m]1>nckx: That was what got to me .. I thought I tried everything, to get the "error/warning" to disappear .. and all this time, it was just some extra info. :D
<nckx>Mrtn[m]1: I'm sorry I didn't take you as seriously as I should have. I'm dealing with a bit of a situation here (hint: it's after midnight and I'm trying to find a plumber), my mood should not have made it to IRC but it did.
<Mrtn[m]1>nckx: In that case you did really fine ... I hope you manage to get a plumber. Are you in Germany?
<nckx>No, but close. 🙂
<Mrtn[m]1><nckx "No, but close. 🙂"> I'm in the same Timezone as you, that is why I guessed Germany. :)
<Mrtn[m]1>Oops .. sorry for the quote.
<nckx>No prob, I've seen far worse from Matrix.
<g_bor[m]>other window...
***daviid is now known as Guest3988
***akko is now known as stallman
***stallman is now known as akko
<anon987321>hi guix
<anon987321>i was trying out profanity
<anon987321>the guix package doesn't have omemo working, although it's supposed to have (it uses the omemo configure flag)
<anon987321>i made a derivation of that package, and i got it working by putting the omemo dependency in `inputs` instead of `native-inputs`
<brendyyn>Strange. I'm trying to reconfigure and somehow I'm getting a conflict between two versions of glib, one for network-manager and one for glib
<brendyyn>Franciman: have you seen streamlink ?
***sneek_ is now known as sneek
***modula is now known as defaultxr
<PurpleSym>Trying to get sssd up and running. It fails though, because it can’t open /gnu/store/…/var/lib/sss/db/config.ldb (read-only file system). Should’t it be looking in /var/ instead?
***davie` is now known as davie_
<civodul>Hello Guix!
<dftxbs3e>hey Ludo!
*vagrantc waves
<dftxbs3e>I just saw that bootstrap gcc is now gcc-7 as well.
<dftxbs3e>I'll try building from scratch again, I think it might work out of the box.
<dftxbs3e>the bootstrap binaries I had were gcc 4.9.x
<dftxbs3e>(for powerpc64le-linux-gnu)
<jonsger>dftxbs3e: when did you made your last boostrap with gcc 4.9.x?
<dftxbs3e>jonsger, few months ago, with the help of samplet
<vagrantc>bootstrapped all the way to 2017! :)
<dftxbs3e>I'm currently updating a GNU Guix VM
<dftxbs3e>then I'll do a build
<jonsger>dftxbs3e: building bootstrap-tarballs should be fine, but on power itself you will see build failures
<dftxbs3e>that's the failures I had
<jonsger>dftxbs3e: looks familar :P
<civodul>we'll need the ppc64le working group at the Guix Days!
<dftxbs3e>civodul, when/where is that?
<civodul>dftxbs3e: right before FOSDEM
<civodul>so 30th and 31st of January
<dftxbs3e>civodul, okay I see! I'll try to be there
<dftxbs3e>and where is that happening?
<dftxbs3e>jonsger, did you bootstrap powerpc64le-linux-gnu from bootstrap-tarballs that include gcc-7?
<jonsger>dftxbs3e: yes /gnu/store/l5fj50x2davhflvqj60bvlhaw1ygs6dk-gcc-bootstrap-0/bin/powerpc64le-linux-gnu-gcc-7.4.0
<dftxbs3e>jonsger, hmm I may have a patch to fix the error you were getting then.
***zap` is now known as davie`
<jonsger>dftxbs3e: oke, let me see?
<dftxbs3e>jonsger, I'll get back to you, I have to test.
<dftxbs3e>it has to be somewhere around this commit: or any other commits I pushed
<civodul>dftxbs3e: it's in downtown Brussels, see
<civodul>there'll be more info coming soon i guess
***emyles` is now known as emyles
<dftxbs3e>civodul, alright, thanks.
<civodul>glad to see y'all working on it, dftxbs3e, jonsger & narispo
<jonsger>oh this wiki looks kind of fancy
<efraim>Unless something changes I'm bringing my G4 to FOSDEM and Guix Days
<efraim>Also, I tried using python3 for the linux libre deblobbing script, still failed
<efraim>Using gawk took 90 minutes instead of 54 but dropped python2
<efraim>Not sure it's worth it though
<civodul>efraim: a G4, like the one i had at work ca. 2004? woohoo! :-)
<civodul>howdy janneke
<efraim>2005 actually :)
<efraim>I still need to see what I need to stick an ssd inside it
<janneke>hey civodul!
<civodul>efraim: it's pretty big though?
<efraim>I have a 12" and a 14", the 14 is in better condition. About twice as thick as my wife's lenovo yoga
<jonsger>I hope I get remote access to my blackbird outside of my home network until February. If I'm able to make it for FOSDEM
<efraim>jonsger: ssh over tor. Hasn't failed me yet
<jonsger>efraim: oke sounds weird. I guess the problem is that my ISP does DS-Lite
<dftxbs3e>ssh over tor is #1 for remote access
<dftxbs3e>works around any NAT
<civodul>yup, i set up Tor on servers for that reason
<civodul>bavier: do you remember how we ended up no making openssh a dependency of openmpi?
<civodul>i'd like to revisit that
<dftxbs3e>civodul, nckx: also, an info that might interest you regarding POWER9, there is pre-release CPUs (DD2.1 revision) that are vulnerable to Spectre and have broken virtualization but otherwise work that are sold for much much cheaper by RaptorCS, that might be great for a build farm.
<dftxbs3e>you should email if you want to purchase these
<civodul>ah, good to know
<civodul>thanks for the hint!
<dftxbs3e>the stock is limited as they are not being produced anymore
<dftxbs3e>but latest news did tell me that there is still some stock left
<nckx>dftxbs3e: Nice, thanks! I'm going to paste that in an e-mail to Guix sysadmins if that's all right.
<dftxbs3e>Sure, go ahead.
<dftxbs3e>also, as said on the mailing list, don't hesitate to join #talos-workstation
<nckx>Heh, turns out I was lurking there & forgot.
<nckx>dftxbs3e: Let's say (this is just me speaking with my clueless-hat on) Guix chose something like <>. Would 2 be enough for the coming year or, say, 2?
<nckx>Yes I should ask this there but new rooms be intimidating, yo.
<dftxbs3e>nckx, what do you mean would 2 be enough?
<nckx>Build farm machines.
<dftxbs3e>nckx, I do not know about your workloads, what do you have right now for building?
<dftxbs3e>I would encourage you build the machine yourself buying a motherboards and CPUs from RaptorCS, it's much cheaper.
<dftxbs3e>POWER9 CPUs are SMT4, so for 1 core, you get 4 threads, and compiling workloads very much profit from that.
<nckx>dftxbs3e: OK, thanks. Yeah, sorry, I don't know how to measure/express our build farm churn. I don't know enough to ask the right questions, full stop :-/
<dftxbs3e>nckx, Alright well, ask someone who knows for the current x86 configuration that you have and I'll give you an equivalent in the OpenPOWER world
<dftxbs3e>nckx, but, to be clear, two of these machines looks very overkill.
<dftxbs3e>A single of these with 2x 18 cores CPUs should be **well enough**
<nckx>Oh, really? I wanted to avoid buying too few 😛
<dftxbs3e>nckx, yeah, the motherboard alone is 2k USD for the Talos II EATX dual socket one
<dftxbs3e>judging from how GNU Guix is built, you could cross compile everything from POWER9
<dftxbs3e>also please note that OSUOSL provides POWER8 VMs rather than POWER9 (it depends, they might also give you POWER9, but verify with lscpu), POWER8 is less performant than POWER9
<nckx>OTOH, you might consider berlin's x86 size ‘overkill’ to. I'm looking for (up to date, accurate) numbers but it's bigger than most might expect.
<nckx>dftxbs3e: I've asked for 9 explicitly, but thanks for the hint.
<dftxbs3e>nckx, well if you have the budget, I have nothing against you getting an overkill setup like the one I bought for home :-)
<dftxbs3e>nckx, is your current build farm based on AMD Opteron with that libreboot compatible ASUS board?
<nckx>dftxbs3e: No, that was tried once and the experience was not good (that was actually the ‘bad experience’ I mentioned in my POWER mail; it was an x86 but there was some overlap in vendors IIRC).
<nckx>The berlin head node is an Intel(R) Xeon(R) CPU E5-2695 v4.
<nomr>So, I'm still trying to learn to debug my breaking network-active channels.scm . When I pass the code to guile, it says "no code for module (guix http-client)"
<nomr>How do I make guile recognize guix modules?
<civodul>hi nomr!
<civodul>nomr: you need to make sure Guix' modules are on GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH
<civodul>if you used 'guix repl', they're there
<civodul>otherwise you need to pass -L ~/.config/guix/current/... -C ~/.config/guix/current/...
<civodul>(admittedly inconvenient)
<nomr>Hi =) thanks so much. I was searching the docs for "guix repl" but couldn't find it.
<civodul>oh, i guess we should fix it
<nomr>Ah the guix binary is more than just the package management section of the docs =) thank you again
<civodul>yup, yw!
<sneek>raghavgururajan, you have 2 messages.
<sneek>raghavgururajan, nckx says: If adding --pure didn't fix ‘./configure --localstatedir=/var’ inside the environment, could you run the following outside of the environment:
<sneek>raghavgururajan, nckx says: guix environment --pure guix --ad-hoc autoconf automake gettext texinfo graphviz help2man -- sh -c "echo 'int main() { return 0; }' > FOO.c && gcc FOO.c && ./a.out"
<raghav-gururajan>nckx Thanks! Yeah, "--pure" did not work. I am gonna try your other option.
<roptat>raghav-gururajan, I found that sometimes running configure in a guix environment doesn't work, because configure embeds some store paths from an older guix environment which was gc'd. Did it happen to you? in that case simply running ./bootstrap again fixes it
<nckx>I've noticed that too. In this case, bootstrap was run immediately prior. (Well… if they listened to me 😛)
<alloy>Anyone some idea on the lookup-compiler error from cuirass as described here: I'm running into the same problem on an machine running aarch64-linux.
<civodul>hi alloy
<civodul>alloy: did you spot any mistakes compared to ?
<civodul>well, not mistakes but rather differences
<alloy>Nope, took that as a reference. It's just very wierd. Also tested a second spec with guix-modular which works just fine
<alloy>It think the problem is somehow while evaluating gnu-system.scm
<alloy>What is different is that I have the package-path-inputs diffent
<alloy>And I use a manifest, like in the example of the manual
<alloy>But, it doesn't make any difference if i use the all subset
<civodul>alloy: can you paste the exact backtrace that you have?
<civodul>the line numbers in the post above are off
<alloy>Here is the backtrace:
<wingo>no guix package for larceny; humm :)
<wingo>i am pleased to see that building chez scheme is also not an instantaneous thing
<wingo>i have a dumb guix question
<wingo>i have an ubuntu machine that runs guix. i use guix pull these days. in my /var/guix/profiles/per-user/wingo, i have both guix-profile and current-guix links out to the store
<wingo>is guix-profile the old spelling for this thing? should my ~/.guix-profile link to ~/.config/guix/current instead of /var/guix/profiles/per-user/wingo/guix-profile ?
<wingo>or is there a difference between guix-profile and current-guix
<civodul>wingo: current-guix is for guix itself
<wingo>for some months now guix has been giving me locale warnings so i assume that i have something messed up
<civodul>i.e., the thing that "guix pull" populates
<civodul>whereas ~/.guix-profile is your profile, as always
<wingo>i see. tx :)
<civodul>so i guess "guix install glibc-utf8-locales" and setting GUIX_LOCPATH will help :-)
<wingo>i did both of those things :)
<wingo>will poke
<alloy>civodul: any ideas on the problem?
<civodul>alloy: apologies, i switched contexts
<civodul>i roughly see what code is involved, but no idea
<civodul>could you boil it down to a simpler config and send a bug report to
<rekado>nckx: the berlin head node doesn’t do any compilation.
<rekado>we have about 25 nodes, all very old.
<nckx>I know, but I don't know/have time to figure how to ssh into the build nodes. Tried the IPs in berlin-nodes.scm, no answer, got bored.
<anon987321>wingo: just installing the locales and guix_locpath isn't enough, it seems
<nckx>rekado: berlin is so much beefier than I expected. Doesn't jive with the feel of ci.guix at all.
<anon987321>issue only stopped for me after exporting $LANG and $LC_ALL
<rekado>the new build farm consists of 24 x Dell PowerEdge R6415 and 6 x Dell PowerEdge R7425.
<rekado>nckx: you should be able to hop onto the build nodes from berlin as either root or hydra.
<nckx>dftxbs3e: ☝
<nckx>OK. I tried sudo [-i] but really didn't give it much thought or time. Thanks!
<rekado>the R6415 comes with the AMD EPYC 7551P
<rekado>the other one comes with two AMD EPYC 7451.
<rekado>the current build nodes are from 2009, I think. They are old Sun machines.
<zig>wow I would love to have one of those for my search engine :)
<rekado>Madalin said he would install one of the new servers today if IT actually finished wiring up the switches as promised.
<rekado>we’ll see.
<zig>guix success is motivating :)
<nckx>rekado: Cool!
<civodul>rekado: neat!
<chrislck>the first time I've really managed to use guix correctly, thanks to
<chrislck>rather impressive all round
<roptat>so, re the presentation I'll give next week, is there any message I should pass that I could have forgotten? The public is mostly made of system administrators, network people and developers
<civodul>roptat: IME sysadmins are rather conservative, and they have their habits with CentOS, Debian, etc.
<civodul>so you need to make sure to bridge between what they do on a daily basis and what Guix does
<civodul>(also: Ansible, Puppet)
<civodul>this is kinda hand-wavy i guess :-)
<roptat>that's mostly the plan so far :)
<civodul>good :-)
<civodul>just to say that you shouldn't start with "functional programming, derivations, garbage collection, lambda calculus, blah" ;-)
<civodul>did you plan to mention "guix deploy"?
<roptat>I don't understand it well enough, so I didn't include it, but I could say a few words
<civodul>maybe just as an opening in the end
<civodul>there's not much to understand: it's "guix system" for groups of machines
<roptat>I don't even have the word "functional" in the presentation :)
<jonsger>rekado: that is a total of 1344 cores and only for Guix?
<chrislck>how about "a blockchain of images"
<nckx>Yess. The meme is spreading.
<nckx>roptat: I avoid ‘functional package manager’ entirely in non-programmer context because everyone thinks they're first to make the ‘oh, you mean it works? good for you’ joke and it detracts from the message.
<nckx>Blockchain package manager FTW.
<nckx>Should've filed a patent.
*chrislck claims prior art.
*chrislck allows its use GPL3 though
<nckx>chrislck: Which prior art?
<chrislck>a few minutes ago :)
<nckx>Oh bud, I've been pushing that bad meme for years 😛
<nckx>And, increasingly, while sober.
<chrislck>in all seriousness, hello all, I'm one of the committers for gnucash and only now getting into guix
*chrislck can't claim to understand guix in any productive amount of detail, but i'll try keep an eye on it
<nckx>chrislck: That's great to hear! We had a bug report about gnucash on Guix in here very recently; did you see it?
<civodul>welcome, chrislck! :-)
<nckx>chrislck: <lispmacs> hi, I've got this problem where, in GnuCash, the Enter key is not doing what it is documented to do (it works fine in Debian). It is supposed to move to next split line in transaction, but it does nothing. I am wondering if this is happening for me onl
<chrislck>thx ;)
<nckx>chrislck: Sorry to put you straight to work :-/
<janneke>chrislck: yes, weclome :)
<chrislck>ah well lipsmacs this particular bug is resolved in recent maint
*chrislck has desecrated wingo's daily-reports.scm and made it beautiful
<nckx>sneek: later tell lispmacs: chrislck says: this particular gnucash bug is resolved in recent maint.
<sneek>Got it.
*nckx prefers ‘lipsmacs’ tho'.
<chrislck>sneek: later tell lipsmacs:
<sneek>Will do.
<nckx>chrislck: It's lispmacs 🙂
<chrislck>sneek: later tell lispmacs:
<sneek>Got it.
<mbakke>weird, I did not get nckx's reply on Josh's message before I sent mine O.o
<nckx>chrislck: Guix strongly prefers to package releases. Any coming up?
<roptat>we could apply a patch if there's one for that issue, though
<nckx>mbakke: I see this happen a lot, kind of takes the joy out of responding to high-effort stuff for obvious reasons :-/ I don't understand.
<chrislck>they (jralls) usually plans it 3-4 per year
<nckx>Gmail shadowbanning?
*nckx assumes everyone uses Gmail because why have hope in humans at this point in time.
***ng0_ is now known as ng0
<chrislck>fwiw one of my guile achievements in gnucash is to enable automatic stress test of all reports -- it tries most reports in existence, flipping options t/f in various combinations
<chrislck>and ensures they all, at least, don't crash. it can do pairwise combinatorics by calling jenny too
<nckx>civodul: Re: retroarch: Debian flirts around the FSDG issue by disabling the Updater menu entry in the .cfg file. This is a regular preference (already provided by upstream) that's also trivial to reënable. I wouldn't consider this acceptable, but what do you think?
<wingo>i fixed my dumb guix problem. it appears to be that the daemon was running without GUIX_LOCPATH
<mbakke>many armhf builds on berlin fail with: `armhf-linux' is required to build `/gnu/store/hibl1fyabr
<mbakke>yxykfadc3h96phd7dw3bw2-karchive-5.63.0.drv', but I am a `x86_64-linux'
<mbakke>looks like the qemu-binfmt service is not running correctly on
<mbakke>hmm there is no such service on that machine, yet it was reconfigured recently
<nomr> gives me a 500 server error when I try to access old issues like . Is this known?
<mbakke>nomr: news to me. Can you send a report to ?
<nomr>I'll try!
<mbakke>civodul, rekado: is it ok to run 'guix deploy' on berlin?
<mbakke>.136 also does not have the qemu-binfmt service
<civodul>mbakke: and was it used for non-x86 stuff?
<civodul>some nodes were not deploy-ready yet
<civodul>i think rekado was looking into it
<mbakke>civodul: yes
<civodul>mbakke: so it should be ok to run "guix deploy"
<civodul>i see there are uncommitted changes in ~root/maintenance
*mbakke tries `guix deploy` on berlin
<mbakke>related: is there a way to clear all the daemons cached failures? :)
<civodul>savannah down :-(
<civodul>mbakke: guix gc --clear-failures $(guix gc --list-failures)
<civodul>but use with care!
<mbakke>civodul: nice :-)
<wingo>interestingly, guix environment resets the effects of "numactl" or "taskset"
<mbakke>guix deploy seems to have worked
<mbakke>needed to restart guix-daemon as well on the deployed machines
<wingo>ah i was wrong, numactl still works. i misunderstood how cpu numbers mapped to numa nodes
<jonsger>civodul: savannah seems up here
<mbakke>hmm, hydra-guix-08 did not get the qemu-binfmt service
<mbakke>I gtg, will continue later
<civodul>mbakke: you need to manually "herd restart qemu-binfmt" and "guix-daemon" on these machines
<elais[m]>How do I load modules from a channel dependency?
<pkill9>elais[m]: like any other modules you would load
<pkill9>whoa i didn't know /var/log/messages stores all history
<nixo__>Hello guix! Anybody doing android development on guix?
<g_bor[m]>hello guix!
<pkill9>hi g_bor[m]
<pkill9>hi Blackbeard[m]
<nckx>Hullo everyone.
*g_bor[m] trying to find out what is this nginx tls issue about...
<rekado>mbakke: it’s okay to run ‘guix deploy’ on berlin. All nodes that are listed in that deploy file can be reached and updated.
<rekado>‘guix deploy’ is surprisingly slow and it will always transfer at least 3 items to a target node, even if that node is up-to-date.
<rekado>nomr: that problem with is fixed in the development version, which I hope to deploy soon.
<sneek>Got it.
<nomr>rekado: thanks !
*g_bor[m] I will try to bisect this, but I suspect this is not working as expected...
<rekado>sneek: what is that problem with
<sneek>I've heard that problem with is fixed in the development version, which I hope to deploy soon.
<rekado>sneek: forget what is that problem with
<sneek>Its been said that that problem with is fixed in the development version, which I hope to deploy soon.
<rekado>sneek: forget that problem with
<sneek>Consider it forgotten.
<rekado>sneek: botsnack
<roptat>nixo__, I kinda do that, but it's not fun
<roptat>I had to get a binary version of the IDE, replace their bundled jdk with guix's and at every step in the compilation, I had to check the logs to understand what to run patchelf on to make them work
<roptat>and everytime you update something, gradle downloads a new version of the android sdk, which contains binaries you have to patchelf again...
<bandali>roptat, i'd love to read about java development using guix in general if there's a blog post about it or if you'd be so kind to write one
<roptat>I don't really do java development actually...
<roptat>well, a bit for android stuff, but it's not what I enjoy the most
<roptat>I'm only interested in *building* java stuff
<bandali>ah :)
<bandali>yeah tbh i don't "enjoy" it either, but being a grad student and all.. it's kind of unavoidable in my field at the moment :p
<theruran>ei? Ludovic Courtès' GPG key expired which was used to sign the guix-system-install ISO
<bandali>theruran, i believe an updated copy of civodul's key is available from
<theruran>bandali: got it, thanks. key fingerprint is correct? 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
<nixo__>roptat: thanks. I fear it's just easier to dual boot. Is there a reason why you are doing it manually instead of having a guix recipe?
<nckx>theruran: Yes, said a random agent on IRC.
<theruran>nckx: better than nothing *shrugs*
<roptat>nixo__, because I can't have a guix recipe for it, the issue appears at runtime, so it won't solve anything
<bandali>theruran, cheers, and yup, that looks correct to me