Re: Debianizing Filter::Crypto::Decrypt

[C.J. Adams-Collier-4]

On Tue, 2009-11-03 at 23:27 +0000, Steve Hay wrote:
> 2009/11/3 C.J. Adams-Collier <cjac@...>:
> > Hey there.  I'm going to package this up.  Want a patch to fix the POD
> > test failure?
> >
> > At least I *think* it is in this package...
> >
>
> Yes, if you have a patch then I'd be happy to receive it.

The point has been raised that OpenSSL is incompatible with the GPL.  Do
you feel like patching your code to indicate this?  We'll bring it up in
the debian-specific copyright file either way, but thought it might be
good for you to know.

Cheers,

C.J.

[Stefan Hornburg (Racke)]

C.J. Adams-Collier wrote:

> On Tue, 2009-11-03 at 23:27 +0000, Steve Hay wrote:
>> 2009/11/3 C.J. Adams-Collier <cjac@...>:
>>> Hey there.  I'm going to package this up.  Want a patch to fix the POD
>>> test failure?
>>>
>>> At least I *think* it is in this package...
>>>
>> Yes, if you have a patch then I'd be happy to receive it.
>
> The point has been raised that OpenSSL is incompatible with the GPL.  Do
> you feel like patching your code to indicate this?  We'll bring it up in
> the debian-specific copyright file either way, but thought it might be
> good for you to know.
>

The module author may allow compiling/linking/using OpenSSL in addition
to the GPL.


Regards
         Racke



--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel Kahn Gillmor-7]

On 11/05/2009 11:22 AM, Stefan Hornburg (Racke) wrote:
> The module author may allow compiling/linking/using OpenSSL in addition
> to the GPL.

hrm.  This is true for the smaller case, but then what about other
GPL'ed perl modules that depend on Filter::Crypto::Decrypt?

Do those modules also need to have the OpenSSL exception in them?  How
far does the extension need to reach?

        --dkg

[Damyan Ivanov-5]

-=| Daniel Kahn Gillmor, Thu, Nov 05, 2009 at 02:33:47PM -0500 |=-
> On 11/05/2009 11:22 AM, Stefan Hornburg (Racke) wrote:
> > The module author may allow compiling/linking/using OpenSSL in addition
> > to the GPL.
>
> hrm.  This is true for the smaller case, but then what about other
> GPL'ed perl modules that depend on Filter::Crypto::Decrypt?
>
> Do those modules also need to have the OpenSSL exception in them?  How
> far does the extension need to reach?

I think the answer to this question is "No", but can't remember why :|

--
dam

[Tim Retout]

On Fri, 2009-11-06 at 10:31 +0200, Damyan Ivanov wrote:

> -=| Daniel Kahn Gillmor, Thu, Nov 05, 2009 at 02:33:47PM -0500 |=-
> > On 11/05/2009 11:22 AM, Stefan Hornburg (Racke) wrote:
> > > The module author may allow compiling/linking/using OpenSSL in addition
> > > to the GPL.
> >
> > hrm.  This is true for the smaller case, but then what about other
> > GPL'ed perl modules that depend on Filter::Crypto::Decrypt?
> >
> > Do those modules also need to have the OpenSSL exception in them?  How
> > far does the extension need to reach?
>
> I think the answer to this question is "No", but can't remember why :|

I think the answer's "yes and no and it doesn't matter".

Yes, all reverse deps would need a GPL exception if the GPL was their
only license (and it could get complicated if those modules then
depended on unrelated Perl modules without an exception).  See, for
instance, the special exception that Totem (and Rhythmbox, but it's not
in debian/copyright, tut, tut) have added so that non-GPL compatible
GStreamer plugins can be used.

No, in practice, most Perl modules are also under the Artistic license,
which is compatible with the OpenSSL license, so we could use them on
those terms.

It doesn't matter, because in the specific case of
libfilter-crypto-perl, any module that truly depended on it would be
using encrypted source code (or just obfuscated, given we know the key?)
so would be contradicting the GPL from the beginning (because we need to
ship the preferred form for modifications).  I suppose we could conceive
of an app that generates obfuscated code, though...

[Standard disclaimers about this not being legal advice apply.]

--
Tim Retout <tim@...>

[Steve Hay-2]

2009/11/5 C.J. Adams-Collier <cjac@...>:

