[MacPorts] #70622: automake @1.17_0 fails to install on 10.4

[MacPorts]

#70622: automake @1.17_0 fails to install on 10.4
------------------------+--------------------
  Reporter:  fhgwright  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.10.1
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------

Comment (by berg-michael):

 Replying to [comment:7 fhgwright]:
 > Replying to [comment:4 berg-michael]:
 > > I am not able to prove this definitively as I don't have a recent
 macOS machine to test.
 > >
 > > However, I think this might be caused by recent versions of bsdtar
 which default to the pax archive format. I see rumblings about these
 changes (https://www.undeadly.org/cgi?action=article;sid=20240417053301,
 https://bugs.python.org/issue36268) in other environments and suspect it
 happened on macOS as well.
 > [...]
 >
 > I don't think that's the issue, for a couple of reasons:
 >
 > 1. AFAIK the extract phase normally unpacks entire tarballs, not
 individual files.

 Things are getting hung up on this command:


 {{{
 "exec -ignorestderr [findBinary tar ${portutil::autoconf::tar_path}]
 -xOj${qflag}f $archive_location ./+CONTENTS"
 }}}

 which evaluates to


 {{{
 tar -xOjf automake-1.17_0.any_any.noarch.tbz2 ./+CONTENTS
 }}}

 The intended output of this command AIUI is simply the contents of
 ./+CONTENTS to stdout. And we do see that output logged. If I drop the
 ./+CONTENTS gnutar unpacks the whole tarball without any complaints.
 >
 > 2. The error message (excerpted above) doesn't sound like it relates to
 this issue.
 >
 I agree, with the caveat that I think this version of gnutar is probably
 just incapable of telling us what's going wrong.

 Further investigation:

 gnutar 1.34 on Ubuntu also dislikes the file and gives a more helpful
 error (truncated):


 {{{
 tar -xOvjf "automake-1.17_0.any_any.noarch.tbz2" ./+CONTENTS
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 ./+CONTENTS
 @name automake-1.17_0
 @portname automake
 @portepoch 0
 @portversion 1.17
 @portrevision 0
 @archs noarch
 opt/local/bin/aclocal
 @comment MD5:733b7a1979a407778c4970c48941270c
 @comment binary:0
 opt/local/bin/aclocal-1.17
 @comment MD5:733b7a1979a407778c4970c48941270c

 [...]

 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
 tar: Ignoring unknown extended header keyword 'SCHILY.fflags'

 }}}

 This lead me to a semi-informative discussion here
 [https://github.com/nodejs/node/issues/22805], which included the
 following comment:

 >FWIW I've encountered some systems with older versions of (gnu) tar that
 will actually exit with a non-zero exit code and produce error messages
 when extracting the tarballs, despite the contents being extracted
 seemingly correctly. So I'd classify it as more than an annoyance.

 The proposed solutions to this problem seem to be:

 0. Suppress the warning at extract-time with --warning=no-unknown-keyword.
 This doesn't exist on gnutar 1.14 so is not an option.

 -or-

 1. Instead of using macOS bsdtar, use gnutar

 -or-

 2. In macOS bsdtar, use --no-xattrs at archive-time

 -or-

 3. In macOS bsdtar, use --format gnutar or --format ustar at archive time.

 -or-

 4. Some amalgam of these options.

 I like option 2 the most, followed by option 3. But I don't know if they
 work.

 If someone with a recent macOS machine (ideally 14 as I think that's most
 likely to be the culprit) could try the following and send the files I'd
 like to see how Tiger handles each output.

 Note that if one of these works, it implies that it should be possible to
 change base to that configuration before repacking affected archives.



 {{{
 #!/bin/bash

 # URL and file names
 url="https://packages.macports.org/automake/automake-1.17_0.any_any.noarch.tbz2"
 downloaded_file="automake-1.17_0.any_any.noarch.tbz2"

 # Download the file
 curl -O "$url"

 # Extract the downloaded archive
 mkdir -p extracted
 bsdtar -xvf "$downloaded_file" -C extracted

 # 1. Re-archive using --format ustar
 bsdtar -cvjf archive_ustar.tbz2 --format ustar -C extracted .

 # 2. Re-archive using --format gnutar
 bsdtar -cvjf archive_gnutar.tbz2 --format gnutar -C extracted .

 # 3. Re-archive using --format pax
 bsdtar -cvjf archive_pax.tbz2 --format pax -C extracted .

 # 4. Re-archive using --format ustar --no-xattrs
 bsdtar -cvjf archive_ustar_no_xattrs.tbz2 --format ustar --no-xattrs -C
 extracted .

 # 5. Re-archive using --format gnutar --no-xattrs
 bsdtar -cvjf archive_gnutar_no_xattrs.tbz2 --format gnutar --no-xattrs -C
 extracted .

 # 6. Re-archive using --format pax --no-xattrs
 bsdtar -cvjf archive_pax_no_xattrs.tbz2 --format pax --no-xattrs -C
 extracted .

 # 7. Re-archive using --no-xattrs
 bsdtar -cvjf archive_no_xattrs.tbz2 --no-xattrs -C extracted .

 # 8. Re-archive with no special arguments
 bsdtar -cvjf archive_default.tbz2 -C extracted .

 # Clean up
 rm -rf extracted
 rm "$downloaded_file"

 echo "Re-archiving and cleanup completed."

 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/70622#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS