Bug#513667: Patch for the 0.10-6.1 NMU of cpad-kernel

2010-04-16 Thread Ron 

Hi Christian,

As I already acked you doing this, you're welcome to push it in
directly without going via DELAYED if you like.

I would query why you felt the need to make this depend on dh=7
though?  This package doesn't depend on any debhelper features
later than what it already declared, so this only makes it harder
for people who might want to backport it than it otherwise needs
to be, and for no real gain at all...

Since we're probably going to nuke this one before long, I'm not
overly fussed about it in this case, but as a general rule I'd
consider this an undesirable change for any package of mine that
doesn't need it, and doesn't gain any benefit from it.  Do you
have some reason to think otherwise?

In any case, I suspect this assumption is wrong:
* Bump debhelper compatibility to 7 and move this to debian/compat
  (the rationale previously given in debian/rules doesn't make sense
  for me as there is only one place where this is set).

This package makes a package from itself.  So I suspect you've just
introduced a bug in the generated kernel module package, which won't
have this set in any place, now that you've removed the one place
where it was and the rationale explaining that ;)

I'm sorry if that wasn't as obvious as it could have been from the
package source, but I think that is also why we have the rationale
of only making the minimum of necessary changes in NMU uploads ;P

I do appreciate your help, and that you were only trying to, but
I suspect you've outsmarted yourself on this one and might like to
take another look at whether the package is still functional with
these changes to it.  I have my doubts the generated kernel package
will build correctly with debhelper compat v1 that it would appear
at first blush you've now left it with.

 Ron


On Fri, Apr 16, 2010 at 07:51:02AM +0200, Christian PERRIER wrote:
 
 Dear maintainer of cpad-kernel,
 
 On Tuesday, April 06, 2010 I sent you a notice announcing my intent to upload 
 a
 NMU of your package to fix its pending l10n issues, after an initial
 notice sent on Sunday, April 04, 2010.
 
 You either agreed for this NMU or did not respond to my notices.
 
 I will now upload this NMU to DELAYED/7-DAY.
 
 The NMU patch is attached to this mail.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#513667: Patch for the 0.10-6.1 NMU of cpad-kernel

2010-04-16 Thread Christian PERRIER 
Quoting Ron (r...@debian.org):

 I would query why you felt the need to make this depend on dh=7
 though?  This package doesn't depend on any debhelper features
 later than what it already declared, so this only makes it harder
 for people who might want to backport it than it otherwise needs
 to be, and for no real gain at all...
 
 Since we're probably going to nuke this one before long, I'm not
 overly fussed about it in this case, but as a general rule I'd
 consider this an undesirable change for any package of mine that
 doesn't need it, and doesn't gain any benefit from it.  Do you
 have some reason to think otherwise?

Well, as debhelper 7 is in lenny, I don't think this is a big hassle
to modernize the package a bit.

Of course, as you point, the change is not really needed per se. I
actually still do this in order to guarantee to people in the future
that someone wanting to work on the package *and then* use new
features of debhelper can do it without breaking anything.

This is more or less why the old version of debhelper compatibility
levels are declared obsolete at some point. Actually, cpad-kernel
*was* using level 4, which is considered obsolete as of now. So, the
level should have been bumped to 5 at the minimum...and while I'm at
it, I prefer bringing it to the compatibility level that's in use now.

 In any case, I suspect this assumption is wrong:
 * Bump debhelper compatibility to 7 and move this to debian/compat
   (the rationale previously given in debian/rules doesn't make sense
   for me as there is only one place where this is set).
 
 This package makes a package from itself.  So I suspect you've just
 introduced a bug in the generated kernel module package, which won't
 have this set in any place, now that you've removed the one place
 where it was and the rationale explaining that ;)
 
 I'm sorry if that wasn't as obvious as it could have been from the
 package source, but I think that is also why we have the rationale
 of only making the minimum of necessary changes in NMU uploads ;P

Hmmm, you're right about this, still.



I'll go the conservative way and revert that change...then upload to
DELAYED/6-DAY



signature.asc
Description: Digital signature