IRC channel logs
2023-02-05.log
back to list of logs
<doras>We only removed older versions so far. <doras>We noticed some symlinks are missing, and that gzip doesn't seem to have a proper package. <fossy>doras: gzip's lack of package is because we never rebuild it after kaem stage (!) -- might look into doing that, even if it's just for increased performance.. <fossy>and gzip 1.2.4 is really old <fossy>doras: can you open an issue for missing symlinks? <stikonas[m]>Hmm, I might have briefly considered updating gzip but didn't get to it <stikonas>by the way, which package has missing symlinks? <fossy>just need to add in --disable-bootstrap and test it properly <doras>fossy: basically the various bin and sbin symlinks are missing. I'll open an issue later if nobody does it before me (or fixes it). <stikonas>for live-bootstrap we want to keep all tarballs (so that it is easy to get checksums) <stikonas>but any consumer wouldn't need older stuff <fossy>we already have usrmerge symlinks in live-bootstrap, no? <fossy>doras: or do you mean they aren't in any package? <fossy>i guess we could have a base-structure package or something, but i'm not really sure if they belong in a package? <stikonas>well, musl package was not very convenient without them <stikonas>as things (e.g. python's) were looking for /lib/ld*.so <doras>fossy: a filesystem package is a common thing to have. <fossy>for distributions, where everything must be a package, yes <fossy>i'm not intrinsically opposed to the idea <stikonas>can we not just add symlinks to all tar.bz2 files? <stikonas>though I'm still not sure which ones actually need them <doras>I guess the symlinks are not a must if we can get everything installed to /usr/bin instead of the various other bin/sbin locations. <doras>I mean a filesystem package is not a must in that case. <doras>stikonas: I lost the diff (power outage :\) but there were a few packages that installed files to sbin <fossy>also, nice talk ekaitz, i particularly appreciated the gcc internals dive :) <doras>I didn't get a chance to check which, but there were ~5 binaries there. I guess it's possible that they came from the same package. <stikonas>if it's just 1 package, perhaps we can just create symlinks in it <stikonas>I didn't test all packages standalone, but most just work after unpacking them in random directory <stikonas>might be that something like gcc does not... <fossy>it wouldn't without binutils <fossy>because it shells out to as ld <stikonas>yeah, that's why I said gcc, when it shells out it might look in symlinked paths <stikonas>(well, you would need to extract binutils and gcc, but that might still be missing symlinks) <doras>Basically extracting all packages in-order to a directory and comparing sysc_image will reveal the files in sbin (and missing symlinks). <doras>I may do it sometime next week if I find some time <doras>Oh, and we now build live-bootstrap inside BuildStream's sandbox. <doras>So the subset of packages we install from sysc are now cached in our remote artifact server. <doras>I'm doing a final rework to my freedesktop-sdk MR, and then we'd finally have the entire bootstrap process end-to-end upstream. <fossy>first integration of live-bootstrap! <stikonas>sigh, testing mrustc is quite slow... I can only do 2 runs per day but hopefully the current one will finish successfully <stikonas>live-bootstrap would struggle with mrustc anyway as it is x86... <stikonas>fossy: hmm, there is one question that I now have after ekaitz talk <stikonas>remember those machine definition files in lisp <stikonas>any idea how we use them (since I don't think we use mes to parse them) <fossy>i think it's lisp-esque, not lisp itself <fossy>theres a bunch of genXYZ invocs using .md file in gcc/Makefile.in <stikonas>yeah, possibly gcc source includes tools to work with it <ekaitz>fossy: thank you! I didn't really know how to put it so... It was a set of random information but I think it turned out ok <ekaitz>stikonas: those MD files are processed in the build system of GCC directly, there are some files called gen-* that are compiled first, those read the MD files and then generate C code that is added to the sources of the compiler <ekaitz>we could read them with a custom parser or something, but I don't think it makes any sense <ekaitz>I don't know if I understood you <stikonas>no need, I was only worried that maybe I've missed some pregenerated files in GCC <stikonas>(since in live-bootstrap we don't want to use any autogenerated files) <ekaitz>stikonas: probably not, they are generated when building gcc itself <ekaitz>there are internal tools to do that <ekaitz>in summary, gcc has some compilation going in the configure step <ekaitz>gcc's build system is a pain in the ass <stikonas>it has top-level configure which is not autotools based <stikonas>which are independent autotools projects <stikonas>and in live-bootstrap we couldn't use top level stuff until almost the end when we finally managed to build gnu autogen <ekaitz>and also it takes files from one to the other <ekaitz>it's mixing stuff from gcc and libgcc folders <ekaitz>fossy: if you want to learn more about GCC's internals there's a course in the internet about it <stikonas>oriansj: can you tag 09d43f0538c87501dcb55889772e024deb4869a4 commit in M2-Mesoplanet (that's previous release) <stikonas>hmm, actually a lot of other git submodules are not tagged... So maybe it's not worth tagging them retroactively, though it would be good to tag it for the next release