Problems with Webapp 3.5.7 - could not send mails

wesser

Hi Felix,

sorry, typing error …

The current and correct Core-Version is 8.7.81

kopano-server_8.7.81.32.d84d89fd9-0+229.2_amd64.deb

and the Webapp- Version is 3.5.7.2298+1289.1

Before the update from Core 8.7.80 and Webapp 3.5.5.2266+1267.1 everything was O.K.

Regards,
Walter

Gerald

I have the same problem on Ubuntu 18.04. Have seen this on two different systems with currently webapp-3.5.7.2298+1289-Ubuntu_18.04 nightly build installed.

One case was answering a simple email, which refused to get sent. I then manually copy/pasted the receipients adresss instead of replying to his email and was able to send him an answer this way.

The other case is when creating a calendar entry with participants (where they probably then should get an email) - also does not get sent… Downgrading webapp to “3.5.6.2289+1281.1” has not solved this… Might need to downgrade further? Or it’s a kopano-core problem - I’m using core-8.7.81.26-Ubuntu_18.04-amd64

Before the update from Core 8.7.80 and Webapp 3.5.5.2266+1267.1 everything was O.K.
UPDATE: I’ve downgraded to 3.5.5.2266+1267.1, which acorrding to wesser was working before. I’ve cleared the cache (in DeskApp, also installed the latest version of Deskapp while I was at it) but the problem persists.

So since 3.5.5 was working for wesser before and its not working now… Probably kopano-core is causing the problem and not really webapp is at fault?

umgfoin

Hi @Gerald and @wesser,
if you’re able to build from source, revert commit f902c9fc124 .
This seems to solve the issue.

++umgfoin.

wesser

Today’s upgrading to Core 8.7.81.48 from the latest builds does not solve the issue for me with Debian 9.
I will wait for another nightly build of the webapp or build from source next weekend like @umgfoin …

Answering or forwarding mails via z-push (2.5.0) is working fine, no problems.

Regards,
Walter

Gerald

@umgfoin said in Problems with Webapp 3.5.7 - could not send mails:

Hi @Gerald and @wesser,
if you’re able to build from source, revert commit f902c9fc124 .
This seems to solve the issue.

++umgfoin.

Unfortunately I’m not able to compile from source, I’m using the nightly builds.
The commit does not seem to have been reverted since it was done on May 6th, so it does not look like this will be fixed :-(

umgfoin

@Gerald said in Problems with Webapp 3.5.7 - could not send mails:

The commit does not seem to have been reverted since it was done on May 6th, so it does not look like this will be fixed :-(

Hi Gerald,
I think this is an incorrect assumption - naturally, fixing nightly builds does not have the highest priority in a commercial enterprise. Neither did I mean that reverting the commit is the final solution, but on first sight a workaround.
There might be other conflicting issues in the test-queue or simply workforce bound to customers.

In order to come around such “blocking” issues, I’d recommend to make yourself familiar with building from source and compile from a stable branch or simply go back to an earlier nightly build.

Kopano does not offer elder builds, thus foresighted archiving is your job in this case - atleast until somebody comes up with a nightly-build archive.

++umgfoin.

Gerald

@umgfoin said in Problems with Webapp 3.5.7 - could not send mails:

In order to come around such “blocking” issues, I’d recommend to make yourself familiar with building from source and compile from a stable branch or simply go back to an earlier nightly build.

Kopano does not offer elder builds, thus foresighted archiving is your job in this case - atleast until somebody comes up with a nightly-build archive.

++umgfoin.

I have my own nightly build archive (for Ubuntu 16.04/18.04 + WebApp & MDM plugin), don’t know if I’m allowed to make this public. So I’ll try going back to a pre-May 6th build. I’m always wary of downgrades because of the database version though :-(

Tw1nh3ad

Hi,

I have downgraded the core only.
This fixed the issue.

kopano-server 8.7.80.936.529d71bca-0+187.1
kopano-webapp 3.5.7.2298+1289.1

fbartels

fyi this php crash should be resolved with https://jira.kopano.io/browse/KC-1507 (currently in review, not yet merged)

source branch for the pr is https://stash.kopano.io/users/jengelhardt/repos/kc/commits?until=refs%2Fheads%2Fkc-1507

wesser

Thanks guys for you replies!
I think it will take some time before core is being patched for that issue.

One further question - can anyone provide me a core 8.7.80 for Debian 9, x64 to get my systems running again?

For the future I’ve learnt, that I am self responsible for archiving older versions before update …

Regards,
Walter

umgfoin

I think it will take some time before core is being patched for that issue.

Now, pushed to master and kc-8.7.x.: RELNOTES.txt

Gerald

Would love to test it, but it seems the daily build service is broken again… Last build is 2 1/2 days old.

irreleph4nt

I can confirm that the current top commit fixes the issue. I am running a custom build on Arch Linux and was also impacted by this issue.

Gerald

There now is a daily build again. Issue seems to be fixed. Todays Ubuntu 18.04 x64 core build contains a duplicate and broken kopano-python-utils package though.

Really sad how often the build process breaks. Or how seldom it works correctly. You get the impression that testers for the daily builds are not really wanted at all.

fbartels

@Gerald said in Problems with Webapp 3.5.7 - could not send mails:

Really sad how often the build process breaks. Or how seldom it works correctly. You get the impression that testers for the daily builds are not really wanted at all.

Please have in mind that these daily builds are “just” automated builds based on our current development branches. These are not finished products that are there for people to test our software with. If you want to evaluate our software it is recommended to request a trial subscription. As for going into production deployments having a subscription with access to tested and supported packages is of course also recommended.

Kopano is on its way to be included in some more distributions (like Debian 10), these distributions will then use a specified official release as well. But knowing the nature of these distributions they will also use way older versions than what is available to our customers (in packaged form at least).

Edit: I should mention that feedback retrieved from the builds of course also helps us in identifying issues in upcoming releases. While fixing issues in the development branch is not always the top priority (paying customers are) we are of course happy for feedback received and even more grateful if the more advanced users (like @umgfoin for example) also provide patches to us.