<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.
<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
<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.
<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>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?
<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.
<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_>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.
<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>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: 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>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>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.
<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>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.