Package Details: qutebrowser-git 0.10.1.r851.gcb5cd1a91-1

Git Clone URL: (read-only)
Package Base: qutebrowser-git
Description: A keyboard-driven, vim-like browser based on PyQt5 and QtWebKit
Upstream URL:
Keywords: browser web webkit
Licenses: GPL
Conflicts: qutebrowser
Provides: qutebrowser
Submitter: The-Compiler
Maintainer: The-Compiler
Last Packager: The-Compiler
Votes: 63
Popularity: 6.126267
First Submitted: 2014-11-11 21:47
Last Updated: 2017-06-20 15:54

Latest Comments

The-Compiler commented on 2017-07-03 04:44

@joemaro QtWebEngine will become the default backend with v1.0 somewhen later this year, at that point I agree it's a hard dependency. Before that, it's not, just like qt5-webengine isn't.

Where do you see "you recommend the people to use the webengine backend on the startpage of the browser and call the old engine "legacy""? I recommend people to not use a legacy QtWebKit, but there's also a newer QtWebKit, and Archlinux has packaged that as qt5-webkit since recently.

joemaro commented on 2017-07-02 16:42

python-opengl is imo a dependency: you recommend the people to use the webengine backend on the startpage of the browser and call the old engine "legacy" and then it won't run with webengine without having pyopengl installed.

The-Compiler commented on 2017-06-24 12:02

python-opengl is already listed as an optional dependency, just like qt5-webengine is.

cee commented on 2017-06-21 20:07

qutebrowser did not run because of missing python-opengl.
What speaks against ading `python-opengl` as a dependency?

mckean commented on 2017-06-21 12:20

I had an issue with pyopengl after the update and had to install it via pip. That doesn't seem entierely right, but it's working...

The-Compiler commented on 2017-03-15 19:31

buttcake: No - it's not required, and the scenario is too uncommon to even add it as an optional dependency.

buttcake commented on 2017-03-15 19:29

Shouldn't this require python-opengl as of ?

The-Compiler commented on 2017-03-07 07:00

Sorry this took so long - but the repo URL is now up-to-date (not that it'd make any difference :P), the pkgver check for qt5-webkit is removed, and userscripts are installed so that ":spawn -u" works for the ones in the repo.

As for the pkgver, I want to wait until v0.10.1 so I can test how to handle the tags correctly, see

hero commented on 2017-02-17 07:43

I second lucc's request to change the pkgver(). From you can see, that it is recommended to use the following for packages with tags:
pkgver() {
cd "$pkgname"
# cutting off 'v' prefix that presents in the git tag
git describe --long | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
This provides something in the likes of 0.9.0.r277.g79d22f250

I have not tested, if it demands to increment the pkgrel.

lucc commented on 2017-02-07 09:06

Could you use "git describe" in pkgver(). It has the advantage to include tag names into the output and hence the version number of aur/qutebrowser-git would better compare to the one of commuinty/qutebrowser.

For comparison, I get these kinds of version strings from other packages (pacman -Q|grep -e '-git '):
afew-git 1:0.242.b19a88f-1
i3pystatus-git 3.35.r179.g82555cb-1
mblaze-git r486.113445d-1
qutebrowser-git r11145.e487fe441-1
texlive-localmanager-git 0.5.1.r0.g6befd1e-1
vimpager-git 2.06.r337.ga7d18ce-1
zsh-history-substring-search-git 1:117.aae3388-1

It also seems that you would not even have to update (use) the epoch of the package as pacsort is happy to consider the new format I imagine a newer version. I tried this by updating the pkgver() like this (and some other variants):
pkgver() {
cd "$srcdir/qutebrowser"
local ver=$(git describe)
printf %s "$ver"
then executed makepkg and finally ask pacsort what it considers the newest version:
$ ls qute*xz|pacsort

(Please note that the 0.9.0 is due to issue #2284.)

All comments