tag 75011 notabug
close 75011
stop
On 20/12/2024 10:11, Emiliano Ezequiel Parenti wrote:
I mean there is a problem with libstdbuf.so, because operating systems put
that file in the libexec folder, and that folder should only contain
executables, not libraries.
I would like this to change, for
I mean there is a problem with libstdbuf.so, because operating systems put
that file in the libexec folder, and that folder should only contain
executables, not libraries.
I would like this to change, for systems to put files where they should, so
that the so files go to lib, and bash and elf
On 3/4/24 03:10, Paul Eggert wrote:
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardwa
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardware. For example, if you're using ZFS,
I don't know whether the problem I've found is with cp or with cmp, so
I don't know whether to address this report to coreutils or diffutils.
If you think I've guessed wrong, please tell me so.
I am trying to make a backup copy of a very large (40 Gigabyte) data
file
tag 66056 notabug
close 66056
stop
On 17/09/2023 19:37, Pádraig Brady wrote:
On 17/09/2023 18:32, Manfred Alfare wrote:
Hi!
Details described here:
https://forums.linuxmint.com/viewtopic.php?t=404074
I don't think anything in tee has changed between 8.30 and 8.32,
wrt carriage return handling
On 17/09/2023 18:32, Manfred Alfare wrote:
Hi!
Details described here:
https://forums.linuxmint.com/viewtopic.php?t=404074
I don't think anything in tee has changed between 8.30 and 8.32,
wrt carriage return handling, especially on linux.
My best guess is that fsarcher has changed to do
the eq
Hi!
Details described here:
https://forums.linuxmint.com/viewtopic.php?t=404074
Regards
Manfred Alfaré
--
--
Ing. Manfred Alfaré
Reichsstraße 52
A 6890 Lustenau
E-Mail: manfred.alf...@gmx.at
Mobile: +43-680-2079232
Web : www.malfare.name
---
This is not a bug in tar or in Emacs, nor is it a bug in coreutils. It's
a problem with Google Drive or with the Linux kernel driver, so I
suggest contacting whoever's in charge of that (I don't know who that
is). I'm closing the coreutils bug report.
Here are some possibly related strangenesses with Emacs and Linux
on my Lenovo Chromebook while running Emacs. Maybe my
real problem is with my internet provider Spectrum.
: time nice tar -czf foo.tar working --warning=no-file-shrank
tar: working/nqthm-1992/examples/basic/tmp.lisp: Read error at
Mon 13 Mar 2023 11:00:14 PM CDT
Here is a bug report by roberstephenbo...@gmail.com
Help please. I seem to have hit a problem running Emacs under Linux on my
$100 Lenovo
Chromebook while connected to Google Drive.
While running the standard Linux tar command in a shell buffer in
Emacs I got
Okay.
You're Welcome.
Good Jobs tty Team.
Original Message
On Dec 1, 2022, 23:32, Paul Eggert - eggert at cs.ucla.edu wrote:
> On 2022-12-01 01:06, human.id...@simplelogin.com wrote: > I think the issue
> is related to lightdm so it would be better to report the issue to the
On 2022-12-01 01:06, human.id...@simplelogin.com wrote:
I think the issue is related to lightdm so it would be better to report the
issue to the lightdm developers.
Thanks, I'm closing the coreutils bug report.
I think the issue is related to lightdm so it would be better to report the
issue to the lightdm developers.
Thank you for your answer.
Good Jobs tty Team
and almost surely is unrelated to your problem.)
You might ask on an Arch mailing list where to report bugs of the form
that you discovered.
Hello tty Team,
I am using an Arch based distribution. The tty1 screen was opened with the
Ctrl+Alt+F1 key combination. When I pressed the Alt+F1 key on this screen, I
saw the commands I saw while opening the distribution on the screen. I forcibly
shut down the computer so as not to wait any lo
Ulf Zibis wrote:
> Currently we have:
> List-Post: GNU coreutils Bug Reports
>
> When using "reply list" to answer to a comment of bug 12345 in a email client
> such as Thunderbird, my reply is sent to bug-coreutils@gnu.org, but it should
> be sent to 12...@debbugs.gnu.org
>
> So I think, we s
Hi,
Currently we have:
List-Post: GNU coreutils Bug Reports
When using "reply list" to answer to a comment of bug 12345 in a email client
such as Thunderbird, my reply is sent to bug-coreutils@gnu.org, but it should be sent to
12...@debbugs.gnu.org
So I think, we should have:
List-Post: GNU
Thank you, Paul! :)
In my test, the -k option of the sort on Mac behaves differently from GNU sort
(I made a mistake stating -n). In other words,
printf '%s\n' 1,a 0,9 | sort -nk1 -t ,
works on Mac, and this is why I thought GNU sort has a bug at first.
Thank you again for your quick response!
On 10/4/21 08:29, Juncheng Yang wrote:
However, this is confusing because 1) the behavior of `-n` and `-g` are not
consistent
Yes, that is confusing. I have followed up to Pádraig about this.
, 2) the `-n` in GNU sort is different from the sort on MacOS (which has
pos2 as pos1+1 instead of 0
Hi developers,
It looks like I had misunderstanding of how `-k` works, by changing to -k
1,1 now it works.
However, this is confusing because 1) the behavior of `-n` and `-g` are not
consistent, 2) the `-n` in GNU sort is different from the sort on MacOS (which
has pos2 as pos1+1 inste
Fair enough. I didn't see anything about that in the help or man page,
perhaps a note should be added there?
On Wed., 30 Sep. 2020, 7:11 am Pádraig Brady, wrote:
> On 29/09/2020 15:20, Assaf Gordon wrote:
> >
> >> On 29/09/2020 02:18, ned haughton wrote:
> >>> When splitting with -d, the numberi
On 29/09/2020 15:20, Assaf Gordon wrote:
On 29/09/2020 02:18, ned haughton wrote:
When splitting with -d, the numbering screws up after 89:
In addition to Pádraig explanation, please see previous similar
discussion here:
https://lists.gnu.org/archive/html/bug-coreutils/2017-02/msg00050.h
On 29/09/2020 02:18, ned haughton wrote:
When splitting with -d, the numbering screws up after 89:
In addition to Pádraig explanation, please see previous similar
discussion here:
https://lists.gnu.org/archive/html/bug-coreutils/2017-02/msg00050.html
http://bugs.gnu.org/25832
regards,
tag 43684 notabug
close 43684
stop
On 29/09/2020 02:18, ned haughton wrote:
When splitting with -d, the numbering screws up after 89:
It behaves like that on purpose so that there is no limit on the
number of file names to split, and so that normal globbing will
result in the correct order
(so
When splitting with -d, the numbering screws up after 89:
```
$ wc -l ../lat_lon_full
110324 ../lat_lon_full
$ split -d ../lat_lon_full lat_lon_
$ ls
lat_lon_00 lat_lon_09 lat_lon_18 lat_lon_27 lat_lon_36 lat_lon_45
lat_lon_54 lat_lon_63 lat_lon_72 lat_lon_81 lat_lon_9000
lat_lon_900
t' to do that, so you should specify the -s (--stable)
option. -s is a GNU extension.
Closing the bug report, as this should fix the problem for you.
On 7/4/20 2:39 PM, Richard Freedman wrote:
> When I use sort -n -c on a specified column in a file sort reports an error
> and then stops if two numbers are exactly the same.
Could you send us the input, and the output of "sort --debug -n -c -k3"
(assuming you're using column 3)? My guess is that
When I use sort -n -c on a specified column in a file sort reports an error and
then stops if two numbers are exactly the same. I want the sort to find actual
sort errors, i.e. number (n+1) < number(n). This negates the use of sort -n -c
on large files to find files that are actually out of orde
jakub.ku...@oracle.com wrote:
I tested the patch on both intel and sparc platform and all seems to work
without any problem.
So I guess this can be closed as solved.
Thanks for checking; closing.
Thanks,
I tested the patch on both intel and sparc platform and all seems to
work without any problem.
So I guess this can be closed as solved.
best regards,
Jakub
On 5/30/19 1:46 AM, Paul Eggert wrote:
On 5/29/19 1:51 AM, jakub.ku...@oracle.com wrote:
somebody found this bug first at 8.16
On 5/29/19 1:51 AM, jakub.ku...@oracle.com wrote:
somebody found this bug first at 8.16, but this might have been there
for longer.
I looked into the revision history and it seems to have been introduced
long ago. I installed the attached further patch.
>From e7461441325a6edca01b6d6b48a73a
wrote:
Thanks for reporting the problem. Please try the attached patch, which
I've installed in the development repository.
Thanks for reporting the problem. Please try the attached patch, which
I've installed in the development repository.
>From fe913993d0e93ce98f0b8b77a866144dbb8bbada Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 28 May 2019 12:42:24 -0700
Subject: [PATCH] cp: fix /dev/stdin pr
Hi,
I found a problem with your solution (even though maybe even more
improbable). If I call it like this: *cp /dev/stdin b.txt < somedevice*,
both stdin and the argument have the same type and copy still fails.
Possible solution might be to call stat when SAME_INODE fails and try it
ag
copied
I found that problem is with SAME_INODE macro. It accepts two
structures, one from stat and another from fstat function. On Solaris,
each of these can return a different thing. While stat returns
information about the /dev/fd/0 file itself (linked by /dev/stdin),
fstat knows much more fro
On 13/05/19 11:24, jakub.ku...@oracle.com wrote:
> Hi,
>
> We found out that the following simple command fails on Solaris with:
>
> cat srcfile.txt | /usr/gnu/bin/cp /dev/stdin dstfile.txt
> cp: skipping file '/dev/stdin', as it was replaced while being copied
Hi,
We found out that the following simple command fails on Solaris with:
cat srcfile.txt | /usr/gnu/bin/cp /dev/stdin dstfile.txt
cp: skipping file '/dev/stdin', as it was replaced while being copied
I found that problem is with SAME_INODE macro. It accepts two
structures, one
tag 35531 notabug
close 35531
stop
On 03/05/19 17:01, Peter Edwards wrote:
> Hi
>
> Although this bug report seems to be a problem with the windows port
> of ls, it reminded me of an interesting investigation into slow ls
> speeds due to colorizing via the LS_COLORS envir
owever that only apply to stock ls, and since we don't know
what options might have been enabled for that 'ls' (including any
default usage of switches such as those mentioned above), it's
hard to say exactly what the problem is.
A suggestion -- try installing a minimal snap
Hi
Although this bug report seems to be a problem with the windows port
of ls, it reminded me of an interesting investigation into slow ls
speeds due to colorizing via the LS_COLORS environment variable.
See
https://news.sherlock.stanford.edu/posts/when-setting-an-environment-variable-gives
On Friday, May 3, 2019 5:56:35 PM CEST Viktors Berstis wrote:
> I don't think the problem has anything to do with sorting or -U1.
It was unclear what you meant by "the problem" so I pointed out the only
inefficiency that was immediately obvious to me.
> When ls is taki
On 5/2/19 8:43 PM, Viktors Berstis wrote:
> I downloaded it from
> https://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.3.0.exe/download
>
> The help said "Report bugs to " which is what I
> did.
Whoever built it just copied that line from upstream. If the build has
MS-Wind
I don't think the problem has anything to do with sorting or -U1. When
ls is taking over 5 minutes for something that should run in a couple
of seconds, the task manager shows that it is using nearly no CPU
it is doing a lot of "other I/O".
It doesn't loo
reutils.git/commit/?id=v7.0~113
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.5~49
Kamil
> Paul Eggert wrote:
> > On 5/2/19 5:41 PM, Viktors Berstis wrote:
> >> The newer version of "ls" built for Windows has the problem.
> >
> > Ah, then you'
ows source that is newer
anywhere? Thanks.
- Viktors Berstis
Paul Eggert wrote:
On 5/2/19 5:41 PM, Viktors Berstis wrote:
The newer version of "ls" built for Windows has the problem.
Ah, then you'll have to talk to whoever built that version, which is not
me (and generally speaki
On 5/2/19 5:41 PM, Viktors Berstis wrote:
> The newer version of "ls" built for Windows has the problem.
Ah, then you'll have to talk to whoever built that version, which is not
me (and generally speaking they don't hang out on this mailing list).
for Windows has the
problem.
By "new" version, I am using the 64 bit build for windows dated
4/20/2005 at 11:41AM with exe size of 180736 bytes, md5sum:
47ba770d80382cbd66ddba13924c1417 Version 5.3.0 . I didn't see a place
to download a newer binary version to try.
BTW, booting
It's probably something inside the kernel (e.g., filesystem code).
What does the shell command 'strace -o /tmp/tr -s 128 -T ls -U -1
dirname | wc' say? You can see which system calls are taking the most
time by then running 'sort -t"<" -k2n /tmp/tr'. On my platform (Fedora
29 x86-64 ext4, an older
My machine has 64GB of ram, 6 core 3.5ghz processor and fast disks.
The directory in question has 57,600 files in it with a total size of
about 47gb.
On a freshly booted machine (nothing cached), "dir /on dirname | wc"
takes about 6 seconds. The second time it takes about 2 seconds.
On a fresh
On Thursday, May 2, 2019 12:03:31 AM CEST Viktors Berstis wrote:
> When running "ls" or "ls -U" on a windows directory containing 5
> files, ls takes forever. Something seems to be highly inefficient in there.
Could you please try it with ls -U -1?
Kamil
> This is for the 64 bit version bui
When running "ls" or "ls -U" on a windows directory containing 5
files, ls takes forever. Something seems to be highly inefficient in there.
This is for the 64 bit version build 4/20/2005 11:41AM. The exe size is
180736 bytes.
Thanks.
- Viktors Berstis
My console becomes 121 characters wide when I turn on
unicode, but stty says it is 132 characters.
Looking at the stty manpage, I see:
Special settings:
...
* cols N
tell the kernel that the terminal has N columns
* columns N
same as cols N
---
I thought
leep 5
Real 2.31
User 0.00
System 0.00
$ file src/timeout
src/timeout: executable (RISC System/6000) or object module not stripped
$ /usr/bin/time ./src/timeout 2.3 sleep 5
Real 2.30
User 0.00
System 0.00
Perhaps it is a problem in the RPM package?
Please try to build fro
.00
/root>
Could be a missing dependence ?
Regards,
Rudy
-Original Message-
From: Bernhard Voelker
Sent: Wednesday 12 December 2018 22:28
To: Rudy BROSTEAUX ; 33...@debbugs.gnu.org
Subject: Re: bug#33718: Syntaxe problem? I can't find the solution :-(
On 12/12/18 3:24 PM, Rud
On 12/12/18 3:24 PM, Rudy BROSTEAUX wrote:
> I need to use your timeout tool.
>
> But when I tried it works with these not very nice message...
> "timeout: warning: timer_create: Invalid argument"
'man 3p timer_create' says:
EINVAL The specified clock ID is not defined.
No idea. For an analy
I suggest debugging the problem by using "strace timeout ..." rather
than plain "timeout ...".
Hello,
I need to use your timeout tool.
But when I tried it works with these not very nice message...
"timeout: warning: timer_create: Invalid argument"
Can I help me?
Kind regards,
Rudy
2unix'.
On 2018-05-17 2:54 a.m., Ivan Ivanov wrote:
Beyond the CRLF problem, I found that the result, returned by tsort on
the file with dos line endings had duplicates. So it is totally
incorrect.
The conclusion of the thread is that dos/windows/mac line endings
will affect "tsort
tags 22624 fixed
close 22624
stop
(triaging old bugs)
With fixes commited in:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=632eda520f7cf49d9d1662835c7c37e17033e128
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=62e7af0326786a7dec91d982238948eddab9d6af
And no further com
ight be better if in your script you set:
#!/bin/sh
LC_ALL=C
export LC_ALL
...
sort | uniq
...
That will force a standard sort order everywhere in your script.
But as you have told whitespace also should be identical at every line so
this might be the problem in my case. Beca
include the date in the timestamp.
But for the purpose of recreating the problem please do include the
timezone too. The -R,--rfc-2822 option is good to use to avoid the
ambiguous timezone naming used in the traditional legacy output.
$ env TZ=US/Mountain date -R -d "2013-03-10 12:00&qu
close 10423
stop
(triaging old bugs)
On 03/11/12 10:26 AM, Pádraig Brady wrote:
On 11/03/2012 03:31 PM, Michael Felt wrote:
Lots of +++ at the end (might be something left over from debugging), but
ends with:
Testsuite summary for GNU coreutils 8.15
Will test with 8.17 in a few days (8.20 d
close 6970
stop
(triaging old bugs)
On 12/09/12 03:17 PM, Bob Proulx wrote:
It has been quite a while since 01 Sep 2010 when this bug ticket last
had any activity.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6970
Has the relevance of this issue expired?
With no further comments in 6 ye
severity 14456 wishlist
retitle 14456 multibyte: stat's %[X] counts bytes instead of characters
stop
Hello,
On 20/10/18 12:40 PM, Errembault Philippe wrote:
This has absolutely nothing to do with a translation problem. It is
related with the I18N string processing.
As you can see, the
I reopened the bug report.
I had forgotten about this problem, but it is still present in the version 8.25
present on the linux mint 18.3 distribution I'm using right now.This has
absolutely nothing to do with a translation problem. It is related with the
I18N multibytes string processing.
As you can see, the line
close 14456
stop
(triaging old bugs)
Hello,
On 23/05/13 02:39 PM, camion_spam-debr...@yahoo.fr wrote:
stat (GNU coreutils) 8.5
the format string length is counted in bytes and not in characters so that the
presence of variable length characters causes misalignment
In the following example t
Hi again,
one last comment on this:
Beyond the CRLF problem, I found that the result, returned by tsort on
the file with dos line endings had duplicates. So it is totally
incorrect.
Than I've tried the followling:
Instead of giving this as an input:
15731102 16019755
15731102 15731104
157
if I run the input file trhough unix2dos – it works, so I
> suspect some strange problem with the unix newlines.
>
> The input file is generated with python script on the Ubuntu 16.04.3 so
> all newlines should be the same.
>
> Test environments (acting the same way):
> --
Hi again,
I've digged more into this, and I found that unix2dos doesn't fix
the problem, but just masks the tsort behaviour.
If you point the tsort result into a file, you will notice, that tsort
breaks some of the newline chars. The input file seems to be ok.
I am still looking into
On 29/05/17 12:52, Pádraig Brady wrote:
On 28/05/17 01:54, Jonny Grant wrote:
Hello
I noticed a problem in the "man unlink" page.
The OPTIONS section is missing, and the Options are listed in the
DESCRIPTION section. Could the OPTIONS section be added?
Thank you, Jonny
I pres
On 28/05/17 01:54, Jonny Grant wrote:
> Hello
>
> I noticed a problem in the "man unlink" page.
>
> The OPTIONS section is missing, and the Options are listed in the
> DESCRIPTION section. Could the OPTIONS section be added?
>
> Thank you, Jonny
I presume y
Hello
I noticed a problem in the "man unlink" page.
The OPTIONS section is missing, and the Options are listed in the
DESCRIPTION section. Could the OPTIONS section be added?
Thank you, Jonny
UNLINK(1) User Commands
UNLINK
(the ASCII value of 'a') -
neither "\xC3" not "\x82" match and so they are deleted.
> For the moment, I'll try to solve my problem differently, but... is this
> a bug? Thanks in advance!
Not a bug - but a yet-missing feature.
For relevant discussion see her
without the umlaut it gives me the empty result, as expected:
$ echo -ne "\xc3\x82" | tr -cd "a" | xxd
[empty result]
I tested several systems, the oldest is a Debian with coreutils 8.5, the
newest an Ubuntu with coreutils 8.25.
For the moment, I'll try to solve my probl
tag 25755 notabug
close 25755
stop
On 16/02/17 00:18, chuyifan wrote:
> Hi:
>
> I found a problem of tail -F in centos 6.7. The kernel version is
> 2.6.32-642.3.1.el6. I execute "tail -f --follow=name
> --max-unchanged-stats=50 --sleep-interval=1 ./t" in a terminal and
Hi:
I found a problem of tail -F in centos 6.7. The kernel version is
2.6.32-642.3.1.el6. I execute "tail -f --follow=name
--max-unchanged-stats=50 --sleep-interval=1 ./t" in a terminal and execute
echo command to append some content to file t. then I execute "mv t t1", the
&
On 25/01/17 22:39, Eric Blake wrote:
> tag 25536 notabug
> done
>
> On 01/25/2017 04:09 PM, L A Walsh wrote:
>> I was trying to compile a file in the 'src' dir of the coreutils,
>> called 'retab.c' but I got all sorts of weird errors.
>> How does one add a file to be made?
You can see what neede
On 01/25/2017 05:24 PM, L A Walsh wrote:
>
>
> Eric Blake wrote:
>> But it
>> sounds like since you bypassed a step and messed up your tree, it may be
>> easiest to just rerun ./bootstrap to fix the incomplete job (bootstrap
>> runs automake under the hood as needed).
>>
>> By the way, this isn't
ectly?
I just subscribed to it, so I'm pretty sure I have the right
address and such...
the bug-coreutils note got ack'ed back in 2 minutes,
w/your reply coming ~30 minutes later.
Original Message
Subject:problem in ./bootstrap
Date: Wed, 25 Jan 2017 15:
tag 25536 notabug
done
On 01/25/2017 04:09 PM, L A Walsh wrote:
> I was trying to compile a file in the 'src' dir of the coreutils,
> called 'retab.c' but I got all sorts of weird errors. Trying
> to do a make clean and remaking it I now get it in a bunch of files:
>
> ./lib/time.h:20:1: error:
I was trying to compile a file in the 'src' dir of the coreutils,
called 'retab.c' but I got all sorts of weird errors. Trying
to do a make clean and remaking it I now get it in a bunch of files:
./lib/time.h:20:1: error: stray '@' in program
@ PRAGMA_SYSTEM_HEADER @
^
./lib/time.h:20:24: error:
635195392 58%
> /opt/p2pcdn/var/storage
>
> Could you give me a awnser about it?
> What is the problem with it?
Older versions of df need the -P option so that one can
process line by line with filters like grep etc.
thanks,
Pádraig
Hi
I have some issue with this command, please check it out:
[root@XXX]# df -B1 | grep storage
/dev/mapper/vg_storage-lv_storage
6171133591552 3345022828544 2512635195392 58%
/opt/p2pcdn/var/storage
Could you give me a awnser about it?
What is the problem with it?
[root
tag 24527 notabug
close 24527
stop
On 09/24/2016 11:44 AM, Jash Dave wrote:
> There is problem while sorting comma separated entries (specifically
> numbers). Even when the separator symbol is set to comma, it reads all
> following columns with numbers, and doesn't treats comm
There is problem while sorting comma separated entries (specifically
numbers). Even when the separator symbol is set to comma, it reads all
following columns with numbers, and doesn't treats comma as separator
between following numbers.
If I use command:
sort -t"," -k1 -n Example.c
tag 23664 notabug
thanks
On 05/31/2016 12:14 PM, Felippe Silvestre wrote:
> [root@superdssbox999 ~]# date
>
> Tue May 31 15:10:47 BRT 2016
>
>
>
> [root@superdssbox999 ~]# date -d"last month"
>
> Sun May 1 15:10:52 BRT 2016
You've hit a FAQ; relative date terms like "last month" are easier
[root@superdssbox999 ~]# date
Tue May 31 15:10:47 BRT 2016
[root@superdssbox999 ~]# date -d"last month"
Sun May 1 15:10:52 BRT 2016
[root@superdssbox999 ~]# date -d"last day last month"
Sat Apr 30 15:10:54 BRT 2016
[root@superdssbox999 ~]#
Atte.
Felippe Silvestre
ched the GNU coreutils list. We do not know apt-get
or apache2 here ... at least, there are much better places you
could ask for help: the distribution's lists (Ubuntu), or a
mailing list for apache2.
As your problem doesn't seem to be related to any coreutils program,
I'm closing this bug in our bug tracker.
Have a nice day,
Berny
levin@ubuntu-1gb-sgp1-01:~$ sudo apt-get remove apache2*
E: Could not open lock file /var/lib/dpkg/lock - open (2: No such file or
directory)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you
root?
levin@ubuntu-1gb-sgp1-01:~$ sudo /etc/init.d/apache2 reload
* Reloading w
ossible.
>> I'd still disallow this case even for -n1 in case the
>> number was parameterized to number of CPUs or whatever.
>
> Hmm, well, I already spent too much time on this so I think I'll check
> in what I have (since it fixes the GNU/Hurd problem) and let it
> percol
1
From: Paul Eggert
Date: Fri, 12 Feb 2016 10:59:20 -0800
Subject: [PATCH] tests: don't wait forever on GNU/Hurd
* tests/cp/parent-perm-race.sh: Add timeouts so that the test does
not wait forever on GNU/Hurd. This does not fix the underlying
bug but at least lets the tests make progress.
spent too much time on this so I think I'll check
in what I have (since it fixes the GNU/Hurd problem) and let it
percolate a bit first.
I have some qualms about the approach suggested above, as it would cause
'split' to give up on files that it currently handles (e.g., typical
On 11/02/16 09:43, Paul Eggert wrote:
> On 02/11/2016 08:10 AM, Nelson H. F. Beebe wrote:
>> end_offset=9223372036854775807
>>
>
> Thanks, that confirms my suspicions about GNU/Hurd. I'm attaching a
> proposed patch; please give it a try if you have a chance. Turned out to
> be trickier than I t
From b4bca1b306a982145a2fc9ceae0d6576c0d01734 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 11 Feb 2016 09:40:20 -0800
Subject: [PATCH] split: fix problems with /dev/zero
Problem reported by Nelson H.F. Beebe in: http://bugs.gnu.org/22624
Other problems also fixed: basically, the code got confused because
GNU/
Thanks, Paul, for hurdtest.c and the subsequent tiny patch to it.
Here is the test on my GNU/Hurd system on virt-manager + QEMU-KVM
on top of CentOS 7:
$ cc hurdtest.c && time ./a.out
file=/dev/zero
CHR
st_size=9223372036854775807
st_blksize=8192
st_blocks=8
cur_offset=0
end_offset=922337203685477
--- hurdtest.c-ORIG 2016-02-11 09:27:57.422023914 +0100
+++ hurdtest.c 2016-02-11 09:28:29.781433313 +0100
@@ -10,7 +10,7 @@
struct stat st;
off_t cur_offset;
off_t end_offset;
- int fd = open ("/dev/zero", O_RDONLY);
+ int fd = open (file, O_RDONLY);
printf ("file=%s\n", file);
On 10/02/16 13:57, Nelson H. F. Beebe wrote:
> I'm pleased to report successful builds, validations, and
> installations of coreutils-8.25 on at least 72 of the 77 machines in
> our lab running various flavors of Unix.
Looks like were improving well in portability :)
Many thanks for giving access
On 02/10/2016 01:57 PM, Nelson H. F. Beebe wrote:
SKIP: tests/split/line-bytes.sh
Timeout, server 192.168.122.66 not responding.
I presume the test that crashes your system is tests/split/l-chunk.sh,
which invokes commands like 'split -n l/10 /dev/null' and 'split -n 1/2
/dev/ze
1 - 100 of 844 matches
Mail list logo
