On ma, 14 kesä 2021, Miro Hrončok wrote:
On 14. 06. 21 13:40, Alexander Bokovoy wrote:
On ma, 14 kesä 2021, Victor Stinner wrote:
Congrats, that's amazing! :-) Let's fix remaining broken packages!
Right now the biggest broken package to us (FreeIPA) is mod_wsgi which
relied on Python C API which was removed in Python 3.10. The same API
was used by uWSGI as well, so it would really be great if Python core
developers and Python maintainers team could have helped mod_wsgi/uWSGI
upstreams to migrate from the old API.
Sadly, this was only found after the fact when a side-tag was already
merged, so FreeIPA right now is broken in Fedora Rawhide.
The problem in mod_wsgi was actually found and reported in November
2020 [1], which is exactly why we test with each pre-release of
Python: To report problems *early* and give maintainers time to fix
them, so we can land the new version with limited negative impact.
Unfortunately, the mod_wsgi maintainer did not respond to the problem
:( While we try really hard, we cannot report each failure to
upstreams directly.
The fact that this blocks FreeIPA was indeed only discovered by chance
while the side tag rebuild was already in progress (and about to be
merged). I wonder haw can we improve the process to ensure problems
like this are known to FreeIPA maintainers since the beginning and
prioritized accordingly. (Ideally, the process would not only be
improved for FreeIPA but the entire distro.)
Well, this is a dependency problem in the first place. When an ABI
change happens, like a Python ABI change with 3.10 mass-rebuild, it
should be assumed and expected that until all previously successfully
built packages were to be rebuilt, there will be broken dependencies.
Perhaps, we could extend our existing checks for a broken compose to be
done on a side-tag on demand? This way mass-rebuilders could ask for
such a run one they consider to be ready to merge and see how that
side-tag merge would affect the distribution. I don't think we have a
better way to detect it before the merge.
What I do not see as acceptable is what Python core team did in November
2020 when this issue was made clear in the original PR to remove the
'old' parser that broke mod_wsgi/uWSGI/unbound and some more packages.
Instead of following up in providing a supported API function, the
comment[1] from Victor was practically ignored.
I assume that opening bugzillas for all the dependent packages for
each failure would be considered as spam by many.
It depends on what that bug opening would mean. If you are doing it
early together with an upstream that breaks its ABI/API, helping them to
see the issues early is one of your goals -- as you stated above.
Realizing through reverse dependencies a damage such breakage could
cause is something you (as Python maintainers in Fedora) could
definitely do and raise the issue earlier also with the package
maintainers/upstreams. In this case FreeIPA is affected but we missed it
completely in November 2020 as nobody told us mod_wsgi would not work
anymore.
In the meantime, I've marked mod_wsgi as "blocker" for the Python 3.11
rebuild next year, but that is not a systematic solution.
I saw that there is some discussion and an effort to help mod_wsgi
upstream already, thank you!
There is a proposed fix [2] but we don't know enough about Apache to
say if it is ideal. In case this blocks you very much, I suggest you
work with the Fedora's mod_wsgi maintainer and backport this patch to
rawhide, keeping an eye on it in case it breaks your use cases, and
report problems to us, so we can adapt it. At this point of the Fedora
35 development schedule, I think this patch should be good enough for
it.
I already nominated mod_wsgi bug as Fedora 35 beta release blocker
because it violates Fedora Server release criteria[2]. I am not a
maintainer for mod_wsgi myself and have no rights to that package.
[1] https://bugs.python.org/issue40939#msg381227
[2] https://fedoraproject.org/wiki/Basic_Release_Criteria#FreeIPA_server_requirements
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
