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