Portage 2.1.9.24 (default/linux/amd64/10.0, gcc-4.5.1-asneeded, glibc-2.12.1-r2, 2.6.36+ x86_64) ================================================================= System uname: Linux-2.6.36+-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Sun, 31 Oct 2010 21:00:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.7, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.5.1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.82 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/openvpn/easy-rsa /var/lib/hsqldb /var/qmail/alias /var/qmail/control /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unknown-features-warn unmerge-orphans userfetch userpriv usersandbox" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.wheel.sk/" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/tree" SYNC="rsync://yamato.home.flameeyes.eu/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java5 java6 mmx modules mudflap multilib mysql ncurses nls nostatic nptl nptlonly openmp pam pcre perl postgres pppd python qt3support readline ruby session sse sse2 ssl sysfs tcpd unicode vhosts xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest cgi" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18 jruby ruby19 ree18" USERLAND="GNU" VIDEO_CARDS="intel radeon nouveau vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos ac:2
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.
