Category: blog
#nuffsaid
Publicizing effectively with Jetpack for WordPress

If you are a blogger, and you use WordPress, you will undoubtedly heard of Jetpack. Jetpack for WordPress provides a ton of enhancements to any WordPress install. Among the goodies is something for the socialite in all of us: the ability to automatically “broadcast” our blog posts to social networks, including Facebook, Twitter, LinkedIn and Google+, via the Publicize feature.
All this free stuff of course comes with a “price” – having a user account on WordPress.com itself. But, if you are a blogger – or at the very least you read other people’s blogs and contribute comments – this is not exactly a hardship.
Set-up and Testing
Setting up Jetpack is as easy as installing a WordPress plug-in. If you are familiar with the process, you will probably have already seen Jetpack in the Add Plugin page.
The Publicize feature is equally easy to set up: you simply click on the button corresponding to the social network you wish to link with, a page/pop-up opens to allow you to authenticate with that social network, and then you return to the Publicize page with a “Connected as…” confirmatory message.

The next step is to write a post and then publish it. Simple, huh? Well, not quite.
Content Formatting
Due to the different ways social networks publish posts, your “write once, publish many” WordPress post may need a little tweaking before it looks as good as possible.
Links:
plus.google.com/+SteveDowe/posts/5eSkkPVLAfb
twitter.com/doweio/status/629950053499584512
Further Testing
Finding the most effective way to post requires more testing. My main aim was to find a way in which one post can look great on the three main social platforms (Google+, Twitter and Facebook – not that I care too much about the latter).
[ This is a legacy-published post, originally written but unpublished on 13 August 2015. Some details may not longer apply to recent software releases. ]
Letting go of the “must blog more” nonsense
As I write this, my last blog post was written about 6 months ago. Not exactly regular, huh!
And I have nothing else to say right now. Goodbye.
Rules for S’s
Seems that my clever little spelling ideas have fallen foul of the English language yet again!
I believed that a double-S in a word (like “hiss“) always requires a soft “ssss“, whereas a single-S is harder – a bit like “szszsz“. But no. That would be too easy.
Take “issue” (I do, quite often – but anyway..). You could say “i-shu” or “iss-yu“. But what about “dissolve” (“dizz-olve“) – that conflicts with my rule, although “dissolution” (“diss-o-lu-shun“) doesn’t.
Disappear ? Soft “ssss” – again, a conflict. Occasion?
Recover virtual machine LVM config when removing physical LVM PV

Yes, I really could not think of a better title for this. 🙂
Recently I added a new drive, connected by USB, to a test server. It was for sharing with a virtual machine running on that server.
Chain of oops
When I connected the drive to the host, I decided to create a volume group and logical volume on it. This would have been fine, were it not that I then attempted to mount this logical volume in the host, rather than the guest. The problem, as I later discovered, was that I’d created a volume group in the host, with the same name as a volume group in the guest. Again, this would have been fine on its own, but the chain of errors was complete when I made the following next moves:
- Shared the physical disk with the virtual machine
- Activated the LVM volume group on the physical disk inside the virtual machine’s operating system (debian)
To its credit, LVM seemed to handle this quite well, and (if memory serves) merged my new logical volumes into one great volume group.
Identity crisis
Switching between different “hosts” (physical host and virtual guest) to edit logical volumes is not very clever, though. The reason is that lvm, within an operating system with drives available at certain locations, will update those drives’ metadata where each drive is a physical disk that is assigned to a volume group.
Let me put this another way: if you have /dev/sda1, /dev/sdb1 and /dev/sdc1 all as PVs (physical volumes) that belong to a VG (volume group), then making a change to the volume group – e.g. something simple like vgrename – will affect those three physical volume’s metadata.
Now, once you have finished doing this in the physical host and start playing around with the VG in your guest’s operating system, things aren’t going to look quite right. If you exported /dev/sdc1 from the host to the guest, the guest might:
- recognise the device at another location, such as /dev/sdb1
- look at it with lvm and wonder where /dev/sda1 and /dev/sdc1 are…
- let you edit this physical volume’s metadata (using LVM tools) in such a way that you cause further problems for yourself back in the physical host, if you planed to share it back there again.
The golden rules for an easy life, so far, are:
- Don’t share volume groups and logical volumes between hypervisors and guests.
- You can share a physical disk to a guest, but if you intend to use a logical volume on it within the guest, create it within the guest. And use it only within the guest.
- If you must manage and share logical volumes from the host to the guest, use NFS.
If you have already created a nightmare of “unknown” disks and missing PVs…
It’s not too difficult to remedy a tricky situation with messed up volume groups. If you are absolutely, positively, 100% certain that you no longer require the missing physical volumes in your VG, then there are actually only three (or four) commands you need:
# lvm vgreduce --removemissing -f <volume group name>
This attempts to remove the missing PVs from your VG and writes an up-to-date config file in /etc/lvm/backup/. If you inspect that file you’ll see a physical_volumes { } stanza which encompasses the physical volumes now remaining in your VG.
However, pay close attention to the status attribute of each PV. You may also see the remaining entry has:
status = ["MISSING"]
If you then attempt a
# vgchange -ay <volume group name>
you may find that the VG will not become active and this file again contains several entries, related to the missing PVs that you thought you’d just removed. The reason for this is that the remaining PV(s) have old meta-data which hasn’t been updated by LVM when you did that lvm vgreduce, earlier. Fear not.
Issue:
# lvm vgextend --restoremissing <volume group name> /path/to/PV
e.g. /path/to/PV might be /dev/sdb1 – you’ll need to know this, no guesses 🙂
After this, inspect the backup config file that you looked at previously. The status should have changed from “missing” to “allocatable”. However, the missing PVs will still be present, so let’s get rid of them:
# lvm vgreduce --removemissing -f <volume group name>
Now take one more look at that config file. It should just contain the PVs that are present and assigned to your VG.
Try activating the VG:
# vgchange -ay <volume group name>
1 logical volume(s) in volume group "<volume group name>" now active
If you’ve got this far, you’re basically on the home straight. Simply mount the LV on the file system and away you go!
Evolution Tasks in Hamster not appearing

