Jim Meyering wrote:
> I suspect this patch works around your compiler's
> inadequate "bool" support:
>
> diff --git a/src/install.c b/src/install.c
> index 73b3981..19efb1d 100644
> --- a/src/install.c
> +++ b/src/install.c
> @@ -189,7 +189,7 @@ static bool
> extra_mode (mode_t input)
> {
>c
Voelker, Bernhard wrote:
> Jim Meyering wrote
>> I'm beginning to think there's a fundamental problem with your system.
>> Here's the comparable part of truss output on a working Solaris 10
> system:
> ...
>> Remember, you did not compile with gcc.
>>
>> Unless someone can suggest an alternative ex
Jim Meyering wrote
> I'm beginning to think there's a fundamental problem with your system.
> Here's the comparable part of truss output on a working Solaris 10
system:
...
> Remember, you did not compile with gcc.
>
> Unless someone can suggest an alternative explanation,
> I'll have to assume th
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>
>> The *second* time that command is run, it appears to print nothing.
>>
>> Do this in src/:
>>
>> ./touch a b; mode3=2755
>> ./ginstall -Cv -m$mode3 a b
>> ./ginstall -Cv -m$mode3 a b
>
> Bingo!
>
>> If the second invocation of ginstal
Jim Meyering wrote:
> The *second* time that command is run, it appears to print nothing.
>
> Do this in src/:
>
> ./touch a b; mode3=2755
> ./ginstall -Cv -m$mode3 a b
> ./ginstall -Cv -m$mode3 a b
Bingo!
> If the second invocation of ginstall doesn't print anything,
> that indica
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Please run this command from your build directory
>>
>> cd src && { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
>>
>> and tell us what it prints.
>
> somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
>
> $ cd src && {
Jim Meyering wrote:
> Long-term, best for you would be to install GNU diffutils.
done:
===
GNU coreutils 7.4.127-d2510: tests/test-suite.log
===
1 of 1 test failed.
.. contents:: :d
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Please run this command from your build directory
>>
>> cd src && { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
>>
>> and tell us what it prints.
>
> somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
>
> $ cd src && {
On Wed, 19 Aug 2009, Voelker, Bernhard wrote:
somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
$ cd src && { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
>
it waits for the command to be continued ... I can't see why
That's not quite valid (POSIX) sh, which requir
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Please run this command from your build directory
>>
>> cd src && { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
>>
>> and tell us what it prints.
>
> somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
>
> $ cd src && {
Jim Meyering wrote:
> sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -C tests \
>TESTS=cp/preserve-gid VERBOSE=yes
I think you meant
sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -C tests check \
TESTS=cp/preserve-gid VERBOSE=yes
BTW: I'm not sure but shouldn't the tests mak
Jim Meyering wrote:
> Please run this command from your build directory
>
> cd src && { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
>
> and tell us what it prints.
somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
$ cd src && { touch a b; mode3=2755; ./ginstall -Cv
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Did you run it as recommended in README, i.e.,
>> after building as non-root, run this:
>>
>> sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
>
> no.
> I built it as non-root, ran `make check` as non-root, and then
> - because
Voelker, Bernhard wrote:
> It fails on this test:
> # option -C ignored if any non-permission mode should be set
> ginstall -Cv -m$mode3 a b > out || fail=1
> compare out out_installed_second || fail=1
> ginstall -Cv -m$mode3 a b > out || fail=1
> compare out out_insta
Jim Meyering wrote:
> Did you run it as recommended in README, i.e.,
> after building as non-root, run this:
>
> sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
no.
I built it as non-root, ran `make check` as non-root, and then
- because I saw that a few tests can only be run
> Jim Meyering wrote:
>> Voelker, Bernhard wrote:
>> FAIL: misc/stdbuf (exit: 1)
> That one's easy.
> My fault for using skip_test_ before it's defined:
It works:
./misc/stdbuf: skipping test: stdbuf not built
SKIP: misc/stdbuf
>> FAIL: install/install-C (exit: 1)
>> =
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Here's a tarball with those two not-yet-pushed changes:
>
> Now, `make check` works ... mostly.
>
> I attached the 2 logfiles - 1 run as root, 1 run as non-root.
> It seems that the test-suite sometimes relies on GNU coreutils
> like rm or mv in th
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Here's a tarball with those two not-yet-pushed changes:
>
> Now, `make check` works ... mostly.
>
> I attached the 2 logfiles - 1 run as root, 1 run as non-root.
> It seems that the test-suite sometimes relies on GNU coreutils
> like rm or mv in the
Jim Meyering wrote:
> Here's a tarball with those two not-yet-pushed changes:
Now, `make check` works ... mostly.
I attached the 2 logfiles - 1 run as root, 1 run as non-root.
It seems that the test-suite sometimes relies on GNU coreutils
like rm or mv in the path instead of the fresh compiled on
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Here's a better patch.
>> (this also renames check-AUTHORS to sc_check-AUTHORS)
>
> this doesn't work - stdbuf is still tried to be built.
> I double-checked with a fresh `tar zxf ...` and the patches
> to the 3 files.
>
> I attached the (solaris) d
Jim Meyering wrote:
> Here's a better patch.
> (this also renames check-AUTHORS to sc_check-AUTHORS)
this doesn't work - stdbuf is still tried to be built.
I double-checked with a fresh `tar zxf ...` and the patches
to the 3 files.
I attached the (solaris) diff of the files and the
output of `mak
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> coreutils began the switch to C99 years ago, and that sort of
>> initialization is a new addition. We did debate whether to use the
>> new-to-coreutils construct. However, if that's the only bit of code
>> that causes build failure for this compi
Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> coreutils began the switch to C99 years ago, and that sort of
>> initialization is a new addition. We did debate whether to use the
>> new-to-coreutils construct. However, if that's the only bit of code
>> that causes build failure for this compil
Jim Meyering wrote:
> coreutils began the switch to C99 years ago, and that sort of
> initialization is a new addition. We did debate whether to use the
> new-to-coreutils construct. However, if that's the only bit of code
> that causes build failure for this compiler, I may accommodate it with
>
24 matches
Mail list logo
