Package Details: qtox-git 1.16.1.r32.ga12bb068d-1

Git Clone URL: (read-only, click to copy)
Package Base: qtox-git
Description: Powerful Tox client written in C++/Qt that follows the Tox design guidelines.
Upstream URL:
Licenses: GPL3
Conflicts: qtox
Provides: qtox
Submitter: prurigro
Maintainer: DragonX256
Last Packager: DragonX256
Votes: 112
Popularity: 0.009404
First Submitted: 2014-07-13 08:46
Last Updated: 2018-07-19 11:47

Pinned Comments

DragonX256 commented on 2017-03-01 15:25

Well, I updated package by myself. And it compiles fine now.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

farseerfc commented on 2016-05-13 12:26

@JZA where do you get tox-git? It's not in the AUR or official repositories. qtox-git depends on toxcore, so it cannot conflict with it.

JZA commented on 2016-05-13 10:12

this package conflict with toxcore:
==> Building and installing package
==> Install or build missing dependencies for qtox-git:
resolving dependencies...
looking for conflicting packages...
:: toxcore and tox-git are in conflict (tox). Remove tox-git? [y/N]

vith commented on 2016-05-03 16:25

I'm a bit late to the discussion about bumping the PKGBUILD on every commit/daily, but here are my thoughts:

# For
I appreciated automatically rebuilding on every git commit when I ran `pacaur -Syu`, if you don't want that, there's the non-git package that's only bumped for stable releases, or, you can add the git package to your ignored packages so you'll only see a warning about the new version being available but not automatically rebuild it. YMMV with other AUR helpers.

# Against
It's not what most AUR maintainers do so nobody's expecting it (clearly, from the other comments). I expect most AUR helper users won't be aware of the ignored packages feature available to them/all helpers might not have such a feature. Maybe a middle ground would be bumping this -git package only when there's a new tagged version.

Anyway, it didn't bother me, in fact it was convenient for me, but I'm not too bothered that it's gone either. I don't think it's too crazy of an idea. I had considered the possibility for other VCS AUR packages I maintain but just hadn't done it.

@kubrick actually the pkgver() is meaningful and does include the tag. it's `${latest_tag}.r${number_of_commits_since_tag}.g${commit_short_hash}`

farseerfc commented on 2016-04-26 11:24

@ShalokShalom I guess it is required for the general systray backend when SNI is not available, see

farseerfc commented on 2016-04-26 11:13

@kubrick Ok I am persuaded. I will let lilac to stop pushing to AUR. Sorry for the inconveniences in these days.

ShalokShalom commented on 2016-04-25 10:15

Please, why pack an qt app with gtk2?

kubrick commented on 2016-04-24 09:25

@farseerfc Not sure this is the best place to discuss this but while we're here... :=)
I still don't understand the point, why don't you just rebuild the package locally when you want an update? As you said, it will always pull the latest "head" anyway.
If every "-git" package was doing that, the daily update would be an absolute nightmare! I guess that most people who use a -git package just rebuild when they know their particular issue has been fixed or a feature has been implemented.
I think what you need is : and create an alternative "always" package like

farseerfc commented on 2016-04-24 04:46

@kubrick @bobi @LA-MJ Oh sorry I missed your comments sent to lilac.
Lilac is actually a build bot running on our server, that pulls in changes of the upstream and rewrite the PKGBUILD and rebuild the package and push the newly built binary package to our unofficial [archlinuxcn] repo. I setup lilac to update AUR so that the PKGBUILD on AUR is always up-to-date, which is usually a good thing.
Keep in mind that this is a VCS package, so breaks are unavoidable. And when you build it, you will get the latest package from upstream, regardless the update rate of AUR package. If you want a stable package, there is already qtox in [community].
Regarding to the changes of the qtox-git packages, I am following several issues of the upstream, some of which are already fixed in the qtox-git but not in qtox. (e.g. Using a daily build binary package helps me (and maybe upstream contributors) to follow the current development state of qtox. The point is, if you need bleeding edge package, lilac can make sure it is not too late than the upstream master branch.

kubrick commented on 2016-04-23 14:45

This is ridiculous. I'm uninstalling this package until this is sorted. pkgver is not even used to fetch a specific tag so you end up having a version number that means absolutely nothing.

bobi commented on 2016-04-22 07:18

Same here.