<adfeno>civodul: Found the error in my ring.scm :) <rekado>I have a couple of patches ready for separating the recommended packages from R itself and to fix the remaining reproducibility problems. <rekado>just need to test one variant of a fix that I think goes a bit too far. ***Piece_Maker is now known as Acou_Bass
***amuck_ is now known as amuck
<efraim>Mesa is failing to build on aarch64 on core-updates, says it cant find libdrm_intel <efraim>Luajit also FTBFS, arch unsupported? <efraim>Luajit beta looks like it has aarch64 support <jmd>How can I change a build flag in the cmake-build-system ? <janneke>civodul: my build whoes yesterday were, *again*, caused by a broken .bashrc of mine <janneke>i'm wondering, am i the only one who ignorantly/wrongly overrides PATH, GUILE_LOAD_PATH etc in his (ubuntu/debian) .bashrc? <janneke>would there be a way to flag such errors? <jmd>janneke: I also override them, but I don't think I'm doing it wrong or in ignorance. <janneke>jmd: hmm...I had on a ubuntu box: #export GUILE_LOAD_PATH=/usr/share/guile/site <janneke>that breaks `guix environment guix -- make', for example <efraim>Can someone restart Python-minimal on core-updates on Hydra? <efraim>I think I'm going to bump luajit to the latest beta release on core-updates, its supposed to have aarch64 support <civodul>janneke: you mean .bashrc vs. .bash_profile? <janneke>civodul: yes...and esp. when using a guix .deb package on a foreign distro <civodul>the manual warns about this, but i don't know what else could be done <janneke>ACTION feels kinda dumb about this, davexunit has helped me several times with things like this, where i modified PATH <janneke>yes, think i've started to learn, but am just wondering about other newcomers <catonano>I messed up my last patch submission. I apologize. <jmd>It looks like aarch64 is still causing grief for core-updates <catonano>I wanted to use git-send-mail but I have no smtp server available for now <catonano>gmail is clunky and awkward and I have to jump through the loops in order to make git-send-mail to rely on that <jmd>catonano: Guix has several MTAs packaged. <efraim>I use msmtp, and I have it call gpg to decrypt the passsword from password.gpg <jmd>Some packages in their wisdom put their shared objects in a library called lib64 or something wierd. Should we change it to lib or what? <slyfox>packages should be fixed upstream to respect $(libdir) (or expose a knob) <jmd>slyfox: Please - we have a code of conduct against such imagery. <slyfox>"The use of sexualized language or imagery" this one? <jmd>Yeah - you were advising people to expose their knobs. <catonano>considered that I have never run an MTA in my life, do you suggest me exim or opensmtpd ? <efraim>I'd go with opensmtpd and forward all my mail to another box. In my /etc/aliases on Debian I have 'efraim: efraim@mailhost.tld' <jmd>Personally I use sendmail - but that is a personal choice. <catonano>efraim: my default mail provider is gmail. I couldn't forward mail traffic trough them, for the same reason tat git-send-mail can't easily rely on them. <catonano>Do you think it could be feasible to rouute mails directly ? <efraim>Even with an app-specific password? <catonano>efraim: in order to access to app specific passwords I'd have to move rom swipe based verification to numeri code 2 pass verification <catonano>so I uunderstand, anyway, their interface is a mess <efraim>AFAIK most mail prociders do a reverse DNS lookup which you'd fail from a standard isp <efraim>I think I tried openmailbox in the past, don't remember if they allowed sending as a gmail alias <slyfox>locally i've set up postfix to send outbound email trough gmail (and a few other mail services) but postfix is not in guix packages for some reason <efraim>I use postfix and dovecot on my mail server <slyfox>i have emails on all of them and postfix choses for me which of them to use as outbound mased on sender email <jmd>efraim: WHy would it fail? <efraim>AAA.BBB.CCC.DDD.ISP-dynamic.monies.com isn't the reverse DNS to AAA.BBB.CCC.ddd <jmd>Then use the correct one. <jmd>I have a test failure during guix build, but not when I run it manually. Any tips on how I can debug it? <methalo>jmd: may be you can see error detail in the log files <jmd>methalo: Unfortunately I cannot. <jmd>At least not enough detail. <methalo>sometimes i compare the config.log files <jmd>I don't think in this case there is anything in the log file to help me. But which 2 log files would I compare anyway? <methalo>one is the generated by guix, and the other generated manually, or misunderstand the question :) <jmd>???So what you are suggesting is that I manually create log file using some unconcous knowledge of what the pertinent difference is, then use diff to compare with the guix geneated logfile to expose that knowlegdge ? <methalo>Sometimes I check the value of the variables and find differences <jmd>I'll have to just patch the test with lots of diagnostics and rerun :( <snape>Well, I push them, nevermind. <efraim>Mysql is terrible for building on aarch64, it wants 4GB of ram <wingo>sneek: later tell snape please do! <wingo>ah if clement is snape then yes, all the better <jamesrichardson>Hello Guix! I'm trying to setup a build server with guix on a foreign distro (Debian in this case). <jamesrichardson>guix offload test fails with a message error: Failed to use Guix module on 'thor.lab01.jamestechnotes.com' (test returned #<unspecified>) <jamesrichardson>I run ssh -i identity-for-guix guix@thor.lab01.jamestechnotes.com guile -c "'(usde-modules (guix config))'"" and I get a 0 return code. <jamesrichardson>I suspect an environment variable is not getting set properly over ssh, but I don't really know. <roptat>can you make a package that needs a tarball and an extra file? <roptat>or do you need to make a package for that extra file first? <janneke>ACTION looks at resurrecting kodi as a possible replacement for my troublesome mythbuntu box <roptat>efraim, that means having an extra package for that extra file, correct? <janneke>tarball with non-conforming name, over 60 bundled libraries... <efraim>roptat: not necessarily, you can define the input in a package style rather than refering to an actual package <jmd>Is there a way to tell the daemon that the standard input must be a terminal? <civodul>jamesrichardson: cool, glad that it works :-) <jamesrichardson>I had to do some rather nasty things to /etc/environment... I'll try to clean it up, reproduce and write somethgin.