Re: libgit2-dev and detection in subsurface/scripts/build.sh

[Cristian Ionescu-Idbohrn via subsurface]

On Wed, 14 Oct 2020, Dirk Hohndel via subsurface wrote:
> 
> I actually think that this isn't a bad idea. Except that it also 
> should have a clause that allows ldconfig to be found in the PATH, 
> right?

Sure, but are there distributions out there that place ldconfig in 
the non-root PATH?

> Would you mind submitting a PR for that, or would you prefer that I 
> do this based on your idea?

I think it's best you train your shell scripting skills a bit ;)


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: libgit2-dev and detection in subsurface/scripts/build.sh

[Dirk Hohndel via subsurface]

I actually think that this isn't a bad idea. Except that it also should have a 
clause that allows ldconfig to be found in the PATH, right?
Would you mind submitting a PR for that, or would you prefer that I do this 
based on your idea?

Thanks

/D

> On Oct 11, 2020, at 9:07 AM, Cristian Ionescu-Idbohrn via subsurface 
>  wrote:
> 
> Debian unstable here.
> 
> I did not have libgit2-dev installed and noticed this in build.log:
> 
>   ./subsurface/scripts/build.sh: line 268: ldconfig: command not found
>   realpath: missing operand
>   Try 'realpath --help' for more information.
> 
> That's because ldconfig is installed in /sbin/ldconfig and a non-root 
> user does not normally have access to /sbin.  Thus the detection will 
> always fail.  So, some sort of detection would be needed.  Something 
> like:
> 
>   if [ -x /sbin/ldconfig ]; then
>   LDCONFIG=/sbin/ldconfig
>   elif [ -x /usr/sbin/ldconfig ]; then
>   LDCONFIG=/usr/sbin/ldconfig
>   else
>   echo "no acces to ldconfig" >&2
>   exit 1
>   fi
> 
>   LIBGIT=$(realpath $($LDCONFIG -p | grep libgit2\\.so\\. |
>   cut -d\  -f4) | awk -Fo '{ print $NF }')
> 
> maybe?
> 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: libgit2-dev and detection in subsurface/scripts/build.sh

[Miika Turkia via subsurface]

On Sun, Oct 11, 2020 at 7:08 PM Cristian Ionescu-Idbohrn via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Debian unstable here.
>
> I did not have libgit2-dev installed and noticed this in build.log:
>
> ./subsurface/scripts/build.sh: line 268: ldconfig: command not
> found
> realpath: missing operand
> Try 'realpath --help' for more information.
>
> That's because ldconfig is installed in /sbin/ldconfig and a non-root
> user does not normally have access to /sbin.  Thus the detection will
> always fail.  So, some sort of detection would be needed.  Something
> like:
>
> if [ -x /sbin/ldconfig ]; then
> LDCONFIG=/sbin/ldconfig
> elif [ -x /usr/sbin/ldconfig ]; then
> LDCONFIG=/usr/sbin/ldconfig
> else
> echo "no acces to ldconfig" >&2
>         exit 1
> fi
>
> LIBGIT=$(realpath $($LDCONFIG -p | grep libgit2\\.so\\. |
> cut -d\  -f4) | awk -Fo '{ print $NF }')
>
> maybe?
>

or just add /sbin and /usr/sbin to PATH environment variable?
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

libgit2-dev and detection in subsurface/scripts/build.sh

[Cristian Ionescu-Idbohrn via subsurface]

Debian unstable here.

I did not have libgit2-dev installed and noticed this in build.log:

./subsurface/scripts/build.sh: line 268: ldconfig: command not found
realpath: missing operand
Try 'realpath --help' for more information.

That's because ldconfig is installed in /sbin/ldconfig and a non-root 
user does not normally have access to /sbin.  Thus the detection will 
always fail.  So, some sort of detection would be needed.  Something 
like:

if [ -x /sbin/ldconfig ]; then
LDCONFIG=/sbin/ldconfig
elif [ -x /usr/sbin/ldconfig ]; then
LDCONFIG=/usr/sbin/ldconfig
else
echo "no acces to ldconfig" >&2
exit 1
fi

LIBGIT=$(realpath $($LDCONFIG -p | grep libgit2\\.so\\. |
cut -d\  -f4) | awk -Fo '{ print $NF }')

maybe?


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: libgit2

[Lubomir I. Ivanov]

On 8 June 2018 at 21:18, Willem Ferguson
 wrote:
> Are there any new requirements with respect to libgit2?

not really.

