Re: [Stretch] Status for architecture qualification

2016-06-28 Thread 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: Bug#827473: ostree: FTBFS on mipsel: "ostree pull" sometimes gets SIGBUS, SIGSEGV

2016-06-28 Thread Simon McVittie
Control: reopen 827473
Control: found 827473 2016.6-2

On Sun, 26 Jun 2016 at 19:54:11 +, Debian Bug Tracking System wrote:
>* New upstream release
...
>  - this version is more careful about thread-safety, which appears
>to fix the test failures that caused FTBFS on mipsel
>(Closes: #827473)

I thought this was true, and it seems to have worked on eberlin and etler
with 2016.6-1; but with 2016.6-2 (which makes no source changes, just
switches one test to LC_ALL=C) it's back to failing with sporadic
bus errors in "ostree pull" on eberlin. 5 out of 5 test runs failed,
but the test that fails in each run is different.

On Tue, 21 Jun 2016 at 11:55:29 +0100, Simon McVittie wrote:
> I'm going to try with valgrind, and if I can't get anything useful out of
> that, either ignore the test failure on mipsel, or ask for the 2016.5-3
> binaries to be removed so they don't block ostree migrating to testing
> on other architectures.

I was unable to get any useful information from valgrind either.

mips porters, is there something special that maintainers are expected
to do to be able to debug or diagnose mips-specific issues? As noted in
an earlier mail to this bug, inspecting the core dump was not helpful.
It's entirely possible that this is an ostree bug, but I'm unlikely to
be able to do anything about it without some indication of where it is.

How confident are we that these machines have reliable hardware,
and that the mipsel toolchain is reliable?

I would really like to resolve this somehow so that ostree and flatpak
can migrate to testing, either by getting enough information to be able
to diagnose and fix what is wrong, by having the mipsel binaries removed,
or by ignoring test failures on mipsel and assuming that if anyone
actually *uses* ostree there, they will also step forward to diagnose and
fix it.

S