Processed: fixed 649294 in 3.1.1-1
Processing commands for cont...@bugs.debian.org: fixed 649294 3.1.1-1 Bug #649294 [linux-2.6] linux-2.6: Duplicate battery after suspend/resume There is no source info for the package 'linux-2.6' at version '3.1.1-1' with architecture '' Unable to make a source version for version '3.1.1-1' Bug Marked as fixed in versions 3.1.1-1. thanks Stopping processing here. Please contact me if you need assistance. -- 649294: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649294 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13227420309876.transcr...@bugs.debian.org
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
Dmitry Smirnov wrote: It is probably obvious to everyone that MEMTEST is harmless. Then why not enable it without painful discussions? Having a feature enabled in the Debian kernel (at release time) is a promise to continue supporting it for the period in which that release is supported. It seems perfectly sane to me that the kernel maintainers might apply their own taste in deciding whether it is worth doing so. (Kernel image size is also a consideration, though probably not a major worry in this particular example.) [...] If just few requests for a feature is not enough to convince that we need it, how many people should ask, exactly, in order to make the change? One reliable contributor. Or just describe a use case that makes it a compelling addition to Debian. (Since there is already a memtest86+ package, replacing memtest86+ isn't one.) Thanks for your interest, and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201120903.ga10...@elie.hsd1.il.comcast.net
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
On Thu, Dec 01, 2011 at 06:09:03AM -0600, Jonathan Nieder wrote: Dmitry Smirnov wrote: It is probably obvious to everyone that MEMTEST is harmless. Then why not enable it without painful discussions? Having a feature enabled in the Debian kernel (at release time) is a promise to continue supporting it for the period in which that release is supported. It seems perfectly sane to me that the kernel maintainers might apply their own taste in deciding whether it is worth doing so. (Kernel image size is also a consideration, though probably not a major worry in this particular example.) [...] If just few requests for a feature is not enough to convince that we need it, how many people should ask, exactly, in order to make the change? One reliable contributor. Or just describe a use case that makes it a compelling addition to Debian. (Since there is already a memtest86+ package, replacing memtest86+ isn't one.) If I understood correctly the usecase is a bit different from memtest86+. With the latter you have a test case to determine if your RAM is bad (or not). With the memtest kernel option memory is tested before it's given out to kmalloc. So it is able in some cases to just not give out bad parts of RAM allowing to use RAM that is a bit broken. Having said that I don't know if it's sensible to add to Debian as I didn't test runtime and binary size overhead. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201130912.gk26...@pengutronix.de
Bug#633526: vserver kernel breaks ssh public_key authentication on NFS
tags 633526 + patch retitle 633526 NFS client uid/gid cache broken on VServer kernels thanks Herbert Poetzl wrote: we now understand the problem, and it was fixed for 3.0.4 with the following patch: http://vserver.13thfloor.at/ExperimentalT/delta-nfs-fix02.diff I can confirm that this patch is fixing the issue. I have tested the patch on top of linux-2.6 2.6.32-37 on a production server and we no longer experience the NFS uid/gid issue. The issue can easily be tested by doing ls -l $file on a NFS mount. The values will show up correctly. After cat $file /dev/null; ls -l $file it will suddenly show wrong uid/gid values of: 4294967294/4294967294 (-2/-2) Waiting for about 20 seconds ls -l $file will show again correct values. So the client cached values are clearly the problem. I strongly recommend to include the patch into the next stable point release as this is major NFS regression from Debian Lenny. Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developermee...@meebey.net http://www.meebey.net/ PEAR Developermee...@php.net http://pear.php.net/ Debian Developer mee...@debian.org http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed78693.1050...@debian.org
Processed: Re: vserver kernel breaks ssh public_key authentication on NFS
Processing commands for cont...@bugs.debian.org: tags 633526 + patch Bug #633526 [linux-2.6] vserver kernel breaks ssh public_key authentication on NFS Added tag(s) patch. retitle 633526 NFS client uid/gid cache broken on VServer kernels Bug #633526 [linux-2.6] vserver kernel breaks ssh public_key authentication on NFS Changed Bug title to 'NFS client uid/gid cache broken on VServer kernels' from 'vserver kernel breaks ssh public_key authentication on NFS' thanks Stopping processing here. Please contact me if you need assistance. -- 633526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633526 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.132274811820203.transcr...@bugs.debian.org
Bug#650652: linux-image-2.6.32-5-amd64: Kernel IPsec code rejects 288-bit keys for AES-CTR as being too long
Package: linux-2.6 Version: 2.6.32-38 Severity: important Tags: patch The kernel incorrectly rejects 288-bit keys for AES-CTR (256 + 32 for nonce) as being too long. This is a rather major deficiency, as it prevents using AES-256-CTR at all for IPsec. This has been fixed as of the 3.0.3-stable kernel release upstream. Here is the patch: https://lkml.org/lkml/2011/8/14/188 -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-38) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Oct 3 03:59:20 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=f6d920b5-0a98-418c-bb19-1657b61fc7e5 ro quiet ** Not tainted ** Kernel log: [1190996.380519] device eth1 entered promiscuous mode [1190998.570627] device eth1 left promiscuous mode [1191001.504018] device eth1 entered promiscuous mode [1191003.256015] device eth1 left promiscuous mode [1191013.064018] device eth1 entered promiscuous mode [1191014.264016] device eth1 left promiscuous mode [1191016.692018] device eth1 entered promiscuous mode [1191020.424015] device eth1 left promiscuous mode [1191028.900018] device eth1 entered promiscuous mode [1191028.932016] device eth1 left promiscuous mode [1191033.364018] device eth1 entered promiscuous mode [1191033.396015] device eth1 left promiscuous mode [1191039.504018] device eth1 entered promiscuous mode [1191040.852014] device eth1 left promiscuous mode ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: GA-MA770-DS3P product_version: chassis_vendor: Gigabyte Technology Co., Ltd. chassis_version: bios_vendor: Award Software International, Inc. bios_version: F5 board_vendor: Gigabyte Technology Co., Ltd. board_name: GA-MA770-DS3P board_version: x.x ** Loaded modules: Module Size Used by xt_owner1063 1 ipt_LOG 4518 2 xt_state1303 4 xt_tcpudp 2319 15 xt_mark 917 2 iptable_mangle 2817 1 xt_MARK 917 1 ipt_MASQUERADE 1554 1 iptable_nat 4299 1 nf_nat 13388 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 9833 7 iptable_nat,nf_nat nf_defrag_ipv4 1139 1 nf_conntrack_ipv4 ip6table_filter 2384 1 ip6_tables 15107 1 ip6table_filter iptable_filter 2258 1 ip_tables 13915 3 iptable_mangle,iptable_nat,iptable_filter x_tables 12845 10 xt_owner,ipt_LOG,xt_state,xt_tcpudp,xt_mark,xt_MARK,ipt_MASQUERADE,iptable_nat,ip6_tables,ip_tables nf_conntrack_irc3347 0 nf_conntrack_ftp5537 0 nf_conntrack 46535 7 xt_state,ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_irc,nf_conntrack_ftp authenc 5674 2 esp44805 2 xfrm4_mode_tunnel 1696 4 deflate 1767 0 zlib_deflate 17746 1 deflate ctr 3363 0 twofish 6025 0 twofish_common 13472 1 twofish camellia 17463 0 serpent16791 0 blowfish7944 0 cast5 16349 0 des_generic15475 0 cbc 2539 2 aes_x86_64 7340 4 aes_generic25714 1 aes_x86_64 xcbc2325 0 rmd160 7104 0 sha256_generic 8692 0 sha1_generic1759 2 hmac2593 4 crypto_null 2492 0 af_key 25421 0 loop 11799 0 firewire_sbp2 11514 0 arc41274 2 ath5k 122959 0 ath13386 1 ath5k radeon574908 0 mac80211 178876 1 ath5k ttm40162 1 radeon cfg80211 130170 3 ath5k,ath,mac80211 rfkill 13044 1 cfg80211 compat 12014 3 ath5k,mac80211,cfg80211 drm_kms_helper 20369 1 radeon pcmcia_core24118 1 compat led_class 2433 2 ath5k,compat drm 142279 3 radeon,ttm,drm_kms_helper i2c_algo_bit4225 1 radeon snd_hda_codec_realtek 235618 1 edac_core 29261 0 edac_mce_amd6433 0 i2c_piix4 8328 0 i2c_core 15819 5 radeon,drm_kms_helper,drm,i2c_algo_bit,i2c_piix4 snd_hda_intel 20035 0 snd_hda_codec 54244 2 snd_hda_codec_realtek,snd_hda_intel snd_hwdep 5380 1 snd_hda_codec k8temp 3283 0 snd_pcm60487 2 snd_hda_intel,snd_hda_codec snd_timer 15598 1 snd_pcm snd46526 6 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer soundcore 4598 1 snd snd_page_alloc 6249 2 snd_hda_intel,snd_pcm pcspkr 1699 0 evdev 7352 3 processor 29935 0 wmi
Re: Moving default module/package lists out of kernel-wedge
Ben Hutchings wrote: It's fairly obvious that the default module lists for Linux should be moved to the linux-2.6 source package. We can do that right now and use relative paths to include them in the per-architecture/flavour lists. However the #include foo-modules syntax would then be unused. It seems like it would be better to allow overriding the directory that is searched. Yes, or search in both places. Also, kernel-wedge has a single package template shared between Linux and kFreeBSD. Is this necessary? (I don't know how the installer selects module packages to use.) Should the Linux package template also be moved to the linux-2.6 source package? It does so based on Priority, plus some special cases. There would not be much duplication involved in copying the package-list into linux-2.6, since kfreebsd only uses 8 entries from that so far. And beyond the odd module udeb name that might be hardcoded into d-i and needs to be the same across linux and kfreebsd, there seems to be only benefit in untangling the two kernels' package-list files. I was considering changing kernel-wedge to support a KW_DEFCONFIG_DIR variable, similar to the KW_CONFIG_DIR variable, that would affect where all of these files are looked for. The (untested) change is pretty small: diff --git a/README b/README index 6bf5b87..df52199 100644 --- a/README +++ b/README @@ -84,7 +84,12 @@ Suppose we want a different set of modules in the speakup flavored kernel. Then create a modules/arch-flavor/nic-modules instead, it will be used by preference. One udeb will be created for each modules list file, containing the listed modules. The names of the files should match the -names of the various modules listed in /usr/share/kernel-wedge/package-list. +names of the various modules listed in the package-list file in the +default-configuration directory. + +The default-configuration directory is either specified by the +environment variable $KW_DEFCONFIG_DIR or else defaults to +/usr/share/kernel-wedge. I don't see why this is necessary. If /usr/share/kernel-wedge/package-list does not exist or is empty, kernel-wedge should still use the package-list file from the linux-2.6 source package, and that's the right place to list all the module udebs. -- see shy jo signature.asc Description: Digital signature
Bug#649294: marked as done (linux-2.6: Duplicate battery after suspend/resume)
Your message dated Thu, 1 Dec 2011 19:22:58 +0100 with message-id 20111201182258.gn3...@radis.cristau.org and subject line Re: Bug#649294: linux-2.6: Duplicate battery after suspend/resume has caused the Debian Bug report #649294, regarding linux-2.6: Duplicate battery after suspend/resume to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 649294: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649294 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Severity: normal Dear Maintainer, After suspend/resume, the kernel seems to think I have 2 batteries, one empty and my real battery. Of course I have only one battery on this laptop (DELL Latitude E6400). It works fine after a reboot: acpi reports only one battery. Here is the output of acpi -i -s before suspend: Battery 0: Full, 100% Battery 0: design capacity 5200 mAh, last full capacity 4464 mAh = 85% Here is the output of acpi -i -s after suspend/resume: Battery 0: slot empty Battery 1: Full, 100% Battery 1: design capacity 5200 mAh, last full capacity 4464 mAh = 85% Do not hesitate to ask for more logs or output, I'll be happy to provide any information necessary. Regards, Bertrand -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Version: 3.1.1-1 On Wed, Nov 30, 2011 at 23:12:16 +0100, Bertrand Marc wrote: I can confirm it is fixed with 3.1.1-1. Closing. Cheers, Julien ---End Message---
Bug#650652: Patch
commit 4203223a1aed862b4445fdcd260d6139603a51d9
Author: Tushar Gohad tgo...@mvista.com
Date: Thu Jul 28 10:36:20 2011 +
xfrm: Fix key lengths for rfc3686(ctr(aes))
Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
The number of bits in key spec is the key length (128/256)
plus 32 bits of nonce.
This change takes care of the Invalid key length errors
reported by setkey when specifying 288 bit keys for aes-ctr.
Signed-off-by: Tushar Gohad tgo...@mvista.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 58064d9..791ab2e 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -462,8 +462,8 @@ static struct xfrm_algo_desc ealg_list[] = {
.desc = {
.sadb_alg_id = SADB_X_EALG_AESCTR,
.sadb_alg_ivlen = 8,
- .sadb_alg_minbits = 128,
- .sadb_alg_maxbits = 256
+ .sadb_alg_minbits = 160,
+ .sadb_alg_maxbits = 288
}
},
};
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ed7cd94.3040...@smu.edu
Bug#594676: [giggzounets...@googlemail.com: Re: Files Download Pb with the atl1c module and my ReadyNAS]
Forwarding with permission. ---BeginMessage--- Le jeudi 24 novembre 2011 à 00:42 -0600, Jonathan Nieder a écrit : Hi Guillaume, Ben Hutchings wrote: On Sat, 2010-08-28 at 11:23 +0200, giggz wrote: I have an eeepc 1201n with debian stable lenny+backports. So I'm using the kernel 2.6.32-bpo.5-amd64. The Ethernet controller is driven by the module atl1c. I'm using firestarter as firewall. I have a file transfer problem between my NAS (readyNAS Duo from Netgear); at first the symptoms: - with firestarter installed (stopped or in use) I can connect my eeepc to my NAS through FTP, CIFS or NFS. For example I can list or go through my shares. But when I'm trying to download a file it is so slow. I get 12Ko in 10minutes... [...] Does this firewall block ICMP? Ping. Could you answer this? It would also be interesting to hear what kernel you use now, how it behaves, and whether you've learned anything else new in the meantime. Thanks for an interesting report. Hi, On my LAN my routeur always forces the mtu of my laptops to 1492. I have a laptop with debian sid and an eeepc with debian stable lenny. On this LAN I have a NAS (readyNAS duo of Netgear). With my laptop with sid I don't have any problem at all to upload/download file from my NAS with ftp/cifs/NFS and with firestarter installed. But with my eeepc (with ethernet atl1c) I get one: - with firestarter installed - with an mtu set to 1492 I can't download file from my NAS through ftp/cifs/NFS. But I can upload without problem. So I have a little bit researched on the problem: - with mtu of 1500 on my eeepc the problem disappears. even firestarter is installed. - the net.ipv4.tcp_timestamps value ist set to 0 by firestarter. When I force it to 1 it works out of the box even with an mtu of 1492. Regards, giggzounet ---End Message---
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
Uwe Kleine-König wrote: With the latter you have a test case to determine if your RAM is bad (or not). With the memtest kernel option memory is tested before it's given out to kmalloc. So it is able in some cases to just not give out bad parts of RAM allowing to use RAM that is a bit broken. That would be fun. Alas, the code just seems to run a memory test at boot time (not at kmalloc-time) and reserve areas that do not pass so they don't get used during the corresponding run of the kernel. Having said that I don't know if it's sensible to add to Debian as I didn't test runtime and binary size overhead. No opinion on that from me. It does seem a shame that many kinds of faults would be likely to be missed: http://www.memtest86.com/tech.html#philo That seems like the bigger potential cost. When someone runs into corruption that the memtest option did not catch, what can we say to such a person? (It would be easier if there were a manpage for kernel parameters and a culture such that everyone read it before enabling them.) I should have just been quiet. :) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201205902.gd4...@elie.hsd1.il.comcast.net
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
On Thursday 01 December 2011 23:09:03 Jonathan Nieder wrote: (Kernel image size is also a consideration, though probably not a major worry in this particular example.) Indeed. In this case we're talking about 130 lines of source code (3 KB), see arch/x86/mm/memtest.c If just few requests for a feature is not enough to convince that we need it, how many people should ask, exactly, in order to make the change? One reliable contributor. Or just describe a use case that makes it a compelling addition to Debian. (Since there is already a memtest86+ package, replacing memtest86+ isn't one.) We have three: Romain Francoise rfranco...@debian.org, who reported (closed) 556365, me and intrigeri intrig...@boum.org. I guess all three of us should be working on our reliability... :) Thanks for your interest, and hope that helps, Jonathan Thank you.
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
On Friday 02 December 2011 07:59:02 Jonathan Nieder wrote: Having said that I don't know if it's sensible to add to Debian as I didn't test runtime and binary size overhead. Binary size overhead is really negligible. No opinion on that from me. It does seem a shame that many kinds of faults would be likely to be missed: Let's not fall into discussion about the quality of this feature. It doesn't matter. It doesn't have to be perfect to be included. Personally I think it is good enough for inclusion as is, because it do catch some errors. ECC is not perfect either, and MEMTEST appears to be better or at least as useful as ECC. That seems like the bigger potential cost. When someone runs into corruption that the memtest option did not catch, what can we say to such a person? (It would be easier if there were a manpage for kernel parameters and a culture such that everyone read it before enabling them.) Such person, if capable of activating MEMTEST with boot-time argument to kernel, may have already read something about it. We can't take responsibility for that person's decisions (or expectations). Use case for MEMTEST is not to catch all errors but to minimize damage. ECC doesn't catch all errors but it is better to have it to avoid massive data corruption due to bad RAM. Vast majority of computers out there do not have any form of ECC and we're not allowing users to have any protection against RAM errors because someone have unexplained reluctance regarding MEMTEST inclusion. Is my test case not good enough? I've seen faulty RAM on servers running 24/7 for years when fault was discovered only after hardware upgrade. Data corruption was probably happening for a very long time and impact is very difficult to understand. MEMTEST can be helpful for this scenario and it can be helpful for notebooks and desktop PCs where people work with sensitive data and do not routinely check their memory on weekly/monthly basis. (who does?) I should have just been quiet. :) No worries, you're thoughts are welcome. :) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112020953.03562.only...@member.fsf.org
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #600846 (http://bugs.debian.org/600846) # Bug title: linux-image-2.6.32-5-amd64: Suspend-To-RAM not works for some months, Suspend-To-Disk not works since last update. # * https://bugs.freedesktop.org/show_bug.cgi?id=43278 # * remote status changed: (?) - NEW usertags 600846 + status-NEW thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201231548.26971.24730.btsl...@busoni.debian.org
Processed: Re: linux-image-3.1.0-1-686-pae: Invalid opcode running df on seed Btrfs filesystem
Processing commands for cont...@bugs.debian.org: found 649847 linux-2.6/3.1.1-1 Bug #649847 [linux-2.6] linux-image-3.1.0-1-686-pae: Invalid opcode running df on seed Btrfs filesystem Bug Marked as found in versions linux-2.6/3.1.1-1. # Regression introduced by 6d07bcec969a (btrfs: fix wrong free space # information of btrfs, 2011-01-05). found 649847 linux-2.6/2.6.38~rc6-1~experimental.1 Bug #649847 [linux-2.6] linux-image-3.1.0-1-686-pae: Invalid opcode running df on seed Btrfs filesystem Bug Marked as found in versions linux-2.6/2.6.38~rc6-1~experimental.1. # Fixed in mainline by b772a86ea6d9 (Btrfs: fix oops when calling # statfs on readonly device, 2011-11-28). tags 649847 + fixed-upstream Bug #649847 [linux-2.6] linux-image-3.1.0-1-686-pae: Invalid opcode running df on seed Btrfs filesystem Added tag(s) fixed-upstream. End of message, stopping processing here. Please contact me if you need assistance. -- 649847: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649847 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13227834127708.transcr...@bugs.debian.org
