GNOME Bugzilla – Bug 722621
gtk-doc tarball was created with 32bit uid/gid, unusable with mingw/msys tar
Last modified: 2018-03-26 03:10:52 UTC
Cerbero build fails on Windows while trying to extract gtk-doc-1.19 TAR archive with the following messages: [(7/39) gtk-doc-lite -> fetch ] -----> Step done [(7/39) gtk-doc-lite -> extract ] -----> Extracting tarball to C:/mingw/msys/1.0/home/User/cerbero/sources/windows_x86_64/gtk-doc-lite-1.19 Unpacking C:/mingw/msys/1.0/home/User/cerbero/sources/local/gtk-doc-lite-1.19/gtk-doc-1.19.tar.xz in C:/mingw/msys/1.0/home/User/cerbero/sources/windows_x86_64 Running command 'tar -Jxf /C/mingw/msys/1.0/home/User/cerbero/sources/local/gtk-doc-lite-1.19/gtk-doc-1.19.tar.xz' tar: Archive value 141164 is out of uid_t range 0..65535 tar: Archive value 141164 is out of uid_t range 0..65535 tar: Archive value 141164 is out of uid_t range 0..65535 tar: Archive value 141164 is out of uid_t range 0..65535 tar: Archive value 141164 is out of uid_t range 0..65535 tar: Archive value 141164 is out of uid_t range 0..65535 ... tar: Exiting with failure status due to previous errors ***** Error running 'build' command: Recipe 'gtk-doc-lite' failed at the build step 'extract' Repacking the archive in Linux and replacing the original one fixes the problem.
*** Bug 727174 has been marked as a duplicate of this bug. ***
Alexey, we just updated to gtk-doc(-lite) 1.20. Can you retry with current cerbero master and confirm it fixes the issue ?
gah, same issue with the 1.20 tarball. The alternative is re-creating a new tarball and putting it somewhere on fdo.
The xz file is created by the gnome infrastructure :/ Maybe there was a glitch.
Just, checked - I actually upload the xz file. The gnome infra creates the 'old' file-types. And indeed the 141164 is the uid of my user account on the machine where I greated the file. Now according to http://www.gnu.org/software/tar/manual/html_section/Attributes.html tar would not restore the uid for normal users (only when run as root). Can you use -o on windows?
-o makes no difference
Will release a fixed 1.21 tonight.
This problem has happened again with gtk-doc-1.27.tar.xz
I do create them with TAR_OPTIONS="--owner=root --group=root" make distcheck now. I don't know what went wrong with the gtk-doc-1.27 release, but I don't see a way to fix those (except by doing a new release). Doing a 1.28 will still take a bit and I am not sure if I can re-upload the archive. If anyone knows a command to fix the archive, I could ask the ftp-admins to run that.
Updating existing tarballs is not a good idea IMHO. It's probably best to just make a new release. Is making a release much work or why will it take some time? Maybe a 1.27.1 bug-fix release could be made instead if that's easier?
I just released 1.28. But maybe it is time to figure why this is actually needed. I don't think anyone else is releasing with these TAR_OPTIONS.
I think the difference is just that everyone else is releasing on their own Linux machines with only a few users and hence low uid. You're doing it on a machine with a uid over 65535 that requires a 32-bit uid. It's possible to fix the archive just but repacking it in an account with a small enough uid. I did that and put it in https://gstreamer.freedesktop.org/data/src/mirror/ so our builds could carry on.