Bug#691488: cron: bytes variable in do_command.c/child_process() is always 1
Package: cron Version: 3.0pl1-124 Severity: minor The patches, including the latest -124, removed incrementing of the 'bytes' variable, so when the mail process fails, there is always 1 in log message: (mailed 1 byte of output; but got status ... It would also be great if the log message included, where the status was got from. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#349957: non-ascii bytes cause shunting of some replied cmd messages (attached)
Thijs Kinkhorst wrote: Hello Vlada, thanks for your response. I think I'll have to get comfortable with the status quo. I surely don't blame you for it. instead I'm grateful for the time and effort you put in. It seems the backports.org package for 2.1.7 is going to be created upon my request. If so and I successfully upgrade on my sarge system with several active mailing lists, I'll report more on the bug or patch it in the code. Additionally, it could be reported upstream then. Just following up here - do you still experience the problem? Thijs Thanks for a care. Unfortunately I was unable to even test the 2.1.7 in the meanwhile. Also my users mysteriously stopped sending e-mail commands to Mailman, so the problem does not occur. Therefore I didn't fight for a change with 2.1.7. -- \//\/\ begin:vcard fn:Vlada Macek n:Macek;Vlada adr:;;;Liberec;;;Czech Republic email;internet:[EMAIL PROTECTED] title:UNIX Admin Developer tel;cell:+420 608 978 164 note;quoted-printable:GPG info: key 0x1F059424, fingerprint 1494 F8DD 6379 4CD7 E7E3 1FC9 D750= 4243 1F05 9424=0D=0A= =0D=0A= When you find a virus in mail from me, then I intended to infect you, sin= ce I use SW that is not distributing malware w/o my knowledge.=0D=0A= =0D=0A= x-mozilla-html:FALSE version:2.1 end:vcard
Bug#349957: non-ascii bytes cause shunting of some replied cmd messages (attached)
Lionel, thanks for your response. I think I'll have to get comfortable with the status quo. I surely don't blame you for it. instead I'm grateful for the time and effort you put in. It seems the backports.org package for 2.1.7 is going to be created upon my request. If so and I successfully upgrade on my sarge system with several active mailing lists, I'll report more on the bug or patch it in the code. Additionally, it could be reported upstream then. Vlada Lionel Elie Mamane wrote: ... I can't say I disagree that trying to keep the latest stable branch as bug-free as possible would be a laudable / desirable goal, but that is not the current Debian procedures. The way Debian, and most GNU/Linux distributions, works is: - At some point in time, a release is made. In our case, Debian 3.1 sarge in the middle of 2005. - Nothing at all is changed in sarge, bugs there stay there, except for security updates and really critical bugs. - In the meantime, a new release is being prepared, in our case etch (which will be numbered Debian 3.2 or maybe 4.0). Non-critical / security bugs get corrected in the development cycle of this new release. See http://www.debian.org/releases/ . You can try to convince Debian to change its way of working, but if you go this route, good luck. Won't be easy. (The right contact is [EMAIL PROTECTED]) ... I'm not saying that running a mixed stable / testing Debian is necessarily a good idea, but if you want non-criticl/security bugs corrected before the new release your choices currently are: - Run a mixed stable / testing Debian and take the packages that are too buggy in stable from testing. - Backport the packages from testing yourself. - Convince someone at http://backport.org/ to do that. - Magic That is suboptimal, but out of my control. Sorry for that. begin:vcard fn:Vlada Macek n:Macek;Vlada adr:;;;Liberec;;;Czech Republic email;internet:[EMAIL PROTECTED] title:UNIX Admin Developer tel;cell:+420 608 978 164 x-mozilla-html:FALSE version:2.1 end:vcard
Bug#349957: [Pkg-mailman-hackers] Bug#349957: non-ascii bytes cause shunting of some replied cmd messages (attached)
Lionel Elie Mamane wrote: On Thu, Jan 26, 2006 at 09:34:36AM +0100, Vlada Macek wrote: Shunted message (displayed by show_qfiles) is attached. It's a usual confirmation message replied by the user. It's localized to Czech (l10n from the package unchanged). I can't reproduce this with 2.1.6. I subscribed a user in Czech, quoting the whole confirmation mail in the reply, it works. I tried both sending the reply by UTF-8 and ISO-8859-2. The bug was filed against the different package mailman version than the one you're using for reproduction tests! Therefore I think you should not mark it as unreproducible. As a user I expect fixing the package that is in my server's Sarge distribution, which stays on version 2.1.5-8sarge1 currently. Or is there something I do not know? IMHO the packages in current Debian Stable should be kept free of known bugs, maybe by backporting fixes from newer upstream releases. Users are not generally going to upgrade some package ad-hoc from other sources, unless it's not some parallel and well known APT repository, such as the one for newer releases of PostgreSQL. -- \//\/\ (Sometimes credited as BA92 C339 6DD2 51F6 BACB 4C1B 5470 360E 20E5 926D.) [ When you find a virus in mail from me, then I intended to infect you, ] [ since I use SW that is not distributing viruses w/o my knowledge. ] begin:vcard fn:Vlada Macek n:Macek;Vlada adr:;;;Liberec;;;Czech Republic email;internet:[EMAIL PROTECTED] title:UNIX Admin Developer tel;cell:+420 608 978 164 x-mozilla-html:FALSE version:2.1 end:vcard
Bug#349957: non-ascii bytes cause shunting of some replied cmd messages (attached)
Package: mailman Version: 2.1.5-8sarge1 Severity: important # cat /etc/environment LANGUAGE=en_CZ:en_US:en_GB:en LANG=en_US.UTF-8 Shunted message (displayed by show_qfiles) is attached. It's a usual confirmation message replied by the user. It's localized to Czech (l10n from the package unchanged). Not every replied confirmation command causes this, but indeed it's an annoying bug, since I have to instruct all subscribers to use the web confirmation method instead, since the e-mail one is buggy. Otherwise the mailman works great. The exception from the error log: Jan 25 21:59:47 2006 (6046) Uncaught runner exception: 'ascii' codec can't decode byte 0xed in position 27: ordinal not in range(128) Jan 25 21:59:47 2006 (6046) Traceback (most recent call last): File /usr/lib/mailman/Mailman/Queue/Runner.py, line 111, in _oneloop self._onefile(msg, msgdata) File /usr/lib/mailman/Mailman/Queue/Runner.py, line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File /usr/lib/mailman/Mailman/Queue/CommandRunner.py, line 237, in _dispose res.process() File /usr/lib/mailman/Mailman/Queue/CommandRunner.py, line 110, in process stop = self.do_command(cmd, args) File /usr/lib/mailman/Mailman/Queue/CommandRunner.py, line 137, in do_command return handler.process(self, args) File /usr/lib/mailman/Mailman/Commands/cmd_confirm.py, line 86, in process if line.lstrip() == match: UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 27: ordinal not in range(128) Jan 25 21:59:47 2006 (6046) SHUNTING: 1138222787.610503+e1e14ee83e0e657b430575a3ba9bf5a4d6cef82e -- \//\/\ (Sometimes credited as BA92 C339 6DD2 51F6 BACB 4C1B 5470 360E 20E5 926D.) [ When you find a virus in mail from me, then I intended to infect you, ] [ since I use SW that is not distributing viruses w/o my knowledge. ] 1138222787.610503+e1e14ee83e0e657b430575a3ba9bf5a4d6cef82e.pck Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from localhost (localhost [127.0.0.1]) by sandbox.cz (Postfix) with ESMTP id 3EAB529F6C for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:47 +0100 (CET) Received: from sandbox.cz ([127.0.0.1]) by localhost (sandbox [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14823-02 for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:45 +0100 (CET) Received: from smtp-out3.iol.cz (smtp-out3.iol.cz [194.228.2.91]) by sandbox.cz (Postfix) with ESMTP id EFBD429F6B for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:44 +0100 (CET) Received: from antivir3.iol.cz (unknown [192.168.30.206]) by smtp-out3.iol.cz (Postfix) with ESMTP id 1B3FCE8484 for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:44 +0100 (CET) Received: from localhost (antivir3.iol.cz [127.0.0.1]) by antivir3.iol.cz (Postfix) with ESMTP id 0E1D4420015 for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:44 +0100 (CET) Received: from smtp-out3.iol.cz (unknown [192.168.30.28]) by antivir3.iol.cz (Postfix) with ESMTP id F0342420014 for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:43 +0100 (CET) Received: from [83.208.204.188] (188.204.broadband2.iol.cz [83.208.204.188]) by smtp-out3.iol.cz (Postfix) with ESMTP id 931373BE43 for [EMAIL PROTECTED]; Wed, 25 Jan 2006 21:59:43 +0100 (CET) Received: from 127.0.0.1 (AVG SMTP
Bug#340724: Missing commands: Watch Thread / Ignore Thread
Package: mozilla-thunderbird Version: 1.0.2-2.sarge1.0.7 I was unable to find the command to Watch current thread or to Ignore it. No UI for it seem to be accessible by a user -- with one exception: In View / Threads menu there are two items: Watched Thread with Unread and Ignored Threads. But there are the viewing selection commands, not the flagging ones. According to some discussions found on the Net, the Watch Thread command should be somewhere near the bottom of the Message menu. In case I was just blind to see what I was after, please consider this bug report as the one informing the developers that the feature is not as intuitive as it should be. :-) -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)Pa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340724: Missing commands: Watch Thread / Ignore Thread
[At 25.11.2005 13:29, Alexander Sack - Debian Bugmail kindly sent the following quotation.] On Fri, Nov 25, 2005 at 01:04:08PM +0100, Vlada Macek wrote: Package: mozilla-thunderbird Version: 1.0.2-2.sarge1.0.7 I was unable to find the command to Watch current thread or to Ignore it. No UI for it seem to be accessible by a user -- with one exception: In View / Threads menu there are two items: Watched Thread with Unread and Ignored Threads. But there are the viewing selection commands, not the flagging ones. flagging ones? Never heard of that before. You sure such a thing exists for mail? AFAIK, there are more threading options for newsgroups ... maybe you can take a look if that's what you refer to? Alexander, I'm sorry, I never learnt that the Watch Thread and Ignore Thread features are available to newsgroups only. I tested it now with a free news server and it works like a charm. Very sad to me such feature is not available for mail. As many other people, I'm subscribed to several lists, some of them are heavy and I would really welcome the ability to watch threads (mainly those I started myself). (At least those two items Watched Thread with Unread and Ignored Threads should currently be made invisible too when viewing mail.) I hope this report may be taken as a feature request then. Otherwise please nuke it. Thank you. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339691: vacation does not wait for its sendmail child
[At 18.11.2005 18:08, Steve Langasek kindly sent the following quotation.] On Fri, Nov 18, 2005 at 05:46:12PM +0100, Vlada Macek wrote: No, I think this is a bogus assumption on the part of maildrop, not a megabug in vacation. I don't see any reason why maildrop should be either setting a process group, or killing the group, under such circumstances. I think it's still a bug in vacation to not check the exit value of the commmand it spawns, but I believe the larger bug is maildrop's. Well, I stand for a different philosophy. Unless some process is designed and set up to run standalone (daemon), it should never be left on its own by a parent. There should never be any zombies. Zombies mean lame programmers. And the way to avoid zombies is by installing a proper SIGCHLD handler, *not* by killing child processes at an arbitrary point of the parent's choosing. I'm afraid you don't get the situation right. (But of course, I'm not omniscient.) We are talking the maildrop bug as you call it, right? I call the behavior a contribution to a good policy. First, there is maildrop - vacation - sendmail fork/exec chain. Sendmail makes an expensive job itself, so it's impossible to finish it until the vacation-parent exits without waiting. Maildrop now assumes the delivery is completed and kills the process group (no mess past me). There really *should*not* exist any sub-processes at this time, unless ones designed to run independently (establishing their own process group/sessions). How could installing a SIGCHLD handler on the part of maildrop help this all? His child vacation has exited, maildrop waits for it. SIGCHLD might be delivered from vacation to maildrop, but it has nothing to do with the zombie sendmail still running... If vacation did what it MUST do (reaping the sendmail by waiting), nothing bad would happen. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339691: vacation does not wait for its sendmail child
[At 18.11.2005 08:23, Steve Langasek kindly sent the following quotation.] On Fri, Nov 18, 2005 at 01:17:43AM +0100, Vlada Macek wrote: Vacation does not wait for its sendmail child to die in any way and exits! Therefore accurate vacation parent (such as maildrop MDA) wipes forked and executed sendmail before it could send any message... Huh? Why is that a reasonable thing for the MDA to do? As I was reading its source, Maildrop just cleans up its own mess, which is rather creditable I think. It sets a process group at the beginning and does (void)kill( -getprocgroup(), SIGHUP ); in the cleanup() method. It's probably more than most of the parent processes do out there, but at least it reveals such megabugs like that of vacation. I don't know whether the package maintainer is viable (there is at least one other serious bug for vacation), but I plead for fixing this bug. It cost me more than I day of desperation to find it, since I completely trust Postfix-MTA code and it looked like Postfix was swallowing the messages... Once fixed, other users wont be hurt anymore. Thanks in advance. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339691: vacation does not wait for its sendmail child
[At 18.11.2005 16:35, Steve Langasek kindly sent the following quotation.] (void)kill( -getprocgroup(), SIGHUP ); in the cleanup() method. It's probably more than most of the parent processes do out there, but at least it reveals such megabugs like that of vacation. No, I think this is a bogus assumption on the part of maildrop, not a megabug in vacation. I don't see any reason why maildrop should be either setting a process group, or killing the group, under such circumstances. I think it's still a bug in vacation to not check the exit value of the commmand it spawns, but I believe the larger bug is maildrop's. Well, I stand for a different philosophy. Unless some process is designed and set up to run standalone (daemon), it should never be left on its own by a parent. There should never be any zombies. Zombies mean lame programmers. So when there is a cop (maildrop here), who can avoid the state of zombies slowly polluting the machine, which is easily reachable especially in mass mail delivery sites, I count it's ok. What would be a reason of running any child-child-child zombies after the maildrop exit? None, I think. If the process chain is alive and long running, then it's IMO not optimal, but tolerable. Therefore that must be a major vacation bug and its authors should go read Stevens (again). I would let maildrop doing a good work protecting the machine, but of course I have no word here except this jaw-jaw. :-) Have a nice $DAY_PHASE. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339691: vacation does not wait for its sendmail child
Package: vacation
Version: 3.3.0
Severity: grave
Tags: patch
Vacation does not wait for its sendmail child to die in any way and exits!
Therefore accurate vacation parent (such as maildrop MDA) wipes forked
and executed sendmail before it could send any message...
Also multiple events that deserve it are not logged.
Patch for both flaws is attached.
--
\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)
diff -U3 -r vacation-3.3.0-orig/vacation.c vacation-3.3.0/vacation.c
--- vacation-3.3.0-orig/vacation.c 2005-11-17 23:42:32.0 +0100
+++ vacation-3.3.0/vacation.c 2005-11-18 00:55:30.0 +0100
@@ -74,6 +74,9 @@
#include fcntl.h
#include sys/param.h
#include sys/stat.h
+#include sys/types.h
+#include sys/wait.h
+
#ifdef HAVE_PATHS_H
# include paths.h
#else
@@ -232,7 +235,7 @@
}
if (msgfilename[0] != '/' || dbfilename[0] != '/')
if (chdir(pw-pw_dir)) {
- msglog(LOG_ERR, no such directory %s.\n, pw-pw_dir);
+ msglog(LOG_ERR, error changing to directory %s: %s\n, pw-pw_dir, strerror(errno));
exit(1);
}
@@ -505,8 +508,8 @@
void sendmessage(const char *myname, const char *msgfile)
{
FILE *mfp, *sfp;
- int i;
- int pvect[2];
+ pid_t pid, wpid;
+ int pvect[2], wstatus;
char buf[MAXLINE];
mfp = fopen(msgfile, r);
@@ -518,12 +521,12 @@
msglog(LOG_ERR, pipe: %m);
exit(1);
}
- i = fork();
- if (i 0) {
+ pid = fork();
+ if (pid 0) {
msglog(LOG_ERR, fork: %m);
exit(1);
}
- if (i == 0) {
+ if (pid == 0) {
dup2(pvect[0], 0);
close(pvect[0]);
close(pvect[1]);
@@ -534,6 +537,7 @@
exit(1);
}
close(pvect[0]);
+
sfp = fdopen(pvect[1], w);
fprintf(sfp, To: %s\n, from);
while (fgets(buf, sizeof buf, mfp)) {
@@ -547,8 +551,31 @@
fputs(buf, sfp);
}
}
+
+ if (ferror(mfp)) {
+ msglog(LOG_ERR, error reading file %s: %s\n, msgfile, strerror(errno));
+ } else if (ferror(sfp)) {
+ msglog(LOG_ERR, error piping message to %s[%d]: %s\n, _PATH_SENDMAIL, pid, strerror(errno));
+ } else {
+ msglog(LOG_INFO, response message passed to %s[%d].\n, _PATH_SENDMAIL, pid);
+ }
+
fclose(mfp);
fclose(sfp);
+
+ do {
+ wpid = waitpid(pid, wstatus, 0);
+ } while (wpid == -1 errno == EINTR);
+
+ if (wpid == -1) {
+ msglog(LOG_ERR, error waiting for death of child %s[%d]: %s\n, _PATH_SENDMAIL, pid, strerror(errno));
+ } else if (WIFEXITED(wstatus)) {
+ if (WEXITSTATUS(wstatus) != 0) {
+ msglog(LOG_ERR, process %s[%d] exited with return code %d\n, _PATH_SENDMAIL, pid, WEXITSTATUS(wstatus));
+ }
+ } else if (WIFSIGNALED(wstatus)) {
+ msglog(LOG_ERR, process %s[%d] died with signal %d\n, _PATH_SENDMAIL, pid, WTERMSIG(wstatus));
+ }
}
void usage(void)
Bug#321992: vsftpd: wrong process title written to log (+ solution)
Package: vsftpd Version: 2.0.3-1 Severity: normal If allowed, vsftpd changes its process name to refrect the current state. It is then correctly displayed by the `ps' command, but the syslog messages get crippled in Linux, like this: Jul 23 08:13:01 hostname .177.102.164: connected: (pam_unix) session opened for user FTPUSER by (uid=0). Whereas it should be: Jul 23 08:13:01 hostname vsftpd: 80.177.102.164: connected: (pam_unix) session opened for user FTPUSER by (uid=0). The cut off part --vsftpd: 80-- is 10 characters in length, as is /usr/sbin/. The original argv[0] was certainly /usr/sbin/vsftpd and GLIBC's variable __progname was set one char after the last slash in argv[0] by the initializing function __init_misc() in GLIBC. First call of syslog() fixes the current pointer __progname into the private pointer LogTag -- in case LogTag is not previously set by syslog() indirectly or openlog() directly (using its first argument). At any time, you could set what you want to be logged using the ident argument. In vsftpd, pam_open_session() calls syslog() to create the message above. I do not know, whether it would react in the good way for previous openlog(argv[0], ...) too... Therefore, in my opinion the safest way of the processtitle-changing program under Linux is to: 1) Set __progname = argv[0]; as soon as possible in main() or set_proc_title_init() at the latest, 2) Now it's up to whether we want to process name to be changed not only in `ps', but also in the syslog: - If so, then at the place up to (or inside) init_set_proc_title() call openlog(__progname_full, ...), - Otherwise, a fixing call openlog(myprog, ) should be made as soon as possible in main(). There should be chosen between these two variants for vsftpd. I'd prefer not to change the process title in syslog, since, by the current source, the process title would be also affected by the (tunable_syslog_enable || tunable_tcp_wrappers) expression in vsf_log_init(). That's because this expression calls/not calls log-title-fixing openlog(vsftpd, ...). (I sent this e-mail upstream to [EMAIL PROTECTED], but I got error response (for another address), so I do not know whether the bugreport reached him.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages vsftpd depends on: ii adduser 3.63 Add and remove users and groups ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcap1 1:1.10-14support for getting/setting POSIX. ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321778: star is fast-forwarding the system time via the -ctime option
Subject: star is fast-forwarding the system time via the -ctime option
Package: star
Version: 1.5a57-1
Severity: important
When using -atime -ctime (to let star restore all inode times after the
dump), star with root privs undeterminably fast-forwards the system time.
This is really SERIOUS bug, which should not occur in such software.
This is probably caused by the method of restoring i-node ctime, see
star/star_unix.c:654:
#ifdef SET_CTIME
if (Ctime) {
gettimeofday(curtime, 0);
settimeofday(tp[2], 0);
}
#endif
ret = utimes(name, tp);
errsav = geterrno();
#ifdef SET_CTIME
if (Ctime) {
gettimeofday(pasttime, 0);
/* XXX Hack: f_ctime.tv_usec ist immer 0! */
curtime.tv_usec += pasttime.tv_usec;
if (curtime.tv_usec 100) {
curtime.tv_sec += 1;
curtime.tv_usec -= 100;
}
settimeofday(curtime, 0);
/* error(pasttime.usec: %d\n, pasttime.tv_usec);*/
}
#endif
Possibly (another) bug: Doesn't sole curtime.tv_usec += pasttime.tv_usec;
statement ignore possible pasttime.tv_sec change for cases, when the
intermediate part lasted unexpectedly long?
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Versions of packages star depends on:
ii libacl1 2.2.23-1 Access control list shared
library
ii libattr12.4.16-1 Extended attribute shared
library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared
libraries an
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307655: gtodo SIGSEGV
Hi, I've also experienced the segfault problem (same backtrace also). It is easily reproducible by me like this: 1) delete the gtodo configuration (rm -rf ~/.gtodo) 2) run gtodo and press Ctrl-E 3) in the Edit Categories dialog delete ALL items 4) press Close, SIGSEGV will immediatelly occur Hope that is just a minor glitch in the code... -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96882: UserDB for Maildrop
Package: maildrop Version: 1.5.3-1.1 Followup-For: Bug #96882 May I also ask the maintainer to compile packaged maildrop with userdb feature? As I see it now, the lack of the feature effectively blocks to use the distro maildrop to deliver to virtual mail accounts (users without record in /etc/passwd) from the MTA. Thanks very much for re-consideration! It would be great if I still could stay with no 3rd party package source or my own compilation... -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
