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