tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[netfilter]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

There is a patch in pending that makes the tcp-window-tracking patch
fail to apply cleanly.  The patch in
pending/24_conntrack-nosysctl.patch:

--- linux-2.4.21-pre5-ac3/net/ipv4/netfilter/ip_conntrack_core.c	Sat Mar 15 12:16:55 2003
+++ linux-2.4.21-pre5-ac3-fixed/net/ipv4/netfilter/ip_conntrack_core.c	Sat Mar 15 12:23:34 2003
@@ -1478,8 +1478,10 @@
 	ip_ct_attach = ip_conntrack_attach;
 	return ret;
 
+#ifdef CONFIG_SYSCTL
 err_free_ct_cachep:
 	kmem_cache_destroy(ip_conntrack_cachep);
+#endif /*CONFIG_SYSCTL*/
 err_free_hash:
 	vfree(ip_conntrack_hash);
 err_unreg_sockopt:


is not accounted for in hunk 5 to file
net/ipv4/netfilter/ip_conntrack_core.c in
extra/tcp-window-tracking.patch.

I guess the question is, should it be expected that patches in suites
like extra should apply if all of submitted and pending are applied.

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

On Thu, 2003-04-03 at 04:51, netfilter@interlinx.bc.ca wrote:
> There is a patch in pending that makes the tcp-window-tracking patch
> fail to apply cleanly.  The patch in
> pending/24_conntrack-nosysctl.patch:
> 
> --- linux-2.4.21-pre5-ac3/net/ipv4/netfilter/ip_conntrack_core.c	Sat Mar 15 12:16:55 2003
> +++ linux-2.4.21-pre5-ac3-fixed/net/ipv4/netfilter/ip_conntrack_core.c	Sat Mar 15 12:23:34 2003
> @@ -1478,8 +1478,10 @@
>  	ip_ct_attach = ip_conntrack_attach;
>  	return ret;
>  
> +#ifdef CONFIG_SYSCTL
>  err_free_ct_cachep:
>  	kmem_cache_destroy(ip_conntrack_cachep);
> +#endif /*CONFIG_SYSCTL*/
>  err_free_hash:
>  	vfree(ip_conntrack_hash);
>  err_unreg_sockopt:
> 
> 
> is not accounted for in hunk 5 to file
> net/ipv4/netfilter/ip_conntrack_core.c in
> extra/tcp-window-tracking.patch.
> 
> I guess the question is, should it be expected that patches in suites
> like extra should apply if all of submitted and pending are applied.

Thanks for the report, I'll try to fix it up.

The answer is that I don't have time to check all the time if everything
still applies after new stuff has been added to pom.

-- 
/Martin

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Hervé Eychenne]

On Thu, Apr 03, 2003 at 12:15:43PM +0200, Martin Josefsson wrote:

> Thanks for the report, I'll try to fix it up.

> The answer is that I don't have time to check all the time if everything
> still applies after new stuff has been added to pom.

The best way is probably to have some scripts run regularly, trying
some patch-o-matic combinations (why not all, as patch is quite
fast...) to detect incompatibilities automatically, and especially
report new ones.
Such a list would be interesting.

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

On Thu, 2003-04-03 at 13:15, Hervé Eychenne wrote:
> On Thu, Apr 03, 2003 at 12:15:43PM +0200, Martin Josefsson wrote:
> 
> > Thanks for the report, I'll try to fix it up.
> 
> > The answer is that I don't have time to check all the time if everything
> > still applies after new stuff has been added to pom.
> 
> The best way is probably to have some scripts run regularly, trying
> some patch-o-matic combinations (why not all, as patch is quite
> fast...) to detect incompatibilities automatically, and especially
> report new ones.
> Such a list would be interesting.

If someone builds the scripts needed :)

tcp-window-tracking.patch should soon be updated in cvs to reflect the
changes.

-- 
/Martin

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[netfilter]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Thu, Apr 03, 2003 at 12:15:43PM +0200, Martin Josefsson wrote:
> 
> Thanks for the report, I'll try to fix it up.

Excellent!

> The answer is that I don't have time to check all the time if everything
> still applies after new stuff has been added to pom.

No, of course not.  My appologies if that is how my message came
across.  My question was more a case of, "should I report when this
happens or is it to be expected with so many patches to be applied"
(kinda like maintaining a kernel these days :-).

You are welcome for the report in any case however.

Thanx for the great work!

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

rmmod ip_conntrack hangs ...?

[marian stagarescu]

i get occasional rmmod ip_conntrack hanging and never returns

is this a known/old/resolved issue ?
i run on 2.4.17 pached up with newnat13 ...

# lsmod 
Module                  Size  Used by
ip_nat_talk             3128   0 (unused)
ip_conntrack_talk       2940   2
ip_nat_tftp             2312   0 (unused)
ip_conntrack_tftp       2236   1
ip_nat_irc              3272   0 (unused)
ip_conntrack_irc        3868   1
ip_nat_h323             3376   0 (unused)
ip_conntrack_h323       3100   1
ip_nat_ftp              4088   0 (unused)
ip_conntrack_ftp        5036   1
ipt_multiport           1004   0 (unused)
ipt_REDIRECT            1076   0 (unused)
ipt_limit               1388   0 (unused)
ipt_LOG                 4412   0 (unused)
ipt_state                952   0 (unused)
ipt_MASQUERADE          1716   0 (unused)
iptable_nat            23192   6 [ip_nat_talk ip_nat_tftp ip_nat_irc
ip_nat_h323 ip_nat_ftp ipt_REDIRECT i
pt_MASQUERADE]
iptable_filter          2124   0 (unused)
ip_conntrack           30080   8 [ip_nat_talk ip_conntrack_talk
ip_nat_tftp ip_conntrack_tftp ip_nat_irc i
p_conntrack_irc ip_nat_h323 ip_conntrack_h323 ip_nat_ftp
ip_conntrack_ftp ipt_REDIRECT ipt_state ipt_MASQU
ERADE iptable_nat]
ip_tables              14688  10 [ipt_multiport ipt_REDIRECT ipt_limit
ipt_LOG ipt_state ipt_MASQUERADE ip
table_nat iptable_filter]


and after:

# /sbin/lsmod 
Module                  Size  Used by
ip_conntrack           30080   0 (deleted)
ip_tables              14688   0



On Thu, 2003-04-03 at 08:57, netfilter@interlinx.bc.ca wrote:
> On Thu, Apr 03, 2003 at 12:15:43PM +0200, Martin Josefsson wrote:
> > 
> > Thanks for the report, I'll try to fix it up.
> 
> Excellent!
> 
> > The answer is that I don't have time to check all the time if
> everything
> > still applies after new stuff has been added to pom.
> 
> No, of course not.  My appologies if that is how my message came
> across.  My question was more a case of, "should I report when this
> happens or is it to be expected with so many patches to be applied"
> (kinda like maintaining a kernel these days :-).
> 
> You are welcome for the report in any case however.
> 
> Thanx for the great work!
> 
> b.
> 
> -- 
> Brian J. Murrell

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Jozsef Kadlecsik]

On 3 Apr 2003, Martin Josefsson wrote:

> > The best way is probably to have some scripts run regularly, trying
> > some patch-o-matic combinations (why not all, as patch is quite
> > fast...) to detect incompatibilities automatically, and especially
> > report new ones.
> > Such a list would be interesting.
>
> If someone builds the scripts needed :)

I have just updated the runme script in patch-o-matic:

- removed copying the source trees at patch testing (faster processing)
- added patch-dependency support

> tcp-window-tracking.patch should soon be updated in cvs to reflect the
> changes.

I'll update the tcp-window-tracking patch around the end of the next week.
I want to test the new version in production before releasing it.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

On Fri, 2003-04-04 at 10:46, Jozsef Kadlecsik wrote:

> I have just updated the runme script in patch-o-matic:
> 
> - removed copying the source trees at patch testing (faster processing)

Gives a quite nice speedup :)

> - added patch-dependency support

This is very nice.

But do we really want to check dependencies in reverse mode?

Say I have patches B and C which both depends on patch A.
I patch in B and A is automagically applied, then I apply C.
Then I reverse B or C and as a result A is also backed out, oops.

    # Check the dependecy of the patch
    if [ -f "$1.depend" ]; then

