Two changes pushed to master

ellie timoney ellie at fastmail.com
Tue Jun 21 20:43:58 EDT 2016


I'm still getting grief from the two Caldav sharing tests:

sharing_samedomain: https://paste.fedoraproject.org/382871/66554226/
sharing_crossdomain: https://paste.fedoraproject.org/382872/14665543/

I've had a good deep dig into the error report, and it really looks like
Cyrus just isn't returning the shared calendars.

Looking specifically at sharing_samedomain for now, here's the part of
the test where things start going awry:

>     $talk2->NewAddressBook("Shared", name => "Shared Address Book");
>     $admintalk->setacl("user.user2.#addressbooks.Shared\@example.com", "user1\@example.com", 'lrsn');
> 
>     my $Addressbooks = $talk1->GetAddressBooks();
> 
>     $self->assert_deep_equals([
>           {
>             'name' => 'personal',
>             'isReadOnly' => 0,
>             'path' => 'Default',
>             'href' => '/dav/addressbooks/user/user1 at example.com/Default/'
>           },
>           {
>             'path' => '/dav/addressbooks/zzzz/user2 at example.com/Shared',
>             'href' => '/dav/addressbooks/zzzz/user2 at example.com/Shared/',
>             'name' => 'Shared Address Book',
>             'isReadOnly' => 1,
>           }
>         ], $Addressbooks);

=> create a new addressbook "Shared" on user2
=> give user1 "lsrn" rights to it
=> look up user1's address books
=> expect to find user1's "Default" addressbook, and user2's "Shared"
addressbook

The output from these actions starts at line 201 (which fpaste doesn't
let me link directly to, doh).

You can see it creating the addressbook (201 Completed), setting the acl
(OK Completed), and then it asks for user1's addressbooks:

> <<<<<<<< PROPFIND http://127.0.0.1:9100/dav/addressbooks/user/user1@example.com/ HTTP/1.1
> <D:propfind xmlns:D='DAV:' xmlns:C='urn:ietf:params:xml:ns:carddav'><D:prop><D:displayname/>
> <D:resourcetype/><D:current-user-privilege-set/></D:prop></D:propfind>
> >>>>>>>> HTTP/1.1 207 Multi-Status

And the response XML (with the long lists of privileges snipped out, for
readability):

> <?xml version="1.0" encoding="utf-8"?>
> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"
> xmlns:XFA68="urn:ietf:params:xml:ns:caldav" xmlns:CY="http://cyrusimap.org/ns/">
>   <D:response>
>     <D:href>/dav/addressbooks/user/user1 at example.com/</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:resourcetype>
>           <D:collection/>
>         </D:resourcetype>
>         <D:current-user-privilege-set>
>           [snip]
>         </D:current-user-privilege-set>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>     <D:propstat>
>       <D:prop>
>         <D:displayname/>
>       </D:prop>
>       <D:status>HTTP/1.1 404 Not Found</D:status>
>     </D:propstat>
>   </D:response>
>   <D:response>
>     <D:href>/dav/addressbooks/user/user1 at example.com/Default/</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:displayname><![CDATA[personal]]></D:displayname>
>         <D:resourcetype>
>           <D:collection/>
>           <C:addressbook/>
>         </D:resourcetype>
>         <D:current-user-privilege-set>
>           [snip]  
>         </D:current-user-privilege-set>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>

There are two responses in this:

  * one for user1's top level (the "addressbook-home-set"? I don't think
  NetCardDAVTalk includes this in the returned list of addressbooks)
  * one for user1's "Default" calendar

But there's no response in the XML containing the expected "Shared"
addressbook, and so we get the test failure:

>  Structures begin differing at:
>   $a->[1] = 'HASH(0x455c428)'
>   $b->[1] = Does not exist
>  at Cassandane/Cyrus/Carddav.pm line 328.

Index 0 is OK - it contains user1's Default calendar.  But index 1,
which we expect to contain user2's Shared calendar, doesn't exist.

This doesn't seem to be a perl module problem -- it's not that the perl
module is mishandling the response, it's that Cyrus is not providing the
expected response.

On a hunch, I tried running Cassandane across fm/future, thinking maybe
there was a relevant Cyrus commit that hadn't been sent upstream yet...
but it fails in the same way.

Any ideas?

Anyone else finding these two tests failing?

On Mon, May 16, 2016, at 11:37 AM, ellie timoney via Cyrus-devel wrote:
> On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote:
> > Are you running the latest version of all the perl modules?  I suspect I
> > have
> > pushed more recent versions to CPAN that fix these - there were a bunch
> > of
> > things that required perl module fiddling.
> 
> I think so, at least the DAV ones and their dependencies:
> 
> => Net::DAVTalk 0.09 (from CPAN)
> => Net::CardDAVTalk 0.03 (from CPAN)
> => Net::CalDAVTalk 0.05+1 (from github)
> 
> The last updates to these on CPAN were a couple of weeks ago, on 2nd and
> 3rd of May. These are the versions I have.
> 
> I'm using a version of Net::CalDAVTalk from github because it's one
> commit ahead of CPAN (fixes missing "_method", which caused most of the
> Caldav tests to fail with the CPAN version).


More information about the Cyrus-devel mailing list