iptables release

iptables release

[Patrick McHardy]

I have a large number of pending patches for iptables for new
matches and targets. I'm not going apply patches for new things
unless they are at least in a -rc kernel, so we have a chance to
fix mistakes. So my question is whether we're ready to release
the current iptables -rc anytime soon (before/when 2.6.24 is
released) or whether we're more likely going to need until 2.6.25,
in which case I would apply them now.

Any opinions?

Re: iptables release

[Jan Engelhardt]

On Nov 27 2007 17:52, Patrick McHardy wrote:
>
> I have a large number of pending patches for iptables for new
> matches and targets. I'm not going apply patches for new things
> unless they are at least in a -rc kernel, so we have a chance to
> fix mistakes. So my question is whether we're ready to release
> the current iptables -rc anytime soon (before/when 2.6.24 is
> released) or whether we're more likely going to need until 2.6.25,
> in which case I would apply them now.
>
> Any opinions?

Apply now, make an rc2 (maybe?),
apply more gems (coming), target 2.6.25,
be done :-)

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Nov 27 2007 17:52, Patrick McHardy wrote:
>> I have a large number of pending patches for iptables for new
>> matches and targets. I'm not going apply patches for new things
>> unless they are at least in a -rc kernel, so we have a chance to
>> fix mistakes. So my question is whether we're ready to release
>> the current iptables -rc anytime soon (before/when 2.6.24 is
>> released) or whether we're more likely going to need until 2.6.25,
>> in which case I would apply them now.
>>
>> Any opinions?
> 
> Apply now, make an rc2 (maybe?),
> apply more gems (coming), target 2.6.25,
> be done :-)


I'm aiming for one release per kernel release to get new stuff
out in time for testing. Unfortunately we're already way behind,
so I'd prefer an earlier release than 2.6.25. My feeling is that
the current -rc works well, so if nobody is aware of any big
issues, I think we should release the current version in a few
weeks when 2.6.24 comes out.

Re: iptables release

[Jan Engelhardt]

On Nov 27 2007 20:04, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> On Nov 27 2007 17:52, Patrick McHardy wrote:
>> > I have a large number of pending patches for iptables for new
>> > matches and targets. I'm not going apply patches for new things
>> > unless they are at least in a -rc kernel, so we have a chance to
>> > fix mistakes. So my question is whether we're ready to release
>> > the current iptables -rc anytime soon (before/when 2.6.24 is
>> > released) or whether we're more likely going to need until 2.6.25,
>> > in which case I would apply them now.
>> >
>> > Any opinions?
>> 
>> Apply now, make an rc2 (maybe?),
>> apply more gems (coming), target 2.6.25,
>> be done :-)
>
> I'm aiming for one release per kernel release to get new stuff
> out in time for testing. Unfortunately we're already way behind,
> so I'd prefer an earlier release than 2.6.25. My feeling is that
> the current -rc works well, so if nobody is aware of any big
> issues, I think we should release the current version in a few
> weeks when 2.6.24 comes out.
>
I have pushed out (as patches) everything I wanted to, so it is
now up to you what to cherry-pick. The autoconf one might get a
little last tweaking once the .*-test situation is clear. I'd
just import ipt_condition.h and so to fix it.

Re: iptables release

[Jesper Dangaard Brouer]

On Tue, 27 Nov 2007, Patrick McHardy wrote:

> I have a large number of pending patches for iptables for new
> matches and targets. I'm not going apply patches for new things
> unless they are at least in a -rc kernel, so we have a chance to
> fix mistakes. So my question is whether we're ready to release
> the current iptables -rc anytime soon (before/when 2.6.24 is
> released) or whether we're more likely going to need until 2.6.25,
> in which case I would apply them now.

What about my performance/scalability patches, do I need to wait another 
kernel cycle to see them released?

I think that, at least patch 1/2 should be applied, as its a obvious fix.

For at patch 2/2, I would like some comments on the type casting, e.g. if 
it will work on all platforms e.g. 64-bit.

I'm also working on a faster chain list search (because listing all rules 
still takes 17 sec on production server with patches applied).  That patch 
should, settle a bit in SVN before released.

Note, right now I have some spare time to work on iptables, in a week I 
don't.  Please give me some feedback on the patches.

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: iptables release

[Patrick McHardy]

