<kyamashita>Guix documentation tells me to use a remove function, but I get the "unbound variable" error when I use it. <lfam>Why... why would you expect time and time zones to be the same in the future?! <lfam>Well, Google shouldn't make their public code depend on the internal tools that they refuse to release to the public. <lfam>I hope that patch applies to go-1.4, our bootstrap Go <lfam>Well, I'll find out later <kyamashita>I solved my "remove" problem. SRFI-1 is required. <lfam>Good luck with the VMs. I have to go! <lfam>Actually, here for a bit longer, in case you still need a rubber duck for the VMs <kyamashita>lfam: I think I'm catching on. Thanks for your help! :) ***jje is now known as Guest23288
***Guest23288 is now known as jje
***jje is now known as Guest17571
***Guest17571 is now known as jje
<Apteryx>What is wicd useful for? I had setup wifi without it during the installation. <Apteryx>And its spawns two processes, wicd and wicd-monitor which consumes almost half (~40 MB) of the lightweight desktop default config. <Apteryx>I guess on a laptop when you hop between cafes. <gry>it has a pretty graphical interface with notifications but if you're comfortable doing your wifi without it then you can remove it <Apteryx>gry: OK, if I uninstall it is configuring /etc/network/interfaces & /etc/wpa_supplicant/wpa_supplicant.conf sufficient to get an automatic DHCP connection at boot? <gry>yes I think so. make sure you have plan B in case I'm wrong but I think that's what I've been doing for years unless I am missing something :) <gry>good luck Apteryx :) good question <atw>One thing I want to try (eventually, maybe) is to have connman as an alternative to wicd. It's packaged, but doesn't appear to be available as a service as wicd is. <Apteryx>Has anyone try installing the guile-emacs package? I did, and it took quite some time to build, but unfortunately when I run "emacs" it errors with a message saying "Uncaught exception: Throw to key syistem-error with args ("load-thunk-from-memory" "~/A" ("No such file or directory") (2))Threads exp <Apteryx>Not sure why it would look into "~/A" <amz3>what are you up to Apteryx ? <Apteryx>Trying to see if I can get ratpoison to display to the full resolution of my 2nd monitor <amz3>hacking on a guile project <amz3>I am working on libgit2 bindings <amz3>somehow it will helpful for guix project <efraim>oss-sec is continuing to have a field-day with jasper <wingo>media decoding in c: not even once <wingo>except that's all the time what we do :) <csanchezdll>efraim: there is a new problem with tar, which I had not seen before, and happens in master (not related to my patch) <efraim>When I go to build make-boot0 its like it fails to unpack the source <efraim>strace has read(10, "In execvp of tar: No such file o"..., 44) = 44 <efraim>I tried patching make-boot0 to not take a patch, thinking that would make the difference, but it didn't help <csanchezdll>but that happens in master when trying to cross-build i686 bootstrap binaries <csanchezdll>there is a similar report on the list like 2 years ago <efraim>I hadn't gotten around to checking the list, so far just tried to fix it myself <csanchezdll>I had no time for much debugging, but I will try again later <efraim>csanchezdll: ok, this one seems rather obvious now: I checked both store directories in PATH, neither one has tar <efraim>I added tar and xz to %boostrap-inputs in bootstrap.scm, and that should be building for the next bunch of hours <csanchezdll>%bootstrap-inputs include %bootstrap-coreutils&co, which should have tar <efraim>yes, but for some reason it wasn't there <csanchezdll>but somehow seems PATH is only including gcc-cross and gcc-binutils <efraim>ok, i moved it so that now they're in make-boot0 inputs and not in %bootstrap-inputs <wingo>libgweather in core-updates fails to build: <wingo>Invalid timezones in ./Locations.xml: Asia/Rangoon <csanchezdll>efraim: looks like a dependency is wrong somewhere. It is trying to cross-build gnu-make-boot0, which fails because it is not cross-compilable (it has no native-inputs) <csanchezdll>but the thing is gnu-make-boot0 should not be needed to cross-compile <csanchezdll>maybe commencement.scm was included somewhere and this created a circular dep? checking... <efraim>I'm on my phone ATM so I can't help look :( <ng0>i feel a bit better than yesterday.. I've read someone wanted to test the network manager service with the nm update I've send? was it successful? <efraim>I think they instead uncovered a bug about not properly building VMs <efraim>Yeah. I forget what happened after that ***candy_ is now known as candy`
<civodul>pro tip: when you have 'guix environment -C something' running and you want to build in that environment from, say, M-x compile, then you can run "guix container exec PID-of-guix-env-shell /bin/sh -c 'source /gnu/store/*-profile/etc/profile ; make -j4'" <civodul>this is a bit faster than rerunning 'guix environment' every time <efraim>civodul: csanchezdll and I did some digging and it seems make-boot0 doesn't have tar or xz in its path, which is why I've been getting my errors and building i686 bootstrap binaries from x86_64 isn't working atm <civodul>too many issues at once, stack overflow :-) <civodul>first, make-boot0 definitely has tar and xz in $PATH, otherwise we wouldn't be using Guix right now :-) <civodul>however, maybe the tar and/or xz programs that were cross-built for ppc/aarch64 are broken <civodul>could you strace the thing to see where that ENOENT ("No such file") comes from? <efraim>I have it in the response on the mailing list. I'm on my phone ATM and will have to debugmore later <csanchezdll>civodul: no ppc involved, building --target=i686-linux bootstrap-binaries with master fails right now <csanchezdll>I saw the problem when trying to rebuild ppc static binaries, but first thing when I hit a problem is trying the same on unmodified head <civodul>csanchezdll: "--target=i686-linux" is incorrect; the correct thing would be "--target=i686-linux-gnu" <civodul>however, from x86_64, you can build natively: "--system=i686-linux" <civodul>there's a subtle distinction between "system strings" and "GNU triplets" <csanchezdll>so, cross-generating bootstrap-tarballs does not work <csanchezdll>one can generate natively (--system) but only for i686 <csanchezdll>the surprising thing is this used to work before I updated my branches, so got broken somewhere in last 2 weeks or so <civodul>so the problem has to do with the cross-compiled 'tar', right? <efraim>for the moment i've added host bootstrap tar and xz to the inputs of make-boot0 to see if that'll fix it, since they should only be needed for unpacking and repacking tarballs <civodul>could you test the cross-compiled binaries individually first? <civodul>if you run "guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)' -K" <civodul>then you can check the 'environment-variables' files in there <civodul>and see if 'tar' and 'xz' are in $PATH <civodul>gnu-make-boot0 cannot be cross-compiled <csanchezdll>I was much more advanced, the thing is I updated my branches yesterday to generate the patches to send to th elist <csanchezdll>before that update I had already all the cross-tools working, I was building hello on the ppc <csanchezdll>then I had to diver topic because gcc-4.9.3 has a known bug on ppb when used with glibc-2.21+ <csanchezdll>now, after updatign the branches, I decided to regenerate the bootstrap binaries (which I already had, just to check everything was working again) <csanchezdll>and I saw this error, so I tried with --target=i686 instead of ppc to make usre it was not caused by my ppc changes <csanchezdll>I am not sure if have succeeded explaining myself :D <csanchezdll>of couse, I can just go back to the commit I was using it (I think I can more or less identify it) and go on <csanchezdll>but the thing is bootstrap binaries cannot be regenerate (i.e. cross-compiled) now, because trying so tries to cross-compile gnu-make-boot0 which is not cross-compilable <csanchezdll>(to everyone else, I am sorry for kidnapping the channel o:-) <civodul>so, you have cross-built bootstrap-tarballs, right? <civodul>and now you're trying to inject them into bootstrap.scm, correct? <csanchezdll>I am trying to generate the bootstrap-tarballs again <civodul>ok, and 'make-boot0' fails to build, correct? <civodul>you're trying to generate them *natively* this time? <csanchezdll>I am trying to cross-generate them again, same as I did <civodul>and was introduced in the last few days? <csanchezdll>so I was trying to get a shortcut (and learn in the process) by debugging why current version fails <csanchezdll>and what I see is "guix build --target=i686-linux-gnu bootstrap-tarballs" tries to cross-compile gnu-make-boot0, which fails (fails exec'ing tar because gnu-make-boot0 has no native inputs, but that is expected as gnu-make-boot0 is not cross-compilable) <csanchezdll>so my guess is something is wrongly triggering gnu-make-boot0 cross-compilation <csanchezdll>guix graph does not help as is huge and AFAIK only gives me the native depencency graph <csanchezdll>but you are right, bisecting is probably the best way forward <rekado>FWIW: I'm working on an interactive graph backend. <civodul>csanchezdll: just replied to your message, hopefully it'll clarify things a bit <csanchezdll>civodul: thanks! I was assuming i686-powerpc-gnu was a supported cross-compilation target <csanchezdll>from now on, when cross compilation fails for ppc, I will try with mips insted <csanchezdll>./pre-inst-env guix build bootstrap-tarballs --target=mips64el-linux-gnu <efraim>if you are running git bisect, I can tell you 6a4cbc6f1261a2c94a8bb05d2765a183235a1b9f is bad, its where I have my aarch64 branch built off of <efraim>unfortunately my last known good was before the last core-updates merge, on the core-updates branch, so i'll leave that one up to csanchezdll <Apteryx>amz3: nice :) (for your guile hacking) <csanchezdll>so, b9bc6e842066b066ebdf9eaf75d41753598d75b5 is good, but b9bc6e842066b066ebdf9eaf75d41753598d75b5^ is bad <csanchezdll>however, nothing in that commit looks related to this :S <csanchezdll>efraim: could you test ./pre-inst-env guix build bootstrap-tarballs --target=mips64el-linux-gnu in those commits? <ng0>so uclibc-ng compiles more than musl, but (at least the hardened version) runs into some bugs.. I'm not done with the package, but this is just what I experience while moving a new system to a uclibc-ng hardened. looks like lots of fun for guix :) <ng0>*gentoo uclibc-ng hardened <efraim>csanchezdll: I can when I get home in a little bit <ng0>i think 99% of packages just work same as glibc, and 1% of packages need a patch or something.. at least with hardened uclibc-ng <efraim>Isn't that the same commit for good and bad? <csanchezdll>I put it that way to make clear it is the commit that changes from good to bad <ng0>wow. numpy has many open bugs <paroneayea>`sudo guix archive --generate-key' is writing to /usr/local/etc/guix <paroneayea>but `guix archive --export -r emacs' is expecting from /etc/guix/signing-key.asc <paroneayea>cwebber@oolong:/tmp$ scp /etc/guix/signing-key.pub kari:/tmp/ <paroneayea>scp is available on the remote machine... I'm guessing there's a path issue <paroneayea>putting openssh in the system profile fixed my scp issue <davexunit>how do I load a new emacs package that I installed without restarting emacs? <ng0>i just replied to that though <ng0>we already have lua-mode :) <ng0>guix package -s lua-mode <davexunit>maybe I'll have something to contribute in a few more months <Apteryx>By the way, I finally understood how ratpoison deals with more than one monitor, it is briefly covered in its manual. <Apteryx>Basically you have to use "nextscreen" (C-t N) or "prevscreen" (C-t P) to switch between the screens and be able to manipulate the frames there. <Apteryx>you can also do C-t : then type sselect to pass the number of the screens (0, 1, etc.) <efraim>csanchezdll: I got home a little bit ago and haven't stopped my previous build, where I added bootstrap-tar and bootstrap-xz to make-boot0, currently i'm building perl-boot0 so it looks like my workaround may work <efraim>but after it finishes I'll get started on those two commits and mips64el-linux-gnu <thomasd>I'm getting permission denied errors during the install phase for a package I'm building <thomasd>nevermind, I just see why... it's a qt trying to install into the qtbase store directory, instead of into the proper target directory <efraim>csanchezdll: i stopped my compilation from before, turns out I was still compiling for x86_64, about to start with the b9b commit now ***Sleep_Walker is now known as Sleep_Worker
<ng0>civodul: i'm looking into pagure, there could be something to work with and contribute to what we want to move it to.. used to be fedora, but it's moving to something beyond fedora-only <csanchezdll>efraim: ok, I was busy as well, trying to work a bit on this issue now