<pabs3>muurkha: thats not actually true about Debian, the ftp-masters require the proper source and require that it be possible to build from source using only binaries in main (but not that it be actually built from source during the build). of course this rule isn't checked for compliance at all <vagrantc>pabs3: i suspect muurkha was talking about things like configure shipped alongside the configure.ac or configure.in or similar ... <pabs3>yeah, we rebuild all those automatically these days <pabs3>I guess only packages with old debhelper compat levels, or overrides disabling it? <vagrantc>there may be other similar-ish files as well ... <pabs3>there is also linux-firmware in main that isn't rebuilt from source of course :( <pabs3>might not even be buildable these days as the build-deps get removed <stikonas>pabs3: Debian rarely rebuids pregenerated files <stikonas>my guess is that bison files are not rebuilt <vagrantc>if we had a list of things that would be worth regenerating, we could nudge debian to start actually regenerating more files <vagrantc>i know debian moves slowly ... all the more reason to start on things soon :) <stikonas>yeah, I think bison/fles files are usually just taken as is <stikonas>I just checked bison source package and even that one does not attempt to rebuild its parser <stikonas>that said, many other distros don't even do as much as Debian does... <stikonas>well, I mean Debian does rebuild more than average. A positive example is that perl's configure.sh script is rebuilt (that one is not autotools) <vagrantc>i think debian ships it's own configure.sh ... or some wrappeer ... "recently" worked on reproducibility issues in debian's perl packages <stikonas>yes, I think fossy reused that work in live-bootstrap <pabs3>stikonas: I think if you find any issues of generated files being used without rebuilding, please do file bugs about them if you can be bothered :) <pabs3>(and really those bugs/fixes should go upstream, so all distros rebuild from source) <stikonas>well, the thing is that upstream git is often fine. It's only releases that have them <stikonas>that's one of the reasons why fossy is considering to swithing live-bootstrap to building from git snapshots... <pabs3>(they left but) I would say that pre-generated files should be removed from even the upstream release tarballs. also the upstream VCS often has pre-generated files, some of them even refuse to delete autocruft when sent patches :( <Hagfish>yeah, that sounds like upstream are doing some weird things <Hagfish>the autogen stuff is not in the repo, but is in the release tarballs? <Hagfish>so their process for releasing their "source" involves generating new code using a script? <pabs3>once case where the generated files are in the VCS is e2fsprogs <oriansj>lanodan: yeah, we haven't had anyone interested in doing that work yet but we should probably document it in a way others know about the problem and things that might be of use to solve it. <oriansj>stikonas: your changes have been reviewed and merged <theruran>oriansj: looks like wiki.bootstrapping.world is not responding <theruran>GH has a wiki option. I don't think you need to make pull requests to contribute to it, but an account is most likely required <theruran>agree that PRs are not as desirable for this use case <muurkha>pabs3: there's a constant stream of "FTBFS" bugs that package maintainers struggle to fix, and if they fail to do so the package is eventually removed from Debian <muurkha>pabs3: or did you mean it wasn't true in the opposite direction? <muurkha>pabs3: by "human-readable pregenerated files" I meant things like how it's okay by Debian lights to bootstrap bison with bison rather than only building it from non-bison parts <pabs3>FTBFS bugs are about build failures, not about not rebuilding generated files from source. FTBFS bugs are usually just due to library interface churn <muurkha>what I meant is that Debian takes failing to build from source seriously <pabs3>agreed on that, the part I disagree with is the second part <muurkha>I think there are still autogenerated configure scripts that get treated as "source" sometimes <muurkha>although as vagrantc pointed out they do try to avoid it, it isn't a fire alarm like an FTBFS bug <pabs3>please file bugs if you see those, that is definitely not the norm. the defaults in debhelper include rebuilding those from source <muurkha>stikonas pointed out bison indeed takes the upstream's pregenerated bison parser <oriansj>theruran: it should be responding correctly now <oriansj>pabs3: it has been bootstrapped thanks to gio <muurkha>yeah, and thanks to a lot of other people who laid the groundwork <pabs3>how does it work without using the pregenerated parser? <muurkha>but until I think last year the answer was "no, bison can only be bootstrapped, you can't build it from source" <muurkha>("bootstrapped" in the sense of "built with itself") <oriansj>theruran: odd, it loads up just fine via tor and there isn't much network traffic <oriansj>and it is connected to a 100MB pipe and the firewall rules allow all IPs on port 80 and 443 <stikonas[m]>pabs: we rebuild pregenerated file from bison file before build, it happens in a few stages. First stage uses heirloom yacc and builds simplified parser <stikonas[m]>pabs3 but heirloom yacc and lex can be used for bootstrapping flex which is also used for rebuilding some bison files <oriansj>in short, all bootstrapping problems can be solved by people who care enough to solve them. ***stikonas_ is now known as stikonas
<stikonas>mostly the same stuff as for hex0, though perhaps not as aggressive <stikonas>i.e. we still use all the same global variables <stikonas>(I did not move any of them to registers) ***WaxCPU is now known as Andrew
***Andrew is now known as WaxCPU