On 9 Apr 2006, Eduard Bloch wrote:
> #include
> * 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 whi
#include
* 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. Exa
On 8 Apr 2006, Eduard Bloch wrote:
>> include
> * Manoj Srivastava [Sat, Apr 08 2006, 09:14:14AM]:
>> On 6 Apr 2006, Eduard Bloch wrote:
>>
include
>>> * 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
#include
* Manoj Srivastava [Sat, Apr 08 2006, 09:14:14AM]:
> On 6 Apr 2006, Eduard Bloch wrote:
>
> > #include
> > * 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, dire
On 6 Apr 2006, Eduard Bloch wrote:
> #include
> * 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 supp
#include
* 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? :-)
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
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 was
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 d
#include
* 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
> >http://svn.debian.o
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, than
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 d
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 tha
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 ker
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 useful
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 b
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 wa
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 debian/co
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 packag
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
in
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:
> >
(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
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 n
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 u
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 linux-2.6/de
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 02:10:44AM -0500, Andres Salomon wrote:
> 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]
On Thu, Mar 23, 2006 at 06:42:23PM +0100, 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). I
> don't remember exactly when this last happened, but for example
> once linux-headers-2.6.15-
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 attem
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
> m
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 attem
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 install
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 a
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 discu
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
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
36 matches
Mail list logo
