IRC channel logs

<sneek>tohoyn: Greetings!!

<tohoyn>sneek: botsnack

<civodul>lloda: hello! it seems that https://git.savannah.gnu.org/cgit/guile.git/commit/?id=3b47f87618047ebb8812788c64a44877a4f2e0dd broke 32-bit builds

<civodul> https://ci.guix.gnu.org/build/3334046/log

<civodul>something with ‘jenkins-lookup3-hashword2’

<lloda>hmm there was a later patch on that

<lloda>the patch after https://git.savannah.gnu.org/gitweb/?p=guile.git;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 https://ci.guix.gnu.org/eval/latest/dashboard?spec=guile and following the red dots

<civodul>specifically from https://ci.guix.gnu.org/build/3349092/details

<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?

<lloda>yes

<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: https://paste.debian.net/1305163/ 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

<sneek>:)

<graywolf>civodul: Are you sure about guix using --no-auto-compile? I don't get why the cache file is created https://paste.debian.net/1305168/

<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 :)

IRC channel logs

2024-01-24.log