event dispatch can hang under some circumstances

Nice catch!

The fix for this is included in the 1.0.13 release.

Release 1.0.13 contains critical fixes that need to be SRU'd into maverick.

Thanks for the patch!

utouch-geis 1.0.13 doesn't currently build on Natty due to linker changes - I've attached the build log (see http://wiki.debian.org/ToolChain/DSOLinking for more information). Can you please update your build system to link against the appropriate libraries?

Also, there should only be a single debian/changelog entry for each time the package was uploaded to Debian or Ubuntu, so please compress the 1.0.12 and 1.0.13 entries into a single entry. That entry should also be targeted to natty instead of UNRELEASED.

I'd also be happy to work with you on an SRU for Maverick, once we've gotten the package up to date in Natty. However, we prefer as a rule to limit patches in SRUs to the minimal patch necessary to fix the bug(s) to minimize the potential for regression. In this case, I think that would be the loop condition change, the -version-info change, and the extern "C" change, but not the error string changes, and probably not the autoconf version number changes, since we'd no longer actually be shipping 1.0.13 (instead this would be a "distro patch" on top of 1.0.11). The "minimal patch" also wouldn't include any linker changes needed to get utouch-geis to build on Natty, since Maverick doesn't have the DSO linking changes.

If that's OK with you, it would be great if you could prepare a debdiff for a version 1.0.11-0ubuntu1.1, targeted at maverick-proposed (see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging for more information about the version number).

I've unsubscribed ubuntu-sponsors for now, but feel free to re-subscribe them once you have a debdiff that's ready for sponsorship.

Packaging for 1.0.11-0ubuntu1.1 is in lp:~utouch-team/utouch-geis/packaging-maverick for maverick-proposed.

Packaging for touch-geis_1.0.13-0ubuntu1 is in lp:~utouch-team/utouch-geis/packaging for natty. Packaging now contains for for FTBFS on natty due to linker changes.

Natty changed looked good, thanks. I've uploaded that. I'll be taking a look at the SRU shortly.

This bug was fixed in the package utouch-geis - 1.0.13-0ubuntu1

---------------
utouch-geis (1.0.13-0ubuntu1) natty; urgency=low

  * New upstream release:
    - Fixes failed make for some dependent projects (LP: #660576).
    - Prevents event dispatch from hanging under some circumstances
      (LP: #656503).
  * Updated to build with toolchain from Natty Narwhal.
 -- <email address hidden> (Stephen M. Webb) Tue, 30 Nov 2010 18:34:46 -0500

Maverick SRU patch looks good as well, so I've sponsored it. It should be evaluated by the SRU team soon. Thanks for revising the patches.

As part of the SRU approval process, the SRU team will want some additional information. In particular, they'll need a discussion of what you feel the regression potential of the patch to be. Could you gather that along with the other things from item 2 on https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and add them to the description of the bug? (I think the IMPACT, DEVELOPMENT, PATCH, and INSTRUCTIONS sections are already covered in the bug's history, but it's easier for the SRU team if it's in one place)

Thanks again

Why does the 0081-event-dispatch-hang-lp656503 patch bump the minor SONAME ABI version? This doesn't add any ABI, just changes the implementation of a function.

+- -version-info 1:1:0 \
++ -version-info 1:2:0 \

It would mean that you can't run programs which got built against the -proposed library with the final library any more. This is an unnecessary change for an SRU (and unnecessary in general, too).

If there was an ABI change the libtool 'current' would need to be bumped. This change just bumps the libtool 'revision', indicating no ABI change. The end result is the .so version goes from libutouch-geis.so.1.0.1 to libutouch-geis.so.1.0.2. Since the NEEDED section of any ELF binary that links to the .so specifies only libutouch-geis.so.1 and the debian package installer runs ldconfig to link the new library to that name, there is no problem running older built apps against the newer library. Or even vice-versa, if you discount the bug being fixed.

The benefit of bumping the revision on a non-API change, and one of the main purposes of .so versioning in the first place, is that it is possible to distinguish between version of the library just by looking at its name. That is, libutouch-geis.so.1.0.1 contains a bug, and libutouch-geis.so.1.0.2 does not. It would be an error to not increment the revision.

What you describe in the first paragraph is bumping the SONAME, which happens on incompatible ABI changes. Compatible ABI changes (i. e. ABI additions mostly) should only need to bump the minor version. But this patch doesn't change ABI at all.

I just saw that the package uses proper .symbols files, so it should still be possible so install the older version of the library with an application that was built against the new one, but it's still a gratuitous change which is both confusing and also unnecessary to fix this bug. You can never be too careful with libraries :-)

BTW, the numbers after the .so are unrelated to the version of the library's source package. The former track ABI changes, the latter track general development.