<chipb>xentrac: yeah, it looks like you're fine in that the recent glibc used for guix (and indeed, current trunk glibc) actually supports the oldstable kernel version (3.2). I had to revert back to version 2.19.1 with --enable-kernel=2.6.18
<chipb>I'm pretty sure my instability arises from a compatibility mismatch between the guix libX11 and the X server I'm using.
<chipb>odd flaky hangs with graphical emacs (terminal mode doesn't exhibit issues that I've seen) and the local Xorg, and insta-crash of my NX sessions when I so much as launch graphical emacs in them.
<chipb>not really sure how to go about troubleshooting that sort of issue.
<chipb>ah, I guess I could ltrace to narrow down exactly when the NX crash occurs.
<yenda->if I want a quick and dirty solution to have clojure up and running before going further later what should I do to get the java cacerts in place ?
<yenda->I noticed that nss-certs are declared in the global packages in the config.scm so I guess I should def a package that copies the file in /etc/ssl/certs/java and sudo guix package -i java-certs ? or sudo guix system reconfigure config.scm after adding the package there ?
<yenda->mark_weaver: thanks, but how do I source a local file ?
<taylanub>yenda-: what exactly do you intend to do?
<yenda->taylanub: get a cacerts file copied in /etc/ssl/certs/java
<yenda->later compile the certs properly by doing a making a clean package definition for that but first I want to have something running properly
<taylanub>yenda-: installing a package will only ever change the contents of a "profile" directory; it can't just put files into /etc. that would be done with a "system" configuration I think, with which I have no experience so far.
<mark_weaver>taylanub: On GuixSD, /etc/ssl is a symlink to /run/current-system/profile/etc/ssl, so if yenda- installs a package with ./etc/ssl/certs/java in his system profile and reconfigures, it will be there.
<alezost>yenda-: I don't think that link may be fixed. IIUC it is automatically generated to be a reference to gnu.org/... The source of the manual are .texi files and they don't hardcode any urls. If you read the manual using info system (for example from Emacs), such links will open the proper info pages.
<amz3>yenda, davexunit I can't test it but I have it in a package (source "/path/to/source/")
<mark_weaver>regarding the icecat security updates: so far I've groveled through the mozilla source repository to find 17 patches on the esr38 branch, and 2 on the master branch, that need to be backported to esr31.
<davexunit>amz3: I had (source ".") in some of my dummy packages used only for 'guix environment' but they broke awhile back
<mark_weaver>the other option is to install guix on top of another distro (perhaps using our binary-installer) and then run "guix system init" from that system to create a fresh GuixSD system on another partition.
<guixnewbie>mark_weaver: Thanks! I think I'll give that a try.
<mark_weaver>bavier`: well, I've told people here before that I'm doubtful that it will work
<bavier`>but that's a use-case that's interesting to me in other areas
<mark_weaver>well, I agree, and it could be made to work, but I'm doubtful that it will work now.
<mark_weaver>so, you'll need to build everything from source, which is a lot
<bavier`>mark_weaver: I had to patch two things, and was then able to build guile
<mark_weaver>but the bigger problem is that you'll need to build everything from source outside of any chroot, which means that configure scripts will find things in /usr and probably try to use some of that stuff.
<davexunit>mark_weaver: I'll try to make it work I guess.
<davexunit>but I don't think asking people to use a glibc from october 2011 or after is asking much.
<mark_weaver>with a new enough kernel (>= 3.8), user namespaces could be used to make a build container, but that's not yet implemented in guix-daemon
<mark_weaver>davexunit: well, libc is not something that users can reasonably update. they have whatever they have.
<davexunit>I guess I need an eval-when or similar to avoid evaluating the forms that define setns and friends.
<mark_weaver>bavier`: the entire system can probably be made to work properly without isolated build environments, but it might be a lot of work, dunno.
<mark_weaver>running all of the builds in a build environment that has access to a host system in /usr etc is something that has seen essentially no testing.
<mark_weaver>I had suggested a different solution to civodul a while back, that would allow binary substitutes to still be used on systems where the store had to be in your home directory (for lack of root)
<bavier`>mark_weaver: how would that work? via grafting?
<mark_weaver>it would involve us changing the default store directory from /gnu/store to something longer, so that the builds could be grafted to contain the real store directory later.
<mark_weaver>but civodul seemed reluctant, and I didn't persue it further.
<mark_weaver>feel free to talk to him about it. I would be in favor of such a mechanism, fwiw.
<davexunit>it concerns me because I know our system is pretty solid, but living so close to the edge of such restrictive limits is very concerning to me.
<mark_weaver>we could increase the limit in our own copy of linux-libre, but of course that won't help users without root
<davexunit>or users using guix on top of another distro
<mark_weaver>bavier`: in the worst case, you could build guix on another box that you have root access to, and then run 'guix publish' on that box so that it can provide substitutes to your IT-dominated system.
<mark_weaver>or, perhaps, run guix within a virtual machine to do the builds.
<bavier`>mark_weaver: getting qemu up and running is actually one of the first things I want guix to help me with on this machine
<osmano807>I'm having a problem, if I uncomment the console-keymap-service, my grub.cfg becomes empty