Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0
gregor herrmann
Version: 2.9.2.1-2
Severity: grave
Justification: renders package unusable
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
While looking at some test issues in libpod-pandoc-perl, I noticed
that pandoc looks quite broken in current amd64/sid:
% pandoc --version
pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory
% echo $?
127
% apt-file search libcmark-gfm.so.0.29.0.gfm.0
libcmark-gfm0: /usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.0
% dpkg -l libcmark-gfm0
…
ii libcmark-gfm0:amd64 0.29.0.gfm.2-1 amd64 CommonMark GitHub flavor gfm library
% dpkg -L libcmark-gfm0
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.2
/usr/share
/usr/share/doc
/usr/share/doc/libcmark-gfm0
/usr/share/doc/libcmark-gfm0/changelog.Debian.gz
/usr/share/doc/libcmark-gfm0/changelog.gz
/usr/share/doc/libcmark-gfm0/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libcmark-gfm0
% ls -la /usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.2 /usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.0
ls: cannot access '/usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.0': No such file or directory
- -rw-r--r-- 1 root root 317688 Jan 18 01:43 /usr/lib/x86_64-linux-gnu/libcmark-gfm.so.0.29.0.gfm.2
So it looks like pandoc wants libcmark-gfm.so.0.29.0.gfm.0 but libcmark-gfm0
ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an issue in libcmark-gfm0
… Not sure where to fix this.
cmark-gfm (0.29.0.gfm.2-1) unstable; urgency=medium
* New upstream version.
* Fix for CVE-2020-5238. (Closes: #965984)
* Switch man page --safe to --unsafe. (Closes: #1003745)
-- Keith Packard <kei...@keithp.com> Mon, 17 Jan 2022 16:43:27 -0800
cmark-gfm (0.29.0.gfm.0-6) unstable; urgency=medium
* Use <stdbool.h> directly instead of "config.h". (Closes: #969212)
-- Keith Packard <kei...@keithp.com> Wed, 02 Sep 2020 10:25:33 -0700
Cheers,
gregor
- -- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'stable-security'), (500, 'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages pandoc depends on:
ii libc6 2.33-2
ii libcmark-gfm-extensions0 0.29.0.gfm.2-1
ii libcmark-gfm0 0.29.0.gfm.2-1
ii libffi8 3.4.2-4
ii libgmp10 2:6.2.1+dfsg-3
ii libpcre3 2:8.39-13
ii pandoc-data 2.9.2.1-2
ii zlib1g 1:1.2.11.dfsg-2
pandoc recommends no packages.
Versions of packages pandoc suggests:
pn citation-style-language-styles <none>
ii context 2020.03.10.20200331-1
pn ghc <none>
ii groff 1.22.4-8
pn libjs-katex <none>
ii libjs-mathjax 2.7.9+dfsg-1
ii librsvg2-bin 2.50.7+dfsg-2
pn nodejs <none>
pn pandoc-citeproc <none>
ii perl 5.32.1-6
pn php <none>
pn python <none>
pn r-base-core <none>
ii ruby 1:2.7.6
ii texlive-latex-extra 2021.20211217-1
ii texlive-latex-recommended 2021.20211217-1
ii texlive-luatex 2021.20211217-1
ii texlive-xetex 2021.20211217-1
pn wkhtmltopdf <none>
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmHm8/JfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaeqg//SynSrZ9ifms45FsFTw/25leWnr1rbeGLz3Xt+aRzfCqcS9gH21uEkXZZ
x1V0zUQlUMh0EtisO2cmQBqZGCzscCL4oHj7hRR3e1yzG4ONcptk0kzJBZK0UesD
0N+l0Q11fE2pVia7TG7kD3BF+FC9/JYobdiDYtIwrwxGBuVzch8xp1v6Vep+vow2
Zc3LUXF+cRyaVejMivVx4Gc1rfpkuZBwmkV5NbAUJ3NSLYsQEVoblBor9DS6BTTF
LyTPijwyWM808k3hVdoC/xFKNtpyMQuzkj4hTzqe7nVbLUEHYLPCzkywu0+5kTvU
cWCq+Z/XjPz0+lWoGrqaiKZ6PV54U+5iVB322ISUaWQA2isfIg/umOa9tBUA/mbd
KaS236uRP+rDwCP3AN0+sKBqhFzTZp7Hcr1BuUV+8cMK3FQB6lbU2u7w/wvFYqCG
eGdZ1FwYJ9HLwdGf3NdvVzwYR8QjMGwGW2L8NVjZsoL/0AQ8xMJsF004oinveVBy
WZIv4g29gvUfC7ac5GW3rPomaQygDJC0pqsqO3gCsD5HRwvoLAAkeWpRPRAimv4d
0MRKPWz7QvHtTZIUH+gxpjiICVEVJEdyYxGUq9qtFPil41rgBT+uFer4dUyt7bKr
yIsYn1SnB/PyhxkCJBPhRIpBQpCvbClpil9hKL3ODsEFjhCncXE=
=2b+J
-----END PGP SIGNATURE-----
Jonas Smedegaard
> that pandoc looks quite broken in current amd64/sid:
>
> % pandoc --version
> pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory
> libcmark-gfm0 ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an
> issue in libcmark-gfm0 … Not sure where to fix this.
blame for having too loose dependency on that inherently untameable
library package.
Thanks for reporting, Gregor - might be enough to request a binNMU but
I'd better tighten that dependency, so will do a regular upload.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
gregor herrmann
> Thanks for reporting, Gregor - might be enough to request a binNMU but
> I'd better tighten that dependency, so will do a regular upload.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
Jonas Smedegaard
> Control: reassign -1 src:cmark-gfm 0.29.0.gfm.2-1
> Control: retitle -1 cmark-gfm: shlibs too relaxed for unstable ABI
> Control: affects -1 pandoc blogliterately gitit pandoc-citeproc patat
[...]
> Hmm - thinking on it, it seems to me that the change really should be
> in the libcmark-gfm package - something like this (untested):
>
> override_dh_makeshlibs:
> dh_makeshlibs --version-info="libcmark-gfm0 (>= ${DEB_VERSION}), libcmark-gfm0 (<< ${DEB_VERSION}+)"
For cmark the above essentially worked - here is the complete changes:
https://salsa.debian.org/debian/cmark/-/commit/8be8eba
When applied, reverse dependencies need a binNMU...
John MacFarlane
A note from upstream, in case it's helpful: we haven't depended
on cmark-gfm since pandoc 2.10.1 (released a year and a half
ago). If you could move to a more recent version of pandoc, this
would avoid the problem entirely. I'm aware that issues of
policy and packaging may make this difficult, though.
Sebastian Ramacher
> Control: clone -1 -2
> Control: retitle -1 cmark-gfm: shlibs too relaxed for unstable ABI
> Control: affects -1 pandoc blogliterately gitit pandoc-citeproc patat
> Control: severity -2 important
> Control: retitle -2 cmark: shlibs too relaxed for unstable ABI
>
> Quoting Jonas Smedegaard (2022-01-18 18:40:33)
> > > that pandoc looks quite broken in current amd64/sid:
> > >
> > > % pandoc --version
> > > pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory
> > > libcmark-gfm0 ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an
> > > issue in libcmark-gfm0 … Not sure where to fix this.
> >
> > blame for having too loose dependency on that inherently untameable
> > library package.
> >
> > Thanks for reporting, Gregor - might be enough to request a binNMU but
> > I'd better tighten that dependency, so will do a regular upload.
>
> the libcmark-gfm package - something like this (untested):
>
> override_dh_makeshlibs:
> dh_makeshlibs --version-info="libcmark-gfm0 (>= ${DEB_VERSION}), libcmark-gfm0 (<< ${DEB_VERSION}+)"
The SONAME is:
$ objdump -x libcmark-gfm.so.0.29.0.gfm.2 | grep SONAME
SONAME libcmark-gfm.so.0.29.0.gfm.2
So the package needs to be named libcmark-gfm0.29.0.gfm.2.
Cheers
>
> Similar is required for the package cmark.
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private
Sebastian Ramacher
Keith Packard
> No, please review Section 8 of the policy.
>
> The SONAME is:
>
> $ objdump -x libcmark-gfm.so.0.29.0.gfm.2 | grep SONAME
> SONAME libcmark-gfm.so.0.29.0.gfm.2
>
> So the package needs to be named libcmark-gfm0.29.0.gfm.2.
end up going through the NEW queue, right? I'm not sure there's a
reasonable alternative though; I just looked at
libcmark-gfm-extensions.so.0.29.0.gfm.0 vs
libcmark-gfm-extensions.so.0.29.0.gfm.2 and they *replaced* one function
with another:
T cmark_gfm_extensions_get_table_alignments
T cmark_gfm_extensions_get_table_columns
T cmark_gfm_extensions_get_table_row_is_header
-T cmark_gfm_extensions_get_tasklist_state
+T cmark_gfm_extensions_get_tasklist_item_checked
T cmark_gfm_extensions_set_table_alignments
T cmark_gfm_extensions_set_table_columns
T cmark_gfm_extensions_set_table_row_is_header
+T cmark_gfm_extensions_set_tasklist_item_checked
B CMARK_NODE_STRIKETHROUGH
B CMARK_NODE_TABLE
B CMARK_NODE_TABLE_CELL
Suggestions welcome, but it looks like Sebastian may be right and that I
need to change the package name of the libraries at each release. Ick.
--
-keith
Keith Packard
> Suggestions welcome, but it looks like Sebastian may be right and that I
> need to change the package name of the libraries at each release. Ick.
package names for each upstream cmark-gfm release.
https://salsa.debian.org/keithp/cmark-gfm/-/commits/lib-autogen
This uses a gbp buildpackage hook to automatically generate
debian/control and the library debian/*.install files as those now
depend on the upstream package version in ways that dpkg-gencontrol
isn't sufficient to deal with.
This does clear the lintian warning about so name not matching package
version at least, so maybe I should have been listening more closely to
those messages.
--
-keith
Keith Packard
> Looks good to me. But then again, I was the one with the wrong approach
> here, so not sure how much my input can be trusted ;-)
names.
I'm a bit uncertain about the Replaces and Breaks clauses in the control
file; we need to make sure to remove the current packages which are
installing the libraries with the same filename. I think I've got it
right, but another bit of review would be appreciated.
I'll wait a week to see if Sebastian has time to respond, and if we're
still both reasonably happy with this approach, I'll go ahead and upload
it (alas, in binary form as is required for the New queue).
--
-keith
Keith Packard
> Looks good to me. The Breaks+Replaces can be dropped after the next
> upstream release.
Right. Thanks much for your review. I've uploaded these bits; they'll be
stuck in New, after which this bug should be closed.
--
-keith