From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 17 Feb 2005 - 17:36:28 GMT
On Thu, Feb 17, 2005 at 12:18:31PM -0500, Stephen Frost wrote:
> * Herbert Poetzl (herbert_at_13thfloor.at) wrote:
> > On Thu, Feb 17, 2005 at 02:23:00PM +0100, Lars E. D. Jensen wrote:
> > > > > patching file mm/mmap.c
> > > > > Hunk #3 FAILED at 1353.
> > > > > Hunk #4 FAILED at 1368.
> > > > > Hunk #5 FAILED at 1418.
> > > > > Hunk #6 FAILED at 1434.
> > > > > Hunk #7 succeeded at 1573 (offset 31 lines).
> > > > > Hunk #8 succeeded at 1813 (offset 31 lines).
> > > > > Hunk #9 succeeded at 1842 (offset 37 lines).
> > > > > Hunk #10 succeeded at 1871 (offset 37 lines).
> > > > > Hunk #11 succeeded at 1907 (offset 37 lines).
> > > > > 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej
>
> This isn't hard to fix. There was just a little rework of a couple
> functions in mmap.c. I can create a patch if you need it for
> debian+vserver.
>
> > > > yes, the patch-2.6.10-vs1.9.4.diff is for vanilla kernels
> > > > (from kernel.org) which should work quite fine with debian
> > > > but I'm sure somebody has already adapted the patch for
> > > > the debian source (which is probably more like 2.6.11-rc*)
> > >
> > > I think I'll stick to the vanilla kernel.
> > >
> > a good choice IMHO, because:
>
> Actually, a bad choice.
well _in your opinion_ that is ;)
> > - mainline (vanilla) kernels get more testing
>
> But continue to have bugs in them, hope you're not doing much 'net
> traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling
> RST packets, as in, it doesn't handle them well and your conntrack table
> will get filled up. This is fixed in the Debian kernels.
it is also fixed in the prepatches for the stable
kernel release (2.6.11-rc4)
> The Debian kernels also get a fair bit of testing themselves, I don't
> know if it's more than vanilla kernels or not, but it's probably less
> than RedHat kernels.
nobody said that debian kernels are untested, and
maybe they get more testing than the mainline kernels
but for sure more feedback happens on lkml for mainline
than for debian ... no?
> > - linux-vserver patches for vanilla kernels get more testing
> > - issues and bugs are easier resolved with more feedback
>
> Debian's kernel team is actually rather responsive to handling bugs and
> getting updates into their kernels to fix the problems in the vanilla
> kernels (of which there's been more and more lately...).
which isn't the point here, as I was talking about
linux-vserver issues and bugs, which AFAIK are not
resolved by Debian's kernel team but by the linux-
vserver's kernel team ;)
anyway, I never did and never will disencourage
anybody willing to provide quality support for some
distribution or spezialized patchset, on the contrary
I'll support anybody doing so, as best as I can, and
you should know that by now ;)
best,
Herbert
> > > > > I know there's a kernel-patch-ctx for Debian, but this is only 1.29
> > > > > vserver patch.
> > > >
> > > > please file a request to the debian maintainer(s) ...
> > >
> > > I've read in another thread that the reason why the 1.9.x branch
> > > isn't in the unstable/testing Debian yet... is that it's still
> > > in development.
> >
> > well, then maybe the debian very-unstable/development-testing branch
> > would fit better (no idea what the debian policies are ;)
>
> The issue with this is that Debian is looking to release and things in
> unstable migrate to testing and then eventually will be released with
> stable. unstable isn't really a whole seperate tree in that sense, at
> least, not right now. After stable is released it'll go back to being
> the latest-greatest that compiles and works after a cursory test.
>
> > > But the someone in that thread also said that a "kernel patch"
> > > might not apply to normal Debian policy very good, which I
> > > partly agree with.
> >
> > I cannot comment on that, but it might be true, of course ...
>
> In general the vserver patches actually work pretty well against the
> Debian kernel patches, it all just depends on what's changeing in each
> patch. Considering the sizes of the patches I'd say it's pretty good
> that there was only one reject, and that wasn't hard to fix anyway.
>
> Stephen
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver