[00:00] thanks :) [00:18] bye [00:20] hm, looks like someone took care of libxcb-render-util0 [00:34] asac, https://edge.launchpad.net/~fta/+archive/staging please give it a try === asac_ is now known as asac [01:43] asac, ping? [01:48] NCommander: he's probably sleeping in Europe :) [01:49] micahg, asac sleeps? [01:49] :-) [01:50] :) [05:22] 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] Does anybody here know about fta's ppa-scripts? [06:27] I'm confused with this debian_tag stuff in get-orig-source [08:03] NCommander: back ;) [08:05] asac, wb, so thunderbird 3.0 works, now what? [08:09] NCommander: how well does it work? are there any performance issues in general? how long did you use it? [08:10] 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] k [08:12] i am not sure what to do next. investigating those crashes would probably be quite time consuming [08:19] asac, indeed ;-/ [08:19] 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] what will that do specifically? [08:20] 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] thats possible, but in this case its unlikely imo [08:21] let me check something [08:21] sure [08:23] http://paste.ubuntu.com/193271/ [08:23] apply that patch and build tbird. [08:24] after configure has run, abort the build and go to build-tree/mozilla [08:24] and run just "make" [08:24] once its finished you can start the debug build in dist/bin [08:24] ./thunderbird [08:25] start the debug build == start the application ;) [08:26] handy [08:26] ripps: DEBIAN_TAG=tag [08:27] asac: huh? [08:27] ripps: you said you were confused by debian_tag stuff ;) [08:27] what in particular ;) [08:27] ? [08:28] 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] ripps: git has the concept of tags, right? [08:30] so i guess thats not your problem ;) [08:30] what confuses you in particular? [08:30] asac: No, it understand that, git tag show a list of release names [08:31] 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] 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] 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] ripps: ah. yeah. i am not sure if there is a way to query log and stuff on remote branches [08:32] ripps: DEBIAN_TAG is only used to get certain releases [08:32] His examples all use bzr, which makes infinately more frustrated to convert to git [08:33] ripps: DEBIAN_DATE= is used to get certain date snapshots [08:33] ripps: well. all the mozilla stuf we are running is using mercurial [08:33] actually i think we only have one project that is all bzr, e.g. gwibber [08:34] ripps: or are you saying that your debian/ stuff is in git too? [08:34] 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] asac: I [08:34] I've setup a branch for my debian stuff [08:34] Let me show you what I've got so far. [08:35] * asac has to get a coffee first now [08:36] https://code.edge.launchpad.net/~gmpc-trunk/+junk/gmpc.trunk [08:40] ifneq (,$(DEBIAN_TAG)) [08:40] get-orig-source: TAG = $(NULL) [08:40] isnt that wrong? [08:40] why is TAG unset if there is no DEBIAN_TAG? [08:41] also ... is get-orig-source: TAG = $(NULL) valid make code at all? [08:41] asac, building [08:41] * asac continues to produce coffee ;) [08:41] Probably will take quite a few hours [08:41] NCommander: great [08:41] * NCommander will need coffee soonish [08:42] asac: I just copied what he had in the gwibber.head code [08:45] asac: okay, what is TAG supposed to be? The release version, the git date, or git version? [08:46] Do I set it early on, like is shows here, or should I do after I've cloned a branch from git? [08:47] ripps: well. i used git a bit and i didnt find a way to do anything without first cloning [08:48] so i guess if upstream has git it needs to clone first ;) [08:48] So I should put this TAG stuff in gos-co: [08:50] 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] He then bumps it up 0.18.95 when it's in beta [08:51] ripps: i am not sure, but i would think you need to do the following: [08:51] get-orig-source: TAG = -r $(shell bzr log --limit 1 $(GWIBBER_URL) | grep ^r | head -1 | cut -d' ' -f2) [08:51] -> make this line not use bzr log [08:51] i think fta uses wget and sedding to get that info for things that dont support remote "log" [08:52] at least thats one option [08:52] the other option is to depend on the gos-all thing first [08:52] and then use git log locally to get that info [08:52] 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] ...hmmm all I want is to have the packages built with gmpc-git$DATE.$REVISION-0ubuntu1 [08:54] ripps: so does anything work at all atm? [08:54] i think in general you are on the right track [08:55] you just miss corner cases [08:55] and have syntax errors i would think (like three get-orig-source: rules... which probably make the stuff fail) [08:55] 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] ripps: whats the difference to what you have now? [08:57] asac, I think you got that patch backwards [08:58] NCommander: thought its already building ;)? [08:58] 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] (could be that i made the diff in wrong order) [08:58] (or edited the .orig )) [08:58] (its early) [08:58] asac, as in; apt-get source thunderbird :-P [08:58] heh [08:59] NCommander: http://paste.ubuntu.com/193286/ ;) [08:59] better? [09:01] yup ;-) [09:01] ripps: ok. so revision 7 looks rather incomplete (e.g. no DEBIAN_TAG etc. at all) [09:02] so, for $VERSION I should get today's date, or should I get the date of the last commit? [09:03] ripps: version is either a) the explicit version passed to DEBIAN_TAG (e.g. DEBIAN_TAG=COMMITID=EXPLICITVERSION) [09:04] or b) the date of the topmost commit + the short commit id i guess (e.g. DATE.commitid) [09:05] 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] (instead of topmost commit) [09:06] ripps: makes any sense to you? [09:06] 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] ripps: yeah. the problem is that bzr revision number always increase ... problem is that this is not true with git commit ids [09:07] ... okay, there are too many varibles with similar meanings going on... hold on, brb [09:07] so you need to prefix the version with date [09:07] or something else that spans a strict order [09:07] ripps: i think you can forget about almost everything that is done with gwibber because it doesnt match for git [09:08] 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] the only thing you have to invent is how to guess a good version out of it [09:08] i suggest that you always use the date of whatever commit you are using and append the short commit id [09:09] actually i wanted to test his script for my networkmanager/connman stuff [09:09] i face the same problem there ;) [09:34] asac: hi. I was giving your updated couchdb package some testing [09:35] 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] after fixing that, I still ran into some failures in the couchdb test suite [09:37] 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] jamesh: what as in LD_LIBRARY_PATH ? [09:42] "because the xulrunner directory was after /usr/lib" ... dont understand what you mean here [09:43] LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/xulrunner-`xulrunner --gre-version`/ [09:43] thats wrong? [09:43] asac: so, the couchdb script was running the erlang VM with "env LD_LIBRARY_PATH=/usr/lib:${LD_LIBRARY_PATH} erl ..." [09:43] that crack came from icu-config.patch [09:44] 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] ok [09:45] jamesh: so i forgot to update some script? [09:45] where is this erlang thing run? [09:45] 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] asac: this was in /usr/bin/couchdb -- one of the files you patched [09:46] search for "command=" [09:46] jamesh: ah ok. so the problem is that libmozjs0 is installed [09:46] ok fixing the order should help [09:47] e.g. export LD_LIBRARY_PATH=/usr/lib/xulrunner-`xulrunner --gre-version`... [09:47] 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] jamesh: why the hell are they adding /usr/lib to LD_LIBRARY_PATH at all? [09:47] jamesh: isnt the testsuite run during build? [09:48] asac: the test suite is run from within a web browser :( [09:48] yeah. thats why i asked you to look, because i have absolutely no clue on couchdb ;) [09:48] good [09:48] so how do i run this thing? [09:49] go to the URL I listed above, click the "test suite" link, then click "run all" [09:49] asac: the unpatched version of the couchdb script runs "icu-config --invoke erl ..." [09:49] that is intended to make sure it runs in an environment that can find the ICU libraries [09:50] jamesh: which test fails? [09:50] only thing that fails is "stats" test [09:50] # 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] as the Debian packager didn't want to depend on libicu-dev, he inlined what it did [09:50] does that match your observation? [09:51] asac: I got failures in a number of the tests before that one, so it might be a local problem then. [09:51] jamesh: uninstall libmozjs0 and libxul0d [09:51] those might hurt [09:53] i just used the package without changing anything else (e.g. no further hacks to LD_LIBRARY_PATH etc) [09:55] I don't have libxul0d installed, and had moved the libmozjs libraries out of the way [09:55] hmm. i have that installed. let me check [09:57] ok after uninstalling libmozjs0d package and restarting couchdb i still get the same results [09:57] one test fails: stats [09:58] not sure then. would need to see more details. i would however, think that its unlikely that it doesnt work in jaunty [09:58] its the same libmozjs [09:58] I'm also getting an error at http://localhost:5984/_config [09:58] i get that too i think [09:58] {"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] thtat's not an error [09:58] ah [09:58] ;) [09:59] so, it seems like things are mostly working for you, which is good. [09:59] I might try rebuilding through my PPA to see if I get a different result [09:59] 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] or give me details on the errors you get on the testcases ;) [10:00] though i doubt that they will mean anything to me ;) [10:03] jamesh: could be that you had libmozjs-dev installed next to xulrunner-dev while building [10:04] that could be it [10:05] jamesh: ok uploaded a jaunty backport to https://edge.launchpad.net/~asac/+archive/sandbox ... will take 30 minutes i would hope [10:07] why * Change erlang-nox dependency to erlang-inets. [10:07] asac: I'm actually testing against a couple of other custom packages, so I'll use the build from my PPA [10:07] ? [10:08] 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] k [10:08] in karmic it has been split up into smaller packages with erlang-nox existing to satisfy dependencies [10:09] depending on erlang-nox brings in a corba implementation, asn1 parser, distributed database, etc [10:09] ok deleted the build in my sandbox [10:10] not the kind of thing you want when trying to squeeze couchdb onto the install CD :) [10:15] 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] as long as you are sure that all commands get the proper LD_LIBRARY_PATH now thats probably fine ;) [10:18] for me it was easier just to set it on top of the script [10:19] anyway. i would think for now that you built it while having libmozjs-dev installed or something [10:19] unless you always used ppa to build (in which case i wouldnt know) [10:20] ripps: fta: thanks [10:21] i would think the main problem is to agree on a good versioning scheme for git. [10:21] i already packaged something using git, hold on [10:21] fta: i saw that we have mobile-browser.git in mozclient [10:21] not sure if that would work out of box [10:21] Okay, libmpd seems to be working, but now I think it's failing when it starts gmpc... something about no push location [10:22] mozclient is not the easiest to start with.. [10:22] (besides from the fact that moblin replaced the repo with something completely different) [10:22] yeah [10:22] i figured that and would prefer not to use that for NM/connman [10:23] https://code.edge.launchpad.net/~fta/+junk/yui3.head [10:23] yui3 uses git [10:24] no revs yet ;) [10:24] lp is slow ;) [10:25] * asac still waiting ;) [10:26] well, http://paste.ubuntu.com/193333/ [10:26] 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] fta: are you sure that date in the git log will always move ahead? [10:27] e.g. if i merge a branch things get committed on top, but i think they still use the same date [10:28] good question. i guess you have to figure that out yourself based on the old commits [10:30] asac: okay. Looks like the problems were my fault. [10:30] ripps, to the user account from dput [10:30] jamesh: what did you do ;)? [10:30] asac: turned on debugging, and it looks like there was another undeclared dependency [10:31] ah. so missing erlang pieces? [10:31] needed to install erlang-xmerl [10:31] yeah [10:31] fta: what does that have do with bzr? bzr is getting a cannot push error [10:31] good. i always knew that shlibs is a great invention ;) [10:31] Actually, it's not getting to the dput step... [10:32] ripps, show me [10:32] ripps: in the docs it say that it will auto push daily bumps [10:32] error reporting does not seem to be one of Erlang's strong points [10:32] ripps: its important that the branch already has a push location for that [10:32] I've been spoiled by Python [10:32] (at best use a different location) [10:32] hope i didnt talk non-sense now ;) [10:32] jamesh: sorry to hear that you need to work with erlang ;) [10:33] must be a special experience ;) [10:33] asac, ripps: no need to already have a predefined location if you're using the conf files [10:34] at least I don't have to hack mozilla :) [10:34] ah [10:34] jamesh: 1:0 for you ;) [10:35] fta: at least the karmic kernel tree seems to move strictly ahead http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git [10:40] 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] fta: here's the output I've got. http://paste.ubuntu.com/193337/ [10:41] i have to run now. will you still be there in an hour or 2? [10:41] fta: and here's my confs. http://paste.ubuntu.com/193339/ [10:41] I'll probably be around [10:42] ripps, what was your cmd? update or daily? [10:42] fta: I just ran ./daily.sh gmpc [10:43] 04:35:28 -0500 woww, it's early for you.. or really late [10:44] fta: I'm on a night schedule, [10:44] oh :) [10:44] So, probably late [10:47] i'm late, i'll get back to you asap [11:48] back [11:49] ripps, still there? [11:49] fta2: yo [11:49] I still can't figure out why it cant push before dput [11:50] 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] (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] ./daily.sh pocket 2>&1 | pastebinit :) [11:58] fta2: http://paste.ubuntu.com/193376/ [12:01] ok, i see. i can't parse your ~/.dput.cf. could please paste it ? [12:02] omg, i put stage instead of staging [12:02] * ripps hits himself repeatedly [12:04] lol [12:05] * fta2 makes a mental note to add an error message there [12:06] asac, did you try it? [12:19] fta2: your scripts? nope. quite happy that ripps jumped the first gun for now [12:19] ;) [12:19] 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] (and gnash, but thats all bzr, so probably easy) [12:20] I forgot to install bzr-builddeb, but otherwise, things look much better than before. It didnt' dput though [12:22] (for me: http://paste.ubuntu.com/193382/) [12:24] hmm ... not sure if KMS is really a good thing. monitor blinks every other minute ;) [12:32] * asac out for a bit [12:39] 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] But now, it's uploading via dput [12:50] ripps: so all is working now? [12:51] asac: https://edge.launchpad.net/~ripps818/+archive/staging [12:51] can you suggest changes to the README ... or would it be better to reference documented examples for git etc. [12:51] a couple packages say failed, but their just in depwait for libmpd to finish [12:52] k [12:52] ripps: so you are doing libmpd and gmpc as dailies? [12:52] 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] https://code.edge.launchpad.net/~gmpc-trunk [12:53] ripps: sure. just wondered if you would be willing to suggest improvements to the README based on your experiences [12:53] asac: that's the plan, but I plan on expanding it to gmpc-plugins, mpd, mpc, and mpdscribble [12:53] ripps: so does the daily script bump the lower version on the build depends automatically? [12:54] asac: well, seeing as alot of glitches came from not having dput line setup correctly... [12:54] or is that something we do in a special way for firefox/xulrunner [12:54] ripps: ok. [12:54] 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] asac: debian_tag was completely foreign concept to me when I started, but now I get it (I think) [12:56] ripps: do you think there are better ways to achieve this? [12:57] 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] well. lets see. [12:57] i think for simple projects it might really happen soon. but the more complex ones somewhat bother me [13:02] 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] yeah. we will see ;) [13:03] i dont see this coming in the next 6 month for mercurial upstreams ;) [13:03] do you have the blueprint? [13:03] (URL) [13:08] asac: https://wiki.ubuntu.com/DailyUpstreamBuildsPOCSpec [13:10] goo that its me and fta used to outline this ;) [13:10] hehe [13:11] blocker is somewhat to get a lp:firefox branch i guess [13:12] done well if by karmic's release there are 4-500 packages maintained [13:12] meaning really 4-500 ? or rather 400-500? [13:12] fta2: ? [13:13] i assume the latter [13:14] 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] Mark said 400-500 [13:15] ripps: what size does the gmpc project have? (e.g. including .git directory) [13:15] ripps, yep, you need a local branch ;) [13:15] It's probably about 20 megs for the entire branch... [13:15] ripps, glad to see it worked at the end ;) [13:16] 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] couldn't be worse than chromium [13:18] 14:17 < asac> james_w: so where can i find your latest daily build tools? [13:18] 14:17 < james_w> asac: bzr-builder on launchpad [13:20] 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] yeah. makes sense ... somewhat [13:22] ripps, http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/rules#L253 nightmarish get-orig-source [13:22] it's all svn though [13:28] 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] i initially wanted that too, but i gave up. it's better to just link to the upstream vcs browser [13:39] asac, did you test my last ia32-lib [13:43] fta2: well. the last i tried missed those libs remember? [13:43] didnt know there was an update afterwards [13:43] i can do that though [13:47] Jun 11 01:34:45 asac, https://edge.launchpad.net/~fta/+archive/staging please give it a try [13:50] fta2: do you know how to do an if-then statement to check if a directroy exists in debian/rules? [13:51] globally or in a rule? [13:52] 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] it's in gos-co [13:53] you can do it in shell [13:53] like this http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/rules#L297 [13:54] just put a @ in front of it? [13:54] minus the echos.. i like my logs to be verbose. it helps the troubleshooting [13:55] no, the @ is to hide the command [13:55] the important part is the \ at the end of each line [13:56] so for make, it's a single line [14:10] fta2: what's the proper way to use the 'upstream' option in ppabot-pkg.conf? [14:11] what do you mean by proper way? ;) [14:12] it's just a directory that you can pass to your get-orig-source [14:12] so you just have to create it or update it [14:13] fta2: do you have any examples of get-orig-source using it? [14:13] chromium [14:14] look for LOCAL_BRANCH [14:15] firefox too but it's hidden into mozilla-devscripts / mozclient [14:15] i have no simpler example i'm afraid [14:18] 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] brb [14:26] so if i have a file with [14:26] line1 [14:26] line2 [14:26] line3 [14:26] line4 [14:26] and want to reverse it to [14:26] line4 [14:26] line2 [14:26] line3 [14:26] line4 [14:26] there seems to be no common unix command for that? [14:26] what the heck? [14:26] rev does the wrong thing [14:26] tail -r doesnt exist on linux [14:26] what am i missing? [14:27] why does rev exist, but no rev-lines [14:27] e.g. whats the so much more important use case for rev? [14:31] ha. i found tac ;) [14:32] ? [14:48] anyone here has contact with the mozilla translation team? [14:48] Seth has not answered for over a month [14:49] and I am starting to wonder if I may just contact someone else [14:49] I need a translation to get in 3.5 [14:49] (swahili-TZ) [14:49] huayra: Seth? [14:49] from mozilla [14:49] huayra: do you have the translation done? [14:49] yeah [14:49] huayra: did you open a bug? which id? [14:50] I have been tracking the mozilla code to keep it up to date [14:50] let me give you the nr [14:51] https://bugzilla.mozilla.org/show_bug.cgi?id=293722 [14:51] Mozilla bug 293722 in Registration & Management "[sw-TZ] Swahili: Firefox" [Normal,Resolved: incomplete] [14:51] https://bugzilla.mozilla.org/show_bug.cgi?id=300754#c40 [14:51] https://bugzilla.mozilla.org/show_bug.cgi?id=300754 [14:52] Mozilla bug 300754 in Registration & Management "[sw-TZ] Kiswahili Firefox localization (Kilinux Team)" [Normal,Assigned] [14:54] huayra: how did you try to reach him? [14:55] zbraniecki: ^^ [14:55] yo [14:55] hi! ;) [14:55] hi asac :) [14:55] how can I help you? [14:55] asac, so thunderbird FTBFSed ... [14:56] zbraniecki: seems huayra needs some help on getting his translation process started (read the last 10 lines or so) [14:56] 15:48 < huayra> Seth has not answered for over a month [14:56] yea, it'll be a nice concept to poke him on this [14:57] zbraniecki: maybe you can give him some guidance? [14:57] asac: I'm involved in the process [14:57] zbraniecki: err. sorry. i think its not about launchpad export. just a plain translation contribution ;) [14:57] it's a little bit complex case [14:57] oh so sw-TZ is complex itself? [14:57] how that? [14:57] since we received multiple localizations which are heavily different [14:58] hmm [14:58] and need to ensure we do the right thing [14:58]