Bug#719890: login should fallback to /bin/sh if shell in /etc/passwd fails
severity 719890 wishlist thanks That's probably a bad idea, since admins may specify nonextant *or restricted* shells in order to disable a user. Specifying a nonextant shell may not be effective on its own (ssh can still forward ports, etc); however, if a restricted shell is accidentally removed, or loses its exec bit, or the partition has an error, or isn't mounted, a user shouldn't be given additional privileges. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#155109: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
You want cron to allow a job to fail silently? Although avoiding noise from some existing package cron.d jobs is additional work, having an assertive cron helps people to catch otherwise-invisible problems (Andrew Pimlott in #443615). Andrew? Perhaps you have a specific, convincing scenario handy. Justin On Wed, May 19, 2010 at 09:58:06AM +0200, Christian Kastner wrote: I think our mails triggered a race condition ;-) I have to admit the change was unintended, which is why I reverted it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484743: run-parts behavior and cron
Tom Metro wrote: run-parts probably doesn't involve itself in managing the output of the jobs it runs, and therefore it doesn't know if a job has produced any output. Without checking source code, that seems to be incorrect: quoting run-parts(8): --report similar to --verbose, but only prints the name of scripts which produce output. The script’s name is printed to whichever of stdout or stderr the script first produces output on. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580887: marked as done (notify user if his crontab is no longer valid upon upgrade)
That argument assumes that cron's parser hasn't been improved or fixed, which is inconsistent with this changelog entry: * entry.c - Explicitly check for valid ranges in range values instead of upstream's broken approach which misses certain combinations of ranges and steps. Closes: #533726 Apparently, this upgrading cron across that version may cause some crontabs that used to run (with unknown behavior) to no longer be run, and (if my recollection of someone else's description of Debian's cron behavior are both accurate) later crontabs from the same file ignored, even though they would've been run before the upgrade. Justin On Sun, May 09, 2010 at 09:33:10PM +, Debian Bug Tracking System wrote: Your message dated Sun, 09 May 2010 23:32:00 +0200 with message-id 4be729d0.60...@kvr.at and subject line Re: Bug#580887: notify user if his crontab is no longer valid upon upgrade has caused the Debian Bug report #580887, regarding notify user if his crontab is no longer valid upon upgrade to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 580887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580887 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems From: jida...@jidanni.org To: sub...@bugs.debian.org Subject: notify user if his crontab is no longer valid upon upgrade Date: Sun, 09 May 2010 23:09:51 +0800 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on busoni.debian.org X-Spam-Level: X-Spam-Bayes: score:0. Tokens: new, 9; hammy, 94; neutral, 59; spammy, 2. spammytokens:1.000-1--aok, 0.999-1--AOK hammytokens:0.000-+--Severity, 0.000-+--H*F:U*jidanni, 0.000-+--H*F:D*jidanni.org, 0.000-+--HX-Spam-Relays-External:sk:jidanni, 0.000-+--H*RU:sk:jidanni X-Spam-Status: No, score=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,PUSSY autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Package: cron Version: 3.0pl1-110 Severity: wishlist Let's say the user has a working crontab for years. Well, upon upgrading cron one day it stops working. He doesn't notice it at first, but after a few days he thinks, 'why is my coffee not ready on time? etc. Well, $ crontab -l|diff file - shows his crontab is A-OK. Even though there should be no need, he does $ crontab file whereupon an *ERROR* is reported. Well, it would be nice if upon upgrade, every user's crontab is checked to see if it is still considered error free with the new version of cron, and if not, then at least mail the user to tell him. It doesn't matter if it is the users fault, or a bug in cron, that caused the user's formerly OK crontab to now become not OK. Just please notify the user, and perhaps now make $ crontab -l #Your crontab has errors with version xxx of cron. Here it is commented #out below. From: Christian Kastner deb...@kvr.at To: jida...@jidanni.org, 580887-d...@bugs.debian.org Subject: Re: Bug#580887: notify user if his crontab is no longer valid upon upgrade Date: Sun, 09 May 2010 23:32:00 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on busoni.debian.org X-Spam-Level: X-Spam-Bayes: score:0. Tokens: new, 18; hammy, 150; neutral, 75; spammy, 1. spammytokens:0.993-1--H*M:60500 hammytokens:0.000-+--H*c:pgp-sha256, 0.000-+--H*c:sk:HnigHHH, 0.000-+--HX-Enigmail-Version:0.95.0, 0.000-+--H*c:protocol, 0.000-+--H*c:micalg X-Spam-Status: No, score=-10.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, PGPSIGNATURE,PUSSY autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 X-Enigmail-Version: 0.95.0 On 05/09/2010 05:09 PM, jida...@jidanni.org wrote: Let's say the user has a working crontab for years. Well, upon upgrading cron one day it stops working. He doesn't notice it at first, but after a few days he thinks, 'why is my coffee not ready on time? etc. Well, $ crontab -l|diff file - shows his crontab is A-OK. Even though there should be no need, he does $ crontab file whereupon an *ERROR* is reported. Well, it would be nice if upon upgrade, every user's crontab is checked to see if it is still considered error free with the new version of cron, and if not, then at least mail the user to tell him. This doesn't have to be even a wishlist bug, because 1) it will never happen and 2) even if it would, a sane upgrade path would be a given. Ad 1: The structure is standardized by POSIX[1]. In fact, it's been this way for 30+ years. All attempts to
Bug#435271: only root crontabs are executed
What is it that cron is writing to syslog? Something about permission denied -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559490: xfsdump: fsr creates files mode 666
On Mon, Dec 07, 2009 at 08:53:22AM +1100, Nathan Scott wrote:
- Justin T Pryzby justinpry...@users.sourceforge.net wrote:
Package: xfsdump
Version: 2.2.48-1
Tags: security
Looks like this:
127176340 drwxrwxrwx 2 root root6 Sep 21 09:40
/var/.fsr/ag0
Thanks, have begun discussions with upstream as to effects of this.
Did you run that ls as root? What permissions do you see on the
/var/.fsr (parent) directory?
That was the output of find -ls, as run by a daily root cronjob [0].
The parent is mode 700, so this is mostly a cosmetic/style issue.
just...@loki:~$ ls -ld /var/.fsr
drwx-- 82 root root 4K 2009-12-06 15:39 /var/.fsr
mask = umask(0);
if (mkdir(buf, 0700) 0) {
If mkdir fails with errno==EEXIST, then fsr warns then continues.
Conceivably someone with pre-existing access to /var could create
/var/.fsr and gain access to something else they didn't have access
to, or cause data corruption while fsr is running. Normally access to
/var already implies existing root access though.
Ideally umask would either be left alone or set to 7, 00077 or ..
and the files would be created with mode 00700 or 00750.
Thanks,
Justin
[0] find / -ignore_readdir_race \( \( -fstype nfs -o -path /proc -o -path /mnt
\) -prune \) -o ! -type s ! -type c ! -type b ! -type l ! -perm -01777 -perm
-2 -ls
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550641: postinst requires usr/share/doc
On Sun, Oct 11, 2009 at 08:10:02PM +0100, Stephen Gran wrote: This one time, at band camp, Debian Bug Tracking System said: Bug #550641 [lintian] postinst depends on usr/share/doc Bug reassigned from package 'lintian' to 'clamav-base'. Bug No longer marked as found in versions lintian/1.23.8. First, I'd like to thank you for the heads up about the bug. Second, I'd like to ask why you're filing bugs based on a naive sed. If you mean the perl script, the clamav bug wasn't even detected by that. I cloned the bug when I noticed the clamav bug (and friends) having remembered reporting it earlier. Sorry for the confusion. Third, I'd like to ask why you think optionally installing a default config file (or db file) from the example shipped in, uh, the examples/ directory is a bug. Optionally? It seems to me that this will fail in postinst configure if u/s/d and $db.cvd, $db.cld, $db.inc all don't exist. install -m 0644 -o $user -g $user /usr/share/doc/clamav-base/examples/$db.cvd $DATABASEDIR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550641: postinst requires usr/share/doc
close 550642 thanks Oops, sorry. I looked at the spamassassin postinst again and it's fine (clamav is broken, though). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542453: logwatch: support cron-L2 END messages
On Sat, Aug 29, 2009 at 11:03:42AM +0200, Willi Mann wrote: Justin T Pryzby schrieb: Package: logwatch Version: 7.3.6.cvs20080702-2 Tags: patch File: /usr/share/logwatch/scripts/services/cron Hi! When do these lines occur on Debian systems? With cron/unstable when /etc/default/cron =~ /-L2/. Justin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541148: [Pkg-nagios-devel] Bug#541148: nagios-plugins: check_http: detect invalid argument to -f
Hi Jan, On Wed, Aug 12, 2009 at 09:51:52AM +0200, Jan Wagner wrote: Hi Justin, On Wednesday 12 August 2009 01:15:11 Justin Pryzby wrote: Package: nagios-plugins Version: 1.4.12-4ubuntu2 maybe you did send your report to the wrong destination? sub...@bugs.debian.org is not ubuntu related. In case this was your intention, please be so kind and write what your patch solves and what is the problem related with it. We use ubuntu at my workplace, but I'm only familiar with bug submission for Debian. So I checked that this applies to the package in debian's unstable, but forgot to change the version header. check_http current allows --follow=foo or -f foo, but not -f=foo. Also the implementation doesn't error when foo is an invalid string. This patch allows -f=foo and errors if foo isn't a recognized follow parameter. Justin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541148: nagios-plugins: check_http: detect invalid argument to -f
Package: nagios-plugins
Version: 1.4.12-4ubuntu2
Tags: patch
--- nagios-plugins-1.4.12/debian/changelog
+++ nagios-plugins-1.4.12/debian/changelog
@@ -1,3 +1,11 @@
+nagios-plugins (1.4.12-4ubuntu2.1) jaunty; urgency=low
+
+ * Non-maintainer upload.
+ * Detect check_http -f=unknown-string, and support -f=valid-string (with
+equal sign).
+
+ -- Justin Pryzby justinpry...@users.sourceforge.net Tue, 11 Aug 2009
16:09:45 -0700
+
nagios-plugins (1.4.12-4ubuntu2) jaunty; urgency=low
* Added 99_check_ntp_segfaults.dpatch: Fix for check_ntp and check_ntp_peer
--- nagios-plugins-1.4.12.orig/plugins/check_http.c
+++ nagios-plugins-1.4.12/plugins/check_http.c
@@ -302,16 +302,21 @@
server_port = HTTPS_PORT;
break;
case 'f': /* onredirect */
+ if (*optarg=='=') ++optarg;
if (!strcmp (optarg, follow))
onredirect = STATE_DEPENDENT;
- if (!strcmp (optarg, unknown))
+ else if (!strcmp (optarg, unknown))
onredirect = STATE_UNKNOWN;
- if (!strcmp (optarg, ok))
+ else if (!strcmp (optarg, ok))
onredirect = STATE_OK;
- if (!strcmp (optarg, warning))
+ else if (!strcmp (optarg, warning))
onredirect = STATE_WARNING;
- if (!strcmp (optarg, critical))
+ else if (!strcmp (optarg, critical))
onredirect = STATE_CRITICAL;
+ else {
+usage2 (_(Invalid option argument: --follow), optarg);
+ }
+
if (verbose)
printf(_(option f:%d \n), onredirect);
break;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521300: squid3: use s-s-d --retry functionality rather than shell reimplementttion
Package: squid3
Version: 3.0.STABLE13-1
Severity: wishlist
Tags: patch
File: /etc/init.d/squid3
See comments in the dpkg source, it does the same thing internally
with greater efficiency. On our proxy squid restarts in 5 seconds now
instead of 25.
--- /etc/init.d/squid3
+++ /tmp/tmp.U14159/squid3 2009-03-26 08:01:43.0 -0700
@@ -77,32 +77,8 @@
}
stop () {
- PID=`cat $PIDFILE 2/dev/null`
- start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON
- #
- # Now we have to wait until squid has _really_ stopped.
- #
- sleep 2
- if test -n $PID kill -0 $PID 2/dev/null
- then
- log_action_begin_msg Waiting
- cnt=0
- while kill -0 $PID 2/dev/null
- do
- cnt=`expr $cnt + 1`
- if [ $cnt -gt 24 ]
- then
- log_action_end_msg 1
- return 1
- fi
- sleep 5
- log_action_cont_msg
- done
- log_action_end_msg 0
- return 0
- else
- return 0
- fi
+ start-stop-daemon --stop --quiet --retry 5 --pidfile $PIDFILE --exec
$DAEMON
+ return 0
}
case $1 in
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521097: n-p-b: check_nt crashes
Package: nagios-plugins-basic Version: 1.4.11-2ubuntu2.1 Severity: normal Can crash in 2 ways: - if -H $host is not specified; - if -l $drive is given for a drive which doesn't exist -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517022: openssl: /it's unique/s/'//
Package: openssl Version: 0.9.8g-4ubuntu3.4 Severity: minor File: /usr/share/man/man1/speed.1ssl.gz --- /usr/share/man/man1/speed.1ssl.gz +++ - 2009-02-24 22:49:58.571289761 -0700 @@ -168,7 +168,7 @@ .IX Header OPTIONS .IP \fB\-engine id\fR 4 .IX Item -engine id -specifying an engine (by it's unique \fBid\fR string) will cause \fBspeed\fR +specifying an engine (by its unique \fBid\fR string) will cause \fBspeed\fR to attempt to obtain a functional reference to the specified engine, thus initialising it if needed. The engine will then be set as the default for all available algorithms. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511425: acct: add [P]PID fields
Package: acct Version: 6.4~pre1-4ubuntu1 Tags: patch File: /usr/share/man/man8/dump-acct.8.gz --- /usr/share/man/man8/dump-acct.8.gz +++ - 2009-01-10 12:35:42.062226575 -0700 @@ -1,4 +1,4 @@ -.TH DUMP-ACCT 8 2006-04-22 6.4pre1 GNU Accounting Utilities +.TH DUMP-ACCT 8 2009-01-10 6.4pre1 GNU Accounting Utilities .SH NAME dump-acct \- print an acct file in human-readable format. @@ -33,6 +33,8 @@ .IR gid , .IR memory , .IR io , +.IR pid , +.IR ppid , .IR time . User, system and effective times are ticks per second. One tick is usually 1/50 of a second. The -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502878: john: allow for non-persistent /var/run
Package: john Version: 1.7.2-3 Severity: normal Tags: patch File: /usr/share/john/cronjob --- /usr/share/john/cronjob +++ tmp.ki8907/cronjob 2008-10-20 08:26:35.0 -0700 @@ -22,6 +22,7 @@ RESTORE=$RUNDIR/restore PASSFILE=`grep -v ^# /etc/john/john-mail.conf | grep -e [ ]*passfile[ ]*=[ ]* | sed -e s/#.*// -e s/.*=[ ]*// |head -1` +[ -d $PIDDIR ] || mkdir $PIDDIR cd $RUNDIR # Gets the PID of the process that should be running john, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495110: apache2.2-common: /DocumentRoot/ s,/* *$,,
Package: apache2.2-common Version: 2.2.3-4+etch4 Tags: patch File: /etc/apache2/sites-available/default http://httpd.apache.org/docs/2.0/mod/core.html#documentroot --- /etc/apache2/sites-available/default +++ /tmp/tmp.RpZWdl7240/default 2008-08-14 09:08:15.0 -0700 @@ -1,8 +1,8 @@ NameVirtualHost * VirtualHost * ServerAdmin [EMAIL PROTECTED] - - DocumentRoot /var/www/ + + DocumentRoot /var/www Directory / Options FollowSymLinks AllowOverride None -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491127: logcheck: please consider an option which will always check the entire log file
On Wed, Jul 16, 2008 at 11:15:51PM +0200, Marc Haber wrote:
Package: logcheck
Version: 1.2.67
Severity: wishlist
It would help with debugging to have an option that causes logcheck to
always look through the entire log file, ie not using logtail.
A couple related things occurred to me, perhaps these can just be
described in README{,.Debian}.
1. How to filter an already-filtered email with a new rule, to see if
it matches (to first order that just does |grep -xEvf
/etc/logcheck/..., but that should also take into account the
violations and their exceptions). logcheck --stdin or something.
2. How to filter many emails (1 per hour * 16 hours) through a given
filter, perhaps as a test or a temporary measure (if something is
known, understood and perhaps fixed, and additional log lines
don't add any useful information and just act as clutter).
|formail -ds grep -xEvf /tmp/filter |formail -ds procmail
3. How to filter the logfiles themselves again, starting at a given
point. Probably best if logcheck supports this itself, to handle
rotation, but can probably be mediated with something like: sed
-sn '/^Xyz 12 34:56:78/,$p' /var/log/{sys,auth.} | logcheck
--stdin, as soon as 1. is implemented.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490969: mysql-server-5.0: initscript should unset BLOCK_SIZE, too
Package: mysql-server-5.0
Version: 5.0.45-1ubuntu3.3
Tags: patch
File: /etc/init.d/mysql
--- /etc/init.d/mysql
+++ tmp.A13560/mysql2008-07-15 09:05:38.668916514 -0700
@@ -65,7 +65,7 @@
# check for diskspace shortage
datadir=`mysqld_get_param datadir`
- if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit
($44096) }'; then
+ if LC_ALL=C BLOCKSIZE= BLOCK_SIZE= df --portability $datadir/. | tail -n 1 |
awk '{ exit ($44096) }'; then
log_failure_msg $0: ERROR: The partition with $datadir is too full!
echoERROR: The partition with $datadir is too full! |
$ERR_LOGGER
exit 1
See /usr/share/info/coreutils.info.gz.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489528: motion: initscript errors
Package: motion Version: 3.2.9-1ubuntu1 Two problems: s-s-d is not writing the pidfile, rather motion is. However new motion packages run as user motion, so can't write to /v/run as specified by process_id_file /var/run/motion.pid. /v/r/motion is already created and set to motion:motion, however the pid location needs to be updated for consistency. == is a bash regex operator, = should be used for string comparison, or -eq for numeric. The script could also be made to use #! /bin/sh. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488737: logwatch: s/=/=~/ services/cron
Package: logwatch
Version: 7.3.6-1ubuntu1
Tags: patch, upstream
File: /usr/share/logwatch/scripts/services/cron
--- /usr/share/logwatch/scripts/services/cron
+++ tmp.L16063/cron 2008-06-30 15:21:34.0 -0700
@@ -142,7 +142,7 @@
$Errors{$Reason}++;
} elsif ( ($FileName) = ($ThisLine =~ /BAD FILE MODE \((.+)\)/) ) {
$BFMFile{$FileName}++;
- } elsif ( ($FileName) = ($ThisLine = /WRONG FILE OWNER \((.+)\)/) ) {
+ } elsif ( ($FileName) = ($ThisLine =~ /WRONG FILE OWNER \((.+)\)/) ) {
$WFO{$FileName}++;
} else {
# Report any unmatched entries...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484122: cron: segmentation fault while executing the jobs
On Mon, Jun 02, 2008 at 05:45:56PM +0200, Michael Domann wrote: Package: cron Version: 3.0pl1-104 Severity: important Hi, i have trouble with the cron. for some weeks. When did it start? Did you upgrade cron or change hardware or ?? the error is evertime the same, i have tested my own build kernel and the debian kernel 2.6.25-2-686. i have set the loglevel to 10 in /etc/default/cron but no more informations happen. I think this requires a -d or -x debug flag but I'm not sure without reading the source (it may also require rebuilding). Can you kill your current crond parent process and start another one under strace, and mail output preceding the segfault? A debug build would also be handy: apt-get build-dep cron apt-get source cron DEB_BUILD_OPTIONS=debug,nostrip dpkg-buildpackage debi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487099: mutt: typo; /implicitely/ s/e// muttrc.5
Package: mutt Version: 1.5.17+20080114-1ubuntu1 Severity: minor Tags: patch File: /usr/share/man/man5/muttrc.5.gz --- /usr/share/man/man5/muttrc.5.gz +++ - 2008-06-19 08:11:17.081474491 -0700 @@ -95,7 +95,7 @@ however the special character \fB*\fP can be used to empty a group of all of its contents. .IP -These address groups can also be created implicitely by the \fBalias\fP, \fBlists\fP, +These address groups can also be created implicitly by the \fBalias\fP, \fBlists\fP, \fBsubscribe\fP and \fBalternates\fP commands by specifying the optional \fI-group\fP option. .IP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482282: more on dbmail
severity 482282 important thanks Also, while removing: |Purging configuration files for dbmail ... |dpkg - warning: while removing dbmail, directory `/usr/share/doc/dbmail/examples' not empty so not removed. |dpkg - warning: while removing dbmail, directory `/usr/share/doc/dbmail' not empty so not removed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482282: dbmail: suggestions for debian/
Package: dbmail Version: 2.2.10-1 Initially I noticed that when dbmail is in state config-files (not installed), cron sends a daily warning from logrotate due to missing logfiles/directories. The postinstall script does: create_user doesn't apparently exist (as a shell function or external program). unconditional chown rather than dpkg-statoverride. gunzip -c /usr/share/doc/dbmail/examples/dbmail.conf.gz, but that fails when the admin removes /u/s/d (which is intended to be allowed). dbmail.prerm is empty, so it's preferable for debhelper to create this file from scratch (or, alternately, it should contain the rollback actions for postinst. dbmail.preinst doesn't need to do getent calls, as adduser --system succeeds gracefully when the user already exists (but perhaps that requires a versioned dependency?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478966: cron.daily/standard not silent
close 478966 3.0pl1-104 forcemerge 462472 478966 thanks On Fri, May 02, 2008 at 01:17:07AM +0200, Andras Korn wrote: Package: cron Version: 3.0pl1-100 Severity: normal Already fixed in sid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476541: exim4-base: please handle nearly-empty logfile in daily cronjob stats
On Mon, Apr 21, 2008 at 08:43:22AM +0200, Marc Haber wrote:
On Sun, Apr 20, 2008 at 09:30:33PM -0400, Justin Pryzby wrote:
I rewrote your patch to use a tempfile instead to reduce code
duplication.
I'd rather have a few megs of code grepped twice than using a tempfile.
I don't know if I understand exactly what you mean (the code is not
grepped but rather the logfile data), but that's otherwise fair. I
tested the attached patch just now, with the following changes from
your initial copy:
. redirect stderr (twice);
. write non-statistic output to stdout (the cronjob pipe), rather
than sending a separate mail.
. Fix regex: don't escape . within a bracket expression (it's
literal without escaping)
Justin
--- exim4-base 2008-04-21 09:21:40.0 -0400
+++ /etc/cron.daily/exim4-base 2008-04-21 09:35:53.0 -0400
@@ -11,6 +11,7 @@
# checking mechanisms or don't care.
E4BCD_DAILY_REPORT_TO=
+E4BCD_DAILY_REPORT_OPTIONS=
E4BCD_WATCH_PANICLOG=yes
E4BCD_PANICLOG_NOISE=
E4BCD_GNUTLS_PARAMS_MAXAGE=14
@@ -34,10 +35,21 @@
# Patches for more sophisticated processing are appreciated via the
# Debian BTS.
+E4BCD_MAINLOG_NOISE=^[[:digit:][:space:]:-]\{20\}\(\(Start\|End\) queue run:
pid=[[:digit:]]\+\|exim [[:digit:].]\+ daemon started: pid=[[:digit:]]\+,
\+.*\)$
+
if [ -n $E4BCD_DAILY_REPORT_TO ]; then
- if [ -x $(command -v eximstats) ]; then
-eximstats /var/log/exim4/mainlog \
-| mail $E4BCD_DAILY_REPORT_TO -s$(hostname --fqdn) Daily
email activity report
+ if [ -x $(command -v eximstats) ] [ -x $(command -v mail) ]; then
+if [ $( /var/log/exim4/mainlog grep -v $E4BCD_MAINLOG_NOISE
2/dev/null | wc -l) -gt 0 ]; then
+ /var/log/exim4/mainlog grep -v $E4BCD_MAINLOG_NOISE 2/dev/null |
+ eximstats $E4BCD_DAILY_REPORT_OPTIONS |
+ mail $E4BCD_DAILY_REPORT_TO -s$(hostname --fqdn) Daily e-mail activity
report
+else
+ echo no mail activity in this interval
+fi
+ else
+echo The exim4 cron job is configured to send a daily report, but
eximstats
+echo and/or mail cannot be found. Please check and make sure that these
two
+echo binaries are available
fi
fi
Bug#374452: closed by Matthias Klose [EMAIL PROTECTED] (Bug#374452: fixed in bash 3.2-2)
reopen 374452 thanks On Sun, Apr 20, 2008 at 10:36:12AM +, Debian Bug Tracking System wrote: #374452: bash: postrm maintscripts should check arguments I think the wrong bug got closed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474933: [Pkg-shadow-devel] Bug#474933: man page off target
On Sat, Apr 19, 2008 at 03:51:38PM +0200, Nicolas François wrote: + to exit from the current shell (and thus will avoid the new logged + in user to return to the session of the caller). Attempting to Instead of: avoid .. to, I would write prevent. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374452: closed by Matthias Klose [EMAIL PROTECTED] (Bug#374452: fixed in bash 3.2-2)
On Sun, Apr 20, 2008 at 04:19:47PM +0200, Matthias Klose wrote: I know it's the correct one. OK, I think I was confused. What about not calling remove-shell on upgrade? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476541: exim4-base: please handle nearly-empty logfile in daily cronjob stats
On Sun, Apr 20, 2008 at 09:34:04PM +0200, Marc Haber wrote:
On Thu, Apr 17, 2008 at 08:41:52AM -0400, Justin Pryzby wrote:
That's probably due to very low mail volume on this laptop machine, in
combination with an earlier logfile rotation.
Please try the following patch against the daily cron job:
Hi Marc,
I don't think that helps or changes the situation at all.
. eximstats generates an empty email, rather than either no mail at
all, or an email that says just: no mail activity in this
interval.
. mail gets an empty pipe and sends a warning to stderr (in a cronjob
that'll end up going to the same place as before).
$ sudo /etc/cron.daily/exim4-base
No valid log lines read
Null message body; hope that's ok
Either eximstats needs to be patched to handle the case of no matching
input lines, or it running it needs to be avoided in that situation.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476541: exim4-base: please handle nearly-empty logfile in daily cronjob stats
On Sun, Apr 20, 2008 at 10:41:10PM +0200, Marc Haber wrote:
On Sun, Apr 20, 2008 at 04:21:38PM -0400, Justin Pryzby wrote:
On Sun, Apr 20, 2008 at 09:34:04PM +0200, Marc Haber wrote:
On Thu, Apr 17, 2008 at 08:41:52AM -0400, Justin Pryzby wrote:
That's probably due to very low mail volume on this laptop machine, in
combination with an earlier logfile rotation.
+if [ $( /var/log/exim4/mainlog grep -v $E4BCD_MAINLOG_NOISE | wc
-l) -gt 0 ]; then
(please apply manually, I had to zap a hunk of irrelevant changes from
the output of svn diff)
Hi Marc
I rewrote your patch to use a tempfile instead to reduce code
duplication. I used the [ -s $t ] || echo .. $t instead of an
if [ -s $t ]; then cat $t; else echo ..; fi |mail since the former
has better error handling than the pipe (f.e. if cat manages to have
an IO error).
I had to discard stderr, which I'm not entirely happy with, but it
seems unavoidable without changing eximstats since the message we're
trying to avoid goes to stderr and sets $? -ne 0. So the only
(poor) possibility is to test the file content against a known string.
Otherwise this is tested to work okay.
--- ./exim4-base2008-04-20 21:20:20.0 -0400
+++ /etc/cron.daily/exim4-base 2008-04-20 21:24:22.0 -0400
@@ -34,10 +34,17 @@
# Patches for more sophisticated processing are appreciated via the
# Debian BTS.
+E4BCD_MAINLOG_NOISE=^[[:digit:][:space:]:-]\{20\}\(\(Start\|End\) queue run:
pid=[[:digit:]]\+\|exim [[:digit:]\.]\+ daemon started: pid=[[:digit:]]\+,
.*\)$
if [ -n $E4BCD_DAILY_REPORT_TO ]; then
if [ -x $(command -v eximstats) ]; then
-eximstats /var/log/exim4/mainlog \
-| mail $E4BCD_DAILY_REPORT_TO -s$(hostname --fqdn) Daily
email activity report
+t=`tempfile`
+trap 'rm -fv -- $t' EXIT
+/var/log/exim4/mainlog grep -v $E4BCD_MAINLOG_NOISE |
+ eximstats $E4BCD_DAILY_REPORT_OPTIONS $t 2/dev/null
+[ -s $t ] || echo no mail activity in this interval $t
+$t mail $E4BCD_DAILY_REPORT_TO -s$(hostname --fqdn) Daily email
activity report
+rm -f $t
+trap - EXIT
fi
fi
Bug#473458: manpages-dev: dlopen man page contradicts ld.so(8)
user [EMAIL PROTECTED] usertag 473458 debian-specific thanks On Fri, Apr 18, 2008 at 06:52:12PM +0200, Michael Kerrisk wrote: Justin Pryzby wrote: reassign 473458 libc6 found 473458 2.7-9 thanks On Sun, Mar 30, 2008 at 09:48:46PM +0300, ygrek wrote: man dlopen says : Otherwise, the dynamic linker searches for the library as follows (see ld.so(8) for further details): [...] o The directories /lib and /usr/lib are searched (in that order). and man ld.so : The necessary shared libraries needed by the program are searched for in the following order [...] o In the default path /usr/lib, and then /lib. so what is searched first - /usr/lib or /lib? [...] But I think it's sufficiently accurate to say that the /lib heirarchy is searched before that of /usr/lib, so ld.so.8 is wrong, thus reassigning. This correct. NOTE: this bad text is in a Debian downstream patch. The usptream page is correct on this point (and has been forever, AFAICS) The ld.so manpage seems to be introduced (not patched) by Debian's diff. Where does the ld.so.8 page used by the rest of the world come from? Does redhat or someone else maintain another page (separate from both glibc upstream and Debian). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473458: manpages-dev: dlopen man page contradicts ld.so(8)
reassign 473458 libc6,manpages thanks On Fri, Apr 18, 2008 at 08:15:43PM +0200, Michael Kerrisk wrote: On Fri, Apr 18, 2008 at 6:35 PM, Justin Pryzby [EMAIL PROTECTED] wrote: user [EMAIL PROTECTED] usertag 473458 debian-specific thanks On Fri, Apr 18, 2008 at 06:52:12PM +0200, Michael Kerrisk wrote: Justin Pryzby wrote: reassign 473458 libc6 found 473458 2.7-9 thanks On Sun, Mar 30, 2008 at 09:48:46PM +0300, ygrek wrote: But I think it's sufficiently accurate to say that the /lib heirarchy is searched before that of /usr/lib, so ld.so.8 is wrong, thus reassigning. This correct. NOTE: this bad text is in a Debian downstream patch. The usptream page is correct on this point (and has been forever, AFAICS) The ld.so manpage seems to be introduced (not patched) by Debian's diff. Where does the ld.so.8 page used by the rest of the world come from? Does redhat or someone else maintain another page (separate from both glibc upstream and Debian). It's in my set; ld.so.8 is one of the few section 8 pages in upstream man-pages. Thanks for pointing that out. I don't know the history behind the libc6 package vs. manpages package inclusion of ld.so.8. It seems to me that manpages is the way to go. I note these differences: . /etc/ld.so.nohwcap; this might be debian-specific, eg. for multi-arch. . The entirely of sections BUGS, NOTES, AUTHORS, COLOPHON; . the libc6 page suffers from bug#365112, fixed in manpages; . man-pages has a more complete and correct description of the search order (This is the initial bug report); . man-pages has better hyphenation escaping; . man-pages fixes typo LD_(DEBUG|PROFILE)_OUTPUT . includes LD_*: SHOW_AUXV, HWCAP_MASK, ORIGIN_PATH, DYNAMIC_WEAK . includes libc5-specific LD_*: KEEPDIR, ARGV0 Suggested fixes to the man-pages content to make it better than the libc6 content in every way: s/indirectly through/indirectly by/ s/resolval/resolution/ s/linked with/ the/ s/set to non/set to a non/ (multiple times) s/Do not update ... and/Update neither .../ Instead of various places, say in the following order. Include content regarding: LD_ASSUME_KERNEL: (with fix: s/multiple version is/multiple versions are/) $PLATFORM: (or uncomment this) (with fix: s/specifcation/specification/) I think glibc should drop ld.so.8. The manpages copy seems to be more easily made to be the best of the two, and gets wider visibility so can be reasonably expected to remain so. Any debian-specific linker changes (perhaps including ld.so.conf.d?) can get included in the debian diff to man-pages. That seems a preferable situation to including an separately-maintained and undiffably-different manpage in libc6, which includes only very few manpages (and only for normal executables and the configuration file gai.conf). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473458: manpages-dev: dlopen man page contradicts ld.so(8)
On Fri, Apr 18, 2008 at 10:34:47PM +0200, Michael Kerrisk wrote: Can you send me the source of the Debian page? I just sent it in a separate message. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476519: [Pkg-shadow-devel] Bug#476519: su - nobody sometimes logged back out instantly
On Thu, Apr 17, 2008 at 07:58:19PM +0800, [EMAIL PROTECTED] wrote: Thanks, I tried your script with PS1=#\ ENV= HOME=/tmp ./test.exp but for 20 instead of 2000 passes, but didn't trigger the bug. Maybe there are some bugs expect(1) cannot trigger like real users. Yes it is a mystery to me. Do you have any signal handling customization in your shell rc files? What does stty -a say (I'm thinking of tostop)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476541: exim4-base: please handle nearly-empty logfile in daily cronjob stats
Package: exim4-base
Version: 4.69-2+b1
File: /etc/cron.daily/exim4-base
Sometimes, I get these messages rather than the expected report (The
first message is empty):
On Wed, Apr 16, 2008 at 07:35:09AM -0400, root wrote:
On Wed, Apr 16, 2008 at 07:41:44AM -0400, Anacron wrote:
/etc/cron.daily/exim4-base:
No valid log lines read
Null message body; hope that's ok
That's probably due to very low mail volume on this laptop machine, in
combination with an earlier logfile rotation.
/var/log/exim4/mainlog
2008-04-17 07:42:11 Start queue run: pid=12298
2008-04-17 07:42:11 End queue run: pid=12298
2008-04-17 08:12:10 Start queue run: pid=12583
2008-04-17 08:12:10 End queue run: pid=12583
2008-04-17 08:30:32 exim 4.69 daemon started: pid=13220, -q30m, listening for
SMTP on [127.0.0.1]:25
2008-04-17 08:30:33 Start queue run: pid=13225
2008-04-17 08:30:34 End queue run: pid=13225
$ /usr/sbin/eximstats /var/log/exim4/mainlog
No valid log lines read
Sending a message writes data to the logfile and eximstats once again
runs normally.
eximstats should be patched to handle nearly-empty logfiles, probably
by perhaps exitting silently, or perhaps by simply outputting
Nearly-empty logfile. Or perhaps the cron tab should avoid running
the stats script in that case, like:
sed -re 's/^[-0-9 :]{19} //' /var/log/exim4/mainlog |
grep -vwe '^Start' -e ^End -e ^exim /dev/null eximstats ... |
mail ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476541: exim4-base: please handle nearly-empty logfile in daily cronjob stats
On Fri, Apr 18, 2008 at 12:04:41AM +0200, Marc Haber wrote: And you have E4BCD_DAILY_REPORT set to non-empty? Yes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292453: tagging 292453, closing 292453
# Automatically generated email from bts, devscripts version 2.10.25 tags 292453 moreinfo # Reasonable explanation given, working as intended, provides given information when available, no other response from submitter close 292453 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475946: net-tools: fix numeric ports handling in netstat
merge 197282 475946 merge 222324 475948 # 475947 contains an updated version of this patch from the same guy. merge 294252 475947 tag 294252 patch found 09 1.60-19 tag 09 confirmed thanks Hi Mike, Thanks for forwarding these bugs. Could you comment on the first patch supplied to #222324? Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437405: this bug/#437405 - removed /etc/default/aumix by hand
It seems that /etc/default/aumix was included in very old (pre-oldstable) aumix packages, but not current ones. Ideally, the version of aumix that dropped the conffile would have removed it, conditionally on its checksum matching the unmodified value, or moved it out of the way, if its checksum didn't match. Nowadays, dpkg has built-in support for obsolete conffiles, so I think it's too late to add support anyway. Is there a .deb available somewhere that shows that it was an included conffile? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475278: mahara mysql howto instructions
Package: mahara Version: 0.9.2-2 Tags: patch File: /usr/share/doc/mahara/README.Debian Debbugs-Cc: [EMAIL PROTECTED] Forwarded: [EMAIL PROTECTED] --- /usr/share/doc/mahara/README.Debian +++ /tmp/tmp.NysWv17388/README.Debian 2008-04-09 16:36:53.0 -0400 @@ -19,8 +19,17 @@ $ sudo -u postgres createdb -O maharauser -E utf8 maharadb CREATE DATABASE -NOTE: If you know what the MySQL equivalents are, please send them to - [EMAIL PROTECTED] so that they will be included in the next release. +Here's how to create a 'maharauser' account on MySQL: + $ mysql -u root -p + Enter password: + CREATE DATABASE mahara; + Query OK, 1 row affected (0.00 sec) + GRANT ALL ON mahara.* to maharax IDENTIFIED BY 'password'; + Query OK, 0 rows affected (0.00 sec) + FLUSH PRIVILEGES; + Query OK, 0 rows affected (0.00 sec) + exit + Bye -- Francois Marier [EMAIL PROTECTED] Wed, 21 Nov 2007 14:44:33 +1300 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474995: procps: /etc/sysctl.d/*.conf files not read at startup
On Tue, Apr 08, 2008 at 11:41:37AM +0100, Goncalo Marrafa wrote: Version: 1:3.2.7-8 Files placed in /etc/sysctl.d/*.conf are not properly read and its values not set in /etc/init.d/procps. There was a bug with the initial implementation of sysctl.d, but I think you misunderstand how it's supposed to work. The existence of the '*.conf/' dir was a mistake. Please remove the *.conf/ directory (move any needed files to /etc/sysctl.d). See also bug#474710 and its siblings. Please close this report if you can then confirm that /etc/sysctl.d works as intended. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474710: A garbage directory mixes in /etc/sysctl.d
On Mon, Apr 07, 2008 at 08:00:02PM +0900, Jonny wrote: Since a directory called *.conf exists in /etc/sysctl.d, the error of unexpected operator occurs with an init script: Comedy of errors. The package includes /etc/sysctl.d/*.conf/ as a directory, I think this is unintentionally done in debian/procps.dirs in the source package. There's also insufficient quoting, although that masks the first problem rather than solves it (the -r/-e test prevents this from causing an error in this case). --- /etc/init.d/procps +++ /tmp/tmp.XfMpp20428/procps 2008-04-07 08:58:30.0 -0400 @@ -27,9 +27,9 @@ case $1 in start|restart|force-reload) for file in /etc/sysctl.d/*.conf /etc/sysctl.conf ; do -if [ -r $file ] ; then +if [ -e $file ] ; then log_action_begin_msg Setting kernel variables ($file) - sysctl -q -p $file + sysctl -q -p $file log_action_end_msg $? fi done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474725: procps: ships strange /etc/sysctl.d/*.conf directory
forcemerge 474725 474710 thanks On Mon, Apr 07, 2008 at 02:47:40PM +0200, Mario 'BitKoenig' Holbe wrote: the new procps starts shipping /etc/sysctl.d and within that directory See earlier bug. some bash-induced scripting issue in package build: while decent shells tend to generate no match errors on constructs like for i in *.nonexistent; do echo $i; done bash tends to use the un-expanded value instead: bash$ for i in *.nonexistent; do echo $i; done *.nonexistent That's the behavior required by published standards, but not actually the problem here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443615: this bug/#443615 - /usr/sbin/cron: sometimes, @reboot jobs are not run
On Fri, Mar 28, 2008 at 12:44:25PM -0400, Justin Pryzby wrote: On Thu, Mar 27, 2008 at 11:35:10AM +, River Tarnell wrote: JP a non-issue in cron, right? However it seems that cron perhaps should JP have sent some warning messages/logs if an error was encountered. Is JP this correct? sorry for taking so long to reply - yes, i think that's correct. it returns nonzero exit status, so I think it should log that, and also warn the user by mail (even if the command output nothing else). I sent patches to #155109 to implement that. [...] if the last time of the crontab lacks a newline, the line will be ignored (and jobs won't run). i haven't gotten around to filing a I think that bug was separately reported, and unfortunately was resolved simply by adding a note to crontab.[15]. It's reasonable IMO to consider it a bug. This is bug#76625, which now has 2 patches (one of them mine). The earlier patch allows a file to end without a newline. Although this is the comfortable behavior, I like the subtle assertiveness of the intent of the upstream crontab's requirement. A file not ending in a newline might have been truncated (eg. due to ENOSPC) and that may even constitute a vulnerability (fill up the /var partition with one's own crontab such that when some other user tries to write/update theirs, the partial crontab runs command foo /bar rather than foo /bar/baz or foo /home/john rather than foo /home/johnk or ...). The behavior of my own patch isn't ideal, in particular since the edit path doesn't benefit from this parsing check. If it's okay with you, I'll close this (#443615) bug rept, since the remaining (2ndary) issues are addressed in other bugs. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474813: lprng/dpkg: preinst called with [ -z $1 ]
Package: lprng,dpkg Versions: 3.8.28dfsg.1-1.1, 1.14.16.6 It seems unlikely, but this sure seems like a dpkg bug. Unpacking lprng (from .../lprng_3.8.28dfsg.1-1.1_amd64.deb) ... preinst called with unknown argument `' /var/lib/dpkg/info/lprng.preinst: |case $1 in |install|upgrade|abort-upgrade) | ;; |*) | echo preinst called with unknown argument \`$1' 2 2008-04-07 15:00:49 install lprng none 3.8.28dfsg.1-1.1 It should have had $1 = install -z $2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474926: lynx-cur: postinst depends on /usr/share/doc
Package: lynx-cur
Version: 2.8.7dev4-1
Severity: important
The package postinstall script script does:
|# First, setup local.cfg
|if [ ! -f ${cnfdir}/local.cfg ] ; then
|cp /usr/share/doc/${pack}/local.cfg.in ${cnfdir}/local.cfg
|fi
However policy allows a local admin to remove /u/s/d and requires
that this doesn't break functionality.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474928: lynx-cur: remove local.cfg in purge, only
Package: lynx-cur
Version: 2.8.7dev4-1
Tags: patch
File: /var/lib/dpkg/info/lynx-cur.postrm
The primary goal of this patch is to preserve the configuration file
local.cfg when the package is removed but not purged. As a 2ndary
effect, it drops old code, removes a needless conditional, and
introduces copies quoting and such.
--- /var/lib/dpkg/info/lynx-cur.postrm
+++ /tmp/tmp.RNXNb10148/lynx-cur.postrm 2008-04-07 19:03:13.0 -0400
@@ -5,21 +5,8 @@
set -e
-if [ $1 = remove ]; then
-rm -f ${cnfdir}/local.cfg
-# handle duplicated lynx.mo
-#for l in ca cs da de et fr hu it ja nl pt_BR ru sl sv tr uk zh_CN zh_TW
-#do
-# dpkg-divert --package lynx-cur --remove --rename --divert \
-# /usr/share/locale/${l}/LC_MESSAGES/lynx.mo.old \
-#/usr/share/locale/${l}/LC_MESSAGES/lynx.mo
-#done
-fi
-
if [ $1 = purge ]; then
-if [ -d ${cnfdir} ] ; then
- rm -r ${cnfdir}
-fi
+ rm -fr -- ${cnfdir}
fi
# dh_installdeb will replace this with shell code automatically
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472932: this bug/#472932 - bochs: manpage not gzipped (cron)
#472932 - bochs: manpage not gzipped (cron) http://bugs.debian.org./472932 Hmm, this is probably due to #470913, so will be get fixed at the next upload, I think. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437374: this bug/#437374 - liblockfile: not handling nostrip build option (policy 10.1)
tag 437374 patch thanks diff -u liblockfile-1.07/debian/changelog liblockfile-1.07/debian/changelog --- liblockfile-1.07/debian/changelog +++ liblockfile-1.07/debian/changelog @@ -1,3 +1,13 @@ +liblockfile (1.07-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Respect DEB_BUILD_OPTIONS=nostrip (Closes: #437374) + * Use finer-grained error handling in maintainer scripts. + * debian/rules: Don't ignore error status of rm -fr (which should not fail). + * debian/rules: Remove stampfiles first. + + -- Justin Pryzby [EMAIL PROTECTED] Sat, 05 Apr 2008 10:18:29 -0400 + liblockfile (1.07-1) unstable; urgency=low * New maintainer. Closes: #465090 diff -u liblockfile-1.07/debian/prerm.nfs liblockfile-1.07/debian/prerm.nfs --- liblockfile-1.07/debian/prerm.nfs +++ liblockfile-1.07/debian/prerm.nfs @@ -16,11 +16,7 @@ fi cp -a /etc/ld.so.preload /etc/ld.so.preload.new -( - set +e - grep -v ^/lib/nfslock\.so /etc/ld.so.preload - set -e -) /etc/ld.so.preload.new +grep -v ^/lib/nfslock\.so /etc/ld.so.preload /etc/ld.so.preload.new || [ $? -eq 1 ] mv /etc/ld.so.preload.new /etc/ld.so.preload diff -u liblockfile-1.07/debian/postinst.nfs liblockfile-1.07/debian/postinst.nfs --- liblockfile-1.07/debian/postinst.nfs +++ liblockfile-1.07/debian/postinst.nfs @@ -20,9 +20,7 @@ fi cd /etc -set +e grep -q '^/lib/nfslock\.so\.0$' ld.so.preload exit 0 -set -e if [ -f ld.so.preload ] then @@ -32,9 +30,7 @@ # Careful here - grep -v might exit with value 1 # which would cause the script to abort. # - set +e - grep -v '^/lib/nfslock\.so' ld.so.preload - set -e + grep -v '^/lib/nfslock\.so' ld.so.preload || [ $? -eq 1 ] ) ld.so.preload.new fi echo /lib/nfslock.so.0 ld.so.preload.new diff -u liblockfile-1.07/debian/rules liblockfile-1.07/debian/rules --- liblockfile-1.07/debian/rules +++ liblockfile-1.07/debian/rules @@ -11,6 +11,12 @@ tmp= debian/tmp +INSTALL=install +ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) + INSTALL+=-s +endif + + build: config.status $(checkdir) make @@ -21,8 +27,8 @@ --with-mailgroup --mandir=/usr/share/man clean: + rm -rf build $(tmp)* debian/files debian/substvars [ ! -f Makefile ] || make distclean - -rm -rf build $(tmp)* debian/files debian/substvars binary-indep: checkroot $(checkdir) @@ -32,7 +38,7 @@ # # First, liblockfile.so.1 # - -rm -rf $(tmp)* + rm -rf $(tmp)* install -d -o root -m 755 $(tmp) install -d -o root -m 755 $(tmp)/DEBIAN install -d -o root -m 755 $(tmp)/usr/lib @@ -43,11 +49,11 @@ install -o root -m 755 debian/postinst $(tmp)/DEBIAN install -o root -m 755 debian/postrm $(tmp)/DEBIAN install -o root -m 644 debian/shlibs $(tmp)/DEBIAN - install -o root -m 644 -s liblockfile.so \ + $(INSTALL) -o root -m 644 liblockfile.so \ $(tmp)/usr/lib/liblockfile.so.$(SOVER) install -o root -m 644 dotlockfile.1 $(tmp)/usr/share/man/man1 gzip -9f $(tmp)/usr/share/man/*/* - install -g mail -m 2755 -s dotlockfile $(tmp)/usr/bin/dotlockfile + $(INSTALL) -g mail -m 2755 dotlockfile $(tmp)/usr/bin/dotlockfile ln -s liblockfile.so.$(SOVER) $(tmp)/usr/lib/liblockfile.so.$(MVER) install -o root -m 644 debian/changelog \ $(tmp)/usr/share/doc/liblockfile1/changelog.Debian @@ -60,7 +66,7 @@ # # Now build liblockfile-dev # - -rm -rf $(tmp)* + rm -rf $(tmp)* install -d -o root -m 755 $(tmp) install -d -o root -m 755 $(tmp)/DEBIAN install -d -o root -m 755 $(tmp)/usr/lib @@ -92,7 +98,7 @@ # # build libnfslock (OBSOLETE) # - -rm -rf $(tmp)* + rm -rf $(tmp)* install -d -o root -m 755 $(tmp) install -d -o root -m 755 $(tmp)/DEBIAN install -d -o root -m 755 $(tmp)/lib -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470918: sudo-ldap: useswronghostname
On Sat, Apr 05, 2008 at 06:36:42PM +0200, Lluis wrote: El Thu, Apr 03, 2008 at 02:44:41PM -0600, Bdale Garbee ens deleit? amb les seg?ents paraules: On Thu, 2008-04-03 at 20:47 +0200, Lluis wrote: El Thu, Apr 03, 2008 at 12:11:17PM -0600, Bdale Garbee ens deleit amb les segents paraules: On Fri, 2008-03-14 at 20:38 +0100, Lluis wrote: 127.0.0.1 localhost 127.0.0.1 hostname.domain hostname I'm not accustomed to seeing two lines for the same IP address in /etc/hosts, I'm not sure that's a good idea... it's hard to decide what behavior should really rbe expected in this case. What happens if you combine the entries into one line like this? 127.0.0.1 hostname.domain hostname localhost I tried with 127.0.0.1 localhost hostname and it didn't work. That kind of makes sense, since the first entry on the first line with a given IP address is the canonical name for that address. Note that my example didn't have localhost at the start of the line. All right, I tried it with 127.0.0.1 hostname.domain hostname localhost and it did indeed work :) So it seems like a result ordering issue (maybe not all results from 'getaddrinfo' are checked?) IIRC debian's glibc's getaddrinfo doesn't actually return multiple hostname aliases for a given address (I researched this a bit WRT #456672). I think glibc borrows this resolv/ code from BIND, and BIND doesn't implement all the necessary things due to threading issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470918: sudo-ldap: useswronghostname
On Sat, Apr 05, 2008 at 05:52:31PM -0400, Justin Pryzby wrote: IIRC debian's glibc's getaddrinfo doesn't actually return multiple hostname aliases for a given address (I researched this a bit WRT #456672). I think glibc borrows this resolv/ code from BIND, and BIND doesn't implement all the necessary things due to threading issues. Oops, even more relevant: is #460910: libc6: consider defining dns-host.c:MULTI_PTRS_ARE_ALIASES -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474157: cron: fails to run jobs during DST time changes
On Fri, Apr 04, 2008 at 12:02:46PM +0400, Petr Kohts wrote: Thanks for reporting. It seems to be the same as bug#217836. Can you describe the derivation of your patch? It seems to be applied to upstream cron code in version 4.1 from ISC. I'm a bit confused about the state of DST handling; there was a patch applied in Debian revision -53, but the patch is large (and combined with other changes) so the (intended) effect of the changes aren't entirely clear to me. As I recall, that patch also seemed to have been applied in the ISC release. As I can see here's the openbsd patch included into debian version -53: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/cron/cron.c.diff?r1=1.3r2=1.4f=h Thanks; my current understanding is that the original patch worked when the time was manually changed by 1-3 hours, but didn't work for real DST changes (the details aren't clear to me). BTW, I think there's a new bug here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/cron/misc.c.diff?r1=1.8r2=1.11f=h --- misc.c.orig 2008-04-06 00:13:14.0 -0400 +++ misc.c 2008-04-06 00:13:10.0 -0400 @@ -723,17 +723,17 @@ long get_gmtoff(time_t *clock, struct tm offset = (local-tm_sec - gmt.tm_sec) + ((local-tm_min - gmt.tm_min) * 60) + ((local-tm_hour - gmt.tm_hour) * 3600); /* Timezone may cause year rollover to happen on a different day. */ if (local-tm_year gmt.tm_year) offset -= 24 * 3600; else if (local-tm_year gmt.tm_year) - offset -= 24 * 3600; + offset += 24 * 3600; else if (local-tm_yday gmt.tm_yday) offset -= 24 * 3600; else if (local-tm_yday gmt.tm_yday) offset += 24 * 3600; return (offset); } #endif /* HAVE_TM_GMTOFF */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327271: Processed: reassign 327271 to iceweasel, found 327271 in 2.0.0.13-1, submitter 327271
On Sat, Apr 05, 2008 at 12:39:03AM +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: #Taking ownership from an unresponsive submitter submitter 327271 ! Bug#327271: mozilla-firefox: fails to err when opening a local file without read access Changed Bug submitter from Justin Pryzby [EMAIL PROTECTED] to Lior Kaplan [EMAIL PROTECTED]. I have to voice some objection, did you ever try to reproduce these, or did you just mass change the submitter? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474008: mongrel: update manpage
On Thu, Apr 03, 2008 at 11:02:05AM -0300, Filipe wrote: On Wed, 2 Apr 2008, Justin Pryzby wrote: You might also mention that modular commands (as I understand) like cluster::configure are supported by installing (in this case) mongrel-cluster. thanks for the idea. Where do you suggest I can put it? I'm not sure, I thought from reading the manpage that this wasn't a supported command (working off someone's wiki howto), and that was the reason it didn't work. I spent quite some time trying other things (like changing -N 3 to -n 3) before realizing (I think) that it just needed a package to be installed. Is this a new feature? Or just an undocumented one? Lacking better ideas, you might add a NOTES section: .SH NOTES .\ Debian-specific (package name): Installation of mongrel-cluster allows one to use additional commands, such as .BR cluster::configure . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470918: sudo-ldap: uses wrong hostname
On Thu, Apr 03, 2008 at 12:11:17PM -0600, Bdale Garbee wrote: On Fri, 2008-03-14 at 20:38 +0100, Lluis wrote: 127.0.0.1 localhost 127.0.0.1 hostname.domain hostname I'm not accustomed to seeing two lines for the same IP address in /etc/hosts, I'm not sure that's a good idea... it's hard to decide what behavior should really rbe expected in this case. What happens if you combine the entries into one line like this? 127.0.0.1 hostname.domain hostname localhost Debian seems to do new installs like this: 127.0.0.1 localhost 127.0.1.1 nadir so localhost 127.0.0.1 is the canonical name for the first loopback address, and the hostname also goes to a reasonable place (although not with the public IP address, since that isn't know and may not be constant). I think /etc/hostname is used as an index to look up in /etc/hosts, so hostname should be a public (or otherwise not loopback) IP address, so the output of hostname -f and -s is right. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474157: cron: fails to run jobs during DST time changes
merge 217836 458123 474157 tag 474157 fixed-upstream thanks On Tue, Apr 01, 2008 at 10:21:30AM +0400, Petya Kohts wrote: Jobs scheduled to run between 1 and 2 am are not run when time moves forward for 1-3 hours (at the beginning of DST) and are run twice when time moves backward for 1-3 hours (at the end of DST). Included is the patch against current trunk. Thanks for reporting. It seems to be the same as bug#217836. Can you describe the derivation of your patch? It seems to be applied to upstream cron code in version 4.1 from ISC. I'm a bit confused about the state of DST handling; there was a patch applied in Debian revision -53, but the patch is large (and combined with other changes) so the (intended) effect of the changes aren't entirely clear to me. As I recall, that patch also seemed to have been applied in the ISC release. Steve, do you recall what this patch was supposed to do? Where can I find the openbsd diff (just looked, without success). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474008: mongrel: update manpage
Package: mongrel Version: 1.1.4-1 Severity: minor Tags: patch File: /usr/share/man/man1/mongrel_rails.1.gz You might also mention that modular commands (as I understand) like cluster::configure are supported by installing (in this case) mongrel-cluster. --- /usr/share/man/man1/mongrel_rails.1.gz +++ /tmp/mongrel_rails1.gz.3945 2008-04-02 10:29:39.0 -0400 @@ -1,4 +1,4 @@ -.TH MONGREL_RAILS 1 2006-11-17 Mongrel Rails +.TH MONGREL_RAILS 1 2008-04-02 Mongrel Rails .SH NAME mongrel_rails \- Ruby Web Server . @@ -27,7 +27,7 @@ .TP mongrel_rails start -G mongrel_8080.yml -e production -p 8080 .PP -And it'll write all the options possible to mongrel_8080.yml, but with your specific changed for environment (-e production) and port (-p 8080). When you run a configuration file with -C, don't pass other options. Rather than have complex rules about whether a configuration file or command line option wins, mongrel_rails just uses configuration file and defaults, or command line options and defaults. Basically don't mix, it won't work. +And it'll write all the options possible to mongrel_8080.yml, but with your specific changes for environment (-e production) and port (-p 8080). When you run a configuration file with -C, don't pass other options. Rather than have complex rules about whether a configuration file or command line option wins, mongrel_rails just uses configuration file and defaults, or command line options and defaults. Basically don't mix, it won't work. . .SH COMMANDS The following commands are supported by mongrel: @@ -36,7 +36,7 @@ .br \fBstop\fP Stops the server. Mongrel is very conservative when it shuts down, so it will wait up to 60 seconds for threads to exit before it finally exits gracefully. .br -\fBstop --force [--wait n]\fP Stops the server. This sends mongrel a kill -9 and then you must delete the .pid file. If the wait parameter is specified, mongrel will wait n seconds before it sends the kill sign. +\fBstop --force [--wait n]\fP Stops the server. This sends mongrel a kill -9 and then you must delete the .pid file. If the wait parameter is specified, mongrel will wait n seconds before it sends the kill signal. .br \fBrestart\fP Restarts the server. . @@ -120,7 +120,8 @@ \fB--version\fPShow mongrel version . .SH SEE ALSO -.BR pen (1), mongrel-cluster (1) +.BR pen (1), +.BR mongrel-cluster (1) . .SH AUTHOR Mongrel (http://mongrel.rubyforge.org/) was written by Zed Shaw. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473711: /etc/cron.daily/standard: should not check lost+found
severity 473711 wishlist retitle 473711 cron.standard: please provide configuration facility to avoid given filesystems thanks On Tue, Apr 01, 2008 at 01:08:25AM -0400, Stefan Monnier wrote: shortens their life expectancy), but really check lost+found is not something to do once a day. It'd be *much* better to do it once per boot. I think once per day is reasonable, since once per boot may be too infrequent for machines with long uptimes. In any case, I feel like it should at least be easy to turn it off. That would be easy and clean to implement, by sourcing /etc/default/cron and later testing [ -z $NO_LOST ] || losttest. However then it might be better to have a variable instead for excluding specific filesystems or filesystem types. Like: FS_EXCL=`echo $FS_EXCL |tr ' ' '\n'` if [ -z $FS_TYPES ] then df -P --type=ext2 --type=ext3 --type=xfs else for a in $FS_TYPES do df -P --type=$t done fi 2/dev/null | grep /dev/ | grep -Fxve $FS_EXCL | [...] OTOH, cron.daily/standard is a conffile, so perhaps it would be best to just make a local modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473711: /etc/cron.daily/standard: should not check lost+found
On Tue, Apr 01, 2008 at 11:56:58AM -0400, Stefan Monnier wrote: shortens their life expectancy), but really check lost+found is not something to do once a day. It'd be *much* better to do it once per boot. I think once per day is reasonable, since once per boot may be too infrequent for machines with long uptimes. I fail to understand how files can appear in lost+found without any reboot. OK, maybe let's not do it once per reboot but once per fsck. How 'bout that? Or are there circumstances where files can appear there while the system is running? I see two scenarios: . The files appear as fsck output at reboot time, but aren't immediately dealt with by the administrators, perhaps due to distraction by more serious problems. Running this test in cron daily effects a reminder the following day. . The filesystem can be manually unmounted and fscked. Do the files still end up in /mountpoint/lost+found? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473817: netstat: Add to manpage: -p only works for root/process owner
On Tue, Apr 01, 2008 at 10:03:23PM +0200, Wolf Wiegand wrote: it should be mentioned in netstat(8), that option -p will only work for root or the respective process owner. It's already there: | PID/Program name | Slash-separated pair of the process id (PID) and process name of the | process that owns the socket. --program causes this column to be | included. You will also need superuser privileges to see this informa‐ | tion on sockets you don’t own. This identification information is not | yet available for IPX sockets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#79037: this bug/#79037 - cron does not shout when the crontab lacks a newline.
* Warns when an error occurs parsing a user crontab (See: #79037).
* user.c: Drop dead code path.
It's unclear how to elegantly handle this during editing (crontab.c);
at that point, it should effect a (specific) warning and prompt about
retry the same edit?.
diff -u cron-3.0pl1/entry.c cron-3.0pl1/entry.c
--- cron-3.0pl1/entry.c
+++ cron-3.0pl1/entry.c
@@ -319,7 +319,8 @@
*/
ch = get_string(cmd, MAX_COMMAND, file, \n);
- /* a file without a \n before the EOF is rude, so we'll complain...
+ /* complain about files ending without \n, since they might
+* have been truncated.
*/
if (ch == EOF) {
ecode = e_cmd;
diff -u cron-3.0pl1/env.c cron-3.0pl1/env.c
--- cron-3.0pl1/env.c
+++ cron-3.0pl1/env.c
@@ -146,8 +146,11 @@
filepos = ftell(f);
fileline = LineNumber;
skip_comments(f);
- if (EOF == get_string(envstr, MAX_ENVSTR - 1, f, \n))
+ if (feof(f)) { return ERR; }
+ if (EOF == get_string(envstr, MAX_ENVSTR - 1, f, \n)) {
+ log_it(CRON,getpid(),DEBUG,error parsing crontab);
return (ERR);
+ }
envstr[MAX_ENVSTR - 1] = '\0';
diff -u cron-3.0pl1/user.c cron-3.0pl1/user.c
--- cron-3.0pl1/user.c
+++ cron-3.0pl1/user.c
@@ -208,10 +208,6 @@
*/
while ((status = load_env(envstr, file)) = OK) {
switch (status) {
- case ERR:
- free_user(u);
- u = NULL;
- goto done;
case FALSE:
#ifdef DEBIAN
err_user = fname;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473458: manpages-dev: dlopen man page contradicts ld.so(8)
reassign 473458 libc6
found 473458 2.7-9
thanks
On Sun, Mar 30, 2008 at 09:48:46PM +0300, ygrek wrote:
man dlopen says :
Otherwise, the
dynamic linker searches for the library as follows (see ld.so(8) for
further details):
[...]
o The directories /lib and /usr/lib are searched (in that order).
and man ld.so :
The necessary shared libraries needed by the program are searched for
in the following order
[...]
o In the default path /usr/lib, and then /lib.
so what is searched first - /usr/lib or /lib?
$ sudo mv -iv /etc/ld.so.cache{,~}
open(/etc/ld.so.cache, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No
such file or directory)
[...]
open(/lib/i686/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No such
file or directory)
[...]
open(/lib/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No such file
or directory)
[...]
open(/lib/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/lib/tls/i686/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT
(No such file or directory)
[...]
open(/usr/lib/i686/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No
such file or directory)
[...]
open(/usr/lib/i686/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/lib/cmov/libbfd-2.18.0.20080103.so, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/lib/libbfd-2.18.0.20080103.so, O_RDONLY) = 4
open(/lib/i686/cmov/libc.so.6, O_RDONLY) = 4
So ld.so uses (roughly speaking) /lib then /usr/lib. As it turns out,
dlopen seems to do kind of the same thing:
open(/etc/ld.so.cache, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libdl.so.2, O_RDONLY) = -1 ENOENT (No such file or
directory)
[...]
open(/lib/i686/cmov/libdl.so.2, O_RDONLY) = 3
[...]
open(/lib/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/lib/tls/i686/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file
or directory)
[...]
open(/usr/lib/i686/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file or
directory)
[...]
open(/usr/lib/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/lib/libc.so.6x, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/lib/i486-linux-gnu/tls/i686/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT (No
such file or directory)
[...]
open(/usr/lib/i486-linux-gnu/tls/i686/cmov/libc.so.6x, O_RDONLY) = -1 ENOENT
(No such file or directory)
[...]
The i486-linux-gnu comes from:
$ cat /etc/ld.so.conf
/usr/local/lib
include /etc/ld.so.conf.d/*.conf
$ cat /etc/ld.so.conf.d/i486-linux-gnu.conf
# Multiarch support
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
That's the default file content, for (Debian-specific?) multiarch
patch to libc6.
The i686, cmov stuff may be distribution specific; the /lib/i686 stuff
is provided by an libc6-i686 package compiled for CPUs with opcodes
not present in vanilla 486 (the earliest x86 CPU supported by
unpatched Debian).
But I think it's sufficiently accurate to say that the /lib heirarchy
is searched before that of /usr/lib, so ld.so.8 is wrong, thus
reassigning.
I note that libc6 2.7 ldconfig now uses /var/cache/ldconfig to
minimize its runtime.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472341: nfs-common: ./configure error searching for KRBDIR
On Sun, Mar 30, 2008 at 03:39:09AM +0200, Steinar H. Gunderson wrote: place. I assume you wouldn't have any ideas? Nope, sorry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473272: bugs.debian.org: forwarded address containing a comma displayed incorrectly
On Sat, Mar 29, 2008 at 07:14:13PM +0100, Ansgar Burchardt wrote: The package information page doesn't display forwared addresses containing a comma incorrectly. The link already ends before the comma, breaking the URL. See http://bugs.debian.org/src:simutrans for an example (the bug #473245 is forwarded to http://forum.simutrans.com/index.php/topic,7611.0.html). On the page with the bug report itself, the link is displayed correctly. See also #367813; bts-link seems to use this /, (!:http://)/ interpretation, so it's not clear to me what the right fix is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464151: this bug/#464151 - sudo 1.6.9p11-2 does not solve Bug #402329
On Thu, Mar 27, 2008 at 08:58:58AM +0100, Dr. Markus Waldeck wrote: What version pam? I use unstable with the default configuration files. The default configuration files don't include any limits.conf entries. Please send all the relevant files, except perhaps conffiles for which the checksum matches that in dpkg -s. Your modules and runtime package is not update to date! Ok, I upgraded them and found that libpam-modules/unstable seems to be the cause. PAM people: should the bug be reassigned (and actually merged with #404836)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472932: bochs: manpage not gzipped (cron)
Package: bochs Version: 2.3.6-3 On Thu, Mar 27, 2008 at 06:27:56AM -0400, Cron Daemon wrote with Subject: Re: Cron [EMAIL PROTECTED] test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ): /etc/cron.daily/man-db: gzip: /usr/share/man/man1/bochs.1.gz: not in gzip format mandb: command '/bin/gzip -dc /usr/share/man/man1/bochs.1.gz' failed with exit status 256 mandb: warning: /usr/share/man/man1/bochs-bin.1.gz: bad symlink or ROFF `.so' request gzip: /usr/share/man/man1/bochs.1.gz: not in gzip format mandb: command '/bin/gzip -dc /usr/share/man/man1/bochs.1.gz' failed with exit status 256 mandb: warning: /usr/share/man/man1/bochs.1.gz: bad symlink or ROFF `.so' request gzip: /usr/share/man/man5/bochsrc.5.gz: not in gzip format mandb: command '/bin/gzip -dc /usr/share/man/man5/bochsrc.5.gz' failed with exit status 256 mandb: warning: /usr/share/man/man5/bochsrc.5.gz: bad symlink or ROFF `.so' request -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472938: cron: SELINUX data uninitialized
Package: cron
Version: 3.0pl1-104
Version: 3.0pl1-83
X-Debbug-Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
../do_command.c:338: warning: `scontext' is used uninitialized in this function
This is present in the initial patch in revision 83. I think the
fprintf should use u-scontext instead of scontext (and probably
should call log_it() instead).
| 333 #ifdef WITH_SELINUX
| 334 if ((is_selinux_enabled() 0) (u-scontext
!= 0L)) {
| 335 security_context_t scontext;
| 336 if (setexeccon(u-scontext) 0) {
| 337 if (security_getenforce() 0) {
| 338 fprintf(stderr, Could not set exec
context to %s for user %s\n, scontext,u-name);
| 339 _exit(ERROR_EXIT);
| 340 }
| 341 }
| 342 }
| 343 #endif
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472937: logcheck: minor grammar mistake in header.txt
On Thu, Mar 27, 2008 at 01:51:18PM +0200, Jonathan Hitchcock wrote: /etc/logcheck/header.txt has the phrase If you wish to no-longer receive it, which is a bit klunky (and, let's be honest, it splits an infinitive). Also, no-longer is not a hyphenated word. Hmm, what infinitive? I think an infinitive is to XX, but to wish isn't what's used. Could we change it to If you no longer wish to receive it? It's one step closer to Debian perfection! I would phrase it in the positive: If you wish to stop receiving it or stop generating it or disable it... Otherwise no longer wish is just a lack of a wish, rather than a wish for the inverse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#155109: this bug/#155109 - cron: sendmail can time out during extended interval of job execution
tag 155109 patch
thanks
#155109 - cron: sendmail can time out during extended interval of job execution
http://bugs.debian.org./155109
I'm including patches for cron-3 and cron-4 which effect the saving of
job output to a tempfile rather than a potentially-longlived pipe to
sendmail. That also allowed me to output a warning when a job fails.
diff -u cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
--- cron-3.0pl1/debian/changelog
+++ cron-3.0pl1/debian/changelog
@@ -1,3 +1,11 @@
+cron (3.0pl1-104.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * do_command.c: Call log_it rather than fprintf when execing a user command
+fails (Closes: 443615).
+
+ -- Justin Pryzby [EMAIL PROTECTED] Thu, 27 Mar 2008 09:04:26 -0400
+
cron (3.0pl1-104) unstable; urgency=low
* Discard errors from df in the standard daily cron task to prevent errors
diff -u cron-3.0pl1/debian/NEWS cron-3.0pl1/debian/NEWS
--- cron-3.0pl1/debian/NEWS
+++ cron-3.0pl1/debian/NEWS
@@ -1,3 +1,10 @@
+cron (3.0pl1-104.1) unstable; urgency=low
+
+Debian cron now outputs a warning to the logfile and to the mail when
+commands fail.
+
+ -- Justin Pryzby [EMAIL PROTECTED] Thu, 27 Mar 2008 15:29:32 -0400
+
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
@@ -9 +15,0 @@
-
diff -u cron-3.0pl1/do_command.c cron-3.0pl1/do_command.c
--- cron-3.0pl1/do_command.c
+++ cron-3.0pl1/do_command.c
@@ -111,12 +111,21 @@
}
+/*
+ * CROND
+ * - cron (runs child_process);
+ *- cron (runs exec sh -c 'tab entry');
+ *- cron (writes any %-style stdin to the command);
+ *- mail (popen writes any stdout to mailcmd);
+ */
+
static void
child_process(e, u)
entry *e;
user*u;
{
- int stdin_pipe[2], stdout_pipe[2];
+ int stdin_pipe[2];
+ FILE*out;
register char *input_data;
char*usernm, *mailto;
int children = 0;
@@ -179,7 +188,11 @@
/* create some pipes to talk to our future child
*/
pipe(stdin_pipe); /* child's stdin */
- pipe(stdout_pipe); /* child's stdout */
+ /* child's stdout */
+ if ((out=tmpfile())==NULL) {
+ log_it(CRON,getpid(),error,create tmpfile);
+ exit(ERROR_EXIT);
+ }
/* since we are a forked process, we can diddle the command string
* we were passed -- nobody else is going to use it again, right?
@@ -270,7 +283,6 @@
* appropriate circumstances.
*/
close(stdin_pipe[WRITE_PIPE]);
- close(stdout_pipe[READ_PIPE]);
/* grandchild process. make std{in,out} be the ends of
* pipes opened by our daddy; make stderr go to stdout.
@@ -278,14 +290,14 @@
/* Closes are unnecessary -- let dup2() do it */
/* close(STDIN) */; dup2(stdin_pipe[READ_PIPE], STDIN);
- /* close(STDOUT) */; dup2(stdout_pipe[WRITE_PIPE], STDOUT);
+ dup2(fileno(out), STDOUT);
/* close(STDERR)*/; dup2(STDOUT, STDERR);
/* close the pipes we just dup'ed. The resources will remain.
*/
close(stdin_pipe[READ_PIPE]);
- close(stdout_pipe[WRITE_PIPE]);
+ // Don't do this: fclose(out);
/* set our login universe. Do this in the grandchild
* so that the child can invoke /usr/lib/sendmail
@@ -364,7 +376,6 @@
* grandchild process...
*/
close(stdin_pipe[READ_PIPE]);
- close(stdout_pipe[WRITE_PIPE]);
/*
* write, to the pipe connected to child's stdin, any input specified
@@ -385,11 +396,6 @@
Debug(DPROC, ([%d] child2 sending data to grandchild\n,
getpid()))
- /* close the pipe we don't use, since we inherited it and
-* are part of its reference count now.
-*/
- close(stdout_pipe[READ_PIPE]);
-
/* translation:
* \% - %
* % - \n
@@ -439,165 +445,12 @@
Debug(DPROC, ([%d] child reading output from grandchild\n, getpid()))
- /*local*/{
- register FILE *in = fdopen(stdout_pipe[READ_PIPE], r);
- register intch = getc(in);
-
- if (ch != EOF) {
- register FILE *mail;
- register intbytes = 1;
- int status = 0;
-
- Debug(DPROC|DEXT,
- ([%d] got data (%x:%c) from grandchild\n,
- getpid(), ch, ch))
-
- /* get name of recipient. this is MAILTO if set to a
-* valid local username; USER otherwise
Bug#464151: this bug/#464151 - sudo 1.6.9p11-2 does not solve Bug #402329
On Wed, Mar 26, 2008 at 04:32:02PM +0100, Dr. Markus Waldeck wrote:
Could you test if this problem exists with recent versions of sudo?
In a quick test, sudo -s set my ulimit back to unlimited:
% sudo -V
Sudo version 1.6.9p12
% ulimit -t
600
% sudo -s
# ulimit -t
600
I tested with bash and zsh on console and in a xterm.
Can you send the content of your pam.d/sudo, security/limits.conf, and
shell rc files (/etc/profile, /etc/bash.bashrc ~/.bash_profile,
~/.bashrc ~/.profile)?
What version pam?
Here:
dpkg -l libpam{0g,-modules,-runtime}
ii libpam-modules 0.79-5 Pluggable Authentication Modules for PAM
ii libpam-runtime 0.79-5 Runtime support for the PAM library
ii libpam0g 0.99.7.1-6 Pluggable Authentication Modules library
I just checked that sudo/stable suffers from this bug, but
sudo/unstable (which depends on libpam0g/unstable) doesn't (here).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472604: manpage should mention that timestamps are bound to a terminal
On Tue, Mar 25, 2008 at 09:15:05AM +0100, Georg Neis wrote: Package: sudo Version: 1.6.9p12-1 Severity: normal --- Please enter the report below this line. --- The manual page says: | Once a user has been authenticated, a timestamp is updated and the | user may then use sudo without a password for a short period of time | (15 minutes unless overridden in sudoers). It doesn't say, however, that a timestamp is bound to a particular terminal. I think that's only true if you enable tty_tickets, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427817: i8kutils: i8kctl(1) manpage and order of fields
tag 427817 patch thanks README.i8kutils.gz has it right, consistent with i8k.c. --- /usr/share/man/man1/i8kctl.1.gz +++ /tmp/i8kctl1.gz.38662008-03-25 22:49:34.0 -0400 @@ -24,9 +24,9 @@ .br 5. left fan status .br -6. right fan speed +6. right fan status .br -7. left fan status +7. left fan speed .br 8. right fan speed .br -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465959: saods9 -- image display tool for astronomy
The package is complicated due to inclusion of many sub-packages [0], for one of which the source is not included in the original tarball [1] and another is modified for the package [2]. Some more info is in the README.Debian. The current packaging diff leaves some room for improvement [3]. It has some useful content though: . a perl script to generate a useful manpage from html documentation; . a copyright file which is pretty-complete for the source for all the files in all the sub-packages. This should be good enough to consider any errors, ommisions, inaccuracies or other problems to be bugs rather than part of some wider, more general problem that should get fixed at some later date. It's become increasingly clear that I don't have the time to deal with it ATM. I'd be happy to help anyone interested in adopting the package, if you take the initiative to tackle one of the larger issues. There's some new upstream releases so you should be prepared to redo some large fraction of the packaging (depending partly on the relative ease of making yourself comfortable with existing packaging). [0] In previous versions, there's blt2.4z tcl8.4.9 tcllib-1.6.1 tk8.4.9 tkimg1.3rc2 tktable2.9 zlib-1.2.3 (3 copies!) I had modified the compilation to depend on the appropriate packages and use shared libraries instead. At first glance the included subpackages don't seem to have changed in any major way in the latest versions. [1] So I replaced the obscured C source with an older, fortran implementation. [2] The included tcl source has some small patch. It was never clear to me why this was necessary, but could be associated with a crash I've seen when linking with the Debian lib. #304804 [3] Off the top of my head, some patch management system should be used, and the source-repacking bits should be redone to 1) not remove sources when that isn't necessary for license reasons; and, 2) move such sources out of the way before compilation to detect if they're used, and put them back in the clean target to get a clean diff. References http://packages.debian.org/sid/saods9 http://bugs.debian.org/saods9 http://packages.debian.org/changelogs/pool/main/s/saods9/saods9_4.0b7-1.5/changelog http://packages.debian.org/changelogs/pool/main/s/saods9/saods9_4.0b7-1.5/saods9.copyright -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361535: closed by Steve Kemp [EMAIL PROTECTED] (Re: bash: [COMPLETION] apt-cache showsrc doesn't complete on source package names)
reopen 361535 thanks $ apt-cache showsrc diffutils |sed 2q Package: diffutils Binary: diff $ lynx -dump http://packages.debian.org/src:diffutils [...] Source Package diffutils [...] * [40]sid (utils): 2.8.1-12 Binary packages: [41]diff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471718: aptitude fails during upgrade
On Wed, 19 Mar 2008, Justin Pryzby wrote: $ aptitude search session manag aptitude: error while loading shared libraries: libapt-pkg-libc6.7-6.so.4.6: cannot open shared object file: No such file or directory On Wed, Mar 19, 2008 at 06:01:52PM -0700, Daniel Burrows wrote: You're saying that you see transient aptitude failures *while upgrading aptitude and apt*, right? i.e., after the upgrade finished, everything worked again? Correct. I can reproduce it at will by upgrading/downgrading apt. I was of the impression that dpkg attempts to let packages work normally even during upgrades. That's why statoverride exists (to give new permissions to the file before the rename()), and why it renames files atomically, and why an upgrade is more elaborate than tar old files remove unpack new files || unpack old files. Of course, the package may not work during the upgrade interval for some higher-level reasons (inconsistencies between files in the new/old versions or such). Why does apt's library include the libc6 version? I guess that ultimately causes the problem. I know that dpkg doesn't remove files in oldver but not in new-ver until the other files in new-ver have been unpacked; however, I don't know if dpkg attempts to unpack files only in new-ver before unpacking the files common to both. (That alone wouldn't fix the problem anyway, since the order of unpacking isn't guaranteed by a normal dependency). Am I wrong to think that library transitions (libfoo1 = libfoo2) and ABI changes (gcc-4.0) are supposed to be supported without things breaking during the upgrade interval? On Thu, Mar 20, 2008 at 10:26:34AM +0100, Raphael Hertzog wrote: And if you can try reproduce it (by downgrading/reupgrading) it would be great to do a simple ls -al /usr/lib/libapt-pkg-libc6.7-6.so.4.6 at the time of the failure. dpkg - warning: downgrading aptitude from 0.4.10-1+b2 to 0.4.4-4. Preparing to replace aptitude 0.4.10-1+b2 (using .../aptitude_0.4.4-4_i386.deb) ... $ aptitude search || ls -l /usr/lib/libapt* aptitude: error while loading shared libraries: libapt-pkg-libc6.3-6.so.3.11: cannot open shared object file: No such file or directory lrwxrwxrwx 1 root root 1K 2008-03-21 10:35 /usr/lib/libapt-inst-libc6.3-6.so.1.1 - libapt-inst-libc6.3-6.so.1.1.0 -rw-r--r-- 1 root root 81K 2007-02-26 16:22 /usr/lib/libapt-inst-libc6.3-6.so.1.1.0 lrwxrwxrwx 1 root root 1K 2008-03-21 10:32 /usr/lib/libapt-pkg-libc6.7-6.so.4.6 - libapt-pkg-libc6.7-6.so.4.6.0 -rw-r--r-- 1 root root 801K 2008-02-16 19:15 /usr/lib/libapt-pkg-libc6.7-6.so.4.6.0 Without further ado, the original upgrade logs have: aptitude: === [INSTALL, DEPENDENCIES] libcwidget1 [UPGRADE] apt 0.6.46.4-0.1 - 0.7.11 [UPGRADE] apt-utils 0.6.46.4-0.1 - 0.7.11 [UPGRADE] aptitude 0.4.4-4 - 0.4.10-1+b1 [UPGRADE] libstdc++6 4.1.1-21 - 4.3.0-1 === dpkg.log: 2008-03-19 14:00:06 upgrade libstdc++6 4.1.1-21 4.3.0-1 2008-03-19 14:00:06 status half-configured libstdc++6 4.1.1-21 2008-03-19 14:00:06 status unpacked libstdc++6 4.1.1-21 2008-03-19 14:00:06 status half-installed libstdc++6 4.1.1-21 2008-03-19 14:00:06 status half-installed libstdc++6 4.1.1-21 2008-03-19 14:00:06 status unpacked libstdc++6 4.3.0-1 2008-03-19 14:00:06 status unpacked libstdc++6 4.3.0-1 2008-03-19 14:00:06 status unpacked libstdc++6 4.3.0-1 2008-03-19 14:00:06 status half-configured libstdc++6 4.3.0-1 2008-03-19 14:00:06 status installed libstdc++6 4.3.0-1 2008-03-19 14:00:06 install libcwidget1 none 0.5.6.1-3 2008-03-19 14:00:06 status half-installed libcwidget1 0.5.6.1-3 2008-03-19 14:00:06 status unpacked libcwidget1 0.5.6.1-3 2008-03-19 14:00:06 status unpacked libcwidget1 0.5.6.1-3 2008-03-19 14:00:06 upgrade aptitude 0.4.4-4 0.4.10-1+b1 2008-03-19 14:00:06 status half-configured aptitude 0.4.4-4 2008-03-19 14:00:06 status unpacked aptitude 0.4.4-4 2008-03-19 14:00:06 status half-installed aptitude 0.4.4-4 2008-03-19 14:00:06 status half-installed aptitude 0.4.4-4 2008-03-19 14:00:07 status unpacked aptitude 0.4.10-1+b1 2008-03-19 14:00:07 status unpacked aptitude 0.4.10-1+b1 2008-03-19 14:00:07 upgrade apt-utils 0.6.46.4-0.1 0.7.11 2008-03-19 14:00:07 status half-configured apt-utils 0.6.46.4-0.1 2008-03-19 14:00:07 status unpacked apt-utils 0.6.46.4-0.1 2008-03-19 14:00:07 status half-installed apt-utils 0.6.46.4-0.1 2008-03-19 14:00:07 status half-installed apt-utils 0.6.46.4-0.1 2008-03-19 14:00:07 status unpacked apt-utils 0.7.11 2008-03-19 14:00:07 status unpacked apt-utils 0.7.11 2008-03-19 14:00:07 upgrade apt 0.6.46.4-0.1 0.7.11 2008-03-19 14:00:07 status half-configured apt 0.6.46.4-0.1 2008-03-19 14:00:07 status unpacked apt 0.6.46.4-0.1 2008-03-19 14:00:07 status half-installed apt 0.6.46.4-0.1 2008-03-19 14:00:07 status half-installed apt 0.6.46.4-0.1 2008-03-19 14:00:07 status unpacked apt 0.7.11 2008-03
Bug#471718: aptitude fails during upgrade
On Mon, Mar 24, 2008 at 08:54:21PM +0100, Raphael Hertzog wrote: On Mon, 24 Mar 2008, Justin Pryzby wrote: I was of the impression that dpkg attempts to let packages work normally even during upgrades. Well, dpkg offers some guaranty but there's no guaranty that a Depends is respected when the package is not configured: Am I wrong to think that library transitions (libfoo1 = libfoo2) and ABI changes (gcc-4.0) are supposed to be supported without things breaking during the upgrade interval? Well, when libfoo1 and libfoo2 coexist on the disk nothing breaks. And that's done with most libraries but it's not done with apt as the binary package is always apt and not libaptX followed by libaptY. What if foo-2 (Depends: libfoo2) is upgraded from foo-1 (Depends: libfoo1) and foo-2 is extracted before libfoo2)? foo might be broken during the upgrade, no? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#37665: strace exit status
The attached patch seems to have the intended effect; strace's exit
status is set to that of the ptraced process, or 1 if strace was
signalled. strace -p pid still exits with zero status.
only in patch2:
unchanged:
--- strace-4.5.15.orig/strace.c
+++ strace-4.5.15/strace.c
@@ -798,10 +798,10 @@
sigaction(SIGCHLD, sa, NULL);
#endif /* USE_PROCFS */
- if (trace() 0)
- exit(1);
+ int ret=trace();
+ if (ret0) exit(1);
cleanup();
- exit(0);
+ exit(ret);
}
int
@@ -1826,7 +1826,7 @@
pv.events = POLLWANT;
if ((what = poll (pv, 1, 1)) 0) {
if (interrupted)
- return 0;
+ return interrupted;
continue;
}
else if (what == 1 pv.revents POLLWANT) {
@@ -1837,13 +1837,13 @@
if (poll(pollv, nprocs, INFTIM) 0) {
if (interrupted)
- return 0;
+ return interrupted;
continue;
}
#else /* !HAVE_POLLABLE_PROCFS */
if (proc_poll(pollv, nprocs, INFTIM) 0) {
if (interrupted)
- return 0;
+ return interrupted;
continue;
}
#endif /* !HAVE_POLLABLE_PROCFS */
@@ -1885,7 +1885,7 @@
#endif /* !HAVE_POLLABLE_PROCFS */
}
if (interrupted)
- return 0;
+ return interrupted;
if (interactive)
sigprocmask(SIG_BLOCK, blocked_set, NULL);
@@ -2135,7 +2135,7 @@
sigprocmask(SIG_BLOCK, blocked_set, NULL);
if (interrupted)
- return 0;
+ return interrupted;
if (pid == -1) {
switch (wait_errno) {
@@ -2424,6 +2424,10 @@
return -1;
}
}
+
+ if (WIFEXITED(status)) return WEXITSTATUS(status);
+ if (WIFSIGNALED(status)) return WTERMSIG(status);
+
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472341: nfs-common: ./configure error searching for KRBDIR
Package: nfs-common Version: 1:1.1.1-14 File: http://buildd.debian.org/nfs-utils checking for nfs4_set_debug in -lnfsidmap... yes checking for Kerberos v5... ./configure: line 23606: test: 163-beta1-debian: integer expression expected /usr The current KRBDIR is /usr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472349: adduser: please delay more than 5 seconds during deluser root
Package: adduser
Version: 3.106
Tags: patch
File: /usr/sbin/deluser
See also: #471705
This patch explicit statement that there is a time limit; without
this, users are likely to reread the huge warning rather than quickly
aborting/suspending the process to investigate.
--- /usr/sbin/deluser
+++ /tmp/tmp.FqfaY26055/deluser 2008-03-23 13:50:46.0 -0400
@@ -225,11 +225,13 @@
}
# Warn in any case if you want to remove the root account
-if ($uid == 0) {
+if ($pw_uid == 0) {
+my $delay=10;
printf (gtx(WARNING: You are just about to delete the root account
(uid 0)\n));
+printf (gtx(This action will proceed in $delay seconds; ));
+printf (gtx(Press Ctrl+C immediately to abort\n));
printf (gtx(Usually this is never required as it may render the whole
system unusable\n));
-printf (gtx(Press immediately Ctrl+C if you want to abort\n));
-sleep 5;
+sleep $delay;
printf (gtx(Ok, you really want it, I'll delete that account\n));
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472349: [Adduser-devel] Bug#472349: adduser: please delay more than 5 seconds during deluser root
On Mon, Mar 24, 2008 at 12:13:57AM +, Stephen Gran wrote: This one time, at band camp, Paul Johnson said: On Sunday 23 March 2008 10:53:15 am Justin Pryzby wrote: This patch explicit statement that there is a time limit; without this, users are likely to reread the huge warning rather than quickly aborting/suspending the process to investigate. With something as grave as removing the root account, wouldn't it make much more sense to ask for explicit confirmation to be entered and wait indefinitely until that happens, similar to what you must do in dpkg or apt if you try to remove base required packages? Yes, perhaps unless an environment variable is set (to allow it to happen in batch, if that's hypothetically useful). I don't know if it'd be sufficiently safe to initialize that variable to allow root's removal if the stdio fd's are /dev/null or such. This bug is mostly harmless when deluser is called without a foolish flag like --remove-home or worse, --remove-all-files. Really? It is possible, of course, to say no, you can't ever do that, but I do feel a little uncomfortable second guessing an admin who wants to do something drastically stupid - unix doesn't generally do that. OTOH adduser/deluser are considered to be high level tools, so it perhaps it isn't entirely unreasonable to reject it at that level? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472349: [Adduser-devel] Bug#472349: adduser: please delay more than 5 seconds during deluser root
On Sun, Mar 23, 2008 at 08:59:57PM -0400, Justin Pryzby wrote: On Mon, Mar 24, 2008 at 12:13:57AM +, Stephen Gran wrote: This one time, at band camp, Paul Johnson said: On Sunday 23 March 2008 10:53:15 am Justin Pryzby wrote: This bug is mostly harmless when deluser is called without a foolish flag like --remove-home or worse, --remove-all-files. Really? Sorry, I meant to expand on that. After removing root's passwd, shadow and group entries, neither su nor sudo works (although single user mode might), and I suspect pam prevents things like cron from running normally. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468075: this bug/#468075 - sudo: system freeze
Thanks for the analysis. Why does it only affect aptitude sometimes (after an upgrade is aborted)? Is that due to some cache? Why isn't apt/itude using mmap (?)? Out of curiousity, what kernel and hardware are you using? On Fri, Mar 21, 2008 at 08:49:13AM -0700, Daniel Burrows wrote: On Fri, Mar 21, 2008 at 07:14:15AM -0700, Daniel Burrows [EMAIL PROTECTED] was heard to say: Interestingly, if I run these on a text console, other text consoles and the programs running in them are unaffected. Only X suffers a complete freeze. Here's an odd thing. If I ssh to localhost, then run the test program I wrote, I get no freeze. If I run su and then run the test program, I get no freeze. If I run sudo sh and then run the test program, I get no freeze. But sudo su -c ./test does freeze. sudo ./test also freezes. (sudo su never made sense to me). I'm not sure what to make of that. Also, while testing, I tried to minimize the time interval of the freeze, by running: while sleep 4; do sudo killall test2; done That worked (terminated the program after a short interval, but long enough for me to know that it froze). However when I tried (to avoid spamming my syslog with sudo events) this: sudo sh -c 'while sleep 4; do killall test2; done' it didn't work (the root shell loop apparently was frozen). Lacking a better explanation, it seems like processes that were UID 0 at some point in time get stuck, but processes that become UID 0 don't. Apparently, all that's necessary is to loop around lseek with a nonzero offset. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468075: this bug/#468075 - sudo: system freeze
reassign 468075 linux-image-2.6.24-1-686 found 468075 2.6.24-4 thanks Hello kernel maintainers, Please see this bug log regarding a soft lockup. A root processes looping around time() is sufficient to make the system unusable. Mar 21 13:06:39 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [bash:2363] Mar 21 13:06:39 libra kernel: Mar 21 13:06:39 libra kernel: Pid: 2363, comm: bash Not tainted (2.6.24-1-686 #1) Mar 21 13:06:39 libra kernel: EIP: 0060:[c0113c77] EFLAGS: 00200286 CPU: 0 Mar 21 13:06:39 libra kernel: EIP is at flush_tlb_page+0x3f/0x62 Mar 21 13:06:39 libra kernel: EAX: 080f55e8 EBX: 080f55e8 ECX: cf5663d4 EDX: cf4bf9b0 Mar 21 13:06:39 libra kernel: ESI: cf5cd900 EDI: cf5663d4 EBP: c10780a0 ESP: ce15de6c Mar 21 13:06:39 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:06:39 libra kernel: CR0: 8005003b CR2: 080f55e8 CR3: 0f5ce000 CR4: 06d0 Mar 21 13:06:39 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:06:39 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:06:39 libra kernel: [c01663f3] do_wp_page+0x3cb/0x4d4 Mar 21 13:06:39 libra kernel: [c016730f] __pte_alloc+0x8d/0x9a Mar 21 13:06:39 libra kernel: [c0165c8b] vm_normal_page+0xd/0x3e Mar 21 13:06:39 libra kernel: [c016791b] copy_page_range+0x2e2/0x383 Mar 21 13:06:39 libra kernel: [c0167981] copy_page_range+0x348/0x383 Mar 21 13:06:39 libra kernel: [c01682a7] handle_mm_fault+0x609/0x685 Mar 21 13:06:39 libra kernel: [c01099ca] sched_clock+0x8/0x18 Mar 21 13:06:39 libra kernel: [c0103044] __switch_to+0x9d/0x11d Mar 21 13:06:39 libra kernel: [c011bf45] do_page_fault+0x1f7/0x592 Mar 21 13:06:39 libra kernel: [c0123ec5] do_fork+0x120/0x1cc Mar 21 13:06:39 libra kernel: [c012f3e6] sys_rt_sigprocmask+0x4b/0xc7 Mar 21 13:06:39 libra kernel: [c011bd4e] do_page_fault+0x0/0x592 Mar 21 13:06:39 libra kernel: [c02bdc32] error_code+0x72/0x78 Mar 21 13:06:39 libra kernel: [c02b] unix_mkname+0x4d/0x6f Mar 21 13:08:36 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [strace:2485] Mar 21 13:08:36 libra kernel: Mar 21 13:08:36 libra kernel: Pid: 2485, comm: strace Not tainted (2.6.24-1-686 #1) Mar 21 13:08:36 libra kernel: EIP: 0060:[c012022f] EFLAGS: 0282 CPU: 0 Mar 21 13:08:36 libra kernel: EIP is at finish_task_switch+0x25/0x81 Mar 21 13:08:36 libra kernel: EAX: c1207940 EBX: ce37f740 ECX: ce19a030 EDX: ce19a000 Mar 21 13:08:36 libra kernel: ESI: EDI: ce19a030 EBP: 0008 ESP: cd0b5f50 Mar 21 13:08:36 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:08:36 libra kernel: CR0: 8005003b CR2: b7804000 CR3: 0df7 CR4: 06d0 Mar 21 13:08:36 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:08:36 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:08:36 libra kernel: [c02bc7aa] schedule+0x588/0x5ec Mar 21 13:08:36 libra kernel: [c0248cae] input_proc_handlers_open+0x8/0xc Mar 21 13:08:36 libra kernel: [c012b977] sys_ptrace+0x7c/0x83 Mar 21 13:08:36 libra kernel: [c0103f76] work_resched+0x5/0x26 Mar 21 13:08:40 libra kernel: BUG: soft lockup - CPU#0 stuck for 2s! [strace:2485] Mar 21 13:08:40 libra kernel: Mar 21 13:08:40 libra kernel: Pid: 2485, comm: strace Not tainted (2.6.24-1-686 #1) Mar 21 13:08:40 libra kernel: EIP: 0060:[c02bda19] EFLAGS: 0206 CPU: 0 Mar 21 13:08:40 libra kernel: EIP is at _spin_unlock_irqrestore+0xa/0x13 Mar 21 13:08:40 libra kernel: EAX: 0206 EBX: ECX: 0206 EDX: 0200 Mar 21 13:08:40 libra kernel: ESI: ce19a030 EDI: EBP: cd0b4000 ESP: cd0b5f7c Mar 21 13:08:40 libra kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 21 13:08:40 libra kernel: CR0: 8005003b CR2: b77c1000 CR3: 0df7 CR4: 06d0 Mar 21 13:08:40 libra kernel: DR0: DR1: DR2: DR3: Mar 21 13:08:40 libra kernel: DR6: 4ff0 DR7: 0400 Mar 21 13:08:40 libra kernel: [c01220bf] wait_task_inactive+0x45/0x62 Mar 21 13:08:40 libra kernel: [c012b8f5] ptrace_check_attach+0xa1/0xa7 Mar 21 13:08:40 libra kernel: [c012b944] sys_ptrace+0x49/0x83 Mar 21 13:08:40 libra kernel: [c0103ed6] syscall_call+0x7/0xb On Fri, Mar 21, 2008 at 07:14:15AM -0700, Daniel Burrows wrote: On Thu, Mar 20, 2008 at 12:24:17PM -0400, Justin Pryzby [EMAIL PROTECTED] was heard to say: On Wed, Mar 19, 2008 at 06:31:13PM -0700, Daniel Burrows wrote: Most likely some critical part of your X session wanted to access the disk, and it was blocked out by apt. I'm not sure how to confirm this; on Windows there are ways of monitoring file accesses across the system (so you could see which programs were contending with apt for the disk and how long they got blocked), but I don't know of any equivalent for Linux. I don't think it's disk IO related. Having run this command very often, all my Packages files are cached at various layers, and (despite having a not-recent machine with a slow disk and only 256MB RAM
Bug#472004: awesome: /Window Managers/s, ,, /usr/share/menu/awesome
Package: awesome Version: 2.2~rc4-1 Tags: patch File: /usr/share/menu/awesome --- /usr/share/menu/awesome +++ /tmp/tmp.lfCMkv5852/awesome 2008-03-21 14:03:28.0 -0400 @@ -1,4 +1,4 @@ -?package(awesome):needs=wm section=Window Managers \ +?package(awesome):needs=wm section=WindowManagers \ title=awesome longtitle=awesome window manager \ command=/usr/bin/awesome \ icon=/usr/share/pixmaps/awesome.xpm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444934: this bug/#444934 - aptitude: fails to install libncurses5-dev/unstable with reject
I think I have some more information about this bug, although I'm not sure if it's actually the same. sudo aptitude install libc6-amd64 [...] The following packages have unmet dependencies: libc6-amd64: Depends: libc6 (= 2.3.6.ds1-13etch5) but 2.7-9 is installed. [...] The following actions will resolve these dependencies: Install the following packages: libc6-amd64 [2.7-9 (unstable, now)] [...] Accept this solution? [Y/n/q/?] No packages will be installed, upgraded, or removed. Note that libc6-amd64 is (unstable, now). Indeed: rc libc6-amd642.7-9 GNU C Library: 64bit Shared libraries for AM So, aptitude initially decided to not install the stable version (from Default-Release) due to dependencies, calculated a solution, but then decided that the installation would do nothing since it wasn't in state removed. However I think the correct check test would be closer to if package in state *installed*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472004: awesome: /Window Managers/s, ,, /usr/share/menu/awesome
On Fri, Mar 21, 2008 at 07:40:11PM +0100, Julien Danjou wrote: Hm, WindowManagers is the old menu stuff, isn't it? Not sure, I was of the impression this was just a typo. I noticed (after installing 10+ window managers) that awesome was the only one in that section. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460194: this bug/#460194 - aptitude: freezes desktop for four seconds when launched with sudo
#460194 - aptitude: freezes desktop for four seconds when launched with sudo http://bugs.debian.org./460194 I can reproduce this problem readily. You said you were using 2.6.24-rc, but that the problem occured with older kernels. How old? I'm not able to reproduce it with 2.6.22. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468075: this bug/#468075 - sudo: system freeze
On Wed, Mar 19, 2008 at 06:31:13PM -0700, Daniel Burrows wrote: On Wed, Mar 19, 2008 at 12:55:19PM -0400, Justin Pryzby [EMAIL PROTECTED] was heard to say: Hi Apt team, do you know anything about what can cause this ? Benoît, what kernel version? sudo aptitude safe-upgrade causes X11 to freeze for 5-10 seconds. This seems to happen when the most recent upgrade attempt was forcibly-aborted (by a signal). It never used to happen for me with dist-upgrade, but after aborting a safe-upgrade, dist-upgrade is now also affected. It seems to be due to the lockfiles /var/lock/aptitude and /var/lib/dpkg/lock. Unfortunately the problem doesn't occur under strace. If your entire X11 desktop is freezing, you probably have a kernel issue, possibly compounded by X. This is 2.6.24, and I previously used .22-vserver (not that this means there can't be a new or longstanding defect or just lots of room for improvement). When an apt frontend starts, it places a lot of load on the system (in terms of hitting the disks, using the IO bus, allocating and accessing a lot of memory, etc), and perhaps the kernel isn't scheduling this very well. Certainly apt isn't, e.g., sending SIGSTOP to X. ;-) I would guess that it doesn't show up in strace because strace imposes extra latency on the process and changes scheduling (the strace process and possibly its output terminal are also active, which might give apt's competitor for I/O more chances to squeeze in). It would be interesting, but not crucial, to know whether it shows up when you use -o to send strace's output to a file. It's worse than you're thinking. When the submitter said freeze the system I assumed it was the same thing I'd seen where aptitude takes several seconds before outputting anything, and stracing it and that point shows lots of read()s of large Packages file with descriptors about ~15. That could reasonably make the system unbearable and not useful interactively, but not completely unresponsive. When I finally ran the given command, though, I got a very real freeze, as seen by the X11 interface. ICMP still responded, and the machine recovers after ~10 seconds. During that interval, however, the cursor is completely unresponsive. Most likely some critical part of your X session wanted to access the disk, and it was blocked out by apt. I'm not sure how to confirm this; on Windows there are ways of monitoring file accesses across the system (so you could see which programs were contending with apt for the disk and how long they got blocked), but I don't know of any equivalent for Linux. I don't think it's disk IO related. Having run this command very often, all my Packages files are cached at various layers, and (despite having a not-recent machine with a slow disk and only 256MB RAM) the drive heads seem to be inactive during this interval. See the attached output of top -b -d0.5 -u root, that shows the runnable/waiting processes (I did grep -Fvwe S to get rid of sleeping ones). That's consistent with the submitters loadavg data. Note that even with aptitude niced, all the other processes are starved. I ran: sh -c 'while sleep 1; do date; done' and, during the safe-upgrade initialization, got 21 lines of output, and 1 second skipped (due to some combination of the effect of added load on scheduling and perhaps being started very near to the edge of a half-second line). That's the expected result. Then I ran: sudo sh -c 'while sleep 1; do date; done. The result is startingly different: there's now a gap of *21 seconds*. So it seems that non-ptraced root processes are blocked, and others continue to be run. I still think there's some problem somewhere between apt and the kernel. ptracing aptitude might reasonably cause a behavior change due to scheduling or such, but that still leaves a fair amount of observed behavior unexplained. Justin btop - 11:31:30 up 3 days, 2:33, 6 users, load average: 0.19, 0.44, 0.30 Tasks: 81 total, 1 running, 78 sleeping, 2 stopped, 0 zombie Cpu(s): 1.9%us, 0.8%sy, 2.2%ni, 94.4%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem:256512k total, 243496k used,13016k free,12560k buffers Swap: 489972k total,35224k used, 454748k free, 170884k cached btop - 11:31:30 up 3 days, 2:33, 6 users, load average: 0.19, 0.44, 0.30 Tasks: 82 total, 5 running, 75 sleeping, 2 stopped, 0 zombie Cpu(s): 8.3%us, 11.7%sy, 11.7%ni, 68.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:256512k total, 243796k used,12716k free,12560k buffers Swap: 489972k total,35224k used, 454748k free, 170884k cached 26999 root 30 10 8584 2752 2516 R 21.0 1.1 0:00.12 stext aptitude 6 root 15 -5 000 R 0.0 0.0 0:23.30 stext events/0 2610 root 20 0 2748 848 728 R 0.0 0.3 0:04.42 stext syslogd 3126 root 20 0 15548 1192 1156 R 0.0 0.5 0:14.90 stext apache2
Bug#471667: [Pkg-shadow-devel] Bug#471667: [D-I] Configuration of passwd during debootstrap fails when run in non-clean target
On Wed, Mar 19, 2008 at 02:04:09PM +0100, Frans Pop wrote:
When during a new installation using Debian Installer the base system
installation step (which uses debootstrap) fails and is retried, the
second installation fails with the following error:
debootstrap: Setting up login (1:4.1.0-2) ...
debootstrap: Setting up passwd (1:4.1.0-2) ...
debootstrap: no matching password file entry in /etc/passwd
debootstrap: delete line 'libuuid:!:13957:0:9:7:::'?
debootstrap: pwck: no changes
debootstrap: Please correct the error and rerun `/sbin/shadowconfig on'
debootstrap: dpkg: error processing passwd (--configure):
debootstrap: subprocess post-installation script returned error exit status 1
Although running debootstrap on a non-clean target is not preferred,
this does seem like an idempotency issue that should be resolved.
Note that the failure of the initial base installation step is
completely unrelated to passwd: the initial installation of passwd (and
the rest of debootstrap) was without problems.
That seems to be passwd.postinst calling shadowconfig on calling
pwck -q, which fails. Presumably the failure is due to a real
inconsistency with system account datafiles.
I note that pwck -q doesn't seem to have the intended effect
(-q shouldn't prompt).
Can you show the relevant content of the debootstrap regarding uuid
packages? Also the output of: grep uuid
/etc/{passwd,shadow,group,gshadow} .
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471667: [Pkg-shadow-devel] Bug#471667: Bug#471667: [D-I] Configuration of passwd during debootstrap fails when run in non-clean target
clone 471667 -1 reassign -1 base-passwd retitle -1 base-passwd: update-passwd leaves account files in inconsistent state according to pwck (should remove user with low UID from shadow, too) found -1 3.5.17 thanks On Wed, Mar 19, 2008 at 03:18:57PM +0100, Frans Pop wrote: On Wednesday 19 March 2008, Justin Pryzby wrote: That seems to be passwd.postinst calling shadowconfig on calling pwck -q, which fails. Presumably the failure is due to a real inconsistency with system account datafiles. I note that pwck -q doesn't seem to have the intended effect (-q shouldn't prompt). Even if it does prompt, I don't think it actually asks for input as that would likely have resulted in a hang. I'm not completely sure of that though. I assumed it was just trying to read from a closed FD (perhaps not due to dpkg not providing one in general, but IDK what your installation environment is, and guessed that it didn't provide a stdin). Do you know what version libuuid was initially installed? I suspect one of the problems was fixed in libuuid1 1.40.7-1 (See #466929). If you agree, the initial report (#471667) can be closed. I changed my mind about the passwd pwck -q prompting problem. On rereading the manual page, the description isn't that it avoids prompting, but rather inhibits report of warnings (errors still cause prompts). That leaves one remaining problem (plus excessive configuration attempts by dpkg): base-passwd leaves the account files in a state where pwck later fails. base-passwd should also have removed the relevant line from /etc/shadow. After the successful initial debootstrap run: /etc/passwd:libuuid:x:42:101::/var/lib/libuuid:/bin/sh /etc/shadow:libuuid:!:13957:0:9:7::: /etc/group:libuuid:x:101: /etc/gshadow:libuuid:!:: After the second failed run the line in /etc/passwd has disappeared: /etc/shadow:libuuid:!:13957:0:9:7::: /etc/group:libuuid:x:101: /etc/gshadow:libuuid:!:: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471705: passwd: deluser weirdness; uninit value
Package: passwd Version: 1:4.0.18.1-7 Severity: normal $ sudo useradd useradd $ grep useradd /etc/passwd useradd:x:1004:1007::/home/useradd:/bin/sh $ sudo deluser useradd Use of uninitialized value in numeric eq (==) at /usr/sbin/deluser line 228. WARNING: You are just about to delete the root account (uid 0) Usually this is never required as it may render the whole system unusable Press immediately Ctrl+C if you want to abort Ok, you really want it, I'll delete that account Removing user `useradd' ... Warning: group `useradd' has no more members. Done. $ grep root /etc/passwd root:x:0:0:root:/root:/bin/bash There was no delay for me to ^C (or otherwise the delay wasn't long enough to read and reread that surprising message). Presumably the error message (apparently a false-positive) is due to the uninitialized value. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471667: [Pkg-shadow-devel] Bug#471667: Bug#471667: Bug#471667: [D-I] Configuration of passwd during debootstrap fails when run in non-clean target
On Wed, Mar 19, 2008 at 04:53:26PM +0100, Frans Pop wrote: On Wednesday 19 March 2008, Justin Pryzby wrote: Do you know what version libuuid was initially installed? I suspect one of the problems was fixed in libuuid1 1.40.7-1 (See #466929). If you agree, the initial report (#471667) can be closed. The current testing version (the same version of all packages gets installed in both attempts): 1.40.6-1. But from #466929: ! Actually, adduser and addgroup automatically avoids the range 1-99, ! even if UID_MIN and/or GID_MIN is set to 1. From my grep output it looks like libuuid is getting 42/101. If the above statement is true then why is UID 42 assigned? #466929 may fix that, but doesn't that still leave a bug in adduser that 1-99 _should_ have been avoided automatically? If the range is reserved, it really should not be left to other packages to avoid it. See #459403 (I haven't checked snapshot.d.n, but I note that the changelog seems to be void of an entry detailing the new use of a dynamic user). Apparently libuuid1 used to pass UID_MIN=1 (likewsie for GID_MIN). It seems reasonable to support this (for local, site-specific administrative policy), and base-passwd won't blindly clobber the change. But package maintainers should have to pass UID_MIN=100. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471667: [Pkg-shadow-devel] Bug#471667: Bug#471667: Bug#471667: Bug#471667: [D-I] Configuration of passwd during debootstrap fails when run in non-clean target
On Wed, Mar 19, 2008 at 05:53:50PM +0100, Frans Pop wrote: On Wednesday 19 March 2008, Justin Pryzby wrote: Apparently libuuid1 used to pass UID_MIN=1 (likewsie for GID_MIN). OK, I missed that info. Is it alright to close this original bug then (having cloned to #471691 and opened unrelated #471705 while testing)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471718: aptitude fails during upgrade
Package: aptitude,dpkg,libc6 I think that this should never happen. Did something break due to the ldconfig updates? While doing an aptitude install aptitude/unstable, I ran a separate command: $ aptitude search session manag aptitude: error while loading shared libraries: libapt-pkg-libc6.7-6.so.4.6: cannot open shared object file: No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469085: live-helper: md5sum can't handle all filenames
On Wed, Mar 19, 2008 at 12:50:51AM +1100, Trent W. Buck wrote:
On Mon, Mar 17, 2008 at 03:52:23PM +0100, Julian Andres Klode wrote:
find . -type f \! -name 'isolinux/isolinux.bin' \! -name
'boot/grub/stage2_eltorito' -print0 | xargs -0 md5sum
../md5sum.txt
For recent (post-oldstable?) versions of findutils, you can use the
post-oldstable is correct, see 9.1.4 Going Back to Exec from the
info document. 4.2.12 is the earliest version supporting -exec {} +.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468075: this bug/#468075 - sudo: system freeze
#468075 - sudo: system freeze http://bugs.debian.org./468075 Oops, I'm awfully sorry, but I didn't actually run the command you gave. When I did, I was immediately able to reproduce the problem. Bdale, have you tried safe-upgrade under sudo under X? I suspect this is not a sudo bug, but an apt one. I know apt now ignores signals (including STOP) during dpkg runs. It's really unclear to me how it causes the system to become unresponsive, though. I note that ping from another host shows no dropped packets and no added delay, so it's not really frozen. Perhaps it's just the x11 interface? Why I don't know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471507: tumgreyspf: typo; /it's/s/'// debian/control
Package: tumgreyspf Version: 1.32-1 Severity: minor Tags: patch diff -u tumgreyspf-1.32/debian/control tumgreyspf-1.32/debian/control --- tumgreyspf-1.32/debian/control +++ tumgreyspf-1.32/debian/control @@ -22,3 +22,3 @@ . - Tumgreyspf uses the file-system as it's database, no additional database is + Tumgreyspf uses the file-system as its database, no additional database is required to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471506: Please support options set through /etc/default/cron parsed by init.d/cron
forcemerge 396928 471506 thanks On Tue, Mar 18, 2008 at 04:54:56PM +0100, Olivier Berger wrote: It would be great to have the possibility to have a /etc/default/cron file to be able to set some runtime options for the cron daemon, like LSBNAMES which is currently only modifiable in /etc/init.d/cron itself, and then won't persist over upgrades. That was implemented in 3.0pl1-101. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
