Bug#456943: bug#15444: One character can be lost if colors are enabled

On 3/25/24 08:49, Vincent Lefevre wrote: This works fine in Xterm, giving on a 80-column terminal: ... However, this triggers the bug in GNOME Terminal (and other libvte-based terminals): That's not good. Is there some escape sequence that will work on both xterm and libvte? I assume the

Bug#1067022: man2html: Segmentation fault with tzfile(5)

On 2024-03-16 16:06, Alejandro Colomar wrote: BTW, I noticed that the upstream homepage is dead: . Is this project defunct? Yes it is. It's been defunct for many years. Attached is a patch for this particular bug. However, a brief code

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 1/31/24 06:06, Pádraig Brady wrote: To my mind the most protective option takes precedence. That's not how POSIX works with mv -i and mv -f. The last flag wins. I assume this is so that people can have aliases or shell scripts that make -i the default, but you can override by specifying

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2024-01-30 03:18, Pádraig Brady wrote: So we now have the proposed change as:   - revert -n to old silent success behavior   - document -n as deprecated   - Leave --update=none as is (will be synonymous with -n)   - Provide --update=none-fail to diagnose and exit failure Thanks, that's

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 1/29/24 08:11, Pádraig Brady wrote: Right, that's why I'm still leaning towards my proposal in the last mail. Well, I won't insist on doing nothing; however, the proposal needs ironing out and now's a good time to do it before installing changes.   - revert to previous exit success

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2024-01-28 05:22, Pádraig Brady wrote: At this stage it seems best for us go back to the original Linux behiavor (use case 3), and to silently deprecate -n in docs to document the portability issues with it. I'm not sure reverting would be best. It would introduce more confusion, and

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2023-12-16 13:46, Bernhard Voelker wrote: Whether the implementation is race-prone or not is an internal thing. I wasn't referring to the internal implementation. I was referring to cp users. With the newer Coreutils (FreeBSD) behavior, you can reliably write a script to do something if

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2023-12-15 10:49, Michael Stone wrote: There's no compelling reason to force this change Well, certainly nobody compelled us at gunpoint Stlll, Pádraig gave a reasonable summary of why the change was made, despite its incompatibility with previous behavior. (One thing I'd add is that

Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

To fix just this bug (as opposed to the other Gnulib-related bugs that may be lurking) try applying the attached Gnulib patch to a grep 3.11 tarball. Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.From d4d8abb39eb02c555f062b1f83ffcfac999c582f Mon Sep 17 00:00:00

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-12 08:28, Alejandro Colomar wrote: I've pushed a signed tag paul1, so you can safely check that the repo is mine (since I don't have HTTPS). Thanks, I'm not sure what exactly this means as I don't contribute to shadow-devel. As far as the remaining patches go, please use your best

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

evised set of patches that addresses the comments you made and embodies my followups.From 324bb0e914b5470650df02bd7b64e963665d44c1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 11 Mar 2023 00:01:02 -0800 Subject: [PATCH 1/8] Simplify change_field by using strcpy * lib/fields.c (change_field)

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 14:39, Alejandro Colomar wrote: I wonder if the patch is really "simplifying". It depends on how one measures simplicity. The reader will need to know strftime's API regardless; requiring the reader to also know strlcpy's API makes the reader's job harder. Also, it's less

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:49, Alejandro Colomar wrote: +: mempcpy (full_tty, "/dev/", sizeof"/dev/" - 1)), This is a great use case for stpcpy(3). I came up with a slightly better approach, that needs neither mempcpy nor stpcpy. I plan to send it along soon.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:59, Alejandro Colomar wrote: If the function is allowed to dereference, then NULL is not allowed, but if the values are uninitialized, then reading any of them should also trigger UB, no? Sure, but the standard says that strftime reads only the struct tm members needed to

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 14:18, Alejandro Colomar wrote: What I'm not sure is that strftime(3) requires nonnull. glibc's strftime implementation segfaults if you pass a null pointer, so we can't pass NULL regardless of whether the strftime API in time.h uses __attribute__ ((nonnull))'.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:59, Alejandro Colomar wrote: Unless the standard specifically allows us to do so, but I can't find anything clear. It's pretty clear if you're a time nerd like me. :-) The standard for strftime says "The appropriate characters are determined using the LC_TIME category of the

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:31, Alejandro Colomar wrote: What's this exactly for? It avoids undefined behavior. A call like strftime (buf, sizeof buf, "XXX", NULL) has undefined behavior, as near as I can make out. It's OK that the dummy is uninitialized.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

