<mark_weaver>the reason sneek responded to the earlier message is because it ended with the word "soon", which sneek thinks is an alias for his own name. <daviid>that's why thay we are totally crazy [s/w eng] :) <lfam>Is there a recommended way to prevent compilation of Guix packages from leaving a remote system completely unresponsive? Like, could I tell systemd to adjust the nice-level of guix-daemon.service? <lfam>Does all the compilation stay within that process hierarchy? <lfam>Ideally, I could get binary substitutes from hydra, but it would also be good to able to run Guix on these dinky little ARM boards <antiatom>If I wanted to mirror all of GuixSD, how much space would this take? <lfam>Looks like yes, so I'm going to try to limit the CPU usage with cgroups <davexunit>antiatom: I don't know even a good estimate because things get added all the time, but on our donation page we are asking for 1TiB of disk for each build machine <antiatom>Okay but not for mirror, for a build machine <davexunit>so, here's the thing: we're not like debian in that someone can just mirror some files on a web server. <adhoc>davexunit: the main issue with that is the source packages are on servers that aren't reliable <adhoc>so a mirror would be really useful <davexunit>if you use hydra.gnu.org for substitutes, you already get source tarballs from there, too. <adhoc>when i tried to build stuff, it failed, it didn't fall back <davexunit>the way to "mirror" guix is to setup your own guix system and build *everything* <davexunit>and when building, you can take advantage of the fact that hydra.gnu.org has already built most everything and guix will just download the binaries <davexunit>adhoc: then it must have been something that there wasn't a substitute available for <davexunit>either it can be substituted or it can't. if it can't, it builds from source, and in the case source tarballs that means running a script that fetches it and verifies the sha256 hash <davexunit>and if the upstream source URL is broken, then you'd get a broken build. <adhoc>davexunit: yes, the build failed to pull the source package <adhoc>davexunit: and yes there was a binary package on hydra <adhoc>but that kind defeats the reproducability(sp?) of it all <adhoc>would be nice to cache all the packages you want to build from before building... ? <davexunit>I don't follow. we have all of the tarballs cached on hydra.gnu.org <adhoc>but if you can't pull the source from the reomte site(not hyrda), you pull the binrary package from hydra, not the source? <adhoc>guix will pull the source package from hyrda ? <davexunit>it's unlikely that this particular scenario would happen, because if guix has the source tarball, it likely already has the binary. so if you say 'guix package -iguile' it will just download the pre-built guile ***y is now known as init
***davi_ is now known as Guest76721
<rekado->How can I fix this dbus error? "The name ca.desrt.dconf was not provided by any .service files" <remi`bd>a new `guix graph` command, this is awesome! <remi`bd>oh, I did not know about (package (inherit foo) …) <remi`bd>can’t find documentation for this feature… <alezost>that wasn't a big help I suppose :-) <rekado_>not even the first release of maven can be built without tons of third-party stuff. <rekado_>it's not even clear which of these libs are required and which are optional. <rekado_>There is a drop-in replacement for maven 2 called buildr, which is written in Ruby... <rekado_>if this is easier to build I'll try to build the dependencies of maven with buildr. <davexunit>does anyone successfully use emacs in lxterminal? <davexunit>it just doesn't want to listen to meta commands <davexunit>the answer was to switch to gnome-terminal :) <rekado_>coveralls --> simplecov --> docile --> coveralls <rekado_>another dependency cycle in the ruby world. <davexunit>once you want to run test suites, there's cycles everywhere. <davexunit>my strategy: don't run tests on testing frameworks <rekado_>for coveralls simplecov is listed as a "runtime dependency", and docile is a runtime input of simplecov. <rekado_>it seems that docile only uses coveralls for tests, though, so I'd have to disable tests there to break the cycle <davexunit>rekado_: welcome to my world. I started this journey young, naive, and optimistic. now I am old, jaded, and bitter. <davexunit>it must be some sort of dark comedy that the people that developed these systems think they've improved things <davexunit>I imagine this is the source of Moore's Law? <ifur>davexunit: surprisingly good read :) ***davi_ is now known as Guest87964
<rekado_>what I find especially frustrating, though, is that I only entered this mess of ruby cycles to break a cycle in the Java world... <ifur>this is generally the main motivator to using Lua :) <davexunit>you went down a rabbit hole within a rabbit hole. <ifur>all you need is an ansi C compiler <ifur>rule of frameworks #1 use the same distro/dependencies as the developers #2 don't talk about rule #1 <davexunit>rekado_: happy to see you packaging gems. we need more more more <davexunit>Guix can create the relevant Heat configs to pass to OpenStack and it will create the stuff you asked for. <ifur>every major contributor have their own fork of openstack, and has largely given up on getting "their" improvements into openstack proper. Instead they makre sure its the crappiest eimplemention that wins <ifur>as most "software by comittee" projects do <ifur>so unless you prefer things like keeplived over corosync/pacemaker, go with openstack -- otherwise by a forked version <davexunit>I'm interested in writing clients for free software private clouds so that we can run Guix on them. the cloud sucks, but when its a cloud that you control, it's a nice abstraction. <ifur>its also not really possible to fix openstack, you *HAVE* to fork the compenents <davexunit>OpenStack and Eucalyptus are the ones that immediately come to mind. I don't know any others. <ifur>davexunit: Synnefo+ganeti+ceph is what the kids that get things to work in bioinformatics use <ifur>greece has a national cloud provider for bioinformatics using that <ifur>ganeti used to be an official google project, but not anymore <ifur>and in more recent versions they have introduced a lot of haskell parts <ifur>but the core is still python <ifur>ganeti gives you everything that you'd expected of a clustered virtualization cloud (as in fault tolerance) <ifur>openstack provides ZERO fault tolerance out of the box <ifur>ganeti essentially replaced libvirt in openstack <ifur>but since ganeti is clustered, most of the gunk openstack puts ontop of libvirt is not needed <ifur>and its a mature project to boot <ifur>synnefo adds a storage layer (for sharing data between users) and a federation layer <ifur>S3 and Swift is provided by ceph mostly <ifur>license could be better :) <davexunit>rekado_: I'm going to review those ruby patches later, but the first thing I noticed is that you duplicated the 'bundler' package as 'ruby-bundler' <davexunit>one could argue that this package should be renamed. not sure, though. <ifur>my irc client crashed it seems <rekado->davexunit: no, I think I added *builder* not *bundler*. <rekado->on my system I still connect to the network like a caveman: ip link set <name> up; dhclient <name> <rekado->I do this because the networking service never succeeds. <rekado->wicd doesn't work because it fails to connect to dbus. <rekado->which is probably because networking isn't running. <rekado->I'd like to know why "networking" fails consistently. <rekado->probably trying to create some existing file after an unclean shut down, or something like that. <DusXMT>I wonder, from where do variables like a user's path get set in GuixSD? <DusXMT>davexunit: that doesn't set things like the path to a user's profile's bin, yet it somehow gets set on login... <DusXMT>mark_weaver: but that only contains (by default, at least on my freshly-installed system) a single line to load up bashrc... <davexunit>yeah you're right, it just sets the current-system path <mark_weaver>DusXMT: indeed, sorry for the confusion. davexunit was right <mark_weaver>although /etc/profile actually tries to load $HOME/.guix-profile/etc/profile first, and if that fails, then it sets PATH. <davexunit>lol just realized that I was talking to the wrong channel up there <DusXMT>Does anyone else experience a segfault whenever you try to do "ls -l"? Without the -l, it works... <codemac>nope - not here. what version of ls are you using? <codemac>same here.. can you paste the backtrace somewhere? <DusXMT>hmmm, if I can figure out how... <codemac>it will segfault, and then type 't a a bt' or "thread apply all backtrace" <codemac>Though, I bet guix strips binaries, so it may not be super helpful <DusXMT>Looks like I have to install icecat... but in the meantime, it seems to be a buffer overflow, it happens in __strcpy_ia32 (), which is called by align_nstrftime.constprop () <davexunit>it's pretty easy to modify packages to build with debugging symbols <DusXMT>yeah, hopefully I'll eventually get to it, but it might take a while, so much setting up to do... <mark_weaver>DusXMT: do you have LD_LIBRARY_PATH set in the environment that calls 'ls' ? <codemac>DusXMT: if you do a info locals or anything like that and see where the null / bad pointer is? <codemac>because this is pretty bizarre to be getting in coreutils on a specific system <codemac>did you build this version of coreutils locally? <DusXMT>codemac: No, I downloaded it as a substitute from hydra ***init is now known as exio4
<DusXMT>codemac: no symbol table info available... and I unfortunately have a bit to do before I can really start looking into it