Bug#910894: spamass-milter: Socket permissions not set correctly if startup takes more than one second

[Will Aoki]

Package: spamass-milter
Version: 0.4.0-1+b1
Severity: normal

If spamass-milter takes too long to create the socket after daemonizing
itself, the socket file will not exist when the startup script attempts
to change its permissions. MTAs relying on the permission change, such
as Postfix, will then be unable to communicate with the milter.

This is a very rare condition: I've encountered it only once in years of
operation. It may have involved I/O contention with other VMs.

The following appeared in the system log. Note that systemd thinks
spamass-milter startup failed, but spamass-milter was actually running.

Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: milter for spamassassin...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: Load kernel modules 
needed to e
nable cpufreq scaling...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: LDAP connection daemon...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: backup and restore 
program...
Oct 11 09:11:49 emptystares systemd[1]: Starting Permit User Sessions...
Oct 11 09:11:49 emptystares burp[578]: burp disabled; edit /etc/default/burp
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: start Winbind daemon...
Oct 11 09:11:49 emptystares systemd[1]: Started Nagios Remote Plugin Executor.
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: GNU configuration 
engine...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: System logger...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: ClamAV virus milter...
Oct 11 09:11:49 emptystares systemd[1]: Starting LSB: Mailman Master Queue 
Runner...
Oct 11 09:11:49 emptystares systemd[1]: Started LSB: backup and restore program.
Oct 11 09:11:49 emptystares systemd[1]: Started LSB: System logger.
Oct 11 09:11:50 emptystares systemd[1]: Started LSB: start Winbind daemon.
Oct 11 09:11:50 emptystares systemd[1]: Started Permit User Sessions.
Oct 11 09:11:50 emptystares systemd[1]: Started Getty on tty1.
Oct 11 09:11:50 emptystares systemd[1]: Reached target Login Prompts.
Oct 11 09:11:50 emptystares nrpe[599]: Starting up daemon
Oct 11 09:11:50 emptystares nrpe[599]: Server listening on 0.0.0.0 port 5666.
Oct 11 09:11:50 emptystares nrpe[599]: Server listening on :: port 5666.
Oct 11 09:11:50 emptystares nrpe[599]: Listening for connections on port 5666
Oct 11 09:11:50 emptystares nrpe[599]: Allowing connections from: 
127.0.0.1,155.98.200.158,10.98.200.172
Oct 11 09:11:58 emptystares systemd[1]: Time has been changed
Oct 11 09:11:58 emptystares ntpdate[426]: step time server 155.98.200.167 
offset 5.443399 sec
Oct 11 09:11:58 emptystares systemd[1]: certbot.timer: Adding 3h 50min 
12.457815s random time.
Oct 11 09:11:58 emptystares systemd[1]: apt-daily-upgrade.timer: Adding 13min 
36.810868s random time.
Oct 11 09:11:58 emptystares systemd[1]: apt-daily.timer: Adding 7h 26min 
3.999855s random time.
Oct 11 09:11:59 emptystares spamass-milter[575]: Starting Sendmail milter 
plugin for SpamAssassin: chmod: cannot access 
'/var/spool/postfix/spamass/spamass.sock': No such file or directory
Oct 11 09:11:59 emptystares systemd[1]: spamass-milter.service: Control process 
exited, code=exited status=1
Oct 11 09:11:59 emptystares systemd[1]: Failed to start LSB: milter for 
spamassassin.
Oct 11 09:11:59 emptystares systemd[1]: spamass-milter.service: Unit entered 
failed state.
Oct 11 09:11:59 emptystares systemd[1]: spamass-milter.service: Failed with 
result 'exit-code'.


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages spamass-milter depends on:
ii  adduser 3.115
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libmilter1.0.1  8.15.2-8
ii  libstdc++6  6.3.0-18+deb9u1
ii  spamc   3.4.1-6+deb9u1

Versions of packages spamass-milter recommends:
ii  postfix   3.1.8-0+deb9u1
ii  spamassassin  3.4.1-6+deb9u1

spamass-milter suggests no packages.

-- Configuration Files:
/etc/default/spamass-milter changed:
OPTIONS="-u spamass-milter -i 127.0.0.1"
OPTIONS="-u spamass-milter -i 127.0.0.1 -i redacted -r redacted"


-- no debconf information

Bug#869666: SYSERR(root): timeout writing message to

[Will Aoki]

On Fri, Mar 23, 2018 at 10:03:40AM -0600, Will Aoki wrote:
> We can confirm the same problem and that it was fixed by downgrading the
> sendmail packages to 8.14.4-8+deb8u2. The problem's a bit tricky in that
> the log message suggests that the destination server is at fault, where
> it's really Sendmail trying to look up names in To: that aren't in the
> envelope.

This appears to be a change in 8.15.1 regarding header rewriting, and
several other folks were caught by surprise:

https://forums.freebsd.org/threads/timeout-writing-message-to-local.55563/
https://groups.google.com/forum/#!topic/comp.mail.sendmail/_Io7xEYqF1s

To deal with this, it's necessary to turn off hostname canonicalization.
As I understand it,

Khost host -t

should result in the previous behavior, but the documentation recommends
turning off hostname canonialication with

