Re: [pygame] Closing issue 211 with big-endian CPU test

2015-10-23 Thread René Dudfield
Hi,

Interesting. I didn't know you could do that ( and that, and that).

Thanks for the information.

By the way, the webhooks can be added through the bitbucket admin
interface. Any of the admins can add them in there.

Am I able to add other users to the launchpad pygame team? I'd probably
want a separate "pygame Robot" user which is able to upload to launchpad
repos+PPAs.

I think for now, the code is building and all but one test is running. For
me, this is enough for now. I'll concentrate on fixing the failing test in
the lib/compat.py and getting a qemu build going. I have a mate running a
freebsd PPC laptop that might be able to give pygame a build... I'll see
how that goes. According to him the more recent debian/ubuntu releases
don't work so well, so he had to change to freebsd.


best,






On Fri, Oct 23, 2015 at 11:12 AM, Thomas Kluyver  wrote:

> On 23 October 2015 at 07:33, René Dudfield  wrote:
>
>> I guess we should incorporate the Debian changes, but I wanted to check
>> with Thomas if what I did was ok? (see revs 14-19).
>>
>
> Fine by me. I just copied the packaging from Debian/Ubuntu originally
> anyway, so bringing in the updates is probably useful.
>
>
>> They use an interesting method to do a hg clone. I'm not sure how to
>> actually use this though... (see get-orig-source-hg in rules). In rev 19 I
>> changed that to get the latest rev from hg. But I guess they want to
>> specify a specific version.
>>
>
> AFAIK, the builders never actually run that target (and even if they did,
> they don't have outside network access). Unlike everything else in
> debian/rules, it's there for human packagers to run to get the data and
> then upload it. Debian packaging can be pretty ugly at times.
>
> Since you already have a machine running a custom webhook when there are
> new commits, perhaps it's best to use that to upload directly to Launchpad
> for PPA builds, bypassing Launchpad's code import and recipe builds:
> https://help.launchpad.net/Packaging/PPA/Uploading
>
> You'd need to work out how to get from a source tree to a Debian source
> package locally, though. I'm sure GPG signatures are involved somehow.
>
> Best wishes,
> Thomas
>


Re: [pygame] Steam Controller

2015-10-23 Thread Jake b
Steam uses SDL2, pygame uses 1.

Maybe it's not the issue, SDL2 docs sounded like it might be:

Joystick events now refer to an SDL_JoystickID. This is because SDL 2.0 can
> handle joysticks coming and going, as devices are plugged in and pulled out
> during your game's lifetime, so the index into the device list that 1.2
> uses would be meaningless as the available device list changes.
>
>
You should also check out the new Game Controller API
>  too, because it's cool,
> and maybe you did a lot of tap dancing with the 1.2 API that this new code
> would solve more cleanly. You can find it in SDL_gamecontroller.h. The Game
> Controller API integrates really nicely with Steam Big Picture Mode: you
> get automatic configuration of most controllers, and a nice UI if you have
> to manually configure it. In either case, Steam passes this configuration
> on to your SDL application
>

-- 
Jake


Re: [pygame] Closing issue 211 with big-endian CPU test

2015-10-23 Thread Thomas Kluyver
On 23 October 2015 at 07:33, René Dudfield  wrote:

> I guess we should incorporate the Debian changes, but I wanted to check
> with Thomas if what I did was ok? (see revs 14-19).
>

Fine by me. I just copied the packaging from Debian/Ubuntu originally
anyway, so bringing in the updates is probably useful.


> They use an interesting method to do a hg clone. I'm not sure how to
> actually use this though... (see get-orig-source-hg in rules). In rev 19 I
> changed that to get the latest rev from hg. But I guess they want to
> specify a specific version.
>

AFAIK, the builders never actually run that target (and even if they did,
they don't have outside network access). Unlike everything else in
debian/rules, it's there for human packagers to run to get the data and
then upload it. Debian packaging can be pretty ugly at times.

Since you already have a machine running a custom webhook when there are
new commits, perhaps it's best to use that to upload directly to Launchpad
for PPA builds, bypassing Launchpad's code import and recipe builds:
https://help.launchpad.net/Packaging/PPA/Uploading

You'd need to work out how to get from a source tree to a Debian source
package locally, though. I'm sure GPG signatures are involved somehow.

Best wishes,
Thomas