Maverick toolchain

[Matthias Klose]

On 29.06.2010 20:22, Matthias Klose wrote:
> On 29.06.2010 16:17, Matt Zimmerman wrote:
>> We spoke at the tech board meeting two weeks ago about the toolchain. In
>> particular, I believe it was proposed that we move to a different
>> branch of
>> the toolchain than what we started Maverick with.
>>
>> We ran out of time in the meeting, and I followed up with you on
>> #ubuntu-devel, where you responded:
>>
>> 15-06-2010 16:12:59< doko> mdz: could we do this later this week? running
>> out of time today, and I'd like to get some performance data
>> (benefits) on
>> ix86.
>>
>> Can you give us an update? Did you get the data you wanted as the
>> basis for
>> a decision? Where do we stand today?
>
> I was planning the rebuild for the end of last week, but shoot myself in
> the foot by uploading a newer compiler package to the archive than was
> in the ppa for the rebuild, so the rebuild was started today, and then
> disabled again by bigjools (requested by asac). It is currently
> difficult to get the resources for a rebuild and not to overload the
> buildds.
>
> - populate-archive cannot be run for single components (bug #599412),
> so that build records were created for all packages on amd64 and
> i386.
>
> - the next launchpad rollout will have a feature to only schedule
> rebuilds for package sets; planning to use this and existing
> package sets (using core + desktop-core + ubuntu-desktop +
> ubuntu-server + kubuntu + netbook)
>
> - test-rebuild archives are now available via the lp-api (bug #599415),
> used this feature to raise the build priority of all packages in main
> minus language package. after these are built, disable the archive
> so that the universe builds are not done.
>
> - started the rebuild, about 450 packages built within 4h, about
> 3100 need building in main on amd64 and i386.
>
> - irc discussion on #soyuz:
>
> <asac_> did doko give his rebuild high prio? seems that since that
> rebuild is started not much is going through the ppa builders anymore
> <bigjools> there's additional latency with the extra load
> <bigjools> the priority is still low for those
> <asac_> so scheduler still has scalability problems?
> <bigjools> unfortunately the build farm doesn't scale well
> <asac_> maybe we could have just scheduled main?
> <bigjools> we're fixing that RSN
> <bigjools> doko said that the code is broken and that doesn't work
> <asac_> doko: can we schedule main and universe in separate batches to
> make the scalability issues a bit less painful?
> <bigjools> asac_: the fact that there's more *queued* makes no difference
> <bigjools> it's the number of builds in progress that counts
> <asac_> bigjools: yes, but if you look at builders
> <asac_> how can it be that 70% currently do rebuild jobs?
> <asac_> while if they have a lower prio they should only be picked up if
> there are idle biulders?
> <bigjools> perhaps there was nothing else in the queue when they were
> picked up
> <asac_> na
> <asac_> my build is waiting for 4h
> <asac_> also we have a bunch of dailies that didnt make it for hours now
> <bigjools> hmmm
> <asac_> https://edge.launchpad.net/~asac/+archive/ppa/+packages
> <asac_>
> https://edge.launchpad.net/~asac/+archive/ppa/+sourcepub/1205942/+listing-archive-extra
>
> <bigjools> I'm going to disable the rebuild
> <bigjools> until we get to the bottom of it
> <bigjools> doko: your rebuild is disabled, sorry, we need to work out
> why it's hogging the builders
> <doko> asac_: bigjools: the plan is to build only main, then disable the
> archive. currently just creating build records for main isn't possible
> <doko> asac_: we do need the rebuild. the dailies aren't a priority ...
> or I'll start doing gcc dailies
> <doko> now re-enabled for the night
>
> - didn't start the armel builds yet, because the armel builders
> are busy, and I was scared about the load on the devirtualized
> buildds.
>
> If we can have the test-rebuild run for two or three days we can build
> main with the gcc linaro branch. It's true that we have problems with
> increased build times for other ppa archives, but I question if the
> daily mozilla and chromium builds should be favored instead of the
> test-rebuild.
>
> I wouldn't expect armel test-rebuild results within the next week.
>
> Matthias

the test builds on amd64, i386 and armel for maverick/main are now finished and 
evaluated.

amd64, i386:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100628/

   one package failed to build with an internal compiler error,
   which is fixed in maverick. failures in testsuites of
   packages were tracked down to problems in the testsuites.  A
   large number of failures are both seen on maverick and the
   rebuild with the linaro toolchain, all of these are fixed
   in current maverick.  Some packages couldn't be built due
   to unmet build dependencies at the time when the snapshot
   was taken.

armel:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707

   see https://wiki.linaro.org/MichaelHope/Sandbox/BuildFailures
   one internal compiler error building a package, under
   investigation.  several failures in testsuites which look
   like ix86'isms, but need closer investigation.

   KDE build failures which need the new qt4-x11 built with the
   linaro gcc.

   Various java related build failures, because openjdk was
   broken at the time of the snapshot.


For both test rebuilds there is no test failure or no build failure which can be 
attributed to a wrong code generation bug in the Linaro GCC.

The Linaro team wants to have the Linaro GCC uploaded to maverick as soon as 
possible, and wants to handle possible regressions within maverick.

I suggest to enable the Linaro GCC on amd64, i386 and powerpc as well, given the 
comittment of the Linaro toolchain working group to addressing potential 
regressions on amd64 and i386 too.

If buildd resources permit, I'll start new test rebuilds before the archive 
unfreezes after alpha3, and is a somewhat stable/buildable state.

   Matthias