<ng0__>i think having that many packages on my host system does not help debugging guix on it.. i have resolved a bit by rewriting PATH, but it's still far from usable (plus 450 out of 1800 packages are still recompiling) with some applications
***fkz is now known as Guest34625
<efraim>i locally disabled libitm for aarch64, gcc-cross-sans-libc-aarch64-linux-gnu actually built and now its continuing on
<efraim>i should look around more (I'M LOOKING AT YOU LINARO) and figure out how others built it without disabling libitm
<efraim>one thing I haven't tried yet is building the cross compiler with only c and not c++ support
<phant0mas>efraim: I had to disable "--disable-libitm" "--disable-libvtv" and "--disable-libsanitizer" as well for Hurd
<ng0>more risk more fun.. and after all I want to toy around with extending the pull etc this year :)
<ng0>having guix on gentoo is simply not fun. others can keep trying, i know it works, but rebuilding the host system, extrem case though when going from a hardened profile to a amd64/desktop profile, took almost 2 days for ~1800 packages
<janneke>if your end target is debian, it makes little sense to go through guix
<galex|713>But it *can* be linked to other distributions since you said on #guile it could import from pip, npm, etc.
<galex|713>janneke: debian doesn’t automate stuff with scheme…
<janneke>you can run the guix package manager on debian, just like you can run RPM on debian
<galex|713>so most of stuff is shell scripts using C binaries using libs and when making anything you have to figure out if you make a shell script, write a C program or even a C library or in what proportion do the three, while with scheme you don’t have this problem
<janneke>however, guix packages are entirely independent of its host
<galex|713>janneke: also rpm is usually to use with a whole distribution while guix can be a lot more flexible than that (it could build stuff according debian binaries and even maybe in the future share binary packages between people)
<janneke>galex|713: i said on #guile that guix wants to import from npm, pipi etc, it's being worked on
<OriansJ>The resulting binary could be written directly to a floppy disk and boot on any x86 system that was written to spec and be able to compile and run itself or other programs also written in hex.
<OriansJ>In short I am trying to make the trusted base be only 512Bytes or smaller in size, then provide all of the bootstrapping functionality required to boostrap a proper assembler and C compiler such that one would be able to Compile GCC and thus make the trust chain provably correct
<OriansJ>combined with a sub 64KB vm, we can reduce the total work for bootstrapping new platforms and expanding the space for detecting issues.
<janneke`>so what platform did you add, and why -- i'd think if you have gcc on any platform, you can bootstrap any other?
<OriansJ>The Knight architecture [With two paper tape drives :D], the idea being is that no single platform or hardware needs to be trusted or depended upon as all other hardware platforms should be able to check other systems' results.
<OriansJ>In short, I am attempting to expand the problem space for a trusted trust attack to have to incorporate ALL hardware platforms ever made or could be made. [Including third party TTL designs] thus making it practically impossible.
<OriansJ>And by explictly only allowing simple and well commented hex, assembly and C programs; I should have provided a simple pattern for others to follow if they wish to independently bootstrap their own version and independently verify any/all of the work I have done thus far.