Bug#578189: marked as done (please move common headers to /usr/src/linux-headers-`uname -r`)
Your message dated Sun, 8 Sep 2013 11:03:31 +0200 with message-id 20130908090331.gb28...@mail.waldi.eu.org and subject line Re: Bug#578189: please move common headers to /usr/src/linux-headers-`uname -r` has caused the Debian Bug report #578189, regarding please move common headers to /usr/src/linux-headers-`uname -r` 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.) -- 578189: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578189 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: linux-headers-2.6.32-4-common Version: 2.6.32-11 Debian breaks compatibility to upstream's kernel source tree by splitting the header file directory tree into 2 parts. This affects 3rd party software, e.g. the makefiles included in Nvidia's driver package. Do you think it would be possible to improve compatibility between Debian's kernel headers and the rest of the world? Many thanx Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvJ/F0ACgkQUTlbRTxpHjeiaQCeITg9AKMT/3wnIa18U0W72bs+ DycAn1Sh+ZJQOnUy3XI0GGGaceQBAwCI =xchA -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- On Sun, Jul 14, 2013 at 11:01:03AM +0200, Bastian Blank wrote: On Sun, Jul 14, 2013 at 10:17:33AM +0200, Harald Dunkel wrote: Any news about this? Nothing. What exactly do you want? No response. The setup is identical to an out-of-tree (O=) build of the kernel. If stuff fails with this setup, it is broken. Bastian -- I'm frequently appalled by the low regard you Earthmen have for life. -- Spock, The Galileo Seven, stardate 2822.3---End Message---
Re: [PATCH] udebs for armmp flavour
On Sat, 2013-09-07 at 19:05 +0100, Ben Hutchings wrote: On Sat, 2013-09-07 at 09:53 +0100, Ian Campbell wrote: On Thu, 2013-09-05 at 08:15 +0100, Ian Campbell wrote: I can't think of any reason not to enable CONFIG_PCI for armmp at this stage. Arnaud? It turns out the CONFIG_PCI is only available for ARCH_IXP4XX and ARCH_DOVE. Neither is enabled in armmp at the minute, although I think dove is v7 and could be in principal. In 3.11 ARCH_MVEBU selects MIGHT_HAVE_PCI, so PCI could be enabled in trunk without any additional platforms. I'll look into this, seems very doable. Would be best to merge sid into trunk first I think, which seems easiest if I wait until after 3.10.10-1 is uploaded. Time to swap in how to do merges in svn again! Ian. -- 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/1378634565.3057.32.ca...@dagon.hellion.org.uk
Bug#719127: Another instance of this crash
Version: 3.10.7-1 On Sun, Aug 18, 2013 at 01:21:02 +0200, Ben Hutchings wrote: This is from a Lenovo X1 Carbon, and also shows 'Thread overran stack, or stack corrupted': http://richardhartmann.de/img/DSC_0469.JPG (small version attached). Yet another one: http://people.debian.org/~jcristau/panic.jpg Cheers, Julien signature.asc Description: Digital signature
Uploading linux (3.10.11-1)
I intend to upload linux to unstable tomorrow. This will include many important fixes from stable updates 3.10.8-3.10.11 and fixes for some hardware support regressions on armel. It also adds udebs for armhf/armmp, as a step toward ARM multiplatform installer support. Unfortunately, it includes an ABI bump. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: Uploading linux (3.10.11-1)
Ok. When will we see this kernel in testing maybe? 2013/9/8 Ben Hutchings b...@decadent.org.uk: I intend to upload linux to unstable tomorrow. This will include many important fixes from stable updates 3.10.8-3.10.11 and fixes for some hardware support regressions on armel. It also adds udebs for armhf/armmp, as a step toward ARM multiplatform installer support. Unfortunately, it includes an ABI bump. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. -- 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/CAF-vDa8qMP=Pn0iZREgUFSbgodTuPfX+uViU=hpfhy9z+av...@mail.gmail.com
Re: Uploading linux (3.10.11-1)
On Sun, 2013-09-08 at 15:18 +0200, Carlo wrote: Ok. When will we see this kernel in testing maybe? https://wiki.debian.org/DebianTesting answers this question in general. Ben. 2013/9/8 Ben Hutchings b...@decadent.org.uk: I intend to upload linux to unstable tomorrow. This will include many important fixes from stable updates 3.10.8-3.10.11 and fixes for some hardware support regressions on armel. It also adds udebs for armhf/armmp, as a step toward ARM multiplatform installer support. Unfortunately, it includes an ABI bump. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Processed: tagging 714974
Processing commands for cont...@bugs.debian.org: tags 714974 + pending Bug #714974 [src:linux] nfs-kernel-server: Duplicate cookies reported - jfs partition, with samba Ignoring request to alter tags of bug #714974 to the same tags previously set thanks Stopping processing here. Please contact me if you need assistance. -- 714974: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714974 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.13786473293462.transcr...@bugs.debian.org
Bug#721191: linux: patch for parisc/hppa architecture
On Wed, Aug 28, 2013 at 11:53:58PM +0200, Helge Deller wrote: On 08/28/2013 11:35 PM, Bastian Blank wrote: Looks reasonable. But please send further changes to remove the non-smp kernels. I can do that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? We like to lower the image count. As long as there are no pressing needs, we like to only have one kernel variant. (Actually I had a similiar idea to use kernel alternatives on parisc too to avoid different UP/SMP kernels). Are there any UP machines since PA-8800? PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. How much space would be needed? Some Arm configs disable SELinux for example to save space. Bastian -- Emotions are alien to me. I'm a scientist. -- Spock, This Side of Paradise, stardate 3417.3 -- 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/20130908141948.ga29...@mail.waldi.eu.org
Bug#721191: linux: patch for parisc/hppa architecture
On Sun, 2013-09-08 at 16:19 +0200, Bastian Blank wrote: On Wed, Aug 28, 2013 at 11:53:58PM +0200, Helge Deller wrote: On 08/28/2013 11:35 PM, Bastian Blank wrote: Looks reasonable. But please send further changes to remove the non-smp kernels. I can do that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? We like to lower the image count. As long as there are no pressing needs, we like to only have one kernel variant. (Actually I had a similiar idea to use kernel alternatives on parisc too to avoid different UP/SMP kernels). Are there any UP machines since PA-8800? PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. How much space would be needed? Some Arm configs disable SELinux for example to save space. Right, debian/config/armel/config-reduced may be a useful list of things that could potentially be disabled. It's also worth checking modules.builtin for things that could possibly be modularised. (Not everything listed there will actually work properly as a module though.) Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#721191: linux: patch for parisc/hppa architecture
On Sun, 2013-09-08 at 15:36 +0100, Ben Hutchings wrote: On Sun, 2013-09-08 at 16:19 +0200, Bastian Blank wrote: On Wed, Aug 28, 2013 at 11:53:58PM +0200, Helge Deller wrote: On 08/28/2013 11:35 PM, Bastian Blank wrote: Looks reasonable. But please send further changes to remove the non-smp kernels. I can do that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? We like to lower the image count. As long as there are no pressing needs, we like to only have one kernel variant. (Actually I had a similiar idea to use kernel alternatives on parisc too to avoid different UP/SMP kernels). Are there any UP machines since PA-8800? PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. How much space would be needed? Some Arm configs disable SELinux for example to save space. Right, debian/config/armel/config-reduced may be a useful list of things that could potentially be disabled. It's also worth checking modules.builtin for things that could possibly be modularised. (Not everything listed there will actually work properly as a module though.) For example, CONFIG_IPV6=m is an easy way to reduce the kernel image size. (We don't do this in general because IPv6 is enabled by default and so will almost always be loaded, and modular code is slightly less efficient.) Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
The effect of the kernel version on am-utils
Hi, Just FYI, as you might be interested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722145 Kaplan
Bug#721191: linux: patch for parisc/hppa architecture
On Wed, 2013-08-28 at 23:22 +0200, Helge Deller wrote: [...] diff -up ./debian/config/hppa/config.parisc64-smp.org ./debian/config/hppa/config.parisc64-smp --- ./debian/config/hppa/config.parisc64-smp.org2013-05-04 04:44:45.0 +0200 +++ ./debian/config/hppa/config.parisc64-smp2013-08-26 22:50:12.0 +0200 @@ -8,6 +8,7 @@ CONFIG_PA8X00=y CONFIG_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=8 +CONFIG_MLONGCALLS=y ## ## file: mm/Kconfig @@ -16,3 +17,24 @@ CONFIG_NR_CPUS=8 # CONFIG_FLATMEM_MANUAL is not set ## end choice +# For the IDE CDROM in C8000 workstation +CONFIG_IDE=m +CONFIG_BLK_DEV_SIIMAGE=m Why not CONFIG_PATA_SIL680 instead? +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y Why should this be built-in? +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m This is redundant with the top-level config. [...] +CONFIG_DRM=y Why should this be built-in? +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y These are automatic configuration symbols; you can't set them. +CONFIG_BACKLIGHT_LCD_SUPPORT=y [...] This is redundant with the top-level config. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#721191: linux: patch for parisc/hppa architecture
On Sun, 2013-09-08 at 17:30 +0100, Ben Hutchings wrote: [...] +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y Why should this be built-in? Never mind, it doesn't select code... +CONFIG_FUSION_SPI=m [...] but both the FUSION and FUSION_SPI symbol settings are redundant with the top-level configuration. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Bug#721191: linux: patch for parisc/hppa architecture
On 09/08/2013 04:19 PM, Bastian Blank wrote: On Wed, Aug 28, 2013 at 11:53:58PM +0200, Helge Deller wrote: On 08/28/2013 11:35 PM, Bastian Blank wrote: Looks reasonable. But please send further changes to remove the non-smp kernels. I can do that. Do you have some background on this request for me? Is it policy that you only want to gave SMP-kernels? We like to lower the image count. As long as there are no pressing needs, we like to only have one kernel variant. Ok. Are there any UP machines since PA-8800? After the request to reduce the kernels to e.g. SMP-only, my thought was to provide only 32bit-UP and 64bit SMP kernels. To be sure I asked on the parisc mailing list. The whole thread can be read here: http://comments.gmane.org/gmane.linux.ports.parisc/5283 Summary: - yes, there exists quite some 32bit-only parisc SMP machines. - the J5600 is SMP capable in both 32bit and 64bit mode, but currently it only boots Linux with a 32bit SMP kernel and crashes with a 64bit SMP kernel. We are working on resolving this... - 64bit SMP kernel boots fine on a 64bit UP machine. So, theretically we can drop the 64bit UP kernel. Only problem: performance loss due to unnecessary spinlock cost. So, right now, the best option would be to only drop the 64bit UP kernel. PPPS: CONFIG_MLONGCALLS=y is necessary since the built kernel otherwise gets too big so that jumps can't be reached. Are there drawbacks? Yes, it might be a little bit slower since the jumps now have one CPU instruction more. But there is no other way to solve it unless we drop some unneccessary kernel options for parisc. How much space would be needed? Some Arm configs disable SELinux for example to save space. Not much. I think it makes sense to look through the complete configs again. Maybe there are things which we can disable for parisc... Helge -- 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/522cdd93.7080...@gmx.de
Bug#721191: linux: patch for parisc/hppa architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/2013 06:30 PM, Ben Hutchings wrote: On Wed, 2013-08-28 at 23:22 +0200, Helge Deller wrote: +# For the IDE CDROM in C8000 workstation +CONFIG_IDE=m +CONFIG_BLK_DEV_SIIMAGE=m Why not CONFIG_PATA_SIL680 instead? I will test if this works too. +# For the built-in SCSI controller in C8000 workstation +CONFIG_FUSION=y Why should this be built-in? it just enables that you can select FUSION_SPI +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m This is redundant with the top-level config. It hasn't been built before, so maybe the dependeny to top-level config didn't worked? Will check. +CONFIG_DRM=y Why should this be built-in? On the C8000 an ATI FireGL is the only built-in GFX card and it's only supported by the radeon DRM driver. So, if the driver isn't built-in, you won't be able to see the debian installer... +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_TTM=y These are automatic configuration symbols; you can't set them. Ok, might be a mistake. +CONFIG_BACKLIGHT_LCD_SUPPORT=y [...] This is redundant with the top-level config. Again, the top-level config didn't seemed to have been pulled. Will check too. Helge -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSLOFwAAoJEIfJwVG1Hjhk8pUH/2ubsd35e2HSAEMY9NvO+8Zm X5EtbbNavUECOidbTKb4y/NuApqfi2ggg1lEWE8wdD+RVkwMdHU47shBcKU29Rws /jki5FxLdHfqhr63ZDtwB/6NAF8ntwtt9+jsMY+DCn/i1nAZddmqnwDOzbF4x1fS T89POQaBOzJGcGk4Azyep75VaFqljxaudAPS15Aha8poZ17fbDZYJOsIWR2j+f+P 1ttybdKByVKGQXfbWvkAtgP7+nj94XXIuCh3TY6WEjzx5WyFwhfh1hOFwUEB2pLQ JLiqQC0tGkfVwdkaRZpxSylBnCh9J1SqSHCr//ywnaP4OBlCRWRm+xie4norhqk= =Gc0w -END PGP SIGNATURE- -- 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/522ce170.3090...@gmx.de
Bug#721191: linux: patch for parisc/hppa architecture
On Sun, 2013-09-08 at 22:43 +0200, Helge Deller wrote: On 09/08/2013 06:30 PM, Ben Hutchings wrote: On Wed, 2013-08-28 at 23:22 +0200, Helge Deller wrote: [...] +CONFIG_FUSION_SPI=m + +# Built-in NIC in C8000 workstation +CONFIG_E1000=m This is redundant with the top-level config. It hasn't been built before, so maybe the dependeny to top-level config didn't worked? Will check. I don't know which version you're looking at, but it is enabled by the current configuration. +CONFIG_DRM=y Why should this be built-in? On the C8000 an ATI FireGL is the only built-in GFX card and it's only supported by the radeon DRM driver. So, if the driver isn't built-in, you won't be able to see the debian installer... [...] The driver won't be built-in, as you're setting CONFIG_DRM_RADEON=m. And it doesn't need to be built-in. It just needs to be in one of the module packages that's included in the installer initramfs. I think you'll need to create a new udeb for DRM drivers and then add this to the package lists for hppa images in the d-i repository. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
