[14:57] <asac> fta2: libxul-embedding == 1.9 .... libxul-embedding-1.9.1 == 1.9.1
[14:57] <fta> asac, ?
[14:57] <asac> thats at least my understanding for now
[14:57] <asac> 00:15 < fta> how can i force an app using libxul-embedding to use xul 1.9 when I have both xul 1.9 and 1.9.1  installed ?
[14:58] <fta> nope, it doesn't work
[14:58] <asac> fta: what doesnt work?
[14:59] <fta> i build with the 1.9 sdk, so with libxul-embedding but once installed, if i have 1.9.1, this is what is used
[14:59] <fta> bug 295490
[14:59] <asac> oh
[14:59] <asac> fta: yeah. fix maxVersion
[14:59] <fta> maxVersion in liferea ?
[14:59] <asac> 1.9.* was wrong ... should have been 1.9.0.*
[15:00] <asac> yeah
[15:00] <asac> in the glue code
[15:00] <fta> oh
[15:00] <fta> cool
[15:00] <asac> let me get it ;)
[15:00] <asac> sigh. my network is soooooooooooo slow
[15:00] <asac> 00:15 < fta> how can i force an app using libxul-embedding to use xul 1.9 when I have both xul 1.9 and 1.9.1  installed ?
[15:00] <asac> oops
[15:00] <asac> 1293B/s 21min21
[15:01] <asac> i think i have to reset my router
[15:01] <asac> bb
[15:02] <asac_> ok lets try ;)
[15:03] <asac_> that worked ;)
[15:03] <asac_> 2s
[15:04] <asac_> fta: ./src/mozilla/mozsupport.cpp
[15:04] <asac_> http://paste.ubuntu.com/72380/
[15:04] <asac_> ;)
[15:04] <asac_> maybe we should detect that during built
[15:06] <fta> damn, this could have saved me some hours :(
[15:07] <asac_> fta: the other way would have been to make ls /etc/gre.d/ first spit out the 1.9.0 conf
[15:07] <asac_> and not the 1.9.1 conf
[15:07] <asac_> (which i expect is the case for you?)
[15:07] <asac_> hmm
[15:07] <asac_> fta: what does ls /etc/gre.d give you?
[15:08] <fta> 1.9.0.4.system.conf              1.9.1b2pre.system.conf         2.0a1pre.system.conf  libxul0d.conf
[15:08] <fta> 1.9.1b2pre-restored.system.conf  1.9a8pre.system.conf.dpkg-bak  firefox.conf
[15:08] <asac_> a bit strange. xulrunner just tests file-by-file and first match is used
[15:09] <asac_> so 1.9.0.4.system.conf should have been used. not sure if ls always gives the same order as 'C' dir listings
[15:09] <asac_> though
[15:09] <fta> i thought it preferred the newest version, which would make sense
[15:10] <asac_> fta: from what i know it doesnt prefer newest
[15:10] <asac_> e.g. in the past i had to make 1.9.0 configs illegal to test with 1.9.1
[15:11] <asac_> personally, I agree that newest would make more sense. we should look into fixing this
[15:12] <asac_> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsGREGlue.cpp#156
[15:13] <asac> fta: http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsGREGlue.cpp#527
[15:13] <asac> so its really just readdir and then match first that suites
[15:14] <fta> in my case, 1.9.1 always wins
[15:14] <asac> fta: please do a strace -eopen -f liferea
[15:15] <asac> and check whether 1.9.0.4.conf is actually looked at
[15:15] <asac> otherwise readdir doesnt return in alphabetic order, but inode or something
[15:21] <asac> fta:        #include <sys/types.h>
[15:21] <asac>        #include <dirent.h>
[15:21] <asac> fta: http://paste.ubuntu.com/72386/
[15:21] <asac> ;)
[15:21] <asac> fta: try that code
[15:21] <asac> and see which order it gives
[15:21] <asac> here it seems like its "random" ;)
[15:21] <asac> most likely your 1.9.1 preceeds the 1.9.0 stuff
[15:22] <asac> http://paste.ubuntu.com/72387/
[15:22] <asac> ^^ thats my garbage struck dir
[16:09] <fta> i'm fighting against a scons
[16:15] <armin76> asac: any idea about my bug? :(
[16:23] <asac> armin76: which?
[16:23] <asac> armin76: i think you never came back when i looked at a bug ;)
[16:23] <asac> but now i forgot
[16:24] <armin76> yeah, had to run fsck on a reiser
[16:24] <armin76> gentoo bug 234110
[16:24] <armin76> meh
[16:24] <armin76> bug gentoo 234110
[16:24] <armin76> stupid bot
[16:25] <armin76> http://bugs.gentoo.org/show_bug.cgi?id=234110
[16:25] <asac> heh
[16:25] <asac> armin76: i would guess that those folks have a dirty install
[16:25] <armin76> why?
[16:25] <asac> its one of those things that regularly pop up
[16:25] <asac> e.g. nothing works -> reinstall works
[16:25] <asac> -> compreg.dat in pkglibdir
[16:25] <asac> or some other cruft
[16:26] <armin76> saw the strace?
[16:26] <asac> armin76: they should attach a strace -eopen -f
[16:26] <asac> no
[16:26] <asac> only see a huge list of config options ;)
[16:26] <armin76> comment 19
[16:27] <asac> yeah still
[16:27] <asac> its meaningless
[16:27] <asac> when people strip strace they always post unimportant parts ;)
[16:27] <asac> hmm
[16:28] <asac> armin76: /usr/lib/xulrunner-1.9/components/libpipboot.so
[16:28] <asac> whats taht?
[16:28] <asac> debug build?
[16:29] <asac> armin76: they should attach a complete strace -eopen -f firefox to the bug
[16:30] <armin76> dunno, i have that file, want it? :D
[16:30] <armin76> k, i'll say so, thanks
[16:30] <asac> armin76: you ahve that file?
[16:30] <asac> armin76: is that a debug build?`
[16:30] <armin76> nop
[16:30] <armin76> e
[16:31] <asac> armin76: how do you install stuff?
[16:31] <armin76> make install? :)
[16:32] <asac> armin76: well. i wouldnt trust make install to do the right thing for mozilla ;)
[16:32] <asac> armin76: that file should be wrapped into libxul.so
[16:32] <asac> and not be there
[16:32] <asac> dpkg -L xulrunner-1.9 | grep pip
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/chrome/pippki.manifest
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/chrome/pippki.jar
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/pipnss.xpt
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/pippki.xpt
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/pipboot.xpt
[16:32] <asac> dpkg -L xulrunner-1.9 | grep so$
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/libpyxpcom.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/libjemalloc.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/libxpcom.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/libmozjs.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/python/xpcom/_xpcom.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/libimgicon.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/libdbusservice.so
[16:32] <asac> /usr/lib/xulrunner-1.9.0.4/components/libpyloader.so
[16:33] <asac> /usr/lib/xulrunner-1.9.0.4/libxul.so
[16:33] <asac> /usr/lib/xulrunner-addons/plugins/libunixprintplugin.so
[16:33] <asac> /usr/lib/xulrunner-addons/plugins/libnullplugin.so
[16:33] <asac> /usr/lib/xulrunner-1.9.0.4/libnssckbi.so
[16:33] <asac> sry ;)
[16:33] <asac> armin76: which configure flags do you pass?
[16:33] <asac> --enable-optimize
[16:33] <asac> --disable-debug
[16:33] <asac> is important
[16:33] <armin76> sec
[16:34] <asac> fta: do you have a built tree lying around for xul 1.9?
[16:34] <armin76> http://rafb.net/p/5ar7KI50.html
[16:35] <fta> asac, hm, not sure, i trashed a lot of my stuff to make some room for chromium
[16:35] <fta> asac, why ?
[16:36] <asac> fta: just wondere where libpipboot.so would be lying around in it ;)
[16:36] <asac> building my own 1.9.0 stuff now
[16:36] <asac> fta: e.g. gentoo ships /usr/lib/xulrunner-1.9/components/libpipboot.so
[16:36] <asac> we dont have that
[16:36] <asac> ;)
[16:36] <asac> we have pipboot.xpt
[16:36] <asac> which makes sense and i assume that we have it in libxul.so
[16:36] <asac> armin76: do you have libxul.so at all?
[16:37] <asac> armin76: urgh. you asked for a paste of the output? ... thats really really long ;) ... attaching would have been more readable i guess
[16:38] <fta> asac, i ship components/libpipboot.so in sm2 and tb3, not in xul1.9*/ff3*
[16:39] <fta> i see i have it in my openkomodo 5 tree too
[16:39] <asac> oh
[16:39] <asac> --disable-libxul
[16:39] <asac> armin76: ^^ why that?
[16:39] <asac> fta: yeah. i think its a libxul component
[16:39] <fta> do we need that?
[16:39] <asac> so those that dont use libxul, still have it
[16:40] <asac> fta: no :)
[16:40] <asac> fta: gentoo is doing something a bit wrong imo
[16:40] <asac> --with-default-mozilla-five-home=/usr/lib/xulrunner-1.9
[16:40] <asac> i dont think that that is still needed either
[16:40] <armin76> asac: not sure
[16:41] <asac> armin76: anyway. lets wait for the strace
[16:41] <armin76> asac: yup, i have it
[16:42] <asac> armin76: you have libxul.so ?
[16:42] <armin76> yup
[16:42] <armin76> /usr/lib/xulrunner-1.9/libxul.so
[16:42] <armin76> /usr/lib/xulrunner-1.9/sdk/lib/libxul.so
[16:42] <asac> armin76: and also the .so files?
[16:42] <asac> e.g. libpipboot.so
[16:43] <armin76> yup
[16:43] <fta> booouh, that's not upstream scheme, it looks like ice*
[16:43] <asac> armin76: what size does libxul.so have for you?
[16:43] <asac> fta: huh?
[16:44] <fta> /usr/lib/xulrunner-1.9/sdk/
[16:44] <asac> fta: i dont think that debian ships all components + libxul
[16:44] <asac> fta: yeah ... a bunch of distros do it that way
[16:44] <armin76> asac: 132k
[16:45] <asac> fta: its a bit of a shame and alrewady caused discussion when people kept using -rpath
[16:45] <fta> i'm facing the same problem with chromium
[16:45] <asac> armin76: yeah thats tiny. a
[16:45] <asac> -rw-r--r-- 1 root root 18201928 2008-11-12 19:49 /usr/lib/xulrunner-1.9.0.4/libxul.so
[16:45] <asac> armin76: but is in line with the --disable-libxul thing
[16:46] <asac> not sure why there is libxul.so at all when you built that way
[16:46] <asac> armin76: but its definitly not supported upstream
[16:46] <armin76> i'm not sure where does the --disable-libxul thing comes...
[16:46] <asac> fta: what do chromium folks do?
[16:46] <armin76> oh, i see it
[16:47] <asac> armin76: have you looked at what we pass as configure flags?
[16:47] <armin76> yup, in fact i think i copied it from there :P
[16:47] <fta> asac, so far, nothing. binaries are just in the objdir and all libs are static, i'm trying to change that
[16:47] <asac> armin76: oh ;)
[16:48] <asac> fta: does upstream want to provide ABI tracked libs?
[16:48] <asac> otherwise linking them into main binary makes a bit of sense
[16:48] <fta> good question
[16:48] <fta> the binary is huge
[16:48] <fta> > 250MB
[16:48] <asac> fta: is that a problem?
[16:48] <asac> (on its own ;))
[16:49] <asac> fta: i think we would like to keep v8 in a system lib
[16:49] <fta> well, no, in the sense that it runs
[16:50] <fta> asac, i already landed some system libs: http://codereview.chromium.org/10626
[16:50] <fta> but most create regressions
[16:52] <asac> fta: why are your comments empty?
[16:53] <fta> asac, because i just updated the patch
[16:53] <asac> ok
[16:53] <fta> i like that site, it's nice to do patch reviewing
[16:54] <fta> imho, far better than bugzilla
[16:54] <asac> yean
[16:54] <fta> google splits bugs and patches
[16:56] <fta> bugzilla should learn from this ;)
[16:56] <fta> [reed], ^^
[16:56] <fta> mconnor, ^^
[16:59] <asac> armin76: what does gentoo do on unemerge? does it track files installed by make install?
[17:02] <armin76> asac: it uses a sandbox system, so it keeps track of everything merged to the real system
[17:03] <asac> armin76: do you ship .autoreg?
[17:05] <armin76> asac: http://rafb.net/p/RMgPlv30.html
[17:06] <fta> damn, patching those scons files is too much python in unknown territory. i need to step back a little bit.
[17:06] <asac> /etc/gre.d/1.8.1.18.conf
[17:06] <asac> ?
[17:07] <armin76> hrm...sec
[17:07] <asac> ok
[17:07] <asac> 1.9 is further down
[17:07] <asac> armin76: where is ffox 3?
[17:07] <asac> (only see mozilla-firefox)
[17:08] <armin76> asac: http://rafb.net/p/s48RV614.html and mozilla-firefox is ff3
[17:10] <asac> /usr/lib/mozilla-firefox/.autoreg
[17:10] <asac> so does that get installed by make instakk
[17:10] <asac> ?
[17:11] <armin76> sec
[17:13] <armin76> asac: yes
[17:14] <armin76> was checking if it got installed by some patch, but nope
[17:15] <fta> seems impossible to build shared and static at the same time with scons :(
[17:16]  * asac wonders why scons is considered better than automake ;)
[17:16] <fta> all in python
[17:16] <fta> which is good.... if you like python
[17:17] <asac> i dont see how that can qualify as better
[17:17] <asac> i think they think that its better because of windows
[17:17] <asac> well ... at least those that think that python build system is better ;)
[17:18] <fta> scons brings in even more magic than make, debhelper and cdbs combined
[17:18] <asac> i hate magic
[17:18] <asac> well ... if its pure declarative its good
[17:18] <asac> but thats not magic
[17:19] <fta> i meant it's even more obscure
[17:19] <asac> like maven for java
[17:19] <asac> compared to ant
[17:19] <asac> lol
[17:19] <asac> http://crupp.de/?p=15
[17:19] <asac> rewad the first paragraph
[17:19] <asac> the guy said he used autotools by ...
[17:20] <asac> "I used hand-written makefiles...."
[17:20] <asac> So I looked for alternatives, and decided to settle on SCons instead of GNU Autotools
[17:20] <asac> he
[17:20] <asac> "And now I decided to revert my decision. Why? Because SCons is far more complicated than it looks, while autoconf/automake is far more simple than it seems."
[17:20] <asac> good guy
[17:20] <fta> patching v8 build system promises to be a challenge
[17:27] <asac> @time
[17:27] <asac> @time berlin
[17:39] <armin76> asac: porting ff to arm? :D
[18:04] <fta> armin76, i monitor the arm builds, so far, xul just failed: http://launchpadlibrarian.net/19673125/buildlog_ubuntu-jaunty-armel.xulrunner-1.9_1.9.0.3%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:05] <fta> -so far
[18:06] <fta> i was about to say, so far, xul is waiting for gnome, but not anymore
[18:07] <armin76> fta: same as hppa did....
[18:08] <armin76> failing on cookie stuff wrt warning treated as err
[18:09] <fta> like for hppa, i don't have access to arm, so i don't plan to blindly try to fix it
[18:11] <armin76> may want to file a bug, then :)
[18:12] <armin76> fta: or filter -Werror :)
[18:13] <fta> no, not the good cure
[18:14] <armin76> in fact
[18:14] <armin76> mozilla bug 417345
[18:14] <armin76> ah, now that i remember
[18:15] <armin76> i did a "patch" for that
[18:15] <armin76> mozilla bug 436133
[18:16] <armin76> guess arm needs to be there as well :)
[18:21] <armin76> asac: see the gentoo bug plz
[18:22] <fta> probably but i have no idea how arm and armel differs in term of flags
[18:23]  * fta is going to lurk in #ubuntu-arm for a while
[18:58] <jdhore1> What's going on with Firefox 3.0.4 in any version of Ubuntu (specifically Hardy)?
[19:15] <armin76> omg
[19:15] <armin76> asac: OMG BUMB!
[20:02] <asac> jdhore1: all ready. security team missed to push it on Thu and since we dont release on Fri we have to wait till Mon
[20:02] <jdhore1> ah
[20:02] <asac> armin76: the strace -eopen -f would be helpful regardless of whether it works or not
[20:03] <asac> armin76: you have fixes for the alignment issues?
[20:03] <asac> we see them on arm now
[20:03] <asac> (armel)
[20:04] <armin76> asac: see mozilla bug 436133
[20:04] <armin76> asac: i punted --disable-libxul and now it works according to the guy
[20:05] <asac> armin76: hmm.
[20:05] <asac> armin76: still . i think he has garbage in his pkglibdir
[20:06] <asac> most likely he will run into issues sooner or later again
[20:15] <armin76> asac: http://rafb.net/p/PiQoTI26.html
[20:15] <armin76> -r0 is with --disable-libxul, -r1 is without
[20:15] <asac> yeah
[20:15] <asac> armin76: http://paste.ubuntu.com/72517/
[20:16] <armin76> asac: i don't know about armel, you guys should ask if its safe to run -Wcast-align on arm or not
[20:16] <armin76> s/arm/armel
[20:17] <asac> armin76: who would be able to tell that thats "safe" i ngeneral?
[20:17] <asac> i mean if it was safe then its a gcc bug that it warns at all ;)
[20:17] <armin76> whoever maintains arm on ubuntu or debian
[20:18] <asac> well. debian just did it i think
[20:18] <asac> not sure if they seriously considered whether its safe or not ;)
[20:18] <armin76> look the patch i did
[20:19] <asac> yeah
[20:19] <asac> easy enough to do
[20:19] <asac> INTEL_CC?
[20:20] <asac> who supports that? ;)
[20:20] <armin76> hppa,ia64 and sparc give errors if stuff is unaligned
[20:20] <asac> sure
[20:20] <armin76> i didn't know arm did as well
[20:20] <asac> armin76: armel does apparently
[20:20] <asac> armin76: http://launchpadlibrarian.net/19673125/buildlog_ubuntu-jaunty-armel.xulrunner-1.9_1.9.0.3%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:20] <armin76> yup
[20:20] <asac> thats where i have the paste from
[20:21] <asac> wonder if the code could be fixed to properly case
[20:21] <asac> cast
[20:22] <armin76> you are better than me at that
[20:23] <armin76> the difference between debian and ubuntu is that debian isn't using -Werror
[20:23] <armin76> while ubuntu does
[20:23] <asac> i remember that they had the same issues on armel when it popped up
[20:23] <asac> i think they then just deliberately passed -Wno-error
[20:23] <asac> not sure if its really a gcc default
[20:25] <asac> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsVoidArray.h#193
[20:25] <armin76> -CXXFLAGS += $(WARNINGS_AS_ERRORS) <- thats from debian
[20:25] <asac> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsVoidArray.cpp#142
[20:25] <asac> armin76: thats in xulrunner right?
[20:26] <armin76> yes
[20:27] <armin76> they're just doing that on xulrunner-1.9.0.3/netwerk/cookie/src/Makefile.in
[20:28] <asac> char mAutoBuf[sizeof(Impl) + (kAutoBufSize - 1) * sizeof(void*)];
[20:29] <armin76> asac: and btw, sparc is still sigbusing
[20:30] <asac> armin76: in cookie?
[20:31] <armin76> no...
[20:31]  * armin76 thinks asac has really bad memory
[20:31] <asac> i can confirm that ;)
[20:31] <armin76> mozilla bug 448658
[20:31] <asac> now i remember ;)
[20:32] <asac> armin76: but dont remember everythign. didnt we fix that?
[20:32] <asac> ;)
[20:33] <fta> our gcc has -Wformat -Wformat-security by default now
[20:33] <fta> https://wiki.ubuntu.com/CompilerFlags
[20:34] <armin76> asac: not too much, you made me try with some patch that just delayed the sigbus 45 mins
[20:35] <fta> on sparc ?
[20:35] <armin76> yeah, see that bug
[20:35] <asac> armin76: what was that patch?
[20:36] <asac> did i just paste that or post it somewhere?
[20:36] <armin76> one like debian's
[20:36] <armin76> let me see the logs
[20:42] <armin76> asac: you pasted me a patch, and then i saw the debian bug, and you told me that was the patch you pasted
[20:44] <armin76> asac: then you got stuck in the canada thing, but you mainly said that with 45 mins you could live with it, i filed that bug at upstream's bugzilla and you didn't say anything after that
[20:45] <asac> oh thats long time ;)
[20:47] <armin76> asac: then we talked about it at the end of september, but you didn't said anything new
[20:49] <armin76> i just asked you if you'd think 3.0.2 will sigbus, since it was released at that time
[20:49] <armin76> and it did, so...
[20:49] <armin76> asac: btw, bumb!
[20:49] <armin76> why you didn't bumb 3.0.4 yet!!!!
[20:50] <asac> armin76: in jaunty -> my lazyness in holiday mode
[20:50] <asac> everywhere else:
[20:50] <asac> 1:02 < asac> jdhore1: all ready. security team missed to push it on Thu and since we dont release on Fri we have  to wait till Mon
[20:50] <asac> armin76: ^^
[20:50] <asac> armin76: the lines dont match anymore :(
[20:51] <armin76> heh
[20:51] <armin76> go fix the sigbus on sparc :P
[20:52] <asac> looking ;)
[20:52] <asac> armin76: is it still the same?
[20:54] <armin76> asac: considering that the file(nsurlclassifierdbservice.cpp) hasn't been changed since 25th august, i'd say yes
[20:54] <armin76> well, it got changed today
[20:54] <asac> armin76: the lines dont match though
[20:55] <armin76> ah
[20:55] <armin76> the patch fails?
[20:55] <asac> no ... the lines in the backtrace dont match anything sensible in the code ;)
[20:56] <asac> at lesta the nsTArray line matches ;)
[20:56] <asac> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsTArray.h#590
[20:57] <armin76> okay, let me run it again
[20:57] <armin76> but i saw at the logs that you told me it didn't make any sense
[20:57] <asac> yeah ;)
[20:57] <asac> at least i found the line where the static cast happens
[20:57] <asac> (i think)
[20:58] <asac> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsTArray.h#182
[20:59] <asac> hmm. so what does new Type ... do?
[20:59] <asac> (e.g. wihtout ())
[21:00] <asac> new (static_cast<void *>(e)) E;
[21:00] <asac> what does that do :)?
[21:00] <armin76> you ask me? :P
[21:00] <asac> without assigning it anywhere :/
[21:00] <asac> fta: ^^ ;)
[21:01] <asac> http://mxr.mozilla.org/mozilla/source/xpcom/glue/nsTArray.h#178
[21:04] <asac> fta: any clue if the cast implicitly binds the constructed thing to "e" =
[21:04] <asac> =
[21:04] <asac> ?
[21:05] <fta> nope, i fried my brain earlier today inside a SConstruct file
[21:10] <asac> something more simple ;) .... cout ... iostream doesnt have that?
[21:11] <asac> ah ... namespace ;)
[21:16]  * armin76 is upgrading to jaunty
[21:32] <asac> armin76: dont know. if you have a up-to-date backtrace of sigbus please show
[21:32] <armin76> yeah
[21:32] <armin76> gdb doesn't seem to run fine on jaunty, trying intrepid now
[21:50] <asac> armin76: heh. now our toolchain guy kicks me for fixing armel + xulrunner
[21:51] <asac> funny thing is that our toolchain needs xulrunner to bootstrap ;)
[21:51] <armin76> you fixed something? :D
[21:51] <asac> armin76: no he wants me to fix that
[21:51] <armin76> thats interesting
[21:51] <armin76> ah
[21:51] <fta> xulrunner used in the bootstrap ???
[21:51] <asac> i think they made an ugly hack and copied xulrunner binaries from debian for the bootstrapping ;)
[21:51] <armin76> s/for/to
[21:51] <asac> fta: yeah :)
[21:51] <fta> what for?
[21:52] <asac> fta: its not required to be functional, but its required to build the huge gcc package
[21:52] <armin76> i can't remember how i made the backtraces...
[21:52] <asac> e.g. gcj provides a plugin ;)
[21:52] <fta> lol
[21:52] <asac> armin76: you need dbgsym ;)
[21:52] <armin76> yeah...but its not available for sparc
[21:52] <asac> fta: this reminds me. we have a new approach -> we go for -dbg packages again for jaunty
[21:53] <fta> asac, already done in 3.1
[21:53] <asac> fta: good
[21:53] <armin76> i think i used gentoo for them...hrm...
[21:53] <asac> fta: so we have xulrunner-1.9-dbg there?
[21:53] <asac> err
[21:53] <fta> i was sick about missing dbgsym in ppa :(
[21:53] <asac> 1.9.1
[21:53] <asac> ;)
[21:53] <asac> fta: i am almost dead because of that ;)
[21:53] <fta> yes, xul + ff
[21:54] <armin76> so it wasn't jaunty, it was ff sigbusing at the start :D
[21:54] <asac> armin76: heh
[21:54] <asac> armin76: somewhere else?
[21:55] <asac> fta: well done
[21:55] <asac> fta: are they ok?
[21:55] <fta> yes
[21:55] <armin76> asac: no clue, no dbg symbols
[21:55] <asac> (i assume you already used them with success)
[21:55] <asac> armin76: for intrepid there should be dbgsym packages
[21:55] <asac> its still in the main component
[21:56] <asac> err i mean in intrepid branch (not -updates/-security)
[21:56] <armin76> for sparc?
[21:56] <asac> yeah
[21:56] <asac> unless it didnt build at all
[21:57] <asac> Alpha 1 freeze ahead
[21:57] <asac> ;)
[21:57] <asac> funny
[21:58] <asac> fta: how many uploads did you do for jaunty?
[21:58] <fta> none
[21:58] <asac> same same
[21:58] <asac> http://merges.ubuntu.com/universe.html
[21:59] <asac> appears to be easy food in universe
[21:59] <fta> persia wants fennec in REVU, but i need xul 1.9.1 in universe 1st
[21:59] <asac> everything green
[21:59] <asac> in REVU?
[21:59] <fta> yep
[21:59] <asac> what kind of idea is that?
[22:00] <fta> no idea, it seems he wants motu to have a look 1st
[22:00] <asac> create an empty ubuntu-dev branch ... request merge there for review ;)
[22:00] <fta> ah?
[22:00] <fta> eh?
[22:00] <armin76> hardy sparc   Failed to build
[22:00] <armin76> fail
[22:00] <asac> fta: if he wants the ability for motus to take a look and discuss the packaging, we can do that in launchpad code review
[22:01] <asac> no need to use REVU for bzr packages
[22:01] <fta> tell him
[22:01] <asac> fta: i can do that. though i would rather not put that through motu
[22:01] <asac> fta: isnt mozillateam maintainer?
[22:01] <fta> it is
[22:02] <asac> fta: where is the policy for NEW packages in universe?
[22:02] <asac> so trolls are on wiki.ubuntu.com
[22:03] <asac> all russian on start page
[22:03] <asac> https://wiki.ubuntu.com/
[22:04] <asac> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Packaging%20it%20yourself
[22:04] <fta> it means "This page is created for people living in Uzbekistan."
[22:04] <asac> fta: ^^
[22:04] <asac> ok sounds at least a bit honourable ;)
[22:05] <armin76> asac: https://launchpad.net/ubuntu/intrepid/+source/firefox-3.0 <- i don't see the dbgsym packages
[22:05] <asac> fta: ok i dont like the idea to just ignore that policy (though i did in the past for sure - unknowingly)
[22:05] <asac> fta: i will talk to MOTU leaders about adapting that policy to allow review of bzr branches through merges to empty branches
[22:06] <asac> maybe we should test if that works
[22:06] <asac> armin76: they are not there. l00ser
[22:06] <armin76> die!
[22:06] <asac> armin76: sec
[22:06] <asac> armin76: https://wiki.ubuntu.com/MozillaTeam/Bugs#Crashes
[22:07] <asac> adjust the apt lines !!!!
[22:07] <asac> ;)
[22:07] <asac> i guess that dbgsym archive should be added to software repositories
[22:08] <asac> in update manager UI
[22:08] <armin76> asac: there's no sparc binaries!
[22:08]  * armin76 shoots asac 
[22:08] <asac> hoho
[22:08] <armin76> http://ddebs.ubuntu.com/pool/universe/f/firefox-3.0/
[22:08] <asac> now i really feel ashame ;)
[22:08]  * asac shoots around too
[22:08] <fta> i can't push it to revu if xul 1.9.1 is not in 1st
[22:08] <asac> fta: heh ;)
[22:08] <asac> fta: right
[22:09] <fta> it's not that i don't want to, it's a dep
[22:09] <asac> fta: so basically this means that xul 1.9.1 has to go through REVU too ;)
[22:09] <asac> see how that makes sense
[22:09] <fta> oh god
[22:09] <asac> fta: will revu complain if you upload with unfullfilled debs?
[22:09] <asac> deps
[22:10] <asac> or will reviewers just be pissed if they cannot "test" on their own?
[22:10] <fta> revu itself no, but reviewers most probably
[22:10] <asac> fta: well. reviewers should review not test ;)
[22:10] <asac> if they want to test they can do ppa
[22:10] <fta> btw, i only used revu twice, it was an horrible experience
[22:11] <asac> fta: yeah ;)
[22:11] <fta> i had to beg for weeks for reviews
[22:11] <asac> fta: well. fennec will be quick i am sure
[22:11] <armin76> lol
[22:11] <asac> but that isnt the point
[22:11] <asac> those are no MOTU packages ;)
[22:11] <armin76> who can it beeeeee now!
[22:11] <asac> those are MT packages and its understood that there isnt much know-how in MOTU
[22:14] <asac> fta: how lintian clean are our packages :) :-P
[22:14] <asac> ?
[22:14] <fta> i guess for xul, it's ugly.. the usr/share vs usr/lib 1st
[22:14] <fta> fennec should be quite clean
[22:15] <fta> let me try it
[22:15] <asac> fta: but fennec ships everything in usr.lib too
[22:15] <asac> fta: we should add overrides
[22:15] <asac> if we go through REVU i dont want people to start complaining about this kind of stuff
[22:15] <asac> that would give me too much heart-pain for sure
[22:17] <fta> just 2:
[22:17] <fta> W: fennec source: out-of-date-standards-version 3.7.3 (current is 3.8.0)
[22:17] <fta> W: fennec: binary-without-manpage usr/bin/fennec
[22:17] <fta> i don't see the point of a man page for fennec
[22:18] <asac> thats ok
[22:18] <asac> those dont need to be dealt with
[22:18] <asac_the_bumber> you guys packaging fennec?
[22:18] <asac> its all there
[22:19] <fta> for months, i packaged it in june
[22:19] <asac_the_bumber> why? is it fun? :D
[22:21] <fta> asac, oh, i want to close mozilla-devscripts 0.11 before i start new devs, could you push it in jaunty for me?
[22:21] <asac> its fun + its a proof of concept thing for more complex xulapps
[22:21] <asac> fta: what are the changes?
[22:22] <fta> asac, quite a lot: http://paste.ubuntu.com/72566/
[22:22] <asac> fta: btw, i was a bit scared during this security update because i didnt keep my eyes on whether we took extra care that orig tarballs are 100% backward compatible (e.g. because of the artwork)
[22:22] <asac> fta: so we should definitly take extra care, that whatever we do with the tarballs, they should be compatible ;)
[22:22] <asac_the_bumber> permet à tous Bumb
[22:22] <asac> so we can use the same for hardy+intrepid+jaunty
[22:23] <fta> asac, i think it is
[22:24] <asac> fta: i think it is too. just as a reminder that we should keep that in mind ;)
[22:24] <asac_the_bumber> Fennec utilisations xul 1.9.1, n'est-ce pas?
[22:24] <asac> yeah
[22:24] <asac> oui
[22:24] <asac> the only word i know ;)
[22:24] <asac_the_bumber> yay, ASAC sait français: D
[22:25] <asac> asac_the_bumber: so do you have a better backtrace?
[22:25] <fta> lol, -sait+connait
[22:25] <asac> dico
[22:25] <fta> -sait+connait le
[22:25] <asac> dicet
[22:26] <asac> from me the "latin" n00b ;)
[22:26] <asac_the_bumber> ASAC: il ne s'est pas écrasé encore, de manière surprenante, c'est avec 3.0.2
[22:26] <fta> is that from google translate ?
[22:26] <asac> please stop non-english languages
[22:26] <asac_the_bumber> lol
[22:26] <asac> i have a bug open where the reporter uses google translate from russian
[22:27] <asac> and insisted that its good to do that and that it would be harsh not to proceed
[22:27] <asac_the_bumber> fta: this thing has a translator embedded
[22:27] <asac_the_bumber> asac: i said that it didn't crash yet
[22:28] <asac_the_bumber> and that i'm using 3.0.2 until the system is upgraded
[22:28] <fta> asac, so, m-d, can i close it ?
[22:28]  * armin76 tries to build fennec
[22:28] <asac> fta: you can always close ;)
[22:29] <asac> i have no feature requests for now
[22:29] <asac> except that i would like to move our branches to use in-package variables to define the orig behaviour
[22:29] <asac> but thats most likely for 0.12
[22:29] <asac> and we stilll need to support the apps for the old branches of course
[22:30] <asac> armin76: take our orig
[22:31] <asac> armin76: are you using 3.0.2 without the original patch?
[22:31] <asac> (i assume you have it ;))
[22:31] <armin76> what original patch?
[22:31] <asac> armin76: well. the obvious one ;)
[22:31] <armin76> debian's?
[22:31] <asac> the one debian has ;)
[22:31] <asac> right
[22:32] <armin76> yeah, i think its without 3.0.2
[22:32] <armin76> err
[22:32] <armin76> its without the patch
[22:32] <asac> ok
[22:32] <armin76> we'll see if it crashes on 45 mins
[22:32] <asac> wired ;)
[22:32] <fta> oh damn, hell, damnation
[22:32] <asac> weird
[22:32] <fta> ix:~/bzr/mozilla-devscripts$ bzr push
[22:32] <fta> Using saved location: bzr+ssh://fta@bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/
[22:32] <fta> bzr: ERROR: KnitPackRepository('bzr+ssh://fta@bazaar.launchpad.net/%7Emozillateam/mozilla-devscripts/mozilla-devscripts/.bzr/repository/')
[22:32] <fta> is not compatible with
[22:32] <fta> KnitPackRepository('file:///src/bzr/.bzr/repository/')
[22:32] <fta> different rich-root support
[22:32] <asac> fta: what branch type do you use?
[22:32] <asac> err repo type
[22:33] <asac> did you upgrade the repo with 0.92 branches inside?
[22:33] <fta> i had to upgrade my repo to import chromium from svn
[22:33] <asac> thats a bad thing ;)
[22:33] <armin76> 17 + 45
[22:33] <asac> fta: i made that mistake at some point
[22:33] <asac> now i have ubuntu_bzr and ubuntu_bzr2 ;)
[22:33] <asac> everything was trashed afterwards
[22:33] <armin76> it should crash at 00:05
[22:34] <asac> i think i could recover by reinstantiating the backup .bzr of repo and branches
[22:34] <armin76> 00:07, sorry *g*
[22:34] <fta> how come my pushes to the fennec branch worked an hour ago ??
[22:34] <asac> armin76: why 45?
[22:34] <asac> thought after the patch it took 45 min
[22:34] <asac> fta: mere luck?
[22:34] <armin76> asac: yeah...but now it doesn't crash and i think its without the patch :/
[22:35] <asac> fta: what is different for fennec and mozilla-devscripts (local/remote)?
[22:35] <asac> KnitPackRepository doesnt sound like pack-0.92
[22:35] <asac> but i might be wrong
[22:35] <asac> sounds more like the even older knit-pack format
[22:36] <fta> why did i ever create a global repo
[22:36] <fta> huge mistake
[22:36] <asac> yeah could be
[22:36] <asac> though it is supposed to boost initial checkout of related branches
[22:37] <asac_the_bumber> jump in my car
[22:37] <asac> fta: just push everything .... then trash everything and start over
[22:37] <asac_the_bumber> i wanna take you home
[22:37] <fta> I can't push
[22:38] <asac> armin76: enable safe-browsing ;)
[22:38] <asac_the_bumber> it is...
[22:38] <asac> do you see the classifier db growing?
[22:38] <asac> maybe you use an already complete profile?
[22:38] <asac_the_bumber> where's that?
[22:38] <asac> which doesnt import stuff
[22:39] <asac_the_bumber> nope, i started over
[22:39] <asac> in profile .... class.*sqli
[22:39] <rzr> hi guys
[22:39] <asac> hi rzr
[22:40] <asac_the_bumber> its 7mb now
[22:40] <asac> growing?
[22:40] <asac_the_bumber> last mod 22:23
[22:40] <rzr> saw my new revision on flashblock ?
[22:40] <asac> thats long ago
[22:40] <asac_the_bumber> its utc, just 20 mins ago
[22:41] <asac> rzr: yep
[22:41] <asac> rzr: did you ask for review of the changes?
[22:41] <rzr> ok great is it ok ?
[22:41] <asac> not looked yet
[22:41] <asac> rzr: if you have requested a merge of branches i will look now ;)
[22:41] <rzr> i did
[22:41] <asac> ok
[22:41]  * asac opens merges
[22:41] <rzr> https://code.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.ubuntu/+merge/1683
 ix:~/bzr/fennec.head$ bzr info
 Repository tree (format: rich-root-pack)
 ix:~/bzr/fennec.head$ bzr info bzr+ssh://fta@bazaar.launchpad.net/%7Emozillateam/fennec/fennec.head/
[22:42] <armin76> gonna try without gdb
 Repository branch (format: unnamed)
 it doesn't work either
[22:42] <rzr> asac: is this the right way to request merges ?
[22:42] <asac> rzr: its already merged
[22:43] <asac> rzr: i think you did it the wrong way
[22:43] <asac> rzr: you have to request a merge on your branch to the ubuntu-dev
[22:43] <rzr> right
[22:43] <asac> not the other way around (which you did from what i can tell)
[22:43] <rzr> i wasnt sure
[22:43] <rzr> i suspected i was wrong
[22:43] <asac> rzr: well.  navigate to your branch and click on propose ofr merge
[22:43] <rzr> when I set my branch as target
[22:44] <asac> go to your branch and use ubuntu-dev as target
[22:44] <asac_the_bumber> asac: it grow from 32k at the beginning to 1.2mb atm
[22:44] <rzr> ok this makes sense
[22:44] <asac_the_bumber> 2.7mb
[22:44] <asac> asac_the_bumber: not sure what you mean. you said 8mb?
[22:45] <asac_the_bumber> yeah, i started over without gdb
[22:45] <asac> asac_the_bumber: good. must be mere luck or your sparc doesnt care about alignment that much ;)
[22:45] <asac> or the patch is applied
[22:46]  * asac feels good about using his original ffox profile again ;9
[22:46] <rzr> There is already a branch merge proposal registered for branch ~rzr/firefox-extensions/flashblock.ubuntu to land on ~ubuntu-dev/firefox-extensions/flashblock.ubuntu that is still active.
[22:46] <asac> rzr: where?
[22:46] <rzr> i suppose this is the hardy backport
[22:46] <rzr> let me cancel it
[22:46] <asac> let me check
[22:46] <asac_the_bumber> asac: doubt it...i think i tested 3.0.2 and it sigbused...the only thing that has changed is that i now use a kernel 2.6.26
[22:46] <asac> rzr: dont need to i think
[22:47] <asac> or does it complain?
[22:47] <asac_the_bumber> anyway, 3.0.4 is the one important now
[22:47] <rzr> it can't : error
[22:47] <asac> rzr: ok then cancel and rerequest
[22:47] <asac> we have to create stable branches anyway i think
[22:47] <asac> rzr: which revision was released to hardy?
[22:47] <fta_> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
[22:48] <asac> rzr: 7?
[22:48] <rzr> 12
[22:48] <asac> fta_: i cannot help you ;) ... i did what i said above (backup.bzr)
[22:48] <asac> rzr: to hardy?
[22:49] <rzr> welll forget about this one
[22:49] <rzr> https://code.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/+merge/431
[22:49] <asac> rzr: which package version is current in .hardy?
[22:49] <rzr> I have to check
[22:49] <asac> rzr: why do you include the backport to hardy in that branch?
[22:50] <asac> that should be in a separate branch
[22:50] <rzr> https://launchpad.net/ubuntu/hardy/+source/flashblock/1.3.9a-0ubuntu1
[22:50] <rzr> yes
[22:50] <asac> based on the actual hardy released revision
[22:50] <asac> oh
[22:50] <asac> let me think for a moment
[22:50] <rzr> I reverted this since I didnt pushed to a .hardy branch
[22:51] <rzr> LP is confusing sometime
[22:51] <asac> ok its as i said. we have to create those .hardy branches and then merge from .ubuntu for backports
[22:51] <rzr> well can we put this hardy branch on hold
[22:51] <rzr> and backport latest one ?
[22:51] <asac> rzr:  we can. but we need to remove those revisions ;)
[22:52] <rzr> which one ?
[22:52] <rzr> there are none
[22:52] <asac> 11 and 12
[22:52] <asac> https://code.edge.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/+merge/431
[22:52] <asac> let me check
[22:52] <rzr> ok i understand
[22:53] <rzr> then I must push r12 to LP right ?
[22:53] <rzr> in a .hardy branch
[22:53] <rzr> then we'll sync latest one ? maybe you're busy now are you ?
[22:55] <asac> phone
[22:57] <asac> rzr: well. i dont mind. to do it properly we should dump revision 11 and 12
[22:58] <asac> push revision 7 to .hardy .... push revision 10 to .intrepid .... then merge .intrepid to .hardy and name that hardy-backports
[22:58] <asac> rzr: but i can do that infrastructure stuff for you
[22:58] <asac> i have to do that anyway i think
[22:59] <rzr> ok please do, but I think I can do this
[22:59] <asac> rzr: well. i have to push to the ~ubuntu-dev branches first. if you could give me the revisions that match the released versions for hardy/intrepid that would be helpful
[22:59] <rzr> ok
[23:01] <fta> ok, everything recovered
[23:01] <asac> :-P
[23:02] <fta> asac, m-d closed, rev 190
[23:02] <rzr> https://launchpad.net/ubuntu/+source/flashblock
[23:02] <rzr> hardy 7 : http://bazaar.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/revision/7
[23:02] <fta> now, i'm getting rid of that bzr repo
[23:03] <rzr> intrepid : looking for  	1.3.10a~snapshot20080611-0ubuntu2
[23:03] <asac> rzr: ok i think i have them
[23:03] <rzr> I missed to merge ?
[23:03] <asac> its 7 for hardy and 11 for intrepid
[23:03] <asac> ok
[23:03] <asac> so
[23:03] <rzr> i dont see it
[23:04] <asac> https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.hardy-backports
[23:04] <rzr> not 11 :
[23:04] <rzr> http://bazaar.launchpad.net/~rzr/firefox-extensions/flashblock.ubuntu/revision/11
[23:04] <asac> https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.intrepid-backports
[23:04] <rzr> ok then I didnt merge this branch
[23:04] <asac> rzr: not sure. i looked at the ~ubuntu-dev brtanch
[23:05] <rzr> grr
[23:05] <asac> rzr: so ... do the new upstream on top of current .head
[23:05] <rzr> I didnt know it existed :)
[23:05] <asac> rzr: well. i created them right now
[23:05] <rzr> where is head ?
[23:05] <asac> rzr: but the ~ubuntu-dev always must be the base for your work
[23:05] <asac> rzr: head is always ~ubuntu-dev .... .ubuntu
[23:05] <rzr> i then it's ok
[23:06] <asac> rzr: no it cant be ok if your revision 11 is different from the ~ubuntu-dev branches ;)
[23:06] <asac> rzr: 1. merge new upstream to https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.ubuntu
[23:06] <rzr> I shouldnt commited backport in 'my main' ~rzr/*.ubuntu branch then ?
[23:06] <asac> rzr: 2. merge flashblock.ubuntu to flashblock.intrepid-backports
[23:06] <asac> rzr: 3. merge flashblock.ubuntu to flashblock.hardy-backports
[23:07] <asac> rzr: rzr well. the name of your branch doesnt matter
[23:07] <asac> rzr: you need to create one branch for each of the 3 steps above
[23:07] <asac> rzr: after they are merged you should delete them from launchpad and locally
[23:07] <rzr> ok
[23:07] <asac> so you start from ~ubuntu-dev next time again
[23:08] <rzr> Is there a document on the workflow , I'll double check it
[23:08] <asac> rzr: the workflow is like above ;)
[23:08] <asac> 3 steps
[23:08] <rzr> ok
[23:08] <asac> plain and simple
[23:08] <asac> maybe step 0. update .upstream branch
[23:08] <asac> rzr: do you have a proper upstream branch?
[23:08] <rzr> yes
[23:08] <asac> ok
[23:09] <asac> rzr: should be quite quick then i guess
[23:09] <rzr> but i am on debian, now I'd like to test it to make sure
[23:10] <rzr> and when you said :
 rzr: 1. merge new upstream to https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/flashblock.ubuntu
[23:10] <rzr> I can push to ~ubuntu-dev
[23:11] <asac> rzr: no merge to always means:
[23:11] <asac> 1. branch the target branch
[23:11] <rzr> and request merge ?
[23:11] <asac> 2. merge the branch locally
[23:11] <asac> 3. push to ~rzr
[23:11] <asac> 4. request merge
[23:11] <asac> yeah ;)
[23:11] <rzr> ok
[23:11] <rzr> i wasnt sure
[23:11] <asac> the name of the ~rzr branch doesnt matter ... it can match the target ~ubuntu-dev ... but doesnt need to
[23:11] <asac> its your choice
[23:12] <rzr> ok
[23:12] <rzr> let's destroy my current branches then
[23:12] <asac> heh ;)
[23:15] <rzr> humm upstream is active
[23:15] <rzr> I checked
[23:16] <asac> does that hinder you from updating the branch?
[23:16] <rzr> I think I'll wait a few days , then
[23:16] <fta> done, except the root cause, the chromium upstream branch :(
[23:16] <rzr> well I can merge last week branch since it seems to work
[23:16] <asac> rzr: not sure if we should really wait for upstream being inactive ;)
[23:16] <asac> rzr: yes. thats a better idea
[23:17] <asac> just merge what you know works
[23:17] <asac> and then go on from there
[23:17] <rzr> i havent tested deeply since I am mostly on sid
[23:17] <rzr> you should hate me :)
[23:17] <asac> i dont mind
[23:17] <asac> extensions should be more or less distro agnostic
[23:18] <rzr> if only we were on a same browser :)
[23:18] <rzr> well let's finish this job ... I have some other stuff to be done soon
[23:18] <asac> good
[23:19] <asac> fta: how messy are nspr/nss branches?
[23:20] <asac> fta: did i ever revert the soname stuff somewhere?
[23:20] <fta> i updated nspr and nss 2 days ago to match 1.9.0.4 reqs, all fine for me
[23:20] <fta> yes
[23:20] <fta> weeks ago
[23:21] <asac> fta: is that nss.dev?
[23:23] <fta> no, nspr.head and nss.head
[23:23] <fta> remember we cleaned that up a while ago ?
[23:23] <asac> yeah
[23:24] <asac> was just confused that an nspr.head overwrite removed a bunch of revisions for me
[23:25] <asac> fta: why is .head still at RC ?
[23:25] <asac> nss
[23:25] <fta> because that's what upstream has
[23:25] <asac> really? thought they were at RTM now
[23:26] <asac> fta: so .dev isnt used anymore?
[23:27] <fta> not by me
[23:27] <fta> http://mxr.mozilla.org/mozilla/source/client.mk
[23:27] <fta> NSPR_CO_TAG          = NSPR_4_7_3_RTM
[23:27] <fta> NSS_CO_TAG           = NSS_3_12_2_RC1
[23:27] <asac> ok
[23:28] <fta> both are in my ppa
[23:29] <asac> fta: ok i am doing bzr push -r 12.1.26 lp:~mozillateam/nss/nss.intrepid now
[23:31] <asac> and bzr push -r 36 lp:~mozillateam/nspr/nspr.intrepid
[23:31] <fta> intrepid ?
[23:32] <fta> it's meant for jaunty
[23:34] <asac> fta: sure. i created the stable branch post-mortem ;)
[23:34] <asac> see the revisions
[23:34] <asac> will --overwrite the .dev branches for now
[23:34] <fta> but i didn't close nss/nspr.head yet
[23:36] <asac> fta: doesnt matter ;)
[23:36] <asac> i just want to fix the .dev branches which are diverged somewhat
[23:37] <asac> and we will do a release soonish
[23:38] <fta> TypeError: cannot concatenate 'str' and 'instance' objects:
[23:38] <fta> i hate python
[23:39] <fta> this is list damit, not an instance' objects
[23:39] <fta> -list+string
[23:40] <asac> hehe
[23:40] <asac> you have to use concat(...)
[23:40] <asac> dont you?
[23:40] <asac> or .str()
[23:40] <asac> tostr
[23:40] <asac> hmm
[23:40] <asac> cant remember ;)
[23:45] <rzr> dammit I forgot I cant reboot while I am rsyncing large files
[23:46] <fta> hmm, it's a file instance, not a string
[23:46] <rzr> let's chroot and test ... erm erm
[23:47] <asac> fta: i think python is like java and has a generic string method associated with every object
[23:47] <asac> you just have to invoke that explicitly
[23:47] <fta> AttributeError: File instance has no attribute 'tostring':
[23:48] <asac> with some luck file instance returns the proper things
[23:48] <asac> fta: yes. like i said. its str() ... or even str(object)
[23:48] <asac> that does that
[23:48] <asac> or something like that
[23:49] <asac> fta: yeah i think its str(object)
[23:50] <asac> that runs the __str__: function
[23:50] <asac> but i think its not the right way to get he file path reliably
[23:51] <asac> fta: why are we on rc1 again ... i updated to rc2 in revision 78
[23:51] <fta> read the entire version
[23:52] <asac> heh
[23:52] <asac> ok
[23:52] <asac> fta: hmm. so we dont have the final .1 release
[23:53] <fta> we missed it
[23:54] <asac> obviously ;)
[23:56] <armin76> asac: it crashed
[23:56] <armin76> the sqlite file is 9.8m
[23:56] <armin76> i'll try tommorrow
[23:56] <fta> ix:~/bzr/build-area/chromium-v8-0.4.3.1~svn20081105r696$ scons library=shared PREFIX=/usr DESTDIR=debian/tmp install
[23:56] <fta> scons: Reading SConscript files ...
[23:56] <fta> ['debian/tmp/usr/lib/libv8.so']
[23:56] <fta> \o/
[23:57] <asac> fta: please use -version-info in some way ;)
[23:57] <fta> Rome was not built in one day!