Bug#760343: transition: protobuf 2.6.0
Control: tags -1 confirmed
On 03/09/14 05:27, Robert Edmonds wrote:
> 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!
My only concern here is that we hit problems like on the previous transitions,
this close to the freeze. But ia64 and sparc are no longer release architectures
and you tested both on amd64 and s390x, and the last time you did a good job in
fixing the regressions, so I'm confident you'll do the same now if any problem
arises (hopefully not). So go ahead and let me know when we're ready for the
binNMUs.
Emilio
Reply to: