Package Details: goldendict-ng-git 23.07.25.r4892.17cd4456-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
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: 29
Popularity: 1.23
First Submitted: 2023-04-17 09:38 (UTC)
Last Updated: 2023-07-26 07:27 (UTC)

Latest Comments

1 2 3 4 5 6 Next › Last »

shmu26 commented on 2023-08-01 17:47 (UTC)

Yes, installing base-devel fixed it. Thanks @slbtty !

slbtty commented on 2023-08-01 13:57 (UTC)

It says you don't have patch command when building libeb. Install base-devel should fix the problem.

shmu26 commented on 2023-08-01 13:32 (UTC) (edited on 2023-08-01 17:42 (UTC) by shmu26)

I get an error when building: [code]Starting prepare()... -> [patch] Applying libeb-4.4.3-14-010_debian.patch... /var/tmp/pamac-build-shmuel/libeb/PKGBUILD: line 27: patch: command not found ==> ERROR: A failure occurred in prepare().[/code]

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?

1 2 3 4 5 6 Next › Last »