Arch Linux User Repository

I've done some testing, and indeed as @katt points out everything that pulls in libtiff breaks after upgrading to 4.5.1, and as I anticipated rebuilding mozjpeg is not useful.

The issue here is pretty simple:

• libjpeg-turbo just released a new version (3.0.0) with some new symbols not in the previous version. Libtiff was rebuilt by Arch Linux and links against these symbols.

• mozjpeg is intended to be a drop in replacement for libjpeg-turbo, but in this case it is failing to do so because the mozjpeg developer has not yet merged in changes from libjpeg-turbo 3.0.0.

• IIRC there used to be an AUR package called mozjpeg-opt for users who wanted to have mozjpeg available, but not use it as a replacement for their system libjpeg-turbo, but this no longer exists.

I think the short-term solution is that mozjpeg users should do sudo pacman -S libjpeg-turbo to switch back to the official package until there is a fix for this.

If mozjpeg doesn't move quickly I may see if it is possible to merge the libjpeg-turbo changes in the PKGBUILD. I'll also file an upstream bug.

I've done some testing, and indeed as @katt points out everything that pulls in libtiff breaks after upgrading to 4.5.1, and as I anticipated rebuilding mozjpeg is not useful.

The issue here is pretty simple:

• libjpeg-turbo just released a new version (3.0.0) with some new symbols not in the previous version. Libtiff was rebuilt by Arch Linux and links against these symbols.

• mozjpeg is intended to be a drop in replacement for libjpeg-turbo, but in this case it is failing to do so because the mozjpeg developer has not yet merged in changes from libjpeg-turbo 3.0.0.

• IIRC there used to be an AUR package called mozjpeg-opt for users who wanted to have mozjpeg available, but not use it as a replacement for their system libjpeg-turbo, but this no longer exists.

I think the short-term solution is that mozjpeg users should do sudo pacman -S libjpeg-turbo to switch back to the official package until there is a fix for this.

If mozjpeg doesn't move quickly I may see if it is possible to merge the libjpeg-turbo changes in the PKGBUILD. I'll also file an upstream bug.

A lighter test is to install libwebp and for example just try to run img2webp and it will complain about an undefined symbol as well.

@dvzrv

They can not know, when these things happen. It's the job of the maintainer to track this.

Personally, I've always found it exasperating when AUR maintainers force me to rebuild packages unnecessarily. If I've already rebuilt it myself or installed it after the dependency got bumped, rebuilding is a total waste. In any case, the way I would track this as an AUR maintainer is by subscribing to the RSS feeds for dependency releases. Presumably that option is available to anyone using the PKGBUILD. (Really, mozjpeg should be in extra, but I haven't had time to put a TU application together so I can manage this and some other packages...)

I'll consider a change in policy here, but I just want to note that doing so would be to adopt behavior I find irritating from others. So much so that I had to quit using AUR update tools like yay because they incorrectly assume that rebuilding is always desirable.

It is the other way round. Libtiff depends on libjpeg-turbo.

Right, I was assuming something like this was the case. But this indicates that mozjpeg did not need a rebuild, as none of its dependencies changed. In this case, me bumping the pkgrel would have been a mistake.

I'm not sure what the cause of the lightdm issue is, as I don't use it. I'll try to install it and see if I notice any problems.

Mozjpeg does indeed provide libturbojpeg.so, so I'll add that.

This package breaks systems on a recent update, see: https://bugs.archlinux.org/task/79579

Fixed a typo in my last comment (irt the soname provided by libjpeg-turbo).

Since rebuilding AUR packages when dependencies change is the responsibility of users, I don't bump pkgrel with no changes. This unnecessarily harms users who have installed the package in the intervening period as they then have to rebuild it.

Oh, but this should always be done as courtesy to the user. They must rebuild their package to not run into these types of issues. They can not know, when these things happen. It's the job of the maintainer to track this.

Also, the exact nature of the referenced bug isn't clear to me. mozjpeg (and libjpeg-turbo for that matter) don't depend on libtiff and so it's not clear to me that rebuilding them would have any effect in this case. Probably the comment by loqs is wrong and there's some other dependency issue at play here?

It is the other way round. Libtiff depends on libjpeg-turbo. As the user did not have the supported libjpeg-turbo (but mozjpeg as replacement) installed, they ran into crashes with gdm/lightdm. We have recently rebuilt libtiff for not depending on a statically but a dynamically linked jbigkit. Now, whether this is the cause of the issue: I don't know, but the timing matches. Whether gdm/lightdm are now still affected (after upgrading mozjpeg to 4.1.4-1) is something you might be able to check :)

On a different note: Do you know if mozjpeg also provides libturbojpeg.so (like libjpeg-turbo does)? If so, it should go to provides as well.

@dvzrv I've pushed just now for the 4.1.4 release and taken your advice on the libjpeg declaration.

Since rebuilding AUR packages when dependencies change is the responsibility of users, I don't bump pkgrel with no changes. This unnecessarily harms users who have installed the package in the intervening period as they then have to rebuild it.

Also, the exact nature of the referenced bug isn't clear to me. mozjpeg (and libjpeg-turbo for that matter) don't depend on libtiff and so it's not clear to me that rebuilding them would have any effect in this case. Probably the comment by loqs is wrong and there's some other dependency issue at play here?

Hi! Please make sure to rebuild and test this library properly. Users have just run into issues with it: https://bugs.archlinux.org/task/79579

Also, the advice in https://aur.archlinux.org/packages/mozjpeg#comment-851177 is not correct. Please only use libjpeg.so (the soname and bitness will be derived by makepkg during build time).

@afontenot Thanks for the update and for enabling tests! For me they are very fast and all of them passes.

@MarsSeed that's irritating, I didn't realize the AUR DB worked like that. I try very hard to avoid forcing pointless rebuilds with a pkgrel bump, but that would have been appropriate here. I'll do that.