caldav free-busy query is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
evolution-data-server (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
A couple of bugs are present which make CalDAV scheduling effectively useless - the combined effect of them is that everyone else shows as having your availability information, rather than their own.
I have patched the bugs upstream, and they have been merged into the branches for both 3.30.4 and 3.31.4:
* https:/
* https:/
I'm hoping to backport these patches to bionic, which packages 3.28 -- I will submit such a debdiff later today. I am submitting here rather than to Debian as the versions of this package in Debian are out of lockstep with Ubuntu's, so the patch doesn't cleanly transfer -- let me know if this is the wrong approach.
Cosmic is on the 3.30 release series, which I assume means the fix will come from upstream and doesn't need to be applied here, but let me know if I should do a patch for that as well.
Thanks :)
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: evolution-
ProcVersionSign
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Dec 12 22:05:38 2018
InstallationDate: Installed on 2018-12-10 (1 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: evolution-
UpgradeStatus: No upgrade log present (probably fresh install)
I have added a patch which applies both upstream merge requests linked above. I was not above to successfully set up pbuilder, but built and tested it successfully with debuild in a bionic VM. Subscribing ubuntu-sru in accordance with http:// packaging. ubuntu. com/html/ security- and-stable- release- updates. html as I'm pretty sure the change I'm requesting would be a stable release update.
Aiming justify that update: this is a significant regression because somewhere between Xenial and Bionic, this caldav freebusy code was rewritten and broken. Additionally somewhere in that timeframe the behavior changed from using the address book's FBURL to using this caldav-based technique (which, again, doesn't work :)