> My previous builds
> (until yesterday all built perfectly. I have libgit2 V0.26, yet, now, with
> building the latest master I get:
>
> -- Checking for module 'libgit2'
> --   No package 'libgit2' found
> CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367
> (message):
>   A required package was not found
> Call Stack (most recent call first):
>   /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532
> (_pkg_check_modules_internal)
>   cmake/Modules/pkgconfig_helper.cmake:2 (pkg_check_modules)
>   cmake/Modules/HandleFindGit2.cmake:3 (pkg_config_library)
>   CMakeLists.txt:124 (include)
>

you can try cleaning the build completely.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

libgit2

[Willem Ferguson]

Are there any new requirements with respect to libgit2? My previous 
builds (until yesterday all built perfectly. I have libgit2 V0.26, yet, 
now, with building the latest master I get:


-- Checking for module 'libgit2'
--   No package 'libgit2' found
CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367 
(message):

  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532 
(_pkg_check_modules_internal)

  cmake/Modules/pkgconfig_helper.cmake:2 (pkg_check_modules)
  cmake/Modules/HandleFindGit2.cmake:3 (pkg_config_library)
  CMakeLists.txt:124 (include)

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 10/12] Support libgit2 api 0.24

[Anton Lundin]

Signed-off-by: Anton Lundin 
---
 core/git-access.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/core/git-access.c b/core/git-access.c
index fe3a918..6fe90b0 100644
--- a/core/git-access.c
+++ b/core/git-access.c
@@ -308,7 +308,11 @@ static int try_to_git_merge(git_repository *repo, 
git_reference **local_p, git_r
}
 
git_merge_init_options(_options, GIT_MERGE_OPTIONS_VERSION);
+#if !LIBGIT2_VER_MAJOR && LIBGIT2_VER_MINOR > 23
+   merge_options.flags = GIT_MERGE_FIND_RENAMES;
+#else
merge_options.tree_flags = GIT_MERGE_TREE_FIND_RENAMES;
+#endif
merge_options.file_favor = GIT_MERGE_FILE_FAVOR_UNION;
merge_options.rename_threshold = 100;
if (git_commit_lookup(_commit, repo, local_id)) {
-- 
2.7.4

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] Be compatible with libgit2 0.22 again

[Anton Lundin]

The callback function was introduced in 0.23, so put it behind that
ifdef.

Signed-off-by: Anton Lundin 
---
 git-access.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-access.c b/git-access.c
index a9e411e..b133a76 100644
--- a/git-access.c
+++ b/git-access.c
@@ -203,7 +203,6 @@ int certificate_check_cb(git_cert *cert, int valid, const 
char *host, void *payl
 static int update_remote(git_repository *repo, git_remote *origin, 
git_reference *local, git_reference *remote, enum remote_transport rt)
 {
git_push_options opts = GIT_PUSH_OPTIONS_INIT;
-   opts.callbacks.push_transfer_progress = _transfer_progress_cb;
git_strarray refspec;
const char *name = git_reference_name(local);
 
@@ -211,6 +210,7 @@ static int update_remote(git_repository *repo, git_remote 
*origin, git_reference
refspec.strings = (char **)
 
 #if USE_LIBGIT23_API
+   opts.callbacks.push_transfer_progress = _transfer_progress_cb;
if (rt == RT_SSH)
opts.callbacks.credentials = credential_ssh_cb;
else if (rt == RT_HTTPS)
@@ -527,8 +527,8 @@ static git_repository *create_local_repo(const char 
*localdir, const char *remot
int error;
git_repository *cloned_repo = NULL;
git_clone_options opts = GIT_CLONE_OPTIONS_INIT;
-   opts.fetch_opts.callbacks.transfer_progress = _progress_cb;
 #if USE_LIBGIT23_API
+   opts.fetch_opts.callbacks.transfer_progress = _progress_cb;
if (rt == RT_SSH)
opts.fetch_opts.callbacks.credentials = credential_ssh_cb;
else if (rt == RT_HTTPS)
-- 
2.1.4

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] Be compatible with libgit2 0.22 again

[Anton Lundin]

In libgit2 0.22 tree_flags was called flags.

Signed-off-by: Anton Lundin <gla...@acc.umu.se>
---
 git-access.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/git-access.c b/git-access.c
index 388fa27..e09deb6 100644
--- a/git-access.c
+++ b/git-access.c
@@ -195,7 +195,11 @@ static int try_to_git_merge(git_repository *repo, 
git_reference *local, git_refe
}
 
git_merge_init_options(_options, GIT_MERGE_OPTIONS_VERSION);
+#ifdef USE_LIBGIT23_API
merge_options.tree_flags = GIT_MERGE_TREE_FIND_RENAMES;
+#else
+   merge_options.flags = GIT_MERGE_TREE_FIND_RENAMES;
+#endif
merge_options.file_favor = GIT_MERGE_FILE_FAVOR_UNION;
merge_options.rename_threshold = 100;
if (git_commit_lookup(_commit, repo, local_id))
-- 
2.1.4

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 1/5] Upgrade libgit2 for android

[Anton Lundin]

Signed-off-by: Anton Lundin gla...@acc.umu.se
---
 packaging/android/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packaging/android/build.sh b/packaging/android/build.sh
index 63c99ff..f8d61e0 100644
--- a/packaging/android/build.sh
+++ b/packaging/android/build.sh
@@ -12,7 +12,7 @@ SQLITE_VERSION=3080704
 LIBXML2_VERSION=2.9.2
 LIBXSLT_VERSION=1.1.28
 LIBZIP_VERSION=0.11.2
-LIBGIT2_VERSION=0.23.0-rc1
+LIBGIT2_VERSION=0.23.0
 LIBUSB_VERSION=1.0.19
 
 # arm or x86
-- 
2.1.4

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Fix compiling against libgit2-0.22.1

[Gaetan Bisson]

Hi,

The attached patch fixes compile errors against libgit2-0.22.1.

It might not make sense at all but, for people like me who do not use
git storage but want to run a bleeding-edge subsurface, it does the job.
:)

Cheers.

-- 
Gaetan
From c8944f796712882b9ea7dced929c5af97e24889b Mon Sep 17 00:00:00 2001
From: Gaetan Bisson bis...@archlinux.org
Date: Sun, 14 Jun 2015 17:02:42 -1000
Subject: [PATCH] Fix compiling against libgit2-0.22.1

I have no idea whether the semantics is right, this patch was only
written so Subsurface compiles against the current stable release of
libgit2.

Signed-off-by: Gaetan Bisson bis...@archlinux.org
---
 git-access.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/git-access.c b/git-access.c
index 8433f70..22b407c 100644
--- a/git-access.c
+++ b/git-access.c
@@ -30,6 +30,13 @@
 #define git_remote_fetch(remote, refspecs, signature, reflog) git_remote_fetch(remote, signature, reflog)
   #endif
 #endif
+
+#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR == 22
+  #define git_remote_push(remote,refspecs,opts) git_remote_push(remote,refspecs,opts,NULL,NULL)
+  #define git_reference_set_target(out,ref,id,log_message) git_reference_set_target(out,ref,id,NULL,log_message)
+  #define git_reset(repo,target,reset_type,checkout_opts) git_reset(repo,target,reset_type,checkout_opts,NULL,NULL)
+#endif
+
 /*
  * api break introduced in libgit2 master after 0.22 - let's guess this is the v0.23 API
  */
-- 
2.4.3

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Fix compiling against libgit2-0.22.1

[Dirk Hohndel]

On Sun, Jun 14, 2015 at 05:23:11PM -1000, Gaetan Bisson wrote:
 Hi,
 
 The attached patch fixes compile errors against libgit2-0.22.1.
 
 It might not make sense at all but, for people like me who do not use
 git storage but want to run a bleeding-edge subsurface, it does the job.
 :)

This breaks the build for me with the version of libgit2 that I'm using...

But adding an additional !USE_LIBIT23_API check to the conditional makes
it work for me as well.

Thanks for the patch

/D

 From c8944f796712882b9ea7dced929c5af97e24889b Mon Sep 17 00:00:00 2001
 From: Gaetan Bisson bis...@archlinux.org
 Date: Sun, 14 Jun 2015 17:02:42 -1000
 Subject: [PATCH] Fix compiling against libgit2-0.22.1
 
 I have no idea whether the semantics is right, this patch was only
 written so Subsurface compiles against the current stable release of
 libgit2.
 
 Signed-off-by: Gaetan Bisson bis...@archlinux.org
 ---
  git-access.c | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/git-access.c b/git-access.c
 index 8433f70..22b407c 100644
 --- a/git-access.c
 +++ b/git-access.c
 @@ -30,6 +30,13 @@
  #define git_remote_fetch(remote, refspecs, signature, reflog) 
 git_remote_fetch(remote, signature, reflog)
#endif
  #endif
 +
 +#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR == 22
 +  #define git_remote_push(remote,refspecs,opts) 
 git_remote_push(remote,refspecs,opts,NULL,NULL)
 +  #define git_reference_set_target(out,ref,id,log_message) 
 git_reference_set_target(out,ref,id,NULL,log_message)
 +  #define git_reset(repo,target,reset_type,checkout_opts) 
 git_reset(repo,target,reset_type,checkout_opts,NULL,NULL)
 +#endif
 +
  /*
   * api break introduced in libgit2 master after 0.22 - let's guess this is 
 the v0.23 API
   */
 -- 
 2.4.3
 

 ___
 subsurface mailing list
 subsurface@subsurface-divelog.org
 http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

update on libgit2

[Dirk Hohndel]

I have been working with one of the developers on the libgit2 team and am
happy to announce that with his code libgit2 successfully uses an http
proxy and I can connect to the Subsurface cloud storage infrastructure
through a proxy.

Since this hasn't landed it libgit2 master, yet, I'm not quite ready to
push the code changes on the Subsurface side, but this is solving a huge
concern of mine regarding the viability of cloud storage in Subsurface.

It will mean that Subsurface 4.5 needs the very bleeding edge of libgit2
which of course has some issues of its own. But you win some, you lose
some :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Willem Ferguson]

