[00:00] always call /usr/bin/firefox-3.5 for FF3.5 [00:00] problem is that $0 is also used if you tell firefox to make itself the default [00:00] always call firefox-3.0 for 3.0 [00:00] so if thats versioned it will break on next update [00:00] i dont want that to happen for the default browser [00:00] wait, can't we just make it pkg specific? [00:00] micahg: firefox-3.5 is a script too ... same boat [00:01] we have to [00:01] but all have to use the sme approach [00:01] firefox-3.0-bin [00:02] firefox-3.5-bin [00:02] (instead of real) [00:02] and firefox-bin [00:02] being links to the binaries and the script calling those instead of the binaries in the firefox pkglibdir [00:03] what does firefox call when it restarts? [00:03] does it fork a process [00:05] yes [00:06] I still don't get why we can't call what's in /usr/bin instead of /usr/lib/ff* [00:06] the code does not know about /usr/bin/ [00:06] it knows about the firefox dir in lib [00:06] and it knows about the $0 path [00:06] thats it [00:07] Is this upstream code or our code? [00:07] we have a patch that fixes it to usr /usr/bin/firefox ;) [00:07] and i tried to fix some $0 bugs at some point [00:07] could be that we have left overs from that too in the tree [00:07] ah === asac___ is now known as asac [00:08] so can't we change the patch based on the internal version number to point to /usr/bin/firefox-3.0 and /usr/bin/firefox-3.5 respectivelyt? [00:08] micahg: system_path_launch_child.patch [00:08] thats in xulrunner [00:08] ok, I'll pull down source and take a look [00:09] branch lp:~mozillateam/xulrunner/xulrunner-1.9.3.head [00:09] micahg: so upstream does this: [00:09] 1. cut leaf from argv[0] [00:09] 2. try to find the same binary in firefox lib dir [00:09] and start that [00:10] problem is that if you upgrade from 3.5.1 to 3.5.2 you dont have same libdir ;) [00:10] so it doesnt exist and restart fails [00:11] at some other place it uses something similar to set the "default" http handler in gnome (we have that check disabled by default so you dont see that feature) [00:12] thats patched in lp:~mozillateam/firefox/firefox-3.7.head [00:12] http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.7.head/annotate/head%3A/debian/patches/lp185622_system_path_default_browser.patch [00:12] e.g. lp185622_system_path_default_browser.patch [00:12] ah [00:12] i think there its even trickier, because there is no access to argv[0] without much effort [00:12] so, is there a variable that would give us the series version number? [00:13] but i might be wrong because i havent looked at that code in depth for ages ;) [00:13] maybe [00:13] that's what I'm thinking [00:14] something like MOZ_APP_NAME - MOZ_VER? [00:14] what would you do with that? [00:15] know which binary to launch based on version [00:15] 3.0.x would be firefox-3.0 [00:15] well. we could do that easily. but i dont want that because that would be a home brewn thing again ... which would mean a patch [00:15] we could even code the version static in the patch [00:16] the argv[0] thing feels upstreamable [00:16] well, that would prevent the patch working for all version [00:16] yes. there are various ways to do that [00:16] I was refering to the patch you showed me in firefox-3.7 not xulrunner [00:16] i just said that even bumping the version once wouldnt make it harder to maintain [00:17] the main problem is that all patches cause efforts on dailies ;) [00:17] yes [00:17] i have no idea how to do that best in an upstreamable fashion [00:17] actually in a fashion beneficial for all upstream builds [00:17] netiher do I, but I think I can fix it for us at least [00:17] we can upstream it with special configure flags most likely [00:18] the default thing shouldnt be versioned for the default browser [00:18] so that would still require some manual tweaking [00:19] for the xulrunner patch, I could write something to parse the version out of argv[0] and use that [00:20] to use /usr/bin/firefox- <--whatever was parsed [00:20] the xulrunner patch should be fixed properly [00:20] like i said. i will probably just do that [00:20] ok [00:20] i am fine to have the other patch fixed [00:20] maybe we can make a patch.in ? [00:21] so, 1. What to do with that bug? 2. Can I help with any of this? [00:21] i dont like the idea to do that in the mozilla build system [00:21] one second [00:24] * asac is really slow right now [00:26] micahg: ok its really just creating the links i mentioned [00:26] we currently patch the right versioned path into the startscript [00:26] ok [00:27] instead you should use that version info to create a link /usr/lib/firefox-$VERSION/firefox /usr/bin/firefox-$VERSION_IF_NOT_DEFAULT-bin [00:27] and the script should call that [00:27] so, should I mark Medium -> Triaged -> assign to you? [00:27] if you dont want to do that ;) ... then yes, please. [00:28] ah, so I can try to create that? [00:29] http://mxr.mozilla.org/mozilla-central/source/toolkit/components/commandlines/public/nsICommandLine.idl [00:29] so are we talking about having a /usr/lib/firefox-3.5 symlinked to /usr/lib/firefox-3.5.x? [00:29] micahg: there we could get argv0 if it helps for the set-default patch [00:29] no [00:29] ugh [00:30] firefox-3.5-real to /usr/lib/firefox-3.5.x/firefox [00:30] where is firefox-3.5-real? [00:30] it doesnt exist yet [00:30] /usr/bin [00:30] i guess [00:30] not sure if there is a better place ;) [00:31] why is that different than /usr/bin/firefox-3.5? [00:31] * micahg is apparently slow too :) [00:31] because firefox-3.5 cannot be a link as its a script and hence it [00:31] ah [00:31] now I get it [00:31] would break argv0 [00:31] you want to link to the binary, not the script :) [00:32] yes. we can provide a proper link that gets properly updated for minor updates [00:32] and restart should work [00:32] ok [00:32] so this would be in the firefox package? [00:32] accross major versino upgrades that probably wont work ... unless they used the unversioned default links [00:32] micahg: i would think so. probably created using dh_link in debian/rules directly [00:33] as we have the version info available there [00:33] well, we don't do major version upgrades in ubuntu, right? [00:33] check that file... there are already a bunch of dh_link dh_install etc. calls [00:33] micahg: we do. like if you have meta firefox installed in jaunty and upgrade to karmic you get a major upgrade [00:33] would be great if resetart just works ... actually i think it will [00:33] as both will have /usr/bin/firefox-real [00:33] ah, yes, it should :) [00:33] (unversioned) [00:34] in teh default package, right? [00:34] i dont know if we ship the links in the meta package [00:34] * micahg is pulling down ff3.7.head right now [00:34] i dont think we do [00:34] for now put them wherever we ship the /usr/bin/firefox link [00:34] (in the default package) [00:35] Where do you want me to make the patch? [00:35] oh fore firefox-3.7 htere is no default package so its definitly in 3.7 [00:35] do I push to a branch under me? [00:35] micahg: where? [00:35] ah ... yes [00:35] idk [00:35] I've never done this before :) [00:35] use ~micahg/firefox/firefox-3.7.head.lpXXXXX [00:36] so with the bug id appended ... thats good as then you can just mark it merged keep it forever [00:36] ok, do I do that when I push? [00:36] (if your launchpad id is micahg) [00:36] it is :) [00:36] micahg: yes. [00:36] ok [00:36] great [00:36] so, I'll take this one then? [00:36] bzr branch ... work ... bzr push lp:~$YOURACCOUNT/.... [00:37] why not. problem is that i will be on holiday next week ;) [00:37] but i think fta will also guide you in case you need help [00:37] ok, well, maybe I'll work on it next week, is there any urgency? [00:37] maybe you get it even done tomorrow ;) [00:37] hehe [00:37] yeah. as you wish [00:37] * micahg has a lot of work work to do :) [00:37] its open long enough so it can wait another few days [00:37] should I assign to me if I won't work on it till next week? [00:38] hmm [00:38] micahg: depends on how you work flow is [00:38] is the new one a dup then? [00:38] * micahg has nothing assigned [00:38] if you can remember without assigning then its ok to not assign or whaeever you prefer [00:38] ok [00:38] is this an old problem? [00:38] i dont remember anything without a major light blinking all day ;) [00:38] its there since we have more than one branch [00:38] i would thihnk [00:39] but it only became really relevant when ubufox started to show "restart" button [00:39] i think that was intrepid [00:39] so, is the current bug in ubufox? [00:39] thats where i landed the fix [00:39] no [00:39] ubufox just relies on that feature to work accross version upgrades [00:39] so without doing anything that restart feature would be even more busted as it would never work for minor upstream versino upgrades [00:40] ok, I'm just wondering if it's a dupe or not, this new one [00:40] before I mark it triaged [00:40] even if its a dupe ... the bug that is worked on is always the master ;) [00:40] ok, so I'll mark this triaged [00:40] do a quick check ... if you dont find something just work on it ;) [00:40] is this considered low? [00:41] medium i would say [00:41] ok [00:41] at least ;) [00:41] its quite an odd behaviour [00:41] micahg: its probably low on the current default version (e.g. 3.5) because that works ;) [00:41] but for 3.6 etc its medium [00:42] you can use firefox-3.6 and firefox-3.7 package already in launchpad afaik [00:42] because they are in a ppa [00:42] so add those targets if you want ;) [00:42] the other thing we have to do is to get rid of firefox-3.0 ;) [00:44] yeah, next week, I'll start on verifying the blueprint [00:44] I need some time off this weekend [00:45] thanks for spending the time going through all that though [00:46] I learned quite a but [00:46] *bit [00:48] asac: do we really want to start tracking stuff against 3.6 and 3.7? [00:49] since there's no official version in Ubuntu for it, how would we ever marked fix released? [01:06] those bug pages were created because of ppa uplaods ;) so bug fixes could be done in ppa [01:06] but i dont mind [01:06] we can also not do that ;) [01:07] if you want to track bugs for ppa, I'll do it [01:08] Also, that issue we were talking about, would it be fixed for 3.0 as well? [01:13] why not ... but not for < karmic [01:13] at least not without quite a long bake time ;) [01:13] ok i am out... talk to you tomorrow ;) [01:13] ok, night [04:26] !fta [04:27] Sorry, I don't know anything about fta [05:09] e-jat: fta is probably offline as it's early morning in europe [05:26] micahg: hi... asac asked me to test firefox 3.5.2 to check if a bug is solved , he said , i have the firefox3.5.2.tar.bz , do i just replace my profile firefox with this? or how do i do it? [05:27] no [05:27] did he as you to test the upstream version? [05:27] or our version? [05:27] 3.5.2 has been out for 2 weeks [05:27] is there bug number? [05:28] he yeah , and he gave the link to the tar.bz , it the cursor bug , just a sec [05:29] sheesh! so many typos! [05:29] micahg: Bug #413950 [05:29] Launchpad bug 413950 in firefox-3.5 "Incorrect cursor positioning in Firefox." [Undecided,Confirmed] https://launchpad.net/bugs/413950 [05:30] right [05:30] so why would he ask you to check 3.5.2? are you running 3.5.1? [05:30] or did he ask you to try 3.5.3? [05:30] huh...! wait [05:31] oops ! i was blind ! he probably gave the wrong link accidentally , and i didnt check :( [05:32] what are you running? [05:32] 3.5.2 in Karmic [05:33] ok, so what's the link he gave you? [05:34] just a sec , checking FF history [05:35] http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5.2/linux-i686/en-US/firefox-3.5.2.tar.bz2 [05:35] ok, maybe he wanted you to check to see if the upstream version has the bug [05:36] go for it [05:36] just download and decompress and run the binary [05:37] micahg: oh ok , just run from the /firefox-bin ? [05:37] yes [05:37] hmmm... ok thanx [05:47] hehe , you guys are confusing! ;p he said upstream version too , i thought that meant the next higher version from upstream ! [05:47] jj [11:12] fta: you are insane (wrt songbird fixing) ... [11:13] insane == in a good way [11:13] i think we talked with stevel that having someone from songbird folks caring for the packaging in ubuntu would be a requirement to get this into universe [11:13] maybe we can use that to get their support on dailies as an excersize on how to maintain stuff [11:19] あさく [11:20] oops [11:20] asac, i fixed it because someone complained it was broken for too long [11:24] ETOOMANYNEWBUGS to start on nm bug processing [11:24] * asac does something else [11:27] http://identi.ca/notice/8534673 ... hehe [11:30] fta: i think we should do dailies for 3.0 for < karmic [11:30] currently folks are stuck with a partial migrated default ffox 3.5 [11:30] i dont even know the status they are in ;) [11:31] i would think we just need the firefox package to be daily (no xul) [11:31] actually we would just need to care that we do an upload whenever i do a security release ... but i have the feeling that having dailies would be easier to (not-) remember [11:48] Jazzva: https://code.edge.launchpad.net/~jazzva/firefox-extensions/mozilla-livehttpheaders-0.15/+merge/10107 ... i guess i failed on that one? [11:50] asac: failed? [11:51] Jazzva: yes. its outstanding stilll ... so i assume i failed to review that ;) [11:52] asac: You probably missed it :) [11:52] heh. i had it in my inbox still ... so i didnt miss completely (otherwise i wouldnt have found it now) [11:53] let me do that [11:53] ok, thanks :) [11:53] also diverged [11:53] gues its really old then [11:54] Jazzva: the nspluginwrapper changes are not made on top of current nsp branch [11:54] can you check whether its ok? [11:54] i will then merge it ... but wasnt sure [11:56] asac: I'm using it right now, and it works for me. IIRC, I uncommitted revs 54-56, applied the diff between 0ubuntu5 and 0ubuntu6 to revision 53, and then worked on top of that. [11:57] that is the reason why it is not the same. [11:58] Jazzva: done liveheaders [11:58] yay, thanks :) [11:58] Jazzva: you mean you made it now apply cleanly? [11:58] nsp? [11:58] asac: apply cleanly? to lp:nspluginwrapper branch? [11:59] ah you uncommitted the uplaod that wasnt done [11:59] right [11:59] let me check that [12:01] Jazzva: you should have used debcommit -e [12:02] the uncommit/recommit doenst have the changelog changes in it now [12:02] and the release is not marked properly with a release commit [12:02] :) here but tired as hell and wont be here long i just got home maybe 20minutes ago [12:03] Jazzva: do you use debcommit at all? [12:03] asac: I use it. [12:03] 1.3.0-0ubuntu1 was never released. you could have re-released with same version [12:03] asac: do you want me to redo the revisions and correct it? [12:04] tough question [12:04] i hate to not have a release commit [12:04] but its many revisions and i dont know about a tool that automatically rebases [12:04] well, it's not that hard. I'll go commit by commit, and just apply diff from the current branch :). [12:04] oh ... what you could try is do a release commit after the revision [12:04] and then try the bzr rebase command [12:04] of your branch against the branch with the release commit on top [12:04] with some luck it will work [12:05] asac: thanks for the push [12:05] if you dont want to, i can probably also give it a shot [12:05] gnomefreak: no problem. i hope i can do lighting today before going to vacation for one week [12:05] will be back on 1st sep [12:05] I'm not sure I followed the part about bzr rebase? [12:05] How do I do that? [12:06] asac: thanks [12:06] Jazzva: install bzr-rebase [12:07] package [12:07] then ... [12:07] branch revision 54 ... uncommit and commit it with debcommit -e (with UNRELEASED) ... then do a release commit (just flip to karmic and use debcommit -r) [12:08] so now you have the new branch with the fixed revision [12:08] now you pull your branch and run bzr rebase against the branch with the release commit on top [12:08] that should replay your commits on top of the one with the new release commit [12:09] asac: Ok, I'll try [12:18] asac: I should pull rev 54 from my branch, right? [12:19] Jazzva: yes. pull that, uncommit that ... change to UNRELEASED, use debcommit -e (and explain the uncommit stuff on top of what gest generated [12:19] ah, ok :) [12:19] and then change manually to karmic and commit with debcommit -r [12:20] then try to rebase your branch on that one [12:20] asac: ok [12:20] (best backup what you just did in case you get it wrong ;)) [12:21] asac: thanks. i wish you a relaxing vacation. [12:26] i will ;) [12:36] asac: That uncommit/commit and then release commit ended up as the newest revisions (after release for 1.3.0) [12:36] and diff shows them as empty commits. [12:38] Jazzva: you rebased in the wrong direction then [12:38] you probably rebased the new against the old branch (old is the one with all your commits) [12:38] you need to rebase the old against the new ;) [12:39] but good that rebase was smart enough to empty them ;) [12:39] ah... ok :) [12:40] asac: i intend to help on universe sponsoring and helping in mozilla related packages suggests itself. [12:52] Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64 [12:52] ALSA lib ../../src/conf.c:2700:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so [12:52] ALSA lib ../../../src/pcm/pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default [12:52] asac, we should really have the x64 flash, ia32 is really broken [13:07] asac: rebase thing is not working, but it's reporting some revisions that don't exist and to report a bug. I'll paste the report now [13:08] asac: http://paste.ubuntu.com/256870/ [13:09] !info firefox hardy [13:09] firefox (source: firefox-3.0): meta package for the popular mozilla web browser. In component main, is optional. Version 3.0.13+nobinonly-0ubuntu0.8.04.1 (hardy), package size 64 kB, installed size 120 kB [13:09] !info firefox-2.0 hardy [13:09] Package firefox-2.0 does not exist in hardy [13:14] asac: have a nice vacation [13:15] thx [13:16] asac, going out for vacations? [13:16] fta: luke is working on a proper biarch build for sounds libs now [13:16] fta: did you see the mail on devel from today? [13:16] no [13:16] gnomefreak, is he leaving for vacations? [13:17] fta: https://lists.ubuntu.com/archives/ubuntu-devel/2009-August/028774.html [13:17] fta: so once he has that done we should replace the current libs with those (or maybe depends) in ia32 [13:17] i think he is looking for help ;) [13:18] he also mentioned that alsa is now properly done already. so you could start with that [13:19] asac, leaving for holidays? [13:19] y [13:19] weekend or more days? [13:20] asac, the split will make backports almost impossible with one branch [13:20] fta2: which split [13:20] ? [13:21] ia32 [13:21] we have a branch? [13:21] i guess that only effects builds that require ia32 during build? [13:21] like your old chromium? [13:24] asac, news about mozilla-devscripts upload? [13:24] does it block anything? [13:25] yeah, all-in-one upload [13:25] i think I should upload it today [13:25] ok [13:25] asac, all-in-one is ready [13:25] will take care that it happens [13:25] if you want me to provide you branch name [13:25] asac, no, i mean, as a consumer of ia32, if the content of ia32-libs changes, that would be impossible to accommodate to with a single branch (like ours) because of the deps/build-deps [13:25] asac, ready branch is here: https://code.launchpad.net/~mozilla-extensions-dev/firefox-extensions/all-in-one-sidebar.ubuntu [13:26] fta2: i would think that ia32-libs would just get changed depends on its own ... so its transparent for depends [13:26] feel free to change the distro from unreleased to unstable [13:26] if you gonna push it [13:26] for build-depends i am not sure .... but we dont use ia32-libs to build anything except previous chromium iirc [13:26] andv: yes [13:26] asac, or just let me know if you won't do it [13:26] andv: is that a new package in debian? [13:26] asac, yep [13:26] andv: you would notice it by the upload not going out by end of tomorrow [13:27] (in worst case) [13:27] asac: there is no abrowser-3.0 package? [13:27] asac, ok perfect [13:27] asac, if any other change is needed just ping me and it will be fixed [13:27] andv: there is a abrowser-3.0 package [13:27] bdrung: yes. that feels like a bug [13:27] gnomefreak, ? [13:27] guess we need to review how we do meta/vs non-meta for abrowser [13:28] although it might be just abrowser as a name [13:28] oops sorry andv [13:28] gnomefreak: it was bdrung asking [13:28] there is no abrowser-3.0 package here indeed [13:28] its a bug i am sure [13:28] asac: i saw [13:28] asac: abrowser is 3.0 isnt it? [13:28] we no longer have any 2.0 in any release [13:28] gnomefreak: its now 3.5 i would hope ... hiding the 3.0 package [13:29] asac: how to fix it? introducing abrowser-3.0 or dropping it in xpi.mk? [13:29] oh damn [13:29] i forgot the changes to default browser [13:29] bdrung: we should fix it by having always versione dpackage and only one unversioned one in the default (like for firefox) [13:30] asac, I had a talk with myon about my NM status he mailed me about, and he said me keyring managers will probably process new debian developers this weekend [13:30] asac, just as an update [13:30] asac, but I assume you'll be away [13:30] gnomefreak, I see a flashgot package on the queue here, any news about it? [13:31] andv: waiting for asac to review and upload [13:31] kk [13:31] since we are at or near FF it is possible it wont make it again [13:32] gnomefreak, yeah [13:32] let's have it for karmic+1 then [13:32] asac: currently we do not have the firefox package in xpi:Depends [13:32] if asac won't make it [13:33] andv: that was the plan but he has 1 more of my packages to push besides flashgot and hes on vacation for the next week/10 days [13:34] gnomefreak: could you have a look at this Bug #416084 , this always happens to me ... do i have to add any additional info? [13:34] Launchpad bug 416084 in thunderbird "thunderbird-bin crashed with SIGSEGV in gtk_main_do_event()" [Medium,New] https://launchpad.net/bugs/416084 [13:34] gnomefreak, which issues did he find on flashgot? [13:34] gnomefreak: did you package latest flashgot? [13:34] please bump to the most recent stuff available [13:34] andv: this time around none. not since i updated to 1.2(i think that is the version in my PPA [13:35] the author send me that all the licensing issues are done [13:35] so we can finally upload it with heads well up [13:35]