Tomas Mraz wrote:
On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote:
4) All supported platforms must have kernels built from the Fedora
kernel SRPM and enabled by default in the spec file. Each kernel must be
built in a timely manner for every SRPM upload.
I do not like this
drago01 píše v Út 20. 03. 2012 v 17:57 +0100:
On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:37 AM, drago01 wrote:
I'm a big fan of cross compilation, but introducing it into Fedora in
order
to support ARM seems unlikely to succeed for too many
On Tue, Mar 20, 2012 at 12:05 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Brendan Conoboy wrote:
Our current build systems can turn GCC 4.7 around in about 24 hours.
The enterprise hardware we anticipate using will take that down to about
12 hours. If speed of build hardware is a
drago01 wrote:
I don't know about the details there but that does not sound like
unfixable to be.
In theory yes, in practice I don't think this will be fixed any time soon,
yet…
I'd even say that fixing that is a prerequisite to allow secondary
archs that run on slow hardware to become
Brendan Conoboy wrote:
In couple years the hardware is going to be surprisingly comparable or
exceed to what you're see on x86, especially as the number of cores
skyrockets while the GHz continue to climb.
Then let's rediscuss making ARM a primary architecture when that happens.
Right now the
drago01 wrote:
qemu? Should be still faster then doing the whole build on arm.
LOL, no!
qemu software emulation slows down by a factor of ~50! Right now ARM is
slower only by a factor of ~12.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Brendan Conoboy wrote:
Please, please, no. Cross compilation for Fedora cannot and will not
ever get a secondary arch to primary. We're talking man-decades of
engineering time to solve all the problems. Decades.
Possible. That just means ARM cannot become a primary architecture any time
On Tue, Mar 20, 2012 at 12:54:36PM -0400, Jon Masters wrote:
The hardware is way slower ... so we can just build on faster hardware
(x86_64). Which is the only sane way to do it.
Trying to build on ARM directly is kind of a gimmick but nothing one
can seriously use to build a whole
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:50 AM, drago01 wrote:
I don't know about the details there but that does not sound like
unfixable to be.
I'd even say that fixing that is a prerequisite to allow secondary
archs that run on slow hardware
On Tue, 2012-03-20 at 09:50 -0700, Brendan Conoboy wrote:
1. Fedora Policy (Which I imagine is based on the technical foundation
of the following 5+ points and others I'm unaware of).
2. Many packages assume a native execution environment which will not
exist. Incredible undertaking to
Michael Cronenworth wrote:
Kevin, you don't know what you are talking about. Every cell phone has
an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM
cpu in it. Almost every tablet has an ARM cpu in it.
Several of those are not suitable devices to run a general purpose
On 03/20/2012 10:27 AM, Kevin Kofler wrote:
Then let's rediscuss making ARM a primary architecture when that happens.
Right now the speed is just not acceptable.
Really? You're going to base your entire opinion on build time data on
inappropriate hardware for one package without knowing even
On Tue, Mar 20, 2012 at 06:29:13PM +0100, Kevin Kofler wrote:
drago01 wrote:
qemu? Should be still faster then doing the whole build on arm.
LOL, no!
qemu software emulation slows down by a factor of ~50! Right now ARM is
slower only by a factor of ~12.
Meh, at least you got something
Simo Sorce wrote:
Can you define what market you refer to ?
Anything which can be reasonably called a computer.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jon Ciesla wrote:
Only if you assume that high clock speed workloads are the only
important workloads. For highly parallellizable tasks, an ARM system
with tons of slower cores is a powerhouse. Think a db server serving
huge numbers of queries.
Unfortunately, our builds are not that
On 03/20/2012 10:44 AM, drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote:
Please, please, no. Cross compilation for Fedora cannot and will not ever
get a secondary arch to primary. We're talking man-decades of engineering
time to solve all the problems.
On 03/20/2012 11:58 AM, Brendan Conoboy wrote:
On 03/20/2012 08:24 AM, Jakub Jelinek wrote:
I think the speed of the build hardware should be also part of the criteria,
as all primary architectures are built synchronously. GCC on x86_64/i686
currently builds often in 2 hours, sometimes in 4
drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:50 AM, drago01 wrote:
I don't know about the details there but that does not sound like
unfixable to be.
I'd even say that fixing that is a prerequisite to allow secondary
archs that run
On Tue, Mar 20, 2012 at 7:05 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 10:44 AM, drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote:
Please, please, no. Cross compilation for Fedora cannot and will not
ever
get a secondary arch to primary.
Richard W.M. Jones wrote:
Meh, at least you got something to _boot_ in qemu-system-arm.
Actually, I haven't tried qemu-system-arm. The ~50 factor I quoted comes
from my past experiences running qemu-system-x86_64 on a 32-bit machine to
build x86_64 RPMs (before I got the Core 2 Duo notebook).
On 3/20/12 8:58 AM, Brendan Conoboy wrote:
I think the real question is, for the developers of on devel-list, how
will longer builds for one arch than another affect your workflow? If
builds on two architectures start at the same time, but one takes longer
to finish than the other, how will
On 03/20/2012 10:54 AM, Kevin Kofler wrote:
As far as I know, this proposal is driven by community people, not Red Hat
people.
Many people in the Fedora ARM community are Red Hat people, but that's
hardly relevant to the proposal.
We're starting now, that's what the secondary architecture
On Tue, Mar 20, 2012 at 1:02 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Jon Ciesla wrote:
Only if you assume that high clock speed workloads are the only
important workloads. For highly parallellizable tasks, an ARM system
with tons of slower cores is a powerhouse. Think a db server
On 3/20/12 11:18 AM, Brendan Conoboy wrote:
We're starting now, that's what the secondary architecture is for.
There's
no need for ARM to be a primary architecture for Fedora to be ready for
it.
No, Fedora ARM started years ago. There comes a point where a secondary
cannot continue to grow.
On 03/20/2012 11:15 AM, drago01 wrote:
As I said in the other mail I am fine with that. I just had to respond
to the man-decades hyperbole. (Maybe I should have just ignored it).
Okay, feel free to send me private mail or ask in IRC and we can
discuss, if only for academic purposes :-)
--
Brendan Conoboy wrote:
Really? You're going to base your entire opinion on build time data on
inappropriate hardware for one package without knowing even what the
factors are in the build time? What if 50% of that time was due to test
timeouts that require a simple fix? Please turn down the
On Tue, 2012-03-20 at 17:37 +0100, drago01 wrote:
On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:21 AM, Ralf Corsepius wrote:
That said, I considera cross-building environment for secondary arch to
be inevitable, which would at least help for the
On 3/20/12 8:37 AM, Tomas Mraz wrote:
I do not like this requirement. This seems to be specifically provided
to block the possibility to have ARM as a primary architecture if we do
not want to support just one or two ARM platforms. I do not really see a
problem in limiting platforms during
Jon Ciesla wrote:
On Tue, Mar 20, 2012 at 1:02 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
Jon Ciesla wrote:
Only if you assume that high clock speed workloads are the only
important workloads. For highly parallellizable tasks, an ARM system
with tons of slower cores is a powerhouse.
On 3/20/12 9:38 AM, Brendan Conoboy wrote:
I'm not sure how it would work, but if koji can be extended to
distribute a single arch build across multiple systems where an
identical srpm can be built with a koji-controlled set of flags, this
would take care of the wide-breadth of kernels needing
Once upon a time, Michael Cronenworth m...@cchtml.com said:
Kevin, you don't know what you are talking about. Every cell phone has
an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM
cpu in it. Almost every tablet has an ARM cpu in it. What do people buy
these days?
On Tue, 2012-03-20 at 18:21 +0100, Dan Horák wrote:
drago01 píše v Út 20. 03. 2012 v 17:57 +0100:
On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:37 AM, drago01 wrote:
I'm a big fan of cross compilation, but introducing it into Fedora in
On 03/20/2012 11:39 AM, Chris Adams wrote:
And how many cell phones, tablets, and TVs is Fedora ARM planning to
target? It doesn't sound like that's the target market (at least at
this time).
Indeed, targeting mobile devices on day 1 is beyond the scope of the
proposal. The first step is
Once upon a time, Brendan Conoboy b...@redhat.com said:
Indeed, targeting mobile devices on day 1 is beyond the scope of the
proposal. The first step is the eat-our-own-dogfood target, which is
self-hosting ARM servers. Mobile devices are a natural direction for
Fedora ARM, of course, but
On 03/20/2012 11:20 AM, Jesse Keating wrote:
Honestly I've yet to see a succinct list of reasons why secondary arch
is no longer good enough for the ARM effort, for at least the next few
releases. I may have missed it in the flurry of emails and debate,
anybody care to recap it for clarity?
On 03/20/2012 11:50 AM, Chris Adams wrote:
Okay, but how many ARM servers are in widespread use? For the resources
required as a primary arch, there should be a large expected user base.
The first sentence of the detailed description on the feature page is
ARM processors are the most popular
On 03/20/2012 11:16 AM, Jesse Keating wrote:
You are materially impacted. AutoQA won't run until the entire build is
complete. Updates cannot be prepared until the entire build is complete.
Buildroots won't be updated with the build results until the entire
build is complete. You won't know if
On 3/20/12 11:50 AM, Brendan Conoboy wrote:
On 03/20/2012 11:20 AM, Jesse Keating wrote:
Honestly I've yet to see a succinct list of reasons why secondary arch
is no longer good enough for the ARM effort, for at least the next few
releases. I may have missed it in the flurry of emails and
On 3/20/12 11:54 AM, Brendan Conoboy wrote:
Believe me, I want to target those CPUs, but no single proposal can
include all the steps necessary to get there. Think of ARM-on-primary
as the first of many steps designed to get us there. If you've ever
climbed a mountain you'll know that the
On Tue, Mar 20, 2012 at 2:59 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 11:16 AM, Jesse Keating wrote:
You are materially impacted. AutoQA won't run until the entire build is
complete. Updates cannot be prepared until the entire build is complete.
Buildroots won't be updated
On 03/20/2012 12:05 PM, Jesse Keating wrote:
So if you're willing to live like that, I must ask again, what do you
think you'll be getting out of being a primary arch?
I'm willing to temporarily do better than secondary and worse than
primary on the road to becoming primary. This is a huge
Brendan Conoboy wrote:
This was one of the points raised by FESCo yesterday, and it's a fine
question that we'll be answering better, elsewhere, in due course. That
said, where does this question lead? If we explain what we're trying to
get to, will it somehow overcome the objections raised
On 3/20/12 12:05 PM, Brendan Conoboy wrote:
IIf there is some sane way to distribute a single armv7hl or armv5tel
build across multiple builders that may be an interesting avenue to
pursue (Sanity tbd by releng:-). The builders we expect to see this
year have 4 cores, but if we could
Chris Tyler píše v Út 20. 03. 2012 v 14:40 -0400:
On Tue, 2012-03-20 at 18:21 +0100, Dan Horák wrote:
drago01 píše v Út 20. 03. 2012 v 17:57 +0100:
On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/20/2012 09:37 AM, drago01 wrote:
I'm a big fan of
On 3/20/12 12:14 PM, Brendan Conoboy wrote:
On 03/20/2012 12:05 PM, Jesse Keating wrote:
So if you're willing to live like that, I must ask again, what do you
think you'll be getting out of being a primary arch?
I'm willing to temporarily do better than secondary and worse than
primary on the
On 03/20/2012 12:03 PM, Chris Adams wrote:
Okay, but why is ARM-as-primary-arch an early step, and not near the
end? Increasing the developer and engineering burden across the whole
project should not be done for a small target audience.
Really there is no beginning and no end, so we're
On 03/20/2012 01:42 PM, Dave Jones wrote:
On Tue, Mar 20, 2012 at 12:54:36PM -0400, Jon Masters wrote:
The hardware is way slower ... so we can just build on faster hardware
(x86_64). Which is the only sane way to do it.
Trying to build on ARM directly is kind of a gimmick but nothing
On 03/20/2012 12:19 PM, Jesse Keating wrote:
What does better than secondary arch mean to you? I'm really
struggling here.
As an example, the same koji server handling x86 builds handling ARM
builds. The same facilities providing power, cooling, storage. Subject
to applicability, the same
On Tue, 20 Mar 2012 20:14:14 +0100
Kevin Kofler kevin.kof...@chello.at wrote:
It doesn't make sense to discuss requirements for becoming a primary
architecture without discussing whether it should be considered in
the first place. I don't see ANY reasons why it's needed. And as I
wrote in my
On Mar 20, 2012, at 1:03 PM, Jesse Keating wrote:
I hate analogies, but no, the first step is working out in a gym to make sure
you're in fit enough shape to go up the mountain.
As a distractor from long, heated threads, and mountain person - gym bunnies
get to altitude and implode
On 03/20/2012 12:44 PM, Chris Murphy wrote:
But this *requirements* thread is about acclimation, planning and anticipating
the challenges of the climb. Serious climbs may involve days or months of this.
So if the analogy holds, a lot of advance work has to be done before ARM
actually is
On 03/20/2012 03:32 PM, Brendan Conoboy wrote:
On 03/20/2012 12:19 PM, Jesse Keating wrote:
What does better than secondary arch mean to you? I'm really
struggling here.
As an example, the same koji server handling x86 builds handling ARM
builds. The same facilities providing power,
- Original Message -
From: Brendan Conoboy b...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Tuesday, March 20, 2012 9:14:11 PM
Subject: Re: RFC: Primary architecture promotion requirements
On 03/20/2012 12:05 PM, Jesse Keating wrote:
So if you're willing to live like
On Mar 20, 2012, at 1:14 PM, Kevin Kofler wrote:
It doesn't make sense to discuss requirements for becoming a primary
architecture without discussing whether it should be considered in the first
place.
Seems requirements are needed to have the discussion, to have metrics based
rather
On 3/20/12 12:32 PM, Brendan Conoboy wrote:
On 03/20/2012 12:19 PM, Jesse Keating wrote:
What does better than secondary arch mean to you? I'm really
struggling here.
As an example, the same koji server handling x86 builds handling ARM
builds.
Only the koji hub would be the same, the arm
On Mar 20, 2012, at 1:52 PM, Brendan Conoboy wrote:
Yes, the all-or-nothing mindset between secondary and primary is almost
certainly the root of the problem.
Well that and I think there's some resistance at the notion that for the
massive consumer market, the desktop is a dead
On 03/20/2012 09:15 AM, Jakub Jelinek wrote:
Looking at last gcc build times (not unusual, though I really remember
arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours
on both arm architectures), from
On 03/20/2012 01:14 PM, Andy Grover wrote:
Can Koji use distcc for ARM arches? Would that speedup be enough to make
ARM build competitive with others?
I believe this is a non-starter for rel-eng. The ARM team are not
recommending this path.
--
Brendan Conoboy / Red Hat, Inc. /
On 03/20/2012 12:15 PM, Jakub Jelinek wrote:
Looking at last gcc build times (not unusual, though I really remember
arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours
on both arm architectures), from
On Tue, Mar 20, 2012 at 06:54:07PM +0100, Kevin Kofler wrote:
Michael Cronenworth wrote:
Kevin, you don't know what you are talking about. Every cell phone has
an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM
cpu in it. Almost every tablet has an ARM cpu in it.
On Tue, Mar 20, 2012 at 11:05:20AM -0700, Brendan Conoboy wrote:
On 03/20/2012 10:44 AM, drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote:
Please, please, no. Cross compilation for Fedora cannot and will not ever
get a secondary arch to primary. We're
On 03/20/2012 01:32 PM, Przemek Klosowski wrote:
Is cross-compile an option? if it is, how long does it take to
cross-compile in an x86_64 environment?
Discussed elsewhere in this thread. Not an option.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
On 03/20/2012 01:48 PM, Richard W.M. Jones wrote:
I would suggest -- in order to move the present discussion on -- that
you try using various methods to speed up an ARM build of (eg) glibc.
distcc, some sort of demo cross-compilation, etc. What works, what
doesn't work, what needs more work?
On 03/20/2012 01:03 PM, Jesse Keating wrote:
As an example, the same koji server handling x86 builds handling ARM
builds.
Only the koji hub would be the same, the arm builders would be different
machines. This isn't all that different from having the primary hub
trigger the arm hub to start a
On Tue, Mar 20, 2012 at 02:33:57PM -0700, Brendan Conoboy wrote:
The sense I'm getting from your reply is that the PA/SA designation
is almost decorative, that a secondary can do anything a primary
can, except inhibit the progress of builds. So, if the Fedora ARM
team fixes all broken
On 3/20/12 2:33 PM, Brendan Conoboy wrote:
On 03/20/2012 01:03 PM, Jesse Keating wrote:
As an example, the same koji server handling x86 builds handling ARM
builds.
Only the koji hub would be the same, the arm builders would be different
machines. This isn't all that different from having the
Brendan Conoboy wrote:
On 03/20/2012 12:03 PM, Chris Adams wrote:
Okay, but why is ARM-as-primary-arch an early step, and not near the
end? Increasing the developer and engineering burden across the whole
project should not be done for a small target audience.
Really there is no beginning
On 03/20/2012 03:33 PM, Jesse Keating wrote:
So in principle, do you object to the same koji hub being used for ARM
if ARM is still SA?
I'm not really sure how to process that question. As a current secondary
arch, the primary hub is still the trigger point for the vast majority
of the builds
On 03/20/2012 03:33 PM, Kevin Kofler wrote:
You haven't answered his question: why would ARM-as-primary come before
Fedora-on-tablets and Fedora-on-cellphones? Those can be perfectly supported
using the secondary architecture infrastructure (or if not, we need to
improve that infrastructure).
On 03/20/2012 05:46 PM, Richard W.M. Jones wrote:
On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote:
On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboyb...@redhat.com wrote:
On 03/20/2012 09:21 AM, Ralf Corsepius wrote:
That said, I considera cross-building environment for secondary
On 03/20/2012 07:05 PM, Brendan Conoboy wrote:
On 03/20/2012 10:44 AM, drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote:
Please, please, no. Cross compilation for Fedora cannot and will not
ever
get a secondary arch to primary. We're talking man-decades of
Chris Adams wrote:
Okay, but how many ARM servers are in widespread use? For the resources
required as a primary arch, there should be a large expected user base.
The first sentence of the detailed description on the feature page is
ARM processors are the most popular CPUs in the world. but
On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote:
2) Updates. Submitting updates requires the entire build to be complete
which means you have to wait for the slowest thing to finish. Having to
wait for 12 hours effectively means you can't even test your update until
the next day, and
On 03/20/2012 04:43 PM, Xose Vazquez Perez wrote:
ARMv8 will be 64-bit and faster:
http://en.wikipedia.org/wiki/ARM_architecture#ARMv8_and_64-bit
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
It should be ready for servers and desktops, maybe, in three-four years.
But not today.
On Tue, 2012-03-20 at 13:50 -0500, Chris Adams wrote:
Once upon a time, Brendan Conoboy b...@redhat.com said:
Indeed, targeting mobile devices on day 1 is beyond the scope of the
proposal. The first step is the eat-our-own-dogfood target, which is
self-hosting ARM servers. Mobile
On Tue, 2012-03-20 at 13:03 -0700, Jesse Keating wrote:
Subject
to applicability, the same QE mechanisms being employed.
I don't see SA/PA mattering as much here. It's up to QE what they want
to take on and what they point automated tooling at.
In theory...yeah. In boring every day
On Tuesday, March 20, 2012, 7:21:25 PM, Ralf Corsepius wrote:
On 03/20/2012 05:46 PM, Richard W.M. Jones wrote:
On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote:
On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboyb...@redhat.com wrote:
On 03/20/2012 09:21 AM, Ralf Corsepius wrote:
That
On 3/20/12 5:14 PM, Adam Williamson wrote:
But sure, in theory, we can do just about anything for a secondary arch
that we do for a primary arch, I don't think there's any technical
barrier to us doing update karma for ARM and test days for ARM and a
release validation process for ARM and all
101 - 178 of 178 matches
Mail list logo
