= Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore dennis@ausil.us, Peter Robinson pbrobinson@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Excellent proposal. I of course think this would be just awesome!
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
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
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.
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik jreznik@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
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač mitr@volny.cz wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik jreznik@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
On 9 July 2013 10:57, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač mitr@volny.cz wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik jreznik@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.
On 9 July 2013 10:57, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač mitr@volny.cz wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik jreznik@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
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.
On Tue, Jul 9, 2013 at 12:54 PM, Miloslav Trmač mitr@volny.cz wrote:
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik jreznik@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
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
On Tue, Jul 9, 2013 at 6:24 PM, Kyle McMartin kyle@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
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.
On Tue, Jul 9, 2013 at 6:43 PM, Matthew Garrett mjg59@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
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.
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett mjg59@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
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@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.
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@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
On Thu, Jul 11, 2013 at 4:33 PM, Matthew Garrett mjg59@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@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
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@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.
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.
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:
- Provide a list of every ARM deficiency.
Every known deficiency, sure.
- Provide a fix for everything listed in 1.
Either a fix or an explanation of why it's not worth fixing.
- 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.
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?
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.
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
Adam Jackson (ajax@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
On Thu, Jul 11, 2013 at 1:08 PM, Bill Nottingham notting@redhat.com wrote:
Adam Jackson (ajax@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham notting@redhat.com wrote:
Adam Jackson (ajax@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
On Mon, Jul 15, 2013 at 4:53 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham notting@redhat.com wrote:
Adam Jackson (ajax@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@redhat.com wrote:
Adam Jackson (ajax@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera bnocera@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
----- Original Message -----
On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera bnocera@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.
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
----- 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.
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
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,
On Tue, 16 Jul 2013 12:18:26 -0700 Brendan Conoboy blc@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:
- 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)
- 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.
- 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
----- 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:
- 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?
- 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.
- 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
On Wed, 17 Jul 2013 12:53:18 -0400 (EDT) Bastien Nocera bnocera@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
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,
On 17 Jul 2013 18:18, "Brendan Conoboy" blc@redhat.com wrote:
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,
Virtio-mmio should land in qemu rawhide soon which should help a little to improve speed but I wouldn't imagine huge improvement.
Peter
-- Brendan Conoboy / Red Hat, Inc. / blc@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
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@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.
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!
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.
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett mjg59@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?
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.
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.
On 2013-07-09 10:53, Gregory Maxwell wrote:
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett mjg59@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).
On Tue, Jul 9, 2013 at 7:22 PM, Adam Williamson awilliam@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
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.
On Tuesday, July 9, 2013, Jonathan Masters 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 ...
On 07/09/2013 08:00 PM, drago01 wrote:
On Tuesday, July 9, 2013, Jonathan Masters <jcm@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?
On Wednesday, July 10, 2013, "Jóhann B. Guðmundsson" < johannbg@gmail.com> wrote:
On 07/09/2013 08:00 PM, drago01 wrote:
On Tuesday, July 9, 2013, Jonathan Masters 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?
You missed the point. I am not talking ab out Desktops but OpenGL if wie dont have such criteria wie should ad it.
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
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?
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 9 Jul 2013 16:33:28 -0400 Peter Jones pjones@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
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@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.
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
On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek jakub@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
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.
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 ---
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.
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett mjg59@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
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 ;)
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
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.
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
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.
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
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?
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
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 12 Jul 2013 07:34:49 +0200 Jakub Jelinek jakub@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
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!
On Thu, Jul 11, 2013 at 2:49 PM, Jakub Jelinek jakub@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
On Thu, Jul 11, 2013 at 7:21 PM, Brendan Conoboy blc@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
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@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
On Thu, 2013-07-11 at 12:14 +0100, Peter Robinson wrote:
On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett mjg59@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 awilliam@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.
- FChE
On 07/11/2013 07:07 PM, Frank Ch. Eigler wrote:
Adam Williamson awilliam@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. ;-)
Once upon a time, Brendan Conoboy blc@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?
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
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.
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.
On Jul 12, 2013, at 5:32, Matthew Garrett mjg59@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
On Fri, Jul 12, 2013 at 5:32 AM, Matthew Garrett mjg59@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
On Thu, 11 Jul 2013 23:50:24 -0400 Rahul Sundaram metherid@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
Hi
On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi kevin@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 12 Jul 2013 00:47:03 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi kevin@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
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote:
Adam Williamson awilliam@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 ;)
On Fri, Jul 12, 2013 at 9:08 AM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote:
Adam Williamson awilliam@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?
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.
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?
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@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.
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.
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.
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!
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
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.
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@ausil.us, Peter Robinson pbrobinson@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_Maintainer...
f17-arm-test.scrye.com is currently not reachable for me.
Regards Till
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensource@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@ausil.us, Peter Robinson pbrobinson@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_Maintainer...
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
On Tue, 9 Jul 2013 22:36:39 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensource@till.name wrote:
...snip...
test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
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
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
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.
On Wed, Jul 10, 2013 at 9:43 PM, Richard W.M. Jones rjones@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
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@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.
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
在 2013-7-11 AM4:43，"Richard W.M. Jones" rjones@redhat.com写道：
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.
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.
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:
I think that's s/Arndale/Chromebook/
-Chris
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
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
----- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jreznik@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
On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer jwboyer@gmail.com wrote:
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jreznik@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
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@gmail.com wrote:
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jreznik@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 11 Jul 2013 12:41:40 +0100 "Daniel P. Berrange" berrange@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@gmail.com wrote:
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jreznik@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
On Thu, Jul 11, 2013 at 12:35:36 +0100, Peter Robinson pbrobinson@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).
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@gmail.com wrote:
On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jreznik@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
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:
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.
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:
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
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:
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?
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:
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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 12 Jul 2013 18:40:21 +0200 Till Maas opensource@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
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/armh...
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/armh...
(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/armh... 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 13 Jul 2013 11:36:00 +0200 Till Maas opensource@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/armh...
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/armh...
(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/armh... 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
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@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/armh...
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/armh...
(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/armh... 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
On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
On Tue, 9 Jul 2013 22:36:39 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensource@till.name wrote:
...snip...
test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
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.
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@gmail.com wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensource@till.name wrote:
...snip...
test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
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
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@gmail.com wrote:
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensource@till.name wrote:
...snip...
test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer...
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.
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@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_Maintainer...
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
On Wed, Jul 10, 2013 at 11:57 AM, Till Maas opensource@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@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
On Wed, Jul 10, 2013 at 5:06 PM, Josh Boyer jwboyer@gmail.com wrote:
On Wed, Jul 10, 2013 at 11:57 AM, Till Maas opensource@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@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 10 Jul 2013 17:57:43 +0200 Till Maas opensource@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@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
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 (awilliam@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
On 2013-07-09 17:36, Bill Nottingham wrote:
Adam Williamson (awilliam@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.
----- Original Message -----
Adam Williamson (awilliam@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
Adam Williamson (awilliam@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
----- Original Message -----
From: "Josh Boyer" jwboyer@gmail.com To: "Development discussions related to Fedora" devel@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@redhat.com wrote:
----- Original Message -----
Adam Williamson (awilliam@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
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.
----- Original Message -----
From: "Richard W.M. Jones" rjones@redhat.com To: "Development discussions related to Fedora" devel@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:
~ 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 11 Jul 2013 02:12:03 -0400 (EDT) Aleksandar Kurtakov akurtako@redhat.com wrote:
----- Original Message -----
From: "Richard W.M. Jones" rjones@redhat.com To: "Development discussions related to Fedora" devel@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
On Wed, 10 Jul 2013 21:56:40 +0100 "Richard W.M. Jones" rjones@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
On Thu, Jul 11, 2013 at 12:28 PM, Caolán McNamara caolanm@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
On Wed, Jul 10, 2013 at 1:28 PM, Aleksandar Kurtakov akurtako@redhat.com wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@gmail.com To: "Development discussions related to Fedora" devel@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@redhat.com wrote:
----- Original Message -----
Adam Williamson (awilliam@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
----- Original Message -----
From: "Peter Robinson" pbrobinson@gmail.com To: "Development discussions related to Fedora" devel@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@redhat.com wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@gmail.com To: "Development discussions related to Fedora" devel@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@redhat.com wrote:
----- Original Message -----
Adam Williamson (awilliam@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:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 10 Jul 2013 15:06:50 -0400 (EDT) Aleksandar Kurtakov akurtako@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
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@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.
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
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
On Wed, 2013-07-10 at 07:45 -0400, Josh Boyer wrote:
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
Adam Williamson (awilliam@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.
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.
On Jul 10, 2013 6:08 PM, "Brendan Conoboy" blc@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 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 Wed, 2013-07-10 at 20:12 -0700, Toshio Kuratomi wrote:
On Jul 10, 2013 6:08 PM, "Brendan Conoboy" blc@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.
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"!
On Thu, Jul 11, 2013 at 6:36 PM, Matthew Miller mattdm@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
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.
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.
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.
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy blc@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
On Thu, Jul 11, 2013 at 6:55 AM, Josh Boyer jwboyer@gmail.com wrote:
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy blc@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
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.
On Thu, Jul 11, 2013 at 11:55 AM, Josh Boyer jwboyer@gmail.com wrote:
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy blc@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
On Thu, Jul 11, 2013 at 7:41 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Jul 11, 2013 at 11:55 AM, Josh Boyer jwboyer@gmail.com wrote:
On Thu, Jul 11, 2013 at 2:04 AM, Brendan Conoboy blc@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
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!
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.
On Thu, 11 Jul 2013 14:22:08 -0400 Peter Jones pjones@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
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.
On Thu, Jul 11, 2013 at 7:22 PM, Peter Jones pjones@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
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 (blc@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
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 (blc@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
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.