[00:05]  * BUGabundo $echo moo; reply: foobed
[00:16] <fta> asac, so i just cheated: http://paste.ubuntu.com/231824/
[00:25] <asac> great ;)
[00:25] <asac> very good and responsibly;)
[00:34] <fta> asac, ??
[00:34] <fta> in v8, does it even work?
[00:34] <fta> +soname=on
[00:34] <fta> +export soname
[00:35] <fta> it probably doesn't..
[00:42] <asac> fta: it does here. but not perfectly
[00:42] <asac> e.g. the links and stuff are not created. just the soname added
[00:42] <fta> it's supposed to be an argument for scons, not an env var
[00:42] <asac> fta: oh yeah
[00:42] <fta> but well, who knows with scons
[00:42] <asac> fta: i figured that out by now ;)
[00:43] <asac> thought i already updated the branch
[00:43] <fta> nope
[00:43] <asac> yeah. will do. currently checking out bleeding_edge
[00:43] <asac> trunk has no landings for 10 days ;)
[00:45] <asac> wow .. that takes ages.
[00:45] <asac> i have the feeling i am trashing my hide all patch right now
[00:45] <asac> in git-svn
[00:45] <fta> we should probably just take: wget -qO- http://src.chromium.org/svn/trunk/src/DEPS | grep //v8 | cut -d'"' -f2
[00:46] <asac> fta: yes. the idea is to use the branches
[00:46] <asac> fta: why i ended up doing this is another story
[00:46] <asac> i wanted to test rebasing
[00:46] <asac> and then found that nothing has landed since i prepared the patch
[00:47] <asac> also thought i might test amd64
[00:47] <fta> so we always have the v8 suitable for chromium, not some crazy stuff that will no work as system lib
[00:47] <fta> not
[00:47] <asac> well. if  chromium flips branches like mad we shouldnt follow chromium i think
[00:48] <asac> if its a maintainable way they proceed then yes.
[00:48] <asac> only future can tell. for now i think the stable branches is right approach. also before doing anything we need to see how the ABI/API breakage is ... but for that i had to hide all symbols
[00:53] <fta> they always use the same branch, they just bump the revid
[00:53] <asac> let me commit a few things
[00:53] <asac> yeah
[00:54] <fta> i wanted to enable v8 daily
[00:54] <asac> i think we need to get a feeling how it goes. i expect them to merge new stuff to the branch quite short before they need it
[00:54] <asac> we will see what happens if we bump ahead a few days (if we really use syslib in chromium at some point)
[00:55] <asac> so in theory they shouldnt break abi/api on branches; if we assume that thats the case it should work to just bump to that branch daily
[00:58] <fta> hm.. can i pass arguments to debian/rules from the bzr bd command line?
[00:58] <asac> fta: well. if you can do that with dpkg-buildpackage or debuild then yes
[01:01] <fta> can't find how
[01:03] <asac> fta: can you check if a bzr bd on current v8 builds?
[01:03] <asac> or at least gets the patches applied
[01:04] <asac> (i have some confusion here with the branches and tarballs i have)
[01:04] <asac> fta: dont do it ;)
[01:04] <asac> i forgot the new file in the patch
[01:06] <fta> asac, http://paste.ubuntu.com/231962/
[01:07] <asac> yes
[01:07] <asac> thats added now
[01:07] <asac> let me check if the build finishes
[01:09] <asac> i think i think i think
[01:09] <asac> i forgot even more
[01:12] <asac> fta: what do you think: should we really add all the hidden wrappers to the tree?
[01:12] <asac> or rahter one file with a list of headers that should be wrapped in obj/... ?
[01:12] <asac> on demand?
[01:12] <asac> for me the list sounds more reasonable
[01:13] <fta> asac, you should file a bug upstream and expose the options, would be a loss to invest time in the wrong direction
[01:14] <fta> i can try to pull some strings if needed
[01:16] <fta> asac, doesn't link here
[01:17] <fta> building chromium with -j4 on my quad core doesn't help, it was already burning all the cores
[01:17] <asac> fta: yes. because of hte headers
[01:18] <fta> missing malloc
[01:18] <fta> http://paste.ubuntu.com/231990/
[01:24] <asac> yes its the missing sysheader thing
[01:24] <asac> $ bzr commit -m "* add create-sysheaders.sh utility script for shlibtype=\"hidden\" - update debian/patches/hidden.patch
[01:24] <asac> * explicitly run create-sysheaders.sh in post-patches:: - update debian/rules"
[01:24] <asac> Committing to: bzr+ssh://bazaar.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head/
[01:25] <asac> modified debian/rules
[01:25] <asac> modified debian/patches/hidden.patch
[01:25] <asac> but now i have to check whats up with the soname ;)
[01:25] <asac> Committed revision 28.
[01:25] <asac> so now it builds
[01:26] <asac> there is one bug left:
[01:26] <asac> http://paste.ubuntu.com/232017/
[01:26] <asac> hmm
[01:27] <asac> i think for the suffix versioned soname type we shouldnt modify the libname at all
[01:27] <asac> and the links should the be created differently
[01:27] <asac> (not sure how with cons)
[01:27] <asac> scons
[02:14] <asac> fta: i think the dailies would be ready to go
[02:21] <fta> hm, no LOCAL_BRANCH :(
[02:22] <asac> fta: just saw that the DEPS actually matches the last commit on 1.2
[02:22] <asac> 18 tests failed
[02:22] <asac> out of 800+
[02:22] <asac> not sure if that is bad
[02:23] <asac> i had a flawless run a few days ago iirc
[02:25] <asac> at least that number is reproducible ;)
[02:27] <fta> done
[02:30] <fta> asac, is that with x64 or still ia32?
[02:33] <asac> patch work xul 1.9.1: http://paste.ubuntu.com/232156/
[02:33] <asac> patch work ffox 3.5: http://paste.ubuntu.com/232158/
[02:34] <asac> patch work xul 1.9.2: http://paste.ubuntu.com/232162/
[02:35] <asac> wrong, but patch work xul 1.9.2: http://paste.ubuntu.com/232163/
[02:36] <asac> patch work ffox 3.5: http://paste.ubuntu.com/232168/
[02:36] <asac> err 3.6
[02:36] <asac> hehe
[02:36] <asac> fta: no thats with 32 i think
[02:36] <asac> i havent tweaked anything
[02:36] <asac> so the posts above show how many times we touch a patch ;)
[02:37] <fta> yeah, i complained about nspr_flags_by_pkg_config_hack.patch many times, even today
[02:38] <asac> the leader is: 11 - debian/patches/bz472807_att356161_nspr_nss_pc.patch
[02:38] <asac> in 1.9.2 xul
[02:38] <fta> mozilla 472807
[02:39] <asac> i cant remember what the problem was. it was some dump compatibility thing
[02:39] <asac> i think we should just drop it and see if ffox build blows up
[02:39] <fta> mozilla 290726
[02:40] <fta> pff 2005
[02:40] <fta> still NEW
[02:40] <asac> debian/patches/dont_depend_on_nspr_sources.patch
[02:41] <asac> i think we should file a bug about that
[02:42] <asac> why would that thing live in nsprpub
[02:42] <asac> i thin it should be top-level
[02:43] <fta> yep, but since hg, this is no longer really needed as we have the full src tree
[02:43] <asac> for debian/patches/bz472807_att356161_nspr_nss_pc.patch
[02:43] <asac>  i am not sure if maintaing all the header links will be less painful
[02:43] <asac> guess they should be auto generated
[02:45] <asac>  debian/patches/bz321315_gconf_backend_for_19.patch
[02:45] <asac> i think that one isnt used anymore
[02:45] <fta> v8 all done, all green \o/
[02:45] <asac> hehe
[02:45] <asac> you mean the package or upstream?
[02:45] <asac> ;)
[02:45] <fta> do you that the symbols file?
[02:45] <fta> there https://edge.launchpad.net/~chromium-daily/+archive/ppa
[02:45] <asac> 5 - debian/patches/rename_venkman_addon.patch
[02:46] <asac> fta: that was a quick build
[02:46] <asac> fta: yes, i added symbols
[02:46] <asac> but i dont think its enough
[02:46] <asac> to detect binary bustage
[02:47] <asac> maybe we could keep the old test binaries of the first run and then locally run them against the new lib
[02:47] <asac> and if we get abi/api problems this means we need to bump something
[02:48] <asac> but the amount of symbols is not really extraordinary high
[02:48] <asac> they clearly marked exported ones and its just n8.h
[02:48] <asac> v8.h
[02:49] <fta> c++ is ugly
[02:49] <fta> _ZN2v816FunctionTemplate31SetNamedInstancePropertyHandlerEPFNS_6HandleINS_5ValueEEENS_5LocalINS_6StringEEERKNS_12AccessorInfoEEPFS3_S6_NS4_IS2_EES9_EPFNS1_INS_7BooleanEEES6_S9_ESI_PFNS1_INS_5ArrayEEES9_ES3_@Base
[02:49] <fta> pff
[02:49] <asac> yeah
[02:49] <asac> at least that string hcanges if the signature changes
[02:52] <asac> commits to v8.h: http://paste.ubuntu.com/232197/
[02:53] <asac> v8-debug.h: http://paste.ubuntu.com/232198/
[02:53] <fta> no -c4 in your rules file?
[02:57] <asac> -c?
[02:58] <asac> not sure if v8 rules is actually mine ;)
[03:02] <fta> i mean, something like DEB_DH_MAKESHLIBS_ARGS += -- -c4
[03:03] <fta> so dpkg-gensymbols complains about new symbols and ftbfs
[03:03] <fta> so we notice
[03:05] <asac> i think i remember ;)
[03:26] <asac> fta: do we need the -- ?
[03:38] <fta> pixman/debian/rules:    dh_makeshlibs -a -V 'libpixman-1-0 (>= 0.10.0)' -- -c4
[03:38] <fta>  /usr/share/cdbs/1/rules/debhelper.mk:   $(if $(is_debug_package),,dh_makeshlibs -p$(cdbs_curpkg) $(DEB_DH_MAKESHLIBS_ARGS))
[03:38] <fta> -c4 is not for dh_makeshlibs, it's for dpkg-gensymbols so yes, we need --
[03:39] <fta> ok, i'm tired, eyes closing, 'night
[03:41] <asac> k
[03:41] <asac> me too
[08:05] <EruditeHermit> fta: any response on your o3d thread?
[11:36] <BUGabundo> ola gente bonita
[11:37] <BUGabundo> asac: hacking V8 ?
[11:37] <asac> hehe
[11:37] <asac> not reall
[11:37] <asac> y
[11:37] <asac> using it / comparing it with mozjs
[11:38] <BUGabundo> ah
[11:38] <BUGabundo> so your vacations are spend hacking code
[11:38] <BUGabundo> :p
[11:38] <asac> my vacations? ;)
[11:38] <BUGabundo> I wish I had vacations! :(
[11:39] <BUGabundo> aren't you on vacations ?
[11:39] <asac> today is weekend
[11:39] <asac> no
[11:39] <asac> i am on weekend ;)
[11:39] <BUGabundo> at least that was what I gathered from yesterday logs
[11:39] <BUGabundo> and what rick said
[11:39] <asac> nah. i went out for a while drinking beers
[11:39] <asac> ;)
[11:39] <BUGabundo> ohh every weekend *is* weekend :)
[11:39] <BUGabundo> oh
[11:39] <asac> normal friday night action ;)
[11:39] <BUGabundo> so I lost another drunku party?
[11:40] <asac> hehe. no. it was just a few beers with a friend
[11:40] <BUGabundo> _action_ ahaha
[11:40] <asac> and then i played ETQW ;)
[11:40] <BUGabundo> a dady friend?
[11:40] <BUGabundo> *lady
[11:40] <asac> like that yeah.
[11:40] <asac> today i will go with a friend who drinks much more
[11:40] <BUGabundo> oh forgot to say yesterday
[11:40] <asac> ... usually ending with whiskey ;)
[11:40] <BUGabundo> maybe I'll file a bug
[11:41] <BUGabundo> but Modem Manager sucks when you want to reconect
[11:41] <asac> BUGabundo: thats something i observed too
[11:41] <BUGabundo> instead connecting it just disconeects
[11:41] <asac> BUGabundo: bit i havent found the time to check whats different
[11:41] <BUGabundo> maybe it needs a longer timeout
[11:41] <BUGabundo> and retry latter
[11:41] <asac> hmm
[11:41] <BUGabundo> instead instante
[11:41] <asac> for me it was hard to reconnect at all
[11:41] <BUGabundo> not for me
[11:42] <BUGabundo> but 70% of my connects end with zero traffic
[11:42] <BUGabundo> so I have to reconnect
[11:42] <asac> option?
[11:42] <BUGabundo> and then end up with it desconectign me intead connecting
[11:42] <BUGabundo> asac: yeah I think so,
[11:42] <asac> but you are able to connect after that happens
[11:42] <asac> (triyng multiple times)
[11:42] <asac> ?
[11:42] <BUGabundo> yeah
[11:43] <BUGabundo> no prob there
[11:43] <asac> thats not that bad then
[11:43] <BUGabundo> right
[11:43] <BUGabundo> I don't worry too much
[11:43] <asac> i had problems with my option card (a real option one, not a huawei option)
[11:43] <asac> to reconnect at all
[11:43] <BUGabundo> what sucks is not conecting with zero bytes (maybe bad DNSs)
[11:43] <asac> so needed unplugging or somethign
[11:43] <BUGabundo> but the fact I press conect and it disconects me instead (when I was already connected)
[11:44] <asac> BUGabundo: hmm. bad dns should not happen if you have setup your connection using the wizard (which overwrites dns entries statically)
[11:44] <BUGabundo> I never have to uplug mine
[11:44] <BUGabundo> but many many times between midnight and 1am it won't connect
[11:44] <BUGabundo> I think its ISP doing somehting
[11:44] <asac> could be
[11:44] <BUGabundo> I just use wiz
[11:44] <BUGabundo> brb
[11:44] <asac> BUGabundo: did you observe the same with 0.7.1?
[11:44] <asac> ok
[11:44] <asac> i have to get coffee too
[11:45] <asac> and maybe buy myself a new keyboard. this one starts to get boring ;)
[11:53] <BUGabundo> back
[11:53] <BUGabundo> asac: I'm using 0.8 ppa
[11:53] <BUGabundo> and yeah .7 behaved similar AFAIR
[11:54] <asac> ok then its not the same problem that i saw
[11:55] <BUGabundo> asac: and this from memory, and I have none
[12:33] <BUGabundo> asac: users on +1 are asking about th favicon for FF
[12:33] <BUGabundo> its the old one, and Windows as the new one
[12:33] <BUGabundo> is it uptream brandign missing or is it us?
[12:34] <asac> favicon?
[12:34] <BUGabundo> yeah
[12:34] <asac> thats usually sent by the website
[12:34] <BUGabundo> on the search bar
[12:34] <asac> its the one you see in the location bar
[12:34] <BUGabundo> err
[12:34] <BUGabundo> no
[12:34] <BUGabundo> look at your FF
[12:35] <BUGabundo> I see the old one
[12:35] <BUGabundo> and a new on the awesome bar
[12:38] <BUGabundo> bbl
[12:44] <asac> h m
[12:45]  * asac wonders if we should use nspr 4.8 in SRU
[12:45] <asac> i gues rather 4.7.5
[12:49] <asac> bug 387812
[12:49] <asac> bug 387745
[13:52] <asac> mozilla bug 471715
[14:45] <asac> ok nss and nspr backports to hardy/intrepid done. that will be a heroic act for chrome i hope ;)
[14:48] <eagles0513875> morning  asac
[14:50] <asac> hi
[16:18] <asac> fta: if the dailies are already fully done, could you kick off another v8 run (i seem to have missed it by a few minutes i guess)
[16:19] <asac> libv8-dev wasnt installable because it referred to libv8 and not libv8-0
[16:27] <asac> fta: do you know if i can tell the build systgem to spit out the actual gcc commands ?
[16:27] <asac> (chromium-browser9
[18:18] <maco> reading asac's blog... is multisearch only on firefox-3.0 and not firefox-3.5?
[18:35] <dtchen> it appears as an active addon in my 3.5.2
[18:35] <dtchen> grr. 3.5.1*
[18:37] <dtchen> so, both -3.0 and -3.5
[18:37] <maco> hm. maybe i need to update then quit and restart firefox then...
[19:03] <asac> ldd sconsbuild/Release/ui_tests | grep v8  libv8.so.0 => /usr/lib/libv8.so.0 (0xf72d4000)
[19:04] <asac> nm -D sconsbuild/Release/ui_tests  | grep v8 | pastebinit
[19:04] <asac> http://paste.ubuntu.com/233340/
[19:05] <BUGabundo> echo: FAIL
[19:25] <asac> ldd sconsbuild/Release/chrome| grep v8 libv8.so.0 => /usr/lib/libv8.so.0 (0xf7301000)
[19:25] <asac> rock & roll
[19:25] <asac> will clean this mess up and then commit it
[19:25] <asac> tomorrow ,)
[20:27] <asac> system chromium stuff committed
[20:27] <asac> err, v8
[20:28] <asac> fta: is GYP_DEFINES what allows me to pass in settings referred to in .gypi files?
[21:48] <asac> cp: cannot stat `./debian/tmp/usr/lib/chromium-browser/mksnapshot': No such file or directory
[22:07] <bdrung> asac: can you have a look at adblock-plus 1.1? https://code.launchpad.net/~bdrung/firefox-extensions/adblock-plus.ubuntu/+merge/6989
[22:07] <bdrung> asac: I have prepared the package for it.
[23:11] <asac> bdrung: lp doesnt show any diff ... odd
[23:13] <bdrung> asac: then grab it via "bzr branch lp:~bdrung/firefox-extensions/adblock-plus.ubuntu"
[23:13] <asac> yeah i know
[23:13] <bdrung> asac: generating the source package does not seam to work.
[23:14] <asac> does not seem to work?
[23:14] <asac> let me check
[23:14] <bdrung> i have to create it manually via bzr export
[23:15] <bdrung> asac: i only changed the export-upstream-revision revid. the last time it worked.
[23:19] <asac> bdrung: why is clean not needed? did we add that to xpi.mk?
[23:20] <bdrung> asac: probably. without the clean target all generated files were removed.
[23:26] <bdrung> asac: thx
[23:26] <asac> bdrung: that was a typo from what i see
[23:26] <asac> Merge -> merge fixed it
[23:27] <bdrung> oh, yes
[23:28] <bdrung> asac: can you have a look at https://bugs.launchpad.net/ubuntu/+source/stanford-pwdhash/+bug/399036 (new release of pwhash)
[23:29] <bdrung> asac: now i maintain the debian package of pwdhash
[23:30] <asac> bdrung: do you build this from some branch for debian?
[23:31] <asac> would be easier to maintain a ubuntu branch based on debian branch i guess
[23:31] <asac> devscripts will hopefully soon be in debian ;)
[23:31] <asac> its also in NEW
[23:32] <bdrung> asac: the debian package is currently waiting in NEW, you can grab the package from http://mentors.debian.net/debian/pool/main/p/pwdhash/pwdhash_1.7-2.dsc (it's identical from the package in NEW)
[23:32] <bdrung> asac: you can use the pwdhash git branch, too.
[23:34] <bdrung> asac: when devscripts hits unstable i will upload a 1.7-3 version, which probably won't need ubuntu changes.
[23:34] <asac> i would think we have enough time still; its better to not go through our NEW review and then also through Debian imo
[23:34] <asac> syncing from debian doesnt need any review
[23:35] <asac> unless you say you really want to have it in now ;)
[23:35] <asac> or that you might forget ... or busy or something later
[23:35] <asac> then we can probably do it
[23:35] <bdrung> no, we don't need to hurry.
[23:36] <bdrung> i have uploaded the package to my ppa, so i hopefully will not forget it.
[23:36] <asac> bdrung: are you doing this together with the debian ext-mainatinaer team?
[23:37] <bdrung> ext-maintainer?
[23:39] <asac> [Pkg-mozext-maintainers]
[23:39] <asac> bdrung: ^^
[23:39] <asac> there is a team for mozext
[23:39] <asac> that are drafting standards etc. now
[23:40] <bdrung> no, this is the first time i hear of it.
[23:40] <asac> we had some predicussion and seemed like they are making progress; somewhat reinventing the wheel, but well ... :)
[23:40] <asac> i am happy that they do something in debian
[23:41] <asac> also we will probably be able to resync where we ship what
[23:41] <asac> so the locations will be changed soonish
[23:41] <asac> but the outcome is actually pretty smart; we can automatically determine in which/app to link the extension and so on
[23:41] <bdrung> sounds good.
[23:43] <bdrung> asac: i am currently preparing mozgest