The better solution may be to try/except the import of pdb, preserving the existing functionality while avoiding this error.

I'm not understanding what the difference is between;

Compatibility with other clients basically requires (read: "has required"?) file names for attachments are ascii-encoded and do not contain spaces. I think there's even an RFC on client-compatible naming conventions for naming attachments, but I'm failing to recall the number (maybe 2138?).

There's very little chance of Kolab being built on our end, for these architectures.

Copenhagen is, in principle, available. The reason for this ticket to exist has largely been obsoleted. This ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

As the 750+ packages are now rebuilding, I'm going to declare this issue as resolved. Please reopen / create a new ticket should some discrepancies persist.

Now that we have the GPG key thing in the OBS sorted, perhaps it is time to rebuild all of Kolab:16 indeed, and refresh what is referred to as community.asc.

So, that got poked in the face... Happy bug-hunting!

I don't remember where to do this in a way that fixes it permanently, so I've hot-fixed it.

@machniak; since we can reproduce this on webmail.kolabsys.com, I can verify there's no discernible error in the console.

In T4241#62348, @rsc wrote:

Closing this as invalid is not nice.

Disabled registration through third part providers, disabled trusting email addresses associated with those providers.

We currently have a problem with the OTP-20 compatibility of most of the erlang packages. Who would have guessed?

The week number is already included in the miniature calendar on the left-hand side, for both month and week views.

@rsc; what is the size of the real estate so we can attempt to reproduce?

This can be reproduced reliably.

This should now be resolved, please verify.

I don't know what to do about it, to be honest. There doesn't seem to be any modules or settings that protect against this type of thing, as far as I could find.

Renaming the mailbox works as intended -- if the result attribute value changes, then so must the mailbox name. This is an effect of the username canonification processes applied in webmail+friends and Cyrus IMAP itself (using ptloader).

A few more remarks.

In D577#6587, @machniak wrote:

In send_update_notification() we send mail in a loop trying up to 5 times if an error occurrs. But this is the only place where we do this. I think it would make sense to do this in all cases, i.e. in _sendmail(). I see also we don't call smtp.quit() consistently. Once we do this on success only, once we do this on error too.

Looking good, except for the corner-case of an errmsg over an un-"captured" exception.

May I have a reference?

The weakness in SHA1 is a collision risk, not an active compromise vector.