Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 16/06/16 02:12, Hector Oron wrote:
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
> 
> Please review and comment if required.

That page is now outdated wrt mips concerns (see below). Do we need to duplicate
the information that we already have on r.d.o/stretch/arch_qualify.html ?

>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.

Sure, that's fine.

> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.

OK. I have removed the DSA concerns for arm64 from arch_qualify due to this.

>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
> 
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]

AIUI armhf/armel needing local admins should still be a concern, even if mild.
Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that.

> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.

I have added you two as armel porters.

>>  * mips64el (NEW)
>>- No DSA buildd (RT blocker)
> 
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.

We now got more hardware. This is no longer a concern.

>>- Rebuild after import not complete (RT Blocker)
> 
> Is there a list of packages that should be rebuilt?

There's just one package missing, which is being worked on. See Aurelien's mail.

>>- Not yet in testing (due to the above).
> 
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.

Once db5.3 is rebuilt, we can enable mips64el in testing.

> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?

Not sure about this one... I don't think anybody has stepped up as a porter.

> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
> 
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.

That's sorted out now.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Dave Jones]

Hello, all.

Sorry for the late response hereI believe I can offer some s390x 
resources for the project if they are still needed.


DJ

On 06/14/2016 05:37 PM, Dimitri John Ledkov wrote:

On 14 June 2016 at 20:22,   wrote:

On 2016-06-14 03:06, Philipp Kern wrote:

On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:

Philipp Kern:

On 2016-06-05 12:01, Niels Thykier wrote:

  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
s390x
- *No* blockers at this time from RT, DSA nor security.
- s390, ppc64el and all arm ports have DSA concerns.

What is the current DSA concern about s390x?

The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)


Yeah, but that's unfortunately one of the universal truths of this port.
I mean in theory sometimes they turn up on eBay and people try to make
them work[1].

It also seems true for other ports where we commonly relied on sponsors
to hand us replacements. But maybe it's only ppc64el these days, maybe
there are useful builds available for the others (including arm64 and
mips) on the market now.

Kind regards and thanks
Philipp Kern

[1] https://www.youtube.com/watch?v=45X4VP8CGtk
 (Here's What Happens When an 18 Year Old Buys a Mainframe)


Fun story, i had a client who was considering getting their hands on a Z9,
they asked me a few others to go with them to see IBM present a demo of it.
Long story short the IBM guys started a job and literally started pulling
CPU and Mem boards out of the machine mid job. The error log on the OS/2
maintenance laptop was going crazy, but the OS kept running the job.

In other words, i don't think a s390x box will ever just die. Really
interesting machines to say the least, hopefully one day i will get to play
with one. The other issues with s390x is that  in most cases you don't buy
them. You essentially lease the CPU usage and IBM charges you based on how
much CPU usage you've consumed over a given time. It makes me wonder how
they ever get on eBay. IBM typically takes them back after you stop paying
for it.


In the talk he did say that for that acient machine he was offered
subscription to the upgraded z/OS for some small amount of dollars a
quarter.

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.



--
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544

Re: [Stretch] Status for architecture qualification

[Luca Filipozzi]

On Mon, Jun 27, 2016 at 04:35:03PM +0200, Wouter Verhelst wrote:
> (sorry for jumping in late here)
> 
> On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> > On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> > 
> > > At the openmainframeproject EU meetup, it was indicated that SUSE
> > > joined with indication that Open Build Service might be able to use
> > > resources hosted by Marist.
> > > 
> > > I wonder if it makes sense to reach out, and see if there are
> > > resources available to use as porter boxes & build boxes. That way
> > > Debian might be able to get such donated resource available on ongoing
> > > basis and hopefully with some hw support.
> > 
> > Marist already support Debian with an s390x buildd:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(sponsor=*marist*)"
> > https://db.debian.org/machines.cgi?host=zani
> > 
> > Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(architecture=s390*)" sponsor
> 
> Given that we already seem to have three hardware sponsors for the s390x
> port, is this really a concern?

Our standard for buildd / porterboxen of a released architecture is:
- multiple machines (N + 1, N sufficient to handle the buildd / porter load)
- under warranty or post-warranty hardware support for the duration of their
  use as buildds / porterboxen including through the LTS timeframe
- located in multiple geographic locations (EU and NA, ideally)
- hosted by different hosting partners, each providing high availability
  (power, cooling, networking) and intelligent remote hands
- under Debian control and/or ownership; available & affordable 
- redundant disks and power supplies
- out-of-band service processor with power management or equivalent

Not satisfying the fifth bullet is a minor concern in the case of s390x.

> If we were to lose one sponsor, we'd still have two (and it would be
> reasonable to try to ensure that we get a new sponsor to replace the one
> lost).

