Bug#1036457: flash-kernel: please add BeagleBone AI-64 support

[Sascha Silbe]

Package: flash-kernel
Version: 3.107
Severity: wishlist
X-Debbugs-Cc: sascha-debian-bugs-flash-kernel-20230...@silbe.org

Dear Maintainer,

I successfully tested flash-kernel on a BeagleBone AI-64 running
Bookworm with the following entry in /etc/flash-kernel/db:

=== Begin ===
Machine: BeagleBoard.org BeagleBone AI-64
Kernel-Flavors: arm64
Boot-Script-Path: /boot/boot.scr
DTB-Id: ti/k3-j721e-beagleboneai64.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools
=== End ===

The Device Tree for BeagleBone AI-64 landed upstream in Linux
6.2. Since Bookworm ships with 6.1 I copied to DTB to
/etc/flash-kernel/dtbs.

U-Boot support is still getting upstreamed but stock U-Boot on eMMC
will boot a Debian installation from an SD card without any change to
the configuration so we don't need to wait for U-Boot support to land
and reach Debian before adding flash-kernel support.


Sascha

(System Information skipped because I'm writing this report on another
host)

Bug#1010605: pytest: please package pytest 7.1.x

[Sascha Silbe]

Source: pytest
Version: 6.0.2-2
Severity: wishlist
X-Debbugs-Cc: sascha-debian-bugs-pytest-2022-05...@silbe.org

Dear Maintainer,

pytest 7.0.0 introduced a couple useful new features. It would be
great to have the latest upstream version (7.1.2 at the time of
writing) in Debian.

Thanks in advance!

Sascha

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'stable-debug'), (100, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1010391: afew: missing dependency on python3-dnspython

[Sascha Silbe]

Package: afew
Version: 3.0.1-1
Severity: normal
X-Debbugs-Cc: sascha-debian-bugs-afew-2022-04...@silbe.org

Dear Maintainer,

after a fresh installation afew fails to start because it cannot find
the "dns" module:

=== Begin ===
Traceback (most recent call last):
  File "/usr/bin/afew", line 33, in 
sys.exit(load_entry_point('afew==3.0.1', 'console_scripts', 'afew')())
  File "/usr/lib/python3/dist-packages/afew/commands.py", line 136, in main
__import__(file_name[:-3], level=0)
  File "/home/sascha/.config/afew/HeaderFilter.py", line 19, in 
class HeaderFilter(Filter):
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 60, in 
register_filter
all_filters[klass.__name__] = klass
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 39, in 
__setitem__
self.filter[key] = value
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 26, in 
filter
self._filter[f.name] = f.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/afew/filters/DKIMValidityFilter.py", 
line 13, in 
import dns.exception
ModuleNotFoundError: No module named 'dns'
=== End ===

The "dns" Python module is shipped by python3-dnspython. Please add a
dependency on it.

NB: my configuration does not make use of DKIMValidityFilter so it's a
hard dependency.

Sascha

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'stable-debug'), (100, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages afew depends on:
ii  python3  3.9.2-3
ii  python3-chardet  4.0.0-1
ii  python3-dkim 1.0.5-1
ii  python3-notmuch  0.31.4-2

afew recommends no packages.

afew suggests no packages.

-- no debconf information

Bug#1008762: debos: does not work with Linux 5.13+

[Sascha Silbe]

Package: debos
Version: 1.0.0+git20201203.e939090-4+b3
Severity: important
Tags: upstream
X-Debbugs-Cc: sascha-debian-bugs-debos-2022-03...@silbe.org

Dear Maintainer,

debos does not work on systems running a 5.13 or newer kernel because
the 9pnet_virtio and virtio_pci modules cannot be loaded:

=== Begin debos --show-boot output ===
[1.443424] Run /init as init process
modprobe: can't load module virtio_pci_modern_dev 
(kernel/drivers/virtio/virtio_pci_modern_dev.ko): No such file or directory
[1.511627] 9pnet: Installing 9P2000 support
modprobe: can't load module netfs (kernel/fs/netfs/netfs.ko): No such file or 
directory
mount: mounting usr on /usr failed: No such device
mount: mounting sbin on /sbin failed: No such device
mount: mounting bin on /bin failed: No such device
mount: mounting lib on /lib failed: No such device
/init: exec: line 28: /lib/systemd/systemd: not found
[1.534807] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
[...]
open /tmp/fakemachine-733191250/result: no such file or directory
=== End debos --show-boot output ===

Since Linux 5.13 there's a new module "netfs" that the "9p" module
depends on. Because fakemachine does not take module dependencies into
account, "netfs" is not copied into the initramfs.

This is in fact the same issue that Steve Langasek encountered in
#989145 "Please do not use uml fakemachine backend in the DEP-8 test".

The naive approach of adding "netfs" to InitrdModules would break
support for kernels older than 5.13. The real solution would be to
perform module dependency resolution but quick work-arounds would be
to either copy all modules (probably increasing early boot memory
usage by ~0.5GiB which may be acceptable) or to copy "netfs" only if
present.

Similarly, virtio_pci depends on virtio_pci_modern_dev which isn't
included in InitrdModules. The same compatibility concerns apply.


Sascha

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'stable-debug'), (100, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debos depends on:
ii  busybox1:1.30.1-6+b3
ii  debootstrap1.0.123
ii  libc6  2.31-13+deb11u3
ii  libglib2.0-0   2.66.8-1
ii  libostree-1-1  2020.8-2+deb11u1
ii  qemu-system-x861:5.2+dfsg-11+deb11u1
ii  qemu-user-static   1:5.2+dfsg-11+deb11u1
ii  systemd-container  247.3-7

Versions of packages debos recommends:
ii  bmap-tools 3.5-3
ii  bzip2  1.0.8-4
ii  e2fsprogs  1.46.2-2
ii  linux-image-amd64  5.16.12-1~bpo11+1
ii  mount  2.36.1-8+deb11u1
ii  ovmf   2020.11-2+deb11u1
ii  parted 3.4-1
ii  udev   247.3-7
ii  xz-utils   5.2.5-2
ii  zip3.0-12

debos suggests no packages.

-- no debconf information

Bug#999772: limesuite-udev: replaces entire /dev/serial directory with single symlink

[Sascha Silbe]

Package: limesuite-udev
Version: 20.10.0+dfsg-2
Severity: important
X-Debbugs-Cc: sascha-debian-bugs-2021-11-16-limesuite-u...@silbe.org

Dear Maintainer,

the udev rules contained in limesuite-udev cause *all* USB serial
adapters using the default vendor / product id of several FTDI chips
(0403:6001) to end up with a symlink /dev/serial, thereby hiding the
/dev/serial/by-{id,path} directories that are needed to consistently
access individual USB serial ports:

=== Begin ===
sascha@twin:~$ ls -l /dev/serial
lrwxrwxrwx 1 root root 7 Nov 16 14:12 /dev/serial -> ttyUSB1
sascha@twin:~$ lsusb -d 0403:6001
Bus 001 Device 015: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 Serial (UART) IC
Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 Serial (UART) IC
Bus 005 Device 006: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 Serial (UART) IC
Bus 005 Device 012: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 Serial (UART) IC
=== End ===

This is the offending line in /lib/udev/rules.d/64-limesuite.rules:

=== Begin ===
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", 
MODE="0666", SYMLINK+="serial"
=== End ===

According to the severity descriptions this bug would be "critical"
("makes unrelated software on the system (or the whole system) break")
but given that there's an easy workaround (uninstalling the package)
for people who don't actually need the functionality I went with
"important" instead. I only ended up with the package installed
because it was pulled in via a Recommends: chain by soapysdr-tools.

A quick grep on the source suggests limesuite itself isn't using the
symlink so the easiest fix would be to simply get rid of the line
quoted above.

Kind regards,
Sascha

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'stable-debug'), (100, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 5.10.70-silbe-v1.0-26-gc0a00df-amd64-1+bpo10+1-amd64 (SMP w/4 CPU 
threads)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#995444: bsdutils: "script" no longer prints output file name at the end

[Sascha Silbe]

Package: bsdutils
Version: 1:2.36.1-8
Severity: normal
Tags: upstream

Dear Maintainer,

since Bullseye, probably caused by upstream commit
d805688afc0c709154c9c6f29383b175c05ffc92 ("script: report also timing
file, do it only once"), "script" no longer outputs the file name at
the end.

I'm using "script" to record the output of programs that create a
large amount of output so that I a) have a copy for future reference
(i.e. a log file) and b) can read the output using a pager like
less. Because I keep the output as a log file, I use assign unique
file names based on the current time ("date +%Y%m%d-%H%M%S"). Because
the output of the programs often is longer than the terminal
scrollback buffer, I cannot scroll up to see the file name at the
start of the "script" output. With "script" no longer printing the
file name at the end this means I need to look up the file name using
"ls -tr|tail" before I can read the file with a pager to review the
current run. This is rather tedious during everyday usage.

Sascha

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bsdutils depends on:
ii  libc62.31-13
ii  libsystemd0  247.3-6

Versions of packages bsdutils recommends:
ii  bsdextrautils  2.36.1-8

bsdutils suggests no packages.

-- no debconf information

Bug#994093: libgradle-android-plugin-java: tries to use removed method setDependencyCacheDir()

[Sascha Silbe]

Package: libgradle-android-plugin-java
Version: 2.2.2-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: 
sascha-debian-bugs-libgradle-android-plugin-java-2021-09...@silbe.org

Dear Maintainer,

the Android Gradle Plugin version in sid (2.2.2-3) does not work with
the Gradle version in bullseye/bookworm/sid (4.4.1-13) because it still
tries to use the
com.android.build.gradle.tasks.factory.AndroidJavaCompile.setDependencyCacheDir()
method that got removed in Gradle 4.0.0 (commit
edadbed1378f439d31bb1d2a8c68c18365e0d1b0).

Upstream stopped using setDependencyCacheDir() in version 3.0.0 (commit
fde89448b47124a9b10c8ab13843c369525b9b8d). If upgrading AGP to that
version isn't an option it may be worth trying to backport the fix.

Example stacktrace:

=== Begin ===
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
FAILURE: Build failed with an exception.
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * 
What went wrong:
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] A 
problem occurred configuring project ':app'.
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > 
Failed to notify project evaluation listener.
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
 > 'void 
com.android.build.gradle.tasks.factory.AndroidJavaCompile.setDependencyCacheDir(java.io.File)'
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * 
Try:
16:33:15.998 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]  
Run with --scan to get full insights.
16:33:15.999 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
16:33:15.999 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * 
Exception is:
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
org.gradle.api.ProjectConfigurationException: A problem occurred configuring 
project ':app'.
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:94)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:89)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator.doConfigure(LifecycleProjectEvaluator.java:70)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator.access$100(LifecycleProjectEvaluator.java:34)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator$ConfigureProject.run(LifecycleProjectEvaluator.java:110)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
16:33:16.000 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:50)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:666)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:135)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 
org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:62)
16:33:16.001 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   
at 

Bug#971696: linux-image-4.19.0-11-armmp: network hangs, oops in ath9k_htc after upgrade

[Sascha Silbe]

Sascha Silbe  writes:

> since the last kernel update (from linux-image-armmp:armhf
> 4.19+105+deb10u5 / linux-image-4.19.0-10-armmp 4.19.132-1 to
> linux-image-armmp 4.19+105+deb10u6 / linux-image-4.19.0-11-armmp
> 4.19.146-1) our BeagleBone Black systems with AR9271 based WLAN adapter
> (ath9k_htc driver) print a kernel warning or oops during boot and all
> network related system calls hang, breaking not just WLAN but also
> ethernet:
[...]
> If there's a git repository I can *cross*-build from with reasonable
> effort I can try git bisect.

I was unable to reproduce this bug using a kernel cross-built from tag
debian/4.19.146-1 in the repository
https://salsa.debian.org/kernel-team/linux.git on a Buster amd64 host or
a Stretch amd64 host. I used the config from the official kernel with
only CONFIG_LOCALVERSION and CONFIG_SYSTEM_TRUSTED_KEYS changed.

Is debian/4.19.146-1 the right tag for the kernel sources used by
linux-image-4.19.0-11-armmp 4.19.146-1? If so, why does this bug only
happen with the official package but not with one I built locally?

One thing that seems odd is that the package built from tag
debian/4.19.146-1 identifies itself as 4.19.87, not 4.19.146.

Sascha


signature.asc
Description: PGP signature

Bug#971696: linux-image-4.19.0-11-armmp: network hangs, oops in ath9k_htc after upgrade

[Sascha Silbe]

Package: src:linux
Version: 4.19.146-1
Severity: important

Dear Maintainer,

since the last kernel update (from linux-image-armmp:armhf
4.19+105+deb10u5 / linux-image-4.19.0-10-armmp 4.19.132-1 to
linux-image-armmp 4.19+105+deb10u6 / linux-image-4.19.0-11-armmp
4.19.146-1) our BeagleBone Black systems with AR9271 based WLAN adapter
(ath9k_htc driver) print a kernel warning or oops during boot and all
network related system calls hang, breaking not just WLAN but also
ethernet:

=== Begin ===
root@mavis:~# ip addr
[no output, just hanging]
=== End ===

Kernel oops (from one boot):

=== Begin ===
[  OK  ] Started Network Manager Script Dispatcher Service.
[   40.785065] IPv6: ADDRCONF(NETDEV_UP): wlx6cfdb9aac04b: link is not ready
[   41.258639] [ cut here ]
[   41.263512] kernel BUG at mm/slub.c:294!
[   41.267603] Internal error: Oops - BUG: 0 [#1] SMP ARM
[   41.272962] Modules linked in: cmac bnep arc4 btusb btrtl btbcm btintel 
bluetooth drbg ansi_cprng evdev ath9k_htc ath9k_common ath9k_hw ath 
ecdh_generic mac80211 hid_generic cfg80211 usbhid snd_usb_audio snd_usbmidi_lib 
rfkill snd_hwdep hid snd_rawmidi snd_seq_device nls_ascii nls_cp437 vfat fat 
snd_soc_simple_card snd_soc_spdif_rx snd_soc_simple_card_utils omap_rng 
rng_core snd_soc_davinci_mcasp snd_soc_edma snd_soc_sdma snd_soc_core 
snd_pcm_dmaengine snd_pcm snd_timer cppi41 snd at24 soundcore omap_wdt 
leds_gpio ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb smsc musb_dsps musb_hdrc udc_core davinci_mdio usbcore phy_am335x 
phy_generic phy_am335x_control ti_cpsw cpsw_ale cpsw_common davinci_cpdma 
omap_hsmmc musb_am335x tps65217
[   41.343301] CPU: 0 PID: 301 Comm: NetworkManager Not tainted 4.19.0-11-armmp 
#1 Debian 4.19.146-1
[   41.352549] Hardware name: Generic AM33XX (Flattened Device Tree)
[   41.358916] PC is at kfree+0x1b4/0x1f0
[   41.362826] LR is at 0xda4af800
[   41.366100] pc : []lr : []psr: 600f0013
[   41.372630] sp : da061570  ip : dfd2389c  fp : da06159c
[   41.378073] r10: 2878  r9 : cf178000  r8 : dd1d1900
[   41.383518] r7 : cf07ce88  r6 :   r5 : da4af800  r4 : c0991234
[   41.390320] r3 : c112abb0  r2 : da4af800  r1 : 2a33  r0 : de001a00
[   41.397123] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   41.404561] Control: 10c5387d  Table: 9a114019  DAC: 0051
[   41.410554] Process NetworkManager (pid: 301, stack limit = 0x42389799)
[   41.417448] Stack: (0xda061570 to 0xda062000)
[   41.421991] 1560: da05d680 00041392 
 dd1d1900
[   41.430520] 1580: dd1d1900 da4af940 cf07ce88 dd1d1900 da0615ac da0615a0 
c0991234 c051adac
[   41.439050] 15a0: da0615cc da0615b0 c0995398 c0991210 dd1d1900 dd1d1900 
bf716128 cf07ce88
[   41.447578] 15c0: da0615e4 da0615d0 c09947f0 c099524c cf07cc00 dd1d1900 
da061604 da0615e8
[   41.456106] 15e0: c0994858 c09947cc cf07cc00 cf07cc0c ff92 cf07ce88 
da06162c da061608
[   41.464635] 1600: bf716128 c0994828 c1205dcc dd44ce20  ff0f 
ff0f cf178000
[   41.473165] 1620: da06168c da061630 bf71bff8 bf715fb8 da061650 0004 
0064 da061694
[   41.481693] 1640: da4d1fa0 da4d18c0 da4d1f80 cf178000 da06168c da061660 
bf6993c0 00041392
[   41.490221] 1660:  cf178000 bf71be94 cf17826c cf17826c c1205dcc 
0001 
[   41.498751] 1680: da061704 da061690 bf6a2f38 bf71bea0  786c 
48e09eb4 7854
[   41.507279] 16a0: 0004 7820 0c04 7824 00d8abff 7868 
84036086 783c
[   41.515807] 16c0: 72ee0a72 7838 0029 7828 66964300 00041392 
000186a0 cf178000
[   41.524336] 16e0: cf179000 cf17826c cf17826c  cf17a000  
da061744 da061708
[   41.532866] 1700: bf6a3e1c bf6a2d60 cf17826c 0898 bf71be94 bf6a0aa0 
da061744 cf178000
[   41.541394] 1720: cf179000 cf17826c bf71be94  cf17a000  
da0617bc da061748
[   41.549922] 1740: bf69b548 bf6a3ce0 c03808e4 0100 0200 0001 
 2000
[   41.558453] 1760: 00551139   c1205dcc cf178028 00023f60 
0028 
[   41.566981] 1780: 2eb17382 bf7160f4 da0617bc 00041392 bf7160f4 dd44ce20 
dd44c494 cf178000
[   41.575509] 17a0: c1205dcc dd44d4ac dd44c480 cf17826c da06180c da0617c0 
bf719a9c bf69aab4
[   41.584040] 17c0: da0617d9 0001 01f4 0001  cf07c040 
0100 00041392
[   41.592568] 17e0:  dd44c480 de5fe000 dd44c480 bf61c688 de5fe85c 
dd7db110 
[   41.601098] 1800: da06182c da061810 bf5af81c bf7199f8 de5fe588 de5fe000 
dd44c480 bf61c688
[   41.609628] 1820: da061864 da061830 bf5c6bc8 bf5af7e0 1002 0001 
da06185c de5fe580
[   41.618156] 1840: c1205dcc  bf61c688 de5fe02c dd7db110  
da06187c da061868
[   41.626685] 1860: bf5c7140 bf5c679c de5fe000 c1205dcc da0618bc da061880 
c09b0008 bf5c70f8
[   41.635216] 1880: de5fe194 de5fe000 da0618a4 de5fe000  00041392 
da0618bc de5fe000
[   41.643744] 18a0: 0001 1003 

Bug#950508: debos: broken in Buster: libresolv.so.2: cannot open shared object file

[Sascha Silbe]

Package: debos
Version: 1.0.0+git20190123.d6e16be-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after the upgrade to Buster debos stopped working. This happens even
with the minimal example from the man page. The output when run with
--show-boot suggests a shared library issue inside the VM:

sascha@brick:~$ debos --show-boot example.yaml 
[0.00] Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 
(2019-11-11)
[0.00] Command line: console=ttyS0 panic=-1 
systemd.unit=fakemachine.service
[...]
[0.713821] Run /init as init process
/bin/busybox: error while loading shared libraries: libresolv.so.2: cannot open 
shared object file: No such file or directory
[0.715660] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
[...]
[0.728779] Kernel Offset: 0x3800 from 0x8100 (relocation 
range: 0x8000-0xbfff)
open /tmp/fakemachine-785139448/result: no such file or directory
sascha@brick:~$

The same happens in a VM where I did a fresh install of debos so it's
very likely to affect all debos users on Buster (hence severity
grave).

Kind regards,
Sascha

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 'stable-debug'), 
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debos depends on:
ii  busybox1:1.30.1-4
ii  debootstrap1.0.114
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libostree-1-1  2019.1-1
ii  qemu-system-x861:3.1+dfsg-8+deb10u3
ii  qemu-user-static   1:3.1+dfsg-8+deb10u3
ii  systemd-container  241-7~deb10u2

Versions of packages debos recommends:
ii  bmap-tools 3.5-2
ii  bzip2  1.0.6-9.2~deb10u1
ii  e2fsprogs  1.44.5-1+deb10u2
ii  linux-image-amd64  4.19+105+deb10u1
ii  mount  2.33.1-0.1
ii  ovmf   0~20181115.85588389-3
ii  parted 3.2-25
ii  udev   241-7~deb10u2
ii  xz-utils   5.2.4-1
ii  zip3.0-11+b1

debos suggests no packages.

-- no debconf information

Bug#944518: linux-image-4.19.0-6-armmp: please enable CONFIG_INPUT_TPS65218_PWRBUTTON

[Sascha Silbe]

Source: linux
Version: 4.19.67-2+deb10u1
Severity: wishlist

Dear Maintainer,

currently it's impossible to use the power button on the BeagleBone
Black when running the Debian kernel. Please enable
CONFIG_INPUT_TPS65218_PWRBUTTON.

Kind regards,
Sascha Silbe

-- Package-specific info:
** Version:
Linux version 4.19.0-6-armmp (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

** Command line:
quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Device Tree model: TI AM335x BeagleBone Black

** Loaded modules:
tun
nls_ascii
nls_cp437
vfat
fat
usbhid
hid
snd_soc_hdmi_codec
snd_soc_simple_card
snd_soc_simple_card_utils
snd_soc_davinci_mcasp
snd_soc_edma
snd_soc_sdma
tilcdc
tda998x
snd_soc_core
omap_rng
drm_kms_helper
rng_core
snd_pcm_dmaengine
snd_pcm
snd_timer
drm
snd
soundcore
cec
at24
cppi41
omap_wdt
leds_gpio
sch_fq_codel
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
smsc
davinci_mdio
musb_dsps
musb_hdrc
udc_core
usbcore
phy_am335x
phy_generic
phy_am335x_control
ti_cpsw
cpsw_ale
cpsw_common
davinci_cpdma
omap_hsmmc
musb_am335x
tps65217

** PCI devices:
not available

** USB devices:
[removed]

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.0-6-armmp (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-6-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-6-armmp recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-6-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-6-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#944256: linux-image-4.19.0-6-armmp: please enable cpufreq for AM335x (BBB)

[Sascha Silbe]

Source: linux
Version: 4.19.67-2+deb10u1
Severity: wishlist

Dear Maintainer,

currently it's impossible to reduce the CPU frequency (e.g. for thermal
management) on AM335x based boards like the BeagleBone Black when
running the Debian kernel. Please enable cpufreq support for those
boards. For starters enabling CONFIG_ARM_TI_CPUFREQ will be required;
not sure if other options are missing, too.

Kind regards,
Sascha Silbe

-- Package-specific info:
** Version:
Linux version 4.19.0-6-armmp (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

** Command line:
quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Device Tree model: TI AM335x BeagleBone Black

** Loaded modules:
tun
nls_ascii
nls_cp437
vfat
fat
usbhid
hid
snd_soc_hdmi_codec
snd_soc_simple_card
snd_soc_simple_card_utils
snd_soc_davinci_mcasp
snd_soc_edma
snd_soc_sdma
tilcdc
tda998x
snd_soc_core
omap_rng
drm_kms_helper
rng_core
snd_pcm_dmaengine
snd_pcm
snd_timer
drm
snd
soundcore
cec
at24
cppi41
omap_wdt
leds_gpio
sch_fq_codel
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
smsc
davinci_mdio
musb_dsps
musb_hdrc
udc_core
usbcore
phy_am335x
phy_generic
phy_am335x_control
ti_cpsw
cpsw_ale
cpsw_common
davinci_cpdma
omap_hsmmc
musb_am335x
tps65217

** PCI devices:
not available

** USB devices:
[removed]


-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.0-6-armmp (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-6-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-6-armmp recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-6-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-6-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information


signature.asc
Description: PGP signature

Bug#846175: gnupg-agent: Unable to use SSH key with empty passphrase since upgrade to Stretch

[Sascha Silbe]

Package: gnupg-agent
Version: 2.1.18-8~deb9u2
Followup-For: Bug #846175

Dear Maintainer,

after the upgrade to Stretch we're hitting this bug, too. We have an
SSH key that's shared between a group of users and used by automated
processes, too (so it cannot be password-protected). The OpenSSH
client refuses to use a private key that's group-readable (bmo#2713
[1]) so as a work-around we've been feeding ssh-add the key from stdin
and using it via the agent rather than directly from the file. Adding
the key to the agent still works, but the key cannot actually be used
by SSH since the upgrade to Stretch:

=== Begin shell session ===
sascha@twin:~/www$ ./rsync-to-outpost+tuple.sh
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.2]
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) 
[sender=3.1.2]
=== End shell session ===