should probably be

    # Check the dependecy of the patch
    if [ -f "$1.depend" -a -z "$MODE" ]; then

which also makes some of the code below redundant.

I've tested this and it works fine.
(changed both the testing and applying)

If that's ok with you I'll commit it together with my changes that adds
support for conflicting patches as well. just add "not " first on the
line in the .depend file.

so tcp-window-tracking.patch.depend would look like:

not extra/ip_conntrack-timeouts.patch

And if ip_conntrack-timeouts.patch already is applied you get this
output:

Patch extra/tcp-window-tracking.patch conflicts with extra/ip_conntrack-timeouts.patch...
ip_conntrack-timeouts.patch ALREADY APPLIED (0 rejects out of 10 hunks).

Conflicting dependency.
   extra/tcp-window-tracking.patch
is incompatible with
   extra/ip_conntrack-timeouts.patch

and it stops.

It skips empty lines and lines beginning with # in the .depend files

I've also added a check if we are using force in apply_patch_depend()
and if we are deps won't be checked.

I've tested my changes with various dependencies and conflicts and it
seems to work.

> > tcp-window-tracking.patch should soon be updated in cvs to reflect the
> > changes.
> 
> I'll update the tcp-window-tracking patch around the end of the next week.
> I want to test the new version in production before releasing it.

Ok, I just updated the current version to apply after
pending/24_conntrack-nosysctl.patch has been applied.

-- 
/Martin

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

On Sat, 2003-04-05 at 13:16, Martin Josefsson wrote:
> On Fri, 2003-04-04 at 10:46, Jozsef Kadlecsik wrote:
> 
> > I have just updated the runme script in patch-o-matic:
> > 
> > - removed copying the source trees at patch testing (faster processing)
> 
> Gives a quite nice speedup :)

And makes dependencies fail :(

If patch A requires that patch B is applied before it can apply we are
screwed :) Nothing is applied during testing so even if patch B tests
fine, patch A won't apply since it depends on B which wasn't applied.

So we need to run the tests against a copy of the sourcetree _if_ we
have dependencies (really only if we have real dependencies and not
conflicting dependencies). And it's only the first patch that should
only be tested, the others can be applied directly onto the copy of the
sourcetree (the dependency checks are still performed)

I'll look at it more closely a little later today.

-- 
/Martin

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Jozsef Kadlecsik]

Hi Martin,

On 5 Apr 2003, Martin Josefsson wrote:

> But do we really want to check dependencies in reverse mode?
>
> Say I have patches B and C which both depends on patch A.
> I patch in B and A is automagically applied, then I apply C.
> Then I reverse B or C and as a result A is also backed out, oops.
>
>     # Check the dependecy of the patch
>     if [ -f "$1.depend" ]; then
>
> should probably be
>
>     # Check the dependecy of the patch
>     if [ -f "$1.depend" -a -z "$MODE" ]; then
>
> which also makes some of the code below redundant.

Yes, I think you're right.

> I've tested this and it works fine.
> (changed both the testing and applying)
>
> If that's ok with you I'll commit it together with my changes that adds
> support for conflicting patches as well. just add "not " first on the
> line in the .depend file.
>
> so tcp-window-tracking.patch.depend would look like:
>
> not extra/ip_conntrack-timeouts.patch
>
> And if ip_conntrack-timeouts.patch already is applied you get this
> output:
>
> Patch extra/tcp-window-tracking.patch conflicts with extra/ip_conntrack-timeouts.patch...
> ip_conntrack-timeouts.patch ALREADY APPLIED (0 rejects out of 10 hunks).
>
> Conflicting dependency.
>    extra/tcp-window-tracking.patch
> is incompatible with
>    extra/ip_conntrack-timeouts.patch
>
> and it stops.
>
> It skips empty lines and lines beginning with # in the .depend files
>
> I've also added a check if we are using force in apply_patch_depend()
> and if we are deps won't be checked.
>
> I've tested my changes with various dependencies and conflicts and it
> seems to work.