Indeed.  The more redundnant sponsors, the less worrying is the concern.

> How about making it a requirement that there is some level of redundancy
> in sponsors for ports where hardware cannot be easily bought with Debian
> money? That would cover the s390x port as well as any potential other
> insanely-expensive-hardware port[1] that we might support now or in the
> future.

That is our requirement, effectively.  The mild concern has not blocked the
port from releasing.  That said, the concern should be documented.

> If push comes to shove, we could also talk to IBM. Pretty much all POWER
> hardware we have was sponsored by IBM; it's not unreasonable to assume they
> might be willing to also sponsor s390x time or hardware.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-20 10:29, John Paul Adrian Glaubitz wrote:

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz 
wrote:

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?


Well it is getting there.


The archive rebuild is done and around 11200 packages are up-to-date. 
It's
just the installer that needs work and someone needs to convince the 
release

team that ppc64 is something we want as a release architecture.

Adrian


Just out of curiosity, what's the stipulation with ppc64? Access to 
hardware shouldn't be a problem if ppc64el is a release arch. Maybe i'm 
just weird, but i would pick ppc64 over ppc64el any day. Other than my 
personal affinity for big endian cpu's, ppc64el only has support for one 
generation of cpu's whereas ppc64 should be able to run on everything 
from power4 / ppc970 and up without too much trouble.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
> On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
>> Well, we just did a full archive rebuild of "ppc64" to be able to
>> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?
> 
> Well it is getting there.

The archive rebuild is done and around 11200 packages are up-to-date. It's
just the installer that needs work and someone needs to convince the release
team that ppc64 is something we want as a release architecture.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
> Well, we just did a full archive rebuild of "ppc64" to be able to
> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Well it is getting there.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:05 PM, Lennart Sorensen wrote:
> Also I suspect many users of 64 bit capable freescale chips
> (e5500 and e6500 cores) are running 32 bit powerpc since they
> don't have enough ram to actually really gain anything
> from going to 64 bit, and the ppc64 port isn't done yet.

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote:
> Do they implement the ISA required by the existing Debian port?

Yes.

The only ones that don't are the Freescale 85xx and P10[12]x chips,
which are powerpcspe due to using the e500 core.

All the 83xx and 82xx chips which are still shipping in many current
products are plain old 32bit powerpc.  Also I suspect many users of 64
bit capable freescale chips (e5500 and e6500 cores) are running 32 bit
powerpc since they don't have enough ram to actually really gain anything
from going to 64 bit, and the ppc64 port isn't done yet.  But those
would be a case of running 32 bit on 64 bit.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> In other words, i don't think a s390x box will ever just die.

I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware.  It's not just about faults with a
piece of equipment.

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

* Lennart Sorensen:

> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today.  They are not going away anytime soon.

Do they implement the ISA required by the existing Debian port?

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/18/2016 06:25 PM, William ML Leslie wrote:
> In case it isn't clear, the number of users of the architecture is not part 
> of the qualification, it is the amount of maintenance pressure involved. 
> Package
> maintainers have to put more effort into ensuring builds succeed for release 
> architectures, which detracts from other work that needs to be done. Not 
> being a
> release architecture is perfectly fine.

I maintain multiple architectures in Debian Ports, including m68k, powerpcspe, 
sh4, sparc64 and x32 and actually, it's not so much of a burden to maintain an
architecture in Debian. Most of the packages don't need special attention and 
if they do, it's usually just poorly written code like people doing weird 
pointer
arithmetics which provoke unaligned access or abuse C/C++ in other ways.

If upstream developers in these cases cared more about code quality and 
adhering to the C/C++ standards, we would hardly ever have issues with any 
ports. Heck,
even on m68k, most packages still build fine and they actually work. As long as 
an architecture is maintained upstream both in the kernel and the toolchain,
there is absolutely no reason to not keep it in Debian unless there is no 
hardware available that can be used for buildds and porterboxes. Ports like
Debian/GNU Hurd or Debian/kFreeBSD are a different story though as they need 
way more work to be able to make all sorts of packages work there.

In the case of PowerPC, both the kernel and the toolchain are very well 
maintained, many packages like GHC have native support for the architecture and 
even
rather problematic packages like Firefox/Thunderbird are supported. Plus, 
PowerPC packages can be built on the POWER8 virtual machines that IBM provides
for Debian Developers in the cloud for free. We have one such machine set up 
for ppc64, for example.

In any case, if PowerPC should ever be dropped as a release architecture, I 
will be more than happy to adopt it in Debian Ports.

PS: If you see your package failing to build on any of the ports architectures 
and you want to fix it and need help, just let me know :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[William ML Leslie]

In case it isn't clear, the number of users of the architecture is not part
of the qualification, it is the amount of maintenance pressure involved.
Package maintainers have to put more effort into ensuring builds succeed
for release architectures, which detracts from other work that needs to be
done. Not being a release architecture is perfectly fine.

And just to bring the topic full circle now, ppc is a release architecture,
nobody is suggesting its removal afaict.
On 18/06/2016 2:54 am, "Brock Wittrock"  wrote:

I run all sorts of PowerPC machines with various versions of Debian and I
don't see that coming to end anytime soon.  These are excellent and
reliable machines.  Biggest issues/hurdles are just graphics at the moment
for both ATI/AMD and Nvidia cards, but even if that is never resolved/fixed
or performance dwindles to nothing, I will continue to use these machines
in text/console only mode if I have to.  Please do not drop this
architecture!


Brock

On Fri, Jun 17, 2016 at 3:24 AM, Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi,
>
> Dan DeVoto wrote:
>
>> In addition to the debian powerpc mailing list, powerpc users are active
>> on the Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything
>> works except 3D acceleration.  I don't see a need to drop it.
>>
>
> I hope that my iBook G3 will serve me for years to come! Low power
> consumption fanless with a SSD disk make superquiet and quite nice!
>
> Riccardo
>
>

Re: [Stretch] Status for architecture qualification

[Riccardo Mottola]

Hi,

Dan DeVoto wrote:

In addition to the debian powerpc mailing list, powerpc users are active on the 
Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything works 
except 3D acceleration.  I don't see a need to drop it.


I hope that my iBook G3 will serve me for years to come! Low power 
consumption fanless with a SSD disk make superquiet and quite nice!


Riccardo

RE: [Stretch] Status for architecture qualification

[luigi burdo]

Here too all new amiga Ng are PPC  with last generations of gpu pcie Amd boards 
and we are using linux  expecially Debian.
Luigi

From: herminio.hernande...@gmail.com
Date: Wed, 15 Jun 2016 22:02:29 -0700
Subject: Re: [Stretch] Status for architecture qualification
To: hector.o...@gmail.com
CC: ni...@thykier.net; debian-ad...@lists.debian.org; t...@security.debian.org; 
debian-rele...@lists.debian.org; debian-po...@lists.debian.org; 
debian-wb-t...@lists.debian.org; r...@debian.org

I know there are still powerpc users who run Debian. I am one of them and love 
to see it continue. How can I help?
Thanks!
On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron <hector.o...@gmail.com> wrote:
[Add to CC debian-wb-team@ and r...@debian.org]



Hello,



2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:

> Hi members of DSA, Security, RT and all porters.

>

> While the freeze still seem far away, I think it is time to start with

> the architecture qualifications.



Excellent! Thanks



I tried to follow the follow-up thread, ended up watching an hour

video which was quite fun and forgot all details. :-)



I have put up the classical wiki page for Stretch at:

  https://wiki.debian.org/ArchiveQualification/Stretch



Please review and comment if required.



> For starters, here are the architectures we are aware of:

>

>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,

>s390x

>- *No* blockers at this time from RT, DSA nor security.

>- s390, ppc64el and all arm ports have DSA concerns.



I understand s390x and ppc64el DSA concerns have been clarified

in-list and those concerns are due to nature of the architecture.



For the ARM ports, which have also been clarified, let me re-confirm:

 * arm64 port has remote power and remote console available, plus

geo-redundancy, hardware is available and there is more hardware

coming in the pipeline. I am unsure why it is listed with multiple DSA

concerns, that surprises me (with DSA and ARM porter hats). The port

currently has 4 machines up, one down waiting to be replaced, in total

5 and more coming.

 * armhf/armel ports share hardware, we currently have 6 machines up

with remote power and remote console (of course that being development

boards is not so nice as server remote management goodies). Some

machines require a button press but local admins are great and always

happy to help.



If none steps up explaining what are DSA concerns on the ARM

architectures, please update status requalification page dropping

those concerns. [DSA hat on]



I see armel has one porter listed, if more are needed, please add

myself and Riku Voipio (armel buildd maints). [ARM hat on]

I see arm64/armhf are covered porterwise however there should be more

porters available if needed.



>- armel has a RT concern about lack of buildds (only 2)



>From the above comment: "armhf/armel ports share hardware, we

currently have 6 machines up"



>  * mips64el (NEW)

>- No DSA buildd (RT blocker)



As far as I can see mips64el is using shared builds with mipsel port

hardware, those machines are DSA.



>- Rebuild after import not complete (RT Blocker)



Is there a list of packages that should be rebuilt?



>- Not yet in testing (due to the above).



Please let's work on getting it in testing ASAP I think the above

blockers can be worked out quite reasonably.



>  * kfreebsd-i386, kfreebsd-amd64

