***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 <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. <leoprikler>dutchie: it should execute autoreconf by default in the bootstrap phase, why? <dutchie>needed to add autoconf to native-inputs <leoprikler>dutchie: after some quick grepping, I see that done throughout Guix. You did nothing wrong. <leoprikler>I should clarify myself. You did nothing wrong by adding autoconf to the inputs. <leoprikler>Having your package built by ci.guix.gnu.org 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>. <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>So I suppose I should add guile's load paths to /etc/environment and see if that works <rekado>if this turns out to resolve the problem, please report this at bug-guix@gnu.org. 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>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>I don't expect to start it before a week or two, I have lots of patches to make.. <sneek>Someone once said staging is none of your business *nckx will never ask sneek again. <mbakke>'qtwayland' is currently failing on staging <nckx>mbakke: Is it still open in the meantime? (Nothing urgent.) <nckx>sneek: What is the cake? <sneek>Last time I checked the cake is a lie <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. <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 <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. <sneek>Last time I checked Core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs <sneek>I've heard Core-updates is fontconfig, eudev and cups-minimal FTBFS <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). <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. <dongcarl>nckx: Oh... I jumped the gun on that commit then I apologize... <nckx>dongcarl: Don't sweat it. <nckx>‘Wow, debian.net's down‽ … … wait a minute.’ <nckx>jje: Could you report a bug to bug-guix at debbugs.gnu.org? Please attach the log again, because that paste expires tomorrow. <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? <jgibbons[m]>It looks like minetest doesn't know about the certs. <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? <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. <vagrantc>do you have the various environment variables exported <vagrantc>that should cover most ... but some applications will implement their own corresponding methods <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>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? <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 <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>(if (present user) (message "No, do it yourself") (...))