<doras>stikonas: it wasn't a return code issue after all. A simple equivalent of "rm -rf" in Python was required to get the `tmp` directories removed. <stikonas>my PR is also almost ready, just need to sort out one shellcheck issue <doras>Interesting find about "$?". I wasn't aware of it. <stikonas>actually shellcheck fix messed somethign up... <stikonas>oh, shellchecks suggestion does not work in old bash... <oriansj>today I have learned, try as hard as you like. if you have ~/.emacs; emacs will not let you *not* have .emacs.d ***genr8eofl_ is now known as genr8eofl
<vagrantc>so, it seems implausible for debian to ever realistically officially bootstrap from a full-source bootstrap for established architectures ... but i just realized that new architectures essentially *do* go through a bootstrap cycle and ... it might be plausible to actually attempt a full-source bootstrap for new architectures <vagrantc>riscv64 is not yet an "official" architecture, and would be amazing to pull this off with <vagrantc>muurkha: technically doable, but getting debian to rebuild all the packages of an architecture ... just not going to happen <vagrantc>i mean, would *love* to be proven wrong, but debian tends to move at a glacial pace ... <vagrantc>but ... when a new architecture enters the archive, even when there's a ~90%+ package set already built, it basically gets thrown away and bootstrapped again <muurkha>oh, I would agree with "for debian to officially bootstrap from a tiny binary seed for established architecture this year", but "ever" means not now, not in 02032, not in 02052, not in 02092 <muurkha>I think it's totally realistic to expect it could happen by 02032 <muurkha>if the unbootstrapped packages (those built from a hand-audited binary seed) are binary-identical to the ones they've built now, then there's very little risk to Debian building them that way <muurkha>and if there *is* a binary difference in those whose build is supposedly "reproducible", that's a strong argument that there's a *large benefit* to unbootstrapping <muurkha>Debian rebuilds all the packages of every architecture pretty frequently, and they're working to do it more frequently <vagrantc>unfortunately, some of the key packages such as gcc and binutils aren't reproducible <muurkha>yes, but there's already strong buy-in within Debian for making them reproducible <Hagfish>not enough buy-in to make it a release requirement and delay the next release until all the reproducibility issues are solved, right? <muurkha>similarly if there weren't lots of packagers solving FTBFS bugs to ensure that they could build Firefox or Chromium, building from source wouldn't be a release requirement; the DDs would throw up their hands and stop considering FTBFS a release blocker <muurkha>Debian would fork into a variant that *did* consider FTBFS to be a release requirement, but shipped Palemoon or something as the browser, and a variant that didn't <muurkha>and everyone would use the second one <Hagfish>debian already had to bend the rules for browsers because of their incompatible release/support cycles, right? <Hagfish>that might be another decision that go revisited by such a fork <muurkha>I haven't kept up, but browsers are a major pain point <Hagfish>they are operating systems within themselves (and not well behaved ones like Emacs is) <Hagfish>i really think some benefactor should pay for Electron to be officially packaged by Debian, though <muurkha>Emacs has grown its own package system, and there's always some impedance mismatch where package systems rub together <muurkha>but Debian is doing pretty well at mapping elpa and npm packages into Debian packages these days <Hagfish>i saw someone complaining that the debian version of React was unusably out of date <Hagfish>but the last time i checked, debian barely had any npm packages, so i guess that's progress <muurkha>wouldn't be surprising if the Debian version of React were in fact unusably out of date <Hagfish>i can't remember the statistic about how many packages are needed to create a hello world react app, but if that's possible at all in debian, it's quite the achievement <muurkha>IIRC it was about 900 last I checked <Hagfish>yeah, a quick search suggested 150 MB of node_modules <muurkha>the npm experiment is super interesting <Hagfish>i hope it represents an extreme, and not a target for other ecosystems to try to surpass :) <muurkha>evidently all the research on "software reuse" in the 01980s and 01990s was kind of barking up the wrong tree <Hagfish>cargo at least has people trying to implement Crev (a distributed source review / vouching system) <muurkha>because npm has evidently reduced the granularity of cost-effective software reuse for many projects down to the level of left-pad <unmatched-paren>it's trying to fix a problem that shouldn't exist in the first place <Hagfish>unmatched-paren: i think companies would pay for someone to pick a trusted set of versions of packages (with maybe something like an insurance payout if the packages do contain malware) <Hagfish>it's "just" a question of building the structures and aligning the incentives <unmatched-paren>Hagfish: if they were willing to do that there'd be "open source dependency review!" companies popping up left, right, and centre <Hagfish>unmatched-paren: you're right, though, the blast radius needs to be limited by the packaging tools / runtimes etc. <Hagfish>crev would become a data format and a market place <muurkha>the runtime and language could together limit the blast radius, the packaging tools can't <muurkha>and neither can the runtime on its own <Hagfish>well, the packaging tool should present the package metadata when you try to install it <Hagfish>like "are you sure you meant to install letf-pad, when left-pad is way more popular?" <unmatched-paren>Programming languages should not have package managers in the first place. the way to fix it is to encourage the use of apt, guix, nix, dnf, pacman, ... instead of specialized package managers <muurkha>to some extent when you decide to depend on someone else's advice, you become vulnerable to them, and that's true whether the advice is verbal directions to a bar, a map, or a software library <unmatched-paren>I don't know how high the bar is for adding a package to debian tho...? <Hagfish>sure, but civilisation is based on the fact that not every has to independently check every thing <muurkha>we can work to increase the legibility and analytical tractability of that advice but we can't entirely eliminate the risk <unmatched-paren>Guix and Nix make it quite easy, but traditional distros might be harder <muurkha>at some point I wrote a PAM module that used HTTP basic auth to check your password <Hagfish>muurkha: to some extent that's "all" cryptography does, it turns big problems into tractable problems, e.g. turning data transfer problems into key transfer problems <muurkha>that is, when you tried to log in to X or whatever, it would send your username and password as basic auth to some HTTP URL configured for PAM <muurkha>and depending on whether the response was 401 or 200 it would let you log in <muurkha>this is pretty useless and I doubt anyone ever used it, but someone did package it for debian <muurkha>Hagfish: true. or key revocation problems <mihi>neither are they patched around. I noticed as those are missing from the git repo :) <mihi>fossy, stikonas[m]: Would you accept pull requests to live-bootstrap that split kaem files (mes, tcc, make) into two parts? part#1 unpacks, calls part#2 and checksums; part#2 does the actual build. <mihi>Reason is that I may want to re-use them in https://github.com/schierlm/FullSourceBootstrapFromGit/ - as that project does not start with tarballs, it currently includes modified copies of those kaem files. I may not be able to test the bootstrap completely, just the part until it gets past that point. <oriansj>well crev and the idea of centralized tarball audit and signing, does have some benefits (just wished they had a client that GCC could build) <Hagfish>oriansj: yeah, it would be nice to have a couple of different implementations, which could maybe experiment a little with the user interface or defaults, while maintaining a compatible data format <oriansj>I'd be happy with a minimal command line client that would download/validate existing signatures and create local signatures <oriansj>the rest of the user interface can be added later