Description of problem:
Whenever I push a commit to Fedora's git, I am seeing this warning:
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 367 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: /usr/lib64/python2.7/site-packages/cffi/model.py:526: UserWarning: 'git_checkout_notify_t' has no values explicitly defined; next version will refuse to guess which integer type it is meant to be (unsigned/signed, int/long)
remote: % self._get_c_name())
remote: /usr/lib64/python2.7/site-packages/cffi/model.py:526: UserWarning: 'git_merge_tree_flag_t' has no values explicitly defined; next version will refuse to guess which integer type it is meant to be (unsigned/signed, int/long)
remote: % self._get_c_name())
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 3 commits
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Checkout a package from fedora's git using fedpkg
2. Apply changes and "git commit"
3. git push
I too noticed this today.
same notices here.
Hi guys, I have it on my todolist for current week.
So I look at it closer and the most probably it is problem of "inconsistent" packages on the server. Same problem occurs on various system, doesn't matter what version of git is used.
According to reported problem here , it was because of bump the python-cffi2 to newer version (on CentOS/RHEL 7.3), but libgit2 and python-pygit2 have not been updated. It seems that it can be resolved by using of current packages from Fedora 25, however it is not bug of packages on Fedora obviously. I don't know how this can be reported to admins or if they know about that already. According to  rhbz, there were troubles with incosistency between python-cffi and python-pygit2 packages and there was pushed new rpm in similar date as this bug
have been reported.
I am closing the bug as this is obviously not fault of the Git and probably it is not even bug of any Fedora package. I will try contact someone from sysadmins of servers with dist-git repositories.
This is a problem in the pygit2/libgit2 package version in EPEL7, which is indeed not git: they're separate implementations of git, sharing none of the codebase.
The pygit2 and libgit2 versions need to be kept in lockstep, which seems to have been missed for the RHEL7.3 update.
The bugzilla that was pointed to in the last comment was about a totally broken combination.
After a rebuild, it does work, just prints this ugly warning for a lot of interactions.
As such, I am reassigning this bug to pygit2, so that the maintainer can take care of it.
Do note: this is a warning, so you can safely ignore it.
I wonder why this BZ was assigned to EPEL7? I had reported this BZ against F25 and still am facing it on F25.
Also, is anybody actually working on fixing this? Meanwhile several people reported it on several mailing lists.
(In reply to Ralf Corsepius from comment #6)
> I wonder why this BZ was assigned to EPEL7? I had reported this BZ against
> F25 and still am facing it on F25.
Because perhaps this is due to server side as already pointed out by:
(In reply to pstodulk from comment #4)
> So I look at it closer and the most probably it is problem of "inconsistent"
> packages on the server. Same problem occurs on various system, doesn't
> matter what version of git is used.
although I don't know what version of packages Fedora git server(?) is using.
Anyway I guess some Fedora infra team's attention is needed here.
The issue is with python-pygit2 and libgit2, versions have been provided in the original comment. Basically, we run what is available in epel :)
I'm looking into fixing this and as a first step built a new libgit2 (while strictly keeping compatibility with the old ABI version and old soname). I suspect warning would be easiest to fix with a python-pygit2 update that should be now possible that libgit2 is updated.
How would that plan work for Fedora infra? If I put a python-pygit2 update in EPEL 7 testing, would you guys be able to test the update?
> How would that plan work for Fedora infra? If I put a python-pygit2 update in EPEL 7 testing, would you guys be able to test the update?
> I'm looking into fixing this and as a first step built a new libgit2
But libgit2 is in RHEL proper and thus we need it fixed there, we can't have it in epel.
Great, thanks for the feedback! No, libgit2 is in EPEL and not in RHEL, which makes things much easier here.
Moving forward with this, I now have a python-pygit2-0.24.2-1.el7 build which should fix the warning. pingou, would it be possible for you or someone else from the infrastructure team to test this on the server side, please? I'll leave it in testing as long as needed and disable autokarma so you guys can try this out.
python-pygit2-0.24.2-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d00d781835
python-pygit2-0.24.2-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d00d781835
So, this depends on the libgit2-0.24.6-1.el7 update also right?
Can we do that update right first? (ie, follow https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy and just announce loudly that it will be an incompatible upgrade and just do it)
Yes, that is correct. It depends on the libgit2-0.24.6-1.el7 update which is already in stable.
I've just sent out an announce mail to epel-announce. Hopefully someone lets it through the moderation queue soon.
Pierre-YvesChibon, Kevin Fenzi, have any of you had time to give the update a try? Would be great to get some testing in the Fedora infrastructure context before pushing this to stable.
I can test, but it's unclear to me if we need to rebuild pagure against the new packages or not (well, I know we don't _need_ to, but we should since the old so's aren't going to stay around forever).
Thanks Kevin, that would be great. No, I don't think it needs a rebuild as pagure uses the python bindings and doesn't link with the C library directly, as far as I know at least.
ok. I updated both on stg.pagure.io and did some testing. Everything seems to work and the warning messages are gone.
Great, thanks again Kevin! Submitted it to stable now.
python-pygit2-0.24.2-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.