IRC channel logs

<matrix_bridge><Lance R. Vick> Possibly more reliable, but using a proprietary Microsoft product as the source of truth for a Linux distro is suboptimal IMIO. Codeberg has support for hosting arbitrary artifacts with no limits for open source projects though. I am considering mirroring all the external source files for stagex, including for live-bootstrap, there.

<sam_>oriansj, fossy, et. al: thank you for the takes!

<GoogulatorMobile>lrvick2: unless Microsoft is able to preimage SHA256, the worst they can do even with full control over the source tarballs is DoSing live-bootstrap, which is essentially what already happens with unstable sources, albeit not intentionally.

<matrix_bridge><cosinusoidally> https://github.com/actions/runner-images/discussions/7191#discussioncomment-8173888 not sure if this has been officially announced but free tier github actions may now be able to use nested virtualization. Could potentially be used to have ci for the qemu path of live-bootstrap?

<stikonas>fossy: is bzip2 download broken for you?

<snuik>stikonas, you have 1 message

<snuik>stikonas, Googulator says: amd64 and riscv64 checksums might need updating too

<stikonas>hmm, perhaps just my one system is boken

<stikonas>broken

<stikonas>seems to work elsewhere

<oriansj>Googulator: well we should probably make many possible root sources of the tarballs.

<oriansj>say git-lfs, gnunet, ipfs, torrents, hosting servers, etc

<oriansj>I was also thinking of a gemini file share; as a quite minimal client could be used.

<oriansj>say bootstrap gmni and just download the rest of the bootstrap tarballs.

<stikonas>some of the sources are not easy to maintain, since tarballs change a bit as we develop live-bootstrap

<lrvick2>Really strugging to get bison 3.8.2 reproducible. Headers all out of order. Having the same problem with gettext, but every other package is bit for bit identical. https://sprunge.us/37CODL

<lrvick2>starting to conside the consequences of using the older version live-bootstrap uses

<oriansj>Googulator: or if we trust unecrypted protocols, we could leverage bash to do the downloads: { echo -e "GET /gnu/wget/ HTTP/1.0\r\nHost: ftp.gnu.org\r\n\r" >&3; cat <&3 ; } 3<> /dev/tcp/ftp.gnu.org/80

<GoogulatorMobile>The issue isn't with trusting unencrypted protocols themselves, but rather for how long they will remain usable

<GoogulatorMobile>Especially since that's a HTTP 1.0 request, which causes problems with virtual servers

<GoogulatorMobile>IIRC Host: isn't even a valid header for HTTP 1.0, but 1.1 will probably need more headers to be valid

<oriansj>That isn't a big problem either, as we could have a minimal client that just reads and writes to /dev/tcp/$HOST

<oriansj>and protocols like torrents can surivive for decades without a single party being responsible for seeding

<oriansj>^surivive^survive^

<deesix>The usage of github for the whole development is, in my opinion, really-really disturbing, indeed.

<oriansj>deesix: well stage0 and all related too tools could easily be moved to sourcehut (they are already mirrored there)

<oriansj>but ultimately it is dependent on what other people like to use

<deesix>The web of hardcoded submodules is not easy to undo; not to mention all the data about issues, etc...

<oriansj>deesix: it is easier than you think. Just move the M2libc repo, then all the rest and finally stage0-posix/stage0-uefi/stage0

<oriansj>Googulator: note that to strip off the http 1.1 header one only needs: https://paste.debian.net/1306909/

<oriansj>which when combined with: { echo -e "GET /gnu/wget/wget2-latest.tar.gz HTTP/1.0\r\nHost: ftp.gnu.org\r\n\r" >&3; cat <&3 ; } 3<> /dev/tcp/ftp.gnu.org/80 >| wget2-latest.tar.gz will get you the wget.tar.gz

<oriansj>you know what, I might as well write a little C program that uses /dev/tcp to download files for mescc-tools-extra

<oriansj>I wonder if Fiwix supports that too?

<deesix>oriansj, good luck with those "just" and "easier". Moving everything out is practically imposible.

<stikonas>why impossible?

<stikonas>it's really just doing git push

<stikonas>and submodules are independent, they don't have to be in the same location

<stikonas>so one can move main repo and submodules independently

<stikonas>e.g. I self-host stage0-uefi myself but various submodules (M2-Planet, etc...) point to oriansj's repos

<stikonas>what is slightly trickier is having two maintained upstream repos (e.g. like mescc-tools have)

<stikonas>easy to forget to sync them...

<oriansj>correction /dev/tcp is a bash abstraction that doesn't actually exist on linux

<deesix>stikonas, consider all the existing history with the hardcoded URLs in the submodules, for example. I'd love to have a mirror of all repos, all with relative submodules; it's a mess (if even possible). And, again... the lock-in is not just about the repo (the "forge" contains lots of data).

<oriansj>so I will probably need to read a bit more to make a tcp client

<stikonas>there isn't that much data in the forge... mostly merge requests, most without even description

<oriansj>deesix: if there is a sufficiently good reason to replace submodules with something better, we will do so

<stikonas>one can always switch to relative paths for submodules

<deesix>stikonas, what about "issues"?

<stikonas>no many of those either...

<oriansj>deesix: as long as the developers here agree on what to do, the rest can be replaced.

<stikonas>see for yourself: https://github.com/oriansj/stage0-posix/issues?q=is%3Aissue+is%3Aclosed

<stikonas>not a big loss even if this is lost

<stikonas>probably a bit more in individual submodule such as M2-Planet

<oriansj>heck we did a vote to move here from freenode

<stikonas>but still not too many

<oriansj>and that was a big and risky move

<oriansj>moving where submodules point is not an issue

<oriansj>especially if the current git repos can just remain as minor mirrors

<oriansj>with a line in the README pointing to where the master repo is located.

<oriansj>like you see in stage0

<deesix>oriansj, how can one replace the already commited URLs in the history?

<deesix>(without rewritting it)

<deesix>wrt submodules

<deesix>(recursively)

IRC channel logs

2024-02-10.log