I had installed Eclipse 3.5 Yoxos on my Ubuntu 8.04 for month, and run fine. I had upgraded to 9.10 last week, and the subversion plugin does not work since upgrade.
When I try to update or commit, Subversion work for hours without any progress in console or progress bars. I can delete files or add them to SVN, but commands wich involve network just hang.
SVN run fine using command line.
I have already patched the GDK problem. Since this I can cancel update/commit without crashing Eclipse.
Regards
Cédric
addedum: here is the error showed in the Eclipse console after severals minutes. On the same directory the command line run fine.
*** Update
svn update "/home/cedric/www/VOO123" -r HEAD --depth infinity
svn: timed out waiting for server
svn: OPTIONS request failed on '/VOO123/trunk'
*** Error (took 10:43.893)
It might be related to the IPV6_V6ONLY setting - I know that this can be a problem for some Java apps on Debian.
Take a look in /etc/sysctl.d/bindv6only.conf and look for a line starting with net.ipv6.bindv6only. If it isn't already, set it to 0:
net.ipv6.bindv6only = 0
Hard to say since you don't even mention which plugin you're using but if I remember well, I was using Subclipse with the SVNKit Client Adapter successfully on Ubuntu 9.10 (I use Subclipse with the JavaHL (JNI) library again on Ubuntu 10.04).
Problem solved : Eclipse have problems under Ubuntu Karmic (9.10), you have to inactivate Assistive Technologies to sold them (a cash in libpango), and since I had inactivated them and restarted my session, it just fine, SVN included.
Related
Until yesterday I had the following dev environment perfectly working:
Ubuntu LTS 20.04
Eclipse (in Snap)
JavaFX (JARs and *.so's in local Folder, --module-path configured in project)
Yesterday "snap" came up and said: stop the app to let updates be installed ... I think, it was talking about Eclipse.
After having Eclipse restarted, my JFx application complained about "glass not being in Java Lib Path". I know this error from Ubuntu LTS 22.04 and could not fix it a month ago (when repairing all paths, you'll end up by some lib ONLY accepting a glibc 2.33, but I already have 2.35) ... that's why I rolled back to 20.04 a month ago :-/
Now this bug hits me again in 20.04 via snap updates.
I drilled the behavior down to having a project's debug commandline, that shows above error. It starts to work as soon as I change that cmd line to NOT use Eclipse's build-in JRE located in Eclipse's snap path. Result: it only works outside of Eclipse now.
Question: does anybody know, how to find the connection in Eclipse's config, that causes Eclipse's Java to use the (obviously freshly installed) snap-version of openjfx (19+11) instead of a working and properly configured (old) local JFx version?
That version seems buggy and does NOT work for Ubuntu 22.04 also in an out-of-the-box installation.
^5
Synopsis
//EDIT: in case this matters ... just saw, that in /snap/eclipse there are TWO versions (60 and 61), with current pointing to 61, BUT the debug-commandline path, showed by Eclipse, uses 60 (not "current and not 61). When I manually launch the Eclipse in 61, it appears completely fresh, without default workspace path and without any plugins.
So when using (on commandline) the java from there, it also works, having no JavaFX plugin under Eclipse dir "61".
I don't reaaly get the idea of a "current" that is unconfigured and all paths pointing to old dir 60 ... obviously my lack of knowledge about snap :-/
I found a workaround: I added an external Java Execution Environment (the system owned JRE) and configured the project to use that.
Now it works again from within Eclipse using the old JFX in my home dir - even the debugger is working fine :-)
But this is no clean solution. I want to have in MY influence, what stuff the internal Java Environments of Eclipse are using. I cannot accept, that the internal JREs are magically connected to some magically appearing snap-app (openjfx 19/11) without even a notice to me or better the option to say "no" to either new snaps or snap updates.
well ... talking to myself :-)
LAST update: some background rollback appears to have sent me to the Test-VM with Ubuntu 22.04 instead of my active VM with Ubuntu 20.04.
So my posted workaround can be regarded as working for those that desparately try to get JavaFX working under 22.04 :-)
So the "problem" I thought to see concerning 20.04 does not exist ... sorry.
I have installed VS Code version 1.8.1. Machine is Windows 7, 64 bit. While installing ionide-fsharp extension, I am getting error "end of central directory record signature not found". It seems version 1.7.2 of VS Code works, however this issue probably seems fixed for version 1.8.0 see this git link. Any idea on how to get the extn installed?
Thanks
Found a workaround for this. Downloaded '.vsix' file of ionide-fs from this link. In VS Code Extensions tab, there is an option 'Install from VSIX'. That worked. So in case anyone is unable to install from vscode extensions tab directly(i.e. from Marketplace), they may try this way of installing an extension.
Just for information, I was getting the same error for version 1.7.2 of vscode as well while trying to install from Marketplace.
Seems there were bugs that exist in past versions, due to the embedded browser and other reasons; these have since been fixed.
The above solution seems a common way to install a troublesome plugin.
However, there is a long standing reason for this error, running out of disk space.
As of v1.54.1 (2021/03) and it turns out this can happen if your disk/home folder can run out of space during download OR install.
https://github.com/microsoft/vscode/issues/118711
I am running a virtualbox with debian installed as local webserver. I am working with eclipse directly on that virtual box with a remote project (RSE plugin). I am having the problem that eclipse starts the DLTK-indexer as soon as I open the project. On the debian machine, instantly my /var/log/auth.log is filling up with a endless list of:
sshd[4271]: error: no more sessions
In eclipse, the error log is filling up with (although using JRE 6):
org.eclipse.core.runtime.CoreException: Operation failed. File system input or output error: rse://xxx.xxx.xxx.xxx/path/to/file/being/indexed
org.eclipse.rse.services.files.RemoteFileIOException: Operation failed. File system input or output error
While indexing is done, I am not able to save any file I am working on, as all ssh-sessions are already used on the server.
It seems that the indexing process tries to open a new connection for every file it´s indexing.
When indexing is finished, everything works normal again, I can save files etc.
I would appreciate the indexer to complete its work, but as code completion does not work afterwards, eclipse was not able to do the indexing.
One solution would be to disable the indexing, but this is not the purpose of an IDE, code completion is one of the few reasons for me to still use an IDE (at least for large projects).
Any ideas on how to make indexing work and get rid of the ssh-errors would be great!
Futher system information:
Host-System: Windows 7 Prof. 64bit
Guest-System (virtualbox): Debian Lenny with sftp subsystem enabled
Eclipse: Indigo with Zend PDT and RSE (already running with Java 6 JRE 1.6.0_45)
Thanks for your help!
David
I was able to fix this issue by doing two things:
set up ssh to use multiplexing (see http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing) in the virtual machine
Upgrade eclipse to Kepler 64Bit release (much faster and more stable in Windows 7) with manual installation of PDT feature (using Zend PDT is a waste of time)
This also works with Java7!
Now I have completely indexed projects and can use code-completion!
I am in the process of getting git-svn working on my Mac. I am currently on Lion (but I had similar results when testing on Snow Leopard. I seem to be one of the few people having this issue. This is different from the issue I see that some people had with just including SVN/Core.pm.
Below is an attempt to do a git svn clone on a vanille repository (obviously the host and directory details have been changed for posting):
Macbook-Pro:git david$ git svn clone https://somesite.com/SVN/someRepo/
Initialized empty Git repository in /Projects/git/MyWorkspace/.git/
Can't load '/System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/auto/SVN/_Core/_Core.bundle' for module SVN::_Core: dlopen(/System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/auto/SVN/_Core/_Core.bundle, 1): Library not loaded: /usr/lib/libsvn_client-1.0.dylib
Referenced from: /System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/auto/SVN/_Core/_Core.bundle
Reason: image not found at /System/Library/Perl/5.12/darwin-thread-multi-2level/DynaLoader.pm line 204.
at /System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/SVN/Base.pm line 59
BEGIN failed--compilation aborted at /System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/SVN/Core.pm line 5.
Compilation failed in require at /Developer/usr/libexec/git-core/git-svn line 58.
In my case, simply installing git via Macports solved my problem. I believe this problem was probably caused by older installs (maybe the Mac OS X Git Installer). If you are in this scenario, first install Macports:
http://www.macports.org/install.php
Then, once Macports is installed (with the correct version for your OS), then run:
sudo port install git-core +svn
After this, I just had to use the git at the new location installed by Macports:
/opt/local/bin/git
I modified my PATH variable so that this was the git used by default.
I took a slightly-different approach to this problem (as I am running a beta of XCode 4.2 as well):
Install the Collabnet Subversion package. I downloaded the OSX 10.7 version as I am running Lion on my Mac.
Create a symlink of all /opt/subversion/libsvn_* files in /usr/lib/
I spent a copious amount of time trying to get this fixed. None of the approaches above helped. What really fixed the issue was to remove the following line from my ~/.zshrc (.bash_profile, if you use bash.)
export VERSIONER_PERL_PREFER_32_BIT=yes;
I have a CVS server which is known to be ok (works from other machines).
I am trying to set up Eclipse to connect from an Ubuntu box.
The following command-line command succeeds:
cvs -d ':extssh:myuser#myhost/path/to/repository' checkout myrepository
Yet when I do Eclipse 'Add CVS Repository' it hangs on this, using both extssh and pserver protocols. extssh using port 22.
(There's no error message, it just hangs. Regardless whether 'Validate connection on finish' is on or off.)
I verified that all of the settings are ok. Port 22 is not blocked.
I double-checked Preferences under 'General>Network Connections' and 'Team>CVS'
I do not think it is an issue with keyless ssh either.
This is on an Ubuntu box, but these exact same Eclipse CVS client settings succeed from a Mac box.
(The Ubuntu box uses 9.10, and Eclipse is installed as EasyEclipse 1.3.1, installed as user, not root.
Plugin org.eclipse.team.* versions are:
(Ubuntu)
org.eclipse.team.cvs.ssh,.ssh2 3.2.100
org.eclipse.team.ui,.core,.cvs.core,.cvs.ui 3.3.r33x_2007...
(Mac)
org.eclipse.team.cvs.ssh2 3.2.300
org.eclipse.team.ui,.cvs.core,.cvs.ui 3.5.100.l20100527-0800
(EasyEclipse prevents me from upgrading the Ubuntu plugins, it insists these 4-year-old ones are the latest. Maybe an argument against using EasyEclipse.)
How to troubleshoot? How to trace what is actually happening inside Eclipse?
(as 'cvs -t -t' would give)
(As a sidebar, Eclipse should actually be printing a proper error message.
I've checked every appnote and userguide I can find with Google.)
Consensus was that EasyEclipse prevents user from upgrading the (4-year-old) Ubuntu plugins, insists that 3.3.x are the latest available, which cause this hang.
As of 5/2011, EasyEclipse is retired unless a new maintainer steps up.