IRC channel logs


back to list of logs

<sneek>tohoyn: Greetings!!
<tohoyn>sneek: botsnack
<civodul>lloda: hello! it seems that broke 32-bit builds
<civodul>something with ‘jenkins-lookup3-hashword2’
<lloda>hmm there was a later patch on that
<lloda>the patch after;a=commit;h=f0df1ed0fdca7a63cffda5e53c968e814b7b06ec
<lloda>does that not fix it
<lloda>i guess it's already bisected
<lloda>idk what 32 bit has to do with any of that
<lloda>is that the 32 bit log? i see 18446744073709551615 there
<civodul>lloda: that’s a build log for i686, yes
<lloda>can you produce a log for the next commit? it was a fixup for this one
<lloda>civodul: jenkins-lookup3-hashword2 is from a much later commit so my patch cannot have broken it. How did you get at that
<graywolf>civodul: Thanks for the reviews. Regarding #68505, I have no issues with using -CP instead of --pure, but would like to keep the -D -f guix.scm. I don't like the autoloading magic that much.
<graywolf>Would that be acceptable?
<civodul>graywolf: sure, fine with me!
<civodul>there are folks insisting on conventions, and folks insisting on being explicit
<civodul>i often lean towards the latter category, but trying to listen to all parties :-)
<civodul>lloda: i was looking at and following the red dots
<civodul>specifically from
<civodul>it’s possible that CI is pointing at the wrong commit range though
<graywolf>cool, will send updated patches later today
<civodul>(for instance because it’s been failing for other reasons)
<civodul>graywolf: thanks!
<civodul>i just realized i hadn’t made the nickname/person mapping until now :-)
<graywolf>And I just today realized I can just read your nick backwards to get the mapping :D
<attila_lendvai>guile picks up old versions of definitions, and it gets fixed when i `rm -rf ~/.cache/guile/`. shouldn't it just work based on filesystem timestamps? or is it an issue on my end with some config? (context: ./pre-inst-env in guix building packages from a checked out channel)
<lloda>timestamps aren't enough, guile would also need to check which modules depend on which, and it doesn't do that atm
<graywolf>Wait, isn't that... bad?
<attila_lendvai>but somehow it didn't cause me any headaches. maybe autocompilation got enabled meanwhile?
<lloda>i thought this was about autocompilation, didn't notice the guix context
<lloda>idk if that makes any difference
<civodul>graywolf: heh :-)
<graywolf>civodul: One interesting downside of the -P is that now ./meta/guile no longer works outside the guix shell. Hm.
<civodul>in practice i doubt anyone relies on auto-compiled stuff except for trivial single-file programs
<civodul>i mean, distros ship .go files
<graywolf>I gonna test if it will work (outside guix shell) without the -P
<lloda>idk about that. I've never precompiled anything in 20+ years of using guile
<graywolf>I use auto-compilation everywhere even for less trivial stuff, I assumed it is safe
<graywolf>I guess I will stop
<civodul>graywolf: yes, so after that one needs to do all their development in ‘guix shell -CP’
<lloda>i do have to clear the cache now and then, but not all that often
<civodul>graywolf: do you have examples?
<graywolf>But explains why my script to update firefor sometimes compiled old version of the package
<civodul>(re auto-compilation)
<graywolf>sure, sec
<attila_lendvai>lloda, in CL i used to have an rmfasl alias. whenever something baffling happened, i just rmfasl-ed a relevant regexp and retried, without much thinking. only started investigating afterwards.
<attila_lendvai>ACTION is not coding much in CL nowadays
<lloda>i confess that's more or less how i operate
<graywolf>civodul: this script sometimes compiled old version of firefox, despite the package being update in the git.
<graywolf>So I "solved" it by (setenv "GUILE_AUTO_COMPILE" "fresh")
<graywolf>And the autocompilation is necessary to get useable error message, that was the reason to not just turn it off.
<attila_lendvai>and when i (often) get that ";;; note: source file ... newer than compiled ...", does guile then load the new version? because the message doesn't say.
<civodul>graywolf: i’d use --no-auto-compile :-)
<civodul>setting GUILE_AUTO_COMPILE happens too late because you’re already running the script
<graywolf>in here it is no problem, I am running (invoke "sh" "-c" "set -x; cd \"$1\" && guix build -L . \"$2\" " "-" wt (symbol->string pkg))
<graywolf>That guix build used old version, but it is a separate process, to the setenv if good enough
<civodul>the ‘guix’ command sets --no-auto-compile
<graywolf>Ok. In that case I have zero idea why the setenv helped. But it did.
<chrislck>sneek: botsnack
<graywolf>civodul: Are you sure about guix using --no-auto-compile? I don't get why the cache file is created
<civodul>try: head $(type -P guix)
<civodul>ah well, for pkg.scm, that’s another story
<civodul>see ‘load*’ in (guix ui) :-)
<graywolf>Ah I see. Then I am back to "no idea" :/
<graywolf>Aaaaah, even with --no-auto-compile, the cache is used *if* it already exists.
<graywolf>Ok, one step close.
<rlb>civodul wingo: iirc (a while back) you'd decided the switch to parallel testing I'd proposed was OK. So I might merge it soon if that's still all right. (Cuts make -j5 check time roughly in half with 4 cores.)
<civodul>rlb: yay! i didn’t look at it but wingo was okay IIRC
<wingo>sgtm :)