Opened 9 months ago

Last modified 2 months ago

#61276 assigned defect

meson @0.55.3: /usr/bin/gnutar: meson-0.55.3/COPYING: implausibly old time stamp 1970-01-01 01:00:00

Reported by: ballapete (Peter Dyballa) Owned by: git@…
Priority: Normal Milestone:
Component: ports Version: 2.6.3
Keywords: tiger leopard powerpc legacy-os Cc: bryancn, jmroot (Joshua Root)
Port: meson

Description

The same error is reported for all files in the tape archive. Reason is that /usr/bin/gnutar is used to outpack the archive. In the end files with this implausible time stamp are installed.

The correct programme to outpack is a recent GNU tar or /opt/local/bin/gnutar.

Attachments (1)

main.log (686.6 KB) - added by ballapete (Peter Dyballa) 9 months ago.
Main.log from PPC Tiger, Mac OS X 10.4.11

Download all attachments as: .zip

Change History (21)

Changed 9 months ago by ballapete (Peter Dyballa)

Attachment: main.log added

Main.log from PPC Tiger, Mac OS X 10.4.11

comment:1 Changed 9 months ago by ryandesign (Ryan Schmidt)

Cc: git@… removed
Owner: set to git@…
Status: newassigned
Summary: /usr/bin/gnutar: meson-0.55.3/COPYING: implausibly old time stamp 1970-01-01 01:00:00meson @0.55.3: /usr/bin/gnutar: meson-0.55.3/COPYING: implausibly old time stamp 1970-01-01 01:00:00

Hmm. The files in the archive have normal current timestamps when unpacked on a more modern macOS 10.13.6. I guess there is a bug in Tiger's gnutar.

comment:2 in reply to:  1 ; Changed 9 months ago by ballapete (Peter Dyballa)

Replying to ryandesign:

Right now it seems to be a (PPC) Tiger problem only. I don't remember whether I had the same problem in Leopard. This check might take some time…

comment:3 Changed 9 months ago by ballapete (Peter Dyballa)

Just checking the time stamps of the installed Meson files on the Leopard volume:

root 552 /\ l -tr /Volumes/Leopard/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/mesonbuild/
total 1928
-rw-r--r--    1 root  wheel   38349  1 Jan  1970 rewriter.py
-rw-r--r--    1 root  wheel   10240  1 Jan  1970 optinterpreter.py
-rw-r--r--    1 root  wheel    4580  1 Jan  1970 munstable_coredata.py
-rw-r--r--    1 root  wheel   51979  1 Jan  1970 mtest.py
-rw-r--r--    1 root  wheel   11250  1 Jan  1970 msubprojects.py
-rw-r--r--    1 root  wheel   12643  1 Jan  1970 msetup.py
-rw-r--r--    1 root  wheel   32219  1 Jan  1970 mparser.py
-rw-r--r--    1 root  wheel   12290  1 Jan  1970 mlog.py
-rw-r--r--    1 root  wheel   23827  1 Jan  1970 mintro.py
-rw-r--r--    1 root  wheel   24149  1 Jan  1970 minstall.py
-rw-r--r--    1 root  wheel    7403  1 Jan  1970 minit.py
-rw-r--r--    1 root  wheel   10255  1 Jan  1970 mesonmain.py
-rw-r--r--    1 root  wheel   61041  1 Jan  1970 mesonlib.py
-rw-r--r--    1 root  wheel   10501  1 Jan  1970 mesondata.py
-rw-r--r--    1 root  wheel   11351  1 Jan  1970 mdist.py
-rw-r--r--    1 root  wheel   12095  1 Jan  1970 mconf.py
-rw-r--r--    1 root  wheel   11096  1 Jan  1970 mcompile.py
-rw-r--r--    1 root  wheel   42990  1 Jan  1970 linkers.py
-rw-r--r--    1 root  wheel   52460  1 Jan  1970 interpreterbase.py
-rw-r--r--    1 root  wheel  228695  1 Jan  1970 interpreter.py
-rw-r--r--    1 root  wheel   14880  1 Jan  1970 envconfig.py
-rw-r--r--    1 root  wheel    2633  1 Jan  1970 depfile.py
-rw-r--r--    1 root  wheel  109734  1 Jan  1970 build.py
-rw-r--r--    1 root  wheel   13259  1 Jan  1970 arglist.py
-rw-r--r--    1 root  wheel       0  1 Jan  1970 __init__.py
-rw-r--r--    1 root  wheel   83600 17 Sep 20:32 environment.py

