[07:47] <ejat> fta: i cant open this page with chromium http://is.gd/3M54x
[10:01] <fta> ejat, nope (snap)
[10:28] <ejat> yeah
[10:28] <ejat> snap ..
[10:31] <fta> *** glibc detected *** /usr/lib/chromium-browser/chromium-browser --type=renderer --lang=en-US --force-fieldtest=CacheSize/CacheSizeGroup_0/DnsImpact/_default_enabled_prefetch/GlobalSdch/_global_disable_sdch/SocketLateBinding/_disable_late_binding/ --channel=23481.a64dba0.1170317228: double free or corruption (!prev): 0x0b5364a8 ***
[11:14] <asac> fta: can you enable verbose build commands for chromium?
[11:15] <asac> or tell me how to do that so i can do it ;)?
[11:43] <asac> fta: i will enable version building for chromium now
[12:02] <ripps> fta: the daily bot gives me warnings when I try to use the ppa:~user/ppa as the ppa name.
[12:02] <ripps> Also, for some reason, my packages aren't adding *.changes to my ppa directory
[12:15] <asac> maybe your bzr-builddeb config does not set the build-area result dir properly?
[12:15] <asac> ripps: ?
[12:19] <ripps> asac: huh?
[12:20] <asac> the bot uses bzr builddeb
[12:20] <asac> that uses a config file or command line arguments
[12:20] <asac> to determine where to put the results
[12:20] <asac> the .changes are put there usually
[12:20] <asac> no clue if thats your problem but its unlikely that no .changes are produced
[12:20] <asac> i expect them to be just in a different dir ;)
[12:20] <ripps> asac: actually it seems to be the new package. The older packages are working and creating .changes, but the new package isn't... maybe I screwed up something in the configs
[12:21] <asac> ripps: do they fail to build?
[12:21] <asac> you should be able to see in log if they produce changes
[12:21] <ripps> asac: they build fine
[12:21] <asac> and you see that changes are produced?
[12:22] <asac> thats what usually happens near the end of the buiöd
[12:22] <asac> maybe you can see dpkg-genchanges or something
[12:26] <ripps> asac: okay, I know where it's going wrong, just now how or why:  http://paste.ubuntu.com/281213/
[12:29] <ripps> I'm using "%: dh $@" as my rules, and it works perfectly in my pbuilder, but for some reason, I think the automatica dh_clean is breaking something
[12:38] <asac> yeah. i think debhelper 7 is a huge mistake ;)
[12:38] <asac> s/think/feel that/
[12:43] <ripps> maaaan... it's way past my bedtime, I just want to get this uploaded and go to bed
[12:44] <ripps> I'm going to try and prevent dh_clean all together and see if it works
[12:44] <asac> heh
[12:44] <asac> ok
[12:45] <asac> if you find it, let us know
[12:59] <ripps> fta: if you read this at some point, it seems that the ppa-bot is causing somekind of issue with dh_clean or dh_auto_clean, http://paste.ubuntu.com/281213/, my issue was resolved by preventing dh_clean alltogether, but this is not an ideal solution.
[13:10] <asac> gah tbird crashed .. ... not evnough memory
[13:57] <ripps> fta: even cdbs is giving me issues, but only with the new package... I don't know what I did, but it's only this new package that get's these issues, not my old one's.  http://paste.ubuntu.com/281276/
[14:18] <asac> ripps: is your produced orig.tar.gz name good?
[14:18] <asac> ripps: can you build without the bot if you use the same tarball produced by bot?
[14:19] <fta2> ripps, could you give me the full logs (or forward me the email if you use -e)?
[14:19] <fta2> asac, taking interest in chromium?
[14:19] <asac> fta2: same as before.
[14:19] <[reed]> I hope not. He's restricted to Mozilla projects!
[14:19] <[reed]> :)
[14:20] <asac> hehe
[14:21] <asac> fortunately, i can also spend my time whereever my work is needed and where distro input is allowed/appreciated/recognized ;)
[14:32] <fta2> grr, it seems it's impossible to use dlsym() with gcc4 and -O2/3/s and strict aliasing
[14:32] <fta2> even the example in the man page is not clean
[14:34]  * asac would think it works. but havent tried
[14:35] <fta2> try to copy/paste the ex and build it with -Werror -O2
[14:36] <asac> ok let me try
[14:36] <asac> gcc -Werror -O2 -rdynamic -o foo test.c -ldl
[14:36] <asac> asac@hector:/tmp$ ./foo
[14:36] <asac> -0.416147
[14:36] <fta2> add -Wall
[14:37] <asac> gcc -pedantic-errors -Werror -O2 -rdynamic -o foo test.c -ldl
[14:37] <asac> asac@hector:/tmp$ ./foo
[14:37] <asac> -0.416147
[14:37] <asac> yeah
[14:37] <asac> that fails ;)
[14:37] <fta2> i use -Wall -pedantic -O2 -Werror in my code
[14:46] <asac> fta2: http://paste.ubuntu.com/281314/
[15:04] <av`> asac, what should we do with #239151
[15:04] <av`> asac, a simply backport or something more?
[15:05] <av`> Launchpad Bug #239151
[15:11] <asac> if flashblock is completely broken for everyone we should consider to do a SRU
[15:11] <asac> for harx
[15:11] <asac> dy
[15:11] <av`> yep
[15:12] <av`> let me know your decision
[15:28] <fta2> asac, hm, i see. a union trick. could work but it means re-engineer all my project as i have a bunch of plugins
[15:33] <asac> fta2: i found somewhere on the web that union type-punning was explicitly left allowed
[15:33] <asac> because that was always the best practice to do something like that
[15:34] <asac> its not a union trick, but the original and most portable way to do things like this ;)
[15:36] <fta2> well, the union adds a layer in my otherwise nice api
[16:04] <asac> fta2: you can wrap that union part
[16:04] <asac> under the API hood
[16:04] <asac> and return the properly type casted function
[16:05] <asac> at least i would expect that APIs pass properly typed funcs in and out
[16:05] <asac> so whatever does the dlsym should do the cast
[16:06] <fta2> trying that..
[17:00] <fta2> asac, why did you add armel? any plan to upload soon?
[17:01] <asac> the plan is to get this up asap. but that takes 1-2 month in my planning
[17:01] <asac> we would put that in karmic-updates as we wont make it for release
[17:02] <asac> this in particular was because someone wanted to compare ffox vs. chromium on arm
[17:03] <asac> and couldnt get it built
[17:03] <asac> once we have most archs built we can disable VERBOSE again by default
[17:03] <asac> just easier to look at buildd logs that way
[17:14] <fta2> i kept it disabled because some lines were really long at some point, more than what the shell allows in cli
[17:15] <asac> if it breaks todays daily we can back it out again
[17:15] <asac> but i hope not
[17:16] <fta2> todays build failed, but for another reason
[17:26] <asac> get-orig-source didnt package that .gyp file up?
[17:29] <fta2> src/native_client was dropped completely until now
[17:29] <fta2> meaning i need a new tarball
[17:30] <fta2> hence a fresher commit
[18:55] <LLStarks> asac. you there?
[18:56] <asac> LLStarks: for a bit
[18:58] <LLStarks> 1. can you tell me that mozilla changelog site again? 2. where can i find older firefox daily builds?
[18:58] <LLStarks> older = older than 1 month
[19:06] <asac> LLStarks: hg.mozilla.org/releases -> mozilla-1.9.2 (3.6) vs. mozilla-1.9.1 (3.5)
[19:07] <LLStarks> narrowed the change to between july 1st and august 1st.
[19:09] <LLStarks> after july 15th.
[19:11] <LLStarks> after 7/25 but before 8/1
[19:14] <asac> LLStarks: cant you find older builds in our ppa?
[19:14] <asac> hmm
[19:14] <asac> i think we only keep sources forever
[19:15] <LLStarks> i'm using http://ftp.mozilla.org/pub/firefox/nightly/2009
[19:16] <asac> LLStarks: we need a one day window
[19:16] <LLStarks> drilling it down right now
[19:17] <LLStarks> 7/28-8/1 right now
[19:20] <asac> thats the thru border thing right?
[19:20] <LLStarks> yup
[19:20] <asac> any better window? ;)
[19:20] <LLStarks> 7/29-8/1
[19:21] <LLStarks> i'm doing 7/30 right now
[19:21] <LLStarks> 7/30 build confirmed
[19:21] <LLStarks> now to find the change
[19:21] <asac> so between 29 and 30 or 30 and 1 ?
[19:22] <asac> LLStarks: ?
[19:22] <asac> worst case would be that it got fixed as a side effect in https://bugzilla.mozilla.org/show_bug.cgi?id=479220
[19:22] <LLStarks> between 7/29 and 7/30\
[19:23] <LLStarks> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=55fd6820c596&tochange=3222b99f441c
[19:24] <LLStarks> http://hg.mozilla.org/mozilla-central/rev/4e85941dfbb5
[19:24] <LLStarks> https://bugzilla.mozilla.org/show_bug.cgi?id=486065
[19:24] <LLStarks> has to be it.
[19:27] <asac> give it a try ;)
[19:27] <asac> the commit i gave above is also from 30st
[19:28] <LLStarks> what commit was that?
[19:29] <asac> seems it landed early 31st
[19:30] <LLStarks> lemme do a before and after for the commit i linked to.
[19:30] <asac> do what?
[19:30] <asac> just put the patch in our xulrunner-1.9.1 package ;)
[19:30] <asac> thats simple patch
[19:31] <asac> or do you have per commit builds ready yet?
[19:31] <asac> how did you find the commits?
[19:31] <asac> i mean the bounds
[19:32] <LLStarks> i just picked an arbitrary date and then worked backwards.
[19:35] <LLStarks> using the mozilla-central builds
[19:36] <asac> let us know
[19:36] <asac> i am out for a while now
[19:37] <LLStarks> k
[19:37] <LLStarks> when will you be back?
[19:38] <asac> doesnt really matter ;) ... just talk to me i will read when back and if you are still here will answer ;)
[19:38] <asac> but i think 1-2 h
[19:38] <LLStarks> ok
[19:49] <LLStarks> micahg. sup.
[19:50] <micahg> hi LLStarks
[19:51] <micahg> asac: any chance of getting TB3.0b4 into karmic?
[19:51] <LLStarks> do you know how i could best way to test a commit without having to create an entire build setup?
[19:52] <micahg> LLStarks: push to PPA?
[19:52] <LLStarks> i guess, but i suck at debian packaging
[19:52] <micahg> LLStarks:you using a bzr checkout?
[19:53] <LLStarks> mercurial
[19:53] <micahg> ah
[19:54] <micahg> you can make a tarball out of it and use the code from our bzr branch to build the debian package
[19:57] <LLStarks> what's the bzr branch name?
[19:58] <LLStarks> lp:~ubuntu-mozilla-daily/firefox/firefox-3.1.head.daily
[19:58] <LLStarks> or do i need xulrunner?
[19:58] <micahg> LLStarks: which version of ff?
[19:58] <LLStarks> 3.5
[19:58] <LLStarks> this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=500368
[19:59] <micahg> and which component ar eyou changing
[19:59] <LLStarks> is fixed by this commit: http://hg.mozilla.org/mozilla-central/rev/4e85941dfbb5
[19:59] <LLStarks> micahg, i'm not sure.
[20:00] <micahg> probably xulrunner
[20:00] <LLStarks> do i also need to compile firefox with it?
[20:00] <micahg> nah, you can use one of the current versions of FF if you're not making any changes
[20:01] <micahg> you just want to test that patch on the 3.5 branch?
[20:01] <LLStarks> yah
[20:02] <LLStarks> will i be able to use firefox 3.5 shipped with karmic?
[20:02] <micahg> I think the easiest way would be to apply it as a patch in debian/patches
[20:02] <micahg> yeah, you would just need to push xulrunner to your ppa
[20:02] <micahg> I'd make the version smaller than current
[20:02] <LLStarks> how do i do that?
[20:02] <LLStarks> push to my ppa.
[20:03] <micahg> do you know how to pull down the source for xul-1.9.1?
[20:04] <asac> LLStarks: build xulrunner-1.9.1 from mozilla-1.9.2 branch
[20:04] <asac> use some local install location
[20:04] <asac> put the gre.conf into /etc/gre.d/
[20:04] <asac> and then firefox will pick up your xulrunner
[20:05] <LLStarks> why do i have to all the work when i know jackshit about packaging?
[20:07] <LLStarks> okay. where do i start.
[20:10] <asac> LLStarks: i told you how to do it without packaging
[20:11] <asac> you do an upstream xulrunner build
[20:11] <asac> make install
[20:11] <asac> ensure that the right gre file is there
[20:11] <asac> done
[20:11] <LLStarks> "build xulrunner-1.9.1 from mozilla-1.9.2 branch"
[20:11] <LLStarks> what does that mean? where do i get this mozilla-1.9.2 branch?
[20:12] <asac> i have you the url ;)
[20:12] <asac> http://hg.mozilla.org/releases/mozilla-1.9.2
[20:12] <fta> 1.9.1 from 1.9.2 ??
[20:13] <LLStarks> wouldn't everything be easier if asac applied this change himself? i'm bound to  **** up.
[20:13] <asac> thats a typo
[20:14] <asac> i never said you should do that
[20:14] <asac> i wanted you to confirm that the patch works
[20:14] <asac> not more
[20:14] <LLStarks> well, i can't confirm at the commit level
[20:14] <LLStarks> only at the binary build
[20:15] <LLStarks> this is precise as i can be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=55fd6820c596&tochange=3222b99f441c
[20:16] <LLStarks> and common sense tells me that  commit 4e85941dfbb5 is the most likely fix
[20:18] <LLStarks> asac, if you could apply it to the next daily or a staging ppa, that would be lovely.
[20:20] <asac> LLStarks: give me a patch that applies cleanly
[20:20] <asac> and remember that i wont try like 10 different patches that way
[20:20] <asac> ok out again for a whil
[20:21] <micahg> asac: I could do this later tonight...after 1AM UTC
[20:21] <LLStarks> so... am i building xulrunner 1.9.1 or 1.9.2?
[20:21] <asac> micahg: go ahead. push that to some ppa and let LLStarks confirm the fix (or confirm yourself)
[20:21] <LLStarks> *diffing against
[20:21] <asac> LLStarks: 1.9.1
[20:22] <LLStarks> and cloning from 1.9.2?
[20:22] <asac> the patch is on 1.9.2 branch ... you want to por t that to 1.9.1
[20:22] <asac> LLStarks: you dont need to clone 1.9.2
[20:22] <micahg> LLStarks: what tz are you in?
[20:22] <LLStarks> EDT
[20:22] <asac> clone 1.9.1 and download the diff from the pushlog
[20:22] <LLStarks> eastern daylight, us
[20:22] <micahg> LLStarks: will you be around 9PM EDT?
[20:22] <LLStarks> yah
[20:22] <micahg> I can build it around then
[20:22] <micahg> push up to my ppa
[20:23] <micahg> and you can install to test
[20:23] <micahg> which LP bug is this for?
[20:23] <micahg> or rather what should I call the patch asac?
[20:23] <asac> we have an upstreawm commit. that should be references
[20:23] <LLStarks> https://bugs.edge.launchpad.net/gtk-engines/+bug/327863
[20:23] <asac> referenced
[20:24] <asac> like bzXXX_attXXX_short_desc.patch
[20:24] <asac> please dont pout that bug in the name
[20:24] <asac> use the one referenced in the upstream commit you cherry pick
[20:24] <LLStarks> "clone 1.9.1 and download the diff from the pushlog" gotcha
[20:24] <asac> and document in changelog or on top of the diff in the patch that this also fixes bug xyz
[20:24] <micahg> asac: what is att?
[20:24] <asac> micahg: the attachment id from the bug
[20:24] <asac> that was committed
[20:25] <micahg> ah
[20:25] <asac> usually in bugzilla tehy sign off a specific file for landing
[20:25] <asac> if you click on it you see the id
[20:25] <asac> is quite important for bugs where there are mulitple patches etc. for various branches
[20:25] <micahg> ok
[20:25] <asac> so https://bugzilla.mozilla.org/show_bug.cgi?id=516465
[20:25] <asac> its 403366
[20:25] <LLStarks> asac, the diff doesn't apply cleanly for you?
[20:26] <asac> i havent checked.
[20:26] <LLStarks> i'll check
[20:26] <micahg> asac: got it, thanks
[20:26] <asac> i am doing something else besides talking to you ;)
[20:26] <LLStarks> understood.
[20:26] <asac> now that micahg takes care you should ask him if you should rebase or if he does that ;)
[20:26] <asac> i would have been more happy to get a patch that is guaranteed to apply cleanly ;)
[20:27] <micahg> I was going to rebase it before applying it
[20:27] <fta> asac,   - chromium-browser (4.0.219.6~svn20090929r27475 -> 4.0.219.8~svn20090929r27516) [78.30MB (+3085kB, +3.94%)]
[20:28] <fta> asac, that's native_client
[20:28] <micahg> I know the lines are off by at least 30
[20:29] <micahg> asac: can you take a quick look at bug 4375454
[20:29] <asac> off is ok ... just quickly check that the code surrounding it is similar
[20:29] <micahg> ugh... bug 437545
[20:29] <asac> yes
[20:29] <asac> we have a different bug for that
[20:29] <asac> its because of devmode
[20:31] <asac> too bad ... cannot find the bug right now
[20:31] <micahg> asac: the patch looks like it would apply cleanly
[20:31] <micahg> but I'll do a test build lateer
[20:32] <asac> micahg: just add to debian/patches/ and series and push to your ppa
[20:33] <asac> builders seem idle ;)
[20:33] <LLStarks> confirm. patches cleanly.
[20:34] <LLStarks> http://pastebin.com/m6699b91b
[20:44] <micahg> waiting for ppa
[20:58] <micahg> looking good
[20:58] <micahg> should be ready in another 10 minutes or so
[20:59] <LLStarks> i have the ppa added.
[20:59] <micahg> you do?
[20:59] <LLStarks> https://launchpad.net/~micahg/+archive/mozilla-test
[20:59] <LLStarks> right?
[20:59] <micahg> this one: https://edge.launchpad.net/~micahg/+archive/mozilla-test
[20:59] <micahg> yep
[21:00] <micahg> I guess good ppa names do help :)
[21:11] <asac> i think one cannot delete ppas yet. so choose a generic name rather than a topic ;)
[21:12] <asac> mozilla-test sounds generic enough of course
[21:17] <fta> asac, with VERBOSE=1, it's now very difficult to track errors, esp since i use --keep-going
[21:18] <fta> asac, i used to look for "error", now, there's -Werror at each line :P
[21:20] <fta> grrr, seems i need to add "libc6-dev-i386 [amd64]" to b-d
[21:24] <asac> fta: if that has impact on your work we can change that back soon.
[21:25] <asac> if possible keep it for a day or two
[21:25] <asac> till the toolchain issues are sorted for armel
[21:25] <asac> if its unbearable on your side: back it out now
[21:27] <asac> fta: ok. its half past 10 ;)
[21:27] <asac> i am leaving for today too
[21:29] <asac> micahg: before i leave. do you need help on the LLStarks patch?
[21:29] <asac> or is all fine?
[21:29] <asac> ok seems amd64 built fine
[21:29] <asac> so you are most likely fine
[21:29] <asac> ttyt
[21:30] <LLStarks> micahg. build is finishing up.
[21:30] <LLStarks> for i386
[21:31] <micahg> seems to be fine asac
[21:31] <micahg> you want me to propose a merge if it works?
[21:36] <LLStarks> i386 built
[21:37] <LLStarks> testing.
[21:38] <LLStarks> \IT WORKS!
[21:38] <LLStarks> holy shit
[21:41] <LLStarks> sorry about that. adrenaline rush. i've never really followed a bug from discovery to fix.
[21:41] <micahg> so, asac wanted this to go into karmic?
[21:42] <LLStarks> that or the default theme had to be changed after appearance freeze.
[21:45] <micahg> I'll propose a merge tonight
[21:51] <BUGabundo> boas noites
[21:51] <BUGabundo> asac: are you around?
[21:51] <BUGabundo> would like to ask you what you think of wish bug of mine
[21:51] <BUGabundo> _before_ I put it on LP
[21:52] <BUGabundo> asac: should NM autoconnect to known wifi networks by default ?
[21:53] <micahg> BUGabundo: doesn't it do that now?
[21:54] <BUGabundo> micahg: no. it remains untick
[21:55] <micahg> is that a regression?  NM connects for me to pomaticallyrevious networks I've connected to aut
[21:55] <BUGabundo> not me, with NM trunk PPA
[21:55] <BUGabundo> its not even selected on a NEW network profile
[22:03] <LLStarks> micahg. your ppa is behind karmic according to dpkg.
[22:03] <LLStarks> did you label correctly?
[22:49] <micahg> LLStarks: yes
[22:49] <micahg> I didn't want to make it above
[22:50] <micahg> micahg: that way if the tests fail, there aren't version issues
[22:57] <BUGabundo> district 9, starting
[22:57] <BUGabundo> bbl
[23:01] <micahg> LLStarks: do you want to change that upstream firefox bug?
[23:01] <LLStarks> to the one that actually fixed?
[23:01] <micahg> yeah :)
[23:03] <LLStarks> fixed.
[23:03] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/327863/
[23:03] <LLStarks> and the upstream link fixed.
[23:06] <micahg> And I just set the importance and assigned to myseld
[23:06] <micahg> *myself
[23:54] <LLStarks> micahg, once merged with the dailies, how does the fix make it into main?
[23:57] <psyke83> asac: hi. Re: bug #422511, even if that patch works, I think that Firefox will still exhibit problems with a theme using a trough >0
[23:58] <psyke83> right now, with a theme using a trough of 2, if you edge-click on the scrollbar in firefox it won't respond - BUT - in other applications, edge-clicking will cause the scrollbar to jump, but you still cannot click on the scrollbar
[23:59] <psyke83> it must be a problem with firefox's gtk implementation. I'm recompiling libgtk2.0-0 with the proposed patch and will check this for certain
[23:59] <psyke83> should I file a new bug, or mention it in the same report and assign to firefox?