Bug#759219: bash-completion: Add mts to known file extensions for mplayer

2014-08-25 Thread Chris Reeves
Package: bash-completion
Version: 1:2.1-4
Severity: wishlist

Dear Maintainer,

When completing the command line for a call to mplayer, bash does not complete
for files with the mts (or MTS) filename extension. MTS is a file extension
for an AVCHD (Advanced Video Coding High Definition) video clip format for
high-definition video, and is used by some Sony and Panasonic video cameras.

Thanks.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash-completion depends on:
ii  bash  4.3-8
ii  dpkg  1.17.10

bash-completion recommends no packages.

bash-completion 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#668995: Fix the fix for the way the permissions are set in /var/spool/sympa and /var/lib/sympa

2012-04-16 Thread Chris Reeves
Package: sympa
Version: 6.1.9-chris3
Severity: important
Tags: patch


The fix for bug #630384 also changed the way ownership of these directories is 
set.
While the find command used for changing permissions is fine, the command used 
to
change ownerships is missing essential parenthesis. This omission results in the
ownership of /var/spool/sympa and /var/lib/sympa not actually being set, causing
various errors when sympa is started and package installation to fail.

A patch which fixes this is below:

--- sympa-6.1.7~dfsg/debian/sympa.postinst  2011-12-04 17:31:04.0 
+
+++ sympa-6.1.9/debian/sympa.postinst   2012-04-16 10:35:11.0 +0100
@@ -288,7 +288,7 @@
 # It's better to search files and directories with wrong owner/group and fix
 # them instead of recursively doing it, even if it's not needed (see #630384)
 find /var/spool/sympa /var/lib/sympa \
