So this is a pretty long, boring, and quite frankly disturbing story on one dark late night...
tldr; launchpad builds are working again, but it's still failing a test. Also, we have arm builds now on the PPA :) However, launchpad does not do PPC builds for PPAs yet... So qemu it is!
Well, now the long version.
I tried to get the launchpad building again... and it did start to build, but kept failing. Then I tried to get the latest debian files from debian (control/rules etc), and merged+committed+pushed them to the packaging bzr repo.
Unfortunately this didn't help either.
Then I noticed it was the upload failing, and the version numbers were different. It thought the new package had an older version than the new one. I couldn't figure out how to change this, so I deleted the old packages in the PPA. Then it started building again! The source package at least was uploaded, and x86+amd64 began to build.
Then I reverted packaging back to rev 13, and tried to build again. So now there are log files for both types of builds.
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).
...
Then I tried the build again, and it wouldn't upload, because the version number was the same. So I once again deleted the packages in the PPA, and went back to rev 19 with the Debian changes.
Note the latest Debian changes made the version name like this with the repo rev and the packaging rev:
"pygame - 1.9.2~pre~r3348+1+21~ubuntu15.04.1"
But the older one (rev 13) does not have the repo version in it, which of course means that we need to delete the packages every time, otherwise they won't upload.
"pygame - 1.9.2~pre~ubuntu+1+22~ubuntu15.04.1"
But there were LOTS of tests failures with how I integrated the Debian changes. I likely did lots wrong.
I tried to fix the lib/compat.py test error in pygame hg, and try to rebuild with rev 13 of packaging.
"
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.
Note, it's a horrible and long build process at the moment. Because the code has to go -> bitbucket -> web hook -> pull from bitbucket -> create new local git repo -> push git repo to github -> manually tell launchpad to pull from github -> delete packages -> tell launchpad to build again -> wait for source build -> wait for binary builds. (15-20 minute turn around). Oh, and the delete package thing doesn't always work right away, so that can add another 30-45 minutes on top.
Then I found out that resetting the git repo to have only one commit makes the bzr import always have a revno of 1. So this is the cause of it thinking the files are always the same. A horrible hack would be to automagically add N number of commits extra on top of the git... um, ewww. Or some other hack perhaps.