Jesper Dangaard Brouer wrote:
> On Tue, 27 Nov 2007, Patrick McHardy wrote:
> 
>> I have a large number of pending patches for iptables for new
>> matches and targets. I'm not going apply patches for new things
>> unless they are at least in a -rc kernel, so we have a chance to
>> fix mistakes. So my question is whether we're ready to release
>> the current iptables -rc anytime soon (before/when 2.6.24 is
>> released) or whether we're more likely going to need until 2.6.25,
>> in which case I would apply them now.
> 
> What about my performance/scalability patches, do I need to wait another 
> kernel cycle to see them released?
> 
> I think that, at least patch 1/2 should be applied, as its a obvious fix.

Yes, the first one is obviously fine. I'm going to apply it now.

> For at patch 2/2, I would like some comments on the type casting, e.g. 
> if it will work on all platforms e.g. 64-bit.

I'll have a closer look.

Re: iptables release

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 27 Nov 2007 17:52:55 +0100

> I have a large number of pending patches for iptables for new
> matches and targets. I'm not going apply patches for new things
> unless they are at least in a -rc kernel, so we have a chance to
> fix mistakes. So my question is whether we're ready to release
> the current iptables -rc anytime soon (before/when 2.6.24 is
> released) or whether we're more likely going to need until 2.6.25,
> in which case I would apply them now.
> 
> Any opinions?

Please wait a few hours at least to release iptables. Just after sending
this mail, I'll moves some libipt_*.man to libxt_*.man and remove
libip6t_state.c which I forgot to remove.

-- Yasuyuki Kozakai

Re: iptables release

[Yasuyuki KOZAKAI]

Hi, Patrick,

From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>

> Please wait a few hours at least to release iptables. Just after sending
> this mail, I'll moves some libipt_*.man to libxt_*.man and remove
> libip6t_state.c which I forgot to remove.

Done.

- I've moved following libipt_*.man to libxt_*.man where libxt_*.c.
  exists and libip6t_*.man does not exist.

	CLASSIFY, CONNMARK, CONNSECMARK, DSCP, NOTRACK, comment, connbytes,
	connmark, dccp, dscp, hashlimit, helper, pkttype, quota, sctp,
	state, string, tcpmss

- I've unified libipt_*.man and libip6t_*.man into libxt_*.man where they
  have no difference and libxt_*.c exists.

	NFQUEUE, SECMARK, esp, limit, mac, mark, physdev, udp

- I've removed libip6t_state.c and libip6t_u32.man. libxt_* for them
  exist.

- I've fixed typo in extensions/Makefile as follows. Now selinux related
  modules would be correctly build by DO_SELINUX=1.

Index: extensions/Makefile
===================================================================
--- extensions/Makefile	(revision 7127)
+++ extensions/Makefile	(revision 7128)
@@ -15,8 +15,8 @@
 
 ifeq ($(DO_SELINUX), 1)
 PF_EXT_SE_SLIB:=$(PF_EXT_SELINUX_SLIB)
-PF6_EXT_SE_SLIB:=$(PF_EXT_SELINUX_SLIB)
-PFX_EXT_SE_SLIB:=$(PF_EXT_SELINUX_SLIB)
+PF6_EXT_SE_SLIB:=$(PF6_EXT_SELINUX_SLIB)
+PFX_EXT_SE_SLIB:=$(PFX_EXT_SELINUX_SLIB)
 endif
 
 # Optionals

Regards,

-- Yasuyuki Kozakai

Re: iptables release

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Tue, 27 Nov 2007 17:52:55 +0100
> 
>> I have a large number of pending patches for iptables for new
>> matches and targets. I'm not going apply patches for new things
>> unless they are at least in a -rc kernel, so we have a chance to
>> fix mistakes. So my question is whether we're ready to release
>> the current iptables -rc anytime soon (before/when 2.6.24 is
>> released) or whether we're more likely going to need until 2.6.25,
>> in which case I would apply them now.
>>
>> Any opinions?
> 
> Please wait a few hours at least to release iptables. Just after sending
> this mail, I'll moves some libipt_*.man to libxt_*.man and remove
> libip6t_state.c which I forgot to remove.


Don't worry, I think releasing in time for 2.6.24 would be enough.

BTW, judging by your last batch of xtables patches you seem to have
managed to import the netfilter SVN in git. I keep getting errors
related to paths:

$ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
Initialized empty Git repository in /tmp/nf.git/.git/
1: Unrecognized path: 
/patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_nat_pptp.h
1: Unrecognized path: /patch-o-matic-ng/trunk/pptp-conntrack-nat/help
1: Unrecognized path: 
/patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_conntrack_pptp.h

It seems it switches the first directory and "trunk". Did you use
git-svnimport or just git-svn for importing?

Re: iptables release

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber@trash.net>

> Don't worry, I think releasing in time for 2.6.24 would be enough.

Thanks.

> BTW, judging by your last batch of xtables patches you seem to have
> managed to import the netfilter SVN in git. I keep getting errors
> related to paths:
> 
> $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
> Initialized empty Git repository in /tmp/nf.git/.git/
> 1: Unrecognized path: 
> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_nat_pptp.h
> 1: Unrecognized path: /patch-o-matic-ng/trunk/pptp-conntrack-nat/help
> 1: Unrecognized path: 
> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_conntrack_pptp.h
> 
> It seems it switches the first directory and "trunk". Did you use
> git-svnimport or just git-svn for importing?

Actually, I have not succeeded to manage them. I manually do 'svn update'
on master branch on local git tree and commits updates, and create new branch
on git tree for my development.

-- Yasuyuki Kozakai

Re: iptables release

[Jan Engelhardt]

On Nov 29 2007 17:01, Yasuyuki KOZAKAI wrote:
>
>> BTW, judging by your last batch of xtables patches you seem to have
>> managed to import the netfilter SVN in git. I keep getting errors
>> related to paths:
>> 
>> $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
>> Initialized empty Git repository in /tmp/nf.git/.git/
>> 1: Unrecognized path: 
>> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_nat_pptp.h
>> 1: Unrecognized path: /patch-o-matic-ng/trunk/pptp-conntrack-nat/help
>> 1: Unrecognized path: 
>> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_conntrack_pptp.h
>> 
>> It seems it switches the first directory and "trunk". Did you use
>> git-svnimport or just git-svn for importing?
>
>Actually, I have not succeeded to manage them. I manually do 'svn update'
>on master branch on local git tree and commits updates, and create new branch
>on git tree for my development.
>
Also, there is no indication that a move was done (e.g. r7117) but instead
a hand copy. I prefer using native svn, or switching to git entirely.

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Nov 29 2007 17:01, Yasuyuki KOZAKAI wrote:
>>> BTW, judging by your last batch of xtables patches you seem to have
>>> managed to import the netfilter SVN in git. I keep getting errors
>>> related to paths:
>>>
>>> $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
>>> Initialized empty Git repository in /tmp/nf.git/.git/
>>> 1: Unrecognized path: 
>>> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_nat_pptp.h
>>> 1: Unrecognized path: /patch-o-matic-ng/trunk/pptp-conntrack-nat/help
>>> 1: Unrecognized path: 
>>> /patch-o-matic-ng/trunk/pptp-conntrack-nat/linux/include/linux/netfilter_ipv4/ip_conntrack_pptp.h
>>>
>>> It seems it switches the first directory and "trunk". Did you use
>>> git-svnimport or just git-svn for importing?
>> Actually, I have not succeeded to manage them. I manually do 'svn update'
>> on master branch on local git tree and commits updates, and create new branch
>> on git tree for my development.
>>
> Also, there is no indication that a move was done (e.g. r7117) but instead
> a hand copy. I prefer using native svn, or switching to git entirely.


I want to switch entirely, but first I have to manage to import the
repository :)

Re: iptables release

[Jan Engelhardt]

On Nov 29 2007 09:27, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> On Nov 29 2007 17:01, Yasuyuki KOZAKAI wrote:
>> > >
>> > > $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
> I want to switch entirely, but first I have to manage to import the
> repository :)
>
The problem is you have a non-trivial repository layout, so
using above's git-svnimport is likely to be not enough.

Re: iptables release

[Jan Engelhardt]

On Nov 29 2007 09:47, Jan Engelhardt wrote:
>On Nov 29 2007 09:27, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> On Nov 29 2007 17:01, Yasuyuki KOZAKAI wrote:
>>> > >
>>> > > $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
>> I want to switch entirely, but first I have to manage to import the
>> repository :)
>>
>The problem is you have a non-trivial repository layout, so
>using above's git-svnimport is likely to be not enough.

