i just upgraded from pre0.28 to 0.30 and have now a major problem to upgrade my repository. because my box is not completely keywords enabled, i have the currently stable version of db installed (4.0.14-r2). the recommended upgrade process (as stated in the ebuild einfo) involves the use of svnadmin-pre0.28 which is obviously built with db-4.1: -----------%>----------- h2o root # /usr/lib/subversion/bin/svnadmin-pre0.28 dump /home/old-repos/ > old-repos.dump /usr/lib/subversion/bin/svnadmin-pre0.28: error while loading shared libraries: libdb-4.1.so: cannot open shared object file: No such file or directory -----------%>----------- so i am not able to upgrade until i do upgrade to the latest db and do a complete revdep-rebuild (which would last ages on this box). i also tried to use svnadmin from another box (db-4.0.14-r2, subversion-0.21) but that did nothing: -----------%>----------- h2o root # /home/carlos/svnadmin-old dump /home/old-repos/ > old-repos.dump /home/carlos/svnadmin-old: relocation error: /home/carlos/svnadmin-old: undefined symbol: svn_pool_create -----------%>----------- is there a way to get a static linked version of svnadmin-pre0.28? also a warning (like for the portage upgrades perhaps) before the ebuild starts its work would have been helpfull. one could kill the emerge process, dump the repos with the current (pre0.28) svnadmin, then emerge and import the repos. any recommendations on how i can solve my problem with minimum cpu cycles? unfortunatly my repos runs on a old K6, with the other components even crappier :( [i'm aware that this problem hits only stable/devel mixed systems and i hope that i'm not breaking some unwritten rules with this bugreport, but a lot of folks do 'mix', so there is a fair chance someone runs into this one...] Reproducible: Always Steps to Reproduce: 1. assuming current stable db-4.0.14 installed 2. ACCEPT_KEYWORDS="~x86" emerge subversion 3. svnadmin-pre0.28 doesnt work because its linked against db-4.1
This pre should not be build with 4.1 unless you build it with that version before, it never by itself build with 4.1 unless you built with that. Emerging db-4.1 temporarilly should fix the problem. Getting a static version is hard. The easiest way is probably just to get back to the old subversion build (with db-4.1, you don't need to do a revdep rebuild as you are only wanting to run svnadmin and then forget again) and then use svnadmin to dump your repository. Then remerge 0.30 and load the dump. Unfortunately there are no static svnadmin binaries. I might look into creating one (that's better than the current "solution"), but that will not be a db-4.1 one, only db-4.0.
the temporary emerge sounds like a good solution - but trying it, i ran into the next problem -----------%>----------- # emerge db-4.1.25 # /usr/lib/subversion/bin/svnadmin-pre0.28 dump /home/old-repos/ > old-repos.dump /usr/lib/subversion/bin/svnadmin-pre0.28: relocation error: /usr/lib/subversion/bin/svnadmin-pre0.28: undefined symbol: svn_pool_create -----------%>----------- damn - so i emerge subversion again - because it might have to be linked against db-4.1 now. the build fails and after some toying around i find out that the problem is libapr (from apache) which was linked against db-4.0. so its apache again. well - reminds me a bit of rpm dependcy hunting - i'm sooo glad that this happens so rarely with gentoo :) ... i'll keep u updated...
I have changed the 0.30.0 ebuild to download a static svnadmin that is precompiled from 0.27.0. This static version however IS build with db-4.0. I'll be looking into creating a db-4.1 version that I will attach to this bug.
Created attachment 18662 [details] A static db4.1 svnadmin Please check whether this svnadmin binary works. It is statically compiled with db4.1. It should allow you to dump your database
i emerge db-4.1, recompiled apache with it (because of libapr) and then i synced and emerged subversion-0.30 twice with several hours break in between - to make sure that i use the latest version. svnadmin-pre0.28 now gives me the same error as in the previous posting: -----------%>----------- h2o root # /usr/lib/subversion/bin/svnadmin-pre0.28 dump /home/old-repos/ > repos-old.dump /usr/lib/subversion/bin/svnadmin-pre0.28: relocation error: /usr/lib/subversion/bin/svnadmin-pre0.28: undefined symbol: svn_pool_create -----------%>----------- unfortunately the static linked version doesnt work either: -----------%>----------- h2o root # ./svnadmin-0.27-db4.1 help Illegal instruction -----------%>----------- to be sure i tried the static svnadmin on my desktop box, and there it works without problems - so it seems that my server is borked somehow. to bring this to an end i propose the following: i'll just make a new repository and populate it from my working copy - it's a pity to lose all the revisions but fortunately i do not depend on them. so the problem for me is *solved* - i'm already starting to feel guilty using u as my personal debugger :-? if someone else runs into this, the static linked version should help them and if not they can comment on the problem here. if u absolutely want to 'really' solve this, then i'm of course willing to provide u with all the help and information i can give u - in this case just tell me what u need or else just forget it until someone else complains...
My pc is a pentium 3, the static libs it pulls in are probably also build for p3. I'll try to make a static version without -march compiled libs soon, but it will take some time as I'll need to set up a chroot environment for it.
if u tell me what to do i could compile it on my box - if this makes things easier for you...
Probably the easiest way for you to go is to downgrade neon, make sure that db-4.1 is installed and then do: USE="-berkdb -python" emerge subversion That will give you an svnadmin that works with the libraries to go with it. Then use this svnadmin to dump your repository to a file. Then you can upgrade neon, and subversion again. And follow the instructions to create a new repos and load the dumpfile into it.
success! i was finally able to dump the repository - here is what i did: + emerged db-4.1 + reemerged apache (because of apxs) + emerged subversion-0.27 with USE="-berkdb -python" unfortunately "-berkdb" just build the client version without svnadmin, so i reemerged subversion-0.27 with USE="-python" and was now able to dump it. i'm currently recompiling everything to stable packages and subversion to 0.30 and will let u know once everything is restored, i guess we can close this then.
ok - that did it, after reemerging db, apache and subversion i was able to load the old repos from the dumpfile. a small note: when restoring the repos with svnadmin, the repos is owned by the user that executed svnadmin. if this is something else than apache, it results in (ssl) errors (displaying as "500 internal server error"). i had to chmod to apache to restore proper permissions - i guess 'su apache "svnadmin...' should work just as well. i'm closing this, reopen if you think it needs more testing or something
