Re: [Python-modules-team] pygame 1.9.3 upload (was: Re: pygame_1.9.3+dfsg-1_source.changes REJECTED)

[Vincent Cheng]

On Fri, Jan 27, 2017 at 1:29 AM, Dominik George  wrote:
>> Well, I do have a sponsor, but apparently, he failed to correctly
>> re-sign my prepared files yesterday ;). Will get him to re-upload
>> today.
>
> Oh, and then it was refused again because of the -doc package… now
> seriously, what's the use of *that* policy (source only uploads not
> allowed to NEW)?

Any newly added binary package will cause your package to land in the
NEW queue (regardless of whether the source package itself is new or
not). Source only uploads to NEW aren't allowed likely because it
prevents the ftpmasters from being able to check the newly introduced
binary packages for whatever criteria they have to accept/reject
packages.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] pygame 1.9.3 upload (was: Re: pygame_1.9.3+dfsg-1_source.changes REJECTED)

[Vincent Cheng]

(please keep the team's mailing list cc-ed)

On Fri, Jan 27, 2017 at 1:20 AM, Dominik George  wrote:

>> Also, would you consider targeting experimental?
>
> No, for various reasons...
>
>> I don't
>>think now is an appropriate time to attempt to push packages into
>>unstable/testing, especially since pygame is a reverse-dep for many
>>other packages.
>
> Hmm... So, I see no issues with that. Dependencies haven't changed (apart 
> from sphinx and the font package), the python3 package has the same 
> dependencies as the python2 package, and I don't see how it would impact 
> other packages badly.

Do you know whether pygame 1.9.3 introduces any backwards-incompatible
API changes? If yes, we would want to treat this like any other
library transition, i.e. defer it until the next stable release. What
I want to avoid at this point is to be uploading library packages that
break its reverse dependencies/build-dependencies and causes a bunch
of new RC bugs. Have you had a chance to verify at least some of the
packages listed below to see if they would be negatively affected by
this upload?

$ ssh mirror.ftp-master.debian.org dak rm -s testing -Rn pygame
Authenticated to mirror.ftp-master.debian.org ([5.153.231.11]:22).
Will remove the following packages from testing:

pygame | 1.9.1release+dfsg-10 | source
python-pygame | 1.9.1release+dfsg-10+b1 | mips64el
python-pygame | 1.9.1release+dfsg-10+b2 | amd64, arm64, armel, armhf,
i386, mips, mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
angrydd: angrydd
ardentryst: ardentryst
bambam: bambam
bouncy: bouncy
bubbros: bubbros
childsplay: childsplay
ffrenzy: ffrenzy
fofix-dfsg: fofix
freealchemist: freealchemist
freevial: freevial
fretsonfire: fretsonfire-game
funnyboat: funnyboat
impressive: impressive
kivy: python-kivy
krank: krank
lightyears: lightyears
magicor: magicor
monsterz: monsterz-data
oneisenough: oneisenough
opensesame: opensesame
pathological: pathological
pydxcluster: pydxcluster
pykaraoke: pykaraoke
   pykaraoke-bin
   python-pykaraoke
pyntor: pyntor
pyracerz: pyracerz
pyscrabble: pyscrabble
pysiogame: pysiogame
pysolfc: pysolfc
pysycache: pysycache
python-elements: python-elements
python-expyriment: python-expyriment
pyvnc2swf: pyvnc2swf
seahorse-adventures: seahorse-adventures
singularity: singularity
snowballz: snowballz
solarwolf: solarwolf
sugar-physics-activity: sugar-physics-activity
sugar-pippy-activity: sugar-pippy-activity
whichwayisup: whichwayisup

# Broken Build-Depends:
angrydd: python-pygame
bouncy: python-pygame
funnyboat: python-pygame
impressive: python-pygame
oggvideotools: python-pygame
opensesame: python-pygame (>= 1.8.1~)
pathological: python-pygame
psychopy: python-pygame
pykaraoke: python-pygame
python-expyriment: python-pygame (>= 1.9.1~)
seahorse-adventures: python-pygame
visionegg: python-pygame
whichwayisup: python-pygame

Dependency problem found.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] pygame 1.9.3 upload (was: Re: pygame_1.9.3+dfsg-1_source.changes REJECTED)

[Vincent Cheng]

Hi Dominik,

On Thu, Jan 26, 2017 at 4:33 PM, Debian FTP Masters
 wrote:
>
>
> Source-only uploads to NEW are not allowed.
>
> binary:python-pygame-doc is NEW.

Thanks for preparing an update for pygame!

