Search Criteria
Package Details: goldendict-ng-git 24.11.0.r5693.15207cf4-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/goldendict-ng-git.git (read-only, click to copy) |
---|---|
Package Base: | goldendict-ng-git |
Description: | The next generation GoldenDict (Supports Qt WebEngine & Qt6). |
Upstream URL: | https://github.com/xiaoyifang/goldendict-ng |
Keywords: | dict dictionary goldendict |
Licenses: | GPL3 |
Conflicts: | goldendict, goldendict-git, goldendict-git-opt, goldendict-svn |
Provides: | goldendict |
Replaces: | goldendict-git-opt, goldendict-svn, goldendict-webengine-git |
Submitter: | slbtty |
Maintainer: | slbtty |
Last Packager: | slbtty |
Votes: | 33 |
Popularity: | 0.068891 |
First Submitted: | 2023-04-17 09:38 (UTC) |
Last Updated: | 2024-10-27 04:24 (UTC) |
Dependencies (22)
- fmt (fmt-gitAUR)
- hunspell (hunspell-gitAUR)
- libebAUR
- libvorbis (libvorbis-aotuvAUR, libvorbis-aotuv-lancerAUR, libvorbis-gitAUR)
- libxtst
- libzim
- lzo
- opencc
- qt6-5compat
- qt6-base (qt6-base-gitAUR, qt6-base-headlessAUR)
- qt6-multimedia
- qt6-speech
- qt6-svg
- qt6-webengine
- tomlplusplus
- xapian-core (xapian-core-gitAUR)
- xz (xz-gitAUR)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat)
- cmake (cmake-gitAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- ninja (ninja-kitwareAUR, ninja-memAUR, ninja-fuchsia-gitAUR, ninja-gitAUR, ninja-jobserverAUR) (make)
- qt6-tools (make)
Required by (7)
- goldendict-cc-cedict-content (requires goldendict) (optional)
- goldendict-enruen-content (requires goldendict) (optional)
- myip-git (requires goldendict) (optional)
- stardict-full-eng-rus (requires goldendict) (optional)
- stardict-full-rus-eng (requires goldendict) (optional)
- stardict-indic-update (requires goldendict)
- translater-git (requires goldendict) (optional)
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »
jronald commented on 2023-07-31 10:10 (UTC)
But in practice it only use one thread. When I changed it to
it builds faster a lot.
slbtty commented on 2023-07-31 09:45 (UTC)
--parallel
is unnecessary because Ninja defaults to run commands in parallel.jronald commented on 2023-07-31 09:19 (UTC)
Could it boost build performance as below?
In PKGBUILD, change
to
or
slbtty commented on 2023-07-24 04:30 (UTC)
I plan to switch to CMake soon. It is thoroughly tested, but in case of any trouble, I have uploaded a stable package without -git https://aur.archlinux.org/packages/goldendict-ng, which still uses qmake
temhelk commented on 2023-07-12 01:13 (UTC) (edited on 2023-07-12 01:39 (UTC) by temhelk)
I checked a few of the ones that have r0 as their revision, and it looks like most of these were just published with the commit that has a tag on it. And if I would clone them, then pkgver that they return will be greater than r0. In these cases, I think they use the number of commits since the last versioned tag.
I think the way you did it should probably work well.
As for the need for it, in my case, I use aurutils and it utilizes pkgver. I think it could be necessary for some setups. It adds all the packages to a local repository that then can be used by multiple devices and in this case, for pacman to know that the version of a package is newer the pkgver of that package should be incremented.
Anyway, thanks for the work that you are doing!
slbtty commented on 2023-07-12 00:31 (UTC) (edited on 2023-07-12 00:33 (UTC) by slbtty)
Yes, you are right. Some tags were deleted, and it is not reliable.
I changed it to the number of commits.
TBH, I don't think this matters much for -git packages. For yay, the --devel flag appears to check the git hash instead of comparing the pkgver.
https://github.com/Jguer/yay/blob/23b053bccfd515756d85ed9b93df403250a35445/doc/yay.8#L359-L366
Every package is doing it differently. Some just set it to r0 and never change it. Not sure what's the best practice 😅.
https://aur.archlinux.org/packages?O=0&SeB=n&K=-git&outdated=&SB=p&SO=d&PP=100&submit=Go
temhelk commented on 2023-07-11 23:37 (UTC)
I'm kind of new to this, so I hope I won't say anything wrong. Right now, when I calculate "pkgver" for that package I get this - "23.06.02.r344.fc7a67d7". Which I think is not very good because the revision is smaller than what is published here (r344 < r356), and the tool that I use thinks that I need to update that package all the time. Could it be that you have some stale tags that were deleted from the upstream repository but are still present in your local repository? And does it make it a bad way to calculate pkgver?
slbtty commented on 2023-07-11 18:47 (UTC)
The tag count is added as
rREVISION
, which should be amonotonically increasing number
as described in the wiki.Thanks for pointing this out.
temhelk commented on 2023-07-11 17:50 (UTC)
Should this package contain a revision in its version? Like it's mentioned here https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
slbtty commented on 2023-06-18 03:47 (UTC)
Thanks, added :)
« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »