[00:00] <BUGabundo> thanks :)
[00:18] <BUGabundo> bye
[00:20] <fta> hm, looks like someone took care of libxcb-render-util0
[00:34] <fta> asac, https://edge.launchpad.net/~fta/+archive/staging  please give it a try
[01:43] <NCommander> asac, ping?
[01:48] <micahg> NCommander: he's probably sleeping in Europe :)
[01:49] <NCommander> micahg, asac sleeps?
[01:49] <NCommander> :-)
[01:50] <micahg> :)
[05:22] <ripps> fta: you in, I'm the one who emailed you earlier with a question on your ppa-scripts. I'm trying to set one up with several git sources, but I'm getting confused with get-orig-source stuff, I've never used them before.
[06:17] <ripps> Does anybody here know about fta's ppa-scripts?
[06:27] <ripps> I'm confused with this debian_tag stuff in get-orig-source
[08:03] <asac> NCommander: back ;)
[08:05] <NCommander> asac, wb, so thunderbird 3.0 works, now what?
[08:09] <asac> NCommander: how well does it work? are there any performance issues in general? how long did you use it?
[08:10] <NCommander> asac, seems to work ok, I made a dummy account, checked the menus. I didn't abuse it or actually download any mail though
[08:11] <asac> k
[08:12] <asac> i am not sure what to do next. investigating those crashes would probably be quite time consuming
[08:19] <NCommander> asac, indeed ;-/
[08:19] <asac> NCommander: so, if you want to debug it for real, you probably should start getting a real --enable-debug --disable-optimize build of tbird 2
[08:20] <NCommander> what will that do specifically?
[08:20] <asac> well. that will enable more debug logging, assertions, etc. but also make the stacktraces more useful by disabling optimization
[08:21]  * NCommander hopes that such an action doesn't make the segfault disappear
[08:21] <asac> thats possible, but in this case its unlikely imo
[08:21] <asac> let me check something
[08:21] <NCommander> sure
[08:23] <asac> http://paste.ubuntu.com/193271/
[08:23] <asac> apply that patch and build tbird.
[08:24] <asac> after configure has run, abort the build and go to build-tree/mozilla
[08:24] <asac> and run just "make"
[08:24] <asac> once its finished you can start the debug build in dist/bin
[08:24] <asac> ./thunderbird
[08:25] <asac> start the debug build == start the application ;)
[08:26] <NCommander> handy
[08:26] <asac> ripps: DEBIAN_TAG=tag
[08:27] <ripps> asac: huh?
[08:27] <asac> ripps: you said you were confused by debian_tag stuff ;)
[08:27] <asac> what in particular ;)
[08:27] <asac> ?
[08:28] <ripps> Um unsure on how to apply fta's method to git. I'm not sure what I'm suppose to do. I guess I just don't understand the terminology as well.
[08:30] <asac> ripps: git has the concept of tags, right?
[08:30] <asac> so i guess thats not your problem ;)
[08:30] <asac> what confuses you in particular?
[08:30] <ripps> asac: No, it understand that, git tag show a list of release names
[08:31] <ripps> what I don't know how to is his method involves bzr log on a remote branch, I can't do that with git until I've pulled into a local one
[08:31] <asac> ripps: so assume you have a release name X .... DEBIAN_TAG=X means that you want to get the tarball exported for that release
[08:32] <ripps> But I'm not trying to get the tarball for a release, I'm trying to get a tarball for an upstream git snapshot
[08:32] <asac> ripps: ah. yeah. i am not sure if there is a way to query log and stuff on remote branches
[08:32] <asac> ripps: DEBIAN_TAG is only used to get certain releases
[08:32] <ripps> His examples all use bzr, which makes infinately more frustrated to convert to git
[08:33] <asac> ripps: DEBIAN_DATE= is used to get certain date snapshots
[08:33] <asac> ripps: well. all the mozilla stuf we are running is using mercurial
[08:33] <asac> actually i think we only have one project that is all bzr, e.g. gwibber
[08:34] <asac> ripps: or are you saying that your debian/ stuff is in git too?
[08:34] <ripps> asac: Yeah, but I can't figure out how he does that with his ppa-scripts, the only one he's explained is his gwibber bzr stuff
[08:34] <ripps> asac: I
[08:34] <ripps> I've setup a branch for my debian stuff
[08:34] <ripps> Let me show you what I've got so far.
[08:35]  * asac  has to get a coffee first now
[08:36] <ripps> https://code.edge.launchpad.net/~gmpc-trunk/+junk/gmpc.trunk
[08:40] <asac> ifneq (,$(DEBIAN_TAG))
[08:40] <asac> get-orig-source: TAG  = $(NULL)
[08:40] <asac> isnt that wrong?
[08:40] <asac> why is TAG unset if there is no DEBIAN_TAG?
[08:41] <asac> also ... is get-orig-source: TAG  = $(NULL) valid make code at all?
[08:41] <NCommander> asac, building
[08:41]  * asac continues to produce coffee ;)
[08:41] <NCommander> Probably will take quite a few hours
[08:41] <asac> NCommander: great
[08:41]  * NCommander will need coffee soonish
[08:42] <ripps> asac: I just copied what he had in the gwibber.head code
[08:45] <ripps> asac: okay, what is TAG supposed to be? The release version, the git date, or git version?
[08:46] <ripps> Do I set it early on, like is shows here, or should I do after I've cloned a branch from git?
[08:47] <asac> ripps: well. i used git a bit and i didnt find a way to do anything without first cloning
[08:48] <asac> so i guess if upstream has git it needs to clone first ;)
[08:48] <ripps> So I should put this TAG stuff in gos-co:
[08:50] <ripps> Should I manually specify the release version? Because gmpc git only shows the releases, but in reality the developer refers to the version as 0.18.1, but git will only show 0.18.0
[08:51] <ripps> He then bumps it up 0.18.95 when it's in beta
[08:51] <asac> ripps: i am not sure, but i would think you need to do the following:
[08:51] <asac> get-orig-source: TAG  = -r $(shell bzr log --limit 1 $(GWIBBER_URL) | grep ^r | head -1 | cut -d' ' -f2)
[08:51] <asac> -> make this line not use bzr log
[08:51] <asac> i think fta uses wget and sedding to get that info for things that dont support remote "log"
[08:52] <asac> at least thats one option
[08:52] <asac> the other option is to depend on the gos-all thing first
[08:52] <asac> and then use git log locally to get that info
[08:52] <ripps> obviously, I just haven't edited since I copied it. I'm considering removing all that stuff and just keeping 'get-orig-source: gos-all'
[08:53] <ripps> ...hmmm all I want is to have the packages built with gmpc-git$DATE.$REVISION-0ubuntu1
[08:54] <asac> ripps: so does anything work at all atm?
[08:54] <asac> i think in general you are on the right track
[08:55] <asac> you just miss corner cases
[08:55] <asac> and have syntax errors i would think (like three get-orig-source: rules... which probably make the stuff fail)
[08:55] <ripps> asac: well, my old version tried to use git pull on a local directory holding the git branches. It seemed to recongnize and build and locate the orig.tar.gz's but then it wouldn't do anything with them and quit out without ever running dput
[08:57] <asac> ripps: whats the difference to what you have now?
[08:57] <NCommander> asac, I think you got that patch backwards
[08:58] <asac> NCommander: thought its already building ;)?
[08:58] <ripps> asac: tons, I've completely redone the get-orig-source, You should be able to see in older revisions in the gmpc.trunk bzr branch I linked you
[08:58] <asac> (could be that i made the diff in wrong order)
[08:58] <asac> (or edited the .orig ))
[08:58] <asac> (its early)
[08:58] <NCommander> asac, as in; apt-get source thunderbird :-P
[08:58] <asac> heh
[08:59] <asac> NCommander: http://paste.ubuntu.com/193286/ ;)
[08:59] <asac> better?
[09:01] <NCommander> yup ;-)
[09:01] <asac> ripps: ok. so revision 7 looks rather incomplete (e.g. no DEBIAN_TAG etc. at all)
[09:02] <ripps> so, for $VERSION I should get today's date, or should I get the date of the last commit?
[09:03] <asac> ripps: version is either a) the explicit version passed to DEBIAN_TAG (e.g. DEBIAN_TAG=COMMITID=EXPLICITVERSION)
[09:04] <asac> or b) the date of the topmost commit + the short commit id i guess (e.g. DATE.commitid)
[09:05] <asac> if DEBIAN_TAG= has no explicitversion you probably want to use the b) form too ... just getting the date of the commit with the given tag/commitid
[09:05] <asac> (instead of topmost commit)
[09:06] <asac> ripps: makes any sense to you?
[09:06] <ripps> Well, according to fta's gwibber.head, he used TAG to get the revison number, which in git would be it's 7 digit hash.
[09:06] <asac> ripps: yeah. the problem is that bzr revision number always increase ... problem is that this is not true with git commit ids
[09:07] <ripps> ... okay, there are too many varibles with similar meanings going on... hold on, brb
[09:07] <asac> so you need to prefix the version with date
[09:07] <asac> or something else that spans a strict order
[09:07] <asac> ripps: i think you can forget about almost everything that is done with gwibber because it doesnt match for git
[09:08] <asac> just implement a get-orig-source that either gets the topmost commit (if no DEBIAN_TAG is given) or gets the DEBIAN_TAG
[09:08] <asac> the only thing you have to invent is how to guess a good version out of it
[09:08] <asac> i suggest that you always use the date of whatever commit you are using and append the short commit id
[09:09] <asac> actually i wanted to test his script for my networkmanager/connman stuff
[09:09] <asac> i face the same problem there ;)
[09:34] <jamesh> asac: hi.  I was giving your updated couchdb package some testing
[09:35] <jamesh> I had some problems with the LD_LIBRARY_PATH bits because the xulrunner directory was after /usr/lib so the old libmozjs was getting found
[09:35] <jamesh> after fixing that, I still ran into some failures in the couchdb test suite
[09:37] <jamesh> as I'm running this on a jaunty box, I'm not sure how much of the problems are local and how much are to do with the package
[09:42] <asac> jamesh: what as in LD_LIBRARY_PATH ?
[09:42] <asac> "because the xulrunner directory was after /usr/lib" ... dont understand what you mean here
[09:43] <asac> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/xulrunner-`xulrunner --gre-version`/
[09:43] <asac> thats wrong?
[09:43] <jamesh> asac: so, the couchdb script was running the erlang VM with "env LD_LIBRARY_PATH=/usr/lib:${LD_LIBRARY_PATH} erl ..."
[09:43] <jamesh> that crack came from icu-config.patch
[09:44] <jamesh> I also updated the bit you added to put the xulrunner path first and not add stray colons if $LD_LIBRARY_PATH wasn't set
[09:44] <asac> ok
[09:45] <asac> jamesh: so i forgot to update some script?
[09:45] <asac> where is this erlang thing run?
[09:45] <jamesh> asac: with the package installed, if you go to "http://127.0.0.1:5984/_utils/index.html" there is a link to run the test suite on the right
[09:45] <jamesh> asac: this was in /usr/bin/couchdb -- one of the files you patched
[09:46] <jamesh> search for "command="
[09:46] <asac> jamesh: ah ok. so the problem is that libmozjs0 is installed
[09:46] <asac> ok fixing the order should help
[09:47] <asac> e.g. export LD_LIBRARY_PATH=/usr/lib/xulrunner-`xulrunner --gre-version`...
[09:47] <jamesh> asac: even after fixing that I was getting some failures in the test suite.  So I was wondering if it passed for you.
[09:47] <asac> jamesh: why the hell are they adding /usr/lib to LD_LIBRARY_PATH at all?
[09:47] <asac> jamesh: isnt the testsuite run during build?
[09:48] <jamesh> asac: the test suite is run from within a web browser :(
[09:48] <asac> yeah. thats why i asked you to look, because i have absolutely no clue on couchdb ;)
[09:48] <asac> good
[09:48] <asac> so how do i run this thing?
[09:49] <jamesh> go to the URL I listed above, click the "test suite" link, then click "run all"
[09:49] <jamesh> asac: the unpatched version of the couchdb script runs "icu-config --invoke erl ..."
[09:49] <jamesh> that is intended to make sure it runs in an environment that can find the ICU libraries
[09:50] <asac> jamesh: which test fails?
[09:50] <asac> only thing that fails is "stats" test
[09:50] <asac> # Assertion 'open_databases > 0 && max >= open_databases, name' failed: should keep the same number of open databases when reaching the max_dbs_open limit
[09:50] <jamesh> as the Debian packager didn't want to depend on libicu-dev, he inlined what it did
[09:50] <asac> does that match your observation?
[09:51] <jamesh> asac: I got failures in a number of the tests before that one, so it might be a local problem then.
[09:51] <asac> jamesh: uninstall libmozjs0 and libxul0d
[09:51] <asac> those might hurt
[09:53] <asac> i just used the package without changing anything else (e.g. no further hacks to LD_LIBRARY_PATH etc)
[09:55] <jamesh> I don't have libxul0d installed, and had moved the libmozjs libraries out of the way
[09:55] <asac> hmm. i have that installed. let me check
[09:57] <asac> ok after uninstalling libmozjs0d package and restarting couchdb i still get the same results
[09:57] <asac> one test fails: stats
[09:58] <asac> not sure then. would need to see more details. i would however, think that its unlikely that it doesnt work in jaunty
[09:58] <asac> its the same libmozjs
[09:58] <jamesh> I'm also getting an error at http://localhost:5984/_config
[09:58] <asac> i get that too i think
[09:58] <asac> {"httpd_design_handlers":{"_list":"{couch_httpd_show, handle_view_list_req}","_show":"{couch_httpd_show, handle_doc_show_req}","_view":"{couch_httpd_view, handle_view_req}"},"httpd_global_handlers":{"/":"{couch_httpd_misc_handlers, handle_welcome_req, <<\"Welcome\">>}","_active_tasks":"{couch_httpd_misc_handlers, handle_task_status_req}","_all_dbs":"{couch_httpd_misc_handlers, handle_all_dbs_req}","_config":"{couch_httpd_misc_handlers, handle
[09:58] <jamesh> thtat's not an error
[09:58] <asac> ah
[09:58] <asac> ;)
[09:59] <jamesh> so, it seems like things are mostly working for you, which is good.
[09:59] <jamesh> I might try rebuilding through my PPA to see if I get a different result
[09:59] <asac> jamesh: i would really suggest that you wipe this libmozjs0d package completely and use exactly the package i gave you. i cannot imagine why it would be different on jaunty
[10:00] <asac> or give me details on the errors you get on the testcases ;)
[10:00] <asac> though i doubt that they will mean anything to me ;)
[10:03] <asac> jamesh: could be that you had libmozjs-dev installed next to xulrunner-dev while building
[10:04] <jamesh> that could be it
[10:05] <asac> jamesh: ok uploaded a jaunty backport to https://edge.launchpad.net/~asac/+archive/sandbox ... will take 30 minutes i would hope
[10:07] <asac> why * Change erlang-nox dependency to erlang-inets.
[10:07] <jamesh> asac: I'm actually testing against a couple of other custom packages, so I'll use the build from my PPA
[10:07] <asac> ?
[10:08] <jamesh> in jaunty, erlang-nox is a mega package containing every erlang library outside of the base system that doesn't depend on X
[10:08] <asac> k
[10:08] <jamesh> in karmic it has been split up into smaller packages with erlang-nox existing to satisfy dependencies
[10:09] <jamesh> depending on erlang-nox brings in a corba implementation, asn1 parser, distributed database, etc
[10:09] <asac> ok deleted the build in my sandbox
[10:10] <jamesh> not the kind of thing you want when trying to squeeze couchdb onto the install CD :)
[10:15] <jamesh> asac: http://launchpadlibrarian.net/27771915/couchdb_0.9.0-2ubuntu2~jh1_0.9.0-2ubuntu2~jh2.diff.gz <- those are the changes I made
[10:18] <asac> as long as you are sure that all commands get the proper LD_LIBRARY_PATH now thats probably fine ;)
[10:18] <asac> for me it was easier just to set it on top of the script
[10:19] <asac> anyway. i would think for now that you built it while having libmozjs-dev installed or something
[10:19] <asac> unless you always used ppa to build (in which case i wouldnt know)
[10:20] <asac> ripps: fta: thanks
[10:21] <asac> i would think the main problem is to agree on a good versioning scheme for git.
[10:21] <fta> i already packaged something using git, hold on
[10:21] <asac> fta: i saw that we have mobile-browser.git in mozclient
[10:21] <asac> not sure if that would work out of box
[10:21] <ripps> Okay, libmpd seems to be working, but now I think it's failing when it starts gmpc... something about no push location
[10:22] <fta> mozclient is not the easiest to start with..
[10:22] <asac> (besides from the fact that moblin replaced the repo with something completely different)
[10:22] <asac> yeah
[10:22] <asac> i figured that and would prefer not to use that for NM/connman
[10:23] <fta> https://code.edge.launchpad.net/~fta/+junk/yui3.head
[10:23] <fta> yui3 uses git
[10:24] <asac> no revs yet ;)
[10:24] <fta> lp is slow ;)
[10:25]  * asac still waiting ;)
[10:26] <fta> well, http://paste.ubuntu.com/193333/
[10:26] <ripps> fta: where does libmpd.head.ppa push to after it's done updating the changelog? It can seem to figure the next part out
[10:27] <asac> fta: are you sure that date in the git log will always move ahead?
[10:27] <asac> e.g. if i merge a branch things get committed on top, but i think they still use the same date
[10:28] <fta> good question. i guess you have to figure that out yourself based on the old commits
[10:30] <jamesh> asac: okay.  Looks like the problems were my fault.
[10:30] <fta> ripps, to the user account from dput
[10:30] <asac> jamesh: what did you do ;)?
[10:30] <jamesh> asac: turned on debugging, and it looks like there was another undeclared dependency
[10:31] <asac> ah. so missing erlang pieces?
[10:31] <jamesh> needed to install erlang-xmerl
[10:31] <jamesh> yeah
[10:31] <ripps> fta: what does that have do with bzr? bzr is getting a cannot push error
[10:31] <asac> good. i always knew that shlibs is a great invention ;)
[10:31] <ripps> Actually, it's not getting to the dput step...
[10:32] <fta> ripps, show me
[10:32] <asac> ripps: in the docs it say that it will auto push daily bumps
[10:32] <jamesh> error reporting does not seem to be one of Erlang's strong points
[10:32] <asac> ripps: its important that the branch already has a push location for that
[10:32] <jamesh> I've been spoiled by Python
[10:32] <asac> (at best use a different location)
[10:32] <asac> hope i didnt talk non-sense now ;)
[10:32] <asac> jamesh: sorry to hear that you need to work with erlang ;)
[10:33] <asac> must be a special experience ;)
[10:33] <fta> asac, ripps: no need to already have a predefined location if you're using the conf files
[10:34] <jamesh> at least I don't have to hack mozilla :)
[10:34] <asac> ah
[10:34] <asac> jamesh: 1:0 for you ;)
[10:35] <asac> fta: at least the karmic kernel tree seems to move strictly ahead http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git
[10:40] <fta> ripps, the idea is that a given pocket is pushed (dput) using the target specified in the conf file, and the daily branch goes to the lp account extracted from the corresponding dput path
[10:40] <ripps> fta: here's the output I've got.  http://paste.ubuntu.com/193337/
[10:41] <fta> i have to run now. will you still be there in an hour or 2?
[10:41] <ripps> fta: and here's my confs.  http://paste.ubuntu.com/193339/
[10:41] <ripps> I'll probably be around
[10:42] <fta> ripps, what was your cmd? update or daily?
[10:42] <ripps> fta: I just ran ./daily.sh gmpc
[10:43] <fta> 04:35:28 -0500 woww, it's early for you.. or really late
[10:44] <ripps> fta: I'm on a night schedule,
[10:44] <fta> oh :)
[10:44] <ripps> So, probably late
[10:47] <fta> i'm late, i'll get back to you asap
[11:48] <fta2> back
[11:49] <fta2> ripps, still there?
[11:49] <ripps> fta2: yo
[11:49] <ripps> I still can't figure out why it cant push before dput
[11:50] <fta2> ripps, i don't have a debug hook for your problem, could you please edit daily.sh, find where update-* is, and run it as sh -x $BINDIR/... then paste me the logs
[11:52] <fta2> (just add sh -x in front of the line calling update-pkg.sh)
[11:54]  * asac prepares for lunch
[11:55]  * ripps forgot to output it to a txt file...
[11:57] <fta2> ./daily.sh pocket 2>&1 | pastebinit :)
[11:58] <ripps> fta2: http://paste.ubuntu.com/193376/
[12:01] <fta2> ok, i see. i can't parse your ~/.dput.cf. could please paste it ?
[12:02] <ripps> omg, i put stage instead of staging
[12:02]  * ripps hits himself repeatedly
[12:04] <fta2> lol
[12:05]  * fta2 makes a mental note to add an error message there
[12:06] <fta2> asac, did you try it?
[12:19] <asac> fta2: your scripts? nope. quite happy that ripps jumped the first gun for now
[12:19] <asac> ;)
[12:19] <asac> will use his findings to do my stuff. still not sure about the upstream version format i want to use for NM+connman
[12:20] <asac> (and gnash, but thats all bzr, so probably easy)
[12:20] <ripps> I forgot to install bzr-builddeb, but otherwise, things look much better than before. It didnt' dput though
[12:22] <asac> (for me: http://paste.ubuntu.com/193382/)
[12:24] <asac> hmm ... not sure if KMS is really a good thing. monitor blinks every other minute ;)
[12:32]  * asac out for a bit
[12:39] <ripps> fta2: hmm... it seems to run the script 3 times, because it would fail after each package, but the third time it actually worked. I didn't do anything. The first two times a I got this error about diverges and meges.
[12:40] <ripps> But now, it's uploading via dput
[12:50] <asac> ripps: so all is working now?
[12:51] <ripps> asac: https://edge.launchpad.net/~ripps818/+archive/staging
[12:51] <asac> can you suggest changes to the README ... or would it be better to reference documented examples for git etc.
[12:51] <ripps> a couple packages say failed, but their just in depwait for libmpd to finish
[12:52] <asac> k
[12:52] <asac> ripps: so you are doing libmpd and gmpc as dailies?
[12:52] <ripps> You can take pointers from how I did mine. The debian/ for the packages is stored in my bzr branches under $package.trunk
[12:52] <ripps> https://code.edge.launchpad.net/~gmpc-trunk
[12:53] <asac> ripps: sure. just wondered if you would be willing to suggest improvements to the README based on your experiences
[12:53] <ripps> asac: that's the plan, but I plan on expanding it to gmpc-plugins, mpd, mpc, and mpdscribble
[12:53] <asac> ripps: so does the daily script bump the lower version on the build depends automatically?
[12:54] <ripps> asac: well, seeing as alot of glitches came from not having dput line setup correctly...
[12:54] <asac> or is that something we do in a special way for firefox/xulrunner
[12:54] <asac> ripps: ok.
[12:54] <asac> ripps: and how about the mental model? i am pretty much used to what the DEBIAN_TAG thing mean etc. wonder if that was difficult to get right for you
[12:55] <ripps> asac: debian_tag was completely foreign concept to me when I started, but now I get it (I think)
[12:56] <asac> ripps: do you think there are better ways to achieve this?
[12:57] <ripps> probably, but hell if I know it. Launchpad has blueprint to build this thing into soyuz, so ultimately, the whole thing might be unecessary in the future.
[12:57] <asac> well. lets see.
[12:57] <asac> i think for simple projects it might really happen soon. but the more complex ones somewhat bother me
[13:02] <ripps> Well, the blueprint mentioned that it would rely on a recipe file (that's the current idea). But it depends on the complexity of that.
[13:03] <asac> yeah. we will see ;)
[13:03] <asac> i dont see this coming in the next 6 month for mercurial upstreams ;)
[13:03] <asac> do you have the blueprint?
[13:03] <asac> (URL)
[13:08] <ripps> asac: https://wiki.ubuntu.com/DailyUpstreamBuildsPOCSpec
[13:10] <asac> goo that its me and fta used to outline this ;)
[13:10] <asac> hehe
[13:11] <asac> blocker is somewhat to get a lp:firefox branch i guess
 done well if by karmic's release there are 4-500 packages maintained