> On Tue, 2009-11-03 at 23:27 +0000, Steve Hay wrote:
>> 2009/11/3 C.J. Adams-Collier <cjac@...>:
>> > Hey there.  I'm going to package this up.  Want a patch to fix the POD
>> > test failure?
>> >
>> > At least I *think* it is in this package...
>> >
>>
>> Yes, if you have a patch then I'd be happy to receive it.
>
> The point has been raised that OpenSSL is incompatible with the GPL.  Do
> you feel like patching your code to indicate this?  We'll bring it up in
> the debian-specific copyright file either way, but thought it might be
> good for you to know.
>

Thanks for the heads-up. I'll add a note to LICENCE that OpenSSL is
distributed under a BSD-style licence. Note that LICENCE already
mentions that two of the functions included in Filter-Crypto are based
on code taken from mod_ssl, which is also distributed under a
BSD-style licence.

Btw, regarding your fix for the POD test failures, I'd like to do
something about this. I've just got two FAIL reports in from CPAN
Testers regarding this bug. Both are on Debian:

http://nntp.x.perl.org/group/perl.cpan.testers/5926663
http://nntp.x.perl.org/group/perl.cpan.testers/5916199

I think the easiest thing to do would be to skip the test concerned
when running on Debian with Pod::Perldoc's VERSION (and/or perldoc's
VERSION if it has one) less than a certain value, or failing that,
just skip it when the Debian version is level than a certain value.
Can you tell me what the appropriate version(s) are that I'd need to
skip the test on?

Thanks,
Steve


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[C.J. Adams-Collier-4]

On Wed, 2009-11-11 at 22:34 +0000, Steve Hay wrote:

> 2009/11/5 C.J. Adams-Collier <cjac@...>:
> > On Tue, 2009-11-03 at 23:27 +0000, Steve Hay wrote:
> >> 2009/11/3 C.J. Adams-Collier <cjac@...>:
> >> > Hey there.  I'm going to package this up.  Want a patch to fix the POD
> >> > test failure?
> >> >
> >> > At least I *think* it is in this package...
> >> >
> >>
> >> Yes, if you have a patch then I'd be happy to receive it.
> >
> > The point has been raised that OpenSSL is incompatible with the GPL.  Do
> > you feel like patching your code to indicate this?  We'll bring it up in
> > the debian-specific copyright file either way, but thought it might be
> > good for you to know.
> >
>
> Thanks for the heads-up. I'll add a note to LICENCE that OpenSSL is
> distributed under a BSD-style licence. Note that LICENCE already
> mentions that two of the functions included in Filter-Crypto are based
> on code taken from mod_ssl, which is also distributed under a
> BSD-style licence.

Yeah, we've been using that.  Thanks!

http://svn.debian.org/viewsvn/pkg-perl/trunk/libfilter-crypto-perl/debian/copyright?revision=46861

> Btw, regarding your fix for the POD test failures, I'd like to do
> something about this. I've just got two FAIL reports in from CPAN
> Testers regarding this bug. Both are on Debian:
>
> http://nntp.x.perl.org/group/perl.cpan.testers/5926663
> http://nntp.x.perl.org/group/perl.cpan.testers/5916199
>
> I think the easiest thing to do would be to skip the test concerned
> when running on Debian with Pod::Perldoc's VERSION (and/or perldoc's
> VERSION if it has one) less than a certain value, or failing that,
> just skip it when the Debian version is level than a certain value.
> Can you tell me what the appropriate version(s) are that I'd need to
> skip the test on?

The perl-doc package diverts /usr/bin/perldoc to /usr/bin/perldoc.stub
when it is installed, so you could use something like this:

$ echo '$x = "is not"; $x = "is" if -e q{/usr/bin/perldoc.stub}; print "perl-doc $x installed\n"' > /tmp/foo;\
 perl /tmp/foo &&\
 sudo apt-get -y install perl-doc >/dev/null 2>&1 ;\
 perl /tmp/foo
perl-doc is not installed
perl-doc is installed

All Debian-based hosts have a file /etc/debian_version, so
-e /etc/debian_version will be enough to know if you're on a system
where you should determine whether you should check
for /usr/bin/perldoc.stub.  Maybe something like the attached?


> Thanks,
> Steve

Cheers,

C.J.


[libfilter-crypto-perl_perldoc.patch]

---

