8 a.m.
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
<pbrobinson(a)gmail.com>
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
that we build and support. This will mean that all packages supported by the
ARM architecture must build for ARM to be released. With the release of Fedora
19 we have deprecated support for software floating support (ARMv5tel sfp) so
the only proposed addition to primary architectures is currently ARMv7
hardware floating point 32 bit support (ARMv7 hfp 32bit).
== Detailed description ==
The Changing IT landscape has started to focus on greener technologies as well
as cheaper mass produced devices that allow for fully functional cheap devices
for lower socio-economic areas and other markets like education and "makers".
ARM SoCs have traditionally been the domain of embedded and mobile
applications but are now finding their way into more traditional computing
devices like desktop, notebook and server markets. Fedora ARM currently works
on many different devices with wider support coming with each new mainline
kernel release.
For this change we will enable armv7hl builds on primary koji, and compose arm
trees as with the other primary architectures. Fedora has in the Phoenix data
centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will
remain allocated to the arm secondary architecture koji instance for building
updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of
life the ARMv5 softfp nodes will able to be be reallocated to other tasks.
Infrastructure has expressed an interest in testing and experimenting with
some of its workloads on ARM, some are allocated to QA and some for releng.
There is currently 24 nodes configured in primary koji ready to go as builders,
there is the capacity to add up to 24 more when ARM becomes primary if
desired.
The kernel is now a multi platform unified ARMv7 kernel supporting a number of
SoCs with support expanding with each new upstream release. We build a base
and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64)
kernel maintainer working in collaboration with the Fedora kernel team. The
releases are composed using the exact same tooling as used for the primary
architectures. Disk images for development boards are generated by appliance-
creator and the kickstarts live in spin-kickstarts, they take a similar format
as the livecds on primary but are shipped as an OEM disk image, and like
primary initial-setup is used to do final user configuration. Like primary pungi
is used to generate an install tree, PXE install trees are created but current
bootloaders don't support isofs so ISO images aren't currently created.
== Scope ==
Add armv7hl to list of arches for f20-build and future build tags in koji
compose armhfp trees with i386 and x86_64. Requisite build hardware already
exists in phx2 and is configured to work with mainline koji.
Proposal owners: change the arches in koji, import the matching ARMv7 rawhide
builds into koji. Update Release Engineering scripts to automatically build
armhfp trees along with i686 and x86_64.
Other developers: submit builds as normal, in the event of unexpected build
failures liaise with the ARM Team to help debug and fix issues.
Release engineering: Will need to add armhfp to the release processes and make
arm install trees and disk images with each milestone compose. Release
Engineering are part of the team of people proposing the Change.
Policies and guidelines: armv7hl builds will be required to complete for
builds to be successful in koji
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10:32 a.m.
Excellent proposal. I of course think this would be just awesome!
--
Sent from my iPad
On Jul 9, 2013, at 15:37, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
<pbrobinson(a)gmail.com>
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
that we build and support. This will mean that all packages supported by the
ARM architecture must build for ARM to be released. With the release of Fedora
19 we have deprecated support for software floating support (ARMv5tel sfp) so
the only proposed addition to primary architectures is currently ARMv7
hardware floating point 32 bit support (ARMv7 hfp 32bit).
== Detailed description ==
The Changing IT landscape has started to focus on greener technologies as well
as cheaper mass produced devices that allow for fully functional cheap devices
for lower socio-economic areas and other markets like education and "makers".
ARM SoCs have traditionally been the domain of embedded and mobile
applications but are now finding their way into more traditional computing
devices like desktop, notebook and server markets. Fedora ARM currently works
on many different devices with wider support coming with each new mainline
kernel release.
For this change we will enable armv7hl builds on primary koji, and compose arm
trees as with the other primary architectures. Fedora has in the Phoenix data
centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will
remain allocated to the arm secondary architecture koji instance for building
updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of
life the ARMv5 softfp nodes will able to be be reallocated to other tasks.
Infrastructure has expressed an interest in testing and experimenting with
some of its workloads on ARM, some are allocated to QA and some for releng.
There is currently 24 nodes configured in primary koji ready to go as builders,
there is the capacity to add up to 24 more when ARM becomes primary if
desired.
The kernel is now a multi platform unified ARMv7 kernel supporting a number of
SoCs with support expanding with each new upstream release. We build a base
and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64)
kernel maintainer working in collaboration with the Fedora kernel team. The
releases are composed using the exact same tooling as used for the primary
architectures. Disk images for development boards are generated by appliance-
creator and the kickstarts live in spin-kickstarts, they take a similar format
as the livecds on primary but are shipped as an OEM disk image, and like
primary initial-setup is used to do final user configuration. Like primary pungi
is used to generate an install tree, PXE install trees are created but current
bootloaders don't support isofs so ISO images aren't currently created.
== Scope ==
Add armv7hl to list of arches for f20-build and future build tags in koji
compose armhfp trees with i386 and x86_64. Requisite build hardware already
exists in phx2 and is configured to work with mainline koji.
Proposal owners: change the arches in koji, import the matching ARMv7 rawhide
builds into koji. Update Release Engineering scripts to automatically build
armhfp trees along with i686 and x86_64.
Other developers: submit builds as normal, in the event of unexpected build
failures liaise with the ARM Team to help debug and fix issues.
Release engineering: Will need to add armhfp to the release processes and make
arm install trees and disk images with each milestone compose. Release
Engineering are part of the team of people proposing the Change.
Policies and guidelines: armv7hl builds will be required to complete for
builds to be successful in koji
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:30 p.m.
New subject: Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)
On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote:
Excellent proposal. I of course think this would be just awesome!
This proposal doesn't address virtualization!
I think this is great, BUT I'd also like to see a widely available
cheap ARM platform that supports virtualization, AND for which
virtualization genuinely works out of the box.
Because, otherwise we can't start properly getting libvirt and the
rest of the virt stack working.
The ARM-based Samsung Chromebook[0] is nearly there, although as
discussed on the arm list last week[1], there are either some missing
bits, or no one's brought all the bits together.
Rich.
[0] Cost around $300, and several virt developers have them already,
plus they are quite good Fedora development machines in and of
themselves.
[1] https://lists.fedoraproject.org/pipermail/arm/2013-July/thread.html#6319
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
5:15 p.m.
New subject: Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)
On Wed, 10 Jul 2013, Richard W.M. Jones wrote:
On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote:
> Excellent proposal. I of course think this would be just awesome!
This proposal doesn't address virtualization!
I think this is great, BUT I'd also like to see a widely available
cheap ARM platform that supports virtualization, AND for which
virtualization genuinely works out of the box.
Because, otherwise we can't start properly getting libvirt and the
rest of the virt stack working.
I was intending to update xen on Fedora 20 to the newly released
xen-4.3.0. This adds ARM support as a technology preview, though I don't
know if this meets your requirements.
Michael Young
2:58 a.m.
New subject: Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)
On Wed, Jul 10, 2013 at 11:15:37PM +0100, M A Young wrote:
On Wed, 10 Jul 2013, Richard W.M. Jones wrote:
>On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote:
>>Excellent proposal. I of course think this would be just awesome!
>
>This proposal doesn't address virtualization!
>
>I think this is great, BUT I'd also like to see a widely available
>cheap ARM platform that supports virtualization, AND for which
>virtualization genuinely works out of the box.
>
>Because, otherwise we can't start properly getting libvirt and the
>rest of the virt stack working.
I was intending to update xen on Fedora 20 to the newly released
xen-4.3.0. This adds ARM support as a technology preview, though I
don't know if this meets your requirements.
I've not tried it, but apparently Xen have sorted out all the issues
with hardware virt on the Chromebook (the "issues" being some u-boot
hacking is needed).
However for Fedora, I'm really talking about KVM. For libguestfs and
the virt-tools we don't currently support Xen.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
11:54 a.m.
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
How many F19 packages currently fail to build (or are excluded but
shouldn't be) on ARM? How do we stand against the other items of
https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
?
Mirek
11:57 a.m.
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
> = Proposed System Wide Change: ARM as primary Architecture =
> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
How many F19 packages currently fail to build (or are excluded but
shouldn't be) on ARM? How do we stand against the other items of
https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
At F-19 gold we were missing around 233 source packages out of around
13,500 total. These are broken down into a couple of groups:
- Non ARM packages (x86/PPC/s390)
- Languages not currerntly supported on ARM - eg D, a fpc and a few others
- Packages that have issues with their CFLAGS (and actually should be
fine if they used distro flags like they should)
- Random other problems.
I'm planning on going through these again and document the remaining packages.
Peter
12:22 p.m.
On 9 July 2013 10:57, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač <mitr(a)volny.cz>
wrote:
> nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik <jreznik(a)redhat.com>
wrote:
>> = Proposed System Wide Change: ARM as primary Architecture =
>> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
>
> How many F19 packages currently fail to build (or are excluded but
> shouldn't be) on ARM? How do we stand against the other items of
>
https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
At F-19 gold we were missing around 233 source packages out of around
13,500 total. These are broken down into a couple of groups:
- Non ARM packages (x86/PPC/s390)
- Languages not currerntly supported on ARM - eg D, a fpc and a few others
- Packages that have issues with their CFLAGS (and actually should be
fine if they used distro flags like they should)
- Random other problems.
I'm planning on going through these again and document the remaining
packages.
How do we treat "Desktop" items where the package compiles fine but does
not run well without external drivers (the GNOME on ARM conversation
earlier ) Or am I misreading that conversation.
--
Stephen J Smoogen.
12:31 p.m.
On 9 July 2013 10:57, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
>
> On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
> > nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik <jreznik(a)redhat.com>
> > wrote:
> >> = Proposed System Wide Change: ARM as primary Architecture =
> >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
> >
> > How many F19 packages currently fail to build (or are excluded but
> > shouldn't be) on ARM? How do we stand against the other items of
> >
> > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
>
> At F-19 gold we were missing around 233 source packages out of around
> 13,500 total. These are broken down into a couple of groups:
> - Non ARM packages (x86/PPC/s390)
> - Languages not currerntly supported on ARM - eg D, a fpc and a few others
> - Packages that have issues with their CFLAGS (and actually should be
> fine if they used distro flags like they should)
> - Random other problems.
>
> I'm planning on going through these again and document the remaining
> packages.
>
How do we treat "Desktop" items where the package compiles fine but does not
run well without external drivers (the GNOME on ARM conversation earlier )
Or am I misreading that conversation.
The same way as we do now. In some cases there are drivers but they're
still in development and not stable (tegra/lima/freedreno), or there's
third party binary drivers (like mainline with the nVidia binary
drivers). The situation is improving rapidly for the 2D/3D accelerated
situation and in the mean time there are numerous other desktops that
run perfectly well. In time I'm sure we'll get to 100% parity with the
mainline platform but I don't believe anyone believes we're there now
but I don't see that as a blocker either.
Peter
12:34 p.m.
On Tue, 2013-07-09 at 18:31 +0100, Peter Robinson wrote:
> How do we treat "Desktop" items where the package
compiles fine but does not
> run well without external drivers (the GNOME on ARM conversation earlier )
> Or am I misreading that conversation.
The same way as we do now. In some cases there are drivers but they're
still in development and not stable (tegra/lima/freedreno), or there's
third party binary drivers (like mainline with the nVidia binary
drivers). The situation is improving rapidly for the 2D/3D accelerated
situation and in the mean time there are numerous other desktops that
run perfectly well. In time I'm sure we'll get to 100% parity with the
mainline platform but I don't believe anyone believes we're there now
but I don't see that as a blocker either.
I disagree with that. I'd at least want to see a plan for how we plan to
address the graphics situation. If the answer is that we have to live
with software rendering for now, then we should have somebody working on
making llvm work on arm again.
noon
On Tue, Jul 9, 2013 at 12:54 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
> = Proposed System Wide Change: ARM as primary Architecture =
> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
How many F19 packages currently fail to build (or are excluded but
shouldn't be) on ARM? How do we stand against the other items of
https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
?
I'm particularly curious about the developer resources and release
criteria items. The proposal calls out one kernel maintainer, which
is great, but doesn't expand on how many others are doing ARM work.
Is the ARM team on the hook to go through all of the existing QA
criteria on ARM platforms and do they have enough resources to do
this?
I have a secondary concern on kernel build times. It's greatly
improved on the newer hardware, but a primary kernel build takes ~ 1hr
45min. An ARM build, which doesn't even build the -debug variants,
still takes ~4 to 4.5hrs. Are other larger packages (gcc, etc)
similarly significantly slower still? How much delay ARM adds to a
build is certainly up for discussion but it would be good to have
numbers showing the average additional time required per package and
the worst case outliers.
josh
12:24 p.m.
On Tue, Jul 09, 2013 at 01:00:27PM -0400, Josh Boyer wrote:
>> = Proposed System Wide Change: ARM as primary Architecture
=
>> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
>
> How many F19 packages currently fail to build (or are excluded but
> shouldn't be) on ARM? How do we stand against the other items of
> https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
> ?
I'm particularly curious about the developer resources and release
criteria items. The proposal calls out one kernel maintainer, which
is great, but doesn't expand on how many others are doing ARM work.
Is the ARM team on the hook to go through all of the existing QA
criteria on ARM platforms and do they have enough resources to do
this?
I wouldn't limit the things I'm willing to fix to the kernel. I'll
happily look into all ARM FTBFS.
--Kyle
12:33 p.m.
On Tue, Jul 9, 2013 at 6:24 PM, Kyle McMartin <kyle(a)redhat.com> wrote:
On Tue, Jul 09, 2013 at 01:00:27PM -0400, Josh Boyer wrote:
> >> = Proposed System Wide Change: ARM as primary Architecture =
> >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
> >
> > How many F19 packages currently fail to build (or are excluded but
> > shouldn't be) on ARM? How do we stand against the other items of
> > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements
> > ?
>
> I'm particularly curious about the developer resources and release
> criteria items. The proposal calls out one kernel maintainer, which
> is great, but doesn't expand on how many others are doing ARM work.
> Is the ARM team on the hook to go through all of the existing QA
> criteria on ARM platforms and do they have enough resources to do
> this?
>
I wouldn't limit the things I'm willing to fix to the kernel. I'll
happily look into all ARM FTBFS.
There's a number of people working on this but ultimately like all
problems we can handle as much as possible but we also need assistance
by the package maintainers themselves.
Peter
12:43 p.m.
On Tue, Jul 09, 2013 at 06:33:53PM +0100, Peter Robinson wrote:
There's a number of people working on this but ultimately like
all
problems we can handle as much as possible but we also need assistance
by the package maintainers themselves.
No, that's not how it works. While you're a secondary architecture you
get to take responsibility for making stuff work yourself. If a package
maintainer is willing to volunteer time and effort to making things work
then that's a bonus, but if they're not then someone who cares about ARM
has to take responsibility.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:49 p.m.
On Tue, Jul 9, 2013 at 6:43 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Jul 09, 2013 at 06:33:53PM +0100, Peter Robinson wrote:
> There's a number of people working on this but ultimately like all
> problems we can handle as much as possible but we also need assistance
> by the package maintainers themselves.
No, that's not how it works. While you're a secondary architecture you
get to take responsibility for making stuff work yourself. If a package
maintainer is willing to volunteer time and effort to making things work
then that's a bonus, but if they're not then someone who cares about ARM
has to take responsibility.
That's correct and you'll find that that's what I've been doing for
2.5+ years now, but we're talking about Primary here... and in primary
it's everyone's responsibility...
BTW where's the secondary bit documented?
Peter
12:52 p.m.
On Tue, Jul 09, 2013 at 06:49:10PM +0100, Peter Robinson wrote:
That's correct and you'll find that that's what I've
been doing for
2.5+ years now, but we're talking about Primary here... and in primary
it's everyone's responsibility...
That's the point. You don't get to be a primary architecture until
you've demonstrated that doing so won't slow down the other
architectures, and that requires you to fix all of these problems
yourself first.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:01 a.m.
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Jul 09, 2013 at 06:49:10PM +0100, Peter Robinson wrote:
> That's correct and you'll find that that's what I've been doing for
> 2.5+ years now, but we're talking about Primary here... and in primary
> it's everyone's responsibility...
That's the point. You don't get to be a primary architecture until
you've demonstrated that doing so won't slow down the other
architectures
Is that "you don't get to be a primary architecture unless
you have
demonstrated that nobody outside of the ARM SIG needs to do any work
on the architecture" == "you don't get to be a primary architecture
unless it doesn't matter whether you are a primary architecture"?
and that requires you to fix all of these problems
yourself first.
That's backwards. For the vast majority of Fedora packagers, ARM
becoming a primary architecture primarily means that every individual
package owner is supposed to fix their packages.
So, in some abstract ideal case, there would be a gradual transition
between an ARM SIG starting the bootstrap effort, and non-ARM package
owners gradually taking care of their packages on ARM as well, with
the experience and knowledge slowly spreading enough so that a switch
to primary when everyone is expected to care eventually becomes a
no-brainer, and the ARM SIG can significantly reduce its scope to
ARM-specific tooling changes.
What you are asking for is the exact opposite: that the ARM SIG
temporarily expands to "own" the ARM aspect of the whole distribution
until there are no ARM bugs, and then to have a "big bang" switchover
to a situation when everyone is supposed to handle their own package
on ARM.
Mirek
9:33 a.m.
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> That's the point. You don't get to be a primary architecture until
> you've demonstrated that doing so won't slow down the other
> architectures
Is that "you don't get to be a primary architecture unless you have
demonstrated that nobody outside of the ARM SIG needs to do any work
on the architecture" == "you don't get to be a primary architecture
unless it doesn't matter whether you are a primary architecture"?
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
> and that requires you to fix all of these problems
> yourself first.
That's backwards. For the vast majority of Fedora packagers, ARM
becoming a primary architecture primarily means that every individual
package owner is supposed to fix their packages.
So promoting ARM comes at a cost to every individual package maintainer,
who now has to do additional work.
So, in some abstract ideal case, there would be a gradual transition
between an ARM SIG starting the bootstrap effort, and non-ARM package
owners gradually taking care of their packages on ARM as well, with
the experience and knowledge slowly spreading enough so that a switch
to primary when everyone is expected to care eventually becomes a
no-brainer, and the ARM SIG can significantly reduce its scope to
ARM-specific tooling changes.
I agree that that's the ideal case. If package maintainers are willing
to volunteer their time to ensure their packages work on ARM then
everything is easier and we all benefit. That doesn't seem to be the
case yet.
What you are asking for is the exact opposite: that the ARM SIG
temporarily expands to "own" the ARM aspect of the whole distribution
until there are no ARM bugs, and then to have a "big bang" switchover
to a situation when everyone is supposed to handle their own package
on ARM.
What I'm saying is that making ARM a primary architecture isn't going to
automatically make volunteers start caring about ARM, and so there
should be evidence that the existing ARM porters can deal with the worst
case scenario of supporting an arbitrary set of packages themselves.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:54 a.m.
On Thu, Jul 11, 2013 at 03:33:27PM +0100, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
> On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > That's the point. You don't get to be a primary architecture until
> > you've demonstrated that doing so won't slow down the other
> > architectures
> Is that "you don't get to be a primary architecture unless you have
> demonstrated that nobody outside of the ARM SIG needs to do any work
> on the architecture" == "you don't get to be a primary architecture
> unless it doesn't matter whether you are a primary architecture"?
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
> > and that requires you to fix all of these problems
> > yourself first.
>
> That's backwards. For the vast majority of Fedora packagers, ARM
> becoming a primary architecture primarily means that every individual
> package owner is supposed to fix their packages.
So promoting ARM comes at a cost to every individual package maintainer,
who now has to do additional work.
I think that's overstating things a bit. The vast majority of packages
in Fedora "just work" with no extra effort required for ARM. Most of the
ARM specific build problems are dealt with by the ARM SIG already. So the
"extra" work for every package maintainer is the occassional ARM specific
bug that may arise randomly from time-to-time. There will be a few packages
where ARM bugs are more frequent - things that deal with hardware alot like
kernel, kvm & Xorg drivers, but IIUC the ARM SIG has people to help out in
those areas. So I don't think the extra work for package maintainers is all
that onerous.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
10:02 a.m.
On Thu, Jul 11, 2013 at 4:33 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
> On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > That's the point. You don't get to be a primary architecture until
> > you've demonstrated that doing so won't slow down the other
> > architectures
> Is that "you don't get to be a primary architecture unless you have
> demonstrated that nobody outside of the ARM SIG needs to do any work
> on the architecture" == "you don't get to be a primary architecture
> unless it doesn't matter whether you are a primary architecture"?
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
Yes, but that is _net_ benefit (benefit - cost). Requiring zero cost
to Fedora doesn't follow from that.
Mirek
10:34 a.m.
On Thu, Jul 11, 2013 at 05:02:27PM +0200, Miloslav Trmač wrote:
On Thu, Jul 11, 2013 at 4:33 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> Promotion is supposed to benefit Fedora, not the architecture being
> promoted.
Yes, but that is _net_ benefit (benefit - cost). Requiring zero cost
to Fedora doesn't follow from that.
We don't currently have the information we'd need to assess the cost.
The majority of packages will build just fine on ARM and the maintainer
will never need to care, but there are plenty of corner cases where
that's not the case. That's why I keep mentioning the llvmpipe thing -
this is a piece of critical infrastructure that was known to be broken
for months, but nobody fixed it. If we promote ARM, who takes
responsibility for fixing it? Someone from the ARM SIG, or the existing
LLVM maintainer? If the latter, how much development effort is removed
from x86 support in the process?
That's why I'd like to see all of these things fixed *before* promotion.
That way we've demonstrated that there's enough people willing and able
to work on ensuring that ARM's supported that we know there's not going
to be any significant cost to the rest of the distribution, and that way
we can make an informed decision that the benefits outweigh the costs.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:25 a.m.
On 07/11/2013 08:34 AM, Matthew Garrett wrote:
That's why I'd like to see all of these things fixed *before*
promotion.
Yes, you've been very consistent, it can be summarized in 3 points:
1. Provide a list of every ARM deficiency.
2. Provide a fix for everything listed in 1.
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.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
11:34 a.m.
On Thu, Jul 11, 2013 at 09:25:43AM -0700, Brendan Conoboy wrote:
On 07/11/2013 08:34 AM, Matthew Garrett wrote:
>That's why I'd like to see all of these things fixed *before* promotion.
Yes, you've been very consistent, it can be summarized in 3 points:
1. Provide a list of every ARM deficiency.
Every known deficiency, sure.
2. Provide a fix for everything listed in 1.
Either a fix or an explanation of why it's not worth fixing.
3. After #1 and #2 are complete, we can talk about what else is
needed.
From a technical standpoint, I think that would be entirely adequate.
The rest is just ensuring that rel-eng, qa and so on are happy, which is
something that can be done entirely in parallel with development.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:50 a.m.
On 07/11/2013 07:33 AM, Matthew Garrett wrote:
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
And you think it would not benefit Fedora.
So promoting ARM comes at a cost to every individual package
maintainer,
who now has to do additional work.
Do you really think individual package maintainers haven't been involved
to date? It's flattering to think that our relatively small crew has
somehow been able to manage every issue that's come up with all 13500+
packages, but the truth is that package maintainers are good people who
already handle many of the ARM issues that come up as source churns.
The main difference is workflow change.
Today: ARM builds are queued by koji-shadow some period of time after
they complete successfully on primary. If a build fails then the
koji-shadow admin gets notified. If it's a real bug it gets BZed, we
work with the package maintainer, the bug is fixed, and we move on.
As primary: ARM builds would be queued at the same time as x86. If a
build fails the package maintainer gets notified. If it's an
ARM-specific bug the maintainer would get in touch with the ARM team.
The full details of this change are TBD and should be discussed.
I agree that that's the ideal case. If package maintainers are
willing
to volunteer their time to ensure their packages work on ARM then
everything is easier and we all benefit. That doesn't seem to be the
case yet.
Oh?
What I'm saying is that making ARM a primary architecture
isn't going to
automatically make volunteers start caring about ARM, and so there
should be evidence that the existing ARM porters can deal with the worst
case scenario of supporting an arbitrary set of packages themselves.
Perhaps 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. / blc(a)redhat.com
10:56 a.m.
On Thu, Jul 11, 2013 at 08:50:05AM -0700, Brendan Conoboy wrote:
On 07/11/2013 07:33 AM, Matthew Garrett wrote:
>Promotion is supposed to benefit Fedora, not the architecture being
>promoted.
And you think it would not benefit Fedora.
On the contrary, I think a solid ARM port benefits Fedora a great deal.
Today: ARM builds are queued by koji-shadow some period of time
after they complete successfully on primary. If a build fails then
the koji-shadow admin gets notified. If it's a real bug it gets
BZed, we work with the package maintainer, the bug is fixed, and we
move on.
And if the bug isn't fixed, we move on anyway.
As primary: ARM builds would be queued at the same time as x86. If
a build fails the package maintainer gets notified. If it's an
ARM-specific bug the maintainer would get in touch with the ARM
team. The full details of this change are TBD and should be
discussed.
And if the bug isn't fixed, we have a problem.
>I agree that that's the ideal case. If package maintainers
are willing
>to volunteer their time to ensure their packages work on ARM then
>everything is easier and we all benefit. That doesn't seem to be the
>case yet.
Oh?
The llvm maintainer hasn't fixed llvmpipe. Nobody working on gcc has
bootstrapped ada.
>What I'm saying is that making ARM a primary architecture
isn't going to
>automatically make volunteers start caring about ARM, and so there
>should be evidence that the existing ARM porters can deal with the worst
>case scenario of supporting an arbitrary set of packages themselves.
Perhaps it's inevitable, but I would like to avoid a reprisal of the
Richard Dawkins & Wendy Wright debate. What evidence are you asking
for?
An ARM repository that is as close as practically possible in features
and bugs to the x86 repository.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:34 a.m.
On Thu, 2013-07-11 at 16:56 +0100, Matthew Garrett wrote:
The llvm maintainer hasn't fixed llvmpipe. Nobody working on gcc
has
bootstrapped ada.
The llvm maintainer would like to reiterate that he took the package
more out of necessity than desire, has no love for llvm itself, is not
paid to be a toolchain hacker, and explicitly disclaimed responsibility
for secondary arches when he took it:
https://lists.fedoraproject.org/pipermail/devel/2013-February/179104.html
If we really wanted to talk about graphics on arm, we'd be talking about
writing drivers for GPUs. You know, fixing actual problems, instead of
throwing our hands in the air and switching out the entire UX because we
can't be bothered to make the core OS any good.
But apparently arm development stops just short of writing code.
- ajax
12:08 p.m.
Adam Jackson (ajax(a)redhat.com) said:
If we really wanted to talk about graphics on arm, we'd be
talking about
writing drivers for GPUs.
Is there any use to shipping freedreno and similar projects in Fedora ARM
before they get to the upstream kernel? (I expect a brickbat from Josh
fairly quickly for suggesting this.)
Bill
12:38 p.m.
On Thu, Jul 11, 2013 at 1:08 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Adam Jackson (ajax(a)redhat.com) said:
> If we really wanted to talk about graphics on arm, we'd be talking about
> writing drivers for GPUs.
Is there any use to shipping freedreno and similar projects in Fedora ARM
before they get to the upstream kernel? (I expect a brickbat from Josh
fairly quickly for suggesting this.)
just fyi, my goal is to get all the userspace parts for freedreno into
fedora. We are part way there now, although for the newest generation
of adreno gpus (a3xx) there are still a handful of wip/hack patches
(for mesa) that aren't quite ready for upstream. And at the moment
some XA patches which would break vmwgfx, so we can't really put those
in fedora (unless maybe they are only applied for arm builds... but
I'd really rather fix that issue properly vs. hack).
For the kernel parts, well sadly on the current available devices that
freedreno would run on, there is not nearly enough of the basic kernel
support upstream to boot fedora. I'm keeping kernel branches at least
for the devices that I have (hp touchpad, nexus4, and ifc6410) on
github. I'd be pretty happy to get to the point where vanilla fedora
userspace + custom kernel works. For upcoming round of devices
(snapdragon 800, aka msm8x74), qcom has switched to device-tree, and
appears to be pushing support to upstream kernel again, so I am
hopeful that the situation improves in the future.
BR,
-R
Bill
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:53 p.m.
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Adam Jackson (ajax(a)redhat.com) said:
> If we really wanted to talk about graphics on arm, we'd be talking about
> writing drivers for GPUs.
Is there any use to shipping freedreno and similar projects in Fedora ARM
before they get to the upstream kernel? (I expect a brickbat from Josh
fairly quickly for suggesting this.)
I've been following the tegra and lima (Mali 400) upstream work pretty
closely but neither is actually usable for gnome-shell yet to be
worth, IMO, even to be packaging it in a third party package. In he
case of the freedreno while the work is cool the qualcomm SoC is
primarily shipped on phones and tablets [1] which isn't our primary
focus so while would be cool to support I'm unsure what the user
experience would be like if we did ship it. Side note there is
upstream multi platform support for the MSM SoCs now but I have no
idea how complete this is (eg AllWinner MP support is upstream but
it's still only core SoC/serial/mmc)
Peter
[1] I've seen one dev board
4:37 p.m.
On Mon, Jul 15, 2013 at 4:53 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Adam Jackson (ajax(a)redhat.com) said:
>> If we really wanted to talk about graphics on arm, we'd be talking about
>> writing drivers for GPUs.
>
> Is there any use to shipping freedreno and similar projects in Fedora ARM
> before they get to the upstream kernel? (I expect a brickbat from Josh
> fairly quickly for suggesting this.)
I've been following the tegra and lima (Mali 400) upstream work pretty
closely but neither is actually usable for gnome-shell yet to be
worth, IMO, even to be packaging it in a third party package. In he
case of the freedreno while the work is cool the qualcomm SoC is
primarily shipped on phones and tablets [1] which isn't our primary
focus so while would be cool to support I'm unsure what the user
experience would be like if we did ship it. Side note there is
upstream multi platform support for the MSM SoCs now but I have no
idea how complete this is (eg AllWinner MP support is upstream but
it's still only core SoC/serial/mmc)
fwiw, there are a few boards. Various iterations of dragonboard[1]..
much cheaper than the pre-low-cost-community-board dev-boards of years
gone by, but still a little bit on the pricey side. And then there is
the inforce ifc6410[2] which is what the dragonboard should have been
all along.
Sadly it seems the devicetree support (which would be needed for
multi-platform) is coming in newer SoC's than the apq8064. Or older
(s3/msm8660). So for out of the box multi-platform fedora kernel, I
think we are talking about some eventual successor to the ifc6410
board.
I should note that the freescale iMX5.x devices also have an adreno
a200 GPU.. which I've not had a chance to add support for yet, but it
is on my TODO list somewhere. Along with a lot of other things.
Although I'm not sure that I'd want to try to run gnome-shell at 1080p
on this one.
BR,
-R
[1] http://mydragonboard.org/
[2] http://www.inforcecomputing.com/product/moreinfo/ifc6410.html
Peter
[1] I've seen one dev board
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:49 a.m.
If phones and tablets aren't the primary focus, what is? Development boards, for the
sake of running Fedora ARM on something? Server systems that don't exist yet (or
aren't widely available[1])?
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?
Cheers
[1]: I looked for a board/system that could be used to run GNOME's OSTree build
system, and couldn't find anything with a price list.
----- Original Message -----
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Adam Jackson (ajax(a)redhat.com) said:
>> If we really wanted to talk about graphics on arm, we'd be talking about
>> writing drivers for GPUs.
>
> Is there any use to shipping freedreno and similar projects in Fedora ARM
> before they get to the upstream kernel? (I expect a brickbat from Josh
> fairly quickly for suggesting this.)
I've been following the tegra and lima (Mali 400) upstream work pretty
closely but neither is actually usable for gnome-shell yet to be
worth, IMO, even to be packaging it in a third party package. In he
case of the freedreno while the work is cool the qualcomm SoC is
primarily shipped on phones and tablets [1] which isn't our primary
focus so while would be cool to support I'm unsure what the user
experience would be like if we did ship it. Side note there is
upstream multi platform support for the MSM SoCs now but I have no
idea how complete this is (eg AllWinner MP support is upstream but
it's still only core SoC/serial/mmc)
Peter
[1] I've seen one dev board
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:45 a.m.
On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
If phones and tablets aren't the primary focus, what is?
Development boards, for the sake of running Fedora ARM on something? Server systems that
don't exist yet (or aren't widely available[1])?
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).
Also at the moment the vast majority of the Desktop UXes are a
dreadful experience on tablets whether that be x86 or ARM based.
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.
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 and would have hence provided a terrible
experience. This was discussed in our weekly meeting.
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.
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.
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.
Peter
[1] http://fedoraproject.org/wiki/Architectures/ARM/F18/Remixes
[2] http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes
6:57 a.m.
----- Original Message -----
On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera
<bnocera(a)redhat.com> wrote:
> If phones and tablets aren't the primary focus, what is? Development
> boards, for the sake of running Fedora ARM on something? Server systems
> that don't exist yet (or aren't widely available[1])?
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.
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.
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 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.
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.
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.
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.
7:28 a.m.
> 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.
> 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.
> 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.
> > 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.
> 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. I don't have
access to the ARM build servers either this isn't just you.
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).
> 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?
> 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.
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.
Peter
8:19 a.m.
----- 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.
8:48 a.m.
> 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):
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
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).
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
bits.
> 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'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
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.
That's your opinion, other people have theirs.
> 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.
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
out first.
> 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).
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
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).
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
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.
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.
Peter
2:18 p.m.
On 07/16/2013 05:28 AM, Peter Robinson wrote:
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...
There are 3 things I would like to add here:
1. As Peter mentioned elsewhere in his reply, not even the ARM team has
access to the ARM builders in PHX. Just like we don't have x86_64.
Access is handled by the infrastructure team, builds are handled by
koji. These are closed systems without remote access provisions.
2. Kevin Fenzi is working on setting up a limited pool
community-accessible ARM builders. Join in the weekly fedora-arm
meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates
about his progress (And other ARM topics). As of last week it was being
considered and worked on, but not immediately ready to go.
3. If you are a Red Hat employee I can provide access to ARM systems of
the same caliber as what is in the Fedora colo. Drop me a line and let
me know what you need- I will make it happen.
Thanks,
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:28 a.m.
On Tue, 16 Jul 2013 12:18:26 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/16/2013 05:28 AM, Peter Robinson wrote:
> 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...
There are 3 things I would like to add here:
1. As Peter mentioned elsewhere in his reply, not even the ARM team
has access to the ARM builders in PHX. Just like we don't have
x86_64. Access is handled by the infrastructure team, builds are
handled by koji. These are closed systems without remote access
provisions.
Correct. It needs koji admin to be able to spin images for a variety of
reasons (mostly resources... disk and builder cycles and io)
2. Kevin Fenzi is working on setting up a limited pool
community-accessible ARM builders. Join in the weekly fedora-arm
meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates
about his progress (And other ARM topics). As of last week it was
being considered and worked on, but not immediately ready to go.
I'm waiting for a firmware update thats hopefully out soon that will
allow us to isolate some SOC's on a seperate physical network wire so
we can make sure they don't interfere with anything else.
3. If you are a Red Hat employee I can provide access to ARM systems
of the same caliber as what is in the Fedora colo. Drop me a line
and let me know what you need- I will make it happen.
We do already have some QA ones with more limited access, we can see
about adding you to access those if that would help?
kevin
11:53 a.m.
----- Original Message -----
On 07/16/2013 05:28 AM, Peter Robinson wrote:
> 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...
There are 3 things I would like to add here:
1. As Peter mentioned elsewhere in his reply, not even the ARM team has
access to the ARM builders in PHX. Just like we don't have x86_64.
Access is handled by the infrastructure team, builds are handled by
koji. These are closed systems without remote access provisions.
https://fedoraproject.org/wiki/Koji/BuildingImages says:
"
koji grant-permission <image> <user>: grant the permission to build an image
type to a user.
"
Is that not correct?
2. Kevin Fenzi is working on setting up a limited pool
community-accessible ARM builders. Join in the weekly fedora-arm
meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates
about his progress (And other ARM topics). As of last week it was being
considered and worked on, but not immediately ready to go.
Great.
3. If you are a Red Hat employee I can provide access to ARM systems
of
the same caliber as what is in the Fedora colo. Drop me a line and let
me know what you need- I will make it happen.
As I mentioned earlier in the thread, I'd rather have community accessible machines.
And I'm not really comfortable manipulating build images from 4000 miles away if
I haven't been able to test them in the slightest locally.
Peter said that he's restart creating GNOME images very soon, which is
good enough for me to start with.
I have packages for the freedreno X server driver done:
http://people.fedoraproject.org/~hadess/peak/xorg-x11-drv-freedreno/
(it currently requires a git mesa, but it might be a good thing to get it in
the distro anyway)
And for a version of adbd that'll run on Fedora:
http://people.fedoraproject.org/~hadess/peak/adbd/
The sources still need fixing to use another user than 2000 by default, and
the systemd service file needs fixing too.
If anyone is interested to get those merged, poke me or Rob Clark about
getting them in Fedora and the patches upstream.
Cheers
12:07 p.m.
On Wed, 17 Jul 2013 12:53:18 -0400 (EDT)
Bastien Nocera <bnocera(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Koji/BuildingImages says:
"
koji grant-permission <image> <user>: grant the permission to build
an image type to a user. "
Is that not correct?
Yeah, I guess it is now. We don't currently grant anyone but koji
admins this ability currently however.
You're welcome to file a rel-eng ticket to ask for it.
As I mentioned earlier in the thread, I'd rather have community
accessible machines. And I'm not really comfortable manipulating
build images from 4000 miles away if I haven't been able to test them
in the slightest locally.
Peter said that he's restart creating GNOME images very soon, which is
good enough for me to start with.
Great.
I have packages for the freedreno X server driver done:
http://people.fedoraproject.org/~hadess/peak/xorg-x11-drv-freedreno/
(it currently requires a git mesa, but it might be a good thing to
get it in the distro anyway)
And for a version of adbd that'll run on Fedora:
http://people.fedoraproject.org/~hadess/peak/adbd/
The sources still need fixing to use another user than 2000 by
default, and the systemd service file needs fixing too.
If anyone is interested to get those merged, poke me or Rob Clark
about getting them in Fedora and the patches upstream.
Excellent.
kevin
12:18 p.m.
On 07/17/2013 09:53 AM, Bastien Nocera wrote:
As I mentioned earlier in the thread, I'd rather have community
accessible machines.
And I'm not really comfortable manipulating build images from 4000 miles away if
I haven't been able to test them in the slightest locally.
Sure, community accessible machines reach the widest audience. Until
that plan is fully ready to go I can provide ARM server access to Red
Hat personnel. Of course it doesn't help when you need to do local
testing. The versatile express image works on any host with
qemu-system-arm, so this is one (slow) avenue. Beyond that, in some
cases it possible to provide hardware. Please email me if you need
this. Thanks,
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:53 p.m.
On 17 Jul 2013 18:18, "Brendan Conoboy" <blc(a)redhat.com> wrote:
Virtio-mmio should land in qemu rawhide soon which should help a little to
improve speed but I wouldn't imagine huge improvement.
Peter
On 07/17/2013 09:53 AM, Bastien Nocera wrote:
> As I mentioned earlier in the thread, I'd rather have
community
accessible machines.
> And I'm not really comfortable manipulating build images from
4000 miles
away if
> I haven't been able to test them in the slightest locally.
Sure, community accessible machines reach the widest audience. Until
that plan is
fully ready to go I can provide ARM server access to Red Hat
personnel. Of course it doesn't help when you need to do local testing.
The versatile express image works on any host with qemu-system-arm, so
this is one (slow) avenue. Beyond that, in some cases it possible to
provide hardware. Please email me if you need this. Thanks,
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2:07 p.m.
On 07/16/2013 01:49 AM, Bastien Nocera wrote:
I'm interested in Fedora on phones, tablets, tiny dongly media
centers, set-top boxes, Wi-Fi routers and eBook readers.
Personally, I'm interested in running Fedora on ARM everywhere, so if
you want to contribute toward the above, by all means do so. Join us in
#fedora-arm, join the mailing list, and we'll do what we can to support
your pursuit. If it can be done within Fedora package guidelines and
spin set it can be an official part of the next release. If it can't,
it can be a remix. In either case you are most welcome to join in and
pursue your interest.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
4:02 a.m.
On 07/11/2013 03:33 PM, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
> On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
>> That's the point. You don't get to be a primary architecture until
>> you've demonstrated that doing so won't slow down the other
>> architectures
> Is that "you don't get to be a primary architecture unless you have
> demonstrated that nobody outside of the ARM SIG needs to do any work
> on the architecture" == "you don't get to be a primary architecture
> unless it doesn't matter whether you are a primary architecture"?
Promotion is supposed to benefit Fedora, not the architecture being
promoted.
Is this some rule that I don't know about? Surely promotion is supposed
to benefit Fedora's users.
Andrew.
6:10 p.m.
>>> That's the point. You don't get to be a primary
architecture until
>>> you've demonstrated that doing so won't slow down the other
>>> architectures
>> Is that "you don't get to be a primary architecture unless you have
>> demonstrated that nobody outside of the ARM SIG needs to do any work
>> on the architecture" == "you don't get to be a primary
architecture
>> unless it doesn't matter whether you are a primary architecture"?
>
> Promotion is supposed to benefit Fedora, not the architecture being
> promoted.
Is this some rule that I don't know about? Surely promotion is supposed
to benefit Fedora's users.
Couldn't agree wholeheartedly!
12:50 p.m.
llvmpipe has been known to be broken for months, and nobody on the ARM
team appears capable of fixing it. As a result, ARM shipped in F19
without any out of the box support for running our default desktop.
This doesn't make it seem like the ARM port currently has sufficient
developer expertise involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring that we don't
end up in a situation where other architectures are held up because
there's nobody who can fix ARM-specific bugs.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:53 p.m.
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
llvmpipe has been known to be broken for months, and nobody on the
ARM
team appears capable of fixing it. As a result, ARM shipped in F19
without any out of the box support for running our default desktop.
This doesn't make it seem like the ARM port currently has sufficient
developer expertise involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring that we don't
end up in a situation where other architectures are held up because
there's nobody who can fix ARM-specific bugs.
Does the secureboot situation on arm mean that this primary architecture
will eventually be un-bootable for people running a non-redhat signed kernel?
12:59 p.m.
On 07/09/2013 10:53 AM, Gregory Maxwell wrote:
Does the secureboot situation on arm mean that this primary
architecture
will eventually be un-bootable for people running a non-redhat signed kernel?
No. We do not support secure boot on ARM in any way. Only devices
which ship without secure boot are supported on Fedora.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:02 p.m.
On Tue, Jul 09, 2013 at 10:53:39AM -0700, Gregory Maxwell wrote:
Does the secureboot situation on arm mean that this primary architecture
will eventually be un-bootable for people running a non-redhat signed kernel?
That's unsupported hardware, in the same way that ipads are.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:22 p.m.
On 2013-07-09 10:53, Gregory Maxwell wrote:
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org>
wrote:
> llvmpipe has been known to be broken for months, and nobody on the ARM
> team appears capable of fixing it. As a result, ARM shipped in F19
> without any out of the box support for running our default desktop.
>
> This doesn't make it seem like the ARM port currently has sufficient
> developer expertise involved, and I'd really like to hear what the
> plans
> are for (a) fixing the existing problems, and (b) ensuring that we
> don't
> end up in a situation where other architectures are held up because
> there's nobody who can fix ARM-specific bugs.
Does the secureboot situation on arm mean that this primary
architecture
will eventually be un-bootable for people running a non-redhat signed
kernel?
I think you're mistaking "the secure boot situation on *Microsoft* ARM"
for "the secure boot situation on ARM".
ARM devices that want to come with an OEM copy of Windows RT
pre-installed have to do certain things with Secure Boot which
effectively prevent anyone else from booting on them. Okay. So, we don't
support such devices.
Microsoft cannot magically apply their OEM licensing requirements to
Every ARM Device Ever, including all the ones that don't run Windows RT.
Which is like 97+% of ARM devices, given the Windows RT sales figures so
far.
Various other popular consumer ARM devices use other techniques - *not*
UEFI Secure Boot - for locking out alternative OSes, so Fedora isn't
going to work on those either, unless they're hacked. Too bad. As
bconoboy says, such things simply fall in the 'unsupported hardware'
box.
When reading media articles about SB, bear in mind they're usually
wildly inaccurate. For the straight dope, apply to mjg59, pjones, or if
neither of them is available, me (but remember I'm just the monkey).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:48 p.m.
On Tue, Jul 9, 2013 at 7:22 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
When reading media articles about SB, bear in mind they're
usually wildly
inaccurate. For the straight dope, apply to mjg59, pjones, or if neither of
them is available, me (but remember I'm just the monkey).
You can ask me as well. I wrote quite a few of the SB patches we're
carrying in the kernel. Whether that makes me more than a monkey, I
have no idea.
josh
1:54 p.m.
Matthew,
We'll be looking into LLVM in due course. There are a few of us capable of fixing the
issue (that you were noted as being extremely concerned about on IRC at the time - we will
be happy to send you updates on this) but we balance this with other priorities (as well
as a desire not to grow a dependency on LLVM more broadly - Fedora relies heavily upon the
expertise of RH's tools team, which focuses on GCC almost exclusively precisely to
avoid fragmenting the resources that do exist to develop awesome new tooling). Right now,
many desktops work just fine, and there is no reason ARM cannot be a a Primary
Architecture because of a temporary bug in llvmpipe (or otherwise we can revive this
thread for you next time it breaks on the other architecture and see if it should be
demoted accordingly?). If there is a rule saying "PA needs GNOME" then this can
easily be adjusted to reflect the fact that many are running Fedora on ARM today happily
with a variety of other desktop environments.
Jon.
--
Sent from my iPad
On Jul 9, 2013, at 18:57, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
llvmpipe has been known to be broken for months, and nobody on the
ARM
team appears capable of fixing it. As a result, ARM shipped in F19
without any out of the box support for running our default desktop.
This doesn't make it seem like the ARM port currently has sufficient
developer expertise involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring that we don't
end up in a situation where other architectures are held up because
there's nobody who can fix ARM-specific bugs.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3 p.m.
On Tuesday, July 9, 2013, Jonathan Masters <jcm(a)redhat.com> wrote:
It is not only that one desktop does not work but pretty much everything
that uses GL ... Which is not acceptable in 2013 IMO ... And this has
nothing to do with GCC vs llvm either ...
Matthew,
We'll be looking into LLVM in due course. There are a few of us capable
of
fixing the issue (that you were noted as being extremely concerned about
on IRC at the time - we will be happy to send you updates on this) but we
balance this with other priorities (as well as a desire not to grow a
dependency on LLVM more broadly - Fedora relies heavily upon the expertise
of RH's tools team, which focuses on GCC almost exclusively precisely to
avoid fragmenting the resources that do exist to develop awesome new
tooling). Right now, many desktops work just fine, and there is no reason
ARM cannot be a a Primary Architecture because of a temporary bug in
llvmpipe (or otherwise we can revive this thread for you next time it
breaks on the other architecture and see if it should be demoted
accordingly?). If there is a rule saying "PA needs GNOME" then this can
easily be adjusted to reflect the fact that many are running Fedora on ARM
today happily with a variety of other desktop environments.
8:36 a.m.
On 07/09/2013 08:00 PM, drago01 wrote:
On Tuesday, July 9, 2013, Jonathan Masters <jcm(a)redhat.com
<mailto:jcm@redhat.com>> wrote:
> Matthew,
>
> We'll be looking into LLVM in due course. There are a few of us
capable of fixing the issue (that you were noted as being extremely
concerned about on IRC at the time - we will be happy to send you
updates on this) but we balance this with other priorities (as well as
a desire not to grow a dependency on LLVM more broadly - Fedora relies
heavily upon the expertise of RH's tools team, which focuses on GCC
almost exclusively precisely to avoid fragmenting the resources that
do exist to develop awesome new tooling). Right now, many desktops
work just fine, and there is no reason ARM cannot be a a Primary
Architecture because of a temporary bug in llvmpipe (or otherwise we
can revive this thread for you next time it breaks on the other
architecture and see if it should be demoted accordingly?). If there
is a rule saying "PA needs GNOME" then this can easily be adjusted to
reflect the fact that many are running Fedora on ARM today happily
with a variety of other desktop environments.
>
It is not only that one desktop does not work but pretty much
everything that uses GL ... Which is not acceptable in 2013 IMO ...
And this has nothing to do with GCC vs llvm either ...
Since when do we make the requirement that PA have to run any DE et all
period regardless if it's 2013 or not?
9:05 a.m.
On Wednesday, July 10, 2013, "Jóhann B. Guðmundsson" <
johannbg(a)gmail.com> wrote:
On 07/09/2013 08:00 PM, drago01 wrote:
On Tuesday, July 9, 2013, Jonathan Masters <jcm(a)redhat.com> wrote:
> Matthew,
>
> We'll be looking into LLVM in due course. There are a few of us capable
of
fixing the issue (that you were noted as being extremely concerned about
on IRC at the time - we will be happy to send you updates on this) but we
balance this with other priorities (as well as a desire not to grow a
dependency on LLVM more broadly - Fedora relies heavily upon the expertise
of RH's tools team, which focuses on GCC almost exclusively precisely to
avoid fragmenting the resources that do exist to develop awesome new
tooling). Right now, many desktops work just fine, and there is no reason
ARM cannot be a a Primary Architecture because of a temporary bug in
llvmpipe (or otherwise we can revive this thread for you next time it
breaks on the other architecture and see if it should be demoted
accordingly?). If there is a rule saying "PA needs GNOME" then this can
easily be adjusted to reflect the fact that many are running Fedora on ARM
today happily with a variety of other desktop environments.
>
It is not only that one desktop does not work but pretty much everything
that uses
GL ... Which is not acceptable in 2013 IMO ... And this has
nothing to do with GCC vs llvm either ...
Since when do we make the requirement that PA have to run any DE et all
period
regardless if it's 2013 or not?
You missed the point. I am not talking ab out Desktops but OpenGL if wie
dont have such criteria wie should ad it.
5:47 p.m.
On Tue, 2013-07-09 at 14:54 -0400, Jonathan Masters wrote:
We'll be looking into LLVM in due course. There are a few of us
capable of fixing the issue (that you were noted as being extremely
concerned about on IRC at the time - we will be happy to send you
updates on this) but we balance this with other priorities (as well as
a desire not to grow a dependency on LLVM more broadly
Functional llvmpipe isn't a new dependency. Every primary arch has had
it working since F17. Two of the secondaries do too in F19. I
appreciate not wanting to depend more on llvm - believe me I really,
really, really, do - but I don't think you get to use that as an out
here.
- Fedora relies heavily upon the expertise of RH's tools team,
which
focuses on GCC almost exclusively precisely to avoid fragmenting the
resources that do exist to develop awesome new tooling).
Sure, but arm also builds without -fstack-protector because it's plainly
unimplemented, which is a fairly major security regression compared to
every other architecture.
The conclusion one might draw is that there's no toolchain attention
being paid to arm at all. Which doesn't inspire in me much confidence.
- ajax
9:47 p.m.
On Tue, Jul 09, 2013 at 02:54:53PM -0400, Jonathan Masters wrote:
Matthew Garrett wrote:
> This doesn't make it seem like the ARM port currently has sufficient
> developer expertise involved, and I'd really like to hear what the plans
> are for (a) fixing the existing problems, and (b) ensuring that we don't
> end up in a situation where other architectures are held up because
> there's nobody who can fix ARM-specific bugs.
We'll be looking into LLVM in due course. There are a few of us
capable of fixing the issue (that you were noted as being extremely
concerned about on IRC at the time - we will be happy to send you
updates on this) but we balance this with other priorities (as well as
a desire not to grow a dependency on LLVM more broadly - Fedora relies
heavily upon the expertise of RH's tools team, which focuses on GCC
almost exclusively precisely to avoid fragmenting the resources that
do exist to develop awesome new tooling). Right now, many desktops
work just fine, and there is no reason ARM cannot be a a Primary
Architecture because of a temporary bug in llvmpipe (or otherwise we
can revive this thread for you next time it breaks on the other
architecture and see if it should be demoted accordingly?). If there
is a rule saying "PA needs GNOME" then this can easily be adjusted to
reflect the fact that many are running Fedora on ARM today happily
with a variety of other desktop environments.
There's a few of you capable of fixing the issue, but there were enough
other things to fix that you didn't have time? That doesn't answer my
question. What are the plans to ensure that there's enough ARM expertise
in Fedora to ensure that ARM-specific bugs in critical infrastructure
packages (like LLVM) don't end up as release blockers?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:33 p.m.
On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote:
llvmpipe has been known to be broken for months, and nobody on the
ARM
team appears capable of fixing it. As a result, ARM shipped in F19
without any out of the box support for running our default desktop.
This doesn't make it seem like the ARM port currently has sufficient
developer expertise involved, and I'd really like to hear what the plans
are for (a) fixing the existing problems, and (b) ensuring that we don't
end up in a situation where other architectures are held up because
there's nobody who can fix ARM-specific bugs.
I'm also concerned that stack protector does not workyet at all. Even if
the desktop was useable, how would we tell people that it's okay to
run e.g. firefox with a straight face? It's not as bad as if, say,
selinux didn't work, but it's a significant concern.
--
Peter
11:19 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 9 Jul 2013 16:33:28 -0400
Peter Jones <pjones(a)redhat.com> wrote:
On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote:
> llvmpipe has been known to be broken for months, and nobody on the
> ARM team appears capable of fixing it. As a result, ARM shipped in
> F19 without any out of the box support for running our default
> desktop.
>
> This doesn't make it seem like the ARM port currently has
> sufficient developer expertise involved, and I'd really like to
> hear what the plans are for (a) fixing the existing problems, and
> (b) ensuring that we don't end up in a situation where other
> architectures are held up because there's nobody who can fix
> ARM-specific bugs.
I'm also concerned that stack protector does not workyet at all.
Even if the desktop was useable, how would we tell people that it's
okay to run e.g. firefox with a straight face? It's not as bad as
if, say, selinux didn't work, but it's a significant concern.
armv7 has stack protector, aarch64 which is outside of this proposal
doesnt yet have it.
from redhat-rpm-config
redhat-rpm-config-9.1.0/rpmrc:optflags: armv7hl %{__global_cflags} -march=armv7-a
-mfpu=vfpv3-d16 -mfloat-abi=hard
redhat-rpm-config-9.1.0/rpmrc:optflags: aarch64 %{__global_cflags}
- -fno-stack-protector
redhat-rpm-config-9.1.0/macros:%__global_cflags -O2 -g -pipe
- -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
- --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
i agree 64 bit arm if and when it goes to primary will need it, but for
today it is outside of the change proposal.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHdiZsACgkQkSxm47BaWfdR2ACfchknZrlHBMKMBnhF71bM7ETT
L2sAoJwuf7NAJf0PVjobmmIg2F4AJHnV
=4yQy
-----END PGP SIGNATURE-----
11:23 a.m.
On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 9 Jul 2013 16:33:28 -0400
Peter Jones <pjones(a)redhat.com> wrote:
> On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote:
> > llvmpipe has been known to be broken for months, and nobody on the
> > ARM team appears capable of fixing it. As a result, ARM shipped in
> > F19 without any out of the box support for running our default
> > desktop.
> >
> > This doesn't make it seem like the ARM port currently has
> > sufficient developer expertise involved, and I'd really like to
> > hear what the plans are for (a) fixing the existing problems, and
> > (b) ensuring that we don't end up in a situation where other
> > architectures are held up because there's nobody who can fix
> > ARM-specific bugs.
>
>
> I'm also concerned that stack protector does not workyet at all.
> Even if the desktop was useable, how would we tell people that it's
> okay to run e.g. firefox with a straight face? It's not as bad as
> if, say, selinux didn't work, but it's a significant concern.
>
armv7 has stack protector, aarch64 which is outside of this proposal
doesnt yet have it.
from redhat-rpm-config
redhat-rpm-config-9.1.0/rpmrc:optflags: armv7hl %{__global_cflags} -march=armv7-a
-mfpu=vfpv3-d16 -mfloat-abi=hard
redhat-rpm-config-9.1.0/rpmrc:optflags: aarch64 %{__global_cflags}
- -fno-stack-protector
redhat-rpm-config-9.1.0/macros:%__global_cflags -O2 -g -pipe
- -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
- --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
i agree 64 bit arm if and when it goes to primary will need it, but for
today it is outside of the change proposal.
Thanks for clearing that up - I had been conflating the two with regards
to this specific issue.
--
Peter
12:36 p.m.
On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
armv7 has stack protector, aarch64 which is outside of this proposal
doesnt yet have it.
Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
really have full stack protector support, while perhaps -fstack-protector
doesn't error out on armv7, it certainly isn't supported in glibc
(neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
arm having security standards high enough for being a primary architecture.
CCing Carlos so that they can discuss that.
Jakub
1:40 p.m.
On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
> armv7 has stack protector, aarch64 which is outside of this proposal
> doesnt yet have it.
Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
really have full stack protector support, while perhaps -fstack-protector
doesn't error out on armv7, it certainly isn't supported in glibc
(neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
arm having security standards high enough for being a primary architecture.
So what does the kernel level CC_STACKPROTECTOR config option bring to
this as it appears to be associated with the -fstack-protector option
as well (according to it's Kconfig description) but is only supported
on x86/arm from that list above (plus sh).
Peter
8:53 p.m.
That option simply preserves the global stack canary value between tasks during context
switch. It's not really core to this. The core piece is userspace compiler tooling. I
know the option exists and I thought/was lead to believe it works. But if Jakub has
concerns I will add that to the feedback I have already raised with ARM/Linaro here in
Dublin this evening.
But also guys, come on. We can't be having random new requirements being added in a
bike shedding exercise with the first this being raised happening now. If there are issues
then they can be prioritized and worked on, but we'll never get anywhere if things are
raised in this manner. As I see it, ARM is the most popular architecture on Earth, is damn
well supported in Fedora, and we do the Fedora community a disservice by not bringing the
4 F's into this and thinking about the broader context. So, I'll/we'll come
back with more data on the stack protector implementation and what we can do about
llvmpipe, but meanwhile please give us useful guidance on what you actually want for ARM
to be a PA. Not "hand wavy it must be feature parity with x86". I can think of
plenty of terrible things x86 does that I would never want to see ARM attempt to match.
Jon.
--
Sent from my iPad
On Jul 10, 2013, at 19:40, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek
<jakub(a)redhat.com> wrote:
> On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
>> armv7 has stack protector, aarch64 which is outside of this proposal
>> doesnt yet have it.
>
> Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
> really have full stack protector support, while perhaps -fstack-protector
> doesn't error out on armv7, it certainly isn't supported in glibc
> (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
> arm having security standards high enough for being a primary architecture.
So what does the kernel level CC_STACKPROTECTOR config option bring to
this as it appears to be associated with the -fstack-protector option
as well (according to it's Kconfig description) but is only supported
on x86/arm from that list above (plus sh).
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
11:11 p.m.
On Wed, Jul 10, 2013 at 09:53:09PM -0400, Jonathan Masters wrote:
But also guys, come on. We can't be having random new
requirements
being added in a bike shedding exercise with the first this being
raised happening now.
Stack protector is not a new requirement in Fedora. It's been part of
the distribution for years.
| ---- Fedora
|
|
| ---- "Your architecture must be at least this competent"
|
|
| ---- stack protector
|
|
|
| ---- m68k
|
|
|
|
| --- elks
|
|
| --- minix
---
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:15 a.m.
On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
> Stack protector is not a new requirement in Fedora. It's been part of
> the distribution for years.
xterm has been part of the distribution for years also, but it's not a
release requirement.
The assumption has always been that all primary architectures embody the
same level of functionality, with the exception of fundamental
differences between the architectures. If things that are currently
supported by the primary architectures cease to be supported by the
primary architectures, that's a strong argument that they're not
fundamental to Fedora. For example, in the absence of hardware nx
support, I wouldn't argue that ARM should be forced to implement
execshield - both because it's fundamentally tied to 32-bit x86, and
because we've given up on supporting it. But yes, if ARM wanted to ship
without xterm while the other primary architectures supported it, I'd
say that that would be a blocker for shipping ARM as a primary
architecture.
I think what's been missed here is that the secondary architecture
promotion guidelines were intended to be an addition to common sense
rather than a replacement for it. They didn't seek to be an exhaustive
list of things that had to be present for something to be a PA - they
were an attempt to shape out the grey areas. A primary architecture
should include everything that one could reasonable expect to be present
in Fedora, which includes security features.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:14 a.m.
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
>
> > Stack protector is not a new requirement in Fedora. It's been part of
> > the distribution for years.
>
> xterm has been part of the distribution for years also, but it's not a
> release requirement.
The assumption has always been that all primary architectures embody the
same level of functionality, with the exception of fundamental
differences between the architectures. If things that are currently
supported by the primary architectures cease to be supported by the
primary architectures, that's a strong argument that they're not
fundamental to Fedora. For example, in the absence of hardware nx
support, I wouldn't argue that ARM should be forced to implement
execshield - both because it's fundamentally tied to 32-bit x86, and
because we've given up on supporting it. But yes, if ARM wanted to ship
without xterm while the other primary architectures supported it, I'd
say that that would be a blocker for shipping ARM as a primary
architecture.
I think assumption is part of the problem here, you're assuming
something that is different to the assumption of others but as it's
not documented anywhere it means that neither opinion is neither right
nor wrong.
I think what's been missed here is that the secondary
architecture
promotion guidelines were intended to be an addition to common sense
rather than a replacement for it. They didn't seek to be an exhaustive
list of things that had to be present for something to be a PA - they
were an attempt to shape out the grey areas. A primary architecture
should include everything that one could reasonable expect to be present
in Fedora, which includes security features.
And I agree that "common sense" is required here, we're not arguing
that security features should be ignored and we weren't ignoring them,
we made an assumption that because the kernel, the compiler options
were there that so was the glibc rather than a boiler plate code that
made all of the rest of the components essentially useless.
As for the common sense about the desktop I don't necessarily agree
that while the gnome desktop is the default that it's an explicit
requirement. There's 4 million XOs shipping Fedora (both x86 and ARM)
that don't ship with gnome3 as well as no doubt millions of instances
of cloud images that don't have a requirement of a desktop yet we
still call them Fedora... Fedora with a requirement for a desktop or a
single desktop option I think is a thing of the past and while I would
like to support it I don't believe it's common sense to have it as a
blocker.
Peter
6:48 a.m.
And following the legitimate concerns about stack-protector this was raised by ARM into
core Linaro as an urgent action for which engineering resource is being assigned to
correct this deficiency ASAP. Thus within a day an issue has been noted that we were
unaware of and is being worked through a process to correct it, as would be the case with
any deficiency on x86. The stack protection stuff will be fixed. Let's bike shed over
the next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
--
Sent from my iPad
On Jul 11, 2013, at 12:14, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
>>
>>> Stack protector is not a new requirement in Fedora. It's been part of
>>> the distribution for years.
>>
>> xterm has been part of the distribution for years also, but it's not a
>> release requirement.
>
> The assumption has always been that all primary architectures embody the
> same level of functionality, with the exception of fundamental
> differences between the architectures. If things that are currently
> supported by the primary architectures cease to be supported by the
> primary architectures, that's a strong argument that they're not
> fundamental to Fedora. For example, in the absence of hardware nx
> support, I wouldn't argue that ARM should be forced to implement
> execshield - both because it's fundamentally tied to 32-bit x86, and
> because we've given up on supporting it. But yes, if ARM wanted to ship
> without xterm while the other primary architectures supported it, I'd
> say that that would be a blocker for shipping ARM as a primary
> architecture.
I think assumption is part of the problem here, you're assuming
something that is different to the assumption of others but as it's
not documented anywhere it means that neither opinion is neither right
nor wrong.
> I think what's been missed here is that the secondary architecture
> promotion guidelines were intended to be an addition to common sense
> rather than a replacement for it. They didn't seek to be an exhaustive
> list of things that had to be present for something to be a PA - they
> were an attempt to shape out the grey areas. A primary architecture
> should include everything that one could reasonable expect to be present
> in Fedora, which includes security features.
And I agree that "common sense" is required here, we're not arguing
that security features should be ignored and we weren't ignoring them,
we made an assumption that because the kernel, the compiler options
were there that so was the glibc rather than a boiler plate code that
made all of the rest of the components essentially useless.
As for the common sense about the desktop I don't necessarily agree
that while the gnome desktop is the default that it's an explicit
requirement. There's 4 million XOs shipping Fedora (both x86 and ARM)
that don't ship with gnome3 as well as no doubt millions of instances
of cloud images that don't have a requirement of a desktop yet we
still call them Fedora... Fedora with a requirement for a desktop or a
single desktop option I think is a thing of the past and while I would
like to support it I don't believe it's common sense to have it as a
blocker.
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:10 a.m.
On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
And following the legitimate concerns about stack-protector this was
raised by ARM into core Linaro as an urgent action for which engineering
resource is being assigned to correct this deficiency ASAP. Thus within
a day an issue has been noted that we were unaware of and is being worked
through a process to correct it, as would be the case with any deficiency
on x86. The stack protection stuff will be fixed. Let's bike shed over the
next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
Just in case it wasn't part of what was discussed, please note that if all
goes well, F20 will be switching to use -fstack-protector-strong rather than
just -fstack-protector so we'd need the functionality for that implemented:
https://fedorahosted.org/fesco/ticket/1128
-Toshio
10:27 a.m.
On 07/11/2013 05:10 PM, Toshio Kuratomi wrote:
On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
> And following the legitimate concerns about stack-protector this was
> raised by ARM into core Linaro as an urgent action for which engineering
> resource is being assigned to correct this deficiency ASAP. Thus within
> a day an issue has been noted that we were unaware of and is being worked
> through a process to correct it, as would be the case with any deficiency
> on x86. The stack protection stuff will be fixed. Let's bike shed over the
> next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
>
Just in case it wasn't part of what was discussed, please note that if all
goes well, F20 will be switching to use -fstack-protector-strong rather than
just -fstack-protector so we'd need the functionality for that implemented:
The good news is that -fstack-protector-strong is exclusively a
middle-end feature which did not require any changes to the backend
implementation. It just caused more functions to be instrumented with
canary checks, based on the local variables in the function and how they
are used.
NVR optimization and retslot handling might different among
architectures (I haven't checked), but the existing patch (in Fedora and
upstream) does not deal with those anyway.
--
Florian Weimer / Red Hat Product Security Team
10:46 a.m.
On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
And following the legitimate concerns about stack-protector this was
raised by ARM into core Linaro as an urgent action for which engineering resource is being
assigned to correct this deficiency ASAP. Thus within a day an issue has been noted that
we were unaware of and is being worked through a process to correct it, as would be the
case with any deficiency on x86. The stack protection stuff will be fixed. Let's bike
shed over the next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
Was the flag ignored previously or why was this missing feature not
announced?
Regards
Till
1:21 p.m.
On 07/11/2013 08:46 AM, Till Maas wrote:
On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
> And following the legitimate concerns about stack-protector this was raised by ARM
into core Linaro as an urgent action for which engineering resource is being assigned to
correct this deficiency ASAP. Thus within a day an issue has been noted that we were
unaware of and is being worked through a process to correct it, as would be the case with
any deficiency on x86. The stack protection stuff will be fixed. Let's bike shed over
the next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
Was the flag ignored previously or why was this missing feature not
announced?
Please see:
https://lists.fedoraproject.org/pipermail/devel/2013-July/185106.html
Per Carlos's email, the flag is not ignored, the feature is there, but
it isn't as 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. / blc(a)redhat.com
1:49 p.m.
On Thu, Jul 11, 2013 at 11:21:30AM -0700, Brendan Conoboy wrote:
On 07/11/2013 08:46 AM, Till Maas wrote:
>On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
>>And following the legitimate concerns about stack-protector this was raised by
ARM into core Linaro as an urgent action for which engineering resource is being assigned
to correct this deficiency ASAP. Thus within a day an issue has been noted that we were
unaware of and is being worked through a process to correct it, as would be the case with
any deficiency on x86. The stack protection stuff will be fixed. Let's bike shed over
the next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
>
>Was the flag ignored previously or why was this missing feature not
>announced?
Please see:
https://lists.fedoraproject.org/pipermail/devel/2013-July/185106.html
Per Carlos's email, the flag is not ignored, the feature is there,
but it isn't as fully featured. Specifically stack guards are
present but pointer guards are not. This was news to all of us.
Stack guards are present, but using libssp, which is the fallback way,
second class citizen and most likely slower than the standard way.
E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
even on ARM kernel provides AT_RANDOM that can be just used.
And I'd bet that even on ARM reading the stack guard via TLS (well,
static only always, i.e. hardcoded offset from TLS register), especially for
PIC, is faster than doing GOT read and two memory references.
Jakub
1:52 p.m.
On 07/11/2013 11:49 AM, Jakub Jelinek wrote:
Stack guards are present, but using libssp, which is the fallback
way,
second class citizen and most likely slower than the standard way.
E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
even on ARM kernel provides AT_RANDOM that can be just used.
And I'd bet that even on ARM reading the stack guard via TLS (well,
static only always, i.e. hardcoded offset from TLS register), especially for
PIC, is faster than doing GOT read and two memory references.
Thanks. Security-wise, is the implementation roughly equivalent in what
is protected against, albeit less efficient?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
2:03 p.m.
On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote:
On 07/11/2013 11:49 AM, Jakub Jelinek wrote:
>Stack guards are present, but using libssp, which is the fallback way,
>second class citizen and most likely slower than the standard way.
>E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
>even on ARM kernel provides AT_RANDOM that can be just used.
>And I'd bet that even on ARM reading the stack guard via TLS (well,
>static only always, i.e. hardcoded offset from TLS register), especially for
>PIC, is faster than doing GOT read and two memory references.
Thanks. Security-wise, is the implementation roughly equivalent in
what is protected against, albeit less efficient?
Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise,
but most probably it is just less efficient. Definitely something to be
benchmarked, analyzed for code size etc.
Jakub
11:36 p.m.
Note that there are teams within Linaro doing benchmarking and driving such. And once the
specific stack protector issue was raised, I poked Marcus in person and he escalated it
such that it will be looked at this next engineering cycle. In general we can plan ahead
if we know there are issues. We can't offer a 4 hour SLA. This isn't meant to be
aimed at Jakub :) just replying here.
Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no
architecture can guarantee every feature at all times. If you would like, we can scrub
through and find something broken on x86 that a test suite claims to work, and we can
infer all kinds of insulting things from that. But it will achieve nothing. Sometimes
stuff just is unintentionally broken. Audit was one such issue a year back - silent
register corruption due to a busted patch and lack of people historically using it to
notice. But we fixed that. And we will find more issues over time and fix those,
especially now that we have many folks running Fedora kernels and others in Linaro ramping
up on testing upstream with non-embedded configs.
Jon.
--
Sent from my iPad
On Jul 11, 2013, at 20:03, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote:
> On 07/11/2013 11:49 AM, Jakub Jelinek wrote:
>> Stack guards are present, but using libssp, which is the fallback way,
>> second class citizen and most likely slower than the standard way.
>> E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
>> even on ARM kernel provides AT_RANDOM that can be just used.
>> And I'd bet that even on ARM reading the stack guard via TLS (well,
>> static only always, i.e. hardcoded offset from TLS register), especially for
>> PIC, is faster than doing GOT read and two memory references.
>
> Thanks. Security-wise, is the implementation roughly equivalent in
> what is protected against, albeit less efficient?
Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise,
but most probably it is just less efficient. Definitely something to be
benchmarked, analyzed for code size etc.
Jakub
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12:34 a.m.
On Fri, Jul 12, 2013 at 12:36:16AM -0400, Jonathan Masters wrote:
Note that there are teams within Linaro doing benchmarking and
driving
such. And once the specific stack protector issue was raised, I poked
Marcus in person and he escalated it such that it will be looked at this
next engineering cycle. In general we can plan ahead if we know there are
issues. We can't offer a 4 hour SLA. This isn't meant to be aimed at
Jakub :) just replying here.
I hope my comments weren't considered as throwing stones on anybody, all I
wanted is that this is improved or at least analysed and benchmarked.
Jakub
12:58 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 12 Jul 2013 07:34:49 +0200
Jakub Jelinek <jakub(a)redhat.com> wrote:
On Fri, Jul 12, 2013 at 12:36:16AM -0400, Jonathan Masters wrote:
> Note that there are teams within Linaro doing benchmarking and
> driving such. And once the specific stack protector issue was
> raised, I poked Marcus in person and he escalated it such that it
> will be looked at this next engineering cycle. In general we can
> plan ahead if we know there are issues. We can't offer a 4 hour
> SLA. This isn't meant to be aimed at Jakub :) just replying here.
I hope my comments weren't considered as throwing stones on anybody,
all I wanted is that this is improved or at least analysed and
benchmarked.
Jakub
Jakub,
I do not believe they were interpreted as such. we all are on the same
team and want it to be better. I believe that Jon was just saying issue
will be worked on and given priority, its just going to take some
planning to do so. Other issues as they come up will also be addressed.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHfmw8ACgkQkSxm47BaWfcajwCeIXsI7jk2z4jcpSqxSmV8q35R
ilkAn1JmWvHDXM8W5mu72fP9jbl9yHYY
=jcM7
-----END PGP SIGNATURE-----
1:17 p.m.
The stack-protector issue has been raised to priority number one for the library folks
within the Linaro toolchain group. I have followed up with members of the toolchain and
steering committees as appropriate to ensure this is going to be taken care of extremely
swiftly.
Next!
--
Sent from my iPad
On Jul 12, 2013, at 5:36, Jonathan Masters <jcm(a)redhat.com> wrote:
Note that there are teams within Linaro doing benchmarking and
driving such. And once the specific stack protector issue was raised, I poked Marcus in
person and he escalated it such that it will be looked at this next engineering cycle. In
general we can plan ahead if we know there are issues. We can't offer a 4 hour SLA.
This isn't meant to be aimed at Jakub :) just replying here.
Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no
architecture can guarantee every feature at all times. If you would like, we can scrub
through and find something broken on x86 that a test suite claims to work, and we can
infer all kinds of insulting things from that. But it will achieve nothing. Sometimes
stuff just is unintentionally broken. Audit was one such issue a year back - silent
register corruption due to a busted patch and lack of people historically using it to
notice. But we fixed that. And we will find more issues over time and fix those,
especially now that we have many folks running Fedora kernels and others in Linaro ramping
up on testing upstream with non-embedded configs.
Jon.
--
Sent from my iPad
On Jul 11, 2013, at 20:03, Jakub Jelinek <jakub(a)redhat.com> wrote:
> On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote:
>> On 07/11/2013 11:49 AM, Jakub Jelinek wrote:
>>> Stack guards are present, but using libssp, which is the fallback way,
>>> second class citizen and most likely slower than the standard way.
>>> E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
>>> even on ARM kernel provides AT_RANDOM that can be just used.
>>> And I'd bet that even on ARM reading the stack guard via TLS (well,
>>> static only always, i.e. hardcoded offset from TLS register), especially for
>>> PIC, is faster than doing GOT read and two memory references.
>>
>> Thanks. Security-wise, is the implementation roughly equivalent in
>> what is protected against, albeit less efficient?
>
> Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise,
> but most probably it is just less efficient. Definitely something to be
> benchmarked, analyzed for code size etc.
>
> Jakub
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2:05 p.m.
On Thu, Jul 11, 2013 at 2:49 PM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 11:21:30AM -0700, Brendan Conoboy wrote:
> On 07/11/2013 08:46 AM, Till Maas wrote:
> >On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
> >>And following the legitimate concerns about stack-protector this was raised
by ARM into core Linaro as an urgent action for which engineering resource is being
assigned to correct this deficiency ASAP. Thus within a day an issue has been noted that
we were unaware of and is being worked through a process to correct it, as would be the
case with any deficiency on x86. The stack protection stuff will be fixed. Let's bike
shed over the next nitpick nuance that the anti-ARM crowd want to throw in the way ;)
> >
> >Was the flag ignored previously or why was this missing feature not
> >announced?
>
> Please see:
>
> https://lists.fedoraproject.org/pipermail/devel/2013-July/185106.html
>
> Per Carlos's email, the flag is not ignored, the feature is there,
> but it isn't as fully featured. Specifically stack guards are
> present but pointer guards are not. This was news to all of us.
Stack guards are present, but using libssp, which is the fallback way,
second class citizen and most likely slower than the standard way.
Am I missing something about using libssp? It is literally a library,
correct? Can you tell me which package provides it in Fedora? The
gcc package removes libssp* unconditionally, so it isn't provided from
that and I can't find a stand-alone libssp package.
josh
4:09 p.m.
On Thu, Jul 11, 2013 at 7:21 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/11/2013 08:46 AM, Till Maas wrote:
>
> On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote:
>>
>> And following the legitimate concerns about stack-protector this was
>> raised by ARM into core Linaro as an urgent action for which engineering
>> resource is being assigned to correct this deficiency ASAP. Thus within a
>> day an issue has been noted that we were unaware of and is being worked
>> through a process to correct it, as would be the case with any deficiency on
>> x86. The stack protection stuff will be fixed. Let's bike shed over the next
>> nitpick nuance that the anti-ARM crowd want to throw in the way ;)
>
>
> Was the flag ignored previously or why was this missing feature not
> announced?
Please see:
https://lists.fedoraproject.org/pipermail/devel/2013-July/185106.html
Per Carlos's email, the flag is not ignored, the feature is there, but it
isn't as 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.
I think this was a mistake from a number of parties PoV and was
actually discovered when someone was looking at an unrelated aarch64
problem. It was everyone's understanding that it was there, enabled
and good to go. There's other distros that believe that the problem is
solved [1]. I agree this is a needed feature and if we'd been aware of
the problem prior it would have been escalated upstream (ARM, Linaro
etc) long ago.
Peter
[1] https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/375189
10:03 a.m.
On Thu, Jul 11, 2013 at 12:14:24PM +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
>>
>> > Stack protector is not a new requirement in Fedora. It's been part of
>> > the distribution for years.
>>
>> xterm has been part of the distribution for years also, but it's not a
>> release requirement.
>
> The assumption has always been that all primary architectures embody the
> same level of functionality, with the exception of fundamental
> differences between the architectures. If things that are currently
> supported by the primary architectures cease to be supported by the
> primary architectures, that's a strong argument that they're not
> fundamental to Fedora. For example, in the absence of hardware nx
> support, I wouldn't argue that ARM should be forced to implement
> execshield - both because it's fundamentally tied to 32-bit x86, and
> because we've given up on supporting it. But yes, if ARM wanted to ship
> without xterm while the other primary architectures supported it, I'd
> say that that would be a blocker for shipping ARM as a primary
> architecture.
I think assumption is part of the problem here, you're assuming
something that is different to the assumption of others but as it's
not documented anywhere it means that neither opinion is neither right
nor wrong.
There is supporting documentation for DJ Delorie's stance:
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
"""
All Fedora packages must successfully compile and build into binary rpms on
at least one supported primary architecture, except where the package is
useful only on a secondary architecture (such as an architecture-specific
boot utility, microcode loader, or hardware configuration tool). Fedora
packagers should make every effort to support all primary architectures.
[...]
If a Fedora package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug
filed in bugzilla, describing the reason that the package does not
compile/build/work on that architecture[...]
"""
We wrote these guidelines to allow for non-symmetric packagesets on
different primary architectures due to bugs and lack of features. Those
things should be fixed but are not required. So, as I mentioned before,
there is probably a set of packages and features that should be considered
essential (or fundamental, to use mjg's wording) but that doesn't include
the whole packageset or all the things that another architecture does. If
a missing xterm package was the only thing that was being debated as holding
up arm as primary, I would say that the guidelines point at that *not* being
a blocker.
-Toshio
2:53 p.m.
On Thu, 2013-07-11 at 12:14 +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
>>
>> > Stack protector is not a new requirement in Fedora. It's been part of
>> > the distribution for years.
>>
>> xterm has been part of the distribution for years also, but it's not a
>> release requirement.
>
> The assumption has always been that all primary architectures embody the
> same level of functionality, with the exception of fundamental
> differences between the architectures. If things that are currently
> supported by the primary architectures cease to be supported by the
> primary architectures, that's a strong argument that they're not
> fundamental to Fedora. For example, in the absence of hardware nx
> support, I wouldn't argue that ARM should be forced to implement
> execshield - both because it's fundamentally tied to 32-bit x86, and
> because we've given up on supporting it. But yes, if ARM wanted to ship
> without xterm while the other primary architectures supported it, I'd
> say that that would be a blocker for shipping ARM as a primary
> architecture.
I think assumption is part of the problem here, you're assuming
something that is different to the assumption of others but as it's
not documented anywhere it means that neither opinion is neither right
nor wrong.
It may be useful to ground this discussion. As I read it, the official
definition of a primary architecture reads:
"Primary Architectures : These are architectures with the majority of
the users, the most common architectures. Build failures on these
architectures are fatal: no packages push to the repositories if they
fail to build for a primary architecture. To put it simply: These are
the architectures for which Fedora will delay a release if they are not
functional. Fedora package maintainers are required to make sure that
their package builds properly for this architecture (or is properly
ExcludeArch'd)."
Nothing about required functionality there. The page couches the
difference strictly in terms of importance to the package building
system and package push process.
https://fedoraproject.org/wiki/Architectures#Primary_Architectures
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:01 p.m.
On 07/11/2013 07:07 PM, Frank Ch. Eigler wrote:
Adam Williamson <awilliam(a)redhat.com> writes:
> [...] "Primary Architectures : These are architectures with the
> majority of the users, the most common architectures. [...]
By that standard, PA treatment of ARM seems way premature.
Or does it mean x86 as PA is 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. / blc(a)redhat.com
10:24 p.m.
Once upon a time, Brendan Conoboy <blc(a)redhat.com> said:
Or does it mean x86 as PA is out of line? There are a lot more
people with ARM devices than x86. Sorry everybody, we're going to
have to demote x86. ;-)
And how many of those ARM devices are supported by Fedora ARM?
--
Chris Adams <linux(a)cmadams.net>
10:50 p.m.
Hi
On Thu, Jul 11, 2013 at 11:01 PM, Brendan Conoboy wrote:
On
Or does it mean x86 as PA is out of line? There are a lot more people
with ARM devices than x86. Sorry everybody, we're going to have to demote
x86. ;-)
False marketing. Majority of ARM devices out there don't run Fedora and
never will.
Rahul
10:58 p.m.
On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote:
> Or does it mean x86 as PA is out of line? There are a lot more
people
> with ARM devices than x86. Sorry everybody, we're going to have to demote
> x86. ;-)
False marketing. Majority of ARM devices out there don't run Fedora and
never will.
Sooner or later, though, we probably _should_ deemphasize 32-bit x86.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:32 p.m.
On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote:
On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote:
> > Or does it mean x86 as PA is out of line? There are a lot more people
> > with ARM devices than x86. Sorry everybody, we're going to have to demote
> > x86. ;-)
> False marketing. Majority of ARM devices out there don't run Fedora and
> never will.
Sooner or later, though, we probably _should_ deemphasize 32-bit x86.
The website already links to 64-bit in preference to 32-bit. There's
arguably reasons to prefer 32-bit in certain memory-constrained
environments, but there's certainly arguments in favour of (say)
dropping most of the 32-bit x86 package set and turning it into a
specialised subset of the overall distribution.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:40 p.m.
On Jul 12, 2013, at 5:32, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote:
> On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote:
>>> Or does it mean x86 as PA is out of line? There are a lot more people
>>> with ARM devices than x86. Sorry everybody, we're going to have to
demote
>>> x86. ;-)
>> False marketing. Majority of ARM devices out there don't run Fedora and
>> never will.
>
> Sooner or later, though, we probably _should_ deemphasize 32-bit x86.
The website already links to 64-bit in preference to 32-bit. There's
arguably reasons to prefer 32-bit in certain memory-constrained
environments, but there's certainly arguments in favour of (say)
dropping most of the 32-bit x86 package set and turning it into a
specialised subset of the overall distribution.
Heck, if you're doing that, go x32 for those small set of libraries and force folks to
build against those :) We'll have a similar API on AArch64 in due course and I
wouldn't want to see a Primary Architecture missing feature parity with secondaries...
:P
5:04 p.m.
On Fri, Jul 12, 2013 at 5:32 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote:
> On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote:
> > > Or does it mean x86 as PA is out of line? There are a lot more people
> > > with ARM devices than x86. Sorry everybody, we're going to have to
demote
> > > x86. ;-)
> > False marketing. Majority of ARM devices out there don't run Fedora and
> > never will.
>
> Sooner or later, though, we probably _should_ deemphasize 32-bit x86.
The website already links to 64-bit in preference to 32-bit. There's
arguably reasons to prefer 32-bit in certain memory-constrained
environments, but there's certainly arguments in favour of (say)
dropping most of the 32-bit x86 package set and turning it into a
specialised subset of the overall distribution.
So sat make it a secondary arch? Not sure how you can be promoting
"specialised subset of the overall distribution" for x86-32 and saying
that ARM must support 100% of what mainline currently does! I
personally would be against demoting the x86 32 bit experience for the
general user but in terms of specialist packages there's already a
delta between x86-32 and 64 in mainline Fedora.
Peter
11 p.m.
On Thu, 11 Jul 2013 23:50:24 -0400
Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi
On Thu, Jul 11, 2013 at 11:01 PM, Brendan Conoboy wrote:
> On
> Or does it mean x86 as PA is out of line? There are a lot more
> people with ARM devices than x86. Sorry everybody, we're going to
> have to demote x86. ;-)
>
False marketing. Majority of ARM devices out there don't run Fedora
and never will.
Well, the same could be said for most x86 machines. ;)
In any case this sub-thread is a bit silly, IMHO.
I think any Fedora primary arch should have hardware readily available
and usable by interested community members. I think ARM and x86 both
meet this criteria fine.
kevin
11:47 p.m.
Hi
On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Thu, 11 Jul 2013 23:50:24 -0400
Rahul Sundaram wrote:
> False marketing. Majority of ARM devices out there don't run Fedora
> and never will.
Well, the same could be said for most x86 machines. ;)
Not really. If one is more realistic and only count systems capable of
running
Fedora, x86 clearly is far far more popular. ARM systems will get
more competitive in this space in the near future and we should be prepared
but we are not there yet and we should be honest about that. Counting
phones and tablets as ARM systems in the context of Fedora is entirely
misleading and folks promoting ARM should stop doing that.
Rahul
12:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 12 Jul 2013 00:47:03 -0400
Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi
On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Thu, 11 Jul 2013 23:50:24 -0400
> Rahul Sundaram wrote:
>
>
> > False marketing. Majority of ARM devices out there don't run
> > Fedora and never will.
>
> Well, the same could be said for most x86 machines. ;)
>
> Not really. If one is more realistic and only count systems capable
> of
running Fedora, x86 clearly is far far more popular. ARM systems
will get more competitive in this space in the near future and we
should be prepared but we are not there yet and we should be honest
about that. Counting phones and tablets as ARM systems in the
context of Fedora is entirely misleading and folks promoting ARM
should stop doing that.
Rahul
I think you will find that only 1 has. There are many things that could
be looked at down the road that are outside the scope of this change
proposal.
It is purely about removing 32 bit hardware floating point arm from
secondary and making it primary. which entails building as primary,
composing as primary, and shipping as primary. the things we build and
ship, OEM images, pxe tree etc, are not part of this Change.
There are lots of aspects of the ARM ecosystem that will evolve and get
better over time. I personally believe that we are at the tipping point
where ARM as primary is viable and something that Fedora should do in
order to enable and be at the forefront of emerging technologies.
I expect that down the road lots of new changes for ARM things will
come. some of them probably wont be things for x86. We the ARM team
have done a lot of work, and made a lot of improvements over the last
year. not everything is perfect but nothing is.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHfmSYACgkQkSxm47BaWffPyACgiRARGytKiM2EUXWPz7D/wrGb
fVwAoLj/RhenAKLNNHmyWyB8vHziwvuJ
=OPTT
-----END PGP SIGNATURE-----
11:01 p.m.
On
> Or does it mean x86 as PA is out of line? There are a lot more people
> with ARM devices than x86. Sorry everybody, we're going to have to demote
> x86. ;-)
>
False marketing. Majority of ARM devices out there don't run Fedora and
never will.
Exactly, and the market of this device out of the cellphones are very
limited, I mean for example in Costa Rica is almost impossible to get and
Raspberry Pi; but if you're thinking about make it *one of the
main*architectures, ok, great I support it!; make it
*the main? *Bad idea
*
*
-Isaac C.
2013/7/11 Rahul Sundaram <metherid(a)gmail.com>
Hi
On Thu, Jul 11, 2013 at 11:01 PM, Brendan Conoboy wrote:
> On
> Or does it mean x86 as PA is out of line? There are a lot more people
> with ARM devices than x86. Sorry everybody, we're going to have to demote
> x86. ;-)
>
False marketing. Majority of ARM devices out there don't run Fedora and
never will.
Rahul
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:08 a.m.
On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote:
Adam Williamson <awilliam(a)redhat.com> writes:
> [...] "Primary Architectures : These are architectures with the
> majority of the users, the most common architectures. [...]
By that standard, PA treatment of ARM seems way premature.
XO 1.75, /endofthread ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:12 p.m.
On Fri, Jul 12, 2013 at 9:08 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote:
> Adam Williamson <awilliam(a)redhat.com> writes:
>
> > [...] "Primary Architectures : These are architectures with the
> > majority of the users, the most common architectures. [...]
>
> By that standard, PA treatment of ARM seems way premature.
XO 1.75, /endofthread ;)
Not sure what you mean by that?
12:39 a.m.
On 07/10/2013 01:36 PM, Jakub Jelinek wrote:
On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
> armv7 has stack protector, aarch64 which is outside of this proposal
> doesnt yet have it.
Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
really have full stack protector support, while perhaps -fstack-protector
doesn't error out on armv7, it certainly isn't supported in glibc
(neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
arm having security standards high enough for being a primary architecture.
CCing Carlos so that they can discuss that.
Without specific support for stack protector (TLS stack guard and TLS pointer
guard) the glibc build will fall back to exporting two symbols for use by
libssp e.g. __stack_chk_guard, and __pointer_chk_guard. They serve a similar
purpose to the TLS variables but are global. Thus I would expect
-fstack-protector to work with libssp on 32-bit ARM, but I haven't verified
that. Even with that support the 32-bit ARM port of glibc lacks proper
pointer mangling/demangling routines so it doesn't make use of the
__pointer_chk_guard value.
In summary:
- I would expect -fstack-protector to work on 32-bit ARM via libssp and
support stack guards but not pointer guards (for pointer mangling).
Next steps:
- Verify libssp works correctly on 32-bit ARM.
- Look at enhancing the existing support in glibc.
- Add TLS stack guard.
- Add TLS pointer guard.
- Add pointer mangle/demangle support.
- Enhance aarch64 to support the same set of features.
The glibc team doesn't have any immediate plans to implement any of this.
Cheers,
Carlos.
9:55 a.m.
On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote:
Next steps:
- Verify libssp works correctly on 32-bit ARM.
- Look at enhancing the existing support in glibc.
- Add TLS stack guard.
- Add TLS pointer guard.
- Add pointer mangle/demangle support.
- Enhance aarch64 to support the same set of features.
Did the arm32 portions of this end up being completed for F20?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:42 a.m.
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote:
> Next steps:
> - Verify libssp works correctly on 32-bit ARM.
> - Look at enhancing the existing support in glibc.
> - Add TLS stack guard.
> - Add TLS pointer guard.
> - Add pointer mangle/demangle support.
> - Enhance aarch64 to support the same set of features.
Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support provides stack guard value in global
variable and is used by existing runtime. Regression tests are
passing in glibc testsuite. Verified working. Upstream verified
that global variable is the best compromise for performance across
all 32-bit ARM targets (TLS will be too slow in the average case).
- Pointer mangling:
- Not supported.
Upstream glibc 2.19 summary:
- Stack guard support already present using global variable.
- Will have pointer encryption support using global variable,
and could be a candidate for backport to f20.
~~~
commit b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8
Author: Will Newton <will.newton(a)linaro.org>
Date: Wed Aug 7 13:55:30 2013 +0100
ARM: Add pointer encryption support.
Add support for pointer encryption in glibc internal structures in C
and assembler code. Pointer encryption is a glibc security feature
described here:
https://sourceware.org/glibc/wiki/PointerEncryption
The ARM implementation uses global variables instead of thread pointer
relative accesses to get the value of the pointer encryption guard
because accessing the thread pointer can be very expensive on older
ARM cores.
...
~~~
Do we need pointer mangling? If so then we need someone to file an
f20 specific bug so the glibc team can look at backporting the fix.
I won't commit to it until I review exactly what might need changing.
Cheers,
Carlos.
11:53 a.m.
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
> Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support provides stack guard value in global
variable and is used by existing runtime. Regression tests are
passing in glibc testsuite. Verified working. Upstream verified
that global variable is the best compromise for performance across
all 32-bit ARM targets (TLS will be too slow in the average case).
What's the effective difference in security between this and the
existing ports?
- Pointer mangling:
- Not supported.
Do we ship it in the x86 ports?
Upstream glibc 2.19 summary:
- Stack guard support already present using global variable.
- Will have pointer encryption support using global variable,
and could be a candidate for backport to f20.
Cool. This is a runtime change, right? There's no requirement for a
rebuild to take advantage of it?
Do we need pointer mangling? If so then we need someone to file an
f20 specific bug so the glibc team can look at backporting the fix.
I won't commit to it until I review exactly what might need changing.
The aim was for parity of important features, but it doesn't seem like
we've ever advertised pointer guard as a Fedora feature so I'm not
personally that worried.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:16 p.m.
On 10/15/2013 12:53 PM, Matthew Garrett wrote:
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
> On 10/14/2013 10:55 AM, Matthew Garrett wrote:
>> Did the arm32 portions of this end up being completed for F20?
>
> For 32-bit ARM on f20:
>
> - Stack guard:
> - Existing glibc support provides stack guard value in global
> variable and is used by existing runtime. Regression tests are
> passing in glibc testsuite. Verified working. Upstream verified
> that global variable is the best compromise for performance across
> all 32-bit ARM targets (TLS will be too slow in the average case).
What's the effective difference in security between this and the
existing ports?
There is no effective security difference between accessing the randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.
It is only a performance optimization. The choice of a global variable vs.
DTV offset has only to do with the speed of access of the stack guard.
> - Pointer mangling:
> - Not supported.
Do we ship it in the x86 ports?
We do.
> Upstream glibc 2.19 summary:
>
> - Stack guard support already present using global variable.
>
> - Will have pointer encryption support using global variable,
> and could be a candidate for backport to f20.
Cool. This is a runtime change, right? There's no requirement for a
rebuild to take advantage of it?
That is correct. It is only an internal glibc change that does not
require any rebuilds for applications to take advantage of this.
The pointer mangling is hidden from the application.
> Do we need pointer mangling? If so then we need someone to file
an
> f20 specific bug so the glibc team can look at backporting the fix.
> I won't commit to it until I review exactly what might need changing.
The aim was for parity of important features, but it doesn't seem like
we've ever advertised pointer guard as a Fedora feature so I'm not
personally that worried.
Pointer mangling is useful, but we can roll that change into an update
and it should not in my opinion block F20.
I've filed:
Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=1019452
Cheers,
Carlos.
1:19 p.m.
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
Pointer mangling is useful, but we can roll that change into an
update
and it should not in my opinion block F20.
I've filed:
Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=1019452
Great. Thanks, Carlos!
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:27 p.m.
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
There is no effective security difference between accessing the
randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.
It is only a performance optimization. The choice of a global variable vs.
DTV offset has only to do with the speed of access of the stack guard.
DTV access is of course going to be expensive, after all, that is a function
call, the question was about reserving a word at fixed constant offset from
the TLS base and how expensive that is vs. global variable access.
For soft FP I guess global variable access must win, for -mtp=cp15
]it depends on how fast the mrc instruction is.
Jakub
1:38 p.m.
On 10/15/2013 02:27 PM, Jakub Jelinek wrote:
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
> There is no effective security difference between accessing the randomized
> stack guard value from a global variable or a value stored in the dynamic
> thread vector.
>
> It is only a performance optimization. The choice of a global variable vs.
> DTV offset has only to do with the speed of access of the stack guard.
DTV access is of course going to be expensive, after all, that is a function
call, the question was about reserving a word at fixed constant offset from
the TLS base and how expensive that is vs. global variable access.
For soft FP I guess global variable access must win, for -mtp=cp15
]it depends on how fast the mrc instruction is.
I talk about DTV, but I should really just say constant offset from TP
since that's what I mean. I don't actually mean using a TLS variable.
Will Newton tested the global variable access code on soft and hard TP
configurations and to quote some initial discussions:
https://sourceware.org/ml/libc-ports/2013-09/msg00134.html
~~~
From a back of the envelope calculation the cost of accessing TLS is
one cycle faster than accessing a global in best case (e.g.
Cortex-A15), considerably slower in common case (50-60 cycles,
Cortex-A9) and slower still in worst case (function call to libgcc and
the kernel, ARMv4/ARMv5).
~~~
Therefore for 32-bit ARM it was decided that a global variable was the
best choice.
For AArch64 it will definitely be a reserved word at a constant offset
from the TP since that's going to be fastest.
Does that clarify things?
Cheers,
Carlos.
4:11 p.m.
On Tue, Jul 09, 2013 at 03:00:05PM +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
<pbrobinson(a)gmail.com>
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
that we build and support. This will mean that all packages supported by the
ARM architecture must build for ARM to be released. With the release of Fedora
19 we have deprecated support for software floating support (ARMv5tel sfp) so
the only proposed addition to primary architectures is currently ARMv7
hardware floating point 32 bit support (ARMv7 hfp 32bit).
Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
test instances for maintainers as described here:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
f17-arm-test.scrye.com is currently not reachable for me.
Regards
Till
4:36 p.m.
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name> wrote:
On Tue, Jul 09, 2013 at 03:00:05PM +0200, Jaroslav Reznik wrote:
> = Proposed System Wide Change: ARM as primary Architecture =
> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
>
> Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
> <pbrobinson(a)gmail.com>
>
> Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
> that we build and support. This will mean that all packages supported by the
> ARM architecture must build for ARM to be released. With the release of Fedora
> 19 we have deprecated support for software floating support (ARMv5tel sfp) so
> the only proposed addition to primary architectures is currently ARMv7
> hardware floating point 32 bit support (ARMv7 hfp 32bit).
Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
http://fedoraproject.org/wiki/Architectures/ARM
The list is expanding regularly and there's a lot of other hardware
currently supported by remix primarily because the complete kernel
support isn't upstream.
test instances for maintainers as described here:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
I've never seen the above before.
There's instances available to QA
https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
f17-arm-test.scrye.com is currently not reachable for me.
Didn't know it existed so I'm not sure who maintains it.
Peter
10:46 a.m.
On Tue, 9 Jul 2013 22:36:39 +0100
Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas
<opensource(a)till.name>
wrote:
...snip...
> test instances for maintainers as described here:
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
I've never seen the above before.
There's instances available to QA
https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
I was working on adding 2 more SOC's for packagers earlier this week.
I wanted to see how much call there was for these... should I try and
make them accessable by all packagers? Or just have a group and
interested people could be added to that group?
> f17-arm-test.scrye.com is currently not reachable for me.
Didn't know it existed so I'm not sure who maintains it.
Thats me. ;)
It's an Genesi - EFIKA MX Smartbook, but it had an old Fedora (16? 17?)
on it and I haven't had time to try and get it working with anything
newer. If someone could assist me in bringing it back up on f19, I'd be
happy to make it available.
kevin
11:14 a.m.
Kevin Fenzi wrote:
I was working on adding 2 more SOC's for packagers earlier this
week.
I wanted to see how much call there was for these... should I try and
make them accessable by all packagers? Or just have a group and
interested people could be added to that group?
I for one would like to have access to some ARM systems for trying
things out. At least one for each arch that's a candidate to become
primary would be nice.
Initially I want to see the results of some uname and RPM commands to
make sure that I get things right in fedora-gnat-project-common.
In the future I hope to be able to test my Ada packages on ARM, but
that can't happen until somebody bootstraps GNAT on ARM. If I should
happen to come across a bucket of round tuits I might even try to
bootstrap GNAT myself, although I think it would be better done by
someone who knows more about GCC and ARM than I do.
Björn Persson
3:43 p.m.
On Wed, Jul 10, 2013 at 06:14:24PM +0200, Björn Persson wrote:
Kevin Fenzi wrote:
> I was working on adding 2 more SOC's for packagers earlier this week.
>
> I wanted to see how much call there was for these... should I try and
> make them accessable by all packagers? Or just have a group and
> interested people could be added to that group?
I for one would like to have access to some ARM systems for trying
things out. At least one for each arch that's a candidate to become
primary would be nice.
I appreciate that some people cannot or don't want to buy hardware,
but if you did have roughly $300 available, then you should probably
get the Oct 2012 Samsung Chromebook or the Arndale development board.
The Chromebook has the advantage IMHO that it's a decent netbook.
For more hardware options see:
https://fedoraproject.org/wiki/Category:Fedora_ARM_Hardware
Don't get an R-Pi. Not anything against it, just that it's a very old
and obsolete variant of the ARM architecture, and no longer supported
in Fedora (since Fedora 19 IIRC).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
4:24 p.m.
On Wed, Jul 10, 2013 at 9:43 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Jul 10, 2013 at 06:14:24PM +0200, Björn Persson wrote:
> Kevin Fenzi wrote:
> > I was working on adding 2 more SOC's for packagers earlier this week.
> >
> > I wanted to see how much call there was for these... should I try and
> > make them accessable by all packagers? Or just have a group and
> > interested people could be added to that group?
>
> I for one would like to have access to some ARM systems for trying
> things out. At least one for each arch that's a candidate to become
> primary would be nice.
I appreciate that some people cannot or don't want to buy hardware,
but if you did have roughly $300 available, then you should probably
get the Oct 2012 Samsung Chromebook or the Arndale development board.
The Chromebook has the advantage IMHO that it's a decent netbook.
$45 will get your a beaglebone which the last of the core support has
landed in 3.11 and I'm testing the kernel now and there should be a
F-19 remix soon...
Peter
3:06 a.m.
On Wed, Jul 10, 2013 at 10:24:05PM +0100, Peter Robinson wrote:
On Wed, Jul 10, 2013 at 9:43 PM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> On Wed, Jul 10, 2013 at 06:14:24PM +0200, Björn Persson wrote:
>> Kevin Fenzi wrote:
>> > I was working on adding 2 more SOC's for packagers earlier this week.
>> >
>> > I wanted to see how much call there was for these... should I try and
>> > make them accessable by all packagers? Or just have a group and
>> > interested people could be added to that group?
>>
>> I for one would like to have access to some ARM systems for trying
>> things out. At least one for each arch that's a candidate to become
>> primary would be nice.
>
> I appreciate that some people cannot or don't want to buy hardware,
> but if you did have roughly $300 available, then you should probably
> get the Oct 2012 Samsung Chromebook or the Arndale development board.
> The Chromebook has the advantage IMHO that it's a decent netbook.
$45 will get your a beaglebone which the last of the core support has
landed in 3.11 and I'm testing the kernel now and there should be a
F-19 remix soon...
But no hardware virtualization right? I think the minimum we should
target for Fedora development machines is whatever supports hardware
virtualization, which is A-15 IIRC.
However a $45 option *is* good for people on limited budgets or people
who want to play with ARM but don't care about virtualization.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
6:24 a.m.
> > I appreciate that some people cannot or don't want to
buy hardware,
> > but if you did have roughly $300 available, then you should probably
> > get the Oct 2012 Samsung Chromebook or the Arndale development board.
> > The Chromebook has the advantage IMHO that it's a decent netbook.
>
> $45 will get your a beaglebone which the last of the core support has
> landed in 3.11 and I'm testing the kernel now and there should be a
> F-19 remix soon...
But no hardware virtualization right? I think the minimum we should
target for Fedora development machines is whatever supports hardware
virtualization, which is A-15 IIRC.
No, not just A-15 but also A-12 [1] (not out yet) and the A-7 does too.
However a $45 option *is* good for people on limited budgets or
people
who want to play with ARM but don't care about virtualization.
Different people have different priorities I don't see a reason to
limit it. The Cortex-A7 [2] SoC design also supports HW virt and the
AllWinner A20 is that SoC so in theory should support it as well as
well and we're starting to see that out on the market, but the kernel
support not yet supported upstream though but it's around $59
Peter
[1] http://www.arm.com/products/processors/cortex-a/cortex-a12-processor.php
[2] http://www.arm.com/products/processors/cortex-a/cortex-a7.php
6:13 a.m.
在 2013-7-11 AM4:43，"Richard W.M. Jones" <rjones(a)redhat.xn--com>:-0s6m5392c
I appreciate that some people cannot or don't want to buy
hardware,
but if you did have roughly $300 available, then you should probably
get the Oct 2012 Samsung Chromebook or the Arndale development board.
The Chromebook has the advantage IMHO that it's a decent netbook.
Agree, I have 2 Arndale now, its performance can beats any other v7
devices.
But. I'm not sure if A15 can be fully supported. Currently I only see many
A9 hardwares.
12:07 p.m.
On 07/15/2013 04:13 AM, Christopher Meng wrote:
Agree, I have 2 Arndale now, its performance can beats any other v7
devices.
But. I'm not sure if A15 can be fully supported. Currently I only see
many A9 hardwares.
Some requisite patches weren't upstream in time for Fedora 19's 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.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:15 p.m.
On Mon, 2013-07-15 at 10:07 -0700, Brendan Conoboy wrote:
Some requisite patches weren't upstream in time for Fedora
19's 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
I think that's s/Arndale/Chromebook/
-Chris
12:36 p.m.
On Mon, 2013-07-15 at 10:28 -0700, Brendan Conoboy wrote:
On 07/15/2013 10:15 AM, Chris Tyler wrote:
> I think that's s/Arndale/Chromebook/
Same SoC, different peripherals sticking out.
Right -- but also different boot processes. I was just noting that the
image for which you provided the URL is for the Chromebook.
-Chris
4:39 a.m.
Hi,
On 07/10/2013 06:14 PM, Björn Persson wrote:
Kevin Fenzi wrote:
> I was working on adding 2 more SOC's for packagers earlier this week.
>
> I wanted to see how much call there was for these... should I try and
> make them accessable by all packagers? Or just have a group and
> interested people could be added to that group?
I for one would like to have access to some ARM systems for trying
things out. At least one for each arch that's a candidate to become
primary would be nice.
Initially I want to see the results of some uname and RPM commands to
make sure that I get things right in fedora-gnat-project-common.
In the future I hope to be able to test my Ada packages on ARM, but
that can't happen until somebody bootstraps GNAT on ARM. If I should
happen to come across a bucket of round tuits I might even try to
bootstrap GNAT myself, although I think it would be better done by
someone who knows more about GCC and ARM than I do.
<warning shameless plug of personal project>
If you want some ARM hardware to play with, you can get some really
cheap Allwinner SOC based devices, most of them with a 1 Ghz cortex
A8, 1 GB or RAM and an sdcard slot (and usb, hdmi out and wifi).
Anything with an allwinner A10, A10s or A13 will work with the
Fedora A10 remix:
https://fedoraproject.org/wiki/Architectures/ARM/AllwinerA10
And I'm working on adding A20 support (dual cortex a7 @ 1 Ghz) atm.
The most well known devices with an A10(s) are the mk802 hdmi
tv-sticks. Simply search ebay for mk802, buy now only, sort
price+shipping low -> high and at the end of the first page
you will find the first A10 devices. At this moment the cheapest
one is $35.23. Which is a pretty sweat deal for what in essence
is a complete computer with a 1Ghz cpu and 1 GB RAM.
Beware there are also mk802-iii devices which have a completely
different CPU. Always check the description mentions allwinner
and/or A10 or A10s.
Note the A10 SOC also has sata out, vga out, composite video out,
wired ethernet, etc. So if you do some more searching you can find
some very interesting devices. Note worthy are the cubieboard:
http://linux-sunxi.org/Cubieboard
And the olimex a10s-olinuxio-micro:
https://www.olimex.com/Products/OLinuXino/A10S/A10S-OLinuXino-MICRO
The olimex design is fully open hardware with schematics and pcb
layout files available. The cubieboard also has schematics available.
Note the olimex uses the A10s and as such does not have sata.
Regards,
Hans
5:25 a.m.
----- Original Message -----
Hi,
On 07/10/2013 06:14 PM, Björn Persson wrote:
> Kevin Fenzi wrote:
>> I was working on adding 2 more SOC's for packagers earlier this week.
>>
>> I wanted to see how much call there was for these... should I try and
>> make them accessable by all packagers? Or just have a group and
>> interested people could be added to that group?
>
> I for one would like to have access to some ARM systems for trying
> things out. At least one for each arch that's a candidate to become
> primary would be nice.
>
> Initially I want to see the results of some uname and RPM commands to
> make sure that I get things right in fedora-gnat-project-common.
>
> In the future I hope to be able to test my Ada packages on ARM, but
> that can't happen until somebody bootstraps GNAT on ARM. If I should
> happen to come across a bucket of round tuits I might even try to
> bootstrap GNAT myself, although I think it would be better done by
> someone who knows more about GCC and ARM than I do.
<warning shameless plug of personal project>
If you want some ARM hardware to play with, you can get some really
cheap Allwinner SOC based devices, most of them with a 1 Ghz cortex
A8, 1 GB or RAM and an sdcard slot (and usb, hdmi out and wifi).
Anything with an allwinner A10, A10s or A13 will work with the
Fedora A10 remix:
https://fedoraproject.org/wiki/Architectures/ARM/AllwinerA10
And I'm working on adding A20 support (dual cortex a7 @ 1 Ghz) atm.
The most well known devices with an A10(s) are the mk802 hdmi
tv-sticks. Simply search ebay for mk802, buy now only, sort
price+shipping low -> high and at the end of the first page
you will find the first A10 devices. At this moment the cheapest
one is $35.23. Which is a pretty sweat deal for what in essence
is a complete computer with a 1Ghz cpu and 1 GB RAM.
Beware there are also mk802-iii devices which have a completely
different CPU. Always check the description mentions allwinner
and/or A10 or A10s.
Note the A10 SOC also has sata out, vga out, composite video out,
wired ethernet, etc. So if you do some more searching you can find
some very interesting devices. Note worthy are the cubieboard:
http://linux-sunxi.org/Cubieboard
And the olimex a10s-olinuxio-micro:
https://www.olimex.com/Products/OLinuXino/A10S/A10S-OLinuXino-MICRO
The olimex design is fully open hardware with schematics and pcb
layout files available. The cubieboard also has schematics available.
Note the olimex uses the A10s and as such does not have sata.
Speaking about hardware - and that's more a question for Spot - could
be possible to organize another round of HW give away as we did with
Raspberries? With a different HW, that's supported in Fedora and it
seems like there are pretty cheap options either. With some metrics,
like commits/packages/packages that need significant effort to make
it working on ARM...
Jaroslav
Regards,
Hans
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6 a.m.
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
Speaking about hardware - and that's more a question for Spot - could
be possible to organize another round of HW give away as we did with
Raspberries? With a different HW, that's supported in Fedora and it
seems like there are pretty cheap options either. With some metrics,
like commits/packages/packages that need significant effort to make
it working on ARM...
The sentiment is nice, but I don't think that last hardware give away
went all that well. Also, to get something competent is going to cost
money. I have no idea what the Fedora budget looks like, but frankly
I'd rather use money on something more beneficial than buying hardware
for a bunch of people that aren't already working on ARM. It will
likely have a shiny factor of about 1 week, and then it will sit on
their desk collecting dust.
josh
6:35 a.m.
On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
>
> Speaking about hardware - and that's more a question for Spot - could
> be possible to organize another round of HW give away as we did with
> Raspberries? With a different HW, that's supported in Fedora and it
> seems like there are pretty cheap options either. With some metrics,
> like commits/packages/packages that need significant effort to make
> it working on ARM...
The sentiment is nice, but I don't think that last hardware give away
went all that well. Also, to get something competent is going to cost
money. I have no idea what the Fedora budget looks like, but frankly
I'd rather use money on something more beneficial than buying hardware
for a bunch of people that aren't already working on ARM. It will
likely have a shiny factor of about 1 week, and then it will sit on
their desk collecting dust.
I agree, not sure what the contribution to the RPi stuff was like but
for the XOs that were given away I'm not aware of a single
contribution to any of the Fedora/OLPC/Sugar projects as a result of
it.
Peter
6:41 a.m.
On Thu, Jul 11, 2013 at 12:35:36PM +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer
<jwboyer(a)gmail.com> wrote:
> On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
>>
>> Speaking about hardware - and that's more a question for Spot - could
>> be possible to organize another round of HW give away as we did with
>> Raspberries? With a different HW, that's supported in Fedora and it
>> seems like there are pretty cheap options either. With some metrics,
>> like commits/packages/packages that need significant effort to make
>> it working on ARM...
>
> The sentiment is nice, but I don't think that last hardware give away
> went all that well. Also, to get something competent is going to cost
> money. I have no idea what the Fedora budget looks like, but frankly
> I'd rather use money on something more beneficial than buying hardware
> for a bunch of people that aren't already working on ARM. It will
> likely have a shiny factor of about 1 week, and then it will sit on
> their desk collecting dust.
I agree, not sure what the contribution to the RPi stuff was like but
for the XOs that were given away I'm not aware of a single
contribution to any of the Fedora/OLPC/Sugar projects as a result of
it.
People who are inclined to do non-trivial contributions to ARM will
probably just go out and buy some ARM hardware themselves, particularly
given how cheaply you can obtain the hardware. For others, having a
central pool of Fedora managed/owned ARM hardware they can get temporary
access to for the purpose of troubleshooting is likely a better use of
limited funds.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 11 Jul 2013 12:41:40 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 12:35:36PM +0100, Peter Robinson wrote:
> On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer <jwboyer(a)gmail.com>
> wrote:
> > On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik
> > <jreznik(a)redhat.com> wrote:
> >>
> >> Speaking about hardware - and that's more a question for Spot -
> >> could be possible to organize another round of HW give away as
> >> we did with Raspberries? With a different HW, that's supported
> >> in Fedora and it seems like there are pretty cheap options
> >> either. With some metrics, like commits/packages/packages that
> >> need significant effort to make it working on ARM...
> >
> > The sentiment is nice, but I don't think that last hardware give
> > away went all that well. Also, to get something competent is
> > going to cost money. I have no idea what the Fedora budget looks
> > like, but frankly I'd rather use money on something more
> > beneficial than buying hardware for a bunch of people that aren't
> > already working on ARM. It will likely have a shiny factor of
> > about 1 week, and then it will sit on their desk collecting dust.
>
> I agree, not sure what the contribution to the RPi stuff was like
> but for the XOs that were given away I'm not aware of a single
> contribution to any of the Fedora/OLPC/Sugar projects as a result of
> it.
People who are inclined to do non-trivial contributions to ARM will
probably just go out and buy some ARM hardware themselves,
particularly given how cheaply you can obtain the hardware. For
others, having a central pool of Fedora managed/owned ARM hardware
they can get temporary access to for the purpose of troubleshooting
is likely a better use of limited funds.
I agree, the developer nodes we are looking to make available while
server nodes without video, run VNC very well, I have tested XFCE,
LXDE, KDE, Sugar, and Mate during f19 development via vnc on them as
well as locally on both pandaboard and trimslice. as well as XFCE and
KDE on chromebook.
There are lots of options for testing all the different aspects of the
Fedora software world on ARM.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHe4e0ACgkQkSxm47BaWfdKywCbBQiUv3/pNHJ48HBltA6pSqLl
aAYAnj+bTuC9LPf4ubkhvAOcFsQVWMsk
=wmWL
-----END PGP SIGNATURE-----
9:24 a.m.
On Thu, Jul 11, 2013 at 12:35:36 +0100,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
I agree, not sure what the contribution to the RPi stuff was like but
for the XOs that were given away I'm not aware of a single
contribution to any of the Fedora/OLPC/Sugar projects as a result of
it.
I've done a little testing with my XO 1.75 that I got as part of this.
If I can run straight Fedora on it I'll switch over to it and do more
testing. But the last time I asked, Fedora's ARM support didn't include
a usable kernel for it. Still I have tried playing some games on it,
and it is usable for some that don't need 3D graphics. The screen size
is a bit small, but is still usable for playing Colossus (which uses java).
10:47 a.m.
On Thu, Jul 11, 2013 at 12:35:36PM +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer
<jwboyer(a)gmail.com> wrote:
> On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
>>
>> Speaking about hardware - and that's more a question for Spot - could
>> be possible to organize another round of HW give away as we did with
>> Raspberries? With a different HW, that's supported in Fedora and it
>> seems like there are pretty cheap options either. With some metrics,
>> like commits/packages/packages that need significant effort to make
>> it working on ARM...
>
> The sentiment is nice, but I don't think that last hardware give away
> went all that well. Also, to get something competent is going to cost
> money. I have no idea what the Fedora budget looks like, but frankly
> I'd rather use money on something more beneficial than buying hardware
> for a bunch of people that aren't already working on ARM. It will
> likely have a shiny factor of about 1 week, and then it will sit on
> their desk collecting dust.
I agree, not sure what the contribution to the RPi stuff was like but
for the XOs that were given away I'm not aware of a single
contribution to any of the Fedora/OLPC/Sugar projects as a result of
it.
IMHO it is also not that easy to get something going with ARM on Fedora.
For example I bought a Sheeva-ARM devices to get upstream release
monitoring running on it . But even when I got it installed,
the device crashed with a kernel soft lockup. Now the devices are no
longer supported. I got a RPi (from the hardware summer of fun) with the
same intent, but until today it is not properly supported and won't. In
the meantime I bought a Cubieboard, no luck here as well. Since the
Cubieboard remix even requires HDMI output and does not work headless, I
did not try it because if missing HDMI hardware. Also all the Fedora ARM
efforts usually require to dd some images instead of just allowing to
run a textmode anaconda via serial or some other installer, which just
feels quirky.
So now I gave up and bought a x86_64 microserver, which will then do the
release monitoring among other things.
Regards
Till
10:58 a.m.
On 07/11/2013 08:47 AM, Till Maas wrote:
IMHO it is also not that easy to get something going with ARM on
Fedora.
For example I bought a Sheeva-ARM devices to get upstream release
monitoring running on it . But even when I got it installed,
the device crashed with a kernel soft lockup.
BZ#?
Now the devices are no
longer supported. I got a RPi (from the hardware summer of fun) with the
same intent, but until today it is not properly supported and won't.
Never been supported by Fedora ARM for lack of upstream kernel and
firmware license issues. It's a Seneca College remix, but AFAIK it
works great:
http://pidora.ca/
In
the meantime I bought a Cubieboard, no luck here as well. Since the
Cubieboard remix even requires HDMI output and does not work headless, I
did not try it because if missing HDMI hardware.
Never been supported by Fedora ARM for lack of upstream kernel. That
might change in the next release as the upstream is coming along.
Also all the Fedora ARM
efforts usually require to dd some images instead of just allowing to
run a textmode anaconda via serial or some other installer, which just
feels quirky.
F19 on ARM supports interactive anaconda installs over serial. Or vnc
installs if you want graphics. Or kickstart installs if you want
automation.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:38 p.m.
On Thu, Jul 11, 2013 at 08:58:11AM -0700, Brendan Conoboy wrote:
On 07/11/2013 08:47 AM, Till Maas wrote:
>IMHO it is also not that easy to get something going with ARM on Fedora.
>For example I bought a Sheeva-ARM devices to get upstream release
>monitoring running on it . But even when I got it installed,
>the device crashed with a kernel soft lockup.
BZ#?
https://bugzilla.redhat.com/show_bug.cgi?id=865022
It is currently closed, because I did not re-test anymore after it was
announced that the device won't be supported anymore soon.
> Now the devices are no
>longer supported. I got a RPi (from the hardware summer of fun) with the
>same intent, but until today it is not properly supported and won't.
Never been supported by Fedora ARM for lack of upstream kernel and
firmware license issues. It's a Seneca College remix, but AFAIK it
works great:
http://pidora.ca/
Yes, but this is probably also a reason why there was little Fedora
related outcome from the Hardware summer of fun.
> In
>the meantime I bought a Cubieboard, no luck here as well. Since the
>Cubieboard remix even requires HDMI output and does not work headless, I
>did not try it because if missing HDMI hardware.
Never been supported by Fedora ARM for lack of upstream kernel.
That might change in the next release as the upstream is coming
along.
> Also all the Fedora ARM
>efforts usually require to dd some images instead of just allowing to
>run a textmode anaconda via serial or some other installer, which just
>feels quirky.
F19 on ARM supports interactive anaconda installs over serial. Or
vnc installs if you want graphics. Or kickstart installs if you
want automation.
This sounds promising. Are there remix-anaconda images that can be used
to test this on a Cubieboard?
Regards
Till
1:50 p.m.
On 07/11/2013 11:38 AM, Till Maas wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=865022
It is currently closed, because I did not re-test anymore after it was
announced that the device won't be supported anymore soon.
Thanks. Since the last update we have added a dedicated ARM kernel
maintainer. Fedora 18 on armv5tel is still supported. If you would
like to pursue the issue further we will assist.
> Never been supported by Fedora ARM for lack of upstream kernel
and
> firmware license issues. It's a Seneca College remix, but AFAIK it
> works great:
>
> http://pidora.ca/
Yes, but this is probably also a reason why there was little Fedora
related outcome from the Hardware summer of fun.
Not sure I follow. Before Pidora Seneca still supported the Pi on
armv5tel, as early as F13.
This sounds promising. Are there remix-anaconda images that can be
used
to test this on a Cubieboard?
I'm not aware of the current remix situation on F19- Perhaps Hans will
comment?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
11:34 a.m.
On Thu, Jul 11, 2013 at 11:50:00AM -0700, Brendan Conoboy wrote:
On 07/11/2013 11:38 AM, Till Maas wrote:
>https://bugzilla.redhat.com/show_bug.cgi?id=865022
>It is currently closed, because I did not re-test anymore after it was
>announced that the device won't be supported anymore soon.
Thanks. Since the last update we have added a dedicated ARM kernel
maintainer. Fedora 18 on armv5tel is still supported. If you would
like to pursue the issue further we will assist.
Thank you, but since the device will not be supported by Fedora in about
6 months, I do not see much use in this.
>>Never been supported by Fedora ARM for lack of upstream
kernel and
>>firmware license issues. It's a Seneca College remix, but AFAIK it
>>works great:
>>
>>http://pidora.ca/
>
>Yes, but this is probably also a reason why there was little Fedora
>related outcome from the Hardware summer of fun.
Not sure I follow. Before Pidora Seneca still supported the Pi on
armv5tel, as early as F13.
The possibility to use a Remix is not that big promoted, therefore it
was not clear to me that I could run Pidora on it with at least packages
similar to Fedora.
Regards
Till
2:03 a.m.
Hi,
On 07/11/2013 08:38 PM, Till Maas wrote:
On Thu, Jul 11, 2013 at 08:58:11AM -0700, Brendan Conoboy wrote:
<snip>
> vnc installs if you want graphics. Or kickstart installs if you
> want automation.
This sounds promising. Are there remix-anaconda images that can be used
to test this on a Cubieboard?
I plan to release F-19 allwinner remix images coming Wednesday or
Thursday. I did not do a same day release as F-19 gold (although I could
have) as I'm working on A20 support (ie cubieboard2), and I want to have
that as part of the release.
I still hope to have A20 support done before the release, but I will do
a release regardless of the A20 state, since I'm going on vacation
starting next week Friday and I want to have a release out before then.
As for the anaconda install support, my images will be a copy of:
Fedora-XFCE-armhfp-19-1-sda.raw.xz with the kernel and uboot replaced
+ some other tweaks, but otherwise unmodified. So if that image can
do anaconda installs, my images should be able to do it too (assuming
there is no model specific code in anaconda which quite likely is wrong).
Regards,
Hans
11:40 a.m.
On Fri, Jul 12, 2013 at 09:03:24AM +0200, Hans de Goede wrote:
As for the anaconda install support, my images will be a copy of:
Fedora-XFCE-armhfp-19-1-sda.raw.xz with the kernel and uboot replaced
+ some other tweaks, but otherwise unmodified. So if that image can
do anaconda installs, my images should be able to do it too (assuming
there is no model specific code in anaconda which quite likely is wrong).
The image name does not really sound like something that can be run
headless to install Fedora. I was expecting something more like a
kernel, a initrd and a pool of verifiable RPMs that can be used as
installation source. For example for x86 an installation iso image would
do, because it is GPG signed and contains everything to setup a Fedora
system that can install packages with package signature verification.
Is there something like this for ARM? The installation page does not
seem to mention this:
https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation
Regards
Till
2:06 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 12 Jul 2013 18:40:21 +0200
Till Maas <opensource(a)till.name> wrote:
On Fri, Jul 12, 2013 at 09:03:24AM +0200, Hans de Goede wrote:
> As for the anaconda install support, my images will be a copy of:
> Fedora-XFCE-armhfp-19-1-sda.raw.xz with the kernel and uboot
> replaced
> + some other tweaks, but otherwise unmodified. So if that image can
> do anaconda installs, my images should be able to do it too
> (assuming there is no model specific code in anaconda which quite
> likely is wrong).
The image name does not really sound like something that can be run
headless to install Fedora. I was expecting something more like a
kernel, a initrd and a pool of verifiable RPMs that can be used as
installation source. For example for x86 an installation iso image
would do, because it is GPG signed and contains everything to setup a
Fedora system that can install packages with package signature
verification.
Is there something like this for ARM? The installation page does not
seem to mention this:
https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation
we have a kernel and initramfs, that can be pxe booted or you can boot
and load, however we have not made it the primary mathod of
install for boards because they generally can only boot and run from a
sdcard you would need to install to the boot media. it quite possibly
works just fine other than not installing uboot to the sdcard in the
way needed, however for non omap systems that copy the file into a
partition it will likely work ok. so cubieboard since you need to dd
u-boot into a particular location of the sdcard it should still be
there post install. Its not tested at all however.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHgU6cACgkQkSxm47BaWfdCowCgpKgZ1y1/2QQsXLToQ6rzCTiX
O2YAn2WgdCrPwzjMtxkT0joUUftC49I8
=7T8k
-----END PGP SIGNATURE-----
4:36 a.m.
On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote:
we have a kernel and initramfs, that can be pxe booted or you can
boot
and load, however we have not made it the primary mathod of
install for boards because they generally can only boot and run from a
sdcard you would need to install to the boot media. it quite possibly
works just fine other than not installing uboot to the sdcard in the
way needed, however for non omap systems that copy the file into a
partition it will likely work ok. so cubieboard since you need to dd
u-boot into a particular location of the sdcard it should still be
there post install. Its not tested at all however.
I cannot completely follow here. However, I guess the images you mean
are the following:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
Is there any particular reason, why there is no signed CHECKSUM file for
these? What is required for these images to be able to run anaconda and
install packages? I assume that anaconda won't verify package
signatures, therefore I guess a copy of manual verified RPMs is
required?
And what can be done with the live image:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
(It is also not signed)
The raw disk images seem to be signed:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Images/a...
But I noticed that here SHA1 is used instead of SHA256 for the GPG
signature and the comment about sha256sum being used to generate the
hashes is missing, e.g. the primary archs have files like these:
https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM
Here is a ticket for this:
https://fedorahosted.org/fedora-infrastructure/ticket/3888
Regards
Till
11:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 13 Jul 2013 11:36:00 +0200
Till Maas <opensource(a)till.name> wrote:
On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote:
> we have a kernel and initramfs, that can be pxe booted or you can
> boot and load, however we have not made it the primary mathod of
> install for boards because they generally can only boot and run
> from a sdcard you would need to install to the boot media. it quite
> possibly works just fine other than not installing uboot to the
> sdcard in the way needed, however for non omap systems that copy
> the file into a partition it will likely work ok. so cubieboard
> since you need to dd u-boot into a particular location of the
> sdcard it should still be there post install. Its not tested at
> all however.
I cannot completely follow here. However, I guess the images you mean
are the following:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
Is there any particular reason, why there is no signed CHECKSUM file
for these? What is required for these images to be able to run
anaconda and install packages? I assume that anaconda won't verify
package signatures, therefore I guess a copy of manual verified RPMs
is required?
We don't make and sign CHECKSUMS for the equivalent bits on any arch.
to have anaconda run you need to boot the kernel and initramfs. and
pass to it options to find the rest of the bits. exactly as is done on
primary. though you likely need to instrall u-boot to the sdcard then
setup a boot.scr that loads things for you. and hopefully anaconda will
let you destroy it when running. since you will be booting from the
target media.
And what can be done with the live image:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
(It is also not signed)
Also true of all arches, we don't make CHECKSUMS or sign them
The raw disk images seem to be signed:
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Images/a...
But I noticed that here SHA1 is used instead of SHA256 for the GPG
signature and the comment about sha256sum being used to generate the
hashes is missing, e.g. the primary archs have files like these:
https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM
probably a difference in the setup of the sigul between primary and
secondary arches. the comment about sha256sum only ever exists in pungi
generated CHECKSUMS all the manually generated ones which includes Live
and Spins trees do not have it. if you want to change things i suggest
you join Release engineering and help me to make things better rather
than just complain that how I do things doesn't suit your needs.
Release Engineering is me with a lot of help from Kevin Fenzi and over
the last few releases a lot more has been asked from me which means
many things that could have been done have not been. as is Both Kevin
and I work a lot more than 40 hours.
Here is a ticket for this:
https://fedorahosted.org/fedora-infrastructure/ticket/3888
the ticket is for nothing mentioned in this email
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHhhWQACgkQkSxm47BaWfc8AgCgvO64NUjKAZIW55jf3lZ/zulF
r4MAnj8tst7Q0iOSIFej0o0FbWSIYiHP
=jAlW
-----END PGP SIGNATURE-----
12:36 p.m.
On Sat, Jul 13, 2013 at 11:50:40AM -0500, Dennis Gilmore wrote:
On Sat, 13 Jul 2013 11:36:00 +0200
Till Maas <opensource(a)till.name> wrote:
> On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote:
>
> > we have a kernel and initramfs, that can be pxe booted or you can
> > boot and load, however we have not made it the primary mathod of
> > install for boards because they generally can only boot and run
> > from a sdcard you would need to install to the boot media. it quite
> > possibly works just fine other than not installing uboot to the
> > sdcard in the way needed, however for non omap systems that copy
> > the file into a partition it will likely work ok. so cubieboard
> > since you need to dd u-boot into a particular location of the
> > sdcard it should still be there post install. Its not tested at
> > all however.
>
> I cannot completely follow here. However, I guess the images you mean
> are the following:
>
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
>
> Is there any particular reason, why there is no signed CHECKSUM file
> for these? What is required for these images to be able to run
> anaconda and install packages? I assume that anaconda won't verify
> package signatures, therefore I guess a copy of manual verified RPMs
> is required?
We don't make and sign CHECKSUMS for the equivalent bits on any arch.
to have anaconda run you need to boot the kernel and initramfs. and
pass to it options to find the rest of the bits. exactly as is done on
primary. though you likely need to instrall u-boot to the sdcard then
setup a boot.scr that loads things for you. and hopefully anaconda will
let you destroy it when running. since you will be booting from the
target media.
> And what can be done with the live image:
>
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/a...
> (It is also not signed)
Also true of all arches, we don't make CHECKSUMS or sign them
At least a while ago these files were available in signed iso images for
the primary arch. Nevertheless, what is (supposed to be) possible with
the LiveOS image for ARM?
> The raw disk images seem to be signed:
>
http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Images/a...
> But I noticed that here SHA1 is used instead of SHA256 for the GPG
> signature and the comment about sha256sum being used to generate the
> hashes is missing, e.g. the primary archs have files like these:
> https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM
probably a difference in the setup of the sigul between primary and
secondary arches. the comment about sha256sum only ever exists in pungi
generated CHECKSUMS all the manually generated ones which includes Live
and Spins trees do not have it. if you want to change things i suggest
you join Release engineering and help me to make things better rather
than just complain that how I do things doesn't suit your needs.
Release Engineering is me with a lot of help from Kevin Fenzi and over
the last few releases a lot more has been asked from me which means
many things that could have been done have not been. as is Both Kevin
and I work a lot more than 40 hours.
Thank you, I will gladly help. I believe I already helped with releng
tasks in the past, back then when buildroot overrides had to be done
manually. If you give me any pointers to what I can do to get the things
signed, I will take a look. I found so far
https://fedoraproject.org/wiki/Stage_final_release_for_mirrors
https://fedoraproject.org/wiki/Create_release_signing_key
but they are not up-to-date and only show the user POV for the sigul
system not the admin POV. So how do we proceed here? If you give me
access to the respective system, I can start with updating the
documentation and you can review them to verify I understand the
process. I guess this probably also helps to identify the reason for the
different hash algorithms used.
> Here is a ticket for this:
> https://fedorahosted.org/fedora-infrastructure/ticket/3888
the ticket is for nothing mentioned in this email
It mentions the different hash method of the CHECKSUM files.
Regards
Till
4:34 p.m.
On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
On Tue, 9 Jul 2013 22:36:39 +0100
Peter Robinson <pbrobinson(a)gmail.com> wrote:
> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name>
> wrote:
...snip...
> > test instances for maintainers as described here:
> > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
>
> I've never seen the above before.
>
> There's instances available to QA
> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
I was working on adding 2 more SOC's for packagers earlier this week.
I wanted to see how much call there was for these... should I try and
make them accessable by all packagers? Or just have a group and
interested people could be added to that group?
They're probably useful for update testing, but I don't think they're
much use for release validation, since that generally equates to testing
deployment, which you can't really do from an ssh session.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:01 p.m.
On 07/10/2013 05:34 PM, Adam Williamson wrote:
On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
> On Tue, 9 Jul 2013 22:36:39 +0100
> Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name>
>> wrote:
>
> ...snip...
>
>>> test instances for maintainers as described here:
>>>
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
>>
>> I've never seen the above before.
>>
>> There's instances available to QA
>> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
>
> I was working on adding 2 more SOC's for packagers earlier this week.
>
> I wanted to see how much call there was for these... should I try and
> make them accessable by all packagers? Or just have a group and
> interested people could be added to that group?
They're probably useful for update testing, but I don't think they're
much use for release validation, since that generally equates to testing
deployment, which you can't really do from an ssh session.
FWIW I'll be proposing (likely tomorrow) an F20 feature/change for ARM virt on
x86, which will track the missing libvirt/virt-manager/etc bits needed to run
Fedora ARM in a VM on x86 using standard tools. Hopefully that helps here.
- Cole
5:02 p.m.
On Wed, 2013-07-10 at 18:01 -0400, Cole Robinson wrote:
On 07/10/2013 05:34 PM, Adam Williamson wrote:
> On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
>> On Tue, 9 Jul 2013 22:36:39 +0100
>> Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>
>>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name>
>>> wrote:
>>
>> ...snip...
>>
>>>> test instances for maintainers as described here:
>>>>
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
>>>
>>> I've never seen the above before.
>>>
>>> There's instances available to QA
>>> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
>>
>> I was working on adding 2 more SOC's for packagers earlier this week.
>>
>> I wanted to see how much call there was for these... should I try and
>> make them accessable by all packagers? Or just have a group and
>> interested people could be added to that group?
>
> They're probably useful for update testing, but I don't think they're
> much use for release validation, since that generally equates to testing
> deployment, which you can't really do from an ssh session.
>
FWIW I'll be proposing (likely tomorrow) an F20 feature/change for ARM virt on
x86, which will track the missing libvirt/virt-manager/etc bits needed to run
Fedora ARM in a VM on x86 using standard tools. Hopefully that helps here.
It most DEFINITELY would, assuming it will perform at least acceptably
(not askin' for miracles, but YKWIM). Thanks muchly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:57 a.m.
On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas
<opensource(a)till.name> wrote:
> Which hardware is supported by ARMv7 hfp 32bit builds? Will
there be
http://fedoraproject.org/wiki/Architectures/ARM
The list is expanding regularly and there's a lot of other hardware
currently supported by remix primarily because the complete kernel
support isn't upstream.
So eventually Raspberry Pi and Cubieboard devices will be supported when
their kernel patches are upstreamed?
> test instances for maintainers as described here:
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...
I've never seen the above before.
Oh. I thought the ARM device was maintained in coordination with the ARM
SIG, but this has been cleared up in Kevin's mail.
Regards
Till
11:06 a.m.
On Wed, Jul 10, 2013 at 11:57 AM, Till Maas <opensource(a)till.name> wrote:
On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name> wrote:
> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
>
> http://fedoraproject.org/wiki/Architectures/ARM
>
> The list is expanding regularly and there's a lot of other hardware
> currently supported by remix primarily because the complete kernel
> support isn't upstream.
So eventually Raspberry Pi and Cubieboard devices will be supported when
their kernel patches are upstreamed?
Raspberry Pi is an ARMv6 device, so no. I have no idea about Cubieboard.
josh
1:21 p.m.
On Wed, Jul 10, 2013 at 5:06 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Wed, Jul 10, 2013 at 11:57 AM, Till Maas
<opensource(a)till.name> wrote:
> On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name> wrote:
>
>> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
>>
>> http://fedoraproject.org/wiki/Architectures/ARM
>>
>> The list is expanding regularly and there's a lot of other hardware
>> currently supported by remix primarily because the complete kernel
>> support isn't upstream.
>
> So eventually Raspberry Pi and Cubieboard devices will be supported when
> their kernel patches are upstreamed?
Raspberry Pi is an ARMv6 device, so no. I have no idea about Cubieboard.
Cubieboard is an Allwinner A10 device which is ARMv7 so will be
supported once it lands upstream. The core SoC support is there and
enabled but it's not much use without storage and various other bits.
Networking landed in mainline kernel yesterday for example.
Peter
11:44 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 10 Jul 2013 17:57:43 +0200
Till Maas <opensource(a)till.name> wrote:
On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas <opensource(a)till.name>
> wrote:
> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there
> > be
>
> http://fedoraproject.org/wiki/Architectures/ARM
>
> The list is expanding regularly and there's a lot of other hardware
> currently supported by remix primarily because the complete kernel
> support isn't upstream.
So eventually Raspberry Pi and Cubieboard devices will be supported
when their kernel patches are upstreamed?
Raspberry Pi will never be a supported device as its armv6, but
cubieboard yes. there is a cubieboard dtb in our kernel today but not
all support is upstream yet. but yes cubieboard will in time be
supported.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHdj2gACgkQkSxm47BaWfee3ACeNQfjp9FOVjCGbsxgoEHYR0tw
AWIAn0cVc1OqaWFbBWjfsaL2DGNAnvea
=eIi1
-----END PGP SIGNATURE-----
6:30 p.m.
On 2013-07-09 6:00, Jaroslav Reznik wrote:
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
The kernel is now a multi platform unified ARMv7 kernel supporting a
number of
SoCs with support expanding with each new upstream release. We build a
base
and LPAE variant similar to i686. There is an ARM specific (ARMv7 and
aarch64)
kernel maintainer working in collaboration with the Fedora kernel team.
The
releases are composed using the exact same tooling as used for the
primary
architectures. Disk images for development boards are generated by
appliance-
creator and the kickstarts live in spin-kickstarts, they take a similar
format
as the livecds on primary but are shipped as an OEM disk image, and
like
primary initial-setup is used to do final user configuration. Like
primary pungi
is used to generate an install tree, PXE install trees are created but
current
bootloaders don't support isofs so ISO images aren't currently created.
So, this raises a few questions: with ARM as a primary arch, exactly
what set of release images would we be supporting? Would we expect to
test each device-specific image at each release point and verify each
one of them was correct? Or would we just test a subset and 'trust' that
the others worked? Do 'we' as a project have access to all the necessary
hardware for testing each of the images?
(Personally, I have an XO 1.75 and a Trimslice lying around here
somewhere; I don't know what else anyone else has squirrelled away).
Someone later in the thread asked whether the 'ARM team' would be on the
hook for QAing the entire kaboodle. Technically with ARM as a primary
arch it would be QA's responsibility to ensure that whatever images we
considered part of the 'primary release' were of releasable quality, but
we are not miracle workers, and we cannot test what we don't have: so
we'd either need to buy a bunch of test devices or rely on people who
already have an interest in using ARM and some ARM devices - so, the ARM
team... - to act under the auspices of the 'QA team'.
I've had an entry on my todo list _forever_ to complete the
'deliverables SOP' I started several releases ago:
https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
(I don't really like the current layout, I was planning on revising it)
The addition of a new arch with quite a pile of 'supported images' would
certainly raise the priority of having such a thing. (We're already
hitting a problem with our *current* primary arches in this area,
though, in that the status of the multi-live, multi-arch and
cloud/appliance images is rather unclear).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:36 p.m.
Adam Williamson (awilliam(a)redhat.com) said:
I've had an entry on my todo list _forever_ to complete the
'deliverables SOP' I started several releases ago:
https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
(I don't really like the current layout, I was planning on revising it)
The addition of a new arch with quite a pile of 'supported images'
would certainly raise the priority of having such a thing. (We're
already hitting a problem with our *current* primary arches in this
area, though, in that the status of the multi-live, multi-arch and
cloud/appliance images is rather unclear).
Plus, in relation to this - the llvmpipe issue brings up that one of
the 'release blocking desktops' *does not work*. This would, by definition,
block the release unless we intend to have different criteria for ARM as a
primary arch.
Outside of that, how might we expect release criteria to change for ARM,
given the different deliverables that are planned?
Bill
11:28 p.m.
On 2013-07-09 17:36, Bill Nottingham wrote:
Adam Williamson (awilliam(a)redhat.com) said:
> I've had an entry on my todo list _forever_ to complete the
> 'deliverables SOP' I started several releases ago:
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>
> (I don't really like the current layout, I was planning on revising
> it)
>
> The addition of a new arch with quite a pile of 'supported images'
> would certainly raise the priority of having such a thing. (We're
> already hitting a problem with our *current* primary arches in this
> area, though, in that the status of the multi-live, multi-arch and
> cloud/appliance images is rather unclear).
Plus, in relation to this - the llvmpipe issue brings up that one of
the 'release blocking desktops' *does not work*. This would, by
definition,
block the release unless we intend to have different criteria for ARM
as a
primary arch.
Outside of that, how might we expect release criteria to change for
ARM,
given the different deliverables that are planned?
I've looked at that several times, and I don't really think the criteria
need to change much at all. The way they're currently worded covers ARM
pretty well, I think. We revised them quite extensively for F19 and I
tried to keep ARM in mind in the wording used there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:02 a.m.
----- Original Message -----
Adam Williamson (awilliam(a)redhat.com) said:
> I've had an entry on my todo list _forever_ to complete the
> 'deliverables SOP' I started several releases ago:
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>
> (I don't really like the current layout, I was planning on revising it)
>
> The addition of a new arch with quite a pile of 'supported images'
> would certainly raise the priority of having such a thing. (We're
> already hitting a problem with our *current* primary arches in this
> area, though, in that the status of the multi-live, multi-arch and
> cloud/appliance images is rather unclear).
Plus, in relation to this - the llvmpipe issue brings up that one of
the 'release blocking desktops' *does not work*. This would, by definition,
block the release unless we intend to have different criteria for ARM as a
primary arch.
I don't see a problem with different set of blocking desktops for ARM, even
as primary architecture. But it's really about resources - do we have people
willing to work for example on LXDE (I'd say more resources friendly for
current ARMs) - not saying there are no people, but more to support it as
blocking desktop, if QA would be able to validate three desktops on two
different platforms... And as we try to avoid "default" world in Fedora now,
let's have LXDE "default" in some cases.
For build times, Dennis has numbers prepared, we decided to let it out of
the proposal and send it for discussion.
Jaroslav
Outside of that, how might we expect release criteria to change for
ARM,
given the different deliverables that are planned?
Bill
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:45 a.m.
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
----- Original Message -----
> Adam Williamson (awilliam(a)redhat.com) said:
> > I've had an entry on my todo list _forever_ to complete the
> > 'deliverables SOP' I started several releases ago:
> >
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> >
> > (I don't really like the current layout, I was planning on revising it)
> >
> > The addition of a new arch with quite a pile of 'supported images'
> > would certainly raise the priority of having such a thing. (We're
> > already hitting a problem with our *current* primary arches in this
> > area, though, in that the status of the multi-live, multi-arch and
> > cloud/appliance images is rather unclear).
>
> Plus, in relation to this - the llvmpipe issue brings up that one of
> the 'release blocking desktops' *does not work*. This would, by definition,
> block the release unless we intend to have different criteria for ARM as a
> primary arch.
I don't see a problem with different set of blocking desktops for ARM, even
as primary architecture. But it's really about resources - do we have people
willing to work for example on LXDE (I'd say more resources friendly for
current ARMs) - not saying there are no people, but more to support it as
blocking desktop, if QA would be able to validate three desktops on two
different platforms... And as we try to avoid "default" world in Fedora now,
let's have LXDE "default" in some cases.
Is LXDE considered a release blocking desktop? I honestly don't know.
I also don't think it matters whether LXDE or FVMW2 or Gnome is the
default desktop on ARM. The criteria should probably be that it ships
with a desktop that is considered release blocking. If LXDE isn't
one, then perhaps it should be made so. The goal here shouldn't be
"we have a desktop". It should be "we have a desktop experience that
is the same on all primary architectures". To that end, whichever
desktop is picked should be release blocking and it should function
the same on all primary architectures.
For build times, Dennis has numbers prepared, we decided to let it
out of
the proposal and send it for discussion.
There was significant concern on this during the first time this came
up for discussion. I think the proposal should at least include a
link to the overall build time improvements. Clearly there has been
improvement, so make the proposal show that.
josh
7:28 a.m.
----- Original Message -----
From: "Josh Boyer" <jwboyer(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Wednesday, July 10, 2013 2:45:53 PM
Subject: Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
> ----- Original Message -----
>> Adam Williamson (awilliam(a)redhat.com) said:
>> > I've had an entry on my todo list _forever_ to complete the
>> > 'deliverables SOP' I started several releases ago:
>> >
>> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>> >
>> > (I don't really like the current layout, I was planning on revising
it)
>> >
>> > The addition of a new arch with quite a pile of 'supported images'
>> > would certainly raise the priority of having such a thing. (We're
>> > already hitting a problem with our *current* primary arches in this
>> > area, though, in that the status of the multi-live, multi-arch and
>> > cloud/appliance images is rather unclear).
>>
>> Plus, in relation to this - the llvmpipe issue brings up that one of
>> the 'release blocking desktops' *does not work*. This would, by
>> definition,
>> block the release unless we intend to have different criteria for ARM as a
>> primary arch.
>
> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have
> people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora
> now,
> let's have LXDE "default" in some cases.
Is LXDE considered a release blocking desktop? I honestly don't know.
I also don't think it matters whether LXDE or FVMW2 or Gnome is the
default desktop on ARM. The criteria should probably be that it ships
with a desktop that is considered release blocking. If LXDE isn't
one, then perhaps it should be made so. The goal here shouldn't be
"we have a desktop". It should be "we have a desktop experience that
is the same on all primary architectures". To that end, whichever
desktop is picked should be release blocking and it should function
the same on all primary architectures.
> For build times, Dennis has numbers prepared, we decided to let it out of
> the proposal and send it for discussion.
There was significant concern on this during the first time this came
up for discussion. I think the proposal should at least include a
link to the overall build time improvements. Clearly there has been
improvement, so make the proposal show that.
I still have serious concerns regarding build times:
* arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
* current primary - https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
This is still too huge gap - roughly 10 times slower. If ARM will become primary arch I
hope this is an exception and not the general rule.
Alexander Kurtakov
Red Hat Eclipse Team
josh
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:17 a.m.
On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
I still have serious concerns regarding build times:
* arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
* current primary - https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
This is still too huge gap - roughly 10 times slower. If ARM will become primary arch I
hope this is an exception and not the general rule.
FWIW, the last libreoffice arm build of
https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
approx 14 hours. While
https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
5 hours on x86
I can probably live with that without to much suffering, but it does
push build times from "start build today, get result today" to "start
build today, get results tomorrow".
C.
3:56 p.m.
On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> I still have serious concerns regarding build times:
> * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
> * current primary - https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h
30m
>
> This is still too huge gap - roughly 10 times slower. If ARM will become primary
arch I hope this is an exception and not the general rule.
FWIW, the last libreoffice arm build of
https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
approx 14 hours. While
https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
5 hours on x86
I can probably live with that without to much suffering, but it does
push build times from "start build today, get result today" to "start
build today, get results tomorrow".
Just a note that Koji is currently configured to time out builds after
24 hours.
Not that you'd want your builds taking longer than this, but it's may
affect the discussion ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
1:12 a.m.
----- Original Message -----
From: "Richard W.M. Jones" <rjones(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Wednesday, July 10, 2013 11:56:40 PM
Subject: Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > I still have serious concerns regarding build times:
> > * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > ~ 17h
> > * current primary -
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
> >
> > This is still too huge gap - roughly 10 times slower. If ARM will become
> > primary arch I hope this is an exception and not the general rule.
>
> FWIW, the last libreoffice arm build of
> https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
> approx 14 hours. While
> https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
> 5 hours on x86
>
> I can probably live with that without to much suffering, but it does
> push build times from "start build today, get result today" to
"start
> build today, get results tomorrow".
Just a note that Koji is currently configured to time out builds after
24 hours.
Not that you'd want your builds taking longer than this, but it's may
affect the discussion ...
I started a new f20 build to see how things will go on and Koji estimates it to around
20h.
See https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1974977 . What are the
possibilities for koji time out to be changed to 48h if/when arm becomes primary?
This would be highly needed to not have to resubmit builds because koji timed out cause it
hit slow builder. We have seen that few times when we tried to bootstrap secondary archs.
Alexander Kurtakov
Red Hat Eclipse team
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1:34 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 11 Jul 2013 02:12:03 -0400 (EDT)
Aleksandar Kurtakov <akurtako(a)redhat.com> wrote:
----- Original Message -----
> From: "Richard W.M. Jones" <rjones(a)redhat.com>
> To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org> Sent: Wednesday, July 10, 2013
> 11:56:40 PM Subject: Re: F20 System Wide Change: ARM as primary
> Architecture
>
> On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> > On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > > I still have serious concerns regarding build times:
> > > * arm -
> > > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > > ~ 17h
> > > * current primary -
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023
> > > ~1h 30m
> > >
> > > This is still too huge gap - roughly 10 times slower. If ARM
> > > will become primary arch I hope this is an exception and not
> > > the general rule.
> >
> > FWIW, the last libreoffice arm build of
> > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413,
> > took approx 14 hours. While
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took
> > approx 5 hours on x86
> >
> > I can probably live with that without to much suffering, but it
> > does push build times from "start build today, get result today"
> > to "start build today, get results tomorrow".
>
> Just a note that Koji is currently configured to time out builds
> after 24 hours.
>
> Not that you'd want your builds taking longer than this, but it's
> may affect the discussion ...
I started a new f20 build to see how things will go on and Koji
estimates it to around 20h. See
https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1974977 .
What are the possibilities for koji time out to be changed to 48h
if/when arm becomes primary? This would be highly needed to not have
to resubmit builds because koji timed out cause it hit slow builder.
We have seen that few times when we tried to bootstrap secondary
archs.
It is a viable option to give us some room just incase.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHeUfEACgkQkSxm47BaWfeOhACfbTvB/um7Vipr1TSWH/oP8AGY
wkMAoK/Y5SeqnYAB7q4arf0yg/3QvUiG
=Ywqd
-----END PGP SIGNATURE-----
1:22 a.m.
On Wed, 10 Jul 2013 21:56:40 +0100
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > I still have serious concerns regarding build times:
> > * arm -
> > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > ~ 17h
> > * current primary -
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h
> > 30m
> >
> > This is still too huge gap - roughly 10 times slower. If ARM will
> > become primary arch I hope this is an exception and not the
> > general rule.
>
> FWIW, the last libreoffice arm build of
> https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413,
> took approx 14 hours. While
> https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took
> approx 5 hours on x86
>
> I can probably live with that without to much suffering, but it does
> push build times from "start build today, get result today" to
> "start build today, get results tomorrow".
Just a note that Koji is currently configured to time out builds after
24 hours.
the timeout is currently hard-coded in the koji sources, but patch
exists to make it configurable, I should ping upstream about it as not
only ARM fights with long build times
Dan
Not that you'd want your builds taking longer than this, but
it's may
affect the discussion ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones Fedora Windows cross-compiler.
Compile Windows programs, test, and build Windows installers. Over
100 libraries supported. http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:28 a.m.
New subject: arm build times
So, wondering...
a) What is the fastest available arm hardware that works today with
fedora ?
b) The fedora builders are currently just one arm per build, right ? Any
benefit to throwing distcc/icecream at the problem ? Wouldn't help the
java builds, but would likely help e.g. the LibreOffice ones which
should be very parallelizable.
C.
7:09 a.m.
New subject: arm build times
On Thu, Jul 11, 2013 at 12:28 PM, Caolán McNamara <caolanm(a)redhat.com> wrote:
So, wondering...
a) What is the fastest available arm hardware that works today with
fedora ?
At the moment the build hardware we have is Calxeda quad core A9 with
4Gb of RAM and a local HDD.
b) The fedora builders are currently just one arm per build, right ?
Any
benefit to throwing distcc/icecream at the problem ? Wouldn't help the
java builds, but would likely help e.g. the LibreOffice ones which
should be very parallelizable.
That would require support in koji/mock and a change in policy on the
way Fedora builds packages so is currently out of scope for the
proposal.
Peter
1:17 p.m.
On Wed, Jul 10, 2013 at 1:28 PM, Aleksandar Kurtakov
<akurtako(a)redhat.com> wrote:
----- Original Message -----
> From: "Josh Boyer" <jwboyer(a)gmail.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Sent: Wednesday, July 10, 2013 2:45:53 PM
> Subject: Re: F20 System Wide Change: ARM as primary Architecture
>
> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
> > ----- Original Message -----
> >> Adam Williamson (awilliam(a)redhat.com) said:
> >> > I've had an entry on my todo list _forever_ to complete the
> >> > 'deliverables SOP' I started several releases ago:
> >> >
> >> >
https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> >> >
> >> > (I don't really like the current layout, I was planning on revising
it)
> >> >
> >> > The addition of a new arch with quite a pile of 'supported
images'
> >> > would certainly raise the priority of having such a thing. (We're
> >> > already hitting a problem with our *current* primary arches in this
> >> > area, though, in that the status of the multi-live, multi-arch and
> >> > cloud/appliance images is rather unclear).
> >>
> >> Plus, in relation to this - the llvmpipe issue brings up that one of
> >> the 'release blocking desktops' *does not work*. This would, by
> >> definition,
> >> block the release unless we intend to have different criteria for ARM as a
> >> primary arch.
> >
> > I don't see a problem with different set of blocking desktops for ARM, even
> > as primary architecture. But it's really about resources - do we have
> > people
> > willing to work for example on LXDE (I'd say more resources friendly for
> > current ARMs) - not saying there are no people, but more to support it as
> > blocking desktop, if QA would be able to validate three desktops on two
> > different platforms... And as we try to avoid "default" world in
Fedora
> > now,
> > let's have LXDE "default" in some cases.
>
> Is LXDE considered a release blocking desktop? I honestly don't know.
> I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> default desktop on ARM. The criteria should probably be that it ships
> with a desktop that is considered release blocking. If LXDE isn't
> one, then perhaps it should be made so. The goal here shouldn't be
> "we have a desktop". It should be "we have a desktop experience that
> is the same on all primary architectures". To that end, whichever
> desktop is picked should be release blocking and it should function
> the same on all primary architectures.
>
> > For build times, Dennis has numbers prepared, we decided to let it out of
> > the proposal and send it for discussion.
>
> There was significant concern on this during the first time this came
> up for discussion. I think the proposal should at least include a
> link to the overall build time improvements. Clearly there has been
> improvement, so make the proposal show that.
I still have serious concerns regarding build times:
* arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
* current primary - https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
This is still too huge gap - roughly 10 times slower. If ARM will become primary arch I
hope this is an exception and not the general rule.
That build gap is due to java not being the fully accelerated one, I
know there's work being done there but it's been a while since I heard
the latest state, the last of which was "soon"
Peter
2:06 p.m.
----- Original Message -----
From: "Peter Robinson" <pbrobinson(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Wednesday, July 10, 2013 9:17:49 PM
Subject: Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 10, 2013 at 1:28 PM, Aleksandar Kurtakov
<akurtako(a)redhat.com> wrote:
> ----- Original Message -----
>> From: "Josh Boyer" <jwboyer(a)gmail.com>
>> To: "Development discussions related to Fedora"
>> <devel(a)lists.fedoraproject.org>
>> Sent: Wednesday, July 10, 2013 2:45:53 PM
>> Subject: Re: F20 System Wide Change: ARM as primary Architecture
>>
>> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik <jreznik(a)redhat.com>
>> wrote:
>> > ----- Original Message -----
>> >> Adam Williamson (awilliam(a)redhat.com) said:
>> >> > I've had an entry on my todo list _forever_ to complete the
>> >> > 'deliverables SOP' I started several releases ago:
>> >> >
>> >> >
https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>> >> >
>> >> > (I don't really like the current layout, I was planning on
revising
>> >> > it)
>> >> >
>> >> > The addition of a new arch with quite a pile of 'supported
images'
>> >> > would certainly raise the priority of having such a thing.
(We're
>> >> > already hitting a problem with our *current* primary arches in
this
>> >> > area, though, in that the status of the multi-live, multi-arch
and
>> >> > cloud/appliance images is rather unclear).
>> >>
>> >> Plus, in relation to this - the llvmpipe issue brings up that one of
>> >> the 'release blocking desktops' *does not work*. This would,
by
>> >> definition,
>> >> block the release unless we intend to have different criteria for ARM
>> >> as a
>> >> primary arch.
>> >
>> > I don't see a problem with different set of blocking desktops for ARM,
>> > even
>> > as primary architecture. But it's really about resources - do we have
>> > people
>> > willing to work for example on LXDE (I'd say more resources friendly
for
>> > current ARMs) - not saying there are no people, but more to support it
>> > as
>> > blocking desktop, if QA would be able to validate three desktops on two
>> > different platforms... And as we try to avoid "default" world in
Fedora
>> > now,
>> > let's have LXDE "default" in some cases.
>>
>> Is LXDE considered a release blocking desktop? I honestly don't know.
>> I also don't think it matters whether LXDE or FVMW2 or Gnome is the
>> default desktop on ARM. The criteria should probably be that it ships
>> with a desktop that is considered release blocking. If LXDE isn't
>> one, then perhaps it should be made so. The goal here shouldn't be
>> "we have a desktop". It should be "we have a desktop experience
that
>> is the same on all primary architectures". To that end, whichever
>> desktop is picked should be release blocking and it should function
>> the same on all primary architectures.
>>
>> > For build times, Dennis has numbers prepared, we decided to let it out
>> > of
>> > the proposal and send it for discussion.
>>
>> There was significant concern on this during the first time this came
>> up for discussion. I think the proposal should at least include a
>> link to the overall build time improvements. Clearly there has been
>> improvement, so make the proposal show that.
>
> I still have serious concerns regarding build times:
> * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~
> 17h
> * current primary -
> https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
>
> This is still too huge gap - roughly 10 times slower. If ARM will become
> primary arch I hope this is an exception and not the general rule.
That build gap is due to java not being the fully accelerated one, I
know there's work being done there but it's been a while since I heard
the latest state, the last of which was "soon"
Yeah, I know the reasons but still this would make it really hard for us to push changes
or test a build fix. I would like all archs to have equal attention but not at the price
of others.
I still have bad memories from ppc building eclipse for similar time and thus causing huge
delays. We usually update most of the Eclipse packages simultaneously (build order
matters) as they are released on the same date if builds are gonna take that will be big
hurdle for us.
3-4 times slower is acceptable but more than that becomes a problem.
Alexander Kurtakov
Red Hat Eclipse Team
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2:11 p.m.
On Wed, 10 Jul 2013 15:06:50 -0400 (EDT)
Aleksandar Kurtakov <akurtako(a)redhat.com> wrote:
Yeah, I know the reasons but still this would make it really hard
for
us to push changes or test a build fix. I would like all archs to
have equal attention but not at the price of others. I still have bad
memories from ppc building eclipse for similar time and thus causing
huge delays. We usually update most of the Eclipse packages
simultaneously (build order matters) as they are released on the same
date if builds are gonna take that will be big hurdle for us. 3-4
times slower is acceptable but more than that becomes a problem.
Interested folks can go look at:
http://arm.koji.fedoraproject.org/
and find packages they care about (please look at f19 or rawhide
builds, as f17/f18 ones also build for armv5tel and will take a lot
longer to build).
We did experiment with SSD disk in the ARM SOC's, but that didn't seem
to help very much at all (ie, the build is mostly cpu bound, not i/o).
Arm builders are also currently Fedora 18. Moving to F19 might help,
not sure.
kevin
11:09 a.m.
On Wed, Jul 10, 2013 at 07:45:53AM -0400, Josh Boyer wrote:
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
>
> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora
now,
> let's have LXDE "default" in some cases.
Is LXDE considered a release blocking desktop? I honestly don't know.
I also don't think it matters whether LXDE or FVMW2 or Gnome is the
default desktop on ARM. The criteria should probably be that it ships
with a desktop that is considered release blocking. If LXDE isn't
one, then perhaps it should be made so. The goal here shouldn't be
"we have a desktop". It should be "we have a desktop experience that
is the same on all primary architectures". To that end, whichever
desktop is picked should be release blocking and it should function
the same on all primary architectures.
There's sort of a more central issue here that's causing this question -
while the release criteria certainly are meant to be a way of evaluating
if the release is complete and functional, there's some creep in of how
we use them because of how they were developed. Specifically, what
they're implicitly testing is whether we've unexpectedly lost functionality
(or quality) from the previous release. Obviously that's not quite the
metric in which we'll be evaluating arm as a PA.
That doesn't mean that the release criteria as they stand aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.
It's two different things, and it's important that we not confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be. The question is "is the infrastructure for normal
desktops to work required to be a PA".
And I think right now, the assumption from outside the ARM team has been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.
--
Peter
12:28 p.m.
On 07/10/2013 04:09 PM, Peter Jones wrote:
That doesn't mean that the release criteria as they stand
aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.
Right
It's two different things, and it's important that we not confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be. The question is "is the infrastructure for normal
desktops to work required to be a PA".
I would think that each sub community
like for example Gnome would be
the ones ultimately responsible for setting/creating their own release
criteria surrounding Gnome, testing it and arguable also be the ones who
decide which primary architectures it would be released on based on
their ( sub-community ) release cycle while KDE for example would have
completely another release cycle aligned to it's upstream.
But as things stand now neither our infrastructure,releng,qa and general
procedures allow for such flexibility and adoption by sub-communities (
but should be something for us to work towards to ).
so for PA to become primary I would think the only requirement would be
does our components build correctly for that architecture not necessary
work ( with the exception of the base/core OS ) since it would be up to
the sub-communities to ensure the releases on the PA which they intend
to release on meets their criteria and works at release time.
And I think right now, the assumption from outside the ARM team has
been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.
I would think so as well.
JBG
4:40 p.m.
On Wed, 2013-07-10 at 12:09 -0400, Peter Jones wrote:
> Is LXDE considered a release blocking desktop? I honestly
don't know.
> I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> default desktop on ARM. The criteria should probably be that it ships
> with a desktop that is considered release blocking. If LXDE isn't
> one, then perhaps it should be made so. The goal here shouldn't be
> "we have a desktop". It should be "we have a desktop experience
that
> is the same on all primary architectures". To that end, whichever
> desktop is picked should be release blocking and it should function
> the same on all primary architectures.
There's sort of a more central issue here that's causing this question -
while the release criteria certainly are meant to be a way of evaluating
if the release is complete and functional, there's some creep in of how
we use them because of how they were developed. Specifically, what
they're implicitly testing is whether we've unexpectedly lost functionality
(or quality) from the previous release. Obviously that's not quite the
metric in which we'll be evaluating arm as a PA.
I'm honestly not entirely sure what you mean by this. Could you explain
it again using short, monkey-friendly words? :)
When writing new criteria, or when doing the major re-write we did for
F19, the approach we take (or at least the one I take, for sure) is
simply to try and identify an attribute a Fedora milestone must have to
make it fit for purpose, and codify that in text. That's really it. The
concept of "whether we've unexpectedly lost functionality from the
previous release" is not one that I consciously, at least, hold in mind
when working on the criteria.
That doesn't mean that the release criteria as they stand
aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.
It's two different things, and it's important that we not
confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be. The question is "is the infrastructure for normal
desktops to work required to be a PA".
I certainly concur with this. The question we should be answering is
simply 'do we consider ARM to be worthy of being a PA yet?', and the
release criteria are not intended as a tool to help answer that
question. Rather, if the answer to that question is 'yes' but the
release criteria are not in line with a world in which ARM is a PA, we
should amend the release criteria. They are certainly not set in stone.
And I think right now, the assumption from outside the ARM team has
been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.
--
Peter
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:25 p.m.
On Wed, 2013-07-10 at 07:45 -0400, Josh Boyer wrote:
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
> ----- Original Message -----
>> Adam Williamson (awilliam(a)redhat.com) said:
>> > I've had an entry on my todo list _forever_ to complete the
>> > 'deliverables SOP' I started several releases ago:
>> >
>> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>> >
>> > (I don't really like the current layout, I was planning on revising
it)
>> >
>> > The addition of a new arch with quite a pile of 'supported images'
>> > would certainly raise the priority of having such a thing. (We're
>> > already hitting a problem with our *current* primary arches in this
>> > area, though, in that the status of the multi-live, multi-arch and
>> > cloud/appliance images is rather unclear).
>>
>> Plus, in relation to this - the llvmpipe issue brings up that one of
>> the 'release blocking desktops' *does not work*. This would, by
definition,
>> block the release unless we intend to have different criteria for ARM as a
>> primary arch.
>
> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora
now,
> let's have LXDE "default" in some cases.
Is LXDE considered a release blocking desktop? I honestly don't know.
No. The release blocking desktops are KDE and GNOME. This is stated in
the preamble of all release criteria pages, for lack of anywhere better
to state it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:08 p.m.
On 07/10/2013 02:25 PM, Adam Williamson wrote:
No. The release blocking desktops are KDE and GNOME. This is stated
in
the preamble of all release criteria pages, for lack of anywhere better
to state it.
If we were only proposing headless ARM servers for primary how would
these criteria apply? The changes to the build system would be the same
with our without these desktops in either case. Note I'm not asking
Adam specifically; it's a question for the room.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:12 p.m.
On Jul 10, 2013 6:08 PM, "Brendan Conoboy" <blc(a)redhat.com> wrote:
I was thinking the same thing earlier. I think Adamw and
jreznik would
both say that we should modify the release criteria for that. I think mjg
is more of the opinion that the fedora distribution means that certain
things including the default desktop are available and that a different
target, like headless servers, should be a spin. I believe that he's left
open the option to rethink how spins and primary arch overlap so that arm
with a headless server spin could be primary but not called fedora.
I think I agree with mjg that we should divorce pa status from the
particular fedora spins that can be made from them. I don't think I agree
as much that the packageset of a particular spin is what defines what
deserves the fedora name: I wouldn't have a problem with an arm packageset
that couldn't support the default desktop.
There probably is a minimal packageset, though. the kernel, glibc, gcc,
and rpm would all be on my list. Given that fesco has a policy about the
package depsolver having to be the same on all spins, probably the current
depdolving package manager as well. Default init system and bash are also
likely although someone might be able to make a case for alternatives to
the defaults being okay... with emphasis on "might".
Getting back to the release criteria; if we are moving towards a model
where a headless server spin was fine as the only product for an arch I
think we'd need to start looking at release criteria being applied more
purely to spins. This might require big changes to how we think about
validating a release.
-Toshio
On 07/10/2013 02:25 PM, Adam Williamson wrote:
> No. The release blocking desktops are KDE and GNOME. This
is stated in
> the preamble of all release criteria pages, for lack of anywhere better
> to state it.
If we were only proposing headless ARM servers for primary how would
these criteria
apply? The changes to the build system would be the same
with our without these desktops in either case. Note I'm not asking Adam
specifically; it's a question for the room.
12:17 a.m.
On Wed, 2013-07-10 at 20:12 -0700, Toshio Kuratomi wrote:
On Jul 10, 2013 6:08 PM, "Brendan Conoboy" <blc(a)redhat.com> wrote:
>
> On 07/10/2013 02:25 PM, Adam Williamson wrote:
>>
>> No. The release blocking desktops are KDE and GNOME. This is stated
in
>> the preamble of all release criteria pages, for lack of anywhere
better
>> to state it.
>
>
> If we were only proposing headless ARM servers for primary how would
these criteria apply? The changes to the build system would be the
same with our without these desktops in either case. Note I'm not
asking Adam specifically; it's a question for the room.
>
I was thinking the same thing earlier. I think Adamw and jreznik
would both say that we should modify the release criteria for that. I
think mjg is more of the opinion that the fedora distribution means
that certain things including the default desktop are available and
that a different target, like headless servers, should be a spin. I
believe that he's left open the option to rethink how spins and
primary arch overlap so that arm with a headless server spin could be
primary but not called fedora.
I'm not actually advocating either course of action.
What I'm saying is that the release criteria are a thing that tries to
codify what we, as a community, decide we want 'Fedora' to be: the
correct process is that we make that decision, then we ensure the
release criteria reflect it.
My position is that 'we', as in Fedora, should decide whether we want
ARM as a primary arch, with whatever caveats are being produced as a
part of this discussion. If we wind up deciding that ARM should be a
primary arch but we don't require it to have a working GNOME desktop, or
whatever, then that's a perfectly valid decision, and we would then
adjust the release criteria and validation process to reflect that.
It would also be a perfectly valid decision to say 'no, all primary
arches should support a certain core feature set, and GNOME is part of
that'. I'm not specifically advocating for either of those decisions;
just saying that "the release criteria as they currently stand say X, so
ARM must do X" is not a good approach.
Getting back to the release criteria; if we are moving towards a
model
where a headless server spin was fine as the only product for an arch
I think we'd need to start looking at release criteria being applied
more purely to spins. This might require big changes to how we think
about validating a release.
So, that's kinda what Johann's suggesting. As I said, on a purely
'intellectual' level I like the model, but in practice, there is still a
substantial faction out there for which "Fedora" is the GNOME live image
or the default DVD install. I'm always up for process improvements, but
I think on a practical level, whatever we come up with is going to have
to ensure that those things work, as it currently does.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:36 a.m.
On Wed, Jul 10, 2013 at 08:12:42PM -0700, Toshio Kuratomi wrote:
There probably is a minimal packageset, though. the kernel, glibc,
gcc,
and rpm would all be on my list. Given that fesco has a policy about the
package depsolver having to be the same on all spins, probably the current
depdolving package manager as well. Default init system and bash are also
likely although someone might be able to make a case for alternatives to
the defaults being okay... with emphasis on "might".
Paging mitr and the "Fedora Base Design"!
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:29 a.m.
On Thu, Jul 11, 2013 at 6:36 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Wed, Jul 10, 2013 at 08:12:42PM -0700, Toshio Kuratomi wrote:
> There probably is a minimal packageset, though. the kernel, glibc, gcc,
> and rpm would all be on my list. Given that fesco has a policy about the
> package depsolver having to be the same on all spins, probably the current
> depdolving package manager as well. Default init system and bash are also
> likely although someone might be able to make a case for alternatives to
> the defaults being okay... with emphasis on "might".
Paging mitr and the "Fedora Base Design"!
The base design component the revamp proposal from FUDCon Lawrence
focused on better change coordination for the "base"; I don't think it
implied that the "base" part should be shipped, or even necessarily
useful, stand-alone.
There are other proposals being worked on by other people that go in
that direction, though :)
Mirek
11:13 p.m.
On Wed, Jul 10, 2013 at 06:08:33PM -0700, Brendan Conoboy wrote:
On 07/10/2013 02:25 PM, Adam Williamson wrote:
>No. The release blocking desktops are KDE and GNOME. This is stated in
>the preamble of all release criteria pages, for lack of anywhere better
>to state it.
If we were only proposing headless ARM servers for primary how would
these criteria apply? The changes to the build system would be the
same with our without these desktops in either case. Note I'm not
asking Adam specifically; it's a question for the room.
Fedora is an operating system that supports a range of desktop
environments, defaulting to the GNOME desktop environment. An OS that
supports headless servers but not desktop environments might be based on
Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
being a Fedora PA.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:04 a.m.
On 07/10/2013 09:13 PM, Matthew Garrett wrote:
Fedora is an operating system that supports a range of desktop
environments, defaulting to the GNOME desktop environment. An OS that
supports headless servers but not desktop environments might be based on
Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
being a Fedora PA.
It is becoming increasingly difficult to distinguish whether to read
these messages as high standards or hyperbole. Maybe your Fedora means
desktop OS, but my Fedora has more facets than that. Fedora Primary is
not some Platonic Form embodied by x86; that would be better described
as Fedora Fantasy.
The all or nothing element in the above simply serves to discourage
further contribution and is harming Fedora's growth. The relentless "I
don't want ARM to sully the good name of Fedora" is absurd: User for
user, ARM is considerably more popular than Fedora. Is your definition
of "Primary" a sacred idea that is responsible for Fedora's success? If
held dear for too long it will be the well known idea responsible for
its failure.
Please consider the idea that there is a useful middle ground "Primary"
and "Secondary".
Primary Release/Primary Build system
|
Primary Build system/Secondary Release
|
Secondary Build system/Secondary Release
It might be multidimensional:
Primary Desktop---Secondary Desktop
| |
Primary Server----Secondary Server
15 months ago:
There were concerns about reliability- we moved to enterprise hardware
in PHX.
There were concerns about build times, particularly that of the kernel:
We bought the fastest hardware available, moved to a unified kernel
architecture and sped up builds many-fold.
There were concerns about kernel and toolchain maintainship: We hired
and/or tasked kernel, glibc, gcc, and other engineers.
There were concerns about releases being held up: We released F19 Beta
and GA on the same day as x86.
There were concerns about releng: Releng wrote the new promotion proposal.
There were concerns about QA&Release criteria: We copied most of
Primary's procedures.
There were concerns about the installer: We're using anaconda and
standard image creation tooling.
There were concerns about desktop users: All supported platforms that
have graphical hardware have a desktop.
The list goes on and on. For any of the above a person can be small and
pick out tiny details where they aren't satisfied, but if you're one of
the people who is going to do that, please say the following:
"I object to armv7hl moving to primary because of $DEFECT, but if
$DEFECT is remedied by $MILESTONE, I will then support the move of
armv7hl to primary". You define $DEFECT and $MILESTONE and we can have
a productive discussion.
At this time I think it is quite reasonable to ask for the build systems
to be merged. Whether you call it Primary, Secondary, or some new
middle-of-the-ground word, it's progress.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:57 a.m.
Thanks Brendan. My Fedora doesn't even use a GNOME desktop. I've happily used XFCE
for years. And I make no secret that I care about servers more than desktops (you know,
that part of the market where general purpose Linux has a huge footprint and stands a
chance). I would hate to look back in five years and say "yea, Hyperscale ARM servers
took over and Red Hat was totally there, but Fedora missed the boat entirely". Move
with the times. Fedora wants to embrace the new and revolutionary? ARM is powering some
very exciting disruption and Fedora should not be sitting on the sidelines naval gazing
and pining for the declining desktop of yesteryear.
--
Sent from my iPad
On Jul 11, 2013, at 7:05, Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/10/2013 09:13 PM, Matthew Garrett wrote:
> Fedora is an operating system that supports a range of desktop
> environments, defaulting to the GNOME desktop environment. An OS that
> supports headless servers but not desktop environments might be based on
> Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
> being a Fedora PA.
It is becoming increasingly difficult to distinguish whether to read these messages as
high standards or hyperbole. Maybe your Fedora means desktop OS, but my Fedora has more
facets than that. Fedora Primary is not some Platonic Form embodied by x86; that would be
better described as Fedora Fantasy.
The all or nothing element in the above simply serves to discourage further contribution
and is harming Fedora's growth. The relentless "I don't want ARM to sully
the good name of Fedora" is absurd: User for user, ARM is considerably more popular
than Fedora. Is your definition of "Primary" a sacred idea that is responsible
for Fedora's success? If held dear for too long it will be the well known idea
responsible for its failure.
Please consider the idea that there is a useful middle ground "Primary" and
"Secondary".
Primary Release/Primary Build system
|
Primary Build system/Secondary Release
|
Secondary Build system/Secondary Release
It might be multidimensional:
Primary Desktop---Secondary Desktop
| |
Primary Server----Secondary Server
15 months ago:
There were concerns about reliability- we moved to enterprise hardware in PHX.
There were concerns about build times, particularly that of the kernel: We bought the
fastest hardware available, moved to a unified kernel architecture and sped up builds
many-fold.
There were concerns about kernel and toolchain maintainship: We hired and/or tasked
kernel, glibc, gcc, and other engineers.
There were concerns about releases being held up: We released F19 Beta and GA on the same
day as x86.
There were concerns about releng: Releng wrote the new promotion proposal.
There were concerns about QA&Release criteria: We copied most of Primary's
procedures.
There were concerns about the installer: We're using anaconda and standard image
creation tooling.
There were concerns about desktop users: All supported platforms that have graphical
hardware have a desktop.
The list goes on and on. For any of the above a person can be small and pick out tiny
details where they aren't satisfied, but if you're one of the people who is going
to do that, please say the following:
"I object to armv7hl moving to primary because of $DEFECT, but if $DEFECT is
remedied by $MILESTONE, I will then support the move of armv7hl to primary". You
define $DEFECT and $MILESTONE and we can have a productive discussion.
At this time I think it is quite reasonable to ask for the build systems to be merged.
Whether you call it Primary, Secondary, or some new middle-of-the-ground word, it's
progress.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:55 a.m.
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/10/2013 09:13 PM, Matthew Garrett wrote:
>
> Fedora is an operating system that supports a range of desktop
> environments, defaulting to the GNOME desktop environment. An OS that
> supports headless servers but not desktop environments might be based on
> Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
> being a Fedora PA.
It is becoming increasingly difficult to distinguish whether to read these
messages as high standards or hyperbole. Maybe your Fedora means desktop
OS, but my Fedora has more facets than that. Fedora Primary is not some
Platonic Form embodied by x86; that would be better described as Fedora
Fantasy.
I will note that it is not x86 alone. If one is simply going by "as
close to the current Fedora experience the current Primary offers",
then the PowerPC secondary arch team is actually ahead of ARM. I'm
not saying they are a better candidate, but I am pointing out that the
criteria Matthew is alluding to is being met by non-x86 architectures.
The all or nothing element in the above simply serves to discourage
further
contribution and is harming Fedora's growth. The relentless "I don't want
I don't believe that is true. ARM is useful, I want it to be a
Primary arch, but I fail to see how your middle ground below of having
it be primary in the build system is going to somehow grow Fedora. I
believe there are concerns that it will place additional burden on
package maintainers (like ppc did before there was a real arch team
for it), and that those concerns are valid.
There were concerns about reliability- we moved to enterprise
hardware in
PHX.
There were concerns about build times, particularly that of the kernel: We
bought the fastest hardware available, moved to a unified kernel
architecture and sped up builds many-fold.
And yet did not include any of that information in your proposal. I
believe build times have improved. I also believe that you should
show it in the proposal so that it is clear you are addressing prior
concerns. I'm appreciate the effort spent to speed up the kernel
build times, but the concern is global. Show the work done in the
proposal with some simple numbers.
Again, I would like to see ARM as Primary and I believe the ARM team
has done a rather good job. Promoting anything to Primary has never
been done before, so bear with us as we work through it.
josh
6:11 a.m.
On Thu, Jul 11, 2013 at 6:55 AM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy
<blc(a)redhat.com> wrote:
> The all or nothing element in the above simply serves to discourage further
> contribution and is harming Fedora's growth. The relentless "I don't
want
I don't believe that is true. ARM is useful, I want it to be a
Primary arch, but I fail to see how your middle ground below of having
it be primary in the build system is going to somehow grow Fedora. I
believe there are concerns that it will place additional burden on
package maintainers (like ppc did before there was a real arch team
for it), and that those concerns are valid.
To expand on this a bit, how do you believe that merging ARM into the
build system is going to encourage growth in Fedora? What will it buy
you that you don't already have? At first glance, it gets you
slightly more timely builds. However, you've already proven that
timely builds isn't an issue at all by having ARM releases ready the
same day as primary. So please, elaborate on that in the proposal.
You have a lot of what you want listed, but not why.
josh
12:43 p.m.
On 07/11/2013 04:11 AM, Josh Boyer wrote:
To expand on this a bit, how do you believe that merging ARM into
the
build system is going to encourage growth in Fedora? What will it buy
you that you don't already have? At first glance, it gets you
slightly more timely builds. However, you've already proven that
timely builds isn't an issue at all by having ARM releases ready the
same day as primary. So please, elaborate on that in the proposal.
You have a lot of what you want listed, but not why.
Speaking just for the build system change, I see these benefits (There
may be others, I don't run the build system):
1. Running koji-shadow is often a full-time job. The person doing the
job could be working on ARM issues directly instead of being a build nanny.
2. Koji-shadow can introduce SA rpms who have a different NVR
dependencies than PA. There are numerous koji-shadow issues, really.
3. Build failures on ARM aren't always ARM specific- it can serve as a
notice of problems present but not yet observed on other architectures,
perhaps hidden by accidental alignment, etc.
4. Failures like those in #4 benefit all secondaries, not just ARM.
Solve it in PA, or we end up solving it once in ARM, once in Power, once
in s390... it's a lot of wasted, redundant effort.
5. Primary packagers are already fixing ARM build failures, they're just
doing it a day or a week later. They don't know there is an issue until
we tell them. 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.
etc.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
6:41 a.m.
On Thu, Jul 11, 2013 at 11:55 AM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy
<blc(a)redhat.com> wrote:
> On 07/10/2013 09:13 PM, Matthew Garrett wrote:
>>
>> Fedora is an operating system that supports a range of desktop
>> environments, defaulting to the GNOME desktop environment. An OS that
>> supports headless servers but not desktop environments might be based on
>> Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
>> being a Fedora PA.
>
>
> It is becoming increasingly difficult to distinguish whether to read these
> messages as high standards or hyperbole. Maybe your Fedora means desktop
> OS, but my Fedora has more facets than that. Fedora Primary is not some
> Platonic Form embodied by x86; that would be better described as Fedora
> Fantasy.
I will note that it is not x86 alone. If one is simply going by "as
close to the current Fedora experience the current Primary offers",
then the PowerPC secondary arch team is actually ahead of ARM. I'm
not saying they are a better candidate, but I am pointing out that the
criteria Matthew is alluding to is being met by non-x86 architectures.
Ahead in what metrics? In terms of packages built ARM is ahead, in
terms of kernel I don't believe it's easy to compare as ARM has a much
wider range of HW available from multiple vendors. In terms of
features like HW virt that's possibly true (but there's other features
that I'm not sure are even possible with PPC that ARM does) and in
terms of maturity of support it's most definitely true that PPC is
ahead.
Comparing f-19 packages (and I am very aware it's but one metric):
ARM statistics: {'older': 18, 'local_only': 4, 'remote_only':
233,
'same': 13355, 'newer': 0, 'total_missing_builds': 18}
PPC statistics: {'older': 49, 'local_only': 8, 'remote_only':
293,
'same': 13259, 'newer': 5, 'total_missing_builds': 49}
s390 statistics: {'older': 15, 'local_only': 3, 'remote_only':
741,
'same': 12850, 'newer': 0, 'total_missing_builds': 15}
> The all or nothing element in the above simply serves to
discourage further
> contribution and is harming Fedora's growth. The relentless "I don't
want
I don't believe that is true. ARM is useful, I want it to be a
Primary arch, but I fail to see how your middle ground below of having
it be primary in the build system is going to somehow grow Fedora. I
believe there are concerns that it will place additional burden on
package maintainers (like ppc did before there was a real arch team
for it), and that those concerns are valid.
> There were concerns about reliability- we moved to enterprise hardware in
> PHX.
>
> There were concerns about build times, particularly that of the kernel: We
> bought the fastest hardware available, moved to a unified kernel
> architecture and sped up builds many-fold.
And yet did not include any of that information in your proposal. I
believe build times have improved. I also believe that you should
show it in the proposal so that it is clear you are addressing prior
concerns. I'm appreciate the effort spent to speed up the kernel
build times, but the concern is global. Show the work done in the
proposal with some simple numbers.
I don't believe it should be included in the proposal, in supporting
docs yes but the proposal is an overview not a justification doc.
Again, I would like to see ARM as Primary and I believe the ARM team
has done a rather good job. Promoting anything to Primary has never
been done before, so bear with us as we work through it.
Which is exactly why we bought it up a year ago have been actively
working through all the issues and why a year ago we asked for
promotion guidelines as opposed to actually proposing it. We're well
aware of that.
Peter
7:08 a.m.
On Thu, Jul 11, 2013 at 7:41 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 11:55 AM, Josh Boyer
<jwboyer(a)gmail.com> wrote:
> On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy <blc(a)redhat.com> wrote:
>> On 07/10/2013 09:13 PM, Matthew Garrett wrote:
>>>
>>> Fedora is an operating system that supports a range of desktop
>>> environments, defaulting to the GNOME desktop environment. An OS that
>>> supports headless servers but not desktop environments might be based on
>>> Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
>>> being a Fedora PA.
>>
>>
>> It is becoming increasingly difficult to distinguish whether to read these
>> messages as high standards or hyperbole. Maybe your Fedora means desktop
>> OS, but my Fedora has more facets than that. Fedora Primary is not some
>> Platonic Form embodied by x86; that would be better described as Fedora
>> Fantasy.
>
> I will note that it is not x86 alone. If one is simply going by "as
> close to the current Fedora experience the current Primary offers",
> then the PowerPC secondary arch team is actually ahead of ARM. I'm
> not saying they are a better candidate, but I am pointing out that the
> criteria Matthew is alluding to is being met by non-x86 architectures.
Ahead in what metrics? In terms of packages built ARM is ahead, in
terms of kernel I don't believe it's easy to compare as ARM has a much
wider range of HW available from multiple vendors. In terms of
features like HW virt that's possibly true (but there's other features
that I'm not sure are even possible with PPC that ARM does) and in
terms of maturity of support it's most definitely true that PPC is
ahead.
In terms of Fedora experience. You install it graphically via
Anaconda. You wind up with Gnome (or LXDE or XFCE) and can run it.
Yum works. Security features are implemented and working. Etc.
These are the things Matthew is alluding to.
Anyway, my point isn't to say THOU MUST HAVE GNOME or focus on one
particular feature. I am merely to point out that it isn't an
x86-only discussion as there are other platforms that are certainly
right up there.
>> There were concerns about build times, particularly that of
the kernel: We
>> bought the fastest hardware available, moved to a unified kernel
>> architecture and sped up builds many-fold.
>
> And yet did not include any of that information in your proposal. I
> believe build times have improved. I also believe that you should
> show it in the proposal so that it is clear you are addressing prior
> concerns. I'm appreciate the effort spent to speed up the kernel
> build times, but the concern is global. Show the work done in the
> proposal with some simple numbers.
I don't believe it should be included in the proposal, in supporting
docs yes but the proposal is an overview not a justification doc.
That's fine. I didn't necessarily mean a big graph in the middle of a
wiki page, so sure. At the moment, there is nothing supporting the
proposal at all. It reads as "here's some marketing stuff about IT
landscapes and cheap devices", followed by two paragraphs of good
technical description of what secondary ARM looks like today, followed
by a list of needed changes.
What I'm looking for is supporting data on prior concerns and what
both the ARM team and the Fedora project gain from making ARM primary.
Again, the proposal is lacking in the why area. "You get ARM!" isn't
cutting it because you've all done such a good job that Fedora already
has ARM on the same day as x86 and PowerPC.
josh
12:58 p.m.
On 07/11/2013 05:08 AM, Josh Boyer wrote:
In terms of Fedora experience. You install it graphically via
Anaconda. You wind up with Gnome (or LXDE or XFCE) and can run it.
Yum works. Security features are implemented and working. Etc.
These are the things Matthew is alluding to.
In theory you can install graphically today. We tested graphical
installs via vnc (Not having a framebuffer puts a crimp in the matter).
You wind up with LXDE or XFCE, etc, and you can run it. Yum works.
Security features are implemented and working- except evidently pointer
guards, which we found out about *yesterday*.
What I'm looking for is supporting data on prior concerns and
what
both the ARM team and the Fedora project gain from making ARM primary.
Again, the proposal is lacking in the why area. "You get ARM!" isn't
cutting it because you've all done such a good job that Fedora already
has ARM on the same day as x86 and PowerPC.
Fair enough!
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:22 p.m.
On Thu, Jul 11, 2013 at 10:58:59AM -0700, Brendan Conoboy wrote:
Security features are implemented and working- except
evidently pointer guards, which we found out about *yesterday*.
The point of this isn't just that it was broken, though - the concern
here is that the test suite said it was not working. What else isn't
working because nobody has even looked? What's worrisome here is not
merely that a major security feature wasn't working. While that is
troubling, the fact of the matter is that people *not* on your team
thought it wasn't working, and assumed that you knew. The test suite
is giving failing results. That's not usually an indicator of high
quality or success.
The worry isn't that there's one thing here or there that doesn't work -
the worry 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.
--
Peter
1:36 p.m.
On Thu, 11 Jul 2013 14:22:08 -0400
Peter Jones <pjones(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 10:58:59AM -0700, Brendan Conoboy wrote:
> Security features are implemented and working- except
> evidently pointer guards, which we found out about *yesterday*.
The point of this isn't just that it was broken, though - the concern
here is that the test suite said it was not working. What else isn't
working because nobody has even looked? What's worrisome here is not
merely that a major security feature wasn't working. While that is
troubling, the fact of the matter is that people *not* on your team
thought it wasn't working, and assumed that you knew. The test suite
is giving failing results. That's not usually an indicator of high
quality or success.
Out of curiosity, where is this test/result?
Gcc package build? or ?
And wow... the gcc build log includes a gigantic uuencoded blob?
and unpackaged files?
:(
kevin
1:39 p.m.
On 07/11/2013 11:22 AM, Peter Jones wrote:
The point of this isn't just that it was broken, though - the
concern
here is that the test suite said it was not working. What else isn't
working because nobody has even looked? What's worrisome here is not
merely that a major security feature wasn't working. While that is
troubling, the fact of the matter is that people *not* on your team
thought it wasn't working, and assumed that you knew. The test suite
is giving failing results. That's not usually an indicator of high
quality or success.
Yes, this is a serious issue for any architecture. It's more of a
people problem than technical though. We can solve it for gcc on ARM
specifically, but as a general case I don't have an easy answer.
The worry isn't that there's one thing here or there that
doesn't work -
the worry 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. / blc(a)redhat.com
4:17 p.m.
On Thu, Jul 11, 2013 at 7:22 PM, Peter Jones <pjones(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 10:58:59AM -0700, Brendan Conoboy wrote:
> Security features are implemented and working- except
> evidently pointer guards, which we found out about *yesterday*.
The point of this isn't just that it was broken, though - the concern
here is that the test suite said it was not working. What else isn't
working because nobody has even looked? What's worrisome here is not
merely that a major security feature wasn't working. While that is
troubling, the fact of the matter is that people *not* on your team
thought it wasn't working, and assumed that you knew. The test suite
is giving failing results. That's not usually an indicator of high
quality or success.
Can you link to these test suite failures? In all cases I would expect
that make check would fail and hence the package would fail to build
but I've seen issues on x86 as well where the "test results" are
logged but ignored. I'm fully aware ARM isn't perfect here because in
the early time of bring up we've needed to disable some tests during
bring or to move things forward while upstream bugs are fixed up but
I've usually filed bugs to track the issue to ensure that things are
reverted on resolution.
The worry isn't that there's one thing here or there that
doesn't work -
the worry 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.
Are you aware of others other than fstack-protector?
Peter
12:23 p.m.
On 07/11/2013 03:55 AM, Josh Boyer wrote:
I will note that it is not x86 alone. If one is simply going by
"as
close to the current Fedora experience the current Primary offers",
then the PowerPC secondary arch team is actually ahead of ARM. I'm
not saying they are a better candidate, but I am pointing out that the
criteria Matthew is alluding to is being met by non-x86 architectures.
I'm not up-to-date on the current condition of Power: Are you
specifically referring to GNOME & KDE? If so I'd posit that this is
because GNOME & KDE make a lot more sense on Power than they do on ARM.
Developer energy goes where it's needed & wanted. Prior to this
discussion nobody was lamenting the state of gnome on their low power
ARM system. We're still building them of course- all the GNOME and KDE
packages are built, they're just not getting used AFAIK.
I don't believe that is true. ARM is useful, I want it to be a
Primary arch, but I fail to see how your middle ground below of having
it be primary in the build system is going to somehow grow Fedora. I
believe there are concerns that it will place additional burden on
package maintainers (like ppc did before there was a real arch team
for it), and that those concerns are valid.
Are those concerns valid? By what measure? Can they be controverted by
evidence? Thus far we have pro and con anecdotes.
And yet did not include any of that information in your proposal. I
believe build times have improved. I also believe that you should
show it in the proposal so that it is clear you are addressing prior
concerns. I'm appreciate the effort spent to speed up the kernel
build times, but the concern is global. Show the work done in the
proposal with some simple numbers.
These are good suggestions- thanks for that.
Again, I would like to see ARM as Primary and I believe the ARM team
has done a rather good job. Promoting anything to Primary has never
been done before, so bear with us as we work through it.
Absolutely. Change is hard, but if all goes well this one will be
popular in hindsight :-)
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:41 p.m.
Brendan Conoboy (blc(a)redhat.com) said:
I'm not up-to-date on the current condition of Power: Are you
specifically referring to GNOME & KDE? If so I'd posit that this is
because GNOME & KDE make a lot more sense on Power than they do on
ARM. Developer energy goes where it's needed & wanted. Prior to
this discussion nobody was lamenting the state of gnome on their low
power ARM system. We're still building them of course- all the
GNOME and KDE packages are built, they're just not getting used
AFAIK.
This seems wildly at odds with
1) what the people using Power in production are targeting (not desktop at
all)
2) what the enthusiast people for ARM are building. After all, the
annoucement explicitly says "The image is available for each of the major
desktop environments" (which, not true), and people in this very thread are
suggesting interested developers get Chromebooks.
I mean, I do know what some people want ARM to be in terms of dense
hypserscale servers (32/64-bit)... but the community that would be using
Fedora ARM does seem to be targeting a wider array than that.
So, in terms of PA, I think there are reasonable guides of parity that need
to be met:
- If a feature claims to be supported on both arches, it should work the same.
Hence, stack-protector needs fixed.
- The main interface for documented Fedora workflows should be the same.
Hence, use of Anaconda, use of systemd, etc.
- The core functionality should work the same
Kernel, glibc, all the core library stacks. And I would argue that yes, this
*includes* libGL. So llvmpipe needs fixed, outside of any desktops. Should
we define the core functionality better? Probably.
- The defaults should be the same.
SELinux on. Filesystem of ext4 (currently), and so forth.
And also therefore, if you're intending to ship/support a desktop use case
(which, from the F19 ARM deliverables seems to be the case), then the same
one that's the default on other primary arches needs to be available, work,
and should be the default on the new primary arch as well.
Bill
1:40 p.m.
On 07/11/2013 10:41 AM, Bill Nottingham wrote:
Kernel, glibc, all the core library stacks. And I would argue that
yes, this
*includes* libGL. So llvmpipe needs fixed, outside of any desktops. Should
we define the core functionality better? Probably.
I would argue that it does not include libGL because it's not a
requirement for headless deployment scenarios. Why would you argue for it?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
2:37 p.m.
Brendan Conoboy (blc(a)redhat.com) said:
On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>Kernel, glibc, all the core library stacks. And I would argue that yes, this
>*includes* libGL. So llvmpipe needs fixed, outside of any desktops. Should
>we define the core functionality better? Probably.
I would argue that it does not include libGL because it's not a
requirement for headless deployment scenarios. Why would you argue
for it?
Well, as I said (and you cut out)
...
I do know what some people want ARM to be in terms of dense
hypserscale servers (32/64-bit)... but the community that would be using
Fedora ARM does seem to be targeting a wider array than that.
...
The F19 ARM release released 5 desktop images. You seem to be arguing that
the required featureset of ARM as a primary arch should only be for headless
deployment, but the ARM community itself is saying otherwise.
Bill
2:47 p.m.
On 07/11/2013 12:37 PM, Bill Nottingham wrote:
Well, as I said (and you cut out)
...
I do know what some people want ARM to be in terms of dense
hypserscale servers (32/64-bit)... but the community that would be using
Fedora ARM does seem to be targeting a wider array than that.
...
The F19 ARM release released 5 desktop images. You seem to be arguing that
the required featureset of ARM as a primary arch should only be for headless
deployment, but the ARM community itself is saying otherwise.
Interests differ between participants. If this was the only objection
to moving ARM to the 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. / blc(a)redhat.com
1:09 p.m.
Brendan Conoboy (blc(a)redhat.com) said:
On 07/11/2013 12:37 PM, Bill Nottingham wrote:
>Well, as I said (and you cut out)
>...
>I do know what some people want ARM to be in terms of dense
>hypserscale servers (32/64-bit)... but the community that would be using
>Fedora ARM does seem to be targeting a wider array than that.
>...
>
>The F19 ARM release released 5 desktop images. You seem to be arguing that
>the required featureset of ARM as a primary arch should only be for headless
>deployment, but the ARM community itself is saying otherwise.
Interests differ between participants. If this was the only
objection to moving ARM to the 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.
If I'm understanding you, you would prefer that ARM be blessed with the
stamp of being a 'primary' arch at the cost of dropping release targets,
images, and featuresets that are made by and for the community now.
I don't think I can support that - it seems awfully unfriendly to the
community that exists now.
Bill
1:18 p.m.
On 07/15/2013 06:09 PM, Bill Nottingham wrote:
Brendan Conoboy (blc(a)redhat.com) said:
> On 07/11/2013 12:37 PM, Bill Nottingham wrote:
>> Well, as I said (and you cut out)
>> ...
>> I do know what some people want ARM to be in terms of dense
>> hypserscale servers (32/64-bit)... but the community that would be using
>> Fedora ARM does seem to be targeting a wider array than that.
>> ...
>>
>> The F19 ARM release released 5 desktop images. You seem to be arguing that
>> the required featureset of ARM as a primary arch should only be for headless
>> deployment, but the ARM community itself is saying otherwise.
> Interests differ between participants. If this was the only
> objection to moving ARM to the 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.
If I'm understanding you, you would prefer that ARM be blessed with the
stamp of being a 'primary' arch at the cost of dropping release targets,
images, and featuresets that are made by and for the community now.
I don't think I can support that - it seems awfully unfriendly to the
community that exists now.
Having an default/release target has been awfully unfriendly to the
community that exist and has existed at least since fc6 - f7 ( when we
introduced live's even longer if you want to count KDE as well ) now and
just recently with the mate desktop wanting to become default so I dont
think that argument applies here since not everybody and every sub
community and every ones contribution to the project is given equal
treatment as things stand now.
However features should apply to all arch primary or not unless they
cant for some reason or another be applied to that architecture which
then should be specifically noted in relevant section in the release notes.
JBG
4:30 p.m.
On 07/15/2013 11:09 AM, Bill Nottingham wrote:
If I'm understanding you, you would prefer that ARM be blessed
with the
stamp of being a 'primary' arch at the cost of dropping release targets,
images, and featuresets that are made by and for the community now.
I wouldn't put it like that. The ARM team isn't asking for a blessing,
we're asking to have builds that block ARM also block x86. At a
technical level, that is a fundamental part of what being primary is.
Yes, there are other aspects, both practical (what is released) and
philosophical (What is Fedora). It's the next logical step. If not
now, when? When libGL is ready to go?
I don't think I can support that - it seems awfully unfriendly to
the
community that exists now.
You are proceeding from a misconception: This is a thought exercise- If
ARM devices didn't have 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. / blc(a)redhat.com
1:01 p.m.
Brendan Conoboy (blc(a)redhat.com) said:
On 07/15/2013 11:09 AM, Bill Nottingham wrote:
>If I'm understanding you, you would prefer that ARM be blessed with the
>stamp of being a 'primary' arch at the cost of dropping release targets,
>images, and featuresets that are made by and for the community now.
I wouldn't put it like that. The ARM team isn't asking for a
blessing, we're asking to have builds that block ARM also block x86.
At a technical level, that is a fundamental part of what being
primary is. Yes, there are other aspects, both practical (what is
released) and philosophical (What is Fedora). It's the next logical
step. If not now, when? When libGL is ready to go?
... when someone fixes it?
>I don't think I can support that - it seems awfully
unfriendly to the
>community that exists now.
You are proceeding from a misconception: This is a thought exercise-
If ARM devices didn't have 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.
And I'm saying that threshold should be that the major libraries work. That
includes libGL.
After all, IT WORKS ON S390. This is not a high bar, and I wouldn't consider
it a requirement for that arch.
Sure, the hardware you care about doesn't include graphics. But the hardware
the community cares about does.
Bill
1:06 p.m.
On 07/16/2013 11:01 AM, Bill Nottingham wrote:
Brendan Conoboy (blc(a)redhat.com) said:
> If not now, when? When libGL is ready to go?
... when someone fixes it?
Hypothetically speaking, if libGL is fixed in the next few days, do you
have any objections to armv7hl being moved to primary koji? Or is that
the tip of the iceberg?
And I'm saying that threshold should be that the major libraries
work. That
includes libGL.
Okay, so it's not just libGL, it's major libraries. Which are those?
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:36 p.m.
Brendan Conoboy (blc(a)redhat.com) said:
Hypothetically speaking, if libGL is fixed in the next few days, do
you have any objections to armv7hl being moved to primary koji? Or
is that the tip of the iceberg?
>And I'm saying that threshold should be that the major libraries work. That
>includes libGL.
Okay, so it's not just libGL, it's major libraries. Which are those?
Well, what else is broken?
It's a matter of approach - you seem to be saying "what are the minimum
requirements, listed so that we can meet them". In terms of a minimum
viable platform, for all its faults, the interfaces specified by the LSB
might be a worthwhile starting point. But even in that case... if an arch
implemented the entire LSB, and 90% of the rest of the distribution did not
build, that's obviously not good enough. So I'm more in favor of "tell us
what you don't have, and we can discuss whether that's good enough."
I don't want to move the goalposts on the ARM effort, but I think it's
reasonable to expect that a list of "Known Broken/Deficient items" be
available. Does such a list exist?
Bill
6:07 p.m.
On 07/16/2013 11:36 AM, Bill Nottingham wrote:
Well, what else is broken?
It's a matter of approach - you seem to be saying "what are the minimum
requirements, listed so that we can meet them". In terms of a minimum
viable platform, for all its faults, the interfaces specified by the LSB
might be a worthwhile starting point. But even in that case... if an arch
implemented the entire LSB, and 90% of the rest of the distribution did not
build, that's obviously not good enough. So I'm more in favor of "tell us
what you don't have, and we can discuss whether that's good enough."
I don't want to move the goalposts on the ARM effort, but I think it's
reasonable to expect that a list of "Known Broken/Deficient items" be
available. Does such a list exist?
The list of outstanding ARM bugs is tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=245418
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
6:09 p.m.
On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote:
>I don't want to move the goalposts on the ARM effort, but I
think it's
>reasonable to expect that a list of "Known Broken/Deficient items" be
>available. Does such a list exist?
The list of outstanding ARM bugs is tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=245418
alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:16 p.m.
On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote:
> >I don't want to move the goalposts on the ARM effort, but I think it's
> >reasonable to expect that a list of "Known Broken/Deficient items" be
> >available. Does such a list exist?
> The list of outstanding ARM bugs is tracked here:
> https://bugzilla.redhat.com/show_bug.cgi?id=245418
alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
And we're working to sure it's completely up to date, sorry but the
last couple of days have been some what hectic for me in other realms.
Peter
9:16 p.m.
On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote:
On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote:
>> >I don't want to move the goalposts on the ARM effort, but I think
it's
>> >reasonable to expect that a list of "Known Broken/Deficient items"
be
>> >available. Does such a list exist?
>> The list of outstanding ARM bugs is tracked here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=245418
>
> alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
And we're working to sure it's completely up to date, sorry but the
last couple of days have been some what hectic for me in other realms.
For instance, it seems to be missing both the stack protector and
llvmpipe issues.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:33 p.m.
On 07/16/2013 07:16 PM, Matthew Garrett wrote:
On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote:
> On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller
> <mattdm(a)fedoraproject.org> wrote:
>> On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote:
>>>> I don't want to move the goalposts on the ARM effort, but I think
it's
>>>> reasonable to expect that a list of "Known Broken/Deficient
items" be
>>>> available. Does such a list exist?
>>> The list of outstanding ARM bugs is tracked here:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=245418
>>
>> alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
>
> And we're working to sure it's completely up to date, sorry but the
> last couple of days have been some what hectic for me in other realms.
For instance, it seems to be missing both the stack protector and
llvmpipe issues.
Finishing scope of stack protector issue- it'll be there in a day or so.
Idea is to get upstream reports in, then link to them.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
9:53 p.m.
On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote:
On 07/16/2013 07:16 PM, Matthew Garrett wrote:
>For instance, it seems to be missing both the stack protector
and
>llvmpipe issues.
Finishing scope of stack protector issue- it'll be there in a day or
so. Idea is to get upstream reports in, then link to them.
Sure, I'm not saying that they're not being worked on. I'm just pointing
out that the ARM tracker bug doesn't list every known ARM issue.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:34 a.m.
On Wed, Jul 17, 2013 at 3:53 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote:
> On 07/16/2013 07:16 PM, Matthew Garrett wrote:
> >For instance, it seems to be missing both the stack protector and
> >llvmpipe issues.
>
> Finishing scope of stack protector issue- it'll be there in a day or
> so. Idea is to get upstream reports in, then link to them.
Sure, I'm not saying that they're not being worked on. I'm just pointing
out that the ARM tracker bug doesn't list every known ARM issue.
Yes, aware of that, the llvm issue is there, might be useful to update
the description. I'll be adding some more soon to cover things like
ada bringup to ensure it's all tracked.
Peter
4:25 p.m.
On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>
> Kernel, glibc, all the core library stacks. And I would argue that yes,
> this
> *includes* libGL. So llvmpipe needs fixed, outside of any desktops.
> Should
> we define the core functionality better? Probably.
I would argue that it does not include libGL because it's not a requirement
for headless deployment scenarios. Why would you argue for it?
I would argue that it's nothing to do with headless scenarios but more
that the vast majority of ARM GPUs support GL-ES which is a
sub/different standard of desktop GL (sorry, I'm not a graphics
programming expert!) and the support for that in mesa and in general
is terrible. There was a proposal to refactor mesa and when I spoke to
ajax (I think, sorry ajax if it wasn't you) or someone it wasn't
basically moving forward upstream at the moment. I'm not sure who
originally was driving this (my google fu doesn't give me the mailing
list proposal ATM).
Peter
4:57 p.m.
On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy
<blc(a)redhat.com> wrote:
> On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>>
>> Kernel, glibc, all the core library stacks. And I would argue that yes,
>> this
>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops.
>> Should
>> we define the core functionality better? Probably.
>
>
> I would argue that it does not include libGL because it's not a requirement
> for headless deployment scenarios. Why would you argue for it?
I would argue that it's nothing to do with headless scenarios but more
that the vast majority of ARM GPUs support GL-ES which is a
sub/different standard of desktop GL (sorry, I'm not a graphics
programming expert!) and the support for that in mesa and in general
is terrible. There was a proposal to refactor mesa and when I spoke to
ajax (I think, sorry ajax if it wasn't you) or someone it wasn't
basically moving forward upstream at the moment. I'm not sure who
originally was driving this (my google fu doesn't give me the mailing
list proposal ATM).
It is getting a bit off the topic, but this it isn't really a problem
with mesa. But rather that we have non-gallium closed src drivers
from the GPU vendors in the ARM space, which only support GLES. And
most/all of the desktop stuff packaged in fedora (in particular,
gnome-shell) is requiring GL.
The desktop gallium mesa drivers, and also the intel mesa driver, all
seem to support both GL and GLES reasonably well..
From a hw standpoint, while they may lack some features compared to
desktop GPU, I think all the current mobile GPUs should support enough
features in hardware to get gnome-shell running (possibly with some
driver tricks, for example in freedreno I have to emulate quads with
triangles). It wouldn't be enough for passing any GL compliance
suite, but the requirements for gnome-shell are fairly basic.
BR,
-R
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6 a.m.
On Monday, July 15, 2013, Rob Clark <robdclark(a)gmail.com> wrote:
On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson
<pbrobinson(a)gmail.com>
wrote:
> On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy
<blc(a)redhat.com> wrote:
>> On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>>>
>>> Kernel, glibc, all the core library stacks. And I would argue that yes,
>>> this
>>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops.
>>> Should
>>> we define the core functionality better? Probably.
>>
>>
>> I would argue that it does not include libGL because it's not a
requirement
>> for headless deployment scenarios. Why would you argue for
it?
>
> I would argue that it's nothing to do with headless scenarios but more
> that the vast majority of ARM GPUs support GL-ES which is a
> sub/different standard of desktop GL (sorry, I'm not a graphics
> programming expert!) and the support for that in mesa and in general
> is terrible. There was a proposal to refactor mesa and when I spoke to
> ajax (I think, sorry ajax if it wasn't you) or someone it wasn't
> basically moving forward upstream at the moment. I'm not sure who
> originally was driving this (my google fu doesn't give me the mailing
> list proposal ATM).
It is getting a bit off the topic, but this it isn't really a problem
with mesa. But rather that we have non-gallium closed src drivers
from the GPU vendors in the ARM space, which only support GLES. And
most/all of the desktop stuff packaged in fedora (in particular,
gnome-shell) is requiring GL.
This is incorrect. It uses cogl which has a gles renderer wich is supposed
Tod work. If it does not that is just a bug that we should fix.
7:42 a.m.
On Tue, 2013-07-16 at 13:00 +0200, drago01 wrote:
> It is getting a bit off the topic, but this it isn't really
a
problem
> with mesa. But rather that we have non-gallium closed src drivers
> from the GPU vendors in the ARM space, which only support GLES. And
> most/all of the desktop stuff packaged in fedora (in particular,
> gnome-shell) is requiring GL.
This is incorrect. It uses cogl which has a gles renderer wich is
supposed Tod work. If it does not that is just a bug that we should
fix.
Eh. Kind of. Yes, cogl has a gles backend, yes it should work, but X
itself also has a dependency on having GL below it. GLX 1.4 exposes
accumulation buffers, which exist in GL but not in GLES; not that
anything uses accum buffers, but their non-existence would technically
be a conformance failure for GLX. GLES doesn't have glBegin, so
xserver's implementation of glBegin, if done atop GLES, would need to
emulate it, and currently does not. And so on.
More immediately, xserver's half of the GLX implementation requires not
just GL, but an actual DRI driver. I have an experimental git tree that
starts fixing that [1] but currently it's a regression for Xorg since it
hasn't yet grown a GLX-on-EGL provider. Still, once you fix that, you
could set about porting xserver/glx/ to GLES.
So, say you were running on such a closed-source driver. You could run
cogl atop the GLES it provides, if you weren't also trying to run X as
your window system. Admittedly we'd like to stop doing that too...
[1] - http://cgit.freedesktop.org/~ajax/xserver/log/?h=glx
- ajax
8:39 a.m.
On Tue, Jul 16, 2013 at 2:42 PM, Adam Jackson <ajax(a)redhat.com> wrote:
On Tue, 2013-07-16 at 13:00 +0200, drago01 wrote:
> > It is getting a bit off the topic, but this it isn't really a
> problem
> > with mesa. But rather that we have non-gallium closed src drivers
> > from the GPU vendors in the ARM space, which only support GLES. And
> > most/all of the desktop stuff packaged in fedora (in particular,
> > gnome-shell) is requiring GL.
>
> This is incorrect. It uses cogl which has a gles renderer wich is
> supposed Tod work. If it does not that is just a bug that we should
> fix.
Eh. Kind of. Yes, cogl has a gles backend, yes it should work, but X
itself also has a dependency on having GL below it. GLX 1.4 exposes
accumulation buffers, which exist in GL but not in GLES; not that
anything uses accum buffers, but their non-existence would technically
be a conformance failure for GLX. GLES doesn't have glBegin, so
xserver's implementation of glBegin, if done atop GLES, would need to
emulate it, and currently does not. And so on.
More immediately, xserver's half of the GLX implementation requires not
just GL, but an actual DRI driver.
Well we have an EGL backend ... I never tested it but shouldn't
EGL+GLES work on X already?
9:58 a.m.
On Tue, Jul 16, 2013 at 7:00 AM, drago01 <drago01(a)gmail.com> wrote:
On Monday, July 15, 2013, Rob Clark <robdclark(a)gmail.com> wrote:
> On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson <pbrobinson(a)gmail.com>
> wrote:
>> On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
>>> On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>>>>
>>>> Kernel, glibc, all the core library stacks. And I would argue that yes,
>>>> this
>>>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops.
>>>> Should
>>>> we define the core functionality better? Probably.
>>>
>>>
>>> I would argue that it does not include libGL because it's not a
>>> requirement
>>> for headless deployment scenarios. Why would you argue for it?
>>
>> I would argue that it's nothing to do with headless scenarios but more
>> that the vast majority of ARM GPUs support GL-ES which is a
>> sub/different standard of desktop GL (sorry, I'm not a graphics
>> programming expert!) and the support for that in mesa and in general
>> is terrible. There was a proposal to refactor mesa and when I spoke to
>> ajax (I think, sorry ajax if it wasn't you) or someone it wasn't
>> basically moving forward upstream at the moment. I'm not sure who
>> originally was driving this (my google fu doesn't give me the mailing
>> list proposal ATM).
>
> It is getting a bit off the topic, but this it isn't really a problem
> with mesa. But rather that we have non-gallium closed src drivers
> from the GPU vendors in the ARM space, which only support GLES. And
> most/all of the desktop stuff packaged in fedora (in particular,
> gnome-shell) is requiring GL.
This is incorrect. It uses cogl which has a gles renderer wich is supposed
Tod work. If it does not that is just a bug that we should fix.
At least as packaged in f19, it seems to require GL. I know of people
who have recompiled it, and supposedly have it working to some degree
with GLES. Not sure if that was the same version as what is in f19,
etc.
Where possible, it would certainly be useful to get more stuff with
GLES support in fedora.
BR,
-R
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:09 a.m.
On Tue, Jul 16, 2013 at 4:58 PM, Rob Clark <robdclark(a)gmail.com> wrote:
On Tue, Jul 16, 2013 at 7:00 AM, drago01 <drago01(a)gmail.com>
wrote:
>
>
> On Monday, July 15, 2013, Rob Clark <robdclark(a)gmail.com> wrote:
>> On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson <pbrobinson(a)gmail.com>
>> wrote:
>>> On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy <blc(a)redhat.com>
wrote:
>>>> On 07/11/2013 10:41 AM, Bill Nottingham wrote:
>>>>>
>>>>> Kernel, glibc, all the core library stacks. And I would argue that
yes,
>>>>> this
>>>>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops.
>>>>> Should
>>>>> we define the core functionality better? Probably.
>>>>
>>>>
>>>> I would argue that it does not include libGL because it's not a
>>>> requirement
>>>> for headless deployment scenarios. Why would you argue for it?
>>>
>>> I would argue that it's nothing to do with headless scenarios but more
>>> that the vast majority of ARM GPUs support GL-ES which is a
>>> sub/different standard of desktop GL (sorry, I'm not a graphics
>>> programming expert!) and the support for that in mesa and in general
>>> is terrible. There was a proposal to refactor mesa and when I spoke to
>>> ajax (I think, sorry ajax if it wasn't you) or someone it wasn't
>>> basically moving forward upstream at the moment. I'm not sure who
>>> originally was driving this (my google fu doesn't give me the mailing
>>> list proposal ATM).
>>
>> It is getting a bit off the topic, but this it isn't really a problem
>> with mesa. But rather that we have non-gallium closed src drivers
>> from the GPU vendors in the ARM space, which only support GLES. And
>> most/all of the desktop stuff packaged in fedora (in particular,
>> gnome-shell) is requiring GL.
>
> This is incorrect. It uses cogl which has a gles renderer wich is supposed
> Tod work. If it does not that is just a bug that we should fix.
At least as packaged in f19, it seems to require GL. I know of people
who have recompiled it, and supposedly have it working to some degree
with GLES. Not sure if that was the same version as what is in f19,
etc.
OK, seems like we indeed do not build them. But once built switching
can be done using ENV vars.
1:53 p.m.
On Thu, 2013-07-11 at 13:41 -0400, Bill Nottingham wrote:
[lots of reasonable criteria snipped]
And also therefore, if you're intending to ship/support a desktop
use case
(which, from the F19 ARM deliverables seems to be the case), then the same
one that's the default on other primary arches needs to be available, work,
and should be the default on the new primary arch as well.
If I may add to this: I could see having a primary architecture that may
not intend to 'ship/support a desktop use case' - it could be targeting
solely the 'headless server' use case. But - in that case I would expect
to see some work towards defining and designing the user experience for
that use case, in ways that would also make sense on other
architectures. I'm convinced that Fedora could be much more awesome on
servers, if this was treated as a proper use case ('minimal install'
does not really do it justice).
Matthias
1:02 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 11 Jul 2013 10:23:50 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 07/11/2013 03:55 AM, Josh Boyer wrote:
> I will note that it is not x86 alone. If one is simply going by "as
> close to the current Fedora experience the current Primary offers",
> then the PowerPC secondary arch team is actually ahead of ARM. I'm
> not saying they are a better candidate, but I am pointing out that
> the criteria Matthew is alluding to is being met by non-x86
> architectures.
I'm not up-to-date on the current condition of Power: Are you
specifically referring to GNOME & KDE? If so I'd posit that this is
because GNOME & KDE make a lot more sense on Power than they do on
ARM. Developer energy goes where it's needed & wanted. Prior to this
discussion nobody was lamenting the state of gnome on their low power
ARM system. We're still building them of course- all the GNOME and
KDE packages are built, they're just not getting used AFAIK.
I actually switched my chromebook over to KDE and used it on my
trimslice quite extensively. during the f19 cycle.
> I don't believe that is true. ARM is useful, I want it to
be a
> Primary arch, but I fail to see how your middle ground below of
> having it be primary in the build system is going to somehow grow
> Fedora. I believe there are concerns that it will place additional
> burden on package maintainers (like ppc did before there was a real
> arch team for it), and that those concerns are valid.
Are those concerns valid? By what measure? Can they be controverted
by evidence? Thus far we have pro and con anecdotes.
> And yet did not include any of that information in your proposal. I
> believe build times have improved. I also believe that you should
> show it in the proposal so that it is clear you are addressing prior
> concerns. I'm appreciate the effort spent to speed up the kernel
> build times, but the concern is global. Show the work done in the
> proposal with some simple numbers.
i will look at throwing together a script to give us some comparisons
between the build times on the different arches.
These are good suggestions- thanks for that.
> Again, I would like to see ARM as Primary and I believe the ARM team
> has done a rather good job. Promoting anything to Primary has never
> been done before, so bear with us as we work through it.
Absolutely. Change is hard, but if all goes well this one will be
popular in hindsight :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHfnAgACgkQkSxm47BaWffSCACeN+s7FHECOv2u6I6uWAXEcvdX
1W4AoK5y5BUyM49tLtSn+z0VTkBnMjIq
=txCb
-----END PGP SIGNATURE-----
1:28 a.m.
----- Original Message -----
From: "Dennis Gilmore" <dennis(a)ausil.us>
To: devel(a)lists.fedoraproject.org
Sent: Friday, July 12, 2013 9:02:48 AM
Subject: Re: F20 System Wide Change: ARM as primary Architecture
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 11 Jul 2013 10:23:50 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
> On 07/11/2013 03:55 AM, Josh Boyer wrote:
> > I will note that it is not x86 alone. If one is simply going by "as
> > close to the current Fedora experience the current Primary offers",
> > then the PowerPC secondary arch team is actually ahead of ARM. I'm
> > not saying they are a better candidate, but I am pointing out that
> > the criteria Matthew is alluding to is being met by non-x86
> > architectures.
>
> I'm not up-to-date on the current condition of Power: Are you
> specifically referring to GNOME & KDE? If so I'd posit that this is
> because GNOME & KDE make a lot more sense on Power than they do on
> ARM. Developer energy goes where it's needed & wanted. Prior to this
> discussion nobody was lamenting the state of gnome on their low power
> ARM system. We're still building them of course- all the GNOME and
> KDE packages are built, they're just not getting used AFAIK.
I actually switched my chromebook over to KDE and used it on my
trimslice quite extensively. during the f19 cycle.
> > I don't believe that is true. ARM is useful, I want it to be a
> > Primary arch, but I fail to see how your middle ground below of
> > having it be primary in the build system is going to somehow grow
> > Fedora. I believe there are concerns that it will place additional
> > burden on package maintainers (like ppc did before there was a real
> > arch team for it), and that those concerns are valid.
>
> Are those concerns valid? By what measure? Can they be controverted
> by evidence? Thus far we have pro and con anecdotes.
>
> > And yet did not include any of that information in your proposal. I
> > believe build times have improved. I also believe that you should
> > show it in the proposal so that it is clear you are addressing prior
> > concerns. I'm appreciate the effort spent to speed up the kernel
> > build times, but the concern is global. Show the work done in the
> > proposal with some simple numbers.
i will look at throwing together a script to give us some comparisons
between the build times on the different arches.
Phew, finally something meaningful :) . I was afraid that the major (at least for me)
problem named "make it cost more time for packagers" will be plain ignored.
Can we get a comparison for majority of packages and get some real point that will become
too costy for packagers - aka build time of less than 20% of packages should be 5 or more
times longer. I personally thing this is pretty low bar but some might argue that it's
high so numbers put are just to serve as an example.
Alexander Kurtakov
Red Hat Eclipse team
> These are good suggestions- thanks for that.
>
> > Again, I would like to see ARM as Primary and I believe the ARM team
> > has done a rather good job. Promoting anything to Primary has never
> > been done before, so bear with us as we work through it.
>
> Absolutely. Change is hard, but if all goes well this one will be
> popular in hindsight :-)
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlHfnAgACgkQkSxm47BaWffSCACeN+s7FHECOv2u6I6uWAXEcvdX
1W4AoK5y5BUyM49tLtSn+z0VTkBnMjIq
=txCb
-----END PGP SIGNATURE-----
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel 
9:52 a.m.
i will look at throwing together a script to give us some
comparisons
between the build times on the different arches.
I've already done this, last time it came up...
http://www.delorie.com/arm/koji-compare-build-times.tar.gz
9:53 a.m.
On Fri, 12 Jul 2013 10:52:15 -0400
DJ Delorie <dj(a)redhat.com> wrote:
> i will look at throwing together a script to give us some
> comparisons between the build times on the different arches.
I've already done this, last time it came up...
http://www.delorie.com/arm/koji-compare-build-times.tar.gz
HTTP request sent, awaiting response... 403 Forbidden
2013-07-12 08:53:13 ERROR 403: Forbidden.
:(
kevin
10:05 a.m.
> http://www.delorie.com/arm/koji-compare-build-times.tar.gz
HTTP request sent, awaiting response... 403 Forbidden
2013-07-12 08:53:13 ERROR 403: Forbidden.
"wget" is blocked unless you're clueful enough to use the -U flag.
Consider it a spot check for "smart enough to not recursively download
my entire web server".
The server should have told you that in the error message.
10:10 a.m.
On Fri, 12 Jul 2013 11:05:49 -0400
DJ Delorie <dj(a)redhat.com> wrote:
> > http://www.delorie.com/arm/koji-compare-build-times.tar.gz
>
> HTTP request sent, awaiting response... 403 Forbidden
> 2013-07-12 08:53:13 ERROR 403: Forbidden.
"wget" is blocked unless you're clueful enough to use the -U flag.
Consider it a spot check for "smart enough to not recursively download
my entire web server".
The server should have told you that in the error message.
It did not. Just forbidden.
kevin
10:07 a.m.
i will look at throwing together a script to give us some
comparisons
between the build times on the different arches.
I've already done this, last time it came up...
http://www.delorie.com/arm/koji-compare-build-times.tar.gz
Also, I'm running the script now, I'll post results when it finishes,
let's not ALL hit the koji database at the same time ;-)
6:19 p.m.
Also, I'm running the script now, I'll post results when it
finishes, let's not ALL hit the koji database at the same time ;-)
Results here:
http://www.delorie.com/arm/f19-times.html
includes the raw time data from koji
6:49 a.m.
On Wed, Jul 10, 2013 at 11:04:51PM -0700, Brendan Conoboy wrote:
The all or nothing element in the above simply serves to discourage
further contribution and is harming Fedora's growth. The relentless
"I don't want ARM to sully the good name of Fedora" is absurd: User
for user, ARM is considerably more popular than Fedora. Is your
definition of "Primary" a sacred idea that is responsible for
Fedora's success? If held dear for too long it will be the well
known idea responsible for its failure.
CPUs are an implementation detail. The experience of running Fedora on
ARM should be as close as possible to that of running Fedora on x86. If
we're willing to compromise on that, then what do we actually mean by
"Fedora"? Something that shares a majority of the packages? Well, in
that case any of the spins would also be Fedora, but we draw a
distinction between a spin and the general install media.
This isn't some new distinction that I'm pulling out of the air. We've
always had a strong idea of what Fedora is and a defined marketing
message that distinguishes between Fedora and something that's
almost-but-not-quite Fedora. Right now the proposal is for something
that's almost-but-not-quite Fedora to be treated as if it's Fedora, and
I don't think that benefits the public perception of the project.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:01 a.m.
----- Original Message -----
On Wed, Jul 10, 2013 at 11:04:51PM -0700, Brendan Conoboy wrote:
> The all or nothing element in the above simply serves to discourage
> further contribution and is harming Fedora's growth. The relentless
> "I don't want ARM to sully the good name of Fedora" is absurd: User
> for user, ARM is considerably more popular than Fedora. Is your
> definition of "Primary" a sacred idea that is responsible for
> Fedora's success? If held dear for too long it will be the well
> known idea responsible for its failure.
CPUs are an implementation detail. The experience of running Fedora on
ARM should be as close as possible to that of running Fedora on x86. If
we're willing to compromise on that, then what do we actually mean by
"Fedora"? Something that shares a majority of the packages? Well, in
that case any of the spins would also be Fedora, but we draw a
distinction between a spin and the general install media.
But spins are Fedora, same as cloud image is still Fedora (and I don't
see complaints it does not run Gnome Shell ;-). Desktop spin is one
spin of the many spins but we promote it (for several reasons) more than
others. So again - I don't see this as a problem with having ARM as PA
(I can see other issues like HW availability, build times, resources) but
having an ARM spin composed from primary builds with a DE that suits
still limited resources on ARM machines - no problem at all. Even blocking
desktop release criteria are fulfilled this way as we don't require for
example LXDE spin to ship Gnome and KDE ;-).
This isn't some new distinction that I'm pulling out of the
air. We've
always had a strong idea of what Fedora is and a defined marketing
message that distinguishes between Fedora and something that's
almost-but-not-quite Fedora. Right now the proposal is for something
that's almost-but-not-quite Fedora to be treated as if it's Fedora, and
I don't think that benefits the public perception of the project.
Almost-but-not-quite Fedora are remixes. Even now Fedora ARM is Fedora,
just a secondary architecture - it's actually more a technical detail
where the builds are done. So we already consider it Fedora! It's not
going to change with ARM being primary.
Jaroslav
--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
7:23 a.m.
On Thu, Jul 11, 2013 at 08:01:46AM -0400, Jaroslav Reznik wrote:
But spins are Fedora, same as cloud image is still Fedora (and I
don't
see complaints it does not run Gnome Shell ;-). Desktop spin is one
spin of the many spins but we promote it (for several reasons) more than
others. So again - I don't see this as a problem with having ARM as PA
(I can see other issues like HW availability, build times, resources) but
having an ARM spin composed from primary builds with a DE that suits
still limited resources on ARM machines - no problem at all. Even blocking
desktop release criteria are fulfilled this way as we don't require for
example LXDE spin to ship Gnome and KDE ;-).
If I download the Fedora installation media, boot it, select all the
defaults and then reboot into the installed system, I get a well-defined
outcome. If we promote ARM to primary and treat it in the same way, the
well-defined outcome will be different depending on whether I pick ARM
or x86.
If I go to fedoraproject.org, the first thing I see is a picture of
Gnome Shell with "Fedora 19" written underneath it. How do we deal with
that in the ARM case? Add a disclaimer indicating that if you pick this
outwardly identical install image for a different architecture, you'll
end up with something that looks entirely different?
Almost-but-not-quite Fedora are remixes. Even now Fedora ARM is
Fedora,
just a secondary architecture - it's actually more a technical detail
where the builds are done. So we already consider it Fedora! It's not
going to change with ARM being primary.
It's not a secondary architecture because it's built on different build
infrastructure. It's built on different build infrastructure because
it's a secondary architecture, and being a secondary architecture means
we don't make the same guarantees to users.
From a practical point of view: how many of the proposed new features
for F20 would be absent from the ARM release? How are we going to
communicate that?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:01 a.m.
On Thu, Jul 11, 2013 at 01:23:21PM +0100, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 08:01:46AM -0400, Jaroslav Reznik wrote:
> But spins are Fedora, same as cloud image is still Fedora (and I don't
> see complaints it does not run Gnome Shell ;-). Desktop spin is one
> spin of the many spins but we promote it (for several reasons) more than
> others. So again - I don't see this as a problem with having ARM as PA
> (I can see other issues like HW availability, build times, resources) but
> having an ARM spin composed from primary builds with a DE that suits
> still limited resources on ARM machines - no problem at all. Even blocking
> desktop release criteria are fulfilled this way as we don't require for
> example LXDE spin to ship Gnome and KDE ;-).
If I download the Fedora installation media, boot it, select all the
defaults and then reboot into the installed system, I get a well-defined
outcome. If we promote ARM to primary and treat it in the same way, the
well-defined outcome will be different depending on whether I pick ARM
or x86.
If I go to fedoraproject.org, the first thing I see is a picture of
Gnome Shell with "Fedora 19" written underneath it. How do we deal with
that in the ARM case? Add a disclaimer indicating that if you pick this
outwardly identical install image for a different architecture, you'll
end up with something that looks entirely different?
> Almost-but-not-quite Fedora are remixes. Even now Fedora ARM is Fedora,
> just a secondary architecture - it's actually more a technical detail
> where the builds are done. So we already consider it Fedora! It's not
> going to change with ARM being primary.
It's not a secondary architecture because it's built on different build
infrastructure. It's built on different build infrastructure because
it's a secondary architecture, and being a secondary architecture means
we don't make the same guarantees to users.
From a practical point of view: how many of the proposed new features
for F20 would be absent from the ARM release? How are we going to
communicate that?
This (& alot of the issues raised in this thread) focus on different
user experiance / features as a reason to not promote ARM from
secondary to primary arch. As a user intending to install / use
Fedora ARM, is that distinction really visible though ? Fedora 19
ARM came out at the same time as Fedora 19 x86, it was fully branded
as Fedora. AFAIK, there was nothing communicated to users in the
F19 ARM announcement that indicates it is inferior to F19 x86 in
any of the ways mentioned in this thread, it gets updates issued
in the same way.
IOW as a end user of F19 ARM the primary / secondary arch distinction
is essentially invisible, unless they actively go looking for it. People
who want to use F19 ARM are going todo so regardless of whether it is a
primary or secondary arch. So if we block ARMs promotion to primary arch
because of lack of say, GNOME desktop, is that really going to have any
direct effect on users of F20 ARM ? I don't think so. In fact I think it
arguably harms users, because having it be a secondary arch discourages
maintainers of packages from getting involved & addressing issues on ARM.
IMHO valid reasons to block ARM from being promoted to primary arch are
things related to Fedora release process / package maintainence. eg the
problem of long build times is a reasonably valid arguemnt, or the lack
of access to hardware for troubleshooting problems, or lack of a formal
QA plan for testing ARM releases.
So back to your point of how we communicate that ARM lacks certain
features. I think that is simply a case of putting something in the
release notes, and we need to do that regardles of whether ARM is a
primary or secondary architecture, because that distinction is mostly
invisible to our users.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11:39 a.m.
On Thu, Jul 11, 2013 at 08:01:46AM -0400, Jaroslav Reznik wrote:
But spins are Fedora, same as cloud image is still Fedora (and I
don't
see complaints it does not run Gnome Shell ;-). Desktop spin is one
Not commenting on the bigger debate at this point, but I want to note that
you can, in fact, run Gnome Shell on top of the cloud image if you want.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:24 a.m.
On Thu, Jul 11, 2013 at 8:04 AM, Brendan Conoboy <blc(a)redhat.com> wrote:
Please consider the idea that there is a useful middle ground
"Primary" and
"Secondary".
With the FESCo-member-as-elected-by-contributors hat on, there really
isn't a middle: The individual packagers are either responsible for
making their package work on ARM or not.
It might be multidimensional:
Primary Desktop---Secondary Desktop
| |
Primary Server----Secondary Server
... and with the
FESCo-member-interacting-with-rel-eng-and-qa-and-others hat on, the
idea of a "server-only ARM release" is fairly plausible to me.
Mirek
9:27 a.m.
On Thu, Jul 11, 2013 at 16:24:49 +0200,
Miloslav Trmač <mitr(a)volny.cz> wrote:
On Thu, Jul 11, 2013 at 8:04 AM, Brendan Conoboy
<blc(a)redhat.com> wrote:
> Please consider the idea that there is a useful middle ground "Primary"
and
> "Secondary".
With the FESCo-member-as-elected-by-contributors hat on, there really
isn't a middle: The individual packagers are either responsible for
making their package work on ARM or not.
Being responsible for, doesn't have to mean having do all of the work for.
10:56 a.m.
On Wed, Jul 10, 2013 at 11:04:51PM -0700, Brendan Conoboy wrote:
The relentless "I don't want ARM to sully the good name of
Fedora" is
absurd: User for user, ARM is considerably more popular than Fedora.
No, this is completely wrong. It's entirely propaganda, and you need to
stop saying things like this in technical discussions. ARM is not popular
*at all* with any large group of people. Full stop. People like some
devices and dislike others, and they've got them both, and that has only
a very weak relationship with the fact that they have ARM cores in them,
even though there are plenty of them in those devices. Quit measuring
"popularity" based on number of deployed cores. It is all the way wrong,
especially given that we're not targetting even a very small percentage
of the devices you're talking about.
--
Peter
12:12 a.m.
On Wed, 2013-07-10 at 18:08 -0700, Brendan Conoboy wrote:
On 07/10/2013 02:25 PM, Adam Williamson wrote:
> No. The release blocking desktops are KDE and GNOME. This is stated in
> the preamble of all release criteria pages, for lack of anywhere better
> to state it.
If we were only proposing headless ARM servers for primary how would
these criteria apply? The changes to the build system would be the same
with our without these desktops in either case. Note I'm not asking
Adam specifically; it's a question for the room.
As I said elsewhere in the thread, the criteria should be subsidiary to
the primary arch designation. If we decide we want to take ARM as a
primary arch in any form in which the current release criteria don't
apply, we should amend the release criteria.
In context I was just providing some background information: as the
criteria currently stand, KDE and GNOME are the release blocking
desktops. (Technically that in itself isn't really an aspect of the
release criteria; it's Fedora status quo that predates the current form
of the release validation process).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:18 a.m.
On 07/10/2013 10:12 PM, Adam Williamson wrote:
As I said elsewhere in the thread, the criteria should be subsidiary
to
the primary arch designation. If we decide we want to take ARM as a
primary arch in any form in which the current release criteria don't
apply, we should amend the release criteria.
In context I was just providing some background information: as the
criteria currently stand, KDE and GNOME are the release blocking
desktops. (Technically that in itself isn't really an aspect of the
release criteria; it's Fedora status quo that predates the current form
of the release validation process).
Yeah, it seems like a foregone conclusion that release criteria would
need to be modified. I don't think the current proposal includes this,
but perhaps it should. Realistically what's going to be needed is some
form of granularity on "primary". At first blush I like the idea of a
"primary server" and "primary desktop" designation (maintaining a
unified build system) but haven't thought the full consequences through.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
1:25 a.m.
On Wed, 2013-07-10 at 23:18 -0700, Brendan Conoboy wrote:
On 07/10/2013 10:12 PM, Adam Williamson wrote:
> As I said elsewhere in the thread, the criteria should be subsidiary to
> the primary arch designation. If we decide we want to take ARM as a
> primary arch in any form in which the current release criteria don't
> apply, we should amend the release criteria.
>
> In context I was just providing some background information: as the
> criteria currently stand, KDE and GNOME are the release blocking
> desktops. (Technically that in itself isn't really an aspect of the
> release criteria; it's Fedora status quo that predates the current form
> of the release validation process).
Yeah, it seems like a foregone conclusion that release criteria would
need to be modified. I don't think the current proposal includes this,
but perhaps it should. Realistically what's going to be needed is some
form of granularity on "primary". At first blush I like the idea of a
"primary server" and "primary desktop" designation (maintaining a
unified build system) but haven't thought the full consequences through.
The required change is not, in fact, necessarily that dramatic, as I
mentioned earlier in the thread. As written, the release criteria do not
explicitly require that the release-blocking desktops work on all
primary architectures. They just talk about things that are required to
work within the desktops themselves.
What would actually need to change for ARM, I think, are just the very
early criteria and preamble, where we have this stuff:
"The term 'release-blocking images' means all the images in which bugs
are currently considered capable of blocking a Fedora release. The
current set of release-blocking images includes the network install
image, the DVD image, and the live images for each of the
release-blocking desktops."
"All release-blocking images must boot in their supported
configurations.", with a bunch of footnotes about what that means
precisely.
I think we could make relatively minor tweaks to those bits - obviously,
we would extend the list of 'release-blocking images', which functions
as a very concise 'deliverables' list - and maybe make it a bit clearer
in the footnotes to the 'initialization requirements' criteria exactly
what behaviour is required from those images. That would really be all
that would be necessary, I think. We _could_ explain specifically in the
preamble that certain criteria are not relevant to certain arches, if we
wanted to.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:18 p.m.
On Wed, 2013-07-10 at 23:25 -0700, Adam Williamson wrote:
On Wed, 2013-07-10 at 23:18 -0700, Brendan Conoboy wrote:
> On 07/10/2013 10:12 PM, Adam Williamson wrote:
> > As I said elsewhere in the thread, the criteria should be subsidiary to
> > the primary arch designation. If we decide we want to take ARM as a
> > primary arch in any form in which the current release criteria don't
> > apply, we should amend the release criteria.
> >
> > In context I was just providing some background information: as the
> > criteria currently stand, KDE and GNOME are the release blocking
> > desktops. (Technically that in itself isn't really an aspect of the
> > release criteria; it's Fedora status quo that predates the current form
> > of the release validation process).
>
> Yeah, it seems like a foregone conclusion that release criteria would
> need to be modified. I don't think the current proposal includes this,
> but perhaps it should. Realistically what's going to be needed is some
> form of granularity on "primary". At first blush I like the idea of a
> "primary server" and "primary desktop" designation (maintaining
a
> unified build system) but haven't thought the full consequences through.
The required change is not, in fact, necessarily that dramatic, as I
mentioned earlier in the thread. As written, the release criteria do not
explicitly require that the release-blocking desktops work on all
primary architectures. They just talk about things that are required to
work within the desktops themselves.
What would actually need to change for ARM, I think, are just the very
early criteria and preamble, where we have this stuff:
"The term 'release-blocking images' means all the images in which bugs
are currently considered capable of blocking a Fedora release. The
current set of release-blocking images includes the network install
image, the DVD image, and the live images for each of the
release-blocking desktops."
"All release-blocking images must boot in their supported
configurations.", with a bunch of footnotes about what that means
precisely.
I think we could make relatively minor tweaks to those bits - obviously,
we would extend the list of 'release-blocking images', which functions
as a very concise 'deliverables' list - and maybe make it a bit clearer
in the footnotes to the 'initialization requirements' criteria exactly
what behaviour is required from those images. That would really be all
that would be necessary, I think. We _could_ explain specifically in the
preamble that certain criteria are not relevant to certain arches, if we
wanted to.
Following today's FESCo decision, I have created a QA trac ticket to
co-ordinate this:
https://fedorahosted.org/fedora-qa/ticket/393
interested parties please feel free to CC yourselves and contribute any
suggested changes / extensions to the above plan there. I'll aim to try
and propose some changes as described above for later this week or early
next week on test@: that is the list where release criteria revision
usually takes place, so please subscribe to that if you're interested in
following the process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:21 p.m.
On Wed, 2013-07-17 at 15:18 -0700, Adam Williamson wrote:
Following today's FESCo decision, I have created a QA trac ticket
to
co-ordinate this:
https://fedorahosted.org/fedora-qa/ticket/393
interested parties please feel free to CC yourselves and contribute any
suggested changes / extensions to the above plan there. I'll aim to try
and propose some changes as described above for later this week or early
next week on test@: that is the list where release criteria revision
usually takes place, so please subscribe to that if you're interested in
following the process.
Also filed https://fedorahosted.org/fedora-qa/ticket/394 for
corresponding changes to the release validation process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:29 a.m.
On Wed, Jul 10, 2013 at 06:02:57AM -0400, Jaroslav Reznik wrote:
I don't see a problem with different set of blocking desktops for
ARM, even
as primary architecture. But it's really about resources - do we have people
willing to work for example on LXDE (I'd say more resources friendly for
current ARMs) - not saying there are no people, but more to support it as
blocking desktop, if QA would be able to validate three desktops on two
different platforms... And as we try to avoid "default" world in Fedora now,
let's have LXDE "default" in some cases.
I do. Fedora is a Linux distribution that has a specific set of software
available, and runs a specific desktop by default. We have a process
whereby people can produce Fedora variants with different defaults, and
we release those as spins. If ARM wants to be *Fedora*, it should behave
identically to the other Fedora architectures. If ARM merely wants to be
able to produce something that's similar to Fedora then we should figure
out what a spin-based PA would look like, but that's not what's
currently being proposed.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:47 a.m.
On Jul 10, 2013, at 8:29 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
If ARM merely wants to be
able to produce something that's similar to Fedora then we should figure
out what a spin-based PA would look like, but that's not what's
currently being proposed.
For F20, this makes more sense to me as a next step, before going whole hog with all
release blocking desktops. Seems like the latter is a lot of chew off for F20. I think
more community maturation is needed to get both dev and QA capable users, who also have an
appropriate range of hardware, to support the new platform. It sounds like the existing
community would be eyeballs deep.
Chris Murphy
8:56 a.m.
On 07/10/2013 12:36 AM, Bill Nottingham wrote:
Plus, in relation to this - the llvmpipe issue brings up that one of
the 'release blocking desktops'*does not work*. This would, by definition,
block the release unless we intend to have different criteria for ARM as a
primary arch.
Then we should remove the default label and "release blocking
desktop(s)" entirely concept with it.
It's far outdated anyway and relic from the past.
Each sub-community ( be it spins be it various arch ) should need to
provide the necessary QA/Releng resources from their sub-community ( if
no such thing the relevant party needs to build one ) while we QA and
Releng focus our available resources on the components that everyone in
the whole distribution use and provide the necessary sub community with
the assistance in relation to QA and Releng.
Outside of that, how might we expect release criteria to change for
ARM,
given the different deliverables that are planned?
It's pretty self explanatory if you dont use "anaconda" or rather an
installer of some sort then those criteria items dont apply to your
arch or spin for that matter so fourth and so on so the release criteria
should be applicable in it's current form and be applied by relevance
regardless of the hardware or hardware architecture being used, If it's
not that's we need to adapt/adjust the criteria to those limitations.
JBG
4:28 p.m.
On Wed, 2013-07-10 at 13:56 +0000, "Jóhann B. Guðmundsson" wrote:
On 07/10/2013 12:36 AM, Bill Nottingham wrote:
> Plus, in relation to this - the llvmpipe issue brings up that one of
> the 'release blocking desktops' *does not work*. This would, by definition,
> block the release unless we intend to have different criteria for ARM as a
> primary arch.
Then we should remove the default label and "release blocking
desktop(s)" entirely concept with it.
It's far outdated anyway and relic from the past.
Each sub-community ( be it spins be it various arch ) should need to
provide the necessary QA/Releng resources from their sub-community
( if no such thing the relevant party needs to build one ) while we QA
and Releng focus our available resources on the components that
everyone in the whole distribution use and provide the necessary sub
community with the assistance in relation to QA and Releng.
I'm afraid I can't agree. I like the simplicity of the model you're
proposing, but from a practical point of view, there is still a commonly
held perception that there is a 'product' called Fedora which is
basically composed of what you get if you go to get.fedoraproject.org,
download one of the things we push at you there, and install it.
Practically speaking, I believe we have to QA that 'thing called Fedora'
as a whole. I don't think your model quite matches what people perceive
Fedora to be.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:17 a.m.
On 07/10/2013 09:28 PM, Adam Williamson wrote:
On Wed, 2013-07-10 at 13:56 +0000, "Jóhann B. Guðmundsson"
wrote:
> >On 07/10/2013 12:36 AM, Bill Nottingham wrote:
> >
>> > >Plus, in relation to this - the llvmpipe issue brings up that one of
>> > >the 'release blocking desktops'*does not work*. This would, by
definition,
>> > >block the release unless we intend to have different criteria for ARM as
a
>> > >primary arch.
> >
> >Then we should remove the default label and "release blocking
> >desktop(s)" entirely concept with it.
> >
> >It's far outdated anyway and relic from the past.
> >
> >Each sub-community ( be it spins be it various arch ) should need to
> >provide the necessary QA/Releng resources from their sub-community
> >( if no such thing the relevant party needs to build one ) while we QA
> >and Releng focus our available resources on the components that
> >everyone in the whole distribution use and provide the necessary sub
> >community with the assistance in relation to QA and Releng.
I'm afraid I can't agree. I like the simplicity of the model you're
proposing, but from a practical point of view, there is still a commonly
held perception that there is a 'product' called Fedora which is
basically composed of what you get if you go to get.fedoraproject.org,
download one of the things we push at you there, and install it.
Practically speaking, I believe we have to QA that 'thing called Fedora'
as a whole. I don't think your model quite matches what people perceive
Fedora to be.
What's your definition of what people perceive Fedora to be?
Regardless of peoples perception or what you think they are there still
would be products however we QA would take care of the installer +
base/core os bits and sub-communities that build upon that base/core OS
like Gnome takes care of QA their own spins.
Who better are to QA their own spin then the people that a) use it b)
create it c) release it?
JBG
1:21 p.m.
"Jóhann B. Guðmundsson" píše v Čt 11. 07. 2013 v 09:17 +0000:
On 07/10/2013 09:28 PM, Adam Williamson wrote:
> On Wed, 2013-07-10 at 13:56 +0000, "Jóhann B. Guðmundsson" wrote:
> > > On 07/10/2013 12:36 AM, Bill Nottingham wrote:
> > >
> > > > > Plus, in relation to this - the llvmpipe issue brings up that
one of
> > > > > the 'release blocking desktops' *does not work*. This
would, by definition,
> > > > > block the release unless we intend to have different criteria
for ARM as a
> > > > > primary arch.
> > >
> > > Then we should remove the default label and "release blocking
> > > desktop(s)" entirely concept with it.
> > >
> > > It's far outdated anyway and relic from the past.
> > >
> > > Each sub-community ( be it spins be it various arch ) should need to
> > > provide the necessary QA/Releng resources from their sub-community
> > > ( if no such thing the relevant party needs to build one ) while we QA
> > > and Releng focus our available resources on the components that
> > > everyone in the whole distribution use and provide the necessary sub
> > > community with the assistance in relation to QA and Releng.
> I'm afraid I can't agree. I like the simplicity of the model you're
> proposing, but from a practical point of view, there is still a commonly
> held perception that there is a 'product' called Fedora which is
> basically composed of what you get if you go to get.fedoraproject.org,
> download one of the things we push at you there, and install it.
> Practically speaking, I believe we have to QA that 'thing called Fedora'
> as a whole. I don't think your model quite matches what people perceive
> Fedora to be.
What's your definition of what people perceive Fedora to be?
Regardless of peoples perception or what you think they are there
still would be products however we QA would take care of the installer
+ base/core os bits and sub-communities that build upon that base/core
OS like Gnome takes care of QA their own spins.
Who better are to QA their own spin then the people that a) use it b)
create it c) release it?
Have you ever reached to these sub-communities and asked them if they
are interested in something like this? Because I'm not sure whether
they're and forcing something like this upon them is not the best idea.
First I think keeping the QA know-how in one team actually has a lot of
benefits.
Second I don't think that the sub-communities or spins, if you will,
have enough manpower and expertize to run their own QA teams.
The current team of Fedora testers is rather small and dividing them
into several more teams would lead to a subcritical number of testers to
run a functional QA.
Third I don't agree with the opinion that people who create the software
are the best people to test it. Quite the opposite. Having a QA team
independent on spins is actually a very good idea. I have witnessed a
lot of situations where developers were too lazy/busy/... to fix serious
problems and it was pertinacity of our independent QA team that forced
them to fix the problems although it sometimes took an escalation to
FESCo. I highly doubt that spin's QA teams would develop into such
independent entities.
Jiri
1:58 p.m.
On 07/11/2013 06:21 PM, Jiri Eischmann wrote:
Have you ever reached to these sub-communities and asked them if
they
are interested in something like this?
In relation to the desktop environments the community surrounding them
have been following the criteria and doing their testing by themselves
with the exception of Gnome of course which we in the QA community have
had to carry from the get go on top of everything else
Because I'm not sure whether
they're and forcing something like this upon them is not the best idea.
We never forced that upon anyone members from those communities ( with
the exception of Gnome ) stepped up walked in and wanted to do it.
First I think keeping the QA know-how in one team actually has a lot
of
benefits.
In one community yes in one team no.
Second I don't think that the sub-communities or spins, if you
will,
have enough manpower and expertize to run their own QA teams.
But you somehow think we in QA or releng for that matter do?
The current team of Fedora testers is rather small and dividing them
into several more teams would lead to a subcritical number of testers to
run a functional QA.
Nobody was talking about diving into the existing reporters base in the
QA community.
Third I don't agree with the opinion that people who create the
software
are the best people to test it.
People that *use* and create the software.
Quite the opposite. Having a QA team
independent on spins is actually a very good idea.
No it's not.
I have witnessed a
lot of situations where developers were too lazy/busy/... to fix serious
problems and it was pertinacity of our independent QA team that forced
them to fix the problems although it sometimes took an escalation to
FESCo.
Really when?
I highly doubt that spin's QA teams would develop into such
independent entities.
Those spins that do not have enough manpower die off which is to be
expected and part of healthy self cleansing process in the project
instead of things as they are now where releng needs to basically try to
carry them alive and working.
JBG
3:44 p.m.
On Thu, 2013-07-11 at 18:58 +0000, "Jóhann B. Guðmundsson" wrote:
On 07/11/2013 06:21 PM, Jiri Eischmann wrote:
> Have you ever reached to these sub-communities and asked them if they
> are interested in something like this?
In relation to the desktop environments the community surrounding them
have been following the criteria and doing their testing by themselves
with the exception of Gnome of course which we in the QA community have
had to carry from the get go on top of everything else
Actually, we are technically responsible for the KDE testing as well. In
practice, some KDE testing tends to come from the KDE SIG, some from QA
(I do quite a bit). I (as a QA group member) also did some testing of
LXDE, Xfce, Sugar, Cinnamon and MATE for F19.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:53 p.m.
On Thu, 2013-07-11 at 09:17 +0000, "Jóhann B. Guðmundsson" wrote:
> I'm afraid I can't agree. I like the simplicity of the
model you're
> proposing, but from a practical point of view, there is still a commonly
> held perception that there is a 'product' called Fedora which is
> basically composed of what you get if you go to get.fedoraproject.org,
> download one of the things we push at you there, and install it.
> Practically speaking, I believe we have to QA that 'thing called Fedora'
> as a whole. I don't think your model quite matches what people perceive
> Fedora to be.
What's your definition of what people perceive Fedora to be?
"What do we talk about when we talk about Fedora?" :)
Well, we just did a major release. Go look on news.google.com for
"Fedora 19", or search for "Fedora 19 review", or just poke through a
few popular tech sites and forums.
What do people do when they want to 'try Fedora 19'? They download the
primary image on the download page, which is the desktop live, and run
it. This is what they've _always_ done.
Do you ever see anyone doing a minimal install and commenting on the
package loadout? Commenting on the actual interesting and difficult
technical changes that are what a distribution really does? No, they run
the live image for a couple of days, decide whether they think the
desktop background looks nice, say whether they liked the installer, and
bash GNOME 3 for a while.
If we're really, really lucky they'll mention there are some other spins
available. In passing. Without ever downloading one. And that's about
it.
Regardless of peoples perception or what you think they are there
still would be products however we QA would take care of the installer
+ base/core os bits and sub-communities that build upon that base/core
OS like Gnome takes care of QA their own spins.
Who better are to QA their own spin then the people that a) use it b)
create it c) release it?
People who want to do QA? I mean, that's why we have a QA team. You've
been around longer than I have, but so far as I recall, the QA team has
always been about doing more than simply testing the core OS.
I must also confess to a personal interest here: if I'm expected to
spend the rest of my professional life doing nothing but testing the
goddamn installer I think I'll quit and start a yak farm. Is that really
what you want us to do forever and ever amen? Apart from anything else,
I find it *interesting* and *useful* to work on desktop testing...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:37 a.m.
On 07/11/2013 07:53 PM, Adam Williamson wrote:
> What's your definition of what people perceive Fedora to be?
"What do we talk about when we talk about Fedora?":)
Well, we just did a major release. Go look on news.google.com for
"Fedora 19", or search for "Fedora 19 review", or just poke through
a
few popular tech sites and forums.
What do people do when they want to 'try Fedora 19'? They download the
primary image on the download page, which is the desktop live, and run
it. This is what they've_always_ done.
Do you ever see anyone doing a minimal install and commenting on the
package loadout? Commenting on the actual interesting and difficult
technical changes that are what a distribution really does? No, they run
the live image for a couple of days, decide whether they think the
desktop background looks nice, say whether they liked the installer, and
bash GNOME 3 for a while.
If we're really, really lucky they'll mention there are some other spins
available. In passing. Without ever downloading one. And that's about
it.
That's presentation issue no more no less.
Instead of actually providing our sub-communities with their own 3rd
level domain under fedoraproject.org ( <sub-community>.fedoraproject.org
) which each include news,presentation download button for their
release. We decide to belittle every sub-communites work and present
only one.
> >Regardless of peoples perception or what you think they are
there
> >still would be products however we QA would take care of the installer
> >+ base/core os bits and sub-communities that build upon that base/core
> >OS like Gnome takes care of QA their own spins.
> >
> >Who better are to QA their own spin then the people that a) use it b)
> >create it c) release it?
People who want to do QA? I mean, that's why we have a QA team. You've
been around longer than I have, but so far as I recall, the QA team has
always been about doing more than simply testing the core OS.
That's news to me anything else you want to share from the past which
actually does not align with what got discussed and done in that era of
"/Just do it"/.
We always have been focusing on the installer and core components which
is the primary function of QA as in to provide an installable and well
working base os for others to build upon.
You yourself know that the installer is the nr.1 cause for slippage and
resource consumption from the QA community but if you rather want to
play desktop testing instead of focusing on the things that actually
matters to everyone in the community like the installer which install
the components and allows users to use that desktop fine that's your choice.
I must also confess to a personal interest here: if I'm expected to
spend the rest of my professional life doing nothing but testing the
goddamn installer I think I'll quit and start a yak farm. Is that really
what you want us to do forever and ever amen? Apart from anything else,
I find it*interesting* and*useful* to work on desktop testing...
I have absolutely no idea what RH expects of you or wants you to do you
as part of your job but if you want to click through Gnome instead of
Anaconda it is fine and nobody is saying you should not do that just
join their community and help them.
If you want to change profession and start your own yak farm go ahead do
it but that's just something you have to make up with yourself.
JBG
10:24 p.m.
On Thu, Jul 11, 2013 at 12:53:23PM -0700, Adam Williamson wrote:
"What do we talk about when we talk about Fedora?" :)
Well, we just did a major release. Go look on news.google.com for
"Fedora 19", or search for "Fedora 19 review", or just poke through
a
few popular tech sites and forums.
What do people do when they want to 'try Fedora 19'? They download the
primary image on the download page, which is the desktop live, and run
it. This is what they've _always_ done.
Well, this is partly self-reinforcing, because it's what we clearly tell
people to do. See http://fedoraproject.org/get-fedora, or the Download Now
link on the front page.
Soooo, speaking of which:
https://fedoraproject.org/wiki/Changes/VisibleCloud
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4 a.m.
Matthew Miller píše v Pá 12. 07. 2013 v 23:24 -0400:
On Thu, Jul 11, 2013 at 12:53:23PM -0700, Adam Williamson wrote:
> "What do we talk about when we talk about Fedora?" :)
> Well, we just did a major release. Go look on news.google.com for
> "Fedora 19", or search for "Fedora 19 review", or just poke
through a
> few popular tech sites and forums.
> What do people do when they want to 'try Fedora 19'? They download the
> primary image on the download page, which is the desktop live, and run
> it. This is what they've _always_ done.
Well, this is partly self-reinforcing, because it's what we clearly tell
people to do. See http://fedoraproject.org/get-fedora, or the Download Now
link on the front page.
Soooo, speaking of which:
https://fedoraproject.org/wiki/Changes/VisibleCloud
I think this is mixing up things together a bit. I don't think no one
thinks we can create an ISO that would work perfectly for all uses
(desktop, server, cloud,...).
IMHO the ideal situation should be: A user interested in Fedora goes to
fedoraproject.org and is asked "Do you want to run Fedora as desktop,
server or a cloud instance?" and each answer should give them one ISO,
the official default product of Fedora Project for that use.
But that doesn't mean we should overwhelm them with gazillion options
for every use.
So it's ok to have a cloud version to download at
http://fedoraproject.org/get-fedora but I think we want to offer them
just one product for cloud, the one we're focused on the most, we test
the most, not all flavours we could possibly have: Matthew's compilation
for cloud, Joe's compilation for cloud,...
And the same applies to other uses such as desktop.
Jiri
11:08 a.m.
On Mon, Jul 15, 2013 at 11:00:32AM +0200, Jiri Eischmann wrote:
> Soooo, speaking of which:
> https://fedoraproject.org/wiki/Changes/VisibleCloud
I think this is mixing up things together a bit. I don't think no one
thinks we can create an ISO that would work perfectly for all uses
(desktop, server, cloud,...).
IMHO the ideal situation should be: A user interested in Fedora goes to
fedoraproject.org and is asked "Do you want to run Fedora as desktop,
server or a cloud instance?" and each answer should give them one ISO,
the official default product of Fedora Project for that use.
Yes, that's what I'm trying to suggest. (Well, just desktop and cloud; we'll
leave traditional server aside for right now.) If it _doesn't_ look like
that's what my proposal is suggesting, please let me know how and where I
can fix it.
So it's ok to have a cloud version to download at
http://fedoraproject.org/get-fedora but I think we want to offer them
just one product for cloud, the one we're focused on the most, we test
the most, not all flavours we could possibly have: Matthew's compilation
for cloud, Joe's compilation for cloud,...
What we're offering right now is the same image -- same bits on disk -- in
different formats. Not different spins. There's significant advantage in
having a run-in-every-cloud image and we're bending as much as possible to
make it so.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
4:42 p.m.
On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2013-07-11 at 09:17 +0000, "Jóhann B. Guðmundsson"
wrote:
> > I'm afraid I can't agree. I like the simplicity of the model you're
> > proposing, but from a practical point of view, there is still a commonly
> > held perception that there is a 'product' called Fedora which is
> > basically composed of what you get if you go to get.fedoraproject.org,
> > download one of the things we push at you there, and install it.
> > Practically speaking, I believe we have to QA that 'thing called
Fedora'
> > as a whole. I don't think your model quite matches what people perceive
> > Fedora to be.
>
> What's your definition of what people perceive Fedora to be?
"What do we talk about when we talk about Fedora?" :)
Well, we just did a major release. Go look on news.google.com for
"Fedora 19", or search for "Fedora 19 review", or just poke through
a
few popular tech sites and forums.
What do people do when they want to 'try Fedora 19'? They download the
primary image on the download page, which is the desktop live, and run
it. This is what they've _always_ done.
Hmm I wouldn't be surprised if we had more Fedora users running on
cloud instances now than we do on the desktop but there's no way to
tell really.
Do you ever see anyone doing a minimal install and commenting on the
package loadout? Commenting on the actual interesting and difficult
technical changes that are what a distribution really does? No, they run
the live image for a couple of days, decide whether they think the
desktop background looks nice, say whether they liked the installer, and
bash GNOME 3 for a while.
Or they run it in the cloud where it mostly just works and they don't
give a hoot about a 10 year support cycle because their spun up image
in some cases barely last 10 days and get on with their job and don't
say a thing :-P
If we're really, really lucky they'll mention there are some
other spins
available. In passing. Without ever downloading one. And that's about
it.
Agree!
4:55 p.m.
On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Thu, 2013-07-11 at 09:17 +0000, "Jóhann B. Guðmundsson" wrote:
>
>> > I'm afraid I can't agree. I like the simplicity of the model
you're
>> > proposing, but from a practical point of view, there is still a commonly
>> > held perception that there is a 'product' called Fedora which is
>> > basically composed of what you get if you go to get.fedoraproject.org,
>> > download one of the things we push at you there, and install it.
>> > Practically speaking, I believe we have to QA that 'thing called
Fedora'
>> > as a whole. I don't think your model quite matches what people
perceive
>> > Fedora to be.
>>
>> What's your definition of what people perceive Fedora to be?
>
> "What do we talk about when we talk about Fedora?" :)
>
> Well, we just did a major release. Go look on news.google.com for
> "Fedora 19", or search for "Fedora 19 review", or just poke
through a
> few popular tech sites and forums.
>
> What do people do when they want to 'try Fedora 19'? They download the
> primary image on the download page, which is the desktop live, and run
> it. This is what they've _always_ done.
Hmm I wouldn't be surprised if we had more Fedora users running on
cloud instances now than we do on the desktop but there's no way to
tell really.
Might be the sites I'm reading, but I have yet to see a single post
anywhere even mentioning the cloud image, while I've replied to dozens
of posts of people testing the desktop live.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:14 p.m.
On Tue, Jul 16, 2013 at 10:55 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote:
> On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Thu, 2013-07-11 at 09:17 +0000, "Jóhann B. Guðmundsson" wrote:
> >
> >> > I'm afraid I can't agree. I like the simplicity of the model
you're
> >> > proposing, but from a practical point of view, there is still a
commonly
> >> > held perception that there is a 'product' called Fedora which
is
> >> > basically composed of what you get if you go to get.fedoraproject.org,
> >> > download one of the things we push at you there, and install it.
> >> > Practically speaking, I believe we have to QA that 'thing called
Fedora'
> >> > as a whole. I don't think your model quite matches what people
perceive
> >> > Fedora to be.
> >>
> >> What's your definition of what people perceive Fedora to be?
> >
> > "What do we talk about when we talk about Fedora?" :)
> >
> > Well, we just did a major release. Go look on news.google.com for
> > "Fedora 19", or search for "Fedora 19 review", or just poke
through a
> > few popular tech sites and forums.
> >
> > What do people do when they want to 'try Fedora 19'? They download the
> > primary image on the download page, which is the desktop live, and run
> > it. This is what they've _always_ done.
>
> Hmm I wouldn't be surprised if we had more Fedora users running on
> cloud instances now than we do on the desktop but there's no way to
> tell really.
Might be the sites I'm reading, but I have yet to see a single post
anywhere even mentioning the cloud image, while I've replied to dozens
of posts of people testing the desktop live.
Well it's live on at least amazon and rackspace so who would know
Peter
9:04 a.m.
On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
Each sub-community ( be it spins be it various arch ) should need to
provide
the necessary QA/Releng resources from their sub-community ( if no such
thing the relevant party needs to build one )
That would be interesting and quite possibly very beneficial, however
the transition from the current system when most people "don't need to
care" would be a complex, longer-term cultural shift that shouldn't be
(and doesn't really need to be) a blocker for the ARM feature.
Mirek
1:06 p.m.
On 07/11/2013 02:04 PM, Miloslav Trmač wrote:
On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> Each sub-community ( be it spins be it various arch ) should need to provide
> the necessary QA/Releng resources from their sub-community ( if no such
> thing the relevant party needs to build one )
That would be interesting and quite possibly very beneficial, however
the transition from the current system when most people "don't need to
care" would be a complex, longer-term cultural shift that shouldn't be
(and doesn't really need to be) a blocker for the ARM feature.
Right the biggest one being the old outdated mindset that got created in
the birth of the distribution when the packageset was only fraction of
what it is today is the biggest hurdle to overcome as well as changing
the mindset of those that think Fedora is nothing more then "Gnome 3
with custom wallpaper" and try to force that vision upon all
architecture,sub-communities and their users.
This most definitely is not something we would achieve over night but is
more something that will take us few release cycle to implement.
I dont argue that this should be a blocker for architectures quite the
opposite as far as I see it the only requirement for an architecture to
be come a "primary" ( thou arguably those are outdated concepts as well
) is that all package currently build ( with the execption if they
simply cannot work on a spesific architecture ) and be available for the
community to use as lego bricks to shape and present to the world as
they image in for that relevant hw.
JBG
7:08 a.m.
On Thu, Jul 11, 2013 at 06:06:04PM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/11/2013 02:04 PM, Miloslav Trmač wrote:
>On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson"
><johannbg(a)gmail.com> wrote:
>>Each sub-community ( be it spins be it various arch ) should need to provide
>>the necessary QA/Releng resources from their sub-community ( if no such
>>thing the relevant party needs to build one )
>That would be interesting and quite possibly very beneficial, however
>the transition from the current system when most people "don't need to
>care" would be a complex, longer-term cultural shift that shouldn't be
>(and doesn't really need to be) a blocker for the ARM feature.
I dont argue that this should be a blocker for architectures quite
the opposite as far as I see it the only requirement for an
architecture to be come a "primary" ( thou arguably those are
outdated concepts as well ) is that all package currently build (
with the execption if they simply cannot work on a spesific
architecture ) and be available for the community to use as lego
bricks to shape and present to the world as they image in for that
relevant hw.
It is only a few weeks you argued that we should drop all packages that
are not "properly maintained". Before that, you wanted to limit the
number of packages a person can maintain, (by your words) to ensure that
he (or she) has enough time to maintain them. Now you think it is a good
idea to add a whole new architecture, which means additional maintenance
load for _every_ package. Could you try to be at least a bit consistent?
D.
9:17 a.m.
On 07/12/2013 12:08 PM, David Tardon wrote:
> I dont argue that this should be a blocker for architectures
quite
> >the opposite as far as I see it the only requirement for an
> >architecture to be come a "primary" ( thou arguably those are
> >outdated concepts as well ) is that all package currently build (
> >with the execption if they simply cannot work on a spesific
> >architecture ) and be available for the community to use as lego
> >bricks to shape and present to the world as they image in for that
> >relevant hw.
It is only a few weeks you argued that we should drop all packages that
are not "properly maintained". Before that, you wanted to limit the
number of packages a person can maintain, (by your words) to ensure that
he (or she) has enough time to maintain them. Now you think it is a good
idea to add a whole new architecture, which means additional maintenance
load for_every_ package. Could you try to be at least a bit consistent?
I still think...
We should drop all packages that are not "properly maintained" since it
affect many communities including the hardware architects ones since
they would have ensure those packages that are not "properly maintained"
would build for their architecture before they would become an primary
architecture.
I would think their time in the project would be better spent on
components that are actively maintained but you apparently dont.
I still think...
We should limit the number of packages that individuals can maintain so
that they can effectively maintain them and as has been pointed out many
times with the arm architecture sub community that they are willing to
help with arm specific bugs not general ones bug the ones but let's
assume they don't which results in higher maintenance on the relevant
component which would results in fewer components that individual could
maintain since it would take more if his or her time to maintain it.
If you dont think maintainers are already overburden and them being so
does not directly affect not only those maintainers directly but also
the community in whole, let's just take Peter Jones for an example an
newly re-elected FESCO member.
Not only does he not respond to bug reports like [1] but he also ignores
infrastructures tools [2] that exist for the sole purpose to notify
maintainers about new upstream releases ( and this is just one of his
components which has 18 bugs assigned to it by my account ) but he
thinks he has enough time to serve on fesco at the same time which
requires him to do at least research into at least each ticket filed in
the fesco tracker and review of system wide features and how ack/nack
those features will affect the community in whole.
Do you honestly think this is healthy for him or for the project in whole?
My solution to address problem like this and prevent "burnouts" in the
project ( although not officially concreted and proposed ) is that we
implement a form of a time share program for the project ( which
arguably should not be limited to package maintenance since this in
essence does affect all participants in the project ) and maintainers
simple sign in how much free time they have or are willing to spare
daily/weekly/monthly in the project and based on those free hours he or
she has, we should be able to calculate how many components he or she
can maintain which could be one if it has an high maintenance burden or
10, 20 100 with low maintenance.
As more sign up to co-maintain component the more free time do the
existing maintainers get, which they in turn can use to (co ) maintain
another component or spend elsewhere in the project.
Implementing something like this would have significantly reduce the
number of components we have available with the increased stability and
not only healthier project but healthier participants as well.
In any case i'm not following how I was somehow being "inconsistent"
with myself with my response and if you have any proposal to solve the
previous mentioned problem in the distribution I'm all ears.
JBG
1. https://bugzilla.redhat.com/show_bug.cgi?id=949328
2. https://bugzilla.redhat.com/show_bug.cgi?id=869540
9:37 a.m.
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B. Guðmundsson" wrote:
Often, people maintain a package because it's required for a certain use
case they have not necessarily for particular love for that package. That's
not the idea situation, but it's better than not having the package at all,
and crucially, it means the actual use case that someone cares about is
covered.
I'm sure Peter would be happy to have a co-maintainer for the syslinux
package. I'd volunteer, but I'm actually _also_ only interested in a small
subset of functionality and am not able to address the bigger picture
either. But if someone would show up and really want to do it justice,
*awesome*.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:50 a.m.
On Fri, Jul 12, 2013 at 10:37:41AM -0400, Matthew Miller wrote:
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B.
Guðmundsson" wrote:
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540
Often, people maintain a package because it's required for a certain use
case they have not necessarily for particular love for that package. That's
not the idea situation, but it's better than not having the package at all,
and crucially, it means the actual use case that someone cares about is
covered.
I'm sure Peter would be happy to have a co-maintainer for the syslinux
package. I'd volunteer, but I'm actually _also_ only interested in a small
subset of functionality and am not able to address the bigger picture
either. But if someone would show up and really want to do it justice,
*awesome*.
FWIW, right now we can't update to 6.01 until we move to gnu-efi-3.0t,
which we haven't done because there's some debugging which needs to be
done there to avoid breaking the other packages that use it. It is on
the radar, and something I hope to address in the next few weeks, with
any luck. That said, this stuff is notoriously hard to debug, as you
may have noticed.
--
Peter
5:24 p.m.
On Fri, Jul 12, 2013 at 3:37 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B.
Guðmundsson" wrote:
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540
Often, people maintain a package because it's required for a certain use
case they have not necessarily for particular love for that package. That's
not the idea situation, but it's better than not having the package at all,
and crucially, it means the actual use case that someone cares about is
covered.
Really? There's packages that have been built once and never updated
that have CVEs and bugs that the "maintainer" never deals with. The
vast majority of ARM build "issues" I've dealt with aren't ARM issues
at all. They're maintainers not fixing problems or updating their own
packages and when ever I fix a problem with a package with ARM
problems I check the bugs and build problems against mainline and in
the vast majority of cases the problems on ARM are actually problems
on x86.
I'm sure Peter would be happy to have a co-maintainer for the
syslinux
package. I'd volunteer, but I'm actually _also_ only interested in a small
subset of functionality and am not able to address the bigger picture
either. But if someone would show up and really want to do it justice,
*awesome*.
So in a lot of cases ARM is only interested in a small subset of cases
but I still fix other issues. Other maintainers pick up packages
because they're only interested in a subset. I'll use llvm as an
example here because ajax has openly said he's only interested in a
subset and he openly quoted it earlier in the thread.
Peter
2:42 a.m.
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/12/2013 12:08 PM, David Tardon wrote:
>>I dont argue that this should be a blocker for architectures quite
>>>the opposite as far as I see it the only requirement for an
>>>architecture to be come a "primary" ( thou arguably those are
>>>outdated concepts as well ) is that all package currently build (
>>>with the execption if they simply cannot work on a spesific
>>>architecture ) and be available for the community to use as lego
>>>bricks to shape and present to the world as they image in for that
>>>relevant hw.
>It is only a few weeks you argued that we should drop all packages that
>are not "properly maintained". Before that, you wanted to limit the
>number of packages a person can maintain, (by your words) to ensure that
>he (or she) has enough time to maintain them. Now you think it is a good
>idea to add a whole new architecture, which means additional maintenance
>load for_every_ package. Could you try to be at least a bit consistent?
I still think...
We should drop all packages that are not "properly maintained" since
it affect many communities including the hardware architects ones
How?
If a package fails to build (on PA), there are several means to resolve
it less severe than dropping the package (provenpackagers, unresponsive
maintainer process, escalation to FESCo).
since they would have ensure those packages that are not
"properly
maintained" would build for their architecture before they would
become an primary architecture.
They have to do it for all packages anyway. There is no requirement that
a maintainer be able to fix arch-specific build problems himself and
upstream might not be interested.
I would think their time in the project would be better spent on
components that are actively maintained but you apparently dont.
I have not said anything like that. I just think your definition of the
meaning of actively maintained (or properly maintained) is completely
unrealistic. That is why I write it in quotes.
I still think...
We should limit the number of packages that individuals can maintain
so that they can effectively maintain them and as has been pointed
out many times with the arm architecture sub community that they are
willing to help with arm specific bugs not general ones bug the ones
but let's assume they don't which results in higher maintenance on
the relevant component which would results in fewer components that
individual could maintain since it would take more if his or her
time to maintain it.
Could you try to use some punctuation? It is quite hard to parse your
paragraph-long sentences...
If you dont think maintainers are already overburden and them being
so does not directly affect not only those maintainers directly but
also the community in whole, let's just take Peter Jones for an
example an newly re-elected FESCO member.
Not only does he not respond to bug reports like [1]
Sorry, but that example is unconvincing. AFAIK there is no policy saying
that every package must be kept at the newest version at every price.
There might be a very good reason why it has not been updated.
(Conversely, you have not provided any reason why it should be updated
in the bug...) And syslinux is not exactly a key part of the distro.
An example: there has been a new release of mdds. I have not updated it
in Fedora, because there has been an API change and libreoffice 4.1 does
not build with it. By your reasoning this means mdds is not "actively
maintained"...
Seriously, world is not black and white, even if you are trying to see
it that way.
but he also
ignores infrastructures tools [2] that exist for the sole purpose to
notify maintainers about new upstream releases ( and this is just
The tool exists to _notify_ maintainers about new releases, not to
_force_ them to update.
one of his components which has 18 bugs assigned to it by my account
) but he thinks he has enough time to serve on fesco at the same
time which requires him to do at least research into at least each
ticket filed in the fesco tracker and review of system wide features
and how ack/nack those features will affect the community in whole.
This is disrespectful to Peter.
Do you honestly think this is healthy for him or for the project in whole?
I am not his nanny, so I cannot tell him what is good for him. And I am
not in the habit of extrapolating from one accidental sample,
My solution to address problem like this and prevent "burnouts" in
the project ( although not officially concreted and proposed ) is
that we implement a form of a time share program for the project (
which arguably should not be limited to package maintenance since
this in essence does affect all participants in the project ) and
maintainers simple sign in how much free time they have or are
willing to spare daily/weekly/monthly in the project and based on
those free hours he or she has, we should be able to calculate how
many components he or she can maintain which could be one if it has
an high maintenance burden or 10, 20 100 with low maintenance.
This is completely unrealistic. There is no metric to measure a
maintenance cost of a package. And how could anyone know how much time
he will be able to spend regularly on the project this week? Next month?
Six months from now? The packagers here are _volunteers_. We need to
motivate them, not force arbitrary rules on them.
As more sign up to co-maintain component the more free time do the
existing maintainers get, which they in turn can use to (co )
maintain another component or spend elsewhere in the project.
You have just sketched a perpetuum mobile.
Implementing something like this would have significantly reduce the
number of components we have available with the increased stability
and not only healthier project but healthier participants as well.
This is what you claim, but you have nothing to prove it. I claim that
the process you envisioned would result in increasingly disgruntled
maintainers and a decrease in the number of users, as Fedora starts to
drop packages they use.
In any case i'm not following how I was somehow being "inconsistent"
with myself with my response
I try to restate it, then.
On one side:
1. you have proposed to drop packages that fail to meet some arbitrary
maintenance standards
2. you have proposed to limit the number of packages a person can
maintain, to make sure that maintainers are not overloaded.
On other side:
A. you are fine with adding a whole new primary architecture, which
contradicts point 2/ from the previous list (by increasing
maintenance load for _all_ maintainers)
B. you propose that the criterium for doing this is that all packages
build, which very probably contradicts point 1/ (that something
builds does not mean that it _works_ too. And if it does not work, it
shifts the responsibility to make it work on its maintainer, which is
against point 2/ again).
tl;dr: You aim to increase 1/ quality of the package base and 2/
healthiness of the maintainers. Inclusion of ARM as PA immediately
decreases both of these. Therefore, by supporting inclusion of ARM as
PA, you are contradicting your previous claims.
and if you have any proposal to solve
the previous mentioned problem in the distribution I'm all ears.
I do not, because I do not think it is as big a problem as you make it.
D.
6:49 a.m.
On 07/15/2013 07:42 AM, David Tardon wrote:
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B.
Guðmundsson" wrote:
> On 07/12/2013 12:08 PM, David Tardon wrote:
>>> I dont argue that this should be a blocker for architectures quite
>>>> the opposite as far as I see it the only requirement for an
>>>> architecture to be come a "primary" ( thou arguably those are
>>>> outdated concepts as well ) is that all package currently build (
>>>> with the execption if they simply cannot work on a spesific
>>>> architecture ) and be available for the community to use as lego
>>>> bricks to shape and present to the world as they image in for that
>>>> relevant hw.
>> It is only a few weeks you argued that we should drop all packages that
>> are not "properly maintained". Before that, you wanted to limit the
>> number of packages a person can maintain, (by your words) to ensure that
>> he (or she) has enough time to maintain them. Now you think it is a good
>> idea to add a whole new architecture, which means additional maintenance
>> load for_every_ package. Could you try to be at least a bit consistent?
>
> I still think...
>
> We should drop all packages that are not "properly maintained" since
> it affect many communities including the hardware architects ones
How?
If a package fails to build (on PA), there are several means to resolve
it less severe than dropping the package (provenpackagers, unresponsive
maintainer process, escalation to FESCo).
What do you mean how?
It's the packagers/maintainers responsibility to ensure his or her
component(s) work in the distribution proven packagers should not be
used to clean up other maintainers mess in the distribution because they
aren't paying attention to their component or do not have enough time to
maintain it.
> since they would have ensure those packages that are not "properly
> maintained" would build for their architecture before they would
> become an primary architecture.
They have to do it for all packages anyway. There is no requirement that
a maintainer be able to fix arch-specific build problems himself and
upstream might not be interested.
> I would think their time in the project would be better spent on
> components that are actively maintained but you apparently dont.
I have not said anything like that. I just think your definition of the
meaning of actively maintained (or properly maintained) is completely
unrealistic. That is why I write it in quotes.
Well obviously I dont think it's unrealistic that packagers and
maintainers actually maintain their component in the distribution.
> I still think...
>
> We should limit the number of packages that individuals can maintain
> so that they can effectively maintain them and as has been pointed
> out many times with the arm architecture sub community that they are
> willing to help with arm specific bugs not general ones bug the ones
> but let's assume they don't which results in higher maintenance on
> the relevant component which would results in fewer components that
> individual could maintain since it would take more if his or her
> time to maintain it.
Could you try to use some punctuation? It is quite hard to parse your
paragraph-long sentences...
No I cannot not.
> If you dont think maintainers are already overburden and them being
> so does not directly affect not only those maintainers directly but
> also the community in whole, let's just take Peter Jones for an
> example an newly re-elected FESCO member.
>
> Not only does he not respond to bug reports like [1]
Sorry, but that example is unconvincing. AFAIK there is no policy saying
that every package must be kept at the newest version at every price.
There might be a very good reason why it has not been updated.
(Conversely, you have not provided any reason why it should be updated
in the bug...) And syslinux is not exactly a key part of the distro.
Never said they did or have so stop twisting my word to somehow aid the
point you are trying to make.
An example: there has been a new release of mdds. I have not updated
it
in Fedora, because there has been an API change and libreoffice 4.1 does
not build with it. By your reasoning this means mdds is not "actively
maintained"...
Seriously, world is not black and white, even if you are trying to see
it that way.
Irrelevant the point was to show that he did not respond to the bug
report this whole time not whether he went all the way and update the
component in the distribution and he is just one sample of many.
> but he also
> ignores infrastructures tools [2] that exist for the sole purpose to
> notify maintainers about new upstream releases ( and this is just
The tool exists to _notify_ maintainers about new releases, not to
_force_ them to update.
Clarify when I did sat the tool was supposed to be used to force
maintainers to update?
> one of his components which has 18 bugs assigned to it by my account
> ) but he thinks he has enough time to serve on fesco at the same
> time which requires him to do at least research into at least each
> ticket filed in the fesco tracker and review of system wide features
> and how ack/nack those features will affect the community in whole.
This is disrespectful to Peter.
Really how is pointing out that Peter is overworked disrespectful to
Peter himself, something that he himself might not realize?
> Do you honestly think this is healthy for him or for the project in whole?
I am not his nanny, so I cannot tell him what is good for him. And I am
not in the habit of extrapolating from one accidental sample,
This general problem in the distribution and not limited to Peter
himself so don't try to make this about him.
> My solution to address problem like this and prevent "burnouts" in
> the project ( although not officially concreted and proposed ) is
> that we implement a form of a time share program for the project (
> which arguably should not be limited to package maintenance since
> this in essence does affect all participants in the project ) and
> maintainers simple sign in how much free time they have or are
> willing to spare daily/weekly/monthly in the project and based on
> those free hours he or she has, we should be able to calculate how
> many components he or she can maintain which could be one if it has
> an high maintenance burden or 10, 20 100 with low maintenance.
This is completely unrealistic. There is no metric to measure a
maintenance cost of a package.
Yes there is you can set a baseline and measure against that like.
* Dealing with a single simplest bug report takes/costs x amount of
your time.
* Updating your component to the latest upstream release takes/cost x x
amount of your time.
etc...
And how could anyone know how much time
he will be able to spend regularly on the project this week? Next month?
Six months from now? The packagers here are _volunteers_. We need to
motivate them, not force arbitrary rules on them.
Illogical conclusion but feel free to motivation people as much as you
want but it will not increaser the free time they have to spare to
dedicate to the project.
> As more sign up to co-maintain component the more free time do the
> existing maintainers get, which they in turn can use to (co )
> maintain another component or spend elsewhere in the project.
You have just sketched a perpetuum mobile.
> Implementing something like this would have significantly reduce the
> number of components we have available with the increased stability
> and not only healthier project but healthier participants as well.
This is what you claim, but you have nothing to prove it. I claim that
the process you envisioned would result in increasingly disgruntled
maintainers and a decrease in the number of users, as Fedora starts to
drop packages they use.
How can you claim that I have nothing to backup my claim while it's
quite obvious that fewer component that individual maintains results in
him being able to dedicate more of his free time to only maintain those
component resulting in better maintainership of the component he
maintains which in turn results in more happier users of that/those
components, while you dont back up your own claim?
> In any case i'm not following how I was somehow being "inconsistent"
> with myself with my response
I try to restate it, then.
On one side:
1. you have proposed to drop packages that fail to meet some arbitrary
maintenance standards
2. you have proposed to limit the number of packages a person can
maintain, to make sure that maintainers are not overloaded.
On other side:
A. you are fine with adding a whole new primary architecture, which
contradicts point 2/ from the previous list (by increasing
maintenance load for _all_ maintainers)
B. you propose that the criterium for doing this is that all packages
build, which very probably contradicts point 1/ (that something
builds does not mean that it _works_ too. And if it does not work, it
shifts the responsibility to make it work on its maintainer, which is
against point 2/ again).
tl;dr: You aim to increase 1/ quality of the package base and 2/
healthiness of the maintainers. Inclusion of ARM as PA immediately
decreases both of these. Therefore, by supporting inclusion of ARM as
PA, you are contradicting your previous claims.
I'm not contracting anything.
If they are dealing with arm spesific bugs yes it might depending on how
much assistance the arm community provides, if not no they are dealing
with the same amount of bugs against their component regardless of the
number of architect it runs on.
JBG
10:01 a.m.
On Mon, Jul 15, 2013 at 11:49:21AM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/15/2013 07:42 AM, David Tardon wrote:
>On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B. Guðmundsson" wrote:
>>On 07/12/2013 12:08 PM, David Tardon wrote:
>
>>I still think...
>>
>>We should limit the number of packages that individuals can maintain
>>so that they can effectively maintain them and as has been pointed
>>out many times with the arm architecture sub community that they are
>>willing to help with arm specific bugs not general ones bug the ones
>>but let's assume they don't which results in higher maintenance on
>>the relevant component which would results in fewer components that
>>individual could maintain since it would take more if his or her
>>time to maintain it.
>Could you try to use some punctuation? It is quite hard to parse your
>paragraph-long sentences...
No I cannot not.
As you want. But do not be surprised if people do not bother to read
them.
>
>>If you dont think maintainers are already overburden and them being
>>so does not directly affect not only those maintainers directly but
>>also the community in whole, let's just take Peter Jones for an
>>example an newly re-elected FESCO member.
>>
>>Not only does he not respond to bug reports like [1]
>Sorry, but that example is unconvincing. AFAIK there is no policy saying
>that every package must be kept at the newest version at every price.
>There might be a very good reason why it has not been updated.
>(Conversely, you have not provided any reason why it should be updated
>in the bug...) And syslinux is not exactly a key part of the distro.
Never said they did or have so stop twisting my word to somehow aid
the point you are trying to make.
You used it to support your own claim. Therefore you must have meant it
that way.
>An example: there has been a new release of mdds. I have not updated it
>in Fedora, because there has been an API change and libreoffice 4.1 does
>not build with it. By your reasoning this means mdds is not "actively
>maintained"...
>
>Seriously, world is not black and white, even if you are trying to see
>it that way.
Irrelevant the point was to show that he did not respond to the bug
report this whole time not whether he went all the way and update
the component in the distribution and he is just one sample of many.
It has exactly the same relevance as your own example. The point was to
show that you cannot apply the same measure on everything.
>
>>but he also
>>ignores infrastructures tools [2] that exist for the sole purpose to
>>notify maintainers about new upstream releases ( and this is just
>The tool exists to _notify_ maintainers about new releases, not to
>_force_ them to update.
Clarify when I did sat the tool was supposed to be used to force
maintainers to update?
When you implied that ignoring it is somehow wrong. Either the
maintainer is free to ignore the tool (in which case it is irrelevant to
mention it here), or he is not (and it seems that you think this is
true), in which case it effectively forces him to update.
>>Do you honestly think this is healthy for him or for the
project in whole?
>I am not his nanny, so I cannot tell him what is good for him. And I am
>not in the habit of extrapolating from one accidental sample,
This general problem in the distribution and not limited to Peter
himself so don't try to make this about him.
You started it.
>
>>My solution to address problem like this and prevent "burnouts" in
>>the project ( although not officially concreted and proposed ) is
>>that we implement a form of a time share program for the project (
>>which arguably should not be limited to package maintenance since
>>this in essence does affect all participants in the project ) and
>>maintainers simple sign in how much free time they have or are
>>willing to spare daily/weekly/monthly in the project and based on
>>those free hours he or she has, we should be able to calculate how
>>many components he or she can maintain which could be one if it has
>>an high maintenance burden or 10, 20 100 with low maintenance.
>This is completely unrealistic. There is no metric to measure a
>maintenance cost of a package.
Yes there is you can set a baseline and measure against that like.
* Dealing with a single simplest bug report takes/costs x amount of
your time.
The bug reports are rarely "simplest".
* Updating your component to the latest upstream release takes/cost
x x amount of your time.
No, it does not. Not all updates mean just uploading a new tarball and a
few trivial changes to the spec. There are new dependencies, build
problems etc.
>And how could anyone know how much time
>he will be able to spend regularly on the project this week? Next month?
>Six months from now? The packagers here are _volunteers_. We need to
>motivate them, not force arbitrary rules on them.
Illogical conclusion but feel free to motivation people as much as
you want but it will not increaser the free time they have to spare
to dedicate to the project.
Neither will shuffling them from a package to a package, as you proposed
in the paragraph that follows this.
On the other side, if Fedora starts to require from maintainers to fill
timesheets, to tell them how many packages they can maintain etc., it
will surely decrease their motivation.
>
>>As more sign up to co-maintain component the more free time do the
>>existing maintainers get, which they in turn can use to (co )
>>maintain another component or spend elsewhere in the project.
>You have just sketched a perpetuum mobile.
>
>>Implementing something like this would have significantly reduce the
>>number of components we have available with the increased stability
>>and not only healthier project but healthier participants as well.
>This is what you claim, but you have nothing to prove it. I claim that
>the process you envisioned would result in increasingly disgruntled
>maintainers and a decrease in the number of users, as Fedora starts to
>drop packages they use.
How can you claim that I have nothing to backup my claim while it's
quite obvious that fewer component that individual maintains results
in him being able to dedicate more of his free time to only maintain
those component resulting in better maintainership of the component
he maintains which in turn results in more happier users of
that/those components, while you dont back up your own claim?
That is a false fallacy. That a maintainer has fewer components does not
imply that he spends more time on each of them.
On the other side, it is quite obvious that if Fedora drops a package,
the users who want to use that package will leave Fedora (some will try
to find a replacement, but definitely not all).
>
>>In any case i'm not following how I was somehow being
"inconsistent"
>>with myself with my response
>I try to restate it, then.
>
>On one side:
>1. you have proposed to drop packages that fail to meet some arbitrary
> maintenance standards
>2. you have proposed to limit the number of packages a person can
> maintain, to make sure that maintainers are not overloaded.
>
>On other side:
>A. you are fine with adding a whole new primary architecture, which
> contradicts point 2/ from the previous list (by increasing
> maintenance load for _all_ maintainers)
>B. you propose that the criterium for doing this is that all packages
> build, which very probably contradicts point 1/ (that something
> builds does not mean that it _works_ too. And if it does not work, it
> shifts the responsibility to make it work on its maintainer, which is
> against point 2/ again).
>
>tl;dr: You aim to increase 1/ quality of the package base and 2/
>healthiness of the maintainers. Inclusion of ARM as PA immediately
>decreases both of these. Therefore, by supporting inclusion of ARM as
>PA, you are contradicting your previous claims.
I'm not contracting anything.
If they are dealing with arm spesific bugs yes it might depending on
how much assistance the arm community provides, if not no they are
dealing with the same amount of bugs against their component
regardless of the number of architect it runs on.
So again:
A. you are fine with adding a whole new primary architecture, which
contradicts point 2/ from the previous list (by increasing
maintenance load for _all_ maintainers *because of ARM-specific bugs*.)
(Well, how else could inclusion of ARM as PA _increase_ the load on
maintainers? The bugs and build problems that are already present on
current PA's are, so to say, already there... I thought this was rather
obvious...)
D.
10:07 a.m.
For the record: this is my last reply in this thread. I have better
things to do...
D.
5:18 p.m.
On Fri, Jul 12, 2013 at 1:08 PM, David Tardon <dtardon(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 06:06:04PM +0000, "Jóhann B.
Guðmundsson" wrote:
> On 07/11/2013 02:04 PM, Miloslav Trmač wrote:
> >On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson"
> ><johannbg(a)gmail.com> wrote:
> >>Each sub-community ( be it spins be it various arch ) should need to provide
> >>the necessary QA/Releng resources from their sub-community ( if no such
> >>thing the relevant party needs to build one )
> >That would be interesting and quite possibly very beneficial, however
> >the transition from the current system when most people "don't need to
> >care" would be a complex, longer-term cultural shift that shouldn't be
> >(and doesn't really need to be) a blocker for the ARM feature.
>
> I dont argue that this should be a blocker for architectures quite
> the opposite as far as I see it the only requirement for an
> architecture to be come a "primary" ( thou arguably those are
> outdated concepts as well ) is that all package currently build (
> with the execption if they simply cannot work on a spesific
> architecture ) and be available for the community to use as lego
> bricks to shape and present to the world as they image in for that
> relevant hw.
It is only a few weeks you argued that we should drop all packages that
are not "properly maintained".
Actually from an ARM perspective that would be a bonus as I spend a
lot more of my time fixing packages that are broken on mainline so
that I can see if they build on ARM which in 80% ish of the cases just
fixes the ARM build issues, in another 10% of cases updating the
package to the latest upstream release fixes the ARM build issues,
there's a percentage point or two where there's problems in the
packaging or using non distro build options like CFLAGS. The vast
majority of the packaging issues I deal with on ARM are not actually
ARM specific and often fix the other secondary arches as well!
Peter
3843
days inactive
3941
days old
256 comments
48 participants
participants (48)
-
Adam Jackson -
Adam Williamson -
Aleksandar Kurtakov -
Andrew Haley -
Bastien Nocera -
Bill Nottingham -
Björn Persson -
Brendan Conoboy -
Bruno Wolff III -
Caolán McNamara -
Carlos O'Donell -
Chris Adams -
Chris Murphy -
Chris Tyler -
Christopher Meng -
Cole Robinson -
Dan Horák -
Daniel P. Berrange -
David Tardon -
Dennis Gilmore -
DJ Delorie -
drago01 -
Florian Weimer -
Frank Ch. Eigler -
Gregory Maxwell -
Hans de Goede -
Jakub Jelinek -
Jaroslav Reznik -
Jiri Eischmann -
Jon Masters -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kyle McMartin -
Lain Cortés González -
M A Young -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Miloslav Trmač -
Peter Jones -
Peter Robinson -
Rahul Sundaram -
Richard W.M. Jones -
Rob Clark -
Stephen John Smoogen -
Till Maas -
Toshio Kuratomi