IRC channel logs
2021-11-18.log
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>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/ ;-) <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 <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. <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 <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>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 <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