Arch Linux User Repository

Hi all,

I'm disowning this package for the following reasons:

• The project is basically dead, no commits in 6 months.
• The project maintainer hasn't rebased it on libjpeg-turbo 3.0, making this package basically useless because it's designed to replace the system's dynamically linked libjpeg: https://github.com/mozilla/mozjpeg/issues/437
• A new JPEG encoder called JPEGLI is released and basically eats Mozjpeg's lunch on every single image I've tested. It's much superior. I strongly recommend anyone who needs a JPEG encoder to switch to this; an encoder cjpegli is included in the libjxl package in extra.

Unfortuantely, jpegli is not (yet) a drop-in replacement for libjpeg, because it is also based on the 2.0 version of libjpeg-turbo.

For comparisons between JPEGLI and MozJPEG (and other codecs), please check https://afontenot.github.io/image-formats-comparison/#sunset&JPEGLI=l&MOZJPEG=l

Hi all,

I'm disowning this package for the following reasons:

• The project is basically dead, no commits in 6 months.
• The project maintainer hasn't rebased it on libjpeg-turbo 3.0, making this package basically useless because it's designed to replace the system's dynamically linked libjpeg: https://github.com/mozilla/mozjpeg/issues/437
• A new JPEG encoder called JPEGLI is released and basically eats Mozjpeg's lunch on every single image I've tested. It's much superior. I strongly recommend anyone who needs a JPEG encoder to switch to this; an encoder cjpegli is included in the libjxl package in extra.

Unfortuantely, jpegli is not (yet) a drop-in replacement for libjpeg, because it is also based on the 2.0 version of libjpeg-turbo.

For comparisons between JPEGLI and MozJPEG (and other codecs), please check https://afontenot.github.io/image-formats-comparison/#sunset&JPEGLI=l&MOZJPEG=l

@afontenot 4.1.5 update, sha256sum: 9fcbb7171f6ac383f5b391175d6fb3acde5e64c4c4727274eade84ed0998fcc1; licenses (SPDX): BSD-3-Clause-Modification, IJG, Zlib; check fails, solve with: make test ||:.

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).