License entry in egg info files

[W. Martin Borgert]

Hi, I believe that the following entries are incorrect:

/usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN
/usr/share/pyshared/cups-1.0.egg-info:License: UNKNOWN
/usr/share/pyshared/Django-1.1.1.egg-info:License: UNKNOWN
/usr/share/pyshared/git_build_package-0.0.0.egg-info:License: UNKNOWN
/usr/share/pyshared/lxml-2.2.2.egg-info:License: UNKNOWN
/usr/share/pyshared/miro-2.5.2.egg-info:License: UNKNOWN
/usr/share/pyshared/pcapy-0.10.6.egg-info:License: UNKNOWN
/usr/share/pyshared/pycrypto-2.0.1.egg-info:License: UNKNOWN
/usr/share/pyshared/pyogg-1.3.egg-info:License: UNKNOWN
/usr/share/pyshared/python_mpd-0.2.1.egg-info:License: UNKNOWN
/usr/share/pyshared/pyvorbis-1.4.egg-info:License: UNKNOWN
/usr/share/pyshared/PyXML-0.8.4.egg-info:License: UNKNOWN
/usr/share/pyshared/Sonata-1.6.2.1.egg-info:License: UNKNOWN
/usr/share/pyshared/spambayes-1.0.4.egg-info:License: UNKNOWN
/usr/share/pyshared/tailor-0.9.35.egg-info:License: UNKNOWN

I'm too lazy right now to file bugs, but shouldn't we fix this?


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

[Ben Finney-5]

"W. Martin Borgert" <debacle@...> writes:

> Hi, I believe that the following entries are incorrect:
>
> /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN
> /usr/share/pyshared/cups-1.0.egg-info:License: UNKNOWN
[…]
> /usr/share/pyshared/spambayes-1.0.4.egg-info:License: UNKNOWN
> /usr/share/pyshared/tailor-0.9.35.egg-info:License: UNKNOWN
>
> I'm too lazy right now to file bugs, but shouldn't we fix this?

Currently, Debian policy is (AFAICT) silent on the topic of
‘foo-1.2.3.egg-info’ files. The ‘License’ field does not IMO have any
effect on copyright or licenses; only an explicit grant of license could
do that, and I don't think that field value would count.

So currently I don't think they are bugs of any severity above ‘minor’.

There's currently no effective Python policy (the latest one at
<URL:http://www.debian.org/doc/packaging-manuals/python-policy/> is way
out of date with regard to current recommended practice).

However, if there *were* to be such a policy, I would expect it to
require that the distutils ‘License’ field at least be consistent with
‘debian/copyright’. So, in principle, I think these *should* be bugs.

Presumably all these are created by upstream ‘setup.py’ settings, so it
would ultimately be for upstream to fix in each case.

--
 \      “It's up to the masses to distribute [music] however they want |
  `\    … The laws don't matter at that point. People sharing music in |
_o__)        their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney


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

[Jakub Wilk]

* W. Martin Borgert <debacle@...>, 2009-10-17, 13:23:
>Hi, I believe that the following entries are incorrect:
>
>/usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN
[snip]
>
>I'm too lazy right now to file bugs

It would be better to file a bug against lintian to have a check for
such issues.

--
Jakub Wilk


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

[Ben Finney-5]

Jakub Wilk <ubanus@...> writes:

> * W. Martin Borgert <debacle@...>, 2009-10-17, 13:23:
> >/usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN
>
> It would be better to file a bug against lintian to have a check for
> such issues.

I disagree. This issue in the ‘setup.py’ settings is upstream's
responsibility. Lintian is best reserved for reporting problems that are
the Debian package maintainer's responsibility.

--
 \        “All opinions are not equal. Some are a very great deal more |
  `\    robust, sophisticated and well supported in logic and argument |
_o__)                                     than others.” —Douglas Adams |
Ben Finney


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

[Paul Wise-3]