I haven't yet had a chance to take a close look at your changes, but
just from skimming your changelog, I have a few comments. Have you had
a chance to send your newly added patches upstream? I'm mostly
concerned about the patch you added to fix various spelling issues;
it's bound to eventually become a maintenance burden if not
upstreamed. Also, would you consider targeting experimental? I don't
think now is an appropriate time to attempt to push packages into
unstable/testing, especially since pygame is a reverse-dep for many
other packages.

Unless you already have a sponsor, I can take a closer look and
sponsor your package if you'd like?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#799725: Please remove alternate build deps for gstreamer 0.10

[Vincent Cheng]

On Mon, Sep 21, 2015 at 1:31 PM, Moritz Muehlenhoff  wrote:
> Source: kivy
> Severity: normal
>
> Hi,
> kivy is using gstreamer 1.0, but still has alternate build-deps/deps
> on gstreamer 0.10:
>
> libgstreamer0.10-dev
> python-gst0.10
>
> Please remove these, gstreamer 0.10 is scheduled for removal from
> the archive.

Is it not possible to keep these alternate build-deps in d/control to
e.g. ease backporting? My understanding is that the dependency
resolver that buildds use will only look at the first build-dep and
disregard alternate build-deps.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] pygame and python 3

[Vincent Cheng]

Hi Lenard,

On Mon, May 4, 2015 at 5:47 PM, Lenard Lindstrom le...@telus.net wrote:
 Hi Vincent,


 On 15-04-29 03:34 AM, Vincent Cheng wrote:

 Hi Lenard,

 First off, thanks for all your work on pygame!

 On Thu, Apr 16, 2015 at 9:26 PM, Lenard Lindstrom le...@telus.net wrote:

 Hi,

 Pygame supported python3 since before version 1.9.0 in 2009. All Pygame
 code
 is written to work with either Python 2.x or 3.x. So building Pygame for
 python3 is the same as for python2. Just use python3 setup.py build
 instead of python setup.py build. Installation is also the same. For
 Pygame 1.9.2, which I
 test against Python 2.7 and 3.4 on i386 Linux Mint, python3 support is
 complete.

 So if a stable Pygame package already exists for python2, adapting it for
 python3 should be straight forward. Let me know if some Pygame bug causes
 problems and I will deal with it promptly.

 Thanks for the effort in keeping Pygame in Linux.

 Just to confirm, does the latest stable pygame release (1.9.1)
 actually support python3? Because back when I initially prepared
 python3 pygame 1.9.1 packages for Debian a few years back, I recall
 that I was able to build it, but just importing pygame with a python3
 interpreter resulted in an error. 1.9.2pre works great though.

 Is there a rough estimate of when 1.9.2 is expected to be released, by
 the way, or is it more along the lines of it'll be done when it's
 done? ;)

 Regards,
 Vincent

 I checked Pygame 1.9.1 with Python 3.4 and see where the problem is. Pygame
 1.9.1 was built and tested on an earlier Python 3 release. Basically, the
 early effort on Python 3 went towards the language upgrade. The C api was
 slower to follow. So Python 3 is basically a moving target for extension
 module developers. I suppose Pygame 1.9.1 could be updated for Python 3.4,
 but is it worth it?

 For practical purposes, Pygame 1.9.2 is in the beta stage of testing. I see
 no new features or rewrites happening before the formal release, just bug
 fixes. Basically the delay in release is one of logistics, getting a new
 automated build site for Windows and OS X. But for Linux, specifically Linux
 Mint 17.1 Cinnamon 32-bit (Ubuntu 14.04.2 LTS, Trusty Tahr), it passes the
 unit tests. Other than some document editing, I think it is as ready as it
 will ever be for a Linux release. As for the date of the formal release,
 that is up to the project administrator, René Dudfield.

Thanks for the explanation! I don't follow upstream development
closely, and I was unsure how close to release 1.9.2 actually is. In
that case, would you consider 1.9.2 as of the last commit on bitbucket
(or any specific commit if you want to suggest one, I suppose) ready
for inclusion in a stable release of Debian/Ubuntu? If so, I'd be
happy to upload 1.9.2 to unstable rather than just experimental.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] pygame and python 3

[Vincent Cheng]

Hi,

pygame maintainer here, sorry for the delayed reply!

