ARM as a primary architecture

Josh Boyer jwboyer at
Wed Mar 21 13:04:42 UTC 2012

On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson <pbrobinson at> 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.


More information about the devel mailing list