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