Re: [gentoo-dev] Subversion and Apache 2.0.54
On Friday 13 May 2005 19:04, Ian Brandt wrote: Paul de Vrieze wrote: Quite likely you changed db versions along the run. While this theoretically should work. The best course of action is to dump the repository. Make sure you have a consistent use of db, and load the repository. Alternatively you could try to use fs_fs Eventually I was able to get a dump by compiling 1.1.4 myself using all the dependencies included in the source with the exception of db-4.1.25_p1-r4. In principle the 1.0 apr's and later should work for subversion. The main versions are still the 0.9.x versions though. These are the ones I use. These database errors are normally not related to the apache version. (apr/apr-util can be related though). I was able to get the 1.1.4 ebuild to work but only with apache-2.0.52-r3, apr-0.9.5-r3, and apr-util-0.9.5. All my attempts to merge 1.1.4 or 1.1.3 and apache-2.0.53/54 (which use apr 0.9.6) resulted in the same failing svn binaries. With the working apache-2.0.52 and subversion-1.1.4 combination I dropped the repository, recreated as fsfs, and successfully loaded the dump I made with my own compile of 1.1.4. It's been running fine since. You could change the useflag to not include berkeley db. On my system things work with apr(-util)-0.96, apache-2.0.54-r5 and subversion-1.1.4. What I should note though is that my apache does not have ldap support compiled in. It could very well be that ldap is causing your troubles. Which db version is your ldap compiled against? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp94MgGQMFyL.pgp Description: PGP signature
Re: [gentoo-dev] Subversion and Apache 2.0.54
On Sunday 08 May 2005 19:09, Ian Brandt wrote: I realized I had added: =dev-libs/apr-0.9.6 =dev-libs/apr-util-0.9.6 to /etc/portage/package.keywords, and that is why apr-1.1.1 and apr-1.1.2 were installed, and not because they were required by apache-2.0.54. I changed = to ~ on those entries, unmerged them, re-emerged apache-2.0.54 and subversion-1.1.4, but still no luck. I tried downgrading to subversion-1.1.3, but get the same results. In principle the 1.0 apr's and later should work for subversion. The main versions are still the 0.9.x versions though. These are the ones I use. These database errors are normally not related to the apache version. (apr/apr-util can be related though). Also for very safe subversion, try to first unmerge it and only after that compile. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprs78b1Qeg5.pgp Description: PGP signature
Re: [gentoo-dev] Subversion and Apache 2.0.54
The latest: I downloaded the subversion-1.1.4 source from tigris.org and did a standard ./configure ; make ; make install. (It picked up my installed db-4.1.25_p1-r4.) As long as I only use the binaries I compiled svnadmin verify and svnlook work fine. If I use the Gentoo subversion-1.1.4 binaries to verify I start getting errors with either install. I had tar'ed up repos after doing a 'db4.1_recover -v -h /var/svn/repos/'. If I revert to that I can use the binaries I installed again without error. ~Ian Danny van Dyk wrote: Ian Brandt schrieb: Hi Konstantin, Thanks for the tips. I'm actually on that road already. It appears my /var/svn/repos/db has been corrupted: # svnadmin verify /var/svn/repos/ *** glibc detected *** double free or corruption (out): 0x08064768 *** Aborted # svnadmin recover /var/svn/repos/ Repository lock acquired. Please wait; recovering the repository may take some time... *** glibc detected *** double free or corruption (out): 0x080667c8 *** Aborted Hmm, that looks like work for the audit team. Tigger: Your mission, if you choose to accept, is... ;-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Subversion and Apache 2.0.54
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Brandt wrote: # svnadmin verify /var/svn/repos/ *** glibc detected *** double free or corruption (out): 0x08064768 *** Aborted Are you sure you have the latest versions of everything? When the big apache unmask happened, my subversion broke for a short while with the same aborts until the new revision was released. This probably isn't the case, but is worth mentioning. - -- Superior ability breeds superior ambition. -- Spock, Space Seed, stardate 3141.9 Aaron Walker [EMAIL PROTECTED] [ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCfZaqC3poscuANHARAoaQAKDG9xjyjqjHrynQdrMGpkVQCcUqtwCfe67f DKDbja0Ujfb/nlFsDVBEnPc= =duNb -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Subversion and Apache 2.0.54
I realized I had added: =dev-libs/apr-0.9.6 =dev-libs/apr-util-0.9.6 to /etc/portage/package.keywords, and that is why apr-1.1.1 and apr-1.1.2 were installed, and not because they were required by apache-2.0.54. I changed = to ~ on those entries, unmerged them, re-emerged apache-2.0.54 and subversion-1.1.4, but still no luck. I tried downgrading to subversion-1.1.3, but get the same results. I'm now thinking that having the newer versions of apr somehow caused the problem, though I'm not exactly sure how as I thought subversion built with the apr included in it's source? The odd thing is that I run db4.1_recover and verify and it doesn't appear that there are any problems: # pwd /var/svn/repos/db # db4.1_recover -v db_recover: Finding last valid log LSN: file: 76 offset 908974 db_recover: Recovery complete at Sun May 8 12:56:44 2005 db_recover: Maximum transaction id 8000 Recovery checkpoint [76][908890] # db4.1_verify changes # db4.1_verify copies # db4.1_verify nodes # db4.1_verify representations # db4.1_verify revisions # db4.1_verify strings # db4.1_verify transactions # db4.1_verify uuids # I've even tried catastrophic recovery, but still no luck on the svn side: # db4.1_recover -cv db_recover: Finding last valid log LSN: file: 76 offset 908974 db_recover: Recovery starting from [1][28] db_recover: Recovery complete at Sun May 8 13:02:24 2005 db_recover: Maximum transaction ID 80012ee5 Recovery checkpoint [76][908974] db_recover: Recovery complete at Sun May 8 13:02:24 2005 db_recover: Maximum transaction id 8000 Recovery checkpoint [76][908974] # sudo -u apache svnadmin verify /var/svn/repos/ *** glibc detected *** double free or corruption (out): 0x08064768 *** Aborted # sudo -u apache svnadmin recover /var/svn/repos/ Repository lock acquired. Please wait; recovering the repository may take some time... *** glibc detected *** double free or corruption (out): 0x080667c8 *** Aborted ~Ian Aaron Walker wrote: Ian Brandt wrote: # svnadmin verify /var/svn/repos/ *** glibc detected *** double free or corruption (out): 0x08064768 *** Aborted Are you sure you have the latest versions of everything? When the big apache unmask happened, my subversion broke for a short while with the same aborts until the new revision was released. This probably isn't the case, but is worth mentioning. -- Superior ability breeds superior ambition. -- Spock, Space Seed, stardate 3141.9 Aaron Walker [EMAIL PROTECTED] [ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Subversion and Apache 2.0.54
I suppose this is effectively to Paul: Have you had a chance to try Subversion with Apache 2.0.54? I'm getting the following error after emerging apache-2.0.54 (along with apr-1.1.1 and apr-1.1.2), and re-emerging subversion-1.1.4: [notice] Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e DAV/2 SVN/1.1.4 configured -- resuming normal operations [error] (20014)Error string not specified yet: Berkeley DB error while opening environment for filesystem /var/svn/repos/db:\nDB_RUNRECOVERY: Fatal error, run database recovery [error] Could not fetch resource information. [500, #0] [error] Could not open the requested SVN filesystem [500, #160029] I was going to take a stab at it, but wanted to first see if you didn't already have something in the works. Thanks, Ian -- gentoo-dev@gentoo.org mailing list