On Mon, 16 Mar 2015, Dimitrios Apostolou wrote:
On Fri, 13 Mar 2015, Dimitrios Apostolou wrote:
I believe my only choice at this point is to forbid "make dist" if tar is
detected to be old (less than 1.29), and keep doing --hard-dereference. I
open to new ideas though. :-)
Th
On Fri, 13 Mar 2015, Dimitrios Apostolou wrote:
I believe my only choice at this point is to forbid "make dist" if tar is
detected to be old (less than 1.29), and keep doing --hard-dereference. I
open to new ideas though. :-)
The attached patch solves the problem in a more eleg
On Tue, 27 Jan 2015, Pavel Raiskup wrote:
On Monday 26 of January 2015 12:12:09 Dimitrios Apostolou wrote:
On Fri, 23 Jan 2015, Pavel Raiskup wrote:
On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote:
Thank you Joerg. If so then it is an issue that must be fixed in
automake
On Fri, 23 Jan 2015, Pavel Raiskup wrote:
On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote:
Thank you Joerg. If so then it is an issue that must be fixed in
automake, which is the reason I cross-posted to both projects, because I
am not sure which one should be changed!
What
On Mon, 19 Jan 2015, Joerg Schilling wrote:
Dimitrios Apostolou wrote:
On Fri, 16 Jan 2015, Paul Eggert wrote:
Dimitrios Apostolou wrote:
Why is such behaviour desirable?
It's more logical, since it causes tar to behave as if the symlink were not
there, and the pointed-to file was
On Sun, 18 Jan 2015, Paul Eggert wrote:
Dimitrios Apostolou wrote:
But when the tarball is extracted, two files with same inode are created,
which
is kind of unexpected behaviour - at least for me
Other utilities have similar behavior (e.g., ls, cp, du), in that they
pretend the symlink
On Fri, 16 Jan 2015, Paul Eggert wrote:
Dimitrios Apostolou wrote:
Why is such behaviour desirable?
It's more logical, since it causes tar to behave as if the symlink were not
there, and the pointed-to file was there instead.
But when the tarball is extracted, two files with same
On Fri, 16 Jan 2015, Eric Blake wrote:
On 01/16/2015 08:01 AM, Dimitrios Apostolou wrote:
Relevant output from "make V=1 dist":
tardir=cfengine-3.7.0a1.5ffcc54 && tar --format=ustar -chf - "$tardir" |
GZIP=--best gzip -c >cfengine-3.7.0a1.5ffcc54.tar.gz
It is
(Please keep me CC'd as I'm not subscribed.)
Hello list,
as the title says, I believe running "make dist" should fail when tar
fails. The problem is that because there is a shell pipeline with gzip,
the exit code of the pipeline is 0. I'm not aware of a portable way to fix
this (named pipes m
(Cross posting to both bug-automake and bug-tar as I can see both projects
being affected.)
(Please keep me CC'd as I'm not subscribed.)
Hello,
this bug report is because of the following messages when extracting a
source tarball generated with "make dist". You can read the full bug
report at
(Please CC me in the replies as I'm not subscribed)
Hello list,
examing the tarballs generated by "make dist" using "tar -tzvvf", it seems
that information about group/owner of the buildsystem is being leaked.
Example output - notice the jenkins/jenkins field:
# tar -tzvvf core/cfengine-3.7.
11 matches
Mail list logo
