Building Subversion 1.5.4 on Debian: Could Not Find Library Containing Rsa_New

Building Subversion 1.5.4 on Debian: could not find library containing RSA_new

Check out my response over here.

Upgrade Subversion 1.4.3 to 1.5.2 on Debian (hosted account)

If you're using openssl with SVN then you need to configure SVN with

./configure .... --with-openssl=/path/to/openssl

When I've done this in the past I've had issues building other binaries that use this lib if I don't specify the -fPIC flag. So it's best to run make with that parameter (if you have that issue). You may also have to point make at your build binary as well.. so your make call will look something like this:

make CC="gcc -fPIC" LDFLAGS="/path/to/openssl/lib"

Don't forget to build openssl with CC="gcc -fPIC" too!

Good luck!

Interoperability of Mercurial 6 with other VCSes

So, as a current maintainer of hg-git and former contributor to hgsubversion, I think I can provide some context here.

Regarding hgsubversion, the short answer that it is either dead or — at best — extremely dormant. Personally, I have not interacted with a Subversion repository in years, and that's a common experience. No-one has been sufficiently motivated to fix bugs, keep it working, and — last, but not least — make it work with Python 3.

For hg-git, a period of semi-dormant state meant that the TortoiseHg maintainers stopped bundling it. We now keep up with Mercurial releases, and I've requested that they reverse that decision. I believe they bundle Dulwich, but as I don't use Windows, I can't say for sure. That said, it's quite reasonable to want to use hg-git with TortoiseHg, and if you run into any specific issues, I'd suggest you file a bug with them — or perhaps add a comment to the bug I linked earlier.

Generally speaking, you should be able to use 0.10.x version of hg-git with most versions of TortoiseHg, as I believe they bundle Dulwich. In that case, enabling the extension should be as simple as:

hg clone -u 0.10.x http://foss.heptapod.net/mercurial/hg-git /path/to/repo

And then adding the following to your .hgrc:

[extensions]
hggit = /path/to/repo/hggit

Once TortoiseHg moves to Python 3.x, the default branch of hg-git will work with it again.

EDIT: I was wrong; they don't bundle Dulwich, it seems. On the bug for this, one of the maintainers posted a link to a packaged installer that includes hg-git & Dulwich. The next release, 6.1, should fix this. Please consider testing the installer, and report to the TortoiseHg maintainers whether it works as expected.

EDIT²: Please note that only SSH works with that installer, as they ran into some issues bundling urllib3, which is necessary for HTTP support.

OpenSSL v1.1.1 Ubuntu 20 TLSv1 - no protocols available

I've just solved my problem with - https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level

Just quoting this link:

You need to add this to the beginning of your config file:

openssl_conf = default_conf

And then this to the end:

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:@SECLEVEL=1

The comment on the above link said:

Note that if you prefer you can make changes to a local copy of the config file, and then ensure your process is started with the environment variable OPENSSL_CONF defined to point at the location of your config file:

export OPENSSL_CONF=/path/to/my/openssl.cnf

This way you can make changes without having to impact your entire system.

I used the second choice "export OPENSSL_CONF=/path/to/my/openssl.cnf" and worked perfectly!

What causes the SVN Error Not a working copy?

If you get a "not a working copy" when doing a recursive svn cleanup, you likely have a subdirectory which should be a working copy (i.e. the .svn directory at the top level says so), but the subdirectory is missing its own .svn directory.

In that case, you could move or delete that directory and then do a local update. To delete the directory,

rm -rf content
svn checkout content

WARNING: rm -rf deletes the folder content permanently.

If you get a not a working copy error, it means that Subversion cannot find a proper .svn directory in the content subdirectory. Check to see if there is an .svn directory in content.

The ideal solution is a fresh checkout, if possible.

---

Related Topics