Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/08/trademark-aggression.html

I was disturbed to read that Canonical, Ltd.’s trademark aggression, which
I’ve been vaguely aware of for some time, has reached a new height. And, I
say this as someone who regularly encourages Free Software projects to
register trademarks, and to occasionally do trademark enforcement and also
to actively avoid project policies that might lead to
naked
licensing. Names matter, and Free Software projects should strive to
strike a careful balance between assuring that names mean what they are
supposed to mean, and also encourage software sharing and modification at
the same time.

However, Canonical, Ltd.’s behavior shows what happens when lawyers and
corporate marketing run amok and fail to strike that necessary balance.
Specifically, Canonical, Ltd. sent a
standard
cease and desist (C&D) letter to Micah F. Lee, for
running fixubuntu.com, a site that
clearly to any casual reader is not affiliated with
Canonical, Ltd. or its Ubuntu® project. In fact, the site is specifically telling you how
to undo some anti-privacy stuff that Canonical, Ltd. puts
into its Ubuntu, so there is no trademark-governed threat to its Ubuntu branding.
Lee fortunately got legal assistance from the EFF, who
wrote
a letter explaining why Canonical, Ltd. was completely wrong.

Anyway, this sort of bad behavior is so commonplace by Canonical,
Ltd. that I’d previously decided to stop talking about when it reached the
crescendo
of Mark
Shuttleworth calling me a McCarthyist because of my Free Software beliefs
and work. But, one comment on Micah’s blog inspired me to comment
here. Specifically, Jono Bacon, who leads Ubuntu’s PR division under the
dubious title of Community Manager,
asks
this insultingly naïve question as a comment on Micah’s blog: Did
you raise your concerns the team who sent the email?.

I am sure that Jono knows well what a C&D letter is and what one looks
like. I also am sure that he knows that any lawyer would advise Micah to
not engage with an adverse party on his own over an issue of
trademark dispute without adequate legal counsel. Thus, for Jono to
suggest that there is some Canonical, Ltd. “team” that Micah
should be talking to not only pathetically conflates Free Software
community operations with corporate legal aggression, but also seem like a
Canonical, Ltd. employee subtly suggesting that those who receive C&D’s
from Canonical, Ltd.’s legal departments should engage in discussion
without seeking their own legal counsel.

Free Software projects should get trademarks of their
own. Indeed, I fully support that and I encourage for folks interested in
this issue to listen to Pam
Chestek’s excellent talk on the topic at FOSDEM 2013 (which Karen Sandler
and I broadcast on Free as in Freedom). However, true Free
Software communities don’t try to squelch Free Speech that criticizes their
projects. It’s deplorable that Canonical, Ltd. has an organized campaign
between their lawyers and their public relations folks like Jono to (a)
send aggressive C&D letters to Free Software enthusiasts who criticize
Ubuntu and (b) follow up on those efforts by subtly shaming those who
lawyer-up upon receiving that C&D.

I should finally note that Canonical, Ltd. has an inappropriate and
Orwellian predilection for coopting words our community (including the word
“community” itself, BTW). Most people don’t know that I myself
registered the domain name canonical.org back on 1999-08-06 (when
Shuttleworth was still running Thawte) for a group of friends who liked to
use the word canonical in the canonical way, and still do so today.
However, thanks to Shuttleworth, it’s difficult
to use canonical
in the canonical way anymore in Free Software circles, because
Shuttleworth coopted the term and brand-markets on top of it. Ubuntu, for
its part, is a word
meaning human
kindness that Shuttleworth has also coopted for his often unkind
activities.

Update at 16:17 on
2013-11-08: Canonical, Ltd. has posted a response regarding their
enforcement action, which claims that their trademark policy
is unusually permissive. This is true if the universe is
“all trademark policies in the world”, but it is false if the
universe is “Open Source and Free Software trademark
policies”. Of course, like any good spin doctors, Canonical, Ltd. doesn’t
actually say this explicitly.

