DevHeads.net

Update libgit2 to 0.27

Hello everyone,

0.27.x is released long time ago, but I never got time for updating it. It
obviously involves SONAME change.

The good thing about this release is that it breaks only things in runtime
and only one function changed signature (for building) which nobody uses
anyway.

I'm going to update library as soon as I get time (possibly on this weekend
if no all dependent packages build fine). I will handle all rebuilds
myself, just sending a notice.

List of affected packages is below.
Maintainers by package:
R-git2r qulogic
geany-plugins dmaphy ohaessler pingou
ghc-bdcs-api clumens
ghc-gi-ggit dshea
git-evtag ignatenkobrain walters
gitg ankursinha ignatenkobrain nacho pwalter
julia nalimilan
kf5-ktexteditor dvratil jgrulich rdieter than
libgit2-glib ignatenkobrain kalev nacho pwalter
python-pygit2 pwalter
rubygem-rugged ignatenkobrain ktdreyer tdawson
rust-exa ignatenkobrain
rust-pretty-git-prompt ignatenkobrain ttomecek
subsurface pingou

Packages by maintainer:
ankursinha gitg
clumens ghc-bdcs-api
dmaphy geany-plugins
dshea ghc-gi-ggit
dvratil kf5-ktexteditor
ignatenkobrain git-evtag gitg libgit2-glib rubygem-rugged rust-exa
rust-pretty-git-prompt
jgrulich kf5-ktexteditor
kalev libgit2-glib
ktdreyer rubygem-rugged
nacho gitg libgit2-glib
nalimilan julia
ohaessler geany-plugins
pingou geany-plugins subsurface
pwalter gitg libgit2-glib python-pygit2
qulogic R-git2r
rdieter kf5-ktexteditor
tdawson rubygem-rugged
than kf5-ktexteditor
ttomecek rust-pretty-git-prompt
walters git-evtag

Comments

Re: Update libgit2 to 0.27

By Amit Saha at 08/16/2018 - 00:14

Hi Igor,

On Fri, Aug 10, 2018 at 4:33 PM Igor Gnatenko <

Thanks for your work. Just noticed that julia hasn't been built
succesfully (<a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=19172" title="https://koji.fedoraproject.org/koji/packageinfo?packageID=19172">https://koji.fedoraproject.org/koji/packageinfo?packageID=19172</a>)
. Seems to have failed with: "cc1plus: error: unrecognized command line
option '-mcet'"

This is currently an issue in Fedora Scientific building. What would be the
path forward here?

Thanks,
Amit.

Re: Update libgit2 to 0.27

By Zbigniew =?utf-... at 08/16/2018 - 04:37

On Thu, Aug 16, 2018 at 02:14:41PM +1000, Amit Saha wrote:
Drop '-mcet'? It's a bit hard to find docs for it, but [1] says:
"""-mcet -fcf-protection enables support for the Control-Flow
-Enforcement > Technology (CET) feature in future Intel CPUs. This
-involves the
generation of additional NOPs, which are ignored by the current
CPUs. It is recommended that you enable this flag now, to detect any
issues caused by them (e.g., interactions with dynamic
instrumentation frameworks, or performance issues)."""

It sounds like it's not something that is particularly needed at this
time.

The build log also has a lot of:
/usr/include/features.h:381:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^~~~~~~
This sounds like the package is not being built with the distro flags.

Zbyszek

Re: Update libgit2 to 0.27

By Amit Saha at 08/16/2018 - 20:30

On Thu, Aug 16, 2018 at 7:25 PM Zbigniew Jędrzejewski-Szmek <

<a href="https://fedoraproject.org/wiki/Changes/HardeningFlags28" title="https://fedoraproject.org/wiki/Changes/HardeningFlags28">https://fedoraproject.org/wiki/Changes/HardeningFlags28</a> seems to suggest
that this was implemented explicitly?

I am way out of touch, but a quick search for `mcet` in the package SRPM
and the source tarball from (<a href="https://src.fedoraproject.org/rpms/julia" title="https://src.fedoraproject.org/rpms/julia">https://src.fedoraproject.org/rpms/julia</a>),
didn't show up `mcet` being explicitly added either.

Re: Update libgit2 to 0.27

By Peter Robinson at 08/16/2018 - 06:48

On Thu, Aug 16, 2018 at 9:37 AM, Zbigniew Jędrzejewski-Szmek
< ... at in dot waw.pl> wrote:
A lot of the scientific stacks appear to do as they please here (they
might have an exception, I'm not sure), but they have a tendency to
use very x86 specific ones, in most cases if they used the distro ones
the code would actually build/run across mult arch platforms. After
getting yelled at for trying to fix it I moved on with life.

Peter