On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>> 1) mechanisms need to be in place to get package
maintainers access to
>>> fix
>>> arm-specific bugs in their packages
>>
>>
>> So we have a tracker bug at the moment. Is that sufficient? If so, we
>> obviously should make sure that it is included in the proposal docs that
>> we have this in place and are using it.
>
>
> A tracker bug is certainly not sufficient. It would be for a SA, but not
> PA. Typically our users have a PA at their disposal, or failing that have
> ready access to a shared PA provided by the Fedora Project that they can log
> into and do their testing.
How was this handled in the case of PPC? My understanding is that due
to legal reasons the Fedora Project never officially provided access
to PPC machines. There were a number of machines that users could get
access to that were provided by individuals but these were never
officially provided by the Fedora project.
That is correct.
> Without ARM systems available for all the releases our
maintainers have to
> support this is a non-starter. I will also note that having to resort to
> using a remote system because the arch isn't generally locally at a
> maintainer's disposal /is/ going to introduce a delay in getting bugs
> resolved and builds out the door. If the arch was ubiquitous in a way that
> lent itself to easy debugging and use that'd be a different matter, but I
> just don't see it as being there right now.
There's a number of cheap hardware becoming available such as the
Raspberry Pi as well as development boards that are available for
either purchase or people can apply to be part of a developer program
to get either discount or free hardware. How was this supported with
PPC? The PPC hardware was a lot more expensive (either Apple devices
or IBM) than the readily available ARM devices. We can also put a
means escalation in place too for those that don't want to purchase or
can't get ready access to HW for testing.
I think you're really asking the wrong question, or maybe taking the wrong
approach. There are a number of reasons PPC was _demoted_ to a secondary
arch, and this is one of them. Asking how it was done while PPC was a PA
is just spinning your wheels. It doesn't matter.
>>> 2) excludearch is not an option. This is fundamentally
contrary to being
>>> a primary arch. In fact this is one of the defining characteristics
>>> of
>>> a secondary arch.
>>
>>
>> Let's think about this some. ARM (32-bit) doesn't do Intel-style
>> microcode, MCE, or many other things that x86 does. I don't think that
>> means we should build packages that are x86-specific for ARM systems. We
>> generally believe that we're starting from a point of good momentum, but
>> there are some packages that won't ever be appropriate for ARM, and
>> there are others where the FTBFS has been longstanding, or there are
>> other (IMO valid) reasons why it might initially be Exclude. That
>> doesn't mean that there would be many such cases. Nonetheless, I think
>> it would be unreasonable to set the entry bar so high that there can be
>> no things left to fix. That basically retains the x86 monopoly.
>
>
> Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as
> a default action when a build fails on ARM is certainly not an option. What
> would help your situation is generating a few lists of packages. One list
> would be packages that you feel just don't make sense on ARM. Another list
> would be the FTBFS you mention. These lists can be debated and decided upon
> /before/ the migration to PA and the ExcludeArches can be in place before
> the switch is pulled.
There's a couple of different categories here.
1) x86 only hardware. There's things like dmidecode, cpuid, various
ACPI, numa, EFI and other HW specific things like intel GPU drivers
where it just doesn't make sense to build on ARM, just like it didn't
make sense to build the various PPC utils etc on x86. In some cases it
might be a short term exclusion as it's expected that the support will
come to ARM, EFI is the classic case here. Others like intel GPUs
never will.
Yes. All good.
2) packages that have x86 dependent code. spice comes into this
category and I've discovered a few others. This would need work from
someone, either the Fedora maintainer or upstream.
Er... I think you forgot "or the Fedora ARM team". Seriously, if you are
counting on getting the Fedora package maintainer to fix something like
that, you are going to be disappointed. You cannot force them to fix it
and ExcludeArch is often the resolution until the arch team comes along
and fixes it.
Ultimately as the person that has done 98% of the builds and lead
the
building of rawhide the vast majority of the packages where we've
added ExcludeArch are where they are x86 or PPC only for a reason, in
fact in a lot of cases I've removed excludes (icedtea-web and a number
of other packages) to ensure we run on ARM. Where it's FTBFS on ARM
there's been bug reports and dialog with maintainers to get the issues
fixed. Most maintainers have actively assisted with this, some have
stated they don't care, in those cases we generally go and fix the
issues ourselves. In quite a few of the cases with build issues it's
actually people doing weird shit in spec files that cause the problem.
This is exactly what I meant above. You've done great work, but what you
describe is simply going to continue whether ARM is primary or secondary.
I just don't want people to think the effort you've put in thus far is
somehow going to magically decrease if ARM is promoted.
josh