Coreutils - upstream mirror

I meet a problem:test-localeconv failed when make check about [email protected] on openEuler_aarch64

Steps to reproduce the issue

[root@localhost coreutils]# make -j126 check
============================================================================
Testsuite summary for GNU coreutils 9.1
============================================================================
# TOTAL: 370
# PASS:  344
# SKIP:  25
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See gnulib-tests/test-suite.log

[root@localhost spack-src]# vim gnulib-tests/test-suite.log
FAIL: test-localeconv
=====================

test-localeconv.c:53: assertion 'l->frac_digits == CHAR_MAX' failed
FAIL test-localeconv (exit status: 134)

or:
[root@localhost gnulib-tests]# ./test-localeconv
test-localeconv.c:53: assertion 'l->frac_digits == CHAR_MAX' failed
Aborted (core dumped)

Can you analyze why the error is reported, or what settings I'm missing?

Hi @pixelb @eggert ,

i can't build coreutils 8.28 with LLVM/clang 5.0.0

In file included from lib/mbsstr.c:32: ./lib/str-kmp.h:42:30: error: use of unknown builtin '__builtin_mul_overflow_p' [-Wimplicit-function-declaration] size_t *table = (size_t *) nmalloca (m, sizeof (size_t)); ^ ./lib/malloca.h:79:25: note: expanded from macro 'nmalloca' #define nmalloca(n, s) (xalloc_oversized (n, s) ? NULL : malloca ((n) * (s))) ^ ./lib/xalloc-oversized.h:46:4: note: expanded from macro 'xalloc_oversized' __builtin_mul_overflow_p (n, s, (__xalloc_count_type) 1) ^ 1 error generated.

here are the logs http://file-store.openmandriva.org/api/v1/file_stores/e06076e9b0c5cef8f2d26b80f37d0143023523c4.log?show=true

Apologies for submitting on GitHub, it's so much more convenient. I will understand if no one sees this because I didn't follow the guidelines.

Justification:

• The existing code is dangerous because it can silently fail to seed the random number generator securely, either when fopen() fails or when read() returns fewer bytes than requested, which can happen if the call is interrupted by an interrupt. This is important for utilities like shred where cryptographic-quality randomness is important.
• I removed the bytes_bound stuff because it didn't seem necessary anywhere it was used, and if get_nonce is ever called with bytes_bound < bufsize, then part of ISAAC's initial state will contain timestamps/PIDs, so it will not be uniformly random. Usually, stream ciphers like ISAAC require their initial state to be uniformly random, otherwise there will be statistical biases in the early output.

I have not tested all the utilities this affects.

(Full disclosure is appropriate in this case because any damage has already been done, fixing the problem in secret would not stop any attacks, but disclosing might encourage users to stop using the dangerous code and upgrade.)

Please consider merging this usage/man change to document recent breaking changes on rmdir tool.

Related to this bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39364 And this commit: https://github.com/coreutils/coreutils/commit/1f443fe57291918ba245b2ffb7cdc07e64630af4

Alternatively revert the linked commit. Regards,

run below script (using inotify)

let count=0; echo $count>>a.log; tail -F a.log & while true; do mv a.log a.log.$count; let count=count+1; echo $count>>a.log; done

When the number of generated file is over the "/proc/sys/fs/inotify/max_user_watches", tail can't watch new a.log file.

Building latest coreutils, running sparse-2.sh test on btrfs will FAIL. After digging on the test script, and run all the test case manually, I have found the reason. test fails on the last part, on line 58

  51 cp --sparse=always k k2 || fail=1
  52 if test $(stat -c %b k2) -ge $(stat -c %b k); then
  53   # If not sparse, then double check by creating with dd
  54   # as we're not guaranteed that seek will create a hole.
  55   # apfs on darwin 19.2.0 for example was seen to not to create holes < 16MiB.
  56   hole_size=$(stat -c %o k2) || framework_failure_
  57   dd if=k of=k2.dd bs=$hole_size conv=sparse || framework_failure_
  58   test $(stat -c %b k2) -eq $(stat -c %b k2.dd) || fail=1
  59 fi