Great suggestions! Feel free to introduce them all.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Sat, 2003-04-05 at 14:28, Martin Josefsson wrote:

> I'll look at it more closely a little later today.

Seems to work fine in my new runme version.

I've attached two patches.
The first is my changes up till before I added this last copy-stuff.
The second is the copy-stuff I just added.

Do you see any problems? If not I'll commit the new version.

-- 
/Martin

[-- Attachment #2: runme-conflict --]
[-- Type: text/plain, Size: 4192 bytes --]

--- runme	2003-04-05 02:07:27.000000000 +0200
+++ runme-works	2003-04-05 13:14:27.000000000 +0200
@@ -302,30 +302,60 @@
 test_patch_depend()
 {
     # Check the dependecy of the patch
-    if [ -f "$1.depend" ]; then
+    if [ -f "$1.depend" -a -z "$MODE" ]; then
 	while read dep
 	do
+	    if [ -z "${dep/##*}" ]; then
+	    	continue
+	    fi
+
+	    not=0
+	    if [ -z "${dep/#not *}" ]; then
+		dep=${dep/#not }
+		not=1
+	    fi
+	    
 	    f=${dep%%.patch*}	# filename without .patch*
 	    p=${dep##$f.patch}	# protocol, if exist
 	    p=${p##.}
 	    n=$f${p:+-$p}
 	    if [ "`echo $PROCESSED | grep $n`" ]; then
-		continue
+		if [ $not == 1 ]; then
+			echo >&2
+			echo "Conflicting dependency." >&2
+			echo "   $1" >&2
+			echo "is incompatible with" >&2
+			echo "   $dep" >&2
+			echo >&2
+			return 1
+		else
+			continue
+		fi
 	    elif [ "`echo $DEPEND | grep $dep`" ]; then
+		echo >&2
 		echo "Circular dependency, patch $1 cannot be applied." >&2
  		echo "Report the problem to the patch-o-matic maintainer." >&2
+		echo >&2
 		return 1
 	    fi
-	    echo Patch $1 depends on $dep...
+	    if [ $not == 1 ]; then
+		echo Patch $1 conflicts with $dep...
+	    else
+	    	echo Patch $1 depends on $dep...
+	    fi
 	    DEPEND="$DEPEND $dep"
-	    isapplied=
             if ./isapplied $KERNEL_DIR $dep
 	    then 
-		isapplied=Y
-	    fi
-            if [ "$isapplied" -a -z "$MODE" ] || [ ! "$isapplied" -a -n "$MODE" ]
-            then :
-            elif test_patch_depend $dep ${p:-"ipv4"}
+		if [ $not == 1 ]; then
+			echo >&2
+			echo "Conflicting dependency." >&2
+			echo "   $1" >&2
+			echo "is incompatible with" >&2
+			echo "   $dep" >&2
+			echo >&2
+			return 1
+		fi
+            elif [ $not == 1 ] || test_patch_depend $dep ${p:-"ipv4"}
 	    then :
 	    else
 		return 1
@@ -402,30 +432,60 @@
 apply_patch_depend()
 {
     # Check the dependecy of the patch
-    if [ -f "$1.depend" ]; then
+    if [ -z "$3" -a -f "$1.depend" -a -z "$MODE" ]; then
 	while read dep
 	do
+	    if [ -z "${dep/##*}" ]; then
+	    	continue
+	    fi
+
+	    not=0
+	    if [ -z "${dep/#not *}" ]; then
+		dep=${dep/#not }
+		not=1
+	    fi
+
 	    f=${dep%%.patch*}	# filename without .patch*
 	    p=${dep##$f.patch}	# protocol, if exist
 	    p=${p##.}
 	    n=$f${p:+-$p}
 	    if [ "`echo $PROCESSED | grep $n`" ]; then
-		continue
+		if [ $not == 1 ]; then
+			echo >&2
+			echo "Conflicting dependency." >&2
+			echo "   $1" >&2
+			echo "is incompatible with" >&2
+			echo "   $dep" >&2
+			echo >&2
+			return 1
+		else
+			continue
+		fi
 	    elif [ "`echo $DEPEND | grep $dep`" ]; then
+		echo >&2
 		echo "Circular dependency, patch $1 cannot be applied." >&2
  		echo "Report the problem to the patch-o-matic maintainer." >&2
+		echo >&2
 		return 1
 	    fi
-	    echo Patch $1 depends on $dep...
+	    if [ $not == 1 ]; then
+		echo Patch $1 conflicts with $dep...
+	    else
+	    	echo Patch $1 depends on $dep...
+	    fi
 	    DEPEND="$DEPEND $dep"
-	    isapplied=
             if ./isapplied $KERNEL_DIR $dep
 	    then 
-		isapplied=Y
-	    fi
-            if [ "$isapplied" -a -z "$MODE" ] || [ ! "$isapplied" -a -n "$MODE" ]
-            then :
-	    elif apply_patch_depend $dep ${p:-"ipv4"}
+		if [ $not == 1 ]; then
+			echo >&2
+			echo "Conflicting dependency." >&2
+			echo "   $1" >&2
+			echo "is incompatible with" >&2
+			echo "   $dep" >&2
+			echo >&2
+			return 1
+		fi
+	    elif [ $not == 1 ] || apply_patch_depend $dep ${p:-"ipv4"}
 	    then :
 	    else
 		return 1
@@ -493,7 +553,7 @@
 apply_patch()
 {
     DEPEND=$1
-    apply_patch_depend $1 $2
+    apply_patch_depend $1 $2 $3
 }
 
 # Reverse order of arguments.
@@ -664,7 +724,7 @@
 			    test_patch $THIS_PATCH ${PROTO:-"ipv4"}
 			    ;;
 		        f*|F*)
-			    apply_patch $THIS_PATCH ${PROTO:-"ipv4"}
+			    apply_patch $THIS_PATCH ${PROTO:-"ipv4"} force
 			    PROCESSED="$PROCESSED $SUITE/$BASE${PROTO:+-$PROTO}"
 			    entertocont # pause before screen is cleared by printheader
 			    ;;

[-- Attachment #3: runme-copy --]
[-- Type: text/plain, Size: 6626 bytes --]

--- ../../tmp/runme-works	2003-04-05 13:14:27.000000000 +0200
+++ runme	2003-04-05 16:33:04.000000000 +0200
@@ -48,6 +48,14 @@
 	echo
 }
 
+#
+# WARNING: this function could fail, always check the output.
+#
+tmpdirname()
+{
+	dd if=/dev/urandom bs=32 count=1 2>/dev/null | od -x -w32 -A n | tr -d ' '
+}
+
 # Too many rejects from trying to patch Configure.help/Config.help and Config.in.
 # So we use special format: First line specifies entry we want to
 # follow, and rest of file is pasted in under that.
@@ -344,7 +352,7 @@
 	    	echo Patch $1 depends on $dep...
 	    fi
 	    DEPEND="$DEPEND $dep"
-            if ./isapplied $KERNEL_DIR $dep
+            if ./isapplied $KTMPDIR $dep
 	    then 
 		if [ $not == 1 ]; then
 			echo >&2
@@ -355,7 +363,7 @@
 			echo >&2
 			return 1
 		fi
-            elif [ $not == 1 ] || test_patch_depend $dep ${p:-"ipv4"}
+            elif [ $not == 1 ] || apply_patch_depend $dep ${p:-"ipv4"}
 	    then :
 	    else
 		return 1
@@ -365,21 +373,21 @@
 
     echo Testing patch $1...
 
-    if [ -f "$KERNEL_DIR/net/$2/netfilter/Config.help" ]; then
+    if [ -f "$KTMPDIR/net/$2/netfilter/Config.help" ]; then
     	DOCUMENTATIONFILE="net/$2/netfilter/Config.help"
-    elif [ -f "$KERNEL_DIR/Documentation/Configure.help" ]; then
+    elif [ -f "$KTMPDIR/Documentation/Configure.help" ]; then
         DOCUMENTATIONFILE="Documentation/Configure.help"
     else
         echo Warning - no help text file could be found in either >&2
-        echo $KERNEL_DIR/net/$2/netfilter/Config.help >&2
-        echo or $KERNEL_DIR/Documentation/Configure.help >&2
+        echo $KTMPDIR/net/$2/netfilter/Config.help >&2
+        echo or $KTMPDIR/Documentation/Configure.help >&2
 	DOCUMENTATIONFILE=/dev/null
     fi
 
-    if apply_config_in_changes $1 $KERNEL_DIR/net/$2/netfilter test &&
-	apply_config_help_changes $1 $KERNEL_DIR/$DOCUMENTATIONFILE test &&
-	apply_makefile_changes $1 $KERNEL_DIR/net/$2/netfilter test &&
-	apply_conntrack_h_changes $1 $KERNEL_DIR/include/linux/netfilter_$2 test
+    if apply_config_in_changes $1 $KTMPDIR/net/$2/netfilter test &&
+	apply_config_help_changes $1 $KTMPDIR/$DOCUMENTATIONFILE test &&
+	apply_makefile_changes $1 $KTMPDIR/net/$2/netfilter test &&
+	apply_conntrack_h_changes $1 $KTMPDIR/include/linux/netfilter_$2 test
     then :
     else
 	return 1
@@ -387,14 +395,14 @@
 
     if [ $MODE ]
     then
-    	REJECTS=`(cd $KERNEL_DIR && patch -R -p1 --dry-run | grep FAILED) < $1`
+    	REJECTS=`(cd $KTMPDIR && patch -R -p1 --dry-run | grep FAILED) < $1`
     else
-    	REJECTS=`(cd $KERNEL_DIR && patch -p1 --dry-run | grep FAILED) < $1`
+    	REJECTS=`(cd $KTMPDIR && patch -p1 --dry-run | grep FAILED) < $1`
     fi
 
     if [ "$REJECTS" ]
     then
-	echo "Testing of patch failed in $KERNEL_DIR" >&2
+	echo "Failed to patch copy of $KERNEL_DIR" >&2
 	return 1
     fi
     if [ ! -e $1.userspace ];
@@ -425,7 +433,32 @@
 test_patch()
 {
     DEPEND=$1
-    test_patch_depend $1 $2
+
+    if [ -f "$1.depend" -a -z "$MODE" ]; then
+	KTMPDIR=`tmpdirname`
+	# I'm really paranoid.  What if there's no /dev/urandom?
+	if [ -z "$KTMPDIR" ]; then
+	   echo Failed to generate kernel tmpdirname: perhaps your /dev/urandom is broken >&2
+	   exit 1
+	fi
+	KTMPDIR=$KERNEL_DIR/../$KTMPDIR
+	if cp -al $KERNEL_DIR/. $KTMPDIR
+	then :
+	else
+	   echo Failed to make copy of $KERNEL_DIR >&2
+	   rm -rf $KTMPDIR
+	   exit 1
+	fi
+
+	test_patch_depend $1 $2
+	ret=$?
+	
+	rm -rf $KTMPDIR
+	return $ret
+    else
+	    KTMPDIR=$KERNEL_DIR
+	    test_patch_depend $1 $2
+    fi
 }
 
 # Args: patch filename, protocol.
@@ -474,7 +507,7 @@
 	    	echo Patch $1 depends on $dep...
 	    fi
 	    DEPEND="$DEPEND $dep"
-            if ./isapplied $KERNEL_DIR $dep
+            if ./isapplied $KTMPDIR $dep
 	    then 
 		if [ $not == 1 ]; then
 			echo >&2
@@ -494,15 +527,15 @@
     fi
 
     echo `modesense 3` patch $1...
-    REJECTSBEFORE="`find $KERNEL_DIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
+    REJECTSBEFORE="`find $KTMPDIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
     if [ -e $1.userspace ];
     then
         REJECTSBEFOREU="`find $NETFILTERDIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
     fi
-    if (cd $KERNEL_DIR && if [ $MODE ]; then patch -R -p1; else patch -p1; fi > /dev/null) < $1
+    if (cd $KTMPDIR && if [ $MODE ]; then patch -R -p1; else patch -p1; fi > /dev/null) < $1
     then :
     else
-	echo Failed to patch $KERNEL_DIR >&2
+	echo Failed to patch copy of $KERNEL_DIR >&2
 	return 1
     fi
     if [ -e $1.userspace ];
@@ -514,7 +547,7 @@
             return 1
         fi
     fi
-    REJECTSAFTER="`find $KERNEL_DIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
+    REJECTSAFTER="`find $KTMPDIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
     if [ -e $1.userspace ];
     then
         REJECTSAFTERU="`find $NETFILTERDIR/. -name '*.rej' -exec cat {} \; | grep -c '^\*\*\* '`"
@@ -525,7 +558,7 @@
         if [ "$REJECTSBEFORE" -ne "$REJECTSAFTER" ] || [ "$REJECTSBEFOREU" -ne "$REJECTSAFTERU" ];
         then
             echo WARNING: patch $1 seems to have had rejects \(`expr $REJECTSAFTER + $REJECTSAFTERU - $REJECTSBEFORE - $REJECTSBEFOREU` new rejections\):
-	    find $KERNEL_DIR/. -name '*rej'
+	    find $KTMPDIR/. -name '*rej'
 	    find $NETFILTERDIR/. -name '*rej'
         else
 	    echo "   Patch $1 `modesense 2` cleanly."
@@ -538,20 +571,21 @@
         if [ "$REJECTSBEFORE" -ne "$REJECTSAFTER" ];
         then
             echo WARNING: patch $1 seems to have had rejects \(`expr $REJECTSAFTER - $REJECTSBEFORE` new rejections\):
-	    find $KERNEL_DIR/. -name '*rej'
+	    find $KTMPDIR/. -name '*rej'
         else
 	    echo "   Patch $1 `modesense 2` cleanly."
         fi
     fi
-    apply_config_in_changes $1 $KERNEL_DIR/net/$2/netfilter/
-    apply_config_help_changes $1 $KERNEL_DIR/$DOCUMENTATIONFILE
-    apply_makefile_changes $1 $KERNEL_DIR/net/$2/netfilter/
-    apply_conntrack_h_changes $1 $KERNEL_DIR/include/linux/netfilter_$2
+    apply_config_in_changes $1 $KTMPDIR/net/$2/netfilter/
+    apply_config_help_changes $1 $KTMPDIR/$DOCUMENTATIONFILE
+    apply_makefile_changes $1 $KTMPDIR/net/$2/netfilter/
+    apply_conntrack_h_changes $1 $KTMPDIR/include/linux/netfilter_$2
 }
 
 # Args: patch filename, protocol.
 apply_patch()
 {
+    KTMPDIR=$KERNEL_DIR
     DEPEND=$1
     apply_patch_depend $1 $2 $3
 }

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Jozsef Kadlecsik]

On 5 Apr 2003, Martin Josefsson wrote:

> > > - removed copying the source trees at patch testing (faster processing)
> >
> > Gives a quite nice speedup :)
>
> And makes dependencies fail :(
>
> If patch A requires that patch B is applied before it can apply we are
> screwed :) Nothing is applied during testing so even if patch B tests
> fine, patch A won't apply since it depends on B which wasn't applied.

I see what you mean. Strange, the patches I used at the testing did depend
on each other.

Then if a patch depends on other patches an any of them isn't applied yet,
then stop and ask to apply that missing patch immediately. Thus we can
keep consistency without the need of copying the source trees.

What do you think?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: tcp-window-tracking vs. pending/24_conntrack-nosysctl.patch

[Martin Josefsson]

On Sat, 2003-04-05 at 16:51, Jozsef Kadlecsik wrote:

> I see what you mean. Strange, the patches I used at the testing did depend
> on each other.
> 
> Then if a patch depends on other patches an any of them isn't applied yet,
> then stop and ask to apply that missing patch immediately. Thus we can
> keep consistency without the need of copying the source trees.
> 
> What do you think?

I think this might be a better solution than my ugly hack that copies
the sourcetree and then doesn't ask the user if he/she/it really wants
to apply the patch. The downside is that if the user wants to install
patch A which requires B which in turn requires C and patch B fails,
then you have a tree which contains C and nothing more. It might be
nicer to the user to not modify anything if something in the
dependency-chain fails.

-- 
/Martin