Package Details: xnviewmp-system-libs 0.96-1

Git Clone URL: https://aur.archlinux.org/xnviewmp-system-libs.git (read-only, click to copy)
Package Base: xnviewmp-system-libs
Description: An efficient multimedia viewer, browser and converter (using system libraries).
Upstream URL: http://www.xnview.com/en/xnviewmp/
Keywords: graphics
Licenses: custom
Conflicts: xnviewmp
Submitter: Corax
Maintainer: Corax
Last Packager: Corax
Votes: 16
Popularity: 0.39
First Submitted: 2017-01-21 15:31
Last Updated: 2020-03-21 16:26

Latest Comments

1 2 3 4 5 Next › Last »

Corax commented on 2020-01-11 19:33

@Maniaxx: thanks for the heads-up and apologies, one day I will remember to makepkg -C before fiddling with things... Now fixed, on the plus side that shows another reason not to copy all the files from $srcdir :)

Maniaxx commented on 2020-01-11 17:47

installed_files_dirs= contains some invalid files. After removing them it works fine. Thanks!

==> Starting package()...
cp: cannot stat 'default.bar': No such file or directory
cp: cannot stat 'default.keys': No such file or directory
cp: cannot stat 'XnView.db': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

Corax commented on 2020-01-11 16:47

@Maniaxx: sorry for the delay, that issue prompted me to look into the other plugins as well and I realised we don't need to use the packaged plugins at all :) Please try 0.94.2-2, it now uses system libraries for everything (and refactored a lot of other things, see the last commit).

Maniaxx commented on 2020-01-09 01:16

I had to manually update the libwebp.so and libwebpdemux.so libs in Plugins folder. Otherwise it throws a missing symbol error.

Corax commented on 2019-03-10 16:36

I thought about it, but I doubt he really cares, since it's not supposed to work with anything but the bundled libs. If a more serious deviation occurs, then we might have no choice but to ask him.

fuan_k commented on 2019-03-10 16:24

Interesting hack. It works fine on my side. Thanks Corax! I'm thinking maybe the XnView developer would be interested in hearing about this problem? Perhaps he could help in that regard, or at least let us know what changes he made on his build environment?

Corax commented on 2019-03-10 15:10

0.93.1 with my wonderf... horrifying hack now up, please test and report back!

Corax commented on 2019-03-09 19:02

For those wondering why I still haven't updated this package (even though I have updated xnviewmp yesterday), that's because unfortunately, linking against the system Qt5 libraries no longer works :( The good news is, thanks to a massive amount of dynamic library hacking, I think I've found a way around it! It seems to work fine, but it's really horrible right now, so I need a bit more time to try and make it less frightening. Hopefully I'll push a functional 0.93.1 within the next few days.

Corax commented on 2019-02-02 12:14

Oh right, I understand now, that explains why Nemo was confused about the original location of the file! I have to admit that I'm not very clear on how the trash is supposed to work...

I have implemented your suggested workaround, putting the gvfs-trash wrapper in XnView's directory to avoid polluting the global PATH. That should do for now.

fuan_k commented on 2019-02-01 03:26

The problem is that I don't (didn't) have the Trash directory in /home yet (until it got created by Thunar when I removed a test file from /home). So xnview fails to even create this Trash directory on its own, and when it doesn't find it, it unlinks the files instead.

Regardless, it shouldn't move files to the /home Trash when attempting to remove files from another partition for example. It should use the Trash from the same partition/file system.

I've already reported it upstream (see link to forum post below).