/srv/irclogs.ubuntu.com/2009/08/22/#ubuntu-mozillateam.txt

bdrungasac___: 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 in00:01
ftaasac___, "No, Debian's fine. This is only in Ubuntu."00:01
asac___fta: run-mailcap.diff comes from debian00:01
asac___whether they are fine or not is nothing i said ;)00:01
ftait's the last comment in the bug00:01
ftahttp://code.google.com/p/chromium/issues/detail?id=1998700:02
ftaasac___, ^^ we have a sync from debian so i don't understand00:03
asac___yes00:03
asac___commented00:04
=== asac___ is now known as asac
asacfta: 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
asacbut most likely its just the right approach to do both00:10
ftaok00:17
bdrungasac: https://code.launchpad.net/~bdrung/mozilla-devscripts/version-0.15/+merge/1055800:18
bdrungasac: i removed the 0.15 tag00:18
=== Grantbow_ is now known as Grantbow
ftaasac, 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
ftahm, 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 there00:29
bdrungasac: also uploaded to mentors: http://mentors.debian.net/debian/pool/main/m/mozilla-devscripts/mozilla-devscripts_0.15.dsc00:35
asacfta: i think thats not always the case00:49
asacthink about you depending on a arch all package from a any package00:49
asacand you do a binary NMU ... the arch package would not be updated most likely00:49
asacbdrung: so pull does not work ;)00:50
asaclet me try to branch locally first ;)00:51
bdrungpull does not work?00:51
asacnot in a bound branch00:52
asaci did pull --local now00:52
asaclaunchpad seems to be problematic ;)00:52
asacnow trying to push ;)00:52
asacok that worked00:52
asacmaybe bzr now opens concurrent connections when pulling multiple revisions into a bound branch00:53
=== rickspencer3 is now known as rickspencer3-afk
ftaasac, bin nmu, looks like debian to me00:57
asacyes00:58
asacbut we use the same techniques in most cases00:58
asacat lesat if someone ask: "is this enough ..." ;)00:58
ftahttp://code.google.com/p/chromium/issues/detail?id=1969400:58
ftai have: chromium-browser-l10n depends on chromium-browser (= ${binary:Version})00:59
asacbdrung: uploaded01:00
ftaeven 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-browser01:00
ftaor something01:00
bdrungthanks01:00
fta(imho, you're releasing m-d too fast)01:01
asacfta: i wanted to get this up before holiday ;)01:01
asac... also ... release fast and often ;)01:01
asacand both debian and ubuntu ard not yet approaching release ;)01:02
micahgasac: I introduced myself to the Developers :)01:02
asachehe01:02
asacmicahg: seems they like you ;)01:03
ftaasac, so?01:04
micahgasac: I think I can reproduce the bug in Jaunty01:04
micahgat least part of it01:04
asacgood01:04
asacso we can rule that out01:04
asacfta: on what?01:05
asacthe depends?01:05
ftayes01:05
ftahttp://paste.ubuntu.com/257233/ that's today01:05
ftait seems to me -l10n could be out of sync01:05
asacfta: what do you think is the problem of the bug?01:06
asacthe packages not being forced to the right version?01:06
ftathe l10n not from the same build as the browser01:06
asacok you think they could be. let me see01:06
asacfta: is anything run during post/pre scripts?01:08
asacsome l10n processing/compilation maybe or so?01:08
ftano01:08
asacthen the depends should be enough imo01:09
ftawhat if the amd/lpia builds are done 1st, and a user upgrade?01:09
asacfta: maybe its unclear how to grab the right sources? so you dont have the right translations in the source?01:09
ftano, the l10n files (which are in fact .grd files) are generated during the build01:10
asacwere from?01:10
asacare the translations in the same directory as the code that uses them?01:10
ftayes01:10
asacreally?01:10
asacso i have main.c01:11
asacand then i have main.c.grd ?01:11
ftano01:11
asacand then i have main.c.grd.fr .en .es ;) ?01:11
asacyeah01:11
ftaeg http://src.chromium.org/svn/trunk/src/chrome/app/resources/locale_settings.grd01:11
asac<output filename="locale_settings_ar.rc" type="rc_all" lang="ar" />01:12
ftaor http://src.chromium.org/svn/trunk/src/chrome/browser/browser_resources.grd01:12
asacwhere is the input file?01:12
asacthere are no translated strings either01:12
asachmm there seem to be <message elements01:13
asacbut those dont look like the translations01:13
asacrather like the "default/fallback"01:13
asacfta: i wouldnt add the breaks t the l10n package01:13
asacthe depends alone should prevent it from upgrading chrome-browser without removing -l10n01:14
ftahttp://src.chromium.org/svn/trunk/src/chrome/app/resources/google_chrome_strings_de.xtb01:14
asacok01:15
asaci dont know. in worst case its a bug in lzma ;)01:15
asaclol01:15
asacor the sources were really not in01:15
asacsync01:15
asacBreaks: chromium-browser (<< 3.0.197.0~svn20090804r22432)01:16
asacReplaces: chromium-browser01:16
asacdo you need this unversioned replaces?01:16
ftahm, it was when i split the package01:17
asacyeah since you maintain everything from same branch you can just make it versioned01:17
asac<< WHATEVERVERSIONYOUDIDTHEMIGRATION01:17
asacanyway. i would hope thats not the problem (though you should consider it)01:18
ftaso the same as the breaks01:18
asacso 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
ftaeh?01:19
asachow sure are you that the strings that are wrong for the french guy were/are really right in the sources?01:19
asacidentifying how those are different might help01:19
asacif they are really daily changes then it might be a pointer to investigate further ;)01:19
ftahe pasted rpm with 2 different versions01:20
ftathe rpm seems to be repacks from my debs01:20
fta-s01:20
asacyeah so an eventual version diff because of arch all/any can be ruled out01:20
asacwhich probably mean that the packaging is maybe missing some pieces?01:20
asacfta: try to force the same dailies01:21
asacand see if it works01:21
asacif thats the case then its upstream out-of-sync issue01:21
asacwhich i would think is a likely thing for dailies from trunk ;)01:21
asacbut i dont know upstream translation polices ... nor do i see from the bug how many strings are wrong01:21
ftai never experienced this bug myself, i was just trying to figure out if it can happen01:21
asacgreat. i cannot open pngs directly there01:22
asacfta: what does the text mean that is in lowest thign?01:23
asacthat seems to explode the window01:23
asacthat big button (greyed out)01:23
asacavez choisi d'ouvrir automatiquement certain types de fichier ...01:24
asachow is "Desktop" called on french desktops?01:24
asacif you install it as french from scratch i mean01:24
asacdo we translate that=01:25
asachmm. they use Download ;)01:25
asacbut still ... maybe it has something to do with how the french dir name is named01:25
ftaDesktop is Bureau in french01:27
ftafrom what i understand, the guy said langpack generated with one build are not usable in another build01:28
ftabut no idea if that's correct01:29
asacfta: what do they produce?01:29
asaccan you check if you can find this overly long string somewhere?01:29
asaci doubt that its in the source01:30
fta$ file /usr/lib/chromium-browser/locales/fr.pak01:30
fta/usr/lib/chromium-browser/locales/fr.pak: data01:30
asaclooks like a mixup01:30
ftacomment 4 shows:01:30
fta$ rpm -q chromium-browser chromium-browser-l10n01:30
ftachromium-browser-4.0.203.0~svn20090818r23670-1.i38601:30
ftachromium-browser-l10n-4.0.202.0~svn20090813r23308-1.noarch01:30
ftaso it's not the same upstream version01:31
ftai have no difficulty to understand that it may give bad results01:31
asacyes01:31
asacit obviously doesnt break if strings are still ok01:31
asacquestion is if out of sync translations often break it01:32
ftain #10, he said "OK, it's OK if both program & l10n data are synced, aka the same SVN rev."01:32
asaci would hope not01:32
asacotherwise they are doing something wrong01:32
asaceverything worse than gettext would be a step back01:32
ftahe's doing weird stuff with the package, not our problem, but could we have the same situation with the PPA?01:32
asacfta: 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
asacfta: no01:33
asacwe are synched01:33
asacthe depends should be enough imo01:33
asacyou need conflicts/replaces only to transition stuff01: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
asacyeah01:34
asacso question is where that is coming from01:35
asaccheck the template used01:35
fta$ find . -print0 | xargs -0 grep 724208122063442954 | pastebinit01:35
ftahttp://paste.ubuntu.com/257247/01:35
asacyeah01:35
asacfta: whats the english text for that?01:35
asacin the source?01:35
asacoh those are generated01:35
asacis there a similar entry in source?01:35
ftathis is from a tarball, not from a build01:36
asacok and the english id?01:36
asacthats not english ;)01:37
asacoops01:37
asaci 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
asacyeah. but somehoe the english text in teh screenshot is a different string01:39
asacso the ids have a mismatch01:39
asacmeans: they are out of sync in the tree i guess01:39
asaci guess the real string is a few before or after ;)01:39
ftathose 724208122063442954 numbers are coming from somewhere, but no idea from where01:40
asacwhere is IDS_OPTIONS_AUTOOPENFILETYPES_INFO mapped to 72420812206344295401:40
asacfta: i guess they make up  a number by a scheme or something01:40
asaccheck whatelse is in the proximity of IDS_OPTIONS_AUTOOPENFILETYPES_INFO01:40
asacor find the string you see in the english screenshot01:40
asacthe IDS_OPTIONS_AUTOOPENFILETYPES_INFO is probably in the proximity there01:41
ftahttp://codereview.chromium.org/16520901:41
asacthere is not the file i care most01:41
asacthe one where the IDS_OPTIONS_AUTOOPENFILETYPES_INFO was in01:41
asac (Patch set is too large to download)01:42
asaci dont see that file01:42
asachttp://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/resources/01:42
asacits not there01:42
asachttp://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chromium_strings.grd?view=markup01:43
asacokm01: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 downloading01:43
asac      </message>01:43
asac      <message name="IDS_OPTIONS_AUTOOPENFILETYPES_INFO" desc="The inform01:43
asacisnt the one above the one that is in the dialog in english?01:44
asacok not01:44
asacIDS_FR_CUSTOMIZE_DEFAULT_BROWSER01:46
asacso yesw01:46
asaccant say more01:46
asacexecpt that its a out of sync ID01:46
asacmaybe its because chrome_strings and chromium_strings are out of date?01:46
asacout of sync01:46
asacwith some luck its fixed next time they sync locales ;))01:47
ftahttp://paste.ubuntu.com/257255/01:47
fta?01:47
asacshould be ok01:47
asaci dont think you need the breaks because of the depends01:48
asacbuit tahts in the past anyway01:48
asaci would drop those things if nothing was ever released to real archives01:48
asacat least after a while01:48
ftahm01:52
ftajcastro, lol, a browser popcon ;) the comments were not at all what you expected, i guess02:28
jcastroheh02:29
ftajcastro, 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 logs02:31
jcastroyeah but I don't02:31
ftai's sure want to know too ;)02:31
fta'd02:31
ftabug 13985502:38
ubottuLaunchpad bug 139855 in soyuz "Display stats about PPA usage" [Low,Triaged] https://launchpad.net/bugs/13985502:38
andvgood morning asac09:19
andvyou disappeared yesterday evening :)09:19
BUGabundodoes mozilla fennec run on android?10:50
BUGabundoasac: ping17:15
BUGabundotell me you are around :)17:15
ftahi18:50
BUGabundoola fta18:50
ftaBUGabundo, he's on holidays for a week18:51
BUGabundobahhhhh18:51
BUGabundowho is going to help me now :(18:52
ftagood time to learn by yourself :)18:52
ftalike we do ;)18:52
ftafennec on android, no way, unless android now allows native apps18:53
BUGabundofta: 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
BUGabundofta: it doesn't18:53
BUGabundobut I read on the ML (thanks to google)18:54
BUGabundothat someone is porting it to the SDK18:54
ftathen it's a full rewrite, not a port18:54
BUGabundoI really would appreciate if you could ping me.... I loose all your replies :)18:54
ftagrrr, use a real irc client18:55
BUGabundofor what?18:58
BUGabundoI can very easily read all the channel blober18:58
BUGabundoI just get a faster notification if you, fta, nick me :)18:58
BUGabundodon't want, don't do it18:59
BUGabundobe FREE18:59
ftaBUGabundo, it's just not natural to me once a discussion has started, and there's no interference19:00
BUGabundook ok19: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 with23: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 subdirectories23:09
bdrung_i think we should check the common names23: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 command23:10
Jazzva_for f in `find . -name {file1,file2}` ; do echo $$f ; done23:10
Jazzva_yeah :)23:10
bdrung_Jazzva_: find -iname copying -o -iname 'license*'23:12
bdrung_that should do it23: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.txt23: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/mxdlf23:30
Jazzva_bdrung_: brb, phone23:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!