On 19/02/2015 07:02, Miika Turkia wrote:



   As supossed, I had a v0.20.0  version built from scratch overlaped
   with the debian package. Cleaned it and the macro worked fine as
   debian version (v0.21.3) has three parameters defined .

   I think the wrapper was set to support three parameters because
   v0.21 (at least the one packaged in debian) had only those 3 and
   fourth was introduced  later.  But agree with you  3 completely
   different versions of the same library function in less than a  year
   is a mess  (saying it smooth and politely).

On Ubuntu Utopic (14.10) I also have the problem with only 1 parameter 
for git_remote _fetch

#define LIBGIT2_VERSION 0.20.0

I use the attached patch on my tree, but never sent it out as I have 
no clue about how the libgit versioning/API works.


miika

I was away for two weeks and got out of touch with respect to the mess 
with libgit2. I run Ubuntu 14.4 and the default version of libgit-dev is 
V19.
Does the latest Subsurface master run with libgit2 V19? The first #if in 
that file appears to provide for this


#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20

but I get make errors as discussed previously on this forum. Upon
applying Miika's patch (above, to git-access.c), I get the following:

.obj/git-access.o: In function `is_git_repository':
git-access.c:(.text+0x327): undefined reference to `git_remote_fetch'

Is there a sane solution for Debian/Ubuntu?
Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Lubomir I. Ivanov]

On 19 February 2015 at 07:02, Miika Turkia miika.tur...@gmail.com wrote:

 On Ubuntu Utopic (14.10) I also have the problem with only 1 parameter for
 git_remote _fetch
 #define LIBGIT2_VERSION 0.20.0

 I use the attached patch on my tree, but never sent it out


ideally we can have git_remote_lookup() in a separate #if branch (
22) since it now doubles.
but the patch is good, as is.

ack.

  as I have no clue about how the libgit versioning/API works.

it mostly doesn't. :\

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[libgit2] Compile issue on debian-unstable

[Salvador Cuñat]

Good night.

While compiling last git-master (2e6fcfc) I have had this problem:

compiling
git-access.c

git-access.c: In function
‘update_local_repo’:

git-access.c:23:65: error: too many arguments to function
‘git_remote_fetch’

   #define git_remote_fetch(remote, refspecs, signature, reflog)
git_remote_fetch(remote, signature,
reflog)


^

git-access.c:87:10: note: in expansion of macro
‘git_remote_fetch’

  error = git_remote_fetch(origin, NULL, NULL,
NULL);


^

In file included from
/usr/local/include/git2/clone.h:14:0,

 from
/usr/local/include/git2.h:17,

 from
git-access.c:11:

/usr/local/include/git2/remote.h:359:17: note: declared here
 GIT_EXTERN(int) git_remote_fetch(git_remote *remote);
 ^
Makefile:1464: recipe for target '.obj/git-access.o' failed

Debian Jessie actually ships  libgit2-21, so it's easy to solve, simply
building a libgit2-22 library, but it would introduce  an extra step in the
building instructions (at least, as removing 2-21 could break some
dependencies).

May be the #define can be changed to cover the older definition of
git_remote_fetch

Regards.

Salva.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Lubomir I. Ivanov]

On 19 February 2015 at 00:50, Salvador Cuñat salvador.cu...@gmail.com wrote:
 Good night.

 While compiling last git-master (2e6fcfc) I have had this problem:

 compiling git-access.c
 git-access.c: In function ‘update_local_repo’:
 git-access.c:23:65: error: too many arguments to function ‘git_remote_fetch’
#define git_remote_fetch(remote, refspecs, signature, reflog)
 git_remote_fetch(remote, signature, reflog)
  ^
 git-access.c:87:10: note: in expansion of macro ‘git_remote_fetch’
   error = git_remote_fetch(origin, NULL, NULL, NULL);
   ^
 In file included from /usr/local/include/git2/clone.h:14:0,
  from /usr/local/include/git2.h:17,
  from git-access.c:11:
 /usr/local/include/git2/remote.h:359:17: note: declared here
  GIT_EXTERN(int) git_remote_fetch(git_remote *remote);
  ^
 Makefile:1464: recipe for target '.obj/git-access.o' failed

 Debian Jessie actually ships  libgit2-21, so it's easy to solve, simply
 building a libgit2-22 library, but it would introduce  an extra step in the
 building instructions (at least, as removing 2-21 could break some
 dependencies).


i'm not very familiar with the Debian names, does the build break for
v.21 or v.22 (or perhaps is it v.20)?

 May be the #define can be changed to cover the older definition of
 git_remote_fetch


at some point we faced the issue the we cannot build Subsurface
against the latest libgit2 master, because there was no indication of
when they change stuff and their API breaks all the time. so it might
not be that easy :\.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Salvador Cuñat]

Hi Lubomir.

I think Debian's libgit2-21 is equivalent to  v0.21

I've just remembered I had a built (not debian package) libgit2 library,
may be it's still hanging around, as /usr/local/include/ is not the usual
install dir for debian.
Gonna take a look.

Regards.

Salva.

2015-02-19 0:22 GMT+01:00 Lubomir I. Ivanov neolit...@gmail.com:

 On 19 February 2015 at 00:50, Salvador Cuñat salvador.cu...@gmail.com
 wrote:
  Good night.
 
  While compiling last git-master (2e6fcfc) I have had this problem:
 
  compiling git-access.c
  git-access.c: In function ‘update_local_repo’:
  git-access.c:23:65: error: too many arguments to function
 ‘git_remote_fetch’
 #define git_remote_fetch(remote, refspecs, signature, reflog)
  git_remote_fetch(remote, signature, reflog)
   ^
  git-access.c:87:10: note: in expansion of macro ‘git_remote_fetch’
