[00:00] <micahg> asac: unless we backport kmozillahelper, there's no reason to include the patches in < lucid
[00:00] <asac> chrisccoulson: right. but lets keep it apply, just make it so it doesnt change anything if qt version is lower
[00:00] <fta> btw, i suck in css, if someone is willing to improve the look, please ping me
[00:00] <micahg> chrisccoulson: I hope you mean jaunty ;)
[00:00] <asac> micahg: true, but having just one branch would be better
[00:00] <asac> my 2c
[00:00] <chrisccoulson> micahg - yeah ;)
[00:00] <micahg> asac: right, same branch, but it would only apply the patches for >= lucid
[00:00] <asac> if quilt has that feature tats fine
[00:00] <micahg> asac: like we do now with apparmor
[00:01] <asac> but if it would mean a manual patch in the rules
[00:01] <asac> that would be bad
[00:01] <asac> because then you cannot just update patches etc.
[00:05] <BUGabundo> fta: http://android.modaco.com/content/google-nexus-one-nexusone-modaco-com/309717/its-dead-new-screen-needed/
[00:05] <BUGabundo> wow
[00:05] <BUGabundo> that page crashes chromium
[00:05] <asac> chrisccoulson: i think in nsKDEUtils.h we could make a #if QT_VERSION or something that always returns false for qt < lucid
[00:05] <asac> static bool getKdeSession()
[00:05] <asac> that is
[00:05] <BUGabundo> time to debug test it
[00:06] <BUGabundo> $ chromiumdatadir="$(mktemp -d)";chromiumdiskcache="$(mktemp -d)";chromium-browser -g --user-data-dir=$chromiumdatadir --disk-cache-dir=$chromiumdiskcache' http://android.modaco.com/content/google-nexus-one-nexusone-modaco-com/309717/its-dead-new-screen-needed/
[00:06] <chrisccoulson> asac - yeah, could do. i will try and look at that tomorrow
[00:06] <asac> cool
[00:07] <asac> fta: antoher idea would be to add a bot to this channel where i can just say !buildstatus
[00:07] <asac> and it dumps the current status somehow ;)
[00:07] <asac> but dashboard is good enough i guess ;)
[00:07] <asac> we could teach the bot to return the url on some command
[00:08] <fta> asac, i already wrote it, but i wasn't sure it would be welcome, so i never plugged it here
[00:08] <asac> fta: in this channel i am sure its welcome ;)
[00:09] <fta> i will have to dig into my code repository see in what state i left it
[00:09] <fta> BUGabundo, that page loads fine here
[00:09] <asac> http://identi.ca/notice/33824116
[00:09] <asac> ;)
[00:10] <BUGabundo> fta: yeah on a clean profile does too
[00:10] <BUGabundo> guess its one of my addons
[00:10] <asac> addons crashing chromium? how many do you have? 50?
[00:10] <BUGabundo> oh come on asac
[00:10] <asac> ;)
[00:24] <chrisccoulson> ah, bugger. i was hoping to do the extension updates in hardy with the minimum of updates, but we need to do the binary package name transition (to xul-ext-*) in hardy, else upgrades break :(
[00:24] <chrisccoulson> ^^micahg
[00:24] <micahg> chrisccoulson: why?
[00:25] <micahg> chrisccoulson: all lucid packages should have xul-ext migration paths
[00:25] <chrisccoulson> micahg - the packages in lucid have conflicts/replaces to ensure the upgrade works, but they are all versioned
[00:25] <chrisccoulson> and the version numbers are too low
[00:25] <micahg> chrisccoulson: 1.1+really2.0 :)
[00:25] <chrisccoulson> so, we'd need to either SRU all the extensions in lucid to change the versioned replaces, or do the transition in hardy
[00:26] <chrisccoulson> heh, we could do that as well
[00:31] <chrisccoulson> if it wasn't for gcc, i'd probably have taken over the whole build farm by now ;)
[00:39] <asac> i would go for the transition in hardy
[00:40] <asac> hmm. actually dont do that for ubufox ;)
[00:41] <crimsun> fta: what is that pastebin for?
[00:45] <chrisccoulson> asac - would that cause an issue wit ubufox?
[00:45] <chrisccoulson> s/wit/with/
[00:46] <asac> chrisccoulson: plugins need to move their location too
[00:46] <asac> e.g. they ship in /usr/share/ubufox/plugins
[00:46] <asac> so the alternative switcher works
[00:46] <asac> not sure if any plugin dose that in hardy though (cant remember when that feature was added)
[00:46] <asac> anyway, i think plugins also need updates
[00:46] <chrisccoulson> asac - ah, i wasn't suggesting to do the whole transition we did in lucid, but just the binary package name change only
[00:47] <asac> ah ok
[00:47] <asac> that works i think ... though we need to check with mvo
[00:47] <chrisccoulson> as it stands at the moment, the conflicts/replaces in lucid aren't tight enough to handle the name transition during the hardy->lucid upgrade
[00:47] <asac> if stable updates in update-manager pull new packages
[00:47] <asac> chrisccoulson: yeah. i understand the problem. the version hack suggested by micahg also works.
[00:48] <chrisccoulson> asac - they do, i tried that in last week when i was testing the ff30.->3.6 transition
[00:48] <asac> ok cool
[00:48] <chrisccoulson> (new packages get installed by u-m)
[00:48] <asac> so we hav three ptions: a) do full transition, b) do name transtion only, c) do fake version update
[00:49] <chrisccoulson> i think i would prefer the 3rd option, but i will probably have to do the second option anyway for the extensions that are already in the PPA
[00:49] <asac> yeah maybe. however, option a) would probably the least work intesive one
[00:49] <BUGabundo> nite
[00:49] <BUGabundo> see you all tomorrow
[00:49] <asac> e.g. just throw them from lucid to hardy
[00:49] <asac> BUGabundo: night
[00:50] <chrisccoulson> yeah, we could do
[13:04] <fta> question for the python experts, i have some dates like this one u'2010-05-28T10:51:47.486204+00:00', i want to compute durations/deltas
[13:06] <fta> nxvl, ^^ ?
[13:13] <BUGabundo_remote> seems no one is expert enough
[13:14] <fta> yeah
[13:14] <fta> i need a datetime or something like that
[13:39] <fta> tricked it.. datetime.datetime.strptime(date_first_dispatched, "%Y-%m-%dT%H:%M:%S.%f+00:00")
[14:56] <chrisccoulson> bugger, we've ran out of space in the u-m-s PPA
[14:56] <chrisccoulson> ^^asac - do you think we should delete stuff or ask for more space?
[14:58] <fta> probably both
[15:20] <asac> chrisccoulson: ums? security ppa?
[15:21] <asac> chrisccoulson: whats the current max space?
[15:21] <asac> 4G?
[15:21] <asac> lets get 10 then
[15:21] <chrisccoulson> asac - it's 10G already
[15:21] <asac> hmm.
[15:21] <asac> chrisccoulson: go into #is and ask if there is a way to increase size at all
[15:21] <asac> ask bigjouls
[15:22] <chrisccoulson> ah, bigjouls doesn't seem to be in there
[15:23] <asac> chrisccoulson: wait till he is back ;)
[15:23] <asac> chrisccoulson: so sorry ... #soyuz ;)
[15:23] <chrisccoulson> on freenode or canonical?
[15:23] <asac> chrisccoulson: latter
[15:23] <chrisccoulson> heh, he's not in there either ;)
[15:34] <asac> 11.5 GiB (1.15%) of 1000.0 GiB
[15:34] <asac> nice
[15:34] <asac> lets share warez there ;)
[15:34] <BUGabundo_remote> new disk?
[15:34] <asac> no ... security ppa
[15:34] <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages
[15:35] <BUGabundo_remote> 1T
[15:35] <BUGabundo_remote> nice
[15:35] <asac> yep
[15:35] <chrisccoulson> asac - that should last me until tomorrow :P
[15:35] <asac> at least ;)
[15:35]  * chrisccoulson sees how quickly he can fill it up
[15:52] <nxvl> fta: time object
[15:52] <nxvl> fta: datetime actually
[15:52] <nxvl> fta: import datetime, then you put that in a datetime object and you can get days for example
[17:42] <chrisccoulson> come back micahg :)
[17:48] <nxvl> chrisccoulson: did you got the change to prepare the document of the firefox backport?
[17:49] <chrisccoulson> nxvl - not yet, i really need to get these packages all in to the PPA first
[17:49] <nxvl> sure
[17:49] <nxvl> let me know when you have it please
[17:49] <chrisccoulson> nxvl, rick created this page earlier: https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[17:50] <chrisccoulson> and it contains the contents of an e-mail i sent out, which has a few details in
[17:53] <nxvl> and it refers to some lists that are not there
[17:58] <chrisccoulson> nxvl - ah, rick forgot the links i put at the bottom of the e-mail
[17:58] <chrisccoulson> what's your e-mail address?
[17:58] <nxvl> that's what i assumed
[17:58] <nxvl> nicolas.valcarcel AT canonical DOT com
[17:59] <chrisccoulson> nxvl - ok, i forwarded the mail to you too
[17:59] <nxvl> thanks
[18:38] <fta> chrisccoulson, http://people.ubuntu.com/~fta/ppa-dashboard/ums.html
[19:01] <asac> fta: can you make http://people.ubuntu.com/~fta/ppa-dashboard/ list all the dashboards rather than showing the default one?
[19:01] <asac> and maybe move the current index.html to daily.html
[19:01] <asac> or somehting?
[19:02] <asac> just and idea so one can browse all the dashboards
[19:02] <fta> asac, most probably, but i'm still experimenting
[19:02] <asac> without making an overview page
[19:02] <asac> kk
[19:02] <fta> the API is weird
[19:02] <fta> and slow
[19:02] <fta> and buggy
[19:02] <asac> oh you are using API ... and dont parse html ;)
[19:02] <asac> good
[19:03] <asac> file bugs ;)
[19:03] <asac> even if only 5% get fixed its a win
[19:22] <fta> the API is not on par with the website :(
[19:31] <jdstrand> chrisccoulson: hi! so, I have that usn 935-1 was given to you for ff 3.5.10. is karmic going to get 364 or 3.5.10?
[19:31] <micahg> jdstrand: 3.5.10 ATM
[19:31] <jdstrand> chrisccoulson: ^
[19:31] <jdstrand> micahg: thanks
[19:32] <chrisccoulson> micahg - ah, you missed the discussion in #ubuntu-desktop ;)
[19:32] <micahg> jdstrand: yes
[19:32] <micahg> oops
[19:32] <micahg> chrisccoulson: yes
[19:32] <micahg> was trying to get in there
[19:32]  * micahg goes to read the backlog
[19:32] <chrisccoulson> we need to get 3.6.4 in karmic before jaunty ;)
[19:32] <chrisccoulson> that's basically the summary
[19:32] <micahg> chrisccoulson: why?
[19:32] <chrisccoulson> we still need to preserve the upgrade path through karmic
[19:32] <micahg> chrisccoulson: I know there will be upgrade issues, but that should only affect the next update
[19:33] <micahg> chrisccoulson: we should have a month to do that
[19:33] <chrisccoulson> yeah, but we can't have a month where upgrades break ;)
[19:33] <chrisccoulson> users wouldn't be very happy
[19:33] <micahg> chrisccoulson: well, ugh
[19:34] <micahg> chrisccoulson: so let's use the karmic xul rdepends for jaunty and then upgrades won't break
[19:34] <jdstrand> chrisccoulson: if karmic gets 3.6.4, please use 930-1 for it like the others
[19:34]  * jdstrand holds onto 935-1 for safekeeping for now
[19:34] <micahg> chrisccoulson: and version all the extensions for jaunty so the upgrades won't break
[19:35] <micahg> chrisccoulson: ugh, I guess if we're doing all that work we can do karmic also :(
[19:35] <micahg> chrisccoulson: ok, so what's the timeline then, hardy, then karmic the week after, then jaunty?
[19:35] <chrisccoulson> micahg - yeah, that's the plan now
[19:36] <micahg> chrisccoulson: I think we should push 3.5.10 to karmic on tuesday regardless
[19:36] <chrisccoulson> micahg - yeah, that might be what happens. it all depends on how fast we can have karmic ready ;)
[19:37] <micahg> chrisccoulson: well, my goal is to have whatever is left for hardy done by Tuesday
[19:38] <micahg> chrisccoulson: BTW, should I reversion my uploads in the transition PPA so you can copy/rebuild to security PPA?
[19:38] <chrisccoulson> micahg - yeah, can do
[19:38] <micahg> chrisccoulson: wait, as in I should ?
[19:39] <chrisccoulson> yeah, you can do that
[19:39] <micahg> chrisccoulson: k
[19:40] <micahg> chrisccoulson: will you be signed in over the weekend?  Those should be ready Sun morning
[19:40] <chrisccoulson> i will be at some point
[19:40] <micahg> chrisccoulson: k
[19:40] <micahg> chrisccoulson: so which extension plan are we using?  I saw the transcript between you and asac
[19:42] <chrisccoulson> well, i had to fix the ones i uploaded already to rename the binaries to xul-ext-* and provide the transitional package
[19:42] <jdstrand> chrisccoulson, micahg: in thinking about 3.5.10 vs 3.6.4 for karmic for a second, I have an opinion
[19:42] <micahg> chrisccoulson: so we're doing the transition in hardy?
[19:43] <micahg> chrisccoulson: won't that cause more problems with additional new binaries?
[19:43] <jdstrand> unless 3.5.9 has a critical vulnerability that doesn't exist in 3.0 or 3.6, we should just publish 3.6.4 for karmic
[19:43] <chrisccoulson> micahg - it's up to you. i had to do that for the ones i already uploaded, as i had no choice once i uploaded them
[19:43] <jdstrand> reason being, that is a lot of archive churn and disruption for karmic users
[19:43] <chrisccoulson> jdstand - yeah, i'm not sure what 3.5.10 fixes
[19:43] <micahg> jdstrand: the problem is the time between we can have all the extensions/rdepends ready for karmic
[19:44] <jdstrand> more than likely, 3.6.4 fixes whatever would be in 3.5.10 anyway, so focusing on 3.6.4 for all releases is best
[19:44] <micahg> jdstrand: I would think we can get up 3.5.10 with minimal effort to at least have a browser w/out known issues
[19:44] <micahg> jdstrand: my guess is it'll take another week to have karmic ready
[19:44] <jdstrand> micahg: yes, but only to turn around 2-3 days later with a new update
[19:44] <jdstrand> ok, 7 days
[19:44] <micahg> jdstrand: your call
[19:45] <jdstrand> normally, we release new packages for all supported releases at once
[19:45] <micahg> jdstrand: if for some reason we don't get karmic to 3.6.4 w/in a week, then what though?
[19:45] <jdstrand> I realize this isn't a normal update
[19:45] <micahg> chrisccoulson: what do you think?
[19:46] <jdstrand> I don't think I have enough info to make the call
[19:46] <chrisccoulson> i'm not sure, but 3.5.10 is ready to go anyway
[19:46] <micahg> chrisccoulson: WRT extensions, I'll do it whatever way you want
[19:46] <jdstrand> I had assumed all releases were getting 3.6.4, until a few minutes ago
[19:46] <chrisccoulson> jdstrand - i'm more concerned about what we do with 3.6.4 on tuesday when hardy, karmic and jaunty aren't all ready ;)
[19:47] <jdstrand> of course
[19:47] <jdstrand> but, it wouldn't be the first time that mozilla updates didn't go out on the day upstream released them
[19:47] <micahg> jdstrand: if we push 3.5.10 to jaunty/karmic and hardy up to 3.6.4, we'll at least have up to date browsers on all releases
[19:48] <jdstrand> so what I am hearing is that hardy and jaunty are fairly close to making it midweek next week, but karmic is not?
[19:48] <chrisccoulson> jdstrand - that was the plan, but then we realized we still need to maintain the jaunty -> karmic upgrade path
[19:48] <chrisccoulson> so we need to do karmic before jaunty (or at the same time)
[19:49] <jdstrand> well, most jaunty users are using 3.0 I'm sure, since that is in the default install
[19:49] <chrisccoulson> yeah, that's right
[19:49] <jdstrand> so upgrading it to 3.5.10 doesn't do a lot for them
[19:49] <jdstrand> so, hardy is ready for midweek next week, but 364 for jaunty and karmic is another week out?
[19:50] <chrisccoulson> jdstrand - i think that's how it's looking atm
[19:51] <jdstrand> while not optimal, since this is a very special case, I'm ok with hardy 364 going out before jaunty and karmic
[19:51] <jdstrand> (hardy+lucid)
[19:51] <micahg> chrisccoulson: jaunty is also more complicated as we should upgrade/import profiles from both 3.0 and 3.5
[19:51] <micahg> chrisccoulson: or at least ask which one
[19:51] <jdstrand> so, let's just say definitively that hardy and lucid will get the 3.6.4 update next week, and they should use 930-1
[19:52] <jdstrand> that leaves jaunty and karmic
[19:52] <jdstrand> karmic-lucid upgrade is ok
[19:52] <jdstrand> if we don't update jaunty, jaunty to karmic upgrade is ok
[19:52] <chrisccoulson> micahg - yeah, i've not tested that yet
[19:53] <chrisccoulson> jdstrand - yeah, seems sensible
[19:53] <jdstrand> so, hardy and lucid go together, and jautny and karmic go together a week later with 930-2
[19:53] <micahg> jdstrand: also if we run into regressions in hardy, I would assume the priority would be those regressions, so karmic/jaunty would get pushed back
[19:53] <jdstrand> micahg: yes
[19:53] <micahg> jdstrand: that's why I think we should push 3.5.10, just in case
[19:53] <jdstrand> with this in mind, the only real course is that jaunty 3.5 and karmic 3.5 should get 3.5.10
[19:53] <jdstrand> (after all)
[19:53] <micahg> jdstrand: :)
[19:54] <jdstrand> that leaves default jaunty 3.0 users out for a bit though, but that is about the best we can do atm
[19:54] <jdstrand> again, I didn't realize only hardy was ready for 3.6.4
[19:54] <micahg> jdstrand: can we make an annoucement that they should switch to firefox-3.5 for a week or is that too confusing?
[19:55] <micahg> jdstrand: I didn't work fast enough on this project, that's why it isn't ready
[19:55] <jdstrand> micahg: I think that would be too confusing, and quite unprecedented
[19:55] <micahg> jdstrand: k
[19:55] <jdstrand> micahg: oh, no blame at all -- I just didn't know the status and assumed we were talking about all three
[19:56] <jdstrand> it will be clear enough in the usn that jaunty didn't get an update, and our cve tracker will also reflect it. then a week or so later, we will get it out
[19:56] <chrisccoulson> micahg - ok, so i'm just going with doing the binary name transition in hardy for the extensions, it's not really much work to do that
[19:56] <jdstrand> actually...
[19:57] <chrisccoulson> and i'm not updating extensions that currently don't work either
[19:57] <micahg> chrisccoulson: k, will do WRT binary name change, what do you mean by not working?
[19:57] <chrisccoulson> we should only do what is necessar to make sure that things which currently work carry on working
[19:57] <jdstrand> no, scratch that
[19:57] <chrisccoulson> micahg - some extensions have unresolvable dependencies, or depend only on firefox 2 etc...
[19:58] <chrisccoulson> we shouldn't worry about those ones
[20:00] <micahg> chrisccoulson: k
[20:00] <jdstrand> nxvl: you probably want to read backscroll ^. basically next week hardy and lucid are getting 3.6.4, jaunty and karmic 3.5 will get 3.5.10 with 3.6.4 coming a week or so later. this means jaunty 3.0 will not be patched for roughly a week and half
[20:01] <nxvl> jdstrand: thanks for letting me know, will check the backscroll
[20:01] <micahg> chrisccoulson: anything else we need to chat about before the wekeend?
[20:02] <chrisccoulson> micahg - i don't think so. i'll be around for most of the evening anyway (although i'm going for dinner in a few minutes)
[20:02] <micahg> chrisccoulson: k, I'll be around for a few more hours, but will be running around the office
[20:30] <fta> http://blog.chromium.org/2010/05/desktop-notifications-now-available-to.html
[20:41] <micahg> fta: idk if these work with notify-osd
[20:42] <fta> i'd like something to interact between chromium and the app indicator
[20:42] <fta> (i use chromium in --app mode a lot)
[20:47] <fta> http://arstechnica.com/gadgets/news/2010/05/intel-to-hardware-accelerate-webm-if-it-becomes-popular.ars
[20:49] <fta> http://arstechnica.com/security/news/2010/05/adobe-considers-monthly-patches-to-improve-security.ars
[20:51] <jdstrand> micahg: are all the backported items for hardy in the ubuntu-mozilla-security ppa now?
[20:51] <micahg> jdstrand: not yet, we still have another 30 packages I think
[20:52] <jdstrand> micahg: ok. for my part, I won't be able to start testing til tuesday then
[20:52] <jdstrand> micahg: what is the url describing everything that is being backported?
[20:53] <micahg> jdstrand: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list has teh packages and there is a gobby doc for the extensions that we will probably move to the wiki
[20:53] <micahg> jdstrand: the table at the bottom is what we're backporting
[20:54] <jdstrand> micahg: yes, that's it. thanks!
[20:54] <micahg> jdstrand: chrisccoulson wrote up a plan as well
[20:54] <micahg> jdstrand: https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[20:55] <micahg> jdstrand: if the porting is done (I hope by Tuesday) if you want, I can help with some testing in the mornings (not sure if that's more important than the packages for jaunty/karmic)
[20:55] <jdstrand> micahg: when do you expect the call for testing email to go out?
[20:56] <jdstrand> micahg: testing is everything
[20:56] <micahg> jdstrand: I'm hoping tuesday, I'll be working Sun/Mon to finish any packaging
[20:56] <jdstrand> micahg: we can potentially identify problems that way, and incorporate fixes in the jaunty/karmic stuff
[20:57] <micahg> jdstrand: k, well, when do you expect to be on Tues morning?
[20:57] <jdstrand> micahg: hmmm.. if the call for testing goes our tuesday, then when is it hoped these will hit -security?
[20:58] <micahg> jdstrand: I hope I can find people to upload/copy&rebuild what I need to the security PPA over the weekend and hopefully < 10 packages left to build tues morning
[20:58] <jdstrand> micahg: I have monday off. Tuesday I will start at 13:00 UTC
[20:59] <micahg> jdstrand: I will make a point to be on then and hopefully will have had a chance to catch up w/ chrisccoulson by then
[20:59] <jdstrand> micahg: my plan for next week is testing of this update. I think we need all hands on deck for testing though, and not just a few of us
[21:00] <micahg> jdstrand: my only concern is I can't do testing and karmic/jaunty porting
[21:00] <jdstrand> so I'm hoping the call for testing will elicit lots of feedback (positive I hope!)
[21:01] <micahg> jdstrand: I can send a message to the bugsquad as well to help w/testing
[21:01] <jdstrand> micahg: I realize that, but the testing will ultimately help your confidence with the porting
[21:01] <jdstrand> this is a huge update and while I'll test it, I don't want to be the only one doing that
[21:02] <micahg> jdstrand: k, that's fine, I've just never done anything like this before and didn't know where the priorities are
[21:02] <jdstrand> I'm not suggesting I will be, I just think this requires a big effort
[21:02] <jdstrand> micahg: if that requires talking to your manager/etc, I understand
[21:02] <jdstrand> this is a big update on a stable LTS release
[21:03] <jdstrand> we strive for and agressively test for no regressions
[21:03] <jdstrand> we won't be able to test everything, but the more people we have, the better chance we have at finding things/demonstrating things are ok for most
[21:03] <micahg> jdstrand: it will be chrisccoulson's call then, I'll discuss with him on Tuesday
[21:03] <jdstrand> micahg: cool, thanks
[21:05] <micahg> jdstrand: you have a minute for an OT question?
[21:05] <jdstrand> micahg: in terms of support, we have a responsibility to the jaunty 3.0 users, of course. however, hardy LTS users are likely more numerous and definitely less forgiving with regressions
[21:05] <micahg> jdstrand: k, makes sense
[21:05] <jdstrand> micahg: so the biggest impact we can have is to test the crap out of hardy. that will build confidence in your work on jaunty, so it isn't wasted time either way
[21:06] <jdstrand> micahg: ok, shoot
[21:06] <micahg> jdstrand: k
[21:06] <micahg> jdstrand: do you know of a good central password repo tool?
[21:06] <jdstrand> micahg: can you explain your use case?
[21:07] <micahg> jdstrand: root password store for lots of servers
[21:07] <chrisccoulson> micahg / jdstrand - i've not read the whole scrollback yet, but if you;re talking about testing, then i'm already discussing with ara about coordinating that
[21:07] <jdstrand> chrisccoulson: that is good news
[21:08] <jdstrand> chrisccoulson: my only concern is that enough people are testing it
[21:08] <micahg> chrisccoulson: I was wondering if my time was better spent continuing porting once hardy is done or to test hardy
[21:08] <jdstrand> s/only/biggest/
[21:09] <jdstrand> micahg: re passwords> is this just for you to maintain locally or for all those servers to access?
[21:09] <chrisccoulson> micahg - your time is probably better spent porting
[21:09] <micahg> jdstrand: well, it's for a team to manage these devices
[21:09] <BUGabundo> evening
[21:09] <micahg> chrisccoulson: k
[21:10] <jdstrand> chrisccoulson: mind you, I haven't been a part of your conversation with ara, but imho the most important thing is testing
[21:11] <jdstrand> chrisccoulson: if the resources are there without micahg, then that's fine
[21:11] <jdstrand> micahg: otoh I don't have a recommendation, sorry
[21:11] <chrisccoulson> jdstrand - yeah, we haven't discussed how exactly to test it yet, but she is aware of this and is going to help out
[21:11] <chrisccoulson> tbh, the thing i'm most worried about is getting the upgrade paths right
[21:11] <micahg> jdstrand: k, was just wondering if your team had a favorite tool for this use case
[21:12] <chrisccoulson> i'm quite confident that everything will be ok functionally
[21:12] <micahg> chrisccoulson: I'm not sure about that
[21:12] <jdstrand> chrisccoulson: the upgrade paths is part of testing
[21:12] <micahg> chrisccoulson: I'm referring to the rdepends
[21:12] <jdstrand> chrisccoulson: but this is I think the largest security update ever performed within Ubuntu
[21:13] <chrisccoulson> jdstrand - yeah, i need to get it right ;)
[21:13] <jdstrand> chrisccoulson: heh
[21:13] <jdstrand> of course
[21:13] <chrisccoulson> i think i'm going to have to work on monday
[21:13] <chrisccoulson> i wonder if i can defer my vacation for a few days ;)
[21:13] <jdstrand> at the risk of stating the obvious, this is complex and high profile and most importantly, a very large number of users are going to be affected
[21:14] <micahg> chrisccoulson: s/days/weeks :)
[21:14] <chrisccoulson> ;)
[21:14] <jdstrand> on an LTS, these users are very unforgiving of regressions
[21:14] <jdstrand> (ie, enterprise users)
[21:14] <chrisccoulson> yeah, that's what worries me ;)
[21:15] <jdstrand> we need as many people doing functional testing as possible
[21:15] <jdstrand> upgrades next
[21:15] <micahg> jdstrand: we can always blame upgrades on Lucid :)
[21:15] <jdstrand> if ara can dedicate resources to that, great
[21:15] <micahg> and fix for .1
[21:15] <jdstrand> I plan to be testing this too, but 2-3 people really does not seem like enough...
[21:16] <chrisccoulson> yeah, hardy -> lucid upgrades aren't enabled yet
[21:16] <micahg> chrisccoulson: they're not
[21:16] <micahg> ?
[21:16] <jdstrand> at least not for the quick turnaround that I perceive is desired for publication
[21:16] <micahg> chrisccoulson: what upgrade path is there for hardy at this point?
[21:16] <chrisccoulson> micahg - not yet (it's not offered by u-m anyway)
[21:16] <chrisccoulson> micahg - no upgrade path is offered in u-m atm
[21:16] <chrisccoulson> although
[21:17] <chrisccoulson> it is technically still possible to upgrade to intrepid, as the archive isn't on oldreleases yet
[21:17] <micahg> chrisccoulson: ah, but they can choose it then?  is hardy -> intrepid still offered, or was that turned off in u-m?
[21:17] <chrisccoulson> i'm going to ask about moving that next week
[21:17] <jdstrand> that should be turned off
[21:17] <chrisccoulson> micahg - u-m in hardy offers no upgrades atm
[21:17] <jdstrand> if it isn't, that is a serious problem
[21:17] <micahg> chrisccoulson: ok
[21:18] <jdstrand> chrisccoulson: I asked micahg, but I'll ask you. when is the call for testing email going out (micahg said tuesday hopefully)? when do you hope for this to be published to -security?
[21:20] <chrisccoulson> jdstrand - yeah, tuesday seems like a good time (although, it will be possible to test the firefox and extension upgrades before then, hopefully)
[21:20] <chrisccoulson> i might not go to bed tonight until all the extensions are done ;)
[21:20] <micahg> chrisccoulson: yeah, I'll finish those first, so that should be Monday
[21:20] <micahg> chrisccoulson: also, we need to make sure any extensions (not addons) work as well
[21:20] <micahg> chrisccoulson: have you thought about openjdk backport yet?
[21:21] <chrisccoulson> micahg - yeah, that was in the mail i sent to ara earlier (the one pasted in to the wiki)
[21:21] <chrisccoulson> i'm not sure about openjdk
[21:21] <micahg> chrisccoulson: I'm going to try to grab the commit that built it for xul192 and add that to the hardy version and see if it works
[21:21] <chrisccoulson> cooo, thanks
[21:22] <chrisccoulson> s/cooo/cool
[21:22] <chrisccoulson> lol
[21:22] <jdstrand> please consider sun-java too -- it is very popular on hardy
[21:22] <asac> ack
[21:22] <micahg> jdstrand: I think that might already work
[21:22] <fta> http://arstechnica.com/microsoft/news/2010/05/for-some-companies-ie-6s-ineptitude-is-a-feature-not-flaw.ars
[21:23] <chrisccoulson> i will install that when i text the next round of extension updates on hardy
[21:23] <asac> chrisccoulson: get mvo involved in testing the upgrades
[21:23] <micahg> jdstrand: more than that, on hardy sun-java6 is the default java :)
[21:23] <asac> chrisccoulson: he has a good infrastrcuture to test various combinations
[21:23] <jdstrand> chrisccoulson: ok. let me be blunt. how do you see testing going? keeping in mind monday is a holiday in the US
[21:23] <chrisccoulson> jdstrand, monday is also a holiday in the UK
[21:23] <jdstrand> micahg: well, it is still multiverse, but yes
[21:23] <chrisccoulson> although, tbh, i think i will be working on monday
[21:26] <asac> chrisccoulson: the release 3.6.4 is now scheduled june 7/8 :)
[21:26] <asac> so another week ;)
[21:26] <asac> build6 is going out
[21:26] <micahg> asac: I now understand your original worries about this project :)
[21:26] <chrisccoulson> asac - that's quite a relief
[21:26] <chrisccoulson> asac - build6 is already in the PPA ;)
[21:26] <asac> heh ;)
[21:27] <micahg> asac: still June 1 on the releases page
[21:27] <jdstrand> chrisccoulson: what is the testing plan? if there is a URL, can you point me to it?
[21:27] <chrisccoulson> jdstrand - rick started a page here: https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[21:27] <jdstrand> yeah, I saw that. it is quite high level
[21:28] <chrisccoulson> but i haven't done any proper planning for testing yet (i'm still trying to get everything updated)
[21:28] <asac> chrisccoulson: micahg: jdstrand forwarded you that mail
[21:29] <chrisccoulson> asac - thanks
[21:29] <micahg> asac: k, thanks
[21:29] <chrisccoulson> asac - is that a list that anyone can subscribe to?
[21:29]  * jdstrand feels like he isn't getting through...
[21:30] <micahg> chrisccoulson: that's the sec list for Ubuntu
[21:30] <micahg> chrisccoulson: oops, mozilla
[21:30] <asac> chrisccoulson: no. but we should get you subscribed to announce
[21:30] <asac> i think its invite only ... could be that it changed
[21:30] <chrisccoulson> asac - yeah, would be useful ;)
[21:31] <micahg> asac: not on their lists page
[21:31] <asac> yeah its invite only
[21:31] <chrisccoulson> jdstrand - so, mvo has offered to help out with upgrade tests
[21:32] <chrisccoulson> (in #ubuntu-desktop a few moments ago)
[21:32] <micahg> chrisccoulson: I think jdstrand is saying we should have a full test plan ready when the call goes out to maximize testing
[21:32] <jdstrand> chrisccoulson: I appreciate your continued work in getting the update ready to test. I also appreciate that you know this is a big update that needs testing and you are willing to do it. in the past, testing has largely fallen on the mozilla maintainer and myself. I am extremely concerned that more resources than 2-3 people have not been allocated for testing this huge update
[21:33] <jdstrand> many users could be affected. the reputation of Ubuntu's LTS is at stake
[21:33] <jdstrand> and not least of which (to me), my name will be on the USN
[21:33] <chrisccoulson> jdstrand - that's why ara is involved too. she's going to get people involved with testing as well
[21:34] <jdstrand> chrisccoulson: where is the conversation with ara taking place?
[21:35] <jdstrand> chrisccoulson: I may be worrying simply because I haven't been part of the testing conversation...
[21:35] <chrisccoulson> jdstrand - via e-mail at the moment, although there's not much in the way of details. that's something i need to start pushing along next week though
[21:35] <chrisccoulson> i'll make sure you're involved with that
[21:35] <jdstrand> chrisccoulson: ok. I very much appreciate it
[21:36] <micahg> chrisccoulson: now that we have another week, what's the plan?
[21:36] <jdstrand> chrisccoulson: please CC security@ubuntu.com so our whole team can know what is happening (in the case of regressions, any one of us may need to respond)
[21:36] <chrisccoulson> jdstrand - ok, will do
[21:36] <micahg> chrisccoulson: also, can you CC me on the test stuff also, please
[21:36] <chrisccoulson> micahg - the plan is the same (get hardy ready, then work on karmic and jaunty)
[21:37] <chrisccoulson> giving priority to getting extensions updated too
[21:37] <jdstrand> chrisccoulson: again, I apologize if I am being a pain :) I want what we all want: a smoothe update
[21:37] <micahg> chrisccoulson: k, the thing is that extensions compile against xul, so that's a possible issue as well
[21:37] <chrisccoulson> jdstrand - no worries ;)
[21:38] <jdstrand> I just happen to know what regressions in stable releases feel like, and it is no fun.... avoiding them is *way* better ;)
[21:38] <chrisccoulson> i feel your pain - i expect i probably won't sleep much between now and roll-out ;)
[21:38] <jdstrand> chrisccoulson: through testing comes confidence
[21:38] <asac> chrisccoulson: jdstrand: send a mail to Dan asking you to be added to security-announce ... if you dont get added by mid next week let me know
[21:38] <chrisccoulson> asac - thanks
[21:39] <jdstrand> if we can be confident that the vast majority of users will have a smooth upgrade, that is a very good thing
[21:39] <chrisccoulson> jdstrand - if you want, then you can already start testing hardy
[21:39] <jdstrand> chrisccoulson: well, that is how this conversation started
[21:39] <chrisccoulson> (firefox and xulrunner are in the PPA, along with ubufox and some other extensions)
[21:39] <chrisccoulson> but not everything is there yet
[21:39] <jdstrand> chrisccoulson: I was told some 30 things needed to be uploaded still
[21:39] <jdstrand> ok
[21:40] <chrisccoulson> jdstrand - yeah, that's right. but the major thing is updated already :)
[21:41] <micahg> chrisccoulson: firefox is less likely to break in Hardy than the rdepends/extensions(plugins)
[21:41] <jdstrand> that may be, but we need to test it all :)
[21:41] <micahg> jdstrand: of course
[21:41]  * jdstrand goes to download
[21:45] <chrisccoulson> are powerpc and hppa officially supported on hardy?
[21:46] <chrisccoulson> oh, that's not too bad. webkit only fails to build on those arch's because the symbols files need updating
[21:48] <micahg> chrisccoulson: according to https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Official%20Architectures the answer is no
[21:48] <chrisccoulson> micahg - thanks. it doesn't matter too much, as it looks like the webkit build failure is a trivial issue anyway
[21:48] <micahg> chrisccoulson: it'll matter is the rdepends FTBFS though :)
[21:49] <chrisccoulson> right, i can't build libproxy, enable the gnome component in libsoup and build epiphany until webkit has built ;)
[21:49] <micahg> chrisccoulson: I mean the xul rdepends :)
[21:50] <chrisccoulson> ah
[21:50] <jdstrand> fwiw, imo if it didn't build before don't worry about it. if say, epiphany did build on powerpc and doesn't because say webkit doesn't build, that is a problem
[21:50] <jdstrand> s/and doesn't/and doesn't now/
[22:01] <asac> jdstrand: chrisccoulson: you got mail?
[22:02] <chrisccoulson> asac - not yet
[22:02] <chrisccoulson> asac - oh, actually, i did ;)
[22:02] <chrisccoulson> my mail filter moved it in to my mozilla mailing list folder ;)
[22:03] <chrisccoulson> i probably should have checked there first
[22:03] <asac> cool
[22:05] <fta> is it clear enough? http://paste.ubuntu.com/441058/
[22:05] <fta> ..that it will be wiped out at the end of the session
[22:09] <BUGabundo> asac: https://edge.launchpad.net/~network-manager/+archive/trunk you lazy arse :)
[22:11] <fta> ?
[22:13] <asac> BUGabundo: please ping cyphermox
[22:13] <asac> that should have been set free already
[22:14] <asac> fta: what is the temp provile for?
[22:14] <asac> fta: i would say: "--temp-profile"
[22:15] <fta> asac, debugging, testing stuff with a fresh profile, ..
[22:15] <fta> i wanted to express the idea that it will be removed
[22:15] <asac> right. but temp implies that better imo
[22:15] <BUGabundo> asac: so you basicly don't do any more work anymore? just delegate ? :D
[22:16] <asac> BUGabundo: i want to give others a chance to step up ..
[22:16] <BUGabundo> okay
[22:20] <fta> asac, http://paste.ubuntu.com/441065/ ?
[22:21] <asac> not sure if clean is the right word ... maybe "Start with a new and temporary profile"
[22:21] <asac> i think clean is just computer slang
[22:21] <asac> or "Start with an empty and temporary profile"
[22:22] <asac> but in the end it doesnt matter much
[22:22] <asac> i think typical use is: BUGabundo complains that everything crashes; you say: try with --temp-profile ;)
[22:22] <BUGabundo> yep
[22:23] <BUGabundo> and it works
[22:23] <asac> oh ... you already tested. nice.
[22:25] <BUGabundo> asac: alias chromiumnew='chromiumdatadir="$(mktemp -d)";chromiumdiskcache="$(mktemp -d)";chromium-browser --user-data-dir=$chromiumdatadir --disk-cache-dir=$chromiumdiskcache'
[22:26] <fta> will be unnecessary tomorrow
[22:27] <BUGabundo> don't care
[22:27] <BUGabundo> wfm
[22:27] <BUGabundo> :)
[22:28] <BUGabundo> and 'should' always work , with any version of chromium or chrome in pretty much any OS
[22:28] <fta> i like jdstrand's idea too: http://penguindroppings.wordpress.com/2010/05/17/browser-profiles-in-chromium/
[22:31] <asac> yeah ... multi profile is good
[22:31] <asac> but its perceived as too power userish ;)
[22:32] <fta> most users won't even notice, users never read man pages
[22:35] <asac> right. and for firefox its just legacy afik ... they officially dont support multiple profiles
[22:40] <BUGabundo> they aren't??
[22:40] <BUGabundo> that's a major loss
[22:45] <chrisccoulson> bah, we have far too many extensions in the archive ;)
[23:06] <asac> chrisccoulson: right. thats what i meant
[23:11] <fta> oh my, the new ffmpeg killed mplayer
[23:11] <fta> mplayer: relocation error: mplayer: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference