[00:28] chrisccoulson, were you able to re-add the window buttons? === asac_ is now known as asac [12:42] micahg, could you please do a verbose build of chromium on ARM in a native PPA for me? for bug 791283 [12:42] Launchpad bug 791283 in chromium-browser "chromium-browser version 11.0.696.71~r86024-0ubuntu1 failed to build on armel" [Undecided,Incomplete] https://launchpad.net/bugs/791283 [12:42] (just set VERBOSE=1) === m_conley_away is now known as m_conley [16:20] fta: yes, I can throw that up in a bit === dpm_ is now known as dpm [19:36] micahg, https://launchpad.net/~chromium-daily/+archive/dev/+build/2542393 [19:40] i guess this particular builder has a problem === Tux is now known as Guest78361 [19:56] fta: is it hung there? [20:11] micahg, no, -dbg is also very long. i pointed you to ld chrome where my keep-alive is visible. that's where it used to timeout [20:12] fta: ah, cool, also, just adding VERBOSE=1 to the top of debian/rules is enough for what doko wants? [20:13] yes [20:13] k, uploading in a minute to the mozilla-security PPA, I'm only building armel [20:13] thanks [20:33] micahg, https://launchpadlibrarian.net/72861598/buildlog_ubuntu-natty-amd64.chromium-browser_13.0.782.1~r87465-0ubuntu1~ucd~dev1~natty_BUILDING.txt.gz look for "keep-alive" [20:34] wow 2h 40 minutes to link [20:34] but it's weird as it's not supposed to spend that long on natty x64 [20:35] anyway, it didn't timeout, and that's what counts [20:36] cool [20:36] here's the armel test build: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/2542760 [20:38] it should fail within 20min or so === yofel_ is now known as yofel [20:58] micahg, is doko asking for the log alone or also the binaries produced? [20:59] fta: no idea, though, if the build can't complete, how can you get binaries [20:59] by building locally, but i can't [21:00] if the build can't complete, how can you build locally? [21:02] when i pbuild locally and it fails, i end up in a shell withing the build tree [21:02] -h [21:02] grr, -g [21:03] oh, the .o are built with g++-4.5, but the binary is linked with g++ [21:03] so it's 4.6 [21:03] m_conley, no tbird beta yet? ;) [21:04] chrisccoulson: very soon! [21:04] m_conley, how soon? i'm wondering whether to upload the current build ;) [21:04] chrisccoulson: you should probably ask Standard8 #maildev for details [21:05] chrisccoulson: also, disk space? [21:05] m_conley, ah. pitti is on vacation today, and i wanted to talk to him about that :) [21:05] so, the current situation is that we can't fit it on [21:05] but i'm not sure what scope there is for trimming more off the CD atm [21:06] from what pitti was talking about yesterday, it doesn't seem like there's a lot of scope for removing much more [21:06] s/gdm/lightdm will help a little [21:06] i think that will be in the order of kB tbh ;) [21:06] if we can help Debian transition to python 2.7, that'll give us 10MB :) [21:06] micahg, could please retry with http://paste.ubuntu.com/617014/ ? [21:07] m_conley, i think pitti is back tomorrow, so i will talk to him about what he has planned for trimming things off the CD [21:07] fta: is there a reason you're using 4.5? [21:08] micahg, because it doesn't build with 4.6 yet [21:08] micahg, it fails at many places, and it's not supported by upstream yet [21:08] m_conley, note that the current desktop ISO's are already about 15MB oversize too :( [21:08] k, will make the change [21:08] chrisccoulson: can you tell us yes or no by tomorrow? [21:08] m_conley, yeah, i hope so :) [21:11] Last I saw pitti talking about it he said he doesn't know how we'll do it [21:12] m_conley, oh, i see it is close now based on the discussion on #tbdrivers ;) [21:12] Omega, yes, that's my feeling too. it doesn't help having qt, gtk2 and gtk3 on the CD :( [21:12] fta: uploaded again [21:21] chrisccoulson: Is there anything that we're shipping that uses Qt? [21:22] i hope LINK.host was enough, there's also LINK [21:22] Omega, yes, unity-2d [21:22] Oh right. [21:22] chrisccoulson: xubuntu is 90MB oversized ATM :) [21:22] micahg, ouch [21:22] and that ships tbird doesn't it? [21:22] most of that is due to pulling in the GNOME stack with gdm [21:23] yeah, they do [21:32] w00t, i've just converted the first extension on lucid and maverick to a pseudo-system-wide extension \o/ [22:04] fta: still failed: https://launchpadlibrarian.net/72876251/buildlog_ubuntu-oneiric-armel.chromium-browser_11.0.696.71~r86024-0ubuntu1~armeltest1_FAILEDTOBUILD.txt.gz === m_conley is now known as m_conley_away [22:20] micahg, yep, but this time, it's all g++-4.5, so it's no longer chromium's fault [22:24] fta: k, let me know if you need anything else === davida is now known as davidascher [22:32] uh, chromium 14 [22:38] Uuhhhh [22:41] well, stable hit on 4/27, so chromium 12 should be coming next week [22:43] * micahg is expecting a stable channel point release update before that though [22:43] might not happen [23:08] micahg, they branch at fixed dates, but they release when it's ready [23:31] chrisccoulson: did you purposely not subscribe -archive to the thunderbird-locales removal bug? [23:31] micahg, i'll just ping pitti in the morning. he likes those bugs ;) [23:31] but, yeah, i just forgot to subscribe them [23:32] k, the removal queue is backed up at the moment [23:32] chrisccoulson: how did you end up handling the epoch? [23:32] heh [23:32] i use dh_gencontrol -v to change the version for the language packs ;) [23:32] k [23:33] i discussed it with pitti first, and it seems like the only sane way to handle it without adding an epoch to the thunderbird source, or thinking up a new name for the language packs and providing a bazillion transitional packages [23:33] k, sounds like a good solution