Similarly, Canonical, Ltd. restates the oft-over-simplified claim
that in trademark law a mark owner is expected to protect the authenticity
of a trademark otherwise they risk losing the mark. What they don’t tell
you is why they believe failure to enforce in this specific instance against
fixubuntu.com had specific risk. Why didn’t they tell us that?: because it
doesn’t. I suspect they could have simply asked for the disclaimer that
Micah gave them willingly, and that would have satisfied the aforementioned
risk adequately.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/08/trademark-aggression.html

I was disturbed to read that Canonical, Ltd.’s trademark aggression, which
I’ve been vaguely aware of for some time, has reached a new height. And, I
say this as someone who regularly encourages Free Software projects to
register trademarks, and to occasionally do trademark enforcement and also
to actively avoid project policies that might lead to
naked
licensing. Names matter, and Free Software projects should strive to
strike a careful balance between assuring that names mean what they are
supposed to mean, and also encourage software sharing and modification at
the same time.

However, Canonical, Ltd.’s behavior shows what happens when lawyers and
corporate marketing run amok and fail to strike that necessary balance.
Specifically, Canonical, Ltd. sent a
standard
cease and desist (C&D) letter to Micah F. Lee, for
running fixubuntu.com, a site that
clearly to any casual reader is not affiliated with
Canonical, Ltd. or its Ubuntu® project. In fact, the site is specifically telling you how
to undo some anti-privacy stuff that Canonical, Ltd. puts
into its Ubuntu, so there is no trademark-governed threat to its Ubuntu branding.
Lee fortunately got legal assistance from the EFF, who
wrote
a letter explaining why Canonical, Ltd. was completely wrong.

Anyway, this sort of bad behavior is so commonplace by Canonical,
Ltd. that I’d previously decided to stop talking about when it reached the
crescendo
of Mark
Shuttleworth calling me a McCarthyist because of my Free Software beliefs
and work. But, one comment on Micah’s blog inspired me to comment
here. Specifically, Jono Bacon, who leads Ubuntu’s PR division under the
dubious title of Community Manager,
asks
this insultingly naïve question as a comment on Micah’s blog: Did
you raise your concerns the team who sent the email?.

I am sure that Jono knows well what a C&D letter is and what one looks
like. I also am sure that he knows that any lawyer would advise Micah to
not engage with an adverse party on his own over an issue of
trademark dispute without adequate legal counsel. Thus, for Jono to
suggest that there is some Canonical, Ltd. “team” that Micah
should be talking to not only pathetically conflates Free Software
community operations with corporate legal aggression, but also seem like a
Canonical, Ltd. employee subtly suggesting that those who receive C&D’s
from Canonical, Ltd.’s legal departments should engage in discussion
without seeking their own legal counsel.

Free Software projects should get trademarks of their
own. Indeed, I fully support that and I encourage for folks interested in
this issue to listen to Pam
Chestek’s excellent talk on the topic at FOSDEM 2013 (which Karen Sandler
and I broadcast on Free as in Freedom). However, true Free
Software communities don’t try to squelch Free Speech that criticizes their
projects. It’s deplorable that Canonical, Ltd. has an organized campaign
between their lawyers and their public relations folks like Jono to (a)
send aggressive C&D letters to Free Software enthusiasts who criticize
Ubuntu and (b) follow up on those efforts by subtly shaming those who
lawyer-up upon receiving that C&D.

I should finally note that Canonical, Ltd. has an inappropriate and
Orwellian predilection for coopting words our community (including the word
“community” itself, BTW). Most people don’t know that I myself
registered the domain name canonical.org back on 1999-08-06 (when
Shuttleworth was still running Thawte) for a group of friends who liked to
use the word canonical in the canonical way, and still do so today.
However, thanks to Shuttleworth, it’s difficult
to use canonical
in the canonical way anymore in Free Software circles, because
Shuttleworth coopted the term and brand-markets on top of it. Ubuntu, for
its part, is a word
meaning human
kindness that Shuttleworth has also coopted for his often unkind
activities.

