> Dear Nikita, > > it is difficult to judge since you did not give the package name. > Nevertheless, the combination of RC bug left unfixed and signs of > obsolescence (package-uses-deprecated-debhelper-compat-version) suggests > that the maintainer might be MIA. If nobody wants to maintain this > package, it should better be orphaned or removed than NMUed. If the > maintainer is active, it is of course with him and not this list that > the contents of the NMU have to be discussed. If he gives you green > light, there is of course no problem fixing no-RC issues. > > Have a nice day, Package in question was ibm-3270 [source], maintainer is Bastian Blank, bug is 553481. I did not put that info into my above mail because my question was actually about procedure, so I did not want to go into discussing this particular bug or package or maintainer. IMO procedure on NMUing is not documented clear enogh in Developer Reference. At least I got confused, although I'm in debian already for years. Nikita > > I've just met an uninstallable package with 3-week-old RC bug, caused > > by soname change of one of dependences. This bug could be fixed by a > > simple rebuild - I've checked if package builds against today's sid - > > yes it does. > > > > I've never done an NMU before, but this looks like a case to try :) > > > > However, reading developer reference about NMUs, I got confused by > > normal vs binary-only uploads for this case. > > > > Is it ok just to add something like > > > > * Non-Maintainer Upload > > * Rebuild against newer libicu (Closes: XXX) > > > > to deban/changelog, build with pbuilder, upload with dput --delayed 2, > > and drop a mail to maintainer? > > > > Or something else should be done? > > Triggering binary-only NMUs on every architecture somehow? > > Build-depending on newer libicu-dev [I guess no since package perfectly > > builds against older libicu-dev]? > > Something else? > > > > Also, is it ok to NMU keeping existing lintian warnings (such as > > package-uses-deprecated-debhelper-compat-version, > > out-of-date-standards-version, patch-system-but-no-source-readme)? > > I don't intend to (co)maintain this package in future, it is just a > > single-time interest.
Attachment:
signature.asc
Description: This is a digitally signed message part.