Hi, On Sat, Aug 17, 2019 at 10:37:43AM +0200, Salvatore Bonaccorso wrote: > Hi Ansgar, > > On Wed, Jun 19, 2019 at 08:39:50AM +0200, Salvatore Bonaccorso wrote: > > 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 > > > 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. > > > > Thank you I think that would be a good compromise. Source-only uploads > > remain possible for security uploads, and ftp-masters and security > > team members do not need to roundtrip reuploading binary builds > > (download, rename, resign ... reupload) and instead uploads which > > contain a buildinfo file rejected giving the uploader a explanation > > why, and the possiblity to just reupload a "proper" source only one. > > We had a couple of occasions still where we needed to do fetch the > builds, rename, resign and reupload the packages. > > Any chance to enable the above check again? That would solve most of > or issues and people which did upload a source only upload but > containing a ${arch}.buildinfo would get their uploads rejected.
We still have recurring this issue, where people continue to upload _sources.changes (even more frequently now I would say, given the workflow for unstable/testing) but which include a _amd64.buildinfo. The last one was the (not yet released) unbound update. So if we can have this check enabled again for the security archive this would help us a lot not having to workaround those rejected uploads :) Thanks for all your work! Regards, Salvatore