>- Not included in Jessie due to lack of sustainable man-power (RT

>  blocker)

>- No news of the situation having changed

>- If there is no news on the situation after DebConf16, I will

>  assume kfreebsd-* will not target Stretch.



Who has been keeping it up for stretch? (As a side note Stephen

Chamberlain, Christoph Egger and many other people keep working on it)

Not sure if those arches have more or less manpower than powerpc (in

example). I think it would be great to make a call here, we either

move kfreebsd ports to debian-ports infrastructure or go for the

release with it.



While working out ArchitectureQualification/Stretch wiki page I

believe everything is mostly fine for release, however I got a

personal concern on powerpc architecture. Is it well maintained? Does

it have porters? Does it have users? Does it still make sense to carry

along?



Another concern (DSA) which I have added and explained in the wiki

page is the lack of georedundancy for the 'mips' port. Verbatim copy

from wiki follows:

"mips: It has 5 buildds in the same datacenter, current hardware are

routers or development boards which makes it very difficult to ship to

other places. The host providing redundancy (lucatelli) at UBC-ECE

must be decomissioned ASAP, leaving the port in a situation of not

geographic redundancy. However advanced plans exists to deploy mips

hardware in other data centers RSN."



I'll

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

On Thu, Jun 16, 2016 at 2:12 AM, Hector Oron  wrote:
[...]
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
[...]

The debian-powerpc@l.d.o mailing list is active so I would say it
still has some users. I have been using partch.d.o for doing some work
on PowerPC. I posted a summary of work people have been doing on this
port lately:

https://lists.debian.org/debian-powerpc/2016/06/msg00046.html

However I do agree that true PowerPC hardware is actually
disappearing, and it is alive mostly thanks to being an ABI using
32bits integer for PPC64 CPU(s).

-M

Re: [Stretch] Status for architecture qualification

[Herminio Hernandez, Jr.]

I know there are still powerpc users who run Debian. I am one of them and
love to see it continue. How can I help?

Thanks!

On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron  wrote:

> [Add to CC debian-wb-team@ and r...@debian.org]
>
> Hello,
>
> 2016-06-05 12:01 GMT+02:00 Niels Thykier :
> > Hi members of DSA, Security, RT and all porters.
> >
> > While the freeze still seem far away, I think it is time to start with
> > the architecture qualifications.
>
> Excellent! Thanks
>
> I tried to follow the follow-up thread, ended up watching an hour
> video which was quite fun and forgot all details. :-)
>
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
>
> Please review and comment if required.
>
> > For starters, here are the architectures we are aware of:
> >
> >  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
> >s390x
> >- *No* blockers at this time from RT, DSA nor security.
> >- s390, ppc64el and all arm ports have DSA concerns.
>
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.
>
> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.
>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
>
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]
>
> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.
>
> >- armel has a RT concern about lack of buildds (only 2)
>
> >From the above comment: "armhf/armel ports share hardware, we
> currently have 6 machines up"
>
> >  * mips64el (NEW)
> >- No DSA buildd (RT blocker)
>
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.
>
> >- Rebuild after import not complete (RT Blocker)
>
> Is there a list of packages that should be rebuilt?
>
> >- Not yet in testing (due to the above).
>
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.
>
> >  * kfreebsd-i386, kfreebsd-amd64
> >- Not included in Jessie due to lack of sustainable man-power (RT
> >  blocker)
> >- No news of the situation having changed
> >- If there is no news on the situation after DebConf16, I will
> >  assume kfreebsd-* will not target Stretch.
>
> Who has been keeping it up for stretch? (As a side note Stephen
> Chamberlain, Christoph Egger and many other people keep working on it)
> Not sure if those arches have more or less manpower than powerpc (in
> example). I think it would be great to make a call here, we either
> move kfreebsd ports to debian-ports infrastructure or go for the
> release with it.
>
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
>
> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
>
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.
>
> > Beyond mips64el, we are not aware of any new architectures for Stretch.
>
> Could you please check with sparc64 porters? I think some of them
> commented on the follow ups.
>
> Regards,
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>
>

Re: [Stretch] Status for architecture qualification

[Hector Oron]

[Add to CC debian-wb-team@ and r...@debian.org]

Hello,

2016-06-05 12:01 GMT+02:00 Niels Thykier :
> Hi members of DSA, Security, RT and all porters.
>
> While the freeze still seem far away, I think it is time to start with
> the architecture qualifications.

Excellent! Thanks

I tried to follow the follow-up thread, ended up watching an hour
video which was quite fun and forgot all details. :-)

I have put up the classical wiki page for Stretch at:
  https://wiki.debian.org/ArchiveQualification/Stretch

Please review and comment if required.

