Arguably we should figure out a way to make this fetch the support
email from the server (or something), but in the short term it seems
worth making the email address at least correct.
andersk reports that we are "incorrectly sending outgoing zephyrs with z_charset
= ZCHARSET_ISO_8859_1, which breaks zwgc (other clients tend to ignore
z_charset). I'm assuming you're shelling out to zwrite; you need to use zwrite
-x UTF-8, or export LC_ALL=en_US.UTF-8."
(imported from commit 8abb28bf8acbe0b5aa99ca13faab24e1e554a031)
This may require just doing an mv on the home directory, plus changing
the home directory in /etc/passwd. It should of course be done carefully.
(imported from commit 660997d897ee6d33563af74f0fc5d4267a911755)
We were having problems where we were suspiciously processing notices
at a rate of 1 notice per 15s, which suggests that we the select was
timing out even though there were notices to be fetched immediately.
We fix this by clearing the queue each time our select loop ends.
(imported from commit 7e7bfbb2126d1f4170d65d1483a0b799dcab80b9)
This should enabled us, in the future, to enable support for mail
zephyrs without requiring users to re-auth.
(imported from commit 2665743212da567fe85742d30cca42b902e41a0d)
The davidben-patched-for-roost Zephyr branch (available at
https://github.com/davidben/zephyr/tree/roost) adds Zephyr support for
these options. We also patch python-zephyr to expose them. These
basically let you save your Zephyr tickets and port number to a file,
so that you can later restore them (even potentially after the machine
rebooted). Basically because Zephyr is UDP, the Zephyr server will
continue trying to deliver messages to a particular port number that
was registered for up to 20 minutes after getting an error; so we can
even have downtime and reboot and still get our packets so long as we
restore the sessions within 20 minutes.
(imported from commit 986cbb157ddfa57aa4b644cd826f8418e9876dc7)
Our .crypt-table parsing code isn't quite correct, in that we don't
handle either the "zcrypt default" or "zcrypt by class/instance" pair
options (for sending messages in either direction) -- you have to be
zcrypting for an entire class. I think this makes sense given that on
the Zulip end we can only enforce anything on a stream level.
(imported from commit a7901b1dc025a04a23ee71ecdd499e3f150ba614)
For now we only support the AES encryption type since the DES one is
probably not used anymore.
(imported from commit 222606db9f704917e74159e7d07a110187a236e6)
This must be deployed after we update our running nginx configuration
to serve api.humbughq.com.
(imported from commit b5c34ebdd595f55eecd6dca6a18a37f105107bd5)
