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? <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>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>Trying to build makefiles from established programs have same problem <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>Sorry, when i compile it it fails <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>I'll just lisp paste the output, right? <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>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>sir123: I think I know the problem. you need to set the LIBRARY_PATH environment variable <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>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>that teaches me to ignore warnings <mark_weaver>sir123: you can get the list of missing environment variables again with "guix package --search-paths" <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? <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_>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_>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 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_>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? <mark_weaver>maybe there will be some hint about the problem in the output *mark_weaver goes afk for a while <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>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. <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. <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)? <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>my first guess is that it introduced a new module dependency cycle. we need better ways to detect and deal with those. <davexunit>mark_weaver: thanks for identifying this issue. <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>I would suggest changing %corelist into a promise, by wrapping its computation with 'delay' and its uses with 'force'. <Pastaf>Any ETA on desktops besides Xfce? that's essentially the only thing holding me back from using guix <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. <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 <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. <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>"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 <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 <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) <davexunit>mark_weaver: I wonder if that will fix the test failures that Andreas noticed. <taylanub>Xiaoman: (at least that's what I remember; I might be mixing up models or so...) <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: Did you read my message concerning duplicity? <a_e>bavier: The test passes, great! <bavier>a_e: re duplicity: I did read it <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.