IRC channel logs
2015-08-07.log
back to list of logs
<yenda>installing/updating vlc feels like pulling the whole internet <yenda>and indeed it didn't update the kernel <caddar>how do i change my shell to zsh on guixsd? <caddar>and question two: does it make me a scoundrel to do ln -s /run/current-system/profile/bin/env /usr/bin/env? If not, how should I write a python script? <Steap>caddar: I must say I also wonder about that /usr/bin/env thingy :) <caddar>i even feel tempted to just go hogwild and ln -s /run/current-system/profile /usr <tennix>how to install different versions of a package? python2 and python3 for example <yenda>is it possible to apply a patch for the kernel the way we do for the other packages ? <alezost>yeah, why not; it's just a usual package <rekado->yenda: is this to make the driver work without the firmware blob? <taylanub>tennix: I'm not sure but I strongly suspect that it's possible. you might want to look into its documentation. <tennix>dmd is the first process with pid=1, seems impossible to run on other distros <alezost>if you mean to use it as a manager of user services <yenda->alezost: you remember my problem with an ati radeon ? It seems like there is a fix (not for 3D but for radeon pilot not to crash at least), I have the patch running at home but hydra was so slow I'll see the result when I come back <tennix>i just installed postgresql with guix on centos and wanted to manage postgres with dmd <alezost>yenda-: yes, I remember. I hope that patch will fix this issue <tennix>and i also installed dmd using guix, but there seems no dmdconf.scm file in ~/.guix-profile <alezost>tennix: what is "dmdconf.scm"? Why do you think it should be in ~/.guix-profile? <tennix>the manual says run "dmd --config=/etc/dmdconf.scm.old", as i installed dmd with normal user, i think /etc will be linked to ~/.guix-profile/etc <tennix>apparently my normal user has no permission to create file in system /etc directory <amz3>(can you give an exemple of user service please?) <tennix>at least i have to run dmd as a daemon, and then can run a service using deco command <tennix>but i don't know how to start dmd, there's no config file to load <tennix>oh, it seems that there's no need to load a config file manually. I just run "dmd" and it just complains that "no such file or directory '~/.dmd.d/run'" <tennix>and i just create this directory and run "dmd" again, only complains "socket directory setup is insecure" <tennix>with "-I" option which ignore insecure, can start dmd daemon now <tennix>now, i just wondering what permission should i set to ~/.dmd.d/run directory <tennix>i'll check the manual for some more details <alezost>tennix: I have 700 permission on that dir <amz3>Sorry for the noise. thx, I understand the use of dmd. I was wondering whether there was other use, like a supervisor replacement, but anyway I don't have interest in that feature. I could use it for emacs daemon though. <tennix>amz3: dmd is similar to systemd/upstart which manage service from system boot <tennix>systemd is a controversial system service manager, but gradually adopted by more and more distros <taylanub>of course I hope/believe that dmd will be even greater (being in Guile), but my experience with systemd on Debian was very nice so kudos to them. <yenda->Is there a plan to give hydra some mirrors (of the susbsitutes rather than more builders) ? <amz3>I think the plan is to use gnunet for binary distribution <amz3>I mean, there is a gsoc for that <taylanub>yenda-: that would probably entail too much synchronization overhead since the packages on hydra change rapidly <yenda->ok, I hope it will work soon, it took me 2hours to update my system with subsitutes from hydra <amz3>my understanding is that at least guile gnunet bindings will be finished <DusXMT>ACTION wonders if there will be a web-like service for gnunet <amz3>there might be still work to be done to have guix distribution over gnunet <amz3>DusXMT: what do you mean? <amz3>something like bittorrrent maelstorm? <DusXMT>amz3: Something similar to the World Wide Web, with someting similar to web pages <taylanub>I thought GnuNet's transfer method is intrinsically high-latency or so, since it's P2P? <taylanub>well, same with Freenet and yet they have Freesites. and I didn't know of Maelstrom... <amz3>after discussion with #gnunet and my own understanding there is nothing stopping from doing so. <amz3>I'm working on something like that <amz3>but it's more a framework for building networked p2p application. which includes application using the web stack <amz3>I think gnunet has also messaging <amz3>since you seem interested i'll explain a bit more <amz3>my plan is to have a database in guile, that can be easily synced/shared over gnunet <amz3>making it easy to "push" updates, which is possible with gnunet, but not directly possible in guile right now <amz3>right now my plan is to keep the P2P spirit, which means an application is not centrally owned. <amz3>actually i'm not interested in other plans <amz3>well, my database is more like a long dream I have. It could work with SQLite or other. It's just that I'd like hopefully to lower the barrier of entry for building such p2p apps from guile avoiding sql databases <amz3>a lot people are interested in this kind of project <amz3>kfor so it's very likely <amz3>for some definition of "a lot" <amz3>so it's likely to be something of next year or next few years <amz3>there is already gittorrent, which use the bittorrent DHT and allows to keep you git repo in the DHT over P2P <amz3>this is the same principle that I will use, except through gnunet <taylanub>I don't know very much about the details of GnuNet and other P2P technologies so I can't give meaningful feedback, but it sounds interesting, thanks for the explanation <amz3>gnunet use something similar to the DHT of bittorrent and kademlia. Which is a distributed key/value store <amz3>what you can do with gdbm or bsddb or kyoto cabinet or wiredtiger or even redis can be done with the DHT and gnunet <amz3>gnunet is database with a specific interface <amz3>that's what my library should make obvious <xentrac>presumably once I have guix 0.8.anything running, I can install current Guile inside of it and build current Guix under Guix <davexunit>xentrac: you'd be better off installing our binary tarball, if you're open to that. <davexunit>I could've sworn debian jessie had at least guile 2.0.9 <xentrac>well, I agree that that would be a more expedient solution <xentrac>surely somewhere there's a directory full of old guix releases? <davexunit>but I think it would be easier to compile guile 2.0.11 and use it to build the latest guix. <xentrac>that could very well be; any idea when the guile dependency changed? <xentrac>or whether I'm likely to run into other similar roadblocks? <xentrac>(you could very reasonably argue that wanting to build it with a 2½-year-old release of guile is silly) <alezost>xentrac: I don't suggest you to try this way <davexunit>I'm not sure when we bumped the min version for 2.0.5 to 2.0.7. <xentrac>guix 0.8.1 is satisfied with 2.0.5+debiansilliness <xentrac>hopefully I can use guix 0.8.1 to build guix 0.8.3 <xentrac>alezost: any particular reason, or just that it's not the best-tested path? <alezost>xentrac: I think it's not tested at all <davexunit>it will work, you can get a new guile from that guix <davexunit>though I worry that we no longer have binaries available for that release. <davexunit>and xentrac will have to build everything from source. <alezost>ACTION is sure there are no binaries for that release <xentrac>building everything from source will make me a happier sentient entity <xentrac>one of the reasons I never installed Vesta was that it was impossible to build it from source <xentrac>(one of the problems with self-sustaining systems like Vesta and Squeak, I guess) <davexunit>yeah, we take care, and so does Guile, to make it possible to bootstrap without needing a previous binary of our software. <xentrac>well, they had a sort of reasonable excuse for it <davexunit>whereas a lot of new compilers and things self-host and remove the bootstrapping option entirely. <davexunit>haskell is one I can think off of the top of my head <xentrac>amusingly, the guix 0.8.1 source distribution now seems to be downloading both guile 2.0.11 and guile 2.09 <xentrac>precompiled versions of them, I think <davexunit>the whole system relies on a very small number of bootstrap binaries <xentrac>hmm, still no Guix for OS X? I might end up having to use Nix so that other people on the project can run the same packages I am... but I'll leave that for later <davexunit>xentrac: I don't think we have a single developer that actually uses OS X. <davexunit>I think we'd be happy if someone did the port, provided that it can be done without a nonfree toolchain. <davexunit>but we need interested in developing *and* maintaining it. <davexunit>I'm not sure how Nix's build farm handles the darwin stuff <davexunit>if it builds them on GNU/Linux, then we could do the same, if they use OS X, then we cannot. <_`_>I doubt they cross compile. <davexunit>maybe they do. no one really uses OS X for servers. <_`_>you still need the xcode sdk I think for most things that help with that <_`_>and that's just to setup the toolchain <xentrac>Nix actually has two different ways of compiling for OS X <_`_>It just seems like too much of a pain instead of just virtualizing it and compiling natively. <davexunit>_`_: yeah if we need xcode then that's a dealbreaker. <davexunit>_`_: we also cannot virtualize OS X because it contains a lot of proprietary software. <_`_>Oh I'm not suggesting any o that <_`_>(os x should be an afterthought, imo) <davexunit>_`_: os x already is an afterthought for us ;) <davexunit>but if someone was, and could port guix without making it nonfree, I would be happy to see it. <_`_>It sounds like it can only be done natively if this pure-darwin is used <xentrac>I'm going to postpone worrying about it for a while :) <xentrac>hmm, I'm still trying to figure out how to get 0.8.1 to become runnable. `./configure && make && make install` completed successfully and has created a guix-daemon binary, but did not create /gnu or /usr/local/bin/guix or anything. I guess now I run guix-daemon or something? <xentrac>I expected `make install` to install a `guix` command <xentrac>`make check` hasn't finished yet but it seems to be compiling diffutils <xentrac>yeah, so `make check` finishes and everything passes <xentrac>INSTALL says to use ./configure && make && make install, but it's just the standard autoconf INSTALL file. there's now a /usr/local/var/guix/daemon-socket/socket <tennix>yes, guix-daemon will create that socket <xentrac>if I try to invoke ./scripts/guix, I get a backtrace ultimately saying "ERROR: no code for module (guix ui)" <xentrac>yes, I created the guix-builder group and users, and launched guix-daemon successfully <xentrac>but shouldn't there be a guix command to ask guix-daemon to build things for me? <xentrac>`: user@debian:~/pkgs/guix-0.8.1; find -name guix-real` returns no results <tennix>i install guix through their binary, and guix command is just a script file, last line of it is exec xxxx/.guix-real <xentrac>davexunit: bash: guix: command not found <xentrac>is it supposed to be installed by `make install` in /usr/local/bin? <xentrac>it installed a bunch of stuff in /usr/local/share/guile, including its bootstrap executables <xentrac>yeah, I didn't override it, and that seems to be where it installed the things it did install <xentrac>yeah, in the Makefile it says `prefix = /usr/local` <xentrac>hmm, this time it did install a guix in /usr/local/bin <xentrac>I wonder why it didn't before! But now I am happified! <davexunit>that's odd... 'make install' certainly works reliably, otherwise we'd have a lot of nondeterminism issues in our package builds <xentrac>maybe it had a hidden dependency on having run `make check` first <xentrac>now I will continue reading the manual <xentrac>meanwhile `guix pull` has decided to compile GCC <davexunit>xentrac: this is because you haven't authorized a server to provide binaries to you <davexunit>xentrac: guix is a source based package manager that optionally allows you to download pre-built binaries *if* you authorize a server as trusted. <xentrac>compiling GCC seems like a reasonable thing to do; it just surprised me <xentrac>it's also compiling Linux, which may not be as sensible <davexunit>with guix being an alpha distro with no stable series, expect a lot of rebuilding. <davexunit>we reduce the amount of rebuilding between releases by having a separate git branch that contains patches that "rebuild the world" <xentrac>it would be nice if its sandboxed builds could use its own version of the Linux kernel in order to make them more reproducible, but chroot is not that powerful :) <xentrac>given that I'm going to keep using Debian's kernel, it seems perhaps unreasonable that it's going to build me a new kernel. what does it want to use it for? <davexunit>guix uses chroot + namespaces to create one of those new-fangled "containers" people like to talk about so much. :) <xentrac>my coworker said "it would be cool if it could use Docker!" <davexunit>xentrac: I'm not sure, but it likely needs a header or shared lib or something else that's distributed with it. <xentrac>I said, "Well, what Docker does is..." <davexunit>I'm actually on the verge of having basic user-accessible container support in guix. <davexunit>so yeah, no docker needed, though we would gladly accept a package recipe for it. :) <xentrac>although, doesn't the ability to write and build a package recipe amount to "basic user-accessible container support" already? <davexunit>what about when you actually use the software? <davexunit>that's what my container implementation, named in Scheme style as 'call-with-container', allows. <xentrac>what can't you do in the build environment? <xentrac>hmm, maybe I should finish reading the manual before I ask more questions <yenda->before packaging docker we need to package go <davexunit>xentrac: the build environment is non-interactive <yenda->anybody working on packaging clojure ? <davexunit>it's very tightly controlled and explicitly for making builds as reproducible as possible. no networking and such. <xentrac>yeah, no networking would make it difficult :) <davexunit>what I am after is a way to make containers that run GuixSD, our distro. <xentrac>it would be useful to be able to run, say, Apache in a container too <xentrac>I saw an amusing article about Docker the other day <davexunit>tennix: we have 'guix system vm' that can be used like a vagrant replacement <tennix>In fact i'm running guix in a vagrant vm <xentrac>not "basically". that's exactly what it says <davexunit>tennix: care to share your vagrantfile for guix? <davexunit>I'm interested in making our VM creation tools cover the necessary things to replace vagrant. <xentrac>if we believe Adam, than Guix could do automatic linking <davexunit>of course, this would only be for guixsd vms. <davexunit>xentrac: there's nothing "wrong", exactly, but it's not very good either. <tennix>maybe i'll try to build a GuixSD vagrant <davexunit>the most wrong thing is that it uses virtualbox by default <xentrac>really? there's no free virtualbox anymore? <_`_>I'd like a better vm management tool, but I'm mostly fine with just invoking qemu(1) these days. <davexunit>but vagrant is just another tool with an imperative, stateful model and all the issues that it brings. <xentrac>(also, should I expect `guix pull` to fill up the 2½G remaining on my SSD?) <davexunit>xentrac: depends on how much software needs to be built. by building everything from source you will bring in considerably more software. <xentrac>I guess if virtualbox has become non-free, we should expect the JVM to become non-free too <tennix>shell by default, and can use chef, puppet and so on <davexunit>tennix: and 'guix system vm' also provisions vms. <xentrac>yenda-: I mean, how do you find the current JVM packages in Guix? <DusXMT>xentrac: Well, from what I know, the problem with Virtualbox is that there isn't a free compiler for the bios <tennix>i just build guix from source in archlinux. only invoking ./configure && make && make install. everything goes well <tennix>trying to build on a mac. it says 'x86_64-darwin14.4.0' is not a supported platform <xentrac>yeah, we were talking about that about half an hour ago <xentrac>I'm guessing that this may be relevant if you want to get Guix running on MacOS <xentrac>the Nix folks are using clang for whatever reason <tennix>i have coreutils installed on mac <davexunit>my knowledge of bootstrapping new systems is practically 0, so I can't really provide much insight into things. <xentrac>yeah, that's becoming increasingly necessary since Apple acquired its GPLv3 allergy <davexunit>yeah, it sure is great to use a brand new Mac with a 2007 release of bash! <xentrac>it offers us some possibility of winning back some hackers who deserted free OSes for MacOS ten years ago :) <davexunit>some of whom are convinced that homebrew is better than GNU/Linux package managers! <xentrac>it's not a very strong argument for them, I'll admit <xentrac>homebrew does have its benefits. especially if you're comparing it against, say, rpm <davexunit>it's better than nothing, and it's nice that an unprivileged user can use it. <xentrac>well, and more to the point, it doesn't provide rollback or isolation <xentrac>"unsafe" is not a very persuasive argument on its own <xentrac>in a few minutes I'm going to one of the most dangerous neighborhoods in Argentina. so far nobody has robbed me there but some of my co-volunteers there have been robbed at gunpoint <xentrac>by comparison, nonfunctional package managers do not seem particularly risky to me <xentrac>but I would like to be able to install a modern version of IPython without worrying that I will irretrievably break booting or audio <tennix>xentrac: programming languages have their own package managers <xentrac>tennix: yeah, I think that that's partly a result of the last ten years of hackers using MacOS <xentrac>but it's also a result of hackers needing things that apt and rpm don't support from package managers <xentrac>like having different versions of a package installed <tennix>ipython can be installed using pip <davexunit>it just adds new package managers you have to use. <davexunit>and they all have their boundaries in which they can operate <yenda->when a package needs jdk we give it icedtea as native-input ? <xentrac>tennix: yes, and one of the major advantages of that is that I can be using the same library versions as my coworkers are <xentrac>I'm not sure that's purely a win, but sometimes it is a win <davexunit>tennix: yes, it has certain advantages but it also has the huge disadvantage that developing and deploying applications is now a complete and utter nightmare. <davexunit>web applications now need at least 3 package managers typically <xentrac>guix already has a balun for PyPI, right? <davexunit>that can (mostly) generate package recipes for you <xentrac>a balun is a thing that lets you connect a balanced microphone to an unbalanced input, or vice versa <xentrac>I didn't remember that it was called an "importer" in Guix <xentrac>are there importers for npm, bower, gem, etc.? <davexunit>I have written a ruby build system, and I'm trying to untangle the complete and utter madness of the node build system. <tennix>oh, nearly all of the newly languages have their own package managers <tennix>do you plan to make importer for each language pkg manager <davexunit>for each one that I'm personally interested in, yeah. <davexunit>I want to to make it as easy as possible to use only Guix. <tennix>and some languages have more than one pakcage managers, python of course <davexunit>yenda-: icedtea6 and icedtea7 are the ones I think. <davexunit>the standard output should have the jvm, and the 'jdk' output has the jdk stuff. <xentrac>C and Java are probably the worst languages in terms of package manager count <davexunit>tennix: but all the data is hosted on pypi.python.org <davexunit>all that matters to us is that there's an API that we can query to get metadata about packages <davexunit>to greatly reduce the boilerplate needed to write new packages for those languages <tennix>some languages like golang has no centeralized repos <davexunit>Go, IMO, is one of the most nonsensical of them all. <davexunit>from what I can tell, everyone just bundles all of their dependencies in their repo <davexunit>and the resulting Go binaries are *always* statically linked <taylanub>I thought Go explicitly favors static linking. <davexunit>you have no choice but to statically link, AFAIK. <xentrac>Yeah, 6g/8g doesn't have dynamic linking AFAIK <tennix>i remember that go support dynamic link now <davexunit>knowing these things, I don't want to touch Go with a ten foot pole. <taylanub>well, static linking has its advantages... <xentrac>what should I move to a bigger disk in order to get the build to not fail? /gnu/store? <davexunit>so that should have enough space to handle large builds <tennix>yes, when deploying applications, there's no dependency hell <taylanub>davexunit: what disadvantages do you have in mind? (genuinely curious, I don't have an opinion on the matter yet) <xentrac>am I going to be sad about storing my /gnu/store on an NTFS partition? <davexunit>tennix: so rather than fixing the problem, peopele take the worst possible approach from a security and maintenance perspective. <xentrac>I guess I'll create a 10GB loop-mounted ext4fs on my ntfs, sigh <yenda->they have src and jarsrc, do we have that too ? <_`_>taylanub: static linking breaks aslr I think <tennix>because disk is getting cheaper and network faster now, developers prefer statically links instead of dealing with complicated dependencies <davexunit>because now they have N versions of a library that has been discovered to contain a vulnerability, and they are now dependent upon the maintainers of *each* application that statically linked that library to update their application. <davexunit>and even discovering which applications statically link a compromised library can be difficult. <davexunit>Guix solves the issue of wanting to use whatever version of a dependency you want without clashing with the rest of the system <yenda->can we have more than one source ? <davexunit>sorry, I'm not too familiar with the clojure stuff <davexunit>there should be an example of two around, though. <yenda->I'm not familiar either I would usually just install the leiningen package :D <yenda->worst case scenario I'll go on #emacs and ask technomancy for help :D <yenda->do you know what the syntax would look like ? <tennix>i'm just trying to build guix on mac <tennix>getgrouplist function seems not compatible <xentrac>guix pull: error: build failed: `/gnu/store' is not a directory <xentrac>: user@debian:~/pkgs/guix-0.8.1; ls -Ldl /gnu/store <xentrac>drwxrwxr-t 40 root guix-builder 49152 Aug 7 12:56 /gnu/store <xentrac>it's a symlink to a directory though! <xentrac>I guess I can mount the partition directly there... <taylanub>xentrac: maybe file a bug report, if you're sure it links to a valid directory, e.g. if you can run "ls /gnu/store" just fine <davexunit>for technical reasons around how build environments are constructed <xentrac>taylanub: well, you can see that it does above, no? <davexunit>I don't know if a /gnu/store that is a symlink would play nice with the bind mounts that need to be done in the build container <xentrac>davexunit: oh, it's not just an oversight? <davexunit>and someone who knows will either fix it or confirm that it isn't a bug <taylanub>and maybe add that it would be nice to have the error message mention the limitation, if it's an intentional limitation <yenda->davexunit: so (cons* (origin...) (origin...)) ? <xentrac>taylanub: that's a good idea; too bad I didn't see your comment before emailing <xentrac>hmm, apparently it's going to recompile gcc again because the last guix pull ran out of disk space while recompiling tar <taylanub>you're building everything from source? :/ <xentrac>I'm not building *everything* from source actually <taylanub>FWIW my /gnu/store is 5 GB already. I could say I have a moderate amount of stuff installed. <davexunit>building everything from source is perfectly reasonable. <xentrac>it's still using the five bootstrap binaries though <xentrac>couldn't it use tar and xz from my Debian system? <xentrac>I mean, you could use the three-stage GCC bootstrapping process <taylanub>IIRC there was a plan to create fixed-point bootstrap binaries (and I have a vague idea of what that means and how it solves the trust issue but don't expect me to be able to explain it...) <xentrac>it's already using the kernel from my Debian system <xentrac>it doesn't completely solve the trust issue without diverse double-compiling <davexunit>but there is a section in the manual about computing a fixed point <xentrac>fixed-point bootstrap binaries are binaries that don't change when you use them to build themselves <davexunit>but anyway, the point is that *everyone* use the *exact* same bootstrap binaries. <xentrac>okay, I'm going off to go see the addicts. if this build runs out of space I'm going to be sad, you guys :) <tennix>mac has getgrouplist(const char *name, int basegid, int *groups, int *ngroups) <tennix>while linux uses gid_t which is unsigned int <tennix>can't convert unsigned int* to int*, that's the problem <xentrac>hmm, it failed again in GCC because /tmp was full <xentrac>(so maybe it was actually gcc that failed last time?) <xentrac>so, now I have 7.7GB available in /tmp, which will hopefully be enough <yenda->davexunit: it looks like source doesn't like to be fed a list of origins <yenda->davexunit: libreoffice itslef has a tarball in its inputs <yenda->which is defined above and contains an origin only <davexunit>maybe that's what I was thinking of and you can't include multiple sources. <davexunit>allowing only a single source tarball makes sense to me <xentrac>hmm, actually it seems like I'm having a reproducibility failure already: <xentrac>warning: gcc/cc1plus-checksum.o differs <tennix>Oops, it's almost 1 o'clock in the morning <xentrac>but it seems like Guix is proceeding anyway <yenda->any idea how i could apply this nix patch to the source ? <davexunit>yenda-: <origin> objects have a 'patches' field <yenda->davexunit: but when I put it there it says it's trash <yenda->"Only garbage was found in the patch input. <davexunit>either the patch doesn't apply, or it can't find the file <yenda->right, if forgot to add the patch in gnu-system <yenda->it still says it's garbage, I wonder if it's because the patch doesn't look like a git patch <yenda->you can't import nixpackage with guix without installing nix ? <yenda->well nvm I noticed its packaged, awesome <sprang>this might be a naive question: why is the input hash a prefix rather than a suffix? I know this was inherited from nix. <davexunit>paroneayea: I just turned icecat off for now. maybe I should disable JS until it is fixed. <davexunit>yenda: the patch is invalid for that version of the linux-libre source <yenda>but we are at 4.1.4 just like the patch <davexunit>are you apply to apply that patch using the 'patch' tool manually? <davexunit>the error is clear: the patch doesn't apply. <yenda>is there some guix specific changes to the kernel ? <yenda>davexunit: what do you mean ? Currently i added the patch to the package definition <yenda>davexunit: ok I compared the patch to the source and some off the changes were already applied hence the error. I got a better one to try out from jxself <yenda>While the kernel recompiles I have other questions :) <yenda>I'm trying to import package definition from nix with guix import <yenda>I installed nix with guix, downloaded nix packages repo and still I can't get it to work <yenda>what is needed exactly to be able to import from nix ? this would deserve a more complete documentation <davexunit>and I'm not in a position to setup nix and nikpkgs <yenda>I'm asking to anyone who would have make it work, it would actually be of great help to have it easely usable because they have tons of packages <davexunit>ludovic wrote it and is honestly probably the only person that has used it. <yenda>The error I get is Nix database directory ‘/nix/var/nix/db’ is not writable: No such file or directory <yenda>I just did guix package -i nix <davexunit>nix has a daemon that needs to be configured and started, like guix. <yenda>and you need to create a nixbld group <yenda>I suppose you do that by adding it to the system configuration and doing system reconfigure ? <yenda>well I hope it will work. I'll do that after the kernel patching is done <davexunit>create the group and do whatever else you have to do to setup nix. <davexunit>it would be cool to have a nix-service pre-built for folks to use :) <yenda>davexunit: do you have an exemple of how to add a group ? <davexunit>(operating-system ... (groups (cons (user-group (name "foobar")) %base-groups))) <davexunit>you'll want to cons extra groups onto %base-groups, which includes a bunch of system groups