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.

Thanks for response Corax. xnview.sh permissions were 744 after installation. I've chmod-ed them to 777 and xnviw now exits with "Segmentation fault (core dumped)". Looked for xnview folder in home/user/.config - there is none. I'll 'yaourt -Rsn' the package and try again; --- I've reinstalled it and have the same error. I've noticed that folder /opt/xnviewmp/UI hass permissions 700 whilst all other folders are 755 (if that matters). Thanks again.

@Slobodan: that's strange. The symlink permissions themselves are irrelevant (symlinks are always 777), what are the permissions of /opt/xnviewmp/xnview.sh? By any chance, have you mounted a partition on /opt whose FS doesn't support Unix permissions (e.g. NTFS)?

I've yaourt-ed xnview on my fresh Manjaro XFCE 32 bit, didn't edit pkgbuild and now, when starting xnview from menu I have this error message: 'Failed to execute command "/usr/bin/xnviewmp %F". Failed to execute child process "/usr/bin/xnviewmp" (Permission denied)'. Simlink permissions are 777. Can you please help? I can be reached via mojimejl@tutanota.com

@fuan_k Weird, I don't have this issue. With the default keys in xnview.ini (shortcut=default.keys, toolbar=default.bar), xnviewmp reads the right files: open("/home/corax/.xnviewmp/default.keys", O_RDONLY|O_CLOEXEC) = 11 open("/home/corax/.xnviewmp/default.bar", O_RDONLY|O_CLOEXEC) = 11

Can any of you guys reproduce this issue reported there please? http://newsgroup.xnview.com/viewtopic.php?f=62&t=35447 The default.keys default.bar files are not looked up properly anymore since 0.85 and the author says he can't reproduce (he only supports Ubuntu as far as I know). Edit: found a fix replace these values in the xnview.ini file located in ~/.config/xnviewmp/xnview.ini shortcut=/home/user/.config/xnviewmp/default.keys toolbar=/home/user/.config/xnviewmp/default.bar

@fritz2 Thanks for the notification, I have bumped the PKGBUILD. No need to comment though, flagging out-of-date is enough to send me a notification.

A new version is out: http://download.xnview.com/XnViewMP-085-linux-x64.tgz Results in a 404 error: curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading http://download.xnview.com/XnViewMP-linux-x64.tgz

@fuan_k First, I wish more people didn't "know much about computers" like you do, the world would be a better place :D To be honest the packaging of XnView MP is awful and I don't feel like the maintainer really understands what he does. Anyway, I found out that I still had a font issue using system libs. I think I found a way to fix it, which is actually quite logical. Please try the latest pkgrel of https://aur.archlinux.org/packages/xnviewmp-system-libs/ and let me know if it works for you (look at the commit message for more info on what I did). Note that this package relies on the gtk2 platform themes, but I believe it should work with qt5ct too (just tweak xnview.sh).

Now segfaulting since the last update, when using system libs (ie. the previous workarounds to fix the fonts don't seem to work anymore because I can only use bundled libs). What on Earth are they doing upstream? xD Changing the following line in xnview.sh causes the segfault: ``export QT_PLUGIN_PATH="$dirname/lib"`` to ``export QT_PLUGIN_PATH="/usr/lib"`` Must be because updated Qt libs are now 5.8 and xnview is still shipping 5.6 libs? Edit: Found a new workaround which works!! Edit xnview.sh as follows: export LD_LIBRARY_PATH="/usr/lib:$dirname/Plugins" export QT_PLUGIN_PATH="/usr/lib" export QT_QPA_PLATFORM_PLUGIN_PATH="$dirname/lib/platforms" export QT_QPA_PLATFORMTHEME="qt5ct" and change qt.conf like this: [Paths] Plugins = Plugins lib = lib Then symlink qt5ct into the Plugins directory: sudo ln -s /usr/lib/qt/plugins/platformthemes/libqt5ct.so /opt/xnviewmp/Plugins/libqt5ct.so And to avoid the "missing style proxy" error (not critical, only optional): sudo mkdir /opt/xnviewmp/Plugins/styles sudo ln -s /usr/lib/qt/plugins/styles/libqt5ct-style.so /opt/xnviewmp/Plugins/styles/libqt5ct-style.so Then qt5ct plugin loads fine again -- although the icons get reverted to default gnome icons for some reason -- but the font is tweaked accordingly to qt5ct again. Can't find a way to have qt5gtk2 working though. Sorry I don't know much about computers but... What a MESS!

@goldpaw Yes with your suggestion it's now less problematic (I've updated the pinned comment accordingly), we just have to notice that upstream has made a new release. When I find time I'll set up something to check that periodically, e.g. every day. And you're very much welcome, I only maintain this package since a few months ago but I'm glad it proves useful to so many people :)