On Fri, Oct 10, 2003 at 09:30:06PM +0200, martin f krafft wrote:
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.0223 +0200]:
...and the freeswan patch is not in the Linux kernel (and as I understand
it, it never will be).
The IPsec patch is not in the 2.4 kernel either. I don't
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.2333 +0200]:
It is in 2.5 and 2.6. It is in Linux henceforth. FreeSWAN, on top of its
other issues, is not, has never been, and never will be, part of the
official kernel.
Is that clearer?
Doesn't explain why the IPsec patch should
On Thu, Oct 16, 2003 at 07:04:27PM +0200, martin f krafft wrote:
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.2333 +0200]:
It is in 2.5 and 2.6. It is in Linux henceforth. FreeSWAN, on top of
its other issues, is not, has never been, and never will be, part of the
official
On Sun, Oct 05, 2003 at 03:18:53PM +0200, Tollef Fog Heen wrote:
* Herbert Xu
| Very few people really need cramfs if they're building custom kernels.
| This is because initrd only makes sense when you're building for a
| large number of machines. If you're building a custom kernel, just
On Mon, Oct 06, 2003 at 10:20:57PM +0200, martin f krafft wrote:
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.29.0232 +0200]:
Hear, hear. IPsec in particular is long overdue in the Linux
kernel and I am glad to see it.
It has existed in the freeswan patch for a while!
...and the
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.0223 +0200]:
...and the freeswan patch is not in the Linux kernel (and as I understand
it, it never will be).
The IPsec patch is not in the 2.4 kernel either. I don't get your
point.
--
Please do not CC me when replying to lists; I read
On Tuesday, Oct 7, 2003, at 15:07 US/Eastern, martin f krafft wrote:
Alright, I give you that. But it works.
Sort of. I routinely have to fight it on my IPSec gateway. It really
doesn't like some of the things I do with (to?) it. I understand the
new IPSec stack is supposed to be much better and
On Mon, 6 Oct 2003, martin f krafft wrote:
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0510 +0200]:
For example, the grsecurity patch has had a history of conflicts
with various patches in the Debian kernel source. Most of those
patches that caused conflicts were in fact essential
also sprach Adam Borowski [EMAIL PROTECTED] [2003.10.08.1124 +0200]:
If it's a small security fix, then I am willing to work that into
grsecurity. But I won't port grsecurity to a new IP stack nor the
other way around.
So, there will be no grsecurity for 2.6?
There will be, but not ported
On Mon, 2003-10-06 at 21:19, martin f krafft wrote:
I'd appreciate if you kept your opinions to yourself,
Can you do the same?
Scott
(Unsigned as I've already packed my keyring for Linux Expo today)
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the
also sprach Steve Langasek [EMAIL PROTECTED] [2003.10.07.0104 +0200]:
As stated above, this is not a reasonable restriction. An
arbitrary kernel patch package might conflict with *any* changes
made to the kernel-source package, including simple security
fixes.
A simple fix is easier to work
On Mon, 2003-10-06 at 15:39, martin f krafft wrote:
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1207 +0200]:
Let's create a package called linux-2.4.22 or
linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which
does exactly this.
I oppose. Let's get rid of
On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote:
But, this would alleviate SOME of the problems. This would be NO DOUBT
very helpful. The Binary Kernel (as in the archives could have any an
all patches you see fit Herbert)
Would it NO doubt make entirely MUCH more sense, to only
On Monday, Oct 6, 2003, at 16:20 US/Eastern, martin f krafft wrote:
It has existed in the freeswan patch for a while!
Let's be serious, FreeS/WAN has serious issues! Being at war with the
kernel routing machinery, for example.
On Monday, Oct 6, 2003, at 18:58 US/Eastern, Adam McKenna wrote:
I don't see how the package being in unstable affects any part of this
argument. Will the feature backport be less desirable when the
kernel-source package is released in a stable revision of Debian?
The whole point of not doing
On Tue, 2003-10-07 at 09:51, Colin Watson wrote:
On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote:
Would it NO doubt make entirely MUCH more sense, to only have to D/L the
Source Code once.
Would it be POSSIBLE to LOSE the Zippy-style CAPITALIZATION, please?
Would it be
also sprach Anthony DeRobertis [EMAIL PROTECTED] [2003.10.07.1935 +0200]:
It has existed in the freeswan patch for a while!
Let's be serious, FreeS/WAN has serious issues! Being at war with the
kernel routing machinery, for example.
Alright, I give you that. But it works.
--
Please do
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1155 +0200]:
Me too - if we have to have significantly modified kernels, they should
be labelled as being such.
They are - look at the last part of the kernel-image-KVERS image.
So 2.4.22-686 indicates a 2.5 IPsec backport?
Reality
also sprach Osamu Aoki [EMAIL PROTECTED] [2003.09.22.0026 +0200]:
Can your patch file to be more modular like X package? It is
a big chunk.
This would be a solution, but it would be an ugly solution. I still
don't believe that the grsecurity patch should have to unpatch even
parts of
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1207 +0200]:
Let's create a package called linux-2.4.22 or
linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which
does exactly this.
I oppose. Let's get rid of kernel-{source,image,etc.} and provide
linux-kernel-*. Then
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.22.1331 +0200]:
It is unacceptable for us to distribute kernels with known
(security) bugs.
It is unacceptable for us to backport features alongside security
patches. From http://www.debian.org/security/faq:
The most important guideline when
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.27.1253 +0200]:
There is no good reason for the
grsec patch to require a vanilla kernel tree, merely one that is
slightly less patched than the current Debian one.
There is a good reason why grsec can require a kernel source that is
2.4.22
On Mon, Oct 06, 2003 at 09:45:13PM +0200, martin f krafft wrote:
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.22.1331 +0200]:
It is unacceptable for us to distribute kernels with known
(security) bugs.
It is unacceptable for us to backport features alongside security
patches. From
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]:
Well, what you seem to want is to have the kernel source avaliable
in a format that makes packaging kernel patches easy. That seems
like a different issue to me.
No, this is the issue. I want the kernel sources to be what they
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.24.2214 +0200]:
make-kpkg and kernel-patches/modules work just fine with vanilla
sources.
Except with --initrd.
I never need initrd if I make my own kernels.
--
Please do not CC me when replying to lists; I read them!
.''`.
also sprach Greg Folkert [EMAIL PROTECTED] [2003.09.28.0209 +0200]:
Would that then allow you to NOT include it in the kernel-source
package, but then make it a standard patch to be installed by default
then? And have a Variable NO_IPSEC_PATCH or something similar so that
kpkg doesn't apply
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0510 +0200]:
For example, the grsecurity patch has had a history of conflicts
with various patches in the Debian kernel source. Most of those
patches that caused conflicts were in fact essential security
fixes. You can review this for
also sprach [EMAIL PROTECTED] [EMAIL PROTECTED] [2003.09.28.0605 +0200]:
That has more to do with the fact that grsecurity is an intrusive
pile of garbage,
I'd appreciate if you kept your opinions to yourself, or state them
in a less aggressive fashion.
Look, it's that simple - authors of
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.29.0232 +0200]:
Hear, hear. IPsec in particular is long overdue in the Linux
kernel and I am glad to see it.
It has existed in the freeswan patch for a while!
--
Please do not CC me when replying to lists; I read them!
.''`. martin
also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]:
I beg your pardon? Why do you believe that the _stable
distribution security FAQ_ is relevant to this argument?
Because it is the only thing I could find that reflects Debian's
take on security fixes: feature backports
also sprach martin f krafft [EMAIL PROTECTED] [2003.09.30.1016 +0200]:
How do y'all suggest we continue on this, because apparently there
are two camps with different opinions, Herbert doesn't think he
needs to do anything, and this issue will just die without a change
happening. I think we
On Mon, Oct 06, 2003 at 10:41:47PM +0200, martin f krafft wrote:
also sprach martin f krafft [2003.09.30.1016 +0200]:
How do y'all suggest we continue on this, because apparently there
are two camps with different opinions, Herbert doesn't think he
needs to do anything, and this issue will
On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote:
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]:
Well, what you seem to want is to have the kernel source avaliable
in a format that makes packaging kernel patches easy. That seems
like a different issue to
On Mon, Oct 06, 2003 at 10:32:20PM +0200, martin f krafft wrote:
also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]:
I beg your pardon? Why do you believe that the _stable
distribution security FAQ_ is relevant to this argument?
Because it is the only thing I could
On Tue, Oct 07, 2003 at 12:30:45AM +0200, Oliver Kurth wrote:
On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote:
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]:
Well, what you seem to want is to have the kernel source avaliable
in a format that makes
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote:
Because it is the only thing I could find that reflects Debian's
take on security fixes: feature backports are to be avoided.
That's because it's the position of the *Security Team*, and is
certainly not binding on other
On Mon, Oct 06, 2003 at 06:04:45PM -0500, Steve Langasek wrote:
On Tue, Oct 07, 2003 at 12:30:45AM +0200, Oliver Kurth wrote:
On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote:
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]:
Well, what you seem to want is
On 2003-10-06, Adam McKenna [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote:
Because it is the only thing I could find that reflects Debian's
take on security fixes: feature backports are to be avoided.
That's because it's the position of the
On Mon, Oct 06, 2003 at 03:58:07PM -0700, Adam McKenna wrote:
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote:
Because it is the only thing I could find that reflects Debian's
take on security fixes: feature backports are to be avoided.
That's because it's the position of
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote:
On Mon, Oct 06, 2003 at 10:32:20PM +0200, martin f krafft wrote:
also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]:
I beg your pardon? Why do you believe that the _stable
distribution security FAQ_ is
* Herbert Xu
| Very few people really need cramfs if they're building custom kernels.
| This is because initrd only makes sense when you're building for a
| large number of machines. If you're building a custom kernel, just
| compile in all the drivers you need for mounting root and that's
Tollef Fog Heen [EMAIL PROTECTED] wrote:
* Herbert Xu
| Very few people really need cramfs if they're building custom kernels.
| This is because initrd only makes sense when you're building for a
| large number of machines. If you're building a custom kernel, just
| compile in all the
Hi, thanks the good maintenance by Herbert,
On Sun, Sep 28, 2003 at 08:12:43AM +1000, Herbert Xu wrote:
Andreas Metzler [EMAIL PROTECTED] wrote:
martin f krafft [EMAIL PROTECTED] wrote:
What I'd really like to hear is a reaction from Herbert to:
Osamu Aoki [EMAIL PROTECTED] in [EMAIL
Osamu Aoki [EMAIL PROTECTED] wrote:
2) I was not suggesting very fine grained modular patch for each issues.
I was expecting something like 3-4 stage patches.
* 1st big patch: cramfs etc. which are essential to be Debian kernel
* 2nd big patch: basic bug fixes. (No feature
also sprach Adam Borowski [EMAIL PROTECTED] [2003.09.28.0744 +0200]:
Well... as 2.6 is coming out really soon, ipsec is in a lot better
position than grsec. Also, you will _have_ to port grsec to 2.6 (or
abandon it), and 2.6 will have ipsec in the upstream sources. The only
difference
On Sun, 28 Sep 2003 20:32:36 -0400, Matt Zimmerman [EMAIL PROTECTED]
wrote:
Hear, hear. IPsec in particular is long overdue in the Linux kernel and I
am glad to see it.
Please note that the 2.6 ipsec is unuseable. You can't filter traffic
that goes into or comes from a tunnel. That's a killer.
Marc Haber [EMAIL PROTECTED] wrote:
Please note that the 2.6 ipsec is unuseable. You can't filter traffic
that goes into or comes from a tunnel. That's a killer.
That's not true. Filtering for tunnels works just fine.
Transport mode filtering is indeed not supported. But you can achieve
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0012 +0200]:
As I have said before, kernel-source's primary purpose is for
building default Debian kernel images. Thus it should contain all
the patches necessary so that the images are uniform across
architectures.
IPsec is not necessary.
On Mon, Sep 29, 2003 at 11:06:00PM +0200, martin f krafft wrote:
Nowhere else does Debian have feature backports,
That's not true. Feature backports are occasionally incidental in, e.g,
XFree86 package updates when snatching a newer version of a driver for
its bugfixes, and the code has changed
On Sun, Sep 28, 2003 at 01:10:27PM +1000, Herbert Xu wrote:
I do not believe that this patch has caused excessive grief for the
benefits that it brings. In fact, conflicts between the Debian kernel
source and random kernel patches floating around are a fact of life.
For example, the
On Sat, 27 Sep 2003, George Danchev wrote:
Why not? It's a package. We modify it as we need to in order to provide
functionality and satisfy the needs of our users. I'm perfectly willing
to bet that more of our users are interested in a functional ipsec stack
than are interested in the
On Sat, 2003-09-27 at 23:10, Herbert Xu wrote:
Greg Folkert [EMAIL PROTECTED] wrote:
So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
is the rational that they *REQUIRE* that piece.
As for the criteria for inclusion, I have already outlined some simple
rules
On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote:
Yes but those criterion fail to mention why it is required in the Debian
Kernel Source. I understand it should be in the default Binary images...
but as for inclusion into the default source, still begs the question
_why_ is it required, as
On Sun, Sep 28, 2003 at 06:08:45PM +0200, Marco d'Itri wrote:
On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote:
Yes but those criterion fail to mention why it is required in the Debian
Kernel Source. I understand it should be in the default Binary images...
but as for inclusion into the
On Sun, 2003-09-28 at 12:08, Marco d'Itri wrote:
On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote:
Yes but those criterion fail to mention why it is required in the Debian
Kernel Source. I understand it should be in the default Binary images..
On Wed, 24 Sep 2003 16:14:03 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
On Mon, Sep 22, 2003 at 08:03:50PM +0200, martin f krafft wrote:
also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]:
However, they might be useful to people using make-kpkg and patch
packages to get
On Wed, Sep 24, 2003 at 04:47:13PM -0500, Chad Walstrom wrote:
Doesn't this have to do with the cramfs patch?
Man, this is quite the delay. I guess that's what I get for
misconfiguring my email server with the wrong origin setting. ;-)
--
Chad Walstrom [EMAIL PROTECTED]
martin f krafft [EMAIL PROTECTED] wrote:
This thread has been going on for a while, and I think the general
voice has been that security backports and other vital patches are
totally alright for kernel-source. However, I think the general
agreement is that feature backports are not okay.
On Thursday 25 September 2003 01:44, Matthew Garrett wrote:
martin f krafft wrote:
also sprach Matthew Garrett [EMAIL PROTECTED]
[2003.09.22.1=
320 +0200]:
It would be inappropriate to do it within a stable release, sure,
but it is something that Debian do do in general. In this case
Le Mardi 23 Septembre 2003 18:21, Steve Greenland a écrit :
On 22-Sep-03, 14:14 (CDT), Florian Weimer [EMAIL PROTECTED] wrote:
It's a well accepted fact among kernel developers that vanilla
kernel.org kernels should not be used by end users. Debian has to
patch the kernel, too. There
George Danchev wrote:
Do you really know how many kernel-patches as debian packages are
broken because of they expext to patch the vanilla 2.4.22 tree.
That's the crux of the matter. The current situation is broken because
it makes it difficult to add extra patches to the kernel-source package
Andreas Metzler [EMAIL PROTECTED] wrote:
martin f krafft [EMAIL PROTECTED] wrote:
This thread has been going on for a while, and I think the general
voice has been that security backports and other vital patches are
totally alright for kernel-source. However, I think the general
agreement is
On Sat, 2003-09-27 at 18:12, Herbert Xu wrote:
Andreas Metzler [EMAIL PROTECTED] wrote:
martin f krafft [EMAIL PROTECTED] wrote:
This thread has been going on for a while, and I think the general
voice has been that security backports and other vital patches are
totally alright for
On Fri, Sep 26, 2003 at 08:08:39AM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
I ran it through diffstat, and removed the files which are created entirely
by
the patch, so these are the changes to common code:
I've had a look and it appears to be acceptable.
Greg Folkert [EMAIL PROTECTED] wrote:
So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
is the rational that they *REQUIRE* that piece.
As the current maintainer of kernel-source, I decide which patches
are included per default. The individual architecture maintainers
martin f krafft wrote:
MFK make-kpkg and kernel-patches/modules work just fine with vanilla
MFK sources.
Matt Zimmerman wrote:
MDZ Except with --initrd.
Doesn't this have to do with the cramfs patch? Wasn't this patch
rejected by Linus for some reason? IIRC, the cramfs patch is something
very
martin f krafft wrote:
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.22.1=
320 +0200]:
It would be inappropriate to do it within a stable release, sure,
but it is something that Debian do do in general. In this case
it's a chunk of code that has almost nothing to do with the core
Chris Cheney [EMAIL PROTECTED] wrote:
Is there a particular reason we are distributing old kernels at all? I
see the following in the archive:
They're needed by non-i386 architectures. Once a kernel-source is no
longer used by any architecture, it can be removed from Debian.
BTW -
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.25.0044 +0200]:
I'm perfectly willing to bet that more of our users are interested
in a functional ipsec stack than are interested in the grsecurity
patch.
I am not opposing having a patch provide that stack.
it's a chunk of code that
Matt Zimmerman [EMAIL PROTECTED] wrote:
I ran it through diffstat, and removed the files which are created entirely by
the patch, so these are the changes to common code:
I've had a look and it appears to be acceptable. Please file a bug
report against kernel and I'll probably include it
This thread has been going on for a while, and I think the general
voice has been that security backports and other vital patches are
totally alright for kernel-source. However, I think the general
agreement is that feature backports are not okay. That's what
kernel-patches are for.
I would like
On Mon, 22 Sep 2003 22:04:15 +0200
martin f krafft [EMAIL PROTECTED] wrote:
I'd appreciate if you would not quote me on a mailing list without
my consent. Anyhow...
also sprach Florian Weimer [EMAIL PROTECTED] [2003.09.22.2114 +0200]:
It's a well accepted fact among kernel developers that
On 22-Sep-03, 14:14 (CDT), Florian Weimer [EMAIL PROTECTED] wrote:
It's a well accepted fact among kernel developers that vanilla
kernel.org kernels should not be used by end users. Debian has to patch
the kernel, too. There isn't much choice.
Agreed, but there's a significant difference
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote:
George Danchev [EMAIL PROTECTED] wrote:
it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is
useless,
leave to users to patch if they want) then all other
kernel-patch-whatever
packages will be fine.
It
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1155 +0200]:
And if you meant the kernel-source package, then please think
twice before you request a such thing. Your idea would require
dozens of versions of kernel-source-NUMBER-foo every time when
I a small fix had to be applied.
Why?
also sprach Bernhard R. Link [EMAIL PROTECTED] [2003.09.22.1213 +0200]:
Thus I see absolutely no reason, why I should want
a debian-package with a unmodified source-tree.
Because
-- it may be on a CD and you cannot download 25+ Mb
-- your kernel source is integrated with the Debian package
also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]:
However, they might be useful to people using make-kpkg and patch
packages to get the right dependencies and ease the download. Thus
I would not vote to throw them out completely.
make-kpkg and kernel-patches/modules work just
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.22.1320 +0200]:
It would be inappropriate to do it within a stable release, sure,
but it is something that Debian do do in general. In this case
it's a chunk of code that has almost nothing to do with the core
kernel code - it just so
On Mon, Sep 22, 2003 at 08:03:50PM +0200, martin f krafft wrote:
also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]:
However, they might be useful to people using make-kpkg and patch
packages to get the right dependencies and ease the download. Thus
I would not vote to throw
On Mon, Sep 22, 2003 at 07:52:40PM +0200, Domenico Andreoli wrote:
sorry for the profane question, is IPsec related to any security issue
in 2.4.2x kernels? i don't care about IPsec, i don't either know what
it really is and i'm having problems with it. is there a way to throw
away it without
Hi, Herbert Xu wrote:
George Danchev [EMAIL PROTECTED] wrote:
it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless,
leave to users to patch if they want) then all other kernel-patch-whatever
packages will be fine.
It is unacceptable for us to distribute kernels
I'd appreciate if you would not quote me on a mailing list without
my consent. Anyhow...
also sprach Florian Weimer [EMAIL PROTECTED] [2003.09.22.2114 +0200]:
It's a well accepted fact among kernel developers that vanilla
kernel.org kernels should not be used by end users.
Could you point me
George Danchev wrote:
On Monday 22 September 2003 14:20, Matthew Garrett wrote:
It would be inappropriate to do it within a stable release, sure, but it
is something that Debian do do in general.
Then all kernel-source-x.y.z prepared like this kernel-source-2.4.22 2.4.22-1
will never be
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote:
George Danchev [EMAIL PROTECTED] wrote:
it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is
useless,
leave to users to patch if they want) then all other
kernel-patch-whatever
packages will be fine.
It
David Z Maze [EMAIL PROTECTED] wrote:
...do you include *everything* that comes by you that meets these
criteria? Because from this it sounds like anything that has an
upstream that can be built as modules would be included. My
particular directed thought right now is a somewhat invasive
Matt Zimmerman [EMAIL PROTECTED] wrote:
OK, these are very minimal criteria, and I think that probably many of the
kernel-patch packages in Debian would fit them. Where would you draw the
line?
Most of them fail the maintainence check.
Unless the patch is clearly going to be merged
On Tue, Sep 23, 2003 at 08:08:07AM +1000, Herbert Xu wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
I currently patch my kernels with device-mapper, a few evms-related patches
and skas3. It would be very convenient if device-mapper and the evms
patches could be included in the the stock
On Sunday 21 September 2003 14:41, Herbert Xu wrote:
martin f krafft [EMAIL PROTECTED] wrote:
I am the kernel-patch-2.4-grsecurity maintainer, and I have been
flooded with grave and important bugs ever since kernel version
2.4.20, since grsecurity does not apply to these kernel versions
On Sunday 21 September 2003 16:04, Josip Rodin wrote:
On Sun, Sep 21, 2003 at 02:44:03PM +0200, martin f krafft wrote:
* The vanilla kernel source is readily available:
I don't consider this readily available. It's faster to just
download it from kernel.org.
Frankly, I doubt that.
Hi!
Am 2003-09-21 13:09 +0200 schrieb martin f krafft:
If I install kernel-source-2.4.21, I want the 2.4.21 kernel source,
I don't want the 2.4.21 kernel source with 2.5's IPsec stack patched
in and hundreds of little fixes.
I fully agree with this.
Speaking as an user, it is perfectly okay
On Sun, Sep 21, 2003 at 05:05:46PM +0200, martin f krafft wrote:
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.21.1644 +0200]:
effects (better hardware support, more features, better
performance or what have we) are generally seen to be worthwhile.
... in addition to possibly more bugs
On Sun, Sep 21, 2003 at 12:00:05PM -0700, Erik Steffl wrote:
if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as
a debian package, not something else... any debian specific changes
should result in kernel name change, that's what's expected in kernel
world (when I get ac
* Martin Pitt [EMAIL PROTECTED] [030922 10:40]:
Speaking as an user, it is perfectly okay and desirable to have a
_default_ installation Debian kernel which is patched (security, ALSA,
whatever). Those users who don't care or don't know about kernel
compiling issues will rest in peace and
Hi!
Am 2003-09-22 12:13 +0200 schrieb Bernhard R. Link:
Speaking as a user, too, I want something I can compile a kernel from.
I'm no kernel hacker and do not intend to become one. Thus I see
absolutely no reason, why I should want a debian-package with a
unmodified source-tree.
I agree. I
hi,
On Mon, Sep 22, 2003 at 12:13:51PM +0200, Bernhard R. Link wrote:
Speaking as a user, too, I want something I can compile a kernel from.
I'm no kernel hacker and do not intend to become one. Thus I see
absolutely no reason, why I should want a debian-package with a
unmodified source-tree.
#include hallo.h
* George Danchev [Mon, Sep 22 2003, 10:40:10AM]:
This is misleading by the way of kernel source tree you provide.
kernel-source-2.4.22 must contain just plain vanilla kernel sources + debian/
directory. Then if I want your backported patches (or anything else) I'll
#include hallo.h
* Jonathan Dowland [Mon, Sep 22 2003, 10:05:13AM]:
if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as
a debian package, not something else... any debian specific changes
should result in kernel name change, that's what's expected in kernel
world
On Monday 22 September 2003 13:13, Bernhard R. Link wrote:
* Martin Pitt [EMAIL PROTECTED] [030922 10:40]:
Speaking as an user, it is perfectly okay and desirable to have a
_default_ installation Debian kernel which is patched (security, ALSA,
whatever). Those users who don't care or don't
Hi!
Am 2003-09-22 11:55 +0200 schrieb Eduard Bloch:
significantly modified; why aren't those modifications distributed as
seperate kernel patches / debian packages in the same way grsec is?
Martin can _simply_ create an alternative apply script which unpatches
the Debian source when
martin f krafft wrote:
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.21.1=
614 +0200]:
Should we stop shipping security fixes backported from development
code?
It always depends, doesn't it? We are backporting *security* fixes
to packages, but we take care not to introduce new
1 - 100 of 132 matches
Mail list logo
