F20 System Wide Change: ARM as primary Architecture

Tue Jul 16 13:19:27 UTC 2013

----- Original Message -----
> >> They're not the primary focus of mainline Fedora either. We're
> >> CURRENTLY focusing on development boards (100s of examples), desktop
> >> like systems (Trimslice and other similar systems), netbooks/laptop
> >> style systems and the various media centre style devices (STB/media
> >> sticks etc), and servers.
> >>
> >> The reason we're not focusing on phones/tablets at the moment is a
> >> number of reasons including things like user experience, resources and
> >> other upstream support of those style of devices. The phone/tablet
> >> manufacturers are dreadful at upstreaming things and the vast majority
> >> of devices are locked (see also the bits of this thread about ARM
> >> devices shipping Windows).
> >
> > You don't want to support devices that can't boot Linux, fair enough, but
> > there's plenty of devices where we could run Linux, given a specific
> > kernel.
> > Seeing as the Fedora rootfs that are shipped for ARM don't include a
> > kernel,
> > I don't see what the blocker is here.
> 
> All supported ARM roots images include a kernel and have done so since
> F-14 so I'm not sure where you get than information from. All our
> kernels are upstream and use the Fedora mainline kernel package.
> 
> Any image that wants to use a kernel that is a non upstream mainline
> Fedora kernel ships as a remix.

This is the rootfs for F18 (I started work on that before F19 got out):

$ tar tvJf Fedora-18-armhfp-rootfs.tar.xz | grep /boot/
drwxr-xr-x root/root          0 2013-02-02 04:28 ./usr/share/anaconda/boot/
-rw-r--r-- root/root        171 2012-09-21 19:22 ./usr/share/anaconda/boot/syslinux-splash.png
-rw-r--r-- root/root       1998 2012-09-21 19:22 ./usr/share/anaconda/boot/splash.png
-rw-r--r-- root/root       2156 2012-09-21 19:22 ./usr/share/anaconda/boot/splash.lss
dr-xr-xr-x root/root          0 2013-02-02 04:49 ./boot/

> >> Also at the moment the vast majority of the Desktop UXes are a
> >> dreadful experience on tablets whether that be x86 or ARM based.
> >
> > And not shipping something people can use to bootstrap development on those
> > devices is going to help how?
> >
> > yum install @gnome-desktop
> > probably took 3 hours on the device I tried it on, between downloading and
> > installing those packages. Fedora having those rootfs/spins available will
> > help bootstrapping the development of the UI on those devices.
> 
> I'm happy to create a remix image to assist in the bootstrap process
> for you if that makes the developers lives easier. We decided not to
> ship it as an official image because once there's an official image
> there's an expectation from standard users that it works. If you'd
> like me to assist with that can you contact me either off list or on
> the ARM list and we can make that happen.

I'm happy doing this myself, it currently needs a few packages that aren't at
the right level in Fedora (mesa for example) or things that aren't in Fedora at
all (the freedreno xf86 driver for example).

> >> All of  the above will improve in time at which point there will be
> >> more reason to focus towards that but to date we've been focusing on
> >> other areas. That's not to say others can't focus on that if that's
> >> their desire... it is after all Fedora.
> >
> > Why do you keep saying "it's not the focus" then? Why ship LXDE-based
> > rootfs
> > and not even ship similar rootfs archives for GNOME, even tagged as a
> > development
> > release?
> 
> I'm saying tablets and phones aren't the focus not that GNOME isn't
> the focus, please don't confuse the two. See above about a development
> image.

What's the focus then? Headless servers? Why compile UI at all if that's the case?
Laptops like ARM chromebooks? Then why isn't GNOME the default you ship on your
spins? If LLVM were to be fixed, the experience wouldn't be any worse than for
the devices without any 2D hardware acceleration. Or is 2D a requirement for
devices to be qualified as supported? Where's that written down?

> >> > I'm interested in Fedora on phones, tablets, tiny dongly media centers,
> >> > set-top boxes, Wi-Fi routers and eBook readers. Why wasn't I allowed to
> >> > have permissions to run image making on the ARM instances? I wanted to
> >> > create a rootfs with gnome-shell as the default, similar to the desktop
> >> > live CD, and couldn't because "it's not the focus". Why should the
> >> > package
> >> > maintainers carry the burden of maintaining packages that get compiled
> >> > on
> >> > ARM if their interests aren't "the focus"? I know I'd get yelled at if I
> >> > started adding "ExcludeArch: arm" to my packages, so why is it OK for
> >> > the
> >> > ARM SIG to dismiss other Fedora contributors' interests, and actively
> >> > block their attempts at making Fedora more available?
> >> >
> >>
> >> I'm not sure what you mean by "Why wasn't I allowed to have
> >> permissions to run image making on the ARM instances?". We decided not
> >> to ship the gnome-shell spin for this release of ARM as out of the box
> >> it wouldn't have worked
> >
> > It wouldn't have worked because nobody stepped up to fix LLVM in the ARM
> > SIG.
> >
> >> and would have hence provided a terrible
> >> experience. This was discussed in our weekly meeting.
> >
> > Tag it as a development/beta/whatever spin/rootfs and do it anyway.
> 
> People don't read that and still expect it to work.

