Bug#942786: py.test fails to run

[Anders Hammarquist]

Package: python-pytest
Version: 4.6.6-1
Severity: grave

Attempting to run py.test fails with the following traceback:
Traceback (most recent call last):
  File "/usr/bin/py.test", line 6, in 
from pkg_resources import load_entry_point
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
3098, in 
@_call_aside
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
3082, in _call_aside
f(*args, **kwargs)
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
3111, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
575, in _build_master
return cls._build_from_requirements(__requires__)
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
588, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
  File 
"/home/iko/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
777, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'configparser>=3.5' distribution was 
not found and is required by importlib-metadata


Note that python-configparser of what should be a suitable version is installed 
(and imports just fine manually):

: luggage%; aptitude show python-configparser
Package: python-configparser 
Version: 3.5.0b2-3
State: installed
Automatically installed: yes
Priority: optional
Section: python
Maintainer: Agustin Henze 
Architecture: all
Uncompressed Size: 412 k
Depends: python:any (< 2.8), python:any (>= 2.7~), libjs-sphinxdoc (>= 1.0)
Description: backport of the enhanced config parser introduced in Python 3.2 - 
PyPy
 The ancient ConfigParser module available in the standard library 2.x has seen 
a major update in Python 3.2. This is a
 backport of those changes so that they can be used directly in Python 2.7. 
 
 This package contains Python 2.7 module.
Homepage: https://bitbucket.org/ambv/configparser

python-pytest 3.10.1-2 (from testing) works.

Bug#805167: rpcbind: Regression: must restart rpc bind to run ypbind (nis)

[Anders Hammarquist]

In a message of Wed, 25 May 2016 20:24:41 +0200, Michael Biebl writes:
>> Restarting rpc bind gets me back to restart nis successfull.
>> 
>> # service rpcbind restart
>> # service nis restart
>> 
>> Reverting to rpcbind 0.2.1-6.1 solves the problem. Please notice
>> that this happens only on systemd machines. Running sysvinit doesn't
>> show this behaviour.
>
>Maybe the rpcbind.socket is simply not up yet.

>From what I found, this was not the case. The problem, as I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805167#54
is that the distributed rpcbind.socket only listens on unix-domain
sockets, and nis talks udp, and thus won't trigger starting rpcbind 
proper.

/Anders

Bug#817195: xserver-xorg-video-intel: xserver hangs when unplugging VGA external display

[Anders Hammarquist]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20160218-1
Severity: normal

If an external display has been active on the VGA port, the
X server switches the display to a text console when the VGA
cable is unplugged, and trying to return (with Alt+Fnn) to
the X server vt hangs the console. Alt-Sysreq-K will successfully
kill the X-server (and start another working one from gdm3). This
happens irrespective of if the external display is actually in use
when the cable is unplugged or not. (e.g. xrandr --output VGA1 --off
before unplugging does not help) However, if the VGA cable has just
been plugged in, but not used to display (Xorg?) video, nothing
untoward happens when unplugging.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct  1  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  9 11:54 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1435 Oct  4  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"

Option  "XkbKeycodes"  "xfree86(thinkpadz60)+aliases(qwerty)"
Option  "XkbTypes" "complete"
Option  "XkbCompat""complete"
Option  "XkbSymbols"   
"pc+us+inet(media_nav_acpi_common)+se:2+group(lctrl_lshift_toggle)+private/modkeys+compose(rctrl)"
Option  "XkbGeometry"  "thinkpad(intl)"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection

Section "Device"
Identifier  "Configured Video Device"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
SubSection "Display"
Virtual 4096 4096
EndSubSection
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection

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

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1

