Package Details: libepoxy-git 1.5.4+20+g34ecb90-1

Git Clone URL: (read-only, click to copy)
Package Base: libepoxy-git
Description: Library handling OpenGL function pointer management
Upstream URL:
Licenses: MIT
Conflicts: libepoxy
Provides: libepoxy
Submitter: haagch
Maintainer: haagch
Last Packager: haagch
Votes: 9
Popularity: 0.000001
First Submitted: 2014-03-15 20:58 (UTC)
Last Updated: 2020-11-13 21:12 (UTC)

Required by (226)

Sources (1)

Latest Comments

haagch commented on 2020-08-04 12:37 (UTC)

Huh, last time I touched this package was when it was still on Still builds without modifications here, what do you mean? Just increasing the version number?

shoober420 commented on 2020-08-04 12:13 (UTC)

Please update your PKGBUILD to reflect the official in the main repository.

TingPing commented on 2017-02-06 17:38 (UTC)

Here is an improved PKGBUILD using the meson build system support recently added, also fixes the version:

linkmauve commented on 2014-07-19 09:48 (UTC)

Hi, please add conflicts=('libepoxy'), or else installing libepoxy from [extra] won’t ask to remove this one.

Det commented on 2014-06-14 00:26 (UTC)

Right, but I thought Git would tag the minor versions itself? Not just the commit tag. Otherwise wouldn't that mean you'd have to tag every single commit for all Git packages? E: For example, with the original suggestion I currently get: $ git describe --tags --long | tr -d v | tr - . 1.2.8.gb2ae054-1 But the revision is actually pretty nice to know as well, so I'd probably just leave it as-is.

haagch commented on 2014-06-13 12:13 (UTC)

Now it's a compromise. :) I meant, this is using git commits AFTER 1.2.0 has been tagged, so development versions that can break at any time. Now if 1.2.0.g7422de5 has a breaking bug and I update to the next commit that fixes that bug, maybe it happens to have a hash 1.2.0.a123445 which is a lower "version", only when someone actually tags the next release version will the version really increase.

Det commented on 2014-06-13 12:00 (UTC)

I thought the next version would automatically be something like* or 1.2.1.g* (otherwise it doesn't really seem like Git's actually doing its job)? If not, then I still disagree on using the total number of commits as the major version just to get the incrementation okay. You could also say: $ echo $(git describe --long --tags | cut -d 'g' -f1)$(git rev-list HEAD --count).g$(git describe --always) | tr -d v | tr - . or if the g-tag is really that useless: $ echo $(git describe --long --tags | cut -d 'g' -f1)r$(git rev-list HEAD --count) | tr -d v | tr - . 1.2.0.r204 These are both pretty complex, I know, but when you say "" that's gonna mean "204th version, with minor release 1, and 2 bug fix releases". E: By the way, as per the previous request, git's missing from the makedeps.

haagch commented on 2014-06-13 09:37 (UTC)

I'm not a fan, because updates within one tag are not incremented monotonically... Maybe so: first number is commit number, then version tag, then hash.

Det commented on 2014-06-12 21:34 (UTC)

Perhaps a clearer version number: pkgver() { cd $_name git describe --tags --long | tr -d v | tr - . } 1.2.0.g7422de5

klusark commented on 2014-05-08 15:57 (UTC)

Could you add git to your makedepends?

nariox commented on 2014-04-23 18:45 (UTC)

Hmm, weird, reinstalling xorg-macros solved it for me... ô.ò

haagch commented on 2014-04-23 18:35 (UTC)

Well, for me it builds, but I am using testing and stuff.

nariox commented on 2014-04-23 18:18 (UTC)

Build failed for me with: error: must install xorg-macros 1.8 or later before running autoconf/autogen. Hint: either install from source, git:// or, depending on you distribution, try package 'xutils-dev' or 'xorg-x11-util-macros' But I do have extra/xorg-util-macros (version 1.19.0-1) installed

Xaap commented on 2014-04-12 12:58 (UTC)

Hi, Missing a makedepend on python (used to generate a source file)