so are you materially impacted?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
eate a ring 0 minimal
compose since we already need to check repoclosure? This might be a
great way to refactor primary/secondary such that we can gracefully
transition i686 down and secondary arches up. Lots of opportunities,
much to consider.
--
Brendan Conoboy / Red Hat, Inc. / b...@redh
On 08/31/2015 11:41 AM, Simo Sorce wrote:
On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:
On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]
Minutes:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html>
Minutes
Re-sending this with a better title so people might read it ;-)
On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]
Minutes:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.h
that does pass repoclosure, the
remaining subpackages go into a second repository with less strict
requirements.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
On 09/02/2015 12:24 PM, Adam Miller wrote:
On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
For today's meeting we didn't really use zodbot minute keeping
features, so in the interest of sparking some discussion I'd like to
recap.
At Flock 2015 there was a 2 hour session on the s
On 09/02/2015 12:24 PM, Josh Boyer wrote:
On Wed, Sep 2, 2015 at 2:59 PM, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
I read it last week. Perhaps the lack of commentary isn't because of
the title. It's because there is nothing new
On 09/02/2015 12:31 PM, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
Yes, thanks -- I admit to having skimmed over it in my mail-catchup
attempt.
especially how the rings interact. As
On 09/02/2015 12:47 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
Yes, thanks -- I admit to having skimmed over it in my mail
On 09/02/2015 02:14 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 13:57 -0700, Brendan Conoboy wrote:
On 09/02/2015 12:47 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a
On 09/07/2015 05:21 AM, Miloslav Trmac wrote:
2015-09-02 23:24 GMT+02:00 Brendan Conoboy mailto:b...@redhat.com>>:
[blc]
>> 5. Ring membership is at the source package level, not the binary
>> package. If one source package's binary/noarch sub-package is in
first class OS for
languages where rpm packaging doesn't make sense is great!
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ing 0 than ring 1? What happens
when a bug in ring 0 requires a fix in ring 1, but the support window
for ring 1 has closed? That's the main thing that's worrying about a
free-for-all with self hosting.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
deve
On 09/07/2015 05:34 AM, Miroslav Suchý wrote:
Dne 2.9.2015 v 20:59 Brendan Conoboy napsal(a):
5. Ring membership is at the source package level, not the binary
package. If one source package's binary/noarch sub-package is in ring
0, all sub-packages are in ring 0.
So we are going to in
On 09/14/2015 11:40 PM, Miroslav Suchy wrote:
Dne 14.9.2015 v 23:10 Brendan Conoboy napsal(a):
/Then/ we could start thinking about /truly minimal/ concepts,
perhaps “container minimal” = “the minimal set needed to start and
run an executable dependent on Fedora ABI” (e.g. kernel version
On 09/15/2015 07:27 AM, Matthew Miller wrote:
On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote:
Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we
offer a longer term of support for ring 0 than ring 1? What happens
when a bug in ring 0 requires a fix
On 09/15/2015 07:51 AM, Josh Boyer wrote:
On Tue, Sep 15, 2015 at 10:27 AM, Matthew Miller
wrote:
On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote:
Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we
offer a longer term of support for ring 0 than rin
On 09/15/2015 07:26 AM, Colin Walters wrote:
'On Mon, Sep 14, 2015, at 05:12 PM, Brendan Conoboy wrote:
I'm just one person with an opinion, it would be best if everybody
with a stake took part in the ring definitions. Creating additional
rings that address communities where self-ho
er to support ARM seems unlikely to succeed for too many reasons to
go into. Let's figure out how to make native compilation work *better*,
how to make koji work *better* when more architectures are involved than
just x86.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing
ss 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 to be built.
We've also had some success with distcc, but have not proposed using it
as reproducability of builds becomes an issue.
--
o climb. It's not a gimmick, we're
just preparing for the future before it gets here. The only problem we
face is that those cores are in multiple CPUs so we can't 'make -j' our
way out of the build system problem.
--
Brendan Conoboy / Red Hat, Inc.
mpilation 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.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapro
. What's your
slowest building package? We can probably extrapolate how long it will
take to build with first generation ARM server hardware. From there we
can talk about how that affects you work flow as well as how to handle
it being delayed. Thanks,
--
Brendan Conoboy / Red Hat, Inc.
On 03/20/2012 10:44 AM, drago01 wrote:
On Tue, Mar 20, 2012 at 5:56 PM, 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.
and even this old Pentium 4 is faster than a
"fast" ARM machine.)
I sincerely doubt it. Compare specs to a Tegra 3 chip. And that's just
a mobile system.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
c purposes :-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
st 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 as with every new direction there are a
different set of challenges to be worked through. For now we're just
talking about the core OS.
--
d by us ARM
aficionados. Again, I understand that there do need to be good reasons,
that's just not the subject of this particular thread. So, other than
build system performance, what are the requirements you'd like to see met?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
dev
igned to get us there. If you've ever
climbed a mountain you'll know that the trick getting to the top is to
put one foot in front of the other. This is just a step along the way.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@list
asible with a bit of retooling,
or a nightmare waiting to happen? The discussion so far has focused
almost exclusively on build time. We hear you. Let's talk about what
to do about it. And what concerns there are besides build time.
--
Brendan Conoboy / Red Hat, Inc. / b..
t work reliably is a proposal unto itself.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
od as x86 and you're
there." That's not productive. There are legitimate issues with moving
to PA so we're having this discussion to identify them and ultimately
work through them.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedorapro
fficiently
and smoothly on embedded devices. That's okay, it's nice to have
followup projects. Meanwhile ARM servers are going to be important too.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
e're trying to
get from the thread.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ut how
to make those improvements needs to be worked out.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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. / b
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
devel
d integrity for performance and that's not an acceptable
condition for PA.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
w them as the authoritative feedback of
Fedora-devel for our planning purposes. On the other hand, if they've
left anything out that should be considered in this plan, I'd like to
see it.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
re
usually considered by FESCo when FESCo makes a decision, and generally
considered by those proposing something and asking for feedback on their
way to a FESCo decision.
Yep. Regards,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
cell
phone running.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
ARMv8 is not contemplated in this proposal as it is so far out.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
es will go along way toward
giving packagers what they need and plan to update the proposal to say
so, subject to the feedback we get on this point.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
This is more of a multi-developer happy item.
2. Total turnaround time on security updates.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/21/2012 11:18 AM, drago01 wrote:
But there seems to be a huge oppositions against that in Fedora.
How does Ubuntu build there ARM builds? Native or using cross compilers?
Native.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
real SATA).
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
n the promise
that they'd eventually meet the Maastricht criteria. Let's not do the same
mistake in Fedora!
What?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
speaking, if presented with an ARM system that builds
packages, on average, 3x faster than x86, will you advocate that x86 be
dropped to secondary and ARM be PA exclusively? Sure it's hypothetical,
but if that one variable changes, how does your position change?
--
Brendan Conoboy / Red Hat
logy. :-) )
I know what's happening in Greece. I don't know why you're bringing it
up here.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ussion and it's easy to see room for
somebody taking offense at your analogy, Let's act like we're all on
the same side. We are, after all, all working on Fedora.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://a
o
Fedora's ability to support mobile devices including ARM laptops,
tablets, and phones. But it's a much longer journey to run Fedora on a
phone than it's going to be to run it on a server.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedora
be servers that double as power-user desktops. There is literally no
reason for anything in-between.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
alpha 1 image. The pointer is it:
http://fedoraproject.org/wiki/Architectures/ARM
We'll have the document updated for this soon. I've set reply-to to the
arm list since the responsible parties are all there.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing
sumption devices can also be used for
content creation. It's the hardware that the majority of all future
developers-in-potential are going to own.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
evices and UEFI for
servers. Jon's prognostications are regarding the long view (years).
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
has in-fact fulfilled the requirements for PA, as agreed to
by all parties at the time of application. If those requirements are
deemed to have been met, promotion is automatic.
There could be a deadline on application acceptance: EG, 12 months from
acceptance of application to fulfillment of criteria. This protects
against criteria becoming stale.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/03/2012 04:58 AM, Josh Boyer wrote:
On Apr 2, 2012 11:10 PM, "Brendan Conoboy" mailto:b...@redhat.com>> wrote:
> All builds must occur on Fedora-maintained build servers.
>
> FYI, this will require an additional koji-hub for each architecture
trying to mov
infrastructure reliability.
Switching koji hubs twice does incur a bit more work, but it may also
provide better results.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/03/2012 12:02 PM, Josh Boyer wrote:
Erm... you already have this. So will any SA making a transition. I
don't see a problem.
Outside PHX, yes. Inside, no.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
On 04/03/2012 12:10 PM, Kevin Fenzi wrote:
I'll note again that the ppc and s390 secondary arch hubs are in fact
in phx2. ;)
You're already one step ahead of ARM ;-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject
d z". If the answer is "FESCo will say how
to keep everybody informed" then let's have the proposal state that.
Basically, I think the guidelines MJG has put together are good
principles; they just need some procedural blanks filled in so SA teams
know how to apply them an
please put it in the
document and include some examples. The word "communicate" doesn't
exist in the current document.
I'm open to providing what I think are reasonable examples if they may
ultimately make it into the end document.
--
Brendan Conoboy / Red Hat, Inc. /
appreciate wider feedback on
message ID 4f8c8416.4000...@redhat.com from yesterday.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ave not, been ported, agree.
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
Okay, please clarify in the document.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nk that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
Okay, please clarify in the document.
Ok.
Thanks!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
d
members of the Fedora community. A secondary architecture should be led
by people who already know how to do that.
Volunteers welcome.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nse to ignore the answer to the question.
Not really. You could potentially satisfy number 8 without satisfying
number 5, and you could satisfy number 5 without satisfying number 8.
As you like.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/18/2012 10:12 PM, Matthew Garrett wrote:
On Wed, Apr 18, 2012 at 09:57:19PM -0700, Brendan Conoboy wrote:
On 04/18/2012 07:13 PM, Matthew Garrett wrote:
The kernel team may have their view skewed by how likely they think it
is that a given architecture will be likely to force additional
xperience across all PAs to the extent technically sensible.
Maybe something else will supplant anaconda in time.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
binson,
jskarvad, djdelorie, jonmasters, jsmith, jmontleon, ctyler, maxam, and
the rest of the Seneca crew for testing images, providing feedback, and
making today a great success.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
qemu, it worked.
Great!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
mplug, guruplug) for
the final beta spin, so it was not included. We are generating them
every night though, so if you'd like to try a *completely untested*
Kirkwood image, you'll find one at the following location:
http://scotland.proximity.on.ca/arm-nightlies/
--
Brendan Conoboy / Re
different, with the hope that they would be reduced
over time, allowing eventual merging of the toolchains?
Why have more than one gcc or binutils for arm-eabi at all? Just add
multilibs for the extra variants of interest. You can even split the
multilibs out into subpackages if it matters.
than necessary.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Monday's testing the latest nightlies
have fixes for all blockers from yesterday's RC1. The images can be
retrieved from:
http://scotland.proximity.on.ca/arm-nightlies/
Cheers,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject
On 06/18/2012 10:18 AM, Adam Williamson wrote:
Sorry for the self-reply, but just in case it's not brutally clear yet,
I wanted to explicitly state this:
[snip]
Bravo!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
nts- Fesco is clearly open to and expecting this, so
if you have an idea on how to further improve the bundling policies,
please propose it. In this way Fedora gets better and better over time.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing
On 10/08/2015 03:32 PM, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 09 October 2015 at 00:14, Brendan Conoboy wrote:
On 10/08/2015 08:48 AM, Haïkel wrote:
[snip]
Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any propo
eir package set to the utmost, they would be able to do so
without creating fake stub packages or using hacks to get around requires.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote:
For docker containers, or containers, which don't want systemd, the current
"Requires: systemd" in a lot
On 12/17/2015 04:22 PM, Adam Williamson wrote:
On Thu, 2015-12-17 at 16:13 -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote:
For docker containers, or containers, which don't want systemd, the current
"Requires: systemd" in a lot of packages is preven
On 12/17/2015 05:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 05:34:31PM -0800, Brendan Conoboy wrote:
On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote
27;s formally asked. Everything else is opinion.
Some of it informed: attorneys, some of it educated guessing (devoted
groklaw readers), some of it blindingly ignorant. Wherever each member
of de...@l.fpo falls on that spectrum, the odds are they shouldn't be
giving legal advice becaus
On 10/30/2012 02:58 PM, David Airlie wrote:
Should we just skip F18? (like seriously).
Seems a little over the top. Why not use the extra time to squash other
bugs, making F18 a better release overall?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel
upports interactive anaconda installs over serial. Or vnc
installs if you want graphics. Or kickstart installs if you want
automation.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it's inevitable, but I would like to avoid a reprisal of the
Richard Dawkins & Wendy Wright debate. What evidence are you asking for?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3. After #1 and #2 are complete, we can talk about what else is needed.
I would say you're setting the bar too high, but it has passed the event
horizon so evidence of its supposed existence is hard to come by. If
this is not what you mean to be conveying please demonstrate otherwise.
d, but if all goes well this one will be
popular in hindsight :-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
em. We're talking about cutting out the middle man.
6. It simplifies releng and infrastructure in that there is one less
secondary to handle, one less koji server to maintain, one less set of
firewall exceptions to honor, and whatever else goes into maintaining
the distinction.
ch a good job that Fedora already
has ARM on the same day as x86 and PowerPC.
Fair enough!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
fully featured. Specifically stack guards are present but
pointer guards are not. This was news to all of us. It's disappointing
that the issue was not brought to the ARM team's attention prior to the
F20 promotion discussion being introduced.
--
Brendan Conoboy / Red Hat, Inc. / b...@re
is that there are relatively major Fedora features that we've
advertised in big letters in the relatively recent past that simply
don't work because nobody has paid any attention to whether or not they
work.
Hmm.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing l
libGL because it's not a
requirement for headless deployment scenarios. Why would you argue for it?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nt in what
is protected against, albeit less efficient?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
this on a Cubieboard?
I'm not aware of the current remix situation on F19- Perhaps Hans will
comment?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
primary build system I would say let's drop
graphics from official Fedora ARM support for the purposes of the move
and make all graphical images respins or remixes.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
s out of line? There are a lot more people
with ARM devices than x86. Sorry everybody, we're going to have to
demote x86. ;-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3.9 GA
kernel, but are in the 3.10 update. This means Arndale should be fully
supportable in Fedora 20. Meanwhile, there is an F19 remix for Arndale
using a later kernel:
http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes
Kudos to Jon Disnard for putting this together.
--
Brenda
On 07/15/2013 10:15 AM, Chris Tyler wrote:
I think that's s/Arndale/Chromebook/
Same SoC, different peripherals sticking out.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
e graphics would it still be essential for PA
promotion that libGL for ARM work and be accelerated? There is no
proposal to throw out the baby or the bathwater. This is about defining
the threshold at which point armv7hl gets built along side i686 and x86_64.
--
Brendan Conoboy / Red Hat, Inc.
1 - 100 of 163 matches
Mail list logo