Also, there currently exist /trunk/PROJECTNAME. If that were to be
imported into git, I would not be sure whether you can tag single
projects like in svn .. in git it seems like just the whole tree.
Trying to tag v1.4.0 would then also include libnfconntrack and
friends in the tag - not good.

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Nov 29 2007 09:47, Jan Engelhardt wrote:
>> On Nov 29 2007 09:27, Patrick McHardy wrote:
>>> Jan Engelhardt wrote:
>>>> On Nov 29 2007 17:01, Yasuyuki KOZAKAI wrote:
>>>>>> $ git-svnimport -v -C nf.git http://svn.netfilter.org/netfilter
>>> I want to switch entirely, but first I have to manage to import the
>>> repository :)
>>>
>> The problem is you have a non-trivial repository layout, so
>> using above's git-svnimport is likely to be not enough.
> 
> Also, there currently exist /trunk/PROJECTNAME. If that were to be
> imported into git, I would not be sure whether you can tag single
> projects like in svn .. in git it seems like just the whole tree.
> Trying to tag v1.4.0 would then also include libnfconntrack and
> friends in the tag - not good.


We could use sepate git repositories for that, shouldn't be
a big problem.

Re: iptables release

[Jan Engelhardt]

On Nov 29 2007 10:13, Patrick McHardy wrote:
>> 
>> Also, there currently exist /trunk/PROJECTNAME. If that were to be
>> imported into git, I would not be sure whether you can tag single
>> projects like in svn .. in git it seems like just the whole tree.
>> Trying to tag v1.4.0 would then also include libnfconntrack and
>> friends in the tag - not good.
>
>
> We could use sepate git repositories for that, shouldn't be
> a big problem.
>

Just start a new git repo without importing anything.

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Nov 29 2007 10:13, Patrick McHardy wrote:
>>> Also, there currently exist /trunk/PROJECTNAME. If that were to be
>>> imported into git, I would not be sure whether you can tag single
>>> projects like in svn .. in git it seems like just the whole tree.
>>> Trying to tag v1.4.0 would then also include libnfconntrack and
>>> friends in the tag - not good.
>>
>> We could use sepate git repositories for that, shouldn't be
>> a big problem.
>>
> 
> Just start a new git repo without importing anything.


No, I want to keep the history.

Re: iptables release

[Jesper Dangaard Brouer]

On Thu, 29 Nov 2007, Patrick McHardy wrote:
>
> It seems it switches the first directory and "trunk". Did you use
> git-svnimport or just git-svn for importing?

I use "git-svn":
  git-svn clone https://svn.netfilter.org/netfilter/ -T trunk -b branches -t tags

And I had to update git to a newer version (1.5.3 than debians 1.4.4) to 
make it work.

Still, I don't think it got the tags and branches right, because 
.git/refs/tags is empty. And it only gets log history back from revision 
3070 (thats where a "new global trunk directory" were created).

When I want to sync with SVN I do:

  git-checkout master
  git-svn fetch
  git-svn rebase

To get one of my work branches up to sync I do a git rebase:

  git-checkout perf_work1
  git rebase master

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: iptables release

[Patrick McHardy]

Jesper Dangaard Brouer wrote:
>
> On Thu, 29 Nov 2007, Patrick McHardy wrote:
>>
>> It seems it switches the first directory and "trunk". Did you use
>> git-svnimport or just git-svn for importing?
>
> I use "git-svn":
>  git-svn clone https://svn.netfilter.org/netfilter/ -T trunk -b 
> branches -t tags
>
> And I had to update git to a newer version (1.5.3 than debians 1.4.4) 
> to make it work.
>
> Still, I don't think it got the tags and branches right, because 
> .git/refs/tags is empty. And it only gets log history back from 
> revision 3070 (thats where a "new global trunk directory" were created).
>
> When I want to sync with SVN I do:
>
>  git-checkout master
>  git-svn fetch
>  git-svn rebase
>
> To get one of my work branches up to sync I do a git rebase:
>
>  git-checkout perf_work1
>  git rebase master

Yeah, that works for importing the head and keeping in sync,
but it doesn't work for importing the entire repository with
branches and history according to the manpage. Still useful
since I hate SVN about as much as CVS :)

Re: iptables release

[Jan Engelhardt]

On Nov 29 2007 21:52, Patrick McHardy wrote:
>>
>>  git-checkout master
>>  git-svn fetch
>>  git-svn rebase
>>
>> To get one of my work branches up to sync I do a git rebase:
>>
>>  git-checkout perf_work1
>>  git rebase master
>
> Yeah, that works for importing the head and keeping in sync,
> but it doesn't work for importing the entire repository with
> branches and history according to the manpage. Still useful
> since I hate SVN about as much as CVS :)

