An aggregation of all the Rock Solid Knowledge Blogs
Ubuntu makes certain things that should be difficult, easy and some things that should be easy, difficult, like assigning keys to commands. I'm a keyboard jockey, I'm way happier using the keyboard than the mouse> I tell my self this is because the keyboard is quicker, but it's probably because I cut my teeth in the days before mouse, and and in Emacs where key chords are king!
This means I am lost without my keyboard shortcuts, in Windows such things as W+L to lock (where W is the Windows key). I use Windows a lot, and if I'm using Ubuntu I'd like the same keys to work. This should be easy, however it appears that having Compiz enabled, Compiz and Gnome clash!. Gnome has dialogs to set up keybindings, but you have to jump through hoops to get it to work.
First hoop is getting Ubuntu to recognise the Windows key (called the Super key in Linux) as a key modifier, like Control and Alt. To do this go to System..Preferences..Keyboard, select the Layouts tab and then Layout Options. From here select Alt/Win key behavior and then choose "Super is mapped to the Win-keys"
Once you've done this you can now edit the Gnome keyboard preferences. From System..Preferences..Keyboard Shortcuts, scroll down to Desktop. Here you can click on the "Show the panel run application dialogue", select this and hit WindowsKey + r on the keyboard. Do the same for Run a terminal, but select WindowsKey + t. You may think you can do the same thing for the Search, Home Folder and Lock screen commands (assign them to Windows + f, Windows + e and Windows +l respectively), however, those commands cannot be assigned from here and if you try, not only will the commands not work but you may have trouble re-assigning the keys elsewhere. Instead to assign these key you will need to you the Compiz Configuration Manager
Select System..Preferences..Advanced Desktop Effects Settings. In the dialog box select General and then Commands. I have my first three commands set to "beagle-search", "nautilus" and "gnome-screensaver-command --lock" respectively and the key bindings set to
There's more here on this.
Now, if only I can get Ctrl+Esc to bring up the main menu!
I'm working with CruiseControl.net this week. First time I've worked with the product and I'm finding a couple of issues (that are all my mistakes) but that aren't particularly well documented. So this is as much for my benefit as anything else.
Firstly, last night after editing the config file I couldn't get the build to run. Now, there are several config files. in c:\Program Files\CruiseControl.NET\server, the main one is the ccnet.config file, this is the default location for this file, that location can be changed, to do that you'd edit the ccservice.exe.config file.
The ccservice.exe.config file is re-read when the CCNet service is (re)started, as is the ccnet.config file. When you edit the ccnet.config file it appears that the service does re-read the file, however, if the file is invalid the service ignores it, and doesn't appear to log this fact anywhere. Re-starting the service will force a re-read of the config file and then log an error if the file is invalid.
I was changing a CCNet config file to do multiple checkouts, after a bit of trial and error the source control section of the file ended up looking like this
<sourcecontrol type="multi">
<sourceControls autoGetSource="true" applyLabel="true">
<vsts autoGetSource="true" >
<server>http://server:8080</server>
<project>$/FOO/SharedUILibraries</project>
<username>user</username>
<password>user</password>
<domain>nt</domain>
<workingDirectory>
C:\...\FOO\SharedUILibraries
</workingDirectory>
<cleanCopy>true</cleanCopy>
<workspace>WS_MINE</workspace>
<deleteWorkspace>true</deleteWorkspace>
</vsts>
<vsts autoGetSource="true" >
<server>http://server:8080</server>
<project>$/FOO/SharedEnterpriseLibrary</project>
<username>user</username>
<password>user</password>
<domain>nt</domain>
<workingDirectory>
C:\...\SharedEnterpriseLibrary
</workingDirectory>
<cleanCopy>true</cleanCopy>
<workspace>WS_MINE</workspace>
<deleteWorkspace>true</deleteWorkspace>
</vsts>
<vsts autoGetSource="true" >
<server>http://server:8080</server>
<project>$/FOO/WD</project>
<username>user</username>
<password>user</password>
<domain>nt</domain>
<workingDirectory>
C:\...\FOO\WD
</workingDirectory>
<cleanCopy>true</cleanCopy>
<workspace>WS_MINE</workspace>
<deleteWorkspace>true</deleteWorkspace>
</vsts>
</sourceControls>
</sourcecontrol>
And this worked, however there was one gotcha. Before getting this to a working stage I was getting a status in the CCNet dashboard of CheckingModifications, whatever I did I'd get this status, even forcing a build wouldn't change it. It turned out the reason for this was that I had put the wrong name in the project element. This meant that CCNet was trying to look for bits that didn't exist, and sat there spinning its wheels. Once corrected everything worked fine.
So if you get the CheckingModifications status, check that your source control settings are correct and that you can do a checkout