Bug#812540: Add ARCH_HISI for Lemaker HiKey support
Package: linux Version: 4.3.3-7 Severity: wishlist Tags: d-i Dear kernel maintainers, while trying to get a d-i booted on a Lemaker HiKey, tbm pointed out that ARCH_HISI is not (yet) activated on linux. Please enable it so we can add HiKey support to Debian. TIA! Best, Kilian
Re: Backports of linux-2.6 and dependencies
Hey Bastian, To implement this solution, we need help from both the backport and the kernel team: we need autobuilders and we need someone for every arch to verify and approve the packages for the archive. as I was on the kernel-archive team since the first minute, sure you can count me in as well. ;) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
zaptel module compilation
Hi Kernel team, I'm trying to resolve #343521 and I found that the linux-headers ship with a file .extraversion instead of providing EXTRAVERSION in the according Makefile. Now, my question is which part of the chain should be fixed accordingly. Right now zaptel-source uses KVERS as it's being provided by module-assistant. Module-assistant itself gathers its knowledge from the kernel Makefile. Thus, for e.g. a linux-2.6.14-2-686-smp the KVERS is linux-2.6.14 as correctly found in the bug report. So, could please maybe someone point me to whether sourcing the .extraversion is the sane approach or where I am to redirect this? Thanks for your help. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#270297: no SysRq key option available
Package: kernel-image-2.6.8-1-686 Version: 2.6.8-2 Severity: normal Hi, for i have had some hard time with the kernel-image-2.6.8-1-686 (see http://lists.debian.org/debian-kernel/2004/09/msg00127.html for details), i'd have preferred to at least have the SysRq key to reboot the locked up machine. If you think it cannot be included for security reasons, please set it disabled, but have the kernel at least know the option. That way enabling it through proc would be possible instead of now always having to shut down the box hard (i.e. unplug the power cord). Before anyone wonders: no, my tower case doesn't have a reset switch at all, only the on-off-key. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages kernel-image-2.6.8-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.74 tools to create initrd image for p ii module-init-tools 3.1-pre5-6 tools for managing Linux kernel mo -- no debconf information
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Hi Sven, /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-1.bz2 /usr/src/kernel-patches/all/2.6.7/debian/patch-2.6.7-2.bz2 For this kind of stuff, it is better to work on the source package of kernel-source. try apt-get source kernel-source-2.6.7 and experiment with it. my point is: when installing a system and thus adding a new kernel, why would i want to install a kernel with patches and settings i don't know? So all i ask for is a policy-refence for the internal kernel-package policy about: - which patches are in (more than just the vanilla kernel) - which hardware is supported - which features are compiled in (like networking etc.) If that can be put on some web page for me to look at, that'd just be terrific. I *DO* understand that putting that into the description is not what you guys want, so ok. Even a pointer to the SVN repository of kernel-source would be ok, if that does list what i search for. This all shall take place *before* moving some 300 MB (binary images, sources, vanilla sources, crawling patch websites etc.) around the net until finally finding the kernel-image i really do want to install (and reading sources and docs and searching bits and pieces in README and TODO files for like 3-4h until i find all info i need to know what went into kernel-source). Maybe with 2.6 there's few patches needed. Maybe however you use a -mm kernel or one of the other near-vanilla-upstream for they have an advantage you think is making them superior. Now all that i want to be able to is inform myself, which piece of software am i getting as kernel-image. Unfortunatelly KERNEL is defined in a little fuzzy way around the Linux comunity (like the RH NPTL-enabled kernels are also a distro-kernel). I hope I could make my point clear. It's not about that I question you do a great job with the kernel-images. Just I want to know if the additional patches are for: - just making it compile - adding features that weren't in (like IPsec for 2.4, Vserver, UML with SKAS patch, O(1) for 2.4 kernels etc.) - reducing warnings that are kind of annoying - making install target the Debian-way For some reason I do believe that it's somewhere between #1 and #2. So now which patches went in that are not just eyecandy, but real new features? Is that asking too much, to be allowed to know what you get before you apt-get install kernel-image-2.6.7-1-k7reboot and find out the hard way? -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Package: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated Severity: normal The description from kernel-patch-debian and kernel-image does not list which patches are contained in the Debian diff. That way it's pretty hard to evaluate which benefits are already provided by using the debian kernel package compared to going vanilla (and patching in what you need apart from vanilla). Moreover i think it'd make more sense making kernel-patch-debian a meta-pacakge depending on all diffs it contains. That way reverting one patch out of the Debian proposed patchset will be much easier. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-vs1.9.1.10 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Hi Christoph, Am Mi, den 07.07.2004 schrieb Christoph Hellwig um 13:48: On Wed, Jul 07, 2004 at 12:29:44PM +0200, Kilian Krause wrote: The description from kernel-patch-debian and kernel-image does not list which patches are contained in the Debian diff. That way it's pretty hard to evaluate which benefits are already provided by using the debian kernel package compared to going vanilla (and patching in what you need apart from vanilla). Currently README.Debian in kernel-source has an incomplete list. I talked to Jens about this and we can't see anything in Policy mandating that at all, so we plan to remove that aswell. With the .dpatch ification you can easily check in the source for yourself, all the .dpatches have proper descriptions. well, installing a kernel first to see if i like its patches is not very compfortable. So i was actually referring to the description of apt-cache show kernel-patch-debian-2.6.7 kernel-image-2.6.7-1-k7 which does not list anything at all. I see that maintaining a list is problematic, so maybe a pointer to the SVN/CVS URL would be helping. Just some place i can check the list *BEFORE* downloading some 30MB off the net (which i then remove after having read README.Debian). Moreover i think it'd make more sense making kernel-patch-debian a meta-pacakge depending on all diffs it contains. That way reverting one patch out of the Debian proposed patchset will be much easier. No way. We give you the kernel package, and all QA is for all the package. If you want to build your own images your ofcourse free to patch grab all patches, but please don't place the burden of taking care of all your crazy ideas on us. It was meant as a means to debug. Like i have a problem and i want to find out which patch breaks (for vanilla kernel works fine), then removing a certain patch and trying might make sense. It was not meant for you to support QA for that, just a better way to build unsupported personal kernel-images or report bugs after proving more details. If that's not needed, ok fine. ;) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
