On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote: > If you don't have the time to make a new build once every year, you > shouldn't be a packager, full stop. I think that's a fair point, but not at all the issue here. I specifically want not to rebuild this, which is why I *have* rebuilt all the other packages I own that were earlier on this and similar lists. [skipping ahead just a little...] > We are talking about crypto-related packages here; being able to > rebuild them and be confident in their contents is arguably more > important than any other kind of package. I see your point in general, though I don't agree in this case. The build is reproducible from source with the earlier gnu-efi-devel, we know exactly what's in it, and (as you know) if there are any serious issues like a CVE for the OpenSSL build involved which would effect it, I don't think there's going to be difficulty remaining aware. There's no reason not to be confident regarding the contents. That said, the current build issue in this case is my fault, and fairly trivial, all said and done. I specifically want not to rebuild it - I very strongly prefer to wait until we're done with the upstream release and use that instead. There are a couple of reasons for that, and they overlap significantly with why this shouldn't be part of the mass rebuilds: - We literally get nothing out of rebuilding it unless something goes wrong. Nothing. Aside from some datestamps and the like that are in this version, you should get the exact same binary. (The next version will actually be fully debian-style reproducible, but that's assuming the same compiler, etc.) - If they're not the same, even if it is merely timestamps in headers differing, then just rebuilding the two "unsigned" packages without going through the process to get the third package signed makes our reproducibility worse, not better. - Because there aren't enough people participating in the broader ecosystem (i.e. reviewing other distro's builds to make sure they haven't messed it up or created a back door, accidentally or on purpose), getting it signed has the effect of adding hard deadlines for quite a bit of ancillary work that will require scheduling and time. - The worst-case support burden is *extraordinarily* high, in dollars, and more builds of the same source tree makes it higher in surprisingly large increments. I can go into detail if you like, but I think you and many others have heard me explain it several times before. - I'm doing most of the upstream work, and doing the rebuilds, getting them signed, and all the work that comes along with that all take time away from actually getting the next version out the door, thus making us farther from the actual desired outcome, rather than closer. Doing an almost-exactly-the-same rebuild is not merely pointless, it is actively harmful. > >> Well the FTB from people pushing builds would be directly due to the > >> fact they're not on the ACL for the secure-boot, there is a handful > >> of packages like that. > > > > So the people who has the rights should start actually doing it, > > shouldn't they. This particular maintainer ignores all bugzilla > > e-mail. > > If I'm reading the policy correctly, the reason it's being considered > for retirement is that the bug was ASSIGNED. If it were still in NEW, > it would be merely orphaned. Three mutually painful policies being applied as a method of *not* listening to a maintainer is not my idea of a good time. It's pretty much the opposite of motivating. -- Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