FEATURE(`nocanonify')

This change does work, although I haven't yet tested operationally to
verify nothing of ours was relying on the old behavior.

Bug#869666: SYSERR(root): timeout writing message to

[Will Aoki]

We can confirm the same problem and that it was fixed by downgrading the
sendmail packages to 8.14.4-8+deb8u2. The problem's a bit tricky in that
the log message suggests that the destination server is at fault, where
it's really Sendmail trying to look up names in To: that aren't in the
envelope.

sendmail.mc with most comments removed:

define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.13.4-3 2005-06-03 16:49:22 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
dnl # Items controlled by /etc/mail/sendmail.conf - DO NOT TOUCH HERE
undefine(`confHOST_STATUS_DIRECTORY')dnl#DAEMON_HOSTSTATS=
dnl # Items controlled by /etc/mail/sendmail.conf - DO NOT TOUCH HERE
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Port=smtp')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MSP-v4, Port=submission')dnl
define(`SMTP_MAILER_MAXRCPTS', 10)
define(`confMAX_DAEMON_CHILDREN', 150)dnl
define(`confPRIVACY_FLAGS',dnl
`needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings')dnl
KDNSTXT dns -R TXT
C{BadIdentUsers}squid CacheFlowServer proxyuser
define(`confBIND_OPTS', `')dnl
define(`confCONNECTION_RATE_THROTTLE', `15')dnl
define(`confCONNECTION_RATE_WINDOW_SIZE',`10m')dnl
FEATURE(`access_db', , `skip')dnl
FEATURE(`greet_pause', `1000')dnl 1 seconds
FEATURE(`delay_checks', `friend', `n')dnl
define(`confBAD_RCPT_THROTTLE',`3')dnl
FEATURE(`conncontrol', `nodelay', `terminate')dnl
FEATURE(`ratecontrol', `nodelay', `terminate')dnl
define(`confMAX_MESSAGE_SIZE', 5000)
FEATURE(`blacklist_recipients')dnl
FEATURE(`mailertable')dnl
FEATURE(`virtusertable')dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
include(`/etc/mail/tls/starttls.m4')dnl
include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `p,y')dnl
FEATURE(`always_add_domain')dnl
MASQUERADE_AS(`my-domain.example.com')dnl
FEATURE(`allmasquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`dnsbl', `zen.spamhaus.org', `$>GetTXT $&{client_addr} $| 
zen.spamhaus.org $| Host $| " blocked: see " $| for details')
define(`confMILTER_MACROS_ENVRCPT', `{rcpt_mailer}, {rcpt_host}, {rcpt_addr}, 
b')
INPUT_MAIL_FILTER(`greylist',`S=local:/path/to/milter-greylist.sock', F=, 
T=C:6s;E:12s)dnl
INPUT_MAIL_FILTER(`clmilter',`S=local:/path/to/clmilter.sock, F=, 
T=C:70s;E:4m')dnl
INPUT_MAIL_FILTER(`spamassassin', `S=local:/path/to/spamass.sock, F=, 
T=C:2m;R:2m;E:8m')dnl
define(`confINPUT_MAIL_FILTERS', `greylist, clmilter, spamassassin')
MAILER_DEFINITIONS
MAILER(`local')dnl
MAILER(`smtp')dnl
LOCAL_RULESETS
SGetTXT
R$-.$-.$-.$- $| $+ $| $+ $| $+ $| $+$: $6 $1.$2.$3.$4 $7 $(DNSTXT 
$4.$3.$2.$1.$5 $) $8
SLocal_check_relay
R$* $: $(dequote "" $&_ $)
RIDENT:$*   $: $1
R$={BadIdentUsers}@$*   $#error $@ 5.7.1 $: "550 Access denied because 
your ident string is " $1
LOCAL_CONFIG
O 
CipherList=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:HIGH:ECDHE-RSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:!aNULL:!MD5
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 
+SSL_OP_CIPHER_SERVER_PREFERENCE

Bug#888837: spamassassin: sa-update failed, spamd does not start anymore

[Will Aoki]

forwarded 37 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7540
thanks

We hit this bug this morning with an sa-update. I'd hazard a guess that
it's the faulty ruleset described in upstream bug #7540 (fixed less than
two hours ago) and will clear up soon, when upstream publishes new
rules.

Bug#860743: [Pkg-samba-maint] Processed: #860743

[Will Aoki]

On Fri, Nov 10, 2017 at 11:12:18PM +0100, Mathieu Parent wrote:
> Is this reproducible on Debian stretch?

I don't know yet, as I haven't gotten that particular system upgraded
yet, but I plan to do so before the year is out.

Bug#860743: samba: smbd fails to reap a few zombie processes

[Will Aoki]

Package: samba
Version: 2:4.2.14+dfsg-0+deb8u5
Severity: normal

It's unclear whether this is a duplicate of bug #816725, so I filed a separate
report. #816725 shows smbd repeatedly starting, failing to delete a pidfile,
and presumably terminating, but this is not happening at my site. It may also
describe a much higher rate of zombie generation than I'm seeing.


After upgrading a busy server from wheezy with 2:4.1.17+dfsg-1~bpo70+1 to
jessie, I'm starting to see zombie smbd processes accumulate at a rate of one
to two a day.

The server was up for a few weeks before processes started accumulating:

> $ ps auxw | grep defunct | grep -v grep ; date; uptime
> root  3550  0.0  0.0  0 0 ?ZApr17   0:00 [smbd] 
> 
> root  3557  0.0  0.0  0 0 ?ZApr17   0:00 [smbd] 
> 
> root  4842  0.0  0.0  0 0 ?ZApr14   0:00 [smbd] 
> 
> root  5880  0.0  0.0  0 0 ?ZApr12   0:00 [smbd] 
> 
> root  7466  0.0  0.0  0 0 ?ZApr16   0:00 [smbd] 
> 
> root 15920  0.0  0.0  0 0 ?ZApr14   0:00 [smbd] 
> 
> root 16200  0.0  0.0  0 0 ?ZApr14   0:08 [smbd] 
> 
> root 17238  0.0  0.0  0 0 ?ZApr18   0:01 [smbd] 
> 
> root 18990  0.0  0.0  0 0 ?ZApr17   0:00 [smbd] 
> 
> root 29334  0.0  0.0  0 0 ?ZApr17   0:02 [smbd] 
> 
> Wed Apr 19 09:00:09 MDT 2017
>  09:00:09 up 21 days, 14:12,  2 users,  load average: 1.24, 1.07, 0.85

The server in question is, for awkward historical reasons, an LDAP-backed
NT4-style PDC and a fileserver. Zombie process accumulation has not been
observed on other fileservers (NT4 or AD-joined) or on NT4-style BDCs.

The server is a VM running on hardware with ECC RAM, so random memory
corruption is unlikely. None of the physical servers it could be running on
have reported any ECC errors.

The server's smb.conf follows. This installation dates back to 2001, so there
may be some cruft present: for example, it still uses 'idamp backend', which is
deprecated but not removed, and it explicitly sets 'mangling method'.

#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which 
# are not shown in this example
#
# Any line which starts with a ; (semi-colon) or a # (hash) 
# is a comment and is ignored. In this example we will use a #
# for commentary and a ; for parts of the config file that you
# may wish to enable
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not many any basic syntactic 
# errors. 
#

#=== Global Settings ===

[global]

# Change this for the workgroup/NT-domain name your Samba server will part of
   workgroup = [redacted]

# server string is the equivalent of the NT Description field
   server string = [redacted]
   netbios name = [redacted]

# If you want to automatically load your printer list rather
# than setting them up individually then you'll need this
   load printers = yes

;printcap name = cups
;printcap name = /etc/printcap.cups

   printing = cups
   printcap = cups

   invalid users = root

# Put a capping on the size of the log files (in Kb).
   #max log size = 1000
   # no limit
   max log size = 0

# If you want Samba to log though syslog only then set the following
# parameter to 'yes'. Please note that logging through syslog in
# Samba is still experimental.
;   syslog only = no

   syslog = 1 passdb:2 auth:2
   log level = 1 passdb:1 auth:3

   hosts allow = [redacted]

   interfaces = [redacted]
   bind interfaces only = yes

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# security_level.txt for details.
   security = user

# You may wish to use password encryption. Please read ENCRYPTION.txt,
# Win95.txt and WinNT.txt in the Samba documentation. Do not enable this
# option unless you have read those documents
   encrypt passwords = yes

# Most people will find that this option gives better performance.
# See speed.txt and the manual pages for details
# You may want to add the following on a Linux system:
# SO_RCVBUF=8192 SO_SNDBUF=8192
   socket options = TCP_NODELAY


domain logons = yes

logon drive = [redacted]

logon path = [redacted]
logon home = [redacted]

# lie to Samba
#dfree command = /usr/local/sbin/samba-dfree

# Debian panic-action
# don't know what version this showed up, but let's see how much it spams
# me with name_to_8_3 crashes:
panic action = /usr/share/samba/panic-action %d

enhanced browsing = yes

# an experiment
#  worked with 3.4.8, does not work with 3.5.5
#  See eg: 

Bug#854648: systemd-sysv: Immediate shutdown can happen despite future time argument if unable to talk to shutdownd

[Will Aoki]

Package: systemd
Version: 215-17+deb8u6
Severity: minor

After upgrading a system from wheezy to jessie, I attempted to schedule a
reboot at 8:27 AM by executing '/sbin/shutdown -r 08:27 completing upgrade'.
It produced this (partial) error, which did not stay on the screen long enough
to copy:

   Failed to talk to shutdownd, proceeding with immediate shutdown:

and rebooted immediately.

Rebooting immediately when the user has specified a time in the future is
unexpected and undocumented behavior.

I have not tested this patch, but the gist of the fix is:

--- src/systemctl/systemctl.c   2017-02-08 15:45:39.0 -0700
+++ src/systemctl/systemctl.c.orig  2017-02-08 16:04:21.503618530 -0700
@@ -6897,7 +6897,8 @@
m);
 
 if (r < 0)
-log_warning("Failed to talk to shutdownd, proceeding 
with immediate shutdown: %s", strerror(-r));
+log_warning("Failed to talk to shutdownd, not 
scheduling shutdown: %s", strerror(-r));
+   return -1;
 else {
 char date[FORMAT_TIMESTAMP_MAX];
 


It could instead be fixed by updating the manpage, but not rebooting
immediately follows the principle of least surprise.

Bug#849481: amanda-common: Amanda::Changer::robot::Interface::MTX calls confess but does not use Carp

[Will Aoki]

Package: amanda-common
Version: 1:3.3.8-1
Severity: normal
Tags: patch

I've been getting occasional failures that leave the following in the report:

  FAILURE DUMP SUMMARY:
taper: FATAL Undefined subroutine 
&Amanda::Changer::robot::Interface::MTX::confess called at 
/usr/lib/amanda/perl/Amanda/Changer/robot.pm line 2563.
backup1.nhmu.utah.edu pool/burp lev 0  FAILED [out of holding space in 
degraded mode]
backup1.nhmu.utah.edu pool/burp lev 0  FAILED [data write: Broken pipe]

The cause of the failure seems to be a fork failing, but a bug in AMANDA's
error-handling code is masking the first problem. This module calls confess(),
but it doesn't use Carp first or otherwise declare &confess.

--- /tmp/robot.pm   2016-12-27 09:41:57.285488949 -0700
+++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm2016-12-27 
09:41:34.045222046 -0700
@@ -2359,6 +2359,7 @@
 use Amanda::Debug qw( debug warning );
 use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps step 
);
 use Amanda::Device qw( :constants );
+use Carp;
 
 sub new {
 my $class = shift;

Bug#813620: Bug #813620 probably upstream bug #757

[Will Aoki]

forwarded 813620 https://bugzilla.sudo.ws/show_bug.cgi?id=757
tags 813620 patch
thanks

I initially ran into this problem on an Ubuntu system, but it seems to
me that bug #813620 is upsteam bug #757. Todd Miller committed a patch
less than an hour after I reported the bug:

https://www.sudo.ws/repos/sudo/rev/605c03afc80f

Bug#833170: linux-image-3.16.0-4-amd64: Reproducable XFS filesystem corruption, possibly connected with ACLs

[Will Aoki]

Package: src:linux
Version: 3.16.7-ckt25-2+deb8u3
Severity: important

I hit a nasty filesystem corruption bug while restoring some backups. I'm able
to reliably reproduce this on every system where I tried to restore to XFS and
on a brand-new VM created for testing (which I can share as an OVF, although
it's pretty big).

Everything's running on hardware with ECC RAM, so memory errors are unlikely.
I've reproduced it on VMs spread across three different storage arrays from two
different vendors. Everything has at least two virtual CPUs.

All systems tested use XFS on LVM.

In my test VM, the only packages not from Debian stable are custom stow and tar
packages to fix bugs in the versions in the stable release and a backport of
burp because the verson in Debian was very old. These are all userland tools
and none should be able to cause filessytem corruption.

I'm using xfsprogs from Debian jessie. On one affected system, I tried version
4.3.0+nmu1 and saw no difference in what xfs_repair found.


At this point, my test case uses the burp backup software to create the I/O
activity which triggers this bug. I have not been able to make tar trigger this
problem.


Steps to reproduce:

1: Create new XFS filesystem & mount it on /srv/src

2: Create some directories in /srv/src & set ACLs (including default ACLs) on
   them

3: Generate deep tree of files in each of the directories from step #2. For
   testing, I used a script which created random files & subdirectories. Total
   bulk was about 2.5 gigabytes.

4: Take backup of /srv/src with burp:

   # burp -a b

5: Unmount /srv/src

6: Create new XFS filesystem & mount it on /srv/src

7: Run restore to /srv/src:

   # burp -a r -r ^/srv/src

   Do not suspend the restore process: the bug appears to require sustained I/O
   to trigger. In trials where I suspended it multiple times during a restore,
   corruption did not surface.


Expected outcome (observed when restoring to e.g. ext4):

1: Can create files (permissions notwithstanding) in every directory under
   /srv/src

2: Default ACL on every directory is the same as the backup utility wrote

3: If filesystem is unmounted and xfs_repair is run on it, no errors will be
   found


Actual outcome (observed when restoring to XFS):

1: Some files & directories cannot be written. The easiest way to find problem
   directories them is:

   # find . -type d -exec touch {}/asdf \;
   touch: cannot touch ‘./a/-BIz/asdf’: Cannot allocate memory
   touch: cannot touch ‘./a/-BIz/Zp.NyvX0guz./asdf’: Cannot allocate memory
   touch: cannot touch ‘./a/-BIz/Zp.NyvX0guz./TWDU/asdf’: Cannot allocate 
memory
   [etc]

   Giving VMs more RAM has no effect on this. Clearing the ACL on the directory
   has no effect.

   Affected directories are not always the same between different runs.

2: The default ACL has not been restored to problem directories. Directories
   which I can write to have had the default ACL restored.

3: If filesystem is unmounted and xfs_repair is run on it, many errors are
   reported:

   # xfs_repair -n /dev/mapper/xfsbugtest--vg-dst 2>&1 | head -90
   Phase 1 - find and verify superblock...
   Phase 2 - using internal log
   - scan filesystem freespace and inode maps...
   - found root inode chunk
   Phase 3 - for each AG...
   - scan (but don't clear) agi unlinked lists...
   - process known inodes and perform inode discovery...
   - agno = 0
   Too many ACL entries, count -2010719080
   entry contains illegal value in attribute named SGI_ACL_FILE or 
SGI_ACL_DEFAULT
   bad security value for attribute entry 1 in attr block 0, inode 133
   problem with attribute contents in inode 133
   would clear attr fork
   bad nblocks 2 for inode 133, would reset to 1
   bad anextents 1 for inode 133, would reset to 0
   Too many ACL entries, count -2010719080
   entry contains illegal value in attribute named SGI_ACL_FILE or 
SGI_ACL_DEFAULT
   bad security value for attribute entry 1 in attr block 0, inode 134
   problem with attribute contents in inode 134
   would clear attr fork
   bad nblocks 2 for inode 134, would reset to 1
   bad anextents 1 for inode 134, would reset to 0
   [...]
   bad nblocks 1 for inode 52741928, would reset to 0
   bad anextents 1 for inode 52741928, would reset to 0
   - process newly discovered inodes...
   Phase 4 - check for duplicate blocks...
   - setting up duplicate extent list...
   - check for inodes claiming duplicate blocks...
   - agno = 0
   - agno = 1
   - agno = 2
   - agno = 3
   No modify flag set, skipping phase 5
   Phase 6 - check inode connectivity...
   - traversing filesystem ...
   - traversal finished ...
   - moving disconnected inodes to lost+found ...
   Phase 7 - verify link counts...
   No modify flag set, skipping filesystem flush and exiting.

   On my production VMs, running xfs_repair without '-n' typically left many

Bug#824196: [Pkg-clamav-devel] Bug#824196: Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, Jul 12, 2016 at 09:11:54PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-07-12 00:07:34 [+0200], Sebastian Andrzej Siewior wrote:
> > I took 2015.NHMU_.AccessionForm_distributed-2.pdf and the
> > local-js-sigs.ndb from the archive and could reproduce the bug on 0.99.2
> > without any further changes. I applied the patch from upstream's
> > bugzilla #11549 and I could not reproduce the issue anymore.
> 
> Will: do you want/need prebuild .deb packages for Squeeze?

We're good, thanks: we have no Squeeze sysetms left. I have
infrastructure to build local packages for Wheezy & Jessie.

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 24, 2016 at 10:51:24PM +0200, Sebastian Andrzej Siewior wrote:
> That is something. Would you mind to send me your clamd.conf +
> /var/lib/clamav without the daily.cvd + main.cvd? I just tried it with
> those pdf and nothing here leaks fds.

Posted at 
ftp://ftp.umnh.utah.edu/general-temporary/clamav/var_lib_clamav.tar.bz2

After additional testing, I think the problem lies with
local-js-sigs.ndb. WIth that file removed, clamav still dumps debug
warnings (when configured per the clamd.conf in the tarball) but does
not seem to leak file descriptors.

Bug#825431: vlc: SIGFPE (divide by zero) while transcoding in line 551 of modules/stream_out/transcode/video.c (transcode_video_encoder_init)

[Will Aoki]

On Thu, Jun 09, 2016 at 03:27:32PM -0600, Will Aoki wrote:
> On Wed, Jun 08, 2016 at 10:14:03AM +0200, Sebastian Ramacher wrote:
> > The mail to wa...@umnh.utah.edu bounced. So let's assume it's fixed.
> 
> Fix confirmed; not replying to the bug to avoid reopening it.

I spoke too soon. The bug is not fixed in vlc 2.2.4-1~deb8u1.

Bug#825431: vlc: SIGFPE (divide by zero) while transcoding in line 551 of modules/stream_out/transcode/video.c (transcode_video_encoder_init)

[Will Aoki]

Package: vlc
Version: 2.2.1-1~deb8u1
Severity: normal
Tags: patch

We run VLC as a daemon to transcode an MJPEG stream from a StarDot camera and
pipe it into another program. After upgrading from wheezy to jessie, VLC began
to crash with SIGFPE.

Although the root cause may be elsewhere in VLC, the patch at
https://patches.videolan.org/patch/10246/ resolves the problem.

This report in the OpenSUSE Bugzilla is probably the same problem:
https://bugzilla.opensuse.org/show_bug.cgi?id=978282


Details on my installation:

VLC is invoked as follows:

/usr/bin/vlc -I dummy --repeat --sout-keep --http-reconnect 
http://ip-redacted/nph-mjpeg.cgi --sout 
'#transcode{venc=x264{keyint=60,profile=baseline,level=3.0,nocabac},vcodec=x264,vb=500,scale=1,acodec=none,threads=6}:rtp{dst=127.0.0.1,port=1,mux=ts}'
 --syslog

Data from core dump:

$ gdb /usr/bin/vlc ~/core
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/vlc...Reading symbols from 
/usr/lib/debug/.build-id/59/71b866af7e3d3a228ce9bed06f5dbcd2f65181.debug...done.
done.
[New LWP 15816]
[New LWP 15814]
[New LWP 15809]
[New LWP 15824]
[New LWP 15806]
[New LWP 15812]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vlc -I dummy --repeat --sout-keep 
--http-reconnect http://172.18.51.40'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x7fd3467855b0 in transcode_video_encoder_init (p_stream=0x7fd338008738,
id=0x7fd3340008c0) at transcode/video.c:551
551 id->i_input_frame_interval  = 
id->p_decoder->fmt_out.video.i_frame_rate_base * CLOCK_FREQ / 
id->p_decoder->fmt_out.video.i_frame_rate;
(gdb) print id->p_decoder->fmt_out.video.i_frame_rate
$1 = 0
(gdb) print id->p_decoder->fmt_out.video.i_frame_rate_base
$2 = 0
(gdb) bt
#0  0x7fd3467855b0 in transcode_video_encoder_init (p_stream=0x7fd338008738,
id=0x7fd3340008c0) at transcode/video.c:551
#1  0x7fd346785ebf in transcode_video_process (p_stream=0x7fd338008738,
id=0x7fd3340008c0, in=0x7fd338c353d0, out=0x7fd346787db3,
out@entry=0x7fd3471d6e10) at transcode/video.c:884
#2  0x7fd34678143b in Send (p_stream=0x7fd338008738, id=0x7fd3340008c0,
p_buffer=) at transcode/transcode.c:661
#3  0x7fd35933d118 in sout_InputSendBuffer (p_input=0x7fd3340009a0,
p_buffer=p_buffer@entry=0x7fd338c353d0) at stream_output/stream_output.c:233
#4  0x7fd3592ca994 in DecoderPlaySout (p_sout_block=0x7fd338c353d0,
p_dec=0x7fd338c20018) at input/decoder.c:1501
#5  DecoderProcessSout (p_block=0x0, p_dec=) at 
input/decoder.c:1556
#6  DecoderProcess (p_block=, p_dec=)
at input/decoder.c:1787
#7  DecoderThread (p_data=0x7fd338c20018) at input/decoder.c:909
#8  0x7fd359b440a4 in start_thread (arg=0x7fd3471d7700) at 
pthread_create.c:309
#9  0x7fd35967587d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-43
ii  libavcodec566:11.6-1~deb8u1
ii  libavutil54 6:11.6-1~deb8u1
ii  libc6   2.19-18+deb8u4
ii  libcaca00.99.beta19-2
ii  libegl1-mesa [libegl1-x11]  10.3.2-1+deb8u1
ii  libfreerdp-cache1.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-codec1.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-crypto1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-locale1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-rail1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-utils1.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreetype62.5.2-3+deb8u1
ii  libfribidi0 0.19

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 24, 2016 at 12:01:37AM +0200, Sebastian Andrzej Siewior wrote:
> After "clamdscan /usr/share/clamav-testfiles/*" (from the
> clamav-testfiles package) it remains at nine. I bet that you have one
> test file which keeps the number of descriptors growing. Could you
> please figure out which one it is?

After a fresh start, it's steady at 9 until I scan the file at
,
after which it increases. Scanning other PDFs from 

also makes clamd leak file descriptors, as do all the PDFs from outside
sources that I've tried.

The second time I scan a file, the number of file descriptors does not
increase.

This explains why it was crashing even before we included one of these
PDFs in the test corpus: clamav-milter presumably gets enough PDFs that
trigger this in routine e-mail traffic that clamd falls over after a few
days.

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 17, 2016 at 10:18:48AM -0600, Will Aoki wrote:
> It doesn't dump core. Memory grows very slightly over time. The very end
> of the debug log and a journal of memory use are attached; error code
> will be available once I run it again without nohup.

It outputs:

[]
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
LibClamAV Error: cli_tgzload: Can't duplicate descriptor 468
LibClamAV Error: Can't load /var/lib/clamav/bytecode.cld: Can't duplicate file 
descriptor
LibClamAV Error: cli_loaddbdir(): error loading database 
/var/lib/clamav/bytecode.cld
ERROR: reload db failed: Can't duplicate file descriptor
Terminating because of a fatal error.
ERROR: Can't unlink the pid file /var//run/clamd.pid

and returns 1.

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 17, 2016 at 10:18:48AM -0600, Will Aoki wrote:
> error code will be available once I run it again without nohup.

It's still running, but some console output from this test run is
interesting, showing it running out of file descriptors:

ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Fri, May 13, 2016 at 11:00:30PM +0200, Sebastian Andrzej Siewior wrote:
> interresting. The source says that there should be more.
> Your bug report says you run i386. Is this the case for the server or
> just the machine you made the report?

It's the server: it was originally a physical computer installed the
summer of 2005. I could probably crossgrade it to amd64 during a
maintenance window on the 24th; it's already on my list of VMs to
crossgrade.

> Could you enable debug loglevel? Maybe it logs something usefull. 
> Also would it be possible to enable core dumps and see if it dumps
> something? Could start clamd from commandline in foreground so you can
> log its exit code? Ah. And could please check with top or something if
> the memory of clamd grows overtime? In case it has a memory leak
> somewhere.

It doesn't dump core. Memory grows very slightly over time. The very end
of the debug log and a journal of memory use are attached; error code
will be available once I run it again without nohup.

> If you manage to give me something to reproduce it locally (like a VM
> image) I might try it when I have some time.

I'll see if I can put a test case together.

Mon May 16 11:05:34 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  1.6 49.6 581456 513312 pts/2   Sl   10:47   0:18 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 11:20:34 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.9 49.6 581508 513392 pts/2   Sl   10:47   0:19 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 11:35:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.7 49.6 581508 513392 pts/2   Sl   10:47   0:20 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 11:50:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  1.0 49.6 581548 513232 pts/2   Sl   10:47   0:39 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 12:05:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.8 49.3 581548 510788 pts/2   Sl   10:47   0:40 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 12:20:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.7 49.3 581548 510788 pts/2   Sl   10:47   0:41 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 12:35:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.6 49.3 581388 510712 pts/2   Sl   10:47   0:42 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 12:50:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.5 49.3 581548 510796 pts/2   Sl   10:47   0:43 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 13:05:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.5 49.4 581548 510948 pts/2   Sl   10:47   0:43 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 13:20:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.4 49.4 581548 510948 pts/2   Sl   10:47   0:44 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 13:35:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.4 49.6 584020 513488 pts/2   Sl   10:47   0:45 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 13:50:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.4 49.6 584020 513492 pts/2   Sl   10:47   0:46 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 14:05:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.3 49.6 584020 513492 pts/2   Sl   10:47   0:46 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 14:20:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.3 50.5 592948 522372 pts/2   Sl   10:47   0:48 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 14:35:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.3 50.5 592948 522372 pts/2   Sl   10:47   0:48 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 14:50:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.3 50.5 592948 522396 pts/2   Sl   10:47   0:49 clamd -c 
/etc/clamav/clamd.conf --pid=/var//run/clamd.pid

Mon May 16 15:05:35 MDT 2016
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28740  0.3 50.5 592948 522396 pts/2   Sl   10:47   0:49 clamd -c 
/et

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Fri, May 13, 2016 at 09:35:07PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-13 09:43:24 [-0600], Will Aoki wrote:
> > Before crashing, the daemon spews the message
> > 
> >accept() failed:
> This is it? Nothing more? There should be an error message included
> after the colon.

That's it. A space is logged after the colon, but nothing else.

May 13 08:56:05 skunk clamd[12310]: accept() failed:
May 13 08:56:05 skunk clamd: Last message 'accept() failed: ' repeated 198 
times, suppressed by syslog-ng on [the loghost]
May 13 08:56:11 skunk clamd[12310]: accept() failed:
May 13 08:56:11 skunk clamd: Last message 'accept() failed: ' repeated 199 
times, suppressed by syslog-ng on [the loghost]

I've noticed that /tmp is filling up with directories named e.g.
clamav-fe97224f9fa888d6e2d47ddfee0ca573.tmp

> You mean you gave a "normal" file and it was reported as a virus?

It's a test we run to make sure that the our exclusions of two PUA
signatures work. We want most PUA signatures, but we don't want to use
these two.

We added the exclusion and the test earlier this week, after the crashes
had started.

Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

Package: clamav-daemon
Version: 0.99+dfsg-0+deb7u2
Severity: important

After upgrading from 0.98.7+dfsg-0+deb7u1 to 0.99+dfsg-0+deb7u2 two
months ago, clamd on one of our servers has crashed approximately daily.
It's rarely stayed running for more than 24 hours. 

Before crashing, the daemon spews the message

   accept() failed:

This is often, but not always, preceeded by:

   Reading databases from /var/lib/clamav

The kernel is not reporting segfaults or OOM.

I had initially suspected this might be related to the custom
configuration file we were using, but the crashes persisted after I
allowed the package to regenerate it.

On this particular server, clamd is used by clamav-milter. A Nagios
check script also runs clamdscan about every five minutes against a CAB,
an EXE, a bzip2'd EXE and a zip file that alll contain
"Clamav.Test.File-6". As of a Monday (long after the problem starte),
the script has started scanning another file we've had false-positive
problems with.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile disabled
StatsHostID = "auto"
StatsEnabled disabled
StatsPEDisabled = "yes"
StatsTimeout = "10"
LogFileUnlock disabled
LogFileMaxSize = "1048576"
LogTime disabled
LogClean disabled
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose = "yes"
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamd.pid"
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
AllowSupplementaryGroups disabled
Bytecode = "yes"
BytecodeSecurity = "Paranoid"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA = "yes"
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = "yes"
ScanPE = "yes"
ScanELF = "yes"
DetectBrokenExecutables disabled
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
PartitionIntersection disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
OLE2BlockMacros disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanArchive = "yes"
ArchiveBlockEncrypted disabled
ForceToDisk disabled
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
ScanOnAccess disabled
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeUID disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled

Config file: freshclam.conf
---
StatsHostID disabled
StatsEnabled disabled
StatsTimeout disabled
LogFileMaxSize = "4294967295"
LogTime disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "48"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = "30"
ReceiveTimeout = "30"
SubmitDetectionStats disabled
DetectionStatsCountry disabled
DetectionStatsHostID disabled
SafeBrowsing =

Bug#774715: burp: Please update burp package to 1.4.40

[Will Aoki]

retitle 774715 Please update burp package to 1.4.40
tags 774715 patch
thanks

All that's really needed for 1.4.40 is a 'quilt refresh': The attached
patches (against 1.4.40 from the upstream's git) are what I used to make
basic burp-1.4.40 packages for local use. I've been compiling it on
wheezy and installing on wheezy & jessie.

I've also been doing some work (not included here, as it's not ready for
public consumption, but deployed to my servers) to make the burp server
run as user 'backup' out of the box on Debian & to not leave
world-readable files with backups & passwords lying around.

>From 3115f407aecddd15c1b0f0f3a3f1d78bc53417e8 Mon Sep 17 00:00:00 2001
From: Will Aoki 
Date: Wed, 30 Mar 2016 15:29:01 -0600
Subject: [PATCH 1/2] initial update to 1.4.40

---
 debian/changelog   |7 +++
 debian/patches/disable_tests.patch |   12 +++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index ac12f61..0289328 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+burp (1.4.40-1umnh0) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release
+
+ -- Will Aoki   Wed, 30 Mar 2016 15:07:15 -0600
+
 burp (1.3.48-1) unstable; urgency=low
 
   * New upstream release.
diff --git a/debian/patches/disable_tests.patch b/debian/patches/disable_tests.patch
index 37fd495..40e5226 100644
--- a/debian/patches/disable_tests.patch
+++ b/debian/patches/disable_tests.patch
@@ -9,11 +9,13 @@ Bug: 
 Reviewed-By: Bastiaan Franciscus van den Dikkenberg 
 Last-Update: <2014-01-09>
 
 burp-1.3.46.orig/test/test_self
-+++ burp-1.3.46/test/test_self
-@@ -12,6 +12,16 @@ path="$PWD"
- build="$path/build"
- target="$path/target"
+Index: burp/test/test_self
+===
+--- burp.orig/test/test_self	2016-03-30 15:05:57.744780009 -0600
 burp/test/test_self	2016-03-30 15:10:30.467193993 -0600
+@@ -22,6 +22,16 @@
+ 	exit 0
+ fi
  
 +if ! [ -c /dev/random -o -c /dev/urandom ] &&
 +   ! [ -e /var/run/egd-pool -o -e /dev/egd-pool -o -e /etc/egd-pool -o -e /etc/entropy ]
-- 
1.7.10.4

>From 13d2d1df2dcd4881db05368d19906c28164cd64b Mon Sep 17 00:00:00 2001
From: Will Aoki 
Date: Wed, 30 Mar 2016 15:29:35 -0600
Subject: [PATCH 2/2] ignore .pc used by quilt

---
 .gitignore |1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index aa57078..61b43b8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ config.status
 libtool
 src/bedup
 src/burp
+.pc
-- 
1.7.10.4

Bug#803967: zbar-tools: Regression: 0.10+doc-10 cannot read barcodes from images that 0.10+doc-8 can

[Will Aoki]

Package: zbar-tools
Version: 0.10+doc-10
Severity: normal

I have a number of images which zbarimg 0.10+doc-8 can read barcodes
from but which 0.10+doc-10 cannot. I've placed an example at
ftp://ftp.umnh.utah.edu/general-temporary/zbar/2015_08_26_JMH-095.jpg

The transcript below demonstrates the problem:

$ sudo apt-get install zbar-tools=0.10+doc-8 libzbar0=0.10+doc-8
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libmagickwand-6.q16-2
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
  libmagickcore5 libmagickwand5 libtiff4 libxt6
Suggested packages:
  libmagickcore5-extra
The following NEW packages will be installed:
  libmagickcore5 libmagickwand5 libtiff4 libxt6
The following packages will be DOWNGRADED:
  libzbar0 zbar-tools
0 upgraded, 4 newly installed, 2 downgraded, 0 to remove and 2 not upgraded.
Need to get 3,077 kB of archives.
After this operation, 8,506 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://my-approx-site:/debian/ wheezy/main libtiff4 amd64 3.9.6-11 
[202 kB]
Get:2 http://my-approx-site:/debian/ jessie/main libxt6 amd64 1:1.1.4-1+b1 
[186 kB]
Get:3 http://my-approx-site:/debian/ wheezy/main libmagickcore5 amd64 
8:6.7.7.10-5+deb7u3 [2,083 kB]
Get:4 http://my-approx-site:/debian/ wheezy/main libmagickwand5 amd64 
8:6.7.7.10-5+deb7u3 [462 kB]
Get:5 http://my-approx-site:/debian/ wheezy/main zbar-tools amd64 
0.10+doc-8 [38.6 kB]
Get:6 http://my-approx-site:/debian/ wheezy/main libzbar0 amd64 0.10+doc-8 
[104 kB]
Fetched 3,077 kB in 0s (15.4 MB/s)
Selecting previously unselected package libtiff4:amd64.
(Reading database ... 68714 files and directories currently installed.)
Preparing to unpack .../libtiff4_3.9.6-11_amd64.deb ...
Unpacking libtiff4:amd64 (3.9.6-11) ...
Selecting previously unselected package libxt6:amd64.
Preparing to unpack .../libxt6_1%3a1.1.4-1+b1_amd64.deb ...
Unpacking libxt6:amd64 (1:1.1.4-1+b1) ...
Selecting previously unselected package libmagickcore5:amd64.
Preparing to unpack .../libmagickcore5_8%3a6.7.7.10-5+deb7u3_amd64.deb ...
Unpacking libmagickcore5:amd64 (8:6.7.7.10-5+deb7u3) ...
Selecting previously unselected package libmagickwand5:amd64.
Preparing to unpack .../libmagickwand5_8%3a6.7.7.10-5+deb7u3_amd64.deb ...
Unpacking libmagickwand5:amd64 (8:6.7.7.10-5+deb7u3) ...
dpkg: warning: downgrading zbar-tools from 0.10+doc-10 to 0.10+doc-8
Preparing to unpack .../zbar-tools_0.10+doc-8_amd64.deb ...
Unpacking zbar-tools (0.10+doc-8) over (0.10+doc-10) ...
dpkg: warning: downgrading libzbar0 from 0.10+doc-10 to 0.10+doc-8
Preparing to unpack .../libzbar0_0.10+doc-8_amd64.deb ...
Unpacking libzbar0 (0.10+doc-8) over (0.10+doc-10) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libtiff4:amd64 (3.9.6-11) ...
Setting up libxt6:amd64 (1:1.1.4-1+b1) ...
Setting up libmagickcore5:amd64 (8:6.7.7.10-5+deb7u3) ...
Setting up libmagickwand5:amd64 (8:6.7.7.10-5+deb7u3) ...
Setting up libzbar0 (0.10+doc-8) ...
Setting up zbar-tools (0.10+doc-8) ...
Processing triggers for libc-bin (2.19-18+deb8u1) ...
$ !zbar
zbarimg  /tmp/2015_08_26_JMH-095.jpg
CODE-39:UT0002918
scanned 1 barcode symbols from 1 images in 18 seconds

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and 
are no longer required:
  libmagickcore5 libmagickwand5 libxt6
Use 'apt-get autoremove' to remove them.
Done
The following packages have been kept back:
  db5.1-util ufraw-batch
The following packages will be upgraded:
  libzbar0 zbar-tools
2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 122 kB of archives.
After this operation, 4,096 B disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://my-approx-site:/debian/ jessie/main zbar-tools amd64 
0.10+doc-10 [35.3 kB]
Get:2 http://my-approx-site:/debian/ jessie/main libzbar0 amd64 0.10+doc-10 
[86.3 kB]
Fetched 122 kB in 0s (4,894 kB/s)
Reading changelogs... Done
(Reading database ... 68973 files and directories currently installed.)
Preparing to unpack .../zbar-tools_0.10+doc-10_amd64.deb ...
Unpacking zbar-tools (0.10+doc-10) over (0.10+doc-8) ...
Preparing to unpack .../libzbar0_0.10+doc-10_amd64.deb ...
Unpacking libzbar0 (0.10+doc-10) over (0.10+doc-8) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libzbar0 (0.10+doc-10) ...
Setting up zbar-tools (0.10+doc-10) ...
Processing triggers for libc-bin (2.19-18+deb8u1) ...
$ !zbar
zbarimg  /tmp/2015_08_26_JMH-095.jpg
scanned 0 barcode symbols from 1 images in 7.1 seconds


WARNING: barcode data was not detected in some image(s)
  things to check:
- is the barcode type supported?  currently supported symbologies are:
  EAN/UPC (EAN-13, EAN-8, UPC-A, UPC-E, ISBN-10, ISBN-13)

Bug#800380: tar: Incorrect --files-from behavior in 1.27 breaks amrecover

[Will Aoki]

Package: tar
Version: 1.27.1-2+b1
Severity: normal
Tags: patch
Control: notfound -1 1.26+dfsg-0.1

Tar 1.27 and 1.28 don't extract the contents of directories specified with
--files-from. This breaks AMANDA's amrecover utility (amanda-client package),
making it unable to extract anything but empty directories and individual files
from GNUTAR archives on wheezy.

The problem is discussed in detail at 
https://forums.zmanda.com/showthread.php?5461-Amrecover-is-not-restoring-directories-recursively/page2

There's a patch at 
http://lists.gnu.org/archive/html/bug-tar/2014-09/msg9.html

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages tar depends on:
ii  libacl1  2.2.52-2
ii  libc62.19-18+deb8u1
ii  libselinux1  2.3-2

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.6-7+b3
pn  ncompress
pn  tar-scripts  
ii  xz-utils 5.1.1alpha+20120614-2+b3

-- no debconf information

Bug#788295: open-iscsi+multipath+lvm breakage actually caused by several other bugs; incorrect size reporting merely a strange side effect

[Will Aoki]

The severe breakage I've been experiencing turns out to be a combination
of Debian bugs #782487/782488 and Ubuntu bug #1431650. I'm not sure why,
but the incorrect size reporting goes away if these other problems are
fixed.

Ubuntu bug #1431650 is deadlock between udev and multipath-tools until
systemd steps in and kills them. The critical clue was this set of
timeouts when iSCSI starts:

Jul 13 15:08:31 xxx kernel: sd 13:0:0:3: [sdl] Attached SCSI disk
Jul 13 15:08:31 xxx kernel: sd 12:0:0:3: [sdk] Attached SCSI disk
Jul 13 15:08:31 xxx kernel: sd 15:0:0:3: [sdn] Attached SCSI disk
Jul 13 15:08:31 xxx kernel: sd 14:0:0:3: [sdm] Attached SCSI disk
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13761] 
/devices/platform/host12/session1/target12:0:0/12:0:0:3/block/sdk timeout; kill 
it
Jul 13 15:09:01 xxx systemd-udevd[217]: seq 3784 
'/devices/platform/host12/session1/target12:0:0/12:0:0:3/block/sdk' killed
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13763] 
/devices/platform/host13/session2/target13:0:0/13:0:0:3/block/sdl timeout; kill 
it
Jul 13 15:09:01 xxx systemd-udevd[217]: seq 3783 
'/devices/platform/host13/session2/target13:0:0/13:0:0:3/block/sdl' killed
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13764] 
/devices/platform/host15/session4/target15:0:0/15:0:0:3/block/sdn timeout; kill 
it
Jul 13 15:09:01 xxx systemd-udevd[217]: seq 3785 
'/devices/platform/host15/session4/target15:0:0/15:0:0:3/block/sdn' killed
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13765] 
/devices/platform/host14/session3/target14:0:0/14:0:0:3/block/sdm timeout; kill 
it
Jul 13 15:09:01 xxx systemd-udevd[217]: seq 3786 
'/devices/platform/host14/session3/target14:0:0/14:0:0:3/block/sdm' killed
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13761] terminated by signal 
9 (Killed)
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13763] terminated by signal 
9 (Killed)
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13764] terminated by signal 
9 (Killed)
Jul 13 15:09:01 xxx systemd-udevd[217]: worker [13765] terminated by signal 
9 (Killed)

I'll file a bug report against multipath-tools asking for the patch to
be merged. With this problem solved, multipath devices could be manually
activated, often without size problems. They started up on boot, but the
size problem was present and they were shut down again within seconds,
even for test LUNs with no partition table.

Jul 13 17:21:24 xxx kernel: [   16.079329] device-mapper: table: 254:3: 
dm-1 too small for target: start=2048, len=12638472159, dev_size=12638472159
Jul 13 17:21:24 xxx kernel: [   16.192112] device-mapper: table: 254:3: 
dm-1 too small for target: start=2048, len=12638472159, dev_size=12638472159
Jul 13 17:21:24 xxx kernel: [   16.284550] device-mapper: table: 254:3: 
dm-1 too small for target: start=2048, len=12638472159, dev_size=12638472159
Jul 13 17:21:24 xxx kernel: [   16.374621] device-mapper: table: 254:3: 
dm-1 too small for target: start=2048, len=12638472159, dev_size=12638472159
Jul 13 17:21:24 xxx kernel: [   16.469226] device-mapper: table: 254:3: 
dm-1 too small for target: start=2048, len=12638472159, dev_size=12638472159
[...]
Jul 13 17:21:25 xxx multipath-tools[1001]: Starting multipath daemon: 
multipathd.
Jul 13 17:21:25 xxx multipathd: 222e80001557aa18f devmap removed
Jul 13 17:21:25 xxx multipathd: 2221e000155449c2e devmap removed
Jul 13 17:21:25 xxx multipathd: 22268000155ea65e2 devmap removed

Multipath now gave useful debug output, and it soon became clear that
bug #782487/#782488 was to blame. Applying the suggested workaround by
editing blacklist_exceptions solve the problem. If it's not possible to
get a fix into a point release, it should probably be mentioned in
NEWS.Debian or the release notes as it causes severe breakage on
upgrades.

With this set of fixes, setting LVMGROUPS /etc/default/open-iscsi works
correctly (in the way it didn't on wheezy if multipath was in use).
Volume groups on multipath iSCSI come up correctly and filesystems on
them are mounted.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788295: open-iscsi+multipath+LVM breakage caused by incorrect size reporting

[Will Aoki]

On further investigation, it seems that something (multipath-tools? the
kernel?) doesn't read the size of the underlying devices correctly. I
initially thought this might be a problem with the GPT on the LUN I was
using, but I was able to reproduce this problem on a new LUN.

I did the following:

1: I published a new LUN 22268000155ea65e2 to the server. The system saw
   it and multipath started correctly.

2: I partitioned /dev/mapper/22268000155ea65e2 with gdisk.

3: I created a new PV on /dev/mapper/22268000155ea65e2-part1, pvmoved
   everything off of the old PV (which I thought was on a disk with an
   invalid GPT), removed the old LV from the volume group and rebooted.

4: The same LVM symptoms I described initially occurred on reboot, and
   the kernel logged this:

   [   44.081263] device-mapper: table: 254:1: dm-0 too small for target: 
start=2048, len=12638472159, dev_size=12638472159
   [   44.170954] device-mapper: table: 254:1: dm-0 too small for target: 
start=2048, len=12638472159, dev_size=12638472159

5: On the underlying volumes (e.g. /dev/sdi), gdisk reports no
   problems. On the multipath device, this happens:

   $ sudo gdisk /dev/mapper/22268000155ea65e2
   GPT fdisk (gdisk) version 0.8.10
   
   Warning! Disk size is smaller than the main header indicates! Loading
   secondary header from the last sector of the disk! You should use 'v' to
   verify disk integrity, and perhaps options on the experts' menu to repair
   the disk.
   Caution: invalid backup GPT header, but valid main header; regenerating
   backup header from main header.
   
   Warning! One or more CRCs don't match. You should repair the disk!
   
   Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: damaged
   
   
   Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
   verification and recovery are STRONGLY recommended.
   
   
   Command (? for help): v
   
   Caution: The CRC for the backup partition table is invalid. This table may
   be corrupt. This program will automatically create a new backup partition
   table when you save your partitions.
   
   Problem: The secondary header's self-pointer indicates that it doesn't reside
   at the end of the disk. If you've added a disk to a RAID array, use the 'e'
   option on the experts' menu to adjust the secondary header's and partition
   table's locations.
   
   Problem: Disk is too small to hold all the data!
   (Disk size is 12638472159 sectors, needs to be 12638474240 sectors.)
   The 'e' option on the experts' menu may fix this problem.
   
   Problem: GPT claims the disk is larger than it is! (Claimed last usable
   sector is 12638474206, but backup header is at
   12638474239 and disk size is 12638472159 sectors.
   The 'e' option on the experts' menu will probably fix this problem
   
   Problem: partition 1 is too big for the disk.
   
   Identified 5 problems!
   
   Command (? for help): q


I expect that I'll be able to produce a simple test case without LVM,
but I'm still not sure what's actually at fault.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788295: wheezy->jessie: open-iscsi+multipath+LVM broken worse than before, plus problematic interactions with official VMware Tools

[Will Aoki]

Package: upgrade-reports
Severity: normal

I recently upgraded a VM from wheezy + a kernel from wheezy-backports to
jessie. This VM mounts data volumes using LVM and multipath iSCSI, and this was
severely broken after the upgrade.

To start with, I want to be clear that broken lvm2 + open-iscsi +
multipath-tools is not a new thing (see e.g. bugs #547187, #455979 and
#605470), but it's broken differently in jessie and my old workarounds don't
work, so I thought it worth sharing what I've found.

PRE-UPGRADE CONFIGURATION:

The system uses open-iscsi to connect to four portals on an iSCSI target. The
storage appliance supports active/active operation. If I set LVMGROUPS in
/etc/default/open-iscsi, LVM activates on one of the individual block devices
instead of using the multipath device, so I left LVMGROUPS blank and instead
ran:

  vgchange -a y
  mount -a

after each boot.

I have this:

  # from multipath-tools FAQ
  types = [ "device-mapper", 16 ]

in /etc/lvm/lvm.conf so that LVM will look at the multipath devices.

Filesystems on LVM on iSCSI have the _netdev option in /etc/fstab.

NARRATIVE:

When I rebooted after the upgrade, I found that open-iscsi was not starting. On
investigation, I found that systemd was breaking a dependency loop (the details
of which I don't have, as apparently it wasn't logged anywhere?) invovling
open-iscsi, several other packages and VMware Tools by not starting open-iscsi.
Once I figured out what was going on, this was easy to solve by removing VMware
Tools and replacing it with open-vm-tools.

Before I figured out why the iSCSI initiator wasn't starting, I tried starting
it myself and activating LVM. The system hung on shutdown and printed this on
the console:

[  457.367028]  connection4:0 ping timeout of 5 secs expired, recv timeout 5, 
last rx 4295004020, last ping 4295005272, now 429006524
[  457.383035]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, 
last rx 4295004024, last ping 4295005276, now 4295006528
[  547.383178]  connection2:0: ping timeout of 5 secs expired, recv timeout 5, 
last rx 4295004024, last ping 4295005276, now 4295006528
[  460.217125]  connection3:0: ping timeout of 5 secs expired, recv timeout 5, 
last rx 4295004730, last ping 4295005982, now 4295007236
[  472.502769] systemd-shutdown[1] Failed to finalize  DM devices, ignoring
[  600.692475] INFO: task lvm:2445 blocked for more than 120 seconds
[  600.692591]  Not tainted 3.16.0-4-amd64 #1
[  600.692670] "echo > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  720.780789] INFO: task lvm:2445 blocked for more than 120 seconds
[  720.780876]  Not tainted 3.16.0-4-amd64 #1
[  720.780930] "echo > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

(Pardon any typoes: this was hand-transcribed from a screenshot.)

After solving this problem, I found that without it being listed in LVMGROUPS,
my volume group was not activated, as before. With LVMGROUPS set correctly, it
was activated and filesystems were mounted (albiet very slowly, possibly
connected with bug #775778), but (as before) LVM was not using the multipath
device.

I found that unlike the situation with wheezy, I could not get LVM to use
multipath at all:

- There's no difference in behavior regardless of whether I have 'types' set in
  /etc/lvm/lvm.conf per the multipath FAQ, possibly because:

- No matter what I have in LVMGROUPS, 'multipath -l' does not show my devices
  after reboot, possibly because:

- On some trials, multipath-tools starts after open-iscsi.

- If I list my VG in LVMGROUPS, it's mounted and activated, but LVM is not
  using multipath.

- I can get multipath to see the devices if I stop & restart all the services,
  but LVM insists on using /dev/sd?. If I filter "r/sd.*/", LVM doesn't see any
  PVs.

- NEWS.Debian mentions that multipath-tools does not provide a systemd unit,
  but does not mention any need to change configuration.

At present the system is not able to use multipath, but I'm keeping it on
jessie instead of reverting because I need certain other bugfixes & updates
that jessie delivers.


MINUTIAE:

It's worth noting that even with VMware Tools removed, systemd is breaking a
dependency loop by not starting clvm. I didn't look into this further because
I'm not (knowingly) using clvm.

May 07 11:51:44 backup1 systemd[1]: Found ordering cycle on basic.target/start
May 07 11:51:44 backup1 systemd[1]: Found dependency on sysinit.target/start
May 07 11:51:44 backup1 systemd[1]: Found dependency on clvm.service/start
May 07 11:51:44 backup1 systemd[1]: Found dependency on corosync.service/start
May 07 11:51:44 backup1 systemd[1]: Found dependency on basic.target/start
May 07 11:51:44 backup1 systemd[1]: Breaking ordering cycle by deleting job 
clvm.service/start
May 07 11:51:44 backup1 systemd[1]: Job clvm.service/start deleted to break 
ordering cycle starting with basic.target/start




-- System Information:
Debian Release: 8.0
  APT prefers 

Bug#748811: dia: Last page omitted from printing under certain conditions

[Will Aoki]

Package: dia
Version: 0.97.2-8
Severity: normal

Steps to reproduce:

1: Open attached problem-demo.dia

2: Go to File -> Print

3: Ensure that "All Pages" is selected

4: Click "Print Preview" (the problem also happens if one clicks "Print", but
   that uses paper)

Expected outcome:

- All three pages appear in the preview or are printed

Actual outcome:

- Pages 1 and 2 appear in the preview or are printed; page 3 is missing

Additional information:

- If you drag the text that tells you to drag it to the third page, the third
  page will print.

- On some trials, I've seen the third page print after I rearranged the various
  labels even if I don't move anything to the third page.

- If you drag the rightmost green handle on the "Network - Bus" object into
  the middle of the third page, the third page will print.

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
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 dia depends on:
ii  dia-common  0.97.2-8
ii  dia-libs0.97.2-8
ii  libart-2.0-22.3.21-2
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u1
ii  libcairo2   1.12.2-3
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libpng12-0  1.2.49-1
ii  libxml2 2.8.0+dfsg1-7+nmu3
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages dia recommends:
ii  gsfonts-x11  0.22

dia suggests no packages.

-- no debconf information


problem-demo.dia
Description: GNU Zip compressed data

Bug#439763: Bug #439763 [Debconf-devel] Bug#439763: debconf: hangs on puppet installs on preseed install

[Will Aoki]

On Mon, Apr 28, 2014 at 09:33:38AM -0600, Will Aoki wrote:
> This hadn't been happening before that date. I haven't identified why it
> works on some but not on others -- there isn't supposed to be any
> configuration difference between the two groups.

All the computers I've had that experience this problem were using dash
for /bin/sh. Using bash for /bin/sh has, so far, made the problem go
away; however, not all computers with dash as /bin/sh have been
experiencing this problem.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#439763: Bug #439763 [Debconf-devel] Bug#439763: debconf: hangs on puppet installs on preseed install

[Will Aoki]

This started happening on April 8th on most of my wheezy systems. I'm
running apt-get from cfengine, not puppet, but symptoms are otherwise
the same, e.g.:

cfengine:x:/bin/sh -c 'DEB: (Reading database ... 326575 files and 
directories currently installed.)
cfengine:x:/bin/sh -c 'DEB: Preparing to replace openssl 1.0.1e-2+deb7u5 
(using .../openssl_1.0.1e-2+deb7u6_amd64.deb) ...
cfengine:x:/bin/sh -c 'DEB: Unpacking replacement openssl ...
cfengine:x:/bin/sh -c 'DEB: Processing triggers for man-db ...
cfengine:x:/bin/sh -c 'DEB: /var/lib/dpkg/info/man-db.postinst: 44: 
/var/lib/dpkg/info/man-db.postinst: 3: Bad file descriptor
cfengine:x:/bin/sh -c 'DEB: dpkg: error processing man-db (--unpack):
cfengine:x:/bin/sh -c 'DEB:  subprocess installed post-installation script 
returned error exit status 2
cfengine:x:/bin/sh -c 'DEB: Errors were encountered while processing:
cfengine:x:/bin/sh -c 'DEB:  man-db
cfengine:x:/bin/sh -c 'DEB: E: Sub-process /usr/bin/dpkg returned an error 
code (1)

This hadn't been happening before that date. I haven't identified why it
works on some but not on others -- there isn't supposed to be any
configuration difference between the two groups.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734084: cups: cupsd resubmitted print jobs on logrotate action / did not recognize successful printing

[Will Aoki]

Package: cups
Version: 1.5.3-5+deb7u1
Severity: normal

I discovered this morning that a computer running CUPS and using printers
advertised from another CUPS server has been resending print jobs whenever its
logs are rotated. The remote server was printing the job, but it would
remain in the queue on the local server.

The page_log looks like this:

rtc-xxx x 273 [03/Jan/2014:07:59:54 -0700] 1 1 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:07:59:54 -0700] total 0 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:07:59:55 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:07:59:56 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:07:59:58 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:01 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:06 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:14 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:16 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:19 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:19 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:21 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:26 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:34 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:35 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:36 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:38 -0700] total 5 - localhost 
x.pdf - -
rtc-xxx x 273 [03/Jan/2014:08:00:42 -0700] total 5 - localhost 
x.pdf - -

The error log contains messages like this:

E [03/Jan/2014:07:59:46 -0700] Failed to update TXT record for Lexmark 
International Lexmark E260dn @ .utah.edu: -2
E [03/Jan/2014:07:59:46 -0700] Failed to update TXT record for test-e260dn @ 
.utah.edu: -2
E [03/Jan/2014:07:59:51 -0700] SLPReg of "Lexmark-E260dn" failed with status 
-20!
E [03/Jan/2014:07:59:51 -0700] SLPReg of "test-e260dn" failed with status -20!
E [03/Jan/2014:08:00:22 -0700] SLPReg of "Lexmark-E260dn" failed with status 
-20!
E [03/Jan/2014:08:00:22 -0700] SLPReg of "test-e260dn" failed with status -20!
E [03/Jan/2014:08:00:54 -0700] SLPReg of "Lexmark-E260dn" failed with status 
-20!
E [03/Jan/2014:08:00:54 -0700] SLPReg of "test-e260dn" failed with status -20!

referring to a completely different printer which was, at one time, attached to
the local machine via USB. There's no mention of the printer this problem was
observed on.

After deleting the job and the disconnected & apparently-unrelated printer, I
was not able to reproduce this problem again, even when printing the same file.
I verified that the PostScript being sent was the same. I saved the contents of
/var/log/cups, /var/cache/cups and /var/spool/cups from before I deleted
anything, so I do have these files available for investigation.

-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
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 cups depends on:
ii  adduser3.113+nmu3
ii  bc 1.06.95-2+b1
ii  cups-client1.5.3-5+deb7u1
ii  cups-common1.5.3-5+deb7u1
ii  cups-filters   1.0.18-2.1
ii  cups-ppdc  1.5.3-5+deb7u1
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.12
ii  ghostscript9.05~dfsg-6.3+deb7u1
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libc-bin   2.13-38
ii  libc6  2.13-38
ii  libcups2   1.5.3-5+deb7u1
ii  libcupscgi11.5.3-5+deb7u1
ii  libcupsimage2  1.5.3-5+deb7u1
ii  libcupsmime1   1.5.3-5+deb7u1
ii  libcupsppdc1   1.5.3-5+deb7u1
ii  libdbus-1-31.6.8-1+deb7u1
ii  libgcc11:4.7.2-5
ii  libgnutls262.12.20-7
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
ii  libkrb5-3  1.10.1+dfsg-5+deb7u1
ii  libldap-2.4-2  2.4.31-1+nmu2
ii  libpam0g   1.1.3-7.1
ii  libpaper1  1.1.24+nmu2
ii  libslp11.2.1-9
ii  libstdc++6 4.7.2-5
ii  libusb-1.0-0   2:1.0.11-1
ii  lsb-base

Bug#721688: BUG: soft lockup, leading to host system being unusable

[Will Aoki]

Here's another crash with identical symptoms. The function at the top of
the stack is different, but in both cases they were called from
VBoxDrvLinuxIOCtl_4_1_18.

Nov 23 23:49:28 desk1 kernel: [47739.677801] BUG: soft lockup - CPU#5 stuck for 
23s! [VirtualBox:7821]
Nov 23 23:49:28 desk1 kernel: [47739.677806] Modules linked in: parport_pc 
ppdev lp parport snd_hrtimer cpufreq_stats cpufreq_powersave cpufreq_userspace 
cpufreq_conservative pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) 
nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc xfs loop snd_hda_codec_hdmi 
snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss 
snd_mixer_oss snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event i915 
snd_rawmidi snd_seq snd_seq_device snd_timer drm_kms_helper snd drm iTCO_wdt 
i2c_i801 soundcore i2c_algo_bit iTCO_vendor_support psmouse acpi_cpufreq joydev 
i2c_core coretemp mperf serio_raw pcspkr evdev video processor button ext4 
crc16 jbd2 mbcache sha256_generic dm_crypt dm_mod raid1 md_mod microcode 
hid_microsoft usbhid hid sg sr_mod cdrom sd_mod crc_t10dif crc32c_intel 
ghash_clmulni_intel aesni_intel aes_x86_64 aes_generic cryptd thermal ehci_hcd 
xhci_hcd ahci libahci fan thermal_sys libata usbcore scsi_mod atl1c usb_common 
[last unloaded: scsi_wait_scan]
Nov 23 23:49:28 desk1 kernel: [47739.677881] CPU 5 
Nov 23 23:49:28 desk1 kernel: [47739.677883] Modules linked in: parport_pc 
ppdev lp parport snd_hrtimer cpufreq_stats cpufreq_powersave cpufreq_userspace 
cpufreq_conservative pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) 
nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc xfs loop snd_hda_codec_hdmi 
snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss 
snd_mixer_oss snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event i915 
snd_rawmidi snd_seq snd_seq_device snd_timer drm_kms_helper snd drm iTCO_wdt 
i2c_i801 soundcore i2c_algo_bit iTCO_vendor_support psmouse acpi_cpufreq joydev 
i2c_core coretemp mperf serio_raw pcspkr evdev video processor button ext4 
crc16 jbd2 mbcache sha256_generic dm_crypt dm_mod raid1 md_mod microcode 
hid_microsoft usbhid hid sg sr_mod cdrom sd_mod crc_t10dif crc32c_intel 
ghash_clmulni_intel aesni_intel aes_x86_64 aes_generic cryptd thermal ehci_hcd 
xhci_hcd ahci libahci fan thermal_sys libata usbcore scsi_mod atl1c usb_common 
[last unloaded: scsi_wait_scan]
Nov 23 23:49:28 desk1 kernel: [47739.677942] 
Nov 23 23:49:28 desk1 kernel: [47739.677945] Pid: 7821, comm: VirtualBox 
Tainted: G   O 3.2.0-4-amd64 #1 Debian 3.2.51-1 Gigabyte Technology 
Co., Ltd. To be filled by O.E.M./Z77-D3H
Nov 23 23:49:28 desk1 kernel: [47739.677951] RIP: 0010:[]  
[] csd_lock+0x8/0x14
Nov 23 23:49:28 desk1 kernel: [47739.677959] RSP: 0018:8803a1c2dc80  
EFLAGS: 0202
Nov 23 23:49:28 desk1 kernel: [47739.677961] RAX: fffa RBX: 
a05e3b8e RCX: 
Nov 23 23:49:28 desk1 kernel: [47739.677964] RDX:  RSI: 
a0556cc9 RDI: 88041f354280
Nov 23 23:49:28 desk1 kernel: [47739.677966] RBP: a0556cc9 R08: 
88040b8be810 R09: 88040b8be810
Nov 23 23:49:28 desk1 kernel: [47739.677968] R10:  R11: 
0246 R12: 
Nov 23 23:49:28 desk1 kernel: [47739.677971] R13: 00015bd9 R14: 
c90006e26000 R15: c90006e01000
Nov 23 23:49:28 desk1 kernel: [47739.677974] FS:  7fd7b2e98700() 
GS:88041f34() knlGS:
Nov 23 23:49:28 desk1 kernel: [47739.677977] CS:  0010 DS:  ES:  CR0: 
8005003b
Nov 23 23:49:28 desk1 kernel: [47739.677979] CR2: 0226 CR3: 
0003dbb5b000 CR4: 001426e0
Nov 23 23:49:28 desk1 kernel: [47739.677982] DR0:  DR1: 
 DR2: 
Nov 23 23:49:28 desk1 kernel: [47739.677984] DR3:  DR6: 
0ff0 DR7: 0400
Nov 23 23:49:28 desk1 kernel: [47739.677987] Process VirtualBox (pid: 7821, 
threadinfo 8803a1c2c000, task 880409c9a180)
Nov 23 23:49:28 desk1 kernel: [47739.677990] Stack:
Nov 23 23:49:28 desk1 kernel: [47739.677991]  81070984 8134f247 
 
Nov 23 23:49:28 desk1 kernel: [47739.677996]    
 0004
Nov 23 23:49:28 desk1 kernel: [47739.678000]  8803a1c2dd28 0001 
c90006e01000 
Nov 23 23:49:28 desk1 kernel: [47739.678005] Call Trace:
Nov 23 23:49:28 desk1 kernel: [47739.678009]  [] ? 
smp_call_function_single+0xce/0xf2
Nov 23 23:49:28 desk1 kernel: [47739.678015]  [] ? 
_raw_spin_unlock_irqrestore+0xe/0xf
Nov 23 23:49:28 desk1 kernel: [47739.678028]  [] ? 
VBoxHost_RTMpPokeCpu+0x33/0x39 [vboxdrv]
Nov 23 23:49:28 desk1 kernel: [47739.678042]  [] ? 
rtR0MemAllocEx+0xba/0x112 [vboxdrv]
Nov 23 23:49:28 desk1 kernel: [47739.678052]  [] ? 
supdrvIOCtl+0x11f6/0x2277 [vboxdrv]
Nov 23 23:49:28 desk1 kernel: [47739.678060]  [] ? 
rtR0Mem

Bug#730051: libapache2-mod-php5: Segfault after PDO memory corruption, possibly Apache-related?

[Will Aoki]

Package: libapache2-mod-php5
Version: 5.4.4-14+deb7u5
Severity: normal

I am unsure as to whether this bug should be filed against PHP or Apache, so I
flipped a coin and filed this against PHP.

After upgrading from squeeze to wheezy, a particular script has started causing
segfaults, but only when it retrieves a particular database record. I have not
yet succeeded at constructing a test case that does not contain private data
and a giant chunk of legacy code.

The segfaults are happening in functions called from PDO's free_statement. The
script uses PDO to connect to a Microsoft SQL Server database.

Findings:

- The crash only happens for me when Apache's mod_deflate is enabled. The crash
  does not happen with the command-line PHP interpreter and does not seem to
  occur when I hit the site over SSL.

- Although I haven't conducted an exhaustive search, the crash only seems to
  happen with a particular database record. I can see nothing unusual about
  that record.

- Bug #696590 notwithstanding, the core dumps show crashing in simple functions
  called from free_statement. I expect that the actual cause of the problem
  lies elsewhere.

- If I delete this line from the script:

Special Notes:

  the crash stops happening. If I alter that line, even going so far as to
  delete all the PHP code on that line, the script still crashes, but if I
  delete that line, the script does not crash.

- If I look at stmt->columns in free_statement, there seems to be evidence of
  memory corruption.  See the GDB transcripts.


GDB session transcripts:

Partial GDB session with one core dump:

[...]
#0  zend_mm_remove_from_free_list (heap=0xb7b1d648, mm_block=0xb7dead14)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_alloc.c:833
#1  0xb59f4edf in _zend_mm_free_int (heap=0xb7b1d648, p=0xb7dead1c)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_alloc.c:2101
#2  0xb690c816 in free_statement (stmt=0xb696bd68)
at /build/php5-2buXwb/php5-5.4.4/ext/pdo/pdo_stmt.c:2400
#3  0xb6912fdb in pdo_dbstmt_free_storage (stmt=0xb696bd68)
at /build/php5-2buXwb/php5-5.4.4/ext/pdo/pdo_stmt.c:2437
#4  0xb5a4707f in zend_objects_store_del_ref_by_handle_ex (handle=,
handlers=0x2) at /build/php5-2buXwb/php5-5.4.4/Zend/zend_objects_API.c:220
#5  0xb5a470bf in zend_objects_store_del_ref (zobject=0xb5a1ce39)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_objects_API.c:172
#6  0xb5a1ce39 in _zval_dtor_func (zvalue=0xb5a0e1cd)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_variables.c:52
#7  0xb5a0e1cd in _zval_ptr_dtor (zval_ptr=0xb5a2aa86)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_variables.h:35
#8  0xb5a2aa86 in zend_hash_apply_deleter ()
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_hash.c:650
#9  0xb5a2c4b5 in zend_hash_reverse_apply (ht=0xb59f594b, apply_func=0)
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_hash.c:804
#10 0xb5a0e504 in shutdown_destructors ()
at /build/php5-2buXwb/php5-5.4.4/Zend/zend_execute_API.c:217
#11 0xb5a1df9d in zend_call_destructors ()
at /build/php5-2buXwb/php5-5.4.4/Zend/zend.c:925
#12 0xb59b8235 in php_request_shutdown (dummy=0xb4a70fc8)
at /build/php5-2buXwb/php5-5.4.4/main/main.c:1723
#13 0xb5ad0284 in php_handler (r=0x0)
at /build/php5-2buXwb/php5-5.4.4/sapi/apache2handler/sapi_apache2.c:520
#14 0xb76e0656 in ap_run_handler (r=r@entry=0xb6135058) at config.c:159
#15 0xb76e0aa9 in ap_invoke_handler (r=r@entry=0xb6135058) at config.c:377
#16 0xb76f2d50 in ap_process_request (r=r@entry=0xb6135058) at 
http_request.c:282
#17 0xb76ef908 in ap_process_http_connection (c=0xb69241f0) at http_core.c:190
#18 0xb76e7b26 in ap_run_process_connection (c=0xb69241f0) at connection.c:43
#19 0xb76e7fd2 in ap_process_connection (c=c@entry=0xb69241f0, csd=0xb6924058)
at connection.c:190
#20 0xb76f83c0 in child_main (child_num_arg=child_num_arg@entry=14) at 
prefork.c:667
#21 0xb76f8d13 in make_child (slot=14, s=) at prefork.c:768
#22 make_child (s=, slot=14) at prefork.c:696
#23 0xb76f9a4c in perform_idle_server_maintenance (p=)
at prefork.c:903
#24 ap_mpm_run (_pconf=_pconf@entry=0xb767d018, plog=0xb73c6018,
s=s@entry=0xb73f4880) at prefork.c:1107
#25 0xb76c96a4 in main (argc=3, argv=0xbfe10214) at main.c:755
(gdb) frame 2
#2  0xb690c816 in free_statement (stmt=0xb696bd68)
at /build/php5-2buXwb/php5-5.4.4/ext/pdo/pdo_stmt.c:2400
2400/build/php5-2buXwb/php5-5.4.4/ext/pdo/pdo_stmt.c: No such file or 
directory.
(gdb) print stmt
$1 = (pdo_stmt_t *) 0xb696bd68
[...]
(gdb) print i
$4 = 14
(gdb) print stmt->column_count
$5 = 67
(gdb) print cols[14].name
No symbol "cols" in current context.
(gdb) print stmt->columns[14].name
$6 = 0xb7dead1c "City"
(gdb) ^Z
[...]
(gdb) print stmt->columns[13].name
$9 = 0x0
(gdb) print stmt->columns[16].name
$10 = 0xb7deb60c "Zip"
(gdb) print stmt->columns[15].name
$11 = 0xb7deb194 "Stat\024\247\336\267"
(gdb) print stmt->columns[14].name
$12 = 0xb7dead1c "City"
(gdb) ^Z
[...]
$13 = 0xb7dead1c "City"
(gdb) print stmt->columns[15].nam

Bug#722592: amanda-server: Inability to read one header stops entire amvault run

[Will Aoki]

Package: amanda-server
Version: 1:3.3.1-4
Severity: normal

If amvault is unable to read the header from one dump, then rather than
continuing on to the rest, it stops the entire run, reporting "Problem reading
Amanda header: EOF". This means that a single error reading source data (in my
chg-disk case, a single zero-length file) will stop the amvault operation, even
if subsequent dumps or tapes are okay.

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages amanda-server depends on:
ii  amanda-common  1:3.3.1-4
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1
ii  libc6  2.13-38
ii  libcurl3   7.26.0-1+wheezy3
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libssl1.0.01.0.1e-2

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
ii  amanda-client  1:3.3.1-4
ii  cpio   2.11+dfsg-0.1
ii  gnuplot4.6.0-8
ii  mt-st  1.1-4
ii  perl [perl5]   5.14.2-21

-- 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#547187: Still present in wheezy

[Will Aoki]

found 2.02.95-7
thanks

This bug is still present in wheezy. Based on reading bug #605470, I
suspect it and this share the same root cause, bug #455979.

There's a workaround for this in open-iscsi, albeit one that doesn't
work with multipath. If one adds the volume group to LVMGROUPS in
/etc/default/open-iscsi, the volume group will be activated, but it
won't using the multipath device.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#721004: http://bugs.debian.org/ shorthand no longer works

[Will Aoki]

Package: bugs.debian.org
Severity: normal

It used to be possible to look up bugs with the shorthand
http://bugs.debian.org/, but now that results in a package
search for the bug number. This shorthand seems to be in very wide use
both in package documentation and links from external web pages.

Procedure to reproduce: point web browser at e.g. http://bugs.debian.org/605470

Expected result: web browser is redirected to 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605470

Actual result: web browser is redirected to 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=605470;dist=unstable


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714384: amanda-client: NT_STATUS_ACCESS_DENIED causes SMB backup to fail completely rather than report warnings after upgrade

[Will Aoki]

Package: amanda-client
Version: 1:3.3.1-4
Severity: normal

After upgrading from squeeze (with 1:3.3.1-3~bpo60+1) to wheezy, SMB
dumps fail with:

> FAILURE DUMP SUMMARY:
>   backup1.nhmu.utah.edu //someserver/ambak lev 0  FAILED [/usr/bin/smbclient 
> exited with status 1: see 
> /var/log/amanda/client/umnh-set/sendsize.20130628001003.debug]

with this in the log:

> Fri Jun 28 00:16:44 2013: thd-0x18a5400: sendsize: no size line match in 
> /usr/bin/smbclient output for //someserver/ambak

if anything on the client returns NT_STATUS_ACCESS_DENIED. This means
that AMANDA will fail to backup the entire DLE, even if only one
directory is unreadable.

Previously, this situation would cause warnings mentioning
NT_STATUS_ACCESS_DENIED but would not cause the entire dump to fail.

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages amanda-client depends on:
ii  amanda-common  1:3.3.1-4
ii  libc6  2.13-38
ii  libcurl3   7.26.0-1+wheezy3
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libreadline6   6.2+dfsg-0.1
ii  libssl1.0.01.0.1e-2

amanda-client recommends no packages.

Versions of packages amanda-client suggests:
pn  dump   
ii  gnuplot4.6.0-8
ii  smbclient  2:3.6.6-6

-- 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#710932: virtualbox: VirtualBox raises its own windows on click

[Will Aoki]

Package: virtualbox-qt
Version: 4.1.18-dfsg-2+deb7u1
Severity: normal

After upgrading from squeeze to wheezy, VirtualBox now raises windows showing
virtual machines when I click on them, rather than allowing the window manager
to decide if the window should be raised.

This happens if I click in the area that's showing the virtual machine, but not
if I click on e.g. the menu bar.

This behavior makes VirtualBox very difficult to use, as it's no longer willing
to share the screen with other programs.

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
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 virtualbox depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.16.10
ii  libc62.13-38
ii  libcurl3 7.26.0-1+wheezy2
ii  libgcc1  1:4.7.2-5
ii  libgsoap22.8.7-2
ii  libpng12-0   1.2.49-1
ii  libpython2.7 2.7.3-6
ii  libsdl1.2debian  1.2.15-5
ii  libssl1.0.0  1.0.1e-2
ii  libstdc++6   4.7.2-5
ii  libvncserver00.9.9+dfsg-1
ii  libx11-6 2:1.5.0-1+deb7u1
ii  libxcursor1  1:1.1.13-1+deb7u1
ii  libxext6 2:1.3.1-2+deb7u1
ii  libxml2  2.8.0+dfsg1-7+nmu1
ii  libxmu6  2:1.1.1-1
ii  libxt6   1:1.1.3-1+deb7u1
ii  python   2.7.3-4
ii  python2.72.7.3-6
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u1
ii  libqt4-opengl 4:4.8.2+dfsg-11
ii  libqtcore44:4.8.2+dfsg-11
ii  libqtgui4 4:4.8.2+dfsg-11
ii  virtualbox-dkms   4.1.18-dfsg-2+deb7u1
ii  virtualbox-qt 4.1.18-dfsg-2+deb7u1

Versions of packages virtualbox suggests:
ii  vde22.3.2-4
pn  virtualbox-guest-additions-iso  

-- 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#536532: virtualbox-ose: VirtualBox raises its windows when it receives focus while the Create New Virtual Machine dialog is open

[Will Aoki]

notfound 4.1.18-dfsg-2+deb7u1
thanks

This does not appear to happen with the current VirtualBox, although it
has other raising-related bugs.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#496931: amanda-client: amrecover should prompt for passwords when using amcrypt-ossl-asym (and other encryption plugins)

[Will Aoki]

fixed #496931 1:3.3.1-3~bpo60+1
thanks

This appears to work in the current version available in
squeeze-backports.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#700594: amanda-client: Scanning causes amandad to use 100% CPU forever

[Will Aoki]

Package: amanda-client
Version: 1:3.3.1-4
Severity: normal

Since switching to bsdtcp, routine security scans have caused amandad to get
stuck doing this:

read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0
poll([{fd=0, events=POLLIN}], 1, -1)= 1 ([{fd=0, revents=POLLIN}])
read(0, "", 253605) = 0

The relevant amandad process uses up all the CPU time that it can, taking the
load average to 1.

The scan is coming from a system which is not listed in /etc/amandahosts but
which tcp_wrappers will allow to connect.

I hope to have packet captures that will cause this once I can coordinate with
the relevant folks to have tcpdump running during a scan.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (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 amanda-client depends on:
ii  amanda-common  1:3.3.1-4
ii  libc6  2.13-37
ii  libcurl3   7.26.0-1+wheezy1
ii  libglib2.0-0   2.33.12+really2.32.4-3
ii  libreadline6   6.2+dfsg-0.1
ii  libssl1.0.01.0.1c-4

amanda-client recommends no packages.

Versions of packages amanda-client suggests:
pn  dump   
pn  gnuplot
ii  smbclient  2:3.6.6-5

-- 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#657690: General protection fault in XFS code

[Will Aoki]

On Sat, Jan 19, 2013 at 11:38:56PM +, Ben Hutchings wrote:
> I don't suppose there were any other XFS-related errors in the kernel
> log?

There's nothing else. The only kernel messages I see for several days
before are about a leap second being inserted and various tape-related
messages (e.g. mt blocking for more than 120 seconds), and the only
kernel messages for a week after are the RAID verifying itself and more
tape stuff.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657690: General protection fault in XFS code

[Will Aoki]

found 657690 linux-2.6/2.6.32-46
thanks

After months of quiet, this problem has reared its head again. This time
the system is still responsive. The system configuration is the same as
mentioned previously, except that the flash drive is no longer attached.

[7617112.478337] general protection fault:  [#1] SMP
[7617112.478369] last sysfs file: /sys/devices/virtual/block/md0/md/mismatch_cnt
[7617112.478402] CPU 0
[7617112.478423] Modules linked in: rpcsec_gss_krb5 nfsd nfs lockd fscache 
nfs_acl a
[7617112.478722] Pid: 47, comm: kswapd0 Not tainted 2.6.32-5-amd64 #1
[7617112.478760] RIP: 0010:[]  [] 
xfs_count_page
[7617112.478836] RSP: 0018:8801254ef968  EFLAGS: 00010207
[7617112.478872] RAX: 880100c0 RBX: eaff0008 RCX: 
8801254ef9c4
[7617112.478929] RDX: 8801254ef9c8 RSI: 8801254ef9cc RDI: 
eaff0008
[7617112.478989] RBP: 00d0 R08: 27a78c762204feef R09: 
365c4a93b1e9e885
[7617112.479048] R10: 880127c20080 R11: a01c19fb R12: 
880126540d90
[7617112.479108] R13: 880126540eb0 R14: dead00100101 R15: 
8801254efe10
[7617112.479168] FS:  () GS:88000520() 
knlGS:000
[7617112.479230] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[7617112.479267] CR2: 016235e0 CR3: a9828000 CR4: 
06f0
[7617112.479324] DR0:  DR1:  DR2: 

[7617112.479383] DR3:  DR6: 0ff0 DR7: 
0400
[7617112.479440] Process kswapd0 (pid: 47, threadinfo 8801254ee000, task 
880
[7617112.479502] Stack:
[7617112.479528]  a01c1a4b   
000
[7617112.479569] <0>  0001  

[7617112.479633] <0>   eaff0008 
000100ff
[7617112.479717] Call Trace:
[7617112.479753]  [] ? xfs_vm_releasepage+0x50/0xa5 [xfs]
[7617112.479796]  [] ? shrink_page_list+0x48d/0x623
[7617112.479836]  [] ? common_interrupt+0xe/0x13
[7617112.479873]  [] ? isolate_pages_global+0xa1/0x20f
[7617112.479911]  [] ? shrink_list+0x45c/0x767
[7617112.479948]  [] ? bit_waitqueue+0x10/0xa0
[7617112.479987]  [] ? proc_delete_inode+0x0/0x40
[7617112.480024]  [] ? determine_dirtyable_memory+0xd/0x1d
[7617112.480063]  [] ? update_curr+0xa6/0x147
[7617112.480100]  [] ? shrink_zone+0x280/0x342
[7617112.480137]  [] ? kswapd+0x4b9/0x686
[7617112.480171]  [] ? isolate_pages_global+0x0/0x20f
[7617112.480209]  [] ? autoremove_wake_function+0x0/0x2e
[7617112.480249]  [] ? __wake_up_common+0x44/0x72
[7617112.480286]  [] ? kswapd+0x0/0x686
[7617112.480320]  [] ? kthread+0x79/0x81
[7617112.480356]  [] ? child_rip+0xa/0x20
[7617112.480391]  [] ? kthread+0x0/0x81
[7617112.480423]  [] ? child_rip+0x0/0x20
[7617112.480457] Code: 49 89 1f eb ef 90 c7 01 00 00 00 00 c7 02 00 00 00 00 c7 
06 0
[7617112.480607] RIP  [] xfs_count_page_state+0x25/0x66 [xfs]
[7617112.480654]  RSP 
[7617112.480857] ---[ end trace 56748dedc4909bd1 ]---


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#682822: squid3: Cleaner way to replace error text

[Will Aoki]

Package: squid3
Version: 3.1.6-1.2+squeeze2
Severity: wishlist

It would be useful if the Squid package offered a Debian-friendly way to
replace error text (beyond making a custom package that Provides squid-langpack
or using dpkg-divert to protect my changes). I have an situation where I must
alter the error text, and the files in /usr/share/squid3/errors aren't
conffiles.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
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 squid3 depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  libcap21:2.19-3  support for getting/setting POSIX.
ii  libcomerr2 1.41.12-4stable1  common error description library
ii  libdb4.8   4.8.30-2  Berkeley v4.8 Database Libraries [
ii  libexpat1  2.0.1-7   XML parsing C library - runtime li
ii  libgcc11:4.4.5-8 GCC support library
ii  libgssapi-krb5-2   1.8.3+dfsg-4squeeze5  MIT Kerberos runtime libraries - k
ii  libk5crypto3   1.8.3+dfsg-4squeeze5  MIT Kerberos runtime libraries - C
ii  libkrb5-3  1.8.3+dfsg-4squeeze5  MIT Kerberos runtime libraries
ii  libldap-2.4-2  2.4.23-7.2OpenLDAP libraries
ii  libltdl7   2.2.6b-2  A system independent dlopen wrappe
ii  libpam0g   1.1.1-6.1+squeeze1Pluggable Authentication Modules l
ii  libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libxml22.7.8.dfsg-2+squeeze4 GNOME XML library
ii  logrotate  3.7.8-6   Log rotation utility
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  netbase4.45  Basic TCP/IP networking system
ii  squid3-common  3.1.6-1.2+squeeze2A full featured Web Proxy cache (H

squid3 recommends no packages.

Versions of packages squid3 suggests:
pn  resolvconf (no description available)
ii  smbclient 2:3.5.6~dfsg-3squeeze8 command-line SMB/CIFS clients for 
pn  squid-cgi  (no description available)
pn  squidclient(no description available)

-- Configuration Files:
/etc/squid3/squid.conf changed [not included]

-- 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#679343: libnet-ldap-perl: Segfaults when adding or deleting tainted values

[Will Aoki]

Package: libnet-ldap-perl
Version: 1:0.4001-2
Severity: normal

If Perl is run with taint checking and the 'add' or 'delete' methods on a
Net::LDAP::Entry object are given an attribute with a tainted value, Perl will
segfault when the 'update' method is used.

Simple example:

$ldapentry->add('memberUid' => $sometaintedvariable);
$ldapentry->update($ldaphandle);
print "This line is never reached because Perl crashes\n";

Observed behavior:

Perl interpreter segfaults. (In my testing, valgrind produces a "Conditional
jump or move depends on uninitialised value(s)" warning simply as a result of
'use Net::LDAP'.)

Expected behavior:

Perl interpreter does not segfault


Complicated example follows:

--- BEGIN EXAMPLE ---
#!/usr/bin/perl -w -T
# This program requires two arguments, a user in LDAP and a group to remove
# that user from.
# This program assumes a Kerberized environment and must be modified to
# work in a different environment.

use Net::LDAP;
use Authen::SASL qw(Cyrus);
use strict;

my %conf;
$conf{'basedn'} = 'PUT YOUR DN HERE';
$conf{'groupsdn'} = 'ou=Groups,' . $conf{'basedn'};
$conf{'ldapserver'} = 'PUT YOUR SERVER HERE';

my $adminuserdn = 'uid=' . getpwuid($<) . "/admin";

sub foo($$$)  {
  my $lh = $_[0];
  my $uid = $_[1];
  my $gid = $_[2];

  my $results = $lh->search(filter => '(&(objectClass=posixGroup)(cn=' . $gid . 
'))', base=>$conf{'basedn'});
  die "Search returned multiple entries\n" if ($results->count() > 1);
  return undef if ($results->count() < 1);

  my $group = $results->pop_entry();
  die "Got an entry for the wrong group" if ($group->dn ne 'cn=' . $gid . ',' . 
$conf{'groupsdn'});

  $group->changetype('modify');
  #$group->add('memberUid' => $uid);
  $group->delete('memberUid' => $uid);

  print "DEBUG: about to update\n";
  print "DEBUG: ${uid}, ${gid}\n";
  print $group->update($lh)->error_text(), "\n";
  print "DEBUG: updated\n";

  print "Removed ${uid} from ${gid} or added it instead\n";
}

my $err;
my $sh = Authen::SASL->new(mechanism=>'GSSAPI') or die "Can't get SASL 
handle\n";
my $lh = Net::LDAP->new($conf{'ldapserver'}, onerr=>sub{print('LDAP: ' . 
$_[0]);});

$err = $lh->start_tls(verify=>'require', capath=>'/etc/ssl/certs/');
$err->code && die 'LDAP start_tls: ' . $err->error;
unless ($lh->root_dse()->supported_sasl_mechanism('GSSAPI')) {
  die "GSSAPI not supported for some reason\n";
} $err = $lh->bind($adminuserdn, sasl=>$sh, version=>3);
$err->code && die 'LDAP bind: ' . $err->error;


if ($#ARGV !=  1) {
  die "Usage: crashit3.pl USER GROUP\n";
}

my $user = shift @ARGV;
my $group = shift @ARGV;

$user =~ /(.*)/;
my $notaintuser = $1;

print "Running without tainted attr value\n";
foo($lh, $notaintuser, $group);

print "Running with tained attr value\n";
foo($lh, $user, $group);

--- END EXAMPLE ---

-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
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 libnet-ldap-perl depends on:
ii  libconvert-asn1-perl   0.22-1Perl module for encoding and decod
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction 

libnet-ldap-perl recommends no packages.

Versions of packages libnet-ldap-perl suggests:
ii  libauthen-sasl-perl2.1500-1  Authen::SASL - SASL Authentication
ii  libio-socket-ssl-perl  1.33-1+squeeze1   Perl module implementing object or
ii  liburi-perl1.54-2module to manipulate and access UR
ii  libxml-parser-perl 2.36-1.1+b1   Perl module for parsing XML files
ii  libxml-sax-perl0.96+dfsg-2   Perl module for using and building
ii  perl [libdigest-md5-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction 

-- 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#674924: [request-tracker-maintainers] Bug#674924: Bug#674924: Bugfix for TCP resets

[Will Aoki]

On Wed, May 30, 2012 at 10:50:51PM +0100, Dominic Hargreaves wrote:
> http://people.debian.org/~dom/rt/ (3.8.8-7+squeeze4~test.1)
> 
> And let me know whether this fixes things for them?

I've had it running all day without seeing or hearing of any problems.

Thanks!

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#674924: [request-tracker-maintainers] Bug#674924: request-tracker3.8: Web interface periodically stops working after DSA-2480-1

[Will Aoki]

On Mon, May 28, 2012 at 12:35:24PM -0600, Will Aoki wrote:
> On Mon, May 28, 2012 at 06:00:56PM +0100, Dominic Hargreaves wrote:
> > Could you check whether the problem goes away if you downgrade to
> > 3.8.8-7+squeeze1 (making sure you stop and start apache afterwards)?
> 
> I'll do that and see if support staff still see the problem. It'll take
> a day or so to be sure it's not happening.

I've had no evidence of the problem since downgrading to
3.8.8-7+squeeze1.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#674924: [request-tracker-maintainers] Bug#674924: request-tracker3.8: Web interface periodically stops working after DSA-2480-1

[Will Aoki]

On Mon, May 28, 2012 at 06:00:56PM +0100, Dominic Hargreaves wrote:
> Could you check whether the problem goes away if you downgrade to
> 3.8.8-7+squeeze1 (making sure you stop and start apache afterwards)?

I'll do that and see if support staff still see the problem. It'll take
a day or so to be sure it's not happening.

> Is the host dedicated to RT or are there other applications/pages
> being served from Apache?

It's a dedicated virtual machine.

> Is it possible that other changes were made to the system configuration
> which have only just been picked up at the point you upgraded?

I don't have record of any configuration changes being made. The only
upgrade I see that might have touched something is the OpenSSL upgrade
installed on the 17th, if Apache wasn't restarted. Here's a transcript
of all upgrades since the last reboot before installing
3.8-3.8.8-7+squeeze2:

[May 17]
cfengine:rt:/bin/sh -c 'DEB: Preconfiguring packages ...
cfengine:rt:/bin/sh -c 'DEB: (Reading database ... 51406 files and directories 
currently installed.)
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace libssl0.9.8 0.9.8o-4squeeze12 
(using .../libssl0.9.8_0.9.8o-4squeeze13_amd64.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement libssl0.9.8 ...
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace openssl 0.9.8o-4squeeze12 
(using .../openssl_0.9.8o-4squeeze13_amd64.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement openssl ...
cfengine:rt:/bin/sh -c 'DEB: Processing triggers for man-db ...
cfengine:rt:/bin/sh -c 'DEB: Setting up libssl0.9.8 (0.9.8o-4squeeze13) ...
cfengine:rt:/bin/sh -c 'DEB: Setting up openssl (0.9.8o-4squeeze13) ...
[May 23]
cfengine:rt:/bin/sh -c 'DEB: (Reading database ... 51406 files and directories 
currently installed.)
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace libxml2 2.7.8.dfsg-2+squeeze3 
(using .../libxml2_2.7.8.dfsg-2+squeeze4_amd64.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement libxml2 ...
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace sudo 1.7.4p4-2.squeeze.2 
(using .../sudo_1.7.4p4-2.squeeze.3_amd64.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement sudo ...
cfengine:rt:/bin/sh -c 'DEB: Processing triggers for man-db ...
cfengine:rt:/bin/sh -c 'DEB: Setting up libxml2 (2.7.8.dfsg-2+squeeze4) ...
cfengine:rt:/bin/sh -c 'DEB: Setting up sudo (1.7.4p4-2.squeeze.3) ...
[May 24]
cfengine:rt:/bin/sh -c 'DEB: Preconfiguring packages ...
cfengine:rt:/bin/sh -c 'DEB: (Reading database ... 51406 files and directories 
currently installed.)
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace request-tracker3.8 
3.8.8-7+squeeze1 (using .../request-tracker3.8_3.8.8-7+squeeze2_all.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement request-tracker3.8 ...
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace rt3.8-clients 
3.8.8-7+squeeze1 (using .../rt3.8-clients_3.8.8-7+squeeze2_all.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement rt3.8-clients ...
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace rt3.8-apache2 
3.8.8-7+squeeze1 (using .../rt3.8-apache2_3.8.8-7+squeeze2_all.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement rt3.8-apache2 ...
cfengine:rt:/bin/sh -c 'DEB: Preparing to replace rt3.8-db-mysql 
3.8.8-7+squeeze1 (using .../rt3.8-db-mysql_3.8.8-7+squeeze2_all.deb) ...
cfengine:rt:/bin/sh -c 'DEB: Unpacking replacement rt3.8-db-mysql ...
cfengine:rt:/bin/sh -c 'DEB: Processing triggers for man-db ...
cfengine:rt:/bin/sh -c 'DEB: Setting up rt3.8-clients (3.8.8-7+squeeze2) ...
cfengine:rt:/bin/sh -c 'DEB: Setting up rt3.8-apache2 (3.8.8-7+squeeze2) ...
cfengine:rt:/bin/sh -c 'DEB: Setting up rt3.8-db-mysql (3.8.8-7+squeeze2) ...
cfengine:rt:/bin/sh -c 'DEB: Setting up request-tracker3.8 (3.8.8-7+squeeze2) 
...
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  If you are using mod_perl or any form 
of persistent perl
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  process such as FastCGI or SpeedyCGI, 
you will need to
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  restart your web server and any 
persistent processes now.
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  If you are using mod_perl or any form 
of persistent perl
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  process such as FastCGI or SpeedyCGI, 
you will need to
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  restart your web server and any 
persistent processes now.
cfengine:rt:/bin/sh -c 'DEB: **WARNING**  
cfengine:rt:/bin/sh -c 'DEB: dbconfig-common: writing config to 
/etc/dbconfig-common/request-tracker3.8.conf
cfengine:rt:/bin/sh -c 'DEB: dbconfig-common: flushing administrative password
cfengine:rt:/bin/sh -c 'DEB: No users with unsalted or weak cryptography found.
cfengine:rt:/bin/sh -c 'DEB: pam_mount(spawn.c:102): error setting uid to 0
cfengine:rt:/bin/sh -c 'DEB: rt-vulnerable-passwords-3.8 invoked successfully 
on upgrade
cfengine:rt:/bin/sh -c 'DEB: Can'

Bug#674924: request-tracker3.8: Web interface periodically stops working after DSA-2480-1

[Will Aoki]

Package: request-tracker3.8
Version: 3.8.8-7+squeeze2
Severity: important

After installing DSA-2480-1, the Request Tracker web interface
periodically stops responding. It does take whatever action the user
requested (e.g. it will send a reply), but no response comes back to the
user, and eventually the connection is reset.

Re-loading the page will sometimes make it work again -- for example, it
timed out loading my daashboard, but after five minutes I refreshed the
page, and it worked.

Apache (and indeed, the entire server) has been restarted since the
upgrade. The e-mail hotfix has been applied, which accounts for the
debsums error below.

(This upgrade was applied to the server before the serious problems with
this release became known.)

No information that I believe relevant is logged.

-- Version information of web server, database and MTA per reportbug note:
ii  apache22.2.16-6+squeeze7 Apache HTTP Server metapackage
ii  apache2-doc2.2.16-6+squeeze7 Apache HTTP Server documentation
ii  apache2-mpm-prefork2.2.16-6+squeeze7 Apache HTTP Server - traditional 
non-threaded model
ii  apache2-utils  2.2.16-6+squeeze7 utility programs for webservers
ii  apache2.2-bin  2.2.16-6+squeeze7 Apache HTTP Server common binary 
files
ii  apache2.2-common   2.2.16-6+squeeze7 Apache HTTP Server common files
ii  exim4  4.72-6+squeeze2   metapackage to ease Exim MTA (v4) 
installation
ii  exim4-base 4.72-6+squeeze2   support files for all Exim MTA 
(v4) packages
ii  exim4-config   4.72-6+squeeze2   configuration for the Exim MTA (v4)
ii  exim4-daemon-light 4.72-6+squeeze2   lightweight Exim MTA (v4) daemon
ii  mysql-client   5.1.61-0+squeeze1 MySQL database client (metapackage 
depending on the latest version)
ii  mysql-client-5.1   5.1.61-0+squeeze1 MySQL database client binaries
ii  mysql-common   5.1.61-0+squeeze1 MySQL database common files, e.g. 
/etc/mysql/my.cnf
ii  mysql-server   5.1.61-0+squeeze1 MySQL database server (metapackage 
depending on the latest version)
ii  mysql-server-5.1   5.1.61-0+squeeze1 MySQL database server binaries and 
system database setup
ii  mysql-server-core-5.1  5.1.61-0+squeeze1 MySQL database server binaries


-- Package-specific info:
Changed files:
  usr/share/request-tracker3.8/lib/RT/Interface/Email.pm

There are locally modified files in /usr/local/share/request-tracker3.8/,
 these may (or may not) be the source of the problem.


-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (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 request-tracker3.8 depends on:
ii  dbconfig-common1.8.46+squeeze.0  common framework for packaging dat
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  exim4  4.72-6+squeeze2   metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-light [ma 4.72-6+squeeze2   lightweight Exim MTA (v4) daemon
ii  libapache-session-perl 1.87-1Perl modules for keeping persisten
ii  libcache-simple-timede 0.27-2Perl module to cache and expire ke
ii  libcalendar-simple-per 1.21-1module for producing simple calend
ii  libcgi-fast-perl   5.10.1-17squeeze3 CGI::Fast Perl module
ii  libcgi-pm-perl 3.49-1squeeze1module for Common Gateway Interfac
ii  libclass-returnvalue-p 0.55-1A return-value object that lets yo
ii  libcss-squish-perl 0.09-1module to compact many CSS files i
ii  libdata-ical-perl  0.16+dfsg-1   Perl module for manipulating iCale
ii  libdbi-perl1.612-1   Perl Database Interface (DBI)
ii  libdbix-searchbuilder- 1.56-1Perl implementation of a simple OR
ii  libdevel-stacktrace-pe 1.2100-1  Perl module containing stack trace
ii  libemail-address-perl  1.889-2   RFC 2822 Address Parsing and Creat
ii  libfcgi-procmanager-pe 0.18-2Functions for managing FastCGI app
ii  libfile-sharedir-perl  1.00-0.1  Locate per-dist and per-module sha
ii  libgd-graph-perl   1.44-3Graph Plotting Module for Perl 5
ii  libgd-text-perl0.86-5Text utilities for use with GD
ii  libgnupg-interface-per 0.42-3Perl interface to GnuPG
ii  libgraphviz-perl   2.04-1Perl interface to the GraphViz gra
ii  libhtml-mason-perl 1:1.44-1  HTML::Mason Perl module
ii  libhtml-parser-perl3.66-1collection of modules that parse H
ii  libhtml-rewriteattribu 0.03-1concise attribute rewriting
ii  libhtml-scrubber-perl  0.08-4Perl extension for scrubbing/sanit
ii  libipc-run-safehandles 0.02-1Use IPC::Run and IPC::Run3 safely
ii  libjs-prototype1.6.1-1  

Bug#660295: Additional information on processes-hanging-in-D-state problem

[Will Aoki]

The problem broke the entire system overnight before I could get an
outage window in which to reboot. Besides the afpd and smbd processes
previously reported, cfagent processes had also begun to hang in 'D',
and while I didn't notice them in 'D' state along with the several
hundred other stuck processes, some component of AMANDA must have hung
because the backup process had been delayed. By this time neither
netatalk nor Samba were working properly.

The system was not sufficiently responsive for me to obtain any other
information about these other blocked processes.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660295: Processes-hanging-in-D-state problem started again after five days

[Will Aoki]

The processes-hanging-in-D-state problem started again within the last
few hours. The system has been up for five days and no network
disruptions involving the NFS server were observed. The problem was
preceeded by the same lockd message I reported earlier. Interestingly,
these stuck processes have the same file open the last time this problem
happened. I can 'cat' the file just fine.

I will proceed to try the kernel from squeeze-backports the next time I
can reboot this server.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#599402: Obtaining core dumps from netatalk

[Will Aoki]

I'm seeing this bug after upgrading to squeeze, and it's causing a
rather severe impact, but it doesn't look like the bug contains enough
information to be useful to the maintainers.

How does one get the Debian netatalk package to write core dumps on
segfaults? Modifying the init script to do 'ulimit -c unlimited' doesn't
cause it to dump core on segfaults, and attaching gdb to running
processes is going to be hit and miss at best until I (or someone) can
get a better handle on what's causing the problem.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660295: Additional information on processes-hanging-in-D-state problem

[Will Aoki]

Unmounting and re-mounting NFS mounts did not solve the problem, as rpciod
is still stuck in 'D' and stuck smbd processes are still spawning with the
same files open as before.

(I also noticed that a small number of afpd (from netatalk) processes were
also stuck in 'DL', with filehandles open on a different NFS mount.)

This left a reboot as the only way to deal with the problem. I'll continue
to monitor the situation, and if the problem persists I'll try the kernel
from squeeze-backports, if it can be installed without too much disruption.
If that persists, the system is going to be reverted to 2.6.26 from lenny.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660262: subversion: svnadmin recover segfaults after lenny to squeeze upgrade

[Will Aoki]

Package: subversion
Version: 1.6.12dfsg-6

(I don't believe this is the same problem as bug #425036. There's not
enough information to tell if it's related to #625627.)

After upgrading from lenny to squeeze, 'svnadmin recover' segfaulted.
Interestingly, while a remote svn+ssh commit failed with
DB_VERSION_MISMATCH (which is what alerted me to the need to run
'svnadmin recover'), a local 'svn update' after some apparently-failed
'svnadmin recover' runs worked without error, as did a local commit.
Before the local update and commit, 'svnadmin recover' always
segfaulted, but after the local update and commit, it ran without error.

Transcript of session:

$ svnadmin recover /path/to/repository
Repository lock acquired.
Please wait; recovering the repository may take some time...
Segmentation fault
$ ulimit -c unlimited
$ !svn
svnadmin recover /path/to/repository
Repository lock acquired.
Please wait; recovering the repository may take some time...
Segmentation fault (core dumped)
$ gdb /usr/bin/svnadmin core
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/svnadmin...(no debugging symbols found)...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libsvn_repos-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_repos-1.so.1
Reading symbols from /usr/lib/libsvn_fs-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_fs-1.so.1
Reading symbols from /usr/lib/libsvn_delta-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_delta-1.so.1
Reading symbols from /usr/lib/libsvn_subr-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_subr-1.so.1
Reading symbols from /usr/lib/libapr-1.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libapr-1.so.0
Reading symbols from /lib/i686/cmov/libpthread.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libpthread.so.0
Reading symbols from /lib/i686/cmov/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libsvn_fs_fs-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_fs_fs-1.so.1
Reading symbols from /usr/lib/libsvn_fs_base-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_fs_base-1.so.1
Reading symbols from /usr/lib/libsvn_fs_util-1.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_fs_util-1.so.1
Reading symbols from /usr/lib/libaprutil-1.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libaprutil-1.so.0
Reading symbols from /usr/lib/libldap_r-2.4.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libldap_r-2.4.so.2
Reading symbols from /usr/lib/liblber-2.4.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/liblber-2.4.so.2
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsqlite3.so.0
Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libuuid.so.1
Reading symbols from /lib/i686/cmov/librt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/librt.so.1
Reading symbols from /lib/i686/cmov/libcrypt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libcrypt.so.1
Reading symbols from /lib/i686/cmov/libdl.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libdb-4.8.so
Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /lib/i686/cmov/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libresolv.so.2
Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsasl2.so.2
Reading symbols from /usr/lib/libgnutls.so.26...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgnutls.so.26
Reading symbols from /usr/lib/libtasn1.so.3...(no debugging symbols 
found)...do

Bug#657690: General protection fault in xfs_vm_releasepage

[Will Aoki]

Package: linux-image-2.6.32-5-amd64
Version: 2.6.32-39squeeze1

My backup server has begun crashing in the XFS code within two minutes
of the start of about one of every six AMANDA runs. The first crash,
twelve days ago, appears to be XFS bug 15516 and will be reported
separately (as I don't see an existing bug report). This morning's crash
follows:

Jan 27 00:11:22 chickenadventurous kernel: [811024.687095] general protection 
fault:  [#1] SMP
Jan 27 00:11:22 chickenadventurous kernel: [811024.687142] last sysfs file: 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input7/event1/uevent
Jan 27 00:11:22 chickenadventurous kernel: [811024.687198] CPU 0
Jan 27 00:11:22 chickenadventurous kernel: [811024.687220] Modules linked in: 
rpcsec_gss_krb5 nfsd nfs lockd fscache nfs_acl auth_rpcgss sunrpc 8021q garp 
stp ext3 jbd mbcache loop snd_hda_codec_intelhdmi snd_hda_codec_realtek 
snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm snd_timer snd drm_kms_helper 
drm psmouse i2c_algo_bit i2c_i801 pcspkr evdev soundcore video serio_raw 
snd_page_alloc i2c_core output button processor xfs exportfs dm_mod raid1 
md_mod sg sr_mod cdrom osst sd_mod crc_t10dif st usbhid usb_storage hid 
ata_piix ata_generic sym53c8xx scsi_transport_spi e1000e libata ehci_hcd 
scsi_mod thermal usbcore nls_base thermal_sys [last unloaded: scsi_wait_scan]
Jan 27 00:11:22 chickenadventurous kernel: [811024.687541] Pid: 47, comm: 
kswapd0 Not tainted 2.6.32-5-amd64 #1
Jan 27 00:11:22 chickenadventurous kernel: [811024.687580] RIP: 
0010:[]  [] xfs_count_page_state+0x25/0x66 
[xfs]
Jan 27 00:11:22 chickenadventurous kernel: [811024.687657] RSP: 
0018:880124867b78  EFLAGS: 00010203
Jan 27 00:11:22 chickenadventurous kernel: [811024.687692] RAX: 
880100b0 RBX: ea0001728008 RCX: 880124867bd4
Jan 27 00:11:22 chickenadventurous kernel: [811024.687750] RDX: 
880124867bd8 RSI: 880124867bdc RDI: ea0001728008
Jan 27 00:11:22 chickenadventurous kernel: [811024.687809] RBP: 
 R08: 7a5da831f7287f78 R09: 6bc7c2d2d83dc935
Jan 27 00:11:22 chickenadventurous kernel: [811024.687869] R10: 
 R11: a0207a03 R12: 8800257a0d90
Jan 27 00:11:22 chickenadventurous kernel: [811024.687928] R13: 
00019e57 R14: 00012805 R15: 880124867c40
Jan 27 00:11:22 chickenadventurous kernel: [811024.687988] FS:  
() GS:88000520() knlGS:
Jan 27 00:11:22 chickenadventurous kernel: [811024.688048] CS:  0010 DS: 0018 
ES: 0018 CR0: 8005003b
Jan 27 00:11:22 chickenadventurous kernel: [811024.688084] CR2: 
7fff89ae8a60 CR3: 01001000 CR4: 06f0
Jan 27 00:11:22 chickenadventurous kernel: [811024.688142] DR0: 
 DR1:  DR2: 
Jan 27 00:11:22 chickenadventurous kernel: [811024.688202] DR3: 
 DR6: 0ff0 DR7: 0400
Jan 27 00:11:22 chickenadventurous kernel: [811024.688258] Process kswapd0 
(pid: 47, threadinfo 880124866000, task 880127b9dbd0)
Jan 27 00:11:22 chickenadventurous kernel: [811024.688320] Stack:
Jan 27 00:11:22 chickenadventurous kernel: [811024.688346]  a0207a53 
  0001
Jan 27 00:11:22 chickenadventurous kernel: [811024.688384] <0>  
0001  
Jan 27 00:11:22 chickenadventurous kernel: [811024.688448] <0>  
 ea0001728040 000101728040
Jan 27 00:11:22 chickenadventurous kernel: [811024.690605] Call Trace:
Jan 27 00:11:22 chickenadventurous kernel: [811024.690639]  
[] ? xfs_vm_releasepage+0x50/0xa5 [xfs]
Jan 27 00:11:22 chickenadventurous kernel: [811024.690683]  
[] ? invalidate_inode_page+0x5c/0x87
Jan 27 00:11:22 chickenadventurous kernel: [811024.690721]  
[] ? invalidate_mapping_pages+0x69/0xdb
Jan 27 00:11:22 chickenadventurous kernel: [811024.690759]  
[] ? shrink_icache_memory+0xfc/0x228
Jan 27 00:11:22 chickenadventurous kernel: [811024.690797]  
[] ? shrink_slab+0xe0/0x153
Jan 27 00:11:22 chickenadventurous kernel: [811024.690833]  
[] ? kswapd+0x4d9/0x686
Jan 27 00:11:22 chickenadventurous kernel: [811024.690867]  
[] ? isolate_pages_global+0x0/0x20f
Jan 27 00:11:22 chickenadventurous kernel: [811024.690907]  
[] ? autoremove_wake_function+0x0/0x2e
Jan 27 00:11:22 chickenadventurous kernel: [811024.690947]  
[] ? __wake_up_common+0x44/0x72
Jan 27 00:11:22 chickenadventurous kernel: [811024.690985]  
[] ? kswapd+0x0/0x686
Jan 27 00:11:22 chickenadventurous kernel: [811024.691017]  
[] ? kthread+0x79/0x81
Jan 27 00:11:22 chickenadventurous kernel: [811024.691052]  
[] ? child_rip+0xa/0x20
Jan 27 00:11:22 chickenadventurous kernel: [811024.691087]  
[] ? kthread+0x0/0x81
Jan 27 00:11:22 chickenadventurous kernel: [811024.691119]  
[] ? child_rip+0x0/0x20
Jan 27 00:11:22 chickenadventurous kernel: [811024.691153] Code: 49 89 1f eb ef 
90 c7 01 00

Bug#600661: ntp: Uses /var/lib/ntp/ntp.conf.dhcp regardless!?

[Will Aoki]

This is quite a nasty bug, as (when combined with #560046) it can easily
leave you in a situation where NTP has silently stopped working. The
incorrect documentation doesn't help matters.

It seems to me that /var/lib/ntp/ntp.conf.dhcp needs to be removed when
the DHCP client stops. It looks like there's code in the hook to do
that, but it evidently doesn't happen reliably, and should the system
crash the file will just get left there.

I'd recommend making arrangements for ntp.conf.dhcp to be erased on boot
and/or altering it to add DHCP-supplied servers in addition to, rather
than in place of, servers that are configured in /etc/ntp.conf.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#632839: alien reporting deb generated while actually failling

[Will Aoki]

On Sun, Aug 28, 2011 at 12:04:21PM -0600, Joey Hess wrote:
> You seem to have an older version of debhelper than I. What version?
> Also, what debian architecture are you building on?
> 
> With debhelper 8.9.4 on i386, this builds successfully.

It's debhelper 8.0.0 on x86_64, the same as the original bug reporter,
which is why I we're both seeing the same problem of alien thinking the
package was built when it wasn't.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#632839: alien reporting deb generated while actually failling

[Will Aoki]

On Sat, Aug 27, 2011 at 04:16:20PM -0600, Joey Hess wrote:
> Will Aoki wrote:
> > I'm seeing what I believe is the same problem.  As far as I can tell,
> > dh_builddeb really isn't generating anything because it doesn't see that
> > anything exists for it to do.
> 
> Interesting. I can't see how that would happen exactly. Can you run
> alien -s , and then send me the debian/ directory it generated in this
> case?

Sent in a separate e-mail not cc'd to the BTS. I noticed after I sent it
that I'd included more than the debian/ directory, but it's small enough
I hope it won't be a problem. Transcript:

waoki@trails1:~/bts-report$ fakeroot alien -s ../MegaCli-4.00.16-1.i386.rpm
Warning: Skipping conversion of scripts in package MegaCli: postinst postrm
Warning: Use the --scripts parameter to include the scripts.
Directory MegaCli-4.00.16 prepared.
waoki@trails1:~/bts-report$ tar czf alien-problem-megacli.tar.gz 
MegaCli-4.00.16/

After making the tarball, I verified that the build fails:

waoki@trails1:~/bts-report$ cd MegaCli-4.00.16/
waoki@trails1:~/bts-report/MegaCli-4.00.16$ fakeroot debian/rules binary
dh_testdir
dh_testdir
dh_testroot
dh_clean -k -d
dh_clean: No packages to build.
dh_installdirs
dh_installdocs
dh_installchangelogs
dh_installchangelogs: Compatibility levels before 5 are deprecated.
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
waoki@trails1:~/bts-report/MegaCli-4.00.16$ ls ..
MegaCli-4.00.16  alien-problem-megacli.tar.gz

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#632839: alien reporting deb generated while actually failling

[Will Aoki]

I'm seeing what I believe is the same problem.  As far as I can tell,
dh_builddeb really isn't generating anything because it doesn't see that
anything exists for it to do.

Working in a fakeroot environment on an amd64 system, I ran 'alien
--veryverbose -g MegaCLI-4.00.16-1.i386.rpm' to unpack the RPM and
prepare for build, then cd'd to the appropriate directory and ran
'debian/rules binary'. When I inserted debug statements into dh_builddeb
before and at the top of the 'foreach my $package (@{$dh{DOPACKAGES}})'
loop, I saw that @{dh{DOPACKAGES}} contains no elements.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#632152: ocsinventory-reports: Leaks database password when dbconfig.inc.php is missing

[Will Aoki]

Package: ocsinventory-reports
Version: 1.02.2-1.1
Severity: normal

When /etc/ocsinventory/dbconfig.inc.php has been deleted (e.g. by bug
#613609, which seems to be the result of something mentioned in
README.Debian but not in NEWS.Debian), OCS Inventory's web interface prompts
for the password to be re-entered (so that it can create a new
dbconfig.inc.php) using what appears to be the same form as install.php
uses: an "OCS Inventory Installation" page containing a form pre-filled with
the username and password for that OCS Inventory normally uses to access its
database.

This behavior is reasonably safe if it's actually being accessed through
install.php and the default restrictions on where install.php can be
accessed from are in place, but in this situation it's accessible from
anywhere that the OCS Inventory web interface is. To be clear: the URL is
, and thus the restriction on install.php in
ocsreports.conf does not apply.

I encountered this problem on an upgrade of an existing installation from
lenny to squeeze.

Steps to reproduce:

1: Upgrade from lenny to squeeze, OR simulate bug #613609 by removing
   /etc/ocsinventory/dbconfig.inc.php.

2: Point web browser at OCS Inventory web interface and examine the source
   of the page that is returned.

-- System Information:
Debian Release: 6.0.2
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-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 ocsinventory-reports depends on:
ii  apache22.2.16-6+squeeze1 Apache HTTP Server metapackage
ii  apache2-mpm-prefork [a 2.2.16-6+squeeze1 Apache HTTP Server - traditional n
ii  dbconfig-common1.8.46+squeeze.0  common framework for packaging dat
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  libapache2-mod-php55.3.3-7+squeeze1  server-side, HTML-embedded scripti
ii  php5   5.3.3-7+squeeze1  server-side, HTML-embedded scripti
ii  php5-mysql 5.3.3-7+squeeze1  MySQL module for php5
ii  ucf3.0025+nmu1   Update Configuration File: preserv

Versions of packages ocsinventory-reports recommends:
ii  libdbd-mysql-perl 4.016-1Perl5 database interface to the My
ii  libdbi-perl   1.612-1Perl Database Interface (DBI)
ii  libnet-ip-perl1.25-2 Perl extension for manipulating IP
ii  libxml-simple-per 2.18-3 Perl module for reading and writin
ii  nmap  5.00-3 The Network Mapper
ii  ocsinventory-serv 1.02.2-1.1 Hardware and software inventory to
ii  php5-gd   5.3.3-7+squeeze1   GD module for php5
ii  samba-common  2:3.5.6~dfsg-3squeeze4 common files used by both the Samb

ocsinventory-reports suggests no packages.

-- Configuration Files:
/etc/ocsinventory/ocsreports.conf changed:
Alias /ocsreports /usr/share/ocsinventory-server/ocsreports
Alias /download   /var/lib/ocsinventory-server/download

   Order deny,allow
   Deny from all
   Allow from 127.0.0.0/255.0.0.0 ::1/128
   Allow from 155.101.89.0/255.255.255.0
   #for waoki:
   Allow from 166.70.27.133
   SSLRequireSSL
   Options Indexes FollowSymLinks
   DirectoryIndex index.php
   # Authorize for setup
   
# For Apache 1.3 and 2.0

AuthType Basic
AuthName "OCS Reports Setup"
AuthUserFile /etc/ocsinventory/htpasswd.setup

# For Apache 2.2

AuthType Basic
AuthName "OCS Reports Setup"
AuthUserFile /etc/ocsinventory/htpasswd.setup

Require valid-user
   
   
   AddType application/x-httpd-php .php
php_value post_max_size 8m
php_value upload_max_filesize   8m
   
   
   AddType application/x-httpd-php .php
php_value post_max_size 8m
php_value upload_max_filesize   8m
   



-- debconf information:
  ocsinventory-reports/remote/host:
  ocsinventory-reports/upgrade-backup: true
  ocsinventory-reports/mysql/admin-user: root
  ocsinventory-reports/database-type: mysql
  ocsinventory-reports/missing-db-package-error: abort
  ocsinventory-reports/dbconfig-upgrade: true
  ocsinventory-reports/purge: false
  ocsinventory-reports/install-error: abort
  ocsinventory-reports/remove-error: abort
  ocsinventory-reports/dbconfig-reinstall: false
  ocsinventory-reports/dbconfig-install: true
  ocsinventory-reports/internal/skip-preseed: true
  ocsinventory-reports/passwords-do-not-match:
  ocsinventory-reports/upgrade-error: abort
  ocsinventory-reports/remote/port:
  ocsinventory-reports/remote/newhost:
  ocsinventory-

Bug#624265: cfengine2: Does not create /etc/cfengine on new install

[Will Aoki]

Package: cfengine2
Version: 2.2.10-2
Severity: minor

On a clean Squeeze install, the cfengine2 package still symlinks
/var/lib/cfengine2/inputs to /etc/cfengine, but it no longer creates
/etc/cfengine. There's no mention of this in NEWS.Debian.gz or
changelog.Debian.gz.

The problem came to my attention because I had to modify my new-system
deployment procedure to create /etc/cfengine (or remove the symlink at
/var/lib/cfengine/inputs) before installing my update.conf.

-- System Information:
Debian Release: 6.0.1
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable')
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 cfengine2 depends on:
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  dpkg1.15.8.10Debian package management system
ii  install-info4.13a.dfsg.1-6   Manage installed documentation in
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libdb4.74.7.25-9 Berkeley v4.7 Database Libraries [
ii  libssl0.9.8 0.9.8o-4squeeze1 SSL shared libraries

cfengine2 recommends no packages.

cfengine2 suggests no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613606: dh-make-perl: Fails to correctly identify GPLv2 in RT::Authen::ExternalAuth v0.08

[Will Aoki]

Thanks for the quick reply.

On Thu, Feb 17, 2011 at 03:11:04PM -0700, gregor herrmann wrote:
> This was with dh-make-perl 0.72-1 from unstable; I'm inclined to
> close this bug against 0.71-1 or 0.72-1, but I'm hesitating since I
> don't find any relevant changes in the code.

On further investigation, it looks like it reads the license correctly
the first time but fails on refresh. A transcript follows:

waoki@rt:~/probtest$ rm -rf RT-Authen-ExternalAuth-0.08/
waoki@rt:~/probtest$ dh-make-perl --cpan RT::Authen::ExternalAuth -e 
wa...@umnh.utah.edu
Going to read '/home/waoki/.cpan/Metadata'
  Database was generated on Thu, 17 Feb 2011 22:29:52 GMT
Going to read 2 yaml files from /home/waoki/.cpan/build/
CPAN: Time::HiRes loaded ok (v1.9719)
DONE
Restored the state of none (in 0.0486 secs)
CPAN: Digest::SHA loaded ok (v5.47)
  Checksum was ok
CPAN: Archive::Tar loaded ok (v1.52)
RT-Authen-ExternalAuth-0.08/
RT-Authen-ExternalAuth-0.08/html/
RT-Authen-ExternalAuth-0.08/html/Callbacks/
RT-Authen-ExternalAuth-0.08/html/Callbacks/ExternalAuth/
RT-Authen-ExternalAuth-0.08/html/Callbacks/ExternalAuth/autohandler/
RT-Authen-ExternalAuth-0.08/html/Callbacks/ExternalAuth/autohandler/Auth
RT-Authen-ExternalAuth-0.08/inc/
RT-Authen-ExternalAuth-0.08/inc/Module/
RT-Authen-ExternalAuth-0.08/inc/Module/Install.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Fetch.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/RTx.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Makefile.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Base.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Metadata.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Can.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/WriteAll.pm
RT-Authen-ExternalAuth-0.08/inc/Module/Install/Win32.pm
RT-Authen-ExternalAuth-0.08/etc/
RT-Authen-ExternalAuth-0.08/etc/RT_SiteConfig.pm
RT-Authen-ExternalAuth-0.08/MANIFEST
RT-Authen-ExternalAuth-0.08/lib/
RT-Authen-ExternalAuth-0.08/lib/RT/
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth.pm
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth/
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth/DBI/
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth/DBI/Cookie.pm
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth/DBI.pm
RT-Authen-ExternalAuth-0.08/lib/RT/Authen/ExternalAuth/LDAP.pm
RT-Authen-ExternalAuth-0.08/lib/RT/User_Vendor.pm
RT-Authen-ExternalAuth-0.08/META.yml
RT-Authen-ExternalAuth-0.08/ChangeLog
RT-Authen-ExternalAuth-0.08/README
RT-Authen-ExternalAuth-0.08/Makefile.PL
RT-Authen-ExternalAuth-0.08/LICENSE
CPAN: File::Temp loaded ok (v0.22)
Found: RT-Authen-ExternalAuth 0.07-02 (librt-authen-externalauth-perl arch=all)
Using cached Contents from Tue Feb 15 16:12:38 2011
- RT  not found in any package
   - it seems it is not available even via CPAN
Needs the following modules for which there are no debian packages available:
 - RT
Using maintainer: Will Aoki 
Found docs: README
Using rules: /usr/share/dh-make-perl/rules.dh7.tiny
--- Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
waoki@rt:~/probtest$ ls
RT-Authen-ExternalAuth-0.08  librt-authen-externalauth-perl_0.07-02.orig.tar.gz
waoki@rt:~/probtest$ cd RT-Authen-ExternalAuth-0.08/
waoki@rt:~/probtest/RT-Authen-ExternalAuth-0.08$ dh-make-perl refresh -e 
wa...@umnh.utah.edu
Engaging refresh mode in .
Found: RT-Authen-ExternalAuth 0.07-02 (librt-authen-externalauth-perl arch=all)
Found docs: README
debian/rules already uses DH7 tiny rules
**
Copyright information incomplete!

Upstream copyright information could not be automatically determined.

If you are building this package for your personal use, you might disregard
this information; however, if you intend to upload this package to Debian
(or in general, if you plan on distributing it), you must look into the
complete copyright information.

The causes for this warning are:
Licensing information is present, but cannot be parsed
Using cached Contents from Tue Feb 15 16:12:38 2011
- RT  not found in any package
Going to read '/home/waoki/.cpan/Metadata'
  Database was generated on Thu, 17 Feb 2011 22:29:52 GMT
Going to read 3 yaml files from /home/waoki/.cpan/build/
CPAN: Time::HiRes loaded ok (v1.9719)
DONE
Restored the state of none (in 0.0124 secs)
   - it seems it is not available even via CPAN
Needs the following modules for which there are no debian packages available:
 - RT
--- Done
waoki@rt:~/probtest/RT-Authen-ExternalAuth-0.08$ cat debian/copyright   
 Format-Specification: 
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
Maintainer: Mike Peachey 
Source: http://search.cpan.org/dist/RT-Authen-ExternalAuth/
Name: RT-Authen-ExternalAuth
DISCLAIMER: This copyright info was automatically extracted
 from the perl module. It may not be accurate, so you better
 check 

Bug#613606: dh-make-perl: Fails to correctly identify GPLv2 in RT::Authen::ExternalAuth v0.08

[Will Aoki]

Package: dh-make-perl
Version: 0.70-1
Severity: minor

dh-make-perl fails to correctly identify RT::Authen::ExternalAuth version 0.08
(available on CPAN) as being licensed under the GPLv2. Per the note it
generated in debian/copyright, I'm reporting this as a bug.

As far as I can tell, the text in LICENSE appears to just be an older version
of the GPLv2 than the one presented in /usr/share/common-licenses/GPL-2. The
only difference I see in the actual text is that still refers to the LGPL by
its old "Library General Public License" name.

-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (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 dh-make-perl depends on:
ii  debhelper 8.0.0  helper programs for debian/rules
ii  dpkg-dev  1.15.8.10  Debian package development tools
ii  fakeroot  1.14.4-1   Gives a fake root environment
ii  libapt-pkg-perl   0.1.24+b1  Perl interface to libapt-pkg
ii  libarray-unique-perl  0.08-1 Tie-able array that allows only un
ii  libclass-accessor-perl0.34-1 Perl module that automatically gen
ii  libdpkg-perl  1.15.8.10  Dpkg perl modules
ii  libemail-date-format-perl 1.002-1Module to generate RFC-2822-valid 
ii  liblist-moreutils-perl0.25~02-1  Perl module with additional list f
ii  libmodule-depends-perl0.14-3 identify the dependencies of a dis
ii  libparse-debcontrol-perl  2.005-2Easy OO parsing of Debian control-
ii  libparse-debianchangelog-perl 1.1.1-2.1  parse Debian changelogs and output
ii  libtie-ixhash-perl1.21-2 ordered associative arrays for Per
ii  libwww-mechanize-perl 1.64-1 module to automate interaction wit
ii  libyaml-perl  0.71-1 YAML Ain't Markup Language
ii  make  3.81-8 An utility for Directing compilati
ii  perl  5.10.1-17  Larry Wall's Practical Extraction 
ii  perl-modules [libmodule-corel 5.10.1-17  Core Perl modules

Versions of packages dh-make-perl recommends:
ii  apt-file  2.4.0  search for files within Debian pac

dh-make-perl 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#322226: fixed version

[Will Aoki]

notfound 36 1.4.4-1
thanks

On Wed, Jul 07, 2010 at 11:21:09AM -0600, Will Aoki wrote:
> On Wed, Jul 07, 2010 at 09:57:26AM -0600, Jean Felder wrote:
> > Hi Will,
> > 
> > According to http://www.cups.org/str.php?L2881 , It seems that this bug is 
> > fixed in current 1.4-x version.
> > 
> > Can you confirm it ?
> 
> I encountered bug #582563 while attempting to confirm whether it was
> fixed. I should be able to try with 1.4.4-1 later this week. If that
> fails to build on stable, then I can prepare a system running testing or
> unstable to try it on, although that will take a little bit longer.

Assuming my squeeze test environment was set up correctly to match my
lenny and sarge environments (Foomatic was acting up, but I believe I
eventually got the print queue set up correctly), #36 appears to be
fixed in CUPS 1.4.  Landscape PDFs that don't print correctly with the
CUPS present in lenny do print correctly with CUPS 1.4 from squeeze.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#168954: fixed version

[Will Aoki]

On Wed, Jul 07, 2010 at 09:57:26AM -0600, Jean Felder wrote:
> Hi Will,
> 
> According to http://www.cups.org/str.php?L2881 , It seems that this bug is 
> fixed in current 1.4-x version.
> 
> Can you confirm it ?

I encountered bug #582563 while attempting to confirm whether it was
fixed. I should be able to try with 1.4.4-1 later this week. If that
fails to build on stable, then I can prepare a system running testing or
unstable to try it on, although that will take a little bit longer.

Once I manage to get it installed, I'll also be able to test to see if
#168954 is still present.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#582563: FTBFS: dh_makeshlibs: command returned error code 256

[Will Aoki]

Package: cups
Version: 1.4.3-1
Severity: important
Justification: fails to build from source

On a lenny system with the various build-depends installed (having re-compiled
them for lenny), cups fails to build with the following:

[...]
dh_makeshlibs -plibcups2
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols disappeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: debian/libcups2/DEBIAN/symbols doesn't match 
completely debian/libcups2.symbols
--- dpkg-gensymbolsxUWtMm   2010-05-20 17:24:14.198617315 -0600
+++ dpkg-gensymbols4iipRb   2010-05-20 17:24:14.230617556 -0600
@@ -1,75 +1,146 @@
 libcups.so.2 libcups2 #MINVER#
- (optional)_cupsadmingetserversetti...@base 1.4.0
- (optional)_cupsadminsetserversetti...@base 1.4.0
- (optional)_cupscharmapfl...@base 1.4.0
- (optional)_cupscharmapf...@base 1.4.0
- (optional)_cupscharmap...@base 1.4.0
- (optional)_cupsconn...@base 1.4.0
- (optional)_cupsencodingn...@base 1.4.0
- (optional)_cupsgetpassw...@base 1.4.0
- (optional)_cupsglob...@base 1.4.0
- (optional)_cupslangprinter...@base 1.4.0
- (optional)_cupslangpri...@base 1.4.0
- (optional)_cupslangp...@base 1.4.0
- (optional)_cupslangstr...@base 1.4.0
- (optional)_cupsmd5app...@base 1.4.0
- (optional)_cupsmd5fin...@base 1.4.0
- (optional)_cupsmd5i...@base 1.4.0
- (optional)_cupsmessagef...@base 1.4.0
- (optional)_cupsmessagel...@base 1.4.0
- (optional)_cupsmessageloo...@base 1.4.0
- (optional)_cupspwgmediabyleg...@base 1.4.0
- (optional)_cupspwgmediabyn...@base 1.4.0
- (optional)_cupspwgmediabys...@base 1.4.0
- (optional)_cupssnmpcl...@base 1.4.0
- (optional)_cupssnmpcopy...@base 1.4.0
- (optional)_cupssnmpdefaultcommun...@base 1.4.0
- (optional)_cupssnmpis...@base 1.4.0
- (optional)_cupssnmpisoidprefi...@base 1.4.0
- (optional)_cupssnmpoidtostr...@base 1.4.0
- (optional)_cupssnmpo...@base 1.4.0
- (optional)_cupssnmpr...@base 1.4.0
- (optional)_cupssnmpsetde...@base 1.4.0
- (optional)_cupssnmpstringto...@base 1.4.0
- (optional)_cupssnmpw...@base 1.4.0
- (optional)_cupssnmpwr...@base 1.4.0
- (optional)_cupssetdefau...@base 1.4.0
- (optional)_cupsseter...@base 1.4.0
- (optional)_cupssethttper...@base 1.4.0
- (optional)_cupssetloc...@base 1.4.0
- (optional)_cupsstral...@base 1.4.0
- (optional)_cupsstrfl...@base 1.4.0
- (optional)_cupsstrform...@base 1.4.0
- (optional)_cupsstrf...@base 1.4.0
- (optional)_cupsstrret...@base 1.4.0
- (optional)_cupsstrsc...@base 1.4.0
- (optional)_cupsstrstatist...@base 1.4.0
- (optional)_cupsuserdefa...@base 1.4.0
- (optional)_cups_debug...@base 1.4.0
- (optional)_cups_debug_le...@base 1.4.0
- (optional)_cups_str...@base 1.4.0
- (optional)_cups_strl...@base 1.4.0
- (optional)_cups_strl...@base 1.4.0
- (optional)_httpaddrp...@base 1.4.0
- (optional)_httpcre...@base 1.4.0
- (optional)_httpencode...@base 1.4.0
- (optional)_httpreadgnu...@base 1.4.0
- (optional)_httpresolve...@base 1.4.0
- (optional)_httpw...@base 1.4.0
- (optional)_httpwritegnu...@base 1.4.0
- (optional)_ippadda...@base 1.4.0
- (optional)_ippfindopt...@base 1.4.0
- (optional)_ippfreea...@base 1.4.0
- (optional)_ipp_add_a...@base 1.4.0
- (optional)_ipp_free_a...@base 1.4.0
- (optional)_ppdfreelangua...@base 1.4.0
- (optional)_ppdget1284val...@base 1.4.0
- (optional)_ppdgetencod...@base 1.4.0
- (optional)_ppdgetlangua...@base 1.4.0
- (optional)_ppdhashn...@base 1.4.0
- (optional)_ppdlocalizeda...@base 1.4.0
- (optional)_ppdnormalizemakeandmo...@base 1.4.0
- (optional)_ppdparseopti...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsadmingetserversetti...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsadminsetserversetti...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupscharmapfl...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupscharmapf...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupscharmap...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsconn...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsencodingn...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsgetpassw...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsglob...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupslangprinter...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupslangpri...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupslangp...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupslangstr...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmd5app...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmd5fin...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmd5i...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmessagef...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmessagel...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupsmessageloo...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupspwgmediabyleg...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupspwgmediabyn...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupspwgmediabys...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupssnmpcl...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cupssnmpcopy...@base 1.4.0
+#MISSING: 1.4.3-1# (optional)_cup

Bug#501945: #501945 present in Lenny

[Will Aoki]

found 501945 2.7-18lenny2
thanks

Just tagging this bug, since it was observed this morning on one of my
Lenny machines. The others I've checked don't seem to be leaking file
descriptors.

I concur that this looks similar to Red Hat bug #428837, but I'm not
certain that it is. The RedHat patch is partially applied in
libnss-ldap_251-7.5etch1 and appears to be fully applied in 261-2.1. If
this were the cause, I'd not expect it to occur on lenny.

I'm going to play with it some more to see if I can trigger the problem
reliably. I have a few ideas for things to try, but I'll need to do them
during a maintenance window.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu1-6927



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#432271: ksymoops output from another Appletalk module oops

[Will Aoki]

On Thu, Aug 13, 2009 at 04:29:36PM -0600, Moritz Muehlenhoff wrote:
> On Mon, Jan 26, 2009 at 05:02:32PM -0700, Will Aoki wrote:
> > So far the bug has not manifested itself on
> > linux-image-2.6.24-etchnhalf.1-686 2.6.24-6~etchnhalf7; however, I have
> > had one unexplained crash.
> 
> So, the appletalk issue seems fixed? Has the unexplained crash manifested
> more often?  Do you have reason to believe it's related to the appletalk
> stack?

As the unexplained crash wrote nothing to the system log and nothing
could be obtained from the console, I have no information to go on. The
crash hasn't happend again, but then, I stopped running atalkd after the
unexplained crash. The appletalk module is still loaded (although I'm
not sure why, as nothing should have loaded it), but nothing is using
it.

Unfortunately, this doesn't say much either way. I've never been able to
reproduce the problem on my test system, despite running AppleTalk on it
for nine months now, and I'm not going to try AppleTalk again on the
production server because the risk is no longer worth the reward. It's
possible that the problem involves load -- if so, I'm not set up for
load testing. If it's a hardware fault, it must be very subtle, as there
are no other symptoms.

If it involves an interaction with a driver not present on my test
system, I'll have hardware available for testing in about a month that's
identical to the production fileserver except for the storage
controller, but it won't be available long before it's needed for
another purpose, so I wouldn't hold your breath.

AppleTalk was a nice-to-have feature but became less and less important
as older Macintoshes were retired, so apart from the brief testing in
December and January, I've not been using it on the problem system for
two years.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536745: audacious: Incorrect playback of mono MP3 files with extra-stereo plugin enabled

[Will Aoki]

Package: audacious
Version: 1.5.1-4
Severity: normal

When attempting to play mono MP3 files while the extra-stereo plugin is
turned on (something which worked correctly with xmms), Audacious
outputs loud noise. The spectrum analyzer visualization is correct. This
problem does not appear to happen when playing mono Ogg Vorbis files.

Steps to reproduce:

 1: Turn on the extra-stereo plugin.
 2: Play a mono MP3 file.

-- System Information:
Debian Release: 5.0.1
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29-2-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/bash

Versions of packages audacious depends on:
ii  audacious-plugins   1.5.1-2  Base plugins for audacious
ii  dbus1.2.1-5  simple interprocess messaging syst
ii  gtk2-engines-pixbuf 2.12.12-1~lenny1 Pixbuf-based theme for GTK+ 2.x
ii  libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii  libaudclient1   1.5.1-4  audacious dbus remote control libr
ii  libaudid3tag1   1.5.1-4  audacious id3 tag manipulation lib
ii  libc6   2.7-18   GNU C Library: Shared libraries
ii  libcairo2   1.6.4-7  The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.1-5  simple interprocess messaging syst
ii  libdbus-glib-1-20.76-1   simple interprocess messaging syst
ii  libglib2.0-02.16.6-1+lenny1  The GLib library of C routines
ii  libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface 
ii  libice6 2:1.0.4-1X11 Inter-Client Exchange library
ii  libmcs1 0.7.1-1  Abstraction library to store confi
ii  libmowgli1  0.6.1-1  a high performance development fra
ii  libpango1.0-0   1.20.5-3+lenny1  Layout and rendering of internatio
ii  libsamplerate0  0.1.4-1  audio rate conversion library
ii  libsm6  2:1.0.3-2X11 Session Management library
ii  libx11-62:1.1.5-2X11 client-side library

Versions of packages audacious recommends:
ii  audacious-plugins-extra   1.5.1-2Various extra plugins for audaciou
ii  unzip 5.52-12De-archiver for .zip files

audacious 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#536532: virtualbox-ose: VirtualBox raises its windows when it receives focus while the Create New Virtual Machine dialog is open

[Will Aoki]

Package: virtualbox-ose
Version: 1.6.6-dfsg-3
Severity: minor

When the Create New Virtual Machine dialog is open and the main VirtualBox
window receives focus, VirtualBox raises all of its windows to the top. This
is extremely annoying when one is using focus-follows-mouse, because if the
cursor but passes over the VirtualBox window, suddenly VirtualBox is on top
of the window I was working with. I don't see a way to turn this behavior
off.

I've not yet seen this behavior with any other dialog boxes.

I'm using the fvwm window manager without a desktop environment.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (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/bash

Versions of packages virtualbox-ose depends on:
ii  adduser3.110 add and remove users and groups
ii  debconf [debconf-2.0]  1.5.24Debian configuration management sy
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libgl1-mesa-glx [libgl1]   7.0.3-7   A free implementation of the OpenG
ii  libglib2.0-0   2.16.6-2  The GLib library of C routines
ii  libidl00.8.10-0.1library for parsing CORBA IDL file
ii  libqt3-mt  3:3.3.8b-5+b1 Qt GUI Library (Threaded runtime v
ii  libsdl1.2debian1.2.13-2  Simple DirectMedia Layer
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libx11-6   2:1.1.5-2 X11 client-side library
ii  libxcursor11:1.1.9-1 X cursor management library
ii  libxml22.6.32.dfsg-5 GNOME XML library
ii  libxslt1.1 1.1.24-2  XSLT processing library - runtime 
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library

Versions of packages virtualbox-ose recommends:
ii  virtualbox-os 2.6.26+1.6.6-dfsg-6+lenny1 PC virtualization solution for Lin

Versions of packages virtualbox-ose suggests:
ii  bridge-utils  1.4-5  Utilities for configuring the Linu
pn  virtualbox-ose-source  (no description available)

-- debconf information:
  virtualbox-ose/upstream_version_change: false



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529344: ocsinventory-reports: Different errors for bad username and for valid username with bad password

[Will Aoki]

Package: ocsinventory-reports
Version: 1.01-6
Severity: normal
Tags: security

The OCS Inventory web interface returns one error if one enters an
invalid username but a different error if one enters a valid username
with an invalid password -- in the English translation, the messages are
"User not registered" and "Password error". This type of behavior is
generally considered a problem because it permits an attacker to
determine whether usernames are valid.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-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/bash

Versions of packages ocsinventory-reports depends on:
ii  apache22.2.9-10+lenny2   Apache HTTP Server metapackage
ii  apache2-mpm-prefor 2.2.9-10+lenny2   Apache HTTP Server - traditional n
ii  dbconfig-common1.8.39common framework for packaging dat
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  libapache2-mod-php 5.2.6.dfsg.1-1+lenny3 server-side, HTML-embedded scripti
ii  php5   5.2.6.dfsg.1-1+lenny3 server-side, HTML-embedded scripti
ii  php5-mysql 5.2.6.dfsg.1-1+lenny3 MySQL module for php5
ii  ucf3.0016Update Configuration File: preserv

Versions of packages ocsinventory-reports recommends:
ii  libdbd-mysql-perl  4.007-1   A Perl5 database interface to the 
ii  libdbi-perl1.605-1   Perl5 database interface by Tim Bu
ii  libnet-ip-perl 1.25-2Perl extension for manipulating IP
ii  libxml-simple-perl 2.18-1Perl module for reading and writin
ii  nmap   4.62-1The Network Mapper
ii  ocsinventory-serve 1.01-6Hardware and software inventory to
ii  php5-gd5.2.6.dfsg.1-1+lenny3 GD module for php5
ii  samba-common   2:3.2.5-4lenny2   Samba common files used by both th

ocsinventory-reports suggests no packages.

-- debconf information excluded




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#322226: STR#2850 patch and #322226

[Will Aoki]

found 36 1.3.9-12
thanks

On Sun, Nov 16, 2008 at 03:55:15PM +0100, Martin Pitt wrote:
> Do you have a chance to test landscape printing with cups from
> experimental? It uses a different filter chaining now (using PDF as
> standard format instead of PS) and thus should avoid this problem
> entirely.

I've finally had a chance to to test the version in experimental. With
1.3.9-12, the following behavior occurs:

My landscape mode test document is set for US Letter paper size, 8.5x11
inches. On a Postscript queue, it prints shrunken down in the middle of
an 8.5x11 sheet of paper, a landscape page in miniature in the middle of
a portrait sheet. On an HPIJS queue, it prints in landscape mode, but
shrunken down in the corner of an 8.5x14 (US Legal) sheet. Portrait mode
output is correct in all cases. I haven't tested with a multipage
landscape document, but I can do so if needed.

To use the notation from STR2881:

Original document:

+--+
|ABCDEF|  8.5 inches
|ABCDEF|
+--+
11 inches

Output via the HPIJS queue, scale and distances approximate:

+---+++  --+
|   |||| 2.75 inches
| ABCDEF|   OR   |   ABCDEF   |  --+
| ABCDEF|   (see note)   |   ABCDEF   |
+---+++
| |  |   |
+-+ 6.5 inches   +---+--- 3.25 inches

(It's not entirely clear whether it's centered on the long axis or in
the corner: when the printer requested 8.5x14, I didn't have any, so I
had to manual-feed some 8.5x11 scrap paper instead.

Output via the Postscript queue, scale and distances approximate:

+--+  --+
|  || 2.75 inches
|ABCDEF|  --+
|ABCDEF|  --+
|  || 2.75 inches
+--+  --+

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#432271: ksymoops output from another Appletalk module oops

[Will Aoki]

On Mon, Dec 22, 2008 at 03:35:18PM -0700, waoki wrote:
> I've not been able to reproduce the problem on a test system, but it
> took less than sixteen hours for an oops to occur on
> linux-image-2.6.18-6-686 2.6.18.dfsg.1-23etch1 on my production system.
> The oops takes down AppleTalk but does not break other parts of the
> system.
> 
> I'll prepare to put the 2.6.24 kernel into production and try with it.

So far the bug has not manifested itself on
linux-image-2.6.24-etchnhalf.1-686 2.6.24-6~etchnhalf7; however, I have
had one unexplained crash.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#501945: nscd runs out of filehandles opening multiple instances of /var/run/nscd/socket and uses 100% CPU

[Will Aoki]

retitle 501945 nscd runs out of filehandles opening multiple instances of 
/var/run/nscd/socket and uses 100% CPU
found 501945 2.3.6.ds1-13etch8
thanks

As a data point: the same nscd failure occurred an hour ago, while
backups were running, on (as far as I can tell so far) a single system.
This particular system was last rebooted two days ago, so long uptime is
not an issue. While this problem was occurring, the slapd process on the
primary LDAP server was quite busy, causing its load average to rise
high enough to also trigger alarms. Nagios noticed the load average rise
before it noticed problems related to the runaway nscd process, but I
don't have data to indicate which actually occurred first.

As backups were running at the time, it could have been triggered by
something AMANDA is doing; however, cfengine was also busy doing its
four-times-an-hour traverse over a largeish directory tree.

Interactive access via the shell continued to work, albeit slowly.
While the problem was occurring, Samba and NRPE did not respond within
ten seconds. After I restarted nscd, everything returned to normal.

Apologies for the serveral typoes in the original bug report --
evidently I didn't proofread it well enough to notice 'of of' or
'averag'.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#432271: ksymoops output from another Appletalk module oops

[Will Aoki]

On Mon, Dec 01, 2008 at 10:16:27AM -0700, waoki wrote:
> I've turned off AppleTalk on the problem system because of this bug, so
> I'm not sure if it will still happen with 2.6.18-6-686, and even though
> the oops didn't affect other aspects of the system's operation, I'd
> rather not try it on my production file server. I'll try it on a test
> system now and get back to you in a few weeks (it may take a while
> before it oopses).
> 
> I can't guarantee that failure to reproduce it on 2.6.18-6-686 on my
> test system means it won't happen on 2.6.18-6-686 on the machine that
> was having problems, but if it runs cleanly on the test system, I may
> risk it on the production system over the holiday break.

I've not been able to reproduce the problem on a test system, but it
took less than sixteen hours for an oops to occur on
linux-image-2.6.18-6-686 2.6.18.dfsg.1-23etch1 on my production system.
The oops takes down AppleTalk but does not break other parts of the
system.

I'll prepare to put the 2.6.24 kernel into production and try with it.

-- 
William Aoki KD7YAFwa...@umnh.utah.edu5-1924



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#432271: ksymoops output from another Appletalk module oops

[Will Aoki]

On Sat, Nov 29, 2008 at 01:38:42AM +0100, Moritz Muehlenhoff wrote:
> On Thu, Jul 19, 2007 at 02:53:17PM -0600, Will Aoki wrote:
> > Here is output from a second incidence of this bug. This crash occurred
> > just this afternoon.
> 
> Does this error still occur on your system?
> 
> If so, could you try to reproduce this bug with the 2.6.24 based
> kernel added in 4.0r4? http://packages.qa.debian.org/l/linux-2.6.24.html

I've turned off AppleTalk on the problem system because of this bug, so
I'm not sure if it will still happen with 2.6.18-6-686, and even though
the oops didn't affect other aspects of the system's operation, I'd
rather not try it on my production file server. I'll try it on a test
system now and get back to you in a few weeks (it may take a while
before it oopses).

I can't guarantee that failure to reproduce it on 2.6.18-6-686 on my
test system means it won't happen on 2.6.18-6-686 on the machine that
was having problems, but if it runs cleanly on the test system, I may
risk it on the production system over the holiday break.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: STR#2850 patch and #322226

[Will Aoki]

On Sun, Nov 16, 2008 at 03:55:15PM +0100, Martin Pitt wrote:
> Do you have a chance to test landscape printing with cups from
> experimental? It uses a different filter chaining now (using PDF as
> standard format instead of PS) and thus should avoid this problem
> entirely.

1.3.9-4 does not build on etch, even after installing po4a and
hardening-wrapper from lenny (which satisfies all depends). The build
fails with the following:

Compiling pdftoijs.cxx...
pdftoijs.cxx:61: warning: non-local variable ':: 
::colspace' uses anonymous type
pdftoijs.cxx: In function 'void parseOpts(int, char**)':
pdftoijs.cxx:177: error: 'assert' was not declared in this scope
pdftoijs.cxx: In function 'int main(int, char**)':
pdftoijs.cxx:382: error: no match for 'operator[]' in 'paperColor[0]'
pdftoijs.cxx:383: error: no match for 'operator[]' in 'paperColor[1]'
pdftoijs.cxx:384: error: no match for 'operator[]' in 'paperColor[2]'
pdftoijs.cxx:394: error: no match for 'operator[]' in 'paperColor[0]'
pdftoijs.cxx:405: error: no match for 'operator[]' in 'paperColor[0]'
pdftoijs.cxx:429: error: no matching function for call to 
'SplashOutputDev::SplashOutputDev(SplashColorMode&, int&, GBool&, SplashColor&, 
int, int)'
/usr/include/poppler/SplashOutputDev.h:50: note: candidates are: 
SplashOutputDev::SplashOutputDev(SplashColorMode, GBool, SplashColor)
/usr/include/poppler/SplashOutputDev.h:45: note: 
SplashOutputDev::SplashOutputDev(const SplashOutputDev&)
pdftoijs.cxx:464: error: invalid cast from type 'SplashColorPtr' to type 'const 
char*'
make[2]: *** [pdftoijs.o] Error 1
make[2]: Leaving directory `/home/waoki/software/cups/cups-1.3.9/filter'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/waoki/software/cups/cups-1.3.9'
make: *** [debian/stamp-makefile-build] Error 2
debuild: fatal error at line 1228:
debian/rules build failed

I don't know why g++ is complaining about assert, but 
makes that error go away. As to the other errors, SplashColor appears to
be defined in libpoppler-dev, and I'm not presently able to install a
newer libpoppler-dev to try building against it. My test systems
currently need to remain on etch and libpoppler-dev from lenny drags in
some build-depends that I'd rather avoid at present. If time permits,
I'll see if I can get it to build later this week.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: STR#2850 patch and #322226

[Will Aoki]

On Thu, Jul 17, 2008 at 04:16:23PM -0600, waoki wrote:
> With str2850.patch applied and the package modified to use the 1.3
> pdftops filter (instead of the 1.4 pdftops filter), landscape output
> stops working to my Postscript test printer, where it worked correctly
> without the patch. My HPIJS test printer, on the other hand, orients the
> page correctly in landscape mode (whereas previously it did not), but
> the output is two and five-eighths inches to the right of where it
> should be.

... and it looks like this problem is now open upstream as STR2881.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: STR#2850 patch and #322226

[Will Aoki]

I haven't had much time to investigate this problem beyond the extent
mentioned in my note of April 3rd, but I thought I should record the
following results:

A few days ago, a patch was posted to STR#2850 (another report of the
PDF landscape printing problem) which purpots to fix it. The patch
applies cleanly against Debian's 1.3.7-9.

With str2850.patch applied and the package modified to use the 1.3
pdftops filter (instead of the 1.4 pdftops filter), landscape output
stops working to my Postscript test printer, where it worked correctly
without the patch. My HPIJS test printer, on the other hand, orients the
page correctly in landscape mode (whereas previously it did not), but
the output is two and five-eighths inches to the right of where it
should be.

The same results occur with the upstream SVN's pdftops (from the 1.3
branch) as of r7750. Additional testing will occur as time permits.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#486739: amanda-common: Wrong paths in amcrypt-ossl-asym manpage or script

[Will Aoki]

Package: amanda-common
Version: 1:2.5.2p1-3
Severity: minor

The FILES section of the amcrypt-ossl-asym(8) manpage describes the
private key, public key and passphrase files as being in
/var/lib/amanda, but the script itself (after the fix for #417818) looks
for them in ~backup, which is /var/backups.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages amanda-common depends on:
ii  adduser  3.102   Add and remove users and groups
ii  debconf [debconf 1.5.11etch1 Debian configuration management sy
ii  libc62.3.6.ds1-13etch5   GNU C Library: Shared libraries
ii  libncurses5  5.5-5   Shared libraries for terminal hand
ii  libreadline5 5.2-2   GNU readline and history libraries
ii  mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent
ii  openbsd-inetd [i 0.20050402-6The OpenBSD Internet Superserver
ii  perl [perl5] 5.8.8-7etch3Larry Wall's Practical Extraction 
ii  tar  1.16-2etch1 GNU tar
ii  update-inetd 4.27-0.5inetd.conf updater

amanda-common recommends no packages.

-- debconf information:
  amanda-common/merge_amandates:



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#474241: [Pkg-cups-devel] Bug#474241: Bug#474241: cupsys: Patch for landscape printing from MacOS X clients

[Will Aoki]

On Wed, 30 Apr 2008 at 13:36:23 +0200, Martin Pitt wrote:

> Oh, you mean that the MacOS client have their own cups which
> transforms the PDF into (broken) PostScript and sends this to the
> Debian cups server? Indeed there's not a lot we could do about this
> I'm afraid, since the pdftops filter isn't involved on the Debian
> side.

The MacOS client sends a PDF to the Debian cups server, and the Debian
CUPS server fails to rotate it correctly. This problem doesn't actually
require a MacOS client to reproduce: you can reproduce the problem by
printing a landscape PDF from the command line on a Debian system: the
broken PDF to PostScript converter is on the Debian system.

I reported this problem as #36, and someone else reported #289893,
which looks like it may be the same problem.

I've been poking at this problem on and off, and the executive summary
is that there are two problems. The first was introduced in 1.2.22-6,
which stopped using the internal xpdf, thus causing a regression of
STR#207. This problem can be fixed using the internal xpdf instead of
the filter script. The pdftops from CUPS 1.4, as provided in the Debian
1.3.6-3 package, has not solved this problem in my testing. I haven't
tried newer Debian packages, nor have I experimented with actually
running CUPS 1.4.

The second problem which affects landscape printing is probably a bug in
Ghostscript (or the way that CUPS drives Ghostscript) and applies to
printers using ljet4, hpijs, and other mechanisms where PostScript
interpreting occurs on the print server, not the printer.

The first part of the problem could be fixed in cups or in poppler-utils
and xpdf-utils. If my understanding of the second problem is correct
(which I'm not entirely confident of), then it needs fixing in cups or
in ghostscript.

For reference, my current production print server is a Sarge system
running cupsys 1.1.23-10sarge1 (using the internal xpdf, as per #36)
and gs-esp 7.07.1-9sarge1. It does not exhibit either problem.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: #322226 still present in 1.3.6-1 despite filter change

[Will Aoki]

found 36 1.3.6-1
thanks

I figured I should note that 36 is still present in 1.3.6-1 despite
the new filter. When printing via hpijs, I see the margin problems that
Reuben Thomas saw, plus some scaling problems, and when printing via
Postscript, I get a Postscript error:

ERROR: undefinedresource
OFFENDING COMMAND: findresource

STACK:

/ProcSet
/CIDInit

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: pdftops from cupsys source works in 1.3.5-1

[Will Aoki]

On Fri, Jan 11, 2008 at 10:11:56AM -0700, waoki wrote:
> For the record:
> 
> Building and installing the pdftops from the cupsys source works for me
> in 1.3.5-1: with it, landscape output works and the page is not offset
> the printer I used for testing. I don't know why the pdftops in the
> version in etch doesn't work for me.

As I was moving a printer to what I had hoped would be the new
production print server, I discovered that while the pdftops workaound
fixes the problem for Postscript queues, it does not fix the problem for
hpijs or ljet4 queues. (I also tested a Gutenprint queue, and with it,
something somewhere in the pipeline changed the paper size. I didn't
pursue it.) 

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467061: packages.debian.org ignores 'en' quality values when deciding which language to display package descriptions in

[Will Aoki]

Package: www.debian.org

If I load (for example)  with my
Accept-Language string set to "en; q=1.0", then the page and the package
description strings all appear in English, and if I load the page with
Accept-Language set to "de; q=1.0, en; q=0.5", then the package
description all appear in German, as expected. If, however, I have my
Accept-Language set to "en; q=1.0, de; q=0.5", then I see the page in
English but the package description strings in German.

This problem also appears for other languages, when packages have
suitable translations available. For example, setting Accept-Language to
"en; q=1.0, fr; q=0.5" causes 
to display in English, but with French package descriptions.

The quality values are not being flat-out ignored, it is not a case of a
value of 1.0 being ignored, and the problem is not positional: if I add
a third language, setting Accept-Language to "de; q=0.3, en; q=0.9, fr;
q=0.5", then I get most of the libc0.1 page in English but the
descriptions are in French, and if I set it to "de; q=0.7, en; q=0.9,
fr; q=0.4" gives most of the page in English and the package
descriptions in German. Only if I set both the French and German quality
values to zero do I get the package descriptions in English, even though
the rest of the page displays in English with any setting where English
outranks the other options.

I first noticed this problem while using Firefox, but I have verified
that it occurs using both w3m and lynx. There is no proxy in use.

Examples:

* With Accept-Language="en; q=1.0, de; q=0.1":

 dep: libc0.1 (>= 2.6-1) [kfreebsd-amd64, kfreebsd-i386]
GNU C-Bibliothek: Dynamische Bibliotheken
also a virtual package provided by libc0.1-udeb 

* With Accept-Language="de; q=1.0, en; q=0.1":

dep: libc0.1 (>= 2.6-1) [kfreebsd-amd64, kfreebsd-i386]
GNU C-Bibliothek: Dynamische Bibliotheken
auch ein virtuelles Paket, bereitgestellt durch libc0.1-udeb

* With Accept-Language="en; q=1.0"

dep: libc0.1 (>= 2.6-1) [kfreebsd-amd64, kfreebsd-i386]
GNU C Library: Shared libraries
also a virtual package provided by libc0.1-udeb

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#462186: netatalk: macusers gives wrong output for usernames longer than 8 characters

[Will Aoki]

Package: netatalk
Version: 2.0.3-4
Severity: normal
Tags: patch

Due to a change in procps, 'ps' no longer displays usernames that are
longer than eight characters. This causes 'macusers' to display
incorrect output:

PID  UID  Username Name Logintime Mac
xx6384004  xxx  x
xx10304005  x

(All UIDs except for the erroneous 0 have been replaced by fake
numbers.)

At one point, this ps behavior was considered a problem (see #86205 and
#94957), but this is now considered to be correct behavior.
(see e.g. #274546, #405063, and the procps FAQ)

The cause of this problem is that 'macusers' attempts to call getpwnam
on whatever it finds in the user column of 'ps', even if it is a number
that needs to be resolved using getpwuid. The following patch fixes this
problem, yielding the following output:


PID  UID  Username Name Logintime Mac
xx6384004  xxx  x
xx1034005 xxx   x


--- /usr/bin/macusers   2007-08-10 20:47:12.0 -0600
+++ macusers2008-01-22 18:52:40.545442240 -0700
@@ -80,7 +80,14 @@
 $time = $4;
 
 if ($ppid != 1) {
-($t, $t, $uid, $t, $t, $t, $name, $t, $t) = getpwnam($user);
+# Deal with truncated usernames. Caution: this does make the
+# assumption that no username will be all-numeric.
+if ($user =~ /^[0-9]+$/) {
+$uid = $user;
+($user, $t, $t, $t, $t, $t, $name, $t, $t) = 
getpwuid($uid);
+} else {
+($t, $t, $uid, $t, $t, $t, $name, $t, $t) = 
getpwnam($user);
+}
 ($name) = ( $name =~ /(^[^,]+)/ );
 printf "%-8d %-8d %-16s %-20s %-9s %s\n", $pid, $uid, $user,
 $name, $time, $mac{$pid};


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages netatalk depends on:
ii  cracklib2  2.7-19pro-active password checker librar
ii  libc6  2.3.6.ds1-13etch4 GNU C Library: Shared libraries
ii  libcupsys2 1.2.7-4etch2  Common UNIX Printing System(tm) - 
ii  libdb4.2   4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [
ii  libgcrypt111.2.3-2   LGPL Crypto library - runtime libr
ii  libgnutls131.4.4-3   the GNU TLS library - runtime libr
ii  libgpg-error0  1.4-1 library for common error values an
ii  libgssapi4-heimdal 0.7.2.dfsg.1-10   Libraries for Heimdal Kerberos
ii  libkrb5-17-heimdal 0.7.2.dfsg.1-10   Libraries for Heimdal Kerberos
ii  libpam-modules 0.79-5Pluggable Authentication Modules f
ii  libpam-runtime 0.79-5Runtime support for the PAM librar
ii  libpam0g   0.79-5Pluggable Authentication Modules l
ii  libslp11.2.1-6.2 OpenSLP libraries
ii  libssl0.9.80.9.8c-4etch1 SSL shared libraries
ii  libtasn1-3 0.3.6-2   Manage ASN.1 structures (runtime)
ii  libwrap0   7.6.dbs-13Wietse Venema's TCP wrappers libra
ii  netbase4.29  Basic TCP/IP networking system
ii  perl   5.8.8-7etch1  Larry Wall's Practical Extraction 
ii  zlib1g 1:1.2.3-13compression library - runtime

Versions of packages netatalk recommends:
ii  cracklib-runtime   2.7-19runtime support for password check
ii  db4.2-util 4.2.52+dfsg-2 Berkeley v4.2 Database Utilities
pn  libpam-cracklib(no description available)
ii  lsof   4.77.dfsg.1-3 List open files
pn  rc (no description available)
pn  slpd   (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: pdftops from cupsys source works in 1.3.5-1

[Will Aoki]

For the record:

Building and installing the pdftops from the cupsys source works for me
in 1.3.5-1: with it, landscape output works and the page is not offset
the printer I used for testing. I don't know why the pdftops in the
version in etch doesn't work for me.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322226: more test data on 322226

[Will Aoki]

found 36 1.3.5-1
thanks

This bug is still present in 1.3.5-1 with both xpdf-utils and
poppler-utils from etch, with the same test procedure as I used on
Monday. Next time I have a chance, I'll test with the built-in pdftops,
and I'll see if I can modify it to deal with the problem.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396226: ACL problem ameliorated in 3.0.28-1

[Will Aoki]

Bug #396226 is ameliorated but not fixed as of 3.0.28-1. Samba still
messes with ACLs, but it no longer locks people out from editing the
file. The following is the result of user 'test' editing a file
originally owned by user 'waoki':

-rw-rwx---+ 1 test visitorservices 19968 Dec 29 17:50 problem test.doc

# file: problem\040test.doc
# owner: test
# group: visitorservices
user::rw-
user:waoki:rw-
group::rw-
mask::rwx
other::---

Unfortunately, Samba bug #4398 has reared its ugly head, and I had to
set 'msdfs root=no' explicitly on the [homes] share and reboot all my
Windows clients. (I'm adding this note so that others who try this will
realize why clients can't map [homes].)

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#168954: Duplex still not working (from command line, with psutils, with 1.2.7-4etch1)

[Will Aoki]

found 168954 1.2.7-4etch1
thanks

This bug is still present in Etch: I've just come across it using psbook
and psnup.

Setting duplex in the PPD for the problem printer works, but this bug
(be it in psutils or cups) prevents overriding it on the lp command
line.

-- 
William Aoki [EMAIL PROTECTED]  KD7YAF



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#416935: Security update deleted old_passwords.cnf

[Will Aoki]

found 416935 5.0.32-7etch3
thanks

When I installed the 5.0.32-7etch3 security update,
/etc/mysql/conf.d/old_passwords.cnf was deleted. I can reproduce the
problem by reinstalling mysql-server-5.0.

Debconf settings:

* mysql-server/root_password: (password omitted)
  mysql-server-5.0/really_downgrade: false
* mysql-server-5.0/need_sarge_compat: false
  mysql-server-5.0/start_on_boot: true
  mysql-server/error_setting_password:
  mysql-server-5.0/nis_warning:
  mysql-server-5.0/postrm_remove_databases: false
  mysql-server-5.0/need_sarge_compat_done: true

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#232549: cupsys: lp -n still prints n^2 copies

[Will Aoki]

found 232549 1.2.7-4
thanks

Bug 232549 is still present in 1.2.7-4: 'lp -n number' still prints
'number' squared copies of the job. Unlike the original reporter, I
notice that this problem occurs regardless of whether I print from a
remote client or from the print server itself.

I reproduced the problem using an HP PSC 2510 connected over the network
using the 'hpoj' package. CUPS sees "DeviceURI 
ptal:hpjd:my.printer.hostname.here".
I reproduced the bug by printing a PostScript file made by running latex
and dvips on the following LaTeX input:

  \documentclass{article}
  \begin{document}

  This is a test document to investigate a printing bug.

  \end{document}

On the multipage document I was printing when I noticed the problem, I
saw that I got runs of several copies of the same page in sequence
before getting copies of the next page. After I canceled the print job,
I neglected to preserve the output order, but I think that within
sequences, the number of copies printed of a particular page was less
than the number of pages I asked for, and that overall, the page number
was not monotonically increasing throughout the output. When I can spare
the paper and ink, I'll conduct another test and report the output
order. (I may be able to do this at work this week or next week, as I'll
be testing the CUPS packages found in etch to see if I can upgrade the
print server from sarge without breaking printing for MacOS users.)

I seem to recall seeing the same problem with MacOS X clients and a
Debian print server several years ago. I don't know if it was ever
solved. If I can dig up my notes on that, I'll post 'em to the bug
report.

-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.35
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages cupsys depends on:
ii  adduser3.102 Add and remove users and groups
ii  cupsys-common  1.2.7-4   Common UNIX Printing System(tm) - 
ii  debconf [debconf-2.0]  1.5.11Debian configuration management sy
ii  gs-esp 8.15.3.dfsg.1-1   The Ghostscript PostScript interpr
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libcupsimage2  1.2.7-4   Common UNIX Printing System(tm) - 
ii  libcupsys2 1.2.7-4   Common UNIX Printing System(tm) - 
ii  libdbus-1-31.0.2-1   simple interprocess messaging syst
ii  libgnutls131.4.4-3   the GNU TLS library - runtime libr
ii  libldap2   2.1.30-13.3   OpenLDAP libraries
ii  libpam0g   0.79-4Pluggable Authentication Modules l
ii  libpaper1  1.1.21Library for handling paper charact
ii  libslp11.2.1-6.2 OpenSLP libraries
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  patch  2.5.9-4   Apply a diff file to an original
ii  perl-modules   5.8.8-7   Core Perl modules
ii  procps 1:3.2.7-3 /proc file system utilities
ii  xpdf-utils [poppler-ut 3.01-9etch1   Portable Document Format (PDF) sui
ii  zlib1g 1:1.2.3-13compression library - runtime

Versions of packages cupsys recommends:
ii  cupsys-client 1.2.7-4Common UNIX Printing System(tm) - 
ii  foomatic-filters  3.0.2-20061031-1.2 linuxprinting.org printer support 
ii  smbclient 3.0.24-6etch4  a LanManager-like simple client fo

-- debconf information:
* cupsys/raw-print: false
* cupsys/backend: ipp, lpd, socket


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432271: ksymoops output from another Appletalk module oops

[Will Aoki]

Here is output from a second incidence of this bug. This crash occurred
just this afternoon.

ksymoops 2.4.11 on i686 2.6.18-4-686.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.6.18-4-686/ (default)
 -m /boot/System.map-2.6.18-4-686 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
1151MB HIGHMEM available.
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ehci_hcd :00:1d.7: debug port 1
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfe6fe000, irq 217, MAC addr 00:04:23:B3:84:15
e1000: :01:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:04:23:b3:84:14
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
EDAC MC: Ver: 2.0.1 May  9 2007
EDAC i82875p: i82875p init one
EDAC MC0: Giving out device to i82875p_edac i82875p: DEV :00:00.0
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug 
enabled
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
lo: Disabled Privacy Extensions
BUG: unable to handle kernel NULL pointer dereference at virtual address 

f8ab0c2b
*pde = 
Oops:  [#1]
CPU:0
EIP:0060:[]Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286   (2.6.18-4-686 #1) 
eax:    ebx: 001f   ecx:    edx: 01cc3280
esi:    edi: f78b7600   ebp: f6f87f44   esp: f6f87d80
ds: 007b   es: 007b   ss: 0068
Stack: 000c f6f87f44 ffa6 f6f87f60 f6f87ec4 ce7d1d80  0002 
   f7264228 f6f87ec4 f8aafd3b f6f87f44 f78b7600  f6f87f44 f694ab80 
   f6f87dec f6f87f44 f694ab80 f6f87df0 f6f87f44 f8aafa74 000b f8ab1560 
Call Trace:
 [] atalk_recvmsg+0xca/0xdb [appletalk]
 [] __lock_atalk_dgram_sendmsg+0x1d/0x2b [appletalk]
 [] sock_sendmsg+0xce/0xe8
 [] autoremove_wake_function+0x0/0x2d
 [] lock_timer_base+0x15/0x2f
 [] setup_sigcontext+0x107/0x18e
 [] __dequeue_signal+0x151/0x15c
 [] sys_sendto+0x116/0x140
 [] do_notify_resume+0x4e4/0x5d7
 [] hrtimer_cancel+0xa/0x14
 [] sys_socketcall+0xeb/0x181
 [] sysenter_past_esp+0x56/0x79
Code: 0f b7 40 0c 8d 5c 08 0c 8b 44 24 10 66 83 78 04 00 75 06 80 78 06 00 75 
1c 8b 44 24 10 83 c0 04 e8 79 e6 ff ff 85 ff 89 44 24 18 <8b> 10 89 54 24 14 75 
26 eb 42 c6 44 24 3e 00 0f b7 87 56 01 00 


>>EIP; f8ab0c2b<=

>>edx; 01cc3280 
>>edi; f78b7600 
>>ebp; f6f87f44 
>>esp; f6f87d80 

Trace; f8aafd3b 
Trace; f8aafa74 
Trace; c021fed7 
Trace; c012d92d 
Trace; c0125380 
Trace; c010205b 
Trace; c0126258 <__dequeue_signal+151/15c>
Trace; c0220434 
Trace; c0102819 
Trace; c012fdd9 
Trace; c02217b5 
Trace; c0102c11 

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  f8ab0c00 
 <_EIP>:
Code;  f8ab0c00 
   0:   0f b7 40 0c   movzwl 0xc(%eax),%eax
Code;  f8ab0c04 
   4:   8d 5c 08 0c   lea0xc(%eax,%ecx,1),%ebx
Code;  f8ab0c08 
   8:   8b 44 24 10   mov0x10(%esp),%eax
Code;  f8ab0c0c 
   c:   66 83 78 04 00cmpw   $0x0,0x4(%eax)
Code;  f8ab0c11 
  11:   75 06 jne19 <_EIP+0x19>
Code;  f8ab0c13 
  13:   80 78 06 00   cmpb   $0x0,0x6(%eax)
Code;  f8ab0c17 
  17:   75 1c jne35 <_EIP+0x35>
Code;  f8ab0c19 
  19:   8b 44 24 10   mov0x10(%esp),%eax
Code;  f8ab0c1d 
  1d:   83 c0 04  add$0x4,%eax
Code;  f8ab0c20 
  20:   e8 79 e6 ff ffcall   e69e <_EIP+0xe69e>
Code;  f8ab0c25 
  25:   85 ff test   %edi,%edi
Code;  f8ab0c27 
  27:   89 44 24 18   mov%eax,0x18(%esp)

This decode from eip onwards should be reliable

Code;  f8ab0c2b 
 <_EIP>:
Code;  f8ab0c2b<=
   0:   8b 10 mov(%eax),%edx   <=
Code;  f8ab0c2d 
   2:   89 54 24 14   mov%edx,0x14(%esp)
Code;  f8ab0c31 
   6:   75 26 jne2e <_EIP+0x2e>
Code;  f8ab0c33 
   8:   eb 42 jmp4c <_EIP+0x4c>
Code;  f8ab0c35 
   a:   c6 44 24 3e 00movb   $0x0,0x3e(%esp)
Code;  f8ab0c3a 
   f:   0f.byte 0xf
Code;  f8ab0c3b 
  10:   b7 87 mov$0x87,%bh
Code;  f8ab0c3d 
  12:   56push   %esi

Bug#322226: [Debian QA] please review your old bug reports against CUPS

[Will Aoki]

found 36 1.2.7-4
thanks

On Sun, Jul 15, 2007 at 01:10:26PM +0300, Martin-??ric Racine wrote:
> Please review your bug report and inform us whether it still applies
> to version 1.2.7-4, as present in Debian release 4.0 (Etch), or to
> newer releases present in the testing branch.

Bug #36 is still present in 1.2.7-4.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432271: linux-image-2.6.18-4-686: BUG: unable to handle kernel NULL pointer dereference: Oops in appletalk driver

[Will Aoki]

Package: linux-image-2.6.18-4-686
Version: 2.6.18.dfsg.1-12etch2
Severity: normal

The following oops occurred earlier today on a system running Netatalk.
(Another system, a Macintosh running Netatalk on 2.6.8-3-powerpc, had no
problems at the same time.) The system this oops is from is about 2/3
upgraded to Etch; the kernel, udev, et cetera are all from etch. The
current system uptime is 15 days; before that, it ran a custom 2.6.12
kernel for more than a year without problems. This oops has not happened
before.

No mesages from the netatalk daemons were recorded in the system logs
prior to this oops.

Jul  8 11:41:48 vulture kernel: BUG: unable to handle kernel NULL pointer 
dereference at virtual a
ddress 
Jul  8 11:41:48 vulture kernel:  printing eip:
Jul  8 11:41:48 vulture kernel: f8aaac2b
Jul  8 11:41:48 vulture kernel: *pde = 
Jul  8 11:41:48 vulture kernel: Oops:  [#1]
Jul  8 11:41:48 vulture kernel: SMP
Jul  8 11:41:48 vulture kernel: Modules linked in: w83627hf hwmon_vid i2c_isa 
i2c_dev appletalk nfsd exportfs lockd nfs_acl sunrpc ipv6 xfs md_mod evdev 
intel_agp agpgart i2c_i801 i82875p_edac edac_mc i2c_core psmouse intel_rng 
pcspkr rtc serio_raw shpchp pci_hotplug st ext3 jbd mbcache dm_mirror 
dm_snapshot dm_mod ide_generic ide_cd cdrom piix e100 mii uhci_hcd e1000 
generic ehci_hcd sym53c8xx scsi_transport_spi ide_core usbcore sd_mod thermal 
processor fan 3w_9xxx scsi_mod
Jul  8 11:41:48 vulture kernel: CPU:0
Jul  8 11:41:48 vulture kernel: EIP:0060:[pg0+946994219/1070019584]Not 
tainted VLI
Jul  8 11:41:48 vulture kernel: EFLAGS: 00010286   (2.6.18-4-686 #1)
Jul  8 11:41:48 vulture kernel: EIP is at atalk_sendmsg+0x128/0x4c7 [appletalk]
Jul  8 11:41:48 vulture kernel: eax:    ebx: 001f   ecx:    
edx: 01cc3280
Jul  8 11:41:48 vulture kernel: esi:    edi: f2c85e00   ebp: f33c1f44   
esp: f33c1d80
Jul  8 11:41:48 vulture kernel: ds: 007b   es: 007b   ss: 0068
Jul  8 11:41:48 vulture kernel: Process atalkd (pid: 3013, ti=f33c 
task=f2c8a000 task.ti=f33c)
Jul  8 11:41:48 vulture kernel: Stack: 000c f33c1f44 ffa6 f33c1f60 
f33c1ec4 ea0ccc80  0002
Jul  8 11:41:48 vulture kernel:f2d59028 f33c1ec4 f8aa9d3b f33c1f44 
f2c85e00  f33c1f44 f525ab00
Jul  8 11:41:48 vulture kernel:f33c1dec f33c1f44 f525ab00 f33c1df0 
f33c1f44 f8aa9a74 000b f8aab560
Jul  8 11:41:48 vulture kernel: Call Trace:
Jul  8 11:41:48 vulture kernel:  [pg0+946990395/1070019584] 
atalk_recvmsg+0xca/0xdb [appletalk]
Jul  8 11:41:48 vulture kernel:  [pg0+946989684/1070019584] 
__lock_atalk_dgram_sendmsg+0x1d/0x2b [appletalk]
Jul  8 11:41:48 vulture kernel:  [sock_sendmsg+206/232] sock_sendmsg+0xce/0xe8
Jul  8 11:41:48 vulture kernel:  [autoremove_wake_function+0/45] 
autoremove_wake_function+0x0/0x2d 
Jul  8 11:41:48 vulture kernel:  [setup_sigcontext+263/398] 
setup_sigcontext+0x107/0x18e
Jul  8 11:41:48 vulture kernel:  [__dequeue_signal+337/348] 
__dequeue_signal+0x151/0x15c
Jul  8 11:41:48 vulture kernel:  [sys_sendto+278/320] sys_sendto+0x116/0x140
Jul  8 11:41:48 vulture kernel:  [do_notify_resume+1252/1495] 
do_notify_resume+0x4e4/0x5d7
Jul  8 11:41:48 vulture kernel:  [hrtimer_cancel+10/20] hrtimer_cancel+0xa/0x14
Jul  8 11:41:48 vulture kernel:  [timer_interrupt+105/115] 
timer_interrupt+0x69/0x73
Jul  8 11:41:48 vulture kernel:  [handle_IRQ_event+35/73] 
handle_IRQ_event+0x23/0x49
Jul  8 11:41:48 vulture kernel:  [sys_socketcall+235/385] 
sys_socketcall+0xeb/0x181
Jul  8 11:41:48 vulture kernel:  [sysenter_past_esp+86/121] 
sysenter_past_esp+0x56/0x79
Jul  8 11:41:48 vulture kernel: Code: 0f b7 40 0c 8d 5c 08 0c 8b 44 24 10 66 83 
78 04 00 75 06 80 78 06 00 75 1c 8b 44 24 10 83 c0 04 e8 79 e6 ff ff 85 ff 89 
44 24 18 <8b> 10 89 54 24 14 75 26 eb 42 c6 44 24 3e 00 0f b7 87 56 01 00
Jul  8 11:41:48 vulture kernel: EIP: [pg0+946994219/1070019584] 
atalk_sendmsg+0x128/0x4c7 [appletalk] SS:ESP 0068:f33c1d80

[EMAIL PROTECTED]:~$ dmesg | ksymoops
ksymoops 2.4.11 on i686 2.6.18-4-686.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.6.18-4-686/ (default)
 -m /boot/System.map-2.6.18-4-686 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
1151MB HIGHMEM available.
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyr

Bug#245423: /sbin is always changed directly after doing a aide --update

[Will Aoki]

On Tue, Dec 12, 2006 at 04:18:25PM +0100, Marc Haber wrote:
> After going through another update round, changing both upstream aide
> and the aide cron job, can you guys please re-try with aide 0.13 from
> Debian testing (it backports nicely if you're running stable) and
> gzip_dbout enabled?

I was unable to reproduce the problem with 0.13.1-2 on my test system.
It fixes the problem for me...

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#398017: bugs.debian.org: 'See the archived reports' doesn't work

[Will Aoki]

Package: bugs.debian.org
Severity: normal

The link to see the archived bug reports does not work - it's generated
(for exmaple) as
,
but it only works if it's manually rewritten to
,

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16.27
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#202018: hfsplus: Failure to mount hfsplus volume

[Will Aoki]

On Fri, Sep 15, 2006 at 08:38:06AM -0600, waoki wrote:
> I need to see if I still have the image I was working on (and then
> sanitize it for outside release), or try to build another image that has
> the same problem. I hope to get that done early next week.

I can't find the old image, but in the near future I'll be doing some
work on one of my old Macintoshes that need BootX to start, and at that
point I think I can generate another hfsplus disk image.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#202018: hfsplus: Failure to mount hfsplus volume

[Will Aoki]

On Fri, Sep 15, 2006 at 12:35:52PM +0200, Aur??lien G??R??ME wrote:
> On Thu, Sep 14, 2006 at 10:24:41PM +1200, Nick Phillips wrote:
> > Aur??lien G??R??ME wrote:
> > > Could you provide me a HFS+ image which fails like it is mentioned in
> > > the bug-report? If it is too big to fit in a mail sent to the Debian
> > > BTS, could you put it online somewhere?
> > 
> > I'm afraid the drive in question is no more, so I can't help. Sorry.
> 
> Thanks anyway for your reply. So, that leaves me with Will to solve
> this bug. Will, what is your status on this?

I need to see if I still have the image I was working on (and then
sanitize it for outside release), or try to build another image that has
the same problem. I hope to get that done early next week.

-- 
William Aoki KD7YAF[EMAIL PROTECTED]5-1924


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#245423: /sbin is always changed directly after doing a aide --update

[Will Aoki]

On Mon, Mar 13, 2006 at 09:13:01AM +0100, Richard van den Berg wrote:
> Last week I saw something similar on one of my systems. The problem was 
> with my aide.db.gz being corrupted (bad block on fd0). I don't think the 
> same issue applies here, but it might have to do with aide not reading 
> in the old database completely. Running a --compare manually after the 
> --update has triggered the problem would be interesting. Maybe this 
> gives us a reproducible test case without the need for an image of the 
> whole system.

It took me a while (the problem mysteriously disappeared for a while on
my machines that still use aide), but here's the output. The changes
(/var/cfengine, et cetara) are correct, but the additions are not.

Process:

$ sudo aide -u | less
[ lots of output]
$ sudo cp /var/lib/aide/aide.db{.new,}
$ sudo aide --compare --before='database_new=file:///var/lib/aide/aide.db.new'
Not enough parameters in db:143132
AIDE found differences between the two databases!!
Start timestamp: 2006-07-28 14:31:40

Summary:
  Total number of files:143529
  Added files:  402
  Removed files:0
  Changed files:14


---
Added files:
---

added:/lib/security/pam_lastlog.so
added:/lib/security/pam_listfile.so
added:/lib/security/pam_mail.so
added:/lib/security/pam_permit.so
added:/lib/security/pam_rhosts_auth.so
added:/lib/security/pam_rootok.so
added:/lib/security/pam_stress.so
added:/lib/security/pam_time.so
added:/lib/security/pam_warn.so
added:/lib/security/pam_access.so
added:/lib/security/pam_deny.so
added:/lib/security/pam_filter.so
added:/lib/security/pam_group.so
added:/lib/security/pam_limits.so
added:/lib/security/pam_nologin.so
added:/lib/security/pam_securetty.so
added:/lib/security/pam_shells.so
added:/lib/security/pam_tally.so
added:/lib/security/pam_wheel.so
added:/lib/security/pam_unix.so
added:/lib/security/pam_userdb.so
added:/lib/security/pam_motd.so
added:/lib/security/pam_mkhomedir.so
added:/lib/security/pam_issue.so
added:/lib/security/pam_unix_acct.so
added:/lib/security/pam_unix_passwd.so
added:/lib/security/pam_unix_auth.so
added:/lib/security/pam_unix_session.so
added:/lib/security/pam_krb5.so
added:/lib/security/pam_ldap.so
added:/lib/security/pam_debug.so
added:/lib/iptables/libipt_standard.so
added:/lib/iptables/libipt_tcp.so
added:/lib/iptables/libipt_udp.so
added:/lib/iptables/libipt_icmp.so
added:/lib/iptables/libipt_mac.so
added:/lib/iptables/libipt_limit.so
added:/lib/iptables/libipt_MASQUERADE.so
added:/lib/iptables/libipt_REJECT.so
added:/lib/iptables/libipt_LOG.so
added:/lib/iptables/libipt_unclean.so
added:/lib/iptables/libipt_state.so
added:/lib/iptables/libipt_multiport.so
added:/lib/iptables/libipt_tos.so
added:/lib/iptables/libipt_TOS.so
added:/lib/iptables/libipt_mark.so
added:/lib/iptables/libipt_MARK.so
added:/lib/iptables/libipt_owner.so
added:/lib/iptables/libipt_SNAT.so
added:/lib/iptables/libipt_DNAT.so
added:/lib/iptables/libipt_IPV4OPTSSTRIP.so
added:/lib/iptables/libipt_REDIRECT.so
added:/lib/iptables/libipt_MIRROR.so
added:/lib/iptables/libipt_SAME.so
added:/lib/iptables/libipt_TCPMSS.so
added:/lib/iptables/libipt_TTL.so
added:/lib/iptables/libipt_ULOG.so
added:/lib/iptables/libipt_ah.so
added:/lib/iptables/libipt_esp.so
added:/lib/iptables/libipt_tcpmss.so
added:/lib/iptables/libipt_ttl.so
added:/lib/iptables/libipt_ipv4options.so
added:/lib/iptables/libipt_NETMAP.so
added:/lib/iptables/libip6t_ipv6header.so
added:/lib/iptables/libipt_length.so
added:/lib/iptables/libipt_mport.so
added:/lib/iptables/libipt_nth.so
added:/lib/iptables/libipt_pkttype.so
added:/lib/iptables/libipt_pool.so
added:/lib/iptables/libipt_POOL.so
added:/lib/iptables/libipt_psd.so
added:/lib/iptables/libipt_quota.so
added:/lib/iptables/libipt_random.so
added:/lib/iptables/libipt_realm.so
added:/lib/iptables/libipt_time.so
added:/lib/iptables/libip6t_tcp.so
added:/lib/iptables/libip6t_udp.so
added:/lib/iptables/libip6t_icmpv6.so
added:/lib/iptables/libip6t_standard.so
added:/lib/iptables/libip6t_MARK.so
added:/lib/iptables/libip6t_mark.so
added:/lib/iptables/libip6t_LOG.so
added:/lib/iptables/libip6t_REJECT.so
added:/lib/iptables/libip6t_multiport.so
added:/lib/iptables/libip6t_length.so
added:/lib/iptables/libip6t_owner.so
added:/lib/iptables/libip6t_limit.so
added:/lib/iptables/libip6t_mac.so
added:/lib/iptables/libipt_CONNMARK.so
added:/lib/iptables/libip6t_condition.so
added:/lib/iptables/libipt_dscp.so
added:/lib/iptables/libipt_connlimit.so
added:/lib/iptables/libipt_ecn.so
added:/lib/iptables/libipt_helper.so
added:/lib/iptables/libipt_iprange.so
added:/lib/iptables/libipt_physdev.so
added:/lib/iptables/libipt_DSCP.so
added:/lib/iptables/libipt_ECN.so
added:/lib/iptables/libipt_rpc.so
added:/lib/iptables/libipt_sctp.so
added:/lib/iptables/libipt_CLASSIFY.so
added:/lib/iptables/libipt_NOTRACK.so
added:/lib/iptables/libipt_connmark.

Bug#376070: nagios-common: init script sporadically fails to see existing nagios process

[Will Aoki]

Package: nagios-common
Version: 2:1.3-cvs.20050402-2.sarge.2
Severity: normal

On occasion, the /etc/init.d/nagios script, when told to restart Nagios,
does not stop the old Nagios process before starting another one. This
leaves two Nagios processes running. This may be related to #294178,
although the fix described therein seems to be present in the version I
have installed.

Transcripts:

  # A process listing from a few days before that happened to still be
  # in my terminal window:

  $ ps auxw | grep nag
  nagios   16068  1.0  1.5  5820 2972 ?SNs  15:05   0:00 
/usr/sbin/nagios /etc/nagios/nagios.cfg
  waoki16071  0.0  0.2  1548  472 pts/3R+   15:05   0:00 grep nag

  # The upgrade was managed by cfengine, but the same problem sometimes
  # happens when I invoke '/etc/init.d/nagios restart' from the command
  # line. Here's the upgrade transcript:

   (Reading database ... 17717 files and directories currently installed.)
   Preparing to replace nagios-text 2:1.3-cvs.20050402-2.sarge.1 (using 
.../nagios-text_2%3a1.3-cvs.20050402-2.sarge.2_i386.deb) ...
   Unpacking replacement nagios-text ...
   Preparing to replace nagios-common 2:1.3-cvs.20050402-2.sarge.1 (using 
.../nagios-common_2%3a1.3-cvs.20050402-2.sarge.2_all.deb) ...
   Stopping nagios: nagios.
   Unpacking replacement nagios-common ...
   Setting up nagios-common (1.3-cvs.20050402-2.sarge.2) ...
   Not setting blank password for nagiosadmin
   Starting nagios: nagios.
   Setting up nagios-text (1.3-cvs.20050402-2.sarge.2) ...

  # This is a process listing from after the upgrade. Note that 16068 is
  # still running.

  $ ps auxw | grep nag
  nagios   16068  0.1  1.5  5820 3000 ?SNs  May15  14:13 
/usr/sbin/nagios /etc/nagios/nagios.cfg
  nagios6791  0.1  1.5  5820 2992 ?SNs  23:03   0:02 
/usr/sbin/nagios /etc/nagios/nagios.cfg
  waoki16578  0.0  0.2  1548  476 pts/3S+   23:39   0:00 grep nag



Once two Nagios processes are running, it's hard to make 'em both die.
The newer process, 6791, wouldn't respond to anything but kill -9.

The problem's a bit difficult to reproduce, but it's happened frequently
enough in the past that I've taken to stopping Nagios, checking that all
'nagios' processes are dead, and only then starting it, instead of using
'/etc/init.d/nagios restart'.


(I wrote up this bug report about a month ago, but didn't finish and
send it until now.)

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-3-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages nagios-common depends on:
ii  adduser 3.63 Add and remove users and groups
ii  apache [htt 1.3.33-6sarge1   versatile, high-performance HTTP s
ii  coreutils [ 5.2.1-2  The GNU core utilities
ii  debconf [de 1.4.30.13Debian configuration management sy
ii  fileutils   5.2.1-2  The GNU file management utilities 
ii  mailx   1:8.1.2-0.20040524cvs-4  A simple mail user agent
ii  nagios-plug 1.4-6Plugins for the nagios network mon
ii  nagios-text 2:1.3-cvs.20050402-2.sarge.2 A host/service/network monitoring 

-- debconf information:
  nagios/wwwsuid: true
  nagios/upgradefromnetsaint:
* nagios/configapache: None


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369044: ethereal: Resizing columns changes the currently-selected packet

[Will Aoki]

Package: ethereal
Version: 0.10.10-2sarge5
Severity: minor

While working with a large capture, I noticed that when I adjust column
widths in the packet list, Ethereal selects the top packet visible in
list, forgetting the one I've currently got selected. For example, I
currently have packets 32066 through 32078 visible in my window, with
32070 selected. When I adjust the relative widths of the Time and Source
columns, Ethereal selects 32066.

This behavior is unexpected and confusing. I'd normally expect the
program to keep my current selection.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages ethereal depends on:
ii  ethereal-common   0.10.10-2sarge5network traffic analyser (common f
ii  libadns1  1.0-8.2Asynchronous-capable DNS client li
ii  libatk1.0-0   1.8.0-4The ATK accessibility toolkit
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii  libcomerr21.37-2sarge1   common error description library
ii  libglib2.0-0  2.6.4-1The GLib library of C routines
ii  libgtk2.0-0   2.6.4-3.1  The GTK+ graphical user interface 
ii  libkrb53  1.3.6-2sarge2  MIT Kerberos runtime libraries
ii  libpango1.0-0 1.8.1-1Layout and rendering of internatio
ii  libpcap0.80.8.3-5System interface for user-level pa
ii  libpcre3  4.5-1.2sarge1  Perl 5 Compatible Regular Expressi
ii  zlib1g1:1.2.2-4.sarge.2  compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]