[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request to Join Project Python Modules Packaging Team from Vincent Cheng (vincentc-guest)



On Sun, May 19, 2013 at 7:09 AM, Jakub Wilk <jwilk@debian.org> wrote:
> * Vincent Cheng <vincentc1208@gmail.com>, 2013-05-18, 01:50:
>
>> I'm currently a DM (DDPO profile here [1]), and I'd like to join the DPMT
>> and PAPT to move some of my self-maintained packages (pygame is one of them)
>> into team maintainership. Most of my other packages are also team-maintained
>> (I'd estimate half of my packages to be in the Debian Games team, in fact).
>
>
> Welcome to the team!

Thanks! :)

> Here's my review of pygame_1.9.2~pre~r3189-2:
>
> You have "python3.2-dev (>= 3.2.3-7)" in Build-Depends. Could you put
> "python3.2-dev (<< 3.2.3-7)" in Build-Conflicts instead? That should have
> the same effect, while making it easier to remove python3.2 from the archive
> in the future.

Fixed.

> What is libjs-sphinxdoc in Depends for? The changelog says "Add depends on
> libjs-sphinxdoc and replace embedded js libraries with symlinks in
> debian/rules", but I don't see anything relevant in debian/rules. But
> anyway, should probably put ${sphinxdoc:Depends} in Depends and use
> dh_shpinxdoc instead of replacing this stuff manually.

Errr...I remember that at one point lintian complained about embedded
js libraries (jquery IIRC), but they don't seem to be present anymore
with the latest hg snapshot. I'll have to take a closer look at
this...

> I advocate against using ${python:Provides}:
> http://lists.debian.org/20110324164804.GA5919@jwilk.net

Fixed.

> It's time to drop Replaces/Conflict with python2.{3,4}-pygame.

Fixed.

> “for” loops in debian/rules lack “set -e”; see Policy §4.6.

Fixed.

> Please honour DEB_BUILD_OPTIONS=nocheck.
>
> Please run tests with all supported Python versions, not only the default
> one.
>
> Is there a reason test failures are ignored?

Some of the tests require X and a display adapter, hence me being lazy
and deciding to just skip tests altogether. I didn't know about xvfb
until just now however, so I'll definitely take another look at it.

> You might want to try run the tests under xvfb. Hopefully that should allow
> running more of them than currently.
>
> You never call "setup.py build" with python3.X, so building Python 3.X
> modules takes place only when you call "setup.py install", that is in
> binary* targets, with (pseudo)root privileges. This is something your should
> avoid.

Fixed.

> /usr/share/pyshared/pygame/docs: AFAICS this is the very same documentation
> as in /usr/share/doc/python-pygames/. Are two copies really needed?
>
> /usr/share/pyshared/examples: examples normally belong to
> /usr/share/doc/$package/examples/.
>
> Documentation and examples are quite big, and they are included in both
> binary packages. Maybe it would make sense to move them to a separate
> documentation package?

Definitely, that's on my TODO list for pygame...which has now just
grown much longer ;)

> /usr/share/pyshared/tests: do tests make sense in the binary package? I
> wouldn't install them.
>
> /usr/share/pyshared/pygame/LGPL: Lintian should have emitted
> extra-license-file.
>
> I see you overrode image-file-in-usr-lib, but "This is where distutils
> installs everything" is a poor excuse. :)

Is there any easy workaround for this? Admittedly I was being a bit
lazy here as well, but pygame's source doesn't contain that many
images and I didn't think it was worth adding more complexity to the
packaging in order to appease lintian.

> test/test_utils/unittest.py is an embedded copy of stdlib module. Please
> make sure it's not used at build time, and that it's not installed into
> binary packages.
>
> Please regenerate src/pypm.c from src/pypm.pyx at build time.
>
> docs/reST/ref/code_examples/joystick_calls.py uses "print" as method name.
> You can't do that in Python 2.X (unless you import print_function from
> __future__).
>

As for everything else, I'll fix each issue one by one when I have
some spare time. In the meantime, I've moved the packaging over from
collab-maint to the team's repository; any help would definitely be
appreciated.

Thanks for the very thorough review! :)

Regards,
Vincent


Reply to: