Package Details: xnviewmp-system-libs 0.93.1-2

Git Clone URL: https://aur.archlinux.org/xnviewmp-system-libs.git (read-only)
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: 14
Popularity: 0.000351
First Submitted: 2017-01-21 15:31
Last Updated: 2019-03-16 14:49

Latest Comments

1 2 3 4 Next › Last »

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

Corax commented on 2019-01-31 23:06

@fuan_k: I'm confused, it's never stopped working for me, and for sure it still does! Deleting files in XnView results in them ending up in ~/.local/share/Trash/files/. Using strace, I do see that XnView tries to execve() gvfs-trash, which fails, and it then looks like it copies the file to Trash manually. Excerpt below (after filtering out some irrelevant operations):

[pid 23066] execve("gvfs-trash", ["gvfs-trash", "-h"], 0x7ffd56385268 /* 47 vars */) = -1 ENOENT (No such file or directory)
[pid 23066] exit_group(-1)              = ?
[pid 23066] +++ exited with 255 +++
[pid 23030] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23066, si_uid=1000, si_status=255, si_utime=0, si_stime=0} ---
[pid 23030] statx(AT_FDCWD, "/home/corax/.local/share/Trash/files/", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=53248, ...}) = 0
[pid 23030] statx(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7238748, ...}) = 0
[pid 23030] stat("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", 0x7ffd56382e50) = -1 ENOENT (No such file or directory)
[pid 23030] renameat2(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", RENAME_NOREPLACE) = -1 EXDEV (Invalid cross-device link)
[pid 23030] openat(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", O_RDONLY|O_CLOEXEC) = 25
[pid 23030] statx(25, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7238748, ...}) = 0
[pid 23030] openat(AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 26
[pid 23030] statx(26, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
[pid 23030] unlink("/tmp/WD/PC290914_190131-225349.JPG") = 0
[pid 23030] statx(AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7225344, ...}) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", R_OK) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", W_OK) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", X_OK) = -1 EACCES (Permission denied)
[pid 23030] chmod("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", 0644) = 0

fuan_k commented on 2019-01-31 20:34

Note that I'm still having the issue and have to use the gvfs-trash script workaround in 0.93.

Creating such script in /home/user/bin/ works since apparently xnview looks for it there on its own.

Should we add this workaround to the PKGBUILD script until next version? Up to you. ;)

doskoi commented on 2019-01-11 05:18

Thanks, I solved it with the gvfs-trash script. I don't even need gvfs anymore :p

fuan_k commented on 2019-01-09 00:46

@doskoi look at this thread: https://newsgroup.xnview.com/viewtopic.php?t=37989

If this is the bug you encounter, it should be fixed in the next release. Otherwise, might want to report upstream.