Red Hat Bugzilla – Bug 239899
pygame 64 bit bug, result: AttributeError: event member not defined
Last modified: 2007-11-30 17:12:04 EST
I installed seahorse-adventures earlier and I thought I'd try it out, but it
fails to start every time I attempt to play it. The python traceback it gives is
Traceback (most recent call last):
File "/usr/bin/seahorse-adventures", line 32, in <module>
File "/usr/share/seahorse-adventures/lib/main.py", line 314, in main
File "/usr/share/seahorse-adventures/lib/pgu/engine.py", line 108, in run
File "/usr/share/seahorse-adventures/lib/pgu/engine.py", line 126, in loop
if not self.event(e):
File "/usr/share/seahorse-adventures/lib/main.py", line 262, in event
File "/usr/share/seahorse-adventures/lib/pgu/engine.py", line 80, in fnc
if v != None: r = f(v)
File "/usr/share/seahorse-adventures/lib/menu.py", line 119, in event
if e.type is USEREVENT and e.action == 'down':
AttributeError: event member not defined
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run `yum install seahorse-adventures` (as root)
2. Run `seahorse-adventures`
Actual results: It crashes as explained above.
Expected results: I'd like to be able to play it. :)
Additional info: This is on an updated Fedora Development box (x86_64 only, no
multilib/32-bit stuff). I also tried to run it as root, but it still fails in
Good catch! I didn't see this myself as I developed this package on a 32 bit
machine. But since this package is 100% python, that shouldn't make a difference.
However there are a couple of 64bit bugs in pygame, one of which get triggered
Chris, re-assigning to you. I know you only do pygame because its a dep of some
of your other packages, but no worries I've got a patch ready for you.
Created attachment 154584 [details]
PATCH: fixing 64 bit bugs
As promised, as you can see its a pretty simple patch, with the chance for
regressions being very close to 0. So please do a new pygame package with this
asap, and mail email@example.com with a request to tag the new pygame
for F7 final inclusion (I wouldn't mind receiving a CC).
Notice that this patch should NOT be used in FC-6, the involved python C api
functions got their prototype changed to take Py_ssize_t pointers (which point
to 64 bit vars on 64 bit machines) instead of int pointers in 2.5, for python
2.4 to current pygame code using int's for this is correct!
Thanks for the patch, Hans! It works nicely here. :D
I checked out a copy of pygame/devel from CVS and appended your patch to the
pygame-1.7.1-64bit.patch already in the CVS tree (changing the paths to all
start at src/ instead of pygame-1.7.1release/src/) and after rebuilding it, I no
longer have this issue with seahorse-adventures. (Hopefully this fixes a bunch
of other 64-bit holes too should any further arise...)
can you please test the -13 release in CVS? I can probably go ahead and push
it, but I'd rather you give it a test first to make sure everything is good. I
have to get rel-eng approval? Why can't I just make tag build?
(In reply to comment #4)
> can you please test the -13 release in CVS? I can probably go ahead and push
> it, but I'd rather you give it a test first to make sure everything is good.
Thanks very much for committing this, Chris. I checked-out a copy of the -13
release and built a local pygame RPM for myself, and it works just fine with
seahorse-adventures and manicor (though manicor worked fine before this patch,
if it makes a difference).
> I have to get rel-eng approval? Why can't I just make tag build?
IIRC, You can push it through the build system, but it won't hit the rawhide
composes or f7-final until after Fedora 7 goes GA. I've been rather absent from
Fedora for most of the merger stuff though; and am still learning my way through
it, reading mails/wiki about it, etc.
Okay, well I pushed the -13 release out and asked them to include this version
in F7. However, just after doing this I noticed another patch someone just
e-mailed the pygame mailing list.
He claims his patch is better because it does something with rectangles, do you
think it is worth applying the extra changes?
I've only briefly perused the patch he posted; but it seems to me that the
changes made by his patch are equivalent in function to the ones already posted
by Hans and what you've earlier had in CVS.
The rectangle changes, though, puzzle me quite a bit. All he did was remove the
type-casting from each of the methods. :|
Also, his patch effectively removes the Python 2.5-only snippets with
#ifdef/#endif preprocessor statements if building against 2.4, but since you're
only applying the patch to the devel branch (which has Python 2.5), this doesn't
seem a necessary feature. (Though it is likely highly necessary for the upstream
package until all vendors move up to Python 2.5 stuff.)
I've reviewed the pythonmailinglist patch, mostly its the functional equivalent
of mine, it gets rid of some warnings. It does however contain one more 64 bit
fix which might be significant. So I think while were at it it would be good to
switch to this patch instead.
okay, sorry I missed that one bit. Should be fixed now, can you test the -14
release in CVS? Thanks.
(In reply to comment #9)
> okay, sorry I missed that one bit. Should be fixed now, can you test the -14
> release in CVS? Thanks.
The -14 release seems fine from my local testing. At least, I can't find any
regressions from the -13 release.
Thanks for your quick response, Chris & Hans!
okay, im going to go ahead and push this then, thanks :)