On Thu, Apr 16, 2015 at 6:47 PM, peter green plugw...@p10link.net wrote:
 One python package used heavilly in the raspberry pi community is pygame.
 Unfortunately the package hasn't had an upstream stable release since 2009
 and the upstream stable release doesn't support python3.

 Currently sid has the latest upstream stable release and no python3-pygame
 package. Experimental does have a python3-pygame package but I have not
 tested it (i'm not really a python guy myself).

 Thoughts? has anyone tried the pythong3-pygame package in experimental?
 should it be pushed to unstable (after jessie release)? are there better
 alternatives to pygame?

Yes, I've tested the python3-pygame package (briefly) prior to
uploading it to experimental, and it is indeed functional. The reason
it's in experimental and not unstable is because I'd rather not upload
a snapshot of upstream svn/hg to sid (I have no idea when upstream is
planning to release 1.9.2). When 1.9.2 is released, I'll push the
current packaging in experimental to sid.

There's also an upstream bug report about python3 support in the
Debian package [1], although there's really nothing new there.

Regards,
Vincent

[1] 
https://bitbucket.org/pygame/pygame/issue/221/debian-python-3-package-for-192

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#781355: Bug#781355: python-docker: New upstream version

[Vincent Cheng]

On Tue, Mar 31, 2015 at 11:41 AM, Tianon Gravi admwig...@gmail.com wrote:

 The first is that I don't know the proper branch format for
 experimental in debian-python's SVN tree (it looks like it's just keep
 going forward in trunk and create a branch when/if a new sid/jessie
 upload is required, but I can't find any documentation to confirm or
 deny that).

I'm unsure myself if there's supposed to be some kind of convention
for branching for different releases; I usually track sid in trunk and
have a separate directory in branches for experimental or backports
branches, etc. Whatever works for you, I suppose.

Of course, this will all be moot once (if?) we migrate from svn to git, right?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] pygame and python 3

[Vincent Cheng]

Hi Lenard,

First off, thanks for all your work on pygame!

On Thu, Apr 16, 2015 at 9:26 PM, Lenard Lindstrom le...@telus.net wrote:
 Hi,

 Pygame supported python3 since before version 1.9.0 in 2009. All Pygame code
 is written to work with either Python 2.x or 3.x. So building Pygame for
 python3 is the same as for python2. Just use python3 setup.py build
 instead of python setup.py build. Installation is also the same. For
 Pygame 1.9.2, which I
 test against Python 2.7 and 3.4 on i386 Linux Mint, python3 support is
 complete.

 So if a stable Pygame package already exists for python2, adapting it for
 python3 should be straight forward. Let me know if some Pygame bug causes
 problems and I will deal with it promptly.

 Thanks for the effort in keeping Pygame in Linux.

Just to confirm, does the latest stable pygame release (1.9.1)
actually support python3? Because back when I initially prepared
python3 pygame 1.9.1 packages for Debian a few years back, I recall
that I was able to build it, but just importing pygame with a python3
interpreter resulted in an error. 1.9.2pre works great though.

Is there a rough estimate of when 1.9.2 is expected to be released, by
the way, or is it more along the lines of it'll be done when it's
done? ;)

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#779319: Bug#779319: python-pygame: Package python-pygame 1.9.2 released 12-12-14

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi,

On Thu, Feb 26, 2015 at 5:28 PM, shirish शिरीष shirisha...@gmail.com wrote:
 Package: python-pygame
 Version: 1.9.2~pre~r3348-1
 Severity: wishlist

 Dear Maintainer,
 Python-pygame was released on 12th December 2014. Can we have that in
 experimental rather than the pre version one which we have now.

The newest released version of pygame on either pygame.org [1] or the
official bitbucket repo [2] is still 1.9.1; there was no newer release
on Dec. 12, 2014, AFAIK. If there was, can you please provide a link?

Regards,
Vincent

[1] http://pygame.org/download.shtml
[2] https://bitbucket.org/pygame/pygame

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#741834: Bug#741834: patch to add LC_ALL=C

[Vincent Cheng]

Control: tag -1 + pending

On Mon, Nov 10, 2014 at 1:46 PM, Thomas Viehmann t...@beamnet.de wrote:
 tag 741834 +patch
 thank you

 Hi,

 this is a tiny patch to address the test failures.

Thanks for the patch Thomas! Will upload soon.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#749321: Bug#749321: reverse dependency of python-pypdf and ITP of python-pypdf2

[Vincent Cheng]

On Thu, Sep 18, 2014 at 9:09 AM, Elena ``of Valhalla''
valha...@trueelena.org wrote:
 I've noticed that the current python-pypdf package has migrated to
 PyPDF2 (thus breaking all of its reverse dependencies in sid):
 should the updated/converted rev-dep depend on python-pypdf = 1.23-1
 or python-pypdf2?

 How is this going to be managed?

Assuming that pypdf and pypdf2 have compatible APIs, another option
would be to simply patch pdfshuffler with something like:

try:
import pypdf
except ImportError:
import pypdf2

...which would avoid having the need for restricting the dependency on
python-pypdf to specific versions.

Adding pypdf2 maintainer to cc list...how compatible is the pypdf2
fork with the original pypdf, and how much work would migrating
applications that depend on the older pypdf to the forked version?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#762186: python-pypdf: Unexpectedly breaks existing programs on update

[Vincent Cheng]

Dear maintainer,

On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi
valhall...@trueelena.org wrote:
 Package: python-pypdf
 Version: 1.23-1
 Severity: grave
 Justification: renders package unusable

 Dear Maintainer,

 updating python-pypdf from 1.13 to 1.23 breaks every existing script
 that use this module with an ImportError: No module named pyPdf.

 Changing pyPdf to PyPDF2 everywhere in the scripts allows to use
 the new version, but in the update there was no hint that this
 change was needed.

 Expecially if this happens during an update between stable versions
 this will break existing deployments of custom programs, causing
 lots of pain.

Worse still is the fact that currently in sid, both src:python-pypdf
and src:pypdf2 build binary package python-pypdf. One of the above
source packages must stop building python-pypdf, and since pypdf2 is
the one that's breaking reverse dependencies, I would very much
appreciate it this is initially done in src:pypdf2.

The next time you package a fork as a new source package, please don't
immediately hijack the other package's namespace, and give a heads up
to maintainers of your library's reverse deps so that they have time
to react. It'd be really nice if you could also coordinate an informal
transition and offer patches/NMUs to fix up pypdf's reverse
dependencies.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#762186: Bug#762186: python-pypdf: Unexpectedly breaks existing programs on update

[Vincent Cheng]

On Sun, Sep 21, 2014 at 2:54 AM, Vincent Cheng vch...@debian.org wrote:
 Dear maintainer,

 On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi
 valhall...@trueelena.org wrote:
 Package: python-pypdf
 Version: 1.23-1
 Severity: grave
 Justification: renders package unusable

 Dear Maintainer,

 updating python-pypdf from 1.13 to 1.23 breaks every existing script
 that use this module with an ImportError: No module named pyPdf.

 Changing pyPdf to PyPDF2 everywhere in the scripts allows to use
 the new version, but in the update there was no hint that this
 change was needed.

 Expecially if this happens during an update between stable versions
 this will break existing deployments of custom programs, causing
 lots of pain.

 Worse still is the fact that currently in sid, both src:python-pypdf
 and src:pypdf2 build binary package python-pypdf. One of the above
 source packages must stop building python-pypdf, and since pypdf2 is
 the one that's breaking reverse dependencies, I would very much
 appreciate it this is initially done in src:pypdf2.

 The next time you package a fork as a new source package, please don't
 immediately hijack the other package's namespace, and give a heads up
 to maintainers of your library's reverse deps so that they have time
 to react. It'd be really nice if you could also coordinate an informal
 transition and offer patches/NMUs to fix up pypdf's reverse
 dependencies.


Looks like the BTS is a bit confused over who the maintainer for
src:pypdf2 is, so forwarding this directly to its maintainer.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743685: urwid: FTBFS: test failures

[Vincent Cheng]

reopen 743685
thanks

On Fri, May 16, 2014 at 2:59 AM, Vincent Cheng vch...@debian.org wrote:
 On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic
 dejan.latino...@imgtec.com wrote:


 Debian patch that removes test_vterm.py
 is attached.

 Vincent, could you please include this patch
 in new Debian package version?

 Thanks, I'll take a look at this asap.

 Ian: it doesn't have to be fixed in upstream right now, no, but it'd
 be nice to have those tests removed (or fixed?) upstream as well so we
 don't end up carrying this patch in Debian forever.


Uploaded...but it looks like it's failing to build on mips now [1];
looks like the same test
(urwid.tests.test_event_loops.TwistedEventLoopTest) that failed wth
urwid/1.2.0-1. The fact that these tests don't consistently fail on
mips(el) is rather annoying. Does anyone know what's going on?

Regards,
Vincent

[1] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=mipsver=1.2.1-2stamp=1400413671

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Migrate from PyPDF to PyPDF2

[Vincent Cheng]

Hi Amr,

On Sun, May 18, 2014 at 5:28 AM, Amr Ibrahim amribrahim1...@hotmail.com wrote:
 Dear maintainers,

 PyPDF project is dead upstream http://pybrary.net/pyPdf/ and is superseded
 by PyPDF2 https://github.com/mstamy2/PyPDF2. Would you consider retiring
 python-pypdf http://packages.qa.debian.org/p/python-pypdf.html and migrate
 to PyPDF2?