> For starters, here are the architectures we are aware of:
>
>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>s390x
>- *No* blockers at this time from RT, DSA nor security.
>- s390, ppc64el and all arm ports have DSA concerns.

I understand s390x and ppc64el DSA concerns have been clarified
in-list and those concerns are due to nature of the architecture.

For the ARM ports, which have also been clarified, let me re-confirm:
 * arm64 port has remote power and remote console available, plus
geo-redundancy, hardware is available and there is more hardware
coming in the pipeline. I am unsure why it is listed with multiple DSA
concerns, that surprises me (with DSA and ARM porter hats). The port
currently has 4 machines up, one down waiting to be replaced, in total
5 and more coming.
 * armhf/armel ports share hardware, we currently have 6 machines up
with remote power and remote console (of course that being development
boards is not so nice as server remote management goodies). Some
machines require a button press but local admins are great and always
happy to help.

If none steps up explaining what are DSA concerns on the ARM
architectures, please update status requalification page dropping
those concerns. [DSA hat on]

I see armel has one porter listed, if more are needed, please add
myself and Riku Voipio (armel buildd maints). [ARM hat on]
I see arm64/armhf are covered porterwise however there should be more
porters available if needed.

>- armel has a RT concern about lack of buildds (only 2)

>From the above comment: "armhf/armel ports share hardware, we
currently have 6 machines up"

>  * mips64el (NEW)
>- No DSA buildd (RT blocker)

As far as I can see mips64el is using shared builds with mipsel port
hardware, those machines are DSA.

>- Rebuild after import not complete (RT Blocker)

Is there a list of packages that should be rebuilt?

>- Not yet in testing (due to the above).

Please let's work on getting it in testing ASAP I think the above
blockers can be worked out quite reasonably.

>  * kfreebsd-i386, kfreebsd-amd64
>- Not included in Jessie due to lack of sustainable man-power (RT
>  blocker)
>- No news of the situation having changed
>- If there is no news on the situation after DebConf16, I will
>  assume kfreebsd-* will not target Stretch.

Who has been keeping it up for stretch? (As a side note Stephen
Chamberlain, Christoph Egger and many other people keep working on it)
Not sure if those arches have more or less manpower than powerpc (in
example). I think it would be great to make a call here, we either
move kfreebsd ports to debian-ports infrastructure or go for the
release with it.

While working out ArchitectureQualification/Stretch wiki page I
believe everything is mostly fine for release, however I got a
personal concern on powerpc architecture. Is it well maintained? Does
it have porters? Does it have users? Does it still make sense to carry
along?

Another concern (DSA) which I have added and explained in the wiki
page is the lack of georedundancy for the 'mips' port. Verbatim copy
from wiki follows:
"mips: It has 5 buildds in the same datacenter, current hardware are
routers or development boards which makes it very difficult to ship to
other places. The host providing redundancy (lucatelli) at UBC-ECE
must be decomissioned ASAP, leaving the port in a situation of not
geographic redundancy. However advanced plans exists to deploy mips
hardware in other data centers RSN."

I'll keep you posted whenever there is progress on that area. I do not
believe it should be a blocker for release, but we must ensure geo
redundancy first.

> Beyond mips64el, we are not aware of any new architectures for Stretch.

Could you please check with sparc64 porters? I think some of them
commented on the follow ups.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: [Stretch] Status for architecture qualification

[Stephen Powell]

On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote:
> 
> There is openmainframe project https://www.openmainframeproject.org/ ,
> which I believe offers access to z/VM instances hosted by Marist
> colledge.
> 
> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.
> 

Of course, there's always Hercules.  Real hardware is always better of course.
But then again, strictly speaking, A z/VM instance is a virtual machine,
running under z/VM.  And z/VM is running in an LPAR, which is essentially
a virtual machine running under PR/SM.  And the physical machine behind
those (at least) two levels of virtualization doesn't really have the
same hardware architecture as a virtual machine, such as physical chpids
vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM
or IOCP.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [Stretch] Status for architecture qualification

[Paul Wise]

On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:

> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.

Marist already support Debian with an s390x buildd:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(sponsor=*marist*)"
https://db.debian.org/machines.cgi?host=zani

Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(architecture=s390*)" sponsor

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [Stretch] Status for architecture qualification

[Dimitri John Ledkov]

