Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>
>> > Or should I go with an alternative patch of making sort.c use xnanosleep
>> > instead of sleep? (For that matter, if we went with xnanosleep, we could
> make
>> > sort's child wait loop start with something smaller, like 0.25 seconds,
On Mon, Nov 23, 2009 at 11:50:47PM +0800, Jian Lin wrote:
> Thanks. I will try the new version soon.
Note that you'll have to reclone the files, the new version won't fix
the old clone I'm afraid.
-chris
Eric Blake byu.net> writes:
> In post-8.1 git, coreutils now fails to link on cygwin 1.5:
>
> CCLD sort.exe
> sort.o: In function `pipe_fork':
> /home/eblake/coreutils-tmp/src/sort.c:898: undefined reference to `_rpl_sleep'
> collect2: ld returned 1 exit status
It also fails to link test-li
Jim Meyering meyering.net> writes:
> > Or should I go with an alternative patch of making sort.c use xnanosleep
> > instead of sleep? (For that matter, if we went with xnanosleep, we could
make
> > sort's child wait loop start with something smaller, like 0.25 seconds,
instead
> > of a minimum
Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>> Looks good.
>
> Thanks for the review.
> I pushed it.
>
>> Would it be worth also warning here about components
>> of the path that are o+w, as that will cause test failures.
>> I had an untested off the cuff script for that here:
>>
>> http://l
Pádraig Brady wrote:
...
> Looks good.
Thanks for the review.
I pushed it.
> Would it be worth also warning here about components
> of the path that are o+w, as that will cause test failures.
> I had an untested off the cuff script for that here:
>
> http://lists.gnu.org/archive/html/bug-coreutil
Eric Blake wrote:
> In post-8.1 git, coreutils now fails to link on cygwin 1.5:
>
> CCLD sort.exe
> sort.o: In function `pipe_fork':
> /home/eblake/coreutils-tmp/src/sort.c:898: undefined reference to `_rpl_sleep'
> collect2: ld returned 1 exit status
>
> this was caused by the gnulib patch:
>
Chen Guo wrote:
> Hi all,
Hi Chen,
Thanks for following up.
It's been frustrating all around.
> I'm looking for some group input/guidance. Is there a kind of
> performance goal we want for a threaded sort implementation? Something I
> can work towards?
Perhaps over-optimistically,
I've been
Hi all,
I'm looking for some group input/guidance. Is there a kind of performance
goal we want for a threaded sort implementation? Something I can work towards?
I submitted a patch earlier, but obviously it had its problems: copious
amounts of copying, worst case n^2, high variance in r
In post-8.1 git, coreutils now fails to link on cygwin 1.5:
CCLD sort.exe
sort.o: In function `pipe_fork':
/home/eblake/coreutils-tmp/src/sort.c:898: undefined reference to `_rpl_sleep'
collect2: ld returned 1 exit status
this was caused by the gnulib patch:
sleep: work around cygwin bug
Jim Meyering wrote:
> Jim Meyering wrote:
> ...
>>> execve("/root/bin/no_such", ["no_such"], [/* 57 vars */]) = -1 EACCES
>>> (Permission denied)
>> ...
>>> /root/bin/ directory is not created in koji buildroot (it is not created by
>>> default at all) - so that might be the difference.
>> Thanks
Jim Meyering wrote:
...
>> execve("/root/bin/no_such", ["no_such"], [/* 57 vars */]) = -1 EACCES
>> (Permission denied)
> ...
>> /root/bin/ directory is not created in koji buildroot (it is not created by
>> default at all) - so that might be the difference.
>
> Thanks! The problem is that your
Thanks. I will try the new version soon.
2009/11/23 Pádraig Brady :
> Jian Lin wrote:
>> 2009/11/23 Pádraig Brady :
>>> Jian Lin wrote:
I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10.
I tried to clone some files with "cp --reflink" to make them
"copy-on-write".
Jian Lin wrote:
> 2009/11/23 Pádraig Brady :
>> Jian Lin wrote:
>>> I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10.
>>> I tried to clone some files with "cp --reflink" to make them
>>> "copy-on-write".
>>> However, I found some of the files cloned have different MD5s to the
>>> ori
2009/11/23 Pádraig Brady :
> Jian Lin wrote:
>> I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10.
>> I tried to clone some files with "cp --reflink" to make them "copy-on-write".
>> However, I found some of the files cloned have different MD5s to the
>> original one.
>>
>> Is BtrFS (o
Ondřej Vašík wrote:
> Jim Meyering wrote:
...
>> Thanks for the report.
>> For the 126 vs 127 problems, it looks like execvp is
>> failing with errno != ENOENT. I.e., when you run "env no_such",
>> we expect execvp to fail with errno == ENOENT, and hence env should
>> exit with EXIT_ENOENT (127).
Hi Jim,
Jim Meyering wrote:
> Ondřej Vašík wrote:
> > I'm trying to package coreutils-8.1 for Fedora Rawhide, but few tests
> > are failing
> > ( http://koji.fedoraproject.org/koji/getfile?taskID=1819634&name=build.log
> > ).
> > I removed all Fedora-only patches to prevent patch-related issues.
Jian Lin wrote:
> I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10.
> I tried to clone some files with "cp --reflink" to make them "copy-on-write".
> However, I found some of the files cloned have different MD5s to the
> original one.
>
> Is BtrFS (or cp with reflink) buggy?
> Or it
I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10.
I tried to clone some files with "cp --reflink" to make them "copy-on-write".
However, I found some of the files cloned have different MD5s to the
original one.
Is BtrFS (or cp with reflink) buggy?
Or it is indeed a feature that I use
Gilles Espinasse wrote:
> path is hardcoded to /us/bin/perl in
> YEAR=`/usr/bin/perl -e 'print [localtime]->[5] + 1900'`;
>
> That fail on LFS style build as perl from toolchain is in /tools/bin and
> final perl is build later
Thanks. Fixed by the patch below.
I could have simply removed the /us
20 matches
Mail list logo
