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' , so I can not fix the issues completely and
>>>> 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
>>>> - Bug 682538 - geos-3.2.1-1.fc13.src.rpm does not build on Fedora-13 for
>>>> These bugs are blockers for the ARMTracker which make them easily
>>> 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?
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:
> 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.