Search Criteria
Package Details: hydrus 530-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/hydrus.git (read-only, click to copy) |
---|---|
Package Base: | hydrus |
Description: | Danbooru-like image tagging and searching system for the desktop |
Upstream URL: | http://hydrusnetwork.github.io/hydrus/ |
Licenses: | custom |
Submitter: | Score_Under |
Maintainer: | Score_Under |
Last Packager: | Score_Under |
Votes: | 35 |
Popularity: | 0.75 |
First Submitted: | 2015-02-28 18:11 (UTC) |
Last Updated: | 2023-06-01 05:28 (UTC) |
Dependencies (36)
- emoji-font (noto-fonts-emoji-flags, noto-fonts-emoji-git, ttf-twemoji-color, noto-fonts-emoji-apple, ttf-twemoji, noto-fonts-emoji-blob, ttf-twemoji-color-git, ttf-ms-win11-auto, noto-fonts-emoji-flag-git, ttf-mutant-emoji, ttf-ms-win11, ttf-apple-emoji, ttf-whatsapp-emoji, noto-fonts-emoji, ttf-joypixels)
- hydrus-docs (hydrus-docs-dummy, hydrus-git)
- python (nogil-python, python36, python32, python39, python38, python37, python310, python312)
- python-beautifulsoup4
- python-html5lib (python-html5lib-git)
- python-lxml
- python-lz4
- python-mpv (python-mpv-git)
- python-numpy (python-numpy-git, python-numpy1.22, python-numpy-openblas, python-numpy-flame, python-numpy-mkl-bin, python-numpy-mkl)
- python-opencv
- python-pillow (python-pillow-git, python-pillow-simd)
- python-psutil
- python-pyqt6
- python-pysocks
- python-qtpy (python-qtpy-git)
- python-requests
- python-send2trash
- python-service-identity
- python-twisted
- python-typing_extensions
- Show 16 more dependencies...
Latest Comments
1 2 3 4 5 6 .. 12 Next › Last »
Score_Under commented on 2023-05-11 15:26 (UTC)
Thanks for the tip, I've confirmed the same on my own machine & added that to the list of required dependencies
guyven commented on 2023-05-11 14:57 (UTC)
After upgrading from version 526-1 to 527-1 I was unable to launch the application until I manually installed the
qt6-multimedia
package. This may need to be added to the dependency list, I have not done any in-depth investigation.This was the error before adding this package:
misagh commented on 2023-04-25 18:59 (UTC)
Thanks for finally making it happen. It's really appreciated. I will report if there are any issues.
joehillen commented on 2023-04-25 18:41 (UTC)
Thank you
Score_Under commented on 2023-04-23 16:04 (UTC) (edited on 2023-04-23 18:06 (UTC) by Score_Under)
The python2 issue was reported and fixed some time ago. I want to know what issue people are having now, after that migration. If the deps take a long time to install, that is surely only an issue when they are being removed between each build, but you should not be removing them if you intend to rebuild the software regularly.
As for mkdocs and its dependencies constantly breaking, I have never seen their compilation fail in recent memory, and barring quirks of my build system (i.e. no automatic dependency gathering and strict package name validation), neither has my build server:
I mentioned this last time and it bears repeating, this PKGBUILD already has a mechanism for excluding the docs makedeps: simply turn off docs in makepkg.conf. I have been asking people to tell me why this isn't an acceptable solution for them but all I've got are crickets, so what do I do with that?
Since this is clearly an issue that's still important to some regulars on here, maybe I'll try another tack: stub out docs in a readily available aur package that "provides" docs, and then split the package. Watch this space.
Upd: It's been split, and the dummy is in
hydrus-docs-dummy
. I've tried with yay and paru, and paru looks like it does a much better job (with yay showing a surprising failure to resolve dependencies), though neither seem to offer the alternative package by default.misagh commented on 2023-04-23 05:36 (UTC)
I don't understand what more we can tell you: mkdocs and its dependencies are a mess that constantly break. They frequently won't compile / install, and even if they do, they significantly increase the installation time of this package as mkdocs wants to not only compile, but run a million tests.
Worst part is, this is not entirely your responsibility because it's the hydrus developer who has created this dependency. However, since they "officially" ship hydrus in such a way that all deps are included, they don't care that this dependency causes issues in this aur package, which makes it our problem, and we already told you what solution we want: remove mkdocs and all its dependencies.
Also, I don't believe its reasonable to expect people here to identify and debug the actual issue beyond what has already been reported, due to python2 being EOL, and many of those dependencies being unmaintained.
Again, just separate the docs and the application. For the past couple of years, many of us have had to do this manually with this package anyways.
Kirtai commented on 2023-04-13 03:23 (UTC)
Ok, it's working fine now. I had the version just before the one where you added the QT_API=pyqt6 setting. It worked with "QT_API=pyqt6" too but then I updated.
Thanks :)
Score_Under commented on 2023-04-13 01:33 (UTC)
@Kirtai, I experienced the same issue when testing, and it seems to be some bad interaction with the Pyside6 API. I tried to work around this by setting
QT_API=pyqt6
in thehydrus-client
script, but of course if you override QT_API yourself or if you run it via any other script, it may not work correctly. Can you tell me if you have an existingQT_API
environment variable, and if you're running it through that script?Kirtai commented on 2023-04-13 00:14 (UTC) (edited on 2023-04-13 00:14 (UTC) by Kirtai)
Seems to be a failure to run with latest updates. 2023-04-13.
Score_Under commented on 2023-04-06 17:16 (UTC)
It would be nice if I knew what headache people are having from this. I'm certainly getting headaches from discussing this for 7 years with very little elaboration as to exactly what is going wrong! I have received some feedback about some dependencies being poorly maintained, but no elaboration past that as to exactly what maintenance troubles are impacting the end user (especially now that I have taken matters into my own hands when it comes to breaking the python2 dependency in the chain, going as far as to break AUR rules to do so while TUs were backlogged and eventually take over ownership of the packages in question), and I have put an exception in the PKGBUILD to remove the help pages and all dependencies downstream of that if the user chooses not to build docs (which is not a standard practice by any means, and as demonstrated, breaks all context-sensitive help features within hydrus and some of the help menu too, but crucially it solves the exact problem people have been discussing for so long in this thread). Many years ago, this package used to be split into three, building sources, docs and optimised bytecode into separate packages, but there were complaints about that setup too, because people's AUR helpers hit on bugs when they handled it - despite it being widespread and a documented standard - and they don't want to use anything else.
Please, instead of one-sided complaints that propose only a solution without detailing the problem and do not consider the impact of that solution on the majority of the userbase, tell me:
I want to avoid making this a half-assed semi-broken out-of-the-box experience for the average user, and breaking all context-sensitive help and half the help menu itself is at best going to give people a bad experience (especially newer users, as many of the more advanced tools have a steep learning curve), or at worst going to end up with a bunch of spurious bug reports against the Hydrus project itself about these features being broken.
If I were to split this package into two completely separate pkgbases, which I assume is what is being asked, then nobody would install the separate docs package even if they needed it. It wouldn't have the same presence when someone's just looking to "install Hydrus from the AUR". To the outside observer who hasn't been part of this discourse, it is just yet another feature that the AUR version botches for no good reason. Additionally, keeping them both up-to-date at the same time, in lockstep with each other's version, would both be more effort in terms of package maintenance (as I now have twice the packages to maintain per Hydrus update), and more effort in terms of system administration for the end user (as they will need to manage version conflicts and install them in the correct order).
At the risk of repeating myself, I don't want to break features just to satisfy a vaguely articulated gripe people have and which people have flatly refused to elaborate on when questioned. If I'm going to break the software for all users, I want a good reason to do it. I don't want to throw the baby out with the bathwater. I don't think that's asking too much.
1 2 3 4 5 6 .. 12 Next › Last »