Re: RFS: loop-aes (#111167)
#include <hallo.h>
* Max Vozeler [Wed, Nov 26 2003, 12:31:16AM]:
> > mv /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23 \
> > /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23-rc3
> > mv: cannot stat `/usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23': No such file or directory
> > make[1]: *** [binary-modules] Error 1
> > make[1]: Leaving directory `/usr/src/modules/loop-aes'
> >
> > make: *** [kdist_image] Error 2
>
> This was a problem in EXTRAVERSION handling that should be
A-Ha.
> fixed in loop-aes-source 1.7e-12 and loop-aes-ciphers-source
> 1.1e-10.
Hm, as said before, look at the examples I mentioned:
- you do not provide a source tarball in /usr/src called after the
common name conventions (pkg-name without trailing -source)
- your packages do DEPEND on the kernel-image-foo but it is not
guaranteed that a make-kpkg'ed kernel is used. In fact, you
completely rely on what the macros of dh_make detect but this
calculations are written for detecting some random kernel, they do
NOT guarantee that a kernel-image-... package is used. In fact, there
are insufficient to rely on anything (IMHO), that is why there is the
module-assistant package
- I guess you did NEVER install the created packages for the kernels
you build them for. It tries to overwrite loop.o from the main kernel
as well as modules.dep and a bunch of other files. WTF? Same thing
with the -ciphers package. You maybe want to use dpkg-divert for
loop.o and not put any of the depmod products into the package but
run depmod -a from the package.
- you recommend to run the binary-modules rule but this rule does NOT
run clean before _and_ after the build process. Expect trouble when
kernel source or compiler change inexpectedly
- your rules files still ignore KPKG_DEST_DIR (as said,
module-assistant's includes will handle it or rip code from
alsa-source)
MfG,
Eduard.
--
Zu guten Beziehungen gelangt man am schnellsten, wenn man den Eindruck
erweckt, sie zu besitzen.
-- Sigmund Graff
Reply to: