New soname needed with 1.4.3 ?

[matroska-org]

New soname needed with 1.4.3 ?

[mbunkus]

Huh… I thought we were really careful. My guess is that compiling in C++14 mode yields different symbol names. Meh.

I'll bump the sonames of both libraries & prepare new releases.

[mbunkus]

@marillat Please note that we've decided to tackle of couple of merge requests & change ideas that we've been pondering & postponing till the next ABI break for some time now. This means that the next version of libEBML will not be released as soon as I initially thought. Also, it won't be API-compatible anymore, requiring new releases of software using it.

You'll have to decide what you want to do with the latest, ABI-breaking-but-not-soname-bumping release — probably just ignore/skip it.

[marillat]

Thanks, I already reverted libEBML to 1.4.2
I'll wait for the next release.

[mbunkus]

I'm re-opening the issue until the new releases have been made, even though the "fix" has already been committed.

[mbunkus]

For others coming here looking for solutions, there are basically two:

1. Skip this release & keep your distro on 1.4.2 for the time being
2. Keep using 1.4.3, but re-compile all libraries & applications using it (e.g. libMatroska, MKVToolNix, VLC, potentially others)

As stated above, we plan to release new versions of both libraries that will have their sonames/soversions bumped properly. As these will also break the API in certain ways, they will also require new releases of software using the libraries. The changes will be pretty small (e.g. see this commit in MKVToolNix — basically only swapping uint32 with the proper type, size_t, and fixing a couple of compiler warnings resulting from the different data type). It'll likely be a couple of days (weeks?) until those new releases are done.

[marillat]

In Debian only 3 applications are using ebml/matroska MKVToolNix, gerbera and vlc
And we have largely the time to rebuild these packages as the Soft Freeze for the next release is scheduled in February 2023.

[CummingCowGirl]

I just reinstall MKVToolNix and it still will not launch with 1.4.3.

[marillat]

@Locutus64 Yes, you must install 1.4.2

[CummingCowGirl]

Installed the Flatpak for MKVToolNix and it seems to be working fine now.

[thesamesam]

It may be worth adding abidiff from libabigail to CI for future.

[mbunkus]

@thesamesam That sounds interesting. Is there a Github workflows config we can take a look at as inspiration?

[thesamesam]

@thesamesam That sounds interesting. Is there a Github workflows config we can take a look at as inspiration?

Sure! I originally got the idea from OpenZFS (see https://github.com/openzfs/zfs/blob/master/.github/workflows/checkstyle.yaml#L40), but managarm's setup is easier to read & understand I reckon: https://github.com/managarm/mlibc/blob/master/.github/workflows/abidiff.yml. @ArsenArsen added it there after I mentioned it in passing!

[mbunkus]

Thanks! I'll take a look.

[johackim]

I can't use mkvextract on Arch Linux and can't downgrade libebml, someone has a workaround ?

[mbunkus]

Re-compile MKVToolNix.

[johackim]

Re-compile MKVToolNix.

Hello @mbunkus, thanks for your answer!

This commands don't works :

sudo pacman -Rsn mkvtoolnix-cli
sudo pacman -S mkvtoolnix-cli

[mbunkus]

Re-compile, not just re-install. If you don't know how to do that, please ask on the Arch Linux forums.

[mbunkus]

@robUx4 As our release of 2.0.0 will still take a bit of time, I plan on releasing libEBML 1.4.4 & libMatroska 1.7.1 which will be ABI-compatible again with libEBML 1.4.2 & libMatroska 1.6.3 respectively. For that I've created the branch v1.4.4 starting at tag release-1.4.3. I'll do similar things for libMatroska.

The tool @thesamesam mentioned, abidiff from the libabigail package, is a god-send for this type of purpose. It allowed me to identify the commits that break the ABI due to removed or changed symbols. Reverting those two commits on top of v1.4.4 (release-1.4.3) was conflict-free. The result was a new shared library that didn't have an ABI diff to the one produced by compiling release-1.4.2.

I've opened a PR into v1.4.4 that contains the reverts.

The reason is that, as you can see here, several distros have already updated, and a lot of users are confused & complaining. The easiest solution seems to be to produce new versions quickly that are ABI-compatible so that distros can update to those. It'll take the pressure of us of releasing our planned, API-breaking 2.0.0.

[johackim]

Re-compile, not just re-install. If you don't know how to do that, please ask on the Arch Linux forums.

It's good with theses commands :

yay -G mkvtoolnix-cli
cd mkvtoolnix/repos/extra-x86_64
makepkg -si

Thanks!

[mbunkus]

libEBML 1.4.4 & libMatroska 1.7.1 have been released. They restore ABI compatibility with prior versions which the most recent releases (1.4.3 & 1.7.0 respectively) unfortunately broke.

More concrete: the new libEBML release 1.4.4 is ABI-compatible with 1.4.2 & 1.4.1 again (probably even further back). However, 1.4.3 is compatible with neighter its predecessor 1.4.2 nor the new one, 1.4.4.

Similarly for libMatroska: the new 1.7.1 is ABI-compatible with 1.6.3 & 1.6.2 again. However, 1.7.0 is compatible neither its predecessor 1.6.3 nor the new one, 1.7.1.

If you had already upgraded to 1.4.3 & re-compiled applications using them, you'll have to re-re-compile with after upgrading to 1.4.4. However, if you hadn't done the re-compiling yet (meaning they'd work with 1.4.2 but not 1.4.3), upgrading to 1.4.4 should work without recompiling. Similarly for libMatroska.

I'm sorry for the inconvenience.