I think it's a config error based on similar, but not identical answers to errors I found such as requirement 'fncache' not supported.
No idea where this is coming from, but it started happening AFTER the upgrade.
This is usually a problem with the server setup. It means the server does not return the expected answer.
Are you using static-http? (and please add the command line you are using when you get the error).
It seems that there is an old hg executable in your path. The error message comes when a client tries to acces a local repository which is created by a higher hg version.
Related
I have attempted to install Psychtoolbox for Octave on Windows 10, per the installation instructions. Before the installation completes, I get this warning:
Screen() failed to work for some reason:
Check the troubleshooting instructions on our Wiki (Download section
and FAQ section, maybe also the Bugs section).
You may need to delete (or rename) the following DLL files in your Octave-4.4.1 installations
bin folder to make this work, then restart Octave:
C:\Octave\4.4.1\bin\libglib-2.0.0.dll
C:\Octave\4.4.1\bin\libgmodule-2.0.0.dll
C:\Octave\4.4.1\bin\opengl32.dll
Once you manage to fix the problem (simply type 'AssertOpenGL' to verify
that stuff works now), you do not need to run the installation routine again,
but can start working immediately.
I had already deleted the named DLL files, which I confirmed. I then ran AssertOpenGL and received this error:
Last Error: could not find library or dependencies: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
Simply calling Screen directly gives this error:
error: library open failed: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
However, the directory containing Screen.mex is at the very top of my path:
Octave's search path contains the following directories:
.
D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64
D:\Coding\PTB\Psychtoolbox
<etc>
As such, the solution to this similar question is of no use. What might I be able to do to correctly configure PTB on Octave?
What version of gstreamer are you using? I had a similar problem recently and fixed it by installing gstreamer 1.14.4. The latest version of gstreamer will not work, nor will versions earlier than 1.14.4.
It seems that Bitbucket has now blocked TLS 1.0 and 1.1.
I am working in Eclipse on Mac OSx 10.12.6 using the MercurialEclipse (hg) 2.2 plugin.
I was receiving SSL handshake errors whenever I tried to pull from the remote Bitbucket repository.
I tried updating the plugin and doing a fresh install, but it still gave the same error.
Then I tried downloading and installing the latest Mercurial package (4.8) from the mercurial web site.
After doing this the error changed to this:
warning: connecting to bitbucket.org using legacy security technology
(TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for
more info abort: error: [SSL: WRONG_VERSION_NUMBER] wrong version
number (_ssl.c:590)
I tried downloading the latest Python, both 3.7.1 and 2.7.15 as I read on Mercurial's site linked in the warning that that it had something to do with Python's OpenSSL implementation, but I still get the same error.
Any suggestions on how I can get Mercurial to work with Bitbucket via TLS 1.2?
I tried the
[ui]
tls = False
This worked for me, though I do not get why. bitbucket only uses tls 1.2, and this seems like it would turn it off. Does anyone know why this worked? It is just bugging me.
I was on Mac OS X 10.12 "Sierra". I updated to 10.13 "High Sierra" and it fixed the issue.
Notably... when I run openssl version now, I get: LibreSSL 2.2.7. Where as before on 10.12 I got: OpenSSL 0.9.8zh 14 Jan 2016.
As you i had the same issue , i had done the above mentioned solution in my VirtualMachine that solved the problem though, whereas in my realtime server this did not solve. The only option you got left is changes your hgrc file within the repository ie "reponame/.hg/hgrc" and update the default path to "ssh://hg#bitbucket.org/'reponame'" instead of "https:#bitbucket.org/'reponame'" its not a good solution but will work until Bitbucket support team comes up with some solution.
Doing this has solved my issue.
Just a Suggestion can you create a "hgrc" file and add
[ui]
tls = False
and give it a try.
I upgraded to Tortoise 3.6.3 yesterday and now I am prompted every time I pull or push a repo. The keyring is set properly, and my user name is in the url.
Any ideas on what may be wrong? Did 3.6.3 break keyring?
Issue 4401 "mercurial_keyring always asks for user/password" from time of 3.6.2 closed as pure extension-specific and contains solution: don't use username in URL anymore
Here is what to put into .hg/hgrc:
[auth]
default.username=myname
default.prefix=http://myrepo
A good way to debug issues like this is to run merciural from the command line with the debug flag, as in:
hg pull --debug
This will clearly indicate if there are problems getting the repo, user name, and password.
UPDATE: A new version of TortoiseHG has been released (3.8.3 at the time of writing) and fixes this issue: upgrading to latest version should be enough.
I had this exact same problem and found the following investigation article to be quite helpful to better understand what't going on (I'm not the author, BTW).
To cut it short, it seems a bug of the mercurial_keyring extension v1.0.1, introduced in TortoiseHG 3.6.2, which also appears to be fixed in v1.1.1.
If you're into Python compiling, it should be possible to upgrade it manually into TortoiseHG by getting it from its official bitbucket repo, compile it and manually place it into TortoiseHG's /lib/library.zip file (backup it beforehand might be wise): if you're not, you have 2 options:
1) clone the bitbucket repo to your HDD and then configure your Mercurial installation to use the new version of that extension module by writing the following in your C:\Users\USERNAME\mercurial.ini file (which was what I did):
[extensions]
mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
(Notice: you might also have to put the path in your PATH or PYTHONPATH env variable, depending if you already have Python and/or Mercurial installed on your machine).
2) wait for the next TortoiseHG release that will contain the updated version.
I try to upgrade to the newest alpha due some testing of extensions. But I get this error, and after Googling some time, I haven't been able to find it.
Fatal error: Class 'Wikimedia\Assert\Assert' not found in /var/www/MediaWiki/includes/libs/ProcessCacheLRU.php on line 132
Since WikiMedia 1.25, some modules were extracted out of the core to vendor directory, including the assert module. To plug these, add the following line:
require_once "vendor/autoload.php";
When installing from Git, you may need to clone another repository.
I had forgot to run
composer update
I can extend this answer by saying you are running this in the prompt in the root directory of your installation. Read more on https://getcomposer.org/
I want to deploy my application to glassvish v3 with asadmin deploy command however I get an error:
com.sun.enterprise.admin.cli.CommandException: remote failure: There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive#1c2a1c7
What can be the problem?
To me, the problem was coming from the fact that in /domains/domain/applications there was still the application I was trying to deploy again.
Another file access possibility I just ran into:
Service was started as root and the app undeployed/deployed. Then, as the correct limited rights user, undeploy/deploy. On deploy you'll receive this error, as the application files will still exist in he 'domains/yourdomain/applications' directory, and will be owned by root.
+1 to Keeg's comment on the awesome error messages we've all come to expect from Glassfish.
Hey I got the same error.In my case,I'd made a directory named "Web-INF",apparently the name of the folder has to be (mandatory) in upper-case i.e. "WEB-INF".
In short,check for spelling errors.
It solved my issue.So just wanted to share.I'm new to glassfish, so can't really tell you the exact solution.But what worked for me could be a solution for you as well.
Just in case someone else finds this question and the above answer doesn't match your case... Our problem was that the temporary area on the Glassfish server was full. Clearing some space let me redeploy the same application. Thank goodness for excellent error messages.
I had an ear project, where the ear package had different version number configured to maven pom.xml than the rest of the projects it contained. It searched sub-modules from version 1.x and the rest of the project was at 1.y version. I updated every pom to same version and that made the trick.