<grothoff>Hi! I'm currently torturing my notebook with a Guix installation. Running into a few fun issues.
<grothoff>Got "unexpected EOF reading line" a few times, as well as hard DNS lookup failures. Both went away after I hardcoded the IPs of hydra and alpha into /etc/hosts. Before than, somehow DNS at Inria was 'too slow' and created timeouts that caused guix system init to fail hard.
<grothoff>Maybe the installer can do the DNS lookup once (also to check if Internet is working) and then store/cache the result in /etc/hosts for the rest of the installation?
<grothoff>Also, when I forgot a * after 'cons' in the config.scm, I just got "wrong number of arguments to cons()" from guix system init, no line number, nothing. Would be nice if we could have at least the line number...
<rekado_>the error is: checking if the VM and compiler work together... configure: error: Compiler failed to compile Java code.
<rekado_>we are using gcj+ecj as the bootstrap compiler and VM. Only ecj-bootstrap is a binary, but it should be portable, so I don't understand why the javac wrapper around gcj fails to compile Java code.
<Sleep_Walker>BTW FTR, I tried guix with LVM yesterday once again and proved that simply moving dev among filesystems initialized from initrd makes more mess and I should take the approach of separate base-filesystem service
<Sleep_Walker>my TODO list for guix is growing much faster than I'm able to find time :/
<Sleep_Walker>I also tried systemd-nspawn for running guix in separated namespaces but initrd is not ready for such case and fails when it has filesystem already mounted :b
<davexunit>the VM's host likely wouldn't be a guixsd machine.
<paroneayea>davexunit: do you think guixops might also be used for the case where guixsd is already installed on a machine, and more or less you want to ssh into all of those and update them to a certain state?
<civodul>and doesn't Chromium itself bundle a zillion of things as well?
<mark_weaver>actually, more generally, we need to look through all of our packages that aren't actively maintained, because some of them haven't had a release in years while security fixes have been gradually accumulated by the individual distros.
<mark_weaver>civodul: heh, yeah, probably so. I haven't looked carefully except to notice that the Qt tarball is absurdly huge.
<mark_weaver>I think the rationale from their perspective is so that they can test the entire integration of libraries, so there are fewer bug reports related to variations across platforms.
<mark_weaver>and of course for Windows and OS X, which have no package managers, it's standard practice for each application to bundle everything.
<mark_weaver>but the downsides are (1) that security fixes have to be applied in every application, and (2) that the multiple copies of shared libraries on disk translates to multiple copies of the libraries in RAM.
<mark_weaver>I think the practice it's *turrible*, as wingo might say.
<jackdaniel>lately I was wondering, why efl didn't got a strong camp
<jackdaniel>that're well developed libraries with nice and simple toolkit
<mark_weaver>I confess to being mostly ignorant of EFL, but I wonder what advantages it has over the GNOME platform that would justify dividing our attention and applications across yet another desktop platform.
<mark_weaver>noting also that the "GNOME platform" is distinct from "GNOME shell". XFCE is also based on the GNOME platform, for example.
<jackdaniel>hm, gnome is a bloat primarily. Anyway EFL devs care to keep library suitable for both high-end machines (it looks marvelous) and old crap w/o gfx - what looks little worse
<mark_weaver>since each desktop application must choose a platform to base itself on, there is a significant cost to having "too many" platforms. it squanders our development time building duplicate applications for each platform, and meanwhile the proprietary platforms are winning.
<mark_weaver>so, IMO, a brand new platform really needs to justify its existence
<jackdaniel>yeah, but efl is pretty mature (not sure if not older then gtk)
<taylanub>xaxes`: you can start by copying another recipe, such as the example recipe in the manual. feel free to ask for help in here and in the mailing list. ultimately you can send a patch to the mailing list created with "git format-patch", after making a commit in the usual style (see other commits that add package recipes)