-   -not -user sympa -or -not -group sympa \
+   \( -not -user sympa -or -not -group sympa \) \
-exec chown sympa:sympa {} \;
 
 # Fix permissions on MTA tools wrappers


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

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sympa depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  dbconfig-common  1.8.46+squeeze.0common framework for packaging dat
ii  debconf [debconf 1.5.36.1Debian configuration management sy
ii  exim4-daemon-lig 4.72-6+squeeze2 lightweight Exim MTA (v4) daemon
ii  libarchive-zip-p 1.30-3  Perl module for manipulation of ZI
ii  libc62.11.3-3Embedded GNU C Library: Shared lib
ii  libcgi-fast-perl 5.10.1-17squeeze3   CGI::Fast Perl module
ii  libdbd-mysql-per 4.016-1 Perl5 database interface to the My
ii  libdbd-pg-perl   2.17.1-2+squeeze1   Perl DBI driver for the PostgreSQL
ii  libdbd-sqlite3-p 1.29-3  Perl DBI driver with a self-contai
ii  libdbi-perl  1.612-1 Perl Database Interface (DBI)
ii  libfcgi-perl 0.71-1+squeeze1 helper module for FastCGI
ii  libfile-copy-rec 0.38-1  Perl extension for recursively cop
ii  libhtml-format-p 2.04-2  format HTML syntax trees into text
ii  libhtml-stripscr 1.03-1  module to filter scripts out of HT
ii  libhtml-tree-per 3.23-2  Perl module to represent and creat
ii  libintl-perl 1.20-1  Uniforum message translations syst
ii  libio-stringy-pe 2.110-4 Perl modules for IO from scalars a
ii  libmailtools-per 2.06-1  Manipulate email in perl programs
ii  libmime-charset- 1.008-1 Perl module for MIME character set
ii  libmime-encwords 1.012-1 Perl interface to deal with RFC 20
ii  libmime-lite-htm 1.23-1  Transform HTML page into MIME emai
ii  libmime-tools-pe 5.428-1 Perl5 modules for MIME-compliant m
ii  libmsgcat-perl   1.03-5  Locale::Msgcat perl module
ii  libnet-ldap-perl 1:0.4001-2  client interface to LDAP servers
ii  libnet-netmask-p 1.9015-4parse, manipulate and lookup IP ne
ii  libregexp-common 2010010201-1module with common regular express
ii  libtemplate-perl 2.22-0.1template processing system written
ii  libterm-progress 2.09-6  Perl module to print a progress ba
ii  libunicode-lineb 0.0.20110501-1.squeeze1 UAX #14 Unicode Line Breaking Algo
ii  libxml-libxml-pe 1.70.ds-1   Perl interface to the libxml2 libr
ii  lsb-base 3.2-23.2squeeze1Linux Standard Base 3.2 init scrip
ii  mhonarc  2.6.16-1Mail to HTML converter
ii  perl 5.10.1-17squeeze3   Larry Wall's Practical Extraction 
ii  perl-modules [li 5.10.1-17squeeze3   Core Perl modules
ii  rsyslog [system- 4.6.4-2 enhanced multi-threaded syslogd
ii  sqlite3  3.7.3-1 A command line interface for SQLit

Versions of packages sympa recommends:
ii  ca-certificates20090814+nmu3squeeze1 Common CA certificates
pn  doc-base   none(no description available)
pn  libapache2-mod-fcg none(no description available)
pn  libcrypt-ciphersab none(no description available)
pn  libfile-nfslock-pe none(no description available)
ii  libio-socket-ssl-p 1.33-1+squeeze1   Perl module implementing object or
pn  libmail-dkim-perl  none(no description available)
pn  

Bug#626294: Updated upstream patch upstream ticket #3288

2011-09-17 Thread Chris Reeves

There is an updated patch for upstream bug #3288, which corresponds to bug
#584138. I have successfully applied this patch to mutt (1.5.20-9+squeeze1) to
fix my segfault issues.

Also CCing bug #626294 as this may affect the proposed patch for that bug.

Regards,
Chris



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



Bug#611517: xserve-xorg-video-intel: X crashes with 845G chipset

2011-02-02 Thread Chris Reeves
Package: xserver-xorg-video-intel
Version: 2:2.13.0-5
Severity: normal


Also experiencing this issue here. X locks up within minutes (cursor
still moves, but clicking has no effect and the screen is not redrawn).

A reboot is required before X can be used again.

This is a fresh install of the base system plus a few more packages.
X-related packages are limited to xserver-xorg, fluxbox, xterm and gdm
(plus dependencies).

The last few lines of dmesg are:
[  346.56] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... 
GPU hung
[  346.500015] render error detected, EIR: 0x
[  346.500027] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns 
-5 (awaiting 2375 at 2374)

The last few lines of syslog are:
Feb  2 20:20:31 voyager acpid: client 871[0:0] has disconnected
Feb  2 20:20:32 voyager acpid: client connected from 1100[0:0]
Feb  2 20:20:32 voyager acpid: 1 client rule loaded
Feb  2 20:20:42 voyager acpid: client 1100[0:0] has disconnected
Feb  2 20:21:21 voyager acpid: client connected from 1100[0:0]
Feb  2 20:21:21 voyager acpid: 1 client rule loaded
Feb  2 20:21:25 voyager acpid: client 1100[0:0] has disconnected
Feb  2 20:21:30 voyager acpid: client connected from 1146[0:0]
Feb  2 20:21:30 voyager acpid: 1 client rule loaded
Feb  2 20:21:35 voyager acpid: client 1146[0:0] has disconnected
Feb  2 20:22:02 voyager acpid: client connected from 1146[0:0]
Feb  2 20:22:02 voyager acpid: 1 client rule loaded
Feb  2 20:22:07 voyager acpid: client 1146[0:0] has disconnected
Feb  2 20:22:16 voyager acpid: client connected from 1182[0:0]
Feb  2 20:22:16 voyager acpid: 1 client rule loaded
Feb  2 20:23:54 voyager kernel: [  346.56] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Feb  2 20:23:54 voyager kernel: [  346.500015] render error detected, EIR: 
0x
Feb  2 20:23:54 voyager kernel: [  346.500027] [drm:i915_do_wait_request] 
*ERROR* i915_do_wait_request returns -5 (awaiting 2375 at 2374)
Feb  2 20:23:59 voyager acpid: client 1182[0:0] has disconnected

The contents of /sys/kernel/debug/dri/0/i915_error_state:
Time: 1296678234 s 865512 us
EIR: 0x
  PGTBL_ER: 0x
  INSTPM: 0x
  IPEIR: 0x
  IPEHR: 0x01e204e9
  INSTDONE: 0x01c1
  ACTHD: 0x01504030



-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Feb  2 19:56 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1733468 Jan 12 03:50 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE 
Chipset Integrated Graphics Device (rev 03)

/etc/X11/xorg.conf does not exist.

Kernel version (/proc/version):
Linux version 2.6.32-5-686 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 04:01:41 UTC 2011

Xorg X server log files on system:
-rw-r--r-- 1 root root 30162 Feb  2 20:23 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32.28-dsa-ia32 i686 Debian
Current Operating System: Linux voyager 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 
UTC 2011 i686
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-686 
root=UUID=b6f0a7c5-9ada-475a-bfac-8f99074f8a26 ro quiet
Build Date: 12 January 2011  03:44:48AM
xorg-server 2:1.7.7-11 (Cyril Brulebois k...@debian.org) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Wed Feb  2 20:22:16 2011
(==) Using system config directory /usr/share/X11/xorg.conf.d
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |--Screen Default Screen Section (0)
(**) |   |--Monitor default monitor
(==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/misc does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/Type1 does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi does not exist.

Bug#501690: postgresql-8.3: PostgreSQL server failed to start on upgrade

2008-10-10 Thread Chris Reeves

I've had the same thing happen on two systems. reportbug reports the same on
both systems except for:
  APT policy: (500, 'testing')
  Kernel: Linux 2.6.25-2-686 (SMP w/4 CPU cores)

In both cases I simply restarted PostgreSQL manually:
/etc/init.d/postgresql-8.3 start
and all was fine.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages postgresql-8.3 depends on:
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libcomerr21.41.0-3   common error description library
ii  libkrb53  1.6.dfsg.4~beta1-4 MIT Kerberos runtime libraries
ii  libldap-2.4-2 2.4.10-3   OpenLDAP libraries
ii  libpam0g  1.0.1-4Pluggable Authentication Modules l
ii  libpq58.3.4-1PostgreSQL C client library
ii  libssl0.9.8   0.9.8g-13  SSL shared libraries
ii  libxml2   2.6.32.dfsg-4  GNOME XML library
ii  postgresql-client-8.3 8.3.4-1front-end programs for PostgreSQL 
ii  postgresql-common 90 PostgreSQL database-cluster manage
ii  tzdata2008e-3time zone and daylight-saving time

postgresql-8.3 recommends no packages.

Versions of packages postgresql-8.3 suggests:
ii  pidentd [ident-server]  3.0.19.ds1-4 TCP/IP IDENT protocol server with 

-- no debconf information




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



Bug#441975: [pkg-nvidia-devel] Bug#441975: nvidia-glx should only provide the TLS version

2008-07-24 Thread Chris Reeves
On Thu, Jul 24, 2008 at 08:48:07AM -0700, Randall Donald wrote:
 
 I was working on this yesterday based on your email. Just to confirm,
 will providing TLS-enabled libnvidia-tls in both /usr/lib
 and /usr/lib/tls work?

It depends upon what exactly your definition of work is. It works on my
lenny system (glibc 2.7, kernel 2.6.25) in as much as having the /usr/lib/tls
version of the library in both /usr/lib/tls and /usr/lib has had no adverse
effect on my running system (whether I boot with /etc/ld.so.nohwcap present or
not) and means that perl -e 'use Qt' does not segfault when
/etc/ld.so.nohwcap is present (which should prevent debconf from crashing when
the kde frontend is used).

As I said in my previous mail, IMHO there is no reason for both versions of
this library to be accessible by a running system at any one time (the
libraries are for use with different glibc and/or kernel versions). Therefore
/usr/lib and /usr/lib/tls should both contain the same version.

The question remains as to whether we wish to continue supporting nvidia-glx
users who use an unpatched kernel 2.4 (which your README.Debian implies are
the target users of the 'non-tls' version). If that is the case then we should
install both versions into /usr/lib/nvidia and continue to use USE_TLS to
switch between the versions. If not, then the one-line change that you made to
debian/rules in r432 should be sufficient to fix things on the nvidia-glx side
of things. Of course, libc6 would still need a Conflicts: or some other
modification.

I hope this is confirmation enough. My more reserved language is simply
because I have a limited ability to test this (the system that this applies to
is a production system).

Cheers,
Chris



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



Bug#441975: nvidia-glx should only provide the TLS version

2008-07-23 Thread Chris Reeves
On Fri, Feb 15, 2008 at 18:59:30 +0100, Aurelian Jarno wrote:
 
 severity 441975 serious
 
 On Sat, Jan 19, 2008 at 12:57:42AM +0100, Aurelien Jarno wrote:
  
  FYI the problem is that /etc/ld.so.nohwcaps disable all optimized
  libraries and use the one from /usr/lib. NVidia had the idea to provide
  a TLS version (in /usr/lib/tls) and a non-TLS version (in /usr/lib) of
  their library. Disabling optimized libraries means that the non-TLS
  version of the library is used. However, their code chose between TLS
  and non-TLS code on a different way (a test code), which always succeed
  on recent systems with NPTL library. This lead to a mix of TLS and
  non-TLS code, leading to a crash.
  
  I will workaround to the glibc to also use tls/ directory even when
  optimized libraries are disabled, as TLS is alway available in lenny.
 
 This workaround causes problems when upgrading from etch to lenny, so it
 will be removed in the next upload. As a consequence, this bug really
 has to be fixed, so I am upgrading it to serious.

I have been able to reproduce this on a lenny machine with a 2.6.25-2 kernel.
In order to do so one must use an nVidia graphics card with the nVidia binary
driver and /etc/ld.so.nohwcaps must exist. The test (as described in a
previous message) is that perl -e 'use Qt' will segfault.

This bug will affect any user of the nvidia-glx package who has their debconf
frontend set to kde (or similar) and tries to upgrade a package which makes
use of /etc/ld.so.nohwcaps (e.g. libc6). These users will be affected
irrespective of whether nvidia-graphics-drivers makes it into lenny or not.


Aurelian is largely correct with this. The nVidia installer comes with two
different copies of libnvidia-tls.so.version inside the installer package.
 - According to the nvidia-installer docs, the version in
   package-dir/usr/lib is for glibc = 2.2, while the version in
   package-dir/usr/lib/tls is for glibc = 2.3. 
 - According to the README.Debian for nvidia-glx, however, the differing
   versions are for 2.4 and 2.6 kernels (presumably on the assumption that
   NPTL is implemented in the latter and not in the former).
Whichever of these interpretations is actually correct, the same version of
the library should be installed into both /usr/lib and /usr/lib/tls so that
the presence of /etc/ld.so.nohwcap does not affect which version of the
library is used (which it shouldn't).

On the basis of the nVidia docs it might seem reasonable to only ship the
second version, since lenny is guaranteed to come with glibc = 2.3. In this
case we only require a one-line change to debian/rules to get things to work
(although the USE_TLS flag would become redundant and so we could also remove
related code and documentation).

On the other hand, if Randall's README.Debian is the more accurate, we might
break things for some users with older kernels. In this case it would take a
few more changes to get things to work (keep both versions of libnvidia-tls in
/usr/lib/nvidia and modify the init scripts to symlink both /usr/lib and
/usr/lib/tls to the same version).

My vote would be for the second option. It would be useful if people could
express their preferences so that I can produce a patch for the preferred
option. This would fix the nvidia-glx package, but does *not* fix the bug
completely.


As I said earlier, this bug will affect any of the users that I have
previously described, irrespective of whether an updated package makes it into
lenny - the presence/use of an old version of nvidia-glx will trigger this
bug. In order to actually fix the bug, nvidia-glx must be upgraded *before*
libc6 (or any other /etc/ld.so.nohwcap-using package).

My thoughts on this would be to make affected packages (e.g. libc6) Conflict
with nvidia-glx ( fixed-version). I'm no expert on how Debian/apt resolves
dependencies, so I'm not 100% sure whether this will result in:
 - removal of nvidia-glx;
 - no upgrade of affected packages;
 - or upgrade of nvidia-glx before affected packages (the desired result).
I'm also unsure of the politics of getting the affected packages to make the
required change, especially considering that they are probably frozen (e.g.
libc6).

Your thoughts and input would be much appreciated.

Cheers,
Chris



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