[fedora-arm] ARM Koji Downtime - Proposed: 2012-03-21 1300-2100 UTC
We need to do some testing on the buildsystem to iron out a few NFS issues and do some physical work. I propose taking the farm offline on Wednesday from 1300-2100 UTC (0800-1700 EDT), any objections? -Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Koji Downtime - Proposed: 2012-03-21 1300-2100 UTC
On Mar 19, 2012 8:41 PM, Chris Tyler ch...@tylers.info wrote: We need to do some testing on the buildsystem to iron out a few NFS issues and do some physical work. I propose taking the farm offline on Wednesday from 1300-2100 UTC (0800-1700 EDT), any objections? Fine with me. It would be great if you could check before hand if there's any large builds nearing completion but most importantly notify once complete or if there's any complications. Thanks foe the updates. Peter -Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
First stab at a few answers-- On Mon, 2012-03-19 at 16:46 -0700, Brendan Conoboy wrote: How are ARM-specific issues such as legacy alignment problems to be addressed? ARM v7 systems have hardware fixup for alignment issues, just as x86 does. ARM v5 systems can do fixup in software with a CPU trap at a small performance cost. (Note: there is a performance cost for hardware fixup, even on x86 systems) How do packagers test and resolve failures on ARM if they don't own an ARM device? There are several solutions available: 1. They can use emulation. Fedora already includes a good-quality ARM emulator (qemu-system-arm) that provides decent performance; we can package ready-to-run ARM images for that emulator. (This emulator can provide Kirkwood execution speeds on a modern x86 PC). 2. ARM computers can be bought for as little as $35 (the Raspberry Pi). 3. Packagers can use Koji for remote scratch builds (just as someone who only has 32-bit x86 can use Koji for 64-bit x86 builds). 4. We could consider setting up remote access to ARM systems (though this doesn't provide a lot of benefit over option 1 in most cases). When will server hardware be available? Real Soon Now(tm)! How about We anticipate early availability of ARM server systems in the summer of 2012. Why isn't being a secondary architecture good enough? 1. The user base is expected to grow to substantial numbers quickly. It is important to provide this user base with timely security updates and fixes, which can happen much more readily in primary arch than in secondary (which, even in the best case, lags behind PA). 2. As innovators in open source, we have an opportunity to take a leadership position by providing first-class support for emerging platforms such as the OLPC XO 1.75 and 3.0, the Raspberry Pi, and upcoming very-environmentally-friendly enterprise-class server systems, each of which supports an admirable goal. 3. The differences between ARM and x86 are not huge, and therefore cost of supporting ARM as a primary arch is not very high. ARM is little-endian (like x86), and nearly all of the libraries and languages in Fedora now support ARM (very different from even a few releases ago). (Needs strengthening) Why not wait for 64 bit ARM? 64 bit ARM is years away from general availability, let alone widespread use. Fully supporting 32-bit ARM now puts us in a solid position to support 64-bit enterprises systems as they appear. With there being so many different kernel variants, how will a kernel build complete in a reasonable period of time? The builds being done in Koji are great, but what is the plan for composes, QE and installation? Rootfs composes will be automated in much the same way that x86 spin composes are now automated. QE and installation will be different but not vastly more complex than in the x86 realm. (I think that we should explain the ARM install situation in terms of live image spin composes, because these have the greatest similarity -- the package selection is preset and not alterable during installation, for example). If Anaconda isn't used to do installations, what will be doing the things Anaconda does which just installing a bunch of packages doesn't? (I don't know what these are) These include: - setting up the partitioning - (in some cases) setting up the network configuration - setting the root password - selecting the timezone - selecting the locale and keyboard layout - (package selection, which does not apply to x86 live images) Several of these will need to move from Anaconda to firstboot (we're already working firstboot modules for a few of these for the Raspberry Pi). Will there be extra patches in the kernel to enable new vendors' ARM processors or will upstream continue to be the way? What does the kernel team think about the the time required to build kernels on ARM? How will it affect their workflow? Question: do we need to do a fully-clean build for each ARM SoC variant? Or can we do the machine and config changes for each and then make? The difference in time could be huge. The proposal suggests building just a versatile express kernel by default (to save time), then using koji flags to support alternate kernels. Is this possible? I think a better question is: Is this wise? This would mean that the majority of the ARM kernels won't be built or tested by default. (Also, do we mean Koji flags or do we mean editing the spec file to set macro values?) In the event that kernels are built separately per the above, what mechanism will be used to keep the kernels in sync? Assertions from the meeting: There must be a commitment of hardware both for build systems and test systems for PA. Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. FTBFS issues should simply be fixed (That's not an ARM
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 09:30 PM, Brendan Conoboy wrote: Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? We're only ever going to asymptotically approach the complete x86 package set so we're going to have to strike a middle ground. What that is is open for discussion, but basically it breaks down into 3 categories: 1. Packages that are truly x86 specific do not need to be made to work on ARM. And the packages that depend upon them hopefully don't either, but there's going to be some issues there. 2. Packages that FTBFS on x86 do not need to be made to work on ARM until they're also made to work on x86. 3. Anything left can and should be made to work on ARM. How many packages are in this set? If it's down to a few dozen let's just fix them up and be done with it. If it's a few hundred we need a plan that involves getting to primary before we're at 100%. So, basically, we need data. What packages fit where in the above 3 categories? How close are we? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On Mon, 2012-03-19 at 21:38 -0700, Brendan Conoboy wrote: 1. Packages that are truly x86 specific do not need to be made to work on ARM. And the packages that depend upon them hopefully don't either, but there's going to be some issues there. Note that this goes both ways - there are a couple of ARM packages that don't make sense on x86, too, since they're low-level, system-specific pieces. -Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 04:46 PM, Brendan Conoboy wrote: How do packagers test and resolve failures on ARM if they don't own an ARM device? I like Chris's suggestion of the simulator- that's good coverage. I'd also support providing login hosts to... somewhere. Seneca? Spare systems in PHX? I'm not sure, but it seems like a good idea to me. When will server hardware be available? During the discussion I said 2-5 months. Notting said 2 was good, 5 was bad. I'll just extrapolate that 3 is not as good and 4 isn't as bad, but ultimately it's going to be when the hardware is available. Hopefully it'll be closer to the 2 than the 5. Why isn't being a secondary architecture good enough? Greater stability in PHX, faster infrastructure, wider mirror selection, greater credibility as a distribution. Why not wait for 64 bit ARM? The mainstay of 64 bit ARM hardware won't be available for a couple years. Incredible ARM systems will be available in the interim that Fedora can run on with comparatively little effort. Additionally, much of what's needed on 64 bit ARM can be done in the 32 bit space (Virtualization support for instance). With there being so many different kernel variants, how will a kernel build complete in a reasonable period of time? Beats me- every proposal is a bit hackish. The builds being done in Koji are great, but what is the plan for composes, QE and installation? This part of the plan really needs some work. Even our discussions about how to compose images isn't quite the same as how to handle QE when it comes time to do an alpha/beta/rc/etc. If Anaconda isn't used to do installations, what will be doing the things Anaconda does which just installing a bunch of packages doesn't? (I don't know what these are) I would hope the standard image builders handle this sort of thing, but do not know. Will there be extra patches in the kernel to enable new vendors' ARM processors or will upstream continue to be the way? Jon answered that it will be upstream only. I agree. Same policy as x86. What does the kernel team think about the the time required to build kernels on ARM? How will it affect their workflow? I suspect Jon is going to discuss with kernel@. The proposal suggests building just a versatile express kernel by default (to save time), then using koji flags to support alternate kernels. Is this possible? According to Dennis: No. So, let's figure out how to get reasonable build times and good breadth on kernel builds. In the event that kernels are built separately per the above, what mechanism will be used to keep the kernels in sync? We may need to have a less ambitious list of kernels. Perhaps keep omap, tegra, highbank, but drop IMX, armada, etc. We'll see where this goes. Assertions from the meeting: There must be a commitment of hardware both for build systems and test systems for PA. In light of qemu+versatile the general test systems might be optional, but in principle if we have systems to spare and appropriate access mechanisms I don't see why not. Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? FTBFS issues should simply be fixed (That's not an ARM problem, but we're definitely impacted by it). Suggest presenting the FTBFS list and subtracting it from the list of packages we need for ARM task list. The changes to QE, particularly because of Anaconda, will be substantial. This is not addressed in the proposal. Agree. Help! Installability doesn't necessarily mean Anaconda (See EC2), but it does mean something. A real plan is called for. We just need to formalize our plan for image generation using standard tools (Hopefully whatever was used for EC2 is valid here). All PA kernels must be derived from the same source rpm. Yes. ... Regarding mail to the 4 groups, What do we want to ask each of them? Releng: Do you have any concerns about moving ARM to PA? What are the things you need to see in place? What do you not want to own? Infrastructure: Do we have the hardware/budget ready? What do you need in place that isn't now? What do you not want to own? QE: What do you need to do proper QE on arm? How much load will this add? How can we help? Kernel: ARM will introduce build time delays, but x86 builds will still finish as fast as ever. Is this sufficient? What do you need to see to be okay with ARM on PA? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org
