[08:26] <dpm> morning all
[08:26] <dpm> let's see if the bugbot is working now...
[08:27] <dpm> bug 954223
[08:27] <dpm> nope
[08:42] <DJones> dpm: One was working yesterday morning - twobottux
[08:42] <DJones> It was amithkk's bot
[08:52] <dpm> it seems to be a bit sleepy now :)
[08:53] <DJones> I can put mine back in the channel if you want, after getting it working yesterday, I took it back out of the channel after realising that one was working
[08:53] <dpm> DJones, ah, yeah, that'd be cool
[08:54] <DJones> bug 954223
[08:54] <ukbot> Ubuntu bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:54] <twobottux> Ubuntu bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:54] <ukbot> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[08:54] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[08:54] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:54] <ukbot> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:54] <DJones> Argh
[08:55] <DJones> dpm: Can you try again
[08:55] <dpm> bug 954223
[08:55] <ukbot> Ubuntu bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:56] <twobottux> Ubuntu bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:56] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[08:56] <ukbot> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[08:56] <ukbot> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:56] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:56] <dpm> it seems both get triggered twice now
[08:56] <DJones> bug 954223
[08:57] <DJones> bug #954223
[08:57] <dpm> https://launchpad.net/bugs/954223
[08:57] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[08:57] <dpm> ah, that's what triggers it
[08:57] <DJones> Ubuntu bug 954223
[08:57] <twobottux> Ubuntu bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[08:58] <dpm> ah, it seems to be quite picky
[08:58] <dpm> so I guess kicking out twobottux and letting yours back in would work?
[08:58] <DJones> Looks like twobottux needs "Ubuntu bug" as the trigger, that seems to be the only difference
[08:58] <dpm> I'd rather just use the "bug ###" syntax
[08:59] <dpm> so do you think that'd be possible? I.e. kicking out twobottux and letting ukbot in?
[08:59] <DJones> I don't mind, whichever works, or maybe one of the recognised/official bots could be brought into the channel now
[09:00] <dpm> DJones, we'll get there eventually. We can't get the official ones in the channel right now, as the person controlling them seems to be on holiday
[09:00] <dpm> so could you help us doing that? ^
[09:01] <DJones> I've just asked the question anyway in one of the other channels, I think there were some changes to the bots yesterday that could mean an official one can be brought in now
[09:15] <dpm> ah, that'd be awesome
[09:22] <elky> yay!
[09:22] <elky> amithkk, you can take twobottux back now, thanks for the loan :)
[09:22] <Tm_T> two logbots?
[09:23] <elky> bug bots
[09:23] <elky> oh, and yes, 2 ubuntulogs
[09:23] <elky> that's clever...
[09:30] <dpm> bug 954223
[09:30] <ubottu> Launchpad bug 954223 in Ubuntu Translations "QT at-spi rolenames are not translatable" [High,Triaged] https://launchpad.net/bugs/954223
[09:30] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/954223
[09:30] <twobottux> Launchpad bug 954223 in qt-at-spi "QT at-spi rolenames are not translatable" [Undecided,Confirmed]
[09:31] <DJones> Maybe mute twobottux
[12:34] <kelemengabor> dpm: hi. do you have any idea why does LP not pick up existing translations in remmina? seb128 fixed the pot generation, but there is only a pot file in the queue: https://translations.launchpad.net/ubuntu/precise/+source/remmina/+imports
[12:34] <dpm> looking...
[12:49] <dpm> kelemengabor, ok, I've just built the package, and it seems it only generates a po file inside the remmina/po folder, and it ignores remmina-plugins/po.
[12:49] <dpm> err a *pot file, I meant
[12:49] <kelemengabor> dpm: sure, I'm already wrinting a comment on the bug about that
[12:49] <dpm> thanks kelemengabor
[12:49] <kelemengabor> but where are the po files?
[12:49] <kelemengabor> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/remmina/precise/files/head:/remmina/po/
[12:50] <kelemengabor> they are here... but not in the queue
[12:51] <dpm> yeah, there are in the translations tarball I've just built too, along with the template. Maybe because they are imported from the branch? Let's approve the template and find out
[12:52] <kelemengabor> I have approved it before asking :)
[12:52] <dpm> :)
[13:22] <kelemengabor> just for the record, there is no need for two remmina templates, it does not use them, only one
[13:23] <dpm> ah, strange
[13:23] <kelemengabor> upstream is buggy
[13:24] <dpm> yeah, I'm a bit worried that translations are set as open in upstream
[13:24] <kelemengabor> I just didn't assumed they would include something this buggy, so the problem cannot be with the upstream source... well, it can be :(
[13:24] <kelemengabor> dpm: hm, maybe then it is not such a big problem if we do not import them :D
[13:25] <dpm> lol
[13:40] <dpm> kelemengabor, it seems translations got imported now. Strangely enough, many are not complete in Ubuntu but they are upstream -> https://translations.launchpad.net/ubuntu/precise/+source/remmina/+pots/remmina
[13:40] <dpm> perhaps the upstream template was not up to date?
[13:41] <kelemengabor> dpm: in the sense that it was split in two, and now it contains everything, it wasn't
[13:43] <dpm> hm, not sure, the untranslated strings in Ubuntu's 'remmina' template are not in upstream's 'remmina-plugins' one
[13:44] <kelemengabor> yeah, there is some difference, upstream is 220+75 long, ours is 314
[13:44] <dpm> exactly
[14:32] <primes2h> Hi dpm! about bug #956797, I followed this instructions https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/RecipeVerifyingTranslationUploads. It ends up (on a temp dir) with a dir structure of this type: /usr/share/locale/$LOCALE/LC_MESSAGES/, but .mo inside are old (I guess they come from the last time the source package took them  from TP)
[14:32] <ubottu> Launchpad bug 956797 in binutils (Ubuntu) "Binutils templates translated but strings are in English" [Undecided,New] https://launchpad.net/bugs/956797
[14:32] <twobottux> Launchpad bug 956797 in binutils "Binutils templates translated but strings are in English" [Undecided,New]
[14:32] <twobottux> Launchpad bug 956797 in binutils "Binutils templates translated but strings are in English" [Undecided,New] https://launchpad.net/bugs/956797
[14:35] <dpm> hi primes2h. Yeah, it might be that the PO files which are used to create the .mo files during the build are old. However, that still does not explain why the shipped .mo files in the language packs are not being loaded.
[14:35] <primes2h> dpm: sure, where should I look for that in your opinion?
[14:38] <dpm> primes2h, you could use 'strace <program>' to see the open() syscalls. There you can see which .mo files are being opened (or trying to be) whenever the <program> is executed
[14:43] <dpm> e.g. to see the .mo files the 'man' command is loading:
[14:43] <dpm> strace man 2>&1 | grep open
[14:45] <dpm> looking at gold, from binutils, which is mentioned in the bug:
[14:45] <dpm> strace man 2>&1 | grep open
[14:46] <dpm> shows that it's not even trying to load an mo file
[14:46] <primes2h> dpm: here I am, sorry I was at the phone
[14:46] <primes2h> dpm: yes, tried with grprof and no .mo file opened
[14:49] <dpm> I'm not familiar with how binutils loads translations, but that seems to me like an upstream bug
[14:50] <jokerdino> amithkk: time to cull twobottux from this channel, there is ubottu working here :)
[15:05] <primes2h> dpm: Ok, so I'll open a bug upstream, thanks!
[20:33] <roadmr> Hello! I've a technical question, hope it's the right place to ask
[20:34] <roadmr> is it enough for an app to be translated if I add the strings to the .pot file? dpm said I needed to add the source files with the strings to POTFILES.in but due to them using Qt I'm not sure that would work too well :/
[20:49] <kelemengabor> roadmr: yes, good place to ask!
[20:50] <kelemengabor> let me start answering it...
[20:50] <roadmr> kelemengabor: hehe thanks :) so what do you think? is updating the .pot file enough? (I'm doing it via a standalone script that runs at build time)
[20:50]  * roadmr apologizes for jumping the gun
[20:51] <kelemengabor> no, please no standalone scripts... they make more trouble in the long term than they solve
[20:51] <kelemengabor> best would be to list everything translatable in POTFILES.in
[20:52] <kelemengabor> and during "make dist" time run intltool-update -p to generate a pot file
[20:53] <kelemengabor> and at package build time run dh_translations
[20:53] <kelemengabor> this latter is Ubuntu-specific
[20:54] <kelemengabor> to do this, you need to call dh --with translations in the debian/rules file
[20:54] <roadmr> kelemengabor: oh ok.. I think our build script (standard setup.py) and debian/rules already have most of this
[20:54] <kelemengabor> perfect :)
[20:54] <roadmr> kelemengabor: this is for checkbox (which you probably hate by now) :) we added a new qt-based frontend, and I'm trying to get the strings from the .cpp and .h files into the .pot file
[20:55] <kelemengabor> a setup.py with a build_i18n rule is all you need
[20:55] <roadmr> kelemengabor: I was copying the approach used by unity-2d
[20:56] <roadmr> kelemengabor: all our new strings are in .cpp or .h files, which I'm currently (in the script) extracting by using xgettext with some arcane parameters
[20:56] <kelemengabor> in many cases... however, there can be corner cases where the auto detection magic of setup.py is not enough, then it is best to keep a POTFILES.in file uptodate
[20:56] <kelemengabor> unity-2d, so we have arrived!
[20:57] <roadmr> kelemengabor: basically --qt -c++ --keyword=checkboxTr:1,2t --keyword=checkboxTr:1,2,4t (to extract strings from the checkboxTr functions)
[20:57] <kelemengabor> https://bugs.launchpad.net/ubuntu-translations/+bug/933468
[20:57] <ubottu> Launchpad bug 933468 in Ubuntu Translations "Translation template is not generated during the build" [Medium,Triaged]
[20:57] <twobottux> Launchpad bug 933468 in unity-2d "Translation template is not generated during the build" [High,Confirmed]
[20:57] <twobottux> Launchpad bug 933468 in unity-2d "Translation template is not generated during the build" [High,Confirmed] https://launchpad.net/bugs/933468
[20:58] <roadmr> kelemengabor: keeping the .cpp and .h files in the POTFILES.in is not a problem, I just need to tell intltool to extract the strings from calls to checkboxTr
[20:58] <kelemengabor> oh, there is a way to do that!
[20:58] <roadmr> kelemengabor: hey, then I'm glad I asked :) adding a task to that bug (or another bug) would have been bad :D
[20:58] <kelemengabor> basically, you need a Makevars file, like... let me look up an example
[20:59] <kelemengabor> indeed :)
[20:59] <roadmr> kelemengabor: awesome, thanks!
[20:59] <kelemengabor> so, the theory is this: http://www.gnu.org/software/gettext/manual/gettext.html#po_002fMakevars
[21:01] <kelemengabor> and it looks like this in action: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.2.0/files/head:/po/
[21:01] <roadmr> oh excellent!
[21:01] <kelemengabor> the interesting part is the XGETTEXT_OPTIONS variable
[21:03] <kelemengabor> you can put all the keywords into it, and in theory, the next setup.py build_i18n will detect those
[21:03] <roadmr> kelemengabor: hmm but if I specify my crazy parameters, will that apply to (and possibly break) extraction of strings from .py files?
[21:03] <kelemengabor> (but maybe it is better if I double check...)
[21:04] <kelemengabor> no, they shouldn't until you keep the keywords used in .py files around
[21:04] <kelemengabor> so to get back to the example, XGETTEXT_OPTIONS = --keyword=_ --keyword=N_ --keyword=g_dngettext:2,3
[21:05] <kelemengabor> when a gettextize script runs, it creates this Makevars file
[21:05] <kelemengabor> and it has the default values --keyword=_ --keyword=N_
[21:05] <kelemengabor> append your own crazyness to the end of this, and you should be good
[21:07] <roadmr> kelemengabor: oh OK, let's give it a try then
[21:08] <roadmr> kelemengabor: one more thing, I'd like to test that the string extraction part is working before doing a full package build, how can I simulate what gets run during package build? intltool-update -P?
[21:08] <kelemengabor> during package build dh_translations -v gets run
[21:08] <kelemengabor> I mean `dh_translations -v`
[21:08] <kelemengabor> at least it should :)
[21:12] <kelemengabor> (oh, I was wrong, it is not python-distutils-extra noticing the Makevars file, but intltool-update. but this should not affect the end result)
[21:12] <roadmr> oh ok, as long as it's farther down the chain it's OK :)
[21:14] <kelemengabor> so, is it better?
[21:15] <roadmr> kelemengabor: I'm still setting up the files to do a test run..
[21:15] <kelemengabor> ok
[21:15]  * kelemengabor starts to get sleepy
[21:15] <roadmr> kelemengabor: hehe sorry :)
[21:17] <roadmr> .. and then I messed up the location of the source files, ok, fixing..
[21:21] <roadmr> kelemengabor: I need to go, but I'll keep working on this, thanks so much for all your help!
[21:21] <roadmr> kelemengabor: maybe I'll pester you tomorrow if I can't get it to work :D
[21:21] <kelemengabor> you are welcome to do so :)
[21:22] <roadmr> thanks!
[21:51] <kelemengabor> note to self: tell roadmr about intltool-update -m