Package Details: libgit2-git 2:1.1.0.r279.g935f85131-1

Git Clone URL: (read-only, click to copy)
Package Base: libgit2-git
Description: A linkable library for Git
Upstream URL:
Licenses: GPL2
Conflicts: libgit2
Provides: libgit2
Submitter: herve
Maintainer: Nukesor
Last Packager: Nukesor
Votes: 10
Popularity: 0.000000
First Submitted: 2009-09-13 14:25 (UTC)
Last Updated: 2021-02-16 22:33 (UTC)

Required by (91)

Sources (1)

Latest Comments

Scimmia commented on 2018-01-16 12:48 (UTC)

You can package it for yourself, you can't put it in the AUR just because you want a newer version, and you certainly can't destroy a -git package to do it.

Anyway, fixed

albfan commented on 2018-01-16 12:34 (UTC)

strictly prohibited? So I cannot have a package libgit2-0.24 or libgit2-0.21 if I needed? Is this policy for real?

By the time ABS was 0.21 I (and I suppose others) need 0.25 (ahead from ABS). Should I provide a unstable version instead of a tar (iirc at that time git master fails compiling)

I don't need this package ahead of ABS anymore, so I will abbandon it so you can do whatever you want with it.

Scimmia commented on 2018-01-16 12:31 (UTC)

Or the original contributors, epoch, provides, conflicts, ...

eschwartz commented on 2018-01-16 11:53 (UTC)

You still have not restored the old pkgver() function.

Scimmia commented on 2018-01-15 23:32 (UTC)

Do you know what git is? Do you know what the -git at the end of the pkgname means? Go read the VCS package wiki page if you don't. As it is, you've destroyed this package. Reverting commits has nothing to do with rewriting history.

As for "policy to provide stable versions ahead from ABS", there is, it is strictly prohibited.

albfan commented on 2018-01-15 21:01 (UTC)

I receive this package to update to a version higher that 0.21, but stable. It do his work for a while.

@Scimmia is there a policy to provide stable versions ahead from ABS? If not then libgit2-git with an stable tar seems a good option.

There's no way to rewrite history, and I refuse to revert commits. You should know that.

Scimmia commented on 2018-01-15 17:19 (UTC)

Hint: start by reverting your last 2 commits, they are completely and totally wrong.

albfan commented on 2018-01-15 13:43 (UTC)

I will rework this to use git in a while

codyps commented on 2016-02-19 16:19 (UTC) (edited on 2016-02-19 16:19 (UTC) by codyps)

check() fails due to libgit2_clar failing. Adding CTEST_OUTPUT_ON_FAILURE=1 (which should be enabled by default in the PKGBUILD) tells me: online::clone::bitbucket_style [/tmp/pacaurtmp-cody/libgit2-git/src/libgit2/tests/online/clone.c:348] Function call failed: (git_clone(&g_repo, "", "./foo", &g_options)) error -1 - HTTP parser error: unexpected content-length header Unclear what the cause is.

rafi commented on 2014-07-02 18:13 (UTC)

Failed to checkout: fatal: ambiguous argument 'development': unknown revision or path not in the working tree.

thestinger commented on 2013-05-31 23:06 (UTC)

Python now cares more about the system locale, so that's the problem. Using an old version that doesn't care about the system locale may work but it's not a long-term solution to the problem.

stefano.facchini commented on 2013-05-31 22:58 (UTC)

thestinger, I don't know about the en_US.UTF-8 locale, but using python2 (with configure flag -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2) solves the problem

stefano.facchini commented on 2013-05-31 22:55 (UTC)

thestinger, I don't know about the en_US.UTF-8 locale, but using python2 (with configure flag -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2) solves the problem

stefano.facchini commented on 2013-05-31 22:50 (UTC)

thestinger, I don't know about the en_US.UTF-8 locale, but using python2 (with configure flag -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2) solves the problem

thestinger commented on 2013-05-31 22:22 (UTC)

You need the en_US.UTF-8 locale generated. It's one of the two locales generated in the root used for building with devtools, so the package has to hardcode it.

stefano.facchini commented on 2013-05-31 22:15 (UTC)

Build fails for me: Linking C shared library [ 24%] Built target git2 [ 24%] Generating tests-clar/clar.suite Traceback (most recent call last): File "", line 240, in <module> suite.load(options.force) File "", line 185, in load if not self.modules[name].refresh(path): File "", line 122, in refresh raw_content = File "/usr/lib/python3.3/encodings/", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 19532: ordinal not in range(128) make[2]: *** [tests-clar/clar.suite] Error 1 make[1]: *** [CMakeFiles/libgit2_clar.dir/all] Error 2 make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

yoseforb commented on 2013-04-16 17:13 (UTC)

And add the provides 'libgit2=0.18.0'

yoseforb commented on 2013-04-16 17:12 (UTC)

Add "-DTHREADSAFE=ON" option for support thread for libgit2-glib (for gitg). By the way, how can we build the documentation ?

thestinger commented on 2013-04-11 11:50 (UTC)

@eworm: sadly git describe can't be used because their tags are messed up only 0.16 is an annotated tag and 0.17 never properly ended up in the master branch

eworm commented on 2013-04-11 11:29 (UTC)

I would like to get some enhancements merge into the PKGBUILD. Take a look here: This makes use of pkgver() function to update package version string to git version. Additionally I've added -DTHREADSAFE=ON as this is needed for gitg from git.

msierks commented on 2012-04-25 14:38 (UTC)

Fix is to build with "-DBUILD_CLAR=OFF" option. The test suite has errors in it at the moment.

msierks commented on 2012-04-25 14:09 (UTC)

I cannot get this package to build. Could you please fix ?

herve commented on 2011-12-29 09:30 (UTC)

Thanks for the report. I lost interest in libgit2 months ago, feel free to adopt the package. Though I'm happy to see libgit2 has evolved a lot since then.

falconindy commented on 2011-12-27 21:17 (UTC)

Broken package due to build system change months ago. New PKGBUILD below with: - fixed arch (anything that compiles is _not_ an 'any' package) - fixed depends (needs zlib) - fixed build function (use cmake, not waf) - better description from upstream - package function (because repackaging is good)