IRC channel logs


back to list of logs

<zimoun`>rekado_: another reason for swithcing
<zimoun`>*switching Bioconductor from tarball to git-reference
<jgart>is this a patch I should apply in packaging `git-interactive-rebase-tool`?
<jgart>It minimizes the size of the resulting binary.
<zimoun>civodul: oh neat! I have seen that a paper in 1024 is coming for the next issue. Hope to read it soon. ;-) (I was thinking to suggest you to write one ;-))
<civodul>heh, i actually wrote it in July
<civodul>not sure what happened to them in the interim
<zimoun>I think 1024 is published twice a year, an issue on Apr. and another one on Nov. Therefore, send it in July means a publication next Nov. … and we are on Nov. \o/ ;-)
<civodul>ok, no wonder then
<zimoun>rekado_: “guix install java-picard“ does not come with java; as it is with r- and r. The issue is that java is not the name of a package. It seems confusing, at least for some users here, and WDYT to bind icedtea to java? Similarly as gcc and gcc-toolchain?
<zimoun>second, ‘guix install java-picard icedtea’ then ’java -jar picard.jar’ is not working as expecting. And just ’picard’ is not there neither.
<rekado_>‘java’ should not be an alias for icedtea. Instead use one of the later openjdk packages.
<rekado_>picard doesn’t install an executable
<rekado_>the official picard documentation also says to run it with java -jar picard.jar
<rekado_>what is not working as expected here?
<zimoun>java-picard uses ant-build-system which uses icedtea. Therefore, I am confused if instead I should use openjdk.
<rekado_>I think a more recent JRE will still be able to run old jars.
*zimoun is trying with openjdk
<zimoun>rekado_: “guix shell java-picard openjdk -- java -jar picard.jar” returns “Error: Unable to access jarfile picard.jar”. It is what I mean by «not working as expected».
<zimoun>civodul: “guix shell jupyter -- jupyter notebook” is not working out-of-the-box. PermissionError: [Errno 13] Permission denied: '/gnu/store/…-profile/etc/jupyter:'. Is it expected?
<rekado_>well, you need the actual location of the thing
<rekado_>zimoun: we could also just install a bin/picard wrapper and call it a day
<zimoun>rekado_: is it the same for any Java stuff?
<rekado_>just for those packages that don’t install an executable by themselves
<rekado_>see also fastqc
<zimoun>so yeah, a wrapper could be nice
<rekado_>it has a somewhat poorly implemented wrapper script, and we just fix it and install it to bin.
<zimoun>yeah, maybe it is enough.
<civodul>zimoun: re jupyter, i think that's a regression
<zimoun>civodul: arf, these days, I am really unlucky with Guix packages
<civodul>everyone is, that's why we're having this spring! :-)
<civodul>(spring would be nice but we'll have to wait)
<zimoun>civodul: Same error with (release v1.3) “guix time-machine --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff -- environment --ad-hoc jupyter -- jupyter notebook”
<PurpleSym>Does it work with the jupyter-notebook package? I’m not sure whether the jupyter package sets a proper environment.
<zimoun>PurpleSym: jupyter-notebook is not a package. Do you mean python-notebook? And idem
<zimoun>but it works with --pure. Sigh!
<civodul>zimoun: on master, "guix shell -CNP jupyter -- jupyter notebook" works like a charm
<zimoun>civodul, yeah. Me too. But not without -CNP. And I miss why. The doctor “guix shell –check” says nothing. And ’env’ neither. Another mystery of life. ;-)
<civodul>zimoun: works for me even without -CNP (but then it launches lynx or something, which is annoying)
<zimoun>indeed, it works with “env -i $(which bash) --login --noprofile --norc”
<zimoun>I found the culprit! The package ’python-ipython’ sets JUPYTER_CONFIG_DIR for a mysterious reason. As I said, mystery of life. ;-)
<PurpleSym>Where does it do that? Only python-jupyter-core should do that.
<zimoun>PurpleSym: Maybe my setup is wrong. «guix shell -C python-ipython coreutils grep bash -- bash -c 'env | grep JUPYTER'»
<PurpleSym>Ah, okay, but python-notebook should set the same envvar, because both at some point propagated python-jupyter-core, no?
<zimoun>PurpleSym: in fact it seems it comes from python-nbformats
<zimoun>and python-nbformat depends on python-jupyter-core
<zimoun>civodul, for instance, this propagation leads to: if an user have fdroidserver installed in their default profile, then “guix shell jupyter” will not work. And the message of “guix shell –check” does not really warn about that – I mean reading the message I think it comes from PATH and it appears to me almost impossible to think about such issue.
<civodul>zimoun: what does --check print for you?
<zimoun>guix shell: warning: variable 'PATH' is clobbered
<zimoun>hint: One or more environment variables have a different value …
<zimoun>Since I am naive, I think it is because PATH.
<zimoun>And if I remove the warning, then:
<zimoun>guix shell: All is good! The shell gets correct environment variables.
<zimoun>but “guix shell jupyter --no-grafts -- jupyter notebook” fails
<zimoun>Well, two issues 1. is propagation and it has to be checked package per package. And 2. is improve --check if possible. IMHO.
<zimoun>No, it is my setup. And I do not know what is wrong. I am the same on several machines. And for only one, it does not work. Time to change my glasses and do something else…
<civodul>hmm i guess "guix shell jupyter --check" would complain
<civodul>in other news, Julia fails tests on core-updates-frozen (numerical tests all at test/math.jl:296)
<zimoun>civodul, about julia hum? weird! With 1568436, julia builds /gnu/store/5s6b2j1i3f3jwzdixa40mlmn2xdcazxy-julia-1.6.3
<zimoun>about my issue with jupyter, I guess the bug is between the chair and the keyboard. ;-)
<civodul>ah, see? :-)
<civodul>for Julia i don't know what to conclude
<zimoun>about Julia, where does it fail?
<civodul>numerical tests reported at location test/math.jl:296
<civodul>i didn't investigate
<zimoun>I mean, does it fail on Berlin or elsewhere?
<civodul>i spawned a local build this afternoon, it took ages and eventually failed
<zimoun>I see. It tooks also ages this morning and failed. After the move of llvm and co, I tried again and the build passes. I do not know if it is related.
<civodul>the move to different modules didn't change the derivations i think