Kernel version (/proc/version):
---
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160121 (Debian 5.3.1-7) ) #1 SMP Debian 4.3.5-1 (2016-02-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 28033 Aug 30  2010 /var/log/Xorg.20.log
-rw-r--r-- 1 root root 26944 Feb  8  2015 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 18924 Feb 18 16:52 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[17.918] 
X.Org X Server 1.17.3
Release Date: 2015-10-26
[17.918] X Protocol Version 11, Revision 0
[17.918] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
[17.918] Current Operating System: Linux luggage 4.3.0-1-amd64 #1 SMP 
Debian 4.3.3-7 (2016-01-19) x86_64
[17.918] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 
root=/dev/mapper/vg0-root ro usbcore.autosuspend=1
[17.918] Build Date: 27 October 2015  11:29:29PM
[17.918] xorg-server 2:1.17.3-2 (http://www.debian.org/support) 
[17.918] Current version of pixman: 0.33.6
[17.918]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[17.918] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[17.918] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb  6 10:44:44 
2016
[17.918] (==) Using config file: "/etc/X11/xorg.conf"
[17.918] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[17.920] (==) No Layout section.  Using the first Screen section.
[17.920] (**) |-->Screen "Default Screen" (0)
[17.920] (**) |   |-->Monitor "Configured Monitor"
[17.921] (==) No device specified for screen "Default Screen".
 

Bug#805167: suggested rpcbind.socket

[Anders Hammarquist]

[didn't think to subscribe to this bug, so I didn't see this until now]

On Thu, 24 Dec 2015 10:57:02 +0100 Laurent Bigonville  wrote:
> > nis can't be the only rpc service that talks to rpcbind over inet rather
> > than unix sockets, and custom rpc services are probably more likely
> > to use inet. The path of least surprise is clearly to start rpcbind
> > on inet socket access as well.
> >
> > You could argue that it should only start on access from localhost,
> > unfortunately binding the loopback address from systemd prevents
> > rpcbind from receiving remote calls, so that doesn't work.
> >
> > Therefore I propose /lib/systemd/system/rpcbind.socket be changed as
> > follows:
> >
> > - --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14
> 20:19:36.018585993 +0100
> > +++ /lib/systemd/system/rpcbind.socket 2015-12-14 20:14:32.905673475
> +0100
> > @@ -3,6 +3,11 @@
> >
> > [Socket]
> > ListenStream=/run/rpcbind.sock
> > +ListenStream=[::]:111
> > +ListenStream=0.0.0.0:111
> > +ListenDatagram=[::]:111
> > +ListenDatagram=0.0.0.0:111
> > +BindIPv6Only=ipv6-only
> >
> > [Install]
> > WantedBy=sockets.target
>
> Has this been tested? I actually don't think this is enough, the code
> that manage the fd passed by systemd should also be adjusted. Not 100%
> sure, but I'm afraid that if the activation is done by the inet socket,
> the unix one will not work (and the opposite)

Yes, I'm running it on my nis clients, and I haven't seen any adverse
effects. I suppose that clients trying to connect to the unix socket
fall back to tcp or udp if it fails, but I think I checked with rpcinfo
that I could talk to rpcbind over all transports. I can check again to
be certain (though not right now).

/Anders

Bug#816663: linux-image-4.4.0-1-amd64: fails to suspend. xfs filesystem blocks suspend.

[Anders Hammarquist]

Package: src:linux
Version: 4.4.2-3
Severity: important

xfs updates in 4.4 cause suspend to fail. See discussion at
http://www.linuxquestions.org/questions/slackware-14/unable-to-suspend-or-hibernate-with-a-4-4-0-kernel-4175563710/

-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160205 (Debian 5.3.1-8) ) #1 SMP Debian 4.4.2-3 (2016-02-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 root=/dev/mapper/vg0-root ro 
usbcore.autosuspend=1

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[ 2922.813564]  81585bc1  a040b2cf 
8802311c6740
[ 2922.813573] Call Trace:
[ 2922.813580]  [] ? schedule+0x31/0x80
[ 2922.813639]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.813648]  [] ? __schedule+0x2e8/0x900
[ 2922.813707]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.813715]  [] ? kthread+0xcd/0xf0
[ 2922.813723]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813729]  [] ? ret_from_fork+0x3f/0x70
[ 2922.813737]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813743] xfsaild/dm-10   S 0001 0   856  2 0x
[ 2922.813751]  880231674200 8800ba68ef40 880231518000 
880231517ec8
[ 2922.813759]  880231674200  88022e368c40 

[ 2922.813767]  81585bc1  a040b2cf 
880231674200
[ 2922.813775] Call Trace:
[ 2922.813782]  [] ? schedule+0x31/0x80
[ 2922.813842]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.813850]  [] ? __schedule+0x2e8/0x900
[ 2922.813910]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.813917]  [] ? kthread+0xcd/0xf0
[ 2922.813925]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813931]  [] ? ret_from_fork+0x3f/0x70
[ 2922.813939]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.813944] xfsaild/dm-12   S 0001 0   865  2 0x
[ 2922.813952]  8800ba68ef40 8800ba68e340 8800ba624000 
8800ba623ec8
[ 2922.813960]  8800ba68ef40  880231501840 

[ 2922.813968]  81585bc1  a040b2cf 
8800ba68ef40
[ 2922.813977] Call Trace:
[ 2922.813985]  [] ? schedule+0x31/0x80
[ 2922.814044]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814052]  [] ? __schedule+0x2e8/0x900
[ 2922.814112]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814119]  [] ? kthread+0xcd/0xf0
[ 2922.814127]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814133]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814141]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814146] xfsaild/dm-4S 0001 0   866  2 0x
[ 2922.814153]  8800ba68e340 8800ba62c540 8802312d 
8802312cfec8
[ 2922.814161]  8800ba68e340  8800ba2b0cc0 

