IRC channel logs


back to list of logs

<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>alright, thanks
<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
<davexunit>paroneayea: cool screenshot
<zacts|pi>davexunit: what do you use to fetch mail for notmuch?
<zacts|pi>I'm assuming offlineimap?
<davexunit>zacts|pi: yes
<zacts|pi>ok cool
<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
<davexunit>'make install'?
<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
<goglosh>nevermind actually
<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>Hello Guix!
<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>yes, but that's not a problem
<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>got it.
<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?
<civodul>it doesn't 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>the VW scandal as a good case against proprietary software:
<civodul>Moglen rocks
<civodul>bavier, rekado: Scalapack has its tests timeout after 25mn; any idea what's going on?
<civodul>as a result the build lasts very long
<civodul>it's already been running for 11h
<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>davexunit: ok
<civodul>i think we should already add Guix to
<civodul>paroneayea: WDYT based on your experience?
<davexunit>civodul: that sounds like a good idea
<civodul>ACTION thinks we must prepare to buy hardware and pay for hosting
<civodul>email sent to + :-)
<davexunit>awesome :)
<davexunit>mark_weaver: picture of a novena heirloom model with a cooling fan hooked up:
<davexunit>better picture:
<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>bavier: ok, maybe yes
<civodul>davexunit: definitely!
<civodul>davexunit: and... you need to get wip-container merged! :-)
<davexunit>yes I know...
<davexunit>so many things to do...
<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
<paroneayea>and asking for help helps!
<civodul>paroneayea: ok, we'll do that when everything is in place
<civodul>i'll keep asking you for advice anyway ;-)
<paroneayea>civodul: :)
<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.
<civodul>Roland is on our side though ;-)
<davexunit>oh dear, emacs needs a new maintainer it seems.
<davexunit>hope that transition goes well.
***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>Steap: roughly yes
<civodul>ACTION posts about the forthcoming locale mess
<Steap> <- this seems to make sense as a single patch
<Steap>it fixes an issue with bootstrapping python-fixtures
<civodul>this one yes, probably
<efraim>emacs/guix-autoload.el fails on make if emacs isn't installed
<civodul>weird, the whole thing is in an "if EMACS" in
<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)
<goglosh>what happens to the old one?
<civodul>goglosh: the old one remains
<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)
<goglosh>ooh, great.
<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
<goglosh>oh, great
<goglosh>*maybe some other things
<goglosh>I'll work it out :D
<alezost>I meant X fonts, but I think they are not required
<goglosh>oh, okay
<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)
<goglosh>yes that's what I want actually
<alezost>ACTION --> Zzz
<civodul>we should provide a 'startx' that works
<goglosh>as a package, maybe
<goglosh>so it *just werks*
<civodul>the 'xinit' package provides 'startx', but it needs love
<zacts>hi guix
<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