IRC channel logs

<oriansj>well one could write a bigger compiler in the M2-Planet C subset but that just requires a good deal of work.

<stikonas>yes, it's not clear if it's worth it

<stikonas>since we do have mes

<oriansj>and janneke has a good deal of experience with getting TCC bootstrapped. So there isn't a real advantage.

<fossy>stikonas: i think i'm on the final revision-build cycle with python QEMU fixes now, python build system is a bit wack when it comes to machdep but figured it out (had to set some weird autoconf variable)

<stikonas>fossy: nice. Feel free to push to PR, you can always push further fixes later

<stikonas>fossy: I guess newest versions of Python don't need that fix?

<fossy>stikonas, doras: then, new gcc is def next on my agenda

<fossy>new pythons seem to have the same problem

<stikonas>hmm, interesting, on my Gentoo system python reports as linux, not linux5

<fossy>hmm, perhaps i added something unnessecarily

<stikonas>well, in any case it would be harmless

<fossy>stikonas: wrt GCC, i think we need to jump to GCC 10 then 12, https://gcc.gnu.org/gcc-11/changes.html second dotpoint

<fossy>i think we have discussed this in the past

<stikonas>fossy: yes, gcc 11 needs newer C++

<stikonas>though I might have hit some problems with GCC 10, when I tried

<stikonas>but in that case, just build some older version, like GCC9 or 8

<fossy>yeah

<fossy>do you have any existing work on new gcc?

<stikonas>and you can first try building with pregen files to see if it builds

<stikonas>fossy: not really

<stikonas>I tried running ./configure and make some time ago

<fossy>yeah, no worries, i've done about the same :P

<stikonas>but it was too long time ago, we have made significant changes now

<fossy>not particualrly recently

<stikonas>I don't expect particularly hard issues

<fossy>new gcc has my focus after python, i'm hoping it should be relatively straightforward now that we have everything we could possibly need

<stikonas>rebuilding all autotools stuff is probably the most annoying thing

<fossy>especially autogen, will make it quite more straightforward

<stikonas>well, except for kernel but that's wip

<fossy>yeah, kernel is a bit of a different story haha

<stikonas>yeah, it's somewhat better with autogen

<stikonas>but you'll still need to find exact versions of autotools that work

<stikonas> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration might be useful

<stikonas>but probably outdated

<fossy>usually that isn't too bad, if you inspect the headers of the generated files in the tarball, no?

<stikonas>yeah, usually they say what was used to generate it

<stikonas>fossy: by the way, what should we do with package dependencies

<fossy>yeah, i've been thinking a little bit about it

<stikonas>now with shared libs, latest output tarballs start depending on others, at least musl

<stikonas>so I've tried running python2 on my normal system and it works

<stikonas>(once I fixed symlinks)

<fossy>i don't think there needs to be any significant revision to the build process to care about dependencies. live-bootstrap is a bit unique in that there's only one combination of packages - unlike distributions where there's a huge graph that has to be resolved, ours is all linear. so any notion of package dependencies doesn't really need to be presented outside of a development tool, imo

<stikonas>no, it can be just some text file with recorded dependencies

<fossy>yeah, that was my thoughts too

<stikonas>I mean it's more for the purposes of using binary outside live-bootstrap

<fossy>particularly in a human+machine readable format

<stikonas>right now e.g. you can just run "bash" on any system

<stikonas>can be musl distro, glibc distro, anything and it just runs

<fossy>right

<fossy>i think just a file with something like: "Python-3.11.1 rundep musl-1.2.1" or whatever is likely sufficient representation, it's really easy to parse and allows for different types of deps in place of "rundep"

<stikonas>and for python, I have to unpack musl package; ln -s usr/bin bin; ln -s usr/lib lib; unpack python; PYTHONHOME=usr lib/ld-musl-i386.so.1 usr/bin/python

<stikonas>yes, something like that would have sufficient info

<stikonas>it can even be created manually

<fossy>yeah, doesn't need to be automatic

<fossy>there's not any guesswork either if you use ldd

<fossy>you just need to know where the library comes from

<stikonas>indeed

<stikonas>and we have ldd in musl's package

<stikonas>though if we want to automate

<stikonas>we can emit list of so files that package provides

<stikonas>this is easy enough to do

<fossy>yeah tar can do that

<oriansj>well at live-bootstrap's current growth rate: fossy/stikonas will have their own Linux Distro with its own custom package manager

<fossy>haha

<stikonas>unlikely to go much further though :D

<stikonas>it's a good base

<stikonas>well, one can always add extras, like openjdk :D

<fossy>to some extent, live-bootstrap kinda is a jank as distro in its end form

<fossy>but it's never really intended to be a distro

<fossy>(or become one)

<stikonas>yeah, it's a bit of a mess for distro

<stikonas>but we had to add some distro like stuff (like packages)

<stikonas>otherwise it's hard to maintain

<fossy>yeah, useful abstractions that happen to come from distros, really

<oriansj>well a package manager at its core only needs to download source files and orchestrate the building of packages

<oriansj>and you already kind of have that

<stikonas>by the way, at some point we probably want a new release of stage0-posix, I guess not urgent but we do have quite a few improvements now

<stikonas>yeah DESTDIR stuff that comes from distros helped us a lot (we used to manually list individual files and their hashes before)

<stikonas>it was pain to update all hashes then

<oriansj>well I guess rm, unbz2 and all of the major changes in M2libc/M2-Planet definitely would qualify for a fresh release

<oriansj>did you want to do the honor stikonas? or shall I

<stikonas>We should probably gather a changelog of all notable changes

<stikonas>doesnt' have to be today

<stikonas>I can first do some more conversions of amd64/x86 defines...

<oriansj>well if I was smarter, I probably should have added a CHANGELOG.org to stage0-posix like I have with mescc-tools

<stikonas>well, we can start it for current release

<stikonas>over the next days/weeks we can retroactively add stuff that was added since last release

<stikonas>it's just that we are likely to get more coverage if we say what's new in the release.

<stikonas>fossy: your last commit conflicts with my fix that I pushed

<fossy>stikonas: i meant to rebase & remove mine, but forgot to before pushing

<stikonas>sure, no problem

<stikonas>ok, and I see you pushed parts.rst

<stikonas>that will help a bit with reviewing regenerated files

<fossy>yes, it's not incredibly extensive, but the highlights are there

IRC channel logs

2023-01-16.log