IRC channel logs


back to list of logs

<jra>civodul: I've built the example mpi program as a package, against mpich in order to get the mpich abi so it is compatible with other mpi implementations that support the mpich abi. The target system has Intel MPI. The target system also uses PBSPro. I'm trying to run 8 processes across 4 nodes. It looks like the first process starts, attempts to send its message, and then the whole thing fails. I
<jra>can't tell if the other processes get off the ground.
<PurpleSym>rekado_: guixr, that’s a command on your system, right?
<zimoun>PurpleSym: FYI, guixr is defined there: <> IIRC. :-)
<PurpleSym>Ah, one of roptat’s colleagues then ;)
<zimoun>ah, I did not know roptat’s colleagues were using guixr. I thought it was a tool used by roelj’s colleagues :-)
<PurpleSym>Ah sorry, my bad, Roel obviously :|
<rekado_>PurpleSym: we got rid of the “guixr” wrapper; it’s just called “guix” now.
***Server sets mode: +nt
***zimoun` is now known as zimoun
<zimoun>rekado_: is it a wrapper named ’guix’?
<rekado_>the wrapper does two things: it sets the daemon socket variable so that it talks to the remote guix-daemon, and it either uses the user’s current Guix (if exists) or the default Guix (some older version that’s shared)
<zimoun>rekado_: have you published it somewhere? I am looking for inspiration. :-)
<zimoun>And “my users“ switching from Conda are complaining that it lacks a ‘load-profile’ subcommand.
<rekado_>it looks something like that:
<rekado_>I’m pretty sure this particular implementation of ‘load-profile’ was Roel’s idea.
<zimoun>yes, it is.
<civodul>rekado_: load-profile looks similar to "guix environment -p", which PurpleSym implemented recently, no?
<civodul>(thought the name is arguably clearer)
<PurpleSym>civodul: I was surprised to see `guix environment -p` merged without any discussions about its name ;)
<zimoun>civodul, PurpleSym: yes, it looks like the same. Cool!
<civodul>PurpleSym: well, it didn't occur to me that it could have a different name back then :-)
<civodul>also, "guix environment" is supposed to be renamed to "guix shell" Real Soon Now
<civodul>that was the consensus a while back
<drakonis>hm, that's interesting to hear.
<drakonis>juicy deets that one.
<Noisytoot>civodul, Will guix environment be an alias for guix shell?
<Noisytoot>Why is guix-science using GitHub?
<rekado_>Noisytoot: why not?
<rekado_>civodul: yes, ‘load-profile’ is very old
<drakonis>we've been having a fun discusso on the main guix channel and we're going to take it to the ml
<drakonis>the existence of an offical contrib channel for things that are fsdg compliant but not guix compliant
<rekado_>I’m really not a fan of blessing any channel as official when it is not up to the standards of the project
<drakonis>its mainly for handling some things that are very difficult to actually get to the baseline for the main repo
<rekado_>yes, I know
<rekado_>still doesn’t make me like it
<drakonis>i know
<drakonis>its a difficult proposal
<rekado_>because these things have a tendency to grow and people just push to the dirty channel instead of making the effort of pushing to Guix
<drakonis>hmm, good point
<rekado_>I’ve seen this a dozen times
<drakonis>do bring it to the main channel though
<drakonis>it is certainly a risk
<rekado_>good thing is: none of this is hypothetical.
<rekado_>we *have* third party channels
<rekado_>and their packages *usually* don’t make it to Guix proper
<rekado_>and it’s not an option to ‘monitor’ those channels and regularly move packages
<drakonis>hmm, yes.
<rekado_>even with cooperative channels this is a major task
<rekado_>like with guix-bimsb, for example
<rekado_>it’s our little dumping ground for science stuff and things that are too flimsy for Guix proper. (That’s from before guix-science started.)
<drakonis>i see
<drakonis>was it the one that has a cuda package in it?
<rekado_>and it’s just really annoying to move packages
<drakonis>or am i thinking of another one?
<rekado_>no, guix-bimsb is free software only
<rekado_>(but the same reasoning applies to all channels)
<rekado_>to me this smells a lot like the desire to have an officially blessed wiki
<rekado_>I can relate to the desire, but I think it’s unwise to act on it :)
<Noisytoot>rekado_, GitHub is nonfree
<rekado_>‘nonfree’ does not apply to services
<rekado_>you also don’t need to use any non-free software to fetch or push
<Noisytoot>It requires nonfree JS to register
<rekado_>well, then don’t register
<Noisytoot>So if you don't already have an account, you need to use nonfree software to open a Pull Request/Issue
<rekado_>you are welcome to contribute by sending patches via email
<rekado_>but I doubt that this is about actual obstacles to contribution