on ext4 file system, cp --sparse=always k k2 will create k2 smaller than k, thus skip the following tests on btrfs file system, cp --sparse=always k k2 will create k2 the same size of k, thus triggers the following tests in the if block on line 57, however, dd if=k of=k2.dd bs=$hole_size conv=sparse will create k2.dd smaller than k2, which is also smaller than k however, on line 58, this test expects k2 and k2.dd are the same size. I think on line 58, -eq should be -ge, because dd if=k of=k2.dd bs=$hole_size conv=sparse works as expected to create a file smaller than the source file.

cp and dd works differently with --sparse on ext4 and btrfs

As others have expressed, mailing lists are antiquated to deal with. Feel free to ignore and close this whenever it's seen.

The last release was March 2020 with 8.32. That is the longest duration between a release for over a decade of coreutil releases.

Not much came up searching the web, this projects README or the resource links provided in this issue template. I did come across an old mailing list question where the answer about release cadence was "whenever it's ready"..

Is there a roadmap or related resource to get an idea of what's blocking that release? (this is a handy feature that platforms like Github or Gitlab can help with)

I'm particularly interested in the cp --reflink=auto default introduced back in June 2020 (fun fact: it's been exactly one year since this commit was made). Some distros backport this, but it'd be nicer to rely on an official release.

It can be confusing/unexpected to find that the behaviour differs between distros packaging for coreutils when the version is the same..

I want to use this code as a basis for my project. I am forking the mv command, since it's relatively simple (~500 lines of dedicated code), and its functions closely match the purpose of my program.

(In case you're curious, I'm making a trash program similar to trash-cli.)

I tried doing make help and ./configure --help, but I found no option to simply compile one binary.

I did a trace on the Makefile, and isolated the command that produces the mv binary: gcc -I. -I./lib -Ilib -I./lib -Isrc -I./src -g -O2 -MT src/mv.o -MD -MP -MF $depbase.Tpo -c -o src/mv.o src/mv.c &&\ echo " CCLD " src/mv;gcc -g -O2 -Wl,--as-needed -o src/mv src/mv.o src/remove.o src/copy.o src/cp-hash.o src/extent-scan.o src/force-link.o src/selinux.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a -lacl -lattr

Of course, it doesn't work without all the object files already generated. I can't tell which lines are producing them, and after skimming the Makefile and configure.ac, I've concluded that I have a newfound appreciation for docker build environments. (I'm mostly a Python programmer, and don't have too much experience with the in-depth GNU toolchains.)

Unfortunately, I can't figure out how to compile it without, y'know, compiling everything else. I don't want to have to drag 50M of source code around just for a variation on a coreutils binary. How can I compile just `mv.c?

I've just updated ubuntu with sudo apt-get update and sudo apt-get upgrade -y but now when I try using the rm command it says command not found. I try sudo apt install coreutils but it's showing I'm on the latest version.

I do understand that this github mirror is not a proper place for reporting bugs but I just refuse to use email do that because such a workflow IMO is absolutely inconvenient, so I'm reporting a problem here and if coreutils developers are interested they will fix it regardless.

I have coreutils 8.32 installed (to be precise coreutils-8.32-18.fc33.x86_64)

It looks like sort by version doesn't always work correctly. Consider this listing:

libpango-1.0.so
libpango-1.0.so.0
libpango-1.0.so.0.4800.4
libpangocairo-1.0.so
libpangocairo-1.0.so.0
libpangocairo-1.0.so.0.4800.4
libpangoft2-1.0.so
libpangoft2-1.0.so.0
libpangoft2-1.0.so.0.4800.4
libpangomm-1.4.so.1
libpangomm-1.4.so.1.0.30
libpangoxft-1.0.so
libpangoxft-1.0.so.0
libpangoxft-1.0.so.0.4800.4

This is exactly what you see when you sort by name.

However when you change the sorting mode to "by version" then something weird happens:

libpangocairo-1.0.so
libpangocairo-1.0.so.0
libpangocairo-1.0.so.0.4800.4
libpangoft2-1.0.so
libpangoft2-1.0.so.0
libpangoft2-1.0.so.0.4800.4
libpangomm-1.4.so.1
libpangomm-1.4.so.1.0.30
libpangoxft-1.0.so
libpangoxft-1.0.so.0
libpangoxft-1.0.so.0.4800.4
libpango-1.0.so
libpango-1.0.so.0
libpango-1.0.so.0.4800.4

This doesn't look right and seems rather illogical. Why has "libpango-1.0.so" become the last one on the list?

