Re: Requests for sponsors to upload NMUs
On 2008-03-04, Neil Williams [EMAIL PROTECTED] wrote: Are sponsors going to start recommending changing SONAMEs in an NMU next? Adding -dbg packages? Of course not, NMUs are different to typical RFS activity. of course is changing SONAMEs in a NMU appropriate if it is appropriate. Having a sponsored upload that is lintian clean is AGoodThing(tm) for an ordinary RFS where the maintainer is the one requesting sponsoring. All those niceties simply do not apply to an NMU - lintian errors are to be preserved in all their ugliness unless specifically part of an existing bug report in the BTS *or* relevant to the fix for the RC bug. (And a mere lintian error/warning is not a good reason to file a new bug either, that's why lintian exists.) yeah. let us not improve the package quality in debian. Sponsors, can we please stick to the rules for NMUs so that those who seek advice here can get clear guidance on what is required? Sponsors, keep up your good work. If the changes are big, please consider DELAYED/something though. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On Wed, 2008-03-05 at 10:57 +, Sune Vuorela wrote: On 2008-03-04, Neil Williams [EMAIL PROTECTED] wrote: Are sponsors going to start recommending changing SONAMEs in an NMU next? Adding -dbg packages? Of course not, NMUs are different to typical RFS activity. of course is changing SONAMEs in a NMU appropriate if it is appropriate. That equates to a hostile hijacking. If the package is orphaned or if the maintainer is MIA and the package can be orphaned beforehand, fine (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is *not* acceptable in an NMU without permission from the maintainer. It is an especially bad idea when doing NMU's as part of a release bug squashing party because of the transition that follows. Unnecessary transitions must be avoided prior to a release. Adding a patch system is also not acceptable in an NMU. Neither is converting from dpkg to debhelper or CDBS or any other build system, even if, in your opinion, it would help the package overall. Having a sponsored upload that is lintian clean is AGoodThing(tm) for an ordinary RFS where the maintainer is the one requesting sponsoring. All those niceties simply do not apply to an NMU - lintian errors are to be preserved in all their ugliness unless specifically part of an existing bug report in the BTS *or* relevant to the fix for the RC bug. (And a mere lintian error/warning is not a good reason to file a new bug either, that's why lintian exists.) yeah. let us not improve the package quality in debian. If you are not the maintainer, those changes must be done either in coordination with the maintainer or via the MIA process. There are protocols for making such changes - NMU is *not* one of them. Sponsors, can we please stick to the rules for NMUs so that those who seek advice here can get clear guidance on what is required? Sponsors, keep up your good work. If the changes are big, please consider DELAYED/something though. That's worse! There is a day NMU bug squashing party in effect so there is no point uploading to the delayed queue. Just don't make hostile or intrusive changes in an NMU. Stick to the NMU rules. An NMU is not a normal upload. Everyone doing NMU's *must* work with the current maintainer *or* the MIA process. Do not delay RC fixes by adding unnecessary cleanup changes. Do not delay RC fixes by implementing a patch system if the package does not use one. Do not delay RC fixes just to remove a few lintian errors or warnings. Keep the NMU clean and make sure the entire patch is in the BTS before seeking a sponsor or making the upload. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Requests for sponsors to upload NMUs
On Wed, 2008-03-05 at 12:37 +, Sune Vuorela wrote: On 2008-03-05, Neil Williams [EMAIL PROTECTED] wrote: of course is changing SONAMEs in a NMU appropriate if it is appropriate. That equates to a hostile hijacking. If the package is orphaned or if No it don't. it is just bugfixing. If it requires binary incompatible changes to fix it, of course the SONAME should be changed as well. Else you introduce new bugs. Such intrusive fixes should not be done without at least trying to contact the maintainer. Debian has set rules for how packages may or may not be modified by people other than the maintainer and it does not matter if you see it as just bug fixing - you need to follow the NMU rules and that means not making intrusive changes. That path leads to chaos. If this is to fix an RC bug, then yes, a SONAME might need changing but this should not be done without consensus or without very good cause. At the very least, contact debian-release for advice before changing a SONAME in an NMU close to a release freeze. Do *not* change a SONAME in an NMU merely on a lintian warning/error. The Lenny release is in six months - it doesn't help anyone to make an unnecessary SONAME bump at this time. That causes more bugs, not less. the maintainer is MIA and the package can be orphaned beforehand, fine (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is *not* acceptable in an NMU without permission from the maintainer. It is an especially bad idea when doing NMU's as part of a release bug You seem to be living in perfect-world where maintainers are always reachable. Or just busy. Every NMU must give the maintainer a chance to fix the problem themselves. The zero-day BSP only applies if the RC bug has already been open for more than 7 days, specifically to allow time for the maintainer to fix the problem themselves. NMUs should not be rushed or overly intrusive and should not include changes that are more than just bugfixing. MIA-process orphaning is too slow for bugfixing. This isn't about anything else than bugfixing. Not true. These are not your own packages, these are packages under the care of someone else. Until you know that the maintainer is MIA, you MUST allow time for the maintainer to supply a fix. The RC BSP states 7 days for this time, absolute minimum. Before that time, yes, feel free to comment on the bug report, add info, suggest a patch etc. but an NMU should not be done, even under zero day BSP release party rules, until the maintainer has had some time to view the problem. Other changes should use the existing NMU rules because, by definition, a non-RC NMU is not urgent. If all the requests for sponsors for NMUs here had been exclusively about bug fixing and nothing else, I wouldn't be spending time on this thread. I worry that too many requests for sponsors for NMUs here were about everything *except* bug fixing and that sponsors were asking for NMUs to make changes that were completely stylistic or solely to shut up lintian. That is not the purpose of an NMU. By all means lets keep NMUs for bug fixing - I like that idea, that is what people expect from an NMU. Sponsors, keep up your good work. If the changes are big, please consider DELAYED/something though. That's worse! There is a day NMU bug squashing party in effect so there is no point uploading to the delayed queue. Just don't make hostile or intrusive changes in an NMU. Stick to the NMU rules. fix bugs. Don't make debian the distribution where bugfixing other packages is forbidden. We need better packages. don't stop people working for this. With delayed/7, you still have 7 days to react. That is not how the BSP works. The RC bug must be open for 7 days, then if the maintainer has not been able to fix it, a zero day NMU can be done - not before. Who knows the package best - you or the regular maintainer? Yes, fix known bugs but don't delay the RC bugs just to fix less important ones. That's perverse. In those 7 days, help the maintainer, offer ideas but don't go trampling over packages until the maintainer has had a chance to fix the issue themselves. If nothing happens after 7 days, don't delay any further, go for a zero day NMU to close the RC bug. If some other bugs can be fixed too, that's fine but don't go after non-bugs like lintian errors. An NMU is not a normal upload. Everyone doing NMU's *must* work with the current maintainer *or* the MIA process. If the current maintainer is busy with real life, that is not possible. MIA-process takes long time. It doesn't take long to check MIA status once the process has completed (as was the case for the original package that started this). Yes, the full MIA process can take a long time but the maintainer must still be given a chance. You cannot assume that the maintainer is MIA from day zero and start making QA-type changes. Equally, once a maintainer is known to be MIA, take the opportunity to get
Re: Requests for sponsors to upload NMUs
On 2008-03-05, Neil Williams [EMAIL PROTECTED] wrote: Yes, fix known bugs but don't delay the RC bugs just to fix less important ones. That's perverse. Do two uploads ;) - one to now and one to delayed. All I'm saying here is that sponsors should not expect NMUs to fix the full range of issues that would normally be essential to fix for an upload to NEW or for an upload of a package already maintained by the person requesting sponsorship. I of course agree on this. But I also think that if someone does this extra things, he should not be asked to undo them before making the NMU. When I am NMU'ing something filled with crack and awfulness, I have a hard time not fixing these as well, especially if it is easy fixable. lintian errors and warnings are explicitly *off-topic* for an NMU, unless directly related to the RC bug. No. changing -make clean to [ ! -f Makefile ] || make clean for example would in my opinion be fully acceptable. (This is not stylistic changes, but nice bugfixes) Can we agree that these tasks should *not* be done in an NMU *unless* directly related to the RC bug? : (or after communication with maintainer) 1. SONAME changes merely to shut up lintian - i.e. where the RC bug has no need to change the SONAME. Yeah. 2. removing commented out lines in debian/rules Yeah. 3. Implementing dpatch or quilt for a package that does not use it yeah. 4. tidying up manpages depends. 5. Changing the build system to/from CDBS/dpkg/dbs/foo yeah. 6. other lintian errors or warnings depends lintian errors and comments in debian/rules are *not* bugs. I'm not against fixing bugs that have been properly filed in the BTS and which Lintian errors are often bugs. There is a big difference between bug-fixing and QA. NMUs are for fixing bugs, not stylistic changes within packages or keeping up with lintian. keeping up with lintian - hah. /Sune - this time it was 462001 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
Hi, On Wed, Mar 05, 2008 at 01:34:39PM +, Neil Williams wrote: On Wed, 2008-03-05 at 12:37 +, Sune Vuorela wrote: On 2008-03-05, Neil Williams [EMAIL PROTECTED] wrote: of course is changing SONAMEs in a NMU appropriate if it is appropriate. That equates to a hostile hijacking. If the package is orphaned or if No it don't. it is just bugfixing. If it requires binary incompatible changes to fix it, of course the SONAME should be changed as well. Else you introduce new bugs. Such intrusive fixes should not be done without at least trying to contact the maintainer. Of course. I didn't understand it otherwise. However, if contacting fails, and the SONAME upgrade is needed to fix a bug, then it may be acceptable to do this in an NMU. Since it's a big change, it would be good to make all delays in the process a bit longer than required, but in the end it may still be acceptable to do a SONAME bump in an NMU. If this is to fix an RC bug, then yes, a SONAME might need changing but this should not be done without consensus or without very good cause. Of course. A SONAME change is very intrusive, and it is clear that it must not be done lightly. At the very least, contact debian-release for advice before changing a SONAME in an NMU close to a release freeze. That sounds like a very good idea. Do *not* change a SONAME in an NMU merely on a lintian warning/error. Does a SONAME change ever fix (or hide) a lintian bug? Ah well, as far as I can see we all agree that this is not something to do in an NMU. You seem to be living in perfect-world where maintainers are always reachable. Or just busy. Every NMU must give the maintainer a chance to fix the problem themselves. The zero-day BSP only applies if the RC bug has already been open for more than 7 days, specifically to allow time for the maintainer to fix the problem themselves. Sune mentioned uploading to DELAYED/7. Doing that will give the maintainer 7 days, not only to come up with his own solution, but also to see whether the proposed (at that moment) NMU is acceptable. Of course it is possible to post the patch to the BTS, wait, and after 7 days do a non-DELAYED NMU upload. The DELAYED queue just automates that process. NMUs should not be rushed or overly intrusive and should not include changes that are more than just bugfixing. I agree. In particular, they should not even fix real bugs which aren't in the BTS yet. But when using the DELAYED queue, this is very simple: report the bug, and upload the fix. If nothing more happens, then 7 days later your NMU will automatically be done. If something does happen, the upload can easily be cancelled (by the maintainer or the NMUer), if that turns out to be desirable. In other words, I'm saying that uploading to a DELAYED queue is just a polite means to provide a patch and allow the maintainer to accept it without any action. The maintainer can also reject it without any extra action, by uploading a better solution before the delay is up. And with minimal extra effort, it can even be rejected without uploading a better solution, although of course that leaves the bug open and thus isn't so nice. :-) MIA-process orphaning is too slow for bugfixing. This isn't about anything else than bugfixing. Not true. These are not your own packages, these are packages under the care of someone else. Until you know that the maintainer is MIA, you MUST allow time for the maintainer to supply a fix. The RC BSP states 7 days for this time, absolute minimum. Before that time, yes, feel free to comment on the bug report, add info, suggest a patch etc. but an NMU should not be done, even under zero day BSP release party rules, until the maintainer has had some time to view the problem. Right. But uploading to a DELAYED queue doesn't count as doing an NMU. Instead it counts as notifying the maintainer, plus a public anouncement and automation of doing an NMU if nothing else changes. I worry that too many requests for sponsors for NMUs here were about everything *except* bug fixing and that sponsors were asking for NMUs to make changes that were completely stylistic or solely to shut up lintian. That is not the purpose of an NMU. I haven't followed the requests, so I wouldn't know, but I agree with you that installing lintian overrides is certainly outside the scope of an NMU. fixing lintian warnings in general may be within the scope, but only if the lintian warning is not a false positive, and if the bug is already in the BTS. Also, for sponsored NMUs I think there is no need for a DELAYED upload, because as a non-DD I think it is reasonable to just post your patch to the BTS and wait 7 days before requesting an NMU sponsor. By all means lets keep NMUs for bug fixing - I like that idea, that is what people expect from an NMU. Indeed. I think we agree on that. :-) Sponsors, keep up your good work. If the changes are big, please
Re: Requests for sponsors to upload NMUs
Sune Vuorela wrote: ...snip... the maintainer is MIA and the package can be orphaned beforehand, fine (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is *not* acceptable in an NMU without permission from the maintainer. It is an especially bad idea when doing NMU's as part of a release bug You seem to be living in perfect-world where maintainers are always reachable. Or perhaps he had an experience similar to mine where the maintainer was available but no attempt was made to contact. MIA-process orphaning is too slow for bugfixing. This isn't about anything else than bugfixing. So, in this case you claim it is only about bugfixing. While you may want to look at it in that light, I am sure there are others who see it differently. Going back to a thread I previously (http://lists.debian.org/debian-mentors/2007/10/msg00229.html) participated in, I will again emphasize the need for communication. If the maintainer is truly MIA, that is a bigger issue than any single bug. Others have made this argument that we should focus on a bug to justify a NMU (even when it goes against established practice or breaks the rules). We may not live in a perfect-world, but we should strive to improve our processes to handle these situations. It does not help if individual DDs promote their pet theories to those who agree with them. Richard P.S. In case it is not obvious, I am not directing my comments to any specific individual or incident. I explicitly reject this narrow bug fix only mindset. I want to promote and improve the entire Debian system where communication is critical. While a NMU is easy to focus on (and acceptable as our documentation shows ;-), we still need to look at the overall consequences and effects. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On 2008-03-05, Richard Hecker [EMAIL PROTECTED] wrote: If the maintainer is truly MIA, that is a bigger issue than any single bug. Others have made this argument that we should Yes. but luckily, we can do both at the same time (fixing bugs and figuring out wether a maintainer is MIA) And a annoying often run into normal bug can be more annoying than a cornercase rc bug. /Sune - this time #467604 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Requests for sponsors to upload NMUs
I've been busy with other things elsewhere but some recent uploads from mentors are confusing me and potentially giving the wrong impression to those whom we mentor and sponsor, IMHO. http://lists.debian.org/debian-devel-announce/2008/03/msg2.html I hope to see you all there fixing bugs and want to remind you that there is still a 0-day NMU (Non-Maintainer Upload) policy active: RC (Release Critical) bugs and Release Goal bugs that are at least 7 days old without maintainer reaction can be NMUed without delay. Please do test your patches, only fix bugs that are already filed to the BTS (Bug Tracking System) when you NMU, send your NMU patch to the BTS and be nice to the maintainer of the package you NMU. Note: only fix bugs that are already filed to the BTS The rest of the normal NMU rules still apply: http://www.uk.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu e.g. On Sun, 2008-03-02 at 12:34 -0500, Kevin Coyner wrote: On Sun, Mar 02, 2008 at 12:46:15AM -0500, Barry deFreese wrote.. Here is another one of my fairly intrusive NMUs. It fixes RC bug: #466143 as well as standards and lintian cleanup. http://mentors.debian.net/debian/pool/main/r/rcalc/rcalc_0.5.0-1.3.dsc Description: graphical symbolic calculator Barry Looks good except for two things: 1. Lots of unneeded whitespace in debian/copyright. Could be removed and also removal of comment-out lines in debian/rules. 2. Perhaps it would be better to have all of the source code changes done through dpatch or quilt. I know this is an NMU and being unobtrusive is important, but there are quite a few upstream source code changes which I think would be better off in a patch system. I'd be willing to upload once these are addressed. So why are we doing this now? This is an NMU - minimal changes scenario. Barry is not the maintainer for this NMU, why are the rules being ignored on mentors? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Requests for sponsors to upload NMUs
2. Perhaps it would be better to have all of the source code changes done through dpatch or quilt. I know this is an NMU and being unobtrusive is important, but there are quite a few upstream source code changes which I think would be better off in a patch system. So why are we doing this now? This is an NMU - minimal changes scenario. Barry is not the maintainer for this NMU, why are the rules being ignored on mentors? (Specifically, do not change the build system in an NMU. With the recent controversy about not having patch systems at all, about new format source packages and storing everything in the .diff.gz, I'm surprised that this is even being considered for an NMU, let alone stipulated as a requirement for upload.) Are sponsors going to start recommending changing SONAMEs in an NMU next? Adding -dbg packages? Of course not, NMUs are different to typical RFS activity. Having a sponsored upload that is lintian clean is AGoodThing(tm) for an ordinary RFS where the maintainer is the one requesting sponsoring. All those niceties simply do not apply to an NMU - lintian errors are to be preserved in all their ugliness unless specifically part of an existing bug report in the BTS *or* relevant to the fix for the RC bug. (And a mere lintian error/warning is not a good reason to file a new bug either, that's why lintian exists.) Sponsors, can we please stick to the rules for NMUs so that those who seek advice here can get clear guidance on what is required? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Requests for sponsors to upload NMUs
On 04/03/2008, Neil Williams wrote: So why are we doing this now? This is an NMU - minimal changes scenario. Well, maybe the world isn't *that* black and white. Remember, NMUs are a way to help people fix their bugs, get their packages back into shape, etc. IANADD, etc., but I already got a few NMUs sponsored, and beside a single (IIRC) maintainer, I've never been insulted because I was doing some unrelated changes, fixing some glitches. (And a mere lintian error/warning is not a good reason to file a new bug either, that's why lintian exists.) (Ask jfs about that: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=464264) Sponsors, can we please stick to the rules for NMUs so that those who seek advice here can get clear guidance on what is required? For the record, last MU for the considered package was back in 2005. Which might explain why Barry introduced above-the-usual-NMU-level changes. Cheers, -- Cyril Brulebois pgpb43OgxtRFp.pgp Description: PGP signature
Re: Requests for sponsors to upload NMUs
Cyril Brulebois wrote: On 04/03/2008, Neil Williams wrote: So why are we doing this now? This is an NMU - minimal changes scenario. Well, maybe the world isn't *that* black and white. Remember, NMUs are a way to help people fix their bugs, get their packages back into shape, etc. IANADD, etc., but I already got a few NMUs sponsored, and beside a single (IIRC) maintainer, I've never been insulted because I was doing some unrelated changes, fixing some glitches. (And a mere lintian error/warning is not a good reason to file a new bug either, that's why lintian exists.) (Ask jfs about that: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=464264) Sponsors, can we please stick to the rules for NMUs so that those who seek advice here can get clear guidance on what is required? For the record, last MU for the considered package was back in 2005. Which might explain why Barry introduced above-the-usual-NMU-level changes. Cheers, I agree with William, I need to watch my Ps and Qs. However, in this case voc is MIA. So ideally I suppose what I should do is orphan the package and make it a QA upload. Sorry and thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On Tue, 04 Mar 2008, Neil Williams wrote: Note: only fix bugs that are already filed to the BTS The rest of the normal NMU rules still apply: The following quote invites other fixes as well! On Sun, 02 Mar 2008, Marc 'HE' Brockschmidt wrote: (http://lists.debian.org/debian-devel-announce/2008/03/msg1.html) Please note that in a BSP, you shouldn't just NMU every RC bug you see. While you are working on a package, check for other low-hanging fruits (like translation updates, typos that can easily be fixed, ...) and fix them in your NMU. So it would seem like *some* additional cleanup *is* permissible while NMU'ing. But HE also said: On the other hand, if you notice that a package looks unmaintained, refrain from fixing the bugs for now and try to find out if the package should be removed or adopted by another maintainer instead. There is no best answer to packages which seem un-maintained to some while the maintainer appears to feel that they are in good shape. Here is a possible order with some time-lag between these (except between 0 and 1!) 0. File bugs. 1. Put bug fixes in the BTS tagged patch. 2. Make a NMU which fixes *only* BTS bugs. 3. Offer to co-maintain the package (copy to MIA). 3alt. Suggest removal of the package. 4. Offer to adopt the package (copy to MIA). Above all be polite both in words and deed! Regards, Kapil. -- signature.asc Description: Digital signature
Re: Requests for sponsors to upload NMUs
On Tue, 2008-03-04 at 23:37 +, Neil Williams wrote: http://mentors.debian.net/debian/pool/main/r/rcalc/rcalc_0.5.0-1.3.dsc http://packages.qa.debian.org/r/rcalc/news/20080303T143226Z.html This NMU seems to introduce more changes than allowed via NMU. So I agree with Neil Williams on his call to debian-mentors to follow the NMU rules. Regards, Bart Martens signature.asc Description: This is a digitally signed message part
Re: Requests for sponsors to upload NMUs
On Tue, 2008-03-04 at 21:31 -0500, Barry deFreese wrote: I agree with William, I'm glad that you agree with Neil Williams. I need to watch my Ps and Qs. However, in this case voc is MIA. I don't think that Sam is MIA. So ideally I suppose what I should do is orphan the package and make it a QA upload. No, I don't think so. Depending on your time and interest, I would suggest to limit the changes in the NMU to only changes that are allowed in an NMU, or to talk to the maintainer to agree on some other approach. Regards, Bart Martens signature.asc Description: This is a digitally signed message part
Re: Requests for sponsors to upload NMUs
On Wed, Mar 5, 2008 at 2:52 PM, Bart Martens [EMAIL PROTECTED] wrote: On Tue, 2008-03-04 at 23:37 +, Neil Williams wrote: http://mentors.debian.net/debian/pool/main/r/rcalc/rcalc_0.5.0-1.3.dsc http://packages.qa.debian.org/r/rcalc/news/20080303T143226Z.html This NMU seems to introduce more changes than allowed via NMU. So I agree with Neil Williams on his call to debian-mentors to follow the NMU rules. That NMU was approved by the maintainer IIRC. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On Wed, 2008-03-05 at 14:57 +0900, Paul Wise wrote: On Wed, Mar 5, 2008 at 2:52 PM, Bart Martens [EMAIL PROTECTED] wrote: On Tue, 2008-03-04 at 23:37 +, Neil Williams wrote: http://mentors.debian.net/debian/pool/main/r/rcalc/rcalc_0.5.0-1.3.dsc http://packages.qa.debian.org/r/rcalc/news/20080303T143226Z.html This NMU seems to introduce more changes than allowed via NMU. So I agree with Neil Williams on his call to debian-mentors to follow the NMU rules. That NMU was approved by the maintainer IIRC. In that case I would suggest to mention this in debian/changelog: * Non-maintainer upload with permission from the maintainer. Regards, Bart Martens signature.asc Description: This is a digitally signed message part
