Arch Linux User Repository

@Score_Under Thanks the issue has been solved by switching back

@misagh, I've given this a look and it does indeed seem to be true that pyqt5 alone hits on some bugs, so I've put a hard dependency for pyside2 in again.

As much as part of me wants to run on pyqt5 just to find the bugs... :)

Hello @Score_Under,

Please take a look at this suggestion by the hydrus developer with regards to using PySide2 as opposed to PyQt5: https://github.com/hydrusnetwork/hydrus/issues/1033#issuecomment-1003620540

Thanks for the hint @Score_Under! After rebuilding and then reinstalling python-mpv, everything works as expected now!

Reinstalling is likely a good enough solution, you don't even need the -git version.

Try pacman -Qo /usr/lib/python3.9 to see which AUR packages are still built for python 3.9 on your system. Those should all be reinstalled (with a clean build, if you get that option) so that they use python 3.10, the current Python version on Arch.

@And1G I Had the issue to. A bandaid would be installing python-mpv-git instead

Anyone else here who can not play videos within hydrus? Only getting "MPV is not available!" and a button to open videos externally. mpv and it's python bindings are installed.

hydrus 467-1 python-mpv 0.5.2-3 mpv 1:0.34.0-3

@Score_Under Thanks. The latest version of Hydrus has fixed this.

@misagh I don't think this is directly related to this package, but rather a problem with your installation of python qt5 bindings. If I were in your position I would check pacman -Qs qt5-python-bindings to see which qt5 bindings I have installed, then remove or reinstall them as necessary.

For me right now, I have these:

score@kirisame ~ % pacman -Qs qt5-python-bindings
local/pyside2 5.15.2-3 (qt qt5)
    Enables the use of Qt5 APIs in Python applications
local/python-pyqt5 5.15.6-2 (pyqt5)
    A set of Python bindings for the Qt5 toolkit

I tried removing pyside2 such that hydrus is definitely using pyqt5, and things still worked, so if possible I would say get python-pyqt5, make sure it's all up to date (not held back on an old AUR version or something), and remove the other bindings.

I don't really know your situation but I hope that leads somewhere helpful.

Hello, I was advised to report you this issue from the official Hydrus github repo: https://github.com/hydrusnetwork/hydrus/issues/1027

Currently the client is unusable for me due to this bug with the package.

Got this error after upgrading:

ImportError: libfmt.so.8: cannot open shared object file: No such file or directory

Solved by installing fmt from extra.

Note regarding v449:

I’m skipping v449 since it’s an experimental release; if you do want to use it, simply edit the PKGBUILD yourself (your AUR helper should provide that option): change the pkgver and update the commit hash in the source array.

Update for v439:

The issue with python-pyqt5 has been resolved and I've changed the dependency back to qt5-python-bindings.

---

---OUTDATED INFORMATION---

Note about v438:

For v438, I have swapped out the qt5-python-bindings dependency (which is satisfied by both pyside2 and python-pyqt5) with pyside2 because the v438 release broke the ability to use python-pyqt5 (see here).

I will change the dependency back to qt5-python-bindings once that issue has been resolved (hopefully in v439).

In the meantime, Hydrus should just work if you have both packages installed, because it will default to use pyside2. But if you do have QT_API=PyQt5 set when launching Hydrus, remove that, as it won't work at the moment (and also isn't necessary anymore in general; this was a workaround to force the use of python-pyqt5 when Hydrus didn't work correctly with pyside2 in the past).

@Amolith: Glad that fixed it. :)

@mser

The only thing I can think of how that could happen is that it's loading the module from elsewhere; e.g., if you also installed NumPy via pip.

That would be correct haha. It looks like I forgot to create a virtual env before manually installing requirements for a different application. Thank you so much!

@Amolith: From what I can see, your output looks fine (package versions seem correct too).

The error suggests an outdated NumPy version.

The only thing I can think of how that could happen is that it's loading the module from elsewhere; e.g., if you also installed NumPy via pip.

You can try:

➜  python -c "import numpy; print(numpy)"
<module 'numpy' from '/usr/lib/python3.9/site-packages/numpy/__init__.py'>

The path you see here is the one it should use if it you installed it via python-numpy package.

Also

➜  python -c "import sys; print(sys.path)"
['', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/usr/lib/python3.9/site-packages']

To see the paths it tries to load modules from in general.

@mser:

I just tried that and still got exactly the same errors. I uninstalled python-numpy, python-opencv, and hydrus, cleaned my cache, then reinstalled all three. Unless I'm misreading the output, both python packages were from the official repos and not the AUR.

https://asciinema.org/a/RCcgjfzHij01OYHRpCY39I1ff

@Amolith:

This looks like an issue with NumPy or/and OpenCV, but I can't reproduce it.

Please try reinstalling python-numpy and python-opencv. And make sure to install python-opencv from the official repo (here), not the version from the AUR. It wrongly links to the AUR version here in aurweb (because for some reason it apparently does that whenever there is a package of the same name in both the official repos and the AUR), but your AUR helper should prefer the official package.

I'm getting an error when I try to open hydrus and I'm not sure how to go about fixing it; I've done a clean build a couple of times but the issue persists. The output is in the pastebin below.

https://bin.nixnet.services/?15639b85d7539f52#HZWzoZ1F8Bmr4J7roBPMP7XdWiT6PGJHXnxNVm6cMZzX

The dependency of qt5-charts is not enough for Hydrus to display charts. It needs the python bindings (python-pyqtchart). I would consider this an optional dependency, since it runs fine without, just not displaying charts.

@Score_Under

Updated the paths-in-opt patch for 389:

https://invent.kde.org/snippets/767

python-matplotlib should be either added as a dependency or optional dependency, since it provides functionality within Hydrus (rendering charts of traffic in the network->review bandwidth usage tab).

@jtmb edit and maintainer, besides this being the last python2 release, as of 334 hydrus no longer uses pafy according to release notes so that dependency can be removed

@Score_Under, I was able to pull the pkgbuild from before python2-wxpython-phoenix was deleted and build it successfully. I wasn't getting any core.so issues, so hopefully it will work until they change over to python3.

https://pastebin.com/P2MJC4XZ

Edit: so apparently python2-pafy isn't getting built in its split package anymore, either, so here is a PKGBUILD to make python2-pafy until that switches over.

https://pastebin.com/mRBzWY4B

Good news is you won't have to deal with python2 for much longer http://hydrus.tumblr.com/post/180600042724/version-332

Next week should be more small stuff like this. Maybe some fun/new for 333 if I can fit it in. I mostly want to tidy up for a 'python 2 final’ 334 on the 12th Dec. On the 12th, I will break up for Christmas to convert the program to python 3.

Well, I've done something I know I will regret, and that's create a package for opencv with python2 support.

That said, python2-wxpython-phoenix has finally kicked the bucket, so that will need replacing. However, every build I have compiled on my own machine has somehow been missing an "init_core" function in its "_core.so". I can't make heads nor tails of this, and gave up some time early October, only to try again now and be faced with exactly the same problem. If anyone can figure out what on earth is going on here & how to compile wxpython-phoenix for python2, I would be grateful for the help.

@Score_Under same as @nadomodan, opencv 3.4.4-1, no /usr/lib/python2.7/site-packages/cv2.so

@Score_Under I have the same problem, opencv 3.4.4-1:

pacman -Qo /usr/lib/python2.7/site-packages/cv2.so

error: No package owns /usr/lib/python2.7/site-packages/cv2.so

downgrading to opencv 3.4.3-5 on which hydrus works gives this output:

pacman -Qo /usr/lib/python2.7/site-packages/cv2.so

/usr/lib/python2.7/site-packages/cv2.so is owned by opencv 3.4.3-5

I had the same problem as @jtmb and installed opencv2 from the AUR to solve it.

@jtmb, I can't reproduce this. Can you tell me what version of opencv you have installed, and whether it drops a "cv2.so" in /usr/lib/python2.7/site-packages?

client fails to start with

import cv2 ImportError: No module named cv2

I believe it's related to opencv but I haven't figured out a workaround.

http://hydrus.tumblr.com/post/179874662149/version-329

after discovering a pdf that ate indefinite 100% CPU while trying to parse, I have decided to stop pulling num_words for pdfs. it was always a super inaccurate number, so let’s wait for a better solution at a later date. hydrus hence no longer requires pypdf2

@Anfasa, check out: https://8ch.net/hydrus/res/10273.html#10342

As of v327, client fails to start (no module named ordered_dict). Seems to be related to urllib3's latest update: https://github.com/urllib3/urllib3/issues/1456

Although that was patched, and my packages are up to date.

python2-wxpython-phoenix is going to be removed: https://lists.archlinux.org/pipermail/aur-requests/2018-September/026757.html. Please create python2-wxpython4 as suggested.

as of v315, parsing is subtly broken when using python2-lxml (hydrus can use either python2-html5lib or python2-lxml). I recommend replacing the lxml dep with html5lib. If both are installed, html5lib will be used by default.

Regarding the official release archives

Indeed. To further explain the context for the benefit of others, the developer seems to have no experience or knowledge of OS best practices, general security concerns, or how to properly integrate software into any modern operating system. You can't package it as-is. He is receptive to suggestions and is respectful, but in general I think he is set in his ways. Another thing to point out is how he doesn't really use git- github is just a glorified webhost to him. No granular commits, no PR, no attention paid to issues. Just uploads a week's work in one commit. There are fewer commits than there are releases!

Because of this scattered haphazard strange development, changes are necessary when trying to integrate hydrus into a package manager. These changes either have to come from upstream, or the package maintainer. Since the dev doesn't use github-issues or accept PRs, if you want upstream changes you have to take your plight to either the imageboard or the discord. Both are filled with younger teens who also don't understand how computers works, and in general your voice will be drowned out by their insistence that the dev shouldn't waste time on things like that. Which is amusing, I don't think they appreciate how rare it is for a side project to consistently update week-by-week. There's plenty of development time to go around.

To be fair, some of the issues are inherit to targeting Windows as the primary platform.

@qlipsos, thanks for the heads up, I've added it to the requirements.

@irlittz, the split-package structure is mostly because it was easier to keep it that way. If it's causing problems I can easily switch it back. Regarding the official release archives, that's partly why I decided to create an AUR package in the first place. They contain a lot of packaged binary dependencies (which are an unnecessary risk), strip permissions (everything is 755), and end up with the incredible filesize of 176MB. Updates from git generally pull less than 1MB per version, which makes the whole process go a lot faster (considering download time and extraction time).

'gtkglext' was required in my case.

Thanks! Is there a reason why your PKGBUILD still has the split-package structure or why you are not using the official release archives?

Apologies for keeping you waiting. I've finally pushed the 290 update (and included working recipes for 289 and 288 in the history just in case).

I see you've found the complications already - there is no python 2 version of wxpython 4+ on the AUR yet. I'm not too sure of the implications either of installing both wxwidgets 3.x and 4.x at the same time, though there are no filesystem-level conflicts.

@Score_Under are there any complications in updating the package? The current release version seems to be at version 290.

Updated hydrus PKGBUILD: https://gist.github.com/anonymous/6f7cee87768108c334d3a75749a6e383

Modified wxpython-phoenix PKGBUILD: https://gist.github.com/anonymous/ecc4b7bf4e6f4fedcb075336c3874f6a

I'll ask the creator for wxpython-phoenix to turn it into a split package. The name might change. After installing both of these Hydrus 290 starts, however I had to manually specify the path to my Hydrus database using the -d option.

The python-lz4 manual update shouldn't be necessary any more - I've succeeded in taking ownership of the package and updated it to the latest version.

@Score_Under thank you for updating! For anyone else wanting to install this now: you'll have to manually update the PKGBUILD for python2-lz4 and install it yourself. This is what I did https://gist.github.com/anonymous/ad3eeb8577ed41f704a11497304baf9f. Feel free to use, if you think it is adequate. EDIT: Nevermind, apparently Score_Under has ownership of that package now, and it is updated. Thank you again.

@Score_Under did you abandon this package? I'm asking because it would have been easily possible to create a temporary AUR package that provides/replaces python2-lz4 instead of waiting for more than a month for a change that is not coming. When you hopefully get around to doing this, adding hdf5 as a dependency will be needed.

Any news on python2-lz4? If aurifier is MIA then it should have been orphaned by a TU by now. It's been nearly a month since you filed the request.

Currently waiting for python2-lz4's arch package to update before we can update this package any further. I'm going to see if I can claim it.

python2-socks dependency should be replaced with arch's official package of python2-pysocks, it provides the same software

Guys, please stop flagging the release out of date less than a day after the release. I am well aware of the release schedule and am subscribed to the github release notifications.

I had no idea the upstream package was so convoluted. You're certainly doing good work, and I appreciate that you have been maintaining the paths-in-opt.patch to provide a sane install. The bug in yaourt created a mild inconvenience which will now be avoided- it won't behave 'exactly the same', if that is any consolation. I'm not familiar with python but I am aware of python bytecode. The packages I deal with always install source, and setup.py stores the bytecode in __pycache__ folders alongside the source. I believe this is standard operating procedure; I may not be able to tell you why it should be done this way, but I don't see a reason to defy convention either. Thanks, though!

This has a source package because it is written entirely in Python, which is in theory a source-only language. In practice, libraries and programs in python should be (and are) compiled down to .pyc/.pyo files to reduce startup time. That process leaves the source code irrelevant, other than for error reporting. Python has no way of including debug info other than as source code, and it's customary to provide source anyway, so I don't think there's any question that the source code should be provided by this PKGBUILD. The only question is whether to split them into different packages or not. As for the docs, I don't quite remember why I first had them in a separate package. It was probably just that the documentation wasn't all in the right directory at the time. Given that the DOC_DIRS method of filtering docs out from the package seems to be working correctly, and that the other Python packages in the arch repos serve as a precedent for packaging python modules with their sources, I've decided to roll all three packages into one. However, even though it's a little more in line with how other things are packaged now, I can't see what the practical outcome of this change is. Yaourt users are going to experience exactly the same, being unable to choose which packages to install (because there is now only one package), and users of other AUR helpers must now install everything. While I am usually a fan of packages which are split in such a way as to give you "everything you need" in one package and extras in others, in this case people can just build the AUR package with modifications if they want to. Regarding its distribution as one package from upstream, I don't want to follow the author's example there because I don't trust their packaging skills. There is a 125MB package provided on GitHub with an installed size of 282MB(!!), which includes everything from the requisite python libraries right down to libx11, gtk, and readline. It includes ffmpeg, swfrender, and upnpc as binaries. Even the Windows binaries are included. As a result of how it packages the source, it ties itself to an architecture right off the bat, which no pure-Python code should need to do. It makes stack traces useless due to how the executables are built, despite containing a complete copy of the source code. Even ignoring the package itself, the upstream source doesn't provide an equivalent to setup.py, which is a fundamental of python software packaging. Given that the package does not even make the distinction between what is part of Hydrus and what is part of the operating system, I will not use that package as an example for how to appropriately divide the Hydrus AUR package. In fact, the problems with the official package are what initially motivated me to begin the Hydrus AUR package. tl;dr: done, but why (practically speaking)?

Makes sense that it's a yaourt bug. I've never encountered it before (which I think says something about how common it is to do this), and I'm not sure what benefit this structure of sources/docs/main brings us. Docs are never separated from the package they describe, so the existence of this as a discrete package confuses me. Hydrus' source is upstream, if you want access to the source, 'makepkg --noprepare --nobuild' (or any of the other many ways) suffice. Having an entire package for the source confuses me, and I can't say I've ever seen a source package. Finally, hydrus is distrubted as one package from upstream. What benefit do we gain from dividing this release into three- and does this benefit warrant bucking the more common established ways to get at the docs and source?

@Aelius I think splitting the package out into three would be the wrong behaviour, since the docs and sources basically come for free in the git repo. Packaging them while packaging the base hydrus package is the simplest way to go about it. I don't think separating into separate PKGBUILDs is any more proper. If you have the ABS checked out, take a look: $ grep -r package_ /var/abs It's a very common idiom in official PKGBUILDs to package related software alongside each other if that makes it quicker and simpler to package things. Yaourt queueing all three for install is a bug in yaourt, rather than this PKGBUILD. Since makepkg supports building multiple packages from one PKGBUILD, the failure to correctly wrap that feature is entirely on Yaourt. There are other AUR tools like pacaur which can correctly install one package at a time. Regarding rolling it all into one package, I don't see much difference between that behaviour and Yaourt's current behaviour. Either way, yaourt will install everything provided by the PKGBUILD. Other AUR helpers will do the right thing, but rolling it all into one package would be throwing out a useful feature (and what I feel are self-evident packaging standards) just to work around the behaviour of broken AUR tools. So for those reasons I'd rather not split this PKGBUILD out or merge all three packages.

The structure of this PKGBUILD causes yaourt to get confused. yaourt sees hydrus, hydrus-sources, and hydrus-docs all as individual packages to be installed; these are all queued for install. The 'hydrus' package alone installs all of them, but since the other two are already queued, yaourt will go through the motion of installing sources and docs anyway. I think you should either just include docs/sources under this package, or properly separate those packages into their own PKGBUILDs.

As far as I can tell Hydrus doesn't use Twisted's TLS client. It starts up fine without that package, so maybe it could go in optional dependencies, but since I don't see it being used anywhere in the code I think I can get away with leaving it out of the dependency list.

You should add extra/python2-service-identity to dependencies as otherwise hydrus-client complains about it when started: > :0: UserWarning: You do not have a working installation of the service_identity module: 'No module named service_identity'. Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied. Without the service_identity module and a recent enough pyOpenSSL to support it, Twisted can perform only rudimentary TLS client hostname verification. Many valid certificate/hostname mappings may be rejected.

Looks like you might need to add more dependencies. Crash.log: ImportError: No module named lxml ImportError: No module named request extra/python2-lxml extra/python2-requests

OK, thanks for the input. This might be an upstream bug, but in case it isn't: 05:08:03 PM: Warning: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx containers,compatible with 2.8), and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8). [1] 19178 segmentation fault (core dumped) hydrus-client

On two separate occasions I've intended to reply to you but ended up getting distracted and not hitting the reply button. I wouldn't be opposed to someone else cloning this package for a git version (or maybe I could make one myself?), but I would be hesitant to make/maintain one for a few reasons: 1. It's easy to do it yourself by removing "#commit=...." from the source list. If you're using an AUR automator like pacaur or yaourt, you can use the option to view the PKGBUILD before you update as your opportunity to make this change. 2. Picking by commit is an effective way to ensure that the source has not been tampered with 3. Sometimes the patches may leave the code inconsistent, e.g. if the Hydrus dev adds another "help" option 4. I would need to push the same code to two different repositories each time

What do you think about making a git version of this package, complete with your patches and other tweaks? While the hydrus git is exclusively used for releases, it would still be useful to have the aur-git version, to update hydrus the moment the dev releases an update. The git version would also require no maintenance on your part so long as the patches still apply.

If desktop-file-utils is not installed, an error is thrown during install (but the install succeeds and hydrus works fine). Perhaps you should add it as a requirement, suppress the error, or remove whatever is calling it.

This has a few differences from the original so I feel I should explain them here: * hydrus-client and hydrus-server are very small scripts which run the client and server respectively, rather than making you use "python2 /opt/hydrus/client.pyw". * the paths-in-opt patch file tweaks Hydrus' use of paths so that it doesn't choke when it's in a read-only part of /opt, and makes it store read-write data in ~/.local/share/hydrus * the running-the-server patch file alters how it runs the server from the client - instead of making it figure out which python executable to use (it chooses wrong anyway), it will just run the "hydrus-server" script