[00:02] asac: don't we have to keep xulrunner for the other apps built on it? [00:04] but as daily? [00:04] sure, but no need to do dailies for those [00:06] asac: well, probably not, the only thing I can think of is if people want to test other apps with the daily [00:09] question is: can we add xulrunner to universe without feeling too bad because we already know it will be abandoned security wise soonish? [00:10] asac: well, it should get at least 6 months after release [00:10] thats the old world ;) [00:10] i am not sure what will happen, but the idea is to even stop doing that [00:10] :) [00:10] asac: I thought it was still in debate [00:10] not sure if mozilla abandoned the idea [00:11] iirc, there was no resolution either way [00:11] but, I think we have to at least throw something in there for the other apps [00:11] what other choice do we have? [00:12] otherwise, we can provide the -dev packages in ff and let them know they might break? [00:12] reconnect [00:12] 01:11 < micahg> iirc, there was no resolution either way [00:12] 01:12 -!- asac_ [n=asac@e177168032.adsl.alicedsl.de] has joined #ubuntu-mozillateam [00:13] (06:11:31 PM) micahg: but, I think we have to at least throw something in there for the other apps [00:13] (06:11:46 PM) micahg: what other choice do we have? [00:13] (06:12:20 PM) micahg: otherwise, we can provide the -dev packages in ff and let them know they might break? [00:13] -> its just a huge axe hanging above us, so imo we need to plan as if they will do it ;) (for now) [00:13] other apps get removed ;) [00:13] ok, then, if we can get clearance for major changes in the depending apps, we can try to bump them to be compliant during the release cycle [00:13] or migrated to webkit [00:13] at best [00:15] well. the major/minor session basically had the input from release team etc. that we should try to get rid of it ... [00:15] one idea would be to provide a trimmed down firefox-3.5-plugin-dev package [00:15] so we can still build plugins (which tend to be not as bad to maintain) [00:16] or we review apps manually and decide on case by case base, what we want to keep supporting [00:16] for those we need committmenet to provide backports in time for _all_ supported archs [00:16] does prism come with it's own xul code? [00:16] no [00:17] well. it could be made to have that ... but ;) [00:17] thats getting ugly [00:17] I'm certainlly willing to help with the backporting [00:18] in general, we'll be doing it for the devel release anyways [00:18] we have a few areas that are hard to get right ... [00:18] a) mozjs ... we have couchdb depending on that [00:19] b) we xul apps that would become more or less void [00:19] -> if we have xulapps without binary components, we should remove them imo -> they can be provided upstream directly somewhat i guess [00:19] asac_, i don't get the migrated to webkit part.. why would moving the burden of security maintenance to webkit change anything? [00:20] first: the world moves to webkit. thats a fact ;) [00:20] so we will have to maintain webkit ;) [00:21] asac_: so, is the moziila team expanding to become the browser team? [00:21] second: embedders like webkit more [00:22] i would think that making a browser team in the long run becomes more and more viable ;) [00:23] thunderbird will stay around for a while longer too i guess [00:23] and if users like chromium more, would you move firefox to universe? [00:24] stuff gets moved to universe when its not on CD, nor on dvd usually [00:24] on any officially support image is more accurate i guess [00:24] wouldn't that depend on the archive restructuring? [00:25] yes. i have no clue about what exactly will happen then ;) === asac_ is now known as asac [00:41] at some point we should get rid of firefox-3.1 transitional packages i guess [00:41] those were only in ppa, right? [00:42] should be safe to drop then in lucid i presume [00:43] they certainly weren't in a production release [00:44] my innovate gnome component shuffeling didnt work out as good as expected :/ [00:44] (speaking to myself) ;) [01:17] hmm ... xdg-open is kind of borked [01:18] yeah [01:18] I meant to look into that [01:23] asac, http://paste.ubuntu.com/330715/ [01:24] the thing is, i don't know when branches are abandonned [01:32] fta: hmm. wasnt gears integrated in chromium? [01:32] no [01:33] they won't do it [01:33] instead? [01:33] their prefer to wait for the html5 offline feature [01:33] they [01:33] is there any mstone targetted for that? [01:34] http://stackoverflow.com/questions/1194784/which-browsers-support-html5-offline-storage [01:35] Google Chrome: Gears Database API, which is built into Chrome and thus doesn’t require a separate install. Surprisingly, Chrome doesn’t yet natively support any form of HTML5 Storage. [01:35] hmm [01:35] so only win [01:37] http://code.google.com/p/chromium/issues/detail?id=17443 [01:41] i know [01:42] svn20091128r33239/build-tree/src/third_party/protobuf2/src/src/google/protobuf/dynamic_message.cc:66: [02:30] http://paste.ubuntu.com/330748/plain/ with trunk [02:31] fta: we are well past 2200 ;) [02:31] grrr [02:31] hehe [02:31] ok its saturday [02:31] so its ok i guess ;) [02:31] what a pity ... gvfs backend for gdocs does not "just work (tm)" [02:32] /home/asac/Development/upstream/gvfs/gvfs_gdata/daemon/gvfsgdocsfile.c:665: undefined reference to `gdata_documents_presentation_get_download_uri' [02:32] guess we need a better libgdata ;) [02:34] * asac spins 0.5.1 from debian sid [02:34] rather than 0.4 we have in karmic [02:35] so ... i managed to get chromium mailto: handler to work [02:35] for yahoo and gmail [02:35] except that xdg-open is broken ... but thats probalby xdg bug (escaping?) [02:35] but opening mailto: in firefox now opens yahoo/g mail in chromium [02:37] now we just need to mount gdocs as HOME/Documents ;) ... and then somehow ensure that we wrap the proper content types by something that opens browser with the right url ;) [02:39] and resolve some "minor" online/offline handling issues before we can provide a good user experience ;) [02:39] feels hard :/ [02:41] * asac wonders if gvfs is in theory good for offline [07:11] Hello, why isn't libmozjs1 built for xulrunner-1.9 ? === AnAnt_ is now known as AnAnt [07:42] AnAnt: what version of ubuntu? [07:42] micahg: karmic & lucid [07:42] AnAnt: xul-1.9 doesn't exist in either [07:42] errm, oops [07:43] 1.9.1 [07:44] sorry I dunno it is named xulrunner-1.9.1 [07:44] so, the same issue holds for that version [07:44] I thought it was part of it [07:44] why isn't libmozjs1 built for it ? [07:45] AnAnt: I think it's part of xulrunner-1.9.1 [07:46] micahg: libmozjs-dev is part of xulrunner-dev ? [07:46] yes [07:46] xulrunner-1.9.1-dev [07:46] in 'xulrunner' there is libmozjs-dev & libxul-dev [07:46] xulrunner is old [07:48] I see, so that's a big deviation from Debian [07:48] AnAnt: we don't import xul from debian [07:52] micahg: do you know since which version (1.9 or 1.9.1) did xulrunner start using heartbeat ? [07:52] no, sorry [07:52] idk what heartbeat is [07:55] ok [09:49] Damn, chromium is segfaulting on me. Now I have to install the huge debug package and get a backtrace [09:52] okay, nevermind. Everything is segfaulting, I think I just got a kernel bug [09:59] asac: you wouldn't happen to be on would you? [10:40] Hello, back to the libmozjs* packages question, I hope that separate packages for libmozjs* are built from xulrunner-1.9.1 (as have been done for old xulrunner) [10:40] AnAnt: they are not and will not be [10:40] some packages use libmozjs, and they can't find mozjs library in xulrunner-1.9.1-dev long path [10:41] micahg: any reason for this ? [10:41] hmmm [10:41] idk [10:41] simplicity? [10:41] let me see if I can find a bug [10:42] micahg: when you said "will not be", I thought you knew a reason for this [10:42] ah, sorry [10:42] that's my tiredness [10:42] 4:45 in the morning :) [10:42] I see [10:43] you need to sleep [10:43] I meant to say I don't think there are plans to revive it, but I'm trying to see if I can find the reason why it's no longer [10:43] ok [10:44] so, asac is asleep ? [10:44] well, probably not at noon, but it's sunday [10:45] asac is in europe ? [10:45] UTC+1 [10:45] ok [10:51] I don't think it was ever in 1.9 [10:51] so that's since hardy [10:53] AnAnt: asac usually pops in sometime Sunday...I'll try to ask if I remember [10:57] AnAnt: apparently you're not the only one with this issue [11:11] ok, thanks [13:49] fta: do you see any error here: http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.bak.bz2 [13:49] it failed to build [13:49] but i dont see anything that is an error [14:37] ok we worked around it by tweaking as [18:04] asac: ping [18:06] AnAnt: ? [18:06] asac: can separate packages for libmozjs* are built from xulrunner-1.9.1 (as have been done for old xulrunner) [18:06] s/are/be [18:06] no [18:08] why is that ? [18:08] there is a abug open about providing a stable ABI/APi [18:08] they say they dont want to do that [18:08] so shipping libmozjs would be wrong [18:08] its not ment for consumption outside of xulrunner/firefox upstream [18:08] let me check something [18:09] there are packages using libmozjs [18:10] https://bugzilla.mozilla.org/show_bug.cgi?id=506890 [18:10] Mozilla bug 506890 in Build Config "Make it possible for Ubuntu to provide libmozjs.so as a system library" [Normal,New] [18:10] AnAnt: right. those in theory use something that isnt allowed [18:10] its not my decision [18:10] read the bug [18:10] ;) [18:11] anyway. xulrunner will be either removed completely from archive (unlikely) or go to universe [18:11] when that happens we can provide a mozjs there [18:11] which doesnt really help couchdb ;) [18:11] bad situation [18:12] thy dont even want to keep abi/api promise within a stable branch ;) [18:12] that means: doomed [18:14] so all our hope is on libseed ;) [18:14] rather webkit ;) [18:20] libseed ? webkit ? what's those for ? [18:22] other js lib [18:38] so, is xulrunner going to be removed in lucid ? [18:39] removed or go to universe that is [18:42] asac, jcastro: http://www.sofaraway.org/ubuntu/tmp/chromium-forest.html 131 releases in 60 days, incl 59 in branches (the rest in trunk) === AnAnt__ is now known as AnAnt [18:50] yes [18:50] AnAnt: yes [18:50] ok, thanks [19:33] asac, i think i will add a get-branch-source target, using something like RELEASE_BRANCH=249, and use that for another PPA [19:34] it's probably best to work in a dedicated branch tough :( [19:34] +h [20:11] asac: around? [20:30] dh_link -p chromium-browser-dbg [20:30] dh_md5sums -pchromium-browser-dbg [20:30] dh_builddeb -pchromium-browser-dbg -- -Z lzma [20:30] dpkg-deb: building package `chromium-browser-dbg' in `../chromium-browser-dbg_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.deb'. [20:30] \o/ [20:30] fta: ^^ [20:30] ;) [20:31] micahg: for a moment. yes. [20:31] ;) [20:31] ah, ok [20:31] if I'm adding different .desktop translations, are they separate commits in bzr and are they separate lines in the changelog? [20:32] micahg: if you add a batch at once you can have them in onecommit/line [20:32] but i wouldnt merge them when i land a second translation a few days later [20:32] Lang1, Lang2, Lang3 (LP: 1, LP: 2, LP: 3)? [20:32] if they have more than one bug i would still go for the multi commit/changelog approach [20:32] ok [20:33] so one per commit one per line [20:33] do I list the file after each line? [20:33] or say something like: add translation for XX (LP: # ...), YY (LP: #...) [20:33] but i dont think we need to save lines in changelog ;) [20:33] micahg: if you dont merge them, then yes [20:33] ok [20:33] i undertand a changelog line as a entry + file modification [20:33] got it, I found 2 other translations over the weekend, so I'm adding them to 3.5.head [20:34] hmm. ok [20:34] the other thing is, do you remember why we don't break out libmozjs anymore? [20:34] ;) [20:35] * asac has to remember to update branch before committing the all-in-one-wonder changes ;) [20:35] micahg: we never did it [20:35] asac: why not start that with 3.6 unless we are backporting all in one to hardy [20:35] read: https://bugzilla.mozilla.org/show_bug.cgi?id=506890 [20:35] Mozilla bug 506890 in Build Config "Make it possible for Ubuntu to provide libmozjs.so as a system library" [Normal,New] [20:36] that explains the reason why what debian does is insane - support wise ;) [20:36] well, it used to be a separate package in xul 1.8 [20:36] that was debian heritage [20:36] ah [20:36] maybe if we go away from xulrunner we can sync debian xulrunner ;) [20:36] and then get libmozjs in universe [20:36] but even then its a bad feeling because we already know we wont be able to support [20:37] (same as for xulrunner we discussed yesterday) [20:37] only a subset of applications we can pick and then prepare for porting ;) [20:37] thats the same for mozjs [20:37] mozjs gets > 1/3 of security fixes [20:38] and those are usually of tricky kind (and nont many not working for mozilla - who wont help us according to bug) would be able to maintain that [20:38] wow [20:39] if you read bug: they didnt even want to commit to not break API on a stable branch :/ [20:39] yeah, I saw that [20:39] that's what the wow was for :) [20:39] so asking for stable minimal API across branches is definitly not right [20:39] for them ;) [20:39] they basically say: dont use mozjs anywhere but in firefox/tbird [20:40] so it almost seems like there's no point in shipping it at all [20:40] right ;) [20:40] thats the whole point ... and if you ship it you need to hire core js devs from mozilla ;) [20:41] ok, we have a few bugs on this, now I know, should I create a master bug or keep telling people to build against xulrunner-1.9.1-dev [20:41] or both? [20:41] we have a master bug afaik [20:41] micahg: tell people to not use mozjs ;) [20:41] the building against xulrunner-1.9.1-dev has the same messy implications [20:41] just that we make it harder for them to do (and increase likelyhood we will bump into them) [20:41] asac: suggest they port to webkit? [20:41] maybe ;) [20:42] for now its probably the only way we can send them [20:42] v8 has same approach as mozjs [20:42] i the most accurate answer is: do not use javascript ;) [20:42] sad but true [20:45] I don't see a master bug [20:45] * asac looks [20:46] great. search for "mozjs" on xulrunner-1.9.1 package -> no result [20:46] but: bug 486079 exists ; [20:46] Launchpad bug 486079 in xulrunner-1.9.1 "installing libmozjs-dev will remove ... firefox ubuntu-desktop ubuntu-docs xulrunner-1.9.1 and a lot more" [Undecided,Incomplete] https://launchpad.net/bugs/486079 [20:46] thats launchpad [20:46] yep [20:47] i thought there was a bug open ;) [20:47] which bugs do you look at? [20:47] maybe i didnt name it MASTER, but consider it a master :) [20:47] generally just ff, but someone came in here last night asking [20:47] bug 286906 [20:47] Launchpad bug 286906 in xulrunner-1.9 "Unable to use libmozjs.so in an application, because of library path problem." [Undecided,Confirmed] https://launchpad.net/bugs/286906 [20:47] micahg: yes. that was anant [20:47] yep [20:47] already told him that mozjs is bad ;) [20:48] should I make that bug the master? [20:48] one sec [20:48] maybe i wont fix it [20:49] ok cannot find it [20:49] go ahead then [20:49] move to 1.9.1 i guess [20:50] should I link to the upstream bug also [20:51] why not ;) [20:52] make it a wishlist bug with title: "provide and support a top-level library package for libmozjs" [20:52] make it a wishlist bug with title: "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)" [20:52] or something similar [20:56] ok [22:12] ugh, they hijacked the builders again [22:12] they == us? or QA folks? ;) [22:12] QA folks it seems :) [22:12] there are 5/8/5 [22:12] I"m going to pbuilder songbird to see if it works [22:12] thtas better than 2/2/3 ;) [22:13] yeah [22:14] asac: it looks like I'm going to have to use songbird's sqlite for the moment [22:15] thats in line with everything we do ;) [22:15] are you on lucid yet? [22:15] nope [22:15] should I be? [22:15] no [22:15] just was curious [22:15] I wasn't planning on jumping until beta 1 [22:15] if sqlite is at least new enough there in theory [22:15] asac, could you add "killall -q -v -9 $(basename $TEST)" at the end of debian/run-test.sh and use it on base_unittests? [22:16] fta: how do i use it on base_unittests? [22:16] debian/run-test.sh path/to/the/bins/base_unittests [22:17] hmm... i dont see the base_unitttests [22:17] did it clean them at end of build? [22:17] oh sorry [22:17] wrong host ;) [22:18] well, run it from sconsbuild/Release [22:18] ./debian/run-test.sh build-tree/src/sconsbuild/Release/base_unittests [22:18] Usage: run-test.sh [-x] [-t sec] test_file log_dir [filter] [22:18] -x Run test_file under xvfb -t sec Timeout in seconds after which we kill the test [22:18] hmm [22:19] -t20 ? [22:19] o log dir was missing [22:19] its running [22:20] ok had to create the right log subdir too [22:21] now running ;) [22:21] how long is that supposed to run ;)? [22:21] 27873 asac 20 0 76256 2212 364 R 99.1 0.5 0:15.12 base_unittests [22:21] running [22:22] at most 10 min [22:22] on your system ;)? [22:22] hehe [22:22] ok let me take a quick break [22:22] no, it's the timeout [22:22] then finish a few specs [22:22] hmm ok [22:22] already more than a minute CPU time ;) [22:23] maybe 10min is not enough to run normally on arm [22:23] the log file shoud grow [22:23] +l [22:25] http://paste.ubuntu.com/331343/ [22:25] thats what is at end atm [22:25] so its either stuck ... at end ... or woking on getting OOM [22:27] fta: its already defunct [22:27] but looping [22:27] http://paste.ubuntu.com/331345/ [22:41] hm, but it run-test still running? [22:41] it runs forever [22:42] i restarted in the meantime [22:42] so ask in 6 minutes or so ;) [22:42] (karmic)asac@jocote:~$ ls -l /tmp/log/build-tree/src/sconsbuild/Release/base_unittests.txt [22:42] -rw-r--r-- 1 asac warthogs 29575 Nov 29 22:37 /tmp/log/build-tree/src/sconsbuild/Release/base_unittests.txt [22:42] (karmic)asac@jocote:~$ date [22:42] so latest at 2247 [22:42] Sun Nov 29 22:42:16 UTC 2009 [22:42] it should stop, right? [22:42] strange, next time, run it with sh -x [22:42] i ran a killall base_unitttests after killing the process [22:42] that left a gdb process still running [22:43] k [22:44] well, if the 1st instance died, i re-run it in gdb, so you have to be patient before killing everything [22:44] how patient? [22:44] 20muntes? [22:45] is that a new log i can check for progress? (with gdb) [22:45] [----------] 14 tests from OutOfMemoryTest [22:45] [ RUN ] OutOfMemoryTest.New [22:45] [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads. [22:45] thats really the end from what i can see [22:45] maybe that warning is FATAL? [22:45] ok 10 minutes almost past ... [22:45] * asac waiting [22:47] ok 10 minutes done -> gdb appeared [22:47] thats correct, right? [22:47] during your build, the script properly exited, but with some processes left behind, so here, the script should terminate itself normally too [22:47] [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads. [22:47] Timeout: aborting command ``./build-tree/src/sconsbuild/Release/base_unittests'' with signal 9 [22:47] Killed [22:47] so the killing worked a bit [22:47] the defunct proc is gone at least [22:48] now i got ## list of FAILED tests: [22:48] [ FAILED ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (792 ms) [22:48] good [22:48] and no zombie, gdb, whatever? [22:49] the killall i asked you to add has a -v, to show if it has catched something [22:50] http://paste.ubuntu.com/331357/ [22:50] fta: gdb is now active [22:51] and apparently under gdb we have a new defunct too [22:51] kind of expected [22:51] so after another 10 minutes this will finish? [22:51] 10min max for a run, so 10min minus the running time [22:52] the process with zombie is already dead and gdb keeps on going ... [22:52] anyway 4 more minutes at max with gdb i hope [22:52] lets see [22:53] xul-ext-adblock-plus ? wtf [22:53] oh, debian [22:53] why am i getting all those debian bug mails? [22:53] subscribed to pkg-moz-extmaintainers or something list? [22:54] maybe they have that list as maintianer and then mails go there [22:54] or its mozillateam malining list ;) [22:54] we still get the icedove mail there [22:54] (next upload will fix that) [22:54] it's the m-t mailing list [22:55] from mozilla-devscripts [23:07] fta: test ended [23:07] [ FAILED ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (792 ms) [23:07] ---- crash logs ---- [23:07] Killed base_unittests(29141) with signal 9 [23:07] Killed base_unittests(29433) with signal 9 [23:07] no process left [23:07] great [23:07] hmm [23:07] asac 17020 1 0 18:37 ? 00:00:01 Xvfb :99 -screen 0 640x480x8 -extension Composite -nolisten tcp [23:07] asac 19033 1 0 19:19 ? 00:00:01 Xvfb :100 -screen 0 640x480x8 -extension Composite -nolisten tcp [23:07] asac 22097 1 0 19:51 ? 00:00:01 Xvfb :104 -screen 0 640x480x8 -extension Composite -nolisten tcp [23:08] asac 22348 1 0 20:01 ? 00:00:01 Xvfb :106 -screen 0 640x480x8 -extension Composite -nolisten tcp [23:08] asac 22368 1 0 20:01 ? 00:00:00 Xvfb :107 -screen 0 640x480x8 -extension Composite -nolisten tcp [23:08] those are still running [23:08] i guess those were started during tests, but never killed [23:08] anything i should do before killing those? [23:08] fta: ? [23:16] 3 [23:16] 2 [23:16] 1 [23:17] killed ;) [23:33] based on the time, yeah, from your previous attempts [23:33] fta: is trunk fixed for you with the funny characters? [23:34] asac, ^^, it seems i should kill that too, but the tricky part is to kill only ours [23:34] micahg, no idea, i only see that at work, and i'm at home [23:34] ah, ok [23:38] fta: I'm having songbird build it's own sqlite, hope that and a patch refresh will fix it [23:39] I need help [23:39] every time i load firefox i get this [23:39] Could not initialize the application's security component. The most likely cause is problems with files in your application's profile directory. Please check that this directory has no read/write restrictions and your hard disk is not full or close to full. It is recommended that you exit the application and fix the problem. If you continue to use this session, you might see incorrect application behaviour when accessing security [23:39] features. [23:40] rcmaehl_linux: is your home partition full? [23:45] no [23:45] and the guys in #firefox gave me the answer [23:45] ok, bye rcmaehl_linux