Maverick toolchain

Matthias Klose doko at
Tue Jun 29 19:22:48 BST 2010

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

  - 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
<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

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.


More information about the technical-board mailing list