IRC channel logs


back to list of logs

<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>so I just added a snippet to it
<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>Can't see much in config log. I'm trying to compile UWM (for UDE).
<pepperleekpotato>I installed any available C/C++ packages.
<pepperleekpotato>Output says the C compiler doesn't work.
<pepperleekpotato>Hm yeah taking a better look in config.log seems I'm running a gcc version that UDE doen't like or alike.
<Sleep_Walker>good morning guix, backtrace for this day - :b
<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: not anymore
<Sleep_Walker>or better - let me try :)
<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>I'll update and retry
<Sleep_Walker>I'm working on enlightenment in different branch
<Sleep_Walker>iyzsong: it fixed gmime issue, and I still have problems with symlinks in etc, but now I can't say whether it is pam.d or not -
<Sleep_Walker>as workaround I use mkfs :b
<Sleep_Walker>omg, again
<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".
<jonkri>Ah, guix pull. :)
<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.
<jonkri>I do a lot of web development.
<davexunit>I haven't yet had time to figure it out.
<davexunit>I don't want to end up maintaining icecat, though. :)
<jonkri>What do you work on?
<jonkri>I mean, are you active in any free software projects, or such?
<davexunit>I'm writing a web interface for Guix.
<davexunit>I am also the web developer at the FSF
<jonkri>OK, cool.
<jonkri>Would this web interface be, like, GNOME Software, but as a web client?
<jonkri>A UI for Guix?
<jonkri>OK, I see.
<davexunit>it will eventually be included in core guix, when it's ready.
<davexunit>still just a prototype.
<jonkri>OK, cool, good luck.
<jonkri>The screenshot seems to be missing from the readme.
<jonkri>It just says "guix-web screenshot".
<davexunit>hmm, I see the screenshot
<jonkri>There appears to be some Iceweasel certificate probblem with
<davexunit>it's not a problem, it's a self-signed cert.
<jonkri>Oh, right. :)
<jonkri>Looks good. The Boostrap CSS is such a convenience, sometimes.
<davexunit>yes, indeed.
<davexunit>I am no designer.
<jonkri>Would it be possible to have something like a "system" metapackage in Guix?
<davexunit>what would that be?
<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>things work differently here.
<davexunit>GuixSD doesn't impose any packages on you.
<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.
<jonkri>Well, thanks for the help. :)
<davexunit>one thing to understand is that you don't typically install software system-wide
<davexunit>you might do that for a few things.
<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.
<jonkri>OK. :)
<davexunit>'guix pull' just gets a new guix
<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>taylanub: yes, those are definitely bugs
<mark_weaver>please mail about each package you find with such a bug
<mark_weaver>I guess those packages wouldn't work at all on GuixSD
<mark_weaver>what others have you found besides libjack?
<jonkri>Is anyone working on a Wayland package for Guix, by any chance?
<taylanub>mark_weaver: an incomprehensive list:
<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 or, 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
<jonkri>OK, mark_weaver, thanks. :)
<mark_weaver>taylanub: thanks for that list!
<mark_weaver>rekado: possibly
<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 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/
<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>ah right, it's not actually using libltdl
<mark_weaver>it's using dlopen directly
<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("") to dlopen("/gnu/store/.../lib/") in mesa
<rekado>yes, this does work.
<rekado>I'll see if I can patch this.
<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>e.g. for loading DRI drivers
<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?
<mark_weaver>I don't believe so
<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 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: thanks!
<mark_weaver>taylanub: would you like to file bug reports for each package with the problem?
<mark_weaver>(they can be very short, maybe even one-liners)
<taylanub>will do. the script just finished running on my machine:
<mark_weaver>taylanub: thanks!
<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 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)
*taylanub goes AFK
<pepperleekpotato>ok thank you!
<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