Are there OpenOffice RPMs available for Fedora 12? I'm trying to build the src.rpm from RHEL6b2 on F12 ARM, but the machine has only 450MB of RAM, so it OOMs during the build. Are there any pre-built binary RPMs available?
Gordan
It doesn't look like there is.
I'm not saying you are wrong or it wont work to use the RHEL6b2 version, but if I was going to build them from scratch, I would probably use the f12 src. OO has a lot of dependencies.
To get around the OOM issue, just add a swap file. Here is a quick how-to if you aren't familiar.
http://www.linux.com/archive/feature/113956
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Quoting Gordan Bobic gordan@bobich.net:
Are there OpenOffice RPMs available for Fedora 12? I'm trying to build the src.rpm from RHEL6b2 on F12 ARM, but the machine has only 450MB of RAM, so it OOMs during the build. Are there any pre-built binary RPMs available?
Gordan
omalleys@msu.edu wrote:
It doesn't look like there is.
I'm not saying you are wrong or it wont work to use the RHEL6b2 version, but if I was going to build them from scratch, I would probably use the f12 src. OO has a lot of dependencies.
I already resolved the dependencies. F12 was 3.1.0, and RHEL6b2 was 3.2.1, so I went with the latter.
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
To get around the OOM issue, just add a swap file. Here is a quick how-to if you aren't familiar.
I'm prefectly aware of how to add a swap file, thanks. I've only been doing this for 20 years or so. :p
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Going through the 3rd attempt now. Let's hope the 16GB USB stick proves to be big enough to hold the build directory...
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
Gordan
Quoting Gordan Bobic gordan@bobich.net:
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
It probably should be reported to the mainline but Im not sure it can be fixed either.. :)
You can probably do a rpm -ivh openssl-devel krb5-devel
then rebuild one and install, then rebuild the other and install and then rebuild the first one again.. that seems convoluted, but you have to recompile gcc 3 times in order to get the bootstrap right too.
Im not sure exactly how important it is given usually you are using the shared libs anyway.
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
no idea. I was trying to figure that out as well. It seems like they need to be reported in both places since they need to be fixed eventually by the official package maintainer
To get around the OOM issue, just add a swap file. Here is a quick how-to if you aren't familiar.
I'm prefectly aware of how to add a swap file, thanks. I've only been doing this for 20 years or so. :p
I didn't know. :)
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
fwiw, when i did kernel build time testing with the guruplug. I tried nfs, and a usb/esata drive plugged into either port. nfs with the nosync option was the fastest (50 minutes) and both esata and usb2 were roughly the same time at 60 minutes.
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
Going through the 3rd attempt now. Let's hope the 16GB USB stick proves to be big enough to hold the build directory...
hopefully. :)
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@bobich.net:
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
It probably should be reported to the mainline but Im not sure it can be fixed either.. :)
But isn't F12 deprecated now? We're so far behind with the ARM port that by the time it's there, it's already deprecated by a Fedora version 2 versions newer.
You can probably do a rpm -ivh openssl-devel krb5-devel
IIRC, the reason why I couldn't do that was because krb5 was missing from the F12 ARM repository I had to build it, but IIRC, openssl-devel wasn't there, either.
Looking at the timestamps, I had to rebuild openssl from src.rpm to get the openssl-devel, then krb5. Needed krb5 for some KDE deppendencies, in order to build konversation.
I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine.
Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up?
then rebuild one and install, then rebuild the other and install and then rebuild the first one again.. that seems convoluted, but you have to recompile gcc 3 times in order to get the bootstrap right too.
Yeah, I know. :(
Im not sure exactly how important it is given usually you are using the shared libs anyway.
It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages.
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
no idea. I was trying to figure that out as well. It seems like they need to be reported in both places since they need to be fixed eventually by the official package maintainer
Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate?
Have you got a URL handy for the Fedora ARM bugzilla?
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
fwiw, when i did kernel build time testing with the guruplug. I tried nfs, and a usb/esata drive plugged into either port. nfs with the nosync option was the fastest (50 minutes) and both esata and usb2 were roughly the same time at 60 minutes.
Yeah, I can believe that. NFS over GbE with async is pretty quick. Build performance on the Toshiba AC100 is quite good when I LD_PRELOAD libeatmydata.so (eats all the fsyncs - I know, I know, at my peril), even onto a slow SD card or USB stick. I figured that 2x Cortex A9 @ 1GHz would build it quicker than 1x Feroceon @ 1.2GHz.
Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around.
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this.
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :)
In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience.
Gordan
Quoting Gordan Bobic gordan@bobich.net:
omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@bobich.net:
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
It probably should be reported to the mainline but Im not sure it can be fixed either.. :)
But isn't F12 deprecated now? We're so far behind with the ARM port that by the time it's there, it's already deprecated by a Fedora version 2 versions newer.
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
There may be a branch at f15 at or around the cortex processors.
You can probably do a rpm -ivh openssl-devel krb5-devel
IIRC, the reason why I couldn't do that was because krb5 was missing from the F12 ARM repository I had to build it, but IIRC, openssl-devel wasn't there, either.
It came from somewhere. I am pretty sure I installed it for the openafs client qemu buildbot system. I don't think I built it.
Looking at the timestamps, I had to rebuild openssl from src.rpm to get the openssl-devel, then krb5. Needed krb5 for some KDE deppendencies, in order to build konversation.
I kind of wonder why openssl needs krb5. OpenSSH i can see needing krb5 and openssl. And I can see krb5 needing openssl for gssapi...
I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine.
I was trying to figure this one out too.
Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up?
Ubuntu is further because it is really Debian unstable. (although I think debian is better..)
Im not sure exactly how important it is given usually you are using the shared libs anyway.
It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages.
Ideally there shouldn't be. :)
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
no idea. I was trying to figure that out as well. It seems like they need to be reported in both places since they need to be fixed eventually by the official package maintainer
Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate?
Have you got a URL handy for the Fedora ARM bugzilla?
I'm not sure there is one, or whether it is part of the bugzilla. The only things I have really found are local to the arm project. I would rather send an email then fill out a form. lol
I can seem to use my fedora account to login to the arm koji. Im getting https://arm.koji.fedoraproject.org/koji/login is handing me back a (Error code: ssl_error_handshake_failure_alert)
Oh and python twisted is broken at the core level which is needed for buildbot.
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
fwiw, when i did kernel build time testing with the guruplug. I tried nfs, and a usb/esata drive plugged into either port. nfs with the nosync option was the fastest (50 minutes) and both esata and usb2 were roughly the same time at 60 minutes.
Yeah, I can believe that. NFS over GbE with async is pretty quick. Build performance on the Toshiba AC100 is quite good when I LD_PRELOAD libeatmydata.so (eats all the fsyncs - I know, I know, at my peril), even onto a slow SD card or USB stick. I figured that 2x Cortex A9 @ 1GHz would build it quicker than 1x Feroceon @ 1.2GHz.
My guess is the 2x cortex will sometimes be quicker then the Feroceon. :) I would actually like to performance test them. :)
Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around.
I wish I had bunch of panda boards lying around, I would probably put then in a chassis with a switch but I would need fundage lol. I wish the panda board had usb3 or esata and dual nic gigE's. I would have bought one of those for sure.
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this.
That seems to big.. almost like there is a memory issue ie hitting a 4gig limit and starting over or something weird or it is rebuilding it too many times.
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :)
I think it will be more complete. You can supposedly get an account on the arm koji, but as mentioned my login did fail. I am assuming the certificate is wrong for the hostname or it isn't configured correctly somehow. You can view it by looking at http://arm.koji.fedoraproject.org/
In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience.
I'm hoping it can be a good possibility too. I'm cheap. I like the energy savings. :)
On 12/29/2010 06:47 PM, omalleys@msu.edu wrote:
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
It probably should be reported to the mainline but Im not sure it can be fixed either.. :)
But isn't F12 deprecated now? We're so far behind with the ARM port that by the time it's there, it's already deprecated by a Fedora version 2 versions newer.
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that" - which we can't do because we're too far behind in the ARM land.
There may be a branch at f15 at or around the cortex processors.
Yes, so I hear - the hardfp branch. Having said that, according to some benchmarks, even softfp armv7l target yields decent performance improvements over armv5tel in some applications, e.g. audio/video codecs and databases:
http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25...
Looking at the timestamps, I had to rebuild openssl from src.rpm to get the openssl-devel, then krb5. Needed krb5 for some KDE deppendencies, in order to build konversation.
I kind of wonder why openssl needs krb5. OpenSSH i can see needing krb5 and openssl. And I can see krb5 needing openssl for gssapi...
Beats me.
I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine.
I was trying to figure this one out too.
I'll get building and see what comes out. Will set up a repository with packages that aren't in the main Fedora repository when I have a reasonable amount. It'll take a while, though - my main build box is a Sheeva Plug! :-O
It would also be really nice if we were to establish a selection of proper rpm kernel packages for at least the most common platforms, e.g.:
- Marvell Kirkwood for the Sheeva Plug - Freescale i.MX515 for the Genesi Efika - nVidia Tegra 2 for the Toshiba AC100
and no doubt others, too. I mention the above specifically because I own these devices and thus intend to have a go at building the suitable packages for them. It is after all, a community effort, right? ;)
Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up?
Ubuntu is further because it is really Debian unstable. (although I think debian is better..)
Sure - but Fedora is "RHEL unstable". I really don't think we have an excuse for being this far behind them.
Im not sure exactly how important it is given usually you are using the shared libs anyway.
It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages.
Ideally there shouldn't be. :)
Since F13 is just around the corner, I'll revisit the issue as soon as the rootfs for that is ready.
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
no idea. I was trying to figure that out as well. It seems like they need to be reported in both places since they need to be fixed eventually by the official package maintainer
Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate?
Have you got a URL handy for the Fedora ARM bugzilla?
I'm not sure there is one, or whether it is part of the bugzilla. The only things I have really found are local to the arm project. I would rather send an email then fill out a form. lol
I can seem to use my fedora account to login to the arm koji. Im getting https://arm.koji.fedoraproject.org/koji/login is handing me back a (Error code: ssl_error_handshake_failure_alert)
I was referring to http://bugzilla.redhat.com. Interestingly, there are options for target platforms based on ARM. But there are several that should arguably be collapsed together because there is only one supported target. The list contains:
arm7 arm9 strongarm xscale
Those should really all be collapsed down to armv5tel for now, since that is the only target available. Where do we file bugzilla reports against bugzilla? ;)
Oh and python twisted is broken at the core level which is needed for buildbot.
You mean the ARM build of it is broken?
I must admit, I was not really intending to use it. My basic approach was going to be to set up a vserver chroot, install all available packages into it, download all available src.rpms and:
iterate build all src.rpms for packages that haven't been installed yet install/update all the packages that have successfully built end
More packages should build with each iteration until only those that don't build cleanly on this platform remain. Those then need investigating further, but that's a number of CPU-weeks of building on my Sheeva Plug...
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
fwiw, when i did kernel build time testing with the guruplug. I tried nfs, and a usb/esata drive plugged into either port. nfs with the nosync option was the fastest (50 minutes) and both esata and usb2 were roughly the same time at 60 minutes.
Yeah, I can believe that. NFS over GbE with async is pretty quick. Build performance on the Toshiba AC100 is quite good when I LD_PRELOAD libeatmydata.so (eats all the fsyncs - I know, I know, at my peril), even onto a slow SD card or USB stick. I figured that 2x Cortex A9 @ 1GHz would build it quicker than 1x Feroceon @ 1.2GHz.
My guess is the 2x cortex will sometimes be quicker then the Feroceon. :) I would actually like to performance test them. :)
I'd expect the Cortex A8 to outpace the Feroceon. A9 (being 2-4 A8s) should easily blow it away.
Performance-wise, I fully intend to do some testing, but getting more packages built is a higher priority at the moment.
Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around.
I wish I had bunch of panda boards lying around, I would probably put then in a chassis with a switch but I would need fundage lol. I wish the panda board had usb3 or esata and dual nic gigE's. I would have bought one of those for sure.
The advantage of Panda is that it is quite cheap and decently specced. If you want something fancier, these look really noce, and they come in uATX for factor, but they are expensive and only if you want 100+/year:
http://www.compulab.co.il/a510/html/a510-sb-datasheet.htm
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this.
That seems to big.. almost like there is a memory issue ie hitting a 4gig limit and starting over or something weird or it is rebuilding it too many times.
See the other thread. Dan said it can take up to 30GB of disk space. Since I've no way of attaching that to my AC100, it's going to have to be NFS-backed on the Sheeva. This may take some days...
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :)
I think it will be more complete. You can supposedly get an account on the arm koji, but as mentioned my login did fail. I am assuming the certificate is wrong for the hostname or it isn't configured correctly somehow. You can view it by looking at http://arm.koji.fedoraproject.org/
I just tried it, and it does seem quite thoroughly broken. :(
In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience.
I'm hoping it can be a good possibility too. I'm cheap. I like the energy savings. :)
I meant the possibility of comfortably running Fedora instead of Ubuntu. :)
Gordan
On 12/29/2010 03:50 PM, Gordan Bobic wrote:
On 12/29/2010 06:47 PM, omalleys@msu.edu wrote:
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that"
- which we can't do because we're too far behind in the ARM land.
Fedora 12 is what's currently available, from a previous ARM port effort. It's not supported anymore. The ARM SIG is targeting F13 (now bootable: http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-sys...) and onward.
There may be a branch at f15 at or around the cortex processors.
Yes, so I hear - the hardfp branch. Having said that, according to some benchmarks, even softfp armv7l target yields decent performance improvements over armv5tel in some applications, e.g. audio/video codecs and databases:
http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25...
I kind of wonder why openssl needs krb5. OpenSSH i can see needing krb5 and openssl. And I can see krb5 needing openssl for gssapi...
Beats me.
I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine.
I was trying to figure this one out too.
I'll get building and see what comes out. Will set up a repository with packages that aren't in the main Fedora repository when I have a reasonable amount. It'll take a while, though - my main build box is a Sheeva Plug! :-O
It would also be really nice if we were to establish a selection of proper rpm kernel packages for at least the most common platforms, e.g.:
- Marvell Kirkwood for the Sheeva Plug
- Freescale i.MX515 for the Genesi Efika
- nVidia Tegra 2 for the Toshiba AC100
and no doubt others, too. I mention the above specifically because I own these devices and thus intend to have a go at building the suitable packages for them. It is after all, a community effort, right? ;)
I think the plan is to eventually get ARM kernels based on the Fedora kernel sources built for many different development boards. Currently, all effort is focused on getting the F13 package collection built. Your efforts would certainly be welcome should you try to tackle kernel builds.
I'll also note that the latest F13 koji builds are already available in a repo: http://arm.koji.fedoraproject.org/repos/dist-f13-build/latest/ That's the repo that was used to generate the F13 rootfs. As packages are built, this repo should approach the coverage of the primary architectures' repositories.
Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up?
Ubuntu is further because it is really Debian unstable. (although I think debian is better..)
Sure - but Fedora is "RHEL unstable". I really don't think we have an excuse for being this far behind them.
Ubuntu and Debian have been working on this for a much longer time. The current Fedora effort is only several months old, and builds off of the incomplete F12 package collection. Further, we only got F13's gcc and glibc working on ARM two months ago, which held up pretty much all progress. Most of the big problems have been knocked out, and things are indeed progressing. I don't really understand the pessimism, my perception is that things are going quite well (it's taken under two months to get a working F13 rootfs!) I don't think that ARM fedora is being neglected at all, it's just a young effort and the results aren't immediately apparent yet.
It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages.
Ideally there shouldn't be. :)
Since F13 is just around the corner, I'll revisit the issue as soon as the rootfs for that is ready.
Alpha-quality rootfs is available for you to play with: see above. krb5 can be built without OpenSSL for bootstraping, the option is at the top of the krb5 specfile. Several packages need to be bootstrapped in a similar fashion: Mono requires mono-devel for instance.
Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate? Have you got a URL handy for the Fedora ARM bugzilla?
I'm not sure there is one, or whether it is part of the bugzilla. The only things I have really found are local to the arm project. I would rather send an email then fill out a form. lol
I can seem to use my fedora account to login to the arm koji. Im getting https://arm.koji.fedoraproject.org/koji/login is handing me back a (Error code: ssl_error_handshake_failure_alert)
I was referring to http://bugzilla.redhat.com. Interestingly, there are options for target platforms based on ARM. But there are several that should arguably be collapsed together because there is only one supported target. The list contains:
arm7 arm9 strongarm xscale
Those should really all be collapsed down to armv5tel for now, since that is the only target available. Where do we file bugzilla reports against bugzilla? ;)
I guess nobody has addressed this yet; most of the build errors thus far have been fixed over IRC or through the list. There is, however, a "bugzilla" product in the redhat bugzilla where you can file bugs against the redhat bugzilla.http://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers
Oh and python twisted is broken at the core level which is needed for buildbot.
You mean the ARM build of it is broken?
I must admit, I was not really intending to use it. My basic approach was going to be to set up a vserver chroot, install all available packages into it, download all available src.rpms and:
iterate build all src.rpms for packages that haven't been installed yet install/update all the packages that have successfully built end
More packages should build with each iteration until only those that don't build cleanly on this platform remain. Those then need investigating further, but that's a number of CPU-weeks of building on my Sheeva Plug...
Luckily, this is already happening on the ARM koji for F13 and beyond. There's a status page at http://arm.koji.fedoraproject.org/status/ It might be easier to look for build failures there to fix than to duplicate the effort (it's certainly faster). You could either set up a mock config to build locally, or just install the f13 rootfs.
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
fwiw, when i did kernel build time testing with the guruplug. I tried nfs, and a usb/esata drive plugged into either port. nfs with the nosync option was the fastest (50 minutes) and both esata and usb2 were roughly the same time at 60 minutes.
Yeah, I can believe that. NFS over GbE with async is pretty quick. Build performance on the Toshiba AC100 is quite good when I LD_PRELOAD libeatmydata.so (eats all the fsyncs - I know, I know, at my peril), even onto a slow SD card or USB stick. I figured that 2x Cortex A9 @ 1GHz would build it quicker than 1x Feroceon @ 1.2GHz.
My guess is the 2x cortex will sometimes be quicker then the Feroceon. :) I would actually like to performance test them. :)
I'd expect the Cortex A8 to outpace the Feroceon. A9 (being 2-4 A8s) should easily blow it away.
Performance-wise, I fully intend to do some testing, but getting more packages built is a higher priority at the moment.
Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around.
I wish I had bunch of panda boards lying around, I would probably put then in a chassis with a switch but I would need fundage lol. I wish the panda board had usb3 or esata and dual nic gigE's. I would have bought one of those for sure.
The advantage of Panda is that it is quite cheap and decently specced. If you want something fancier, these look really noce, and they come in uATX for factor, but they are expensive and only if you want 100+/year:
There are plans to add some pandaboards to the koji buildfarm as well: http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Secondary_Architecture/...
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this.
That seems to big.. almost like there is a memory issue ie hitting a 4gig limit and starting over or something weird or it is rebuilding it too many times.
See the other thread. Dan said it can take up to 30GB of disk space. Since I've no way of attaching that to my AC100, it's going to have to be NFS-backed on the Sheeva. This may take some days...
Maybe set mock up to work off of a USB hard drive on the Sheeva (if you have one laying around?)
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :)
I think it will be more complete. You can supposedly get an account on the arm koji, but as mentioned my login did fail. I am assuming the certificate is wrong for the hostname or it isn't configured correctly somehow. You can view it by looking at http://arm.koji.fedoraproject.org/
I just tried it, and it does seem quite thoroughly broken. :(
The web interface seems broken at the moment, but it's still possible to submit builds via the command line using directions at http://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers. I just submitted a scratch build without issue.
In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience.
I'm hoping it can be a good possibility too. I'm cheap. I like the energy savings. :)
I meant the possibility of comfortably running Fedora instead of Ubuntu. :)
Give it time, F13 and beyond are striving to reach package parity with the primary architectures (as much as is possible anyway.) The effort is young, but making lots of progress.
Rich
On 12/29/2010 10:39 PM, Rich Mattes wrote:
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that"
- which we can't do because we're too far behind in the ARM land.
Fedora 12 is what's currently available, from a previous ARM port effort. It's not supported anymore. The ARM SIG is targeting F13 (now bootable: http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-sys...) and onward.
OK, downloading now. I'm guessing that it'd be more fruitful at the moment to be working on things for F13 than on F12.
I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine.
I was trying to figure this one out too.
I'll get building and see what comes out. Will set up a repository with packages that aren't in the main Fedora repository when I have a reasonable amount. It'll take a while, though - my main build box is a Sheeva Plug! :-O
It would also be really nice if we were to establish a selection of proper rpm kernel packages for at least the most common platforms, e.g.:
- Marvell Kirkwood for the Sheeva Plug
- Freescale i.MX515 for the Genesi Efika
- nVidia Tegra 2 for the Toshiba AC100
and no doubt others, too. I mention the above specifically because I own these devices and thus intend to have a go at building the suitable packages for them. It is after all, a community effort, right? ;)
I think the plan is to eventually get ARM kernels based on the Fedora kernel sources built for many different development boards. Currently, all effort is focused on getting the F13 package collection built. Your efforts would certainly be welcome should you try to tackle kernel builds.
Indeed, I need to do this anyway. I will share results I think will be useful. What I am ideally hoping to do is come up with just two kernel packages, an armv5tel and an armv7l one, that will cover most things. Whether that will turn out to be possible remains to be seen.
I'll also note that the latest F13 koji builds are already available in a repo: http://arm.koji.fedoraproject.org/repos/dist-f13-build/latest/ That's the repo that was used to generate the F13 rootfs. As packages are built, this repo should approach the coverage of the primary architectures' repositories.
Wasn't that the theory with the F12 build, too?
Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up?
Ubuntu is further because it is really Debian unstable. (although I think debian is better..)
Sure - but Fedora is "RHEL unstable". I really don't think we have an excuse for being this far behind them.
Ubuntu and Debian have been working on this for a much longer time. The current Fedora effort is only several months old, and builds off of the incomplete F12 package collection. Further, we only got F13's gcc and glibc working on ARM two months ago, which held up pretty much all progress. Most of the big problems have been knocked out, and things are indeed progressing. I don't really understand the pessimism, my perception is that things are going quite well (it's taken under two months to get a working F13 rootfs!) I don't think that ARM fedora is being neglected at all, it's just a young effort and the results aren't immediately apparent yet.
I wouldn't call it pessimism at all. I'm surprised more than anything. But I am certainly willing to stick my ore in and help shift things along in whatever way I can.
It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages.
Ideally there shouldn't be. :)
Since F13 is just around the corner, I'll revisit the issue as soon as the rootfs for that is ready.
Alpha-quality rootfs is available for you to play with: see above. krb5 can be built without OpenSSL for bootstraping, the option is at the top of the krb5 specfile. Several packages need to be bootstrapped in a similar fashion: Mono requires mono-devel for instance.
Hmm... Is there anything that can be done about this? It seems conceptually broken.
Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate? Have you got a URL handy for the Fedora ARM bugzilla?
I'm not sure there is one, or whether it is part of the bugzilla. The only things I have really found are local to the arm project. I would rather send an email then fill out a form. lol
I can seem to use my fedora account to login to the arm koji. Im gettinghttps://arm.koji.fedoraproject.org/koji/login is handing me back a (Error code: ssl_error_handshake_failure_alert)
I was referring tohttp://bugzilla.redhat.com. Interestingly, there are options for target platforms based on ARM. But there are several that should arguably be collapsed together because there is only one supported target. The list contains:
arm7 arm9 strongarm xscale
Those should really all be collapsed down to armv5tel for now, since that is the only target available. Where do we file bugzilla reports against bugzilla? ;)
I guess nobody has addressed this yet; most of the build errors thus far have been fixed over IRC or through the list. There is, however, a "bugzilla" product in the redhat bugzilla where you can file bugs against the redhat bugzilla.
Filed. Thanks for pointing this out. :)
http://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers
Oh and python twisted is broken at the core level which is needed for buildbot.
You mean the ARM build of it is broken?
I must admit, I was not really intending to use it. My basic approach was going to be to set up a vserver chroot, install all available packages into it, download all available src.rpms and:
iterate build all src.rpms for packages that haven't been installed yet install/update all the packages that have successfully built end
More packages should build with each iteration until only those that don't build cleanly on this platform remain. Those then need investigating further, but that's a number of CPU-weeks of building on my Sheeva Plug...
Luckily, this is already happening on the ARM koji for F13 and beyond. There's a status page at http://arm.koji.fedoraproject.org/status/ It might be easier to look for build failures there to fix than to duplicate the effort (it's certainly faster). You could either set up a mock config to build locally, or just install the f13 rootfs.
Yup, it's extracting onto a USB stick as I type. :)
Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around.
I wish I had bunch of panda boards lying around, I would probably put then in a chassis with a switch but I would need fundage lol. I wish the panda board had usb3 or esata and dual nic gigE's. I would have bought one of those for sure.
The advantage of Panda is that it is quite cheap and decently specced. If you want something fancier, these look really noce, and they come in uATX for factor, but they are expensive and only if you want 100+/year:
There are plans to add some pandaboards to the koji buildfarm as well: http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Secondary_Architecture/...
Cool. I can't help but wish, though, that such thing came with Power-over-Ethernet option. It would make things so much cheaper and simpler, and all of these devices come in under the 15.4W TDP limit of Class 3 PoE.
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Im surprised at this.. it doesn't -seem- like it should be quite that big.
By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this.
That seems to big.. almost like there is a memory issue ie hitting a 4gig limit and starting over or something weird or it is rebuilding it too many times.
See the other thread. Dan said it can take up to 30GB of disk space. Since I've no way of attaching that to my AC100, it's going to have to be NFS-backed on the Sheeva. This may take some days...
Maybe set mock up to work off of a USB hard drive on the Sheeva (if you have one laying around?)
Actually, I think GbE to my storage box will almost certainly be quicker. The NFS shared are async, and the server as 8GB of RAM for caching and 8 disks in RAID10. It should blow away anything that a local USB eSATA disk can manage. :)
Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these.
I was hoping the f13 would be released for xmas. :) but it appears like f12 is going to be around a bit longer..
I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :)
I think it will be more complete. You can supposedly get an account on the arm koji, but as mentioned my login did fail. I am assuming the certificate is wrong for the hostname or it isn't configured correctly somehow. You can view it by looking athttp://arm.koji.fedoraproject.org/
I just tried it, and it does seem quite thoroughly broken. :(
The web interface seems broken at the moment, but it's still possible to submit builds via the command line using directions at http://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers. I just submitted a scratch build without issue.
Thanks for that, I'll look into it.
In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience.
I'm hoping it can be a good possibility too. I'm cheap. I like the energy savings. :)
I meant the possibility of comfortably running Fedora instead of Ubuntu. :)
Give it time, F13 and beyond are striving to reach package parity with the primary architectures (as much as is possible anyway.) The effort is young, but making lots of progress.
Once I get F13 working I'm tempted to start building RHEL6 SRPMS, since that is largely based on F12/F13. Due to the much lower version churn, it should be a lot easier to support in the longer term. Hmm... Maybe I should see if the CentOS project is interested in having an ARM port, it seems like a logical place where this would fit.
Gordan
On 12/29/2010 10:39 PM, Rich Mattes wrote:
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that"
- which we can't do because we're too far behind in the ARM land.
Fedora 12 is what's currently available, from a previous ARM port effort. It's not supported anymore. The ARM SIG is targeting F13 (now bootable: http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-sys...) and onward.
It seems the metadata is broken on some of the packages in the F13 koji repository. The URLs list a host as "hongkong" which is clearly not going to resolve. Any chance of a fix? The packages in question are pretty important for a usable build system.
Gordan
Quoting Gordan Bobic gordan@bobich.net:
On 12/29/2010 10:39 PM, Rich Mattes wrote:
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that"
- which we can't do because we're too far behind in the ARM land.
Fedora 12 is what's currently available, from a previous ARM port effort. It's not supported anymore. The ARM SIG is targeting F13 (now bootable: http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-sys...) and onward.
It seems the metadata is broken on some of the packages in the F13 koji repository. The URLs list a host as "hongkong" which is clearly not going to resolve. Any chance of a fix? The packages in question are pretty important for a usable build system.
I put it on Paul Whalen blog like a week ago. I just overrode it. in /etc/hosts put 142.204.133.150 arm.koji.fedoraproject.org hongkong
It works. I just reran it.
On 12/30/2010 04:43 AM, omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@bobich.net:
On 12/29/2010 10:39 PM, Rich Mattes wrote:
The plan is to finish 13, do 14, then 15. As I believe some or most of the bugs if they are getting pushed upstream should be worked out.?
The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available.
This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that"
- which we can't do because we're too far behind in the ARM land.
Fedora 12 is what's currently available, from a previous ARM port effort. It's not supported anymore. The ARM SIG is targeting F13 (now bootable: http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-sys...)
and onward.
It seems the metadata is broken on some of the packages in the F13 koji repository. The URLs list a host as "hongkong" which is clearly not going to resolve. Any chance of a fix? The packages in question are pretty important for a usable build system.
I put it on Paul Whalen blog like a week ago. I just overrode it. in /etc/hosts put 142.204.133.150 arm.koji.fedoraproject.org hongkong
Hmm... Not so good if you're behind a transparent proxy... :(
Gordan
Gordan Bobic píše v St 29. 12. 2010 v 15:54 +0000:
omalleys@msu.edu wrote:
It doesn't look like there is.
I'm not saying you are wrong or it wont work to use the RHEL6b2 version, but if I was going to build them from scratch, I would probably use the f12 src. OO has a lot of dependencies.
I already resolved the dependencies. F12 was 3.1.0, and RHEL6b2 was 3.2.1, so I went with the latter.
Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build
I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that.
Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla?
To get around the OOM issue, just add a swap file. Here is a quick how-to if you aren't familiar.
I'm prefectly aware of how to add a swap file, thanks. I've only been doing this for 20 years or so. :p
It is probably going to take quite a bit of time to compile. Given there isn't a compiled version for arm, it will probably take more work then just a recompile.
Well:
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Going through the 3rd attempt now. Let's hope the 16GB USB stick proves to be big enough to hold the build directory...
IIRC a build of OO.org needs more than 30GB of free disk space, few gigs can be saved when the langpacks are not built
Dan
1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes).
2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died.
Going through the 3rd attempt now. Let's hope the 16GB USB stick proves to be big enough to hold the build directory...
IIRC a build of OO.org needs more than 30GB of free disk space, few gigs can be saved when the langpacks are not built
*blinks*
OOohkay... NFS on the SheevaPlug it is!
Gordan
-
Dan Horák -
Gordan Bobic -
omalleys＠msu.edu -
Rich Mattes