<oriansj>looks like mes-m2 needs to grow some documentation about how to get MesCC working on it. <oriansj>from a fresh git clone --recursive and on commit f9ebb331680b4d4e2f16b5c401f143fdd62b0e0a <oriansj>The solution I found was you need to install python3-distutils as well. So you might wish to add it to your README as a dependency along with python3 ***stikonas_ is now known as stikonas
<stikonas>you probably changed live-bootstrap a lot recently <stikonas>hex2 for risc-v is also going not too bad but will have to wait until I find more time to finish it <stikonas>got most of the stuff working, just need to fix some issue with . (rest of the things are working) <fossy>yes, I will add that, thanks oriansj ***lithium.libera.chat sets mode: +o ChanServ
<pabs3>I replied saying bootstrappable aims to ignore tarball cruft, so bootstrap just from VCS exports should work just as well as tarballs. I hope I am correct there <stikonas>pabs3: we had some of the same problems in live-bootstrap <stikonas>what we ended up doing is to extract info (command to import gnulib) from released tarball and then re-import gnulib into released tarball. This was not always possible, so for some projects we started with VCS snapshot <stikonas>in principle we could have used vcs snapshot for everything <stikonas>regarding tools, there are no extra dependencies because we already rebuilt all pre-gen files <stikonas>(but that's not what distros usually do) <pabs3>Debian aims to at least, we autoreconf by default. of course using crufty release tarballs papers over various issues, like not depending on autoconf-archive <stikonas>so basically live-bootstrap is trying to the following 1) No pre-gen files used (kernel might end up exception but I think we'll still remove most of the blobs if we use linux-libre) 2) Try to use release tarballs and use it if that works 3) Use VCS snapshot otherwise <stikonas>pabs3: yeah, autoreconf is big part of initial preparation <pabs3>what do you do about embedded code copies like m4 from autoconf-archive or $whoknowswhere ? <pabs3>(the thread above is me trying to get Debian to switch away from crates.io/PyPI/Rubygems/etc packages to VCS exports) <stikonas>nothing, embedded copies are used in live-bootstrap as long as it's human written <stikonas>another cleanup thing we often do is remove bison/flex generated files <stikonas>removing info files too (those are less imporant I guess but we do that too) <pabs3>I see, so lots of things might break if you went with VCS tarballs, as some upstreams don't do embedding in their VCS but do in their tarballs <stikonas># libunistring does not specify which gnulib snapshot was used, pick a random one that works <stikonas>there was no info in either tarball or vcs <pabs3>how much churn is there in gnulib? <stikonas>I'm not too familiar with gnulib, but mots gnu packages use it <stikonas>is that gnulib import process generates Makefile.am file <stikonas>which is a fairly simple file, perfectly human readable <stikonas>so to reimport gnulib process was basically <stikonas>check if auto-generated Makefile.am file has a comment with command used to import gnulib <stikonas>if there is no comment, try to figure out command via other means <oriansj>pabs3: well VCS are a good match for rolling releases of software. It isn't a good match for "this shit is touchy as hell software". In regards to bootstrappable builds; we may distribute things like stage0-posix and live-bootstrap using git but honestly we stick largely with tars as untar.c is much easier to bootstrap than git clone. <pabs3>yeah, in the context of the thread I'm talking about `git archive` tarballs, rather than git clone <pabs3>one can use those along with the git tags <fossy>stikonas: as far as i can tell currently in my branch there is no pregen files. but i could have missed something <fossy>what a stupid checksum mismatch between chroot and qemu <fossy>some random line number dwarf information <fossy>i think i will just disable debugging lol <stikonas>maybe we should switch away to some other implementation?