<toxemicsquire4>yea, first of all, I downloaded the guix source tree from git and I extracted it and copied my wicd.scm to the gnu/packages folder. I tried to run ./bootstrap before the "make && ./pre-inst-env guix build wicd
<toxemicsquire4>but ./bootstrap failed because of undefined macro : PKG-CHECK-MODULES
<davexunit>toxemicsquire4: when you are more comfortable using guix, you should try running 'guix environment guix' to quickly setup a development environment.
<jgrant>toxemicsquire4: Yeah, setting up a dev environment even with Guix Environment is not ideal atm. I really want a "guix devel" that will create a seperate development profile -- and clone into the latest repo. :^P
<jgrant>Guix environment is devent in-route though.
<davexunit>guix environment does exactly what you want to do, sans the profile.
<toxemicsquire4>davexunit: I'll try to learn more about it, but for the mean time, I'll stick to what I'll already know.
<davexunit>because, really, the profile is unnecessary in this case. especially now that guix environment runs pretty fast.
<jgrant>davexunit: Doesn't it not stay as-is, once you leave the shell you used to call it?
<davexunit>environment variables are the only thing that change.
<toxemicsquire4>ok, once the guix building finishes, I could finally start finding out what's wrong in my messed up recipe http://pastebin.com/2q7LCv2i I filled in most of the things that I need, though I don't know how to add dependencies yet
<davexunit>using a profile would work, but it's more of a burden.
<davexunit>profiles protect the included packages from the GC, so you have to take care to prune old generations.
<zykotick9>mark_weaver: i did not. i saw you had the previous version available as a pre-built image. but to be honest, that didn't work for either (i don't remember the issue), so i set my mind to trying the install with the new one ;) i might check the "vm generator" out sometime, thanks.
<mark_weaver>jcca: http://hydra.gnu.org/ is our build farm. it's a bunch of machines that compile all the packages in guix so that users don't have to compile things themselves. they can download pre-compiled binaries.
<mark_weaver>but we don't have any ARM machines in the build farm yet, so no pre-compiled binaries for ARM.
<mark_weaver>zykotick9: if you are worried about guix infecting the host system, it should be noted that guix only puts things in /gnu/store, $PREFIX/var/guix and $PREFIX/var/log/guix
<mark_weaver>and if you install packages in your user profile, then it makes a ~/.guix-profile symlink
<mark_weaver>so it's effectively invisible unless you set your environment variables (e.g. PATH) to point to things in ~/.guix-profile
<mark_weaver>you don't have to run "make install". just prefix the commands with "/path/to/build-dir/pre-inst-env" and it will run out of the build directory
<zykotick9>mark_weaver: you seemed to read my mind. i've been avoiding installing guix as a package manager, due to hesitations of having a 3rd party package manager on my system. i think you just laid those to rest. thanks! sounds like something i'd be willing to try :)
<Morgawr>the only annoying thing is that the timing of talks sometimes overlaps in uncomfortable ways, like a talk ends at 11:15 am and another starts at 11:00 am so you either miss the end of one or the beginning of the other
<DusXMT>Probably the only thing I dislike about Guix is the long waiting times you have to wait to test out a small change, I remember that was a great PITA with abiword... but I guess we now have `guix environment', which can cut off most of that time in most cases...
<taylanub>anyone know whether lookups for 'localhost' work in the build worker environment?
<DusXMT>Although I'm not sure if a change I did can be done.
<DusXMT>I've made cross compilers use a ld-wrapper, so the paths to libraries get embedded into the binaries just like with native programs, although that means that they're bound to the cross compiler, since they have its library path (for libgcc) in their RPATH field.
<DusXMT>mark_weaver: Do you think the change I did may be problematic?
<mark_weaver>taylanub: as for normal quoted lists, there's no good way to do it, because sometimes quoted lists are code, and thus should be indented as usual, and sometimes they are data. emacs has no way of knowing which it is.
<davexunit>toxemicsquire4: just checked. no, we don't have it.
<rekado>taylanub: I've got Ardour ready. Maybe some of its dependencies may be useful for Audacity. May be worth checking.
<toxemicsquire4>davexunit: Would it be a bad idea to leave ncurses support out of wicd?
<davexunit>toxemicsquire4: since it's a python package, you can run './pre-inst-env guix import pypi urwid' to generate the basic boilerplate
<davexunit>toxemicsquire4: having wicd at all would be better than not having it.
<davexunit>having curses support would be good, but if you decide not to go for it, make sure you leave a ';; TODO: Add urwid for ncurses interface' comment in the code.
<toxemicsquire4>I'll have to make a recipe for urwid first, then make sure it can compile, then try to compile wicd.
<davexunit>toxemicsquire4: is urwid not an optional dependency?
<toxemicsquire4>It is, but it doesn't feel right to leave it out. Most network managers are very difficult to use from the command line, nm and wicd are 2 of them. the ncurses interface makes everything so much easier
<taylanub>apparently it's really "localhost" that causes some issues in the ngircd test suite. the test sends "who localhos*" to the server and doesn't get the expected answer
<taylanub>while localhost is mapped to 127.0.0.1, it also requires 127.0.0.1 to be mapped to localhost somehow?
<taylanub>indeed. no idea how this reverse DNS works, but the server responds with 127.0.0.1 where the test suite expects "localhost"
<alexshendi>Good evening! I have a package (ecl-13.5.1.tar.gz) that I can compile as a user with the usual "./configure; make" command. Can someone tell me how to get a build receipe skeleton for guix?
<jxself>The (build-system gnu-build-system) thing is the key part.
<jxself>Everything else is hopefully self explanatory.
<toxemicsquire4>davexunit: I wrote up a recipe for urwid, add it to gnu-system.am, make, ./pre-inst-env guix build urwid, and it gives me back the error "gnu/packages/urwid.scm:35:12: In procedure module-lookup: Unbound variable: python-2" even though I entered (inputs `(("python-2" ,python-2)))
<mark_weaver>taylanub: there is no nameserver running in the build environment. just /etc/hosts, which the glibc name resolver will consult, but some other software might not look in /etc/hosts and instead insist on a real nameserver.
<toxemicsquire4>Actually, I think itll only take a bit more than 2 weeks to get everything done. I'm still a newbie, so this is all very new for me, but I'll be able to finish it. I think an ncurses interface is very important for wicd, its very hard to use without it.
<mark_weaver>most users will probably use a GUI interface for wicd, no?
<davexunit>toxemicsquire4: but we can get the package into the distro sooner without it, and then just add the urwid input when it's ready.
<mark_weaver>toxemicsquire4: btw, for that fedora URL, just include it verbatim. that big hash value will change in some unpredictable way when the next version comes out, so there's no point in doing the 'string-append' thing to construct the URL automatically based on the version, as we usually use.
<toxemicsquire4>ok, now it starts building to an extent, but complains about no module called setup-tools
<taylanub>hm, looks like the commit is on top even more changes in-between. this one removes DNS related things entirely from the test suite; I might add the patch which attempts to fix DNS related problems
<mark_weaver>toxemicsquire4: are you using the python-build-system ?
*mark_weaver is almost completely ignorant of python build systems
<davexunit>setuptools is not an implicit input to the python build system
<taylanub>is there a reason a kill(1) command would fail in the build environment, on a process that was started by the builder? the test suite starts then tries to kill a process, failing if "kill -0" on the PID still returns 0 (success) after 5 seconds; so the problem could also be related to rapid re-use of the PID...
<taylanub>hm, the line using kill is 'kill > /dev/null 2>&1 || exit 1' meaning the kill command itself does succeed, otherwise the script wouldn't continue (which it does)
<davexunit>I have never used xkbcomp, so I'm afraid that I can't answer your question. someone else here might know.
<mark_weaver>ryuslash: I've successfully used "setxkbmap -option ctrl:nocaps" to put the control key where it belongs, and I guess that "setxkbmap -keymap" or "setxkbmap -layout" might help, but since I use qwerty myself I haven't tried.
<ryuslash>would you also happen to know where the keymaps are stored on GSD? I've got a customized keymap and I don't know currently where to put it :)
<mark_weaver>almost everything is stored in immutable directories, so you can't just put it there.
<toxemicsquire4>mark_weaver: Sorry, but still not getting how to make a patch file. So I got my source tree that I got from git with my modified gnu/packages/python.scm, then I run "git format-patch", and after that "git commit -a", then "git format-patch -1", is that it?
<mark_weaver>better to figure out a way to have setxkbmap find it where you put it
<ryuslash>yeah, and there's no /usr/share or anything it seems
<davexunit>toxemicsquire4: commit first, then run 'git format-patch -1'