FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 11-22-2009, 05:31 PM
"Nikita V. Youshchenko"
 
Default NMU question

Hi

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.

Please advice

Nikita
 
Old 11-22-2009, 05:47 PM
Luk Claes
 
Default NMU question

Nikita V. Youshchenko wrote:
> Hi

Hi

> 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?

No, something elso should be done.

> Triggering binary-only NMUs on every architecture somehow?

Right [1].

Cheers

Luk

[1] http://wiki.debian.org/binNMU


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-23-2009, 10:40 AM
Charles Plessy
 
Default NMU question

Le Sun, Nov 22, 2009 at 09:31:59PM +0300, Nikita V. Youshchenko a écrit :
>
> 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.

> 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.

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,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-23-2009, 11:03 AM
"Nikita V. Youshchenko"
 
Default NMU question

> 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.
 

Thread Tools




All times are GMT. The time now is 04:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org