diff --git a/t/03_script.t b/t/03_script.t
index f8bbf12..ab71428 100755
--- a/t/03_script.t
+++ b/t/03_script.t
@@ -604,25 +604,30 @@ MAIN: {
                     ^ Options:   /mosx,
          '-h option works');
 
-    {
-        local $ENV{PERLDOC} = '-t';
-        chomp($data = qx{$perl $crypt_file -m});
-        like($data, qr/^ NAME         .*?
-                       ^ SYNOPSIS     .*?
-                       ^ ARGUMENTS    .*?
-                       ^ OPTIONS      .*?
-                       ^ EXIT\ STATUS .*?
-                       ^ DIAGNOSTICS  .*?
-                       ^ EXAMPLES     .*?
-                       ^ ENVIRONMENT  .*?
-                       ^ SEE\ ALSO    .*?
-                       ^ AUTHOR       .*?
-                       ^ COPYRIGHT    .*?
-                       ^ LICENCE      .*?
-                       ^ VERSION      .*?
-                       ^ DATE         .*?
-                       ^ HISTORY      /mosx,
-             '-m option works');
+  SKIP: {
+      skip 'debian host without perl-doc installed', 1
+  if( -e q{/etc/debian_version} &&  # Debian-based host
+      !-e q{/usr/bin/perldoc.stub}  # perl-doc has not diverted /usr/bin/perldoc
+  );
+
+      local $ENV{PERLDOC} = '-t';
+      chomp($data = qx{$perl $crypt_file -m});
+      like($data, qr/^ NAME         .*?
+                     ^ SYNOPSIS     .*?
+                     ^ ARGUMENTS    .*?
+                     ^ OPTIONS      .*?
+                     ^ EXIT\ STATUS .*?
+                     ^ DIAGNOSTICS  .*?
+                     ^ EXAMPLES     .*?
+                     ^ ENVIRONMENT  .*?
+                     ^ SEE\ ALSO    .*?
+                     ^ AUTHOR       .*?
+                     ^ COPYRIGHT    .*?
+                     ^ LICENCE      .*?
+                     ^ VERSION      .*?
+                     ^ DATE         .*?
+                     ^ HISTORY      /mosx,
+   '-m option works');
     }
 
     unlink $mbfile;

---

[Jonas Smedegaard]

On Wed, Nov 11, 2009 at 03:45:11PM -0800, C.J. Adams-Collier wrote:
>On Wed, 2009-11-11 at 22:34 +0000, Steve Hay wrote:

>> Btw, regarding your fix for the POD test failures, I'd like to do
>> something about this. I've just got two FAIL reports in from CPAN
>> Testers regarding this bug. Both are on Debian:
>>
>> http://nntp.x.perl.org/group/perl.cpan.testers/5926663 
>> http://nntp.x.perl.org/group/perl.cpan.testers/5916199
>>
>> I think the easiest thing to do would be to skip the test concerned
>> when running on Debian with Pod::Perldoc's VERSION (and/or perldoc's
>> VERSION if it has one) less than a certain value, or failing that,
>> just skip it when the Debian version is level than a certain value.
>> Can you tell me what the appropriate version(s) are that I'd need to
>> skip the test on?
>
>The perl-doc package diverts /usr/bin/perldoc to /usr/bin/perldoc.stub
>when it is installed, so you could use something like this:
>
>$ echo '$x = "is not"; $x = "is" if -e q{/usr/bin/perldoc.stub}; print "perl-doc $x installed\n"' > /tmp/foo;\
> perl /tmp/foo &&\
> sudo apt-get -y install perl-doc >/dev/null 2>&1 ;\
> perl /tmp/foo
>perl-doc is not installed
>perl-doc is installed
>
>All Debian-based hosts have a file /etc/debian_version, so
>-e /etc/debian_version will be enough to know if you're on a system
>where you should determine whether you should check
>for /usr/bin/perldoc.stub.  Maybe something like the attached?

If you want a less distro-specific testing method (even if the results
is perhaps distro-specific) then perhaps use lsb_release instead
(contained in lsb-base in Debian) which on Debian queries the content of
/etc/debian_version.


  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[C.J. Adams-Collier-4]

> If you want a less distro-specific testing method (even if the results
> is perhaps distro-specific) then perhaps use lsb_release instead
> (contained in lsb-base in Debian) which on Debian queries the content of
> /etc/debian_version.

> - Jonas


