@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 :)
Search Criteria
Package Details: xnviewmp 1.7.1-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/xnviewmp.git (read-only, click to copy) |
|---|---|
| Package Base: | xnviewmp |
| Description: | An efficient multimedia viewer, browser and converter. |
| Upstream URL: | https://www.xnview.com/en/xnviewmp/ |
| Keywords: | graphics |
| Licenses: | custom |
| Submitter: | oliwer |
| Maintainer: | Corax |
| Last Packager: | Corax |
| Votes: | 302 |
| Popularity: | 5.50 |
| First Submitted: | 2008-07-25 19:01 (UTC) |
| Last Updated: | 2024-04-09 18:52 (UTC) |
Dependencies (2)
- qt5-multimedia (qt5-multimedia-gitAUR)
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR) (optional) – support for moving files to trash
Required by (0)
Sources (2)
Corax commented on 2017-02-01 21:18 (UTC)
goldpaw commented on 2017-02-01 14:37 (UTC)
@Corax happy to help! :D
And I totally agree that the way the xnview team does their versioning is a problem. We're bound to get checksum errors and bugs from time to time since they don't really label or announce anything. But it's easy enough for us to check the md5 of the source and manually modify the PKGBUILD when needed. We'll figure it out!
Thanks for your continued work, wouldn't know what to do without this package! :)
Corax commented on 2017-01-24 22:10 (UTC)
@goldpaw I implemented your suggestion in the latest commit (I didn't bump the pkgrel as there is no point in making everyone rebuild exactly the same package). Thanks again!
Corax commented on 2017-01-23 21:27 (UTC)
@goldpaw I actually thought about doing that (very briefly though). I was concerned that it could be deceiving as the source archive would be renamed to the wrong version if the PKGBUILD it out-of-date, but that only happens if you've never run makepkg before, which probably means that you don't keep the PKGBUILD repo after building, in which case it doesn't matter how the sources are named. Also doing so would allow me (and others) to keep the various versions around. So yes definitely a good idea, but... Yeah I remember now, there's actually a problem with that. As we've seen last week, upstream doesn't necessarily bump the version number when publishing a new release. I think I'll work around that by appending a rel (release) number. Anyway thanks for mentioning this, I hadn't considered it seriously enough :-)
DungeonMaster commented on 2017-01-22 22:03 (UTC)
@Corax
Beautiful. Works great.
Just a hint for those who might be experiencing problems with QT_QPA_PLATFORMTHEME=qt5ct I downloaded a package in the AUR called qt5gtk2 and I use QT_QPA_PLATFORMTHEME=qt5gtk
qt5gtk is explained well in this article:
http://dglava.github.io/en/qtplatform-style.html
goldpaw commented on 2017-01-22 15:21 (UTC)
@Corax the problem with the wrong md5sum is that the download is stored with the same name each time. This leads to PKGBUILD assuming that the file is already downloaded, and thus it attempts to use the existing one instead. Which leads to a md5sum mismatch, of course.
The solution is to modify the PKGBUILD slightly, so that it includes the pkgver$ variable in the downloaded filename. All that needs changing are the two sources. Not that it's important to use " instead of ' here, otherwise it won't change the $pkgver variable into the actual file version.
I changed the thwo source lines to this, and was able to build it without manually having to delete the old download first:
source_x86_64=("XnViewMP_linux_x64_$pkgver.tgz::http://download.xnview.com/XnViewMP-linux-x64.tgz")
source_i686=("XnViewMP_linux_$pkgver.tgz::http://download.xnview.com/XnViewMP-linux.tgz")
Yay! :D
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: 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...
Corax commented on 2017-01-21 12:13 (UTC) (edited on 2017-01-21 12:53 (UTC) by Corax)
@blitz qt5-location is a dependency of qt5-webkit so there's no need to specify it. I've just checked that all needed qt5-* dependencies are there. And yes, it's much smaller, that's one of the reasons why it's good to get rid of the bundled libs.
@fuan_k You're absolutely right, the libicu 54 libs are gone, my src tree was not in a clean state >.< Will fix right now.
Regarding QT_QPA_PLATFORMTHEME, it's a good point as I use it too (although I don't use qt5ct anymore, I use gtk2 from qt5-styleplugins), I'll try to see how it interacts with the rest...
fuan_k commented on 2017-01-20 23:05 (UTC) (edited on 2017-01-21 01:58 (UTC) by fuan_k)
The only reliable way I found to fix the font issue is to use qt5ct and add this to the environment variables (or just add the following to xnview.sh maybe?)
QT_QPA_PLATFORMTHEME=qt5ct
This will force the Qt application to use whatever you set up. You can also use the "--platformtheme qt5ct" command line option.
You'll notice this in terminal output when running xnviewmp: qt5ct: using qt5ct plugin
Unfortunately, there is still a weird problem: if you use a different desktop environment (i3wm for example) and if you load another picture (from a file manager), the theme will get swapped to the Fusion Theme. More details there: https://wiki.archlinux.org/index.php/qt#Qt5
Fonts will stay fine though, but some widget buttons will get shuffled around and such. Very strange. Anyway, that should go to the XnViewMP developer. ;)
fuan_k commented on 2017-01-20 22:46 (UTC) (edited on 2017-01-20 22:55 (UTC) by fuan_k)
Had an error with this line, as it couldn't find the file (I never had it): rm "${pkgdir}/opt/${pkgname}/lib/"libicu*.54*
You might want to change for the following (I could be wrong, but I tested it and it worked I think):
if [[ -e "${pkgdir}/opt/${pkgname}/lib/"libicu*.54* ]]; then
rm "${pkgdir}/opt/${pkgname}/lib/"libicu*.54*
fi
Anyway, I still get issues with this package:
-remove qt.conf as usual (otherwise I get: This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".)
-the font is indeed still the wrong one. Still investigating... Have you guys tried using strace on this program? It's crazy the amount of libraries it's looking for in places that don't even exist... ugh.
Pinned Comments
Corax commented on 2017-01-21 15:34 (UTC) (edited on 2017-02-12 19:23 (UTC) by Corax)
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.