Till Maas wrote: > On Tue, Mar 08, 2011 at 10:07:46PM +0000, Gordan Bobic wrote: >> On 03/08/2011 09:04 PM, Till Maas wrote: >>> On Tue, Mar 08, 2011 at 10:01:02AM +0000, Gordan Bobic 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?? >>> Tracking build failures is probably overkill as long as not all packages >>> are expected to build on ARM. >> Aren't all the packages expected to build on ARM? Which ones aren't >> expected to build? > > I do not have a list but as far as I understand the whole ARM > infrastructure is not yet completed and not all packages have been tried > to be build. I suspect it's more a case that some packages fail to build, rather than the build not having been tried. > There are packages that have e.g. circular dependencies and > therefore do not build currently and need some manual intervention. Circular dependencies are not likely to be arch specific, though, are they? > Also > for packages that have missing dependencies in ARM it is expected that > they do not build currently, but they might once the dependencies are in > the ARM repo. There is not much a packager can do about, therefore a bug > report does not help to track anything. Absolutely, I am not talking about packages not building due to missing dependencies. But those dependencies typically aren't there because they fail to build for other, possibly arch specific reasons, which I would tend to think should be accompanied by a bugzilla report. >>> Tracking patches in Bugzilla that fix >>> build failures is a good idea, though. This allows maintainers to >>> inspect patches and apply them. >>> >>> I guess once Fedora-ARM is completely working, all non-working packages >>> should be tracked as mentioned in the wiki: >>> http://fedoraproject.org/wiki/Architectures#Tracker_Bugs >> That seems contradictory. Once it is completely working, that implies >> all packages are working, in which case there's nothing to fix/track. > > I meant the time when Fedora-ARM provides a stable release or is ready > to provide one including the infrastructure to provide updates and all > packages that build are in sync with the primary archs or in other > words: the only missing thing is to get all packages from the primary > archs to build on Fedora-ARM. I don't see that happening any time soon. Just cleaning up all the alignment errors is going to take a lot of code rewriting. I've been filing these as bugs, but I keep finding new ones. I am really starting to lean toward suggesting the default /proc/cpu/alignment policy at least on pre-release (alpha/beta/rc) Fedoras for ARM should be signal+warn. At least that way we'd get core dumps to try to pin down where the alignment issues are occurring. Then again, considering just how prevalent bad coding practices are in a lot of the packages, I suspect this issue isn't going to go away any time soon. Even if we catch most of the frequently occurring ones, the more obscure cases are likely to be cropping up for years. Perhaps there should be a push for introducing a GCC switch/policy for the ARM backend that makes all arrays and structures aligned to a word boundary by default? I heard a rumour that GCC's SPARC back end already does this, but I haven't verified it. If it's true, then at least there is a precedent for such a thing. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
