[00:10] <ari-tczew> chrisccoulson, micahg: could you comment on merges.u.c packages which are not mergeable? we use form 'Do not merge'
[00:10] <micahg> ari-tczew: we went through this before...
[00:12] <micahg> nonetheless, I added the message to nss and nspr
[00:13] <ari-tczew> micahg: yes, but I remember when chrisccoulson told me that some packages are not mergeable with Debian due to another packaging style.
[00:14] <micahg> yep, we should add them to the sync blacklist list as well, I'll discuss that with him
[00:14] <ari-tczew> micahg: would be nice, thanks
[00:14] <micahg> ari-tczew: I appreciate your efforts
[00:15] <ari-tczew> micahg: wow, I'm glad
[00:18] <micahg> chrisccoulson: do you need to be explicit in setting -DDEB_NO_OPTIMIZE=1?
[00:18] <chrisccoulson> micahg - not really ;)
[00:18] <chrisccoulson> there's a few inconsistencies
[00:20] <micahg> chrisccoulson: ok
[00:28] <ari-tczew> micahg: only these 2 packages?
[00:29] <micahg> ari-tczew: AFAICT, chromium-browser, firefox, seamonkey, thunderbird, and xulrunner* is the other
[00:29] <ari-tczew> did you look on https://merges.ubuntu.com/universe-manual.html ?
[00:29] <micahg> ari-tczew: I don't see any mozilla packages on that list
[00:30] <ari-tczew> micahg: aha, I'm following there where chrisccoulson is TIL
[00:30] <micahg> ari-tczew: chrisccoulson last cycle was heavily involved with the desktop team :)
[00:31] <ari-tczew> aha
[00:51] <micahg> chrisccoulson: about gnash, should we file another bug to fix up the alternatives and just have this merge be updated to install in the correct path?
[00:59] <chrisccoulson> micahg - i don't mind too much really. it's probably quicker to just do gnash and flashplugin-installer at the same time :)
[01:00] <micahg> chrisccoulson: right, but I think it's reasonable to have the merge updated to install only in mozilla/plugins
[01:00] <chrisccoulson> yeah, we should definately do that
[01:00] <chrisccoulson> i want to do that with all plugins really
[01:00] <micahg> chrisccoulson: the old postrm will remove the old entries right?
[01:01] <chrisccoulson> micahg - yeah, it should do
[01:01]  * chrisccoulson looks at http://adren.org/~cyril/debian/MaintainerScripts.html
[01:01] <chrisccoulson> :)
[01:04] <micahg> chrisccoulson: any harm carrying old alternatives in teh postrm to make sure we get rid of them?
[01:04] <micahg> it seems like we should do this for one cycle to be safer
[01:04] <chrisccoulson> we shouldn't need that really, but if we did, it would probably be better in the preinst script instead
[01:05] <micahg> chrisccoulson: preinst gets run before portrm
[01:05] <micahg> *postrm
[01:06] <chrisccoulson> yeah, that's ok. it's normally where you'd handle upgrade cleaning. as long as the old postrm doesn't fail if the alternatives are already gone, but they should handle that already
[01:10] <micahg> chrisccoulson: BTW, lightning backported to Lucid fine, but won't build on earlier series, but idk if I really care
[01:11] <chrisccoulson> yeah, i think i saw that. i think it needs a newer mozilla-devscripts to build on older releases
[01:11] <micahg> chrisccoulson: yeah, I suppose I can just copy that over from the daily PPA
[01:11] <chrisccoulson> it needs the dh7 sequence
[01:11] <micahg> so that would work on karmic only
[01:12] <micahg> unless I copy the dh7 backport from the daily PPA as well
[01:15] <chrisccoulson> ooh, i got conkeror working :)
[01:15] <chrisccoulson> it wasn't what i thought it was in the end
[01:15] <chrisccoulson> the chrome.manifest is installed in the wrong place, so i need to move it and adjust all the path names
[01:15] <chrisccoulson> that was a pure guess though!
[01:17] <micahg> cool
[01:18] <chrisccoulson> oh, it's simpler than that. we're just not installing the top-level chrome.manifest, which just includes the pre-existing one
[01:18] <chrisccoulson> d'oh!
[01:18] <chrisccoulson> easy fix though
[05:27] <micahg> \o/ memory usage is much better with the daily than b7
[05:28] <micahg> nm, took a second to eat it all :P
[09:15] <dpm> fta2, fta, are you around? I've just spoken to henninge and jtv, and we could perhaps reserve ~30 minutes to have a chat to go through the remaining blockers for chromium translations. Would you have time and a preferred time today?
[09:15] <dpm> I was thinking of having a chat in #launchpad
[09:17] <fta2> dpm, hi
[09:17] <fta2> i'm available in a few minutes
[09:18] <dpm> fta2, just ping me when ready and we'll chat in #launchpad then. I have a call in ~45 minutes, but we can talk until then
[09:19] <fta2> ok
[15:52] <fta> dpm, let me know when you have a draft.
[15:53] <dpm> fta, yes, I'm on it, I'll e-mail you for review before publishing anything
[15:54] <fta> dpm, btw, 1 thing that may be worth insisting on: when there's n variables %{xx}, there must be the same %{xx} in the translated strings (as there's a checker at building time, leading to FTBFS)
[15:54] <fta> same n, i meant
[15:55] <fta> dpm, also, where's than html tag, it must stay parsable (there should be very few left). comes to mind the "<!-- x -->" turned into "<!- x ->" which is incorrect => FTBFS
[15:56] <dpm> right, I'll take note of these
[15:56] <dpm> thanks
[15:56] <fta> dpm, i have a sanity checker for that 2nd case, but i reject the faulty strings, it doesn't attempt to fix them
[15:57] <fta> other than that, i have nothing in particular to add
[15:58] <fta> dpm, i keep an eye on http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html but i'm not polyglot so i can't judge if lp translations are better or worse than the upstream ones
[16:01] <dpm> fta, I cannot read all languages, but looking at the Spanish translations, it seems that most of the changes in LP are enhancements to the upstream strings
[16:02] <fta> dpm, great. and they are at 100% too :)
[16:03] <dpm> fta, yeah, these guys are always at the top, also for Ubuntu: http://people.ubuntu.com/~dpm/ubuntu-10.10-translation-stats.html
[16:04] <fta> nice
[17:25] <micahg> chrisccoulson: Thunderbird wasn't ready for Natty yet :(
[17:25] <chrisccoulson> micahg - that's ok, it means i have to fix it quicker now ;)
[17:25] <micahg> I'll have a look at that this week
[17:25] <micahg> oh, if you like
[17:26] <chrisccoulson> yeah, i'll probably fix it this evening. the armel issue seems to something the linaro guys are aware of already
[17:26] <micahg> chrisccoulson: even on i386
[17:26] <micahg> chrisccoulson: fails in the daily builds as well
[17:27] <chrisccoulson> i'll get i386 and amd64 fixed in a bit, they don't look too difficult to fix
[17:48] <micahg> chrisccoulson: is dehydra something we want to keep? should I request an addition to the packageset?
[17:49] <micahg> I'm wondering how we missed that in Maverick
[17:51]  * micahg guesses doko wanted it :_/
[18:01] <chrisccoulson> micahg - yeah, doko seems to mostly take care of it
[18:09] <micahg> chrisccoulson: so, should I request addition to the packageset though?
[18:32] <chrisccoulson> micahg - yeah, you can request it be added to the packageset if you like
[19:59] <micahg> chrisccoulson: I can take a crack at the armel failure next weekend if the Linaro guys don't get to it first
[20:01] <micahg> if there's not a rush, you can just assign to me and I"ll figure it out