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 <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>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. <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 <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. <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. <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. <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>at least we will have a working pf firewall for power users by July.. <phant0mas>how can I set let's say CC='gcc -m32' through guile before the configure flags? <mark_weaver>that should be handled by the fact that target is i686-gnu <mark_weaver>did you use a cross-compiler in your testing yesterday? <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 <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>setting CC, LD, and CPP like that is definitely not going to be correct in Guix, anyway. <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>I will keep looking in other guile recipes for help <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 <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>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"))) <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. <zacts>is phant0mas working on a guix HURD distro? <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 <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>perhaps there's another mark weaver, without underscore or something? <civodul>phant0mas: i actually did what you're working on a couple of years ago in Nixpkgs <mark_weaver>civodul: phant0mas thinks that "-m32" has to be passed to the compiler for mach. What do you think? <civodul>something like that is needed when building from a 64-bit machine <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 <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>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 <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>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>phant0mas: did you try passing #:configure-flags '("CFLAGS=-m32") ? <mark_weaver>civodul: won't he need 32-bit libraries in the chroot? <civodul>well, i think it should work, beause Mach doesn't link against anything <mark_weaver>civodul: maybe so, but it seems that configure compiles a test program. he got "configure: error: C compiler cannot create executables" <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 <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 <mark_weaver>right, something like (alist-replace 'install ,install-phase (alist-delete 'build %standard-phases)) <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>oh, sorry, you need to wrap that in (lambda _ ...) also.. <phant0mas>don't worry I found a similar one in linux.scm <mark_weaver>so (let ((install-phase '(lambda _ (zero? (system* "make" "install-data"))))) ...) <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>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 _" <phant0mas> (system* "make" "install-data"))) like that? <phant0mas>and what should be the third argument for alist-replace? <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 <mark_weaver>The build is done as one of the guix-builder users, but maybe there's a private uid namespace, dunno. <Steap_>the '0' id cannot be found by getgrgid(), for instance <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. <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>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. <mark_weaver>the expression immediately following "#:phases" is the alist to use. <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: is it the same "/etc/group" as on my system ? <Steap_>mark_weaver: so my real question si "what's the content of the 'fake' /etc/group ?" <mark_weaver>Steap_: it's a very minimal, fixed /etc/group. not sure what's in it off-hand, but not much. <Steap_>@file{/etc/group} with an entry for the user's group; <Steap_>so that would be the 'guix-builder' group <mark_weaver>Steap_: if you search for "etc/group" in the nix directory, you'll have your answers. <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_>yes, so the only gid defiend in 1001 <Steap_>I'll try by replacing that with 1001 <civodul>so there could be a case for adding a 'root' group <mark_weaver>Steap_: no, that won't work on other people's system. <Steap_>oh, the gid depends on my system <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 <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_>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 <civodul>normally 99% of them are patched automatically <Steap_>anyway, /bin/sh is a POSIX requirement *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. <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 <Steap_>and they may want to have it point to ~/bin/zsh/bin/zsh <civodul>they expect the subprocess module to handle subprocesses <civodul>how it does that is an implementation issue :-) <Steap_>civodul: they specifically intend it to call /bin/sh <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>i think "/bin/sh" should really read as "POSIX Bourne-compatible shell" <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 <Steap_>If Python does nto call /bin/sh as the doc says it should, I'll quit. <Steap_>Go raise goats in a mountain or something. <Steap_>When you think about it, it can't be that bad <Steap_>civodul: now you're going a bit too far :p <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. <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 <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_ 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_>yes we do, since the same shell will always be used <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 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. <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. <Steap_>heheh, no, sorry, I'm just a bit busy :) <civodul>keep cool folks, the world will keep spinning regardless ;-) <Steap_>"what's the worst that could happen ?" <phant0mas>I fixed what mark told me ,but now I ge this error <phant0mas>ERROR: In procedure memoize-variable-access!: <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>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_>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. <mark_weaver>phant0mas: you didn't delete anything from /nix/store by hand, did you? <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. <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>well yes, you need ~4GiB to compile GCC <mark_weaver>dasfds: the issue is how much virtual memory the linker needs to link. <dasfds>civodul: It's on the same parition. <mark_weaver>dasfds: it may will be that modern icecat simply can't be linked on a 32-bit box anymore. <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>Let me make it clear, I'm trying to build IceCat, which requires building GCC. <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>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? <civodul>you never tried because you used substitutes? <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> ?: 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 ...] <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 <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 ? <civodul>dasfds: oops actually it's %final-inputs in base.scm, rather <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. <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>dasfds may be the only one who has tried bootstrapping guix-0.5 on i686. <dasfds>mark_weaver: No swap, 2201 (according to free -m). <mark_weaver>it's possible that's not enough. I'd add swap and try again. <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>So, I'll try and report back. As always, thanks for helping out. <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>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. <mark_weaver>dasfds: okay, then I guess it's not memory related. it's probably just a bug in binutils. <dasfds>Would it help if I try a different GCC? <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>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>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. <civodul>mark_weaver: ah ok, that's worrisome <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>so it's a complete 32-bit user space, but an x86_64 kernel and CPU (if that matters) <dasfds>mark_weaver: I've git am'd the latest three 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. <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>well, I'd be curious to see if it makes a difference anyway. <dasfds>Is it necessary to restart the daemon? <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>civodul: how were the current i686 bootstrap tarballs created? <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. <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>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>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. <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 :) <mark_weaver>civodul: would it be tricky to bootstrap 64-bit guix within a 32-bit host OS? <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 <mark_weaver>civodul: why not? what's needed from the host OS other than 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 <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) <civodul>so on a machine with a 64-kernel, one can always do "guix build -s x86_64-linux hello" <mark_weaver>ah, and %current-system defaults to %system, which comes from config.scm, generated by configure. <dasfds>mark_weaver: You mean the distro? <dasfds>This machine runs gNewSense. (I have to install for source a lot.) <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>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>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. <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. <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 <phant0mas>mark_weaver: one question I have , do you sleep at all? You are always online <civodul>phant0mas: just replied to your first patch <phant0mas>and I would really like to see Hurd getting bigger!! <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. <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>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. <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 <phant0mas>they have probably removed the mips source code <mark_weaver>you have to connect via an plain ftp client and navigate to the directory via a symlink elsewhere. <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>well, actually mips.MK83.tar.Z and mips.MK84.tar.Z are right there. <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. <mark_weaver>it would be nice. I'm using MIPS (Loongson in a Yeeloong) as my primary machine nowadays. <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>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>the problem with open spark is that it's too big. it takes too much space in an fpga. <davexunit>I'm surprised at how high the screen resolution is, too. <phant0mas>Migen looks awesome, I will show it to my professor on Monday <phant0mas>guys I think I'll go to sleep, it's already 1 AM over here