libzzip: destroot fails when user's UID is large because pax/tar header field is too small

[brian@…]

I get this error staging libzzip:

$ port install libzzip
--->  Computing dependencies for libzzip
--->  Fetching libzzip
--->  Verifying checksum(s) for libzzip
--->  Extracting libzzip
--->  Applying patches to libzzip
--->  Configuring libzzip
--->  Building libzzip
--->  Staging libzzip into destroot
Error: Target org.macports.destroot returned: no files matched glob pattern "*.3"

[brian@…]

Sorry, I forgot to add a few things:

• libzzip 0.13.60
• OS X 10.5.8
• XCode 3.1

[ryandesign@…]

If you're really running Xcode 3.1, you should ​upgrade to Xcode 3.1.4.

[brian@…]

XCode 3.1.2, actually. Unfortunately I don't have root access to the system and getting software upgraded is not at all easy, so I only ask when it is absolutely necessary. I'd be on 10.6 if I could.

[ryandesign@…]

I bet if you wait a couple months more you can be on 10.7 :)

[ryandesign@…]

So for some reason, pax was unable to pack up the manpages during the build phase, and therefore unable to unpack them again during the destroot phase, and therefore there were no manpages for the glob command to find.

Tell me about Second_HD. Is this a normal Mac-formated hard drive? Is it case sensitive, or is there anything else unusual about it?

Tell me about /bin/pax. Does it work when you use it manually from the terminal?

What user are you when you're running the port command, and what is that user's uid? What is the MacPorts user (what is macportsuser set to in macports.conf) and what is that user's uid?

[brian@…]

I didn't have the heart to reply before, in a couple of month I might just be 2 revs behind :(

Let's see, Second_HD is formatted case sensitive, otherwise it isn't unusual. I am not running as a root user. One issue that occasionally causes problems are the group names, the default group comes from Active Directory and has a space in the name. I run macports as user blandy, and that is the ID defined in macports.conf. The group is "HOU1\domain users". UID and GID are 20746962 and 1582497824, respectively.

Ah, pax doesn't appear to work properly. A simple command like this:

pax -x tar -w test.txt > test.tar

Gives this error message:

pax: Ustar header field is too small for uid 20746962, using nobody
pax: Ustar header field is too small for xpdfrc

[ryandesign@…]

Sorry I seem to have forgotten this ticket. Were you able to figure out how to fix your pax command, for example by restoring it from your backups or reinstalling it from your Mac OS X installation media?

[amintora@…]

I'm seeing the same problem: Running OS-X: 10.6.8 , Xcode: 3.2.6 (1761)

dsur2-lt61:~ atora$ sudo port install libzzip
--->  Computing dependencies for libzzip
--->  Staging libzzip into destroot
Error: Target org.macports.destroot returned: no files matched glob pattern "*.3"
Log for libzzip is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>
dsur2-lt61:~ atora$ 
dsur2-lt61:~ atora$

tail of main.log:

:info:destroot xinstall: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/zziplib-0.13.60/docs/zzip-parse.htm -> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/destroot/opt/local/share/doc/libzzip/html/zzip-parse.htm
:info:destroot xinstall: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/zziplib-0.13.60/docs/zzip-sdl-rwops.htm -> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/destroot/opt/local/share/doc/libzzip/html/zzip-sdl-rwops.htm
:info:destroot xinstall: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/zziplib-0.13.60/docs/zzip-xor.htm -> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/destroot/opt/local/share/doc/libzzip/html/zzip-xor.htm
:info:destroot xinstall: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/zziplib-0.13.60/docs/zzip-zip.htm -> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/work/destroot/opt/local/share/doc/libzzip/html/zzip-zip.htm
:error:destroot Target org.macports.destroot returned: no files matched glob pattern "*.3"
:debug:destroot Backtrace: no files matched glob pattern "*.3"
    while executing
"$post $targetname"
:info:destroot Warning: the following items did not execute (for libzzip): org.macports.activate org.macports.destroot org.macports.install
:notice:destroot Log for libzzip is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libzzip/libzzip/main.log

[ryandesign@…]

The end of the main.log isn't so interesting. The entire main.log might be, to see if it's the same root cause as in this ticket (pax doesn't work). If it is, same advice to you as is already above in this ticket: fix your pax command.

[brian@…]

I believe the issue is pax can't handle large UIDs, and if you are logged in via Active Directory, you get a very large UID. I looked into this a bit and it seemed like it might be possible to tell libzzip to use a different archiver? I believe its configure script prefers pax but can fallback to other utilities.

[ryandesign@…]

Replying to brian@…:

it might be possible to tell libzzip to use a different archiver? I believe its configure script prefers pax but can fallback to other utilities.

That would be fine. If you can provide more info on how this might be accomplished perhaps we can change the port. I did not find a configure flag for this.

[brian@…]

No, I don't think there was a configure script option. But it looked as if, and I didn't test this, that if pax were not found in the path that it would fall back to something else.

[amintora@…]

from 'sudo port install libzzip'

[amintora@…]

Replying to brian@…:

I believe the issue is pax can't handle large UIDs, and if you are logged in via Active Directory, you get a very large UID...

Hmm... very interesting. libzzip compiles fine on my other mac os x (with same OS, XCode, port, etc.) and fails on the mac that I have on LDAP directory... my UID is long: uid=0123456789(username)

{I've changed the digits to 0...9 for security reasons}

[amintora@…]

Replying to brian@…:

Ah, pax doesn't appear to work properly. A simple command like this:

pax -x tar -w test.txt > test.tar

Gives this error message:

pax: Ustar header field is too small for uid 20746962, using nobody
pax: Ustar header field is too small for xpdfrc

yep same issue here, assuming it means Tar header field for UID is too small for my UID (since I'm on LDAP):

ator-abc:~ atora$ 
ator-abc:~ atora$ echo 'asd;fkajsdf;lkajsflaksjfal;kjf;asljfadj' > test.txt
ator-abc:~ atora$ cat test.txt 
asd;fkajsdf;lkajsflaksjfal;kjf;asljfadj
ator-abc:~ atora$ pax -x tar -w test.txt > test.tar
pax: Tar header field is too small for test.txt
ator-abc:~ atora$ 

[amintora@…]

debug version...

[ryandesign@…]

Fine. So if someone can figure out how to tell libzzip not to use pax and to use something else, we'll modify the port to do that.

[ryandesign@…]

Has duplicate #31764.

[jmr@…]

r90863