=== Begin syslog ===
Jul  7 10:48:55 twin gpg-agent[9439]: Failed to lookup password for key 
s/D8B841113308EB78E0E12F4C41A144783CCEC9D0 with secret service: Cannot 
autolaunch D-Bus without X11 $DISPLAY
Jul  7 10:48:55 twin pinentry[1189]: it took 8 tries to grab the keyboard
Jul  7 10:49:01 twin gpg-agent[9439]: failed to unprotect the secret key: No 
passphrase given
Jul  7 10:49:01 twin gpg-agent[9439]: failed to read the secret key
Jul  7 10:49:01 twin gpg-agent[9439]: ssh sign request failed: No passphrase 
given 
Jul  7 10:49:01 twin gpg-agent[9439]: Failed to lookup password for key 
s/D8B841113308EB78E0E12F4C41A144783CCEC9D0 with secret service: Cannot 
autolaunch D-Bus without X11 $DISPLAY
Jul  7 10:49:01 twin pinentry[1195]: it took 8 tries to grab the keyboard
Jul  7 10:49:03 twin gpg-agent[9439]: failed to unprotect the secret key: No 
passphrase given
Jul  7 10:49:03 twin gpg-agent[9439]: failed to read the secret key
Jul  7 10:49:03 twin gpg-agent[9439]: ssh sign request failed: No passphrase 
given 
=== End syslog ===

Sascha

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2713

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-11+deb9u3
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgpg-error0   1.26-2
ii  libnpth01.3-1
ii  libreadline77.0-3
ii  pinentry-curses [pinentry]  1.0.0-2
ii  pinentry-gtk2 [pinentry]1.0.0-2

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-8~deb9u2
ii  gpgsm  2.1.18-8~deb9u2

Versions of packages gnupg-agent suggests:
pn  dbus-user-session  
ii  libpam-systemd 232-25+deb9u2
pn  pinentry-gnome3
ii  scdaemon   2.1.18-8~deb9u2

-- no debconf information

Bug#901675: notion: Unconditionally uses /bin/sh instead of user shell

[Sascha Silbe]

Package: notion
Version: 3+2015061300-2+b1
Severity: normal

Dear Maintainer,

I'm defining a couple of shell functions in my ~/.bash_profile and
export them so I can use them in xterms started from within
notion. This worked fine in jessie, but broke with the update to
stretch. Apparently in stretch dash (which provides /bin/sh) drops
bash functions from the environment. Since notion uses /bin/sh (rather
than the user shell) to execute any program everything started by
notion will lack the shell functions.

Please make the shell to use configurable and / or default to using
the user shell instead of /bin/sh. Not only does this avoid this kind
of bug, it also matches the user expectations regarding the shell
syntax more closely.

PS: Thanks for maintaing the Debian package for notion!

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages notion depends on:
ii  gnome-terminal [x-terminal-emulator]  3.22.2-1
ii  libc6 2.24-11+deb9u3
ii  libice6   2:1.0.9-2
ii  liblua5.2-0   5.2.4-1.1+b2
ii  libsm62:1.2.2-1+b3
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  x11-utils 7.7+3+b1
ii  xterm [x-terminal-emulator]   327-2

Versions of packages notion recommends:
ii  xfonts-100dpi 1:1.0.4+nmu1
ii  xfonts-100dpi-transcoded  1:1.0.4+nmu1

Versions of packages notion suggests:
pn  docker  
ii  menu2.1.47+b1

-- no debconf information

Bug#596334: dnsutils: Still happens in Stretch

[Sascha Silbe]

Package: dnsutils
Version: 1:9.10.3.dfsg.P4-12.3+deb9u3
Followup-For: Bug #596334
Control: found 596334 1:9.10.3.dfsg.P4-12.3+deb9u3

Dear Maintainer,

I'm not the original reporter but I can still reproduce this bug in
Stretch:

sascha@vorratskeller3:~$ dig +sigchase +dnssec +topdown -t MX silbe.org 

Launch a query to find a RRset of type MX for zone: silbe.org with
nameservers:
.   54683   IN  NS  a.root-servers.net.
.   54683   IN  NS  b.root-servers.net.
[...]

;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for org. with DNSKEY:9795: success

;; We are in a Grand Father Problem: See 2.2.1 in RFC 3658

;; ERROR : silbe.org. is not a subdomain of: org. FAILED

../../../lib/dns/name.c:2183: REQUIRE(source->length > 0) failed.
Aborted

Sascha

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.54-ti-r93 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsutils depends on:
ii  bind9-host [host]  1:9.10.3.dfsg.P4-12.3+deb9u3
ii  libbind9-140   1:9.10.3.dfsg.P4-12.3+deb9u3
ii  libc6  2.24-11+deb9u1
ii  libcap21:2.25-1
ii  libcomerr2 1.43.4-2
ii  libdns162  1:9.10.3.dfsg.P4-12.3+deb9u3
ii  libgeoip1  1.6.9-4
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libisc160  1:9.10.3.dfsg.P4-12.3+deb9u3
ii  libisccfg140   1:9.10.3.dfsg.P4-12.3+deb9u3
ii  libk5crypto3   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  liblwres1411:9.10.3.dfsg.P4-12.3+deb9u3
ii  libssl1.0.21.0.2l-2
ii  libxml22.9.4+dfsg1-2.2+deb9u1

dnsutils recommends no packages.

Versions of packages dnsutils suggests:
pn  rblcheck  

-- no debconf information

Bug#868352: linux: Please enable USB_SERIAL_CONSOLE

[Sascha Silbe]

Source: linux
Version: 4.11.6-1
Severity: normal

Dear Maintainer,

on some amd64 systems no native or PCI(e) serial ports are available
resp. possible. USB serial adapters are the only option to get a
serial console for debugging boot problems in this case. Unfortunately
the Debian amd64 kernels are built with USB_SERIAL_CONSOLE unset
(because USB_SERIAL is not built-in) so even that option isn't
available. When the BIOS text mode isn't working (e.g. high-res
monitor with a BIOS that only supports up to FullHD) one is left
without any working console device.

So please enable USB_SERIAL_CONSOLE (requires USB_SERIAL=y) for future
kernels and consider setting one of the USB serial adapter drivers to
built-in as well so that it's available before module loading. But
even just USB_SERIAL_CONSOLE alone (with all USB serial drivers as
modules) is likely better than the current situation; AFAICT the USB
serial console should get activated as soon the the USB serial driver
is loaded (haven't tested it, though).

Sascha

-- System Information:
Debian Release: 8.8
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-updates'), (100, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#862083: firejail: crashes when using --allow-debuggers ("free(): invalid pointer")

[Sascha Silbe]

Dear Reiner,

Reiner Herrmann  writes:

[...]
> I was able to reproduce the issue in a jessie chroot with the bpo package.
> After some debugging I found that it is a memory corruption in fs.c.
> Fortunately it has also already been fixed upstream [1], which is
> already part of 0.9.44.10-1.
> I will cherry-pick the fix for (hopefully) stretch and backports.

Awesome, thanks!

Sascha


signature.asc
Description: PGP signature

Bug#862218: mumble: spams console with "warning: Unknown speex_preprocess_ctl request: 26" (and 35)

[Sascha Silbe]

Package: mumble
Version: 1.2.8-2
Severity: normal

Dear Maintainer,

on all the ARM based systems that I've tried (OLPC XO-1.75 (*), Wandboard
Quad, OpenRD Base) mumble spams stdout or stderr with these lines:

=== Begin ===
warning: Unknown speex_preprocess_ctl request:  26
warning: Unknown speex_preprocess_ctl request:  35
=== End ===


It's producing them at such a high rate that sshd consumes considerable
CPU time when I run mumble over SSH.

At least on the Wandboard Quad it happens both with on-board audio and
with a USB headset (Microsoft LifeChat LX-6000); OpenRD Base doesn't
have on-board audio so I only tried the USB headset. On XO-1.75 it
crashes before it can output more than a few of these lines; see my
other bug report (which apparently ended up on
debian-backpo...@lists.debian.org because I had the backports version
installed when I reported the bug).

Sascha

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.10.15-wandboard-30-2-g80e913c7cb9e (SMP w/4 CPU cores; 
PREEMPT)
Locale: LANG=en_GB.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 mumble depends on:
ii  gconf2 3.2.6-3
ii  libasound2 1.0.28-1
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libavahi-compat-libdnssd1  0.6.31-5
ii  libc6  2.19-18+deb8u9
ii  libg15daemon-client1   1.9.5.3-8.3
ii  libgcc11:4.9.2-10
ii  libopus0   1.1-2
ii  libprotobuf9   2.6.1-1
ii  libpulse0  5.0-13
ii  libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-sql-sqlite  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libsndfile11.0.25-9.1+deb8u1
ii  libspeechd20.8-7
ii  libspeex1  1.2~rc1.2-1
ii  libspeexdsp1   1.2~rc1.2-1
ii  libssl1.0.01.0.1t-1+deb8u6
ii  libstdc++6 4.9.2-10
ii  libx11-6   2:1.6.2-3
ii  libxi6 2:1.7.4-1+b2
ii  lsb-release4.1+Debian13+nmu1

mumble recommends no packages.

Versions of packages mumble suggests:
ii  mumble-server  1.2.8-2
pn  speech-dispatcher  

-- no debconf information

Bug#862085: spice-client: Doesn't start at all: crtc_overlap_test: unsupported partial overlap

[Sascha Silbe]

Package: spice-client
Version: 0.12.5-1+deb8u4
Severity: important

Dear Maintainer,

not sure exactly when it broke (upgrade to jessie or some later
update), but spicec doesn't work at all anymore on my system:

=== Begin ===
sascha.silbe@twin:~$ spicec -h localhost -p 1234
(/usr/bin/spicec:11405): Spice-Warning **: 
x11/platform.cpp:1377:crtc_overlap_test: unsupported partial overlap
Error: unhandled exception: unsupported partial overlap
=== End ===

It doesn't matter whether there's a spice server listening on the
given port, so it appears to bail out quite early.

Sascha

-- System Information:
Debian Release: 8.8
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, 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 spice-client depends on:
ii  libasound2   1.0.28-1
ii  libc62.19-18+deb8u9
ii  libgcc1  1:4.9.2-10
ii  libjpeg62-turbo  1:1.3.1-12
ii  libopus0 1.1-2
ii  libpixman-1-00.32.6-3
ii  libssl1.0.0  1.0.1t-1+deb8u6
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxinerama1 2:1.1.3-1+b1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

spice-client recommends no packages.

spice-client suggests no packages.

-- no debconf information

Bug#862083: firejail: crashes when using --allow-debuggers ("free(): invalid pointer")

[Sascha Silbe]

Package: firejail
Version: 0.9.44.8-1~bpo8+1
Severity: normal

Dear Maintainer,

