#1151226 libiir-dev: cmake fails reporting unable to find .a file

Package:
libiir-dev
Source:
libiir-dev
Description:
DSP IIR realtime filter library - development files
Submitter:
Nick Bailey
Date:
2026-10-20 18:25:02 UTC
Severity:
normal
#1151226#5
Date:
2026-10-18 13:35:02 UTC
From:
To:
Dear Maintainer,

   * What led up to the situation?
Attempt to build source and linking lib11r1

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
Buiding the library from the upstream source or installing the version in testing are both effective remedies.

   * What was the outcome of this action?
A small test program builds perfectly when upstream source is used, but cmake fails when libiir-dev and libiir1-dev are installed from stable

   * What outcome did you expect instead?
It seems that the packaged cmake scripts expect to find a .a file, but that this file is not included in the package.
If this is the case, either it should be included, or the cmake files be adjusted to reflect that it is not.
I can apparently resolve this by installing v.1.10 from testing, but am reluctant to mix packaged from different sources on production machines.

#1151226#10
Date:
2026-10-19 07:00:37 UTC
From:
To:
Hi Nick,

Thanks for reporting this. I believe this is the same issue as
https://bugs.debian.org/1125282 but I want to make sure before merging the
bugs. This bug is reported against 1.10.0+dfsg-4+b1; but from the
description, I understand that it affects 1.9.5+dfsg-1 (the version in
stable) and does *not* affect 1.10.1+dfsg-4 (the version in testing), is that
correct?

I’ve asked for a stable update to fix this in stable too.

Regards,

Stephen

#1151226#15
Date:
2026-10-19 13:54:59 UTC
From:
To:
Yes, sorry to have missed that duplicate report. Bernd (who is the main dev on
this library -- i've copied this to him) asked me to check out the stable
package because he'd had reports that it would break compilation. Indeed it
does. 1.10 in testing is fine. Building from upstream on stable is fine. And
installing a downloaded deb from a testing repo on stable with dpkg is also
fine.

I'm not sure if you are deciding to remove .a archives from binary packages as
a matter of policy? I don't have an axe to grind about that, but the upstream
expects it to be there. Hence, I strongly suspect, the cmake error. It
essentially stops the dev package in testing being useful to anybody wanting
to develop with it.

Thanks for getting back so quickly!

Nick/.

#1151226#20
Date:
2026-10-20 10:35:44 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
iir1, 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 1151226@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stephen Kitt <skitt@debian.org> (supplier of updated iir1 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: Tue, 20 Oct 2026 12:21:21 +0200
Source: iir1
Architecture: source
Version: 1.10.0+dfsg-6
Distribution: unstable
Urgency: medium
Maintainer: Stephen Kitt <skitt@debian.org>
Changed-By: Stephen Kitt <skitt@debian.org>
Closes: 1151226
Changes:
 iir1 (1.10.0+dfsg-6) unstable; urgency=medium
 .
   * Ship the static libraries. Closes: #1151226.
Checksums-Sha1:
 7e7596b996d63c15e285b9834e4456b0b9701151 1972 iir1_1.10.0+dfsg-6.dsc
 17a199c3e3529671bc64e6aabe880d0ce684de41 3924 iir1_1.10.0+dfsg-6.debian.tar.xz
 3d2903b244361689e37a14aa9874cf6daed9ccc4 7461 iir1_1.10.0+dfsg-6_source.buildinfo
Checksums-Sha256:
 34d1c1f01cf1abc0d94f0cf333113baab872ef7d066ee50f75d12beb345ceb91 1972 iir1_1.10.0+dfsg-6.dsc
 7cc052d989cc546158846a5372365ad5d468071427fc1cffbfd5c63db0e2feb6 3924 iir1_1.10.0+dfsg-6.debian.tar.xz
 90ff7f75aed8cb0e6abc6d79427e2bf14ef855e3dcc037b3bc1793dc26b607b1 7461 iir1_1.10.0+dfsg-6_source.buildinfo
Files:
 573aeef1cd0a6679f861c080d8a0074e 1972 libs optional iir1_1.10.0+dfsg-6.dsc
 97cf8c9947b0c76a80755a0596f6d1e9 3924 libs optional iir1_1.10.0+dfsg-6.debian.tar.xz
 2846fe70fe2910ee0d919e5b4ed92253 7461 libs optional iir1_1.10.0+dfsg-6_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmrXQPEACgkQgNMC9Yht
g5xI+Q//YHYbZ8X0Hd3JgSdoJUIE0LAAL1I14rDD6bFORDTX+1PPGhxZhCreVh5n
veNDeiXbMyMPP+eFmD+WNAkzcWtYCycMZN0jRe1LRqv1xfWl4OoROrnOkG8FVcX/
cOBbYLGwGUnqdOGc9ydRUBB2c61IBDnfHxqLaBM9DF86lcT8HwTVsVWhn6qeguT8
7DL+8Tf9O4vDAdADsGvfEbJXjiRgriCE/WAu3OllWfqG9dKXdePJpE9mYypw5/jc
J2NRlbSbassxCvrzjQZZdDGHar3Nix3zro1olQbCpEkvajwhR9Zd0WxFSRUsCdm7
AtO1BsZdwXTk+vl4wijmVXVdphx85APHK910Zqn8Bk0LO8BarVtFKcNrnSDweejW
TJb5kKE/VGQdCvoodKCxhYerZhtoxmVp88QBvB1+CCBYysKv6p9y5I2BbpkLsPad
Xj2OWkYb5+rgppEbkFTemLmbASHvjPlxid64Wem+DRnrmQpyXB/1WWrMi5UNHxKc
5CQI9Tilo4SOnW1rumj1qDyaDyuHTp480+zwtfCPwLTLKr+shJBPxUxADoXvIq4b
8lNdGwLNGzC2KAXFCLlfueOteiBDYHV06XAo0t5mHsUCSY4y6p5FV0RqUeOcGEBy
x3jEsW3b8pQqjCqntn/NmKwSRLpMJcaPPeo+0E2nDPx2S8CyUos=
=HLgH
-----END PGP SIGNATURE-----

#1151226#25
Date:
2026-10-20 18:24:09 UTC
From:
To:
No need to apologise, old bugs are hard to find and in any case it was useful
to hear from you about this issue.

In general I don’t package static libraries because we try to avoid using
them in Debian (they make bug fixes and security updates harder to ship,
since everything using them needs to be rebuilt). However there’s no policy
forbidding static libraries entirely, and if they’re useful to end users,
then it makes sense to ship them; so I’ve updated the package to do so.
You’ll see that appear in testing in a week’s time, and I’ll update my stable
update request to switch to that approach too.

Regards,

Stephen