Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
1.4.2 stops using qt5-webengine, however it still uses some of its
dependencies and now qt5-quickcontrols2.
|
|
|
|
New 1.4.0 tarball.
|
|
Update dependencies: XnView now uses qt5-webengine instead of
qt5-webkit. qt5-sensors was pulled in by qt5-webkit, so add it
explicitly.
|
|
Packaged Qt libraries got upgraded to 5.15.11, and unfortunately that
seems to have increased the number of Qt-versioned STL symbols the
XnView binary expects. Update qt5_std_fun_forwarder.S accordingly.
|
|
|
|
|
|
It turns out that the XnView executable wants new Qt_5-versioned
libstdc++ symbols, and that doesn't show up immediately on startup
unless forcing lazy binding off with LD_BIND_NOW. On the plus side, it
doesn't need the ones from 0.93.1 any more: 2 in, 3 out :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
XnView now uses libraw (see release notes), unfortunately the system one
doesn't seem to work, so the easiest option is to package the provided
one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
THe SHA256 doesn't match the one given by
https://newsgroup.xnview.com/viewtopic.php?f=82&t=40411&p=162833#p162797,
for now I've put the actual sum.
|
|
|
|
|
|
Another source release, the modified files are still irrelevant so no
pkgrel bump needed either.
|
|
The only difference with the previous archive is the removal of
libqt5ct.so, which is irrelevant for this package (all the libs are
removed), so no need for a pkgrel bump.
|
|
|
|
|
|
|
|
Lesson of the day: use `makepkg -C` before looking at the source
files... One more reason not to copy all the files from $srcdir!
|
|
The latest update to libwebp (1.1) broke XnView, because it tries to
link against the system libwebpmux.so while using the packaged
libwebp.so (in Plugins).
Because of this, I realised that there is no point in using the packaged
plugins, since they are all libraries available in standard Arch
packages. This commit replaces them with symlinks to system libs (as
XnView is still unhappy if it cannot find them in Plugins/), and adds
the relevant dependencies.
While at it, I also realised that a lot of files are junk and don't need
to be installed, and that many permissions are wrong. Fix all that by
specifying which files/directories to install (instead of removing
some), and only making executable those that should be.
Finally, it looks the bug that prevented me from getting rid of lib/
altogether is gone, so there's no need to symlink the Qt plugin
directories any more. As a result, the only use we still have for
xnview.sh is the LD_PRELOAD hack, and we don't need the one included in
the archive any more.
|
|
|
|
The XnView binary in that release has wrong permissions, add some more
permission cleanup.
|
|
|
|
|
|
|
|
I had the unpleasant surprise to find that something changed in the Qt5
libraries shipped in 0.93.1, in such a way that they're not quite
compatible with the system ones on Arch. Fortunately I found a way
around that, which is frankly horrifying, but as long as you don't look
at it it's probably alright!
On the plus side, I've made some cleanups:
- Drop the 32-bit package (like in xnviewmp).
- Drop the trash workaround, it's fixed in 0.93.1.
- No need to special-case the "styles" folder any more, since it's now
shipped as well.
|
|
As reported by fuan_k, the trash functionality is now quite broken
because XnView relies on gvfs-trash, which no longer exists. Until it is
properly fixed, use a wrapper that calls gio trash (gio is provided by
glib2, so the optdepends has been updated).
See also: https://newsgroup.xnview.com/viewtopic.php?t=37989
|