Hello,
- there is one pending patch reporting truncated messages when log_msg_size() is exceeded, it can be in once Roberto confirms that my change is correct to his patch.
Confirmed now in another thread.
Thanks Jose and Roberto for helping me preparing the release.
Let's make it the best release ever ;). Open issues (on my/our side), but _no_ showstopper: o The TCP close -> lose 1 message feature (non-trivial, postponed ad infinitum, I guess) o I should be re-running the performance tests I did about 14 months ago (postponed until I find enough time) o An engineer in our company wrote something about sources.c being broken regarding packet parsing code. As I cannot possibly see or guess what he meant, we can safely ignore this for now. I will sit down with him and ask what the issue was. As a test, I've downloaded syslog-ng-1.6.0rc1 and compared to the current sources.c. The changes are minor and IMHO not related to packet parsing code. o We have a test suite for syslog-ng that we built up for QA reasons. If there is an interest in submitting those, I'll talk to the management. o We internally patch syslog-ng to have a counter assigned to each message. So we have a log_id and additionally know which messages are lost. I wonder if such a feature (given the patch was polished) could be of any interest. o Sometimes it's not feasible to build a stunnel or ssh forward or whatever secured channel you can create, to forward syslog-ng messages encrypted. A long standing wish would be to integrade SSL support for syslog-ng. If there was a discussion about this earlier, please point me to it. That's it for now, I think :). Thanks and happy releasing, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc