IRC channel logs

<davexunit>good evening, #guix.

*davexunit remembers that he wants redis packaged

<davexunit>tried once, had issues with the test suite

<grothoff>Hi! I'm currently torturing my notebook with a Guix installation. Running into a few fun issues.

<grothoff>Got "unexpected EOF reading line" a few times, as well as hard DNS lookup failures. Both went away after I hardcoded the IPs of hydra and alpha into /etc/hosts. Before than, somehow DNS at Inria was 'too slow' and created timeouts that caused guix system init to fail hard.

<grothoff>Maybe the installer can do the DNS lookup once (also to check if Internet is working) and then store/cache the result in /etc/hosts for the rest of the installation?

<grothoff>Also, when I forgot a * after 'cons' in the config.scm, I just got "wrong number of arguments to cons()" from guix system init, no line number, nothing. Would be nice if we could have at least the line number...

<civodul>Hello Guix!

<mthl>Hello civodul

<civodul>hey, mthl!

<civodul>how is everything?

<mthl>busy :-)

<civodul>exams are not over yet?

<mthl>my exams are over, but i'm in a traineeship at inria now

<mthl>I work on starPU on MPI

<mthl>quite complicated for my little head ;-)

<mthl>and you? on vacation?

<civodul>mthl: really you're at Inria on StarPU?

<civodul>i'm not there today, but we gotta have coffee next week!

<mthl>nice!

<civodul>paroneayea: BTW, just saw your message on emacs-devel, thanks for the ad! ;-)

<phant0mas>civodul: sent an updated glibc-macro patch and the problem I am facing.

<phant0mas>have a look when you can :-)

<phant0mas>RMS is having a talk today here at Iraklion

<rekado_>grothoff: I agree it would be nicer if "guix system init" printed a backtrace or at least a little more information.

<civodul>phant0mas: ok!

<civodul>oh, howdy grothoff, good to see you here! ;-)

<grothoff>Yeah, should have joined earlier, took me a bit long...

<rekado_>Is there a way for us to see the config log for a given build failure on hydra? I'd like to investigate why icedtea6 is failing on MIPS: http://hydra.gnu.org/build/458815/nixlog/5/raw

<rekado_>the error is: checking if the VM and compiler work together... configure: error: Compiler failed to compile Java code.

<rekado_>we are using gcj+ecj as the bootstrap compiler and VM. Only ecj-bootstrap is a binary, but it should be portable, so I don't understand why the javac wrapper around gcj fails to compile Java code.

<rekado_>the config log might help

<civodul>rekado_: unfortunately no

<civodul>in an ideal world, Guix hackers would have access to development machines for each architecture

<civodul>like Debian does

<civodul>mark_weaver: you've seen the weak DH thing?

<Sleep_Walker>logjam?

<civodul>yes

<civodul>apparently GnuTLS has a reasonable default (768 bits) and may increase it soon

<civodul>thanks to the publicity of the attack

<Sleep_Walker>GnuTLS IIRC shouldn't be affected

<civodul>yeah though it can do better

<civodul>the paper is worth a read

<Sleep_Walker>another vulnerability with name - customer loves that :b

<civodul>it includes an analysis to determine the likelihood of the NSA having used that weakness

<civodul>yeah it's funny to see all this marketing around security issues ;-)

<civodul>but it's probably very efficient

<rekado_>I just successfully built numpy with openblas. Will submit a patch to the ML for discussion once I confirmed that the tests for a couple of dependent packages still pass.

<rekado_>apparently numpy+openblas is buggy under some circumstances (e.g. when used with python < 3.4 and with openmp and when forking).

<Sleep_Walker> https://pbs.twimg.com/media/CE-eT6WUMAEmEo0.png ;)

<Sleep_Walker>BTW FTR, I tried guix with LVM yesterday once again and proved that simply moving dev among filesystems initialized from initrd makes more mess and I should take the approach of separate base-filesystem service

<Sleep_Walker>my TODO list for guix is growing much faster than I'm able to find time :/

<Sleep_Walker>I also tried systemd-nspawn for running guix in separated namespaces but initrd is not ready for such case and fails when it has filesystem already mounted :b

<Sleep_Walker>IOW I'm still alive, but busy, sorry :)

<grothoff>civodul: for logjam, the DH analysis is not marketing. They really looked at our reporting on how the NSA breaks TLS/SSH/etc. and reverse-engineered the attack from that.

<davexunit>Sleep_Walker: why do you need an initrd with systemd-nspawn?

<sneek>Welcome back davexunit, you have 1 message.