Looks to have the same problem…

comment:4 Changed 8 months ago by mf2k (Frank Schima)

Keywords: powerpc legacy-os added; ppc removed

comment:5 Changed 8 months ago by ballapete (Peter Dyballa)

There are more such packages: py38-click, py38-jinja2, py38-joblib, py38-regex, py38-tornado.

comment:6 Changed 8 months ago by kencu (Ken)

Here are mine -- look fine -- Tiger PPC -- but I do have the gnutar port installed, if that changes things:

tigerg5$ cd /opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/mesonbuild 
tigerg5$ ls -la
total 1928
drwxr-xr-x   39 root  wheel    1326 Oct 20 19:47 .
drwxr-xr-x   46 root  wheel    1564 Oct 20 19:47 ..
-rw-r--r--    1 root  wheel       0 Aug 15 09:27 __init__.py
drwxr-xr-x   29 root  wheel     986 Oct 20 19:47 __pycache__
-rw-r--r--    1 root  wheel   13259 Sep 10 09:39 arglist.py
drwxr-xr-x    9 root  wheel     306 Oct 20 19:47 ast
drwxr-xr-x   11 root  wheel     374 Oct 20 19:47 backend
-rw-r--r--    1 root  wheel  109740 Oct 20 19:47 build.py
drwxr-xr-x   11 root  wheel     374 Oct 20 19:47 cmake
drwxr-xr-x   19 root  wheel     646 Oct 20 19:47 compilers
-rw-r--r--    1 root  wheel   52437 Oct 20 19:47 coredata.py
drwxr-xr-x   15 root  wheel     510 Oct 20 19:47 dependencies
-rw-r--r--    1 root  wheel    2633 Aug 15 09:27 depfile.py
-rw-r--r--    1 root  wheel   14880 Sep 10 09:39 envconfig.py
-rw-r--r--    1 root  wheel   83599 Oct 20 19:47 environment.py
-rw-r--r--    1 root  wheel  228695 Sep 10 09:39 interpreter.py
-rw-r--r--    1 root  wheel   52460 Sep 10 09:39 interpreterbase.py
-rw-r--r--    1 root  wheel   43005 Oct 20 19:47 linkers.py
-rw-r--r--    1 root  wheel   11096 Sep 10 09:39 mcompile.py
-rw-r--r--    1 root  wheel   12095 Sep 10 09:39 mconf.py
-rw-r--r--    1 root  wheel   11351 Sep 10 09:39 mdist.py
-rw-r--r--    1 root  wheel   10501 Aug 15 09:27 mesondata.py
-rw-r--r--    1 root  wheel   61041 Sep 10 09:39 mesonlib.py
-rw-r--r--    1 root  wheel   10255 Sep 10 09:39 mesonmain.py
-rw-r--r--    1 root  wheel    7403 Sep 10 09:39 minit.py
-rw-r--r--    1 root  wheel   24149 Sep 10 09:39 minstall.py
-rw-r--r--    1 root  wheel   23827 Sep 10 09:39 mintro.py
-rw-r--r--    1 root  wheel   12290 Sep 10 09:39 mlog.py
drwxr-xr-x   24 root  wheel     816 Oct 20 19:47 modules
-rw-r--r--    1 root  wheel   32219 Sep 10 09:39 mparser.py
-rw-r--r--    1 root  wheel   12643 Sep 10 09:39 msetup.py
-rw-r--r--    1 root  wheel   11250 Sep 10 09:39 msubprojects.py
-rw-r--r--    1 root  wheel   51979 Sep 10 09:39 mtest.py
-rw-r--r--    1 root  wheel    4580 Aug 15 09:27 munstable_coredata.py
-rw-r--r--    1 root  wheel   10240 Sep 10 09:39 optinterpreter.py
-rw-r--r--    1 root  wheel   38349 Aug 15 09:27 rewriter.py
drwxr-xr-x   25 root  wheel     850 Oct 20 19:47 scripts
drwxr-xr-x   17 root  wheel     578 Oct 20 19:47 templates
drwxr-xr-x    6 root  wheel     204 Oct 20 19:47 wrap
Last edited 8 months ago by kencu (Ken) (previous) (diff)

