1229810 - Port Bug 1228444 and Bug 1228467 to Chatzilla

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Philip Chee]

references:
Bug 1228444 Rename DIST_FILES to FINAL_TARGET_PP_FILES
Bug 1228467 Don't preprocess chrome files without preprocessor directives

Comment 1

[Philip Chee]

Attachment: Bug1229810PreProcess.patch

> -*	content/chatzilla/contents.rdf               (xul/content/contents.rdf)
> +	content/chatzilla/contents.rdf               (xul/content/contents.rdf)

mozbuild.preprocessor.Error: ('c:\\t1\\hg\\comm-central\\mozilla\\extensions\\irc\\xul/content/contents.rdf', None, 'no preprocessor directives found', None)

> +FINAL_TARGET_PP_FILES += [
> +    'xpi/resources/install.rdf',
> +]

I did not remove the following line in Makefile.in because we need to supporting building on comm-aurora, comm-beta, and comm-release.
DIST_FILES = xpi/resources/install.rdf

Comment 2

[:Gijs (he/him)]

Comment on attachment 8694785 [details] [diff] [review]
Bug1229810PreProcess.patch

If we're doing anything about contents.rdf it's going to be killing it entirely, so please just remove it.

For install.rdf: in the makefile world, what's packaging chrome.manifest, and shouldn't that be in there or FINAL_TARGET_FILES, too?

Comment 3

[Philip Chee]

(In reply to :Gijs Kruitbosch from comment #2)

> If we're doing anything about contents.rdf it's going to be killing it
> entirely, so please just remove it.
Will fix. Thanks.

> For install.rdf: in the makefile world, what's packaging chrome.manifest,
> and shouldn't that be in there or FINAL_TARGET_FILES, too?

I don't *know* for certain but IIRC putting two lines in moz.build like:

JAR_MANIFESTS += ['jar.mn']
USE_EXTENSION_MANIFEST = True

Causes a chrome.manifest file to be created in the right place. Maybe ask glandium or gps?

Comment 4

[Tony Mechelynck [:tonymec]]

IIUC, this bug is why cZ's install.rdf, which is present at ./xpi/resources/install.rdf relative to the cZ repo, is not found back in SeaMonkey's ./distribution/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi (the packaged-in ChatZilla) after installation.

Alas, the latest SeaMonkey 2.43a1 linux-x86_64 nightly is at the moment the one from 17 December. As soon as both (this bug is fixed on Trunk) and (my nightlies appear again) I'll be sure to check that they come with a usable ChatZilla.

Comment 5

[Tony Mechelynck [:tonymec]]

P.S. There is also a cZ ./locales/generic/install.rdf but it seems less up-to-date. Not sure if it is used, or what for.

Comment 6

[Frank-Rainer Grahl (:frg)]

Philip,

I am not sure if this is the right bug here but the suite l10n builds are also broken starting with 2.41. I am unable to build the de language pack on Windows. I think the build files in the locales directory need some changes too.

Comment 7

[Frank-Rainer Grahl (:frg)]

Tony,

overlooked you comment when I wrote my last reply. You are right. At least the processing of the locales/generic/install.rdf needs to change too. It's used for the l10n builds to produce a language pack xpi and it's broken now.

Comment 8

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #7)
> Tony,
> 
> overlooked you comment when I wrote my last reply. You are right. At least
> the processing of the locales/generic/install.rdf needs to change too. It's
> used for the l10n builds to produce a language pack xpi and it's broken now.

See the parallel bug 1229803 which was fixed a few days ago for DOMi, giving it back its installability. Maybe a third parallel bug is needed for langpacks. Hopefully all langpacks use a common template which would allow fixing them all in one fell swoop? (ChatZilla and DOMi actually have their separate repositories, distinct from each other and from mozilla-central.)

Comment 10

[:Gijs (he/him)]

contents.rdf was removed in bug 1185748, so I'm just going to land the rest of this patch with r=me

Comment 11

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/chatzilla/rev/35ff2f0f2ad8

This should be fixed on CZ tip now. If different bits of SeaMonkey need to create tags or whatever, I don't know anything about that and you'll have to do it yourself. :-)

Comment 12

[Tony Mechelynck [:tonymec]]

(In reply to :Gijs Kruitbosch from comment #11)
> remote:   https://hg.mozilla.org/chatzilla/rev/35ff2f0f2ad8
> 
> This should be fixed on CZ tip now. If different bits of SeaMonkey need to
> create tags or whatever, I don't know anything about that and you'll have to
> do it yourself. :-)

