Package Details: libjpeg-xl-git r24.gc8ce59f-1

Git Clone URL: https://aur.archlinux.org/libjpeg-xl-git.git (read-only, click to copy)
Package Base: libjpeg-xl-git
Description: JPEG XL image format reference implementation (git version)
Upstream URL: https://jpeg.org/jpegxl/
Keywords: jpegxl jxl libjpegxl
Licenses: Apache
Conflicts: libjpeg-xl
Provides: libjpeg-xl
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 4
Popularity: 0.22
First Submitted: 2020-02-01 14:20
Last Updated: 2020-10-13 17:58

Required by (0)

Sources (13)

Latest Comments

1 2 3 4 Next › Last »

dbermond commented on 2020-10-13 17:59

@andrius4669 Package updated to match the latest upstream changes.

andrius4669 commented on 2020-10-13 15:21

...
-- Installing: /home/anon/.cache/yay/libjpeg-xl-git/pkg/libjpeg-xl-git/usr/bin/xyb_range
make: Leaving directory '/home/anon/.cache/yay/libjpeg-xl-git/src/build'
rm: cannot remove '/home/anon/.cache/yay/libjpeg-xl-git/pkg/libjpeg-xl-git/usr/bin/cbrunsli': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

dbermond commented on 2020-07-28 01:38

@hotaru Patches updated to match to latest upstream changes. Package is now building fine.

hotaru commented on 2020-07-28 01:14

looks like the remove-werror patch is no longer needed:

patching file CMakeLists.txt
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file CMakeLists.txt.rej
==> ERROR: A failure occurred in prepare().
    Aborting...
error making: libjpeg-xl-git

dbermond commented on 2020-05-06 22:31

@andrius4669 It's better to use all submodules that are explicitly declared by upstream. Package is now fixed.

andrius4669 commented on 2020-05-06 20:58

Well, actually, mingw-std-threads is not actually being used or even referenced at all if MINGW is not defined. So fix what is not exactly cleanest but works for me well is:

diff --git a/PKGBUILD b/PKGBUILD
index 0d68e71..9495c4f 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -25,7 +25,6 @@ source=('git+https://gitlab.com/wg1/jpeg-xl.git'
         'git+https://github.com/google/brunsli.git'
         'git+https://github.com/webmproject/sjpeg.git'
         'git+https://skia.googlesource.com/skcms.git'
-        'git+https://github.com/meganz/mingw-std-threads.git'
         '010-libjpeg-xl-git-remove-werror.patch'
         '020-libjpeg-xl-git-fix-headers-install-path.patch'
         '030-libjpeg-xl-git-fix-gdk-pixbuf-install-path.patch'
@@ -38,7 +37,6 @@ sha256sums=('SKIP'
             'SKIP'
             'SKIP'
             'SKIP'
-            'SKIP'
             '0f538f216f7fca8611efd5d638b521eb2c3b1fb716720afb371f034b3165c90c'
             'c2ea669a2afd94b6582921c893e0b382cd632c12d0a9c2358f955fd6cccffdc3'
             '1666790b92321fbf5859abe50c7355c91b0eddd7381529f35f052e71913c3bf0'
@@ -46,6 +44,7 @@ sha256sums=('SKIP'

 prepare() {
     git -C jpeg-xl submodule init
+    git -C jpeg-xl submodule deinit --force third_party/mingw-std-threads
     git -C jpeg-xl config --local submodule.third_party/brotli.url "${srcdir}/brotli"
     git -C jpeg-xl config --local submodule.third_party/lodepng.url "${srcdir}/lodepng"
     git -C jpeg-xl config --local submodule.third_party/lcms.url "${srcdir}/Little-CMS"
@@ -53,7 +52,6 @@ prepare() {
     git -C jpeg-xl config --local submodule.third_party/brunsli.url "${srcdir}/brunsli"
     git -C jpeg-xl config --local submodule.third_party/sjpeg.url "${srcdir}/sjpeg"
     git -C jpeg-xl config --local submodule.third_party/skcms.url "${srcdir}/skcms"
-    git -C jpeg-xl config --local submodule.third_party/mingw-std-threads.url "${srcdir}/mingw-std-threads"
     git -C jpeg-xl submodule update
     patch -d jpeg-xl -Np1 -i "${srcdir}/010-libjpeg-xl-git-remove-werror.patch"
     patch -d jpeg-xl -Np1 -i "${srcdir}/020-libjpeg-xl-git-fix-headers-install-path.patch"

dbermond commented on 2020-05-06 20:47

I've identified what's happening. It seems that the commit referenced by submodule mingw-std-threads was moved. Maybe it was on the git master branch but now it's not on master branch anymore and not on any branch currently. I'll push a fix.

My git sources on $SRCDEST were still pointing to that old state, so I could not reproduce the issue.

andrius4669 commented on 2020-05-06 20:16

Non-makepkg based git submodule update:

$ git submodule update
Cloning into '/home/anon/jpeg-xl/third_party/brotli'...
Cloning into '/home/anon/jpeg-xl/third_party/brunsli'...
Cloning into '/home/anon/jpeg-xl/third_party/googletest'...
Cloning into '/home/anon/jpeg-xl/third_party/lcms'...
Cloning into '/home/anon/jpeg-xl/third_party/lodepng'...
Cloning into '/home/anon/jpeg-xl/third_party/mingw-std-threads'...
Cloning into '/home/anon/jpeg-xl/third_party/sjpeg'...
Cloning into '/home/anon/jpeg-xl/third_party/skcms'...
Submodule path 'third_party/brotli': checked out '35ef5c554d888bef217d449346067de05e269b30'
Submodule path 'third_party/brunsli': checked out 'ede60d8bae3c10c56e64a0001f7b354c5a086ca3'
Submodule path 'third_party/googletest': checked out '0ea2d8f8fa1601abb9ce713b7414e7b86f90bc61'
Submodule path 'third_party/lcms': checked out '65c63bf549d78253c14b30b3d62cb668bbbe612c'
Submodule path 'third_party/lodepng': checked out '48e5364ef48ec2408f44c727657ac1b6703185f8'
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 2 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 2.00 KiB | 1023.00 KiB/s, done.
From https://github.com/meganz/mingw-std-threads
 * branch            baca8abcfa9576d1682e049c46c4805230aeda5b -> FETCH_HEAD
Submodule path 'third_party/mingw-std-threads': checked out 'baca8abcfa9576d1682e049c46c4805230aeda5b'
Submodule path 'third_party/sjpeg': checked out '868ab558fad70fcbe8863ba4e85179eeb81cc840'
Submodule path 'third_party/skcms': checked out '64374756e03700d649f897dbd98c95e78c30c7da'

There is clearly something different about mingw-std-threads repo compared to others.. but I have no idea how to get it working yet.

andrius4669 commented on 2020-05-06 19:57

can confirm. same issue with both pikaur and pure makepkg

RubenKelevra commented on 2020-05-06 13:42

@dbermond

I already did choose the cleanBuild option on yay.

I also tried to download the files from aur and use makepkg, which also fails.

Sure that your package just builds fine because you have something cached? Because I cannot build it on multiple machines...