IRC channel logs


back to list of logs

<zimoun>Yeah, the cache would be helpful. I am still missing if it could allow to run in a Guix-less environment.
<zimoun>civodul: Hi, seems down.
<rekado_>just finished builing python-pytorch 1.12.0
<rekado_>no idea how to test it, though
<civodul>hi there!
<civodul>a paper (fr) on using NixOS for distributed testbeds:
<civodul>zimoun: 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>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
<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_>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_>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 ...)
<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_>*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