On 04/01/12 01:11 AM, Vincent Cheng wrote:
On Tue, Jan 3, 2012 at 4:02 AM, A Mennucc<mennu...@debian.org> wrote:
hi,
I compiled a new pygame, with MMX enabled ,
(and w/o the portmidi build-dependency on kfreebsd, that is blocking the
transition to testing);
it is in
http://mennucc1.debian.net/pygame/
source files:
pygame_1.9.1release+dfsg-3.dsc
pygame_1.9.1release+dfsg-3.debian.tar.gz
I compiled in amd64, it seems OK;
I ran test/transform_test.py and it says OK,
but I dont know if it really tries the SDL bug codepath;
in case, may you provide a snippet of python code that specifically tries
it?
a.
The Pygame unit tests can be run with the run_tests.py script (try the
--help command line option). It will run all tests in subprocess and
then emit a final report to standard out. The portmidi unit tests are
interactive, so will not run by default.
Which modules get built is determined by the config.py script. It reads
Setup.in, and edits it into Setup, which is then used by setup.py.
Commenting out the pypm entry in either Setup or Setup.in will prevent
the pypm extension module from building and linking to portmidi.
Unfortunately the midi.py module will still be installed, but it will do
nothing unless its init() function is called. I think midi.py can be
safely removed from the build directory to omit it from the installation.
Thanks for preparing an updated pygame package! I was going to do so
myself, but I was short on spare time these last few days.
I would change the b-d on libportmidi-dev from [!kfreebsd-any] to
[linux-any], given that portmidi also FTBFS on hurd-i386 and I see no
indication that it's going to be fixed on hurd anytime soon.
I've also tried building pygame in a kfreebsd-i386 VM. I have no idea
how to get the build log out of a VBox VM, so I ended up taking
screenshots of the log instead; they're attached with this e-mail.
First problem is that pygame stalls when it can't find some of its
dependencies (for kfreebsd, this is portmidi and porttime), and
requires that the user manually types in 'y' at the prompt (otherwise
the build just seems to stall forever; see pygame_ftbfs1.png). How
will the buildds end up handling this?
Second problem is that pygame FTBFS on kfreebsd after the user accepts
the prompt to proceed with the build (see pygame_ftbfs2.png); pygame's
camera extension is Linux-specific.
If you have spare time this week, you're welcome to tackle these
issues yourself. Otherwise, I'll get to it sometime this week or next.
Thanks! :)
Vincent
The camera module was experimental at the time of Pygame 1.9.1. Other
experimental 1.9.1 modules are midi, scrap, and pixelarray. Yes, only
camera is marked experimental in the docs. The scrap module is kind of a
patchwork affair that resisted porting to Python 3. midi does not
integrate well with SDL events because portmidi lacks a callback
mechanism. A PixelArray handled slicing unusually, and the 1.9.2 version
is not entirely backward compatible. Feel free to leave any of them out.
Lenard Lindstrom
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