Thanks Jonas.

It looks like CentOS doesn't have a lsb_release in the path, so we'd
have to search $ENV{PATH} and then call it.

I don't see an easy way to tell from the output whether a distribution
is debian-based.

cjac@hardy0:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.3 LTS
Release: 8.04
Codename: hardy

cjac@lenny0:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 5.0.1 (lenny)
Release: 5.0.1
Codename: lenny

Perhaps for now

 -e q{/etc/debian_version} && !-e q{/usr/bin/perldoc.stub}

is the easiest and least prone to error.

Steve?

[Steve Hay-2]

2009/11/12 C.J. Adams-Collier <cjac@...>:

>
>> If you want a less distro-specific testing method (even if the results
>> is perhaps distro-specific) then perhaps use lsb_release instead
>> (contained in lsb-base in Debian) which on Debian queries the content of
>> /etc/debian_version.
>
>> - Jonas
>
>
> Thanks Jonas.
>
> It looks like CentOS doesn't have a lsb_release in the path, so we'd
> have to search $ENV{PATH} and then call it.
>
> I don't see an easy way to tell from the output whether a distribution
> is debian-based.
>
> cjac@hardy0:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 8.04.3 LTS
> Release:        8.04
> Codename:       hardy
>
> cjac@lenny0:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:    Debian GNU/Linux 5.0.1 (lenny)
> Release:        5.0.1
> Codename:       lenny
>
> Perhaps for now
>
>  -e q{/etc/debian_version} && !-e q{/usr/bin/perldoc.stub}
>
> is the easiest and least prone to error.
>
> Steve?
>

I think avoiding lsb_release looks simpler.

Is it correct to always check in /usr/bin for perldoc.stub, though?
Pod::Usage locates perldoc itself by looking in $Config{scriptdir}.
Would perldoc.stub be there as well, alongside perldoc, or is it
always in /usr/bin ?


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[C.J. Adams-Collier-4]

On Thu, 2009-11-12 at 23:03 +0000, Steve Hay wrote:

> Is it correct to always check in /usr/bin for perldoc.stub, though?
> Pod::Usage locates perldoc itself by looking in $Config{scriptdir}.
> Would perldoc.stub be there as well, alongside perldoc, or is it
> always in /usr/bin ?

Yep, the perl-doc package diverts /usr/bin/perldoc
to /usr/bin/perldoc.stub without consulting $Config{scriptdir}.

cjac@dev0:/usr/src/deb/perl-5.10.1$ grep divert debian/perl*doc*
debian/perl-doc.postrm:    dpkg-divert --remove --package perl-doc --rename \
debian/perl-doc.postrm: --divert /usr/bin/perldoc.stub /usr/bin/perldoc
debian/perl-doc.preinst:    dpkg-divert --add --package perl-doc --rename \
debian/perl-doc.preinst: --divert /usr/bin/perldoc.stub /usr/bin/perldoc
debian/perl.perldoc:# place-holder, diverted by perl-doc

Cheers,

C.J.

[Steve Hay-2]

2009/11/12 C.J. Adams-Collier <cjac@...>:

> On Thu, 2009-11-12 at 23:03 +0000, Steve Hay wrote:
>
>> Is it correct to always check in /usr/bin for perldoc.stub, though?
>> Pod::Usage locates perldoc itself by looking in $Config{scriptdir}.
>> Would perldoc.stub be there as well, alongside perldoc, or is it
>> always in /usr/bin ?
>
> Yep, the perl-doc package diverts /usr/bin/perldoc
> to /usr/bin/perldoc.stub without consulting $Config{scriptdir}.
>
> cjac@dev0:/usr/src/deb/perl-5.10.1$ grep divert debian/perl*doc*
> debian/perl-doc.postrm:    dpkg-divert --remove --package perl-doc --rename \
> debian/perl-doc.postrm: --divert /usr/bin/perldoc.stub /usr/bin/perldoc
> debian/perl-doc.preinst:    dpkg-divert --add --package perl-doc --rename \
> debian/perl-doc.preinst:        --divert /usr/bin/perldoc.stub /usr/bin/perldoc
> debian/perl.perldoc:# place-holder, diverted by perl-doc
>

Okay, thanks.

Filter-Crypto-1.30 has just been uploaded to CPAN with the test skip
patch and a note in LICENCE about the OpenSSL licence terms.


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...