most efficient way to map perl RH rpms to OE package names?

most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

  i've just been handed a list of about 200 perl packages by their
centos rpm names, and i want to map most, if not all, of them to their
equivalent OE package names.

 my first instinct (based on not having used a lot of perl OE
packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
just to fetch and build every possible module available through the OE
perl recipe -- that will at least give me an idea of what's available.

  next, i can see the pattern in some OE package names -- i've
verified that the Time::HiRes package is available in OE as
perl-module-time-hires, which i assume is part of the dynamic naming
being done in perl_5.22.1.bb.

 am i approaching this the right way?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

>   i've just been handed a list of about 200 perl packages by their
> centos rpm names, and i want to map most, if not all, of them to their
> equivalent OE package names.
>
>  my first instinct (based on not having used a lot of perl OE
> packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> just to fetch and build every possible module available through the OE
> perl recipe -- that will at least give me an idea of what's available.
>
>   next, i can see the pattern in some OE package names -- i've
> verified that the Time::HiRes package is available in OE as
> perl-module-time-hires, which i assume is part of the dynamic naming
> being done in perl_5.22.1.bb.
>
>  am i approaching this the right way?
>

Could also bitbake perl, then use oe-pkgdata-util to locate the actual perl
modules in the packages, i.e. */Time/HiRes.pm.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1679 bytes --]

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

On Mon, 24 Oct 2016, Christopher Larson wrote:

>
> On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>         i've just been handed a list of about 200 perl packages by their
>       centos rpm names, and i want to map most, if not all, of them to their
>       equivalent OE package names.
>
>        my first instinct (based on not having used a lot of perl OE
>       packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
>       just to fetch and build every possible module available through the OE
>       perl recipe -- that will at least give me an idea of what's available.
>
>         next, i can see the pattern in some OE package names -- i've
>       verified that the Time::HiRes package is available in OE as
>       perl-module-time-hires, which i assume is part of the dynamic naming
>       being done in perl_5.22.1.bb.
>
>        am i approaching this the right way?
>
> Could also bitbake perl, then use oe-pkgdata-util to locate the
> actual perl modules in the packages, i.e. */Time/HiRes.pm.

  i had just started playing with oe-pkgdata-util, it obviously has a
lot of equivalent functionality to your "bb", does it obsolete "bb" at
this point?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Mon, 24 Oct 2016, Christopher Larson wrote:

>
> On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>         i've just been handed a list of about 200 perl packages by their
>       centos rpm names, and i want to map most, if not all, of them to their
>       equivalent OE package names.
>
>        my first instinct (based on not having used a lot of perl OE
>       packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
>       just to fetch and build every possible module available through the OE
>       perl recipe -- that will at least give me an idea of what's available.
>
>         next, i can see the pattern in some OE package names -- i've
>       verified that the Time::HiRes package is available in OE as
>       perl-module-time-hires, which i assume is part of the dynamic naming
>       being done in perl_5.22.1.bb.
>
>        am i approaching this the right way?
>
>
> Could also bitbake perl, then use oe-pkgdata-util to locate the
> actual perl modules in the packages, i.e. */Time/HiRes.pm.

  i once wrote a wiki page on "bb", distinguishing between queries
you could make before you did a build, versus queries that needed a
build. it seems like oe-pkgdata-util needs a completed build for
pretty much everything, do i have that right?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

On Tue, 25 Oct 2016, Robert P. J. Day wrote:

> On Mon, 24 Oct 2016, Christopher Larson wrote:
>
> >
> > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >         i've just been handed a list of about 200 perl packages by their
> >       centos rpm names, and i want to map most, if not all, of them to their
> >       equivalent OE package names.
> >
> >        my first instinct (based on not having used a lot of perl OE
> >       packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> >       just to fetch and build every possible module available through the OE
> >       perl recipe -- that will at least give me an idea of what's available.
> >
> >         next, i can see the pattern in some OE package names -- i've
> >       verified that the Time::HiRes package is available in OE as
> >       perl-module-time-hires, which i assume is part of the dynamic naming
> >       being done in perl_5.22.1.bb.
> >
> >        am i approaching this the right way?
> >
> >
> > Could also bitbake perl, then use oe-pkgdata-util to locate the
> > actual perl modules in the packages, i.e. */Time/HiRes.pm.
>
>   i once wrote a wiki page on "bb", distinguishing between queries
> you could make before you did a build, versus queries that needed a
> build. it seems like oe-pkgdata-util needs a completed build for
> pretty much everything, do i have that right?

  never mind, i just read this snippet from the YP ref manual:

"You can use the oe-pkgdata-util command-line utility to query
PKGDATA_DIR and display various package-related information. When you
use the utility, you must use it to view information on packages that
have already been built."

so i'm assuming that means for *all* oe-pkgdata subcommands, no
exceptions.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

  following up on my original query, i'm now in the process of
"mapping" a couple hundred CentOS perl rpms to their OE equivalents,
and here's the process so far; just want to check that i'm going about
this in a sane way.

  first, as chris larson suggested, use "oe-pkgdata-util" to see which
generated perl modules appear to match up to equivalent rpms, and
quite a number of them seem to be direct equivalents, such as:

 * perl-HTTP-Tiny-0.033-3.el7.noarch
 * perl-module-http-tiny

so examples like that appear pretty straightforward.

  next, i noticed that there are a few perl recipes under OE,
recipes-devtools and recipes-extended, a couple *apparent*
equivalents:

 * perl-XML-LibXML-2.0018-5.el7.x86_64
 * libxml-perl_0.08.bb

 * perl-XML-NamespaceSupport-1.11-10.el7.noarch
 * libxml-namespacesupport-perl_1.11.bb

and so on. not so many of those but still, that took care of a few
more matches.

  finally, i figure i'm going to have to dive into meta-cpan for the
rest, and here's something puzzling.

  one of the RH rpms to be matched was
perl-IO-Compress-2.061-2.el7.noarch, but the generated modules were:

  perl-module-io-compress-deflate
  perl-module-io-compress-adapter-bzip2
  perl-module-io-compress-zlib-extra
  perl-module-io-compress-zip-constants
  perl-module-io-compress-bzip2
  perl-module-io-compress-adapter-identity
  perl-module-io-compress-zlib-constants
  perl-module-io-compress-base-common
  perl-module-io-compress-adapter-deflate
  perl-module-io-compress-gzip
  perl-module-io-compress-zip
  perl-module-io-compress-gzip-constants
  perl-module-io-compress-base
  perl-module-io-compress-rawdeflate

but no "perl-module-io-compress", which is what i would have expected.

  however, if i pop over to meta-cpan, there *is* a recipe file
"io-compress-perl_2.069.bb". can anyone explain how i should interpret
this?

  it seems (and i am not a perl expert) that the foundation
IO::Compress recipe is at meta-cpan, but the more specific sub-modules
are built from the base OE perl recipe. or is it that these modules:

  perl-module-io-compress-base-common
  perl-module-io-compress-base

represent the base class? i'm just trying to figure out the standard
OE packaging for perl modules.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

  one more question on this topic before i dive back in ... it seems
that some perl modules are available as both a perl recipe-generated
module, and from meta-cpan.

  generated module:
	perl-module-compress-raw-bzip2
  meta-cpan recipe:
	compress-raw-bzip2-perl_2.069.bb

am i reading correctly that those should represent the same thing, and
that (theoretically) i could include either equivalently?

  ok, back to work ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> On Tue, 25 Oct 2016, Robert P. J. Day wrote:
>
> > On Mon, 24 Oct 2016, Christopher Larson wrote:
> >
> > >
> > > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <
> rpjday@crashcourse.ca> wrote:
> > >         i've just been handed a list of about 200 perl packages by
> their
> > >       centos rpm names, and i want to map most, if not all, of them to
> their
> > >       equivalent OE package names.
> > >
> > >        my first instinct (based on not having used a lot of perl OE
> > >       packages) is to add both "perl" and "perl-modules" to
> IMAGE_INSTALL,
> > >       just to fetch and build every possible module available through
> the OE
> > >       perl recipe -- that will at least give me an idea of what's
> available.
> > >
> > >         next, i can see the pattern in some OE package names -- i've
> > >       verified that the Time::HiRes package is available in OE as
> > >       perl-module-time-hires, which i assume is part of the dynamic
> naming
> > >       being done in perl_5.22.1.bb.
> > >
> > >        am i approaching this the right way?
> > >
> > >
> > > Could also bitbake perl, then use oe-pkgdata-util to locate the
> > > actual perl modules in the packages, i.e. */Time/HiRes.pm.
> >
> >   i once wrote a wiki page on "bb", distinguishing between queries
> > you could make before you did a build, versus queries that needed a
> > build. it seems like oe-pkgdata-util needs a completed build for
> > pretty much everything, do i have that right?
>
>   never mind, i just read this snippet from the YP ref manual:
>
> "You can use the oe-pkgdata-util command-line utility to query
> PKGDATA_DIR and display various package-related information. When you
> use the utility, you must use it to view information on packages that
> have already been built."
>
> so i'm assuming that means for *all* oe-pkgdata subcommands, no
> exceptions.


Right, oe-pkgdata-util is about inspecting build output via pkgdata,
whereas most of bb is inspection tools about the metadata — before the
build. The only exception is bb-contents, which is a convenience, just
wraps oe-pkgdata-util under the hood and tells the user the oe-pkgdata-util
command in case they want to run it directly.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 3334 bytes --]

Re: most efficient way to map perl RH rpms to OE package names?

[Tim Orling]

[-- Attachment #1: Type: text/plain, Size: 3807 bytes --]

Robert,

You did not mention meta-perl:
http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl

The perl modules in meta-perl follow Debian naming:
https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html
https://anonscm.debian.org/cgit/?q=perl

When Jens developed meta-cpan, he was trying to improve the packaging of
perl modules, but did not necessarily follow the "established guidelines"
for OE perl module naming (which was the meta-perl layer at the time). What
he did provide is a method to use the CPAN metadata to create OE perl
modules.

The perl packaging in OE-Core follows yet another pattern. I assume it grew
out of a need to not package all the modules in a monolithic "perl-modules"
package (like Debian does) for our embedded-specific usage.

Not an ideal situation, but we have similar issues with python modules.

Cheers.

--Tim

On Tue, Oct 25, 2016 at 8:07 AM, Christopher Larson <clarson@kergoth.com>
wrote:

>
> On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca>
> wrote:
>
>> On Tue, 25 Oct 2016, Robert P. J. Day wrote:
>>
>> > On Mon, 24 Oct 2016, Christopher Larson wrote:
>> >
>> > >
>> > > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <
>> rpjday@crashcourse.ca> wrote:
>> > >         i've just been handed a list of about 200 perl packages by
>> their
>> > >       centos rpm names, and i want to map most, if not all, of them
>> to their
>> > >       equivalent OE package names.
>> > >
>> > >        my first instinct (based on not having used a lot of perl OE
>> > >       packages) is to add both "perl" and "perl-modules" to
>> IMAGE_INSTALL,
>> > >       just to fetch and build every possible module available through
>> the OE
>> > >       perl recipe -- that will at least give me an idea of what's
>> available.
>> > >
>> > >         next, i can see the pattern in some OE package names -- i've
>> > >       verified that the Time::HiRes package is available in OE as
>> > >       perl-module-time-hires, which i assume is part of the dynamic
>> naming
>> > >       being done in perl_5.22.1.bb.
>> > >
>> > >        am i approaching this the right way?
>> > >
>> > >
>> > > Could also bitbake perl, then use oe-pkgdata-util to locate the
>> > > actual perl modules in the packages, i.e. */Time/HiRes.pm.
>> >
>> >   i once wrote a wiki page on "bb", distinguishing between queries
>> > you could make before you did a build, versus queries that needed a
>> > build. it seems like oe-pkgdata-util needs a completed build for
>> > pretty much everything, do i have that right?
>>
>>   never mind, i just read this snippet from the YP ref manual:
>>
>> "You can use the oe-pkgdata-util command-line utility to query
>> PKGDATA_DIR and display various package-related information. When you
>> use the utility, you must use it to view information on packages that
>> have already been built."
>>
>> so i'm assuming that means for *all* oe-pkgdata subcommands, no
>> exceptions.
>
>
> Right, oe-pkgdata-util is about inspecting build output via pkgdata,
> whereas most of bb is inspection tools about the metadata — before the
> build. The only exception is bb-contents, which is a convenience, just
> wraps oe-pkgdata-util under the hood and tells the user the oe-pkgdata-util
> command in case they want to run it directly.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 5555 bytes --]

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

  ok, one more question about all this "mapping RH/CentOS rpms to Perl
modules" nonsense i'm buried in, with the hope i can resolve this once
and for all and finish this off, and then i can shut up about this.

  in brief, a current build system creates an X86-target bootable
linux system by installing (among other things) a couple hundred
CentOS Perl module RPMs. rather than list them all here, i took a few
minutes and put them all up on a wiki page yesterday:

  http://www.crashcourse.ca/wiki/index.php/RPM_OE

to keep track of progress. as you can see, all those RPMs (being
mostly perl modules) are either x86_64 or noarch rpms, no surprise
there. obviously, to convert this build system to OE/YP, i need to
determine the OE recipe/package equivalent of all those rpms. i
originally thought that wouldn't be so hard ... silly me.

  as i started poking around, i noted (as you can read in the Overview
i wrote on that wiki page) that some of those modules could be found
in a number of places:

  * part of the "perl-modules" definition when building perl itself
  * from the OE layer
  * from the meta-openembedded/meta-perl layer
  * from the meta-cpan layer

(side note: the new target system is not x86, it's powerpc, which
explains the necessity of replacing the current build system, which is
x86 only and therefore unusable.)

  to start things off and to see how much of all that i could get into
the target image during a first pass, i did the obvious:

  * selected "qemuppc" as the target MACHINE
  * added "perl-modules" to IMAGE_INSTALL to add *all* generated
    perl modules to the image
  * IMAGE_FEATURES += "package-management", to get "rpm" on the
    target to examine the installed rpms
  * built a "core-image-minimal"

all that worked fine, i fired up the resulting qemuppc image and
verified that it did indeed have all 639 "perl-module-*ppc7400.rpm"
generated packages. overkill, yes, but i don't care at the moment.

  and this is where the fun starts as i now need to figure out where
to get the rest. i spent a few minutes just searching the layers i
mentioned above but, surely, there's an easier way. one of the
absolutely crucial modules that needs to be on the target is
Text::Template, but i see no existing recipe for that.

  more to the point, i would have thought that OE would have a
mechanism to build such modules dynamically -- i thought that was the
whole purpose of the "meta-cpan" layer. i was reading this linkedin
page:

https://www.linkedin.com/pulse/how-we-brought-cpan-embedded-devices-jens-rehsack?articleId=8774955546707699773

which refers to "automating basic package maintenance", so i assumed
there was some automatic way of doing this. am i misreading that?

  in any event, what is the *proper* way to do this? surely it doesn't
involve manually hunting down each recipe file one by one. in
addition, even when i find a recipe file, it sometimes doesn't have
related recipe files in the same place.

  case in point -- we need these two modules:

 * perl-Authen-PAM-0.16-16.el7.x86_64
 * perl-Authen-SASL-2.15-10.el7.noarch

however, the meta-perl layer contains the second, but not the first,
so it's not clear to me what criteria is used to include perl module
recipes in any given layer.

  thoughts? as a single example, how would one include the
Text::Template module in a target image? any assistance gratefully
received.

rday

p.s. i typically don't work with perl modules, so if i sound clueless
about perl packaging, that's because i am.

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

On Tue, 25 Oct 2016, Christopher Larson wrote:

> On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Tue, 25 Oct 2016, Robert P. J. Day wrote:
>
>       >   i once wrote a wiki page on "bb", distinguishing between queries
>       > you could make before you did a build, versus queries that
>       > needed a build. it seems like oe-pkgdata-util needs a
>       > completed build for pretty much everything, do i have that
>       > right?
>
>         never mind, i just read this snippet from the YP ref manual:
>
>       "You can use the oe-pkgdata-util command-line utility to query
>       PKGDATA_DIR and display various package-related information.
>       When you use the utility, you must use it to view information
>       on packages that have already been built."
>
>       so i'm assuming that means for *all* oe-pkgdata subcommands, no
>       exceptions.
>
> Right, oe-pkgdata-util is about inspecting build output via pkgdata,
> whereas most of bb is inspection tools about the metadata — before
> the build. The only exception is bb-contents, which is a
> convenience, just wraps oe-pkgdata-util under the hood and tells the
> user the oe-pkgdata-util command in case they want to run it
> directly.

  ah, excellent, this is important for me since, when i teach OE/YP,
one of the first things i do is distinguish between a "build" and
"nobuild" project directory ("nobuild" meaning configured only), and
use "bb" to show how much one can query about the project before any
compilation is done. this is amazingly useful.

rday

p.s. if readers don't know about "bb", i wrote a page on it once upon
a time:

  http://www.crashcourse.ca/wiki/index.php/Bb

i better go back and make sure it's up to date.

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: most efficient way to map perl RH rpms to OE package names?

[Robert P. J. Day]

  never mind, i think i finally twigged to what i need ... i can see
in the include file "perl-rdepends_5.22.1.inc" how to define a
required module, such as the following "Text::*" modules:

RDEPENDS_${PN}-module-text-abbrev += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-carp"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-overload"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-selfloader"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-strict"
RDEPENDS_${PN}-module-text-balanced += "${PN}-module-vars"
RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-carp"
RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-strict"
RDEPENDS_${PN}-module-text-tabs += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-tabs += "${PN}-module-strict"
RDEPENDS_${PN}-module-text-tabs += "${PN}-module-vars"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-re"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-strict"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-text-tabs"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-vars"
RDEPENDS_${PN}-module-text-wrap += "${PN}-module-warnings-register"

so, AFAICT, i need define only the equivalent information for
additional modules i want, and explicitly add those to the list of
modules i want built.

  seems pretty straightforward, am i overlooking anything?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================