<sneek>davexunit, please_help says: is this what you're looking for? https://www.gnu.org/software/guile/manual/html_node/Foreign-Structs.html

<davexunit>Sleep_Walker: from what I've gathered, we would just want to run dmd and we'd be all set.

<Sleep_Walker>davexunit: I'm on openSUSE while playing with GuixSD, that's all

<Sleep_Walker>davexunit: yeah, that would probably work, I'm running init script from initrd

<civodul>grothoff: oh of course, the research they did is clearly very rigorous; i'm was just referring to how people now give names, logos, web sites, etc. for vulnerabilities

*davexunit pushes wip-deploy branch

*davexunit tries to understand openstack

<civodul>davexunit: yay for wip-deploy! boo for openstack!

<davexunit>civodul: what's wrong with openstack? I assume there's something I don't know.

<civodul>honestly i don't really know ;-)

<davexunit>I need some free platform to target

<civodul>it looks like a huuuge piece of glue to me

<civodul>but i dunno

<civodul>Steap works on it, so he'd be in a better position to comment

<davexunit>what do you mean?

<davexunit>openstack itself looks like a huge piece of glue? or writing the code for 'guix deploy' would be a huge piece of glue?

<davexunit>or both? :P

<civodul>ah no, that openstack itself is glue

<civodul>that said, when i think openstack i mostly think of the web UIs

<civodul>but i guess that's just a tiny part of it

<davexunit>there's a whole HTTP API to provision VMs and stuff

<davexunit>and it's self-hostable, which made me think that it would be a good target

<civodul>ah ok

<civodul>but is it the right level?

<civodul>i mean openstack seems to do way more than that

<civodul>and in practice, it seems hard to package

<davexunit>I have no idea how hard it is to package.

<davexunit>but from the perspective of 'guix deploy', we just want to be able to talk with some server and say "make this VM, please"

<davexunit>and with openstack we could do that.

<davexunit>for comparison, nixops seems to focus on amazon's AWS service, which is a similar thing, but proprietary.

<civodul>but i guess we could use something like libvirt for that?

<civodul>that sounds lower-level and more tractable

<civodul>(then again, i'm no expert, so these are just my feelings)

<davexunit>it seems like you're thinking that we'd be spawning VMs on a machine already running guix.

<davexunit>but this is more about creating guix machines on *any* infrastructure someone writes an adapter for.

<paroneayea>hm

<davexunit>the VM's host likely wouldn't be a guixsd machine.

<paroneayea>davexunit: do you think guixops might also be used for the case where guixsd is already installed on a machine, and more or less you want to ssh into all of those and update them to a certain state?

<davexunit>paroneayea: sure.

<civodul>davexunit: oh, ok

<davexunit>but I'm particularly interested in deploying guix to a private "cloud" that I control.

<civodul>let's not use that word ;-)

<civodul>nixops assumes an ssh server and Nix are running on the target

<civodul>so the admin does the initial install, and then Nixops can start managing it

<daviid>yes, because private it obviously sun :)

<paroneayea>cloud2butt

<davexunit>civodul: hmmm that wasn't what I gathered. I thought that nixops did the provisioning and everything.

<davexunit>provision resources, copy system closure, etc.

<civodul>yes but to copy the closure, there has to be a store on the target

<davexunit>I thought it created the disk image as needed to do it.

<civodul>at least that was the case in the "Charon" days, dunno if that changed

<civodul>maybe it does nowadays

<civodul>well that's obviously even better if it can work this way!

<davexunit>if not, I've greatly misunderstood things.

<davexunit>and perhaps I'll table this for awhile.

<civodul>oh or maybe it does that for EC2 and all these things?

<civodul>perhaps *i* misunderstood things, you probably know more about Nixops's current status than i do :-)

<davexunit>civodul: from reading nixops some more, I can see that it creates new EC2 instances and volumes, but I haven't yet found how it initializes a NixOS system on those resources.

*davexunit continues to wait for home directory backup to finish

<davexunit>getting closer to being able to switch to guixsd on this laptop

<mark_weaver>someone(TM) should probably be patching security flaws in the zillions of bundled libraries in Qt, e.g. the bundled copy of Chromium(!). http://lwn.net/Articles/645615/

<mark_weaver>better yet, unbundle those things!

<mark_weaver>but I'll leave that to someone who's interested in Qt

<zacts>hi

<mark_weaver>hi zacts

<civodul>mark_weaver: ouch, this is terrible

<mark_weaver>that's just the latest chromium security announcement. there have been others in the past that haven't been dealt with either.

<civodul>yeah

<civodul>and doesn't Chromium itself bundle a zillion of things as well?

