From patchwork Thu May 18 18:43:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 6871 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4QMf4y07lHz3wlM for ; Thu, 18 May 2023 18:43:46 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4QMf4r0CWkz9Vp; Thu, 18 May 2023 18:43:40 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4QMf4q5dR9z30Jw; Thu, 18 May 2023 18:43:39 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4QMf4n6mVqz2xZH for ; Thu, 18 May 2023 18:43:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4QMf4n51VGz18M; Thu, 18 May 2023 18:43:37 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1684435417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=asujQHPBdbfQBGSTptYm/+kFck6LRqIiBVoAfskxIGo=; b=qol3xNfHEsIbmaAJxCj03UqoHOBQRE/tabIVhWZHOK9w4BhC9GWcimtjkT/X25AWqEIP2v WLT/JdtjEE/qaPAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1684435417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=asujQHPBdbfQBGSTptYm/+kFck6LRqIiBVoAfskxIGo=; b=to3NFi3gws0fDgH58tdBYCTMUpwOFizR6UugORI5N3IG+63PgKJeWj6jpxU+ggDhamh9eC gipVPBvM9tn32K2fZJWrk+gzcA0NOevqZLC4cf/oIuiBaiv8BogHYtL1cZOWtjdr145y21 /ustYrNZjKCcj2oG201o6dwzsEyQ+XiQwFrg8GtYfFhfWmsDadeJbA6+k76uKo6y2+yffG S5QxAdq8CUix7GT12fhPQrWh8yapDJ1SUO7RRQabe/o/RWUCdCnNdRTyUaNB80fz0cK/aY l3h23rrSA5XesPcIuh4iAxOYXg3x4+NTsg6gmaa2dfq/Fm+aCECeL9ss210t/w== From: Adolf Belka To: development@lists.ipfire.org Subject: [PATCH] grep: Update to version 3.11 Date: Thu, 18 May 2023 20:43:22 +0200 Message-Id: <20230518184328.172754-5-adolf.belka@ipfire.org> In-Reply-To: <20230518184328.172754-1-adolf.belka@ipfire.org> References: <20230518184328.172754-1-adolf.belka@ipfire.org> MIME-Version: 1.0 X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" - 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 --- lfs/grep | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/grep b/lfs/grep index 1a0b45350..dde47ffa2 100644 --- a/lfs/grep +++ b/lfs/grep @@ -24,7 +24,7 @@ include Config -VER = 3.10 +VER = 3.11 THISAPP = grep-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -50,7 +50,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 5ff169a4ed39e8af1e6729fd2e1bafd39036a4f56cf831f990d58bf9e76bc7d8b055254ae7f60509be4e8bf2f3737edb15431a8ecfc7fc058578d2abea3d73b9 +$(DL_FILE)_BLAKE2 = e21785bca20b5a090d32bb5dc525fb298af30165106ed4c289b1518ea3d2acdcacfd6309b12f13be29a4b958f19588546119c695deb2b7500d49dcff86357bdc install : $(TARGET)