On Thursday, April 26, 2018 7:01:05 PM CEST Christian Weisgerber wrote:
> In the tar 1.30 release there was a problem with the difflink.at
> test; this has been fixed in HEAD. However, the test still fails
> on *BSD and there is an underlying portability issue.
>
> The preparatory part of the tes
On 04/27/2018 05:22 AM, Christian Weisgerber wrote:
I don't know at which level this should be fixed
Simplest, I think, would be for tar to stop using the progname module
and to assume only getprogname instead. The progname module is
problematic for reasons discussed in this thread:
https:/
Sergey Poznyakoff:
> > For GNU tar 1.30, the regression tests remfiles01.at and remfiles02.at
> > (175 176) fail.
>
> Pretty strange, but both tests work for me (the release would have been
> impossible if they woudn't). Any specific conditions in order to
> reproduce that?
It fails for me on Op
Hi Christian,
> For GNU tar 1.30, the regression tests remfiles01.at and remfiles02.at
> (175 176) fail. The immediate problem is that tar's child process
> fails to identify itself as "tar (child)" in the error message.
Pretty strange, but both tests work for me (the release would have been
imp
For GNU tar 1.30, the regression tests remfiles01.at and remfiles02.at
(175 176) fail. The immediate problem is that tar's child process
fails to identify itself as "tar (child)" in the error message.
The underlying cause is a change in gnulib, specifically this commit:
https://git.savannah.gnu.o
Christian Weisgerber wrote:
> I suggest the following fix:
>
> --- /home/naddy/difflink.at Thu Apr 26 18:58:04 2018
> +++ difflink.at Thu Apr 26 18:52:59 2018
> @@ -20,7 +20,7 @@
> mkdir a
> genfile -f a/x
> ln -s x a/y
> -ln a/y a/z
> +ln -P a/y a/z
Do you like this to fail on many s