[ 2922.814169]  81585bc1  a040b2cf 
8800ba68e340
[ 2922.814178] Call Trace:
[ 2922.814185]  [] ? schedule+0x31/0x80
[ 2922.814244]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814252]  [] ? __schedule+0x2e8/0x900
[ 2922.814312]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814320]  [] ? kthread+0xcd/0xf0
[ 2922.814328]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814334]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814342]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814348] xfsaild/dm-14   S 0001 0   914  2 0x
[ 2922.814356]  8800ba62c540 88023128b180 8800ba56 
8800ba55fec8
[ 2922.814364]  8800ba62c540  880231534b40 

[ 2922.814372]  81585bc1  a040b2cf 
8800ba62c540
[ 2922.814380] Call Trace:
[ 2922.814387]  [] ? schedule+0x31/0x80
[ 2922.814446]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814454]  [] ? __schedule+0x2e8/0x900
[ 2922.814514]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814522]  [] ? kthread+0xcd/0xf0
[ 2922.814530]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814536]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814544]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814548] xfsaild/dm-6S 88023bd15900 0   915  2 0x
[ 2922.814556]  88023128b180 880232234d80 880231144000 
880231143ec8
[ 2922.814564]  88023128b180  880231534bc0 
881f9800
[ 2922.814572]  81585bc1  a040b2cf 
88023128b180
[ 2922.814580] Call Trace:
[ 2922.814588]  [] ? schedule+0x31/0x80
[ 2922.814647]  [] ? xfsaild+0x5af/0x600 [xfs]
[ 2922.814708]  [] ? xfs_trans_ail_cursor_first+0x90/0x90 
[xfs]
[ 2922.814716]  [] ? kthread+0xcd/0xf0
[ 2922.814723]  [] ? kthread_create_on_node+0x190/0x190
[ 2922.814730]  [] ? ret_from_fork+0x3f/0x70
[ 2922.814737]  [] ? kthread_create_on_node+0x190/0x190

