533070 - Sunbird nightly builds fail with |No rule to make target .../calendar/sunbird/branding/nightly/Makefile.in|

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Stefan Sitter [:ssitter]]

Sunbird builds fail after the checkin for Bug 532656.

make[4]: *** No rule to make target `/e/buildbot/comm-1.9.1-sunbird-win32/build/calendar/sunbird/branding/nightly/Makefile.in', needed by `calendar/sunbird/branding/nightly/Makefile'.  Stop.

make[3]: *** [export_tier_app] Error 2
make[2]: *** [tier_app] Error 2
make[1]: Leaving directory
`/e/buildbot/comm-1.9.1-sunbird-win32/build/objdir-tb'
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: WiP Patch - v1

We should redo our branding similar to how Thunderbird did. The idea is to mirror the branding directory in /other-licenses/branding/sunbird at /calendar/sunbird/branding/nightly.

I came across a few files I'm not sure are still being used. These are:

- Header.bmp     (Windows, isn't wizHeader enough?)
- Watermrk.bmp   (Windows, not used by Thunderbird?)
- watermark.png  (Linux, probably the ex- installer)
- header.png     (Linux, probably the ex- installer)
- app.ico        (What is this used for?)
- document.ico   (What is this used for?)

The patch is WiP, I've done some basic testing (full build + starting app)  but wanted to get this up so you know something is happening here. I'd appreciate if someone (ssitter? mschroeder?) could test the build on windows and mac.

Nevertheless requesting review from Standard8, since he redid the Thunderbird branding and can best say if I'm doing the right thing.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> Created an attachment (id=416272) [details]
> WiP Patch - v1

Initial comments:

- With this patch you're defining MOZ_USE_GENERIC_BRANDING in Makefiles that are no longer necessary: http://mxr.mozilla.org/comm-central/search?string=MOZ_USE_GENERIC_BRANDING

My mac build with official branding seemed fine. I've queued up try-server builds of official & unofficial, so some of them should be around in a few hours.

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v2

* Removed all instances of MOZ_USE_GENERIC_BRANDING
* Checked all other MOZ_BRANDING_DIRECTORY occurrences, it seems we don't use the OFFICIAL_BRANDING define either.

I'll try to get these through the tryserver again, now that its fixed for calendar.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v3

Forgot a Makefile, new Tryserver builds building. Windows fails due to bug 533418.

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 416546 [details] [diff] [review]
Fix - v3

>diff --git a/calendar/sunbird/app/Makefile.in b/calendar/sunbird/app/Makefile.in

> ifneq (,$(filter gtk gtk2,$(MOZ_WIDGET_TOOLKIT)))
> ICON_FILES = \
>-    $(DIST)/branding/mozicon128.png \
>-    $(DIST)/branding/mozicon50.xpm \
>-    $(DIST)/branding/mozicon16.xpm \
>+    $(DIST)/branding/default128.png \
>+    $(DIST)/branding/default50.xpm \
>+    $(DIST)/branding/default16.xpm \
>     $(NULL)
> 
>-libs:: $(ICON_FILES)
>-	$(INSTALL) $^ $(DIST)/bin/icons
>+libs::
>+	$(INSTALL) $(ICON_FILES) $(DIST)/bin/icons
> 
> install::
> 	$(SYSINSTALL) $(IFLAGS1) $(ICON_FILES) $(DESTDIR)$(mozappdir)/icons
> endif
> 
> ifeq ($(MOZ_WIDGET_TOOLKIT),gtk2)
> libs::
> 	$(INSTALL) $(DIST)/branding/default.xpm $(DIST)/bin/chrome/icons/default
> 
> install::
> 	$(SYSINSTALL) $(IFLAGS1) $(DIST)/branding/default.xpm $(DESTDIR)$(mozappdir)/chrome/icons/default
> endif

We don't support gtk now (it is only gtk2 that we support), so you could just do what we do in mail/app/Makefile.in:

ifeq ($(MOZ_WIDGET_TOOLKIT),gtk2)
libs::
        $(INSTALL) $(IFLAGS1) $(DIST)/branding/default* $(DIST)/bin/chrome/icons
/default

install::
        $(SYSINSTALL) $(IFLAGS1) $(DIST)/branding/default* $(DESTDIR)$(mozappdir
)/chrome/icons/default
endif



>diff --git a/calendar/sunbird/branding/nightly/content/Makefile.in b/calendar/sunbird/branding/nightly/content/Makefile.in

>+include $(DEPTH)/config/autoconf.mk
>+
>+DEFINES += -DAB_CD=$(AB_CD) -DMOZ_DISTRIBUTION_ID_UNQUOTED=$(MOZ_DISTRIBUTION_ID)
>+
>+include $(topsrcdir)/config/rules.mk

You don't need those defines as you're not processing anything in the jar.mn (and you don't need the makefile if you follow my comment below).

>diff --git a/calendar/sunbird/branding/nightly/content/jar.mn b/calendar/sunbird/branding/nightly/content/jar.mn

Save yourself a little bit of build time, and just put this as calendar/sunbird/branding/nightly/jar.mn.

>diff --git a/calendar/sunbird/branding/nightly/locales/Makefile.in b/calendar/sunbird/branding/nightly/locales/Makefile.in

>+# relativesrcdir = mail/branding/unofficial/locales TODO ???

Hmm, so that is at least wrong, if not useless as well, probably worth just dropping it and seeing if anything breaks ;-)

>+include $(DEPTH)/config/autoconf.mk
>+
>+DEFINES += -DAB_CD=$(AB_CD) -DMOZ_DISTRIBUTION_ID_UNQUOTED=$(MOZ_DISTRIBUTION_ID)

You don't need MOZ_DISTRIBUTION_ID_UNQUOTED, I know TB has it, but we don't need it either ;-)

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #1)
> I came across a few files I'm not sure are still being used. These are:

It is probably worth fixing the files in follow-up bugs although I agree some of them seem unused now.

Comment 7

[Mark Banner (:standard8)]

Comment on attachment 416546 [details] [diff] [review]
Fix - v3

I've not tested this, but I've given it a good look through, r=Standard8 with the changes mentioned in my earlier comment.

Comment 8

[Stefan Sitter [:ssitter]]

I tested patch "Fix - v3" against comm-1.9.1/mozilla-1.9.1 on Windows. 
The build succeeded for both official and generic branding.

Comment 9

[Tony Mechelynck [:tonymec]]

In reply to comment #1
I don't think the following has been answered above, but sorry if it has.

Aren't app.ico and document.ico the icons present inside the Windows GUI executable? app.ico to be displayed in the topleft corner of the window and on the taskbar, and then document.ico for "documents" whose default handler is this app?

Comment 10

[Thomas Lauria]

I applied patch "Fix - v3" on comm-1.9.1 on Linux amd64. 
The build succeeded. I build only once, with --disable-official-branding set.

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v4

Review comments taken into account, checking this one in.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/f3b17956ae4c>
and comm-191 <http://hg.mozilla.org/releases/comm-1.9.1/rev/af8a37ce75bf>

-> FIXED

Comment 13

[Stefan Sitter [:ssitter]]

The buildbot "WINNT 5.2 comm-1.9.1 sunbird build %" is still failing with the same error: <http://tinderbox.mozilla.org/showbuilds.cgi?tree=Calendar1.0>
Linux and Mac seems to build fine.

Comment 14

[Tony Mechelynck [:tonymec]]

(In reply to comment #13)
> The buildbot "WINNT 5.2 comm-1.9.1 sunbird build %" is still failing with the
> same error: <http://tinderbox.mozilla.org/showbuilds.cgi?tree=Calendar1.0>
> Linux and Mac seems to build fine.

Yes, that's the only non-green column on the Calendar1.0 waterfall ATM. On Linux, the Sb nightly installs and reads my calendars the way it should.

Comment 15

[Tony Mechelynck [:tonymec]]

P.S.
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8pre) Gecko/20091223 Calendar/1.0b2pre
Build ID: 20091223030938

Comment 16

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Both windows machines are failing due to "SIGKILL failed to kill process". I don't see the current error message?

The mac machines are failing due to some install.rdf merge error I can't quite explain.

Do we have separate bugs to fix these issues? if not we should file them.