On 03/08/2011 12:20 PM, Niels de Vos wrote: > On Tue, Mar 8, 2011 at 10:01 AM, Gordan Bobic<gordan@xxxxxxxxxx> 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm