Emilio Pozuelo Monfort wrote:
> 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
Thank you very much! I will upload protobuf 2.6.0-3 to unstable soon.
It's true that we did see some annoying regressions in the last protobuf
transition, but that was largely due to me trying to hack around
upstream's lack of explicit support for some of our architectures (they
had per-architecture assembly implementations with no generic fallback),
which has been corrected in the latest release. I'm also happy to
report that upstream has fixed all of our portability issues in the most
recent release and I was able to retire all of the Debian-specific
portability patches. So I'm hopeful this transition will be a bit
smoother than the last one.
By the way, I notice on the transition tracker web page:
https://release.debian.org/transitions/html/auto-protobuf.html
that the "affected" Ben expression is:
.depends ~
/libprotobuf\-lite9|libprotobuf9|libprotoc9|libprotobuf\-lite8|libprotobuf8|libprotoc8/
I think this excludes packages whose source packages have a
Build-Dependency on protobuf-compiler, but whose binary packages *don't*
have a corresponding dependency on one of protobuf's library packages.
Can you clarify whether those packages should be binNMU'd as well, or
should the transition be limited strictly to the ABI transition of
protobuf's library packages? Looking at the difference between the
auto-protobuf transition tracking page and the list of packages I
generated with my Ben expression:
> > is_affected = .depends ~ /libprotobuf8|libprotobuf-lite8|libprotoc8/ |
> > .depends ~ /libprotobuf9|libprotobuf-lite9|libprotoc9/ | .build-depends ~
> > /protobuf-compiler/;
The additionally affected packages seem to be:
chromium-browser
closure-compiler
mapnik-vector-tile
meson
python-shogun
At least in the case of mapnik-vector-tile (which ships the output of
running the protobuf compiler), which I examined more closely than the
others, I am inclined to think that any package that runs the protobuf
compiler during its build should be binNMU'd, otherwise FTBFS issues
could go unnoticed until a new upload or a QA rebuild. But maybe this
is too aggressive. Any advice?
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910210935.ga25...@mycre.ws