Please file a (wishlist) bug report against python-pypdf with your
rationale (and please send future bug reports directly to the bug
tracker, not this mailing list).

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743685: urwid: FTBFS: test failures

[Vincent Cheng]

On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic
dejan.latino...@imgtec.com wrote:


 Debian patch that removes test_vterm.py
 is attached.

 Vincent, could you please include this patch
 in new Debian package version?

Thanks, I'll take a look at this asap.

Ian: it doesn't have to be fixed in upstream right now, no, but it'd
be nice to have those tests removed (or fixed?) upstream as well so we
don't end up carrying this patch in Debian forever.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#747567: Bug#747567: python3-pygame doesn't contain Pygame's documentation

[Vincent Cheng]

On Sun, May 11, 2014 at 8:07 AM, Jonathan Ballet j...@multani.info wrote:
 On Fri, May 09, 2014 at 07:57:33PM -0700, Vincent Cheng wrote:
 V Hi Jonathan,

 On Fri, May 9, 2014 at 7:48 PM, Jonathan Ballet j...@multani.info wrote:
  Package: python3-pygame
  Version: 1.9.2~pre~r3348-1
  Severity: normal
 
  Dear Maintainer,
 
  at the moment, python3-pygame only contains tutorials but
  not the reference documentation (API, etc.)
  However, python-pygame does contain everything.
 
  danio:~$ dpkg -L python3-pygame | grep html
  /usr/lib/python3/dist-packages/pygame/install.html
  /usr/lib/python3/dist-packages/pygame/readme.html
  /usr/lib/python3/dist-packages/pygame/docs/logos.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/MoveIt.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/ImportInit.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/DisplayModes.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/camera/CameraIntro.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games6.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games5.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games4.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games3.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games2.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/tom/MakeGames.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/surfarray/SurfarrayIntro.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/intro/intro.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/chimp/chimp.py.html
  /usr/lib/python3/dist-packages/pygame/docs/tut/chimp/ChimpLineByLine.html
  /usr/lib/python3/dist-packages/pygame/docs/ref/pygame_cursor.html
  /usr/lib/python3/dist-packages/pygame/docs/ref/index.html
  danio:~$ dpkg -L python-pygame | grep html
  /usr/share/doc/python-pygame/logos.html
  /usr/share/doc/python-pygame/tut/newbieguide.html
  [...]
  /usr/share/doc/python-pygame/tut/MoveIt.html
  /usr/share/doc/python-pygame/ref/locals.html
  /usr/share/doc/python-pygame/ref/mixer.html
  /usr/share/doc/python-pygame/ref/tests.html
  /usr/share/doc/python-pygame/ref/draw.html
  /usr/share/doc/python-pygame/ref/mouse.html
  /usr/share/doc/python-pygame/ref/movie.html
  /usr/share/doc/python-pygame/ref/surfarray.html
  /usr/share/doc/python-pygame/ref/cdrom.html
  [...]
 
  Is it possible to provide the documentation without having to install
  both packages?
 
  (On a side note, this documentation should probably be moved to
  /usr/share/doc instead of being shipped in the Python package
  directory.)

 It's on my todo list (along with other things like migrating to
 pybuild and running the test suite with xvfb, etc.), but I doubt I'll
 have time to get around to this anytime soon. Anyways, patches welcome
 as always. :)

 I would love to help, but as much as I've been using Debian, it seems my
 head can't fit how to properly set up, build and/or hack on Debian
 packaging :/
 If you ever make a patch (or at worst, several patches) to solve this
 issue, I can try to have another look and try to understand this, once
 again.

If you're in need of a good practical Debian packaging guide, I highly
recommend Lucas Nussbaum's packaging-tutorial (which you can apt-get
install, or fetch online [1]). Some Python specific packaging tips are
covered on the Debian wiki [2] as well. You're also more than welcome
to drop by #debian-mentors and #debian-python on OFTC if you're still
struggling with packaging-related issues.

Regards,
Vincent

[1] 
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
[2] https://wiki.debian.org/Python/LibraryStyleGuide

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#747567: Bug#747567: python3-pygame doesn't contain Pygame's documentation

[Vincent Cheng]

On Sun, May 11, 2014 at 10:36 PM, Jonathan Ballet j...@multani.info wrote:
 On Sun, May 11, 2014 at 09:25:27PM -0700, Vincent Cheng wrote:
 
  It's on my todo list (along with other things like migrating to
  pybuild and running the test suite with xvfb, etc.), but I doubt I'll
  have time to get around to this anytime soon. Anyways, patches welcome
  as always. :)
 
  I would love to help, but as much as I've been using Debian, it seems my
  head can't fit how to properly set up, build and/or hack on Debian
  packaging :/
  If you ever make a patch (or at worst, several patches) to solve this
  issue, I can try to have another look and try to understand this, once
  again.

 If you're in need of a good practical Debian packaging guide, I highly
 recommend Lucas Nussbaum's packaging-tutorial (which you can apt-get
 install, or fetch online [1]). Some Python specific packaging tips are
 covered on the Debian wiki [2] as well. You're also more than welcome
 to drop by #debian-mentors and #debian-python on OFTC if you're still
 struggling with packaging-related issues.

 Regards,
 Vincent

 [1] 
 https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
 [2] https://wiki.debian.org/Python/LibraryStyleGuide

 Thank you for the links. I will have a look and try to propose a patch
 when I will time, patience, and motivation to dive into this again.
 Hopefully, by then, the package will be out of experimental and I would
 be able to install the build dependencies without spending 50 minutes to
 try to do so (which I gave up to.)


I suggest using a clean chroot for building packages, e.g. using
pbuilder [1], cowbuilder, or sbuild. This is required if you're
actually uploading packages to the archive, and the buildds also build
packages in clean, disposable chroots, to avoid contamination by your
local build environment. It also makes it far easier to automatically
install the correct build-deps, without messing up your local build
environment.

I'm waiting for a new upstream release (1.9.2?) before uploading
pygame to unstable (python3 support in pygame isn't mature enough with
1.9.1).

Regards,
Vincent

[1] http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#747567: Bug#747567: python3-pygame doesn't contain Pygame's documentation

[Vincent Cheng]

Hi Jonathan,

On Fri, May 9, 2014 at 7:48 PM, Jonathan Ballet j...@multani.info wrote:
 Package: python3-pygame
 Version: 1.9.2~pre~r3348-1
 Severity: normal

 Dear Maintainer,

 at the moment, python3-pygame only contains tutorials but
 not the reference documentation (API, etc.)
 However, python-pygame does contain everything.

 danio:~$ dpkg -L python3-pygame | grep html
 /usr/lib/python3/dist-packages/pygame/install.html
 /usr/lib/python3/dist-packages/pygame/readme.html
 /usr/lib/python3/dist-packages/pygame/docs/logos.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/MoveIt.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/ImportInit.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/DisplayModes.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/camera/CameraIntro.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games6.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games5.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games4.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games3.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/games2.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/tom/MakeGames.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/surfarray/SurfarrayIntro.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/intro/intro.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/chimp/chimp.py.html
 /usr/lib/python3/dist-packages/pygame/docs/tut/chimp/ChimpLineByLine.html
 /usr/lib/python3/dist-packages/pygame/docs/ref/pygame_cursor.html
 /usr/lib/python3/dist-packages/pygame/docs/ref/index.html
 danio:~$ dpkg -L python-pygame | grep html
 /usr/share/doc/python-pygame/logos.html
 /usr/share/doc/python-pygame/tut/newbieguide.html
 [...]
 /usr/share/doc/python-pygame/tut/MoveIt.html
 /usr/share/doc/python-pygame/ref/locals.html
 /usr/share/doc/python-pygame/ref/mixer.html
 /usr/share/doc/python-pygame/ref/tests.html
 /usr/share/doc/python-pygame/ref/draw.html
 /usr/share/doc/python-pygame/ref/mouse.html
 /usr/share/doc/python-pygame/ref/movie.html
 /usr/share/doc/python-pygame/ref/surfarray.html
 /usr/share/doc/python-pygame/ref/cdrom.html
 [...]

 Is it possible to provide the documentation without having to install
 both packages?

 (On a side note, this documentation should probably be moved to
 /usr/share/doc instead of being shipped in the Python package
 directory.)

It's on my todo list (along with other things like migrating to
pybuild and running the test suite with xvfb, etc.), but I doubt I'll
have time to get around to this anytime soon. Anyways, patches welcome
as always. :)

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743685: FTBFS: test failures

[Vincent Cheng]

Source: urwid
Version: 1.2.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

urwid 1.2.1-1 currently FTBFS on i386 and mipsel according to the buildd [1]
logs. Note that the test suite is now run against all python2 and python3
versions supported in sid (rather than just python2, as was the case with
previous versions of urwid); the test failure on i386 is a new one, and only
happens with python3.


i386 [2]:

==
FAIL: test_linefeed (urwid.tests.test_vterm.TermTest)
--
Traceback (most recent call last):
  File /«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py, 
