[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Binary-only rebuild of a package in trixie

On Tue, 04 Nov 2025 at 22:43:42 -0600, John Goerzen wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118629 pertains to a
bug that can be resolved in trixie by simply rebuilding ckermit from
source.

I'd like to know how to accomplish this.  Is there someone that I could
contact to do that?  Or does it require a new changelog entry, and
source upload, to trixie-proposed-updates or some such?
The half-answer is: open a trixie-pu bug to ask the stable release managers what they would prefer.
I believe it is possible to binNMU packages in stable, just like they can be binNMU'd in unstable (but with some coordination required to make sure that the version progression still goes stable <= testing <= unstable). If this is the preferred route, it is the release team that would do it, and they prefer to be contacted by opening a bug (so that they can use the BTS as a task tracker) rather than sending mailing list email that can easily get forgotten.
Or if there's a reason to need a sourceful upload, the first step of making that happen is *also* to contact the stable release managers with a debdiff. So either way, a bug against the release.debian.org pseudo-package is the right thing to do.
I see from the bug report that ckermit is second-guessing OpenSSL's versioning policy: 


    . C-Kermit built with OpenSSL 3.4.1 11 Feb 2025
    . Version found  OpenSSL 3.5.1 1 Jul 2025
    OpenSSL versions 1.0.0 or newer must be the same
    major and minor version number, and Kermit may not
    be used with a version of OpenSSL older than the one
    supplied at compile time.
This seems to be applying the OpenSSL 1.x versioning policy (each new *minor* version is a new incompatible ABI / new SONAME) and assuming it's still true for OpenSSL 3, but that isn't the case: as per <https://www.openssl-library.org/policies/general/versioning-policy/index.html> the new policy since OpenSSL 3 is that each new *major* version (only) is a new incompatible ABI / new SONAME, but minor versions are backward-compatible. (This is the familiar major.minor.micro pattern seen in "semantic versioning", and in many other popular libraries like GTK, Qt and SDL.)
So please approach upstream about removing this check, or at least making it behave appropriately for OpenSSL 3.x.
In Debian specifically, we manage ABI breaks via the ELF SONAME and binary package renaming, and compatible minor-version upgrades via dpkg-shlibdeps, so second-guessing version checks like this is usually inappropriate and it is often better for it to be patched out completely. For example, if a package was built against OpenSSL 3.6, but then ends up migrating to testing before 3.6 and running against 3.5, that can actually be OK if it doesn't use any of the APIs that were added or changed behaviour in 3.6. As a result I suspect that the release team will ask you to patch out (delete or #if 0) this version check and rely on Debian's normal versioning mechanisms. 

    smcv
Reply to: