- Update from version 3.10 to 3.11
- Update of rootfile not required
- Changelog
* Noteworthy changes in release 3.11 (2023-05-13) [stable]
** Bug fixes
With -P, patterns like [\d] now work again. Fixing this has caused
grep to revert to the behavior of grep 3.8, in that patterns like \w
and \b go back to using ASCII rather than Unicode interpretations.
However, future versions of GNU grep and/or PCRE2 are likely to fix
this and change the behavior of \w and \b back to Unicode again,
without breaking [\d] as 3.10 did.
[bug introduced in grep 3.10]
grep no longer fails on files dated after the year 2038,
when running on 32-bit x86 and ARM hosts using glibc 2.34+.
[bug introduced in grep 3.9]
grep -P no longer fails to match patterns using negated classes
like \D or \W when linked with PCRE2 10.34 or newer.
[bug introduced in grep 3.8]
** Changes in behavior
grep --version now prints a line describing the version of PCRE2 it uses.
For example, it prints this when built with the very latest from git:
grep -P uses PCRE2 10.43-DEV 2023-04-14
or this with what's currently available in Fedora 37:
grep -P uses PCRE2 10.40 2022-04-14
previous versions of grep wouldn't respect the user provided settings for
PCRE_CFLAGS and PCRE_LIBS when building if a libpcre2-8 pkg-config module
was found.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 3.9 to 3.10
- Update of rootfile not required
- Changelog
* Noteworthy changes in release 3.10 (2023-03-22) [stable]
** Bug fixes
With -P, \d now matches only ASCII digits, regardless of PCRE
options/modes. The changes in grep-3.9 to make \b and \w work
properly had the undesirable side effect of making \d also match
e.g., the Arabic digits: ٠١٢٣٤٥٦٧٨٩. With grep-3.9, -P '\d+'
would match that ten-digit (20-byte) string. Now, to match such
a digit, you would use \p{Nd}. Similarly, \D is now mapped to [^0-9].
[bug introduced in grep 3.9]
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Update from version 3.8 to 3.9
- Update of rootfile not required
- Changelog
Noteworthy changes in release 3.9 (2023-03-05) [stable]
Bug fixes
With -P, some non-ASCII UTF8 characters were not recognized as
word-constituent due to our omission of the PCRE2_UCP flag. E.g.,
given f(){ echo Perú|LC_ALL=en_US.UTF-8 grep -Po "$1"; } and
this command, echo $(f 'r\w'):$(f '.\b'), before it would print ":r".
After the fix, it prints the correct results: "rú:ú".
When given multiple patterns the last of which has a back-reference,
grep no longer sometimes mistakenly matches lines in some cases.
[Bug#36148#13 introduced in grep 3.4]
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
- Update from version 3.7 to 3.8
- Update of rootfile not required
- Changelog
* Noteworthy changes in release 3.8 (2022-09-02) [stable]
** Changes in behavior
The -P option is now based on PCRE2 instead of the older PCRE,
thanks to code contributed by Carlo Arenas.
The egrep and fgrep commands, which have been deprecated since
release 2.5.3 (2007), now warn that they are obsolescent and should
be replaced by grep -E and grep -F.
The confusing GREP_COLOR environment variable is now obsolescent.
Instead of GREP_COLOR='xxx', use GREP_COLORS='mt=xxx'. grep now
warns if GREP_COLOR is used and is not overridden by GREP_COLORS.
Also, grep now treats GREP_COLOR like GREP_COLORS by silently
ignoring it if it attempts to inject ANSI terminal escapes.
Regular expressions with stray backslashes now cause warnings, as
their unspecified behavior can lead to unexpected results.
For example, '\a' and 'a' are not always equivalent
<https://bugs.gnu.org/39678>. Similarly, regular expressions or
subexpressions that start with a repetition operator now also cause
warnings due to their unspecified behavior; for example, *a(+b|{1}c)
now has three reasons to warn. The warnings are intended as a
transition aid; they are likely to be errors in future releases.
Regular expressions like [:space:] are now errors even if
POSIXLY_CORRECT is set, since POSIX now allows the GNU behavior.
** Bug fixes
In locales using UTF-8 encoding, the regular expression '.' no
longer sometimes fails to match Unicode characters U+D400 through
U+D7FF (some Hangul Syllables, and Hangul Jamo Extended-B) and
Unicode characters U+108000 through U+10FFFF (half of Supplemental
Private Use Area plane B).
[bug introduced in grep 3.4]
The -s option no longer suppresses "binary file matches" messages.
[Bug#51860 introduced in grep 3.5]
** Documentation improvements
The manual now covers unspecified behavior in patterns like \x, (+),
and range expressions outside the POSIX locale.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
- Update from 3.6 to 3.7
- Update of rootfile not required
- Changelog
* Noteworthy changes in release 3.7 (2021-08-14) [stable]
** Changes in behavior
Use of the --unix-byte-offsets (-u) option now evokes a warning.
Since 3.1, this Windows-only option has had no effect.
** Bug fixes
Preprocessing N patterns would take at least O(N^2) time when too many
patterns hashed to too few buckets. This now takes seconds, not days:
: | grep -Ff <(seq 6400000 | tr 0-9 A-J)
[Bug#44754 introduced in grep 3.5]
- More details of the changes can be found in the ChangeLog file in the source tarball.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Update from 2.27 to 3.6
- No update of rootfiles required
- Changelog is too long to include here
Full details can be reviewed in the ChangeLog file in the source tarball
55 bug fixes implemented between 2.27 and 3.6
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Most of these files still used old dates and/or domain names for contact
mail addresses. This is now replaced by an up-to-date copyright line.
Just some housekeeping... :-)
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This will allow us to run multiple builds on the same
system at the same time (or at least have them on disk).
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