This tinderbox-build, made after the fix landed, comes with a ChatZilla which includes an install.rdf and can be installed by clicking on the link to {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi in the page for file:///usr/local/seamonkey/distribution/extensions. The XPI of the same name in the previous tinderbox-build, built before the landing, had no install.rdf.

I am at the point where the add-ons manager tells me "ChatZilla will be updated after you restart seaMonkey", which is farther than I could arrive when the bug wasn't fixed.

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 SeaMonkey/2.43a1" 
ID:20151229113729 en-US 
c-c:93949bd3d352d8fbc60428149ddb95c8757ea256 
m-c:9ddf0da90fb3bc1ae29966dc596013fc54a44bd2

Comment 13

[Edmund Wong (:ewong)]

(In reply to :Gijs Kruitbosch from comment #11)
> remote:   https://hg.mozilla.org/chatzilla/rev/35ff2f0f2ad8
> 
> This should be fixed on CZ tip now. If different bits of SeaMonkey need to
> create tags or whatever, I don't know anything about that and you'll have to
> do it yourself. :-)

That's what's needed right now.

Comment 14

[Edmund Wong (:ewong)]

Fwiw, changed SEA2_37_RELBRANCH to point to the
new cset.

https://hg.mozilla.org/chatzilla/rev/e1ed4994cb0b

Comment 15

[Frank-Rainer Grahl (:frg)]

Did you try it with a non en-us build? I am quite sure building the language pack in the locales directory is still broken.

FRG

Comment 16

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #15)
> Did you try it with a non en-us build? I am quite sure building the language
> pack in the locales directory is still broken.
> 
> FRG

No I didn't. You do mean the locales included in the cZ XPI don't you? If they're still broken, IMHO a followup bug would be best. OTOH if you mean the global SeaMonkey langpacks, then a different branch is indicated because their code dosen't live in the cZ repo.

Comment 17

[Tony Mechelynck [:tonymec]]

s/a different branch/a different bug/

Comment 18

[Frank-Rainer Grahl (:frg)]

suite comm-release and comm-beta builds are broken right now. They do not like FINAL_TARGET_PP_FILES.

comm-beta and I suspect comm-aurora and comm-central locale de suite builds break in preprocessing for the chatzilla languagage pack. Should I open another bug for this as Tony suggested?

+++ snipp +++
==============================
ERROR PROCESSING MOZBUILD FILE
==============================

The error occurred while processing the following file:

    c:/seamonkey/comm-release/mozilla/extensions/irc/moz.build

The error was triggered on line 24 of this file:

    FINAL_TARGET_PP_FILES += [

The underlying problem is an attempt to read a reserved UPPERCASE variable that does not exist.

The variable read causing the error is:

    FINAL_TARGET_PP_FILES

Maybe you meant FINAL_TARGET_FILES or FINAL_TARGET?

Please change the file to not use this variable.

Comment 19

[:Gijs (he/him)]

Why aren't the release and beta builds using a specific tag of ChatZilla to build?

Comment 20

[Ian Neal]

(In reply to Edmund Wong (:ewong) from comment #14)
> Fwiw, changed SEA2_37_RELBRANCH to point to the
> new cset.
> 
> https://hg.mozilla.org/chatzilla/rev/e1ed4994cb0b

It is probably wrong to keep using SEA2_37_RELBRANCH as we released 2.37 a while ago now.

Whatever tag (SEA2_40_RELBRANCH perhaps) that is used for current comm-release (2.40) and comm-beta (2.41) should probably point to something like https://hg.mozilla.org/chatzilla/rev/bfc8dea4cfab (which doesn't include FINAL_TARGET_PP_FILES changes).

Then SEA2_42_RELBRANCH should point to a rev that does include FINAL_TARGET_PP_FILES changes i.e. https://hg.mozilla.org/chatzilla/rev/35ff2f0f2ad8

Comment 21

[Frank-Rainer Grahl (:frg)]

Suite comm-release en-us and a de locale release builds fine with Chatzilla tag SEAMONKEY_2_40_RELEASE. The xpi and the de-language xpi seem to be fine and include preprocessed install.rdf files. The Seamonkey target verson seem to be too low in both of them? Didn't try to install them yet.

FRG

Comment 22

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #21)
> Suite comm-release en-us and a de locale release builds fine with Chatzilla
> tag SEAMONKEY_2_40_RELEASE. The xpi and the de-language xpi seem to be fine
> and include preprocessed install.rdf files. The Seamonkey target verson seem
> to be too low in both of them? Didn't try to install them yet.
> 
> FRG

So the correct tags exist but we need to make sure that we pull the right one? This points to a SeaMonkey / Release Engineering problem.

Comment 23

[Ian Neal]

(In reply to Tony Mechelynck [:tonymec] from comment #22)
> (In reply to Frank-Rainer Grahl from comment #21)
> > Suite comm-release en-us and a de locale release builds fine with Chatzilla
> > tag SEAMONKEY_2_40_RELEASE. The xpi and the de-language xpi seem to be fine
> > and include preprocessed install.rdf files. The Seamonkey target verson seem
> > to be too low in both of them? Didn't try to install them yet.
> > 
> > FRG
> 
> So the correct tags exist but we need to make sure that we pull the right
> one? This points to a SeaMonkey / Release Engineering problem.

comm-release and comm-beta will work with SEAMONKEY_2_40_RELEASE but I think it would be better to create a tag SEA2_40_RELBRANCH that includes the fix from bug 1223210 (i.e. https://hg.mozilla.org/chatzilla/rev/bfc8dea4cfab)

Comment 24

[Edmund Wong (:ewong)]

(In reply to Ian Neal from comment #20)
> (In reply to Edmund Wong (:ewong) from comment #14)
> > Fwiw, changed SEA2_37_RELBRANCH to point to the
> > new cset.
> > 
> > https://hg.mozilla.org/chatzilla/rev/e1ed4994cb0b
> 
> It is probably wrong to keep using SEA2_37_RELBRANCH as we released 2.37 a
> while ago now.
> 
> Whatever tag (SEA2_40_RELBRANCH perhaps) that is used for current
> comm-release (2.40) and comm-beta (2.41) should probably point to something
> like https://hg.mozilla.org/chatzilla/rev/bfc8dea4cfab (which doesn't
> include FINAL_TARGET_PP_FILES changes).
> 
> Then SEA2_42_RELBRANCH should point to a rev that does include
> FINAL_TARGET_PP_FILES changes i.e.
> https://hg.mozilla.org/chatzilla/rev/35ff2f0f2ad8

If no one objects, I'll backout my tag change and push a use-the-right-tag
change.

Comment 25

[Edmund Wong (:ewong)]

(In reply to Edmund Wong (:ewong) from comment #14)
> Fwiw, changed SEA2_37_RELBRANCH to point to the
> new cset.
> 
> https://hg.mozilla.org/chatzilla/rev/e1ed4994cb0b

Backed this change out: https://hg.mozilla.org/chatzilla/rev/7d4285ebc5d6

Comment 26

[Edmund Wong (:ewong)]

Spinning the required c-a changes to bug 1235961, since the changes required
are not relevant to this bug.

Comment 27

[:Gijs (he/him)]

(In reply to Edmund Wong (:ewong) from comment #26)
> Spinning the required c-a changes to bug 1235961, since the changes required
> are not relevant to this bug.

Does this mean we're done here?

Comment 28

[Frank-Rainer Grahl (:frg)]

Depends if this bug also covers the language pack. Language pack processing is still broken for suite comm-beta to c-c

Comment 29

[Ian Neal]

(In reply to Frank-Rainer Grahl from comment #28)
> Depends if this bug also covers the language pack. Language pack processing
> is still broken for suite comm-beta to c-c

I believe we still need to tag the relevant cset for c-b and c-r and update the client.py to pull it.

Comment 30

[Frank-Rainer Grahl (:frg)]

Just tried to build a de c-c locale suite on Windows. Changed chatzilla branch to default in client.py and made sure that it was checked out fresh. Builds fine but the additional chatzilla xpi language pack is broken as I suspected. The install.rdf is not preprocessed and copied into it.  

Btw. had to hack debugQA just to get it going. Also refused to build but that's another story.

This was the last action for me this year. Cheers to all of you and see you next year :)

FRG

Comment 31

[Edmund Wong (:ewong)]

(In reply to :Gijs Kruitbosch from comment #27)
> (In reply to Edmund Wong (:ewong) from comment #26)
> > Spinning the required c-a changes to bug 1235961, since the changes required
> > are not relevant to this bug.
> 
> Does this mean we're done here?

I believe so.

Comment 32

[:Gijs (he/him)]

(In reply to Frank-Rainer Grahl from comment #30)
> Just tried to build a de c-c locale suite on Windows. Changed chatzilla
> branch to default in client.py and made sure that it was checked out fresh.
> Builds fine but the additional chatzilla xpi language pack is broken as I
> suspected. The install.rdf is not preprocessed and copied into it.  

Please could you file a separate bug specifically about what's going wrong here, and how you're creating the additional cz langpack (using makexpi.py, or something else?)

Resolving this because we're no longer breaking the main SM build, and that was what this bug got filed about.

Comment 33

[Frank-Rainer Grahl (:frg)]

Will do.

Just lloked if one is already open and I think Bug 1210791 needs to be resolved first for locale builds to succeed. This one already covers the main problem.

FRG

Comment 34

[Tony Mechelynck [:tonymec]]

Oops. Bug appeared in SeaMonkey 2.42 as a consequence of the landings mentioned in comment #0 so I went too fast in assigning tracking flags.

Fixed in comment #11 for 2.43a1 and in bug 1235961 comment #4 for 2.42a2. Earlier branches unaffected.