IRC channel logs

2015-02-20.log

back to list of logs

<mark_weaver>iyzsong: what do I need to do to display your name properly in Guix?
<mark_weaver>in icecat, for example, when looking at the commit logs in http://git.savannah.gnu.org/cgit/guix.git/log?h=core-updates , I see only boxes with hex codes
<mark_weaver>(for your name)
<sir123>Hey guys, I've installed gcc, binutils and glibc to try and compile a program. But it keeps rejecting a hello world program, the linker complaining no crt1 and crti.so files. Did I mess up the install?
<mark_weaver>sir123: guix -r gcc binutils glibc -i gcc-toolchain
<mark_weaver>basically, you need something called 'ld-wrapper' which will arrange for the built programs to find things in the nonstandard locations in guix.
<mark_weaver>the 'gcc-toolchain' package includes gcc, binutils, glibc, and ld-wrapper.
<mark_weaver>and also arranges for ld-wrapper to take precedence over the ld in the binutils package.
<sir123>Ok. Is the default ld not set up for the guix design?
<sir123>No good. Same error.
<mark_weaver>hmm. how did you compile the program?
<mark_weaver>what exact commands?
<sir123>gcc entrance.cpp -o FakeCDM
<sir123>Trying to build makefiles from established programs have same problem
<mark_weaver>did you delete anything from /gnu/store ?
<sir123>Nope
<sir123>I've learned :)
<mark_weaver>can you install 'strace' and run 'strace FakeCDM' ?
<sir123>That's the thing. Strace doesn't work either.
<mark_weaver>sorry, did the 'gcc' command above fail, or does it succeed but running the program fails?
<sir123>Ok, error on my part.
<sir123>Sorry, when i compile it it fails
<sir123>Well, links
<mark_weaver>can you add -v to the 'gcc' command line and see details on what it's trying to do?
<sir123>Yup. I'll hop into my emacs erc to lisp paste it. Wait a mo
<sir123>Ok, I'm here.
<mark_weaver>hi
<sir123>I'll just lisp paste the output, right?
<mark_weaver>yes
<mark_weaver>sir123: also, can you type "ls -l $(which gcc)" and tell me which package name the symbolic link is pointing to?
<mark_weaver>the package name is the bit after the long base64 hash string
<sir123>ok
<sir123>the pastelisp is: http://paste.lisp.org/+34J1.
<sir123>and the ls -l:
<sir123>lrwxrwxrwx 5 root guixbuild 71 Jan 1 1970 /home/rhys/.guix-profile/bin/gcc -> /gnu/store/5wniqwf1l24dvrf9xq0l8lc71fqgms6g-gcc-toolchain-4.9.2/bin/gcc
<mark_weaver>can you paste entrance.cpp ?
<sir123>sure.
<mark_weaver>sir123: I think I know the problem. you need to set the LIBRARY_PATH environment variable
<sir123>sorry, system messed up
<mark_weaver>sir123: I think I know the problem. you need to set the LIBRARY_PATH environment variable, and also the CPATH variable.
<mark_weaver>let me see if this is documented anywhere.
<mark_weaver>sir123: when you installed 'gcc' in your profile, did it not tell you that those needed to be set, along with recommendations of what they should be set to?
<mark_weaver>and I suspect it should have reminded you when you installed 'gcc-toolchain' as well.
<sir123>Yes, it did.
<sir123>that teaches me to ignore warnings
<sir123>works fine now
<mark_weaver>sir123: you can get the list of missing environment variables again with "guix package --search-paths"
<mark_weaver>I recommend putting those in your .bash_profile
<sir123>Ok. Thanks for the help!
<mark_weaver>np, happy hacking!
<rekado_>Julia's ccall facility looks up so names in the output of ldconfig. This is not functional on Guix, so dynamic loading of system libraries fails. Is there a precedent on how to deal with situations like this?
<rekado_>the so names are fixed at build time, so I might be able to hardcode them in the ccall function
<rekado_>is there another way we can obtain so names at runtime other than using ldconfig -p?
<rekado_>for context see the last comments here: https://github.com/JuliaLang/julia/issues/10246
<taylanub>rekado_: hard coding should be fine since that's how Guix does things anyway, no?
<taylanub>i.e. fixing what exact shared object a program will open, to fulfill the purely functional aspect
<rekado_>taylanub: I'm a little reluctant to go down this route, because I'd have to substantially rewrite that function.
<rekado_>I don't understand how nix solved this.
<rekado_>they do declare certain libs as inputs but they don't seem to modify any of this lib loading at all.
<rekado_>it looks like they are simply downloading tarballs of the required libs and let the Julia build use those instead of the bundled libs.
<rekado_>yet, they also pass USE_SYSTEM_*=1 for these libraries --- this is confusing and it shouldn't work, according to what I've seen in my build attempts.
<rekado_>I must say that Guix package definitions are *much* more readable than Nix packages. Scheme is beautiful and the absence of string interpolation is a blessing.
<rekado_>Is it okay for me to push this fix? ---> http://lists.gnu.org/archive/html/guix-devel/2015-02/msg00506.html
<rekado_>I will have to prepare a very similar fix for scipy as well.
<rekado_>these packages fail to build because of locale issues.
<grantix>Yeah, Raco doesn't work in Racket. Mentioned before, but thought it was just my install -- but now it just throws a pile of errors.
<rekado_>On two different machines I cannot use guix pull successfully
<rekado_>I get this error:
<rekado_>can anyone else here confirm this?
<davexunit>rekado_: I *just* got this same error
<davexunit>not sure what's going on
<rekado_>meh, just noticed that one of the packages I just finished does not permit commercial redistribution, making it non-free. I contacted the authors to ask if they would consider relicensing.
<davexunit>I had when I find stuff like that.
<davexunit>I started play this really cool visual novel written in RenPy, but it's CC-BY-NC licensed so I can't package it. :(
<rekado_>for the institute I may have to add a local bioinformatics-nonfree module for things like this :-/
<rekado_>I do hope they reconsider, though.
<rekado_>in many packages licensing is very sloppy.
<rekado_>packaged another application that contains GPL-licensed code but is released as "BSD/MIT licensed"; contacted the author to ask for clarification.
<mark_weaver>rekado_, davexunit: can you try running 'guix pull' again with the --verbose option?
<rekado_>mark_weaver: ok
<mark_weaver>maybe there will be some hint about the problem in the output
*mark_weaver goes afk for a while
<rekado_>mark_weaver: http://paste.lisp.org/display/145840
<mark_weaver>rekado_: hmm, so one of the files is failing to compile
<mark_weaver>what version of guile are you using on the host system ?
<mark_weaver>actually, nevermind, that's irrelevant
<mark_weaver>I guess it's guix/scripts/offload.scm that's failing to compile.
<mark_weaver>but the compiler seems to be dying without producing any output
<mark_weaver>rekado_, davexunit: okay, I just ran 'guix pull' (for the very first time ever) with --url set to my locally produced tarball of the git checkout, and I see the same problem here.
<davexunit>well at least it's not just us.
<mark_weaver>it failed for me on a different file though.
<davexunit>I haven't had time to debug today
<mark_weaver>for me it failed on guix/scripts/import/gnu.scm
<mark_weaver>I'm trying it again in case it is non-deterministic
<mark_weaver>so I can do a git bisect here
<mark_weaver>it failed in the same place, so it is at least somewhat deterministic, but might depend on the order the files are place in the tarball.
<mark_weaver>*placed
<mark_weaver>actually we sort the file list, so no.
<kurohin>hi, i am trying to follow the guide on installing guix but i have a problem with running the guix system init ...... ... command, It tells me "source expression failed to match any pattern", am I missing some modules that i need to use beside (gnu)?
<davexunit>kurohin: hello! if you could paste your OS config on http://paste.lisp.org that would be helpful.
<mark_weaver>kurohin: yeah, sounds like a syntax problem in your OS config
<kurohin>ok, going to take second look before pasting it to paste.lisp.org.
<grantix>Ankle isn't broken and I probably won't need surgery, yah! I have some freetime to work on Guix likely this weekend now though. :^)
*grantix investigates into asdf is something Guix should have available.
<grantix>Mypaint is also something I plan to get going in the relatively soon future, long-term is Krita -- maybe.
<a_e>grantix: Good luck inside bad luck!
<mark_weaver>kurohin: I would suggest just pasting your config. we can probably spot the problem relatively quickly.
<grantix>Also, I don't know if lsh-service's recipe is an indication ... but figuring out how to get openssh's daemon going seems to be a monster.
<kurohin>trying to paste it, but i cant get the copy paste working from my virtual machine so am installing links to be able to paste it
<mark_weaver>bavier`, rekado_, davexunit: my git bisect run indicates that the recent 'guix pull' breakage started with this commit: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=66392e475d4fa89760ec64d62c5d0c203e853866
<mark_weaver>my first guess is that it introduced a new module dependency cycle. we need better ways to detect and deal with those.
<mark_weaver>anyway, I'll have to pick this up later.
<davexunit>mark_weaver: thanks for identifying this issue.
<davexunit>we seem to run into module cycles a lot. :(
<mark_weaver>on second thought, maybe not a cycle issue, but rather the definition of %corelist which tries to talk to the daemon when the module is loaded.
<mark_weaver>yeah, I think that's the problem.
<mark_weaver>I would suggest changing %corelist into a promise, by wrapping its computation with 'delay' and its uses with 'force'.
<mark_weaver>although, where is 'store' coming from?
<mark_weaver>well, I'll have to pick this up later. gotta run!
<davexunit>later!
<Pastaf>Any ETA on desktops besides Xfce? that's essentially the only thing holding me back from using guix
<grantix>Pastaf: What do you "need"/want?
<grantix>GNOME & KDE is likely sometime away.
<davexunit>Pastaf: no ETA. if people want a particular desktop, they should get their hands dirty and help package it. :)
<Xiaoman>Is GuixSD DE Xfce? It looks really weird
<grantix>Xiaoman: The default session is Windowmaker.
<Pastaf>well, Xfce is basically the only desktop that I just plain don't like
<davexunit>Xiaoman: GuixSD doesn't really have defaults like that.
<grantix>There s no "GuixSD".
<davexunit>you configure the system as you would like.
<grantix>Desktop Environment*
<davexunit>the slim-service defaults to a windowmaker session right now because it was the easiest thing to package.
<Pastaf>I'd be happy with just about any other one
<Xiaoman>Oh, Windowmaker, ok - gonna look into getting Xfce running
<taylanub>Pastaf: are you sure it's not WindowMaker whose looks you dislike? :)
<davexunit>GNOME has the extra challenge of depending on systemd that needs to be worked around.
<Xiaoman>What do you mean that there's no "GuixSD", grantix ?
<grantix>I would suspect that eventually we might provide and distribute a GNOME image eventually, due to a number of factors -- that is something I see easiy arguable.
<taylanub>Xiaoman: I believe "there's no 'GuixSD DE'" was meant
<grantix>taylanub: Yeah.
<grantix>Sorry, on painkillers.
<Xiaoman>Oh, ok
<taylanub>i.e. Guix will just package all DEs it gets to package, and choosing one will be a matter of "guix package -i <de-of-choice>"
<Pastaf>well, I don't like the double bars, with the launcher seperate from the running applications
<davexunit>GuixSD systems are defined by a declarative configuration file, and it's up to you to configure the system you would like.
<davexunit>the base packages and services are *very* minimal.
<taylanub>somewhat like Arch I guess
<Pastaf>arch isn't free though </3
<grantix>Pastaf: Parabola. :^P
<grantix>Arch also doesn't have a relatively universal OS EDSL.
<Xiaoman>Yeah, I have it running now already - just trying to get iwlwifi to load the firmware for my centrino advanced 6205, which fails, before I start messing with other programs
<davexunit>taylanub: yeah, Arch doesn't have a canoncial DE. Neither do we.
<grantix>Nor does really any distro sans NixOS and even then, you mess with too much Bash to keep me happy.
<davexunit>you build up GuixSD to be what you would like.
<Xiaoman>anyone here that has any pointers on getting iwlwifi to work with that NIC?
<Xiaoman>it fails to load the firmware, which suggests to me that it misses the firmware
<Xiaoman>for example in Debian you would have to install an extra package for the firmware
<taylanub>does anyone know a solution to when a ./configure script uses pkg-config to check for the existence of a library, but that library doesn't seem to provide a <dir>/share/pkg-config/<lib>.pc file?
<grantix>There's a chance I'm heading to bed soon ... it's only 3 here, but man, I'm fatigued.
<taylanub>Xiaoman: are there libre iwlwifi drivers? GuixSD uses Linux-libre, which doesn't include any non-free drivers.
<Xiaoman>I think it does
<Xiaoman> https://www.h-node.org/wifi/view/en/753/Intel-Corporation-Centrino-Advanced-N-6205--rev-34-
<Xiaoman>suggests that it does
<Xiaoman>"Tested also with Trisquel 7.0. Works fine."
<Xiaoman>I doubt Trisquel comes loaded with non-free firmware
<taylanub>hmm, shot in the dark: "modprobe iwlwifi"
<Xiaoman>yeah, it is then it fails to load firmware
<mark_weaver>Pastaf: I don't like the double bars either. fortunately that is easily customizable in xfce. I just have a single bar on top, and nothing on the bottom.
<Pastaf>oh really? I haven't tried it much
<Xiaoman>Xfce is really customizable
<Pastaf>I just put it on my BSD, went "nope" and installed kde
<taylanub>Xiaoman: I'm suspecting the firmware isn't libre, and whoever used it with Trisquel added it manually. you can probably find the firmware file via google and put it into /lib/firmware or so, but note that this works around Guix's packaging mechanism, and you'll be executing a binary blob downloaded from the web right in your kernel
<Pastaf>I gueesss if I can remove that, it's livable
<mark_weaver>rekado_, davexunit, bavier`: I just pushed a fix for the 'guix pull' problem. it should hopefully work now.
<Xiaoman>taylanub, yeah, that is what I'm afraid for
<mark_weaver>(or soon, not sure if there's some small delay)
<mark_weaver>anyway, now I *really* have to run..
*mark_weaver goes afk
<Xiaoman>I assumed X220 could be run libre with the whole push for opening up those old thinkpads
<taylanub>Xiaoman: see Gluglug X220, which adds a wifi card with libre drivers (meaning the unmodified X220 doesn't have that)
<Xiaoman>oooh
<davexunit>mark_weaver: I wonder if that will fix the test failures that Andreas noticed.
<davexunit>oh yeah, you're gone. bye!
<taylanub>Xiaoman: (at least that's what I remember; I might be mixing up models or so...)
<Xiaoman>Wait, gluglug doesn't sell X200
<Xiaoman>Wait, gluglug doesn't sell X220*
<taylanub>OK, I was thinking of http://shop.gluglug.org.uk/product/libreboot-x200/
<taylanub>I don't know about the X220 then
<Xiaoman>I guess I could buy a Atheros AR5B95
<Xiaoman>Hmmm... I wonder why firmware for 6205 is in the free department of Debian, when it is non-free
<bavier>a_e: I just pushed a fix for the cpan importer test, could you try it?
<a_e>bavier: Will do!
<a_e>bavier: Did you read my message concerning duplicity?
<a_e>bavier: The test passes, great!
<bavier>a_e: great
<bavier>a_e: re duplicity: I did read it
<bavier>still looking into it.
<a_e>Okay, nice.
<bavier>the main issue is with the command that duplicity calls gpg with
<bavier>namely: "gpg", which is only found in gpg-1. But I think we should be able to override/patch that to "gpg2" somehow
<bavier>I don't think we can get around it for hdup, unfortunately
<a_e>I just wondered if maybe a newer version was compatible with gpg2 out of the box.
<a_e>"gpg2" instead of "gpg" should normally work.
<a_e>I think one of them had a newer version on github, but I have forgotten the details.
<bavier>yes, duplicity has an updated version. hdup is stagnant, but maybe we could get it to use gpg2
<a_e>Right now, I am trying to install avidemux, a video editor. The build system is a bash script on top of cmake. What a nightmare!
<a_e>It includes an outdated bundled copy of ffmpeg that it uncompresses and patches during the build. Of course there are /bin/sh all over the place.
<a_e>bavier: Then I do not know how important it is to get rid of gnupg-1. Maybe it is not worth investing much work into it.
<a_e>A package more or less does not make a big difference.
<bavier>and gpg-1 is still supported with security updates.