Red Hat Bugzilla – Bug 237137
Package Request: thunderbird lightning plugin for calendar synchronization
Last modified: 2014-03-16 23:06:20 EDT
Can the lightning plugin for thunderbird be packaged for fedora?
I also vote for it!
the main problem is twofold.
first of all a lightning addon build takes more then a kernel or gcc compile!
second fedora thunderbird compile configuration is different from the default
mozilla thunderbird config. which means the lightning plugin downloadable from
mozilla plugins download page:
is not working on fedora (which means it's installable but not working properly).
so it's very desirable to add lightning build to thunderbird.
anyway for those who'd like to use lightning on fedora 7, here is my version:
Levente, is there any chance that you could provide a build for x86_64 as well?
No thunderbird-devel package yet. This might need to be F8 material.
You can use the thunderbird extension from www.mozilla.com without any problem.
Do we really need a separate package for each extension? No need to custom
compile for Fedora.
Lightning Nightly Linux Builds:
Is it available for every arch we support? Does it run against older versions
of e.g. glibc?
In short, no - Mozilla don't appear to build for x86_64. There was a
user-contributed x86_64 build for 0.3, but not for 0.3.1 (the current release)
and it didn't work on my system (FC6).
Then we probably do need a custom version. Unfortunately, because of the gecko
story, we have no good way to do this right now. This requires a major change
(XULRunner) which we will be doing for FC8. I might be able to backport to FC7
and older depending on how well that goes.
I've added two Mozilla bugs that would make this bug irrelevant. Wouldn't it be
more useful to help the Lightning team directly rather than package a custom RPM
for Fedora only?
There's no way to guarantee that the build will run on all current distros
equally well because of dependencies, filesystem structure, etc.
Lightning doesn't require any special dependencies. As long as you have
Thunderbird installed -- it will work.
It doesn't require any special file structure.
This bug is just to get a 64-bit version of Lightning built because the
Lightning folks haven't done it. It's a typical user add-on for Thunderbird with
a small binary piece. Nothing more.
Link-time dependencies are still dependencies. See for example Google Toolbar.
It is just a small binary but doesn't work with Fedora 7 because it was built
against an old toolchain. Building against a newer toolchain would mean that it
wouldn't work with older distros.
This gets a vote from me, it is a real bind not being able to use lightning in F7.
mike your comment is simple not true. have you ever try mozilla build of
lightning? they are _not_ working on neither fc6 nor f7. and if you read my
mozilla response to my mail they do not even plan a build which works for
fedora. anyway the latest 0.5 build for f7 can be found:
0.5 works well while 20070707 build contains the new layout but for me (with
large .ics files) this version is very slow.
the best would be to add a subpackage to thunderbird and simple build along with
it. i can send a patch to the spec file:-)
0.7 builds of lightning don't work on f7 either.
I have a patch to the thunderbird spec file to build lightning as well, which
I'm going to attach.
I would argue that lightning is a special case of an extension anyway, since the
default build instructions seem to require building the whole of thunderbird, so
this seems the best way to do it.
Created attachment 241791 [details]
Patch to enable building lightning together with thunderbird
This is a patch to the thunderbird specfile to enable building lightning
together with thunderbird
I'll also attach the actual specfile and the thunderbird-mozconfig-lightning
file which simply adds the configuration file
Created attachment 241801 [details]
Extra mozconfig file that includes the switch to enable building the extension
Created attachment 241811 [details]
The actual modified specfile to build thunderbird 126.96.36.199 and lightning 0.7
And here's the actual specfile.
(the thunderbird rpms are basically unchanged but included for completeness -
these are still uploading as I submit this...)
Mozilla doesn't release an actual source archive for Lightning, so I created
one from cvs as described in the specfile, available here:
Any comments on the above appreciated - should I ask for review?
Some relevant links on the default Lightning not working with Fedora:
Added request for review on patch
I think, that currently this being not full blown package review should fit more
into component "distribution".
Do I need to re-request review on this patch after it being moved between
We are not going to build extensions from within the thunderbird SRPM.
I'm working on fixing how we do extensions, but right now, there's no good way
to do this.
Re Comment 25:
I sure agree that we shouldn't build extensions in general from the thunderbird
SRPM. Lightning is different because:
A) It's in the Mozilla codebase
B) It's one of the few official extensions produced by Mozilla
C) There are key reasons it's built like this (it's essentially a part of
thunderbird that's stripped from the default build)
I can understand though if you don't want to do this. But would it be acceptable
then to make a separate SRPM for lightning that includes the thunderbird source
code, builds thunderbird and lightning, and discards the thunderbird build?
Otherwise it's pretty much making it impossible for Fedora users to have a
decent lightning install
Believe me, I understand how lightning is not your average extension, but it's
still an extension. The distributor is a little irrelevant here to the reasons
why we can't take it like this.
I don't think it's feasible either to essentially duplicate the thunderbird
source tree in a different SRPM because:
* A system installed extension in the current way of doing things would have to
reside within the thunderbird application directory, which changes with each new
version currently ($LIBDIR/thunderbird-$version). This means there would be RPM
conflicts if both aren't upgraded simultaneously, or you would lose the
extension on upgrades.
* It is an additional burden to sync two trees up identically. Every time I
patch our thunderbird RPM, lightning really should get the same patch, and vice
versa to keep things in optimal sync, especially on these versions where there
isn't a guaranteed stable API.
* It is extra work for releasing security updates which are not infrequent,
especially because of the two above items.
I promise you I'm working on the code to do this the correct way. I attached
the patch upstream yesterday in fact, and so far has received positive comments,
so it should be accepted soon I hope. I'm pushing hard for it. The only
drawback is I'm not sure how doable it would be to port it to FC8 or 7. It
might have to be an FC9+ thing... But I'll see what I can do.
OK, presume you're talking about
https://bugzilla.mozilla.org/show_bug.cgi?id=311008 - that looks great.
All the specific lightning issues still remain though - unless we make it
possible to build lightning entirely independently of thunderbird, which still
doesn't necessarily mean we'll avoid any need for version updates.
So given your points in Comment 27, do you have a proposal for how this should
Making it build independently is not a difficult problem to solve, but it
doesn't do any good if there's no place to stick it. That's why 311008 is so
*** Bug 429339 has been marked as a duplicate of this bug. ***
(In reply to comment #29)
> Making it build independently is not a difficult problem to solve, but it
> doesn't do any good if there's no place to stick it. That's why 311008 is so
Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=311008 has been
checked in (but presumably we need to wait for this to percolate up to the
Sorry für the noise but isn't this bug a duplicate of #357661? The sunbird
package in EPEL5 does already include thunderbird-lightning
Building and will push the package shortly
*** This bug has been marked as a duplicate of 357661 ***