On 14 June 2016 at 20:22,   wrote:
> On 2016-06-14 03:06, Philipp Kern wrote:
>>
>> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>>>
>>> Philipp Kern:
>>> > On 2016-06-05 12:01, Niels Thykier wrote:
>>> >>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>> >>s390x
>>> >>- *No* blockers at this time from RT, DSA nor security.
>>> >>- s390, ppc64el and all arm ports have DSA concerns.
>>> > What is the current DSA concern about s390x?
>>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>>
>>> As I recall the argument went something along the lines of:
>>>
>>> "Debian cannot replace the hardware; if any of the machines dies, we
>>> need a sponsor to replace it.  If all of them dies and we cannot get
>>> sponsored replacements, we cannot support the architecture any longer"
>>>
>>> (My wording)
>>
>>
>> Yeah, but that's unfortunately one of the universal truths of this port.
>> I mean in theory sometimes they turn up on eBay and people try to make
>> them work[1].
>>
>> It also seems true for other ports where we commonly relied on sponsors
>> to hand us replacements. But maybe it's only ppc64el these days, maybe
>> there are useful builds available for the others (including arm64 and
>> mips) on the market now.
>>
>> Kind regards and thanks
>> Philipp Kern
>>
>> [1] https://www.youtube.com/watch?v=45X4VP8CGtk
>> (Here's What Happens When an 18 Year Old Buys a Mainframe)
>
>
> Fun story, i had a client who was considering getting their hands on a Z9,
> they asked me a few others to go with them to see IBM present a demo of it.
> Long story short the IBM guys started a job and literally started pulling
> CPU and Mem boards out of the machine mid job. The error log on the OS/2
> maintenance laptop was going crazy, but the OS kept running the job.
>
> In other words, i don't think a s390x box will ever just die. Really
> interesting machines to say the least, hopefully one day i will get to play
> with one. The other issues with s390x is that  in most cases you don't buy
> them. You essentially lease the CPU usage and IBM charges you based on how
> much CPU usage you've consumed over a given time. It makes me wonder how
> they ever get on eBay. IBM typically takes them back after you stop paying
> for it.
>

In the talk he did say that for that acient machine he was offered
subscription to the upgraded z/OS for some small amount of dollars a
quarter.

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.

-- 
Regards,

Dimitri.

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-14 03:06, Philipp Kern wrote:

On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:

Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
> What is the current DSA concern about s390x?
The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)


Yeah, but that's unfortunately one of the universal truths of this 
port.

I mean in theory sometimes they turn up on eBay and people try to make
them work[1].

It also seems true for other ports where we commonly relied on sponsors
to hand us replacements. But maybe it's only ppc64el these days, maybe
there are useful builds available for the others (including arm64 and
mips) on the market now.

Kind regards and thanks
Philipp Kern

[1] https://www.youtube.com/watch?v=45X4VP8CGtk
(Here's What Happens When an 18 Year Old Buys a Mainframe)


Fun story, i had a client who was considering getting their hands on a 
Z9, they asked me a few others to go with them to see IBM present a demo 
of it. Long story short the IBM guys started a job and literally started 
pulling CPU and Mem boards out of the machine mid job. The error log on 
the OS/2 maintenance laptop was going crazy, but the OS kept running the 
job.


In other words, i don't think a s390x box will ever just die. Really 
interesting machines to say the least, hopefully one day i will get to 
play with one. The other issues with s390x is that  in most cases you 
don't buy them. You essentially lease the CPU usage and IBM charges you 
based on how much CPU usage you've consumed over a given time. It makes 
me wonder how they ever get on eBay. IBM typically takes them back after 
you stop paying for it.

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 14/06/16 09:06, Philipp Kern wrote:
> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>> Philipp Kern:
>>> On 2016-06-05 12:01, Niels Thykier wrote:
  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
s390x
- *No* blockers at this time from RT, DSA nor security.
- s390, ppc64el and all arm ports have DSA concerns.
>>> What is the current DSA concern about s390x?
>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>
>> As I recall the argument went something along the lines of:
>>
>> "Debian cannot replace the hardware; if any of the machines dies, we
>> need a sponsor to replace it.  If all of them dies and we cannot get
>> sponsored replacements, we cannot support the architecture any longer"
>>
>> (My wording)
> 
> Yeah, but that's unfortunately one of the universal truths of this port.
> I mean in theory sometimes they turn up on eBay and people try to make
> them work[1].
> 
> It also seems true for other ports where we commonly relied on sponsors
> to hand us replacements. But maybe it's only ppc64el these days, maybe
> there are useful builds available for the others (including arm64 and
> mips) on the market now.

AFAIK we rely on sponsors for all ports. The difference is that if we eventually
have to buy things ourselves, we can get mips*, arm* or x86 buildds (for
example), but we can't reasonably get a s390x one.

But that's not something we can change, so as long as there no other concerns,
this shouldn't be a blocker.

Emilio

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On 2016-06-05 12:01, Niels Thykier wrote:

 * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
   s390x
   - *No* blockers at this time from RT, DSA nor security.
   - s390, ppc64el and all arm ports have DSA concerns.


What is the current DSA concern about s390x?

Kind regards and thanks
Philipp Kern

Re: [Stretch] Status for architecture qualification

[Oleg Endo]

Hi,

On Sun, 2016-06-05 at 13:26 +0200, John Paul Adrian Glaubitz wrote:

> sh4:
> 

> 
> The two biggest issues with sh4 are currently with binutils and the 
> kernel. binutils has problems when building Qt5:
> 

There is in fact another big elephant in the room, which I have
mentioned several times before...

The atomic model that is currently being used on sh4-linux works only
on SH3* and SH4* single-core systems.  Packages built for the current
sh4-linux will not work on multi-core systems like SH7786...

There should be two distinct builds .. sh4-linux with the current
atomic model (-matomic-model=soft-gusa) and sh4a-linux with the newer 
-matomic-model=hard-llcs.  I think it would be the easiest thing for
Debian to switch the whole thing to SH4A only and drop the older SH4.

I will add a GCC configure option to allow changing the default atomic
model.  Currently it's hardcoded to -matomic-model=soft-gusa for sh3
-linux or sh4*-linux.

Cheers,
Oleg

(GCC SH Maintainer)

Re: [Stretch] Status for architecture qualification

[Steven Chamberlain]

Hi,

John Paul Adrian Glaubitz wrote:
> I have invested lots of time and effort to get sparc64 into a usable state in 
> Debian.
> We are close to 11.000 installed packages. Missing packages include Firefox,
> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).

Trying to have *every* package build and stay built on every port, and
supported for the lifetime of stable, is a lot of work without much
purpose sometimes.  And it's unreasonable for any one port to block
testing migration of a package on all arches, unless it is something
really essential.

This might be done either:
  * in the official archive, with relaxed rules for testing migration
and more frequently de-crufting of out-of-date packages;
  * creating a mini testing/stable suite based on debian-ports.org?
where maybe only the core packages are candidates to migrate.

[0]: I'd define core packages as everything needed to install, boot, and
then build packages on that arch.  The rebootstrap project gives us some
idea of what those are;  but add to that the kernel and any bootloaders.
Being able to rebootstrap, should be part of the arch release
qualification anyway IMHO.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

John Paul Adrian Glaubitz:
> Hi Niels!
> 
> On 06/05/2016 12:01 PM, Niels Thykier wrote:
>> Beyond mips64el, we are not aware of any new architectures for Stretch.
>>
>> I kindly ask you to:
>>
>>  * Porters, please assert if your architecture is targeting Stretch.
> 
> To give some insight what's happening in Debian Ports. We have two candidates 
> which
> I think would qualify for inclusion in a stable release. There is also a third
> potential candidate for future releases of Debian once the hardware has become
> available.
> 

Thanks. :)

> ppc64:
> 
> [...]

AFAICT, it is not in unstable and I have not heard of any attempts to
bootstrap it there yet.  Who is working on it and what is the ETA?

> 
> sparc64:
> 
> [...]
> 

Thanks for the update.  For every one working on this, please keep in
mind that it can take quite a while to be set up and included in testing
(even without missing hardware).

If you are unable to acquire (promise of) the necessary hardware within
a month or two, making it into a Stretch will probably be very hard.

> sh4:
> 
> [...]
> 
> Thanks,
> Adrian
> 
> [...]

While it sounds exciting, I doubt it will be ready for Stretch (I
presume this was the "potential candidate for a future release").

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 13:00, Holger Levsen wrote:

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
   

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed
 

[...]
   

sparc64:
We are close to 11.000 installed packages.
 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?

   
I presume he is talking about source packages in the "installed" state 
in wana-build. For comparison this is currently 12153 for amd64 and 
10937 for mips.


(this leads to the interesting conclusion that about half the source 
packages in sid are arch-all only)

Re: [Stretch] Status for architecture qualification

[Christian Seiler]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
>> ppc64:
>>
>> This architecture is basically on par with the release architectures. We 
>> have over
>> 11.000 packages installed
> [...]
>> sparc64:
>> We are close to 11.000 installed packages. 
> 
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

But around 12000 of those source packages only build Arch: all packages.
If you look at amd64's buildd stats in sid, there are ~12000 source
packages in the Installed state:

https://buildd.debian.org/status/architecture.php?a=amd64=sid

i386 also has ~12000; arm64, armhf, armel, powerpc and ppc64 have ~11500
each; mipsel has ~11300 and mips has ~11000.

Arch: all has ~15000 source packages in the Installed state (but that
also counts packages that build both Arch: !all and Arch: all.

From these statistics, sparc64 appears to be a tiny bit behind mips in
terms of archive coverage, but not by much.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

There are just around 12,000 source packages with arch:amd64 in sid:

glaubitz@wuiet:~$ wanna-build -A sparc64 -d unstable --list=installed | wc -l
10828
glaubitz@wuiet:~$ wanna-build -A ppc64 -d unstable --list=installed | wc -l
10990
glaubitz@wuiet:~$ wanna-build -A amd64 -d unstable --list=installed | wc -l
12154
glaubitz@wuiet:~$

The rest is arch:all:

glaubitz@wuiet:~$ wanna-build -A all -d unstable --list=installed | wc -l
15672
glaubitz@wuiet:~$

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Holger Levsen]

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
> ppc64:
> 
> This architecture is basically on par with the release architectures. We have 
> over
> 11.000 packages installed
[...]
> sparc64:
> We are close to 11.000 installed packages. 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

Hi Niels!

On 06/05/2016 12:01 PM, Niels Thykier wrote:
> Beyond mips64el, we are not aware of any new architectures for Stretch.
> 
> I kindly ask you to:
> 
>  * Porters, please assert if your architecture is targeting Stretch.

To give some insight what's happening in Debian Ports. We have two candidates 
which
I think would qualify for inclusion in a stable release. There is also a third
potential candidate for future releases of Debian once the hardware has become
available.

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed with some fluctuation due to the frequent necessary 
binNMUs
for the Haskell packages. Moreover, yaboot, the bootloader used on many powerpc
machines is now supporting ppc64, too. So building usable debian-installer CD 
images
should be possible:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322540

Although yaboot still currently FTBFS on ppc64, so someone has to look into 
that.

Both openSUSE and Fedora provide official installation images for ppc64, 
upstream
development in the toolchain and kernel is active, too.

> http://dl.fedoraproject.org/pub/fedora-secondary/releases/23/Server/ppc64/iso/
> http://download.opensuse.org/ports/ppc/distribution/13.2/iso/

To set up buildds and porterboxes, virtual machines could be set up on the same
POWER servers that are used to provide powerpc and ppc64el machines, provided
that there are still enough resources available.

sparc64:

Since sparc (32-bit userland, 64-bit kernel) was dropped after Wheezy, 
development
focus shifted to sparc64 which is fully 64-bit. Upstream development was 
recently
picked up again and both kernel and toolchain are again in active development 
with
many developers being employed by Oracle. They have released a reference 
platform
last fall:

> https://oss.oracle.com/projects/linux-sparc/

I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
We are close to 11.000 installed packages. Missing packages include Firefox,
Thunderbird/Icedove, golang and LibreOffice to name the most important ones. I
haven't looked into golang yet, but Firefox, Thunderbird and LibreOffice have 
good
chances to be working soon. LibreOffice has just some tests failing in the 
testsuite
thanks to James Clarke who has ported the architecture-dependent code from 
sparc to
sparc64. Firefox and Thunderbird require some fixing in the JavaScript engine:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1275204

There are also some pending patches which fix binutils/gold and gcc-5/6 after 
which
even more packages should build without problems:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809509
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818934
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792921

Otherwise, many packages mostly fail to build from source because of some bad
programming practices which provokes unaligned access:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806208

To set up buildds and porterboxes, we would need new hardware. We have some 
older
SPARC Fire T2000 machines running as buildds plus one beefy SPARC-T5 (192 GiB 
RAM,
192 CPU threads), but those are not really suitable as official DSA machines. I
have reached out to Oracle and asked for hardware donations for that matter.

sh4:

This architecture is also known as SuperH and is actually no longer actively
developed and marketed by its developing company, Renesas.

However, there have been interesting developments for this architecture, it is
becoming open source and therefore potentially interesting for many Debian users
and developers who are concerned with privacy and free computing:

> https://lwn.net/Articles/647636/

This has become possible since - as explained in the article above - all patents
related to SuperH are expiring one after another meaning that the hardware can 
be
reimplemented without infringing any patents.

The current result of this effort is the J-Core project:

> http://j-core.org/

The big advantage of Super-H/J-Core over existing open source architectures like
OpenRISC is that both kernel and toolchain are already fully supported so that
Debian can be installed on these machines without any limitations.

We are currently at around 9100 installed packages, a large number of packages 
will
soon be able to build once I have finished bootstrapping GHC (the Haskell 
compiler)
which takes some time on my older SH-7785LCR hardware (still building for 14 
days).


The two biggest issues with sh4 are currently with binutils and the kernel. 
binutils
has problems when building Qt5:

> https://sourceware.org/bugzilla/show_bug.cgi?id=17739

While the kernel needs some additional syscalls to be wired up in the interface 
which
prevents gtk+3.0_3.20.x being built on sh4:

> https://bugzilla.kernel.org/show_bug.cgi?id=119121

As the SH port of the Linux kernel was recently turned into maintained state 
again
after two