Bug#1036457: flash-kernel: please add BeagleBone AI-64 support
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
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
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+
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
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
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()
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 org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuild
Bug#971696: linux-image-4.19.0-11-armmp: network hangs, oops in ath9k_htc after upgrade
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
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 c120
Bug#950508: debos: broken in Buster: libresolv.so.2: cannot open shared object file
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
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)
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
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
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
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
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")
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)
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
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")
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
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
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
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
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
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
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
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
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 (Bug#548880: fixed in debootstrap 1.0.85)
Dear Ansgar, dear Julien, Debian Bug Tracking System 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
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 (Separato
Bug#581039: tightvnc: Version 2.7.10 available by now; fixes key bindings for Mac OS X vnc server
Dear Ola, Ola Lundqvist 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
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
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] Options: -c, --count count of matching processes -d, --delimeter 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 match listed process group IDs -G, --group match real group IDs -n, --newest select most recently started -o, --oldest select least recently started -P, --parentmatch only childs of given parent -s, --sessionmatch session IDs -t, --terminal match by controlling terminal -u, --euidmatch by effective IDs -U, --uid match by real IDs -x, --exact match exectly with command name -F, --pidfile 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] Options: -, --signal signal to send (either number or name) -e, --echodisplay what is killed -f, --fulluse full process name to match -g, --pgroup match listed process group IDs -G, --group match real group IDs -n, --newest select most recently started -o, --oldest select least recently started -P, --parentmatch only childs of given parent -s, --sessionmatch session IDs -t, --terminal match by controlling terminal -u, --euidmatch by effective IDs -U, --uid match by real IDs -x, --exact match exectly with command name -F, --pidfile 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
Hello Dererk, Dererk 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: no longer happens with wheezy-backports version
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#775953: openntpd if-up.d hook can cause system boot to hang indefinitely
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 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_header.isra.15+0x50/0x154) [] (dump_header.isra.15) from [] (oom_kill_process+0xa0/0x374) [] (oom_kill_process) from [] (out_of_memory+0x2d8/0x320) [] (out_of_memory) from [] (moom_callback+0x20/0x28) [] (moom_callback) from [] (process_one_work+0x1c4/0x370) [] (process_one_work) from [] (worker_thread+0x2b8/0x440) [] (worker_thread) from [] (kthread+0xb8/0xcc) [] (kthread) from [] (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 0 openntpd [ 2253] 0 2253 1037 678 50 0 ntpd [ 2254] 103 2254 1004 633 5
Bug#766867: python-gevent: SSL support broken with current Python in Jessie (2.7.8)
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 "", line 1, in 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 "", line 1, in 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 pn python-gevent-doc pn python-openssl -- 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
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
Bug#738556: libaqbanking: Please package and backport 5.3.6beta
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=03&release=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
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 migemo 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: [Fwd: Undelivered Mail Returned to Sender]
Michel Dänzer writes: > Not very nice... > : 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 ) [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 "" [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, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi,
Bug#696176: No problem here
Filipus Klutiero 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#710697: python-webdav: no support for properties that are not plain XML-safe character strings (binary data, XML nodes)
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#710690: python-webdav: recursive only yields a subset of properties
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 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#710672: python-webdav: Unsolicited use of persistent connections causes HTTP/1.0 clients to hang
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: Journal listing Name by-id/ by-tags/ by-title/ === 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#707564: minicom: please show config or device name in status bar
Adam Lackorzynski 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 (ttyUSB, ttyS, serial/by-path/pci*usb*-port, ...). Also, is there a way to enable this through configuration, rather than setting up the environment (MINICOM)? Sascha pgpqUQJYkE3Hf.pgp Description: PGP signature
Bug#707564: minicom: please show config or device name in status bar
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#699205: [3.7.1->3.7.3 regression] ps, pgrep and pkill segfault
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 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 "", line 1, in 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') Serial(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#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)
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 "", line 1, in File "/usr/lib/python3/dist-packages/serial/rfc2217.py", line 90, in 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 "", line 1, in 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 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 -- 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#699914: python3-serial: TCP mode: data loss, timeout handling broken
Package: python3-serial Version: 2.5-2.1 Severity: normal Dear Maintainer, when used in TCP mode ('socket://:'), 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 "", line 1, in 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 -- 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
Jonathan Nieder 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#699218: procps: FTBFS with test suite error: testsuite/lib.test/fileutils_badfd.sh missing
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
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 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 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 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] [drm]
Bug#697624: minicom: can't use /dev/serial/by-path/*usb* device names
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
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 --- 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#696989: policykit-1: refuses all actions if user is member of a large number of groups
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#692009: bup: should Recommend python-pyxattr and python-pylibacl
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
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
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
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 ii ncmpcpp [mpd-client] 0.5.10-1 pn pulseaudio -- 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#683343: conkeror: extensions screen never finishes loading
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#683335: xpdf: can't disable reverse video on the command line anymore
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#642903: nodm: config failure still happens, makes dist-upgrade to Wheezy fail
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
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
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
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 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 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 > 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
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#662683: w3m: incorrect URLs for GET forms with a fragment identifier
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]: When submitting this form, w3m constructs the URL https://dev.laptop.org/ticket/11558#comment?replyto=description&reply=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=description&reply=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 migemo (no description available) ii mime-support 3.48-1 MIME files 'mime.types' & 'mailcap pn w3m-el (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#593815: bugs.debian.org inaccessible when IPv6 is enabled but not routed
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 (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 (no description available) pn squid-cgi (no description available) pn squidclient(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: 144020% 10080 refresh_patte
Bug#631807: segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc
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
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 cut&paste 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
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 c
Bug#648724: libgconf2-4: GCONF_DEFAULT_SOURCE_PATH support broken
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: [PATCH] Fix #648724
* 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 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 +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-b
Bug#648724: libgconf2-4: GCONF_DEFAULT_SOURCE_PATH support broken
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#647313: xdg-user-dirs-update uses incorrect config file paths
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
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 "", line 1, in 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
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 from jarabe import intro File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/intro/__init__.py", line 8, in 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 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
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 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 rc3
Bug#638723: Acknowledgement (network-manager: uses group "netdev" in D-Bus policy files, but does not create the group)
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
Bug#638723: network-manager: uses group "netdev" in D-Bus policy files, but does not create the group
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: dbus-1/system.d/wpa_supplicant.conf: 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#638718: debootstrap: please add loopback configuration to /etc/network/interfaces
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#638716: etckeeper: please ignore shadow backup files (/etc/{passwd, group, shadow, gshadow}-)
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#635289: [PATCH sugar-base] Add support for IPython 0.11+
From: Julian Taylor 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 Reviewed-by: Sascha Silbe --- 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#573518: mime-support: outdated for several years, Fedora git repo
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ä (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#634265: d-feet: GTK warnings on start-up
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
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
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
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, "" % (name,), "exec") File "", 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
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#620419: psi: causes 10Hz wake-ups even if not connected
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 (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#620345: libcap2-bin: setpcaps, sucap and execcap are missing
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-dev (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#619643: gnome-session: please provided updated package (at least 2.91.4)
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
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(no description available) pn python2.5-gobject (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: Acknowledgement ("etckeeper init" in existing VCS checkout chokes on file names containing special characters)
tag 617350 + patch thanks >From 39f0dab095eb1a72264920762e2d4d7617b1fd86 Mon Sep 17 00:00:00 2001 From: Sascha Silbe 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#617350: "etckeeper init" in existing VCS checkout chokes on file names containing special characters
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#612428: libtext-wikicreole-perl: links without description are converted to double on output
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 tags: === Begin Input === [[https://sascha.silbe.org/]] === End Input === === Begin Output === https://sascha.silbe.org/";>https://sascha.silbe.org";>https://sascha.silbe.org/ === 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
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 (Bug#605767)
Excerpts from Jonathan Nieder's message of Fri Dec 03 11:20:37 +0100 2010: > The subject seems to be ASCII. Ideas? Hmm, maybe the fact that it asked for the encoding (because the cover letter contained the recipients real name in the body) played a role. Shame on me for not posting the entire output which might have suggested this. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature