Number of candidate source rpms: 13595
Number of source rpms built in stage 4: 10646
Number of packages built in stage4 with aarch64 components: 4117
Currently building packages Singular-3.1.5-5.fc19.src.rpm alienarena-7.65-2.fc19.src.rpm alienblaster-1.1.0-11.fc19.src.rpm cluttermm-1.3.3-4.fc19.src.rpm code-editor-2.3.1-15.fc19.src.rpm cuneiform-1.1.0-13.fc19.src.rpm distcc-3.2rc1-3.fc19.src.rpm f1lt-2.0.2-3.fc19.src.rpm gcc-4.8.1-2.x1.fc19.src.rpm gerbv-2.6.0-3.fc19.src.rpm gle-4.2.4c-8.fc19.src.rpm glib2-2.36.3-1.fc19.src.rpm gnome-screenshot-3.8.2-1.fc19.src.rpm gsmartcontrol-0.8.7-2.fc19.src.rpm gstreamer-plugins-fc-0.2-7.fc19.src.rpm gstreamer1-plugins-good-1.0.7-1.fc19.src.rpm hercstudio-1.4.0-2.fc19.src.rpm inkscape-0.48.4-4.fc19.src.rpm libQGLViewer-2.3.9-6.fc19.src.rpm libtool-2.4.2-16.fc19.src.rpm luckybackup-0.4.7-3.fc19.src.rpm pax-3.4-16.fc19.src.rpm perl-IPC-Cmd-0.80-3.fc19.src.rpm plug-1.1-7.fc19.src.rpm psimedia-1.0.3-11.fc19.src.rpm python-openid-teams-1.0-1.fc19.src.rpm python-pivy-0.5.0-5.hg609.fc19.src.rpm qbrew-0.4.1-10.fc19.src.rpm qca2-2.0.3-5.fc19.src.rpm qt-4.8.4-19.x1.fc19.src.rpm qt-assistant-adp-4.6.3-5.fc19.src.rpm qt-mobility-1.2.2-0.4.20120224git.fc19.src.rpm qwt-6.0.1-3.fc19.src.rpm strigi-0.7.7-8.20120626.fc19.src.rpm uClibc-0.9.33.2-3.fc19.src.rpm virtuoso-opensource-6.1.6-3.fc19.src.rpm webkitgtk-2.0.2-2.x1.fc19.src.rpm widelands-0-0.35.build17.fc19.src.rpm yubikey-personalization-gui-3.1.2-2.fc19.src.rpm zint-2.4.3-5.fc19.src.rpm
Packages building since previous report (which might be stuck or crashed) Singular-3.1.5-5.fc19.src.rpm alienarena-7.65-2.fc19.src.rpm alienblaster-1.1.0-11.fc19.src.rpm code-editor-2.3.1-15.fc19.src.rpm distcc-3.2rc1-3.fc19.src.rpm f1lt-2.0.2-3.fc19.src.rpm gcc-4.8.1-2.x1.fc19.src.rpm glib2-2.36.3-1.fc19.src.rpm gnome-screenshot-3.8.2-1.fc19.src.rpm gsmartcontrol-0.8.7-2.fc19.src.rpm gstreamer-plugins-fc-0.2-7.fc19.src.rpm hercstudio-1.4.0-2.fc19.src.rpm inkscape-0.48.4-4.fc19.src.rpm libQGLViewer-2.3.9-6.fc19.src.rpm libtool-2.4.2-16.fc19.src.rpm luckybackup-0.4.7-3.fc19.src.rpm pax-3.4-16.fc19.src.rpm perl-IPC-Cmd-0.80-3.fc19.src.rpm plug-1.1-7.fc19.src.rpm python-openid-teams-1.0-1.fc19.src.rpm qbrew-0.4.1-10.fc19.src.rpm qca2-2.0.3-5.fc19.src.rpm qt-4.8.4-19.x1.fc19.src.rpm qt-assistant-adp-4.6.3-5.fc19.src.rpm qt-mobility-1.2.2-0.4.20120224git.fc19.src.rpm uClibc-0.9.33.2-3.fc19.src.rpm virtuoso-opensource-6.1.6-3.fc19.src.rpm webkitgtk-2.0.2-2.x1.fc19.src.rpm yubikey-personalization-gui-3.1.2-2.fc19.src.rpm
Total current build failure count: 888 failed
Build failures from unsatisfied dependencies: 501 failed-dep-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-dep-rpms for complete list.
Build failures after dependency resolution: 387 failed-build-rpms See http://arm-temp.ausil.us/pub/fedora-arm/data/failed-build-rpms for complete list.
Naive Top 10 dependency issues 364 ghc-Cabal-devel 137 java-devel 103 kdelibs4-devel 90 globus-core(x86-64) >= 8 83 kdelibs4-devel >= 4.10.4 74 java-devel >= 1:1.6.0 69 erlang-rebar 59 mono-devel 52 nodejs-devel 41 wxGTK-devel
Previously broken builds that are now fixed: libmwaw-0.1.7-2.fc19 php-guzzle-Guzzle-3.4.3-1.fc19
Newly attempted builds that failed: eog-3.8.2-1.fc19 globus-openssl-module-3.2-5.fc19 gnome-commander-1.2.8.15-7.fc19.1 kannel-1.4.3-10.fc18 kaudiocreator-1.3-6.fc19 libexplain-1.2-1.fc19 network-manager-applet-0.9.8.2-1.fc19 pdfbox-1.8.1-1.fc19 pikloops-0.2.5-12.fc19 ski-1.3.2-14.fc19 smart-1.3.1-68.fc17 sugar-browse-149.3-1.fc19 vmpk-0.4.0-7.fc19
On Sun, Jun 30, 2013 at 08:10:23AM -0400, Brendan Conoboy wrote:
Number of candidate source rpms: 13595
Number of source rpms built in stage 4: 10646
Number of packages built in stage4 with aarch64 components: 4117
I have been watching the automatic mails since they were introduced, (thanks I now have yet another in memory counter, I was actually mentally happy when it crossed 4000 thinking we're getting closer to 50%). What is the limitating factor ? I don't think there is a too big depth of package dependencies, so if the main factor isn't some lack of computing power, I would have assumed that unlocking some key package (e.g. python, gtk libs, ...) would allow some quick progresses, but it smells like it's progressing purely lineary. Is that dependant on converting each of the package (like auto* updates when they lack aarch64 support ?) Cole (I assume it's mostly you based on mails and commits samples I saw), would you share the story there ?
Just being curious,
Daniel
On 06/30/2013 04:59 AM, Daniel Veillard wrote:
I have been watching the automatic mails since they were introduced, (thanks I now have yet another in memory counter, I was actually mentally happy when it crossed 4000 thinking we're getting closer to 50%). What is the limitating factor ? I don't think there is a too big depth of package dependencies, so if the main factor isn't some lack of computing power, I would have assumed that unlocking some key package (e.g. python, gtk libs, ...) would allow some quick progresses, but it smells like it's progressing purely lineary. Is that dependant on converting each of the package (like auto* updates when they lack aarch64 support ?) Cole (I assume it's mostly you based on mails and commits samples I saw), would you share the story there ?
Not sure who Cole is.
Progress is currently limited by number of builders. There are about 300 source rpms in the build queue at present and more being added as deps get built. As we get deeper into the queue the packages remaining tend to have a wider array of dependencies and take longer to build. Remember all these builds are being done by aarch64 simulation, so installing and linking with a wider array of libraries has a material impact on build time.
There are still some packages that once built will unlock a large number of additional builds. The single biggest blocker today is openjdk. We're working on bringing it in. Unlocking ghc (waiting on llvm which is waiting on gcc 4.8.1) and erlang would also unlock many.
There are a number of packages that have been attempted, but failed to build. Everybody is welcome to grab one of these and fix it- don't let us ARM team members claim all the honour! The list of broken packages is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage4_Problem_Pack...
Quick start guide for contributors is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
Cheers,
On Mon, Jul 1, 2013 at 11:31 AM, Brendan Conoboy blc@redhat.com wrote:
There are a number of packages that have been attempted, but failed to build. Everybody is welcome to grab one of these and fix it- don't let us ARM team members claim all the honour! The list of broken packages is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage4_Problem_Pack...
I have several ATLAS-using packages on that list. All of them fail at link time like this:
/usr/lib64/atlas/liblapack.so: undefined reference to `_gfortran_concat_string' /usr/lib64/atlas/libptf77blas.so: undefined reference to `_gfortran_st_write_done' /usr/lib64/atlas/liblapack.so: undefined reference to `_gfortran_pow_i4_i4' /usr/lib64/atlas/libptf77blas.so: undefined reference to `_gfortran_st_write' /usr/lib64/atlas/libptf77blas.so: undefined reference to `_gfortran_transfer_integer_write' /usr/lib64/atlas/liblapack.so: undefined reference to `_gfortran_compare_string' /usr/lib64/atlas/liblapack.so: undefined reference to `_gfortran_etime' /usr/lib64/atlas/libptf77blas.so: undefined reference to `_gfortran_transfer_character_write' /usr/lib64/atlas/libptf77blas.so: undefined reference to `_gfortran_stop_string' collect2: error: ld returned 1 exit status
Don't know what's going on there, but fixing that would get a number of other package builds going. Regards, -- Jerry James http://www.jamezone.org/
On Mon, Jul 01, 2013 at 10:31:06AM -0700, Brendan Conoboy wrote:
On 06/30/2013 04:59 AM, Daniel Veillard wrote:
I have been watching the automatic mails since they were introduced, (thanks I now have yet another in memory counter, I was actually mentally happy when it crossed 4000 thinking we're getting closer to 50%). What is the limitating factor ? I don't think there is a too big depth of package dependencies, so if the main factor isn't some lack of computing power, I would have assumed that unlocking some key package (e.g. python, gtk libs, ...) would allow some quick progresses, but it smells like it's progressing purely lineary. Is that dependant on converting each of the package (like auto* updates when they lack aarch64 support ?) Cole (I assume it's mostly you based on mails and commits samples I saw), would you share the story there ?
Not sure who Cole is.
Cole Robinson, he commited spec fixes for aarch64 in my packages :-)
Progress is currently limited by number of builders. There are about 300 source rpms in the build queue at present and more being added as deps get built. As we get deeper into the queue the packages remaining tend to have a wider array of dependencies and take longer to build. Remember all these builds are being done by aarch64 simulation, so installing and linking with a wider array of libraries has a material impact on build time.
okay
There are still some packages that once built will unlock a large number of additional builds. The single biggest blocker today is openjdk. We're working on bringing it in. Unlocking ghc (waiting on llvm which is waiting on gcc 4.8.1) and erlang would also unlock many.
There are a number of packages that have been attempted, but failed to build. Everybody is welcome to grab one of these and fix it- don't let us ARM team members claim all the honour! The list of broken packages is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage4_Problem_Pack...
I looked at a couple, both were configure not recognizing the aarch64 architecture (xalan and xerces),
Quick start guide for contributors is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
Definitely non-trivial, allows to get a better understanding of the task !
thanks for the explanations !
Daniel
-
Brendan Conoboy -
Daniel Veillard -
Jerry James