Re: [tcpdump-workers] autoconf 2.61 versus 2.68
> 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
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
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
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
> 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
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