=== guiverc2 is now known as guiverc
=== guiverc2 is now known as guiverc
=== thibf7 is now known as thibf
=== ubuntu_4321 is now known as ubuntu4321
[22:24] <tsimonq2> sudip, jbicha, liushuyu, RikMills: Okay, so we now have libgit2 1.9 in plucky-proposed. This is the last release in the libgit2 1.x series, so I'd imagine we won't get to 2.x before Plucky's release.
[22:24] <tsimonq2> https://ubuntu-archive-team.ubuntu.com/transitions/html/libgit2-1.9.html#!good,bad,partial,unknown,!notintesting
[22:25] <tsimonq2> I'll get the NCRs out of the way, we'll just need some Rust updates again.
[22:32] <liushuyu> tsimonq2: Unfortunately Rust itself is somewhat sensitive to the libgit2 version changes
[22:33] <liushuyu> one reason is that it needs a binding to use the libgit2 C library
[22:33] <tsimonq2> liushuyu: It should be possible to update libgit2-sys without having to update the entire stack... right?
[22:33] <tsimonq2> Also, from the 1.9 changelog:
[22:33] <tsimonq2> The new LIBGIT2_VERSION_CHECK macro will indicate whether the version of libgit2 being compiled against is at least the version specified. For example: #if LIBGIT2_VERSION_CHECK(1, 6, 3) is true for libgit2 version 1.6.3 or newer. In addition, the new LIBGIT2_VERSION_NUMBER macro will return an integer version representing the libgit2 version number. For example, for version 1.6.3,
[22:33] <tsimonq2> LIBGIT2_VERSION_NUMBER will evaluate to 010603. Added by @HamedMasafi in #6882
[22:34] <tsimonq2> That might make it slightly easier
[22:36] <liushuyu> tsimonq2: Just checked, it seems like some struct had some layout changes. Only updating libgit2-sys will almost certainly causing a crash
[22:37] <liushuyu> We will need to cherry-pick some patches from the git2-rs upstream to adapt to the layout changes
[22:39] <liushuyu> So for cross-language projects, ABI is also very important, because on both sides of the language boundaries, they need to agree on the parameter/structure layouts
[22:41] <tsimonq2> Makes sense. I'm not in a huge rush to ram this through, and if you need any help I'm happy to assist how I can.
[22:42] <liushuyu> I will need to check if Debian Rust Team(s) is/are also doing their own transition(s)
[22:42] <tsimonq2> This is ahead of Debian, yeah; Utkarsh *really* needs a bouncer. :(
[22:43] <liushuyu> Well, then all those Debian micropackages won't be fixable. We don't really want to maintain those
[22:45] <liushuyu> Just to make sure we are not going to walk back the libgit 1.9 update in this release, right?
[22:46] <tsimonq2> We *can* if absolutely needed, but I'd also like Debian to pick up this update veryverysoon. Thus my frustration in trying to get ahold of Utkarsh.
[22:49] <tsimonq2> (I could NMU, but NMUing a transition seems noncollaborative at best.)
[22:52] <liushuyu> (I also don't think NMUing a new version to a package that has an active maintainer is a good idea)
[22:53] <tsimonq2> +1
[22:55] <tsimonq2> I filed a bug in Debian and CCed you
[22:57] <liushuyu> tsimonq2: Okay, thanks!
[22:57] <tsimonq2> liushuyu: Thank *you* for promptly bringing all this up :)
[22:57] <tsimonq2> I hope we can get this sorted soon.
[22:58] <tsimonq2> As always, if you're feeling ambitious, I'm happy to sponsor debdiffs.
[23:00] <liushuyu> tsimonq2: Well, "in theory", Rust should already have had all the libraries migrated away from libgit2. But due to a lot of difficulties (basically there is only one single person working on that), it hasn't happened yet
[23:01] <tsimonq2> That makes sense. Ideally yeah, we'd maybe only have to update e.g. libgit2-sys or similar :)
[23:01] <liushuyu> (I actually found it very impressive that a single person could write a Git client from scratch in a year)
[23:01] <tsimonq2> (That *is* quite impressive.)
[23:03] <liushuyu> In the meanwhile, I will start cherry picking the patches
[23:05] <tsimonq2> Thanks!