IRC channel logs

2014-02-15.log

back to list of logs

<civodul>i'd need to wrap my head around that thing to say something clever ;-)
<civodul>i don't know why, it's never trivial to think about the effect of these things
<civodul>:-)
<mark_weaver>I'll give it some thought. thorny issues, indeed.
<mark_weaver>I suspect that the emacs I built with 64K page size (the so-called "maximum architectural page size" for MIPS) will work with kernels that use a smaller page size. I'll have to verify that though.
<civodul>ah, ok
<civodul>but what happens with huge pages on Intel?
<mark_weaver>if that's true, then I think it would suffice to make sure all build machines use the maximum architecture page size.
<civodul>yes
<mark_weaver>huge pages are different. they are always used explicitly (at least by the kernel).
<mark_weaver>the ABI of each platform specifies the maximum architectural page size, and ELF binaries are linked appropriately.
<mark_weaver>however, there's still a problem that users who build emacs on their own machine will not be able to upgrade their kernel without it breaking, and it's a pain to fix that, because it's hard to convince Guix that it should delete the old one and rebuild.
<mark_weaver>maybe a package should be able to declare that it depends on the page size, and then have that included in the hash calculation.
<civodul>well i've never heard about such a problem with NixOS on Intel
<mark_weaver>but that's a pain for different reasons. then we'd need build machines for each page size.
<civodul>and i don't think it has any workarounds for Emacs
<civodul>but maybe that's just because everyone uses 4k pages in practice on Intel
<mark_weaver>maybe so.
<civodul>so at least we'll have to pay extra attention for mips
<mark_weaver>4K is the only supported page size for the i686 ABI at least. not sure about x86_64 off-hand.
<civodul>ok
<mark_weaver>I just looked it up. the x86_64 ABI says that page size can be any power of two between 4K and 64K.
<mark_weaver>hmm. I wonder how this doesn't come up on x86_64.
<waxysubs>mark_weaver just discovered that after opening a frame on X with emacs multi-tty, and then closing it, if the X server is killed the entire emacs dies.
<waxysubs>apparently only with gtk+ builds, according to the error message.
<civodul>:-)
<civodul>oh
*civodul -> zZz
<waxysubs>good night!
<civodul>good night/day!
<zacts>morning guix
<zacts>mark_weaver: we should have a working core of NuBSD Fire, based on FreeBSD, without ports no later than July of this year. I will try to get some patches for the beginnings of a deblobbed kFreeBSD kernel and gnu userland for guix around that time also.
<zacts>civodul: ^
<zacts>at least we will have a working pf firewall for power users by July..
<phant0mas>I am back guys,finished with some errands
<phant0mas>now back to mach
<phant0mas>how can I set let's say CC='gcc -m32' through guile before the configure flags?
<mark_weaver>I don't think you should do that.
<mark_weaver>that should be handled by the fact that target is i686-gnu
<phant0mas>according to mach building documentantion
<phant0mas>and my yesterday testing I have to
<mark_weaver>did you use a cross-compiler in your testing yesterday?
<mark_weaver>did you pass --target=i686-gnu yesterday?
<mark_weaver>--host, rather
<phant0mas>yes
<phant0mas>CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu
<phant0mas>CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --prefix= --host=i686-unknown-linux-gnu
<phant0mas>I had to use this
<phant0mas>in order to build it in a 64 bit machine
<mark_weaver>we cross compile things from 64-bit to 32-bit without that flag all the time. that's how hydra builds the i686 binaries.
<mark_weaver>I think you should talk to civodul about this.
<mark_weaver>setting CC, LD, and CPP like that is definitely not going to be correct in Guix, anyway.
<phant0mas>ok mark you know better
<phant0mas>civodul: I need you :P
<mark_weaver>even braunr thought you should set CPPFLAGS instead (I saw), which would be better, but still shouldn't be needed on Guix.
<phant0mas>yeh he told me the same
<phant0mas>I was just following the instructions...
<mark_weaver>I know.
<phant0mas>I will keep looking in other guile recipes for help
<phant0mas>another question
<phant0mas>where should be install the mach headers in a system?
<phant0mas>because we only need them in order to build the kernel
<phant0mas>and they have to be in the same folder with mig
<mark_weaver>every package built on guix goes into its own private directory /nix/store/<BIGHASH>-<PACKAGENAME>-<VERSION>
<mark_weaver>that will be added to CPATH automatically during the build of anything that declares mach-headers as an input
<phant0mas>ok
<mark_weaver>well, <that-dir>/include, rather.
<mark_weaver>so you should be installing in <OUT>/include/??? where <OUT> is the result of (assoc-ref outputs "out")
<mark_weaver>that <OUT> will automatically be passed as --prefix to configure by the build process by default.
<mark_weaver>so if there's some make target that installs just a headers, you could just use that.
<mark_weaver>otherwise you'll have to do the copy manually.
<mark_weaver>as for how to set CPPFLAGS and LDFLAGS (which is what you should be setting instead of CPP/CC/LD), use #:configure-flags as an argument. Something like (arguments '(#:configure-flags '("CPPFLAGS=-m32 -E -x c -undef -ansi" "LDFLAGS=-melf_i386")))
<phant0mas>I think I got it
<phant0mas>:-D
<phant0mas>now back to work
<mark_weaver>okay, happy hacking!
<mark_weaver>when doing test builds, pass -K to "guix build" so that it will keep the build directory around (in /tmp/nix-build-...) in case of failure.
<phant0mas>ok
<zacts>is phant0mas working on a guix HURD distro?
<mark_weaver>he's working on porting Guix to HURD, yes.
<zacts>neato
<mark_weaver>phant0mas: It's possible you might need "CFLAGS=-m32" as well. again, I don't see why these things should be necessary, but maybe I'm wrong.
<mark_weaver>another possibility is that some of these things are needed because the build system in these packages isn't robust for cross-compilation, so they need some help.
<mark_weaver>civodul is much more knowledgeable about these things, though.
<phant0mas>Okay, I am getting the error "configure: error: C compiler cannot create executables"
<phant0mas>but before I get into that first have a look at my recipe, if I have done anything wrong there
<phant0mas> http://pastebin.com/raw.php?i=vUVbDZsN
<mark_weaver>hi civodul!
<civodul>howdy mark_weaver!
<mark_weaver>thanks to guix, I'm connected to freenode using tor. but I'm curious, for you it identifies you as (~user@gateway/tor-sasl/civodul), but for me it's (~user@gateway/tor-sasl/markweaver/x-14656265)
<mark_weaver>do you know off-hand why I have that suffix and you don't?
<civodul>hmm no
<civodul>maybe viric knows?
<civodul>perhaps there's another mark weaver, without underscore or something?
<mark_weaver>ah, could be.
<mark_weaver>phant0mas: civodul is here now, maybe he can help.
<civodul>phant0mas: i actually did what you're working on a couple of years ago in Nixpkgs
<civodul>so https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific/gnu might help
<mark_weaver>civodul: phant0mas thinks that "-m32" has to be passed to the compiler for mach. What do you think?
<mark_weaver>(he took that from some docs on compiling mach)
<mark_weaver>I thought it probably shouldn't be needed.
<civodul>something like that is needed when building from a 64-bit machine
<civodul>so phant0mas is probably right
<mark_weaver>okay, I stand corrected :)
<civodul>heh ;-)
<civodul>turns out that Mach only has preliminary 64-bit support
<mark_weaver>I thought that would be taken care of by the cross-compiler. Do we pass -m32 when cross-compiling i686 binaries from a 64-bit machine?
<mark_weaver>well, you needn't educate me on these things. I don't want to distract you from your potluck :)
<civodul>Mach doesn't need a cross-compiler to be built
<civodul>heh, np :-)
<phant0mas>when I was building from my 64 bit machine I needed the extra flags, but in guix with only the flag--host=i686-unknown-linux-gnu will it be compiled right?
<mark_weaver>I think that host is wrong if you're on a 64-bit machine.
<mark_weaver>do you need to pass --host?
<phant0mas>outside guix yes
<mark_weaver>I think that's probably why you got the error "configure: error: C compiler cannot create executables"
<phant0mas>and in the guix recipe if I don't pass --host I get in configure configure: error: unsupported combination of cpu type `x86_64' and platform
<phant0mas> `default'.
<mark_weaver>I'm sorry, I don't know off-hand what's going on.
<mark_weaver>One guess is that it's trying to build and run a 32-bit executable, and the 32-bit libraries are missing.
<phant0mas>in my machine I had to change my version of gcc with gccmultilib
<phant0mas>so probably it has to do something with the not being able to find the 32 bit libraries in guix
<mark_weaver>it might be that you need to pass "--system=i686-linux" to "guix build"
<civodul>phant0mas: in https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/gnu/mach/default.nix i used --build=i686-linux-gnu
<phant0mas>yep I saw it :-)
<civodul>actually i'm not sure if was sufficient
<civodul>yeah using --system=i686-linux will do the right thing, but it's a bit of a sledgehapper
<phant0mas>I will try calling guix build with --system=i686-linux
<civodul>*sledgehammer, even
<civodul>phant0mas: did you try passing #:configure-flags '("CFLAGS=-m32") ?
<phant0mas>yep
<mark_weaver>civodul: won't he need 32-bit libraries in the chroot?
<mark_weaver>that's why I suggested --system
<civodul>ah
<civodul>well, i think it should work, beause Mach doesn't link against anything
<phant0mas>okay downloading 32 bit libs with guix
<phant0mas>gonna need sometime
<phant0mas>:P
<mark_weaver>civodul: maybe so, but it seems that configure compiles a test program. he got "configure: error: C compiler cannot create executables"
<civodul>arg, ok
<civodul>maybe #:make-flags then :-)
<mark_weaver>what would he add to #:make-flags to solve this problem?
<phant0mas>with make-flags I made it to call make install-data
<phant0mas>in order to install the headers
<mark_weaver>phant0mas: I think that won't work as you expect.
<mark_weaver>phant0mas: I think you probably need to delete the 'build' phase and replace the 'install' phase.
<mark_weaver>otherwise, it will simply add those flags to both of the default make commands (one for build and one for install)
<mark_weaver>so you'll still end up compiling and installing everything
<phant0mas>so canselling the build
<phant0mas>and fixxing that
<phant0mas>(alist-delete 'build %standard-phases)
<phant0mas>am I right?
<mark_weaver>yes
<phant0mas>I am getting the hang of it :-D
<phant0mas> (alist-replace
<phant0mas> 'install ,install-phase)
<phant0mas>and then write the install-phase
<mark_weaver>right, something like (alist-replace 'install ,install-phase (alist-delete 'build %standard-phases))
<phant0mas>ok
<mark_weaver>install-phase would be something like '(zero? (system* "make" "install-data")) I guess
<mark_weaver>(I'm assuming you're right about 'install-data' being the appropriate target.
<mark_weaver>)
<phant0mas>I think I am :-)
<mark_weaver>oh, sorry, you need to wrap that in (lambda _ ...) also..
<phant0mas>don't worry I found a similar one in linux.scm
<phant0mas>:-)
<mark_weaver>so (let ((install-phase '(lambda _ (zero? (system* "make" "install-data"))))) ...)
<mark_weaver>cool
<phant0mas> http://pastebin.com/raw.php?i=z7LdsYin
<phant0mas>how about this?
<mark_weaver>remove the ","
<mark_weaver>(and then you need a third argument to 'alist-replace')
<mark_weaver>also, I think you shouldn't use DESTDIR. That should be handled by the --prefix arg to configure, no?
<mark_weaver>In a proper build system, it will install in $DESTDIR$PREFIX
<mark_weaver>so I think you'll duplicate the prefix.
<phant0mas>so I remove that
<mark_weaver>if so, that means you don't need 'out' at all, so you can remove the inner 'let' and also the "lambda* (...)" can be simplified to just "lambda _"
<mark_weaver>(because you don't need the arguments)
<phant0mas>(lambda_(zero?
<phant0mas> (system* "make" "install-data"))) like that?
<mark_weaver>right
<phant0mas>and what should be the third argument for alist-replace?
<civodul>phant0mas: see guix/build/utils.scm
<civodul>(alist-replace key value alist)
<phant0mas>ok
<civodul>key = 'install
<civodul>value = (lambda* ...)
<civodul>alist = %standard-phases
<phant0mas>yeap I found it in utils.scm
<phant0mas>yep*
<phant0mas>thnx civodul
<civodul>admittedly this should all be documented in the manual too
<Steap_>Hey, just needed some info about the chroot (not sure whether this is documented)
<Steap_>1) I'm pretty sure we do not have access to /etc/group, right ?
<Steap_>2) What is getuid(2) supposed to return ?
<mark_weaver>/etc/group is usually world-readable. not sure why it wouldn't be in the chroot
<mark_weaver>as for the uid in the build process, I'm not sure. Why does it matter?
<Steap_>mark_weaver: I'm trying to fix the Python tests
<Steap_>and the issues arise
<mark_weaver>The build is done as one of the guix-builder users, but maybe there's a private uid namespace, dunno.
<phant0mas> http://pastebin.com/raw.php?i=6p7fmzJ9
<phant0mas>is it right now?
<Steap_>the '0' id cannot be found by getgrgid(), for instance
<mark_weaver>phant0mas: no
<mark_weaver>phant0mas: 'alist-delete' and 'alist-remove' are not imperative operations. they don't modify anything. they return a new alist that's a modified version of the input alist.
<phant0mas>so I have to change the alist
<mark_weaver>you need to start with %standard-phases and then return a modified version. you do this in two steps. first you get a version with the build phase removed, and then, starting from that one, you create another one with the 'install' phase replaced.
<mark_weaver>no, you're not changing anything.
<mark_weaver>you're creating a new alist, based on %standard-phases.
<mark_weaver>(alist-delete 'build <alist>) returns a new alist that's the same as <alist> but with the 'build' phase removed.
<phant0mas>aaa I get it
<mark_weaver>and similarly for 'alist-replace'.
<phant0mas>how do I make it to use the new list?
<mark_weaver>the expression immediately following "#:phases" is the alist to use.
<mark_weaver>s/is/returns/
<mark_weaver>this is the functional programming style, as opposed to the imperative programming style that's most common.
<civodul>Steap_: /etc/group is available (see guix.texi in master), and getuid returns a uid :-)
<Steap_>civodul: hehe
<Steap_>civodul: is it the same "/etc/group" as on my system ?
<mark_weaver>Steap_: no, that would be an impurity.
<Steap_>mark_weaver: yes
<civodul>Steap_: no, see guix.texi
<Steap_>mark_weaver: so my real question si "what's the content of the 'fake' /etc/group ?"
<Steap_>ok
<mark_weaver>Steap_: it's a very minimal, fixed /etc/group. not sure what's in it off-hand, but not much.
<civodul>just an entry for the user's group
<Steap_>@file{/etc/group} with an entry for the user's group;
<Steap_>so that would be the 'guix-builder' group
<civodul>yes
<Steap_>ok
<Steap_>and is the gid fixed ?
<civodul>i think so
<mark_weaver>Steap_: if you search for "etc/group" in the nix directory, you'll have your answers.
<Steap_>ok
<Steap_>oh
<civodul>but the uid is taken from the build user pool
<mark_weaver>it seems that it uses whatever getgid() returns, which is probably an impurity unless there's a private uid/gid namespace.
<Steap_>nice
<Steap_>yes, so the only gid defiend in 1001
<Steap_>and the Python test use gid 0
<Steap_>so that explains the failure
<civodul>arf
<Steap_>I'll try by replacing that with 1001
<civodul>so there could be a case for adding a 'root' group
<Steap_>oh that'd be even better
<mark_weaver>Steap_: no, that won't work on other people's system.
<mark_weaver>*systems.
<Steap_>oh, the gid depends on my system
<Steap_>hum
<mark_weaver>personally, I'd just remove those tests.
<mark_weaver>s/remove/disable/
<Steap_>btw, how would it be an impurity to add /nix/.../bin/sh in the chroot, with 'sh' pointing to (which "sh") ?
<civodul>if it's in the store, it's not an impurity
<mark_weaver>Steap_: it might or might not be an impurity, but it would make it less likely for us to notice if /bin/sh was being improperly used somewhere.
<Steap_>civodul: oh no right, I'd need /bin/sh
<Steap_>not /nix...
<mark_weaver>all of those things really need to be patched anyway.
<Steap_>the main issue is that in the GNU system, /bin/sh will be available
<Steap_>but it isn't in the chroot
<civodul>yes
<civodul>why do you need /bin/sh?
<Steap_>so we have to patch countless cases of '/bin/sh' => /nix/.../sh'
<mark_weaver>but we shouldn't be producing packages that reference /bin/sh
<Steap_>civodul: nothing specific
<Steap_>just a general issue
<civodul>normally 99% of them are patched automatically
<mark_weaver>The /bin/sh will be for normal users
<Steap_>anyway, /bin/sh is a POSIX requirement
<Steap_>civodul: yeah, in the shebangs
<Steap_>but not elsewhere
<civodul>right
*civodul can hear shebangs scream "we are the 99%!"
<Steap_>I had to patch Python's subprocess so that it uses /nix/.../sh instead of /bin/sh when the latter isn't available
<mark_weaver>we want to produce packages that never make use of that /bin/sh requirement.
<mark_weaver>hehehe
<Steap_>it sort of sucks because it adds a branch, and branches are not free :)
*Steap_ is stuck in the 80's
<civodul>just make sure Python never refers to /bin/sh
<Steap_>well, I have to make sure it does
<Steap_>because Python users expect the subprocess module to use /bin/sh
<civodul>why would they?
<Steap_>and they may want to have it point to ~/bin/zsh/bin/zsh
<Steap_>for instance :)
<civodul>they expect the subprocess module to handle subprocesses
<Steap_>not always to /nix/.../sh
<civodul>how it does that is an implementation issue :-)
<Steap_>civodul: they specifically intend it to call /bin/sh
<Steap_>according to the documentation
<civodul>Guile's popen, Awk's, etc. are all patched
<Steap_>does the doc say they must call /bin/sh ? :p
<Steap_>or just that they have to call *a* shell ?
<civodul>nobody reads the doc anyway :-)
<Steap_>hahaha
<civodul>i think "/bin/sh" should really read as "POSIX Bourne-compatible shell"
<civodul>that's what we're doing here
<mark_weaver>civodul++
<Steap_>As a Python user, I can tell you that when I pass "shell=True" as an argument to subprocess.Popen(), I expect /bin/sh to be called
<civodul>no, you expect a Bourne shell to be called
<Steap_>Everything in computer engineering is already fucked up enough
<civodul>distinguish name and behavior
<Steap_>If Python does nto call /bin/sh as the doc says it should, I'll quit.
<mark_weaver>wow
<Steap_>Go raise goats in a mountain or something.
<civodul>go raise goats, then! :-)
<civodul>goats need love
<Steap_>When you think about it, it can't be that bad
<civodul>;-)
<civodul>certainly not
<Steap_>civodul: now you're going a bit too far :p
<civodul>just kidding :-)
<Steap_>I'm pretty sure that goat lovers aren't upset by Debian's switch to systemd
<Steap_>Their lives must be quite great, all in all.
<civodul>surely
<Steap_>Anyway, is some guy ever has to debug such an issue
<mark_weaver>Steap_: what you're demanding conflicts with the reproducability and roll-back requirements of Guix.
<Steap_>and ends up seeing /bin/sh not called
<Steap_>they'll pull their hair off
<Steap_>mark_weaver: how so ?
<mark_weaver>Steap_: consider this: if you build a Guix package that makes use of Python during the build, it would not use the same shell every time, if you we do as you demand.
<Steap_>yeah, right
<Steap_>well, no
<Steap_>oh yes,
<Steap_>hum
*Steap_ needs to make up his mind
<Steap_>I ended up patchign Python so that it uses /nix/.../sh *iff* /bin/sh is not found
<Steap_>which seems like a good solution to please both the purity of Guix and the needs of Python users
<mark_weaver>that's not good enough. it violates the requirements of Guix.
<Steap_>mark_weaver: when building, it will always use /nix/.../sh
<Steap_>but when users run Python on their systems, they'll be free to use /bin/sh
<mark_weaver>it means that we can't ever achieve bit-identical reproducable builds.
<Steap_>hum
<Steap_>yes we do, since the same shell will always be used
<Steap_>*in the builds*
<mark_weaver>well, okay, that's true.
<Steap_>but "in the real world", Python users will see the expected behaviour
<mark_weaver>I really think you're being ridiculously pedantic about this.
<mark_weaver>This not just not the way things are done in the Guix/Nix world.
<mark_weaver>but admittedly, that's a weak argument.
*mark_weaver goes to play with the 3-year-old.
<Steap_>mark_weaver: being ridiculously pedantic is what I like about being a dev :)
<civodul>Steap_: we can have a more in-depth discussion on the list if you want, but so far the idea has been to refer to store file names in such cases
<mark_weaver>Steap_: the thing is, even if it's still possible to do reproducable *builds*, it reduces reproducable behavior in the system outside of the chroot builds if python uses /bin/sh.
<mark_weaver>we are violating lots of standards in Guix, such as FHS.
<mark_weaver>we do this because we are making improvements on what came before.
<mark_weaver>and avoiding /bin/sh is one example of that.
<Steap_>civodul: yeah, we'll discuss that when I send the patch
<mark_weaver>Guix does not just aim for reproducable builds. it aims for reproducable behavior of systems, so that if something works and then you broke it, you can roll back and get it working again.
<mark_weaver>well, I see you're ignoring me now. bye
<Steap_>heheh, no, sorry, I'm just a bit busy :)
<mark_weaver>fair enough
<civodul>keep cool folks, the world will keep spinning regardless ;-)
<Steap_>civodul: are you sure ? :p
<civodul>well, i hope so!
<Steap_>"what's the worst that could happen ?"
<phant0mas>the sun could blow up :P
<phant0mas>I fixed what mark told me ,but now I ge this error
<phant0mas>ERROR: In procedure memoize-variable-access!:
<phant0mas>ERROR: Unbound variable: lambda_
<phant0mas>fixed that
<phant0mas>It works :-D
<mark_weaver>it works? yay!
<phant0mas>but I used --system=i686-linux with guix build...
<dasfds>civodul: I'm still hitting that cc1plus error I reported even though I extended the size of the partition. Any suggestions?
<dasfds>civodul: The log is full of -Wpedantic warnings, so it's hard to look through.
<dasfds>One of the errors I'm suspicious about is this one: /tmp/nix-build-gcc-cross-boot0-4.8.2.drv-0/gcc-4.8.2/libdecnumber/configure: line 3114: cd: /homeless-shelter: No such file or directory
<dasfds>Steap_: Have you tried builing icecat on your i686 box?
<dasfds>building*
<dasfds>On a sidenote, why does the recipe have two pythons in the native-inputs field?
<Steap_>dasfds: nah, mostly because I don't have an i686 box anymore :/
<Steap_>dasfds: the two Python's looks like a typo :)
<dasfds>does anyone have an i686 machine here?
<dasfds>Steap_: I've just finished reading the discussion regarding /bin/sh in Python. IIUC, the shell from the store will be used while building the package, but /bin/sh will be used at runtime. Is it correct?
<Steap_>dasfds: that's what I'd like to achieve
<dasfds>But what would happen to the ISO users, the ones that don't have /bin/sh at all?
<Steap_>dasfds: they'd use the shell from the store
<Steap_>basically, I do:
<Steap_>sh = '/bin/sh' if os.path.exists('/bin/sh') else '/nix/.../sh'
<dasfds>Hm, I don't understand why mark_weaver isn't happy about this solution then. IIUC, we could still have reproducible builds; are there any downsides?
<dasfds>Currently it looks like a win-win scenario.
<mark_weaver>I want reproducability even when I'm not in a chroot.
<phant0mas>and I think I messed u pmy guix instalation....
<mark_weaver>but whatever, I'm tired of arguing. I can always fix things up in my own tree.
<phant0mas>messed um*
<phant0mas>up*
<mark_weaver>phant0mas: you didn't delete anything from /nix/store by hand, did you?
<phant0mas>hehehe :P
<phant0mas>what should I do now?
<mark_weaver>phant0mas: what are the symptoms?
<mark_weaver>oh, you did. damn.
<Steap_>mark_weaver: yeah, I don't see the point in arguing here any more; I'll finish my Python work, and we'll discuss all that on the mailing list once it's done. Anyway, you're making a good point, and I might end up just doing it as you suggested anyway :)
<mark_weaver>I'm sorry, I don't know how to fix that other than to delete everything in /nix and $PREFIX/var/nix and start over.
<dasfds>mark_weaver: Please make sure to repeat your concerns when this issue will be discussed on the list, so others could make an informed decision.
<phant0mas>warning: collision encountered: /nix/store/42vh1v0n2ry2ymfq9qb9b113gbwg8vvc-binutils-2.23.2/share/info/standards.info /nix/store/ysqgpw7bn4ry6gj3y37a5nrskckkw0i2-autoconf-2.69/share/info/standards.info
<phant0mas>warning: arbitrarily choosing /nix/store/42vh1v0n2ry2ymfq9qb9b113gbwg8vvc-binutils-2.23.2/share/info/standards.info
<phant0mas>warning: collision encountered: /nix/store/7bnva9f8cvmzd66wiqbfqy1ws4xnifxa-ld-wrapper-0/bin/ld /nix/store/42vh1v0n2ry2ymfq9qb9b113gbwg8vvc-binutils-2.23.2/bin/ld
<phant0mas>warning: arbitrarily choosing /nix/store/7bnva9f8cvmzd66wiqbfqy1ws4xnifxa-ld-wrapper-0/bin/ld
<mark_weaver>I know that it's possible to fix up the sqlite database by hand, but I've never tried. I don't know the details.
<phant0mas>deleting all...you damn rm command...
<mark_weaver>phant0mas: there's nothing wrong with those collisions. they are expected.
<mark_weaver>at some point we should make unions a bit smarter, but for now there are warnings.
<civodul>dasfds: i don't remember, was that an ENOMEM error?
<civodul>ah no, ENOSPC
<dasfds>civodul: Right.
<civodul>well yes, you need ~4GiB to compile GCC
<dasfds>civodul: I have 281.
<civodul>oh
<civodul>and /tmp?
<Steap_>281GiB ?
<dasfds>Steap_: Yes, G.
<mark_weaver>dasfds: the issue is how much virtual memory the linker needs to link.
<dasfds>civodul: It's on the same parition.
<dasfds>partition*
<mark_weaver>dasfds: disk space won't save you here.
<mark_weaver>dasfds: nor will swap space.
<dasfds>Damn.
<mark_weaver>dasfds: it may will be that modern icecat simply can't be linked on a 32-bit box anymore.
<dasfds>awesome news...
<dasfds>I'm still planning to try without Guix; just to make sure.
<mark_weaver>oh, nevermind, I got confused. I thought you were talking about icecat for some reason. sorry.
<mark_weaver>last I knew, it was still possible to build GCC with a much smaller address space.
<dasfds>I was talking about IceCat.
<mark_weaver>oh.
<dasfds>Wait.
<dasfds>Let me make it clear, I'm trying to build IceCat, which requires building GCC.
<dasfds>And GCC fails.
<mark_weaver>okay, well, forget what I wrote then.
<dasfds>OK.
<mark_weaver>what is the error?
<dasfds> https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00092.html
<mark_weaver>looks like 'ld' is silently return 1 (failure) but printing no error message. that sounds like a bug in binutils.
<mark_weaver>but if it ran out of memory or disk, such a bug wouldn't be surprising.
<dasfds>In that case, wouldn't there be an OOM error in the log?
<dasfds>How much memory does it need?
<mark_weaver>I don't know off-hand.
<mark_weaver>do you have a separate /tmp partition?
<dasfds>No, I don't.
<mark_weaver>okay, then I guess disk is not an issue.
<mark_weaver>or maybe it's just a bug in binutils.
<mark_weaver>I don't have any 32-bit boxes anymore.
<dasfds>How can I test that?
<dasfds>Should I build binutils?
<mark_weaver>it's not an easy thing.
<dasfds>So, as I said, I'll try to build it without Guix.
<mark_weaver>if it was crashing it would easier, because you could get a core dump.
<civodul>dasfds: but you did build it successfully in the past, right?
<dasfds>civodul: No, I've never tried.
<civodul>or is it core-updates?
<dasfds>master
<civodul>you never tried because you used substitutes?
<dasfds>No, I simply didn't want to.
<civodul>so you never used Guix on that machine, right?
*civodul tries to understand
<dasfds>Are you asking about GCC of IceCat? If the former, I can't remember; if the latter, I've never needed it. No, I've been using Guix on this machine for years.
<dasfds>civodul: I could have used the substitute if I was building this version of GCC before.
<dasfds>civodul: What should I do to force IceCat to build GCC 4.7.3 instead? How can I make it the default version?
<mark_weaver>dasfds: it's failing very early in the bootstrap of guix.
<mark_weaver>my guess is that you'll run into the same problem even if you just try to build "hello" at this point.
<mark_weaver>I guess you haven't tried to build anything since the last core-updates merge.
<dasfds>So, can't I bootstrap with 4.7.3?
<jmd>Why can I not (use-modules (ice-9 iconv)) in guix?
<jmd>
<mark_weaver>jmd: What makes you say that you cannot?
<jmd>I get errors
<mark_weaver>what errors?
<jmd>In unknown file:
<jmd> ?: 1 [scm-error misc-error #f "~A ~S" ("no code for module" (ice-9 iconv)) #f]
<jmd>In ice-9/boot-9.scm:
<jmd> 106: 0 [#<procedure 8feb440 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
<jmd>
<civodul>dasfds: the default is specified in guix/build-system/gnu.scm
<civodul>but really, i don't think this will help
<civodul>building IceCat requires lots of disk space and memory too
<mark_weaver>jmd: (ice-9 iconv) was added to Guile in 2.0.9. I guess you're using an old version of guix with guile-2.0.7 in the bootstrap.
<civodul>well ~500 MiB of disk, but it's C++, so more memory
<jmd>oh maybe.
<mark_weaver>guix-0.5 uses guile-2.0.9 in the bootstrap. anything older will be guile-2.0.7.
<phant0mas>fixed my guix instalation, testing gnumach package again
<mark_weaver>phant0mas: in the future, you need to use "guix gc --delete /nix/store/..." to delete things from the store. it won't let you do it if anything else in the store that you need still references it.
<dasfds>civodul: I've looked through but understand what exactly have to be changed there.
<jmd>string->bytevector is available only in 2.07 and later ?
<dasfds>don't*
<phant0mas>I will definitely keep in mind that
<civodul>dasfds: oops actually it's %final-inputs in base.scm, rather
<mark_weaver>jmd: 2.0.9 or later
<civodul>dasfds: but it won't help; if the thing fails with ENOSPC, then it means there's no space left
<civodul>and that's what needs to be figured out, i think
<mark_weaver>string->utf8 was available much earlier, fwiw. but anyway, you should upgrade your guix install.
<jmd>bummer!
<dasfds>civodul: It doesn't fail with ENOSPC now.
<dasfds>civodul: I've recently extended the partition. It still fails, though.
<mark_weaver>civodul: 'ld' returns 1 without printing an error, while linking cc1plus in gcc-cross-boot0
<mark_weaver> https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00092.html
<mark_weaver>it seems likely that guix is broken on i686.
<mark_weaver>dasfds may be the only one who has tried bootstrapping guix-0.5 on i686.
<mark_weaver>dasfds: how much RAM do you have? how much swap?
<mark_weaver>s/likely/possible/
<dasfds>mark_weaver: No swap, 2201 (according to free -m).
<dasfds>That's total.
<mark_weaver>2 gigs?
<dasfds>Yes.
<mark_weaver>it's possible that's not enough. I'd add swap and try again.
<dasfds>OK.
<mark_weaver>it doesn't have to be a separate partition. it could be a swap file.
<dasfds>How much should I add? 2 gigs also?
<mark_weaver>I'd recommend 3 gigs of swap, to be on the safe side, since you have plenty of disk free.
<dasfds>OK.
<dasfds>So, I'll try and report back. As always, thanks for helping out.
<mark_weaver>you're welcome!
<mark_weaver>thanks for testing on i686 :)
<phant0mas>okay now before continuing with mig
<phant0mas>I will name the pagkage hurd
<phant0mas>packages*
<phant0mas>like linux.scm
<phant0mas>and put everything in there
<dasfds>mark_weaver: Out of curiosity, have you tried to compile IceCat on your Lemote box?
<mark_weaver>dasfds: I compiled an old version of icecat (3.6.16) about two years on my homebuilt-system, outside of Guix.
<mark_weaver>at the time, I couldn't get any newer version working.
<mark_weaver>I assume that the latest icecat will require some porting effort to get it working on MIPS.
<viric>I remember having to patch firefox for mips64
<davexunit>firefox is quite the complicated program, I wonder how much work it will take to port...
<mark_weaver>my guess is that it will be a lot of work.
<davexunit>mips isn't exactly on mozilla's radar.
<mark_weaver>indeed
<davexunit>they're too busy fighting off chrome.
<mark_weaver>there are some relevant repos here: http://dev.lemote.com/code/
<mark_weaver>including "firefox-3.7 with JIT Javascript engine for Loongson" and "WebKit on loongson"
<mark_weaver>oh, the "WebKit on loongson" repo appears to be completely empty. The Firefox one is 4 years old.
<mark_weaver>well, I'm not sure now. it seems that cgit is broken on that site.
<mark_weaver>bah. it's not cgit. I can't clone those repos at all.
<mark_weaver>they seem to have gone away or been moved, but the website still shows them.
<mark_weaver>well, it hardly matters. all of that stuff is so old, and the JS implementations have changed so much, it's probably useless at this point anyway.
<dasfds>mark_weaver: Adding 2773 megs of swap didn't help.
<dasfds>Any ideas?
<mark_weaver>dasfds: okay, then I guess it's not memory related. it's probably just a bug in binutils.
<mark_weaver>bummer.
<dasfds>Would it help if I try a different GCC?
<mark_weaver>dasfds: are you running with --no-substitutes?
<mark_weaver>I don't think the bug is in GCC. I think it's in binutils.
<dasfds>mark_weaver: Yes, I passed the option to the daemon.
<dasfds>mark_weaver: Should I try binutils 2.23.1, then?
<mark_weaver>please wait a minute or two for me to look.
<dasfds>Sure.
<mark_weaver>right now, guix master is using 2.23.2. I doubt that 2.23.1 will be any better. usually those micro revisions are bug fixes only.
<mark_weaver>if you're going to switch binutils, I'd be tempted to instead upgrade it to 2.24.
<mark_weaver>you could cherry-pick the commit from core-updates
<dasfds>mark_weaver: OK, will try.
<mark_weaver>just beware that between now and the next core-updates merge, you will have to keep that local change in place. "git pull --rebase" works well.
<dasfds>Thanks for the heads up.
<civodul>mark_weaver: ah ok, that's worrisome
<civodul>but master definitely works on i686
<mark_weaver>civodul: what makes you say that?
<civodul>well it works on an x86_64 CPU
<civodul>used as an i686
<civodul>hydra has been building for i686 for some time
<mark_weaver>civodul: but has anyone tried bootstrapping it (with --no-substitutes) on an i686 system?
<mark_weaver>dasfds: why don't you wait on this. maybe civodul has a better idea.
<mark_weaver>civodul: how is that done? is hydra doing the i686 builds in a complete 32-bit environment, or is it cross-compiling everything?
<civodul>mark_weaver: on a "real" one? hopefully yes
<civodul>mark_weaver: it's building as with --system=i686-linux, which uses the Linux 32-bit personality
<civodul>etc.
<civodul>so it's a complete 32-bit user space, but an x86_64 kernel and CPU (if that matters)
<mark_weaver>okay
<dasfds>mark_weaver: I've git am'd the latest three commits.
<dasfds>binutils-related commits*
<civodul>anyway, i expect dasfds would have reported such a big issue before :-)
<mark_weaver>well, for some reason it's consistently failing for dasfds. 'ld' returns 1 without printing an error message. he says he has over 200 gigs free, /tmp is not a separate partition, and he now has 2 gigs of RAM + over 2.5 gigs of swap.
<dasfds>civodul: As I said, it's possible that I was using the substitute, so the bug didn't show up.
<mark_weaver>dasfds: so you have "
<mark_weaver>gnu: binutils: Upgrade to 2.24." ?
<mark_weaver>what other two did you take?
<dasfds>mark_weaver: Yes, as well as the latest two.
<dasfds>gnu: binutils: Build with --enable-deterministic-archives.
<dasfds>tests: Adjust to recent Binutils change.
<mark_weaver>okay
<mark_weaver>well, I'd be curious to see if it makes a difference anyway.
<dasfds>Is it necessary to restart the daemon?
<mark_weaver>no
<dasfds>OK.
<mark_weaver>hmm, it occurs to me that at this point in the bootstrap, you might be using the linker in the bootstrap tarball anyway.
<mark_weaver>if that's the case, then this has no chance of working anyway.
<dasfds>We'll see. It's currently fetching the binutils tarball.
<dasfds>I hope it'll work, though. I don't want to build all the IceCat dependencies outside of Guix.
<mark_weaver>hmm, yeah, I think that's right.
<mark_weaver>I think this has no chance of making a difference.
<dasfds>Sigh.
<mark_weaver>civodul: how were the current i686 bootstrap tarballs created?
<mark_weaver>were they cross-built, or natively built?
<mark_weaver>dasfds: fwiw, I doubt you'd be able to build modern icecat on a 32-bit box anyway. 3 years ago it started becoming impractical to build firefox on 32-bit systems, and I doubt it's gotten any better since then.
<mark_weaver>if you want to build icecat from source, I think you need to acquire a 64-bit box.
<mark_weaver>having said all that, it would be good to understand why guix is failing its bootstrap on i686.
<mark_weaver>I suppose I could install 32-bit debian on my thinkpad and try it myself.
<mark_weaver>with my voluminous free time :)
<dasfds>No need if you don't really want to, I'm serious.
<dasfds>I bet there are more important things you could do.
<mark_weaver>true
<dasfds>More enjoyable even.
<mark_weaver>dasfds: if I were you, I'd try to find a friend of yours who wants to upgrade his machine, and see if he'll sell you his existing one.
<dasfds>mark_weaver: And... it failed again. You were right.
<mark_weaver>dasfds: okay, you should roll back those commits now. git reset --hard origin/master
<dasfds>Thanks for mentioning that. But it's a different branch, so I'll simply switch to master.
<mark_weaver>okay
<mark_weaver>damn. I was so close to having gnunet on my Yeeloong, but it failed two tests.
<dasfds>mark_weaver: This machine supports the 64-bit instruction set. I should tweak the kernel, no need to ask a friend.
<mark_weaver>dasfds: oh!
<mark_weaver>so why are you running i686 software on it?
<civodul>mark_weaver: natively built
<mark_weaver>civodul: thanks
<civodul>(sorry for being intermittently absent, BTW)
<mark_weaver>no need to apologize, civodul. as I've said before, the level of support you provide for Guix is amazing :)
<dasfds>Indeed.
<davexunit>agreed!
<civodul>:-)
<phant0mas>civodul rocks !!
<mark_weaver>civodul: would it be tricky to bootstrap 64-bit guix within a 32-bit host OS?
<mark_weaver>how would that be done?
<mark_weaver>(I see no inherent difficulties, but maybe the build system isn't set up to do that easily)
<civodul>well the host OS would be unable to run the 64-bit binaries
<civodul>so i don't see how this could work
<phant0mas>just sent a patch with gnumach headers
<civodul>yay!
<mark_weaver>civodul: why not? what's needed from the host OS other than the kernel?
<phant0mas>and now back to work
<phant0mas>:P
<civodul>the kernel
<civodul>mark_weaver: but so if it's a 32-bit kernel, it won't work
<mark_weaver>civodul: right. but what if it's a 64-bit kernel and 32-bit host OS?
<civodul>the user space of the host OS doesn't matter at all
<civodul>your user space is belong to Guix
<mark_weaver>civodul: heh :)
<mark_weaver>right, but when he does "guix package -i hello" how will it decide whether to build 64-bit binaries or 32-bit binaries?
<dasfds>mark_weaver: I couldn't enable 64-bit support in the kernel several years ago, so I postponed that for some time in the future. It seems the future has come.
<mark_weaver>dasfds: admittedly, if you want to build that 64-bit kernel from source code, you might need to upgrade your toolchain first.
<mark_weaver>that part might be tricky. it would probably be enormously easier to download a pre-compiled 64-bit kernel.
<civodul>mark_weaver: which bootstrap binaries are used depends on the value of (%current-system)
<dasfds>Yak shaving...
<civodul>so on a machine with a 64-kernel, one can always do "guix build -s x86_64-linux hello"
<civodul>and that should work
<civodul>(never tried, but hey ;-))
<mark_weaver>ah, and %current-system defaults to %system, which comes from config.scm, generated by configure.
<civodul>exactly
<mark_weaver>thanks!
<mark_weaver>dasfds: out of curiosity, what is your host OS?
<dasfds>mark_weaver: You mean the distro?
<mark_weaver>right
<dasfds>This machine runs gNewSense. (I have to install for source a lot.)
<dasfds>from*
<dasfds>It's based on Squeeze, IIRC.
<dasfds>That's 2010.
<mark_weaver>dasfds: okay, so you're already downloading pre-compiled binaries from them, when you get security updates and so on, right? if so, then you can just install the amd64 kernel from them, I think.
<dasfds>mark_weaver: But that wouldn't allow me to configure the kernel, would it?
<mark_weaver>no
<mark_weaver>linux-image-2.6-amd64 is what you'd need, fwiw.
<mark_weaver>once you have a 64-bit userspace, then you can configure your kernel.
<mark_weaver>you could build a custom kernel from guix's 64-bit userland.
<mark_weaver>but somehow, you have to get from your current 32-bit-only system to a 64-bit kernel.
<mark_weaver>and that requires a linker that can link 64-bit binaries. I'm not sure if the 32-bit linker you have can do that.
<mark_weaver>I confess I'm not sure either way, but I don't want to spend time figuring it out.
<dasfds>Ugh, I think I've done enought maintenance for today.
<mark_weaver>okay.
<dasfds>enough*
<mark_weaver>you'd also need a GCC capable of compiling 64-bit programs.
<mark_weaver>it seems to me that the easiest way forward by far is to download linux-image-2.6-amd64, run it, and then install 64-bit guix from it. and then you can compile a custom 64-bit kernel to your liking.
<mark_weaver>well, maybe the package name is different on gnewsense.
<mark_weaver>anyway, ttyl
<dasfds>Maybe I should simply switch the distro. I've been running gNewSense, so I could recommend it to others. (They don't have non-free repos nor mention non-free software on the wiki.) But is it a good thing to suggest such an outdated distro? I doubt so.
<mark_weaver>well, isn't the idea to switch to Guix? :)
<mark_weaver>but yeah, maybe. there are other good options.
<mark_weaver>trisquel or parabola come to mind.
<davexunit>trisquel is pretty good.
<davexunit>that's the most "user friendly" fully free distro.
<dasfds>I've used both. And I'm not a fan of rolling release distros that don't have roll-back functionality. One of my machines runs Trisquel, but I haven't been following the project for a while.
<phant0mas>something is wrong with my damn gmail and messed up my patch I sent, I just resent the correct one!
<phant0mas>or it may be my lack of food, going to eat something :P
<mark_weaver>no worries!
<phant0mas>mark_weaver: one question I have , do you sleep at all? You are always online
<dasfds>hahaha
<phant0mas>how do you do that?
<mark_weaver>i'm fairly sleep deprived lately :)
<phant0mas>:P
<civodul>phant0mas: just replied to your first patch
<civodul>it's a good start, congrats!
<phant0mas>fixing it right away
<phant0mas>thnx :-)
<mark_weaver>phant0mas: great start, indeed! :)
<mark_weaver>I'd like convert my old thinkpad to Guix on Hurd...
<phant0mas>and I would really like to see Hurd getting bigger!!
<phant0mas>and guix can definetily help to that
<mark_weaver>the big thing, though, is that I want to move away from Intel. I don't use Intel at all anymore. So I'll have to port GNU Mach to something else.
<phant0mas>that probably need a lot of work
<phant0mas>needs*
<mark_weaver>indeed.
<mark_weaver>CMU Mach was running on MIPS at one point in the past. that part of the code is no longer present in GNU Mach, but it might be a good start.
<mark_weaver>(I found an old copy of Mach with the MIPS code)
<phant0mas>can I have a look?
<mark_weaver>I'll have to find it again. let's see...
<mark_weaver>phant0mas: see http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00099.html and http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00239.html
<mark_weaver>phant0mas: the URL with the old mach code is no longer accessible, but at some point I did some digging and found another copy of that old mach somewhere, and looked through the code a bit.
<mark_weaver>I'll have to search my disks for it now.
<phant0mas>when I try to access the link in the mail I get this error
<phant0mas>530 /afs/cs.cmu.edu/data/anonftp/afs/cs/project/mach/public/src/mkernel/mips.tar.Z is not available to guest users
<civodul>good night/day, & happy hacking!
<civodul>:-)
<mark_weaver>g'night!
<phant0mas>they have probably removed the mips source code
<mark_weaver>I got it.
<mark_weaver>you have to connect via an plain ftp client and navigate to the directory via a symlink elsewhere.
<mark_weaver>I'm downloading it all now.
<phant0mas>okay
<phant0mas>can you upload it to github or something so it can be more easily accesible?
<mark_weaver>actually, it's not that hard, you just need the right URL: ftp://ftp.cs.cmu.edu/project/mach/src/mkernel/
<mark_weaver>within there, there's a mips directory.
<mark_weaver>src/mips, rather
<phant0mas>yep
<phant0mas>I found it
<mark_weaver>well, actually mips.MK83.tar.Z and mips.MK84.tar.Z are right there.
<phant0mas>downloading everythin
<phant0mas>downloading everything
<mark_weaver>i386.MK84.tar.Z is also probably important, to see what changes were made to it between that version and modern GNU Mach.
<mark_weaver>some of those changes would presumably need to be made to the mips version as well.
<mark_weaver>no doubt it's still a lot of work, but it's a good start.
<mark_weaver>it's comforting to know that not only Mach, but even Hurd ran on MIPS in the past.
<phant0mas>if it one could,it will again!
<phant0mas>:-)
<mark_weaver>it would be nice. I'm using MIPS (Loongson in a Yeeloong) as my primary machine nowadays.
<phant0mas>are you satisfied with it's perfomance?
<mark_weaver>no, not really, but I have much worse complaints with intel, namely that there are no modern intel machines that can be used without non-free bioses and huge binary blobs being loaded into them.
<mark_weaver>The Thinkpad X60 is the last one I know that can be used with a 100% free software system, but that's a dead end.
<mark_weaver>I have some hope that Loongson will be more friendly to free software, and also some hope in the Freescale-based Novena.
<phant0mas>let me have a look at that last one
<mark_weaver> http://www.bunniestudios.com/blog/?tag=novena
<mark_weaver>I really want that laptop.
<phant0mas>so it has an fpga on it as well
<phant0mas>nice
<phant0mas>I shall keep an eye on that
<phant0mas>could we use fpga's for a completely free system? I mean we could run any cpu we wanted on them
<phant0mas>I found some gpl licenced verilog code of open spark
<phant0mas>and I was planing to try it on my univercities virtex 5 fpgas
<mark_weaver>phant0mas: check out the milkymist project.
<mark_weaver>milkymist.org
<mark_weaver>the problem with open spark is that it's too big. it takes too much space in an fpga.
<mark_weaver>s/spark/sparc/
<davexunit>mark_weaver: the novena looks awesome!
<mark_weaver>yeah, it's very exciting work.
<davexunit>now *that's* a hacker's laptop.
<mark_weaver>indeed!
<davexunit>I'm surprised at how high the screen resolution is, too.
<mark_weaver>not cheap though
<davexunit>yeah, definitely not.
<phant0mas>Migen looks awesome, I will show it to my professor on Monday
<phant0mas>python based tools? sounds like a dream :P
<phant0mas>guys I think I'll go to sleep, it's already 1 AM over here
<phant0mas>first thing tomorrow fixxing that patch
<phant0mas>see ya!!
<mark_weaver>later!