Bug#655376: kernel: pl2302 kernel driver bug

Hi Jonathan, I can reproduce the kernel trace trying to access two FTDI devices from the same (custom) application. I'm guessing the concurrent access to the respective USB driver is the actual problem though. This leaves the driver in a state where communication over the serial link is no

Bug#655376: kernel: pl2302 kernel driver bug

Hi again, FWIW, I've rebuilt/backported the 3.2.6-1 kernel from testing for/to stable (had to revert some changes in the python-based parts of the Debian kernel build system to make them work with python 2.6) and we can no longer reproduce the problem. Cheers, Rene -- To UNSUBSCRIBE, email

Bug#641654: nvidia-kernel-dkms: Nvidia kernel module fails compiling, duo GPL-only symbols used by a non-GPL module

Hi, the archlinux folks appear to have a patch for this: http://aur.archlinux.org/packages.php?ID=12132 http://aur.archlinux.org/packages/nv/nvidia-rt/nvidia-rt.tar.gz I'm afraid I currently lack the time to verify whether the patch is the correct solution. Have any of the maintainers tried

Bug#704664: Not a critical

Hi Anton, thanks for taking the time to triage this bug report. I am a bit puzzled by your response though. reportbug very clearly states that data loss warrants either 'grave' (which I selected) or 'critical' severity depending on whether it is recoverable or not. The release policy document

Bug#773121: iceweasel: H.264 playback broken again in Jessie?

Hi Braiam, On 12/14/2014 06:52 PM, Braiam Peguero wrote: My understanding is that gstreamer0.10-ffmpeg has been replaced by gstreamer1.0-libav in Jessie, so I've installed that instead. about:config shows that media.gstreamer.enabled is set to true. Unfortunately,

Bug#773121: iceweasel: H.264 playback broken again in Jessie?

forcemerge 737092 773121 thanks It turns out that the packages required to make GStreamer-based H.264 playback work in Jessie are gstreamer1.0-plugins-good and gstreamer1.0-libav. I believe iceweasel should Recommend both packages. Neither of them were installed by default. It also turns out

Bug#757914: iceweasel: please Suggests: gstreamer1.0-libav

Hi Martin-Éric, I also ran into this problem. I believe it is already covered by #737092 (which suggests adding gstreamer1.0-plugins-good and gstreamer1.0-libav to Recommends). If you agree, please consider closing this one as a duplicate. Cheers, Rene -- To UNSUBSCRIBE, email to

Bug#774914: firmware-linux-nonfree: Include the intel sst firmwares required for audio on Bay Trail

Hi Antonio, On 03/04/2015 04:17 PM, Antonio Ospite wrote: Sound is not working yet, TBH I sent this report to Debian after I managed to successfully load the drivers and upload the firmware without further tests, I guess I was just trusting what linux-firmware was shipping and thought I could

Bug#774914: firmware-linux-nonfree: Include the intel sst firmwares required for audio on Bay Trail

Hi, On Fri, 09 Jan 2015 02:34:54 +0100 Antonio Ospite a...@ao2.it wrote: please conside adding to firmware-linux-nonfree (or firmware-linux if possible) the sst firmware files required to have audio working on devices based on Bay Trail. On a Bay Trail tablet I get this error: [ 16.532488]

Bug#774914: firmware-linux-nonfree: Include the intel sst firmwares required for audio on Bay Trail

[My appologies if you received an earlier draft of this. I accidentally hit Send...] Hi, On Fri, 09 Jan 2015 02:34:54 +0100 Antonio Ospite a...@ao2.it wrote: On a Bay Trail tablet I get this error: [ 16.532488] sst-acpi 80860F28:00: Direct firmware load for

Bug#774914: firmware-linux-nonfree: Include the intel sst firmwares required for audio on Bay Trail

Hi, On 03/03/2015 10:53 PM, René Wagner wrote: I believe this is a manifestion of incorrect dynamic irq allocation causing all sorts of GPIO/SDIO-using hardware to break (see e.g. [3]). A patch by Thomas Gleixner is available at [4] which IIRC has already been applied upstream in later kernel

Bug#774914: firmware-linux-nonfree: Include the intel sst firmwares required for audio on Bay Trail

Hi Antonio, On 03/03/2015 10:23 PM, Antonio Ospite wrote: It is true that I am running a custom kernel, but the files I am talking about are shipped upstream by linux-firmware anyways. Of course this is not a urgent matter at all and it can wait after Jessie becomes stable but, eventually,

Bug#801525: systemd: incorrect boot timestamps in wtmp, last reports negative duration

Hi Micheal, On 11/09/2015 02:27 AM, Michael Biebl wrote: $ cat /etc/timezone Europe/Berlin $ tail -n1 /etc/adjtime LOCAL Most likely an issue of using LOCAL time, yeah. My suggestion would be to switch to UTC. I'm afraid I cannot arbitrarily change that setting. This is a dual-boot

Bug#801342: systemd: plain dm-crypt volumes not brought up on boot

Package: systemd Version: 215-17+deb8u2 Severity: normal [This was originally meant as a followup to #712439 which has been archived.] Dear maintainers, I upgraded a laptop from wheezy to jessie last weekend using dist-upgrade which installed systemd as the init system. Since the upgrade

Bug#801525: systemd: incorrect boot timestamps in wtmp, last reports negative duration

Package: systemd Version: 215-17+deb8u2 Severity: normal Dear maintainers, I'm not perfectly sure which package generates the "reboot" entries in wtmp. I believe in jessie to which I recently upgraded this is systemd, but please rassign this if that is not the case. Since the upgrade to jessie

Bug#801342: systemd: plain dm-crypt volumes not brought up on boot

Dear maintainers, it turns out that other users are affected by this, too. Over on debian-user@ Arno Schuring suggested [1] to add service files that override the default ones and call cryptdisks_start/stop as a workaround. I can confirm that with the following service files for swap and tmp my

Bug#766838: [pkg-ntp-maintainers] Bug#766838: ntpdate runs before network is up

Hi Kurt, thanks for your response! On 01/15/2017 06:25 PM, Kurt Roeckx wrote: I don't think we should have a while loop in there, or at least time out after some time. Note that this is within a background sub-shell and that the wait_for_file call above also contains a while loop. I do see

Bug#766838: ntpdate runs before network is up

tags 766838 + patch thanks Dear maintainers, my testing indicates that there are two distinct problems. First, for whatever reason, /etc/network/if-up.d/ntpdate is called with $IFACE = --all in addition to legitimate interfaces. This causes a race condition: If the $IFACE = --all instance

Bug#870529: squeezelite: please do not run as root

Package: squeezelite Version: 1.6.4-1+b1 Severity: important Tags: security Dear maintainer, the squeezelite Debian package currently runs squeezelite as root. Considering that squeezelite deals with arbitrary audio streams received from the network this is only looking for trouble and

Bug#248122: Please run wget as user nobody

Hi Thijs, I'm sorry to resurrect this from the dead. I came across this bug looking for something completely different... On Fri, 15 Dec 2006 14:05:00 +0100 (CET) "Thijs Kinkhorst" wrote: I've seen the discussion in this bug, and I wonder whether it makes sense to