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