Initial cut at a Debian package linting wrapper for Firehose

[Paul Tagliamonte]

Hello, Firehosen,

I've just hacked a basic wrapper around one of the most used Debian
tools; Lintian. It's currently brokenish (need to work out some stray
Nones in the schema), but should be good to go shortly. Check it out on
GitHub[1]

While wrapping it, I also added some helper functions which could use
some feedback. They're very Debian-centric, but could be simply adapted
for Firehose proper if we decided on that.

Cheers,
  Paul


P.S., for those who missed the joke, see[2]


[1]: https://github.com/paultag/storz/blob/master/wrappers/storz-lintian
[2]: http://en.wikipedia.org/wiki/Storz

-- 
 .''`.  Paul Tagliamonte <paultag(a)debian.org&gt;
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[David Malcolm]

On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
>  Hello, Firehosen,
>  
>  I've just hacked a basic wrapper around one of the most used Debian
>  tools; Lintian. It's currently brokenish (need to work out some stray
>  Nones in the schema), but should be good to go shortly. Check it out on
>  GitHub[1] 
Nice.  I started making a list of projects using Firehose in the
README.rst and added a link.

>  While wrapping it, I also added some helper functions which could
> use
>  some feedback. They're very Debian-centric, but could be simply adapted
>  for Firehose proper if we decided on that. 
Those would be:
https://github.com/paultag/storz/blob/master/storz/deb.py
right?

If every Debian project using Firehose is going to use code like that,
then it would makes sense to slurp that into Firehose itself, but I
don't want to force dependencies on people using Firehose that aren't
using the deb functionality (I see you have a couple of "from debian"
imports, which don't exist on this box).
So you could put these into a new firehose/debian.py, or alternatively
put the imports into *method scope* within firehose/report.py, and have
a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
classmethods.  (If you also want to slurp in the exception classes into
firehose you'd want to rename them also, naturally)

Cheers
Dave

Relicensing (was Re: Initial cut at a Debian package linting wrapper for Firehose)

[David Malcolm]

On Sun, 2013-02-10 at 16:09 -0500, David Malcolm wrote:
>  On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
>  > Hello, Firehosen,
>  > 
>  > I've just hacked a basic wrapper around one of the most used Debian
>  > tools; Lintian. It's currently brokenish (need to work out some stray
>  > Nones in the schema), but should be good to go shortly. Check it out on
>  > GitHub[1]
>  
>  Nice.  I started making a list of projects using Firehose in the
>  README.rst and added a link.
>  
>  > While wrapping it, I also added some helper functions which could use
>  > some feedback. They're very Debian-centric, but could be simply adapted
>  > for Firehose proper if we decided on that.
>  
>  Those would be:
>  https://github.com/paultag/storz/blob/master/storz/deb.py
>  right?
>  
>  If every Debian project using Firehose is going to use code like that,
>  then it would makes sense to slurp that into Firehose itself, but I
>  don't want to force dependencies on people using Firehose that aren't
>  using the deb functionality (I see you have a couple of "from debian"
>  imports, which don't exist on this box).
>  So you could put these into a new firehose/debian.py, or alternatively
>  put the imports into *method scope* within firehose/report.py, and have
>  a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
>  classmethods.  (If you also want to slurp in the exception classes into
>  firehose you'd want to rename them also, naturally) 
Oh, and we chatted about this on IRC, but it's worth mentioning here:
we're going to relicense Firehose from GPLv3, probably to "LGPLv2.1 or
later", to allow it to be license-compatible with a broader array of
projects.  (I need it to be compatible with GPLv3 so that I can run it
from inside GCC, but I'd prefer a more liberal license so it can be used
e.g. in a wide array of web apps for reporting, and embedded in other
Python-based static analyzers).

See:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibil...

Paul: you already agreed to this on IRC, right?  The only other
contributor so far is Michael Hrivnak (CCed) who verbally gave me
permission to relicense as I saw fit when we created this thing at
FUDcon a few weeks ago (and also another Red Hatter).   (Better to
relicense sooner rather than later, i.e. whilst the number of
contributors is small)

Dave

Relicensing (was Re: Initial cut at a Debian package linting wrapper for Firehose)

[Paul Tagliamonte]

On Sun, Feb 10, 2013 at 04:21:14PM -0500, David Malcolm wrote:
>  On Sun, 2013-02-10 at 16:09 -0500, David Malcolm wrote:
>  > On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
>  > > Hello, Firehosen,
>  > > 
>  > > I've just hacked a basic wrapper around one of the most used Debian
>  > > tools; Lintian. It's currently brokenish (need to work out some stray
>  > > Nones in the schema), but should be good to go shortly. Check it out on
>  > > GitHub[1]
>  > 
>  > Nice.  I started making a list of projects using Firehose in the
>  > README.rst and added a link.
>  > 
>  > > While wrapping it, I also added some helper functions which could use
>  > > some feedback. They're very Debian-centric, but could be simply adapted
>  > > for Firehose proper if we decided on that.
>  > 
>  > Those would be:
>  > https://github.com/paultag/storz/blob/master/storz/deb.py
>  > right?
>  > 
>  > If every Debian project using Firehose is going to use code like that,
>  > then it would makes sense to slurp that into Firehose itself, but I
>  > don't want to force dependencies on people using Firehose that aren't
>  > using the deb functionality (I see you have a couple of "from debian"
>  > imports, which don't exist on this box).
>  > So you could put these into a new firehose/debian.py, or alternatively
>  > put the imports into *method scope* within firehose/report.py, and have
>  > a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
>  > classmethods.  (If you also want to slurp in the exception classes into
>  > firehose you'd want to rename them also, naturally)
>  
>  Oh, and we chatted about this on IRC, but it's worth mentioning here:
>  we're going to relicense Firehose from GPLv3, probably to "LGPLv2.1 or
>  later", to allow it to be license-compatible with a broader array of
>  projects.  (I need it to be compatible with GPLv3 so that I can run it
>  from inside GCC, but I'd prefer a more liberal license so it can be used
>  e.g. in a wide array of web apps for reporting, and embedded in other
>  Python-based static analyzers).
>  
>  See:
>  https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibil...
>  
>  Paul: you already agreed to this on IRC, right?  The only other 
Yep, but for the sake of having a GPG signed public message:

At Dave's discretion I hearby retroactively relicense all my work on
firehose to be under the LGPL, the version of which Dave is free to
choose. I'll assume this puts the code under LGPLv2.1+, and will modify
the current source to reflect this. If that's not right, let me know.

>  contributor so far is Michael Hrivnak (CCed) who verbally gave me
>  permission to relicense as I saw fit when we created this thing at
>  FUDcon a few weeks ago (and also another Red Hatter).   (Better to
>  relicense sooner rather than later, i.e. whilst the number of
>  contributors is small) 
Aye! I'm generally perfectly fine with any DFSG free license, shouldn't
make too much of a fuss here.

>  
>  Dave 
-T

>  
>  _______________________________________________
>  firehose-devel mailing list
>  firehose-devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/firehose-devel 
-- 
 .''`.  Paul Tagliamonte <paultag(a)debian.org&gt;
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

