IRC channel logs
2024-05-10.log
back to list of logs
<oriansj>well I do like the idea of improving the security situation of git workflows, git namespaces make me wonder about potential security exploits that can be hidden inside of them. <matrix_bridge><Andrius Štikonas> fossy: yeah, I noticed missing libdir in heirloom too <matrix_bridge><Andrius Štikonas> Also byacc uses different convention for makefile (in files and not in mk/) <matrix_bridge><Andrius Štikonas> But early preseed is at least redistributable now, no more cddl+GPL issue... <stikonas>well, for #live-bootstrap we need to build from source <fossy>would depend a bit. what is git->dist-tarball doing <fossy>or is it just packaging it up into a tarball? <stikonas>but yeah, hard to tell without more details <stikonas>i assume all distros just use tarball, so they don't need ruby <kpcyrd>fossy: it's generating files, otherwise it'd be a non-issue (and `git archive` doesn't require ruby) :) <stikonas>yeah, so that's not good enough for live-bootstrap <stikonas>that's why we bootstrap flex, bison, perl and autoconf the long way <stikonas>python too does quite a few rebuilds, starting from 2.4 <kpcyrd>stikonas: Arch Linux is trying to avoid pre-processed source code (post Jia Tan) and prefer building from git snapshots, that's how the topic came up :) <stikonas>how do they deal with bison/flex/python then/ <stikonas>anyway, the easies suggestion is to go via older versions... <kpcyrd>(all of them are flagged as autotools pre-processed) <stikonas>well, they are also bison/flex processed <stikonas>e.g. they include both bison-3.8.2/src/scan-gram.l and bison-3.8.2/src/scan-gram.c <stikonas>though might be more readable than autotools... <kpcyrd>the annotation I do is kinda makeshift, hopefully people have a better understanding of "true source code" in a few years and this kind of heuristic annotation won't be necessary anymore <stikonas>well, in live-bootstrap we spend quite a bit figuring out all those pregenerated files... More than anywhere else... <stikonas>though generally upstreams were not receptive... <fossy>yes, people tended to not be particularly interested in the pregenerated files issue, so we've been kind of chugging along doing it by ourselves over here <fossy>perhaps there is more interest nowdays? <fossy>wrt to this specific ruby situation i would personally say that does not suffice, as you're just kinda adding an extra step in the cycle that obscures the cycle <stikonas>ruby 1.8 might be buidlable without ruby <matrix_bridge><cosinusoidally> I've added annother alternative bootstrap path to my tcc_bootstrap_alt project. Alt bootstrap path is hex0 -> hex1 -> hex2 -> M0 -> M2_simple_asm.M1 -> M2_simple_asm.c -> M2_tcc_js_simple.c (less a cut down version of M2) -> tcc_js -> .... -> tcc-0.9.27 . tldr I am able to bootstrap without depending on cc_x86.M1 <matrix_bridge><cosinusoidally> this alt path depends on glibc and bash though <oriansj>cosinusoidally: a binary glibc and bash or a built one? <Googulator>cosinusoidally: what's the point of avoiding cc_x86? <Googulator>Why not hex0 -> hex1 -> hex2 -> M0 -> cc_x86 -> M2-Planet (bootstrap version) -> full M2-Planet -> M2-Mesoplanet -> mescc-tools -> mescc-tools-extra (up to this point, this is just stage0) -> tcc_js -> .... -> tcc-0.9.27? <oriansj>well it does create an alternate path which could be used to detect if something was slipped into stage0's later stages. <oriansj>and I am assuming cosinusoidally is enjoying that work and it could provide some ideas for anyone wanting to go from M2-Mesoplanet to TCC directly (providing another potential path early in the chain)