Using Debian Wheezy, I found that trying to use Evolution as my task source for hamster-applet was not working.
I enabled Evolution as my source for tasks in Hamster. When executing hamster-time-tracker from the CLI, an error would appear in my terminal:
** (Time Tracker:14088): WARNING **: Failed to open calendar (type 1): Authentication required
I first thought that the problem was with hamster, that it was an outdated version. So I downloaded the source from github, re-built it and installed it on my system (after removing the old hamster). This didn’t help. But, as I had the source handy, I thought I’d take a look.
In the hamster-master/src/hamster directory is a file called external.py and, in that, this:
try:
import evolution
from evolution import ecal
except:
evolution = None
So, I know I have found the right area to start investigating this issue further.
For python applications to interface to Evolution, which is written in C, some interfacing software is required. This is installed generally in the form of the package “python-evolution” (http://packages.debian.org/wheezy/python-evolution). As shown at the top of that page, the source for this binary package is gnome-python-desktop (http://packages.debian.org/source/wheezy/gnome-python-desktop).
The next step was to search for the source package responsible for interfacing to Evolution’s calendar. I soon found this. From the Packages Debian page (packages.debian.org) you would click the Developer Information (PTS) link (http://packages.qa.debian.org/gnome-python-desktop). Once there, on the right hand side, click browse source code (http://sources.debian.net/src/gnome-python-desktop/2.32.0%2Bdfsg-3). You end up at a page listing folders containing source files. Simply click into evolution and then click on evo-calendar.c (http://sources.debian.net/src/gnome-python-desktop/2.32.0%2Bdfsg-3/evolution/evo-calendar.c).
I don’t profess to know programming in C, or even how to read much of it really, but you learn by doing – so let’s give it a go. Around lines 24-34, we see the declaration of what I believe is a structure:
#include “evo-calendar.h”
ECal *
evo_cal_source_open_source(const char *uri, ECalSourceType type)
{
ESourceList *sources = NULL;
ESource *source = NULL;
ECal *cal = NULL;
GError *gerror = NULL;
g_debug(“Opening calendar source uri: %s\n”, uri);
This looks like what we need – some code that is trying to open the calendar. It’s also including the header file, evo-calendar.h, which we may need to look at in a sec. So, the main purpose of this code is to open a calendar:
if (strcmp(uri, “default”)) {
if (!e_cal_get_sources(&sources, type, &gerror)) {
g_warning(“Unable to get sources for calendar (type %u): %s”,
type, gerror && gerror->message ? gerror->message : “None”);
g_clear_error(&gerror);
return NULL;
}
source = evo_environment_find_source(sources, uri);
if (!source) {
g_warning(“Unable to find source for calendar (type %u)”, type);
return NULL;
}
cal = e_cal_new(source, type);
if(!cal) {
g_warning(“Failed to create new calendar (type %u)”, type);
return NULL;
}
if(!e_cal_open(cal, FALSE, &gerror)) {
g_warning(“Failed to open calendar (type %u): %s”,
type, gerror && gerror->message? gerror->message : “None”);
g_object_unref(cal);
g_clear_error(&gerror);
return NULL;
}
} else {
if (!e_cal_open_default (&cal, type, NULL, NULL, &gerror)) {
g_warning(“Failed to open default calendar: %s”,
gerror && gerror->message ? gerror->message : “None”);
g_clear_error(&gerror);
return NULL;
}
}
return cal;
If you read closely, you’ll see that we have an IF statement, followed immediately by another IF statement:
if (strcmp(uri, “default”)) {
if (!e_cal_get_sources(&sources, type, &gerror)) {
g_warning(“Unable to get sources for calendar (type %u): %s”,
strcmp may be a string-compare function. Regardless, because of our error message in the terminal, cited previously, it’s fair to say that this strcmp is returning a TRUE. In other words, a basic test is conducted based on the URI that is being passed in to this function, and an error is being returned.
The error returned, “Failed to open calendar”, is a string within the C source code in this same file, at around line 57:
if(!e_cal_open(cal, FALSE, &gerror)) {
g_warning(“Failed to open calendar (type %u): %s”,
type, gerror && gerror->message? gerror->message : “None”);
g_object_unref(cal);
g_clear_error(&gerror);
return NULL;
}
This is the error message we are seeing! The (type %u) bit after the message is probably the return code (a general rule is that if the return code is 0, everything is ok, and any valyue other than 0 means there’s a problem) and the : %s bit is the string returned from the function trying to open the calendar, giving a reason why.
So, to reiterate our error message:
** (Time Tracker:14088): WARNING **: Failed to open calendar (type 1): Authentication required
The function e_cal_open() is returning this error code. To understand this function more, and what’s happening in this code, we need to look at the source for this function and also understand what data we’re passing to it.
Firstly, our call to the function is this:
e_cal_open(cal, FALSE, &gerror)
We can come back to what we’re passing to this function in a moment. Firstly, though, where is the e_cal_open function? We need to find out how it works!
Remember earlier that our file evo-calendar.c has an “include” pointing to the file evo-calendar.h? Well, that means “grab the file evo-calendar.h and make its resources available to me”. Within evo-calendar.h, there is no e_cal_open() function, but there are other includes, including one pointing to libecal/e-cal.h.
On debian, lib-ecal is another package installed along with Evolution. So, finding the file e-cal.h is as simple as using find or locate. On my system, the complete path to the file is /usr/include/evolution-data-server-3.4/libecal/e-cal.h. Hurrah – let’s go searching that C for e_cal_open:
$ grep -i e_cal_open /usr/include/evolution-data-server-3.4/libecal/e-cal.h
gboolean e_cal_open (ECal *ecal, gboolean only_if_exists, GError **error);
void e_cal_open_async (ECal *ecal, gboolean only_if_exists);
gboolean e_cal_open_default (ECal **ecal, ECalSourceType type, ECalAuthFunc func, gpointer data, GError **error);
The first one is the one we’re interested in at present: e_cal_open.
[ Sorry. This is an incomplete post, published for completeness instead of binned.]
Brasilian – a Saturday favourite

I’m consciously reworking my way through Taylors’ range of filter coffee. Many times before we’ve had the Italian style medium roast and, in addition, we’ve also gone for the number 6 strength “Hot Lava Java”. But sometimes you need a milder option, to more gently ease you into into a state of caffienated bliss.
Score out of 5 … 3. It’s a mellow cup, but perhaps missing some depth to the flavour. Not disagreeable at all though. Would still recommend.
I’m consciously reworking my way through Taylors’ range of filter coffee. Many times before we’ve had the Italian style medium roast and, in addition, we’ve also gone for the number 6 strength “Hot Lava Java”. But sometimes you need a milder option, to…
I’m consciously reworking my way through Taylors’ range of filter coffee. Many times before we’ve had the Italian style medium roast and, in addition, we’ve also gone for the number 6 strength “Hot Lava Java”. But sometimes you need a milder option, to…
http://stevedowe.me/2015/08/brasilian-a-saturday-favourite.html
“Hello trademark litigation from LG”?
"Hello trademark litigation from LG"?