comment:7 Changed 8 months ago by ballapete (Peter Dyballa)

root 322 /\ /opt/local/bin/xz -dc /opt/local/var/macports/distfiles/at-spi2-core/at-spi2-core-2.38.0.tar.xz | /opt/local/bin/gnutar --no-same-owner -vtf - | head
drwxr-xr-x mgorse/users      0 2020-09-12 21:22 at-spi2-core-2.38.0/
-rw-r--r-- mgorse/users    420 2020-09-12 21:22 at-spi2-core-2.38.0/AUTHORS
-rw-r--r-- mgorse/users  26530 2020-09-12 21:22 at-spi2-core-2.38.0/COPYING
-rw-r--r-- mgorse/users    816 2020-09-12 21:22 at-spi2-core-2.38.0/INSTALL
-rw-r--r-- mgorse/users     29 2020-09-12 21:22 at-spi2-core-2.38.0/MAINTAINERS
-rw-r--r-- mgorse/users  28371 2020-09-12 21:22 at-spi2-core-2.38.0/NEWS
-rw-r--r-- mgorse/users   3465 2020-09-12 21:22 at-spi2-core-2.38.0/README
-rw-r--r-- mgorse/users   1741 2020-09-12 21:22 at-spi2-core-2.38.0/at-spi2-core.doap
drwxr-xr-x mgorse/users      0 2020-09-12 21:22 at-spi2-core-2.38.0/atspi/
-rw-r--r-- mgorse/users   1419 2020-09-12 21:22 at-spi2-core-2.38.0/atspi/atspi-accessible-private.h
  C-c C-croot 323 /\ /opt/local/bin/xz -dc /opt/local/var/macports/distfiles/at-spi2-core/at-spi2-core-2.38.0.tar.xz | /usr/bin/gnutar --no-same-owner -vtf - | head
drwxr-xr-x mgorse/users      0 1970-01-01 01:00:00 at-spi2-core-2.38.0/
-rw-r--r-- mgorse/users    420 1970-01-01 01:00:00 at-spi2-core-2.38.0/AUTHORS
-rw-r--r-- mgorse/users  26530 1970-01-01 01:00:00 at-spi2-core-2.38.0/COPYING
-rw-r--r-- mgorse/users    816 1970-01-01 01:00:00 at-spi2-core-2.38.0/INSTALL
-rw-r--r-- mgorse/users     29 1970-01-01 01:00:00 at-spi2-core-2.38.0/MAINTAINERS
-rw-r--r-- mgorse/users  28371 1970-01-01 01:00:00 at-spi2-core-2.38.0/NEWS
-rw-r--r-- mgorse/users   3465 1970-01-01 01:00:00 at-spi2-core-2.38.0/README
-rw-r--r-- mgorse/users   1741 1970-01-01 01:00:00 at-spi2-core-2.38.0/at-spi2-core.doap
drwxr-xr-x mgorse/users      0 1970-01-01 01:00:00 at-spi2-core-2.38.0/atspi/
-rw-r--r-- mgorse/users   1419 1970-01-01 01:00:00 at-spi2-core-2.38.0/atspi/atspi-accessible-private.h

Same behaviour in my own account – doesnotworkforme?

comment:8 in reply to:  2 Changed 8 months ago by ballapete (Peter Dyballa)

Replying to ryandesign:

Right now it seems to be a (PPC) Tiger problem only. I don't remember whether I had the same problem in Leopard. This check might take some time…

No, it's also on PPC Leopard, Mac OS X 10.5.8:

DEBUG: system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_python_py-pip/py38-pip/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/py-pip/pip-20.2.4.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 
/usr/bin/gnutar: pip-20.2.4/AUTHORS.txt: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: pip-20.2.4/LICENSE.txt: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: pip-20.2.4/MANIFEST.in: implausibly old time stamp 1970-01-01 01:00:00
...

