<mark_weaver>just checkout the git repo as your normal user, make the change (revert the offending commit, ideally), then "./bootstrap && ./configure --prefix= --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) && make"
*civodul makes suggestions, then goes afk for a while :-)
<rekado_>civodul: a "grep" helper that runs over a file line by line and returns #t when found seems generally useful. Instead of adding this to my IcedTea package as a local function could I add it to build/utils.scm instead?
<bavier`>rekado_: there's fold-port-matches in (guix build utils), does that do what you need?
<DusXMT>I''m trying to build a very simple initrd for my system: No modules, only ext2fs tools, and only mount the root drive and boot from that... but I'm failing for some reason. I don't understand where the error is now...
<taylanub>leaving aside the whole 'promoting "GNU systems" over "Linux distros"' talk though, I'm worried about RMS's apparently firm stance against the "GSD" acronym :\\
<civodul>toothbrush0: it's like all taxes: once it starts working, you can't resist and end up extending it!
<jgrant>I mean, I don't get the fear. Mention "GNU GSD" en massse. Don't give people the chance to misassociate.
<jgrant>It's like people who think the G in the GPL is GNU, when if someone said the "GNU GPL" (which is it's proper and formal title) it eliminates this possiblility practically.
*jgrant will brb, feel free to respond he'll check the log. Wants to see if the kernel revisions in master fixed his issue to boot because of USB -- yesterday, or he still needs to file a formal bug report. o/
<jgrant>THe issue is too, I don't know if this is just something to do with my hardware or something tied to other factors/people as well. BUt since the actual GSD install base is so small currently, who knows? I certainly don't.
<jgrant>Like I don't know if I should file a formal bug for this, or revert a patch locally and leave it be.
<jgrant>DusXMT: Since the USB autoloading patch yesterday for initd, I have rebuilt my config and all revisionary configurations past that of my initial working config -- now have an issue where at boot it says a systemlink is missing, tries to open a guile prompt, and then I get a whole bunch of calltraces for USB stuff.
<jgrant>DusXMT: Currently, via the method I mentioned. I assume I don't have sda2 set as "boot" and that's whyI've been doing this way. Have parabola install cd in drive, use parabola's grub from said cd to boot from the existing os, then it takes you to GSD's grub and it's "all good" from there.
<jgrant>Okay, the good news is that enabling the boot partition -- as I suspected, works now without having a cd in my diskdrive! The eh news, is it's still the same in that any reivison of my config past the initially provided, doesn't work still. :^P
<jgrant>So, guessing it has nothing to do with the boot method, but has something to do with either my device and/or the patch itself.
<jgrant>I'm probally not going to bugger much with it today, since assumingly based on the ML it lookt like 0.8.1 is going to get released tommorow at some point -- and I'll just go from there. :^P
<civodul>jgrant: do you still have the USB problem?
<civodul>could you post precise details of what's going on at boot time?
<civodul>i tested the change with those USB machines on two machines, FWIW
<jgrant>civodul: The only thing that I can see during boottime, is that there's a complaint of a missing syslink, then the prompt for guile tries to open, then a whole bunch of usb calltraces come back. Is there a way to store this bootup phase, somewhere? That's a lot to transcribe. Most of it is general calltrace complaints though (after guile's prompt attempts to load). Right before said prompt, is that missing symlink e
<mark_weaver>actually, I'm running low on disk space, so I might try that myself soon.
<mark_weaver>civodul: btw, in general, 'autoconf' phases should be put after 'unpack' instead of before 'configure', becuase otherwise the 'patch-usr-bin-file' phase doesn't fix the problems in configure and things will fail on MIPS and ARM.
*jgrant just did so, going to reboot and check what happened.
*mark_weaver fixes that problem in the guile-ssh package
<xjgrant>I hate this laptop, for a number of reason... But I try not to punch gift horses that much.
<xjgrant>As in, it was literally a 700$ gift from my parents.
<davexunit>civodul: thanks, I hope to revisit it some day and make the package list work more like guix.el
<davexunit>so you can mark many things for installation/upgrade/removal
<xjgrant>Worse comes to worst, Ill go forward with my inital plan to reinstall GSD as of the release of 0.8.1. In any case, this has been a helpful excercise to get me a bit more familiar with some general workings of Guix.
<mark_weaver>civodul: fwiw, in general, I don't think we should remove a platform from 'supported-systems' just because it doesn't build currently, unless it seems almost hopeless. (racket comes to mind)
<toothbrush0>mine's on github, but it's embarrassingly close to the doc-example
<jgrant>toothbrush0: Mines actually pretty close to the doc's too. Most of the actual work I've done formally, has been trying to get my packages to line up to what I was used to on my Fedora install. It's probably going to morph to into something relatively different relatively fast as this is now my day-to-day driver (GSD is on my main laptop) ... but, this is what I have thusfar. http://paste.lisp.org/display/145439
<mark_weaver>I agree that having the set of user packages in some kind of configuration file would be a nice option to have.
<toothbrush0>i like the idea of having my installed software trackable somehow... as in, should i ever need to do a fresh install i won't find myself going "oh yeah i still need that package" a week later
<jgrant>mark_weaver: Yeah, I think your perefered method is better -- I just don't think it's worth the effort until we get somefactor of "guix user" system in place to split my config/workflow in such a way.
<jgrant>toothbrush0: Instead of "guix system reconfigure" that deals with the whole store and system config -- you'd be able to do per-user configurations in the same way you'd be able to manage the system's config.