The most humane walkthrough found so far: http://ralf.schaeftlein.de/2009/02/04/howto-setup-a-openldap-server-for-ubuntu-810/
Aug 27, 2010
Aug 12, 2010
It is best to install Eclipse standalone and use its own software update/install mechanism, rather than rely on system package management (pacman, in this case). This avoids all sorts of permission and plugin conflicts.
Mar 05, 2010
After installing Atlassian Connector in Eclipse and everything just goes to shit: all installed plugins disappear from preferences. The problem, as it turns out, lies in installing Eclipse as root (sudo pacman -S) and later installing plugins while Eclipse is running as non-root.
So, the right thing to do is either:
- run Eclipse as root when installing packages; or
- chown /usr/share/eclipse to the appropriate user.
Feb 09, 2010
After updating to GWT 2.0.1 (official) and moving our project to a arch/vbox, I had a small adventure trying to get DevMode window to come up: it just wouldn't. The window just came up blank and nothing else happened.
It turns out you are running awesome, Java may not play nice. You need this:
And remember to export GDK_NATIVE_WINDOWS=true to make all your Eclipse buttons work correctly.
Thanks to selckin on ##gwt for wmname suggestion.
Jan 26, 2010
After two weeks of research and experimentation, finally arrived at the settings that stop Eclipse from making you want to gouge your eyes out.
This goes into ~/.Xdefaults:
Xft.dpi: 76 #84 for 27" iMac Xft.antialias: true Xft.hinting: true Xft.hintstyle: hintslight Xft.rgba: rgb
And this is what's installed (in that order):
drwxr-xr-x 2 root root 4096 Jan 15 11:26 pkgconfig-0.23-1 drwxr-xr-x 2 root root 4096 Jan 15 12:00 freetype2-ubuntu-2.3.11-2 drwxr-xr-x 2 root root 4096 Jan 15 12:02 fontconfig-ubuntu-2.6.0-8 drwxr-xr-x 2 root root 4096 Jan 15 12:29 libxft-ubuntu-2.1.14-2 drwxr-xr-x 2 root root 4096 Jan 15 13:05 cairo-ubuntu-1.8.8-1 drwxr-xr-x 2 root root 4096 Jan 18 10:13 ttf-inconsolata-20090215-1 drwxr-xr-x 2 root root 4096 Jan 18 10:15 ttf-bitstream-vera-1.10-6 drwxr-xr-x 2 root root 4096 Jan 25 22:06 ttf-dejavu-2.30-1
And this is why we like to use Macs.
By the way, the .Xdefaults bit above also helps with X11 on the Mac (yay for wireshark).
Jan 19, 2010
This is surprisingly elusive, so here it is. After creating a debug/run target with Run/Debug as... -> Python run, add this variable in the Environment tab:
If you're debugging Django, add another:
You will also want to add --noreload to your runserver argument.
Jan 11, 2010
Per `default installations instructions`_ the clipboard integration does not work in guest xterm. The problem with xterm is that by default it uses a different internal clipboard.
To fix, add the following to ~/.Xdefaults:
XTerm*selectToClipboard:true XTerm.vt100.translations: #override \n\ Shift : ignore() \n\ Shift : insert-selection(CLIPBOARD,PRIMARY,CUT_BUFFER0)\n\
instructions: http://unthingable.eat-up.org/?p=3 .. _original solution: http://forums.virtualbox.org/viewtopic.php?f=3&p=118929
Jan 10, 2010
This is a +1 to the touting of the virtues of virtualization.
A number of things happened recently — a new iMac, a new dev project, new developers on the team, new unexplained gremlins — that made me realize: virtualization is the way to go. We develop on Linux, so I chose VirtualBox because it's free-er and lighter than VMWare.
Software is not system agnostic. If you chose to develop on your own machine then it has to serve several masters: you, the owner and operator, and the projects you're working on. As a result, you spend time configuring your system for multiple potentially conflicting tasks and solving system-related problems instead of actually working on the project. Increasing the number of developers and projects obviously makes things worse.
Adding development systems and setup time
It's rarely just a simple checkout from your favorite source control repo. There are also tools and libraries to install (some of which will serve no other purpose than this particular project), tables to set up and checklists to follow.
No two environments are the same, especially when run by different people. Ultimately, each developer must design his/her own unique solution to getting the project to run on their system. Sometimes the solution does not exist.
There is crap you install for every project and probably never remove. Then there is crap that has to run as part of the context of working on project X: Eclipse, several VIM sessions, consoles, terminals, CSS color pickers, etc.. This is crap you have to fire up and shut down when you switch contexts. No, you do not have unlimited system resources.
If all this crap hogging your precious system is bad enough, what do you do when you have, say, two projects that require different versions of Postgres?
Conflicts with YOUR system
Even if only work on one thing, your personal machine lives its own independent life. What happens to your machine during its course might affect your environment in ways you may not expect, much less like. Just recently a Safari 4.0.4 (how appropriate) broke GWT hosted mode, and the only solution was a manual rollback. Yeah, fun!
Your environment-sensitive projects are bad for your system. Your system is bad for your environment-sensitive projects. They must be divided.
Why, of course the nice isolated VM that fires up in an instant and tucks away when not needed.
Every developer can have the exact same environment
No unexplained irreproducible glitches, no variances.
Press a button and your whole development environment disappears. With all its running tomcat servers, databases end editors. System resources: free!
Press another button and it's back exactly as it was.
Snapshots are incredibly useful. Save any known good state and revert to it when things have gone bad. No need to retrace your steps if you don't want to.
More importantly, this is unlimited freedom to try anything. Want to replace X11 fonts and see what it looks like? No problem! Make a snapshot and fire away. You'll be spared the agony of having to fix the system you just broke.
As of VirtualBox 3.1 snapshots are brancheable! You can branch off any snapshot, past or future (relative), and have a whole tree of them. Right now you can only run one snapshot at a time, though, but there is a way of spawning off a new machine.
Your target environment will likely be different from your host. In a VM it can be exactly the same, or at most you'll have to resolve conflicts between one development environment and the target, rather than many.
Jan 09, 2010
Followed the `rpm installation instructions`_. Installed "Development Libraries", " Development Tools", gcc-devel, etc.., and kernel headers from the repo:
# yum install kernel_headers # export KERN_DIR=/usr/src/kernels/2.6.18-164.10.1.el5-x86_64 # /etc/init.d/vboxdrv setup ... [FAIL] # uname -r 2.6.31-302-rs
Version mistmatch. Damn.
Ah, here we go: `proper headers`_ â€” yay! Wait, what? /usr/src/linux-headers-2.6.31-302-ec2/scripts/mod/modpost requires GLIBC_2.8, and we can't mess with glibc or the kernel. Attempted building and installing glibc 2.8 on the side, no go. Damn.
Ok, it's been a day now, we get resourceful and desperate:
# cd /usr/src/linux # rm srcipts/mod/modpost # make scripts # ldd scripts/mod/modpost (no problem, yay) # /etc/init.d/vboxdrv setup ... [ DONE! ]
Finally! OK, let's fire it up:
# VBoxHeadless !!Assertion Failed!! Expression: GipMapReq.u.Out.pGipR3->u32Magic == SUPGLOBALINFOPAGE_MAGIC Location : /home/vbox/vbox-3.0.12/src/VBox/HostDrivers/Support/SUPLib.cpp(321) int SUPR3Init(PSUPDRVSESSION*) Trace/breakpoint trap
Fuck it. I give up.
So, to recap: after a full day of installing headers, installing hacked headers, building glibc 2.8 and a futile attempt to get vboxdrv to build with that, hacking modpost, trying two different PUEL versions (3.0 and 3.1) we still get nothing.
VBox OSE won't compile because of failing some version dependency checks and CentOS repo is hopelessly out of date. Tried with multiple different versions of vbox, ultimately it's too much pain.
Another possibility worth exploring is bringing up the image in vmware or xen.
instructions: http://www.virtualbox.org/wiki/Linux_Downloads .. _proper headers: http://cloudservers.rackspacecloud.com/index.php/Installing_Kernel_Headers_for_2.6.31-302-rs
After a couple of days of digging through outdated and conflicting documentation, I finally figured out the proper steps. Then jamesconway from #vbox put it all nicely together:
As root: 1. pacman -Syu xorg install entire group (is everything actually required?) 2. pacman -S kernel26-headers gcc make 3. Install guest additions 4. X -configure 5. change the mouse driver from "mouse" to "vboxmouse" in /root/xorg.conf.new 6. mv /root/xorg.conf.new /etc/X11/xorg.conf 7. add hal to DAEMONS in rc.conf rc.vboxadd is not required because it is added to /etc/rc.local automatically Not as root: 8. add /usr/bin/VBoxClient-all to the top of ~/.xinitrc (even if it does not exist)