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_resolv...
However there are quite some more packages failing the build process: - https://arm.koji.fedoraproject.org/koji/builds
I'd like some advise on the best/efficient way forward. Any other thoughts are also more than welcome!
Possibly I could request to become a proven packager [2], but I do not know if fixing building ARM-packages is enough to get FESCo approve my request.
Many thanks, Niels
[1] https://fedoraproject.org/wiki/Provenpackager_policy [2] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
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:
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:
We're tracking build failures as bugs now? Really??
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.
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.
Gordan
On Tue, Mar 8, 2011 at 10:01 AM, Gordan Bobic gordan@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:
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:
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_resolv...
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?
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).
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.
Cheers, Niels
On Tue, Mar 08, 2011 at 12:20:10PM +0000, Niels de Vos wrote:
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?
Actually package maintainers are not expected to fix bugs for build-issues on secondary archs, except for accepting patches that fix them.
Regards Till
On 03/08/2011 09:07 PM, Till Maas wrote:
On Tue, Mar 08, 2011 at 12:20:10PM +0000, Niels de Vos wrote:
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?
Actually package maintainers are not expected to fix bugs for build-issues on secondary archs, except for accepting patches that fix them.
How do we get ARM to be one of the primaries? :-)
One particular good thing that comes out of ARM porting is that on <= ARMv6 alignment errors aren't auto-corrected, which means that it gives a wake-up call to all the people that are making unsound assumptions.
My recent shock was when chasing an alignment error in e2fsprogs. There are unaligned char arrays all over the place being used as buffers and having structs cast into them. How any of the extfs tools ever worked on ARM in the first pace is nothing short of a miracle. I'm told that SPARC has the same alignment restriction issue, but the GCC backend for SPARC automatically aligns all arrays to a suitable word boundary. The ARM backend doesn't do this, nor is there a compile time switch to make it do that. The only reason I can think of for it being automatic on SPARC but not on ARM is because ARM was until recently a very embedded arch, and thus memory space was deemed more important than holding the programmer by the hand.
Gordan
On 03/08/2011 12:20 PM, Niels de Vos wrote:
On Tue, Mar 8, 2011 at 10:01 AM, Gordan Bobicgordan@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:
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:
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_resolv...
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
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:
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:
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. 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
Regards Till
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:
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:
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?
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.
Gordan
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:
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:
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. There are packages that have e.g. circular dependencies and therefore do not build currently and need some manual intervention. 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.
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.
Regards Till
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:
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:
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
On Sun, Mar 06, 2011 at 02:45:15PM +0000, Niels de Vos wrote:
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:
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
I'd like some advise on the best/efficient way forward. Any other thoughts are also more than welcome!
Submitting patches to Bugzilla is the recommended way for this.
Possibly I could request to become a proven packager [2], but I do not know if fixing building ARM-packages is enough to get FESCo approve my request.
Even if you are a proven packager you should still ask the maintainer for approval of patches to avoid unwanted side-effects, but you can do the work to update the package. I do not know how much you already have contributed to Fedora to prove that you are a experienced packager. If you think it is not enough, you submit more patches using bugzilla for now and ask for provenpackager membership once you got more feedback from packagers or more patches accepted. In general helping to fix secondary arch build issues is a proper reason to become a proven packager.
Btw. if there are packagers that agree to a patch you submitted but lack the time to update the package, you can ping me and I will help. Maybe this helps to speed up the patch approval. You might want to mention this possibility on the bug reports to get the packagers faster to agree. There are probably also other proven packagers here on the ARM list that will help with this.
Regards Till
On Tue, Mar 8, 2011 at 9:15 PM, Till Maas opensource@till.name wrote:
On Sun, Mar 06, 2011 at 02:45:15PM +0000, Niels de Vos wrote:
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:
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
I'd like some advise on the best/efficient way forward. Any other thoughts are also more than welcome!
Submitting patches to Bugzilla is the recommended way for this.
Possibly I could request to become a proven packager [2], but I do not know if fixing building ARM-packages is enough to get FESCo approve my request.
Even if you are a proven packager you should still ask the maintainer for approval of patches to avoid unwanted side-effects, but you can do the work to update the package. I do not know how much you already have contributed to Fedora to prove that you are a experienced packager. If you think it is not enough, you submit more patches using bugzilla for now and ask for provenpackager membership once you got more feedback from packagers or more patches accepted. In general helping to fix secondary arch build issues is a proper reason to become a proven packager.
That's more or less the plan I have at the moment. I'll file some more BZ's and see if the patches get picked up.
Btw. if there are packagers that agree to a patch you submitted but lack the time to update the package, you can ping me and I will help. Maybe this helps to speed up the patch approval. You might want to mention this possibility on the bug reports to get the packagers faster to agree. There are probably also other proven packagers here on the ARM list that will help with this.
That's very good to know. I'll likely come back on your offer, or maybe I'll send an email at secondary@lists.fedoraproject.org to see how other architectures handle it.
Many thanks for all the input, Niels
-
Gordan Bobic -
Niels de Vos -
Till Maas