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

Re: Lost .asc file in archive by not referencing it in an upload (Was: Re: OpenSSL updates)



On 2018-04-09 14:18:37 [+0100], Ian Jackson wrote:
> Sebastian Andrzej Siewior writes ("Lost .asc file in archive by not referencing it in an upload (Was: Re: OpenSSL updates)"):
> > On 2018-03-29 16:09:32 [+0200], Salvatore Bonaccorso wrote:
> > > One was rejected, because:
> > > 
> > > openssl1.0_1.0.2l-2+deb9u3.dsc: Refers to non-existing file 'openssl1.0_1.0.2l.orig.tar.gz.asc'
> > > Perhaps you need to include the file in your upload?
> > 
> > the 9u1 upload did not have the .asc file referenced and so it got lost. What
> > could be done to avoid such mistakes in the future?
> > Would it make sense to let dak reject uploads for uploads of the same upstream
> > version when the .dsc files does not reference the .asc anymore? Or would it
> > better to teach dpkg-source to fail (based on a config switch) if the .asc
> > file is missing.
> 
> Would re-uploading the file have succeeded ?  If so, then using dgit
> to do the upload would have DTRT because dgit checks with the archive
> and always includes in the upload exactly the files which are not
> present in the archive.

I am not 100% sure.
Usually every upload references the .asc file in the .dsc file but only
the first upload (the full-source upload) references the .asc file in
the .changes file (the rules seem to be the same as for the .orig file
from what I can tell).
So I *think* if I would manually fiddle the .asc file into the .changes
file then everything should be okay. If that is the case then dgit would
probably do the right thing. I don't know if DAK allows this - it might
not care.
However, I would like avoid losing the file in the first place :)

> ian.

Sebastian


Reply to: