kopano-search no longer starting ...

fbartels

ok, then lets just assume that you are running from the final branch, which means you must currently be on 8.4.4 and theoretically speaking must have run 8.4.3 before.

There was no related change to kopano-search between these two versions: https://documentation.kopano.io/kopano_changelog/kc.html#kopano-core-8-4-4-8-4-4-0

troubleticket

<sigh> … means to me, I have to search the reason for this in any of the other updated Debian-Packages, haven’t I … <sigh>

Thanks anyway

Joe

umgfoin

Hi @troubleticket ,
I’d try to delete pre-compiled python-files, first:
Recursively remove all *.pyc in folders like /usr/lib/python2.7/dist-packages/kopano*, then restart kopano-search and check results again.

++umgfoin.

troubleticket

Hi @umgfoin ,

thanks for another light at the end of the tunnel (or at least in the tunnel) … ;o)

Does this affect any other parts of kopano-core?
I see five(5) .pyc’s in a folder “kopano-search” but 47 all in all …?

Are these precompiled’s be rebuilt later automagically?

Thanks for helping.

Joe

umgfoin

@troubleticket said in kopano-search no longer starting ...:

Does this affect any other parts of kopano-core?…?

No. Precompiled byte-code (.pyc) only loads, but never executes faster than its plaintext counterpart. So you might notice - if any - only a difference at first access.

Are these precompiled’s be rebuilt later automagically?

Yes, they’ll get rebuilt upon first call of the corresponding .py-script/ module.

++umgfoin.

umgfoin

@troubleticket said in kopano-search no longer starting ...:

I see five(5) .pyc’s in a folder “kopano-search” but 47 all in all …?

Delete them all e.g. find . -name "*.pyc" -delete and start in /usr/lib/python2.7/dist-packages

troubleticket

Hi @umgfoin ,

… deleted everything like you suggested, checked: no more .pyc’s …
-> no change in behavior: kopano-seach woń’t start, messages the same …

… no idea … =o(

Greetings, thanks …

Joe

umgfoin

OK,
next step:

Locate file /usr/lib/python2.7/dist-packages/MAPI/Tags.py and check if a line like

PR_EXTENDED_FOLDER_FLAGS = PROP_TAG(PT_BINARY, 0x36DA) # following specs

is present.

++umgfoin

troubleticket

Hi @umgfoin ,

nope, no such line … <hope arisin’> … =o}

Joe

umgfoin

@troubleticket said:

<hope arisin’> … =o}

…not sure ;-)
I’d say atleast, package python-mapi didn’t upgrade, correctly. You might reinstall this package, but possibly other (/kopano-search/python-)packages are concerned, too.

Btw., where did you install this from? As of today, I can’t see any Debian7-core-packages under community-downloads.

++umgfoin

troubleticket

@umgfoin ,

this kopano installation I maintain for a friend of mine who has a small office of his own, and he has an account for the official repositories, which (as mentioned above) were without debian7-versions for quite some week, whereafter these suddenly reappeared.

I’ll give it a try and reinstall python-mapi … oooops …:

Besides lots of other “libmapi1 php5-mapi python-mapi” are kept back from being updated by “apt-get”???
I suppose, this is been setup by kopano, isn’t it …?

Regards and lots of thanks for your time!

Joe

troubleticket

Hi everyone,

I got the problem solved: It was my misunderstanding of “kept back” and “hold”.
All packages are now being installed manually/updated correctly and kopano-search is working again.

Thanks @umgfoin for leading my eyes to the malfunction of upgrades, and to everyone else for reading, thinking, answering, helping.

Regards

Joe