Re: RFC: Primary architecture promotion requirements
On Mon, 2012-04-23 at 12:59 -0700, Brendan Conoboy wrote: It's not about anaconda specifically, it's about having a standard installer experience across all PAs to the extent technically sensible. Maybe something else will supplant anaconda in time. FWIW, in writing the QA release criteria, we used the generic term 'the installer' rather than the specific 'anaconda' to avoid this kind of ambiguity. In general I tend to prefer the use of generic terms in this kind of policy document for exactly this reason - to acknowledge and protect against the possibility of the currently-favoured implementation of any particular thing changing in future. -- 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: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 04:13:40PM -0400, Jared K. Smith wrote: On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. Just for the sake of argument, our Amazon EC2 images aren't using Anaconda for installation, but they're still considered part of Fedora. That's why I recently added EC2 support to livemedia-creator. Since I don't have an EC2 account it is untested -- help would be appreciated. I agree with the sentiment that Anaconda should be a requirement for instances where it makes sense to boot from bootable media (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the traditional installation method is often copy an image to an SD (or micro-SD) card and then boot from that card. Just to make sure I'm clear, are you insisting that the software tool that puts the image on the SD card be Anaconda, or are you OK with some other Fedora-approved tool for doing so? We should be able to make images using livemedia-creator -- It needs to be run on the target hardware though, currently there is no cross-arch support. The last I heard from ARM was that Anaconda wasn't built for ARM. The goal of creating lmc was to use Anaconda's logic for all installs, including creating system images or live media.. This will increase reliability and cut down on the number of bugs we see because livecd-creator really is just a wrapper around a yum chroot install. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpcYXr3qDGUi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Apr 24, 2012 at 1:05 PM, Brian C. Lane b...@redhat.com wrote: That's why I recently added EC2 support to livemedia-creator. Since I don't have an EC2 account it is untested -- help would be appreciated. Awesome. I'll try to check it out in the next week or so. We should be able to make images using livemedia-creator -- It needs to be run on the target hardware though, currently there is no cross-arch support. The last I heard from ARM was that Anaconda wasn't built for ARM. I know the folks up at Seneca have been working on building it for ARM -- I've been a bit out of the ARM loop the last couple of weeks, so I don't know the very latest status. I'll try to find out in tomorrow's ARM meeting. The goal of creating lmc was to use Anaconda's logic for all installs, including creating system images or live media.. This will increase reliability and cut down on the number of bugs we see because livecd-creator really is just a wrapper around a yum chroot install. Yes, I'm well aware of the goals behind lmc, and I think it's definitely a better way forward. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
After some tweaking, these are now accepted as https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 07:00 PM, Matthew Garrett wrote: After some tweaking, these are now accepted as https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Fail to see the reasoning why Anaconda and the Installer team are involved in these requirements care to elaborate how/why FESCo fits them into the bigger picture? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 07:33:44PM +, Jóhann B. Guðmundsson wrote: On 04/23/2012 07:00 PM, Matthew Garrett wrote: After some tweaking, these are now accepted as https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Fail to see the reasoning why Anaconda and the Installer team are involved in these requirements care to elaborate how/why FESCo fits them into the bigger picture? Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jóhann B. Guðmundsson (johan...@gmail.com) said: On 04/23/2012 07:00 PM, Matthew Garrett wrote: After some tweaking, these are now accepted as https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Fail to see the reasoning why Anaconda and the Installer team are involved in these requirements care to elaborate how/why FESCo fits them into the bigger picture? We shouldn't be promoting anything to primary arch that you can't install. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 07:42 PM, Matthew Garrett wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. So FESCo is in otherwords saying that other installers and even installing methods ( think like the distribution would be flashed to a device in the maybe not to distant future instead of being installed in the traditional sense as we know it to be ) are not allowed or otherwise considered to be part of the distribution should some community members want to writer and or package an alternative installer to ship and use on their spin? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
2012/4/23 Jóhann B. Guðmundsson johan...@gmail.com: On 04/23/2012 07:42 PM, Matthew Garrett wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. So FESCo is in otherwords saying that other installers and even installing methods ( think like the distribution would be flashed to a device in the maybe not to distant future instead of being installed in the traditional sense as we know it to be ) are not allowed or otherwise considered to be part of the distribution should some community members want to writer and or package an alternative installer to ship and use on their spin? I think it wasn't so much forbidding alternate methods as requiring that the primary one be supported. -J JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 12:54 PM, Jóhann B. Guðmundsson wrote: So FESCo is in otherwords saying that other installers and even installing methods ( think like the distribution would be flashed to a device in the maybe not to distant future instead of being installed in the traditional sense as we know it to be ) are not allowed or otherwise considered to be part of the distribution should some community members want to writer and or package an alternative installer to ship and use on their spin? It's not about anaconda specifically, it's about having a standard installer experience across all PAs to the extent technically sensible. Maybe something else will supplant anaconda in time. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 07:54:57PM +, Jóhann B. Guðmundsson wrote: On 04/23/2012 07:42 PM, Matthew Garrett wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. So FESCo is in otherwords saying that other installers and even installing methods ( think like the distribution would be flashed to a device in the maybe not to distant future instead of being installed in the traditional sense as we know it to be ) are not allowed or otherwise considered to be part of the distribution should some community members want to writer and or package an alternative installer to ship and use on their spin? Fesco is saying that if you have hardware that can install via Anaconda, you must support installing via Anaconda. It's legitimate for you to also have other install mechanisms, and hardware that's incapable of supporting Anaconda installs isn't required to have them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. Just for the sake of argument, our Amazon EC2 images aren't using Anaconda for installation, but they're still considered part of Fedora. I agree with the sentiment that Anaconda should be a requirement for instances where it makes sense to boot from bootable media (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the traditional installation method is often copy an image to an SD (or micro-SD) card and then boot from that card. Just to make sure I'm clear, are you insisting that the software tool that puts the image on the SD card be Anaconda, or are you OK with some other Fedora-approved tool for doing so? -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 4:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Fesco is saying that if you have hardware that can install via Anaconda, you must support installing via Anaconda. It's legitimate for you to also have other install mechanisms, and hardware that's incapable of supporting Anaconda installs isn't required to have them. Thanks for the clarification. I just wanted to make sure I understood that. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 3:13 PM, Jared K. Smith jsm...@fedoraproject.org wrote: On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Because if you have hardware that can install via Anaconda and you don't support installing via Anaconda, you're not Fedora. Just for the sake of argument, our Amazon EC2 images aren't using Anaconda for installation, but they're still considered part of Fedora. I think that's more akin to a spin. I agree with the sentiment that Anaconda should be a requirement for instances where it makes sense to boot from bootable media (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the traditional installation method is often copy an image to an SD (or micro-SD) card and then boot from that card. Just to make sure I'm clear, are you insisting that the software tool that puts the image on the SD card be Anaconda, or are you OK with some other Fedora-approved tool for doing so? -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 07:45 PM, Bill Nottingham wrote: We shouldn't be promoting anything to primary arch that you can't install. Valid point but it still does not explain why FESCo chose to limit that exclusively to Anaconda and the Installer team and their installation methods or lack there of. FESCo Sorry guys your arch will have to wait to become primary until Anaconda and the Installer team has a) Decided b) Designed c) Implemented How to install your arch. Wanting to be primary arch SIG But our user base already can install via this method here and we actually preferred they did.. FESCo Sorry no flag no country those are the rules so if you want to sail under the Fedora flag you have to ride the snake... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 08:29:59PM +, Jóhann B. Guðmundsson wrote: On 04/23/2012 07:45 PM, Bill Nottingham wrote: We shouldn't be promoting anything to primary arch that you can't install. Valid point but it still does not explain why FESCo chose to limit that exclusively to Anaconda and the Installer team and their installation methods or lack there of. ARM is moving into the server and laptop space. There's an expectation that devices of that nature can be installed using Anaconda. If a port is only supporting embedded devices where Anaconda makes no sense then that's fine, but if it's supporting other hardware classes then it needs to have a working Anaconda. I've no idea why this is controversial. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 08:14 PM, Jared K. Smith wrote: Fesco is saying that if you have hardware that can install via Anaconda, you must support installing via Anaconda. It's legitimate for you to also have other install mechanisms, and hardware that's incapable of supporting Anaconda installs isn't required to have them. Thanks for the clarification. I just wanted to make sure I understood that. FESCo should make that more clear in the requirements but even if they do they still make secondary architecture solely depended upon the will and the time of someone within the Installer team to implement the solution required to install Fedora for their architecture before they can become primary architecture. That can mean from never to having to wait for several release cycles before becoming primary architecture for the distribution. From my point of view that makes absolutly no sense and the requirements should be refactored to require an working installation method... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 08:57:47PM +, Jóhann B. Guðmundsson wrote: On 04/23/2012 08:14 PM, Jared K. Smith wrote: Fesco is saying that if you have hardware that can install via Anaconda, you must support installing via Anaconda. It's legitimate for you to also have other install mechanisms, and hardware that's incapable of supporting Anaconda installs isn't required to have them. Thanks for the clarification. I just wanted to make sure I understood that. FESCo should make that more clear in the requirements but even if they do they still make secondary architecture solely depended upon the will and the time of someone within the Installer team to implement the solution required to install Fedora for their architecture before they can become primary architecture. Yes, in the same way that they need someone in the kernel team to build them a kernel. It's a package. It's under active development. It just needs someone on the architecture to write the code. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jóhann B. Guðmundsson (johan...@gmail.com) said: On 04/23/2012 08:14 PM, Jared K. Smith wrote: Fesco is saying that if you have hardware that can install via Anaconda, you must support installing via Anaconda. It's legitimate for you to also have other install mechanisms, and hardware that's incapable of supporting Anaconda installs isn't required to have them. Thanks for the clarification. I just wanted to make sure I understood that. FESCo should make that more clear in the requirements but even if they do they still make secondary architecture solely depended upon the will and the time of someone within the Installer team to implement the solution required to install Fedora for their architecture before they can become primary architecture. There are these magical things called patches that can be submitted. Much like the secondary arch team would need to do so for the kernel (also mentioned in the guidelines), the X maintainers (also mentioned in the guidelines), etc. Unless you're suggesting secondary arch maintainers are somehow unable to do so? Fedora's about providing a consistent experience wherever possible; this means using consistent interactive installation tools, consistent image creation tools, and so on. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 04/23/2012 09:07 PM, Bill Nottingham wrote: Fedora's about providing a consistent experience wherever possible; this means using consistent interactive installation tools It's not enough to always be using the same tools but those tools need to be consitent in usage as well so for your noble goal now try putting consistency and Anaconda in the same sentence =) All jokes aside and focusing on a bit more broader but fundemental question so I and perhaps some others can get a better understanding why things are as they are in the 21 first century. Why do we distinquish between architectures in the first place and what do we hope to achive or otherwise gain from doing that in a community that first and foremost is about scratching your own itch ( at least for some of us )? What is the justification for the need for the seperation in the firstplace? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 23, 2012 at 10:08:54PM +, Jóhann B. Guðmundsson wrote: What is the justification for the need for the seperation in the firstplace? You'd be fine with Fedora m68k? We have the separation because it's not just about scratching your own itch. Each additional supported architecture means that teams who are already overworked have to look after even more moving parts. Architecture-specific bugs are a pain for package maintainers to deal with. Attaching the Fedora name to poorly maintained ports weakens our brand. If we're going to support an architecture then its maintainers need to prove that they can maintain it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 28, 2012 at 10:11:35PM +0100, Matthew Garrett wrote: I'm planning on moving this to the Wiki (as a draft) at the end of the week, so if people have any further feedback please let me know. Now at http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mon, Apr 2, 2012 at 4:45 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Now at http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 FESCo would welcome more discussion of this draft, and plans to vote on it next week. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
I'm planning on moving this to the Wiki (as a draft) at the end of the week, so if people have any further feedback please let me know. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler kevin.kof...@chello.at wrote: drago01 wrote: Those numbers look way better then Kevin's 50x slower without any citation ... thanks for getting this numbers. I'm surprised emulating ARM in QEMU is so much faster than qemu-system- x86_64 (which was how I measured the 50 times). Given that x86_64 is way more complex then ARM it is not *that* surprising. Are they really using QEMU for everything or are they actually using host or cross tools (and QEMU only for when the build process is trying to run a just built binary)? The later i.e cross tools + user emulation for binaries. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Thu, Mar 22, 2012 at 8:32 AM, drago01 drag...@gmail.com wrote: On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler kevin.kof...@chello.at wrote: drago01 wrote: Those numbers look way better then Kevin's 50x slower without any citation ... thanks for getting this numbers. I'm surprised emulating ARM in QEMU is so much faster than qemu-system- x86_64 (which was how I measured the 50 times). Given that x86_64 is way more complex then ARM it is not *that* surprising. Are they really using QEMU for everything or are they actually using host or cross tools (and QEMU only for when the build process is trying to run a just built binary)? The later i.e cross tools + user emulation for binaries. OK as Dennis said it seems they also run the compilers through qemu. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:59 PM, Brendan Conoboy b...@redhat.com wrote: On 03/21/2012 11:18 AM, drago01 wrote: But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? Native. OK kind of unexpected though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Thu, 2012-03-22 at 12:57 +0200, Nikos Roussos wrote: On Tue, Mar 20, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: What do people buy these days? Phones, tablets, and TVs. Not desktop computers. Citation needed. Desktop/notebook computers aren't going to go away any time soon. http://www.economist.com/node/21531109 with some interesting charts Which is actually confirmation of the previous sentence. The smartphones, tablets and similar devices together are growing much much faster than desktops and notebooks and are already much bigger market but they are not replacement for the desktops and notebooks. Which also supports the idea of having Fedora support both of these groups of computing devices well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Thu, Mar 22, 2012 at 11:27 AM, Tomas Mraz tm...@redhat.com wrote: On Thu, 2012-03-22 at 12:57 +0200, Nikos Roussos wrote: On Tue, Mar 20, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: What do people buy these days? Phones, tablets, and TVs. Not desktop computers. Citation needed. Desktop/notebook computers aren't going to go away any time soon. http://www.economist.com/node/21531109 with some interesting charts Which is actually confirmation of the previous sentence. The smartphones, tablets and similar devices together are growing much much faster than desktops and notebooks and are already much bigger market but they are not replacement for the desktops and notebooks. That depends, in the developed western world probably not, in the developing world most users are just going straight to smartphones and tablets and not bothering with desktops/laptops at all. The reasons for this is low power and price. In those areas desktops are dead and the increase in usage in this markets is 100s of millions of devices are year and for a lot of users it's their only means of accessing the internet and associated information. Which also supports the idea of having Fedora support both of these groups of computing devices well. Exactly one of the primary drivers for us to open up the discussion. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Mar 22, 2012, at 5:33 AM, Peter Robinson wrote: That depends, in the developed western world probably not, in the developing world most users are just going straight to smartphones and tablets and not bothering with desktops/laptops at all. The reasons for this is low power and price. Exactly. Power, price, infrastructure, space. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 6:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: Maybe a distribution of PandaBoards/R-Pi for every FAS account holder could help, any sponsor? :D OLPC is starting mass production of XO-1.75 units, based on an ARMv7 Marvell Armada 610. School kids in Uruguay and Nicaragua will start their school year with them, using a F14 ARM build. Peter Robinson has been instrumental in making this happen (and of course thanks to all the ARM porters). We have free units for Fedora developers that are interested -- we'll ship them for free anywhere in the world. The numbers are limited (we are a non-profit), apply for units here: http://wiki.laptop.org/go/Contributors_program#FAQ Some additional discussion: http://lists.fedoraproject.org/pipermail/arm/2011-July/001661.html In the form, you can state that your project is porting Fedora to ARMv7 ensuring it runs great on XO-1.75 :-) and mention what packages you're working on, or if you are or intend to be part of the Fedora ARM porters team, state so. We're on the fedora-arm mailing list, we'll know you :-) F17 upgrade is coming midyear, which will give these units a big kick in the pants in terms of performance. After that, we are cooking some bold sw+hw plans for the future. All based on ARM. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 06:51 PM, Brendan Conoboy wrote: On 03/20/2012 03:33 PM, Jesse Keating wrote: doing all of these things doesn't happen magically just because the board/fesco grants that ARM is suddenly a primary arch. If we made arm a primary arch tomorrow, you'd still have to solve all the above issues, only now you've got hundreds of very angry developers who's workflow is now severely interrupted, and they're all calling for your head. Doesn't it make more sense to solve these issues /before/ doing the promotion? Figure out how to make the car go 60mph before taking it onto the freeway, else you'll piss off all the other cars on the freeway. Absolutely. We're having this discussion as a way to solve the issues before promotion. None of us expect ARM to be promoted today, or tomorrow, but perhaps 3-5 months from now is realistic. Or maybe that's too soon. The bottom line is that there are issues to be worked out and that's what has prompted the discussion. I think this is the best takeway from the thread I've seen so far. We're trying to figure out where to go to get to PA. If it turns out F18 is wildly optimistic, ok, no problem. We'll come back later after we get all the kinks ironed out. But the past few days have provided invaluable initial input as we figure out how to drive at 60mph, while also giving you greater than 60mpg in power/performance :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:11:27PM -0500, Dennis Gilmore wrote: I have spoken with the OpenSUSE guys they dont use qemu-system-arm but rather qemu-arm and lay out things and build using a hybrid environment thats also how they build ppc s390 and other arches. the only build hardware they have is x86. doing full system emulation will be slower. In case it's not clear to the peanut gallery, qemu-system-arm and qemu-arm work in different ways. qemu-system-arm emulates a complete machine, so your ARM kernel is also running and being emulated. qemu-arm just emulates the userspace part of the program, but translates system calls from the program and runs them against the regular (x86-64 in this case) kernel. qemu-arm should be a lot faster, since the kernel part is running at full speed. On the other hand, there's some start-up overhead for every process run this way. I should also say that in both cases qemu's TCG emulation is reasonably smart, and recompiles guest ARM code on the fly down to native (x86-64 in this case) code. Recommended reading: http://lugatgt.org/content/qemu_internals/downloads/slides.pdf Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
drago01 wrote: On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler kevin.kof...@chello.at wrote: I'm surprised emulating ARM in QEMU is so much faster than qemu-system- x86_64 (which was how I measured the 50 times). Given that x86_64 is way more complex then ARM it is not *that* surprising. I think the fact that they're using userspace emulation rather than system emulation is actually the biggest difference to the setup I was using, and accounts for a significant part of the difference in slowdown. (Note that userspace emulation wasn't an option at all in my setup, for x86_64 on 32- bit x86.) To know for sure, we'd have to measure how long it takes to do builds with qemu-system-arm, assuming we can get that to work at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote: On 03/20/2012 12:44 PM, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, the all-or-nothing mindset between secondary and primary is almost certainly the root of the problem. We want more representation in Fedora than being a secondary connotes, Maybe you should begin by convincing package maintainers that ARM is a good platform (if it is; I do not know) and that they want to use it, instead of (figuratively speaking) shoving it down their throats by means of FESCo decision to promote ARM to primary arch. If you attract enough people, the transition may just happen naturally... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 13:44 -0600, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, this might be actually the best short-term path. Or rather than demoting the other secondary architectures to tertiary status just have different scale for various secondary architectures in terms of official infrastructure support. I can see automatic spawning of secondary builds for ARM in the main koji instance, use of main bodhi, etc., etc. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I took Qt as an example as it's a package I know. -- build.meego.com --- http://build.meego.com/package/show?package=qtproject=Trunk armv8el build19 started build qt.spec at Sat Nov 5 02:09:33 UTC 2011. build19 finished build qt.spec at Sat Nov 5 03:01:43 UTC 2011. approx. 1 hour i586 build17 started build qt.spec at Fri Nov 4 23:33:24 UTC 2011. build17 finished build qt.spec at Sat Nov 5 00:05:03 UTC 2011. approx. half hour (1/2) armv8el vs i586 factor of 2 http://build.meego.com/package/show?package=qtproject=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore armv7el build42 started build qt.spec at Thu May 12 08:49:50 UTC 2011. build42 finished build qt.spec at Thu May 12 10:42:21 UTC 2011. approx. 2 hours i586 build11 started build qt.spec at Thu May 12 08:49:48 UTC 2011. build11 finished build qt.spec at Thu May 12 09:09:47 UTC 2011. approx. armv7el vs i586 factor of 4 -- Fedora -- i686 2012-02-20 14:31:51,510 - Mock Version: 1.1.18 2012-02-20 15:05:21,089 - State Changed: end approx. half hour armv7hl 2012-03-18 17:58:09,566 - Mock Version: 1.1.18 2012-03-19 04:53:07,593 - State Changed: end better not calculating... So probably using Qemu could speed it up quite a lot. Also OBS offers Those numbers look way better then Kevin's 50x slower without any citation ... thanks for getting this numbers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, 2012-03-21 at 05:04 -0400, Jaroslav Reznik wrote: - Original Message - just a side note - I was told by an OpenSUSE on ARM person that they use x86 boxes with the user-space qemu virtual machine. It works quite fast, but still needs some hacking eg. in test-suites Yep, OpenSUSE uses qemu - it's sometimes not as stable as it should be, I saw a few strange random crashes in qemu but usually it works. I talked with them once, they were surprised by our native builds policy. Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. Fully-emulated actually fits into the Native Builds guideline, but it hasn't been economical to use this approach because there's no hardware support for ARM emulation on x86 (the way that there is hardware acceleration for x86 virtualization on x86) and it therefore requires a very fast/expensive x86 box to emulate a slow/cheap ARM box. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That's not to say there weren't a large number of people that _did_ try and fix things. It's just not a clear cut this arch is primary so package maintainers will fix arch issues. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote: 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. From a QA perspective, there's a fairly important instance of this case. We sometimes wind up working on very compressed timescales in validation sprints. We don't get very long to do validation. So it's not unusual for me to be bugging, say, the kernel team to give us a new kernel build that fixes a blocker bug, so we can do a new release candidate, so we can test the release candidate in twelve hours, so we can make the go/no-go meeting deadline the next morning. If builds get significantly slower, that could have a concrete impact on the release validation process: it's plausible that we'd either need to extend the validation period somewhat - earlier freezes - or we would have to eat a somewhat higher likelihood of release slippages. Thanks Adam, this is the first real use case where speed of builds is important for something other than keeping the developer happy. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. And we've already being doing that with the vast majority of issues already fixed and committed to mainline. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 10:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I took Qt as an example as it's a package I know. -- build.meego.com --- http://build.meego.com/package/show?package=qtproject=Trunk armv8el build19 started build qt.spec at Sat Nov 5 02:09:33 UTC 2011. build19 finished build qt.spec at Sat Nov 5 03:01:43 UTC 2011. approx. 1 hour i586 build17 started build qt.spec at Fri Nov 4 23:33:24 UTC 2011. build17 finished build qt.spec at Sat Nov 5 00:05:03 UTC 2011. approx. half hour (1/2) armv8el vs i586 factor of 2 http://build.meego.com/package/show?package=qtproject=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore armv7el build42 started build qt.spec at Thu May 12 08:49:50 UTC 2011. build42 finished build qt.spec at Thu May 12 10:42:21 UTC 2011. approx. 2 hours i586 build11 started build qt.spec at Thu May 12 08:49:48 UTC 2011. build11 finished build qt.spec at Thu May 12 09:09:47 UTC 2011. approx. armv7el vs i586 factor of 4 -- Fedora -- i686 2012-02-20 14:31:51,510 - Mock Version: 1.1.18 2012-02-20 15:05:21,089 - State Changed: end approx. half hour armv7hl 2012-03-18 17:58:09,566 - Mock Version: 1.1.18 2012-03-19 04:53:07,593 - State Changed: end better not calculating... So probably using Qemu could speed it up quite a lot. Also OBS offers quite a lot of flexibility to decouple arch builds, disable selected archs etc. But I'm not sure about the processes for chain builds, updates, how they make the builds consistent (if one arch fails)... All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Add to that 1Gb of RAM and swap the problem gets worse. The devices we're looking at have proper SATA ports (not over USB) and quad core 4GB RAM and the time to build is an order of magnitude faster, and those boards aren't overly stable as they're not production level HW so once we get our hands on production level versions of that HW we can start to properly test the difference in large packages such as gcc, qt, libreoffice and the kernel and will be able to much better ascertain the impact. I believe that should be soon although I'm not in direct contact. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:13 AM, David Tardon dtar...@redhat.com wrote: On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote: On 03/20/2012 12:44 PM, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, the all-or-nothing mindset between secondary and primary is almost certainly the root of the problem. We want more representation in Fedora than being a secondary connotes, Maybe you should begin by convincing package maintainers that ARM is a good platform (if it is; I do not know) and that they want to use it, instead of (figuratively speaking) shoving it down their throats by means of FESCo decision to promote ARM to primary arch. If you attract enough people, the transition may just happen naturally... There is no doubt it is a good platform, it's not about shoving it down people's throats, it's about making Fedora available on millions of devices that are cheap and low power. The transition is happening already and it happening due to cost and power, whether that be in the data centre running on servers or in the developing world. You just have to look at the millions of ARM based devices being sold in China, India and other parts of Asia. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:26:58PM +, Peter Robinson wrote: On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. And we've already being doing that with the vast majority of issues already fixed and committed to mainline. Agreed. I just mean that it's not a terribly significant benefit to becoming a primary architecture. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 1:52 PM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. TBH we need someone to take over the FTBFS things that Matt use to do, there's still 400+ packages that are FTBFS on x86 primary arch post the F-17 gcc 4.7 mass rebuild and even some going all the way back to the F-12 mass rebuilt (yes 3 mass rebuilds ago!). that number was actually much closer to 600 but the ARM team have fixed well over 100 of those on mainline because they were blocking what we were doing on ARM. Then once that is in place a means of tracking ExcludeArch/ExclusiveArch would be an excellent and very useful tool for all arches, primary or otherwise IMO. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. Possibly. There are ExcludeArch trackers that people are supposed to make their bugs block and that was normally sufficient to give the arch team a heads up. However, I'm sure there were packages that didn't have bugs filed like that. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. The buildroots get regenerated every time anyway, so journalling isn't really getting you anything. If a builder crashes, you probably want to throw the old buildroot away and start over anyway. out of curiousity, Is the setup of the builders documented somewhere ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 2:58 PM, Dave Jones da...@redhat.com wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. The buildroots get regenerated every time anyway, so journalling isn't really getting you anything. If a builder crashes, you probably want to throw the old buildroot away and start over anyway. out of curiousity, Is the setup of the builders documented somewhere ? I believe it is somewhere, the reference I had is completely out of date. The current configuration would not be the configuration used in primary arch but ultimately it was the best we could do with the platforms that were available 12-18 months ago. A lot has changed in that time. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
So probably using Qemu could speed it up quite a lot. Also OBS offers quite a lot of flexibility to decouple arch builds, disable selected archs etc. But I'm not sure about the processes for chain builds, updates, how they make the builds consistent (if one arch fails)... All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Add to that 1Gb of RAM and swap the problem gets worse. The devices we're looking at have proper SATA ports (not over USB) and quad core 4GB RAM and the time to build is an order of magnitude faster, and those boards aren't overly stable as they're not production level HW so once we get our hands on production level versions of that HW we can start to properly test the difference in large packages such as gcc, qt, libreoffice and the kernel and will be able to much better ascertain the impact. I believe that should be soon although I'm not in direct contact. It was more argument about real qemu speed from real deployment. Not bashing the current setup. It's better to have real data over just talking here :) 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: RFC: Primary architecture promotion requirements
On 03/21/2012 10:58 AM, Dave Jones wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. You could also turn off the journal in ext4. That'd lose the journal IO and stalls waiting for it and you'd still get the block mapping IO savings of delalloc and extents. - z -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:32:04AM -0400, Zach Brown wrote: On 03/21/2012 10:58 AM, Dave Jones wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. You could also turn off the journal in ext4. That'd lose the journal IO and stalls waiting for it and you'd still get the block mapping IO savings of delalloc and extents. Yes, that would be even better. (Hi Zab!) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 05:25 AM, Chris Tyler wrote: Fully-emulated actually fits into the Native Builds guideline, but it hasn't been economical to use this approach because there's no hardware support for ARM emulation on x86 (the way that there is hardware acceleration for x86 virtualization on x86) and it therefore requires a very fast/expensive x86 box to emulate a slow/cheap ARM box. The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 6:52 AM, Peter Jones wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. This sounds like the perfect use case for a SCM feature I haven't had the time to work on. If all commit diffs are sent to a message bus by way of a git hook, then one consumer on the bus could be canning for additions of ExcludeArch. When these are discovered a bug could be filed automatically, or some group would get notified, basically something would happen, and we wouldn't depend on a human noticing the change or following policy to file a bug. In the short term, if this is something we see high value in tracking, we can just add another git hook to do this directly, rather than relying on a message bus. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 10:36 AM, Brendan Conoboy wrote: The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. Arm emulation would go a long way toward validating produced install images too. Those of us that validate x86 images depend heavily on KVM and the like. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 06:26 AM, Peter Robinson wrote: Thanks Adam, this is the first real use case where speed of builds is important for something other than keeping the developer happy. Other points raised on the list are: 1. The nature of chainbuilds would feel slowed build times particularly. This is more of a multi-developer happy item. 2. Total turnaround time on security updates. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 06:07:57 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I have spoken with the OpenSUSE guys they dont use qemu-system-arm but rather qemu-arm and lay out things and build using a hybrid environment thats also how they build ppc s390 and other arches. the only build hardware they have is x86. doing full system emulation will be slower. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qGdQACgkQkSxm47BaWfcQ3gCfWys0mvR6MOKZRTj9hcopT92C OMgAn1/jXyJdJ7tvJAVsZiLZCU7MvJTk =6tKT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 10:12:58 -0400 Josh Boyer jwbo...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. Possibly. There are ExcludeArch trackers that people are supposed to make their bugs block and that was normally sufficient to give the arch team a heads up. However, I'm sure there were packages that didn't have bugs filed like that. the main issue is that we need to have tracking in place that doesnt require people do anything. because people dont do what they should. I see it all the time when dealing with mass rebuilds etc people do one or 2 of the steps to remove a package, but quite often do not do all 3. We do have plans to redo it to make it a single step. the more we can automate the tracking of it the better we will nknow the full extent of where things are. if we can cut down on what people have to do the more likely it will be that we have true representation of the data. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qG08ACgkQkSxm47BaWfcgZwCfUKuV7OhzKPIqvVQGMAmKb/Hf dPgAoKD8T6bqeLYKMXxvJJHQiINoxOFQ =pYET -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:11 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 06:07:57 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I have spoken with the OpenSUSE guys they dont use qemu-system-arm but rather qemu-arm and lay out things and build using a hybrid environment thats also how they build ppc s390 and other arches. the only build hardware they have is x86. doing full system emulation will be slower. Which is exactly what I proposed ... i.e use cross compilers and really on qemu to run stuff that gets generated and run during build. But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 11:18 AM, drago01 wrote: But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? Native. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 6:59 PM, Brendan Conoboy b...@redhat.com wrote: On 03/21/2012 11:18 AM, drago01 wrote: But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? Native. As do Debian I believe. I think, but aren't 100% sure, that all major distributions except suse build as native. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 02:13 PM, Peter Robinson wrote: As do Debian I believe. I think, but aren't 100% sure, that all major distributions except suse build as native. At the last Linaro Connect the Debian guys said they're building natively on i.MX53 boards (Which are cool because they have real SATA). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Actually debian hfp is built on efika smart tops. They have a 8gb ssd attached using pata and 512mb ram. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Brendan Conoboy b...@redhat.com wrote: On 03/21/2012 02:13 PM, Peter Robinson wrote: As do Debian I believe. I think, but aren't 100% sure, that all major distributions except suse build as native. At the last Linaro Connect the Debian guys said they're building natively on i.MX53 boards (Which are cool because they have real SATA). -- 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: RFC: Primary architecture promotion requirements
drago01 wrote: Those numbers look way better then Kevin's 50x slower without any citation ... thanks for getting this numbers. I'm surprised emulating ARM in QEMU is so much faster than qemu-system- x86_64 (which was how I measured the 50 times). Are they really using QEMU for everything or are they actually using host or cross tools (and QEMU only for when the build process is trying to run a just built binary)? That said, a factor of 2 to 4 is still too slow! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jesse Keating wrote: Arm emulation would go a long way toward validating produced install images too. Those of us that validate x86 images depend heavily on KVM and the like. But full system emulation is slower by a LARGE factor, not merely the 2 to 4 Jaroslav quoted for OBS, which (according to Dennis) is using a hybrid setup including some host and cross tools and QEMU userspace emulation as a fallback, NOT full system emulation. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Mar 2012 02:02:59 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Jesse Keating wrote: Arm emulation would go a long way toward validating produced install images too. Those of us that validate x86 images depend heavily on KVM and the like. But full system emulation is slower by a LARGE factor, not merely the 2 to 4 Jaroslav quoted for OBS, which (according to Dennis) is using a hybrid setup including some host and cross tools and QEMU userspace emulation as a fallback, NOT full system emulation. Kevin Kofler its not using cross tools at all and i never said it is. They use qemu-arm to run the processes they run all arm binaries. rather than emulating the full system they run the processes emulated. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qpwQACgkQkSxm47BaWff+GgCfcmHo7SspYuQXZDsxceXyU9VY pZsAoJH9xJcN6b4zJ/LgPtYtNN2n+Xlb =JO5R -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 03:19:35PM +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: ... 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Of course the general requirement that builds on the architecture to be promoted must not take much longer time than builds on the current primary architectures still stays. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:37 AM, Tomas Mraz tm...@redhat.com wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: ... 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. There's nothing blocking ARM from building multiple kernels in that requirement. They just need to all be enabled in the SRPM that gets sent to koji for the build. We do this for 32-bit x86 already by building both the normal and PAE i686 variants. The intention is to basically have a consistent and reproducible build for all kernels built from a single SRPM. I really don't think we want to enable additional kernels for final builds that have not been tested at all during development of the release. That doesn't make sense at all and sounds like poor engineering practice. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. That would be acceptable of course, and it would still fit with the requirement above just fine. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 04:37:17PM +0100, Tomas Mraz wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. The problem with not doing a full set of builds in rawhide is that it significantly reduces the testing - both in terms of making sure that code still bilds, and in terms of making sure that we don't have unexpected functional regressions. Shortly before release is a really bad time to discover this. My impression is that the kernel team don't want that to be a possibility. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Yes, there's no fundamental reason that these builds need to occur in series. If koji had support for exploding builds out to multiple machines then things would work much better. Another alternative might be to investigate whether distcc is practical in this environment. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:51 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Mar 20, 2012 at 04:37:17PM +0100, Tomas Mraz wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. The problem with not doing a full set of builds in rawhide is that it significantly reduces the testing - both in terms of making sure that code still bilds, and in terms of making sure that we don't have unexpected functional regressions. Shortly before release is a really bad time to discover this. My impression is that the kernel team don't want that to be a possibility. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Yes, there's no fundamental reason that these builds need to occur in series. If koji had support for exploding builds out to multiple machines then things would work much better. Another alternative might be to investigate whether distcc is practical in this environment. Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? -J -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:55:41AM -0500, Jon Ciesla wrote: Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? I was planning to after we'd had some discussion here, just to make sure I wasn't proposing anything too unreasonable. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:57 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Mar 20, 2012 at 10:55:41AM -0500, Jon Ciesla wrote: Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? I was planning to after we'd had some discussion here, just to make sure I wasn't proposing anything too unreasonable. Excellent. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? Actually, I hadn't thought about it that way before, but having a build fail on x86 or x86_64 would allow me to kill the ARM build and save load on the ARM buildsys. A win, if it's going to fail anyway. -J -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? I thought about this a bit yesterday. My conclusions are that it will impact people in 2 cases. 1) The build works fine on i686 and x86_64 and completes in the current normal time, but then the ARM build fails some number of minutes/hours later. For most packages, that likely isn't a big deal but for large packages like gcc and the kernel, I could have done exactly what you propose and downloaded the x86 results while waiting hours for ARM to complete and tested. If the ARM build fails while I'm doing that, I need to go and redo that testing after ARM is fixed because it failing will fail the entire koji build. 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? For the builds completed on some architectures, but waiting on others nothing is moved over to the packages/ dirs. Yes, you can grab them from the task directories, but only manually, scripts fetching testsuite results won't see them, it can't be filed into bodhi, in rawhide isn't tagged into the buildroots, etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
- Original Message - From: Josh Boyer jwbo...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Jakub Jelinek ja...@redhat.com, second...@lists.fedoraproject.org Sent: Tuesday, 20 March, 2012 4:08:16 PM Subject: Re: RFC: Primary architecture promotion requirements On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? I thought about this a bit yesterday. My conclusions are that it will impact people in 2 cases. 1) The build works fine on i686 and x86_64 and completes in the current normal time, but then the ARM build fails some number of minutes/hours later. For most packages, that likely isn't a big deal but for large packages like gcc and the kernel, I could have done exactly what you propose and downloaded the x86 results while waiting hours for ARM to complete and tested. If the ARM build fails while I'm doing that, I need to go and redo that testing after ARM is fixed because it failing will fail the entire koji build. 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. 3) chain builds in rawhide become slower. For X we do a lot of chain + dependency building, and I think the gnome guys do as well So now I have 12 packages to update, I need the first two to complete before I can get the next 10 etc, Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 04:58 PM, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? My #1 problem would be making packages compilable and bug-hunting arch-specific compilation problems. If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? Yes, because building primary archs first doesn't help when build-problems are secondary arch specific. That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 4:58 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. Well the solution seems rather obvious to me . There is no real (technical) reason why you cannot build on x86_64 hardware. I never ever built anything on ARM directly using cross compilers on an x86_64 host is orders of magnitude faster so I saw no reason to attempt to build on ARM. The ARM hardware I worked with had only 128MB of RAM and a 400Mhz CPU but the same should apply to modern ARM platforms too (i.e building on x86_64 is just the saner way). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 08:47 AM, Josh Boyer wrote: There's nothing blocking ARM from building multiple kernels in that requirement. They just need to all be enabled in the SRPM that gets sent to koji for the build. We do this for 32-bit x86 already by building both the normal and PAE i686 variants. The intention is to basically have a consistent and reproducible build for all kernels built from a single SRPM. This is infact what we're doing now- a single kernel build produces rpms for a number of different ARM platforms (omap, tegra, imx, versatile, etc). I really don't think we want to enable additional kernels for final builds that have not been tested at all during development of the release. That doesn't make sense at all and sounds like poor engineering practice. Agree. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. That would be acceptable of course, and it would still fit with the requirement above just fine. I'm not sure how it would work, but if koji can be extended to distribute a single arch build across multiple systems where an identical srpm can be built with a koji-controlled set of flags, this would take care of the wide-breadth of kernels needing to be built. We've also had some success with distcc, but have not proposed using it as reproducability of builds becomes an issue. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? Is cross-compilation a realistic option? In theory this would improve the speed of builds to something like the x86-64 speed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? We use cross-compilation right now for mingw-* packages (for Windows). However you cannot use cross-compilation to create a foo-*.armv7hl.rpm package. That's because our entire toolchain, from RPM through Koji, simply does not understand cross-compilation properly. Solvable, but undoubtedly a ton of work for everyone. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:37 AM, drago01 wrote: I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Okay, why not? The ones off the top of my head, and this is by no means exhaustive: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. 3. Absence of arm-linux cross compilers in the distribution. 4. If there were arm-linux cross compilers, how do you keep them in sync with native gcc? 5. Where does the sys-root for an arm-linux cross compiler come from? 6. Would koji then be native/cross ambidextrous? Who is going to do that? For all these reasons and more we're not proposing cross compilation for ARM. Just doing so defies what it means to be PA. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). In couple years the hardware is going to be surprisingly comparable or exceed to what you're see on x86, especially as the number of cores skyrockets while the GHz continue to climb. It's not a gimmick, we're just preparing for the future before it gets here. The only problem we face is that those cores are in multiple CPUs so we can't 'make -j' our way out of the build system problem. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:46 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? We use cross-compilation right now for mingw-* packages (for Windows). However you cannot use cross-compilation to create a foo-*.armv7hl.rpm package. That's because our entire toolchain, from RPM through Koji, simply does not understand cross-compilation properly. Solvable, but undoubtedly a ton of work for everyone. I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Hello, On 03/20/2012 12:37 PM, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Fedora generally doesn't cross-compile because you have to minimally run certain target configuration stuff on the host, and there are many other hardcoded expectations. [ Aside - skip this bit - because someone is going to mention it and take this thread onto a wild tangent, yes you can use distcc hacks, yes, there is/was Scratchbox, and yes there are many other cute hacks. We haven't proposed any of this because we want to be boring, we want to win acceptance by doing what x86 does in as many cases as reasonable. It isn't reasonable to expect ARM to install using Anaconda on a $25 target, but it is reasonable to expect on-target build ]. Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Next year, we're going to see Cortex A-15 systems that will be much faster still, and the year after, we're going to see 64-bit systems with at least 8 highly performing cores. It's not all about performance though. ARM isn't going to beat x86 in a speed race...that is not the goal. It's about aggregate performance, not individual node performance at the high end, and about mass availability at the low end. We can remain an x86-only primary distro. But that won't help address the longer term problems we will face. I'll spare the hyperbole for the moment, but I will add that this is a multi-year journey that we want to begin now. Yes, there are rough edges, yes this is cutting edge stuff, yes that is precisely what Fedora is all about. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. So, first of all, I disagree that there should be a process for promoting an architecture to primary in the first place. The set of primary architectures (x86_64, i686) should be set in stone unless a MAJOR change in hardware landscape happens, e.g. x86 gets discontinued by the hardware manufacturers and everyone uses ARM instead. I don't see that happening any time soon. Adding primary architectures puts a major burden on all Fedora maintainers. In the current state of things, I don't see a sufficient demand for making ARM (or even less any other secondary architecture) a primary architecture. If ARM is really the future as its proponents claim, we can revisit that in a few years. Not now. The focus should be on finding ways to make secondary architecture releases more timely (i.e. it's not acceptable that e.g. the stable ARM release is still Fedora 14 which doesn't even get security updates anymore), not to cheat around the problem by making ARM a primary architecture (which does not help all the other secondary architectures). Secondary architectures in Fedora are subject to looser constraints than primary architectures for two primary reasons: 1) To make it easier to bootstrap an architecture without the overhead of the primary architecture release engineering process 2) To avoid primary architecture development being held up by poorly developed or niche architectures 3) To avoid slowing down all builds by having to wait for the slow builders to complete them. 4) To avoid build failures caused by platform-specific toolchain bugs or limitations failing the entire build and forcing the maintainer to fix them. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: 1) There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. 2) All builds must occur on Fedora-maintained build servers. 3) Where technically possible, all supported hardware targets must be supported via Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for simultaneous support of install and target media. Why would we want to make such an architecture (the exceptions) primary?! 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. 5) Sufficient developer resources must be available to fix any architecture-specific issues in such a way that they do not delay overall Fedora development. 6) It must be possible for maintainers of critical-path hardware dependent packages to have direct access to supported hardware in order to rectify any release-blocking issues. For example, X maintainers must have direct access to any hardware with graphics capabilities. 7) The port must not rely on sourceless binaries unless they fall under the generic firmware exemption. Where source and toolchain are available, the binaries must be built in the Fedora build infrastructure. This lacks several important requirements: * The platform should actually have a significant market share. Why would we want to make an obscure niche device a primary architecture (even if it fulfills all the 7 requirements you listed)? Your criteria would even allow architectures to become primary which don't have anywhere near the market share even ARM has (let alone x86). * The builders should not take significantly longer to complete builds than the x86 builders. Otherwise builds (especially chain builds) will be slowed down by a lot. * The architecture needs to have sufficient support from the pool of Fedora maintainers as a whole, who will be on the hook for making their packages build for it. * The toolchain (port) needs to have sufficient quality to not cause tons of platform-specific bugs which are of no fault of the package. (We've had our fair share of those with ppc/ppc64, due to both bugs and bizarre TOC size limitations.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 12:56 PM, Brendan Conoboy wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Yup. I vote we shelve this part of the discussion in the interest of ever turning our proposal into something that will be accepted. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:37 AM, drago01 wrote: I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Okay, why not? The ones off the top of my head, and this is by no means exhaustive: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). I said technical so lets take policy aside ... 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. qemu? Should be still faster then doing the whole build on arm. 3. Absence of arm-linux cross compilers in the distribution. Err yeah but nothing that can't be fixed. 4. If there were arm-linux cross compilers, how do you keep them in sync with native gcc? Build from the same srpm. 5. Where does the sys-root for an arm-linux cross compiler come from? 6. Would koji then be native/cross ambidextrous? Who is going to do that? No real answers to them yet but fixing them seems to be easier then make arm as fast as x86_64. For all these reasons and more we're not proposing cross compilation for ARM. Just doing so defies what it means to be PA. We should somehow define what a PA is then. I wouldn't have added built on native hardware because that does not really seem to matter. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). In couple years the hardware is going to be surprisingly comparable or exceed to what you're see on x86, especially as the number of cores skyrockets while the GHz continue to climb. Might be true might be not ... we are talking about the next couple of months not years. It's not a gimmick, we're just preparing for the future before it gets here. The only problem we face is that those cores are in multiple CPUs so we can't 'make -j' our way out of the build system problem. Huh? Not sure I follow here. Also I am not opposed to having ARM as PA, I just don't really think we should do it the way it is proposed here (build on hardware that is way slower then the rest of the builders). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:57 PM, Jon Masters j...@redhat.com wrote: On 03/20/2012 12:56 PM, Brendan Conoboy wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Yup. I vote we shelve this part of the discussion in the interest of ever turning our proposal into something that will be accepted. OK fair enough (even though I still think that it is the only sane way to solve the build speed issue). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jakub Jelinek wrote: Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. Ouch!!! That shows that ARM should be the LAST architecture we consider for primary status rather than the first. (That said, I don't think it makes sense to make PPC primary again or to make S/390 primary. They don't have anywhere near the market share. But IMHO ARM doesn't have the market share either.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Brendan Conoboy wrote: Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? IMHO, at MOST 50% longer (factor 1.5) build time, and that's already being nice. You're off by a factor of 4! No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. That's exactly why we should stick with only x86 as primary architecture(s) in the foreseeable future. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? See the other replies: chain builds, updates, platform-specific errors, build results. A lot of things depend on the builds to actually complete. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Kevin Kofler wrote: But IMHO ARM doesn't have the market share either. Kevin, you don't know what you are talking about. Every cell phone has an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM cpu in it. Almost every tablet has an ARM cpu in it. What do people buy these days? Phones, tablets, and TVs. Not desktop computers. Hell, ARM is even building server boxes now (this is probably where Red Hat's interest is in). I'll enjoy calling up these emails 2 years from now when you're complaining that Fedora isn't ready for ARM (if we don't start now). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 18:08 +0100, Kevin Kofler wrote: Jakub Jelinek wrote: Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. Ouch!!! That shows that ARM should be the LAST architecture we consider for primary status rather than the first. (That said, I don't think it makes sense to make PPC primary again or to make S/390 primary. They don't have anywhere near the market share. But IMHO ARM doesn't have the market share either.) Can you define what market you refer to ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
