Re: Any advice on big upgrade lenny->jessie?
On Fri, 12 May 2017, Boylan, Ross wrote: > I tried to build db4.2-util from source on jessie, but couldn't even Try installing the old binary packages. That often works on stuff that doesn't have nasty reverse-dependencies. > get configure to run: > https://lists.debian.org/debian-devel/2017/05/msg00069.html. Maybe I > could have just installed the deb from wheezy, but that didn't seem > trustworthy. ldd the resulting binaries if the install goes through. If it is just glibc and berkeley DB libs, it will work just fine. > Instead I ran the wheezy system in a chroot, copied the current > cyrus-upgrade-db script into it, edited upgrade cyrus-db-types.txt to > change all the berkeley db's to skiplist (except I left the DBENGINE > line intact) and ran the upgrade script in the chroot. I had to alter > the path to cvt_cyrusdb so the script could find it. > > I copied the resulting files to the new system and deleted > cyrus-db-types.active. Yeah, that will do it :) > My next step is to install sasl, and then I'll try installing cyrus. Good luck... -- Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Source repository?
On Fri, 05 May 2017, Boylan, Ross wrote: > I know apt-get source will fetch it, but I was hoping to get something more > integrated with the revision history. > https://sources.debian.net/src/cyrus-imapd-2.4/stable/ is good for browsing > on the web, but doesn't seem designed for other uses. > > I guess I'll use apt-get, but am curious about other methods. It looks like the vcs metadata in the package control file is borked. We should fix that... The git repos are here (you likely want the first one): https://anonscm.debian.org/cgit/pkg-cyrus-imapd/cyrus-imapd.git/ https://anonscm.debian.org/cgit/pkg-cyrus-imapd/cyrus-imapd-2.4.git/ https://anonscm.debian.org/cgit/pkg-cyrus-imapd/cyrus-imapd-2.2.git/ https://anonscm.debian.org/cgit/pkg-cyrus-imapd/kolab-cyrus-imapd.git/ The clone URLs are at the bottom of the page. -- Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Bug#743013: Does not restart/stop due to PIDFILE problem
On Thu, 10 Apr 2014, Francis Russell wrote: As a consequence of this bug, release 1.0.1.g-2 of Debian openssl which restarts services that are affected by the Heartbleed bug (http://heartbleed.com/) will not restart Cyrus. The old Cyrus process will be left running, potentially a source of a serious security compromise. There is no potentially. It *will* leak private data over Heartbleed. http://lists.andrew.cmu.edu/pipermail/cyrus-devel/2014-April/002971.html -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Bug#734648: cyrus-nntpd-2.4: nntp not working after upgrade to wheezy
On Wed, 08 Jan 2014, Ulrich Eckhardt wrote: This bug was resolved quickly by the cyrus team but planned for 2.4.18. I was able to incorporate the two commits of the solution into the source package cyrus-imapd-2.4_2.4.16-4+deb7u1 and build a new working nntpd for cyrus 2.4.16. The following patch can be applied to fix this problem: I'd rather wait a couple weeks for 2.4.18, because we might as well investigate all commits landed since 2.4.16 as potential candidates for a stable update. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#686110: cyrus-imapd: Corrupted databases can exhaust logging diskspace
On Wed, 29 Aug 2012, Ondřej Surý wrote: On Tue, Aug 28, 2012 at 7:46 PM, Jamie Thompson bugs.deb...@jamie-thompson.co.uk wrote: Following a power failure my tls_sessions.db file became corrupted (UPS is currently out of commission - anyway). When the server restarted, I did not notice this fact and would not do so until my next logcheck email (or an attempt to check my mail). Unfortunately, within a few hours my logfiles ended up being full of cyrus's infinite unsuccessful startup attempts, resulting in 6GB of logfiles, which so happened to take my server down. Ideally Cyrus should try to recover the databases, if that fails, delete the session-specific recreateable ones (i.e. tls_sessions.db) and try again, and if it is still unable to start, stop trying as without intervention it's just wasting electricity and disk space. Well, ideally you should check your system, deamons and logs after a power failure. I don't think upstream would want to waste development cycles on something which can be easily circumvented by human operator. That depends. Cyrus master has a controlled respawn system, which may or may not be active by default. *IF* it was enabled, and master still filled the log quicky, THEN it is certainly a bug upstream will want to fix. man cyrus.conf will tell you more about it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#680363: cyrus-imapd-2.2: imapd gets mad falling into endless loop
On Tue, 10 Jul 2012, Kiss Gabor (Bitman) wrote: #0 0xb7754424 in __kernel_vsyscall () #1 0xb720f96b in poll () from /lib/i686/cmov/libc.so.6 #2 0xb4d43444 in ldap_int_select (ld=0x91a8638, timeout=0x0) at os-ip.c:1098 #3 0xb4d2cdbb in wait4msg (ld=0x91a8638, msgid=4, all=0, timeout=0x0, result=0x91afb64) at result.c:335 #4 ldap_result (ld=0x91a8638, msgid=4, all=0, timeout=0x0, result=0x91afb64) at result.c:120 #5 0xb4b7091e in ?? () from /lib/libnss_ldap.so.2 #6 0xb4b70c38 in ?? () from /lib/libnss_ldap.so.2 #7 0xb4b73625 in _nss_ldap_endgrent () from /lib/libnss_ldap.so.2 [...] Actually I bet function wait4msg() in libraries/libldap/result.c in OpenLDAP calls ldap_int_select() in endless loop with zero timeout. The strace output looked like there were pending events on fd 16 for the select() call. In that case, it will return immediately... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#680363: cyrus-imapd-2.2: imapd gets mad falling into endless loop
tag 680363 + unreproducible thanks On Wed, 11 Jul 2012, Kiss Gabor (Bitman) wrote: Actually I bet function wait4msg() in libraries/libldap/result.c in OpenLDAP calls ldap_int_select() in endless loop with zero timeout. The strace output looked like there were pending events on fd 16 for the select() call. In that case, it will return immediately... Actually I cannot debug it more because I had to replace libnss-ldap with libnss-ldapd. I'm really sorry. Thanks for your efforts. I am always too happy to see someone ditch libnss-ldap for *anything* else, even if it is only libnss-ldapd, so don't worry about it :-) I will close the bug as unreproducible for now. If someone hits it and decides to debug it further, *especially* if it hits in wheezy, we can just reopen it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#680363: cyrus-imapd-2.2: imapd gets mad falling into endless loop
Please confirm that this is not caused by the leap-second issues, i.e. you've seen it on a freshely rebooted server, or prior to the 29th of june. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Canonical location of cyrus-devel repositories
On Sat, 15 Oct 2011, Ondřej Surý wrote: I think that debian/control has correct information: Vcs-Git: git://git.debian.org/pkg-cyrus-imapd/cyrus-imapd-2.4.git Vcs-Browser: http://git.debian.org/?p=pkg-cyrus-imapd/cyrus-imapd-2.4.git (Except that git.debian.org is down atm.) When I tried to check yesterday, 2.4.12 was not visible to the vcs-browser. If alioth is down right now, maybe it was a glitch... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Bug#644503: cyrus-common-2.2: not installabel in sid
On Thu, 06 Oct 2011, Ralf Treinen wrote: Package: cyrus-common-2.2 Version: 2.4.12-1 Severity: serious User: trei...@debian.org Usertags: edos-outdated Hi, cyrus-common-2.2 (2.4.12-1) says: Depends: ... cyrus-common-2.4 The cyrus-common-2.4 (2.4.12-1) package says: Conflicts: ... cyrus-common-2.2 As a consequence, cyrus-common-2.2 (2.4.12-1) is not installable. Shouldn't we ask for the removal of the 2.2 branch from Sid? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Init script slowness
On Tue, 04 Oct 2011, Thomas Cataldo wrote: diff --git a/debian/cyrus-common.cyrus-imapd.init b/debian/cyrus-common.cyrus-imapd.init index fc85485..282ac8d 100755 --- a/debian/cyrus-common.cyrus-imapd.init +++ b/debian/cyrus-common.cyrus-imapd.init @@ -172,7 +172,7 @@ do_stop() sync_stop [ $? = 2 ] return 2 -start-stop-daemon --stop --quiet --retry=QUIT/30/TERM/10/KILL/5 --pidfile $PIDFILE --name $NAME +start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 --pidfile $PIDFILE --name $NAME RETVAL=$? [ $RETVAL = 2 ] return 2 I have some code that does cyrus restarts and it always takes 30sec if someone has already connected to cyrus / is connected to cyrus. The idea is to allow a safe shutdown, which SIGQUIT is supposed to do. If SIGQUIT behaviour is not optimal, that's the bug that should be fixed instead. We can also add extra actions such as immediate-restart and force-stop that use QUIT/5/TERM/10/KILL/5 for example. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Init script slowness
On Tue, 04 Oct 2011, Ondřej Surý wrote: I agree on fixing SIGQUIT behaviour. Does anyone have an easy way to test whether sigquit is doing the right thing on open but idle connections of the various protocols? After all, if does not have an open transaction _now_, it should get immediately closed by a sigquit... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Init script slowness
On Tue, 04 Oct 2011, Steven Kurylo wrote: On Tue, Oct 4, 2011 at 10:28 AM, Henrique de Moraes Holschuh h...@debian.org wrote: On Tue, 04 Oct 2011, Ondřej Surý wrote: I agree on fixing SIGQUIT behaviour. Does anyone have an easy way to test whether sigquit is doing the right thing on open but idle connections of the various protocols? After all, if does not have an open transaction _now_, it should get immediately closed by a sigquit... Checking in proc, my user has 5 imapd processes right now. I attached strace to them one at a time, then issued a sigquit. Each time the process exited immediately. The logs show something like: Oct 4 10:36:50 thetis cyrus/imaps[12021]: fetching user_deny.db entry for 'stevenkurylo' Oct 4 10:37:55 thetis cyrus/imaps[12021]: auditlog: traffic sessionid=cyrus-12021-1317741678-1 bytes_in=16484 bytes_out=80756 Oct 4 10:37:55 thetis cyrus/master[1325]: process 12021 exited, status 75 Oct 4 10:37:55 thetis cyrus/master[1325]: service imaps pid 12021 in BUSY state: terminated abnormally I haven't had an issue with shut down taking the full 30 seconds. Seeing a strace and the log files from a pid on a machine exhibiting this behavoir would be interesting. And also the protocol trace (cyrus calls it telemetry). That, together with the strace/ltrace, would allow us to nail the problem down rather fast and submit a bug report upstream. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: cyrus-imapd-2.2 removal
On Thu, 14 Apr 2011, Sven Mueller wrote: On Tue, April 12, 2011 4:29 pm, OndÅ#65533;ej SurÃœ wrote: I was thinking that since we have an automatic upgrade script now (and I will push upstream to move the logic to cvt_cyrusdb), we could drop cyrus-imapd-2.2 from unstable by creating empty virtual packages built from cyrus-imapd-2.4. What do you think? Next release will be in two years, that's plenty of time... Sounds good to me, but we need to make sure that the upgrade really works from a squeeze cyrus-imapd 2.2 to the new packages. For now, I suggest we give it a RC bug to not propagate to wheezy, and request removal from Wheezy. If we find out we do need it in Wheezy, it will be easy to remove the bug and let it migrate. Otherwise, we can request the complete removal later on closer to the wheezy release. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#621422: Package dependency error - smtptest test client authentication fails without libsasl2-modules installed
On Thu, 07 Apr 2011, Ondřej Surý wrote: is sufficient or we should add a hard dependency on libsasl2-modules. We cannot, it would be a layering violation. We already document this throughoutly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#622092: cyrus-imapd-2.2: fix for build with multiarch
On Sun, 10 Apr 2011, Steve Langasek wrote: multiarch. The attached patch has been applied in Ubuntu for this issue, correcting this call to use --with-com_err with no argument to get the default search path. Has this been triple-checked to do the right thing? I used to have to employ extremely hard measures (aka rm -fr et/ in debian/rules clean) to convince the Cyrus build to not do anything extremely hazardous, such as using pieces of system com-err and pieces of cyrus com-err. I *really* would not trust configure to not do something idiotic without directly checking the object files and poisoning the local copies of com-err to fail any build that touches them, so as to make sure everything is doing what it is supposed to... Otherwise, we should supplement the suggested patch with the destruction of the upstream com-err crap (and anything else we don't ever want in the build anyway while at it) in the clean target. This is _really_ an issue of much better safe than sorry, as it would bork the error handling paths (argh!). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: cyrus 2.4 new build deps
On Thu, 31 Mar 2011, Thomas Cataldo wrote: On Thu, Mar 31, 2011 at 2:09 AM, Henrique de Moraes Holschuh h...@debian.org wrote: On Wed, 30 Mar 2011, Thomas Cataldo wrote: - libtool (= 2.2~), + libtool (= 2.2), ~ sorts earlier than null, so this part of your change request doesn't make any sense, and must not be done. Not really sure what range of versions it can match when used here. Obviously mine (Version: 2.2.6b-2ubuntu1) is not fine. Whatever you're using is broken. $ dpkg --compare-versions '2.2.6b-2ubuntu1' ge '2.2~' ; echo $? 0 -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Accidental upload of 2.4 to unstable
On Wed, 30 Mar 2011, Ondřej Surý wrote: unfortunatelly I have accidentaly uploaded 2.4.6-3 to unstable. We may try talking to ftp-masters and have it removed, or we could just deal with the fallout. What do you think? Well, it is there, and we do NOT have the stable ABI requirements of the linux kernel, so the only strong blocker I had (namespace abuse, such as make_*, in /usr/bin) can still be fixed anyway :p Don't bother removing it from unstable. It obviously wanted to go there already :-) My thought is that we should leave it in unstable and this will bring us more testers and we wanted to do that anyway in near future, so we have 2.4 in wheezy. Yep, but better upload a new one with NEWS.Debian explaining that there is no automated migration path at all, and about the mess with the 2.2 packages removing important files. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: cyrus 2.4 new build deps
On Wed, 30 Mar 2011, Thomas Cataldo wrote: - libtool (= 2.2~), + libtool (= 2.2), ~ sorts earlier than null, so this part of your change request doesn't make any sense, and must not be done. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#611674: cyrus-clients-2.4: smtptest falsely claims user is authenticated
On Wed, 02 Feb 2011, brian m. carlson wrote: Please feel free to test against my server on port 587. Since you are obviously not authorized to relay mail through my server, smtptest should not claim you are authenticated. I might try that. But if one of the other maintainers could jump in and test it, I'd be grateful. Did you, perchance, try to do something that requires one to be authenticated to work? Not originally, but over IPv6 everyone except localhost must be authenticated. I've demonstrated something that requires authentication (and fails) in the transcript, which I've included below: Good, so we have confirmed that it is some sort of stupid bug in the SASL client (smtptest), and not anything more dangerous. S: 250 HELP Authenticated. Security strength factor: 256 I hate when that happens. It logged a lot of useless trash, but not what was really important. Either that, or smtptest/SASL thinks it got external authentication going (where the TLS layer suceeding implies you're already autenticated), so there was nothing to capture in the first place. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#611674: cyrus-clients-2.4: smtptest falsely claims user is authenticated
On Mon, 31 Jan 2011, brian m. carlson wrote: If I use smtptest with the -a and -u options but without -m, it claims that I am authenticated when I am not. It does not even try to issue an AUTH command. I am certain that bk2...@example.com is not an authorized user at the domain I've specified (since I administer that server). ... S: 220 2.0.0 Ready to start TLS verify error:num=18:self signed certificate TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) C: EHLO smtptest S: 250-castro.crustytoothpaste.net Hello [IPv6:2001:470:1f05:79:216:d3ff:feb3:801e], pleased to meet you S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-EXPN S: 250-VERB S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250-ETRN S: 250-AUTH GSSAPI CRAM-MD5 DIGEST-MD5 PLAIN S: 250-DELIVERBY S: 250 HELP Authenticated. Security strength factor: 256 We need the full telemetry to see what SASL is doing. Please run it in verbose mode. If it autenticated through GSSAPI, for example, it might not require a password. Did you, perchance, try to do something that requires one to be authenticated to work? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: 2.4.6 and /usr/sbin/cyrus
On Wed, 05 Jan 2011, Ondřej Surý wrote: On Tue, Dec 28, 2010 at 14:36, Henrique de Moraes Holschuh h...@debian.org wrote: On Wed, 22 Dec 2010, Thomas Cataldo wrote: On Tue, Dec 21, 2010 at 1:35 PM, Ondřej Surý ond...@sury.org wrote: Thanks fixed. Now it builds correctly. Agreed, but can we please go upstream first on this one? I'd really HATE to have something like that on Debian and something different upstream (even if it only happens in a future version). I'll try to raise the issue on upstream devel list. I'd also recommend not naming it cyrus, as cyrus is a common prefix for a number of projects. Maybe cyrimap if cyrus-imap is too long... Really? I know only cyrus-sasl and cyrus-imap (and apt-cache search isn't much help ... and google mainly talks about Miley Cyrus :)). And I can add support for cyrus-sasl2 as well if needed. Heh, better not mix the two packages. Let's ask upstream. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Testing 2.4
On Wed, 05 Jan 2011, Nikolaus Rath wrote: Is there a way to verify that the in-place upgrade worked? Or is it possible that the upgrade seems to work smoothly, but after a week I'm suddenly in trouble? In that case I would probably go with an IMAP migration instead... Well, I don't know. The bugs I've seen (and I have _not_ paid much attention, RL is a real bitch right now) are sublte issues with some messages. The big flashy ones have been long fixed, after all... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Testing 2.4
On Tue, 04 Jan 2011, Nikolaus Rath wrote: I would like to test the cyrus 2.4 packages, but I need some guidance on how to do it. The others have already told you about building from git. You have also to keep good backups of the old data, 2.4 is *very* new, and upstream is still finding and fixing issues related to the upgrade path. It has some serious potential for headaches, we'd never upload it to unstable right now even if the packaging was already good (and we were not in a freeze). It still needs a month or two of upstream bugfixing. Note: this doesn't apply for new installs, or migrations over IMAP (instead of in-place). I can't say much about replication, 2.4 fixes some serious limitations from 2.3, but on the other hand that's a lot of refactored and new code... but for single systems, it should be damn good already. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: 2.4.6 and /usr/sbin/cyrus
On Wed, 22 Dec 2010, Thomas Cataldo wrote: On Tue, Dec 21, 2010 at 1:35 PM, Ondřej Surý ond...@sury.org wrote: Thanks fixed. Now it builds correctly. Agreed, but can we please go upstream first on this one? I'd really HATE to have something like that on Debian and something different upstream (even if it only happens in a future version). I'd also recommend not naming it cyrus, as cyrus is a common prefix for a number of projects. Maybe cyrimap if cyrus-imap is too long... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Package names... cyrus-imapd-2.4+cyrus-imapd vs cyrus-imapd
On Fri, 03 Dec 2010, Jeroen van Meeuwen (Kolab Systems) wrote: On Tuesday, November 23, 2010 04:52:07 pm Henrique de Moraes Holschuh wrote: On Tue, 23 Nov 2010, Ond??ej Surý wrote: I was thinking how we can provide our users better experience and I suggest we either: a) drop the -2.4 suffix at all b) keep the -2.4 suffix and provide cyrus-imapd, cyrus-clients, etc. metapackages (the mysql, postgresql way) What is your opinion. I think that upstream is stable enough between 2.x releases now, that we could go the a) way. (b) please. Really. With 10 years of experience with this kind of stuff on top. (b) sounds perfectly reasonable and acceptable -though I won't be doing anything similar on the other ends of my spectrum. We may have to revisit this if the dynamics of cyrus upstream releases change too much, but this is the kind of decision we can only take after we've seen what happens with 2.4, 2.5 and 2.6 :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Active maintainers of Cyrus IMAPD
On Mon, 29 Nov 2010, tof+ali...@raceme.org wrote: while looking at the user list @ alioth I have found these inactive users (no mail from them in my mailbox in last year and more): Christophe Boyanique I suggest we remove them unless we hear from them (they are all in Cc:). I am still alive and interrested by the packaging of Cyrus in Debian. But I have no time to participate :( I am in reader mode, but if you want to keep only involved people I can unsubscribe. It is not about the mailing list, it is about write access to the alioth project... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#454498: status update?
On Tue, 23 Nov 2010, Ondřej Surý wrote: On Mon, Nov 22, 2010 at 23:00, Henrique de Moraes Holschuh h...@debian.org wrote: On Sun, 21 Nov 2010, Costin Gusa wrote: Is it ok to ask here about including uoa.gr autocreate/autosieve patches or should I file a bug against the newly 2.4.4? (I just found them prepared for 2.4.4 here: Unless one of the other Cyrus maintainers overrides me, those will be added only after they get merged upstream. That won't be me. I'm with hmh on that issue. I consider those patches too invasive to be included in stock Debian installation (no need to argue with me). Two votes against, then. That said, it *is* being merged upstream, but I understand there are a few problems still, and it might end up being targeted to a future 2.5 branch. I *really* don't want to ever deal with bugs about bad interaction of those patches and a murder cluster that uses online replication... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#454498: status update?
On Sun, 21 Nov 2010, Costin Gusa wrote: Is it ok to ask here about including uoa.gr autocreate/autosieve patches or should I file a bug against the newly 2.4.4? (I just found them prepared for 2.4.4 here: Unless one of the other Cyrus maintainers overrides me, those will be added only after they get merged upstream. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#454498: status update?
On Sat, 20 Nov 2010, Henrique de Moraes Holschuh wrote: On Fri, 19 Nov 2010, Costin Gusa wrote: It's almost a year since last message on this list, squeeze is frozen, cyrus stable is already 2.4.4. 2.4.4 is in experimental. Sorry, it is still in NEW. But it has been uploaded for experimental. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus IMAPD 2.4
On Wed, 17 Nov 2010, Jeroen van Meeuwen (Kolab Systems) wrote: On Wednesday, November 17, 2010 11:29:21 am Ondřej Surý wrote: I am still busy as always, but I am very close for a need for newer cyrus for our systems, so I might put some effort into it. I propose we just skip 2.3 and go directly for 2.4 for squeeze+1. FWIW, I second the motion. I agree with that (although I have now 2.3 in production). But we need to forward-port the patches (should be much easier now). In fact, for 2.4, we can even try the upstream first approach, since it sees a lot of code churn and timely new releases right now... BUT: upstream has not settled down on a workflow that allows for easy bug fixing patch flux that can be released with little notice when a very nasty bug gets fixed yet, so we might have to use a LOT of discretion before releasing a new upstream. But it looks like they have felt the need for that kind of workflow now, due to some nasty crap in 2.4.2/2.4.3 that wanted a quick fix+release, but there was unfinished work in the tree getting in the way. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus IMAPD 2.4: Release early, release often
On Wed, 17 Nov 2010, Ondřej Surý wrote: cyrus-imapd-2.4 has been uploaded to experimental. That said, we still don't have a clear upgrade path from 2.2 to 2.4. Upgrades from 2.3 to 2.4 will not be supported at all. FWIW, I just went through 2.1 - 2.3 and it is reasonably painless. 2.2-2.3 and 2.2-2.4 (and 2.3-2.4) are mostly automatic, BUT when they break you're screwed, so you need a backup of the old data, plus a fixed Cyrus to re-do the in-place upgrade... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus IMAPD 2.4
On Thu, 18 Nov 2010, Jeroen van Meeuwen (Kolab Systems) wrote: upstream has not settled down on a workflow that allows for easy bug fixing patch flux that can be released with little notice when a very nasty bug gets fixed yet, so we might have to use a LOT of discretion before releasing a new upstream. But it looks like they have felt the need for that kind of workflow now, due to some nasty crap in 2.4.2/2.4.3 that wanted a quick fix+release, but there was unfinished work in the tree getting in the way. Since I am the release engineer for upstream Cyrus now, I can make sure timely releases are being done (like, *actually done*), have patches be accepted (like, *actually committed* to at least master), be backported, and recommend releases be issued. Hmm, looks like we will have premium first class Cyrus support in Debian now :-) My suggestion is that you guys should make heavy use of topic branches, so that only stabilized work goes into the next-release branches. That should make it trivial to release fast when required, without hindering development. to this release. That said, I am strongly in favor of a weekly 2 bug-fix release over a month postponing 15 low hanging fruit bugs going in -I hope that makes sense ;-) It does. On an additional, more personal note, I have to admit I'm not all that great a coder; I'm more the kind of release engineer that trusts the people actually doing the coding and merely organizes the process around releasing / issue tracking / back-porting, etc. Which is an important job. The coders get distracted, well, coding :) A release manager is always a damn great help. We should know, being a distro... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus IMAPD 2.4
On Fri, 19 Nov 2010, Jeroen van Meeuwen (Kolab Systems) wrote: I hope to overcome some of the differences between various distributions, which primarily concern program, file and directory locations, as well as the work-arounds implemented for man-page naming conflicts, for example. Both are extremely important to the documentation effort upstream as well as downstream sometimes (e.g. a vendor such as Kolab Systems). Would anyone here have any thoughts on that subject? Sure. Create a master utility, let's say cyrus-imap-tool, that calls the utilities like reconstruct, ctl_mboxlist, etc. Then, install the real utilities in a private namespace (hardcoded at compile time), e.g. in Debian it would be in /usr/lib/cyrus-imap/tools or something like that. I.e. do what git did (including manpage access through --help, or through man master-tool-subcommand. This works, and since there is no namespace pollution issues, we won't have anymore stuff like cyrreconstruct in Debian where some other distros keep it as reconstruct, etc. The cyrus-imap-tool master tool can have a command to list each important path... And *please* rename the master daemon to cyrus-master or cyrmaster, as that is something that is likely to remain in the main namespace... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: [pkg-kolab] cyrus-imapd 2.3.16
On Wed, 01 Sep 2010, Jeroen van Meeuwen (Kolab Systems) wrote: Jeroen van Meeuwen (Kolab Systems) wrote: http://git.kolabsys.com/apt/kolab-cyrus-imapd/ Please hold that thought while I being to understand that I completely fail to work with git-buildpackage. One thing about git is that using it over http is *really* *painful* in the long run. Maybe you should try to get a native git server in there? git-buildpackage and the other git package helpers can be... weird. Good luck with them :p For one thing, there is absolutely NO packaged tool that can import a series of debian source packages to git without screwing up. All of them do very idiotic things, to the point that you start wondering if the people writing them grok git at all... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus hmh branch
On Wed, 18 Aug 2010, Dan White wrote: IOERROR: opening /var/lib/cyrus/user_deny.db: No such file or directory Those are local6.debug messages. You could modify your syslog configuration to disregard them. You actually have to. Cyrus logs a LOT of idiotic crap as LOG_DEBUG :-( On the grounds that this at the very least wastes a lot of resources even if filtered in the syslog daemon, I'd say it would be _nice_ to teach cyrus to not syslog() this stuff unless requested. But that's in the 'wishlist that should be fixed upstream' class. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: two cyrus debian dev branches?
On Tue, 10 Aug 2010, Andre Felipe Machado wrote: Thanks for your explanations. I am planning to test 2.3.16 backported to Lenny, for use with murder (sharding mail boxes). Is it possible to your team upload the hmh branch to experimental, in order to get more visibility and maybe more testers? Yes, but I am about 16 man-hours from being happy enough with it to merit an upload to experimental, and I haven't been able to put much work, just a couple man-hours per week so far. OTOH, I *did* put some work, and will upload it soon. But it was fixing-Debian-fixes-for-upstream-problems work so that we can send stuff upstream, with very minimal packaging work. Anyway, that branch is kept in a always-buildable state, and also in a should work well state. Note that we claim absolutely nothing about how well it will upgrade to future versions. One of the things I haven't done yet is to move stuff around and rename utilities with too-generic-a-name with a 'cyr' prefix. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#525391: cyrus-imapd-2.3: Can we get this into unstable yet?
On Thu, 15 Jul 2010, Matthieu PATOU wrote: Package: cyrus-imapd-2.3 Followup-For: Bug #525391 Almost one year since last report, and still no sign of life in sid, unstable, not to speak about testing or the future squeeze. New version of cyrus imap brings new functionnalities that could be useful to mail administrators and users. I'm for example thinking about the sharedseen flag that was introduced in 2.3.10. What is stopping/blocking the debian cyrus team to push it to sid ? There is some pending stuff we don't want uploaded to sid. We're also revising a bunch of patches with upstream right now, as well. A new upload to experimental should come soonish (2.3.16), and is already available (but not complete) in our SVN tree. SVN: https://mail.incase.de/svn/cyrus22/branches/cyrus23/cyrus-imapd-2.3-hmh/ If you're going to play with that, subscribe to the ML: https://alioth.debian.org/mail/?group_id=30579 -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: 13-master_process_handling.dpatch
On Fri, 02 Jul 2010, Patrick Goetz wrote:
OK, first small coding error that I've been able to find in a patch
so far. I'm putting it out there for comment unless I'm missing
something.
in 13-master_process_handling.dpatch,
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+int s = sizeof(struct notify_message);
should be
-- --
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+size_t s = sizeof(struct notify_message);
Any comments before I change this in the patch?
Depends on the rest of read_msg(), doesn't it? Let me look at the full
patch...
It should be ssize_t (note the double s), but int is safe.
I think that code is mine, from 10 years ago. Damn, looks ugly, it can
probably be done better :) I might rework it.
Don't send patch 12 and 13 upstream just yet. Let me go over them
again, I already have at least a proper header for them explaining what
they [attempt to] do, salvaged from the changelogs from the Cyrus 2.1
packages... some have links to bug reports, etc.
I also have some metadata for patch 08, basically we want those
shutdown() and close() because it helps reduce the time the sockets
spend on TIME_WAIT.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-Cyrus-imapd-Debian-devel mailing list
Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: building source packages from SVN
On Tue, 15 Jun 2010, Patrick Goetz wrote: Can one of you jot down for me the debian command(s) you typically use to build a source package from the SVN tree? dpkg-buildpackage -uc -us -rfakeroot Should be enough, at least on my tree. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: [SVN] r888 - in /branches/cyrus23/cyrus-imapd-2.3-hmh/debian: README.source changelog compat control cyrus-common-2.3.cyrus2.3.init cyrus-common-2.3.lintian cyrus-common-2.3.preinst executable.fil
On Fri, 07 May 2010, s...@incase.de wrote: hmh wrote: +Unpatch is not that smart, if a patch gets misapplied, it may fail to +revert things properly. If you have a fix for this, I am sure dpatch +would benefit from it :-) I assume you actually were to say quilt would benefit from it? Nah, it is about dpatch alright. Quilt is less dumb. You just found a bug in the doc :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: 2.3.16 code drop action?
On Wed, 20 Jan 2010, Henrique de Moraes Holschuh wrote: Well, it is not a the state I'd like, but its best I at least commit something instead of taking more time. The changelog needs more love, and I want to clean up more stuff before I even consider putting it forward as a candidate for an experimental or unstable upload. I had the opportunity and drive to clean it up further. debian/rules is a lot more sleek now, and I switched from dpatch to quilt for a number of reasons. The two main ones are: quilt is less prone to leaking cruft or misapplying patches, and dpkg-source format 3.0. Please comment on the packaging changes. There is also a README.source to help... I have gone over all the debian patches, and cleaned them up for 2.3.16. I will go over them again, many of those need a bit more care, and the ones which will be thruly useless when I am done with, need to be removed. This still needs to be done. The tree I am using is based on upstream tarball releases. I will keep an eye on the incremental work being done on the other cyrus 2.3 working branch (no, it is not entirely up-to-date yet). Merging all improvements from the other branches is next, so that I can use this thing at work :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Historic series for 2.2.x
Gentleman, one of these days I we will have a git-buildpackage that can properly import a series of Debian packages with a beautiful proper ladder commit and merge history without a lot of intervention, and I will go wild with it ;-) At that point, I'll try to produce a nice archive of our cyrus package history. I have managed to get almost all cyrus 2.1 packages that were uploaded, and if I really get around to it, I have all the history to at least produce the trees required for the very early ones from 2002-2004 when snapshot.d.n didn't exist (but getting a source package out of them might not be easy, and require a woody VM. oh dear...) I am now trying to find all the source packages we published for the 2.2 series, but snapshot.d.n is missing a lot of them. Anyone has them, perchance? Trying to get them out of SVN ain't the same, and it might not give me the exact package we shipped, anyway, so it is a last-resort option... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: r854 - in /branches/cyrus23/cyrus-imapd-2.3-development/debian: changelog control
On Sun, 17 Jan 2010, Dan White wrote: The master/cyrmaster daemon still has SNMP support via agentx. I can only find documentation for it in upstream in master(8). We should have that in cyrmaster(8)... That said, the snmp support is very incomplete, and you MUST be aware that you HAVE to restart cyrus if you ever restart snmpd, or the agentx interface will be gone. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Cyrus Debian patches - isdigit
(Cc to the Debian Cyrus-imap devel ML added) On Mon, 14 Dec 2009, Bron Gondwana wrote: I was just reading through your cyrus-2.3 packages in experimental because our current install process is to build a .tar.gz and then use alien to convert it to a .deb, which is pretty evil. I'd prefer to build real Debian packages at some point! Heh, those packages need a lot of love. I have some fixes, and the other two maintainers might have a few of their own as well. As the kernel merge window closes, I will shift some of my spare time from kernel-land to Debian-land, so I hope to commit a few cleanups to the experimental branch soon. We have an SVN tree that has much newer stuff than the packages in experimental, this URL will help you keep better track of the packages: http://packages.qa.debian.org/c/cyrus-imapd-2.3.html Anyway, I noticed that you're patching cyrus_isdigit back to isdigit in the sources, and wondered why. We originally replaced those calls because we found that isdigit was calling out to a utf-8 enabled library that caused a much more complex check than is required. It's I don't really know, as I didn't author that patch. But I will make sure we don't do that in the next round of uploads. actually parsing numbers which are guaranteed to only include [0-9], and the CPU usage was halved for SEEN-db intensive workloads when we made this change. The test really isn't for a fully-formed unicode digit, it's for 0-9. I'd be happy to rename it cyrus_is0to9 or something instead if that made the intent clearer! We really don't care if it's any other sort of digit. I'd support that rename :-) If 0to9 is too ugly, call it is_asciidigit() or somesuch, that should give anyone looking at the code the hint :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#555664: closed by Marco d'Itri m...@linux.it (Bug#555664: fixed in netbase 4.38)
On Mon, 07 Dec 2009, Klaus Ethgen wrote: On Sun, Dec 06, 2009 at 05:57:10PM +, Debian Bug Tracking System wrote: * etc-services: added sieve (4190/tcp). * etc-services: removed sieve (2000/tcp). (Closes: #555664) Uh, that's a very bad idea! managesieve is using port 2000 for long time now. To change it in service file ends in clients not able anymore to http://www.iana.org/assignments/port-numbers There is no kind way to fix this. It was a _very_ foolhardy move to have managesieve/timsieved on port 2000, instead of requesting an IANA allocation from day one. But that mistake is in the past, and it is too late to fix it. Sieve belongs on port 4190, and worse, something in widespread use needs port 2000, which IANA says belongs to it. So Sieve gets evicted. It *is* that simple. OTOH, I do think we will need to make this a lot more public, as it *will* break just about every professional cyrus install I know of (since everyone adds a sieve frontend of some sort). That change make debian incompatible to all managesieve installations out there! Everyone will have to move to the IANA-allocated port. So please revoke that change as soon as possible! That will *NOT* happen. And it wasn't us who changed things, anyway, and I would not waste my time trying to convice Marco to back down the change. He will not do it, and he is right in not doing so. But, as I said, I think we will need to publish this problem widely. And you *are* free to tell cyrmaster to listen to port 2000, you know. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#555664: marked as done (Port conflict between asterisk and cyrus-common)
On Mon, 07 Dec 2009, Marco d'Itri wrote: On Dec 07, Henrique de Moraes Holschuh h...@debian.org wrote: Marco, does netbase document such changes in a more user-visible place than the Debian changelog? No, I do not think it would be appropriate to use NEWS.Debian since very few users would be interested. Can you reconsider adding this to NEWS.Debian for netbase? It is going to break enough installs to cause problems, and while we will add a note in the Cyrus packages, the fact is that the change happens when the user installs the new netbase package makes adding a note just to Cyrus' NEWS.Debian far from optimal. ManageSeive is widely used by Cyrus installs, since one always uses Sieve configuration frontends (web-based most of the time). They often don't run on the same boxes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#555664: marked as done (Port conflict between asterisk and cyrus-common)
On Mon, 07 Dec 2009, Marco d'Itri wrote: On Dec 07, Henrique de Moraes Holschuh h...@debian.org wrote: No, I do not think it would be appropriate to use NEWS.Debian since very few users would be interested. Can you reconsider adding this to NEWS.Debian for netbase? http://qa.debian.org/popcon.php?package=cyrus-imapd-2.2 The number of affected systems is tiny, about 0.7%. Many users use upstream cyrus, and it will also hit users of other sieve-aware systems and clusters, not just cyrus. It is going to break enough installs to cause problems, and while we will add a note in the Cyrus packages, the fact is that the change happens when the user installs the new netbase package makes adding a note just to Cyrus' NEWS.Debian far from optimal. People who use stable will get the warning at the right time, people who use unstable must accept little inconveniences like these. I worry about the people who run testing, actually. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#555664: closed by Marco d'Itri m...@linux.it (Bug#555664: fixed in netbase 4.38)
On Mon, 07 Dec 2009, Dan White wrote: On 07/12/09 15:37 -0200, Henrique de Moraes Holschuh wrote: Out of curiosity, I just tried to do a: $sieveport = 'sieve'; instead of $sieveport = 2000; in my PHP Avelsieve config, but no go. PHP, or Avelsieve, will not do service name resolution like Cyrus, unfortunately. Hrnf, I bet that means it blows up on IPv6 as well, then. Just say no to PHP if you can help it (unfortunately, that's quite hard to do in the webmail business :( ). That said, I will send a message to cyrus-users and debian-user warning people about the change. I'd appreciate if you guys could file bugs on packages that use port 2000 (instead of the 'sieve' service name) by default to fix their config files as well. Let's reduce the problem space to existing cluster installs as much as we can, at the very least. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#556388: Problem with cyrus-common-2.2.postinst script
On Sat, 21 Nov 2009, Sven Müller wrote: Henrique, you probably know this better than anyone else in the packaging team, so: Could we skip this script during package upgrades? I think so. In fact, I am not sure we still need this script at all, it is stuff from 2002, Cyrus has came a long way since... I actually even think we don't need the --cleansquat here, even during upgrade from 2.2, since the format doesn't seem to have changed. AFAIK, it hasn't changed, so we shouldn't need it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Trying to update our experimental 2.3 branch to 2.3.15
As you have probably noticed, I did some small cleanups on the tarballs in the repository... the cruft was nagging me for some weird reason or another. If you disagree with any of the cleanups, just revert them, I won't object ;-) I will now try to upgrade the cyrus23 branch to 2.3.15. I will not commit until it is working, just to make sure I don't make a mess of what we already have :) If any of you guys have it already done, this is the time to tell me about it... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#547947: CVE-2009-3235: CMU sieve buffer overflows
found 547947 2.2.12-1 fixed 547947 2.2.13-10+etch2 fixed 547947 2.2.13-14+lenny1 thanks On Tue, 22 Sep 2009, Benjamin Seidenberg wrote: fixed 547947 2.2.13-15 thanks A fix was released before the CVE was even published Indeed. I am not sure how old this bug is, it might well go going further back than 2.2.12, but that won't matter to Debian. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#547947: CVE-2009-3235: CMU sieve buffer overflows
notfixed 547947 2.2.13-10+etch2 notfixed 547947 2.2.13-14+lenny1 tag 547947 + confirmed thanks Well, it looks like we need to go another round of security updates for Cyrus. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: Bug#547947: CVE-2009-3235: CMU sieve buffer overflows
Full patch for cve-2009-3235 for cyrus-imap-2.2. One hunk of bc_eval.c
doesn't apply to the older version (no BC_BODY handling).
I will commit it to the trunk in a few minutes.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
Index: sieve/script.c
===
--- sieve/script.c (revision 842)
+++ sieve/script.c (working copy)
@@ -526,9 +526,9 @@
if ((ret != SIEVE_OK) interp-err) {
char buf[1024];
if (lastaction == -1) /* we never executed an action */
- sprintf(buf, %s, errmsg ? errmsg : sieve_errstr(ret));
+ snprintf(buf, sizeof(buf), %s, errmsg ? errmsg : sieve_errstr(ret));
else
- sprintf(buf, %s: %s, action_to_string(lastaction),
+ snprintf(buf, sizeof(buf), %s: %s, action_to_string(lastaction),
errmsg ? errmsg : sieve_errstr(ret));
ret |= interp-execute_err(buf, interp-interp_context,
Index: sieve/sieve.y
===
--- sieve/sieve.y (revision 842)
+++ sieve/sieve.y (working copy)
@@ -923,7 +923,7 @@
else if (!strcmp(r, ne)) {return NE;}
else if (!strcmp(r, eq)) {return EQ;}
else{
- sprintf(errbuf, flag '%s': not a valid relational operation, r);
+ snprintf(errbuf, sizeof(errbuf), flag '%s': not a valid relational operation, r);
yyerror(errbuf);
return -1;
}
Index: sieve/bc_eval.c
===
--- sieve/bc_eval.c (revision 842)
+++ sieve/bc_eval.c (working copy)
@@ -440,7 +440,7 @@
int comparator=ntohl(bc[i+3].value);
int apart=ntohl(bc[i+4].value);
int count=0;
- char scount[3];
+ char scount[21];
int isReg = (match==B_REGEX);
int ctag = 0;
regex_t *reg;
@@ -608,7 +608,7 @@
int relation=ntohl(bc[i+2].value);
int comparator=ntohl(bc[i+3].value);
int count=0;
- char scount[3];
+ char scount[21];
int isReg = (match==B_REGEX);
int ctag = 0;
regex_t *reg;
___
Pkg-Cyrus-imapd-Debian-devel mailing list
Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Accepted cyrus-imapd-2.2 2.2.13-17 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 22 Sep 2009 17:17:17 -0300 Source: cyrus-imapd-2.2 Binary: cyrus-common-2.2 cyrus-doc-2.2 cyrus-imapd-2.2 cyrus-pop3d-2.2 cyrus-admin-2.2 cyrus-murder-2.2 cyrus-nntpd-2.2 cyrus-clients-2.2 cyrus-dev-2.2 libcyrus-imap-perl22 Architecture: source all i386 Version: 2.2.13-17 Distribution: unstable Urgency: high Maintainer: Henrique de Moraes Holschuh h...@debian.org Changed-By: Henrique de Moraes Holschuh h...@debian.org Description: cyrus-admin-2.2 - Cyrus mail system - administration tools cyrus-clients-2.2 - Cyrus mail system (test clients) cyrus-common-2.2 - Cyrus mail system - common files cyrus-dev-2.2 - Cyrus mail system (developer files) cyrus-doc-2.2 - Cyrus mail system - documentation files cyrus-imapd-2.2 - Cyrus mail system - IMAP support cyrus-murder-2.2 - Cyrus mail system (proxies and aggregator) cyrus-nntpd-2.2 - Cyrus mail system (NNTP support) cyrus-pop3d-2.2 - Cyrus mail system - POP3 support libcyrus-imap-perl22 - Interface to Cyrus imap client imclient library Closes: 547947 Changes: cyrus-imapd-2.2 (2.2.13-17) unstable; urgency=high . * Security Update: CVE-2009-3235: Multiple stack-based buffer overflows in the Sieve parsing code, patches taken from upstream CVS (closes: #547947) Checksums-Sha1: dd9c7bce7171080c1ce040de9067708b983a01af 2188 cyrus-imapd-2.2_2.2.13-17.dsc 2377d8ddbb12f62790041c2819ab74eabdb1 264147 cyrus-imapd-2.2_2.2.13-17.diff.gz 3e327104046b62afba9a75433277b5b7095f4792 223104 cyrus-doc-2.2_2.2.13-17_all.deb f5aa48ebbb85c7f0ce11922c50653f01b97e187e 82862 cyrus-admin-2.2_2.2.13-17_all.deb fcd6efb6062f0e94ba65c73626ad123ca2fd58ec 5569126 cyrus-common-2.2_2.2.13-17_i386.deb 898aab0b6eea88cbf80756367b5e2ca4cdd63239 914888 cyrus-imapd-2.2_2.2.13-17_i386.deb cd3571d823634b7b27533410fc5edbd821faea95 273748 cyrus-pop3d-2.2_2.2.13-17_i386.deb f8853944bb29577f53ee9dcbe474981d89a4f53a 1108422 cyrus-murder-2.2_2.2.13-17_i386.deb 13ae41b06da71c9f5119c1b4233645530fc7c442 593234 cyrus-nntpd-2.2_2.2.13-17_i386.deb e32d6d2a6655e86c7e93bb43bd1d415da73eb31f 131102 cyrus-clients-2.2_2.2.13-17_i386.deb 31a010d27bfc87b9101933a06e2d549bbcf850be 264628 cyrus-dev-2.2_2.2.13-17_i386.deb 8c65671522aec415ba6de39158756c1aeef577aa 181834 libcyrus-imap-perl22_2.2.13-17_i386.deb Checksums-Sha256: c2f32f4b88921c30d2035db1dfd5b8ed314ddb03522bf5893dffab89f14de1e0 2188 cyrus-imapd-2.2_2.2.13-17.dsc bf1bf78334c63904a859683146415abe4fb76bbdb737ebacef9289439d6821c5 264147 cyrus-imapd-2.2_2.2.13-17.diff.gz 30f310edab9b9564ff2b61718c242e23fe1ade73173862d4c5ef71cb2ee79809 223104 cyrus-doc-2.2_2.2.13-17_all.deb 27e3d4cfe6a272f2e6db9c19161e0ae1f8ea434f835b6ce97a3f0c2d720ffcd8 82862 cyrus-admin-2.2_2.2.13-17_all.deb c889117ca6ac3ca9cb77b6f7fdf498e238914e6a6e128ca52b9699845809f5d1 5569126 cyrus-common-2.2_2.2.13-17_i386.deb 225274b752f52db89207477a0748c1e7a8a08d367a9a0fb618aba910f31219c6 914888 cyrus-imapd-2.2_2.2.13-17_i386.deb 7e6f81846093e188826d59258bacfe1f32aea352bbcf47ab3988dc8d57103a44 273748 cyrus-pop3d-2.2_2.2.13-17_i386.deb aad792dfe0ad3fae19f6393d5412418d7c8a4a65cd493330362ce3afbbfa62a9 1108422 cyrus-murder-2.2_2.2.13-17_i386.deb 42314027327d30de0943b6180df79ba3d3fc2118c90028450dfdef572c2af10c 593234 cyrus-nntpd-2.2_2.2.13-17_i386.deb 51b6d28055c5496c1ab6283db542e5382f0681ea4a9cd40cf00696ded84dd199 131102 cyrus-clients-2.2_2.2.13-17_i386.deb ff8f2b71d759041dfe8b5c26d256fb59428ca3e1a8b9dafb0806ada8ed9a5fa5 264628 cyrus-dev-2.2_2.2.13-17_i386.deb 1327ccec366134a8709adc48c6a7e3bdc1cdb6bbd33f048465d2152951635b3e 181834 libcyrus-imap-perl22_2.2.13-17_i386.deb Files: a63485b82141fb19bc27bf2c7d2dd093 2188 mail extra cyrus-imapd-2.2_2.2.13-17.dsc 1df5acae785f5935618033bac2693250 264147 mail extra cyrus-imapd-2.2_2.2.13-17.diff.gz 2ff32d7770238bc5297c6dc81a7195ae 223104 doc extra cyrus-doc-2.2_2.2.13-17_all.deb 26fa1e619890f4aaa4572b8b8fa8acab 82862 mail extra cyrus-admin-2.2_2.2.13-17_all.deb 83152af1491876f4058f6fa6920ed071 5569126 mail extra cyrus-common-2.2_2.2.13-17_i386.deb cc8a952ff767c0bfd7049a3eba8c0440 914888 mail extra cyrus-imapd-2.2_2.2.13-17_i386.deb b5ea42d096d51378664a69936cb93ab1 273748 mail extra cyrus-pop3d-2.2_2.2.13-17_i386.deb b235a2be339db99e89b88bbbe386030a 1108422 mail extra cyrus-murder-2.2_2.2.13-17_i386.deb 684b396ff23dd4bee26ac7a9f6eb7573 593234 mail extra cyrus-nntpd-2.2_2.2.13-17_i386.deb 5f92397b1c2bb919f01c16904eef5021 131102 mail extra cyrus-clients-2.2_2.2.13-17_i386.deb 29d70bae4d46149dcbe86994e89d1ffc 264628 devel extra cyrus-dev-2.2_2.2.13-17_i386.deb 2000b0b07235264eed63fb0f38c5234a 181834 perl extra libcyrus-imap-perl22_2.2.13-17_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCgAGBQJKuYpwAAoJEKwN24xXhzJzdbcH/09Bv+pZ6uKb9H/jgzDYpEn2 S8ZELf/FL/s5aR9V1U7ICVUvqZmycqtC+7X4/TrZzkn16sY4275ueiU4IV8XAfhW SHUAOU3tWOJ2FPP0p/68/zMf44enFYKkTeMnkU/rpGXYJK4P5dM2ZCfPy5tEHBtA
Re: cyrus-imapd-2.2: New upstream version available
On Fri, 11 Sep 2009, Sven Mueller wrote: Debian External Health System schrieb: The Debian External Health Status system (a.k.a. DEHS) has found a new upstream version of the package cyrus-imapd-2.2 in the unstable distribution. The current package version is 2.2.13-16 and latest by upstream is 2.2.13p1. Apart from the obvious thing (the security patch), they also updated some of the error string handling. I don't see any security issue in that part of the code (old or new). However, the real question is: Should we release a 2.2.13p1-1 for unstable+squeeze? Why not? An update is an update, bug fixes are bug fixes, and it will make version-based security scanners a lot happier. Or should we only do that if/when we also update to a newer BerkeleyDB? If we release often, we have better checkpoints to hunt down bugs. It would be nice to know if something broke because of the new upstream, or because of BDB, and releasing the new upstream now (without the newer BDB) would help with that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
Re: 2.3/Sid release engineering (was Re: Missing autoconf build-dependancy in cyrus-imapd-2.3 branch ?)
On Fri, 31 Jul 2009, Sven Mueller wrote: While I agree in general, this is causing a big task: Write a script that is able to locate all the BDB files in question That script is only necessary if we ever shipped BDB for per-user databases (seen, etc) in Cyrus 2.2. Otherwise it is OK to just tell the user to do it himself. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-Cyrus-imapd-Debian-devel mailing list Pkg-Cyrus-imapd-Debian-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
