Re: re_compile_pattern change
"James Youngman" <[EMAIL PROTECTED]> writes: > I'll consider myself notified.Apart from that bugfix are there any > other essential changes I should import, or are you suggesting I > update the whole of gnulib to current CVS? Generally speaking, I find it easiest just to sync all of gnulib. That's what everyone else does. It's simpler, since you don't need to worry so much about integration hassles within gnulib. > I am using an older version of gnulib because I try to change the > stable release series of findutils only to fix bugs. Updating to the > newest current release of gnulib every time I release findutils seemed > to me to be a lot of code churn; the gnulib code usually changes more > than the findutils code, at least for the stable releases of > findutils. True, but the gnulib code tends to be fairly stable, and most other distributions (coreutils, tar, bison, etc.) just use the latest gnulib code. I'd put findutils in the same category as coreutils as needing stability, and (if memory serves) as far as gnulib is concerned findutils uses a subset of what coreutils uses, so if it's good enough for coreutils > I don't have an effective mechanism (other than diff -r) of figuring > out what changes occurred in gnulib between two releases of findutils, > either. If you take gnulib snapshots, you can diff the gnulib ChangeLog entries. Admittedly there will be many entries for files you're not using. Or you can keep track of when you snapshotted gnulib, and use CVS to find out what changed, by telling CVS the dates.
Re: re_compile_pattern change
On 12/25/06, Paul Eggert <[EMAIL PROTECTED]> wrote: The 'tar' version is correct. But this is not an Autoconf issue; it is a gnulib version issue. The gnulib fix (dated March 25) is here: http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/m4/regex.m4?r1=1.50&r2=1.51 but apparently findutils is running with an older version of gnulib. I don't see any reason findutils shouldn't be using the latest CVS gnulib. I'll CC: this to [EMAIL PROTECTED] to give the findutils maintainers a heads-up on the bug. I'll consider myself notified.Apart from that bugfix are there any other essential changes I should import, or are you suggesting I update the whole of gnulib to current CVS? I am using an older version of gnulib because I try to change the stable release series of findutils only to fix bugs. Updating to the newest current release of gnulib every time I release findutils seemed to me to be a lot of code churn; the gnulib code usually changes more than the findutils code, at least for the stable releases of findutils. I don't have an effective mechanism (other than diff -r) of figuring out what changes occurred in gnulib between two releases of findutils, either. That also makes me reluctant to routinely update gnulib from CVS. James.
Re: re_compile_pattern change
[EMAIL PROTECTED] writes: > One difference I noted in the test code used between tar-1.16.1 and > findutils-4.2.29 (2.60 vs 2.60a) was: > > tar: s = re_compile_pattern ("a[[:]:]]b\n", 11, ®ex); > findutils: s = re_compile_pattern ("a[:]:]b\n", 9, ®ex); > > A printf in both shows that tar says "Invalid character class name" as the > comment in the code says it should. findutils says null causing an exit > code of 1 and the test to fail. The 'tar' version is correct. But this is not an Autoconf issue; it is a gnulib version issue. The gnulib fix (dated March 25) is here: http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/m4/regex.m4?r1=1.50&r2=1.51 but apparently findutils is running with an older version of gnulib. I don't see any reason findutils shouldn't be using the latest CVS gnulib. I'll CC: this to [EMAIL PROTECTED] to give the findutils maintainers a heads-up on the bug.
re_compile_pattern change
In gettext-0.16.1 and findutils-4.2.29, the version of autoconf used was 2.61 and 2.60a respectively. gettext-0.14.5, findutils-4.2.27, tar-1.16.1, coreutils-5.96, diffutils-2.8.1, grep-2.5.1a, and inetutils-1.5 all used 2.60 or older. The reason I bring this up is that the outcome of re_compile_pattern has changed somewhere between 2.60 and 2.60a and I don't know if it is a bug in the newer autoconf (>2.60), or a long-standing bug in the older versions of autoconf (<=2.60). One difference I noted in the test code used between tar-1.16.1 and findutils-4.2.29 (2.60 vs 2.60a) was: tar: s = re_compile_pattern ("a[[:]:]]b\n", 11, ®ex); findutils: s = re_compile_pattern ("a[:]:]b\n", 9, ®ex); A printf in both shows that tar says "Invalid character class name" as the comment in the code says it should. findutils says null causing an exit code of 1 and the test to fail. I do not know which behavior is correct. Can someone shed some light on this, please? I'm not subscribed, so please CC. Thanks!