Log message:
grep: Update to 3.11

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.

Log message:
grep: Update to 3.10

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]

* 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]

Log message:
grep: Update to 3.8

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.

Log message:
*: recursive bump for perl 5.36

Log message:
textproc: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes

Unfetchable distfiles (fetched conditionally?):
./textproc/convertlit/distinfo clit18src.zip

Log message:
textproc: Remove SHA1 hashes for distfiles

Log message:
grep: update to 3.7.

** 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]

* Noteworthy changes in release 3.6 (2020-11-08) [stable]

** Changes in behavior

  The GREP_OPTIONS environment variable no longer affects grep's behavior.
  The variable was declared obsolescent in grep 2.21 (2014), and since
  then any use had caused grep to issue a diagnostic.

** Bug fixes

  grep's DFA matcher performed an invalid regex transformation
  that would convert an ERE like a+a+a+ to a+a+, which would make
  grep a+a+a+ mistakenly match "aa".
  [Bug#44351 introduced in grep 3.2]

  grep -P now reports the troublesome input filename upon PCRE execution
  failure.  Before, searching many files for something rare might fail with
  just "exceeded PCRE's backtracking limit".  Now, it also reports \ 
which file
  triggered the failure.

Log message:
*: recursive bump for perl 5.34

Log message:
grep: Update to 3.5

Changelog:
* Noteworthy changes in release 3.5 (2020-09-27) [stable]

** Changes in behavior

  The message that a binary file matches is now sent to standard error
  and the message has been reworded from "Binary file FOO matches" to
  "grep: FOO: binary file matches", to avoid confusion with ordinary
  output or when file names contain spaces and the like, and to be
  more consistent with other diagnostics.  For example, commands
  like 'grep PATTERN FILE | wc' no longer add 1 to the count of
  matching text lines due to the presence of the message.  Like other
  stderr messages, the message is now omitted if the --no-messages
  (-s) option is given.

  Two other stderr messages now use the typical form too.  They are
  now "grep: FOO: warning: recursive directory loop" and "grep: FOO:
  input file is also the output".

  The --files-without-match (-L) option has reverted to its behavior
  in grep 3.1 and earlier.  That is, grep -L again succeeds when a
  line is selected, not when a file is listed.  The behavior in grep
  3.2 through 3.4 was causing compatibility problems.

** Bug fixes

  grep -I no longer issues a spurious "Binary file FOO matches" line.
  [Bug#33552 introduced in grep 2.23]

  In UTF-8 locales, grep -w no longer ignores a multibyte word
  constituent just before what would otherwise be a word match.
  [Bug#43225 introduced in grep 2.28]

  grep -i no longer mishandles ASCII characters that match multibyte
  characters.  For example, 'LC_ALL=tr_TR.utf8 grep -i i' no longer
  dumps core merely because 'i' matches 'İ' (U+0130 LATIN CAPITAL
  LETTER I WITH DOT ABOVE) in Turkish when ignoring case.
  [Bug#43577 introduced partly in grep 2.28 and partly in grep 3.4]

  A performance regression with -E and many patterns has been mostly fixed.
  "Mostly" as there is a performance tradeoff between Bug#22357 and \ 
Bug#40634.
  [Bug#40634 introduced in grep 2.28]

  A performance regression with many duplicate patterns has been fixed.
  [Bug#43040 introduced in grep 3.4]

  An N^2 RSS performance regression with many patterns has been fixed
  in common cases (no backref, and no use of -o or --color).
  With only 80,000 lines of /usr/share/dict/linux.words, the following
  would use 100GB of RSS and take 3 minutes. With the fix, it used less
  than 400MB and took less than one second:
    head -80000 /usr/share/dict/linux.words > w; grep -vf w w
  [Bug#43527 introduced in grep 3.4]

** Build-related

  "make dist" builds .tar.gz files again, as they are still used in
  some barebones builds.

* Noteworthy changes in release 3.4 (2020-01-02) [stable]

** New features

  The new --no-ignore-case option causes grep to observe case
  distinctions, overriding any previous -i (--ignore-case) option.

** Bug fixes

  '.' no longer matches some invalid byte sequences in UTF-8 locales.
  [bug introduced in grep 2.7]

  grep -Fw can no longer false match in non-UTF-8 multibyte locales
  For example, this command would erroneously print its input line:
    echo ab | LC_CTYPE=ja_JP.eucjp grep -Fw b
  [Bug#38223 introduced in grep 2.28]

  The exit status of 'grep -L' is no longer incorrect when standard
  output is /dev/null.
  [Bug#37716 introduced in grep 3.2]

  A performance bug has been fixed when grep is given many patterns,
  each with no back-reference.
  [Bug#33249 introduced in grep 2.5]

  A performance bug has been fixed for patterns like '01.2' that
  cause grep to reorder tokens internally.
  [Bug#34951 introduced in grep 3.2]

** Build-related

  The build procedure no longer relies on any already-built src/grep
  that might be absent or broken.  Instead, it uses the system 'grep'
  to bootstrap, and uses src/grep only to test the build.  On Solaris
  /usr/bin/grep is broken, but you can install GNU or XPG4 'grep' from
  the standard Solaris distribution before building GNU Grep yourself.
  [bug introduced in grep 2.8]

Log message:
*: bump PKGREVISION for perl-5.32.