Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sat, Apr 13, 2019 at 12:02 PM Niels Thykier wrote:
> From a release team PoV, we would very much like to see this be fixed
> with a Breaks as well.
I've prepared the change and attached to this email. This will make
libarcus3 and cura-engine need to be upgraded in the same time to
package versions which was built with libprotobuf17.
> On the flip side, having libprotobuf10 remain on some systems during
> upgrades will spell trouble for us later. Each release, we see a number
> of upgrade issues related to old, long obsolete packages that were
> removed releases ago. Lets ensure libprotobuf10 does not become one of
> them for bullseye or later.
In the last five years (I can remember about protobuf) upstream only
increased the soname - I don't think it will change. But I'll try to
remember and with the new upstream release (targeting Bullseye) add a
break to libprotobuf10.
Regards,
Laszlo/GCS
diff -Nru protobuf-3.6.1.3/debian/control protobuf-3.6.1.3/debian/control
--- protobuf-3.6.1.3/debian/control 2018-12-09 12:45:11.0 +
+++ protobuf-3.6.1.3/debian/control 2019-04-16 22:12:03.0 +
@@ -66,6 +66,7 @@
Multi-Arch: same
Section: libs
Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libarcus3 (<< 3.3.0-2), cura-engine (<< 1:3.3.0-2.1+b1)
Description: protocol buffers C++ library
Protocol buffers are a flexible, efficient, automated mechanism for
serializing structured data - similar to XML, but smaller, faster, and
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Wed, 3 Apr 2019 00:04:43 +0200 Andreas Beckmann wrote: > [...] > > What's the point in having a cruft package (libprotobuf10) installable > in buster, if it has been shown that this allows partial upgrades (yes, > partial upgrades *are* supported) that reproducibly cause failures? > The cruft package itself does not cause harm. It's the combination with > other packages that's problematic. There is an easy solution to prevent > all these (see Subject), without imposing any limitation on buster. > > While it is possible to add the Breaks to libarcus3 instead, is this > sufficient to prevent *all* failure cases? Which package will be the > next to be touched to prevent mixture errors? > > There is no point in touching Build-Depends, as we can't build against > this cruft in sid. > > Andreas > > Hi, >From a release team PoV, we would very much like to see this be fixed with a Breaks as well. > Hi Pirate, > > On Sat, Oct 20, 2018 at 10:39 AM Pirate Praveen > wrote: >> On Mon, 15 Oct 2018 16:26:23 +0300 Adrian Bunk wrote: >> > When it has been observed that ending up with both libprotobuf10 and >> > libprotobuf17 in a binary will not work, then this should be expressed >> > through the package dependencies. > ... of the binaries that need to be compiled with the same ProtoBuf version. > >> Are you planning to upload this fix? Testing migration is currently >> blocked by this rc bug and there is a delay caused by autopkgtest failure. > Let's break it to parts. > 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. > While libprotobuf10 and libprotobuf17 *can* be installed together, nothing in buster should rely on libprotobuf10 any longer. Indeed, libprotobuf10 is not even in buster any longer. > [...] >> > That would avoid a couple of potential problems in situations like >> > stretch->buster upgrades or for testing users. > Breaking libprotobuf10 would cause more problems. All ProtoBuf > related packages would need to migrate once and together. Cause > problem with any local compiled program for libprotobuf10. > This may have been an issue at that time, but it no longer is (as libprotobuf10 is not in testing anymore). On the flip side, having libprotobuf10 remain on some systems during upgrades will spell trouble for us later. Each release, we see a number of upgrade issues related to old, long obsolete packages that were removed releases ago. Lets ensure libprotobuf10 does not become one of them for bullseye or later. Thanks, ~Niels
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sun, 31 Mar 2019 16:51:51 +0200 Giovanni Mascellani wrote: > Hi, > > On Sat, 27 Oct 2018 17:30:32 +0300 Adrian Bunk wrote: > > Properly handling this in package like libarcus3 becomes difficult once > > you consider that such packages might be backported to stretch-backports > > and would use libprotobuf10 there. > > > > We might even end up with upgrade failures if a user could end up with > > a nonworking combination of packages installed during an upgrade, and > > a maintainer script calls such a nonworking program. > > This is a sensible concern, but I share László's view here: the two > versions of protobuf are not in conflict and can happily coexist on the > same system, so there is no reason to declare a Break. What must be > ensured is that no package depends on both at the same time: wouldn't it > be better that this last package declared Conflicts and possibly > Build-Conflicts towards the version of protobuf that is not meant to be > used? What's the point in having a cruft package (libprotobuf10) installable in buster, if it has been shown that this allows partial upgrades (yes, partial upgrades *are* supported) that reproducibly cause failures? The cruft package itself does not cause harm. It's the combination with other packages that's problematic. There is an easy solution to prevent all these (see Subject), without imposing any limitation on buster. While it is possible to add the Breaks to libarcus3 instead, is this sufficient to prevent *all* failure cases? Which package will be the next to be touched to prevent mixture errors? There is no point in touching Build-Depends, as we can't build against this cruft in sid. Andreas
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
Hi, On Sat, 27 Oct 2018 17:30:32 +0300 Adrian Bunk wrote: > Properly handling this in package like libarcus3 becomes difficult once > you consider that such packages might be backported to stretch-backports > and would use libprotobuf10 there. > > We might even end up with upgrade failures if a user could end up with > a nonworking combination of packages installed during an upgrade, and > a maintainer script calls such a nonworking program. This is a sensible concern, but I share László's view here: the two versions of protobuf are not in conflict and can happily coexist on the same system, so there is no reason to declare a Break. What must be ensured is that no package depends on both at the same time: wouldn't it be better that this last package declared Conflicts and possibly Build-Conflicts towards the version of protobuf that is not meant to be used? Hop this helps, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sat, Oct 27, 2018 at 08:34:49AM +0530, Pirate Praveen wrote: > > > On 2018, ഒക്ടോബർ 27 2:38:23 AM IST, Adrian Bunk wrote: > >No, it is not. > > > >I would expect everything that fails during build time to fail the same > > > >way at runtime. > > > > Can you reproduce the bug? Once it is built against the correct version, it > will use that version only. After downgrading libarcus3 to 3.3.0-1: $ CuraEngine [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) terminate called after throwing an instance of 'google::protobuf::FatalException' what(): This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) Aborted $ Properly handling this in package like libarcus3 becomes difficult once you consider that such packages might be backported to stretch-backports and would use libprotobuf10 there. We might even end up with upgrade failures if a user could end up with a nonworking combination of packages installed during an upgrade, and a maintainer script calls such a nonworking program. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On 2018, ഒക്ടോബർ 27 2:38:23 AM IST, Adrian Bunk wrote: >No, it is not. > >I would expect everything that fails during build time to fail the same > >way at runtime. > Can you reproduce the bug? Once it is built against the correct version, it will use that version only. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
Control: severity -1 serious Control: retitle -1 libprotobuf17 needs Breaks: libprotobuf10 On Sun, Oct 21, 2018 at 01:27:52PM +0530, Pirate Praveen wrote: > On Sat, 20 Oct 2018 11:36:55 +0200 > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > > Let's break it to parts. > > 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. > > OK. Since its only an issue during build time and not runtime, I think > we can reduce the severity of this bug. No, it is not. I would expect everything that fails during build time to fail the same way at runtime. > > 2) Packages that depend on each other, need to be compiled with the > > same ProtoBuf version. This should be expressed in those package > > dependencies. >... How exactly do you want this to be "expressed in those package dependencies" so that it is ensured that any kind of stretch/buster/sid mixing that is permitted by the package dependencies is also working? If you actually have a complete solution that is better than a Breaks: libprotobuf10 in libprotobuf17, please share the details. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sat, 20 Oct 2018 11:36:55 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > 2) Packages that depend on each other, need to be compiled with the > same ProtoBuf version. This should be expressed in those package > dependencies. You might want to comment here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900429#36 > 3) Self-tests need fixing, this is clear. Now there is only a warning, it can be fixed by adding Restrictions: allow-stderr in debian/tests/control. signature.asc Description: OpenPGP digital signature
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sun, 21 Oct 2018 13:27:52 +0530 Pirate Praveen wrote: > I have also asked upstream for support here > https://github.com/protocolbuffers/protobuf/issues/5276 there is already > one person assigned to it. > Upstream confirmed it is debian specific and it seems this should be merged with #911404. signature.asc Description: OpenPGP digital signature
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Sat, 20 Oct 2018 11:36:55 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > Let's break it to parts. > 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. OK. Since its only an issue during build time and not runtime, I think we can reduce the severity of this bug. > 2) Packages that depend on each other, need to be compiled with the > same ProtoBuf version. This should be expressed in those package > dependencies. Then we'll need to clone this bug and assign to cura-engine and ignition-transport (build currently failing on all archs). I don't know if this needs to be extended to android-platform-frameworks-base bitcoin caffe-contrib litecoin mixxx which failed to build on some archs. > 3) Self-tests need fixing, this is clear. I have retitled the bug and sine autopkgtest failure is not rc and its really an issue of tests and not protobuf itself, I think we can reduce severity to important. > > protobuf 3.6.1 autopkgtest is failing with this error, can you help > > fixing this? > I'll also check these, but help might be needed. My Java knowledge is > very rusty. I have also asked upstream for support here https://github.com/protocolbuffers/protobuf/issues/5276 there is already one person assigned to it. signature.asc Description: OpenPGP digital signature
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
Hi Pirate, On Sat, Oct 20, 2018 at 10:39 AM Pirate Praveen wrote: > On Mon, 15 Oct 2018 16:26:23 +0300 Adrian Bunk wrote: > > When it has been observed that ending up with both libprotobuf10 and > > libprotobuf17 in a binary will not work, then this should be expressed > > through the package dependencies. ... of the binaries that need to be compiled with the same ProtoBuf version. > Are you planning to upload this fix? Testing migration is currently > blocked by this rc bug and there is a delay caused by autopkgtest failure. Let's break it to parts. 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. 3) Self-tests need fixing, this is clear. > > That would avoid a couple of potential problems in situations like > > stretch->buster upgrades or for testing users. Breaking libprotobuf10 would cause more problems. All ProtoBuf related packages would need to migrate once and together. Cause problem with any local compiled program for libprotobuf10. > > It should also fix the autopkgtest failures that are currently > > preventing protobuf from entering testing this month. > > I added Breaks and ran autopkgtests again, but it still failed. Indeed, breaks in ProtoBuf is not the solution. This needs investigating, maybe updating the tests. > I think the examples are not updated for new api. New jar file does not > have this class. [...] > protobuf 3.6.1 autopkgtest is failing with this error, can you help > fixing this? I'll also check these, but help might be needed. My Java knowledge is very rusty. Regards, Laszlo/GCS
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
[copying debian-java as the failure is java related]
On Mon, 15 Oct 2018 16:26:23 +0300 Adrian Bunk wrote:
> Yes, that's what I also suspect.
>
> When it has been observed that ending up with both libprotobuf10 and
> libprotobuf17 in a binary will not work, then this should be expressed
> through the package dependencies.
Hi Laszlo,
Are you planning to upload this fix? Testing migration is currently
blocked by this rc bug and there is a delay caused by autopkgtest failure.
> That would avoid a couple of potential problems in situations like
> stretch->buster upgrades or for testing users.
>
> It should also fix the autopkgtest failures that are currently
> preventing protobuf from entering testing this month.
I added Breaks and ran autopkgtests again, but it still failed.
diff --git a/debian/control b/debian/control
index cae7232..d060e8c 100644
--- a/debian/control
+++ b/debian/control
@@ -66,6 +66,7 @@ Architecture: any
Multi-Arch: same
Section: libs
Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libprotobuf10 (<< 3.6.1~)
Description: protocol buffers C++ library
Protocol buffers are a flexible, efficient, automated mechanism for
serializing structured data - similar to XML, but smaller, faster, and
I think the examples are not updated for new api. New jar file does not
have this class.
Hi java team,
protobuf 3.6.1 autopkgtest is failing with this error, can you help
fixing this?
javac -cp $CLASSPATH AddPerson.java ListPeople.java
com/example/tutorial/AddressBookProtos.java
com/example/tutorial/AddressBookProtos.java:1077: error: cannot find symbol
private com.google.protobuf.Timestamp lastUpdated_;
full log,
https://ci.debian.net/data/packages/unstable/amd64/p/protobuf/latest-autopkgtest/log.gz
Thanks
Praveen
signature.asc
Description: OpenPGP digital signature
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Mon, Oct 15, 2018 at 06:33:50PM +0530, Pirate Praveen wrote: > On Sat, 13 Oct 2018 23:42:59 +0300 Adrian Bunk wrote: > > Package: libprotobuf17 > > Version: 3.6.1-2 > > Severity: serious > > Control: affects -1 src:cura-engine > > I think this was caused by another dependency still built against older > protobuf. >... Yes, that's what I also suspect. When it has been observed that ending up with both libprotobuf10 and libprotobuf17 in a binary will not work, then this should be expressed through the package dependencies. That would avoid a couple of potential problems in situations like stretch->buster upgrades or for testing users. It should also fix the autopkgtest failures that are currently preventing protobuf from entering testing this month. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
Package: libprotobuf17 Version: 3.6.1-2 Severity: serious Control: affects -1 src:cura-engine https://buildd.debian.org/status/package.php?p=cura-engine=sid ... Running tests... /usr/bin/ctest --force-new-ctest-process -j4 Test project /<>/obj-x86_64-linux-gnu Start 1: SpaceFillingTreeFillTest Start 2: SparseGridTest Start 3: IntPointTest Start 4: LinearAlg2DTest 1/8 Test #1: SpaceFillingTreeFillTest .***Exception: Child aborted 0.02 sec [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) terminate called after throwing an instance of 'google::protobuf::FatalException' what(): This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) Start 5: PolygonUtilsTest 2/8 Test #2: SparseGridTest ...***Exception: Child aborted 0.03 sec [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) terminate called after throwing an instance of 'google::protobuf::FatalException' what(): This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) Start 6: PolygonTest 3/8 Test #3: IntPointTest .***Exception: Child aborted 0.03 sec [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) terminate called after throwing an instance of 'google::protobuf::FatalException' what(): This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) Start 7: StringTest 4/8 Test #4: LinearAlg2DTest ..***Exception: Child aborted 0.02 sec [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) terminate called after throwing an instance of 'google::protobuf::FatalException' what(): This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".) Start 8: UnionFindTest 5/8 Test #6: PolygonTest ..***Exception: Child aborted 0.01 sec [libprotobuf FATAL google/protobuf/stubs/common.cc:79] This program was compiled against version 3.0.0 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.6.1). Contact the program author for an update. If you compiled the program
