--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On 28/09/14 12:49, Jonathan Wiltshire wrote:
> On 2014-09-27 18:49, Robert Edmonds wrote:
>> Robert Edmonds wrote:
>>> Robert Edmonds wrote:
>>> > 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.
>>>
>>> It turns out node-mapnik FTBFS (#759843) due to a problem with
>>> mapnik-vector-tile (#762643) unrelated to the protobuf transition. I've
>>> uploaded a fix for this to DELAYED, so once mapnik-vector-tile
>>> 0.5.1+dfsg-1.3 is in the archive, node-mapnik can be binNMU'd. (And I
>>> think that will complete the transition?)
>>
>> Hi,
>>
>> mapnik-vector-tile 0.5.1+dfsg-1.3 is in unstable and I've confirmed that
>> it fixes #759843, so node-mapnik can be binNMU'd now.
>
> Thanks, scheduled. I also fixed up the found/fixed versions for #759843, or
> various tools will believe it still affects node-mapnik in sid and jessie.
And with that, the old library was removed from testing, so this is finally
over. Closing.
Emilio
--- End Message ---