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

Re: Bug#776928: unblock: debian-installer-netboot-images/20150107



Hi all,

Le dimanche, 8 février 2015, 21.54:04 Cyril Brulebois a écrit :
> Niels Thykier <niels@thykier.net> (2015-02-06):
> > A debhelper compat is an explicit no-go per the freeze policy.
> > 
> > Otherwise, looks good to me.
> 
> It's a bit unfortunate that d-i-n-i is huge and not too useful to
> upload during the release cycle in that we get to only notice this
> kind of things ("woops, we bumped the debhelper version compat in
> that package too but it never reached testing") during the freeze;
> sorry about that.
> 
> Since d-i-n-i is basically about collecting files in packages (see
> get-images.sh), and about shipping them through various binaries, this
> kind of things is /possibly/ harmless, but I really didn't check
> anything. It would probably be helpful to double check that dh 7 and
> dh 9 lead to identical binaries, and maybe think about letting this
> change slide with the rest (but so far I really have no opinion on
> this).

So I've gone and done that (twice), the result of all debdiffs is exactl 
identical:

> File lists identical (after any substitutions)
> 
> No differences were encountered between the control files

This show that the change (but also that the revert) is harmless. 
Frankly, I'd find the "explicit no-go therefore imposing a revert" quite 
silly in this specific case.

> In case the explicit no-go stays (which I'd consider fair, to be
> honest), I'd rather avoid doing nasty things with the release version
> numbering (see Holger's reply), and get the revert through an upload
> matching RC 2. Which means getting d-i-n-i even later in testing but
> that would probably be safer.

That's technically correct. I'd find it quite sad to postpone a 
migration to testing for d-i-n-i, especially as every d-i upload [or at 
the very least, the final d-i] will impose a d-i-n-i upload and 
migration, again.

> On a slightly different note: Why we're still using a non-debian.org
> mirror (MIRROR in debian/rules) is still beyond me.

Using http.debian.net accelerates my builds by a big margin. I don't 
care enough though, so feel free to commit a change.

Cheers,
OdyX


Reply to: