Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Christian Perrier schrieb: > Quoting Sven Mueller ([EMAIL PROTECTED]): > >> the current SVN head (available at >> https://mail.incase.de/svn/cyrus22/trunk) where I could also grant > > > Could you give me the SVN checkout URL so that I get a non anonymous > copy and thus can commit ? > > I saw that you guys committed most of the incoming translations > indeed, so that might be useless, but who knows ? For non-anonymous checkout you might use https://[EMAIL PROTECTED]/svn/cyrus22/trunk or svn co --username bubulle https://mail.incase.de/svn/cyrus22/trunk And if I'm not mistaken, I did indeed check in all translations except for the "Norwegian Bokmål" (nb) one. cu, Sven signature.asc Description: OpenPGP digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Quoting Sven Mueller ([EMAIL PROTECTED]): > the current SVN head (available at > https://mail.incase.de/svn/cyrus22/trunk) where I could also grant Could you give me the SVN checkout URL so that I get a non anonymous copy and thus can commit ? I saw that you guys committed most of the incoming translations indeed, so that might be useless, but who knows ? signature.asc Description: Digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Christian Perrier wrote on 31/03/2008 18:24: Quoting Benjamin Seidenberg ([EMAIL PROTECTED]): Task #1: Implement IP stack on top of UDP for class Task #2: Implement message passing in my mini-operating system for other class Task #3: Work on cyrus. If someone wants to send me an all inclusive diff to avoid an NMU, I will go ahead and use it and prepare an upload. As neither the LSB header issue not the l10n fixes are urgent, I propose you that I handle this just like a regular l10n NMU, including a 10-days translation update round. Then, instead of building/uploading the NMU, I send you the patch (thus including the fix for LSB headers, the l10n changes and other QA fixes I found...plus the needed debian/changelog entries, with the Closes: statements)and wait for a regular upload. Would that fit with your own plans ? It would be highly appreciated if any of your patches could be against the current SVN head (available at https://mail.incase.de/svn/cyrus22/trunk) where I could also grant commit rights to you if you tell me which username/password combo you want (by gpg encrypted mail). Note that I just committed fixes for the following issues: * Fix init script LSB header (closes: 470110) * Update logcheck rules and the rule filenames (closes: 473526) (Right before I got your mail.) The galician translation update was already incorporated in the 2.2.13-13 upload. The portoguese translation already is in SVN anyway. Any additional fixes are quite welcome. Due to all the stuff I currently need to do I don't know when I will be able to build, test and upload a new package. I might be able to do that this week or next weekend, but I can't guarantee a thing. Regards, Sven signature.asc Description: OpenPGP digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Quoting Benjamin Seidenberg ([EMAIL PROTECTED]): > Task #1: Implement IP stack on top of UDP for class > Task #2: Implement message passing in my mini-operating system for other > class > Task #3: Work on cyrus. > > If someone wants to send me an all inclusive diff to avoid an NMU, I > will go ahead and use it and prepare an upload. As neither the LSB header issue not the l10n fixes are urgent, I propose you that I handle this just like a regular l10n NMU, including a 10-days translation update round. Then, instead of building/uploading the NMU, I send you the patch (thus including the fix for LSB headers, the l10n changes and other QA fixes I found...plus the needed debian/changelog entries, with the Closes: statements)and wait for a regular upload. Would that fit with your own plans ? signature.asc Description: Digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Task #1: Implement IP stack on top of UDP for class Task #2: Implement message passing in my mini-operating system for other class Task #3: Work on cyrus. If someone wants to send me an all inclusive diff to avoid an NMU, I will go ahead and use it and prepare an upload. Otherwise, I'm hoping someone else on the team *cough*Sven*cough* could maybe prepare an upload. Benjamin Christian Perrier wrote: > Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): > >> Any hope of having the init.d dependency information fixed soon? >> > > > I'm working on an l10n NMU which I started preparing yesterday. > > In that process, I generally look over the said package BTS and also > fix trivial QA issues. This one went on my radar and the fix is > already there. > > The l10n NMU process is pretty long: > - 2 week maintainer nnotification delay > - 10 days translation update round > > Also, the maintainer(s) of the package can object to the NMU which I > suspend when they do. However, I keep the package on my radar and, in > (the very rare) case nothing happens, I NMU anyway. > > In short, the fix should come at least in about 3-4 weeks. > > In this process, I already fixed and will contineu to fix many other > LSB-headers related issues, by the way.. (missing ones, most of the > time). > > > > > > > ___ > Pkg-Cyrus-imapd-Debian-devel mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel signature.asc Description: OpenPGP digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): > > Any hope of having the init.d dependency information fixed soon? I'm working on an l10n NMU which I started preparing yesterday. In that process, I generally look over the said package BTS and also fix trivial QA issues. This one went on my radar and the fix is already there. The l10n NMU process is pretty long: - 2 week maintainer nnotification delay - 10 days translation update round Also, the maintainer(s) of the package can object to the NMU which I suspend when they do. However, I keep the package on my radar and, in (the very rare) case nothing happens, I NMU anyway. In short, the fix should come at least in about 3-4 weeks. In this process, I already fixed and will contineu to fix many other LSB-headers related issues, by the way.. (missing ones, most of the time). signature.asc Description: Digital signature
Bug#470110: cyrus-common-2.2: Problem with LSB header in init.d script
Package: cyrus-common-2.2 Version: 2.2.12-0.6 Severity: important Tags: patch User: [EMAIL PROTECTED] Usertags: incorrect-dependency I just checked the shutdown order in unstable on a machine with dependency based boot sequencing enabled, and discovered a problem with the init.d scripts provided in the cyrus-common-2.2 package. It stops to late and start to early, as it do not depend on $remote_fs which guarantee that /usr/ will be mounted and that it stops before sendsigs. Another issue is that the init.d script list S in its stop runlevel list. This make a useless stop symlink in rcS.d/, and S should not be included there. Here is a patch to solve these issues. diff -ur cyrus-imapd-2.2-2.2.13.orig/debian/cyrus-common-2.2.cyrus2.2.init cyrus-imapd-2.2-2.2.13/debian/cyrus-common-2.2.cyrus2.2.init --- cyrus-imapd-2.2-2.2.13.orig/debian/cyrus-common-2.2.cyrus2.2.init 2008-03-09 08:44:30.0 +0100 +++ cyrus-imapd-2.2-2.2.13/debian/cyrus-common-2.2.cyrus2.2.init 2008-03-09 08:45:26.0 +0100 @@ -2,10 +2,10 @@ # ### BEGIN INIT INFO # Provides: cyrus-common-2.2 -# Required-Start: $syslog $network -# Required-Stop: $syslog $network +# Required-Start: $remote_fs $syslog $network +# Required-Stop: $remote_fs $syslog $network # Default-Start: 2 3 4 5 -# Default-Stop: S 0 1 6 +# Default-Stop: 0 1 6 # Short-Description: common init system for cyrus 2.2 IMAP/POP3 daemons. # Description: common init system the for cyrus 2.2 IMAP/POP3 daemons. # starts the central cyrus 2.2 master process, which can Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
