This is a multi-part MIME message sent by reportbug.


Dear maintainer,

Please find attached a final version of this patch for the time_t
transition. This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, 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)

diff -Nru vnlog-1.36/debian/changelog vnlog-1.36/debian/changelog
--- vnlog-1.36/debian/changelog 2024-01-09 05:22:52.000000000 +0000
+++ vnlog-1.36/debian/changelog 2024-02-28 23:19:22.000000000 +0000
@@ -1,3 +1,10 @@
+vnlog (1.36-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition. Closes: #1063051
+
+ -- Steve Langasek <vorlon@debian.org> Wed, 28 Feb 2024 23:19:22 +0000
+
vnlog (1.36-4) unstable; urgency=medium

* More thorough "clean" (Closes: #1047392)
diff -Nru vnlog-1.36/debian/control vnlog-1.36/debian/control
--- vnlog-1.36/debian/control 2023-06-19 19:53:11.000000000 +0000
+++ vnlog-1.36/debian/control 2024-02-28 23:19:22.000000000 +0000
@@ -1,7 +1,7 @@
Source: vnlog
Priority: optional
Section: devel
-Build-Depends: debhelper-compat (= 11),
+Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 11),
mrbuild,
dh-python,
python3:any,
@@ -20,7 +20,10 @@
Vcs-Browser: https://salsa.debian.org/science-team/vnlog
Testsuite: autopkgtest-pkg-python

-Package: libvnlo

Hi. vnlog does not depend on time_t. Is it too late to stop this
update?

The abi-compliance-checker failure is here:

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libvnlog-dev/base/log.txt

That error message says what the problem is: you are not supposed to
#include vnlog.h directly. Instead you're supposed to use the
"vnl-gen-header" tool (also in the "libvnlog-dev" package) to produce
usable headers that themselves #include vnlog.h. For instance:

vnl-gen-header 'int w' 'uint8_t x' 'char* y' 'double z' > vnlog_fields_generated.h

If you then run vnlog_fields_generated.h (which, again, #includes
vnlog.h) through abi-compliance-checker, you'll see that it passes. vnl-gen-header doesn't support any time-related types, so this is y2k38
safe.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 28, 2024 at 04:47:39PM -0800, Dima Kogan wrote:

Hi. vnlog does not depend on time_t. Is it too late to stop this
update?

The abi-compliance-checker failure is here:

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libvnlog-dev/base/log.txt

That error message says what the problem is: you are not supposed to
#include vnlog.h directly. Instead you're supposed to use the "vnl-gen-header" tool (also in the "libvnlog-dev" package) to produce
usable headers that themselves #include vnlog.h. For instance:

vnl-gen-header 'int w' 'uint8_t x' 'char* y' 'double z' > vnlog_fields_generated.h

If you then run vnlog_fields_generated.h (which, again, #includes
vnlog.h) through abi-compliance-checker, you'll see that it passes. vnl-gen-header doesn't support any time-related types, so this is y2k38
safe.

If you are confident that it's y2k38 safe, feel free to revert the NMU
(which has already been uploaded but not yet accepted).

--
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXf2YwACgkQVo0w8yGy Ez1VNxAAnIR3kaLun6xVMk28gxg511+/K+hWZb68vbWTgsmqOVxWWxbTdiTVLk15 WkLMPKCk9aSSb2M9rBi840y9Kat0wWEy73CdBk/4Pz+BOnPhZNxkyAGPC1t9lmBR I2l35rnAYknIDdyu1iK+LcfqFn0I5mimCtpi5L0do6Hv2sNTFlSEJlxPvU+UXbV9 J68StTStTufhh95O2lTrP0keZvLFZadVqpifpNTj+pMZpEon/Ppdo1qliuQjdzlu femUIZMqjce2Vegar5jEHHKxeDOnkz+P1EP5zLo+NEtza0m+c45w3dVgbcsUbw2Z zq1hnhA77UILqkW+lB8ZvzRzF9htW8+ryorng4iOQJoXB0V1tZKbvIW2ARRWVLnO d84hAlpywhv+FoHdS5MQLT10HNifUcgm+VeG7gseKSrUmrOKzzH9/p0ay5L9FPzs npqmSn1EzHBRFUXXBHL8GSKWjBQ7Dw4lwbfa8sdwygXDXWX4bUhi6sSlpsgV7h+l 3b9JdcLtg4/i5lRwL3qkQAS6CWeC9KOoRXZUIEhGq9345M2HTXgbxrWlWzF8XmDX KvkI9qqv+hs1cTwD5D+2

On Wed, Feb 28, 2024 at 10:20:50PM -0800, Dima Kogan wrote:

Thanks for replying. I'll revert the changes.

... however, I will say it's very strange to ship a shared library,
that has a public shlibs file, and has a -dev package that depends on
it, but the headers shipped in that -dev package are NOT the
authoritative api for that library?

That's how I did it, and while it sounds odd, I believe this is right.
The public interface is

vnl-gen-header ... > generated.h

and

#include "generated.h"

The generated header contains some user-facing macros that call the
functions in vnlog.h with specific arguments. That's the API. From the compiler's perspective, the functions declared in vnlog.h are the
interface, and the ABI in those symbols must be stable, and putting them
into the .symbols file is appropriate. Let me know if I'm doing
something wrong.

What I'm unclear on is why you don't run vnl-gen-header at build time and output the "generated" header in the -dev package with a comprehensive description of all the ABI entry points?

--
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXgJDUACgkQVo0w8yGy Ez1wgxAAurphZbW1xoblYbf1QxEs8I25CHOdPfyDACR1rEGR88ayVCncwJFnogQX o+RJZXRJj0B7iHH6vQXIy8Ic3z2cgOm3MfVLdNkaeqR5VmCjCS3xyiOU3sVbYnm8 aNW0z6318KxOOPtgJqqzTzedw5QnSmHyJIyY8pMmqVVvj4vUttDn7L5DKdpO0bKk 2MuhIFqq9pma4x3ms8/Lqi4yYLwYiXp/OeKl1ssWnMpEg+uXMt95Ms+oSRHPg4XK rWerdEjjc2sazcowCPitkhfmmUIZ8FEnptGwbB6Rc7poz2sUezUycICMZSiPXxkp N/IDi/l43K7xd11zVjRLeEzTmYZ9ilOxNgUSc4PEf5EemyNeLdPdEAiyjqywwPkf VDz7iSejigTUywi1N3LdccVanaPF+9EQ0XRcUmX4SK0M2hYoC5nXqaEr+OBGfo5i HWoUdso/utMwYZvVEMys75B/qD4ajv52Nh2iJbAHDniU4PE2wG9Vq4Fkl0StLhLR Lc2sH7YIG35jRqY90wGKne6ES4WO+zc0x4CTThFDZnILFtmdDBK/0nlXc/w3Cvr6 rHv1h9uO3sRyEK2I7bdy

Thanks for replying. I'll revert the changes.

... however, I will say it's very strange to ship a shared library,
that has a public shlibs file, and has a -dev package that depends on
it, but the headers shipped in that -dev package are NOT the
authoritative api for that library?

That's how I did it, and while it sounds odd, I believe this is right.
The public interface is

vnl-gen-header ... > generated.h

and

#include "generated.h"

The generated header contains some user-facing macros that call the
functions in vnlog.h with specific arguments. That's the API. From the compiler's perspective, the functions declared in vnlog.h are the
interface, and the ABI in those symbols must be stable, and putting them
into the .symbols file is appropriate. Let me know if I'm doing
something wrong.

Thanks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)