Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 00:48 -0300, Itamar Reis Peixoto wrote: On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. I agree, we must have a bootstrapping guide. We're going to deliver one after this armv7hl bootstrap. What we're going to do is get koji running with a minimal mock (or even once we get to just mock) and then re-run the bootstrap scripts automatically/rebuild the RPMs and hope that we caught every customization we needed. Those that were missed will be documented, then everything will be written up. Maybe not Shakespeare, but sufficiently. The wider problem that feeds from this is setting guidance. I'll throw some recommendations out there as a result of the bootstrap, not limited to just the two observations so far. Debian and others have much more comprehensive documentation on this stuff and that needs fixing. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 6:31 AM, Jon Masters j...@redhat.com wrote: We're going to deliver one after this armv7hl bootstrap. What we're going to do is get koji running with a minimal mock (or even once we get to just mock) and then re-run the bootstrap scripts automatically/rebuild the RPMs and hope that we caught every customization we needed. Those that were missed will be documented, then everything will be written up. Maybe not Shakespeare, but sufficiently. The wider problem that feeds from this is setting guidance. I'll throw some recommendations out there as a result of the bootstrap, not limited to just the two observations so far. Debian and others have much more comprehensive documentation on this stuff and that needs fixing. Jon. how hard is to add a flag bootstrap in rpm spec file to all base packages needed to start ? -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. I agree with Jon 100%. As folks know, I have been an ardent supporter of self-hosting since I started working with Linux (and RHL/Fedora) 12 years ago. I'm not alone in this position, and have had the help of many maintainers over the years to fix FTBFS bugs as I've uncovered and reported them - Thank You! However, I haven't had as much time to put into that effort recently as I believe it deserves. FESCo asked me to draft a procedure [1], a task from [2] for ensuring identified FTBFS packages were blocked, which I've done. But the procedure lacks a key component - identifying, through Fedora Project-maintained efforts (and not my own private efforts), the list of pacakges that FTBFS. That could be a rel-eng mass rebuild run. That could be a stand-alone rebuild effort. I'm not going to dictate. I have had some interest from individuals asking how they could help, but they seemed to be daunted by the need for a good deal of builder resources to do a mass rebuild in a reasonable amount of time. And unfortunately, I'm not in a position to put the builders I scrounged up on the public internet for use. If self-hosting and reliable package building is important to you, please chime in with ideas for how we can make this a standard part of the Fedora release process. [1] https://fedoraproject.org/wiki/Deprecate_FTBFS_packages [2] https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Finding builder resources for FTBFS (was: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY)
Matt Domsch wrote: But the procedure lacks a key component - identifying, through Fedora Project-maintained efforts (and not my own private efforts), the list of pacakges that FTBFS. That could be a rel-eng mass rebuild run. That could be a stand-alone rebuild effort. I'm not going to dictate. I have had some interest from individuals asking how they could help, but they seemed to be daunted by the need for a good deal of builder resources to do a mass rebuild in a reasonable amount of time. And unfortunately, I'm not in a position to put the builders I scrounged up on the public internet for use. I wonder if this could be done by distributed volunteer computing, perhaps as a BOINC project. From a security veiwpoint it may not be a good idea to install packages that have been built on some random dude's computer, but that's not a problem if we'll build them just to check that the build process works and won't actually use the built packages. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. This has been raised with FESCO in the past, and I don't think there's any fudnamental disagreement on it. But scheduling one mass rebuild per cycle doesn't prevent us ending up in a broken state unless we do it right at the end of the cycle, and right now that's problematic in terms of release process - rebuilding everything we've just QAed is an excellent way to introduce subtle breakage. So it really needs to be an out-of-archive verification rather than one that's targetted at the release, and we need the resources and manpower to handle it. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. My personal opinion is that bootstrapping is an intrinsically difficult and time consuming exercise. I'm enthusiastic about changes that make it easier, but not if they come at the cost of providing features that maintainers want to provide. It's rare for us to need to start an architecture from scratch, and I think optimising for rare cases is misguided. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 04:43:30PM +0100, Matthew Garrett wrote: On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. This has been raised with FESCO in the past, and I don't think there's any fudnamental disagreement on it. But scheduling one mass rebuild per cycle doesn't prevent us ending up in a broken state unless we do it right at the end of the cycle, and right now that's problematic in terms of release process - rebuilding everything we've just QAed is an excellent way to introduce subtle breakage. So it really needs to be an out-of-archive verification rather than one that's targetted at the release, and we need the resources and manpower to handle it. Alternately, we could take a lesson from our compatriots at openSUSE. Their openSUSE Build Service throws a combination of automated intelligence and hardware at the problem. Given the package dependency tree, if package B BuildRequires package A, then every time A gets rebuilt, B is also bumped and rebuilt. This causes build breakage to get caught fairly early in the process (rather than via an asynchronous out-of-tree process), and the resulting packages are available in their equivalent of the rawhide tree for test and use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 16:23 -0500, Matt Domsch wrote: On Sun, Jul 10, 2011 at 04:43:30PM +0100, Matthew Garrett wrote: On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. This has been raised with FESCO in the past, and I don't think there's any fudnamental disagreement on it. But scheduling one mass rebuild per cycle doesn't prevent us ending up in a broken state unless we do it right at the end of the cycle, and right now that's problematic in terms of release process - rebuilding everything we've just QAed is an excellent way to introduce subtle breakage. So it really needs to be an out-of-archive verification rather than one that's targetted at the release, and we need the resources and manpower to handle it. Alternately, we could take a lesson from our compatriots at openSUSE. Their openSUSE Build Service throws a combination of automated intelligence and hardware at the problem. Given the package dependency tree, if package B BuildRequires package A, then every time A gets rebuilt, B is also bumped and rebuilt. This is, in my opinion, the correct way to solve the problem. You can't really know if something FTBFS unless you do this kind of thing. I'd go further and advocate for sufficient hardware to continually rebuild everything daily and automate bootstrap like Debian are looking into, but that's all stuff for the future. This causes build breakage to get caught fairly early in the process (rather than via an asynchronous out-of-tree process), and the resulting packages are available in their equivalent of the rawhide tree for test and use. It doesn't just benefit bootstrap either. Take (random example) the recent CFLAGS change in redhat-rpm-config. What should happen at that point is that every package is automatically rebuilt. Should it cause a problem? No. But having packages randomly fail to build later because of some change made months or even years earlier is something to fix. I know I'm preaching to the choir here. There are many reasonable reasons why some of these problems exist, and it's no failure on the part of rel-eng folks, who do their best. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 05:31:09PM -0400, Jon Masters wrote: It doesn't just benefit bootstrap either. Take (random example) the recent CFLAGS change in redhat-rpm-config. What should happen at that point is that every package is automatically rebuilt. Should it cause a problem? No. But having packages randomly fail to build later because of some change made months or even years earlier is something to fix. That change was made based on the assumption that there'll be a mass rebuild in the F16 timescale. It's not practical for us to insist on mass rebuilds every time we make an individual change, especially since in this case we'd have had to do it again once it's moved to ldflags rather than cflags. It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: On Sun, Jul 10, 2011 at 05:31:09PM -0400, Jon Masters wrote: It doesn't just benefit bootstrap either. Take (random example) the recent CFLAGS change in redhat-rpm-config. What should happen at that point is that every package is automatically rebuilt. Should it cause a problem? No. But having packages randomly fail to build later because of some change made months or even years earlier is something to fix. That change was made based on the assumption that there'll be a mass rebuild in the F16 timescale. It's not practical for us to insist on mass rebuilds every time we make an individual change, especially since in this case we'd have had to do it again once it's moved to ldflags rather than cflags. It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I actually disagree. I've been working on rebuilding F-14 for the current softfp arm platform that doesn't need to be boot strapped. The amount of packages in Fedora 14 that don't compile on the main intel platform even if I do a plain vanilla F-14 install with no updates (ie it was broken on release and wasn't any better with any of the updates). There wasn't a mass rebuild for F-14, just for perl and python dependencies. Even with the F-15 mass rebuild I've found a number of packages that their owners never bothered to fix the FTBFS that was a result of the F-15 mass rebuild that have caused me problems that I've had to fix because the owner of the package never bothered to fix the FTBFS. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 22:44 +0100, Matthew Garrett wrote: It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I can think of specific cases where dependent packages failed to rebuild 6 months later because of an earlier change, and I'm sure we can find some involving years at a time. Further, there are some noarch packages that haven't been rebuilt in many releases, but that's another issue. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 06:12:38PM -0400, Jon Masters wrote: On Sun, 2011-07-10 at 22:44 +0100, Matthew Garrett wrote: It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I can think of specific cases where dependent packages failed to rebuild 6 months later because of an earlier change, and I'm sure we can find some involving years at a time. Further, there are some noarch packages that haven't been rebuilt in many releases, but that's another issue. 6 months isn't even one year, let alone many. Let's avoid hyperbole. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 11:11:52PM +0100, Peter Robinson wrote: On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I actually disagree. I've been working on rebuilding F-14 for the current softfp arm platform that doesn't need to be boot strapped. The amount of packages in Fedora 14 that don't compile on the main intel platform even if I do a plain vanilla F-14 install with no updates (ie it was broken on release and wasn't any better with any of the updates). There wasn't a mass rebuild for F-14, just for perl and python dependencies. Even with the F-15 mass rebuild I've found a number of packages that their owners never bothered to fix the FTBFS that was a result of the F-15 mass rebuild that have caused me problems that I've had to fix because the owner of the package never bothered to fix the FTBFS. Finding that something that didn't build, hasn't been changed and still doesn't build isn't terribly random :) We could do better, but introducing more mass rebuilds as part of the release cycle isn't going to make things significantly better when we're already failing to deal with the fallout from the mass rebuilds we *do* carry out. Fixing this is a process issue rather than one that's fixed by having FESCO mandate a mass rebuild after every change that could conceivably cause breakage. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 11:49 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: On Sun, Jul 10, 2011 at 11:11:52PM +0100, Peter Robinson wrote: On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote: It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I actually disagree. I've been working on rebuilding F-14 for the current softfp arm platform that doesn't need to be boot strapped. The amount of packages in Fedora 14 that don't compile on the main intel platform even if I do a plain vanilla F-14 install with no updates (ie it was broken on release and wasn't any better with any of the updates). There wasn't a mass rebuild for F-14, just for perl and python dependencies. Even with the F-15 mass rebuild I've found a number of packages that their owners never bothered to fix the FTBFS that was a result of the F-15 mass rebuild that have caused me problems that I've had to fix because the owner of the package never bothered to fix the FTBFS. Finding that something that didn't build, hasn't been changed and still doesn't build isn't terribly random :) We could do better, but introducing more mass rebuilds as part of the release cycle isn't going to make things significantly better when we're already failing to deal with the fallout from the mass rebuilds we *do* carry out. Fixing this is a process issue rather than one that's fixed by having FESCO mandate a mass rebuild after every change that could conceivably cause breakage. If a mass rebuild causes breakage its a problem which ever way you look at it, the package will eventually be rebuilt and cause the breakage, in my opinion your better off doing that in a controlled manner rather than sweeping it under the carpet and hoping no one will notice. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 11:59:36PM +0100, Peter Robinson wrote: On Sun, Jul 10, 2011 at 11:49 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: Finding that something that didn't build, hasn't been changed and still doesn't build isn't terribly random :) We could do better, but introducing more mass rebuilds as part of the release cycle isn't going to make things significantly better when we're already failing to deal with the fallout from the mass rebuilds we *do* carry out. Fixing this is a process issue rather than one that's fixed by having FESCO mandate a mass rebuild after every change that could conceivably cause breakage. If a mass rebuild causes breakage its a problem which ever way you look at it, the package will eventually be rebuilt and cause the breakage, in my opinion your better off doing that in a controlled manner rather than sweeping it under the carpet and hoping no one will notice. I agree, but if we're failing to deal with FTBFS with the number of mass rebuilds we currently have, introducing more mass rebuilds doesn't magically make things better. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. Thanks, Jon. I agree, we must have a bootstrapping guide. -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. Last week, we succeeded in reaching a point where we have a native RPM (and therefore rpmbuild) running, and we are therefore now entering what we call stage3 (stage1 was cross-compilation, stage2 was limited native building from the sources) in which we can build packages natively. Dennis has made some progress building python and a priority will be to get native packages built sufficient to have a python RPM. Once we have python, we then get to yum, mock, and finally Koji. At that point, we just have to rebuild everything twice more (once in rpmbuild, then use those bits in a full koji) before we can build the many more packages we will require for a self-hosted system! Lots of fun! :) You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110708 That page contains links to the general instructions on (note that documentation on stage3 is being updated, by me, at the moment - the above link has some notes sufficient for Friday, but these will be incorporated into the generic instructions I link to below): https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
Hi Folks, Join us on Friday to celebrate July with another in our series of VFADs! This is an awesome opportunity to participate in improving support for ARM processors, and to learn about architecture bootstrap. Last week, we successfully added a number of new packages to our bootstrap filesystem image and got closer to having a working F15 environment we can use to build official RPMs with hard floating point, on ARMv7 systems. It's never too soon or too late to help, and you can participate at any time, by following the instructions linked below - no need to wait for us, just let us know when you've got bits we can pull into the official rootfs (which is managed in git) we are building to bootstrap the rest. Don't forget that you can find out a lot more about the Fedora ARM project, and about getting involved by visiting the wiki: http://fedoraproject.org/wiki/Architectures/ARM Which also contains links to canned images you can use to drop onto your own ARM system and hit the ground running without any installation time. Awesomeness! Jon. --- Fedora ARM hardfp activity days --- We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day on Friday, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these be on Fridays. You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110701 That page contains links to the general instructions on: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Wed, 2011-06-29 at 09:14 +0200, Nikola Pajkovsky wrote: Refreshing news! What is pain in the ass is rhel6, because it doesn't have qemu-system-arm. I will play around with rhel6 and qemu-system-arm. Then I will try to build my packages for arm (if already aren't in). Is there a list of built packages? If you are internal, ping me and I can make available access to a couple of PandaBoards to save building up emulation bits (should be available ahead of Friday but not available yet). We're trying to do this natively, though I've nothing against using qemu if you'd like :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Wed, 2011-06-29 at 02:17 -0400, Jon Masters wrote: Hi Folks, Join us on Friday to celebrate July with another in our series of VFADs! Hi Jon, Just a heads up that you won't have many Canadians joining you -- July 1 is Canada Day, a *big* party date on our calendar. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
