IRC channel logs

<rekado> https://guix.bordeaux.inria.fr/ says 502 Bad Gateway

<civodul>bah, thanks for the heads-up!

<civodul>FD leak it seems

<rekado>thanks for restarting it

<rekado> https://guix.bordeaux.inria.fr/search?query=python-3.8 shows that we’ve got 6 test failures in Python 3.8

<civodul>uh, crap

<rekado>today I continue debugging this weird irreproducible behavior in npm

<rekado>people at the MDC can’t install rstudio-server because of this

<rekado>npm at the MDC doesn’t install all JavaScript files, but it works on my laptop and on PurpleSym’s machines.

<rekado>it’s quite an astonishing difference in behavior

<civodul>oh, weird

<civodul>i've seen npm mentioned on IRC lately but i haven't followed

<rekado>I discussed this a little with jlicht on IRC, but nothing came of it yet.

<rekado>I’m not familiar with the tools of the JavaScript world, so I’ve been having a hard time tracing things.

<rekado>the difference is quite big and must be down to file system interactions. Here’s a diff of files installed on my laptop vs the cluster: the

<rekado>oops: https://elephly.net/paste/1687517237.diff.html

<civodul>file system traversal ordering issue?

<civodul>most likely what we see in: guix challenge node-sqlite3 --diff=diffoscope

<PurpleSym>rekado: Are the missing files consistently the same ones or does that change?

<rekado>I don’t have enough systems to figure this out. But mere rebuilds seem to always miss the same files.

<rekado>I want to see if I can reduce the problem to just one component of npm; arborist seems to be responsible for traversing and building file trees, so I’ll focus on that next

<rekado>slightly off topic: on the topic of RHEL making it hard to get source code, I think the solution by the Rocky folks is neat: just use the GPL! Legitimately become a user of the binaries and then obtain the sources. https://rockylinux.org/news/keeping-open-source-open/

<civodul>rekado: fun

<civodul>i wonder how RH will respond

<civodul>maybe they'll just sink

<rekado>I think if it becomes a problem for them they’ll require a service contract to obtain these images.

<rekado>I don’t think Red Hat will disappear, because they are one of the few distros that are in practise “certified”.

<rekado>it doesn’t mean much to anyone except for those who look for a certification for some reason, to tick a box on a requirements sheet.

<civodul>heh

<zimoun>hi!

<civodul>hey zimoun!

<zimoun>almost the week-end \o/ :-)

<zimoun>civodul: if I build “guix build /gnu/store/cnrdap3kyw9bpgz1ckxsz7a7dl6z6cr2-guile-charting-0.2.0.tar.gz.drv” then it displays « warning: rewriting hashes in `/gnu/store/y8lixv7x5wqqq4qlzda4yhprcxbyc3pw-guile-charting-0.2.0.tar.gz'; cross fingers » What does it mean?

<rekado>would you object if I worked on a patch to the daemon to optionally disable the deletion of unreachable links on GC operations?

<civodul>that you passed --check :-)

<civodul>rekado: not if you have a convincing cover letter :-)

<rekado>great :)

<civodul>at first sight i don't see why one would want to keep them around

<rekado>the fact that any gc operation deletes unreachable locations (e.g. user profiles whose link origin is on a file system that is not mounted on the server where guix-daemon runs) is why I haven’t run “guix gc” in ages at the MDC and “disabled” it in the Guix wrapper script.

<rekado>home directories are not mounted on the server where guix-daemon runs, and even if they were the daemon would not be able to read the home directories.

<rekado>so it always decides that user profiles may be deleted.

<zimoun>civodul: yes but it downloads first /gnu/store/18nccx70bbjwyx9a03vncay8wzjg55j6-guile-charting-0.2.0.tar.gz then warns and stores /gnu/store/y8lixv7x5wqqq4qlzda4yhprcxbyc3pw-guile-charting-0.2.0.tar.gz

<zimoun>Well, I have the same questions: « Starting download of /gnu/store/3dq55rw99wdc4g4wblz7xikc8a2jy7a3-hello-2.12.1.tar.gz » and then returns /gnu/store/3dq55rw99wdc4g4wblz7xikc8a2jy7a3-hello-2.12.1.tar.gz

<zimoun>But if I use --check: « Starting download of /gnu/store/1s6xba6nafkxb242kafkg3x10jkdn2n9-hello-2.12.1.tar.gz »

<zimoun>Why is it different?

<zimoun>Both are using the same derivation /gnu/store/3hxraqxb0zklq065zjrxcs199ynmvicy-hello-2.12.1.tar.gz.drv

<civodul>zimoun: when using --check, the store item is already in store; so it has to produce it under a different name

<zimoun>Hum, why ’-check’ is it not appended in that case? Or what is the sugar that is added to transform 3dq55rw99wdc4g4wblz7xikc8a2jy7a3 to 1s6xba6nafkxb242kafkg3x10jkdn2n9?

<civodul>good question, i forgot the details

<civodul>we should check nix/libstore/build.cc

<zimoun>hehe! I was looking into it (identified when grepping with the “cross fingers” ;-)) But then I was hum?! maybe civodul will have the answer directly at hand. :-)

<zimoun>Thanks. So I will give a look. :-)

<rekado>I patched almost all instances of readdir in npm to sort the collection it returns, but sadly that didn’t make any difference in the number of files installed.

<rekado>readdir in npm doesn’t return a collection right away; it can be used with a callback that traverses the array of files, so it’s a little tricky to sort the output

IRC channel logs

2023-06-30.log