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
 : :'  :
 `. `'`
   `-