Bug#1061409: rasdaemon does not actually support PAGE_CE_ACTION etc.
Package: rasdaemon Version: 0.6.8-1.1 rasdaemon upstream offers the ability to offline memory when failures are detected (see <https://github.com/mchehab/rasdaemon/commit/9ae6b70eff>). Debian's rasdaemon includes the configuration files to do that at /etc/default/rasdaemon, with lines like: PAGE_CE_REFRESH_CYCLE="24h" PAGE_CE_THRESHOLD="50" PAGE_CE_ACTION="soft" This makes it look like the feature is enabled. However, those settings in /etc/default/rasdaemon are never actually used, and rasdaemon will never try to offline failing memory, because the Debian package is not compiled with the necessary "--enable-memory-ce-pfa" flag. Compiling rasdaemon with "--enable-memory-ce-pfa" would fix this. I tested compiling with that extra flag, and if you do so, these new lines are emitted in the logs when it is started, indicating the code is working: rasdaemon: Page offline choice on Corrected Errors is soft rasdaemon: Threshold of memory Corrected Errors is 50 / 24h I'd like to suggest that this option be enabled. If people don't want to use this feature, they can edit /etc/default/rasdaemon as documented to change it to PAGE_CE_ACTION="off". If it is decided not to enable this feature, then /etc/default/rasdaemon should be modified to remove these options so it doesn't look like it is enabled. -- Robert L Mathews
Bug#1035577: New upstream Dovecot stable version 2.3.20
Package: dovecot-core Version: 1:2.3.19.1+dfsg1-2.1 Severity: wishlist The current upstream version of dovecot is 2.3.20, which fixes several problems in 2.3.19 while adding almost no features. It's been remarkably problem-free on the Dovecot mailing list, compared to 2.3.19 that had numerous problem reports. If possible, it would be great to see 2.3.20 in Debian rather than 2.3.19. -- Robert L Mathews
Bug#762086: spamassassin: email reports have sometimes list of others email addresses included
I experienced this bug, but found it is fixed in SpamAssassin 3.4.3 and
later by:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7577
https://svn.apache.org/viewvc?view=revision=1844813
Using the "bullseye" or "buster-backports" version of SpamAssassin
solves the problem, so I'm guessing this bug report can be closed.
If it helps, attached is a Perl script that shows the original problem
for those having trouble duplicating it.
--
Robert L Mathews
#!/usr/bin/perl
=pod
Demonstrate Debian bug 762086. On my machine, this prints this
for the first message:
* 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
* provider (address[at]yahoo.com)
And this for the second message:
* 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
* provider (address[at]yahoo.com) (address[at]gmail.com)
=cut
use Mail::SpamAssassin;
my $spamassassin = Mail::SpamAssassin->new({
debug => 0,
});
my $message_lines = <\r
To: "To 1" \r
Subject: Test 1\r
\r
Test 1
EOF
my $sa_message = $spamassassin->parse($message_lines);
my $sa_status = $spamassassin->check($sa_message);
print $sa_status->get_tag('REPORT');
$sa_status->finish;
$sa_message->finish;
$message_lines = <\r
To: "To 2" \r
Subject: Test 2\r
\r
Test 2
EOF
$sa_message = $spamassassin->parse($message_lines);
$sa_status = $spamassassin->check($sa_message);
print $sa_status->get_tag('REPORT');
Bug#926881: Add support for setting tlb_dynamic_lb option in /etc/network/interfaces
Package: ifenslave Version: 2.9 Severity: normal Tags: patch Bonding driver 3.7.1 and later supports an option called "tlb_dynamic_lb" for "balance-tlb" mode, but there is no support for setting it in the /etc/network/interfaces file. This patch adds support for that. With this patch, adding "bond-tlb_dynamic_lb 0" to the interfaces file correctly shows "bond0: Setting dynamic-lb to off (0)" in logs, and correctly sets the value of "/sys/class/net/bond0/bonding/tlb_dynamic_lb". -- Robert L Mathews, Tiger Technologies --- debian/ifenslave.if-pre-up +++ debian/ifenslave.if-pre-up @@ -144,6 +144,9 @@ # arp_validate must be after mode (because mode must be active-backup). sysfs arp_validate "$IF_BOND_ARP_VALIDATE" + # tlb_dynamic_lb must be after mode (because mode must be active-tlb). + sysfs_change_down tlb_dynamic_lb "$IF_BOND_TLB_DYNAMIC_LB" + # lacp_rate must be set after mode (because mode must be 802.3ad). # Changing lacp_rate requires $BOND_MASTER to be down. sysfs_change_down lacp_rate "$IF_BOND_LACP_RATE" --- debian/README.Debian +++ debian/README.Debian @@ -206,6 +206,9 @@ * bond-xmit_hash_policy: Write into /sys/class/net//bonding/xmit_hash_policy +* bond-tlb_dynamic_lb: + Write into /sys/class/net//bonding/tlb_dynamic_lb + The following files in /sys/class/net/bond*/bonding are read-only, so no
Bug#743512: Also seen in grub-pc 1.99-27+deb7u3
I can confirm this report. I occasionally do what the original reporter does: replace an entire set of disks on a live server using mdadm --fail / mdadm --remove / [physical hot swap] / mdadm --add / grub-install, and the identical problem happened to me. In my case the disks are a three-disk RAID 1 array rather than RAID 10, and I partitioned them with "parted" rather than using "dd". I replaced the first two and grub-install worked with no trouble: # grub-install /dev/sdc # grub-install /dev/sdb But the third gave me: # grub-install /dev/sda /usr/sbin/grub-probe: error: no such disk. Auto-detection of a filesystem of /dev/md0 failed. # grub-install --recheck /dev/sda /usr/sbin/grub-probe: error: no such disk. Auto-detection of a filesystem of /dev/md0 failed. ... with the other symptoms identical. To my astonishment, running this: # mdadm --examine /dev/sda2 ... fixed it; "grub-install /dev/sda" then works without errors. Clearly "mdadm --examine" has a mysterious helpful side-effect, the nature of which is puzzling. However, I can't reproduce the original problem on demand; this has happened to me only once when doing this on about half a dozen physically identical (in terms of hardware) servers. -- Robert L Mathews
Bug#719948: Bug is still present in 3.2.57-3+deb7u1
As a followup, this bug still happens with the latest wheezy kernel: Linux [hostname] 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3+deb7u1 i686 GNU/Linux It's still trivially reproducible by following the to reproduce instructions previously mentioned. -- Robert L Mathews -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719948: Kernel BUG in cgroup freezer when repeatedly freezing/thawing a group
Package: src:linux
Version: 3.2.46-1
Severity: important
Dear Debian Linux Kernel Maintainers,
If I create a cgroup freezer container on an SMP machine and repeatedly
freeze/thaw it in a loop, the kernel freezes with a BUG.
To reproduce, create a cgroups freezer container with a single process
in it on an SMP machine with wheezy standard kernel 3.2.46-1:
mkdir /dev/cgroups-freezer
mount -t cgroup -o freezer freezer /dev/cgroups-freezer
mkdir /dev/cgroups-freezer/crashtest
cd /dev/cgroups-freezer/crashtest
sleep 3600
echo $! tasks
Then run this ugly perl one-liner from within the same crashtest
directory:
perl -e 'while (1) { open FILE, freezer.state or die; print FILE
FROZEN or die; close FILE or die; open FILE, freezer.state or die;
print FILE THAWED or die; close FILE or die; };'
On my test machines, the following BUG reproducibly happens in less than
a second, and the machine locks up:
[ 2703.254372] [ cut here ]
[ 2703.254530] kernel BUG at
/build/linux-dJLVDt/linux-3.2.46/kernel/cgroup_freezer.c:241!
[ 2703.254769] invalid opcode: [#1] SMP
[ 2703.254917] Modules linked in: netconsole nfnetlink_log nfnetlink
configfs nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop
snd_intel8x0 snd_ac97_codec snd_pcm snd_page_alloc snd_timer snd
soundcore ac97_bus ac battery processor parport_pc parport power_supply
thermal_sys button psmouse serio_raw pcspkr joydev evdev i2c_piix4
i2c_core vboxguest(O) ext4 crc16 jbd2 mbcache usbhid hid sg sr_mod
sd_mod cdrom crc_t10dif ata_generic ata_piix ohci_hcd ehci_hcd ahci
libahci usbcore e1000 libata scsi_mod usb_common [last unloaded: netconsole]
[ 2703.256018]
[ 2703.256018] Pid: 2835, comm: perl Tainted: G O
3.2.0-4-686-pae #1 Debian 3.2.46-1 innotek GmbH VirtualBox/VirtualBox
[ 2703.256018] EIP: 0060:[c106dc6f] EFLAGS: 00010002 CPU: 0
[ 2703.256018] EIP is at update_if_frozen.isra.1+0x47/0x73
[ 2703.256018] EAX: EBX: 0001 ECX: df2ef4c0 EDX: dd265ee4
[ 2703.256018] ESI: 0001 EDI: dd6a6350 EBP: ESP: dd265edc
[ 2703.256018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 2703.256018] Process perl (pid: 2835, ti=dd264000 task=df248ee0
task.ti=dd264000)
[ 2703.256018] Stack:
[ 2703.256018] dd265ee4 df2ef4c0 de2b1284 df2ef4c0 dd6a6340
dd265f28 0002
[ 2703.256018] c106dd5a c12c271a c1165b6c c106dd01 c13e892c dd265f28
0916b860 c106b49d
[ 2703.256018] 0006 df2ef4c0 1000 5a4f5246 4e45 520eb4b9
2fb866f6 520eb4bf
[ 2703.256018] Call Trace:
[ 2703.256018] [c106dd5a] ? freezer_write+0x59/0x13c
[ 2703.256018] [c12c271a] ? _cond_resched+0x5/0x18
[ 2703.256018] [c1165b6c] ? _copy_from_user+0x28/0x47
[ 2703.256018] [c106dd01] ? freezer_read+0x66/0x66
[ 2703.256018] [c106b49d] ? cgroup_file_write+0x18f/0x1e1
[ 2703.256018] [c10ccddf] ? rw_verify_area+0xc6/0xe7
[ 2703.256018] [c106b30e] ? cgroup_file_open+0x87/0x87
[ 2703.256018] [c10cd07f] ? vfs_write+0x83/0xd4
[ 2703.256018] [c10cd23f] ? sys_write+0x3d/0x61
[ 2703.256018] [c12c7f5f] ? sysenter_do_call+0x12/0x28
[ 2703.256018] Code: e8 2b f6 ff ff eb 0b e8 2d ff ff ff 46 3c 01 83 db
ff 8b 44 24 04 8d 54 24 08 e8 fe f6 ff ff 85 c0 75 e4 85 ed 75 06 85 db
74 17 0f 0b 4d 75 0c 39 f3 75 0e c7 07 02 00 00 00 eb 06 39 f3 74 02
[ 2703.256018] EIP: [c106dc6f] update_if_frozen.isra.1+0x47/0x73
SS:ESP 0068:dd265edc
[ 2703.256018] ---[ end trace 29c9f3fc0f436abe ]---
I have duplicated this on wheezy with this kernel:
Linux [hostname] 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686 GNU/Linux
And on squeeze with the same kernel backported, but on different amd64
(non-virtual) hardware:
Linux [hostname] 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.46-1~bpo60+1
x86_64 GNU/Linux
In my testing, the BUG only happens on SMP machines, and not on single
CPU machines.
Also, if you include a slight delay before the freeze, the problem
doesn't happen reproducibly, at least to me:
perl -e 'while (1) { select (undef, undef, undef, 0.01); open FILE,
freezer.state or die; print FILE FROZEN or die; close FILE or die;
open FILE, freezer.state or die; print FILE THAWED or die; close
FILE or die; };' # does not BUG due to the select() delay
Looking at line 241 of kernel/cgroup_freezer.c in version 3.2.46,
something is clearly wrong: the code believes the state of the group is
CGROUP_THAWED, and yet it contains a frozen task. The fact that it's
both timing- and SMP- dependent suggests a race condition of some kind.
-- System Information:
Debian Release: 7.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Robert L Mathews, Tiger Technologies
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617898: cron.daily fails: run-parts, logrotate and man_db
tags 617898 - moreinfo thanks I can duplicate this bug in squeeze. It happens if you remove logrotate from /etc/cron.daily, and instead put something like this in a new file at /etc/cron.d/logrotate: 20 04 * * * root /usr/sbin/logrotate /etc/logrotate.conf This causes errors like logrotate_script: 2: invoke-rc.d: not found. The reason this happens is that when scripts are run from /etc/cron.d, the default $PATH is: /usr/bin:/bin But when they're run from /etc/cron.daily, the default $PATH is: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin This, in turn, is because /etc/crontab contains this line before run-parts --report /etc/cron.daily: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin That changes the $PATH for cron.daily (and cron.hourly, cron.weekly, and cron.monthly)... but there is no such path override for scripts running from /etc/cron.d. The simple solution to the original person's problem is to add this to his /etc/cron.d/logrotate script: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin However, I was a little surprised to find that the default $PATH is different for scripts run from /etc/cron.d and /etc/cron.daily. Although it's unlikely, a misunderstanding about that could perhaps cause someone to make a security-related mistake. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587763: scary messages from JBD when manipulating quotas on ext4
Jonathan Nieder wrote: Thanks for the update, and no problem. What filesystem options does your test system use (as shown in /proc/mounts or by dumpe2fs -h bdev)? How do you set up quotas on it? Both the test system (that doesn't show errors) and the live system (that does) have identical mount options: ext4 rw,noatime,errors=remount-ro,acl,barrier=1,data=ordered,usrquota The initial quotas were enabled with quotaon -a, then by setting a 100GB / 1 million file quota for each user on the system other than root, using setquota. Don't know why I couldn't reproduce it. Perhaps something to do with the live server's (heavy and varied) disk write patterns. Looking closer, straightforward testing of that one patch would probably not reveal much anyway --- any subtle effects wouldn't necessarily be triggered often. Pointers that might help someone review the code: Hmmm. These changes to eliminate an erroneous -- but harmless -- warning gives me the heebie-jeebies! In your shoes, I'd mark this as won't fix and let it get fixed in the next real kernel version change -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587763: linux-image-2.6.32-5-amd64: scary messages from JBD when manipulating quotas on ext4
Jonathan Nieder wrote: Sounds like nothing good. There's a proposed patch described at http://bugs.debian.org/587763 but we can't apply it unless it is tested against a 2.6.32-based kernel and confirmed to fix the problem. So: - are you still interested in pursuing this? Unfortunately, I'm not able to reproduce the original problem on a test system for some reason (and I tried quite hard). It only happens on one of my production servers, but I can't experiment on that one. Sorry about that. :-( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587763: linux-image-2.6.32-5-amd64: scary messages from JBD when manipulating quotas on ext4
Moritz wrote: This might have been fixed in 2.6.32.17 (and thus in Debian revision 2.6.32-19 for Squeeze and 2.6.33 for sid). Can you confirm? This bug still exists in squeeze kernel 2.6.32-35squeeze2 (I'm using linux-image-2.6.32-5-amd64 2.6.32-35squeeze2). The patch wasn't committed to the upstream kernel until 2.6.35 on July 27, 2010: http://git.strongswan.org/?p=linux-dumm.git;a=commitdiff;h=62d2b5f2dcd3707b070efb16bbfdf6947c38c194 -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470748: libapache2-mod-fcgid: Data written to stderr goes to wrong log file
For what it's worth, this bug was fixed upstream here: http://svn.apache.org/viewvc?view=revisionrevision=816367 -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606282: ksplice-objmanip depends on wrong version of libbfd
Package: ksplice Version: 0.9.9-2 Severity: normal When using ksplice-create, it runs for a while and eventually errors out with: /usr/lib/ksplice-objmanip: error while loading shared libraries: libbfd-2.19.51.20090827.so: cannot open shared object file: No such file or directory Indeed, ksplice-objmanip uses libbfd-2.19.51.20090827.so, preventing me from running it manually, either: $ ldd /usr/lib/ksplice-objmanip linux-gate.so.1 = (0xb782b000) libbfd-2.19.51.20090827.so = not found libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb76df000) /lib/ld-linux.so.2 (0xb782c000) $ /usr/lib/ksplice-objmanip /usr/lib/ksplice-objmanip: error while loading shared libraries: libbfd-2.19.51.20090827.so: cannot open shared object file: No such file or directory Looking at binutils on squeeze, it has a different version of libbfd: $ dpkg -L binutils | egrep libbfd /usr/lib/libbfd-2.20.1-system.20100303.so So it appears that ksplice-objmanip is depending on an unavailable version of libbfd. The inability to run ksplice-objmanip makes ksplice not work at all, at least on my system (I don't know if this breaks it for everyone, so I'm marking this as a normal bug for now). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ksplice depends on: ii binutils 2.20.1-15 The GNU assembler, linker and bina ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii patch 2.6-2 Apply a diff file to an original ii perl 5.10.1-16 Larry Wall's Practical Extraction ii rsync 3.0.7-2fast remote file copy program (lik ksplice recommends no packages. ksplice suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499926: pure-ftpd SITE UTIME command sets incorrect time
Package: pure-ftpd Version: 1.0.21-8 Pure-ftpd supports the SITE UTIME command, which allows the client to set the modification time of a file to a particular timestamp, expressed in UTC. However, pure-ftpd passes the UTC timestamp directly to the operating system's utime() function, which is a bug, because utime() requires that the timestamp be in local time instead of UTC. The end result is that, for example, if your server is in time zone US/Pacific, the SITE UTIME command sets the file's timestamp 7 hours ahead of what it should be. See this page (which was written by someone else) for a confirmation: http://www.smartftp.com/support/kb/pureftpd-utime-bug-f2615.html To fix the bug, pure-ftpd needs to convert UTC to local time. The fix is trivial on Linux: Just replace mktime() with timegm() in doutime() of ftpd.c (I've tested this and it works). -- Robert L Mathews, Tiger Technologies -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475426: Incorrect Content-Length and Content-Type with Premature end of script headers error page
Package: apache2 Version: 2.2.3-4+etch4 If a CGI script dies without printing any headers to STDOUT, Apache returns a 500 Internal Server Error page and logs Premature end of script headers. However, the error page returned to the visitor has incorrect headers. It looks like this: HTTP/1.1 500 Internal Server Error Date: Thu, 10 Apr 2008 17:21:05 GMT Server: Apache/2.2.3 (Debian) mod_python/3.2.10 [etc.] Content-Length: 0 Connection: close Content-Type: text/plain; charset=UTF-8 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title500 Internal Server Error/title /headbody h1Internal Server Error/h1 pThe server encountered an internal error or [etc.] The Content-Length: 0 and Content-Type: text/plain headers are both wrong. These incorrect headers make some browsers (e.g., Konqueror) fail to display the HTML content of the error page. For comparison, Apache 2.0 sent the correct Content-Length and used the correct Content-Type: text/html header. This is easy to duplicate by creating a CGI script that contains nothing more than: #!/bin/sh exit 0; Thanks! -- Robert L Mathews -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392052: More info from someone with same problem
Christopher Martin wrote: Could you please upgrade your kdebase (and therefore kdeprint) to the version in Sid/unstable, 3.5.5? Then tell me if the problem persists (I guess you'll have to try printing with both Host=localhost and Host=127.0.0.1). Sorry to be a pain, but I want to be certain whether or not the problem still exists in 3.5.5, given that the Etch release isn't too far off. I was all set to do this, but then I thought why don't I try a normal dist-upgrade on testing first, just to make sure I'm current. That upgraded the following packages this morning: 2006-10-24 12:26:17 upgrade libsqlite0 2.8.16-1 2.8.17-1 2006-10-24 12:26:18 upgrade libslang2 2.0.6-3 2.0.6-4 2006-10-24 12:26:44 upgrade bittorrent 3.4.2-8.1 3.4.2-10 2006-10-24 12:26:48 upgrade devscripts 2.9.21 2.9.22 2006-10-24 12:26:49 upgrade discover1-data 1.2006.01.14 2.2006.10.12-1 2006-10-24 12:26:49 upgrade kdelibs-data 4:3.5.5a-1 4:3.5.5a.dfsg.1-1 2006-10-24 12:26:55 upgrade kdelibs4c2a 4:3.5.5a-1 4:3.5.5a.dfsg.1-1 2006-10-24 12:26:59 upgrade kdelibs 4:3.5.5a-1 4:3.5.5a.dfsg.1-1 2006-10-24 12:27:00 upgrade libggi2 1:2.2.1-4 1:2.2.1-5 2006-10-24 12:27:00 upgrade libgphoto2-2-dev 2.2.1-4 2.2.1-7 2006-10-24 12:27:02 upgrade libgphoto2-port0 2.2.1-4 2.2.1-7 2006-10-24 12:27:04 upgrade libgphoto2-2 2.2.1-4 2.2.1-7 2006-10-24 12:27:05 upgrade libxres1 2:1.0.0-3 2:1.0.1-2 2006-10-24 12:27:05 upgrade sqlite 2.8.16-1 2.8.17-1 2006-10-24 12:27:05 upgrade wwwconfig-common 0.0.46 0.0.47 2006-10-24 13:17:41 upgrade kappfinder 4:3.5.4-2+b1 4:3.5.5a-2 And... the problem has gone away on my machine, *without* upgrading kdebase or kdeprint. Hmmm. So, in an effort to be helpful, I started downgrading the above packages, and eventually found that downgrading kdelibs4c2a from 3.5.5a.dfsg.1-1 to 3.5.5a-1 caused the problem to start happening again. So: kdelibs4c2a 4:3.5.4-3 worked fine. kdelibs4c2a 4:3.5.5a-1 causes the problem. kdelibs4c2a 4:3.5.5a.dfsg.1-1 fixes the problem. This is definitely the case; again, downgrading back to kdelibs4c2a 4:3.5.5a-1 makes the problem start happening again. So, since 4:3.5.5a.dfsg.1-1 is now in testing, it's now solved as far as I'm concerned. Puzzling, though. -- Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392052: More info from someone with same problem
I also recently (2006-10-22) did a dist-upgrade and started experiencing the same problem described here: nothing in KDE would print any more, and I saw the same error when looking at Printers in the KDE Control Center: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: localhost: read failed (15). However, I am using the testing distribution, so my kdeprint is still version 3.5.4-2+b1, and kdebase is still 3.5.4-2. On other words, kdeprint has not changed for some time on my machine. What *did* change on my machine as a result of the dist-upgrade is most of the other KDE components (to 3.5.5). So I suspect the problem actually lies elsewhere (I don't know where). In response to the last poster, I looked at my ~/.kde/share/config/kdeprintrc file. It also has not changed in a long time, but I started playing with it to see if I could modify it to fix the problem. I found that this line in the [CUPS] section causes it to fail: Host=localhost But if I change that line to this, it works(!): Host=127.0.0.1 My machine has /etc/hosts set up correctly for localhost: $ host localhost localhost has address 127.0.0.1 So. This seems to indicate that some other KDE component in 3.5.5, other than kdeprint, has somehow broken the ability for hostnames to be resolved from kdeprintrc. Does that makes sense? Not to me. Hope it's useful to someone else If anyone cares, I can send along my /var/log/dpkg to show the exact 383 packages that were upgraded when the problem started. -- Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383258: FreeSans lowercase letter e is distorted
Package: ttf-freefont Version: 20060501cvs-8 When upgrading ttf-freefont from version 20051102-2 to 20060501cvs-8, I found that the top of the lowercase letter e in FreeSans (regular) is distorted (and was not before). When displayed at 12 point with anti-aliasing turned on, the top curve of the e is thinner than it used to be. When displayed at 11 points, the top of the e is taller than other lowercase letters. A screenshot of the differences is at: http://www.robandmollie.com/ttf-freefont/screenshot.png These screen shots were taken on the same machine, with the only difference being the version of ttf-freefont installed. In particular, look at the text lowercase letter on the 11 point 20060501cvs-8 version -- the distortion of the lowercase e is quite distracting, as the letter e now appears taller than other lowercase letters. When a large amount of 11 point text is viewed, the effect of the taller e is quite jarring. This problem occurs in all KDE and Gnome applications (for example, in both Konqueror and OpenOffice). Changing the details of the anti-aliasing settings on my computer has no effect on the problem. Using Debian testing (as of 2006-08-14), xorg 7.0.22, radeon driver, and DisplaySize 519.0 324.0 for a 1920x1200 screen. Let me know if there is any other info I can provide. Thanks! -- Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350954: DSA-960-1 security update breaks libmail-audit-perl when $ENV{HOME} is not set
Package: libmail-audit-perl
Version: 2.1-5sarge2
Tags: patch
The libmail-audit-perl 2.1-5sarge2 NMU update tries to fix the insecure
temporary file creation bug in Mail::Audit. However, the fix can cause
serious problems in cases where $ENV{HOME} is not set.
The problem is with this line at the top:
(undef,$logfile) = tempfile(mail_audit.log-X,TMPDIR=1);
The first problem with this is that TMPDIR=1 is not a valid option
for File::Temp's tempfile -- that option only works with tempdir(). So
that option is being ignored and the temporary file is being created in
the current working directory instead, which fails if the program
doesn't have write permission for that directory. This is easily
demonstrated as follows:
$ cd /
$ /usr/bin/env -i perl -e 'use Mail::Audit;'
Error in tempfile() using mail_audit.log-X: Parent directory (.)
is not writable at /usr/share/perl5/Mail/Audit.pm line 12
The correct usage to make tempfile() use a temporary directory would be
something like:
(undef,$logfile) =
tempfile(mail_audit.log-X, DIR = File::Spec-tmpdir);
The second problem with having the tempfile() line at the top of the
script when $ENV{HOME} is not present is that Mail::Audit now attempts
to create a temporary log file every time it is used, even if logging is
not enabled:
$ cd /tmp
$ /usr/bin/env -i perl -e 'use Mail::Audit;'
This creates an orphaned empty file in /tmp every time it's run.
The combination of these two problems is serious: in my case, a working
script that uses Mail::Audit and doesn't do any logging (which was
therefore not affected by the security bug in the first place) is now
trying, and failing, to create a temporary log file in the current
working directory every time the script is run, rendering the script
unusable.
A proposed solution is attached. This patch only calls tempfile() if
logging is actually used with a missing filename. And if logging is
used, it uses File::Spec-tmpdir to locate /tmp.
Although the code includes an extra use File::Spec for clarity, this
is not actually a new dependency, because the code already uses
File::Temp which depends on File::Spec anyway.
The patch also updates the documentation, which got out of sync when the
behavior changed from the security update.
Thanks!
--
Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/
--- Audit.pm.orig 2006-02-01 10:09:05.0 -0800
+++ Audit.pm 2006-02-01 10:34:31.0 -0800
@@ -5,12 +5,6 @@
my $logging;
my $loglevel=3;
my $logfile;
-if (exists $ENV{HOME} and defined $ENV{HOME} and -d $ENV{HOME}) {
- $logfile = $ENV{HOME}/.mail_audit.log
-}
-else {
- (undef,$logfile) = tempfile(mail_audit.log-X,TMPDIR=1);
-}
# --
# no user-modifiable parts below this line.
@@ -25,6 +19,7 @@
# @ISA will depend on whether the message is MIME; if it is, we'll be MIME::Entity. if not, we'll be Mail::Internet.
use Fcntl ':flock';
use File::Temp qw(tempfile);
+use File::Spec;
$ASSUME_MSGPREFIX = 0;
@@ -124,8 +119,9 @@
You may also specify C log = $logfile to write a debugging log; you
can set the verbosity of the log with the Cloglevel key, on a scale of
1 to 4. If you specify a log level without a log file, logging will be
-written to F/tmp/you-audit.log where Fyou is replaced by your user
-name.
+written to F.mail_audit.log in your home directory if the HOME
+environment variable is set, or to F/tmp/mail_audit.log-X (where
+FX contains random characters) if not.
Usually, the delivery methods Caccept, Cpipe, and
Cresend are final; Mail::Audit will terminate when they
@@ -161,9 +157,19 @@
open LOG, /dev/null;
if (exists $opts{loglevel}) { $logging = 1; $loglevel = $opts{loglevel}; }
if (exists $opts{log}) { $logging = 1;$logfile = $opts{log}; }
-if ($logging) { open LOG, $logfile or open LOG, /dev/null;
- # this doesn't seem to propagate to the calling script. hmm.
- }
+if ($logging) {
+unless (defined $logfile) {
+if (exists $ENV{HOME} and defined $ENV{HOME} and -d $ENV{HOME}) {
+$logfile = $ENV{HOME}/.mail_audit.log
+}
+else {
+(undef,$logfile) =
+tempfile(mail_audit.log-X, DIR = File::Spec-tmpdir);
+}
+}
+open LOG, $logfile or open LOG, /dev/null;
+# this doesn't seem to propagate to the calling script. hmm.
+}
_log(1, -- new run at . localtime);
my $draft = Mail::Internet-new( exists $opts{data}? $opts{data} : \*STDIN, Modify=0 );
Bug#340170: fakepop is missing carriage return in LIST response
Package: fakepop
Version: 7
Tags: patch
When fakepop receives a LIST command, it sends a reply that looks like
this (for example):
+OKCRLF
1SP1024LF
2SP2048LF
.CRLF
Note that the message sizes only have a line feed character after them,
rather than the carriage return/line feed combo required by the POP
standard. The carriage return is missing.
This problem causes (at least) the Mac OS X Mail POP client to hang
after issuing a LIST command.
The following trivial patch solves the problem:
--- fakepop.c.orig 2004-12-01 09:13:02.0 -0800
+++ fakepop.c 2005-11-21 06:30:04.0 -0800
@@ -49,7 +49,7 @@
j = msg_gettotalmsgs();
printf(+OK\r\n);
for (i = 1; i = j; i++) {
- printf(%d %d\n, i, msg_getsize(i));
+ printf(%d %d\r\n, i, msg_getsize(i));
}
printf(.\r\n);
}
Thanks!
--
Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
