Package Details: goldendict-ng-git 24.11.0.r5693.15207cf4-1

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)

Required by (7)

Sources (1)

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

cmake --build build_dir --parallel 8

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

cmake --build build_dir

to

cmake --build build_dir --parallel

or

cmake --build build_dir --parallel <jobs>

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)

And does it make it a bad way to calculate pkgver?

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 a monotonically 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 :)