<stikonas>the other PR with autoconf pregen files still has some issues, so in draft mode for ow <stikonas>gforce_de1977: btw, I guess there is little point of running parallel tests until I finish my PR, so maybe we can postpone it a bit <fossy>stikonas[m]: i have now finished perl 5.10 <fossy>but it is only suitable for bootstrapping newer perl (i culled all extensions) <fossy>(because that wouldn't build and i only want it for newer perl) <fossy>i think metaconfig is doable for newer perl because debian does it <fossy>so if debian can we probably can <stikonas[m]>Hmm, in this case we might want to wait for either metaconfig before enabling build (can still merge without run2.sh) or stow... <gforce_de1977>i have done this night a massrun with an "old" checkout, just for getting better numbers (there where 88 qemu-instances non-booting in the run before, seems fixed now): https://paste.debian.net/1193291/ (the numbers are still valid) <gforce_de1977>now i will concentrate on a very fresh checkout with rootfs.py <gforce_de1977>stikonas: take your time and poke if i should start another run <bauen1>stikonas[m]: the problem with make is that some autoconf versions are lacking dependencies, so that would need to be fixed and then a rm should all be that is necessary <bauen1>i can also pr my commits to make stow work in <bauen1>just the rest of making builds use stow and versioned autohell is very messy <stikonas>fossy: if you are not building full perl for 5.10, maybe microperl is enough? <stikonas>I guess it should have the same functionality <bauen1>>_> automake-1.10.3 hard codes `autoreconf` in the Makefile <bauen1>thank you autohell tools for nothing, again <stikonas>bauen1: oh, and AUTORECONF= varaible doesn't help? <stikonas>bauen1: by the way, what's the reason we can't have non-versioned autotools symlinks with stow? <bauen1>stikonas: well, we can but then we can only have one autotools linked, and imho being specific with the versions is good, especially once i try to move some of these into chroots where i need to know the version used <bauen1>stikonas: you could recreate the autotools unversioned symlinks everytime to point to the newest version <stikonas>I know we need more than one for binutils and gcc <bauen1>i've pushed my latest wip again, but i don't really like how messy all of this is <stikonas>well, you can try to clean it up a bit until you are happier <fossy><stikonas> fossy: if you are not building full perl for 5.10, maybe microperl is enough? <bauen1>idk, currently run.sh is imo too messy <fossy>no im building full Perl -extensions <fossy>It needs full stdlib support <stikonas>ok, I see. Anyway, I don't know the right term either <bauen1>i could also try to build a upkg-build tool to do chroot builds right after we get stow, but i still need to figure out a good way of getting the pseudo packages into the chroot <stikonas>but yeah, I think run.sh has to be cleaned up a bit more <stikonas>or at least complexity hidden in some function <bauen1>stikonas: stow is already working quite well <stikonas>well, I mean you have those link and unlik fucntions <bauen1>true, but imho it's still quite messy :/ <bauen1>stikonas: once i catch up to run2 i'll probably rebase, clean up the commits and make a pr <stikonas>still better than before, but can try to make it even less messy <bauen1>stikonas: i can start writing a upkg_build1 wrapper that takes care of the first few things (and will eventually be turned into upkg-build to do chroot builds) <stikonas>is to have build function do a bit more work <stikonas>now all build steps are prefixed with DESTDIR <bauen1>for now i'm playing catch up with all the autotools to specify the concrete version used <bauen1>defining DESTDIR is usally easy, except for cases with multiple stages / passes, so i would have to rewrite it, but i'll do this next <stikonas>although, we only care about the last pass <stikonas>so maybe can do something like: use the same destdir, but if it exists, remove previous destdir once we are ready to install into a new one <bauen1>yes, i also thought about making all the "staged" builds e.g. autoconf bootstrapping into one <bauen1>stikonas: i'd prefer not to do any "remove exisiting" if at all possible <bauen1>stikonas: eventually i can then "preseed" the packages and have upkg skip things if checksums match expected values <stikonas>well, can always name DESTDIR=pkg_name_build_script_name <bauen1>probably $(basename $script_name) but yes that should work <bauen1>isn't there some compression program that does exactly that ? <OriansJ`>gforce_de1977: well it certainly is for initial seed to be a subset of PI; finding it is a bit more of a problem. Making it a prime number would be far easier. <stikonas>well, any program is almost surely is a subset of pi digits <stikonas>anyway, being prime of subset of pi does not guarantee that there are no backdoors <stikonas>since pi also should have all malicious programs somewhere in its digits <bauen1>btw is there a proper name for the autoconf / automake tools ? i just keep calling them autohell, but that might not be quite appropiate <bauen1>gforce_de1977: by the way, how did you get sha256sum to do a recursive checksum of a directory ? <Hagfish>gforce_de1977: you know me too well :) i've already trolled the HN discussion about it <Hagfish>well, i didn't mention bootstrapping, but i see what you mean about it overlapping with this project <Hagfish>i think the advantage of turning a program into a prime is that it allows it to be published while not the program itself is illegal <Hagfish>hopefully that won't ever be the case for bootstraps <Hagfish>but yeah, putting the seed into a tweet (in some encoding), and on various blockchains would be a nice way of ensuring it is universally (and permanently) available <Hagfish>unfortunately the various source code packages won't be so easy to make available <Hagfish>if we're relying on hash matching to secure those, then maybe we only care about the hash of the initial seed <Hagfish>as long as you can trust the system which checks the hash of the seed you want to use, hmm <bauen1>you should also include the sha1 of live-bootstraps most recent commit ? <bauen1>(sha256 would be better), then you have a hash tree from using which you can get to gcc 4 <stikonas>bauen1: where is sha256sum used recursively? <bauen1>stikonas: in a log of gforce_de1977 runs <gforce_de1977>its just this command: sha256sum /after/bin/* /after/lib/* /after/include/* /after/share/* || true <gforce_de1977>fossy: please review pull-96 and merge, and i can make another shot of mass-testruns <stikonas>gforce_de1977: can you run mass-test run on branch of PR? <stikonas>that might give us more info whether PR works <gforce_de1977>stikonas: good idea, running on branch is no problem, will do ***jorts is now known as nckx
***cbaines_ is now known as cbaines