Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
Hi Laszlo/GCS, On Wed, Jan 13, 2021 at 11:14:22PM +0100, László Böszörményi (GCS) wrote: > This change was recently merged. Going to do the upload tomorrow. Seems we had some cross-fire on my activity and your mail... here's a status update: I just merged both the m-a related merge-requests (as you noticed). I also cherry-picked a trivial fix from upstream that was needed for the package to not FTBFS with python3.9. (Note: I have not checked if the rest of the python parts are actually compatible with python3.9, just fixed the obvious FTBFS.) I've already uploaded it as a NMU (as there was no feedback up until now), hope this helps. All tagged and pushed to the git repo. If you have any additional changes you want to see also uploaded I guess doing another upload tomorrow doesn't hurt. The (full) freeze is getting closer though, so please make it ASAP if you think another upload is needed. One thing I was on the fence about was if I should bump debhelper-compat to 12, given that 11 is *discuraged* but I held back on that... you might want to run lintian-brush on the repo. > > Thanks, > Laszlo/GCS Regards, Andreas Henriksson
Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
On Fri, Jan 8, 2021 at 11:42 PM Helmut Grohne wrote: > On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote: > This is a practical problem affecting packages inside Debian. Both bear > and sysdig fail to cross build from source, because they > protobuf-compiler-grpc is installed for the host architecture and cannot > be run. > > > If I'm not mistaken the protobuf-compiler-grpc package should be marked > > `Multi-Arch: foreign` just like for example protobuf-compiler package is. > > Yes, this is the most obvious cure of the problem. However, it is not > entirely clear that doing so is correct. The foreign marking is less of > a method to make things cross buildable. It is a guarantuee on the > interface provided by a package. Unless that guarantuee is warranted, > the marking is quite simply wrong and shouldn't be issued. If the > marking is correct, it does solve the cross building issues. This change was recently merged. Going to do the upload tomorrow. Thanks, Laszlo/GCS
Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
Control: affects -1 + src:bear src:sysdig Hi, On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote: > Package: protobuf-compiler-grpc > Version: 1.16.1-1 > Severity: normal > > Dear Maintainer, > > I'm having a problem with grpc_cpp_plugin in my cross-build environment. > > ``` > $ apt-get build-dep -aarmhf . -y > Note, using directory '.' to get the build dependencies > Reading package lists... > Building dependency tree... > Reading state information... > The following packages were automatically installed and are no longer > required: > libc-ares2 libgoogle-perftools4 libtcmalloc-minimal4 libunwind8 > Use 'apt autoremove' to remove them. > The following packages will be REMOVED: > protobuf-compiler-grpc > The following NEW packages will be installed: > [...] protobuf-compiler-grpc:armhf [...] > ``` This is a practical problem affecting packages inside Debian. Both bear and sysdig fail to cross build from source, because they protobuf-compiler-grpc is installed for the host architecture and cannot be run. > If I'm not mistaken the protobuf-compiler-grpc package should be marked > `Multi-Arch: foreign` just like for example protobuf-compiler package is. Yes, this is the most obvious cure of the problem. However, it is not entirely clear that doing so is correct. The foreign marking is less of a method to make things cross buildable. It is a guarantuee on the interface provided by a package. Unless that guarantuee is warranted, the marking is quite simply wrong and shouldn't be issued. If the marking is correct, it does solve the cross building issues. In order to evaluate correctness, one has to figure out what the "interface" of the protobuf-compiler-grpc package is. It provides a number of plugins for protoc's plugin mechanism. A bit of testing and googling later, I found that those plugins use a binary protocol on stdin and stdout to communicate with protoc. Binary protocols may or may not be architecture dependent. It seems like the one being used here is based on protocol buffers, which hints that is indeed architecture independent. Furthermore, the output of the plugins is program source, which tends to be architecture independent. To validate this, I've attempted combining protobuf-compiler:amd64 with protobuf-compiler-grpc:armhf. Using qemu-user-static, I plugged the grpc_cpp_plugin into protoc. It just worked. This is a minor confirmation of the hypothesis. >From my pov, this is sufficient to issue the Multi-Arch: foreign marking as it requires that you can mix and match protobuf-compiler and protobuf-compiler-grpc for various architectures (so long as you can actually run the code) and expect them to work together. Helmut
Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
Hello again, On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote: > Package: protobuf-compiler-grpc > Version: 1.16.1-1 > Severity: normal > > Dear Maintainer, > > I'm having a problem with grpc_cpp_plugin in my cross-build environment. [...] > > If I'm not mistaken the protobuf-compiler-grpc package should be marked > `Multi-Arch: foreign` just like for example protobuf-compiler package is. [...] I just discussed with Helmut on IRC where we collaborately tried to figure out how protoc and grpc_cpp_plugin interacts. Helmut said he'd write a more detailed report soon and post here, but the conclusion was that using `Multi-Arch: foreign` is likely correct for both protobuf-compiler and protobuf-compiler-grpc (as I previously suggested in my initial bug report). I would be happy to see this fix uploaded soon so it has a chance to go into testing before freeze! As there has been no feedback so far I'm preparing to NMU it soon. Please tell me if I can go ahead directly, if you have any objections, etc. Regards, Andreas Henriksson
Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
Package: protobuf-compiler-grpc Version: 1.16.1-1 Severity: normal Dear Maintainer, I'm having a problem with grpc_cpp_plugin in my cross-build environment. ``` $ apt-get build-dep -aarmhf . -y Note, using directory '.' to get the build dependencies Reading package lists... Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: libc-ares2 libgoogle-perftools4 libtcmalloc-minimal4 libunwind8 Use 'apt autoremove' to remove them. The following packages will be REMOVED: protobuf-compiler-grpc The following NEW packages will be installed: [...] protobuf-compiler-grpc:armhf [...] ``` If I'm not mistaken the protobuf-compiler-grpc package should be marked `Multi-Arch: foreign` just like for example protobuf-compiler package is. This would allow me to keep my hosts native protobuf-compiler-grpc package installed while installing the packages build-dependencies if I'm not mistaken. (Reported against the buster/stable version which is affected, but also verified that the situtation still seems to be the same with the testing/unstable version of the package.) Regards, Andreas Henriksson PS. Please don't take my word for anything about multi-arch stuff. If you're not qualified to know the correct solution I can probably help get someone else in the loop who can give us guidance.
