IRC channel logs

<zimoun>Yeah, the cache would be helpful. I am still missing if it could allow to run in a Guix-less environment.

<drakonis> https://spritely.institute/static/papers/scheme-primer.html

<zimoun>civodul: Hi, https://hpc.guix.info/channels seems down.

<rekado_>just finished builing python-pytorch 1.12.0

<rekado_>no idea how to test it, though

<civodul>a paper (fr) on using NixOS for distributed testbeds: https://2022.compas-conference.fr/programme/papiers/ComPAS2022_paper_9-2.pdf

<civodul>zimoun: https://hpc.guix.info/channels/ works for me!

<zimoun>so it means it’s on my side… hum?!

<civodul>what do you mean by "down" anyway?

<civodul>zimoun: oh you're the one talking at Café Guix today, right?

<zimoun>yeap

<zimoun>I cannot access to the webpage

<civodul>could you be more specific? :-)

<civodul>does it just hang without fetching anything in a timely fashion?

<civodul>same for all of hpc.guix.info?

<rekado_>(works for me, too)

<zimoun>yes, it hangs forever. Whatever, it is probably my webbrowser. :-)

<rekado_>are you on a restricted network?

<zimoun>no, I think it is from my webbrowser. I will restart it soon.

<zimoun>rekado_: how long is Xapian indexing for Mumi?

<zimoun>is Mumi indexing the whole and is it doing incremental update index?

<rekado_>both

<rekado_>since I changed the layout of the database to make space for message ids I had to throw away the existing xapian database

<rekado_>first pass is a full indexing; then the mumi worker does incremental updates

<zimoun>do you remember how long is this first pass?

<rekado_>quite a long time

<rekado_>more than 20 minutes

<zimoun>for all messages of Debbugs?

<civodul>rekado_: congrats on the pytorch update + torchvision!

<zimoun>Since it is confusing on #guix, I ask here: from REPL, how ,use is from (use-modules)? Maybe civodul knows. ;-)

<civodul>",use" is the same as 'use-modules'

<zimoun>Hum, ,use(custom) works for not (use-modules (custom)). Bah I probably have something wrong.

<zimoun>civodul: what is this error «(exception %exception (non-self-quoting 140737321012256 "#<&message message: \"unsupported manifest format\">"))»?

<rekado_>that error is due to the manifest version upgrade

<rekado_>the new manifest format allows for references to other parts of the manifest

<rekado_>when you get that error it means that you’re using an older Guix on a newer profile

<rekado_>I got an error just like that when using the time machine, so maybe something’s not right there.

<zimoun>Yeah, I removed ~/.cache/guix/inferiors and then boum!

<zimoun>something is unexpected, indeed.

<zimoun>I am running 06493e7 (from today) and I try to go to 791069737 (from Feb)

<zimoun>That’s really annoying! Because ’guix time-machine’ seems broken. civodul, any clue?

*rekado_ check

<rekado_>s

<rekado_>trying “./pre-inst-env guix time-machine --commit=791069737 -- describe” now

<rekado_>I want to see *where exactly* it fails

<rekado_>my uneducated guess is that the old Guix (the one launched by the time machine) is forced to access a new profile.

<rekado_>build of /gnu/store/kw6c8qmwsmk38hlfizg6kq30j4lwzpgb-guix-package-cache.drv failed

<rekado_>not sure yet, but that seems to be part of the profile that holds the old Guix

<rekado_>the profile manifest is in fact a version 4 manifest

<rekado_>generating the package cache with the old Guix modules cannot work on a newer manifest that’s not supported by the old Guix modules

<rekado_>this suggests that previous manifest version bumps were also deadly to the time machine

<rekado_>(but perhaps they predate the introduction of the time machine)

<rekado_>I’m a little confused about this, because I don’t know what happens exactly when. But the fix would be to use the older Guix modules to build the profile (if that’s possible).

<rekado_>gotta go for a bit, but I’ll investigate more in a few hours.

<zimoun>rekado_: thanks

<rekado_>the problem was introduced in 4ff12d1de7cd617b791996ee7ca1240660b4c20e

<zimoun>I thought that the inferiors were using the old Guix modules to build the profile

<rekado_>so if you’re using a guix before that the time machine will work

<rekado_>(in case you need that for presentations)

<rekado_>inside the inferior the old Guix is used, but it’s used on a profile that was built with the new stuff (before the inferior came into play)

<rekado_>a bit surprising, but I’ll figure this out when my daughter is asleep

<zimoun>hehe! Good luck :-)

*zimoun checks 4ff12d1de7cd617b791996ee7ca1240660b4c20e

<rekado_>perhaps we can fix this in channel-instances->manifest

<rekado_>makes it more complicated, but it might work

<rekado_>- single out the channel matching GUIX-CHANNEL? first

<rekado_>- build that guix

<rekado_>- then build the manifest inside an inferior using that very guix

<rekado_>that should fix it

<rekado_>or maybe in channel-instance-derivations, where we already single out the core channel

<rekado_>(I’m a little rusty when it comes to the monadic code…)

<rekado_>channel-instance-derivations returns a monadic value, not an actual list of derivations

<rekado_>same with channel-instances->manifest

<rekado_>I’m feeling very stupid. Can’t use my brain to mentally connect the store monad stuff with gexps.

<rekado_>I’m thinking that we could use gexp->derivation-in-inferior, because it already exists.

<zimoun>rekado_: what does it mean (_deps ...) https://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm?id=4ff12d1de7cd617b791996ee7ca1240660b4c20e#n494

<zimoun>why is it not just (deps ...) ?

<zimoun>Well, your analysis in the bug report appears to me correct; but it looks like a spaghetti plate… so I am going to eat. :-) I will try to understand later.

<rekado_>(_deps ...) is a match clause that matches several elements and binds them to the variable “_deps”

<rekado_>“deps” (an unrelated value) is bound earlier, on line 481

<rekado_>the underscore conventionally means “don’t care”

<rekado_>so really we’re just throwing that value away

<zimoun>Ok, I was thinking that it had a special meaning. How is it possible that the compiler does not fail? Anyway, that’s not the root of the issue but a typo nonetheless. :-)

<rekado_>it’s not a type

<rekado_>typo

<rekado_>*that* was a typo

<rekado_>“deps” is bound higher up

<rekado_>we’re using that

<rekado_>at the line you linked to we don’t care about what’s bound to _deps

<rekado_>I’m testing a workaround for that manifest problem

<zimoun>Ah right! I have been confused because the previous version is almost identical. Thanks for the explanation.

<rekado_>profile-derivation is another problem; it’s not enough to run its builder through gexp->derivation-in-inferior.

<rekado_>the builder itself includes a gexp of the manifest; and that already includes the current manifest format version

<rekado_>not sure how to get around this

IRC channel logs

2022-07-07.log