Package Details: xnviewmp 1.7.1-1

Git Clone URL: (read-only, click to copy)
Package Base: xnviewmp
Description: An efficient multimedia viewer, browser and converter.
Upstream URL:
Keywords: graphics
Licenses: custom
Submitter: oliwer
Maintainer: Corax
Last Packager: Corax
Votes: 301
Popularity: 6.22
First Submitted: 2008-07-25 19:01 (UTC)
Last Updated: 2024-04-09 18:52 (UTC)

Dependencies (2)

Required by (0)

Sources (2)

Pinned Comments

Corax commented on 2017-01-21 15:34 (UTC) (edited on 2017-02-12 19:23 (UTC) by Corax)

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: Do keep in mind that this is an experimental package though, and things may break when I try to fix other things...

Corax commented on 2017-01-20 21:49 (UTC) (edited on 2023-10-30 20:39 (UTC) by Corax)

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.

Latest Comments

1 2 3 4 5 6 .. 26 Next › Last »

flan_suse commented on 2024-04-09 13:40 (UTC)

1.7.1 was released with some important fixes :)

Corax commented on 2023-10-30 20:33 (UTC)

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

flan_suse commented on 2023-10-16 02:16 (UTC) (edited on 2023-10-16 18:49 (UTC) by flan_suse)

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:

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:


You should have this:


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

QuaverFace commented on 2023-10-15 17:47 (UTC)

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

valsaven commented on 2023-07-22 04:32 (UTC)

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

schnedan commented on 2023-07-20 20:18 (UTC)

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

Corax commented on 2022-12-29 20:31 (UTC)

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

Mechanicus commented on 2022-12-29 18:54 (UTC)

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

Mechanicus commented on 2022-12-29 18:48 (UTC)

@Corax, interestingly, but the crash is not present on this updated xnviewmp archive. Version 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).

Corax commented on 2022-12-29 18:36 (UTC)

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