On 10/09/14 23:09, Robert Edmonds wrote: > 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?
I guess we could do those, better safe than sorry. However since they don't have any dependencies on libproto*, they will probably migrate instantly. I'm not sure that is the intended behaviour either. I have scheduled the first round of binNMUs (all but protobuf-c, node-mapnik, osmium and the 5 packages that don't have the dependencies). Regards, Emilio -- 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/54133e31.1060...@debian.org
