#1146800 timg: ftbfs with openslide 4.0.1 in experimental

Package:
libopenslide-dev
Source:
libopenslide-dev
Description:
Development files for the OpenSlide library
Submitter:
Étienne Mollier
Date:
2026-09-06 18:33:01 UTC
Severity:
normal
Tags:
#1146800#5
Date:
2026-09-05 17:37:47 UTC
From:
To:
Dear Maintainer,

timg currently fails to build from source against openslide
4.0.1 in experimental with the following error:
-------8<--------------8<--------------8<--------------8<-------
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@
                debhelper-compat (= 13),
                libavdevice-dev,
                libdeflate-dev,
+               libdicom-dev,
                libexif-dev,
                libpoppler-glib-dev,
                libgraphicsmagick++-dev,
@@ -13,6 +14,7 @@
                libpng-dev,
                libqoi-dev,
                libsixel-dev,
+               libsqlite3-dev,
                librsvg2-dev,
                libswscale-dev,
                libturbojpeg-dev,
-------8<--------------8<--------------8<--------------8<-------

Note that the bug will become serious once openslide 4.0.1 will
be uploaded to unstable.

In hope this helps,
Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier@debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-

#1146800#10
Date:
2026-09-05 17:49:25 UTC
From:
To:
Hi Étienne,

If this is a dependency required by openslide, shouldn't it be declared by openslide?
The error message suggests that and looking into the pkgconfig file too,
so I guess the correct way is to have libopenslide-dev Depends: on those libraries,
or are I am missing something?

Cheers,
--
tobi

#1146800#23
Date:
2026-09-05 18:03:05 UTC
From:
To:
Hi Tobias,

Tobias Frost, on 2026-09-05:

The other reverse dependencies didn't run into such error
conditions, so I thought they would be optional and only needed
for certain code paths of the library; perhaps I should have
them Recommended for general use.  If you still believe that
would be better sorted in libopenslide-dev, then feel free to
reaffect the bug and I'll proceed to the necessary adjustments.

Have a nice day,  :)

#1146800#28
Date:
2026-09-05 18:15:16 UTC
From:
To:
Hi again,

Étienne Mollier, on 2026-09-05:

Oh, I missed the point about the .pc file and the reaffectation.
I'm going ahead, thanks for your remark!

Have a nice day,  :)

