Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
[László Böszörményi] > You are right that removing public symbols from a library interface > is an ABI break and requires a SONAME change. Per coding standards > function names starting with underscore are part of the private API > and a) not to be used outside of the library, b) if used nevertheless, > it's accepted that the other code can break anytime. Which coding standards? I believe the Debian policy require SONAME changes when the ABI break. Did I misunderstand? > First of all, critical is used for several issues like making the > system unbootable or causing huge data loss. That's not the case. I base my understanding on https://www.debian.org/Bugs/Developer#severities >, which state the following for critical: * critical - makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. My observation is that the libtiff change 'made unreleated software on the system break', making this a bug with severity 'critical'. > What you proposed is to diverge from tiff upstream and adding back the > mentioned function, then forcing a SONAME change, doing a transition > with over two hundred code rebuilds on fourteen architectures. This > makes no sense. To me it is the only approach that make sense when the ABI is broken. > As noted above, the Python Tk library copies an internal tiff function > and probably not just one but a whole set of those (just check its > compat/libtiff/libtiff source directory). Note, I do not try to defend the libtk-img developers. To me their behaviour is beside the point, which is that the tiff ABI broke (a public symbol was removed) and the SONAME as not bumped. -- Happy hacking Petter Reinholdtsen
Bug#1012825: Removed symbol without major SONAME bump
Control: merge 1013877 1013878 On Sun, Jun 26, 2022 at 2:18 PM László Böszörményi (GCS) wrote: > See the attached patch, basically it's a one liner. Sergei just needs > to add it to the libtk-img package source. Then it's just one bug, sorry for the duplication. As soon as Sergei uploads this fix, linuxcnc will work again as well. Just a note that tiff will no longer export its private functions, breaking libtk-img entirely. Of course, tiff upstream reported it for libtk-img. See its bug tracker [1]. Hope this helps, Laszlo/GCS [1] https://sourceforge.net/p/tkimg/bugs/109/
Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
Control: tags 1012825 -patch
Control: clone 1012789 -1
Control: reassign -1 libtk-img
Control: retitle -1 libtk-img: add _TIFFsetString to its internal tiff library
Control: tags -1 +patch
On Sat, Jun 25, 2022 at 5:07 PM Petter Reinholdtsen wrote:
> While it might sound sensible on the surface, the realities is that the
> libraries binary interface (aka ABI) changed, removing a public symbol
> from the library. Such API change require a no major SONAME number to
> avoid breaking programs using the library.
You are right that removing public symbols from a library interface
is an ABI break and requires a SONAME change. Per coding standards
function names starting with underscore are part of the private API
and a) not to be used outside of the library, b) if used nevertheless,
it's accepted that the other code can break anytime.
> It is not linuxcnc-uspace that is using it. It is the tcl/tk Img
> library. To test for yourself, try running 'wish' and give it the
> 'package require Img' command to load the Img library. linuxcnc do the
> equivalent loading, but using the python Tk library.
Yup, I was tricked by the bug reports. . In this case, the Python Tk
library must follow the internal change of tiff.
> Removing the symbol without bumping the SONAME made it impossible for
> programs using the symbol to keep the old working library version. This
> was the ratinale for my severity setting critical. Given that the
> symbol removal without bumping SONAME broken libtk-img and linuxcnc,
> what is your argument for lowering the severity to normal?
First of all, critical is used for several issues like making the
system unbootable or causing huge data loss. That's not the case. Then
as noted above, projects using others internal structures and/or
functions must follow that when the latter changes.
What you proposed is to diverge from tiff upstream and adding back the
mentioned function, then forcing a SONAME change, doing a transition
with over two hundred code rebuilds on fourteen architectures. This
makes no sense.
As noted above, the Python Tk library copies an internal tiff function
and probably not just one but a whole set of those (just check its
compat/libtiff/libtiff source directory). It must accept to follow
tiff development and act on such changes. Especially that the
mentioned removed function is a one liner, being a wrapper for another
function. If libtk-img needs that function, right. Copy it to their
code like it copied others already.
See the attached patch, basically it's a one liner. Sergei just needs
to add it to the libtk-img package source.
Regards,
Laszlo/GCS
Description: add _TIFFsetString function for being removed from tiff
The _TIFFsetString private function was internal of tiff and removed in
tiff 4.4.0+ versions. As Tk library used it in its source, copy the function
to its source.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-06-25
---
--- libtk-img-1.4.13+dfsg.orig/compat/libtiff/libtiff/tif_unix.c
+++ libtk-img-1.4.13+dfsg/compat/libtiff/libtiff/tif_unix.c
@@ -352,6 +352,12 @@ _TIFFmemcmp(const void* p1, const void*
return (memcmp(p1, p2, (size_t) c));
}
+void
+_TIFFsetString(char** cpp, char* cp)
+{
+ _TIFFsetByteArray((void**) cpp, (void*) cp, strlen(cp)+1);
+}
+
static void
unixWarningHandler(const char* module, const char* fmt, va_list ap)
{
Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
[László Böszörményi] > As noted by libtiff upstream as well, this function was internal of > tiff and its declaration was in a header file that was not installed > publicly. They could change that without prior notice. While it might sound sensible on the surface, the realities is that the libraries binary interface (aka ABI) changed, removing a public symbol from the library. Such API change require a no major SONAME number to avoid breaking programs using the library. > If linuxcnc-uspace still wants to use it, then copy that function[1] > and its details to their source tree. They already done copying with > the _TIFFsetString() function declaration. Then I can add a break for > its older versions for tiff. It is not linuxcnc-uspace that is using it. It is the tcl/tk Img library. To test for yourself, try running 'wish' and give it the 'package require Img' command to load the Img library. linuxcnc do the equivalent loading, but using the python Tk library. Removing the symbol without bumping the SONAME made it impossible for programs using the symbol to keep the old working library version. This was the ratinale for my severity setting critical. Given that the symbol removal without bumping SONAME broken libtk-img and linuxcnc, what is your argument for lowering the severity to normal? -- Happy hacking Petter Reinholdtsen
Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
Control: tags 1012825 patch Control: severity 1012825 normal Control: unblock 1012789 by 1012825 On Fri, Jun 24, 2022 at 11:57 AM Petter Reinholdtsen wrote: > Until upstream decide to reinsert the symbol or bump the SONAME, I > suggest to carry this patch. It should get the broken packages in > Debian working again. As noted by libtiff upstream as well, this function was internal of tiff and its declaration was in a header file that was not installed publicly. They could change that without prior notice. If linuxcnc-uspace still wants to use it, then copy that function[1] and its details to their source tree. They already done copying with the _TIFFsetString() function declaration. Then I can add a break for its older versions for tiff. Regards, Laszlo/GCS [1] https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_dir.c#L43
Bug#1012825: Removed symbol without major SONAME bump
Control: tags -1 + patch
Until upstream decide to reinsert the symbol or bump the SONAME, I
suggest to carry this patch. It should get the broken packages in
Debian working again.
diff -ur tiff-4.4.0/libtiff/tif_dir.c tiff-4.4.0-new/libtiff/tif_dir.c
--- tiff-4.4.0/libtiff/tif_dir.c2022-05-20 18:15:09.0 +0200
+++ tiff-4.4.0-new/libtiff/tif_dir.c2022-06-24 10:45:10.465540590 +0200
@@ -56,6 +56,8 @@
}
void _TIFFsetByteArray(void** vpp, const void* vp, uint32_t n)
{ setByteArray(vpp, vp, n, 1); }
+void _TIFFsetString(char** cpp, char* cp)
+{ setByteArray((void**) cpp, (void*) cp, strlen(cp)+1, 1); }
static void _TIFFsetNString(char** cpp, const char* cp, uint32_t n)
{ setByteArray((void**) cpp, cp, n, 1); }
void _TIFFsetShortArray(uint16_t** wpp, const uint16_t* wp, uint32_t n)
diff -ur tiff-4.4.0/libtiff/tiffiop.h tiff-4.4.0-new/libtiff/tiffiop.h
--- tiff-4.4.0/libtiff/tiffiop.h2022-05-20 18:15:09.0 +0200
+++ tiff-4.4.0-new/libtiff/tiffiop.h2022-06-24 10:45:40.709737278 +0200
@@ -340,6 +340,7 @@
extern uint32_t _TIFFDefaultStripSize(TIFF* tif, uint32_t s);
extern void _TIFFDefaultTileSize(TIFF* tif, uint32_t* tw, uint32_t* th);
+extern void _TIFFsetString(char**, const char*);
extern void _TIFFsetByteArray(void**, const void*, uint32_t);
extern void _TIFFsetShortArray(uint16_t**, const uint16_t*, uint32_t);
extern void _TIFFsetLongArray(uint32_t**, const uint32_t*, uint32_t);
In addition the debian/libtiff5.symbols file will need an update.
--
Happy hacking
Petter Reinholdtsen
Bug#1012825: Removed symbol without major SONAME bump
Control: severity -1 critical [Håvard F. Aasen] > It was actually a bug [1] in linuxcnc that made me look. Then it was just > to search for the library that previously had that symbol. > Should probably have reported back with my findings. Aha. I have linked the two bugs together now, to allow BTS to track the two alongside each other. As this bug make the linuxcnc package fail to start, ie 'make unreleated software on the system break', I believe the correct severity for this issue is critical. Note, in the upstream bug there seem to be reluctance to both reinsert the symbol and bump the SONAME, claiming programs using this symbol should be changed instead. It seem like a good idea in any case to fix libtk-img, but that would be independent of the need for a SONAME bump due to the ABI change. -- Happy hacking Petter Reinholdtsen
Bug#1012825: Removed symbol without major SONAME bump
Control: forwarded -1 https://gitlab.com/libtiff/libtiff/-/issues/437 Nasty issue. I created an issue upstream about it. How did you discover the problem? Can it be automatically detected in a autopkgtest script? -- Happy hacking Petter Reinholdtsen
