=== asac_ is now known as asac === BUGabundo1 is now known as BUGabundo [00:37] fta apt url not working on 3.6? [00:38] apturl works because of ubufox [00:39] I believe [00:39] realy? [00:40] yes [00:40] does it even work in 3.5? [00:40] in karmic it should now [00:40] asac: released it [00:40] I had to roll it back because it screwed up flash foe [00:40] for me [00:41] :( [00:41] since it prob won't work on 3.6 [00:41] I can't use apturl [00:41] BUGabundo: you can try to override compatability and try it in 3.6 [00:41] $ ls -l /etc/firefox-3.*/pref/apturl.js [00:41] -rw-r--r-- 1 root root 246 2008-03-28 15:44 /etc/firefox-3.0/pref/apturl.js [00:41] last time it was a mess [00:42] $ dpkg -S apturl.js [00:42] apturl: /etc/firefox-3.0/pref/apturl.js [00:42] apturl: /usr/share/firefox/defaults/pref/apturl.js [00:42] but ubufox is what works with apturl [00:42] some one forgot to commit [00:45] i remember i had to add support for ff3.0 last year [00:45] bug 207281 [00:45] Launchpad bug 207281 in xulrunner-1.9 "[hardy beta] firefox3b4 does not recognize apturls (apt://) (dup-of: 203538)" [High,Fix released] https://launchpad.net/bugs/207281 [00:45] Launchpad bug 203538 in apturl "Don't work with Firefox3 beta5" [Medium,Fix released] https://launchpad.net/bugs/203538 [00:45] eh [00:46] looks like that's another thing we need to abstact out like the search plugins into a generic local [00:46] *locale [00:48] i won't touch it, i think asac already has something in mind for that [00:49] right [00:49] I'll talk to him about it tomorrow [00:51] one strange think I'm noticing [00:51] I set my cookies to ASK [00:51] I only have like 15 cookies on my FF [00:51] but on deviantart.com/ [00:51] I get asked on every page if I want to save the cookie and in every I say NO [00:52] why doesn't FF remember it? [00:53] because each page is a new subdomain [00:53] cookies can be per domain or per subdomain [00:54] :( [00:55] you can probbaly deny cookies for a certain domain if you want [00:56] prob [01:54] fta: asac hey [03:40] !ping fta .. [03:40] Sorry, I don't know anything about ping fta .. [08:00] hola [08:00] * asac back from the dead [08:00] LLStarks: pong [08:01] LLStarks: i dont know [08:01] you see it though, right? [08:01] which ffox? [08:01] 3.6 [08:01] nightly [08:02] from the ppa [08:02] since when ? [08:02] a few days [08:02] 2-3 [08:02] havent updated my dailies for a few dys [08:02] will do that now [08:04] hi asac [08:04] hi micahg [08:04] * asac scrolls back [08:04] where should we move the user agent discussion if at all? [08:07] micahg: you say folks still complaining about Shiretoko? [08:07] still folks complaining? dont we have a bug where we can point them to? [08:08] LLStarks: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090713 Ubuntu/9.10 (karmic) Minefield/3.6a1pre [08:08] that one is still ok [08:08] now upgrading [08:08] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090719 Ubuntu/9.10 (Karmic Koala) Firefox/3.6a1pre - Build ID: 20090719154019 [08:09] yes, i know it's a bit franksteing [08:09] *stein [08:09] now testing [08:09] but i do it for compat sake [08:09] still upgrading ;) [08:09] compat? [08:10] i think this upgrade will take a bit; i get a coffee now [08:18] asac: yeah, they;re complaining in the bug === micahg1 is now known as micahg [08:32] asac: I don't know how to make it any clearer [08:32] should we keep going back and forth in the bug? [08:37] i think its ok [08:38] just dont feed them [08:38] there is not much more we can tell [08:38] we will soon enough make it firefox [08:38] just let them keep going back and forth them? [08:38] in Jaunty? [08:39] i will think about it once we have it in karmic [08:39] :) [08:39] ok [08:39] so, what about the user agent stuff [08:39] should I report any more? [08:40] hmm gone ;) [08:41] oh, also, gnomefreak make the debdiff for the ubufox is recommended problem [08:42] *made [08:44] asac: would u mind to check this bug 401207 [08:44] Launchpad bug 401207 in firefox-3.5 "shiretoko crash when closing page pdf viewed" [Undecided,New] https://launchpad.net/bugs/401207 [08:44] it occurs for shiretoko n minefield [08:52] asac: adobe reader? [08:52] we have the plugin in the partner repo [08:54] BTW, asac, just triaged a bug where FF3.5 won't quit on ext4 [08:54] bug 400088 [08:54] Launchpad bug 400088 in firefox-3.5 "Firefox 3.5 doesn't terminate with home dir on ext4" [High,Triaged] https://launchpad.net/bugs/400088 [08:55] * micahg is off to bed [08:56] micahg: sleep well [08:56] thanks :) [08:56] micahg: where did gnomefreak put the debdiff? [08:56] (for ubufox) [09:38] http://src.chromium.org/viewvc/chrome/trunk/src/courgette/ [09:38] e-jat: epends on the the backtrace if its triaged [09:38] let me look [09:40] i follow the wiki .. to debug it .. [09:40] asked [09:40] e-jat: please use ubuntu-bug firefox-3.5 to file bugs in future ;) [09:40] that will attach loads of info that is helpful [09:40] e-jat: i think you can run apport-collect now [09:41] to attach that info as well [09:44] yeah .. forgot about that .. doing the apport-collect now .. [09:48] thx [09:49] asac: im using adobe reader 9.1 [09:51] asac, is the font smoothing bug present on your machine? [09:52] LLStarks: font smoothing? [09:55] LLStarks: let me check. upgrad should be there now ;) [09:55] thx [09:55] so the profile dialog works as before [09:55] no it work [09:57] asac: from the full bt output .. where should i look the main cause it break? [09:57] LLStarks: http://people.canonical.com/~asac//tmp/Moz36Jul20.png [09:59] e-jat: do you always get this BadAccess error? [09:59] buf = "BadAccess (attempt to access private resource denied)\0\0\0\0\0\0\0\0\0\0" [09:59] probably you see the error on the console too [10:02] mozilla bug 451944 [10:02] ouch [10:02] Mozilla bug 451944 in Plug-ins "Fx crashes when displaying PDF with Adobe Reader 9.0.0 with modified user agent string [@ msvcr80.dll@0x14500] ("nsPluginHostImpl::UserAgent return=(null)" when UA string exceeds a length limit (more than 25 extra characters))" [Critical,Resolved: duplicate] http://bugzilla.mozilla.org/show_bug.cgi?id=451944 [10:02] mozilla bug 457157 [10:02] Mozilla bug 457157 in Plug-ins "tab crash after destroying an embedded pdf object (Adobe Reader 9.0.0)" [Critical,Resolved: duplicate] http://bugzilla.mozilla.org/show_bug.cgi?id=457157 [10:04] yeah .. i think it similiar :) [10:04] e-jat: didnt apport-collect work? [10:04] e-jat: its fixed [10:04] it shouldnt be in 9.1 anymore i mean [10:05] hmm so .. what shall i do now ? remove the plugin n reinstall ? [10:05] for ff 3.0.11 its work well .. [10:06] e-jat: and 3.5? [10:06] crash .. same goes with 3.6 [10:08] 11:04 < asac> e-jat: didnt apport-collect work? [10:11] asac: to collect info ? [10:11] e-jat: to attach that to the bug [10:11] like i asked you [10:11] apport work .. [10:11] 10:40 < asac> e-jat: i think you can run apport-collect now [10:11] 10:41 < asac> to attach that info as well [10:11] 10:44 < e-jat> yeah .. forgot about that .. doing the apport-collect now .. [10:11] 10:48 < asac> thx [10:12] there is not info on the bug yet [10:12] bug 401207 [10:12] Launchpad bug 401207 in firefox-3.5 "shiretoko crash when closing page pdf viewed" [Undecided,Incomplete] https://launchpad.net/bugs/401207 [10:12] apport-collect data n dependecies already there [10:15] e-jat: thats what apport collect attached? [10:15] there should be a bunch of more stuff when you use ubuntu-bug firefox-3.5 [10:15] i thought apport-collect would run the hook like ubuntu-bug [10:18] :( [10:20] another thing .. my 3.5 n 3.6 look weird while at google main page .. it look like this : http://imagebin.ca/view/hC2n2dW.html [10:20] hi [10:20] it show long form fill [10:20] asac, hey, glad you're back [10:20] asac, some reading for you: [10:20] Jul 18 19:19:33 asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/5dfbadda21300b37# [10:20] Jul 18 19:20:02 asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/5bd9d185a45f81ba# [10:20] Jul 18 19:35:39 asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/aabc1472bf19b2f5# [10:21] Jul 19 02:15:52 asac, funny.. http://codereview.chromium.org/155558 [10:21] Jul 20 00:25:32 asac, http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium :( === dpm_ is now known as dpm [10:27] Hi asac, can we talk about bug #217908 again? [10:27] Launchpad bug 217908 in cairo "Pixellated Images in Firefox/Opera due to incorrect EXTEND_PAD implementation in several video drivers" [High,Fix released] https://launchpad.net/bugs/217908 [10:27] Jeff has reviewed the patch I posted now [10:28] fta: thanks. i had to get out over the weekend [10:28] and then had no chance to look back ;) [10:29] I still think we should go with this patch for now until we have the new x server and cairo in karmic: http://launchpadlibrarian.net/22544758/xulrunner-1.9.1.debdiff [10:33] heh [10:33] fta: thanks for those first three pointers [10:36] " Flash calls gtk_widget_modify_bg from an expose handler" [10:36] hear hear [10:36] + [10:36] +// Flash calls XGetWindowAttributes with a NULL display, which crashes. [10:36] +// So we intercept that function and make sure the display is set. [10:37] * asac wonders if those were filed upstream [10:38] fta: do yo uknow if they work with adobe on such things? [10:38] i think they do, did you read the comments below the patch? [10:42] asac, http://paste.ubuntu.com/222582/ [10:44] asac: we (Mozilla) do report bugs to Adobe [10:48] why does it suck so much then? [11:00] reed: those are chromium hacks [11:01] reed: we actually thought about using libjpeg from mozilla as the new system jpeg [11:01] asac, hi [11:02] reed: because we think that mozilla did the last optimizations on that otherwise dead upstream [11:02] but we ended up in crashes. you think it makes sense to file bugs about that? [11:02] bluekuja: h [11:02] i [11:03] asac, we fixed the startup already on the first revision but my co-maint forgot to push them [11:04] asac, but now it's ok, fixed them and tried it out on pbuilder [11:04] asac: sure, feel free [11:04] bluekuja: so thats the thing i wanted to sponsor, but then someone else did? [11:04] I do know there are some libjpeg patches still in bugzilla [11:05] that need to land sometime [11:05] asac, nope, it was cgmail [11:05] asac, we did so much changes on it (like 30+ lines changelog) [11:06] reed: right. mozilla jpeg didnt really look more un-dead then upstream, except that moz has more patches on top :) [11:06] bluekuja: why wasnt it tested? [11:06] asac, so we lost the change related to startup (e.g changing final dir to /usr/share/cgmail/stuff [11:06] asac, it was tested, but we had it working [11:07] asac, we had a working branch [11:07] well. [11:07] asac, but we forgot to push the change related to startup [11:07] why wasnt the bzr revision i was given tested? [11:07] why did it work? [11:07] is this a corner case? [11:08] asac, nope, we fixed the startup error and we had it working (as u can see in the changelog) [11:08] asac, but those changes weren't pushed to the branch [11:08] why "we" [11:08] i didnt test it at all [11:08] (maybe my co-maint forgot to do it) [11:09] we = me and my c-maint [11:09] right. so the revision i was given wasnt tested ;) [11:10] asac, looks like we tried out our files [11:10] asac, which were working [11:10] ok [11:10] asac, and maybe we forgot to push the changes we test directly to the branch [11:10] i dont understand how that can happen with something packaged though [11:10] how can two guys test the same without pushing? [11:11] asac, maybe we got confused with the huge changelog [11:11] asac, a lot of changes [11:11] anyway. it just means the revision released wasnt tested ;) [11:11] asac, and we lost some pieces around [11:11] which is bad. but we will get over it [11:11] the bug is marked pending. [11:11] asac, yep [11:12] you should always add changelog entry in the same commit you do the change [11:12] in that wy you know that changelog reflects what is in the branch [11:12] edit changelog, then use debcommit [11:12] asac, oh ok, I was used to first do the change and then update the changelog on the other rev [11:13] asac, anyway if you have unstable there, after you built the package, just install it and run it from console [11:13] asac, it *will* work [11:14] i dont want to test anything. i expect any sponsoree to submit stuff that works :) [11:15] asac, k [11:15] its ok. but not starting at all is really a gross bug ;) [11:15] asac, believe me I tested it [11:15] asac, and it worked over here [11:15] well. you didnt test it properly then [11:16] asac, or maybe I tested it on my files [11:16] asac, with everything updated and fixed [11:16] the file that is missing is package mangaed. that means it was in the package you tested, that mans you didnt build the package from the bzr branch [11:16] exactly [11:17] I built it externally thinking the branch was updated [11:17] my error [11:17] y [11:17] but the fix is ready, so, the problem doesnt exist [11:22] asac, gonna test it one more time [11:22] asac, gonna ping u when done [11:23] asac, ping [11:25] TomJaeger: hi. sorry if it felt like i ignore you ;) [11:26] i saw you but then you scrollef of my radar ;) [11:26] okay, so what do you think? [11:27] * asac fights with launchpad [11:27] that bug is a mess [11:29] TomJaeger: i think you need superreview ... https://bugzilla.mozilla.org/show_bug.cgi?id=422179 [11:29] reed: ^^? [11:29] Mozilla bug 422179 in GFX: Thebes "Implement Bug 381661 (bilinear filtering of upscaled images) for Linux" [Normal,New] [11:32] Do we need to get patches reviewed that go in development versions? [11:34] The longer we wait, the less testing we get, and we might not be that far away from 1.7 being branched off and the closed-source drivers being shut out [11:42] TomJaeger: we need to land it upstream, yes. [11:43] 1.7 branch is cairo? [11:43] xserver [11:43] this means essentially no testing for binary drivers [11:45] can you explain that to me? also why would rushing this fix in help? [11:46] TomJaeger: ^^ [11:46] I'd prefer if the fix attached to the launchpad bug (not the one posted on the mozilla bugtracker), which unconditionally enables EXTEND_PAD be used for a while [11:46] otherwise we'll have to wait for karmic upgrading to xserver-1.7 for the fix to kick in [11:47] binary drivers aren't usually available until the last minute before release (frglx for sure), so they won't get any testing [11:48] at least that's how I think it works, I've never used the binary driver before [11:49] but the video driver API has definitely changed since 1.6 [11:51] For what it's worth, I haven't heard any complaints from nvidia/ati users, but I have no way of knowing how many people are actually using my firefox-smooth-scaling PPA [11:52] TomJaeger: where was the full EXTEND_PAD patch suggested upstream? [11:52] its not in that bug, right? [11:52] in moz bug i mean [11:53] sorry, what was the question? [11:53] 12:52 < asac> TomJaeger: where was the full EXTEND_PAD patch suggested upstream? [11:53] 12:52 < asac> its not in that bug, right? [11:53] 12:52 < asac> in moz bug i mean [11:53] .> [11:53] 12:46 < TomJaeger> I'd prefer if the fix attached to the launchpad bug (not the one posted on the mozilla bugtracker), which unconditionally enables EXTEND_PAD be used for a while [11:54] meaning: i definitly cannot add this patch if its not in moz tracker [11:54] if its in moz tracker we need to get it review- [11:55] e.g. i need to get them to review whatever we add [11:55] we can add it to trunk [11:55] but thats basically all we can do and we dont have that many users on trunk dailies [11:57] so I might as well not go though all the work of getting this patch reviewed and explaining all the details to upstream, because nobody is going to test it anyway [11:58] TomJaeger: you mean the 1.7 server fix? [11:58] no, I mean the unconditional one [11:58] i think that should be pushed through [11:58] right. but if you dont do it, then i have to do it - in theory before landing it [11:59] i could add it until we rebrand firefox, but that might not be long enough to be of any value [11:59] i could add it to 3.5 in karmic i mean [11:59] afaics the 1.7 server fix will get landed and we should concentrate on cherry picking that. why wouldnt it work? [12:00] it'll work, but it'll depend on xserver 1.7 [12:00] also if we add the 1.7 server fix we could at least ask our X maintainer to remind binary driver providers to test this bug before sending it in [12:00] you think thats a good compromise? [12:00] free drivers will get enough testing i presume [12:01] yes, free drivers should be fine [12:01] okay, so let's do that [12:01] right. so it all depends on the non-fre ones. imo only thing we can do is really raise awareness aobut this [12:02] i mean even testing xserver 1.6 might not help because you never know what regressions you get in the new driveres [12:02] especially since api changes etc. [12:02] so it might work well, and then i wouldnt be shocked if it doesnt work with 1.7 anyway [12:02] great [12:03] lets follow this 1.7 patch through ... and rather get permission to cherry pick it to 3.5 (in case they dont want it upstream on that branch) [12:03] okay, sounds good [12:03] how does the superreview process work? [12:04] TomJaeger: you need to ask superreview from a superreviewer ;) [12:04] wait a sec [12:04] http://www.mozilla.org/hacking/reviewers.html [12:05] TomJaeger: if you have that i can commit that for you [12:05] it doesn't seem like this needs superreview [12:05] TomJaeger: or you can add needs-checkin to whiteboard .. so some friendly moz committer does that [12:06] TomJaeger: i think only reason its not needed is if the reviewer is superrevierwer [12:06] at least that was my rule of thumb [12:06] okay [12:06] why do you think you dont need it? [12:07] it doesn't really fall under any of the "What needs super-review?" categories. [12:07] Effective immediately, super-review will be required for certain types of changes for _all_ code residing in mozilla-central (Hg) (and all release branches based on mozilla-central) unless explicitly exempted in the Exceptions section below. [12:08] anyway [12:08] i asked reed to look, so he will guide you i am sure [12:11] great [12:12] if he doesnt follow up later today (he is sleeping i guess) let me know [12:12] okay, thanks. Will do. [13:27] fta: there? [13:47] asac, ? [13:49] i wish someone fixes bug 243344.. [13:49] Launchpad bug 243344 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::IMEngineInstanceBase::get_frontend_data()" [Medium,Confirmed] https://launchpad.net/bugs/243344 [13:59] fta2: isnt that an ArneGoetje bug? [14:00] does it crash all the apps or just the scim server side? [14:00] fta2: http://hg.mozilla.org/users/dmills_mozilla.com/about-tab [14:00] just scim [14:01] asac, dead since april? [14:02] fta2: could be that it moved somewhere else. most likely its just that they noticed that they wont get it done for 3.5 and so it got lower priority again now [14:19] http://code.google.com/p/chromium/issues/detail?id=9643 [14:20] asac, do you know the current status of the multi-arch project? [14:20] i guess i can ask mvo [14:21] i have no idea. ask mvo, yes. [14:21] at best in ubuntu-devel [14:21] most people that know about that are probably there [14:22] fta2: so all im libs are missing? [14:22] have you tried if it works if those get installed? [14:24] there are dozens of ia32-libs related bugs currently open :( [14:28] maybe we should have an ia32-libs ppa, auto updated like my ia32-*-chromium-* package so we can add the missing pieces (debs, links) and keep it up-to-date security wise, at least at the level of each distro [14:31] fta2: you say stop distributing it in the archive? [14:31] or have a ppa to layer on top? [14:31] how would that ppa get enabled? automagically? [14:54] asac, i'm not sure it's possible to run fetch-* directly inside the builders [14:55] fta2: what does fetch- do? [15:10] asac, .. but the idea would be to auto-update the debs in it, create a kind of hash, if it's different, push that to the ppa. at build time, add the missing links like in karmic, eventually tweak control with the other ia32 packages [15:11] asac, fetch-* downloads the indexes, then grab all the debs and the corresponding source packages [15:13] hey asac and fta2 how you guys doing [15:13] good ;) [15:13] thanks [15:13] hope you too [15:13] :) [15:13] asac, i'm quite sure it's possible to do something with a bunch pbuilders, i'm just afraid i don't have the resources to test on anything but karmic [15:13] ya trying to get used to my mac [15:13] and im contemplating setting up another vm to push to karmic while i keep one for jaunty so i can test stuff for you guys [15:14] * eagles051387 waits to get scolded for getting a mac lol [15:14] fta2: before thinking further we should understand what the state of the multiarch effort is and what exactly they plan todo [15:14] * eagles051387 sits and waits for the lecture to start on multiarch effort [15:15] asac, multiarch will do no good to jaunty<->hardy [15:15] asac: does this have to do with multiple processor architectures [15:16] eagles051387, no, it's about running 32bit on 64bit distro, but without the ia32-libs crap [15:16] that sounds interesting [15:16] would love to figure out how mac is gonna do it in their next release [15:17] https://wiki.ubuntu.com/MultiarchSpec [15:17] fta2: i am not sure how much effort we really want to put into hardy <-> jaunty [15:17] fact is that we all dont even have that installed [15:18] and also this sounds like an endless support nightmare [15:18] e.g. the more you try to do better the more requests and complains you will get etc. [15:18] i expect things to be quite stable there [15:19] fta2: how many ia32 packages do you suggest? [15:20] like one per seed? [15:20] or random? e.g. one for chromium, one for other stuff? [15:20] or like it is now= [15:20] ? [15:20] one per seed [15:21] and where would special depends for things not in the seeds (like chromium) go in? [15:21] would you maintain unofficial seeds for that? [15:21] the thing is, there are some rogue ia32 packages that people found somewhere to fix their own bugs [15:21] :) [15:22] asac: i would be willing to test it out with various things like shoutcast if need be [15:22] i can upgrade my desktop upstairs to karmic and start testing [15:22] eagles051387: what particular do you want to test? [15:23] the multiarch stuff [15:23] i have 64bit jaunty currently on my desktop i have in the other room [15:24] eagles051387: i dont think we have something to test right now. we are discussing what we could improve and found that we couldnt even test whatever we decide to do [15:24] fta2: i didnt question the idea of fixing the ia32 packages. just want to understand whats the idea :) [15:24] gotcha [15:25] asac: would you like me to try and figure out how its gonna work in mac when the release the next version of it [15:25] eagles051387: as soon as we have something we are happy to have testers i am sure [15:25] cuz from what i have been talking to people in mac channel they are saying that it doesnt use ia32-libs and and you both discussing this has got me interested to figure out how mac has it implemented [15:26]