Relicensing (was Re: Initial cut at a Debian package linting wrapper for Firehose)

[David Malcolm]

On Sun, 2013-02-10 at 17:57 -0500, Paul Tagliamonte wrote:
>  On Sun, Feb 10, 2013 at 04:21:14PM -0500, David Malcolm wrote:
>  > On Sun, 2013-02-10 at 16:09 -0500, David Malcolm wrote:
>  > > On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
>  > > > Hello, Firehosen,
>  > > > 
>  > > > I've just hacked a basic wrapper around one of the most used Debian
>  > > > tools; Lintian. It's currently brokenish (need to work out some stray
>  > > > Nones in the schema), but should be good to go shortly. Check it out on
>  > > > GitHub[1]
>  > > 
>  > > Nice.  I started making a list of projects using Firehose in the
>  > > README.rst and added a link.
>  > > 
>  > > > While wrapping it, I also added some helper functions which could use
>  > > > some feedback. They're very Debian-centric, but could be simply
> adapted
>  > > > for Firehose proper if we decided on that.
>  > > 
>  > > Those would be:
>  > > https://github.com/paultag/storz/blob/master/storz/deb.py
>  > > right?
>  > > 
>  > > If every Debian project using Firehose is going to use code like that,
>  > > then it would makes sense to slurp that into Firehose itself, but I
>  > > don't want to force dependencies on people using Firehose that aren't
>  > > using the deb functionality (I see you have a couple of "from
> debian"
>  > > imports, which don't exist on this box).
>  > > So you could put these into a new firehose/debian.py, or alternatively
>  > > put the imports into *method scope* within firehose/report.py, and have
>  > > a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
>  > > classmethods.  (If you also want to slurp in the exception classes into
>  > > firehose you'd want to rename them also, naturally)
>  > 
>  > Oh, and we chatted about this on IRC, but it's worth mentioning here:
>  > we're going to relicense Firehose from GPLv3, probably to "LGPLv2.1 or
>  > later", to allow it to be license-compatible with a broader array of
>  > projects.  (I need it to be compatible with GPLv3 so that I can run it
>  > from inside GCC, but I'd prefer a more liberal license so it can be used
>  > e.g. in a wide array of web apps for reporting, and embedded in other
>  > Python-based static analyzers).
>  > 
>  > See:
>  > https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibil...
>  > 
>  > Paul: you already agreed to this on IRC, right?  The only other
>  
>  Yep, but for the sake of having a GPG signed public message:
>  
>  At Dave's discretion I hearby retroactively relicense all my work on
>  firehose to be under the LGPL, the version of which Dave is free to
>  choose. I'll assume this puts the code under LGPLv2.1+, and will modify
>  the current source to reflect this. If that's not right, let me know.
>  
>  > contributor so far is Michael Hrivnak (CCed) who verbally gave me
>  > permission to relicense as I saw fit when we created this thing at
>  > FUDcon a few weeks ago (and also another Red Hatter).   (Better to
>  > relicense sooner rather than later, i.e. whilst the number of
>  > contributors is small)
>  
>  Aye! I'm generally perfectly fine with any DFSG free license, shouldn't
>  make too much of a fuss here. 
I've relicensed firehose as "LGPLv2.1 or later" as of:
https://github.com/fedora-static-analysis/firehose/commit/bfadb4d8414ecbd...

[Paul Tagliamonte]

On Sun, Feb 10, 2013 at 04:09:20PM -0500, David Malcolm wrote:
>  On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
>  > Hello, Firehosen,
>  > 
>  > I've just hacked a basic wrapper around one of the most used Debian
>  > tools; Lintian. It's currently brokenish (need to work out some stray
>  > Nones in the schema), but should be good to go shortly. Check it out on
>  > GitHub[1]
>  
>  Nice.  I started making a list of projects using Firehose in the
>  README.rst and added a link. 
Sweet. Hopefully this turns more into a set of Debian tool wrappers (or
perhaps not even that, evetually)

>  
>  > While wrapping it, I also added some helper functions which could use
>  > some feedback. They're very Debian-centric, but could be simply adapted
>  > for Firehose proper if we decided on that.
>  
>  Those would be:
>  https://github.com/paultag/storz/blob/master/storz/deb.py
>  right? 
Yeah, that's right! Also `wrapper', there's some stuff in there to ease
some of the Firehose tree creation, but nothing major.

>  
>  If every Debian project using Firehose is going to use code like that,
>  then it would makes sense to slurp that into Firehose itself, but I
>  don't want to force dependencies on people using Firehose that aren't
>  using the deb functionality (I see you have a couple of "from debian"
>  imports, which don't exist on this box). 
Aye, I assumed so, so saved you the pull request :)

>  So you could put these into a new firehose/debian.py, or
> alternatively
>  put the imports into *method scope* within firehose/report.py, and have
>  a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
>  classmethods.  (If you also want to slurp in the exception classes into
>  firehose you'd want to rename them also, naturally) 
Not a bad idea. I'll take a look on how to get that stuff upstream'd
ASAP.

>  
>  Cheers
>  Dave
>  
>  _______________________________________________
>  firehose-devel mailing list
>  firehose-devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/firehose-devel 
Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag(a)debian.org&gt;
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag