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

Bug#760343: transition: protobuf 2.6.0



Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Hi,

Sorry for submitting this bug so shortly before the upcoming cutoff on
new transitions, but I'd like to update protobuf to 2.6.0 for jessie,
which was just released last week.  This version has an ABI SONAME bump
in its libraries due to the usual C++ reasons, but API compatibility is
quite good, and I expect only one or two packages will need fixes.
Upstream has recently become active again, and this is the first new
release in ~1.5 years.

There are quite a few bug fixes in this release.  In fact, I was able to
retire most of the patches we've added in Debian for issues that have
since been fixed upstream.  But the biggest update is that the fast,
optional C++-backed implementation in the Python bindings has been
overhauled.  The C++ implementation for python-protobuf was previously
enabled for the wheezy release but was disabled recently due to bugs,
and I'd like to avoid regressing to the slow, pure Python only version
for jessie.  (It also might be possible to finally get Python 3 support
for protobuf before the release, though this will require fixes in some
other packages first.)

I've built and tested protobuf 2.6.0-1 on amd64 and s390x.  It's
currently uploaded to experimental, waiting in NEW, due to the SONAME
changes.

Here is the Ben file for the transition:

title = "protobuf";
is_affected = .depends ~ /libprotobuf8|libprotobuf-lite8|libprotoc8/ | .depends ~ /libprotobuf9|libprotobuf-lite9|libprotoc9/ | .build-depends ~ /protobuf-compiler/;
is_good = .depends ~ /libprotobuf9|libprotobuf-lite9|libprotoc9/;
is_bad = .depends ~ /libprotobuf8|libprotobuf-lite8|libprotoc8/;

Here is the list of affected packages (30):

    anfo
    bitcoin
    chromium-browser
    clementine
    closure-compiler
    cubemap
    drizzle
    imposm
    imposm-parser
    libphonenumber
    mapnik-vector-tile
    meson
    mixxx
    monav
    mosh
    mozc
    mumble
    node-mapnik
    ola
    osmium
    osmpbf
    ostinato
    php-pinba
    pinba-engine-mysql
    pink-pony
    pokerth
    protobuf-c
    python-shogun
    shogun
    zbackup

I've attempted re-builds for 29 out of these 30 packages
(chromium-browser is an 0.8 GB source package, do not want) in a clean
sid pbuilder environment containing protobuf 2.6.0-1.  24 of those 29
successfully built with no sourceful changes.  The build logs are
available here:

    https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/

The 5 packages that failed to build were:

node-mapnik
-----------

    This package Build-Depends against mapnik-vector-tile, which ships a
    .pb.h file in /usr/include (a bad upstream practice).
    mapnik-vector-tile needs to be binNMU'd first before node-mapnik can
    be binNMU'd.

    Actually, the mapnik-vector-tile package even ships a .cc file in
    /usr/include.  WTF.

    It would be better if mapnik-vector-tile shipped a .proto file in
    /usr/share rather than installing the .pb.h output of running
    protobuf-compiler against that file into /usr/include.  That would
    insulate against incompatible changes in protobuf-compiler.

    (https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/node-mapnik_1.2.3-1_amd64.build)

osmium
------

    Same problem as node-mapnik.  The libosmpbf-dev (src:osmpbf) package
    ships .pb.h files in /usr/include, so osmpbf needs to be rebuilt
    first.

    It would be better if osmpbf libosmpbf-dev shipped .proto files
    instead of .pb.h files.  (Actually, now that I look at it, the
    libosmpbf-dev package *only* ships a static library containing
    compiled .pb.c files and the corresponding .pb.h files.)

    (https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/osmium_0.0~20111213-g7f3500a-3.1_amd64.build)

pinba-engine-mysql
------------------

    FTBFS due to unrelated bug #759837.  It would probably otherwise
    build successfully, since it ships its own .proto file and runs
    protoc during the build.  (Though, weirdly, at configure time rather
    than via a Makefile rule.)

    (https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/pinba-engine-mysql_1.0.0-4_amd64.build)

pokerth
-------

    FTBFS due to unrelated bug #759851.  It would probably otherwise
    build successfully, since it ships its own .proto files and runs
    protoc during the build.

    (https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/pokerth_1.1.1-2_amd64.build)

protobuf-c
----------

    FTBFS due to upstream bug #163
    (https://github.com/protobuf-c/protobuf-c/issues/163).  The fix for
    this is relatively trivial and since I am upstream I plan to release
    a new version adding protobuf 2.6.0 compatibility very shortly.

    (https://people.debian.org/~edmonds/build-logs/protobuf_2.6.0-1/protobuf-c_1.0.1-1_amd64.build)

So, my expectation is that two rounds of binNMUs (everything but
node-mapnik and osmium, then those two packages), plus a new sourceful
upload of protobuf-c, would be sufficient to accomplish the transition.
(Besides the two packages that already FTBFS for unrelated reasons.)

Thanks for considering my request!

-- 
Robert Edmonds
edmonds@debian.org


Reply to: