<mark_weaver>sneek: later tell tyrion-mx: regarding the error in https://paste.debian.net/282051/, I guess that means that my advice to tell grub to install in /dev/sdaN was bad. sorry about that. better take alezost's suggestion to run 'guix system init' with --no-grub <aravind>I am trying a "guix refresh -u" and that dies with a "guix refresh: error: mkstemp!: Permission denied" <aravind>this is all on an arch linux box running guix 0.8.2. <sir123>Hey guys, I have a package I want to test :). I have written a declaration in my local copy of the Guix source tree, how do I test it? <phant0mas>sir123: ./pre-inst-env guix build name_of_package <sir123>do i have to compile my source tree? <phant0mas>yes run make before running the above command <sir123>i'm setting up my 'guix environment guix' now <phant0mas>did you add the package declaration in a existing scm file, or did you create a new one for your package <sir123>existing scm file, the package is fbset (controls the 'Linux framebuffer') in the linux.scm file <sir123>idk if it really relates to the kernel, confusion over naming the whole system makes it a pain :( <sir123>I got my info from the Debian web pages, is that a problem? <phant0mas>I don't think it will be a problem as long as it is correct :-) <sir123>The source tarball doesn't specify its licence, but Debian devs seemto think its gpl2 <sir123>automake should be able to create a Makefile.in file in the source tree, right? <sir123>configure.ac:21: error: required file 'build-aux/config.rpath' not found <sir123>config-daemon.ac:15: error: required file 'nix/config.h.in' not found <sir123>copied straight from the git repo, why are these files not there? <daviid>sir123: from a git repo you probably have to run ./autogen.sh first [not a guix user [yet] by the way] <sir123>there is no autogen.sh in the tree <amz3>At the very begginning you must first run ./bootstrap. You don't need to re-run make when adding a package <Steap>amz3: sir123 is long gone :) <amz3>Steap: sorry did not have time to test, guix-tox, did you push it ? <Steap>it's a modified verson of tox <mark_weaver>I took the liberty of pushing the --build=<triplet> change to core-updates, and have been building it on armhf in addition to hydra, and everything seems good so far with that. <mark_weaver>however, there seems to be problems with cross-compilation in core-updates, even without the --build change. <mark_weaver>leading to: ERROR: In procedure string-append: Wrong type (expecting string): #f <mark_weaver>(I cancelled the remaining jobs from the earlier core-updates evaluation, but the same cross-compile failures happened there <mark_weaver>I guess the error is in the 'set-cross-path' phase, maybe because (assoc-ref inputs "libc/linux-headers") returned #f <civodul>hopefully that's the only place where that "/" notation is used <mark_weaver>oh, right, this is related to your scalability work in 161094c8e2b46128544b85dae8e97d4fcb2818c0 <mark_weaver>civodul: 'magit-svn' also includes (assoc-ref %build-inputs "magit/git-modes") <civodul>did a quick grep and i can't seem to find others <civodul>for magit it's easy: just use "git-modes" directly <civodul>i'm looking at the cross-base.scm one, which might be more difficult <civodul>it turned out to be easily fixed as well <civodul>i shamelessly offloaded the cross-gcc build to hydra.gnunet.org because my hard disk is kinda full <mark_weaver>civodul: what happens if there are two propagated inputs with the same key string, but which are different? <civodul>mark_weaver: the two get in the input alist under the same key, but after the direct inputs <civodul>so you can't really refer to a specific one with assoc-ref <civodul>but they are taken into account for the purposes of the 'set-paths' phase and so on <mark_weaver>as long as they're after the direct inputs, I guess it rarely matters <rekado>icedtea on x86_64 failed because the build slave ran out of space. <rekado>this is bound to lead to a couple more failures. <tyrion-mx>Hello, yesterday the guix installation failed because of problems with grub <sneek>Welcome back tyrion-mx, you have 1 message. <sneek>tyrion-mx, mark_weaver says: regarding the error in https://paste.debian.net/282051/, I guess that means that my advice to tell grub to install in /dev/sdaN was bad. sorry about that. better take alezost's suggestion to run 'guix system init' with --no-grub <tyrion-mx>if I run "guix system" I get an error, are you aware of that? <tyrion-mx>ERROR: In procedure car: Wrong type (expecting pair): () <rekado>tyrion-mx: is there more to this error? Is "guix system" the complete command? <mark_weaver>tyrion-mx: well, it's not a great error message, but "guix system" by itself is not a valid command. <tyrion-mx>I tried to run again the same command with --no-grub and now I get: guix system: error: build failed: path `/gnu/store/mlk1njc4wp5bfs88dfjrmy9rqrmwk5a9-grub.cfg' is not valid ***ljhms_ is now known as ljhms
***Steap_ is now known as Steap
<mark_weaver>tyrion-mx: I think you should wipe the target partition clean and re-run "guix system init <os-config> /target" (or whatever is the relevant partition) <mark_weaver>guix system init is really meant to install into a fresh partition <mark_weaver>the error you got would seem to indicate that there's no entry in the sqlite database corresponding to /gnu/store/mlk1njc4wp5bfs88dfjrmy9rqrmwk5a9-grub.cfg <mark_weaver>I confess I'm not exactly sure what's going on there <tyrion-mx>mark_weaver, is there no other solution that can make me save some time? <mark_weaver>because most of the time was spent building or downloading stuff into the store on your host (ubuntu?) system <mark_weaver>if that stuff is still there, then guix system init should be relatively fast <rekado>hmm, "guix build r" shows me that a *lot* of things will be built locally, including gcc, coreutils, gfortran and many more. <rekado>looking at hydra it looks like gfortran has already been built, so I should be able to get a binary. <mark_weaver>rekado: is sounds like maybe something in your local guix got changed that forced a lot of rebuilding <rekado>I reset to origin/master and ran make. <tyrion-mx>should I remove the grub line from the config.scm file? <tyrion-mx> (bootloader (grub-configuration (device "/dev/sda9"))) <mark_weaver>tyrion-mx: it sounds like somehow your local store got corrupted <mark_weaver>that doesn't tend to happen. the only examples I've seen were due to user error. <tyrion-mx>or is there a way not have to rebuild everything? <mark_weaver>tyrion-mx: recently we added a command "guix gc --verify=repair". I don't know much about it, but it might be worth a try. <mark_weaver>but it might be that your daemon (from the most recent release) is too old to support it. <mark_weaver>failing that, you should probably just blow away /gnu, /var/guix, and /var/log/guix and start with a fresh install. <mark_weaver>I don't have time now to help you debug this further <tyrion-mx>I ran guix gc and it seems that it is deleting all <mark_weaver>(i.e. from either our source tarball or a git checkout) <rekado>hmm, the store items it says it wants to build all exist. <tyrion-mx>it is guix system --no-grub init or guix system init --no-grub ? <rekado>there is only *one* thing in this very long list that it wants to download: /gnu/store/qp42nrg3vxvcswhvdkgis7lfmr8il8bw-netpbm-10.61.01-checkout <rekado>guix gc --verify=repair and --verify=contents passed without errors. <rekado>"./pre-inst-env guix build r" fetches the list of substitutes and still wants to build everything. <rekado>I wished it would tell me *why* it wants to build everything. <rekado>:( tried reverting the latest changes to the substitute mechanism, but the behaviour is the same. <rekado>unfortunately I cannot reproduce this on GuixSD. <mark_weaver>rekado: tell me about how you built the 'guix' command that wants to rebuild everything. did you build it from source code yourself? <rekado>~/.config/guix/latest does not exist <mark_weaver>so this happens when running ./pre-inst-env guix ... ? <rekado>I wonder if this is a late effect of having done 'make install' in the past. <rekado>trying to clean out everything now. <mark_weaver>rekado: if you run ./pre-inst-env it shouldn't matter <rekado>it's the production deployment for the cluster. <mark_weaver>rekado: if I run "sha256sum *" in gnu/packages/bootstrap/x86_64-linux, this is the output: <mark_weaver>265d2f633a5ab35747fc4836b5e3ca32bf56ad44cc24f3bd358f1ff6cf0779a5 bash <mark_weaver>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0 guile-2.0.9.tar.xz <mark_weaver>50689abdf2d5374e17ea8c51801f04f7590ad604af33a12a940cc11d137a4a2f mkdir <mark_weaver>16440b4495a2ff9c6aa50c05a8c9066e1004a5990b75aa891f08cdf8753c8689 tar <mark_weaver>930ad7e88ca0b2275dc459b24aea912fadd5b7c9e95be06788d4b61efc7ef470 xz <rekado>I have the suspicion someone fiddled with the server and didn't tell me about it. <rekado>it's the same for other users, so I think it doesn't matter. <rekado>odd, I get this line repeatedly, even after it says that it will build everything (except one thing) locally: <rekado>how exactly does the substitution mechanism work? There are files containing substitute metadata at $localstatedir/guix/substitute/cache --- <rekado>if a store path is found there it should be downloaded from the specified location, no? <rekado>so, /gnu/var/guix/substitute/cache/ does not contain a file including the string "/gnu/store/bva47a41xcr4gxps5hmy24iwypfvb4iv-bison-2.7.1". <rekado>same for /gnu/store/5bfmznava1p9rry14cgm89bi9crvk6lb-r-3.2.1, which cannot be found in the substitute cache. <rekado>when you start building "r" on your x86_64 machine, which hash is shown? <rekado>never mind, hydra agrees with /gnu/store/5bfmznava1p9rry14cgm89bi9crvk6lb-r-3.2.1. <rekado>so, why do I not see this store path in my substitute cache? <rekado>In fact, I don't even see "-r-3.2.1" in the cache. <rekado>I moved away the substitute cache and started with a fresh one. <rekado>surprised to see that all of them look like this: <rekado>there is only *one* file that looks different, and that's the one for /gnu/store/qp42nrg3vxvcswhvdkgis7lfmr8il8bw-netpbm-10.61.01-checkout <rekado>could happen when the response from looking up the narinfo is 404 or when it's 200 and read-narinfo fails. <rekado>I'd really like to have more debug info.