IRC channel logs

<absorto>ah! I see... thanks!

<davexunit>woo, guix containers no longer require that the user create a special directory before running them

<davexunit>the container directory is created via mkdtemp and a tmpfs is mounted there

<davexunit>now they are totally ephemeral :)

<ewemoa>davexunit: so how does one try this out?

<ewemoa>amz3: was able to get hostapd running on a guix sd machine -- now got to get the service part working...

<davexunit>ewemoa: there's a special wip-container branch

<davexunit>things arent' particularly usable yet

<davexunit>especially given that I'm having some troubles with user namespaces.

<ewemoa>davexunit: ah -- good luck with further work :)

<davexunit>simple stuff works, like creating a container for a 'guix environment' call

<davexunit>full guixsd systems pose further issues

<davexunit>from what I've read, I think we'll need a special setuid program to create the containers

<davexunit>so that more than 1 uid/gid can be mapped from the container to the host

<davexunit>guixsd containers fail due to this limitation right now.

*davexunit sends another documentation patch to libcontainer

*davexunit goes to sleep

<mark_weaver>efraim: the time advantage of 'git pull' vs 'guix pull' is not something you would notice the first time you build from git, where you have to build the whole thing.

<mark_weaver>the advantage is when you update, and only have a compile the files that actually changed since the last build.

<mark_weaver>s/have a/have to/

<mark_weaver>in that case, the speed advantage is so vast that you would never need to time it to see the difference. we are talking on the order of a few seconds typically to update via git.

<mark_weaver>to run 'make' after git pull, I mean.

<mark_weaver>the only caveat is that every once in a while, you need to "make clean-go && make" because we change some macro, and our Makefiles don't include the necessary dependencies to handle those cases properly.

<mark_weaver>amd tjat

<mark_weaver>and that's the reason that we can't simply use this technique in 'guix pull'.

<zacts>wait, which mailing list should I check for guix commits?

<zacts>namely, if there was a commit for the guix systemd init service patch?

<mark_weaver>sneek: later tell absorto: the reason your attempt to configure the network with a static IP didn't work is because you didn't set the default gateway router.

<sneek>Got it.

<mark_weaver>zacts: you might find it easier to use the cgit web interface: http://git.savannah.gnu.org/cgit/guix.git

<zacts>mark_weaver: oh, yes that does make sense

<zacts>git log

*zacts often over-complicates stuff

<mark_weaver>but fyi, the commit notification email list is here: https://lists.gnu.org/mailman/listinfo/guix-commits

<zacts>oh neat cool

<zacts>I think I was confused between a couple of the listed ML

<zacts>(as this patch seemed so trivial)

<zacts>my apologies, I had a long day

<mark_weaver>or if you have a local git checkout, you can use 'git log' or in emacs, starting from within the git checkout: C-x v L

<zacts>indeed

<ewemoa>i have a preliminary package for hostapd -- i'd like to have it start after (during?) boot...i presume specifying a service is part of what's necessary, but also have a bridge configured appropriately. is there some existing service that does something similar?

<codemac>anyone use dmd with services that always daemonize themselves?

<codemac>I'm trying to write a (make <service> ...) for gpg-agent, but gpg-agent calls --daemon, and I'm not sure it works

<codemac>does dmd track the pid correctly if I just use (make-forkexec-constructor) like most everything else? or is there something else I should do?

<civodul>Hello Guix!

<codemac>hello civodul! I just asked a question about dmd if you had time

*civodul looks at the log

<civodul>codemac: you should arrange to not call gpg-agent with --daemon

<civodul>that is, make-forkexec-constructor captures the PID of its direct child, that's it

<civodul>so if said child forks again (as with --daemon), you're screwed

<civodul>well, if it forks, you have to handle it differently

<civodul>we do that for dhclient, for instance

<codemac>hm ok. I can track it with a cgroup, but I don't know the opinions about dmd using linux specific features. for now I could see if the --server option does what I want on gpg-agent.

<codemac>and thanks to dmd using all this scheme, I can always write my own wrapping shenanigans regardless! hurrah guile :)

<codemac>or I guess running without --daemon suffices according to the man page

<codemac>thanks for the comments civodul

<codemac>aha! gpg-agent --daemon --no-detach works

