On Sun, Sep 21, 2003 at 08:27:49PM -0500, Manoj Srivastava wrote:
I am always willing to improve my packages; the constraints
are ability (I would need to grok the details of the current
implementation), time, and collaboration (I would need to find out
how to get a hook into the
On Mon, 22 Sep 2003 11:27, Manoj Srivastava wrote:
The scripts handle ordering by testing each dependency, and if it is
not already applied, invoking the corresponding apply script. In
this way, all dependencies should be applied in proper order.
Rollback could presumably be implemented
On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
On Sun, May 18, 2003 at 12:06:21PM -0500, Manoj Srivastava wrote:
There is also a mechanism to order the order in which
kernel-patches are applied -- so if, say, a m68k kernel image
maintainer wanted to create a patch
On Sun, Sep 21, 2003 at 06:36:25PM -0500, Manoj Srivastava wrote:
On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
dh-kpatches provides a dependency/ordering facility which has worked
well for me in my packages. It also provides
On Sun, 21 Sep 2003 20:12:26 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
On Sun, Sep 21, 2003 at 06:36:25PM -0500, Manoj Srivastava wrote:
On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman [EMAIL PROTECTED]
said:
dh-kpatches provides a dependency/ordering facility which has
worked well
On Tue, 27 May 2003 11:04:07 +0200, Arnd Bergmann [EMAIL PROTECTED] said:
The order in which the patches are applied should in general not be
significant. If it is, it should be stated in the patch
description. I assumed that the 'Depends' tag is semantically more a
'Pre-Depends', right?
On Sun, May 25, 2003 at 08:12:00AM +1000, Herbert Xu wrote:
Christoph Hellwig [EMAIL PROTECTED] wrote:
Why can't Debian have just one tree for multiple architectures like
SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386,
x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel
On Sat, May 31, 2003 at 12:14:31PM -0500, Christian T. Steigies wrote:
I think this is contracticting to what you said just a few messages earlier.
For 2.4.21 will there be a pristine kernel-source and seperate i386-patch or
not? It seems I am the m68k maintainer, and I am for the seperate
I'm answering a bit late, but after rethinking, I don't see what's that
wrong with that approach.
Le dim 25/05/2003 à 11:33, Herbert Xu a écrit :
That is an advantage. However, it also means that any update to the
modules source package cannot be built until another entire
kernel-image set is
On Sun, May 25, 2003 at 08:26:08PM +1000, Anthony Towns wrote:
As far as I could tell, we don't have any other examples at present,
than alsa and pcmcia.
Since no one seems to have replied correcting me, there's also apparently
linux-wlan-ng-modules-*, i2c-*, and lm-sensors-*.
Cheers,
aj
--
On Tue, May 27, 2003 at 07:23:27AM +1000, Herbert Xu wrote:
On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
We could get around Guido's point mentionned above by having a list of
default patches to apply, which would by default contain the debian
patch.
Yes, but then the
Arnd wrote:
Actually, I was thinking of a different concept with a 'Replaces: tag,
Hm. As I understand it, it would be more something like a Provides:
declaration, it seems. Such a feature does not seem useless to me at
first glance (we already see aglomerations of patches, like FOLK,
which
On Tue, May 27, 2003 at 07:37:42AM +0200, Sven Luther wrote:
On Tue, May 27, 2003 at 07:23:27AM +1000, Herbert Xu wrote:
On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
We could get around Guido's point mentionned above by having a list of
default patches to apply, which
Matt Zimmerman [EMAIL PROTECTED] wrote:
All definite benefits. The one thing which seems to be missing is to ensure
that the arch-specific kernels do not miss out on important fixes (such as
security) to the main kernel source tree.
Yes that isn't easy to check apart from the fact that if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 27 May 2003 10:27, Yann Dirson wrote:
Let's look at your example:
| Patch-name: Debian base patch
| Patch-id: debian
| Architecture: all
| Kernel-version: 2.4.20
| Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
|
|
On Tue, 27 May 2003 19:04, Arnd Bergmann wrote:
Here I suppose the pre-patch is supposed to be applied first, and then
the application of the debian patch would only trigger application of
those dependant patches not provided by the pre-patch.
The order in which the patches are applied
On Tue, May 27, 2003 at 08:16:59PM +1000, Russell Coker wrote:
On Tue, 27 May 2003 19:04, Arnd Bergmann wrote:
Here I suppose the pre-patch is supposed to be applied first, and then
the application of the debian patch would only trigger application of
those dependant patches not provided
Sven wrote:
Why don't we use a scheme similar to what xfree86 use for its patches.
Sure we would need to adapt it as the patches are distributed, but we
could well do it.
As I understand it, the xfree86 package uses (some derivative of) dbs,
in which the package maintainer has to order the
Arnd wrote:
Let's look at your example:
| Patch-name: Debian base patch
| Patch-id: debian
| Architecture: all
| Kernel-version: 2.4.20
| Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
|
| Patch-name: Pre-patch 2.4.21-pre7
| Patch-id: patch-2.4.21-pre7
|
Herbert wrote:
Yes that isn't easy to check apart from the fact that if there isn't
an arch update after a security update to kernel-source, then that arch
is probably vulnerable. If you've got an idea on how this can improved,
please let us know.
A possibility would be to define a
Yann Dirson dijo [Tue, May 27, 2003 at 10:38:54AM +0200]:
That's more or less what I'd think of as well. We can start with an
empty security patch, and have this one grow as needed. This way, apt
will show people they have an outdated security patch - which, BTW,
may be more of an incentive
On Mon, May 26, 2003 at 09:25:42PM +0200, Yann Dirson wrote:
Matt wrote:
The ideal solution would be to be able to share tarballs between source
packages. Then, all of the kernel-image packages could be built as if
they had a complete kernel source tree as their source package (which
Matt wrote:
The ideal solution would be to be able to share tarballs between source
packages. Then, all of the kernel-image packages could be built as if they
had a complete kernel source tree as their source package (which simplifies
things a lot), and yet we would only need one such tarball
Matt wrote:
It would be a significant gain if kernel modules could always be built
against kernel-headers, without requiring full kernel-source.
Since recently there are also kernel-build packages, which appear to
be made precisely for that. I take it to mean the kernel-headers
packages have
Herbert wrote:
* The kernel-source binary contains all bug fixes as is. Guido raised
a good point that if we separated the patches from the kernel-source, then
users may miss out on the bug fixes. This is especially important in light
of the current speed of upstream releases.
* The
Arnd wrote:
Ok, but I still would love to see single patches instead of one big
patch containing all the common stuff. You can't really avoid
situations where you want a patch on all architectures except one or
two. This may be either because a patch breaks on one architecture
(which should
Matt wrote:
The part you seem to have missed is the distinction between a source package
and a binary package in what I wrote above.
Not completely, although the time between reading and answering did
not help me to be 100% clear with this :)
I do not think this is a practical idea to work
On Sun, May 25, 2003 at 11:00:34AM +1000, Herbert Xu wrote:
But the pristine kernel source and the Debian patch are already available
to the architecture maintainers:
apt-get --tar-only source kernel-source-2.4.xx
apt-get --diff-only source kernel-source-2.4.xx
So I don't think having a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 26 May 2003 22:20, Yann Dirson wrote:
If you mean, whether it can handle something like Architecture:
!ia64, !hppa, well, not yet, although it could be done. But that
would mean stopping the use of make-kpkg-level architecture support,
On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
We could get around Guido's point mentionned above by having a list of
default patches to apply, which would by default contain the debian
patch.
Yes, but then the problem is that unsuspecting users could be
building kernels using
On Sun, May 25, 2003 at 01:51:05AM +0200, Arnd Bergmann wrote:
SuSE don't have a single kernel source either. They have a set of
a few hundred common patches plus some more patches (e.g. 200
for s390) that are used only for one architecture, usually both 32 and
64 bit. Single patches can be
On Sat, May 24, 2003 at 06:32:26PM -0400, Matt Zimmerman wrote:
It's not noise at all when it's something that we and others (desperately!)
want to know about.
Then read through the prepatch diffs, everything adding checks to
ioctl methods or similar is likely one them.
On Sat, May 24, 2003 at 08:10:20PM -0400, Matt Zimmerman wrote:
in task_struct then perhaps so assuming that we care about it enough to do
it in such a way. Otherwise I don't see your point.
Are task_struct and mm_struct exposed to modules?
Yes.
they should need to be, but I am no
On Sun, May 25, 2003 at 06:21:00AM +0200, Christoph Hellwig wrote:
On Sat, May 24, 2003 at 06:32:26PM -0400, Matt Zimmerman wrote:
It's not noise at all when it's something that we and others (desperately!)
want to know about.
Then read through the prepatch diffs, everything adding checks
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote:
OK, barring any major objections, that's how it will be for 2.4.21.
Is there any possibility of having the various foo-modules-2.4.xx packages
be built concurrently with kernel-image-2.4.xx too?
Something like:
On Sun, 25 May 2003 15:11, Matt Zimmerman wrote:
On Sun, May 25, 2003 at 06:21:00AM +0200, Christoph Hellwig wrote:
On Sat, May 24, 2003 at 06:32:26PM -0400, Matt Zimmerman wrote:
It's not noise at all when it's something that we and others
(desperately!) want to know about.
Then read
On Sun, May 25, 2003 at 01:11:44AM -0400, Matt Zimmerman wrote:
Then read through the prepatch diffs, everything adding checks to
ioctl methods or similar is likely one them.
This approach does not scale.
Right, you got it. Similarly it doesn't scale to announce all these
bits. Just
Anthony Towns aj@azure.humbug.org.au wrote:
Having kernel modules associated with the kernel source package they're
built for makes it a bunch easier to make sure they're deleted from
the archive along with the corresponding kernel images, and makes sure
that when someone uploads a new
On Sun, May 25, 2003 at 07:33:04PM +1000, Herbert Xu wrote:
Anthony Towns aj@azure.humbug.org.au wrote:
Having kernel modules associated with the kernel source package they're
built for makes it a bunch easier to make sure they're deleted from
the archive along with the corresponding kernel
On Sun, 25 May 2003 19:33, Herbert Xu wrote:
In the long term, we should have as few binary module packages as
possible. They should either be integrated into our kernel-source
if it is popular enough or made source-only so that the people who
really need them can build them privately. I
On Sun, May 25, 2003 at 08:20:39PM +1000, Russell Coker wrote:
What is the status of the pcmcia support anyway?
Seems to work fine. Red Hat uses inkernel pcmcia at least.
There's some pcmcia drivers not (yet?) merged in the kernel but patching
them in is rather easy.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 25 May 2003 06:19, Christoph Hellwig wrote:
On Sun, May 25, 2003 at 01:51:05AM +0200, Arnd Bergmann wrote:
As a real-world example, kernel-patch-s390 can provide
the ptrace bug fix from Martin Schwidefsky, while
kernel-patch-debian
On Sun, May 25, 2003 at 09:23:44AM +0200, Christoph Hellwig wrote:
On Sun, May 25, 2003 at 01:11:44AM -0400, Matt Zimmerman wrote:
Then read through the prepatch diffs, everything adding checks to
ioctl methods or similar is likely one them.
This approach does not scale.
Right,
On Sun, May 25, 2003 at 04:09:51PM +1000, Russell Coker wrote:
On Sun, 25 May 2003 15:11, Matt Zimmerman wrote:
This approach does not scale. I cannot personally review the diffs for
every upstream release of all the software in Debian, nor can any other
individual or even a small group.
On Sun, May 25, 2003 at 02:34:50PM +0200, Arnd Bergmann wrote:
When building kernel-image-s390, make-kpkg would first apply
the arch specific patches and the the arch independent ones that
have not been superceded by an arch specific one.
Again that's a very bad idea.
On Sat, May 24, 2003 at 08:44:48AM +1000, Herbert Xu wrote:
Guido Guenther [EMAIL PROTECTED] wrote:
This only works if we have a _clean_ kernel-source-2.X.Y package. One of
the reasons why maintaining kernel-patch-2.X.Y-arch packages is such a
pain is the asymmetry between i386 and other
Guido Guenther [EMAIL PROTECTED] wrote:
It's very hard to get these bug fixes anyway since when I do a
_complete_ diff between kernel-source-2.X.Y in the archive and the
kernel source for architecture foo I'll _always_ (accidentally)
pull out all the bug fixes you made. Only diffing specific
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote:
OK, barring any major objections, that's how it will be for 2.4.21.
I will make kernel-source-2.4.21 be identical to the upstream tar ball
except for the non-free bits. A kernel-patch-i386 package will be
introduced.
You won't here
On Sat, May 24, 2003 at 04:06:30PM +0200, Guido Guenther wrote:
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote:
OK, barring any major objections, that's how it will be for 2.4.21.
I will make kernel-source-2.4.21 be identical to the upstream tar ball
except for the non-free
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote:
Guido, you're not going about it the right way. It's a three-way
merge. You take a kernel.org tree, diff it against the architecture
tree that you're interested in, and then wiggle it into applying to the
kernel source
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote:
Guido Guenther [EMAIL PROTECTED] wrote:
It's very hard to get these bug fixes anyway since when I do a
_complete_ diff between kernel-source-2.X.Y in the archive and the
kernel source for architecture foo I'll _always_
On Sat, May 24, 2003 at 07:03:22PM +0200, Christoph Hellwig wrote:
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote:
Guido, you're not going about it the right way. It's a three-way
merge. You take a kernel.org tree, diff it against the architecture
tree that you're
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote:
Guido, you're not going about it the right way. It's a three-way merge.
You take a kernel.org tree, diff it against the architecture tree that
you're interested in, and then wiggle it into applying to the kernel
source
On Sat, May 24, 2003 at 01:25:38PM -0400, Daniel Jacobowitz wrote:
Sure, it's more work but I think it's worth it.
Because no one's done it?
Hey, if that was an argument. The question is whether people want it..
We can't count on it because the architecture ports become available at
On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote:
Some m68k architectures might be a hard, I agree. But having a package
that works on as many machines as possible would be very cool.
well, I there is a shared debian-kernel cvs then all architecture
maintainers can commit,
On Sat, May 24, 2003 at 07:51:17PM +0200, Karsten Merker wrote:
Because it simply did not work out - not all architectures are in sync with
Linus' tree
Oh, I know that well enough.
and if I understood our port maintainer correctly, there are
some architecture-specific things Linus does not
On Fri, May 23, 2003 at 09:20:28PM +1000, Herbert Xu wrote:
So unless someone can come up with a solution to this problem,
we will have to live with multiple Debian source packages for now.
This does make security fixes more difficult than it would be otherwise,
however, I do not think it
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote:
Guido, you're not going about it the right way. It's a three-way
merge. You take a kernel.org tree, diff it against the architecture
tree that you're interested in, and then wiggle it into applying to the
kernel source
On Sat, May 24, 2003 at 08:18:40PM +0200, Bernd Eckenfels wrote:
On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote:
Some m68k architectures might be a hard, I agree. But having a package
that works on as many machines as possible would be very cool.
well, I there is a
On Sun, 25 May 2003 04:18, Bernd Eckenfels wrote:
On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote:
Some m68k architectures might be a hard, I agree. But having a package
that works on as many machines as possible would be very cool.
well, I there is a shared debian-kernel
On Sat, May 24, 2003 at 02:34:17PM -0400, Matt Zimmerman wrote:
What benefit is there in not announcing these problems? Security through
obscurity? How can we inform our users of their exposure when we are not
informed ourselves about security problems?
Noise. You can's accnounce every
On Sat, May 24, 2003 at 01:42:22PM -0400, Matt Zimmerman wrote:
So this means that maintainers of the architecture patches must be sure to
merge in these fixes, otherwise they may inherit security vulnerabilities
(for example)? How can we track when this has happened when there are so
many
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote:
Guido, you're not going about it the right way. It's a three-way
merge. You take a kernel.org tree, diff it against the architecture
tree that you're interested in, and then wiggle it into applying to the
kernel source
On Sun, May 25, 2003 at 04:29:13AM +1000, Russell Coker wrote:
On Sun, 25 May 2003 04:18, Bernd Eckenfels wrote:
On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote:
Some m68k architectures might be a hard, I agree. But having a package
that works on as many machines as
Matt Zimmerman [EMAIL PROTECTED] wrote:
Given an explicit kernel-patch-debian, containing architecture-agnostic
differences between kernel.org source and Debian's kernel source,
arch-specific merges could be mostly automated, and security fixes could be
made in one place.
How does this
Matt Zimmerman [EMAIL PROTECTED] wrote:
I think that we can live with multiple source packages given a little bit of
infrastructure which more closely follows the way that kernel development
happens. We need to be able to introduce specific patches to all of our
kernels while minimizing the
Christoph Hellwig [EMAIL PROTECTED] wrote:
Why can't Debian have just one tree for multiple architectures like
SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386,
x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches
for sparc,sparc64,mips and m68k although I can't
On Sat, May 24, 2003 at 08:42:39PM +0200, Christoph Hellwig wrote:
On Sat, May 24, 2003 at 02:34:17PM -0400, Matt Zimmerman wrote:
What benefit is there in not announcing these problems? Security
through obscurity? How can we inform our users of their exposure when
we are not informed
On Sat, May 24, 2003 at 08:44:26PM +0200, Guido Guenther wrote:
On Sat, May 24, 2003 at 01:42:22PM -0400, Matt Zimmerman wrote:
So this means that maintainers of the architecture patches must be sure
to merge in these fixes, otherwise they may inherit security
vulnerabilities (for
On Sun, May 25, 2003 at 07:37:10AM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
Given an explicit kernel-patch-debian, containing architecture-agnostic
differences between kernel.org source and Debian's kernel source,
arch-specific merges could be mostly automated,
On Sun, May 25, 2003 at 07:58:09AM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
By 'independent packages', do you mean that we should have separate
kernel-source source packages for each architecture? This would seem to
be a step backward.
No, they are independent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig [EMAIL PROTECTED] wrote:
Why can't Debian have just one tree for multiple architectures like
SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386,
x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Sun, May 25, 2003 at 07:37:10AM +1000, Herbert Xu wrote:
How does this automate the arch-specific merges where conflicts arise?
1. unpack pristine kernel source
2. apply Debian patch
3. dry-run arch-specific patch
4. if no conflicts, test and
Matt Zimmerman [EMAIL PROTECTED] wrote:
In general, this is not a problem. The exception is coordinated disclosure,
where it is important that fixes be available for all architectures in order
to minimize exposure. In those cases, it would be helpful to coordinate
with all of the kernel
Martin Schulze wrote:
Only a few people will probably have noticed the mess resulting from
tons of different kernel packages in the stable (and unstable)
distribution. Not only there are several versions of kernel source in
each architecture, they are also different for most architectures.
On Fri, May 23, 2003 at 09:04:05AM +0200, Martin Schulze wrote:
Martin Schulze wrote:
Only a few people will probably have noticed the mess resulting from
tons of different kernel packages in the stable (and unstable)
distribution. Not only there are several versions of kernel source in
On Fri, 23 May 2003 17:04, Martin Schulze wrote:
I wonder if some people (Maybe Manoj and Russell, who are both quite
competent) could help with this effort.
I would love to contribute, however at the moment I am over-committed already.
Progress towards getting SE Linux support in main is
Martin Schulze [EMAIL PROTECTED] wrote:
Manoj emphasized[1] that using one single kernel source package per
kernel version and maintaining several patch packages for each
architecture which finally build our kernel-image-$version packages is
possible.
It seems that there is some confusion
On Fri, May 23, 2003 at 05:58:15PM +1000, Russell Coker wrote:
That's not a problem, you just have to run diff between the source tree for
the platform in question and the Linus tree.
This only works if we have a _clean_ kernel-source-2.X.Y package. One of
the reasons why maintaining
On Fri, May 23, 2003 at 09:04:05AM +0200, Martin Schulze wrote:
To make it more interesting, Matt Zimmerman revealed[2] that merging all
kernel source packages would save space of one CD from our archive and our
CD images.
I was probably exaggerating slightly; I did not do the calculations.
Guido Guenther [EMAIL PROTECTED] wrote:
This only works if we have a _clean_ kernel-source-2.X.Y package. One of
the reasons why maintaining kernel-patch-2.X.Y-arch packages is such a
pain is the asymmetry between i386 and other arches - almost every time
a new kernel-source package is
Le dim 18/05/2003 à 16:52, Martin Schulze a écrit :
I also wonder if there are efforts in progress to unify the kernel
source through more than two architectures? This would require a
group or architecture maintainers (current kernel package mantainers)
to work collaboratively towards this
Hello
On Sun, May 18, 2003 at 04:52:54PM +0200, Martin Schulze wrote:
*SNIP*
Removing one kernel version and including another without rebuilding
all modules packages will break several installations. Not removing
the old packages will make the archive grow through time which will
cause
On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote:
I'll start here:
Kernel package policy:
kernel image to avoid confusion between kernel source, kernel headers,
kernel modules, etc.
--
* It should only exist one kernel-source package.
* Every
On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote:
Kernel module policy:
-
* Kernel modules must be provided as a binary source package.
* Module source packages should provide a debian/rules file.
* The debian/rules file must compile the module if
Ola Lundqvist [EMAIL PROTECTED] writes:
Kernel module policy:
-
* Kernel modules must be provided as a binary source package.
* Module source packages should provide a debian/rules file.
* The debian/rules file must compile the module if KSRC=kernelsourcedir
and
Hello
On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote:
On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote:
I'll start here:
Kernel package policy:
kernel image to avoid confusion between kernel source, kernel headers,
Agreed.
kernel modules, etc.
Hello
On Mon, May 19, 2003 at 12:43:02PM -0400, David Z Maze wrote:
Ola Lundqvist [EMAIL PROTECTED] writes:
Kernel module policy:
-
* Kernel modules must be provided as a binary source package.
* Module source packages should provide a debian/rules file.
* The
Only a few people will probably have noticed the mess resulting from
tons of different kernel packages in the stable (and unstable)
distribution. Not only there are several versions of kernel source in
each architecture, they are also different for most architectures.
Only mips and mipsel share
On Sun, 18 May 2003 16:52:54 +0200, Martin Schulze [EMAIL PROTECTED] said:
I also wonder if there are efforts in progress to unify the kernel
source through more than two architectures? This would require a
group or architecture maintainers (current kernel package
mantainers) to work
On Mon, 19 May 2003 03:06, Manoj Srivastava wrote:
When I first envisaged the kernel source and kernel-patch
system, I always figured there should be a single source package per
version -- the one you get from kernel.org. *EVERY* arch, including
i386, should provided a kernel-patch
On Sun, May 18, 2003 at 04:52:54PM +0200, Martin Schulze wrote:
I also wonder if there are efforts in progress to unify the kernel
source through more than two architectures? This would require a
group or architecture maintainers (current kernel package mantainers)
to work collaboratively
On Mon, May 19, 2003 at 09:33:48AM +1000, Brian May wrote:
Looking at woody in fact, it appears to only exceptions appear to be
HPPA and IA64:
kernel-source-2.2.22 - Linux kernel source for version 2.2.22
kernel-source-2.4.10 - Linux kernel source for version 2.4.10
kernel-source-2.4.14 -
On Sun, May 18, 2003 at 12:06:21PM -0500, Manoj Srivastava wrote:
There is also a mechanism to order the order in which
kernel-patches are applied -- so if, say, a m68k kernel image
maintainer wanted to create a patch relative to the i386 patches,
they could depend on that patch, and
On Mon, May 19, 2003 at 05:13:54AM +1000, Russell Coker wrote:
Definately. This should be done if only to avoid multiple copies of a 27M
bzip2 archive wasting everyone's disk space and network bandwidth.
Also regarding the i386 arch, multiple patches would be good. Something
in the i386
95 matches
Mail list logo
