[08:27] <micahg> asac: can you look at bug 462150
[08:32] <micahg> asac: FTBFS for daily merge proposed
[08:33] <micahg> asac: I'm going to sleep, talk to you in the morning
[08:33] <micahg> asac: also did the flash thing and assigned to you
[09:23] <asac> k
[13:04] <gnomefreak> kenvandine: asac are either of you seeing that gwibber-demaon is not shut down after gwibber has been closed?
[13:52] <asac> jdstrand: USN ... xul ffox 1.9/3.0 + 1.9.1/3.5
[13:57] <jdstrand> asac: 853-1
[13:57] <jdstrand> asac: can you ping me when the builds are done so I can get to testing them as soon as possible?
[13:58] <asac> jdstrand: yes. that USN for _all_ =?
[13:58] <asac> or different USN for 3.5 vs. 3.0?
[14:06] <jdstrand> asac: are they affected in the same way? or are 3.5 and 3.0 quite different, like how 2 and 3.0 were
[14:06] <jdstrand> if it is one or 2 CVEs difference, let's use 853-1
[14:06] <jdstrand> (or even more depending on how many are different)
[14:07] <jdstrand> let's go with 'if less than half of the CVEs affect one compared to the other, use 2 USNs'
[14:09] <asac> jdstrand: i havent checked in depth for this update yet. i think its safe to assume that 3.5 and 3.0 address overlapping, but not-identical issues
[14:09] <asac> i can use 853-2 ... as we did in the past?
[14:09] <jdstrand> asac: we do things like 'This issue only affected Ubuntu 9.10' all the time
[14:10] <jdstrand> asac: the bottom line, is that ultimately, it is Firefox, just a different version. if they are mostly the same, we should use one USN
[14:10] <asac> i would prefer to have a straight line which we follow for all releases, instead of always checking of there is enough overlap
[14:10] <jdstrand> asac: but yeah, if you need a second, use 853-2
[14:11] <jdstrand> asac: I think the 50% rule is good
[14:11] <asac> 50% rule?
[14:11] <jdstrand> 09:08 < jdstrand> let's go with 'if less than half of the CVEs affect one  compared to the other, use 2 USNs'
[14:11] <asac> that means we always have to check for each release
[14:11] <jdstrand> asac: well, someone has to
[14:11] <asac> either we say we always use the same or we always use a different ,)
[14:11] <jdstrand> that is yet another exception for firefox
[14:11] <asac> of course if htere is a firedrill for just 3.5
[14:11] <asac> etc.
[14:12] <asac> i can use the same and let you untangle that
[14:12] <asac> during documentation
[14:12] <jdstrand> if you prefer, we can always use one
[14:12] <asac> kk
[14:14] <jdstrand> asac: btw, what happened with adobe-flashplugin?
[14:14] <jdstrand> asac: is whatever bug that caused the issue fixed?
[14:17] <asac> let me check this
[14:21] <asac> jdstrand: i have no idea where to get the last thing
[14:21] <asac> i mean the broken deb
[14:21] <asac> so i can verify that i hit the regression
[14:22] <asac> grrr ... why did someone remove that at all without talking to me  before
[14:22] <asac> i was poking brian for quite some time etc.
[14:22] <jdstrand> asac: let me see if I can scrounge it up
[14:22] <asac> jdstrand: where can i get the new binaries?
[14:22] <asac> ok got them
[14:22] <asac> let me test that at least
[14:22] <jdstrand> https://launchpad.net/ubuntu/karmic/+queue
[14:22] <asac> with just dpkg -i
[14:26] <asac> jdstrand: ok ... i think the prerm failed-upgrade should get a || true in the update-alternatives line :(
[14:27] <asac> do you agree?
[14:28] <asac> i couldnt trigger the bug here though ...
[14:28] <asac> its definitly better than before ... but think || true would be helpful to prevent bustage in other corner cases
[14:29] <jdstrand> I'll have to look, but have no idea what the original problem was. I am only involved because iamfuzz pinged me to deNEW it
[14:30] <asac> jdstrand: well. it update-alternative bustage ... --remove-all ... etc.
[14:39] <jdstrand> asac: hmm-- I looked at it and tbh I don't think I can give a good opinion. my update-alternatives experience is low
[14:40] <jdstrand> asac: though, an || true certainly wouldn't hurt
[14:40] <asac> i think we have to guard the --remove in faild-upgrade with || true
[14:41] <jdstrand> asac: would you mind responding to the email to iamfuzz I CC'd you one with your opinion?
[14:41] <asac> i am not sure if i am allowed to
[14:41] <jdstrand> s/one/on/
[14:41] <asac> subject?
[14:41] <jdstrand> Subject: Re: [ubuntu/karmic] adobe-flashplugin 10.0.32.18-1karmic2 (New)
[14:42] <jdstrand> allowed to?
[16:27] <asac> darn. failed to merge micah rebase
[16:27] <asac> fta2: can you or want me to add him to the team?
[16:32] <fta2> asac, done
[16:33] <asac> rock!
[16:43] <asac> ok after some poking i think that all security update builds are now building ... in ppa
[17:05] <asac> jdstrand: so one other issue on our plate ... not directly related to security, but still needs to go to security imo ...
[17:05] <asac> jdstrand: for bug 235135 there was a bogus upload to hardy-backports with a backout
[17:06] <asac> jdstrand: check out the hardy versions ... so the problem is that now hardy-backports users dont get a good flash because we didnt update the -backports package etc.
[17:06] <asac> and i would prefer to not needed to push updates the -backports for each and every update
[17:06] <asac> so the idea is to bump the -security/-updates package version to the same hacky schemed used in -backports
[17:06] <asac> meaning: our -security/-updates packages will be higher version and then we dont need to bump -backports all the time
[17:07] <asac> so ... that would require update through -proposed -> -updates -> security
[17:07] <asac> micahg prepared a debdiff once we say that thats the rigth way forward
[17:08] <eagles0513875> oh my
[17:08] <eagles0513875> just realized karmic is due out tomorrow lol
[17:08] <asac> micahg: do we have an explicit regression bug for that thing? if so, i would think we should open one instead of using the original bug with loads of comments
[17:08] <asac> yes
[17:08] <micahg> yes, I attached the debdiff to it :)
[17:08] <asac> http://identi.ca/notice/13143533
[17:08] <asac> micahg: what bug id?
[17:09] <micahg> bug 461773
[17:09] <asac> thx
[17:10] <asac> micahg: so we added you to the team ;)
[17:10] <micahg> thank you asac fta :)
[17:10] <asac> basically meaning. that you can push to branches and destroy everything ;)
[17:10] <micahg> asac: I'll wait for you to walk me through the first push to branch :)
[17:11] <asac> micahg: i would think for simple rebases on the .head you are quite well set ... if you change other stuff, just let us know up front so we can take a quick look until you gain more confidence/experience
[17:11] <asac> micahg: sure. you can start with the merge proposal you did yesterday
[17:11]  * asac tries to dig that up
[17:11] <micahg> ok, so basically, I just branch, make the fixes and push?
[17:11] <asac> yes
[17:11] <asac> same as if you push to your own branch
[17:12]  * micahg has never actually pushed on top of his own branch yet
[17:12] <asac> micahg: try that a few times maybe ;)
[17:12] <asac> micahg: what branch did you propose ?
[17:12] <micahg> https://code.edge.launchpad.net/~micahg/firefox/firefox-3.7-20091027
[17:13] <asac> micahg: that merge updates a patch together with a build dep
[17:13] <asac> thats not good
[17:13] <asac> ;)
[17:14] <asac> that needs to be two commits
[17:14] <asac> actually i would suggest three commits:
[17:14] <asac> 1. new snapshot
[17:14] <asac> 2. rebase patch
[17:14] <asac> 3. adjust build depends
[17:14] <micahg> ok, I'm only off by one :)
[17:14] <asac> yeah
[17:14] <micahg> so, I uncommit, commit the rebase, and commit the build-dep
[17:14] <asac> micahg: so why do we need mesa?
[17:14] <asac> is that really an issue?
[17:15] <micahg> the build asked for it
[17:15] <micahg> it errrored after the rebase
[17:15] <fta2> webgl
[17:15] <asac> thx
[17:15] <micahg> ah yes
[17:15] <micahg> I guess I should put that it
[17:15] <asac> so do we need full mesa-common-dev?
[17:15] <asac> maybe we just need one of the depends of it?
[17:15] <micahg> and the bmo number as well
[17:15] <micahg> that's what it asked for
[17:15] <asac> maybe check what configure.in checks ... e.g. what .pc file et al
[17:16] <asac> yes. bmo number would be a plus
[17:16] <micahg> It's one of hte bugs I'm signed up for
[17:16] <asac> like: "add mesa-common-dev to build-depends after landing of "feature x" aka bmo:xxxxx
[17:16] <asac> if thats really needed
[17:16] <micahg> http://launchpadlibrarian.net/34515609/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20091027r34228%2Bnobinonly-0ubuntu1~karmic~ppa2_FAILEDTOBUILD.txt.gz
[17:17] <asac> yes. but important to double check even if upstream prints that
[17:18] <asac> but yeah seems to be right
[17:18] <asac> mesa-common-dev contains that glx.h
[17:18] <asac> so split that commit in two
[17:18] <micahg> ok
[17:18] <asac> why did you need to rebase the other patch?
[17:18] <asac> that seems to not fail in the build
[17:19] <micahg> it was the build before that
[17:19] <asac> micahg: use a comment like i suggested above: "add mesa-common-dev to build-depends after landing of "feature x" aka bmo:xxxxx"
[17:19] <asac> ok
[17:19] <micahg> it failed in the daily build
[17:19] <micahg> I fixed it and this came up
[17:19] <asac> yeah
[17:19] <asac> ok
[17:19] <asac> all good then
[17:19] <micahg> after I fix the commits, is there a command I can use besides push --overwrite?
[17:19] <asac> micahg: push to a new location
[17:20] <asac> please dont push --overwrite to any ~mozillateam branch ;)
[17:20] <micahg> no, to my branch
[17:20] <asac> for that --overwrite is ok. or a new branch and marking the other abandoned
[17:20] <micahg> but if you uncommit, that's the only recourse?
[17:20] <asac> yes
[17:20] <micahg> ok
[17:20] <micahg> good to know
[17:20]  * asac gets reminded that we should cnofigure mozillateam branches as append_only
[17:21] <asac> micahg: also for ~mozillateam branches ... if you get a diverge ... dont merge from mozillateam branch and push
[17:21] <asac> rather branch mozillateam branch ... and merge your changes into it
[17:21] <asac> otherwise you will move backwards with bzr revisions
[17:21] <asac> its a messy bzr feature ;)
[17:21] <asac> that you can flip merge push
[17:22] <asac> but should be fixed once we have append_only set afai was told
[17:22] <micahg> merge as in locally or in LP?
[17:22] <asac> no ... if you commit something locally ... now i or fta commit something to mozillateam
[17:22] <asac> and then you want to push bzr will tell you that you diverged
[17:22] <asac> and suggests you to merge from the mozillateam branch
[17:23] <asac> but dont do that ;)
[17:23] <asac> rather branch a fresh copy from mozillateam
[17:23] <asac> and merge your local branch on top of that
[17:23] <asac> before pushing
[17:23] <micahg> ok
[17:23] <asac> but in case you get a diverge when pushing, just ask
[17:23] <asac> so you are sure :)
[17:23] <micahg> I always pull a fresh copy before I start working ;)
[17:23] <asac> just remember that in that case bzr might suggest you something bad ;)
[17:24] <asac> micahg: yes. still there could be something happening in between ;)
[17:24] <asac> you never know
[17:24] <asac> at some point there will be a diverge i am sure ;)
[17:24] <micahg> do you want mozilla bug 516213 which is the master or mozilla bug 517566 which added the test?
[17:24] <micahg> indeed
[17:24] <asac> yeah ... use the configure test addition
[17:24] <asac> or both
[17:25] <micahg> ok
[17:25] <micahg> BTW, the rest of the week, I probably won't be able to do much, but I'll start up again sat night
[17:26] <micahg> I need to finish a project for work
[17:26] <asac> thx for the info
[17:26] <asac> no problem
[17:26] <micahg> but I'll see about pushing up this fix
[17:26] <asac> yes, please do that ;)
[17:30] <micahg> asac: how does this look
[17:30] <micahg> https://code.edge.launchpad.net/~micahg/firefox/firefox-3.7-20091027
[17:36] <asac> micahg: the commit logs look ok ;) ... cant see the revisions because launchpad dislikes me
[17:36] <asac> but i assume its the right thing. so go ahead and push
[17:37] <micahg> can I merge in LP?
[17:37] <micahg> hmm
[17:37] <micahg> apparently LP doesn't like me either right now ;)
[17:37] <asac> no
[17:37] <asac> you cannot merge there
[17:37] <asac> you can make a merge request and push directlky
[17:37] <asac> but i would rather push directly now
[17:37] <asac> to mozillateam
[17:37] <asac> and just mark your branch abandoned
[17:44] <asac> micahg: does xulrunner need the same fix?
[17:51] <micahg> ok, seems like not...
[17:51] <micahg> idk why
[17:51] <asac> jdstrand: so all but ffox 3.5/1.9.1 for jaunty should be available for our supported archs
[17:51] <micahg> I have to head into the offic enow
[17:51] <jdstrand> asac: cool, thanks
[17:51] <asac> micahg: interesting ... we should remember to check that
[17:51] <micahg> I'll be back on in about 40 minutes
[17:52] <asac> jdstrand: so i will be out and do serious poking tomorrow. but that shouldnt stop you from testing now if that better suites your schedule
[17:52] <jdstrand> asac: yeah, I hope to, but we'll see how the day goes. I appreciate it :)
[17:53] <asac> i386/adm64 are currently building for the universe ffox 3.5/1.9.1 pair too
[17:53] <asac> so wil be there in a few
[18:22]  * asac out for the evening
[18:50] <micahg> jdstrand: should I fix my debdiff for the flash-hady fix to target hardy-security?
[18:50] <jdstrand> micahg: bug #?
[18:50] <micahg> bug 461773
[18:51] <jdstrand> micahg: yes, please use hardy-security
[18:52] <jdstrand> micahg: when you upload your debdiff, please mark it 'In Progress' based on https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Preparing%20an%20update
[18:52] <jdstrand> err
[18:53] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Submission
[18:53] <micahg> should I remove the assignee?
[18:54] <jdstrand> micahg: use whatever is appropriate
[18:54] <jdstrand> micahg: we have scripts that alert us to security bugs with patches marked In Progress
[18:54] <micahg> I assume high status is appropriate
[18:54] <jdstrand> that's fine
[18:58] <micahg> jdstrand: done
[19:02] <jdstrand> micahg: thanks!
[20:08] <micahg> asac: you around?
[20:39] <jdstrand> asac: can you review https://code.launchpad.net/~jdstrand/firefox/firefox-452591+455792+447006/+merge/14109 ?
[20:40] <jdstrand> asac: not super time-critical, but I'd like it to be in there for whever the next SRU is
[20:40] <jdstrand> asac: I'll do SRU text for the bugs (but not today)
[21:00] <micahg> jdstrand: 3.5.4 was a;ready committed, so you might want to fix
[21:01] <micahg> oh, nevermind
[21:01] <micahg> I guess he didn't do that...
[21:01] <jdstrand> micahg: well, it's only the packaging (debian/) and he always has to munge the changelog anyway
[21:01] <jdstrand> but yeah, it wasn't committed yet
[21:02] <micahg> I guess he was in a rush
[21:05] <BUGabundo> night o/
[21:15] <micahg> fta: you around?
[21:15] <fta> yes
[21:16] <micahg> ok, if I'm commiting a "new version upstream change", is the version number the only thing that should change in the changelog, or can I have all the changelog changes in there for my updates?
[21:17] <micahg> ugh, I guess it's a silly question
[21:17] <micahg> I'll just move the changes one at a time
[21:18] <BUGabundo> fta: did you manage to control the snapshot sizes?
[21:18] <fta> micahg, i didn't get your question (the 2nd part) but if you figured it out, fine
[21:18] <fta> BUGabundo, yes
[21:19] <BUGabundo> fta: how?
[21:19] <micahg> fta: is there a command to use the same commit message from a merge?
[21:22] <fta> BUGabundo, 'discard snapshot'. it's a confusing name but what it does is what i wanted, drop an intermediate snapshot that was no longer needed
[21:23] <fta> micahg, why do you want the same commit log? just say it's a merge for some branch & revid
[21:23] <BUGabundo> cool
[21:23] <BUGabundo> fta: well want more confusion?
[21:23] <BUGabundo> bridge doesn't allow access from the own pc :)
[21:23] <micahg> I'm locally merging in my changes from the branch I made
[21:24] <micahg> I want to have the proper commit log in the firefox branch
[21:24] <fta> micahg, just pull them
[21:24] <fta> no need to merge unless someone else put something on top
[21:24] <fta> pull or push (depending on where you are)
[21:25] <dtchen> asac: ff 3.5.4+nobinonly-0ubuntu0.9.10.1 and xul 1.9.1.4+nobinonly-0ubuntu0.9.10.1 look good from my testing (existing profile in 3.5, new profile in 3.5, migrated profile from 3.0)
[21:25] <fta> BUGabundo, i can't communicate between host and guest with shared folders :( i have to sftp my stuff in and out
[21:26] <fta> no idea why, it just doesn't work as documented
[21:26] <BUGabundo> fta: that's very strange!
[21:26] <BUGabundo> is tehre any report on it ?
[21:26] <BUGabundo> tried by ip ?
[21:26] <fta> not sure where to look
[21:26] <fta> yep
[21:27] <BUGabundo> I had a few troubles with it too
[21:27] <BUGabundo> only works if I launch from RUN
[21:27] <BUGabundo> not by icon or network browsing
[21:28] <micahg> fta: does the branch nick matter?
[21:29] <fta> micahg, no, it's local
[21:29] <micahg> ok
[21:29] <micahg> I think I'm ready to push up the changes to ff3.7.head
[21:29] <fta> but we use to name our local branches like on lp
[21:30] <fta> to avoid confusion
[21:30] <micahg> well, I made a temp branch to do the ff changes
[21:30] <micahg> from now on, I'll just use the lp name
[21:30] <micahg> it's just bzr push, right?
[21:31] <fta> depends
[21:31] <micahg> I did a bzr pull on my temp branch and it pulled in the 3 revisions I added
[21:31] <fta> bzr info should show you the default push & pull locations. if it's not lp, you have to specify it
[21:31] <fta> then you can also add --remember for later
[21:32] <micahg> pulling changed the submit branch
[21:33] <micahg> so, bzr push lp:~mozillateam/firefox/firefox-3.7.head/ ?
[21:33] <fta> yep
[21:34]  * micahg hopes it works :)
[21:36] <micahg> fta: https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.7.head, looks ok, right?
[21:37] <micahg> do you want to respin the ff3.7 daily?
[22:20] <fta> micahg, done
[22:30] <yoasif> micahg, any news on the nvidia + firefox bug?
[23:18] <micahg> yoasif: no, probably not until sat night