#1146800#33
Date:
2026-09-05 18:48:57 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
openslide, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1146800@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Étienne Mollier <emollier@debian.org> (supplier of updated openslide package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 05 Sep 2026 20:22:16 +0200
Source: openslide
Architecture: source
Version: 4.0.1+dfsg-1~0exp3
Distribution: experimental
Urgency: medium
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Changed-By: Étienne Mollier <emollier@debian.org>
Closes: 1146800
Changes:
 openslide (4.0.1+dfsg-1~0exp3) experimental; urgency=medium
 .
   * d/control: remove build dependency on cmake and libgdk-pixbuf-2.0-dev.
     Thanks to Benjamin Gilbert
   * d/control: add myself to uploaders.
   * d/control: complement libopenslide-dev dependencies.
     libopenslide-dev depends on libdicom-dev and libsqlite3-dev.  This
     fixes build failures affecting reverse build dependencies due to new
     requirements of openslide. (Closes: #1146800)
Checksums-Sha1:
 cafd6a0612643169d503e5c54f8910395d138226 2656 openslide_4.0.1+dfsg-1~0exp3.dsc
 5dd74eab6a5320455c14a97f6ed17df1848b8b3c 20784 openslide_4.0.1+dfsg-1~0exp3.debian.tar.xz
 b0f2a3437ad56921147c0640f379b527b2ede563 10766 openslide_4.0.1+dfsg-1~0exp3_amd64.buildinfo
Checksums-Sha256:
 9036257b3839e7e36343d53e6b7add748ce87d2494313522fd27679c95b17955 2656 openslide_4.0.1+dfsg-1~0exp3.dsc
 2c6a49485df1a71d71d1de46bd535066f0b786ebb86f4695682cb3230cc8e3f9 20784 openslide_4.0.1+dfsg-1~0exp3.debian.tar.xz
 f6dfefe1eb873f205d32000b36d5d8992b428dfd9a944266a451c7ee11679000 10766 openslide_4.0.1+dfsg-1~0exp3_amd64.buildinfo
Files:
 df7c181a2ee009c423839af96ad3dc88 2656 libs optional openslide_4.0.1+dfsg-1~0exp3.dsc
 8d0837a94f59c280842d05013c731b93 20784 libs optional openslide_4.0.1+dfsg-1~0exp3.debian.tar.xz
 5bc87ddb854f641cb635f6f08004465e 10766 libs optional openslide_4.0.1+dfsg-1~0exp3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmqcYCcUHGVtb2xsaWVy
QGRlYmlhbi5vcmcACgkQeTz2fo8NEdoSlA/8DEEWQ68G6iLJpEBsLs3nBJQtbP07
Qg+Wt4lQZQB/Jlr4M6J0wqH3UzuZV6ky4aqhfw/efMByflSmQQtfFKoSWcNLmH9g
K0e74n+RS4x3HBymtRuaEhiZGVu371T0/8ErR4bDiyjoN3loRBYAsWaVlh0K0tjE
kOYUQc3OCIFdJo5FF+HNFOOw+4tdCmEoVFgKr/Avn0juN6fxlkzleyySPiNHoIlZ
EVgGD+BZPc7uO0700Aau648Qu2SIu7D9wZIYzBB0Ie6DdjY5e4PO9njt5L+tn9tk
nna+yyAI7c1ba0UUeKuNOT8KRNqw7BK3sZVCWU6NKVBLzwBT0jBJsdzkqOsvpTlw
w5V9gae7KFeU3R6Xv7A1LHf+9w/p7yQHfwj/gRsvNsPNdmyC947uj2k++qXAtTl4
bT86hGPdO2I/kpaKxGm5JV3HuTF/PqnCwghlav/VHU1JBb1H21OuDIS/1GtYgZv7
SCUdfiiAvRozt20EI/Ja04kUwCzfmi1M6s2weHpw4O2fO1vpLcn8cx8E8Du2BEEf
a73K7nfurDOW7xOiHgBY3z73ex+BSZ7kK3WhPFzSHtKvwS6+H7H0Zvk4I4givsid
kOR7RYlk3JlRBbTQ3qwbN8AiF8SpncXdjLSNoFp30iactWWy+0H2KK/nhCXNndgc
L03YgawyMKkAIEk=
=UQe/
-----END PGP SIGNATURE-----

#1146800#38
Date:
2026-09-05 20:37:22 UTC
From:
To:
The fix in 4f724835ef doesn't make sense to me.  OpenSlide doesn't expose
any of its dependencies in its own headers, so there's no reason that
specifically libdicom-dev and libsqlite3-dev should be dependencies of
libopenslide-dev.  This is just the usual problem that pkg-config uses
Requires.private to mean both "packages needed for static linking" and
"packages needed for header inclusion", which are very different lists.
Surely the same logic should be applied to all OpenSlide -dev dependencies,
one way or the other?

$ pkg-config --libs openslide
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glib-2.0', required by 'openslide', not found
Package 'gio-2.0', required by 'openslide', not found
Package 'gobject-2.0', required by 'openslide', not found
Package 'cairo', required by 'openslide', not found
Package 'libdicom', required by 'openslide', not found
Package 'sqlite3', required by 'openslide', not found
Package 'libxml-2.0', required by 'openslide', not found
Package 'libtiff-4', required by 'openslide', not found
Package 'libopenjp2', required by 'openslide', not found
Package 'libjpeg', required by 'openslide', not found
Package 'libpng', required by 'openslide', not found
Package 'zlib', required by 'openslide', not found
Package 'libzstd', required by 'openslide', not found

#1146800#43
Date:
2026-09-06 09:09:51 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
openslide, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1146800@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Étienne Mollier <emollier@debian.org> (supplier of updated openslide package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 06 Sep 2026 10:46:05 +0200
Source: openslide
Architecture: source
Version: 4.0.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Changed-By: Étienne Mollier <emollier@debian.org>
Closes: 1099727 1146800
Changes:
 openslide (4.0.1+dfsg-1) unstable; urgency=medium
 .
   * Migrate openslide 4.0.1 to unstable for auto-openslide transition.
 .
 openslide (4.0.1+dfsg-1~0exp3) experimental; urgency=medium
 .
   * d/control: remove build dependency on cmake and libgdk-pixbuf-2.0-dev.
     Thanks to Benjamin Gilbert
   * d/control: add myself to uploaders.
   * d/control: complement libopenslide-dev dependencies.
     libopenslide-dev depends on libdicom-dev and libsqlite3-dev.  This
     fixes build failures affecting reverse build dependencies due to new
     requirements of openslide. (Closes: #1146800)
 .
 openslide (4.0.1+dfsg-1~0exp2) experimental; urgency=medium
 .
   * Team upload.
 .
   [ Nilesh Patra ]
   * d/t/get-test-data: Change tar to xz; improve the script
 .
   [ Étienne Mollier ]
   * New upstream version 4.0.1+dfsg
     The new version addresses CVE-2026-54604.  (Closes: #1099727)
   * CVE-2026-48977.patch: delete: fixed upstream.
   * d/control: move to meson build system.
     The change also introduced an extra dependency on cmake.
   * d/control: build depends on libdicom-dev.
   * d/rules: remove now unneeded configure option.
   * d/docs: update README's name.
   * Transition to libopenslide1.
   * d/t/run-unit-test: update to new sample data.
   * d/copyright: complement entries after copyright review.
Checksums-Sha1:
 9cfa3d4c4e7b2a9108071e4142e8d0c155952188 2752 openslide_4.0.1+dfsg-1.dsc
 f4ca0e0a9264c0df9fb8f1fdbab8f9c8104baac9 20796 openslide_4.0.1+dfsg-1.debian.tar.xz
Checksums-Sha256:
 b3561004d6df631ce5ae26d893d3112adfaf7148d248a90a32508c316f4a2c1f 2752 openslide_4.0.1+dfsg-1.dsc
 83f25617a9205b1850cd654012d7b63712375a5617fc24d6e76df5d4cf7ec60f 20796 openslide_4.0.1+dfsg-1.debian.tar.xz
Files:
 2581e0c54f5571088d4a6fc9f4d8b751 2752 libs optional openslide_4.0.1+dfsg-1.dsc
 6d4c8cef5127e9afa09fc7069846482c 20796 libs optional openslide_4.0.1+dfsg-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmqdKhIUHGVtb2xsaWVy
QGRlYmlhbi5vcmcACgkQeTz2fo8NEdp6EQ/9ERi5+APVZOqjztjVb/kQFtekL6Br
oIfIT66dPFynCtbet8tOh8odlC0p9w+MkxH3A8PLvUneDcF3QY/pExuyc9rtFnJo
kQ2VDfgRrgKDHRKDAAMB2RikTAM+AgwBFvXvLyOv1EQjMSnjX8LxsyqzN5PgJgKr
k31P9rP9hCmVGg2ZXe8REn92pqaTp087zcK5y1/U2v8Do7hYsJnhlQdq7HGa9XCX
QyiTtFh7cKPweI0IAOmuTzvUbPfROCstoAA1KRnv754oVQ950ur2/6jh2zWAiblX
apn+m960SO2cqeVgajs36TkNWXXSRe26Dq+KEmdOxE6OiwPO/ojdsV6HIdWryclw
yrDTi91g/pDuS9ZLRrZpYwFjgKlCDb7vhyOzitng7XDb3K2djcBW0CbTaTl9dVaD
n+lQGwVK+tWZ8/KCHZ8QtyEmhRtHxOajzNxOWaXGFyD+TUR7EjlbS96W464NctZ8
q+o5CJ2iC55cxooobPI8GKvdvMDQRL9+khWj/NQ2Ek7isY7gSDyvcRRvH26ttcAK
Gu0oB6faCBE3X9xKdcGvmk14BMXvTB06ed3ay7my589v5GLeHMYd0SwuqhcQpOl/
zDI/LOWV4lAcfXRTI6fqW+nJBfpllK0GEoxQ0UZbTX2pJ0dbCmaRZRXDUIYuhM5z
vpiUEuX0fPQdyrM=
=NCBf
-----END PGP SIGNATURE-----

#1146800#48
Date:
2026-09-06 09:22:35 UTC
From:
To:
Hi Benjamin, Hi Tobias,

Benjamin Gilbert, on 2026-09-05:

Thanks for your remark, right now I'll stick to focusing on the
transition coordinated in #1146803, so that CVE-2026-54604
finally gets resolved.  In this context, 4f724835ef is mostly a
fix/workaround to avoid jamming the transition on build failure
of timg.

Longer term, I would lean toward my initial idea that pulling
the extra components would be the responsibility of the reverse
dependencies, depending on their build requirements, be it due
to real usage of the headers, or due to constraints caused by
the build management system.  I may be conflating two distinct
issues here, but the situation feels reminescent of #826048
affecting gdcm.  I'm not sure how you would want to move next:

  * the current situation is probably weird but okay for now;
  * I still believe complementing timg build dependencies would
    be appropriate, even if my actions from yesterday don't well
    reflect that;
  * I won't get in the way of complementing libopenslide-dev
    dependencies if you believe this is the right approach, in
    which case I'm okay to tackle a dedicated bug or apply a
    patch.

What do you gentlemen think?

Have a nice Sunday,  :)

#1146800#53
Date:
2026-09-06 16:37:24 UTC
From:
To:
Thanks for the context.  If I'm understanding #826048 correctly, that
bug describes non-fatal warnings about optional dependencies.  Here,
the additional -dev packages are necessary for libopenslide-dev to be
useful at all, so it seems to me that libopenslide-dev should add
dependencies on them.  I've filed #1146883 to discuss further.

#1146800#58
Date:
2026-09-06 17:17:39 UTC
From:
To:
Hi Benjamin,

Benjamin Gilbert, on 2026-09-06:

Thanks, let's continue there.

Have a nice day,  :)

#1146800#63
Date:
2026-09-06 17:51:03 UTC
From:
To:
Am Sun, Sep 06, 2026 at 11:22:35AM +0200 schrieb Étienne Mollier:

Let me try debugging it:

openslide declares dependencies e.g. on sqlite in its package file. timg is not
using sqlite at all. It is openslide that is requiring this dependency (and
grepping timg source for sqlite yields an empty result, while for openslide it
does not).

Possibly the pc file shouldn't declare a dependency on sqlite if it does not
need it? Maybe the bug is with the pc file?

It might also be a bug with CMake's pkg_check_modules, but CMake upstream seems
to disagree: https://gitlab.kitware.com/cmake/cmake/-/work_items/25692

Let's see what stock pkgconfig does (this is in a pbuilder chroot with timg
build-deps installed):

pkgconf --libs openslide ; echo result: $?

Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glib-2.0', required by 'openslide', not found
Package 'gio-2.0', required by 'openslide', not found
Package 'gobject-2.0', required by 'openslide', not found
Package 'cairo', required by 'openslide', not found
Package 'libdicom', required by 'openslide', not found
Package 'sqlite3', required by 'openslide', not found
Package 'libopenjp2', required by 'openslide', not found
result: 1

And this isn't specific to --libs:

root@gondor:/tmp/buildd/timg-1.5.2# pkgconf --cflags openslide ; echo $?

Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glib-2.0', required by 'openslide', not found
Package 'gio-2.0', required by 'openslide', not found
Package 'gobject-2.0', required by 'openslide', not found
Package 'cairo', required by 'openslide', not found
Package 'libdicom', required by 'openslide', not found
Package 'sqlite3', required by 'openslide', not found
Package 'libopenjp2', required by 'openslide', not found
result: 1

So pkgconfig is unhappy, regardless of timg.

I think the .pc file is wrong, or pkgconfig does some weird stuff. I thought
Requires.private was only supposed to matter for static linking, so I'm not
sure why pkgconfig is trying to resolve these dependencies for a normal
--cflags/--libs query.

To make sure this isn't somehow specific to timg, I made a minimal OpenSlide
test program:

#include <stdio.h>
#include <openslide/openslide.h>

int main(void)
{
printf("OpenSlide version: %s\n", openslide_get_version());
return 0;
}

It fails to compile/link with:

cc -o openslide-test openslide-test.c $(pkg-config --cflags --libs openslide)

because pkg-config fails to resolve the dependencies above.

However, the exact same program links fine when using the library directly:

cc -o openslide-test openslide-test.c -lopenslide

So I don't think this is a timg issue. The OpenSlide library itself is linkable
and its headers work; it is specifically the pkg-config metadata/resolution
which is causing the failure.

Looking at the generated openslide.pc, the relevant part is:

Requires.private: glib-2.0 >= 2.56, gio-2.0, gobject-2.0, cairo >= 1.2, libdicom >= 1.3.0, sqlite3 >= 3.14, libxml-2.0, libtiff-4, libopenjp2 >= 2.1.0, libjpeg, libpng > 1.2, zlib, libzstd

There is a distinction here between Requires.private and Libs.private: the
former is precisely where dependencies which are only relevant to the
implementation are normally expressed. So I don't think simply adding all these
-dev packages to libopenslide-dev is necessarily the right solution either.

timg doesn't use sqlite. It is only indirectly depending on it through
OpenSlide's pkg-config metadata.

I'd therefore suggest that we first determine why pkgconf is resolving
Requires.private for a normal query, and whether the OpenSlide .pc file is
appropriate for Debian's pkgconf semantics, rather than adding OpenSlide's
entire set of private build dependencies to libopenslide-dev.

#1146800#68
Date:
2026-09-06 18:04:23 UTC
From:
To:
PS:
https://github.com/pkgconf/pkgconf/issues/300
https://github.com/pkgconf/pkgconf/issues/352

might be what's going on.
Upstream pkgconfig updated their docs in
https://github.com/pkgconf/pkgconf/pull/353

so I guess, everything whats in required.private nees a dependency in
openslide. 
The question is if openslide should list those in required.private,
not sure. they might be needed for static linking, but does openslide
ship a static library?

#1146800#73
Date:
2026-09-06 18:12:19 UTC
From:
To:
This is a longstanding shortcoming of pkg-config.  I fully agree that
the ecosystem should distinguish between header dependencies and
library dependencies needed for static linking, but it doesn't, and a
lot of electrons have been spilled trying to get the pkgconf
maintainers to support this use case.  As things stand, openslide.pc
is properly declaring its dependencies for static linking, which
necessarily causes the header dependencies to balloon out of control.

(OpenSlide doesn't make this decision directly; it delegates to
Meson's support for generating .pc files.)

#1146800#78
Date:
2026-09-06 18:31:50 UTC
From:
To:
Hi gents,

Thanks for your analysis, I'm convinced and will upload the full
fix soon.

Have a nice day,  :)