IRC channel logs


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>but I get some errors I don't know how to tackle:
<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...
<Steap>rgc: is the daemon running ?
<rgc>it prints this kind of things
<rgc>accepted connection from pid 30351, uid 1000
<rgc>5 operations
<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>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>we'll see
<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
<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>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
<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!
<jmd>warning: while fetching 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>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 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
*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
<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>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 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 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>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
<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>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>not as a way to build a product
*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
<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
<quiliro>but i want to use that to help freedom -> free distro -> guix
<quiliro>-> guix package manager
<quiliro>how about gpm?
<Steap>gpm ?
<quiliro>never mind that comment
<quiliro>guix package manager -> GPM
<Steap>well, the GPM is already usable
<quiliro>but i do not want to get into that
<quiliro>i know
<Steap>it just lacks end-user packages
<Steap>so they could work on that
<quiliro>you work on making it bootable and they work on end user packages?
<quiliro>but someone has to learn first
<Steap>well, packaging stuff is "easy"
<quiliro>i will be the one to teach them
<quiliro>i saw the video
<quiliro>it looks very easy
<quiliro>civodul: ^
<Steap>well, you "just" have to fix errors one by one
<quiliro>what errors?
<Steap>well, let's say you want to package "foo"
<Steap>there migth be compilation errors
<quiliro>is there some doc about that?
<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
<quiliro>who to ask when errors present?
<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>1) Install Guix from git
<Steap>2) Build "hello"
<quiliro>i never had a problem compiling
<Steap>3) try to package something that is not yet in Guix
<quiliro>unless i changed something in configure
<quiliro>or missed a dependency
<quiliro>i think i saw those steps somewhere
<Steap>they may want to try that to see if they're interested in the project
*quiliro is reading
<quiliro>Steap: how?
<quiliro>show them civodul's video?
<Steap>or read a recipe
<Steap>copy/paste it
<Steap>modify it
<quiliro>teach them to install guix distro?
<Steap>see what happens
<Steap>come here for help
<quiliro>thank Steap
<rgc>Steap: I see you're the support guy :)
<rgc>I'll be trying to finish my first build today, so expect more questions :)