libhocr installed noarch python files into /usr/lib/python2.7 and arch-dependent file as /usr/lib64/python2.7/site-packages/_hocr.so there is nothing wrong for python module having both arch-independent and arch dependent parts, so sisyphus_check should not complain. $ find /usr/src/tmp/libhocr-buildroot/usr/lib*/py* /usr/src/tmp/libhocr-buildroot/usr/lib/python2.7 /usr/src/tmp/libhocr-buildroot/usr/lib/python2.7/site-packages /usr/src/tmp/libhocr-buildroot/usr/lib/python2.7/site-packages/hocr.pyo /usr/src/tmp/libhocr-buildroot/usr/lib/python2.7/site-packages/hocr.pyc /usr/src/tmp/libhocr-buildroot/usr/lib/python2.7/site-packages/hocr.py /usr/src/tmp/libhocr-buildroot/usr/lib64/python2.7 /usr/src/tmp/libhocr-buildroot/usr/lib64/python2.7/site-packages /usr/src/tmp/libhocr-buildroot/usr/lib64/python2.7/site-packages/_hocr.so /.out/python-module-libhocr-0.10.17-alt1_9.x86_64.rpm: invalid x86_64 python module path: /usr/lib/python2.7/site-packages/hocr.py /usr/lib/python2.7/site-packages/hocr.pyc /usr/lib/python2.7/site-packages/hocr.pyo sisyphus_check: check-python ERROR: python modules packaging violation hsh-rebuild: libhocr-0.10.17-alt1_9.src.rpm: sisyphus_check failed. hsh.log lines 1286-1303/1303 (END)
У меня были такие пакеты, заталкивание файлов *.py* в /usr/lib64/... решает проблему.
(В ответ на комментарий №1) > У меня были такие пакеты, заталкивание файлов *.py* в /usr/lib64/... решает > проблему. это руками нужно делать, а хочется пакет собирать роботом :( вопрос в том, что проблема искусственная, и создана некорректной реализацией самой указанной проверки. Ведь файлы установлены корректно, это же не .so в /usr/lib.
Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов, помещенных туда по ошибке вместо /usr/lib64/python2.7/ ?
"Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов, помещенных туда по ошибке вместо /usr/lib64/python2.7/ ?" Мне тоже в голову ничего не идёт. На глаз можно, а вот робот вряд ли справится.
по расширению. *.py, *.pyo, *.pyc, легальные, все остальное -- нелегально
Разве *.pyo легален уже? :)
(В ответ на комментарий №5) > по расширению. *.py, *.pyo, *.pyc, легальные, > все остальное -- нелегально или, вместо исключения на noarch files, добавить правило на отсутствие blobs `file` !~ / ELF /: в крайнем случае правило на рсширение. почти все блобы - *.so, но в rpmquery -l -p python-module-* попался /usr/lib64/python2.7/site-packages/Ft/Lib/DistExt/stubmain.exe
(В ответ на комментарий №6) > Разве *.pyo легален уже? :) Чесно говоря, не знаю, не понимаю. Немного офтопик, про *.pyo, но хотелось бы разобраться. я хочу научить робота корректно конвертировать python-* модули, но наше текущее python policy непонятно где и какое.
Похоже, до сих пор никому это полиси так и не понадобилось сильно, что до сих пор его и не существует ;)
(В ответ на комментарий №8) > > Разве *.pyo легален уже? :) > Чесно говоря, не знаю, не понимаю. > Немного офтопик, про *.pyo, но хотелось бы разобраться. > я хочу научить робота корректно конвертировать python-* модули, > но наше текущее python policy непонятно где и какое. т.е. приложение установило *.py файл. 1) надо ли этот файл компилировать на стадии install? 2) если надо, то кто это делает штатно? 3) что из откомпилированного упаковывать?
думаю, что тема с *.pyo/*.pyc несколько офтопик в этом баге, стоит наверное в devel@ перенести. (В ответ на комментарий №9) > Похоже, до сих пор никому это полиси так и не понадобилось сильно, что до сих > пор его и не существует ;) вот народ вроде меня и пакует что попало, как попало, где попало, потому что нет полиси, которое его бы просвещало. например, я бы с удовольствием узнал бы, какими граблями чревата упаковка *.pyc.
(В ответ на комментарий №10) > т.е. приложение установило *.py файл. > 1) надо ли этот файл компилировать на стадии install? > 2) если надо, то кто это делает штатно? > 3) что из откомпилированного упаковывать? на самом деле, очень полезно было бы обсудить, понять и решить. те же *.pyc файлы. если с ними грабли -- надо их удалять принудительно еще на стадии %install в brp-fix=python.
"вот народ вроде меня и пакует что попало, как попало, где попало, потому что нет полиси" Ну есть драфт, лично я им руководствуюсь. Писал не я, и там многое, наверно, уже поменять надо. Вот кто бы взялся за это... PS. *.pyc ничем не чревато, в отличие от *.pyo (хотя я не на 100% уверен, что это так, глядя на python-module-pexpect).
"т.е. приложение установило *.py файл. 1) надо ли этот файл компилировать на стадии install?" Не надо, оно само после verify-elf компилируется.
(В ответ на комментарий №3) > Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов, > помещенных туда по ошибке вместо /usr/lib64/python2.7/ ? можно ослабить проверку до `file $1` not match ' ELF '
(В ответ на комментарий №14) > "т.е. приложение установило *.py файл. > 1) надо ли этот файл компилировать на стадии install?" > Не надо, оно само после verify-elf компилируется. спасибо, дальше разбираемся, надо ли паковать 1) *.pyo файлы 2) *.pyс файлы ?
В случае noarch *.pyo можно не паковать, для верности. Но лучше пусть выскажутся более просвещённые.
(В ответ на комментарий №17) > В случае noarch *.pyo можно не паковать, для верности. Но лучше пусть > выскажутся более просвещённые. надо бы понять и разобраться - там много тонкостей. я вот интересные грабли вытоптал. когда-то я в hplip паковал только *.py файлы. а некоторые пользователи в каких-то ситуациях пускали hplip-tools от рута. при этом от рута создавали *.py[oc] файлы. Потом обновлялись и у них ничего не работало. стал паковать все, чтобы такого не повторилось.
по поводу *.pyc / *.pyo и python-policy это отдельная тема, не связанная напрямую с данным багом. Данный баг о том, что sisyphus_check превышает свои полномочия, запрещая вместе с патологическими случаями и вполне разумную политику упаковки. Более того, эта же проблема вылезла и в libsmbios, и как оказалось, этот пакет родом из SuSE Build Factory. т.е. указанная схема упаковки (с раздельными noarch и arch частями) - это не выдумки федоры, а распространенная дистрибутивная практика. предлагаю ослабить проверку до проверки на отсутствие blobs, т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /. Дмитрий, если дадите добро, готов подготовить патч.
(In reply to comment #19) > предлагаю ослабить проверку до проверки на отсутствие blobs, > т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /. как вы себе представляете применение file(1) в sisyphus_check?
2viy: PYTHONDONTWRITEBYTECODE=yes ?
(В ответ на комментарий №20) > (In reply to comment #19) > > предлагаю ослабить проверку до проверки на отсутствие blobs, > > т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /. > как вы себе представляете применение file(1) в sisyphus_check? Да, стормозил. Перепутал с repocop :) тогда по расширениям -- разрешить *.py *.pyo *.pyc файлы
(В ответ на комментарий №21) > 2viy: PYTHONDONTWRITEBYTECODE=yes ? Спасибо! буду знать. Вообще хорошо бы обновить полиси по питону... пока руки не доходят сесть и разобраться. не так часто с питоном сталкиваюсь.
(In reply to comment #22) > (В ответ на комментарий №20) > > (In reply to comment #19) > > > предлагаю ослабить проверку до проверки на отсутствие blobs, > > > т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /. > > как вы себе представляете применение file(1) в sisyphus_check? > > Да, стормозил. Перепутал с repocop :) > тогда по расширениям -- разрешить *.py *.pyo *.pyc файлы Хорошо. Просьба каким-нибудь образом передать мне исходный код какого-нибудь пакета, на котором это изменение можно было бы проверить.
Created attachment 5268 [details] python-module-libhocr
Created attachment 5269 [details] python-module-libsmbios прикладываю src.rpm пакеты
sisyphus_check-0.8.29-alt1 -> sisyphus: * Tue Dec 20 2011 Dmitry V. Levin <ldv@altlinux> 0.8.29-alt1 - 220-check-python: allow packaging of *.py* files in the arch-independent site-packages directory on x86-64 (closes: #26728).
(In reply to comment #25) > Created an attachment (id=5268) [details] > python-module-libhocr Должен признать, что с целью тестирования я был вынужден увидеть этот libhocr.spec, и он пробудил во мне самые отвратительные чувства.
(В ответ на комментарий №28) Спасибо! > Должен признать, что с целью тестирования я был вынужден увидеть этот > libhocr.spec, и он пробудил во мне самые отвратительные чувства. я в devel@ поднял эту тему.
еще в сборочнице надо обновить: http://git.altlinux.org/tasks/60714/logs/events.1.1.log 2011-Dec-21 00:06:17 :: [x86_64] #100 libhocr-0.10.17-alt1_9.src.rpm: build OK x86_64/rpms/python-module-libhocr-0.10.17-alt1_9.x86_64.rpm: invalid x86_64 python module path: /usr/lib/python2.7/site-packages/hocr.py /usr/lib/python2.7/site-packages/hocr.pyc /usr/lib/python2.7/site-packages/hocr.pyo sisyphus_check: check-python ERROR: python modules packaging violation 2011-Dec-21 00:06:21 :: #100: libhocr-0.10.17-alt1_9.src.rpm: sisyphus_check FAILED
Обновил.