Yeah, like they don't read which device type they have before downloading the
correct spin image. As you don't have a method of installation that works on
all ARM devices, I don't think your assessment is correct, especially for
the current target of Fedora ARM.

> >> There's nothing to stop someone doing a remix of gnome-shell with
> >> third party drivers/kernels etc but unfortunately the way the spins
> >> are build doesn't allow the use of third party repositories but this
> >> is no different to the rel-eng policy for mainline x86 but then
> >> there's nothing stopping it from being done on another ARM system and
> >> many people have created remixes for both F-18 [1] and F-19 [2] so
> >> we're not explicitly stopping you from creating a gnome-shell remix.
> >
> > Which brings me back to the question of why I haven't been allowed an
> > account to create a spin using the Fedora build servers. I doubt that
> > my 700 MHz/384 MB device is suitable for handling large packages and images
> > to create a spin.
> 
> Do you have an account on the mainline x86 koji instance to create
> images there? The lack of access to Fedora infrastructure is the same
> for all types of infrastructure whether it be ARM or x86.

If I started being responsible for doing the Desktop spin, I'm fairly
certain that I wouldn't be asked if the machine I want to install this
on is a tablet or a desktop machine.

> I don't have
> access to the ARM build servers either this isn't just you.

This makes it worse, not better...

> All the remix images to date have been created on the users own
> devices. If you are internal to Red Hat there's process to get access
> to internal infrastructure but you've not approached me about any form
> of access to any sort of stuff or even approached me about options
> available to create images, nor have you asked a question on the ARM
> mailing list and I've not seen any queries on IRC (not to say I've not
> missed it).

I'm not interested in Red Hat internal infrastructure. The work I'm doing
on ARM isn't for Red Hat (even if it will benefit it in the longer term).
I'm interested in GNOME, and Fedora is what I hoped to be a helpful way to
bootstrap the work I want to do for GNOME.

> >> We've not been "dismiss other Fedora contributors' interests, and
> >> actively block their attempts" in fact we actively encourage people
> >> that are interested in rolling up their sleeves and helping out in
> >> their particular interest area. You've emailed me directly about how
> >> to create remixes and I've provided you details on how to do that and
> >> if there's someone else who is causing issues please contact me off
> >> list and I'll address that particular issue but I fail to see our
> >> decision to not ship a spin that doesn't currently work as blocking
> >> others ability to remix a spin as they choose as many others have
> >> successfully done so.
> >
> > If it were an x86/x86-64 spin I wanted to create, I have access to plenty
> > of machines, plenty of power, and plenty of storage. This isn't my case for
> > ARM.
> >
> > If somebody were to send me an ARM device on which I can plug 4GB of RAM
> > and a
> > SATA hard-drive, I wouldn't be asking why I didn't get access to this build
> > service to create spins. That's again not the case.
> 
> Who did you ask? I've not seen any queries on the mailing lists about
> this problem. Have you asked internally what infrastructure there is
> to Red Hat people?

I didn't ask anyone, because I didn't think I'd need one more machine on my
desk (or something that wasn't accessible by upstream community members I work
with).

> >> As for "burden of maintaining packages that get compiled on ARM" I
> >> don't believe you've had any extra burden, there have been very few
> >> GNOME packages that have had compile issues on ARM and I believe for
> >> the vast majority of those few that have the ARM team have fixed them
> >> without any intervention required.
> >
> > Except the shell doesn't run, so we wouldn't know.
> 
> The shell does run with closed drivers so we do, it's been seen as
> running by Rob Clarke as well on devices and there's a lot of gnome
> that is usable with out the shell.

Rob's work doesn't use closed source drivers. It uses non-upstream drivers (msm)
and open-source user-space bits (which I intend on submitting when I have
a way to test them).

> Ultimately I'm happy to help with your issues whether that be
> appropriate access to HW for you to build images yourself or
> assistance by spinning images on my own HW. Access to the Fedora ARM
> build infra is limited to core infra people and that's the same across
> both mainline and non mainline stuff but please post the questions and
> queries about this to the ARM mailing list or email me so it doesn't
> get lost because this is the first time I'm aware of your issues other
> than the email you sent me about how to build an image which I replied
> to you with the details and never heard anything further.

I went to the fedora ARM IRC channel, and asked for access to build spins. I
was just plainly refused access because the device I was interested in was a
phone, so that was the end of it. I've not needed to create the spins yet (there's
still trouble with the GPU drivers), but when they do work, that's where I'll be
blocking.