<mark_weaver>actually, more generally, we need to look through all of our packages that aren't actively maintained, because some of them haven't had a release in years while security fixes have been gradually accumulated by the individual distros.

<mark_weaver>civodul: heh, yeah, probably so. I haven't looked carefully except to notice that the Qt tarball is absurdly huge.

<zacts>what's going on with chromium and QT?

<mark_weaver>Qt has a policy of bundling almost every library or subprogram that it uses, which means that copies of the source code for all of that stuff is included in the Qt tarball.

<davexunit>what a strange policy.

<ijp>hopefully they aren't also customising the bundled copies

<zacts>huh, that's odd

<ijp>which is all too common

<mark_weaver>I think the rationale from their perspective is so that they can test the entire integration of libraries, so there are fewer bug reports related to variations across platforms.

<mark_weaver>and of course for Windows and OS X, which have no package managers, it's standard practice for each application to bundle everything.

<mark_weaver>but the downsides are (1) that security fixes have to be applied in every application, and (2) that the multiple copies of shared libraries on disk translates to multiple copies of the libraries in RAM.

<mark_weaver>I think the practice it's *turrible*, as wingo might say.

<mark_weaver>*is

<civodul>indeed

<zacts>mark_weaver: should we flamewar the QT mailing lists?

<zacts>(kidding kidding)

<mark_weaver>heh

<paroneayea>mark_weaver: there's no humbleness in that bundle

<paroneayea>(sorry)

<paroneayea>(sorry for multiple reasons :))

<mark_weaver>lol

<mark_weaver>the Qt source tarball is over 300 megabytes.

<mark_weaver>any library that bundles an entire modern web browser... I just don't know what to say...

<mark_weaver>it's like a whole operating system in one tarball

<paroneayea>wow

<taylanub>:)

<taylanub>while I was debugging Qt, the failed-build directory would grow to 5 GB

<mark_weaver>taylanub deserves huge props for dealing with that difficult Qt build problem a while back.

<mark_weaver>I don't want to touch that library with a 10 foot pole :)

<mark_weaver>I used KDE for a few years when it was at version 3.x, and for a long while I waffled between KDE and GNOME, but now I'm quite firmly in the GNOME camp.

<davexunit>people seem to give GTK a lot of flak and praise Qt, but they never seem to mention this issue.

*paroneayea puts qt in a docker container

<mark_weaver>hahaha

<jackdaniel>lately I was wondering, why efl didn't got a strong camp

<jackdaniel>that're well developed libraries with nice and simple toolkit

<mark_weaver>I confess to being mostly ignorant of EFL, but I wonder what advantages it has over the GNOME platform that would justify dividing our attention and applications across yet another desktop platform.

<mark_weaver>noting also that the "GNOME platform" is distinct from "GNOME shell". XFCE is also based on the GNOME platform, for example.

<jackdaniel>hm, gnome is a bloat primarily. Anyway EFL devs care to keep library suitable for both high-end machines (it looks marvelous) and old crap w/o gfx - what looks little worse

<jackdaniel>ok, if you put this that way

<mark_weaver>I dunno, I think that GNOME platform is fairly lightweight, given all of the functionality it provides.

<jackdaniel>maybe, I didn't do deep comparision of both platforms

<jackdaniel>it's self-containing, lightweight with various features tough, with sane interface for foreign libraries

<mark_weaver>that said, if someone would like to package EFL for Guix, as long as it complies with the GNU FSDG, we would of course accept it.

<jackdaniel>yes, that was offtopic a little (my wondering)

<mark_weaver>since each desktop application must choose a platform to base itself on, there is a significant cost to having "too many" platforms. it squanders our development time building duplicate applications for each platform, and meanwhile the proprietary platforms are winning.

<mark_weaver>so, IMO, a brand new platform really needs to justify its existence

<jackdaniel>yeah, but efl is pretty mature (not sure if not older then gtk)

<mark_weaver>I haven't seen the case make for EFL.

<mark_weaver>*made

<jackdaniel>yep, it was 2 years before gtk

<jackdaniel>s/was/is/

<mark_weaver>what was two years before GTK? EFL, or the Enlightenment window manager?

<jackdaniel>hm, efl are libraries grown to build enlightenment, project start dates to 1996

<mark_weaver>okay, but at the time GTK was started, I don't remember having any notion that Enlightenment was more than a window manager.

<jackdaniel>it might be that free software problem isn't too many platforms (it is, I know), but also lack of good marketing?

<mark_weaver>probably so. GNOME's marketing seems fairly good in recent years, but it's hard for a small organization to compete with Apple's huge marketing budget.

