severity 692327 important thanks On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs <x...@debian.org> wrote:
> Package: libotr, release.debian.org > Severity: serious > User: release.debian....@packages.debian.org > Usertags: transition > > Recently libotr has been updated to version 4.x.x with binary package > name libotr5. > > By the looks of things, it was done because of pidgin-otr package which > now requires libotr5. > It was done because upstream has updated their source and the new libotr is incompatible with the old one. > But this means an un-coordinated transition has started, as there are 6 > other packages that build-depend on libotr2-dev and all of them fail to > build from source against libotr5-dev: > I was not aware a "coordinated transition" was necessary for such a small library. I'm under the impression the release team has bigger fish to fry right now. > * bitlbee > * irssi-plugin-otr > * kdenetwork > * mcabber > * psi-plus > * python-otr > > Please do something to resolve this. Input from release team is highly > welcome. > > Possibilities I can think of are: > * revert libotr source package to 3.2.1-1 & upload libotr5 (4.0.0-2) > source package > No. Upstream will not provide maintenance for 3.x. > * keep libotr source package as it is, upload libotr2 (3.2.1-1) source > package > No. See above. > * provide patches/NMUs to fix FTBFS for above packages when built > against libotr5-dev. > How about letting their upstreams doing their jobs? libotr 3.x is gone, I'm sure they'll wake up eventually. > Usually disruptive uploads like this one, should be co-ordinated with > the release team with a transition bug, and staged in experimental to do > test rebuilds. > I don't see how this is a serious bug. 1) it only affects unstable (which is named so for a reason) 2) libotr5 has been sitting in experimental for quite a while, and upstream devs have been quite vocal about the transition 3) libotr5 can be installed alongside libotr2 kthxbye -- Thibaut VARENE http://hacks.slashdirt.org/
