IRC channel logs

<zacts>oh, I just have an outdated automake.

<zacts>I need to figure out how to install one locally.

<civodul>guix package -i automake :-)

*civodul goes to bed

<civodul>good night/day!

<zacts>ino this is for the bootstrap process to even get guix installed in the first place.

<zacts>seriously, after my port of guile-2 to FreeBSD, and my initial deblob scripts for NuBSD Fire. I'm done with it.. I would rather work on guix. (scheme) is fun too.

<zacts>I can't wait until I can switch over to guix as my main distro.

<zacts>first, I need to get a new automake installed.

<mark_weaver>yeah, I'm looking forward to it as well :)

<zacts>although, I am still interested in Minix3 for educational reasons..

<mark_weaver>I'm using Guix exclusively for my user environment though.

<zacts>mark_weaver: I'm going to bootstrap guix. I like slackbuilds, but guix is much nicer.

<mark_weaver>but I should warn you that it's a fairly minimal system at this point.

<zacts>mark_weaver: oh, yeah. I've tried guix once before, so yeah, and I can see the package list.

<mark_weaver>I use a minimal window manager called ratpoison, and otherwise basically live in emacs.

<zacts>but, yeah. my needs are fairly minimal.

<zacts>xterm + i3 + bash/zsh + vim + emacs + tmux + cli tools

<mark_weaver>is i3 a window manager?

<zacts>mark_weaver: oh yep!

<zacts>maybe I'll port it to guix!

<zacts>it doesn't require a ton of dependencies, and is fairly minimal.

<mark_weaver>sounds good! when I switched to a fully guix user environment, that was a huge motivation to add packages that I needed.

<mark_weaver>maybe it will be the same for you

<zacts>probably, yeah.

<zacts>I grow tired of some of the opinionated BSD developers.. I like free software, but I do like alternative OS, and educationally I like to study different ways of doing things.

<zacts>some of their opinions are unwarranted, but some I do agree with, but hm..

<zacts>I would much rather work on software with a nice welcoming environment, than an opinionated elite community.

<zacts>also, I really do value the ability to hack code, and not have it become proprietary..

<zacts>anyway.. enough of my ramblings on my frustrations with the BSD community.

<zacts>Although, Minix3 is nice and welcoming, and I like that.

<mark_weaver>yeah, I think copyleft is important, personally.

<mark_weaver>and community, as you said.

<mark_weaver>I started out in the BSD world long ago myself.

<mark_weaver>first 386BSD 0.1 in the early 90s, which became NetBSD, which was my home for a long time.

<mark_weaver>It wasn't until around 1999 or so that I switched to Debian.

<mark_weaver>(I forget exactly when)

<mark_weaver>well, before that I was on MacOS and NeXT, but that's really ancient history :)

<zacts>interesting..

<zacts>I think guix will be good, not only for philosophical reasons, but also I think it will help improve the coherentness of the entire gnu and gnu/linux system.

<zacts>I just invented a new word. \\o/

<mark_weaver>heh

<zacts>but the ability to really work with how dependencies work, and how one can build them from any point in the spaghetti of what your package tree looks like at any given moment.

<zacts>rollbacks and snapshots sound cool too.

<mark_weaver>I want to run the newest software, but I also want a stable system. These two desires seemed irreconcilable for a long time, but I think Guix allows it.

<zacts>anyway, let me see how this automake builds.

<zacts>mark_weaver: me also. I also like rolling-release + stability, but also the ability to never have to reinstall.

<zacts>full reinstall that is

<mark_weaver>right

<zacts>I highly value the philosophy of 'the grandma test' and you get a new OS, plug it in, and it works for the next 10 years with almost no problems.

<zacts>the grandma test = if my grandma can use it, then it's stable / reliable / good clean software.

<mark_weaver>if you have trouble with the automake thing, another way is to start with the guix-0.5 tarball, and then use it to install automake and everything else you need, and then use that to bootstrap from git.

<zacts>:D

<zacts>hm.. ok.

<mark_weaver>well, I suppose that's suboptimal now because the recent switch from /nix/store to /gnu/store

<mark_weaver>I changed my mind. get automake working :)

<mark_weaver>I could build a tarball for you, if you like.

<zacts>hah

