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

Getting the same error as simona.

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.

Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
-- Configuring incomplete, errors occurred!

This package should probably remove the libjpeg virtual package in provides following the general ArchLinux change: https://archlinux.org/todo/stop-relying-on-virtual-libjpeg-lib32-libjpeg-package/

Also see the libjpeg-turbo change and comments there: https://gitlab.archlinux.org/archlinux/packaging/packages/libjpeg-turbo/-/commit/a0e534d2803d7561c791ab5cd7f1a6f496d0cfaa

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