[00:37] <BUGabundo> fta apt url not working on 3.6?
[00:38] <micahg> apturl works because of ubufox
[00:39] <micahg> I believe
[00:39] <BUGabundo> realy?
[00:40] <micahg> yes
[00:40] <fta> does it even work in 3.5?
[00:40] <micahg> in karmic it should now
[00:40] <micahg> asac: released it
[00:40] <micahg> I had to roll it back because it screwed up flash foe
[00:40] <micahg> for me
[00:41] <BUGabundo> :(
[00:41] <BUGabundo> since it prob won't work on 3.6
[00:41] <BUGabundo> I can't use apturl
[00:41] <micahg> BUGabundo: you can try to override compatability and try it in 3.6
[00:41] <fta> $ ls -l /etc/firefox-3.*/pref/apturl.js
[00:41] <fta> -rw-r--r-- 1 root root 246 2008-03-28 15:44 /etc/firefox-3.0/pref/apturl.js
[00:41] <BUGabundo> last time it was a mess
[00:42] <fta> $ dpkg -S apturl.js
[00:42] <fta> apturl: /etc/firefox-3.0/pref/apturl.js
[00:42] <fta> apturl: /usr/share/firefox/defaults/pref/apturl.js
[00:42] <micahg> but ubufox is what works with apturl
[00:42] <BUGabundo> some one forgot to commit
[00:45] <fta> i remember i had to add support for ff3.0 last year
[00:45] <fta> bug 207281
[00:45] <fta> eh
[00:46] <micahg> looks like that's another thing we need to abstact out like the search plugins into a generic local
[00:46] <micahg> *locale
[00:48] <fta> i won't touch it, i think asac already has something in mind for that
[00:49] <micahg> right
[00:49] <micahg> I'll talk to him about it tomorrow
[00:51] <BUGabundo> one strange think I'm noticing
[00:51] <BUGabundo> I set my cookies to ASK
[00:51] <BUGabundo> I only have like 15 cookies on my FF
[00:51] <BUGabundo> but on deviantart.com/
[00:51] <BUGabundo> I get asked on every page if I want to save the cookie and in every I say NO
[00:52] <BUGabundo> why doesn't FF remember it?
[00:53] <micahg> because each page is a new subdomain
[00:53] <micahg> cookies can be per  domain or per subdomain
[00:54] <BUGabundo> :(
[00:55] <micahg> you can probbaly deny cookies for a certain domain if you want
[00:56] <BUGabundo> prob
[01:54] <EruditeHermit> fta: asac hey
[03:40] <e-jat> !ping fta ..
[08:00] <asac> hola
[08:00]  * asac back from the dead
[08:00] <asac> LLStarks: pong
[08:01] <asac> LLStarks: i dont know
[08:01] <LLStarks> you see it though, right?
[08:01] <asac> which ffox?
[08:01] <LLStarks> 3.6
[08:01] <LLStarks> nightly
[08:02] <LLStarks> from the ppa
[08:02] <asac> since when ?
[08:02] <LLStarks> a few days
[08:02] <LLStarks> 2-3
[08:02] <asac> havent updated my dailies for a few dys
[08:02] <asac> will do that now
[08:04] <micahg> hi asac
[08:04] <asac> hi micahg
[08:04]  * asac scrolls back
[08:04] <micahg> where should we move the user agent discussion if at all?
[08:07] <asac> micahg: you say folks still complaining about Shiretoko?
[08:07] <asac> still folks complaining? dont we have a bug where we can point them to?
[08:08] <asac> 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] <asac> that one is still ok
[08:08] <asac> now upgrading
[08:08] <LLStarks> 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] <LLStarks> yes, i know it's a bit franksteing
[08:09] <LLStarks> *stein
[08:09] <asac> now testing
[08:09] <LLStarks> but i do it for compat sake
[08:09] <asac> still upgrading ;)
[08:09] <asac> compat?
[08:10] <asac> i think this upgrade will take a bit; i get a coffee now
[08:18] <micahg1> asac: yeah, they;re complaining in the bug
[08:32] <micahg> asac: I don't know how to make it any clearer
[08:32] <micahg> should we keep going back and forth in the bug?
[08:37] <asac> i think its ok
[08:38] <asac> just dont feed them
[08:38] <asac> there is not much more we can tell
[08:38] <asac> we will soon enough make it firefox
[08:38] <micahg> just let them keep going back and forth them?
[08:38] <micahg> in Jaunty?
[08:39] <asac> i will think about it once we have it in karmic
[08:39] <micahg> :)
[08:39] <micahg> ok
[08:39] <micahg> so, what about the user agent stuff
[08:39] <micahg> should I report any more?
[08:40] <asac> hmm gone ;)
[08:41] <micahg> oh, also, gnomefreak make the debdiff for the ubufox is recommended problem
[08:42] <micahg> *made
[08:44] <e-jat> asac: would u mind to check this bug 401207
[08:44] <e-jat> it occurs for shiretoko n minefield
[08:52] <asac> asac: adobe reader?
[08:52] <micahg> we have the plugin in the partner repo
[08:54] <micahg> BTW, asac, just triaged a bug where FF3.5 won't quit on ext4
[08:54] <micahg> bug 400088
[08:55]  * micahg is off to bed
[08:56] <asac> micahg: sleep well
[08:56] <micahg> thanks :)
[08:56] <asac> micahg: where did gnomefreak put the debdiff?
[08:56] <asac> (for ubufox)
[09:38] <asac> http://src.chromium.org/viewvc/chrome/trunk/src/courgette/
[09:38] <asac> e-jat: epends on the the backtrace if its triaged
[09:38] <asac> let me look
[09:40] <e-jat> i follow the  wiki .. to debug it ..
[09:40] <asac> asked
[09:40] <asac> e-jat: please use ubuntu-bug firefox-3.5 to file bugs in future ;)
[09:40] <asac> that will attach loads of info that is helpful
[09:40] <asac> e-jat: i think you can run apport-collect now
[09:41] <asac> to attach that info as well
[09:44] <e-jat> yeah .. forgot about that .. doing the apport-collect now ..
[09:48] <asac> thx
[09:49] <e-jat> asac: im using adobe reader 9.1
[09:51] <LLStarks> asac, is the font smoothing bug present on your machine?
[09:52] <e-jat> LLStarks: font smoothing?
[09:55] <asac> LLStarks: let me check. upgrad should be there now ;)
[09:55] <LLStarks> thx
[09:55] <asac> so the profile dialog works as before
[09:55] <asac> no it work
[09:57] <e-jat> asac: from the full bt output .. where should i look the main cause it break?
[09:57] <asac> LLStarks: http://people.canonical.com/~asac//tmp/Moz36Jul20.png
[09:59] <asac> e-jat: do you always get this BadAccess error?
[09:59] <asac> buf = "BadAccess (attempt to access private resource denied)\0\0\0\0\0\0\0\0\0\0"
[09:59] <asac> probably you see the error on the console too
[10:02] <asac> mozilla bug 451944
[10:02] <asac> ouch
[10:02] <asac> mozilla bug 457157
[10:04] <e-jat> yeah .. i think it similiar :)
[10:04] <asac> e-jat: didnt apport-collect work?
[10:04] <asac> e-jat: its fixed
[10:04] <asac> it shouldnt be in 9.1 anymore i mean
[10:05] <e-jat> hmm so .. what shall i do now ? remove the plugin n reinstall ?
[10:05] <e-jat> for ff 3.0.11 its work well ..
[10:06] <asac> e-jat: and 3.5?
[10:06] <e-jat> crash .. same goes with 3.6
[10:08] <asac> 11:04 < asac> e-jat: didnt apport-collect work?
[10:11] <e-jat> asac: to collect info ?
[10:11] <asac> e-jat: to attach that to the bug
[10:11] <asac> like i asked you
[10:11] <e-jat> apport work ..
[10:11] <asac> 10:40 < asac> e-jat: i think you can run apport-collect now
[10:11] <asac> 10:41 < asac> to attach that info as well
[10:11] <asac> 10:44 < e-jat> yeah .. forgot about that .. doing the apport-collect now ..
[10:11] <asac> 10:48 < asac> thx
[10:12] <asac> there is not info on the bug yet
[10:12] <asac> bug 401207
[10:12] <e-jat> apport-collect data n dependecies already there
[10:15] <asac> e-jat: thats what apport collect attached?
[10:15] <asac> there should be a bunch of more stuff when you use ubuntu-bug firefox-3.5
[10:15] <asac> i thought apport-collect would run the hook like ubuntu-bug
[10:18] <e-jat> :(
[10:20] <e-jat> 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] <fta> hi
[10:20] <e-jat> it show long form fill
[10:20] <fta> asac, hey, glad you're back
[10:20] <fta> asac, some reading for you:
[10:20] <fta> Jul 18 19:19:33 <fta>   asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/5dfbadda21300b37#
[10:20] <fta> Jul 18 19:20:02 <fta>   asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/5bd9d185a45f81ba#
[10:20] <fta> Jul 18 19:35:39 <fta>   asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/aabc1472bf19b2f5#
[10:21] <fta> Jul 19 02:15:52 <fta>   asac, funny.. http://codereview.chromium.org/155558
[10:21] <fta> Jul 20 00:25:32 <fta>   asac, http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium :(
[10:27] <TomJaeger> Hi asac, can we talk about bug #217908 again?
[10:27] <TomJaeger> Jeff has reviewed the patch I posted now
[10:28] <asac> fta: thanks. i had to get out over the weekend
[10:28] <asac> and then had no chance to look back ;)
[10:29] <TomJaeger> 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] <asac> heh
[10:33] <asac> fta: thanks for those first three pointers
[10:36] <asac> " Flash calls gtk_widget_modify_bg from an expose handler"
[10:36] <asac> hear hear
[10:36] <asac> +
[10:36] <asac> +// Flash calls XGetWindowAttributes with a NULL display, which crashes.
[10:36] <asac> +// So we intercept that function and make sure the display is set.
[10:37]  * asac wonders if those were filed upstream
[10:38] <asac> fta: do yo uknow if they work with adobe on such things?
[10:38] <fta> i think they do, did you read the comments below the patch?
[10:42] <fta> asac, http://paste.ubuntu.com/222582/
[10:44] <reed> asac: we (Mozilla) do report bugs to Adobe
[10:48] <fta> why does it suck so much then?
[11:00] <asac> reed: those are chromium hacks
[11:01] <asac> reed: we actually thought about using libjpeg from mozilla as the new system jpeg
[11:01] <bluekuja> asac, hi
[11:02] <asac> reed: because we think that  mozilla did the last optimizations on that otherwise dead upstream
[11:02] <asac> but we ended up in crashes. you think it makes sense to file bugs about that?
[11:02] <asac> bluekuja: h
[11:02] <asac> i
[11:03] <bluekuja> asac, we fixed the startup already on the first revision but my co-maint forgot to push them
[11:04] <bluekuja> asac, but now it's ok, fixed them and tried it out on pbuilder
[11:04] <reed> asac: sure, feel free
[11:04] <asac> bluekuja: so thats the thing i wanted to sponsor, but then someone else did?
[11:04] <reed> I do know there are some libjpeg patches still in bugzilla
[11:05] <reed> that need to land sometime
[11:05] <bluekuja> asac, nope, it was cgmail
[11:05] <bluekuja> asac, we did so much changes on it (like 30+ lines changelog)
[11:06] <asac> reed: right. mozilla jpeg didnt really look more un-dead then upstream, except that moz has more patches on top :)
[11:06] <asac> bluekuja: why wasnt it tested?
[11:06] <bluekuja> asac, so we lost the change related to startup (e.g changing final dir to /usr/share/cgmail/stuff
[11:06] <bluekuja> asac, it was tested, but we had it working
[11:07] <bluekuja> asac, we had a working branch
[11:07] <asac> well.
[11:07] <bluekuja> asac, but we forgot to push the change related to startup
[11:07] <asac> why wasnt the bzr revision i was given tested?
[11:07] <asac> why did it work?
[11:07] <asac> is this a corner case?
[11:08] <bluekuja> asac, nope, we fixed the startup error and we had it working (as u can see in the changelog)
[11:08] <bluekuja> asac, but those changes weren't pushed to the branch
[11:08] <asac> why "we"
[11:08] <asac> i didnt test it at all
[11:08] <bluekuja> (maybe my co-maint forgot to do it)
[11:09] <bluekuja> we = me and my c-maint
[11:09] <asac> right. so the revision i was given wasnt tested ;)
[11:10] <bluekuja> asac, looks like we tried out our files
[11:10] <bluekuja> asac, which were working
[11:10] <asac> ok
[11:10] <bluekuja> asac, and maybe we forgot to push the changes we test directly to the branch
[11:10] <asac> i dont understand how that can happen with something packaged though
[11:10] <asac> how can two guys test the same without pushing?
[11:11] <bluekuja> asac, maybe we got confused with the huge changelog
[11:11] <bluekuja> asac, a lot of changes
[11:11] <asac> anyway. it just means the revision released wasnt tested ;)
[11:11] <bluekuja> asac, and we lost some pieces around
[11:11] <asac> which is bad. but we will get over it
[11:11] <asac> the bug is marked pending.
[11:11] <bluekuja> asac, yep
[11:12] <asac> you should always add changelog entry in the same commit you do the change
[11:12] <asac> in that wy you know that changelog reflects what is in the branch
[11:12] <asac> edit changelog, then use debcommit
[11:12] <bluekuja> asac, oh ok, I was used to first do the change and then update the changelog on the other rev
[11:13] <bluekuja> asac, anyway if you have unstable there, after you built the package, just install it and run it from console
[11:13] <bluekuja> asac, it *will* work
[11:14] <asac> i dont want to test anything. i expect any sponsoree to submit stuff that works :)
[11:15] <bluekuja> asac, k
[11:15] <asac> its ok. but not starting at all is really a gross bug ;)
[11:15] <bluekuja> asac, believe me I tested it
[11:15] <bluekuja> asac, and it worked over here
[11:15] <asac> well. you didnt test it properly then
[11:16] <bluekuja> asac, or maybe I tested it on my files
[11:16] <bluekuja> asac, with everything updated and fixed
[11:16] <asac> 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] <bluekuja> exactly
[11:17] <bluekuja> I built it externally thinking the branch was updated
[11:17] <bluekuja> my error
[11:17] <asac> y
[11:17] <bluekuja> but the fix is ready, so, the problem doesnt exist
[11:22] <bluekuja> asac, gonna test it one more time
[11:22] <bluekuja> asac, gonna ping u when done
[11:23] <TomJaeger> asac, ping
[11:25] <asac> TomJaeger: hi. sorry if it felt like i ignore you ;)
[11:26] <asac> i saw you but then you scrollef of my radar ;)
[11:26] <TomJaeger> okay, so what do you think?
[11:27]  * asac fights with launchpad
[11:27] <asac> that bug is a mess
[11:29] <asac> TomJaeger: i think you need superreview ... https://bugzilla.mozilla.org/show_bug.cgi?id=422179
[11:29] <asac> reed: ^^?
[11:32] <TomJaeger> Do we need to get patches reviewed that go in development versions?
[11:34] <TomJaeger> 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] <asac> TomJaeger: we need to land it upstream, yes.
[11:43] <asac> 1.7 branch is cairo?
[11:43] <TomJaeger> xserver
[11:43] <TomJaeger> this means essentially no testing for binary drivers
[11:45] <asac> can you explain that to me? also why would rushing this fix in help?
[11:46] <asac> TomJaeger: ^^
[11: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:46] <TomJaeger> otherwise we'll have to wait for karmic upgrading to xserver-1.7 for the fix to kick in
[11:47] <TomJaeger> binary drivers aren't usually available until the last minute before release (frglx for sure), so they won't get any testing
[11:48] <TomJaeger> at least that's how I think it works, I've never used the binary driver before
[11:49] <TomJaeger> but the video driver API has definitely changed since 1.6
[11:51] <TomJaeger> 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] <asac> TomJaeger: where was the full EXTEND_PAD patch suggested upstream?
[11:52] <asac> its not in that bug, right?
[11:52] <asac> in moz bug i mean
[11:53] <TomJaeger> sorry, what was the question?
[11:53] <asac> 12:52 < asac> TomJaeger: where was the full EXTEND_PAD patch suggested upstream?
[11:53] <asac> 12:52 < asac> its not in that bug, right?
[11:53] <asac> 12:52 < asac> in moz bug i mean
[11:53] <asac> .>
[11:53] <asac> 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] <asac> meaning: i definitly cannot add this patch if its not in moz tracker
[11:54] <asac> if its in moz tracker we need to get it review-
[11:55] <asac> e.g. i need to get them to review whatever we add
[11:55] <asac> we can add it to trunk
[11:55] <asac> but thats basically all we can do and we dont have that many users on trunk dailies
[11:57] <TomJaeger> 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] <asac> TomJaeger: you mean the 1.7 server fix?
[11:58] <TomJaeger> no, I mean the unconditional one
[11:58] <asac> i think that should be pushed through
[11:58] <asac> right. but if you dont do it, then i have to do it - in theory before landing it
[11:59] <asac> i could add it until we rebrand firefox, but that might not be long enough to be of any value
[11:59] <asac> i could add it to 3.5 in karmic i mean
[11:59] <asac> afaics the 1.7 server fix will get landed and we should concentrate on cherry picking that. why wouldnt it work?
[12:00] <TomJaeger> it'll work, but it'll depend on xserver 1.7
[12:00] <asac> 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] <asac> you think thats a good compromise?
[12:00] <asac> free drivers will get enough testing i presume
[12:01] <TomJaeger> yes, free drivers should be fine
[12:01] <TomJaeger> okay, so let's do that
[12:01] <asac> right. so it all depends on the non-fre ones. imo only thing we can do is really raise awareness aobut this
[12:02] <asac> i mean even testing xserver 1.6 might not help because you never know what regressions you get in the new driveres
[12:02] <asac> especially since api changes etc.
[12:02] <asac> so it might work well, and then i wouldnt be shocked if it doesnt work with 1.7 anyway
[12:02] <asac> great
[12:03] <asac> 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] <TomJaeger> okay, sounds good
[12:03] <TomJaeger> how does the superreview process work?
[12:04] <asac> TomJaeger: you need to ask superreview from a superreviewer ;)
[12:04] <asac> wait a sec
[12:04] <asac> http://www.mozilla.org/hacking/reviewers.html
[12:05] <asac> TomJaeger: if you have that i can commit that for you
[12:05] <TomJaeger> it doesn't seem like this needs superreview
[12:05] <asac> TomJaeger: or you can add needs-checkin to whiteboard .. so some friendly moz committer does that
[12:06] <asac> TomJaeger: i think only reason its not needed is if the reviewer is superrevierwer
[12:06] <asac> at least that was my rule of thumb
[12:06] <TomJaeger> okay
[12:06] <asac> why do you think you dont need it?
[12:07] <TomJaeger> it doesn't really fall under any of the "What needs super-review?" categories.
[12:07] <asac> 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] <asac> anyway
[12:08] <asac> i asked reed to look, so he will guide you i am sure
[12:11] <TomJaeger> great
[12:12] <asac> if he doesnt follow up later today (he is sleeping i guess) let me know
[12:12] <TomJaeger> okay, thanks. Will do.
[13:27] <asac> fta: there?
[13:47] <fta2> asac, ?
[13:49] <fta2> i wish someone fixes bug 243344..
[13:59] <asac> fta2: isnt that an ArneGoetje bug?
[14:00] <asac> does it crash all the apps or just the scim server side?
[14:00] <asac> fta2: http://hg.mozilla.org/users/dmills_mozilla.com/about-tab
[14:00] <fta2> just scim
[14:01] <fta2> asac, dead since april?
[14:02] <asac> 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] <fta2> http://code.google.com/p/chromium/issues/detail?id=9643
[14:20] <fta2> asac, do you know the current status of the multi-arch project?
[14:20] <fta2> i guess i can ask mvo
[14:21] <asac> i have no idea. ask mvo, yes.
[14:21] <asac> at best in ubuntu-devel
[14:21] <asac> most people that know about that are probably there
[14:22] <asac> fta2: so all im libs are missing?
[14:22] <asac> have you tried if it works if those get installed?
[14:24] <fta2> there are dozens of ia32-libs related bugs currently open :(
[14:28] <fta2> 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] <asac> fta2: you say stop distributing it in the archive?
[14:31] <asac> or have a ppa to layer on top?
[14:31] <asac> how would that ppa get enabled? automagically?
[14:54] <fta2> asac, i'm not sure it's possible to run fetch-* directly inside the builders
[14:55] <asac> fta2: what does fetch- do?
[15:10] <fta2> 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] <fta2> asac, fetch-* downloads the indexes, then grab all the debs and the corresponding source packages
[15:13] <eagles051387> hey asac and fta2 how you guys doing
[15:13] <asac> good ;)
[15:13] <asac> thanks
[15:13] <asac> hope you too
[15:13] <eagles051387> :)
[15:13] <fta2> 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] <eagles051387> ya trying to get used to my mac
[15:13] <eagles051387> 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] <asac> 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] <fta2> asac, multiarch will do no good to jaunty<->hardy
[15:15] <eagles051387> asac: does this have to do with multiple processor architectures
[15:16] <fta2> eagles051387, no, it's about running 32bit on 64bit distro, but without the ia32-libs crap
[15:16] <eagles051387> that sounds interesting
[15:16] <eagles051387> would love to figure out how mac is gonna do it in their next release
[15:17] <fta2> https://wiki.ubuntu.com/MultiarchSpec
[15:17] <asac> fta2: i am not sure how much effort we really want to put into hardy <-> jaunty
[15:17] <asac> fact is that we all dont even have that installed
[15:18] <asac> and also this sounds like an endless support nightmare
[15:18] <asac> e.g. the more you try to do better the more requests and complains you will get etc.
[15:18] <fta2> i expect things to be quite stable there
[15:19] <asac> fta2: how many ia32 packages do you suggest?
[15:20] <asac> like one per seed?
[15:20] <asac> or random? e.g. one for chromium, one for other stuff?
[15:20] <asac> or like it is now=
[15:20] <asac> ?
[15:20] <fta2> one per seed
[15:21] <asac> and where would special depends for things not in the seeds (like chromium) go in?
[15:21] <asac> would you maintain unofficial seeds for that?
[15:21] <fta2> the thing is, there are some rogue ia32 packages that people found somewhere to fix their own bugs
[15:21] <mahfouz> :)
[15:22] <eagles051387> asac: i would be willing to test it out with various things like shoutcast if need be
[15:22] <eagles051387> i can upgrade my desktop upstairs to karmic and start testing
[15:22] <asac> eagles051387: what particular do you want to test?
[15:23] <eagles051387> the multiarch stuff
[15:23] <eagles051387> i have 64bit jaunty currently on my desktop i have in the other room
[15:24] <asac> 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] <asac> fta2: i didnt question the idea of fixing the ia32 packages. just want to understand whats the idea :)
[15:24] <eagles051387> gotcha
[15:25] <eagles051387> 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] <asac> eagles051387: as soon as we have something we are happy to have testers i am sure
[15:25] <eagles051387> 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] <asac> eagles051387: if you could explain how that works that would be great. however its unlikely that their solution would help us to fix issues in the old releases ... maybe it helps to get a better solution for future though
[15:26] <eagles051387> hardy is lts right
[15:27] <asac> yes.
[15:27] <eagles051387> humm ok
[15:28] <eagles051387> ill try do some digging and see what i can find
[15:37] <fta2> asac, http://paste.ubuntu.com/222756/
[15:39] <fta2> so obviously, many attempted to fix the problem by doing additional packages
[15:40] <asac> right
[15:42] <fta2> and it doesn't work, as you can't depend on 2 hacks providing the same fix
[15:44] <asac> problem obviously also is if there are intersections between different ia32 packages
[15:44] <asac> so its hard to do any split technically
[15:46] <fta2> crbug.com/17112
[15:47] <fta2> this is an example of rogue packages
[15:52] <fta2> brb, reboot needed
[16:23] <fta2> asac, tb3 broke the bot, somehow
[16:23] <asac> hmm
[16:23] <asac> fta2: is that in the mail that got send?
[16:24] <fta2> yes
[16:24]  * asac pulls inbox
[16:24] <fta2> at the end
[16:30] <fta2> the bot should probably do something smarter there
[16:31] <asac> i dont see what happens
[16:31] <fta2> just dying is not the solution :S
[16:31] <asac> the command printed is supposed to be the real command right?
[16:31] <asac> or is there something liek revisions etc. omitted?
[16:31] <fta2> hg clone sort of failed
[16:31] <asac> the command i see htere looks ok
[16:31] <fta2> it's the same command
[16:31] <asac> is that a new directory it uses? or somethign with an existing checkout?
[16:31] <asac> maybe its a hg regression?
[16:32] <asac> was there a mecurial upgrade recently?
[16:32] <fta2> Thu, 09 Jul 2009 17:21:25 +0200
[16:32] <fta2> hmm
[16:32] <asac> when did you pull that update on your bot machine?
[16:33] <asac> check dpkg log
[16:34] <fta2> reboot at 16:54, the bot kicked off at 17:00, close but that's not it
[16:35] <fta2> 2009-07-12 for hg
[16:36] <asac> reboot? because you upgraded?
[16:37] <fta2> pending upgrade, from earlier
[16:37] <fta2> pending reboot, from earlier
[16:37] <asac> ok. so hg didnt get updated in todays batch
[16:37] <fta2> nope
[16:37] <asac> anything else changed in todays upgrade?
[16:38] <fta2> yeah, a lot
[16:38] <asac> let me run that ocmmand
[16:38] <asac> maybe hg is busted upstream ;)
[16:38] <asac> you never know
[16:39] <fta2> just did ff and xul before
[16:41] <fta2> asac, seems fine now
[16:41] <asac> scary
[16:41] <asac> so maybe upstream hg was really busted
[16:44] <asac> bluekuja: so bad news is that my debian system is really offline
[16:44] <bluekuja> asac, really?
[16:44] <asac> i wanted to get connman up now because folks really wanted it, but then noticed its not there :(
[16:45] <bluekuja> asac, aww
[16:45] <asac>  ping -n hector
[16:45] <asac> PING hector.personalfree.com (192.168.1.3) 56(84) bytes of data.
[16:45] <asac> From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
[16:46] <bluekuja> how long will it take to have it back?
[16:47] <bluekuja> asac, anyway we have decided to move using debhelper, cdbs seems to be broken in karmic
[16:50] <asac> bluekuja: broken? in which sense?
[16:52] <bluekuja> asac, I dunno if the problem is pysupport or cdbs
[16:52] <asac> what _is_ the problem :/
[16:52] <asac> ;)
[16:52] <bluekuja> asac, because it doesnt recognize executables and searches data/stuff on the global namespace
[16:53] <bluekuja> asac, and into pysupport.private, you can find all files except executables
[16:53] <bluekuja> asac, but I dist-upgraded this afternoon, maybe something is broken on my system
[16:53] <bluekuja> asac, this evening the other guy will try it on his system
[16:53] <asac> i wouldnt shift to a different packaging approach just because sometihng suddenly doesnt work anymore
[16:54] <bluekuja> asac, works in debian
[16:54] <bluekuja> asac, not in ubuntu
[16:54] <bluekuja> asac, problem is: if something is really broken it will take time to have it working again
[16:54] <asac> bluekuja: check on -motu whats best to use for python so it can be used accross distros
[16:54] <asac> they know for sure
[16:54] <asac> but i dont because i am not a python man ;)
[16:55] <asac> bluekuja: i am sure there is a right way; switching to debhelper sounds like the wrong way :) ... you need to use pysupport etc. anyway afaik
[16:55] <bluekuja> asac, yeah, I'll try to fix it with cdbs then
[16:57] <bluekuja> asac, how long till ur system gets back?
[16:59] <asac> bluekuja: till i get back to the physical location
[16:59] <asac> which is Thursday evening most likely
[16:59] <bluekuja> oh damn
[16:59] <bluekuja> this is a really bad news
[16:59] <asac> yeah
[16:59] <bluekuja> asac, maybe connection went down?
[17:00] <asac> sorry
[17:00] <bluekuja> and will be back?
[17:00] <asac> no. i remember having it shut off
[17:00] <asac> and not remembering it to put on because i left early in the morning
[17:00] <bluekuja> aww
[17:00] <asac> (i had friend sleeping in that room before i left ... which is why i turned it off)
[17:00] <bluekuja> oh ok
[17:01] <asac> bluekuja: ask the guy who sponsored the other package maybe?
[17:01] <bluekuja> asac, yeah
[17:02] <bluekuja> asac, did u read the email i sent u the other week?
[17:02] <asac> that takes a bit i am sure. i cannot do that one week after you reappeared
[17:03] <asac> not sure what i should write even
[17:03] <bluekuja> asac, another bad news?
[17:03] <bluekuja> lol
[17:04] <asac> from a social point, I would love to, but if you reflect realistically on it you will probably agree.
[17:04] <bluekuja> asac, yeah, I agree with your point
[17:04] <bluekuja> asac, just hoping it won't take ages
[17:04] <asac> ages not ... a while, yes.
[17:05] <bluekuja> asac, wanted to start it before september cause more time to work on
[17:05] <bluekuja> it was the only motivation
[17:05] <bluekuja> but np
[17:05] <asac> great. dont feel bad about it ;)
[17:05] <asac> you already got back to -motu easily
[17:06] <bluekuja> asac, yep, I did tons of packages previous years
[17:06] <bluekuja> asac, and I didnt forget how they works
[17:06] <bluekuja> ^^
[17:08] <micahg> asac: was 3.0.12 built with the fix for touching .autoreg?
[17:08] <micahg> FF ^^
[17:08] <asac> micahg: i think so ... but most likely depends on the release
[17:09] <asac> karmic == yes, <=jaunty ~= no
[17:09] <micahg> oh
[17:09] <micahg> so we're still going to get autoreg bugs?
[17:09] <micahg> like bug 400555
[17:09] <asac> micahg: which releases did we get that from?
[17:09] <micahg> that was for 3.0.11
[17:10] <micahg> jaunty
[17:10] <bluekuja> asac, is chromium a good browser?
[17:10] <asac> bluekuja: try it yourself
[17:10] <asac> !chromium
[17:10] <micahg> you fixed the 3.5 and committed the fix for 3.0 as well
[17:10] <micahg> just wondering where it got applied
[17:10] <bluekuja> micahg, do you use karmic?
[17:10] <micahg> bluekuja: no
[17:10] <micahg> not until Beta
[17:11] <bluekuja> micahg, unstable?
[17:11] <asac> bluekuja: https://edge.launchpad.net/~chromium-daily/+archive/ppa
[17:11] <micahg> no, jaunty
[17:11] <bluekuja> ah ok
[17:11] <bluekuja> asac, ty
[17:11] <micahg> with selected packages backported
[17:11] <micahg> it's my work system
[17:11] <asac> micahg: how many dupes did we get onh .autoreg yet?
[17:11] <micahg> just 1 so far...
[17:11] <micahg> I think most people have FF installed already
[17:12] <micahg> but I figured it was easy to fix
[17:12] <micahg> and not really a dup, just 1 for 3.5 and 1 for 3.0
[17:13] <asac> micahg: to understand the impact of this we need to figure if this is a regression or just a corner case triggering this
[17:13] <micahg> ok, I'll ping the 3.0 user to see if it was a first install of FF3
[17:13] <micahg> that's my guess
[17:14] <micahg> ah, you already requested info :)
[17:14] <asac> now more
[17:15] <micahg> asac: is it normal to show my signature like in that bug?
[17:15] <asac> micahg: is probably a malone bug. but if you send by email thats what happens, yes
[17:15] <asac> if you send with mime signature then it even has an attachment afaik
[17:16] <micahg> ok, I wanted to try the command by e-mail
[17:16] <micahg> so I enabled my signature
[17:17] <micahg> oh, we were talking about centraling the directory where apturl stores the .js files
[17:17] <micahg> so apturl doesn't need to be updated every ff release
[17:17] <micahg> it could go in the same dir as the search engine plugins
[17:18] <asac> what do you mean? /etc/firefox-3.0/pref ?
[17:18] <micahg> yeah, right now it's here 401794
[17:18] <micahg> oops
[17:18] <micahg> /usr/share/firefox/defaults/pref/apturl.js
[17:19] <micahg> but ff3.5 doesn't seem to support it
[17:19] <asac> i dont think that that is used
[17:19] <asac> yeah
[17:19] <micahg> oh
[17:19] <micahg> ubufox provides the js file for apturl?
[17:19] <asac> well, what i dont want to do is to add another preferences directory
[17:19] <asac> i dont think preferences work with bundles (which we could otherwise use)
[17:19] <micahg> can't we make /firefox/ without a version the master prefs dir?
[17:20] <asac> micahg: which file in ubufox do you see?
[17:21]  * asac thinks its only shipped by apturl
[17:23] <micahg> I didn't see one, you just mentioned that you don't think that file is it, that's the file that's in apturl
[17:23] <micahg> oops
[17:23] <micahg> /etc/firefox-3.0/pref/apturl.js
[17:23] <micahg> that one :)
[17:23] <micahg> there are 2 in there now
[17:24] <asac> two?
[17:24] <asac> oh two handlers. yes.
[17:24] <asac> apt + apt +xxx ?
[17:24] <micahg> http://pastebin.com/f7b597aa8
[17:24] <asac> yes. thats ok
[17:25] <asac> we could drop the firefox location
[17:25] <asac> thats ffox 2
[17:25] <micahg> won't we need a third for ff3.5?
[17:25] <micahg> can't we just make like /etc/firefox?
[17:25] <asac> prefs might be incompatible
[17:26] <asac> so we would need versioned dirs anyway if we want two instances to be installabl
[17:26] <micahg> oh, ok
[17:26] <asac> /etc/firefox would hence mean a third, "common" location
[17:26]  * micahg has to get ready for work
[17:26]  * micahg will be back later to chat about this
[17:26] <micahg> thanks :)
[17:26] <asac> great cu
[17:33] <bluekuja> asac, are you able to test if a package runs for me?
[17:34] <bluekuja> asac, with karmic of course
[17:34] <bluekuja> * you
[17:38] <asac> no time for now
[17:38] <bluekuja> k
[17:50] <kaddi> hi, i'm on kubuntu jaunty and FF isn't closing correctly (even if I use file->exit). It keeps running after I hit the x, is there anything to fix this?
[17:53] <asac> why do you think its still running?
[17:53] <asac> kaddi: ?
[17:54] <kaddi> beause when I try to open FF again, it says "Firefox is already running please close before proceeding". And when I check top it also shows FF as running (and not just a short time. I left the PC running over night, but FF was still active, just no windows opened anymore)
[17:56] <asac> kaddi: sounds odd.
[17:56] <asac> so you can log out? and it keeps on running?
[17:56] <asac> thats really crazy. can you killall firefox / firefox-3.5 it?
[17:57] <kaddi> asac this problem has been present throughout firefox 3.0.7 to 3.5, creating a new profile didn't help, moving  .mozilla didn't help. Up til now it didn't bother me too much, because I just use killall firefox before starting firefox. But with the latest update the binary seems to be in /ust/lib/firefox-3.5.1 and killall doesn't touch that one, I need to find it with top and kill
[17:58] <asac> kaddi: you run firefox-3.5?
[17:58] <asac> killall firefox-3.5 then ;)
[17:58] <kaddi> I have been running it for a couple of weeks
[17:58] <asac> but anyway. what extensions are you using? try to disable them one by one
[17:58] <kaddi> I know ;)
[17:58] <asac> usually such kind of things are caused by rogue extensions ;)
[17:58] <kaddi> the problem also appears in safe-mode or with a completely new profile.
[17:59] <asac> kaddi: the other problem on kde is the gtk engine
[17:59] <kaddi> killall firefox-3.5 doesn't work, as mentioned before.. (sry i'm catching up ;) )
[17:59] <asac> try to use a gtk engine that gnome uses
[17:59] <asac> (and not the special gtk qt thing or whatever its called ;))
[17:59] <kaddi> how do i do that?
[17:59] <kaddi> htop
[18:00] <kaddi>  sry
[18:00] <asac> not sure
[18:00] <asac> kaddi: dpkg -l gtk-engin*
[18:00] <asac> ?
[18:01] <kaddi> asac: I'll be right back, I have the gnome desktop installed, and will just switch over and run FF in it to see whether that changes anything
[18:02]  * asac goes in after hour mode ... getting food stocks etc
[18:02] <asac> bbl
[18:04] <bluekuja> have fun
[18:09] <kaddi> asac: it actually seems to work fine with gnome
[18:10] <kaddi> I closed it a couple of times and got no complaints :o
[18:10] <kaddi> so it is the rendering in kde that poses the problem?
[18:13] <kaddi> so do you have any idea how to make this work with kde?
[18:22] <kaddi> asac you still there?
[18:27] <bluekuja> kaddi, he elft
[18:27] <bluekuja> * left
[18:27] <bluekuja> for a while
[18:29] <kaddi> hmm, ok :/
[18:30] <kaddi> anyone got any suggestions then how to run FF on kde with the gtk-engine from gnome?
[18:30] <bluekuja> nope sorry
[18:30] <bluekuja> I use gnome since ages
[18:31] <kaddi> lol, this is annoying.. well maybe google will know
[18:34] <bluekuja> yeah
[18:34] <bluekuja> maybe
[18:56] <asac> kaddi: do you have xulrunner-1.9*gnome-support instlaled?
[18:56] <asac> otherwise you probably will have to select a different gtk theme engine, yes.
[18:56] <asac> not exactly how kde sets that, but probably some env
[18:58] <asac> kaddi: (System Settings -> Appearance -> GTK Styles & Fonts) You can also set it to attempt to mimic your current Qt4/KDE4 theme, but that's really buggy.
[18:58] <asac> not sure if that works
[18:58] <asac> just a randome google hit
[18:59] <kaddi> i have xulrunner 1.9 gnome support installed
[18:59] <kaddi> and google obviously likes you a lot better than me
[18:59] <kaddi> :p
[18:59] <asac> so GTK Styles & Fonts
[18:59] <asac> is there i kde control center?
[19:00] <kaddi> need to switch back
[19:00] <kaddi> brb
[19:06] <kaddi> i don't see anything relating to gtk in kde helpcenter, however gtk-engine and gtk-qt-engine are installed
[19:08] <kaddi> ok, found it :) it was under appearances
[19:08] <asac> kaddi: does switching to something help?
[19:11] <kaddi> asac you're the best :D I changed the style to industrial and it works :D
[19:11] <asac> hehe
[19:11] <asac> kaddi: can you file a bug against gtk-engines-qt
[19:11] <asac> or something
[19:11] <asac> kaddi: is that karmic or jaunty?
[19:11] <kaddi> I suppose I can, should I just write what I experienced, or do they need more info?
[19:11] <kaddi> jaunty
[19:12] <asac> kaddi: hmm. there probably are bugs already.
[19:12] <asac> kaddi: check it out : bugs.launchpad.net/ubuntu/+source/gtk2-engines-gtk-qt
[19:14] <kaddi> I checked with Firefox bugs mor than once, I think I even filed one once, but it never occurred to me, that it might be the gtk-qt-engine :p
[19:15] <kaddi> I'm lucky you're here, I guess. :)
[19:15] <kaddi> https://bugs.launchpad.net/ubuntu/+source/gtk-qt-engine/+bug/306056
[19:16] <kaddi> this one looks a lot loke my problem, should I jsut add a commentary about having the same problem with kde 4.2.4 and FF 3.5.1?
[19:18] <asac> kaddi: no. there are enough me toos i think
[19:18] <asac> kaddi: just subscribe yourself
[19:18] <asac> and answer if asked for input
[19:18] <kaddi> :)
[19:32] <kaddi> thanks again and bye
[19:49] <fta> asac, https://answers.edge.launchpad.net/chromium-browser/+question/77578 :(
[22:18] <EruditeHermit> fta: hey
[22:18] <fta> hey
[22:20] <EruditeHermit> fta: can I make a request with the o3d plugin?
[22:20] <EruditeHermit> you are including/compiling against nvidia cg 2.1
[22:20] <EruditeHermit> but that has a bug that makes it not work on ATI cards
[22:20] <EruditeHermit> can you include the newer updated 2.2 version?
[22:21] <EruditeHermit> when I manually replaced the files with those from 2.2, it all worked
[22:25] <BUGabundo> fta: (10:22:07 PM) seb128_: BUGabundo, ok, the amd64 build lacks the png loader for some reason
[22:25] <BUGabundo> don't update. or will loose all icons :(
[22:25] <fta> EruditeHermit, i ship what upstream ships, why can't *they* bump it?
[22:26] <fta> BUGabundo, eh?
[22:26] <fta> BUGabundo, build of what?
[22:26] <BUGabundo> fta: x64 karmic
[22:26] <BUGabundo> https://bugs.edge.launchpad.net/bugs/401938
[22:27] <fta> i'm x32 here
[22:27] <BUGabundo> oh ok
[22:27] <BUGabundo> fyi in any case
[22:38] <fta> asac, do you have a page describing the automatic video codecs installation we have?
[22:39] <EruditeHermit> fta: so I have to bug upstream?
[22:40] <fta> EruditeHermit, it's not that i don't want to do it, i would prefer to drop cg completely as discussed earlier, but there's no alternative today, and i didn't have time to touch o3d since we last talked
[22:41] <EruditeHermit> ok
[22:41] <fta> so yes, please file a bug