[pkg-otr-team] Bug#767230: libotr transition started by mistake :-/

[intrigeri]

Hi,

[It's probably too late already, but if you prefer I can move this
discussion to a dedicated bug filed against release.d.o.]

Here's my analysis of the potential ABI/API breakage in libotr
4.0->4.1, and attached the debdiff (implementing plan A) that I could
upload to sid (and then request to be aged or unblocked so that it
migrates to testing eventually).

Functions added to context.h
============================

otrl_context_find_recent_instance
---------------------------------

ConnContext * otrl_context_find_recent_instance(ConnContext * context,
               otrl_instag_t recent_instag);

This one is not modified at all in context.c

otrl_context_find_recent_secure_instance
----------------------------------------

ConnContext * otrl_context_find_recent_secure_instance(ConnContext * context);

This one is slightly changed in context.c. Ignoring the typo fix in
a comment, the change is:

  -           if (context->msgstate != OTRL_MSGSTATE_PLAINTEXT) return 1;
  +           if (c_iter->msgstate != OTRL_MSGSTATE_PLAINTEXT) return 1;

I doubt this breaks the API or ABI.

Function added to both mem.c and mem.h
======================================

int otrl_mem_differ(const unsigned char *buf1, const unsigned char *buf2,
    size_t len);

My (limited) understanding is that adding a function does not break
the API nor ABI.

readelf
=======

I've diff'ed the output of the following command run on the one hand
on current Jessie (libotr 4.0.0-3) and current sid (libotr 4.1.0-1):

  readelf -Ws /usr/lib/libotr.so.5 | awk '{print $8}' | sort

The result is that two symbols were added in 4.1:

  gcry_mpi_snew at GCRYPT_1.6
  otrl_mem_differ

The full output lines from readelf -Ws, regarding the added or modified
functions, is:

  * 4.0:

    117: 0000000000007a50   123 FUNC    GLOBAL DEFAULT   11 otrl_context_find_recent_instance
    185: 0000000000007b20   292 FUNC    GLOBAL DEFAULT   11 otrl_context_find_recent_secure_instance

  * 4.1:

    118: 0000000000007af0   123 FUNC    GLOBAL DEFAULT   11 otrl_context_find_recent_instance
    181: 000000000000bd50   100 FUNC    GLOBAL DEFAULT   11 otrl_mem_differ
    187: 0000000000007bc0   292 FUNC    GLOBAL DEFAULT   11 otrl_context_find_recent_secure_instance

I lack the background to tell if the differences seen in the 1st (Num)
and 2nd (Value) columns matter. Do they indicate ABI breakage?

symbols
=======

I've extracted the libotr5 binary packages from Jessie and sid, and
then run:

  dpkg-gensymbols -v4.0.0 -plibotr5 -P/tmp/intrigeri/4.0-extracted -Osymbols
  dpkg-gensymbols -v4.1.0 -plibotr5 -P/tmp/intrigeri/4.1-extracted -Osymbols

The second command tells me:

  --- symbols (libotr5_4.1.0_amd64)
  +++ dpkg-gensymbolsjwu_Lf	2014-11-01 17:42:21.409469548 +0100
  @@ -51,6 +51,7 @@
    otrl_instag_read_FILEp at Base 4.0.0
    otrl_instag_write at Base 4.0.0
    otrl_instag_write_FILEp at Base 4.0.0
  + otrl_mem_differ at Base 4.1.0
    otrl_mem_init at Base 4.0.0
    otrl_message_abort_smp at Base 4.0.0
    otrl_message_disconnect at Base 4.0.0

... which seems to confirm the fact that there was no
API/ABI breakage.

Applications built against libotr 4.0 and running with 4.1
==========================================================

  * pidgin-otr 4.0.1-1 rebuilt in a Jessie chroot: works fine on
    current sid

=> seems to confirm that applications built against the old version
still work fine with the new one.

The attached patch
==================

I've gone with the smallest possible change (removing one single
line), and left the warning be printed on stderr, in the hope it may
help debugging issues in case something is wrong with this analysis.
If the RT prefers, I can drop the warning too.

I've successfully tested the resulting libotr5 binary package with:

  * pidgin-otr 4.0.1-1 built in a Jessie chroot (against libotr 4.0)
  * pidgin-otr 4.0.1-1 from sid (that was built against libotr 4.1)

... but I could not directly test the actual intended effect of the
patch (it would require building an _older_ version of libotr with
this patch, building a package against the new version, and running it
with the patched old version). This leads me to think that perhaps
this patch may not be as useful as I used to think.

Conclusion
==========

Unless the differences I've found in readelf output indicate ABI
breakage, it seems equally safe to either:

  * upload with the attached debdiff to sid, wait for it to build on
    all architectures, and then let it migrate to testing;
  * just let libotr migrate to testing as is (my current understanding
    is that it should fix two RC bugs, without introducing any new
    breakage).

So, whatever the release team feels more comfortable with :)

[Regarding the plans for Jessie+1, I've filed #767652 so we (pkg-otr
team) don't forget about it.]

Cheers,
-- 
intrigeri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 767230.debdiff
Type: text/x-diff
Size: 2745 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-otr-team/attachments/20141101/66371d20/attachment-0001.diff>