[00:05] asac, http://code.google.com/p/chromium/issues/detail?id=26448 [00:32] fta: whats that? [00:32] i mea n... in hardy we have a recent enough nss right? [00:32] does this really happen in our built? [00:33] we generate the lower version through symbols [00:33] if new symbols are not used, then yeah [00:33] i'm not sure, people with vanilla hardy? or broken symbols? [00:35] yes. but vanilla hardy is not supported imo [00:36] i've just been Cced to the bug, i don't any additional information [00:37] yeah. but you said you will bump requirements ;) [00:37] which i think is not needed. users that install vanilla hardy ... dont get fixes/updates ... so chrome is broken :) [00:37] thats how it is ;) [00:37] the fix for that is available in -security [00:37] and -updates [00:37] and all real life hardy users should have that [00:38] even downstreams should at least track -security [00:53] please add that to the bug [00:54] !ping [00:54] Here I am, brain the size of a planet and you expect me to respond to a ping? How depressing. [00:54] hm [01:00] asac, o3d is now native x64 [01:01] and is now very similar to chromium.. gyp, scons, etc.. but it builds its own flow of libs [01:01] incl v8 & skia [01:05] Hello all, I am woundering if some of you could please enlighten me on when firefox forks and gets control of the flash player? [01:07] LlamaZorz: what do you mean? [01:09] When you are in firefox and go to a page that utilizes flash. Does firefox create a new instantiation of flash or does it use one sole instance with a lock, im trying to figure out how that works === asac_ is now known as asac [08:45] morningall === jonathan__ is now known as eagles0513875 === dpm_ is now known as dpm === jonathan__ is now known as eagles0513875 [10:25] fta: i think the tools/ directory should be in build-system? [10:26] tried to build fennec with 1.9.2 build-system ... choked because build/Makefile.in wants to do something with tools/rb... [10:29] * eagles0513875 waves to asac :) [10:29] hi eagles0513875 [10:30] asac: question bout lucid dev do you recommend upgrading or using a chroot environment to work on extensions [10:30] also how then does one go about testing them in the version of firefox in karmic [10:32] eagles0513875: i would suggest to setup chroot ... [10:32] ok [10:32] !chroot [10:32] chroot is used to make programs believe that the directory they are running in is really the root directory. It can be used to stop programs accessing files outside of that directory, or for compiling 32bit applications in a 64bit environment (https://wiki.ubuntu.com/DebootstrapChroot) [10:32] for extensions you might even not need to have lucid at all [10:32] except maybe for a final build tests etc. you should be able to do that in karmic [10:33] for now testing and working on karmic should be fine [11:00] asac, yes, probably [12:12] Is there any reason why the backported xulrunner-1.9.1-dev has an unsolvable mozilla-nspr>4.8.2 prerequesite in its libxul.pc? [12:24] http://pastebin.com/m5c00089d [12:24] Could this be due to building on a later version of Ubuntu? [12:31] stsquad: its replaced during build time ... NSPR_VERSION=$(shell $(NSPR_CONFIG) --version) [12:32] not sure how you backport it ... but you seem to built it somewhere where there is nspr 4.8.2 [12:32] oh yeah [12:32] I'm just checking now, the current xulrunner-1.9.1-dev is from the PPA (I'm on Hardy). [12:32] and if you dont use native nspr during build you get NSPR_VERSION=$(shell $(DEPTH)/nsprpub/config/nspr-config --version) [12:33] yeah [12:33] so the reason is that we fallback to in-source nspr if the system version is too low [12:33] stsquad: you have mozilla-nspr.pc too? [12:34] right ... so there should be a mozilla-nspr.pc ... dont we ship that? [12:35] you can surely workaround by backporting karmic nspr first ... so we use system-nspr [12:35] or did you already backport nspr 4.8 from karmic? [12:36] * stsquad looks [12:37] The only nspr I have is libnspr4-dev from Hardy's repos (which I assume must be the right one as FF3.5 is running) [12:37] * stsquad checks ldd [12:38] stsquad: no [12:38] the one in hardy is too old [12:38] it will fallback to in-source nspr [12:38] backport the karmic nspr + nss [12:38] * stsquad is confused [12:39] then build the xulrunner 1.9.1 [12:39] xulruner packages an libnspr4.so [12:39] stsquad: dpkg -L xulrunner-1.9.1 | grep nspr [12:39] yes [12:39] thats the in-source one [12:39] so if system-nspr is too low our build system reverts to its own nspr [12:39] however, building against that is a bit busted (upstream) [12:39] would probably required a few fixes [12:40] stsquad: do you need libxul.pc? maybe check if libxul-embedding.pc is what you want (for standalone applications its the right thing to do and libxul.pc is just for plugins and components that get loaded in a running xulrunner) [12:40] So the in source nspr is only for FF itself, it can't be used for embedding? [12:41] With the system FF (3.0) I was using pkg-config --exists xulrunner-gtkmozembed [12:41] I'm now using pkg-config --exists mozilla-gtkmozembed which pulls in libxul.pc [12:41] stsquad: thats a red herring ... if you embed gecko you must not use that [12:41] some redhat guy pushed for that ... and hte name is confusing [12:42] So the correct pkgconfig for embedding gecko is? [12:42] you need to use the standalone glue ... whihc is libxul-embedding-unstable [12:42] or libxul-embedding [12:42] https://developer.mozilla.org/en/xpcom_glue [12:43] also check this: https://wiki.ubuntu.com/XulrunnerGecko [12:43] which gives info what needs to be done to port stuff from 1.8 (which stil used mozilla-gtkmozembd) to 1.9+ [12:43] might be a bit outdated here and then but in general should be right [12:44] search for #ifdef XPCOM_GLUE [12:44] on that wiki page [12:44] thats basically the code you need to properly use the xpcom glue [12:44] Ahh so the calls in the app to gtk_moz_embed_new etc need to be changed to use xpcom glue instead [12:49] asac: thanks for the pointers, I think I know what I need to fix now [12:59] stsquad: more or less yes. there are a few implications though: e.g. you must not use internal symbols etc. just xpcom interfaces [13:00] but you shouldnt use those internal symbols anyway === debfx_ is now known as debfx [13:14] ~5 new dupes a day for the scim crash bug :( [13:31] fta: i was also subscribed to that bug , finally i got fed up and unsubscribed ;) [13:32] asac: why does updating firefox always reinstall the search engines? I remove them and they keep getting installed with every update :( [13:33] mac_v, yep, i just unsubscribed too [13:34] mac_v: thats a bug [13:35] asac: oh , good... i was worried it was intentional ... \o/ [13:35] * mac_v now searches for bug :) [13:36] its probably the same as the "keywords wiped" things [13:36] thing [13:36] in launchpad [13:36] havent found time to investigate [13:37] * mac_v wonders if anyone still uses yahoo search engine o.0 [13:39] ah found it.. Bug #428306 [13:39] Launchpad bug 428306 in firefox-3.5 "default search engines are removed and readded (keywords wiped) with upgrade" [Low,Confirmed] https://launchpad.net/bugs/428306 [15:12] darn ... this about: stuff kills me ;) [15:21] about? [15:35] yes its a mess ... supposed to fix ubufox with about:ubuntuhome about:offlinehome ... [15:49] fta: is anything needed besides chromium-browser to build chromium? [15:49] like is there a build depends ppa still? === pace_t_zulu_ is now known as pace_t_zulu [17:18] asac, no, the build-dep ppa is not ready, i had issues with cdbs backports [17:20] asac, http://codereview.chromium.org/174162 (last comment), what do you think? === aakashd_ is now known as aakashd === micahg1 is now known as micahg [18:15] fta: not sure. i think its ok to keep inspector if thats the user experience chrome folks want to ship [18:15] http://launchpadlibrarian.net/35579379/buildlog_ubuntu-karmic-armel.chromium-browser_4.0.245.0~svn20091111r31665-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz [18:15] * asac spins chromium on porter box [18:21] chromium-browser 19439 1.48% 3512 8849 7074 4 [18:21] chromium-browser-inspector 964 0.07% 70 170 724 0 [18:22] asac, the initial idea was that if less than 5% of the users really need that, it's not worth making it a hard dep [18:22] we are at 4.96% now [18:32] fta: right. but if upstream thinks they want such a rarely used thing by default then there is no point fighting it ... also atm folks using chromium are of the "lets try it" kind ... so they install -inspector with higher likelyhood than normal users. [18:33] fta: how can i continue a build when i fixed something without making full clean? [18:33] (chromium-browser) [18:37] fta: in common.gypi there is 'armv7%': 0, ... is that something we have to set to 1? or are those variables detected somewhere [18:37] ? [18:39] e.g. do i need to put that in GYP_DEFINES or somehting? i would hope that its auto detected (which as it seems it isnt) [18:42] it's not [18:44] well, supposedly, there's target_arch=' fta: right. target probably is right [18:45] try to add armv7=1 [18:45] but in common.gypi there also is armv7% : 0 [18:45] right [18:45] fta: is there a way to incremental build? [18:45] hmm its not a patch ... let me just respin [18:46] building [18:46] ... [18:46] lets see [18:47] name 'armv7' is not defined while evaluating condition 'armv7==1 and _toolset=="target"' in [18:47] that feels a bit odd though [18:47] it should at least be 0 [18:47] what does that % mean? [18:47] is that gypi syntax? [18:49] fta: https://wiki.mozilla.org/Releases/Thunderbird_3.0rc1#Build_Revisions [18:49] can we produce a tarball based on such revisions? [18:50] i assume we cannot specify two/three different revisions for comm-central/mozilla-central [18:50] i know, they made THUNDERBIRD_3_0rc1_RELEASE earlier today [18:50] oh there i THUNDERBIRD_3_0rc1_BUILD1 [18:50] it's not needed [18:50] yeah [18:50] in comm-central there is no such tag as it seems [18:51] at least i dont see it in hg.mozilla.org/comm-central [18:51] just grab tb3 with that tag, it will fetch the right wul [18:51] oh wait ... maybe its a branch [18:51] it's in a branch [18:51] that's why i've made a tb3.1 package [18:52] i should add it to the bot [18:52] but with that silly restriction.. [18:52] same for lucid [18:52] no such tag for comm-central :( [18:52] oh in releases [18:52] * asac checks [18:53] got it i think [18:53] good [18:53] mozclient should do that for you [18:53] yeah [18:53] i just didnt find it at all [18:53] ;) [18:53] now i have it [18:53] ? [18:54] just get-orig-source as usual [18:54] fta: i looked in comm-ncetral ... not comm-1.9.1 [18:54] i use the RSS feeds [18:54] http://hg.mozilla.org/releases/comm-1.9.1/atom-tags [18:54] http://hg.mozilla.org/comm-central/atom-tags [18:54] good ... i think chromium beuilt got past that gypi thing [18:55] now waiting [18:55] yeah [18:55] http://hg.mozilla.org/releases/mozilla-1.9.2/atom-tags [18:55] etc [18:55] yep [18:56] hmm the comm-central revisions http://hg.mozilla.org/releases/comm-1.9.1/rev/6ec88ca5bf7a seems to not have that BUILD1 tag [19:01] i don't see a BUILD tag, just RELEASE [19:08] [reed], can you steal the fix from the tracemonkey branch? [19:09] <[reed]> fta: yeah, should be able to [19:09] <[reed]> let me check when TM is going to be merged next [19:10] <[reed]> if it's going to be a while, I'll just push it to m-c [19:11] ok [19:18] fta: Linux jocote 2.6.28-14-lange51 #46arm1 Thu Aug 6 23:33:27 CST 2009 armv7l GNU/Linux [19:18] whats the best way to make that "dynamic"? [19:19] what do you mean? [19:19] e.g. in upstream build system [19:19] what is uname -m ? [19:19] fta: make armv7 : 1 in common.gypi if its armv7* i guess [19:19] armv7l [19:20] is uname -m [19:20] yes then [19:22] check uname -m for armv7 in the armel test [19:22] why did you add a test using DEB_BUILD_ARCH instead of DEB_BUILD_GNU_CPU? [19:22] asac, ^^ [19:39] fta: isnt BUILD_ARCH right? e.g. in case someone wants to cross-compile? [19:46] both should work, but GNU_CPU is less ubuntu specific, it matches hw better [19:46] DEB_BUILD_ARCH_CPU=i386 [19:46] DEB_BUILD_GNU_CPU=i486 [19:46] DEB_BUILD_ARCH=i386 [19:47] and i wanted a generic x64 instead of amd64 [19:47] er, x86_64 [19:48] asac, ^^, could plz pastebin dpkg-architecture ? [19:50] http://paste.ubuntu.com/317197/ [19:52] howdy [19:52] sick man entering the room [19:57] asac, so DEB_BUILD_GNU_CPU=arm is nice, use that to set both target_arch=arm & armv7=1 [19:59] fta: are you sure that GNU_CPU has the host arch? [19:59] like for cross-compiling and stuff? [20:01] it's BUILD.*CPU, not HOST.*CPU [20:01] cdbs knows about both [20:07] ok, nice, i build xul in less than 12 minutes incl the pbuilder setup [20:07] fta: how? === micahg1 is now known as micahg [20:08] by using all cpu/cores available [20:08] committed in the 1.9.3 branch [20:09] they don't want us to take a lot of builder time, so we'll take power more for each builder [20:09] (more misplaced) [20:13] micahg, it won't help if you just have 1 cpu [20:13] that's good [20:15] but then, locally, you can use distcc, or ccache [20:15] too bad the builders are just dual core, not quad or more [20:16] asac, http://code.google.com/p/chromium/wiki/LinuxChromiumArm [20:19] 85% [145 xulrunner-1.9.3-dbg 22299555/64.0MB 34%] 69.1kB/s 10min 3s [20:19] can't you guys make this any smaller?? [20:19] its taking FOR EVER [20:20] Fetched 262MB in 5min 14s (833kB/s) [20:20] that's still slow though [20:21] right [20:21] now imagine ALL LUCID updates [20:21] not done in a week [20:21] Need to get 293MB of archives. After unpacking 229MB will be used. [20:22] the mere package list is HUGE [20:22] Fetched 18.4MB in 1min 36s (191kB/s) [20:23] i can use lzma, but asac said it's not acceptable, for some reason [20:24] i use lzma for chromium only [20:24] as it's not in the repo [20:24] to lzma just the -dbg, it will mean patching cdbs [20:28] bah [20:28] I'm purging -dbg packags [20:29] 285 MBs freed :) [20:33] Is there any ppa that just carries Mozilla's "releases" (e.g. FF 3.6 beta 2) instead of updating every day? [20:33] yes [20:33] mozilla security ppa [20:34] !g mozilla security ppa [20:34] Error: I am only a bot, please don't think I'm intelligent :) [20:34] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa [20:34] BUGabundo: Ahh, but it doesn't have 3.6 yet, I checked. [20:34] it doesn't? [20:34] fta care to help ? [20:35] hackel: I built it, but I have to fix the branding still [20:35] https://edge.launchpad.net/~micahg/+archive/mozilla-beta [20:35] BUGabundo: mozilla security is security releases :) [20:35] of stable versions [20:37] micahg: thanks I'll give that a try, I'm not fussy about branding. :) [20:37] hackel: yeah, but we're not supposed to have official branding for pre-releases [20:38] Oh, you mean it actually says Firefox instead of Namoroka or whatever? [20:38] yes [20:38] I won't tell anyone. ;) [20:40] fta is there a "open in new tab from memory" shortcut on chromium? [21:28] asac, micahg1, BUGabundo: http://paste.ubuntu.com/317269/ [21:28] asac: around? [21:29] * BUGabundo checks fta virus [21:35] micahg1, didn't you bump cairo in xul 1.9.2? === jtv1 is now known as jtv [21:37] hmm [21:37] idr [21:37] I've been bumping as the warnings happen [21:37] nope, not yet === micahg1 is now known as micahg [21:37] did it on 1.9.1 and ff3.5 [21:38] and TB3 [21:39] * BUGabundo is seeing doubles [21:39] fta, you're starting lucid builds? [21:39] yes [21:39] all ppa will explode [21:40] fta, I'll bump xul192 and ff36 tonight [21:40] i need to add tb3.1 too [21:40] probably need fixes too [21:40] fta: songbird patches, do I need to be in the outside build-tree to use them? [21:41] for xul and ff, I go into build-tree/mozilla and work there [21:41] you need to be where the .pc folder is [21:42] so the .pc folder is created during debuild? [21:42] it's created by quilt, so during the patch step, before configure [21:43] ok, got it, I'll try to get the patches up to date over the weekend then [21:44] damn, i ordered two things from amazon us, they ungrouped them [21:46] lol "estimated delivery date: December 22, 2009" [21:49] can anyone play this smoothly? http://vimeo.com/6686768 [21:50] i can't, neither with ff, nor with chromium [21:51] asac: please release m-d as version 0.17.1 (i want this rc bug fixed) [21:54] fta, seems mostly smooth with the occasional audio hiccup [21:54] ff3.6b2 [21:55] with 3.7, the sound is jerky, like every 3 secs, so the video sometimes stops [21:55] the browser is at 100% cpu, so the plugin probably lacks resources to play smoothly [21:56] it's a dual core 2.3GHz [21:56] dtchen_, ^^ [21:58] micahg, asac: http://paste.ubuntu.com/317291/ [21:58] * micahg will be waiting for it to break tomorrow :) [21:58] bdrung, which RC bug? [21:58] bdrung, you can upload it yourself [21:59] av`: i can upload it, but not sponsor it [21:59] fta: plays perfectly with mplayer. Flash has never played video well for me. Great video, by the way... [21:59] bdrung, ? [22:00] av`: https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts [22:00] commit 274 [22:01] bdrung, re-link it again please, lost the window [22:01] hackel, yep, i love timelapses, i'm trying to make my own videos, but linux mostly sucks for photography :( [22:01] av`: ? [22:02] bdrung, re-link me the branch [22:02] av`: can't you scoll up to this post? https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts [22:03] av`, it's a native package, don't release stuff without going to asac or myself [22:03] bdrung, yes, works now [22:03] we need to make an "upstream" release [22:03] fta, actually bdrung is one of the authors [22:04] fta, plus m-ds has an R-C bug that makes it unusable atm [22:04] so I don't know if we can wait long to have it uploaded [22:04] still not a reason to do a wild upload [22:05] I don't think bdrung would do a wild upload [22:05] iirc, asac said he'll do it [22:05] av`: there are versions in the u-m-d ppa [22:06] fta: are you a DD? [22:06] ok, great, I saw bdrung was asking several times about it so I didnt understand why he couldnt upload it himself [22:06] no, but i'm upstream for this package, i've created it [22:06] fta: it's a bug fix and a point release (0.17 -> 0.17.1) would fit, wouldn't it? [22:07] micahg, it's not a local fix, buildds doesnt work with the current release [22:07] micahg, so it needs to be pushed to the archive and not locally, since the buildd gets the latest package built [22:07] ah, you're saying nothing will compile in the builders [22:07] initially, i just wanted X.Y (a float), but well, i don't mind [22:07] got it [22:08] micahg, exactly, it fails to build cause of that RC bug :) [22:08] jazzva is not on the uploaders list. so sponsoring would not work. then i can upload it, too. [22:08] fta, jazzva used 0.18 not 0.17.1 from what I saw [22:08] bdrung, no, you can't [22:09] av`: ? [22:09] bdrung, the changelog's entry should be owned by you [22:09] bdrung, the changelog's entry should be owned by you [22:09] av`: yes, i have to change the ownership [22:09] = your name must appear into the changelog latest entry [22:09] yes, exactly [22:10] av`: the changelog owner needs to be in the uploaders list [22:10] yes [22:10] but you must be the changelog owner to have the upload accepted [22:10] it is required to change it anyway [22:11] so uploaders list + ownership of changelog's entry [22:11] av`: yes, i will change this if i upload the package [22:11] k, perfect [22:11] but anyway ask to fta or asac, I don't wanna set up a war for a bug fix :) [22:12] fta: am i allowed to upload it to debian? [22:13] fta: do you prefer 0.17.1 or 0.18? [22:13] asac: ^ [22:14] upload yes, but only once it has been closed. and as i'm not in sync myself, i want asac to close it [22:14] that's what i meant by upstream [22:14] sorry, i'm tired, tough to write tonight [22:15] fta: what do you mean with closed? [22:15] +T [22:15] the UNRELEASE to xx commit [22:16] fta: with uploading i meant changing UNRELEASE to xx, commit and tag it, and then upload it [22:18] then we need to agree if there's enough stuff in to make the release, or if we have other stuff in the queue to stick in [22:18] as i said, i lack context, so i won't do it myself, sorry [22:19] fta: i don't know any stuff. [22:19] fta: so it's better to release this one commit bug fix. [22:20] fta: release often, release early - especially bug fixes === cyphermo1 is now known as cyphermox === BUGabundo1 is now known as BUGabundo [23:44] fta: if a PA client requests low latency, PA is happy to grant that at the expense of high cpu utilization [23:44] fta: this is a consequence of the mainloop [23:46] dtchen_, is there a way to mitigate that? i mean, slightly higher latency in exchange for less cpu? [23:46] so playback becomes smooth again [23:48] well, yes, the PA app needs to be changed [23:48] I'll try to push a PPA version soon [23:48] time. I never have enough. [23:54] dtchen_, would it help to have daily p-a PPA? [23:54] +a [23:54] fta: no [23:55] I discussed this with PA upstream at the beginning of the Karmic cycle, and he said it wouldn't be particularly useful, because changes aren't committed to the public VCS daily [23:55] hmm [23:56] note that I wouldn't mind having one, but he seems indifferent to it, which is somewhat baffling