Lightning can not be installed if SeaMonkey is not build with enable-calendar

NEW
Unassigned

Status

enhancement
--
critical
2 years ago
2 years ago

People

(Reporter: frg, Unassigned)

Tracking

SeaMonkey 2.49 Branch
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.49esr affected, seamonkey2.55 affected)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

2 years ago
Lightning is using some binary components (libical and some backend cpp files. Binary components were discontinued so starting with TB 52 they were linked into libxul. Bug 1318258 covers this.

SeaMonkey releases are currently build without calendar because we still have not solved the l10n repack bug 1231349.

The consequence is that the binary components are not build and the current Lightning on AMO does not work or better is completly broken. You will see various failues in the preferences and processing. The same would occur if you build TB without calendar.

The solution would be to always build the binary components for later use.
Reporter

Updated

2 years ago
Reporter

Comment 1

2 years ago
Posted patch 1402645-249-relbranch.patch (obsolete) — Splinter Review
Patch for 2.49.1 SeaMonkey comm-esr52 relbranch only. Verified working on Linux and Windows x64.

Workaround only. Can not be used in a normal production branch because this would break building Lightning.
Attachment #8911512 - Flags: review?(iann_bugzilla)
Attachment #8911512 - Flags: feedback?(ewong)
Reporter

Comment 2

2 years ago
Fallen,

I assume the binary components are here to stay. Shouldn't the calendar tree be refactored in light of this? If you think yes I can try to fix this properly.

Maybe Lightning should be dropped as an add-on and always be build into both TB and SM? The current setup will probably completly break in the near future with the current Gecko api removals and changes.
Flags: needinfo?(philipp)
Reporter

Comment 3

2 years ago
Posted file configurerrror.txt
ewong configure output error with the jars still in the tree.
Attachment #8911790 - Flags: feedback?(ewong)
Comment on attachment 8911790 [details]
configurerrror.txt

And this is with the following change only?

-if CONFIG['MOZ_CALENDAR']:
-    DIRS += [
+DIRS += [
         '/calendar/lightning',
-        '/calendar/timezones'
-    ]
+]

What about just:
diff --git a/suite/app.mozbuild b/suite/app.mozbuild
--- a/suite/app.mozbuild
+++ b/suite/app.mozbuild
@@ -10,18 +10,13 @@ include('/toolkit/toolkit.mozbuild')
 if CONFIG['MOZ_EXTENSIONS']:
     DIRS += ['/extensions']

 if CONFIG['MOZ_COMPOSER']:
     DIRS += ['/editor/ui']

 DIRS += ['/%s' % CONFIG['MOZ_BRANDING_DIRECTORY']]

-if CONFIG['MOZ_CALENDAR']:
-    DIRS += [
-        '/calendar/lightning',
-        '/calendar/timezones'
-    ]

 DIRS += [
     '/xpfe/components/autocomplete',
     '/suite',
 ]
Attachment #8911790 - Flags: feedback?(ewong)
Comment on attachment 8911512 [details] [diff] [review]
1402645-249-relbranch.patch

I am not 100% sure the need to do a wholesale removal of those files.  As
mentioned in comment #4, with the removal of the if CONFIG['CALENDAR']: part
of app.mozbuild, I believe it is sufficient to disable calendar.
Attachment #8911512 - Flags: feedback?(ewong) → feedback-
Reporter

Comment 6

2 years ago
Added back some parts which I think are safe, did a fresh compile and retested it. Some other parts could, for sure, be added back to the moz.build files too but every full compile with at least two languages is a 40 minutes round trip + test and so I just consider it working fine for now unless the real build breaks :) Happy to test other patches if needed.

As before only for the SeaMonkey relbranch in comm-esr52 and needs to be backed out when we are finally solve the l10n bug.
Attachment #8911512 - Attachment is obsolete: true
Attachment #8911512 - Flags: review?(iann_bugzilla)
Attachment #8912293 - Flags: review?(iann_bugzilla)
Attachment #8912293 - Flags: feedback?(ewong)
Attachment #8912293 - Flags: approval-comm-esr52?
Comment on attachment 8912293 [details] [diff] [review]
1402645-249-relbranch-V2.patch

Well, it builds..
Attachment #8912293 - Flags: feedback?(ewong) → feedback+

Comment 8

2 years ago
Comment on attachment 8912293 [details] [diff] [review]
1402645-249-relbranch-V2.patch

If you are removing the JAR_MANIFESTS += ['jar.mn'] lines from the moz.build files, do you actually need to remove the jar.mn files?
r/a=me for comm-esr52
Flags: needinfo?(frgrahl)
Attachment #8912293 - Flags: review?(iann_bugzilla)
Attachment #8912293 - Flags: review+
Attachment #8912293 - Flags: approval-comm-esr52?
Attachment #8912293 - Flags: approval-comm-esr52+
Reporter

Comment 9

2 years ago
> do you actually need to remove the jar.mn files?

Unfortunately yes see attachment in comment 3.
Flags: needinfo?(frgrahl)
Reporter

Comment 10

2 years ago
SEAMONKEY_2_49_ESR_RELBRANCH only:

https://hg.mozilla.org/releases/comm-esr52/rev/684e4c349de07eb06ac08120fbfdc74d6b42d29b

Leaving the bug open for finding a permanent solution.
(In reply to Frank-Rainer Grahl (:frg) from comment #2)
> Fallen,
> 
> I assume the binary components are here to stay. Shouldn't the calendar tree
> be refactored in light of this? If you think yes I can try to fix this
> properly.
I don't see myself finding any time to work on the ical.js port soon, so even though it is just a hack what we currently do, it is indeed here to stay.

Refactoring the source files for the binary component into a separate directory would substantially rip out files that are only really useful for Lightning. I think I'd prefer to keep them in place, but you can of course add the specific directory with binary files for compiling in even without enable-calendar.


> 
> Maybe Lightning should be dropped as an add-on and always be build into both
> TB and SM? The current setup will probably completly break in the near
> future with the current Gecko api removals and changes.

Until the add-on APIs break I think this is not necessary.
Flags: needinfo?(philipp)
You need to log in before you can comment on or make changes to this bug.