bdrung | asac___: what was the command for sign-off/releasing? | 00:00 |
---|---|---|
asac___ | fta: the bug sounds ... | 00:00 |
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:01 |
fta | http://code.google.com/p/chromium/issues/detail?id=19987 | 00:02 |
fta | asac___, ^^ we have a sync from debian so i don't understand | 00:03 |
asac___ | yes | 00:03 |
asac___ | commented | 00:04 |
=== asac___ is now known as asac | ||
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:10 |
fta | ok | 00:17 |
bdrung | asac: https://code.launchpad.net/~bdrung/mozilla-devscripts/version-0.15/+merge/10558 | 00:18 |
bdrung | asac: i removed the 0.15 tag | 00:18 |
=== Grantbow_ is now known as Grantbow | ||
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:22 |
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:29 |
bdrung | asac: also uploaded to mentors: http://mentors.debian.net/debian/pool/main/m/mozilla-devscripts/mozilla-devscripts_0.15.dsc | 00:35 |
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:49 |
asac | bdrung: so pull does not work ;) | 00:50 |
asac | let me try to branch locally first ;) | 00:51 |
bdrung | pull does not work? | 00:51 |
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:52 |
asac | maybe bzr now opens concurrent connections when pulling multiple revisions into a bound branch | 00:53 |
=== rickspencer3 is now known as rickspencer3-afk | ||
fta | asac, bin nmu, looks like debian to me | 00:57 |
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:58 |
fta | i have: chromium-browser-l10n depends on chromium-browser (= ${binary:Version}) | 00:59 |
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:00 |
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:01 |
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:02 |
asac | micahg: seems they like you ;) | 01:03 |
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:04 |
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:05 |
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:06 |
asac | fta: is anything run during post/pre scripts? | 01:08 |
asac | some l10n processing/compilation maybe or so? | 01:08 |
fta | no | 01:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
asac | great. i cannot open pngs directly there | 01:22 |
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:23 |
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:24 |
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:25 |
fta | Desktop is Bureau in french | 01:27 |
fta | from what i understand, the guy said langpack generated with one build are not usable in another build | 01:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
fta | this is from a tarball, not from a build | 01:36 |
asac | ok and the english id? | 01:36 |
asac | thats not english ;) | 01:37 |
asac | oops | 01:37 |
asac | i scrolled up ;) | 01:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
asac | isnt the one above the one that is in the dialog in english? | 01:44 |
asac | ok not | 01:44 |
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:46 |
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:47 |
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:48 |
fta | hm | 01:52 |
fta | jcastro, lol, a browser popcon ;) the comments were not at all what you expected, i guess | 02:28 |
jcastro | heh | 02:29 |
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:31 |
fta | bug 139855 | 02:38 |
ubottu | Launchpad bug 139855 in soyuz "Display stats about PPA usage" [Low,Triaged] https://launchpad.net/bugs/139855 | 02:38 |
andv | good morning asac | 09:19 |
andv | you disappeared yesterday evening :) | 09:19 |
BUGabundo | does mozilla fennec run on android? | 10:50 |
BUGabundo | asac: ping | 17:15 |
BUGabundo | tell me you are around :) | 17:15 |
fta | hi | 18:50 |
BUGabundo | ola fta | 18:50 |
fta | BUGabundo, he's on holidays for a week | 18:51 |
BUGabundo | bahhhhh | 18:51 |
BUGabundo | who is going to help me now :( | 18:52 |
fta | good time to learn by yourself :) | 18:52 |
fta | like we do ;) | 18:52 |
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:53 |
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:54 |
fta | grrr, use a real irc client | 18:55 |
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:58 |
BUGabundo | don't want, don't do it | 18:59 |
BUGabundo | be FREE | 18:59 |
fta | BUGabundo, it's just not natural to me once a discussion has started, and there's no interference | 19:00 |
BUGabundo | ok ok | 19:00 |
bdrung_ | Jazzva_: how about guessing the files for MOZ_XPI_DOCUMENTED_LICENSE_FILES if this variable is not set? | 22:17 |
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:04 |
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:05 |
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:07 |
Jazzva_ | maybe to replace with | 23:08 |
bdrung_ | Jazzva_: ok, license.txt should be added. | 23:08 |
bdrung_ | but subdirectories? | 23:08 |
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:09 |
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:10 |
bdrung_ | Jazzva_: find -iname copying -o -iname 'license*' | 23:12 |
bdrung_ | that should do it | 23:12 |
Jazzva_ | bdrung_: ok. if you want, you can add that. | 23:13 |
bdrung_ | Jazzva_: or sould we check for 'licence*', too? | 23:14 |
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:16 |
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:18 |
Jazzva_ | bdrung_: I think that's ok. just replace [se] in the last part with [sc] :) | 23:21 |
bdrung_ | ups, yes :) | 23:21 |
bdrung_ | Jazzva_: here you are: https://code.launchpad.net/~bdrung/mozilla-devscripts/mxdlf | 23:30 |
Jazzva_ | bdrung_: brb, phone | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!