On 2023-07-29 17:30 -0700, Paul Eggert wrote:
> On 2023-07-29 12:44, Pádraig Brady wrote:
>> I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
>> which is what glibc uses to force the smaller time types.
>> However that didn't fix the issue, so I'll need to look a bit more,
>> and how to
A 32-bit "who" program reports funny login dates:
,
| $ file src/who
| src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0,
with debug_info,
On 2023-03-31 13:01 -0700, Paul Eggert wrote:
> On 2023-03-31 10:01, Alberto Salvia Novella wrote:
>> Is this on purpose?
>
> Yes, part of the idea was to let shell programmers easily test whether
> cp successfully copied the data.
By making them stop using the '-n' option, since they cannot
On 2017-03-02 13:16 -0800, L A Walsh wrote:
> Sven Joachim wrote:
>> ,
>> | EXDEV oldpath and newpath are not on the same mounted filesystem.
>> | (Linux permits a filesystem to be mounted at multiple
>> | points, but rename() does not wo
Am 02.03.2017 um 10:51 schrieb Ruediger Meier:
> I have two bind mounts of the same filesystem
>
> $ grep "/tmp" /etc/fstab
> /dev/vg0/tmpdirs /mnt/tmpdirs ext4
> acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
> 1 2
> /mnt/tmpdirs/tmp /tmp none
On 2012-09-24 08:37 +0200, Alan Curry wrote:
Georgiy Treyvus writes:
Finally I had him show me the mount options of the relevant partitions.
Many I recognized. Some I did not. I started researching those I did
Did you notice this one?:
Mount options for fat
(Note: fat is
On 2012-09-24 21:25 +0200, Alan Curry wrote:
If the mount man page disagrees with the kernel, it's still a bug in the man
page at least.
Possibly, but the mount manpage is not part of coreutils.
(Also, the rest of the world needs to work around extra stupidity because of
rsync?)
No, all
On 2011-06-09 22:59 +0200, Bob Proulx wrote:
Johan Oudinet wrote:
GNU coreutils 8.5
Ubuntu 10.10 32bits Ext4
$ sudo touch f; ln f g
ln: creating hard link `g' = `f': Operation not permitted
Thank you for the bug report. However I am unable to recreate this
problem using 8.5 on my Debian
On 2010-09-08 18:24 +0200, Eric Blake wrote:
On 09/08/2010 07:34 AM, Zoltán Krajcsovics wrote:
coreutils version (from man page):
GNU coreutils 6.9.92.4-f088d-dirty
That seems like a weird version - normally, the only people that
should be running a -dirty version are those actually
On 2010-03-08 08:59 +0100, Jim Meyering wrote:
Sven Joachim wrote:
I would like to subscribe this new list to Gmane¹ if nobody has done
Thanks! That would be useful.
this yet. I suppose address encryption² could be turned off (makes it
somewhat more convenient to reply) ?
Personally I
On 2010-03-08 09:57 +0100, Jim Meyering wrote:
Bob Proulx wrote:
Legacy like this?
http://dir.gmane.org/gmane.comp.gnu.coreutils.announce
Good point. Forgot about that. And that's the one *I* requested.
It's just that I don't use that one as much and had
become inured to the
On 2010-03-08 07:51 +0100, Jim Meyering wrote:
There is a new mailing list: coreut...@gnu.org
We will soon hook up a debbugs-based bug tracker to the existing,
bug-coreutils list, and it will create a new ticket for each
seemingly-new thread.
We will then prefer to keep usage questions and
On 2010-03-08 08:50 +0100, Bob Proulx wrote:
Sven Joachim wrote:
As for the group name, gmane.comp.gnu.core-utils.general seems to be a
reasonable choice.
If we are voting then I would vote for coreutils and not
core-utils.
Yes, good point. It's just a bug that bug-coreutils@gnu.org
Am 04.02.2010 um 14:45 schrieb Klaus Bramstedt:
I used the command
date -d $DATE
for almost all dates between Aug 2002 end Jan 2010 in a script.
Date has a format like this
2003-03-30 02:08:17
However, 7 of 42048 randomly distributed dates in the list failed:
date: ungültiges Datum
On 2009-09-08 13:55 +0200, Jim Meyering wrote:
Here's another snapshot, prior to coreutils-7.6.
All tests passed on Debian sid i386, including the (very) expensive and
root checks. :-)
Cheers,
Sven
I found another oddity with ls -v in coreutils 7.2. The placement of
Emacs autosave files is inconsistent:
,
| % touch a .b
| % ls -lav
| total 0
| drwxr-xr-x 2 sven sven 80 Apr 9 09:02 .
| drwxrwxrwt 11 root root 240 Apr 9 09:02 ..
| -rw-r--r-- 1 sven sven 0 Apr 9 09:02 .b
|
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
$ sudo make -k check-root
cd tests make check-root SUBDIRS=
make[1]: Entering directory `/usr/local/src/coreutils-7.1.81-9b653/tests'
make check
On 2009-03-26 16:38 +0100, Kamil Dudka wrote:
On Thursday 26 of March 2009 16:20:15 Sven Joachim wrote:
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
The failure has been already reported:
http
While the ordering of hidden files in ls -v seems to be fixed
now, there are still inconsistencies. Here's what I get in the latest
snapshot:
,
| LANG=C /usr/local/src/coreutils-7.1.63-8e6a6/src/ls -alv
| total 0
| drwxr-xr-x 2 sven sven 160 Mar 19 11:13 .
| drwxrwxrwt 9 root root 200 Mar 19
On 2009-02-24 11:13 +0100, Kamil Dudka wrote:
On Monday 23 February 2009 22:12:48 Sven Joachim wrote:
I just upgraded coreutils from 6.12 to 7.1, and the new sorting behavior
of `ls -v' really irritates me. Backup files are listed before the real
files, parent directory (..) at the very end
I just upgraded coreutils from 6.12 to 7.1, and the new sorting behavior
of `ls -v' really irritates me. Backup files are listed before the real
files, parent directory (..) at the very end... At first I thought that
I had sorted by time and not by name in Emacs' dired:
,
|
I got an error in `make check' in this snapshot:
,
| make[3]: Entering directory
`/usr/local/src/coreutils-6.10.156-0ec48/tests/mkdir'
| make check-TESTS
| make[4]: Entering directory
`/usr/local/src/coreutils-6.10.156-0ec48/tests/mkdir'
| make[5]: Entering directory
On 2008-03-29 19:03 +0100, Jim Meyering wrote:
What type of system are you using?
Debian GNU/Linux sid, i386 architecture.
Kernel?
Linux 2.6.24.4, self-compiled.
Which version of libselinux?
2.0.59, according to `dpkg -l libselinux1'.
Please run this:
strace -o log ./mkdir -Z
On 2008-03-29 19:21 +0100, Jim Meyering wrote:
Here's a patch that actually has a chance of working ;-)
I can confirm that it actually works. :-)
Sven
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
On 2008-03-29 22:08 +0100, Jim Meyering wrote:
Sven Joachim [EMAIL PROTECTED] wrote:
On 2008-03-29 19:03 +0100, Jim Meyering wrote:
Kernel?
Linux 2.6.24.4, self-compiled.
Was that without CONFIG_SECURITY_SELINUX ?
Yes.
open(/proc/self/task/20595/attr/fscreate, O_RDWR|O_LARGEFILE) = -1
Hello Jim,
thanks for your prompt reply. I just downloaded the coreutils 6.1
package from alpha.gnu.org, and it seems this test no longer fails.
However, there is another dircolors related problem if SHELL is not
set. I ran (unset SHELL; make VERBOSE=yes -k check) and noticed the
following
Jim Meyering wrote:
Thanks for reporting that.
Here's how I've fixed it:
[...]
- ['a', {IN = {k = exec\n}},
+ ['a', '-b', {IN = {k = exec\n}},
Yes, that works. Thanks!
Cheers,
Sven
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
27 matches
Mail list logo