[13:12] <asac> meaning really 4-500 ? or rather 400-500?
[13:12] <asac> fta2: ?
[13:13] <asac> i assume the latter
[13:14] <ripps> Okay, this d/ling all of gmpc everytime I run daily.sh is annoying. I need to implement a method that uses a local branch that is updated...
[13:14] <fta2> Mark said 400-500
[13:15] <asac> ripps: what size does the gmpc project have? (e.g. including .git directory)
[13:15] <fta2> ripps, yep, you need a local branch ;)
[13:15] <ripps> It's probably about 20 megs for the entire branch...
[13:15] <fta2> ripps, glad to see it worked at the end ;)
[13:16] <ripps> fta2: yeah, well the hard part is getting the gmpc-plugins package working. It's a mish-mash of of 20+ different repos, some with different vcs's
[13:17] <fta2> couldn't be worse than chromium
[13:18] <asac> 14:17 < asac> james_w: so where can i find your latest daily build tools?
[13:18] <asac> 14:17 < james_w> asac: bzr-builder on launchpad
[13:20] <ripps> Now, the feature that I really want now is to port the vcs's commit changes to daily. So people actually know what's changed since yesterday
[13:21] <asac> yeah. makes sense ... somewhat
[13:22] <fta2> ripps, http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/rules#L253  nightmarish get-orig-source
[13:22] <fta2> it's all svn though
[13:28] <fta2> vcs's commit changes in changelog is somewhat tricky. either you create a new entry daily (pollution) or you reset the content of the current release log (then people will miss some) or you pile up everything in the current release (may be too big)
[13:29] <fta2> i initially wanted that too, but i gave up. it's better to just link to the upstream vcs browser
[13:39] <fta2> asac, did you test my last ia32-lib
[13:43] <asac> fta2: well. the last i tried missed those libs remember?
[13:43] <asac> didnt know there was an update afterwards
[13:43] <asac> i can do that though
[13:47] <fta2> Jun 11 01:34:45 <fta>   asac, https://edge.launchpad.net/~fta/+archive/staging  please give it a try
[13:50] <ripps> fta2: do you know how to do an if-then statement to check if a directroy exists in debian/rules?
[13:51] <fta2> globally or in a rule?
[13:52] <ripps> in a rules, I'm doing a check to see if a local repo exists and then to do either git clone or git pull
[13:52] <ripps> it's in gos-co
[13:53] <fta2> you can do it in shell
[13:53] <fta2> like this http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/rules#L297
[13:54] <ripps> just put a @ in front of it?
[13:54] <fta2> minus the echos.. i like my logs to be verbose. it helps the troubleshooting
[13:55] <fta2> no, the @ is to hide the command
[13:55] <fta2> the important part is the \ at the end of each line
[13:56] <fta2> so for make, it's a single line
[14:10] <ripps> fta2: what's the proper way to use the 'upstream' option in ppabot-pkg.conf?
[14:11] <fta2> what do you mean by proper way? ;)
[14:12] <fta2> it's just a directory that you can pass to your get-orig-source
[14:12] <fta2> so you just have to create it or update it
[14:13] <ripps> fta2: do you have any examples of get-orig-source using it?
[14:13] <fta2> chromium
[14:14] <fta2> look for LOCAL_BRANCH
[14:15] <fta2> firefox too but it's hidden into mozilla-devscripts / mozclient
[14:15] <fta2> i have no simpler example i'm afraid
[14:18] <fta2> i've only implemented that local cache for huge packages, like mozilla & chromium. i don't usually care when the tarball is small
[14:18] <fta2> brb
[14:26] <asac> so if i have a file with
[14:26] <asac> line1
[14:26] <asac> line2
[14:26] <asac> line3
[14:26] <asac> line4
[14:26] <asac> and want to reverse it to
[14:26] <asac> line4
[14:26] <asac> line2
[14:26] <asac> line3
[14:26] <asac> line4
[14:26] <asac> there seems to be no common unix command for that?
[14:26] <asac> what the heck?
[14:26] <asac> rev does the wrong thing
[14:26] <asac> tail -r doesnt exist on linux
[14:26] <asac> what am i missing?
[14:27] <asac> why does rev exist, but no rev-lines
[14:27] <asac> e.g. whats the so much more important use case for rev?
[14:31] <asac> ha. i found tac ;)
[14:32] <fta2> ?
[14:48] <huayra> anyone here has contact with the mozilla translation team?
[14:48] <huayra> Seth has not answered for over a month
[14:49] <huayra> and I am starting to wonder if I may just contact someone else
[14:49] <huayra> I need a translation to get in 3.5
[14:49] <huayra> (swahili-TZ)
[14:49] <asac> huayra: Seth?
[14:49] <huayra> from mozilla
[14:49] <asac> huayra: do you have the translation done?
[14:49] <huayra> yeah
[14:49] <asac> huayra: did you open a bug? which id?
[14:50] <huayra> I have been tracking the mozilla code to keep it up to date
[14:50] <huayra> let me give you the nr
[14:51] <huayra> https://bugzilla.mozilla.org/show_bug.cgi?id=293722
[14:51] <huayra> https://bugzilla.mozilla.org/show_bug.cgi?id=300754#c40
[14:51] <huayra> https://bugzilla.mozilla.org/show_bug.cgi?id=300754
[14:54] <asac> huayra: how did you try to reach him?
[14:55] <asac> zbraniecki: ^^
[14:55] <zbraniecki> yo
[14:55] <asac> hi! ;)
[14:55] <zbraniecki> hi asac :)
[14:55] <zbraniecki> how can I help you?
[14:55] <NCommander> asac, so thunderbird FTBFSed ...
[14:56] <asac> zbraniecki: seems huayra needs some help on getting his translation process started (read the last 10 lines or so)
[14:56] <asac> 15:48 < huayra> Seth has not answered for over a month
[14:56] <zbraniecki> yea, it'll be a nice concept to poke him on this
[14:57] <asac> zbraniecki: maybe you can give him some guidance?
[14:57] <zbraniecki> asac: I'm involved in the process
[14:57] <asac> zbraniecki: err. sorry. i think its not about launchpad export. just a plain translation contribution ;)
[14:57] <zbraniecki> it's a little bit complex case
[14:57] <asac> oh so sw-TZ is complex itself?
[14:57] <asac> how that?
[14:57] <zbraniecki> since we received multiple localizations which are heavily different
[14:58] <asac> hmm
[14:58] <zbraniecki> and need to ensure we do the right thing
[14:58] <asac> yeah i see that that is difficult
[14:58] <asac> huayra: can you shed some light on which group does what and why you have different groups duplicating efforts?
[15:05] <asac> if our version of Firefox can't be optimized...
[15:05] <asac> why not use swiftweasel???
[15:05] <asac> http://brainstorm.ubuntu.com/idea/18058/
[15:05] <asac> i like ideas ;) ... but not if people ping me about them :(
[15:06] <asac> zbraniecki: we have a similar thing you might wanna think/talk about for romanian
[15:06] <asac> zbraniecki: seems there are two types or romanian: new + old
[15:06] <zbraniecki> asac: we have a very solid community in Romania
[15:06] <asac> not sure if its new or not, but firefox translation uses the direct opposite of what is used everywhere in gnome
[15:07] <zbraniecki> I can get you in touch with them
[15:07] <asac> well no need to.
[15:07] <zbraniecki> irina, alina, alexandruu are the core and they are very active
[15:07] <asac> just wanted to point out that there is not always a one-solution fits all
[15:07] <zbraniecki> I visited them some time ago at the conference they organized
[15:07] <zbraniecki> yea
[15:07] <asac> for instance, we would need a X translation for gnome and a Y solution for KDE ... and maybe you need a Z solution for windows ;)
[15:07] <asac> what a mess
[15:07] <zbraniecki> but I didn't hear from anyone at the conference anything about two romanians a the time
[15:08] <asac> i was approached by some guy working with gnome and on ubuntu translations
[15:08] <asac> during last UDS ... he explained to me that firefox is currently using the opposite what the rest of the apps use
[15:08] <asac> i even think its really even different glyphs
[15:08] <zbraniecki> I'll ask them about it
[15:08] <asac> like greak vs. latin
[15:08] <zbraniecki> thanks for pointing that out
[15:08] <asac> yeah.
[15:09] <asac> not sure if this would be something we need to differentiate by country code or something
[15:09] <asac> like ro-RO and ro-RN ;)
[15:09] <asac> (excuse my ignorance)
[15:12] <zbraniecki> yea, let's see what they'll say
[15:13] <zbraniecki> they're young and pretty relaxed people, I trust them not to be zealots on any side
[15:13]  * huayra reading answers
[15:13]  * huayra was taken into a meeting
[15:14] <huayra> ok. To address who does what read this: https://wiki.ubuntu.com/UbuntuSwahiliTranslators/UmojaProject
[15:14] <huayra> and this: http://huayra.wordpress.com/2009/04/04/impossibles-take-just-a-little-bit-more-time-the-umoja-project-a-swahili-translation-community-effort/
[15:15] <huayra> but if you don't want to read the whole thing, well I put this for you like this
[15:15] <asac> huayra: can you specifically explain to me what kind of translation groups you have and why you dont join a team?
[15:15] <asac> cool
[15:15] <huayra> I am just managing here
[15:15] <huayra> and I play the political game in the shadow ;)
[15:16] <huayra> Ibasically the Swahili translation was not updated since 2004
[15:16] <huayra> and a collegue and I started a team (he is gfrom Tanzania)
[15:17] <huayra> actually you played a role in this, remeber we chatted about this in  november last year?
[15:17] <huayra> 2008-11-24 Contacted the Ubuntu Mozilla team for advice on FF3 translation. They advise us to contact directly Axel and Seth from Mozilla.
[15:18] <asac> i remember your nick, yeah
[15:18] <huayra> so we managed to make a translation in a short time by creating a local community in Dar-Es-Salaam and on the web
[15:18] <huayra> Emanuel, my collegue, flown down to Tanzania over Christhmas and they got 80% of the work done
[15:19] <huayra> at the same time the kilinux group, the one that was suppossed to make this upstream back in 2004
[15:19] <huayra> did nothing
[15:19] <huayra> but started acting after we had translated most of it
[15:20] <huayra> http://www.it46.se/show_entry.php?id=152
[15:20] <huayra> http://www.it46.se/show_entry.php?id=148
[15:20] <huayra> Alberto who used to lead this effort left the upstream work to the team
[15:21] <huayra> they did not do anything with it in 4-5 years
[15:21] <huayra> so basically we took over that
[15:21] <huayra> and contacted Mozilla as you guys recommended us
[15:21] <huayra> we had a nice cooperation until the Mozilla guys got blinded by politics, overlooked the facts and now they do not know what to do
[15:22] <huayra> so I asked Seth to at least include the translation in beta state under 3.5
[15:22] <huayra> and no answered has been given
[15:22] <huayra> asac, that's the story
[15:22] <asac> *sigh*
[15:22] <asac> huayra: have you ever tried to communicate with the kilinux folks
[15:22] <asac> or only thorugh mozilla?
[15:22] <huayra> yep
[15:22] <asac> huayra: so what do they say?
[15:22] <huayra> I had before we started our own effort
[15:23] <huayra> they wanted me to support them with money... I am not affraid of saying it: It's a scam
[15:23] <huayra> they didin't want to cooperate as a community they wanted cash
[15:23] <fta2> ripps, to speed up your packaging changes, you can run sync instead of daily. like ./sync-ppa.pl -p .../ppabot-pkgs-foo.conf -c ..../ppabot-foo.conf -P [somepackage]
[15:23] <huayra> I can send you the email I sent to Seth and the proposal from the team
[15:23] <asac> zbraniecki: maybe you could invite some kilinex folks together with huayra and maybe me to phone conference?
[15:24] <huayra> they got half a million kroner from Sweden in 2005 and nothing was ever done...
[15:24] <asac> zbraniecki: or an irc meeting
[15:24] <huayra> no
[15:24] <asac> i think this can only be sorted by having a open multi-party discussion
[15:24] <huayra> do not include me in that equation
[15:24] <fta2> ripps, it will just resync the branches, based on the same tarball. so it will increment the version iterator for you. just commit stuff to your packaging branch and sync-ppa it
[15:24] <huayra> you can rather include
[15:24] <huayra> Emanuel
[15:24] <huayra> the tech lead
[15:24] <asac> huayra: whoever you consider best for that job
[15:24] <huayra> a Tanzanian
[15:25] <huayra> of course, we have tried to work this in the open, but unfortunately we are not getting answers
[15:25] <huayra> and what we want is to get the job done
[15:25] <huayra> to so\hjow to the team that their effort was worthwhile
[15:25] <huayra> and that communities can do more with action that with titles
[15:26] <huayra> and so we propose that the KlnX team takes the credit as long as this whole things gets done
[15:26] <huayra> but not even that is good enough....
[15:26] <ripps> fta2: when would the best time of day to build these packages, they're nowhere as cpu intensive as chromium or mozilla, but gmpc-plugins alone can take some time (setting up build enviromnet 20 different packages)
[15:27] <zbraniecki> huayra: I think you have a little bit one sided point of view on this issue
[15:27] <huayra> of course I do
[15:27] <zbraniecki> huayra: I'll try to push things on our side
[15:27] <asac> well thats normal ;)
[15:27] <huayra> that's why I am not getting involved
[15:27] <fta2> ripps, hold on, i wrote something about that a while ago
[15:27] <huayra> I am just trying to get people to act
[15:27] <huayra> that's all
[15:27] <zbraniecki> huayra: makes sense to me.
[15:27] <fta2> ripps, https://wiki.ubuntu.com/fta/ppa-queues
[15:27] <zbraniecki> huayra: I'm sorry it takes so long for Mozilla to get you through
[15:28] <huayra> not me, the Umoja project team
[15:28] <zbraniecki> we're very sensitive and careful with such decisions
[15:28] <huayra> I am just a community manager
[15:28] <huayra> I know
[15:28] <huayra> I have my colleague Emanuel here now
[15:28] <ripps> fta2: btw, thanks for all the help, this is really awesome and should make maintaining all the packages by gmpc-trunk team alot quicker and easier
[15:28] <huayra> maybe he can read the log and then talk to you directly?
[15:29] <zbraniecki> and since it overlaps with 3.5 release we have less cycles to analyze the case with all details
[15:29] <zbraniecki> huayra: I'd be happy to chat with him, I already did on email and we received your work thanks to Emanuel :)
[15:29] <asac> huayra: i think its fine. if zbraniecki says that mozilla is working on it, i would think we should just wait and maybe do some gentle reminders from time to time
[15:30] <zbraniecki> yea, I already sent two email since we started chatting and I'll try to get back to you with answers by today
[15:30] <fta2> ripps, you're welcome. let me know if you need more features that could be helpful for others too.
[15:30] <huayra> zbraniecki, ok then we let time do the trick
[15:30] <huayra> zbraniecki, I am not trying to push too much here
[15:30] <zbraniecki> huayra: you're doing the right thing. It takes way to long
[15:30] <huayra> I just do not want a team of people that have been working hard not see their work materialized
[15:31] <huayra> our next goal is start with OOO
[15:31] <huayra> and for that you need real motivation
[15:31] <huayra> And these people have been amazing
[15:31] <huayra> so I just want to see the right thing happen
[15:31] <zbraniecki> that's totally reasonable. I share your experience, since I've been a part of polish localization team for 8 years now :)
[15:31] <huayra> I feel strongly about this, yes, I am biased, yes. But I know that the right thing  is to get this over with
[15:32] <huayra> :)
[15:32] <huayra> Let see the facts,
[15:32] <huayra> I introduce to you eferuzi
[15:32] <huayra> the tech lead
[15:32] <asac> hi eferuzi
[15:32] <huayra> and I have to run and get my daughter from kindergarden
[15:32] <huayra> ;)
[15:32] <zbraniecki> hi eferuzi
[15:32] <zbraniecki> huayra: thanks for your poke :)
[15:32] <eferuzi> hey zb how are you
[15:33] <huayra> zbraniecki and asac thank you very much
[15:33] <zbraniecki> hi eferuzi :)
[15:33] <eferuzi> zbraniecki: how is all coming
[15:33] <eferuzi> well i have been working on TuxPaint and Pidgin
[15:34] <zbraniecki> eferuzi: huayra poked me about your case, and I jumped to bugs. we're delaying it :( I'm trying to see how can we unblock the process and get sw-TZ back on track
[15:34] <eferuzi> we had planned to do a conference this juni as i will be in Tanzania for two weeks
[15:34] <eferuzi> but we have had to wait till you accept our work
[15:35] <zbraniecki> eferuzi: I'm syncing back with the team on your case and I'll try to give you the status update by today
[15:35] <asac> cool
[15:36] <eferuzi> zbraniecki: what is the issue as its becoming very difficult  to motivate the team to do other projects as we had invested all we had on firefox
[15:37] <zbraniecki> eferuzi: I totally understand that. and I believe that we should not let the things block your team from getting firefox builds
[15:37] <eferuzi> we will appricate,
[15:38] <eferuzi> zbraniecki: i have sent the local builds out and have done some reviews based on the reviews.
[15:38] <zbraniecki> eferuzi: apologized for the delay to your team. I'll do my best to push it forward now
[15:38] <asac> from reading the mozilla bug 300754 the kilinux team basically agreed on providing feedback. doesnt read like they want to keep the lead on it
[15:38] <zbraniecki> yes, I saw your latest updates
[15:39] <zbraniecki> asac: well, there are still two localizations that are extremely uncompatible
[15:39] <asac> but i dont know what goes on behind the scenees of course
[15:39] <zbraniecki> I'll provide you all an email with the status update once I get my team back online (some of them dare to sleep now... americans ;))
[15:39] <asac> zbraniecki: so the one you attached is from kilinex?
[15:39] <asac>  sw-TZ updated to latest Fx3.5   (502.74 KB, application/octet-stream)
[15:39] <eferuzi> i will be in Tanzania from the 21st June - 5th July I have some locales for about 10 languages i want  to work on and I wanted to use use this time to also push Firefox into the rural areas
[15:39] <asac> 2009-04-06 16:26 PDT, Zbigniew Braniecki
[15:39] <zbraniecki> asac: depending on which one
[15:39] <asac> ?
[15:40] <asac> well last two attachments not submitted by Emanuel
[15:41] <asac> anyway. i am out of this game ;) .... ENOBACKGROUND ;)
[15:41] <eferuzi> asac: we sent out the words that we not in the Kilinux glossary so that they can look at them. The ideas was to do work and UDSM will do the QA
[15:42] <eferuzi> so i created a list of all the words that were new or different from what UDSM had and emailed it it to them
[15:43] <eferuzi> i have been waiting for the respond but nothing has come through.
[15:43] <asac> what is UDSM?
[15:43] <eferuzi> that KILINUX (Unversity of Dar Es Salaam)
[15:44] <eferuzi> zbraniecki + asac: i agree that may be the work we did is not the best swahili there is
[15:45] <eferuzi> but if we do not make it available for Swahili speakers them we will not know
[15:45] <eferuzi> so what tzLUG suggested to Kilinux is lets release it and the improve as we go along as it will take a while before the words are approved by the Tanzania Swahili Board
[15:46] <eferuzi> its a long chain of events before we have just one word approved
[15:47] <asac> eferuzi: approved by whom? UDSM?
[15:47] <asac> what does "approve a word" mean?
[15:47] <asac> is that a newly invented word for an otherwise not existing term
[15:48] <asac> or just about choosing one out of many existing/established translations?
[15:48] <eferuzi> it mean that say we say the word "plug in" as to translated to swahili
[15:48] <eferuzi> we do not have that word in Swahili
[15:48] <eferuzi> so what we would do is we would coin a term  and translate
[15:48] <eferuzi> as it stands the Kilinux says that these words have to be sent to the Swahili Board
[15:49] <eferuzi> and I totally agree with them
[15:49] <eferuzi> but the issue is that takes them a long time
[15:49] <asac> true
[15:49] <eferuzi> and i told them we can not work like that
[15:49] <eferuzi> we need speed as we have a lot to localised
[15:49] <asac> so couldnt we keep the ones that currently have no translation in english?
[15:50] <eferuzi> say that again
[15:50] <asac> at least here in germany, we dont translate all new computer words, but keep them until something else evolves
[15:50] <eferuzi> i do not get you
[15:50] <asac> i mean, there is no such thing like a board that tries to approve new word inventions
[15:50] <eferuzi> we can do that too
[15:50] <asac> instead they listen for what is used most
[15:50] <asac> and then standardize it
[15:50] <eferuzi> but in the tzLUG team we have language students that assist us with the localization
[15:51] <eferuzi> that is what i wanted to to
[15:51] <asac> well. i am just curious how your language evolves
[15:51] <asac> for instance, france has a board and they really try to enforce new french words for lots of new terms
[15:51] <eferuzi> but the Kilinux team says that words have to approved by the Swahili board
[15:51] <eferuzi> we have something like that in Tanzania
[15:51] <eferuzi> only that its a long process
[15:52] <asac> eferuzi: so simple question. if you talk with someone on the street about those things. what word are you using?
[15:52] <eferuzi> and you have to beg people to do that
[15:52] <asac> and did you ever experience, that suddenly a new word was invented and then everybody started to use that instead?
[15:52] <eferuzi> it looks like you and i work exactly tha sam
[15:52] <eferuzi> what we did when a word was new
[15:53] <eferuzi> we would ask people on the street
[15:53] <eferuzi> what it is
[15:53] <eferuzi> for example
[15:53] <eferuzi> we have a word like memory stick
[15:54] <eferuzi> if we to translate it will be "fimbo ya kumbukumbu" but in the street is know as flashi
[15:54] <eferuzi> and we would go with what the people are already used to
[15:54] <asac> zbraniecki: Adi Roiban aka adi at roiban dot ro is the RO translator that pointed out the RO difference (in case you want to give him a shot before talking to your ro translators
[15:56] <eferuzi> but then we would be stepping on Kilinux Team as they want all words to be approved by the board and that requires money and time which tzLUG we do not have
[15:56] <eferuzi> but we can do the work the best we know how
[15:56] <eferuzi> i will from him and email and get his wisdom
[15:57] <eferuzi> i think this is why it took Kilinux so much time to do the translation
[15:57] <eferuzi> i opted for lets do it now and review it over time. that way we make Firefox popular and get some feedback
[15:58] <eferuzi> as oppose to wait till we have all words approved, which will never happen as new words will continue coming out.
[16:02] <andrew_sayers> I'm interested in working around the issue with Flash not inhibiting the screensaver, and I was told it was better to come and ask you guys rather than just firing off patches.
[16:03] <andrew_sayers> (Of course, this was *after* firing off said patches)
[16:03] <andrew_sayers> Is there any interest in this idea, and what's my best course of action at this point?
[16:04] <asac> andrew_sayers: were you the one requesting for the ubufox merge?
[16:04] <andrew_sayers> Yeah, that's me.
[16:04] <asac> cool. sorry that i didnt reply yet. and thanks for prodding us here
[16:04] <andrew_sayers> Sure, just so long as I haven't made some horrible faux pas :)
[16:06] <asac> andrew_sayers: so ... are you still thinking that your approach is something that can be done in a fashion that rocks?
[16:06] <asac> or did you get new ideas in the meantime?
[16:07] <andrew_sayers> If there's interest, and the basic implementation doesn't make you throw up, I'd look for ways to make it more fine-grained, yeah.
[16:07] <asac> well. we always want to improve things. if this can be done in a good way, we should at least discuss it. so whats your latest idea ;)
[16:08] <andrew_sayers> Well, I'm mostly thinking about ways to better decide when to inhibit the screensaver.
[16:09] <andrew_sayers> For example, I assume it's possible to detect when FF is active and not minimised?
[16:10] <andrew_sayers> I'm not aware of any way to detect when Flash is playing fullscreen, but that would be a good test if it's possible.
[16:11] <asac> andrew_sayers: so i think one way to see if its full-screen is to find out the X window
[16:11] <asac> and then query the properties through an X call or something
[16:12] <andrew_sayers> I tried that with xwininfo, but it didn't seem to be reliable.
[16:14] <asac> andrew_sayers: unreliable in which way?
[16:18] <andrew_sayers> asac: I'm rechecking, but my memory was that it would report the wrong geometry at times.
[16:19] <asac> andrew_sayers: maybe there is a different property than geometry that indicates full screen?
[16:20] <asac> fta2: so how about punching en-US.xpi into -dev package too ;)
[16:21] <asac> currently it always gets eaten by launchpad ;)
[16:21] <asac> or do we need a special -data package for that?
[16:21] <fta2> eH?
[16:23] <fta2> lack of context
[16:24] <andrew_sayers> asac: Hmm, I think maybe npviewer.bin opens two windows, and you need some magic word to get the geometry for the second (fullscreen) one.  Assuming it takes some time to get this working right, what would be the best way to update you?
[16:24] <andrew_sayers> (Updates may be of the form "this patch would depend on x11-utils" :s)
[16:26] <asac> fta2: we export en-US.xpi for launchpad rosetta as  translation template (e.g. the lp-export...mk magic from mozilla-devscripts)
[16:26] <asac> fta2: however, this is not put in any package (only automagically uploaded on official builds)
[16:29] <fta2> asac, i remember now. it's only needed for the PPAs, right?
[16:30] <asac> its needed for those who want to do something with that xpi
[16:30] <jcastro> asac: playing email tag with gears folks, but I am close!
[16:30] <asac> you cannot even download it from launchpad unless you download the full trnaslation pack (which is 1G or something=
[16:35] <asac> jcastro: thx
[16:35] <asac> for doing this ;)
[16:39] <jcastro> no worries man, my job. :D
[16:39] <jcastro> fta2: the upstream chromium snapshot has working drag and drop for bookmarks, I was able to arrange my toolbar how I wanted and then move back to your build
[16:40] <andrew_sayers> asac: looks like the only way to detect fullscreen is by writing a bit of C, or by depending on a package like x11-utils/python-xlib.  Both fine by me, but probably a hassle for you :)
[16:40] <andrew_sayers> Also, do we want to think about playing a Youtube video in not-fullscreen?
[16:43] <fta2> jcastro, do you mean my build is not capable of doing it directly?
[17:06] <jcastro> fta2: this was last night, so I don't think so, but they have builds kicking off every few hours
[17:07] <fta2> jcastro, dailies are not enough for you? you want a continuous build? :) i guess the lp guys will kill me
[17:07] <fta2> and i'd need 1 TB of quota
[17:07] <jcastro> fta2: no I only needed it for that one feature, I'm good.
[17:08] <jcastro> once I got my bookmarks organized I went back to your build, but I suppose it will catch up today
[17:08] <fta2> most probably, tell me if it doesn't
[20:39] <gandi> asac: ping
[21:00] <fta> asac, ia32?
[22:23] <micahg> I found a rendering bug in FF3.5
[22:26] <BUGabundo> just one ?
[22:26] <BUGabundo> you aren't trying hard enough! stop slacking
[22:26] <BUGabundo> :))
[22:27] <micahg> BUGabundo: I've been using it for 4 months with almost no issues
[22:27] <BUGabundo> ahhh
[22:28] <BUGabundo> I stop using it 2 or 3 months ago
[22:28] <micahg> I was working on a project with a PNG that renders funny and was ready to blame it on my fglrx drivers
[22:28] <BUGabundo> now using 3.6
[22:28] <micahg> but someone suggested a browser issue
[22:28] <micahg> and lo and behold, it's fine in 3.0
[22:28] <BUGabundo> and 3.6 ?
[22:28] <micahg> don't know
[22:29] <BUGabundo> test it
[22:35] <micahg> I haven't installed 3.6
[22:35]  * micahg is installing it now
[22:38] <fta> gwibber's broken, again
[22:38] <BUGabundo> fta: ??
[22:38] <BUGabundo> working here
[22:38] <BUGabundo> let me restart it
[22:39] <fta> looks fine now
[22:39] <BUGabundo> https://wiki.ubuntu.com/BUGabundo
[22:39] <BUGabundo> hadhsg<hhd
[22:39] <BUGabundo>   Installed: 1.2.0~bzr340-0ubuntu1~daily1
[22:39] <fta> http://paste.ubuntu.com/193784/
[22:40] <BUGabundo> daily ?
[22:41] <fta> yep but it's fine now
[22:41] <micahg> BUGabundo: bug is in FF3.6 also
[22:43] <BUGabundo> micahg: upstream it !
[22:43] <micahg> yeah, I have to add it to LP first
[22:43] <micahg> then I can upstream it
[22:43] <BUGabundo> naaaa
[22:43] <BUGabundo> LOL
[22:53] <fta> hm, 6 crashes in cpyfakemstat64 (f=0xffddb6e4, st=0x0) at ../communicate.c:210
[22:53] <fta> the question is now why..
[22:55] <BUGabundo> on gwibber
[22:55] <BUGabundo> ?
[22:58] <fta> no, http://launchpadlibrarian.net/27765299/buildlog_ubuntu-karmic-i386.chromium-browser_3.0.188.0~svn20090610r18068-0ubuntu1~ucd1_FULLYBUILT.txt.gz
[22:59] <fta> trying to debug http://launchpadlibrarian.net/27761142/buildlog_ubuntu-karmic-i386.chromium-browser_3.0.188.0~svn20090610r18068-0ubuntu1~ucd1_FULLYBUILT.txt.gz
[22:59] <fta> (crash in libfakeroot-sysv.so)