Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

On 23-Apr-2016, Markus Koschany wrote:
> Please fix these issues and then I'm going to upload the package.

I have addressed all those issues in the updated source package,
available now:

$ dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)to learn.” —Richard M. Stallman, 2002 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 11:00 schrieb Ben Finney:
> Ben Finney  writes:
> 
>> I will merge the “common” files into the ‘colossal-cave-adventure’
>> binary package.
> 
> This is now done, and the updated source package is available:
> 
> $ dget -x 
> http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc
> 

Hi Ben,

it looks like nobody has any objections against using the adventure
virtual name.

I think we are almost finished now:

debian/copyright:

"Every package must be accompanied by a verbatim copy of its copyright
information..."

That means the CC-BY-4.0 license must be quoted in full here because it
is not one of the common licenses. (which is a shame in my opinion, but
can't be helped at the moment)

debian/watch: s/version=3/version=4/

Please fix these issues and then I'm going to upload the package.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Ben Finney  writes:

> I will merge the “common” files into the ‘colossal-cave-adventure’
> binary package.

This is now done, and the updated source package is available:

$ dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

-- 
 \  “Not using Microsoft products is like being a non-smoker 40 or |
  `\ 50 years ago: You can choose not to smoke, yourself, but it's |
_o__)   hard to avoid second-hand smoke.” —Michael Tiemann |
Ben Finney 

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Markus Koschany  writes:

> The rationale for providing multiple binary packages is that users
> should be able to install a subset of an application and save some
> disk space.

Another important rationale for splitting common files to a separate
binary package, is to avoid duplication and potential divergence.

> In this case they always have to install both packages because
> otherwise the game would be broken. It would be a different case if
> they already had a choice and could choose between different variants.

My intention was to enable existing and future implementations to have
the canonical data file available, without needing to deal with the
Python application.

> I wouldn't decline to upload but you should take this wall of text
> into consideration. In my opinion you can always split the package
> later when a potential port might require it.

Fair enough. I will merge the “common” files into the
‘colossal-cave-adventure’ binary package.

> Indeed they redirect all requests now. I don't know if that comes with
> a performance penalty though. I wonder why we need two fields,
> Vcs-Browser and Vcs-Git, if they are identical...

Because the meanings are different (one is for VCS operations on the
repo, one is for web-browser access to browse the repo). And commonly
they are not the same URL.

-- 
 \“I hate it when my foot falls asleep during the day, because |
  `\that means it's gonna be up all night.” —Steven Wright |
_o__)  |
Ben Finney

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 00:53 schrieb Ben Finney:
> On 19-Apr-2016, Markus Koschany wrote:
>> thanks for your update. There are only a few things left before we can
>> upload the package.
> 
> Thank you for working with me on this.
> 
>> My main concern is the adventure-common binary package because I
>> don't believe that shipping advent.dat with an extra package is very
>> useful at the moment.
> 
> Would you decline to upload on that basis? I appreciate you don't
> think there's a benefit, but is there any appreciable harm from having
> the ‘adventure-common’ package?
> 
>> I think it is cool to have a modern Python3 version but it would be
>> rather boring to have identical versions that simply reuse the same
>> story from advent.dat.
> 
> My thinking is that the Python 3 package is rather idiosyncratic, and
> that I'd like to make it clear the common files are available for
> different ports from the original Fortran program.
> 
> I'm not going to insist, but I'd like to know whether you think this
> structure is harmful, or only that this isn't the style you would
> choose.

I think the word harmful is a bit too strong but I don't think that your
current approach is beneficial either. The rationale for providing
multiple binary packages is that users should be able to install a
subset of an application and save some disk space. In this case they
always have to install both packages because otherwise the game would be
broken. It would be a different case if they already had a choice and
could choose between different variants.

