This looks like overkill to me, for openconnect. There's precisely one function exported from libopenconnect which uses time_t, and I suspect there aren't any *users* of that function in the distribution anyway (neither openconnect(8) nor NetworkManager- openconnect use it). So although it's not best practice, we could actually get away with just *dropping* that function, and adding a new function which returns either an explicit 64-bit value or a timespec or something.
Alternatively... on how many of our 64-bit architectures can we just return the high 32 bits of the 64-bit time_t in a register that we call-clobbered anyway — so callers who expect a 64-bit time_t get to see it all, and callers who expect a 32-bit time_t just don't notice? The contents of the *low* 32 bits are the same either way, right? It definitely doesn't seem like we need to switch to a new soname ... except *are* you switching the soname? Or just the package name? It looks like the symbol versions are remaining the *same*...? How does that work? On Sat, 2024-02-03 at 16:13 -0300, Lucas Kanashiro wrote: > Source: openconnect > Version: 9.12-1 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > openconnect as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a > change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it > is > important that libraries affected by this ABI change all be uploaded > close > together in time. Therefore I have prepared a 0-day NMU for > openconnect > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. > Although > this package will be uploaded to experimental immediately, there will > be a > period of several days before we begin uploads to unstable; so if > information > becomes available that your package should not be included in the > transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.2.0-39-generic (SMP w/32 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system)
smime.p7s
Description: S/MIME cryptographic signature
