IRC channel logs


back to list of logs

<phant0mas>good morning guix
<phant0mas>the mig i packaged doesn't work right
<phant0mas>it's isn't linked with the mach-headers
<phant0mas>so I have to specifically pass this flag "TARGET_CPPFLAGS=-I " to mig configure with the position of the include folder from mach-headers
<phant0mas>or maybe not..
<phant0mas>oh crap....
<phant0mas>managed to build gnumach by invoking guix build with --system=i686-linux
<phant0mas>now trying to find whay can't do the same by passing the flag --build=i686-pc-gnu to the configure
<Fulax>Is there any .deb package of guix? or at least the debian's specific build files?
<phant0mas>there isn't any deb package of guix from what I know
<Fulax>phant0mas: that's what I thought, thanks for confirmation
<phant0mas>you are welcome
<phant0mas>mark_weaver: are you here?
<phant0mas>I am kinda lost here
<phant0mas>if I build gnumach with --system=i686-linux at guix build
<phant0mas>it builds just fine
<phant0mas>else it won't no matter what flag I pass to the configure
<phant0mas>and outside guix
<phant0mas>I can only build it if I change some env vars before invoking configure
<phant0mas>even if I pass cflags
<phant0mas>it won't work
<phant0mas>should I set env vars in guix as well and try again?
<mark_weaver>I think that --system flag is what you want anyway, no?
<mark_weaver>oh, sorry. nevermind.
<mark_weaver>this is not my area of expertise.
<phant0mas>I want to be able to build it
<phant0mas>without having to invoke that flag
<mark_weaver>well, the hurd only runs in 32-bit mode, right?
<mark_weaver>so it needs to be built with a 32-bit toolchain.
<phant0mas>that's right
<phant0mas>so for now I shouldn't worry
<phant0mas>I will find a way
<phant0mas>I am reading the config logs
<mark_weaver>I think for now you should just pass --system=i686-linux to all the builds, and when civodul comes back, ask him if there's a better way.
<phant0mas>sorry for going so slow
<phant0mas>my uncle was in town and I went to pay him a visit
<mark_weaver>no worries, I don't think you're being particularly slow.
<phant0mas>btw something else I wanted to ask you
<phant0mas>you told me you used to write drivers right?
<phant0mas>do you have any good books in your mind that I could read?
<mark_weaver>phant0mas: what kernel do you need to write the drivers for? Linux?
<mark_weaver>I guess that Linux Device Drivers <> is probably a good resource, but it's quite out-of-date. Linux is evolving very quickly, and in practice driver authors just have to keep up on the changes to the internal APIs incrementally.
<mark_weaver>what kind of device are you writing a driver for?
<ggrant>Is it possible to generate a somewhat practical vm now? I'm stuck on Fedora 20 and I want to contribute, but due to some Fedora centric stuff I can't get it installed.
<ggrant>Well I can, but I can't set up the build users group and the like.
<phant0mas>mark_weaver: for the arm zedboard running linux
<phant0mas>I am reading Linux Device Drivers
<mark_weaver>ggrant: what difficulty did you run into creating the build users group and users?
<mark_weaver>I see no reason why you shouldn't be able to get Guix running on Fedora 20.
<ggrant>mark_weaver: Since Fedora moved everything to bin, calling some of the commands to make it.
<ggrant>I can try the install again, one sec.
<mark_weaver>ggrant: one thing: I recommend passing --system to useradd. we fixed that in the manual in git master, but it's not in the manual of the most recent release (0.5)
<mark_weaver>(that makes it so that the build users won't show up in the graphical login window)
<ggrant>mark_weaver: Well now, I'm not even getting to that point. When running the bootstrap, I get "autoreconf: running: /usr/bin/autoconf --force error: possibly undefined macro: PKG_CHECK_MODULES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation."
<zerwas>I think I had the same error recently. Unfortunately I can't remember the solution. Maybe it was running libtoolize
<mark_weaver>ggrant: it's easier if you initially build from a tarball instead of from git.
<mark_weaver>then you don't have to run bootstrap
*ggrant should've just stayed on his Parabola install.
<mark_weaver>but fwiw, the problem there is probably that pkg-config wasn't installed when you ran bootstrap.
<ggrant>mark_weaver: It was. :^P
<mark_weaver>well, maybe there's some kind of pkg-config-devel package or something, for fedora.
<ggrant>mark_weaver: Doesn't look like it. :^P
<mark_weaver>on my system, the PKG_CHECK_MODULES macro is defined in /usr/share/aclocal/pkg.m4
<mark_weaver>do you have that file on your system?
<mark_weaver>it's part of pkg-config.
<mark_weaver>where is it located on your system?
<ggrant>mark_weaver: */usr/share/aclocal/pkg.m4
<mark_weaver>strange. that should be in the default path where the autotools look. well, for now, you could: export ACLOCAL_PATH=/usr/share/aclocal and try running bootstrap again.
*mark_weaver suspects that either the fedora autotools are configured to look in the wrong place, or that their pkg-config package is installing pkg.m4 in the wrong place. somehow, those two things are lining up.
<mark_weaver>maybe breakage from the recent /usr/bin -> /bin change.
<mark_weaver>do you have a /share/aclocal directory on your system, with files in it?
<ggrant>Just /share? I have no root directory called /share.
<ggrant>Also the aclocal thing worked.
<ggrant>Not sure how/if the group adding will work, though. :^P
<mark_weaver>why do you think it wouldn't?
<ggrant>mark_weaver: I've tried it before, and it didn't.
<mark_weaver>well, please try again and tell me the details of what happened, and we'll work through it.
<ggrant>Will do.
<ggrant>Yeah, it can't find useradd.
<ggrant>Found it in /usr/sbin/useradd
<ggrant>May have got it.
<ggrant>mark_weaver: Yup, thanks! Grabbing glibc now. :^)
<mark_weaver>excellent :)
<ggrant>Yah, now maybe I can start contributing weekly. Still need/want to package feh, scrot, rtorrent, mypaint, and a few others.
<mark_weaver>that would be most welcome!
<davexunit>ggrant: feh and scrot would be handy. :)
<davexunit>I'm just starting to get back into writing packages.
<davexunit>seems that guix is rebuilding all of the bootstrap stuff right now...
<mark_weaver>it might have been a while since your last build :)
<davexunit>yes it has
<mark_weaver>I've recently switched to using Guix programs (almost) exclusively from within my user session. e.g. PATH contains only ~/.guix-profile/bin and no system paths.
<davexunit>that's on my list of things to do.
<mark_weaver>and it's amazing how much that motivates me to write/improve packages that I need.
<mark_weaver>hence the recent flood of patches from me.
<davexunit>yeah that's exactly why I want to do it. I just haven't had the time to get everything configured.
<phant0mas>when I find some time I will package some avr programming tools for my arduino
<davexunit>is there any prior art for building URLs to package tarballs where the URL path contains some fragment of the version number in it?
<davexunit>for instance, the URL for the latest mpd tarball is"
<mark_weaver>davexunit: the way I do it is: (string-join (take (string-split version #\\.) 2) ".")
<mark_weaver>for example in my gmime package in mail.scm
<davexunit>nice! thanks.
<davexunit>I forgot about take.
<mark_weaver>you need to import (srfi srfi-1)
<mark_weaver>ah, it would be nice to have mpd, indeed!
<mark_weaver>I've never gotten in the habit of using that, but I'd like to switch to it.
<davexunit>I recently setup mpd to work with emms and it's quite nice.
*ggrant is attempting a nap. Peace, for now people.
*ggrant is AFK.
<mark_weaver>ggrant: sleep well!
<davexunit>mpd has a nice architecture. in addition to the emms client, I run another client that just "scrobbles" the songs I play to
<mark_weaver>indeed, its architecture is the major draw for me.
<phant0mas>mark_weaver: I was about writing the gnumach recipe and then make the gnumach-headers inherit most of the info from it
<phant0mas>I was thinking*
<phant0mas>what do you think?
<mark_weaver>fwiw, the 'linux-libre-headers' and 'linux-libre' packages don't inherit from each other.
<phant0mas>that's why I am asking
<phant0mas>so better not eh?
<mark_weaver>here's one thing to keep in mind: it might be preferable to update 'gnumach' more often than 'mach-headers'
<phant0mas>understood :-)
<davexunit>yay, mpd builds now. just missing all the bells and whistles
<mark_weaver>because updating 'mach-headers' will require the entire system to be rebuilt, but hopefully 'gnumach' can be upgraded without requiring that.
<mark_weaver>davexunit: in guix, you mean?
<davexunit>mark_weaver: yeah.
<davexunit>my recipe is working.
<phant0mas>I was also thinking about using git-fetch for the gnumach, there are a lot of bugfixes not in the tarball versionm
<phant0mas>what about that?
<mark_weaver>davexunit: sweet!
<mark_weaver>phant0mas: mmm, dunno. I suspect that civodul would prefer to stick with tarball releases, but who knows?
<phant0mas>I will do some experimenting on the git version
<phant0mas>and I will ask ludo as well
<phant0mas>I <3 guix :-)
<davexunit>it really is a pretty pleasant experience to write guix packages. for most packages, anyway.
<davexunit>how do you force a package to be rebuilt?
<mark_weaver>well, if you made any changes, it will be rebuilt automatically.
<davexunit>mpd built fine, but I lost the output of its configure script and I want to see the optional dependencies that I missed.
<mark_weaver>davexunit: cd $PREFIX/var/log/nix/drvs; ls -ltr */* | tail
<mark_weaver>those are the log files of your most recent builds.
<mark_weaver>or in this case, ls -ltd */*-mpd-* | tail
<mark_weaver>sorry, ls -ltrd */*-mpd-* | tail
<mark_weaver>(forgot the -r)
<mark_weaver>going offline for a bit, happy hacking!
<davexunit>see ya!
<mark_weaver>welcome :)
<ggrant>Hm, imlib2 is "checking for X" ... not sure what should be an input here besides libxext, which is listed as the only x dependency I can find.