Games often provide a significant amount of data and media files and
then it really makes sense to split off the data into some arch:all
-data or -common package when the architecture dependent data is small
compared to the arch-indep part. It would have been extremely wasteful,
if I hadn't done that for freeorion. (C++ game, -data package ~150 MB)
but in your case the game is already arch:all instead of arch:any and
adventure-common is even smaller than colossal-cave-adventure. So
another variable must be taken into account: metadata. Every binary
package in Debian's archive produces metadata and _every_ user has to
fetch this information, for instance with apt when doing a daily update.
In your case the performance penalty (even when it's rather small) is
greater than the advantage of having a separate -common package which
could be reused for a potential and not yet packaged adventure variant.

And last but not least the ftp team once rejected an extra -doc package
for the game njam because it was very small and insisted to merge it
into the -data package. The funny part is that my sponsor back then
thought it was a good idea, so the situation was kind of reversed.

I wouldn't decline to upload but you should take this wall of text into
consideration. In my opinion you can always split the package later when
a potential port might require it.

[...]
>> and that we use cgit for better performance.
> 
> Recently, the default browser on Alioth was switched to Cgit. So,
> at  the Cgit
> browser is presented.

Indeed they redirect all requests now. I don't know if that comes with a
performance penalty though. I wonder why we need two fields, Vcs-Browser
and Vcs-Git, if they are identical...

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

On 19-Apr-2016, Markus Koschany wrote:
> thanks for your update. There are only a few things left before we can
> upload the package.

Thank you for working with me on this.

> My main concern is the adventure-common binary package because I
> don't believe that shipping advent.dat with an extra package is very
> useful at the moment.

Would you decline to upload on that basis? I appreciate you don't
think there's a benefit, but is there any appreciable harm from having
the ‘adventure-common’ package?

> I think it is cool to have a modern Python3 version but it would be
> rather boring to have identical versions that simply reuse the same
> story from advent.dat.

My thinking is that the Python 3 package is rather idiosyncratic, and
that I'd like to make it clear the common files are available for
different ports from the original Fortran program.

I'm not going to insist, but I'd like to know whether you think this
structure is harmful, or only that this isn't the style you would
choose.


> colossal-cave-adventure.desktop: error: (will be fatal in the future):
> value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
> Entry" is an icon name with an extension, but there should be no
> extension as described in the Icon Theme Specification if the value is
> not an absolute path

I didn't see that part of the specification, thank you.

> Please change the Vcs fields […] so that the name of the git
> repository is identical to the source package name

Okay. The name ‘pkg-python-adventure’ was originally chosen because
the repository had only the Debian packaging, like other ‘pkg-foo’
repositories. I will re-name it now that the repository also contains
the upstream code.

> and that we use cgit for better performance.

Recently, the default browser on Alioth was switched to Cgit. So,
at  the Cgit
browser is presented.

> There is a authoritative list of virtual package names (yeah,
> bureaucracy in Debian is wonderful)
> 
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> 
> Please follow the procedure outlined in this text file

Great, I didn't know that existed :-) I will follow that procedure.

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP], Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Hello Ben,

thanks for your update. There are only a few things left before we can
upload the package. My main concern is the adventure-common binary
package because I don't believe that shipping advent.dat with an extra
package is very useful at the moment. As a compromise I offer you help
in resolving future issues with possibly other adventure variants in
Debian. However I expect that they will a) just ship the file with their
own package and b) it is rather unlikely that we will see another
implementation of the original adventure game in Debian. I think it is
cool to have a modern Python3 version but it would be rather boring to
have identical versions that simply reuse the same story from advent.dat.

Please fix

colossal-cave-adventure.desktop: (found with desktop-file-validate)

colossal-cave-adventure.desktop: error: (will be fatal in the future):
value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
Entry" is an icon name with an extension, but there should be no
extension as described in the Icon Theme Specification if the value is
not an absolute path

Please change the Vcs fields from:

Vcs-Git:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

Vcs-Browser:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

to

Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-adventure.git
Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/python-adventure.git

so that the name of the git repository is identical to the source
package name and that we use cgit for better performance. Please push
the package to collab-maint next time and I will work and upload from there.

Last but not least:

There is a authoritative list of virtual package names (yeah,
bureaucracy in Debian is wonderful)

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

Please follow the procedure outlined in this text file and post to
debian-devel and CC this RFS bug report. Personally I have no objections
against using the adventure name but it is polite to inform fellow DDs too.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP], Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Howdy Markus,

(Limiting distribution just to the RFS bug report to discuss the
sponsorship.)

Markus Koschany  writes:

> Am 18.04.2016 um 02:15 schrieb Ben Finney:
> > Those are in end-line comments (“# foo”). My understanding is that
> > end-line comments with that syntax are permitted in any Debian
> > control files.
>
> cme check dpkg made me aware of this and it probably refers to:
> https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax

That's right, thank you for showing it to me.

I don't think that restriction is justified, and have now filed
bug#821363 to effect a change in that policy.

Until then, the specification has the meaning as you described it. I
have removed those comment lines from ‘debian/copyright’.

> CC-BY-4.0 is a good choice and would help to avoid any confusion.

Done.

> I can live with the python3-adventure split off but as Bas already
> said I also find it unlikely that another program will ever make use
> of it.

Another reason was that Pybuild and dh_python make it much easier to
handle the package build when there is a ‘python3-libraryname’ package
containing the library.

However, you have convinced me that it is misleading to present a
‘python3-adventure’ when the package does not install a public module to
be imported.

I have merged the Python library back into the main application binary
package.

> Could you remove those ^L form feed characters please?

Done.


> desktop-file-validate is a useful tool to ensure compliance with the
> freedesktop specification. The written text can be found at
>
> https://specifications.freedesktop.org/menu-spec/latest/

Thank you. I have corrected the badly-formatted field in the desktop
entry.

> Another suggestion: The recommended location for hicolor icons is
> /usr/share/icons/hicolor.

These are deliberately low-colour icons (8 colours and 16 colours) to
reduce the file size; but there doesn't appear to be an XDG standard
place for low-colour icons.

> If you resize your icons to 256x256 you could install them to
> /usr/share/icons/hicolor/256x256/apps and replace the absolute icon
> path in your desktop file with the icon name.

Done.


The resulting updated source package is available:

$ dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

-- 
 \  “Every valuable human being must be a radical and a rebel, for |
  `\  what he must aim at is to make things better than they are.” |
_o__)  —Niels Bohr |
Ben Finney 

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 18.04.2016 um 02:15 schrieb Ben Finney:
[...]
>> I found the following things with check-all-the-things:
>>
>> colossal-cave-adventure.desktop: found with desktop-file-validate
>> error: value "adventure;advent;colossal;cave;spelunk" for locale string
>> list key "Keywords" in group "Desktop Entry" does not have a semicolon
>> (';') as trailing character
> 
> Thank you. I formed that field just by copying others. Is there a
> specification for that field that I've missed?

Sorry I've missed this paragraph. The fix is simple just add a semicolon
after spelunk. desktop-file-validate is a useful tool to ensure
compliance with the freedesktop specification. The written text can be
found at

https://specifications.freedesktop.org/menu-spec/latest/

Another suggestion: The recommended location for hicolor icons is
/usr/share/icons/hicolor. If you resize your icons to 256x256 you could
install them to /usr/share/icons/hicolor/256x256/apps and replace the
absolute icon path in your desktop file with the icon name.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 a...@debian.org


Hi Markus!


>Yes, I would sponsor the package if we can resolve the remaining issues.


(setting you as owner, to avoid double reviews by other potential sponsors)

thanks for your work, and sorry for the noise!

Gianfranco


>> The vim comments at the bottom are not allowed (syntax-wise)
> 
> Those are in end-line comments (“# foo”). My understanding is that
> end-line comments with that syntax are permitted in any Debian control
> files.

cme check dpkg made me aware of this and it probably refers to:

https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax

"Lines starting with # without any preceding whitespace are comments
lines that are only permitted in source package control files
(debian/control). These comment lines are ignored, even between two
continuation lines. They do not end logical lines."

The file syntax of copyright format 1.0 files is the same as for other
control files.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax


>> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
>> or CC-BY-4.0
> 
> Thanks. The package includes works I have derived from upstream works
> licensed under CC By-2.0.
> 
> My understanding of the problems with CC licenses version 2.0 is in the
> potential for some licensors to set impractical restrictions on
> attribution. That is not the case for any of these specific works, so I
> think they are DFSG-free currently.
> 
> To avoid such problems arising for the derived works, I will set the
> license to CC By-4.0 in those derived works as distributed in Debian.

CC-BY-4.0 is a good choice and would help to avoid any confusion. I
agree with you that CC-BY-2.0 is debatable but I'd rather prefer not to
open a can of worms here. On the following site are a few links of older
discussion:

https://wiki.debian.org/DFSGLicenses


>> You have patched the upstream sources (12 patches). In general the
>> patches look O.K but I wonder if they are all necessary. Did you
>> forward them upstream? Why do you think Debian should diverge from
>> upstream?
> 
> Those patches turn the work into a useable stand-alone program for
> Debian. Each one is submitted upstream, and I'm corresponding with the
> upstream maintainer to get these changes incorporated.

Fair enough.

>> You split the game into three arch:all binary packages. I'm not
>> totally convinced that this is really necessary for a game like
>> python-adventure. Your current approach is not totally wrong either,
>> perhaps a bit too perfectionist though. Are there strong reasons why
>> you split the game into three parts?
> 
> I would think rather that conforming to Debian policy would be the
> default, and a divergence would need a strong reason.

I'm not so sure about your last sentence since the Policy doesn't
dictate this particular packaging scheme IMO but I'd stand corrected if
you could point me to the relevant Policy part. Bas Wijnen has already
voiced some of my concerns in his previous e-mail.

In my opinion we should also take practical reasons into account and
creating three arch:all packages for such a trivial game comes with a
lot of overhead. For example adventure-common just ships the 50kb small
advent.dat file. Sometimes I need to package annotations or libraries
that can be equally small in seize but in those cases there is always a
concrete package in need of those dependencies. Here there only could be
a potential consumer in the future, which is also rather unlikely, but I
can't imagine that the trade off between meta data and maintenance costs
and saving 50 kb is really worth it. I recommend to merge advent.dat
into colossal-cave-adventure and be done with it.

I can live with the python3-adventure split off but as Bas already said
I also find it unlikely that another program will ever make use of it.

>> Why don't you join the Python or Games Team and maintain
>> python-adventure within one of these teams?
> 
> No particular reason. I am enjoying maintaining the code as it is.

Ok. The keyword is maintaining. In general I don't find it important
where people actually maintain software as long if they keep it updated
and in good shape. Still I would encourage you to join a team because it
often simplifies regular tasks like finding a sponsor.

Could you remove those ^L form feed characters please?

Regards,


Markus

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 18.04.2016 um 02:15 schrieb Ben Finney:
> Markus Koschany  writes:
> 
>> I had a look at your package and wanted to give you some feedback
>> because of the effort you put into packaging this game.
> 
> Thank you! Are you a prospective sponsor of this package?

Yes, I would sponsor the package if we can resolve the remaining issues.

>> The vim comments at the bottom are not allowed (syntax-wise)
> 
> Those are in end-line comments (“# foo”). My understanding is that
> end-line comments with that syntax are permitted in any Debian control
> files.

cme check dpkg made me aware of this and it probably refers to:

https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax

"Lines starting with # without any preceding whitespace are comments
lines that are only permitted in source package control files
(debian/control). These comment lines are ignored, even between two
continuation lines. They do not end logical lines."

The file syntax of copyright format 1.0 files is the same as for other
control files.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax


>> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
>> or CC-BY-4.0
> 
> Thanks. The package includes works I have derived from upstream works
> licensed under CC By-2.0.
> 
> My understanding of the problems with CC licenses version 2.0 is in the
> potential for some licensors to set impractical restrictions on
> attribution. That is not the case for any of these specific works, so I
> think they are DFSG-free currently.
> 
> To avoid such problems arising for the derived works, I will set the
> license to CC By-4.0 in those derived works as distributed in Debian.

CC-BY-4.0 is a good choice and would help to avoid any confusion. I
agree with you that CC-BY-2.0 is debatable but I'd rather prefer not to
open a can of worms here. On the following site are a few links of older
discussion:

https://wiki.debian.org/DFSGLicenses


>> You have patched the upstream sources (12 patches). In general the
>> patches look O.K but I wonder if they are all necessary. Did you
>> forward them upstream? Why do you think Debian should diverge from
>> upstream?
> 
> Those patches turn the work into a useable stand-alone program for
> Debian. Each one is submitted upstream, and I'm corresponding with the
> upstream maintainer to get these changes incorporated.

Fair enough.

>> You split the game into three arch:all binary packages. I'm not
>> totally convinced that this is really necessary for a game like
>> python-adventure. Your current approach is not totally wrong either,
>> perhaps a bit too perfectionist though. Are there strong reasons why
>> you split the game into three parts?
> 
> I would think rather that conforming to Debian policy would be the
> default, and a divergence would need a strong reason.

I'm not so sure about your last sentence since the Policy doesn't
dictate this particular packaging scheme IMO but I'd stand corrected if
you could point me to the relevant Policy part. Bas Wijnen has already
voiced some of my concerns in his previous e-mail.

In my opinion we should also take practical reasons into account and
creating three arch:all packages for such a trivial game comes with a
lot of overhead. For example adventure-common just ships the 50kb small
advent.dat file. Sometimes I need to package annotations or libraries
that can be equally small in seize but in those cases there is always a
concrete package in need of those dependencies. Here there only could be
a potential consumer in the future, which is also rather unlikely, but I
can't imagine that the trade off between meta data and maintenance costs
and saving 50 kb is really worth it. I recommend to merge advent.dat
into colossal-cave-adventure and be done with it.

I can live with the python3-adventure split off but as Bas already said
I also find it unlikely that another program will ever make use of it.

>> Why don't you join the Python or Games Team and maintain
>> python-adventure within one of these teams?
> 
> No particular reason. I am enjoying maintaining the code as it is.

Ok. The keyword is maintaining. In general I don't find it important
where people actually maintain software as long if they keep it updated
and in good shape. Still I would encourage you to join a team because it
often simplifies regular tasks like finding a sponsor.

Could you remove those ^L form feed characters please?

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Ben Finney  writes:

> Markus Koschany  writes:
>
> > CC-BY-2.0 is not a DFSG-free license, if possible better use
> > CC-BY-3.0 or CC-BY-4.0
>
> To avoid such problems arising for the derived works, I will set the
> license to CC By-4.0 in those derived works as distributed in Debian.

This is now done, the updated source package is available:

$ dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

I'm looking forward to a sponsor for this implementation of a classic
game!

-- 
 \   “If you go flying back through time and you see somebody else |
  `\   flying forward into the future, it's probably best to avoid eye |
_o__)   contact.” —Jack Handey |
Ben Finney 

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Bas Wijnen  writes:

