hi, looks like some changes from the py3k merge that Lenard just did.
Note, that the build bot last built successfully: revision 2047 So you can always check out that revision, that built successfully on osx, until trunk is fixed. This is also points out how changes on one platform can easily break other platforms, and why the buildbot is so awesome. cu, On Mon, May 4, 2009 at 1:33 AM, Brian Fisher <br...@hamsterrepublic.com>wrote: > My automated build machine is having the same problem on OS X, so I'd say > it's nothing wrong with your setup: > http://thorbrian.com/pygame/builds.php > > > On Sun, May 3, 2009 at 12:14 AM, el lauwer <el.lau...@gmail.com> wrote: > >> Oi, >> >> Ok, I will use git as for my daily work, and submit my code to svn if >> I need a global feedback. >> >> I have solved the problem with architecture, but now I get the following >> syntax error in the pygame code: >> >> rc/transform.c:57: error: syntax error before ‘_state’ >> src/transform.c:58: warning: initialization makes integer from pointer >> without a cast >> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in >> a function) >> src/transform.c:59: warning: excess elements in scalar initializer >> src/transform.c:59: warning: (near initialization for ‘_state’) >> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in >> a function) >> src/transform.c:60: warning: excess elements in scalar initializer >> src/transform.c:60: warning: (near initialization for ‘_state’) >> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in >> a function) >> src/transform.c:61: warning: excess elements in scalar initializer >> src/transform.c:61: warning: (near initialization for ‘_state’) >> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in >> a function) >> src/transform.c:62: warning: excess elements in scalar initializer >> src/transform.c:62: warning: (near initialization for ‘_state’) >> src/transform.c:62: warning: data definition has no type or storage class >> src/transform.c: In function ‘surf_scalesmooth’: >> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from >> incompatible pointer type >> src/transform.c: In function ‘surf_get_smoothscale_backend’: >> src/transform.c:1437: error: request for member ‘filter_type’ in something >> not a structure or union >> src/transform.c: In function ‘surf_set_smoothscale_backend’: >> src/transform.c:1443: warning: initialization from incompatible pointer >> type >> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this >> function) >> src/transform.c:1497: error: (Each undeclared identifier is reported only >> once >> src/transform.c:1497: error: for each function it appears in.) >> src/transform.c: In function ‘inittransform’: >> src/transform.c:2739: warning: assignment from incompatible pointer type >> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out >> error: command 'gcc' failed with exit status 1 >> >> Slu >> >> >> >> >> On 3-mei-09, at 07:48, Nirav Patel wrote: >> >> I personally found/find it useful to use a personal git repo, and use >>> git-svn to stay up to date with the Pygame SVN. You can use "git svn >>> rebase" to keep your repo up to date with upstream and then commit >>> with "git svn dcommit" when you have code that others can >>> use/test/hack. >>> >>> There is a decent guide for using git-svn with github here: >>> http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/ >>> >>> That is also useful so you have a repo to work in until 1.9 is >>> released and you can start committing to Pygame SVN. >>> >>> Nirav >>> >>> On Sun, May 3, 2009 at 1:10 AM, René Dudfield <ren...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> more below... >>>> >>>> On Sun, May 3, 2009 at 2:50 PM, el lauwer <el.lau...@gmail.com> wrote: >>>> >>>>> >>>>> Oi, >>>>> >>>>> I am installing the latest version of pygame on svn, >>>>> so I can start coding on my camera module. I am >>>>> installing it under virtualenv so I can keep using >>>>> the stable pygame release for my current games. >>>>> >>>>> 1) >>>>> I recently reseaved a svn account for the pygame >>>>> svn repository. How do you sugest I use this account >>>>> during the development prossess, should I use it to >>>>> commit all my changes to the main brange, or should >>>>> I make a personal brange just for my work on the >>>>> camera module. Can I use my github account instead, >>>>> if so, what must I do with the changes and bug >>>>> fixel to the main pygame development brange. >>>>> >>>> >>>> >>>> You might want to work on the main trunk, or not... depending on a >>>> number of >>>> things. >>>> >>>> Either a separate branch or in your git hub is probably a good way to >>>> go. >>>> If you put things in svn, then it's easier for some of the pygame >>>> developers >>>> to watch your work, and maybe even make changes. However it's up to >>>> you. >>>> >>>> Best to merge your work in occasionally into a svn branch at least. Or >>>> send the mailing list a link to your work when you've committed >>>> something >>>> you'd like people to look at or merge in. >>>> >>>> Then when your work is getting along, talk about merging it into the >>>> trunk >>>> with the mailing list and other developers. If no one has changed any >>>> of >>>> the files you have changed, then it's probably ok. >>>> >>>> Working in the trunk lets you take advantage of some other things... >>>> like >>>> the build bots which build on mac/win python2.4 python2.5 python2.6 and >>>> run >>>> the tests for you. So it can save you a lot of testing work. >>>> >>>> Say you wanted to make some changes to surface.c and a bunch of others >>>> that >>>> aren't part of the camera module directly, and didn't commit to trunk >>>> for a >>>> few weeks... there's a good chance someone else might make changes to >>>> those >>>> files. >>>> >>>> As long as you communicate with other devs what your working on it >>>> should be >>>> fine. >>>> >>>> >> >
