From: Adrian Bunk <bunk@stusta.de>
To: Christian Hesse <mail@earthworm.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Kernel .patches support
Date: Sat, 25 Jun 2005 00:31:15 +0200 [thread overview]
Message-ID: <20050624223115.GL6656@stusta.de> (raw)
In-Reply-To: <200506242303.17813.mail@earthworm.de>
On Fri, Jun 24, 2005 at 11:03:17PM +0200, Christian Hesse wrote:
> On Friday 24 June 2005 09:36, Adrian Bunk wrote:
> > On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > > Hi everybody,
> > >
> > > every time I apply a patch to my kernel tree I (or my scripts) make an
> > >
> > > echo $PATCHNAME $PATCHVERSION >> .patches
> > >
> > > This patch makes the file accessible via /proc/patches.gz. I think this
> > > can be handy if you want to know what patches you (or your distributor)
> > > applied to your running kernel...
> > >...
> > > Let me know what you think.
> >
> > To be honest, I'm not a fan of it.
> >
> > If e.g. looking at a Debian kernel source that has 289 different patches
> > with names like tty-locking-fixes7 applied, you'll see that this often
> > won't give you much valuable information.
>
> You can search Debian lists, archives, ... for "tty-locking-fixes7". After
> that you probably know what the fix is good for.
The _only_ Google hit for "tty-locking-fixes7" isn't very helpful.
I could simply download the source package for the kernel...
> On the other hand if there is a security fix in a Debian list you can check if
> your kernel is patched by running "zcat /proc/patches.gz | grep
> security-fix-foo-bar".
"zless /usr/share/doc/<pkgname>/Debian.src.changelog.gz" already gives
you the same information plus information about the contents of the
patches including CAN references and bug numbers.
> > You'd need an uniform naming convention for patches across
> > distributions, and I don't think such things are worth the effort.
>
> If a distribution has a naming convention for itself this patch can already be
> useful I think. Even without it can be.
If you are building your own kernel, you have to manually check that you
don't forget to add every patch you apply to .patches .
In a distribution, the information is already present at better places.
> Christian
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
prev parent reply other threads:[~2005-06-24 22:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-23 21:58 [PATCH] Kernel .patches support Christian Hesse
2005-06-23 22:38 ` Karim Yaghmour
2005-06-24 6:02 ` Ian Campbell
2005-06-24 7:36 ` Adrian Bunk
2005-06-24 8:57 ` Coywolf Qi Hunt
2005-06-24 20:48 ` Christian Hesse
2005-06-24 21:03 ` Christian Hesse
2005-06-24 22:31 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050624223115.GL6656@stusta.de \
--to=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@earthworm.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox