opal is missing a b-d on ptlib, which is not in oneiric

[Matthias Klose]

opal is missing a b-d on ptlib, which is not in oneiric but only in experimental, not letting opal build. an update of ptlib seems to be out of question, so please could you revert the sync by using a fake version number?

[Iain Lane (laney)]

Was there an FFe for this sync?

[Colin Watson (cjwatson)]

The sync happened long before feature freeze (2011-05-02).

Are we sure that it's better to go back rather than forward here? I'm unsure as to how much else may want the new opal.

[Colin Watson (cjwatson)]

On second thoughts, ptlib 2.10.1~dfsg-1 appears to be incompatible with the version of opal in Oneiric (missing GetSessionVars somewhere or other), and ptlib 2.8.4-1ubuntu1 fails to build with a hideous C++ backtrace, which appears to correspond with some kind of corrupted allocation arena but valgrind doesn't reveal anything interesting either:

root@sarantium:/tmp/buildd/ptlib-2.8.4# LD_LIBRARY_PATH=/tmp/buildd/ptlib-2.8.4/lib gdb samples/hello_world/obj*/hello
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /tmp/buildd/ptlib-2.8.4/samples/hello_world/obj_linux_x86/hello...done.
(gdb) r
Starting program: /tmp/buildd/ptlib-2.8.4/samples/hello_world/obj_linux_x86/hello
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
__gnu_cxx::__detail::_Bitmap_counter<__gnu_cxx::bitmap_allocator<PContainerReference>::_Alloc_block*>::_M_reset (this=0x522b5c, __index=0) at /usr/include/c++/4.6/ext/bitmap_allocator.h:430
430 _M_curr_bmap = reinterpret_cast<size_t*>
(gdb) bt
#0 __gnu_cxx::__detail::_Bitmap_counter<__gnu_cxx::bitmap_allocator<PContainerReference>::_Alloc_block*>::_M_reset (this=0x522b5c, __index=0) at /usr/include/c++/4.6/ext/bitmap_allocator.h:430
#1 0x004456a3 in __gnu_cxx::bitmap_allocator<PContainerReference>::_M_allocate_single_object (this=0x522b40) at /usr/include/c++/4.6/ext/bitmap_allocator.h:883
#2 0x0043af2d in allocate (__n=1, this=0x522b40) at /usr/include/c++/4.6/ext/bitmap_allocator.h:1020
#3 PContainerReference::operator new () at ptlib/common/contain.cxx:55
#4 0x0043b521 in PContainer::PContainer (this=0x51edbc, initialSize=1) at ptlib/common/contain.cxx:67
#5 0x0043b8a2 in PAbstractArray::PAbstractArray (this=0x51edbc, elementSizeInBytes=1, initialSize=1) at ptlib/common/contain.cxx:165
#6 0x0043e4e2 in PBaseArray (this=0x51edbc, initialSize=1) at /tmp/buildd/ptlib-2.8.4/include/ptlib/array.h:284
#7 PCharArray (initialSize=1, this=0x51edbc) at /tmp/buildd/ptlib-2.8.4/include/ptlib/array.h:564
#8 PString::PString (this=0x51edbc) at /tmp/buildd/ptlib-2.8.4/include/ptlib/contain.inl:57
#9 0x00247500 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ptclib/psasl.cxx:179
#10 _GLOBAL__sub_I_psasl.cxx(void) () at ptclib/psasl.cxx:343
#11 0x0011e81b in ?? () from /lib/ld-linux.so.2
#12 0x0011e904 in ?? () from /lib/ld-linux.so.2
#13 0x0011111f in ?? () from /lib/ld-linux.so.2
Backtrace stopped: Not enough registers or memory available to unwind further

So, um. If Seb is happy rolling back opal I certainly wouldn't object.

[Colin Watson (cjwatson)]

Some discussion on #ubuntu-release from a while back:

<cjwatson> tumbleweed: hm, you're the last uploader of ptlib; AFAICS in order to get opal building, we need to bump ptlib to a new upstream version (e.g. merge from Debian experimental)
<tumbleweed> cjwatson: sure I can do that
<tumbleweed> cjwatson: the merge is trivial (configure option), but isn't enough to get opal building
<tumbleweed> opal-3.8.4~dfsg/src/opal/ivr.cxx:191:40: error: 'class OpalVXMLSession' has no member named 'GetSessionVars'
<tumbleweed> and the new opal requires a new spandsp, I don't know how far down this rabbit hole I want to go :)
<tumbleweed> aha, with the new spandsp, opal 3.10.1 builds a little further, and hits a libav api change

[Sebastien Bacher (seb128)]

not sure now why opal got sycned, it was a while back during the start of the cycle merges, we probably just followed GNOME there, seems the easiest would be to update the experimental versions of ptlib and ekiga as well, that stack have limited rdepends and updating them should not be ok

[Sebastien Bacher (seb128)]

subscribing the release team to get a ffe approval to update ptlib and ekiga, ptlib has opal, ekiga and t38modem in its rdepends, t38modem has been dropped from debian testing for a while and seems unmaintained so it basically just impacts on ekiga, the experimental version seem to be what other distributions are shipping as well

[Colin Watson (cjwatson)]

The attached patch fixes up opal 3.10.1~dfsg-1 to build against current libav.

[Colin Watson (cjwatson)]

Which implies that opal needs to go from 3.8.4 to 3.10.1 as well, unless somebody can figure out how to get ptlib 3.8.4 to build and thinks it's worth keeping the stack at 3.8. It looks as though ptlib and opal need to broadly match.

Can we have a summary of the upstream feature changes in 3.8+3.10?

[Sebastien Bacher (seb128)]

it's not easy to summarize the changes, the opal tarballs have no changelog or NEWS file and the diff between those versions is not really trivial.

Updating the ekiga stack will only impact on ekiga mainly which is not really actively maintained in Ubuntu nor bug free in its current version it doesn't really seem to be something that should be high on considerations list for oneiric

[Martin Pitt (pitti)]

FWIW, this is a can of worms:

 * Current ekiga package in oneiric just shows me the network warning dialog, and then hangs without showing anything, so it's unusable right now.

 * Current oneiric ekiga does not build against the 2.10.1/3.10.1 ptlib/opal stack from experimental

 * Current upstream ekiga version 3.3.2 needs ptlib 2.10.2 and opal 3.10.2. I am currently packaging these, port their patches, etc., and check if ekiga 3.3.2 is building and working.

[Martin Pitt (pitti)]

I finally have working packages now:

 * spandsp built unmodified from Debian sid
 * ptlib from experimental, updated to 2.10.2
 * opal from experimental, updated to 3.10.2, with Colin's patch added and ported to 3.10.2
 * ekiga 3.3.2

This brings up the main window, still remembers all my previous calls and contact lists from the last time I used ekiga (which must have been around lucid or so, when I started using empathy and telepathy-sofiasip). I can make SIP calls just fine.

I haven't tested video calls.

So, these obviously didn't get a lot of testing, but would fix the NBS/FTBFS problems, and the current Ekiga version in oneiric doesn't work for me at all; does it for any one else?

ptlib's only rdepends are opal and ekiga, opal's only rdepends is ekiga.

I removed t38modem, as it's quite unmaintained, FTBFS, and also depends on NBS libraries. There is a new upstream version 2.0, which might work with the current libraries. I'm really not interested in packaging it (nor am I really interested ekiga, but *shrug*), as these days there are plenty of well working and free/paid online fax services which really are a lot easier to use than a fax modem emulator.

Since I spent some 2.5 hours on the stack, I am obviously biased now, but I'd like to propose to upload the lot.

If other release team members disagree, my second preference is to remove ptlib, opal, and ekiga from Ubuntu, as it seems that nobody really cares about them.

[Martin Pitt (pitti)]

Oh, forgot: spandsp has two rdepends in universe: asterisk and yate. The new version doesn't break API/ABI, but still these two ought to be tested with the new spandsp version.

[Colin Watson (cjwatson)]

I'm inclined to say go ahead with this at this point. Despite the problems, it seems a lot more likely to work well than trying to bodge together something that works out of the existing versions in the archive.

[Stefano Rivera (stefanor)]

We all seem to be in agreement that we should go ahead (but find out from an Asterisk user if it breaks asterisk). I think the alternatives are much worse.

FFe granted.

[Martin Pitt (pitti)]

I synced spandsp, as it is a prerequisite for the other packages.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ptlib - 2.10.2~dfsg-0ubuntu1

