IRC channel logs

2015-06-10.log

back to list of logs

<bavier`>hmmm, I was expecting to be able to install the docs for 'git ... --help' with the "doc" output of git
<bavier`>but I guess we have a separate 'git-manpages' package
<bavier`>seems strange to me
<bavier`>especially if we're not even building the docs ourselves.
<bavier`>some references to "/bin/sh" in our ghc package
<bavier`>I'll send a patch later
<bavier`>only just now has it caused a test to fail :P
<civodul>Hello Guix!
<rekado>ardour seems to be calling home to check for a later version. I'll try to remember to patch this "feature" away.
<civodul>ouch, indeed
<civodul>seems to be more and more frequent
<anthk>how do I upgrade all packages on guixsd? guix package -u '*' gives me an error
<rekado_>anthk: what's the error?
<anthk>rekado_, http://pastebin.com/raw.php?i=7u7F9bb1
<rekado_>sneek: later tell davexunit In guix-web's configure.ac I commented "AC_CONFIG_SRCDIR(guix-web)", ran autogen.sh and now configure works fine. Why is this line needed?
<sneek>Will do.
<rekado_>anthk: If you just use "guix package -u" without any regexp it should also just work.
<rekado_>(I suppose you may have intended '.*' instead of '*', which is a valid glob pattern, but not a valid regexp, afaict.)
<anthk>rekado_, thanks
***anthk is now known as anthk_
<ngz>Hello. I'm still struggling a bit on locales. Whenever I try to install a package, I get "substitute: warning: failed to install locale: Invalid argument". However, running, e.g., "guix package -A something" doesn't signal anything.
<ngz>Using strace, I get something suspicious: open("/gnu/store/3s4j92hixp1b1w1nk98hn1a8s1r9sg76-guix-0.8.2.c2ee19e/share/locale/fr_FR.UTF-8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory), which means guix tries to open locales from the store, even though LOCPATH is set and gilbc-locales are installed.
<civodul>ngz: this is normal: it's trying to open message catalogs, and they are not necessarily available
<civodul>message catalogs do not live in $LOCPATH
<ngz>So, is this substitute warning normal?
<civodul>ngz: the "substitute: warning: failed to install locale" message comes from 'guix substitute', which is spawned by guix-daemon
<civodul>so that means that guix-daemon itself must have a valid LOCPATH set
<ngz>Hmm. So I need to set LOCPATH system-wide.
<civodul>or at least for guix-daemon
<ngz>I can modify it system-wide editing /etc/profile but I don't know how to change it for guix-daemon, which doesn't have any $HOME.
<civodul>depends on how you start it
<civodul>if you launched it manually, just run: LOCPATH=... guix-daemon ...
<civodul>if you have a script, add the LOCPATH setting in there
<ngz>I don't know how it is launched. I used a binary install, created users and well...
<ngz>Since guix-daemon runs as root, would it solve the problem to also install glibc-locales as root and set root's LOCPATH to its own personal profile?
<civodul>yes, definitely
<civodul>run "guix package -i glibc-locales" as root
<civodul>and set LOCPATH in ~root/.bash_profile or similar
<ngz>Actually, I cannot: /var/guix/profiles/per-user/root is not owned by me (root) so guix refuse to install glibc-locales.
<ngz>It is owned by 30001:30000
<ngz>It reminds be a problem about file permissions in the tarball.
<civodul>yeah exactly
<civodul>you need to chown it root:root
<ngz>I changed ownership of /var/guix/profiles/per-user/root to root:root (non recursively) and installed glibc-locales. I also put export LOCPATH=$HOME/.guix-profile/lib/locale in .profile. Logging back to test the changes.
<civodul>ok
<ngz>No luck.
<rekado_>davexunit: in "guix environment -l env.scm" ./configure fails with "./configure: line 2353: GUILE_PROGS: command not found"
<davexunit>rekado_: I'll clone guix-web now and try
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, rekado_ says: In guix-web's configure.ac I commented "AC_CONFIG_SRCDIR(guix-web)", ran autogen.sh and now configure works fine. Why is this line needed?
<davexunit>also, I don't know why that line is there.
<davexunit>I just monkey typed
<rekado_>heh
<rekado_>wow, blast+ is really big. It's taking much longer to build than even the IcedTea packages and it fails the install phase on my workstation for lack of disk space.
<davexunit>oh boy
<davexunit>can't connect to gitorious
<rekado_>I cloned it over https.
<davexunit>not working at the moment
<davexunit>off
<davexunit>oof*
<davexunit>I have a copy on a computer that I don't access to right now
<rekado_>BTW: I don't get this GUILE_PROGS error when I run autogen.sh outside the "guix environment" session.
<davexunit>intereseting
<ngz>civodul: I tried with ~root instead of $HOME, but it doesn't change anything. In a terminal, logged as root, LOCPATH is correctly and so is LANG. Yet, I get the substitute warning when running guix package -i ... from a regular user.
<rekado_>blast is terrible.
<rekado_>the bin directory is 4.6GB alone.
<rekado_>removing texlive on my system now to make space for the installation...
<rekado_>I suppose I should split outputs.
<rekado_>argh! The install phase failed *again* for lack of space. I'm starting out with 16GB of space!
<rekado_>(how should binary substitutes for this ever work?)
<rekado_>python-scipy still depends on atlas. I'll try later to build it with openblas instead.
<anthk_>how can I import a CPAN package with "guix import" ?
<rekado_>anthk_: guix import cpan Module::Name
<anthk_>rekado but that gives me an scheme code
<rekado_>right.
<rekado_>importing means: create a package expression for the module.
<anthk_>how do I use that expr?
<rekado_>you'll have to add this expression to gnu/packages/perl.scm, for example.
<rekado_>bind it to an appropriate name, check that all inputs exist, then build it with guix build the-name
<rekado_>"guix import" is not a magic wrapper around other package management systems.
<rekado_>hmm, moving scipy to openblas is more difficult than I thought.
<rekado_>I wonder if we should also build openblas with lapack.
<bavier>rekado: does scipu require lapack functions?
<bavier>beyond those already contained in openblas?
<bavier>s/scipu/scipy/
<mark_weaver>rekado_, davexunit: the GUILE_PROGS error would seem to indicate that guile.m4 could not be found in ACLOCAL_PATH when autogen.sh was run.
<davexunit>mark_weaver: yeah, my thought is that I left guile out of the environment or something
<davexunit>but I can't check right now.
<mark_weaver>okay
<davexunit>thanks
<mark_weaver>np!
<rekado_>bavier: well, we build openblas with "NO_LAPACK=1"
<bavier>rekado: I see
<rekado_>I did this because I thought: hey, we already have "lapack" and we're doing the same for Atlas.
<rekado_>davexunit: guile-2.0 is in the inputs of the package defined in env.scm.
<davexunit>rekado_: autoconf and automake are there, right?
<davexunit>did you 'autoreconf -vif' from within the environment?
<rekado_>they are in the native-inputs.
<rekado_>autogen.sh runs autoreconf -vif, and yes, I did this in the environment.
<davexunit>okay, just making sure.
<bavier>rekado: adding the lapack package to scipy's inputs might be enough; openblas contains only a subset of lapack routines
<davexunit>not sure what's going on then.
<davexunit>sorry for the mess.
<rekado_>env|grep AC shows me this: ACLOCAL_PATH=/home/rwurmus/.guix-profile/share/aclocal
<rekado_>so since I don't have guile installed in my profile GUILE_PROGS would fail, I think.
<rekado_>shouldn't this variable be set by "guix environment"?
<davexunit>yes
<davexunit>is your bashrc clobbering it?
<rekado_>(I'm always assuming "guix environment" performs magic, so I never looked behind the curtain.)
<rekado_>davexunit: very good point!
<davexunit>rekado_: use the --search-paths flag for 'guix environment'
<davexunit>does it output a ACLOCAL_PATH?
<rekado_>Argh! .bashrc is overwriting the env variable! That's an old file; I wonder how it got there.
<rekado_>moved everything to .profile a while ago.
<rekado_>sorry!
<davexunit>np
<davexunit>glad we found the culprit
<rekado_>make fails now, but I'll look at this tomorrow again.
<rekado_>enough for today.
*rekado_ waves
<davexunit>we'll get there!
<efraim>i didn't know about `env`, found this there: PANTS=ON
<ijp>wonderful
<davexunit>haha
<davexunit>what program sets that
<efraim>no idea, probably enlightenment
<efraim> https://unix.stackexchange.com/questions/62566/what-does-the-enlightenment-desktop-e17-environment-variable-pants-on-do
<mark_weaver>civodul: in core-updates, glibc-cross-mips64el-linux-gnu fails to build: http://hydra.gnu.org/build/492460/nixlog/1/tail-reload
<mark_weaver>mips64el-linux-gnu-ld: skipping incompatible /gnu/store/yv1czi6flx51wrx7i6iq2iv19411kf2m-gcc-cross-sans-libc-mips64el-linux-gnu-4.9.2/lib/gcc/mips64el-linux-gnu/4.9.2/libgcc.a when searching for -lgcc
<mark_weaver>mips64el-linux-gnu-ld: cannot find -lgcc
<mark_weaver>any idea what that's about?
<mark_weaver> https://www.youtube.com/watch?v=oIrXuv-JjeE
<mark_weaver>^^ Richard Stallman in 'Hackers - Wizards of the Electronic Age'
<mark_weaver>a very young RMS, around the time he started GNU.
<davexunit>lol @ the very ignorant guy juxtaposed next to rms
<mark_weaver>I'd like to know who that other guy is, the one who compares his software to works of art, and for someone else to modify it would be analogous to changing a color on a painting.
<davexunit>yeah I don't recognize him, but I've encountered that attitude before.
<davexunit>people might make changes I don't like, so they shouldn't be allowed to make changes at all!
<davexunit>and of course he confuses practical works with purely artistic ones.
<mark_weaver>right
<mark_weaver>it's been a while since I've heard that perspective so brazenly expressed in connection with software (with phrases like "because then it won't be mine" and "that wrecks the whole painting, that changes everything that I did, and that to me is one of the greatest insults"), but I suppose maybe it's because I don't like to spend time around such people.
<mark_weaver>although I suspect that today, many people who feel that way would say it in a way that sounds less selfish.
<mark_weaver>I appreciate his honesty, though.
<mark_weaver>civodul: I think we should wait for the next core-updates cycle to make the changes I talked about: requiring NEON on armhf, and passing --build in gnu-build-system. I don't really have the spare energy to make those changes this cycle.
<mark_weaver>civodul: in core-updates, on armhf, when I try to run "guix package -u" I get this: ERROR: unsupported manifest format #<procedure %manifest-procedure (entries)>
<mark_weaver>to be more precise, that's on commit f8badf1
<civodul>mark_weaver: re ARM changes, ok
<civodul>mark_weaver: the "unsupported manifest format" means that the Guix being used is older than the Guix that produced ~/.guix-profile/manifest
<civodul>the broken error message means it's older than 88aab8e3
<civodul>(May 4th)
<mark_weaver>civodul: that happened with 'guix' commit f8badf1 from core-updates
<mark_weaver>hmm, it seems that 88aab8e3 is not in core-updates
<civodul>yeah perhaps we need to merge master in core-updates
<mark_weaver>well, there's no rush on that. I have some more security updates to apply to master, so I'll wait until after those to merge.
<mark_weaver>'guix package -u' is just my lame way of testing many builds on armhf for now.
<davexunit>mark_weaver: 'guix environment --ad-hoc' will do it without creating a new profile generation. :)
<mark_weaver>davexunit: what argument(s) would I pass to that?
<mark_weaver>if I need to pass an explicit set of packages, I could just as well use 'guix build'
<davexunit>mark_weaver: 'guix build' can build multiple packages? heh, never knew!
<davexunit>nvm then!
<mark_weaver>davexunit: I don't think it can, but I can write: for pkg in ...; do guix build -K $pkg; done
<davexunit>ah, okay
<davexunit>well, you don't need a for loop to do it with guix environment
<davexunit>but I guess it's not much more convenient
<mark_weaver>the advantage of the loop is that if a build fails, it keeps trying to build other things.
<mark_weaver>although it's all pretty ghetto compared to hydra
<davexunit>ah okay.
<davexunit>makes sense.
*davexunit would like to be able to easily run his own CI server
<mark_weaver>hydra is basically packaged, and is just waiting for a license change in some perl library that's only available under the artistic license.
<davexunit>oh great
<davexunit>that's exciting
<davexunit>I have some custom packages that I'd like to have builds for.
<davexunit>though guix-daemon still doesn't support multiple substitute servers
<mark_weaver>davexunit: I think that's probably a limitation in our substituter build hook, not in guix-daemon itself.
<mark_weaver>guix-daemon just uses our hook, which is written in scheme.
<davexunit>okay, yeah.
<mark_weaver>guix/scripts/substitute.scm
<davexunit>once that limitation is removed it will enable more cool stuff
<davexunit>'guix publish' will become actually useful
<mark_weaver>indeed!
<bavier>mark_weaver: I think the perl module packager needs another ping...
<bavier>I've pinged 3 or 4 times to have the issues resolved, once the final copyright holder responded positively
***exio4 is now known as y
<paroneayea>mark_weaver: oh cool
<paroneayea>mark_weaver: is that likely to happen soon re: the license change?
<mark_weaver>paroneayea: good question! I have no way to know. iirc, the last I checked it was waiting on some copyright holder to agree to the change.
<bavier>mark_weaver, paroneayea: https://github.com/rurban/Set-Object/pull/4
<bavier>all holder have agreed, but the pull request needs to be updated and merged.
<mark_weaver>maybe poking them would be useful?
<bavier>I don't have a github account, so I can't ask for an update there, but I can email again
<bavier>how to nicely poke a 4th time? ;)
<mark_weaver>hehe
<mark_weaver>well, it's been a long time since the last poke, no?
<bavier>a month, yes
<bavier>it'd be nice to get those last few hydra patches in
<mark_weaver>I suppose in the worst case we could make our own git repo with the needed merge, but it would be great to avoid that.
<mark_weaver>well, the legal issues are not clear to me.
<ArneBab>mark_weaver, civodul: gentoo is actually doing one file per version, roughly 2-4 times more files than what guix would have with one file per program.
<ArneBab>But I guess it would increase the ratio of use-module lines vs. code lines.
<ArneBab>(=actual package definition)
<mark_weaver>we could optimize those imports easily enough