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