IRC channel logs

2021-12-15.log

back to list of logs

<PurpleSym>Trying to merge js-mathjax@3, how would I convert origins inside inputs to gexp inputs?
<rekado>I don’t know. But you can still use the old style.
<PurpleSym>Alright, I’ll keep it as-is. Thanks :)
<zimoun>civodul, does the target cluster require something configured to run relocatable pack? I get «proot error: ptrace(TRACEME): Operation not permitted»
<civodul>zimoun: hi! ah
<civodul>so ptrace(2) normally just works, but there's a silly feature in Linux that allows you to disable it
<civodul>yama something
<civodul>i suppose /proc/sys/kernel/yama/ptrace_scope is 0 on your machine?
<civodul>if so, PRoot won't work
<civodul>so you can switch to GUIX_EXECUTION_ENGINE=fakechroot
<zimoun>civodul, it is 3.
<zimoun> GUIX_EXECUTION_ENGINE=fakechroot ./mybin/sh returns out of memory to store relocation results for ./mybin/sh
<civodul>could you paste the exact output?
<civodul>and command
<zimoun> https://paste.debian.net/1223574/
<zimoun>civodul: Pack using “guix pack -RR -S /mybin=bin bash“ on my laptop and then ./mybin/sh on cluster. Message link above.
<civodul>zimoun: and the output when you set GUIX_EXECUTION_ENGINE=fakechroot ?
<civodul>(note that gdb is also unusable on this machine, you should tell the admins...)
<zimoun> https://paste.debian.net/1223576/
<zimoun>It is a new cluster. :-) Since many things are bigger than my skills, I prefer ask before if I miss something. :-)
<civodul>woow, it's an interesting error that you have here
<zimoun>ah!
<civodul>zimoun: someone reported that the datefudge source tarball vanished...
<civodul>... and "guix lint -c archival datefudge" says it's not archived
<civodul>is it a case you already encountered before?
<civodul>it's annoying that our sophisticated machinery isn't helping when it should :-)
<zimoun>civodul, yes. Yesterday morning I was a bit upset that datefudge is not in Berlin or Bordeaux and not yet in Disarchive DB (because xz). Why do we have 2 build farms if we are not able to simply cover ‘guix pull’ and robustify?
<zimoun> http://logs.guix.gnu.org/guix/2021-12-14.log#103342
<zimoun> http://logs.guix.gnu.org/guix/2021-12-14.log#103945
<zimoun>To answer your question, the machinery for tarball is not yet robust.
<zimoun>Because the coverage is not 100% yet.
<zimoun>I mean, when Berlin is down, as it is these days, Guix is off. When Bordeaux must cover the basic operations as ’guix pull’, even if substitutes are not there.
<zimoun>And it is not the case for reasons I miss.
<zimoun>civodul, to be concrete, I do not understand why https://git.savannah.gnu.org/cgit/guix.git/tree/etc/source-manifest.scm is not run on Bordeaux. As I proposed https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00174.html or there https://yhetil.org/guix/87bl44vfvg.fsf_-_@gmail.com/ so I gave up on this front. :-)
<civodul>zimoun: oh that's because it's xz, so it's understandable
<civodul>(i was missing that bit of info)
<civodul>as is often the case, shit happens in a fairly coordinated fashion: ci.guix is in a bad shape, and bordeaux.guix ran out of space a few days ago
<civodul>it needs more disks, etc.
<zimoun>Forest Gump quotation? ;-)
<civodul>more or less :-)
<zimoun>Here, https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00215.html I wrote «My question with duplication is about “long term storage of all the sources”. Not about building twice» and «Now Guix have 2 build farms so let consider it is a strength. :-) The question is how to exploit such strength by sharing the workload and have a better global scaling up (and not 2 independent
<zimoun>scaling).»
<civodul>i think everyone agrees with the goal, we "just" need to actually implement it
<zimoun>And my impression is that Berlin and Bordeaux are 2 independant build farms. Issuing the same issue: space, GC, etc.
<civodul>sysadmin workforce is a bottleneck
<zimoun>yeah, plumber are always missing ;-)
<civodul>so a large part of the work is code, and that part could be handled in a distributed fashion
<civodul>sending patches and all
<civodul>but then there's a part that requires root or physical access, and that's the bottleneck
<zimoun>But Bordeaux is missing space because it keeps too much. AFAIK, there is no coordinated policy.
<zimoun>about physical access, I agree. It reminds me this discussion https://yhetil.org/guix/CAJ3okZ2MOdaihQ2u7cZLjHQOCqmg9xV4zmC0KCe85FVoU8pMYw@mail.gmail.com/ ;-)
<zimoun>Anyway, my plan for 2022 is maybe mirror somewhere in France a part of Berlin, as the Chinese mirror.
<drakonis>more mirrors is a big yes.
<zimoun>Thanks to rekado_ for all the tough “physical“ work, btw!
<rekado_>I’m a little miffed about how quickly we got from ci.guix.gnu.org is in good shape and steadily improving to ‘is in a bad shape :(
<rekado_>I’ll be back in an hour, gotta go
<rekado_>civodul: BTW: news about ci in your mailbox ;)
<zimoun>rekado_: as civodul said with all their wisdom: shit happens. :-)
<zimoun>Personally, I am impressed by all the collective work done!
<zimoun>As nckx said, some beers are highly deserved. ;-)
<nckx>(Or whatever you imbibe. :)
<nckx>I missed all the berlin discussion here.
<nckx>s/berlin/CI/
<zimoun>You missed nothing, only my unjustified French ramblings.
<nckx>😃
<zimoun>I hope that now Bordeaux is up again, we could come with a minimal redundancy; and avoid ‘guix pull’ breakage.
<nckx>zimoun: Oh, what broke?
<nckx>Or do you just mean in general, for the next time Savannah (rather than berlin) goes down?
<nckx>I agree.
<zimoun>missing datefuge, for this one.
<nckx>Ah, that's why someone asked me for datefudge…
<zimoun>for one, me yesterday morning. :-)
<zimoun>I have to go.