[ 2922.814786] Restarting kernel threads ... done.
[ 2922.815680] Restarting tasks ... done.
[ 2922.870902] video LNXVIDEO:00: Restoring backlight state
[ 

Bug#805167: suggested rpcbind.socket

[Anders Hammarquist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nis can't be the only rpc service that talks to rpcbind over inet rather
than unix sockets, and custom rpc services are probably more likely
to use inet. The path of least surprise is clearly to start rpcbind
on inet socket access as well.

You could argue that it should only start on access from localhost,
unfortunately binding the loopback address from systemd prevents
rpcbind from receiving remote calls, so that doesn't work.

Therefore I propose /lib/systemd/system/rpcbind.socket be changed as
follows:

- --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14 20:19:36.018585993 
+0100
+++ /lib/systemd/system/rpcbind.socket  2015-12-14 20:14:32.905673475 +0100
@@ -3,6 +3,11 @@
 
 [Socket]
 ListenStream=/run/rpcbind.sock
+ListenStream=[::]:111
+ListenStream=0.0.0.0:111
+ListenDatagram=[::]:111
+ListenDatagram=0.0.0.0:111
+BindIPv6Only=ipv6-only
 
 [Install]
 WantedBy=sockets.target

/Anders
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWbxcvAAoJENr9WVlAi3ub8cMQAKlHfLV6iR9IpirlvJZLFy2z
dFyI/v+a05u7Dre/2ae22E1fruRuNttUZDddVujR52r6jqHdDPERUt5eAUmhVAd2
iV54+7dUhSos6vBdyk674Mdd14EZl05ur8a0+y6s42MyMVyJusUw8JRMxDZ3obOK
rF8w5184TrnCTqSgKCx4ApmOQJ7yP9EMHTgThOqx/1Mu9oK+3eviaF1pko2S+3O/
1XhonndOeKgMeLznqzZOIwdx2QN9wwpTAxU/of1VE6Zgm0PKHjGmGZNxnox4A2VS
1uAeNdTPPC41voO4aw7xJnhn7rHS9I/ZGcsmJHds2+TlMb0wSLL3LGC5BwTLbSWA
gCUo0JuSGtOF/gBhFLzsBv9Z1lNnAmwd1DXKEBEe3vyJvlG4sZo2xqdzhreERPwz
hT2HtGayow8QaH0yC12zHVtciHo8GcQ06+0yUSh9poDooux7dWfdleQlB9sBD7Kq
gw228wBu3ClPX20tWxb9Cu1GPvW8rKr08L41ohgH8mFVGLO04GeWHREQgH9BDH82
ad6zfnCwNuqePb1gZkj4TeZG5LKanH8c2gLww1RBMf9v+MsMTDbXNPkg7CrvuXHc
czyiGWKzeiy5gW5Z0htm2VY/3gaf8+zIGjb3ufbNhy/u3/HbqukTOq+e1UKhxtvh
lufmo+eSfRkpnft+2GvJ
=Apc5
-END PGP SIGNATURE-

Bug#733674: libnewlib-arm-none-eabi: missing symlink causes arm-none-eabi-gcc to fail

[Anders Hammarquist]

Hi Agustin,

In a message of Thu, 02 Jan 2014 20:45:32 -0300, Agustin Henze writes:
 gcc-arm-none-eabi expects a /usr/lib/arm-none-eabi/include symlink
 pointing to /usr/include/newlib if libnewlib-arm-none-eabi is to 
 be usable. I think the package ought to provide the symlink.

  the main idea of gcc-arm-none-eabi is to allow choose the C standard
library that you want. With this in mind if you want to use newlib as C
standard library in your project then you need to add the path pointing to
newlib (the path that you mentioned above) in your list of include paths. For
clarify you can do this in gcc with -I/usr/include/newlib.

Almost, you want to use -isystem, but I see your point. I still think
it would be better to set it up to work without special flags for gcc
(and use update-alternatives to allow selecting which of several
install libc's should be default), so it works out of the box. You
could also set up someplace to point gcc's -sysroot flag to select an
alternate libc.

/Anders


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

Bug#733674: libnewlib-arm-none-eabi: missing symlink causes arm-none-eabi-gcc to fail

[Anders Hammarquist]

Package: libnewlib-arm-none-eabi
Version: 2.0.0-1
Severity: important

Dear Maintainer,

gcc-arm-none-eabi expects a /usr/lib/arm-none-eabi/include symlink
pointing to /usr/include/newlib if libnewlib-arm-none-eabi is to 
be usable. I think the package ought to provide the symlink.

/Anders

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

Kernel: Linux 3.10.9 (SMP w/2 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libnewlib-arm-none-eabi depends on:
ii  libnewlib-dev  2.0.0-1

Versions of packages libnewlib-arm-none-eabi recommends:
ii  gcc-arm-none-eabi  4.8.2-5+4

Versions of packages libnewlib-arm-none-eabi suggests:
pn  libnewlib-doc  none

-- 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#662780: cups: new version causes printer to hang for ages, then only print a blank page

[Anders Hammarquist]

In a message of Thu, 17 May 2012 16:14:45 +0200, Paul Menzel writes:
  cups 1.5.2-8 fixes LP #951627 and has entered unstable. Hopefully you
  will be able to say it addresses your problem too.

I think I experienced that problem today with `cups` 1.5.2-11 and
cups-filter 1.0.16-2 and 1.0.18-1.

Do you still experience this problem or is this fixed for you and I
should open a separate report?

I still see it with cups 1.5.2-8 and cups-filters 1.0.5-1, upgrading now
to check with current version...
and cups 1.5.2-11 / cups-filters 1.0.18-1 exhibit the blank-page printing
at least (I don't have a PDF that I know for sure to trigger the ghostscript
takes forever part of the bug handy right now, but feel free to mail me
the one that caused the problem for you and I can try it here too.)

I suspect, reading the Ubuntu bug reports, that some fixes were applied
specifically for Kyocera (and Brother, respectively) printers, and since
mine is a Lexmark those fixes don't trigger for me. I haven't looked at
the code though.

/Anders

PS: Anders and Brian, next time you follow up on a bug report, please
use `bts show --mbox 662780` and import the message to your mail
program. That way the threading is kept. `bts` is packaged in
`devscripts`. That would be awesome.

Neat.




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

Bug#669563: dvb-apps conflicts nmh

[Anders Hammarquist]

Package: dvb-apps
Version: 1.1.1+rev1457-4
Severity: normal

The most recent dvb-apps conflicts with nmh. While they contain a file
with the same name (/usr/share/man/man1/scan.1.gz), the correct solution
is not to conflict, as they do not provide even remotely similar
functionality, but rather for dvb-apps to not provide this file. (n)mh
clearly has precedence, having provided that particular command for several
decades.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dvb-apps depends on:
ii  libc6   2.13-26
ii  libpng12-0  1.2.47-1
ii  libx11-62:1.4.4-4
ii  libzvbi00.2.33-4
ii  makedev 2.3.1-89
ii  udev175-3.1
ii  zlib1g  1:1.2.6.dfsg-2

dvb-apps recommends no packages.

dvb-apps 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#662780: Similar issues with Lexmark Optra N PostScript printer

[Anders Hammarquist]

I'm seeing similar things with my Lexmark Optra N PS printer.
However, if I attempt to print plain postscript files, things
work just fine.

I also discovered that the ghostscript-supplied pdf2ps command
produces postscript files which generate a blank page when printed,
while they display fine using gs. Thus I suspect that this problem
may actually have more to do with ghostscript that cups.

poppler-utils (xpdf) supplied pdftops produces printable postscript.

/Anders



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

Bug#616071: ITP: python-oejskit -- python driven javascript unit testing

[Anders Hammarquist]

Package: wnpp
Severity: wishlist
Owner: Anders Hammarquist i...@debian.org

* Package name: python-oejskit
  Version : 0.9.0
  Upstream Author : Open End AB, Samuele Pedroni pedro...@openend.se
* URL : http://pypi.python.org/pypi/oejskit
* License : MIT
  Programming Lang: python
  Description : python driven javascript unit testing

jskit contains infrastructure and in particular a py.test plugin to enable
running tests for JavaScript code inside browsers directly using py.test as
the test driver. Running inside the browsers comes with some speed cost, on
the other hand it means for example the code is tested against the real-
world DOM implementations.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-sideframework that can already be exposed through
WSGI (or for which a subset of WSGI can be written to accommodate the jskit
own needs) can play along.



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

Bug#555469: libc6 postinst calls invoke-rc.d with bogus -query argument

[Anders Hammarquist]

Package: libc6
Version: 2.10.1-6
Severity: grave
Tags: patch

The libc6 postinst calls invoke-rc.d with the argument -query which,
given the code around it was probably intended to be --query. However,
that will cause the postinst to abort since -e is in effect on the shell.

The following patch fixes it so that it does what I think was intended:

--- /tmp/libc6.postinst 2009-11-09 21:41:12.703428816 +0100
+++ /var/lib/dpkg/info/libc6.postinst   2009-11-09 21:33:48.467429571 +0100
@@ -163,12 +163,14 @@
if [ -x `which invoke-rc.d 2/dev/null` ]; then
# Should be if invoke-rc.d ${service} status; then, but
# it is not yet supported by all scripts
-   invoke-rc.d -query ${service} start ; status=$?
+set +e
+   invoke-rc.d --query ${service} start ; status=$?
if [ $status = 104 ] ; then
services=$service $services
else
echo WARNING: init script for $service not found.
fi
+set -e
else
if [ -f /usr/share/file-rc/rc ] || [ -f /usr/lib/file-rc/rc 
]  [ -f /etc/runlevel.conf ]; then
idl=$(filerc $rl $service)



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

Bug#529291: rrdtool python bindings leak memory

[Anders Hammarquist]

Package: python-rrdtool
Version: 1.3.1-4
Tags: patch

The python bindings for the calls rrd_info, rrd_graph_v and rrd_update_v
do not properly release references to some objects that they allocate
leading to memory leaks. Attacked is a patch to fix it.

/Anders

Index: trunk/bindings/python/rrdtoolmodule.c
===
--- trunk/bindings/python/rrdtoolmodule.c   (revision 1440)
+++ trunk/bindings/python/rrdtoolmodule.c   (working copy)
@@ -435,6 +435,7 @@
 }
 if (val) {
 PyDict_SetItemString(r, data-key, val);
+Py_DECREF(val);
 }
 data = data-next;
 }
@@ -459,10 +460,13 @@
 if ((data = rrd_info(argc, argv)) == NULL) {
 PyErr_SetString(ErrorObject, rrd_get_error());
 rrd_clear_error();
-return NULL;
+r = NULL;
+} else {
+r = PyDict_FromInfo(data);
+rrd_info_free(data);
 }
-r = PyDict_FromInfo(data);
-rrd_info_free(data);
+
+destroy_args(argv);
 return r;
 }
 
@@ -484,10 +488,13 @@
 if ((data = rrd_graph_v(argc, argv)) == NULL) {
 PyErr_SetString(ErrorObject, rrd_get_error());
 rrd_clear_error();
-return NULL;
+r = NULL;
+} else {
+r = PyDict_FromInfo(data);
+rrd_info_free(data);
 }
-r = PyDict_FromInfo(data);
-rrd_info_free(data);
+
+destroy_args(argv);
 return r;
 }
 