Please fix.

I'm not sure if this is translation related issues, but each time I run the "date" program the format is wrong and make me confused.

How to reproduce:

LANG=id_ID.UTF-8 date --date="2021-01-26T18:49:57+07:00"

The result:

Sel 26 Jan 2021 06:49:57  WIB

Expected result:

Sel 26 Jan 2021 18:49:57 WIB

As you can see, the result is wrong. This is off by 12 hours.

It's really frustrating if unaware user use "date" as logging program and they get incorrect result.

Additional note:

If I use LANG=id date, the result is Tue Jan 26 18:49:57 WIB 2021. It seem the time format is correct, but the language and date format is messed up.

NB: I know I can use: date +"%a %d %b %Y %T %Z" with result Sel 26 Jan 2021 18:49:57 WIB to make correct date.

hope you don't mind, I've taken the liberty of algorithmically coding up the primes listed in the testing scenarios for the factor utility, and also created 2 more derivative primes from the same set using combinations of string manipulations.

Feel free to incorporate these into the test cases as you see fit. Aside from gnu-gawk's template codes, I hereby declare all code shown below to be classified under [ public domain ] :

9223372036854775421
9223372036854775643
18446744073709551709
94441166490049640643114101303190314499640643114101
04346046994430930304346046940094664449905590304464482454586302332293465458630233229

       # gawk profile, created Sun Nov 27 17:55:45 2022

       # BEGIN rule(s)

       BEGIN {
     1         OFS = RS
     1     CONVFMT = "%.250g"
     1     ___=(____=(__=((_+=++_)^++_)^(_^_-_-_))-(_^_*(_+_)+_)) \
                     (_____=__-(_^_+(_+_)*(_^_-_)+(_+_)^_))        \
                     (______=__+=__+(_+(_+_^_)*_))                 \
                     (__=rev(substr("", __ = sprintf("%.f%.f", int(____*__),
                     int(_____*__)), gsub("["(_^_)(_^_*_+--_^_)"]+","",__))__))

     1     gsub("[" ((++_+_)*(_+_^_)-_) "]+","",___)
     1     print _____, ____, ______, __, rev(___)
       }

    94  function rev(___, __, _)
       {    
    94     return \
           (_+=_^=_<_)^_<(__=+__ ? +__ : length(___)) \
            ? rev(substr(___,_=int(__/-_)-+-++__),__-_) \
              rev(substr(___,_^!--_,_),_)          \
            :     substr((___)(__<=_++? "" : substr(___,_--,
                       _^_==__) substr(___,_,--_))___,__,__)
       }

and output from gnu-factor utility ::

     - 9223372036854775421: 9223372036854775421
 
     - 9223372036854775643: 9223372036854775643
 
     - 18446744073709551709: 18446744073709551709

     - 94441166490049640643114101303190314499640643114101: 94441166490049640643114101303190314499640643114101

     - 4346046994430930304346046940094664449905590304464482454586302332293465458630233229: 4346046994430930304346046940094664449905590304464482454586302332293465458630233229

On 8.32, When install does: $ strace install -m 0444 -o 0 -g 0 -D "recursive softlink" ... ... newfstatat(AT_FDCWD, "recursive softlink", 0x7ffe91a254d0, 0) = -1 ELOOP (Too many levels of symbolic links)

Which isn't really unexpected, when trying to deal with a softlink like that.

But on 9.1, the install seems to proceed just fine? Now I know that softlinks are a POSIX rabbithole, but the difference in behavior is ... unexpected? To me it looks like this was unintentionally "fixed" by cleaning of some code? Anyway. I can't find a commit or a declaration of changes to behavior. But maybe I'm just looking in the wrong place.

error: opening directory '/tmp/nix-build-coreutils-9.0.drv-0/coreutils-9.0/gt-pwd-long.sh.P4Ne/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz': File name too long

Given /tmp/test is a pipe that is regularly disappearing and reappearing, when running tail -F -n +1 /tmp/test the behavior changed from:

tail: '/tmp/test' has become inaccessible: No such file or directory
tail: '/tmp/test' has appeared;  following new file
tail: /tmp/test: cannot seek to offset 0: Illegal seek

to:

tail: '/tmp/test' has become inaccessible: No such file or directory
tail: '/tmp/test' has appeared;  following new file
[new content]