Hamish Moffatt <[EMAIL PROTECTED]> (14/10/2007): > Thanks for your NMU Cyril. However I think the above is excessive for > a simple FTBFS NMU for an otherwise maintained package.
I'm sorry for that. I'm usually tempted to make the packages I upload
lintian-clean, which is often required, or at least strongly recommended
by the sponsors.
Since last upload happened in 2006, and since the maintainer didn't
answer on an RC bug, I thought that a bit of help would be welcome,
which is the purpose of an NMU.
Again, sorry for being so intrusive, but I didn't encounter any
reticence about my previous patches &| NMU until now (I was given green
light several times), and I'm not that confident about separating the
fixes for only-important-bugs in several patches, and posting them on
individual bugs where there's been no answer for hundreds of days, even
when the patch is already included (I'm not speaking of this bug, or of
this package, or of this maintainer in particular, just a general remark
on the RC bugs I already looked at/worked on).
Shall we open bugs for each and every problem encountered, with
individual patch, and then check them regularly through the QA? Or fix
them all while we're at it, and then be slapped by the maintainer, and
eventually some of them reverted or fixed in a different way? I took the
second road until now, increasing my blame counter from 0 to 1.
> For example the Makefile.{am,in} COPYING change: this is purely
> cosmetic. I disagree that your solution is the best; maintaining
> patches to upstream sources is a nuisance, while fixing things up
> afterwards in debian/rules is easier.
ACK. I must confess I don't even remember why I did that this way…
Cheers,
--
Cyril Brulebois
signature.asc
Description: Digital signature