@@ -509,10 +516,13 @@
 if ((data = rrd_update_v(argc, argv)) == NULL) {
 PyErr_SetString(ErrorObject, rrd_get_error());
 rrd_clear_error();
-return NULL;
+r = NULL;
+} else {
+r = PyDict_FromInfo(data);
+rrd_info_free(data);
 }
-r = PyDict_FromInfo(data);
-rrd_info_free(data);
+
+destroy_args(argv);
 return r;
 }
 



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

Bug#515096: python-mako incorrectly claims to support all python version

[Anders Hammarquist]

Package: python-mako
Version: 0.2.2-1

Trying to install python-mako on a system with python2.3 installed
fails because python-mako claims to support all python versions, while
it infact seems to requre at least 2.4. Setup results in this error
when byte compiling for python2.3

Setting up python-mako (0.2.2-1) ...
INFO: using old version '/usr/bin/python2.3'
Compiling /usr/lib/python2.3/site-packages/mako/_ast_util.py ...
  File /usr/lib/python2.3/site-packages/mako/_ast_util.py, line 111
for a, b in iter_fields(node)))
  ^
SyntaxError: invalid syntax

The line uses a generator expression, and those were added in
python2.4.

/Anders




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

Bug#491665: ITP: supervisor -- system for controlling process state