If you are willing to reorder the SVN tree, that may make git
more happy.

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Nov 29 2007 21:52, Patrick McHardy wrote:
>   
>>>  git-checkout master
>>>  git-svn fetch
>>>  git-svn rebase
>>>
>>> To get one of my work branches up to sync I do a git rebase:
>>>
>>>  git-checkout perf_work1
>>>  git rebase master
>>>       
>> Yeah, that works for importing the head and keeping in sync,
>> but it doesn't work for importing the entire repository with
>> branches and history according to the manpage. Still useful
>> since I hate SVN about as much as CVS :)
>>     
>
> If you are willing to reorder the SVN tree, that may make git
> more happy.

I think its more a SVN misconfiguration. git-svnimport looks for
(example) iptables/trunk, but its trunk/iptables. Couldn't find
out where the misconfiguration is though.

Re: iptables release

[Yasuyuki KOZAKAI]

Hi,

I'm not sure that I could get all changeset of iptables, but anyway
I put iptables.git at
	rsync://people.netfilter.org/users/yasuyuki/git/iptables.git

Please note that many released iptables which can be downloaded from
http://www.netfilter.org/projects/iptables/downloads.html are not
identical to each svn tags. So please don't mind even if no git commit
matches the archives.

I didn't import svn branches and tags by git-svnimport,
because sometimes doing that broke 'origin' git branch, and I saw that
some svn tags were not identical to any revision of svn turnk.
I can create git branches to keep svn tags and released iptables
sources, if people want.

The followings are logs of many troubles...

** Notable history of iptables svn tree

By the revision 702, svn.netfilter.org/netfilter/iptables/trunk was created.
branches and tags were at
	svn.netfilter.org/netfilter/iptables/branches
	svn.netfilter.org/netfilter/iptables/tags
respectively.

By 3071, the trunk of iptables was moved to
	svn.netfilter.org/netfilter/trunk/iptables

By 3109, the 'branches' of iptables was moved to
	svn.netfilter.org/netfilter/branches/iptables

The revsions 5092 - 5223 are not usual changes. 'svn log' says as follows.
Sorry, I don't know what happend at that time.

$ svn log -r5092 -v http://svn.netfilter.org/netfilter
------------------------------------------------------------------------
r5092 | (no author) | 2004-10-11 22:40:52 +0900 (Mon, 11 Oct 2004) | 1 line

This is an empty revision for padding.
------------------------------------------------------------------------

** What I did to create iptables git tree

I did
	$ git-svnimport -v -s 702 -l 3070 -T iptables/trunk	\
		http://svn.netfilter.org/netfilter 

I thought that such argument to -T was not expected by the author of
git-svnimport, but it seemd to work. ;) I did not use -b and -t for
branches and tags. Because I found that some commits on 'origin' were
broken by them.

Sometimes the TCP connection to SVN server was disconnected while importing.
In that case, I reset 'origin' and 'master' branch so that they refered
the last suceeded commit, removed .git/SVN2GIT_HEAD and .git/ORIG_HEAD,
and excecuted git-svnimport without '-s' again.

git-svnimport failed to import revision 1375. I don't know the reason.
I suspect that subversion or something on my environment could not manage
the charactor including '~' above 'a' of ISO-8859-1 encoding.
After all, I manually downloaded the changeset, creates a git patch,
applied it to 'origin' branch of git tree, and executed git-svnimport
without '-s'.

Next, I did
	$ git-svnimport -v -s 3109 -l 5091 -T trunk/iptables	\
		-b dummy_branches -t dummy_tags			\
		http://svn.netfilter.org/netfilter

It failed at 5091, so I reset 'origin' and 'master' branch so that
they refered the last commit (which was for revision 4552) and I did

	$ git-svnimport -v -s 5224 -T trunk/iptables	\
		-b dummy_branches -t dummy_tags		\
		http://svn.netfilter.org/netfilter

** A Comment
Well, I don't want to do this again :)

-- Yasuyuki Kozakai

Re: iptables release

[Jan Engelhardt]

On Dec 1 2007 02:37, Yasuyuki KOZAKAI wrote:
>
>$ svn log -r5092 -v http://svn.netfilter.org/netfilter
>------------------------------------------------------------------------
>r5092 | (no author) | 2004-10-11 22:40:52 +0900 (Mon, 11 Oct 2004) | 1 line
>
>This is an empty revision for padding.

While empty commits can happen (it does take a specific course of action
though), the log message is unusual, esp. with (no author) and "This is an
empty revision for padding".

