My garden has been invaded by a fox.
Well, not quite - I just happened to look out my back window this morning, and saw this really odd orange-brown lump curled up on my lawn. I thought it was a dog at first, but then it looked up at me, and hey presto, it was the local fox.
He graciously consented to let me take a few photos of him (her?), and then left me with a parting tail.
Nifty.
$work had me tied at home today - some cables were being moved around, so I had to disable check-ins for all of the distributed nodes to avoid data loss. As a result, I got slightly active on the list of outstanding home improvement jobs, and tackled one of them.
Before I took a jigsaw to some wood:
After:
Before I took it to even more wood:
After:
The work isn’t finished, as those boards are only held together with friction. Tomorrow’s work will include making blocks to tie the pieces together with, and anchoring the wood to the floor and wall in a manner that makes it easy to lift the ‘lid’ of the boxing to work on the piping. I’ll also be hitting up a lumberyard on Monday with the aim of getting a plank that’s 22mm x 250mm to finish the boxing in front of the sink, and behind the toilet. It’ll then need some paint - either varnish or gloss white, I’m undecided.
In version 3.0002_4 of the DBD::mysql module, support for version 4.1 of MySQL has been broken. Probably not intentionally, but definitely broken. See, in version 5 of MySQL, the MySQL folks added a new type - ‘bit’. 3.0002_4 accounts for this, but doesn’t account for it cleanly - if you don’t have version 5 of MySQL installed, the install breaks with wonderful errors that look like:
dbdimp.c: In function `mysql_to_perl_type':
dbdimp.c:249: error: `MYSQL_TYPE_BIT' undeclared (first use in this function)
dbdimp.c:249: error: (Each undeclared identifier is reported only once
dbdimp.c:249: error: for each function it appears in.)
dbdimp.c:259: error: `MYSQL_TYPE_VARCHAR' undeclared (first use in this function)
dbdimp.c:263:25: warning: extra tokens at end of #ifdef directive
Downgrading to 3.0002 sorts it all out, and in fairness, after checking CPAN I found that _4 is flagged as ‘developer edition’ - in other words, it will break. Hit cpan2rpm over the head and life is good. In other news, that type_bit error actually only had 1 hit on Google. Amazing.
Today, while trying to get Mail::SPF::Query to build cleanly, I ran into a wonderful error that caused the test harness to bomb out. Google got me nowhere, the phrasing (This account is currently not available) was way too generic to get any useful hits on.
The build environment is a CentOS 4.2 installation, updated via yum. Nothing special. The only caveat is that I was doing the build of Mail::SPF::Query via rpmbuild as root. Yes, I know, bad move - but it did show up an interesting glitch:
# make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e” “test_harness(0, ‘blib/lib’, ‘blib/arch’)” t/*.t
t/00_all….NOK 9# Test 9 got: “This account is currently not available.: 192.0.2.1 is neither permitted nor denied by domain of 06.spf1-test.mailzone.com” (t/00_all.t at line 109 fail #8)
# Expected: “192.0.2.1 is neither permitted nor denied by domain of 06.spf1-test.mailzone.com”
The ‘account is currently not available’ message is the one that’s too generic, and it throws the test right off. The result did contain the correct string that the test wanted, but the test is a hard match, not a soft match. The source code for the SPF module didn’t have the ‘not available’ message, nor did the DNS query results (tethereal capture to make sure). This meant it had to be coming from deeper down the stack of modules - the only question was where?
The source code for Query.pm states on line 1082:
$newval = $query->{myhostname} if (lc $field eq 'r');
So now I knew it was myhostname that was messing up.
Grep resulted in:
284: $query->{myhostname} = Sys::Hostname::Long::hostname_long();
So, off to Sys::Hostname::Long to see how it gets the hostname. A quick debug flag later, and I had
Sys::Hostname::Long - Last Dispatch method = exec_hostname_fqdn
Ah hah. Checking that routine:
if ($< == 0) {
$tmp = `su nobody -c "hostname --fqdn"`;
} else {
$tmp = `hostname --fqdn`;
}
And therein lies the source of the error message. The ‘nobody’ account is disabled by default in CentOS 4.2, and my building the SPF module as root triggered the logic. Solution? Fix my build environment to build as a non-root user.
Much like the other weekend when I travelled to Wales to catch the sun, I travelled to the Peak District this weekend. One car, one camera, one map, one laptop and a tube of Pringles were my supplies for the trip - hopefully all of them would work. I opted to shoot in RAW format this time around, in the hope that I could do more with the photos if there were problems with exposure etc.
I had been assured by my weather forecast relaying entity that there would be sun in the area by 11 A.M at the latest, so I set off around 8:30 up the A34 to Congleton, aiming to catch the A54 across to Buxton, and then work my way south to the A52 to get home. It wasn’t exactly the brightest of mornings, instead the grey clouds were low in the sky, dimming any available light and generally making photography a pain.
My gallery is powered by an application called, oddly enough, Gallery 1.5. One of the nifty features of Gallery is that it can read the metadata from JPEG images - clicking on Photo Properties causes a window to display, and if EXIF data is present, it gets displayed in a nice table format. One of the downsides to this feature is it only works if you have JPEG images - the code that Gallery uses to determine whether or not the image supports EXIF looks like:
if(eregi('jpe?g$', $file)) {
return true;
} else {
return false;
}
Brilliant.
A quick trip with Google got me to the home of ExifTool - a Perl application that can dig EXIF/IPTC/XMP data out of pretty much any image format, and write it back if you so desire. So, onwards and upwards, time to make Gallery understand what exiftool is!
Well, it appears that Konica Minolta (the manufacturers of my Dynax 5D) have decided to pull out of the camera business. This would explain (perhaps) why they were giving away the DImage Master software for the price of a first-class stamp. I’m not all that enamoured with Sony equipment - it always seems to be overpriced, with more attention paid to form than function. Time will tell whether or not they’ll actually keep up their end of the contract and actually make cameras and lenses for the KM mount, or whether they’ll just gut the intellectual property from the transfer and cite ‘profit concerns’ or similar as the reason for discontinuing manufacture and perhaps even support.
Am I fear-mongering? Possibly. I’m a bit worried, because I’ve got a shiny new camera, and within 30 days of owning it, the manufacturer has dropped out of the race. The only possible benefit at this point is glass for the mount type used by the 5D gets dirt cheap.. I can hope, can’t I?
