IRC channel logs


back to list of logs

<mark_weaver>sneek: later tell tyrion-mx: regarding the error in, 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
<mark_weaver>sneek: botsnack
<aravind>I am trying a "guix refresh -u" and that dies with a "guix refresh: error: mkstemp!: Permission denied"
<aravind>a "guix pull" works just fine.
<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 :-)
<phant0mas>I'll be afk for a bit
<sir123>The source tarball doesn't specify its licence, but Debian devs seemto think its gpl2
<sir123>ok thanks phant0mas
<sir123>automake should be able to create a file in the source tree, right?
<sir123>it's reporting issues
<sir123> error: required file 'build-aux/config.rpath' not found
<sir123> error: required file 'nix/' 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 ./ first [not a guix user [yet] by the way]
<sir123>*goes afk*
<sir123>there is no in the tree
<civodul>Hello Guix!
<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>amz3: it's not part of Guix
<Steap>it's a modified verson of tox
<Steap>it is on my git page :
<civodul>someone suggested that we should support "Oz":
<civodul>didn't know that one
<mark_weaver>hi civodul!
<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>the errors are like this:
<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>aarrgh, yes
<civodul>damn it
<civodul>hopefully that's the only place where that "/" notation is used
<civodul>(i thought it wasn't used anywhere)
<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")
<mark_weaver>ACTION attempts to search for them
<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
<mark_weaver>I wasn't able to find any other either
<civodul>it turned out to be easily fixed as well
<mark_weaver>that's good!
<civodul>i shamelessly offloaded the cross-gcc build to 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?
<mark_weaver>heh :)
<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
<mark_weaver>sounds reasonable
<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
<civodul>ACTION goes out
<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, 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>oh, nice
<tyrion-mx>best support ever :D
<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?
<tyrion-mx>rekado, yes, to both questions
<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>it's gonna take hours again
<tyrion-mx>mark_weaver, is there no other solution that can make me save some time?
<tyrion-mx>btw that file does not exist in /gnu/store
<mark_weaver>it shouldn't take hours again
<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
<mark_weaver>did you delete or modify anything in your store?
<tyrion-mx>ok, I will try then
<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.
<rekado>there are no local changes.
<tyrion-mx>mark_weaver, same error
<tyrion-mx>should I remove the grub line from the config.scm file?
<tyrion-mx> (bootloader (grub-configuration (device "/dev/sda9")))
<tyrion-mx>ok, that line must stay there it seems
<paroneayea>heh, the pumpiverse markov bot is saying things about guix
<paroneayea>ACTION <3 markov bots
<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>and now?
<tyrion-mx>should I reinstall guix and try again?
<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.
<tyrion-mx>let's try, thanks for the help
<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>It does not support the command
<tyrion-mx>I ran guix gc and it seems that it is deleting all
<mark_weaver>did you at any point build guix from source code?
<mark_weaver>manually, that is.
<mark_weaver>(i.e. from either our source tarball or a git checkout)
<tyrion-mx>mark_weaver, nope
<mark_weaver>well, I don't know what happened
<mark_weaver>I've not seen or heard of this problem before
<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>I don't get it.
<alezost>tyrion-mx: any variant will do
<tyrion-mx>ok, great
<rekado>this is crazy.
<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>yes, it was built from source.
<mark_weaver>and tell me where ~/.config/guix/latest points to
<mark_weaver>rekado: from a git checkout?
<rekado>yes, from a git checkout.
<rekado>~/.config/guix/latest does not exist
<rekado>(this is not on GuixSD)
<mark_weaver>so this happens when running ./pre-inst-env guix ... ?
<mark_weaver>what is the output of "git describe" ?
<mark_weaver>sorry, "git describe --dirty"
<mark_weaver>you might try "make clean-go && make"
<rekado>I did that already.
<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
<mark_weaver>is this on x86_64?
<rekado>yes, it's on x86_64.
<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
<mark_weaver>do those match what you see?
<rekado>yes, they match
<mark_weaver>I'm sorry, I'm out of ideas
<rekado>thanks, anyway.
<rekado>I have the suspicion someone fiddled with the server and didn't tell me about it.
<rekado>things don't just break.
<mark_weaver>you might try clearing out ~/.cache/guile/ccache
<mark_weaver>although I'm not sure it should matter
<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>updating list of substitutes from ''... 100.0%
<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>it can be found on my laptop.
<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>(narinfo (version 1) (cache-uri "") (date 1436910402) (value #f))
<rekado>(value #f)
<rekado>there is only *one* file that looks different, and that's the one for /gnu/store/qp42nrg3vxvcswhvdkgis7lfmr8il8bw-netpbm-10.61.01-checkout
<rekado>how can this happen?
<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.