[00:00] <bdrung> asac___: what was the command for sign-off/releasing?
[00:00] <asac___> fta: the bug sounds ...
[00:01] <asac___> fta: so yeah. when i am back from holiday i will try to get that in
[00:01] <fta> asac___, "No, Debian's fine. This is only in Ubuntu."
[00:01] <asac___> fta: run-mailcap.diff comes from debian
[00:01] <asac___> whether they are fine or not is nothing i said ;)
[00:01] <fta> it's the last comment in the bug
[00:02] <fta> http://code.google.com/p/chromium/issues/detail?id=19987
[00:03] <fta> asac___, ^^ we have a sync from debian so i don't understand
[00:03] <asac___> yes
[00:04] <asac___> commented
=== asac___ is now known as asac
[00:10] <asac> fta: anyway. i think the xdg-mime > mailcup-run > BROWSER approach is something worth considering; one would have to do some research though how that is behaving in non DE environments etc.
[00:10] <asac> but most likely its just the right approach to do both
[00:17] <fta> ok
[00:18] <bdrung> asac: https://code.launchpad.net/~bdrung/mozilla-devscripts/version-0.15/+merge/10558
[00:18] <bdrung> asac: i removed the 0.15 tag
=== Grantbow_ is now known as Grantbow
[00:22] <fta> asac, isn't "foo Depends bar (= ${binary:Version})" enough to make sure that foo and bar are always in sync? (foo is arch, bar is all-arch)
[00:29] <fta> hm, if amd64 is built 1st, a user can upgrade the browser without the lang packs still waiting for the i386 build to complete.. i should add a conflict there
[00:35] <bdrung> asac: also uploaded to mentors: http://mentors.debian.net/debian/pool/main/m/mozilla-devscripts/mozilla-devscripts_0.15.dsc
[00:49] <asac> fta: i think thats not always the case
[00:49] <asac> think about you depending on a arch all package from a any package
[00:49] <asac> and you do a binary NMU ... the arch package would not be updated most likely
[00:50] <asac> bdrung: so pull does not work ;)
[00:51] <asac> let me try to branch locally first ;)
[00:51] <bdrung> pull does not work?
[00:52] <asac> not in a bound branch
[00:52] <asac> i did pull --local now
[00:52] <asac> launchpad seems to be problematic ;)
[00:52] <asac> now trying to push ;)
[00:52] <asac> ok that worked
[00:53] <asac> maybe bzr now opens concurrent connections when pulling multiple revisions into a bound branch
=== rickspencer3 is now known as rickspencer3-afk
[00:57] <fta> asac, bin nmu, looks like debian to me
[00:58] <asac> yes
[00:58] <asac> but we use the same techniques in most cases
[00:58] <asac> at lesat if someone ask: "is this enough ..." ;)
[00:58] <fta> http://code.google.com/p/chromium/issues/detail?id=19694
[00:59] <fta> i have: chromium-browser-l10n depends on chromium-browser (= ${binary:Version})
[01:00] <asac> bdrung: uploaded
[01:00] <fta> even if the bug doesn't look ubuntu to me, i realize now I have a race, so i need a conflict, or a break in chromium-browser
[01:00] <fta> or something
[01:00] <bdrung> thanks
[01:01] <fta> (imho, you're releasing m-d too fast)
[01:01] <asac> fta: i wanted to get this up before holiday ;)
[01:01] <asac> ... also ... release fast and often ;)
[01:02] <asac> and both debian and ubuntu ard not yet approaching release ;)
[01:02] <micahg> asac: I introduced myself to the Developers :)
[01:02] <asac> hehe
[01:03] <asac> micahg: seems they like you ;)
[01:04] <fta> asac, so?
[01:04] <micahg> asac: I think I can reproduce the bug in Jaunty
[01:04] <micahg> at least part of it
[01:04] <asac> good
[01:04] <asac> so we can rule that out
[01:05] <asac> fta: on what?
[01:05] <asac> the depends?
[01:05] <fta> yes
[01:05] <fta> http://paste.ubuntu.com/257233/ that's today
[01:05] <fta> it seems to me -l10n could be out of sync
[01:06] <asac> fta: what do you think is the problem of the bug?
[01:06] <asac> the packages not being forced to the right version?
[01:06] <fta> the l10n not from the same build as the browser
[01:06] <asac> ok you think they could be. let me see
[01:08] <asac> fta: is anything run during post/pre scripts?
[01:08] <asac> some l10n processing/compilation maybe or so?
[01:08] <fta> no
[01:09] <asac> then the depends should be enough imo
[01:09] <fta> what if the amd/lpia builds are done 1st, and a user upgrade?
[01:09] <asac> fta: maybe its unclear how to grab the right sources? so you dont have the right translations in the source?
[01:10] <fta> no, the l10n files (which are in fact .grd files) are generated during the build
[01:10] <asac> were from?
[01:10] <asac> are the translations in the same directory as the code that uses them?
[01:10] <fta> yes
[01:10] <asac> really?
[01:11] <asac> so i have main.c
[01:11] <asac> and then i have main.c.grd ?
[01:11] <fta> no
[01:11] <asac> and then i have main.c.grd.fr .en .es ;) ?
[01:11] <asac> yeah
[01:11] <fta> eg http://src.chromium.org/svn/trunk/src/chrome/app/resources/locale_settings.grd
[01:12] <asac> <output filename="locale_settings_ar.rc" type="rc_all" lang="ar" />
[01:12] <fta> or http://src.chromium.org/svn/trunk/src/chrome/browser/browser_resources.grd
[01:12] <asac> where is the input file?
[01:12] <asac> there are no translated strings either
[01:13] <asac> hmm there seem to be <message elements
[01:13] <asac> but those dont look like the translations
[01:13] <asac> rather like the "default/fallback"
[01:13] <asac> fta: i wouldnt add the breaks t the l10n package
[01:14] <asac> the depends alone should prevent it from upgrading chrome-browser without removing -l10n
[01:14] <fta> http://src.chromium.org/svn/trunk/src/chrome/app/resources/google_chrome_strings_de.xtb
[01:15] <asac> ok
[01:15] <asac> i dont know. in worst case its a bug in lzma ;)
[01:15] <asac> lol
[01:15] <asac> or the sources were really not in
[01:15] <asac> sync
[01:16] <asac> Breaks: chromium-browser (<< 3.0.197.0~svn20090804r22432)
[01:16] <asac> Replaces: chromium-browser
[01:16] <asac> do you need this unversioned replaces?
[01:17] <fta> hm, it was when i split the package
[01:17] <asac> yeah since you maintain everything from same branch you can just make it versioned
[01:17] <asac> << WHATEVERVERSIONYOUDIDTHEMIGRATION
[01:18] <asac> anyway. i would hope thats not the problem (though you should consider it)
[01:18] <fta> so the same as the breaks
[01:18] <asac> so i would triple check that the sources i used are really what they expect them to be and ask the submitter to submit information about package verions etc.
[01:19] <fta> eh?
[01:19] <asac> how sure are you that the strings that are wrong for the french guy were/are really right in the sources?
[01:19] <asac> identifying how those are different might help
[01:19] <asac> if they are really daily changes then it might be a pointer to investigate further ;)
[01:20] <fta> he pasted rpm with 2 different versions
[01:20] <fta> the rpm seems to be repacks from my debs
[01:20] <fta> -s
[01:20] <asac> yeah so an eventual version diff because of arch all/any can be ruled out
[01:20] <asac> which probably mean that the packaging is maybe missing some pieces?
[01:21] <asac> fta: try to force the same dailies
[01:21] <asac> and see if it works
[01:21] <asac> if thats the case then its upstream out-of-sync issue
[01:21] <asac> which i would think is a likely thing for dailies from trunk ;)
[01:21] <asac> but i dont know upstream translation polices ... nor do i see from the bug how many strings are wrong
[01:21] <fta> i never experienced this bug myself, i was just trying to figure out if it can happen
[01:22] <asac> great. i cannot open pngs directly there
[01:23] <asac> fta: what does the text mean that is in lowest thign?
[01:23] <asac> that seems to explode the window
[01:23] <asac> that big button (greyed out)
[01:24] <asac> avez choisi d'ouvrir automatiquement certain types de fichier ...
[01:24] <asac> how is "Desktop" called on french desktops?
[01:24] <asac> if you install it as french from scratch i mean
[01:25] <asac> do we translate that=
[01:25] <asac> hmm. they use Download ;)
[01:25] <asac> but still ... maybe it has something to do with how the french dir name is named
[01:27] <fta> Desktop is Bureau in french
[01:28] <fta> from what i understand, the guy said langpack generated with one build are not usable in another build
[01:29] <fta> but no idea if that's correct
[01:29] <asac> fta: what do they produce?
[01:29] <asac> can you check if you can find this overly long string somewhere?
[01:30] <asac> i doubt that its in the source
[01:30] <fta> $ file /usr/lib/chromium-browser/locales/fr.pak
[01:30] <fta> /usr/lib/chromium-browser/locales/fr.pak: data
[01:30] <asac> looks like a mixup
[01:30] <fta> comment 4 shows:
[01:30] <fta> $ rpm -q chromium-browser chromium-browser-l10n
[01:30] <fta> chromium-browser-4.0.203.0~svn20090818r23670-1.i386
[01:30] <fta> chromium-browser-l10n-4.0.202.0~svn20090813r23308-1.noarch
[01:31] <fta> so it's not the same upstream version
[01:31] <fta> i have no difficulty to understand that it may give bad results
[01:31] <asac> yes
[01:31] <asac> it obviously doesnt break if strings are still ok
[01:32] <asac> question is if out of sync translations often break it
[01:32] <fta> in #10, he said "OK, it's OK if both program & l10n data are synced, aka the same SVN rev."
[01:32] <asac> i would hope not
[01:32] <asac> otherwise they are doing something wrong
[01:32] <asac> everything worse than gettext would be a step back
[01:32] <fta> he's doing weird stuff with the package, not our problem, but could we have the same situation with the PPA?
[01:32] <asac> fta: i really think you should just verify this reall ylong string. maybe its easy to see once you see how and wher that is typed ;)
[01:33] <asac> fta: no
[01:33] <asac> we are synched
[01:33] <asac> the depends should be enough imo
[01:33] <asac> you need conflicts/replaces only to transition stuff
[01:34] <fta> $ find . -print0 | xargs -0 grep 'ouvrir automatiquement certains types'
[01:34] <fta> ./src/chrome/app/resources/generated_resources_fr.xtb:<translation id="724208122063442954">Vous avez choisi d'ouvrir automatiquement certains types de fichiers après leur téléchargement. Vous pouvez changer ces paramètres afin que les fichiers téléchargés ne s'ouvrent pas automatiquement.</translation>
[01:34] <asac> yeah
[01:35] <asac> so question is where that is coming from
[01:35] <asac> check the template used
[01:35] <fta> $ find . -print0 | xargs -0 grep 724208122063442954 | pastebinit
[01:35] <fta> http://paste.ubuntu.com/257247/
[01:35] <asac> yeah
[01:35] <asac> fta: whats the english text for that?
[01:35] <asac> in the source?
[01:35] <asac> oh those are generated
[01:35] <asac> is there a similar entry in source?
[01:36] <fta> this is from a tarball, not from a build
[01:36] <asac> ok and the english id?
[01:37] <asac> thats not english ;)
[01:37] <asac> oops
[01:37] <asac> i scrolled up ;)
[01:38] <fta>       <message name="IDS_OPTIONS_AUTOOPENFILETYPES_INFO" desc="The information label for the 'Reset always open files' button">
[01:38] <fta>         You have chosen to open certain file types automatically after downloading. You can clear these settings so that downloaded files don't open automatically.
[01:38] <fta>       </message>
[01:39] <asac> yeah. but somehoe the english text in teh screenshot is a different string
[01:39] <asac> so the ids have a mismatch
[01:39] <asac> means: they are out of sync in the tree i guess
[01:39] <asac> i guess the real string is a few before or after ;)
[01:40] <fta> those 724208122063442954 numbers are coming from somewhere, but no idea from where
[01:40] <asac> where is IDS_OPTIONS_AUTOOPENFILETYPES_INFO mapped to 724208122063442954
[01:40] <asac> fta: i guess they make up  a number by a scheme or something
[01:40] <asac> check whatelse is in the proximity of IDS_OPTIONS_AUTOOPENFILETYPES_INFO
[01:40] <asac> or find the string you see in the english screenshot
[01:41] <asac> the IDS_OPTIONS_AUTOOPENFILETYPES_INFO is probably in the proximity there
[01:41] <fta> http://codereview.chromium.org/165209
[01:41] <asac> there is not the file i care most
[01:41] <asac> the one where the IDS_OPTIONS_AUTOOPENFILETYPES_INFO was in
[01:42] <asac>  (Patch set is too large to download)
[01:42] <asac> i dont see that file
[01:42] <asac> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/resources/
[01:42] <asac> its not there
[01:43] <asac> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chromium_strings.grd?view=markup
[01:43] <asac> okm
[01:43] <asac> <message name="IDS_OPTIONS_DOWNLOADLOCATION_ASKFORSAVELOCATION" desc="The 'Ask for save location before downloading' checkbox label">
[01:43] <asac>         Ask where to save each file before downloading
[01:43] <asac>       </message>
[01:43] <asac>       <message name="IDS_OPTIONS_AUTOOPENFILETYPES_INFO" desc="The inform
[01:44] <asac> isnt the one above the one that is in the dialog in english?
[01:44] <asac> ok not
[01:46] <asac> IDS_FR_CUSTOMIZE_DEFAULT_BROWSER
[01:46] <asac> so yesw
[01:46] <asac> cant say more
[01:46] <asac> execpt that its a out of sync ID
[01:46] <asac> maybe its because chrome_strings and chromium_strings are out of date?
[01:46] <asac> out of sync
[01:47] <asac> with some luck its fixed next time they sync locales ;))
[01:47] <fta> http://paste.ubuntu.com/257255/
[01:47] <fta> ?
[01:47] <asac> should be ok
[01:48] <asac> i dont think you need the breaks because of the depends
[01:48] <asac> buit tahts in the past anyway
[01:48] <asac> i would drop those things if nothing was ever released to real archives
[01:48] <asac> at least after a while
[01:52] <fta> hm
[02:28] <fta> jcastro, lol, a browser popcon ;) the comments were not at all what you expected, i guess
[02:29] <jcastro> heh
[02:31] <fta> jcastro, i think what he meant at the beginning is that as PPAs are not mirrored, someone from lp/cannonical should have the real numbers, just grep the logs
[02:31] <jcastro> yeah but I don't
[02:31] <fta> i's sure want to know too ;)
[02:31] <fta> 'd
[02:38] <fta> bug 139855
[02:38] <ubottu> Launchpad bug 139855 in soyuz "Display stats about PPA usage" [Low,Triaged] https://launchpad.net/bugs/139855
[09:19] <andv> good morning asac
[09:19] <andv> you disappeared yesterday evening :)
[10:50] <BUGabundo> does mozilla fennec run on android?
[17:15] <BUGabundo> asac: ping
[17:15] <BUGabundo> tell me you are around :)
[18:50] <fta> hi
[18:50] <BUGabundo> ola fta
[18:51] <fta> BUGabundo, he's on holidays for a week
[18:51] <BUGabundo> bahhhhh
[18:52] <BUGabundo> who is going to help me now :(
[18:52] <fta> good time to learn by yourself :)
[18:52] <fta> like we do ;)
[18:53] <fta> fennec on android, no way, unless android now allows native apps
[18:53] <BUGabundo> fta: took me *one* year to figure that NM could _easily_ share a connection, to find out today, I can't make it work out of the box on a jaunty livecd :(
[18:53] <BUGabundo> fta: it doesn't
[18:54] <BUGabundo> but I read on the ML (thanks to google)
[18:54] <BUGabundo> that someone is porting it to the SDK
[18:54] <fta> then it's a full rewrite, not a port
[18:54] <BUGabundo> I really would appreciate if you could ping me.... I loose all your replies :)
[18:55] <fta> grrr, use a real irc client
[18:58] <BUGabundo> for what?
[18:58] <BUGabundo> I can very easily read all the channel blober
[18:58] <BUGabundo> I just get a faster notification if you, fta, nick me :)
[18:59] <BUGabundo> don't want, don't do it
[18:59] <BUGabundo> be FREE
[19:00] <fta> BUGabundo, it's just not natural to me once a discussion has started, and there's no interference
[19:00] <BUGabundo> ok ok
[22:17] <bdrung_> Jazzva_: how about guessing the files for MOZ_XPI_DOCUMENTED_LICENSE_FILES if this variable is not set?
[23:04] <Jazzva_> bdrung_: I think that sounds good, and should be easy. we could find the files with find command and set the M_X_D_L_F. is that what you had in mind?
[23:05] <bdrung_> Jazzva_: yes. here is what is needed: MOZ_XPI_DOCUMENTED_LICENSE_FILES ?= $(strip $(shell for f in COPYING LICENSE; do if test -f $$f; then echo $$f; fi; done))
[23:07] <Jazzva_> bdrung_: I think we cannot limit to those two. We need to include subdirectories, and there might be variations (for example license.txt, or something similar)
[23:08] <Jazzva_> maybe to replace with
[23:08] <bdrung_> Jazzva_: ok, license.txt should be added.
[23:08] <bdrung_> but subdirectories?
[23:09] <Jazzva_> bdrung_: I saw those cases :). weave or ubiquity has something like that. It uses some code, not written by the upstream team itself, and they ship license files with that code in subdirectories
[23:09] <bdrung_> i think we should check the common names
[23:09] <Jazzva_> bdrung_: I agree with that. those three would be just fine, but I think we should also check the subdirectories...
[23:10] <bdrung_> Jazzva_: ok, then i transform it into a find command
[23:10] <Jazzva_> for f in `find . -name {file1,file2}` ; do echo $$f ; done
[23:10] <Jazzva_> yeah :)
[23:12] <bdrung_> Jazzva_: find -iname copying -o -iname 'license*'
[23:12] <bdrung_> that should do it
[23:13] <Jazzva_> bdrung_: ok. if you want, you can add that.
[23:14] <bdrung_> Jazzva_: or sould we check for 'licence*', too?
[23:16] <Jazzva_> bdrung_: ok. but maybe we should use the * wildcard. some other extension might use a  file named licenseCheck.js. so, let's restrict to licen{s,c}e{,.txt}
[23:16] <Jazzva_> s/should/shouldn't/
[23:18] <bdrung_> Jazzva_: yes, that's better. the command looks now like: find * -iname copying -o -iname licen[sc]e -o -iname licen[se]e.txt
[23:21] <Jazzva_> bdrung_: I think that's ok. just replace [se] in the last part with [sc] :)
[23:21] <bdrung_> ups, yes :)
[23:30] <bdrung_> Jazzva_: here you are: https://code.launchpad.net/~bdrung/mozilla-devscripts/mxdlf
[23:32] <Jazzva_> bdrung_: brb, phone