IRC channel logs

<oriansj>test blobs should never be needed; no exceptions

<oriansj>if you have a test that requires a blob; build it as part of the test so that everyone knows exactly whats up

<oriansj>and I believe there is a path one could build zig without binaries but the window to document that in guix is closing.

<oriansj>and I think the idempotent rebuilds is knocking on a very common idea that; we can encode what is needed to build a program and we should. Then the entire build question becomes a solved problem with fixed assets.

<robin>oriansj, what is closing the window re: zig? bootstrapping complexity?

<oriansj>robin: internet history disappearing with the bits and details needed

<robin>ah, ty

<oriansj>once the build chain is in guix and the bits mirrored into the Software Heritage archive, then it'll stick around for a while (basically until something crazy happens)

<andydude>What is the software heritage archive?

<andydude>Sounds like GH code vault

<AwesomeAdam54321>andydude: It's an archive of source code for preservation

<robin>oriansj, d'you know if anyone's working on zig stuff?

<robin>sounds like something i might be able to handle, plus i know a very early contributor

<andydude>I like zig

<andydude>There is one thing I don't like about Zig

<andydude>and that's the tendency/tradition of using structs like JavaScript people use objects

<andydude>I prefer closed/well-defined structs over open/hash-table type maps

<andydude>So my scheme hex0 was short, for some reason it turned into several pages when I wrote it in python

<andydude> https://gist.github.com/andydude/3c0dbe962c8b723a9547702bba21a76c

<pabs3>andydude: https://archive.softwareheritage.org/ - they import all of GitHub/GitLab (but have a backlog), Debian/Guix and various other distros, lots of other forges

<pabs3>oriansj: re internet history disappearing, if anything is still up and needs saving imminently, I'm part of ArchiveTeam and we can save (to archive.org) at-risk sites (or proactively save others) https://wiki.archiveteam.org/

<pabs3>ArchiveTeam also have a code archiving project, but its more about at-risk stuff https://wiki.archiveteam.org/index.php/Codearchiver

<pabs3>(I'm also part of SWH a bit)

<pabs3>sam_: the repro builds folks are also working on reproducing the existing binaries, as well as the existing fuzzing stuff to reduce sources of non-determinism

<andydude>my understanding is the guix removes timestamps and replaces parts of scripts to make sure there's none of that

<andydude>one project I would save is xar

<andydude>looks like it's already archived

<andydude>Apple put some notice in their fork saying that it's unmaintained, but I'm also sure it's used by 100% of the installers in macos

<oriansj>hmm; I see 0.9.1 and 0.10.1 in guix already. But looking at the 0.10.1 build, I think it is doing the build with the generated sources as 0.10 onward are written in zig and not C; so clang couldn't be compiling the human written sources.

<aggi>the GNU buildsystem side is rather fragile

<aggi>setting LIBTOOL="slibtool -all-static"; the entire tree collapses

<aggi>AR="tcc -ar"... have fun

<aggi>i am trying to cover all relevant test-cases (with cross-compilation involved), and keeping this fully reproducible/deterministic, all emerge logs, sources, distfiles, hashes archived

<aggi>all changes made can be diffed, from my hotfix-overlay against gentoo portage tree (except for what i had to pull manually from the old gentoo-archives predating their year2013 transition)

<aggi>hence, if an ebuild did not come from mainline portage tree, it came from their archives, and a few dozen ebuilds i had written myself

<aggi>i think it's completely tracked with timestamps and hashes, didn't miss anything

<aggi>it is important the gentoo-archives and their distfiles do not vanish

<aggi>i did mirror the distfiles, but quit syncing 2022, because it's too much

<aggi>removing all c++ dependencies simplified the whole approach

<aggi>the principle issue with this, those depenendencies are not _optional_ with what upstream did since ~2013

<aggi>gentoo, as an exemplary case, covers broader requirements, than what bootstrappable alone did

<aggi>the little patching required for tcc-toolchain, is maintained with a tcc-9999.ebuild itself too

<aggi>hence patches and build-time configuration can be scraped easily

<aggi>current status is, i have to abandon both, autotools/perl and gentoo/python

<aggi>which is remarkable, because otherwise many complicated builds succeeded (such as statically linked mplayer, ffmpeg, with tcc-toolchain _only_)

<aggi>meaning, in principle, my approach has proven appropriate, but among ~500ebuilds python/gentoo and perl/gnu refused to

<aggi>there wasn't any thought given to this problem yet

<aggi>gentoo itself reported bootstrapping success, but this includes inviting upstream madhouse

<aggi>full tcc-toolchain support within gentoo and GNU isn't some fringe niche corner-case, currently it is the _only_ viable option

<aggi>i consider it a bad excuse, when #bootstrappable argues a fast transition towards gcc/binutils were necessary

<aggi>or, to put it another way: what's not passing acceptence criteria of bootstrappable isn't worth bootstrapping nor archival

<aggi>if perl/autotools and python/gentoo didn't pass with tcc-toolchain (and/or related static linking problem), then it's not worth the efforts

<aggi>this too affects linux-kernel itself

<aggi>the choice either bootstrappable or gentoo or linux had to make, was either fully supporting tcc, or don't

<aggi>to my understanding, linux-kernel already made this decision, without support for tcc (except some experimental linux-2.4 proof-of-concept)

<aggi>gentoo had made the decision too

<lanodan>Which makes me wonder about swapping linux-kernel for fiwix, wouldn't be very modern but at least you'd get a rather simple system

<aggi>I kept linux-2.4/tcc on TODO

<nikolar>now that you mention it, what's the newest linux that can be built with only tcc

<aggi>linux-2.4

<nikolar>ah ok

<nikolar>do newer versions use a lot of compiler specific feature

<nikolar>features

<aggi>there was several transitions

<lanodan>Maybe one could try to rebase the patches on more current versions but that sounds horribly tedious, specially without upstream support

<nikolar>indeed

<nikolar>the kernel has grown a lot since 2.x

<aggi>bootstrappable patching to musl-libc was very helpful

<aggi>yet you see... --disable-shared

<aggi>and then, you got the fun ones with perl and python following

<aggi>even when bootstrappable transitions to gcc/binutils; the side-effects of --disable-shared remained

<aggi>at this spot i consider bootstrapping deadlocked/trapped still

<nikolar>is there a repo with tcc compilible linux, i want to mess with it :)

<aggi>i got a complete userspace bootstrapped, but it is missing the tools needed to do so: autotools and gentoo, because those aren't self-hosting with tcc

<aggi>as a consequence there is the following options: 1) abandoning autotools and gentoo (which is desireable but not feasible currently)

<aggi>or 2) repairing perl and python which is very difficult, and wouldn't abandon autotools and gentoo

<aggi>option 1) was the recommended approach, but it is enormous efforts necessary to accomplish this

<aggi>option 3) is the status quo, i can emit a tcc-compiled distribution, but it isn't self-hosting

<aggi>this at least is sufficient, to continue development, to approach various milestones gradually

<aggi>but abandoning gentoo and autotools is an "all-at-once" "all-or-nothing" mega task, and i am _forced_ to do so currently

<aggi>or anyone else, who would try to fully support tcc

<aggi>so far it seems, noone had tried yet, although it is feasible

<aggi>and desirable, but it was avoided, and/or close to sabotaged GNU/linux remained portable accross toolchains (including a quality one that tcc is)

IRC channel logs

2024-08-16.log