On 9 Apr 2006, Eduard Bloch wrote:
#include hallo.h
* Manoj Srivastava [Sun, Apr 09 2006, 01:54:03AM]:
And there are additional targets that m-a-infected rules file
provide, used to predict the file location and debug the build
environment.
I am not sure I understand. Predict which file
On 8 Apr 2006, Eduard Bloch wrote:
include hallo.h
* Manoj Srivastava [Sat, Apr 08 2006, 09:14:14AM]:
On 6 Apr 2006, Eduard Bloch wrote:
include hallo.h
* Sven Luther [Thu, Apr 06 2006, 08:09:46AM]:
On Wed, Apr 05, 2006 at 09:12:08PM -0700, Jurij Smakov wrote:
On Wed, 5 Apr 2006, Sven
#include hallo.h
* Manoj Srivastava [Sun, Apr 09 2006, 01:54:03AM]:
And there are additional targets that m-a-infected rules file
provide, used to predict the file location and debug the build
environment.
I am not sure I understand. Predict which file location?
Output file.
On 6 Apr 2006, Eduard Bloch wrote:
#include hallo.h
* Sven Luther [Thu, Apr 06 2006, 08:09:46AM]:
On Wed, Apr 05, 2006 at 09:12:08PM -0700, Jurij Smakov wrote:
On Wed, 5 Apr 2006, Sven Luther wrote:
So, directly using make-kpkg as was the recomended way until now
is no more supported ?
#include hallo.h
* Manoj Srivastava [Sat, Apr 08 2006, 09:14:14AM]:
On 6 Apr 2006, Eduard Bloch wrote:
#include hallo.h
* Sven Luther [Thu, Apr 06 2006, 08:09:46AM]:
On Wed, Apr 05, 2006 at 09:12:08PM -0700, Jurij Smakov wrote:
On Wed, 5 Apr 2006, Sven Luther wrote:
So, directly
On Wed, Apr 05, 2006 at 09:12:08PM -0700, Jurij Smakov wrote:
On Wed, 5 Apr 2006, Sven Luther wrote:
So, directly using make-kpkg as was the recomended way until now is no more
supported ?
Recommended by whom? :-) I did not explore the issue in detail, but we
By Manoj :), as well as
#include hallo.h
* Sven Luther [Thu, Apr 06 2006, 08:09:46AM]:
On Wed, Apr 05, 2006 at 09:12:08PM -0700, Jurij Smakov wrote:
On Wed, 5 Apr 2006, Sven Luther wrote:
So, directly using make-kpkg as was the recomended way until now is no more
supported ?
Recommended by whom? :-) I did
On Mon, Apr 03, 2006 at 10:37:43PM -0700, Jurij Smakov wrote:
Hi,
In the discussion I've seen so far most people tend to favor the system,
in which each individual module package builds the binary packages
matching the current kernels. Based on that I've written a very
preliminary draft
On Wed, 5 Apr 2006, Sven Luther wrote:
So, directly using make-kpkg as was the recomended way until now is no more
supported ?
Recommended by whom? :-) I did not explore the issue in detail, but we
have a *lot* of modules packaged with module-assistant in the archive
already. If that way
On Mon, Apr 03, 2006 at 10:37:43PM -0700, Jurij Smakov wrote:
Hi,
In the discussion I've seen so far most people tend to favor the system,
in which each individual module package builds the binary packages
matching the current kernels. Based on that I've written a very
preliminary draft
On Tue, 4 Apr 2006, Bastian Blank wrote:
On Mon, Apr 03, 2006 at 10:37:43PM -0700, Jurij Smakov wrote:
There is already one available on
svn://svn.debian.org/pkg-voip/zaptel-modules/trunk/debian.
or
http://svn.debian.org/wsvn/pkg-voip/zaptel-modules/trunk/debian/
Great! I'll have a look,
#include hallo.h
* Jurij Smakov [Tue, Apr 04 2006, 09:34:29AM]:
On Tue, 4 Apr 2006, Bastian Blank wrote:
On Mon, Apr 03, 2006 at 10:37:43PM -0700, Jurij Smakov wrote:
There is already one available on
svn://svn.debian.org/pkg-voip/zaptel-modules/trunk/debian.
or
Hi,
In the discussion I've seen so far most people tend to favor the system,
in which each individual module package builds the binary packages
matching the current kernels. Based on that I've written a very
preliminary draft of the policy (below). One problem with the
described scheme is
Hello,
I'm looking into Ubuntu kernel nowadays 'cause a project and found
that their idea of maintain the modules directly inside of kernel
might be a easier to deal solution in mid and long term.
IMHO, keeping our kernel modules outside of kernel itself will work
until the module is prove
On Wed, Mar 29, 2006 at 11:10:03AM -0300, Otavio Salvador wrote:
Hello,
I'm looking into Ubuntu kernel nowadays 'cause a project and found
that their idea of maintain the modules directly inside of kernel
might be a easier to deal solution in mid and long term.
IMHO, keeping our kernel
On Sun, 26 Mar 2006, Sven Luther wrote:
[..]
2) do not build module .udebs from out-of-tree packages, and let it be the
responsability of the d-i team to extract choice modules from those
out-of-tree modules .debs to be repackaged as .debs. I don't know if the d-i
team is ready to go that
On Tue, Mar 28, 2006 at 08:12:04PM -0800, Jurij Smakov wrote:
On Sun, 26 Mar 2006, Sven Luther wrote:
[..]
2) do not build module .udebs from out-of-tree packages, and let it be the
responsability of the d-i team to extract choice modules from those
out-of-tree modules .debs to be
On Fri, Mar 24, 2006 at 03:29:00PM +0100, Max Vozeler wrote:
Let me try again: In order to build module packages for Debian
kernel packages and the repackaged -di kernel packages, I need to
know at build-time which flavours my package should try to build
for so that I can generate
On Fri, Mar 24, 2006 at 01:16:45AM -0500, Joey Hess wrote:
(Your use of the term udeb kernels is confusing and innaccurate. d-i
does not use different kernels than anything else.)
Indeed, point taken. To clarify: I meant the udeb packages
kernel-image-$KVERS-di.
Max Vozeler wrote:
2. The
On Fri, 24 Mar 2006, Max Vozeler wrote:
Let me try again: In order to build module packages for Debian
kernel packages and the repackaged -di kernel packages, I need to
know at build-time which flavours my package should try to build
for so that I can generate debian/control accordingly. This
On Friday 24 March 2006 15:29, Max Vozeler wrote:
My question is: How can I
determine the subset of flavours that are used in -di packages
and that it makes sense to build module udebs for?
All flavors d-i builds udebs from for all architectures can be found in
the d-i SVN archive in
On Thu, Mar 23, 2006 at 02:10:44AM -0500, Andres Salomon wrote:
That other stuff is what I'm interested in, at this point; waldi
claims to be working on stuff[0]. Waldi, can you please expand upon
that?
It works properly for linux-nonfree-2.6. For further informations please
take a look at
On Wed, Mar 22, 2006 at 08:32:06PM -0800, Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
rebuild and
On Thu, Mar 23, 2006 at 12:13:16AM -0500, Joey Hess wrote:
Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
On Wed, Mar 22, 2006 at 08:32:06PM -0800, Jurij Smakov wrote:
Hi,
It is pretty obvious (to me, at least) that the need for the official
packaging policy for the out-of-tree kernel modules is long overdue. As
mentioned on the wiki page dedicated to it [0], the current situation is a
mess.
On Thu, Mar 23, 2006 at 12:13:16AM -0500, Joey Hess wrote:
Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
On Thursday 23 March 2006 21:30, Sven Luther wrote:
There are some minor technical hurdles to it, and a strong irrational
opposition to it though, so it is probably going to stay a problem.
You don't learn, do you?
pgppU8gwjUm0D.pgp
Description: PGP signature
On Thu, Mar 23, 2006 at 09:30:02PM +0100, Sven Luther wrote:
On Thu, Mar 23, 2006 at 06:42:23PM +0100, Max Vozeler wrote:
2. The information about flavours used in udeb kernels is not
available in linux-headers. For normal flavours waldi's build
Sure it is, the whole
People who don't want to read me, please don't read me :)
On Fri, Mar 24, 2006 at 01:25:25AM +0100, Max Vozeler wrote:
On Thu, Mar 23, 2006 at 09:30:02PM +0100, Sven Luther wrote:
On Thu, Mar 23, 2006 at 06:42:23PM +0100, Max Vozeler wrote:
2. The information about flavours used in udeb
On Thu, 23 Mar 2006, Joey Hess wrote:
Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
rebuild and installation, if
(Your use of the term udeb kernels is confusing and innaccurate. d-i
does not use different kernels than anything else.)
Max Vozeler wrote:
1. The version of linux-headers in unstable is sometimes ahead of
the udeb kernel-image packages, like right now (2.6.15/2.6.16).
Only because the
Hi,
It is pretty obvious (to me, at least) that the need for the official
packaging policy for the out-of-tree kernel modules is long overdue. As
mentioned on the wiki page dedicated to it [0], the current situation is a
mess. I would like to call for a formal discussion, which will eventually
Jurij Smakov wrote:
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
rebuild and installation, if neccessary.
The thing I really
Jurij Smakov wrote:
Hi,
It is pretty obvious (to me, at least) that the need for the official
packaging policy for the out-of-tree kernel modules is long overdue. As
mentioned on the wiki page dedicated to it [0], the current situation is
a mess. I would like to call for a formal
34 matches
Mail list logo
