On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote: > > Also here, it feels to me that once something is accepted into a policy > > queue, dak should already consider it something controlled by itself, > > store checksums in the database and be done, not keep the .changes > > around as a "source of truth" for additional processing, imho. > > Throwing away .changes doesn't help with .buildinfo name conflicts.
It helps in the sense that once the .changes is thrown away, dak would
be free to rename the .buildinfo however it likes.
> We could also just not accept .buildinfo uploads when they don't contain
> useful information about published binaries, that is for source-only
> uploads.
>
> Maybe I should reenable the check for this at least on security-master?
> It was rejecting uploads that are okay for unstable/experimental so I
> disabled it again the last time.
That would indeed be a fine workaround for me, and reduce the load the
security team is experience, since it's the team which is the most
affect by this.
(Incidentally, it also is the same way launchpad works, there you can't
upload a .buildinfo for an arch that you aren't uploading, and humans
can't upload binaries, so you can't upload .buildinfo for binaries at
all).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
