1314892 - Provide allowed duplicate list for SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Frank-Rainer Grahl (:frg)]

c-c compile is currently broken. Provide the list of allowed duplicated for all platforms to make find-dupes.py happy.

Comment 1

[Edmund Wong (:ewong)]

Attachment: dupe_linux.txt

this is the duplicate list for Linux.

Comment 2

[Frank-Rainer Grahl (:frg)]

Stefan,

can you provide the dupes list for OSX? c-c is currently broken.

Comment 3

[Frank-Rainer Grahl (:frg)]

Attachment: 1314892-interim.patch

This turns the dupes into a warning till the lists are ready.

Comment 4

[Stefan [:stefanh]]

(In reply to Frank-Rainer Grahl from comment #2)
> Stefan,
> 
> can you provide the dupes list for OSX? c-c is currently broken.

What is a "dupes list" and how do I generate one?

Comment 5

[Frank-Rainer Grahl (:frg)]

make installer or make package should log the duplicates to the console. The one for TB is in mail/installer/allowed-dupes.mn. See bug 1313670. Without it find-dupes.py now errors out per default.

Comment 6

[Philip Chee]

Comment on attachment 8807534 [details] [diff] [review]
1314892-interim.patch

> +	-w -f $(MOZILLA_DIR)/browser/installer/allowed-dupes.mn \
Hmm if you use -w then -f is not needed right? Unless you are trying to reduce the console spam.

Comment 7

[Stefan [:stefanh]]

Attachment: dupe_mac.txt

Here's all the reported dupes. I was a little bit unsure of the format, so I didn't filter the paths.

Comment 8

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/09eeb66be9226c9e22f91ef1b2bb4b841ca93ce1

> Hmm if you use -w then -f is not needed right? Unless you are trying to reduce the console spam.

Acutally I wasn't sure if it wouldn't need at least one file and wanted to play it safe. Didn't have the patience to play around any longer with it :) Also it should now only report our duplicates.

Comment 9

[Frank-Rainer Grahl (:frg)]

Attachment: 1314892-SeaMonkey-dupes-WIP.patch

Stefan could you probably apply the patch, run an OSX compile and upload the remaining once here or put them in an updated patch. 

The toolkit backend code has a problem here with l10n again. Even after whitelisting the inspector locale files it will report GB and US as duplicate. Personally I would just leave the -w switch in place and not fix it there.

Comment 10

[Frank-Rainer Grahl (:frg)]

>> remaining once 

remaining ones of course.

Comment 11

[Stefan [:stefanh]]

Comment on attachment 8821520 [details] [diff] [review]
1314892-SeaMonkey-dupes-WIP.patch

Hmm, lots of warnings. I'll attach a log so you can see how it looks.

Comment 12

[Stefan [:stefanh]]

Attachment: dupes_mac.txt

Log of dupes when doing 'mach package' in suite/installer.

Comment 13

[Frank-Rainer Grahl (:frg)]

Attachment: 1314892-SeaMonkey-dupes.patch

Stefan,

Merry Christmas. Could you try this list. I added the OSX specific files from your log and cleaned it up a bit. I am almost sure the the seamonkey.app prefix is not needed for most of them. This list should only report the DOMi en-GB and en-US l10n files as duplicate.

Comment 14

[Stefan [:stefanh]]

Comment on attachment 8821777 [details] [diff] [review]
1314892-SeaMonkey-dupes.patch

If I understand this right, I shouldn't see any warnings at all for files listed in suite/installer/allowed-dupes.mn? I don't really see any difference...

Comment 15

[Stefan [:stefanh]]

Attachment: mac_dupes_log.txt

Here's the log when packaging with the current patch.

Comment 16

[Stefan [:stefanh]]

(In reply to Frank-Rainer Grahl from comment #13)
> Stefan,
> 
> Merry Christmas.

Merry Christmas!

Comment 17

[Stefan [:stefanh]]

Comment on attachment 8821777 [details] [diff] [review]
1314892-SeaMonkey-dupes.patch

Sorry, I must have missed something when applying the patch. There's 2 lines that needs to be changed, ten it works fine:

+SeaMonkey.app/Contents/MacOS/plugin-container.app/Contents/Resources/English.lproj/InfoPlist.strings
+SeaMonkey.app/Contents/Resources/en.lproj/InfoPlist.strings

Should be:
plugin-container.app/Contents/Resources/English.lproj/InfoPlist.strings
en.lproj/InfoPlist.strings

Comment 18

[Frank-Rainer Grahl (:frg)]

Attachment: 1314892-SeaMonkey-dupes-V1.patch

-w needs to stay in for now because of the inspector locale files.

Comment 19

[Ian Neal]

Comment on attachment 8821823 [details] [diff] [review]
1314892-SeaMonkey-dupes-V1.patch

r/a=me

Comment 20

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/b2de81d657b6fe3c5f991e9f29ce0e3076272d0e
https://hg.mozilla.org/releases/comm-aurora/rev/4085badebe0a1745e4ccdd54627104cfbe4ce099

Set leave-open. The patch needs an small update because Lightning is installed under distribution/extentions there.

Comment 21

[Frank-Rainer Grahl (:frg)]

Attachment: 1314892-SeaMonkey-dupes-distri.patch

Followup for Lightning only.

IanN what to do about DOMi?

- Edit a comment into the GB or US locales so that they are different
- Try to fix it in a followup bug
- Move the locales to the l10n repositories (which would also theoretically help for the l10n build bug).

Comment 22

[Ian Neal]

(In reply to Frank-Rainer Grahl from comment #21)
> Created attachment 8821923 [details] [diff] [review]
> 1314892-SeaMonkey-dupes-distri.patch
> 
> Followup for Lightning only.
> 
> IanN what to do about DOMi?
> 
> - Edit a comment into the GB or US locales so that they are different
> - Try to fix it in a followup bug
> - Move the locales to the l10n repositories (which would also theoretically
> help for the l10n build bug).

Should Lightning have its own dupes list rather than TB / SM each having one for it?

I already have a patch for moving locales to l10n repos (and doing some flattening), just wanted to check the best way of achieving it with flod or pike.

Comment 23

[Frank-Rainer Grahl (:frg)]

>> Should Lightning have its own dupes list rather than TB / SM each having one for it?

Was on my mind too and planned to open a bug in calendar next.

Fallen do you concur that Lightning should get its own dupes file which can be included by TB and SeaMonkey then?

FRG

Comment 24

[Edmund Wong (:ewong)]

Comment on attachment 8821923 [details] [diff] [review]
1314892-SeaMonkey-dupes-distri.patch

Review of attachment 8821923 [details] [diff] [review]:
-----------------------------------------------------------------

::: suite/installer/allowed-dupes.mn
@@ +267,5 @@
>  chrome/toolkit/skin/classic/global/media/throbber.png
>  extensions/[e-mail]/chrome/modern/skin/modern/communicator/brand/throbber-anim.png
>  chrome/classic/skin/classic/communicator/brand/throbber-anim.png
> +
> +# Lightning Nighly

nit: Nightly

Comment 25

[Ian Neal]

Comment on attachment 8821923 [details] [diff] [review]
1314892-SeaMonkey-dupes-distri.patch

r/a=me still needs an answer from Fallen though

Comment 26

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to Frank-Rainer Grahl from comment #23)
> Fallen do you concur that Lightning should get its own dupes file which can
> be included by TB and SeaMonkey then?

Sure, sounds good to me. If it is just the few files as it is right now, I think its not worth too much extra effort through. The goal is to consolidate the themes in a way that we only need one xpi anyway.

Comment 27

[Frank-Rainer Grahl (:frg)]

Took the liberty and pushed it to beta because aurora merged since the approve:

https://hg.mozilla.org/comm-central/rev/9a8875e3bff1e9f6cd2ba8e1745d722addce4de2
https://hg.mozilla.org/releases/comm-beta/rev/adb2af9a87b6321f1b0fc16320d9996ae0715ff6

If I find some time (no promise) I will look at Bug 1317630 to get the Calendar dupes out of mail and suite.