Bug#743796: flash-kernel: kirkwood+ should be considered the same as kirkwood
Package: flash-kernel Version: 3.3+deb7u2 Severity: normal Dear Maintainer, * What led up to the situation? Built a custom kernel with make-kpkg * What exactly did you do (or not do) that was effective (or ineffective)? I built it in the directory containing the .git subdirectory * What was the outcome of this action? make-kpkg decided to call the kernel -kirkwood+- instead of xxx-kirkwood-xxx, so flash-kernel considers it's no good for my system. * What outcome did you expect instead? flash-kernel should accept an image called xxx-kirkwood+ as valid for a kirkwood system -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.8.0-jh1-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flash-kernel depends on: ii devio1.2-1+b1 ii initramfs-tools 0.109.1 ii linux-base 3.5 flash-kernel recommends no packages. Versions of packages flash-kernel suggests: ii u-boot-tools 2012.04.01-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140406155610.3317.136.report...@plug.colmar.atlantech.com
Bug#743796: flash-kernel: kirkwood+ should be considered the same as kirkwood
John Hughes j...@calva.com (2014-04-06): Package: flash-kernel Version: 3.3+deb7u2 Severity: normal Dear Maintainer, * What led up to the situation? Built a custom kernel with make-kpkg * What exactly did you do (or not do) that was effective (or ineffective)? I built it in the directory containing the .git subdirectory * What was the outcome of this action? make-kpkg decided to call the kernel -kirkwood+- instead of xxx-kirkwood-xxx, so flash-kernel considers it's no good for my system. * What outcome did you expect instead? flash-kernel should accept an image called xxx-kirkwood+ as valid for a kirkwood system AFAICT make-kpkg is not considered supported, at least by the kernel team. I suggest you start using the deb-pkg target instead. I'm not going to oppose the change if someone wants to patch flash-kernel of course; just trying to share my understanding of the current situation. Mraw, KiBi. signature.asc Description: Digital signature
Bug#743796: flash-kernel: kirkwood+ should be considered the same as kirkwood
On Sun, 2014-04-06 at 18:24 +0200, Cyril Brulebois wrote: John Hughes j...@calva.com (2014-04-06): Package: flash-kernel Version: 3.3+deb7u2 Severity: normal Dear Maintainer, * What led up to the situation? Built a custom kernel with make-kpkg * What exactly did you do (or not do) that was effective (or ineffective)? I built it in the directory containing the .git subdirectory * What was the outcome of this action? make-kpkg decided to call the kernel -kirkwood+- instead of xxx-kirkwood-xxx, so flash-kernel considers it's no good for my system. * What outcome did you expect instead? flash-kernel should accept an image called xxx-kirkwood+ as valid for a kirkwood system AFAICT make-kpkg is not considered supported, at least by the kernel team. I suggest you start using the deb-pkg target instead. [...] I don't think that will make a difference. The package name should always be 'linux-image-' plus the kernel version string (as reported by uname -r). The kernel build system appends '+' to the kernel version string if the source directory is version-controlled and there are uncommitted changes. For example, when I build a Debian package to test Linux 3.2.y, I am using a git repository patched using quilt and I get a package named something like linux-image-3.2.56-rc1+. This is appended *after* any localversion such as John has specified ('-kirkwood'). There is an easy workaround which is to commit changes before building. But I think it is reasonable to expect flash-kernel to tolerate the '+'. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part