All the dependent packages built fine? Are the affected maintainers at least notified about this?

All the dependent packages built fine?

Yes. Most of them depend on libgit2 through rust-libgit2-sys, so it was main place where update needed to happen.

Are the affected maintainers at least notified about this?

Well, I am maintainer for most of dependent packages. The geany-plugins, git-evtag, julia and kf5-ktexteditor build just fine with new version, so there was no need to notify anybody.

I respectfully disagree about the "no need to notify anybody" even when there was no build failure.

However, assuming there will be no outcry by @dmaphy @ohaessler @pingou @walters @nalimilan @dvratil @jgrulich @rdieter @than, you'll have my +1.

I've seen the commit on the Geany-Plugins package and also the Bodhi update (got notification mails from pagure and bodhi). This was notification enough for me, actually. :-)

What I don't understand is, do you guys see any necessity to test the Geany VCS plugin beforehands? If yes, I'm just asking myself how if the update goes straight to stable? Probably that's some thing I just don't understand.

It was set as karma limit 1 (which I also don't understand) but will not be pushed before the release.

It was set as karma limit 1 (which I also don't understand) but will not be pushed before the release.

That is the default which I set by scripts I have... But after submitting update from side tag it is not possible to edit the update anymore :/

But after submitting update from side tag it is not possible to edit the update anymore :/

I've opened https://github.com/fedora-infra/bodhi/issues/4002

It's a bit unfortunate that there's an SONAME bump between the 0.99.0 "RC" and the 1.0.0 stable release ... but updating from a prerelease to a stable release sounds like a good idea to me, so long as the maintainers of the affected packages don't object (which it looks like they don't).

Well yes notifying is always nice.

I don't any rebuild of julia. Is that expected? :-/

Yep, looks like julia rebuild is missing from the update, as well in rawhide, where it still depends on libgit2.so.0.99()(64bit). @ignatenkobrain did you miss that one?

According to my repoquery, julia is the only missing package.

I see that @ignatenkobrain is trying to solve that problem, but julia failed to build.

Should we stop that update in the meantime?

I see that @ignatenkobrain is trying to solve that problem, but julia failed to build.
Should we stop that update in the meantime?

I added negative karma on the bodhi update now.

From the build log:

LibGit2/libgit2: Test Failed at /builddir/build/BUILD/julia/build/usr/share/julia/stdlib/v1.4/LibGit2/test/libgit2.jl:162
Expression: v.major == LIBGIT2_MIN_VER.major && v.minor >= LIBGIT2_MIN_VER.minor

That should be easy to fix ;)

Yes, I've just triggered a new build which should hopefully succeed.

you are not building it in the side tag, hence it is happening against libgit 0.99.0.

I've asked for the build to be cancelled. Will try to submit in the tag if I can figure out what is the tag name.

[julia (f32)]$ fedpkg build --target=f32-build-side-21550 --nowait
Could not execute build: Unknown build target: f32-build-side-21550

no idea :(

I've been talking with @mohanboddu on IRC. We are no longer able to build into the side tag once the update has been submitted for stable (even when revoked now). I've requested a buildroot override for libgit2-1.0.0-1.fc32 and will build julia and request a different update. Then, I'll remove the override.

I build it now in different side tag with libgit2-1.0.0 tagged there. Wait a bit.

I have added julia build to the update.

+1 to push this to F32

+1

As side note:

I have added julia build to the update.

How?

How?

bodhi updates edit --addbuilds julia-1.4.0-3.fc32 FEDORA-2020-cb72ecb134 --autotime

Glad the update is editable now \o/

Is the update stuck? It was last updated 4 days ago but is still pending->testing even though the last push to testing was (according to my own updates submitted 2 days ago) 15 hours ago. The current compose that started 3 hours ago also doesn't seem to mention it.

This is APPROVED (+3, 0, -0)

The update is on the way to testing, but indeed seem stuck.

It is stuck. bodhi thinks it's not all signed, even though it should be. We are investigating.

If I'm not mistaken, you've missed rebuilding R-git2r, and golang-github-libgit2-git2go.

golang-github-libgit2-git2go is only for 0.28, and the 1.0.0-compatible version is a different branch, so will get a different srpm, which I'll make after libgit2's stable. So there's not really any need to rebuild, but I thought I'd mention it since you didn't.

According to koschei, R-git2r is not ready for libgit2 1.0.0 and fails to compile against it.

• R-git2r depends on 0.28 (source: https://koji.fedoraproject.org/koji/rpminfo?rpmID=20153451)
• golang-github-libgit2-git2go does not need to rebuild, only things (binaries) which depend on it (which are not in Fedora)

• R-git2r depends on libgit2>0.26.0; 0.28 is just what it was last built against.
• golang-github-libgit2-git2go is used by git-time-metric, which is a binary in Fedora (but as I said, doesn't need rebuild.)