Update at 16:17 on
2013-11-08: Canonical, Ltd. has posted a response regarding their
enforcement action, which claims that their trademark policy
is unusually permissive. This is true if the universe is
“all trademark policies in the world”, but it is false if the
universe is “Open Source and Free Software trademark
policies”. Of course, like any good spin doctors, Canonical, Ltd. doesn’t
actually say this explicitly.

Similarly, Canonical, Ltd. restates the oft-over-simplified claim
that in trademark law a mark owner is expected to protect the authenticity
of a trademark otherwise they risk losing the mark. What they don’t tell
you is why they believe failure to enforce in this specific instance against
fixubuntu.com had specific risk. Why didn’t they tell us that?: because it
doesn’t. I suspect they could have simply asked for the disclaimer that
Micah gave them willingly, and that would have satisfied the aforementioned
risk adequately.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/08/trademark-aggression.html

I was disturbed to read that Canonical, Ltd.’s trademark aggression, which
I’ve been vaguely aware of for some time, has reached a new height. And, I
say this as someone who regularly encourages Free Software projects to
register trademarks, and to occasionally do trademark enforcement and also
to actively avoid project policies that might lead to
naked
licensing. Names matter, and Free Software projects should strive to
strike a careful balance between assuring that names mean what they are
supposed to mean, and also encourage software sharing and modification at
the same time.

However, Canonical, Ltd.’s behavior shows what happens when lawyers and
corporate marketing run amok and fail to strike that necessary balance.
Specifically, Canonical, Ltd. sent a
standard
cease and desist (C&D) letter to Micah F. Lee, for
running fixubuntu.com, a site that
clearly to any casual reader is not affiliated with
Canonical, Ltd. or its Ubuntu® project. In fact, the site is specifically telling you how
to undo some anti-privacy stuff that Canonical, Ltd. puts
into its Ubuntu, so there is no trademark-governed threat to its Ubuntu branding.
Lee fortunately got legal assistance from the EFF, who
wrote
a letter explaining why Canonical, Ltd. was completely wrong.

Anyway, this sort of bad behavior is so commonplace by Canonical,
Ltd. that I’d previously decided to stop talking about when it reached the
crescendo
of Mark
Shuttleworth calling me a McCarthyist because of my Free Software beliefs
and work. But, one comment on Micah’s blog inspired me to comment
here. Specifically, Jono Bacon, who leads Ubuntu’s PR division under the
dubious title of Community Manager,
asks
this insultingly naïve question as a comment on Micah’s blog: Did
you raise your concerns the team who sent the email?.

I am sure that Jono knows well what a C&D letter is and what one looks
like. I also am sure that he knows that any lawyer would advise Micah to
not engage with an adverse party on his own over an issue of
trademark dispute without adequate legal counsel. Thus, for Jono to
suggest that there is some Canonical, Ltd. “team” that Micah
should be talking to not only pathetically conflates Free Software
community operations with corporate legal aggression, but also seem like a
Canonical, Ltd. employee subtly suggesting that those who receive C&D’s
from Canonical, Ltd.’s legal departments should engage in discussion
without seeking their own legal counsel.

Free Software projects should get trademarks of their
own. Indeed, I fully support that and I encourage for folks interested in
this issue to listen to Pam
Chestek’s excellent talk on the topic at FOSDEM 2013 (which Karen Sandler
and I broadcast on Free as in Freedom). However, true Free
Software communities don’t try to squelch Free Speech that criticizes their
projects. It’s deplorable that Canonical, Ltd. has an organized campaign
between their lawyers and their public relations folks like Jono to (a)
send aggressive C&D letters to Free Software enthusiasts who criticize
Ubuntu and (b) follow up on those efforts by subtly shaming those who
lawyer-up upon receiving that C&D.

I should finally note that Canonical, Ltd. has an inappropriate and
Orwellian predilection for coopting words our community (including the word
“community” itself, BTW). Most people don’t know that I myself
registered the domain name canonical.org back on 1999-08-06 (when
Shuttleworth was still running Thawte) for a group of friends who liked to
use the word canonical in the canonical way, and still do so today.
However, thanks to Shuttleworth, it’s difficult
to use canonical
in the canonical way anymore in Free Software circles, because
Shuttleworth coopted the term and brand-markets on top of it. Ubuntu, for
its part, is a word
meaning human
kindness that Shuttleworth has also coopted for his often unkind
activities.