error = git_remote_fetch(origin, NULL, NULL, NULL);
^
  In file included from /usr/local/include/git2/clone.h:14:0,
   from /usr/local/include/git2.h:17,
   from git-access.c:11:
  /usr/local/include/git2/remote.h:359:17: note: declared here
   GIT_EXTERN(int) git_remote_fetch(git_remote *remote);
   ^
  Makefile:1464: recipe for target '.obj/git-access.o' failed
 
  Debian Jessie actually ships  libgit2-21, so it's easy to solve, simply
  building a libgit2-22 library, but it would introduce  an extra step in
 the
  building instructions (at least, as removing 2-21 could break some
  dependencies).
 

 i'm not very familiar with the Debian names, does the build break for
 v.21 or v.22 (or perhaps is it v.20)?

  May be the #define can be changed to cover the older definition of
  git_remote_fetch
 

 at some point we faced the issue the we cannot build Subsurface
 against the latest libgit2 master, because there was no indication of
 when they change stuff and their API breaks all the time. so it might
 not be that easy :\.

 lubomir
 --

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Lubomir I. Ivanov]

On 19 February 2015 at 02:14, Lubomir I. Ivanov neolit...@gmail.com wrote:
 i'm not sure why we have the wrapper for a 3 parameter
 git_remote_fetch(), as i can't find it in their log.
 fe3a40a4ff056400 is when git_remote_fetch() was added with one param
 and then it changed to 4 params at c3ab1e5af4c43d.


ok my bad, i do see a 3 parameter git_remote_fetch() at the v0.21 tag.
salvador, given your remote.h file says there is 1 parameter for said
function i think you may have a couple of versions of libgit
installed, probably the current used remote.h being from e.g. v0.20.

it would be best to uninstall both versions and install the latest
that the OS provides.
(and nuke the libgit people from orbit)

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Salvador Cuñat]

2015-02-19 1:14 GMT+01:00 Lubomir I. Ivanov neolit...@gmail.com:



 i'm not sure why we have the wrapper for a 3 parameter
 git_remote_fetch(), as i can't find it in their log.
 fe3a40a4ff056400 is when git_remote_fetch() was added with one param
 and then it changed to 4 params at c3ab1e5af4c43d.

 what a mess.

  I've just remembered I had a built (not debian package) libgit2 library,
 may
  be it's still hanging around, as /usr/local/include/ is not the usual
  install dir for debian.
  Gonna take a look.
 

 could be the case, but our macro may be wrong as well.
 l


Hi Lubomir.

As supossed, I had a v0.20.0  version built from scratch overlaped with the
debian package. Cleaned it and the macro worked fine as debian version
(v0.21.3) has three parameters defined .

I think the wrapper was set to support three parameters because v0.21 (at
least the one packaged in debian) had only those 3 and fourth was
introduced  later.  But agree with you  3 completely different versions of
the same library function in less than a  year is a mess  (saying it smooth
and politely).

Regards.

Salva.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [libgit2] Compile issue on debian-unstable

[Lubomir I. Ivanov]

On 19 February 2015 at 01:42, Salvador Cuñat salvador.cu...@gmail.com wrote:
 Hi Lubomir.

 I think Debian's libgit2-21 is equivalent to  v0.21


BTW, what does /include/git2/version.h says in terms of x.xx version?

c3ab1e5af4c43d added the 4 parameter version to git_remote_fetch()
(version.h was at 0.20).

0.21 *should* have the parameter version, but looking at your GCC
output of remote.h it says that git_remote_fetch() has one argument,
which shouldn't be the case.

but in general i think that we should use:

#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR  21
  #define git_remote_fetch(remote, refspecs, signature, reflog)
git_remote_fetch(remote)
#endif

i'm not sure why we have the wrapper for a 3 parameter
git_remote_fetch(), as i can't find it in their log.
fe3a40a4ff056400 is when git_remote_fetch() was added with one param
and then it changed to 4 params at c3ab1e5af4c43d.

what a mess.

 I've just remembered I had a built (not debian package) libgit2 library, may
 be it's still hanging around, as /usr/local/include/ is not the usual
 install dir for debian.
 Gonna take a look.


could be the case, but our macro may be wrong as well.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] api change in libgit2-0.22

[Dirk Hohndel]

On Thu, Jan 22, 2015 at 10:14:03PM +0100, Martin Gysel wrote:
 Yet another api change in libgit2...
 let's quote the website libgit2 is ... linkable library with a solid
 API ...

Yeah, right. What a mess. And I assume there is no easy check for the
exact commits where this happens, so for people who were on master for
libgit2 this might break their build now (which then can be fixed by
pulling latest master of libgit2)...

Oh well.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] api change in libgit2-0.22

[Martin Gysel]

Yet another api change in libgit2...
let's quote the website libgit2 is ... linkable library with a solid
API ...

Signed-off-by: Martin Gysel m...@bearsh.org
---
 save-git.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/save-git.c b/save-git.c
index a8f745c..6c2587b 100644
--- a/save-git.c
+++ b/save-git.c
@@ -26,6 +26,14 @@
   #define git_reference_set_target(out,ref,target,signature,log_message) \
git_reference_set_target(out,ref,target)
 #endif
+/*
+ * api break in libgit2 revision 0.22
+ */
+#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR  22
+  #define git_treebuilder_new(out, repo, source) git_treebuilder_create(out, 
source)
+#else
+  #define git_treebuilder_write(id, repo, bld)   git_treebuilder_write(id, bld)
+#endif
 
 #define VA_BUF(b, fmt) do { va_list args; va_start(args, fmt); put_vformat(b, 
fmt, args); va_end(args); } while (0)
 
@@ -464,7 +472,7 @@ static int tree_insert(git_treebuilder *dir, const char 
*name, int mkunique, git
  * set the unique flag, which will then append the SHA1
  * of the directory to the name when it is written.
  */
-static struct dir *new_directory(struct dir *parent, struct membuffer *namebuf)
+static struct dir *new_directory(git_repository *repo, struct dir *parent, 
struct membuffer *namebuf)
 {
struct dir *subdir;
const char *name = mb_cstring(namebuf);
@@ -477,7 +485,7 @@ static struct dir *new_directory(struct dir *parent, struct 
membuffer *namebuf)
 * and an empty treebuilder list of files.
 */
subdir-subdirs = NULL;
-   git_treebuilder_create(subdir-files, NULL);
+   git_treebuilder_new(subdir-files, repo, NULL);
memcpy(subdir-name, name, len);
subdir-unique = 0;
subdir-name[len] = 0;
@@ -489,7 +497,7 @@ static struct dir *new_directory(struct dir *parent, struct 
membuffer *namebuf)
return subdir;
 }
 
-static struct dir *mktree(struct dir *dir, const char *fmt, ...)
+static struct dir *mktree(git_repository *repo, struct dir *dir, const char 
*fmt, ...)
 {
struct membuffer buf = { 0 };
struct dir *subdir;
@@ -504,7 +512,7 @@ static struct dir *mktree(struct dir *dir, const char *fmt, 
...)
break;
}
if (!subdir)
-   subdir = new_directory(dir, buf);
+   subdir = new_directory(repo, dir, buf);
free_buffer(buf);
return subdir;
 }