line 128, in test_linefeed
self.expect('hello\nworld')
  File /«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py, 
line 120, in expect
self.assertEqual(got, what, desc)
AssertionError: b'hello' != b'hello\nworld' : Expected:
b'hello\nworld'
Got:
b'hello'

--
Ran 280 tests in 0.758s

FAILED (failures=1)


mipsel [3]:

==
FAIL: test_run (urwid.tests.test_event_loops.TwistedEventLoopTest)
--
Traceback (most recent call last):
  File /«PKGBUILDDIR»/urwid/tests/test_event_loops.py, line 128, in test_run
self.assertIn(da, out)
AssertionError: 'da' not found in ['waiting', 'hello', 'clean exit']

--
Ran 289 tests in 6.329s

FAILED (failures=1)


[1] https://buildd.debian.org/status/package.php?p=urwid
[2] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=i386ver=1.2.1-1stamp=1396632579
[3] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=mipselver=1.2.1-1stamp=1396648217

Regards,
Vincent

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-5-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743118: Bug#743118: urwid: FTBFS: Tests failures

[Vincent Cheng]

On Fri, Apr 4, 2014 at 9:00 AM, Ian Ward i...@excess.org wrote:
 On Mon, Mar 31, 2014 at 2:28 AM, Vincent Cheng vch...@debian.org wrote:
 I didn't come across this test failure when I built and uploaded urwid
 on my amd64 laptop, but the mips and sparc buildds are also choking on
 the same test case according to the build logs [1]; it's also
 preventing the package from migrating to testing. An upload to
 fix/skip this test would certainly be appreciated.

 Just released 1.2.1 with a fix

Uploaded, thanks!

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743118: Bug#743118: urwid: FTBFS: Tests failures

[Vincent Cheng]

