IRC channel logs


back to list of logs

<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>that was word salad...
<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.
<davexunit>if you want to see more details
<simonft>cool, thanks
***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...
<cehteh>how that?
<cehteh>configure? .. ah for building?
<cehteh>.. haskell ftw :D
<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>it does seem strange
<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>Hello Guix!
<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>dunno, i'm not an expert ;-)
<jmd>I'm not either.
<civodul>what i know is that mark_weaver wouldn't bother with a machine requiring non-free software
<amz3>héllo :)
<davexunit>ACTION pushed one container commit that got OK'd back in July but never pushed.
<civodul>davexunit: yay!
<civodul>we need containers!
<civodul>at some point we should look what it takes to retrofit user name spaces in the daemon
<davexunit>I want that.
***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>wwwwww: maybe check out
<davexunit>I haven't done bootstrapping or porting work, so I can't help further.
<civodul>core-updates is being built!
<civodul>howdy, paroneayea!
<paroneayea>hi civodul :)
<civodul>paroneayea: a couple of days ago you mentioned you might give a talk on Guix, no?
<paroneayea>civodul: I did mention it!
<civodul>you did!
<civodul>so, you're giving it?
<paroneayea>civodul: it'll be a talk at a small gnu/linux usergroup in chicago
<civodul>ah excellent
<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 :)
<civodul>that's a good sign :-)
<civodul>thanks for bothering them ;-)
<davexunit>cool :)
<paroneayea>ACTION playing with his json-ld implementation more this morning
<paroneayea>most things are rendering ok
<paroneayea>civodul: ld == linked data
<civodul>oh i see, didn't know that
<davexunit>I still don't understand it :)
<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"
<civodul>sounds interesting
<paroneayea>civodul: yeah
<civodul>ACTION has to rush
<davexunit>ACTION pushed a messed up commit, reverted it, and pushed a fixed one.
<davexunit>sorry for the noise in the log.
<davexunit>paroneayea: good read about issues with nixops
<davexunit>things we should avoid
<davexunit>we'll easily avoid the problem with a sqlite db by not using one :)
<davexunit>also this has some stuff about locking nixpkgs to a particular version in environment files:
<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>basically, it's good to follow r/nixos :)
<davexunit>furthermore, I'm constantly in awe of how over-engineered and complicated Chef makes things.
<davexunit>we can surely do better than this.
<paroneayea>davexunit: reading!
<paroneayea>davexunit: I agree re: we can do better
<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.
<paroneayea>davexunit: that's a good idea
<paroneayea>davexunit: I'll do that!
<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>some shell scripts + ssh
<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: maybe even guix scripts + ssh ;)
<davexunit>yeah, I think we can do that.
<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?
<paroneayea>assuming alists would probably be used
<davexunit>paroneayea: maybe something like that.
<davexunit>though checking in generated files to a git repo isn't exactly ideal to me.
<davexunit>but currently I have no better idea.
<davexunit>ideas welcome. :)
<davexunit>the answer is certainly not "centralized server"
<davexunit>p2p ops
<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
<paroneayea>there may be a hybrid approach
<paroneayea>bbiab tho
<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 is asking for username/password?
<taylanub>xanthippe: guest maybe?
<xanthippe>taylanub: no dice :/
<taylanub>xanthippe: apparently it's "anonymous"
<xanthippe>taylanub: turns out im being mitm
<xanthippe>thanks though!
<taylanub>no problem...
<Steap>Is Hydra about to die ?
<davexunit>Steap: it's building core-updates so it's very stressed
<Steap>oh right
<davexunit>we really need a powerful dedicated server for hydra
<xanthippe>should I not be installing guixsd now if hydra is stressed?
<davexunit>xanthippe: give it a shot anyway.
<davexunit>if you experience network issues, it's likely due to that.
<xanthippe>yea it's going quite slow
<boegel>bavier: ping?
<bavier>boegel: hi
<boegel>bavier: mind popping in to #easybuild?