@@ -595,7 +603,7 @@ static int save_one_picture(git_repository *repo, struct 
dir *dir, struct pictur
 static int save_pictures(git_repository *repo, struct dir *dir, struct dive 
*dive)
 {
if (dive-picture_list) {
-   dir = mktree(dir, Pictures);
+   dir = mktree(repo, dir, Pictures);
FOR_EACH_PICTURE(dive) {
save_one_picture(repo, dir, picture);
}
@@ -612,7 +620,7 @@ static int save_one_dive(git_repository *repo, struct dir 
*tree, struct dive *di
 
/* Create dive directory */
create_dive_name(dive, name, tm);
-   subdir = new_directory(tree, name);
+   subdir = new_directory(repo, tree, name);
subdir-unique = 1;
free_buffer(name);
 
@@ -738,7 +746,7 @@ static int save_one_trip(git_repository *repo, struct dir 
*tree, dive_trip_t *tr
 
/* Create trip directory */
create_trip_name(trip, name, tm);
-   subdir = new_directory(tree, name);
+   subdir = new_directory(repo, tree, name);
subdir-unique = 1;
free_buffer(name);
 
@@ -837,8 +845,8 @@ static int create_git_tree(git_repository *repo, struct dir 
*root, bool select_o
 
/* Create the date-based hierarchy */
utc_mkdate(trip ? trip-when : dive-when, tm);
-   tree = mktree(root, %04d, tm.tm_year + 1900);
-   tree = mktree(tree, %02d, tm.tm_mon + 1);
+   tree = mktree(repo, root, %04d, tm.tm_year + 1900);
+   tree = mktree(repo, tree, %02d, tm.tm_mon + 1);
 
if (trip) {
/* Did we already save this trip? */
@@ -1072,7 +1080,7 @@ static int do_git_save(git_repository *repo, const char 
*branch, bool select_onl
/* Start with an empty tree: no subdirectories, no files */
tree.name[0] = 0;
tree.subdirs = NULL;
-   if (git_treebuilder_create(tree.files, NULL))
+   if (git_treebuilder_new(tree.files, repo, NULL))
return report_error(git treebuilder failed);
 
/* Populate our tree data structure */
-- 
2.2.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 04:39, Thiago Macieira thi...@macieira.org wrote:
 On Sunday 07 December 2014 02:15:33 Lubomir I. Ivanov wrote:
 On 7 December 2014 at 00:42, Thiago Macieira thi...@macieira.org wrote:
  On Saturday 06 December 2014 15:49:57 Lubomir I. Ivanov wrote:
  +#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20 
  !defined(USE_LIBGIT21_API) git_threads_init();
  +#else
  +   git_libgit2_init();
  +#endif
 
  Conditional is broken

 does it break the build for you?

 Yes.

 ../../src/subsurface/main.cpp: In function ‘int main(int, char**)’:
 ../../src/subsurface/main.cpp:48:19: error: ‘git_libgit2_init’ was not
 declared in this scope


  The API changed for libgit2 0.22, not in 0.21.


ok, i see. looks like i got confused here.

 odd, can't find such a thing as 0.22 in version.h or in their tags.
 is the current master *actual* version hidden in some way, while 0.21
 is displayed in both git and the source?

 It's past the 0.21 tag, which means the change happened for version 0.22.
 More
 importantly, anyone installing the tagged and released versions 0.21, 0.21.1
 and 0.21.2 now has their builds broken.


0.21 works for me with the current solution.
is the attached patch the fix you are looking for?; if not perhaps you
can send a patch yourself.

BTW, they have releases marked 0.21.1, 0.21.2, but version.h doesn't
reflect it in master - it's at 0.21.0

just downloaded this:
https://launchpad.net/ubuntu/+source/libgit2/0.21.2-2
and version.h is 0.21.2 there, which means that these newer tagged
releases happen from other branches and makes checking for the RELEASE
digit unreliable, say if the user is using the master branch to build.

lubomir
--


0001-main.cpp-rework-the-libgit2-version-check.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 14:37, Lubomir I. Ivanov neolit...@gmail.com wrote:
 On 7 December 2014 at 04:39, Thiago Macieira thi...@macieira.org wrote:
 On Sunday 07 December 2014 02:15:33 Lubomir I. Ivanov wrote:
 On 7 December 2014 at 00:42, Thiago Macieira thi...@macieira.org wrote:
  On Saturday 06 December 2014 15:49:57 Lubomir I. Ivanov wrote:
  +#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20 
  !defined(USE_LIBGIT21_API) git_threads_init();
  +#else
  +   git_libgit2_init();
  +#endif
 
  Conditional is broken

 does it break the build for you?

 Yes.

 ../../src/subsurface/main.cpp: In function ‘int main(int, char**)’:
 ../../src/subsurface/main.cpp:48:19: error: ‘git_libgit2_init’ was not
 declared in this scope


  The API changed for libgit2 0.22, not in 0.21.


 ok, i see. looks like i got confused here.

 odd, can't find such a thing as 0.22 in version.h or in their tags.
 is the current master *actual* version hidden in some way, while 0.21
 is displayed in both git and the source?

 It's past the 0.21 tag, which means the change happened for version 0.22.
 More
 importantly, anyone installing the tagged and released versions 0.21, 0.21.1
 and 0.21.2 now has their builds broken.


 0.21 works for me with the current solution.
 is the attached patch the fix you are looking for?; if not perhaps you
 can send a patch yourself.

 BTW, they have releases marked 0.21.1, 0.21.2, but version.h doesn't
 reflect it in master - it's at 0.21.0

 just downloaded this:
 https://launchpad.net/ubuntu/+source/libgit2/0.21.2-2
 and version.h is 0.21.2 there, which means that these newer tagged
 releases happen from other branches and makes checking for the RELEASE
 digit unreliable, say if the user is using the master branch to build.


erm, that patch won't work for everyone...
i think i was trying to make a point that their API broke mid 0.21
(macro) version.

so do we have to use another macro such as USE_LIBGIT22_API?
ideas?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Dirk Hohndel]

 On Dec 7, 2014, at 4:49 AM, Lubomir I. Ivanov neolit...@gmail.com wrote:
 
 erm, that patch won't work for everyone...
 i think i was trying to make a point that their API broke mid 0.21
 (macro) version.
 
 so do we have to use another macro such as USE_LIBGIT22_API?
 ideas?

No, I think we need to realize that for some libraries you simply can’t build 
with master.
We can take your patch if it is modified to check for version 0.22. Once they 
switch version numbers, this will be the right thing to do.
In the meantime we need to document “do not build with master, only build with 
a tagged version”.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Thiago Macieira]

On Sunday 07 December 2014 19:09:03 Lubomir I. Ivanov wrote:
 also the version bump for 0.21 is not at the tag for 0.21, but before it.

Ask them to bump the master version to 0.22 already. In fact, you can probably 
contribute that change yourself :-)

Qt changes the version number in one of the first few commits after the 
branching for the release. In fact, we should change the 5.4 branch now to 
5.4.1.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 20:05, Thiago Macieira thi...@macieira.org wrote:
 On Sunday 07 December 2014 19:09:03 Lubomir I. Ivanov wrote:
 also the version bump for 0.21 is not at the tag for 0.21, but before it.

 Ask them to bump the master version to 0.22 already. In fact, you can probably
 contribute that change yourself :-)


seems like a bad idea,
i'm probably going to flame someone in the process... ;-)

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 20:18, Gaetan Bisson bis...@archlinux.org wrote:
 [2014-12-06 15:48:03 +0200] Lubomir I. Ivanov:
 +#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20  
 !defined(USE_LIBGIT21_API)

 This breaks building against libgit2 for me:

 main.cpp: In function 'int main(int, char**)':
 main.cpp:48:19: error: 'git_libgit2_init' was not declared in this 
 scope
   git_libgit2_init();
^
 Makefile:1198: recipe for target '.obj/main.o' failed

 I'm running an up-to-date Arch Linux system with libgit2-0.21.1;
 git2/version.h has:

 #define LIBGIT2_VERSION 0.21.0
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21
 #define LIBGIT2_VER_REVISION 0

 and USE_LIBGIT21_API is nowhere defined...


another patch was sent that supposedly fixes the mess.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 20:26, Lubomir I. Ivanov neolit...@gmail.com wrote:
 On 7 December 2014 at 20:24, Gaetan Bisson bis...@archlinux.org wrote:
 [2014-12-07 08:18:48 -1000] Gaetan Bisson:
 and USE_LIBGIT21_API is nowhere defined...

 Ah, well, maybe in subsurface-configure.pri; not sure why, though.
 There's no mention of git_libgit2_init anywhere in my libgit2 headers.


 and what does version.h say?


my bad, you already posted version.h

so if 'git_libgit2_init' isn't there and this is the case for version.h:
#define LIBGIT2_VER_MAJOR 0
#define LIBGIT2_VER_MINOR 21

there is no solution...it could be that the distro used another branch
to build the library.

from one of my earlier messages:
 799e22ea (API broken) is after 4fb32a44 (version.h bumped to 0.21).

799e22ea made the git_libgit2_init() change.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Thiago Macieira]

On Sunday 07 December 2014 20:22:48 Lubomir I. Ivanov wrote:
 On 7 December 2014 at 20:05, Thiago Macieira thi...@macieira.org wrote:
  On Sunday 07 December 2014 19:09:03 Lubomir I. Ivanov wrote:
  also the version bump for 0.21 is not at the tag for 0.21, but before it.
  
  Ask them to bump the master version to 0.22 already. In fact, you can
  probably contribute that change yourself :-)
 
 seems like a bad idea,
 i'm probably going to flame someone in the process... ;-)

Hi, I noticed that the master branch still says that libgit2 is version 0.21. 
When trying to build Subsurface with the master version, I'm getting build 
errors due to source-incompatible changes. Can I suggest that libgit2 change 
its version number soon after the release or at the latest at the same moment 
as a source- or binary-incompatible change lands?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Dirk Hohndel]

 On Dec 7, 2014, at 10:41 AM, Thiago Macieira thi...@macieira.org wrote:
 
 On Sunday 07 December 2014 20:22:48 Lubomir I. Ivanov wrote:
 On 7 December 2014 at 20:05, Thiago Macieira thi...@macieira.org wrote:
 On Sunday 07 December 2014 19:09:03 Lubomir I. Ivanov wrote:
 also the version bump for 0.21 is not at the tag for 0.21, but before it.
 
 Ask them to bump the master version to 0.22 already. In fact, you can
 probably contribute that change yourself :-)
 
 seems like a bad idea,
 i'm probably going to flame someone in the process... ;-)
 
 Hi, I noticed that the master branch still says that libgit2 is version 
 0.21. 
 When trying to build Subsurface with the master version, I'm getting build 
 errors due to source-incompatible changes. Can I suggest that libgit2 change 
 its version number soon after the release or at the latest at the same moment 
 as a source- or binary-incompatible change lands?

