[00:43] <micahg> chrisccoulson: the initial builds for sept 7 have been tagged, but I'm still following up with upstream about whether or not we need an NSPR bump
[00:45] <chrisccoulson> micahg - cool. but we still need NSS don't we?
[00:46] <micahg> chrisccoulson: yeah, that landed for 192
[00:46] <micahg> nspr landed with it, but it might not be needed
[00:46] <chrisccoulson> ok, i'll get that sponsored to maverick tomorrow
[00:46] <micahg> and for Firefox it really doesn't matter
[00:46] <micahg> since we use bundled libs
[00:47] <chrisccoulson> yeah, i think i'll just push 3.6.9+build1 to maverick tomorrow
[00:47] <chrisccoulson> hopefully with working breakpad!
[00:47] <micahg> chrisccoulson: well, I'd rather not'
[00:47] <chrisccoulson> really?
[00:47] <micahg> chrisccoulson: that'll be the build on the beta CD most likely
[00:47] <micahg> if there's a problem, what do we do/
[00:48] <micahg> it's a catch 22
[00:48] <micahg> if we upload, it might be secure but broke
[00:48] <micahg> if we don't it'll work, but will be vulnerable
[00:49] <chrisccoulson> the freeze is 1 week, and we can still use some of that period to fix blockers for the beta
[00:49] <chrisccoulson> (if anything went wrong)
[00:49] <chrisccoulson> the only issue with waiting is that we'll unfreeze only a few days before 3.6.9 is meant to be released
[00:49] <chrisccoulson> and then there will be a huge backlog of builds to contend with too
[00:50] <micahg> chrisccoulson: right, well, we can get in security PPA and build now :)
[00:50] <micahg> and get the other stuff in maverick and not risk a broken build on the CD
[00:51] <chrisccoulson> yeah, we can for the other releases. i want to switch on the crash reporter for the lucid update though, so i need to speak to jdstrand first
[00:52] <micahg> chrisccoulson: beta has much higher uptake than the alpha milestones, so I think we should be safe with the build that works
[08:26]  * sebner waves
[08:27] <sebner> Since a few days firefox (maverick) isn't displaying external youtube videos. A fresh profile fixes the issue but I'm wondering how to move my history/bookmarks/cookies from the old to the new profile
[10:27] <Steelynose> firefox 3.6.3 and thunderbird 3.0.6 in lucid abort execution of /etc/[firefox|thunderbird]/pref/[firefox|thunderbird].js when there is a call line like 'var userName = getenv("USER");'
[10:28] <Steelynose> where should such configurations be put at?
[10:30] <Steelynose> sorry wgron version for firefox, should be 3.6.8
[10:56] <chrisccoulson> Steelynose, no, you can't do that. what are you actually trying to do?
[10:58] <Steelynose> I'm trying to preset mail accounts in thunderbird, for which I need the user's login which is available through the environment variable "USER"
[10:59] <chrisccoulson> those files are specifically for setting preferences, you can't do anything else with them
[10:59] <Steelynose> that's exactly what I want to do
[11:00] <chrisccoulson> and then do what with the preference?
[11:00] <Steelynose> we have a working setup with a locally managed thunderbird installation under opensolaris
[11:01] <chrisccoulson> sebner - did you get flash working in the end?
[11:01] <chrisccoulson> you could try removing Cache and pluginreg.dat from your profile folder
[11:01] <Steelynose> when a user starts thunderbird for the first time, the server settings to access his mailbox are automatically created using the preference system
[11:01] <Steelynose> I'm planning on a deployment for 5000+ users
[11:02] <chrisccoulson> you need to write an extension for that, you shouldn't be doing it with preferences
[11:02] <Steelynose> no, it seems more than a lack of support in the thunderbird.js
[11:02] <sebner> chrisccoulson: flash is working (youtube, games) but not if a site includes a youtube video
[11:03] <chrisccoulson> Steelynose, no. they're preference files that are parsed for static values. you can't actually run any javascript in them. that is what extensions are for
[11:03] <chrisccoulson> you're doing it completely wrong
[11:04] <Steelynose> chrisccoulson: https://developer.mozilla.org/en/MCD , see getenv
[11:04] <Steelynose> for shure this is supported with stock thunderbird, but not via firefox.js
[11:05] <Steelynose> or thunderbird.js
[11:05] <Steelynose> background for this: the settings we make should not be overwritten on package updates
[11:05] <Steelynose> we are using this in a vdi environment
[11:06] <chrisccoulson> Steelynose, right, it's supported through using a cfg file
[11:06] <chrisccoulson> but not the preferences files like you're trying to do
[11:07] <Steelynose> ah, ok, I didn't realize there is a difference
[11:08] <Steelynose> so if I use pref("general.config.filename", "mythunderbird.cfg"); in thunderbird.js where does mythunderbird.cfg has to be located?
[11:08] <chrisccoulson> i think in the application folder
[11:09] <Steelynose> so it's not possible to use such settings site-wite being protected from package upgrades?
[11:10] <chrisccoulson> probably not, no
[11:10] <chrisccoulson> we could probably fix that
[11:10] <Steelynose> or is my information not correct that the referenced file can not include an absolute path like /etc/thunderbird/conf/mythunderbird.cfg
[11:11] <chrisccoulson> i don't think it can. i think somebody already tried this, and it didn't work
[11:11] <Steelynose> a fix to that would be much appreciated
[11:11] <chrisccoulson> what we need to do really is ship a template in /etc/thunderbird and symlink it from the install folder
[11:11] <chrisccoulson> that might work
[11:12] <Steelynose> sounds like a dirty fix ;-)
[11:12] <Steelynose> as the filename to use is hard coded this way
[11:13] <chrisccoulson> well, that's already the case for the system preferences
[11:13] <chrisccoulson> eg, with firefox we ship a /etc/firefox/pref/firefox.js, which is symlinked from the install folder
[11:13] <Steelynose> oh, I haven't investigated that
[11:14] <chrisccoulson> although, that's going away in firefox 4
[11:15] <Steelynose> ? there's a new preferences system in firefox 4?
[11:15] <chrisccoulson> well, not a new preference system. but all of the preferences are rolled in to a single file at build-time now, so they can't be edited or changed on an installed system
[11:16] <chrisccoulson> applications wishing to add new preferences will do so by installing an extension
[11:16] <chrisccoulson> (which is the proper way anyway)
[11:16] <chrisccoulson> and we'll probably provide an extension to expose a system-wide preference file
[11:17] <Steelynose> hm, ok, so the best way to implement our mail setup would be to write an extension for it
[11:17] <chrisccoulson> see here for why that's changing - http://blog.mozilla.com/mwu/2010/08/13/omnijar-how-does-it-work/
[11:18] <Steelynose> great, thanks for the link
[11:21] <Steelynose> but still, at least a fix for thunderbird 3.* would be really appreciated ;-)
[11:41] <sebner> chrisccoulson: didn't fix the issue btw :\
[15:08] <jdstrand> chrisccoulson: we are going to want to test the crashhandler with the apparmor profile on
[15:09] <chrisccoulson> jdstrand, yeah, we should. have you tested that in maverick yet?
[15:09] <chrisccoulson> although, in maverick you need the patch from http://breakpad.appspot.com/166001 anyway
[15:09] <jdstrand> chrisccoulson: I have not specifically
[15:09] <jdstrand> I have 3.6.8+build1+nobinonly-0ubuntu3 with additionall apparmor patches
[15:10] <jdstrand> s/all/al/
[15:34] <chrisccoulson> micahg - did you find out whether we need the latest NSPR?
[15:35] <chrisccoulson> jdstrand, i've just realised i never gave you there nss/nspr packages yet ;)
[15:35] <chrisccoulson> s/there/the
[15:53] <chrisccoulson> jdstrand, i've put nss/npsr in http://people.canonical.com/~chrisccoulson
[15:56] <jdstrand> chrisccoulson: ok
[16:19] <jdstrand> chrisccoulson: so, are nss/nspr required for something in maverick?
[16:19] <chrisccoulson> jdstrand, yeah, for the xul1.9.2.9 update
[16:21] <jdstrand> chrisccoulson: rather than lintian overiding the versionless GPL stuff, why not just adjust debian/copyright to use GPL-2 and LGPL-2.1?
[16:22] <jdstrand> chrisccoulson: (for nss)
[16:22] <jdstrand> I haven't looked at nspr yet
[16:22] <jdstrand> looking at what is written in debian/copyright, my suggestion seems appropriate
[16:23] <chrisccoulson> jdstrand, the copyright information doesn't give a specific version (it says "the terms of the GNU General Public License version 2 or subsequent, or the terms of the GNU Lesser General Public License version 2.1 or subsequent")
[16:23] <chrisccoulson> so i thought it made sense to point to the versionless symlink, which is updated to point to the latest version
[16:25] <jdstrand> chrisccoulson: well, the files are licensed GPL-2.0 by spot checking a few, and the GPL-2 already has the "or later" bits in there
[16:26] <jdstrand> chrisccoulson: I think that GPL-2 is more accurate
[16:26] <chrisccoulson> jdstrand, ok, i can fix that
[16:26] <jdstrand> chrisccoulson: I appreciate it
[16:32] <jdstrand> chrisccoulson: can you do the same with nspr?
[16:32] <jdstrand> chrisccoulson: I'll upload both when you are done
[16:42] <chrisccoulson> jdstrand, ok, that's done now
[16:44] <jdstrand> chrisccoulson: ack
[17:04] <jdstrand> chrisccoulson: uploaded
[17:05] <chrisccoulson> jdstrand, thanks
[17:05] <jdstrand> sure :)
[17:14] <micahg> chrisccoulson: not yet, let me ping again
[17:15] <micahg> chrisccoulson: either way, I don't think we should push it out
[17:16] <micahg> PR_STATIC_ASSERT moves from prlog.h to prtypes.h and that might cause other packages to need updates
[17:17] <chrisccoulson> that's ok, it only affects things needing a rebuild, and pretty much everything using nspr includes prtypes.h anyway
[17:18] <chrisccoulson> most things using nspr wouldn't work if they didn't include that
[17:19] <jdstrand> chrisccoulson: I'm wondering the status of firefox and the apparmor fixes and the pending beta freeze
[17:21] <chrisccoulson> jdstrand, yeah, what do you think too?
[17:21] <chrisccoulson> (do another 3.6.8 upload for beta and move to 3.6.9 after the freeze, or upload 3.6.9+build1 now)
[17:21] <jdstrand> chrisccoulson: wait, what? I was asking a different question. I just want my apparmor fixes in :)
[17:21] <jdstrand> ah
[17:22] <chrisccoulson> jdstrand, yeah, i need to decide in order to get them in though ;)
[17:22] <jdstrand> chrisccoulson: how sure of we that 3.6.9 will be out by release?
[17:23] <chrisccoulson> jdstrand, i'm fairly sure it will be out by release. it's just whether it will be out before final freeze (although i think that's still pretty low risk)
[17:23] <chrisccoulson> the issue is whether we should introduce a new version right before we freeze and spin the beta ISO's
[17:23] <jdstrand> chrisccoulson: what is build1 exactly, in terms of upstream? is it a beta, an rc?
[17:24] <chrisccoulson> jdstrand, it's what goes out to the beta channel, and will (hopefully) become 3.6.9 if there are no issues
[17:24] <jdstrand> chrisccoulson: have there been any showstoppers upstream?
[17:24] <jdstrand> chrisccoulson: ie, are you expecting a respin?
[17:24] <jdstrand> (of 3.6.9)
[17:25] <chrisccoulson> jdstrand, it's difficult to say, we only got this one yesterday
[17:25] <micahg> jdstrand: what's better to have a stable build that will have known security vulnerabilities 4 days after release or a beta build that might have issues
[17:25] <micahg> not even in beta channel yet
[17:25] <jdstrand> micahg: well, depending on the freeze window, what we have in maverick will still have the security issues
[17:26] <jdstrand> I'm not concerned with that at all really
[17:26] <jdstrand> all releases get timely mozilla updates
[17:26] <jdstrand> and whether it is 4 days, 10 days, 3 weeks, it doesn't really matter
[17:27] <jdstrand> (I mean it sorta does, but...)
[17:27] <jdstrand> 4 days, 1- days, 3 weeks, etc after maverick releases that is
[17:28] <chrisccoulson> we should probably wait until after the freeze then
[17:28] <jdstrand> I want to say 3.6.9build1, but for some reason I'm feeling conservative and think 3.6.8 is better
[17:28] <jdstrand> maybe revisit 3.6.9 for after beta
[17:29] <jdstrand> anyway, that's my opinion
[17:30] <chrisccoulson> jdstrand, the main concern is we don't really have a feel for the quality of it until it's pushed out to the beta channel tomorrow
[17:30] <chrisccoulson> (and we'll be frozen then)
[17:31] <jdstrand> chrisccoulson: it seems clear that we should wait then
[17:32] <chrisccoulson> ok, i'll do another 3.6.8 upload later. i'm stringing it out as long as possible, as i really want to get the breakpad patch in
[17:32] <jdstrand> chrisccoulson: upstream hasn't stated this is beta quality, we shouldn't either
[17:32] <chrisccoulson> but i'm still going through review comments on it
[17:33] <jdstrand> I'm sure you'll make the right decision. it isn't like people won't get 3.6.9 eventually :)
[17:33] <jdstrand> 3.6.8 seems safer, especially since more people will be trying out maverick beta
[17:58] <micahg> chrisccoulson: well, I'll start dogfooding 3.6.9, do you think FF4 will be ready this weekend for me to make the beta PPA?
[17:59]  * micahg is actually going to call it firefox-next
[18:00] <chrisccoulson> micahg - yeah, should be. i'll try and fix the main issue before then (rolling our preferences in to the build, unless you want to have a crack at that)
[18:02] <micahg> chrisccoulson: I don't know if I'll have time, but if I do, i can try, that code's probably changed quite a bit since the patch was made
[19:25] <sebner> chrisccoulson: another idea what I can do about my firefox - flash - profil problem? =)
[19:40] <chrisccoulson> sebner - you could try removing some of the other transient files (eg, XPC.mfasl, XUL.mfasl, xpti.dat, compreg.dat, extensions.ini and extensions.cache)
[19:42] <chrisccoulson> make sure you backup though ;)
[19:43] <sebner> hehehehehe
[19:43] <sebner> chrisccoulson: I'll give it a try :)
[20:04] <chrisccoulson> micahg - we can't build nss 3.12.7 without nspr 4.8.6 anyway (it needs PL_ClearArenaPool, which is a new function)
[20:04] <chrisccoulson> http://bazaar.launchpad.net/~mozillateam/nspr/nspr.head/revision/68
[20:25] <micahg> chrisccoulson: right, but we don't need either for Firefox, for xulrunner on the other hand is questionable
[20:29] <chrisccoulson> micahg - oh, of course. it's only 2.0 that requires the newer nss ;)
[20:30] <micahg> chrisccoulson: well, I meant we could always use the bundled nss/nspr if the version isn't high enough in the release just like sqlite
[20:31] <chrisccoulson> yeah, i'd prefer not to change that in a security update though
[20:32] <micahg> chrisccoulson: k, well, 1.9.1 doesn't need it anymore, the question is 1.9.2
[20:33] <micahg> chrisccoulson: we're discussing if it's needed or not in mozilla 567620 and I copied you on the msgs to the release driver
[20:33] <ubot2> Mozilla bug 567620 in Build Config "mozilla-central won't build with the latest system NSPR (4.8.4)" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=567620
[20:33] <chrisccoulson> thanks
[20:34] <chrisccoulson> did you see tb3.1.3 is tagged now?
[20:34] <chrisccoulson> and sm2.0.7. it's going to be a fun week
[20:35] <micahg> chrisccoulson: yep, all planning on releasing 2010-09-07
[20:35] <micahg> or thereabouts
[20:36] <micahg> chrisccoulson: we need to wait and see what happens to my NSPR bug befor preparing tb3.1.3, SM and TB3.0 shoudl be ok though
[20:37] <micahg> chrisccoulson: also, I think we should wait another month before updating Lucid, there still seem to be a few issues with 3.1.x
[20:37] <chrisccoulson> jdstrand, i'm not too sure what to do with bug 609941. so far, nobody else has reported this since the last week of july
[20:37] <ubot2> Launchpad bug 609941 in firefox-3.5 (Ubuntu Karmic) (and 1 other project) "package firefox 3.5.9 nobinonly-0ubuntu0.9.10.1 failed to install/upgrade: trying to overwrite '/usr/share/bug/firefox/presubj', which is also in package firefox-2 0:2.0.0.21~tb.21.308 nobinonly-0ubuntu0.8.04.1 (affects: 1) (heat: 120)" [High,Triaged] https://launchpad.net/bugs/609941
[20:37] <micahg> although, I'm not sure if 3.0 is better.  I want to update the stable PPA soon and see if I can get some people with open 3.0 bugs to test
[20:38] <chrisccoulson> micahg - yeah, i don't mind waiting another iteration
[20:39] <chrisccoulson> jdstrand - we only really have 2 options for that bug:
[20:39] <jdstrand> chrisccoulson: I suggest adding the conflicts as you suggested
[20:39] <micahg> chrisccoulson: the thing I"m waiting on for the stable PPA is I need to make sure the wrapper script works correctly for 2.0 upgrades
[20:39] <chrisccoulson> 1) Add a transitional package and associated conflicts (like you suggested), which wil remove the package. i'm not sure how acceptable that is in a security update though
[20:40] <chrisccoulson> or, 2) move the files in the main FF package around to avoid the conflict, which i'm not so keen on doing
[20:40] <chrisccoulson> seeing as only 2 people reported the bug, i'd rather not risk another regression by moving conffiles around ;)
[20:40] <jdstrand> 2 sounds regression prone
[20:40] <chrisccoulson> yeah, i'd rather not do 2 either. if it was affecting lots of users then it might be more acceptable
[20:41] <jdstrand> '1' seems safest, if not totally ideal
[20:41] <chrisccoulson> ok, i'll try and get that in to the 3.6.9 update tonight
[20:41] <chrisccoulson> jdstrand, do we need a separate USN for thunderbird (3.0.7 and 3.1.3)?
[20:42] <jdstrand> chrisccoulson: well, 3.1.3 is in maverick, so no USN
[20:42] <chrisccoulson> yeah, i forgot ;)
[20:48] <sebner> chrisccoulson: unfortunately didn't fix the issue either
[23:12] <micahg> chrisccoulson: is this a bad changelog: http://pastebin.ubuntu.com/483650/
[23:13] <chrisccoulson> micahg - i don't think so. i've done changelogs like that before
[23:13] <micahg> chrisccoulson: k :)
[23:13] <micahg> I got my FFes :)
[23:13] <chrisccoulson> cool
[23:14] <micahg> so we get sqlite 3.7.2 in maverick hopefully
[23:16] <micahg> chrisccoulson: I think we're still going to end up with an Ubuntu diff because of the wrapper for mediatomb (will work on later), but I'll see what the pkg-multimedia team says about it
[23:28] <micahg> chrisccoulson: so, 1.5 hrs till freeze, what's happening w/maverick and 3.6.9/bzr fixes