when passing --allow-debuggers to firejail to enable strace or gdb to
work inside firejail (in order to figure out why the sandboxed
application doesn't work), firejail crashes immediately on start-up:

sascha.silbe@twin:~$ firejail --allow-debuggers echo ok
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-passwdmgr.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 8465, child pid 8466
*** Error in `firejail': free(): invalid pointer: 0x55b39282d354 ***
Error: cannot establish communication with the parent, exiting...
sascha.silbe@twin:~$


-- System Information:
Debian Release: 8.8
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, 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 firejail depends on:
ii  libapparmor1  2.9.0-3
ii  libc6 2.19-18+deb8u9

Versions of packages firejail recommends:
ii  iptables1.4.21-2+b1
ii  xauth   1:1.0.9-1
ii  xpra0.14.10+dfsg-1
ii  xserver-xephyr  2:1.16.4-1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed:
xephyr-screen 1280x720


-- no debconf information

Bug#861272: fdroidserver: Backport of fdroidserver does not work with aapt from Jessie

[Sascha Silbe]

Package: fdroidserver
Version: 0.7.0-1~bpo8+1
Severity: important

Dear Maintainer,

the Jessie backport of fdroidserver has only an unversioned recommend
on aapt, so the Jessie version gets pulled in. "fdroid update" chokes
on the output of "aapt dump badging ", particularly the
"uses-permissions:" line:

=== Begin ===
sascha.silbe@twin:~/somewhere$ fdroid update --create-metadata
CRITICAL: Unknown exception found!
Traceback (most recent call last):
  File "/usr/bin/fdroid", line 147, in 
main()
  File "/usr/bin/fdroid", line 124, in main
mod.main()
  File "/usr/lib/python3/dist-packages/fdroidserver/update.py", line 1397, in 
main
apks, cachechanged = scan_apks(apps, apkcache, repodirs[0], knownapks, 
options.use_date_from_apk)
  File "/usr/lib/python3/dist-packages/fdroidserver/update.py", line 639, in 
scan_apks
perm_match = re.match(permission_pat, line).groupdict()
AttributeError: 'NoneType' object has no attribute 'groupdict'
=== End ===

This is the pattern it uses to match:

permission_pat = 
re.compile(".*(name='(?P.*?)')(.*maxSdkVersion='(?P.*?)')?.*")


These are the actual uses-permission: output lines from aapt:

uses-permission:'android.permission.WRITE_EXTERNAL_STORAGE'
uses-permission:'android.permission.ACCESS_FINE_LOCATION'
uses-permission:'android.permission.INTERNET'
uses-permission:'android.permission.READ_EXTERNAL_STORAGE'


aapt from Stretch isn't installable (requires libstdc++6 from
Stretch), but pointing fdroid at a copy of the Android SDK managed by
Android Studio worked fine:

=== Begin ===
sascha.silbe@twin:~/somewhere$ ANDROID_HOME="${HOME}/android-jail/Android/Sdk" 
fdroid update --create-metadata
INFO: Generated skeleton metadata for some.package.id
INFO: Creating signed index with this key (SHA256):
[...]
INFO: Finished.
=== End ===

So it looks like aapt from Jessie is too old for the fdroidserver
package in jessie-backports.

As the bug affects the primary use case (creating and publishing an
F-Droid repository) but there is a work-around (albeit using non-free
software) I've set the severity to important. Please adjust if you
disagree with my assessment.

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, 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 fdroidserver depends on:
ii  default-jdk 2:1.7-52
ii  openjdk-7-jdk   7u121-2.6.8-2~deb8u1
ii  python3 3.4.2-2
ii  python3-clint   0.3.7-1
ii  python3-libcloud0.15.1-1
ii  python3-paramiko1.15.1-1
ii  python3-pil 2.6.1-2+deb8u3
ii  python3-pyasn1  0.1.9-1~bpo8+1
ii  python3-pyasn1-modules  0.0.5-0.1
ii  python3-requests2.4.3-6
ii  python3-yaml3.11-2
pn  python3:any 
ii  rsync   3.1.1-3

Versions of packages fdroidserver recommends:
ii  aapt  21-2
pn  adb   
ii  git   1:2.11.0-2
ii  opensc0.14.0-2
ii  zipalign  21-4

Versions of packages fdroidserver suggests:
ii  bzr  2.6.0+bzr6595-6
pn  gradle   
pn  maven
ii  mercurial3.1.2-2+deb8u3
pn  php5 
ii  ruby 1:2.1.5+deb8u2
ii  subversion   1.8.10-6+deb8u4
pn  vagrant  
pn  vagrant-cachier  
pn  vagrant-libvirt  
pn  virtualbox   

-- no debconf information

Bug#858048: [Pkg-tigervnc-devel] Bug#858048: tigervnc: Outdated build dependencies

[Sascha Silbe]

Dear Ola,

Ola Lundqvist  writes:

> Thank you for the report.
>
> Just a check. These two problems you reported, they are specific to jessie,
> right?

I suppose so. Haven't tried building on Stretch or Sid. But since both
ship recent enough versions of the relevant packages, it shouldn't fail
to build there.

BTW, the backport seems to be running fine for now. The only dependency
I needed to backport was fltk1.3 (no changes required); all other
packages can be taken as-is from Stretch. Given that tigervnc didn't
make it into Jessie, an official backport would be nice.

Sascha


signature.asc
Description: PGP signature

Bug#858048: tigervnc: Outdated build dependencies

[Sascha Silbe]

Source: tigervnc
Version: 1.7.0+dfsg-6~bpo8+1
Severity: minor

Dear Maintainer,

while building a local backport of tigervnc to jessie, I noticed that
some of the build dependencies were too lax. At least the following
are now required:

=== Begin ===
x11proto-core-dev (>= 7.0.31),
x11proto-randr-dev (>= 1.5.0),
xtrans-dev (>= 1.3.5),
libxfont-dev (>= 1:2.0.1),
libtool (>= 2.4.6-2),
=== End ===

Also debian/gbp.conf doesn't set the compression method for the
upstream tarball, so git-buildpackage fails with a less than perfect
error message by default. Adding the following line to debian/gbp.conf
helped:

=== Begin ===
compression = xz
=== End ===


Sascha

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#857031: cabal-install: Please update backport to 1.24.x

[Sascha Silbe]

Package: cabal-install
Version: 1.22.6.0-2~bpo8+1
Severity: normal

Dear Maintainer,

the versions of cabal-install in jessie and jessie-backports contain
severe memory leaks, causing systems with "only" 512MiB RAM (e.g. ARM
based servers, some VMs / virtual servers) to run out of memory during
"cabal update". According to the upstream changelog, the memory leaks
are supposed to be fixed since 1.24.0.0 (see #2826, #2914, #2916), so
an updated backport would be great.

Thanks in advance.

Sascha

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, 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 cabal-install depends on:
ii  ghc [libghc-cabal-dev]  7.10.3-6~bpo8+2
ii  libc6   2.19-18+deb8u7
ii  libffi6 3.1-2+b2
ii  libgmp102:6.0.0+dfsg-6
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages cabal-install recommends:
ii  ghc  7.10.3-6~bpo8+2

cabal-install suggests no packages.

-- no debconf information

Bug#854499: git-daemon-sysvinit: unconditionally enables --verbose, causing IP addresses to be logged

[Sascha Silbe]

Package: git-daemon-sysvinit
Version: 1:2.1.4-2.1+deb8u2
Severity: normal

Dear Maintainer,

/etc/init.d/git-daemon always passes the --verbose option to
git-daemon. Since there is no corresponding option like --quiet that
would be able to counter it, there's no way to disable IP address
logging without modifying /etc/init.d/git-daemon itself.

Instead --verbose should be included in GIT_DAEMON_OPTIONS in the
default /etc/default/git-daemon file so that the user can remove it.

Logging IP addresses can be problematic within the EU due to privacy
laws, especially since git-daemon-sysvinit is usually used to provide a
public, unauthenticated service (thus no need to identify the user) and
without a way to inform the user about the privacy policy.

Sascha

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.8.17-wandboard-29-2-g49a7648fc7ba (SMP w/4 CPU cores; 
PREEMPT)
Locale: LANG=en_GB.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 git-daemon-sysvinit depends on:
ii  adduser  3.113+nmu3
ii  git  1:2.1.4-2.1+deb8u2

git-daemon-sysvinit recommends no packages.

git-daemon-sysvinit suggests no packages.

-- Configuration Files:
/etc/default/git-daemon changed:
GIT_DAEMON_ENABLE=true
GIT_DAEMON_USER=gitdaemon
GIT_DAEMON_BASE_PATH=/var/lib/git
GIT_DAEMON_DIRECTORY=/var/lib/git
GIT_DAEMON_OPTIONS=""

/etc/init.d/git-daemon changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/lib/git-core
DESC="git-daemon service"
NAME=git-daemon
DAEMON=/usr/lib/git-core/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
[ -e /usr/share/git-core/sysvinit/sentinel ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
GIT_DAEMON_USER=${GIT_DAEMON_USER:-gitdaemon}
GIT_DAEMON_BASE_PATH=${GIT_DAEMON_BASE_PATH:-/var/lib}
GIT_DAEMON_DIRECTORY=${GIT_DAEMON_DIRECTORY:-/var/lib/git}
DAEMON_ARGS="--user=$GIT_DAEMON_USER --pid-file=$PIDFILE --detach"
DAEMON_ARGS="$DAEMON_ARGS --reuseaddr $GIT_DAEMON_OPTIONS"
DAEMON_ARGS="$DAEMON_ARGS --base-path=$GIT_DAEMON_BASE_PATH 
$GIT_DAEMON_DIRECTORY"
. /lib/init/vars.sh
. /lib/lsb/init-functions
do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 
--test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
}
do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
case "$1" in
  start)
if [ $GIT_DAEMON_ENABLE = true ]; then
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC " "$NAME"
else
[ "$VERBOSE" != no ] && log_warning_msg "$NAME not enabled in 
/etc/default/$NAME, not starting..."
exit 0
fi
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
  ;;
  stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  status)
   status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
   ;;
  restart|force-reload)
if [ $GIT_DAEMON_ENABLE != true ]; then
[ "$VERBOSE" != no ] && log_warning_msg "$NAME not enabled in 
/etc/default/$NAME, stopping..."
do_stop
case "$?" in
  0|1)
log_end_msg 0 ;;
  *)
log_end_msg 1 ;;
esac
exit
fi
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
  0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
  *)
# Failed to stop
log_end_msg 1
;;
esac
;;
  *)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
  

Bug#854313: bleygraph needs python-matplotlib, cannot handle dbconfig-common.conf

[Sascha Silbe]

Package: bley
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

tried to run bleygraph; ran into two issues:

1. bleygraph needs python-matplotlib, but the bley package doesn't
   depend on (or even just suggest) it:

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 92, in 
   import matplotlib
   ImportError: No module named matplotlib

2. bleygraph apparently doesn't cope with the database config being
   split out to dbconfig-common.conf. Depending on how it's invoked,
   it either uses the (incorrect) database configuration from
   bley.conf or chokes trying to parse dbconfig-common.conf:

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 103, in 
   db = database.connect(**dbsettings)
   sqlite3.OperationalError: unable to open database file

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley -c /etc/bley/bley.conf 
-c /etc/bley/dbconfig-common.conf
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 97, in 
   dnswl_threshold  = config.getint('bley', 'dnswl_threshold')
 File "/usr/lib/python2.7/ConfigParser.py", line 359, in getint
   return self._get(section, int, option)
 File "/usr/lib/python2.7/ConfigParser.py", line 356, in _get
   return conv(self.get(section, option))
 File "/usr/lib/python2.7/ConfigParser.py", line 618, in get
   raise NoOptionError(option, section)
   ConfigParser.NoOptionError: No option 'dnswl_threshold' in section: 'bley'

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley -c 
/etc/bley/dbconfig-common.conf -c /etc/bley/bley.conf 
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 103, in 
   db = database.connect(**dbsettings)
   sqlite3.OperationalError: unable to open database file

   sascha@outpost:~$ sudo -u bley ls -l /var/lib/bley 
   total 736
   -rw-r- 1 bley bley 749568 Feb  5 23:32 bley
   -rw-r--r-- 1 bley bley  0 Feb  5 23:38 bley.db

   After modifying bley.conf to match dbconfig-common.conf and
   changing to the database directory first (it apparently ignores
   the dbpath setting), I finally got bleygraph to work:

   sascha@outpost:~$ sudo -u bley sh -c 'cd /var/lib/bley && bleygraph -d 
/tmp/bley -c /etc/bley/bley.conf '
   plotting 12h:
- /tmp/bley/ar-12h.png
- /tmp/bley/ch-12h.png
   plotting 24h:
- /tmp/bley/ar-24h.png
- /tmp/bley/ch-24h.png
   plotting 7d:
- /tmp/bley/ar-7d.png
- /tmp/bley/ch-7d.png
   plotting 28d:
- /tmp/bley/ar-28d.png
- /tmp/bley/ch-28d.png
   plotting 365d:
- /tmp/bley/ar-365d.png
- /tmp/bley/ch-365d.png
   

Sascha

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#853216: rsyslog: mmanom does not anonymise IPv6 addresses

[Sascha Silbe]

Package: rsyslog
Version: 8.4.2-1+deb8u2
Severity: normal

Dear Maintainer,

rsyslog ships the mmanom module which is useful for stripping IP
addresses from log messages for services that do not offer log format
customisation themselves. Unfortunately it doesn't support IPv6, so
it's of no use for IPv6 enabled services which should be pretty much
everything these days.

Depending on the circumstances, anonymising log messages may be
required by data protection law (or "just" be best practice) so having
an easy way for administrators to do this is important.

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, 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 rsyslog depends on:
ii  init-system-helpers  1.22
ii  initscripts  2.88dsf-59
ii  libc62.19-18+deb8u7
ii  libestr0 0.1.9-1.1
ii  libjson-c2   0.11-4
ii  liblogging-stdlog0   1.0.4-1
ii  liblognorm1  1.0.1-3
ii  libuuid1 2.25.2-6
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages rsyslog recommends:
ii  logrotate  3.8.7-1+b1

Versions of packages rsyslog suggests:
ii  rsyslog-doc8.4.1-1
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

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

-- no debconf information

Bug#853185: gatling: No simple way to disable logging of IP addresses

[Sascha Silbe]

Package: gatling
Version: 0.13-5+b3
Severity: normal

Dear Maintainer,

there's no way to disable logging of IP addresses in gatling itself as
all the logging is hard-coded. As logging is done to a custom log file
rather than via syslog, filtering via the syslog daemon isn't possible
either. The only way to add a post-processing filter is by hacking the
init script or disabling the init script and using a custom setup
(e.g. a hand-crafted systemd unit file). So disabling logging of IP
addresses for gatling on a given system requires a considerable amount
of work.

>From a technical point of view, this is fine. Logging of IP addresses
is very useful for debugging. From a legal point view, it's
problematic at best for public facing servers in at least Germany and
often advised against by lawyers and data protection officials (see
e.g. [1]). To be on the safe side (and to be privacy friendly),
administrators may want to disable logging of IP addresses entirely
(like libapache2-mod-removeip does for Apache) or put them through a
custom filter (that might e.g. filter out all IP addresses that are
not on an explicit white list containing company-internal IP
addresses).

Sascha

[1] https://www.datenschutzzentrum.de/ip-adressen/index.html

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#548880: closed by Julien Cristau <jcris...@debian.org> (Bug#548880: fixed in debootstrap 1.0.85)

[Sascha Silbe]

Dear Ansgar, dear Julien,

Debian Bug Tracking System <ow...@bugs.debian.org> writes:

[...]
>  debootstrap (1.0.85) unstable; urgency=medium
[...]
>[ Ansgar Burchardt ]
[...]
>* Error out when seeing short options. (Closes: #548880)

Kudos!

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr.: DE281696641


signature.asc
Description: PGP signature

Bug#825861: freecad: After update to 0.16 design contents are "invisible", ViewProvider2DObjectPython on console

[Sascha Silbe]

Package: freecad
Version: 0.16+dfsg2-1~bpo8+1
Severity: important

Dear Maintainer,

thanks for providing a backport for 0.16! Unfortunately after
updating, I cannot load my document created with the 0.15.4671
backport anymore.

When loading my "old" document, the 3D view continues to show the
start page, even though the tab for my document is active. In
addition, the following errors appear on the terminal I started
FreeCAD on:

=== Begin ===
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d487c0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d1f990 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d487c0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a025a0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4da6940 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a025a0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d17b90 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4da6440 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d17b90 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d09b20 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4ca4420 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d09b20 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d214a0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d33cb0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d214a0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a48c30 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a63840 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a48c30 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a5fc10 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a035a0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a5fc10 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a9c0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a62950 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a9c0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a843b0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4c818f0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a843b0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a020 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d67a30 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a020 

Bug#581039: tightvnc: Version 2.7.10 available by now; fixes key bindings for Mac OS X vnc server

[Sascha Silbe]

Dear Ola,

Ola Lundqvist o...@inguza.com writes:

 I'll see what I can do. The package is up for adoption as I have little
 spare time (kids...), but I'll see if I can get some free time some day.

TL;DR: TightVNC 2.x is Windows-only. Cannot send Option key with any
   non-Apple VNC viewer to the built-in Mac OS X VNC server.

When trying to install TightVNC 2.7.10 locally for the time being, we
noticed that there actually is no TightVNC for Unix anymore, despite
what the home page says. There is TightVNC 2.7.10 for Windows and there
is the TightVNC Java Viewer 2.7.2. That's it. :-/

We got TigerVNC installed locally, but couldn't get the Option key to
work at all using any of the key symbols that were mentioned anywhere
related to VNC on Mac OS X or that might have made sense in this context
(Meta_L/R, Alt_L/R, Hyper_L/R, ISO_Level3_Shift, Mode_switch,
Menu). Even if we send the same sequence (xte 'keydown Shift_L'
'keydown Meta_L' 'sleep 1' 'keyup Shift_L' 'keyup Alt_L') the built-in
Mac OS X VNC client sends when connected to vnc4server running on Linux,
it doesn't work. So AFAICT there's no way for a non-Apple VNC viewer
that will make the built-in VNC server of Mac OS X trigger an Option key
press (it does work using the built-in Apple VNC viewer). Anyone who got
the Option key to work probably is using a third-party VNC server on the
Mac OS X side.

We've given up on controlling the Mac via VNC for now as there were
other issues as well (dragging something in Xcode didn't work and there
were no apparent other ways of achieving the same result). Might try
again using a third party VNC server some other time.

So while having TigerVNC (not TightVNC as there is no Unix version
anymore) in Debian would be great, it doesn't really solve the Option
key issue. The fix in TightVNC 2.7.10 is probably for the Windows
TightVNC viewer to properly send the Windows key (Super_L). The VNC
viewers available in Debian already send the key presses as-is, it's the
server side that doesn't handle them correctly.

Sascha


signature.asc
Description: PGP signature

Bug#581039: tightvnc: Version 2.7.10 available by now; fixes key bindings for Mac OS X vnc server

[Sascha Silbe]

Source: tightvnc
Followup-For: Bug #581039

Dear Maintainer,

it would be really great to have the latest upstream release (version
2.7.10 from 2013-07-24) packaged. Besides tons of other changes
compared to 1.3.9, it supposedly fixes sending Option key presses
(Windows key on the local side) to remote native (i.e. built-in) Mac
OS X VNC servers.

(Sorry, can't help with packaging — completely booked out myself. I'd
be happy to test the package if somebody else prepares one, though).

Thanks for taking care of TightVNC in Debian for so long; it's been of
great help!

Sascha

-- System Information:
Debian Release: 7.8
  APT prefers stable
  APT policy: (990, 'stable'), (990, 'oldstable'), (500, 'oldstable-updates'), 
(500, 'stable'), (100, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Bug#787001: pgrep/pkill: incorrect return code on syntax error

[Sascha Silbe]

Package: procps
Version: 1:3.3.3-3
Severity: normal
File: /usr/bin/pgrep

Dear Maintainer,

the manual page states that in case of a syntax error, pgrep / pkill
with return with an exit status of 2. This is useful to distinguish
between proper operation (but no match found) and incorrect usage.

However, the actual behaviour differs from that. pgrep / pkill return
with an exit code of 1 in case of a syntax error:

=== Begin ===
sascha.silbe@mimosa:~$ pgrep --foobar foobar ; echo $?
pgrep: unrecognized option '--foobar'

Usage:
 pgrep [options] pattern

Options:
 -c, --count   count of matching processes
 -d, --delimeter string  specify output delimeter
 -l, --list-name   list PID and process name
 -v, --inverse negates the matching
 -f, --fulluse full process name to match
 -g, --pgroup id,... match listed process group IDs
 -G, --group gid,... match real group IDs
 -n, --newest  select most recently started
 -o, --oldest  select least recently started
 -P, --parent ppid,...   match only childs of given parent
 -s, --session sid,...   match session IDs
 -t, --terminal tty,...  match by controlling terminal
 -u, --euid id,...   match by effective IDs
 -U, --uid id,...match by real IDs
 -x, --exact   match exectly with command name
 -F, --pidfile file  read PIDs from file
 -L, --logpidfile  fail if PID file is not locked

 -h, --help display this help and exit
 -V, --version  output version information and exit

For more details see pgrep(1).
1
sascha.silbe@mimosa:~$ pkill --foobar foobar ; echo $?
pkill: unrecognized option '--foobar'

Usage:
 pkill [options] pattern

Options:
 -sig, --signal sigsignal to send (either number or name)
 -e, --echodisplay what is killed
 -f, --fulluse full process name to match
 -g, --pgroup id,... match listed process group IDs
 -G, --group gid,... match real group IDs
 -n, --newest  select most recently started
 -o, --oldest  select least recently started
 -P, --parent ppid,...   match only childs of given parent
 -s, --session sid,...   match session IDs
 -t, --terminal tty,...  match by controlling terminal
 -u, --euid id,...   match by effective IDs
 -U, --uid id,...match by real IDs
 -x, --exact   match exectly with command name
 -F, --pidfile file  read PIDs from file
 -L, --logpidfile  fail if PID file is not locked

 -h, --help display this help and exit
 -V, --version  output version information and exit

For more details see pgrep(1).
1
=== End ===

The latest version in jessie and sid (2:3.3.9-9) is still affected.

This was apparently fixed upstream in procps 3.2.8 (released 2009),
got broken again in procps-ng 3.3.2 (released 2012) and should be
fixed again in procps-ng 3.3.10 (released 2014).

Kind regards,
Sascha

-- System Information:
Debian Release: 7.8
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (1, 'experimental')
Architecture: armel (armv7l)

Kernel: Linux 3.0.19-mimosa-8-01603-g1b85fba (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages procps depends on:
ii  initscripts   2.88dsf-41+deb7u1
ii  libc6 2.13-38+deb7u8
ii  libgcc1   1:4.7.2-5
ii  libncurses5   5.9-10
ii  libncursesw5  5.9-10
ii  libprocps01:3.3.3-3
ii  libtinfo5 5.9-10
ii  lsb-base  4.1+Debian8+deb7u1

Versions of packages procps recommends:
ii  psmisc  22.19-1+deb7u1

procps 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#775953: openntpd if-up.d hook can cause system boot to hang indefinitely

[Sascha Silbe]

Hello Dererk,

Dererk der...@debian.org writes:

 I'm trying to reproduce this, and trying to understand your working
 environment, which seems to be an armel architecture of an ARMv5tel device.
 Is your device being able to be emulated by qemu or some equivalent
 tool? What physical device is that?

Thanks for looking into this. This report is for Debian Wheezy on an
OpenRD-Base. I've seen similar hangs before even on x86 hardware, but as
I haven't investigated them in detail at the time I cannot be sure it's
the same issue. A quick attempt at reproducing it using an amd64 VM
(using an image provided by aurel32 [1]) failed, i.e. openntpd didn't
hang even when configured as described and with the network adapter
deactivated, unconnected on the host side or just the default route deleted
manually.

This was on a production server that I'd prefer not to touch for further
testing. I have some boards I can use for testing (Wandboard Quad and
OpenRD-Client), but unfortunately they are still in their moving box. I
can give it another try once they're back in operation, but that may
take quite a while. :-/

FWIW, lowering the severity is fine with me. It seems like it's not too
easy to reproduce, so shouldn't bite too many others. And if it happens
to anyone else, they'll at least find the work-around in the bug log and
can hopefully also provide additional information.

Sascha

[1] https://people.debian.org/~aurel32/qemu/amd64/


signature.asc
Description: PGP signature

Bug#775953: openntpd if-up.d hook can cause system boot to hang indefinitely

[Sascha Silbe]

Package: openntpd
Version: 20080406p-4
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

when
a) openntpd is configured to listen on some interface and
b) openntpd is configured to step the time on start-up and
c) the DNS servers are not reachable for any reason,

the openntpd if-up.d hook will delay system boot indefinitely. Even in
single-user mode neither sshd nor a login shell are started before this
happens.

Excerpt from console log (manually killing ntpd using the OOM killer via
magic SysRq):

=== Begin ===
[] Configuring network interfaces...device lan0 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): lanbr: link is not ready

Waiting for lanbr to get ready (MAXWAIT is 32 seconds).
u32 classifier
Performance counters on
input device check on
Actions configured
Mirror/redirect action on
Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
mv643xx_eth_port mv643xx_eth_port.0 lan0: link up, 1000 Mb/s, full duplex, flow 
control disabled
lanbr: port 1(lan0) entered forwarding state
lanbr: port 1(lan0) entered forwarding state
IPv6: ADDRCONF(NETDEV_CHANGE): lanbr: link becomes ready
Starting rpcbind daemon...Already running..
Starting NFS common utilities: statd idmapd.
mount.nfs4: Failed to resolve server bbox: Name or service not known
Restarting openntpd: ntp_adjtime returns frequency of 52.990387ppm
lanbr: port 1(lan0) entered forwarding state

--- BREAK active ---
--- BREAK inactive ---
SysRq : Manual OOM execution
kworker/0:4 invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
CPU: 0 PID: 161 Comm: kworker/0:4 Not tainted 3.18.0-openrd-1-1-gff3a1b1 #16
Workqueue: events moom_callback
[c0013674] (unwind_backtrace) from [c00107e0] (show_stack+0x10/0x14)
[c00107e0] (show_stack) from [c077b514] (dump_header.isra.15+0x50/0x154)
[c077b514] (dump_header.isra.15) from [c00a16e0] 
(oom_kill_process+0xa0/0x374)
[c00a16e0] (oom_kill_process) from [c00a1e04] (out_of_memory+0x2d8/0x320)
[c00a1e04] (out_of_memory) from [c03d1b44] (moom_callback+0x20/0x28)
[c03d1b44] (moom_callback) from [c0032460] (process_one_work+0x1c4/0x370)
[c0032460] (process_one_work) from [c00328f0] (worker_thread+0x2b8/0x440)
[c00328f0] (worker_thread) from [c0035ea0] (kthread+0xb8/0xcc)
[c0035ea0] (kthread) from [c000de10] (ret_from_fork+0x14/0x24)
Mem-info:
Normal per-cpu:
CPU0: hi:  186, btch:  31 usd:  61
active_anon:770 inactive_anon:31 isolated_anon:0
 active_file:3066 inactive_file:2094 isolated_file:0
 unevictable:471 dirty:0 writeback:0 unstable:0
 free:116988 slab_reclaimable:1298 slab_unreclaimable:1042
 mapped:908 shmem:54 pagetables:99 bounce:0
 free_cma:0
Normal free:467952kB min:2848kB low:3560kB high:4272kB active_anon:3080kB 
inactive_anon:124kB active_file:12264kB inactive_file:8376kB unevictable:1884kB 
isolated(anon):0kB isolated(file):0kB present:524288kB managed:507456kB 
mlocked:1884kB dirty:0kB writeback:0kB mapped:3632kB shmem:216kB 
slab_reclaimable:5192kB slab_unreclaimable:4168kB kernel_stack:720kB 
pagetables:396kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 124*4kB (UEM) 78*8kB (UEM) 67*16kB (UEM) 19*32kB (UEM) 6*64kB (UEM) 
7*128kB (UEM) 4*256kB (UE) 2*512kB (U) 1*1024kB (U) 5*2048kB (UEM) 110*4096kB 
(MR) = 467952kB
5595 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
131072 pages of RAM
117226 free pages
4208 reserved pages
2025 slab pages
271341 pages shared
0 pages swap cached
[ pid ]   uid  tgid total_vm  rss nr_ptes swapents oom_score_adj name
[  190] 0   190  537  176   50 0 init
[  191] 0   191  437  276   40 0 rc
[  200] 0   200  504  472   50 0 startpar
[  314] 0   314  697  516   50 -1000 udevd
[  428] 0   428  696  438   50 -1000 udevd
[  432] 0   432  696  438   50 -1000 udevd
[  618] 0   618  545  305   60 0 bootlogd
[  619] 0   619  423  324   40 0 startpar
[ 1797] 0  1797  437  267   40 0 networking
[ 1805] 0  1805  425  285   40 0 ifup
[ 1974] 0  1974  588  434   50 -1000 rpcbind
[ 1997]   104  1997  668  540   50 -1000 rpc.statd
[ 2021] 0  2021  702  354   50 -1000 rpc.idmapd
[ 2133] 0  2133  437  299   50 0 sh
[ 2134] 0  2134  418  269   40 0 run-parts
[ 2230] 0  2230  437  297   50 0 openntpd
[ 2232] 0  2232  437  286   40 0 invoke-rc.d
[ 2249] 0  2249  437  266   40

Bug#775953: openntpd: no longer happens with wheezy-backports version

[Sascha Silbe]

Package: openntpd
Followup-For: Bug #775953

Dear Maintainer,

after upgrading to the openntpd version from wheezy-backports (no
other changes), the indefinite hang no longer occurs.

Kind regards,
Sascha

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 3.18.0-openrd-1-1-gff3a1b1
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openntpd depends on:
ii  adduser  3.113+nmu3
ii  libc62.13-38+deb7u6
ii  libssl1.0.0  1.0.1e-2+deb7u13
ii  netbase  5.0

openntpd recommends no packages.

openntpd suggests no packages.

-- Configuration Files:
/etc/default/openntpd changed:
DAEMON_OPTS=-s -f /etc/openntpd/ntpd.conf

/etc/openntpd/ntpd.conf changed:
listen on *
servers 0.debian.pool.ntp.org
servers 1.debian.pool.ntp.org
servers 2.debian.pool.ntp.org
servers 3.debian.pool.ntp.org


-- 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#766867: python-gevent: SSL support broken with current Python in Jessie (2.7.8)

[Sascha Silbe]

Package: python-gevent
Version: 1.0.1-1
Severity: normal

Dear Maintainer,

with current python2.7 (2.7.8-10) from Jessie, the SSL support in
python-gevent is broken for at least two reasons:

1. References no longer existing ssl._ssl.sslwrap()

   gevent.ssl.SSLSocket.connect() tries to use ssl._ssl.sslwrap() which
   no longer exists in Python 2.7.8 (it did exist in Python 2.7.3,
   shipped by wheezy):

   sascha@vm-android:~$ python
   Python 2.7.8 (default, Oct  7 2014, 17:59:21) 
   [GCC 4.9.1] on linux2
   Type help, copyright, credits or license for more information.
import gevent.ssl
import gevent.socket
sock = gevent.socket.socket()
ssl_sock = gevent.ssl.SSLSocket(sock)
ssl_sock.connect(('bugs.debian.org', 443))
   Traceback (most recent call last):
 File stdin, line 1, in module
 File /usr/lib/python2.7/dist-packages/gevent/ssl.py, line 329, in connect
   self._sslobj = _ssl.sslwrap(self._sock, False, self.keyfile, 
self.certfile,
   AttributeError: 'module' object has no attribute 'sslwrap'


2. References ssl.SSLContext which gets introduced by Python 2.7.9

   When given an already-connected socket, gevent.ssl.SSLSocket.__init__()
   tries to reference SSLContext which doesn't exist in Python 2.7.8 yet
   (gets introduced by 2.7.9):

   sascha@vm-android:~$ python
   Python 2.7.8 (default, Oct  7 2014, 17:59:21) 
   [GCC 4.9.1] on linux2
   Type help, copyright, credits or license for more information.
import gevent.ssl
import gevent.socket
sock = gevent.socket.socket()
sock.connect(('bugs.debian.org', 443))
ssl_sock = gevent.ssl.SSLSocket(sock)
   Traceback (most recent call last):
 File stdin, line 1, in module
 File /usr/lib/python2.7/dist-packages/gevent/ssl.py, line 84, in __init__
   ctx = SSLContext(ssl_version)
   NameError: global name 'SSLContext' is not defined


-- 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.16-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-gevent depends on:
ii  libc62.19-11
ii  python   2.7.8-1
ii  python-greenlet  0.4.2-1+b2

python-gevent recommends no packages.

Versions of packages python-gevent suggests:
pn  python-gevent-dbg  none
pn  python-gevent-doc  none
pn  python-openssl 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#747871: mkinitramfs: breaks with LUKS root on MMC (mkinitramfs: for root /dev/dm-0 missing mmcblk /sys/block/ entry) and MODULES=dep

[Sascha Silbe]

Package: initramfs-tools
Version: 0.109.1
Severity: normal
File: /usr/sbin/mkinitramfs

Dear Maintainer,

on a system with the rootfs living inside LUKS on an SD card,
mkinitramfs (and thus update-initramfs) fails with:

=== Begin ===
root@mimosa:/boot# update-initramfs -k 3.0.19-mimosa-8-01603-g1b85fba -c
update-initramfs: Generating /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba
mkinitramfs: for root /dev/dm-0 missing mmcblk /sys/block/ entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
update-initramfs: failed for /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba 
with 1.
=== End ===


Older versions displayed a warning (which I ignored since everything
needed for boot is built-in to the custom kernel anyway), but didn't
abort initramfs generation.

It looks like hook-functions is a bit overzealous in stripping down
the partition name to a device name, resulting in mmcblk rather than
mmcblk0. There's existing special casing in dep_add_modules for
device mapper (LVM/LUKS) on top of cciss or ida and for root on cciss,
ida, mmc and a few more in place already, but not for device mapper on
top of mmc. Maybe a recursive function would be a better fit for
determining the modules needed for the rootfs?

For reference, this is a trace of mkinitramfs:

=== Begin trace ===
+ CONFDIR=/etc/initramfs-tools
+ verbose=n
+ test -e /bin/busybox
+ BUSYBOXDIR=/bin
+ test -e /usr/lib/initramfs-tools/bin/busybox
+ export BUSYBOXDIR
++ getopt -o c:d:ko:r:v -n mkinitramfs -- -o 
/boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new 
3.0.19-mimosa-8-01603-g1b85fba
+ OPTIONS=' -o '\''/boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new'\'' -- 
'\''3.0.19-mimosa-8-01603-g1b85fba'\'''
+ '[' 0 '!=' 0 ']'
+ eval set -- ' -o '\''/boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new'\'' 
-- '\''3.0.19-mimosa-8-01603-g1b85fba'\'''
++ set -- -o /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new -- 
3.0.19-mimosa-8-01603-g1b85fba
+ true
+ case $1 in
+ outfile=/boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new
+ shift 2
+ true
+ case $1 in
+ shift
+ break
+ . /usr/share/initramfs-tools/scripts/functions
+ . /usr/share/initramfs-tools/hook-functions
+ . /etc/initramfs-tools/initramfs.conf
++ MODULES=dep
++ BUSYBOX=y
++ KEYMAP=n
++ COMPRESS=gzip
++ DEVICE=
++ NFSROOT=auto
+ EXTRA_CONF=
+ for i in '/usr/share/initramfs-tools/conf.d/*' '${CONFDIR}/conf.d/*'
+ '[' -e '/usr/share/initramfs-tools/conf.d/*' ']'
+ for i in '/usr/share/initramfs-tools/conf.d/*' '${CONFDIR}/conf.d/*'
+ '[' -e '/etc/initramfs-tools/conf.d/*' ']'
+ for i in '/usr/share/initramfs-tools/conf-hooks.d/*'
+ '[' -d /usr/share/initramfs-tools/conf-hooks.d/cryptsetup ']'
+ '[' -e /usr/share/initramfs-tools/conf-hooks.d/cryptsetup ']'
+ . /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
++ KEYMAP=y
++ BUSYBOX=y
++ FRAMEBUFFER=y
+ '[' -n '' ']'
+ '[' -z /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new ']'
+ touch /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new
++ readlink -f /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new
+ outfile=/boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new
+ '[' 1 -ne 1 ']'
+ version=3.0.19-mimosa-8-01603-g1b85fba
+ case ${version} in
+ case ${version} in
+ '[' -z '' ']'
+ compress=gzip
+ command -v gzip
+ dpkg --compare-versions 3.0.19-mimosa-8-01603-g1b85fba lt 2.6.38
+ '[' gzip = lzop ']'
+ '[' gzip = xz ']'
+ '[' -d /boot/initrd.img-3.0.19-mimosa-8-01603-g1b85fba.new ']'
+ MODULESDIR=/lib/modules/3.0.19-mimosa-8-01603-g1b85fba
+ '[' '!' -e /lib/modules/3.0.19-mimosa-8-01603-g1b85fba ']'
+ '[' '!' -e /lib/modules/3.0.19-mimosa-8-01603-g1b85fba/modules.dep ']'
+ '[' -n '' ']'
++ mktemp -d /var/tmp/mkinitramfs_XX
+ DESTDIR=/var/tmp/mkinitramfs_K8XasF
+ chmod 755 /var/tmp/mkinitramfs_K8XasF
+ NOEXEC=
++ tail -1
++ awk '{print $6}'
++ df -P /var/tmp/mkinitramfs_K8XasF
+ fs=/
+ '[' -n / ']'
+ grep -q 'on / .*noexec'
+ mount
++ mktemp /var/tmp/mkinitramfs-OL_XX
+ __TMPCPIOGZ=/var/tmp/mkinitramfs-OL_OuJNFs
++ dpkg --print-architecture
+ DPKG_ARCH=armel
+ export MODULESDIR
+ export version
+ export CONFDIR
+ export DESTDIR
+ export DPKG_ARCH
+ export verbose
+ export KEYMAP
+ export MODULES
+ export BUSYBOX
+ export __TMPCPIOGZ
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/bin
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/conf/conf.d
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/etc
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/lib/modules
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/run
+ for d in bin conf/conf.d etc lib/modules run sbin scripts '${MODULESDIR}'
+ mkdir -p /var/tmp/mkinitramfs_K8XasF/sbin
+ for d in bin conf/conf.d etc lib/modules run sbin 

Bug#738556: libaqbanking: Please package and backport 5.3.6beta

[Sascha Silbe]

Package: libaqbanking
Version: 5.3.5beta-2
Severity: important

Dear Maintainer,

please package 5.3.6beta and provide a backport of it for wheezy.

Aqbanking 5.3.6beta [1] fixes a bug that prevented interoperation with
some banks when using RDH-10. In addition, the aqbanking 5.2 and 5.3
series contain important fixes and enhancements for SEPA
interoperation. Many banks have already dropped non-SEPA support on
their HBCI servers, so the version currently in wheezy-backports is
insufficient for many (possibly most) HBCI users.

Thanks in advance.

Sascha

[1] 
http://www2.aquamaniac.de/sites/download/releasenote.php?package=03release=111

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Bug#717904: w3m: doesn't support IPv6 link-local addresses

[Sascha Silbe]

Package: w3m
Version: 0.5.3-8
Severity: normal

Dear Maintainer,

w3m works fine with URLs containing an IPv6 address of global
scope. However, when adding the interface specifier required for
link-local addresses, w3m completely mis-parses the URL. This is
apparent when using a proxy: w3m requests the URL http://[fe80:0/;
from the proxy, rather than the entered URL
http://[fe80::f2ad:4eff:fe00:6112%eth0]/;. Without a proxy, w3m
simply states that it can't load the URL without giving any reason.

The syntax for using IPv6 link-local addresses as part of URLs is
defined by RFC 6874 [1].

IPv6 link-local addresses are quite useful for interacting with
embedded devices. They require neither manual configuration (like
static IPv4 addresses do) nor additional equipment (like a DHCP server
for giving out IPv4 addresses).

Sascha

[1] http://www.rfc-editor.org/info/rfc6874

-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (100, 
'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages w3m depends on:
ii  libc62.17-7
ii  libgc1c2 1:7.1-9.1
ii  libgpm2  1.20.4-6
ii  libssl1.0.0  1.0.1e-2
ii  libtinfo55.9-10
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages w3m recommends:
ii  ca-certificates  20130119

Versions of packages w3m suggests:
ii  man-db2.6.2-1
ii  menu  2.1.46
pn  migemonone
ii  mime-support  3.52-1
ii  w3m-el1.4.4-11
ii  w3m-img   0.5.3-8

-- 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#696176: No problem here

[Sascha Silbe]

Filipus Klutiero chea...@gmail.com writes:

 I also use a Radeon HD 7660D (on A10-5700) and do not experience this 
 issue on my wheezy install (using Linux 3.8). Can you reproduce with 
 current versions?

Yes, I can still reproduce this using xserver-xorg-video-radeon
1:6.14.4-8 and linux-image-3.8-trunk-amd64 3.8.5-1~experimental.1.

Sascha


pgp2Nw9eOV5p7.pgp
Description: PGP signature

Bug#696176: [Fwd: Undelivered Mail Returned to Sender]

[Sascha Silbe]

Michel Dänzer daen...@debian.org writes:

 Not very nice...

 sascha-debian-bugs-xserver-xorg-video-radeon-2012-12...@silbe.org: host
 b.mx.chost.de[87.106.8.89] said: 534 Message header size, or recipient
 list, exceeds policy limit. (in reply to end of DATA command)

Not sure how you've hit this. Are you trying to transmit a large image
as part of the headers rather than as part of the content? ;)

Medium term I'll be going back to running my own primary MX again, which
won't have that limitation.


 [163321.388] (II) RADEON(0): GPU accel disabled or not working, using 
 shadowfb for KMS

 In the log file included in the bug report, acceleration isn't really
 enabled according to the above and related lines. Is this the case from
 the first time the X server starts after bootup, or only after a while
 (maybe related to the below)?

The log file got included automatically, after I switched back to the
non-accelerated configuration. Thought I had also attached a log file
with enabled acceleration, but can't see it on the tracker. I've
included the one from today (ColorTiling off, but NoAccel commented out)
below.


 DRM Information from dmesg:
 ---
 [77304.456255] [drm] PCIE GART of 512M enabled (table at 0x0004).
 [77304.474984] [drm] ring test on 0 succeeded in 3 usecs
 [77304.475541] [drm] ib test on ring 0 succeeded in 0 usecs
 [92065.412338] [drm] PCIE GART of 512M enabled (table at 0x0004).
 [92065.431039] [drm] ring test on 0 succeeded in 3 usecs
 [92065.431568] [drm] ib test on ring 0 succeeded in 0 usecs
 [...]

 This looks like the GPU keeps locking up. The basic symptoms of a GPU
 lockup and reset are: the display freezes for about 10 seconds, then the
 display blanks momentarily while the GPU is reset, then the display
 resumes. Have you noticed this, either when doing something in
 particular, or randomly?

No, I don't think any 10s freezes happened during normal
operation. Maybe the messages above were issued during a suspend/resume
cycle? Though I couldn't trigger them right now using
pm-suspend. Switching to an accelerated X server and back didn't trigger
it either.


 Does upgrading to libdrm-radeon1 2.4.40-1 from experimental help for
 this?

I'm currently running 2.4.40-1~deb7u2. If you think it might make a
difference I could try rebuilding 2.4.45-3 for wheezy (the sid one is
depending on the new libc already) and install it.


Thanks for looking into this!

Sascha

[1077359.633] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[1077359.633] X Protocol Version 11, Revision 0
[1077359.633] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
[1077359.633] Current Operating System: Linux twin 3.8-trunk-amd64 #1 SMP 
Debian 3.8.5-1~experimental.1 x86_64
[1077359.633] Kernel command line: BOOT_IMAGE=/vmlinuz-3.8-trunk-amd64 
root=/dev/mapper/twin_vg-wheezy--root ro rootflags=data=journal 
usbcore.autosuspend=1 snd_hda_intel.power_save=1 
resume=/dev/mapper/dmcrypt-swap-ssd console=tty0 console=ttyS0,115200 quiet
[1077359.633] Build Date: 17 April 2013  10:22:47AM
[1077359.633] xorg-server 2:1.12.4-6 (Julien Cristau jcris...@debian.org) 
[1077359.633] Current version of pixman: 0.26.0
[1077359.633]   Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[1077359.633] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[1077359.633] (==) Log file: /var/log/Xorg.0.log, Time: Fri Jun  7 09:54:24 
2013
[1077359.634] (==) Using config file: /etc/X11/xorg.conf
[1077359.634] (==) Using config directory: /etc/X11/xorg.conf.d
[1077359.634] (==) Using system config directory /usr/share/X11/xorg.conf.d
[1077359.635] (==) No Layout section.  Using the first Screen section.
[1077359.635] (==) No screen section available. Using defaults.
[1077359.635] (**) |--Screen Default Screen Section (0)
[1077359.635] (**) |   |--Monitor default monitor
[1077359.635] (==) No device specified for screen Default Screen Section.
Using the first device section listed.
[1077359.635] (**) |   |--Device ATI Technologies Inc ATI Default Card
[1077359.635] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[1077359.635] (==) Automatically adding devices
[1077359.635] (==) Automatically enabling devices
[1077359.635] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[1077359.635]   Entry deleted from font path.
[1077359.636] (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
[1077359.636]   Entry deleted from font path.
[1077359.636] (WW) The directory /usr/share/fonts/X11/75dpi does not exist.
[1077359.636]   Entry deleted from font path.
[1077359.636] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,

Bug#710672: python-webdav: Unsolicited use of persistent connections causes HTTP/1.0 clients to hang

[Sascha Silbe]

Package: python-webdav
Version: 0.9.8-3
Severity: normal

Dear Maintainer,

pywebdav uses persistent connections even for HTTP/1.0 GET requests
without a Connection: Keep-Alive header. This causes the client to
hang waiting for the connection to close. RFC2616 explicitly states
HTTP/1.1 servers must not assume HTTP/1.0 clients to support
persistent connections:

=== Begin RFC2616 excerpt ===
8.1.2.1 Negotiation
[...]
   Clients and servers SHOULD NOT assume that a persistent connection is
   maintained for HTTP versions less than 1.1 unless it is explicitly
   signaled. [...]
=== End RFC2616 excerpt ===


In addition, both a Connection: close and a Connection: Keep-Alive
header are sent and Date is sent twice:

=== Begin tcpflow dump ===
127.000.000.001.50660-127.000.000.001.08009: GET / HTTP/1.0
User-Agent: w3m/0.5.3+cvs-1.1055
Accept: text/html, text/*;q=0.5, image/*, */*
Accept-Encoding: Xgzip, compress, bzip, bzip2, deflate
Accept-Language: en;q=1.0
Host: localhost:8009
Pragma: no-cache
Cache-control: no-cache


127.000.000.001.08009-127.000.000.001.50660: HTTP/1.0 200 OK

127.000.000.001.08009-127.000.000.001.50660: Server: DAV/0.9.8 Python/2.7.3

127.000.000.001.08009-127.000.000.001.50660: Date: Sat, 01 Jun 2013 10:11:00 GMT

127.000.000.001.08009-127.000.000.001.50660: Connection: close

127.000.000.001.08009-127.000.000.001.50660: Accept-Ranges: bytes

127.000.000.001.08009-127.000.000.001.50660: Date: Sat, 01 Jun 2013 10:11:00 GMT

127.000.000.001.08009-127.000.000.001.50660: DAV: 1

127.000.000.001.08009-127.000.000.001.50660: Last-Modified: Sat, 01 Jun 2013 
10:11:00 GMT

127.000.000.001.08009-127.000.000.001.50660: Connection: Keep-Alive

127.000.000.001.08009-127.000.000.001.50660: Keep-Alive: timeout=15, max=86

127.000.000.001.08009-127.000.000.001.50660: Content-Length: 253

127.000.000.001.08009-127.000.000.001.50660: Content-Type: text/html; 
charset=utf-8

127.000.000.001.08009-127.000.000.001.50660: 

127.000.000.001.08009-127.000.000.001.50660: html
headtitleJournal listing/title/head
body
table
trthName/th/tr
trtda href=by-id/by-id//a/td/tr
trtda href=by-tags/by-tags//a/td/tr
trtda href=by-title/by-title//a/td/tr
/table
/html
=== End tcpflow dump ===


A quick patch for these issues:

=== Begin ===
--- WebDAVServer.py.old 2013-06-01 14:23:19.105319133 +0200
+++ WebDAVServer.py 2013-06-01 14:23:35.457092427 +0200
@@ -62,9 +62,9 @@
 log.debug(Use send_body method)
 
 self.send_response(code, message=msg)
-self.send_header(Connection, close)
+if 'Connection' not in headers:
+self.send_header(Connection, close)
 self.send_header(Accept-Ranges, bytes)
-self.send_header('Date', rfc1123_date())
 
 self._send_dav_version()
 
@@ -255,8 +255,9 @@
 self.send_body(data, status_code, None, None, content_type,
headers)
 else:
-headers['Keep-Alive'] = 'timeout=15, max=86'
-headers['Connection'] = 'Keep-Alive'
+if self.request_version == 'HTTP/1.1':
+headers['Keep-Alive'] = 'timeout=15, max=86'
+headers['Connection'] = 'Keep-Alive'
 self.send_body_chunks_if_http11(data, status_code, None, None,
 content_type, headers)
=== End ===


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

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

Versions of packages python-webdav depends on:
ii  python2.7.3-4
ii  python-pkg-resources  0.6.24-1

python-webdav recommends no packages.

python-webdav 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#710690: python-webdav: recursive allprops only yields a subset of properties

[Sascha Silbe]

Package: python-webdav
Version: 0.9.8-3
Severity: normal

Dear Maintainer,

when all properties for a resource and its children are requested,
pywebdav only returns the value of those properties that are also set
on requested collection itself. It does not return the properties that
are only on one of the children (or grandchildren for that
matter). Also, 404 is returned for any property that is on the
requested collection, but not on the current child.

The reason for this is that the list of property names is created once
in pywebdav.lib.propfind.PROPFIND.create_allprop() and applied to each
resource.


Here's a quick hack to fix it:

=== Begin ===
--- propfind.py.old 2013-06-01 17:03:19.031822359 +0200
+++ /usr/lib/python2.7/dist-packages/pywebdav/lib/propfind.py   2013-06-01 
17:08:50.0 +0200
@@ -66,7 +66,7 @@
 
 df = None
 if self.request_type == RT_ALLPROP:
-df = self.create_allprop()
+df = self.create_prop(allprop=True)
 
 if self.request_type == RT_PROPNAME:
 df = self.create_propname()
@@ -78,7 +78,7 @@
 return df
 
 # no body means ALLPROP!
-df = self.create_allprop()
+df = self.create_prop(allprop=True)
 return df
 
 def create_propname(self):
@@ -118,17 +118,7 @@
 
 return doc.toxml(encoding=utf-8)
 
-def create_allprop(self):
- return a list of all properties 
-self.proplist = {}
-self.namespaces = []
-for ns, plist in self._dataclass.get_propnames(self._uri).items():
-self.proplist[ns] = plist
-self.namespaces.append(ns)
-
-return self.create_prop()
-
-def create_prop(self):
+def create_prop(self, allprop=False):
  handle a prop request
 
 This will
@@ -156,16 +146,25 @@
 ms.tagName = 'D:multistatus'
 
 if self._depth == 0:
+if allprop:
+self.proplist = self._dataclass.get_propnames(self._uri)
+self.namespaces = self.proplist.keys()
 gp, bp = self.get_propvalues(self._uri)
 res = self.mk_prop_response(self._uri, gp, bp, doc)
 ms.appendChild(res)
 
 elif self._depth == 1:
+if allprop:
+self.proplist = self._dataclass.get_propnames(self._uri)
+self.namespaces = self.proplist.keys()
 gp, bp = self.get_propvalues(self._uri)
 res = self.mk_prop_response(self._uri, gp, bp, doc)
 ms.appendChild(res)
 
 for newuri in self._dataclass.get_childs(self._uri):
+if allprop:
+self.proplist = self._dataclass.get_propnames(newuri)
+self.namespaces = self.proplist.keys()
 gp, bp = self.get_propvalues(newuri)
 res = self.mk_prop_response(newuri, gp, bp, doc)
 ms.appendChild(res)
@@ -173,6 +172,9 @@
 uri_list = [self._uri]
 while uri_list:
 uri = uri_list.pop()
+if allprop:
+self.proplist = self._dataclass.get_propnames(uri)
+self.namespaces = self.proplist.keys()
 gp, bp = self.get_propvalues(uri)
 res = self.mk_prop_response(uri, gp, bp, doc)
 ms.appendChild(res)
=== End ===


Not sure why proplist and namespaces are instance variables rather
than getting passed as a parameter to get_propvalues() and why we
namespaces is a separate variable instead of just using
proplist.keys() in mk_propname_response(), so I haven't changed that.


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

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

Versions of packages python-webdav depends on:
ii  python2.7.3-4
ii  python-pkg-resources  0.6.24-1

python-webdav recommends no packages.

python-webdav 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#710697: python-webdav: no support for properties that are not plain XML-safe character strings (binary data, XML nodes)

[Sascha Silbe]

Package: python-webdav
Version: 0.9.8-3
Severity: wishlist

Dear Maintainer,

there's currently no way to return property values from
dav_interface.get_prop() that are anything else than plain characters
strings with no XML-unsafe characters. While
PROPFIND.mk_prop_response() would accept a xml.dom.minidom.Element or
even a list list of those, the Element can only be created from inside
mk_prop_response(): the xml.dom.minidom implementation requires the
Document object for instantiating Nodes, but
PROPFIND.mk_prop_response() and PROPFIND.get_propvalues() do not pass
the Document object down to dav_interface.get_prop().

I'm not sure what the best way to add support for non-string property
values would be. Passing the Document as another parameter to
get_prop() would break existing code using pywebdav. Maybe introducing
a new method get_prop2() and falling back to the one? If the check is
done outside the loop, it may be reasonably efficient.


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

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

Versions of packages python-webdav depends on:
ii  python2.7.3-4
ii  python-pkg-resources  0.6.24-1

python-webdav recommends no packages.

python-webdav 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#707564: minicom: please show config or device name in status bar

[Sascha Silbe]

Package: minicom
Version: 2.6.2-1
Severity: wishlist

Dear Maintainer,

I'm often using multiple minicom instances to work on multiple serial
ports (connected both to different devices and to different ports of
the same device) in parallel. Currently, it's hard to distinguish
these instances as they all look exactly the same. It would be quite
useful if minicom could display the name of the config or serial
device in use in the status bar.

Screen real estate is usually not an issue for me, but on systems
where it is, the minicom version could be dropped. If showing the name
of the serial device, it may need to be shortened (especially when
using /dev/serial/by-path/...). When showing the config name, that's
unlikely to be a problem (though not impossible).

Sascha

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

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

Versions of packages minicom depends on:
ii  libc6  2.13-38
ii  libtinfo5  5.9-10

Versions of packages minicom recommends:
ii  lrzsz  0.12.21-5

minicom 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#707564: minicom: please show config or device name in status bar

[Sascha Silbe]

Adam Lackorzynski a...@os.inf.tu-dresden.de writes:

 Starting minicom with -T will show the device name instead of the online
 time. I guess that's what you're looking for.

Thanks for the hint; I wouldn't have expected the option to have this
effect, based on the description in the manual page (Disable the
display of the online time in the status bar.). Perhaps a better
phrasing would be Show device name instead of online status in the
status bar. or Replace online status in status bar with device name.?

The option does almost what I need. Except that in the case I tested, it
cut off the most interesting part of the device name: the last digit
that indicates what port I'm on. The devices are named
/dev/serial/by-name/ll8p1 through /dev/serial/by-name/ll8p8. minicom
shows serial_by-name_ll8p for all of them. The terminal is 185
characters wide, so there's no reason for minicom to cut off the device
name. And if there would be, it should probably be stripping off the
head, not the tail, as in most cases the port number comes last
(ttyUSBn, ttySn, serial/by-path/pci*usb*usb-id-portn, ...).

Also, is there a way to enable this through configuration, rather than
setting up the environment (MINICOM)?

Sascha


pgpqUQJYkE3Hf.pgp
Description: PGP signature

Bug#699205: [3.7.1-3.7.3 regression] ps, pgrep and pkill segfault

[Sascha Silbe]

Version: 3.8.5-1~experimental.1

This doesn't happen with linux-image-3.8-trunk-amd64
3.8.5-1~experimental.1 (currently available from experimental). The
problematic kernel version (linux-image-3.7-trunk-amd64
3.7.3-1~experimental.1) isn't available from experimental anymore, so
I'm considering this fixed.

Kudos to whoever fixed it.

Sascha


pgpBt2rw5C7Yn.pgp
Description: PGP signature

Bug#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)

[Sascha Silbe]

Package: python3-serial
Version: 2.5-2.1
Severity: important

Dear Maintainer,

the RFC2217 support of pyserial, at least when used with Python 3, is
completely broken. Even just importing serial.rfc2217 fails:

=== Begin ===
sascha.silbe@twin:~$ python3
Python 3.2.3 (default, Feb 20 2013, 14:44:27) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial.rfc2217
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 90, in module
IAC_DOUBLED = to_bytes([IAC, IAC])
  File /usr/lib/python3/dist-packages/serial/serialutil.py, line 55, in 
to_bytes
b.append(item)  # this one handles int and str
TypeError: an integer is required
=== End ===

Importing serial.rfc2217 happens automatically when passing a
rfc2217:// URL to serial.serial_for_url():

=== Begin ===
sascha.silbe@twin:~$ python3
Python 3.2.3 (default, Feb 20 2013, 14:44:27) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial
 serial.serial_for_url('rfc2217://localhost:4001')
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/__init__.py, line 45, in 
serial_for_url
from . import rfc2217  # late import, so that users that don't use it don't 
have to load it
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 90, in module
IAC_DOUBLED = to_bytes([IAC, IAC])
  File /usr/lib/python3/dist-packages/serial/serialutil.py, line 55, in 
to_bytes
b.append(item)  # this one handles int and str
TypeError: an integer is required
=== End ===


I've verified that it still happens with python3-serial 2.6-1 from sid.


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

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

Versions of packages python3-serial depends on:
ii  python3  3.2.3-6

python3-serial recommends no packages.

Versions of packages python3-serial suggests:
pn  python3-wxgtk2.8 | python3-wxgtk  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#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)

[Sascha Silbe]

Sascha Silbe sascha-debian-bugs-pyserial-2013-05...@silbe.org writes:

 the RFC2217 support of pyserial, at least when used with Python 3, is
 completely broken. Even just importing serial.rfc2217 fails:
[...]


I managed to fix that part by replacing serial.serialutil.to_bytes()
with the following:

def to_bytes(seq):
convert a sequence to a bytes type
b = bytearray()
for item in seq:
if isinstance(item, bytes):
b.append(ord(item))
else:
b.append(item)
return bytes(b)


The previous comment about bytearray.append() also handling non-integers
is simply incorrect.


However, using python3-serial in RFC2217 mode with ser2net 2.6-1,
configured in RFC2217 mode (telnet + remctl; confirmed working using
microcom 2012.06.0-2), still fails:

=== Begin ===
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 436, in open
raise SerialException(Remote does not seem to support RFC2217 or BINARY 
mode %r % mandadory_options)
serial.serialutil.SerialException: Remote does not seem to support RFC2217 or 
BINARY mode [we-BINARY:False(INACTIVE), we-RFC2217:False(REQUESTED)]
=== End ===


Using Python 2 it works fine:

=== Begin ===
sascha.silbe@twin:~$ python
Python 2.7.3 (default, Jan  2 2013, 13:56:14) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial
 serial.serial_for_url('rfc2217://172.16.0.77:4001')
Serialid=0x2448e10, open=True(port='rfc2217://172.16.0.77:4001', 
baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, 
rtscts=False, dsrdtr=False)
 
=== End ===


It seems the Python 3 version does different things on the wire than the
Python 2 one:

=== Begin payload of network packets, using python2 ===
11.804968 192.168.1.2.55752  172.16.0.77.4001
fffd 01
11.805196 192.168.1.2.55752  172.16.0.77.4001
fffb 03
11.805383 192.168.1.2.55752  172.16.0.77.4001
fffd 03
11.805607 192.168.1.2.55752  172.16.0.77.4001
fffd 2c
11.805654 192.168.1.2.55752  172.16.0.77.4001
fffb 2c
11.854005 172.16.0.77.4001  192.168.1.2.55752
fffb 03ff fb01 fffe 01ff fd00
11.854234 192.168.1.2.55752  172.16.0.77.4001
fffb 00
11.874337 172.16.0.77.4001  192.168.1.2.55752
fffb 01ff fe03
11.884146 172.16.0.77.4001  192.168.1.2.55752
fffb 03ff fc2c fffa 2c6b 00ff f0ff fd2c
11.894046 172.16.0.77.4001  192.168.1.2.55752
fffd 00
11.906036 192.168.1.2.55752  172.16.0.77.4001
fffa 2c01  2580 fff0
11.906145 192.168.1.2.55752  172.16.0.77.4001
fffa 2c02 08ff f0
11.906197 192.168.1.2.55752  172.16.0.77.4001
fffa 2c03 01ff f0
11.906258 192.168.1.2.55752  172.16.0.77.4001
fffa 2c04 01ff f0
11.964215 172.16.0.77.4001  192.168.1.2.55752
fffa 2c65  2580 fff0 fffa 2c66 08ff f0
11.964244 172.16.0.77.4001  192.168.1.2.55752
fffa 2c67 01ff f0ff fa2c 6801 fff0
12.006749 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 01ff f0
12.034048 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 01ff f0
12.057067 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 0bff f0
12.094156 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 0bff f0
12.107393 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 08ff f0
12.144054 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 08ff f0
12.157701 192.168.1.2.55752  172.16.0.77.4001
fffa 2c0c 01ff f0
12.194055 172.16.0.77.4001  192.168.1.2.55752
fffa 2c70 01ff f0
12.208043 192.168.1.2.55752  172.16.0.77.4001
fffa 2c0c 02ff f0
12.244098 172.16.0.77.4001  192.168.1.2.55752
fffa 2c70 02ff f0
=== End payload of network packets, using python2 ===


=== Begin payload of network packets, using python3 ===
40.714514 192.168.1.2.55753  172.16.0.77.4001
fffd 01
40.714541 192.168.1.2.55753  172.16.0.77.4001
fffb 03
40.714556 192.168.1.2.55753  172.16.0.77.4001
fffd 03
40.714568 192.168.1.2.55753  172.16.0.77.4001
fffd 2c
40.714581 192.168.1.2.55753  172.16.0.77.4001
fffb 2c
40.754194 172.16.0.77.4001  192.168.1.2.55753
fffb 03ff fb01 fffe 01ff fd00
40.754251 172.16.0.77.4001  192.168.1.2.55753
fffb 01ff fe03
40.764074 172.16.0.77.4001  192.168.1.2.55753
fffb 03ff fc2c
40.764121 172.16.0.77.4001  192.168.1.2.55753
fffa 2c6b 00ff f0ff fd2c
=== End payload of network packets, using python3 ===


So either my fix above breaks other parts of the code or there's more
broken than just to_bytes(). A quick guess would be that python3-serial
doesn't recognise what sredird sends.

Sascha


pgpaxeXhVg6jE.pgp
Description: PGP signature

Bug#699914: python3-serial: TCP mode: data loss, timeout handling broken

[Sascha Silbe]

Package: python3-serial
Version: 2.5-2.1
Severity: normal

Dear Maintainer,

when used in TCP mode ('socket://address:port'), python3-serial
will loose most of the received characters. This is because
SocketSerial.read() _replaces_ the buffer instead of appending to it:

[...]
data = bytearray()
timeout = time.time() + self._timeout
while len(data)  size and time.time()  timeout:
try:
# an implementation with internal buffer would be better
# performing...
data = self._socket.recv(size - len(data))
except socket.timeout:
# just need to get out of recv form time to time to check if
# still alive
continue
except socket.error as e:
# connection fails - terminate loop
raise SerialException('connection failed (%s)' % e)
return bytes(data)


As a workaround, read() can be called with size=1, with the obvious
impact on performance.

There are a couple of additional bugs concerning timeout handling of
SocketSerial.read():

1. The socket timeout is hardcoded to 2 seconds. When setting smaller
   values with setTimeout(), read() will still wait for 2 seconds in
   most cases (i.e. unless there was data to be read and reading took
   longer than the timeout):

f.setTimeout(.1)
start_time=time.time(); f.read(); print(time.time() - start_time)
   b''
   2.0022289752960205

   With some protocols or tasks, 2 seconds can be way too long.


2. Not setting a timeout (the default is blocking mode) will cause
   read() to fail:

   Traceback (most recent call last):
 File stdin, line 1, in module
 File /usr/lib/python3/dist-packages/serial/socket_connection.py, line 
136, in read
   timeout = time.time() + self._timeout
   TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'


3. Setting timeout to 0 (non-blocking mode) causes read() to never
   return any data.

   The while loop won't do even a single iteration, so no chance to
   read from the socket.


While there has been some module level refactoring, pyserial 2.6 still
ships a SocketSerial class with the above bugs.

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

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

Versions of packages python3-serial depends on:
ii  python3  3.2.3-5

python3-serial recommends no packages.

Versions of packages python3-serial suggests:
pn  python3-wxgtk2.8 | python3-wxgtk  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#699218: procps: FTBFS with test suite error: testsuite/lib.test/fileutils_badfd.sh missing

[Sascha Silbe]

Package: procps
Version: 1:3.3.3-2
Severity: serious
Justification: FTBFS

Dear Maintainer,

in order to help diagnosing #699205, I need to rebuild procps with
debugging options as there's no pre-built -dbg package (hint,
hint). Unfortunately that fails with a test suite error, despite
nocheck being set in DEB_BUILD_OPTIONS:

=== Begin ===
sascha.silbe@twin:~/src/deb$ apt-get source procps/wheezy
sascha.silbe@twin:~/src/deb$ cd procps-3.3.3
sascha.silbe@twin:~/src/deb/procps-3.3.3$ DEB_BUILD_OPTIONS=nostrip noopt 
dpkg-buildpackage
[...]
=== lib tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./lib.test/fileutils.exp ...
ERROR: tcl error sourcing ./lib.test/fileutils.exp.
ERROR: couldn't execute 
/home/sascha.silbe/src/deb/procps-3.3.3/testsuite/lib.test/fileutils_badfd.sh:
 no such file or directory
while executing
spawn $badfd
(file ./lib.test/fileutils.exp line 13)
invoked from within
source ./lib.test/fileutils.exp
(uplevel body line 1)
invoked from within
uplevel #0 source ./lib.test/fileutils.exp
invoked from within
catch uplevel #0 source $test_file_name
Running ./lib.test/strutils.exp ...
[...]
=== End ===



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

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

Versions of packages procps depends on:
ii  initscripts   2.88dsf-34
ii  libc6 2.13-37
ii  libncurses5   5.9-10
ii  libncursesw5  5.9-10
ii  libprocps01:3.3.3-2
ii  libtinfo5 5.9-10
ii  lsb-base  4.1+Debian8

Versions of packages procps recommends:
ii  psmisc  22.19-1

procps 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#699205: linux-image-3.7-trunk-amd64: ps, pgrep and pkill segfault after upgrade from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1

[Sascha Silbe]

Jonathan Nieder jrnie...@gmail.com writes:

 after updating the linux-image-3.7-trunk-amd64 from
 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1 today and rebooting,
 the tools ps, pgrep and pkill (package procps) are always segfaulting:

 Just to check: if you downgrade to 3.7.1 again, do the segfaults go
 away?  (Historical versions of Debian packages are available from
 http://snapshot.debian.org)

Confirmed.


 I'll try to provide a backtrace at the end of the week if noone else
 can reproduce this in the meantime; debugging this issue is a pain as
 it requires reboots, especially since the procps test suite runs (and
 fails) despite 'nocheck' in DEB_BUILD_OPTIONS.

 Sounds like http://bugs.debian.org/656508

I'm afraid not. #656508 is also about the test suite failing, but the
output is quite different. With 3.7.3-1~experimental.1 it caught the
segfaults (good in general), but even with 3.7.1-1~experimental.2 it
fails the lib tests because of a missing file:

=== Begin ===
=== lib tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./lib.test/fileutils.exp ...
ERROR: tcl error sourcing ./lib.test/fileutils.exp.
ERROR: couldn't execute 
/home/sascha.silbe/src/deb/procps-3.3.3/testsuite/lib.test/fileutils_badfd.sh:
 no such file or directory
while executing
spawn $badfd
(file ./lib.test/fileutils.exp line 13)
invoked from within
source ./lib.test/fileutils.exp
(uplevel body line 1)
invoked from within
uplevel #0 source ./lib.test/fileutils.exp
invoked from within
catch uplevel #0 source $test_file_name
Running ./lib.test/strutils.exp ...
=== End ===


Have just filed a separate bug about that.


 A pre-built -dbg
 package would have been nice.

 Sounds worth a separate report. :)

I've mentioned it in the FTBFS report. Maybe a gentle nudge is
enough. :)


   I wonder what got of the Squeeze release
 goal Automatic creation of debug packages for the entire archive...

 I know that for my library package (liblzma) I haven't bothered but
 would be happy to take care of it if I knew there were a push for this
 systemwide.  Might be worth starting a discussion on debian-policy@.

Maybe one of these days I'll do (probably on debian-devel first,
though). I seem to have a knack of triggering crashes, especially in
applications using lots of libraries that don't ship a -dbg package.

Sascha


pgpK0_5G5NrNU.pgp
Description: PGP signature

Bug#699205: linux-image-3.7-trunk-amd64: ps, pgrep and pkill segfault after upgrade from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1

[Sascha Silbe]

Package: src:linux
Version: 3.7.3-1~experimental.1
Severity: important

Dear Maintainer,

after updating the linux-image-3.7-trunk-amd64 from
3.7.1-1~experimental.2 to 3.7.3-1~experimental.1 today and rebooting,
the tools ps, pgrep and pkill (package procps) are always segfaulting:

=== Begin ===
sascha.silbe@twin:~$ uname -r
3.7-trunk-amd64
sascha.silbe@twin:~$ ps
Signal 11 (SEGV) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
sascha.silbe@twin:~$ pgrep scdaemon
Segmentation fault
sascha.silbe@twin:~$ pkill scdaemon
Segmentation fault
sascha.silbe@twin:~$ apt-cache policy linux-image-3.7-trunk-amd64
linux-image-3.7-trunk-amd64:
  Installed: 3.7.3-1~experimental.1
  Candidate: 3.7.3-1~experimental.1
  Version table:
 *** 3.7.3-1~experimental.1 0
  1 http://ftp.de.debian.org/debian/ experimental/main amd64 Packages
100 /var/lib/dpkg/status
sascha.silbe@twin:~$ grep linux-image-3.7-trunk-amd64 /var/log/dpkg.log
2013-01-06 20:34:07 install linux-image-3.7-trunk-amd64:amd64 none 
3.7.1-1~experimental.2
2013-01-06 20:34:07 status half-installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:34:07 status half-installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:34:38 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:34:38 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:34:39 configure linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2 none
2013-01-06 20:34:39 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:34:39 status half-configured linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-06 20:36:22 status installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:20 upgrade linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2 3.7.3-1~experimental.1
2013-01-28 17:17:20 status half-configured linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:20 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:20 status half-installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:21 status half-installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:56 status half-installed linux-image-3.7-trunk-amd64:amd64 
3.7.1-1~experimental.2
2013-01-28 17:17:56 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1
2013-01-28 17:17:56 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1
2013-01-28 17:17:57 configure linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1 none
2013-01-28 17:17:57 status unpacked linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1
2013-01-28 17:17:57 status half-configured linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1
2013-01-28 17:18:14 status installed linux-image-3.7-trunk-amd64:amd64 
3.7.3-1~experimental.1
sascha.silbe@twin:~$ 
=== End ===


This may well be a bug in procps triggered by an API change
(i.e. change of format in /proc files), but I wouldn't expect such an
API change from an update within the kernel.org stable release
series, so I'm filing this against the kernel package, rather than
procps. Feel free to reassign or split the ticket.

I'll try to provide a backtrace at the end of the week if noone else
can reproduce this in the meantime; debugging this issue is a pain as
it requires reboots, especially since the procps test suite runs (and
fails) despite 'nocheck' in DEB_BUILD_OPTIONS. A pre-built -dbg
package would have been nice. I wonder what got of the Squeeze release
goal Automatic creation of debug packages for the entire archive...


-- Package-specific info:
** Version:
Linux version 3.7-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.7.3-1~experimental.1

** Command line:
BOOT_IMAGE=/vmlinuz-3.7-trunk-amd64 root=/dev/mapper/twin_vg-wheezy--root ro 
rootflags=data=journal usbcore.autosuspend=1 snd_hda_intel.power_save=1 
resume=/dev/mapper/dmcrypt-swap-ssd quiet

** Not tainted

** Kernel log:
[   59.628580] WARNING! power/level is deprecated; use power/control instead
[   59.631595] kvm: Nested Virtualization enabled
[   59.631599] kvm: Nested Paging enabled
[   59.647230] [drm] ib test on ring 0 succeeded in 0 usecs
[   59.648314] [drm] Radeon Display Connectors
[   59.648316] [drm] Connector 0:
[   59.648318] [drm]   HDMI-A-1
[   59.648319] [drm]   HPD1
[   59.648322] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[   59.648323] [drm]   Encoders:
[   59.648325] [drm] DFP1: INTERNAL_UNIPHY2
[   59.648326] [drm] Connector 1:
[   59.648327] [drm]   VGA-1
[   59.648329] [drm]   HPD2
[   59.648330] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 
0x654c
[   59.648331] [drm]   Encoders:
[   59.648332] [drm] CRT1: INTERNAL_UNIPHY2
[   59.648333] 

Bug#697624: minicom: can't use /dev/serial/by-path/*usb* device names

[Sascha Silbe]

Package: minicom
Version: 2.6.1-1
Severity: normal

Dear Maintainer,

123456789012345678901234567890123456789012345678901234567890123456789012
minicom cuts off the name of the serial device file at the first colon,
so by-path persistent serial device names can't be used; at least not
for USB serial adapters.

I'm using several el-cheapo USB serial adapters that have no serial
number on the same host, so the only way to distinguish them reliably is
to identify them by the physical port of the USB hub they're plugged
into, which is exactly what the /dev/serial/by-path/*usb* symlinks do.

To reproduce:

1. Plug in a USB serial adapter
2. Check /dev/serial/by-path for the device name, e.g.
   /dev/serial/by-path/platform-orion-ehci.0-usb-0:1.1:1.0-port0
3. Create a new minicom configuration file:
   minicom -s P1
4. In Serial port setup, enter the device name from 2. in
   A - Serial Device.
5. Choose Exit (not Exit from Minicom)
6. The following error message will appear:
   minicom: cannot open /dev/serial/by-path/platform-orion-ehci.0-usb-0: No 
such file or directory


As you can see, minicom cuts off the device name after the first
colon. Shortening the path (for testing purposes) or adding a backslash
for to escape the colon shows the same result.

minicom(1) mentions space, comma and semicolon as special characters in
the device name, but not colon.


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 3.2.0-4-kirkwood
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages minicom depends on:
ii  libc6  2.13-37
ii  libtinfo5  5.9-10

Versions of packages minicom recommends:
ii  lrzsz  0.12.21-5

minicom 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#696989: policykit-1: refuses all actions if user is member of a large number of groups

[Sascha Silbe]

Package: policykit-1
Version: 0.105-1
Severity: important

Dear Maintainer,

PolicyKit refuses all actions for my own user account, but works fine
for other accounts:

=== Begin SSH session as sascha.silbe ===
sascha.silbe@twin:~$ cat 
/etc/polkit-1/localauthority/50-local.d/90-sudo-allow-everything.pkla
[AllowEverythingToSudoGroup]
Identity=unix-group:sudo
Action=*
# from within active ConsoleKit sessions
ResultActive=yes
# from within inactive ConsoleKit sessions
ResultInactive=yes
# from within non-local ConsoleKit sessions
ResultAny=yes
sascha.silbe@twin:~$ id -u
8193
sascha.silbe@twin:~$ getent group sudo
sudo:x:27:sascha.silbe,bine
sascha.silbe@twin:~$ pkcheck --action-id 
org.freedesktop.udisks.filesystem-mount --process $$
Not authorized.
=== End SSH session as sascha.silbe ===

=== Begin SSH session as bine ===
bine@twin:~$ pkcheck --action-id org.freedesktop.udisks.filesystem-mount 
--process $$ ; echo $?
0
=== End SSH session as bine ===


Apparently polkitd chokes on the large number of groups my account is
a member of:

=== Begin ===
root@twin:~# /usr/lib/policykit-1/polkitd -r
Entering main event loop
Connected to the system bus
Registering null backend at priority -10
Using authority class PolkitBackendLocalAuthority
Acquired the name org.freedesktop.PolicyKit1

** (polkitd:20969): WARNING **: skipping unknown tag _description at line 15

** (polkitd:20969): WARNING **: skipping unknown tag _message at line 16

** (polkitd:20969): WARNING **: Error looking up groups for uid 8193: Numerical 
result out of range

=== End ===

Checking the source
(src/polkitbackend/polkitbackendlocalauthority.c:get_groups_for_user()),
there's even a TODO entry for this bug:

  gid_t groups[512];
  int num_groups = 512;
[...]
  /* TODO: should resize etc etc etc */

  if (getgrouplist (passwd-pw_name,
passwd-pw_gid,
groups,
num_groups)  0)
{
  g_warning (Error looking up groups for uid %d: %s, uid, g_strerror 
(errno));
  goto out;
}


Once the account is a member of more than the hard-coded limit of 512
groups, PolicyKit will not recognise the user at all, therefore refuse
all actions for them.

This bug is still present in the latest development version (d6acecd),
now in
src/polkitbackend/polkitbackendjsauthority.c:subject_to_jsval().

The reason my user account is part of so many groups is that I'm using
the rainbow package extensively to run web browsers and the like with
less privileges than my user account and in isolation from each
other. For each isolated session, a group is created to enable
exchange of files between my user account and the session account (but
not between the sessions).

I've set the Severity to Important because PolicyKit refuses to work
at all (for this user) once the hard-coded limit is exceeded, rather
than just some part of PolicyKit not working as expected or only the
first few groups being evaluated to determine whether to grant access.


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

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

Versions of packages policykit-1 depends on:
ii  consolekit 0.4.5-3.1
ii  dbus   1.6.8-1
ii  libc6  2.13-37
ii  libexpat1  2.1.0-1
ii  libglib2.0-0   2.33.12+really2.32.4-3
ii  libpam0g   1.1.3-7.1
ii  libpolkit-agent-1-00.105-1
ii  libpolkit-backend-1-0  0.105-1
ii  libpolkit-gobject-1-0  0.105-1

policykit-1 recommends no packages.

policykit-1 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#696989: policykit-1: refuses all actions if user is member of a large number of groups

[Sascha Silbe]

tags 696989 + patch
thanks

With this patch it's working fine for me, both for users with a small
number of groups and for users with a large numbers of groups.

Sascha

Description: Fix get_groups_for_user() for large number of users
 get_groups_for_user() used a hard-coded limit for the number of
 groups before, barring all access to users with a large number of
 groups.
 .
 Dynamically allocate the list instead, potentially resizing it based
 on what getgroupslist() tells us.
Author: Sascha Silbe sascha-...@silbe.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Bug-Debian: http://bugs.debian.org/696989
Last-Update: 2012-12-30

--- policykit-1-0.105.orig/src/polkitbackend/polkitbackendlocalauthority.c
+++ policykit-1-0.105/src/polkitbackend/polkitbackendlocalauthority.c
@@ -749,11 +749,17 @@ get_groups_for_user (PolkitIdentity *use
   uid_t uid;
   struct passwd *passwd;
   GList *result;
-  gid_t groups[512];
-  int num_groups = 512;
+  int num_groups, groups_size = 512;
+  gid_t *groups = malloc(groups_size * sizeof(gid_t));
   int n;
+  int error;
 
   result = NULL;
+  if (!groups)
+  {
+g_warning (Out of memory when looking up groups for uid %d, uid);
+goto out;
+  }
 
   /* TODO: it would be, uhm, good to cache this information */
 
@@ -765,22 +771,34 @@ get_groups_for_user (PolkitIdentity *use
   goto out;
 }
 
-  /* TODO: should resize etc etc etc */
-
-  if (getgrouplist (passwd-pw_name,
-passwd-pw_gid,
-groups,
-num_groups)  0)
+  num_groups = groups_size;
+  error = getgrouplist (passwd-pw_name, passwd-pw_gid, groups, num_groups);
+  if ((error  0)  (num_groups  groups_size))
+  {
+gid_t *new_groups;
+
+groups_size = num_groups;
+new_groups = realloc(groups, groups_size * sizeof(gid_t));
+if (!new_groups)
 {
-  g_warning (Error looking up groups for uid %d: %s, uid, g_strerror 
(errno));
+  g_warning (Out of memory when looking up groups for uid %d, uid);
   goto out;
 }
+groups = new_groups;
+error = getgrouplist (passwd-pw_name, passwd-pw_gid, groups, 
num_groups);
+  }
+  if (error  0)
+  {
+g_warning (Error looking up groups for uid %d: getgrouplist() failed, 
uid);
+goto out;
+  }
 
   for (n = 0; n  num_groups; n++)
 result = g_list_prepend (result, polkit_unix_group_new (groups[n]));
 
  out:
-
+  if (groups)
+free(groups);
   return result;
 }
 


pgpVqJGReczo2.pgp
Description: PGP signature

Bug#692009: bup: should Recommend python-pyxattr and python-pylibacl

[Sascha Silbe]

Package: bup
Version: 0.25~git2011.11.04-5
Severity: minor

Dear Maintainer,

bup meta requires python-pyxattr and python-pylibacl in order to
back up and restore extended attributes resp. ACLs, so they should be
listed in Recommends or at least Suggests.

=== Begin ===
sascha.silbe@twin:~/baz$ bup meta -f /dev/null --create .
Warning: Linux xattr support missing; install python-pyxattr.
Warning: POSIX ACL support missing; install python-pylibacl.
sascha.silbe@twin:~/baz$ 
=== End ===

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

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

Versions of packages bup depends on:
ii  git [git-core]  1:1.7.10.4-1
ii  git-core1:1.7.10.4-1
ii  libc6   2.13-35
ii  python  2.7.3~rc2-1
ii  python-fuse 2:0.2.1-7
ii  python-support  1.0.15
ii  python-tornado  2.3-2

Versions of packages bup recommends:
ii  par2  0.4-11

bup 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#689499: python-notmuch: Please install Python 3 bindings

[Sascha Silbe]

Package: python-notmuch
Version: 0.13.2-1
Severity: normal

Dear Maintainer,

notmuch ships with Python 3 bindings, but the Debian package doesn't
install them. Some third-party tools (that use the notmuch bindings)
work better with Python 3 than with Python 2.x. There may even be some
that don't work at all with Python 2.

This is probably too late for Wheezy, so once it's fixed in sid a
backport of the latest upstream version (including the incompatible
format changes) would be appreciated.

Sascha

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

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


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

Bug#687250: scdaemon: spamming syslog if reader cannot be found

[Sascha Silbe]

Package: scdaemon
Version: 2.0.19-1
Severity: important

Dear Maintainer,

If scdaemon cannot find the configured reader, it will flood syslog:

Sep 11 09:17:42 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
Sep 11 09:17:42 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
Sep 11 09:17:43 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
Sep 11 09:17:44 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
Sep 11 09:17:44 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
Sep 11 09:17:45 twin pcscd: winscard.c:241:SCardConnect() Reader Gemalto USB 
Shell Token V2 01 00 Not Found
[...]

Not only does it consume CPU time without need (the operation that
triggered the spawning of scdaemon will have finished successfully
using an on-disk key after the first error message from scdaemon), but
it also clutters the syslog.  In certain configurations (time-based
syslog rotation without size restrictions), it could even lead to
filling up /var/log. In other configurations it could lead to more
important messages getting dropped too early. For this reason (impact
on other parts of the system) I'm setting the severity to
important. scdaemon itself will continue to operate normally. Once I
plug in the matching card reader, the spamming will stop and SSH will
be able to use the key stored on the card.

Background: I have two USB smartcard readers (of different form
factors, for cards of different form factor): one for online banking
via HBCI and the other one for use with GnuPG (including SSH). The
GnuPG one usually gets plugged into the system I happen to be
physically present at, but sometimes I don't plug it in at all because
the local keys are sufficient for the task at hand. To prevent the
smartcard reader used for HBCI from confusing GnuPG, I have
configured scdaemon (via ~/.gnupg/scdaemon.conf) to only use a
specific reader.


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

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

Versions of packages scdaemon depends on:
ii  libassuan0 2.0.3-1
ii  libc6  2.13-35
ii  libgcrypt111.5.0-3
ii  libgpg-error0  1.10-3
ii  libksba8   1.2.0-2
ii  libpth20   2.0.7-16
ii  libusb-0.1-4   2:0.1.12-20

scdaemon recommends no packages.

scdaemon 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#685365: mpd: init script shows start-create-db in help message, but does not support it

[Sascha Silbe]

Package: mpd
Version: 0.16.7-2
Severity: normal

Dear Maintainer,

The help output for /etc/init.d/mpd includes the start-create-db
action:

root@twin:/var/lib/mpd/music# /etc/init.d/mpd --help
Usage: /etc/init.d/mpd {start|start-create-db|stop|restart|force-reload}

However trying to execute it only prints the help again:

root@twin:/var/lib/mpd/music# /etc/init.d/mpd start-create-db
Usage: /etc/init.d/mpd {start|start-create-db|stop|restart|force-reload}

Indeed /etc/init.d/mpd contains no mention of start-create-db other
than the help output. It's probably a left-over and should be removed
to avoid confusion.


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

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

Versions of packages mpd depends on:
ii  adduser   3.113+nmu3
ii  libao41.1.0-2
ii  libasound21.0.25-4
ii  libaudiofile1 0.3.4-1
ii  libavahi-client3  0.6.31-1
ii  libavahi-common3  0.6.31-1
ii  libavahi-glib10.6.31-1
ii  libavcodec53  6:0.8.3-6
ii  libavformat53 [libavformat-extra-53]  6:0.8.3-6
ii  libavutil51 [libavutil-extra-51]  6:0.8.3-6
ii  libc6 2.13-35
ii  libcurl3-gnutls   7.26.0-1
ii  libfaad2  2.7-8
ii  libflac8  1.2.1-6
ii  libgcc1   1:4.7.1-2
ii  libglib2.0-0  2.32.3-1
ii  libid3tag00.15.1b-10
ii  libjack0 [libjack-0.116]  1:0.121.3+20120418git75e3e20b-2
ii  libmad0   0.15.1b-7
ii  libmikmod23.1.12-4
ii  libmms0   0.6.2-3
ii  libmp3lame0   3.99.5+repack1-3
ii  libmpcdec62:0.1~r459-4
ii  libogg0   1.3.0-4
ii  libpulse0 2.0-6
ii  libsamplerate00.1.8-5
ii  libshout3 2.2.2-8
ii  libsqlite3-0  3.7.13-1
ii  libstdc++64.7.1-2
ii  libvorbis0a   1.3.2-1.3
ii  libvorbisenc2 1.3.2-1.3
ii  libvorbisfile31.3.2-1.3
ii  libwavpack1   4.60.1-3
ii  lsb-base  4.1+Debian7
ii  zlib1g1:1.2.7.dfsg-13

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.6.31-1
pn  icecast2  none
ii  ncmpcpp [mpd-client]  0.5.10-1
pn  pulseaudionone

-- Configuration Files:
/etc/mpd.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#683335: xpdf: can't disable reverse video on the command line anymore

[Sascha Silbe]

Package: xpdf
Version: 3.03-10
Severity: normal

Dear Maintainer,

after upgrading from Squeeze to Wheezy, the +rv option that
previously disabled reverse video (when it had been enabled by X
resources) doesn't work anymore:

sascha.silbe@twin:~$ xpdf +rv time_based_workflow.pdf 
error: +rv file not found
sascha.silbe@twin:~$ 

I couldn't find any other way to disable reverse video just for a
single run, like a new -no-rv option or a context menu option.


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

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

Versions of packages xpdf depends on:
ii  lesstif2  1:0.95.2-1
ii  libc6 2.13-33
ii  libgcc1   1:4.7.1-2
ii  libpoppler19  0.18.4-3
ii  libstdc++64.7.1-2
ii  libx11-6  2:1.5.0-1
ii  libxt61:1.1.3-1

Versions of packages xpdf recommends:
ii  cups-bsd   1.5.3-1
ii  gsfonts-x110.22
ii  poppler-data   0.4.5-8
ii  poppler-utils  0.18.4-3

xpdf 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#683343: conkeror: extensions screen never finishes loading

[Sascha Silbe]

Package: conkeror
Version: 1.0~~pre+git120527-1
Severity: important

Dear Maintainer,

after the update to Wheezy, the extensions screen (invoked via Alt+x
extensions) shows only a constantly spinning Loading...
message. It doesn't use the CPU much and doesn't seem to be doing
anything on disk either.

Output in the terminal:

sascha.silbe@twin:~$ conkeror 
NS_ERROR_FILE_TARGET_DOES_NOT_EXIST: Component returned failure code: 
0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsILocalFile.isSymlink]
load_rc()@chrome://conkeror/content/rc.js:23
handle_command_line()@chrome://conkeror/content/command-line.js:179
null()@file:///usr/share/conkeror/components/command-line.js:23
Console error: [JavaScript Warning: reference to undefined property 
types[type] {file: chrome://mozapps/content/extensions/extensions.js line: 
1480}]
  Category: chrome javascript
Console error: [JavaScript Error: Root node doesn't exist for 'discover' view 
{file: chrome://mozapps/content/extensions/extensions.js line: 647}]
  Category: chrome javascript


Marking as important as it's impossible to manage and configure
extensions other than by using the extensions screen AFAIK.

-- Package-specific info:

-- Extensions information
Name: Monkeysphere
Location: 
/usr/share/mozilla/extensions/{a79fe89b-6662-4ff4-8e88-09950ad4dfde}/tls-xul-...@monkeysphere.info
Status: app-disabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.2 (1.2-2))
Location: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-6-plugin:amd64
Status: enabled


-- Addons package information
ii  icedtea-6-plug 1.2-2  web browser plugin based on OpenJDK and Iced

-- Extensions information
Name: Monkeysphere
Location: 
/usr/share/mozilla/extensions/{a79fe89b-6662-4ff4-8e88-09950ad4dfde}/tls-xul-...@monkeysphere.info
Status: app-disabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.2 (1.2-2))
Location: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-6-plugin:amd64
Status: enabled


-- Addons package information
ii  icedtea-6-plug 1.2-2  web browser plugin based on OpenJDK and Iced

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

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

Versions of packages conkeror depends on:
ii  xulrunner-1.9.1  1.9.1.16-17
ii  xulrunner-10.0   10.0.6esr-1

Versions of packages conkeror recommends:
ii  conkeror-spawn-process-helper  1.0~~pre+git120527-1
ii  xdg-utils  1.1.0~rc1+git20111210-6

Versions of packages conkeror suggests:
ii  emacs [emacsen]23.4+1-3
ii  emacs23 [emacsen]  23.4+1-3

-- 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#642903: nodm: config failure still happens, makes dist-upgrade to Wheezy fail

[Sascha Silbe]

Package: nodm
Version: 0.11-1.2
Followup-For: Bug #642903

Dear Maintainer,

this still happens and causes the distro upgrade from Squeeze to Wheezy
to fail. I was able to recover from the dist-upgrade failure, but it
wasn't exactly a smooth experience (due to a combination of factors, the
nodm-induced abort of the dist-upgrade process being one of them).



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 3.3.8-xo1-1-00053-g89bd3b0 (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nodm depends on:
ii  debconf [debconf-2.0]  1.5.44
ii  libc6  2.13-33
ii  libpam0g   1.1.3-7.1
ii  libx11-6   2:1.5.0-1
ii  x11-common 1:7.7+1
ii  x11-xserver-utils  7.7~3

nodm recommends no packages.

nodm suggests no packages.

-- debconf information:
* nodm/min_session_time: 120
* nodm/enabled: true
* nodm/xsession: /etc/X11/Xsession
* nodm/x_options: vt7 -nolisten tcp -dpi 200
* nodm/first_vt: 7
* nodm/user: sascha.silbe


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

Bug#565764: python-dogtail: Please package 0.8.0 as well

[Sascha Silbe]

Package: python-dogtail
Severity: normal

In the meantime (over two years), version 0.8.0 has been
released. This is the version required to test GTK3 based
systems. Upstream will continue maintaining 0.7.x for testing GTK2
based systems. AIUI, both versions would need to be installable in
parallel in order to be able to test both GTK2 and GTK3 based
applications, but I haven't tried testing GTK2 based applications with
0.8.0 yet to see if that would work, too.

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

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



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

Bug#675513: libgeier0: loaded xmlsec library version is not compatible

[Sascha Silbe]

Package: libgeier0
Version: 0.13-1
Severity: grave
Justification: renders package unusable
Followup-For: Bug #675513

Dear Maintainer,

the purpose of libgeier is to send VAT reports to the IRS (or rather
the German equivalent). The xmlsec incompatibility issue makes that
impossible, so I'm raising the severity to grave.

Simply recompiling libgeier in Wheezy fixed the issue for me, too. So
all that's needed to fix it for Wheezy (which is frozen, so shouldn't
receive any incompatible libxmlsec1 updates AIUI) is to force a
rebuild of this package.

Kudos for maintaining this package, BTW!

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armel (armv7l)

Kernel: Linux 3.0.19-mimosa-5-01574-gd4cfabf (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgeier0 depends on:
ii  libc6   2.13-33
ii  libnspr42:4.9.1-1
ii  libnspr4-0d 2:4.9.1-1
ii  libnss3 2:3.13.5-1
ii  libnss3-1d  2:3.13.5-1
ii  libxml2 2.8.0+dfsg1-4
ii  libxmlsec1  1.2.18-1
ii  libxmlsec1-nss  1.2.18-1
ii  libxslt1.1  1.1.26-12+rebuild1
ii  zlib1g  1:1.2.7.dfsg-13

libgeier0 recommends no packages.

libgeier0 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#668997: bup: breaks if PYTHONOPTIMIZE is set

[Sascha Silbe]

Package: bup
Version: 0.17b-2squeeze1
Severity: important


bup uses the Python assert statement for regular operations, not just
for additional sanity checks that go beyond what should be done during
normal operation (i.e. debugging assertions). Python disables assert
when running in optimised mode [1,2], e.g. by running with -O [3] or
setting the PYTHONOPTIMIZE environment variable [4].

One effect is that bup join does not work at all:

{{{
sascha.silbe@twin:~$ bup join -r /media/bup-encfs-plain xo15-sascha-home 
bup server: reading from stdin.
bup server: command: 'set-dir /media/bup-encfs-plain'
bup server: bupdir is '/media/bup-encfs-plain'
bup server: command: 'list-indexes'
bup server: command: 'cat xo15-sascha-home'
Traceback (most recent call last):
  File /usr/lib/bup/cmd/bup-server, line 183, in module
cmd(conn, rest)
  File /usr/lib/bup/cmd/bup-server, line 132, in cat
for blob in cat_pipe.join(id):
  File /usr/lib/bup/bup/git.py, line 907, in join
for d in self._join(self.get(id)):
  File /usr/lib/bup/bup/git.py, line 894, in _join
for blob in self.join(treeline[5:]):
  File /usr/lib/bup/bup/git.py, line 907, in join
for d in self._join(self.get(id)):
  File /usr/lib/bup/bup/git.py, line 882, in _join
type = it.next()
  File /usr/lib/bup/bup/git.py, line 852, in _fast_get
raise GitError('expected blob, got %r' % spl)
bup.git.GitError: expected blob, got ['\n']
Traceback (most recent call last):
  File /usr/lib/bup/cmd/bup-join, line 31, in module
for blob in cat(id):
  File /usr/lib/bup/bup/client.py, line 215, in cat
sz = struct.unpack('!I', self.conn.read(4))[0]
struct.error: unpack requires a string argument of length 4
Exception bup.client.ClientError: ClientError('server tunnel returned exit code 
1',) in bound method Client.__del__ of bup.client.Client instance at 
0x1f425f0 ignored
}}}


It's possible that it silently breaks during backup in ways that will
only get noticed when one actually tries to restore the backup, so
I've raised the priority to important. I haven't audited the code to
check whether any code path used during backup stages actually uses
assert with operations that have side effects, so feel free to lower
the priority if you're sure it can't silently corrupt data if run in
optimise mode.

The version currently in sid (0.25~git2011.11.04-3) is affected as well.


[1] http://docs.python.org/reference/simple_stmts.html#the-assert-statement
[2] http://docs.python.org/library/constants.html#__debug__
[3] http://docs.python.org/using/cmdline.html#cmdoption-O
[4] http://docs.python.org/using/cmdline.html#envvar-PYTHONOPTIMIZE

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

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

Versions of packages bup depends on:
ii  git [git-core]  1:1.7.9.5-1  fast, scalable, distributed revisi
ii  git-core1:1.7.2.5-3  fast, scalable, distributed revisi
ii  libc6   2.11.3-3 Embedded GNU C Library: Shared lib
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-fuse 2:0.2.1-2Python bindings for FUSE (Filesyst
ii  python-support  1.0.10   automated rebuilding support for P
ii  python-tornado  1.0.1-1  scalable, non-blocking web server 

Versions of packages bup recommends:
ii  par2  0.4-11 Parity Archive Volume Set, for che

bup 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#648724: libgconf2-4: GCONF_DEFAULT_SOURCE_PATH support broken

[Sascha Silbe]

Excerpts from Sascha Silbe's message of 2011-11-29 14:52:52 +0100:

 My patch has landed upstream without changes as commit
 c129898afaa562ffc38f434e5e0c607f525101b8.

Is there a chance of cherry-picking the fix into Debian? It's already in
upstream git, but there hasn't been a release yet and it's been broken
for over three months now. The packaging updates that have recently
migrated into wheezy have caused my system to break again (because they
don't include the fix but have a higher version than the local package
with the fix).

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature

Bug#593815: bugs.debian.org inaccessible when IPv6 is enabled but not routed

[Sascha Silbe]

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


During an IPv6 outage today I hit this bug again and tried out the
patch [1] from Kusanagi Kouichi sl...@ac.auone-net.jp (thanks,
Kusanagi!).

Since my IPv6 upstream was working again before the squid build was
completed, I used ip6tables to simulate the conditions:

flatty:~# ip6tables -I INPUT -s 2001:8d8:580:400:6564:a62:0:2 -j DROP
flatty:~# ip6tables -I INPUT -s 2001:858:2:2:214:22ff:fe11:ac9e -j DROP
flatty:~# ip6tables -I INPUT -s 2607:f8f0:610:4000:6564:a62:ce0c:1372 -j DROP

Accessing [1] with an unpatched squid from squeeze (3.1.6-1.2+squeeze2)
failed with the following error message after three minutes:

=== Cut ===
The following error was encountered while trying to retrieve the URL: 
http://bugs.debian.org/cgi-bin/
bugreport.cgi?

Connection to 2607:f8f0:610:4000:6564:a62:ce0c:1372 failed.

The system returned: (101) Network is unreachable

The remote host or network may be down. Please try the request again.
=== Cut ===

With Kusanagis patch applied, it still took considerable time sometimes
(though not always), but at least it worked.


Sascha

[1] 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=65;filename=ipv6-fix.diff;att=1;bug=593815

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

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US, 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-2  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+squeeze3 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:
ii  resolvconf1.46   name server information handler
pn  smbclient none (no description available)
pn  squid-cgi none (no description available)
pn  squidclient   none (no description available)

-- Configuration Files:
/etc/squid3/squid.conf changed:
acl manager proto cache_object
acl from_localhost src 127.0.0.0/8
acl from_localhost src ::1/128
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl to_localhost dst ::1/128
acl from_localnet src 192.168.0.0/16
acl from_localnet src 2001:6f8:120a::/64
acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl to_broken_ipv6_sites dst 2002:1255:2c78::1/128
acl to_broken_ipv6_sites dst 2002:8cba:4600::/40
http_access allow manager from_localhost
http_access deny manager
http_access deny to_localhost
http_access allow from_localnet
http_access allow from_localhost
http_access deny all
http_port 192.168.1.252:3128
http_port 127.0.0.1:3128
tcp_outgoing_address 192.168.1.252 to_broken_ipv6_sites
hierarchy_stoplist cgi-bin ?
cache_mem 32 MB
memory_replacement_policy heap GDSF
cache_replacement_policy heap GDSF
cache_dir ufs /var/cache/squid/small 128 16 256 max-size=262144
cache_replacement_policy heap LFUDA
cache_dir ufs /var/cache/squid/big 16384 64 256
maximum_object_size 512 MB
log_mime_hdrs on
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:   

Bug#662683: w3m: incorrect URLs for GET forms with a fragment identifier

[Sascha Silbe]

Package: w3m
Version: 0.5.2-10
Severity: normal


Trying to reply to a comment on a Trac instance doesn't work because
w3m appends parameters to the end of the URL even though it contains a
fragment identifier. To give an example, this is the HTML code for the
first Reply button on [1]:

form name=addreply method=get action=#comment
  div class=inlinebuttons
input type=hidden name=replyto value=description /
input type=submit name=reply value=Reply title=Reply, quoting this 
description /
  /div
/form

When submitting this form, w3m constructs the URL
https://dev.laptop.org/ticket/11558#comment?replyto=descriptionreply=Reply
and doesn't send the parameters to the server.

Instead, it should have parsed the URL, appended the parameters and
reassembled the URI to the form
https://dev.laptop.org/ticket/11558?replyto=descriptionreply=Reply#comment .
This would have caused Trac on the server to pre-fill the Comment field
accordingly (with a quote of the ticket description) and w3m to move
the cursor to the Comment field after loading.

Sascha

[1] https://dev.laptop.org/ticket/11558

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

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

Versions of packages w3m depends on:
ii  libc6   2.11.3-3 Embedded GNU C Library: Shared lib
ii  libgc1c21:6.8-1.2conservative garbage collector for
ii  libgpm2 1.20.4-3.3   General Purpose Mouse - shared lib
ii  libncurses5 5.7+20100313-5   shared libraries for terminal hand
ii  libssl0.9.8 0.9.8o-4squeeze7 SSL shared libraries
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages w3m recommends:
ii  ca-certificates20090814+nmu3squeeze1 Common CA certificates

Versions of packages w3m suggests:
ii  man-db2.5.7-8on-line manual pager
ii  menu  2.1.44 generates programs menu for all me
pn  migemonone (no description available)
ii  mime-support  3.48-1 MIME files 'mime.types'  'mailcap
pn  w3m-elnone (no description available)
ii  w3m-img   0.5.2-10   inline image extension support uti

-- 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#631807: segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc

[Sascha Silbe]

Package: libcap-ng0
Version: 0.6.6-1
Followup-For: Bug #631807

Dear Maintainer,

I'm afraid I can also confirm this bug. Took me some time to realise
that it's not gnome-keyring-daemon's fault that it crashes (with a
segfault) on every invocation, even --help.

Fortunately, as Thomas Maass helpfully pointed out, the Ubuntu version
(0.6.6-1ubuntu1) does not exhibit the same problem, so I finally have a
workaround.

Still, it's a grave bug (at least on armel) that should be fixed ASAP
as it renders packages that link against libcap-ng0 completely
inoperable. (Sorry to not dig into it myself and send a patch, but I
already have my own fair share of bugs to fix.)

FWIW, this is on an XO-1.75 laptop [1].


[1] http://wiki.laptop.org/go/XO-1.75

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armel (armv7l)

Kernel: Linux 3.0.0-mimosa-1-00214-gd1fa5f2 (PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcap-ng0 depends on:
ii  libc6  2.13-26

libcap-ng0 recommends no packages.

libcap-ng0 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#652747: listadmin: --remove-member fails silently

[Sascha Silbe]

Package: listadmin
Version: 2.40-4
Severity: normal


listadmin --remove-member appears to succeed (prints Ok, return code 0),
but listadmin -l shows that the member remains on the list:

sascha.silbe@twin:~$ listadmin -l a@l.a.c |grep r@l.o.a
r@l.o.a
sascha.silbe@twin:~$ listadmin --remove-member r@l.o.a a@l.a.c
Ok
sascha.silbe@twin:~$ echo $?
0
sascha.silbe@twin:~$ listadmin -l a@l.a.c |grep r@l.o.a
r@l.o.a
sascha.silbe@twin:~$

(addresses shortened after cutpaste for privacy reasons)

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

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

Versions of packages listadmin depends on:
ii  libcrypt-ssleay-perl  0.57-2 Support for https protocol in LWP
ii  libtext-reform-perl   1.20-1 Perl module for manual text wrappi
ii  libwww-perl   5.836-1Perl HTTP/WWW client/server librar

listadmin recommends no packages.

listadmin 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#652480: wget: Fails to verify SSL server certificate

[Sascha Silbe]

Package: wget
Version: 1.13.4-1
Severity: normal

Dear Maintainer,

wget fails to connect to https://patchwork.sugarlabs.org/, claiming the
certificate is untrusted:

(wheezy-jhbuild)sascha.silbe@twin:~/sugar-jhbuild/source/sugar$ wget -d -O - 
https://patchwork.sugarlabs.org/patch/1084/mbox/
Setting --output-document (outputdocument) to -
DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2011-12-17 16:34:47--  https://patchwork.sugarlabs.org/patch/1084/mbox/
Resolving patchwork.sugarlabs.org (patchwork.sugarlabs.org)... 140.186.70.53, 
2002:8cba:4635::1
Caching patchwork.sugarlabs.org = 140.186.70.53 2002:8cba:4635::1
Connecting to patchwork.sugarlabs.org 
(patchwork.sugarlabs.org)|140.186.70.53|:443... connected.
Created socket 5.
Releasing 0x01603d20 (new refcount 1).
ERROR: The certificate of `patchwork.sugarlabs.org' is not trusted.
(wheezy-jhbuild)sascha.silbe@twin:~/sugar-jhbuild/source/sugar$

The OpenSSL command-line tool s_client can connect quite fine to the
same server, however:

(wheezy-jhbuild)sascha.silbe@twin:~/sugar-jhbuild/source/sugar$ openssl 
s_client -CApath /etc/ssl/certs -connect patchwork.sugarlabs.org:443
CONNECTED(0003)
depth=2 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
Authority, emailAddress = supp...@cacert.org
verify return:1
depth=1 O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root
verify return:1
depth=0 CN = *.sugarlabs.org
verify return:1
---
Certificate chain
 0 s:/CN=*.sugarlabs.org
   i:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
 1 s:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
   i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing 
Authority/emailAddress=supp...@cacert.org
---
Server certificate
-BEGIN CERTIFICATE-
MIIELDCCAhSgAwIBAgIDAMm1MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NB
Y2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNV
BAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcNMTEwMzIwMjE1NDE1WhcNMTMwMzE5
MjE1NDE1WjAaMRgwFgYDVQQDFA8qLnN1Z2FybGFicy5vcmcwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBANa99DRfcDjNLHciJHxk7dSNjK0LZbh1yXziTu8BoTSr
Jvec3Hw6g5SZW8lNnQiqW7o+/mQs8UXvKlnfpljFhJEk6JVySlRm9bn0tE9yNtUy
HSYB6FmI9mhCiqqxZ8fduoh5LQAumKect/umCCIycddvZwpy+yjSbRqfGRDRzSMZ
AgMBAAGjgcQwgcEwDAYDVR0TAQH/BAIwADA0BgNVHSUELTArBggrBgEFBQcDAgYI
KwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYBBAGCNwoDAzALBgNVHQ8EBAMCBaAwMwYI
KwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5jYWNlcnQub3Jn
LzA5BgNVHREEMjAwgg8qLnN1Z2FybGFicy5vcmegHQYIKwYBBQUHCAWgEQwPKi5z
dWdhcmxhYnMub3JnMA0GCSqGSIb3DQEBBQUAA4ICAQA+SUhvpG1TYS9KOZMJVhW3
vNVWwv3eW5aG66o4D66h1nsrMc98UWYmE5OBwHZd6m2lNbKVp9LvJFMqWZky5jg7
9dRbOdtkvdvvkhPPJwXTEmj1pLaEtFssue24gXvC4aWvv1O94uvzoEV7vGUa3lMT
NZxD631FmuttpBrElzpbDj5AVPKpvcsyytxWIavsjc8RK+1HIZW5WHwoYK0a6Xvb
tc5YtZYft1iCesund2eHtSaJ8Gp3XPfUe9m86L948w7BswNcSy7jdNf7S8yV2Gd/
OJtxXDzZVzvkpglMKAcaecZbvw5sYJ/A371Wu9X/6UrNwpUbN8/e08NRP8NaeAxb
nOg+iqNs4wuxI5ae4Sfjy1vDVtoEgwW0PhaMHaEVlsoT5TejViy9KNqW3snli6I8
5luHfEY4sDtV/DYsyxrgVo/2YP69LJ6Y+01CxB9xNKo9IfzkX5cP7ZGk12DcHQK7
Rutte4u+YNQMLoeWxkGbQ6nvfTn6VeO0vWts0fo/Ey6k5B2IsODF8mqOSli3QXMi
b9tqzSFZddUeQ+Uiqo2m3jxA4pmE8s+jtSFMLwCJbh+PkfqmKhJcOo51zBwnzOjD
k6PB44UhpXpAHEeUm8vMEVM7ImDt6dqzK/dV0cQFRURoF/H0cWm7U9woUNUC9Wgs
NFuwOnC8IQuculcFvXqv1A==
-END CERTIFICATE-
subject=/CN=*.sugarlabs.org
issuer=/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
---
No client certificate CA names sent
---
SSL handshake has read 3226 bytes and written 369 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : SSLv3
Cipher: DHE-RSA-AES256-SHA
Session-ID: 60D5304D64255F9F398C623BCCBB94D29ACB536C0C39EC9DBBCA77B64693E63E
Session-ID-ctx:
Master-Key: 
A358E6D5DF040C3D36017368C5B06C969760F40C8A0421E5F5CA88E86B06E04D2A081A4DC6FA00B00BE476CDC2124FA9
Key-Arg   : None
PSK identity: None
PSK identity hint: None
Compression: 1 (zlib compression)
Start Time: 1324135451
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---


Explicitly setting the directory for the CA certificates (like s_client
needs) doesn't help either:

(wheezy-jhbuild)sascha.silbe@twin:~/sugar-jhbuild/source/sugar$ wget -d 
--ca-directory=/etc/ssl/certs -O - 
https://patchwork.sugarlabs.org/patch/1084/mbox/
Setting --ca-directory (cadirectory) to /etc/ssl/certs
Setting --output-document (outputdocument) to -
DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2011-12-17 16:32:56--  https://patchwork.sugarlabs.org/patch/1084/mbox/
Resolving patchwork.sugarlabs.org (patchwork.sugarlabs.org)... 140.186.70.53, 
2002:8cba:4635::1
Caching patchwork.sugarlabs.org = 140.186.70.53 2002:8cba:4635::1
Connecting to patchwork.sugarlabs.org 
(patchwork.sugarlabs.org)|140.186.70.53|:443... connected.
Created socket 5.
Releasing 0x0161dd40 (new refcount 1).
ERROR: The 

Bug#648724: libgconf2-4: GCONF_DEFAULT_SOURCE_PATH support broken

[Sascha Silbe]

tags 648724 + patch fixed-upstream
thanks

My patch has landed upstream without changes as commit
c129898afaa562ffc38f434e5e0c607f525101b8.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature

Bug#648724: libgconf2-4: GCONF_DEFAULT_SOURCE_PATH support broken

[Sascha Silbe]

Package: libgconf2-4
Version: 3.2.3-1
Severity: important

Dear Maintainer,

the upgrade from gconf 2.32.4-1 to 3.2.3-1 broke the support for
GCONF_DEFAULT_SOURCE_PATH. The latter had been introduced to allow tools
like jhbuild to tell GConf about additional places to search for
defaults and settings. Without this support Sugar [1] won't work inside
sugar-jhbuild [2] as no defaults are set.

This is partially due to an upstream bug (Gnome#664031 [3]) and
partially because Debian explicitly configures GConf to use the new
DBus backend (which lacks GCONF_DEFAULT_SOURCE_PATH support) instead
of the default ORBit backend (which supports GCONF_DEFAULT_SOURCE_PATH).


Invocation on a system that still has gconf 2.32.4-1:

sascha.silbe@mimosa:~$ ~/sugar-jhbuild/sugar-jhbuild run gconftool-2 --get 
/desktop/sugar/desktop/favorites_layout
ring-layout
sascha.silbe@mimosa:~$


Invocation on a system with gconf updated to 3.2.3-1:

(wheezy-jhbuild)sascha.silbe@twin:~$ ~/sugar-jhbuild/sugar-jhbuild run 
gconftool-2 --get /desktop/sugar/desktop/favorites_layout
No value set for `/desktop/sugar/desktop/favorites_layout'
(wheezy-jhbuild)sascha.silbe@twin:~$


[1] http://wiki.sugarlabs.org/go/What_is_Sugar%3F
[2] http://wiki.sugarlabs.org/go/Development_Team/Jhbuild
[3] https://bugzilla.gnome.org/show_bug.cgi?id=664031

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

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

Versions of packages libgconf2-4 depends on:
ii  gconf2-common 3.2.3-1
ii  libc6 2.13-21
ii  libdbus-1-3   1.4.16-1
ii  libdbus-glib-1-2  0.98-1
ii  libglib2.0-0  2.28.8-1
ii  libldap-2.4-2 2.4.25-4
ii  libxml2   2.7.8.dfsg-5

libgconf2-4 recommends no packages.

libgconf2-4 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#648724: [PATCH] Fix #648724

[Sascha Silbe]

* 05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch:
  Patch to fix GCONF_DEFAULT_SOURCE_PATH support when building with D-Bus
  backend. Closes: #648724
---

The included GConf patch has been submitted upstream [1].

 debian/changelog   |9 ++
 ...nd-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch |  108 
 debian/patches/series  |1 +
 3 files changed, 118 insertions(+), 0 deletions(-)
 create mode 100644 
debian/patches/05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch

[1] https://bugzilla.gnome.org/show_bug.cgi?id=664031#c2

diff --git a/debian/changelog b/debian/changelog
index ce0570f..2299e82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gconf (3.2.3-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * 0001-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch:
+Patch to fix GCONF_DEFAULT_SOURCE_PATH support when building with D-Bus
+backend. Closes: #648724
+
+ -- Sascha Silbe sascha-...@silbe.org  Mon, 14 Nov 2011 20:24:27 +
+
 gconf (3.2.3-1) unstable; urgency=low

   [ Jeremy Bicha ]
diff --git 
a/debian/patches/05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch 
b/debian/patches/05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch
new file mode 100644
index 000..8ef3f23
--- /dev/null
+++ 
b/debian/patches/05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch
@@ -0,0 +1,108 @@
+From 04c83a792700cd974c43c83feb7a8dae05e68a63 Mon Sep 17 00:00:00 2001
+From: Sascha Silbe sascha-...@silbe.org
+Date: Mon, 14 Nov 2011 16:13:27 +0100
+Subject: [PATCH] D-Bus backend: Add GCONF_DEFAULT_SOURCE_PATH support
+ (#664031)
+
+Forward-port 7baf4c6b33a6dd0697a8bdb81bd86c72d58ebdc6
+(Allow overriding the default config via $GCONF_DEFAULT_SOURCE_PATH)
+from the ORBit to the D-Bus backend to fix (sugar-)jhbuild breakage when
+building with --disable-orbit.
+---
+ gconf/gconf-dbus.c |   30 +++---
+ 1 files changed, 19 insertions(+), 11 deletions(-)
+
+diff --git a/gconf/gconf-dbus.c b/gconf/gconf-dbus.c
+index 817a1f9..9f92125 100644
+--- a/gconf/gconf-dbus.c
 b/gconf/gconf-dbus.c
+@@ -76,8 +76,6 @@ struct _GConfEngine {
+
+   gpointer owner;
+   int owner_use_count;
+-
+-  guint is_default : 1;
+
+   /* If TRUE, this is a local engine (and therefore
+* has no ctable and no notifications)
+@@ -299,7 +297,6 @@ gconf_engine_blank (gboolean remote)
+
+   conf-local_sources = NULL;
+   conf-is_local = FALSE;
+-  conf-is_default = TRUE;
+ }
+   else
+ {
+@@ -308,7 +305,6 @@ gconf_engine_blank (gboolean remote)
+   conf-notify_dirs = NULL;
+   conf-local_sources = NULL;
+   conf-is_local = TRUE;
+-  conf-is_default = FALSE;
+ }
+
+   return conf;
+@@ -512,8 +508,8 @@ ensure_database (GConfEngine  *conf,
+
+   if (conf-database != NULL)
+ return TRUE;
+-
+-  if (conf-is_default)
++
++  if (conf-addresses == NULL)
+ {
+   message = dbus_message_new_method_call (GCONF_DBUS_SERVICE,
+ GCONF_DBUS_SERVER_OBJECT,
+@@ -811,7 +807,9 @@ GConfEngine*
+ gconf_engine_get_default (void)
+ {
+   GConfEngine* conf = NULL;
+-
++  const gchar* source_path;
++  GError* err = NULL;
++
+   if (default_engine)
+ conf = default_engine;
+
+@@ -819,9 +817,21 @@ gconf_engine_get_default (void)
+ {
+   conf = gconf_engine_blank (TRUE);
+
+-  conf-is_default = TRUE;
+-
+   default_engine = conf;
++
++  source_path = g_getenv (GCONF_DEFAULT_SOURCE_PATH);
++  if (source_path != NULL)
++   {
++ conf-addresses = gconf_load_source_path (source_path, err);
++ if (err)
++   {
++ g_warning (Could not parse GCONF_DEFAULT_SOURCE_PATH: %s,
++err-message);
++ g_error_free (err);
++   }
++   }
++  else
++   conf-addresses = NULL;
+ }
+   else
+ conf-refcount += 1;
+@@ -843,7 +853,6 @@ gconf_engine_get_for_address (const gchar* address, 
GError** err)
+ {
+   conf = gconf_engine_blank (TRUE);
+
+-  conf-is_default = FALSE;
+   conf-addresses = addresses;
+
+   if (!ensure_database (conf, TRUE, err))
+@@ -877,7 +886,6 @@ gconf_engine_get_for_addresses (GSList *addresses, 
GError** err)
+
+   conf = gconf_engine_blank (TRUE);
+
+-  conf-is_default = FALSE;
+   conf-addresses = NULL;
+
+   tmp = addresses;
+--
+1.7.6.3
+
diff --git a/debian/patches/series b/debian/patches/series
index ed48d84..c92dfd1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,5 @@
 01_defaults_path.patch
 02_fix_wrong_return_value.patch
 04_manpage.patch
+05-D-Bus-backend-Add-GCONF_DEFAULT_SOURCE_PATH-support-.patch
 25_gconf-path-max-hurd.patch
--
1.7.6.3




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

Bug#647313: xdg-user-dirs-update uses incorrect config file paths

[Sascha Silbe]

Package: xdg-user-dirs
Version: 0.14-1
Severity: important

Dear Maintainer,

xdg-user-dirs-update tries to load the system-wide configuration files
from /etc, rather than from /etc/xdg where they have been installed by
the package:

(wheezy-jhbuild)sascha.silbe@twin:~$ strace -f -s 256 xdg-user-dirs-update
[...]
stat(/home/sascha.silbe/.config/user-dirs.conf, 0x7fffb17b9f10) = -1 ENOENT 
(No such file or directory)
stat(/home/sascha.silbe/sugar-jhbuild/install/etc/xdg/user-dirs.conf, 
0x7fffb17b9f10) = -1 ENOENT (No such file or directory)
stat(/etc/user-dirs.conf, 0x7fffb17b9f10) = -1 ENOENT (No such file or 
directory)
stat(/home/sascha.silbe/.config/user-dirs.defaults, 0x7fffb17b9cd0) = -1 
ENOENT (No such file or directory)
stat(/home/sascha.silbe/sugar-jhbuild/install/etc/xdg/user-dirs.defaults, 
0x7fffb17b9cd0) = -1 ENOENT (No such file or directory)
stat(/etc/user-dirs.defaults, 0x7fffb17b9cd0) = -1 ENOENT (No such file or 
directory)
write(2, No default user directories\n, 28) = 28
[...]
(wheezy-jhbuild)sascha.silbe@twin:~$ ls -l /etc/xdg/user-dirs.*
-rw-r--r-- 1 root root 414 Jul 30 17:00 /etc/xdg/user-dirs.conf
-rw-r--r-- 1 root root 418 Jul 30 17:00 /etc/xdg/user-dirs.defaults
(wheezy-jhbuild)sascha.silbe@twin:~$


This renders xdg-user-dir unusable on systems without pre-existing user
configuration files or manual intervention by the user (like setting up
symlinks in /etc that point to the correct locations).


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

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

Versions of packages xdg-user-dirs depends on:
ii  libc6  2.13-21

xdg-user-dirs recommends no packages.

xdg-user-dirs 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#637823: [Debian-olpc-devel] Bug#637823: uses deprecated python-evince

[Sascha Silbe]

Excerpts from Michael Biebl's message of Sun Aug 14 23:34:47 +0200 2011:

 sugar-read-activity uses python-evince, a python binding for libevince
 which is part of gnome-python-desktop 2.32.
 
 python-evince will no longer be buildable, as soon as we upload evince
 3.0 to unstable (it's currently available in experimental)
 The bindings for libevdocument and libevview in version 3.0 are
 generated using the GObject Introspection framework [1].
 
 Your package needs to be updated to use that new binding infrastructure.

Updating Read to use evince 3 requires a GTK 3 based sugar-toolkit
version since GTK 2 and GTK 3 cannot be mixed within the same process.
Porting Sugar to Gnome 3 is an ongoing effort [1] and will probably take
another few months to complete.

In the meantime it would be great to have an actually working version
[2,3] of python-evince:

 import evince
 evince.View
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'View'

(wheezy-jhbuild)sascha.silbe@twin:~$ dpkg -l python-evince
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  python-evince  2.32.0-1+b1Python bindings for the 
evince libraries


Sascha

[1] https://wiki.sugarlabs.org/go/Features/GTK3
[2] https://bugzilla.gnome.org/show_bug.cgi?id=639758
[3] 
http://git.gnome.org/browse/gnome-python-desktop/commit/?id=fe79fd6f6a6ef1047bbca3e56cef3823e64869b1
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature

Bug#644010: python-hippocanvas: Needs to be rebuilt against Python 2.7

[Sascha Silbe]

Package: python-hippocanvas
Version: 0.3.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

the default Python version in Wheezy has been changed to 2.7 and consequently
python-hippocanvas broke as it only ships a Python 2.6 extension module:

Traceback (most recent call last):
  File /home/sascha.silbe/sugar-jhbuild/install/bin/sugar-intro, line 20, in 
module
from jarabe import intro
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/intro/__init__.py,
 line 8, in module
from jarabe.intro.window import IntroWindow
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/intro/window.py,
 line 25, in module
import hippo
ImportError: No module named hippo

(wheezy-jhbuild)sascha.silbe@twin:~$ dpkg -L python-hippocanvas
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python-hippocanvas
/usr/share/doc/python-hippocanvas/README
/usr/share/doc/python-hippocanvas/AUTHORS
/usr/share/doc/python-hippocanvas/copyright
/usr/share/doc/python-hippocanvas/changelog.Debian.gz
/usr/share/doc/python-hippocanvas/NEWS.gz
/usr/share/doc/python-hippocanvas/changelog.gz
/usr/share/doc/python-hippocanvas/TODO
/usr/lib
/usr/lib/python2.6
/usr/lib/python2.6/dist-packages
/usr/lib/python2.6/dist-packages/hippo.so
(wheezy-jhbuild)sascha.silbe@twin:~$


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

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

Versions of packages python-hippocanvas depends on:
ii  libatk1.0-0 2.2.0-1
ii  libc6   2.13-21
ii  libcairo2   1.10.2-6.1
ii  libcroco3   0.6.2-1
ii  libfontconfig1  2.8.0-3
ii  libfreetype62.4.6-2
ii  libgdk-pixbuf2.0-0  2.24.0-1
ii  libglib2.0-02.28.6-1
ii  libgtk2.0-0 2.24.6-1
ii  libhippocanvas-1-0  0.3.1-1
ii  libpango1.0-0   1.28.4-3
ii  libpng12-0  1.2.46-3
ii  librsvg2-2  2.34.1-2
ii  libxml2 2.7.8.dfsg-4

python-hippocanvas recommends no packages.

python-hippocanvas 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#640222: nfs-common: init script failure during installation, leaving package half-configured

[Sascha Silbe]

Package: nfs-common
Version: 1:1.2.4-1
Severity: normal


For an unknown reason /etc/init.d/nfs-common start failed during
installation of nfs-common, leaving the package in half-configured state:

sascha.silbe@mimosa:~$ sudo aptitude install nfs-common
The following NEW packages will be installed:

  libgssglue1{a} [0.3-2] +98.3 kB (D: libtirpc1, D: nfs-common) (for 
nfs-common)
  libnfsidmap2{a} [0.24-1] +123 kB (D: nfs-common) (for nfs-common)
  libtirpc1{a} [0.2.2-5] +242 kB (D: nfs-common, D: rpcbind) (for nfs-common)
  nfs-common [1:1.2.4-1] +721 kB
  rpcbind{a} [0.2.0-6] +172 kB (D: nfs-common) (for nfs-common)
0 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 414 kB of archives. After unpacking 1,356 kB will be used.
Do you want to continue? [Y/n/?] y
Get:1 http://ftp.de.debian.org/debian/ wheezy/main libgssglue1 armel 0.3-2 
[22.0 kB]
Get:2 http://ftp.de.debian.org/debian/ wheezy/main libtirpc1 armel 0.2.2-5 
[76.2 kB]
Get:3 http://ftp.de.debian.org/debian/ wheezy/main libnfsidmap2 armel 0.24-1 
[30.3 kB]
Get:4 http://ftp.de.debian.org/debian/ wheezy/main rpcbind armel 0.2.0-6 [41.3 
kB]
Get:5 http://ftp.de.debian.org/debian/ wheezy/main nfs-common armel 1:1.2.4-1 
[244 kB]
Fetched 414 kB in 1s (253 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously deselected package libgssglue1.
(Reading database ... 98059 files and directories currently installed.)
Unpacking libgssglue1 (from .../libgssglue1_0.3-2_armel.deb) ...
Selecting previously deselected package libtirpc1.
Unpacking libtirpc1 (from .../libtirpc1_0.2.2-5_armel.deb) ...
Selecting previously deselected package libnfsidmap2.
Unpacking libnfsidmap2 (from .../libnfsidmap2_0.24-1_armel.deb) ...
Selecting previously deselected package rpcbind.
Unpacking rpcbind (from .../rpcbind_0.2.0-6_armel.deb) ...
Selecting previously deselected package nfs-common.
Unpacking nfs-common (from .../nfs-common_1%3a1.2.4-1_armel.deb) ...
Processing triggers for man-db ...
Setting up libgssglue1 (0.3-2) ...
Setting up libtirpc1 (0.2.2-5) ...
Setting up libnfsidmap2 (0.24-1) ...
Setting up rpcbind (0.2.0-6) ...
Starting rpcbind daemon
Setting up nfs-common (1:1.2.4-1) ...

Creating config file /etc/idmapd.conf with new version

Creating config file /etc/default/nfs-common with new version
Adding system user `statd' (UID 107) ...
Adding new user `statd' (UID 107) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Starting NFS common utilities: statd idmapd failed!
invoke-rc.d: initscript nfs-common, action start failed.
dpkg: error processing nfs-common (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
  Errors were encountered while processing:
 nfs-common
[master 294ea6f] committing changes in /etc after apt run
 Author: sascha.silbe sascha.si...@mimosa.sascha.silbe.org
 115 files changed, 525 insertions(+), 50 deletions(-)
 create mode 100644 default/nfs-common
 create mode 100644 gssapi_mech.conf
 create mode 100644 idmapd.conf
 rewrite init.d/.depend.start (69%)
 rewrite init.d/.depend.stop (60%)
 create mode 100755 init.d/nfs-common
 create mode 100755 init.d/rpcbind
 create mode 100644 insserv.conf.d/rpcbind
 create mode 100644 netconfig
 create mode 12 rc0.d/K05nfs-common
 create mode 12 rc0.d/K05rpcbind
 rename rc0.d/{K04hwclock.sh = K06hwclock.sh} (100%)
 rename rc0.d/{K05networking = K06networking} (100%)
 rename rc0.d/{K06ifupdown = K07ifupdown} (100%)
 rename rc0.d/{K07umountfs = K08umountfs} (100%)
 rename rc0.d/{K08cryptdisks = K09cryptdisks} (100%)
 rename rc0.d/{K09cryptdisks-early = K10cryptdisks-early} (100%)
 rename rc0.d/{K10umountroot = K11umountroot} (100%)
 rename rc0.d/{K11halt = K12halt} (100%)
 create mode 12 rc1.d/K05nfs-common
 create mode 12 rc1.d/K05rpcbind
 rename rc1.d/{S02bootlogs = S20bootlogs} (100%)
 rename rc1.d/{S03single = S21single} (100%)
 create mode 12 rc2.d/S16rpcbind
 create mode 12 rc2.d/S17nfs-common
 rename rc2.d/{S01nodm = S19nodm} (100%)
 rename rc2.d/{S01rsyslog = S19rsyslog} (100%)
 rename rc2.d/{S01sudo = S19sudo} (100%)
 rename rc2.d/{S02bootlogs = S20bootlogs} (100%)
 rename rc2.d/{S02cron = S20cron} (100%)
 rename rc2.d/{S02dbus = S20dbus} (100%)
 rename rc2.d/{S02nullmailer = S20nullmailer} (100%)
 rename rc2.d/{S02pcscd = S20pcscd} (100%)
 rename rc2.d/{S02rsync = S20rsync} (100%)
 rename rc2.d/{S02ssh = S20ssh} (100%)
 rename rc2.d/{S03avahi-daemon = S21avahi-daemon} (100%)
 rename rc2.d/{S03network-manager = S21network-manager} (100%)
 rename rc2.d/{S04rc.local = S22rc.local} (100%)
 rename rc2.d/{S04rmnologin = S22rmnologin} (100%)
 rename rc2.d/{S04stop-bootlogd = S22stop-bootlogd} (100%)
 create mode 12 rc3.d/S16rpcbind
 create mode 12 rc3.d/S17nfs-common
 rename rc3.d/{S01nodm = S19nodm} (100%)
 rename rc3.d/{S01rsyslog = S19rsyslog} (100%)
 rename 

Bug#638716: etckeeper: please ignore shadow backup files (/etc/{passwd, group, shadow, gshadow}-)

[Sascha Silbe]

Package: etckeeper
Version: 0.48
Severity: wishlist


The shadow backup files /etc/{passwd,group,shadow,gshadow}- duplicate
data already tracked by etckeeper. Please add them to the default ignore list.

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

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

Versions of packages etckeeper depends on:
ii  debconf [debconf-2.0]1.5.36.1Debian configuration management sy
ii  git [git-core]   1:1.7.5.4-1 fast, scalable, distributed revisi
ii  mercurial1.6.4-1 scalable distributed version contr

Versions of packages etckeeper recommends:
ii  cron  3.0pl1-116 process scheduling daemon

etckeeper suggests no packages.

-- Configuration Files:
/etc/etckeeper/init.d/20restore-etckeeper changed [not included]

-- 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#638718: debootstrap: please add loopback configuration to /etc/network/interfaces

[Sascha Silbe]

Package: debootstrap
Version: 1.0.26+squeeze1
Severity: wishlist


I'm filing this against debootstrap because the system was installed
using debootstrap and /etc/network/interfaces isn't owned by any
package, so my best guess is that the file was created by debootstrap.
Feel free to reassign this ticket as appropriate.

The default /etc/network/interfaces contains no configuration at all.
However having the loopback interface up and running is important for
many programs. Please add loopback configuration to the default
/etc/network/interfaces like debian-installer does:

=== Begin ===
# The loopback network interface
auto lo
iface lo inet loopback
=== End ===

For chroots this doesn't hurt (/etc/init.d/ifupdown won't get called),
but for real systems it's crucial.

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

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

Versions of packages debootstrap depends on:
ii  wget  1.12-2.1   retrieves files from the web

Versions of packages debootstrap recommends:
ii  gnupg 1.4.10-4   GNU privacy guard - a free PGP rep

debootstrap 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#638723: network-manager: uses group netdev in D-Bus policy files, but does not create the group

[Sascha Silbe]

Package: network-manager
Version: 0.8.4.0-2
Severity: normal


On a brand new system installed using debootstrap, the following error
occurs during installation of NetworkManager:

Setting up dbus (1.4.14-1) ...
Starting system message bus: dbusUnknown group netdev in message bus 
configuration file
..

These are the offending files:

root@mimosa:/etc# git grep netdev -- dbus-1
dbus-1/system.d/NetworkManager.conf:policy group=netdev
dbus-1/system.d/wpa_supplicant.conf:policy group=netdev
root@mimosa:/etc#


I'm not quite sure who should create the group (maybe both wpasupplicant
and network-manager), so I'm filing this against network-manager (only).
Feel free to reassign or duplicate the bug.

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

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



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

Bug#638723: Acknowledgement (network-manager: uses group netdev in D-Bus policy files, but does not create the group)

[Sascha Silbe]

This appears to have been just a sequencing issue: after the
installation was finished, it worked fine:

root@mimosa:/etc# /etc/init.d/dbus reload
Reloading system message bus config...done.
root@mimosa:/etc# 


I needed to restart installation after running into Debian#630750 and
can't rule out that that changed the ordering. Here's the full log:

=== Begin ===
root@mimosa:/etc# aptitude install network-manager libpam-ck-connector-
The following NEW packages will be installed:
  consolekit{a} [0.4.5-1] +639 kB (D: policykit-1) (for
network-manager)  
  dbus{a} [1.4.14-1] +913 kB (D: consolekit, D: network-manager, D:
policykit-1, R: libdbus-1-3) (for network-manager)  
  dnsmasq-base{a} [2.57-1] +745 kB (R: network-manager) (for
network-manager)  libck-connector0{a} [0.4.5-1] +115 kB (D:
consolekit) (for network-manager)  
  libdbus-1-3{a} [1.4.14-1] +369 kB (D: consolekit, D: dbus, D:
dnsmasq-base, D: libck-connector0, D: libdbus-glib-1-2, D: libnm-glib2,
D: libnm-util1, D: modemmanager, D: network-manager, D: wpasupplicant)
(for network-manager)  
  libdbus-glib-1-2{a} [0.94-4] +340 kB (D: consolekit, D: libnm-glib2,
D: libnm-util1, D: modemmanager, D: network-manager) (for
network-manager)  
  libglib2.0-0{a} [2.28.6-1] +3,154 kB (D: consolekit, D:
libdbus-glib-1-2, D: libgudev-1.0-0, D: libnm-glib2, D: libnm-util1, D:
libpolkit-agent-1-0, D: libpolkit-backend-1-0, D: libpolkit-gobject-1-0,
D: modemmanager, D: network-manager, D: policykit-1, D:
shared-mime-info) (for network-manager)  
  libglib2.0-data{a} [2.28.6-1] +6,599 kB (R: libglib2.0-0) (for
network-manager)  
  libgudev-1.0-0{a} [172-1] +193 kB (D: libnm-glib2, D: modemmanager,
D: network-manager) (for network-manager)  
  libnl1{a} [1.1-7] +348 kB (D: network-manager, D: wpasupplicant)
(for network-manager)  
  libnm-glib2{a} [0.8.4.0-2] +434 kB (D: network-manager) (for
network-manager)  
  libnm-util1{a} [0.8.4.0-2] +561 kB (D: libnm-glib2, D:
network-manager) (for network-manager)  libpcap0.8{a} [1.1.1-8] +307
kB (D: ppp) (for network-manager)  
  libpcre3{a} [8.12-4] +463 kB (D: libglib2.0-0, S: grep) (for
network-manager)  
  libpcsclite1{a} [1.7.4-1] +123 kB (D: wpasupplicant, S: gnupg) (for
network-manager)  
  libpolkit-agent-1-0{a} [0.102-1] +90.1 kB (D: policykit-1) (for
network-manager)  
  libpolkit-backend-1-0{a} [0.102-1] +143 kB (D: policykit-1) (for
network-manager)  
  libpolkit-gobject-1-0{a} [0.102-1] +156 kB (D: consolekit, D:
libpolkit-agent-1-0, D: libpolkit-backend-1-0, D: network-manager, D:
policykit-1) (for network-manager)  
  libxml2{a} [2.7.8.dfsg-4] +1,610 kB (D: shared-mime-info) (for
network-manager)  
  modemmanager{a} [0.4.997-1] +1,061 kB (R: network-manager) (for
network-manager)  network-manager [0.8.4.0-2] +3,686 kB  
  policykit-1{a} [0.102-1] +348 kB (R: network-manager) (for
network-manager)  
  ppp{a} [2.4.5-5] +1,069 kB (R: network-manager, S: ifupdown) (for
network-manager)  sgml-base{a} [1.26+nmu1] +152 kB (D: xml-core) (for
network-manager)  
  shared-mime-info{a} [0.90-1] +4,088 kB (R: libglib2.0-0) (for
network-manager)  tcl{a} [8.5.0-2] +69.6 kB (D: usb-modeswitch) (for
network-manager)  
  tcl8.5{a} [8.5.10-1] +4,432 kB (D: tcl, D: usb-modeswitch) (for
network-manager)  
  usb-modeswitch{a} [1.1.9-1] +193 kB (R: modemmanager, R:
usb-modeswitch-data) (for network-manager)  
  usb-modeswitch-data{a} [20110805-1] +242 kB (D: usb-modeswitch, R:
usb-modeswitch-data) (for network-manager)  
  wpasupplicant{a} [0.7.3-3] +1,139 kB (D: network-manager) (for
network-manager)  xml-core{a} [0.13] +266 kB (R: libxml2) (for
network-manager)  
The following packages are RECOMMENDED but will NOT be installed:
  libpam-ck-connector (R: consolekit)  
0 packages upgraded, 31 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.8 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?] 
Get:1 http://ftp.de.debian.org/debian/ wheezy/main libpcre3 armel 8.12-4
[223 kB]
Get:2 http://ftp.de.debian.org/debian/ wheezy/main libdbus-1-3 armel
1.4.14-1 [146 kB]
Get:3 http://ftp.de.debian.org/debian/ wheezy/main libglib2.0-0 armel
2.28.6-1 [1,535 kB]
Get:4 http://ftp.de.debian.org/debian/ wheezy/main libdbus-glib-1-2
armel 0.94-4 [180 kB]
Get:5 http://ftp.de.debian.org/debian/ wheezy/main libgudev-1.0-0 armel
172-1 [108 kB]
Get:6 http://ftp.de.debian.org/debian/ wheezy/main libnl1 armel 1.1-7
[121 kB]
Get:7 http://ftp.de.debian.org/debian/ wheezy/main libpcap0.8 armel
1.1.1-8 [126 kB]
Get:8 http://ftp.de.debian.org/debian/ wheezy/main tcl8.5 armel 8.5.10-1
[1,569 kB]
Get:9 http://ftp.de.debian.org/debian/ wheezy/main tcl all 8.5.0-2
[4,636 B]
Get:10 http://ftp.de.debian.org/debian/ wheezy/main usb-modeswitch-data
all 20110805-1 [29.4 kB]
Get:11 http://ftp.de.debian.org/debian/ wheezy/main usb-modeswitch armel
1.1.9-1 [46.2 kB]
Get:12 http://ftp.de.debian.org/debian/ wheezy/main libxml2 armel
2.7.8.dfsg-4 [815 kB]
Get:13 http://ftp.de.debian.org/debian/ wheezy/main 

Bug#573518: mime-support: outdated for several years, Fedora git repo

[Sascha Silbe]

Package: mime-support
Version: 3.48-1
Severity: normal


mime-support apparently hasn't been synced with upstream (IANA) for
several years now. The MIME type I've noticed as missing
(application/vnd.olpc-sugar) has been registered at IANA since at least
2007-06-07 [1].

Having proper file extension - MIME type mappings by default would
make things a lot easier for operators of HTTP servers that publish
files of this type.

The Fedora git repository mentioned in the original report seems to live
at [2] now (web browsable via [3]). The mime.types file in that
repository contains application/vnd.olpc-sugar [4], so it's at least
more recent than the one shipped by the Debian mime-support package.

I don't know how they sync with IANA, but asking Ville Skyttä
ville.sky...@iki.fi (the author of the last commit, titled Sync with
IANA as of 2011-07-17) sounds like a good idea.

[1] http://www.iana.org/assignments/media-types/application/vnd.olpc-sugar
[2] git://git.fedorahosted.org/mailcap.git
[3] http://git.fedorahosted.org/git/?p=mailcap.git
[4] 
http://git.fedorahosted.org/git?p=mailcap.git;a=blob;f=mime.types;h=b001b051ab2a2f0f1241688243cff151bcf2414d;hb=HEAD#l652

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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  file  5.04-5 Determines file type using magic

mime-support 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#635289: [PATCH sugar-base] Add support for IPython 0.11+

[Sascha Silbe]

From: Julian Taylor jtaylor.deb...@googlemail.com

IPython 0.11 has changed API: AutoFormattedTB is now in IPython.core.ultratb,
not in IPython.ultraTB. We automatically fall back to the pre-0.11 names if
the 0.11 import statement fails.

[added comments, changed description]
Signed-off-by: Sascha Silbe si...@activitycentral.com
Reviewed-by: Sascha Silbe si...@activitycentral.com
---
 src/sugar/logger.py |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/sugar/logger.py b/src/sugar/logger.py
index 275c57d..21cd2c9 100644
--- a/src/sugar/logger.py
+++ b/src/sugar/logger.py
@@ -69,7 +69,13 @@ def _except_hook(exctype, value, traceback):
 # Attempt to provide verbose IPython tracebacks.
 # Importing IPython is slow, so we import it lazily.
 try:
-from IPython.ultraTB import AutoFormattedTB
+try:
+# IPython 0.11+
+from IPython.core.ultratb import AutoFormattedTB
+except ImportError:
+# IPython 0.10.2 and below
+from IPython.ultraTB import AutoFormattedTB
+
 sys.excepthook = AutoFormattedTB(mode='Verbose',
 color_scheme='NoColor')
 except ImportError:
-- 
1.7.5.4




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

Bug#634265: d-feet: GTK warnings on start-up

[Sascha Silbe]

Package: d-feet
Version: 0.1.10-3
Severity: minor


d-feet prints the following warnings on start-up:

=== Begin ===
/usr/lib/pymodules/python2.6/dfeet/_ui/uiloader.py:38: GtkWarning: Unknown 
property: GtkAction.enabled
  self.ui.add_from_file(ui_dir + '/' + file)
/usr/lib/pymodules/python2.6/dfeet/_ui/uiloader.py:38: GtkWarning: GtkPaned 
cannot have more than 2 children

  self.ui.add_from_file(ui_dir + '/' + file)
/usr/lib/pymodules/python2.6/dfeet/_ui/uiloader.py:38: GtkWarning: GtkVPaned 
does not have a property called expand
  self.ui.add_from_file(ui_dir + '/' + file)
/usr/lib/pymodules/python2.6/dfeet/_ui/uiloader.py:38: GtkWarning: GtkVPaned 
does not have a property called pack_type
  self.ui.add_from_file(ui_dir + '/' + file)
=== End ===

The GUI seems to be complete (thus Severity: minor), but not having used
d-feet before I can't be sure.

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

Kernel: Linux 2.6.35.13-xo1.5-2-00903-g8ed2132 (PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages d-feet depends on:
ii  hicolor-icon-theme  0.12-1   default fallback theme for FreeDes
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-dbus 0.83.1-1 simple interprocess messaging syst
ii  python-glade2   2.17.0-4 GTK+ bindings: Glade support
ii  python-gtk2 2.17.0-4 Python bindings for the GTK+ widge
ii  python-support  1.0.10   automated rebuilding support for P

Versions of packages d-feet recommends:
ii  python-wnck   2.30.0-4   Python bindings for the WNCK libra

d-feet 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#631384: python-webdav: Incomplete PROPFIND response

[Sascha Silbe]

Excerpts from Daniel Baumann's message of Sun Jul 10 15:26:36 +0200 2011:
 you forgot to attach the patch.

Oops, sorry. Here it is.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


propfind-ns-fix.patch
Description: Binary data


signature.asc
Description: PGP signature

Bug#631384: python-webdav: Incomplete PROPFIND response

[Sascha Silbe]

Package: python-webdav
Version: 0.9.4-1+squeeze1
Severity: normal
Tags: patch


python-webdav returns only the properties of a single namespace, not
all of them. That's because the two loops in
DAV.propfind.PROPFIND.mk_propname_response() are sequential instead of
nested. Patch attached.

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

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

Versions of packages python-webdav depends on:
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-pkg-resources0.6.14-4 Package Discovery and Resource Acc
ii  python-support  1.0.10   automated rebuilding support for P

python-webdav recommends no packages.

python-webdav 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#628484: python-xpcom: 'print' method from nsIWebBrowserPrint doesn't work because it triggers a syntax error

[Sascha Silbe]

Package: python-xpcom
Version: 1:0.0~hg20100212-5+1
Severity: normal


When trying to access the 'print' method of the nsIWebBrowserPrint
interface, python-xpcom generates Python code on the fly and fails to
evaluate it because 'print' is a reserved keyword in Python:

(sugar-jhbuild1)sascha.silbe@twin:~$ ./print-bug.py
returning /tmp/prefs.js for key NS_APP_PREFS_50_FILE
GConf Error: Failed to contact configuration server; the most common cause is a 
missing or misconfigured D-Bus session bus daemon. See 
http://projects.gnome.org/gconf/ for information. (Details -  1: Server ping 
error: IDL:omg.org/CORBA/COMM_FAILURE:1.0)
Traceback (most recent call last):
  File ./print-bug.py, line 20, in _save_pdf
getattr(print_iface, 'print')
  File /usr/lib/pymodules/python2.6/xpcom/client/__init__.py, line 374, in 
__getattr__
return getattr(interface, attr)
  File /usr/lib/pymodules/python2.6/xpcom/client/__init__.py, line 466, in 
__getattr__
unbound_method = BuildMethod(method_info, self._iid_)
  File /usr/lib/pymodules/python2.6/xpcom/client/__init__.py, line 125, in 
BuildMethod
codeObject = compile(method_code, XPCOMObject method '%s' % (name,), 
exec)
  File XPCOMObject method 'print', line 2
def print(self, Param1, Param2):
^
SyntaxError: invalid syntax


print-bug.py is attached.

In case anyone else gets stuck on the issue, here is how I worked around it:

try:
print_method = getattr(print_iface, 'print')
except SyntaxError:
# HACK: Run-time patch python-xpcom to work around a bug.
# 'print' is a reserved keyword, so it must not occur in generated
# code.
iid = interfaces.nsIWebBrowserPrint
internal_interface = print_iface.__dict__['_interfaces_'][iid]
info = internal_interface.__dict__['_method_infos_']['print']
info.name = 'print_'
print_method = getattr(print_iface, 'print')


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

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

Versions of packages python-xpcom depends on:
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libnspr4-0d 4.8.6-1  NetScape Portable Runtime Library
ii  libpython2.62.6.6-8+b1   Shared Python runtime library (ver
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-support  1.0.10   automated rebuilding support for P
ii  xulrunner-1.9.2 1.9.2.13-2   XUL + XPCOM application runner

python-xpcom recommends no packages.

python-xpcom suggests no packages.

-- no debconf information
#!/usr/bin/env python
import gobject
import gtk
import hulahop.webview
import xpcom.components

hulahop.startup('/tmp')


class Browser(hulahop.webview.WebView):
def do_setup(self):
hulahop.webview.WebView.do_setup(self)
gobject.timeout_add(3, self._save_pdf)

def _save_pdf(self):
cls = xpcom.components.classes['@mozilla.org/gfx/printsettings-service;1']
setting_service = cls.getService(xpcom.components.interfaces.nsIPrintSettingsService)
req = self.get_dom_window().QueryInterface(xpcom.components.interfaces.nsIInterfaceRequestor)
print_iface = req.getInterface(xpcom.components.interfaces.nsIWebBrowserPrint)
getattr(print_iface, 'print')


browser = Browser()
browser.show()
main_window = gtk.Window()
main_window.add(browser)
main_window.show()
browser.load_uri('http://www.sugarlabs.org/')
gtk.main()

Bug#627450: paprass available only in french

[Sascha Silbe]

Package: paprass
Version: 2.05-1
Severity: normal


paprass is written in french without translation to any other language, not
even to english. It's very hard to use simply because I'd have to look up
every string in a dictionary first.

This should be mentioned clearly in the package description.


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

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

Versions of packages paprass depends on:
ii  python-imaging-sane1.1.7-2   Python Imaging Library - SANE inte
ii  python-reportlab   2.4-4 ReportLab library to create PDF do
ii  python-wxgtk2.82.8.10.1-3+b1 wxWidgets Cross-platform C++ GUI t

paprass recommends no packages.

paprass 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#620345: libcap2-bin: setpcaps, sucap and execcap are missing

[Sascha Silbe]

Package: libcap2-bin
Version: 1:2.19-3
Severity: important


libcap2-bin is lacking several of the utilities mentioned in the package
description: execcap, sucap and - this is the problematic part - setpcaps.

execcap and sucap were intended as work-arounds for the lack of support
for file-based capabilities, so they might be obsolete and would just
need to be removed from the package description (it wouldn't harm to
keep them, though).

setpcaps OTOH is the only tool that can change the capabilities of an
(already running) process. There's no alternative in licap-ng-utils.
This is the reason for Severity: important.

-- System Information:
Debian Release: 6.0.1
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.34-rc7-flatty-ocf-2-00126-g835446b
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcap2-bin depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libcap2   1:2.19-3   support for getting/setting POSIX.
ii  libpam-runtime1.1.1-6.1  Runtime support for the PAM librar
ii  libpam0g  1.1.1-6.1  Pluggable Authentication Modules l

libcap2-bin recommends no packages.

Versions of packages libcap2-bin suggests:
pn  libcap-devnone (no description available)

-- 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#620419: psi: causes 10Hz wake-ups even if not connected

[Sascha Silbe]

Package: psi
Version: 0.14-2
Severity: normal


powertop shows psi causing 10 wake-ups per second even if it's offline.
This wastes energy; in particular it can prevent some hardware from
entering lower power states.

-- System Information:
Debian Release: 6.0.1
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages psi depends on:
ii  libaspell15 0.60.6-4 GNU Aspell spell-checker runtime l
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libgcc1 1:4.4.5-8GCC support library
ii  libqca2 2.0.2-1  libraries for the Qt Cryptographic
ii  libqca2-plugin-ossl 0.1~20070904-4   QCA OSSL plugin for libqca2
ii  libqt4-dbus 4:4.6.3-4Qt 4 D-Bus module
ii  libqt4-network  4:4.6.3-4Qt 4 network module
ii  libqt4-qt3support   4:4.6.3-4Qt 3 compatibility library for Qt
ii  libqt4-xml  4:4.6.3-4Qt 4 XML module
ii  libqtcore4  4:4.6.3-4Qt 4 core module
ii  libqtgui4   4:4.6.3-4Qt 4 GUI module
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libx11-62:1.3.3-4X11 client-side library
ii  libxss1 1:1.2.0-2X11 Screen Saver extension library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages psi recommends:
ii  sox  14.3.1-1+b1 Swiss army knife of sound processi

Versions of packages psi suggests:
ii  libqca2-plugin-gnupg 2.0.0~beta3-1   QCA gnupg plugin for libqca2
pn  psi-translations none  (no description available)
ii  xdg-utils1.0.2+cvs20100307-2 desktop integration utilities from

-- 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#619643: gnome-session: please provided updated package (at least 2.91.4)

[Sascha Silbe]

Source: gnome-session
Version: 2.30.2-3
Severity: wishlist


gnome-session 2.91.4 changed the way sessions are defined, allowing non-Gnome
desktop environments to use gnome-session as-is (by passing a CLI option).

It would be great to have an updated Debian package for gnome-session (with
all the dependencies that might need to be updated), even if just in
experimental. 2.91.93 would be preferred since 2.91.92 introduced an
incompatible format change, but 2.91.4 should be enough for now.

-- 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.35.9-xo1.5-2-00133-gf43bb39 (PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-session-bin depends on:
ii  dbus-x11  1.2.24-4   simple interprocess messaging syst
ii  gconf22.28.1-6   GNOME configuration database syste
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libdbus-1-3   1.2.24-4   simple interprocess messaging syst
ii  libdbus-glib-1-2  0.88-2.1   simple interprocess messaging syst
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface
ii  libice6   2:1.0.6-2  X11 Inter-Client Exchange library
ii  libsm62:1.1.1-1  X11 Session Management library
ii  libupower-glib1   0.9.5-5abstraction for power management -
ii  libx11-6  2:1.3.3-4  X11 client-side library
ii  libxau6   1:1.0.6-1  X11 authorisation library
ii  libxext6  2:1.1.2-1  X11 miscellaneous extension librar
ii  libxrender1   1:0.9.6-1  X Rendering Extension client libra
ii  libxtst6  2:1.1.0-3  X11 Testing -- Record extension li
ii  upower0.9.5-5abstraction for power management

gnome-session-bin recommends no packages.

gnome-session-bin 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#619126: python-gtk2: please update PyGtk to at least 2.22

[Sascha Silbe]

Package: python-gtk2
Version: 2.17.0-4
Severity: wishlist


The current upstream version of PyGtk is 2.26 (released on 2010-09-27).
It would be great to have at least PyGtk 2.22 since it wraps API that was
added in GTK 2.20 (most notably GtkOffscreenWindow).

-- System Information:
Debian Release: 6.0.1
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python-gtk2 depends on:
ii  libatk1.0-0   1.30.0-1   The ATK accessibility toolkit
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-6   The Cairo 2D vector graphics libra
ii  libfontconfig12.8.0-2.1  generic font configuration library
ii  libfreetype6  2.4.2-2.1  FreeType 2 font engine, shared lib
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface
ii  libpango1.0-0 1.28.3-1+squeeze2  Layout and rendering of internatio
ii  python2.6.6-3+squeeze6   interactive high-level object-orie
ii  python-cairo [python2 1.8.8-1+b1 Python bindings for the Cairo vect
ii  python-gobject [pytho 2.21.4+is.2.21.3-1 Python bindings for the GObject li
ii  python-numpy  1:1.4.1-5  Numerical Python adds a fast array
ii  python-support1.0.10 automated rebuilding support for P
pn  python2.5-cairo   none (no description available)
pn  python2.5-gobject none (no description available)

python-gtk2 recommends no packages.

Versions of packages python-gtk2 suggests:
ii  python-gtk2-doc   2.17.0-4   Python bindings for the GTK+ widge

-- 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#617350: etckeeper init in existing VCS checkout chokes on file names containing special characters

[Sascha Silbe]

Package: etckeeper
Version: 0.48
Severity: normal


Running etckeeper init on a checkout of a git repository managed by
etckeeper chokes on file names containing special characters:

sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT$ git clone 
flatty:git/etc-xo15-sascha
Cloning into etc-xo15-sascha...
remote: Counting objects: 4131, done.
remote: Compressing objects: 100% (3107/3107), done.
remote: Total 4131 (delta 1222), reused 2320 (delta 307)
Receiving objects: 100% (4131/4131), 1.37 MiB | 669 KiB/s, done.
Resolving deltas: 100% (1222/1222), done.
sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT$ cd etc-xo15-sascha/
sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT/etc-xo15-sascha$ sudo 
etckeeper init -d .
[: 1: ./NetworkManager/system-connections/AdHoc: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT/etc-xo15-sascha$ sudo sh 
-x $(which etckeeper) init -d .
[...]
+ /etc/etckeeper/init.d/10restore-metadata
+ /etc/etckeeper/init.d/20restore-etckeeper
[: 1: ./NetworkManager/system-connections/AdHoc: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
[: 1: ./NetworkManager/system-connections/Auto: unexpected operator
+ /etc/etckeeper/init.d/40vcs-init
+ /etc/etckeeper/init.d/50vcs-ignore
+ /etc/etckeeper/init.d/50vcs-perm
+ /etc/etckeeper/init.d/50vcs-pre-commit-hook
+ /etc/etckeeper/init.d/60darcs-deleted-symlinks
+ /etc/etckeeper/init.d/70vcs-add
sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT/etc-xo15-sascha$ grep 
system-connections .etckeeper
maybe chmod 600 './NetworkManager/system-connections/AdHoc for Sugar Ch1'
maybe chmod 600 './NetworkManager/system-connections/Auto 802.1x'
maybe chmod 600 './NetworkManager/system-connections/Auto FRITZ!Box Fon WLAN 
7270'
maybe chmod 600 './NetworkManager/system-connections/Auto Sinus W 500V'
maybe chmod 600 './NetworkManager/system-connections/Caspar'
maybe chmod 600 './NetworkManager/system-connections/DHCP'
maybe chmod 600 './NetworkManager/system-connections/link-local'
sascha.silbe@twin:/tmp/sascha_silbe/tmpbox.7kmjhKHhbT/etc-xo15-sascha$


Because the files in question were written by NetworkManager, there's a
chance for privilege escalation. However it doesn't happen automatically
in the default set-up (etckeeper init isn't usually run on an existing
checkout) and only users that are allowed to configure NetworkManager
system connections are able to exploit it, so I'll leave it up to you
to decide on the severity and handling.


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

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

Versions of packages etckeeper depends on:
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  git [git-core] 1:1.7.2.3-2.2 fast, scalable, distributed revisi
ii  mercurial  1.6.4-1   scalable distributed version contr

Versions of packages etckeeper recommends:
ii  cron  3.0pl1-116 process scheduling daemon

etckeeper suggests no packages.

-- debconf information:
  etckeeper/commit_failed:
  etckeeper/purge: true



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

Bug#617350: Acknowledgement (etckeeper init in existing VCS checkout chokes on file names containing special characters)

[Sascha Silbe]

tag 617350 + patch
thanks

From 39f0dab095eb1a72264920762e2d4d7617b1fd86 Mon Sep 17 00:00:00 2001
From: Sascha Silbe sascha-...@silbe.org
Date: Tue, 8 Mar 2011 12:54:40 +0100
Subject: [PATCH] restore-etckeeper: don't choke on special characters

Include quotes in the to-be-evaluated string so that the expanded parameter
will be interpreted as a single word.
---
 etckeeper/init.d/20restore-etckeeper |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/etckeeper/init.d/20restore-etckeeper 
b/etckeeper/init.d/20restore-etckeeper
index 5dc4425..0485e63 100755
--- a/etckeeper/init.d/20restore-etckeeper
+++ b/etckeeper/init.d/20restore-etckeeper
@@ -7,7 +7,7 @@ maybe () {
command=$1
shift 1
 
-   if eval [ -e \$$# ]; then
+   if eval [ -e \\$$#\ ]; then
$command $@
fi
 }
-- 
1.7.2.3


signature.asc
Description: PGP signature

Bug#612428: libtext-wikicreole-perl: links without description are converted to double a href=... on output

[Sascha Silbe]

Package: libtext-wikicreole-perl
Version: 0.07-1
Severity: normal


If the input contains a link without additional text, creole_parse() will
output two nested a tags:

=== Begin Input ===
[[https://sascha.silbe.org/]]
=== End Input ===

=== Begin Output ===
pa href=https://sascha.silbe.org/;a 
href=https://sascha.silbe.org;https://sascha.silbe.org/a//a/p
=== End Output ===


-- System Information:
Debian Release: 6.0
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libtext-wikicreole-perl depends on:
ii  perl  5.10.1-17  Larry Wall's Practical Extraction

libtext-wikicreole-perl recommends no packages.

libtext-wikicreole-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#611633: python-xpcom: please provide updated package linking against xulrunner-1.9.2

[Sascha Silbe]

Package: python-xpcom
Version: 1:0.0~hg20100212-5
Severity: wishlist


AFAICT xulrunner-1.9.2 fixes a lot of bugs that remain unfixed in
xulrunner-1.9.1, so it would be great to get python-xpcom updated to
support xulrunner-1.9.2.

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

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

Versions of packages python-xpcom depends on:
ii  libc6   2.11.2-9 Embedded GNU C Library: Shared lib
ii  libnspr4-0d 4.8.6-1  NetScape Portable Runtime Library
ii  libpython2.62.6.6-8+b1   Shared Python runtime library (ver
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  python  2.6.6-3+squeeze5 interactive high-level object-orie
ii  python-support  1.0.10   automated rebuilding support for P
ii  xulrunner-1.9.1 1.9.1.16-4   XUL + XPCOM application runner

python-xpcom recommends no packages.

python-xpcom 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#605767: git-email: UTF-8 content in To: causes Subject: to also be RFC2047 encoded

[Sascha Silbe]

Package: git-email
Version: 1:1.7.2.3-2
Severity: minor


If To: contains a non-ASCII character, the Subject: header is RFC2047
encoded even if it contains only ASCII characters:

=== Begin ===
From: Sascha Silbe sascha-...@silbe.org
To: =?UTF-8?q?St=C3=A9phane=20Magnenat?= stephane.magne...@mavt.ethz.ch
Subject: =?UTF-8?q?Patches=20for=20Osqoop?=
Date: Fri,  3 Dec 2010 10:51:30 +0100
Message-Id: 1291369892-17749-1-git-send-email-sascha-...@silbe.org
X-Mailer: git-send-email 1.7.2.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
=== End ===


I haven't checked what happens for different header combinations (e.g.
Subject: or From: containing non-ASCII and To: only ASCII), but would
expect them to show the same issue.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages git-email depends on:
ii  git  1:1.7.2.3-2 fast, scalable, distributed revisi

Versions of packages git-email recommends:
ii  libauthen-sasl-perl   2.1500-1   Authen::SASL - SASL Authentication
ii  libemail-valid-perl   0.184-1Perl module for checking the valid
ii  libnet-smtp-ssl-perl  1.01-2 SSL support for Net::SMTP

Versions of packages git-email suggests:
pn  git-doc   none (no description available)

-- 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