[fedora-arm] What is the best way to fix build issues with Fedora 13 RPMs?

[Gordan Bobic]

On 03/08/2011 12:20 PM, Niels de Vos wrote:
> On Tue, Mar 8, 2011 at 10:01 AM, Gordan Bobic<gordan at bobich.net>  wrote:
>> Niels de Vos wrote:
>>> Hello all,
>>>
>>> it looks like not all Fedora 13 packages can be build on ARM yet. For
>>> some packages there have been tickets opened at the Trac instance:
>>> - https://fedorahosted.org/arm/report/1
>>>
>>> I'd like to help out with building these packages, but am not a
>>> 'proven packager' [1], so I can not fix the issues completely and rely
>>> on the package maintainer or other proven packagers. What I am doing
>>> right now is filing bugs against the packages that can not be build on
>>> ARM. I'm including pointers to the issue and propose fixes, like:
>>> - Bug 682515 - libgda-4.1.4-1.fc13.src.rpm does not rebuild on Fedora 13 for ARM
>>> - Bug 682538 - geos-3.2.1-1.fc13.src.rpm does not build on Fedora-13 for ARM
>>>
>>> These bugs are blockers for the ARMTracker which make them easily findable:
>>> - https://bugzilla.redhat.com/showdependencytree.cgi?id=245418&hide_resolved=1
>>
>> We're tracking build failures as bugs now? Really??
>
> Well, yeah. There is FTBFS:
> - http://fedoraproject.org/wiki/FTBFS
> - https://bugzilla.redhat.com/show_bug.cgi?id=FTBFS
> - https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1
>
> I don's know what the best way would be to mark FTBFS bugs as ARM
> specific. But we sure rely on the packagers for fixing the
> build-issues for their package.
>
> Maybe there should be a FTBFS-ARM tracker-bug?

I think this would be useful. It would also be nice to see a broader 
effort in pushing arch specific patches back into mainline. It's really 
disappointing to see a package have ARM specific patches over several 
major releases. It really should be paid attention to after it's been 
fixed once. Having a tracker bug would increase the visibility of the 
issue and that can only be a good thing, IMO.

>> If build failures are now tracked as bugs, OpenOffice/LibreOffice would
>> probably be an important one to address sooner rather than later. I have
>> 3.3.0.4 from rawhide _almost_ building when configured without the Java
>> bits, but it fails in the packaging stage, erroneously trying to extract
>> non-existant beanshell components. Without OO/LO, we haven't got a
>> usable office package on ARM, which is a bit of an issue. And since
>> Ubuntu have it working, we really ought to be keeping up.
>
> I'd suggest creating a BZ for that. Maybe the packagers are interested
> in helping out (well, they should imho).

I would expect so. The problem that finally got me in LO isn't to do 
with the build process but with the install/packaging stage.

>> The main thing that's stopping me from making progress on this at a
>> sensible rate is that OO/LO takes 3 or so days to build on my Sheevaplug.
>
> Yeah, thats an issue. I dont know if the arm.koji builders are any
> quicker? You might want to check out
> fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers .
> However, if you build from the srpm you'll need to upload it, which is
> likely an other bottleneck for OO/LO.

Well, I'm going to try networking up my Toshiba AC100 (2x 1GHz Tegra2) 
to the Sheevaplug (1x 1.2GHz Kirkwood), and see if I can get some 
benefit from distcc, but in LO at least half of the build effort is 
actually compiling various language packs using perl scripts and 
suchlike, which won't benefit. :(

Gordan