> On May 31, 2016, at 5:09 AM, Axel Rau <axel....@chaos1.de> wrote: > > >> Am 30.05.2016 um 22:39 schrieb Axel Rau <axel....@chaos1.de>: >> >> connection.realConnection.py_types[postgres.six.text_type] = (705, >> postgres.core.FC_TEXT, my_text_out) >> exceptions.AttributeError: ‚module' object has no attribute 'six‘ > I removed that line: ... > pg8000.core.ProgrammingError: (u'ERROR', u'42P01', u'relation > "calendarserver" does not exist', u'19', u'parse_relation.c', u'986', > u'parserOpenTable', u'', u'') > 2016-05-31T12:48:55+0200 [calendarserver.tap.util#critical] Step failure: > UpgradeDatabaseAddressBookDataStep > - - - > I have created an empty database and expected caldavd to create all the > necessary tables. > Is this wrong?
Nope, that's a perfectly valid expectation. I'm pretty sure the 'six' module is actually required, however. It seems reasonable to guess that this might be yet another startup-time race condition around when a module is imported versus when it is used. Considering the attempt to fix this in a different place has already failed, more investigation is required... I don't have any immediate suggestions other than to maybe try to find a way to get the previously suggested patch to work, then apply the same technique in other areas as needed... not terribly clean, I know. -dre > > Axel > --- > PGP-Key:29E99DD6 ☀ computing @ chaos claudius > > _______________________________________________ > calendarserver-dev mailing list > calendarserver-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-dev _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
