A channel discover would give the following error:

root@ip-10-56-47-23:~# pear channel-discover guzzlephp.org/pear
 Discovering channel guzzlephp.org/pear over http:// failed with message: channel-add: Cannot open "http://guzzlephp.org/pear/channel.xml" (File http://guzzlephp.org:80/pear/channel.xml not valid (received: HTTP/1.1 404 Not Found
 ))
 Trying to discover channel guzzlephp.org/pear over https:// instead
 Discovery of channel "guzzlephp.org/pear" failed (channel-add: Cannot open "https://guzzlephp.org/pear/channel.xml" (Connection to `guzzlephp.org:443' failed: Connection refused))

Strangely, I could fetch the channel.xml file manually and add the channel. But even then, the install would fail (with similar messages about 404 errors).

The solution seemed to be upgrading PEAR – I was running version 1.9.0 (check it with “pear -V”), so I upgraded it:

root@ip-10-56-47-23:~# pear upgrade pear

after which I had version 1.9.4. Then I tried the channel discover again, with much better results:

root@ip-10-56-47-23:~# pear channel-discover guzzlephp.org/pearAdding Channel "guzzlephp.org/pear" succeeded
 Discovery of channel "guzzlephp.org/pear" succeeded

The deployment is done by a parameterized build job, where the parameter is the version of the project that we want to deploy. The job will run remote commands over ssh on servers that you’ve defined in the Jenkins configuration. Those commands will pull down a version of our code, unpack it, and run the rest of the install steps.

First you’ll need to install the Publish over SSH Plugin, which will allow files to be transferred to your servers and remote commands to be run.

Set up the SSH key for remote access of your target servers, in the Manage Jenkins page:

and setup the definitions for each of the servers that you want to deploy to:

Then in the configuration for the new deployment job you’ve set up, you’ll use the “Send files or execute commands over SSH before the build starts” settings in the “Build Environment” section to remotely execute a script to carry out the install steps on each remote server:

Notice that the build parameter “$version” is available to the Exec command that gets remotely executed – other Jenkins environment variables will also be available (e.g. $BUILD_NUMBER, $JOB_NAME etc).

Use the “Add Server” button to add more target servers, with the same Exec command.

Now you can deploy your project (or run any other remote scripts) by running the build job and specifying a version number.

So we set up a parameterised job in Jenkins that will take the name of a branch and run the build process.

As for all github builds, you need to have installed the git plugin first (https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin) and set up your github globals in the Jenkins settings:

Then set up a parameterized build job with the repo as the GitHub project and with “branch” as the parameter to be specified:

and in the Source Code Management section, add the parameter to the “Branches to build”:

Don’t specify any build triggers – you’ll probably just want to run this on-demand against specific branches, rather than every time there’s a push to the repo (which is what happens by default).

Now you can build any branch just by giving the branch name as the required parameter when the job is started.

Here are the steps (assumes that you’ve set up your ssh keys correctly, according to e.g. http://help.github.com/linux-set-up-git/)

Setup the git globals:

$ git config --global user.name "Julian Higman"
$ git config --global user.email "jh @ kasabi.com"

Create the new project, add a README file, and connect it to the github remote project:

$ mkdir my-new-project
$ cd my-new-project/
$ git init
$ touch README
$ git add README
$ git commit -m "First commit"
$ git remote add origin git@github.com:kasabi/my-new-project.git
$ git push -u origin master

Now copy in the project source files, excluding svn files and other project config files:

$ cd ..
$ rsync -r --exclude=.svn --exclude=.buildpath --exclude=.project --exclude=.git my-old-project/ my-new-project/

Then add the new files, commit them, and push to the remote repo:

$ cd my-new-project/
$ git add -A
$ git status
$ git commit -m "added project files"
$ git push

There’s a fix for general Drush usage here: http://contrib.linalis.com/content/continuer-dutiliser-drush-quand-ftpdrupalorg-est-down

That fix changes the download url to use drupal.org (which is working) instead of ftp.drupal.org (which isn’t).

Unfortunately Drush Make uses it’s own download functions, so this doesn’t help.. Here’s my (very similar) hack to get the Drush Make downloads working..

Change line 367 in drush_make.drush.inc to the following:

'url'  => str_replace('ftp.', '', $release['file']),

(The file should be somewhere like /usr/share/drush/commands/drush_make)

And don’t forget to remove the hack when ftp.drupal.org comes back..

It’s not enabled by default on Ubuntu 10.04, but here’s how to turn it on (put it in a startup script):

xinput set-prop –type=float “AlpsPS/2 ALPS DualPoint TouchPad” “Synaptics Coasting Speed” 1

You have to declare the variable as “global” before setting it in the outer scope – then it works again.

So, this used to work (but doesn’t under PHP 5.3) :

$util = new Utility();

global $util;

function show() {

global $util;

echo "$util->version";

}

global $util;

$util = new Utility();

function show() {

global $util;

echo "$util->version";

}

I tried the obvious “sudo gem install activerecord”, but it gave an error – it needs to install the i18n gem, but that needs rubygems version >= 1.3.6, and I had rubygems 1.3.5.

So I had to upgrade  rubygems first, which would normally be :

sudo gem update --system

but that reports that it’s been disabled on Debian, and directs you to use apt-get instead (which doesn’t have a better version). So I had to use the gem-updater gem:

sudo gem install rubygems-update

sudo update_rubygems

sudo gem install activerecord

I still needed to get the mysql gem installed, which in turn needed the libmysql-dev stuff installed

Ubuntu images support CloudInit, which runs scripts on startup to allow you to configure the server (set up ssh keys, update the repos etc). There’s a load of different ways to specify what should get run (see https://help.ubuntu.com/community/CloudInit for full details).

One of the simplest is just to give it a script in the User Data, like this:

#!/bin/sh
echo "Hello World.  The time is now $(date -R)!" | tee /root/output.txt
EOF

It runs as the root user, so you can do pretty much anything you want to configure the box.

Tue Jun 08 17:39 INTERNET 2931.108 KB

Tue Jun 08 17:38 INTERNET 2930.525 KB

Tue Jun 08 17:38 INTERNET 2930.143 KB

Tue Jun 08 17:37 INTERNET 2930.299 KB

Tue Jun 08 17:36 INTERNET 2930.785 KB

Tue Jun 08 17:36 INTERNET 2930.895 KB

Tue Jun 08 17:35 INTERNET 2929.817 KB

Tue Jun 08 17:35 INTERNET 2930.283 KB

Tue Jun 08 17:35 INTERNET 2931.05 KB

Tue Jun 08 17:34 INTERNET 2930.991 KB

Tue Jun 08 17:34 INTERNET 2930.765 KB

Tue Jun 08 17:33 INTERNET 2930.441 KB

Tue Jun 08 17:33 INTERNET 2929.775 KB

Tue Jun 08 17:33 INTERNET 2929.608 KB

Tue Jun 08 17:32 INTERNET 5637.054 KB

Tue Jun 08 17:31 INTERNET 2930.137 KB

Tue Jun 08 17:31 INTERNET 2931.101 KB

Tue Jun 08 17:30 INTERNET 2930.31 KB

Tue Jun 08 17:30 INTERNET 2930.408 KB

Tue Jun 08 17:29 INTERNET 2930.107 KB

...etc

That’s about 60M in the space of 10 minutes. Which seems like a lot. Similar patterns appear at regular intervals..

Looking at the times of the entries, the data usage is due to Google Maps running on my HTC Hero, which I’m using for sat nav.

If that happens on, say, 10 days in the month, then that’s already 600M of data used. Hm.  (Add to that the Spotify usage, and 2GB starts to make sense..)

Anyone know if Google Maps can cache its data on Android?