IRC channel logs
2024-04-11.log
back to list of logs
<Googulator>"As an upstream maintainer, I have chosen (...) to give *tarballs* to my users, not git repositories." - This seems to be a core misunderstanding/disagreement between upstream maintainers and distributions. <Googulator>Distributors aren't *users,*, they're, well, distributors. <sam_>I tried to push back a bit <sam_>not sure if I will reply more there <matrix_bridge><Andrius Štikonas> Googulator: Might as well just provide tested binaries to users and don't rebuild them as that invalidates release testing... <Googulator>IMO the fundamental issue is that there are more people interacting with one's maintained software than just users and developers <Googulator>the needs of a distributor or integrator are quite different from those of either users or developers <Googulator>and then you have auditors, etc. each with their own workflows <Googulator>for a user, it's entirely fine to just download a release tarball, run the included pregen build script, and be done with it (heck, most users are fine with just downloading prebuilt binaries, if available) <Googulator>a "plain old" developer will just work with the Git repo, make changes, submit them, and not care about the build system being sane beyond "works for me" - getting that change into a release tarball is the job of the maintainers anyway <Googulator>but a distributor/integrator isn't just contributing back, but also distributing their own version, for which they have to take responsibility - and you can't reasonably do that unless you can trust the sources you work with, as well as that what you put out is indeed properly derived from the source <Googulator>and that requires either that the release tarballs be derived from the repository in a reproducible and provably correct way, or that the repository is directly usable for distribution, bypassing the user-facing tarball <Googulator>and an auditor, of course, needs access to both the Source of Truth (the repository) and any "convenience outputs" (source tarballs, binaries, HTML documentation, etc.) derived from it, in a way that permits meaningful comparison <sam_>that's a great point Googulator (wrt distributing our own, responsibility, etc) <Googulator>there's even established precedent that a redistributor is responsible for supplying the corresponding source code, and can't pass that responsibility on to upstream <Googulator>and if that's true for supplying source, it's not far-fetched to think that a redistributor is also responsible for the correctness & security of distributed code <Googulator>In the case of the tarballs in question, I would even argue that the tarball is a distinct source distribution from the upstream Git, and so any non-source included needs source code distributed alongside it, in such a way that the non-source be reproducibly regenerated from it <stikonas>Googulator: indeed, very nice points. You should reply to that thread <Googulator>maybe we need to propose a new tool to autotools, named "autopwn", to automatically inject a backdoor, and a corresponding "-p / --pwn" option to autoreconf :) <sam_>please do consider replying with these <sam_>i think they might be persuasive <Googulator>I do like the idea of providing "-src" tarballs, although the naming is IMO not ideal <Googulator>"-user" vs "-reference" (or "-redist") might be better <Googulator>another gem from the same mail: "(or, well, GNU has chosen for me, even before I was present) to give *tarballs* to my users, not git repositories" <Googulator>...that "choice" was made before git was invented <Googulator>indeed, quite a few GNU tarballs used in live-bootstrap predate the use of any form of real version control by GNU <Googulator>only snapshot commits (snapshots of what?) until March 2021, then finally real commits, but all tagged as exclusively authored by Chet Ramey, the maintainer - I somehow doubt that even that is a proper development history <Googulator>and the release branches are literally just the release tarball contents committed, even for recent releases, with no connection to the devel branch <stikonas>yeah, and even if "choice was made", it doesn't mean that things should be set in stone <Googulator>such behavior should probably trigger more scrutiny these days after the XZ incident <stikonas>Googulator: I guess the way it works there is patches are mailed, then "patch -p1" and git commit <stikonas>in svn there wasn't this much distinction between committer and author <sam_>bash still does this, yes <Googulator>and it's not a simple "patch -p1", the actual commit contents are also slightly different <sam_>people have to retire at some point <sam_>it is way easier to inherit something with vcs.. <Googulator>given that it predates even the simplify refactor <stikonas>half of the remaining items are documentation anyway <Googulator>"Provide more detailed instructions on how to prepare and run the project, most notably without rootfs.py" - is this still a goal? <Googulator>with the recent refactors, if anything, dependency on Python has increased significantly <Googulator>but basically the big sticking point is "mes 0.26.1 (unreleased)" <Googulator>also OpenSSL 3.0 - marked "optional", but 1.1.1 has reached its EOL <stikonas>Googulator: well, instructions could still be written on how to do it without python <stikonas>and yes, mes 0.26 is very slow, so we are waiting for that <Googulator>which, as I understand, needs an as-of-yet-unpublished patch on top of 0.26 <Googulator>if it was just about slowness, 0.25 would be fine <Googulator>looking at the current documentation we currently have for Pythonless build, there is one major issue: "Only copy distfiles listed in steps/pre-network-sources into this disk." <Googulator>pre-network-sources is of course gone, the file list is instead directly derived from the manifest & sources files using Python code that's unreasonable to replicate by hand <Googulator>Is there any update on that one? Last I heard was that there exists privately a version of / patch for Mes that solves it, but it's not even published, let alone included in a real Mes release <Googulator>it would be great to at least get that patch published