Update at 16:17 on
2013-11-08: Canonical, Ltd. has posted a response regarding their
enforcement action, which claims that their trademark policy
is unusually permissive. This is true if the universe is
“all trademark policies in the world”, but it is false if the
universe is “Open Source and Free Software trademark
policies”. Of course, like any good spin doctors, Canonical, Ltd. doesn’t
actually say this explicitly.

Similarly, Canonical, Ltd. restates the oft-over-simplified claim
that in trademark law a mark owner is expected to protect the authenticity
of a trademark otherwise they risk losing the mark. What they don’t tell
you is why they believe failure to enforce in this specific instance against
fixubuntu.com had specific risk. Why didn’t they tell us that?: because it
doesn’t. I suspect they could have simply asked for the disclaimer that
Micah gave them willingly, and that would have satisfied the aforementioned
risk adequately.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/08/trademark-aggression.html

I was disturbed to read that Canonical, Ltd.’s trademark aggression, which
I’ve been vaguely aware of for some time, has reached a new height. And, I
say this as someone who regularly encourages Free Software projects to
register trademarks, and to occasionally do trademark enforcement and also
to actively avoid project policies that might lead to
naked
licensing. Names matter, and Free Software projects should strive to
strike a careful balance between assuring that names mean what they are
supposed to mean, and also encourage software sharing and modification at
the same time.

However, Canonical, Ltd.’s behavior shows what happens when lawyers and
corporate marketing run amok and fail to strike that necessary balance.
Specifically, Canonical, Ltd. sent a
standard
cease and desist (C&D) letter to Micah F. Lee, for
running fixubuntu.com, a site that
clearly to any casual reader is not affiliated with
Canonical, Ltd. or its Ubuntu® project. In fact, the site is specifically telling you how
to undo some anti-privacy stuff that Canonical, Ltd. puts
into its Ubuntu, so there is no trademark-governed threat to its Ubuntu branding.
Lee fortunately got legal assistance from the EFF, who
wrote
a letter explaining why Canonical, Ltd. was completely wrong.

Anyway, this sort of bad behavior is so commonplace by Canonical,
Ltd. that I’d previously decided to stop talking about when it reached the
crescendo
of Mark
Shuttleworth calling me a McCarthyist because of my Free Software beliefs
and work. But, one comment on Micah’s blog inspired me to comment
here. Specifically, Jono Bacon, who leads Ubuntu’s PR division under the
dubious title of Community Manager,
asks
this insultingly naïve question as a comment on Micah’s blog: Did
you raise your concerns the team who sent the email?.

I am sure that Jono knows well what a C&D letter is and what one looks
like. I also am sure that he knows that any lawyer would advise Micah to
not engage with an adverse party on his own over an issue of
trademark dispute without adequate legal counsel. Thus, for Jono to
suggest that there is some Canonical, Ltd. “team” that Micah
should be talking to not only pathetically conflates Free Software
community operations with corporate legal aggression, but also seem like a
Canonical, Ltd. employee subtly suggesting that those who receive C&D’s
from Canonical, Ltd.’s legal departments should engage in discussion
without seeking their own legal counsel.

Free Software projects should get trademarks of their
own. Indeed, I fully support that and I encourage for folks interested in
this issue to listen to Pam
Chestek’s excellent talk on the topic at FOSDEM 2013 (which Karen Sandler
and I broadcast on Free as in Freedom). However, true Free
Software communities don’t try to squelch Free Speech that criticizes their
projects. It’s deplorable that Canonical, Ltd. has an organized campaign
between their lawyers and their public relations folks like Jono to (a)
send aggressive C&D letters to Free Software enthusiasts who criticize
Ubuntu and (b) follow up on those efforts by subtly shaming those who
lawyer-up upon receiving that C&D.