That email seems incorrect. It doesn’t mention “braindead”, “moron”, “clueless”,
or any of the other many relevant keywords…

:-/

So yes, if someone with better self control than me would like to engage the 
developers of libgit2, that would be great. Alternatively we could ask Linus to 
help :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 21:08, Joakim Bygdell j.bygd...@gmail.com wrote:
 Both your patches breaks building on Mac.

 llibgit2 version.h
 #define LIBGIT2_VERSION 0.21.2
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21
 #define LIBGIT2_VER_REVISION 2


and this one (attached)?

lubomir
--


0001-main.cpp-rework-the-libgit2-version-check.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Joakim Bygdell]

 On 07 Dec 2014, at 20:16, Lubomir I. Ivanov neolit...@gmail.com wrote:
 
 On 7 December 2014 at 21:08, Joakim Bygdell j.bygd...@gmail.com wrote:
 Both your patches breaks building on Mac.
 
 llibgit2 version.h
 #define LIBGIT2_VERSION 0.21.2
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21
 #define LIBGIT2_VER_REVISION 2
 
 
 and this one (attached)?
 
 lubomir
 --
 0001-main.cpp-rework-the-libgit2-version-check.patch

That one works.


/Jocke

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Gaetan Bisson]

[2014-12-07 20:32:14 +0200] Lubomir I. Ivanov:
 so if 'git_libgit2_init' isn't there and this is the case for version.h:
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21
 
 there is no solution...it could be that the distro used another branch
 to build the library.
 
 from one of my earlier messages:
  799e22ea (API broken) is after 4fb32a44 (version.h bumped to 0.21).
 
 799e22ea made the git_libgit2_init() change.

Well, there is no occurrence of libgit2_init in the 0.21.1 tarball:

https://github.com/libgit2/libgit2/archive/v0.21.1.tar.gz

-- 
Gaetan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

On 7 December 2014 at 21:34, Gaetan Bisson bis...@archlinux.org wrote:
 [2014-12-07 20:32:14 +0200] Lubomir I. Ivanov:
 so if 'git_libgit2_init' isn't there and this is the case for version.h:
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21

 there is no solution...it could be that the distro used another branch
 to build the library.

 from one of my earlier messages:
  799e22ea (API broken) is after 4fb32a44 (version.h bumped to 0.21).

 799e22ea made the git_libgit2_init() change.

 Well, there is no occurrence of libgit2_init in the 0.21.1 tarball:


you can try the last patch i posted in the thread.
it checks for 0.22 and only then it uses the git_libgit2_init() function.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] main.cpp: fix broken build for libgit2 0.21

