Commit Graph

6 Commits

Author SHA1 Message Date
Yann E. MORIN
ec50e407be support/dependencies: drop check for maximal tar version
So far, we checked that the tar present on the host was at most tar
1.29, because tar 1.30 changed the way it generates archives.

Having a maximum tar version requirement meant that we would eventually
always have to build our own host-tar, as distributions are updating
the version they use.

But now, we have found a way to generate reproducible archives starting
with tar 1.27 onward, so we no longer need the check for a maximum tar
version, so we can drop that requirement.

Note: this is semantically a revert of b8fa273d50 (check-host-tar.sh:
blacklist tar 1.30+), but keeping the new, mostly-linear code-path.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Vincent Fazio <vfazio@xes-inc.com>
2021-01-10 22:06:58 +01:00
Yann E. MORIN
c3af086395 support/dependencies: treat BSD-tar like the other cases
Currently, when we detect that tar is BSD-tar, we fake an unsupported
version (major, minor) and rely on the version check to reject BSD-tar.

There is no reason to use such shenanigans, when we can simply reject it
from the onset.

Simplify the logic:
  - use positive logic in the condition
  - directly exit in error

Also, comment that case like the other cases are commented.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-11-24 15:14:50 +01:00
Peter Korsgaard
cdac332d20 check-host-tar.sh: bump minimum tar version to 1.27 for reproducible tar files with long paths
Fixes:
http://autobuild.buildroot.net/results/b18/b187e64a61918f17f69588e2355a03286bc5808e

tar 1.27 subtly changed the tar format when a GNU long link entry is added
(which is done for path elements > 100 characters).  The code used to set
the permission mode of the link entry to 0:

  header = start_private_header ("././@LongLink", size, time (NULL));
  FILL (header->header.mtime, '0');
  FILL (header->header.mode, '0');
  FILL (header->header.uid, '0');
  FILL (header->header.gid, '0');
  FILL (header->header.devmajor, 0);
  FILL (header->header.devminor, 0);

This got dropped in 1.27 by commit df7b55a8f6354e3 (Fix some problems with
negative and out-of-range integers), so the settings from
start_private_header() are used directly - Which are:

  TIME_TO_CHARS (t < 0 ? 0 : min (t, MAX_OCTAL_VAL (header->header.mtime)),
		 header->header.mtime);
  MODE_TO_CHARS (S_IFREG|S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, header->header.mode);
  UID_TO_CHARS (0, header->header.uid);
  GID_TO_CHARS (0, header->header.gid);

The end result is that tar >= 1.27 sets mode to 644.

The consequence of this is that we create different tar files when long path
names are encountered (which often happens when a package downloads a
specific sha1 from a git repo) depending on the host tar version used,
causing hash mismatches.

As a workaround, bump our minimum tar version to 1.27.  It would be nicer to
only do this if we have packages from bzr/git/hg enabled, but that is an
exercise for later.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-02 14:46:52 +02:00
Peter Korsgaard
b8fa273d50 check-host-tar.sh: blacklist tar 1.30+
Tar 1.30 changed the --numeric-owner output for filenames > 100 characters,
leading to hash mismatches for the tar archives we create ourselves from
git.  This is really a fix for a bug in earlier tar versions regarding
deterministic output, so it is unlikely to be reverted in later versions.

For more details, see:
http://lists.busybox.net/pipermail/buildroot/2018-January/211222.html

To work around this issue, blacklist tar 1.30+ similar to how we do it for
pre-1.17 versions so Buildroot falls back to building host-tar.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-27 17:02:26 +01:00
Heiko Abraham
fc90fa9417 Improve tar check if bsdtar is installed
If bsdtar is installed, fix script error for tar version detection.

bsdtar does not provide all expected command line (long) options
like "--hard-dereference". To ensure compatibility, mark version
of tar as 'invalid' and trigger build of 'host-tar'.

[Peter; slightly reworded commit text]
Signed-off-by: Heiko Abraham <abrahamh@web.de>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-31 09:39:40 +02:00
Thomas De Schampheleire
fd10b42ab8 dependencies: build a host-tar if no suitable tar can be found
Some toolchains, like the one built with buildroot itself, use hardlinks (for
example to link between the c++ and g++ binary). Unpacking such a toolchain
with the --strip-components options does not work correctly if the system tar
is too old (<1.17). Even recent releases of RedHat/CentOS still ship with
tar 1.15.

This patch checks for a suitable tar version (tar 1.17+) on the host system,
and adds host-tar to the host dependencies if none can be found.

host-tar is download and extracted as cpio.gz instead of tar.gz, to prevent
chicken-egg problem.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
v4 Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-02-09 22:59:21 +01:00