<jackdaniel>i agree, I was just comparing gnome and efl. good marketing is hard and cost money and time

<mark_weaver>but EFL's marketing seems extremely weak. It is hardly ever brought to my attention. I nearly forgot that Enlightenment existed since the turn of the century.

<jackdaniel>nobody to blame

<mark_weaver>I remember it getting a lot of buzz in the early years though.

<jackdaniel>yep, that might be a case why it isn't popular

<jackdaniel>well, buzz might be due to being lean - they adapted wayland as first, and are working on tizen support

<jackdaniel>oh, i read it wrong, forget last sentence. Or change it "it might get buzz again soon"

<sneek>Okay.

<mark_weaver>well, IMO, unless it has some major architectural advantage that I don't know about, at this point I think it would be a detriment to our community to divide our attention.

<mark_weaver>IMO anyway, but obviously people are free to work on what they want :)

<mark_weaver>(and we'd gladly accept EFL packages in Guix as long as it's FSDG compliant)

<jackdaniel>first I have to learn guix ^_^

<jackdaniel>btw, what is a target graphics server - X11 or Wayland (in longer perspective) for guix sd?

<mark_weaver>oh, I think we're all eager to move to Wayland when it's ready.

<mark_weaver>but currently we're on X11

*mark_weaver goes afk

<rekado>quick update on the mysterious "permission denied" error: I get it for anything I run as uid 30000.

<rekado>(setuid 30000) (execl "/gnu/store/nnjnqr747xzvfkbf8vj7gassaak35g24-coreutils-8.23/bin/echo" "guile")

<rekado>this, too, will fail.

<rekado>It works when run with uid 1000 (my user account), but it will fail for any other account, all of which have /sbin/nologin as shell.

<mark_weaver>rekado: that makes it sound like some directory is owned by uid 30000, and that the "user" permission bits are more restrictive than the "other" permissions bits.

<mark_weaver>or perhaps it is a group thing instead of a uid thing.

<rekado>oh, sorry, I meant 30001, not 30000.

<rekado>30000 is the gid, 30001 is the first guix build user's uid.

<mark_weaver>well, whatever. the point is, if a directory has owner 30001 and the mode bits are 055, then everyone but that user will be able to access the directory.

<rekado>I'll run a find query to see if there's anything like that in the store.