<mark_weaver>(that's another option)

<zacts>mark_weaver: well, let me see what I can do first.

<mark_weaver>okay

<mark_weaver>make sure to do a "git pull" if you haven't recently, because the change to /gnu/store is fairly recent.

<zacts>oh, good to know.

<zacts>I've got it locally installed.

<zacts>it was totally simple with ./configure --prefix

<zacts>it being automake

<mark_weaver>you might have to set ACLOCAL_PATH before running ./bootstrap

<didi>I wonder why using a toplevel directory.

<mark_weaver>it needs to be able to find all the relevant .m4 files (typically in /usr/share/aclocal)

<mark_weaver>if, after running ./bootstrap, the ./configure script fails on a line that has an unexpanded m4 macro (i.e. all caps, and clearly not shell code), it probably means that you're missing a relevant .m4 file or that it couldn't be found.

<zacts>yeah, HACKING explains all of this.

<mark_weaver>the automake that came with slackware would be configured to look in the right places by default. your home-built one might be looking in different places by default.

<mark_weaver>ah, indeed it does!

<mark_weaver>zacts: btw, I suggest that you pass --localstatedir=/var to Guix's configure.

<mark_weaver>that will put the log files in /var/log/guix and the guix state in /var/guix

<mark_weaver>otherwise, they'll end up in $prefix/var/log/guix and $prefix/var/guix

<zacts>oh, neato

<zacts>will do

<mark_weaver>anyway, time for me to sleep.. good luck!

<zacts>thanx

<zacts>mark_weaver: thanks for your help. I now have the latest git version of guix installed on my slackware box.

<zacts>you guys will have to tell me how to import a new package without needing to rebuild all of guix each time.

<zacts>the proper way of doing that.

<zacts>I'm really interested in importing i3 now. that sounds like it would be cool.

<civodul>Hello Guix!

<zacts>'lo civodul

<phant0mas>hello civodul

<zacts>so do I issue: ./pre-inst-env guix build

<zacts>if I want to add a package without rebuilding all of guix?

<zacts>or what is the proper way to do this?

<phant0mas>I started writing a gcc -sans free in cross-base especially for hurd because still something wants to be build as a 64 bit

<phant0mas>but it seems I have to do something with binutils as well

<phant0mas>because in the config.log

<phant0mas>the only thing pointing to 64 bit is this part

<phant0mas>COLLECT_GCC=gcc

<phant0mas>COLLECT_LTO_WRAPPER=/gnu/store/z8qifq9172ad17a7mxg9w8jq51axwwqr-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper

<phant0mas>Target: x86_64-unknown-linux-gnu

<atheia>Hi Guixers,

<atheia>Quick question — just ran a clean git install of Guix on a vanilla Debian Squeeze install (with automake from sid)

<atheia>About 6 tests failed in the suite

<atheia>I presume this is not expected?

<atheia>Also the substituter returns error 500s.

<atheia>Does anyone know whether this is currently expected?

<rgrau>hi. I have a question regarding the recipes versionning. When a new version of a package comes out, if I update the recipe and you push it to the repo, what happens to packages that depend on the old version? do you keep every recipe for every version?

<civodul>zacts: ./pre-inst-env guix build the-package

<civodul>zacts: see HACKING and the manual

<zacts>ok. I see it now. thanks.

<civodul>phant0mas: what?

<civodul>rgrau: the packages already in the store are still there

<civodul>so for instance, GCC 4.7 is installed in your profile

<civodul>then somebody pushes the definition for 4.8

<civodul>but that's no problem: your profile still refers to GCC 4.7

<kindahero>hi

<civodul>hey, kindahero

<kindahero>civodul: can I ask some Q about gsoc

<civodul>yes, sure

<kindahero>should I write to GNU as well while applying?

<civodul>to GNU? what do you mean?

<civodul>you should first email guix-devel@gnu.org, about your plans

<civodul>you're lucky: you can reuse Xue's plan ;-)

<civodul>then you must apply on google-melange too

<kindahero>;)

<civodul>more importantly, you must familiarize yourself with the software

<civodul>have you played a bit with Guix?

<kindahero>yes. so far I built guix

<kindahero>tried to read info doc

<civodul>don't just try ;-)

<kindahero>haha

<kindahero>I was just honest

<kindahero>though :)

<civodul>a good thing to do to get started would be to try to add a package

<civodul>a simple one

<kindahero>I am trying to netcdf

<civodul>ah right, great

<civodul>then do ask on this channel whenever you run into problems

