Closed Bug 1293943 Opened 4 years ago Closed 4 years ago

l10n nightly builds: wget-en_US tries to get lightning xpi

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ewong, Assigned: ewong)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

Not exactly sure what's going on right now, but the log for
the l10n nightly build(repack?) is showing this during the
wget-en_US (which should be getting the seamonkey tarball/zip and
not lightning.. but I admit I haven't been paying attention to
the l10n only until lately..so I could've missed something),
we're getting:

DEBUG: doshell: command: /usr/bin/env DOWNLOAD_BASE_URL="http://ftp.mozilla.org/pub/seamonkey/nightly" SYMBOL_SERVER_HOST="symbolpush.mozilla.org" EN_US_BINARY_URL="http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk" CCACHE_DIR="/builds/ccache" POST_SYMBOL_UPLOAD_CMD="/usr/local/bin/post-symbol-upload.py" MOZ_AUTOMATION="1" SYMBOL_SERVER_SSH_KEY="/home/seabld/.ssh/seabld_dsa" MOZ_MAKE_COMPLETE_MAR="1" LD_LIBRARY_PATH="/tools/gcc-4.5/lib" PATH="/tools/buildbot/bin:/usr/local/bin:/usr/lib/ccache:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/tools/git/bin:/tools/python27/bin:/tools/python27-mercurial/bin:/home/cltbld/bin" MOZ_UPDATE_CHANNEL="nightly" L10NBASEDIR="../../l10n" CVS_RSH="ssh" CCACHE_COMPRESS="1" SYMBOL_SERVER_PATH="/mnt/netapp/breakpad/symbols_sea/" MOZ_OBJDIR="objdir" MOZ_CRASHREPORTER_NO_REPORT="1" SYMBOL_SERVER_USER="seabld" DISPLAY=":2" TINDERBOX_OUTPUT="1" CCACHE_UMASK="002" python '/builds/slave/c-cen-t-lnx-l10n-ntly/tools/buildfarm/utils/retry.py' -s 1 -r 5 -t 1260 make wget-en-US
DEBUG: child environment: {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'TZ': 'EST5EDT', 'HOSTNAME': 'mock', 'HOME': '/builds', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TMPDIR': '/tmp'}
retry: Calling <function run_with_timeout at 0x7fa23b4190c8> with args: (['make', 'wget-en-US'], 1260, None, None, False, True), kwargs: {}, attempt #1
Executing: ['make', 'wget-en-US']
make -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
make[1]: Entering directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
mkdir -p ../../dist/xpi-stage
(cd ../../dist/xpi-stage && wget -nv -N http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)
http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi:
2016-08-10 03:00:40 ERROR 404: Not Found.
make[1]: *** [wget-en-US] Error 8
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
make: *** [calendar-wget-en-US] Error 2
retry: Failed, sleeping 1 seconds before retrying
retry: Calling <function run_with_timeout at 0x7fa23b4190c8> with args: (['make', 'wget-en-US'], 1260, None, None, False, True), kwargs: {}, attempt #2
Executing: ['make', 'wget-en-US']
make -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
make[1]: Entering directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
(cd ../../dist/xpi-stage && wget -nv -N http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)
http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi:
2016-08-10 03:00:42 ERROR 404: Not Found.
make[1]: *** [wget-en-US] Error 8
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
make: *** [calendar-wget-en-US] Error 2
retry: Failed, sleeping 1 seconds before retrying
retry: Calling <function run_with_timeout at 0x7fa23b4190c8> with args: (['make', 'wget-en-US'], 1260, None, None, False, True), kwargs: {}, attempt #3
Executing: ['make', 'wget-en-US']
make -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
make[1]: Entering directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
(cd ../../dist/xpi-stage && wget -nv -N http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)
http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi:
2016-08-10 03:00:44 ERROR 404: Not Found.
make[1]: *** [wget-en-US] Error 8
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
make: *** [calendar-wget-en-US] Error 2
retry: Failed, sleeping 1 seconds before retrying
retry: Calling <function run_with_timeout at 0x7fa23b4190c8> with args: (['make', 'wget-en-US'], 1260, None, None, False, True), kwargs: {}, attempt #4
Executing: ['make', 'wget-en-US']
make -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
make[1]: Entering directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
(cd ../../dist/xpi-stage && wget -nv -N http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)
http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi:
2016-08-10 03:00:45 ERROR 404: Not Found.
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
make[1]: *** [wget-en-US] Error 8
make: *** [calendar-wget-en-US] Error 2
retry: Failed, sleeping 1 seconds before retrying
retry: Calling <function run_with_timeout at 0x7fa23b4190c8> with args: (['make', 'wget-en-US'], 1260, None, None, False, True), kwargs: {}, attempt #5
Executing: ['make', 'wget-en-US']
make -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
make[1]: Entering directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
(cd ../../dist/xpi-stage && wget -nv -N http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)
http://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi:
2016-08-10 03:00:47 ERROR 404: Not Found.
make[1]: *** [wget-en-US] Error 8
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-l10n-ntly/build/comm-central-trunk/objdir/calendar/lightning'
make: *** [calendar-wget-en-US] Error 2
retry: Giving up on <function run_with_timeout at 0x7fa23b4190c8>
Unable to successfully run ['make', 'wget-en-US'] after 5 attempts

was the lightning xpi supposed to also be copied to the latest-comm-central-trunk
directory?
frg, got any ideas?
Flags: needinfo?(frgrahl)
Hmm just looking at the dates from the Thunderbird builds it looks to me like they are done in parallel and uploaded to different locations. I am seeing no l10n builds but this seems to be generally broken:

https://archive.mozilla.org/pub/calendar/lightning/nightly/2016/08/2016-08-10-00-40-02-comm-aurora/
https://archive.mozilla.org/pub/thunderbird/nightly/2016/08/2016-08-10-00-40-02-comm-aurora/

I think you should ask Adrian. His unofficial builds also contain lightning xpis in the ftp dirs. I will check the makefiles if I find something.
Flags: needinfo?(frgrahl)
The errors come from \calendar\lightning\lightning-packager.mk. I am quite sure this needs to change to take suite builds into account. 

Maybe its enough to skip this completely or only the first part:

>> # Check if EN_US_BINARY_URL has finally been set
>> ifdef EN_US_BINARY_URL
>> # If so, we are expected to unpack when the language pack is created
>> ensure-stage-dir: wget-en-US unpack
>> else
>> # If not, use the existing lightning from xpi-stage, or warn that the var is not set.
>> ensure-stage-dir:
>> ifeq (,$(wildcard $(XPI_STAGE_PATH)/$(XPI_NAME)/))
>> 	$(error You must set EN_US_BINARY_URL)
>> endif
>> endif
>> wget-en-US: FINAL_BINARY_URL = $(subst thunderbird,calendar/lightning,$(EN_US_BINARY_URL))

I think here is where it actually failed. Didn't take Seamonkey into account and just assumed a tb build. 

But would also be wrong or lets say not 100% ocrrect:
http://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-central-trunk/lightning-5.3a1.en-US.linux-i686.xpi)

latest-comm-central-trunk doesn't exist. Should be latest-comm-central as in Thunderbird builds. I think we should match them or we will have further problems down the road with this.

This would have worked then:

http://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-central/lightning-5.3a1.en-US.linux-i686.xpi:
(In reply to Frank-Rainer Grahl from comment #4)

> http://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-central/
> lightning-5.3a1.en-US.linux-i686.xpi:

Given https://dxr.mozilla.org/comm-central/source/suite/locales/Makefile.in#242

I'm wondering if we should just override those rules so that it fits our
infra?

(In reply to Frank-Rainer Grahl from comment #4)
> >> wget-en-US: FINAL_BINARY_URL = $(subst thunderbird,calendar/lightning,$(EN_US_BINARY_URL))
> 
> I think here is where it actually failed. Didn't take Seamonkey into account
> and just assumed a tb build. 
> 

With the above, I'm keen to ask Fallen if adding a check in the
wget-en-US rule to check whether it's TB or SM that lightning is
being packaged under?

:Fallen, is this a viable choice?
Flags: needinfo?(philipp)
(In reply to Edmund Wong (:ewong) from comment #5)
> (In reply to Frank-Rainer Grahl from comment #4)
> > >> wget-en-US: FINAL_BINARY_URL = $(subst thunderbird,calendar/lightning,$(EN_US_BINARY_URL))
> > 
> > I think here is where it actually failed. Didn't take Seamonkey into account
> > and just assumed a tb build. 
> > 
> 
> With the above, I'm keen to ask Fallen if adding a check in the
> wget-en-US rule to check whether it's TB or SM that lightning is
> being packaged under?
> 
> :Fallen, is this a viable choice?

Edit fail.  Supposed to ask the above.  Ignore  the 'modify to fit our needs' 
response.
I looked a little further into this. There is also an upload step at the end which would then be triggered by building the Nightly. The question is if the lightning language pack generation shouldn't be completely disabled during Seamonkey builds? Otherwise we and TB would probably upload them and worst case with different build options.
I'm fine with changing the wget-en-US rule to adapt for seamonkey. For the upload rule please make sure that Seamonkey doesn't upload Lightning to /calendar/, as this is already being done by Thunderbird.
Flags: needinfo?(philipp)
Attached patch wip patch (obsolete) β€” β€” Splinter Review
This patch ensures that SeaMonkey's wget-en-US is run first before
calendar's wget-en-US.

Note:  SeaMonkey uses latest-comm-central-trunk, so aside for changing
seamonkey to calendar/lightning, we need to also change latest-comm-central-trunk
to latest-comm-central.


NB2: while I've tried this on a slave and it 'works', I'm not confident
this is sufficient enough to unhork the l10n nightlies since I'm
just fixing the |make wget-en-US|.. this could just well as break
in later steps.  

so asking review on the calendar part.
Attachment #8789967 - Flags: review?(philipp)
(In reply to Edmund Wong (:ewong) from comment #9)
> Created attachment 8789967 [details] [diff] [review]
> wip patch
> 
> This patch ensures that SeaMonkey's wget-en-US is run first before
> calendar's wget-en-US.

Why?

Because we use toolkit/locales' l10n.mk's wget-en-US rule (afaik),
and the current state of our wget-en-US uses Calendar's wget-en-US
methodology, when we really should use toolkit's wget-en-US.  So..
I copied l10n.mk's wget-en-US to sm-wget-en-US: .

This is my understanding so far.  Pretty much need clarification from
anyone atm.
Comment on attachment 8789967 [details] [diff] [review]
wip patch

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

r+ with this typo fix, I'd appreciate if you could stay on the hook if for some reason this breaks Thunderbird release builds.

::: suite/locales/Makefile.in
@@ +223,5 @@
>  $(MAKE) -C $(LIGHTNING_PATH) LOCALE_MERGEDIR=$(LOCALE_MERGEDIR) $(subst calendar-,,$@)
>  $(MAKE) -C $(GDATA_PATH) LOCALE_MERGEDIR=$(LOCALE_MERGEDIR) $(subst calendar-,,$@)
>  endef
>  
> +sm-wget-en-uUS:

sm-wget-en-US
Attachment #8789967 - Flags: review?(philipp) → review+
Attached patch proposed patch (v2) (obsolete) β€” β€” Splinter Review
fixed typo.
Assignee: nobody → ewong
Attachment #8789967 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8792362 - Flags: review+
(In reply to Philipp Kewisch [:Fallen] from comment #11)
> Comment on attachment 8789967 [details] [diff] [review]
> wip patch
> 
> Review of attachment 8789967 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ with this typo fix, I'd appreciate if you could stay on the hook if for
> some reason this breaks Thunderbird release builds.
> 

Definitely

> ::: suite/locales/Makefile.in
> @@ +223,5 @@
> >  $(MAKE) -C $(LIGHTNING_PATH) LOCALE_MERGEDIR=$(LOCALE_MERGEDIR) $(subst calendar-,,$@)
> >  $(MAKE) -C $(GDATA_PATH) LOCALE_MERGEDIR=$(LOCALE_MERGEDIR) $(subst calendar-,,$@)
> >  endef
> >  
> > +sm-wget-en-uUS:
> 
> sm-wget-en-US

Fixed.
https://hg.mozilla.org/comm-central/rev/daeb41bc07bbe0059d419bd0ed71a614d1ae0cc5
Bug 1293943 - l10n nightlies busted on wget-en-US r=Fallen a=ewong
Attached patch fix for previous patch β€” β€” Splinter Review
Apparently I missed out on the variable EN_US_BINARY_URL.  

I should've had :

FINAL_BINARY_URL = $(subst seamonkey,calendar/lightning,$(subst latest-comm-central-trunk,latest-comm-central,$(EN_US_BINARY_URL)))

but I missed the $( before the EN_US_BINARY_URL.

Also,

unpack and upload (right now, at least.. probably needs fixing for upload)
doesn't need the double colons.  Fixed that as well.

(incidentally..  I backed out the previous patch)
Attachment #8792362 - Attachment is obsolete: true
Attachment #8792377 - Flags: review?(philipp)
Attachment #8792377 - Flags: review?(philipp) → review+
https://hg.mozilla.org/comm-central/rev/6497b3aa36e15daf7bc6828c2e9e421f33e95b6d
Bug 1293943 - l10n nightlies busted on wget-en-US. r=Fallen a=ewong
Blocks: 1304284
Looks like this unhorked the wget-en-US rule.  So closing.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Depends on: 1306191
Blocks: SM2.46
Blocks: 1306191
No longer depends on: 1306191
You need to log in before you can comment on or make changes to this bug.