<rekado>(but why would it be this way? This doesn't make any sense.)

<mark_weaver>well, it would have to be one of the directories that gets looked up while following the symlinks

<mark_weaver>or one of the shared libraries needed by the program

<mark_weaver>or the ld.so

<mark_weaver>afaik, those are the things that could cause the execl to fail and return.

<rekado>but I get this for any user but my own and root. So permissions would have to be even more restrictive/weird.

<mark_weaver>well, maybe something is owned by you then

<mark_weaver>or your group or something

<rekado>nothing in /gnu is owned by uid 1000 or my gid (says "find")

<rekado>if I could be sure this doesn't happen again I'd just reinstall and forget about it.

<mark_weaver>rekado: I would start a shell where running 'echo' fails, and run 'ldd' on the echo executable, and then try 'cat'ing each of those files to /dev/null.

<mark_weaver>each of the shared libraries, I mean.

<mark_weaver>as well as the "program interpreter", which in this case will be the linker loader (ld.so)

<rekado>where would ld.so be located? I can't find it on /.

<rekado>oh, it's versioned.

<mark_weaver>rekado: for that echo, it's /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/ld-linux-x86-64.so.2

<mark_weaver>(I have the same echo on my system)

<mark_weaver>so, from a shell where running 'echo' fails, try 'cat'ing that to /dev/null

<mark_weaver>ditto for the other things listed in the output of "ldd /gnu/store/nnjnqr747xzvfkbf8vj7gassaak35g24-coreutils-8.23/bin/echo"

<rekado>I have no shell session where echo fails; I can only use guile to setuid and then execl.

<mark_weaver>which are: /gnu/store/rsw0dkmv1x2krv9pl1ciai1h235r9nb7-gcc-4.8.4-lib/lib/libgcc_s.so.1 and /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/libc.so.6

<rekado>the only things that fail in a shell session are sudo and su (asking me for a password, even when I'm root).

<rekado>but I suppose I could read them from the guile REPL.

<mark_weaver>running 'echo' from guile fails, but running it from the shell works? using the same user id?

<mark_weaver>this is a totally bizarre problem

<rekado>well, I haven't been able to change the user id on the shell, because "su" asks for the user's password.

<mark_weaver>and apparently unique to you

<rekado>I didn't want to set one.

<mark_weaver>when run as root, 'su' shouldn't ask for a password

<rekado>I know!

<rekado>but: It DOES!

<rekado>I agree that it's totally bizarre.

<rekado>hence my email.

<mark_weaver>well, try opening those files from guile then.

<mark_weaver>after (setuid 30001) I guess

<mark_weaver>(assuming that it's an environment where 'execl' fails on 'echo')

<mark_weaver>you wrote (setuid 30000) above, but I guess that was a mis-copy, right?

<rekado>sure enough: opening ld-2.21.so fails.

<rekado>I meant (setuid 30001) above.

<rekado>(setuid 30001) (open-input-file "/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/ld-2.21.so")

<rekado>ERROR: In procedure open-file:

<rekado>ERROR: In procedure open-file: Permission denied: "/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/ld-2.21.so"

<mark_weaver>okay, can you check the permissions on every parent directory of that file?

<mark_weaver>what's the output of: ls -ld /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21 /gnu/store /gnu /

<rekado>drwxr-xr-x 3 root root 4096 May 17 12:06 /gnu/

<rekado>drwxrwxr-t 751 root guixbuild 479232 May 20 08:26 /gnu/store/

<rekado>dr-xr-xr-x 10 root root 4096 Jan 1 1970 /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21//

<rekado>dr-xr-xr-x 4 root root 4096 Jan 1 1970 /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/

<mark_weaver>can you type in the exact command I did?

<mark_weaver>in the case of symlinks, those trailing slashes change the meaning

<mark_weaver>also, can you show me the contents of /proc/mounts ?

<mark_weaver>I'd also like to see the output of: ls -l /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/ld-2.21.so

<mark_weaver>rekado: ^^

<mark_weaver>I have to go soon, but can spare a few more minutes

<rekado>I think here's something odd:

<rekado>drwx------ 17 rekado 1001 4096 May 20 21:25 //

<rekado>that's the output for ls -ld /

<mark_weaver>bingo.

<mark_weaver>there's the problem

<rekado>yay!

<rekado>thank you!

<rekado>so ... how can this be..?

<rekado>why "//"?

<mark_weaver>chown root.root /; chmod 755 /

<mark_weaver>I don't know

<mark_weaver>I wonder how this happened

<mark_weaver>and yes, I'm curious what's up with the double-slash

<mark_weaver>also, the double-slash on /gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21// in the output you pasted.

<mark_weaver>but if rekado is the only non-root user who can access *anything* on the filesystem, I'd expect lots of breakage all over the place.

<rekado>everything's fine now: sudo works, su works, the guile script runs.

<rekado>thanks a lot!

<rekado>I wonder how this could have happened.

<mark_weaver>np! I recommend rebooting, so that daemons can come up properly.

<rekado>I notice that the gid is not my current gid but the one I had on Fedora.

<rekado>I'm not reusing anything from Fedora but my /home.

<mark_weaver>how did you install this? from the USB installer, or from Guix on Fedora?

<rekado>with the USB installer.

<mark_weaver>did you create this root filesystem from the USB installer?

<rekado>I may have created it before booting with the USB disk.

<mark_weaver>well, anyway, I have to go now. happy hackin!

<rekado>thanks again

<mark_weaver>*hacking

<mark_weaver>np, I'm glad to have this mystery behind us :)

*rekado reboots now

*mark_weaver goes afk

<xaxes`>hmm, is anyone going to make package for i3wm?

<rekado>it feels so good to have a normal system again :)

<taylanub>xaxes`: maybe ... are you? ;-)

<xaxes`>taylanub: maybe, but I don't know how to

<taylanub>xaxes`: you can start by copying another recipe, such as the example recipe in the manual. feel free to ask for help in here and in the mailing list. ultimately you can send a patch to the mailing list created with "git format-patch", after making a commit in the usual style (see other commits that add package recipes)

<xaxes`>okay, I'm prepared, I think: http://i.imgur.com/XbSWKv9.jpg

<taylanub>:-)

<xaxes`>taylanub: making packages on guix on virtual machine isn't any problem, right?

<taylanub>xaxes`: you can install guix on top another distro via the bootstrap binaries

<rekado>xaxes`: no problem, but also not necessary.

<rekado>guix as a package manager on top another GNU system works just fine and doesn't mess with your system.

<xaxes`>hmm, what exactly guix is? a linux distribution?

<rekado>guix is a package manager.

<rekado>"guix system distribution" (GuixSD) is a GNU distribution.

<xaxes`>I'm using emacs for a few month, so it'd be happy if my system'd be as hackable as my emacs

<xaxes`>and it seems like guixsd is the answer :D

IRC channel logs

2015-05-22.log