<efraim>between your and ricardo's suggestions I have python2-oauthlib building. I thought I had to edit python2-cryptography to fix python2-oauthlib, but now I understand everything that uses python2-cryptography needs to be specifically told what to do
<Gottox>efraim: We at voidlinux are using one armv7 gcc-cross for all our platforms.
<civodul>rekado_: then i don't understand your suggestion ;-) what did you mean by "bootstrap GCC first"?
<rekado_>well, in my dream world there is a tiny compiler for a subset of C written in assembly, which would be used to build tinyCC, which would be used to build GCC, which can then be used to build cross-GCCs.
<rekado_>it's not much of a suggestion, I'm just dreaming out loud.
<civodul>the problem is not cross-GCCs, but rather everything before
<civodul>and unfortunately, by switching to C++, GCC spoiled our dream
<rekado_>could an older version of GCC be used to build the C++ compiler?
<rekado_>my dream is just to move the root of the graph a few more turtles down.
<civodul>an older version might work today, but it's not sustainable
<civodul>most likely we'd have to build a very old GCC, to build an old one, to build a recent one, to build the latest one
<civodul>and the old versions would probably need patching here and there, more and more over time
<civodul>unless we also build old binutils and glibc
<cehteh>civodul: about all this build-server, funding stuff and more .. i would really like if guix could sustain with a completely distributed infrastructure, gnunet, bittorrent, signed builds where anyone trusted can cooperate
<mark_weaver>rekado_: replacing just the compiler wouldn't really help all that much, because you still need binaries of all the other utilities, plus a kernel.
<mark_weaver>rekado_: my dream is to implement a minimal little subset-of-scheme REPL that works as a coreboot/libreboot payload, and then document a set of REPL commands that gradually builds up the system to the point of being able to compile the GNU toolchain and go from there.
<mark_weaver>another example of a coreboot/libreboot payload is GRUB
<rekado_>civodul: I was convinced that Python offered a way to "import /path/to/module", but I was shocked to learn that this doesn't actually exist.
<desiderantes>hello, i see that a systemd .service file is provided when installing guix for users
<rekado_>Ruby supports this, though, and I really think it's worth working on a build phase that replaces plain "require lib" statements with "require /path/to/lib"
<rekado_>mark_weaver: that's a nice dream :) I'd like that.
<mark_weaver>and part of the bootstrap process would involve compiling the last version of GCC (4.6?) that doesn't require C++ to compile, and then using that to compile the newest version of GCC that can be compiled with that version of GCC, and so on, until we get to the version of GCC that we want.
<desiderantes>civodul, i've been testing it and it seems to work properly, how can i propose it for inclusion?
<civodul>desiderantes: post it to guix-devel; better: if you're familiar with the autotools, post a patch that integrates it similar to etc/guix-daemon.service.in
<civodul>specifically, do something similar to commit d2825c96
<mark_weaver>civodul: well, my main concern about all of the reproducible builds projects that currently exist is that they all requires putting one's faith in a *huge* pile of binary code to start with.
<mark_weaver>which is not to say that this is not a logical first step, and an important one.
<mark_weaver>but I for one will not be satisfied until we can start from something whose machine code is fully auditable by a single person in a reasonable length of time, and then have the rest of the bootstrap be 100% source code in the true sense of the term (preferred form for editing)
<mark_weaver>the diverse compilation idea is a good one, but it's important to remember that the compiler is only one of the components where such a Thompson attack could be launched from. the assembler, linker, and kernel are other places to be concerned with.