IRC channel logs

<rgc>hi, just installed guix (from git), created the groups and users for builders, and I'm now trying to install a package (lua).

<rgc>but I get some errors I don't know how to tackle: https://gist.github.com/1cc6497cd128fb7fa1ea

<rgc>I tried adding the --bootstrap option but I get the same 'ERROR: bootstrap binary not found "guile-2.0.9.tar.xz" "x86_64-linux"' error

<rgc>it seems it fails to find guile-2.0.9 in bootstrap.scm:183 . I see it's not there at all... https://gitorious.org/guix/guix/source/d6b5e4bbbdc69f78ccccf0186153d0744b7f399d:gnu/packages/bootstrap/x86_64-linux

<Steap>rgc: is the daemon running ?

<rgc>yup

<rgc>it prints this kind of things

<Steap>oh

<rgc>accepted connection from pid 30351, uid 1000

<rgc>5 operations

<rgc>

<Steap>yeah, ok, so no errors

<Steap>Can you build hello, by running "./pre-inst-env guix build hello" ?

<Steap>(it's one of the simplest packages, so it's expected to work)

<rgc>nope, the same error, bootstrap binary not found "guile ...." "x86_64-linux"

<Steap>hum

<Steap>rgc: what do you have in gnu/packages/bootstrap ?

<rgc> https://gist.github.com/e5ed036cc359f9dc0472

<rgc>but I downloaded guix 0.5

<rgc>and ./configure && make

<rgc>and it's building hello now

<rgc>(using the daemon from the git)

<rgc>....

<rgc>we'll see

<Steap>hum

<rgc>in the 0.5 gnu/packages/bootstrap there's a guile-2.0.9..... file in every subdir

<Steap>yes

<Steap>I don't know exactly how, but it's also there in my checkout of the git repository

<Steap>it must be downloaded by Guix at some point

<rgc>maybe it failed at some point when doing the 'make'

<rgc>if it did, it failed somehow silently

*rgc will check after build hello

<Steap>oh, have you run the bootstrap script ?

<rgc>yup

<rgc>I reran it just now, and it spitted a warning about 'dot' not being available

<rgc>(which is some graphviz thing AFAIK)

<Steap>yes

<Steap>you should install it using your usual package manager

<rgc>running make there while building 'hello'

<rgc>is it always taking that long to build a single package? I guess it caches the deps that are the same for other packages

<rgc>Hello world!

<Steap>the first build is quite long

<Steap>because you have none of the required dependencies

<rgc>oks, that makes sense

<rgc>when trying to create a recipe, I kept getting " killing processes belonging to uid `1001': setting uid: Operation not permitted", until I guix download http.....

<rgc>does that mean that in order to build any package, the sources have to be in my local store already? doesn't make much sense but....

<Steap>no no

<Steap>you're not supposed to get that error

<Steap>what command were you using to build your package ?

<rgc>./pre-inst-env scripts/guix build package-name

<Steap>do you have a full output ?

<rgc>yup

<rgc> https://gist.github.com/30df63229edc7d5f1ffa

<rgc>accepted connection from pid 21176, uid 1000