d40e2f92f3e50d13d87393bd30b2b4b20b89a2d6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 11 Mar 2023 00:01:02 -0800 Subject: [PATCH 1/6] Fix undefined behavior in change_field * lib/fields.c (change_field): Do not ever compute [-1], as behavior is undefined. Since we know that the string

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

On 2023-01-20 01:51, Santiago Ruano Rincón wrote: I'll clone the bug in Debian (and adjust severities), to make it easier to follow/differentiate both bugs. Paul, do you want me to do the same in debbugs.gnu.org? Please don't bother, since the bug is already fixed upstream.

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Dec 2022 14:16:45 -0800 Subject: [PATCH] grep: bug: backref in last of multiple patterns * NEWS: Mention this. * src/dfasearch.c (GEAcompile): Trim trailing newline from the last pattern, even if it has back-references and follows a pattern

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-06 11:32, Eli Zaretskii wrote: My question was whether in this scenario, since the parent Emacs exits, the child Emacs can get SIGHUP, simply because its parent exited and the read end of the PTY no longer exists. Yes, my sense from the few experiments I tried, is that it's a

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-05 22:51, Eli Zaretskii wrote: But is it possible for a program like Emacs to get SIGHUP in such a situation, or is that highly improbable? We have standard streams of the inferior Emacs process connected via PTYs to the parent process, I believe -- does that deliver SIGHUP or

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-04 00:00, Eli Zaretskii wrote: We need to establish what is the source of SIGHUP in these cases. "These cases" mean, AFAIU, the situations where Emacs launched an async subprocess to do native compilation (which is another Emacs process in a --batch session), and the parent Emacs

Bug#1019724: bug#57604: Bug#1019724: warning: stray \ before - causes autopkgtest failure

On 9/19/22 05:32, Santiago Ruano Rincón wrote: as you can read below, there are 4235 packages including the warning in their build logs. Funnily, grep is also in the list :-) Grep is on the list because Debian indirectly requires ucf to build Grep, and ucf issues the warning about stray \

Bug#922552: [bug-diffutils] bug#36488: diffutils 3.7 make check failure ppc64le opensuse on colors test

art of a release, Debian shouldn't need any patches for diffutils. For now I am closing the diffutils bug report <https://bugs.gnu.org/36488>; if I was too optimistic and the patch doesn't fix things we can always reopen it. From 9b20182d48481c7ca647ff8926feeb8e1da4f7b0 Mon Sep 17 00:00:00

Bug#940852: tzdata should install tzdata.zi file

Package: tzdata Version: 2019c-1 The upstream tzdata by default installs a file /usr/share/zoneinfo/tzdata.zi that contains version info along with the exact source used to generate the TZif binary files. This file was introduced in tzdb 2017c but apparently Debian hasn't picked it up yet. It

Bug#867283: Crash in glibc's mktime in low-memory situations

I proposed a patch here: https://sourceware.org/bugzilla/show_bug.cgi?id=21716#c1 Please give it a try.

Bug#897653: tar 1.30 breaks pristine-tar

On 05/14/2018 07:56 AM, Antonio Terceiro wrote: I still need to study the > code a bit further to try to come up with a better suggestion. Sorry, the only suggestion I can make is that you should just use the new GNU tar. The old one was obviously busted and it generated busted tarballs.

Bug#883733: bug#29613: Debian Bug#883733: grep returns 0 even if there is no match

On 12/08/2017 03:11 AM, Santiago R.R. wrote: $ echo 1 | grep -E '^(11+)\1+$|^1?$' ; echo $? 1 0 Shouldn't the last grep command exit 1 too? Yes it should. This appears to be due to a longstanding bug in the glibc regular expression matcher. See:

Bug#721358: bug#28574: cross compilnng, man pages

Pádraig Brady wrote: + && : $${TZ=UTC} && export TZ\ That should be UTC0 instead of UTC, as POSIX says that TZ=UTC is not portable. Other than that it looks good to me.