<kindahero>one question was, is there any way we can specify about optional dependencies?

<kindahero>I mean netcdf can be built with/without hdf5

<kindahero>right now I am trying to built manually from the source.

<civodul>well, each package definition specifies a list of dependencies

<kindahero>before packaging.

<civodul>if you want to define a variant of a package with a different set of dependencies, then that's possible

<civodul>were you able to build stuff with Guix?

<kindahero>no, not yet

<kindahero>I am reading package definitions in guix folder (math.scm)

<kindahero>I am trying to plugging netcdf in one of the sample package

<kindahero>is there any way I can test that without building whole guix again?

<kindahero>by the way, where to get SHA of downloading package.?

<kindahero>for eg, netcdf download page

<kindahero> (http://www.unidata.ucar.edu/downloads/netcdf/index.jsp) doesn't put one.

<civodul>kindahero: as a first step, could you run "guix package -i hello"?

<civodul>that will install GNU Hello in your profile

<kindahero>okay.

<civodul>and to do that, it will end up building any prequisites, including GCC

<civodul>so that's going to take some time, but it's important that it works

<civodul>as for the SHA256, please see the "Defining Packages" section in the manual

<kindahero>ok thanks.

<rgrau>kindahero: you can try this tut I wrote with all my love for future newbies-like-me :) http://puntoblogspot.blogspot.com.es/2014/02/guix-tutorial.html

<rgrau>it's like a compressed step by step guide to superbasic package building and contributing. I'd like to write another tut for more complex packages, but first I have to succeed building more complex packages :)

<rgrau>civodul: regarding the versions, makes total sense. I'll send an update to the luajit package later

<civodul>cool

<civodul>and thanks for the tutorial, it's certainly helpful!

<phant0mas>civodul: just came back

<phant0mas>do you remember the errors I have ?

<phant0mas>Error: incorrect register `%rax' used with `l' suffix

<phant0mas>with hurd glibc?

<phant0mas>I changed the gcc recipe in crossbase.scm

<phant0mas>so I can be sure that everything targets i686

<phant0mas>sorry for not being clear before, I was in a hurry for a course :P

<civodul>sorry, i'm lost

<phant0mas>okay, let me explain again

<phant0mas>I am building the hurd glibc using the san free gcc

<phant0mas>ok?

<phant0mas>and I was getting the error " Error: incorrect register `%rax' used with `l' suffix"

<phant0mas>and according to rbraun somethings tries to get built as 64 bit

<phant0mas>not 32

<phant0mas>so I modified the gcc sans free recipe I was using

<phant0mas>to make sure I had the right crosscompiler

<phant0mas>but I was still getting the same error with before

<phant0mas>so I checked the config log

<phant0mas>of hurd's glibc

<phant0mas> http://pastebin.com/raw.php?i=9QhzgM57 here it is

<phant0mas>and I saw it was still using a 64 bit lto-wrapper

<civodul>hmm

<phant0mas>any suggestions?

<civodul>phant0mas: could you post to guix-devel your current patch, the exact command line you typed, and whatever logs you have?

<civodul>because i think i don't understand everything

<civodul>i'll be away from keyboard this week-end, though

<phant0mas>okay I will search it a little more on my own now that I finished my courses for today and I will send it on the guix-devel afterwards if I still have a problem

<civodul>great!

<teythoon>:)

<phant0mas>civodul: I think I found the problem , I wasn't using a cross-mig

<phant0mas>hey teythoon

<teythoon>hi phant0mas :)

<phant0mas>I am having some problem with my cross-toolchain but I am working on that

<phant0mas>problems*

<civodul>good

<phant0mas>cross-mig recipe works perfectly

<phant0mas>now let's try again

<phant0mas>with glibc

<mark_weaver>that's good!

<rigelk>hi #guix ; end of my exams, back on guix :)

<davexunit>woo!

<rigelk>is hydra back up ? is there a way to download binaries of my toolchain so that i can (at last) compile doxygen ?

<davexunit>I actually have no idea. I've been out of the loop and civodul signed off shortly before you joined.

<rigelk>woops. seems we miss each other every time ^^'

<davexunit>time zones be damned.

<rigelk>+1

<rigelk>what time is it, in your place ?

<davexunit>1:14 PM

<davexunit>eastern time.

<rigelk>6:16 PM down here :)

