[00:10] <fta> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081126 Ubuntu/9.04 (jaunty) Shiretoko/3.1b2
[00:12] <fta> asac, your distribution.ini says firefox even if the branding is not firefox :(
[00:13] <asac> oh completely forgot about that ;)
[00:14] <asac> distribution.ini.firefox distribution.ini.abrowser ... dont think we need a template
[00:15] <fta> it should match the desktop, ie, firefox/abrowser/minefield/shiretoko
[00:15] <fta> so a template is better
[00:16] <asac> gnome-terminal consumes 600M mem
[00:16] <asac> have to close it i guess
[00:17] <fta> that's why i'm using xterms
[00:17] <fta> strangely, ff is using 12% cpu while idle
[00:17] <asac> i think X has a huge mem leak here ;)
[00:18] <asac> i closed everything ... and still 1.5G in use
[00:20] <asac> omg geyes_applet2 uses 100 ;)
[00:20] <asac> tomboy 65
[00:20] <fta> RES ? or VIRT ?
[00:21] <asac> RES
[00:21] <asac> bzr-notify 25 RES
[00:21] <asac> that has to go
[00:21] <asac> i never installed
[00:21] <asac> it
[00:21] <asac> now i have to find it and purge it
[00:22] <asac> ok bzr-gtk uninstalled ;)
[00:22] <fta>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[00:22] <fta> 27772 fta       20   0  556m 385m  30m S   18 19.0   3:25.03 firefox-3.1
[00:22] <fta> 10384 root      20   0  218m 172m  15m S    1  8.5  49:32.14 Xorg
[00:22] <fta>  8511 fta       20   0  208m  61m  23m S    0  3.0  10:11.08 rhythmbox
[00:22] <fta> 10576 fta       20   0  162m  58m  21m S    0  2.9   3:12.31 liferea-bin
[00:22] <fta> 10850 fta       20   0 91476  47m  14m S    0  2.3   0:30.10 evince
[00:22] <fta> 10568 fta       20   0  140m  36m  18m S    0  1.8   0:47.21 nautilus
[00:23] <asac> oh ... i have two Xorg ;)
[00:23] <asac>  5517 root      20   0  553m 152m  13m S    4  7.6 131:33.30 Xorg
[00:23] <asac>  5877 root      20   0  553m 152m  13m S    0  7.6   0:00.00 Xorg
[00:29] <asac> too bad. this ended in a reboot ;)
[00:30] <fta> eheh
[00:31] <asac> 13997 root      20   0 54716 2560 1952 S    0  0.1   0:00.04 NetworkManager
[00:31] <asac> sry
[00:31] <asac> 2560
[00:31] <asac> thats cool
[00:31] <asac> i blame python apps for most bloat ;)
[00:31] <asac> why does jockey-backend need 20m res?
[00:31] <asac> NM doesnt even use 2.5m
[00:32] <asac> fta: http://paste.ubuntu.com/77255/
[00:32] <asac> thats the ordered "root" process list
[00:33] <asac> http://paste.ubuntu.com/77256/
[00:33] <asac> thats the user process list
[00:33] <asac> (more or less virgin sys)
[00:39] <fta> trackerd, bbaaaaaahh
[00:41] <fta> prism is still broken, no idea why
[00:42] <fta> jaunty only, intrepid is fine
[00:46] <asac> fta: intrepid == same version as in jaunty, just built on intrepid is fine?
[00:47] <asac> fta: maybe a maxVersion thing?
[01:14] <fta> same problem after a rebuild, even with fresher sources
[01:15] <fta> Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://webrunner/content/webrunner.js :: <TOP_LEVEL> :: line 31"  data: no]
[01:15] <fta> Error: WebRunner is undefined
[01:15] <fta> Source File: chrome://webrunner/content/webrunner.xul
[01:15] <fta> Line: 167
[01:22] <asac> fta: xul 1.9.1?
[06:37] <wiki> Is it possible to upload a hidden release to my ppa without it affecting/superseding my other releases.I want to test if my pkg is building properly on all platforms.
[10:34] <james_w> asac: how do I turn an xpi in to an orig.tar.gz?
[10:52] <asac> james_w: med-xpi-unpack
[10:53] <asac> james_w: makes a standard structure out of it
[10:53] <asac> james_w: thats in mozilla-devscripts
[10:53] <directhex> clever!
[10:53] <james_w> is it normal to have a get-orig-source rule?
[10:54] <asac> james_w: not in our extension branches atm
[10:54] <james_w> I would have thought that would be a good idea, rather than having a watch file that downloaded something that couldn't be used straight away
[10:54] <asac> james_w: volans has developed a set of script that might be helpfule here
[10:54] <directhex> get-orig-source is a joyous thing. except when repacking to tgz, which causes pain
[10:55] <asac> james_w: well. get-orig-source doesnt help us as we have upstream in the branches
[10:55] <james_w> it's separate from that in my opinion
[10:55] <james_w> it's about getting the .orig.tar.gz to build against
[10:55] <asac> james_w: why would you want that?
[10:56] <asac> james_w: it feels like redundancy
[10:56] <asac> we already have the orig in the bzr branch
[10:56] <james_w> because we need an .orig.tar.gz
[10:56] <asac> only problem is "how" to spot the right revision
[10:56] <asac> james_w: imo bzr bd --export-upstream --export-upstream-rev=... is the right thing to do
[10:57] <asac> james_w: https://code.edge.launchpad.net/~volans/firefox-extensions/med-auto-scripts
[10:57] <asac> thats what volans did so far
[10:58] <james_w> if export-upstream is the best way to do it why don't you set up the branches like that?
[10:58] <asac> james_w: what do you mean?
[10:59] <james_w> why isn't the config of the branch set up to do that automatically?
[10:59] <asac> james_w: how?
[10:59] <james_w> though it doesn't work too well at the moment for uploading a -2
[10:59] <asac> james_w: a while back we talked about it
[10:59] <james_w> with a .bzr-builddeb/default.conf
[10:59] <asac> (e.g. how to find the right revision for upstream)
[11:00] <asac> i thought there was no "generic" solution
[11:00] <james_w> you can set the revision in there
[11:00] <asac> james_w: cool
[11:00] <james_w> then when you want to work on a new upstream change that, add a changelog entry, fix up anything else and commit it
[11:00] <asac> james_w: and i suppose that that file gets also committed?
[11:00] <james_w> it will then start building from the revision
[11:00] <james_w> then I could just grab the branch and run "bzr bd"
[11:01] <asac> james_w: ok. lets take a step back:
[11:01] <james_w> however, as I said it is currently broken for uploading a -2
[11:01] <james_w> or -0ubuntu2
[11:01] <asac> lets assume i have a .ubuntu branch (e.g. full source packaging) ... now i merge a new .upstream into it:
[11:01] <asac> cd test.ubuntu; bzr merge ../test.upstream; bzr commit -m "* new upstream release X.y.Z"
[11:01] <james_w> yep, I forgot that bit
[11:02] <asac> how can i know up front what revision the merge will have
[11:02] <asac> ?
[11:02] <asac> e.g.
[11:02] <james_w> do a "vi .bzr-builddeb/default.conf" before commit
[11:02] <asac> and what shall i add there? i dont know the revision the commit will be before?
[11:02] <james_w> no
[11:03] <asac> (its not the top level revision which i could guess afaik, its the nested version)
[11:03] <james_w> you don't tell it the revision in *this* branch, you tell it the revision in the upstream branch that you are working off
[11:03] <james_w> in your example it's the last revision of ../test.upstream
[11:03] <asac> james_w: ok. but that requires to keep upstream ?
[11:03] <james_w> no, just to know the revision id of it
[11:04] <james_w> once you have that and you have merged it you can delete the upstream branch
[11:04] <asac> james_w: ok so i guess bzr bd sees the branch nick and then finds the right merge revision?
[11:04] <james_w> eh?
[11:04] <asac> james_w: if i delete .upstream after that
[11:05] <asac> how will bzr bd be able to produce a orig?
[11:05] <asac> i assumed it would use --export-upstream=. --export-upstream=magic-revision
[11:05] <asac> err
[11:05] <asac> i assumed it would use --export-upstream=. --export-upstream-revision=magic-revision
[11:05] <james_w> yep
[11:06] <asac> james_w: so. from what i understand its not magic-revision i add to default.conf ... but just "upstream-revision"
[11:06] <asac> how does bzr bd find the magic-revision in the .ubuntu branch ;)?
[11:06] <james_w> the revision id of the tip revision of the upstream branch when you merge it
[11:06] <asac> james_w: revision id != revno?
[11:06] <james_w> exactly
[11:07] <asac> james_w: ok that makes sense. how can i see revision id?
[11:07] <james_w> revision id is a uuid which won't change when you merge
[11:07] <james_w> bzr log --show-ids
[11:07] <asac> nice
[11:07] <james_w> talking with you has made me see that this could be improved
[11:08] <asac> james_w: ok. so what exactly is needed in default.conf?
[11:08] <james_w> jelmer uses this mode and keeps hitting the -2 problem
[11:09] <james_w> and I think I may be able to make it work for him, make it easier for you, and still work for the other use case that is why we have these problems
[11:09] <james_w> I need to think about it a bit more first though
[11:09] <asac> james_w: sure
[11:09] <asac> james_w: actually. we have those auto scripts i pointed you to
[11:09] <james_w> http://jameswestby.net/bzr/builddeb/user_manual/export_upstream.html
[11:10] <asac> james_w: those are atomic things helpful to auto sync with AMO repository
[11:10] <james_w> I think "export-upstream = ." should work
[11:10] <asac> james_w: ok. is there a convenience script that allows me to branch "upstream" from a .ubuntu branch?
[11:10] <james_w> I reckon you should hold off from using this in anger until I have fixed it up though
[11:10] <asac> that would help me to upgrade the .upstream branches
[11:10] <james_w> there is code, but no script
[11:11] <asac> e.g. bzr branch-upstream lp:~mozillateam/firefox-extensions/extension1.ubuntu
[11:11] <asac> err
[11:11] <asac> e.g. bzr branch-upstream lp:~mozillateam/firefox-extensions/extension1.ubuntu extension1.upstream
[11:11] <asac> that would be quite cool i think
[11:13] <asac> james_w: so i can export-upstream-revision = <revno-upstream-head> ... and bzr commit would look at the export-upstream = ... field, then guess the upstream revision-id ... and remember that in the commit somewhere?
[11:14] <asac> sounds like massiv magic ;)
[11:17] <asac> james_w: or do I need to use tag: ... for now? (in export-upstream-revision)
[11:17] <asac> (would work too here i guess)
[11:30] <james_w> there's no magic to remember a revision id
[11:31] <james_w> if you put a revision number in export-upstream-revision then it will look up that revision number in whatever you have for export-upstream whenever it needs that revision
[11:34] <asac> james_w: ok. how is the syntax for a revision-id?
[11:34] <asac> is there some prefix like: tag:
[11:34] <asac> or just the revision id?
[11:34] <james_w> revid:
[11:38] <asac> cool
[11:38] <asac> that will work
[14:12] <fta2> asac, why did you remove the shlib from nspr ?
[14:26] <asac> fta2: whats the prob?
[15:10] <fta2> http://package-import.ubuntu.com/x/xulrunner-1.9/
[15:11] <asac> yeah
[15:11] <asac> i looked at those
[15:11] <asac> as outlined in mail its not really for us yet ;)
[15:12] <asac> but a good start
[15:12] <fta2> indeed. it should identify VCS-* and try to merge that with what has been really pushed. tricky.
[15:13] <asac> fta2: heh
[15:13] <asac> fta2: yeah. well. do you have scrollback?
[15:13] <asac> fta2: i talked about it with james
[15:13] <fta2> not here. only at home
[15:13] <asac> fta2: we need to add a meta file that refers to upstream branch and revision-id
[15:14] <asac> we would then commit that when we bump the changelog
[15:14] <asac> unfortunate that we dont have a .upstream branch
[15:14] <asac> but we actually could use something like the import .upstream branch
[15:14] <asac> fta2: i wonder how long branching xulrunner .upstream takes ;)
[15:14] <asac> its quite a bunch of files
[15:16]  * asac runs time bzr branch http://package-import.ubuntu.com/x/xulrunner-1.9/intrepid-upstream
[15:16] <fta2> i gave up on imports of upstream branches in lp for chromium, always broken :(
[15:18] <fta2> and locally, git-svn is many times faster than bzr-svn
[15:18] <fta2> so i work in git now
[15:18] <asac> yeah
[16:54] <fta2> asac, bug 302859
[16:57] <fta2> same for me
[17:04] <fta2> this is related to 1.9.1
[17:34] <asac> fta2: yes. maxVersion issue too here
[17:38] <fta2> yep, i've mentionned that in the bug already, i'll prepare a patch for seb