> I didn't look at the package, but just a quick note:

Thanks. In the case of this package it is unusual; see its PyPI entry at
.

The game as I have packaged it is a normal command-line program: run the
command to play the game.

The Python module has additional behaviour though. It is able to play
the game by being imported in Python as a main module. That is, it
modifies the names available so that game commands can be typed as
Python syntax.

I'm not completely decided on whether that is useful in Debian, nor
whether the module name ‘adventure’ is appropriate. But I would like to
leave the option open for some publicly-available import to provide that
feature in Python. That's why I have done the work to build the separate
‘python3-adventure’ binary package.

> Similarly for adventure-common: the usual reason for splitting off
> common files is that you don't want a copy for every arch on the
> mirrors […] Or do you have a different reason for the split?

Another common reason to build a ‘foo-common’ package is that there can
be multiple possible implementations of essentially the same ‘foo’
behaviour, that could each make use of common files. Adventure is one
such variously-implemented program.

> Do you expect any package (or user) to need the data files, but not
> the game?

I am making the ‘adventure-common’ package because it could be used by
other Adventure implementations.

-- 
 \“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 

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Markus Koschany  writes:

> I had a look at your package and wanted to give you some feedback
> because of the effort you put into packaging this game.

Thank you! Are you a prospective sponsor of this package?

> The vim comments at the bottom are not allowed (syntax-wise)

Those are in end-line comments (“# foo”). My understanding is that
end-line comments with that syntax are permitted in any Debian control
files.

> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
> or CC-BY-4.0

Thanks. The package includes works I have derived from upstream works
licensed under CC By-2.0.

My understanding of the problems with CC licenses version 2.0 is in the
potential for some licensors to set impractical restrictions on
attribution. That is not the case for any of these specific works, so I
think they are DFSG-free currently.

To avoid such problems arising for the derived works, I will set the
license to CC By-4.0 in those derived works as distributed in Debian.

> You have patched the upstream sources (12 patches). In general the
> patches look O.K but I wonder if they are all necessary. Did you
> forward them upstream? Why do you think Debian should diverge from
> upstream?

Those patches turn the work into a useable stand-alone program for
Debian. Each one is submitted upstream, and I'm corresponding with the
upstream maintainer to get these changes incorporated.

> You split the game into three arch:all binary packages. I'm not
> totally convinced that this is really necessary for a game like
> python-adventure. Your current approach is not totally wrong either,
> perhaps a bit too perfectionist though. Are there strong reasons why
> you split the game into three parts?

I would think rather that conforming to Debian policy would be the
default, and a divergence would need a strong reason.

> Why don't you join the Python or Games Team and maintain
> python-adventure within one of these teams?

No particular reason. I am enjoying maintaining the code as it is.

> I found the following things with check-all-the-things:
>
> colossal-cave-adventure.desktop: found with desktop-file-validate
> error: value "adventure;advent;colossal;cave;spelunk" for locale string
> list key "Keywords" in group "Desktop Entry" does not have a semicolon
> (';') as trailing character

Thank you. I formed that field just by copying others. Is there a
specification for that field that I've missed?

> codespell --quiet-level=3
> ./adventure/advent.dat:996: KNIVE  ==> KNIFE
> ./adventure/advent.dat:1462: THRU  ==> THROUGH
>
> Might be intentional since it's the original game dialogue.

Yes, that's right; the purpose of the package is to present the original
game data and dialogue.

> pep8 --ignore W191 . found something that could be improved. Nothing
> critical but it could be forwarded upstream.
>
> pyflakes3 .
> ./adventure/__main__.py:10: 'readline' imported but unused

Thanks, I will work with upstream on code style over time.

-- 
 \  “If you don't fail at least 90 percent of the time, you're not |
  `\aiming high enough.” —Alan Kay |
_o__)  |
Ben Finney

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 17.04.2016 um 05:58 schrieb Ben Finney:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Howdy,
> 
> I am looking for a sponsor for my package ‘python-adventure’.

Hi Ben,

I had a look at your package and wanted to give you some feedback
because of the effort you put into packaging this game.

debian/copyright:

The vim comments at the bottom are not allowed (syntax-wise)
CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
or CC-BY-4.0

There are a lot of form feed characters (^L) in various debian files
which I would remove.

You have patched the upstream sources (12 patches). In general the
patches look O.K but I wonder if they are all necessary. Did you forward
them upstream? Why do you think Debian should diverge from upstream?

You split the game into three arch:all binary packages. I'm not totally
convinced that this is really necessary for a game like
python-adventure. Your current approach is not totally wrong either,
perhaps a bit too perfectionist though. Are there strong reasons why you
split the game into three parts?

Why don't you join the Python or Games Team and maintain
python-adventure within one of these teams?

I found the following things with check-all-the-things:

colossal-cave-adventure.desktop: found with desktop-file-validate
error: value "adventure;advent;colossal;cave;spelunk" for locale string
list key "Keywords" in group "Desktop Entry" does not have a semicolon
(';') as trailing character

codespell --quiet-level=3
./adventure/advent.dat:996: KNIVE  ==> KNIFE
./adventure/advent.dat:1462: THRU  ==> THROUGH

Might be intentional since it's the original game dialogue.

pep8 --ignore W191 . found something that could be improved. Nothing
critical but it could be forwarded upstream.

pyflakes3 .
./adventure/__main__.py:10: 'readline' imported but unused

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Package: sponsorship-requests
Severity: wishlist

Howdy,

I am looking for a sponsor for my package ‘python-adventure’.

Package name: python-adventure
Version : 1.4-1
Upstream Author : Brandon Rhodes 
  * URL : https://pypi.python.org/pypi/adventure/
  * License : Apache License 2.0
Section : games

Description: Colossal Cave Adventure game

Explore Colossal Cave, where others have found fortunes in
treasure and gold, though it is rumored that some who enter
are never seen again.
.
Colossal Cave Adventure (originally named “ADVENT” or
“Adventure”) is the seminal text adventure game, written by
Will Crowther and Don Woods.
.
This is a re-implementation of the “350-point” version, using
the same game content from the PDP-10 source code of the late
1970s.
.
It uses the original text exactly, and emits responses slow
enough to read as the contemporary terminal interfaces did.


It builds those binary packages:

* adventure-common - Colossal Cave Adventure game — common files
* colossal-cave-adventure - Colossal Cave Adventure game
* python3-adventure - Colossal Cave Adventure game — Python 3

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/python-adventure

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

-- 
 \ “Our task must be to free ourselves from our prison by widening |
  `\our circle of compassion to embrace all humanity and the whole |
_o__)   of nature in its beauty.” —Albert Einstein |
Ben Finney 


signature.asc
Description: PGP signature