Learn more about these different git repos.
Other Git URLs
There was recently some issues around libgit2 in rawhide. It was moved to a module and then had multiple versions and caused some issues.
Now, the non modular one is back and tagged correctly in f31, but for some reason it's not collected into the Everything repo.
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190718.n.0/logs/global/ is an example of such a compose.
See: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190718.n.0/compose/Everything/x86_64/os/Packages/l/libgit2-* only has libgit2-glib and libgit2_27 compat package. Failed kde live compose: https://koji.fedoraproject.org/koji/taskinfo?taskID=36320552
The libgit2 module still exists and is default, but that shouldn't override the bare rpm should it?
Note that the kde live uses libgit2, so this breaks rawhide composes until we fix it.
CC: @ignatenkobrain @sgallagh @adamwill @mohanboddu
This is my understanding as well.
The last libgit2 module or rpm was built on July 14th, the last successful compose we had was on 17th. I am not sure what caused it to behave like this. It dropped libgit2-0.28.2-2.fc31 out of tonights compose.
FYI, we are using pungi-4.1.38-1.fc30.noarch for the failed compose and the last compose that worked was using pungi-4.1.36-5.fc30.noarch. So, something in 37-1 or 38-1 caused this issue.
pungi-4.1.38-1.fc30.noarch
pungi-4.1.36-5.fc30.noarch
37-1
38-1
There was recently some issues around libgit2 in rawhide. It was moved to a module and then had multiple versions and caused some issues. ... The libgit2 module still exists and is default, but that shouldn't override the bare rpm should it?
Uh, yes. If it has the same package name as the one in the default stream, the one in the default stream wins. The end.
So we probably need to drop the default stream from Rawhide.
@sgallagh non-modular and the one from default stream are the same. This should not be the case. Something has changed in pungi.
So I think there are 2 problems:
This seems to be caused by the change that added module metadata into pkgset repos (required for DNF failsafe to not trigger in buildinstall phase). However at the same change is changed what packages DNF finds in the repo – there is some unwanted filtering.
I think marking the repo as module_hotfixes could avoid this, but I have no good way of testing that. My attempts to recreate the issue result in warning about not being able register existing type ModulemdModuleStream and then hanging forever.
module_hotfixes
The proposed change is in PR: https://pagure.io/pungi/pull-request/1243
My attempts to recreate the issue result in warning about not being able register existing type ModulemdModuleStream and then hanging forever.
This is what happens if you're trying to load both libmodulemd.so.1 and libmodulemd.so.2 into the same process. It's the same issue that we saw when using the newest createrepo_c (with libmodulemd 2.x) in pungi built against libmodulemd 1.x.
My attempts to recreate the issue result in warning about not being able register existing type ModulemdModuleStream and then hanging forever. This is what happens if you're trying to load both libmodulemd.so.1 and libmodulemd.so.2 into the same process. It's the same issue that we saw when using the newest createrepo_c (with libmodulemd 2.x) in pungi built against libmodulemd 1.x.
Yup, that's it, except in my case it was Pungi on 2.x. Thanks for the pointer.
I think this should be fixed in pungi-4.1.38-2.fc30. Please try it and let me know. https://koji.fedoraproject.org/koji/buildinfo?buildID=1315226
Commit c6d6367 fixes this issue
Login to comment on this ticket.