[Anders Hammarquist]

Package: wnpp
Severity: wishlist
Owner: Anders Hammarquist [EMAIL PROTECTED]

* Package name: supervisor
  Version : 3.0a6
  Upstream Author : Chris McDonough/Agendaless Consulting
* URL : http://supervisord.org/
* License : BSD-like (http://www.repoze.org/LICENSE.txt)
  Programming Lang: Python
  Description : system for controlling process state

Supervisor is a system for controlling and maintaining process state,
similar to what init does, but not intended as an init replacement.

It will manage individual processess or groups of processes that
need to be started and stopped in order, and it is possible to
control individual process state via an rpc mechanism, thus allowing
ordinary users to restart processes.



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

Bug#491667: ITP: python-meld3 -- an HTML/XML templating system

[Anders Hammarquist]

Package: wnpp
Severity: wishlist
Owner: Anders Hammarquist [EMAIL PROTECTED]

* Package name: python-meld3
  Version : 0.6.4
  Upstream Author : hris McDonough [EMAIL PROTECTED]
* URL : http://plope.com/software/meld3/
* License : Zope Public License
  Programming Lang: Python
  Description : an HTML/XML templating system

meld3 is an HTML/XML templating system for Python 2.3+ which
keeps template markup and dynamic rendering logic separate from
one another. See http://www.entrian.com/PyMeld for a treatise
on the benefits of this pattern.

supervisor (see other ITP) depends on this package.



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

Bug#435194: Appears to be a gcc bug

[Anders Hammarquist]

I experimented a bit with bind9 to try and figure out what causes
this error.

Adding -O2 to CFLAGS makes it work. Now, I haven't analyzed which
code is broken (i.e. if -O2 makes it botch the test, or if not having
-O2 makes the code leading up to the test fail), but either way would
make it a gcc bug.

this was bind9-9.4.2-1 on alpha (an EV56 Miata in this case)

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87



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

Bug#427057: More details makeing this bug less stochastic

[Anders Hammarquist]

I've spent some time further analyzing what is going on to cause this
bug.

1) The problem only occurs if the SSL server asks for a client certificate

2) The problem occurs when the server times out the HTTP/1.1 keep-alive
   (after 15 seconds using the current defaults in twisted with the
   script I sent).

3) From looking at the network traffic with wireshark, it appears that
   iceweasel attempts to reestablish the connection using SSL v2 after
   it's been timed out, which is then rejected.

This bug should probably go upstream.

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87


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

Bug#427057: iceweasel picks up wrong libssl3.so

[Anders Hammarquist]

In a message of Sun, 03 Jun 2007 20:19:45 EDT, Eric Dorland writes:
 So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel
 shell script (which invokes the actual binary,
 /usr/lib/iceweasel/firefox-bin). How are you invoking it? 
 
 Using the /usr/bin/iceweasel script... So at least theoretically,
 running it as env LD_LIBRARY_PATH=/usr/lib/iceweasel iceweasel
 vs just iceweasel shouldn't make any difference (I've read the
 script now). But it certainly did when I was chasing the SSL problem
 friday (or am I going insane?).

I doubt you're crazy but maybe you made a mistake. Try it again on the
machine you were having problems with and see.

Ok, I have some more data now (which also explains why I thought
setting LD_LIBRARY_PATH helped). I haven't managed to recreate
exactly the same situation I had on friday, but it looks similar
enough that I think it's still the same problem.