>------------------------------------------------------------------------
>
>** What I did to create iptables git tree
>
>I did
>	$ git-svnimport -v -s 702 -l 3070 -T iptables/trunk	\
>		http://svn.netfilter.org/netfilter 
>
>I thought that such argument to -T was not expected by the author of
>git-svnimport, but it seemd to work. ;) I did not use -b and -t for
>branches and tags. Because I found that some commits on 'origin' were
>broken by them.
>
>Sometimes the TCP connection to SVN server was disconnected while importing.
>In that case, I reset 'origin' and 'master' branch so that they refered
>the last suceeded commit, removed .git/SVN2GIT_HEAD and .git/ORIG_HEAD,
>and excecuted git-svnimport without '-s' again.

I would have rsynced the svn tree off, then do a local svn-to-git transform.
That would have avoided potentially dangerous disconnects.

>** A Comment
>Well, I don't want to do this again :)

Heh.

Re: [netfilter-core] iptables release

[Harald Welte]

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

On Tue, Nov 27, 2007 at 05:52:55PM +0100, Patrick McHardy wrote:
> I have a large number of pending patches for iptables for new
> matches and targets. I'm not going apply patches for new things
> unless they are at least in a -rc kernel, so we have a chance to
> fix mistakes. So my question is whether we're ready to release
> the current iptables -rc anytime soon (before/when 2.6.24 is
> released) or whether we're more likely going to need until 2.6.25,
> in which case I would apply them now.

I have a number of manpage updates pending, unfortunately I still can't
commit to the repository (and since it includes many file renames it's
hard to just submit a patch).

I'd prefer if the release is held back until the documentation is in
sync.

-- 
- Harald Welte <laforge@netfilter.org>                 http://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 --]

iptables release

[Patrick McHardy]

I'll probably release the next iptables version tommorrow.
Anyone who still wants to get fixes in, please send them
now. Test results are also welcome :)

Re: iptables release

[Jan Engelhardt]

On Thursday 2009-09-10 15:29, Patrick McHardy wrote:

>I'll probably release the next iptables version tommorrow.
>Anyone who still wants to get fixes in, please send them
>now. Test results are also welcome :)

Do features count?

I would have wanted to submit Mohit's -Z# support earlier, but the 
misunderstanding between making a statement and inquiring a question 
about the usefulness (I have been convinced now) held it up 
unfortunately.

Re: iptables release

[Jan Engelhardt]

On Monday 2009-09-14 19:06, Patrick McHardy wrote:
>
>Sorry, I don't want any features that late in the release stage.
>Feel free to send it to me now that the release is out :)
>


The following changes since commit 352ccfb847dfd290a7b761cd87445a48e551acb5:
  Jan Engelhardt (1):
        manpages: more fixes to minuses, hyphens, dashes

are available in the git repository at:

  git://dev.medozas.de/iptables zero

Jan Engelhardt (1):
      iptables: manpage updates for augmented -Z syntax

Mohit Mehta (1):
      iptables: expose option to zero packet/byte counters for a specific rule

 ip6tables.8.in |    7 ++++---
 ip6tables.c    |   31 ++++++++++++++++++++++++-------
 iptables.8.in  |    7 ++++---
 iptables.c     |   31 ++++++++++++++++++++++++-------
 4 files changed, 56 insertions(+), 20 deletions(-)

Re: iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2009-09-14 19:06, Patrick McHardy wrote:
>> Sorry, I don't want any features that late in the release stage.
>> Feel free to send it to me now that the release is out :)
>>
> 
> 
> The following changes since commit 352ccfb847dfd290a7b761cd87445a48e551acb5:
>   Jan Engelhardt (1):
>         manpages: more fixes to minuses, hyphens, dashes
> 
> are available in the git repository at:
> 
>   git://dev.medozas.de/iptables zero
> 
> Jan Engelhardt (1):
>       iptables: manpage updates for augmented -Z syntax
> 
> Mohit Mehta (1):
>       iptables: expose option to zero packet/byte counters for a specific rule

Pulled and pushed out again, thanks Jan.

iptables release

[Fabio Pedretti]

Hi, is there a plan to push a new release of iptables?
It has some fixes which are routinely reported in distros having
latest stable release 1.8.3.
Thanks

Re: iptables release

[Fabio Pedretti]

Debian also has some patches that may be applicable upstream:
https://salsa.debian.org/pkg-netfilter-team/pkg-iptables/tree/master/debian/patches

Il giorno mar 10 set 2019 alle ore 20:47 Fabio Pedretti
<pedretti.fabio@gmail.com> ha scritto:
>
> Hi, is there a plan to push a new release of iptables?
> It has some fixes which are routinely reported in distros having
> latest stable release 1.8.3.
> Thanks