IRC channel logs


back to list of logs

<Apteryx>efraim: thanks!
<Apteryx>interesting; tripadvisor is hosting GNU: eh!
<pkill9>they're hosting ubuntu and centos stuff also
<pkill9>and archlinux
<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>thanks for the info!
<lfam>Happy hacking
<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>Hello guix!
<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>actual value: #f
<g_bor>home-page: 200
<g_bor>expected value :""
<g_bor>domain not found system error
<g_bor>in test/lint.scm:424:29
<g_bor>These are my test failures on current master. Both in lint.
<g_bor>commit is 62d14d240.
***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>Same here.
<marusich>I'm on a branch based off of 3b2fa4787938a408fab27ef7b3bc1302b6b6a805.
<marusich>Whoa, that's old D:
<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>This is commit 62d14d240.
<g_bor>current guix version is: e5f9ec8bc3...
<g_bor>Just ran guix pull.
<g_bor>This is on GuixSD.
<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
<marusich>Let me restate that.
<rekado>yes, but shouldn’t it rather behave like “--ad-hoc” which is given all the direct inputs of the package as an argument?
<marusich>Actually, wait, I said it right.
<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>Hello guix!
<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 ...))
<bavier`>nckx: see guix/packages.scm:815
<Sleep_Walker>efraim: good to see you're interested in OBS package :)
<Sleep_Walker>efraim: FYI, guile 2.0 is not in Factory, you need to take gnutls-guile package from
<Sleep_Walker>(that is built against 2.2)
<g_bor>Hello guix!
<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>This is bb2a95580.
<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>Anyone else noticed this?
<rekado>maybe it’s a corrupt archive?
<g_bor>rekado: Yes, most probably.
<g_bor>Ok, now I finally got to the java-jeromq bug. I will have a look at that now.
<efraim>dolphin-emu builds on aarch64
<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, 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>In general, no
<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 <>
<ocharles>thanks lfam. I think I found it at, which is called by derivations.scm `derivation` function
<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
<lfam>ocharles: You might find the manual section "Programming Interface" helpful. It describes how things work to some degree:
<ocharles>Oh, very nice - thank you!
<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? :)
<Sleep_Walker>IIRC separator
<htgoebel>Hi guix!
<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
<pkill9>that's why it throw sthat error
<lfam>efraim: That's weird. It works for me in this example: guix build --no-grafts shotwell --substitute-urls=""
<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 <>?
<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
<daviid>*did not register
<lfam>daviid: That's okay, you can still send a message there
<daviid>lfam: ah ok, will do then
<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 :-)
<daviid>lfam: done!
<lfam>Thanks a lot daviid :)
<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 ...
<g_bor>Hello guix!
<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?
<daviid>bavir` ah, xcolor ... I see
<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.
<lfam>I restarted 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: <>. I wonder if you are still interested in these packages?
<bavier`>lfam: yes.
<bavier`>lfam: I can take a look at them
<lfam>Thanks. If we need to keep the old librsync around too, I guess that would be fine
<bavier`>rdiff-backup has a new upstream at