<civodul>perfect :-)

<civodul>codemac: now, what would the gpg-agent service look like?

<civodul>i run it as my own unprivileged user

<civodul>so it's normally not something dmd would do for me

<civodul>although it's not hard to make a service that would take a user name as an argument, and switch to that uid

<rekado_>civodul: I can take care of the Rhythmbox review later today.

<civodul>rekado_: cool, thanks

<amz3>ewemoa: nice, you want to use guix to create a router?

<amz3>ewemoa: look at dmd documentation or dmd in guix's logs they are several people working on services

<amz3>héllo all :)

<amz3>I'm using rhythmbox, it works I mean, once dconf is installed it works perfectly

<amz3>(plus maybe some gstreamer issue as discussed in the ML for totem)

<amz3>also I think it requires to logout/login

<amz3>not sure about that

<rekado_>"also I think it requires to logout/login" <--- what does that mean? It does not work right after installation?

<amz3>totem was buggy before login/logout

<amz3>rhythmbox was ok, but did store config as execpected without dconf

<amz3>I was saying, that you can try to login/logout to "fix bugs" if you have some

<amz3>this is totem that was buggy, but when totem was ok, rhythmbox was ok too. sorry if its misleading

<rekado_>ok.

<ewemoa>amz3: yes, want to try guix sd for a router -- thanks for the tips

<civodul>remi`bd: just read your report: very nice, thanks!

<civodul>i'll try to setup a peer and give it a try later today

<civodul>remi`bd: dunno if you're familiar with the autotools, but maybe you could copy configure.ac and Makefile.am from guix/dhcp.git and adjust them for your project

<civodul>even without being an expert, that should be OK

<remi`bd>I’ll have a look

<remi`bd>thanks!

<remi`bd>oh, I had a little question

<remi`bd>I ran into some trouble with sizeof, last week

<civodul>oh?

<remi`bd>it seems like this commit is not in the Guile used by Guix

<remi`bd> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=cff1d39b2003470b5dcdab988e279587ae2eed8c

