[00:01] LLStarks: when asac releases the next version to main, he can include it if he so chooses [00:04] micahg: you may also be interested in that issue, since you assigned yourself to bug #327863 (the trough appearing in firefox text boxes) [00:04] Launchpad bug 327863 in xulrunner-1.9.1 "non-zero GtkRange::trough-border value produces strange boxes in Firefox" [Low,In progress] https://launchpad.net/bugs/327863 [00:04] the bugs may be related [00:04] psyke83: which version of ubuntu are you on? [00:04] Karmic [00:04] psyke83: do you want to try the xulrunner from my ppa which fixes that other bug? [00:04] micahg: I tried a daily build of 3.6 a few days ago - the text box issue was fixed, but the edge clicking wasn't [00:05] sure, what's the address? [00:05] https://edge.launchpad.net/~micahg/+archive/mozilla-test [00:07] micahg: thanks, will get back to you in a few minutes, need to make a phone call [01:01] psyke83. you'll need dload and dpkg the deb manually since it's behind main. [01:04] LLStarks: that's not true [01:04] you can go into aptitude and select it manually [01:05] but that can break things. [01:05] LLStarks: nope [01:05] NAFAIK [01:07] micahg: yes, apt-get or synaptic will try to remove the ffox gnome support packages, but it's no problem, I manually installed [01:07] the issue is fixed [01:07] I'm going to install the patched version of gtk to see if edge scrolling works in firefox and other apps, brb [01:13] micahg: ok, your patch works perfectly :) [01:13] psyke83: LLStarks found it [01:13] I just built the package [01:13] or rather uploaded it [01:13] ah, well, thanks to LLStarks as well :) [01:14] this issue may be related tangentially: bug #422511 [01:14] no problem. [01:14] Launchpad bug 422511 in gtk+2.0 "problem with new scrollbar in Human theme - GtkRange::trough-border set to 2" [Medium,In progress] https://launchpad.net/bugs/422511 [01:20] psyke83, why would the extra pixels matter? [01:21] if i want to scroll, i'm most likely to go the extreme edge of the screen. [01:23] LLStarks, that's the problem, you can't do that [01:23] i can. [01:23] LLStarks: what theme? [01:23] human default. [01:23] latest updates. [01:23] do you have a grey scrollbar? [01:24] colored. [01:24] something is wrong, then [01:24] multiple people have confirmed this issue [01:25] the bug is that you can't click the edge and scroll, right? [01:25] i can't do that in firefox though. [01:25] only nautilus. [01:25] LLStarks, yes, that's it [01:25] https://bugs.launchpad.net/firefox/+bug/422511/comments/7 [01:25] Launchpad bug 422511 in gtk+2.0 "problem with new scrollbar in Human theme - GtkRange::trough-border set to 2" [Medium,In progress] [01:26] works in evolution. [01:26] and nautilus [01:26] and other gtk-based apps i suppose. [01:26] hmm, no-go with gnome-terminal [01:27] will the patch allow this for all apps? [01:27] LLStarks: there's two problems. Forget Firefox for a minute. In all applications, if you edge-click it works, but does not grab the scrollbar. The patch fixes the scrollbar grabbing issue [01:27] in Firefox, no clicks are registered at all [01:28] grab the scrollbar? you mean literally grab the bar? [01:28] or just register a click event? [01:28] LLStarks: the patch fixes all compliant applications. Firefox happens to have another bug in which it doesn't register edge clicks at all. [01:28] ok, do this: [01:29] open a nautilus window with enough files for it to scroll when maximized. Click on the right-edge *beside* the scrollbar. The expected behaviour is to grab the scrollbar, but what really happens is that it thinks you clicked the scrollbar background and jumps up/down [01:32] ah [01:35] I was hoping that the bugfix you found would possibly fix up the trough issue with the scrollbar (so that Firefox would register *any* clicks, even if it's incorrect), but it seems not to have helped [01:35] is this a gtk issue? [01:36] there's two issues - one in gtk (proposed fix available which works), and one in Firefox (no clicks register at all) [01:38] did you file a firefox bug? [01:38] cuz it's still broken in the 3.7 alphas. [01:41] not yet, I only noticed recently that Firefox's behaviour differed from other apps [01:43] i could file a bug, but i'm not sure how to best describe the issue. [01:50] thanks, I'll file the bug :) [02:27] asac: didn't you just accept a merge to demote ubufox to recommends? (https://code.edge.launchpad.net/~gnomefreak/firefox/firefox.dev/+merge/9113) [02:28] asac: I meant suggests [02:28] hmm. i thought i did that to -gnome-support only [02:28] remind me to back that out tomorrow ;) [02:29] its not needed anymore now that there is apturl-kde [02:29] also i am quite concerned that ubufox doesnt work on livecd ;) [02:29] s/that/whether/ [02:29] asac: indeed [02:30] I brought that up 2 releases ago [02:30] bug me more about that ;) [02:30] ok [02:30] so LLStarks confirmed that bug fixed [02:30] not sure why i missed it [02:30] so I'll propose a merge later [02:31] why is gnome-support optional now? [02:31] doesn't gdebi need it? [02:31] because kde folks complained [02:31] but now deb links can't be opened. [02:31] so ubuntu desktop install has it installed by default [02:32] yeah. mime type integration is good to have with gnomevfs. but that is a bit buggy too afaik. 3.6 should be better [02:34] can't ubufox fulfill gnome-support's function? [02:34] or is it plugin finder only? [02:34] its not a native extension - and better keep it that way [02:34] so cannot do that [02:34] also, ubufox should be linked with apt and not rely on manual installations [02:34] i have other ideas for karmic+1 [02:35] but too late to discuss that now ;) [02:35] linked with apt? [02:35] apturl is the right thing [02:35] let's say i need flash, ubufox installs it [02:36] yes. but why not use apturl [02:36] i used apt as a catch-all [02:36] its there. its easy. no need to reinvent the wheel [02:36] ubufox shouldn't lead me to the flash installation page or simply fail to find the proper plugin. [02:36] apturl supports more stuff like auto adding repos on demand etc. [02:37] ubufox does not lead you to the flash installation page [02:37] it shows you the plugin finder [02:37] i've tried on 2 fresh installs this week and ubufox failed to install flash and other plugins [02:37] the database isnt updated ;) [02:37] or asked for manual [02:37] so its empty for karmic atm [02:37] ah [02:37] go to about:config [02:38] that makes sense [02:38] search for pfs. [02:38] and edit those [02:38] replace 9.10 with 9.04 [02:38] (at the end of those lengthy urls) [02:38] should be two pfs. urls [02:39] go to video.google.com [02:39] etc. [02:40] some sites do tricks and never try to display flash content if there is no flash plugin [02:40] thats why you sometimes dont get the finder [02:40] but thats out of hands [02:40] youtube is unfortuantely an example [02:40] at least adobe provides apturl on their download page now [02:40] afaik [02:42] asac: should I comment on that merge that you wanted to back out? [02:44] asac, they do? [02:45] link? [02:45] no time [02:45] micahg: yes. thx [03:01] LLStarks: I proposed the merge [03:01] i got the mail :) [03:02] ahg [03:02] i hope that bug 422511 won't require bugging the firefox devs and push for priority. [03:03] Launchpad bug 422511 in gtk+2.0 "problem with new scrollbar in Human theme - GtkRange::trough-border set to 2" [Medium,In progress] https://launchpad.net/bugs/422511 [03:04] the only reason 327863 is getting fixed is because the bug was elevated through exposure and because i took ownership in tracking down the fix. [03:06] LLStarks: well, it's the same story in Mozilla as it is in Ubuntu...we're limited on resources [03:07] when you think about, as a person who nothing aside from basic python, i was the person least likely to get the bug fixed. [03:07] *who knows nothing [03:07] LLStarks: everyone starts somewhere :) [03:09] it's not only a lack of resources, it's a lack of enthusiasm. [03:09] I don't know about that [03:09] there are a lot of people geared up [03:09] some just afraid to take the plunge [03:09] you have to be forceful and follow through with bug reports. otherwise they just sit and gather dust. [03:14] LLStarks: if you want to go for another one, I can package it for you [03:15] i can certainly try. i seem to have a knack for being a liaison. [03:23] micahg, i think psyke83 and asac are trying to elevate it. [03:24] conn too. [03:24] cool [03:45] fta: ping [03:57] this damn ppabot, why is it doing this crap! pbuilder has no issue with these rules.... dammit, I'm sick, my head hurts, I can't deal with this right now [03:59] fta: I'm leaving, if you can figure out what's wrong, email me. All my libmpdclient packaging is in the gmpc-trunk team branches. [04:08] <[reed]> I haven't seen a bug filed upstream on 422511 [04:09] <[reed]> I wouldn't be surprised if Firefox's code had a bug in it, but unless people report problems, they won't get fixed [04:10] LLStarks: ^^^ [04:11] brilliant. [04:11] part of it was fixed, part of it wasn't [04:12] [reed]: the display was fixed with mozilla bug 486065, but the clicking was not [04:12] Mozilla bug 486065 in Layout: Block and Inline "hidden scrollbars get drawn anyway when Gtk theme gives scrollbars borders" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=486065 [04:20] micahg. https://bugzilla.mozilla.org/show_bug.cgi?id=519609 [04:20] Mozilla bug 519609 in General "Click events are not registered on the right edge of a scrollbar when using a GTK theme with a trough-border greater than zero." [Normal,Unconfirmed] [04:20] great, can you update the LP bug? [04:25] LLStarks: nm, I did it [08:58] hi [09:01] hey sevoir [09:01] asac: should be able to work on bindwood this afternoon all hell has broken loose at the start of this week [09:02] Can anybody help me? I have 2 bug report with [packaging-need] label. https://bugs.launchpad.net/ubuntu/+bug/422206, https://bugs.launchpad.net/ubuntu/+bug/422208 [09:02] Launchpad bug 422206 in ubuntu "[needs-packaging] firefox-ubuntu-hu-menu" [Wishlist,New] [09:14] sevoir: i would package it but never packaged before so i would need asac's or someone else who knows how to help me [09:15] xpi packages are done [09:15] ahhh so you already have it packaged just need it uploaded === asac_ is now known as asac [09:16] Where? :) [09:16] launcpad ppa? [09:19] I packaged from older versions, but I dont know that these deb packages is okay? : http://www.sevoir.hu/firefox-extension/ [09:21] im the wrong person to ask sevoir [09:21] sevoir: you are better off asking asac [09:21] morning asac [09:22] okay. [09:22] asac please ;-) [10:02] ripps, i'm willing to help you but i need the full logs to locate the problem [10:04] fta: okay, I'll make an empty commit and pastebin the output. Do you want a direct console 2>&1, or do you want the output from -e [10:04] -e should be enough, it's supposed to contain everything [10:05] if you also see something in the console, please pastebin it [10:06] fta: did you see the pastebin I posted last night? [10:06] hm, no [10:07] http://paste.ubuntu.com/281276/ [10:08] d'oh! ugly [10:08] The cdbs in this package is nearly identical to other packages, but this package is the only one that does this. [10:09] i definitely need the logs [10:09] okay, i just experienced an error while running daily.sh -e [10:09] Can't locate MIME/Entity.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at -e line 2. [10:10] BEGIN failed--compilation aborted at -e line 2. [10:11] you need libmime-tools-perl [10:11] morning fta [10:12] morning [10:13] okay, trying again [10:13] sevoir: we need bzr packaging branches for those extensions [10:14] okay, I will create bzr packagig branches [10:15] btw. the url you posted does not exist ;) [10:17] yes, because I updating deb packages for new versions ;-) [10:18] Dang, nothing werid happened this round, because daily.sh thought it built the packages last time... recommiting. [10:22] asac, if it's NEW here it should be uploaded on Debian [10:24] ripps, could you diff -r your .head branch and one of the .head.ppa.xx branch ? i guess d/control is weird [10:26] fta: daily.sh buildlog: http://paste.ubuntu.com/282002/ [10:27] av`: yes [10:27] asac, maint should be set to pkg-mozext [10:27] asac, and it should be pushed to git on alioth [10:27] i dont know [10:27] no [10:27] fta: diff -r *.head *.head.ppa.karmic: http://pastebin.com/f347e39c7 [10:28] why not? [10:28] why? [10:28] why not push that to bzr? [10:28] alioth is not a professional service. i lost all my data once ;) [10:28] ripps, gasp, something's wrong.. it's not supposed to touch the "Package: libmpdclient-dev" line [10:28] +Package: libmpdclient-dev (>= 2.0.0~git20090930.275b256-0ubuntu1~ripps2) [10:28] depends if that extension will be team-maintaned or not [10:29] av`: we have a team on our own here. i am not here to merge teams [10:29] if debian wants to run their own team thats great [10:29] anyone can join that team [10:29] fta: the control was made by dh_make, but then I just filled in all the necessary info, why is it trying to mess with -dev? [10:29] but its definitly not a policy [10:29] asac, m-d is actually a policy [10:30] asac, binaries renames are too [10:30] waitaminute, dh_make listed the -dev before the normal package... why'd it do that? [10:30] av`: thats a policy yes. but i talked about a team policy [10:30] you can either use the mozilla-extension-dev team in ubuntu [10:30] or something else [10:31] asac, yeah, but I thought that pushing it to debian would have moved the maintainer to our debian team [10:31] fta: should I just but -dev after the normal package? or is that irrelevant? [10:31] no [10:31] as far as we gonna keep in sync [10:31] we maintain stuff here, but upload to debian. [10:32] ok, fine for me, it's your decision in the end [10:32] well we === some of us. [10:32] everyone can do what they want. [10:32] yeah, sure [10:32] all i am saying is that i wont take care about extensions not maintained in launchpad.net/firefox-extensions project [10:33] yeah, but well, an extension can be maintained on bzr without problems [10:33] yes [10:33] having the debian team watchint it would be better for everyone [10:34] debian folks are invited to join the launchpad team [10:34] yep [10:34] i assume they will do that [10:34] will not do that [10:34] ripps, where is the .head branch? [10:34] because they are too scared to entangle with ubuntu folks [10:35] fta: on my computer or on launchpad? [10:35] lp [10:35] asac, I'm already into the team and I started working on Ubuntu first than debian [10:35] asac, so I'm not scared to entagle with ubuntu guys (i am one too) ;) [10:36] https://code.edge.launchpad.net/~gmpc-trunk/+junk/libmpdclient.head.ppa [10:36] asac, the only thing I wanted to propose it to set the maint to the team, so that we can monitor any extension that will pushed into debian [10:36] https://code.edge.launchpad.net/~gmpc-trunk/+junk/libmpdclient.trunk [10:36] asac, if it will stay on bzr, fine [10:37] you can use the ubuntu extension team as maintainer for stuff that is maintained in that team [10:37] if you maintain stuff in some other team you can use that team, yes. [10:37] we didnt do that for other extensions [10:37] maint is set to ubuntu devs [10:37] in the past we used MOTU [10:37] we used it too [10:37] simply because thats the group of folks that can upload [10:37] now [10:37] and we didnt have many MOTUs [10:38] but we already started to move away from that approach [10:38] there is no checklist point about moving the maintainer [10:38] afaik the last few extensions are not in ~ubuntu-dev, but ~mozilla-extensions-dev [10:38] also because the team doesnt have an official ML [10:38] av`: no. because i didnt perceive this as a problem. [10:39] you can use the same mailing list as ubuntu dev [10:39] we shared devel-discuss for core dev an motu in the past [10:39] yes, but mixing messages is not the best [10:40] but anyway it's your choice, np [10:40] ripps, found the bug. "sed -i -e '1,/^Package: /s/\(libmpdclient-dev\)[^,]*/\1 (>= 2.0.0~git20090930.275b256-0ubuntu1~ripps2)/' debian/control" is supposed to change only the "Source:" section, but it also matches the 1st line of the 1st Package section, which happens to be a package you explicitly asked the bot to "version" in your 'deps'. So the quick workaround is to move that -dev package further below [10:41] asac, where is gnomefreak? I'm moving flashgot to the team, wanted to update him [10:41] av`: i am not against it in general. the main point i am seeing is that it doesnt make sense to fragment the ubuntu mozilla community [10:41] which is why i always said that we dont neeed a separate channel on oftc [10:41] first let the debian team/ubuntu team grow substantially [10:42] asac, if you want I can add the bot here [10:42] then look into making that a separate team with everything [10:42] the channel is mainly for that [10:42] what bot? [10:42] commits bot [10:42] commits where? [10:42] commits made on extensions [10:42] on git [10:42] I guess there is one for bzr too [10:42] yes. but we dont use that [10:43] i dont think such a bot is really helpful. but if you can find one then thats fine [10:43] fta: okay, let's see how it goes this time *crosses-fingers* [10:44] asac, unluckily bzr one is a bit complex, and it needs to get hooks added on the server [10:44] asac, it would be nice to have that implemented in LP [10:45] fta: woot! it's uploading [10:46] great [10:46] i need to run now, cu later [10:46] asac, problem is that, as you said, debian guys won't join #mozilla-team on freenode, I guess [10:49] double woot! it built correctly! [11:38] sevoir: check out https://wiki.ubuntu.com/MozillaTeam/Extensions/Packaging [11:40] ohh, great [12:01] sevoir: sry i could have been of more help [12:01] asac helped me [12:03] I hope I create good standard ubuntu firefox extension pack :-) [12:03] :) hes great guy to have in the community [12:03] sevoir: if not you can always retry :) [12:03] thats how one learns [12:04] First package for me ;-) [12:05] :) well i have packaged bindwood extension for firefox thats my first and im still learning [12:06] xpi package is routine, but it is difficult a bit. I'm happy that I will learning this procedure ;-) [12:07] sevoir: to backage you could use bzr bd to build the package for testing on ur local machine [12:07] then upload it somewhere [12:07] bzr is done [12:07] :-) [12:07] asac: once i get bindwood fixed and working and tested and i package it using bzr bd where do i upload it too [12:07] sevoir: test it out before uploading :) make sure things work if not time to tweak it lol [12:08] eagles0513875: you push your branch to your private location and ask for a merge to the release branch (~ubuntu-dev afaik) [12:08] gotcha asac :) [12:08] hopefully after part 2 of my linux cert i can work on finishing it up this afternoon === jtv is now known as jtv-afk [12:09] k [12:09] eagles0513875: sure, I dont want publish not working version :-) [12:10] asac: going nuts atm starting lectures and all but hopefully once i get this linux cert done this afternoon ill get into a routine === jtv-afk is now known as jtv [13:21] asac: you there? [13:23] sindhudweep: yep [13:24] hi [13:24] hi [13:24] so first a couple of prerequisites. [13:24] I can't seem to get pbuilder to build the current source package for gnash. [13:26] http://pastebin.com/d4ec46bb6 [13:29] sindhudweep: maybe your pbuilder does not have all the apt sources required? [13:29] Depends: libagg-dev which is a virtual package. [13:29] that feels like you only have "main" [13:35] my apt sources for the machine certainly has universe. How do i set the sources for the chroot that pbuilder will use? [13:37] hi asac, adiroiban, the Romanian translation team leader is telling me that the Romanian translations in Firefox are still the upstream ones in Karmic. Have there been any changes in the whitelisting? [13:38] during the dev cycle [13:39] looking at xulrunner I can see there are 2 source packages in Ubuntu [13:39] https://translations.edge.launchpad.net/ubuntu/karmic/+source/xulrunner-1.9.1 [13:39] https://translations.edge.launchpad.net/ubuntu/karmic/+source/xulrunner-1.9 [13:46] dpm: yes. all should be from launchpad [13:46] dpm: except those that have a country code [13:47] we tried to import all translations from xulrunner (1.9) to 1.9.1 and firefox 3.0 to 3.5 [13:47] i thought that worked [13:48] I did not really notice it in Catalan, because we translate upstream, but I think adiroiban is involved both upstream and translates FF in LP as well [13:48] ok. so we should migrate 1.9 -> 1.9.1 and firefox 3.0 -> 3.5 [13:49] asac: I will also test with other languages and see if LP changes are updated with language packs [13:50] adiroiban: what do you mean by migrate? [13:51] rename [13:51] adiroiban: we did that when we opened translations [13:51] and make sure no translations are lost [13:51] if you kept on editing 1.9 [13:51] talk to arne [13:51] ok [13:51] you need to reimport the stuff [13:51] not sure why there is a xulrunner-1.9 at all ... we used an unversioned one for 1.9 iirc [13:52] hmm maybe arne renamed that [13:52] think we discussed that yeah [13:52] in Karmic we still have Firefox 3.0 ... but as you say [13:52] I will talk with Arne and sort this out [13:52] this cycle was more like a test cycle for devmode etc. [13:53] we will go for translations that have upstream translations to the upstream translations for final [13:53] Firefox 3.0 is on the top of the templates list [13:53] and keep those that are good whitelisted that dont have an upstream translation [13:53] next cycle we will start with devmode right away [13:53] ok [13:53] and work on getting upstreaming procedures done [13:53] adiroiban: I don't think we need anything renamed, we've got both ff3.5 and 3.0 templates, we should disable the 3.0 at some point [13:53] so we have xulruner-1.9 and firefox 3.5 [13:53] your case is a bit difficult though [13:53] we probably need innovation there [13:54] dpm: i think he ment that he wanted to get all the translations to the 3.5 template ... technically we need to export 3.0 and import that to 3.5 [13:54] asac: can we disable the FF3.0 template already? [13:54] dpm: ok. but right not ff 3.0 has top priority and 3.5 0 [13:54] we did that [13:54] adiroiban: I know [13:54] dpm: we should. but we should first ensure that everything is properly ported. [13:54] reimported [13:55] yep [13:55] also in future there will be multiple versions [13:55] in karmic we will remove ffox 3.0 completely [13:55] the current firefox 3.5 is pure upstream [13:55] but thats not the case in all cycles [13:55] and it does not contain the changes made for 3.0 [13:55] especially if we release right after final users often want the old firefox [13:55] adiroiban: yes. we imported all upstream translations [13:55] right [13:55] and then the other on top [13:55] if we disable firefox 3.0 right now. we will lost all changes made in LP [13:56] yes. we should take care that those get properly taken over [13:56] this is why I was talking about migrating those changes from 3.0 to 3.5 [13:56] but I will talk with Arne about those changes [13:56] yes. its not a rename though. its an export + produce .xpi + import [13:56] adiroiban: disabling it does not remove the translations from the database. In any case, what we should do is to give FF3.0 a low priority and FF3.5 a higher one [13:57] adiroiban: do you see your changes in ffox 3.0? [13:57] in the templates list, I mean [13:57] yes [13:57] dpm: yes. please do the priority thing [13:57] dpm: I will change the priority [13:57] as I'm already working on that [13:57] shouldnt that be done for the whole template? [13:57] adiroiban: ok, thanks [13:58] do you ahve powers to change the whole template? [13:58] yes [13:58] good [13:58] asac: yes, adiroiban is also in the ubuntu-translation-coordinators team [14:02] done. firefox 3.5 and xulrunner 1.9 are now on top [14:02] 1.9.1? [14:02] adiroiban: ` [14:02] ? [14:02] 1.9.1 is now with priority 0 [14:02] guess was a typo :) [14:03] adiroiban: 1.9.1 should be on top [14:03] 1.9 at bottom [14:03] ffox 3.5 on top ... 3.0 at bottom [14:03] ah [14:03] ok [14:03] 1.9.1 + 3.5 belong together [14:03] thx [14:04] kenvandine: recreating the proxies does not work? [14:04] bus = dbus.SessionBus() [14:04] db_mb_obj = bus.get_object("com.Gwibber", "/com/gwibber/Microblog") [14:04] asac, no [14:04] db_msg_obj = bus.get_object("com.Gwibber", "/com/gwibber/Messages") [14:04] ... [14:04] like factoring that out to a "client_connect" [14:04] which is weird [14:04] kenvandine: thats odd. it works in C at least ;) [14:04] yeah :) [14:04] kenvandine: maybe the session bus caches that? [14:05] there is definately some weirdness going on [14:05] asac: true. done [14:05] i also tried an argument to get_object that follows name changes, so if the daemon restarts the client should follow it [14:05] but it doesn't work either [14:05] so either we are doing something wrong in our dbus code [14:05] adiroiban: you could zip up the current 3.0 and 1.9 addon tree [14:05] or python-dbus is busted [14:05] adiroiban: and import that [14:07] kenvandine: can you write a quick mini client that just pulls messages? [14:07] yep. Hope the xpi merge is working ok. I will start by importing only the ro_RO translations [14:07] kenvandine: like every 2 seconds iterate through messages and then one can debug this in a confined space [14:07] asac, i am going to write a quick test case un-related to gwibber [14:07] to isolate the problem [14:07] i would think that NameOwnerChanges might be too late [14:07] like: [14:07] a) send a query [14:08] b) NameOwnerChange [14:08] c) recreate proxies [14:08] d) error from query is still coming [14:08] true [14:08] so just NameOwnerChange isnt enough ... but i guess thats obvious [14:08] yeah [14:08] but in the case where both client and daemon are idle [14:08] follow_name_owner_changes = True [14:09] if the daemon restarts [14:09] adiroiban: asac, Adi is mentioning the ro_RO translations. Could it be that the problem with Romanian translations was because of the country code? [14:09] i would expect the client to follow it [14:09] how is name_ower_changes to work? [14:09] throw special exception "e.g. EAGAIN" [14:09] while its redoing the connection? [14:09] get_object should handle it for us [14:09] i found several examples that seemed straight forward [14:09] but all in C [14:09] dpm: the country code is only an issue if the exported .po files have that [14:10] like es-ES -> broken [14:10] fi -> works [14:10] ok [14:10] i think ro get exported as ro.po [14:10] asac, so abstracting it away from our program completely... which is really ideal [14:10] dpm: and he confirmed that it works on 3.0/1.9 [14:10] but it doesn't seem to work in python [14:10] i am going to write a test case and make sure it isn't gwibber that is doing the wrong thing somewhere [14:10] so i assume its just that the changes they did were not properly carried over (or done after we did the migration) [14:11] kenvandine: what i mean is: how does call_blocking handle it ... just wait till it reappears? [14:11] or do we get an exception "currently down" [14:11] just waits i think [14:11] the C example i found did nothing to handle it [14:12] seemed the dbus api handled it under the covers [14:12] ah... ignore the ro_RO... ro is ok :) [14:12] i want to repro it with a much simple test case [14:12] gwibber is way to complex to be sure [14:12] kenvandine: i would think it would be simple enough to call "messages" on gwibber ;) [14:12] kenvandine: ok [14:13] we dont use blocking calls in NM so i cannot tell how well that _can_ work for the name_owner changes. i would expect that it doesnt guard you from all exceptions [14:13] although following name changes isn't the only thing we need [14:13] which means using it doesnt really help ;) [14:13] as its just a NameOwnerChange signal you need to handle [14:13] the biggest problem is we have blocking calls in both the client and the daemon [14:13] so they can get into a state where they are both blocked [14:14] yes. deadlock [14:14] kenvandine: daemon shouldnt call client ... does it? [14:14] and that is usually triggered by that crazy urllib2 problem with facebook [14:14] it does [14:14] besides from replies7signals [14:14] it has too... [14:14] well [14:14] signals feels like what is needed ;) [14:14] we raise the client via dbus [14:14] so it can work with stuff like the indicator [14:15] but that can be async for sure [14:15] and if the client isn't running, we need dbus to start it [14:15] so more than a signal [14:15] yeah [14:15] that part is, i think [14:15] ryan has been chasing a bug in the facebook module [14:15] it hangs on some calls in urllib2 [14:15] it never times out [14:15] and it blocks [14:16] that is really what is triggering most of the hangs we are seeing [14:16] yeah ... its a bad practice to use blocking IO in the first place ;) [14:16] yeah [14:16] i was ranting about that a few month back [14:16] but seems python is just inferior for these kind of things [14:16] ryan seems to think we need it there [14:16] i guess that is why [14:16] well [14:16] we should be able to work around that [14:16] i wouldnt say that. but async IO design software is much cleaner ;) [14:16] thats my opinion :) [14:17] i think he is getting burned out with python :) [14:17] have a main loop ... and event driven flow ;) [14:18] well. cant be true that python sucks so much ;) [14:18] though i obviously prefer C ... but i think for gwibber with its plugin arch pythong should be better [14:18] though now we crash even more because the transparent wrapping of the dbus calls [14:18] yeah... i think he hits too many things that aren't as mature in python [14:18] doesnt really provide incentives to do proper error handling [14:19] i wouldn't be surprised if gwibber 3 was C or C++ (he is getting into qt stuff) and extendable with python [14:19] at least the core of the daemon in C [14:19] we'll see :) [14:20] i prefer keeping it in python and make it cleaner [14:20] from what i was told he isnt really an experienced/main-profession developer ... if thats right i dont think that C will help much ;) [14:20] he has gained lots of experience now... but it isn't his profession for sure [14:21] i want to try to prevent major over hauls ever 6 months :) [14:21] yeah [14:21] just make what's there more robust and simplere [14:22] your -daemon work at least got rid of the ugly new Thread ;) [14:22] things [14:22] or are you running multiple threads still? [14:22] hmm i guess you do on daemon side at least [14:22] aka blocking IO needs that [14:22] yeah [14:42] asac: the changes for gnash 0.8.6 are available: https://code.edge.launchpad.net/~gnash/gnash/ubuntu.head. I'll hold off on merging https://code.edge.launchpad.net/~sindhudweep-sarkar/gnash/KDE4packaging till tomorrow or post release [14:42] email me if you hit any issues as i won't be available via irc. [15:05] asac, well my much simpler test cases handles the NameOwnerChange with follow_name_owner_changes = True [15:06] with no exception handling on my part [15:06] so clearly something weird in the gwibber code [15:19] kenvandine: can you post your testcase ;) [15:20] i figured out why the follow example isn't working in gwibber [15:20] no mainloop set for dbus [15:20] that is an easy fix [15:20] yeah [15:20] now i am adding exception handling to my test case [15:20] when i am happy with that i will do it in gwibber :) [15:22] bye all [15:22] sevoir: bye. did you manage to get something? [15:22] yep [15:22] following instructions= [15:23] ? [15:23] cool. once you want feedback on that push yuor branch somewhere [15:23] I created deb package locally [15:23] I will test at home [15:23] :-) [15:24] I will come back tomorrow [15:24] Maybe with good news :) [15:24] thx for all information [15:24] bye [15:52] asac: guess what :) [16:33] hi all [16:33] Is the right place to post some thunderbird launch pb ? [16:34] It start one, but I cannot write msg, and then never starts again until I restart session [16:35] jdstrand: how to disable sbin.dhclient3? [16:35] is that just creating a link in the disable folder? [16:35] (sorry, i forgot that again) [16:41] asac: to permanently disable, put a link in the disable folder [16:42] jdstrand: how to reload? [16:42] restart? [16:42] asac: to temporarily disable, do 'apparmor_parser -R /etc/apparmor.d/sbin.dhclient3' [16:42] to reload the profile: [16:42] If I run thunderbird under console I get this : + for curr_pis in '"${HOME}/${MOZ_USER_DIR}/init.d"/K*' '"${dist_bin}/init.d"/K*' [16:42] + '[' -x '/home/sli/.thunderbird/init.d/K*' ']' [16:42] + for curr_pis in '"${HOME}/${MOZ_USER_DIR}/init.d"/K*' '"${dist_bin}/init.d"/K*' [16:42] + '[' -x '/usr/lib/thunderbird/init.d/K*' ']' [16:42] + exit 0 [16:42] nah ;) ... i need permanently because i need dhclient to access stuff in my /home [16:42] apparmor_parser -r /etc/apparmor.d/sbin.dhclient3 [16:42] for my developmenet environment [16:43] asac: why not just add the files you need into the profile? [16:43] Well I have nowhere an init.d directory [16:43] jdstrand: because then i dont get the latest without either merging or loosing ;) [16:43] jdstrand: or is dhclient now stable enough? [16:43] asac: you don't need to reload if you use '-R'. if you don't, use /etc/init.d/apparmor force-reload [16:43] what is -r? remove permanently? [16:44] asac: the dhclient profile hasn't changed since early in the cycle [16:44] asac: -r is 'reload' the profile [16:44] -R is remove the profile [16:44] why did I do such stupid update under ubuntu 8.10 [16:44] jdstrand: does that install a link or remove the file? [16:44] asac: neither [16:44] jdstrand: may i suggest to rename that to aa-client or something? ;) ... i wouldnt have looked at the features of parser [16:45] asac: those are both temporary [16:45] jdstrand: ah right temporary [16:45] ok [16:45] asac: to permanently disable, you must manually link into disable/ [16:45] asac: and then use either -R to unload the profile, or smash it with a sledgehammer and reload all of apparmor with the initscript [16:45] ok but i cannot use -r to just reload [16:46] kk [16:46] tried just -r ... that complained [16:46] * asac tests [16:46] asac: -r is used for reloading a profile that you may have modified. for what you seem to be trying to do, it isn't what you want [16:46] great ;) i got a lease [16:47] i want aa-client reload|disable|enable ;) [16:47] but now i am happy too ;) [16:47] asac: of course it is up to you, but I'd recommend modifying the profile for you needs [16:47] i see the point of not providing that [16:47] Ho good I had to kill thunderbird-bin [16:47] asac: im lpic level 1 certified [16:47] im happy as well [16:47] jdstrand: i will play around with it later. for now i disabled it ;) [16:47] eagles0513875: congrats [16:47] Why did the script not notified or killed the app by himself [16:47] asac: dhclient3 does run as root and it has had security issues (which is why we have the profile) [16:47] asac: sure thing [16:48] (just an fyi) [16:48] ty asac [16:48] thks for help :D [16:49] sli_: those things in the script are not a problem normally [16:51] ok have to prepare for travel [16:51] bbi 3 hours or so [16:53] ok asac [19:38] [reed], ff3.7 is really unusable [19:38] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [19:38] 21847 fta 20 0 1076m 420m 28m R 29 20.9 1638:35 firefox-3.7 [19:38] <[reed]> I'm not seeing this [19:39] <[reed]> hmm [19:39] that's with no addon (expect abp) [19:39] it's really slow when i type in textareas [19:39] <[reed]> or, maybe I can [19:40] <[reed]> er, I am [19:40] <[reed]> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [19:40] <[reed]> 4264 reed 20 0 1046m 411m 34m S 29 20.9 1244:44 firefox-bin [19:40] yeah [19:40] my cpu fan is never quiet, that's unbearable [19:40] moving to chromium [19:41] <[reed]> I'll take a look at it later [19:45] asac: a reminder to back out that change from ff3.5.head [21:38] asac, ping? [21:39] asac, RE https://bugzilla.mozilla.org/show_bug.cgi?id=486065#c60 -- I've generated a try-server build of 1.9.1 + patch for that bug + the followup patch that dbaron mentioned [21:40] Mozilla bug 486065 in Layout: Block and Inline "hidden scrollbars get drawn anyway when Gtk theme gives scrollbars borders" [Normal,Resolved: fixed] [21:40] asac, build is at https://build.mozilla.org/tryserver-builds/dholbert@mozilla.com-try-b28226f038b0/ [21:41] asac, could you (or someone who's hitting the Karmic theme issue) test that build to confirm that it fixes the problem? [21:42] (n/m, posting on bug)