I should finally note that Canonical, Ltd. has an inappropriate and
Orwellian predilection for coopting words our community (including the word
“community” itself, BTW). Most people don’t know that I myself
registered the domain name canonical.org back on 1999-08-06 (when
Shuttleworth was still running Thawte) for a group of friends who liked to
use the word canonical in the canonical way, and still do so today.
However, thanks to Shuttleworth, it’s difficult
to use canonical
in the canonical way anymore in Free Software circles, because
Shuttleworth coopted the term and brand-markets on top of it. Ubuntu, for
its part, is a word
meaning human
kindness that Shuttleworth has also coopted for his often unkind
activities.

Update at 16:17 on
2013-11-08: Canonical, Ltd. has posted a response regarding their
enforcement action, which claims that their trademark policy
is unusually permissive. This is true if the universe is
“all trademark policies in the world”, but it is false if the
universe is “Open Source and Free Software trademark
policies”. Of course, like any good spin doctors, Canonical, Ltd. doesn’t
actually say this explicitly.

Similarly, Canonical, Ltd. restates the oft-over-simplified claim
that in trademark law a mark owner is expected to protect the authenticity
of a trademark otherwise they risk losing the mark. What they don’t tell
you is why they believe failure to enforce in this specific instance against
fixubuntu.com had specific risk. Why didn’t they tell us that?: because it
doesn’t. I suspect they could have simply asked for the disclaimer that
Micah gave them willingly, and that would have satisfied the aforementioned
risk adequately.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/08/trademark-aggression.html

I was disturbed to read that Canonical, Ltd.’s trademark aggression, which
I’ve been vaguely aware of for some time, has reached a new height. And, I
say this as someone who regularly encourages Free Software projects to
register trademarks, and to occasionally do trademark enforcement and also
to actively avoid project policies that might lead to
naked
licensing. Names matter, and Free Software projects should strive to
strike a careful balance between assuring that names mean what they are
supposed to mean, and also encourage software sharing and modification at
the same time.

However, Canonical, Ltd.’s behavior shows what happens when lawyers and
corporate marketing run amok and fail to strike that necessary balance.
Specifically, Canonical, Ltd. sent a
standard
cease and desist (C&D) letter to Micah F. Lee, for
running fixubuntu.com, a site that
clearly to any casual reader is not affiliated with
Canonical, Ltd. or its Ubuntu® project. In fact, the site is specifically telling you how
to undo some anti-privacy stuff that Canonical, Ltd. puts
into its Ubuntu, so there is no trademark-governed threat to its Ubuntu branding.
Lee fortunately got legal assistance from the EFF, who
wrote
a letter explaining why Canonical, Ltd. was completely wrong.

Anyway, this sort of bad behavior is so commonplace by Canonical,
Ltd. that I’d previously decided to stop talking about when it reached the
crescendo
of Mark
Shuttleworth calling me a McCarthyist because of my Free Software beliefs
and work. But, one comment on Micah’s blog inspired me to comment
here. Specifically, Jono Bacon, who leads Ubuntu’s PR division under the
dubious title of Community Manager,
asks
this insultingly naïve question as a comment on Micah’s blog: Did
you raise your concerns the team who sent the email?.

I am sure that Jono knows well what a C&D letter is and what one looks
like. I also am sure that he knows that any lawyer would advise Micah to
not engage with an adverse party on his own over an issue of
trademark dispute without adequate legal counsel. Thus, for Jono to
suggest that there is some Canonical, Ltd. “team” that Micah
should be talking to not only pathetically conflates Free Software
community operations with corporate legal aggression, but also seem like a
Canonical, Ltd. employee subtly suggesting that those who receive C&D’s
from Canonical, Ltd.’s legal departments should engage in discussion
without seeking their own legal counsel.

Free Software projects should get trademarks of their
own. Indeed, I fully support that and I encourage for folks interested in
this issue to listen to Pam
Chestek’s excellent talk on the topic at FOSDEM 2013 (which Karen Sandler
and I broadcast on Free as in Freedom). However, true Free
Software communities don’t try to squelch Free Speech that criticizes their
projects. It’s deplorable that Canonical, Ltd. has an organized campaign
between their lawyers and their public relations folks like Jono to (a)
send aggressive C&D letters to Free Software enthusiasts who criticize
Ubuntu and (b) follow up on those efforts by subtly shaming those who
lawyer-up upon receiving that C&D.