---------------
ptlib (2.10.2~dfsg-0ubuntu1) oneiric; urgency=low

  * Merge with Debian experimental. (LP: #836915) Remaining Ubuntu changes:
    - debian/rules: Configure with --enable-exceptions, to avoid
      -fno-exceptions leaking into pkg-config.
  * New upstream bug fix release
  * Drop pluginmgr.patch, dlclose_fix.patch: Included upstream.
  * debian/rules: Disable failing and rather dubious "compiled static" test,
    as this makes no actual effort of checking the binary. (The binary is
    really compiled dynamically)

ptlib (2.10.1~dfsg-1) experimental; urgency=low

  * New upstream release: 2.10.1 (Luyten)
    Closes: #622012, #598986
  * Re-Add myself to Uploaders
  * Bump debhelper compat to 8
  * Fix debian/watch to allow double digit minor versions
  * Drop Changelog-ptlib from docs as upstream doesn't ship it
  * Bump Standards-Version to 3.9.2 - no changes required
  * Update VCS browser field to anonscm.d.o
  * Repack as DFSG to remove upstream's windows binaries
  * Fix debian/watch to add ~dfsg version mangle
  * Remove unused ${shlibs:Depends} from libpt-dev, libpt-dbg and libpt-doc
  * Re-Add more complete clean target and debian/clean for dh_clean to wipe
    out leftover files
  * Replace jquery.js with Debian's version to make lintian happy
  * Add symbols file for libpt2.10.1 (but don't fail builds while we're in
    experimental)
  * Add pkg-kde-tools to take advantage of pkgkde-symbolshelper which is
    better suited for C++ libs - thanks to Modestas Vainius!
    (this makes c++ symbol files somewhat less painful. But still different
    g++ versions emit a bit different symbol sets so ftbfs'es happen)
  * Register API documentation with doc-base
  * Add dlclose fixes from upstream to unloading plugins without ld.so issuing
    an error

ptlib (2.8.4-1) experimental; urgency=low

  * New upstream release
  * NEW package libpt2.8.4 - soname bump

ptlib (2.8.3-1) experimental; urgency=low

  * New upstream release
  * NEW package libpt2.8.3 - soname bump
  * Add Build-Depends: libpulse-dev - Pulse audio support
  * dh_installchangelogs ChangeLog-ptlib-*.txt

ptlib (2.8.2-1) experimental; urgency=low

  * New upstream release
    - NEW packages libpt[2.8.2,-dbg] - soname bump
  * Standards Version 3.9.1 - no changes
  * source/format -> 3.0 (quilt)

ptlib (2.8.1-1) experimental; urgency=low

  * New upstream release
    - NEW packages libpt2.8.1[-dbg] - soname bump
  * Sync from branches/ptlib-2.6
 -- Martin Pitt <email address hidden> Sat, 10 Sep 2011 09:12:12 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package opal - 3.10.2~dfsg-0ubuntu1

---------------
opal (3.10.2~dfsg-0ubuntu1) oneiric; urgency=low

  [ Colin Watson ]
  * Update to 3.10 version to fix FTBFS/NBS. (LP: #836915)
  * Port to libav 0.7 API.

  [ Martin Pitt ]
  * New upstream bug fix release, required by Ekiga 3.3.2.
  * Drop spandsp_autoconf_cppflags.patch, applied upstream.
  * libav_0.7.patch: Port to new upstream version.

opal (3.10.1~dfsg-1) experimental; urgency=low

  * New upstream release: 3.10.1 (Luythen)
  * Put myself back into Uploaders
  * Bump debhelper compat to 8
  * Fix debian/watch to allow double digit minor version
  * Bump PTLib depends to 2.10 version (Luythen) as well
  * Bump Debian source version to 3.0
  * Enable samples to be built with --enable-samples instead of explicitly
    building them in debian/rules
  * Add libspandsp-dev (>= 0.0.6~pre17) to Build-Deps to allow T.38 to use it
  * Add debian/clean for all files that need to be purged before rebuild
  * Add debian/patches/plugins_clean_target.patch: Most of the plugins don't
    have a clean target and thus don't allow rebuilds
  * Update debian/rules to cope with latest samples compilation changes
    upstream
  * Remove Changelog from docs as upstream doesn't ship it
  * Replace jquery.js with Debian's libjs-jquery version to make lintian happy
  * Add symbols file for libopal3.10.1 (but don't fail builds while we're in
    experimental)
  * Add pkg-kde-tools to take advantage of pkgkde-symbolshelper which is
    better suited for C++ libs - thanks to Modestas Vainius!
    (this makes c++ symbol files somewhat less painful. But still different
    g++ versions emit a bit different symbol sets so ftbfs'es happen)
  * Add libavcodec-dev to enable H.263
  * Register API documentation with doc-base
  * Patch spandsp_autoconf_cppflags backported from upstream trunk
  * Adjust DFSG-repack: Remove *.dll and *.exe from upstream source
  * Fix Vcs-Browser URL
  * Bump Standards-Version to 3.9.2
 -- Martin Pitt <email address hidden> Sat, 10 Sep 2011 09:36:25 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package ekiga - 3.3.2-0ubuntu1

---------------
ekiga (3.3.2-0ubuntu1) oneiric; urgency=low

  * debian/watch: Look for bz2 tarballs, and unstable versions.
  * New upstream release. (LP: #836915)
  * Drop libnotify0.7.patch, included upstream.
  * Disable ubuntu_lpi.patch, needs porting, and this is not a supported main
    package any more.
  * debian/control.in: Update build dependencies according to configure.ac:
    - Drop libsigc++-2.0-dev
    - Add libboost-signals-dev, libglib2.0-dev, libgdu-dev, libexpat1-dev
    - Bump libgtk2.0-dev, libopal-dev, libpt-dev
 -- Martin Pitt <email address hidden> Sun, 11 Sep 2011 12:51:59 +0200