On Sat, Sep 28, 2019 at 12:28 PM Alex Andreotti
wrote:
> On Sat, Sep 28, 2019 at 09:15:42AM +0200, László Böszörményi (GCS) wrote:
> > Can you revert to 6.4.0~rc3-1 and check it? But I'm going to update
> > the packaging to the fixed upstream release. Please test that anyway.
>
> I tried, 6.4.0~rc
On Sat, Sep 28, 2019 at 03:22:51AM +0200, Matthias Andree wrote:
[cut]
> fetchmail behaved inconsistently between daemon and non-detaching modes
> in the upstream version without Debian patches already until 6.4.0-rc4,
> and that needed fixing, and is what I've fixed.
>
> If there are additional
On Sat, Sep 28, 2019 at 1:03 AM Alex Andreotti wrote:
> Attention, I was using it with a relative path and it worked, the
> behavior change is that it stopped working, I believe with one of the
> two updates below:
This would be strange, but let's see the changes.
> September 4
>
> fetchmail
Am 28.09.19 um 00:59 schrieb Alex Andreotti:
> Attention, I was using it with a relative path and it worked, the
> behavior change is that it stopped working, I believe with one of the
> two updates below:
fetchmail behaved inconsistently between daemon and non-detaching modes
in the upstream vers
Attention, I was using it with a relative path and it worked, the
behavior change is that it stopped working, I believe with one of the
two updates below:
September 4
fetchmail (6.4.0~rc4-1) unstable; urgency=medium
* New major upstream RC release.
* Remove outdated and P
Control: tags -1 confirmed upstream
Alex, thanks for your report, you've found a very long-standing
inconsistency in fetchmail's behaviour.
The workaround is to give an *absolute* path for FETCHMAILHOME in daemon
mode. This will be fixed in 6.4.0.
Package: fetchmail
Version: 6.4.0~rc4-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
I have been using fetchmail for several years to download mail from multiple
accounts, one instance for each account using the FETCHMAILHOME variable.
I realized only today that it was
7 matches
Mail list logo
