[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian/ppc64el feasiability to become an official architecture

Breno Leitao wrote:
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
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.

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.
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.

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.

Reply to: