[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libotr 4.0.0 hasn't entered testing after 55 days



On Sat, 2013-07-06 at 17:14 +0200, Thibaut VARENE wrote:
> On Sat, Jul 6, 2013 at 4:39 PM, Paul Wise <pabs@debian.org> wrote:
>         On Sat, Jul 6, 2013 at 10:31 PM, Thibaut VARENE wrote:
>         
>         > libotr 4.0.0 hasn't entered testing yet and I don't
>         understand why. The
>         > status page reports that it hasn't been built on any arch
>         ("missing 3
>         > binaries"), but those binaries are no longer built by
>         libotr.

They'll stay in unstable until ftp-master remove them. And that
generally won't happen whilst they still have reverse-dependencies.

>         The transition looks like it is blocked by some RC bugs:
>         
>         http://release.debian.org/transitions/html/libotr5.html
>         http://bugs.debian.org/cgi-bin/pkgreport.cgi?sev-inc=serious;sev-inc=grave;sev-inc=critical;src=bitlbee;src=irssi-plugin-otr;src=mcabber;src=pidgin-otr;src=psi-plus
>         
> 
> 
> Still don't get it: why are bugs in packages that depend on libotr
> blocking libotr?

See above. They're keeping libotr2 in the archive, and britney won't
consider libotr for migration while that's the case.

> libotr is perfectly fine and I don't see why it should be blocked from
> moving to testing because some packages that depend on it aren't
> properly maintained? Wnat if these packages are never updated to
> libotr5?

Then they should be removed from testing, and possibly from the archive
altogether.

One of the bugs had an update a week ago, so it seems a little unfair to
claim it's "not properly maintained".

> Are we going to punish those who have updated? This is for instance
> preventing the migration of pidgin-otr and irssi-plugin-otr, and I'm
> receiving (angry) mail about it (which is the reason why I looked into
> this in the first place) ;-P

Then you should tell them to help fix the RC bugs instead. :P

You maintain a library with several reverse dependencies, and uploaded a
package to Debian which changed its SONAME. Part of the implied
responsibility of doing that is to help make sure that the
reverse-dependencies are able to cope with the changes.

I've pinged the bugs against the other packages to query progress.

Regards,

Adam


Reply to: