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