Re: libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free
Stefan Sperling wrote: On Wed, Jul 21, 2010 at 09:19:26AM +0300, Angel Tsankov wrote: Stanimir Stamenkov wrote: 20.7.2010 г. 14:32 +0300, /Angel Tsankov/: When I run kdesvn I get a dialog showing the following message: Could not find our part: Cannot load library /usr/lib/kde4/kdesvnpart.so: (/usr/lib/libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free) Files /usr/lib/kde4/kdesvnpart.so and /usr/lib/libsvn_ra_neon-1.so.0 both exist. The former is part of kdesvn and the latter is part of subversion. In case this is relevant, I have installed the following packages: * openssl 0.9.8j (configured with --prefix=/usr --openssldir=/usr/share); * neon 0.28.4 (configured with --prefix=/usr --with-ssl); * subversion 1.6.12 (configured with --prefix=/usr). Do I need to upgrade openssl or neon? Or is the problem elsewhere? This is user mailing list for the general Subversion distribution/client. I guess your question is more appropriate for the kdesvn mailing list. Since the problem is with libsvn_ra_neon-1.so.0 (which is part of Subversion), I think my question is appropriate for this mailing list, as well. The problem is most probably not with Subversion. We get reports similar to yours quite a lot, and they usually are local installation problems. You most likely have a local problem with your installation of Subversion and related software. Quite possibly your kdesvn libraries were linked against a different set of libraries than they are combined with at runtime. You don't mention if you're compiling kdesvn yourself, too. If not done carefully, installing and running a mixture of vendor-provided distribution packages and self-compiled binaries can cause subtle problems, such as apparently random crashes, or unresolved symbol errors like you are seeing. These can of course be fixed and worked around, but I'd like to encourage you to use pre-compiled packages from your distribution vendor instead. > Why are you compiling your own binaries? If you use binary packages you won't have any such problems. I want to make my own Linux distribution and I've compiled from source almost every package except for firefox, thunderbird, and openoffice. I agree that this is a local installation problem. However, I am not equally sure that the problem is *not* with Subversion: if the problem is with some other package, can you explain how this package can "force" libsvn_ra_neon-1.so.0 to use an undefined symbol (GENERAL_NAME_free)? Just for information, neon was installed before subversion, and subversion was installed before kdesvn. Please note that I'm only trying to diagnose the problem. I'm not saying that subversion is buggy -- in fact, the problem might be in the way I configured (or built) subversion. I'm just seeking help here... Btw, could neon from Subversion's package have anything to do with this issue? Thanks for your long answer, Angel Tsankov
Re: libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free
On Tue, Jul 20, 2010 at 7:32 AM, Angel Tsankov wrote: > When I run kdesvn I get a dialog showing the following message: > > Could not find our part: Cannot load library /usr/lib/kde4/kdesvnpart.so: > (/usr/lib/libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free) > > Files /usr/lib/kde4/kdesvnpart.so and /usr/lib/libsvn_ra_neon-1.so.0 both > exist. The former is part of kdesvn and the latter is part of subversion. > In case this is relevant, I have installed the following packages: > > * openssl 0.9.8j (configured with --prefix=/usr --openssldir=/usr/share); > * neon 0.28.4 (configured with --prefix=/usr --with-ssl); > * subversion 1.6.12 (configured with --prefix=/usr). > > Do I need to upgrade openssl or neon? Or is the problem elsewhere? Start from the beginning. Are you building all of these components yourself, and then slapping kdesvn on top? Or are you installing pre-built binaries from an upstream source? If you're installing from upstream, I'd guess that you are getting the components from different sources and need to recompile kdesvn. And this sort of conflict is why building from scratch is a lot of extra work. > >
Re: fixing files committed with wrong eol-style
On Tue, Jul 20, 2010 at 10:16 AM, Les Mikesell wrote: > On 7/20/2010 12:49 AM, Nico Kadel-Garcia wrote: >> Look, *BREAK* the history. History is overvalued: Make a clean tag >> with your final pre-switchover release, with a note explaining what >> happened, and make an entirely new repository or branch with entirely >> imported code. It will be much cleaner to track and follow what >> happened without trying to back-revise history of mixed EOL >> configurations. > > I have to disagree very much with this. The ability to easily see what > changed between any two points is most of the value of using version control > systems. Sometimes you won't know why the old way was better until long > after you've forgotten the details of the changes - or the person who made > them may no longer be around. The EOL problem makes this a seriously broken problem. The wreckage of the old code is in a clean location, where the changes can be tracked too, but there is *NO WAY* to "easily see what changed" between files with unpredictably changing EOL's. With a clean demarcation, you have a well denoted break point to mark where you'll have to change procedures to get your diffs.
Re: libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free
Nico Kadel-Garcia wrote: On Tue, Jul 20, 2010 at 7:32 AM, Angel Tsankov wrote: When I run kdesvn I get a dialog showing the following message: Could not find our part: Cannot load library /usr/lib/kde4/kdesvnpart.so: (/usr/lib/libsvn_ra_neon-1.so.0: undefined symbol: GENERAL_NAME_free) Files /usr/lib/kde4/kdesvnpart.so and /usr/lib/libsvn_ra_neon-1.so.0 both exist. The former is part of kdesvn and the latter is part of subversion. In case this is relevant, I have installed the following packages: * openssl 0.9.8j (configured with --prefix=/usr --openssldir=/usr/share); * neon 0.28.4 (configured with --prefix=/usr --with-ssl); * subversion 1.6.12 (configured with --prefix=/usr). Do I need to upgrade openssl or neon? Or is the problem elsewhere? Start from the beginning. Are you building all of these components yourself, I build myself all of these packages from source and install them. and then slapping kdesvn on top? I don't know what you mean by 'slapping kdesvn on top'. I simply build (from source) and install kdesvn after installing all these packages the way I already explained. > Or are you installing pre-built binaries from an upstream source? No, I'm not installing pre-built binaries. Angel Tsankov
Subversion client ssl cert configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am currently trying to configure my svn client so it automagically uses my client ssl certificate to authenticate to our svn server. The documentation states that one simply should edit the configuration in .subversion/servers by adding a new group, i.e. [groups] mygroup = my.server.example.net and then adding the configuration under the group, i.e. [mygroup] ssl-client-cert-file = /path/to/the/client/cert/mygroup.p12 This does work so far. What I do want to do now though is to assign specific certificates depending on which directory I access on this svn server; i.e [groups] mygroup = my.server.example.net/svn/myrepo1 mygroup2 = my.server.example.net/svn/myrepo2 [mygroup] ssl-client-cert-file = /path/to/the/client/cert/mygroup.p12 [mygroup2] ssl-client-cert-file = /path/to/the/client/cert/mygroup2.p12 This does not work so far. As I understand it, svn simply tries to match the hostname of the server against the patterns under [groups] but not the rest of the URI. Is there a way to change this, or configure svn to match the full URI against the pattern? - -- Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMRvfhAAoJENUwDGtuxH+UCtcIAKH0jnhFoyKtf84KIBmKKTBJ 51ikA9DMctHkD2D7oH/xKna13Yy/h5+F3uqGOIaH95ZqUnbDSsR1wMuXJ2dZ3oCV v4PB8/tGfU5eSX6tgiXMu09aGfD+3BlCIzcpx3M7xxtoLrD53NUMZwHQK6L7Zdx5 3tG1mSH2Vmm0OIEgQpBZFHvit2FRqGMq/CUa33YLcwMc0wQTSYpoqUyp6YAP1x0e rvEDxPEIu+AObZ+kVMK24yUSTCWPKSd7V53B+jCpHJSZysA6fMpxaYhoRPD8pvOW 4XDiPanKM5pQdlYWRW54OFRj3jr5E9w5wjX5D0x2HfEKqHU0hx/QtWI02FrPxWA= =aM9Y -END PGP SIGNATURE-
Re: question on Subverison confguration
> I am new to any version control system. > I need to create an environment to test the below. > How do we create multiple repositries on the Sub version system? > How to tag the branch looping 20 times? > Can anyone help me on this. > > Create a large NFS file system for the source control repository and connect > it to the Subversion system referred to as Rep1. > > Create a large NFS file system for a second source control repository and > connect it to the Subversion system referred to as Rep2. > > Loop the following 20 times to create a deep Subversion repository for Rep1 > and Rep2: > [...More stuff...] I can't imagine why anyone would be doing this -- except if this was a test of your knowledge. There is nothing listed in your directions that a person with just a year or two of Linux experience can't do on their own. Loop 20 times? Basic stuff in Shell. Create new directories and cd into them? Beginning shell programming. The Subversion stuff isn't standard Unix stuff. Actually, it probably is by now since Subversion comes with all versions of Unix and Linux (even Mac OS X). But, it shouldn't take more than a few hours to go through the Subversion manual and find everything you need. The Subversion manual is one of the best open source manuals I've read. It goes through the basics of source control, and how Subversion works. And, you can certainly skip the stuff in the last half of the book (at least for now). I've have helped people with complex issues and even written a few customized pre-commit scripts for people on this list. I've setup test Subversion servers and mirror repositories to test answers. But your question is about a very specific task, and a type of task that really has little to do in the real world. It is the type of task that a teacher or potential employee would ask ask a test to prove your competence in what you profess to know. And, that's where I have to draw the line. I cannot help someone cheat on a test. Worse, I've been on the short end when it comes to cleaning up a mess by someone whose credentials didn't mesh with their abilities. In another email on this thread you asked: "Could you please provide the syntax for tag the branch using svn?" You need the exact syntax? Go to the Subversion Manual which is on line. It's at http://svnbook.com. It's the very first entry when you Google "Subversion Book". Then search for the word "Tag" on the Table of Contents. That'll point you to Chapter 4. Right there in the top of Chapter 4, under "Creating a Simple Tag" is the exact syntax you're requesting. Read a bit farther, and it explains: - But wait a moment: isn't this tag creation procedure the same procedure we used - to create a branch? Yes, in fact, it is. In Subversion, there's no difference between - a tag and a branch. Both are just ordinary directories that are created by copying." If you found this confusing, we'd be happy to clear this up for you. It's how you learn. But, it appears instead you don't want to bother with even knowing the information. You merely want someone to do it for you. I find having to learn new ideas and ways of doing things the best part of my job. It's how I learned Subversion. It's how I learned version control. It's how I learned Perl, Unix administration, shell scripting, and now Python. In fact, I'm busy rewriting many of my Perl scripts into Python not because my job requires it, but because it's a good way to learn Python. it would take me about 10 minutes or so to bang out a basic outline of what you want. Heck, most of the people on this list could do it in five minutes and it'd probably be more error free than the crappy code that I write. The fact that no one has done this probably means most people on this list are rather suspicious of your request. It appears too much like a school assignment rather than something needed for work. If you don't know shell scripting, get yourself a good shell scripting book and learn. In a year or two, you'll find that knowing shell scripting will get you much farther along in your career. Pick up the Subversion manual and follow the on line examples. In a week, you'll know enough to setup repositories and do basic administration. Knowing Subversion will also help you in your career. After that, learn Git, Perforce, and CVS, and you'll know enough about version control systems that you'll be able to pick up any new ones in a few days. Once you start making an attempt to learn this stuff, you won't have any troubles finding people willing to help you on this list or various other places on the Internet. -- David Weintraub qazw...@gmail.com
--native-eol setting not applied to externals?
I have a set of source code containing a some svn:externals references to other repositories. In each group of code, there are text files marked with the svn:eol-style property, value: native. If I export all the source without using --native-eol on Windows or UNIX, the text files are all in the expected format (CRLF or LF, respectively). If I export all the source on Windows, using the --native-eol LF option, the text files in the non-external area are correctly in UNIX LF format. The text files in the external areas are in the native Windows CRLF format. Apparently the --native-eol setting is not applied to the source in the external areas. If I export all the source on UNIX, using the --native-eol CRLF option, the same problem occurs in reverse. The non-external text files are correctly in Windows CRLF format, and the external text files are in the native LF format. I think the expected behavior should be to have all the source (main and external) exported in the format specified with the --native-eol option. As a workaround, we are currently exporting the externals separately, with the appropriate --native-eol option, after exporting the main source with the --ignore-externals option. This works as expected. The versions of client and servers are all >= 1.6.5. Can anyone confirm? Thanks, Mark
Re: --native-eol setting not applied to externals?
Mark Hanson wrote on Wed, Jul 21, 2010 at 08:37:25 -0700: > I have a set of source code containing a some svn:externals references to > other repositories. In each group of code, there are text files marked with > the svn:eol-style property, value: native. > > If I export all the source without using --native-eol on Windows or UNIX, the > text files are all in the expected format (CRLF or LF, respectively). > > If I export all the source on Windows, using the --native-eol LF option, the > text files in the non-external area are correctly in UNIX LF format. The > text files in the external areas are in the native Windows CRLF format. > Apparently the --native-eol setting is not applied to the source in the > external areas. > > If I export all the source on UNIX, using the --native-eol CRLF option, the > same problem occurs in reverse. The non-external text files are correctly in > Windows CRLF format, and the external text files are in the native LF format. > > I think the expected behavior should be to have all the source (main and > external) exported in the format specified with the --native-eol option. > > As a workaround, we are currently exporting the externals separately, with > the appropriate --native-eol option, after exporting the main source with the > --ignore-externals option. This works as expected. > > The versions of client and servers are all >= 1.6.5. > > Can anyone confirm? > No. Using July 18 trunk, both with file externals and directory externals, an exported file with svn:eol-style=native has the --native-eol end-of-lines in the export. I used the 'svn export --native-eol=foo WC WC' syntax. > Thanks, Mark >
Re: Subversion client ssl cert configuration
Bernd May wrote on Wed, Jul 21, 2010 at 15:36:34 +0200:
> What I do want to do now though is to assign specific certificates
> depending on which directory I access on this svn server; i.e
> [groups]
> mygroup = my.server.example.net/svn/myrepo1
> mygroup2 = my.server.example.net/svn/myrepo2
> [mygroup]
> ssl-client-cert-file = /path/to/the/client/cert/mygroup.p12
> [mygroup2]
> ssl-client-cert-file = /path/to/the/client/cert/mygroup2.p12
>
> This does not work so far.
>
> As I understand it, svn simply tries to match the hostname of the server
> against the patterns under [groups] but not the rest of the URI.
>
> Is there a way to change this, or configure svn to match the full URI
> against the pattern?
>
Haven't checked the code, but I wouldn't be surprised if this was hard wired.
(Probably part of the code is in libsvn_ra_{serf,neon} and part in
libsvn_subr.) Could you provide multiple files to the ssl-client-cert-file
setting? Or just concatenate all certs into one big file
(mygroup1-and-mygroup2.p12) and then point to that?
Daniel
(sorry, I don't have time to dive into the source myself right this second.)
> - --
> Bernd
> -BEGIN PGP SIGNATURE-
