yes! [root@mail:~]$ rpm -q dbmail dbmail-3.1.16-5.fc19.20140721.rh.69c0592867ad012bd1b78b873b65f7e53064971c.x86_64
[root@mail:~]$ systemctl status dbmail-imapd.service dbmail-pop3d.service
dbmail-imapd.service - DBMail IMAP Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service; enabled)
Active: active (running) since Di 2014-07-22 21:57:51 CEST; 2 days ago
Main PID: 633 (dbmail-imapd)
CGroup: name=systemd:/system/dbmail-imapd.service
└─633 /usr/sbin/dbmail-imapd -D
Am 24.07.2014 22:06, schrieb Jorge Bastos:
> Hi Harald,
>
> So how is this, problem solved?
>
>> -----Original Message-----
>> From: dbmail-boun...@dbmail.org [mailto:dbmail-boun...@dbmail.org] On
>> Behalf Of Harald Leithner
>> Sent: terça-feira, 22 de Julho de 2014 08:39
>> To: DBMail mailinglist
>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
>> last clean version
>>
>> Runs fine for me, no customer complains since yesterday \o/
>>
>>
>> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <p...@nfg.nl>:
>>
> So, you think we're ready for 3.1.17?
>
> On 21-07-14 17:10, Reindl Harald wrote:
>>>>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>>>>>
>>>>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>>>>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between both
>>>>> * checksum of all testmessages for POP3 and IMAP correct * see also
>>>>> attachment
>>>>>
>>>>> not sure if the conlusion "putting gmime back in charge" is entirely
>>>>> correct or the dbmail code just had some memory bug but at least i
>>>>> see no current problems and can't find the context of the
>>>>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>>>>>
>>>>> only that below where i was too stupid to notice the regression
>>> while
>>>>> other commits between 3.1.10 and 3.1.11 obviously are fine
>>>>>
>>> _____________________________________________________________________
>>>>> _____________________
>>>>>
>>>>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
>>>>> cleanup callback 2014-02-24 Fixed wrong result check in change
>>>>> username function 2014-02-21 fix regression in utf7 mailbox matching
>>>>> 2014-02-18 IMAP: fix inverted logic during abort
>>>>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>>>>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
>>> an
>>>>> error 2014-02-10 remove unused file
>>>>>
>>>>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>>>>> reconstruction !! -- KILLER -- !!
>>>>>
>>>>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>>>>> unit-tests after merge 2014-01-30 Merge branch 'dbmail_3_1_utf8_fix'
>>>>> of https://github.com/alyarskiy/dbmail
>>>>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>>>>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>>>>> 3.1.10
>>>>>
>>> _____________________________________________________________________
>>>>> _____________________
>>>>>
>>>>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>>>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>> use
>>>>>> for my upgrade, but 'd like some feedback from anyone using it
>>>>>> already
>>>>>
>>>>> yes because there are only small well deserved bugfixes from 3.1.10
>>>>> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>>>>>
>>>>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
>>>>> memory leak
>>>>>
>>>>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>>>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>>>>
>>>>>> Currently testing the change.
>>>>>>
>>>>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>>>>
>>>>>>> CLEAN - snapshot:
>>>>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>>>>> _____________________________________________________
>>>>>>
>>>>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support wrapped
>>>>>>> boundaries during reconstruction
>>>>>>
>>>>>>> there must be happening something bad in memory
>>>>>>
>>>>>>> that is the guilty commit and sadly i remember that it fixed a bug
>>>>>>> rpeorted from myself in case of specific messages not proper
>>>>>>> re-constructed at least on Apple Mail
>>>>>>>
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
>>>>>>> 468e2cb4d520789cd35156145c5f37
>>>>>>
>>>>>>>
>>>>>>>
> no idea why a commit from 2014-02-10 took that long to get visible
>>>>>>> each day more
>>>>>>
>>>>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>>>>> unbelieveable
>>>>>>>>
>>>>>>>> i am building and stressing serveral releases 3.1.10 is the last
>>>>>>>> one not suffering from the problem "--" instead "-- mime-id" and
>>> i
>>>>>>>> have clearly no idea why this started around June to affect more
>>>>>>>> and more users
>>>>>>>>
>>>>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>>>>
>>>>>>>> with 3.1.10 it's impossible for me to produce enough concurrency
>>>>>>>> to get any single mismatch
>>>>>>>>
>>>>>>>> that below is expected because fixed with the following commit
>>>>>>>>
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
>>>>>>>> e1d120581740020f4e73c3cf8d3a6c0
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
