Fedora-11 ARM Repositories are now available!
Details: built for ARMv5 EABI, soft-float, little endian.
Currently there are packages from three yum groups: Base, Core and Web-Server.
A yum-enabled pre-built root filesystem is available along with instructions for working with known platforms (currently Qemu,
Sheevaplug)
The Fedora/ARM architecture wiki page has more information:
http://fedoraproject.org/wiki/Architectures/ARM
Do let us know any issues that you may face, or any additional Fedora Packages/Groups that you would like to have in the
repositories.
Our next steps include a) making the package repository much more complete by building packages from more package groups (starting
with the Gnome Desktop group) b) tracking f11-updates for these packages.
Tuesday, June 30, 2009
Tuesday, June 16, 2009
Incorrect host parameter
While rebuilding gcc and glibc I found out that the builds were being passed the host parameter as
instead of
Strange!
I checked back at the gcc/glibc that were built earlier (27 April 2009). These seemed to get built correctly with the right host parameter. So what changed? The rpm and redhat-rpm-config rpms were the same as in April. And yet we see a different behaviour.
Normally, the host parameter that we see while manually building is armv5tel-redhat-linux. While right now we see it is armv5tel-koji-linux. So most likely koji is substituting the _host rpm macro with its own version, and while doing so it neglects the -gnueabi suffix. And probably it was included in one of the latest versions (We use koji trunk on fedora-arm)
Thankfully, there is a configuration option to override this through kojid.conf. Fixed it on all the builders.
--host=armv5tel-koji-linux-gnu
instead of
--host=armv5tel-koji-linux-gnueabi
Strange!
I checked back at the gcc/glibc that were built earlier (27 April 2009). These seemed to get built correctly with the right host parameter. So what changed? The rpm and redhat-rpm-config rpms were the same as in April. And yet we see a different behaviour.
Normally, the host parameter that we see while manually building is armv5tel-redhat-linux. While right now we see it is armv5tel-koji-linux. So most likely koji is substituting the _host rpm macro with its own version, and while doing so it neglects the -gnueabi suffix. And probably it was included in one of the latest versions (We use koji trunk on fedora-arm)
Thankfully, there is a configuration option to override this through kojid.conf. Fixed it on all the builders.
Thursday, June 11, 2009
Minimal fedora-arm rootfs
The bootstrap phase has seen a lot of packages being built for F-11. Specifically, 730+ packages have been built (and counting).
So how far have we reached as far as a working rfs is concerned? Not too far away now. Only some dependencies need to satisfied. All the major dep trees have been satisfied. The only thing remaining is cyrus-sasl which needs mysql and postgresql. Once that is done, we'll give another shot at building an rfs from the available packages. If no new install-time deps are required, we'll be good to go!
Any time now!
So how far have we reached as far as a working rfs is concerned? Not too far away now. Only some dependencies need to satisfied. All the major dep trees have been satisfied. The only thing remaining is cyrus-sasl which needs mysql and postgresql. Once that is done, we'll give another shot at building an rfs from the available packages. If no new install-time deps are required, we'll be good to go!
Any time now!
Monday, June 8, 2009
Autobuild result
We built 117 packages in the autobuild run that we ran through the weekend. Much more than what I was expecting, great! We missed out to tag the 'libtool' package in the tag, so nothing that uses libtool was built. That will happen in the next run tonight.
Saturday, June 6, 2009
Second phase of the bootstrap build ..
After some hiccups, the second pass for the F-11 builds from F11` has been finally scheduled.
Yesterday, there was an issue with unicode encoding in some package's "provides" tag.
Basically, there is a koji utility called "mergerepos" which (as the name suggests) merges multiple repos into one. This is required because we use something called "external repos" (The F-11` repo is attached as an external repo to the build tag). Since, we need to merge the repo generated out of the build tag and the external repo, mergerepos comes into the picture. Now, some of the font packages (baekmuk-ttf-batang-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-gulim-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-dotum-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-hline-fonts-2.2-21.fc11.noarch.rpm, sazanami-mincho-fonts-0.20040629-7.20061016.fc11.noarch.rpm) had unicode/random encoding in their "provides" tag. "mergerepos" didn't seem to handle it pretty well and it used to fail.
Since, luckily, not many packages seem to depend on these font packages, we have removed this packages from the F-11` set.
(We have reported the issue to the maintainer and he is having a look at it)
After this, some time was spent on coming to a closure. There were some missing deps here and there. Nothing major here. Just had to add these packages to the dist-f11-build-bs tag and we were good to go.
The second pass has started now. Hoping that a good set will be built over the weekend :)
Yesterday, there was an issue with unicode encoding in some package's "provides" tag.
Basically, there is a koji utility called "mergerepos" which (as the name suggests) merges multiple repos into one. This is required because we use something called "external repos" (The F-11` repo is attached as an external repo to the build tag). Since, we need to merge the repo generated out of the build tag and the external repo, mergerepos comes into the picture. Now, some of the font packages (baekmuk-ttf-batang-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-gulim-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-dotum-fonts-2.2-21.fc11.noarch.rpm, baekmuk-ttf-hline-fonts-2.2-21.fc11.noarch.rpm, sazanami-mincho-fonts-0.20040629-7.20061016.fc11.noarch.rpm) had unicode/random encoding in their "provides" tag. "mergerepos" didn't seem to handle it pretty well and it used to fail.
Since, luckily, not many packages seem to depend on these font packages, we have removed this packages from the F-11` set.
(We have reported the issue to the maintainer and he is having a look at it)
After this, some time was spent on coming to a closure. There were some missing deps here and there. Nothing major here. Just had to add these packages to the dist-f11-build-bs tag and we were good to go.
The second pass has started now. Hoping that a good set will be built over the weekend :)
Friday, June 5, 2009
Peek Forward to autobuild
A fairly large set of F-11` rpms (from the coreset) is now available. There are about 40 odd packages which have still to make there way into this thing yet.
But in order to make automation work over the weekend, we'll go ahead and schedule a build pass over all the 700SRPMS using the F-11` build root. There will still be failures (since those 40 packages haven't made there way into F-11` yet.) And we will reschedule them after the failing-40 are done. But there should be some good number of packages that succeed. And it validates the build scripts as well.
Lets see how this goes.
But in order to make automation work over the weekend, we'll go ahead and schedule a build pass over all the 700SRPMS using the F-11` build root. There will still be failures (since those 40 packages haven't made there way into F-11` yet.) And we will reschedule them after the failing-40 are done. But there should be some good number of packages that succeed. And it validates the build scripts as well.
Lets see how this goes.
Circular Deps
The most time-consuming component of tracking Fedora package builds is circular dependencies... More the number of packages in the set, more the time it takes. Yesterday was spent in chasing a libsoup->libproxy->webkitgtk toolkit dependency.
This is how it starts:
Build --> gvfs-1.2.3-2
Dep failure. libsoup. Ok.
Build --> libsoup-2_26_0_9-1_fc11
Dep failure. libproxy. No problem.
Build --> libproxy-0_2_3-8_fc11
Error WebKit-Gtk-devel not found. Hmm... Strange I see it right there in koji, with the proper tag, why doesn't it find it?
Turns out the package was renamed to webkitgtk in F-11. So it won't pick the older package. Alright, lets build that.
Build --> webkitgtk-1_1_4-1_fc11
Ok, webkitgtk again needs some version of libsoup that I don't have in koji yet.
Well, but libsoup needs libproxy again. Going through libsoup commit logs, tells me that libsoup shifted from GConf2 to libproxy in the past. So lets build libsoup's version that builds with GConf2.
Build --> libsoup-2_25_4-1_fc11
No, that would have been too simple won't it. The version of GConf2 that I have in koji has some 'pkgconfig' errors. So I look at GConf2 commit logs. Somewhere upthere, there is a version that fixes this issue.
Build --> GConf2-2_24_0-3_fc11
Finally! Something got built... And now to pop the rest of the stack and pray :-)
Its time I start looking into how to fix the problem with shadowing.
This is how it starts:
Build --> gvfs-1.2.3-2
Dep failure. libsoup. Ok.
Build --> libsoup-2_26_0_9-1_fc11
Dep failure. libproxy. No problem.
Build --> libproxy-0_2_3-8_fc11
Error WebKit-Gtk-devel not found. Hmm... Strange I see it right there in koji, with the proper tag, why doesn't it find it?
Turns out the package was renamed to webkitgtk in F-11. So it won't pick the older package. Alright, lets build that.
Build --> webkitgtk-1_1_4-1_fc11
Ok, webkitgtk again needs some version of libsoup that I don't have in koji yet.
Well, but libsoup needs libproxy again. Going through libsoup commit logs, tells me that libsoup shifted from GConf2 to libproxy in the past. So lets build libsoup's version that builds with GConf2.
Build --> libsoup-2_25_4-1_fc11
No, that would have been too simple won't it. The version of GConf2 that I have in koji has some 'pkgconfig' errors. So I look at GConf2 commit logs. Somewhere upthere, there is a version that fixes this issue.
Build --> GConf2-2_24_0-3_fc11
Finally! Something got built... And now to pop the rest of the stack and pray :-)
Its time I start looking into how to fix the problem with shadowing.
Wednesday, June 3, 2009
Slow slow arm koji
For the past couple of days, arm koji has been horribly slow... Opening the front page or task status page is like a 1 minute task. Or it dumps a "proxy error"
genpkgmetadata is probably killing the VM.
genpkgmetadata is probably killing the VM.
Quick rehash
A quick rehash of what all has been happening thus far:
F-11 tracking is in-progress. koji-shadow was shadowing builds for f-11 for the main fedora koji server. I was expecting it to run more independently, but that hasn't yet happened because of the "prefer-new" option. It pulls in additional dependencies, that have to be taken care of manually.
Recently, koji-shadow is also running into some Python Traceback Issues. I have requested dgilmore to look into it.
In the meanwhile, we are using koji to perform an F-11 bootstrap the way we did for F-10. The only difference being, this time it will be done using koji. If we get there with this method faster than koji-shadow, great!
F-10 --> F-11` --> F-11 (for the basic set of 2000 rpms or ~450 SRPMS)
Thanks to koji and scripting, we have already built 400 of these SRPMS for the F-11` within a span of 3 days. The others are build/dep failures.
But what that means is that, once we have F-11' complete (with patched packages etc.) going to F-11 will only be a 5/6 day effort, since build deps are already fixed.
Now to fix the deps failures first...
F-11 tracking is in-progress. koji-shadow was shadowing builds for f-11 for the main fedora koji server. I was expecting it to run more independently, but that hasn't yet happened because of the "prefer-new" option. It pulls in additional dependencies, that have to be taken care of manually.
Recently, koji-shadow is also running into some Python Traceback Issues. I have requested dgilmore to look into it.
In the meanwhile, we are using koji to perform an F-11 bootstrap the way we did for F-10. The only difference being, this time it will be done using koji. If we get there with this method faster than koji-shadow, great!
F-10 --> F-11` --> F-11 (for the basic set of 2000 rpms or ~450 SRPMS)
Thanks to koji and scripting, we have already built 400 of these SRPMS for the F-11` within a span of 3 days. The others are build/dep failures.
But what that means is that, once we have F-11' complete (with patched packages etc.) going to F-11 will only be a 5/6 day effort, since build deps are already fixed.
Now to fix the deps failures first...
The Fedora-ARM Blog
First blog entry for the Fedora-ARM blog.
A collections of blogs from all contributors to Fedora-ARM.
A collections of blogs from all contributors to Fedora-ARM.
Subscribe to:
Posts (Atom)