=== micahg1 is now known as micahg [01:22] asac. what's the best way to find when and how a change landed in the 1.9.2 branch? [01:23] hg blame your/file [01:23] or http://mxr.mozilla.org/mozilla1.9.2/ [01:24] fta: what do I need to look for in the .rej file? [01:25] micahg, it's the part of the original patch that was rejected and that you need to re-add, or drop if it's no longer needed [01:25] well, I'm looking at the file and I can't see what's wrong [01:26] often, it's just that the context of the patch changed, so just re-add the changes manually, and quilt refresh afterwards [01:28] fta: would whitespace mess up a patch? [01:28] yes, everything different will [01:28] fta, this is so frustrating. i know that a trough-border issue was resolved between firefox 3.5.4 and 3.6a1 [01:28] but i can't drill it down any further [01:29] LLStarks: those releases are not contiguous [01:29] i know [01:29] but between those branchings [01:30] would it be mozilla-central or mozilla-1.9.2? [01:32] 3.6a1 would be mozilla-1.9.2 [01:32] mozilla-central is 3.7 [01:32] well, if the fixed behavior is present in both, where did it originate? [01:33] in both what/ [01:34] the bug is fixed in both [01:35] yet i can't find the commit that fixed the bug [01:39] well [01:39] it depends when it was fixed [01:39] if it was after the branch, it landed in 3.7 first [01:39] before they were the same [01:39] in mxr.mozilla.org, you can search for files and then see who committed what revision [01:41] it's fixed in 3.6a1 [01:41] i'm not sure how much earlier though [01:44] LLStarks: maybe search bugzilla for the bug and see the changeset [01:45] my bug is the only relevant one [01:45] why are you looking for it? [01:45] to have the fix backported for karmic [01:46] the art team wants it [01:46] do you have the bug number for bugzilla? [01:46] https://bugzilla.mozilla.org/show_bug.cgi?id=500368 [01:46] Mozilla bug 500368 in Widget: Gtk "non-zero GtkRange::trough-border value produces strange boxes in Firefox/Xulrunner" [Normal,Unconfirmed] [01:46] thats definitly not the bug [01:47] that was fixed upstream ;) [01:47] i know [01:47] i'm looking for the commit [01:47] i am sure you wont find it that easily ;) [01:47] there are probably 2k commits or something ;) [01:47] what's with the wink [01:47] you need to find the bug :) [01:47] you did it, didn't you? [01:47] i did it? [01:48] i know the bug was elevated [01:48] asac: http://bazaar.launchpad.net/~micahg/firefox/firefox-3.7.head/revision/459 [01:48] but i lack the technical knowhof to find it [01:48] i remember that we did something ... yes. [01:48] * micahg finally go tit [01:48] but i have no clue ;) [01:48] oops :) [01:48] got it [01:49] that's the nsGnome patch [01:49] wait, is that it? [01:49] LLStarks: something else for the umd builds [01:49] https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=trough&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=EXPIRED&resolution=MOVED&resol [01:49] thats a search for trough with all closed bugs ;) [01:50] but i dont see it in there ;) [01:50] asac: should I propose a merge? [01:50] could someone have fixed it without even knowing it? [01:51] LLStarks: sure [01:51] btw asac, the bug i filed was previously and erroneous marked as worksforme by brosnan [01:52] micahg: is the patch done? [01:52] and working? ;) [01:53] asac: the first part [01:53] I fixed the gnome fix, now on to the missing dir [01:54] micahg, if it was a blind, blanket fix done as part of the evolution of the gtk widget in firefox, would it even be documented in a mailing list or public sphere? [01:54] LLStarks: you know ... all is in hg [01:54] and bugzilla [01:54] thts all [01:54] check the commits to [01:54] LLStarks: without a bug or a changeset, you have no idea if it was a side benefit of another patch or explicitely [01:54] /widget/src/gtk2/gtk2drawing.c [01:54] fixed [01:55] /widget/src/gtk2/nsNativeThemeGTK.cpp [01:55] with some luck those files have not been touched so often ;) [01:55] i know, i've been looking at changes over the past year [01:55] i don't know enough c to parse the files [01:55] asac: does mxr deal with missing files? [01:56] summary: Bug 501104. Handle GTK2 default button borders properly. r+sr=roc [01:57] Error: Launchpad bug 501104 could not be found [01:57] LLStarks: ^^ [01:57] LLStarks: i dont look at code [01:57] just at the changes [01:57] mozilla bug Bug 501104 [01:57] Error: Launchpad bug 501104 could not be found [01:57] mozilla Bug 501104 [01:57] Mozilla bug 501104 in Widget: Gtk "Our handling of default button borders doesn't match GTK" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=501104 [01:57] bingo [01:58] does the canonical agreement with mozilla allow small backports? [01:58] from future releases? [01:58] no [01:58] we need to get it landed upstream [01:59] if its too risky for them its too risky for us ;) [01:59] which is quite a sensible line ;) [01:59] LLStarks: but thats just button borders [01:59] i dont think thats your bug [01:59] i know [01:59] trough-borders [01:59] scrollbars and the like [02:01] brb [02:04] asac, I think I found the bug for the other one upstream [02:13] asac: mozilla bug 511642 is breaking 3.6 [02:13] Mozilla bug 511642 in Build Config "use a single packaging manifest across all three platforms (with preprocessing)" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=511642 [02:13] and 3.7 [02:15] yeah [02:15] so they unified the list [02:15] so we need to adjust our patch to patch the new file [02:15] browser/installer/package-manifest.in [02:15] yep [02:16] working on it now [02:16] did you manage to get first patch done? [02:16] want to show me? [02:16] yep [02:16] just the patch i mean ;) [02:16] and maybe an interdiff [02:16] https://code.edge.launchpad.net/~micahg/firefox/firefox-3.7.head [02:16] of the previous to the new patch [02:16] micahg: please use topic names ;) [02:16] ?? [02:16] you now took the same branch name as our branch [02:17] this means you cannot keep it after we merged it [02:17] well you can keep it [02:17] ok [02:17] but you cannot reuse the same name [02:17] use topic name [02:17] well [02:17] topic names [02:17] like firefox-3.7.head.daily-patch-rebase-DATE [02:17] what should I have used for this ff3.7.head.umd20090910 [02:17] or something else innovative [02:17] yes for instance [02:17] ok [02:17] well [02:17] I can push up a new branch [02:17] you can rename the branch even in launchpad ;) [02:18] doesnt matter. just wanted to explain the problem with not using topic branches ;) [02:18] ok [02:18] done [02:18] so launchpad code is completely broken [02:18] new url please ;) [02:18] i cannot look at the diff anymore now ;) [02:19] ah ok [02:19] no [02:19] ;) [02:19] found it [02:19] you used my name ;) [02:19] hmm [02:20] ok so that patch was just rebased ... no changes needed? [02:20] update debian/patches/lp185622_system_path_default_browser.patc [02:20] forgot the "h" at the end [02:20] but no need to fix that ;) [02:20] I only removed lines [02:20] yes [02:21] ok [02:21] push the new one ;) [02:21] working on it... [02:21] k [02:21] I refreshed the first patch [02:21] the second one is giving me issues [02:21] let me try again [02:21] Update lp185622_system_path_default_browser.patch to remove libgnomevfs (Mozilla Bug 294375) [02:21] i usually just say: [02:21] Mozilla bug 294375 in File Handling "libgnomevfs-WARNING **: Deprecated function. User modifications to the MIME database are no longer supported." [Minor,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=294375 [02:21] * adjust patches to new upstream code base [02:21] - update patch1 [02:21] - update patch2 [02:22] and do those in one commit unless some patch needs more love [02:22] ok [02:22] but the new patch needs more love [02:22] I thoguht you said to do one fix per patch [02:22] because they refactored stuff [02:22] micahg: for me "* adjust/rebase patches to new upstream code base" is one fix ;) [02:22] ok [02:22] well [02:22] because all together fix the build [02:22] ;) [02:23] if there is a bug or a more complicated rebase [02:23] I can fix and then repush [02:23] no its ok [02:23] well [02:23] maybe use the adjust syntax ;) [02:23] no need to do all in one patch [02:24] but i dont mind if its not in changelog as long as its clear that this adjusts/rebases a patch [02:24] asac: I'm still learning the lingo [02:25] sure. your comment reads too "complicated" ;) [02:25] I thought it was removing gnomevfs from the patch, but it was really rebasing since we didn't make any changes with gnomevfs [02:25] i would think ... oh it was serious work needed ;) [02:25] even though it just shuffles bits [02:25] yes [02:25] thats what i men [02:25] mean [02:25] a comment like: "* adjust/rebase patches" ... implies: business as usual [02:26] everything else would make me wonder: what was this in a year or so ;) [02:26] its your private branch so you can just uncommit and push --overwrite [02:27] after doing it two or three times [02:27] you will know the procedure ;) [02:27] is it not helpful to mention which upstream patches caused the rebase? [02:27] its not really rocket science. just a few "best" practices we do with our branches that make live easier to collaborate [02:28] micahg: usually not. [02:28] its at the committers discretion [02:28] for rebasing usually not [02:28] but for dropping its nice to say which bug made this obsolete [02:28] or if the patch was not a rebase, but needed to be redone differently [02:29] ok [02:29] I got through it [02:29] so for this "manifest unification" cause [02:29] working on file 3 of the installer cleanup [02:29] it might be reasonable to say that [02:29] its not a plain adjust [02:29] but "rework patch after upstream landing of bug ..." [02:29] or something [02:29] maybe also give a word or two how you reworked it if its noteworthy [02:30] like "rework patches after upstream landing of bug ...; we move the bits and pieces from the platform specific installer manifest to the new common location and do this and that ..." [02:30] ;) [02:30] but dont make an art out of it ;) [02:34] ah, I'm done :) [02:35] ok, so now I make another commit [02:35] yeah [02:35] or just uncommit and fix everything in the comment :) [02:35] uncom,mit? [02:35] i would split it in two commits: [02:36] ok [02:36] a) simple patch rebase/addjustment [02:36] b) patch changes because of manifest changes [02:36] but thats just my opinion [02:36] ok [02:36] will do [02:36] if you are sure that your manifest adjustment was good you can also just sell it as a "rebase" [02:36] * micahg thinks is good, but it was 3 patches and 1 code change [02:37] what do you mean? [02:37] my suggestion is [02:37] I had to change bin to @BINPATH@ [02:37] ah [02:37] in one file [02:37] to match the new style [02:37] ok [02:37] well. just commit as you think [02:38] so 2 commits or one? [02:38] i will see if that makes sense to me ;) [02:38] i wouldnt commit a patch change that involved real changes in a normal "adjust all patches to new codebase" commit [02:39] but thats me ; [02:39] ) [02:39] but if in doubt. splitting is always good ;) [02:39] also gives you more commits and more bzr karma in launchpad ;) [02:42] oh no ;) ... just found out that i trashed my gnome-bluetooth upload i prepared in /tmp/ with last reboot [02:42] * asac shouldnt reboot [02:42] ok, I just pushed it up [02:43] I noted the mozilla bug for the manifest change [02:43] launchpad is slow in updating ... takes a minute i gues [02:44] done [02:45] yeah. so the commit message is still not formatted like we do ;) [02:45] brb [02:45] ugh [02:46] sorry [02:46] http://bazaar.launchpad.net/~micahg/firefox/firefox-3.7.head.daily-patch-rebase-20090910/changes [02:46] look at that [02:46] forgot the * [02:46] should I fix? [02:46] also you dont need the "updated patches:" line [02:46] because we say: [02:46] - update path/to/file [02:47] - remove path/to/file [02:47] - add path/to/file [02:47] ok [02:47] I'll try again :) [02:48] in the meantime i look at the changes [02:48] also i usually say: "... after upstream landing of BUG or TOPIC" ;) [02:48] or TOPIC (bmo: BUG) [02:49] but if the formatting is ok i am fine ;) [02:50] +bin/chrome/awesome-branding.jar [02:50] thats wrong i think [02:50] you need to use templates everywhere in our patch [02:50] @BINPATH@ [02:50] same for the browser_branding patch [02:51] oops [02:51] you can edit the patches directly ;) [02:51] of course its safer to push and refresh [02:51] maybe do that to excersize a bit more ;) [02:51] editing patches directly can still be done later ;) [02:53] #ifdef XP_UNIX [02:53] is the #endif there somewhere? [02:53] could be that we dont see it in this patch ;) [02:53] yes [02:53] ok [02:54] is it ok that I put it there and not under the ifndef XP_MACOSX? [02:54] our patch is not really arch specific [02:55] i would think [02:55] so could be moved even outside that block [02:55] but doesnt relly matter much here [02:55] * micahg will try a test build [02:56] cool [02:56] thats important [02:56] maybe the branding is completely busted now and firefox doesnt work ;) [02:56] but i hope its ok [02:56] the changes look good to me ;) [02:56] yay! [02:56] at least from the technical side [02:56] BTW, 3.6 only needs the manifest changes [02:57] if it doesnt work we have to check whats going on now [02:57] I fixed the binpath, now I have to push it up again [02:57] fix the commit syntax while you are at it ;) [02:58] I did [02:58] good [02:58] BTW, the main problem I had was I didn't know where to fix the .rej file :) [02:59] did you figure that out? [02:59] yep, with some help from hyperair [02:59] the quiltrc fta gave you had some "use unified rejects" option [02:59] you might want to try that at some point [02:59] the normal .rej format is odd [02:59] but i got used to it [03:00] great [03:00] that you dound your way ;) [03:00] micahg: you forgot a whitespace ;) [03:00] indentation [03:00] of comment :) [03:00] yeah, I had to fix it in the file and then use your funny diffstat ccommand [03:00] you should really look at bzr log | less [03:00] where? [03:01] hmm [03:01] maybe its the firefox font ;) [03:01] its ok ;) [03:01] that's the browser [03:01] yeah [03:01] so please test a build [03:01] and let me know if it works [03:02] is xulrunner also coming? [03:02] didnt even know it failed ;) [03:02] no xul is fine as it seems [03:02] ok [03:03] I made an alias for quilt refresh --diffstat [03:03] yes. you can also use quiltrc for that ;) [03:03] i think everything is ok but the QUILT_PATCHES thing [03:03] thats bogus as it seems for the embedded tarball thing here [03:04] fta: so firefox-3.7 is still in dep wait state. probably got the 1.9.3~umd as the lower bound today ;)? [03:05] asac: well, it wouldn't bui,ld anywyas [03:05] sure [03:06] thats for sure i mean ;) [03:06] i386 has 14k jobs on 15 ppa builders [03:06] ouch [03:06] https://edge.launchpad.net/builders [03:18] asac: builds started right away for me [03:32] asac: it built fine :) [03:34] asac: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20090910 Ubuntu/9.04 (jaunty) Minefield/3.7a1pre [03:37] does it work? [03:37] yep [03:38] try to install abrowser stuff please [03:38] micahg: did you install all packages? e.g. also the -branding etc.? [03:38] yeah, I had the ff3.7 branding [03:38] it showed minefield [03:38] now trying abrowser branding [03:39] hmm [03:39] xml error on abrowser [03:39] asac: yikes, it's like 5 days of back ups for PPAs [03:40] micahg: check if downgrading to latest fixes it at all [03:40] otherwise its not a bug in your change ;) [03:42] still a problem [03:42] but someone else opened a bug for that issue [03:42] in 3.5 [03:43] maybe it's only abrowser related? [03:43] could be. there is a problem in 3.5? [03:44] do you have the menu whited out in 3.7? [03:45] hmm so abrowser command starts firefox 3.0 with official branding ;) [03:45] on jaunty [03:45] or karmic? [03:45] xml error in about help? [03:45] err help -> about [03:45] thats what i see [03:46] seems we miss a logoCopyright entity in our branding pieces [03:46] hmm [03:46] well, if you don't have the abrowser-branding installed [03:46] those branding pieces get lumped together during tarball creation iirc [03:46] micahg: what do you mean? [03:47] i installed abrowser-3.5-branding [03:47] thats how i installed abrowser ;) [03:47] on jaunyt or karmic? [03:47] karmic [03:47] and abrowser-3.5 depends on abrowser-3.5-branding [03:47] yeha, that shouldn't show 3.0 anything [03:48] thats just the abrowser command [03:48] the abrowser-3.5 command works [03:48] only thing broken is about help [03:48] which afaik is what the 3.5 bug is about [03:48] asac: http://packages.ubuntu.com/search?suite=karmic&arch=any&searchon=contents&keywords=abrowser [03:48] that's why [03:48] sure [03:49] should I open a bug? [03:49] thats not a big problem ... we just need a bug for that ;) [03:49] yes. [03:49] "ship unversioned abrowser commandin firefox-3.5 ... or something alike [03:49] and we already have one for the other [03:49] bug 396156 [03:49] Launchpad bug 396156 in firefox-3.5 "Help→About does not function (abrowser-3.5, jaunty-proposed)" [High,In progress] https://launchpad.net/bugs/396156 [03:49] yes [03:49] i have to investigate that [03:51] asac: -beta? [03:51] bug 427674 [03:51] Launchpad bug 427674 in firefox-3.5 "ship unversioned abrowser command in firefox-3.5" [Undecided,New] https://launchpad.net/bugs/427674 [03:52] thx [03:53] * micahg could probably fix, but I'm already working on 3 different bugs [03:53] so have you tried the versioned abrowser command? [03:53] where? [03:53] I tried abrowser-3.7 [03:53]