<goglosh>the only way to start X is with slim? <goglosh>see, all I want is to run `startx` or anything analogous and have the usual results. <goglosh>the guix manual only talks about slim in the context of X <mark_weaver>goglosh: at present, it's rather difficult to start X without using slim. <goglosh>hey I was thinking about a discussion that was going on yesterday, pertaining system administration and script portability <goglosh>you know, not being able to just #!/usr/bin/env perl at the start of a script <goglosh>wouldn't it be as easy as making a dummy chroot environment for those scripts, which are expecting a more traditional unix layout? <goglosh>full of symlinks and aliases that mimick this environment? <mark_weaver>at one point, I thought of doing something like this, but when you look at the details, it's really not feasible. <mark_weaver>I don't have time to explain why, but if you think I'm wrong, feel free to flesh out the details and make a concrete proposal. I think you'll discover along the way why it can't work. <mark_weaver>and anyway, we already know that it's possible to solve this problem in an almost ideal way <goglosh>I don't know enough of the workings of guix yet, I'll take your word for it <zacts|pi>davexunit: what do you use to fetch mail for notmuch? <goglosh>so if I understand correctly the way to go if I want to build, I'll need to make a package..? <davexunit>packages are just one type of object that Guix knows how to build <goglosh>what I mean is... I shouldn't go with the old ./configure make make install... right? <davexunit>you are free to do that, but the software installed that way will not have the benefits of being managed by Guix. <davexunit>I do './configure && make' for all sorts of software, most of which I am hacking on so I do not do the 'make install' step <goglosh>it's just... I tried it, and it didn't really work <goglosh>maybe it was somehting in my setup at the time. I'm actually asking because right now I want to install the oh-my-zsh thing <rekado>daviid: I wanted to package guile-gnome, actually, but then read that guile-clutter was not released yet. That's what held me back. <civodul>rekado: could you update tests/cran.scm to account for the new 'cran-uri'? <rekado>civodul: sure! (I also should add some runtime checks as you suggested after the importer was merged.) ***joehillen_ is now known as joehillen
<rekado>I'm currently setting up the socat solution to share the daemon socket on the privileged machine with cluster nodes. I wonder if exposing the daemon socket can be dangerous. <rekado>how are user ids retained when communicating over the socket? <civodul>the daemon checks if the UID of the connections is zero <civodul>nix-daemon grants special privileges to UID 0, but guix-daemon should make no difference <civodul>however, it's safer to have socat run unprivileged <civodul>(it's the effective UID of the 'socat' process that talks to the daemon that matters) <rekado>that's the socat process on the same machine where the daemon runs. <rekado>on the cluster nodes users run their own instance of socat to let guix connect to the TCP port when it talks to the local socket. <rekado>all user information is lost, though, when the message is received by the socat process on the daemon host. <civodul>as long as the receiving socat is not running as UID zero, that's OK <civodul>there's a single socat running on each "client" node, right? <rekado>profile modifications are done by the local "guix" command, not by the daemon, right? <rekado>i.e. the daemon only builds stuff, but "guix package" changes links. <civodul>this is why /var/guix/profiles/ must be shared over NFS <rekado>I was worried for a moment that I misunderstood. <civodul>ACTION is becoming more and more concerned about the locale mess when we upgrade <rekado>hmm, I think I still don't understand this right. Aren't profiles also built by the daemon and placed in the store? <rekado>All that's in /var/guix/profiles is the links to profiles in the store. <rekado>if there is no user information retained when talking to a remote daemon, how does it know for what user it is to build a profile in the store? <civodul>the profile builds everything that needs to be built, including profiles <rekado>or does it simply not need to know? <rekado>ah, the profile in the store is not actually owned by the user. <rekado>it's just the links to the profile that are user-owned. <civodul>as a result the build lasts very long <davexunit>civodul: random note: the GNOME packages are known as "xdg-app bundles", according to a comment on LWN. <rekado>civodul: sorry, I don't know what's wrong with ScaLAPACK :-/ <civodul>paroneayea: WDYT based on your experience? <civodul>ACTION thinks we must prepare to buy hardware and pay for hosting <civodul>email sent to donate@fsf.org + guix-sysadmin@gnu.org :-) <bavier>civodul: I've looked at the scalapack i686 build a bit. I unfortunately don't know what's going on. <bavier>I'd be tempted to disable tests on i686 for now <davexunit>I started writing some comments on an HN thread about Docker, explaining how Guix containers actually avoid a lot of problems people have with Docker and other image-based container systems <davexunit>I realize that I *really* need to prepare a blog post that explains this stuff with some pictures <civodul>davexunit: and... you need to get wip-container merged! :-) <paroneayea>civodul: having a nice civicrm page through FSF has worked well for us, yes <paroneayea>civodul: recommendation: put that donate link very visible on your website, maybe even in several places. You might think this is cheapening things, but it isn't. <paroneayea>civodul: people aren't going to donate unless you guide them to it <civodul>paroneayea: ok, we'll do that when everything is in place <civodul>i'll keep asking you for advice anyway ;-) <davexunit>hmm, that libc patch thread isn't going so well. <davexunit>the last message was particularly concerning. <davexunit>not exactly a friendly community I guess. unfortunate. <davexunit>oh dear, emacs needs a new maintainer it seems. ***davi_ is now known as Guest34043
<wgreenhouse>guixsd has my most needed packages, but not a lot of the services to run them. is contirbuting services definitions a sensible place to start helping out with guix? <davexunit>ACTION outlined a blog post about containers <davexunit>a bunch of paragraphs left to write, but I have the basic topics down. <Steap>So, is there really a *strict* one package/update per patch rule? <efraim>the only real exceptions were like when the cran-uri update happened recently or fixing a bunch of typos or descriptions <civodul>ACTION posts about the forthcoming locale mess <Steap>it fixes an issue with bootstrapping python-fixtures <efraim>emacs/guix-autoload.el fails on make if emacs isn't installed <civodul>weird, the whole thing is in an "if EMACS" in emacs.am <goglosh>okay so, whenever I use guix system reconfigure <goglosh>a new configuration 'instantiates' and the grub is set to point there (whatever that means) <civodul>you can select it from the GRUB menue <civodul>if you want to remove it, you have to run "sudo rm /var/guix/profiles/system-129-link" (say) <civodul>in the future there'll be 'guix system delete-generation' or something <goglosh>also, now that you're here I'd like to know <goglosh>the only way to have X is with the destop-services? <goglosh>'cause I tried installing xorg-server by itself but startx wouldn't work <alezost>goglosh: I don't know about startx/xinit, but you can definitely run X server itself <alezost>For that, along with xorg-server, you also need to install xf86-input-evdev, xf86-video-<required-drivers>, maybe some other things; and run it like this: "X -configdir "/path/to/your/conf.d" :0 vt7" for example <alezost>I meant X fonts, but I think they are not required <alezost>you also need to specify the module path, either with '-modulepath /home/<me>/.guix-profile/lib/xorg/modules' or by putting ModulePath into "Files" section in a conf file <alezost>just to note: I don't use slim, instead I installed all required X packages into my profile and I start X server manually (actually I use dmd to start it, but it's not relevant) <civodul>we should provide a 'startx' that works <civodul>the 'xinit' package provides 'startx', but it needs love <goglosh>man, the same errorr again: no screens found <goglosh>dbus-core: error connecting to system bus: [...] Failed to connect to socket /var/run/dbus/system_bus_socket 
