Hello, I'd like to ask for a build of mod_perl in EPEL9 as our application is depending on it and we'd like to move to Centos 9 rather sooner than later. There were some issues with EPEL8 already, but fixed in the end, so i hope it'll work in epel9 as well. Thank you!
I don't feel confident in supporting mod_perl in EPEL9. If you need that package there, I can give you permissions and you can maintain it there yourself. What's your FAS username?
As I wrote, I'm not going to maintain mod_perl in EPEL 9. If there is anybody will to do that, I can give him the permission, or better transfer ownership of the whole package, including Fedora. The new maintainer should know that self test do not pass with a threaded implementation of httpd worker model which is the default one in Fedora and EPEL 9 (and 8?).
*** Bug 2049744 has been marked as a duplicate of this bug. ***
I'll take the entire project. My FAS account is kni. It looks like the failed test occurs only on EPEL 9 x86_64 architecture: https://copr.fedorainfracloud.org/coprs/kni/mod_perl-for-epel/build/3291634/ EPEL 8 is fine. 2.0.11 builds fine in EPEL 9. As a stop gap, I may build 2.0.11 then deal with the 2.0.12 build failure later. https://copr.fedorainfracloud.org/coprs/kni/mod_perl-for-epel/build/3291663/ Do you have any comment on the status of the 6 open bugs, dating back to 2017? Have any been fixed? Are those worth looking into?
(In reply to Andrew Bauer from comment #4) > I'll take the entire project. My FAS account is kni. > Great to hear there is somebody willing to maintain mod_perl. Do you want only EPEL, or also Fedora? > It looks like the failed test occurs only on EPEL 9 x86_64 architecture: > https://copr.fedorainfracloud.org/coprs/kni/mod_perl-for-epel/build/3291634/ > The failures are not specific to architecture. They are simply random. I believe that are triggered a race between spawing threaded by httpd and forks (?) in tests of mod_perl. I have no clue whether it's a bug in tests, in mod_perl code, or an inherent issue in forking from a multithreaded process (pthread_atfork(3)). > EPEL 8 is fine. > It isn't. It suffers from the same problem. Fedora too. > 2.0.11 builds fine in EPEL 9. As a stop gap, I may build 2.0.11 then deal > with the 2.0.12 build failure later. > https://copr.fedorainfracloud.org/coprs/kni/mod_perl-for-epel/build/3291663/ > There is (almost) no difference in code between 2.0.11 and 2.0.12. 2.0.12 only incorporated patches which Fedora's 2.0.11 had already used before. > Do you have any comment on the status of the 6 open bugs, dating back to > 2017? Have any been fixed? Are those worth looking into? Those are yet another random crashes without any reproducer. Very difficult to locate and fix.
Now I can see you wrote "the entire project". I gave you this package in Fedora and in EPEL. I whish you good luck with this package.
Yes, yes I did. I may regret it. I spent the day yesterday reading mod_perl bug reports, which grew to searching bug reports from other popular distros. Poaching patches and other relevant info from other distros has worked for me in the past. Essentially same_interp_req_body() returns nothing sometimes, which lead me right to your bug on CPAN...from 2 years ago. Ugh. If I can get the package to build just once, I may just run with it until new information arrives, in the form of a response from the author or additional bug reports from others. Not building it will just block other packages important to me and others. I want to avoid that.
My approach for building mod_perl was keep the tests in %check phase of a spec file enabled, and simply resubmit failed builds in Koji until they pass. 0--4 resubmits usually are enough. The spec file also removes few tests which especially often fail. Based on this experience I started deprecation of mod_perl in Fedora and rejecting addition to new EPELs. I think that the future is fixing httpd to set PATH_INFO variable correctly (bug #1651746). Then PSGI applications would work with Apache httpd + mod_fcgid (or mod_psgi) out of the box. The other ones can resort to good old CGI.
FEDORA-EPEL-2022-7128d5a274 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7128d5a274
FEDORA-EPEL-2022-7128d5a274 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7128d5a274 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-7128d5a274 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.