It seems that it is caused by interaction between the SSL server and
iceweasel. If the SSL server asks for a client certificate, but does
not specify any acceptable certificate authorities, connecting to the
SSL server will always work flawlessly the first time. Sometimes
the second and further attempts to connect will fail with a connection
interrupted error message:

The connection was interrupted

The connection to localhost: was interrupted while the page was loading.

* The site could be temporarily unavailable or too busy. Try again in a few
  moments.

* If you are unable to load any pages, check your computer's network
  connection.

* If your computer or network is protected by a firewall or proxy, make sure
  that Iceweasel is permitted to access the Web.

Sometimes, if the SSL server uses TLSv1 only, it will instead say that
the Iceweasel can't connect securely to localhost because the site uses
a security protocol which isn't enabled.

Unfortunately, I can't trigger it consistently, but it seems more common
if the server uses SSLv3 only or TLSv1 only. Using SSLv23 (i.e. 2 and 3
autonegotiation) breaks less often, but it happens there too.

Oh, and it's not the server, because openssl s_client connects just fine.

I'm including a small python program to test it. Uncommenting the
load_client_ca() line seems to make it consistently not break. If it's
not there, it will occasionally break. Switching methods seems to trigger
it quicker, so changing which SSL.*_METHOD is uncommented and then
reloading the page is more likely to trigger.

You'll need python-twisted-web2 and python-pyopenssl installed.

Generate the required certificates like:

$ openssl genrsa -out CA.key 1024
$ openssl req -new -key CA.key -x509 -out cacert
$ openssl genrsa -out foo.pkey 1024
$ openssl req -new -key foo.pkey -out foo.creq
$ openssl x509 -req -in foo.creq -CA cacert -CAkey CA.key -CAcreateserial -out 
foo.cert

/Anders

from twisted.python import log
from twisted.internet import reactor, ssl
from twisted.web2 import server, resource, channel, http
import sys

from OpenSSL import SSL, crypto

class Root(resource.Resource):
addSlash = True

def render(self, req):
return http.Response(code=200, stream='foo')

class SSLContextFactory(ssl.ContextFactory):
def __init__(self, pkey, cert, cacert, method):
_pkey = crypto.load_privatekey(crypto.FILETYPE_PEM, open(pkey).read())
_cert = crypto.load_certificate(crypto.FILETYPE_PEM, open(cert).read())
_cacert = crypto.load_certificate(crypto.FILETYPE_PEM, open(cacert).read())

self._ctx = ctx = SSL.Context(method)
#ctx.load_client_ca(cacert)
ctx.set_verify(SSL.VERIFY_PEER, self.verifyClientCallback)
ctx.set_cipher_list('RC4:-EXP:-LOW:-ADH:@STRENGTH')
ctx.use_certificate(_cert)
ctx.use_privatekey(_pkey)
certstore = ctx.get_cert_store()
certstore.add_cert(_cacert)

def verifyClientCallback(self, conn, cert, errnum, depth, ok):

Verifiy the client connection.

Arguments:   conn - the SSL connection
 cert - the certificate being checked
 errnum - error code from SSL (if applicable)
 depth - depth in certificate verification chain
 ok - 1: everything ok so far,
  0: an error (available in errnum)
Returns: The new 'ok' value

return ok


def getContext(self):
return self._ctx

def main():
log.startLogging(sys.stderr)
site = server.Site(Root())
print site

sslctx = SSLContextFactory('foo.pkey', 'foo.cert', 'cacert',
   #SSL.SSLv23_METHOD)
   #SSL.SSLv3_METHOD)
   SSL.TLSv1_METHOD)

print site
reactor.listenSSL(, channel.HTTPFactory(site), sslctx)
reactor.run()

if __name__ == '__main__':
main()

Bug#427057: iceweasel picks up wrong libssl3.so

[Anders Hammarquist]

In a message of Sat, 02 Jun 2007 23:20:00 EDT, Eric Dorland writes:
* Anders Hammarquist ([EMAIL PROTECTED]) wrote:
 Package: iceweasel
 Version: 2.0.0.3-2

 If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from
 that package rather than the one that it comes with. This results in
 partial breakage of its SSL support. Most noticably, it will not support
 TLSv1 connections.

I have a hard time believing that, what makes you think so?

The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the
problem go away, and that the problem stayed away without setting
LD_LIBRARY_PATH after purging libnss3.

However, I can't repeat it on another machine by installing libnss3
so something else must be off too. I'll investigate further when I
get back to work (and the machine that was broken) and see if I can
figure out what actually happend on monday. Close this bug and I'll
refile if I figure it out.

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87


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

Bug#427057: iceweasel picks up wrong libssl3.so

[Anders Hammarquist]

