Processed: Re: hyperv-daemons: include debian specific versions of hv_get* scripts

2015-11-20 Thread Debian Bug Tracking System
Processing control commands: > tags -1 +patch Bug #796882 [hyperv-daemons] hyperv-daemons: include debian specific versions of hv_get* scripts Added tag(s) patch. -- 796882: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796882 Debian Bug Tracking System Contact ow...@bugs.debian.org with pro

Bug#796882: hyperv-daemons: include debian specific versions of hv_get* scripts

2015-11-20 Thread Hideki Yamane
control: tags -1 +patch Hi, On Tue, 25 Aug 2015 14:27:46 +0200 Christoph Martin wrote: > hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found > hv_kvp_daemon[941]: sh: 1: hv_get_dhcp_info: not found > hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found > hv_kvp_daemon[941]: sh: 1: hv_get_dhcp

Bug#805614: linux: PCAP filter "ether host" === "ether dst" when capture on a dummy interface

2015-11-20 Thread Zhang Jingqiang
在 Friday 20 November 2015 20:14:20,Ben Hutchings 写道: > Version: 4.2.6-1 > What about 4.2.6? I can't reproduce it with my laptop now. So there's must be something different with the pcap file I used. And maybe this "bug" is also there with 4.2.5. I found this bug with a pcap file captured from a Cen

Bug#805614: linux: PCAP filter "ether host" === "ether dst" when capture on a dummy interface

2015-11-20 Thread Ben Hutchings
Control: tag -1 moreinfo On Fri, 2015-11-20 at 16:38 +0800, Zhang Jingqiang wrote: > Source: linux > Version: 4.2.6-1 > Severity: normal > > Hello, > > Not found with 4.2.5 > Found with 4.3 What about 4.2.6? > Step to reproduce: > 1. ip link add name test0 mtu 65535 type dummy > 2. ip link set

Processed: Re: Bug#805614: linux: PCAP filter "ether host" === "ether dst" when capture on a dummy interface

2015-11-20 Thread Debian Bug Tracking System
Processing control commands: > tag -1 moreinfo Bug #805614 [src:linux] linux: PCAP filter "ether host" === "ether dst" when capture on a dummy interface Added tag(s) moreinfo. -- 805614: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805614 Debian Bug Tracking System Contact ow...@bugs.debian

Bug#805652: linux: please activate CONFIG_CC_STACKPROTECTOR_STRONG

2015-11-20 Thread Laurent Bonnaud
Package: linux Version: 4.2.6-1 Severity: normal Hi, current Linux kernels in Debian are compiled with CONFIG_CC_STACKPROTECTOR but not with CONFIG_CC_STACKPROTECTOR_STRONG: $ grep STACKPROT /boot/config-4.2.0-1-amd64 CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKP

linux_3.16.7-ckt20-1_multi.changes ACCEPTED into proposed-updates->stable-new

2015-11-20 Thread Debian FTP Masters
Mapping jessie to stable. Mapping stable to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 19 Nov 2015 15:14:30 + Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16.0-4 linux-libc-dev linux-headers-

Processing of linux_3.16.7-ckt20-1_multi.changes

2015-11-20 Thread Debian FTP Masters
linux_3.16.7-ckt20-1_multi.changes uploaded successfully to localhost along with the files: linux_3.16.7-ckt20-1.dsc linux_3.16.7-ckt20.orig.tar.xz linux_3.16.7-ckt20-1.debian.tar.xz linux-support-3.16.0-4_3.16.7-ckt20-1_all.deb linux-doc-3.16_3.16.7-ckt20-1_all.deb linux-manual-3.16_3.

Bug#793049:

2015-11-20 Thread Артём Банщиков
Here's dmesg output with radeon.dpm=1. Best regards, Artyom. dmesg_out Description: Binary data

Processed: Re: Bug#777231: libdrm-intel1: GPU HANG: ecode 0:0x87d3bffa, reason: Ring hung, action: reset

2015-11-20 Thread Debian Bug Tracking System
Processing control commands: > reassign -1 src:linux Bug #777231 [libdrm-intel1] libdrm-intel1: GPU HANG: ecode 0:0x87d3bffa, reason: Ring hung, action: reset Bug reassigned from package 'libdrm-intel1' to 'src:linux'. No longer marked as found in versions libdrm/2.4.58-2. Ignoring request to alt

Re: Bug#777231: libdrm-intel1: GPU HANG: ecode 0:0x87d3bffa, reason: Ring hung, action: reset

2015-11-20 Thread Andreas Boll
Control: reassign -1 src:linux Is this still an issue? Reassigning to src:linux since the commit in question is for the i915 kernel driver. Thanks, Andreas On Fri, Feb 06, 2015 at 05:40:37PM +0100, Bart Schuurmans wrote: > Package: libdrm-intel1 > Version: 2.4.58-2 > Severity: important > Tags:

Processed: Re: Bug#805579: nouveau: lockup with "[TTM] Buffer eviction failed"

2015-11-20 Thread Debian Bug Tracking System
Processing control commands: > reassign -1 src:linux Bug #805579 [libdrm-nouveau2] nouveau: lockup with "[TTM] Buffer eviction failed" Bug reassigned from package 'libdrm-nouveau2' to 'src:linux'. No longer marked as found in versions libdrm/2.4.65-3. Ignoring request to alter fixed versions of b

Re: Bug#805579: nouveau: lockup with "[TTM] Buffer eviction failed"

2015-11-20 Thread Andreas Boll
Control: reassign -1 src:linux This is likely a problem in the nouveau kernel driver or TTM. Reassigning to src:linux. Thanks, Andreas On Thu, Nov 19, 2015 at 01:46:36PM -0500, Eric Cooper wrote: > Package: libdrm-nouveau2 > Version: 2.4.65-3 > Severity: normal > > My graphics system occasional

Bug#793049: Regression: bad performance of hardware video decoding using mesa-vdpau-drivers

2015-11-20 Thread Andreas Boll
Could you boot with linux kernel parameter radeon.dpm=1 and attach dmesg output after playing some video? With the kernel parameter it logs more information about dynamic power management of the graphics card. Thanks, Andreas On Fri, Oct 23, 2015 at 03:05:22AM +0300, Артём Банщиков wrote: > Rece

Processed: affects 793049

2015-11-20 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > affects 793049 mesa-vdpau-drivers Bug #793049 [src:linux] Regression: bad performance of hardware video decoding using mesa-vdpau-drivers Added indication that 793049 affects mesa-vdpau-drivers > thanks Stopping processing here. Please contact m

Bug#805168: linux-image-4.2.0-1-amd64: sudden USB disconnect

2015-11-20 Thread Vincent Lefevre
On 2015-11-16 12:12:06 +0100, Vincent Lefevre wrote: > This has now happened on a different machine (see below). After looking at this problem more closely, this is a hardware bug with this machine (actually the screen and its USB hub). The fact that this bug got triggered just a few days ago is j

Bug#805614: linux: PCAP filter "ether host" === "ether dst" when capture on a dummy interface

2015-11-20 Thread Zhang Jingqiang
Source: linux Version: 4.2.6-1 Severity: normal Hello, Not found with 4.2.5 Found with 4.3 Step to reproduce: 1. ip link add name test0 mtu 65535 type dummy 2. ip link set test0 up 3. Capture traffic on test0 tcpdump -i test0 "ether host " 4. Use tcpreplay to replay some traffic tcpreplay