I've created an ebuild for mod_python-3.2.8 for my own use, so I
thought I'd post it here. The ebuild is based on the 3.1.4-r1 ebuild,
but I've made a lot of changes, most of which I hope are
self-explanatory. Please see the notes in the patch files for
details. This build has been patched to work with apache-2.2 using
code from the upstream svn archive, so it is definitely just for
testing. (On the other hand, the necessary changes are VERY few.)
I haven't had a chance yet to test this ebuild with apache-2.0 or
bash-3.1. But I have, I hope, made it easy for others to do
so. mod_python comes with a test suite that is only going to get
nicer, so I implemented src_test to run it. This works for me with the
hard-masked apache-2.2 ebuild.
Anybody want to try this? Seeing the tests running is very gratifying
when it works. Any reports of success or failure would be
nice. If no one is interested, I'll come back to it in a little while
myself (but like I said, this works for me).
Files to be uploaded in a moment:
Created attachment 80551 [details]
Created attachment 80552 [details]
Created attachment 80553 [details, diff]
Created attachment 80554 [details, diff]
Created attachment 80555 [details, diff]
Why did you give your ebuild version 3.2.8? 3.2.8 isn't out yet.
I was looking at svn when I did this, and 3.2.8 is tagged and up on the apache mirrors. Honest, I just ran emerge -f mod_python again and grabbed it.
The ebuild can't find its tarball, because the version doesn't exist.
And the testing doesn't seem to work for me, when running `ebuild mod_python-3.2.7.ebuild test` (I renamed everything back to 3.2.7) I only get a message "It appears that mod_python has already been tested; skipping." (I was going to see if everything worked with apache-2.0.55).
Other than this and the version is still weird, seems to work just fine.
Strange. You can find the file at:
This should be placed in /usr/portage/distfiles/.
As for "It appears that mod_python has already been tested; skipping.", you have two choices. The first is:
rm -f /var/tmp/portage/mod_python-3.2.8/.tested
ebuild mod_python-3.2.8.ebuild test
The other is:
ebuild mod_python-3.2.8.ebuild clean test
I get "Test phase [not enabled]". Sorry, I guess this is stupid, but I can't find it on the forums right now: how do I enable the test phase?
FEATURES=test ebuild mod_python-3.2.8.ebuild test
Still works for me :).
Thanks! Seems to pass all tests for me (but I'm still doing this with 3.2.7).
A couple of changes to this ebuild. First off, the ebuild was using
the installed version of the python libs instead of the built
version. Bad, and fixed.
Also, I backed off a little on patching for apr-1.0 support (which is
necessary to load mod_python into apache-2.2). The install is now
vanilla 3.2.8 unless the special use flag apr-1-compat is set. If you
need the patch, you will be greeted with eerrors if you try to emerge
I still haven't tested with apache-2.0, nor with bash-3.1. To try this
out with apache-2.0, run:
FEATURES=test emerge =mod_python-3.2.8
For apache-2.2 testing:
FEATURES=test USE=apr-1-compat emerge =mod_python-3.2.8
I've made changes to the following:
I've also split apache-2.2-support.upstream.patch in two:
Created attachment 80671 [details]
Created attachment 80672 [details, diff]
Created attachment 80673 [details, diff]
Created attachment 80674 [details, diff]
I just installed the actual 3.2.8 (now that it's available from mirrors).
It works just beautifully!
Can this get committed to the tree?
(Adding apache herd, as they're also in the package metadata.)
I'd really like to see this in Portage!
(In reply to comment #19)
> I'd really like to see this in Portage!
Me too. I've installed it with Apache 2.0.55 including running the tests. Tests were clear and everything seems to be working fine.
(In reply to comment #20)
> (In reply to comment #19)
> > I'd really like to see this in Portage!
Me also! Please, please somebody.
Just wanted to add that the ebuild works fine for me with apache 2.0.55.
(I've included this one along with modified apache-2.2.0 ebuilds to http://svn.ossdl.de/all/ossdl overlay.)
Hi, I hate to be a whiner, but I'm really having issues believing that Gentoo is supposed to be a good up-to-date server distribution when things like this are happening. The latest mod_python in Portage is 3.1!
(In reply to comment #24)
> Hi, I hate to be a whiner, but I'm really having issues believing that Gentoo
> is supposed to be a good up-to-date server distribution when things like this
> are happening. The latest mod_python in Portage is 3.1!
Please note that we are all volunteers, and with the number of packages in the tree we are vastly understaffed. We will get to it when we get to it.
Where does it say on the gentoo website or in the documentation that Gentoo is supposed to be a good up-to-date server distribution?
Gentoo is about having control of your system, tweaking to work how you want it. If you need this version of this package, download the ebuild from this bug and put it in an overlay and use it.
If you don't want to do that, then please be patient until a developer has enough time and/or interest to update this package.
Note when upgrading from apache 2.0:
Apache 2.2 fails when loading your old mod_python 3.1.4, and will also fail the test when compiling mod_python, so remember to remove:
"-D PYTHON" from "APACHE2_OPTS" in "/etc/conf.d/apache2"
before compiling mod_python 3.2.8
(In reply to comment #26)
Peter: I haven't looked at this; I just want to make certain I
understand what you're saying. Is it that that mod_python-3.2.8 fails
only its tests when apache-2.2 and mod_python-3.1.4 are both installed
and apache is configured with '-D PYTHON'? And if this is the case for
some obvious reason, do you know what it is exactly?
I'm sorry for not clarifying this enough. Well, actually it's not really a bug in the ebuild, but rather a user issue.
If apache for some reason fails to start (in my case because i upgraded to apache 2.2, and the old mod_python-3.1.4 did'nt work anymore), the tests mod_python-3.2.8 does using apache will of course fail. So this of course means you have to disable all non-working modules and make sure apache starts without erros, before building mod_python-3.2.8.
I guess a lot of people might be upgrading to mod_python-3.2.8 while upgrading to apache 2.2 (because of the 2.2 compatibility), so i thought this could become an issue for some?
(In reply to comment #28)
> If apache for some reason fails to start (in my case because i upgraded to
> apache 2.2, and the old mod_python-3.1.4 did'nt work anymore), the tests
> mod_python-3.2.8 does using apache will of course fail.
As described, this is wrong. The tests run /usr/sbin/apache2
directly with generated config files and load the newly compiled
module, not the old one. I have apache-2.2.0-r2 and mod_python-3.2.8.
emerge -u =mod_python-3.1.4-r1
* Apache2 has detected a syntax error in your configuration files:
apache2: Syntax error on line 490 of /etc/apache2/httpd.conf: Syntax error on line 3 of /etc/apache2/modules.d/16_mod_python.conf: Cannot load /usr/lib/apache2/modules/mod_python.so into server: /usr/lib/apache2/modules/mod_python.so: undefined symbol: APR_STATUS_IS_SUCCESS
FEATURES=test USE=apr-1-compat emerge =mod_python-3.2.8
Works for me.
The ebuild from the overlay (http://svn.ossdl.de/all/ossdl) is working well for me (x86).
*** Bug 142900 has been marked as a duplicate of this bug. ***
Created attachment 94616 [details]
mod_python working w/o patches
I used the 3.2.8 overlay from http://svn.ossdl.de/all/ossdl as a starting point.
I now run apache 2.2.3 with mod_python 3.2.10 having bash 3.1 and i didn't need any of the patches included with 3.2.8 to build mod_python.
Maybe gentoo-testing.patch makes sense, but it wasn't applyable so i simply skipped it too. My attached ebuild is a quick hack removing the error for apr-1-compatibility and all the patches.
3.2 doesn't seem to compile for me under gcc-4.1, a quick version bump to 2.10 compiled fine, and runs great.
works nice on my ~amd64 system:
Created attachment 98105 [details]
3.2.10 ebuild with ~x86 and ~amd64 keywords