<davexunit>I've now patched ruby executables to add input gems to the gem path <davexunit>turns out that the 'gem' program was already writing executable wrappers to set up some gem environment stuff. <davexunit>as of now, the user still needs to set GEM_PATH in order for the ruby package they actually installed to be found, but I think that's reasonable. <ewemoa>hurray for adapting existing infrastructure :) *davexunit sends more ruby related patches to the list <davexunit>hmm, my patch-executables patch probably doesn't go far enough <davexunit>if foo requires bar to run, but bar requires baz, my solution wouldn't get baz on the load path... ***Digit_ is now known as Digit
<pepperleekpotato>Hello. I'm trying to complice an application but I get the 'configure error C compiler cannot create executables'. Does anyone know what could be wrong? <davexunit>pepperleekpotato: is this in a build recipe? <mark_weaver>pepperleekpotato: you should look at the config.log and see what went wrong <pepperleekpotato>Hm yeah taking a better look in config.log seems I'm running a gcc version that UDE doen't like or alike. <iyzsong>Sleep_Walker: Hi, do you still have the duplicates login pam-service issue? After run 'make gnu/system/linux.go', 'pre-inst-env guix system reconfigure' works for me. <Sleep_Walker>iyzsong: can't confirm - I have the same issue as in the morning - the one with gmime <iyzsong>Sleep_Walker: did you have commit 93c117eec? I install notmuch and gmime today (with substitutes) without problem. <Sleep_Walker>lrwxrwxrwx 1 root root 62 8. bře 13.02 /bin/sh -> /gnu/store/nq6idcqwqc9x6z7g9jxq11a58jqx6w8x-bash-4.3.33/bin/sh <svetlana>is it normal for guix to store binaries in /gnu/store/*/bin/* ? <iyzsong>svetlana: yes, every package have binaries in its $out/bin (/gnu/store/xxx-package-version/bin) <jonkri>When I'm trying to install IceCat using Guix 0.8, I'm getting this message: "gnu/packages/gnuzilla.scm:46:2: note: using icecat-31.2.0 but icecat-31.4.0 is available upstream". <davexunit>we can detect new upstream releases of GNU software <davexunit>I don't think that means its packaged, though. <davexunit>but serves as a reminder for *someone* to do the update :) <jonkri>Yes. In the case of something like Firefox, a reminder seems pretty important. :) <jonkri>There's some Linux/glibc/coreutils stuff being fetched with this pull... I'm guessing that's the bootstrap stuff. <davexunit>I want a more bleeding edge icecat or something. icecat sticks with firefox long term support releases, but mozilla is at firefox 36 at this point. <davexunit>jonkri: is this the first package you've installed since updating? then yes. <davexunit>it gets *all* of the software that icecat was built with. <jonkri>Oh, I thought I was pulling. Cool. <jonkri>Yeah, I would probably need something like a bleeding edge icecat too. <davexunit>I don't want to end up maintaining icecat, though. :) <jonkri>I mean, are you active in any free software projects, or such? <jonkri>Would this web interface be, like, GNOME Software, but as a web client? <davexunit>it will eventually be included in core guix, when it's ready. <jonkri>The screenshot seems to be missing from the readme. <jonkri>It just says "guix-web screenshot". <jonkri>There appears to be some Iceweasel certificate probblem with media.dthompson.us. <davexunit>it's not a problem, it's a self-signed cert. <jonkri>Looks good. The Boostrap CSS is such a convenience, sometimes. <jonkri>Would it be possible to have something like a "system" metapackage in Guix? <jonkri>Like, if a distro want to abstract away the individual packages, like Coreutils, and instead define named system releases. <jonkri>So if a vulnerability happens in something like Coreutils for instance, that would be one package update from the perspective of the user, instead of several. <davexunit>you'd just update your system like you would any distro <jonkri>OK, let's assume that there is a system "meta package that depends on Linux, Coreutils, etc. <jonkri>And let's say that a future version of this "meta package" switches the kernel to, say, Hurd. <jonkri>From the user's perspective, the user upgrades to the new version of the system meta package, he might not care that the underlying dependencies change. <jonkri>Like when you dist-upgrade with apt-get, apt-get knows certain packages are not needed anymore. <jonkri>I guess I'm wondering how mature these kinds of mechanisms are in Guix. <davexunit>you configure your OS to have the packages desired. <jonkri>I'm thinking if someone were to put together a distro which did things differently. A defined set of packages designed to work together. An integrated solution, if you will. <jonkri>I guess the software app for that distro could show only certain packages, and that the "system" meta package would be one such visible package. <davexunit>one thing to understand is that you don't typically install software system-wide <davexunit>but most application software you'd install into a per-user profile <davexunit>to upgrade an OS would be a 'guix pull' + 'guix system reconfigure', that would install the new versions of all the base software in your OS config files. <jonkri>I guess that second command is specific for GuixSD. I'm currently using Debian. <davexunit>doesn't install any other new software to your profile <davexunit>'guix package -u' would upgrade all of the software in your profile <jonkri>Yes, that one I discovered by myself. :) <taylanub>there's many executables in /gnu/store with dangling .so references. (specifically to libjack it seems, but also others.) if I use my Debian system's ldd, these resolve to .so files on my system. this is probably a bug, right? (or each instance is an individual packaging bug, assuming our ld handling cannot do a better job.) <mark_weaver>please mail bug-guix@gnu.org about each package you find with such a bug <mark_weaver>I guess those packages wouldn't work at all on GuixSD <jonkri>Is anyone working on a Wayland package for Guix, by any chance? <taylanub>need to refine that method a bit to get a better list, and only the package names (not every executable) <rekado>I built a programme that depends on libGL. When I start it I get this error: <rekado>libGL error: Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. <rekado>Is this a problem with our mesa package? <mark_weaver>jonkri: I'm not aware of anyone working on Wayland yet <mark_weaver>rekado: it may be that udev should be a propagated-input in mesa, not sure. <rekado>re dangling .so references: I find it odd that jack2 would have a reference to libjack.so.0 which is provided by jack-1, an alternative JACK implementation. <rekado>mark_weaver: I'll propagate udev from mesa and see if that fixes it. <mark_weaver>rekado: hmm, although if it's trying to dlopen it, that may not be enough or even appropriate <mark_weaver>rekado: we should probably find the place in mesa where the dlopen happens, and help it find libudev <mark_weaver>preferably by making it look for the right absolute pathname, or else using one of the libltdl APIs for adding directories to its search path <rekado>it tries to look for it in /gnu/store/vd8ij01bq08icp87bz5gs2v4bq53bls6-glibc-2.21/lib/libudev.so.0 <rekado>oh, that's just one of the places <mark_weaver>rekado: for now, so you could at least try running your program, set LTDL_LIBRARY_PATH to help it find libudev <rekado>hmm, I set LTDL_LIBRARY_PATH=/gnu/store/sai0a4yzwqdmsfzykad8k4qqjxmvn1z9-eudev-2.1.1/lib/ but the error is unchanged. <mark_weaver>rekado: well, setting LD_LIBRARY_PATH might work for now <mark_weaver>but I think the proper fix is probably to change dlopen("libudev.so.N") to dlopen("/gnu/store/.../lib/libudev.so.N") in mesa <mark_weaver>it looks like there are several places in Mesa that call dlopen, and probably most of them need to be fixed <mark_weaver>some of them don't have a simple string literal as the argument to dlopen <mark_weaver>updating mesa will force a rebuild of every X program/library, I believe. it should probably be done in another branch. <jonkri>Is anyone working on a D-Bus API for Guix? <rekado>the package I just completed (and which segfaults because of mesa's use of dlopen) is PCB. Should I hold it back until Mesa has been updated? <mark_weaver>rekado: do those dlopen errors prevent PCB from working properly, or is it just a warning? <rekado>it segfaults on startup :-/ Using LD_LIBRARY_PATH I can start it. <mark_weaver>rekado: for now, it would probably be okay to use 'wrap-program' to make a wrapper around PCB that adds the eudev path to LD_LIBRARY_PATH, with a FIXME comment <taylanub>mark_weaver: here's a better script http://sprunge.us/ITFM quite a monstrosity but it's a one-time hack. takes a lot of time (still running here) but should be comprehensive I think. <taylanub>I guess it might have false positives too, if some package uses LD_LIBRARY_PATH hacks to make some executables find .so files... <mark_weaver>taylanub: would you like to file bug reports for each package with the problem? <mark_weaver>a lot of those are probably not really issues, but it's great to have that set of possible issues to look through <pepperleekpotato>Hello guys, I've recently installed Guix and I'm testing it these days. I know it's work in progress but I've noticed a few bugs and I could mention some things that I found difficult to configure until I have a working system. Is it worth mailing the guix-dev or is it just for super-technical stuff there? <taylanub>pepperleekpotato: you might want to directly file bug reports, sending mail to bug-guix@gnu.org. that way they will be archived and won't be forgotten in case they're minor end-user concerns which don't immediately get developer attention <pepperleekpotato>hi taylanub. ok i'll do this. do i just subscribe and then just mail bug-guix? should i send an email per possible bug? <pepperleekpotato>and B) can I file bugs for the system distribution too or just the package manager? <taylanub>pepperleekpotato: AFAIK you don't need to subscribe (that would be weird for a bug-report ML), and you can report bugs for both (development is united as of now, and I guess it will remain so) <mark_weaver>jxself: linux-libre 3.18.9 is out. are you around, or should I take care of it? *mark_weaver begins building it to test <rekado>rebuilt gimp with pygtk, but it has the same problem as solfege and probably needs to be patched in a similarly ugly manner. <mark_weaver>it may be that we need a way to combine build systems together somehow, e.g. to combine python-build-system with glib-or-gtk-build-system <mark_weaver>though I confess I don't remember what you had to do for solfege, so maybe my suggestion is not germane to your issue 