Failure to activate cctools with bsdtar from libarchive port

[agouasmi (Gouasmia)]

Hi,

The log file is attached. I have macOS Mojave 10.14.6

Any ideas?

[agouasmi (Gouasmia)]

log file

[kencu (Ken)]

I have no clue on this one ! Perhaps Josh or RJVB can help.

[jmroot (Joshua Root)]

On 10.14 the system bsdtar doesn't support hfscompression. I guess you probably have the libarchive port installed? If it's outdated, try updating it.

[agouasmi (Gouasmia)]

Thank you for your reply. I do have the lib archive port installed. I have the latest version 3.4.2. (Feb 11th, 2020).

I tried uninstalling->installing but it didn't work. Using port clean before each attempt didn't work either.

[jmroot (Joshua Root)]

Strange. This looks similar (but not identical) to #56563, which was fixed in libarchive 3.4. Could be a new issue in 3.4.2 I guess. Turning off hfscompression in macports.conf should work around it at least.

[agouasmi (Gouasmia)]

Yes, it worked! Thank you and take care!

[kencu (Ken)]

this doesn't turn out to have anything specific to do with cctools

[tobypeterson]

duplicate of #60230

[tobypeterson]

Reopening, I misunderstood the issue. Still need to figure out to repro though.

[tobypeterson]

Alright, I can repro on 10.15; seems to be something special about the cctools package. Requires using bsdtar with --hfsCompression and -p

[tobypeterson]

I think this failure is just an edge case not covered by the previous fix. I think eborisch should take a look, as this appears to be an issue upstream. Just extract any of the cctools packages, e.g. ​http://packages.macports.org/cctools/cctools-927.0.2_2+llvm90.darwin_19.x86_64.tbz2, using bsdtar --hfsCompression -xpf

[eborisch (Eric A. Borisch)]

These are failing as the files it is trying to create are set readonly and have extended metadata associated with them from the buildbot for some reason. Explicitly, they have these (in addition to a "Intentionally left blank" empty resource fork which I've elided) attached: (this is in the cctools tarball linked above)

xattr -l opt/local/share/man/man3/end.3.gz
[...]
com.apple.lastuseddate#PS:
00000000  A5 F5 38 5C 00 00 00 00 AA 2A 8D 10 00 00 00 00  |..8......*......|
00000010
com.apple.metadata:kMDLabel_xnqz26a5n2idcpq4xsodv4zg4u:
00000000  F2 C1 BC 50 DC 76 36 DF 4D 59 1F CB B9 DA F9 1D  |...P.v6.MY......|
00000010  E5 71 D3 83 CD 13 71 7F 02 99 A4 AC CE F6 1D 6E  |.q....q........n|
00000020  AB 6A 26 77 D2 42 F7 65 F2 E0 E4 24 9D CC DE 51  |.j&w.B.e...$...Q|
00000030  05 24 5B 8C B4 AC D9 44 13 07 A4 1F 00 81 F4 20  |.$[....D....... |
00000040  B2 3C 76 67 99 BF 26 8F F2 7B 7E C5 18 73 24 34  |.<vg..&..{~..s$4|
00000050  1A 64 E6 A9 4E 5E BC F1 2B                       |.d..N^..+|
00000059

So there's potentially a bug in libarchive where it tries to ​set these after the file ​has been chmod()-ed to readonly and gets an EPERM. This is similar to a bug I helped fix to get compression working in the first place. I don't know if the ​comment in the code about chmod() clearing ACLs applies to OSX, so that needs some investigation. Anyone know?

But there's also the question of why the builtbot is creating this metadata in the first place. Anyone know why these are on there or if they are needed?

[eborisch (Eric A. Borisch)]

I see that they're getting extended attributes even in a local build... interesting.

[eborisch (Eric A. Borisch)]

Heh. So these are starting from the source cctools tarball. I see in the cctools port there are a number of "delete stray resource fork" actions. It looks like these need to be expanded to catch the manpages, too; this works for me. Will submit a pull request.

devel/cctools/Portfile

@@ -192 +192 @@
         }
         reinplace "s:__TRY_SYSTEM_CLANG__:${try_system_clang}:" ${worksrcpath}/as/driver.c
 
+        foreach file [glob ${worksrcpath}/man/*] {
+            ui_debug "deleting stray rsrc fork from ${file}"
+            if {${os.major} >= 9} {
+                system "cp -X  ${file} ${file}.tmp"
+                system "mv ${file}.tmp ${file}"
+            } else {
+                system "cp /dev/null ${file}/rsrc"
+            }
+        }
+
         foreach file [glob ${worksrcpath}/{*/,}Makefile] {
 
             ui_debug "deleting stray rsrc fork from ${file}"

I will try to get back to the libarchive bits at some point, but this should fix this explicit issue.

[eborisch (Eric A. Borisch)]

​Pull request.

[eborisch (Eric A. Borisch)]

Merged in ​d6e1def.

[kencu (Ken)]

These rsrc forks turned up only in the latest cctools tarball...no idea how they got there. Hopefully they will disappear next time cctools is updated.

[jmroot (Joshua Root)]

Replying to eborisch:

I will try to get back to the libarchive bits at some point, but this should fix this explicit issue.

This was the only ticket tracking the wider issue with the libarchive port, so please open a new one if you want to consider this one as only covering the specific case of extracting cctools.

[jmroot (Joshua Root)]

@eborisch: Didn't notice you weren't Cc'd before, please see above comment.