search

msys2 / MSYS2-packages

Package scripts for MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
1.29k stars 487 forks source link

makepkg: bsdtar: .PKGINFO: archive_write_pax_header: 'x' header failed?! #90

Open ladserg opened 9 years ago

ladserg commented 9 years ago

при сборке пакета при помощи makepkg вылазит ошибка, и не собираются пакеты:

  -> Создание файла .MTREE...
  -> Архивируется пакет...
bsdtar: .PKGINFO: archive_write_pax_header: 'x' header failed?!  This can't happen.

==> ОШИБКА: Не удалось создать файл пакета.
Alexpux commented 9 years ago

Видел такое пару раз. Насколько помню это случается когда имя пользователя в системе содержит символы не из латиницы. Создай пользователя с именем на английском и им собирай

Alexpux commented 9 years ago

Да и кстати зачем плодить одно и тоже тут и на форуме sources.ru?

ladserg commented 9 years ago

Не, у меня имя пользователя такое же как тут, на форуме не отвечает никто. Да и вроде тут как бы по теме, ветка на форуме к MSYS2 (судя по её названию) отношения не имеет.

Мож у меня нехватет чего, MSYS2 поставлен из архива снапшота 20141003, обновлен, установлены пакеты git wget xz bzip2 p7zip autoconf automake libtool make svn tar patch cvs bison pkg-config, mingw-w64-x86_64-toolchain, mingw-w64-i686-toolchain и всё. В батники запуска добавлена строка:

set PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0;%systemroot%\idmu\common

Что бы не конфликтовало с другими библиотеками.

Alexpux commented 9 years ago

Еще вспомнил что такое может быть если ты залогинен в винде под сетевой учетной записью. Например, под доменной учеткой.

ladserg commented 9 years ago

хм, это есть, у меня корпоративка, без этого никак. Это не обойти?

ladserg commented 9 years ago

правда 

set | grep ladserg

вроде никакого криминала не выдает :-/

Alexpux commented 9 years ago

Я не знаю как корпоративку обойти пока. Создавай локального пользователя и логинься под ним. Полагаю что проблема в разрешениях для пользователя, но я на работе тоже не смог победить.

ladserg commented 9 years ago

Хм, действительно, работать под локальной учеткой не вариант, придется искать другой вариант.

Примерно есть предположение в чём может быть проблема?

Alexpux commented 9 years ago

Нет. Нужно strace'ом покопаться

ladserg commented 9 years ago

проблема похоже в bsdtar, т.к. команда вида:

bsdtar cf dddd.tar PKG/mingw-w64-x86_64-gmp

Уже выдаёт такие матюки:

bsdtar: PKG/mingw-w64-x86_64-gmp/: archive_write_pax_header: 'x' header failed?!  This can't happen.

буду копать дальше, чего он корпоративку так не любит.

Кста, обычный tar себя так не ведёт.

Alexpux commented 9 years ago

Скорее не сам bsdtar а libarchive я думаю

ladserg commented 9 years ago

А tar не использует libarchive? Сама по себе ошибка вызывается из libarchive похоже, просто я не могу понять в чём разница для libarchive/bsdtar между локальным и доменным пользователи. Окружение переменных я уже делал одинаковым, оба пользователя - локальные администраторы, даже имя одинаковое.

Alexpux commented 9 years ago

Тут скорее всего завязаны cygwin/msys права, которые эмулируются. Будет время посмотрю. Попробуй сделать strace лог (под msys2_shell.bat) strace -o strace.log bsdtar cf dddd.tar PKG/mingw-w64-x86_64-gmp

ladserg commented 9 years ago

уже сделал, под обоими пользователями, сижу сравниваю, хотя не могу сказать что особо понимаю что там, специализация чуток иная.

ladserg commented 9 years ago

Да, похоже проблемы где то внутри, за пределами libarchive, т.к. я сейчас взял bsdtar скомпиленный статически тулчайном, с ним нет такой ошибки. Закинул его вместо штатнного MSYS'овского, пакет собрался нормально.

Хм, если есть такая проблема, то она можети в других местах неожиданно себя показать :-/

Alexpux commented 9 years ago

Ты просто решил воспользоваться mingw версией bstar, но тут тоже могут быть сложности) MSYS версия нативно работает с msys2-runtime в то время как mingw через различные процедуры конвертации)

ladserg commented 9 years ago

в данном случае bsdtar от MSYS2 не работает в нужных условиях.

ladserg commented 9 years ago

Чуток не по теме, в mingw-builds есть патч gcc-4.8.2-fix-for-windows-not-minding-non-existant-parent-dirs.patch для gcc, и в пакете mingw-w64-gcc есть патч 140-fix-for-windows-not-minding-non-existent-parent-dirs.patch, но они почему то отличаются на два символа:

Сравнение файлов C:\1\MSYS64\HOME\LADSERG\MINGW-BUILDS-DEVELOP\PATCHES\GCC\1\140-fix-for-windows-not-minding-non-existent-parent-dirs.patch и GCC-4.8.2-FIX-FOR-WINDOWS-NOT-MINDING-NON-EXISTANT-PARENT-DIRS.PATCH
***** C:\1\MSYS64\HOME\LADSERG\MINGW-BUILDS-DEVELOP\PATCHES\GCC\1\140-fix-for-windows-not-minding-non-existent-parent-dirs.patch
+               }
+             *dirsep++ = dirsepc;
+           }
***** GCC-4.8.2-FIX-FOR-WINDOWS-NOT-MINDING-NON-EXISTANT-PARENT-DIRS.PATCH
+               }
+             *dirsep = dirsepc;
+           }
*****

