Re: F20 System Wide Change: ARM as primary Architecture
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote: > Pointer mangling is useful, but we can roll that change into an update > and it should not in my opinion block F20. > > I've filed: > Bug 1019452 - [ARM] Backport pointer mangling support from upstream. > https://bugzilla.redhat.com/show_bug.cgi?id=1019452 Great. Thanks, Carlos! -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote: > On 10/14/2013 10:55 AM, Matthew Garrett wrote: > > Did the arm32 portions of this end up being completed for F20? > > For 32-bit ARM on f20: > > - Stack guard: > - Existing glibc support provides stack guard value in global > variable and is used by existing runtime. Regression tests are > passing in glibc testsuite. Verified working. Upstream verified > that global variable is the best compromise for performance across > all 32-bit ARM targets (TLS will be too slow in the average case). What's the effective difference in security between this and the existing ports? > - Pointer mangling: > - Not supported. Do we ship it in the x86 ports? > Upstream glibc 2.19 summary: > > - Stack guard support already present using global variable. > > - Will have pointer encryption support using global variable, > and could be a candidate for backport to f20. Cool. This is a runtime change, right? There's no requirement for a rebuild to take advantage of it? > Do we need pointer mangling? If so then we need someone to file an > f20 specific bug so the glibc team can look at backporting the fix. > I won't commit to it until I review exactly what might need changing. The aim was for parity of important features, but it doesn't seem like we've ever advertised pointer guard as a Fedora feature so I'm not personally that worried. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
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 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote: > Next steps: > - Verify libssp works correctly on 32-bit ARM. > - Look at enhancing the existing support in glibc. > - Add TLS stack guard. > - Add TLS pointer guard. > - Add pointer mangle/demangle support. > - Enhance aarch64 to support the same set of features. Did the arm32 portions of this end up being completed for F20? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, 2013-07-17 at 15:18 -0700, Adam Williamson wrote: > Following today's FESCo decision, I have created a QA trac ticket to > co-ordinate this: > > https://fedorahosted.org/fedora-qa/ticket/393 > > interested parties please feel free to CC yourselves and contribute any > suggested changes / extensions to the above plan there. I'll aim to try > and propose some changes as described above for later this week or early > next week on test@: that is the list where release criteria revision > usually takes place, so please subscribe to that if you're interested in > following the process. Also filed https://fedorahosted.org/fedora-qa/ticket/394 for corresponding changes to the release validation process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, 2013-07-10 at 23:25 -0700, Adam Williamson wrote: > On Wed, 2013-07-10 at 23:18 -0700, Brendan Conoboy wrote: > > On 07/10/2013 10:12 PM, Adam Williamson wrote: > > > As I said elsewhere in the thread, the criteria should be subsidiary to > > > the primary arch designation. If we decide we want to take ARM as a > > > primary arch in any form in which the current release criteria don't > > > apply, we should amend the release criteria. > > > > > > In context I was just providing some background information: as the > > > criteria currently stand, KDE and GNOME are the release blocking > > > desktops. (Technically that in itself isn't really an aspect of the > > > release criteria; it's Fedora status quo that predates the current form > > > of the release validation process). > > > > Yeah, it seems like a foregone conclusion that release criteria would > > need to be modified. I don't think the current proposal includes this, > > but perhaps it should. Realistically what's going to be needed is some > > form of granularity on "primary". At first blush I like the idea of a > > "primary server" and "primary desktop" designation (maintaining a > > unified build system) but haven't thought the full consequences through. > > The required change is not, in fact, necessarily that dramatic, as I > mentioned earlier in the thread. As written, the release criteria do not > explicitly require that the release-blocking desktops work on all > primary architectures. They just talk about things that are required to > work within the desktops themselves. > > What would actually need to change for ARM, I think, are just the very > early criteria and preamble, where we have this stuff: > > "The term 'release-blocking images' means all the images in which bugs > are currently considered capable of blocking a Fedora release. The > current set of release-blocking images includes the network install > image, the DVD image, and the live images for each of the > release-blocking desktops." > > "All release-blocking images must boot in their supported > configurations.", with a bunch of footnotes about what that means > precisely. > > I think we could make relatively minor tweaks to those bits - obviously, > we would extend the list of 'release-blocking images', which functions > as a very concise 'deliverables' list - and maybe make it a bit clearer > in the footnotes to the 'initialization requirements' criteria exactly > what behaviour is required from those images. That would really be all > that would be necessary, I think. We _could_ explain specifically in the > preamble that certain criteria are not relevant to certain arches, if we > wanted to. Following today's FESCo decision, I have created a QA trac ticket to co-ordinate this: https://fedorahosted.org/fedora-qa/ticket/393 interested parties please feel free to CC yourselves and contribute any suggested changes / extensions to the above plan there. I'll aim to try and propose some changes as described above for later this week or early next week on test@: that is the list where release criteria revision usually takes place, so please subscribe to that if you're interested in following the process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 17 Jul 2013 18:18, "Brendan Conoboy" 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. / b...@redhat.com > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/17/2013 09:53 AM, Bastien Nocera wrote: As I mentioned earlier in the thread, I'd rather have community accessible machines. And I'm not really comfortable manipulating build images from 4000 miles away if I haven't been able to test them in the slightest locally. Sure, community accessible machines reach the widest audience. Until that plan is fully ready to go I can provide ARM server access to Red Hat personnel. Of course it doesn't help when you need to do local testing. The versatile express image works on any host with qemu-system-arm, so this is one (slow) avenue. Beyond that, in some cases it possible to provide hardware. Please email me if you need this. Thanks, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, 17 Jul 2013 12:53:18 -0400 (EDT) Bastien Nocera wrote: > https://fedoraproject.org/wiki/Koji/BuildingImages says: > " > koji grant-permission : 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
- Original Message - > On 07/16/2013 05:28 AM, Peter Robinson wrote: > > All the remix images to date have been created on the users own > > devices. If you are internal to Red Hat there's process to get access > > to internal infrastructure... > > There are 3 things I would like to add here: > > 1. As Peter mentioned elsewhere in his reply, not even the ARM team has > access to the ARM builders in PHX. Just like we don't have x86_64. > Access is handled by the infrastructure team, builds are handled by > koji. These are closed systems without remote access provisions. https://fedoraproject.org/wiki/Koji/BuildingImages says: " koji grant-permission : grant the permission to build an image type to a user. " Is that not correct? > 2. Kevin Fenzi is working on setting up a limited pool > community-accessible ARM builders. Join in the weekly fedora-arm > meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates > about his progress (And other ARM topics). As of last week it was being > considered and worked on, but not immediately ready to go. Great. > 3. If you are a Red Hat employee I can provide access to ARM systems of > the same caliber as what is in the Fedora colo. Drop me a line and let > me know what you need- I will make it happen. As I mentioned earlier in the thread, I'd rather have community accessible machines. And I'm not really comfortable manipulating build images from 4000 miles away if I haven't been able to test them in the slightest locally. Peter said that he's restart creating GNOME images very soon, which is good enough for me to start with. I have packages for the freedreno X server driver done: http://people.fedoraproject.org/~hadess/peak/xorg-x11-drv-freedreno/ (it currently requires a git mesa, but it might be a good thing to get it in the distro anyway) And for a version of adbd that'll run on Fedora: http://people.fedoraproject.org/~hadess/peak/adbd/ The sources still need fixing to use another user than 2000 by default, and the systemd service file needs fixing too. If anyone is interested to get those merged, poke me or Rob Clark about getting them in Fedora and the patches upstream. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, 16 Jul 2013 12:18:26 -0700 Brendan Conoboy wrote: > On 07/16/2013 05:28 AM, Peter Robinson wrote: > > All the remix images to date have been created on the users own > > devices. If you are internal to Red Hat there's process to get > > access to internal infrastructure... > > There are 3 things I would like to add here: > > 1. As Peter mentioned elsewhere in his reply, not even the ARM team > has access to the ARM builders in PHX. Just like we don't have > x86_64. Access is handled by the infrastructure team, builds are > handled by koji. These are closed systems without remote access > provisions. Correct. It needs koji admin to be able to spin images for a variety of reasons (mostly resources... disk and builder cycles and io) > 2. Kevin Fenzi is working on setting up a limited pool > community-accessible ARM builders. Join in the weekly fedora-arm > meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates > about his progress (And other ARM topics). As of last week it was > being considered and worked on, but not immediately ready to go. I'm waiting for a firmware update thats hopefully out soon that will allow us to isolate some SOC's on a seperate physical network wire so we can make sure they don't interfere with anything else. > 3. If you are a Red Hat employee I can provide access to ARM systems > of the same caliber as what is in the Fedora colo. Drop me a line > and let me know what you need- I will make it happen. We do already have some QA ones with more limited access, we can see about adding you to access those if that would help? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 6:36 PM, Matthew Miller 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 17, 2013 at 3:53 AM, Matthew Garrett wrote: > On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote: >> On 07/16/2013 07:16 PM, Matthew Garrett wrote: > >> >For instance, it seems to be missing both the stack protector and >> >llvmpipe issues. >> >> Finishing scope of stack protector issue- it'll be there in a day or >> so. Idea is to get upstream reports in, then link to them. > > Sure, I'm not saying that they're not being worked on. I'm just pointing > out that the ARM tracker bug doesn't list every known ARM issue. Yes, aware of that, the llvm issue is there, might be useful to update the description. I'll be adding some more soon to cover things like ada bringup to ensure it's all tracked. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote: > On 07/16/2013 07:16 PM, Matthew Garrett wrote: > >For instance, it seems to be missing both the stack protector and > >llvmpipe issues. > > Finishing scope of stack protector issue- it'll be there in a day or > so. Idea is to get upstream reports in, then link to them. Sure, I'm not saying that they're not being worked on. I'm just pointing out that the ARM tracker bug doesn't list every known ARM issue. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 07:16 PM, Matthew Garrett wrote: On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote: On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller wrote: On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? The list of outstanding ARM bugs is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=245418 alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker And we're working to sure it's completely up to date, sorry but the last couple of days have been some what hectic for me in other realms. For instance, it seems to be missing both the stack protector and llvmpipe issues. Finishing scope of stack protector issue- it'll be there in a day or so. Idea is to get upstream reports in, then link to them. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote: > On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller > wrote: > > On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: > >> >I don't want to move the goalposts on the ARM effort, but I think it's > >> >reasonable to expect that a list of "Known Broken/Deficient items" be > >> >available. Does such a list exist? > >> The list of outstanding ARM bugs is tracked here: > >> https://bugzilla.redhat.com/show_bug.cgi?id=245418 > > > > alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker > > And we're working to sure it's completely up to date, sorry but the > last couple of days have been some what hectic for me in other realms. For instance, it seems to be missing both the stack protector and llvmpipe issues. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller wrote: > On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: >> >I don't want to move the goalposts on the ARM effort, but I think it's >> >reasonable to expect that a list of "Known Broken/Deficient items" be >> >available. Does such a list exist? >> The list of outstanding ARM bugs is tracked here: >> https://bugzilla.redhat.com/show_bug.cgi?id=245418 > > alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker And we're working to sure it's completely up to date, sorry but the last couple of days have been some what hectic for me in other realms. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 10:55 PM, Adam Williamson wrote: > On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote: >> On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: >> > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: >> > >> >> > I'm afraid I can't agree. I like the simplicity of the model you're >> >> > proposing, but from a practical point of view, there is still a commonly >> >> > held perception that there is a 'product' called Fedora which is >> >> > basically composed of what you get if you go to get.fedoraproject.org, >> >> > download one of the things we push at you there, and install it. >> >> > Practically speaking, I believe we have to QA that 'thing called Fedora' >> >> > as a whole. I don't think your model quite matches what people perceive >> >> > Fedora to be. >> >> >> >> What's your definition of what people perceive Fedora to be? >> > >> > "What do we talk about when we talk about Fedora?" :) >> > >> > Well, we just did a major release. Go look on news.google.com for >> > "Fedora 19", or search for "Fedora 19 review", or just poke through a >> > few popular tech sites and forums. >> > >> > What do people do when they want to 'try Fedora 19'? They download the >> > primary image on the download page, which is the desktop live, and run >> > it. This is what they've _always_ done. >> >> Hmm I wouldn't be surprised if we had more Fedora users running on >> cloud instances now than we do on the desktop but there's no way to >> tell really. > > Might be the sites I'm reading, but I have yet to see a single post > anywhere even mentioning the cloud image, while I've replied to dozens > of posts of people testing the desktop live. Well it's live on at least amazon and rackspace so who would know Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: > >I don't want to move the goalposts on the ARM effort, but I think it's > >reasonable to expect that a list of "Known Broken/Deficient items" be > >available. Does such a list exist? > The list of outstanding ARM bugs is tracked here: > https://bugzilla.redhat.com/show_bug.cgi?id=245418 alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 11:36 AM, Bill Nottingham wrote: Well, what else is broken? It's a matter of approach - you seem to be saying "what are the minimum requirements, listed so that we can meet them". In terms of a minimum viable platform, for all its faults, the interfaces specified by the LSB might be a worthwhile starting point. But even in that case... if an arch implemented the entire LSB, and 90% of the rest of the distribution did not build, that's obviously not good enough. So I'm more in favor of "tell us what you don't have, and we can discuss whether that's good enough." I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? The list of outstanding ARM bugs is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=245418 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: > > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: > > > >> > I'm afraid I can't agree. I like the simplicity of the model you're > >> > proposing, but from a practical point of view, there is still a commonly > >> > held perception that there is a 'product' called Fedora which is > >> > basically composed of what you get if you go to get.fedoraproject.org, > >> > download one of the things we push at you there, and install it. > >> > Practically speaking, I believe we have to QA that 'thing called Fedora' > >> > as a whole. I don't think your model quite matches what people perceive > >> > Fedora to be. > >> > >> What's your definition of what people perceive Fedora to be? > > > > "What do we talk about when we talk about Fedora?" :) > > > > Well, we just did a major release. Go look on news.google.com for > > "Fedora 19", or search for "Fedora 19 review", or just poke through a > > few popular tech sites and forums. > > > > What do people do when they want to 'try Fedora 19'? They download the > > primary image on the download page, which is the desktop live, and run > > it. This is what they've _always_ done. > > Hmm I wouldn't be surprised if we had more Fedora users running on > cloud instances now than we do on the desktop but there's no way to > tell really. Might be the sites I'm reading, but I have yet to see a single post anywhere even mentioning the cloud image, while I've replied to dozens of posts of people testing the desktop live. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 05:28 AM, Peter Robinson wrote: All the remix images to date have been created on the users own devices. If you are internal to Red Hat there's process to get access to internal infrastructure... There are 3 things I would like to add here: 1. As Peter mentioned elsewhere in his reply, not even the ARM team has access to the ARM builders in PHX. Just like we don't have x86_64. Access is handled by the infrastructure team, builds are handled by koji. These are closed systems without remote access provisions. 2. Kevin Fenzi is working on setting up a limited pool community-accessible ARM builders. Join in the weekly fedora-arm meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates about his progress (And other ARM topics). As of last week it was being considered and worked on, but not immediately ready to go. 3. If you are a Red Hat employee I can provide access to ARM systems of the same caliber as what is in the Fedora colo. Drop me a line and let me know what you need- I will make it happen. Thanks, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 01:49 AM, Bastien Nocera wrote: I'm interested in Fedora on phones, tablets, tiny dongly media centers, set-top boxes, Wi-Fi routers and eBook readers. Personally, I'm interested in running Fedora on ARM everywhere, so if you want to contribute toward the above, by all means do so. Join us in #fedora-arm, join the mailing list, and we'll do what we can to support your pursuit. If it can be done within Fedora package guidelines and spin set it can be an official part of the next release. If it can't, it can be a remix. In either case you are most welcome to join in and pursue your interest. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Brendan Conoboy (b...@redhat.com) said: > Hypothetically speaking, if libGL is fixed in the next few days, do > you have any objections to armv7hl being moved to primary koji? Or > is that the tip of the iceberg? > > >And I'm saying that threshold should be that the major libraries work. That > >includes libGL. > > Okay, so it's not just libGL, it's major libraries. Which are those? Well, what else is broken? It's a matter of approach - you seem to be saying "what are the minimum requirements, listed so that we can meet them". In terms of a minimum viable platform, for all its faults, the interfaces specified by the LSB might be a worthwhile starting point. But even in that case... if an arch implemented the entire LSB, and 90% of the rest of the distribution did not build, that's obviously not good enough. So I'm more in favor of "tell us what you don't have, and we can discuss whether that's good enough." I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 11:01 AM, Bill Nottingham wrote: Brendan Conoboy (b...@redhat.com) said: If not now, when? When libGL is ready to go? ... when someone fixes it? Hypothetically speaking, if libGL is fixed in the next few days, do you have any objections to armv7hl being moved to primary koji? Or is that the tip of the iceberg? And I'm saying that threshold should be that the major libraries work. That includes libGL. Okay, so it's not just libGL, it's major libraries. Which are those? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Brendan Conoboy (b...@redhat.com) said: > On 07/15/2013 11:09 AM, Bill Nottingham wrote: > >If I'm understanding you, you would prefer that ARM be blessed with the > >stamp of being a 'primary' arch at the cost of dropping release targets, > >images, and featuresets that are made by and for the community now. > > I wouldn't put it like that. The ARM team isn't asking for a > blessing, we're asking to have builds that block ARM also block x86. > At a technical level, that is a fundamental part of what being > primary is. Yes, there are other aspects, both practical (what is > released) and philosophical (What is Fedora). It's the next logical > step. If not now, when? When libGL is ready to go? ... when someone fixes it? > >I don't think I can support that - it seems awfully unfriendly to the > >community that exists now. > > You are proceeding from a misconception: This is a thought exercise- > If ARM devices didn't have graphics would it still be essential for > PA promotion that libGL for ARM work and be accelerated? There is > no proposal to throw out the baby or the bathwater. This is about > defining the threshold at which point armv7hl gets built along side > i686 and x86_64. And I'm saying that threshold should be that the major libraries work. That includes libGL. After all, IT WORKS ON S390. This is not a high bar, and I wouldn't consider it a requirement for that arch. Sure, the hardware you care about doesn't include graphics. But the hardware the community cares about does. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 4:58 PM, Rob Clark wrote: > On Tue, Jul 16, 2013 at 7:00 AM, drago01 wrote: >> >> >> On Monday, July 15, 2013, Rob Clark wrote: >>> On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson >>> wrote: On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: > On 07/11/2013 10:41 AM, Bill Nottingham wrote: >> >> Kernel, glibc, all the core library stacks. And I would argue that yes, >> this >> *includes* libGL. So llvmpipe needs fixed, outside of any desktops. >> Should >> we define the core functionality better? Probably. > > > I would argue that it does not include libGL because it's not a > requirement > for headless deployment scenarios. Why would you argue for it? I would argue that it's nothing to do with headless scenarios but more that the vast majority of ARM GPUs support GL-ES which is a sub/different standard of desktop GL (sorry, I'm not a graphics programming expert!) and the support for that in mesa and in general is terrible. There was a proposal to refactor mesa and when I spoke to ajax (I think, sorry ajax if it wasn't you) or someone it wasn't basically moving forward upstream at the moment. I'm not sure who originally was driving this (my google fu doesn't give me the mailing list proposal ATM). >>> >>> It is getting a bit off the topic, but this it isn't really a problem >>> with mesa. But rather that we have non-gallium closed src drivers >>> from the GPU vendors in the ARM space, which only support GLES. And >>> most/all of the desktop stuff packaged in fedora (in particular, >>> gnome-shell) is requiring GL. >> >> This is incorrect. It uses cogl which has a gles renderer wich is supposed >> Tod work. If it does not that is just a bug that we should fix. > > At least as packaged in f19, it seems to require GL. I know of people > who have recompiled it, and supposedly have it working to some degree > with GLES. Not sure if that was the same version as what is in f19, > etc. OK, seems like we indeed do not build them. But once built switching can be done using ENV vars. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 7:00 AM, drago01 wrote: > > > On Monday, July 15, 2013, Rob Clark wrote: >> On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson >> wrote: >>> On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: On 07/11/2013 10:41 AM, Bill Nottingham wrote: > > Kernel, glibc, all the core library stacks. And I would argue that yes, > this > *includes* libGL. So llvmpipe needs fixed, outside of any desktops. > Should > we define the core functionality better? Probably. I would argue that it does not include libGL because it's not a requirement for headless deployment scenarios. Why would you argue for it? >>> >>> I would argue that it's nothing to do with headless scenarios but more >>> that the vast majority of ARM GPUs support GL-ES which is a >>> sub/different standard of desktop GL (sorry, I'm not a graphics >>> programming expert!) and the support for that in mesa and in general >>> is terrible. There was a proposal to refactor mesa and when I spoke to >>> ajax (I think, sorry ajax if it wasn't you) or someone it wasn't >>> basically moving forward upstream at the moment. I'm not sure who >>> originally was driving this (my google fu doesn't give me the mailing >>> list proposal ATM). >> >> It is getting a bit off the topic, but this it isn't really a problem >> with mesa. But rather that we have non-gallium closed src drivers >> from the GPU vendors in the ARM space, which only support GLES. And >> most/all of the desktop stuff packaged in fedora (in particular, >> gnome-shell) is requiring GL. > > This is incorrect. It uses cogl which has a gles renderer wich is supposed > Tod work. If it does not that is just a bug that we should fix. At least as packaged in f19, it seems to require GL. I know of people who have recompiled it, and supposedly have it working to some degree with GLES. Not sure if that was the same version as what is in f19, etc. Where possible, it would certainly be useful to get more stuff with GLES support in fedora. BR, -R > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
>> 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
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 2:42 PM, Adam Jackson wrote: > On Tue, 2013-07-16 at 13:00 +0200, drago01 wrote: > >> > It is getting a bit off the topic, but this it isn't really a >> problem >> > with mesa. But rather that we have non-gallium closed src drivers >> > from the GPU vendors in the ARM space, which only support GLES. And >> > most/all of the desktop stuff packaged in fedora (in particular, >> > gnome-shell) is requiring GL. >> >> This is incorrect. It uses cogl which has a gles renderer wich is >> supposed Tod work. If it does not that is just a bug that we should >> fix. > > Eh. Kind of. Yes, cogl has a gles backend, yes it should work, but X > itself also has a dependency on having GL below it. GLX 1.4 exposes > accumulation buffers, which exist in GL but not in GLES; not that > anything uses accum buffers, but their non-existence would technically > be a conformance failure for GLX. GLES doesn't have glBegin, so > xserver's implementation of glBegin, if done atop GLES, would need to > emulate it, and currently does not. And so on. > > More immediately, xserver's half of the GLX implementation requires not > just GL, but an actual DRI driver. Well we have an EGL backend ... I never tested it but shouldn't EGL+GLES work on X already? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
- 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/root171 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 s
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, 2013-07-16 at 13:00 +0200, drago01 wrote: > > It is getting a bit off the topic, but this it isn't really a > problem > > with mesa. But rather that we have non-gallium closed src drivers > > from the GPU vendors in the ARM space, which only support GLES. And > > most/all of the desktop stuff packaged in fedora (in particular, > > gnome-shell) is requiring GL. > > This is incorrect. It uses cogl which has a gles renderer wich is > supposed Tod work. If it does not that is just a bug that we should > fix. Eh. Kind of. Yes, cogl has a gles backend, yes it should work, but X itself also has a dependency on having GL below it. GLX 1.4 exposes accumulation buffers, which exist in GL but not in GLES; not that anything uses accum buffers, but their non-existence would technically be a conformance failure for GLX. GLES doesn't have glBegin, so xserver's implementation of glBegin, if done atop GLES, would need to emulate it, and currently does not. And so on. More immediately, xserver's half of the GLX implementation requires not just GL, but an actual DRI driver. I have an experimental git tree that starts fixing that [1] but currently it's a regression for Xorg since it hasn't yet grown a GLX-on-EGL provider. Still, once you fix that, you could set about porting xserver/glx/ to GLES. So, say you were running on such a closed-source driver. You could run cogl atop the GLES it provides, if you weren't also trying to run X as your window system. Admittedly we'd like to stop doing that too... [1] - http://cgit.freedesktop.org/~ajax/xserver/log/?h=glx - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
>> 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 do
Re: F20 System Wide Change: ARM as primary Architecture
- Original Message - > On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera 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 a
Re: F20 System Wide Change: ARM as primary Architecture
On Monday, July 15, 2013, Rob Clark wrote: > On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson wrote: >> On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: >>> On 07/11/2013 10:41 AM, Bill Nottingham wrote: Kernel, glibc, all the core library stacks. And I would argue that yes, this *includes* libGL. So llvmpipe needs fixed, outside of any desktops. Should we define the core functionality better? Probably. >>> >>> >>> I would argue that it does not include libGL because it's not a requirement >>> for headless deployment scenarios. Why would you argue for it? >> >> I would argue that it's nothing to do with headless scenarios but more >> that the vast majority of ARM GPUs support GL-ES which is a >> sub/different standard of desktop GL (sorry, I'm not a graphics >> programming expert!) and the support for that in mesa and in general >> is terrible. There was a proposal to refactor mesa and when I spoke to >> ajax (I think, sorry ajax if it wasn't you) or someone it wasn't >> basically moving forward upstream at the moment. I'm not sure who >> originally was driving this (my google fu doesn't give me the mailing >> list proposal ATM). > > It is getting a bit off the topic, but this it isn't really a problem > with mesa. But rather that we have non-gallium closed src drivers > from the GPU vendors in the ARM space, which only support GLES. And > most/all of the desktop stuff packaged in fedora (in particular, > gnome-shell) is requiring GL. This is incorrect. It uses cogl which has a gles renderer wich is supposed Tod work. If it does not that is just a bug that we should fix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 9:49 AM, Bastien Nocera 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 wrote: > > Adam Jackson (a...@redhat.com) said: > >> If we really wanted to talk about graphics on arm, we'd be talking about > >> writing drivers for GPUs. > > > > Is there any use to shipping freedreno and similar projects in Fedora ARM > > before they get to the upstream kernel? (I expect a brickbat from Josh > > fairly quickly for suggesting this.) > > I've been following the tegra and lima (Mali 400) upstream work pretty > closely but neither is actually usable for gnome-shell yet to be > worth, IMO, even to be packaging it in a third party package. In he > case of the freedreno while the work is cool the qualcomm SoC is > primarily shipped on phones and tablets [1] which isn't our primary > focus so while would be cool to support I'm unsure what the user > experience would be like if we did ship it. Side note there is > upstream multi platform support for the MSM SoCs now but I have no > idea how complete this is (eg AllWinner MP support is upstream but > it's still only core SoC/serial/mmc) > > Peter > > [1] I've seen one dev board > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 3:37 PM, Matthew Miller wrote: > On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: >> 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328 >> 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540 > > Often, people maintain a package because it's required for a certain use > case they have not necessarily for particular love for that package. That's > not the idea situation, but it's better than not having the package at all, > and crucially, it means the actual use case that someone cares about is > covered. Really? There's packages that have been built once and never updated that have CVEs and bugs that the "maintainer" never deals with. The vast majority of ARM build "issues" I've dealt with aren't ARM issues at all. They're maintainers not fixing problems or updating their own packages and when ever I fix a problem with a package with ARM problems I check the bugs and build problems against mainline and in the vast majority of cases the problems on ARM are actually problems on x86. > I'm sure Peter would be happy to have a co-maintainer for the syslinux > package. I'd volunteer, but I'm actually _also_ only interested in a small > subset of functionality and am not able to address the bigger picture > either. But if someone would show up and really want to do it justice, > *awesome*. So in a lot of cases ARM is only interested in a small subset of cases but I still fix other issues. Other maintainers pick up packages because they're only interested in a subset. I'll use llvm as an example here because ajax has openly said he's only interested in a subset and he openly quoted it earlier in the thread. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 1:08 PM, David Tardon wrote: > On Thu, Jul 11, 2013 at 06:06:04PM +, "Jóhann B. Guðmundsson" wrote: >> On 07/11/2013 02:04 PM, Miloslav Trmač wrote: >> >On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson" >> > wrote: >> >>Each sub-community ( be it spins be it various arch ) should need to >> >>provide >> >>the necessary QA/Releng resources from their sub-community ( if no such >> >>thing the relevant party needs to build one ) >> >That would be interesting and quite possibly very beneficial, however >> >the transition from the current system when most people "don't need to >> >care" would be a complex, longer-term cultural shift that shouldn't be >> >(and doesn't really need to be) a blocker for the ARM feature. >> >> I dont argue that this should be a blocker for architectures quite >> the opposite as far as I see it the only requirement for an >> architecture to be come a "primary" ( thou arguably those are >> outdated concepts as well ) is that all package currently build ( >> with the execption if they simply cannot work on a spesific >> architecture ) and be available for the community to use as lego >> bricks to shape and present to the world as they image in for that >> relevant hw. > > It is only a few weeks you argued that we should drop all packages that > are not "properly maintained". Actually from an ARM perspective that would be a bonus as I spend a lot more of my time fixing packages that are broken on mainline so that I can see if they build on ARM which in 80% ish of the cases just fixes the ARM build issues, in another 10% of cases updating the package to the latest upstream release fixes the ARM build issues, there's a percentage point or two where there's problems in the packaging or using non distro build options like CFLAGS. The vast majority of the packaging issues I deal with on ARM are not actually ARM specific and often fix the other secondary arches as well! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 9:08 AM, Adam Williamson wrote: > On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote: >> Adam Williamson 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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 5:32 AM, Matthew Garrett 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: >> On 07/11/2013 10:41 AM, Bill Nottingham wrote: >>> >>> Kernel, glibc, all the core library stacks. And I would argue that yes, >>> this >>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops. >>> Should >>> we define the core functionality better? Probably. >> >> >> I would argue that it does not include libGL because it's not a requirement >> for headless deployment scenarios. Why would you argue for it? > > I would argue that it's nothing to do with headless scenarios but more > that the vast majority of ARM GPUs support GL-ES which is a > sub/different standard of desktop GL (sorry, I'm not a graphics > programming expert!) and the support for that in mesa and in general > is terrible. There was a proposal to refactor mesa and when I spoke to > ajax (I think, sorry ajax if it wasn't you) or someone it wasn't > basically moving forward upstream at the moment. I'm not sure who > originally was driving this (my google fu doesn't give me the mailing > list proposal ATM). It is getting a bit off the topic, but this it isn't really a problem with mesa. But rather that we have non-gallium closed src drivers from the GPU vendors in the ARM space, which only support GLES. And most/all of the desktop stuff packaged in fedora (in particular, gnome-shell) is requiring GL. The desktop gallium mesa drivers, and also the intel mesa driver, all seem to support both GL and GLES reasonably well.. From a hw standpoint, while they may lack some features compared to desktop GPU, I think all the current mobile GPUs should support enough features in hardware to get gnome-shell running (possibly with some driver tricks, for example in freedreno I have to emulate quads with triangles). It wouldn't be enough for passing any GL compliance suite, but the requirements for gnome-shell are fairly basic. BR, -R > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: > >> > I'm afraid I can't agree. I like the simplicity of the model you're >> > proposing, but from a practical point of view, there is still a commonly >> > held perception that there is a 'product' called Fedora which is >> > basically composed of what you get if you go to get.fedoraproject.org, >> > download one of the things we push at you there, and install it. >> > Practically speaking, I believe we have to QA that 'thing called Fedora' >> > as a whole. I don't think your model quite matches what people perceive >> > Fedora to be. >> >> What's your definition of what people perceive Fedora to be? > > "What do we talk about when we talk about Fedora?" :) > > Well, we just did a major release. Go look on news.google.com for > "Fedora 19", or search for "Fedora 19 review", or just poke through a > few popular tech sites and forums. > > What do people do when they want to 'try Fedora 19'? They download the > primary image on the download page, which is the desktop live, and run > it. This is what they've _always_ done. Hmm I wouldn't be surprised if we had more Fedora users running on cloud instances now than we do on the desktop but there's no way to tell really. > Do you ever see anyone doing a minimal install and commenting on the > package loadout? Commenting on the actual interesting and difficult > technical changes that are what a distribution really does? No, they run > the live image for a couple of days, decide whether they think the > desktop background looks nice, say whether they liked the installer, and > bash GNOME 3 for a while. Or they run it in the cloud where it mostly just works and they don't give a hoot about a 10 year support cycle because their spun up image in some cases barely last 10 days and get on with their job and don't say a thing :-P > If we're really, really lucky they'll mention there are some other spins > available. In passing. Without ever downloading one. And that's about > it. Agree! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 4:53 PM, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham wrote: >> Adam Jackson (a...@redhat.com) said: >>> If we really wanted to talk about graphics on arm, we'd be talking about >>> writing drivers for GPUs. >> >> Is there any use to shipping freedreno and similar projects in Fedora ARM >> before they get to the upstream kernel? (I expect a brickbat from Josh >> fairly quickly for suggesting this.) > > I've been following the tegra and lima (Mali 400) upstream work pretty > closely but neither is actually usable for gnome-shell yet to be > worth, IMO, even to be packaging it in a third party package. In he > case of the freedreno while the work is cool the qualcomm SoC is > primarily shipped on phones and tablets [1] which isn't our primary > focus so while would be cool to support I'm unsure what the user > experience would be like if we did ship it. Side note there is > upstream multi platform support for the MSM SoCs now but I have no > idea how complete this is (eg AllWinner MP support is upstream but > it's still only core SoC/serial/mmc) fwiw, there are a few boards. Various iterations of dragonboard[1].. much cheaper than the pre-low-cost-community-board dev-boards of years gone by, but still a little bit on the pricey side. And then there is the inforce ifc6410[2] which is what the dragonboard should have been all along. Sadly it seems the devicetree support (which would be needed for multi-platform) is coming in newer SoC's than the apq8064. Or older (s3/msm8660). So for out of the box multi-platform fedora kernel, I think we are talking about some eventual successor to the ifc6410 board. I should note that the freescale iMX5.x devices also have an adreno a200 GPU.. which I've not had a chance to add support for yet, but it is on my TODO list somewhere. Along with a lot of other things. Although I'm not sure that I'd want to try to run gnome-shell at 1080p on this one. BR, -R [1] http://mydragonboard.org/ [2] http://www.inforcecomputing.com/product/moreinfo/ifc6410.html > Peter > > [1] I've seen one dev board > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 11:09 AM, Bill Nottingham wrote: If I'm understanding you, you would prefer that ARM be blessed with the stamp of being a 'primary' arch at the cost of dropping release targets, images, and featuresets that are made by and for the community now. I wouldn't put it like that. The ARM team isn't asking for a blessing, we're asking to have builds that block ARM also block x86. At a technical level, that is a fundamental part of what being primary is. Yes, there are other aspects, both practical (what is released) and philosophical (What is Fedora). It's the next logical step. If not now, when? When libGL is ready to go? I don't think I can support that - it seems awfully unfriendly to the community that exists now. You are proceeding from a misconception: This is a thought exercise- If ARM devices didn't have graphics would it still be essential for PA promotion that libGL for ARM work and be accelerated? There is no proposal to throw out the baby or the bathwater. This is about defining the threshold at which point armv7hl gets built along side i686 and x86_64. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: > On 07/11/2013 10:41 AM, Bill Nottingham wrote: >> >> Kernel, glibc, all the core library stacks. And I would argue that yes, >> this >> *includes* libGL. So llvmpipe needs fixed, outside of any desktops. >> Should >> we define the core functionality better? Probably. > > > I would argue that it does not include libGL because it's not a requirement > for headless deployment scenarios. Why would you argue for it? I would argue that it's nothing to do with headless scenarios but more that the vast majority of ARM GPUs support GL-ES which is a sub/different standard of desktop GL (sorry, I'm not a graphics programming expert!) and the support for that in mesa and in general is terrible. There was a proposal to refactor mesa and when I spoke to ajax (I think, sorry ajax if it wasn't you) or someone it wasn't basically moving forward upstream at the moment. I'm not sure who originally was driving this (my google fu doesn't give me the mailing list proposal ATM). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 7:22 PM, Peter Jones 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 7:21 PM, 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham wrote: > Adam Jackson (a...@redhat.com) said: >> If we really wanted to talk about graphics on arm, we'd be talking about >> writing drivers for GPUs. > > Is there any use to shipping freedreno and similar projects in Fedora ARM > before they get to the upstream kernel? (I expect a brickbat from Josh > fairly quickly for suggesting this.) I've been following the tegra and lima (Mali 400) upstream work pretty closely but neither is actually usable for gnome-shell yet to be worth, IMO, even to be packaging it in a third party package. In he case of the freedreno while the work is cool the qualcomm SoC is primarily shipped on phones and tablets [1] which isn't our primary focus so while would be cool to support I'm unsure what the user experience would be like if we did ship it. Side note there is upstream multi platform support for the MSM SoCs now but I have no idea how complete this is (eg AllWinner MP support is upstream but it's still only core SoC/serial/mmc) Peter [1] I've seen one dev board -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 06:09 PM, Bill Nottingham wrote: Brendan Conoboy (b...@redhat.com) said: On 07/11/2013 12:37 PM, Bill Nottingham wrote: Well, as I said (and you cut out) ... I do know what some people want ARM to be in terms of dense hypserscale servers (32/64-bit)... but the community that would be using Fedora ARM does seem to be targeting a wider array than that. ... The F19 ARM release released 5 desktop images. You seem to be arguing that the required featureset of ARM as a primary arch should only be for headless deployment, but the ARM community itself is saying otherwise. Interests differ between participants. If this was the only objection to moving ARM to the primary build system I would say let's drop graphics from official Fedora ARM support for the purposes of the move and make all graphical images respins or remixes. If I'm understanding you, you would prefer that ARM be blessed with the stamp of being a 'primary' arch at the cost of dropping release targets, images, and featuresets that are made by and for the community now. I don't think I can support that - it seems awfully unfriendly to the community that exists now. Having an default/release target has been awfully unfriendly to the community that exist and has existed at least since fc6 - f7 ( when we introduced live's even longer if you want to count KDE as well ) now and just recently with the mate desktop wanting to become default so I dont think that argument applies here since not everybody and every sub community and every ones contribution to the project is given equal treatment as things stand now. However features should apply to all arch primary or not unless they cant for some reason or another be applied to that architecture which then should be specifically noted in relevant section in the release notes. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Brendan Conoboy (b...@redhat.com) said: > On 07/11/2013 12:37 PM, Bill Nottingham wrote: > >Well, as I said (and you cut out) > >... > >I do know what some people want ARM to be in terms of dense > >hypserscale servers (32/64-bit)... but the community that would be using > >Fedora ARM does seem to be targeting a wider array than that. > >... > > > >The F19 ARM release released 5 desktop images. You seem to be arguing that > >the required featureset of ARM as a primary arch should only be for headless > >deployment, but the ARM community itself is saying otherwise. > > Interests differ between participants. If this was the only > objection to moving ARM to the primary build system I would say > let's drop graphics from official Fedora ARM support for the > purposes of the move and make all graphical images respins or > remixes. If I'm understanding you, you would prefer that ARM be blessed with the stamp of being a 'primary' arch at the cost of dropping release targets, images, and featuresets that are made by and for the community now. I don't think I can support that - it seems awfully unfriendly to the community that exists now. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 10:15 AM, Chris Tyler wrote: I think that's s/Arndale/Chromebook/ Same SoC, different peripherals sticking out. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, 2013-07-15 at 10:07 -0700, Brendan Conoboy wrote: > Some requisite patches weren't upstream in time for Fedora 19's 3.9 GA > kernel, but are in the 3.10 update. This means Arndale should be fully > supportable in Fedora 20. Meanwhile, there is an F19 remix for Arndale > using a later kernel: > > http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes I think that's s/Arndale/Chromebook/ -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 04:13 AM, Christopher Meng wrote: Agree, I have 2 Arndale now, its performance can beats any other v7 devices. But. I'm not sure if A15 can be fully supported. Currently I only see many A9 hardwares. Some requisite patches weren't upstream in time for Fedora 19's 3.9 GA kernel, but are in the 3.10 update. This means Arndale should be fully supportable in Fedora 20. Meanwhile, there is an F19 remix for Arndale using a later kernel: http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes Kudos to Jon Disnard for putting this together. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 11:00:32AM +0200, Jiri Eischmann wrote: > > S, speaking of which: > > https://fedoraproject.org/wiki/Changes/VisibleCloud > I think this is mixing up things together a bit. I don't think no one > thinks we can create an ISO that would work perfectly for all uses > (desktop, server, cloud,...). > IMHO the ideal situation should be: A user interested in Fedora goes to > fedoraproject.org and is asked "Do you want to run Fedora as desktop, > server or a cloud instance?" and each answer should give them one ISO, > the official default product of Fedora Project for that use. Yes, that's what I'm trying to suggest. (Well, just desktop and cloud; we'll leave traditional server aside for right now.) If it _doesn't_ look like that's what my proposal is suggesting, please let me know how and where I can fix it. > So it's ok to have a cloud version to download at > http://fedoraproject.org/get-fedora but I think we want to offer them > just one product for cloud, the one we're focused on the most, we test > the most, not all flavours we could possibly have: Matthew's compilation > for cloud, Joe's compilation for cloud,... What we're offering right now is the same image -- same bits on disk -- in different formats. Not different spins. There's significant advantage in having a run-in-every-cloud image and we're bending as much as possible to make it so. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
For the record: this is my last reply in this thread. I have better things to do... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 11:49:21AM +, "Jóhann B. Guðmundsson" wrote: > On 07/15/2013 07:42 AM, David Tardon wrote: > >On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: > >>On 07/12/2013 12:08 PM, David Tardon wrote: > > > >>I still think... > >> > >>We should limit the number of packages that individuals can maintain > >>so that they can effectively maintain them and as has been pointed > >>out many times with the arm architecture sub community that they are > >>willing to help with arm specific bugs not general ones bug the ones > >>but let's assume they don't which results in higher maintenance on > >>the relevant component which would results in fewer components that > >>individual could maintain since it would take more if his or her > >>time to maintain it. > >Could you try to use some punctuation? It is quite hard to parse your > >paragraph-long sentences... > > No I cannot not. As you want. But do not be surprised if people do not bother to read them. > > > > >>If you dont think maintainers are already overburden and them being > >>so does not directly affect not only those maintainers directly but > >>also the community in whole, let's just take Peter Jones for an > >>example an newly re-elected FESCO member. > >> > >>Not only does he not respond to bug reports like [1] > >Sorry, but that example is unconvincing. AFAIK there is no policy saying > >that every package must be kept at the newest version at every price. > >There might be a very good reason why it has not been updated. > >(Conversely, you have not provided any reason why it should be updated > >in the bug...) And syslinux is not exactly a key part of the distro. > > Never said they did or have so stop twisting my word to somehow aid > the point you are trying to make. You used it to support your own claim. Therefore you must have meant it that way. > > >An example: there has been a new release of mdds. I have not updated it > >in Fedora, because there has been an API change and libreoffice 4.1 does > >not build with it. By your reasoning this means mdds is not "actively > >maintained"... > > > >Seriously, world is not black and white, even if you are trying to see > >it that way. > > Irrelevant the point was to show that he did not respond to the bug > report this whole time not whether he went all the way and update > the component in the distribution and he is just one sample of many. It has exactly the same relevance as your own example. The point was to show that you cannot apply the same measure on everything. > > > >>but he also > >>ignores infrastructures tools [2] that exist for the sole purpose to > >>notify maintainers about new upstream releases ( and this is just > >The tool exists to _notify_ maintainers about new releases, not to > >_force_ them to update. > > Clarify when I did sat the tool was supposed to be used to force > maintainers to update? When you implied that ignoring it is somehow wrong. Either the maintainer is free to ignore the tool (in which case it is irrelevant to mention it here), or he is not (and it seems that you think this is true), in which case it effectively forces him to update. > >>Do you honestly think this is healthy for him or for the project in whole? > >I am not his nanny, so I cannot tell him what is good for him. And I am > >not in the habit of extrapolating from one accidental sample, > > This general problem in the distribution and not limited to Peter > himself so don't try to make this about him. You started it. > > > >>My solution to address problem like this and prevent "burnouts" in > >>the project ( although not officially concreted and proposed ) is > >>that we implement a form of a time share program for the project ( > >>which arguably should not be limited to package maintenance since > >>this in essence does affect all participants in the project ) and > >>maintainers simple sign in how much free time they have or are > >>willing to spare daily/weekly/monthly in the project and based on > >>those free hours he or she has, we should be able to calculate how > >>many components he or she can maintain which could be one if it has > >>an high maintenance burden or 10, 20 100 with low maintenance. > >This is completely unrealistic. There is no metric to measure a > >maintenance cost of a package. > > Yes there is you can set a baseline and measure against that like. > > * Dealing with a single simplest bug report takes/costs x amount of > your time. The bug reports are rarely "simplest". > * Updating your component to the latest upstream release takes/cost > x x amount of your time. No, it does not. Not all updates mean just uploading a new tarball and a few trivial changes to the spec. There are new dependencies, build problems etc. > > >And how could anyone know how much time > >he will be able to spend regularly on the project this week? Next month? > >Six months from now? The packagers here are _volunteers_. We need to > >mot
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 07:42 AM, David Tardon wrote: On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: On 07/12/2013 12:08 PM, David Tardon wrote: I dont argue that this should be a blocker for architectures quite the opposite as far as I see it the only requirement for an architecture to be come a "primary" ( thou arguably those are outdated concepts as well ) is that all package currently build ( with the execption if they simply cannot work on a spesific architecture ) and be available for the community to use as lego bricks to shape and present to the world as they image in for that relevant hw. It is only a few weeks you argued that we should drop all packages that are not "properly maintained". Before that, you wanted to limit the number of packages a person can maintain, (by your words) to ensure that he (or she) has enough time to maintain them. Now you think it is a good idea to add a whole new architecture, which means additional maintenance load for_every_ package. Could you try to be at least a bit consistent? I still think... We should drop all packages that are not "properly maintained" since it affect many communities including the hardware architects ones How? If a package fails to build (on PA), there are several means to resolve it less severe than dropping the package (provenpackagers, unresponsive maintainer process, escalation to FESCo). What do you mean how? It's the packagers/maintainers responsibility to ensure his or her component(s) work in the distribution proven packagers should not be used to clean up other maintainers mess in the distribution because they aren't paying attention to their component or do not have enough time to maintain it. since they would have ensure those packages that are not "properly maintained" would build for their architecture before they would become an primary architecture. They have to do it for all packages anyway. There is no requirement that a maintainer be able to fix arch-specific build problems himself and upstream might not be interested. I would think their time in the project would be better spent on components that are actively maintained but you apparently dont. I have not said anything like that. I just think your definition of the meaning of actively maintained (or properly maintained) is completely unrealistic. That is why I write it in quotes. Well obviously I dont think it's unrealistic that packagers and maintainers actually maintain their component in the distribution. I still think... We should limit the number of packages that individuals can maintain so that they can effectively maintain them and as has been pointed out many times with the arm architecture sub community that they are willing to help with arm specific bugs not general ones bug the ones but let's assume they don't which results in higher maintenance on the relevant component which would results in fewer components that individual could maintain since it would take more if his or her time to maintain it. Could you try to use some punctuation? It is quite hard to parse your paragraph-long sentences... No I cannot not. If you dont think maintainers are already overburden and them being so does not directly affect not only those maintainers directly but also the community in whole, let's just take Peter Jones for an example an newly re-elected FESCO member. Not only does he not respond to bug reports like [1] Sorry, but that example is unconvincing. AFAIK there is no policy saying that every package must be kept at the newest version at every price. There might be a very good reason why it has not been updated. (Conversely, you have not provided any reason why it should be updated in the bug...) And syslinux is not exactly a key part of the distro. Never said they did or have so stop twisting my word to somehow aid the point you are trying to make. An example: there has been a new release of mdds. I have not updated it in Fedora, because there has been an API change and libreoffice 4.1 does not build with it. By your reasoning this means mdds is not "actively maintained"... Seriously, world is not black and white, even if you are trying to see it that way. Irrelevant the point was to show that he did not respond to the bug report this whole time not whether he went all the way and update the component in the distribution and he is just one sample of many. but he also ignores infrastructures tools [2] that exist for the sole purpose to notify maintainers about new upstream releases ( and this is just The tool exists to _notify_ maintainers about new releases, not to _force_ them to update. Clarify when I did sat the tool was supposed to be used to force maintainers to update? one of his components which has 18 bugs assigned to it by my account ) but he thinks he has enough time to serve on fesco at the same time which requires him to do at least research into at least each ticket fi
Re: F20 System Wide Change: ARM as primary Architecture
在 2013-7-11 AM4:43，"Richard W.M. Jones" 写道： > 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Matthew Miller píše v Pá 12. 07. 2013 v 23:24 -0400: > On Thu, Jul 11, 2013 at 12:53:23PM -0700, Adam Williamson wrote: > > "What do we talk about when we talk about Fedora?" :) > > Well, we just did a major release. Go look on news.google.com for > > "Fedora 19", or search for "Fedora 19 review", or just poke through a > > few popular tech sites and forums. > > What do people do when they want to 'try Fedora 19'? They download the > > primary image on the download page, which is the desktop live, and run > > it. This is what they've _always_ done. > > Well, this is partly self-reinforcing, because it's what we clearly tell > people to do. See http://fedoraproject.org/get-fedora, or the Download Now > link on the front page. > > S, speaking of which: > https://fedoraproject.org/wiki/Changes/VisibleCloud I think this is mixing up things together a bit. I don't think no one thinks we can create an ISO that would work perfectly for all uses (desktop, server, cloud,...). IMHO the ideal situation should be: A user interested in Fedora goes to fedoraproject.org and is asked "Do you want to run Fedora as desktop, server or a cloud instance?" and each answer should give them one ISO, the official default product of Fedora Project for that use. But that doesn't mean we should overwhelm them with gazillion options for every use. So it's ok to have a cloud version to download at http://fedoraproject.org/get-fedora but I think we want to offer them just one product for cloud, the one we're focused on the most, we test the most, not all flavours we could possibly have: Matthew's compilation for cloud, Joe's compilation for cloud,... And the same applies to other uses such as desktop. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: > On 07/12/2013 12:08 PM, David Tardon wrote: > >>I dont argue that this should be a blocker for architectures quite > >>>the opposite as far as I see it the only requirement for an > >>>architecture to be come a "primary" ( thou arguably those are > >>>outdated concepts as well ) is that all package currently build ( > >>>with the execption if they simply cannot work on a spesific > >>>architecture ) and be available for the community to use as lego > >>>bricks to shape and present to the world as they image in for that > >>>relevant hw. > >It is only a few weeks you argued that we should drop all packages that > >are not "properly maintained". Before that, you wanted to limit the > >number of packages a person can maintain, (by your words) to ensure that > >he (or she) has enough time to maintain them. Now you think it is a good > >idea to add a whole new architecture, which means additional maintenance > >load for_every_ package. Could you try to be at least a bit consistent? > > > I still think... > > We should drop all packages that are not "properly maintained" since > it affect many communities including the hardware architects ones How? If a package fails to build (on PA), there are several means to resolve it less severe than dropping the package (provenpackagers, unresponsive maintainer process, escalation to FESCo). > since they would have ensure those packages that are not "properly > maintained" would build for their architecture before they would > become an primary architecture. They have to do it for all packages anyway. There is no requirement that a maintainer be able to fix arch-specific build problems himself and upstream might not be interested. > > I would think their time in the project would be better spent on > components that are actively maintained but you apparently dont. I have not said anything like that. I just think your definition of the meaning of actively maintained (or properly maintained) is completely unrealistic. That is why I write it in quotes. > > I still think... > > We should limit the number of packages that individuals can maintain > so that they can effectively maintain them and as has been pointed > out many times with the arm architecture sub community that they are > willing to help with arm specific bugs not general ones bug the ones > but let's assume they don't which results in higher maintenance on > the relevant component which would results in fewer components that > individual could maintain since it would take more if his or her > time to maintain it. Could you try to use some punctuation? It is quite hard to parse your paragraph-long sentences... > > If you dont think maintainers are already overburden and them being > so does not directly affect not only those maintainers directly but > also the community in whole, let's just take Peter Jones for an > example an newly re-elected FESCO member. > > Not only does he not respond to bug reports like [1] Sorry, but that example is unconvincing. AFAIK there is no policy saying that every package must be kept at the newest version at every price. There might be a very good reason why it has not been updated. (Conversely, you have not provided any reason why it should be updated in the bug...) And syslinux is not exactly a key part of the distro. An example: there has been a new release of mdds. I have not updated it in Fedora, because there has been an API change and libreoffice 4.1 does not build with it. By your reasoning this means mdds is not "actively maintained"... Seriously, world is not black and white, even if you are trying to see it that way. > but he also > ignores infrastructures tools [2] that exist for the sole purpose to > notify maintainers about new upstream releases ( and this is just The tool exists to _notify_ maintainers about new releases, not to _force_ them to update. > one of his components which has 18 bugs assigned to it by my account > ) but he thinks he has enough time to serve on fesco at the same > time which requires him to do at least research into at least each > ticket filed in the fesco tracker and review of system wide features > and how ack/nack those features will affect the community in whole. This is disrespectful to Peter. > > Do you honestly think this is healthy for him or for the project in whole? I am not his nanny, so I cannot tell him what is good for him. And I am not in the habit of extrapolating from one accidental sample, > > My solution to address problem like this and prevent "burnouts" in > the project ( although not officially concreted and proposed ) is > that we implement a form of a time share program for the project ( > which arguably should not be limited to package maintenance since > this in essence does affect all participants in the project ) and > maintainers simple sign in how much free time they have or are > willing to spare daily/we
Re: F20 System Wide Change: ARM as primary Architecture
On Sat, Jul 13, 2013 at 11:50:40AM -0500, Dennis Gilmore wrote: > On Sat, 13 Jul 2013 11:36:00 +0200 > Till Maas 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/armhfp/os/images/pxeboot/ > > > > 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/armhfp/os/LiveOS/ > > > (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/armhfp/Fedora-Images-armhfp-19-CHECKSUM > > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 13 Jul 2013 11:36:00 +0200 Till Maas 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/armhfp/os/images/pxeboot/ > > 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/armhfp/os/LiveOS/ > (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/armhfp/Fedora-Images-armhfp-19-CHECKSUM > But I noticed that here SHA1 is used instead of SHA256 for the GPG > signature and the comment about sha256sum being used to generate the > hashes is missing, e.g. the primary archs have files like these: > https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM probably a difference in the setup of the sigul between primary and secondary arches. the comment about sha256sum only ever exists in pungi generated CHECKSUMS all the manually generated ones which includes Live and Spins trees do not have it. if you want to change things i suggest you join Release engineering and help me to make things better rather than just complain that how I do things doesn't suit your needs. Release Engineering is me with a lot of help from Kevin Fenzi and over the last few releases a lot more has been asked from me which means many things that could have been done have not been. as is Both Kevin and I work a lot more than 40 hours. > Here is a ticket for this: > https://fedorahosted.org/fedora-infrastructure/ticket/3888 the ticket is for nothing mentioned in this email Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHhhWQACgkQkSxm47BaWfc8AgCgvO64NUjKAZIW55jf3lZ/zulF r4MAnj8tst7Q0iOSIFej0o0FbWSIYiHP =jAlW -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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/armhfp/os/images/pxeboot/ 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/armhfp/os/LiveOS/ (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/armhfp/Fedora-Images-armhfp-19-CHECKSUM 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 12:53:23PM -0700, Adam Williamson wrote: > "What do we talk about when we talk about Fedora?" :) > Well, we just did a major release. Go look on news.google.com for > "Fedora 19", or search for "Fedora 19 review", or just poke through a > few popular tech sites and forums. > What do people do when they want to 'try Fedora 19'? They download the > primary image on the download page, which is the desktop live, and run > it. This is what they've _always_ done. Well, this is partly self-reinforcing, because it's what we clearly tell people to do. See http://fedoraproject.org/get-fedora, or the Download Now link on the front page. S, speaking of which: https://fedoraproject.org/wiki/Changes/VisibleCloud -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> Also, I'm running the script now, I'll post results when it > finishes, let's not ALL hit the koji database at the same time ;-) Results here: http://www.delorie.com/arm/f19-times.html includes the raw time data from koji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 12 Jul 2013 18:40:21 +0200 Till Maas wrote: > On Fri, Jul 12, 2013 at 09:03:24AM +0200, Hans de Goede wrote: > > > As for the anaconda install support, my images will be a copy of: > > Fedora-XFCE-armhfp-19-1-sda.raw.xz with the kernel and uboot > > replaced > > + some other tweaks, but otherwise unmodified. So if that image can > > do anaconda installs, my images should be able to do it too > > (assuming there is no model specific code in anaconda which quite > > likely is wrong). > > The image name does not really sound like something that can be run > headless to install Fedora. I was expecting something more like a > kernel, a initrd and a pool of verifiable RPMs that can be used as > installation source. For example for x86 an installation iso image > would do, because it is GPG signed and contains everything to setup a > Fedora system that can install packages with package signature > verification. > > Is there something like this for ARM? The installation page does not > seem to mention this: > https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation we have a kernel and initramfs, that can be pxe booted or you can boot and load, however we have not made it the primary mathod of install for boards because they generally can only boot and run from a sdcard you would need to install to the boot media. it quite possibly works just fine other than not installing uboot to the sdcard in the way needed, however for non omap systems that copy the file into a partition it will likely work ok. so cubieboard since you need to dd u-boot into a particular location of the sdcard it should still be there post install. Its not tested at all however. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHgU6cACgkQkSxm47BaWfdCowCgpKgZ1y1/2QQsXLToQ6rzCTiX O2YAn2WgdCrPwzjMtxkT0joUUftC49I8 =7T8k -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
The stack-protector issue has been raised to priority number one for the library folks within the Linaro toolchain group. I have followed up with members of the toolchain and steering committees as appropriate to ensure this is going to be taken care of extremely swiftly. Next! -- Sent from my iPad On Jul 12, 2013, at 5:36, Jonathan Masters wrote: > Note that there are teams within Linaro doing benchmarking and driving such. > And once the specific stack protector issue was raised, I poked Marcus in > person and he escalated it such that it will be looked at this next > engineering cycle. In general we can plan ahead if we know there are issues. > We can't offer a 4 hour SLA. This isn't meant to be aimed at Jakub :) just > replying here. > > Btw, on a tangent, those throwing stones in the other subthreads need to bear > in mind no architecture can guarantee every feature at all times. If you > would like, we can scrub through and find something broken on x86 that a test > suite claims to work, and we can infer all kinds of insulting things from > that. But it will achieve nothing. Sometimes stuff just is unintentionally > broken. Audit was one such issue a year back - silent register corruption due > to a busted patch and lack of people historically using it to notice. But we > fixed that. And we will find more issues over time and fix those, especially > now that we have many folks running Fedora kernels and others in Linaro > ramping up on testing upstream with non-embedded configs. > > Jon. > > -- > Sent from my iPad > > On Jul 11, 2013, at 20:03, Jakub Jelinek wrote: > >> On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote: >>> On 07/11/2013 11:49 AM, Jakub Jelinek wrote: Stack guards are present, but using libssp, which is the fallback way, second class citizen and most likely slower than the standard way. E.g. the libssp stack guard setup always uses /dev/urandom, while I guess even on ARM kernel provides AT_RANDOM that can be just used. And I'd bet that even on ARM reading the stack guard via TLS (well, static only always, i.e. hardcoded offset from TLS register), especially for PIC, is faster than doing GOT read and two memory references. >>> >>> Thanks. Security-wise, is the implementation roughly equivalent in >>> what is protected against, albeit less efficient? >> >> Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise, >> but most probably it is just less efficient. Definitely something to be >> benchmarked, analyzed for code size etc. >> >> Jakub >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 11:50:00AM -0700, Brendan Conoboy wrote: > On 07/11/2013 11:38 AM, Till Maas wrote: > >https://bugzilla.redhat.com/show_bug.cgi?id=865022 > >It is currently closed, because I did not re-test anymore after it was > >announced that the device won't be supported anymore soon. > > Thanks. Since the last update we have added a dedicated ARM kernel > maintainer. Fedora 18 on armv5tel is still supported. If you would > like to pursue the issue further we will assist. Thank you, but since the device will not be supported by Fedora in about 6 months, I do not see much use in this. > >>Never been supported by Fedora ARM for lack of upstream kernel and > >>firmware license issues. It's a Seneca College remix, but AFAIK it > >>works great: > >> > >>http://pidora.ca/ > > > >Yes, but this is probably also a reason why there was little Fedora > >related outcome from the Hardware summer of fun. > > Not sure I follow. Before Pidora Seneca still supported the Pi on > armv5tel, as early as F13. The possibility to use a Remix is not that big promoted, therefore it was not clear to me that I could run Pidora on it with at least packages similar to Fedora. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, 12 Jul 2013 11:05:49 -0400 DJ Delorie wrote: > > > > http://www.delorie.com/arm/koji-compare-build-times.tar.gz > > > > HTTP request sent, awaiting response... 403 Forbidden > > 2013-07-12 08:53:13 ERROR 403: Forbidden. > > "wget" is blocked unless you're clueful enough to use the -U flag. > Consider it a spot check for "smart enough to not recursively download > my entire web server". > > The server should have told you that in the error message. It did not. Just forbidden. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> i will look at throwing together a script to give us some comparisons > between the build times on the different arches. > I've already done this, last time it came up... > http://www.delorie.com/arm/koji-compare-build-times.tar.gz Also, I'm running the script now, I'll post results when it finishes, let's not ALL hit the koji database at the same time ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> > http://www.delorie.com/arm/koji-compare-build-times.tar.gz > > HTTP request sent, awaiting response... 403 Forbidden > 2013-07-12 08:53:13 ERROR 403: Forbidden. "wget" is blocked unless you're clueful enough to use the -U flag. Consider it a spot check for "smart enough to not recursively download my entire web server". The server should have told you that in the error message. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, 12 Jul 2013 10:52:15 -0400 DJ Delorie wrote: > > > i will look at throwing together a script to give us some > > comparisons between the build times on the different arches. > > I've already done this, last time it came up... > > http://www.delorie.com/arm/koji-compare-build-times.tar.gz HTTP request sent, awaiting response... 403 Forbidden 2013-07-12 08:53:13 ERROR 403: Forbidden. :( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> i will look at throwing together a script to give us some comparisons > between the build times on the different arches. I've already done this, last time it came up... http://www.delorie.com/arm/koji-compare-build-times.tar.gz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 10:37:41AM -0400, Matthew Miller wrote: > On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328 > > 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540 > > Often, people maintain a package because it's required for a certain use > case they have not necessarily for particular love for that package. That's > not the idea situation, but it's better than not having the package at all, > and crucially, it means the actual use case that someone cares about is > covered. > > I'm sure Peter would be happy to have a co-maintainer for the syslinux > package. I'd volunteer, but I'm actually _also_ only interested in a small > subset of functionality and am not able to address the bigger picture > either. But if someone would show up and really want to do it justice, > *awesome*. FWIW, right now we can't update to 6.01 until we move to gnu-efi-3.0t, which we haven't done because there's some debugging which needs to be done there to avoid breaking the other packages that use it. It is on the radar, and something I hope to address in the next few weeks, with any luck. That said, this stuff is notoriously hard to debug, as you may have noticed. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: > 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328 > 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540 Often, people maintain a package because it's required for a certain use case they have not necessarily for particular love for that package. That's not the idea situation, but it's better than not having the package at all, and crucially, it means the actual use case that someone cares about is covered. I'm sure Peter would be happy to have a co-maintainer for the syslinux package. I'd volunteer, but I'm actually _also_ only interested in a small subset of functionality and am not able to address the bigger picture either. But if someone would show up and really want to do it justice, *awesome*. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/12/2013 12:08 PM, David Tardon wrote: I dont argue that this should be a blocker for architectures quite >the opposite as far as I see it the only requirement for an >architecture to be come a "primary" ( thou arguably those are >outdated concepts as well ) is that all package currently build ( >with the execption if they simply cannot work on a spesific >architecture ) and be available for the community to use as lego >bricks to shape and present to the world as they image in for that >relevant hw. It is only a few weeks you argued that we should drop all packages that are not "properly maintained". Before that, you wanted to limit the number of packages a person can maintain, (by your words) to ensure that he (or she) has enough time to maintain them. Now you think it is a good idea to add a whole new architecture, which means additional maintenance load for_every_ package. Could you try to be at least a bit consistent? I still think... We should drop all packages that are not "properly maintained" since it affect many communities including the hardware architects ones since they would have ensure those packages that are not "properly maintained" would build for their architecture before they would become an primary architecture. I would think their time in the project would be better spent on components that are actively maintained but you apparently dont. I still think... We should limit the number of packages that individuals can maintain so that they can effectively maintain them and as has been pointed out many times with the arm architecture sub community that they are willing to help with arm specific bugs not general ones bug the ones but let's assume they don't which results in higher maintenance on the relevant component which would results in fewer components that individual could maintain since it would take more if his or her time to maintain it. If you dont think maintainers are already overburden and them being so does not directly affect not only those maintainers directly but also the community in whole, let's just take Peter Jones for an example an newly re-elected FESCO member. Not only does he not respond to bug reports like [1] but he also ignores infrastructures tools [2] that exist for the sole purpose to notify maintainers about new upstream releases ( and this is just one of his components which has 18 bugs assigned to it by my account ) but he thinks he has enough time to serve on fesco at the same time which requires him to do at least research into at least each ticket filed in the fesco tracker and review of system wide features and how ack/nack those features will affect the community in whole. Do you honestly think this is healthy for him or for the project in whole? My solution to address problem like this and prevent "burnouts" in the project ( although not officially concreted and proposed ) is that we implement a form of a time share program for the project ( which arguably should not be limited to package maintenance since this in essence does affect all participants in the project ) and maintainers simple sign in how much free time they have or are willing to spare daily/weekly/monthly in the project and based on those free hours he or she has, we should be able to calculate how many components he or she can maintain which could be one if it has an high maintenance burden or 10, 20 100 with low maintenance. As more sign up to co-maintain component the more free time do the existing maintainers get, which they in turn can use to (co ) maintain another component or spend elsewhere in the project. Implementing something like this would have significantly reduce the number of components we have available with the increased stability and not only healthier project but healthier participants as well. In any case i'm not following how I was somehow being "inconsistent" with myself with my response and if you have any proposal to solve the previous mentioned problem in the distribution I'm all ears. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 06:06:04PM +, "Jóhann B. Guðmundsson" wrote: > On 07/11/2013 02:04 PM, Miloslav Trmač wrote: > >On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson" > > wrote: > >>Each sub-community ( be it spins be it various arch ) should need to provide > >>the necessary QA/Releng resources from their sub-community ( if no such > >>thing the relevant party needs to build one ) > >That would be interesting and quite possibly very beneficial, however > >the transition from the current system when most people "don't need to > >care" would be a complex, longer-term cultural shift that shouldn't be > >(and doesn't really need to be) a blocker for the ARM feature. > > I dont argue that this should be a blocker for architectures quite > the opposite as far as I see it the only requirement for an > architecture to be come a "primary" ( thou arguably those are > outdated concepts as well ) is that all package currently build ( > with the execption if they simply cannot work on a spesific > architecture ) and be available for the community to use as lego > bricks to shape and present to the world as they image in for that > relevant hw. It is only a few weeks you argued that we should drop all packages that are not "properly maintained". Before that, you wanted to limit the number of packages a person can maintain, (by your words) to ensure that he (or she) has enough time to maintain them. Now you think it is a good idea to add a whole new architecture, which means additional maintenance load for _every_ package. Could you try to be at least a bit consistent? D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 07:53 PM, Adam Williamson wrote: What's your definition of what people perceive Fedora to be? "What do we talk about when we talk about Fedora?":) Well, we just did a major release. Go look on news.google.com for "Fedora 19", or search for "Fedora 19 review", or just poke through a few popular tech sites and forums. What do people do when they want to 'try Fedora 19'? They download the primary image on the download page, which is the desktop live, and run it. This is what they've_always_ done. Do you ever see anyone doing a minimal install and commenting on the package loadout? Commenting on the actual interesting and difficult technical changes that are what a distribution really does? No, they run the live image for a couple of days, decide whether they think the desktop background looks nice, say whether they liked the installer, and bash GNOME 3 for a while. If we're really, really lucky they'll mention there are some other spins available. In passing. Without ever downloading one. And that's about it. That's presentation issue no more no less. Instead of actually providing our sub-communities with their own 3rd level domain under fedoraproject.org ( .fedoraproject.org ) which each include news,presentation download button for their release. We decide to belittle every sub-communites work and present only one. >Regardless of peoples perception or what you think they are there >still would be products however we QA would take care of the installer >+ base/core os bits and sub-communities that build upon that base/core >OS like Gnome takes care of QA their own spins. > >Who better are to QA their own spin then the people that a) use it b) >create it c) release it? People who want to do QA? I mean, that's why we have a QA team. You've been around longer than I have, but so far as I recall, the QA team has always been about doing more than simply testing the core OS. That's news to me anything else you want to share from the past which actually does not align with what got discussed and done in that era of "/Just do it"/. We always have been focusing on the installer and core components which is the primary function of QA as in to provide an installable and well working base os for others to build upon. You yourself know that the installer is the nr.1 cause for slippage and resource consumption from the QA community but if you rather want to play desktop testing instead of focusing on the things that actually matters to everyone in the community like the installer which install the components and allows users to use that desktop fine that's your choice. I must also confess to a personal interest here: if I'm expected to spend the rest of my professional life doing nothing but testing the goddamn installer I think I'll quit and start a yak farm. Is that really what you want us to do forever and ever amen? Apart from anything else, I find it*interesting* and*useful* to work on desktop testing... I have absolutely no idea what RH expects of you or wants you to do you as part of your job but if you want to click through Gnome instead of Anaconda it is fine and nobody is saying you should not do that just join their community and help them. If you want to change profession and start your own yak farm go ahead do it but that's just something you have to make up with yourself. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote: > Adam Williamson writes: > > > [...] "Primary Architectures : These are architectures with the > > majority of the users, the most common architectures. [...] > > By that standard, PA treatment of ARM seems way premature. XO 1.75, /endofthread ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Hi, On 07/11/2013 08:38 PM, Till Maas wrote: On Thu, Jul 11, 2013 at 08:58:11AM -0700, Brendan Conoboy wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
- Original Message - > From: "Dennis Gilmore" > To: devel@lists.fedoraproject.org > Sent: Friday, July 12, 2013 9:02:48 AM > Subject: Re: F20 System Wide Change: ARM as primary Architecture > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 11 Jul 2013 10:23:50 -0700 > Brendan Conoboy wrote: > > > On 07/11/2013 03:55 AM, Josh Boyer wrote: > > > I will note that it is not x86 alone. If one is simply going by "as > > > close to the current Fedora experience the current Primary offers", > > > then the PowerPC secondary arch team is actually ahead of ARM. I'm > > > not saying they are a better candidate, but I am pointing out that > > > the criteria Matthew is alluding to is being met by non-x86 > > > architectures. > > > > I'm not up-to-date on the current condition of Power: Are you > > specifically referring to GNOME & KDE? If so I'd posit that this is > > because GNOME & KDE make a lot more sense on Power than they do on > > ARM. Developer energy goes where it's needed & wanted. Prior to this > > discussion nobody was lamenting the state of gnome on their low power > > ARM system. We're still building them of course- all the GNOME and > > KDE packages are built, they're just not getting used AFAIK. > > I actually switched my chromebook over to KDE and used it on my > trimslice quite extensively. during the f19 cycle. > > > > I don't believe that is true. ARM is useful, I want it to be a > > > Primary arch, but I fail to see how your middle ground below of > > > having it be primary in the build system is going to somehow grow > > > Fedora. I believe there are concerns that it will place additional > > > burden on package maintainers (like ppc did before there was a real > > > arch team for it), and that those concerns are valid. > > > > Are those concerns valid? By what measure? Can they be controverted > > by evidence? Thus far we have pro and con anecdotes. > > > > > And yet did not include any of that information in your proposal. I > > > believe build times have improved. I also believe that you should > > > show it in the proposal so that it is clear you are addressing prior > > > concerns. I'm appreciate the effort spent to speed up the kernel > > > build times, but the concern is global. Show the work done in the > > > proposal with some simple numbers. > > i will look at throwing together a script to give us some comparisons > between the build times on the different arches. Phew, finally something meaningful :) . I was afraid that the major (at least for me) problem named "make it cost more time for packagers" will be plain ignored. Can we get a comparison for majority of packages and get some real point that will become too costy for packagers - aka build time of less than 20% of packages should be 5 or more times longer. I personally thing this is pretty low bar but some might argue that it's high so numbers put are just to serve as an example. Alexander Kurtakov Red Hat Eclipse team > > > These are good suggestions- thanks for that. > > > > > Again, I would like to see ARM as Primary and I believe the ARM team > > > has done a rather good job. Promoting anything to Primary has never > > > been done before, so bear with us as we work through it. > > > > Absolutely. Change is hard, but if all goes well this one will be > > popular in hindsight :-) > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iEYEARECAAYFAlHfnAgACgkQkSxm47BaWffSCACeN+s7FHECOv2u6I6uWAXEcvdX > 1W4AoK5y5BUyM49tLtSn+z0VTkBnMjIq > =txCb > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 11 Jul 2013 10:23:50 -0700 Brendan Conoboy wrote: > On 07/11/2013 03:55 AM, Josh Boyer wrote: > > I will note that it is not x86 alone. If one is simply going by "as > > close to the current Fedora experience the current Primary offers", > > then the PowerPC secondary arch team is actually ahead of ARM. I'm > > not saying they are a better candidate, but I am pointing out that > > the criteria Matthew is alluding to is being met by non-x86 > > architectures. > > I'm not up-to-date on the current condition of Power: Are you > specifically referring to GNOME & KDE? If so I'd posit that this is > because GNOME & KDE make a lot more sense on Power than they do on > ARM. Developer energy goes where it's needed & wanted. Prior to this > discussion nobody was lamenting the state of gnome on their low power > ARM system. We're still building them of course- all the GNOME and > KDE packages are built, they're just not getting used AFAIK. I actually switched my chromebook over to KDE and used it on my trimslice quite extensively. during the f19 cycle. > > I don't believe that is true. ARM is useful, I want it to be a > > Primary arch, but I fail to see how your middle ground below of > > having it be primary in the build system is going to somehow grow > > Fedora. I believe there are concerns that it will place additional > > burden on package maintainers (like ppc did before there was a real > > arch team for it), and that those concerns are valid. > > Are those concerns valid? By what measure? Can they be controverted > by evidence? Thus far we have pro and con anecdotes. > > > And yet did not include any of that information in your proposal. I > > believe build times have improved. I also believe that you should > > show it in the proposal so that it is clear you are addressing prior > > concerns. I'm appreciate the effort spent to speed up the kernel > > build times, but the concern is global. Show the work done in the > > proposal with some simple numbers. i will look at throwing together a script to give us some comparisons between the build times on the different arches. > These are good suggestions- thanks for that. > > > Again, I would like to see ARM as Primary and I believe the ARM team > > has done a rather good job. Promoting anything to Primary has never > > been done before, so bear with us as we work through it. > > Absolutely. Change is hard, but if all goes well this one will be > popular in hindsight :-) > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHfnAgACgkQkSxm47BaWffSCACeN+s7FHECOv2u6I6uWAXEcvdX 1W4AoK5y5BUyM49tLtSn+z0VTkBnMjIq =txCb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 12 Jul 2013 07:34:49 +0200 Jakub Jelinek wrote: > On Fri, Jul 12, 2013 at 12:36:16AM -0400, Jonathan Masters wrote: > > Note that there are teams within Linaro doing benchmarking and > > driving such. And once the specific stack protector issue was > > raised, I poked Marcus in person and he escalated it such that it > > will be looked at this next engineering cycle. In general we can > > plan ahead if we know there are issues. We can't offer a 4 hour > > SLA. This isn't meant to be aimed at Jakub :) just replying here. > > I hope my comments weren't considered as throwing stones on anybody, > all I wanted is that this is improved or at least analysed and > benchmarked. > > Jakub Jakub, I do not believe they were interpreted as such. we all are on the same team and want it to be better. I believe that Jon was just saying issue will be worked on and given priority, its just going to take some planning to do so. Other issues as they come up will also be addressed. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHfmw8ACgkQkSxm47BaWfcajwCeIXsI7jk2z4jcpSqxSmV8q35R ilkAn1JmWvHDXM8W5mu72fP9jbl9yHYY =jcM7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 12 Jul 2013 00:47:03 -0400 Rahul Sundaram wrote: > Hi > > > On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi wrote: > > > On Thu, 11 Jul 2013 23:50:24 -0400 > > Rahul Sundaram wrote: > > > > > > > False marketing. Majority of ARM devices out there don't run > > > Fedora and never will. > > > > Well, the same could be said for most x86 machines. ;) > > > > Not really. If one is more realistic and only count systems capable > > of > running Fedora, x86 clearly is far far more popular. ARM systems > will get more competitive in this space in the near future and we > should be prepared but we are not there yet and we should be honest > about that. Counting phones and tablets as ARM systems in the > context of Fedora is entirely misleading and folks promoting ARM > should stop doing that. > > Rahul I think you will find that only 1 has. There are many things that could be looked at down the road that are outside the scope of this change proposal. It is purely about removing 32 bit hardware floating point arm from secondary and making it primary. which entails building as primary, composing as primary, and shipping as primary. the things we build and ship, OEM images, pxe tree etc, are not part of this Change. There are lots of aspects of the ARM ecosystem that will evolve and get better over time. I personally believe that we are at the tipping point where ARM as primary is viable and something that Fedora should do in order to enable and be at the forefront of emerging technologies. I expect that down the road lots of new changes for ARM things will come. some of them probably wont be things for x86. We the ARM team have done a lot of work, and made a lot of improvements over the last year. not everything is perfect but nothing is. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHfmSYACgkQkSxm47BaWffPyACgiRARGytKiM2EUXWPz7D/wrGb fVwAoLj/RhenAKLNNHmyWyB8vHziwvuJ =OPTT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Hi On Fri, Jul 12, 2013 at 12:00 AM, Kevin Fenzi 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Jul 12, 2013, at 5:32, Matthew Garrett 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Note that there are teams within Linaro doing benchmarking and driving such. And once the specific stack protector issue was raised, I poked Marcus in person and he escalated it such that it will be looked at this next engineering cycle. In general we can plan ahead if we know there are issues. We can't offer a 4 hour SLA. This isn't meant to be aimed at Jakub :) just replying here. Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no architecture can guarantee every feature at all times. If you would like, we can scrub through and find something broken on x86 that a test suite claims to work, and we can infer all kinds of insulting things from that. But it will achieve nothing. Sometimes stuff just is unintentionally broken. Audit was one such issue a year back - silent register corruption due to a busted patch and lack of people historically using it to notice. But we fixed that. And we will find more issues over time and fix those, especially now that we have many folks running Fedora kernels and others in Linaro ramping up on testing upstream with non-embedded configs. Jon. -- Sent from my iPad On Jul 11, 2013, at 20:03, Jakub Jelinek wrote: > On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote: >> On 07/11/2013 11:49 AM, Jakub Jelinek wrote: >>> Stack guards are present, but using libssp, which is the fallback way, >>> second class citizen and most likely slower than the standard way. >>> E.g. the libssp stack guard setup always uses /dev/urandom, while I guess >>> even on ARM kernel provides AT_RANDOM that can be just used. >>> And I'd bet that even on ARM reading the stack guard via TLS (well, >>> static only always, i.e. hardcoded offset from TLS register), especially for >>> PIC, is faster than doing GOT read and two memory references. >> >> Thanks. Security-wise, is the implementation roughly equivalent in >> what is protected against, albeit less efficient? > > Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise, > but most probably it is just less efficient. Definitely something to be > benchmarked, analyzed for code size etc. > >Jakub > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote: > On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote: > > > Or does it mean x86 as PA is out of line? There are a lot more people > > > with ARM devices than x86. Sorry everybody, we're going to have to demote > > > x86. ;-) > > False marketing. Majority of ARM devices out there don't run Fedora and > > never will. > > Sooner or later, though, we probably _should_ deemphasize 32-bit x86. The website already links to 64-bit in preference to 32-bit. There's arguably reasons to prefer 32-bit in certain memory-constrained environments, but there's certainly arguments in favour of (say) dropping most of the 32-bit x86 package set and turning it into a specialised subset of the overall distribution. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> > 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 > 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 > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, 11 Jul 2013 23:50:24 -0400 Rahul Sundaram 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote: > > Or does it mean x86 as PA is out of line? There are a lot more people > > with ARM devices than x86. Sorry everybody, we're going to have to demote > > x86. ;-) > False marketing. Majority of ARM devices out there don't run Fedora and > never will. Sooner or later, though, we probably _should_ deemphasize 32-bit x86. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
