Re: [Python-modules-team] pygame 1.9.3 upload (was: Re: pygame_1.9.3+dfsg-1_source.changes REJECTED)
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)
(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)
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
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
Hi Lenard, On Mon, May 4, 2015 at 5:47 PM, Lenard Lindstrom 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 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
[Python-modules-team] Bug#781355: Bug#781355: python-docker: New upstream version
On Tue, Mar 31, 2015 at 11:41 AM, Tianon Gravi 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
Hi Lenard, First off, thanks for all your work on pygame! On Thu, Apr 16, 2015 at 9:26 PM, Lenard Lindstrom 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
Re: [Python-modules-team] pygame and python 3
Hi, pygame maintainer here, sorry for the delayed reply! On Thu, Apr 16, 2015 at 6:47 PM, peter green 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#779319: Bug#779319: python-pygame: Package python-pygame 1.9.2 released 12-12-14
Control: tag -1 + moreinfo Hi, On Thu, Feb 26, 2015 at 5:28 PM, shirish शिरीष 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
Control: tag -1 + pending On Mon, Nov 10, 2014 at 1:46 PM, Thomas Viehmann 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#762186: Bug#762186: python-pypdf: Unexpectedly breaks existing programs on update
On Sun, Sep 21, 2014 at 2:54 AM, Vincent Cheng wrote: > Dear maintainer, > > On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi > 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#762186: python-pypdf: Unexpectedly breaks existing programs on update
Dear maintainer, On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi 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#749321: Bug#749321: reverse dependency of python-pypdf and ITP of python-pypdf2
On Thu, Sep 18, 2014 at 9:09 AM, Elena ``of Valhalla'' 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
Re: [Python-modules-team] Migrate from PyPDF to PyPDF2
Hi Amr, On Sun, May 18, 2014 at 5:28 AM, Amr Ibrahim 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
reopen 743685 thanks On Fri, May 16, 2014 at 2:59 AM, Vincent Cheng wrote: > On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic > 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=urwid&arch=mips&ver=1.2.1-2&stamp=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
[Python-modules-team] Bug#743685: urwid: FTBFS: test failures
On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic 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
On Sun, May 11, 2014 at 10:36 PM, Jonathan Ballet 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
On Sun, May 11, 2014 at 8:07 AM, Jonathan Ballet 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 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
Hi Jonathan, On Fri, May 9, 2014 at 7:48 PM, Jonathan Ballet 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
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=urwid&arch=i386&ver=1.2.1-1&stamp=1396632579 [3] https://buildd.debian.org/status/fetch.php?pkg=urwid&arch=mipsel&ver=1.2.1-1&stamp=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
On Fri, Apr 4, 2014 at 9:00 AM, Ian Ward wrote: > On Mon, Mar 31, 2014 at 2:28 AM, Vincent Cheng 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#743199: queuelib dependency required
On Mon, Mar 31, 2014 at 5:13 AM, Kumar Appaiah 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#711807: zsi is marked for autoremoval from testing
Hi Paul, On Sun, Mar 30, 2014 at 9:40 PM, Debian testing autoremoval watch 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#743118: Bug#743118: urwid: FTBFS: Tests failures
On Sun, Mar 30, 2014 at 5:31 PM, Ian Ward wrote: > On Sun, Mar 30, 2014 at 12:56 PM, David Suárez > 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#733828: Bug#733828: Update to python3-urwid?
On Tue, Mar 11, 2014 at 6:51 PM, brian m. carlson 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?
Hi Andrea and Ed, Would it be ok with you if we were to set pygame's maintainer to the Debian Python Modules Team ? 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
On Sun, Feb 24, 2013 at 4:12 AM, Julien Cristau 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#700782: Bug#700997: Bug#700995: Solving directory vs. symlink conflict: /usr/include/python3.2
[Adding python3.2's maintainer, as well as #701071 and #701045, to cc:] On Sat, Feb 23, 2013 at 3:55 AM, Julien Cristau 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#700994: python3-numpy: directory vs. symlink conflict: /usr/include/python3.2
# 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