[Lubomir I. Ivanov]

From: Lubomir I. Ivanov neolit...@gmail.com

799e22ea0c3f20 in libgit2 renamed a function, which
breaks our build. To fix that we check the current version
and if the USE_LIBGIT21_API definition was used.

Signed-off-by: Lubomir I. Ivanov neolit...@gmail.com
---
re-sending to the ML
---
 main.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/main.cpp b/main.cpp
index 7adc1f5..540e75a 100644
--- a/main.cpp
+++ b/main.cpp
@@ -42,7 +42,11 @@ int main(int argc, char **argv)
files.push_back(a);
}
}
+#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20  
!defined(USE_LIBGIT21_API)
git_threads_init();
+#else
+   git_libgit2_init();
+#endif
setup_system_prefs();
prefs = default_prefs;
fill_profile_color();
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Thiago Macieira]

On Saturday 06 December 2014 15:49:57 Lubomir I. Ivanov wrote:
 +#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR = 20 
 !defined(USE_LIBGIT21_API) git_threads_init();
 +#else
 +   git_libgit2_init();
 +#endif

Conditional is broken

The API changed for libgit2 0.22, not in 0.21.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Add libdivecomputer and libgit2 to Ubuntu building

[Miika Turkia]

On Sat, Nov 22, 2014 at 7:51 AM, Dirk Hohndel d...@hohndel.org wrote:

 On Sat, Nov 22, 2014 at 06:49:39AM +0200, Miika Turkia wrote:
  Some instructions how building libdivecomputer differs from Subsurface
  build. And mention to copy libigt2 over to other repository if needed.

 I have started to play with this and would like go a slightly different
 path (but I'd like your feedback).

 I would like to cheat when creating our packages. I'd like to AT LEAST
 include our private libdivecomputer and link statically against that.
 (I'd like our private marble as well, but that's a lot more work and most
 likely not worth it).

 So I was thinking of having a completely clean git directory layout like
 this:

 src/subsurface
 src/subsurface/libdivecomputer

 Both of these directories are whatever git version I want (let's say tip
 of master and tip of my private branch).
 Then cp that src/subsurface directory into src/subsurface-$VERSION

 then start building libdivecomputer first
 then build subsurface and make sure you link it against libdivecomputer.a

 Does that make sense?


sounds fine by me. I'll try to take a look at what the debian/rules file
should be for this. No promises though, as debain/ubuntu packaging is
somewhat mysterious territory.


 PS: here's the start of my script:

 #!/bin/bash
 # start from the directory above the combined subsurface 
 # subsurface/libdivecomputer directory
 VERSION=$(cd subsurface ; git describe | sed -e 's/-g.*$// ; s/^v//')
 echo building Subsurface $VERSION
 if [[ -d subsurface-$VERSION ]]; then
 rm -rf subsurface-$VERSION.bak.prev
 mv subsurface-$VERSION.bak subsurface-$VERSION.bak.prev
 mv subsurface-$VERSION subsurface-$VERSION.bak
 fi
 mkdir subsurface-$VERSION
 (cd subsurface ; tar cf - . ) | (cd subsurface-$VERSION tar xf - )
 cd subsurface-$VERSION/libdivecomputer

 # now make libdivecomputer

 cd ..

 # now create the Subsurface package with the libdivecomputer.a that we
 # just built

 Compiling both libdivecomputer and subsurface with the same debian/rules
should be doable, so no need for individually compile them. However, I am
not yet sure how the static compilation and linking can be done Debian way.
Will need to do some testing here.

The git version string for libdivecomputer should probably be manually
updated into libdc sources as the compilation is done outside of git tree,
and thus that string is not returned by subsurrace --version. At least
that is how it currently works from subsurface-beta Launchpad repository
(Subsurface v4.2.90, built with libdivecomputer v0.5.0-devel ()).

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Add libdivecomputer and libgit2 to Ubuntu building

[Dirk Hohndel]

On Sat, Nov 22, 2014 at 06:49:39AM +0200, Miika Turkia wrote:
 Some instructions how building libdivecomputer differs from Subsurface
 build. And mention to copy libigt2 over to other repository if needed.

I have started to play with this and would like go a slightly different
path (but I'd like your feedback).

I would like to cheat when creating our packages. I'd like to AT LEAST
include our private libdivecomputer and link statically against that.
(I'd like our private marble as well, but that's a lot more work and most
likely not worth it).

So I was thinking of having a completely clean git directory layout like
this:

src/subsurface
src/subsurface/libdivecomputer

Both of these directories are whatever git version I want (let's say tip
of master and tip of my private branch).
Then cp that src/subsurface directory into src/subsurface-$VERSION

then start building libdivecomputer first
then build subsurface and make sure you link it against libdivecomputer.a

Does that make sense?

/D

PS: here's the start of my script:

#!/bin/bash
# start from the directory above the combined subsurface 
# subsurface/libdivecomputer directory
VERSION=$(cd subsurface ; git describe | sed -e 's/-g.*$// ; s/^v//')
echo building Subsurface $VERSION
if [[ -d subsurface-$VERSION ]]; then
rm -rf subsurface-$VERSION.bak.prev
mv subsurface-$VERSION.bak subsurface-$VERSION.bak.prev
mv subsurface-$VERSION subsurface-$VERSION.bak
fi
mkdir subsurface-$VERSION
(cd subsurface ; tar cf - . ) | (cd subsurface-$VERSION tar xf - )
cd subsurface-$VERSION/libdivecomputer

# now make libdivecomputer

cd ..

# now create the Subsurface package with the libdivecomputer.a that we
# just built

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Cristian Ionescu-Idbohrn]

On Mon, 10 Nov 2014, Cristian Ionescu-Idbohrn wrote:

 The problem is debian packaging.  There's already a bug filed for
 that, as I mentioned in an earlier post.  See
 https://bugs.debian.org/768482.

And the bug is now closed.  A new libgit2-dev with proper dependencies
was released to debian unstable:

Depends: libgit2-21 (= 0.21.2-1), libz-dev, libssl-dev

It will probably soon migrate to debian jessie (next stable).


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Cristian Ionescu-Idbohrn]