У кого два плюса лишние? :-)

Alexpux commented 9 years ago

Все последние патчи в mingw-packages. Я периодически делаю бэкпорт в mingw-builds когда есть время

ladserg commented 9 years ago

Хм, понял, думаю прикрутить патчи из mingw-packages к mingw-builds.

mingwandroid commented 9 years ago

Вы * определенно * нужен ++ там.

ladserg commented 9 years ago

надо niXman'а попросить присмотреться к этому патчу, если плюсы там нужны, то неправильный патч может создавать какие нибудь мелкие проблемы. Возможно именно поэтому у меня в некоторых программах пропадали разделители директорий и получалось нечто вроде такого:

C:1msys64homeladsergmingw-builds-developpatchesgcc1

Вместо:

C:\1\msys64\home\ladserg\mingw-builds-develop\patches\gcc\1\

:-)

Alexpux commented 9 years ago

Тебе уже сказали что плюсы нужны) Этот патч написал @mingwandroid - он лучше знает что нужно.

mingwandroid commented 9 years ago

Там вы страдаете от побега из '\', который является общность побег в C строк, конечно. Вы должны использовать Трассирование или что-то, чтобы обнаружить, какая программа лечения вашего '\' как экранирующий символ, либо удвоить их как '\' для обеспечения пост-бежал версию является '\'. Там нет необходимости просить niXman, он не писал этот патч и он не записывается фиксированное ++ версию патча, я сделал! Во всяком случае, этот код очень специфичен для поиска заголовка (#include) GCC и выполняется только в следующей случае: 1 включают каталог имеет ".." в нем. 2 Родительский каталог не существует. Я только видел эти условия, когда кросс-компиляции Glibc для Linux мишень с хозяином Windows.

ladserg commented 9 years ago

@Alexpux дык это я и сказал :-) Просто в mingw-build патч без плюсов, надо поправить, это вроде вотчина niXmana, к нему обращаться что бы плюсы добавил в официальную сборку?

Alexpux commented 9 years ago

можешь его спросить или я на днях сам добавлю

ladserg commented 9 years ago

@mingwandroid спасибо за разьяснения

@Alexpux если есть возможность добавь, кста у тебя binutils при помощи gcc 4.9.1 нормально собирается?

Alexpux commented 9 years ago

@ladserg, давно не собирал - нужно глянуть, но раньше проблем не было

ladserg commented 9 years ago

@Alexpux если один раз собирал при помощи gcc 4.9.1, то проблем не должно быть, непатченный binutils, просто, сходу не собирается при помощи gcc 4.9.1, пока либо не повыкидываешь все флаги -Wall и -Werror, либо не изменишь код, чьи варнинги для gcc 4.9.1 становились стоп-ошибками.

Alexpux commented 9 years ago

Вечером проверю

ladserg commented 9 years ago

Появилась дополнительная информация, если у пользователя домена по умолчанию назначена встроенная группа домена, например "Пользователи домена", "Администраторы домена", "Администраторы предприятия" и т.д., то ошибка проявляется, если назначить пользователю домена по умолчанию созданную руками группу, то ошибка не проявляется.

Может это поможет чем?

ladserg commented 9 years ago

UPD: Похоже ошибка проявляется если у пользователя домена назначена по умолчанию група с названием "Пользователи чего-то" или "Администраторы чего-то", даже если они созданы руками.

DJm00n commented 9 years ago

@ladserg, столкнулся с этой же проблемой на рабочем компе. Получилось побороть?

Alexpux commented 9 years ago

у меня такая проблема когда работаю из под доменной учетки. Захожу с локальной.

DJm00n commented 9 years ago

Вдруг кому нужно будет. Костыль по совету @Alexpux: Сделал себе временного юзера User и под доменной учеткой запустил msys2 shell под новым пользователем:

runas /user:User "C:\Windows\System32\cmd.exe /A /Q /K C:\msys64\msys2_shell.bat"

Теперь makepkg-mingw собирает пакеты номально.

Alexpux commented 4 years ago

Problem with bsdtar under Active Directory account is related to the fact that Group ID (GID) being too long (user GID in Active Directory is 32 bits long).

Alexpux commented 4 years ago

as workaround UID/GID can be overrided by adding, for example, --gid 10000 --uid 10000 to bsdtar cmd

sskras commented 1 year ago

@Alexpux commented on Jan 14, 2020:

Problem with bsdtar under Active Directory account is related to the fact that Group ID (GID) being too long (user GID in Active Directory is 32 bits long).

Is this an issue on Cygwin too?

Strangely enough, it's 32-bit long on Linux too: https://stackoverflow.com/questions/1922761/size-of-pid-t-uid-t-gid-t-on-linux/1922892#1922892

On an i686 and x86_64 (so, 32-bit and 64-bit) processor running Linux >= 3.0.0, the answer is:

pid_t: 4
uid_t: 4
gid_t: 4

[...] On intel architectures, sizes are defined in /usr/include/bits/typesizes.h:

define UID_T_TYPE U32_TYPE

define GID_T_TYPE U32_TYPE

define PID_T_TYPE S32_TYPE

In other words, uid_t and gid_t are unsigned 32-bit integers and pid_t is a signed 32-bit integer. This applies for both 32- and 64-bits.

Have you found the code path where the GID from Active Directory gets truncated?