<nckx>reed__: Yeah, downloading substitutes blows up without retrying if something fails.
<reed__>nckx: the only weird thing is that it would always fail at the same points, so it didn't seem to be just any random networking error
<nckx>Interesting. If you think that's really the case, would you be willing to report a bug (to bug-guix), with the relevant output?
<reed__>i would get a "substitute failed" error, but then if I ran "guix package --upgrade <name of the specific substitute where it failed>" then "guix package --upgrade" it would usually make it past that part and fail at a later substitute
<reed__>Unfortunately, i have since restarted my computer
<reed__>and I don't think that would really explain why upgrading the specific spot separately would succeed
<nckx>reed__: Interesting & yes, that's what I was considering too (texlive for example used to be literal gigabytes if it isn't still). I guess the only way to know for sure is to keep the output when you next upgrade everything & feel free to report a bug if it seems less-than-random.
<reed__>i will be sure to save my output next time
<nckx>It would be nice to eventually retry lost connections (HTTP supports that but I doubt our simple Guile HTTP client does). Patches welcome, if that's your jam.
<demotri>Still, I want to know what my problem here is and how I can debug Guile-things in general :-)
<demotri>snape: Ah, I see. "(if (null? new-outputs) [...] #f ...)" Still, even when I added some output, it failed with an exception. And I don't know how see the real problem or how to step through it.
<demotri>I tried to add a breakpoint: ",break db-add-build". It breaks. But then ,locals is empty. And ,step doesn't look very helpful. What are all those frames?
<snape>demotri: I never use the Guile step by step debugger. Actually, I thought it didn't have any.
<snape>maybe you'll have more luck on #guile though
<snape>demotri: to debug it, you could display the requests, and type them manually to better understand which one goes wrong
<demotri>snape: You mean: In the method "db-add-build", before the "(sqlite-exec", I should insert a display/format of the prepared text? Or in general add some debugging outputs at interesting lines?
<snape>demotri: did you get my private message with the link?
<demotri>I had that idea but then thought of how to do that: I'm currently using the compiled cuirass package from guix. How would I get my debug messages into the code? I also have the git-checkout. I could insert the lines there. How would I this modified cuirass then? I currently only think of "guix build --with-sources=...", but it must be easier.
<snape>demotri: just ./bootstrap && ./configure && make
<snape>cool! I'm going to have lunch, I'll be back in an hour or so. Good luck ;)
<demotri>snape: I will have lunch nearly too. Thanks so far :-)
<demotri>snape: Trick with "./pre-inst-env guile" works: I tried displaying messages in the good-case of "db-add-specification" and I see them. Will go to lunch now and then have to work something. Thanks so far.
<apteryx>davexunit: it doesn't happen often, but it did and might reoccur if they ever upgrade their infrastructure that would change (say, a bugfix last last time) the way their tarballs are generated (since they are generated on demand, not cached).
<janneke>and stage0 should be able to build all of mescc-tools, which should be able to build m2-planet, which should be able to build mes.c ... all only depending on one 500 byte binary ... but we're not there yet
<civodul>janneke: 5702107a31f52a615c516084b7a82d9f5e2967e0 is exactly what we need, thanks!
<civodul>as a followup, we should change make-bootstrap.scm to refer to %mescc-tools-bootstrap-tarball, right?
<civodul>such that "guix build bootstrap-tarballs" does the right thing