Bug#498336: bug#28306: grep: option to filter non-printable characters from contents

Santiago R.R. wrote: What's your position on this? Sounds like a reasonable option, though I think I might make it another form of coloring rather than a separate option.

Bug#532541: bug#27931: grep -o fails to count empty lines (Debain Bug #532541)

es can use 'grep "^$"', which is what I'd expect them to do anyway (-o would be superfluous there even if it included empty matches). >From fe06a81c1fdaeda10bfdde82b43e2b18bfd1de5e Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Thu, 3 Aug 2017 13:07:

Bug#870576: Configure Emacs --without-pop or (in Emacs 26) --with-mailutils

Package: emacs25 Version: 25.1+1-4 Debian ships Emacs with the default configuration, which means it installs a separate program 'movemail' that retrieves email via the POP3 protocol. When it uses POP3, 'movemail' supports only unencrypted mail transfer, which is a significant security

Bug#863002: bug#27763: egrep.sh: grep missing path

Santiago Ruano Rincón wrote: As suggested by this user, it would be better if egrep/fgrep script calls grep using its absolute path. Debian bug 863002 doesn't explain why it would be better, as the original bug report is evidently a case of misunderstanding how PATH works. Although we used

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On 01/25/2017 10:24 AM, Zack Weinberg wrote: The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE from largefile.m4 serial 12", so that sounds like there was an add-on .m4 file with the same functionality floating around prior to that - I don't know where to find copies of that

Bug#851934: bug#23035: date: regression in timezone printing (+%Z)

into Gnulib to improve the parse_datetime2 API, and installed the attached patches into coreutils. This uncovered a bug in one of our recently-added test cases, which the attached patches also fix. From 22767d84c2d80a66d2fc886f55872616432b786d Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.

Bug#842339: [Bug-tar] possible fixes for CVE-2016-6321

542f7205f2548456 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@penguin.cs.ucla.edu> Date: Sat, 29 Oct 2016 21:04:40 -0700 Subject: [PATCH] When extracting, skip ".." members * NEWS: Document this. * src/extract.c (extract_archive): Skip members whose names contain "..".

Bug#783122: tzdata: Wrong data for Europe/Minsk

This problem should go away (or at least be different) once Ubuntu updates to tz 2016g, which no longer uses "MSK" to abbreviate Minsk Time. 2016g uses "+03" instead, as part of the push to use numeric time zone abbreviations instead of inventing alphabetic ones.

Bug#831673: bug#24024: grep: Mixing "max-count" and "after-context" outputs too few lines

ut Control) the documentation could be clearer and I installed the attached patch. From 90a2dd8b7f93ef0a8f08741e6fcb07220f9549f6 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Wed, 7 Sep 2016 22:22:37 -0700 Subject: [PATCH] doc: define "context lines" MIME-Version: 1.

Bug#806331: [Reproducible-builds] [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

On 06/15/2016 01:44 PM, Ximin Luo wrote: In such a case, it is a bug to be using $POSIX_SHELL - which only tests for conformance with POSIX and not these "other bugs that make it unusable". Gnulib can't test for all POSIX violations, only for the ones it knows about. CONFIG_SHELL lets the user

Bug#186568: bug#22793: grep -E assertion failure with back references

arn...@skeeve.com wrote: Paul Eggert <egg...@cs.ucla.edu> wrote: With recent 'grep' you can work around the problem by configuring --with-included-regex. Not so. I did a fresh ./boostrap ./configure --with-included-regex make and it still core dumps: $ ec

Bug#186568: bug#22793: grep -E assertion failure with back references

With recent 'grep' you can work around the problem by configuring --with-included-regex. That has some other undesirable properties, though. This is really a glibc bug and the glibc patch could be applied to the Debian copy of glibc.

Bug#809007: [bug-diffutils] bug#22245: [la...@debian.org: Bug#809007: diffutils: FTBFS: FAIL: test-update-copyright.sh]

Santiago Vila wrote: I find a little bit odd that only the left brace is escaped in the git commit above. Sure, it will remove the warning about the left brace, but it looks a little bit inconsistent. It depends on which sort of consistency one wants. I mildly prefer omitting backslashes when

Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)

Bruce Korb wrote: This file comes from gnulib. Its copyright notice came from Texinfo and I assume that was from its original contributor. Ludovic, do you know what's going on with the copyright notice of doc/gendocs_template?

Bug#772901: os-prober wrong output with grep 2.21 or later

Package: os-prober Version: 1.65 Tags: patch os-prober uses 'grep' in an unportable way, in that it assumes that the regular expression . matches the NUL byte (all zero bits). POSIX doesn't guarantee this, and as of grep 2.21 this might not work. If os-prober assumes GNU grep the fix should

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

I audited the Emacs trunk source code for getenv-related races that have undefined behavior and could have the reported symptoms. I found some other races and installed a fix for them as Emacs trunk bzr 118095. I expect this patch to be harder to backport to older Emacs versions, and less

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

The failure scenario described in https://bugs.debian.org/699325#17 was fixed in Emacs trunk bzr 111064; see Bug#13054 http://bugs.gnu.org/13054. This fix is in the next Emacs release, and the fix should be easily backportable to older Emacs releases. -- To UNSUBSCRIBE, email to

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Paul Eggert wrote: Attached are some proposed patches which should improve the performance of grep -P when applied to binary files, among other things. I have some other ideas for boosting performance further but thought I'd publish these first. I pushed those patches, along with the attached

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

this will solve the performance problem entirely with -P and encoding errors but at least it should be heading in the right direction. From ad34b7d8556e9fc274690666ac6ded2b6576feb3 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Sun, 14 Sep 2014 11:42:08 -0700 Subject: [PROPOSED

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: Glibc regards it as ASCII: You're right. Sorry, I was confused. FreeBSD, Solaris, and AIX work the way that I thought, though. Plus, in GNU regular expressions the pattern . works the way that I thought with LC_ALL=C; my guess (without investigating this) is that

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

On 09/12/2014 02:29 PM, Vincent Lefevre wrote: an option to control what happens on encoding errors would be better and sufficient. It might suffice for your use cases, but it's more complicated and less flexible than being able to match bytes within the regular expression. (Plus, someone

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: I wonder whether anyone is interested in matching individual bytes in a file regarded as UTF-8 encoded. This seems weird. It's not weird at all. For example, suppose we invent the notation [[:error:]] to match encoding errors. Then the pattern '[[:error:]]' would

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: But both of these solutions have the drawback of working only in UTF-8 locales. Not at all; '[[:error:]]' would match a single-byte encoding error in the current locale. The tz database is interested in UTF-8 so it sets the LC_ALL environment variable to a UTF-8

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Come to think of it, grep -P misbehaves badly in multibyte locales that are not UTF-8. It should report an error and exit rather than output gibberish. I installed the attached patch to catch that. From cac91e3e233b769d60d7b5d6bc0e8afc67c0c713 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg

Bug#758105: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: There's no reason that '.' matches something that doesn't belong to the charset in C locale, but doesn't match in a UTF-8 locale. In the C locale on GNU/Linux, all byte values are members of the charset. That is why it's OK for '.' to accept that byte in the C locale

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

: Paul Eggert egg...@cs.ucla.edu Date: Thu, 11 Sep 2014 09:52:01 -0700 Subject: [PATCH] grep: fix false matches with -P '...$' and invalid UTF-8 * src/pcresearch.c (Pexecute): Use PCRE_NOTEOL when matching initial substrings of a line. --- src/pcresearch.c | 3 ++- 1 file changed, 2 insertions

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

it a shot with the attached further patch. From 266b8d4485053a6733e11d43a66c09d080c520fa Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Thu, 11 Sep 2014 12:05:19 -0700 Subject: [PATCH] grep: fix false matches with -P '...$' and invalid UTF-8 * tests/pcre-invalid-utf8-input: Add

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: the C locale corresponds to ANSI_X3.4-1968, No it doesn't, at least not on any current platform I'm aware of. And POSIX does not require that. POSIX even allows the C locale to be multibyte, e.g., UTF-8. I would say that this should be the same for invalid byte

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: ypig% LC_ALL=C locale charmap ANSI_X3.4-1968 That may be what the 'locale' command says, but bytes with the top bit on are considered to be valid single-byte characters. There are no encoding errors. So, in that sense it's not strict ASCII. the current behavior

Bug#758105: bug#18266: grep -P and invalid exits with error

Paul Eggert wrote: perhaps there's a PCRE version dependency here? I found a PCRE-version-dependent problem that may be relevant, and installed the attached further patch to fix it. From dc7d532d16dec740d11b6817c9b558543aca0136 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu

Bug#758105: bug#18266: grep -P and invalid exits with error

patch was applied). So I rewrote it and installed the attached patch instead. Please give it a try. From 29855e7bbe47b91680ae0cba5729c5becfaa3216 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Tue, 9 Sep 2014 12:41:54 -0700 Subject: [PATCH] grep: -P now treats invalid UTF-8

