upgrade from 3.3 to 3.4 on debian 7 x64 breaks email (wallace at fault?)

[Matthias Busch]

Update...

tl;dr:
mail works, problem found, my fault
freebusy still not working, dont know why



it was indeed wallace "blocking" the mail.
when the wallace footer text/html filepath is missing in kolab.conf 
(even if they dont exist) wallace goes belly up

pykolab.log excerpt:
----------------------
2015-03-08 00:35:56,562 pykolab.conf WARNING Die Option 
wallace/footer_html existiert in der Konfigurationsdatei 
/etc/kolab/kolab.conf nicht, sie wird aus den Standardeinstellungen geholt
2015-03-08 00:35:56,563 pykolab.conf WARNING Diese Option hat keinen 
Standardwert.
2015-03-08 00:35:56,563 pykolab.conf WARNING Die Option 
wallace/footer_text existiert in der Konfigurationsdatei 
/etc/kolab/kolab.conf nicht, sie wird aus den Standardeinstellungen geholt
2015-03-08 00:35:56,563 pykolab.conf WARNING Diese Option hat keinen 
Standardwert.
2015-03-08 00:35:56,564 pykolab.wallace ERROR Module footer.execute() 
failed on message 
'/var/spool/pykolab/wallace/invitationpolicy/incoming/tmpkqSdnh' with 
error: Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/wallace/__init__.py", line 65, 
in pickup_message
     result_filepath = modules.execute(module, filepath)
   File "/usr/lib/python2.7/dist-packages/wallace/modules.py", line 116, 
in execute
     return modules[name]['function'](*args, **kw)
   File "/usr/lib/python2.7/dist-packages/wallace/module_footer.py", 
line 79, in execute
     if not os.path.isfile(footer_text_file) and not 
os.path.isfile(footer_html_file):
   File "/usr/lib/python2.7/genericpath.py", line 29, in isfile
     st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, NoneType found
--------------------------

dont really know what those files are supposed to do. but I now know the 
path must stay in the kolab.conf :)

warning but still works:
2015-03-08 00:39:18,226 pykolab.wallace WARNING No contents configured 
for footer module

--------------------------------------
freebusy via thunderbird doesnt work

the addon is pulling freebusy info via:
https://domain.tld/freebusy/user.ifb

login:
login is either via UID or primary email (tested with browser: access 
granted)

user / pulling data:
I tried user with uid and primary email and a username that does not exist
- uid --> dummy vfreebusy
- primary email --> dummy vfreebusy
- not exist --> dummy vfreebusy

in webmail it seems to work.
I created a whole day engagement (today) for user B
when I look at freebusy for user b today I get all clear
when I look at freebusy for user b tomorrow I get busy where there are 
previous dates set

I am assuming that either whole-day engagements do not trip freebusy 
(they should) or (and more likely) freebusy is not pulling live data 
when accessed but using cached data.
never noticed a time lag in 3.3 and if it is indeed the case here, I 
would like to go back to "live data" if possible...

freebusy.log is empty

any ideas about .../freebusy/x.ifb not giving data?
any ideas about the (possible) time lag?