Here's two functions I came up with in the end. One to convert MailboxGUID to something that a search on msExchMailboxGuid will like:

sub exch_to_ad {
  my $guid = shift;
  $guid =~ s/[\{\}]+//g;
  my $string = '';
  my $count = 0;
  foreach my $part ( split /\-/, $guid ) {
    $count++;
    if ( $count >= 4 ) {
      $string .= "\\$_" for unpack "(A2)*", $part;
    }
    else {
      $string .= "\\$_" for reverse unpack "(A2)*", $part;
    }
  }
  return $string;
}

And another to take a msExchMailboxGuid field, which is a byte array, and convert it to a MailboxGUID.

sub ad_to_exch {
  my $guid = shift;
  my @vals = map { sprintf("%.2X", ord $_) } unpack "(a1)*", $guid;
  my $string = '{';
  $string .= join '', @vals[3,2,1,0], '-', @vals[5,4], '-', 
     @vals[7,6], '-', @vals[8,9], '-', @vals[10..$#vals], '}';
  return $string;
}

Hopefully this should save other people some time.

Big kudos to all concerned

When I met David Golden and Ricardo Signes at the Birmingham QA Hackathon in 2009 and discussions were happening about Metabase and how submissions would be made to it, I'd expressed concern about the weight of the dependencies that would be required to make Metabase submissions.

I came up with the idea of a Metabase relay server, something that would act as an intermediate between smokers and the Metabase. The smokers would use an very lightweight transport to submit reports to the relay, which would then forward the requests on to the Metabase server.

And that was as far as it went until the beta testing of Metabase started. I wrote Test::Reporter::Transport::Socket which would be installed on the smoker. This takes as options the address of a relay server and the TCP port to connect to. The data is passed using Storable's nfreeze function and unfrozen at the relay.

The relay server side is dealt with by a number of parts, POE::Component::Metabase::Client::Submit, POE::Component::Metabase::Relay::Server and the easy to use metabase-relayd.

The relay server has a SQLite database backend which stores reports to be submitted, if transmission fails it will requeue and try again until submission succeeds (this is in contrast to Test::Reporter::Transport::Metabase which does not have a resubmission mechanism)

So using it. On each of the smokers install Test::Reporter::Transport::Socket.

For CPAN::Reporter add following line to ~/.cpanreporter/config.ini

transport = Socket host my.relay.server port 8080

For CPANPLUS it is slightly harder, you will have to edit the CPANPLUS config file and find the setting for cpantest_reporter_args or you could run this script to set the appropriate values for you.

On what will be your relay server simply install App::Metabase::Relayd, which should pull in all the required dependencies.

metabase-relayd uses the directory ~/.metabase for finding its configuration file relayd and for storing the database file, etc.

Unless you are an existing CPAN Tester then run metabase-profile to generate yourself a profile id file and move the resultant file into ~/.metabase.

Create a relayd file in ~/.metabase

address=192.168.1.87,127.0.0.1
port=8080
idfile=/home/chris/.metabase/metabase_id.json
dbfile=/home/chris/.metabase/relay.db
url=https://metabase.cpantesters.org/beta/
debug=1
multiple=1

This is my relayd adjust to taste

Then simply start metabase-relayd

Wouldn't it be great if there was a tool to do this for me?

And so Dist::Zooky was born.

( Embarressingly I had to explain the reference to RJBS, who found this ).

Dist::Zooky generates a dist.ini for a distribution by examining the metadata produced by running Makefile.PL or Build.PL and then converting it to something that
Dist::Zilla will like.

For Build.PL and Module::Install based distributions it does this from the MYMETA.yml file that is produced by running the .PL file. For ExtUtils::MakeMaker based distributions it gathers the meta by parsing the Makefile that is generated. Ick.

Here's an example

$ cd Foo-Bar

$ ls -l

total 32

-r--r--r-- 1 chris users 20 Apr 1 2005 CHANGES

-rw-r--r-- 1 chris users 152 Apr 1 2005 MANIFEST

-rw-r--r-- 1 chris users 389 Jan 13 2008 META.yml

-r-xr-xr-x 1 chris users 297 Jun 24 14:41 Makefile.PL

-r--r--r-- 1 chris users 19 Apr 1 2005 README

drwxr-xr-x 2 chris users 512 Apr 1 2005 bin

drwxr-xr-x 3 chris users 512 Apr 1 2005 lib

-r--r--r-- 1 chris users 49 Apr 1 2005 test.pl

And Makefile.PL looks like this:

use ExtUtils::MakeMaker;

WriteMakefile(
NAME => 'Foo::Bar',
AUTHOR => 'Gobby Davro',
LICENSE => 'perl',
VERSION_FROM => 'lib/Foo/Bar.pm',
EXE_FILES => ['bin/foobar.pl'],
PREREQ_PM => { 'Some::Dependency' => '1.02' },
);

So we run dzooky the Dist::Zooky command-line tool:

$ dzooky Wrote 'dist.ini'

There are a number of files that should be removed now

Do you want me to remove [MANIFEST Makefile.PL] ? (yes/no) [no] yes
Removing files
Done.
$

And now we have a dist.ini file:

name = Foo-Bar version = 0.01 author = Gobby Davro license = Perl_5 copyright_holder = Gobby Davro

[GatherDir]
[PruneCruft]
[ManifestSkip]
[MetaYAML]
[MetaJSON]
[License]

;[Readme]

[ExecDir]

[ExtraTests]
[ShareDir]

[MakeMaker]

[Manifest]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]

