IRC channel logs
2014-02-23.log
back to list of logs
<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>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>if I build gnumach with --system=i686-linux at guix build <phant0mas>else it won't no matter what flag I pass to the configure <phant0mas>I can only build it if I change some env vars before invoking configure <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>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>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>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 <https://lwn.net/Kernel/LDD3/> 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. <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 <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 configure.ac:51: 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. *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. <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 <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>Not sure how/if the group adding will work, though. :^P <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>mark_weaver: Yup, thanks! Grabbing glibc now. :^) <ggrant>Yah, now maybe I can start contributing weekly. Still need/want to package feh, scrot, rtorrent, mypaint, and a few others. <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>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. <mark_weaver>and it's amazing how much that motivates me to write/improve packages that I need. <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? <mark_weaver>davexunit: the way I do it is: (string-join (take (string-split version #\\.) 2) ".") <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. <davexunit>mpd has a nice architecture. in addition to the emms client, I run another client that just "scrobbles" the songs I play to libre.fm <phant0mas>mark_weaver: I was about writing the gnumach recipe and then make the gnumach-headers inherit most of the info from it <mark_weaver>fwiw, the 'linux-libre-headers' and 'linux-libre' packages don't inherit from each other. <mark_weaver>here's one thing to keep in mind: it might be preferable to update 'gnumach' more often than 'mach-headers' <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. <phant0mas>I was also thinking about using git-fetch for the gnumach, there are a lot of bugfixes not in the tarball versionm <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 <davexunit>it really is a pretty pleasant experience to write guix packages. for most packages, anyway. <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 <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.