On Sat, Oct 17, 2009 at 9:50 PM, Ben Finney <ben+debian@...> wrote:

> I disagree. This issue in the ‘setup.py’ settings is upstream's
> responsibility. Lintian is best reserved for reporting problems that are
> the Debian package maintainer's responsibility.

Do you object to spelling-error-in-binary,
duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or
the other lintian tests that check upstream stuff?

Also, it is the maintainer's responsibility to point out upstream
problems to upstream, if lintian can help automatically detect such
problems, I think it is a good idea to do so.

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

[W. Martin Borgert]

On 2009-10-17 23:59, Ben Finney wrote:
> So currently I don't think they are bugs of any severity above ‘minor’.

I agree, that this is 'minor' or even 'wishlist'.

> Presumably all these are created by upstream ‘setup.py’ settings, so it
> would ultimately be for upstream to fix in each case.

The maintainer can patch the setup.py file in the meantime or in
case upstream does not care.

A lintian check sounds like a good idea to me. It's all about
package consistency. Fortunately, I forgot my poor Perl
knowledge years ago, so somebody else has to write it.


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

[Ben Finney-5]

Paul Wise <pabs@...> writes:

> Do you object to spelling-error-in-binary,
> duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or
> the other lintian tests that check upstream stuff?

I think they lead to widely-used, persistent overrides, and I think such
overrides are an indicator that the specific check is inappropriate.

That said, I freely acknowledge that in this case I can't predict
whether that would be the result.

> Also, it is the maintainer's responsibility to point out upstream
> problems to upstream, if lintian can help automatically detect such
> problems, I think it is a good idea to do so.

"W. Martin Borgert" <debacle@...> writes:

> The maintainer can patch the setup.py file in the meantime or in case
> upstream does not care.

I don't have a strong objection in this case, and I can see good
arguments for and against a Lintian check. I wouldn't put up a fight
either way :-)

--
 \           “I was in a bar the other night, hopping from barstool to |
  `\     barstool, trying to get lucky, but there wasn't any gum under |
_o__)                                       any of them.” —Emo Philips |
Ben Finney


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

[W. Martin Borgert]

On 2009-10-18 09:46, Ben Finney wrote:
> I don't have a strong objection in this case, and I can see good
> arguments for and against a Lintian check. I wouldn't put up a fight
> either way :-)

Me neither, it's certainly one of the least pressing issues we
have with Debian & Python :~)


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

[Paul Wise-3]

On Sun, Oct 18, 2009 at 6:46 AM, Ben Finney <ben+debian@...> wrote:
> Paul Wise <pabs@...> writes:
>
>> Do you object to spelling-error-in-binary,
>> duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or
>> the other lintian tests that check upstream stuff?
>
> I think they lead to widely-used, persistent overrides, and I think such
> overrides are an indicator that the specific check is inappropriate.

Sounds like you have observed people using overrides inappropriately.

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

[Bernd Zeimetz]

Ben Finney wrote:
> Paul Wise <pabs@...> writes:
>
>> Do you object to spelling-error-in-binary,
>> duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or
>> the other lintian tests that check upstream stuff?
>
> I think they lead to widely-used, persistent overrides, and I think such
> overrides are an indicator that the specific check is inappropriate.

Usually an override is a fail in the maintainer's brain or a bug in lintian.
Only in rare cases overrides are the right way to go.


--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

[Ben Finney-5]

Bernd Zeimetz <bernd@...> writes:

> Usually an override is a fail in the maintainer's brain or a bug in
> lintian. Only in rare cases overrides are the right way to go.

Yes, that's pretty much my point: that *if* a Lintian check leads to
many maintainers adding an override for that tag that persist over time,
then probably the check was badly implemented or a bad idea in the first
place.

--
 \     “I thought I'd begin by reading a poem by Shakespeare, but then |
  `\     I thought ‘Why should I? He never reads any of mine.’” —Spike |
_o__)                                                         Milligan |
Ben Finney


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