On Sun, Mar 30, 2014 at 5:31 PM, Ian Ward i...@excess.org wrote:
 On Sun, Mar 30, 2014 at 12:56 PM, David Suárez david.sephi...@gmail.com 
 wrote:
 AssertionError: Lists differ: [u'da', u'ta', 'waiting', 'hel... != ['da', 
 'ta', 'waiting', 'hello...

 This is a test that is just being a little too strict. I'm planning to
 remove or fix this test as it doesn't reflect a failure in any real
 programs.

 Hopefully I'll have time to release a fix soon. We could also add a
 patch to skip this test in the debian packaging for now.

I didn't come across this test failure when I built and uploaded urwid
on my amd64 laptop, but the mips and sparc buildds are also choking on
the same test case according to the build logs [1]; it's also
preventing the package from migrating to testing. An upload to
fix/skip this test would certainly be appreciated.

Regards,
Vincent

[1] https://buildd.debian.org/status/package.php?p=urwid

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#711807: zsi is marked for autoremoval from testing

[Vincent Cheng]

Hi Paul,

On Sun, Mar 30, 2014 at 9:40 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 zsi 2.1~a1-3 is marked for autoremoval from testing on 2014-04-29

 It is affected by these RC bugs:
 711807: zsi: FTBFS: mv: cannot stat 
 './/debian/patched/bogus-shebang-remove.dpatch.new'


I took a quick look at the above bug and tried to reproduce it in an
up-to-date sid chroot (using pbuilder), and like David, I'm unable to
reproduce this either. Paul, since you're the original bug reporter,
could you perhaps take a second look at this, and if it's still
reproducible, let us know how?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#743199: queuelib dependency required

[Vincent Cheng]

On Mon, Mar 31, 2014 at 5:13 AM, Kumar Appaiah
a.ku...@alumni.iitm.ac.in wrote:

 ImportError: Error loading object 'scrapy.core.scheduler.Scheduler': No 
 module named queuelib

Oops, sorry! I've just uploaded python-queuelib to NEW [1], and once
it gets accepted I'll add it as a dependency for python-scrapy.

Regards,
Vincent

[1] https://ftp-master.debian.org/new/python-queuelib_1.1.1-1.html

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#733828: Bug#733828: Update to python3-urwid?

[Vincent Cheng]

On Tue, Mar 11, 2014 at 6:51 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
 tags 708305 + fixed-upstream
 kthxbye

 It would be really nice if you would update the package to a new version
 of urwid.  The new version fixes #708305, which routinely causes a
 program I've written to abort and lose all of the data in its working
 set.  This is very frustrating for the users of said program.

 It's not clear to me if this package is still being maintained, since I
 haven't gotten any response whatsoever to any of the three bugs I've
 filed.  If you're not still interested in maintaining this package,
 please orphan it so that users don't get a false impression that it's
 maintained.

This is a team-maintained package. You're more than welcome to join
the Debian Python Modules Team and help out with this package if you'd
like.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Hand pygame maintainership over to Debian Python Modules Team?

[Vincent Cheng]

Hi Andrea and Ed,

Would it be ok with you if we were to set pygame's maintainer to the
Debian Python Modules Team
python-modules-team@lists.alioth.debian.org? I'm personally in
favour of moving as many packages as possible over to team
maintainership, and pygame is important enough that I think it
deserves to have more people taking care of it (and besides, team
uploads are easier to do than NMUs).

Ed: you're currently pygame's maintainer, but even though I've sent
you multiple private emails (and I and Andreas cc'ed you in our
conversations) since I took up de facto maintainership of pygame back
in June of 2011, I've never heard back from you at all. Not to mention
that a quick search through Debian's mailing lists seems to indicate
that you were last seen around 2002...are you still active in Debian,
and would you still like to take part in maintaining pygame?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#700782: Bug#700997: Bug#700995: Solving directory vs. symlink conflict: /usr/include/python3.2

[Vincent Cheng]

[Adding python3.2's maintainer, as well as #701071 and #701045, to cc:]

On Sat, Feb 23, 2013 at 3:55 AM, Julien Cristau jcris...@debian.org wrote:
 On Fri, Feb 22, 2013 at 09:32:45 +0100, Andreas Beckmann wrote:

 On 2013-02-22 08:51, Vincent Cheng closed #700997:
 * [...] distutils in Debian now
   takes care of installing headers into the right location as of 
  python3.2
   (= 3.2.3-7), so add a build-dep on that [...]

 Maybe a solution for the other packages, too.

 Sounds like all of these bugs should be reassigned to python3.2-dev
 then, and closed?

Someone first has to manually check that these packages use distutils
(look for something along the lines of python setup.py install
--install-layout=deb in debian/rules) and doesn't move around stuff
manually in debian/rules or elsewhere; binNMUs should then be safe
(although I still think source uploads to get python3.2-dev (=
3.2.3-7) added to build-depends of each of these packages should be
done). I'll get around to looking at the rest of these bugs
(eventually), as they should be easy to fix in the above holds true.

Andreas, if I understood your analysis of #700782 correctly, the
hypothetical situation that an user unpacks any of the affected
packages (or an older version prior to being rebuilt against
python3.2-dev (= 3.2.3-7)) before python3.2-dev to trigger this bug
still exists, right? In that case, python3.2-dev should probably still
add a Conflicts: relationship with all of the affected packages; I
wonder if Matthias might have anything to say about this?

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#700782: Bug#700997: Bug#700995: Solving directory vs. symlink conflict: /usr/include/python3.2

[Vincent Cheng]

On Sun, Feb 24, 2013 at 4:12 AM, Julien Cristau jcris...@debian.org wrote:
 On Sun, Feb 24, 2013 at 03:42:06 -0800, Vincent Cheng wrote:

 Andreas, if I understood your analysis of #700782 correctly, the
 hypothetical situation that an user unpacks any of the affected
 packages (or an older version prior to being rebuilt against
 python3.2-dev (= 3.2.3-7)) before python3.2-dev to trigger this bug
 still exists, right? In that case, python3.2-dev should probably still
 add a Conflicts: relationship with all of the affected packages; I
 wonder if Matthias might have anything to say about this?

 Very much NAK to adding conflicts against packages at this stage,
 especially for issues that don't affect the upgrade path from squeeze
 (where there's no python3.2).


Fair enough, I'll leave it to your discretion whether to tag #701071
and #701045 as wheezy-ignore, or just close them altogether.

The rest of the bugs need at least a binNMU (rebuild against the fixed
python3.2-dev package) before they can be closed.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#700994: python3-numpy: directory vs. symlink conflict: /usr/include/python3.2

[Vincent Cheng]

# see following explanation
tag 700994 + patch
thanks

Hi,

while looking into #700782, we discovered that there is a symlink
vs. directory conflict between python3-numpy and python3.2-dev:
  python3.2-dev has /usr/include/python3.2 - python3.2mu
  python3-numpy ships /usr/include/python3.2/numpy
Please move the linked shipped as python3.2/numpy to python3.2mu.

FYI, from python3.2's changelog:

 python3.2 (3.2.3-7) unstable; urgency=low
 .
   * distutils: Append the abiflags to the python include dir.

So this bug should be fixed simply by adding a build-dep on
python3.2-dev (= 3.2.3-7), similar to how #700996 and #700997 were
fixed.

Regards,
Vincent

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team