Subject: bug#73316: closed (Re: bug#73316: Numeric user ID too large when generating the tarball)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 24 Feb 2025 17:06:02 +0000

Your bug report

#73316: Numeric user ID too large when generating the tarball

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
73316: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#73316: Numeric user ID too large when generating the tarball
From: Karl Berry <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 24 Feb 2025 10:04:54 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

[I mailed this yesterday, but the bug has not been updated. Disturbing.
originally mailed on Date: Sun, 23 Feb 2025 13:35:17 -0800.
Trying again.]

Hi Giacomo - back on your report from last year (sorry):

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
    
    1. As you pointed out, TAR_OPTIONS is working fine from the command 
    line, but it doesn't work when written inside Makefile.am, 

You need to add an "export" directive to the Makefile, which requires
GNU make.  As in:

TAR_OPTIONS = --owner=0 --group=0
export TAR_OPTIONS

FWIW, I added this to the manual for the automake-1.17 release
(https://gnu.org//automake/manual/automake.html#Basics-of-Distribution)
following another user's report, https://bugs.gnu.org/19615.

I've added your finding of tax-pax to the manual. I don't know if
tar-pax is portable enough now for general use. It wasn't when it was
invented.

    2. The workaround we were attempting uses an AS_IF to initialize a 
    variable to be used as argument in AM_INIT_AUTOMAKE, but 
    AM_INIT_AUTOMAKE is reading that variable as an option. Are we missing 
    something regarding the syntax of autotools?

As far as I can see, I don't think AM_INIT_AUTOMAKE can handle
"computed" options. Looking at Automake/Options.pm, it is just
considering the options as string constants and checking for validity
using regexps. I don't see a feasible way to do otherwise.

    3. Feature request: it would be nice to have a "tar-no-owner" option
    for AM_INIT_AUTOMAKE that sets user and group ids to 0. (The
    "privileges" issue apparently is only when extracting with
    --same-owner, so intended)

It would be nice. The problem is that there's no portable way to do it,
and it's not simple to detect and change the tar invocation.

If you're willing to use GNU tar, the above should suffice.
If you need to be portable to all tars, then, well, I don't know how/if
it's possible with any other tar.

I'm going to close this for lack of anything more to do, but please
reply/reopen issue as desired. --thanks, karl.

Subject: Numeric user ID too large when generating the tarball
From: [email-masked]
To: [email-masked]
Date: Tue, 17 Sep 2024 10:34:01 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Good morning,

GNU Astronomy Utilities (Gnuastro) uses GNU Autotools. A Gnuastro 
developer encountered the "Numeric user ID too large" error when 
generating a tarball with the 'make dist' command on his macOS (Monterey 
12.3) laptop. His user id is an integer with 9 digits, which is too big 
for the old v7 and ustar formats of tar.

The issue is discussed in Gnuastro's bug tracker 
(https://savannah.gnu.org/bugs/?65578), where the work-around conclusion 
was to use a conditional that adds 'tar-pax' to 'AM_INIT_AUTOMAKE' when 
the user ID is so large. For reference, here is Gnuastro's configure.ac: 
https://git.savannah.gnu.org/cgit/gnuastro.git/tree/configure.ac#n44
The issue was also erroneusly reported in autoconf's bug tracker 
(https://savannah.gnu.org/support/?111123).

Even though we encountered this problem in macOS, this problem may not 
be limited to it. Other user management systems who use such large IDs 
may also cause this issue.

While it is possible to write such workaround downstream in Gnuastro, it 
would be nice to have the issue solved upstream in the GNU Autotools 
since it can happen for any other developer of other software that uses 
Autotools.

Best Regards,
Giacomo Lorenzetti