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