IRC channel logs


back to list of logs

***Elon_Satoshi is now known as Copenhagen_Bram
<reed_>Hi All, out of curiosity, when you run "guix package --upgrade" what percentage of the time does it work flawlessly on the first try?
<nckx>reed__: 90% of the time? Every time.
<nckx>What's your problem?
<reed__>It usually fails for me and I need to upgrade many packages on their own
<reed__>It might be because my wifi is spotty
<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__>so I don't really have any exact outputs
<nckx>reed__: But repeated ‘guix package --upgrade .’ (‘.’ for ‘everything’) always fail at the exact same spot?
<nckx>Not that general fragility isn't a problem we should fix eventually, but that sounds like a real bug.
<reed__>yes. I believe i had "guix package --upgrade . --do-not-upgrade qutebrowser"
<reed__>It could just be that those particular spots had larger downloads so they were more likely to be interrupted by a network issue
<reed__>but it was remarkably consistent
<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.
<nckx>Sorry I can't be of more help :-)
<reed__>No problem! I'm only a novice Guile programmer and haven't done any HTTP programming. But perhaps as a longterm goal I could look into it
<reed__>nckx: I am able to reproduce the bug while upgrading qutebrowser. How should I file a bug report?
<nckx>reed__: bug-guix at
<reed__>nckx: thanks
*nckx → 😴
<g_bor>hello guix!
<janneke>hello g_bor!
<civodul>Hello Guix!
*civodul does a "spring" cleanup in the system code
<snape>hi guix!
*snape just spilled coffee on his 90€ keyboard :/
<civodul>ouch :-/
<kmicu>Now you can finally clean it ヽ(*^▽^)/ *whistles Always Look On The Bright Side Of Life*
<snape>True! I just did it ;)
<demotri>I'm trying to understand Cuirass and Guile debugging. I'm in a Cuirass environment, started guile.
<demotri>This works: (parameterize ((%package-database my-db-file)) (with-database (for-each (lambda (spec) (db-add-specification spec)) new-specs)))
<demotri>I can see the new spec and input in the sqlite DB.
<demotri>Now I try this: (parameterize ((%package-database my-db-file)) (with-database (db-add-build my-build)))
<demotri>It fails: In cuirass/utils.scm:
<demotri> 115:35 0 (_)
<demotri>cuirass/utils.scm:115:35: Throw to key `sqlite-error' with args `(#f 1299)'.
<demotri>The call is still "hanging", there is no REPL-promt, I need to hit Ctrl-C.
<demotri>How can I debug this? Can I get any more information? How do I interpret the args (#f 1299)?
<snape>demotri: could you share your whole code? (new-specs, my-build...)
<demotri>snape: I'm preparing a paste.
<demotri> Its a bit dirty, but the main things are there. I not only want a solution, I also want to know how to debug things with Guile :-)
<demotri>Ah, and the purpose: In this step, I don't care about Cuirass as a build system. I want to fill the database with some random stuff, and if it is heavily filled, look at the performance.
<snape>demotri: do you want Berlin's database?
<demotri>snape: That would be very kind, for looking at the performance/indices.
*snape is preparing it
<snape>it's a snapshot from last month maybe
<demotri>snape: I think that doesn't make too much difference concerning the API performance.
<snape>demotri: by the way, db-add-build returns #f if it produces no new outputs
<snape>so you need to add at least one output
<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: both, actually ;)
<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>on the git-checkout
<demotri>snape: 1.5G, currently downloading. Thanks!
<snape>and then, there is a ./pre-inst-env too
<demotri>OK, so far. But then? After make? If I just say "guile" and then (use-modules (cuirass)), that's the old one from the Guix store.
<demotri>Ah, that's the trick.
<snape>yes, ./pre-inst-env guile
<demotri>So, just "./pre-inst-env guile"?
<snape>I think so
<demotri>OK ;-)
<demotri>Will try that out.
<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.
<snape>demotri: great!
<civodul>hey demotri!
<civodul>good to see work on the database stuff :-)
<demotri>civodul: Hi. Work is at first understanding all this. I don't know when/if there is a result. Not too much praise before anything is done.
<g_bor>hello guix!
<g_bor>demotri: What are you working on?
<civodul>hey g_bor!
<civodul>demotri: yeah, the code has become a bit "tricky", as you rightfully pointed out on the list
<demotri>g_bor: Trying to understand Cuirass. Looking at the Database and if/how one can make it faster. Getting into Guile-debugging, etc.
<g_bor>demotri: nice!
<davexunit>rekado_: could you explain the reasoning behind changing the Tiled source field to fetch from git?
<mbakke>davexunit: GitHub-generated "archive" tarballs are not deterministic and may get a different checksum in the future.
<davexunit>mbakke: we've been using them for years and I've never seen them generate something different
<davexunit>is this a new change at github?
<bavier>it happened to a few packages
<bavier>and, yeah, we figured out that github's method is not deterministic
<bavier>so switching to git checkout's is a mitigation strategy
<davexunit>I'm surprised this wasn't a problem sooner
<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).
<apteryx>davexunit: I wrote a tool to find and fix the hashes of the packages with mutated tarballs from github:
<davexunit>I'm surprised they aren't cached
<apteryx>or they might be cached but still cache is not persistent so not guaranteed to not change.
<apteryx>ideally my script would know how to rewrite the package definition to use git-fetch instead of url-fetch ;)
<g_bor>hello guix!
<g_bor>I just got the word, that we have a new Outreachy intern.
<g_bor>lsl88: congratulations!
<lsl88>thank you! I am really grateful. Sorry, I am crying of happiness
<apteryx>lsl88: congrats and welcome :-)
<lsl88>I cant believe it
<lsl88>thank you, thank you for being such a lovely community
<apteryx>don't hesitate asking questions here or on the mailing list
<civodul>ooh, congrats lsl88!
<civodul>that's really good news
<demotri>g_bor: My first reaction was to say that we are not yet allowed to tell. But the deadline is over since 13 minutes :-)
<demotri>lsl88: Congrats :-)
<g_bor>demotri: I checked the alumn page on outreachy before telling :)
<demotri>g_bor: Yes, I checked that too and noticed from the mail that we already have Nov 16, 16:00h UTC :-)
<thorwil>hi guix!
<janas>lsl88: congrats!
<g_bor>I have to go now, have a nice day!
<thorwil>seems the symlink repair yesterday was good for exactly one guix pull (2 if one counts a `sudo guix pull` to the same commit)
<thorwil>"Migrating profile generations to '/var/guix/profiles/per-user/thorwil'..."
<thorwil>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/thorwil/current-guix-1-link"
<nckx>Congratulations, lsl88!
<thorwil>what achievment did i miss? :)
<lsl88>thank you all, sorry for the delay, I was thanking also my relatives for the support
<bavier`>lsl88: welcome!
<thorwil>ah outreachey. congratulations, lsl88
<thomassgn>hm, first time I've had. 'guix build: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused' ... is this a known fixable problem?
<thomassgn>same happens with guix environment.
<demotri>thomassgn: Is your build server running?
<demotri>Try to restart it.
<mbakke>thomassgn: Sounds like your guix-daemon has stopped.
<civodul>thomassgn: that, or the permissions on /var/guix/daemon-socket/socket are wrong
<thomassgn>aye. Indeed. I just found that guix-daemon does not have '--fallback' as an option. fiddling it back now... :) Thanks
<thomassgn>that is the server was not running.
<civodul>is this NSS test failure a known issue?
<civodul>i vaguely remember people discussed NSS issues recently
<bavier`>does anyone know what the '#:system "arhmf-linux"' in go's package is about?
<civodul>it's from commit 2ab321ca37d1c00c1540d78d587226d3d487b2d4, efraim probably knows :-)
<bavier`>on my aarch64 system it seems to cause issues
<bavier`>"guix build: error: build failed: while setting up the build environment: cannot set armhf-linux personality: Invalid argument"
<dustyweb>beep boop
<janneke>civodul: i'm adding mescc-tools-bootstrap-tarball and %bootstrap-mescc-tools to replace %mescc-tools-seed
<lsl88>I have a question. Do you have any preferences about a site for my blog?
***rekado_ is now known as rekado
<rekado>thorwil: have you confirmed that the symlink chain is as I described yesterday?
<thorwil>rekado: yes, it _was_
<thorwil>i wonder if `sudo guix pull --commit=...` might have to do with this reset to the wrong links
<rekado>just to be sure: what does “sudo guix --version” say?
<thorwil>rekado: guix (GNU Guix) 0.15.0-2.8bbb79c
<rekado>thorwil: and “sudo -E guix --version”?
<rekado>that “sudo guix” is from mid-July.
<thorwil>rekado: guix (GNU Guix) 0.15.0-2.8bbb79c
<thorwil>that would explain why `sudo guix describe` doesn't work. but what did `sudo guix pull --commit=...` do, then?
<thorwil> /root/.config/guix contains no "current", only "latest"
<apteryx>thorwil: you must have your guixes confused in the new vs old scheme; new guix is under ~/.config/guix/current, old one would have been part of your ~/.guix-profile
<apteryx>check that your PATH has the new ~/.config/guix/current location before ~/.guix-profile
<apteryx>otherwise it'll not find the new guix copy
<thorwil>echo $PATH: /home/thorwil/.config/guix/current/bin:/home/thorwil/.guix-profile/bin:/home/thorwil/.guix-profile/sbin:/home/thorwil/.config/guix/current/bin:/home/thorwil/.guix-profile/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
<thorwil>sheesh, i must have it extended twice
<thorwil>i must admit i'm not sure what the `${PATH:+:}$PATH` part in `export PATH="$HOME/.config/guix/current/bin${PATH:+:}$PATH"` does
<nckx>thorwil: Add a ‘:’ iff $PATH is not the empty string.
<thorwil>nckx: ah, ty. i take it that line is correct, then
<nckx>${PATH:+:} expands to ‘’ or ‘:’, never anything else. Hence the $PATH following it.
<nckx>Yes, that part looks legit.
<thorwil>still wondering why "/home/thorwil/.config/guix/current/bin" appears twice
<thorwil>pretty sure i did several `sudo guix pull` since july and before i learned of --commit
<thorwil>anyway, `sudo guix pull` referred to comit a7b7d48cc70cee61b0212b531461430cd4c099ad this time
<thorwil>16-Nov-2018 15:50
<thorwil>should /root/.config/guix contain a "current"?
<thorwil>if so, could i just symlink to ~/.config/guix/current and never mess with `sudo guix` again?
<apteryx>thorwil: Are you on GuixSD?
<thorwil>apteryx: no, since i need a few things not available there, i went back to ubuntu
<apteryx>thorwil: OK
<apteryx>the symlink might work, yes, but I'm not sure how the guix-daemon will be updated if at all that way
<apteryx>(on foreign distro this is usually handled by guix pull as root)
<apteryx>someone please correct me if I'm telling lies ;)
<janneke>civodul: i'm building/packaging %bootstrap-mescc-tools the traditional way for now
<thorwil>it looks like a i have been building new guix for root frequently, but somehow an old version got stuck, i.e. the symlinking business went wrong
<janneke>i was hoping to have a full source packaging of mescc-tools...but I don't see how to package it at this time
<bavier`>thorwil: specific things missing?
<thorwil>bavier`: yes, 2 cases of non or not quite free software, at least one crucial package: freecad. oh, and i happen to really like the unity desktop and getting that thing to work elsewhere ...
<bavier`>thorwil: thanks
<bavier`>have you tried the GNOME3 desktop?
<civodul>janneke: ok! not sure what the "traditional way" is, but i'll see :-)
<thorwil>bavier`: a long time ago. havn't tried any recent version, due to both aesthetic and technical considerations (trying to keep it short and polite ;)
<civodul>thorwil: ~/.config/guix/current is per-user, such that each user can update when they want
<bavier`>thorwil: understood, thanks
<civodul>on a single-user machine though, it would make sense to allow people to upgrade all profiles at once
<thorwil>civodul: i though use of --commit would bring me closer to that
<thorwil>civodul: however, resolution of `guix` in the sudo case is obviously wrong on my system
<civodul>thorwil: yes, you can use --commit to get the same Guix both in root and your other user, that works well
<civodul>but perhaps we could have, say, "sudo guix pull --global", which would update for every user
<civodul>dunno, just thinking out loud
<thorwil>sounds good. though in the ned, it's about all of pull, package -u and garbage collection/cleanup, right?
<thorwil>which guix -> /home/thorwil/.config/guix/current/bin/guix
<thorwil>sudo which guix -> /usr/local/bin/guix
<thorwil>i hope ^ is as expected?
<janneke>civodul: i now also updated %bootstrap-tarballs on my core-updates-next
<janneke>civodul: pretty sure we should be able to build mescc-tools without any dependencies some time soon, but atm i'm lost how to do that
<civodul>janneke: why without any dependencies?
<janneke>and a simple, transparent, guix-scripted bootstrap is preferrable
<civodul>on master, if you run "guix build bootstrap-tarballs", you get those 5 big tarballs
<janneke>stage0 has a 500 byte hex0 assembler...the only dependency that should spawn all of stage0
<civodul>they have lots of build-time dependencies
<civodul>but that's not a problem
<janneke>sure, i just updated my core-updates-next with one extra patch for bootstrap-tarballs :-)
*civodul checks
<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
<janneke>i'm so embarrased i missed this
<janneke>tnx :-)
<civodul>also we must make sure make-bootstrap.scm doesn't refer to bootstrap.scm, otherwise we're running in circles :-)
<janneke>ah, i think i added %bootstap* to boottrap-tarballs -- where i should have added the actual tarballs from whith the %bootstrap* are created
<janneke>so 47102264e is fubar, the earlier patches should be OK
*janneke rewrites bootstrap-tarballs once again