<remi`bd>(sizeof (list '* uint8)) ⇒ 9

<remi`bd>where it returns 12 or 16 with this commit (depending on (sizeof '*))

<remi`bd>(guile 2.0.11, 2014)

<civodul>remi`bd: ooh, this is weird because this commit is much older

<civodul>remi`bd: where did you find this commit, which branch?

<remi`bd>I found it through the search

<civodul>interesting, it's neither in stable-2.0 nor in master

<civodul>anyway, you'll have to work around it for now

<remi`bd>yes

<civodul>i've cherry-picked the commit in stable-2.0

<civodul>davexunit: wip-container seems to be getting close to merging, no?

<davexunit>civodul: needs a few more things

<davexunit>civodul: I think we're going to need a setuid root utility to assist with unprivileged container creation.

<davexunit>the other issue is I need to figure out how to allow for interactive container processes and inserting processes into a container.

<davexunit>but we're getting there.

<davexunit>oh another thing I was trying out was the use of pivot_root instead of chroot to more effectively jail the container process.

<davexunit>since the chroot can be escaped, but I haven't figured out how to use pivot_root correctly yet.

<civodul>davexunit: there was a commit that does that in Nix

<davexunit>civodul: oh I'll need to find that

<civodul>maybe we could have a simple daemon that listens on a Unix-domain socket and creates containers on behalf of the caller, for a pre-defined set of authorized users

<davexunit>civodul: I'm not sure we need a pre-defined set of authorized users, because the containers themselves can have dropped privileges

<civodul>right

<davexunit>but then again I'm still confused some aspects of user namespace

<civodul>ok

<davexunit>because it's impossible to map many users within the namespace to a single user outside

<civodul>it has to be a one-to-one mapping?

<davexunit>yes

<davexunit>because it's a 1-1 mapping, an unprivileged user can *only* map their own uid/gid

<davexunit>so right now guix containers are restricted to a single user

<davexunit>and the guixsd boot script fails accordingly

<civodul>except if you run it as root, i guess?

<davexunit>yeah

<davexunit>a user with setuid/setgid capabilities

<civodul>well, it's Linux, no big surprise ;-)

<davexunit>yeah

<davexunit>I'm starting to feel the snark

<civodul>heh

<davexunit>I was hoping to avoid a daemon, but it will be necessary it seems.

<davexunit>from reading criticisms about docker, people don't like having to go through the daemon for everything.

<davexunit>and other container tools require no daemon

<davexunit>but I imagine they require root privileges

<civodul>i guess it's either a setuid helper or a daemon

<davexunit>civodul: yeah

<davexunit>I suppose I lean towards a daemon because it's more flexible

<civodul>yes

<davexunit>and in the future I can see this daemon being the basis for a new, pure Guile build daemon.

<civodul>definitely

<davexunit>so might as well go with a daemon that speaks sexps over a unix domain socket.

<civodul>yes, and we could easily deploy it on GuixSD anyway

<davexunit>with a daemon we get other advantages, like being able to keep track of all container pids

<davexunit>or associating names with containers

<civodul>"docker ps"

<davexunit>yes

<davexunit>exactly

<davexunit>and "docker exec"

<civodul>right

<davexunit>and other stuff that can come later

<davexunit>cgroup support is a must-have

<davexunit>but it can wait

<civodul>right, and cgroup is meant to be managed by a single process, AIUI

<davexunit>systemd and docker get along, somehow.

<civodul>which is called "systemd" in some distros

<civodul>heh

<davexunit>docker searches the mount points to find all the cgroup mount points

<davexunit>so I imagine we can do the same.

<davexunit>find them, don't create them.

<davexunit>and add our own hierarchy within each.

<davexunit>/sys/fs/cgroup/memory/guix

<davexunit>etc.

<civodul>yeah, dunno

<civodul>dmd would happily use cgroups

<civodul>so perhaps it'll have to provide a cgroup manager

<davexunit>not sure. it seems we can do it independently.

<civodul>ok

<davexunit>of course, dmd could do its own thing, but 'guix container' could find and take advantage of the system provided cgroups.

<civodul>i see

<davexunit>I guess we'll see how it plays out.

<davexunit>if we can get the basics working decently, we'll get it in master and maybe someone will see the release notes and be motivated to contribute improvements.

<civodul>good strategy :-)

<civodul>i was thinking that a first milestone could be container support without the helper daemon

<civodul>as a "technology preview", as they call it

<davexunit>yeah

<davexunit>we'll have to limit it to being run as root

<civodul>yes

<davexunit>sounds good

<civodul>and the 2nd milestone would be the helper daemon/setuid program

<davexunit>I just want to figure out pivot_root and interactive processes first

<davexunit>then we can get it in

<civodul>yes, np, take the time it needs

<civodul>i did not mean to pressure you

<rekado_>davexunit: re rubygems and the problem of "equivalent source" --- after writing my message about this I no longer feel badly about using gems as published on rubygems.org. Was there some other concern I'm forgetting?

<davexunit>rekado_: I think you've convinced me that it's okay.

<davexunit>;)

<davexunit>the ruby build system will have to extract the gem to run the test suite and stuff

<davexunit>and then run gem install on the originally downloaded gem

<davexunit>weird but it should work

<davexunit>I have to write my thoughts on the list

<davexunit>I will yield to rubygems.org, but I am very opposed to some of things pjotr is trying to do.

<davexunit>I know he means well, so I hope I can get it sorted out so we're both on the same page.

<rekado_>"I am very opposed to some of things pjotr is trying to do" <-- so am I.

<davexunit>for example, bundling extra gems in a single build instead of just making the guix packages

<rekado_>I don't want to give in to poor solutions for the sake of adoption.

<davexunit>exactly.

<davexunit>I can already use the 'gem' and 'bundler' tools on my guixsd systems just fine

<davexunit>without using any of the guix packages for ruby libraries

<rekado_>right.

<davexunit>though the issue of installing a ruby library that includes binaries needs to get solved.

<davexunit>I'm not too into writing wrapper scripts like the python build system does.

<davexunit>I'd rather just propagate the ruby interpreter.

<davexunit>though that has to be specified for each project rather than happening automatically, so maybe we need something else.

<rekado_>how does propagating the ruby interpreter help here?

<davexunit>rekado_: it means that ruby will be in their profile

<rekado_>we only use wrapper scripts with python to set PYTHONPATH.

<davexunit>thus they get the search paths

<rekado_>oh, I see.

<davexunit>yeah, we could do the same to set GEM_PATH

<davexunit>not sure if we should

<rekado_>propagating ruby makes it impossible to have two applications installed that happen to use different versions of ruby.

<davexunit>rekado_: that would cause all sorts of problems anyway

<davexunit>ruby has no concept of a RUNPATH

<davexunit>so we propagate all ruby library inputs

<rekado_>we don't do this for Python executables, though. As long as we wrap the executable with a PYTHONPATH containing the paths of all required modules it will just work. Even without propagation.

<davexunit>and since some ruby libraries have native extensions, the version of ruby used to build that library is very important.

<rekado_>(Or am I missing something again?)

<davexunit>rekado_: well maybe I need to re-do all of this to be like python.

<rekado_>well, it's not like the way we do it for Python executables is convenient (wrapping is messy), but it does seem to work.

<davexunit>I guess what I need is some help with it from someone else interested in Ruby.

<davexunit>I'm getting burnt out trying to make this sane.

<rekado_>davexunit: I cannot promise anything (these days especially), but I'm somewhat interested in getting this to work. Is your latest work in master or in some other branch?

<davexunit>rekado_: it's all in master

<rekado_>okay.

<rekado_>I'll try to take a look some time this weekend.

<davexunit>pjotr seems to be working on a new ruby build system

<rekado_>oh.

<rekado_>is pjotr on IRC some timesL

<davexunit>rekado_: I don't know how you find so much time for this stuff. you're a machine. :)

<rekado_>?

<davexunit>pretty much never

<rekado_>heh, I wish.

<davexunit>we'll just have to follow up on the list

<rekado_>okay.

<rekado_>I think we need to update all packages with input gfortran-4.8. Most of them are in maths.scm.

<rekado_>Otherwise I expect incompatibilities when these packages are built with GCC 4.9.

<civodul>indeed

<mark_weaver>we are ending up with the current compiler version hardcoded in several places, and they all have to be updated when we switch our default compiler.

<mark_weaver>this seems suboptimal to me.

<mark_weaver>I think we should have some variable names that mean "the default gcc", or "the default gfortran", etc, no?

<mark_weaver>we have that for all other packages :)

<mark_weaver>that's actually the reason I used 'gcc-final' from commencement for ocaml, but then civodul changed it.

<mark_weaver>anyway, I have to go afk for a while. happy hacking!

<civodul>mark_weaver: agreed, we should have (define gcc gcc-4.9) or similar

<civodul>we must still use (canonical-package gcc) instead of gcc-final though

<bavier`>I'm working on a few more packages that use gfortran, and I was wondering about the upgrade path

<bavier`>I agree with mark_weaver about a "default gfortran" variable

<civodul>the first one who submits the patch wins!

<mthl>civodul: every challenge needs a prize, what do you offer? ;)

<rekado_>as far as I can tell we really just need this:

<rekado_>(define-public gcc gcc-4.9)

<rekado_>(define-public gfortran (custom-gcc gcc "gfortran" '("fortran")))

<rekado_>and then change all gfortran-version inputs to gfortran.

<civodul>rekado_ is about to win!

<rekado_>should this all be one commit?

<civodul>yes, and then a second one that updates all the hard-coded references

<rekado_>patch sent. I hope this is okay. (I haven't waited for everything to be rebuilt.)

<civodul>normally no rebuild happens

<civodul>well, except for those who were referring to 4.8 instead of 4.9, for instance

<rekado_>only R used 4.9. All other packages were on gfortran-4.8.

<bavier`>rekado: thanks for the patch

<civodul>yes, perfect!

<knivsta>would guix be ready for consumer use?

<knivsta>Whom is it intended for?

<knivsta>Emacs of the distro is a bit scary for newbies

<efraim>in a sense, other than not having 20k+ packages, the main thing guix is missing for newbies is a nice installer and a gui for updates

<davexunit>knivsta left

<cehteh>even some crude scripts for installing would do, just question/answer game

<davexunit>that can come later

<davexunit>better to focus on the real tech now

<cehteh>integrate the guix configuration in guile-emacs as customize group :D

<zacts>lo guix

IRC channel logs

2015-06-25.log