IRC channel logs
2021-05-06.log
back to list of logs
<rekado>civodul: thanks for the patches! <rekado>on this old store I have a number of store items that appear to be corrupt. This makes “guix copy” abort. <rekado>is it possible to just attempt to fix that one item instead of runnig “guix gc --verify=contents,repair” over the whole store? <rekado>(because that would take days and I’m afraid it would also helpfully delete things it can’t reach…) <efraim>(ins)efraim@3900XT ~/workspace/guix$ sudo guix gc --verify=contents,repair /gnu/store/q54f2b7qz4vhwbmxww0i19z8mayabmpg-lzip-1.21 <efraim>guix gc: error: extraneous arguments: /gnu/store/q54f2b7qz4vhwbmxww0i19z8mayabmpg-lzip-1.21 <rekado>in my fever dreams I bind-mounted the item in question into a container to hide the rest of the store… <rekado>(got my AstraZeneca shot yesterday) <zimoun>rekado: how do you feel? I am procrastinating to get mine. :-) <rekado>I had a mild fever (38 deg) yesterday night, violent shivering, now muscle pain — the usual flu symptoms. <rekado>but no headache; I’m just feeling dizzy. <zimoun>cool, it means you have a good immunitory system ;-) <rekado>yeah, my immune system is easily spooked <rekado>I found it interesting that my history of thrombocytopenia was not considered a counter indication. <rekado>it seems that the fears of blood clotting due to a violent auto-immune response are a little exaggerated *rekado runs “guix gc --verify=repair,contents” and waits <zimoun>yeah, on the other hand thrombocytopenia means your blood clots hardly, right? Well, I agree with you with “little” exaggeration. :-) <rekado>AFAIUI the blood clots are not due to thrombocytes doing their thing, but due to the immune system attacking thrombocytes and using them up in the process, leaving behind gobs of garbage that clogs up veins. <rekado>(my bout of thrombocytopenia half a life-time ago was also due to an auto-immune response.) <zimoun>if ndeck was here, we would have the medical explanations. ;-) <civodul>hopefully "guix gc" will be able to salvage store items <zimoun>what does it mean? guix package: error: getting attributes of path `/gnu/store/kg9mirg6xbvzcp0a98v7326n1nvvwgsj-hello-2.10': No such file or directory <roelj>Hey all, we are having a very strange case where the guix-daemon deletes the glibc store path of itself. <roelj>Has anyone experienced this before? <efraim>Sounds like something related to grafting <rekado>roelj: is localstatedir correct? <rekado>I literally had the same problem <rekado>the background is that localstatedir was once configured to be /gnu/var/guix <rekado>since several months (years?) “guix pull” reproduces that localstatedir when you pull <rekado>but when I pulled too far into the past I ended up with a guix-daemon that assumed that /var/guix contained the db <rekado>and so it ended up merrily deleting things from /gnu/store until it deleted too much of itself to abort. <rekado>efraim: grafting is oft-maligned, but it won’t delete anything. <zimoun>I am running ssh remote guix archive --generate-key | guix archive --authorize but it returns «guix archive: error: mkdir : Permission non accordée». I am not have root acces to this remote machine. How can I exchange items? <rekado>the acl is stored in /etc/guix/acl, and authorization writes to it. <rekado>“guix archive --generate-key” also writes to /etc/guix <rekado>perhaps you can overwrite the sysconfdir to write elsewhere? <zimoun>ok, once the key exist on the remote machine, how do I transfer it? <rekado>you only need the public key at /etc/guix/signing-key.pub; everyone should be able to read it. <zimoun>so you mean ssh remote cat /etc/guix/signing-key.pub | sudo guix archive –authorize ? <rekado>I’m now doing this to copy as many useful store items as possible: for p in /gnu/var/guix/profiles/per-user/*/*; do echo $(readlink -f $p); done | grep -v "/gnu/var" | xargs -n 10 guix copy --to=sl-bimsb-p-gxm1 <rekado>zimoun: yes, something like that <roelj>rekado: I set GUIX_STATE_DIRECTORY and NIX_STATE_DIR (for very old daemons) in the systemd service that runs the guix-daemon. <roelj>rekado: Could there be a case that this isn't enough? <roelj>zimoun: It is very nice to know that "guix pull" preserves it. The reason I set the above mentioned environment variables was because I want to be able to "guix pull" rather than build-my-own every time. <zimoun>roelj: it can be error prone too. :-) For instance sysconfdir is not mentioned in the manual and the location is not standard. So the usual “./configure --localstatedir=/var && make && ./pre-env-inst guix pull” leads something different as just “guix pull”. :-) <rekado>roelj: I switched to “guix pull” for our cluster deployment a year or two ago. <rekado>I don’t miss the “pre-inst-env” hackery <roelj>Is GUIX_STATE_DIRECTORY equivalent to --localstatedir, and is that what can cause guix-daemon to delete a glibc store output? <civodul>roelj: GUIX_STATE_DIRECTORY is equivalent to --localstatedir, yes <civodul>it can also cause guix-daemon to delete Inkscape from the store <roelj>Right, so currently, when I run guix-daemon with GUIX_STATE_DIRECTORY=/gnu, and I do "guix build acl", the build fails and the glibc store path is removed, so a subsequent call to "guix" fails. <roelj>Well, our localstatedir is /gnu, so that should be correct for our cluster. It seems as if guix-daemon doesn't pick up the environment variable. <rekado>ah, I didn’t realize it was /gnu :) <rekado>so the db sits right there in /gnu/db.sqlite? <civodul>roelj: shouldn't it be GUIX_STATE_DIRECTORY=/gnu/var then? <roelj>The database sits in /gnu/db <rekado>FWIW the “corruption” I see in our /gnu/store is from auto-compiled Python files! <rekado>I must have loaded some Python package on the server where the daemon runs <rekado>I wonder if we could add that bind-mount magic to the systemd unit file. <zimoun>Ouch! It is crazy all concepts Guix has, which are so familiar when one uses it daily. Then how hard it is to explain them… aside to keep the right level without too much details. civodul, about JRES, yeah 1h is nothing. ;-) <zimoun>I have seen an extension, I guess. <zimoun>qnd for live demo, one really needs to cache all the commands which will be launched :-) <civodul>zimoun: oh yes, live demos can easily go wrong <civodul>when i do that during talks, i make sure the packages i'm going to refer to are in the store beforehand <zimoun>yeah, I do that too. But, you have a question, you slightly tweak and boum! Heavy computations. :-) Some part are slow, we know. Other are just because doing The Right Thing is just costly. But people have never thought about it… and compare to APT, Conda & friend. <zimoun>And it is the first time I really realize how far the usual scientific is far from the Scientific Method applied to computations. :-) <zimoun>Ah, a slow example: I launched «guix time-machine --commit=d57660c5 -- build hello», commit from 2019, I go to grocery, bread etc. and it is still running on a workstation. ;-) <civodul>zimoun: let's hope it eventually succeed :-) <rekado>time-machine has to build Guix and if you’re unlucky there’s no substitute for that old version of Guix, so you end compiling a lot. <rekado>you also compile with an older Guile, which can sting <zimoun>yeah and then unlucky again, you can also compile gcc and friends… the DeLorean is really expansive. ;-) <civodul>BTW "guix time-machine --commit=a099685659b4bfa6b3218f84953cbb7ff9e88063 -- repl" (for 1.2.0) went pretty fast for me <civodul>granted, it's less than one year old