Call for testing: patch-o-matic-ng

Call for testing: patch-o-matic-ng

[Harald Welte]

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

Hi!

I've now gotten patch-o-matic-ng to a state where it is actually quite
useable.  

Everybody interested can check it out from CVS
(netfilter/patch-o-matic-ng).  Everything should look exactly like the
old patch-o-matic, including screen output and command syntax.

However, the implementation behind the curtain is completely different.
Interested people are invited to look into the perl source of
Netfilter_POM.pm and 'runme'.

I would like to have people start testing/using pom-ng and report errors
back to me (via email).

The differences from a user's point of view:

- dependencies are resolved recursively
- verbose error reporting
- new, more verbose './runme --man' documentation
- if you want to apply a specific set of patches, don't prefix them
  with the repository name (i.e. use
  	./runme pptp-conntrack-nat
  instead of
  	./runme extra/pptp-conntrack-nat

The differences from a developer's point of view:

- support for requirements (i.e. kernel >= 2.4.22)
- recursive dependencies
- support for multiple kernel build systems (i.e. 2.4.x and 2.6.x)
- automatic creation of Configure.help entries / Kconfig help sections
  from the patches 'help' file
- no wholefile-patches in CVS.  This means that entirely new files like
  net/ipv4/netfilter/ipt_foo.c / ipt_foo.h are not stored as patches but
  rather in their original form.   This in turn means real version
  control on the sourcecode!
- backend seperated from frontend (i.e. other user frontends could be
  implemented
- not limited to the linux sourcecode.  It is easy to add support for
  other projects (if a patchlet would have to patch other software, too)

However, some stuff is still missing (see the patch-o-matic/TODO file).
I'm working on implementing those missing features, though.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng

[KOVACS Krisztian]

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


  Hi,

2003-12-21, v keltezéssel 13:24-kor Harald Welte ezt írta:
> I would like to have people start testing/using pom-ng and report errors
> back to me (via email).

  I've tried it, and had some problems with it. Namely, the following
error message (Debian woody and sid, perl 5.6.1 and 5.8.2):

hidden@big:~/patch-o-matic-ng$ ./runme 
Examining kernel in /usr/src/linux-2.4.22-tproxy113
Can't bless non-reference value at /usr/share/perl/5.6.1/Term/Cap.pm line 136.

  The patch attached fixed the problem.

-- 
 Regards,
   Krisztian KOVACS

[-- Attachment #2: tgetent.diff --]
[-- Type: text/x-patch, Size: 434 bytes --]

Index: runme
===================================================================
RCS file: /cvspublic/netfilter/patch-o-matic-ng/runme,v
retrieving revision 1.7
diff -u -r1.7 runme
--- runme	21 Dec 2003 19:03:23 -0000	1.7
+++ runme	22 Dec 2003 09:47:15 -0000
@@ -201,7 +201,7 @@
 }
 
 if (defined($ENV{TERM})) {
-	my $terminal = Term::Cap->Tgetent();
+	my $terminal = Tgetent Term::Cap {};
 	$clrscr = $terminal->Tputs('cl', 1);
 }
 

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

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

On Mon, Dec 22, 2003 at 10:56:26AM +0100, KOVACS Krisztian wrote:
>   I've tried it, and had some problems with it. Namely, the following
> error message (Debian woody and sid, perl 5.6.1 and 5.8.2):
> 
> hidden@big:~/patch-o-matic-ng$ ./runme 
> Examining kernel in /usr/src/linux-2.4.22-tproxy113
> Can't bless non-reference value at /usr/share/perl/5.6.1/Term/Cap.pm line 136.

thanks, I'll apply your fix.

>  Regards,
>    Krisztian KOVACS

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng (condition filter)

[Tim Gardner]

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

Harald,

The condition filter (at least for 2.6) has extra files:

condition/linux/net/ipv6/Makefile.ladd
condition/linux/net/ipv6/Config.in.ladd

The presense of Makefile.ladd will not allow the filter to be applied. I 
suspect Config.in.ladd will cause a similar problem for 2.4.

Attached is a patch that removes these files as well as patches 
ipt_condition.c for 2.6.

ipv6/netfilter/ipt_condition.c compiles with warnings. Since I'm not using it 
(and I'm basically lazy), I'll leave it up to the authors to make it correct 
for 2.6

rtg
-- 
Tim Gardner - timg@tpi.com
www.tpi.com 406-443-5357

[-- Attachment #2: condition.diffs --]
[-- Type: text/x-diff, Size: 2285 bytes --]

diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c	2003-12-18 11:47:55.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv4/netfilter/ipt_condition.c	2003-12-23 07:45:30.000000000 -0700
@@ -17,6 +17,7 @@
 \*-------------------------------------------*/
 
 #include<linux/module.h>
+#include <linux/version.h>
 #include<linux/proc_fs.h>
 #include<linux/spinlock.h>
 #include<linux/string.h>
@@ -90,9 +91,17 @@
 
 
 static int
-match(const struct sk_buff *skb, const struct net_device *in,
-      const struct net_device *out, const void *matchinfo, int offset,
-      const void *hdr, u_int16_t datalen, int *hotdrop)
+match(
+	const struct sk_buff *skb,
+	const struct net_device *in,
+	const struct net_device *out,
+	const void *matchinfo,
+	int offset,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
+	const void *hdr,
+	u_int16_t datalen,
+#endif
+	int *hotdrop)
 {
 	const struct condition_info *info =
 	    (const struct condition_info *) matchinfo;
diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd	2003-12-20 09:38:19.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Config.in.ladd	1969-12-31 17:00:00.000000000 -0700
@@ -1,2 +0,0 @@
-  dep_tristate '  MAC address match support' CONFIG_IP6_NF_MATCH_MAC $CONFIG_IP6_NF_IPTABLES
-  dep_tristate '  Condition variable match support' CONFIG_IP6_NF_MATCH_CONDITION $CONFIG_IP6_NF_IPTABLES
diff -r -u --new-file netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd
--- netfilter/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd	2003-12-20 09:38:19.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/condition/linux/net/ipv6/Makefile.ladd	1969-12-31 17:00:00.000000000 -0700
@@ -1,2 +0,0 @@
-obj-$(CONFIG_IP6_NF_MATCH_MARK) += ip6t_mark.o
-obj-$(CONFIG_IP6_NF_MATCH_CONDITION) += ip6t_condition.o

Re: Call for testing: patch-o-matic-ng (fuzzy filter)

[Tim Gardner]

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

Harald,

Attached is a patch file that corrects ipt_fuzzy.c for 2.6.

rtg
-- 
Tim Gardner - timg@tpi.com
www.tpi.com 406-443-5357

[-- Attachment #2: fuzzy.diff --]
[-- Type: text/x-diff, Size: 816 bytes --]

diff -r -u --new-file netfilter/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c netfilter.wrk/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c
--- netfilter/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c	2003-12-18 11:15:29.000000000 -0700
+++ netfilter.wrk/patch-o-matic-ng/fuzzy/linux/net/ipv4/netfilter/ipt_fuzzy.c	2003-12-23 08:07:52.000000000 -0700
@@ -17,6 +17,7 @@
 */
 
 #include <linux/module.h>
+#include <linux/version.h>
 #include <linux/skbuff.h>
 #include <linux/ip.h>
 #include <linux/random.h>
@@ -64,8 +65,10 @@
 	       const struct net_device *out,
 	       const void *matchinfo,
 	       int offset,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
 	       const void *hdr,
 	       u_int16_t datalen,
+#endif
 	       int *hotdrop)
 {
 	/* From userspace */

Re: Call for testing: patch-o-matic-ng (condition filter)

[Harald Welte]

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

On Tue, Dec 23, 2003 at 07:57:23AM -0700, Tim Gardner wrote:
> Harald,
> 
> The condition filter (at least for 2.6) has extra files:
> 
> condition/linux/net/ipv6/Makefile.ladd
> condition/linux/net/ipv6/Config.in.ladd
> 
> The presense of Makefile.ladd will not allow the filter to be applied. I 
> suspect Config.in.ladd will cause a similar problem for 2.4.

thanks a lot, I'm removing them from CVS right now.

> Attached is a patch that removes these files as well as patches 
> ipt_condition.c for 2.6.

we'd need lots of fixes like this one.  Are there any volunteers for submitting patches like this and making sure that 2.4.x and 2.6.x compile ok ?

> Tim Gardner - timg@tpi.com
-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng

[Gaël Le Mignot]

Hello,

I've tested pom-ng on 2.6.0  with USAGI patch, the patch-o-matic seems
to work, but the kernel doesn't compile (I put nearly all patches, and
select M in the kernel config wherever it was possible):

  CC      net/core/netfilter.o
net/core/netfilter.c: In function `nf_log_register':
net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
net/core/netfilter.c:760: error: for each function it appears in.)
net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
net/core/netfilter.c: In function `nf_log_unregister':
net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
make[3]: *** [net/core/netfilter.o] Error 1


I think maybe some patches doesn't work with 2.6, would it possible to
add a way to select patch that works with 2.6 ? like ./runme extra-2.6
or such ?

-- 
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

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

On Tue, Dec 23, 2003 at 02:13:15PM +0100, Gaël Le Mignot wrote:
> I've tested pom-ng on 2.6.0  with USAGI patch, the patch-o-matic seems
> to work, but the kernel doesn't compile (I put nearly all patches, and
> select M in the kernel config wherever it was possible):
> 
>   CC      net/core/netfilter.o
> net/core/netfilter.c: In function `nf_log_register':
> net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
> net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
> net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
> net/core/netfilter.c:760: error: for each function it appears in.)
> net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
> net/core/netfilter.c: In function `nf_log_unregister':
> net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
> make[3]: *** [net/core/netfilter.o] Error 1
> 
> 
> I think maybe some patches doesn't work with 2.6, would it possible to
> add a way to select patch that works with 2.6 ? like ./runme extra-2.6
> or such ?

yes, indeed.  There are numerous patches that would not work in the
2.6.x kernels.  They have yet to be identified.  Once they are
identified, we can put a special "requires" tag into the 'info' file of
those patches.

This way the 2.4 only patches would only be offered if you have a 2.4.x
kernel source (and vice-versa).

You could help us in finding out which patches compile and which ones
don't.

> -- 
> Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 12:30 pm, Harald Welte wrote:
> On Tue, Dec 23, 2003 at 02:13:15PM +0100, Gaël Le Mignot wrote:

<< much snippage >>
	
> yes, indeed.  There are numerous patches that would not work in the
> 2.6.x kernels.  They have yet to be identified.  Once they are
> identified, we can put a special "requires" tag into the 'info' file of
> those patches.
>
> This way the 2.4 only patches would only be offered if you have a 2.4.x
> kernel source (and vice-versa).
>
> You could help us in finding out which patches compile and which ones
> don't.
	Oh my ... more work for the weekend ... I'll go grab POM-ng shortly ... 
	(I'm building 2.6.0 kernel on a test basis at the moment)


> > --
> > Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr

Re: Call for testing: patch-o-matic-ng

[Gaël Le Mignot]

Hello Harald, hello netfiler list ;)

I did  some tests on which  patch from the patch-o-matic  works on 2.6
and which ones don't compile. Here is the complete result of my tests.

I just try compiling them (after applying patches on a vanilla 2.6.0),
I didn't try to load or use them.

I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
to display it - or do it so fast that I don't notice it.

Here is the list from 'base' and 'extra' sets:

**** BASE ****

Does not compile:

- pool, nf-log, raw:
  CC      net/core/netfilter.o
net/core/netfilter.c: In function `nf_log_register':
net/core/netfilter.c:760: warning: implicit declaration of function `br_write_lock_bh'
net/core/netfilter.c:760: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)
net/core/netfilter.c:760: error: (Each undeclared identifier is reported only once
net/core/netfilter.c:760: error: for each function it appears in.)
net/core/netfilter.c:765: warning: implicit declaration of function `br_write_unlock_bh'
net/core/netfilter.c: In function `nf_log_unregister':
net/core/netfilter.c:770: error: `BR_NETPROTO_LOCK' undeclared (first use in this function)

- HOPLIMIT: 
  Does not compile, but exists has ip6t_hl.o in vanilla 2.6.0

- connlimit:
  CC [M]  net/ipv4/netfilter/ipt_connlimit.o
net/ipv4/netfilter/ipt_connlimit.c:214: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_connlimit.c: In function `init':
net/ipv4/netfilter/ipt_connlimit.c:219: error: `ip_conntrack_module' undeclared (first use in this function)
net/ipv4/netfilter/ipt_connlimit.c:219: error: (Each undeclared identifier is reported only once
net/ipv4/netfilter/ipt_connlimit.c:219: error: for each function it appears in.)
net/ipv4/netfilter/ipt_connlimit.c:220: warning: implicit declaration of function `__MOD_INC_USE_COUNT'
net/ipv4/netfilter/ipt_connlimit.c: In function `fini':
net/ipv4/netfilter/ipt_connlimit.c:227: error: `ip_conntrack_module' undeclared (first use in this function)
net/ipv4/netfilter/ipt_connlimit.c:228: warning: implicit declaration of function `__MOD_DEC_USE_COUNT'

It seems to be module initialisation stuff changes, probably easy to fix.

- NETLINK:
  CC [M]  net/ipv4/netfilter/ipt_NETLINK.o
net/ipv4/netfilter/ipt_NETLINK.c:90: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_NETLINK.c:91: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_NETLINK.c: In function `fini':
net/ipv4/netfilter/ipt_NETLINK.c:115: error: structure has no member named `socket'
net/ipv4/netfilter/ipt_NETLINK.c:115: error: structure has no member named `socket'
make[3]: *** [net/ipv4/netfilter/ipt_NETLINK.o] Error 1

Compiles with warning:

  CC [M]  net/ipv4/netfilter/ipt_quota.o
net/ipv4/netfilter/ipt_quota.c:65: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_dstlimit.o
net/ipv4/netfilter/ipt_dstlimit.c:468: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_mport.o
net/ipv4/netfilter/ipt_mport.c:99: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_time.o
net/ipv4/netfilter/ipt_time.c:124: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_random.o
net/ipv4/netfilter/ipt_random.c:75: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_psd.o
net/ipv4/netfilter/ipt_psd.c: In function `ipt_psd_match':
net/ipv4/netfilter/ipt_psd.c:178: warning: comparison of distinct pointer types lacks a cast
net/ipv4/netfilter/ipt_psd.c:178: warning: comparison of distinct pointer types lacks a cast
net/ipv4/netfilter/ipt_psd.c: At top level:
net/ipv4/netfilter/ipt_psd.c:336: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_nth.o
net/ipv4/netfilter/ipt_nth.c:144: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_ipv4options.o
net/ipv4/netfilter/ipt_ipv4options.c:155: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_fuzzy.o
net/ipv4/netfilter/ipt_fuzzy.c:171: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_u32.o
net/ipv4/netfilter/ipt_u32.c:198: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_TTL.o
net/ipv4/netfilter/ipt_TTL.c:97: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_TTL.c:97: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.o
net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.c:66: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.c:66: warning: initialization from incompatible pointer type
  CC [M]  net/ipv6/netfilter/ip6table_mangle.o
net/ipv6/netfilter/ip6table_mangle.c: In function `ip6t_local_hook':
net/ipv6/netfilter/ip6table_mangle.c:162: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136)
  CC [M]  net/ipv6/netfilter/ip6t_REJECT.o
net/ipv6/netfilter/ip6t_REJECT.c: In function `reject6_target':
net/ipv6/netfilter/ip6t_REJECT.c:149: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:152: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:155: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:158: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
net/ipv6/netfilter/ip6t_REJECT.c:161: warning: passing arg 5 of `icmpv6_send' discards qualifiers from pointer target type
  CC [M]  net/ipv4/netfilter/ipt_osf.o
net/ipv4/netfilter/ipt_osf.c:83: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_realm.o
net/ipv4/netfilter/ipt_realm.c:55: warning: initialization from incompatible pointer type

Compiles without warning:

NETMAP SAME iprange 


**** EXTRA ****

Does not compile:

- rsh
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:88: error: field `ct_rsh_info' has incomplete type

- mms-conntrack-nat 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:89: error: field `ct_mms_info' has incomplete type

- h323-conntrack-nat 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:90: error: field `ct_h225_info' has incomplete type

- cuseemee-nat
oops forgot to copy/paste the error message, sorry

- rtsp-conntrack 
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:74: error: field `ct_rtsp_info' has incomplete type

- talk-conntrack-nat
  CC      net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:26:
include/linux/netfilter_ipv4/ip_conntrack.h:89: error: field `ct_talk_info' has incomplete type


Compiles with warning:

  CC [M]  net/ipv4/netfilter/ipt_IPMARK.o
net/ipv4/netfilter/ipt_IPMARK.c:72: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_IPMARK.c:72: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_CONNMARK.o
net/ipv4/netfilter/ipt_CONNMARK.c:71: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_CONNMARK.c:71: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_egg.o
net/ipv4/netfilter/ip_conntrack_egg.c: In function `init':
net/ipv4/netfilter/ip_conntrack_egg.c:207: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_XOR.o
net/ipv4/netfilter/ipt_XOR.c:94: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_XOR.c:94: warning: initialization from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_rpc_tcp.o
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `alloc_request_p':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: missing braces around initializer
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: excess elements in struct initializer
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:165: warning: initialization makes integer from pointer without a cast
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `check_rpc_packet':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:252: warning: operation on `data' may be undefined
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c: In function `init':
net/ipv4/netfilter/ip_conntrack_rpc_tcp.c:457: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ip_conntrack_rpc_udp.o
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `alloc_request_p':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: missing braces around initializer
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: excess elements in struct initializer
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:164: warning: (near initialization for `(anonymous).timeout.lock')
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:165: warning: initialization makes integer from pointer without a cast
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `check_rpc_packet':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:252: warning: operation on `data' may be undefined
net/ipv4/netfilter/ip_conntrack_rpc_udp.c: In function `init':
net/ipv4/netfilter/ip_conntrack_rpc_udp.c:452: warning: assignment from incompatible pointer type
  CC [M]  net/ipv4/netfilter/ipt_rpc.o
net/ipv4/netfilter/ipt_rpc.c:76: warning: type defaults to `int' in declaration of `EXPORT_NO_SYMBOLS'
net/ipv4/netfilter/ipt_rpc.c:76: warning: data definition has no type or storage class
net/ipv4/netfilter/ipt_rpc.c:389: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_rpc.c: In function `init':
net/ipv4/netfilter/ipt_rpc.c:398: warning: implicit declaration of function `__MOD_INC_USE_COUNT'
net/ipv4/netfilter/ipt_rpc.c: In function `fini':
net/ipv4/netfilter/ipt_rpc.c:421: warning: implicit declaration of function `__MOD_DEC_USE_COUNT'

*** Warning: "__MOD_DEC_USE_COUNT" [net/ipv4/netfilter/ipt_rpc.ko] undefined!
*** Warning: "__MOD_INC_USE_COUNT" [net/ipv4/netfilter/ipt_rpc.ko] undefined!

  CC [M]  net/ipv4/netfilter/ipt_addrtype.o
net/ipv4/netfilter/ipt_addrtype.c:50: warning: initialization from incompatible pointer type

  CC [M]  net/ipv4/netfilter/ipt_TCPLAG.o
net/ipv4/netfilter/ipt_TCPLAG.c: In function `divide_down':
net/ipv4/netfilter/ipt_TCPLAG.c:102: warning: statement with no effect
net/ipv4/netfilter/ipt_TCPLAG.c: At top level:
net/ipv4/netfilter/ipt_TCPLAG.c:643: warning: initialization from incompatible pointer type
net/ipv4/netfilter/ipt_TCPLAG.c:644: warning: initialization from incompatible pointer type

Compiles without warning:

quake3-conntrack-nat
   


-- 
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> Hello Harald, hello netfiler list ;)
>
> I did  some tests on which  patch from the patch-o-matic  works on 2.6
> and which ones don't compile. Here is the complete result of my tests.
>
> I just try compiling them (after applying patches on a vanilla 2.6.0),
> I didn't try to load or use them.
>
> I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
> to display it - or do it so fast that I don't notice it.
>
>
	Agreed -- same here -- offlist to Harald as well since I think my perl is weirding out on us.

	Alistair

Re: Call for testing: patch-o-matic-ng

[Unknown, Alistair Tonner]

On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> Hello Harald, hello netfiler list ;)
>
> I did  some tests on which  patch from the patch-o-matic  works on 2.6
> and which ones don't compile. Here is the complete result of my tests.
>
> I just try compiling them (after applying patches on a vanilla 2.6.0),
> I didn't try to load or use them.
>
> I've noticed too that when  a patch doesn't apply, pom-ng doesn't seem
> to display it - or do it so fast that I don't notice it.
>
>
	Agreed -- same here -- offlist to Harald as well since I think my perl is weirding out on us.

	Alistair

Re: Call for testing: patch-o-matic-ng

[Galtar]

Hi!

Can anybody can tell me where I can download Patch-o-magic-ng???

-- 
Best regards,
 Galtar                            mailto:galtar2@wp.pl

Re: Call for testing: patch-o-matic-ng

[Antony Stone]

On Thursday 25 December 2003 9:06 am, Galtar wrote:

> Hi!
>
> Can anybody can tell me where I can download Patch-o-magic-ng???

Quoting from Harald's original posting in this thread:

"Everybody interested can check it out from CVS
(netfilter/patch-o-matic-ng).  Everything should look exactly like the
old patch-o-matic, including screen output and command syntax."

See http://www.netfilter.org/downloads.html#cvs for more details.

Antony.

-- 
In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Call for testing: patch-o-matic-ng

[Henrik Nordstrom]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2145 bytes --]

On Sun, 21 Dec 2003, Harald Welte wrote:

> - no wholefile-patches in CVS.  This means that entirely new files like
>   net/ipv4/netfilter/ipt_foo.c / ipt_foo.h are not stored as patches but
>   rather in their original form.   This in turn means real version
>   control on the sourcecode!

One idea for further improvement:

It would be nice if runme could support "wholefile modifications" where
both the whole original and patched files are stored rather than a diff
(patch generated on the fly when applying to the kernel source tree). This
simplifies the development phase of a extension requiring patching of
other files and also simplifies maintenance of major rewrites.

I have been using the above model for a number of kernel projects for a
long time and find it very successful at tracking the changes. What I do
is that my development tree only contains the changed files, and then a
script copies the changes over to the kernel tree. The script is designed
in such manner that it can be run multiple times to copy over new changes
to a already patched tree, completely eleminating the need to directly
modifying the full source tree directly during development.

The script I am using is attached to this message. to try it out grab for
example a copy of the user-mode-linux CVS tree or another project using
"full modified files" source layout, then place the script in the top 
level directory (the equivalence of the Linux top level source directory) 
and then run the script supplying the path to your full kernel tree as 
argument.

Note that agree that the main CVS repository probably should contain
patches like it is now rather than "wholefile patches".  But during
development I find maintaining a patch file is a little awkward and some
kind of changes easily get lost. And in the few cases where a patch mostly 
rewrites a existing file having it as a full file makes more sense than 
patch format.

> However, some stuff is still missing (see the patch-o-matic/TODO file).
> I'm working on implementing those missing features, though.

What is also missing is a equivalence to the NEWPATCHES document.

Regards
Henrik

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2397 bytes --]

#!/bin/sh
cd `dirname $0`

# This variable is used for backup copies to allow incremental patching
project=uml

KERNEL_DIR="${KERNEL_DIR:-/usr/src/linux-${project}}"
while [ $# -ge 1 ]; do
    case "$1" in
    -full)
	full=1;;
    -orig)
    	orig=1;;
    *)
    	break;;
    esac
    shift
done
KERNEL_DIR=${1:-${KERNEL_DIR}}
if [ ! -d ${KERNEL_DIR} ]; then
    echo "ERROR: No kernel directory"
    exit 1
fi
find . -name '.#*' -print0 | xargs -0 rm -f
# Create "original" copies of the Linux sources
if [ ! -d orig ] || [ $orig ]; then
  echo "First time. Creating \"pristine\" source copies in $PWD/orig"
  find . -type f -print -o -name 'orig' -prune | while read file; do
    if [ -f ${KERNEL_DIR}/$file ]; then
      mkdir -p orig/`dirname $file`
      cp -p ${KERNEL_DIR}/$file orig/$file
      echo "   $file"
    fi
  done
  if [ $orig ]; then
    exit
  fi
fi
# On full updates, get rid of all user-mode architecture files
if test $full; then
  rm -rf ${KERNEL_DIR}/arch/um ${KERNEL_DIR}/include/asm-um
fi
# Set up new UM kernel tree directories
find -name CVS -prune -o -name orig -prune -o -type d -print | (cd ${KERNEL_DIR} && xargs mkdir -p )
# Copy over UM kernel changes
echo "Patching kernel with UML changes"
find [^o]* -name CVS -prune -o -name .cvsignore -prune -o -name orig -prune -o -type f -print | while read f; do
  if test -f orig/$f; then
    first=
    # This is a patched file. Only copy over the changes, preserve
    # any other local modifications.
    if [ ! -f ${KERNEL_DIR}/$f.no${project} ]; then
      # First time. Make a backup copy of the original (possibly modified)
      # kernel source, so we can update it again later if needed
      cp -p ${KERNEL_DIR}/$f ${KERNEL_DIR}/$f.no${project}
      first=1
    fi
    if test $f -nt ${KERNEL_DIR}/$f || test $full || test $first; then
      # Apply the changes to the kernel tree
      if ! test $first; then
	rm -f ${KERNEL_DIR}/$f
	cp -p ${KERNEL_DIR}/$f.no${project} ${KERNEL_DIR}/$f
      fi
      diff -u orig/$f $f | patch -s ${KERNEL_DIR}/$f
      touch -r $f ${KERNEL_DIR}/$f
      echo "P   $f"
    fi
  else
    # This is a project specific file. Just copy it over.
    if ! test -f ${KERNEL_DIR}/$f || ! cmp -s $f ${KERNEL_DIR}/$f || test $full; then
      cp -p $f ${KERNEL_DIR}/$f
      echo "    $f"
    fi
  fi
done

ip_conntrack_pptp

[Jan Kaastrup]

Hi Harald and all on this list.

I have problems with ip_conntrack_pptp patch from POM-20031219

It seems the patch doesn't apply what it should:

"In the pptp-conntrack-nat.patch.configure.help it says something like
this:
CONFIG_IP_NF_CT_PROTO_GRE
  This module adds generic support for connection tracking and NAT of
the
  GRE protocol (RFC1701, RFC2784).  Please note that this will only work
  with GRE connections using the key field of the GRE header."

I do something like this for patching my kernel (2.4.21):
patch -p1 < ./path-o-mat.../ip_conntrack_pptp.patch, and everything
seems allright.

But I Never get the option in my kernelconfiguration - I want to make it
as a module.
I do have the ip_conntrack_pptp.c and .h file, maybe it is possible to
make my module out of them?


Does anyone know of this, or is it just me being stupid ?



Thanks a lot in regards

Jan

Re: ip_conntrack_pptp

[Harald Welte]

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

On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> Hi Harald and all on this list.
> 
> I have problems with ip_conntrack_pptp patch from POM-20031219
> Does anyone know of this, or is it just me being stupid ?

*sigh* *sigh* *sigh*.  

Does anybody actually ponder reading the 'README' file included in the
patch-o-matic package?

> Jan

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Unknown, Alistair Tonner]

On January 22, 2004 12:53 pm, Harald Welte wrote:
> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> >
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
>
> *sigh* *sigh* *sigh*.
>
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?


	I thought that was for padding to make the MD5 sums work??? 
	*grin*

	Alistair
>
> > Jan

Re: ip_conntrack_pptp

[Arnt Karlsen]

On Thu, 22 Jan 2004 12:53:45 -0500, 
Harald Welte <laforge@netfilter.org> wrote in message 
<20040122175345.GN1810@obroa-skai.de.gnumonks.org>:

> On Thu, Jan 22, 2004 at 04:57:26PM +0100, Jan Kaastrup wrote:
> > Hi Harald and all on this list.
> > 
> > I have problems with ip_conntrack_pptp patch from POM-20031219
> > Does anyone know of this, or is it just me being stupid ?
> 
> *sigh* *sigh* *sigh*.  
> 
> Does anybody actually ponder reading the 'README' file included in the
> patch-o-matic package?

..put it in the " *) " to bang it into our faces when we mistype, 
_some_ of it oughtta stick.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: ip_conntrack_pptp

[Harald Welte]

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

On Mon, Jan 26, 2004 at 10:20:10AM +0100, Jan Kaastrup wrote:
> Hi Harald
> 
> I have read the README file for POM - and I cannot find anything that
> could tell what is wrong:(

The README doesn't tell you anywhere to apply that patchc manually.  It
tells you to run the './runme' script.

However, you are telling me, that you are manually applying the patch.
Witch will only give you about 90% of the required changes, not all of
them.

> >I do something like this for patching my kernel (2.4.21):
> >patch -p1 < ./path-o-mat.../ip_conntrack_pptp.patch, and everything
> >seems allright.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

RE: Call for testing: patch-o-matic-ng

[Vilmos Branyik]

Alistair

Why are you using my name and email address for your posting?

Vilmos

> -----Original Message-----
> From: Vilmos Branyik 
> Sent: Tuesday, December 23, 2003 5:52 PM
> To: kilobug@freesurf.fr; Harald Welte
> Cc: Netfilter Development Mailinglist; Netfilter Mailinglist
> Subject: Re: Call for testing: patch-o-matic-ng
> 
> 
> On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> > Hello Harald, hello netfiler list ;)
> >
> > I did  some tests on which  patch from the patch-o-matic  
> works on 2.6
> > and which ones don't compile. Here is the complete result 
> of my tests.
> >
> > I just try compiling them (after applying patches on a 
> vanilla 2.6.0),
> > I didn't try to load or use them.
> >
> > I've noticed too that when  a patch doesn't apply, pom-ng 
> doesn't seem
> > to display it - or do it so fast that I don't notice it.
> >
> >
> 	Agreed -- same here -- offlist to Harald as well since 
> I think my perl is weirding out on us.
> 
> 	Alistair
> 

Matt Branyik
www.piopc.net
(719) 784-6955 

> -----Original Message-----
> From: Vilmos Branyik 
> Sent: Tuesday, December 23, 2003 5:52 PM
> To: kilobug@freesurf.fr; Harald Welte
> Cc: Netfilter Development Mailinglist; Netfilter Mailinglist
> Subject: Re: Call for testing: patch-o-matic-ng
> 
> 
> On December 23, 2003 07:26 pm, Gaël Le Mignot wrote:
> > Hello Harald, hello netfiler list ;)
> >
> > I did  some tests on which  patch from the patch-o-matic  
> works on 2.6
> > and which ones don't compile. Here is the complete result 
> of my tests.
> >
> > I just try compiling them (after applying patches on a 
> vanilla 2.6.0),
> > I didn't try to load or use them.
> >
> > I've noticed too that when  a patch doesn't apply, pom-ng 
> doesn't seem
> > to display it - or do it so fast that I don't notice it.
> >
> >
> 	Agreed -- same here -- offlist to Harald as well since 
> I think my perl is weirding out on us.
> 
> 	Alistair
> 

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

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

On Wed, Dec 31, 2003 at 09:51:51AM +0100, Jozsef Kadlecsik wrote:
> Unfortunately that's not so uncommon: nf-log, raw, TRACE, TCP window
> tracking patches, conntrack refcounting/locking/etc. patches, all
> conntrack/nat helpers, all targets which modify the packet.

yes, thanks for pointing this out.

> But seriously, when patch-o-matic is used in another project, that would
> be based on some software source code which would have got a version
> number. So 'kernel version' could be replaced by 'software version' above.
> And it could be implemented in Netfilter_POM.pm, without touching 'runme'
> (I think/hope).
> 
> I believe we should avoid the structure of separated directory trees for
> the different versions of the same patch.

ok, I'll implement multiple-version support, most likely tomorrow.  Have
to think about the ideal naming convention, though.

the 'patch' file should be called 'linux.patch' anyway.  help and info
should remain the same, since the description and information is valid
for for the whole patchlet, independent of how many per-project
directories or patches exist.

a 2.6 specific patch would then be inside a linux-2.6 directory.  The
only remaining question is:

- how to encode the information 'which patch for which version' in the 
  info file ?  We would need something like
  "if linux >= 2.6.0 && linux < 2.7.0, then use linux-2.6 and
  linux-2.6.patch"

- what about patchlets that have the same wholefiles but a different
  'patch' file.  I.e. a new conntrack helper that has the same source
  file, valid for 2.4 and 2.6 - but a different diff for patching
  something into conntrack_core ?

> Best regards,
> Jozsef

Happy new year, too.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng

[Jozsef Kadlecsik]

On Thu, 1 Jan 2004, Harald Welte wrote:

> a 2.6 specific patch would then be inside a linux-2.6 directory.  The
> only remaining question is:
>
> - how to encode the information 'which patch for which version' in the
>   info file ?  We would need something like
>   "if linux >= 2.6.0 && linux < 2.7.0, then use linux-2.6 and
>   linux-2.6.patch"
>
> - what about patchlets that have the same wholefiles but a different
>   'patch' file.  I.e. a new conntrack helper that has the same source
>   file, valid for 2.4 and 2.6 - but a different diff for patching
>   something into conntrack_core ?

Something like 'best match wins'?

linux-2.6.13		- just for 2.6.13
linux-2.6		- every (other) 2.6 release
linux-2.4		- every 2.4 release
linux			- every other release :-)

(Same goes for the linux.patch file.) 'Requires' could be used to set
general version bounds, like

Requires: linux >= 2.4.22

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: Call for testing: patch-o-matic-ng

[Herve Eychenne]

On Mon, Jan 05, 2004 at 12:32:35PM +0100, Jozsef Kadlecsik wrote:

> On Thu, 1 Jan 2004, Harald Welte wrote:

> > a 2.6 specific patch would then be inside a linux-2.6 directory.  The
> > only remaining question is:
> >
> > - how to encode the information 'which patch for which version' in the
> >   info file ?  We would need something like
> >   "if linux >= 2.6.0 && linux < 2.7.0, then use linux-2.6 and
> >   linux-2.6.patch"
> >
> > - what about patchlets that have the same wholefiles but a different
> >   'patch' file.  I.e. a new conntrack helper that has the same source
> >   file, valid for 2.4 and 2.6 - but a different diff for patching
> >   something into conntrack_core ?

> Something like 'best match wins'?

> linux-2.6.13		- just for 2.6.13
> linux-2.6		- every (other) 2.6 release
> linux-2.4		- every 2.4 release
> linux			- every other release :-)

> (Same goes for the linux.patch file.) 'Requires' could be used to set
> general version bounds, like
> Requires: linux >= 2.4.22

I think the convention of Debian Packages files with a line like
Depends: zope, python2.1-popy (>= 2.0.8), python2.1-popy (<< 2.0.9)
would just be perfect.
I just hope there is some kind of out-of-the-box perl module which
would deal with these kinds of versioning issues (handle parsing,
compare versions, resolve recursive dependencies, etc).

That would imply versioning of patches, which would be a good
thing.

 Herve

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

Re: Call for testing: patch-o-matic-ng

[Harald Welte]

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

On Mon, Jan 05, 2004 at 12:55:33PM +0100, Herve Eychenne wrote:
> I think the convention of Debian Packages files with a line like
> Depends: zope, python2.1-popy (>= 2.0.8), python2.1-popy (<< 2.0.9)
> would just be perfect.
> I just hope there is some kind of out-of-the-box perl module which
> would deal with these kinds of versioning issues (handle parsing,
> compare versions, resolve recursive dependencies, etc).

I wish there was.  At least my last search of the CPAN didn't reveal
anything like that.  If anyone knows such a module, please send me a
link.

> That would imply versioning of patches, which would be a good
> thing.

no.  Currently we are just talking about dependencies of a patch towards
an installed kernel version.

Having one patch depend on a particular version of another patch is
something different - and I don't see a way to implement that without 
storing that version information somewhere in the kernel tree.

>  Herve

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

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

Re: Call for testing: patch-o-matic-ng

[Jozsef Kadlecsik]

Hi Herve,

On Mon, 5 Jan 2004, Herve Eychenne wrote:

> I think the convention of Debian Packages files with a line like
> Depends: zope, python2.1-popy (>= 2.0.8), python2.1-popy (<< 2.0.9)
> would just be perfect.

No, that's not so simple. I had just convinced Harald (:-) that we should
keep the different versions of the same patch in one directory, like:

foo/
foo/info			# Common auxiliary files
foo/help
foo/linux-2.4.patch		# 2.4 speficic patch and whole files
foo/linux-2.4/...
foo/linux-2.6.patch		# 2.6 specific patch and whole files
foo/linux-2.6/...

The Requires (in your context: Depends) lines can be added to the info
file, which thus valid for all patch-versions. In Debian, you have one
specific package. Here we have multiple versions of the same patch.

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: Call for testing: patch-o-matic-ng

[Herve Eychenne]

On Mon, Jan 05, 2004 at 01:45:46PM +0100, Jozsef Kadlecsik wrote:

> Hi Herve,

> On Mon, 5 Jan 2004, Herve Eychenne wrote:

> > I think the convention of Debian Packages files with a line like
> > Depends: zope, python2.1-popy (>= 2.0.8), python2.1-popy (<< 2.0.9)
> > would just be perfect.

> No, that's not so simple. I had just convinced Harald (:-) that we should
> keep the different versions of the same patch in one directory, like:

> foo/
> foo/info			# Common auxiliary files
> foo/help
> foo/linux-2.4.patch		# 2.4 speficic patch and whole files
> foo/linux-2.4/...
> foo/linux-2.6.patch		# 2.6 specific patch and whole files
> foo/linux-2.6/...

> The Requires (in your context: Depends) lines can be added to the info
> file, which thus valid for all patch-versions. In Debian, you have one
> specific package. Here we have multiple versions of the same patch.

It's pretty much the same as the Debian scheme.
A Debian package name is equivalent to your "foo". Several
versions of it may exist at the same time.
Debian has several files (.deb) containing a package name and version.
A "Packages" file is computed based on that files.

Your "info" is the equivalent of a single entry in the Debian Packages
file, no problem...
Your "linux-2.4" is the equivalent of the package-version.deb
Your "help" could probably be integrated into "info".

So I see no problem with your scheme. Yet, what would you put in
"linux-2.4/..."?  Why doesn't it get into linux-2.4.patch?

I would have thought about a single file for each foo-version, which
would be called foo-version.pom

Each file would contain:

<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>
Module: foo
Section: extra
Author: ...
...
Version: 2.4.3      # note: version of the module, not of the kernel)
Depends: nat (>= 0.9.0), linux (>= 2.4.22)
Description: the foo module adds ...

<the diff itself>
<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>

And you could have at the same time, if needed:
<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>
Module: foo
Section: extra
Author: ...
...
Version: 2.6.3
Depends: nat (>= 1.0.0), linux (>= 2.6.0)
Description: the foo module adds ...

<the diff itself>
<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>

Everything in a flat directory... Or you can create a section
directory, like the old system.
Or even create a directory per module, if you want, so you can factorize
Module name and Description fields.

Well... do as you please.

 Herve

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

Re: Call for testing: patch-o-matic-ng

[Jozsef Kadlecsik]

On Mon, 5 Jan 2004, Herve Eychenne wrote:

> > foo/
> > foo/info			# Common auxiliary files
> > foo/help
> > foo/linux-2.4.patch		# 2.4 speficic patch and whole files
> > foo/linux-2.4/...
> > foo/linux-2.6.patch		# 2.6 specific patch and whole files
> > foo/linux-2.6/...
>
> > The Requires (in your context: Depends) lines can be added to the info
> > file, which thus valid for all patch-versions. In Debian, you have one
> > specific package. Here we have multiple versions of the same patch.
>
> It's pretty much the same as the Debian scheme.
> A Debian package name is equivalent to your "foo". Several
> versions of it may exist at the same time.
> Debian has several files (.deb) containing a package name and version.
> A "Packages" file is computed based on that files.

As Harald wrote, I was misleading: it's not truly patch "version", but
patch flavours against kernel versions. What we'd like to solve is the
clean handling of which patch flavour should be applied against a given
kernel source.

> Your "info" is the equivalent of a single entry in the Debian Packages
> file, no problem...
> Your "linux-2.4" is the equivalent of the package-version.deb
> Your "help" could probably be integrated into "info".
>
> So I see no problem with your scheme. Yet, what would you put in
> "linux-2.4/..."?  Why doesn't it get into linux-2.4.patch?

That subdirectory tree contains the whole files and the special files from
the patch file. So the original patch file is split into several chunks:

- whole files added to the kernel tree
- specially handled files (Config.in/Kconfig/Makefile/ip_conntrack.h/etc)
- rest as normal patch file

So we don't want to collapse them into two files (control + "deb").

In my opinion, patch-o-matic-ng should be flexible enough to handle
patches against different kernel versions with the mininal maintenance
overhead. We have to name the patch file/subdir, so we can encode the
kernel dependency simply there. Why should we store the dependecy
explicitly in a separated control file? Of course the naming does not give
enough flexibility in some cases, so general dependecy setting still could
be stated in the control file - if required.

Scanning my machine, I could not find a perl module which implements the
deb dependecy checking. :-(

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: Call for testing: patch-o-matic-ng

[Herve Eychenne]

On Tue, Jan 06, 2004 at 11:32:15AM +0100, Jozsef Kadlecsik wrote:

> Scanning my machine, I could not find a perl module which implements the
> deb dependecy checking. :-(

Yes, apt is in C++... If someone feels like writing this in Perl and
incorporate it into CPAN, I think it would be interesting for quite a
few people, as version and dependency checking is not only needed in
Debian, obviously. :-)

 Herve

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

Re: Call for testing: patch-o-matic-ng

[Henrik Nordstrom]

On Mon, 5 Jan 2004, Jozsef Kadlecsik wrote:

> No, that's not so simple. I had just convinced Harald (:-) that we should
> keep the different versions of the same patch in one directory, like:
> 
> foo/
> foo/info			# Common auxiliary files
> foo/help
> foo/linux-2.4.patch		# 2.4 speficic patch and whole files
> foo/linux-2.4/...
> foo/linux-2.6.patch		# 2.6 specific patch and whole files
> foo/linux-2.6/...

Looks excellent for the purpose to me.

And I also agree that these versions is not the same as package versions.
The version of the patch in all directories should be the same, what
differs is what version of Linux the patch applies to.

Regards
Henrik