On 03/07/2020 07:34, Andreas Metzler wrote:
> There is a typo in the patch on +fixes:
>
> receive.c:1787:1: warning: implicit declaration of function 'exim_gettime';
> did you mean 'exim_gettimg'? [-Wimplicit-function-declaration]
> 1787 | exim_gettime(&message_id_tv);
> -extern voidexim_ge
On 2020-07-02 Jeremy Harris wrote:
[...]
> Proposed fix is pushed upstream. Some testing would be good.
Hello,
Thank you, I will upload to Debian/unstable soonish.
There is a typo in the patch on +fixes:
receive.c:1787:1: warning: implicit declaration of function 'exim_gettime'; did
you mean
On Tue, 30 Jun 2020 17:11:35 +0200 Marc Haber
wrote:
> I have forwarded this to exim-users,
>
> https://lists.exim.org/lurker/message/20200630.150143.248009f3.en.html
Proposed fix is pushed upstream. Some testing would be good.
--
Cheers,
Jeremy
On Mon, Jun 22, 2020 at 07:40:31AM +0200, Michal Politowski wrote:
> Package: exim4
> Version: 4.94-4
> Followup-For: Bug #962847
>
> gdb shows the wait happening in milliwait, called from exim_wait_tick:
>
> 0xf7faf169 in __kernel_vsyscall ()
> #0 0xf7faf169 in __kernel_vsyscall ()
> #1 0xf742
I am seeing a similiar issue now on my personal laptop when software
delivers a message to the locally running exim via SMTP. The software
never returns until it times out, redelivering the message to the local
exim on the next try. Exim has the message on its queue as well, but the
process handlin
Package: exim4
Version: 4.94-4
Followup-For: Bug #962847
gdb shows the wait happening in milliwait, called from exim_wait_tick:
0xf7faf169 in __kernel_vsyscall ()
#0 0xf7faf169 in __kernel_vsyscall ()
#1 0xf742fc44 in __GI___sigsuspend (set=0xffdc53ac) at
../sysdeps/unix/sysv/linux/sigsuspend.
On Mon, 2020-06-15 at 18:01 +0200, Marc Haber wrote:
> On Mon, Jun 15, 2020 at 01:56:18PM +0200, Rémi Letot wrote:
> > My mail client and exim are both running on my laptop, and the
> > provided logs are from that same laptop.
> >
> > The fault is the delay between exim accepting the message, and
Hi,
I can reproduce the bug on my system, but I think it's GNU Emacs
related:
After I put my system to sleep for 5 minutes, sending a test mail
with GNU Emacs took 5 minutes, while sending one with
"/usr/bin/bsd-mailx" was possible without the lag.
The bug bit me for 2 days, I wasn't able
Marc Haber writes:
> On Mon, Jun 15, 2020 at 01:56:18PM +0200, Rémi Letot wrote:
>> My mail client and exim are both running on my laptop, and the provided
>> logs are from that same laptop.
>>
>> The fault is the delay between exim accepting the message, and actually
>> delivering it to the sma
On Mon, Jun 15, 2020 at 01:56:18PM +0200, Rémi Letot wrote:
> My mail client and exim are both running on my laptop, and the provided
> logs are from that same laptop.
>
> The fault is the delay between exim accepting the message, and actually
> delivering it to the smarthost. During that delay, m
Marc Haber writes:
> Logs of the fault please, or it didn't happen. Which system is the one
> we're seeing the exim logs from? Where does your mail client run?
Hello,
thanks for your answer.
My mail client and exim are both running on my laptop, and the provided
logs are from that same lapt
On Mon, Jun 15, 2020 at 02:34:42AM +0200, Rémi Letot wrote:
> Since upgrading to 4.94 (4.94-1 and 4.94-2 display the problem), I have
> noticed delays when trying to send email after the laptop has been sleeping.
>
> My mail client (emacs) simply gets stuck until I cancel the message, or
> wait
Package: exim4
Version: 4.94-2
Severity: normal
Dear Maintainer,
I'm using exim4 on a laptop to send email through a smarthost.
Up to 4.93-16, everything went well.
Since upgrading to 4.94 (4.94-1 and 4.94-2 display the problem), I have
noticed delays when trying to send email after the lapt
13 matches
Mail list logo
