<OriansJ`>I must say the README has one heck of a delta <OriansJ`>So the next release of stage0-posix will unfortunately have to build the x86 binary for mes-m2 (until I properly port it to M2libc) <Hagfish>does it make sense for me to ask how M2libc compares in size to something like musl? <fossy>OriansJ`: what do you mean, build the x86 binary for mes-m2? <fossy>cant --bootstrap-mode just be used? <stikonas>fossy: should I use one word per line in import-gnulib? <fossy>stikonas: i prefer one word per line, i think that is the most readable <stikonas>well, both were pasted from the comments in generated file <fossy>i think if you split it manually it would be better tho <stikonas>ok, I'll remove pylint since in the end I actually used default file <fossy>i'm moving back a version to perl 5.10 cause 5.12 seems to be kinda buggy <stikonas>I briefly looked at building makeinfo but it needs newer perl <fossy>hopefully 5.10 is more simple <fossy>5.12 had almost double the number of .o's than 5.6 for libperl <stikonas>but then we discovered those pregenerated files <stikonas>so went with that chain starting from 5.0 <stikonas>fossy: the other PR updatede too (although, it's on top of findutils branch) <stikonas>ok, pylint passes without that pylintcfg <stikonas>fossy: by the way, when are you building perl, after 5.6 of after gcc?\ <OriansJ`>Hagfish: yes it is certainly a reasonable question. It is smaller but it should grow to the size required to build TCC with mescc. <OriansJ`>fossy: well if you remember M2-Planet builds require asm blocks to do system calls and such things are unique for each architecture. So mes-m2 is using the asm blocks that janneke did and they are x86 specific. So to make a mes-m2 binary that runs on AArch64 or armv7l, I'll have to provide those bits of functionality on those architectures as well. <OriansJ`>The path forward would be to implement that functionality in M2libc <fossy><stikonas> fossy: by the way, when are you building perl, after 5.6 of after gcc?\ <stikonas>fossy: so are findutils and rootfs.py port ready for merge, or do I need to make more fixes? <fossy>stikonas: just merged before seeing lol ***ChanServ sets mode: +o rekado_
***Noisytoot is now known as Noisytoot__
***Noisytoot__ is now known as Noisytoot
***stikonas_ is now known as stikonas
<stikonas>although, I can't run it as many times as you did <bauen1>stikonas: can you push your fixes somewhere ? <stikonas>bauen1: so I think timestamp of autoconf.in will not be greated than that of autoconf.as <stikonas>and we need to regenerate it in any case <bauen1>stikonas: not sure if there are other dependencies specified in the makefile <stikonas>bauen1: ok, it actually doesn't build at autoconf-2.65 <stikonas>I wonder if dependencies are solved in autoconf 2.65 <gforce_de1977> stikonas: no problem, i will start tomorrow a new massrun, so we have results 24h later <stikonas>no idea about the other failures right now <stikonas>but if we can fix at least this one, that would still be good <gforce_de1977>stikonas: it does not matter for now, it is just a computer which has time and electricity 8-))) <stikonas>by the way, you might need to do some minor adjustments to your script <stikonas>./rootfs.py is mostly compatible, but command line flags now have dashes in front, e.g. ./rootfs.py --chroot (or -c) ***nckx is now known as jorts
<stikonas>bauen1: so unfortunately autoconf that patch doesn't help... <stikonas>although, it's still good to merge, but I should remove "Fixes: #92" from description... <stikonas>(I'll possibly convert it to simply rm bin/autoconf.in file) <stikonas>hmm, I think the correct workaroud would be to first run make -C lib