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