Hi, Florian: Florian Ernst wrote: > Dear maintainer / upstream, > > as you are without doubt well aware, there is a new upstream release > available, cf. <https://github.com/protobuf-c/protobuf-c/releases> > listing
Thanks, yes, I am aware. > | v1.5.0 Latest > | Nov 26, 2023 > | What's Changed > | Makefile.am: change link order by @franksinankaya in #486 > | GitHub actions fail on Windows due to missing unzip command by @britzl in > #525 > | Export and install CMake targets by @morrisonlevi in #472 > | Use CMAKE_CURRENT_BINARY_DIR instead of CMAKE_BINARY_DIR by @KivApple in > #482 > | remove deprecated functionality by @aviborg in #542 > | Avoid "unused variable" compiler warning by @rgriege in #545 > | Update autotools by @AtariDreams in #550 > | Support for new Google protobuf 22.x, 23.x releases by @edmonds in #673 > | Miscellaneous fixes by @edmonds in #675 > | Remove protobuf 2.x support by @edmonds in #676 > | Silence some compiler diagnostics by @edmonds in #677 > | Fixing MSVC build for Msbuild and Makefile generators by @MiguelBarro in > #685 None of these changes are particularly interesting for Debian. That's why I didn't upload 1.5.0 to Debian. If I recall correctly I only released 1.5.0 in the first place because the previous release was not building on Windows. The most interesting change is probably PR#673, but Debian still has protobuf 3.21.x in unstable. I suspect at some point the protobuf maintainer will want to skip over those older 22.x and 23.x releases to something newer (experimental has 25.x; upstream just released an RC for 28.0) that would require fixes in and a new upstream release of protobuf-c in order to support newer versions of protobuf ([0] is where that work is occurring). > Considering that this release hasn't found its way into Debian yet, and > that #1004962 went without any feedback (visible to me, that is, of > course), and that the packaging repo on Salsa seem to be out of date, I > was wondering whether this package might be in need of support. > > I could assist by packaging the most recent release, if that'd interest > you. > > Please let me know what your plans are. I don't really need any help maintaining the Debian package. It's a fairly trivial package that ships a C library and a single command-line binary. Where assistance would be much more helpful is in the upstream protobuf-c project where almost all of my protobuf-c effort is spent. The previously mentioned open PR#711 [0] is where the fixes for compatibility with newer protobuf releases are being prepared. However, protobuf-c is a cross-platform project and most of the build/runtime failures these days tend to occur on non-Linux platforms, or in the cmake build system (which isn't used for the Debian package build), so that may be less interesting if your focus is Debian. I would like to nail down the compatibility issues with upstream protobuf 26.x, 27.x, 28.x on Linux, MacOS, and Windows, release protobuf-c 1.5.1, and upload 1.5.1 to Debian. The other task I can think of with the upstream protobuf-c project that needs help is replacing the existing autotools and cmake build systems with meson. I had started that development work on a branch [0] a few years ago but if I recall correctly I ran into some issues that required feature changes in meson, so I set that work aside in order to wait for the meson changes to make it into stable Linux distros. I am pretty confident that meson can easily replace autotools for protobuf-c now, but I'm less confident that it can replace cmake, which tends to be used by Windows developers in "interesting" ways. So that would require some testing on various platforms, including Windows, preferably by someone who is a lot more familiar with software development practices on Windows (which isn't me). But it would be very nice to have a single upstream build system for protobuf-c, instead of two or three. [0] https://github.com/protobuf-c/protobuf-c/pull/711 [1] https://github.com/protobuf-c/protobuf-c/tree/edmonds/meson-build-system -- Robert Edmonds edmo...@debian.org