<rgc>killing processes belonging to uid `1001': setting uid: Operation not permitted

<rgc>358 operations

<rgc>and that's on the daemon

<Steap>are you running the daemon as root ?

<rgc>nope, but I neither when running guix download

<Steap>hum

<rgc>after the guix download , it seems it's building something

<Steap>try running the daemon as root

<Steap>it should be

<rgc>oks. will finish this build first

<rgc>I couldn't get everything work for luajit, but it seems after sudoing the daemon and a few chowns it's working. tomorrow I'll continue with the luajit recipe

<rgc>thanks Steap for your help!

<rgc>bye

<jmd>warning: while fetching http://hydra.gnu.org/nix-cache-info: server is unresponsive

<civodul>Hello Guix!

<jmd>I've posted yet another candidate patch implementing an octave package.

<jmd>(without any propagated inputs)

<civodul>jmd: cool!

<civodul>i'll look at it later today if noone beats me

<Steap>Does one need to do anything special for '(which "bash")' to return the path to bash ?

<Steap>I get "#f"

<civodul>Steap: if you get #f, that means that "bash" is not in $PATH

<civodul>maybe you could check the 'environment-variables' file of the build

<Steap>civodul: hum, funny, /tmp/nix-build-python-3.3.3.drv-0 is empty

<civodul>did the log show anything?

<Steap> http://pastealacon.com/33904

<Steap>I've recently switched from core-updates to master

<civodul>so that's even before the first phase

<civodul>can you show the recipe?

<Steap>it's quite a pain

<Steap>but the funny thing is, if I remove the "which" from the recipe

<Steap>and let the build go on

<Steap>I can see in environment-variables taht the bash used is /nix/store/0r0r5wlg1mzf57haxfkalk62px93gch3-bash-4.2/bin

<Steap>but if I run

<Steap>./pre-inst-env guix build bash

<civodul>aaah yes

<Steap>I get /nix/store/d9wk13sqzi1i39y11ivb90z68llj17sk-bash-4.2

<civodul>that's because environment variables aren't set yet

<Steap>so I have two bashes, for some reason

<civodul>see: gnu-build calls set-paths, which actually sets $PATH et al.

<civodul>(in gnu-build-system.scm)

<civodul>so 'which' cannot be used this early

<Steap>oh, I see

<Steap>so, should I really need it, I could add bash to the inputs and use 'assoc-ref', right ?

<Steap>anyway, I can probably work around this

<Steap>I'm working on the ctypes issue in Python

<Steap>The "PITA" acronym was invented for situations like this one

<sriharsha>what's does that stand for?

<Steap>It's really a huge pain that we cannot use /bin/sh in teh chroot even though it will be available in Guix

<Steap>sriharsha: Pain In The Ass

<sriharsha>ok :)

<civodul>Steap: but can you explain what you're trying to do? :-)

<civodul>i agree that it's annoying, but i wonder how you got there ;-)

<Steap>civodul: well, let's talk about subprocess.Popen()

<Steap>it runs a command, kind of like system(3) in C

<Steap>and you can ask subprocess.Popen() to use /bin/sh

<Steap>it's a very common thing to do

<sriharsha>civodul, does the hydra.gnu.org build recipes from master branch?

<Steap>so when people install Guix and run subprocess.Popen(), they will be able to dothat, and it will work, right ?

<Steap>Since /bin/sh will be a symlink to /nix/store/.../sh

<Steap>but when running the tests, we do not have /bin/sh

<Steap>so they fail

<Steap>(and it's the same kind of error that prevents ctypes from being built)

<Steap>so, to fix the tests, we'd have to ask subprocess.Popen() to use /nix/store/.../sh instead of /bin/sh

<Steap>but well, then the user would not use /bin/sh as they'd expect (and they might want to make /bin/sh point to something else, like /home/cyril/opt/zsh/bin/zsh)

<Steap>Would it hurt purity to have a /bin/sh pointing to /nix/store/.../sh in the chroot ?

<jmd>Steap: I think it would.

<jmd>Normally one substitutes all /bin/sh with the /nix/store/.../sh

<Steap>jmd: yeah, but in my case, it would be quite weird to replace /bin/sh with /nix/store/.../sh

<Steap>Python users really expect to use /bin/sh when using the subprocess module

<jmd>That just shows why python is such a snake!

<jmd>All current packages replace /bin/sh with /nix/store/.../sh

<jmd>The real answer is to send a patch upstream and tell them not to use hard coded paths.

<jmd>They should use $(SHELL)

<Steap>I'm pretty sure they would not want to look into environment variables and lose some time when running a process :)

<civodul>sriharsha: yes, it builds from master, but it seems to be stalled currently :-/

<civodul>Steap: in the chroot yes

<civodul>it would hurt purity

<Steap>erf

<civodul> http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00041.html

*civodul keeps linking to the same message ;-)

<civodul>outside of the chroot, no problem, we'll do that

<Steap>civodul: but it means we can't properly test software

<Steap>How can I run tests with /nix/store/.../sh but have the final binary use /bin/sh ?

<Steap>Am I sure the behaviour will be the same ?

<Steap>It's tricky

<civodul>well yes, it's a tradeoff

*civodul has to go

<jmd>Steap: It is not a problem.

<jmd>When installed, /bin/sh will link to /nix/store/.../sh

<quiliro>hello innovative and free people!}

<jmd>quiliro: They're all on a pilgrimmage right now.

<quiliro>jmd: huh?

<quiliro>a university is playing with my suggestion to collaborate with guix

<viric>fosdem

<quiliro>not with money but with 6 it students

<quiliro>oh fosdem!

<quiliro>live streaming?

<quiliro>and 1 management, 1 art and 1 communication student

<quiliro>10 hours per week....40 weeks

<viric>luckily students don't need money

<quiliro>viric: haha...yes they do...but they need the diploma more

<Steap>Students only need coffee.

<Steap>Pretty much like programmers.

<Steap>quiliro: what would the non-IT students do ?

<quiliro>Steap: the management student will find the needs of the different areas and what to include in specific groupings of packages....for example: what does a the hotel and tourism professional will need in his distro.....s/he will also see that the team works as a team (the other students)

<quiliro>the communications student will work with the art student to see that the presentation and accessibility is good....and he will also make a good name for the distro with press coverage and the likes

<quiliro>the art/design student will make the artistic par..icons, art of the distro, wallpapers, fonts, etc

<quiliro>that is my idea

<quiliro>what do you think? any other areas?

<quiliro>so that will be 2400 IT hours and 1200 non-IT for GUIX

<quiliro>3600 hours...of course they will cost...the knowledge we will give them is not gratis

<quiliro>it is free but not gratis

<quiliro>it is libre

<quiliro>i could not find streaming of fosdem

<Steap>hum

<Steap>call me a grumpy hacker if you like, but I'm a bit afraid of waht the "communication" student might do

<Steap>Because we do not try to force-feed people with Guix :)

<Steap>And well, management is pretty much useless.

<Steap>The art student would probably the most useful, since developers aren't usually extremely gifted when it comes to designing logos and such

<mark_weaver>quiliro: it would probably be best to talk about this over email, on the guix-devel@gnu.org mailing list. I know that civodul prefers to communicate that way for most things.

<jmd> /sigh hydra is unresponsive again

<Steap>Yes, such important matters should probably be discussed over email, since not everybody idles on IRC 24/7

<civodul>yes, good idea

<jmd>civodul: Can you kick hydra for us?

<civodul>i'd do it, but it's too far from me! :-)

<civodul>lemme see

<quiliro>ok...the idea is to make a free distro....is devel the right list?

<quiliro>or gnu-linux-libre

<civodul>hey quiliro

<civodul>quiliro: if the project is specifically about using Guix, the guix-devel is the right list, yes

<quiliro>bonsoir civodul

<civodul>bonsoir ;-)

<quiliro>yes...the guix 100% free distro

<civodul>right, so guix-devel is the place

<civodul>it's the only mailing list actually, so don't be afraid just because it has "devel" in it ;-)

<quiliro>cool

<quiliro>haha

<quiliro>i think guix is the friendliest developer distro for the way it packages the programs

<quiliro>for the little i know about programming

<quiliro>but it loks friendly

<quiliro>i saw the august presentation

<civodul>heh

<quiliro>The big question is: do you think, based on the knowledge level I have told you they have (programming in C, C++ and Java), the students will be able to have the distro ready for use of end users in that timeframe (1 year)?

<quiliro>it should have a desktop

<quiliro>:-D

<quiliro>in "normal-people" language (as my ex-girlfriend used to tell me to talk to her)

<quiliro>s/language/speak/

<civodul>quiliro: probably not, but i do hope the rest of us will have it "ready" by then ;-)

<civodul>for students it should be thought of as a way to get familiar with free software development in general

<civodul>not as a way to build a product

*civodul goes back preparing his talk

*Steap hates the word "product"

<mark_weaver>+1

<Steap>quiliro: it really depends upon their background, I think

<Steap>When I was a student, most of the IT students hated IT :)

<Steap>Needless to say they were not that good.

<civodul>mark_weaver: me too, but i must have been too much exposed to IT marketing newspeak :-)

<quiliro>it is very important that it is usable by the end user in 1 year....what is necessary for that to occur?

<quiliro>will the students be of help or will they be a load?

<quiliro>i wanted them to come to guix because i want guix to grow

<Steap>quiliro: packaging a DE would be the biggest part

<quiliro>but if they will not help, it is better for me that they contribute somewhere else

<quiliro>ok

<Steap>also, even with a DE, it's not gonna be as friendly as Ubuntu within a year

<quiliro>why?

<Steap>well, we'd need a nice GUI such as Synpatic on top of the package manager

<Steap>Synaptic*

<quiliro>don't worry about that part

<Steap>and it's not easy to imagine what the distro is gonna be in a year

<quiliro>the important part is the usability

<quiliro>not installing new packages

<Steap>quiliro: what do you mean by that ?

<Steap>quiliro: I can already use the package manager

<Steap>I know other people do

<quiliro>that the user can write emails, write text documents, spreadsheets, save and list files and use several other programs from the gui (with pretty little icosn,haha)

<quiliro>yes , it is important but that is more important for the project that university is proposing

<Steap>well, we can do that in text :)

<Steap>the GUI part, on the other hand...

<Steap>does the distro have to wokr well, or would a package manager be enough ?

<quiliro>Steap: yes it can be done in text, but that will defeat that project objective

<quiliro>Steap: what do you mean? it is the distro that is needed

<Steap>quiliro: they could work on the GUI part using the package manager on top of a Debian system, for instance

<quiliro>no...the idea is that they want to make a distro...i told them not to make a fork but contribute to guix

<quiliro>but they have to show end user results

<quiliro>not console

<Steap>I see.

<quiliro>unless that serves other purposes....what i mean is that they have to make something something that someone needs