I should finally note that Canonical, Ltd. has an inappropriate and
Orwellian predilection for coopting words our community (including the word
“community” itself, BTW). Most people don’t know that I myself
registered the domain name canonical.org back on 1999-08-06 (when
Shuttleworth was still running Thawte) for a group of friends who liked to
use the word canonical in the canonical way, and still do so today.
However, thanks to Shuttleworth, it’s difficult
to use canonical
in the canonical way anymore in Free Software circles, because
Shuttleworth coopted the term and brand-markets on top of it. Ubuntu, for
its part, is a word
meaning human
kindness that Shuttleworth has also coopted for his often unkind
activities.

Update at 16:17 on
2013-11-08: Canonical, Ltd. has posted a response regarding their
enforcement action, which claims that their trademark policy
is unusually permissive. This is true if the universe is
“all trademark policies in the world”, but it is false if the
universe is “Open Source and Free Software trademark
policies”. Of course, like any good spin doctors, Canonical, Ltd. doesn’t
actually say this explicitly.

Similarly, Canonical, Ltd. restates the oft-over-simplified claim
that in trademark law a mark owner is expected to protect the authenticity
of a trademark otherwise they risk losing the mark. What they don’t tell
you is why they believe failure to enforce in this specific instance against
fixubuntu.com had specific risk. Why didn’t they tell us that?: because it
doesn’t. I suspect they could have simply asked for the disclaimer that
Micah gave them willingly, and that would have satisfied the aforementioned
risk adequately.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/10/07/paypal-perl.html

I recently upgraded
to Debian wheezy.
On, Debian squeeze, I
had no problem using the stock Perl module Business::PayPal::API
to import PayPal transactions for Software Freedom Conservancy, via the
Debian package libbusiness-paypal-api-perl.

After the wheezy upgrade, something goes wrong and it doesn’t work.
I reviewed
some similar complaints, that seem to relate
to this
resolved bug, but that wasn’t my problem, I don’t think.

I ran strace to dig around and see what was going on. The working
squeeeze install did this:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1365) = 1365
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
        rt_sigaction(SIGALRM, {0xxxxxx, [], 0}, {SIG_DFL, [], 0}, 8) = 0
        rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
        alarm(60)                               = 0
        read(3, "SOMEDATA", 5)               = 5
        

But the same script on wheezy did this at the same point:

        select(8, [3], [3], NULL, {0, 0})       = 1 (out [3], left {0, 0})
        write(3, "SOMEDATA"..., 1373) = 1373
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout)
        read(3, 0xxxxxxxx, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
        

I was pretty confused, and basically I still am, but then I
noticed this
in the documentation for Business::PayPal::API,
regarding SOAP::Lite:

if you have already loaded Net::SSLeay (or IO::Socket::SSL), then Net::HTTPS
will prefer to use IO::Socket::SSL. I don’t know how to get SOAP::Lite to
work with IO::Socket::SSL (e.g., Crypt::SSLeay uses HTTPS_* environment
variables), so until then, you can use this hack:
local $IO::Socket::SSL::VERSION = undef;

That hack didn’t work, but I did confirm via strace that on
wheezy, IO::Socket::SSL was getting loaded instead
of Net::SSL. So, I did this, which was a complete and much worse
hack:

        use Net::SSL;
        use Net::SSLeay;
        $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;
        # Then:
        use Business::PayPal::API qw(GetTransactionDetails TransactionSearch);
        

… And this incantation worked. This isn’t the right fix, but I
figured I should publish this, as this ate up three hours, and it’s worth
the 15 minutes to write this post, just in case someone else tries to use
Business::PayPal::API on wheezy.

I used to be a Perl expert once upon a time. This situation convinced me
that I’m not. In the old days, I would’ve actually figured out what was
wrong.