Hi, today I did an emerge --update world, and subversion, apache apr, neon etc etc were updated, unfortunately now apache is serving blank pages.. unmerging subversion fixes apache, apache version is 2.0.58-r2, just wondering if this is experienced by others and how to fix it, cheers, Ross
You can try with newer Apache. Add to /etc/portage/package.keywords: =net-www/apache-2.2.4-r7 =app-admin/apache-tools-2.2.4-r3
Hi, thanks that worked nicely! (In reply to comment #1) > You can try with newer Apache. Add to /etc/portage/package.keywords: > =net-www/apache-2.2.4-r7 > =app-admin/apache-tools-2.2.4-r3 >
(In reply to comment #1) > You can try with newer Apache. Add to /etc/portage/package.keywords: > =net-www/apache-2.2.4-r7 > =app-admin/apache-tools-2.2.4-r3 After updating my config I just witnessed the newer apache dying with a segfault almost instantly. So I reverted to 2.0.58 to have the basic website back running again. Would be nice if we can get Subversion back working too, because the -r4 update rendered it unusable. Oh, yes some people are crucially dependend on SVN.. =) Cheers, Vasco
solved updating subversion to 1.4.4-r1
(In reply to comment #4) > solved updating subversion to 1.4.4-r1 Confirmed. Vasco
(In reply to comment #5) > (In reply to comment #4) > > > solved updating subversion to 1.4.4-r1 > > Confirmed. > > > Vasco So now do you have Apache 2.2.4-r7 + Subversion 1.4.4-r1?
No, Apache 2.0.58-r2 (stable) + Subversion ~1.4.4-r1. Apache 2.2 segfaulted instantly upon start, so I had to revert to 2.0.58... Sorry for being unclear. Cheers, Vasco
Updating to subversion "1.4.X" (~arch) is NOT AN OPTION! ... though I can confirm that doing the update solves the problem, i. e. "apache-2.0.58-r2 + "subversion-1.4.4-r1" seems to work. Axel
If some of you have problems with Apache 2.2.4-r7, you can try to find places, where errors occur. http://www.gentoo.org/proj/en/qa/backtraces.xml
It seems that problem caused by existence of two different versions of apr library in apache process' address space. The simplest workaround is to mask subversion-1.3.2-r4 and neon-0.26.3, remove apr-1 and install older subversion-1.3.2-r3. Assuming apache-2.2 is not stable (or it is?) can we link apache-2.0 against apr-1?
I think the problem was introduced as part of the solution for bug #167522 The thing is that both "apache-2.0.X" as well as "subversion-1.3.X" require and work perfectly with "apr-0". The question is, why does subversion "1.3.2-r4" on the contrary to "1.3.2-r3" introduce a (slotted) "apr-1" dependency. Even more funny is that "subversion-1.4.4-r1" does NOT pull in "apr-1", but either "lives" with what "apache2" has installed or pulls in "apr-0". Axel
(In reply to comment #10) > can we link apache-2.0 against apr-1? No. (In reply to comment #11) > Even more funny is that "subversion-1.4.4-r1" does NOT pull in > "apr-1", but either "lives" with what "apache2" has installed > or pulls in "apr-0". There's >=dev-libs/apr-util-0.9.7 which also matches ~1.2.8. Subversion works correctly with apr{,-util}:1. (In reply to comment #7) > Apache 2.2 segfaulted instantly upon start Could you write steps to reproduce it? (Which commands you ran, etc.)
> (In reply to comment #7) > > Apache 2.2 segfaulted instantly upon start > Could you write steps to reproduce it? (Which commands you ran, etc.) I have a pretty overloaded Apache 2.0.58 configuration with mpm_worker, auth_ldap, DAV, SVN and PHP running with threads so I suspect the segfault is related more to PHP-5.2.2 threading than to Apache 2.2 itself. And since I did only a quick install of ~2.2 to get SVN back working again my configuration (esp. auth_ldap -> authz_ldap) wasn't converted properly. Cheers, Vasco
(In reply to comment #12) >> Even more funny is that "subversion-1.4.4-r1" does NOT pull in >> "apr-1", but either "lives" with what "apache2" has installed >> or pulls in "apr-0". >There's >=dev-libs/apr-util-0.9.7 which also matches ~1.2.8. >Subversion works correctly with apr{,-util}:1. Yes, but it DOES NOT PULL IN "apr-1", if "apache-2.0.X" and thereby "apr-0.9.7" is installed. So "subversion-1.4.4-r1" is much smarter in handling the different "apr-X" requirements of "apache" than "subversion-1.3.2-r4" is. Axel
What's the status of this bug? I am experiencing the same problem, with apache 2.0.58-r2 and subversion-1.3.2-r4. Reverting back to subversion-1.3.2-r3 complains about a bad neon version, so I will have to rollback a few packages. Any one able to get a working apache/subversion after the upgrades?
The easiest way to get a working config seems to be (assuming you are building for x86) # emerge -v --unmerge '>=dev-libs/apr-1' # emerge -v --unmerge '>=dev-libs/apr-util-1' # echo "dev-util/subversion-1.4.4* ~x86" >> /etc/portage/package.keywords # emerge -v --update subversion and then run # revdep-rebuild -X -- -pv to see, if anything has been broken by unmerging "apr-1" Axel
(In reply to comment #15) > What's the status of this bug? I am experiencing the same problem, with apache > 2.0.58-r2 and subversion-1.3.2-r4. Subversion generally can use either apr{,-util}:0 or apr{,-util}:1. Apache 2.0.* can use only apr{,-util}:0. Apache 2.2.* can use only apr{,-util}:1. Gentoo developers decided to force Subversion 1.3.2-r4 to use apr{,-util}:1. Subversion 1.3.2-r4 and apr{,-util}:1 are now marked as stable, but the only Apache versions which can work with apr{,-util}:1 are still marked as unstable. Quoting http://www.apache.org/dist/httpd/Announcement2.2.html "This release builds on and extends the Apache 2.0 API. Modules written for Apache version 2.0 will need to be recompiled in order to run with Apache 2.2, and require minimal or no source code changes." You can also read http://httpd.apache.org/docs/2.2/new_features_2_2.html > Any one able to get a working apache/subversion after the upgrades? See comment #2.
I just committed the fix for this to CVS in dev-util/subversion-1.3.2-r4, please emerge --sync in a couple of hours and try again emerging it, it should not work again correctly with apache-2.0, I'd appreciate test reports, thanks! Best regards, CHTEKK. PS: the Header of the fixed ebuild looks like this: # $Header: /var/cvsroot/gentoo-x86/dev-util/subversion/subversion-1.3.2-r4.ebuild,v 1.6 2007/06/22 08:21:43 chtekk Exp $
(In reply to comment #18) > I just committed the fix for this to CVS in dev-util/subversion-1.3.2-r4, Just want to ask you whether you could attach the complete diff on this bugreport, please. Thanks a lot!
(In reply to comment #19) > (In reply to comment #18) > > I just committed the fix for this to CVS in dev-util/subversion-1.3.2-r4, > > Just want to ask you whether you could attach the complete diff on this > bugreport, please. Thanks a lot! http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.3.2-r4.ebuild?r1=1.5&r2=1.6
(In reply to comment #18) > I just committed the fix for this to CVS in dev-util/subversion-1.3.2-r4, > please emerge --sync in a couple of hours and try again emerging it, it should > not work again correctly with apache-2.0, I'd appreciate test reports, thanks! You meant s/should not/should, right ? Anyway : it brings a supposed useless (for me) apr-util-1 but it seems to work fine here (stable apache 2.0, x86). [ebuild R ] net-www/apache-2.0.58-r2 USE="apache2 ssl threads -debug -doc -ldap -mpm-itk -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker (-selinux) -static-modules" 0 kB [ebuild R ] dev-util/subversion-1.3.2-r4 USE="apache2 bash-completion berkdb nls python zlib -emacs -java -nowebdav -perl -ruby" 0 kB Portage 2.1.2.7 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r8 i686) ================================================================= System uname: 2.6.20-gentoo-r8 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System release 1.12.9 Timestamp of tree: Fri, 22 Jun 2007 09:20:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openjms/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php4/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cli-php4/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache collision-protect distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles http://ftp.club-internet.fr/pub/mirrors/gentoo http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--human-readable" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="apache2 bash-completion berkdb bitmap-fonts bzip2 caps clamd cli cracklib crypt cups curl dri enscript expat fam foomaticdb fortran gd gdbm gmp iconv isdnlog javamail jbig jms jmx jpeg libg++ logrotate maildir midi mpeg mudflap ncurses nls nptl nptlonly openmp pam pcre pic png pppd python readline reflection ruby sasl session spl sqlite sqlite3 ssl tcpd threads tiff truetype truetype-fonts type1-fonts unicode vhosts x86 xml xml2 xorg zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Quite hard to find out from the diff (whitespace changes?) what has actually changed, but it seems that the significant part is to force linking against "apr-0", if "apache-2.0.*" is installed, otherwise against "apr-1" which is still pulled in. Though I think that "discover_apr_suffix" should not only check for "apache-2.0", but also for "apr-0" which -- in theory -- could have been manually removed after emergeing "apache-2.0" I'll give it a try. Apart from this I find it hard to understand why a "stable" ebuilds has been modified (original -r4 ebuild forces apr-1 to be used in subversion regardless of the apache version) to meet requirememts of an "~arch" ebuilds (apache-2.2) while ignoring requirements of another "stable" ebuild (apache-2.0). Or am I getting something wrong? Cheers, Axel
(In reply to comment #21) > You meant s/should not/should, right ? Anyway : it brings a supposed useless > (for me) apr-util-1 but it seems to work fine here (stable apache 2.0, x86). Yeah, good catch, should have been "should". ;) And glad to hear it works! (In reply to comment #22) > Quite hard to find out from the diff (whitespace changes?) what has > actually changed, but it seems that the significant part is > > to force linking against "apr-0", if "apache-2.0.*" is installed, > otherwise against "apr-1" which is still pulled in. > > Though I think that "discover_apr_suffix" should not only check > for "apache-2.0", but also for "apr-0" which -- in theory -- > could have been manually removed after emergeing "apache-2.0" Uhmm how so? That would break Apache horribly, and it's not supported in the scope of our packages system: apache depends on apr, if you remove apr, broken apache, that's it... Or am I misunderstanding something? > Apart from this I find it hard to understand why a "stable" ebuilds > has been modified (original -r4 ebuild forces apr-1 to be used in > subversion regardless of the apache version) to meet requirememts > of an "~arch" ebuilds (apache-2.2) while ignoring requirements of > another "stable" ebuild (apache-2.0). > Or am I getting something wrong? Well, we originally didn't notice that forcing subversion to use apr-1 would break mod_svn on Apache 2.0, especially since we do most of our testing on Apache 2.2 now, and no one else noticed until it finally hit stable... It passed right through our usual checks and tests, sorry for that. Best regards, CHTEKK.
(In reply to comment #18) > I'd appreciate test reports, thanks! Many thanks for your patch!!! It also works fine here (x86 32bit). Some package details incl. my USE-flags: hostname # emerge -pv subversion apache These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-util/subversion-1.3.2-r4 USE="apache2 bash-completion berkdb java nls perl python ruby zlib -emacs -nowebdav" 0 kB [ebuild R ] net-www/apache-2.0.58-r2 USE="apache2 ldap ssl threads -debug -doc -mpm-itk -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker (-selinux) -static-modules" 0 kB
In reply to comment #23: > > Though I think that "discover_apr_suffix" should not only check > > for "apache-2.0", but also for "apr-0" which -- in theory -- > > could have been manually removed after emergeing "apache-2.0" > Uhmm how so? That would break Apache horribly, and it's not supported in the > scope of our packages system: apache depends on apr, if you remove apr, broken > apache, that's it... Or am I misunderstanding something? Of course it would break "apache-2.0". What I meant is that manually removing "apr-0" would not only prevent apache from running, but would also cause the subversion ebuild to fail, when trying to compile/link against a non-existing library. Adding an additional check for "apr-0" in the "apache-2.0" case, could prevent the build process from failing unexpectedly. OK, this extra check is close to paranoia, but it won't hurt ... Cheers, Axel
And please mark the dev-util/subversion-1.3.2-r4 as ~ since it breaks the stable apache packages.
(In reply to comment #25) > Of course it would break "apache-2.0". > > What I meant is that manually removing "apr-0" would not only prevent > apache from running, but would also cause the subversion ebuild to > fail, when trying to compile/link against a non-existing library. > Adding an additional check for "apr-0" in the "apache-2.0" case, > could prevent the build process from failing unexpectedly. > > OK, this extra check is close to paranoia, but it won't hurt ... Indeed it won't... I've added the check, so we also catch that case... It will produce a non-working mod_svn then, but the rest of Subversion would work, and in that particular case, mod_svn not working is not the biggest problems the admin who removed apr will probably be facing with Apache. ;) (In reply to comment #26) > And please mark the dev-util/subversion-1.3.2-r4 as ~ since it breaks the > stable apache packages. Uhmm no... The bug was fixed, and several people confirm it works now, please make sure you have emerge --sync'ed from an up-to-date mirror (check the ebuilds header, should at least be v 1.6). In fact, I'm finally closing this bug, as it seems the fix works as expected. :) Have fun using SVN! Best regards, CHTEKK.
Looks good! For I didn't want to downgrade from "subversion-1.4.4-r1" (~arch) -- which I upgraded to, to fix the "apr problem" with "apache-2.0" -- I gave the new "subversion-1.4.4-r2" a try. As far as I can see, "1.4.4-r2" uses exactly the same mechanism to determine which "apr" version/slot it should link to as "1.3.2-r4" does, and both pull in (slotted) "apr-1". // though not using it, if "apache-2.0" is found. So I can confirm that the following configuration also works: + apache-2.0.58-r2 (x86) + subversion-1.4.4-r2 (~x86) Having both apr(-util)?-0.9.12 and apr(-util)?-1.2.8 installed is no problem since "apache-2.0" links against "apr-0" anyway and subversion does it NOW because of "discover_apr_suffix()". Thanks! Axel
*** Bug 187043 has been marked as a duplicate of this bug. ***
