IRC channel logs


back to list of 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:
<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:
<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
<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
<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 and 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>oh, I had a little question
<remi`bd>I ran into some trouble with sizeof, last week
<remi`bd>it seems like this commit is not in the Guile used by Guix
<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
<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
<davexunit>but then again I'm still confused some aspects of user namespace
<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>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>a user with setuid/setgid capabilities
<civodul>well, it's Linux, no big surprise ;-)
<davexunit>I'm starting to feel the snark
<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
<davexunit>and in the future I can see this daemon being the basis for a new, pure Guile build daemon.
<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>and "docker exec"
<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
<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.
<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.
<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>we'll have to limit it to being run as root
<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 Was there some other concern I'm forgetting?
<davexunit>rekado_: I think you've convinced me that it's okay.
<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, 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>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
<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_>I'll try to take a look some time this weekend.
<davexunit>pjotr seems to be working on a new ruby build system
<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. :)
<davexunit>pretty much never
<rekado_>heh, I wish.
<davexunit>we'll just have to follow up on the list
<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.
<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