GNU bug report logs - #73316
Numeric user ID too large when generating the tarball

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Karl Berry <karl <at> freefriends.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#73316: closed (Numeric user ID too large when generating the
 tarball)
Date: Mon, 24 Feb 2025 17:06:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 24 Feb 2025 10:04:54 -0700
with message-id <202502241704.51OH4sEt1100982 <at> freefriends.org>
and subject line Re: bug#73316: Numeric user ID too large when generating the tarball
has caused the debbugs.gnu.org bug report #73316,
regarding Numeric user ID too large when generating the tarball
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
73316: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: glorenzetti <at> cefca.es
To: bug-automake <at> gnu.org
Subject: Numeric user ID too large when generating the tarball
Date: Tue, 17 Sep 2024 10:34:01 +0200

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

[Message part 3 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: glorenzetti <at> cefca.es
Cc: 73316 <at> debbugs.gnu.org
Subject: Re: bug#73316: Numeric user ID too large when generating the tarball
Date: Mon, 24 Feb 2025 10:04:54 -0700

[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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.