IRC channel logs


back to list of logs

***Server sets mode: +cnt
<ng0>there is a tool to diff tarballs content right?
<ng0>i seem to remember coming across this in guix or in nix
<ng0>I have 2 tarballs created on 2 different operating systems but operating on the same git checkout running make dist
<ng0>that's the one
<ng0>many thanks :)
<jje>build for weston-6.0.1 fails with the following:
<davexunit>rekado: I have discovered that, too, but I think the problems go even deeper. perhaps all the way to our gcc packages.
<davexunit>rekado: I've been doing some testing inside a container and it seems that, even with RUNPATH info in the shared libs, I can still use those libraries elsewhere by setting LD_LIBRARY_PATH
<davexunit>so maybe runpaths aren't such a blocker after all.
<dutchie>hmm, does gnu-build-system not include an `autoreconf` binary?
<gnutec>Guix is so great that is unfair with others distro.
<raghavgururajan>Hello Guix!
<leoprikler>dutchie: it should execute autoreconf by default in the bootstrap phase, why?
<dutchie>it couldn't find it
<dutchie>needed to add autoconf to native-inputs
<raghavgururajan>gnutec Could you eloborate your statement please? :-)
<leoprikler>dutchie: after some quick grepping, I see that done throughout Guix. You did nothing wrong.
<dutchie>i'm creating a new package
<dutchie>so i did do something wrong :)
<dutchie>but i have fixed it now
<leoprikler>I should clarify myself. You did nothing wrong by adding autoconf to the inputs.
<leoprikler>Having your package built by feelsgood.png
<zimoun>with Emacs-debbugs, how can I get the Message-ID?
<zimoun>Other said, when submitting an updated version with git-send-email, to keep clean the thread, if I understand well, I use --in-reply-to=<message-id>.
<leoprikler>zimoun: can you download the message as mbox?
<zimoun>yes I can but I would like to have a workflow without.
<zimoun>I use C-u g to display the raw article and then search in. Which is not so much convenient. I can write an ELisp helper but maybe it already exists and I am not aware.
<kirisime>I've set up build offloading, but when I run `guix offload test' I get "Guix is usable" followed by "error: failed to connect to `#<input-output>': Protocol error"
<kirisime>It's not a very helpful error so I don't know how to troubleshoot.
<rekado>kirisime: I found that I still needed to make sure that /etc/environment contained both GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.
<rekado>I only found this by attaching strace to sshd on the target machine. Not a great way to debug this.
<rekado>kirisime: does the SSH connection itself work fine?
<rekado>have both machines authorized each others’ keys?
<kirisime>rekado: since the test claims to have returned a store path and whatnot, I'd guess the ssh is connection works just fine.
<kirisime>rekado: And the guix keys seem to be in place too, though, how do I check if the contents of /etc/guix/acl are as they should be?
<rekado>the file should contain the public part of the signing key of the other machine
<kirisime>They're there yes
<kirisime>So I suppose I should add guile's load paths to /etc/environment and see if that works
<rekado>here’s what I use (on the machine that’s doing the building):
<rekado>if this turns out to resolve the problem, please report this at This shouldn’t be needed.
<kirisime>It's not a GUIXSD system though, and I'm not the only user.
<rekado>so, the machine that builds things only uses Guix as a package manager?
<rekado>(BTW: it’s “Guix System”; the name “GuixSD” is no longer used)
<kirisime>Yeah, and probably only for me.
<kirisime>It's my SO's gaming machine and I'd hate to break things on it. I just don't want to build another kernel on my laptop.
***apteryx_ is now known as apteryx
<gnutec>I use emacs to access #guix IRC and C-x 3 to devide the windows in a widescreen monitor. Just saying.
<leoprikler>I have MPC status on the left of my IRC window and sr-speedbar on the right.
<kirisime>I've opened a dired with multi-hop tramp to access the other system's filesystem as root but when I open files they look like the ones on my system instead. Directory listing is remote, files look local.
<gnutec>In emacs, C-g stop all command in progress.
<kirisime>Well, that weirdness was caused by me running C-x C-f /ssh:user@remotehost|sudo:root@localhost:/etc/
<kirisime>`localhost' should be `remotehost' too, otherwise the multi-hop only works half way
<rekado>sneek: what’s the status of core-updates?
<rekado>mbakke: may I push something to core-updates?
<mbakke>rekado: go crazy :-)
<mbakke>I don't expect to start it before a week or two, I have lots of patches to make..
<nckx>sneek: What is staging?
<sneek>Someone once said staging is none of your business
<nckx>mbakke: …?
*nckx will never ask sneek again.
<mbakke>'qtwayland' is currently failing on staging
<mbakke>I'll try to find a fix this weekend unless is resolved by then
<nckx>mbakke: Is it still open in the meantime? (Nothing urgent.)
<efraim>sneek: what is cake
<nckx>sneek: What is the cake?
<sneek>Last time I checked the cake is a lie
<efraim>I forgot the 'the'
<mbakke>nckx: not really, as that would cause huge rebuilds on the CI
<nckx>sneek: Pendantic botsnack.
<mbakke>nckx: can you push a 'staging-next'?
<nckx>mbakke: Sure, maybe. It's just a rat-king of interdependent Perl packages that turned into staging material, I might run out of energy before finishing.
<dongcarl>Going to push patchv3 here if people aren't opposed, thank you efraim and nckx for the tips and review!
<nckx>mbakke: Do you have a personal branch-master checklist? Adding ‘sn eek: <branch> is open|closed|…’ would actually be a great addition.
<nckx>And keep us from bothering you.
<mbakke>nckx: using sneek for that sounds sensible
<efraim>I've tried it before, didn't work well
<nckx>efraim: Why?
<efraim>sneek: what is core-updates
<sneek>Someone once said Core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs
<mbakke>nckx: I'm a bit busy right now, but a more transparent/formal branch merge workflow would be great.
<nckx>efraim: Apart from the pedantry that bit rekado above.
<mbakke>nckx: can you raise it on the ML?
<efraim>Leo and I tried working on core-updates with sneek to keep track of our progress and sneek had a hard time with overlapping messages
<nckx>efraim: Was it because sneek sometimes picks up random ‘x is y’ pronouncements even without sneek: ? I remember that happening once.
<efraim>sneek: what is core-updates
<sneek>Last time I checked Core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs
<efraim>At least its consistent now
<efraim>Sneek forget core-updates
<efraim>Sneek what is core-updates
<sneek>I've heard Core-updates is fontconfig, eudev and cups-minimal FTBFS
<efraim>Overlapping messages
<efraim>Sneek forget core-updates
<sneek>Consider it forgotten.
<nckx>efraim: Yeah. I told sneek ‘core-updates is open’ in a query window 5 minutes ago and they said they'd keep it in mind.
<nckx>That was before you asked them & they still gave the old def.
<nckx>So either sneek has multiple memories of whom to tell what (they will go far in management) or is simply a broken clock (OK, still no impediment, really).
<dongcarl>I also want to get #37924 through, as it doesn't affect existing packages, and can only fix a broken behavior... I would like some review on the PATCH 2/2 here, as I've not messed with the (gnu ci) module:
<nckx>dongcarl: Neither have I but I can still ask obvious questions: Why ‘glibc glibc-2.28’?
<nckx>Everything else seems explicitly multi-versioned.
<nckx>(Except gcc, but that's used differently.)
<dongcarl>nckx: Not sure what you mean by explicitly multi-versioned
<nckx>Right. I mean ‘gcc-x gcc-y gcc-z’ instead of ‘gcc gcc-y gcc-z’.
<nckx>Same for the 2 guiles. glibc is the only package in that list relying on ‘whatever the default version is’.
<dongcarl>nckx: Oh I see... My thought process was just to test our "default glibc" (in guile land at least), and debian stable's "default glibc" (2.28)
<dongcarl>Don't know what _should_ happen though, would like guidance
<nckx>OK, sounds sensible. Can't offer guidance.
<dongcarl>Gunna push first commit now... Maybe someone will chime in on the (gnu ci) front
<nckx>Give it a few more days, then push.
<jje>the weston-6.0.1 build is failing during the check phase:
<dongcarl>nckx: Oh... I jumped the gun on that commit then I apologize...
*dongcarl is sweating
<jje>sorry meant
<nckx>dongcarl: Don't sweat it.
<nckx>‘Wow,'s down‽ … … wait a minute.’
*nckx reads
<nckx>jje: Could you report a bug to bug-guix at Please attach the log again, because that paste expires tomorrow.
<jje>ok no problem
<nckx>Thanks 🙂
<nckx>jje: Sorry, actually don't, my bad.
<jje>ok i wont
<nckx>Checking before reporting should be a habit, but I should have been more explicit here.
<nckx>jje: 🙂 You can disable the weston test suite with (arguments `(#:tests? #f)…) if you're so technically inclined.
<nckx>Or just keep trying, or downclock your CPU as noted in that bug report.
<dongcarl>Has anyone had experience with the clang that we package? Trying to use it right now, and it seems like because clang doesn't understand `LIBRARY_PATH`, it doesn't get passed down and `ld` can't even find `crt1.o`
<bavier>dongcarl: the same has affected some packages as well
<bavier>i.e. some packages that build with clang see errors
<dongcarl>bavier: Oh... Have there been previous attempts at fixes that I can look at?
<bavier>atm idk
<lfam>People are discussing improving Clang in Guix now:
<dongcarl>lfam: Oh thanks, looking
<jgibbons[m]>Hello guix!
<jgibbons[m]>It looks like minetest doesn't know about the certs.
<jgibbons[m]>Something might be wrong with libcurl.
<jgibbons[m]>2019-10-30 11:02:17: ERROR[Main]: not found (SSL peer certificate or SSH remote key was not OK) (response code 0)
<jgibbons[m]>I asked minetest about it and they think it might be a libcurl problem.
<jgibbons[m]>Is there a way to check if libcurl knows where the certs are?
<leoprikler>does curl itself know about the certs?
<str1ngs>jgibbons[m]: do you have nss-certs installed?
<jgibbons[m]>Yes. Curl knows about the certs and nss-certs are installed when I do this.
<str1ngs>jgibbons[m]: aye curl should give an indicator if libcurl is working
<vagrantc>do you have the various environment variables exported
<jgibbons[m]>Which environment variables should I look for?
<vagrantc>SSL_CERT_DIR, SSL_CERT_FILE, etc.
<vagrantc>that should cover most ... but some applications will implement their own corresponding methods
<jgibbons[m]>I did that but it does not work.
<jgibbons[m]>libcurl is working.
<jgibbons[m]>I'll see what minetest does.
<kirisime>jgibbons[m]: On guix, libcurl doesn't use any cetificate bundle and doesn't hardcode any path to look into. Curl the command line tool honors an environment variable that the library itself doesn't, so the cli tool working doesn't mean the library will find your certs.
<kirisime>The program (minetest) needs to check the environment variable or take a command-line argument for the search path, and if it does I suppose you can use wrap-program or some such to have things work.
<kirisime>But, when I wrote a package for megatools I just added a one line patch to the program's source code that hardcodes the certs bundle path...
<dongcarl>w/re the LIBRARY_PATH thing... this patch should fix it:
<dongcarl>Will upstream
<dongcarl>Submitted a bug report which should help with startfile pickup on clang:
<dongcarl>Most of the details needed to fix this is there... Will probably take someone who's more experienced than me about 10 mins to fix
<gnutec>Ops! I asking if guix can use instead gcc and make. So I type C-h i in emacs and see "guix pack". But only how have guix instaled in your system (I use Guix System so...).
<leoprikler>Please try rephrasing that. So instead of invoking "guix package ...", you want to build a package manually with gcc, make, etc. or what exactly do you want to do?
<gnutec>leoprikler: I'm not talking about "guix package" but "guix pack". Is not about install package but software development without gcc command or make. :) "But only *who have guix". I just saying. It's not a question.
<kirisime>So how do I leave a message for rekado here?
<leoprikler>sneek: tell kirisime like this
<sneek>kirisime, leoprikler says: like this
<kirisime>sneek: tell rekado Following some advice and then intuition I got the offloading working on ubuntu by installing guix and guile in the offloading user's profile, having the .bashrc file not discriminate against non-interactive shells and calling eval `guix package --search-paths=prefix`. As far as I can tell modifying /etc/profile wasn't necessary and the issue might've been with the libraries the variables would point to being missing
<kirisime>in the first place.
<sneek>rekado, kirisime says: Following some advice and then intuition I got the offloading working on ubuntu by installing guix and guile in the offloading user's profile, having the .bashrc file not discriminate against non-interactive shells and calling eval `guix package --search-paths=prefix`. As far as I can tell modifying /etc/profile wasn't necessary and the issue might've been with the libraries the variables would point to being missing
<leoprikler>someone should add a check to sneek
<leoprikler>(if (present user) (message "No, do it yourself") (...))