On 3/11/2015 11:10 AM, Olaf Hopp wrote:> Please see the thread with subject > "Sieve permissions issue following update" > I tested sucessfully a developper issue last month > on the hint of Stephan. Yesterday I started to test the currenr RCs. > > First I was disappointed, because the error seems to persist. > So I double checked everything, recreated / recompiled everything > an the error went away. So I thought it was mistake on my side. > I gave Spephan postive feedback. And I'm waiting for the final release > for my production server. > > But when I read your mails, I'm not feeling happy. > I think it's a kink of luck/voodoo/whatever. > > What you must do, I think, is to compile the sieve script with the > exact version running afterwards. > And I think you should the remove the compiled .svbin files > before recreating them again. Don't overwrite them with the compiler. > > I think I'll also dig into this any further today.Please do. I cannot reproduce this so far. Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg). Regards, Stephan.
> Since E.B. still got an obscure debug message about metadata not being > up to date, I added debug lines to the remaining places where this could > emerge (currently only available from hg).Using hg from just now - first line looks like what you want: dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: file script: Binary reports different script location (`script2.sieve' rather than `/usr/local/var/dovecot/sieve/script2.sieve') dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: binary up-to-date: script metadata indicates that binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: Script binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date
> Using hg from just now - first line looks like what you want: > > dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: file script: Binary reports different script location (`script2.sieve' rather than `/usr/local/var/dovecot/sieve/script2.sieve') > dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: binary up-to-date: script metadata indicates that binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date > dovecot: lmtp(testuser at example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: Script binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date >Also, it does appear that blowing away *everything* in my global script location (is removing the svbin file the key?) and re-creating it all seems to fix the problem.
On 03/12/2015 12:02 AM, Stephan Bosch wrote:> On 3/11/2015 11:10 AM, Olaf Hopp wrote: >> Please see the thread with subject >> "Sieve permissions issue following update" >> I tested sucessfully a developper issue last month >> on the hint of Stephan. Yesterday I started to test the currenr RCs. >> >> First I was disappointed, because the error seems to persist. >> So I double checked everything, recreated / recompiled everything >> an the error went away. So I thought it was mistake on my side. >> I gave Spephan postive feedback. And I'm waiting for the final release >> for my production server. >> >> But when I read your mails, I'm not feeling happy. >> I think it's a kink of luck/voodoo/whatever. >> >> What you must do, I think, is to compile the sieve script with the >> exact version running afterwards. >> And I think you should the remove the compiled .svbin files >> before recreating them again. Don't overwrite them with the compiler. >> >> I think I'll also dig into this any further today. > > Please do. I cannot reproduce this so far. > > Since E.B. still got an obscure debug message about metadata not being > up to date, I added debug lines to the remaining places where this could > emerge (currently only available from hg). > > Regards, > > Stephan. >Hi, I'm still trying but currently I can not reproduce the bug. But I will keep on hammering on it. Olaf -- Karlsruher Institut f?r Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakult?t f?r Informatik Dipl.-Geophys. Olaf Hopp - Leitung IT-Dienste - Am Fasanengarten 5, Geb?ude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp at kit.edu atis.informatik.kit.edu www.kit.edu KIT - Universit?t des Landes Baden-W?rttemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5214 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150312/24412f19/attachment.p7s>
On 3/12/2015 11:56 AM, Olaf Hopp wrote:> On 03/12/2015 12:02 AM, Stephan Bosch wrote: >> On 3/11/2015 11:10 AM, Olaf Hopp wrote: >>> Please see the thread with subject >>> "Sieve permissions issue following update" >>> I tested sucessfully a developper issue last month >>> on the hint of Stephan. Yesterday I started to test the currenr RCs. >>> >>> First I was disappointed, because the error seems to persist. >>> So I double checked everything, recreated / recompiled everything >>> an the error went away. So I thought it was mistake on my side. >>> I gave Spephan postive feedback. And I'm waiting for the final release >>> for my production server. >>> >>> But when I read your mails, I'm not feeling happy. >>> I think it's a kink of luck/voodoo/whatever. >>> >>> What you must do, I think, is to compile the sieve script with the >>> exact version running afterwards. >>> And I think you should the remove the compiled .svbin files >>> before recreating them again. Don't overwrite them with the compiler. >>> >>> I think I'll also dig into this any further today. >> >> Please do. I cannot reproduce this so far. >> >> Since E.B. still got an obscure debug message about metadata not being >> up to date, I added debug lines to the remaining places where this could >> emerge (currently only available from hg). >> >> Regards, >> >> Stephan. >> > > Hi, > I'm still trying but currently I can not reproduce the bug. > But I will keep on hammering on it.Looks like I found the bug. Will need some time to fix this properly. Regards, Stephan.