Re: [tcpdump-workers] autoconf 2.61 versus 2.68

2013-04-15 Thread François-Xavier Le Bail
> From: Guy Harris 
> If we want to ensure that the configuration scripts we ship are generated by 
> a 
> particular version of autoconf, we should remove configure from the 
> repository, 
> add an autogen.sh script to re-generate the configure file, and ensure that 
> it's run as part of the release-tarball building process.


Similar way:
- remove configure and config.h.in from repository,
- change AC_PREREQ Macro in configure.in, for example : AC_PREREQ(2.68),
- run "autoreconf"as part of the release-tarball building process.

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] autoconf 2.61 versus 2.68

2013-04-15 Thread Guy Harris

On Apr 15, 2013, at 7:18 AM, François-Xavier Le Bail  
wrote:

>> From: Guy Harris 
>> If we want to ensure that the configuration scripts we ship are generated by 
>> a 
>> particular version of autoconf, we should remove configure from the 
>> repository, 
>> add an autogen.sh script to re-generate the configure file, and ensure that 
>> it's run as part of the release-tarball building process.
> 
> Similar way:
> - remove configure and config.h.in from repository,
> - change AC_PREREQ Macro in configure.in, for example : AC_PREREQ(2.68),
> - run "autoreconf"as part of the release-tarball building process.

The only difference there is the AC_PREREQ() macro and hardwiring "autoreconf" 
as the "remake the configure script" process.

The latter is probably OK if we're not going to use automake.

The former requires developers who work from Git to have that autoconf 2.68 or 
later.  I'm not sure we need to require 2.68, even if it happens to be the 
version on the machine that builds the release tarballs.  AC_PREREQ() should 
specify the minimum number known to build the current version of configure.in 
(so that somebody who doesn't have that version gets a "sorry, you need 
autoconf X.YY or later" error rather than some weird error).

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


[tcpdump-workers] moves to github

2013-04-15 Thread Michael Richardson

1) we have created github.com/the-tcpdump-group.  It has copies
   of three repositories:
   a) libpcap
   b) tcpdump
   c) tcpdump-htdocs

   These are pushed by a nightly cron job from our master machine.
   So no, github is not the golden or only copy.

   Creating a group means that more people than just I can handle
   merges.  Please contact me if you'd like to help.

2) Guy Harris has run a source 2 github python script to transfer issues
   from SF to github.  They are at:
   https://github.com/the-tcpdump-group/tcpdump/issues
(103 open, 199 closed)

   https://github.com/the-tcpdump-group/libpcap/issues
(116, 173 closed)

   We need help going through these issues.
   I think we can probably come up with some markup to indicate what
   is what, and I see colours and other stuff to help sort things out.
   Tell me your github ID, and I'll add you to the team if necessary.

   There are lots of patches, turning them into pull requests would be
   great.  Many of them are likely already done.

3) we have gotten slightly distracted from the 4.4 release, I will
   resume it and release the -rc2.  It doesn't have any autoconf
   changes.  I'm happy to do whatever is recommended, as long as
   the solution is easy to do on stock ("stable") debian, LTS ubuntu,
   and RHEL6/Centos6... cause I hate making people run unstable stuff
   just to contribute.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 






   


___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] moves to github

2013-04-15 Thread Guy Harris

On Apr 15, 2013, at 7:40 PM, Michael Richardson  wrote:

> 2) Guy Harris has run a source 2 github python script to transfer issues
>   from SF to github.

If you're curious, it's

https://github.com/ttencate/sf2github
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] moves to github

2013-04-15 Thread Denis Ovsienko

> 2) Guy Harris has run a source 2 github python script to transfer issues
>    from SF to github.  They are at:
>    https://github.com/the-tcpdump-group/tcpdump/issues
> (103 open, 199 closed)
>
>    https://github.com/the-tcpdump-group/libpcap/issues
> (116, 173 closed)
>
>    We need help going through these issues.
>    I think we can probably come up with some markup to indicate what
>    is what, and I see colours and other stuff to help sort things out.
>    Tell me your github ID, and I'll add you to the team if necessary.
>
>    There are lots of patches, turning them into pull requests would be
>    great.  Many of them are likely already done.

I tried closing a couple of issues, but ran into a question. Do existing tags 
in GitHub issues (v3.5, v3.6, ... v4.3) mean "opened against version N.N" or 
"fixed in version N.N"?

Should the tickets in SourceForge tracker be closed now?

-- 
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] moves to github

2013-04-15 Thread Guy Harris

On Apr 15, 2013, at 9:37 PM, Denis Ovsienko  wrote:

> I tried closing a couple of issues, but ran into a question. Do existing tags 
> in GitHub issues (v3.5, v3.6, ... v4.3) mean "opened against version N.N" or 
> "fixed in version N.N"?

Those were copied over from SourceForge; the intent, at least, of the tags was 
"opened against version N.N".

I'm not sure whether they served/serve a useful purpose.

> Should the tickets in SourceForge tracker be closed now?

If there were an automated way to do so - with commenting closed, and a 
"further comments on the issue at http://github.org/the-tcpdump-group/..."; as 
the closing comment - that would make sense.

I'm not sure anybody here wants to close 219 SourceForge comments by hand. :-)

If you mean that when you close an issue by hand on GitHub, the corresponding 
SF issue should be closed by hand, that might not be a bad idea.  (I did that 
for the tcpdump issue you closed on GitHub with "-W implements that".)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers