Breno Leitao wrote:
I intepret the "must be built without external patches" as it must be possible to have a self-contained subset of debian where all packages can be built on your architecture from pure debian source packages and where all build-dependencies are satisfiable.Hi Peter, Thank you for your reply. On 07/24/2014 08:14 PM, peter green wrote:Note: this is the perspective of a dd who is not directly involved with powerc though I have come across some of your bug reports, nor am I a member of the ftp or release teams. It's probablly mostly right but i'm sure others will point out any errors.I would like to share the ppc64el port's status with you, and check if it is feasible to consider it as an official port for the next Debian release, or, what it may be missing for that.quite a bit needs to be done and I personally think it's unlikely any new architectures will make it in time for the jessie freeze at this point. The first step is going to be persuading the ftp masters to let you into the debian archive. You can see the ftpmasters critera at https://ftp-master.debian.org/archive-criteria.html .Right, as I understand we are on track to meet all those criteria. We have a good archive coverage, a debian installer, fast machines doing the build, and, finally a DD helping us.It sounds like the main thing you will need to do to meet them is push your fixes into debian proper so ppc64el can be built without external patches.Right?.What do you mean by built? We have a huge amount of packages building for ppc64el without external patches. At this time, we already built more than 8k8 source architecture-dependent packages (of almost 10K) for this platform[1] Also, the debootstrap packages are all BFS on ppc64el, and if you want a environment that contains git, openjdk, ssh, vim and latex, less than 10 bugs need to be accepted[2] [1] http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/Uploaded.html [2] https://wiki.debian.org/ppc64el/topBugs
There isn't a lot of point IMO. Your ports health in debian testing will be more related to it's health in debian unstable than to it's health in a seperate rebuild of testing since the main way testing is updated is through migrations of source and binaries from unstable.When you are added to testing you will be added as a "broken and fucked" (release team's terminology not mine) architecture. To get out of this state you will need to get and keep your port in a healthy state in testing. That will mean fixing (in some cases through NMUs) issues that are blocking migration of packages you need (whether or not those issues are related to your architecture) and fixing any architecture specific build failures as quickly as possible (since when you are in the "broken and fucked" state your builds will not be blockers for testing migration so a new upload that breaks your architecture will be able to migrate).Right. Do you recommend us to start building packages from 'testing' right now? We can create another buildd instances that only build testing and we can see how healthy it is.
The key thing is that binaries only migrate from unstable to testing either alongside source packages or when the source version in testing and unstable matches. What this means is that an architecture newly added to testing will be missing many packages. To get those packages into place generally means getting their version in testing and unstable into sync and that can mean fixing bugs that are not only not specific to your architecture but don't even directly affect it.
It's technically possible to add binaries to testing for a package where testing and unstable are out of sync by binnmuing to TPU but AIUI the release team don't like this to be done on a routine basis.