Arch Linux User Repository

I have created a new package: xnviewmp-system-libs. This is exactly the same build, except that the bundled Qt/icu libs are removed. Please try it if you want to use XnView without the bundled libs, and discuss any issue related to this configuration here: https://aur.archlinux.org/packages/xnviewmp-system-libs/. Do keep in mind that this is an experimental package though, and things may break when I try to fix other things...

If makepkg fails because the checksum is incorrect, please flag the package out-of-date and I will update the PKGBUILD.

The PKGBUILD now references the latest versioned archive, as a result of which it should keep working if a new version is released. However, upstream sometimes updates released archives in place, in which case the checksum will fail and a manual intervention is required.

@flan_suse: sorry for the very late reply. You're right, I actually spotted this a while back but didn't find the motivation to make the move. I was a little concerned that I might miss updates, but there are some pretty reactive people reporting new versions here so that should be fine. There will still be issues when Pierre decides to change an already released tar (it happened again recently), but this is fortunately not anywhere as frequent as regular updates. I'll make the switch for this package and xnviewmp-system-libs now.

Upstream does not version the released archives

They actually do.

I think you should update the PKGBUILD so that it pulls the tarballs from this URL:

https://download.xnview.com/old_versions/XnView_MP/

This will avoid the issue of "invalid SHA256", since it will download a specific version, rather than the generic "XnViewMP-linux-x64.tgz".

So instead of this:

source=("XnViewMP-linux-x64_${pkgver}-rel${srcrel}.tgz::https://download.xnview.com/XnViewMP-linux-x64.tgz"

You should have this:

source=("XnViewMP-linux-x64_${pkgver}-rel${srcrel}.tgz::https://download.xnview.com/old_versions/XnView_MP/XnView_MP-${pkgver}-linux-x64.tgz"

Don't be fooled by "old_versions" in the URL. Pierre adds the files on the same day of release.

looks like checksum is outdated for tgz. 1.6.0-1 (14/10) should be: f5a1a620c785ea7e8bbadac646d3cbe6202b183124769c1153a7b05f61ca9d75

@Corax, maybe it will help. The correct SHA256 for current XnViewMP-linux-x64.tgz file is 3816b6a86223e1a9bbf93ab6c61526ddcb2b8b3ff662408f2b88647e5ba7a9a8

here update fails with validation of sha256... so I flag out of date as requested.

Right, the new archive (no release note from upstream) has QtWebEngineProcess added, not sure how that's related to the crash. Glad it's fixed either way. As to why qt5-* are kept as dependencies, see my comments below (from 18/12).

@Corax regarding this XnViewMP bundle, I didn't find any dependency to the system Qt5 libs, so the dependency list can be cleared from Qt5 completely.

@Corax, interestingly, but the crash is not present on this updated xnviewmp archive. Version 1.4.0.2 was crashed once you try to open GPS map window in the picture properties. And since the XnViewMP is bundled with Qt 5.15.11, I supposed that the crash was caused by the Qt version mix (the Arch Linux Qt5 is 5.15.7).

@Mechanicus: uh, now that is strange! See below for the discussion regarding qt5- dependencies. For your particular issue, there is a more fundamental problem: it is impossible to prevent qt5- from being installed, and indeed they will be installed in many if not most systems (because they are dependencies for other packages).

What this means is that in any case, we need this package to work when qt5-* are installed. Do you have a backtrace of the crash? How hard is it to reproduce?

Hello @Corax! Thank you for maintaining the XnViewMP AUR package! Could you please remove all qt5 dependencies for this pkgbuild, since with the mix of bundled and system libs the application crashes when you try to open GPS information of the picture. With bundled-only libs it works just fine.