module-assistant support for zaptel

[Jose Carlos Garcia Sogo]

--=-bm9/fUvtfktZsewg4EjU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El lun, 28-03-2005 a las 09:23 +0200, Tzafrir Cohen escribi=C3=B3:
> On Sun, Mar 27, 2005 at 11:37:29PM +0200, Jose Carlos Garcia Sogo wrote:
> > El dom, 27-03-2005 a las 23:06 +0200, Tzafrir Cohen escribi=C3=B3:
> > > [ This post still does not refer to the issues rased by Eduard Bloch]
> > >=20
> > > On Sun, Mar 27, 2005 at 02:13:44AM +0200, Tzafrir Cohen wrote:
> > > > After playing with m-a a bit, I still don't see it saving me work w=
ith
> > > > automated builds. It requires quite a lot of initial setup, and mos=
t of
> > > > it appears to be the job of root.=20
> >=20
> >   Yes, for running in /usr/src you have to run m-a as root. Basically #
> > m-a a-i zaptel should do the trick.=20
>=20
> However for multiple kernels you basically have to extract the trees.

 Yes, or have kernel-sources-* packages around. With that it is enough.
You only have to pass -l $kvers-1,$kvers-2,... to m-a to get the module
compiled for every kernel version (see my other reply)

>=20
> >=20
> > > >=20
> > > > In addition, packaging the files in an internat tgz bypasses any sa=
nity=20
> > > > check lintian and others would do to them.
> >=20
> >   But there is no check that lintian can make to those files. Lintian
> > could only work in user generated zaptel-modules package. If you check
> > any other kernel modules package, you will see that source is also
> > placed in a tar.gz file.
>=20
> Did you notice you add -m 644 to almost every install (you actually
> forgot it with some, and used plain cp). lintian won't check file modes
> inside a tarball.

 Wooops. That's a fault on my part. And while you're right on this, I am
not sure lintian will fail on that, and having the source as a tar.gz is
better in my opinion.

>=20
> Anyway, what about /usr/include/linux/torisa.h ? Can zaptel-source
> provide it?

  Sorry, I don't know what do you mean here. It is included in
zaptel-source.

>=20
> >=20
> > > >=20
> > > > I've played with it all day long and it seems very unsuitable for
> > > > non-root builds. If it requires that the code module is compressed =
to a
> > > > rather than kept in its own directory than it really does harm. If =
not,
> > > > I have no problem with it and it might actually turn out useful one=
 day.
> >=20
> >   If you want to use it as non-root you have to pass --user-dir dir/ to
> > m-a, being dir a directory you have permissions.
>=20
> Been there, done, that and read the man page. The docs of the package
> leave me with a feeling that "this is fine if you want to run it as root
> and mess your own /usr/src , however if you run it as user, you're on
> your own".

 Well, it is intended to run on /usr/src... after all that is the point
on which kernel-headers will unpack by default. If you have unpacked
them by hand you have to pass the dir to m-a.

 Using a dir in $HOME can be a bit difficult, but I don't see what can
be the goal of compiling zaptel modules as an user, which by default
don't have either permissions to install packages nor permissions to
load modules in kernel space.

 Cheers,

--=20
Jose Carlos Garcia Sogo
   jsogo@debian.org

--=-bm9/fUvtfktZsewg4EjU
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCScbgS+BYJZB4jhERAkpbAJ4/toDqscu1oaw6DE/rdek47Kfe3QCfccW3
0Y/KbVThGXDwfvpr8/WU9qY=
=LKau
-----END PGP SIGNATURE-----

--=-bm9/fUvtfktZsewg4EjU--