From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] sed: Update to 4.8 Date: Wed, 03 Feb 2021 22:34:59 +0000 Message-ID: <384A8E72-CC78-4046-91D5-6CFF51DC7561@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7893170759281508174==" List-Id: --===============7893170759281508174== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 3 Feb 2021, at 22:33, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 03/02/2021 23:27, Michael Tremer wrote: >> Hi Adolf, >> In all the patches from today, you seem to have a little issue in the root= files. >> Scroll down please. >>> On 3 Feb 2021, at 15:01, Adolf Belka wrote: >>>=20 >>> - Update sed from 4.4 to 4.8 >>> - Updated rootfile >>> - Changelog >>> * Noteworthy changes in release 4.8 (2020-01-14) [stable] >>> ** Bug fixes >>> - "sed -i" now creates temporary files with correct umask (limited to u= =3Drwx). >>> Previously sed would incorrectly set umask on temporary files, result= ing >>> in problems under certain fuse-like file systems. >>> [bug introduced in sed 4.2.1] >>> ** Release >>> distribute gzip-compressed tarballs once again >>> ** Improvements >>> a year's worth of gnulib development, including improved DFA performa= nce >>> * Noteworthy changes in release 4.7 (2018-12-20) [stable] >>> ** Bug fixes >>> - Some uses of \b in the C locale and with the DFA matcher would fail, = e.g., >>> the following would mistakenly print "123-x" instead of "123": >>> echo 123-x|LC_ALL=3DC sed 's/.\bx//' >>> - Using a multibyte locale or certain regexp constructs (some ranges, >>> backreferences) would avoid the bug. [bug introduced in sed 4.6] >>> * Noteworthy changes in release 4.6 (2018-12-19) [stable] >>> ** Improvements >>> - sed now prints a clear error message when r/R/w/W (and s///w) commands >>> are missing a filename. Previously, w/W commands would fail with conf= using >>> error message, while r/R would be a silent no-op. >>> - sed now uses fully-buffered output (instead of line-buffered) when >>> writing to files. This should noticeably improve performance of "sed = -i" >>> and other write commands. >>> Buffering can be disabled (as before) with "sed -u". >>> - sed in non-cygwin windows environments (e.g. mingw) now properly hand= les >>> '\n' newlines in -b/--binary mode. >>> ** Bug fixes >>> - sed no longer accesses invalid memory (heap overflow) when given inva= lid >>> backreferences in 's' command [bug#32082, present at least since sed-= 4.0.6]. >>> - sed no longer adds extraneous NUL when given s/$//n command. >>> [related to bug#32271, present since sed-4.0.7] >>> - sed no longer accesses invalid memory (heap overflow) with s/$//n reg= exes. >>> [bug#32271, present since sed-4.3]. >>> ** New Features >>> New option, --debug: print the input sed script in canonical form >>> and annotate program execution. >>> * Noteworthy changes in release 4.5 (2018-03-31) [stable] >>> ** Bug fixes >>> - sed now fails when matching very long input lines (>2GB). >>> Before, sed would silently ignore the regex without indicating an >>> error. [Bug present at least since sed-3.02] >>> - sed no longer rejects comments and closing braces after y/// commands. >>> [Bug existed at least since sed-3.02] >>> - sed -E --posix no longer ignores special meaning of '+','?','|' . >>> [Bug introduced in the original implementation of --posix option in >>> v4.1a-5-gba68fb4] >>> - sed -i now creates selinux context based on the context of the symlink >>> instead of the symlink target. [Bug present since at least sed-4.2] >>> - sed -i --follow-symlinks remains unchanged. >>> - sed now treats the sequence '\x5c' (ASCII 92, backslash) as literal >>> backslash character, not as an escape prefix character. >>> [Bug present since sed-3.02.80] >>> Old behavior: >>> $ echo z | sed -E 's/(z)/\x5c1/' # identical to 's/(z)/\1/' >>> z >>> New behavior: >>> $ echo z | sed -E 's/(z)/\x5c1/' >>> \1 >>>=20 >>> Signed-off-by: Adolf Belka >>> --- >>> config/rootfiles/common/sed | 2 +- >>> lfs/sed | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>>=20 >>> diff --git a/config/rootfiles/common/sed b/config/rootfiles/common/sed >>> index 8db08fa39..f355a89ca 100644 >>> --- a/config/rootfiles/common/sed >>> +++ b/config/rootfiles/common/sed >>> @@ -1,3 +1,3 @@ >>> bin/sed >>> #usr/share/info/sed.info >>> -#usr/share/man/man1/sed.1 >>> +#usr/share/man/man1/sed.1 >>> \ No newline at end of file >> There is a newline missing at the end of it. > Whoops. My error. For some reason I had it in my memory that I should "not"= have a blank line at the end of the rootfile. > I realise now that I "should" have a blank line at the end of all of them. = Will put a note about this in my list of things that I should pay attention t= o getting right. > Sorry. Next sets of patches will not have that problem. No problem. All files have a \n at the end. There are no exceptions as far as I know and = every editor should do it automatically. >=20 > Regards, > Adolf >> I corrected a couple of them and in general they confuse tar when building= the image. >> Did you change editors or something? >> -Michael >>> diff --git a/lfs/sed b/lfs/sed >>> index 9123183e3..9c5b33e4a 100644 >>> --- a/lfs/sed >>> +++ b/lfs/sed >>> @@ -24,7 +24,7 @@ >>>=20 >>> include Config >>>=20 >>> -VER =3D 4.4 >>> +VER =3D 4.8 >>>=20 >>> THISAPP =3D sed-$(VER) >>> DL_FILE =3D $(THISAPP).tar.xz >>> @@ -53,7 +53,7 @@ objects =3D $(DL_FILE) >>>=20 >>> $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) >>>=20 >>> -$(DL_FILE)_MD5 =3D e0c583d4c380059abd818cd540fe6938 >>> +$(DL_FILE)_MD5 =3D 6d906edfdb3202304059233f51f9a71d >>>=20 >>> install : $(TARGET) >>>=20 >>> --=20 >>> 2.30.0 --===============7893170759281508174==--