On Mon, 10 Nov 2014, Dirk Hohndel wrote:
  On Nov 9, 2014, at 3:27 PM, Dirk Hohndel d...@hohndel.org wrote:
  Yes.  Thanks.  Unfortunately, there's still a problem when
  building subsurface from source :(
 
  It seems reasonable to at least document this on our web page.
  I'll try to do this today

 Done. Please let me know if this makes sense - it would be nice if
 people could add this to the translated pages as well

Look good.


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

ERROR: Package libgit2 not found

[Cristian Ionescu-Idbohrn]

Anyone else seeing this (on recent debian unstable)?

,
| $ qmake
| Project ERROR: Package libgit2 not found
`

Still, I have the libgit2 packages installed:

,
| libgit2-21:amd64install
| libgit2-dev:amd64   install
`

I have the libs:

,
| /usr/lib/x86_64-linux-gnu/libgit2.a
| /usr/lib/x86_64-linux-gnu/libgit2.so
| /usr/lib/x86_64-linux-gnu/libgit2.so.0.21.2
| /usr/lib/x86_64-linux-gnu/libgit2.so.21
`

and I see header files installed in /usr/include/git2.

And:

,
| $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/libgit2.pc
| libdir=/usr/lib/x86_64-linux-gnu
| includedir=/usr/include
|
| Name: libgit2
| Description: The git library, take 2
| Version: 0.21.2
| Requires.private:  openssl zlib libssh2
| Libs.private:  -lhttp_parser -lrt
| Libs: -L${libdir} -lgit2
| Cflags: -I${includedir}
`

What could cause the error?


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

FTBFS libgit2

[Salvo Tomaselli]

Is there anything new about libgit2 in the qmake file?

I get this
Project ERROR: Package libgit2 not found

I have the dev files installed, and I tried to have a look but it seems like a 
straightforward directive so I don't know where the problem is.

Using master from git.


-- 
Salvo Tomaselli

Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di 
senso, ragione ed intelletto intendesse che noi ne facessimo a meno.
-- Galileo Galilei

http://ltworf.github.io/ltworf/

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTBFS libgit2

[Dirk Hohndel]

 On Nov 9, 2014, at 9:10 AM, Salvo Tomaselli tipos...@tiscali.it wrote:
 
 Is there anything new about libgit2 in the qmake file?
 
 I get this
 Project ERROR: Package libgit2 not found
 
 I have the dev files installed, and I tried to have a look but it seems like 
 a 
 straightforward directive so I don't know where the problem is.
 
 Using master from git.

This hasn’t changed in several months and is working fine for people on other 
distributions.
I assume you are on some flavor of Debian?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Dirk Hohndel]

 On Nov 9, 2014, at 6:07 AM, Cristian Ionescu-Idbohrn 
 cristian.ionescu-idbo...@axis.com wrote:
 
 Answer to myself:
 
 $ pkg-config --print-errors --exists libgit2
 Package libssh2 was not found in the pkg-config search path.
 Perhaps you should add the directory containing `libssh2.pc'
 to the PKG_CONFIG_PATH environment variable
 Package 'libssh2', required by 'libgit2', not found
 
 I needed to install package libssh2-1-dev.  Patch attached.
 INSTALL needs to be updated too.

I don’t see Subsurface requiring libssh2. A quick git grep shows no mention. Is 
it possible that this is an issue with libgit2 packaging on Debian?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Dirk Hohndel]

On November 9, 2014 12:07:14 PM Tomaz Canabrava tcanabr...@kde.org wrote:


On Sun, Nov 9, 2014 at 3:43 PM, Dirk Hohndel d...@hohndel.org wrote:


  On Nov 9, 2014, at 6:07 AM, Cristian Ionescu-Idbohrn 
 cristian.ionescu-idbo...@axis.com wrote:
 
  Answer to myself:
 
  $ pkg-config --print-errors --exists libgit2
  Package libssh2 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libssh2.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'libssh2', required by 'libgit2', not found
 
  I needed to install package libssh2-1-dev.  Patch attached.
  INSTALL needs to be updated too.

 I don’t see Subsurface requiring libssh2. A quick git grep shows no
 mention. Is it possible that this is an issue with libgit2 packaging on
 Debian?


Looks so.
But if some compile libgit with ssh and others don't, it's not safer to
require both?


I'd prefer to understand what's going on. To me it seems packaging is 
broken for that package if it requires another package but doesn't have a 
dependency


/D


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Cristian Ionescu-Idbohrn]

On Sun, 9 Nov 2014, Cristian Ionescu-Idbohrn wrote:

 Package libgit2-21 shows these dependencies:

   Depends: libc6 (= 2.15), libhttp-parser2.1 (= 2.1),
libssh2-1 (= 1.2.3), libssl1.0.0 (= 1.0.0),
zlib1g (= 1:1.1.4)

 while the corresponding -dev package lists:

   Depends: libgit2-21 (= 0.21.2-1), libz-dev, libssl-dev

 libssh2-1-dev is missing from the dependency list.

 Fortunately, some debian developers/maintainers should be watching
 this list and react.

 Still, until the problem is taken care of, the workaround is to
 install libssh2-1-dev.  The patch for subsurface-configure.pri should
 not be needed, but reveals the problem.

There's even a bug files against libgit2-dev:

https://bugs.debian.org/768482

Nevertheless:

,
| $ qmake
| Project ERROR: Package libgit2 not found
`

is still confusing.


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Cristian Ionescu-Idbohrn]

On Sun, 9 Nov 2014, Dirk Hohndel wrote:
  On Nov 9, 2014, at 1:37 PM, Cristian Ionescu-Idbohrn 
  cristian.ionescu-idbo...@axis.com wrote:
 
  There's even a bug files against libgit2-dev:
 
  https://bugs.debian.org/768482
 
  Nevertheless:
 
  ,
  | $ qmake
  | Project ERROR: Package libgit2 not found
  `
 
  is still confusing.

 I agree. I’m not quite sure what to do about this. Do you have a
 suggestion for a patch that would fix the problem, Cristian?

I wish I had...  Oh well, at least we now know what the problem is and
how to work around it.  People with better knowledge of pkg-config
might have some idea.  /usr/lib/x86_64-linux-gnu/pkgconfig/libgit2.pc
looks like this on my box:

,
| libdir=/usr/lib/x86_64-linux-gnu
| includedir=/usr/include
|
| Name: libgit2
| Description: The git library, take 2
| Version: 0.21.2
| Requires.private:  openssl zlib libssh2
| Libs.private:  -lhttp_parser -lrt
| Libs: -L${libdir} -lgit2
| Cflags: -I${includedir}
`

What does that file show on other distributions?


Cheers,

-- 
Cristian
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: ERROR: Package libgit2 not found

[Dirk Hohndel]

On November 9, 2014 3:21:11 PM Cristian Ionescu-Idbohrn 
cristian.ionescu-idbo...@axis.com wrote:



On Mon, 10 Nov 2014, Salvo Tomaselli wrote:

 In data domenica 9 novembre 2014 09:43:12, Dirk Hohndel ha scritto:
  I don’t see Subsurface requiring libssh2. A quick git grep shows
  no mention. Is it possible that this is an issue with libgit2
  packaging on Debian?

 Subsurface in debian doesn't use libgit2, I wrote a patch to take it
 away because of the poor status of libgit2, otherwise Subsurface
 wouldn't have been in the upcoming stable release of debian.

Yes.  Thanks.  Unfortunately, there's still a problem when building
subsurface from source :(


It seems reasonable to at least document this on our web page. I'll try to 
do this today


/D


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface