Package Details: mozjpeg 4.1.1-2

Git Clone URL: https://aur.archlinux.org/mozjpeg.git (read-only, click to copy)
Package Base: mozjpeg
Description: JPEG image codec with accelerated baseline decoding and superior encoding
Upstream URL: https://github.com/mozilla/mozjpeg
Licenses: BSD
Conflicts: libjpeg, libjpeg-turbo, mozjpeg-git, turbojpeg
Provides: libjpeg, libjpeg-turbo, libjpeg.so, turbojpeg
Submitter: afontenot
Maintainer: afontenot
Last Packager: afontenot
Votes: 28
Popularity: 0.089431
First Submitted: 2015-08-14 12:26 (UTC)
Last Updated: 2022-08-21 18:13 (UTC)

Required by (1042)

Sources (1)

Latest Comments

1 2 3 Next › Last »

MarsSeed commented on 2022-03-09 13:01 (UTC)

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

afontenot commented on 2022-03-09 01:20 (UTC)

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

MarsSeed commented on 2022-02-11 14:36 (UTC)

@afontenot Thanks for the change! Please also bump to pkgrel=2, as AUR hasn't refreshed the package metadata in its DB, so AUR helpers can't make use of the new provides information during dependency resolution.

afontenot commented on 2022-02-10 17:59 (UTC)

@MarsSeed Done; I think other packages that explicitly depend on a version when they actually don't need it are broken, but if it eases compatibility I guess its fine.

MarsSeed commented on 2022-02-10 12:55 (UTC)

Please kindly declare explicitly:

provides=(libjpeg.so=8-64)

Doing that will inform AUR helpers that look at that field and should prevent conflicts during installation/upgrade of this and Arch packages that hardcode depends=(libjpeg.so=8-64).

magicgoose commented on 2021-08-17 22:04 (UTC)

you can work around this by changing the provides to "libjpeg-turbo=2.1.0" in this PKGBUILD (or whatever the required version is when you read this).

Unfortunately this doesn't help anymore. I changed the line to

provides=("libjpeg" "libjpeg.so" "turbojpeg" "libjpeg-turbo=2.1.1")

and when I install, I get error:

error: failed to prepare transaction (could not satisfy dependencies)
:: removing libjpeg-turbo breaks dependency 'libjpeg-turbo=2.1.1' required by lib32-libjpeg-turbo

I remember it worked some time ago, so this must be because of some pacman change? (just a guess) Any ideas what to do with this?

afontenot commented on 2021-05-20 10:48 (UTC) (edited on 2021-05-20 10:58 (UTC) by afontenot)

@juliusk: you can work around this by changing the provides to "libjpeg-turbo=2.1.0" in this PKGBUILD (or whatever the required version is when you read this).

I'm going to have to have a think (and possibly ask on the mailing list) about the best way to go here. The issue is that lib32-libjpeg-turbo is requiring a specific version of libjpeg-turbo. Several problems:

  1. I don't know if lib32-libjpeg-turbo actually needs a very specific version of the libjpeg-turbo library or not.

  2. I don't know if the version of libjpeg-turbo that the latest release of mozjpeg is based on is actually drop in compatible with the specific version of libjpeg-turbo requested. Unfortunately mozjpeg doesn't get updated very often. Promising users that it's compatible by changing the PKGBUILD seems risky.

  3. This is probably a moving target, since any time anything bumps the version requirement for libjpeg-turbo I'd have to update the PKGBUILD. In light of 1 and 2 I don't know that that's advisable.

Quick edit: now that I think about it, it seems like the solution might be removing lib32-libjpeg-turbo and using lib32-mozjpeg instead. That's not my package so I'm not sure why it might not work, but I'll try to have a look at that too.

juliusk commented on 2021-01-15 10:12 (UTC)

The install fails for me:

error: failed to prepare transaction (could not satisfy dependencies)
:: removing libjpeg-turbo breaks dependency 'libjpeg-turbo=2.0.6' required by lib32-libjpeg-turbo

afontenot commented on 2020-11-25 23:19 (UTC)

@eschwartz: thank you as well! I was pretty sure about the libjpeg-turbo dependency being wrong (because it would prevent you from using certain drop-ins), but it looks like that's now been fixed in the mpv package.