using bug reports on vendor kernels

using bug reports on vendor kernels

[Oliver Neukum]

Hi,

is there a site that would allow me to browse a list of patches added to 
vendor kernels (esp. RedHat). I need this to use an oops supplied by a user.

	TIA
		Oliver

Re: using bug reports on vendor kernels

[arjan]

In article <01080923020201.04501@idun> you wrote:

> is there a site that would allow me to browse a list of patches added to 
> vendor kernels (esp. RedHat). I need this to use an oops supplied by a user.

I mostly documented the patches in the Red Hat Linux 7.1 default kernel
(2.4.2-2) at

http://people.redhat.com/arjanv/patches.html

But as this was a fair amount of work which nobody seemed to want, I haven't
actually finished nor done the same for later released kernels....

Greetings,
  Arjan van de Ven

Re: using bug reports on vendor kernels

[Andreas Dilger]

Oliver writes:
> is there a site that would allow me to browse a list of patches added to 
> vendor kernels (esp. RedHat). I need this to use an oops supplied by a user.

You _should_ be able to simply get the RedHat source RPM, and have a look
at the various patches that are applied to the base Linus kernel.  At least
that is how the Turbolinux and SuSE kernels are built (haven't looked
at a RedHat kernel in a while, but I expect the same).  Granted, some
of the patch names are not exactly self explanitory (e.g. jumbo patches
like -ac or -aa, which have their own documentation somewhere, often l-k).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: using bug reports on vendor kernels

[Bill Rugolsky Jr.]

On Thu, Aug 09, 2001 at 10:15:08PM +0100, arjan@fenrus.demon.nl wrote:
> In article <01080923020201.04501@idun> you wrote:
> 
> > is there a site that would allow me to browse a list of patches added to 
> > vendor kernels (esp. RedHat). I need this to use an oops supplied by a user.
> 
> I mostly documented the patches in the Red Hat Linux 7.1 default kernel
> (2.4.2-2) at
> 
> http://people.redhat.com/arjanv/patches.html
> 
> But as this was a fair amount of work which nobody seemed to want, I haven't
> actually finished nor done the same for later released kernels....
 
The real question is why not include the documentation with the patch?
As Linus will probably tell you, patch is pretty smart about stripping out stray
commentary, e.g.,

	patch -p1 < ~/mail/apply

Regards,

  Bill Rugolsky

Re: using bug reports on vendor kernels

[Oliver Neukum]

Am Donnerstag,  9. August 2001 23:31 schrieben Sie:
> Oliver writes:
> > is there a site that would allow me to browse a list of patches added to
> > vendor kernels (esp. RedHat). I need this to use an oops supplied by a
> > user.
>
> You _should_ be able to simply get the RedHat source RPM, and have a look
> at the various patches that are applied to the base Linus kernel.  At least
> that is how the Turbolinux and SuSE kernels are built (haven't looked
> at a RedHat kernel in a while, but I expect the same).  Granted, some
> of the patch names are not exactly self explanitory (e.g. jumbo patches
> like -ac or -aa, which have their own documentation somewhere, often l-k).

It might do so. However the speed of my internet connectivity would make this 
a very, very slow task.
And the day after having completed that I'd be bound to get a bug report from 
a Mandrake user.

	Regards
		Oliver

Re: using bug reports on vendor kernels

[Arjan van de Ven]

On Thu, Aug 09, 2001 at 05:34:59PM -0400, Bill Rugolsky Jr. wrote:

> The real question is why not include the documentation with the patch?
> As Linus will probably tell you, patch is pretty smart about stripping out stray
> commentary, e.g.,
> 
> 	patch -p1 < ~/mail/apply
> 

Doesn't help the people who don't want to look at all the patches but just
want an overview.... and the spec file where the patches are applied does
have (mostly 1 liners) documentation.

Re: using bug reports on vendor kernels

[Bill Rugolsky Jr.]

On Thu, Aug 09, 2001 at 10:46:35PM +0100, Arjan van de Ven wrote:
> On Thu, Aug 09, 2001 at 05:34:59PM -0400, Bill Rugolsky Jr. wrote:
> 
> > The real question is why not include the documentation with the patch?
> > As Linus will probably tell you, patch is pretty smart about stripping out stray
> > commentary, e.g.,
> > 
> > 	patch -p1 < ~/mail/apply
> > 
> 
> Doesn't help the people who don't want to look at all the patches but just
> want an overview.... and the spec file where the patches are applied does
> have (mostly 1 liners) documentation.

Well, my point is that the person creating the patch or adding it to the kernel
should document it, thereby distributing the work.  If formatted as a standard
header, one could pull it all out with a favorite text processing tool,
sed ... perl, and put it in a file, in say
/usr/share/doc/kernel*/rh-patch-descriptions. :-)

Regards,

   Bill Rugolsky

Re: using bug reports on vendor kernels

[Bill Rugolsky Jr.]

On Thu, Aug 09, 2001 at 11:42:38PM +0200, Oliver Neukum wrote:
> It might do so. However the speed of my internet connectivity would make this 
> a very, very slow task.
> And the day after having completed that I'd be bound to get a bug report from 
> a Mandrake user.

It sounds like you want an {ftp,http,...} server that allows you to
look transparently into archives like zip, tar, cpio, rpm, etc.
Do any of the standard ones do this?  (ftp certainly can *create* .tar.)

Just don't ask for it in the kernel ...

   [ducks under desk :-)]

Regards,

   Bill Rugolsky

Re: using bug reports on vendor kernels

[Ignacio Vazquez-Abrams]

On Thu, 9 Aug 2001, Oliver Neukum wrote:

> Hi,
>
> is there a site that would allow me to browse a list of patches added to
> vendor kernels (esp. RedHat). I need this to use an oops supplied by a user.
>
> 	TIA
> 		Oliver

All of Red Hat's kernel SRPMs are available via FTP from ftp.redhat.com.
Basically they start with a stock kernel, add a decent -acXX, apply
vendor-specific drivers, and then any cleanups that exist or they wrote.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: using bug reports on vendor kernels

[Ville Herva]

On Thu, Aug 09, 2001 at 10:46:35PM +0100, you [Arjan van de Ven] claimed:
> On Thu, Aug 09, 2001 at 05:34:59PM -0400, Bill Rugolsky Jr. wrote:
> 
> > The real question is why not include the documentation with the patch?
> > As Linus will probably tell you, patch is pretty smart about stripping out stray
> > commentary, e.g.,
> > 
> > 	patch -p1 < ~/mail/apply
> > 
> 
> Doesn't help the people who don't want to look at all the patches but just
> want an overview.... and the spec file where the patches are applied does
> have (mostly 1 liners) documentation.

I proposed this before, but what about having one standard PATCHES file in
the kernel source tree, with all the applied pathes would touch\x7f

After having built a kernel, I could come back after months and see at one
glance what patches I (or somebody else) had applied and in what order.

Something like

cat PATCHES
+++++++++++++++++
patch: ac5
summary: Alan Cox kernel patch collection
url: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.2
date: 05.04.2001
email: laughing@shared-source.org
+++++++++++++++++
patch: ide-04052001
summary: Hedrick IDE patch
url: ftp://ftp.kernel.org/pub/linux/kernel/people/hedrick/2.2
date: 05.04.2001
email: andre@linux-ide.org
+++++++++++++++++
patch: proconfig
summary: /proc .config support
url:  http://www.it.uc3m.es/~ptb/proconfig/
date: 06.08.2000
email: ptb@it.uc3m.es

etc etc. Every applied patch would append its info to that file. I'm not
sure, though, how that could be accomplished with patch, but if anything
else fails, PATCHES/-directory might do the job. Although then you lose the
apply order information.

And the compiled kernel could automagically have 
2.2.18-ac5+ide-04052001+proconfig suffix (if that's feasible - it could
become quite long.)


-- v --

v@iki.fi

Re: using bug reports on vendor kernels

[Chmouel Boudjnah]

Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de> writes:

> It might do so. However the speed of my internet connectivity would make this 
> a very, very slow task.
> And the day after having completed that I'd be bound to get a bug report from 
> a Mandrake user.

https://kenobi.mandrakesoft.com/cgi-bin/viewcvs.cgi/SPECS/kernel/