<simonft>davexunit: what actually has to be done for a distribution to work in a container? I don't know quite enough about namespaces to figure this out. <davexunit>simonft: not that much for the server use-case. <davexunit>you need to a few special things to setup things like /dev/console, /sys, /proc <davexunit>you need to setup a few special things like /dev/console, /sys, /proc <davexunit>the basic implementation, call-with-container, is in master, actually. ***necronian_ is now known as necronian
***mark-otaris is now known as mark_otaris
***vezzy is now known as quasinoxen
<bavier>this is a bit crazy, git-annex is using upwards of 6GB of RAM just to configure itself... <bavier>cehteh: yes, "Configuring git-annex..." <bavier>eventually killed it after 7.5GB and still no sign of progress <cehteh>i've once build it, but thats long ago, cant remember such behaviour <cehteh>haskell eats memory a lot .. but 7.5G sounds even excessive for haskell <bavier>hmm.. with 'cabal install git-annex' it seems to configure in a matter of seconds ***wailord is now known as marmoset
***marmoset is now known as wailord
<civodul>iyzsong: so, i'm tempted to revert that libtasn1 upgrade and get the branch built <civodul>we can always upgrade it later, once things have settled <jmd>Is guix now bootable on the Lemote ? <civodul>jmd: not all the changes are in master yet, but wip-loongson2f has everything AFAIK <jmd>I thought that loongson was the non-free one. <civodul>unless i'm mistaken, loongson designates the CPU family <jmd>I should have expressed that better. <jmd>I thought that the only machines sold with the loongson CPU needed non-free drivers to operate some of their hardware. <civodul>hmm i think the Lemote Yeelong already had a loongson, no? <civodul>what i know is that mark_weaver wouldn't bother with a machine requiring non-free software <davexunit>ACTION pushed one container commit that got OK'd back in July but never pushed. <civodul>at some point we should look what it takes to retrofit user name spaces in the daemon ***davi_ is now known as Guest12199
<wwwwww>Is there any kind of description how to bootstrap Guix with a new toolchain and build packages? For example imagine that I would like to use the reproducible packages of Debian in the Guix system. <davexunit>wwwwww: this needs some clarification. Guix also offers build reproducibility, though it's a work in progress just like Debian. <wwwwww>Yes, it needs some clarification ... <taylanub>do you mean you would like to use Debian's build toolchain as the bootstrap component for a new tree of Guix packages? (AFAIUI that would make your tree of packages hash-incompatible with the binary substitutes on Hydra) <wwwwww>... that waas only a bad example ... <wwwwww>... I would like to build other free operating systems with Guix ... <wwwwww>... but I used for my question above this bad example ... <davexunit>do you mean using guix to build packages for other distros? <wwwwww>... My task is to get FreeBSD built with Guix. I need some startting point to replace the toolchain/buildsyste/whatever of Guix <davexunit>I haven't done bootstrapping or porting work, so I can't help further. <civodul>paroneayea: a couple of days ago you mentioned you might give a talk on Guix, no? <paroneayea>civodul: it'll be a talk at a small gnu/linux usergroup in chicago <paroneayea>civodul: yeah, nothing big and fancy, but there will probably be about 20 people there. I'm going through town and a number of people there heard me talk about guix enough <paroneayea>that they were interested in hearing me give a talk :) <paroneayea>ACTION playing with his json-ld implementation more this morning <paroneayea>basically it allows you to add types and vocabulary <paroneayea>and transform a document from elsewhere into a format where you are sure you know what the terms actually mean <paroneayea>so imagine a big federated network, and you're consuming a lot of activities on the federated network <civodul>sort-of "hyperdata" (in comparison with "hypertext") <paroneayea>you don't want to consume data where you meant "run" as in "run a program" and they meant "run" as in "run a mile" <davexunit>ACTION pushed a messed up commit, reverted it, and pushed a fixed one. <davexunit>we'll easily avoid the problem with a sqlite db by not using one :) <davexunit>wingo desired such a feature for guix itself <davexunit>since the result of the environment depends on the version of guix used to build it. <davexunit>furthermore, I'm constantly in awe of how over-engineered and complicated Chef makes things. <davexunit>in a nutshell: we need to provide a way to do distributed ops stuff. <paroneayea>davexunit: so in a month I need to start working on getting a deployment system in place that's "good enough" to do our "premium hosting" promise for mediagoblin from the last campaign <paroneayea>davexunit: so I guess I'll be simultaneously looking at nix and guix <paroneayea>davexunit: my hope is I can get it up and running without toooooo many yaks to shave with guix <paroneayea>but if it turns out that there's too much to package and yak-shave, I'll do nix for now and use it as "lessons learned" to eventually migrate to guixops. <davexunit>paroneayea: you should write up some requirements for guix-devel and we can see what we can do. <davexunit>I don't expect 'guix deploy' to be good enough at that point, but I do think we can get all the needed guix packages and services written. <davexunit>so that you can manage the server without much fuss <paroneayea>davexunit: we might be able to build hacky workarounds for guix deploy <paroneayea>davexunit: it might be good enough to start with <paroneayea>davexunit: as long as I can have a reasonably easy way to start up remote servers <paroneayea>davexunit: if we store everything in scheme rather than sqlite <paroneayea>davexunit: would we want to sort the alists and pprint them so they can be moderately diffable in some git log? <davexunit>though checking in generated files to a git repo isn't exactly ideal to me. <davexunit>the answer is certainly not "centralized server" <paroneayea>davexunit: so honestly, I envision two ways of going about managing servers <paroneayea>one is writing the sexps myself, which is probably okay actually! that's how it is working with a lot of ansible type stuff <paroneayea>the other one is having a tool which writes them for me <davexunit>the state I can think of is all stuff that is fed back to us from the software that manages the systems: the instance's IP address and stuff. ***sepi``` is now known as sepi
<xanthippe>ftp alpha.gnu.org is asking for username/password? <davexunit>Steap: it's building core-updates so it's very stressed <davexunit>we really need a powerful dedicated server for hydra <xanthippe>should I not be installing guixsd now if hydra is stressed? <davexunit>if you experience network issues, it's likely due to that. <boegel>bavier: mind popping in to #easybuild?