An error generated during 'emerge --update --deep world': LOG FILE minus some compilation garbage ------------------------------------------ >>> Unpacking source... >>> Unpacking mod_perl-2.0.1.tar.gz to /var/tmp/portage/mod_perl-2.0.1-r2/work [32;01m*[0m Applying mod_perl-2.0.1-sneak-tmpdir.patch ... [A[188C [34;01m[ [32;01mok[34;01m ][0m >>> Source unpacked. Reading Makefile.PL args from @ARGV MP_TRACE = 1 MP_DEBUG = 1 MP_USE_DSO = 1 MP_APXS = /usr/sbin/apxs2 no conflicting prior mod_perl version found - good. Configuring Apache/2.0.54 mod_perl2/2.0.1 Perl/v5.8.7 Checking if your kit is complete... Looks good 'TMPDIR' is not a known MakeMaker parameter name. [ info] generating script t/TEST [ info] generating script ./t/cgi-bin/cookies.pl Writing Makefile for Apache::Test Checking for File::Spec...ok INSERT UNEEDED COMPILATION TEXT HERE -I/var/tmp/portage/mod_perl-2.0.1-r2/work/mod_perl-2.0.1/Apache-Test/lib -MModPerl::BuildMM -e ModPerl::BuildMM::glue_pod lib/Apache2/Status.pm /var/tmp/portage/mod_perl-2.0.1-r2/work/mod_perl-2.0.1/docs/api/Apache2/Status.pod blib/lib/Apache2/Status.pm Manifying blib/man3/Apache2::Status.3pm /usr/bin/perl5.8.7 -Iblib/lib -I/var/tmp/portage/mod_perl-2.0.1-r2/work/mod_perl-2.0.1/Apache-Test/lib -MModPerl::BuildMM -e ModPerl::BuildMM::glue_pod ModPerl-Registry/lib/ModPerl/Registry.pm /var/tmp/portage/mod_perl-2.0.1-r2/work/mod_perl-2.0.1/docs/api/ModPerl/Registry.pod blib/lib/ModPerl/Registry.pm Manifying blib/man3/ModPerl::Registry.3pm /usr/bin/perl5.8.7 -MExtUtils::Install -e \ "-e qq{.mypacklist} && uninstall(qq{.mypacklist}, 1, 0)" [31;01mACCESS DENIED[0m chmod: /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm [31;01mACCESS DENIED[0m unlink: /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm Cannot forceunlink /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm: Permission denied at -e line 1 unlink /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm make: *** [nuke_Apache__test] Error 13 !!! ERROR: www-apache/mod_perl-2.0.1-r2 failed. !!! Function src_install, Line 127, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. [31;01m--------------------------- ACCESS VIOLATION SUMMARY ---------------------------[0m [31;01mLOG FILE = "/var/log/sandbox/sandbox-www-apache_-_mod_perl-2.0.1-r2-28853.log"[0m chmod: /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm unlink: /usr/lib/perl5/vendor_perl/5.8.6/i686-linux/Apache/test.pm [31;01m--------------------------------------------------------------------------------[0m LOG FILE -------------------------------------------------------- I unmerged and emerged mod_perl to workaround the problem. Reproducible: Always Steps to Reproduce: 1. 'emerge --update --deep world' to mod_perl 2.0.1 Actual Results: emerge failed Expected Results: emerged successfully Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11-hardened-r15 i686) ================================================================= System uname: 2.6.11-hardened-r15 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.12.0_pre8 dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.chem.wisc.edu/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X alsa apache2 apm arts avi berkdb bitmap-fonts browserplugin cdr crypt cups doc dvdr eds emboss encode esd fam foomaticdb fortran gd gdbm gif gnome gpm gstreamer gtk gtk2 hal howl imlib ipv6 java jpeg junit kde libg++ libwww mad mikmod motif mozilla mp3 mpeg mysql mysqli ncurses nls ntpl ntplonly ogg oggvorbis opengl oss pam pdflib perl php png python qt quicktime readline ruby sdl spell ssl tcpd tidy tiff truetype truetype-fonts type1-fonts vorbis x86 xml xml2 xmlrpc xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Please, unmerge the old version first and then try again. Works fine here.
Do you sudo to do your emerges? I was getting this when testing the packages if I "sudo emerge..." (had to do with mixed up environments between root, sudo, and self). Actually becoming root for the emerge process worked (hence why this went into portage :)
Because mod_perl is ~x86 for apache2 I had emerged mod_perl for apache and I got the same error. As stated above once I unmerged mod_perl and added perl-core/CGI ~x86 and www-apache/mod_perl ~x86 the error went away.
(In reply to comment #3) > Because mod_perl is ~x86 for apache2 I had emerged mod_perl for apache and I got > the same error. As stated above once I unmerged mod_perl and added perl-core/CGI > ~x86 and www-apache/mod_perl ~x86 the error went away. Closing then, thanks for reporting back.
I'm having the same problem, and, when searching, came across bug #95061, which appears to be the same issue: mod_perl 2 fails with sandbox violations trying to unlink "/usr/lib/perl5/vendor_perl/5.8.6/ i686-linux-thread-multi/Apache/test.pm" whenever an older version of mod_perl is installed. Can the problem actually be fixed? If the two versions cannot co-exist, shouldn't the metadata of version 2 be changed to, at minimum, not have different a different slot from version 1?
*** Bug 114606 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Can the problem actually be fixed? If the two versions cannot co-exist, shouldn't the metadata of version 2 > be changed to, at minimum, not have different a different slot from version 1? Uhm no - that would do the exact oposite of what you are requesting, causing 1.99.x be installed along with 2.0.x; 1.2x versions are SLOT="0" and work with apache-1; 1.99.x/2.0.x are SLOT="1" and work with apache-2. You cannot have multiple versions of mod_perl installed for the same apache version. Upgrading only occurs on the same slot.
(In reply to comment #7) > (In reply to comment #5) > > Can the problem actually be fixed? If the two versions cannot co-exist, > shouldn't the metadata of version 2 > > be changed to, at minimum, not have different a different slot from version 1? > > Uhm no - that would do the exact oposite of what you are requesting, causing > 1.99.x be installed along with 2.0.x; 1.2x versions are SLOT="0" and work with > apache-1; 1.99.x/2.0.x are SLOT="1" and work with apache-2. You cannot have > multiple versions of mod_perl installed for the same apache version. Upgrading > only occurs on the same slot. Actually, I was suggesting having all mod_perl's have the same SLOT, but looking at this bug now, I don't know why I thought of SLOTing at all. What I should have been thinking about was something which would control which versions of the ebuild were present at build-time... like giving mod_perl-2 a $DEPEND which blocks older mod_perls. (I think.) -Jonathan
*** Bug 116044 has been marked as a duplicate of this bug. ***
Um, not to be impolite, but I don't think this bug is "FIXED". There is no actual fix to the problem (mod_perl 2 refusing to emerge ...), nothing to work around it by getting older mod_perl's uninstalled first, and not even any einfo messages in the ebuild to warn people. People are still opening bugs on this. It's fine to mark them dups, but this bug needs to be reopened, because the problem clearly still exists.
*** Bug 124279 has been marked as a duplicate of this bug. ***
Reopen, if there's no better solution we should probably block older mod_perl versions on upgrade to force unmerge.
*** Bug 127391 has been marked as a duplicate of this bug. ***
*** Bug 128196 has been marked as a duplicate of this bug. ***
Can someone (anyone) please provide which version of mod_perl they had before and which version they are upgrading to (specifically, down to the -r :). Obviously it's the UNINST phase of the make install that is causing this problem, but since I haven't seen this during random upgrades (1.X ->2.0.1, 2.0.1 -> 2.0.2) I'd like to isolate why it happens for some folks and not everyone. Thanks!
(In reply to comment #15) > Can someone (anyone) please provide which version of mod_perl they had before > and which version they are upgrading to (specifically, down to the -r :). > Obviously it's the UNINST phase of the make install that is causing this > problem, but since I haven't seen this during random upgrades (1.X ->2.0.1, > 2.0.1 -> 2.0.2) I'd like to isolate why it happens for some folks and not > everyone. > > Thanks! > Portage doesn't report any installed versions, so I'm asuming it's a fresh install. I have the problem with all the versions (2.0.1-r1, 2.0.1-r2 and 2.0.2)
(In reply to comment #16) > (In reply to comment #15) > > Can someone (anyone) please provide which version of mod_perl they had before > > and which version they are upgrading to (specifically, down to the -r :). > > Obviously it's the UNINST phase of the make install that is causing this > > problem, but since I haven't seen this during random upgrades (1.X ->2.0.1, > > 2.0.1 -> 2.0.2) I'd like to isolate why it happens for some folks and not > > everyone. > > > > Thanks! > > > > Portage doesn't report any installed versions, so I'm asuming it's a fresh > install. I have the problem with all the versions (2.0.1-r1, 2.0.1-r2 and > 2.0.2) > Ok, it turned out that I'm running 1.27-r4 at the moment. Is it supposed not to show up when you're upgrading tot version 2+ ???
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > Can someone (anyone) please provide which version of mod_perl they had before > > > and which version they are upgrading to (specifically, down to the -r :). > > > Obviously it's the UNINST phase of the make install that is causing this > > > problem, but since I haven't seen this during random upgrades (1.X ->2.0.1, > > > 2.0.1 -> 2.0.2) I'd like to isolate why it happens for some folks and not > > > everyone. > > > > > > Thanks! > > > > > > > Portage doesn't report any installed versions, so I'm asuming it's a fresh > > install. I have the problem with all the versions (2.0.1-r1, 2.0.1-r2 and > > 2.0.2) > > > > Ok, it turned out that I'm running 1.27-r4 at the moment. > Is it supposed not to show up when you're upgrading tot version 2+ ??? > I unmerged version 1.27-r4 manually and now version 2.0.1-r2 is installing without errors. It looks like some removal issue...
*** Bug 133280 has been marked as a duplicate of this bug. ***
This is not the case for me... I've unmerged apache-1 and mod_perl and still get this error
To get around this bug on another system (I had a bunch of other issues with the first system I tried this on) I had to upgrade perl to perl-5.8.8-r1
No duplicates for 6 months, assuming fixed.
Removed version 1.27-r4. Current perl is 5.8.8. And the emerge now succeeds. I still think this unmerging of the previous version should be part of the ebuild, forcing the user to either unmerge the previous version (choosing apache2, I assume) or to leave the 1.x version alone. Hence, I reopen the bug.
(In reply to comment #23) > Removed version 1.27-r4. Current perl is 5.8.8. And the emerge now succeeds. I > still think this unmerging of the previous version should be part of the > ebuild, forcing the user to either unmerge the previous version (choosing > apache2, I assume) or to leave the 1.x version alone. > > Hence, I reopen the bug. > Of course, I cannot do this, since I'm not the submitter of this particular version of the bug :)
As per the request, re-opened until instructed otherwise.
(In reply to comment #23) > Removed version 1.27-r4. Current perl is 5.8.8. And the emerge now succeeds. I > still think this unmerging of the previous version should be part of the > ebuild, forcing the user to either unmerge the previous version (choosing > apache2, I assume) or to leave the 1.x version alone. emerge of what exactly? mod_perl-1* and mod_perl-2* are two different slots, please reread Comment #15.
> emerge of what exactly? mod_perl-1* and mod_perl-2* are two different slots, > please reread Comment #15. > Correct me if I'm wrong, but I think the dependency is governed by the version of apache? Doesn't apache2 imply mod_perl-2*? To answer your question, though, I emerged mod_perl-1* a long, long time ago (over three or four years ago, I guess). Then, the dependency on mod_perl-2* popped up. When and more specifically how this was caused has by now been covered by the mists of time :) But my strong guess is that going from apache to apache2 caused this to happen. When did apache2 become the preferred solution?
