| Summary: | www-apache/mod_python tests freeze for over eight hours | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mmokrejs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Build log | ||
|
Description
Diego Elio Pettenò (RETIRED)
2010-11-01 10:19:48 UTC
Created attachment 252773 [details]
Build log
I think we should just last rite mod_python. The only dep in the tree is viewvc, which can also work with other types of server setups. Upstream is dead and I'm not sure it even works well with recent Python. (In reply to comment #2) > I think we should just last rite mod_python. The only dep in the tree is > viewvc, which can also work with other types of server setups. Upstream is > dead and I'm not sure it even works well with recent Python. Cool, any volunteers? (In reply to comment #4) > Cool, any volunteers? If you refer to treecleaning, I periodically review bugs with treecleaners involved to remove packages if needed The idea sounds maybe good to you but I personally very much dislike forcing people to the extra work of studying what new alternives are available, what configuration steps will be needed, what needs to be rewritten in their application, test the new code+setup elsewhere, deploy, fix bugs. The question should not be how many packages in Gentoo portage tree depend on it but how many third-party, user-installed tools require it. Just a quick glance at http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be-officially.html and http://code.google.com/p/modwsgi/ and finally http://blog.dscpl.com.au/ tells me I will need several days to study all of this and re-write yet unknown amount of code in my applications which are just running fine several years. I don't care about no support for python-3 in mod_python as I am not going to rewrite my applications in that either. I just don't get the idea dropping a package working fine many people just because there are some bug reports open. As I see this is currently the only bug opened for mod_python in gentoo. (Actually, same like removal of php-5.2 causing that apps needed to be rewritten). If you want to continue using mod_python, you're of course welcome to do so. It's only being removed from the tree because none of the Gentoo developers are willing to spend time on doing the necessary maintenance to keep this package properly working. You can always start an overlay and maintain it there. But after each python version bump you need to run python-updater and for that, you need the ebuild in the tree. Sure, one can copy it into /usr/local/portage but in the first place, there IS NO NEED TO DROP IT. Would there be 20 criticval bug in Gentoo's bugzilla then maybe, but until that I still think you can just keep it in the tree. I believe it works for hundreds/thousands of people and there is just no reason to drop it due to some unresolved bugs. There were always some bugs open so what? In other words, this is only causing a hassle to end users. (In reply to comment #8) > In other words, this is only causing a hassle to end users. You mean it's making this a lot simpler for new users that shouldn't be bothered by dead packages in tree so it's clear how they should setup their server, write their code, etc +1 for dropping the package (In reply to comment #8) > But after each python version bump you need to run python-updater and for > that, you need the ebuild in the tree. Sure, one can copy it into > /usr/local/portage but in the first place, there IS NO NEED TO DROP IT. > Would there be 20 criticval bug in Gentoo's bugzilla then maybe, but until > that I still think you can just keep it in the tree. I believe it works for > hundreds/thousands of people and there is just no reason to drop it due to > some unresolved bugs. There were always some bugs open so what? Pretty sure you're wrong about the hundreds/thousands of people still using it. Also, I'm pretty sure python-updater works on ebuilds in overlays. And regarding this particular build.log. The tests all fail because apache is misconfigured in the sandbox, possibly just because /etc/resolv.conf is not accessible from sandbox. Isn't this just an ebuild issue? Several of the tested features work fine for me since years. I think this is just a broken testing setup. And to drop a package because an ebuild does not support USE=test ... That's really not justifiable. The ebuild can contain an einfo() line pointing potential *new developers* to mod_wsgi or other alternatives. The message is not targeted to users will to use the application itself. More importantly, Graham Dumpleton's website even enumerates what "old" mod_python features are NOT available in mod_wsgi. For me, the PSP handler (the mod_python's default) has no replacement. I can only rewrite my apps. :( Gentoo is not a developer training center with rights to decently force developers to move towards a different infrastructure/language/IDE, etc. It should be here to serve users with the infrastructure to install whatever applications (both in portage tree and even third-party). Requiring a rewrite of applications to run them on Gentoo after some DD.MM.YYYY is not justifiable. People either stop doing 'emerge --sync', or copy some ebuild to their own local portage, or leave Gentoo. Sorry if I was unclear. I also do agree python-updater uses ebuilds in local portage, sure. The point was that one needs to copy the ebuild away before it disappears from official portage. To find it later on in some cvs/svn repositiory is not a usual task for most people. Or at least for me, who contributed some ebuilds in the past already. (In reply to comment #3) > (In reply to comment #2) > > I think we should just last rite mod_python. The only dep in the tree is > > viewvc, which can also work with other types of server setups. Upstream is > > dead and I'm not sure it even works well with recent Python. Bad idea as mod_python is used by a number of people in their day-to-day job in out of the thee manner, removing based on a build test fail (because of wrong setup either test or sandbox) will hit that users. Why not just RESTRICT test and prepare it for sandbox when it will possible, and treeclean this package only if real issues will be. I use mod_python and rewriting the code would be problematic as modwsgi does not provide the facilities that I need (the code I have is an authorization hook) I've restricted the tests and unmasked the package. |