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

Re: Bug#934928: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.



Le mercredi, 21 août 2019, 10.44:51 h CEST Adam D. Barratt a écrit :
> Control: tags -1 -moreinfo +confirmed
> 
> On 2019-08-21 09:14, Didier 'OdyX' Raboud wrote:
> > Le mardi, 20 août 2019, 16.55:47 h CEST Adam D. Barratt a écrit :
> >> Control: tags -1 + moreinfo
> >> 
> >> [Recipients changed to use the p-u bug rather than the win32-loader
> >> one]
> 
> >> On 2019-08-16 07:55, Didier 'OdyX' Raboud wrote:
> [...]
> 
> >> > +win32-loader (0.9.3+deb10u1) buster; urgency=medium
> >> > +
> >> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> >> > +    (Closes: #933829)
> >> > +
> >> > + -- Didier Raboud <odyx@debian.org>  Fri, 16 Aug 2019 08:53:00 +0200
> >> > +
> >> > 
> >> >  win32-loader (0.9.3) unstable; urgency=medium
> >> >  
> >> >    [ Thomas Gaugler ]
> >> 
> >> This wants to be against 0.9.4, which is the version in buster. It
> >> will
> >> also want an unblock-udeb for the 0.9.5 upload in unstable, so that
> >> reaches testing before the point release.
> > 
> > Ah, indeed; thanks for the check.
> > 
> > +win32-loader (0.9.4+deb10u1) buster; urgency=medium
> > +
> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> > +    (Closes: #933829)
> > +
> > + -- Didier Raboud <odyx@debian.org>  Fri, 16 Aug 2019 08:53:00 +0200
> 
> Better. :-) Please go ahead.

Uploaded.

> > As for the unblock-udeb; do you need another bug, or were you asking
> > debian-
> > boot@ for approval?
> 
> My understanding was that it's blocked at your request rather than
> -boot's, to ensure that it doesn't get out of sync with the files in
> tools/ on mirrors. I can happily add the unblock-udeb, but we'll need to
> make sure that ftp-master also do the relevant magic on their side. (If
> that's still manual intervention.)

(Thanks for the unblock :-) )

As far as I'm concerned, it can stay unblocked outside of the freeze. I don't 
care _enough_ for the testing win32-loader.exe to be in sync to warrant always 
needing to unblocking this package manually.

Where would it make sense to document that the win32-loader /tools/ 
counterpart needs to be copied from unstable to testing at freeze time and for 
each subsequent upload only, but that we're fine with having it out-of-sync 
outside of the freeze?

Cheers,
    OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: