Bug#901015: transition: protobuf
On 10/24/18 3:54 PM, Mattia Rizzolo wrote: > If "a rebuild is required to make them compatible", you should add > Breaks against those versions, as it maeans the new protobuf is not > compatible to them and coinstallation should be prevented. > That would also hint britney to trigger autopkgtest with both the new > rebuilt rdep and the new protobuf, and migrate them in lockstep. > This was suggested earlier but rejected by protobuf maintainer. "1) Can libprotobuf10 and libprotobuf17 installed together and independent packages working correctly with these libraries? Yes, these are possible. I don't see the need to break the old libprotobuf10 package. 2) Packages that depend on each other, need to be compiled with the same ProtoBuf version. This should be expressed in those package dependencies." https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910964#29 Though the suggestion by protobuf maintainer was not acceptable to ignition-msgs maintainer https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900429#36 signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Wed, Oct 24, 2018 at 03:47:47PM +0530, Pirate Praveen wrote: > I think these regressions should not add a delay to testing migration as > autopkgtests are passing in unstable and a rebuild is required to make > them compatible with new protobuf version. > > autopkgtest for gazebo/9.0.0+dfsg5-4.2: amd64: Regression ♻ > autopkgtest for ignition-msgs/1.0.0+dfsg1-5: amd64: Regression ♻ > autopkgtest for ignition-transport/4.0.0+dfsg-4: amd64: Regression ♻ > autopkgtest for ola/0.10.7.nojsmin-1: amd64: Regression ♻ > Required age increased by 18 days because of autopkgtest If "a rebuild is required to make them compatible", you should add Breaks against those versions, as it maeans the new protobuf is not compatible to them and coinstallation should be prevented. That would also hint britney to trigger autopkgtest with both the new rebuilt rdep and the new protobuf, and migrate them in lockstep. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#901015: transition: protobuf
Hi Emilio, I think these regressions should not add a delay to testing migration as autopkgtests are passing in unstable and a rebuild is required to make them compatible with new protobuf version. autopkgtest for gazebo/9.0.0+dfsg5-4.2: amd64: Regression ♻ autopkgtest for ignition-msgs/1.0.0+dfsg1-5: amd64: Regression ♻ autopkgtest for ignition-transport/4.0.0+dfsg-4: amd64: Regression ♻ autopkgtest for ola/0.10.7.nojsmin-1: amd64: Regression ♻ Required age increased by 18 days because of autopkgtest signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On 2018, ഒക്ടോബർ 12 12:36:45 PM IST, "László Böszörményi (GCS)" wrote: > Uploaded ProtoBuf with the latest gRPC to Sid. Thanks a lot for your work! I hope to upload them to stretch-backports as soon as they enter testing (I have rebuilt them for my personal repo before). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#901015: transition: protobuf
Hi Emilio, On Thu, Oct 11, 2018 at 12:56 PM Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 11/09/2018 09:51, László Böszörményi (GCS) wrote: > > The last package which fails is gazebo which seems to be team > > maintained but it has two NMUs already. There's no bug reported here > > for the protobuf update but upstream aware of it and has a patch[1]. > > This one is not yet tested by me, but the upstream BTS contains a > > comment that's a working fix for gazebo 7.x and the original bug > > report[2] states that the fix is in place for the 8.x and 9.x versions > > as well. If you have time, please file a bug for this to the gazeboo > > source package - but as noted its Debian maintainers are not very > > active. > > Sounds good. Please go ahead with the transition and bump the bugs to serious. Uploaded ProtoBuf with the latest gRPC to Sid. Already built on most release architectures, only mips64el and mipsel have still these in their build queue. Reverse dependencies seems to be updated expect Gazebo. Raised its bug severity[1]. Cheers, Laszlo/GCS [1] https://bugs.debian.org/908854#10
Bug#901015: transition: protobuf
Control: tags -1 confirmed On 11/09/2018 09:51, László Böszörményi (GCS) wrote: > On Tue, Sep 11, 2018 at 8:41 AM Pirate Praveen > wrote: >> On Fri, 17 Aug 2018 10:21:41 +0200 >> =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: >>> The new protobuf -> protobuf-c / grpc chain compiles now on all >>> release architectures. Due to the mentioned protobuf soname change, I >>> have to restart building of all other dependent packages. I'll be off >>> the grid for the weekend, but will do it next week. >> >> Any update on this? > Indeed, missed to post the results. I'm not at home, all I write is > from my head only. I've build tested all the protobuf reverse > dependencies. > About two packages fail for other reasons and those are already > reported as an RC bug. Four packages fail due to protobuf changes and > three of those already reported by you and have an upstream patch. > I've tested those and their build now works. > The last package which fails is gazebo which seems to be team > maintained but it has two NMUs already. There's no bug reported here > for the protobuf update but upstream aware of it and has a patch[1]. > This one is not yet tested by me, but the upstream BTS contains a > comment that's a working fix for gazebo 7.x and the original bug > report[2] states that the fix is in place for the 8.x and 9.x versions > as well. If you have time, please file a bug for this to the gazeboo > source package - but as noted its Debian maintainers are not very > active. Sounds good. Please go ahead with the transition and bump the bugs to serious. Cheers, Emilio
Bug#901015: transition: protobuf
On Tue, 11 Sep 2018 09:51:07 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > The last package which fails is gazebo which seems to be team > maintained but it has two NMUs already. There's no bug reported here > for the protobuf update but upstream aware of it and has a patch[1]. > This one is not yet tested by me, but the upstream BTS contains a > comment that's a working fix for gazebo 7.x and the original bug > report[2] states that the fix is in place for the 8.x and 9.x versions > as well. If you have time, please file a bug for this to the gazeboo > source package - but as noted its Debian maintainers are not very > active. I have reported it as #908854 and it is already fixed upstream in 9.2 version. I think we can upload protobuf now and raise severity of the gazebo bug to serious. signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Tue, Sep 11, 2018 at 8:41 AM Pirate Praveen wrote: > On Fri, 17 Aug 2018 10:21:41 +0200 > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > > The new protobuf -> protobuf-c / grpc chain compiles now on all > > release architectures. Due to the mentioned protobuf soname change, I > > have to restart building of all other dependent packages. I'll be off > > the grid for the weekend, but will do it next week. > > Any update on this? Indeed, missed to post the results. I'm not at home, all I write is from my head only. I've build tested all the protobuf reverse dependencies. About two packages fail for other reasons and those are already reported as an RC bug. Four packages fail due to protobuf changes and three of those already reported by you and have an upstream patch. I've tested those and their build now works. The last package which fails is gazebo which seems to be team maintained but it has two NMUs already. There's no bug reported here for the protobuf update but upstream aware of it and has a patch[1]. This one is not yet tested by me, but the upstream BTS contains a comment that's a working fix for gazebo 7.x and the original bug report[2] states that the fix is in place for the 8.x and 9.x versions as well. If you have time, please file a bug for this to the gazeboo source package - but as noted its Debian maintainers are not very active. Regards, Laszlo/GCS [1] https://bitbucket.org/osrf/gazebo/pull-request/2984 [2] https://bitbucket.org/osrf/gazebo/issues/2483/gazebo-compilation-broken-with-protobuf-36
Bug#901015: transition: protobuf
On Fri, 17 Aug 2018 10:21:41 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > On Tue, Aug 14, 2018 at 6:53 AM Robert Edmonds wrote: > > I've released a new upstream version of protobuf-c that fixes the FTBFS > > issue with protobuf 3.6, which fixes #900621. I will upload it to > > unstable shortly. > To whom it may concern, a status update. > Robert released and uploaded an updated protobuf-c version. It built > fine with protobuf 3.0.0 and I could build it with 3.6.0.1 as well. > Google released a new protobuf release with 3.6.1 version number. I've > packaged it and due to a new soname version it had to go through NEW. > Then it had a new grpc release which was packaged and uploaded as > well. > The new protobuf -> protobuf-c / grpc chain compiles now on all > release architectures. Due to the mentioned protobuf soname change, I > have to restart building of all other dependent packages. I'll be off > the grid for the weekend, but will do it next week. Any update on this? > Regards, > Laszlo/GCS > > signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Tue, Aug 14, 2018 at 6:53 AM Robert Edmonds wrote: > I've released a new upstream version of protobuf-c that fixes the FTBFS > issue with protobuf 3.6, which fixes #900621. I will upload it to > unstable shortly. To whom it may concern, a status update. Robert released and uploaded an updated protobuf-c version. It built fine with protobuf 3.0.0 and I could build it with 3.6.0.1 as well. Google released a new protobuf release with 3.6.1 version number. I've packaged it and due to a new soname version it had to go through NEW. Then it had a new grpc release which was packaged and uploaded as well. The new protobuf -> protobuf-c / grpc chain compiles now on all release architectures. Due to the mentioned protobuf soname change, I have to restart building of all other dependent packages. I'll be off the grid for the weekend, but will do it next week. Regards, Laszlo/GCS
Bug#901015: transition: protobuf
Hi, I've released a new upstream version of protobuf-c that fixes the FTBFS issue with protobuf 3.6, which fixes #900621. I will upload it to unstable shortly. László Böszörményi (GCS) wrote: > On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen > wrote: > > On Fri, 6 Jul 2018 10:55:03 +0200 > > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= > > wrote: > > > The most problematic point is the protobuf-c dependency package. It > > > was developed (and packaged) by one of us (an other DD), Robert S. > > > Edmonds. It is the most complete C language implementation of Protocol > > > Buffers. While it has a newer upstream release in Git than the > > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > > which is in experimental. > [...] > > What do you think about providing protobuf3.0 in parallel to updating > > protobuf to 3.6? That way we can move ahead with gitlab and provide more > > time for either updating protobuf-c or porting packages to protobluff. > > We can drop protobuf3.0 when protobuf-c issue is resolved. > Actually I would like to investigate every possibility. > 1) Check the list of protobuf-c main contributors[1] if any of them > can / want to continue its development. > 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't > be its upstream developer on the long run. > 3) Patch protobuf-c to use the implementation of scoped_array in Boost. > 4) At least check the required porting needs of dependencies to > protobluff. Ask their maintainers if they want / can do the porting. > Maybe they know other alternatives. > > If these fail and RMs ACK to carry two versions of protobuf then of > course, do it. Emilio? > How quick do you need to solve this GitLab update? I guess, quick. -- Robert Edmonds edmo...@debian.org
Bug#901015: transition: protobuf
[Copying Emilio] On Thu, 12 Jul 2018 10:27:58 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > [Removed the Security Team Cc, they were relevant for backporting > protobuf to Stretch, not for updating it in Sid.] > > On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen > wrote: > > On Fri, 6 Jul 2018 10:55:03 +0200 > > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= > > wrote: > > > The most problematic point is the protobuf-c dependency package. It > > > was developed (and packaged) by one of us (an other DD), Robert S. > > > Edmonds. It is the most complete C language implementation of Protocol > > > Buffers. While it has a newer upstream release in Git than the > > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > > which is in experimental. > [...] > > What do you think about providing protobuf3.0 in parallel to updating > > protobuf to 3.6? That way we can move ahead with gitlab and provide more > > time for either updating protobuf-c or porting packages to protobluff. > > We can drop protobuf3.0 when protobuf-c issue is resolved. > Actually I would like to investigate every possibility. > 1) Check the list of protobuf-c main contributors[1] if any of them > can / want to continue its development. > 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't > be its upstream developer on the long run. > 3) Patch protobuf-c to use the implementation of scoped_array in Boost. > 4) At least check the required porting needs of dependencies to > protobluff. Ask their maintainers if they want / can do the porting. > Maybe they know other alternatives. > > If these fail and RMs ACK to carry two versions of protobuf then of > course, do it. Emilio? Hi Emilio, Can you comment? > How quick do you need to solve this GitLab update? I guess, quick. > > Cheers, > Laszlo/GCS > [1] https://github.com/protobuf-c/protobuf-c/graphs/contributors > > signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Thursday 12 July 2018 01:57 PM, László Böszörményi (GCS) wrote: > How quick do you need to solve this GitLab update? I guess, quick. We are not able to backport some complex security fixes to gitlab 8.13 in stretch. Security team wants to remove gitlab 8.13 from stable and I'd like to provide an update path via stretch-backports before it is removed. So the sooner we can provide, the better :) signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
[Removed the Security Team Cc, they were relevant for backporting protobuf to Stretch, not for updating it in Sid.] On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen wrote: > On Fri, 6 Jul 2018 10:55:03 +0200 > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > > The most problematic point is the protobuf-c dependency package. It > > was developed (and packaged) by one of us (an other DD), Robert S. > > Edmonds. It is the most complete C language implementation of Protocol > > Buffers. While it has a newer upstream release in Git than the > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > which is in experimental. [...] > What do you think about providing protobuf3.0 in parallel to updating > protobuf to 3.6? That way we can move ahead with gitlab and provide more > time for either updating protobuf-c or porting packages to protobluff. > We can drop protobuf3.0 when protobuf-c issue is resolved. Actually I would like to investigate every possibility. 1) Check the list of protobuf-c main contributors[1] if any of them can / want to continue its development. 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't be its upstream developer on the long run. 3) Patch protobuf-c to use the implementation of scoped_array in Boost. 4) At least check the required porting needs of dependencies to protobluff. Ask their maintainers if they want / can do the porting. Maybe they know other alternatives. If these fail and RMs ACK to carry two versions of protobuf then of course, do it. Emilio? How quick do you need to solve this GitLab update? I guess, quick. Cheers, Laszlo/GCS [1] https://github.com/protobuf-c/protobuf-c/graphs/contributors
Bug#901015: transition: protobuf
On Fri, 6 Jul 2018 10:55:03 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > The most problematic point is the protobuf-c dependency package. It > was developed (and packaged) by one of us (an other DD), Robert S. > Edmonds. It is the most complete C language implementation of Protocol > Buffers. While it has a newer upstream release in Git than the > packaged version, it's still not compatible with protobuf 3.6.0.1 > which is in experimental. > Main reason is that scoped_array (a class template to store pointers > to a dynamically allocated array) is removed from newer protobuf > releases, still protobuf-c still would like to use it. While Boost has > a similar (same?) scoped_array implementation since its 1.49 version, > I highly doubt protobuf-c should be altered to use that. As I can't > reach Robert for about nine months and I don't see any life sign from > him either, protobuf-c definitely needs a new upstream maintainer with > internal protobuf knowledge. > > Of course, several other C implementation of protobuf exist. > PBC[1] seems to be dead for more than a year now and does _not_ have a > code generator. > Nanopb[2] is a trim down version for 32 bits and microcontrollers only. > protobluff[3] seems to be the most viable alternative. It's modular, > seems to be in development and integrates with the upstream code > generator. > None of these are packaged as I know. > > But why is all the fuzz you may ask. The protobuf-c library is used by > several big / important projects. Like Knot DNS (a high-performance > DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and > PostGIS (geographic objects support for PostgreSQL, postgis) - > maintained by people like Ondřej Surý and Carnil (Salvatore > Bonaccorso), ones that I bow before them for their knowledge. These > packages and others would break with starting the protobuf transition > without protobuf-c being updated. Porting these to protobluff might be > an even bigger task. László, What do you think about providing protobuf3.0 in parallel to updating protobuf to 3.6? That way we can move ahead with gitlab and provide more time for either updating protobuf-c or porting packages to protobluff. We can drop protobuf3.0 when protobuf-c issue is resolved. Thanks Praveen signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On July 6, 2018 2:25:03 PM GMT+05:30, "László Böszörményi (GCS)" wrote: >Praveen, as I saw you even talked to the Security Team about >backporting protobuf and grpc packages to Stretch for GitLab >issues[4]. Please do so with caution about protobuf-c for the reasons >mentioned above. In the future pretty please at least Cc me for >transition requests for packages that I maintain. It's much harder to >learn that it's already filed by someone else who may not know all the >consequences. I notified you as soon as I filed this here, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855034#60 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#901015: transition: protobuf
Control: owner -1 ! Hi, First thing first. Protocol Buffers is a data interchange format used by several projects and C++ based. Language bindings are available, but not all of those come from upstream, Google Inc. It also has an RPC library and framework called gRPC with language bindings on its own. Rebuilding tests are in progress. But the following things are crucial. protobuf now builds ruby-google-protobuf which was built from src:ruby-google-protobuf previously. The mentioned dependency, grpc now includes the ruby-grpc and ruby-grpc-tools binaries. Previously these were built from src:ruby-grpc. Conflicts and replaces are in place of course. The most problematic point is the protobuf-c dependency package. It was developed (and packaged) by one of us (an other DD), Robert S. Edmonds. It is the most complete C language implementation of Protocol Buffers. While it has a newer upstream release in Git than the packaged version, it's still not compatible with protobuf 3.6.0.1 which is in experimental. Main reason is that scoped_array (a class template to store pointers to a dynamically allocated array) is removed from newer protobuf releases, still protobuf-c still would like to use it. While Boost has a similar (same?) scoped_array implementation since its 1.49 version, I highly doubt protobuf-c should be altered to use that. As I can't reach Robert for about nine months and I don't see any life sign from him either, protobuf-c definitely needs a new upstream maintainer with internal protobuf knowledge. Of course, several other C implementation of protobuf exist. PBC[1] seems to be dead for more than a year now and does _not_ have a code generator. Nanopb[2] is a trim down version for 32 bits and microcontrollers only. protobluff[3] seems to be the most viable alternative. It's modular, seems to be in development and integrates with the upstream code generator. None of these are packaged as I know. But why is all the fuzz you may ask. The protobuf-c library is used by several big / important projects. Like Knot DNS (a high-performance DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and PostGIS (geographic objects support for PostgreSQL, postgis) - maintained by people like Ondřej Surý and Carnil (Salvatore Bonaccorso), ones that I bow before them for their knowledge. These packages and others would break with starting the protobuf transition without protobuf-c being updated. Porting these to protobluff might be an even bigger task. Praveen, as I saw you even talked to the Security Team about backporting protobuf and grpc packages to Stretch for GitLab issues[4]. Please do so with caution about protobuf-c for the reasons mentioned above. In the future pretty please at least Cc me for transition requests for packages that I maintain. It's much harder to learn that it's already filed by someone else who may not know all the consequences. Thanks, Laszlo/GCS [1] https://github.com/cloudwu/pbc [2] https://jpa.kapsi.fi/nanopb/ [3] https://squidfunk.github.io/protobluff/ [4] https://salsa.debian.org/ruby-team/gitlab/wikis/stretch-backports
Bug#901015: transition: protobuf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, protobuf 3.6 is in experimental and ready to start the transition from 3.0 in unstable. I've rebuilt the relevant reverse-build-dependencies from unstable. The following succeed and can be binNMU'd directly: android-platform-tools-analytics-library anfo appstream aseba berkeley-express bernhard biomaj3-daemon biomaj3-download biomaj3-process bookkeeper caffe clementine closure-compiler compiz criu cubemap dfvfs dnsdist docker-runc dogecoin electrum etcd gobgp go-dep golang-gitaly-proto golang-github-prometheus-client-model golang-gogoprotobuf golang-google-genproto golang-google-grpc grpc grr harvest-tools ignition-msgs imposm imposm-parser libphonenumber litecoin mahimahi mapbox-vector-tile mapnik-vector-tile meson mkgmap mkgmap-splitter mosh mozc nageru netty osgearth osmpbf ostinato paraview pdns-recursor pink-pony projectreactor protozero pychromecast py-macaroon-bakery python-axolotl python-shogun python-trezor qtwebengine-opensource-src ricochet-im runc shogun usbguard vlc zbackup cura-engine: after libarcus The following packages already FTBFS: collectd dummydroid mixxx opencv - not enough space to build Seems to be unrelated failures: bitcoin - failed due to symbols issue. containerd, docker-containerd - dependency issues gazebo - should build after ignition osmosis - seems unrelated https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900615 r-cran-rprotobuf - unmet build dep android-platform-frameworks-base Filed bugs for the remaining: ignition-transport - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900429 ola https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900436 pokerth https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900616 protobuf-c https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900621 Thanks Praveen Ben file: title = "protobuf"; is_affected = .depends ~ /\b(libprotobuf\-lite16|libprotobuf16|libprotoc16|ruby\-google\-protobuf|libprotobuf\-lite10|libprotobuf10|libprotoc10)\b/; is_good = .depends ~ /\b(libprotobuf\-lite16|libprotobuf16|libprotoc16|ruby\-google\-protobuf)\b/; is_bad = .depends ~ .depends ~ /\b(libprotobuf\-lite10|libprotobuf10|libprotoc10)\b/; signature.asc Description: OpenPGP digital signature
