<pkill9>they're hosting ubuntu and centos stuff also <Apteryx>they must have some gentle sysadmins <Apteryx>hmm. I've fixed the fact that our emacs build system would pass even when there were byte-compilation errors... but there seems to be many packages that were failing :( <adamvy>The current way that guix profiles are set up, if I install some library to my user profile, and then try to build a program which uses it, I can compile it successfully but I can't run it without setting up LD_LIBRARY_PATH. Is there something we can do about this? <adamvy>It feels wrong to have to muck around with envrionment variables manually. <lfam>adamvy: It should work if you use the tools from the gcc-toolchain package <adamvy>innteresting, so I'm supposed to install gcc-toolchain rather than just plain gcc <adamvy>I see that the gcc-toolchain includes ld-wrapper <lfam>adamvy: Right, when you use gcc-toolchain it takes care of all the library paths for you. Whereas the regular 'gcc' package doesn't <adamvy>I kind of ignored those packages since they were in commencement.scm I thought they were only related to bootstrapping :S <adamvy>It might be useful to add a note to the GCC package description about the gcc-toolchain packages <atw>Apteryx: did you test that with fold-packages? <g_bor>It seems that current master has test failures in lint. <rekado>g_bor: what test failures are these? Do you have test logs? <g_bor>I have home-page connection refused and home-page 200 failing. <g_bor>home-page: Connection Refused <g_bor>domain not found system error <g_bor>These are my test failures on current master. Both in lint. ***Gamayun_ is now known as Gamayun
<rekado>g_bor: this is odd because we don’t make an attempt to connect to the internet <rekado>do you have something running on port 9999? <rekado>I just ran “make check TESTS=tests/lint.scm” and I cannot reproduce the test failures. <marusich>I'm on a branch based off of 3b2fa4787938a408fab27ef7b3bc1302b6b6a805. <g_bor>I don't run on 9999 anything that I know about. I'm now running guix pull, I will check when that is finished <mbakke>Ooh, we now have 666 files to compile during `guix pull`. <g_bor>Ok, so netstat -l does not show anything on port 9999. <g_bor>"make check TESTS=tests/lint.scm" fails for me with the exact same errors. <g_bor>current guix version is: e5f9ec8bc3... <rekado>Why does “(guix scripts environment)” use “package-environment-inputs” when packages are loaded from a file, but “package+propagated-inputs” when ad-hoc is used? <rekado>I have a suspicion that package-environment-inputs doesn’t quite do the right thing. <marusich>I don't know the details, but I believe the intent is to create an environment with the dependencies of the package when loading from a file. <rekado>for example, package-environment-inputs will include glibc for any package, because that’s part of the bag. <marusich>And the intent is to create an environment with just the specified package and its propagated inputs when using --ad-hoc. <rekado>my current problem is not only that glibc is included, but that it is the ungrafted glibc (which causes things to fail on older kernels) <marusich>So, I would expect guix environment -l my-file.scm to behave the same as guix environment my-package, assuming that my-package is returned by the code in my-file.scm <rekado>yes, but shouldn’t it rather behave like “--ad-hoc” which is given all the direct inputs of the package as an argument? <rekado>FWIW I think that the behaviour for both “guix environment foo” and “guix environment -l ends-with-foo.scm” is odd. <marusich>Yes, I think you're right; I would expect "guix environment -l myfile.scm" and "guix environment my-package" to produce the same result as when I run "guix environment --ad-hoc i ..." where the i's are the direct inputs of my-package. <rekado>it is somewhat worrying that (some of?) the things I get from “guix environment -l” are not grafted. <marusich>I would expect that to be the same, basically, as if I did "guix package -p -i my-profile input1 input2 input 3 ..." and then did 'eval "$(guix package -p my-profile --search-paths)"' <marusich>Maybe if you email David, who wrote guix environment, he might offer more insight into its intended behavior. Seems odd if it's not picking up grafts, though. <rekado>I’m trying to find a short example with which this can be replicated. ***benny- is now known as benny
<rekado>hmm, I cannot reproduce this with raptor2 <rekado>this uses the grafted curl and the environment ends up containing that grafted version of curl. <rekado>I wonder if the error is due a mistake in my glibc graft <efraim>You used (package/inherit in commencement? <efraim>I know that's The Right Thing but I don't remember why ***dghubble_ is now known as dghubble
<jayspeer>Hello. I'm currently trying out GuixSD on laptop. Is there a specific way to handle network connection? So far I managed to get wireless running with NetworkManager but wired is no go. Any suggestions? <jayspeer>Nevermind - my ethernet cable was broken... -_- Have a nice day everyone! <kmicu>Classic. Have a nice day jayspeer ( ^_^)／ ***lanlink_ is now known as lanlink
<jayspeer>To add some spice I just finished my networking course ^_^ <g_bor>I'm trying to get java-jeromq right. <g_bor>Anyone knows why we are using a git checkout there? <g_bor>It seems there is a 0.4.3 release tarball? <rekado>g_bor: I used a git checkout because the tarball is generated on demand <rekado>efraim: that’s a special macro written by Mark <rekado>I just looked up previous glibc grafts; I don’t really understand the exact effect of this macro. <efraim>I think its supposed to allow grafting without creating a loop ***Digitteknohippie is now known as Digit
<nckx>I think I asked about package/inherit here a while back; seemed that nobody knew the answer. Still interested :-) <bavier`>nckx: could you repeat the question? :) <nckx>Just when/why to use (package/inherit ...) instead of (package (inherit ...)). <bavier`>nckx: package/inherit handles package "replacements". It should be safe to use anywhere you'd otherwise use (package (inherit ...)) <g_bor>Now the two test failures from lint is gone. <g_bor>I currently have one in packages, it says cannot find bootstrap binary guile-2.0.9 <g_bor>Test name is: pacakge-source-derivation, snippet <g_bor>oops... package-source-derivation, snippet <g_bor>A mail from debian security just fell into my mailbox. <g_bor>They are advising to upgrade kernels. Is GuixSD affected? Or do we already have these fixed? <efraim>Sleep_Walker: does OBS also build debian & co packages? <g_bor>icedtea-3.6.0 substitute from hydra seems to be failing consistently. <g_bor>Ok, now I finally got to the java-jeromq bug. I will have a look at that now. <Sleep_Walker>efraim: it can, but you need to add debian files and enable it <efraim>Sleep_Walker: I was thinking of working on that, it would make it easier to build guix from source on debian & derivatives <efraim>mbakke: are you sure we want glib:bin as an input for json-glib? i know it uses meson build system, but that's the type of thing normally covered with glib-or-gtk-build-system and/or substituted out <pkill9>when Guix is updated upstream, does that force everything to be rebuilt due to the Guix repo itself being considered an input? And does that mean that everything needs to be downloaded again, even if nothing you have installed has any updated in the newly downloaded guix repository? <Sleep_Walker>efraim: I know very little about Debian packaging but I can help you with OBS stuff <pkill9>s/needs to be downloaded/gets to be downloaded on `guix package -u` <efraim>I've spent a lot of time over the past two years looking at sources.debian.org, I can probably figure out the debian packaging stuff <ocharles>Hello. Does anyone know where in the Guix source it adds derivations to the Nix store? <lfam>pkill9: To clarify, you are asking if a new version of Guix itself causes all the packages to be rebuilt? <pkill9>well, a new version of the guix package definitions from `guix pull` <pkill9>but that's considered a new version of Guix itself, so yes I think <lfam>We try to avoid rebuilding whenever we can :) <lfam>Hi ocharles! I don't know exactly. If nobody replies here after a little while, please send your question to <help-guix@gnu.org> <ocharles>I'll idle around though in case anyone has more info <lfam>Yeah, the derivations module is where a lot of the action happens, but I'm not very knowledgeable at that level <ocharles>I'm not used to this whole "useful documentation" thing ;) <lfam>Heh, there is always room for improvement :) <efraim>what was the answer again for --substitute-urls='url1 url2'? <lfam>What was the question? :) <htgoebel>How do I install both python and python2 into a profile? Running "guix package -i python python@2" <htgoebel>gives an "error: profile contains conflicting entries for python" <lfam>efraim: It should work like you wrote it <pkill9>htgoebel: i asked that a while back, you can't relaly do it because python reads the PYTHONPATH variable to find it's libraries and doesn't distinguish between version in that variable <pkill9>you can only really install to different profiles <efraim>i get code=exited, status=64 with 'url1 url2' <htgoebel>pkill9: I already fail installing the package. I don't care about the PYTHONPATH issue ATM. <pkill9>i mean, that's why it considers them conflicting eachother <pkill9>because they both rely on PYTHONPATH, but they won't distinguish version <pkill9>of libraries in the directories specified in PYTHONPATH <efraim>i'm sticking it in the guix-daemon <lfam>I also pass arguments like that to guix-daemon <daviid>hello, a quick suggestion: on the package list on the web page, i think the alphabetic letter selection menu should be presented both on top and at the bottom ... right now we have to scroll down the first page to get access to it ... <lfam>daviid: Good idea, can you send it to <bug-guix@gnu.org>? <daviid>then, I think someone should package linphone, i can't do it, it is a skype killer, GPL, with a free sip server, it really is an app to have - it is better and more robust then skype (at least on linux)... <daviid>lfam: i did not registered to bug-guix <lfam>daviid: That's okay, you can still send a message there <htgoebel>pkill9: Nope! :-) The error is not about conflicting PYTHONPATH entries, but about conflicting *packages*. <htgoebel>guix does not know the PYTHONPATH entries are conflicting. PYTHONPATH is handled like any other "search-path". <htgoebel>PYTHONPATH is only "conflicting" since in guix we use in a way it is not intended to be used. <htgoebel>I'm going to work on this issue, but for this I need both versions of python installed in one profile :-) <rekado>htgoebel: you’re right: you currently cannot install packages with the same name (but different versions) into the same profile. You *can*, however, use “guix environment --ad-hoc” to create a profile that doesn’t have this restriction. <bavier`>daviid: I've thought the same about the package list, thanks for sending a message. <efraim>american-fuzzy-lop also needs qemu-minimal-2.10, I think it would be best to just add the source as a field to afl-qemu's source rather than use the one in bootloaders.scm <daviid>bavier`: hello! yw! how is guile-cv guix packaging going? <bavier`>daviid: slow. I got hung up on some of the latex packages. <bavier`>I might try having another go at it this weekend <daviid>latex, really? that is surprising, is it the font maybe? all other packages are i texlive, iirc <bavier`>yeah, we could probably depend trivially on texlive <bavier`>but I have a bit of an aversion to texlive dependencies <daviid>oh I see, you are making small latex packages not to depend on texlive... the iwona font isn't in texlive core though <bavier`>otoh, it would probably be better to just get guile-cv working, and then pare down the latex dependencies later <daviid>bavier`: I don't know, maybe you're right, texlive is sort of a monster pckage :), adn yet again, does not contain the font I selected ... <daviid>bavier`: thanks anyway, take your time, maybe your approach is better... <daviid>bavier` the reason I'm not in a hurry is, guile still is a problem, untill maintainers address my 2 requests for improvemnts, one way or another, guile-cv users do have to manually patch guile, and I kow that, no biounformatix person will ever do that on earth ... <bavier`>the iwona package, iirc, is fine; it's xcolor that is having trouble <g_bor>I'm trying to build a modified version of java-jeromq. I've created the sources, modified them and then I tried building it with transformation option --with-source, but I got a warning, that the transformation option did not affect the package. <g_bor>What are the requirements of this option? <lfam>Scipy failed spuriously on Hydra. It got to 'build-succeeded' but still registered as failed <rekado>restarting the build should help. It shouldn’t actually rebuild it. <mbakke>efraim: regarding json-glib, I didn't check if glib:bin is still needed. Do you think it can cause problems? <efraim>it might cause collisions in profiles <mbakke>It's a native input, so should not be referenced. <lfam>bavier`: I noticed you added the btar and rdiff-backup packages back in 2014. They are affected by the proposed major update of librsync: <https://bugs.gnu.org/30448>. I wonder if you are still interested in these packages? <lfam>Thanks. If we need to keep the old librsync around too, I guess that would be fine