[00:43] 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] micahg - cool. but we still need NSS don't we? [00:46] chrisccoulson: yeah, that landed for 192 [00:46] nspr landed with it, but it might not be needed [00:46] ok, i'll get that sponsored to maverick tomorrow [00:46] and for Firefox it really doesn't matter [00:46] since we use bundled libs [00:47] yeah, i think i'll just push 3.6.9+build1 to maverick tomorrow [00:47] hopefully with working breakpad! [00:47] chrisccoulson: well, I'd rather not' [00:47] really? [00:47] chrisccoulson: that'll be the build on the beta CD most likely [00:47] if there's a problem, what do we do/ [00:48] it's a catch 22 [00:48] if we upload, it might be secure but broke [00:48] if we don't it'll work, but will be vulnerable [00:49] the freeze is 1 week, and we can still use some of that period to fix blockers for the beta [00:49] (if anything went wrong) [00:49] 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] and then there will be a huge backlog of builds to contend with too [00:50] chrisccoulson: right, well, we can get in security PPA and build now :) [00:50] and get the other stuff in maverick and not risk a broken build on the CD [00:51] 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] chrisccoulson: beta has much higher uptake than the alpha milestones, so I think we should be safe with the build that works === TannerF is now known as TannerF|homework === TannerF|homework is now known as TannerF === TannerF is now known as The_{Soap} === The_{Soap} is now known as TannerF [08:26] * sebner waves [08:27] 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] 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] where should such configurations be put at? [10:30] sorry wgron version for firefox, should be 3.6.8 [10:56] Steelynose, no, you can't do that. what are you actually trying to do? [10:58] 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] those files are specifically for setting preferences, you can't do anything else with them [10:59] that's exactly what I want to do [11:00] and then do what with the preference? [11:00] we have a working setup with a locally managed thunderbird installation under opensolaris [11:01] sebner - did you get flash working in the end? [11:01] you could try removing Cache and pluginreg.dat from your profile folder [11:01] 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] I'm planning on a deployment for 5000+ users [11:02] you need to write an extension for that, you shouldn't be doing it with preferences [11:02] no, it seems more than a lack of support in the thunderbird.js [11:02] chrisccoulson: flash is working (youtube, games) but not if a site includes a youtube video [11:03] 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] you're doing it completely wrong [11:04] chrisccoulson: https://developer.mozilla.org/en/MCD , see getenv [11:04] for shure this is supported with stock thunderbird, but not via firefox.js [11:05] or thunderbird.js [11:05] background for this: the settings we make should not be overwritten on package updates [11:05] we are using this in a vdi environment [11:06] Steelynose, right, it's supported through using a cfg file [11:06] but not the preferences files like you're trying to do [11:07] ah, ok, I didn't realize there is a difference [11:08] so if I use pref("general.config.filename", "mythunderbird.cfg"); in thunderbird.js where does mythunderbird.cfg has to be located? [11:08] i think in the application folder [11:09] so it's not possible to use such settings site-wite being protected from package upgrades? [11:10] probably not, no [11:10] we could probably fix that [11:10] or is my information not correct that the referenced file can not include an absolute path like /etc/thunderbird/conf/mythunderbird.cfg [11:11] i don't think it can. i think somebody already tried this, and it didn't work [11:11] a fix to that would be much appreciated [11:11] what we need to do really is ship a template in /etc/thunderbird and symlink it from the install folder [11:11] that might work [11:12] sounds like a dirty fix ;-) [11:12] as the filename to use is hard coded this way [11:13] well, that's already the case for the system preferences [11:13] eg, with firefox we ship a /etc/firefox/pref/firefox.js, which is symlinked from the install folder [11:13] oh, I haven't investigated that [11:14] although, that's going away in firefox 4 [11:15] ? there's a new preferences system in firefox 4? [11:15] 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] applications wishing to add new preferences will do so by installing an extension [11:16] (which is the proper way anyway) [11:16] and we'll probably provide an extension to expose a system-wide preference file [11:17] hm, ok, so the best way to implement our mail setup would be to write an extension for it [11:17] see here for why that's changing - http://blog.mozilla.com/mwu/2010/08/13/omnijar-how-does-it-work/ [11:18] great, thanks for the link [11:21] but still, at least a fix for thunderbird 3.* would be really appreciated ;-) [11:41] chrisccoulson: didn't fix the issue btw :\ [15:08] chrisccoulson: we are going to want to test the crashhandler with the apparmor profile on [15:09] jdstrand, yeah, we should. have you tested that in maverick yet? [15:09] although, in maverick you need the patch from http://breakpad.appspot.com/166001 anyway [15:09] chrisccoulson: I have not specifically [15:09] I have 3.6.8+build1+nobinonly-0ubuntu3 with additionall apparmor patches [15:10] s/all/al/ === JanC_ is now known as JanC [15:34] micahg - did you find out whether we need the latest NSPR? [15:35] jdstrand, i've just realised i never gave you there nss/nspr packages yet ;) [15:35] s/there/the [15:53] jdstrand, i've put nss/npsr in http://people.canonical.com/~chrisccoulson [15:56] chrisccoulson: ok [16:19] chrisccoulson: so, are nss/nspr required for something in maverick? [16:19] jdstrand, yeah, for the xul1.9.2.9 update [16:21] 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] chrisccoulson: (for nss) [16:22] I haven't looked at nspr yet [16:22] looking at what is written in debian/copyright, my suggestion seems appropriate [16:23] 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] so i thought it made sense to point to the versionless symlink, which is updated to point to the latest version [16:25] 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] chrisccoulson: I think that GPL-2 is more accurate [16:26] jdstrand, ok, i can fix that [16:26] chrisccoulson: I appreciate it [16:32] chrisccoulson: can you do the same with nspr? [16:32] chrisccoulson: I'll upload both when you are done [16:42] jdstrand, ok, that's done now [16:44] chrisccoulson: ack [17:04] chrisccoulson: uploaded [17:05] jdstrand, thanks [17:05] sure :) [17:14] chrisccoulson: not yet, let me ping again [17:15] chrisccoulson: either way, I don't think we should push it out [17:16] PR_STATIC_ASSERT moves from prlog.h to prtypes.h and that might cause other packages to need updates === fta_ is now known as fta [17:17] that's ok, it only affects things needing a rebuild, and pretty much everything using nspr includes prtypes.h anyway [17:18] most things using nspr wouldn't work if they didn't include that [17:19] chrisccoulson: I'm wondering the status of firefox and the apparmor fixes and the pending beta freeze [17:21] jdstrand, yeah, what do you think too? [17:21] (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] chrisccoulson: wait, what? I was asking a different question. I just want my apparmor fixes in :) [17:21] ah [17:22] jdstrand, yeah, i need to decide in order to get them in though ;) [17:22] chrisccoulson: how sure of we that 3.6.9 will be out by release? [17:23] 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] the issue is whether we should introduce a new version right before we freeze and spin the beta ISO's [17:23] chrisccoulson: what is build1 exactly, in terms of upstream? is it a beta, an rc? [17:24] jdstrand, it's what goes out to the beta channel, and will (hopefully) become 3.6.9 if there are no issues [17:24] chrisccoulson: have there been any showstoppers upstream? [17:24] chrisccoulson: ie, are you expecting a respin? [17:24] (of 3.6.9) [17:25] jdstrand, it's difficult to say, we only got this one yesterday [17:25] 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] not even in beta channel yet [17:25] micahg: well, depending on the freeze window, what we have in maverick will still have the security issues [17:26] I'm not concerned with that at all really [17:26] all releases get timely mozilla updates [17:26] and whether it is 4 days, 10 days, 3 weeks, it doesn't really matter [17:27] (I mean it sorta does, but...) [17:27] 4 days, 1- days, 3 weeks, etc after maverick releases that is [17:28] we should probably wait until after the freeze then [17:28] I want to say 3.6.9build1, but for some reason I'm feeling conservative and think 3.6.8 is better [17:28] maybe revisit 3.6.9 for after beta [17:29] anyway, that's my opinion [17:30] 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] (and we'll be frozen then) [17:31] chrisccoulson: it seems clear that we should wait then [17:32] 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] chrisccoulson: upstream hasn't stated this is beta quality, we shouldn't either [17:32] but i'm still going through review comments on it [17:33] I'm sure you'll make the right decision. it isn't like people won't get 3.6.9 eventually :) [17:33] 3.6.8 seems safer, especially since more people will be trying out maverick beta [17:58] 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] 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] 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] chrisccoulson: another idea what I can do about my firefox - flash - profil problem? =) [19:40] 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] make sure you backup though ;) [19:43] hehehehehe === yofel_ is now known as yofel [19:43] chrisccoulson: I'll give it a try :) [20:04] 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] http://bazaar.launchpad.net/~mozillateam/nspr/nspr.head/revision/68 [20:25] chrisccoulson: right, but we don't need either for Firefox, for xulrunner on the other hand is questionable [20:29] micahg - oh, of course. it's only 2.0 that requires the newer nss ;) [20:30] 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] yeah, i'd prefer not to change that in a security update though [20:32] chrisccoulson: k, well, 1.9.1 doesn't need it anymore, the question is 1.9.2 [20:33] 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] 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] thanks [20:34] did you see tb3.1.3 is tagged now? [20:34] and sm2.0.7. it's going to be a fun week [20:35] chrisccoulson: yep, all planning on releasing 2010-09-07 [20:35] or thereabouts [20:36] 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] 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] 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] 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] 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] micahg - yeah, i don't mind waiting another iteration [20:39] jdstrand - we only really have 2 options for that bug: [20:39] chrisccoulson: I suggest adding the conflicts as you suggested [20:39] 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] 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] 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] seeing as only 2 people reported the bug, i'd rather not risk another regression by moving conffiles around ;) [20:40] 2 sounds regression prone [20:40] yeah, i'd rather not do 2 either. if it was affecting lots of users then it might be more acceptable [20:41] '1' seems safest, if not totally ideal [20:41] ok, i'll try and get that in to the 3.6.9 update tonight [20:41] jdstrand, do we need a separate USN for thunderbird (3.0.7 and 3.1.3)? [20:42] chrisccoulson: well, 3.1.3 is in maverick, so no USN [20:42] yeah, i forgot ;) [20:48] chrisccoulson: unfortunately didn't fix the issue either [23:12] chrisccoulson: is this a bad changelog: http://pastebin.ubuntu.com/483650/ [23:13] micahg - i don't think so. i've done changelogs like that before [23:13] chrisccoulson: k :) [23:13] I got my FFes :) [23:13] cool [23:14] so we get sqlite 3.7.2 in maverick hopefully [23:16] 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] chrisccoulson: so, 1.5 hrs till freeze, what's happening w/maverick and 3.6.9/bzr fixes