Bug#758105: bug#18266: grep -P and invalid exits with error

Norihiro Tanaka wrote: I see that new version has no response for following test which was used previously. printf '\x80ab\n' | env LC_ALL=en_US.utf8 src/grep -P '.?b' Thanks for reporting that. The test case works for me (Fedora 20 x86-64, GCC 4.9.1): $ printf '\x80ab\n' | env

Bug#760861: bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Mon, 8 Sep 2014 11:40:39 -0700 Subject: [PATCH 1/4] doc: mention which commands are optional * doc/coreutils.texi (coreutils invocation, df invocation) (stty invocation, whoami invocation, nproc invocation) (arch invocation

Bug#758105: grep -P and invalid exits with error

Vincent Lefevre wrote: [...] Note that this option can also be passed to pcre_exec() and pcre_dfa_exec(), to suppress the validity checking of subject strings only. If the same string is being matched many times, the option can be safely set for the second and

Bug#758105: grep -P and invalid exits with error

Thanks, but that patch seems to depend on libpcre internals, in that it knows that pcre_exec cannot possibly succeed without first checking its entire input buffer for invalid UTF-8 bytes. Even if that's true now, it reflects a performance bug that might be fixed in a future libpcre version.

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

Santiago wrote: Another solution would be to don't check if binary files are valid (passing PCRE_NO_UTF8_CHECK to pcre_exec), but I don't know if that'd avoid security holes It wouldn't. (We already tried it.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a

Bug#758105: bug#18266: grep -P and invalid exits with error

Santiago wrote: Please, revert ca7868cc27db3d9deafaa2e0ac5a2bb0aa8ef373 That commit was necessary to avoid undefined behavior in libpcre. We can't simply undo the commit (unless you want to reintroduce security holes into grep :-). The current behavior is the best we can do, unless

Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: it would be better to replace invalid UTF-8 sequences by zero bytes before passing them to libpcre. Is it allowed to do that in Pexecute()? Sorry, I don't know. I was hoping that the volunteer (whoever it is) could figure all this stuff out. grep should work

Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: The problem with this solution is that it would change the length of the text, while replacing invalid bytes by zero bytes could be done in place (if allowed), with very little change of the code, I think. True. Though it might be more user-friendly to use '?' as the

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: On input, using null bytes may be better if one wants to be able to match real replacement characters without false positives. Maybe, though this is no place to get fancy. It's simple to tell users an invalid byte acts like '?'. Simple is good. Anyway, this is a

Bug#602162: /usr/share/zoneinfo/Australia/Sydney: DST indistinguishable

This bug is fixed in the recently-released 2014f release of the tz database, and when that release propagates into Debian you should be able to close this bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#736919: bug#16586: grep: infinite loop in grep -P on some files with invalid UTF-8 sequences

Jim Meyering wrote: This bug is still present in upstream libpcre version 8.35. Ah, sorry, I thought it was Debian-specific. I've reopened grep bug 16586 http://bugs.gnu.org/16586, and have forwarded it to Philip Hazel, who currently has the PCRE bug assigned, according to

Bug#736919: bug#16586: grep: infinite loop in grep -P on some files with invalid UTF-8 sequences

Santiago wrote: it was a debian-pcre-specific bug. Thanks, closing the bug upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738546: bug#16713: [Jakub Wilk] Bug#738546: typo in gzip(1) manpage: syncronizing - synchronizing

On 02/10/2014 07:37 AM, Bdale Garbee wrote: A user of my Debian packaging of gzip points to a typo in the man page. That's not in the upstream version, so I'm taking the liberty of closing the upstream bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a

Bug#720352: bug#15147: tr: crash upon failed write(2)

I can reproduce the problem without coreutils on Ubuntu 13.04 x86-64. Compile the following program with plain gcc foo.c and then run ./a.out /dev/full; it'll dump core the same way. So it appears that this is a bug in the C library, not in coreutils. It's a fairly serious bug, I'd say.

Bug#452365: [Bug-tar] symlink-eating bug: the reproducer

Thanks, I just now reproduced the problem with tar 1.26 but could not reproduce it with the latest git version. this appears to be similar to this bug: http://lists.gnu.org/archive/html/bug-tar/2011-06/msg0.html which was fixed in tar upstream, here:

Bug#598018: bug#12947: [brl...@debian.org: Bug#598018: install: temporary insecure file permissions]

Thanks, I installed this patch into the coreutils master branch, and I'm marking the upstream coreutils bug as done. From 7ee71d9ddad1435bbea00779bcd4c62482ea3473 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Tue, 20 Nov 2012 13:15:34 -0800 Subject: [PATCH] install: fix

Bug#693463: zdiff man page contains incorrect info about /tmp

Package: gzip Version: 1.5-1.1 Debian has added the following text to zdiff.1, but this addition is no longer correct, as /tmp is not used in this case on Debian in gzip 1.5. Can you please remove this from the zdiff man page? Thanks. .P When both files must be uncompressed before comparison,

Bug#647522: non-deterministic compression results with gzip -n9

/commit/?id=0a284baeaedca68017f46d2646e4c921aa98a90d From b9de47462b1b487cf4024b4c157ee5ac6c5849c3 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Sun, 18 Mar 2012 11:07:02 -0700 Subject: [PATCH] gzip: fix nondeterministic compression results Reported by Jakub Wilk in http

Bug#647522: non-deterministic compression results with gzip -n9

Thanks very much for the patch. But can someone who's looked into it please explain why 'window' needs to be zeroed out? This will save me time in reviewing the patch. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?

Bug#647522: non-deterministic compression for CREDITS.gz in libppl9 amd64 armel

I can't reproduce the problem on x86-64 with vanilla gzip 1.4 and vanilla gzip 1.3.12. So the problem appears to be either architecture-dependent, or it's a property of the Debian patches to gzip, or something like that, and I expect we'll need more information about how to reproduce the problem.

Bug#655118: bug#10592: Bug#655118: Please enabled hardened build flags

I am not observing this problem in the Emacs trunk, with either GCC 4.6.2 or GCC 4.7.0 20120127 (experimental), when I compile with -Wformat -Wformat-security. I suspect the problem has already been fixed in the trunk in a different way, by rewriting movemail to use prototypes. I'm therefore

Bug#653073: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for

On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: Note: there is no reason why the kernel could not return the mount information with shadowed paths removed in a separate procfs node, as that would cause no security/troubleshooting problems. That's what I was thinking of, and it'd be a

Bug#653073: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for

On 01/19/12 08:30, Henrique de Moraes Holschuh wrote: On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library This argument would have stronger force if there were real code in a real application, code that solved the overall

Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for

On 01/18/12 06:25, Goswin von Brederlow wrote: What df should do is automatically skip the entries that are obscured or generally inaccessible. Isn't this missing some of the larger context? df is just doing what lots of other programs do: finding out what file systems one has, and reporting

Bug#647522: non-deterministic compression results with gzip -n9

On 12/08/11 02:27, Riku Voipio wrote: According to gzip RFC, the last 4 bytes are ISIZE, which should be uncompressed input size. Which leaves me rather baffled how that can differ on same input files - and how gunzip is completly happy with both versions of compressed file, producing the same

Bug#647522: non-deterministic compression results with gzip -n9

I should add that it's OK (from the point of view of the RFCs) if gzip produces different outputs given the same inputs when compressing. The RFCs allow that and presumably other gzip implementations do that. All that's required is that compress+decompress result in a copy of the original. That

Bug#136231: [Bug-tar] Failure with --owner and --group when names cannot be mapped to IDs

On 08/08/2011 03:28 AM, Thayne Harbaugh wrote: Attached is a patch that allows archives to be created with arbitrary owner or group names. Thanks for the bug report and patch; I was unaware of the problem. This runs into another area that I'd been meaning to enhance for some time: tar doesn't

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

On 12/03/10 02:03, Jim Meyering wrote: Would you mind adding a Bug fixes entry for this in coreutils' NEWS file? It'd be nice to commit that along with an update of the gnulib submodule to the latest. Sure, done, with this notice: cp -u no longer does unnecessary copying merely because

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

than the other, where we can create files in the latter. I suspect this goes beyond what coreutils's test cases can easily do. From 409c6b774c25afce33f8b67fbf7af3eb3304f6cf Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Wed, 1 Dec 2010 21:25:56 -0800 Subject: [PATCH] utimecmp

Bug#602907: [Bug-tar] need help with tar output stability problem

I cannot reproduce the problem that you observe. With tar 1.24 and 1.25, I get the same 60753920-byte file that you generate with tar 1.23. I also get the same file if I use tar 1.15.1. I am building tar on RHEL 5.5 (x86-64) with GCC 4.5.1; except that the 1.15.1 tar is that of RHEL 5.5 itself.

Bug#602907: [Bug-tar] need help with tar output stability problem

On 11/10/2010 10:14 PM, Bdale Garbee wrote: On Wed, 10 Nov 2010 21:59:03 -0800, Paul Eggert egg...@cs.ucla.edu wrote: This file name is exactly 100 bytes long, and if I recall, that used to be a problem area in GNU tar. The 1.24 tarball contains a longlink representation of the file (which

Bug#587702: tar (rmt) hangs since update in lenny when using --rsh-command=\/usr\/bin\/ssh

This bug was also reported to bug-tar in http://lists.gnu.org/archive/html/bug-tar/2010-09/msg00033.html and a fix has been applied to the upstream sources http://git.savannah.gnu.org/cgit/paxutils.git/commit/?id=3098be8a03bded997cfd3b43e92f1784eaeb4322 so the bug should be fixed in the next

Bug#586301: [bug-diffutils] Re: Bug#586301: diffutils: doubled slashes in --recursive output (path//path) (fwd)

On 08/14/10 23:46, Jim Meyering wrote: [PATCH] diff -r: avoid printing excess slashes in concatenated file names Thanks, that looks good to me. Hmm, at some point we should replace zalloc with xzalloc too, I suppose, and maybe get rid of diffutils' 'concat' function. -- To UNSUBSCRIBE,

Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary

Erik Rossen [EMAIL PROTECTED] writes: And, if one wants to be REALLY pedantic, it looks like the file node is supposed to be changed each time. For example, here is an extract: As I read the spec, chown and chgrp are explicitly required to make the equivalent of a chown() call, which in turn

Bug#474436: coreutils: ls --time-style=locale no longer works

Bo Borgerson [EMAIL PROTECTED] writes: Is it possible to maintain an English translation with only LC_TIME info? Yes. I maintain an English translation by hand for GNU diffutils. This is for LC_MESSAGES but a similar thing could be done for LC_TIME. The diffutils message translations are to

Bug#290727: coreutils: dd: Please support /dev/stdin as argument to if=

How about this patch? It fixes the bug that was reported. It does have the downside of possibly failing with EMFILE when the current version would not fail, but that is a minor drawback. 2008-03-30 Paul Eggert [EMAIL PROTECTED] * lib/fd-reopen.c: Work even if FILE is /dev/stdin

Bug#467378: coreutils: Please include a program to truncate files

Jim Meyering [EMAIL PROTECTED] writes: If you don't mind truncating first, how about this? true /var/spool/whatever/foo dd bs=1 seek=2G of=/var/spool/whatever/foo /dev/null Also, the latter command works even if the former command is omitted. That is, by itself, that invocation of

Bug#461049: dd's reaction to a close of the output. (debian Bug#461049)

Following up on Debian bug 461049 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461049, Nick Stoughton [EMAIL PROTECTED] writes: Note that last paragraph ... I believe that this does give dd permission to report its statistics on SIGPIPE. It certainly does. Wow. That perform some

Bug#432941: [Leo Moisio] Bug#432941: autoconf: autoreconf can't handle multi-line assignment to ACLOCAL_AMFLAGS

Thanks for reporting the problem. I installed this doc fix for now. * doc/autoconf.texi (autoreconf Invocation): Document ACLOCAL_AMFLAGS limitation reported by Leo Moisio in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432941. Index: doc/autoconf.texi

  1   2   >