In a message of Sun, 03 Jun 2007 15:01:25 EDT, Eric Dorland writes:
 I have a hard time believing that, what makes you think so?
 
 The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the
 problem go away, and that the problem stayed away without setting
 LD_LIBRARY_PATH after purging libnss3.
 
So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel
shell script (which invokes the actual binary,
/usr/lib/iceweasel/firefox-bin). How are you invoking it? 

Using the /usr/bin/iceweasel script... So at least theoretically,
running it as env LD_LIBRARY_PATH=/usr/lib/iceweasel iceweasel
vs just iceweasel shouldn't make any difference (I've read the
script now). But it certainly did when I was chasing the SSL problem
friday (or am I going insane?).

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87


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

Bug#427057: iceweasel picks up wrong libssl3.so

[Anders Hammarquist]

Package: iceweasel
Version: 2.0.0.3-2

If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from
that package rather than the one that it comes with. This results in
partial breakage of its SSL support. Most noticably, it will not support
TLSv1 connections.

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87


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

Bug#315339: More problems w/ lvm2 and striped lvm1 volumes

[Anders Hammarquist]

Hi!

Here is another data point. I just (tried to) upgrade to lvm2 2.01.14-3
and it breaks my striped lvm1 volme, but the single-disk one works fine.

I've tried the vgcfgbackup/vgcfgrestore trick to try to get the metadata
consistent, but no go. The lvm is sdb + sdc (yes, they're old disks...)

Any ideas? (other than running vgconvert from 2.01.04?)

Initially:
# pvdisplay -v /dev/sdb
Using physical volume(s) on command line
  --- Physical volume ---
  PV Name   /dev/sdb
  VG Name   vg1
  PV Size   3.00 GB / not usable 11.31 MB
  Allocatable   yes 
  PE Size (KByte)   8192
  Total PE  382
  Free PE   176
  Allocated PE  206
  PV UUID   uUjd8k-fAF9-M3Nv-fMVh-JDb8-Lmde-XOBoZe
   
After vgcfgbackup+restore (so *something* changed):
# pvdisplay -v /dev/sdb
Using physical volume(s) on command line
  --- Physical volume ---
  PV Name   /dev/sdb
  VG Name   vg1
  PV Size   2.98 GB / not usable 0   
  Allocatable   yes 
  PE Size (KByte)   8192
  Total PE  382
  Free PE   176
  Allocated PE  206
  PV UUID   uUjd8k-fAF9-M3Nv-fMVh-JDb8-Lmde-XOBoZe
   
vgscan from 2.01.14 says (usr lives on vg1):
# vgscan 
  Reading all physical volumes.  This may take a while...
  LV usr: inconsistent LE count 206 != 412
  Internal error: LV segments corrupted in usr.
  Volume group vg1 not found
  Found volume group vg2 using metadata type lvm1
Exit 5

# cat /etc/lvm/backup/vg1 
# Generated by LVM2: Thu Oct 13 16:42:42 2005

contents = Text Format Volume Group
version = 1

description = Created *after* executing '/sbin/vgcfgbackup'

creation_host = eskarina  # Linux eskarina 2.6.13.4 #1 SMP Wed Oct 12 
22:27:15 MEST 2005 i686
creation_time = 1129214562  # Thu Oct 13 16:42:42 2005

vg1 {
id = azz8CP-V6mU-DEyq-Riqc-LPC1-9h6o-xSlzPy
seqno = 0
status = [RESIZEABLE, READ, WRITE]
system_id = eskarina1076353081
extent_size = 16384 # 8 Megabytes
max_lv = 256
max_pv = 256

physical_volumes {

pv0 {
id = uUjd8k-fAF9-M3Nv-fMVh-JDb8-Lmde-XOBoZe
device = /dev/sdb # Hint only

status = [ALLOCATABLE]
pe_start = 16768
pe_count = 382  # 2.98438 Gigabytes
}

pv1 {
id = ouci2x-aJWh-pHgp-b9d6-Ox0I-rXAf-A3StE7
device = /dev/sdc # Hint only

status = [ALLOCATABLE]
pe_start = 16768
pe_count = 382  # 2.98438 Gigabytes
}
}

logical_volumes {

usr {
id = 00------00
status = [READ, WRITE, VISIBLE]
allocation_policy = normal
read_ahead = 1024
segment_count = 1

segment1 {
start_extent = 0
extent_count = 412  # 3.21875 Gigabytes

type = striped
stripe_count = 2
stripe_size = 32# 16 Kilobytes

stripes = [
pv0, 0,
pv1, 0
]
}
}
}
}

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED]
Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50
G|teborg, Sweden.   RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87


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