On Mon, Aug 27, 2007 at 04:14:35PM -0400, [EMAIL PROTECTED] wrote:
> I notice there is a source package for the kernel and a package of debian
> patches. Has the kernel source already been patched or would one need to
> patch it with all of the included debian patches when building
I notice there is a source package for the kernel and a package of
debian patches. Has the kernel source already been patched or would
one need to patch it with all of the included debian patches when
building a custom kernel?
"Everything should be made as simple as possible, bu
On Wed, Dec 03, 2003 at 05:38:11PM -0500, Nathanael Nerode wrote:
> The security advisory does not mention these (the current 2.4.x kernels
> available in sarge), and the upstream fix is apparently not until 2.4.23.
No offense... but (a) why would the DSA mention Sarge, and (b) isn't it
obvious th
The security advisory does not mention these (the current 2.4.x kernels
available in sarge), and the upstream fix is apparently not until 2.4.23.
Can we get an announcement as to the safety of these Debian packages?
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
. there should be a kernel-source-linux/bsd/hurd/whatever-version
package that it the upstreams pure vanilla source.
2. Each architecture and debian in general should have a patches
relative to that and metapackages to provide a kernel tree. Thats
already there for most archs (all but 2 afaik).
3
Bao C. Ha <[EMAIL PROTECTED]> wrote:
>
> If I want both the freeswan module capability and IPVS, how should
> I proceed.
If all you need is to run freeswan, then you can unapply the IPSEC patch,
and simply use KLIPS.
If you need the new stack, then you will need to fix the conflicts.
It should
George Danchev <[EMAIL PROTECTED]> wrote:
>
> Sorry but this is not true and your documentation is misleading ! You have
> already known that your ipsec patch can't even be unapplied cleanly, and it
> is documented for kernel-source-2.4.22-2 in #213987... This is not
t; > You can either use a vanilla kernel, or unapply the IPSEC patch as
> > documented in the README.Debian file.
Sorry but this is not true and your documentation is misleading ! You have
already known that your ipsec patch can't even be unapplied cleanly, and it
is documented for
applied by default in the debian kernel? Asking
> users to unapply a patch that shouldn't be in the stable kernel in the
> first place is unacceptable. Telling them to use the "vanilla kernel"
> makes them lose the security updates, the only ones that should be
> applied
On Mon, Oct 06, 2003 at 07:12:03PM +1000, Herbert Xu wrote:
Hi Herbet,
If I want both the freeswan module capability and IPVS, how should
I proceed.
Thanks.
Bao
> Bao C. Ha <[EMAIL PROTECTED]> wrote:
> >
> > I am trying to patch the kernel 2.4.22 and got into troubles. It seems
> > that the
ipsec patch applied by default in the debian kernel? Asking
users to unapply a patch that shouldn't be in the stable kernel in the
first place is unacceptable. Telling them to use the "vanilla kernel"
makes them lose the security updates, the only ones that should be
applied to debian
Bao C. Ha <[EMAIL PROTECTED]> wrote:
>
> I am trying to patch the kernel 2.4.22 and got into troubles. It seems
> that the Debian kernel has been patched to do away the pmtu field of
> the struct dst_entry (include/net/dst.h).
>
> Any sugegstions on how to get it working again. The last working
Hello all,
I am trying to patch the kernel 2.4.22 and got into troubles. It seems
that the Debian kernel has been patched to do away the pmtu field of
the struct dst_entry (include/net/dst.h).
Any sugegstions on how to get it working again. The last working Debian
kernel with IPVS is 2.4.20.
#include
* martin f krafft [Mon, Sep 22 2003, 08:03:18PM]:
> This is a good point. Debian makes an effort to be kernel
> independent, so why does the kernel-source install Linux?
>
> I think we should rename to linux-kernel-source, linux-kernel-image
> and so on...
Good point.
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 Wed, Sep 24, 2003 at 01:56:09PM -0500, Ryan Underwood wrote:
>
> Hi,
>
> On Mon, Sep 22, 2003 at 08:03:18PM +0200, martin f krafft wrote:
> >
> > This is a good point. Debian makes an effort to be kernel
> > independent, so why does the kernel-source install Lin
Hi,
On Mon, Sep 22, 2003 at 08:03:18PM +0200, martin f krafft wrote:
>
> This is a good point. Debian makes an effort to be kernel
> independent, so why does the kernel-source install Linux?
>
> I think we should rename to linux-kernel-source, linux-kernel-image
> and so
ore of an
> > issue than having "-debian" in it...
>
> This is a good point. Debian makes an effort to be kernel
> independent, so why does the kernel-source install Linux?
>
> I think we should rename to linux-kernel-source, linux-kernel-image
> and so on...
A
point. Debian makes an effort to be kernel
independent, so why does the kernel-source install Linux?
I think we should rename to linux-kernel-source, linux-kernel-image
and so on...
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <[EMAIL PROTECTED
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 implem
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
>>
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
> > /usr/share/doc/kernel-ima
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
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 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
ice if Joey could summarize
again, I don't read d-d very often.
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 patc
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
--
l
a build problem is solved is nothing compared to the time between 2
kernel releases. And it is a worthwile loss if we don't have anymore
issues with modules being out of sync.
> In the long term, we should have as few binary module packages as
> possible. They should either be inte
> may be more of an incentive to upgrade than just an outdated
> kernel-source package.
>
> That does not mean the user will rebuild his kernel at once with the
> new patch, but well, I don't think we can do much more here :)
I like the idea... And maybe we should alert the user that
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 possi
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
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
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
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 appl
-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, ...
>
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 ch
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 the kernel-source package thinking that
> > it contained all th
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
debian
> > patch.
>
> Yes, but then the problem is that unsuspecting users could be
> building kernels using the kernel-source package thinking that
> it contained all the security fixes.
Have it depend on a kernel-source-security-fixes or something
such ? And have make-kpkg issue
building kernels using the kernel-source package thinking that
it contained all the security fixes.
I believe that distributing a binary package that may contain
known security problems is a very serious problem.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~
Yann Dirson <[EMAIL PROTECTED]> wrote:
>
> 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 proven deficient in some way, but I probably missed many
> things - I am even under the impression the
-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 suppo
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
>
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
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 shou
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
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
package
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 n
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
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. Arc
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 g
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.
>
lished both this diff alone as well as the combined patch.
The trouble was that the sid kernel-source included Alan's patch
while the woody kernel-source didn't (it does now), so now you
could no longer use kernel-patch-s390 from one tree for the other.
> > When building kernel-imag
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.
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 p
On Sun, May 25, 2003 at 07:33:04PM +1000, Herbert Xu wrote:
> Anthony Towns 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 c
Anthony Towns 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 upload
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. Ju
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.
> >
>
kernel-i386_2.4.21-3_i386.dsc:
Build-Depends: linus-kernel (=2.4.21),
pcmcia-source, alsa-modules-source
Binaries: kernel-image-2.4.21, pcmcia-modules-2.4.21,
alsa-modules-2.4.21
Having kernel modules associated with th
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
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 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. S
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 ker
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-sp
,s390,s390x,ia64 but their kernel also has patches
> > for sparc,sparc64,mips and m68k although I can't guarantee that these
> > really work in the relased tree (but last time I visted their office
> > people were playing with those ports in their spare time).
SuSE don'
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
> >
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,
> >
vulnerabilities (for example)? How can we track when this has happened
> > when there are so many different patches?
> The situation won't change much over the current one. You currently can't
> be sure that an arch doesn't back out security fixes in our kernel-source
>
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 infor
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
as to how it can work:
>>
>> 1. The architectures should be treated as independent packages.
>
> 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 ar
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
> ma
transition problem :(
>
> The problem here is when architecture specific patches require patches to
> core
> code. If we have a single kernel source tree that everyone commits to then
> it will be changing daily, it will be difficult to determine what source was
> used to compile a
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 applyin
re are so
> many different patches?
The situation won't change much over the current one. You currently
can't be sure that an arch doesn't back out security fixes in our
kernel-source with it's kernel-patch diff (intentionally or not).
Herbert did a great job of keeping the ker
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 po
If we have a single kernel source tree that everyone commits to then
it will be changing daily, it will be difficult to determine what source was
used to compile a particular kernel (and getting two kernels compiled from
the same source will be a neat trick).
I think that the thing to do is t
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
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 applyin
can work:
>
> 1. The architectures should be treated as independent packages.
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.
> We should not be shy of releasing DSA
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
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, a
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 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 applyin
rchitecture
> > tree that you're interested in, and then wiggle it into applying to the
> > kernel source package that comes with Debian. It's not all that hard,
> > and there's a number of tools to help you (dirdiff, for instance; but
> > all I ever use is diff, pa
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
> > k
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 applyin
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
&g
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
> intr
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 b
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- packages is such a
> > pain
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- packages is such a
> pain is the asymmetry between i386 and other arches - almost every time
> a new ker
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 cal
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 maintai
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 see
ain is going well, when that is
sorted out I'll have a lot more spare time for such things.
> I have to admit, that having several architectures use the same plain
> kernel source from Linus Torvalds aka kernel.org could be problematic
> since many architecture ports use their own ker
al versions of kernel source in
> > each architecture, they are also different for most architectures.
> > Only mips and mipsel share the same kernel source.
> >
> > To make it worse, there are also third party kernel modules that
> > depend on a particular version
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 a
1 - 100 of 135 matches
Mail list logo
