On May 18, 2018 11:50:35 PM GMT+05:30, Simon McVittie <[email protected]> wrote: >On Fri, 18 May 2018 at 21:18:49 +0530, Pirate Praveen wrote: >> libgit2 0.27 is now available in experimental. Please make sure your >package >> is ready for this version by the time we upload this package to >unstable in >> one to two weeks. > >Have you tried building reverse-dependencies like gitg against the >new libgit2?
I wanted to give a heads up earlier. I will rebuild all the reversed dependencies now. >How extensive are the API/ABI breaks in the new version of libgit2? My main motivation was to get ruby-rugged 0.27 which required newer libgit2. Only new symbols are added. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/commit/?id=814217455e3d06c9d7062e39f70352e96b595e64 >> The severity of this report will be raised to serious once >> libgit2 0.27 is uploaded to unstable. > >This is not how transitions work. "This package is involved in >a transition" is not a release-critical bug: packages affected by >transitions are normally rebuilt by binNMUs scheduled by the release >team, which cannot usefully close bugs. You should only open or >escalate >release-critical bugs if something is known to be wrong, such as gitg >failing to build from source against the new version of libgit2. This is first transition for me so I'm sure I missed some bits. That is also the reason to file bugs at this stage so people involved are aware. >The release team are unlikely to give you a transition slot for >uploading >the new libgit version to unstable until/unless you can estimate how >much >breakage it will cause and how much effort is involved in fixing it. Thanks for the tips, I will rebuild all reverse deps and escalate or close the bugs as required. >Thanks, > smcv -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
