***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. <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 gnu.org *civodul does a "spring" cleanup in the system code *snape just spilled coffee on his 90€ keyboard :/ <kmicu>Now you can finally clean it ヽ(*＾▽＾)／ *whistles Always Look On The Bright Side Of Life* <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>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>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>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: 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 <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. <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. <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>demotri: What are you working on? <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. <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 <bavier>and, yeah, we figured out that github's method is not deterministic <bavier>so switching to git checkout's is a mitigation strategy <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>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>I just got the word, that we have a new Outreachy intern. <lsl88>thank you! I am really grateful. Sorry, I am crying of happiness <lsl88>thank you, thank you for being such a lovely community <apteryx>don't hesitate asking questions here or on the mailing list <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 :-) <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 :-) <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" <lsl88>thank you all, sorry for the delay, I was thanking also my relatives for the support <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? <demotri>thomassgn: Is your build server running? <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 <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" <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>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>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? <thorwil>apteryx: no, since i need a few things not available there, i went back to ubuntu <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 <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 ... <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 <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 <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 <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 <janneke>sure, i just updated my core-updates-next with one extra patch for bootstrap-tarballs :-) <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 <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