of course! and please continue to notice about proposed release candidates so that at least your faithful testers have the chance to point out regressions like in 3.1.17
I had a WTF moment yesterday because as I woke up i saw your commit and while about build the Snapshot in the hope get the race bug solved the release announce followed by crying out "what he is smoking today this regression is catched within the first 30 seconds" :-) -------- Ursprüngliche Nachricht -------- Von: Paul J Stevens <p...@nfg.nl> Gesendet: 21. Juli 2014 17:56:16 MESZ An: DBMail mailinglist <dbmail@dbmail.org> Betreff: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10 last clean version -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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=8c612adbe6468e2cb4d520789cd35156145c5f37 >> >>> >>> 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=8a042214ae1d120581740020f4e73c3cf8d3a6c0 >>>> >>>> >>>> >>>> _______________________________________________ >>>> DBmail mailing list DBmail@dbmail.org >>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail - -- ________________________________________________________________ Paul J Stevens pjstevns @ gmail, twitter, github, linkedin www.nfg.nl/i...@nfg.nl/+31.85.877.99.97 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPNOCAACgkQ8iITvBH4zTG6sQCfbxpK51myu1FJL93Bl7g0a282 S1EAoM13GWE6HFQEr0yKqRuAb75JoD7g =VNeh -----END PGP SIGNATURE----- _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail -- Reindl Harald (mobile) the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development +43 (676) 40 221 40 http://www.thelounge.net _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