comment:9 Changed 8 months ago by kencu (Ken)

So -- I guess we're making gnutar a dependency for -- what? -- using xz on older systems?

comment:10 in reply to:  9 ; Changed 8 months ago by ballapete (Peter Dyballa)

Replying to kencu:

So -- I guess we're making gnutar a dependency for -- what? -- using xz on older systems?

Actually gnutar does not need to have any dependency. If it finds any of xz | bzip2 | gzip | lzip | lzma | lzop | compress it can handle compressed tape archives. xz should become a part of MacPorts – how does it work on Catalina or such with xz compressed archives? Apple does not put xz in macOS… A clever option would be if port would be able to determine which of the compressors exists on the system and then decide to fetch the most efficient file – which would mean to take into account data rate of the internet connection, speed of the file system and RAM, and power of the CPU.

comment:11 in reply to:  10 Changed 6 months ago by ryandesign (Ryan Schmidt)

Cc: bryancn added
Keywords: leopard added

Has duplicate #61819.

Replying to ballapete:

Replying to kencu:

So -- I guess we're making gnutar a dependency for -- what? -- using xz on older systems?

Actually gnutar does not need to have any dependency. If it finds any of xz | bzip2 | gzip | lzip | lzma | lzop | compress it can handle compressed tape archives.

Ken was suggesting that we should modify MacPorts base so that, when the distfile is an xz-compressed tarball, we use MacPorts gnutar instead of Tiger or Leopard's older version. However, duplicate #61819 shows that the problem is not specific to xz compression; in that ticket, it was a gz-compressed tarball. So the problem is presumably that some modern tar archives, regardless of what type of compression is later applied to them, cannot be extracted by the version of gnutar on Tiger or Leopard. Whether this is a bug in some modern tar archive creator, or whether these tar archives are valid and there is a bug in the decompression routines in Tiger and Leopard's gnutar, is unknown. It may be worthwhile for someone to investigate. If it turns out that these archives are invalid, then that bug could be fixed in whatever tool was used to create the archives, and then over time fewer invalid archives would be created as people upgrade their tools.

MacPorts handles decompression separately from untarring, so it is unlikely that the compression type has any bearing on our ability to process the uncompressed tarball inside.

Probably the only solution we have for this at the moment is that individual ports that use distfiles that have this quality should have code added to them to use port gnutar on those older systems. I don't know of a way that MacPorts base could detect this problem and do so automatically, since the port's dependencies must be determinable before the distfile has been downloaded.

xz should become a part of MacPorts

The request to do so is #52000 but there is no consensus that we should do so.

how does it work on Catalina or such with xz compressed archives? Apple does not put xz in macOS…

When a portfile specifies use_xz yes, MacPorts base automatically adds an extract dependency on port:xz.

OS X 10.9 and later can decompress xz files, even though they do not include the xz binary. The request to use this facility in MacPorts base and thus avoid the dependency on port:xz is #56237 but nothing has been done about it yet.

A clever option would be if port would be able to determine which of the compressors exists on the system and then decide to fetch the most efficient file – which would mean to take into account data rate of the internet connection, speed of the file system and RAM, and power of the CPU.

I see no reason to do anything of this kind. This would involve many complicated changes to MacPorts base, and I don't see what the benefit would be.

comment:12 Changed 3 months ago by kencu (Ken)

At least part of issue seems to be due to a change in python <https://docs.python.org/3/library/zipfile.html> where they have a new timestamps parameter:

New in version 3.8: The strict_timestamps keyword-only argument

And that now makes Tiger's older utils flag and error, it would seem.

Editing zipfile.py in python38 on Tiger, and changing the default to strict_timestamps=False instead of True and the ports I tried to build on Tiger work again, as you might expect.

I take it this is more or less the behaviour python had for years prior to them implementing the new check.

I am not necessarily suggesting this for MacPorts, but that is what I am doing, and my ports are all building again, so YMMV.

Last edited 3 months ago by kencu (Ken) (previous) (diff)

