IRC channel logs
2014-01-30.log
back to list of 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>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 <Steap>rgc: is the daemon running ? <rgc>it prints this kind of things <rgc>accepted connection from pid 30351, uid 1000 <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>rgc: what do you have in gnu/packages/bootstrap ? <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>in the 0.5 gnu/packages/bootstrap there's a guile-2.0.9..... file in every subdir <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>I reran it just now, and it spitted a warning about 'dot' not being available <rgc>(which is some graphviz thing AFAIK) <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 <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>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 <rgc>accepted connection from pid 21176, uid 1000 <rgc>killing processes belonging to uid `1001': setting uid: Operation not permitted <rgc>and that's on the daemon <Steap>are you running the daemon as root ? <rgc>nope, but I neither when running guix download <rgc>after the guix download , it seems it's building something <Steap>try running the daemon as root <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! <jmd>I've posted yet another candidate patch implementing an octave package. <jmd>(without any propagated inputs) <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 ? <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 <Steap>I've recently switched from core-updates to master <civodul>so that's even before the first phase <Steap>but the funny thing is, if I remove the "which" from the recipe <Steap>I can see in environment-variables taht the bash used is /nix/store/0r0r5wlg1mzf57haxfkalk62px93gch3-bash-4.2/bin <Steap>./pre-inst-env guix build bash <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>so 'which' cannot be used this early <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 <Steap>It's really a huge pain that we cannot use /bin/sh in teh chroot even though it will be available in Guix <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>(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 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 ? <jmd>Steap: It is not a problem. <jmd>When installed, /bin/sh will link to /nix/store/.../sh <jmd>quiliro: They're all on a pilgrimmage right now. <quiliro>a university is playing with my suggestion to collaborate with guix <quiliro>not with money but with 6 it students <quiliro>and 1 management, 1 art and 1 communication student <viric>luckily students don't need money <quiliro>viric: haha...yes they do...but they need the diploma more <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>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>i could not find streaming of fosdem <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 <jmd>civodul: Can you kick hydra for us? <civodul>i'd do it, but it's too far from me! :-) <quiliro>ok...the idea is to make a free distro....is devel the right list? <civodul>quiliro: if the project is specifically about using Guix, the guix-devel is the right list, yes <civodul>it's the only mailing list actually, so don't be afraid just because it has "devel" in it ;-) <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>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>in "normal-people" language (as my ex-girlfriend used to tell me to talk to her) <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 goes back preparing his talk *Steap hates the word "product" <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 <Steap>also, even with a DE, it's not gonna be as friendly as Ubuntu within a year <Steap>well, we'd need a nice GUI such as Synpatic on top of the package manager <Steap>and it's not easy to imagine what the distro is gonna be in a year <Steap>quiliro: what do you mean by that ? <Steap>quiliro: I can already use the package manager <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>unless that serves other purposes....what i mean is that they have to make something something that someone needs <quiliro>but i want to use that to help freedom -> free distro -> guix <Steap>well, the GPM is already usable <Steap>it just lacks end-user packages <quiliro>you work on making it bootable and they work on end user packages? <Steap>well, packaging stuff is "easy" <Steap>well, you "just" have to fix errors one by one <Steap>well, let's say you want to package "foo" <Steap>there migth be compilation errors <Steap>errors when running configure <Steap>and there's no real doc, because it depends on the software you're packaging <Steap>so, when things go wrong, this can take quite a lot of time to fix <Steap>well, you have to understand what causes them <quiliro>where should someone start if they want to install and then contribute to guixx? <Steap>go through the source code of your package <Steap>3) try to package something that is not yet in Guix <quiliro>unless i changed something in configure <Steap>they may want to try that to see if they're interested in the project <rgc>Steap: I see you're the support guy :) <rgc>I'll be trying to finish my first build today, so expect more questions :)