Re. QEMU setup: getting the runs ready didn't take more than a couple of hours (mostly debugging), but the dead blocking hours waiting for the results were quite annoying. GCC 5.4 takes significantly more time and RAM to compile than the 4.9 build, which on a more minimal system (e.g. the lenovo S10 I've acquired from Stan) makes builds practically impossible.

Rerunning the bootstrapper now finally yields a genesis.vpatch that is identical to Lobbes' and which verifies against Trinque's signature of the Keccak V patch.

I bet that was a nice to see!

All in all, arriving here required about two weeks of bootstrapper runs, modifications and reruns,

Yikes! How much of that 2 weeks do you attribute to the QEMU set up and the gcc 5.4 fandango ?

However, I did require a reference genesis.vpatch to do any debugging, and I'm not sure that this is even sufficient. Don't get me wrong, I very much like the idea of using the bootstrapper's output as a basis for further ebuilds, but what am I going to do if I can't even debug the process of producing a verifiable basis?

Yeah, being able to debug the process is needed and ties right in to comment the third concerning publishing your modifications.

@Stanislav Datskovskiy: Re. GCC, why not just package a signed binary along with the rest of the stage3? Ave1's already spent a lot of time working on GNAT, so IMHO that'd be a proper replacement for GCC 5.4.0.

@bvt: Re. Musl, I got that, but it's not clear to me whether Cuntoo was supposed to do static linking and just mine didn't, or what. I guess I'll have to review the older Cuntoo log threads to get a better idea of the decisions made there.

Thanks re. the emacs pointer, I'll look into it. From what I understand there should be a magical incantation to patch the ebuild and get it compiling, or is there another package in there, or what?

Re. where kernel installation goes, that makes sense; on the other hand, maybe Trinque did it in that order for some particular reason? Let's see what he says.

@Jacob Welsh: At some point there was some heated debate about making Emacs portable to other libcs (and as it happens, I can't readily find it), IIRC the GNU people didn't want to give glibc up at all. I don't know what are the main differences between XEmacs and GNU Emacs, but I'm not against completely dumping the latter, provided that I can run e.g. a SLIME/SBCL environment on the former.

from what I understand, it's not possible to compile Emacs using Musl.

My "solution" to this was... XEmacs.

Though since the GNU one is supposedly ported to all kinds of systems, it might just be assuming "Linux == glibc" and have a switch accessible somewhere to turn off the "unexec" thing which I recall was the culprit, at the cost of slower startup.

4. emacs support on musl (a hack for its dumper really) should be in, it is added through musl overlay (/var/lib/layman/musl/app-editors/emacs on my system, the overlay is added by default during cuntoo installation). I have never tried to install it there, though.

6. The simples change would be to move kernel configuration and installation to the last step.