Created attachment 265443 [details] emerge --info Current thunderbird with lightning add-on often forgets about my remote calendars. Restarting the app does make them reappear, but simply reloading them doesn't. Web server is a apache with mod_dav running on localhost. The calendars are configured as remote iCal files stored on a http (DAV) server. It seem sthat the first time TB tries an automatic refresh, it gets a "304 Not Modified" response, and incorrectly clears the calendars in response to that. Steps to Reproduce: 1. Condigure a DAV calendar on an (preferrably unencrypted) HTTP server 2. Open Edit / Preferences / Lightning / General 3. Enable refresh and set the timeout to 1 minute 4. Restart TB 5. Start wireshark 6. Wait a bit over one minute 7. Observe that the Tasks pane in TB is suddenly empty 8. Switch to the Lightning tab, and observe that it is empty as well.
6a. observe that wireshark will show you the 304 Not Modified responses from the DAV server.
Perhaps upstream https://bugzilla.mozilla.org/show_bug.cgi?id=389281 is to blame. There the calendar is cleared whenever the response has length zero, without taking the status code into account. Reported this upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=640920
Created attachment 265907 [details, diff] upstream patch modified to apply cleanly
Created attachment 265909 [details] ebuild with patch
Instead of the tweaked patch and modified ebuild, the following is enough for users that want the fix before it enters the main portage tree: # mkdir -p /etc/portage/patches/mail-client/thunderbird-3.1.9 # wget \ -O /etc/portage/patches/mail-client/thunderbird-3.1.9/fce654340106.patch \ http://hg.mozilla.org/releases/comm-1.9.2/raw-rev/fce654340106 At least on my system that worked just as well. A fix in portage would obviously be preferable, though, and for that we do need a modified ebuild. Maintainers might perhaps prefer an ebuild diff. I think the upstream commit is clean enough, as applying its patch generated no error messages for me. Why did you see need for a modification to the patch?
Hunk #3 didn't apply cleanly for me (manually using the patch command and having portage do it), hence having the need to manually apply the patch then generating the patch I've previously attached.
You know what, looking back I think my problem was that I applied a different patch from you. I had applied https://bugzilla.mozilla.org/attachment.cgi?id=518903 which I thought was the one to use since it was newer, but wasn't actually the one checked in. So the link you provided in comment #5 is probably the one to actually use.
(In reply to comment #7) > You know what, looking back I think my problem was that I applied a different > patch from you. I had applied 518903 which I thought was the > one to use since it was newer, but wasn't actually the one checked in. That seems to be checked in as 60833e1149eb for comm-central, their main development branch, while my link was to the version backportet to the comm-1.9.2 branch, which corresponds to the thunderbird version in question.
This is more or less fixed as 3.1.10 doesn't seem to have this problem and is stable on the same arches as 3.1.9.
Marking as FIXED as per previous comment.
