Re: List of long term FTBFS packages to be retired in February

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 06, 2020 at 05:41:53PM -0500, Peter Jones wrote:
> 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.)
...snip...

This is not exactly true, since we switched rpm binary payload to zstd,
we get... a miniscule amount of time less building images as it unpacks?
:)

In any case, perhaps we should just do what we do with many of our
policies: Just have an exception process and record those packages that
should be excepted?

kevin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux