Hi Ansgar,
On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
[...]
> > Sure, I understand that things works like that, I'm just showing a few
> > design points that could potentially be done differently.
>
> We could also just not accept .buildinfo uploads when they don't contain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 2019-06-18 at 21:20 +0200, Mattia Rizzolo wrote:
> 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 s
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 a
Mattia Rizzolo writes:
> On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
>> The .buildinfo files are referred to in the .changes files; renaming
>> them would require updating the .changes file. The .changes files are
>> used to upload the security updates to ftp-master.
>
> With
On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
> The .buildinfo files are referred to in the .changes files; renaming
> them would require updating the .changes file. The .changes files are
> used to upload the security updates to ftp-master.
With .changes being ephemeral, it f
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote:
> > This behaviour is really causing issues for the security-archive so in
> > one way or the other there needs to be a solution. Regularly we need
> > to fetch the buildd changes and build binary packages, resign them and
> > reupload the
