IRC channel logs

<oriansj>The final votes results: https://paste.debian.net/1199541/ (unless I missed your vote or accidentially recorded it wrong) looks like our final stop is libera.chat

<stikonas>well, libera.chat seems to be winning by quite some margin

<stikonas>so unless there are lots of missed votes (unlikely)...

<oriansj>stikonas: well most peopls simply obstained fro voting, so a majority isn't possible but yes it does look that way.

<oriansj>also I think most people probably don't want another move so soon, as it would present more risks without any measurable gain.

<siraben>oriansj: do you mind announcing the move on the mailing list or somewhere public?

<oriansj>siraben: done: https://www.freelists.org/post/bootstrappable/Freenode,1

<siraben>oriansj: thank you, I'll add it to freenode-exodus

<siraben>I was informed someone created https://tinyurl.com/fleenode2

<Melg8>siraben i guess it would be "python3 ./rootfs.py --chroot" or "python3 ./rootfs.py --chroot --force_timestamps --tmpdir ./temp"

<siraben>Melg8: thanks, that works

<siraben>Melg8: what's the --force_timestamps option for?

<Melg8>siraben it sets all timestamps in image to be 0 unix time (even for links) so when all other problems with reproducibility would be fixed - it will be same bit by bit image with result of build. if that option is off - it would use current time - and that woud give difference in files each time

<Melg8>siraben same idea as all derivation results in nix/store have same date

<siraben>I notice that it's using only one core (I'm on the MES stage), does it go multi-core later on?

<siraben>would help with CI time

***nimaje1 is now known as nimaje

<siraben>Melg8: happy to stay that it works

<siraben>say*

<siraben>yay, gcc 4.0.4!

<siraben> https://github.com/fosslinux/live-bootstrap/issues/123

***attila_lendvai_ is now known as attila_lendvai

***roptat_ is now known as Guest5512

<Melg8>Hi, why when building mescc-tools - we use --BaseAddress 0x8048000 and but when building mes itself - it 0x1000000? (see https://gitlab.com/janneke/mes/-/blob/2ab4c5c676cb66088b0fb8de03b40b01f07bd4e0/kaem.run#L131) - what that address mean? what are rules for choose that value?

<stikonas>Melg8: I don't know how those values were chosen, it would be good if there was explanation for that somewhere, but that number is address of base pointer

<stikonas>e.g. see a bit here https://codearcana.com/posts/2013/05/21/a-brief-introduction-to-x86-calling-conventions.html

<stikonas>but I think it has to be explained somewhere if the goal for bootstrap to be understood by most programmers

<Melg8>i mean, if i use 8048000 for mes - what would break?

<stikonas>Melg8: well, try

<stikonas>maybe it will crash...

<Melg8[m]>i'll just do same thing here - want to hashes of binaries be same with live-bootstrap, or debugging would be nightmare

<stikonas>changing base pointer would certainly change hashes of binaries

<Melg8>it was surprising to me that mes includes kaem scripts in it)

<stikonas>not the official mes tarballs if I remember correctly

<stikonas>we wrote manual kaem scripts for those

<stikonas>maybe oriansj's fork has kaem scripts

<mihi>hello :) finally found time again to look at Debian's dependency graph for bootstrap issues. There are 254 source packages that require themselves (or rather, its build outputs) to be installed to be compiled, not counting the 78 build-essential source packages.

<Hagfish>oof, i thought Debian had tried solving that with "build profiles"(?)

IRC channel logs

2021-06-01.log