Closed Bug 533070 Opened 10 years ago Closed 10 years ago

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

Categories

(Calendar :: Sunbird Only, defect, blocker)

defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ssitter, Assigned: Fallen)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 3 obsolete files)

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
Attached patch WiP Patch - v1 (obsolete) β€” β€” Splinter Review
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.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #416272 - Flags: review?(bugzilla)
(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.
Attached patch Fix - v2 (obsolete) β€” β€” Splinter Review
* 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.
Attachment #416272 - Attachment is obsolete: true
Attachment #416531 - Flags: review?(bugzilla)
Attachment #416272 - Flags: review?(bugzilla)
Attached patch Fix - v3 (obsolete) β€” β€” Splinter Review
Forgot a Makefile, new Tryserver builds building. Windows fails due to bug 533418.
Attachment #416531 - Attachment is obsolete: true
Attachment #416546 - Flags: review?(bugzilla)
Attachment #416531 - Flags: review?(bugzilla)
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 ;-)
(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 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.
Attachment #416546 - Flags: review?(bugzilla) → review+
Summary: Builds fail with |No rule to make target .../calendar/sunbird/branding/nightly/Makefile.in| → Sunbird nightly builds fail with |No rule to make target .../calendar/sunbird/branding/nightly/Makefile.in|
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.
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?
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.
Attached patch Fix - v4 β€” β€” Splinter Review
Review comments taken into account, checking this one in.
Attachment #416546 - Attachment is obsolete: true
Attachment #418869 - Flags: review+
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
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
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.
(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.
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
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.
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.