[00:03] great [00:23] fta? [00:26] alexbodn, ? [00:26] how are you? [00:27] well, it's 1:30am [00:31] fta: 2:30 here ;) . still active? [00:34] fta: i'm packaging bluegriffon. do you know how the application file can be a script taken from xuldev/sdk/bin/xulrunner, calling application_name-bin, taken from xulrunner-stub or -bin? i mean how should i script this? [00:36] i already packaged bluegriffon [00:36] last year [00:37] https://code.edge.launchpad.net/~fta/+junk/bluegriffon.head [00:37] alexbodn, ^^ [00:38] i know, you sent me your link, but it changed significantly, and now it's quite straight forward to do it. that's why i'm reworking it [00:38] oh [00:38] what is so different now? [00:38] i'm also basing myself in the fennec ubuntu example [00:39] may i upload you the curent diff? [00:41] fta: i'm opening a private window to you, to send the diff. ok? [00:42] hm, i can't accept it, i can only cancel, wth? [00:43] i'll retry [00:43] same [00:44] fta: could you accept now? [00:44] nope [00:44] i'll mail this, ok? [00:44] ok [00:51] fta: sent [01:08] still not there, probably in my greylist queue. i'll have a look tomorrow [01:08] fta: np [01:09] fta:do you have another im? [01:09] fta: icq, msn, yahoo? [01:10] nope, just µblob (identi.ca) [01:13] fta: what's µblob ? google doesn't seem to know about it [01:13] alexbodn, do you know twitter? identi.ca is a free twitter: http://identi.ca [01:14] alexbodn, http://en.wikipedia.org/wiki/Micro-blogging [01:14] i see === asac_ is now known as asac [01:29] fta: i'm alexbodn on identi.ca [01:29] hello asac [07:53] ola [08:07] http://techvideoblog.com/computex/arm-director-of-mobile-computing-about-arm-laptops-with-android-and-ubuntu/ [08:15] alexbodn: hi. whats up? did you get what you wanted from fta? [08:16] fta: yeah moz does a b99 ;) [08:17] fta: seems to be some beta channel update for pre-testing RC ;) [08:17] so damn. the mailman approval didnt work :) [09:32] asac: hello [09:34] alexbodn: hey. good morning ;) [09:34] we have coversated by night a little, and i found some direction by grepping in the bluegriffon source tree. [09:34] alexbodn: ok. so did you find fta's bzr branch? [09:36] yes he sent it to me before, but bluegriffon changed since then, to the good, and fta's patches to upstream have been adopted in part at least [09:38] asac: do you have newer xulrunner (1.9.[1-9]) packaged for ubuntu? [09:42] alexbodn: we have 1.9.1 (for ffox 3.5) and 1.9.2 (trunk) [09:43] great. can they co-exist with debian's 1.9 family? [09:48] alexbodn: yes, should work [09:48] at least for now [09:48] probably a problem because we only conflict with xulrunner-1.9-dev and not xulrunner-dev which is the one used by debian [09:49] so the binaries can coexist in ubuntu/debian ... the -dev packages _can't_ coexist [09:49] because the idea is that you select which build target you use by installing the proper -dev [09:49] i understand [09:55] in the next few days we will start transitioning to 1.9.1 by default in ubuntu :) [09:55] well first in ppa [09:59] great. i foresee both bluegriffon and fennec should need these [10:02] fta: does trunk open homepage in new tab for you too now? [10:18] hmm ... seems to be not an upstreawm feature. [10:18] odd [12:19] hmmm ... trunk does weird things ;) [12:19] like starting with a different profile than the one i used for the first window [12:20] trunk firefox? [12:21] asac: why did i just do that :( [12:21] oh shit [12:24] ok fixed i think [12:30] this mono discussion is better than tv [12:32] gnomefreak: so you approved him ;) [12:32] but deactivated again :) [12:32] yeah mant to decline first :( [12:32] sure [12:32] as long as the guy cannot reenable his account its ok [12:33] have you read this mono discussion? [12:33] no ;) ... too much mail [12:33] i dont htink he can but there are ways to fix that once he tries [12:33] topic didnt sound attractive enough for me to look closer [12:33] 1 person hates the idea and 35 others trying to defend mono [12:35] I don't know that's why I'm writing here to get the MONO people kicked out [12:35] thats a quote [12:35] ;) [12:35] well. thats on -devel-discuss? [12:35] yeah [12:35] i thought we had mono devs for atleast 1 year [12:51] ok rest of bugmail can wait a week or 2 when i get back on here [13:06] hm, since the last reboot, i had tons of [13:06] [48671.965227] end_request: I/O error, dev fd0, sector 0 [13:06] [48684.140609] end_request: I/O error, dev fd0, sector 0 [13:06] [48696.304600] end_request: I/O error, dev fd0, sector 0 [13:06] [48708.468736] end_request: I/O error, dev fd0, sector 0 [13:06] yeah [13:06] had that too [13:06] took quite some time to boot because of that probing [13:06] dont even have a fd0 [13:06] yep [13:06] fta: complain in #ubuntu-kernel ... let me know what they say ;) [13:10] you didnt have that on shutdown? [13:10] gnomefreak: i wish you good luck .... get better soon and cu asap [13:10] asac: thanks [13:11] i had those errors on 2.6.28-12 during shutdown. numbers always changed. updating to 2.6.28-13 fixed it for me [13:11] only had that on startup [13:12] i cant use 2.6.30 with GUI so ive stayed oin 28 [13:12] s.oin/on [13:12] ah ff 3.0.11 is in testing as well as sm 1.1.17 [13:13] yeah [13:13] and tbird 2.0.0.22 [13:14] yep that too [13:27] ok that time already. see ya asap if everything goes well i should hav emost of sight in left eye by end of week i would think [14:16] asac, answering chromium questions ? ;) [14:16] asac, bug 384579 [14:16] Launchpad bug 384579 in linux "Linux thinks there’s a floppy drive when there’s not. Probing slows down bootup by almost a minute." [Unknown,Confirmed] https://launchpad.net/bugs/384579 [14:16] sure [14:17] i get those questions ;) [14:17] and load is pretty low [14:17] i subscribed the team last week, as noone got those before, except by chance [14:19] hmm. not sure if i saw them before [14:19] but probably not ;) [14:34] hmm https://blueprints.edge.launchpad.net/chromium-browser/+spec/chromium-human-theme [14:37] interesting spec ;) [14:37] fta: what theming mechanism does chromium offer? [14:37] follow the link [14:39] fta: hmm. how can we make this honour gtk theme selection? [14:40] good question [14:44] fta: ffox trunk remote client seems to be broken. do you see that too? [14:44] maybe its because i have multiple profiles [14:44] if i open a new firefox through command it opens ffox with a profile currently not in use [14:45] hm, wtm [14:45] i mean wfm [14:45] fta: do you have more than one profile? [14:46] I have 4 but i use only the default one [14:46] strange [14:47] i still get those bad X errors sometimes http://paste.ubuntu.com/190886/ [14:49] hmm seems to work too now [14:49] lets see if it comes back [14:50] fta: oh it happens only if i open a url with command line [14:50] like: open one instance, then use firefox http://test.tld [14:51] nevermind [14:51] it must be something in gnome settings [14:51] ok preferred application had wrong custom command [14:53] ok [15:37] quite annoying devel-discuss thread on mono :) [15:38] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/008447.html [15:43] lol [15:43] 2 threads, units and mono [15:44] unit consistency, yeah ;) [15:49] asac, the crash in ff3.6 is really annoying [15:50] fta: which crash? [15:50] the one on startup when calling it in remote mode [15:51] yeah jemalloc stuff it hink [15:51] fta: do you have a backtrace? [15:53] asac, it's in the bug. here is fresh one: http://paste.ubuntu.com/190928/ [15:53] right. what did i say was the problem ;)? [15:54] do you know the bug id? [15:55] bug 319480 [15:55] Launchpad bug 319480 in firefox "firefox-3.1 crashed with SIGSEGV in memalign()" [Unknown,Confirmed] https://launchpad.net/bugs/319480 [15:55] mozilla 473629 bug 319480 [15:55] Mozilla bug 473629 in jemalloc "crash on exit in glibc memalign with jemalloc statically linked" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=473629 [15:55] bug 355551 [15:55] Launchpad bug 355551 in firefox-3.5 "firefox-3.5 crashed with SIGSEGV in ptmalloc_init()" [Medium,New] https://launchpad.net/bugs/355551 [15:56] so it's 3.5 and 3.6 [15:56] definitly [15:56] its jemalloc statically linked in [15:56] i dont think we do that in 3.0 [15:56] its like said here: https://bugzilla.mozilla.org/show_bug.cgi?id=473629#c4 [15:56] Mozilla bug 473629 in jemalloc "crash on exit in glibc memalign with jemalloc statically linked" [Normal,New] [15:56] thats what i found. [15:56] the libc code should not directly call the libc malloc function, but should use the overloadable function name instead [15:57] let me check if i can find it quickly again [16:00] fta: wanna test this patch :) : http://paste.ubuntu.com/190930/ [16:00] d'oh! [16:01] fta: better try in a chroot first ;) [16:04] ok uploading this somewhere [16:04] not sure if it builds though [16:05] https://edge.launchpad.net/~asac/+archive/sandbox ;) [16:06] btw, did you push your gtk patch forward? i still need to update ia32libs [16:08] fta: there is a bug with atk-bridge killing flash in nspluginwrapper .... otherwise i would push it [16:08] and firefox forgets that it sets AT_NO_BRIDGE [16:08] in env [16:08] havent figured out [16:08] why it forgets that env [16:09] i think it has something to do with the fact that unloading libxul.so will also unload a few const chars that have been added to env [16:11] so glibc is spinning https://edge.launchpad.net/~asac/+archive/sandbox [16:11] looks dirty [16:11] fta: the env problem? [16:11] yes [16:12] yes. it definitly is broken. but i am not sure if hte unloading bug is really responsible for the env getting wiped in the main firefox process (i added debug output and it just forgets about AT_NO_BRIDGE) [16:15] * asac wipes gutsy chroots to get space for libc testbed [16:19] * asac sets up karmic chroot [16:21] fta: the bookmark manager is there [16:21] fta: I just can't drag stuff around, but it's coming along! [16:22] jcastro, hm, how? using the menu entry? [16:22] no, right clicking on the bar [16:23] and selecting bookmark manager [16:23] oh, you can remove the window decorations now [16:23] oh? [16:23] !!!! [16:23] cool! [16:24] all they need is max/min buttons [16:24] would be nice if the dark blue was transparent [16:24] it's transparent in windows [16:25] is there a linux-specific changelog anyplace? The overall one is just too much to keep track of [16:26] i don't think so [16:27] it would be neat instead of blue if it got the tint for the chrome off your gtk colors [16:32] now that google produces its own debs, i wonder what will happen with my dailies [16:32] I don't think they do dailies [16:32] chromium-browser 5721 0.51% 390 1912 3419 0 [16:32] google-chrome-unstable 465 0.04% 3 1 461 0 [16:34] plus yours goes into the right place, not /opt. :p [16:34] how often do you think they'll update it? [16:35] probably weekly, not sure [16:36] not sure they update the deb through a repo or directly like on windows [16:38] what a mess.. http://ubuntuforums.org/showthread.php?p=7408653 [16:39] look in /etc/cron.daily/google-chrome [16:39] jcastro, i don't have it [16:39] jcastro: paste it ;) [16:40] i mean, i don't want it ;) [16:40] http://paste2.org/p/252100 [16:40] so that libc build failed to build ;) [16:41] i have the feeling i dont know what i am doing. lets see if it builds now that i included proper headers [16:45] so the package adds a google repo for you, re-adds it daily if it's not there, and re-enables it if it's disabled like after a major upgrade [16:45] i sure don't want that to happen in my back [16:45] yeah ;) [16:46] fta: do they depend on mst fonts? [16:47] fta: so you answered your own question, we still need your dailies. :p [16:47] annoying idea to have a cron script that readds a repo [16:47] asac, no idea, i don't have their deb [16:47] isnt really changing a thing [16:48] just annoying ;) [16:48] jcastro, yeah :) [16:49] kind interesting that they dont even have repos for jaunty/karmic/hardy, etc. [16:49] probably doesnt matter as they link in everything anyway [16:49] right [16:50] one big pile in /opt [16:51] jcastro, can you please dgkc -c the deb? [16:51] sure [16:51] dpkg [16:52] http://paste2.org/p/252115 [16:52] asac, just added ff3.6, tb3 and chromium to the list of preferred apps in gnome [16:56] jcastro, do you have the 32b deb too? [16:56] no [16:57] it's strange, they ship the 32b libs of nspr/nss/sqlite but nothing else, i thought that were targetting hardy [16:57] +they [16:58] oh, the links are just needed at build time, so maybe those debs are also fine in hardy [17:00] jcastro, btw, is the chromium logo still blurry in gnome do? [17:02] lol http://groups.google.com/group/chromium-discuss/browse_thread/thread/41f77fc003ff263?pli=1 [17:13] yes, it is [17:18] jcastro, hmm, could you try to remove /usr/share/pixmaps/chromium-browser.png? i hope /usr/share/icons/hicolor/*/apps/chromium-browser.png will take precedence then [17:19] lemme chech selinux with symbolic-functions ;) [17:19] i think fedora folks said they dont see that problem ;) [17:19] fta: nope, removing it and restarting do didn't fix it [17:20] i should read about this /usr/share/icons/hicolor/ thing then [17:24] hm, icon-theme.cache [17:32] jcastro, which app has a good icon in gnome do? (so i can have a look at how it is done as i can't find a spec) [17:32] firefox/minefield do [17:32] lol [17:32] heh [17:33] but it's just a 48x48 icon [17:43] fta: you know where it crashes in ptmalloc_init ;)? [17:43] fta: http://paste.ubuntu.com/190995/ [17:43] last line [17:43] so yeah. even the crash on startup seems to be due to corrupted env [17:44] so leaking all envs might help ;) [17:44] Stacktrace: [17:44] #0 ptmalloc_init () at arena.c:346 [17:45] SegvAnalysis: [17:45] Segfault happened at: 0x184561 : cmpb $0x4d,(%eax) [17:45] PC (0x00184561) ok [17:45] source "$0x4d" ok [17:45] destination "(%eax)" (0x019f305a) not located in a known VMA region (needed writable region)! [17:49] fta: right. what i am saying is that the place that crashes iterates the env ;) === rickspencer31 is now known as rickspencer3-afk [17:49] and we know that env is busted [17:49] ok [17:49] so we need to leak env ;) [17:50] at least those coming from constant strings [17:53] i give up on those desktop icons. no spec :( [18:00] oh, nice. about:credits in chromium [18:40] jcastro, http://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel/release-notes is the best i could find [18:41] fta: ah, good enough === rickspencer3-afk is now known as rickspencer31 [19:26] asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/9ea5db23053e773a/a4233e4dcf29cd3a?lnk=raot [19:27] fta: i think the problem should be fixed now [19:27] asac, ? [19:29] fta: the memaling crash [19:29] at least for me it works now ;) [19:30] using your patched glibc? [19:31] fta: no. using the patch i committed to .head ;) [19:31] 1.9.2 [19:31] leaking the env [19:32] but NO_AT_BRIDGE is still not properly passed to the npviewer [19:33] which still breaks flash if i add the gtk fix of 32 bit modules [19:33] but i guess thats rather the way the process is forked [19:33] so does a normal execv reset the env? [19:33] or pass it properly down? [19:37] ... "The other functions take the environment for the new process image from the external variable environ in the current process." [19:37] extern char **environ; [19:37] asac, you asked me a question about xul growing in size, where/when was that? [19:38] 8:54 < asac> 18:13 < cjwatson> asac: xulrunner-1.9 seems to have grown by a megabyte from .0.8 to .0.10 - do you know why? [19:38] fta: ^^ [19:40] fta: so between 1.9.0.8 and 1.9.0.10 we gained weight ;) [19:43] i guess i will run a diff on the trees after dinner [19:43] now heading for that [19:49] fta: can you kick of another trunk spin round? [19:50] or, well, tomorrow is early enough i think [19:50] ok out for food [19:51] which branch? [19:53] 1.9.2 + 3.6 heads [19:53] k [19:58] libxul.so is 3MB bigger [20:00] same libs [20:01] i guess it's gcc 4.4 [20:01] 1.9.9.8 was from jaunty, hence gcc 4.3 [20:06] fta: was 1.9.0.9 also gcc 4.4? [20:06] otherwise the change should probably be between .9 and .10 [20:06] * asac ponders lp [20:06] https://edge.launchpad.net/ubuntu/karmic/i386/xulrunner-1.9 [20:06] no .9 !? [20:07] fta: yeah. so .9 went to jaunty-security [20:07] and karmic was still close [20:07] and .10 was a firedrill so karmic doesnt have .9 ;) [20:09] fta: maybe we pull something not as system lib? [20:09] but that wouldnt change libxul most likely [20:09] hmm [20:09] so yeah. its probably gcc ;) [20:09] unless upstream changed optimization options or some other flag [20:11] or maybe just the linker? [20:13] grr. cannot access binaries of the jaunty-security build in launchpad :/ [20:13] why? [20:14] http://launchpadlibrarian.net/25826822/xulrunner-1.9_1.9.0.9%2Bnobinonly-0ubuntu0.9.04.1_i386.deb [20:14] really odd [20:14] [ ] xulrunner-1.9_1.9.0.10+nobinonly-0ubuntu0.9.04.1_amd64.deb 28-Apr-2009 20:04 8.3M [20:14] [ ] xulrunner-1.9_1.9.0.10+nobinonly-0ubuntu0.9.04.1_i386.deb 28-Apr-2009 20:05 7.2M [20:14] but [20:15] [ ] xulrunner-1.9_1.9.0.10+nobinonly-0ubuntu1.respin1_amd64.deb 30-Apr-2009 21:04 8.3M [20:15] [ ] xulrunner-1.9_1.9.0.10+nobinonly-0ubuntu1.respin1_i386.deb 30-Apr-2009 21:04 8.1M [20:15] so: only i386 grew [20:15] to almost the same size as amd64 [20:15] fta: where did you find that link? i couldnt see it :( [20:15] https://edge.launchpad.net/ubuntu/jaunty/i386/xulrunner-1.9 [20:16] https://edge.launchpad.net/ubuntu/jaunty/i386/xulrunner-1.9/1.9.0.9+nobinonly-0ubuntu0.9.04.1 [20:16] interesting [20:16] the other path doesnt work ;) [20:16] e.g. clicking on the changelog on main packaging page [20:16] and then selecting the arch [20:16] anyway. its i386 that is busted [20:18] jsut the respin [20:18] fta: yeah. but before the respin it was completely broken [20:18] e.g. failed with bus error [20:18] which i thought just ment it picked some bad toolchain state when archive opened [20:50] asac, re-spinning xul 1.9.2 [20:50] cool [20:51] fta: ffox needs to be rebuild too ... it copies the stub [20:51] hm, really? [20:51] fta: yes. ffox copies xulrunner-stub [20:51] at least on trunk [20:52] fta: compare size of $pkglibdir/firefox and $pkglibdir_xul19/xulrunner-stub [20:53] fta: but maybe you dont need that ;) ... i think the problematic part was in libxul [20:53] so lets just try xul for now [20:53] yep [20:54] chromium-testsuite is starting to look good [20:54] http://launchpadlibrarian.net/27655058/buildlog_ubuntu-karmic-i386.chromium-browser_3.0.184.0~svn20090608r17866-0ubuntu1~ucd1_FULLYBUILT.txt.gz [20:54] nice [20:55] i mean, gdb, good backtraces, tests in a fake X server, timeouts to prevent infinite builds, etc.. === rickspencer31 is now known as rickspencer3-afk [20:57] but there are drawbacks, crashes in libfakeroot-sysv.so, no network, no shared memory, .. [20:57] fta: no network -> even no "lo" ? [20:57] i don't know. === rickspencer3-afk is now known as rickspencer31 [21:15] fta: heh, drag and drop for the bookmark manager just landed [21:17] boas noites [21:18] jcastro, are you monitoring svn? ;) [21:29] fta: I happen to have seen the mail go by (no, I am that not that pathetic, hah) [21:52] hm, it's indeed very slow to push chromium-browser from a dsl link [22:01] ahahaaha [22:02] fta: does your Power Button works on Karmic? [22:02] fortunately [22:03] but i'm still fighting with bug 384934 [22:03] Launchpad bug 384934 in xorg "Xorg very slow after upgrade" [Undecided,New] https://launchpad.net/bugs/384934 [22:11] jcastro, unfortunately, i can't respin the bot for chromium due to the quota. i'm limited to 1 push per 24h [22:12] so it's also very difficult to experiment [22:17] ouch [22:18] jcastro: its so funny to see fta Answer ticket eheh [22:20] waiting for bug 381296 to land [22:20] Launchpad bug 381296 in soyuz "PPA max quota is too small" [High,Fix committed] https://launchpad.net/bugs/381296 [22:49] also waiting for bug 378828 to land [22:49] Launchpad bug 378828 in soyuz "DepWaits no longer processed" [High,Fix committed] https://launchpad.net/bugs/378828 [22:57] didnt land yet? [22:57] hmm [22:57] so we do this manually now? [22:57] what a pain ;) [22:57] i still have the 10 min workaround in my bot [22:58] fta: thats the orig.tar.gz bug [22:58] fta: the depswaits should be like keep lower bound one day trailing [22:58] or something [22:59] thought i saw depwaits being processed properly alrady [22:59] hm, apparently, i dropped the workaround [22:59] http://bazaar.launchpad.net/~fta/%2Bjunk/ppa-scripts/annotate/head%3A/sync-ppa.pl#L210 [23:00] timestamp: Sat 2009-05-30 11:02:33 +0200 [23:01] so it seems ok [23:07] heh [23:07] so its committed, but fixed ;) [23:07] fun [23:11] fta: did you check if the fix works? [23:11] hm, not yet [23:11] (without copying stub ;)) [23:12]