comment:13 in reply to:  12 ; Changed 3 months ago by ballapete (Peter Dyballa)

Replying to kencu:

Ken,

I don't think that this is the problem. Look here:

pete 232 /\ /opt/local/bin/gnutar vtf distfiles/meson/meson-0.57.1.tar.gz
drwxr-xr-x jpakkane/jpakkane 0 2021-02-20 14:21 meson-0.57.1/
-rw-r--r-- jpakkane/jpakkane 11358 2020-08-15 18:27 meson-0.57.1/COPYING
-rw-r--r-- jpakkane/jpakkane   360 2021-02-09 00:20 meson-0.57.1/MANIFEST.in
-rw-r--r-- jpakkane/jpakkane  1355 2021-02-20 14:21 meson-0.57.1/PKG-INFO
-rw-r--r-- jpakkane/jpakkane  3246 2021-02-01 21:35 meson-0.57.1/README.md
pete 233 /\ /opt/local/bin/gnutar vtf distfiles/meson/meson-0.54.1.tar.gz
drwxr-xr-x jpakkane/jpakkane 0 2020-04-26 11:09 meson-0.54.1/
-rw-r--r-- jpakkane/jpakkane 11358 2016-01-23 19:52 meson-0.54.1/COPYING
-rw-r--r-- jpakkane/jpakkane   415 2020-04-26 11:07 meson-0.54.1/MANIFEST.in
-rw-r--r-- jpakkane/jpakkane  1357 2020-04-26 11:09 meson-0.54.1/PKG-INFO
-rw-r--r-- jpakkane/jpakkane  3354 2020-04-26 11:07 meson-0.54.1/README.md

vs.

pete 237 /\ /usr/bin/gnutar zvtf distfiles/meson/meson-0.57.1.tar.gz
/usr/bin/gnutar: Record size = 8 blocks
drwxr-xr-x jpakkane/jpakkane 0 1970-01-01 01:00:00 meson-0.57.1/
-rw-r--r-- jpakkane/jpakkane 11358 1970-01-01 01:00:00 meson-0.57.1/COPYING
-rw-r--r-- jpakkane/jpakkane   360 1970-01-01 01:00:00 meson-0.57.1/MANIFEST.in
-rw-r--r-- jpakkane/jpakkane  1355 1970-01-01 01:00:00 meson-0.57.1/PKG-INFO
-rw-r--r-- jpakkane/jpakkane  3246 1970-01-01 01:00:00 meson-0.57.1/README.md
pete 238 /\ /usr/bin/gnutar zvtf distfiles/meson/meson-0.54.1.tar.gz
/usr/bin/gnutar: Record size = 8 blocks
drwxr-xr-x jpakkane/jpakkane 0 1970-01-01 01:00:00 meson-0.54.1/
-rw-r--r-- jpakkane/jpakkane 11358 1970-01-01 01:00:00 meson-0.54.1/COPYING
-rw-r--r-- jpakkane/jpakkane   415 1970-01-01 01:00:00 meson-0.54.1/MANIFEST.in
-rw-r--r-- jpakkane/jpakkane  1357 1970-01-01 01:00:00 meson-0.54.1/PKG-INFO
-rw-r--r-- jpakkane/jpakkane  3354 1970-01-01 01:00:00 meson-0.54.1/README.md

To me this looks like Python is not involved here. Indeed I never had a problem to upgrade py38-* ports.

The problem is that port is using (now) faulty tools and I have on my disk files from a time before any Mac OS existed.

pete 225 /\ /opt/local/bin/gnutar --version
tar (GNU tar) 1.34
Copyright © 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Geschrieben von John Gilmore und Jay Fenlason.
pete 226 /\ /usr/bin/gnutar --version
tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097
Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.
Modified to support extended attributes.

comment:14 Changed 3 months ago by ballapete (Peter Dyballa)

Port performed a few minutes ago:

DEBUG: system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_net_nss/nss/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nss/nss-3.62.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 
/usr/bin/gnutar: nss-3.62/nss/.hg_archival.txt: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.arcconfig: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.clang-format: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.gitignore: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.hgignore: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.sancov-blacklist: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/.taskcluster.yml: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/COPYING: implausibly old time stamp 1970-01-01 01:00:00
/usr/bin/gnutar: nss-3.62/nss/Makefile: implausibly old time stamp 1970-01-01 01:00:00

