[fedora-arm] OpenOffice RPMs

[Gordan Bobic]

On 12/29/2010 06:47 PM, omalleys at 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-25135-22766

>> 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