> Any image that wants to use a kernel that is a non upstream
> Fedora kernel ships as a remix.
This is the rootfs for F18 (I started work on that before F19 got out):
We no longer support a rootfs tarball because it caused more problems
than it solved.
> I'm happy to create a remix image to assist in the bootstrap
> 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).
OK, ultimately I was offering to provide you an image where you can
then add your own local repos and just have to update the missing
> I'm saying tablets and phones aren't the focus not that
> the focus, please don't confuse the two. See above about a development
What's the focus then? Headless servers? Why compile UI at all if that's the
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've already covered the current targets earlier in the thread in
response to one of your other replies.
> > Tag it as a development/beta/whatever spin/rootfs and do it
> 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.
That's your opinion, other people have theirs.
> Do you have an account on the mainline x86 koji instance to
> 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.
Not sure what you mean here. There isn't open access to Fedora's build
infrastructure to ensure security of the builds. My point about access
to the infrastructure is that it's got nothing to do with doing builds
but to do with ensuring the security of the overall build platform to
ensure the packages and hence the distribution is what it says it is
and can be trusted.
> I don't have
> access to the ARM build servers either this isn't just you.
This makes it worse, not better...
It comes down to the security of the infrastructure and is completely
off topic for this thread. Access is granted presumably on RBAC
rulesets. Those that need access have it, those that don't don't. It's
a fairly standard IT systems policy. There's probably also some legal
in there as well, I don't particularly care.
> 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.
At the moment we don't provide that infrastructure, it's something
we're looking at providing but the security issues need to be sorted
> Who did you ask? I've not seen any queries on the mailing
> 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
OK, so I'm not sure what the issue is here. Most of this is now off
topic but feel free to open a thread on the ARM mailing list about it.
> The shell does run with closed drivers so we do, it's been
> 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).
I know Rob's work isn't closed source, I was referring to another
unrelated driver. It was meant to be two examples of it working.
> Ultimately I'm happy to help with your issues whether that
> 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
still trouble with the GPU drivers), but when they do work, that's where I'll be
I didn't see the conversation but as I've stated above there's no
general access to the Fedora build infra but this isn't anything to do
with phones (and not being there I have no idea of the comms and I
can't find your IRC nick in my proxy server channel logs) but rather
security and other related stuff.