<mihi>And there are 830 more packages that are in a build cycle (i. e. you need A to build B and B to build A). Most of the cycles are quite small (3 or 4), but there is one strongly connected component of 749 packages that all form a giant ball of mud of build dependencies... <mihi>Hagfish, probably there is a way to get them built (or cross-built) without depending on them, but at least the default build will first download the binary before building the source. <mihi>BTW any suggestions how to visualize a strongly-connected directed graph with 749 nodes? I could not get graphviz/dot to finish. yEd is able to open and visualize it, but either you only see a large gray ball of mud, or the nodes are too small to be seen... <Hagfish>mihi: if there is a significant subset of nodes that don't depend on anything, but are depended on by lots of things, you could take them out of the graph and maybe colour the remaining nodes based on which core nodes they depend on <Hagfish>other than that, i think "large gray ball of mud" is as much semantic meaning as you can extract from a 749 node graph <Hagfish>at that scale, the problem isn't the visualisation, it's the input data :) <mihi>Hagfish, in a strongly connected graph there are no nodes that don't depend on anything :) <mihi>(strongly connected == every node indirectly depends on every other node) <oriansj>Melg8: --BaseAddress and --base-address in hex2 simply specify what is the address for which the binary will be loaded into memory. Its impact is primary on stack space for x86 and AMD64 and other architectures that put the stack below the binary in memory. <oriansj>So changing its value will never break a hex2 file (unless it hard-codes an address instead of doing &label) <oriansj>The reason why I choose 0x8048000 and janneke opted for 0x1000000 is: it was the address that GCC usually does for x86 binaries and 0x1000000 is just a nice round number. <oriansj>mihi: I think sorting out Debian's build is going to involve some ugly guix build magic to sort it all out. Because I don't think it will be possible to bootstrap Debian outside of a functional package manager. <oriansj>stikonas: yeah mes-m2 is basically the ugly workhouse of dealing with all of the ugly details of bootstrapping mes.c and I can't blame janneke for that; M2-Planet+mescc-tools is my mess to clean up <oriansj>also stage0-posix has the current mes-m2 kaem build scripts for x86 but I'll need hel pto finish the M2libc porting of mes-m2+mescc to finally make mes-m2 architecture neutral. <mihi>oriansj, I agree until you have bootstrapped all "build-essential" packages (which include the package manager). My analysis was about the packages that are *not* build-essential and could in theory be bootstrapped from within a "build-essential" Debian. <oriansj>mihi: thank you for that correction in my understanding ^_^ <Hagfish>(pity i couldn't pass that on before they disconnected) <Melg8[m]>oriansj: can't we use something like https://github.com/xoreaxeaxeax/movfuscator idea to protect some of our c compilers against kernel messing around? so like take this movfuscator compiled with regular gcc than compile tinycc with it, check that all instructions in resulting binary is moves, and than try to compile kernel with it?) than use that kernel to run the rest <Melg8[m]>okay, from the video about it, that wouldn't fly - because compiler compiled with this would compile hello world for 3 days. <oriansj>Melg8: one would need to bootstrap a trusted GCC before one could use such a compiler. (As it needs GCC to be built) <oriansj>Also one doesn't have to compromise the binaries to compromise the outputs of the binaries. <nimaje>well, you should be root in docker(?), than just creating a small script at /bin/sudo that runs the command that sudo would run should work(?) <nimaje>and as live-bootstrap don't uses options for sudo (as far as I found) the script would be #!/bin/sh\n"$@" <fossy>siraben: were you running without kvm also?? <fossy>that would have been super fricking slow <siraben>yes if I ran it on an actual NixOS server <siraben>uh I didn't stick around to see how long it took, heh <fossy>lol when gforce_d11977 tried it it ran for multiple days <fossy>can probably just add a --disable-sudo --disable-kvm flags <siraben>fossy: it definitely took less than a day for me <siraben>like a few hours tops (I ssh'd into my server to check on it) <siraben>hah, at most 4 hours according to my IRC messages <siraben>started: Wed 02 Jun 2021 07:38:29 AM UTC <siraben>`date; sudo nix-shell -I nixpkgs=channel:nixpkgs-unstable -p python3 python38Packages.requests qemu linuxPackages_4_4.kernel --run 'python3 ./rootfs.py --chroot --force_timestamps --tmpdir ./temp'; date` <siraben>lol i did not get to find out because a shell gets launched after bootstrapping finishes <stikonas>siraben: well, that's why timestamps option is not the default <stikonas>if you hadn't enabled it, you could then just check for latest file written <siraben>fossy: Wed 02 Jun 2021 15:05:10 PM UTC to 15:59 UTC ***jackhill is now known as KM4MBG
***wowaname is now known as opal
***KM4MBG is now known as jackhill
<Melg8>Hi, is mes-m2, which is build by m2-planet on 13 step with mes-m2.kaem called by (live-bootstrap/sysa/mescc-tools-seed/src/mescc-tools-seed/x86/kaem.run) used anywhere later in the build or not? <oriansj>Melg8: mes-m2 built by M2-Planet is the mes.c binary upon which MesCC runs to compile TCC (assuming they have integrated the latest stage0-posix commit) <Melg8>no, i think i'm looking at version that doesnt include this latest stage0-posix <oriansj>Melg8: that seems like something one would want to get done as it includes some serious performance improvements for mescc-tools and the mescc-tools-extra submodule which allows sha256sum checks of everything although I think I forgot to include the mescc-tools-extra build and the after.kaem hook for live-bootstrap to eliminate the double reboot. <Melg8>why m2-planet -> custom mes-m2 -> GNU Mes (MesCC?) -> TCC - can't some of this pipe collapse into something smaller? <oriansj>Melg8: well the old stage0-posix didn't build a mes-m2 that could run MesCC; So it was kinda a hack around that issue but the latest does build a mes-m2 that can run MesCC (and contains a version of MesCC that works in it too) <Melg8>for example - what TCC can, that MesCC can't? what mes-m2 cant, but full Mes can? i see that like 4 different c compilers, so they have different feature sets, if all of them needed? <oriansj>Melg8: well cc_* is the most minimal C compiler written in assembly so it is the only one that doesn't need a C compiler to be built. M2-Planet is the only C compiler simple enough to be built by cc_* but support macros and a bunch of nice extra features needed to build mes-m2 (a scheme interpreter) MesCC is a scheme program that compiles C programs but includes enough features to build TCC but not GCC. <Melg8>btw, i try to eliminate some of code duplication with generator based on nix, which uses nix to generate kaem scripts, and what i observed so far is that (at least with versions of projects, that used by live-bootstrap) for example file x86_defs.M1 - with slight differences - are used from 3 different places (stage0-posix/x86/, <Melg8>m2-planet/test/common_x86, mes-wip-2_13/lib/m2/x86) that looks strange for me) <Melg8>so in principle - TCC or even GCC could be backported as M2-planet stage (which can be build by cc_) an that's it? <oriansj>Melg8: well those were harmonized in M2libc <oriansj>but yes in theory with sufficient effort TCC or GCC could be built by M2-Planet or cc_*