while modern software works (also the complicated way):

pete 230 /\ /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nss/nss-3.62.tar.gz' | /opt/local/bin/gnutar --no-same-owner -vtf - | head
-rw-r--r-- 0/0             136 2021-02-19 11:03 nss-3.62/nss/.hg_archival.txt
-rw-r--r-- 0/0             132 2021-02-19 11:03 nss-3.62/nss/.arcconfig
-rw-r--r-- 0/0            1995 2021-02-19 11:03 nss-3.62/nss/.clang-format
-rw-r--r-- 0/0             167 2021-02-19 11:03 nss-3.62/nss/.gitignore
-rw-r--r-- 0/0             177 2021-02-19 11:03 nss-3.62/nss/.hgignore
-rw-r--r-- 0/0              52 2021-02-19 11:03 nss-3.62/nss/.sancov-blacklist
-rw-r--r-- 0/0            2544 2021-02-19 11:03 nss-3.62/nss/.taskcluster.yml
-rw-r--r-- 0/0           18100 2021-02-19 11:03 nss-3.62/nss/COPYING
-rw-r--r-- 0/0            5041 2021-02-19 11:03 nss-3.62/nss/Makefile

Gnutar can handle all compressed tape archives without auxiliary tools and its recent version should become the tool working at least on Tiger.

comment:15 in reply to:  13 Changed 3 months ago by ryandesign (Ryan Schmidt)

Replying to ballapete:

The problem is that port is using (now) faulty tools and I have on my disk files from a time before any Mac OS existed.

Peter, as I said in comment:11 we have not determined which software is faulty. It could be that Tiger's /usr/bin/gnutar is faulty because it cannot deal with some valid tar archives that are now becoming popular. But it could also be that whatever software is creating these new tarballs is faulty and that the tarballs are actually invalid. If you are interested in this problem being fixed, please try to identify which of these theories is correct. If some modern utility is creating invalid tarballs, you can file a bug report with the author of that utility and explain to them in what way the archives they're creating are invalid, so that they can fix it, so that you will then be able to decompress future archives on Tiger again. Even if the new archives are technically valid, perhaps the author of the utility would be willing to revert whatever change they made that is causing this problem for Tiger's gnutar.

Whatever the cause, as I said earlier, we probably need to modify the affected ports to avoid the use of /usr/bin/gnutar on Tiger until the affected ports are updated to new versions that have tarballs that don't exhibit this problem.

comment:16 in reply to:  14 Changed 3 months ago by ryandesign (Ryan Schmidt)

Replying to ballapete:

Gnutar can handle all compressed tape archives without auxiliary tools and its recent version should become the tool working at least on Tiger.

If you mean that we should simply modify MacPorts base so that it uses /opt/local/bin/gnutar to decompress all tar files, we obviously cannot do that because then you could never install gnutar or its dependencies in the first place since they are distributed as (compressed) tar files.

comment:17 in reply to:  13 Changed 3 months ago by kencu (Ken)

As per https://trac.macports.org/ticket/61819, base hard-codes /usr/bin/gnutar.

If it used gnutar instead of /usr/bin/gnutar, at least on systems prior to darwin10 or something, then gnutar could be transparently be overridden by installing gnutar, which gets you past the bootstrap issue.

there are a few other workarounds in that ticket.

comment:18 Changed 2 months ago by kencu (Ken)

Cc: jmroot added

comment:19 Changed 2 months ago by kencu (Ken)

josh, the ask here is that base not use the full path to gnutar on Tiger, but just use the bare gnutar command, so a newer version installed by the gnutar port would be found and used.

What do you think?

comment:20 Changed 2 months ago by kencu (Ken)

There is also this option for tar --warning=no-timestamp but the tar on Tiger doesn't accept that, it appears:

$ uname -a
Darwin tigerg5.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

$ /usr/bin/tar --warning=no-timestamp
/usr/bin/tar: unrecognized option `--warning=no-timestamp'
Note: See TracTickets for help on using tickets.