[00:26] <zul> zul
[00:27] <highvoltage> highvoltage
[00:28] <highvoltage> TIMMEAH
[00:42] <nigelb> highvoltage: heh
[03:57] <didrocks> cjwatson: skaet: FYI, nux and unity uploaded, release well tested :)
[03:57] <didrocks> now more than time to go to bed, see you tomorrow
[03:57] <skaet> didrocks:  awesome.    thanks!   sleep well.
[03:57] <didrocks> thanks :)
[08:55] <ogra_> lamont, Calling command: /home/buildd/bin/BuildLiveCD -f ext3 -s omap4 -d natty ubuntu-headless
[08:55] <ogra_> ssh: connect to host acorn.buildd port 22: No route to host
[08:55] <ogra_> acorn.buildd finished at Thu Mar 24 08:38:03 UTC 2011 (failed)
[13:46] <zul> does anyone know what happened to the amd64 iso for server today?
[13:47] <ogra_> did you check the logs?
[13:48] <zul> where are the logs?
[13:49] <ogra_> http://people.canonical.com/~ubuntu-archive/
[13:49] <ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/natty/ for server
[13:51] <zul> ogra_: thanks
[14:15] <cjwatson> zul: I've fixed the overrides for the next publisher run
[14:16] <zul> cjwatson: cool thanks..
[14:16] <cjwatson> (some packages were at Priority: required when they shouldn't have been, due to a snafu in NEW)
[14:51] <Riddell> is this acceptable? https://lists.ubuntu.com/archives/ubuntu-archive/2011-March/040160.html  linking to sources on sourceforge to comply with MPL/GPL obligations, I would say not since the files on sourceforge might disappear
[14:53] <cjwatson> I'd tend to agree, we should meet our source distribution obligations without the aid of third parties
[14:53] <cjwatson> if nothing else it's in our own interest to do so
[14:53] <cjwatson> (though I haven't read the exact terms of the MPL here)
[15:12] <ScottK> Would a copy of the source at p.u.c be sufficient?
[15:13] <cjwatson> why can't it go in the package?
[15:14] <cjwatson> it doesn't have to be built from it if the governing licence doesn't require that; but we have a perfectly good standard way to distribute source, I'm not sure why we wouldn't want to use it
[15:14] <ScottK> Makes sense.
[15:16] <ScottK> cjwatson: I discussed adding mx51images for Headless and Kubuntu with skaet last night and she was in favor.  I also confirmed that the hardware I have to test them is functional with that subarch (and doesn't need a separate one of it's own).  Would you be able to help me out with getting the images started?
[15:17] <cjwatson> ScottK: possibly, what's involved?
[15:17] <ScottK> cjwatson: For Headless it should be just another subarch build.
[15:18] <ScottK> I'm not sure what exactly needs to be done for that.
[15:18] <cjwatson> well, what's the required image format like?
[15:19] <ScottK> I don't know more than 'like the ompa3/4 images'
[15:24] <cjwatson> I think we used to have i.MX51 images.  Would it be sufficient to resurrect them?
[15:25] <cjwatson> in fact, the code's still in debian-cd for natty, just not built
[15:25] <ScottK> It should be.
[15:25] <cjwatson> what kernel should be used?
[15:25] <cjwatson> we'll need a d-i build against it
[15:25] <ScottK> It's built out of the linaro kernel.
[15:25] <ScottK> let me look
[15:26] <ScottK> https://launchpad.net/ubuntu/+source/linux-linaro-mx51
[15:27] <cjwatson> good, it has udebs at least
[15:42] <seb128> should bug #727726 be assigned to someone or milestoned? it's still an issue
[15:42] <ubot4`> Launchpad bug 727726 in ubiquity (Ubuntu Natty) (and 1 other project) "gnome panel is about 4px instead of 30 on install (affects: 2) (heat: 177)" [Low,Confirmed] https://launchpad.net/bugs/727726
[15:45] <seb128> the current custom partioner screen and tz selection page don't fit on a 1024x600 screen also
[15:45] <seb128> there is bug #732068 and a serie of others in launchpad
[15:45] <seb128> but none seems targetted for natty
[15:45] <ubot4`> seb128: Bug 732068 on http://launchpad.net/bugs/732068 is private
[15:46] <seb128> bug #732068
[15:46] <ubot4`> Launchpad bug 732068 in ubiquity (Ubuntu) "partitioning part of LiveCD installer doesn't fit on 1024x600 screen (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/732068
[15:46] <seb128> it's not? stupid bot :p
[15:49] <cjwatson> ev: ^- FYI
[15:49] <ev> indeed, on my hit list via a separate bug
[15:49] <ev> marking as a duplicate now
[15:49] <seb128> ev: thanks
[15:50] <seb128> ev: btw we were discussing ubuntu-geonames with desktopers yesterday, do you know if the fact that the locations are not translated would be easy to fix for natty?
[15:51] <seb128> not sure where the datas are coming from and if the translated infos are available
[15:52] <ev> https://bugs.launchpad.net/ubuntu-geonames/+bug/729022
[15:52] <ubot4`> Launchpad bug 729022 in indicator-datetime (Ubuntu Natty) (and 5 other projects) "Locations in the settings are not localized (affects: 1) (heat: 10)" [Low,Invalid]
[15:53] <ev> mterry and I talked through it a bit yesterday in #ubuntu-installer
[15:53] <ev> I don't know if I'll have time for that, but fortunately it's a largely a server-side problem
[15:53] <seb128> ev: right, the question is rather "is that something easy to fix, or is the current database you use not providing what is needed"
[15:53] <ev> we can anticipate the eventual change by passing the locale as an argument to the url
[15:53] <ev> the database has it
[15:54] <seb128> ev: or asked differently "should we look at using libgweather for the indicator to fix that issue"
[15:54] <seb128> which is what the GNOME applet uses
[15:54] <seb128> it has its locations translated
[15:54] <ev> it has a table of translated names
[15:54] <seb128> ok
[15:54] <seb128> so let's try to fix it
[15:54] <seb128> ev: thanks ;-)
[15:55] <ev> http://irclogs.ubuntu.com/2011/03/23/%23ubuntu-installer.html around 14:24
[15:55] <ev> sure
[23:00] <slangasek> lamont: do you know why https://launchpad.net/ubuntu/+source/libgd2/2.0.36~rc1~dfsg-5ubuntu2/+buildjob/2342500 is starting in 1 minute for 30 minutes?  Is that within tolerance for launchpad's ability to predict start times, or is something wedged? :)
[23:19] <Daviey> I thought https://launchpad.net/ubuntu/+source/gcj-4.5/4.5.2-7ubuntu1/+buildjob/2342162 looked wedged... but seems it does take a long time!  took 18 hours, 35 min to build on Maverick.. that is awful.  (compared with 2.5 hours on amd64)
[23:30] <slangasek> right, libgd2 is building now, so 'sallgood
[23:31] <doko> Daviey: don't worry about java core packages, take care of eucalyptus ;p
[23:32]  * slangasek chuckles