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.

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?

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?