<rigelk>and i suppose we've got people from all over the world

<rigelk>advantage: the irc chan should always be animated :]

<mark_weaver>rigelk: I believe that hydra is back up, and building packages that are based in /gnu/store.

<mark_weaver>rigelk: so if your guix is configured to use /gnu/store, then it should be able to download binaries from hydra. I'm not sure if hydra is still serving binaries for /nix/store or not.

<rigelk>btw, i there a way to be informed of hydra's status ?

<mark_weaver>visit http://hydra.gnu.org/

<rigelk>mark_weaver: how can i set up the new /gnu/store ?

<mark_weaver>rigelk: well, it's the default in recent git master, so if you build from the latest git, that will be the case.

<mark_weaver>the ./configure option is --with-store-dir=/gnu/store

<mark_weaver>hmm, looks like there are still problems on hydra.

<rigelk>is the configure option defaulted in the git master ? (do i still need to type the option with an updated guix source ?)

<mark_weaver>I'm sorry, I don't know what the deal is with subtitutes at the moment. I've never used them myself.

<mark_weaver>it looks like there are not yet any substitutes for /gnu/store on hydra

<mark_weaver>rigelk: If you need substitutes, I'm afraid you may have to wait a bit more.

<mark_weaver>civodul is gone away for the weekend.

<mark_weaver>s/is/has/

<rigelk>:/ I think I'm gonna build on another computer for the moment

<mark_weaver>if you build from current git, you don't need to specify --with-store-dir=/gnu/store, but there's no harm in specifying it. I'd also recommend specifying --localstatedir=/var

<mark_weaver>I actually think there's a good chance that you might get substitutes if you use the guix-0.5 tarball for now, but I can't say for sure.

<mark_weaver>(if you use the 0.5 tarball with /nix/store as the store dir, which is the default for that version)

*mark_weaver wishes he had just kept his mouth shut...

<mark_weaver>better for someone who actually uses substitutes to answer this...

<rigelk>eh, that's still a hint :)

<mark_weaver>the thing is, going forward we'll be using /gnu/store, and those will probably be on hydra within a week, so it seems a bit silly to install a new guix with /nix/store, especially if you intend to contribute.

<mark_weaver>oh, wait.

<mark_weaver>I was misreading things on http://hydra.gnu.org/

<mark_weaver>it looks like there are, in fact, a great many substitutes available for current git master with /gnu/store as the store dir.

<mark_weaver>so just build from current git master and it should be fine, I think.

<mark_weaver>rigelk: ^^

<mark_weaver>sorry for the confusion...

<rigelk>no problem :)

<mark_weaver>see http://hydra.gnu.org/project/gnu

<mark_weaver>85% of packages built on master branch.

<rigelk>oh, and what's with the other project, guix ?

<rigelk>0% ?

<rigelk>is it the old branch git version with /nix/store ?

<mark_weaver>yeah, don't worry about that one. that's what was throwing me off before. you should be looking at "gnu".

<mark_weaver>that's trying to build the guix release tarball, but we're in a transitional state right now.

<rigelk>it it occuring often ?

<mark_weaver>no

<mark_weaver>hydra was just moved to new machines.

<mark_weaver>it's still not perfect, but the important stuff is working now.

<rigelk>oh, ok :)

<phant0mas>mark_weaver: hurd-headers recipe in hurd.scm has as a native-input mig

<phant0mas>and then me when cross-compiling the hurd-headers in cross-base.scm I do this

<phant0mas>(native-inputs `(("cross-gcc-hurd" ,xgcc)

<phant0mas>("cross-binutils" ,xbinutils)

<phant0mas>("cross-mig" ,xmig)

<phant0mas>,@(package-native-inputs hurd-headers)))))

<phant0mas>Which of the 2 mig will be used? the new one or the old one?

<mark_weaver>I don't know. You should probably remove it, using alist-delete.

<phant0mas>ok

<mark_weaver>so do something like ,@(alist-delete "mig" (package-native-inputs hurd-headers))

<mark_weaver>(assuming that "mig" is the string you used in hurd-headers)

<mark_weaver>this is really a question for civodul, but that should get you moving int he meantime.

<mark_weaver>s/int he/in the/

<mark_weaver>actually, I can tell you definitively that if you don't delete the old one, both will be included. however, I don't know which will take precedence.

IRC channel logs

2014-03-14.log