<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
<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.
<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!
<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>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 <firstname.lastname@example.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)...
<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.
<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?