;[Prereq / ConfigureRequires]
;[Prereq / BuildRequires]
[Prereq]
Some::Dependency = 1.02

Neat, huh.

And as usual I found some yaks to shave on my travels.

First off I had to port over Module::Install::GithubMeta to Dist::Zilla::Plugin::GithubMeta.

Flush with the success of this I decided to try converting some other of my Module::Install extensions, starting with Module::Install::AssertOS.

After much gnashing of teeth and hair-pulling I've eventually released Dist::Zilla::Plugin::AssertOS to CPAN.

Closely followed by Dist::Zilla::Plugin::NoAutomatedTesting.

Both these demonstrate a slightly dubious mechanism for manipulating the dzil generated Makefile.PL. You might want Dist::Zilla::Plugin::MakeMaker::Awesome instead.

Smokebrew is now available on CPAN and after some smoking of my own dog-food appears to work really really well.

The name was inspired by GUGOD's perlbrew, but Smokebrew itself does things differently to perlbrew.

It doesn't do the environment tweaking, for instance, to switch between the installed perls.

The goal has been to build, install and configure various versions of perl for CPAN Testing.

The configuration is dealt with by App::SmokeBrew::Plugin's. These are objects that are called by Smokebrew after it has successfully built and installed a particular version of perl. Smokebrew comes with two plugins, Null and CPANPLUS::YACSmoke. The former does no configuration and the latter configures for CPAN Testing with CPANPLUS::YACSmoke.

smokebrew --email tester@cpan.org --builddir /home/tester/build --prefix /home/tester/perls --perlargs "-Dusethreads" --perlargs "-Duse64bitint" --plugin Null --recent --verbose

The above would build "recent" perls which are stable perls from 5.8.9 into directories in /home/tester/perls that will have threads and 64bitinit and it will use the Null plugin to configure those perls, which effective does no configuration.

smokebrew --email tester@cpan.org --builddir /home/tester/build --prefix /home/tester/perls --perlargs "-Dusethreads" --perlargs "-Duse64bitint" --plugin CPANPLUS::YACSmoke --recent --verbose

This would do the same as above, but now each perl will configured using the CPANPLUS::YACSmoke plugin and they will be ready to start CPAN Testing, say using minismokebox.

PERL5_YACSMOKE_BASE=/home/tester/perls/conf/perl-5.8.9/ minismokebox --nolog --debug --indices --perl /home/tester/perls/perl-5.8.9/bin/perl