[00:00] there's no soname [00:01] apparently, the shared lib magic from scons is still far from libtool [00:01] fta: we should really encode the tag in changelog for new upstream revisions [00:01] didn't I ? [00:02] i thought i did... [00:02] fta: nss.head? [00:02] dont see it [00:02] just the version. but hard to guess without version scheme [00:02] but we are bad about that for other branches to i guess [00:02] at least in nspr.head [00:04] ack. can confirm that its in nspr.head [00:04] ok so just a glitch ;) [00:06] the great fear of having nspr/nss diverged in xul trunk was unfounded. they are in sync, i think i can go back to system lib in trunk [00:06] we should also revisit the in-source libjpeg [00:07] and we must update system sqlite, ours is old now [00:07] asac: task #1 ready : https://code.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/+merge/1727 [00:19] fta: well. i dont mind about system libs or not. i just think that nss will move ahead once they have RTM [00:20] rzr: next time please create the new upstream changelog when doing the merge [00:20] in practice, they bump nss and nspr in branch and trunk at the same time [00:20] e.g. in revision 11 you could have created new UNRELEASED changelog entry with just [00:20] * new upstream release (...) [00:20] fta: how about ffox 2? [00:21] i don't know, i don't monitor it [00:21] was that migrated to latest 3.12 ? [00:21] * asac looks [00:21] fta: http://mxr.mozilla.org/mozilla1.8/source/client.mk#261 [00:21] so that means that they will move ahead ;) [00:22] sooner or later ;) [00:22] ix:~/bzr/build-area/chromium-v8-0.4.3.1~svn20081105r696$ scons library=shared sample PREFIX=/usr DESTDIR=debian/tmp install [00:22] scons: Reading SConscript files ... [00:22] scons: done reading SConscript files. [00:22] scons: Building targets ... [00:22] scons: Nothing to be done for `sample'. [00:22] Install file: "libv8.so" as "debian/tmp/usr/lib/libv8.so" [00:22] scons: done building targets. [00:22] double shot of \o/ [00:22] good ;) [00:22] rzr: why the orig rule=? [00:23] but they can't do shared and static in on shot.. [00:23] rzr: we dont want to produce orig.tar.gz, but produce an updated .upstream branch [00:23] this help to generate the upstream tarball for debian [00:23] i try to merge it as best as possible [00:24] is it annoying ? [00:25] rzr: why use a different orig for debian than for ubuntu? [00:25] e.g. both can be generated from branches [00:26] rzr: problem is that people see that and use that for ubuntu [00:26] i am sure ;) [00:26] and then things become messy [00:26] it's troll time :) [00:26] e.g. we get uploads with bzr [00:27] anyway I can remove this part if needed [00:27] rzr: is README.source relevant if you have the get-orig-source code? [00:28] README seems mandatory [00:29] since the user will know where his software come from [00:29] rzr: yeah. but the content should be correct. it should read: "to build orig.tar.gz run ./debian/rules get-orig-source " [00:29] It's in policy IICR [00:30] current content looks like it duplicates the content in debian/rules ... at best [00:30] I am not sure, policy ask to put address of the upstream tarball [00:30] am i right ? [00:30] and debian/rules is not installed on user system [00:31] asac, http://www.scons.org/wiki/SconsVsOtherBuildTools [00:31] I'll remove get-orig-source if you want [00:31] not README.source :) [00:31] or you have to kill me :) [00:32] rzr: keep get-orig-source .... and add how to use debian/rules to reproduce current orig.tar.gz in a first paragraph [00:32] and keep the full explanation in a 2nd paragraph: "how to get the upstream source manually" [00:32] this will fail tests [00:33] desert island test etc ... [00:33] not sure what you mean [00:33] the full instruction will still be in [00:33] not in the deb file [00:33] just add a 1st instruction [00:33] in the patch file [00:33] in other words [00:34] rzr: read what i wrote [00:34] two paragraphs: [00:34] the upstream source will not visible from : /usr/share/doc/flashblock [00:34] 1st. how to use get-orig-source [00:34] 2nd. how to do it manually [00:34] ok [00:34] 2nd == what you currently have [00:34] it's ok for me [00:35] but imo the desert island test is about licenses [00:35] and not about orig ;) [00:35] if you are on a desert island you wont be able to access upstream repos anyway ;) [00:35] so the only source you might have is the orig.tar.gz on a source CD/DVD [00:35] no but I can write a book and put a reference to him [00:36] and rely on the fact that policy ask this to be mentionned in copyright file [00:37] not sure i understnad ;) [00:37] well it's late :) [00:37] but dont mind ... if you add the 1st paragraph ... and also a hint about upstream branch ;) [00:37] thats ok [00:37] ok perfect [00:38] upstream branch ? ubuntu one I guess, using bzr-buildpackage i guess ? [00:38] debian guys will hate me :) [00:39] rzr: later things will be released to debian from there too [00:39] mozilla-devscripts will go up [00:39] and then there is no reason not to directly upload there [00:39] rzr: no not how to build from branch ... instruuction how to update .upstream tree [00:40] on LP right ? if some ubuntu+debian DD can sponsor FB to debian this will be perfect for me [00:41] else any reference to LP or ubuntu will make me loosing my time to the debian guys... [00:42] oh well, [00:50] ok keep it out of that then. [00:50] but i think it should be in [00:50] but until -devscripts is in debian its not really needed to name it [00:53] http://rzr.online.fr/volatile/tmp/README.source [00:53] is the branch name correct ? [00:53] because I am the owner not a motu ou core developper [00:55] rzr: thats ok. use the code.launchpad.net url instead [00:55] (so yuo can directly navigate using browser) [00:55] ok this is safer [00:55] huh? [00:55] rzr: https://code.launchpad.net/~rzr/firefox-extensions/flashblock.upstream [00:58] I thought about only : https://code.launchpad.net/firefox-extensions [00:58] since it can move [00:58] if I'm killed by a debian integrist or ubuntu terrorist [00:59] nevermind [01:06] asac: let me wish you a good night and thanks for your explanations I appreciated [01:06] btw, the branch is ready === rzr is now known as rZr [01:13] rZr: the upstream version is wrong [01:13] 1.3.11.a [01:13] where did you get that from? [01:14] that should be 1.3.11a [01:14] there is a bug [01:14] there are 2 files [01:14] install.rdf and install.js [01:14] yes. install.rdf should match [01:15] it doesnt [01:15] i used install.js instead [01:15] should this be reported upstream ? [01:15] 1.3.11.a [01:17] rZr: yes. please ask "ted" on irc.mozilla.org [01:17] maybe do that tomorrow [01:17] ok [01:19] commented that on the merge [01:46] dpkg-shlibdeps: warning: couldn't find library libxpcom.so needed by debian/firefox-3.0/usr/lib/firefox-3.0.4/components/libbrowserdirprovider.so (its RPATH is ''). [01:46] fta: ^^ ;) [01:46] whats that? [01:46] did we always have that= [01:47] hmm [01:47] maybe local xulrunner dir [01:48] ok [01:48] its ok [01:48] yes, for ages, maybe forever [01:49] sure [01:49] was confused by libxpcom.so for amoment [01:49] forgot that its not wrapped into libxul.so [01:50] i have no idea of how to teach scons to do the libfoo.so -> libfoo.so.X.Y.Z [02:00] or to use a soname [02:00] fta: soname is usually just ldflag [02:01] yes but i don't call ld myself [02:01] hm, maybe i can pass a flag somewhere [02:01] nv['NUMPY_PKG_CONFIG'][libname].version [02:01] env['NUMPY_PKG_CONFIG'][libname].version [02:02] http://www.opensync.org/ticket/467 [02:03] At the moment we're lacking at SO-NAMING support in our scons environment. Sorry about that .. the implementation of SO-NAMING support in our scons env is planned. I don't recommend to package 0.30 yet .. it's only interesting for developers and advanced testing and maybe for packagers which need some time to get familiar with scons. [02:04] env.SharedLibrary ('target', sources, RPATH = "/usr/lib", SHLINKFLAGS = env['SHLINKFLAGS'] + ' -Wl,-soname=$TARGET') [02:05] thanks, i'll have a look [02:08] i have the feeling that it really lacks support for it [02:08] there is just: SHLIBSUFFIX [02:08] cannot see that it does magic from soname or seomthing and creates the appropriate links [02:08] i think we should add SHLIBVERSION [02:08] or something [02:09] appaned that to SHLIBSUFFIX [02:09] and create the appropriate links [02:10] i think the author of scons is in the #chromium channel, i'll ask him next week [02:10] how should i name the v8 package ? chromium-v8 / chromium-v8-dev ? libv8 / libv8-dev ? [02:11] fta: do we have a chromium-v8 project? [02:11] i still think we hsould have one [02:11] not yet, i'm not ready to push any of the branches [02:11] then ship stuff in chromium-v8 source and produce libv8* [02:11] binaries [02:12] not libv8-0 ? or something like that? [02:13] not sure [02:13] but including a version should be ok [02:22] next step will be to teach chromium how to use system v8 [02:24] asac, well, 1st attempt (still without the soname stuff): http://paste.ubuntu.com/72660/ [02:27] asac, http://paste.ubuntu.com/72662/ [02:29] fta: ok. do you gen-symbols? [02:29] ? [02:30] to track symbols [02:30] of lib [02:30] no, not yet [02:30] k [02:31] i should try to upstream my patches asap [02:31] i feel this one will be tricky [02:47] "To work with the V8 code you need to download and build the development branch. Active development of V8 takes place on a branch, branches/bleeding_edge, from which we push "green" versions that have passed all tests to trunk/ every week or so. " [02:47] interesting, trunk is not HEAD :) [02:51] yeah ... but trunk is most likely what is wanted for HEAD packaging :-P [02:53] yes, i have not plan to package "bleeding_edge" but this is mandatory to create patches against it to upstream them [02:56] if its once a week the diff shouldnt be that massive usually === Sergeant_Pony is now known as KB1OHY [03:20] gen-symbols is impossible without soname [11:46] asac: http://rafb.net/p/NEqexh24.html [12:15] asac: http://rafb.net/p/twPPKg34.html <- this one better [14:15] insane [14:15] my IRC system just hang [14:16] it hung up over night and didnt work until i plugged in a monitor and rebooted. all fine [14:17] lets hope that this isnt the beginning of the end [14:17] http://de.youtube.com/watch?v=yX8yrOAjfKM&feature=bz301 [14:17] The Matrix Runs on Windows -> Ubuntu ;) [14:20] so obviously if there was any ping or such ... dont expect an answer :) [14:21] * directhex pings asac [14:23] heh [14:49] armin76: SIGBUS [14:49] please reproduce [15:05] @time [15:05] Current time in Etc/UTC: November 16 2008, 15:05:05 - Next meeting: Americas Regional Board in 1 day [15:05] reconnect [15:11] asac: http://rafb.net/p/NEqexh24.html [15:11] asac: http://rafb.net/p/twPPKg34.html <- this one better [15:11] armin76: thats the unpatched crash [15:11] ;) [15:11] armin76: now we need to get the other ;)( [15:11] oh [15:12] the first one is new [15:12] the first one is when starting with a fresh profile [15:12] armin76: first one is probably useless because of corrupt stack [15:12] scary [15:14] the second is with an used profile, because gdb-6.8 doesn't seem to want to run it when creating the profile, dunno why [16:49] i'll be king [16:53] asac_the_bumber: found the issue? [16:54] nope [16:54] i just built 1.9.0.4 with debian's patch [16:55] k [17:13] in ff3.1, all my rss/atom prefs changed to preview in Shiretoko :( useless [17:19] https://edge.launchpad.net/chromium-project ... feels weird to see chromium maintained by a mozilla team.. [17:32] a chromium team would look nicer [17:35] fta: a chromium team with ubuntu mozilla team guys? ^^ [17:43] a restricted team, like mozillateam, ie, with write access to branches [17:48] asac, 1st branch: https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head [17:51] asac: upstream is about to fix the typo , I'll update it then and tell you when to merge my branch [17:57] http://www.labnol.org/internet/google-chrome-logo-design-inspiration/4414/ :) [18:00] asac: http://rafb.net/p/O7dgMn96.html <- with the patch [18:24] armin76: please post the patched nsUrlClassifierDBService.cpp [18:25] asac: http://rafb.net/p/PrTIvx80.html [18:27] armin76: imo that means that the compiler is right when it spits out warnings for nsTArray [18:27] which we ignore ;) [18:31] no u [18:31] *g* [18:36] armin76: can you please build the classifier cpp file with -Walign-cast ? [18:36] e.g. in build tree just remove the .o and so on and manually invoke the g++ line [18:39] let me build it [18:46] wow. armel is really slow ;) [18:46] https://edge.launchpad.net/+builds/prumnopitys [18:46] xul is already building more than 2 hours [18:46] and is in layout/ [18:49] mozilla-firefox-1.5.0.6: Fri Aug 11 08:35:17 2006: 13 hours, 39 minutes, 30 seconds [18:49] mozilla-firefox-2.0.0.1-r2: Wed Jan 17 06:11:48 2007: 14 hours, 36 minutes, 42 seconds [18:49] mozilla-firefox-2.0.0.4: Wed Jul 25 08:32:50 2007: 18 hours, 12 minutes, 30 seconds [18:49] armin76: where is that? [18:49] thats on a netwinder, 233mhz 128mb [18:49] on your system? [18:49] oh [18:49] well. i think this one has 500 or so ;) [18:49] not sure [18:49] mhz [18:50] yosh, enough of gimp for today, https://edge.launchpad.net/chromium-v8 [18:50] xulrunner-1.9.0.2: Thu Sep 25 18:31:18 2008: 3 hours, 15 minutes, 0 seconds <- with distcc [18:51] fta: so you took over team ownership ;) [18:51] asac: how are your holidays going? ^^ [18:51] asac, so far yes, noone else worked on this [18:51] fta: thats ok. just thought mt was team owner before [18:51] but dont care much [18:52] sebner: too much holiday ;) [18:52] isnt good [18:52] asac, it was weird to have a mozilla team owner of a competitive project [18:52] fta: well ;) [18:53] fta: but retroactively restricting team ownership isnt the best way either ;) [18:53] asac: I thought so :P btw, you forgot to comment :P bad boy. however, not necessary anymore [18:53] sebner: comment? [18:54] asac: on my application ;) [18:54] asac, well, what are non active members good for in a team? i see tons of users joining teams just to collect logos [18:55] fta: just a point that when you bump people better ask ;) [18:55] sure [18:55] asac: MOTU application. but as I said. not necessary anymore [18:58] <[reed]> fta: chromium-team should take over https://launchpad.net/googlechrome [18:58] <[reed]> :) [18:59] fta: so do we need to go for individual ownership for everything mozillateam owned now? [18:59] [reed], well, this page should be removed instead [18:59] asac, ? eh? [19:00] nm [19:00] <[reed]> fta: true, dunno how to delete it, though! [19:01] <[reed]> asac: remember, mozilla-related sessions at the latter half of UDS week, please! [19:01] yeah [19:01] <[reed]> considering I only get to MV on Tuesday afternoon ;) [19:01] asac, i just created a new team because chromium is not a mozilla project, no other reason, if you want to join, you're welcome, after all you're canonical so you can join everything [19:01] fta: didn't know that canonical entitles to join everything ;) [19:03] asac: bah :P [19:03] <[reed]> fta: I agree that mozillateam shouldn't own Chromium [19:03] [reed]: thats not the question ;) [19:03] mighty asac shouldn't be scared :P [19:03] there isnt much a question as of now ;) [19:07] [reed], it's done using questions.. Question #51560 [19:08] Question 51560 [19:08] answer 51560 [19:08] bahh [19:08] https://answers.edge.launchpad.net/launchpad/+question/51560 [19:08] <[reed]> lol [19:12] i think i won't do openkomodo, it's another xul engine with tons of patches [19:12] you should really take over debian bug 497701 [19:12] Debian bug 497701 in libv8 "RFP: libv8 -- Google V8 JavaScript Engine" [Wishlist,Open] http://bugs.debian.org/497701 [19:12] otherwise there will be duplication of effort [19:13] you already know i'm no longer interested by debian [19:14] still if debian does a package it doesnt make sense to maintain it independently here [19:14] fta: you will end up in a situation where you have rdepends on debian package getting synched here [19:14] and then you are not free anymore, but become dominated by what debian folks do to your package in debian [19:14] i don't understand why we always have to work with them but don't give a damn about our work, this is not fair [19:15] because we still sync a lot of other work from them [19:15] -but+but they [19:15] fta: right. but it saves a lot of work [19:16] fta: you need to first upload. then you can upload without being a DD [19:16] and the syncs get back here [19:16] fta: also you can circumvent all the REVU stuff ;) [19:17] just push it to debian and see how it gets here automatically ;) [19:20] asac: it doesn't give any warning [19:21] armin76: with -Wcast-align ? [19:22] asac: err, wait [19:23] asac: http://rafb.net/p/lsgB8a46.html [19:28] armin76: why is there a reinterpret cast in 2027 at all= [19:30] thats from debian's patch [20:10] https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/1.9.0.4+nobinonly-0ubuntu1/+build/788444/+files/buildlog_ubuntu-jaunty-armel.xulrunner-1.9_1.9.0.4+nobinonly-0ubuntu1_FULLYBUILT.txt.gz [20:11] Finished: 2 minutes ago (took 3 hours 50 minutes) [20:11] ^^ armin76 [20:12] asac: omgs! [20:13] well, it just took 4 hours [20:23] armel, hihi [21:23] armel 7573 builds waiting in queue [21:24] yeah. now that xul is there things can lift off [21:24] with ~1h per package, that's still one year [21:31] nah ;) [21:31] 1h is too much [21:31] average is 4min ;) [21:33] i can no longer build ff3.1 in jaunty/ppa :( [21:33] FATAL: kernel too old [21:33] http://launchpadlibrarian.net/19629359/buildlog_ubuntu-jaunty-i386.firefox-3.1_3.1~b2~hg20081113r21632%2Bnobinonly-0ubuntu1~fta2_CHROOTWAIT.txt.gz [22:14] boom http://paste.ubuntu.com/73091/ [22:33] damn; https://edge.launchpad.net/v8