Re: Old ipw2200 code in 2.6.13-git3 and 2.6.13-mm1
On Fri, Sep 02, 2005 at 08:48:28PM -0700, Miles Lane wrote: [snip] > Can we please get the latest IPW2200 code into the development kernels soon? Seconded. I haven't rebuilt the 1.0.6 code against the 2.6.13-git kernels, but my 2.6.13-rc4 build with 1.0.6 ipw2200 in it seems much more stable and dependable at starting up a network than 2.6.13-git-current does. (For example, I had to do a full power-cycle to get things working again after I ran into a "failed to send TX_POWER" issue - I've never seen that before, but I've never run the 1.0.0 driver before today.) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Old ipw2200 code in 2.6.13-git3 and 2.6.13-mm1
On Fri, Sep 02, 2005 at 08:48:28PM -0700, Miles Lane wrote: [snip] Can we please get the latest IPW2200 code into the development kernels soon? Seconded. I haven't rebuilt the 1.0.6 code against the 2.6.13-git kernels, but my 2.6.13-rc4 build with 1.0.6 ipw2200 in it seems much more stable and dependable at starting up a network than 2.6.13-git-current does. (For example, I had to do a full power-cycle to get things working again after I ran into a failed to send TX_POWER issue - I've never seen that before, but I've never run the 1.0.0 driver before today.) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays where rc4-mm1 works fine.
On Mon, Aug 15, 2005 at 08:50:12AM -0700, Linus Torvalds wrote:
> > Is there any way to make git tell exactly where between rc4 and rc5
> > each kernel is, so I can name the bzimages accordingly?
>
> You'd have to use the raw commit names, since these things don't have any
> symbolic names. You can get that by just doing
>
> cat .git/HEAD
>
> which will give you a 40-character hex string (representing the 160-bit
> SHA1 of the top commit). Not very readable, but it's unique, and if you
> report that hex string to other git users, they can trivially recreate the
> tree you have.
The following patch (which Sam has in the kbuild tree for 2.6.14, IIRC)
will make that automatic, or you can just do:
ln -s .git/HEAD localversion-git
(My patch will notice when you are at a tag and not append anything
special in thaat case.)
Index: linux-git/Makefile
===
--- linux-git.orig/Makefile 2005-07-31 04:30:00.0 -0400
+++ linux-git/Makefile 2005-07-31 04:32:16.0 -0400
@@ -551,6 +551,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a git TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# git/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only git is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: linux-git/init/Kconfig
===
--- linux-git.orig/init/Kconfig 2005-07-31 04:30:00.0 -0400
+++ linux-git/init/Kconfig 2005-07-31 04:32:16.0 -0400
@@ -77,6 +77,22 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for git tags that
+ belong to the current top of tree revision.
+
+ A string of the format -g will be added to the localversion
+ if a git based tree is found. The string generated by this will be
+ appended after any matching localversion* files, and after the value
+ set in CONFIG_LOCALVERSION
+
+ Note: This requires Perl, and a git repository, but not necessarily
+ the git or cogito tools to be installed.
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
Index: linux-git/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-git/scripts/setlocalversion 2005-07-31 04:32:16.0 -0400
@@ -0,0 +1,56 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[EMAIL PROTECTED]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print <
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+chdir($srctree);
+
+my @LOCALVERSIONS = ();
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+# Git/Cogito store the top-of-tree "commit" in .git/HEAD
+# A list of known tags sits in .git/refs/tags/
+#
+# The simple trick here is to just compare the two of these, and if we get a
+# match, return nothing, otherwise, return a subset of the SHA-1 hash in
+# .git/HEAD
+
+sub do_git_checks {
+ open(H,"<.git/HEAD") or return;
+ my $head = ;
+ chomp $head;
+ close(H);
+
+ opendir(D,".git/refs/tags") or return;
+ foreach my $tagfile (grep !/^\.{1,2}$/, readdir(D)) {
+ open(F,"<.git/refs/tags/" . $tagfile) or return;
+ my $tag = ;
+
Re: rc6 keeps hanging and blanking displays where rc4-mm1 works fine.
On Mon, Aug 15, 2005 at 08:50:12AM -0700, Linus Torvalds wrote:
Is there any way to make git tell exactly where between rc4 and rc5
each kernel is, so I can name the bzimages accordingly?
You'd have to use the raw commit names, since these things don't have any
symbolic names. You can get that by just doing
cat .git/HEAD
which will give you a 40-character hex string (representing the 160-bit
SHA1 of the top commit). Not very readable, but it's unique, and if you
report that hex string to other git users, they can trivially recreate the
tree you have.
The following patch (which Sam has in the kbuild tree for 2.6.14, IIRC)
will make that automatic, or you can just do:
ln -s .git/HEAD localversion-git
(My patch will notice when you are at a tag and not append anything
special in thaat case.)
Index: linux-git/Makefile
===
--- linux-git.orig/Makefile 2005-07-31 04:30:00.0 -0400
+++ linux-git/Makefile 2005-07-31 04:32:16.0 -0400
@@ -551,6 +551,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a git TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# git/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only git is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: linux-git/init/Kconfig
===
--- linux-git.orig/init/Kconfig 2005-07-31 04:30:00.0 -0400
+++ linux-git/init/Kconfig 2005-07-31 04:32:16.0 -0400
@@ -77,6 +77,22 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool Automatically append version information to the version string
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for git tags that
+ belong to the current top of tree revision.
+
+ A string of the format -g will be added to the localversion
+ if a git based tree is found. The string generated by this will be
+ appended after any matching localversion* files, and after the value
+ set in CONFIG_LOCALVERSION
+
+ Note: This requires Perl, and a git repository, but not necessarily
+ the git or cogito tools to be installed.
+
config SWAP
bool Support for paging of anonymous memory (swap)
depends on MMU
Index: linux-git/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-git/scripts/setlocalversion 2005-07-31 04:32:16.0 -0400
@@ -0,0 +1,56 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson [EMAIL PROTECTED] GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print EOT;
+Usage: setlocalversion srctree
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+chdir($srctree);
+
+my @LOCALVERSIONS = ();
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+# Git/Cogito store the top-of-tree commit in .git/HEAD
+# A list of known tags sits in .git/refs/tags/
+#
+# The simple trick here is to just compare the two of these, and if we get a
+# match, return nothing, otherwise, return a subset of the SHA-1 hash in
+# .git/HEAD
+
+sub do_git_checks {
+ open(H,.git/HEAD) or return;
+ my $head = H;
+ chomp $head;
+ close(H);
+
+ opendir(D,.git/refs/tags) or return;
+ foreach my $tagfile (grep !/^\.{1,2}$/, readdir(D)) {
+ open(F,.git/refs/tags/ . $tagfile) or return;
+ my $tag = F;
+ chomp $tag;
+ close(F);
+ return if ($tag eq $head);
+ }
+ closedir(D
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Nyberg wrote:
> (akpm: a fix for this needs to go into 2.6.13, inotify + nfs
> trivially oopses otherwise, even if inotify isn't actively used)
This patch seems to have fixed it for me.
I upgraded to fdbd22dad31982b64a4e663fd056a8a7cfac9607 and applied this
patch on top of it, and I can't retrigger the oops. (It seemed rather
easy to hit on the other kernel)
So, I guess:
Seems-to-fix-it: Ryan Anderson <[EMAIL PROTECTED]>
> It looks like the following sequence is done in the wrong order.
> When vfs_unlink() is called from sys_unlink() it has taken a ref
> on the inode and sys_unlink() does the last iput() but when called
> from other callsites vfs_unlink() might do the last iput() and
> free inode, so inotify_inode_queue_event() will receive an already
> freed object and dereference an already freed object.
>
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
>
> Index: mm/fs/namei.c
> ===
> --- mm.orig/fs/namei.c2005-08-07 12:06:16.0 +0200
> +++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
> @@ -1869,8 +1869,8 @@
> /* We don't d_delete() NFS sillyrenamed files--they still exist. */
> if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
> struct inode *inode = dentry->d_inode;
> - d_delete(dentry);
> fsnotify_unlink(dentry, inode, dir);
> + d_delete(dentry);
> }
>
> return error;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9pgyfhVDhkBuUKURAjbSAKCavd7s4zdk/uce1TZ0CX018RGRmgCfXWFI
XjAPhBcEoLyJDWnjk9oI+XI=
=NMc4
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
(Snipping the oops down a bit in size) On Sun, Aug 07, 2005 at 07:08:05PM +0200, Alexander Nyberg wrote: > On Sat, Aug 06, 2005 at 11:56:30PM -0400 Ryan Anderson wrote: > > Unable to handle kernel paging request at virtual address 6b6b6b6b > > EIP is at inotify_inode_queue_event+0x55/0x150 > > Call Trace: > > [vfs_unlink+358/560] vfs_unlink+0x166/0x230 > > [pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd] > > [pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd] > > [pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd] > > [pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd] > > [pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd] > > [pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd] > > [svc_authenticate+112/336] svc_authenticate+0x70/0x150 > > [svc_process+960/1648] svc_process+0x3c0/0x670 > > [pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd] > > [ret_from_fork+6/20] ret_from_fork+0x6/0x14 > > [pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd] > > [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 > > (the long-aged vfs veteran steps into the picture...) > > It looks like the following sequence is done in the wrong order. > When vfs_unlink() is called from sys_unlink() it has taken a ref > on the inode and sys_unlink() does the last iput() but when called > from other callsites vfs_unlink() might do the last iput() > > Can you reproduce with this patch? It should happen with some nfs > activity, I'll try to set up a scenario myself. I'll try after I get a new hard drive in and let the RAID rebuild. It seems like a very big coincidence that this happened *right* as a drive was failing though - or is that just a bizarre coincidence? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
(Snipping the oops down a bit in size) On Sun, Aug 07, 2005 at 07:08:05PM +0200, Alexander Nyberg wrote: On Sat, Aug 06, 2005 at 11:56:30PM -0400 Ryan Anderson wrote: Unable to handle kernel paging request at virtual address 6b6b6b6b EIP is at inotify_inode_queue_event+0x55/0x150 Call Trace: [vfs_unlink+358/560] vfs_unlink+0x166/0x230 [pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd] [pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd] [pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd] [pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd] [pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd] [pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd] [svc_authenticate+112/336] svc_authenticate+0x70/0x150 [svc_process+960/1648] svc_process+0x3c0/0x670 [pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd] [ret_from_fork+6/20] ret_from_fork+0x6/0x14 [pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd] [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 (the long-aged vfs veteran steps into the picture...) It looks like the following sequence is done in the wrong order. When vfs_unlink() is called from sys_unlink() it has taken a ref on the inode and sys_unlink() does the last iput() but when called from other callsites vfs_unlink() might do the last iput() Can you reproduce with this patch? It should happen with some nfs activity, I'll try to set up a scenario myself. I'll try after I get a new hard drive in and let the RAID rebuild. It seems like a very big coincidence that this happened *right* as a drive was failing though - or is that just a bizarre coincidence? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Nyberg wrote:
(akpm: a fix for this needs to go into 2.6.13, inotify + nfs
trivially oopses otherwise, even if inotify isn't actively used)
This patch seems to have fixed it for me.
I upgraded to fdbd22dad31982b64a4e663fd056a8a7cfac9607 and applied this
patch on top of it, and I can't retrigger the oops. (It seemed rather
easy to hit on the other kernel)
So, I guess:
Seems-to-fix-it: Ryan Anderson [EMAIL PROTECTED]
It looks like the following sequence is done in the wrong order.
When vfs_unlink() is called from sys_unlink() it has taken a ref
on the inode and sys_unlink() does the last iput() but when called
from other callsites vfs_unlink() might do the last iput() and
free inode, so inotify_inode_queue_event() will receive an already
freed object and dereference an already freed object.
Signed-off-by: Alexander Nyberg [EMAIL PROTECTED]
Index: mm/fs/namei.c
===
--- mm.orig/fs/namei.c2005-08-07 12:06:16.0 +0200
+++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
@@ -1869,8 +1869,8 @@
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
if (!error !(dentry-d_flags DCACHE_NFSFS_RENAMED)) {
struct inode *inode = dentry-d_inode;
- d_delete(dentry);
fsnotify_unlink(dentry, inode, dir);
+ d_delete(dentry);
}
return error;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9pgyfhVDhkBuUKURAjbSAKCavd7s4zdk/uce1TZ0CX018RGRmgCfXWFI
XjAPhBcEoLyJDWnjk9oI+XI=
=NMc4
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcapatcch equivalent?
On Fri, Aug 05, 2005 at 03:10:17PM -0700, Andrew Morton wrote: > I do this, which mostly works: > > MERGE_BASE=$(git-merge-base $(cat .git/refs/heads/origin ) \ > $(cat .git/refs/heads/$patch_name)) > > cg-diff -r $MERGE_BASE:$(cat .git/refs/heads/$patch_name) >> \ > $PULL/$patch_name.patch > > (I'm supposed to be doing real git merges of 40 trees and let git do more > work for me. I'll do that when I'm feeling really, really trusting). Would something like this make you more comfortable? You get one repository per tree, but hardlinked objects so space shouldn't be an issue... and each one works "normally". All you need to do is setup "origin" as the Linus's tree, then clone each of the other repositories you want to track, then run this script. (You *may* want to clone Linus's tree, then edit .git/branches/origin in each of the sub-trees to save a lot of network bandwidth, but it shouldn't matter, as the git relink will get you to about the same state after the first run anyway.) == #!/bin/sh repos="agpgart cpufreq net-2.6 sparc-2.6" rm -rf merged git clone -l origin merged for i in $repos ; do echo "../$i" > "merged/.git/branches/$i" ; done git relink agpgart/ cpufreq/ net-2.6/ sparc-2.6/ merged/ origin/ ( cd origin ; git pull origin ) for i in $repos ; do ( cd "$i" git pull origin ) done cd merged mkdir -p .git/refs/merge-points/ for i in $repos ; do cat .git/HEAD > ".git/refs/merge-points/pre-$i" git pull "$i" # Note, this should trigger off an error return from git pull # Unfortunately, git pull always returns an error, so it doesn't # work quite perfectly - hence this being unconditional. echo "Please fix up the merge if necessary, commit it, and exit this subshell." sh cat .git/HEAD > ".git/refs/merge-points/post-$i" git diff $(cat .git/refs/merge-points/pre-$i)..$(cat .git/refs/merge-points/post-$i) > "../$i.patch" done -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcapatcch equivalent?
On Fri, Aug 05, 2005 at 03:10:17PM -0700, Andrew Morton wrote: I do this, which mostly works: MERGE_BASE=$(git-merge-base $(cat .git/refs/heads/origin ) \ $(cat .git/refs/heads/$patch_name)) cg-diff -r $MERGE_BASE:$(cat .git/refs/heads/$patch_name) \ $PULL/$patch_name.patch (I'm supposed to be doing real git merges of 40 trees and let git do more work for me. I'll do that when I'm feeling really, really trusting). Would something like this make you more comfortable? You get one repository per tree, but hardlinked objects so space shouldn't be an issue... and each one works normally. All you need to do is setup origin as the Linus's tree, then clone each of the other repositories you want to track, then run this script. (You *may* want to clone Linus's tree, then edit .git/branches/origin in each of the sub-trees to save a lot of network bandwidth, but it shouldn't matter, as the git relink will get you to about the same state after the first run anyway.) == #!/bin/sh repos=agpgart cpufreq net-2.6 sparc-2.6 rm -rf merged git clone -l origin merged for i in $repos ; do echo ../$i merged/.git/branches/$i ; done git relink agpgart/ cpufreq/ net-2.6/ sparc-2.6/ merged/ origin/ ( cd origin ; git pull origin ) for i in $repos ; do ( cd $i git pull origin ) done cd merged mkdir -p .git/refs/merge-points/ for i in $repos ; do cat .git/HEAD .git/refs/merge-points/pre-$i git pull $i # Note, this should trigger off an error return from git pull # Unfortunately, git pull always returns an error, so it doesn't # work quite perfectly - hence this being unconditional. echo Please fix up the merge if necessary, commit it, and exit this subshell. sh cat .git/HEAD .git/refs/merge-points/post-$i git diff $(cat .git/refs/merge-points/pre-$i)..$(cat .git/refs/merge-points/post-$i) ../$i.patch done -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Support UML and make O= when building Debian packages
Support UML builds and make O= when building Debian packages.
Sam, I'm pretty sure I've sent this before, but it seems to have been
dropped. I've been using this for a while to build my personal kernels,
and haven't had any problems. This is a combination of old patches.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index: linux-git/scripts/package/builddeb
===
--- linux-git.orig/scripts/package/builddeb 2005-07-16 01:35:52.0
-0400
+++ linux-git/scripts/package/builddeb 2005-07-16 01:38:22.0 -0400
@@ -14,18 +14,37 @@ set -e
# Some variables and settings used throughout the script
version=$KERNELRELEASE
tmpdir="$objtree/debian/tmp"
+packagename=linux-$version
+
+if [ "$ARCH" == "um" ] ; then
+ packagename=user-mode-linux-$version
+fi
# Setup the directory structure
rm -rf "$tmpdir"
mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot"
+if [ "$ARCH" == "um" ] ; then
+ mkdir -p "$tmpdir/usr/lib/uml/modules/$version"
"$tmpdir/usr/share/doc/$packagename" "$tmpdir/usr/bin"
+fi
# Build and install the kernel
-cp System.map "$tmpdir/boot/System.map-$version"
-cp .config "$tmpdir/boot/config-$version"
-cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
+if [ "$ARCH" == "um" ] ; then
+ cp System.map "$tmpdir/usr/lib/uml/modules/$version/System.map"
+ cp .config "$tmpdir/usr/share/doc/$packagename/config"
+ gzip "$tmpdir/usr/share/doc/$packagename/config"
+ cp $KBUILD_IMAGE "$tmpdir/usr/bin/linux-$version"
+else
+ cp System.map "$tmpdir/boot/System.map-$version"
+ cp .config "$tmpdir/boot/config-$version"
+ cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
+fi
if grep -q '^CONFIG_MODULES=y' .config ; then
- INSTALL_MOD_PATH="$tmpdir" make modules_install
+ INSTALL_MOD_PATH="$tmpdir" make KBUILD_SRC= modules_install
+ if [ "$ARCH" == "um" ] ; then
+ mv "$tmpdir/lib/modules/$version"/*
"$tmpdir/usr/lib/uml/modules/$version/"
+ rmdir "$tmpdir/lib/modules/$version"
+ fi
fi
# Install the maintainer scripts
@@ -53,6 +72,8 @@ linux ($version) unstable; urgency=low
EOF
# Generate a control file
+if [ "$ARCH" == "um" ]; then
+
cat < debian/control
Source: linux
Section: base
@@ -60,12 +81,34 @@ Priority: optional
Maintainer: $name
Standards-Version: 3.6.1
-Package: linux-$version
+Package: $packagename
+Architecture: any
+Description: User Mode Linux kernel, version $version
+ User-mode Linux is a port of the Linux kernel to its own system call
+ interface. It provides a kind of virtual machine, which runs Linux
+ as a user process under another Linux kernel. This is useful for
+ kernel development, sandboxes, jails, experimentation, and
+ many other things.
+ .
+ This package contains the Linux kernel, modules and corresponding other
+ files version $version
+EOF
+
+else
+cat < debian/control
+Source: linux
+Section: base
+Priority: optional
+Maintainer: $name
+Standards-Version: 3.6.1
+
+Package: $packagename
Architecture: any
Description: Linux kernel, version $version
This package contains the Linux kernel, modules and corresponding other
- files version $version.
+ files version $version
EOF
+fi
# Fix some ownership and permissions
chown -R root:root "$tmpdir"
Index: linux-git/scripts/package/Makefile
===
--- linux-git.orig/scripts/package/Makefile 2005-07-16 01:35:52.0
-0400
+++ linux-git/scripts/package/Makefile 2005-07-16 01:38:22.0 -0400
@@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s
$(CONFIG_SHELL) $(MKSPEC) prebuilt > $@
binrpm-pkg: $(objtree)/binkernel.spec
- $(MAKE)
+ $(MAKE) KBUILD_SRC=
set -e; \
$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
set -e; \
@@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec
#
.PHONY: deb-pkg
deb-pkg:
- $(MAKE)
+ $(MAKE) KBUILD_SRC=
$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
clean-dirs += $(objtree)/debian/
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Support UML and make O= when building Debian packages
Support UML builds and make O= when building Debian packages. Sam, I'm pretty sure I've sent this before, but it seems to have been dropped. I've been using this for a while to build my personal kernels, and haven't had any problems. This is a combination of old patches. Signed-Off-By: Ryan Anderson [EMAIL PROTECTED] Index: linux-git/scripts/package/builddeb === --- linux-git.orig/scripts/package/builddeb 2005-07-16 01:35:52.0 -0400 +++ linux-git/scripts/package/builddeb 2005-07-16 01:38:22.0 -0400 @@ -14,18 +14,37 @@ set -e # Some variables and settings used throughout the script version=$KERNELRELEASE tmpdir=$objtree/debian/tmp +packagename=linux-$version + +if [ $ARCH == um ] ; then + packagename=user-mode-linux-$version +fi # Setup the directory structure rm -rf $tmpdir mkdir -p $tmpdir/DEBIAN $tmpdir/lib $tmpdir/boot +if [ $ARCH == um ] ; then + mkdir -p $tmpdir/usr/lib/uml/modules/$version $tmpdir/usr/share/doc/$packagename $tmpdir/usr/bin +fi # Build and install the kernel -cp System.map $tmpdir/boot/System.map-$version -cp .config $tmpdir/boot/config-$version -cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +if [ $ARCH == um ] ; then + cp System.map $tmpdir/usr/lib/uml/modules/$version/System.map + cp .config $tmpdir/usr/share/doc/$packagename/config + gzip $tmpdir/usr/share/doc/$packagename/config + cp $KBUILD_IMAGE $tmpdir/usr/bin/linux-$version +else + cp System.map $tmpdir/boot/System.map-$version + cp .config $tmpdir/boot/config-$version + cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +fi if grep -q '^CONFIG_MODULES=y' .config ; then - INSTALL_MOD_PATH=$tmpdir make modules_install + INSTALL_MOD_PATH=$tmpdir make KBUILD_SRC= modules_install + if [ $ARCH == um ] ; then + mv $tmpdir/lib/modules/$version/* $tmpdir/usr/lib/uml/modules/$version/ + rmdir $tmpdir/lib/modules/$version + fi fi # Install the maintainer scripts @@ -53,6 +72,8 @@ linux ($version) unstable; urgency=low EOF # Generate a control file +if [ $ARCH == um ]; then + cat EOF debian/control Source: linux Section: base @@ -60,12 +81,34 @@ Priority: optional Maintainer: $name Standards-Version: 3.6.1 -Package: linux-$version +Package: $packagename +Architecture: any +Description: User Mode Linux kernel, version $version + User-mode Linux is a port of the Linux kernel to its own system call + interface. It provides a kind of virtual machine, which runs Linux + as a user process under another Linux kernel. This is useful for + kernel development, sandboxes, jails, experimentation, and + many other things. + . + This package contains the Linux kernel, modules and corresponding other + files version $version +EOF + +else +cat EOF debian/control +Source: linux +Section: base +Priority: optional +Maintainer: $name +Standards-Version: 3.6.1 + +Package: $packagename Architecture: any Description: Linux kernel, version $version This package contains the Linux kernel, modules and corresponding other - files version $version. + files version $version EOF +fi # Fix some ownership and permissions chown -R root:root $tmpdir Index: linux-git/scripts/package/Makefile === --- linux-git.orig/scripts/package/Makefile 2005-07-16 01:35:52.0 -0400 +++ linux-git/scripts/package/Makefile 2005-07-16 01:38:22.0 -0400 @@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s $(CONFIG_SHELL) $(MKSPEC) prebuilt $@ binrpm-pkg: $(objtree)/binkernel.spec - $(MAKE) + $(MAKE) KBUILD_SRC= set -e; \ $(CONFIG_SHELL) $(srctree)/scripts/mkversion $(objtree)/.tmp_version set -e; \ @@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec # .PHONY: deb-pkg deb-pkg: - $(MAKE) + $(MAKE) KBUILD_SRC= $(CONFIG_SHELL) $(srctree)/scripts/package/builddeb clean-dirs += $(objtree)/debian/ -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New SCM and commit list
On Sun, Apr 10, 2005 at 11:15:20PM -0700, Linus Torvalds wrote: > On Mon, 11 Apr 2005, Jeff Garzik wrote: > > > But I hope that I can get non-conflicting merges done fairly soon, and > > > maybe I can con James or Jeff or somebody to try out GIT then... > > > > I don't mind being a guinea pig as long as someone else does the hard > > work of finding a new way to merge :) > > So I can tell you what merges are going to be like, just to prepare you. > > First, the good news: I think we can make the workflow look like bk, ie > pretty much like "git pull" and "git push". And for well-behaved stuff > (ie minimal changes to the same files on both sides) it will even be fast. > I think. If you can stick something meaningful in a simple text file, overwritten after each merge completes, similar to the BitKeeper/csets-in file, it should be trivial to write a wrapper for the basic merge tool that calls a trigger after each merge and uses csets-in to generate diffs and email them out. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New SCM and commit list
On Sun, Apr 10, 2005 at 11:15:20PM -0700, Linus Torvalds wrote: On Mon, 11 Apr 2005, Jeff Garzik wrote: But I hope that I can get non-conflicting merges done fairly soon, and maybe I can con James or Jeff or somebody to try out GIT then... I don't mind being a guinea pig as long as someone else does the hard work of finding a new way to merge :) So I can tell you what merges are going to be like, just to prepare you. First, the good news: I think we can make the workflow look like bk, ie pretty much like git pull and git push. And for well-behaved stuff (ie minimal changes to the same files on both sides) it will even be fast. I think. If you can stick something meaningful in a simple text file, overwritten after each merge completes, similar to the BitKeeper/csets-in file, it should be trivial to write a wrapper for the basic merge tool that calls a trigger after each merge and uses csets-in to generate diffs and email them out. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [03/08] fix ia64 syscall auditing
On Tue, Apr 05, 2005 at 01:49:18PM -0700, Greg KH wrote: > On Tue, 2005-04-05 at 13:27 -0700, David Mosberger wrote: > > >>>>> On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said: > > > > Greg> -stable review patch. If anyone has any objections, please > > Greg> let us know. > > > > Nitpick: the patch introduces trailing whitespace. > > Sorry about that, I've removed it from the patch now. > > > Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-) > > Because some of us use vim and ":set list" to see it, when we remember > to... :) Try adding this to your .vimrc: highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/ Then you'll have to resist the urge to fix whitespace issues instead of not seeing them at all. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [03/08] fix ia64 syscall auditing
On Tue, Apr 05, 2005 at 01:49:18PM -0700, Greg KH wrote: On Tue, 2005-04-05 at 13:27 -0700, David Mosberger wrote: On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH [EMAIL PROTECTED] said: Greg -stable review patch. If anyone has any objections, please Greg let us know. Nitpick: the patch introduces trailing whitespace. Sorry about that, I've removed it from the patch now. Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-) Because some of us use vim and :set list to see it, when we remember to... :) Try adding this to your .vimrc: highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/ Then you'll have to resist the urge to fix whitespace issues instead of not seeing them at all. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Automatically append a semi-random version for BK users
Sam, my patch to automatically include a random value based upon the
BitKeeper or CVS version in the kernel version had one, rather minor,
bug related to building in seperate object and source trees.
This patch fixes that up.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index: local-quilt/scripts/setlocalversion
===
--- local-quilt.orig/scripts/setlocalversion2005-04-02 18:29:21.0
-0500
+++ local-quilt/scripts/setlocalversion 2005-04-02 18:29:54.0 -0500
@@ -14,6 +14,7 @@ EOT
}
my ($srctree) = @ARGV;
+chdir($srctree);
my @LOCALVERSIONS = ();
@@ -39,7 +40,6 @@ my @LOCALVERSIONS = ();
# -BK and the above 8 characters to the end of the version.
sub do_bk_checks {
- chdir($srctree);
my $changeset = `bk changes -r+ -k`;
chomp $changeset; # strip trailing \n safely
my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
@@ -69,7 +69,6 @@ sub do_bk_checks {
# On this check, there is no real need for a MD5 hash, so
# the revision number is used directly.
sub do_cvs_checks {
- chdir($srctree);
my $status = `LANG=C cvs status -v ChangeSet`;
my @lines = split /\n/, $status;
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Automatically append a semi-random version for BK users
Sam, my patch to automatically include a random value based upon the
BitKeeper or CVS version in the kernel version had one, rather minor,
bug related to building in seperate object and source trees.
This patch fixes that up.
Signed-Off-By: Ryan Anderson [EMAIL PROTECTED]
Index: local-quilt/scripts/setlocalversion
===
--- local-quilt.orig/scripts/setlocalversion2005-04-02 18:29:21.0
-0500
+++ local-quilt/scripts/setlocalversion 2005-04-02 18:29:54.0 -0500
@@ -14,6 +14,7 @@ EOT
}
my ($srctree) = @ARGV;
+chdir($srctree);
my @LOCALVERSIONS = ();
@@ -39,7 +40,6 @@ my @LOCALVERSIONS = ();
# -BK and the above 8 characters to the end of the version.
sub do_bk_checks {
- chdir($srctree);
my $changeset = `bk changes -r+ -k`;
chomp $changeset; # strip trailing \n safely
my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
@@ -69,7 +69,6 @@ sub do_bk_checks {
# On this check, there is no real need for a MD5 hash, so
# the revision number is used directly.
sub do_cvs_checks {
- chdir($srctree);
my $status = `LANG=C cvs status -v ChangeSet`;
my @lines = split /\n/, $status;
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
On Sat, Mar 26, 2005 at 01:27:53AM -0800, Chris Wright wrote: > > Could you please add CAN IDs to the stable changelog for already assigned > > vulnerabilities? > > That's what I did for .5 -> .6. We can't retroactively update changeset > comments, and I'm not sure we have any other candidates in -stable. > We'll certainly continue to add them as we have them. bk helptool comments You can, actually. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
On Sat, Mar 26, 2005 at 01:27:53AM -0800, Chris Wright wrote: Could you please add CAN IDs to the stable changelog for already assigned vulnerabilities? That's what I did for .5 - .6. We can't retroactively update changeset comments, and I'm not sure we have any other candidates in -stable. We'll certainly continue to add them as we have them. bk helptool comments You can, actually. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories
On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote: > I had a similar problem building binrpm-pkg. > Try following patch. It worked for me. My problem wasn't actually resolved by this - the make in builddeb still caused issues. So, a normal, unified diff form of the patch, fixed up, is attached. Signed-off-By: Ryan Anderson <[EMAIL PROTECTED]> Index: local-quilt/scripts/package/Makefile === --- local-quilt.orig/scripts/package/Makefile 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/Makefile2005-03-19 19:25:06.0 -0500 @@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s $(CONFIG_SHELL) $(MKSPEC) prebuilt > $@ binrpm-pkg: $(objtree)/binkernel.spec - $(MAKE) + $(MAKE) KBUILD_SRC= set -e; \ $(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version set -e; \ @@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec # .PHONY: deb-pkg deb-pkg: - $(MAKE) + $(MAKE) KBUILD_SRC= $(CONFIG_SHELL) $(srctree)/scripts/package/builddeb clean-dirs += $(objtree)/debian/ Index: local-quilt/scripts/package/builddeb === --- local-quilt.orig/scripts/package/builddeb 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/builddeb2005-03-19 19:25:27.0 -0500 @@ -25,7 +25,7 @@ cp .config "$tmpdir/boot/config-$version cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version" if grep -q '^CONFIG_MODULES=y' .config ; then - INSTALL_MOD_PATH="$tmpdir" make modules_install + INSTALL_MOD_PATH="$tmpdir" make KBUILD_SRC= modules_install fi # Install the maintainer scripts -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories
On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote: I had a similar problem building binrpm-pkg. Try following patch. It worked for me. My problem wasn't actually resolved by this - the make in builddeb still caused issues. So, a normal, unified diff form of the patch, fixed up, is attached. Signed-off-By: Ryan Anderson [EMAIL PROTECTED] Index: local-quilt/scripts/package/Makefile === --- local-quilt.orig/scripts/package/Makefile 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/Makefile2005-03-19 19:25:06.0 -0500 @@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s $(CONFIG_SHELL) $(MKSPEC) prebuilt $@ binrpm-pkg: $(objtree)/binkernel.spec - $(MAKE) + $(MAKE) KBUILD_SRC= set -e; \ $(CONFIG_SHELL) $(srctree)/scripts/mkversion $(objtree)/.tmp_version set -e; \ @@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec # .PHONY: deb-pkg deb-pkg: - $(MAKE) + $(MAKE) KBUILD_SRC= $(CONFIG_SHELL) $(srctree)/scripts/package/builddeb clean-dirs += $(objtree)/debian/ Index: local-quilt/scripts/package/builddeb === --- local-quilt.orig/scripts/package/builddeb 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/builddeb2005-03-19 19:25:27.0 -0500 @@ -25,7 +25,7 @@ cp .config $tmpdir/boot/config-$version cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version if grep -q '^CONFIG_MODULES=y' .config ; then - INSTALL_MOD_PATH=$tmpdir make modules_install + INSTALL_MOD_PATH=$tmpdir make KBUILD_SRC= modules_install fi # Install the maintainer scripts -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Automatically append a semi-random version for BK users
Sam, this version includes the CVS portion.
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper or CVS and CONFIG_LOCALVERSION_AUTO is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
This currently supports BitKeeper and CVS (assuming the format is the
same as the BK->CVS tree)
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index: local-quilt/Makefile
===
--- local-quilt.orig/Makefile 2005-03-14 20:53:59.0 -0500
+++ local-quilt/Makefile2005-03-14 20:54:02.0 -0500
@@ -549,6 +549,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a BitKeeper, or other SCM, TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# BitKeeper/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only BitKeeper is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: local-quilt/init/Kconfig
===
--- local-quilt.orig/init/Kconfig 2005-03-14 20:53:59.0 -0500
+++ local-quilt/init/Kconfig2005-03-17 23:49:44.0 -0500
@@ -69,6 +69,24 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper or CVS tags that
+ belong to the current top of tree revision.
+
+ A string of the format -BK will be added to the localversion
+ if a BitKeeper based tree is found. The string -cvs-$version will be
+ added to the localversion if a CVS tree based on the BK->CVS tree is
+ found. The string generated by this will be appended after any
+ matching localversion* files, and after the value set in
+ CONFIG_LOCALVERSION
+
+ Note: This requires Perl and the Digest::MD5 module, as well
+ as BitKeeper and/or CVS.
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
Index: local-quilt/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ local-quilt/scripts/setlocalversion 2005-03-17 23:02:02.0 -0500
@@ -0,0 +1,120 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[EMAIL PROTECTED]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print <
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+#
+# The process is as follows:
+#
+# 1. Get the key of the top of tree changeset:
+# cset=`bk changes -r+ -k`
+#This will be something like:
+#[EMAIL PROTECTED]|ChangeSet|20050314010036|43252
+#
+# 2. Get the tag, if any, associated with it:
+# bk prs -h -d':TAG:\n' -r$cset
+#
+# 3. If no such tag exists, take the hex-encoded md5sum of the
+# changeset key, extract the first 8 characters of it, and add
+# -BK and the above 8 characters to the end of the version.
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset; # strip trailing \n safely
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ if (length($tag)
Re: [PATCH] Automatically append a semi-random version for BK users
Sam, this version includes the CVS portion.
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper or CVS and CONFIG_LOCALVERSION_AUTO is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
This currently supports BitKeeper and CVS (assuming the format is the
same as the BK-CVS tree)
Signed-Off-By: Ryan Anderson [EMAIL PROTECTED]
Index: local-quilt/Makefile
===
--- local-quilt.orig/Makefile 2005-03-14 20:53:59.0 -0500
+++ local-quilt/Makefile2005-03-14 20:54:02.0 -0500
@@ -549,6 +549,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a BitKeeper, or other SCM, TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# BitKeeper/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only BitKeeper is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: local-quilt/init/Kconfig
===
--- local-quilt.orig/init/Kconfig 2005-03-14 20:53:59.0 -0500
+++ local-quilt/init/Kconfig2005-03-17 23:49:44.0 -0500
@@ -69,6 +69,24 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool Automatically append version information to the version string
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper or CVS tags that
+ belong to the current top of tree revision.
+
+ A string of the format -BK will be added to the localversion
+ if a BitKeeper based tree is found. The string -cvs-$version will be
+ added to the localversion if a CVS tree based on the BK-CVS tree is
+ found. The string generated by this will be appended after any
+ matching localversion* files, and after the value set in
+ CONFIG_LOCALVERSION
+
+ Note: This requires Perl and the Digest::MD5 module, as well
+ as BitKeeper and/or CVS.
+
config SWAP
bool Support for paging of anonymous memory (swap)
depends on MMU
Index: local-quilt/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ local-quilt/scripts/setlocalversion 2005-03-17 23:02:02.0 -0500
@@ -0,0 +1,120 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson [EMAIL PROTECTED] GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print EOT;
+Usage: setlocalversion srctree
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+#
+# The process is as follows:
+#
+# 1. Get the key of the top of tree changeset:
+# cset=`bk changes -r+ -k`
+#This will be something like:
+#[EMAIL PROTECTED]|ChangeSet|20050314010036|43252
+#
+# 2. Get the tag, if any, associated with it:
+# bk prs -h -d':TAG:\n' -r$cset
+#
+# 3. If no such tag exists, take the hex-encoded md5sum of the
+# changeset key, extract the first 8 characters of it, and add
+# -BK and the above 8 characters to the end of the version.
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset; # strip trailing \n safely
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ if (length($tag) == 0
Re: [PATCH] Automatically append a semi-random version for BK users
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper (or another SCM) and CONFIG_LOCALVERSION_AUTO
is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
This currently supports BitKeeper only, but support for other SCMs is
easy to add.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index: local-quilt/Makefile
===
--- local-quilt.orig/Makefile 2005-03-14 19:17:41.0 -0500
+++ local-quilt/Makefile2005-03-14 20:45:11.0 -0500
@@ -549,6 +549,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a BitKeeper, or other SCM, TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# BitKeeper/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only BitKeeper is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: local-quilt/init/Kconfig
===
--- local-quilt.orig/init/Kconfig 2005-03-14 19:17:41.0 -0500
+++ local-quilt/init/Kconfig2005-03-14 20:49:45.0 -0500
@@ -69,6 +69,21 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper, or other SCM tags that
+ belong to the current top of tree revision.
+
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+ Note: This requires Perl and the Digest::MD5 module, as well
+ as BitKeeper.
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
Index: local-quilt/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ local-quilt/scripts/setlocalversion 2005-03-14 20:41:01.0 -0500
@@ -0,0 +1,85 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[EMAIL PROTECTED]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print <
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+#
+# The process is as follows:
+#
+# 1. Get the key of the top of tree changeset:
+# cset=`bk changes -r+ -k`
+#This will be something like:
+#[EMAIL PROTECTED]|ChangeSet|20050314010036|43252
+#
+# 2. Get the tag, if any, associated with it:
+# bk prs -h -d':TAG:\n' -r$cset
+#
+# 3. If no such tag exists, take the hex-encoded md5sum of the
+# changeset key, extract the first 8 characters of it, and add
+# -BK and the above 8 characters to the end of the version.
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset; # strip trailing \n safely
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ if (length($tag) == 0) {
+ # There is no tag at the Top of Tree changeset, so this is not
+ # a release tree. To distinguish this from the previous
+ # release tree, someth
Re: [PATCH] Automatically append a semi-random version for BK users
Snipping a bit as I go, thanks for the feedback, Sam.
On Mon, Mar 14, 2005 at 11:43:17PM +0100, Sam Ravnborg wrote:
> On Wed, Mar 09, 2005 at 03:06:38AM -0500, Ryan Anderson wrote:
> > Two approachs are present here, a Perl version that is setup to handle
> > other automatic version appends (i.e, a CVS version shouldn't be much
> > effort to add), and a simplistic shell version that depends on "md5sum".
> > Both approaches generate the same hash.
>
> Please skip the shell version - add a note in Kconfig that enabling this
> option requires perl.
Thanks. That makes this much easier to do.
> > #exportINSTALL_PATH=/boot
> >
> > +# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
> > +# and try to determine if the current source tree is a release tree, of
> > any sort,
> > +# or if is a pure development tree.
> > +# A 'release tree' is any tree with a BitKeeper TAG associated with it.
> > +# The primary goal of this is to make it safe for a native BitKeeper user
> > to
> > +# build a release tree (i.e, 2.6.9) and also to continue developing
> > against the
> > +# current Linus tree, without having the Linus tree overwrite the 2.6.9
> > tree
> > +# when installed.
> > +#
> > +# (In the future, CVS and SVN support will be added as well.)
> > +
> > +ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
> > + ifeq ($(shell ls -d $(srctree)/BitKeeper
> > 2>/dev/null),$(srctree)/BitKeeper)
> > + localversion-bk := $(shell
> > $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
> > + LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
> > + endif
> > +endif
> Move the logic to determine the SCM system into the perl script.
> And do not assume bk, select more generic names.
Ok, simple enough to do.
> Also use:
> ifdef CONFIG_LOCALVERSION_AUTO
> like in rest of Makefile.
>
> Something like this:
> ifdef CONFIG_LOCALVERSION_AUTO
> LOCALVERSION += $(CONFIG_SHELL) $(srctree)/scripts/setlocalversion.sh
> $(srctree)
> endif
> note - perl script does not use objtree.
I forget why I had that there - I'll remove it.
> diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
> > --- /dev/null Wed Dec 31 16:00:00 196900
> > +++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
> > +
> > +# We are going to use the following commands to try and determine if
> > +# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
> > patches)
> > +# We currently assume that all meaningful version boundaries are marked by
> > a tag.
> > +# We don't care what the tag is, just that something exists.
> > +
> > [EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
> > [EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
> - to be deleted?
I'll simply rewrite as a better explanation of what's going on, for the
poor Perl neophytes. :)
> > +
> > +sub do_bk_checks {
> > + chdir($srctree);
> > + my $changeset = `bk changes -r+ -k`;
> > + chomp $changeset;
> > + my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
> > +
> > + printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if
> > ($debug > 0);
> > +
> > + if (length($tag) == 0) {
> if this imply that this is not a release tree then please write so - to
> be consistent with comment in top-level makefile.
> Thats good for poor sould like me that does not know perl.
Ok, I think I've made what's going on much more apparent in my revised
version.
> > + # We do not have a tag at the Top of Tree, so we need to
> > generate a localversion file
> > + # We'll use the given $changeset as input into this.
> > + my $localversion = Digest::MD5::md5_hex($changeset);
> > + $localversion = substr($localversion,0,8);
> > +
> > + printf("localversion = '%s'\n",$localversion) if ($debug > 0);
> > +
> > + push @LOCALVERSIONS, "BK" . $localversion;
> > +
> > + }
> > +}
> > +
> > +
> > +if ( -d "BitKeeper" ) {
> > + my $bk = `which bk`;
> > + chomp $bk;
> > + if (length($bk) != 0) {
> > + do_bk_checks();
> > + }
> > +}
> And this part should be prepared for cvs+svn.
I was going to implement the CVS version tonight, but I can't seem to
find the bk2cvs tree (Google is failing).
I'll send an incremental patch when I do track it down, for now, I'll
reply to this with my new version.
Again, thanks for the feedback.
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Automatically append a semi-random version for BK users
Snipping a bit as I go, thanks for the feedback, Sam.
On Mon, Mar 14, 2005 at 11:43:17PM +0100, Sam Ravnborg wrote:
On Wed, Mar 09, 2005 at 03:06:38AM -0500, Ryan Anderson wrote:
Two approachs are present here, a Perl version that is setup to handle
other automatic version appends (i.e, a CVS version shouldn't be much
effort to add), and a simplistic shell version that depends on md5sum.
Both approaches generate the same hash.
Please skip the shell version - add a note in Kconfig that enabling this
option requires perl.
Thanks. That makes this much easier to do.
#exportINSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of
any sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user
to
+# build a release tree (i.e, 2.6.9) and also to continue developing
against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9
tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper
2/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell
$(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
Move the logic to determine the SCM system into the perl script.
And do not assume bk, select more generic names.
Ok, simple enough to do.
Also use:
ifdef CONFIG_LOCALVERSION_AUTO
like in rest of Makefile.
Something like this:
ifdef CONFIG_LOCALVERSION_AUTO
LOCALVERSION += $(CONFIG_SHELL) $(srctree)/scripts/setlocalversion.sh
$(srctree)
endif
note - perl script does not use objtree.
I forget why I had that there - I'll remove it.
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
patches)
+# We currently assume that all meaningful version boundaries are marked by
a tag.
+# We don't care what the tag is, just that something exists.
+
[EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
[EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
- to be deleted?
I'll simply rewrite as a better explanation of what's going on, for the
poor Perl neophytes. :)
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf(ChangeSet Key = '%s'\nTAG = '%s'\n, $changeset, $tag) if
($debug 0);
+
+ if (length($tag) == 0) {
if this imply that this is not a release tree then please write so - to
be consistent with comment in top-level makefile.
Thats good for poor sould like me that does not know perl.
Ok, I think I've made what's going on much more apparent in my revised
version.
+ # We do not have a tag at the Top of Tree, so we need to
generate a localversion file
+ # We'll use the given $changeset as input into this.
+ my $localversion = Digest::MD5::md5_hex($changeset);
+ $localversion = substr($localversion,0,8);
+
+ printf(localversion = '%s'\n,$localversion) if ($debug 0);
+
+ push @LOCALVERSIONS, BK . $localversion;
+
+ }
+}
+
+
+if ( -d BitKeeper ) {
+ my $bk = `which bk`;
+ chomp $bk;
+ if (length($bk) != 0) {
+ do_bk_checks();
+ }
+}
And this part should be prepared for cvs+svn.
I was going to implement the CVS version tonight, but I can't seem to
find the bk2cvs tree (Google is failing).
I'll send an incremental patch when I do track it down, for now, I'll
reply to this with my new version.
Again, thanks for the feedback.
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Automatically append a semi-random version for BK users
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper (or another SCM) and CONFIG_LOCALVERSION_AUTO
is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
This currently supports BitKeeper only, but support for other SCMs is
easy to add.
Signed-Off-By: Ryan Anderson [EMAIL PROTECTED]
Index: local-quilt/Makefile
===
--- local-quilt.orig/Makefile 2005-03-14 19:17:41.0 -0500
+++ local-quilt/Makefile2005-03-14 20:45:11.0 -0500
@@ -549,6 +549,26 @@ export KBUILD_IMAGE ?= vmlinux
# images. Default is /boot, but you can set it to other values
export INSTALL_PATH ?= /boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+#
+# A 'release tree' is any tree with a BitKeeper, or other SCM, TAG associated
+# with it. The primary goal of this is to make it safe for a native
+# BitKeeper/CVS/SVN user to build a release tree (i.e, 2.6.9) and also to
+# continue developing against the current Linus tree, without having the Linus
+# tree overwrite the 2.6.9 tree when installed.
+#
+# Currently, only BitKeeper is supported.
+# Other SCMs can edit scripts/setlocalversion and add the appropriate
+# checks as needed.
+
+
+ifdef CONFIG_LOCALVERSION_AUTO
+ localversion-auto := $(shell $(PERL) $(srctree)/scripts/setlocalversion
$(srctree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
Index: local-quilt/init/Kconfig
===
--- local-quilt.orig/init/Kconfig 2005-03-14 19:17:41.0 -0500
+++ local-quilt/init/Kconfig2005-03-14 20:49:45.0 -0500
@@ -69,6 +69,21 @@ config LOCALVERSION
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool Automatically append version information to the version string
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper, or other SCM tags that
+ belong to the current top of tree revision.
+
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+ Note: This requires Perl and the Digest::MD5 module, as well
+ as BitKeeper.
+
config SWAP
bool Support for paging of anonymous memory (swap)
depends on MMU
Index: local-quilt/scripts/setlocalversion
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ local-quilt/scripts/setlocalversion 2005-03-14 20:41:01.0 -0500
@@ -0,0 +1,85 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson [EMAIL PROTECTED] GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 1) {
+ print EOT;
+Usage: setlocalversion srctree
+EOT
+ exit(1);
+}
+
+my ($srctree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if this
+# repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches) We
+# currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+#
+# The process is as follows:
+#
+# 1. Get the key of the top of tree changeset:
+# cset=`bk changes -r+ -k`
+#This will be something like:
+#[EMAIL PROTECTED]|ChangeSet|20050314010036|43252
+#
+# 2. Get the tag, if any, associated with it:
+# bk prs -h -d':TAG:\n' -r$cset
+#
+# 3. If no such tag exists, take the hex-encoded md5sum of the
+# changeset key, extract the first 8 characters of it, and add
+# -BK and the above 8 characters to the end of the version.
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset; # strip trailing \n safely
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ if (length($tag) == 0) {
+ # There is no tag at the Top of Tree changeset, so this is not
+ # a release tree. To distinguish this from the previous
+ # release tree, something must be appended to the version
[KBUILD] Bug in make deb-pkg when using seperate source and object directories
Sam, When running "make O=something deb-pkg", I get a failure that claims I haven't configured my kernel (I have). Running it a second time tells me to run "make mrproper" (include/linux/version.h got built on the first run) I did some preliminary poking around, but kbuild is still, well, mostly magic to me - I can't see where the object directory is getting lost. Think you can take a look? (Note, this failure shouldn't require anything Debian specific on your system to trigger - it's failing, as far as I can tell, on the $(MAKE) right before the call build the builddeb script, so it should be easy to reproduce) The log of when I run it follows: [EMAIL PROTECTED] ~/dev/linux/local-quilt$ blocal deb-pkg make make -C /home/ryan/dev/linux/local-quilt O=/home/ryan/dev/linux/output/local Makefile:487: .config: No such file or directory Using /home/ryan/dev/linux/local-quilt as source for kernel CHK include/linux/version.h UPD include/linux/version.h SYMLINK include/asm -> include/asm-i386 HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc SHIPPED scripts/kconfig/zconf.tab.h SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -s arch/i386/Kconfig *** *** You have not yet configured your kernel! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[6]: *** [silentoldconfig] Error 1 make[5]: *** [silentoldconfig] Error 2 make[4]: *** [include/linux/autoconf.h] Error 2 make[3]: *** [all] Error 2 make[2]: *** [deb-pkg] Error 2 make[1]: *** [deb-pkg] Error 2 make: *** [deb-pkg] Error 2 "blocal" is a simple wrapper to cut down on retyping things, it's just this: [EMAIL PROTECTED] ~/dev/linux/local-quilt$ cat /home/ryan/bin/blocal #!/bin/bash -e PWD=`pwd` if [ "$PWD" != "/home/ryan/dev/linux/local-quilt" ]; then cd /home/ryan/dev/linux/local-quilt fi make O=../output/local/ -j4 CC="ccache distcc" $* -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL
(trimming cc: down a bit) On Thu, Mar 10, 2005 at 06:40:11AM +0100, Sam Ravnborg wrote: > On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote: > > On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote: > > > BTW, Linus: Any chance you ever change something to version or > > > extraversion in bk just after a release ? I know I already ask and it > > > degenerated into a flamefest, and I don't know if that is specifically > > > the case now, but I keep getting report of people saying "I have a bug > > > in 2.6.xx" while in fact, they have some kind of bk clone of sometime > > > after 2.6.xx... > > > > The answer is the same: I'd still like to have somebody (preferably Sam) > > who is comfortable with all the build scripts get a revision-control- > > specific version at build-time, so that BK users would get the top-of-tree > > key value, and other people could get some CVS revision or something. > > I have a patch somewhere in my inbox, and got one from Ryan yesterday > also. I will see if I during the weekend find some time to look at it. Sam, you'll probably want this on top of the patch I sent. (I haven't built in a clean tree in a while, found a minor problem when I was transitioning to quilt today.) When running scripts/setlocalversion.sh, use $(CONFIG_SHELL) so the executable bit doesn't need to be set. Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> Index: local-quilt/Makefile === --- local-quilt.orig/Makefile 2005-03-12 20:36:24.0 -0500 +++ local-quilt/Makefile2005-03-12 20:54:40.0 -0500 @@ -563,7 +563,7 @@ ifeq ($(CONFIG_LOCALVERSION_AUTO),y) ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper) - localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree)) + localversion-bk := $(shell $(CONFIG_SHELL) $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree)) LOCALVERSION := $(LOCALVERSION)$(localversion-bk) endif endif -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UML - Restore proper descriptions in make deb-pkg target
On Wed, Mar 09, 2005 at 10:03:01AM +0100, Blaisorblade wrote: > > Yes, it must go in... only the Description is a bit problematic, since you'll > get with the below: > Description: Linux kernel, version linux-2.6.11 > > Description: Linux kernel, version user-mode-linux-2.6.11 Good point. This pulls the description from the Debian user-mode-linux package, and puts $version back in the appropriate places for both descriptions. Incremental on top of the previous patch. Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> Index: local-quilt/scripts/package/builddeb === --- local-quilt.orig/scripts/package/builddeb 2005-03-12 20:36:24.0 -0500 +++ local-quilt/scripts/package/builddeb2005-03-12 20:40:50.0 -0500 @@ -73,6 +73,29 @@ EOF # Generate a control file +if [ "$ARCH" == "um" ]; then + +cat < debian/control +Source: linux +Section: base +Priority: optional +Maintainer: $name +Standards-Version: 3.6.1 + +Package: $packagename +Architecture: any +Description: User Mode Linux kernel, version $version + User-mode Linux is a port of the Linux kernel to its own system call + interface. It provides a kind of virtual machine, which runs Linux + as a user process under another Linux kernel. This is useful for + kernel development, sandboxes, jails, experimentation, and + many other things. + . + This package contains the Linux kernel, modules and corresponding other + files version $version +EOF + +else cat < debian/control Source: linux Section: base @@ -82,10 +105,11 @@ Package: $packagename Architecture: any -Description: Linux kernel, version $packagename +Description: Linux kernel, version $version This package contains the Linux kernel, modules and corresponding other - files version $packagename + files version $version EOF +fi # Fix some ownership and permissions chown -R root:root "$tmpdir" -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL
(trimming cc: down a bit) On Thu, Mar 10, 2005 at 06:40:11AM +0100, Sam Ravnborg wrote: On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote: On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote: BTW, Linus: Any chance you ever change something to version or extraversion in bk just after a release ? I know I already ask and it degenerated into a flamefest, and I don't know if that is specifically the case now, but I keep getting report of people saying I have a bug in 2.6.xx while in fact, they have some kind of bk clone of sometime after 2.6.xx... The answer is the same: I'd still like to have somebody (preferably Sam) who is comfortable with all the build scripts get a revision-control- specific version at build-time, so that BK users would get the top-of-tree key value, and other people could get some CVS revision or something. I have a patch somewhere in my inbox, and got one from Ryan yesterday also. I will see if I during the weekend find some time to look at it. Sam, you'll probably want this on top of the patch I sent. (I haven't built in a clean tree in a while, found a minor problem when I was transitioning to quilt today.) When running scripts/setlocalversion.sh, use $(CONFIG_SHELL) so the executable bit doesn't need to be set. Signed-off-by: Ryan Anderson [EMAIL PROTECTED] Index: local-quilt/Makefile === --- local-quilt.orig/Makefile 2005-03-12 20:36:24.0 -0500 +++ local-quilt/Makefile2005-03-12 20:54:40.0 -0500 @@ -563,7 +563,7 @@ ifeq ($(CONFIG_LOCALVERSION_AUTO),y) ifeq ($(shell ls -d $(srctree)/BitKeeper 2/dev/null),$(srctree)/BitKeeper) - localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree)) + localversion-bk := $(shell $(CONFIG_SHELL) $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree)) LOCALVERSION := $(LOCALVERSION)$(localversion-bk) endif endif -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KBUILD] Bug in make deb-pkg when using seperate source and object directories
Sam, When running make O=something deb-pkg, I get a failure that claims I haven't configured my kernel (I have). Running it a second time tells me to run make mrproper (include/linux/version.h got built on the first run) I did some preliminary poking around, but kbuild is still, well, mostly magic to me - I can't see where the object directory is getting lost. Think you can take a look? (Note, this failure shouldn't require anything Debian specific on your system to trigger - it's failing, as far as I can tell, on the $(MAKE) right before the call build the builddeb script, so it should be easy to reproduce) The log of when I run it follows: [EMAIL PROTECTED] ~/dev/linux/local-quilt$ blocal deb-pkg make make -C /home/ryan/dev/linux/local-quilt O=/home/ryan/dev/linux/output/local Makefile:487: .config: No such file or directory Using /home/ryan/dev/linux/local-quilt as source for kernel CHK include/linux/version.h UPD include/linux/version.h SYMLINK include/asm - include/asm-i386 HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc SHIPPED scripts/kconfig/zconf.tab.h SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -s arch/i386/Kconfig *** *** You have not yet configured your kernel! *** *** Please run some configurator (e.g. make oldconfig or *** make menuconfig or make xconfig). *** make[6]: *** [silentoldconfig] Error 1 make[5]: *** [silentoldconfig] Error 2 make[4]: *** [include/linux/autoconf.h] Error 2 make[3]: *** [all] Error 2 make[2]: *** [deb-pkg] Error 2 make[1]: *** [deb-pkg] Error 2 make: *** [deb-pkg] Error 2 blocal is a simple wrapper to cut down on retyping things, it's just this: [EMAIL PROTECTED] ~/dev/linux/local-quilt$ cat /home/ryan/bin/blocal #!/bin/bash -e PWD=`pwd` if [ $PWD != /home/ryan/dev/linux/local-quilt ]; then cd /home/ryan/dev/linux/local-quilt fi make O=../output/local/ -j4 CC=ccache distcc $* -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UML - Restore proper descriptions in make deb-pkg target
On Wed, Mar 09, 2005 at 10:03:01AM +0100, Blaisorblade wrote: Yes, it must go in... only the Description is a bit problematic, since you'll get with the below: Description: Linux kernel, version linux-2.6.11 Description: Linux kernel, version user-mode-linux-2.6.11 Good point. This pulls the description from the Debian user-mode-linux package, and puts $version back in the appropriate places for both descriptions. Incremental on top of the previous patch. Signed-off-by: Ryan Anderson [EMAIL PROTECTED] Index: local-quilt/scripts/package/builddeb === --- local-quilt.orig/scripts/package/builddeb 2005-03-12 20:36:24.0 -0500 +++ local-quilt/scripts/package/builddeb2005-03-12 20:40:50.0 -0500 @@ -73,6 +73,29 @@ EOF # Generate a control file +if [ $ARCH == um ]; then + +cat EOF debian/control +Source: linux +Section: base +Priority: optional +Maintainer: $name +Standards-Version: 3.6.1 + +Package: $packagename +Architecture: any +Description: User Mode Linux kernel, version $version + User-mode Linux is a port of the Linux kernel to its own system call + interface. It provides a kind of virtual machine, which runs Linux + as a user process under another Linux kernel. This is useful for + kernel development, sandboxes, jails, experimentation, and + many other things. + . + This package contains the Linux kernel, modules and corresponding other + files version $version +EOF + +else cat EOF debian/control Source: linux Section: base @@ -82,10 +105,11 @@ Package: $packagename Architecture: any -Description: Linux kernel, version $packagename +Description: Linux kernel, version $version This package contains the Linux kernel, modules and corresponding other - files version $packagename + files version $version EOF +fi # Fix some ownership and permissions chown -R root:root $tmpdir -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote:
> On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> >
> > BTW, Linus: Any chance you ever change something to version or
> > extraversion in bk just after a release ? I know I already ask and it
> > degenerated into a flamefest, and I don't know if that is specifically
> > the case now, but I keep getting report of people saying "I have a bug
> > in 2.6.xx" while in fact, they have some kind of bk clone of sometime
> > after 2.6.xx...
>
> The answer is the same: I'd still like to have somebody (preferably Sam)
> who is comfortable with all the build scripts get a revision-control-
> specific version at build-time, so that BK users would get the top-of-tree
> key value, and other people could get some CVS revision or something.
I've got something that fixes up the version by adding -BK and then 8
hex characters from the md5 hash of the top of tree changeset key.
I was starting to work on stuffing that same value into a /proc file so
that you can figure out what the tree looked like, but at the moment,
you at least get a semi-random string appended to the version.
I resent the patch yesterday, but I'll put it here, too:
> I have this dim memory that Sam might even have had some early trials, but
> maybe thats just wishful thinking.. Sam?
I think that was my patch - Sam was going to look at it, but I suspect
it got lost in more interesting things. :)
(I sent a better described version to Andrew yesterday, if you want to
grab that description and use it instead.)
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-09 02:51:15 -05:00
+++ b/Makefile 2005-03-09 02:51:15 -05:00
@@ -550,6 +550,24 @@
#exportINSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper
2>/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell
$(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2005-03-09 02:51:15 -05:00
+++ b/init/Kconfig 2005-03-09 02:51:15 -05:00
@@ -69,6 +69,18 @@
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper tags that belong to the
+ current top of tree revision.
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[EMAIL PROTECTED]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print <
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
patches)
+# We currently assume that all meaningful version boundaries are marked by a
tag.
+# We don't care what the tag is, just that something exists.
+
[EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
[EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -
[PATCH] Automatically append a semi-random version for BK users
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper and CONFIG_LOCALVERSION_AUTO is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
Two approachs are present here, a Perl version that is setup to handle
other automatic version appends (i.e, a CVS version shouldn't be much
effort to add), and a simplistic shell version that depends on "md5sum".
Both approaches generate the same hash.
I've sent this twice before, gotten no comments, so I'm really looking
for feedback on the approach and idea, more than anything else.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-09 02:51:15 -05:00
+++ b/Makefile 2005-03-09 02:51:15 -05:00
@@ -550,6 +550,24 @@
#exportINSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper
2>/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell
$(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2005-03-09 02:51:15 -05:00
+++ b/init/Kconfig 2005-03-09 02:51:15 -05:00
@@ -69,6 +69,18 @@
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper tags that belong to the
+ current top of tree revision.
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[EMAIL PROTECTED]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print <
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
patches)
+# We currently assume that all meaningful version boundaries are marked by a
tag.
+# We don't care what the tag is, just that something exists.
+
[EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
[EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if
($debug > 0);
+
+ if (length($tag) == 0) {
+ # We do not have a tag at the Top of Tree, so we need to
generate a localversion file
+ # We'll use the given $changeset as input into this.
+ my $localversion = Digest::MD5::md5_hex($changeset);
+ $localversion = substr($localversion,0,8);
+
+ printf("localversion = '%s'\n",$localversion) if ($debug > 0);
+
+ push @LOCALVERSIONS, "BK" . $localversion;
+
+ }
+}
+
+
+if ( -d "BitKeeper" ) {
+ my $bk = `which bk`;
+ chomp $bk;
+ if (length($bk) != 0) {
+ do_bk_checks();
+ }
+}
+
[PATCH] Automatically append a semi-random version for BK users
Automatically append a semi-random version if the tree we're building
isn't tagged in BitKeeper and CONFIG_LOCALVERSION_AUTO is set.
This fixes the case when Linus (or someone else) does a release and tags
it, someone else does a build of that release tree (i.e, 2.6.11), and
installs it. Later, before another release occurs (i.e, -rc1), another
build happens, and the actual, released 2.6.11 is overwritten with the
-current tree.
Two approachs are present here, a Perl version that is setup to handle
other automatic version appends (i.e, a CVS version shouldn't be much
effort to add), and a simplistic shell version that depends on md5sum.
Both approaches generate the same hash.
I've sent this twice before, gotten no comments, so I'm really looking
for feedback on the approach and idea, more than anything else.
Signed-Off-By: Ryan Anderson [EMAIL PROTECTED]
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-09 02:51:15 -05:00
+++ b/Makefile 2005-03-09 02:51:15 -05:00
@@ -550,6 +550,24 @@
#exportINSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper
2/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell
$(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2005-03-09 02:51:15 -05:00
+++ b/init/Kconfig 2005-03-09 02:51:15 -05:00
@@ -69,6 +69,18 @@
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool Automatically append version information to the version string
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper tags that belong to the
+ current top of tree revision.
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+
config SWAP
bool Support for paging of anonymous memory (swap)
depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson [EMAIL PROTECTED] GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print EOT;
+Usage: setlocalversion srctree objtree
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
patches)
+# We currently assume that all meaningful version boundaries are marked by a
tag.
+# We don't care what the tag is, just that something exists.
+
[EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
[EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf(ChangeSet Key = '%s'\nTAG = '%s'\n, $changeset, $tag) if
($debug 0);
+
+ if (length($tag) == 0) {
+ # We do not have a tag at the Top of Tree, so we need to
generate a localversion file
+ # We'll use the given $changeset as input into this.
+ my $localversion = Digest::MD5::md5_hex($changeset);
+ $localversion = substr($localversion,0,8);
+
+ printf(localversion = '%s'\n,$localversion) if ($debug 0);
+
+ push @LOCALVERSIONS, BK . $localversion;
+
+ }
+}
+
+
+if ( -d BitKeeper ) {
+ my $bk = `which bk`;
+ chomp $bk;
+ if (length($bk) != 0) {
+ do_bk_checks();
+ }
+}
+
+printf -%s\n, join(-,@LOCALVERSIONS) if (scalar @LOCALVERSIONS 0);
diff -Nru a/scripts
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote:
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
BTW, Linus: Any chance you ever change something to version or
extraversion in bk just after a release ? I know I already ask and it
degenerated into a flamefest, and I don't know if that is specifically
the case now, but I keep getting report of people saying I have a bug
in 2.6.xx while in fact, they have some kind of bk clone of sometime
after 2.6.xx...
The answer is the same: I'd still like to have somebody (preferably Sam)
who is comfortable with all the build scripts get a revision-control-
specific version at build-time, so that BK users would get the top-of-tree
key value, and other people could get some CVS revision or something.
I've got something that fixes up the version by adding -BK and then 8
hex characters from the md5 hash of the top of tree changeset key.
I was starting to work on stuffing that same value into a /proc file so
that you can figure out what the tree looked like, but at the moment,
you at least get a semi-random string appended to the version.
I resent the patch yesterday, but I'll put it here, too:
I have this dim memory that Sam might even have had some early trials, but
maybe thats just wishful thinking.. Sam?
I think that was my patch - Sam was going to look at it, but I suspect
it got lost in more interesting things. :)
(I sent a better described version to Andrew yesterday, if you want to
grab that description and use it instead.)
Signed-Off-By: Ryan Anderson [EMAIL PROTECTED]
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-09 02:51:15 -05:00
+++ b/Makefile 2005-03-09 02:51:15 -05:00
@@ -550,6 +550,24 @@
#exportINSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any
sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper
2/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell
$(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2005-03-09 02:51:15 -05:00
+++ b/init/Kconfig 2005-03-09 02:51:15 -05:00
@@ -69,6 +69,18 @@
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool Automatically append version information to the version string
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper tags that belong to the
+ current top of tree revision.
+ A string of the format -BK will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+
config SWAP
bool Support for paging of anonymous memory (swap)
depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2005-03-09 02:51:15 -05:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson [EMAIL PROTECTED] GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print EOT;
+Usage: setlocalversion srctree objtree
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some
patches)
+# We currently assume that all meaningful version boundaries are marked by a
tag.
+# We don't care what the tag is, just that something exists.
+
[EMAIL PROTECTED] ~/dev/linux/local$ T=`bk changes -r+ -k`
[EMAIL PROTECTED] ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf(ChangeSet Key = '%s'\nTAG = '%s'\n, $changeset, $tag) if
($debug 0
Re: [uml-devel] [PATCH] UML - Make deb-pkg build target build a Debian-style user-mode-linux package
Sorry, I forgot something important. On Mon, Mar 07, 2005 at 01:28:28PM -0500, Ryan Anderson wrote: > Make the deb-pkg build target understand the "um" arch and set up the > package and directory structure to match a mainline-Debian style > user-mode-linux package. > > This is primarily so that it stops matching, exactly, the naming > convention used by normal, non-UML kernels generated by this command. > > Installing "linux-2.6.11" and "linux-2.6.11", where one is a UML kernel > doesn't do the right thing. This fixes that. Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> > > > diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb > --- a/scripts/package/builddeb2005-03-07 13:21:16 -05:00 > +++ b/scripts/package/builddeb2005-03-07 13:21:16 -05:00 > @@ -14,18 +14,38 @@ > # Some variables and settings used throughout the script > version=$KERNELRELEASE > tmpdir="$objtree/debian/tmp" > +packagename=linux-$version > + > +if [ "$ARCH" == "um" ] ; then > + packagename=user-mode-linux-$version > +fi > > # Setup the directory structure > rm -rf "$tmpdir" > mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot" > +if [ "$ARCH" == "um" ] ; then > + mkdir -p "$tmpdir/usr/lib/uml/modules/$version" > "$tmpdir/usr/share/doc/$packagename" "$tmpdir/usr/bin" > +fi > > # Build and install the kernel > -cp System.map "$tmpdir/boot/System.map-$version" > -cp .config "$tmpdir/boot/config-$version" > -cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version" > +if [ "$ARCH" == "um" ] ; then > + $MAKE linux > + cp System.map "$tmpdir/usr/lib/uml/modules/$version/System.map" > + cp .config "$tmpdir/usr/share/doc/$packagename/config" > + gzip "$tmpdir/usr/share/doc/$packagename/config" > + cp $KBUILD_IMAGE "$tmpdir/usr/bin/linux-$version" > +else > + cp System.map "$tmpdir/boot/System.map-$version" > + cp .config "$tmpdir/boot/config-$version" > + cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version" > +fi > > if grep -q '^CONFIG_MODULES=y' .config ; then > INSTALL_MOD_PATH="$tmpdir" make modules_install > + if [ "$ARCH" == "um" ] ; then > + mv "$tmpdir/lib/modules/$version"/* > "$tmpdir/usr/lib/uml/modules/$version/" > + rmdir "$tmpdir/lib/modules/$version" > + fi > fi > > # Install the maintainer scripts > @@ -60,11 +80,11 @@ > Maintainer: $name > Standards-Version: 3.6.1 > > -Package: linux-$version > +Package: $packagename > Architecture: any > -Description: Linux kernel, version $version > +Description: Linux kernel, version $packagename > This package contains the Linux kernel, modules and corresponding other > - files version $version. > + files version $packagename > EOF > > # Fix some ownership and permissions > > -- > > Ryan Anderson > sometimes Pug Majere > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595_id=14396=click > ___ > User-mode-linux-devel mailing list > User-mode-linux-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UML - Make deb-pkg build target build a Debian-style user-mode-linux package
Make the deb-pkg build target understand the "um" arch and set up the package and directory structure to match a mainline-Debian style user-mode-linux package. This is primarily so that it stops matching, exactly, the naming convention used by normal, non-UML kernels generated by this command. Installing "linux-2.6.11" and "linux-2.6.11", where one is a UML kernel doesn't do the right thing. This fixes that. diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb --- a/scripts/package/builddeb 2005-03-07 13:21:16 -05:00 +++ b/scripts/package/builddeb 2005-03-07 13:21:16 -05:00 @@ -14,18 +14,38 @@ # Some variables and settings used throughout the script version=$KERNELRELEASE tmpdir="$objtree/debian/tmp" +packagename=linux-$version + +if [ "$ARCH" == "um" ] ; then + packagename=user-mode-linux-$version +fi # Setup the directory structure rm -rf "$tmpdir" mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot" +if [ "$ARCH" == "um" ] ; then + mkdir -p "$tmpdir/usr/lib/uml/modules/$version" "$tmpdir/usr/share/doc/$packagename" "$tmpdir/usr/bin" +fi # Build and install the kernel -cp System.map "$tmpdir/boot/System.map-$version" -cp .config "$tmpdir/boot/config-$version" -cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version" +if [ "$ARCH" == "um" ] ; then + $MAKE linux + cp System.map "$tmpdir/usr/lib/uml/modules/$version/System.map" + cp .config "$tmpdir/usr/share/doc/$packagename/config" + gzip "$tmpdir/usr/share/doc/$packagename/config" + cp $KBUILD_IMAGE "$tmpdir/usr/bin/linux-$version" +else + cp System.map "$tmpdir/boot/System.map-$version" + cp .config "$tmpdir/boot/config-$version" + cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version" +fi if grep -q '^CONFIG_MODULES=y' .config ; then INSTALL_MOD_PATH="$tmpdir" make modules_install + if [ "$ARCH" == "um" ] ; then + mv "$tmpdir/lib/modules/$version"/* "$tmpdir/usr/lib/uml/modules/$version/" + rmdir "$tmpdir/lib/modules/$version" + fi fi # Install the maintainer scripts @@ -60,11 +80,11 @@ Maintainer: $name Standards-Version: 3.6.1 -Package: linux-$version +Package: $packagename Architecture: any -Description: Linux kernel, version $version +Description: Linux kernel, version $packagename This package contains the Linux kernel, modules and corresponding other - files version $version. + files version $packagename EOF # Fix some ownership and permissions -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] UML - Make deb-pkg build target build a Debian-style user-mode-linux package
Make the deb-pkg build target understand the um arch and set up the package and directory structure to match a mainline-Debian style user-mode-linux package. This is primarily so that it stops matching, exactly, the naming convention used by normal, non-UML kernels generated by this command. Installing linux-2.6.11 and linux-2.6.11, where one is a UML kernel doesn't do the right thing. This fixes that. diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb --- a/scripts/package/builddeb 2005-03-07 13:21:16 -05:00 +++ b/scripts/package/builddeb 2005-03-07 13:21:16 -05:00 @@ -14,18 +14,38 @@ # Some variables and settings used throughout the script version=$KERNELRELEASE tmpdir=$objtree/debian/tmp +packagename=linux-$version + +if [ $ARCH == um ] ; then + packagename=user-mode-linux-$version +fi # Setup the directory structure rm -rf $tmpdir mkdir -p $tmpdir/DEBIAN $tmpdir/lib $tmpdir/boot +if [ $ARCH == um ] ; then + mkdir -p $tmpdir/usr/lib/uml/modules/$version $tmpdir/usr/share/doc/$packagename $tmpdir/usr/bin +fi # Build and install the kernel -cp System.map $tmpdir/boot/System.map-$version -cp .config $tmpdir/boot/config-$version -cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +if [ $ARCH == um ] ; then + $MAKE linux + cp System.map $tmpdir/usr/lib/uml/modules/$version/System.map + cp .config $tmpdir/usr/share/doc/$packagename/config + gzip $tmpdir/usr/share/doc/$packagename/config + cp $KBUILD_IMAGE $tmpdir/usr/bin/linux-$version +else + cp System.map $tmpdir/boot/System.map-$version + cp .config $tmpdir/boot/config-$version + cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +fi if grep -q '^CONFIG_MODULES=y' .config ; then INSTALL_MOD_PATH=$tmpdir make modules_install + if [ $ARCH == um ] ; then + mv $tmpdir/lib/modules/$version/* $tmpdir/usr/lib/uml/modules/$version/ + rmdir $tmpdir/lib/modules/$version + fi fi # Install the maintainer scripts @@ -60,11 +80,11 @@ Maintainer: $name Standards-Version: 3.6.1 -Package: linux-$version +Package: $packagename Architecture: any -Description: Linux kernel, version $version +Description: Linux kernel, version $packagename This package contains the Linux kernel, modules and corresponding other - files version $version. + files version $packagename EOF # Fix some ownership and permissions -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - Make deb-pkg build target build a Debian-style user-mode-linux package
Sorry, I forgot something important. On Mon, Mar 07, 2005 at 01:28:28PM -0500, Ryan Anderson wrote: Make the deb-pkg build target understand the um arch and set up the package and directory structure to match a mainline-Debian style user-mode-linux package. This is primarily so that it stops matching, exactly, the naming convention used by normal, non-UML kernels generated by this command. Installing linux-2.6.11 and linux-2.6.11, where one is a UML kernel doesn't do the right thing. This fixes that. Signed-off-by: Ryan Anderson [EMAIL PROTECTED] diff -Nru a/scripts/package/builddeb b/scripts/package/builddeb --- a/scripts/package/builddeb2005-03-07 13:21:16 -05:00 +++ b/scripts/package/builddeb2005-03-07 13:21:16 -05:00 @@ -14,18 +14,38 @@ # Some variables and settings used throughout the script version=$KERNELRELEASE tmpdir=$objtree/debian/tmp +packagename=linux-$version + +if [ $ARCH == um ] ; then + packagename=user-mode-linux-$version +fi # Setup the directory structure rm -rf $tmpdir mkdir -p $tmpdir/DEBIAN $tmpdir/lib $tmpdir/boot +if [ $ARCH == um ] ; then + mkdir -p $tmpdir/usr/lib/uml/modules/$version $tmpdir/usr/share/doc/$packagename $tmpdir/usr/bin +fi # Build and install the kernel -cp System.map $tmpdir/boot/System.map-$version -cp .config $tmpdir/boot/config-$version -cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +if [ $ARCH == um ] ; then + $MAKE linux + cp System.map $tmpdir/usr/lib/uml/modules/$version/System.map + cp .config $tmpdir/usr/share/doc/$packagename/config + gzip $tmpdir/usr/share/doc/$packagename/config + cp $KBUILD_IMAGE $tmpdir/usr/bin/linux-$version +else + cp System.map $tmpdir/boot/System.map-$version + cp .config $tmpdir/boot/config-$version + cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version +fi if grep -q '^CONFIG_MODULES=y' .config ; then INSTALL_MOD_PATH=$tmpdir make modules_install + if [ $ARCH == um ] ; then + mv $tmpdir/lib/modules/$version/* $tmpdir/usr/lib/uml/modules/$version/ + rmdir $tmpdir/lib/modules/$version + fi fi # Install the maintainer scripts @@ -60,11 +80,11 @@ Maintainer: $name Standards-Version: 3.6.1 -Package: linux-$version +Package: $packagename Architecture: any -Description: Linux kernel, version $version +Description: Linux kernel, version $packagename This package contains the Linux kernel, modules and corresponding other - files version $version. + files version $packagename EOF # Fix some ownership and permissions -- Ryan Anderson sometimes Pug Majere --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, Mar 03, 2005 at 12:59:18AM -0800, Matthew Frost wrote: > > OT, 3.0.0 is an even-numbered release, therefore stable. So what do you > call the odd-numbered unstable series that produces it? ;) 3.-1.x :) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, Mar 03, 2005 at 12:59:18AM -0800, Matthew Frost wrote: OT, 3.0.0 is an even-numbered release, therefore stable. So what do you call the odd-numbered unstable series that produces it? ;) 3.-1.x :) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11
On Wed, Mar 02, 2005 at 07:46:05AM -0800, Linus Torvalds wrote: > (In contrast the full ChangeLog was missing because the generation script > I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 > or worse, so the log from the last -rc release is fast, but going back all > the way to 2.6.10 took long long enough that I didn't wait for it). Is there some reason why bk changes -aem -rv2.6.10..+ | shortlog isn't sufficient? I'd guess your script will want to calculate the 2.6.10 part automatically, but that seems to run in a second or so on my machine, from a largely cold cache. I *think* this gets all the changes where a -d (date) based method gets very confused by parallel trees. Am I missing something? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote: > The problem with major development trees like 2.4.x vs 2.5.x was that the > release cycles were too long, and that people hated the back- and > forward-porting. That said, it did serve a purpose - people kind of knew > where they stood, even though we always ended up having to have big > changes in the stable tree too, just to keep up with a changing landscape. How about this idea, instead: At 2.6.12, make two parallel BitKeeper trees: 2.6 and 2.7 Push bugfixes into 2.6. Push *everything* that's not a bugfix into 2.7. "bk pull" the 2.6 tree into the 2.7 tree each day when you wake up. A week later, release 2.6.12.1 from the 2.6 tree, then immediately bk pull the 2.7 tree into the 2.6 tree. Release 2.6.13-rc1 at about the same time, and again only take bugfixes into the 2.6 tree. In 3-7 weeks, after a few more -rc iterations with just bugfixes, release 2.6.13. This should keep the differences between the trees down to something somewhat... sane, and, hopefully, keep the stable tree stable. People working on big changes can do them against 2.6.x if they need stability, and know that if they stay current with each 2.6.x release as they work, they should have a controllable amount of pain for merges. My thinking is simply that if you're going to use BitKeeper, you might as well abuse it for all that it's worth. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote: The problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting. That said, it did serve a purpose - people kind of knew where they stood, even though we always ended up having to have big changes in the stable tree too, just to keep up with a changing landscape. How about this idea, instead: At 2.6.12, make two parallel BitKeeper trees: 2.6 and 2.7 Push bugfixes into 2.6. Push *everything* that's not a bugfix into 2.7. bk pull the 2.6 tree into the 2.7 tree each day when you wake up. A week later, release 2.6.12.1 from the 2.6 tree, then immediately bk pull the 2.7 tree into the 2.6 tree. Release 2.6.13-rc1 at about the same time, and again only take bugfixes into the 2.6 tree. In 3-7 weeks, after a few more -rc iterations with just bugfixes, release 2.6.13. This should keep the differences between the trees down to something somewhat... sane, and, hopefully, keep the stable tree stable. People working on big changes can do them against 2.6.x if they need stability, and know that if they stay current with each 2.6.x release as they work, they should have a controllable amount of pain for merges. My thinking is simply that if you're going to use BitKeeper, you might as well abuse it for all that it's worth. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11
On Wed, Mar 02, 2005 at 07:46:05AM -0800, Linus Torvalds wrote: (In contrast the full ChangeLog was missing because the generation script I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 or worse, so the log from the last -rc release is fast, but going back all the way to 2.6.10 took long long enough that I didn't wait for it). Is there some reason why bk changes -aem -rv2.6.10..+ | shortlog isn't sufficient? I'd guess your script will want to calculate the 2.6.10 part automatically, but that seems to run in a second or so on my machine, from a largely cold cache. I *think* this gets all the changes where a -d (date) based method gets very confused by parallel trees. Am I missing something? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
On Thu, Feb 24, 2005 at 02:46:05AM -0800, Andrew Morton wrote: > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > > +spinlock_t fork_cn_lock = SPIN_LOCK_UNLOCKED; > > This should have static scope, and could be local to fork_connector(). > > Please use DEFINE_SPINLOCK(). (There's a reason for this, but I forget > what it was). Static analysis tools, IIRC. (Stanford checker, sparse) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
On Thu, Feb 24, 2005 at 02:46:05AM -0800, Andrew Morton wrote: Guillaume Thouvenin [EMAIL PROTECTED] wrote: +spinlock_t fork_cn_lock = SPIN_LOCK_UNLOCKED; This should have static scope, and could be local to fork_connector(). Please use DEFINE_SPINLOCK(). (There's a reason for this, but I forget what it was). Static analysis tools, IIRC. (Stanford checker, sparse) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Makefiles are not built using a Fortran compiler
On Tue, Feb 08, 2005 at 03:44:17PM +, Matthew Wilcox wrote: > On Tue, Feb 08, 2005 at 01:23:48PM +0100, Roman Zippel wrote: > > Enabling the following in the Makefile should have the same effect: > > > > # For maximum performance (+ possibly random breakage, uncomment > > # the following) > > > > #MAKEFLAGS += -rR > > This reduces the debug output even further (and size of debug output is > strongly correlated with time taken to do a null build): > > -rw-r--r-- 1 willy willy 65582214 2005-02-07 21:13 vanilla.debug > -rw-r--r-- 1 willy willy 51413770 2005-02-07 22:17 nosuffixes.debug > -rw-r--r-- 1 willy willy 37245484 2005-02-08 09:56 maxperf.debug > > Seems like it gets rid of the RCS and SCCS rules -- certainly a big > improvement, and I'm not sure anyone really uses those rules. Can we > perhaps uncomment this line at the beginning of 2.6.12 and see if anyone > complains? This should reduce make overhead by 30-40% which is really > worth doing. The BitKeeper users sometimes make use of the SCCS rules. BK installs itself in such a way as to provide the SCCS commands, and Make will update things if you forget to do a bk -r get -Sq after a pull. >From a totally clean tree, this doesn't work (I forget why, offhand, but I think it's something to do with the *config targets), but it is helpful at times from partially clean trees to automatically "get" from the SCCS copy of the file. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Makefiles are not built using a Fortran compiler
On Tue, Feb 08, 2005 at 03:44:17PM +, Matthew Wilcox wrote: On Tue, Feb 08, 2005 at 01:23:48PM +0100, Roman Zippel wrote: Enabling the following in the Makefile should have the same effect: # For maximum performance (+ possibly random breakage, uncomment # the following) #MAKEFLAGS += -rR This reduces the debug output even further (and size of debug output is strongly correlated with time taken to do a null build): -rw-r--r-- 1 willy willy 65582214 2005-02-07 21:13 vanilla.debug -rw-r--r-- 1 willy willy 51413770 2005-02-07 22:17 nosuffixes.debug -rw-r--r-- 1 willy willy 37245484 2005-02-08 09:56 maxperf.debug Seems like it gets rid of the RCS and SCCS rules -- certainly a big improvement, and I'm not sure anyone really uses those rules. Can we perhaps uncomment this line at the beginning of 2.6.12 and see if anyone complains? This should reduce make overhead by 30-40% which is really worth doing. The BitKeeper users sometimes make use of the SCCS rules. BK installs itself in such a way as to provide the SCCS commands, and Make will update things if you forget to do a bk -r get -Sq after a pull. From a totally clean tree, this doesn't work (I forget why, offhand, but I think it's something to do with the *config targets), but it is helpful at times from partially clean trees to automatically get from the SCCS copy of the file. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT] Better handling of bad xfers/interrupt delays in psmouse
On Sun, Feb 06, 2005 at 12:55:00PM -0500, Dmitry Torokhov wrote: > > Hmm, wouldn't it be nice if they put spell checker in GCC? ;) Isn't the resulting beast called "emacs"? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT] Better handling of bad xfers/interrupt delays in psmouse
On Sun, Feb 06, 2005 at 12:55:00PM -0500, Dmitry Torokhov wrote: Hmm, wouldn't it be nice if they put spell checker in GCC? ;) Isn't the resulting beast called emacs? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
