Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Alexey Tourbin]

On Mon, Oct 31, 2016 at 3:10 PM, Girar Builder pender robot
<girar-builder@altlinux.org> wrote:
> 2016-Oct-31 12:04:42 :: task #171635 for sisyphus resumed by imz:
> #200 build 0.1-alt6 from /people/imz/packages/python-module-repoze.who.plugins.beaker_tkt.git

> 2016-Oct-31 12:07:23 :: dependencies check OK
> 2016-Oct-31 12:07:24 :: ELF symbols check OK

То, что эта проверка отработала очень быстро, означает, что ни в
старом, ни в новом пакете нет ELF файлов. Почему тогда этот пакет не
noarch?

Надо какое-нибудь предупреждение выводить в этом месте. Даже не
обязательно со словом warning, а просто чтобы было понятно, что там
произошло.

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

Здравствуйте Alexey Tourbin
 В сообщении от 1 ноября 2016 вы написали:
> То, что эта проверка отработала очень быстро, означает, что ни
> в старом, ни в новом пакете нет ELF файлов. Почему тогда этот
> пакет не noarch?

А всегда-ли признаком noarch является наличие ELF файлов ? В 
рассылке мелькало, что приходилось отменять noarch, если 
результат построения каких-то файлов (например картинок (??), 
полученных при построении пакета не совпадает в разных 
архитектурах).

К сожалению ссылки сейчас на это сообщение не дам - искать надо.

-- 
  А ещё говорят так  (fortune): 
 
Кошка гуляющая сама по себе - кошка Мебиуса. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Alexey Tourbin]

2016-11-01 9:41 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
> Здравствуйте Alexey Tourbin
>  В сообщении от 1 ноября 2016 вы написали:
>> То, что эта проверка отработала очень быстро, означает, что ни
>> в старом, ни в новом пакете нет ELF файлов. Почему тогда этот
>> пакет не noarch?
>
> А всегда-ли признаком noarch является наличие ELF файлов ?

Не всегда. Но это один из главных признаков. Ну и это же питновский
модуль. Я его посмотрел, ничего архитектурно-зависимого там не
заметил. Если вписать ему "BuildArch: noarch", то он соберется как
noarch, с путями /usr/lib вместо /usr/lib64. Очень гуттаперчевая
конструкция, которая успешно выходит из-под проверки
gb-task-check-noarch, которая иначе бы подсказал, что пакет нужно
сделать noarch.

В общем, пока придумал сообщение "no ELF binaries":
https://github.com/svpv/perl-qa-rpmelfsym/commit/5e6a3b59

> В рассылке мелькало, что приходилось отменять noarch, если
> результат построения каких-то файлов (например картинок (??),
> полученных при построении пакета не совпадает в разных
> архитектурах).

Да, я помню историю, у mithraen получались картинки с разными
параметрами, и эти параметры попадали в вывод file(1). С одной
стороны, если картинки функционально эквивалентны, то можно было бы
ослабить требование к полному совпадению типов file(1). С другой
стороны, почему они получаются разными? Нет для этого достаточно
хорошей причины. Так что делайте так, чтобы получались одинаковыми.

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

Здравствуйте!

On Sat, 5 Nov 2016, Alexey Tourbin wrote:

> 2016-11-01 9:41 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
>> Здравствуйте Alexey Tourbin
>>  В сообщении от 1 ноября 2016 вы написали:
>>> То, что эта проверка отработала очень быстро, означает, что ни
>>> в старом, ни в новом пакете нет ELF файлов. Почему тогда этот
>>> пакет не noarch?
>>
>> А всегда-ли признаком noarch является наличие ELF файлов ?
>
> Не всегда. Но это один из главных признаков. Ну и это же питновский
> модуль. Я его посмотрел, ничего архитектурно-зависимого там не
> заметил. Если вписать ему "BuildArch: noarch", то он соберется как
> noarch, с путями /usr/lib вместо /usr/lib64. Очень гуттаперчевая

Не успел сразу ответить с релевантными ссылками.

Про эти питоновские пакеты таким вопросом, бывало, уже задавались люди. 
Есть подозрение, что это сделано из-за особенностей работы namespace 
packages в питоне, когда модуль TOPLEVEL.X должен лежать в файловой 
системе как-то так:

TOPLEVEL/__init__.py
TOPLEVEL/X.py

Для архитектурно-зависимого модуля Y внутри того же namespace TOPLEVEL

TOPLEVEL/Y.py

лежит внутри /usr/lib64/ . Это заставляет класть

TOPLEVEL/__init__.py

тоже внутри /usr/lib64/ и все

TOPLEVEL/X.py

без разбору тоже. Есть PEP, начиная с какого-то Python 3.N, который 
позволяет больше гибкости в организации подобных namespaces. Возможно, это 
можно будет упростить. С проявлением нерабочести из-за этого мы, кажется, 
сталкивались при переезде на новые пути site-packages при пересборке с 
помощью python3-3.3 -- из записок того времени:

python-module-zope.lifecycleevent[1] - OK, собрались после остававшихся 
семи python-module-zope (требовавших ABI, и, соответственно, пересборка 
которых была отложена до python3-3.5 ради экономии -- однократности 
пересборки)

python-module-zope.filerepresentation[2] - OK см. пред.

[1]: http://git.altlinux.org/tasks/archive/done/_156/160265/logs/events.8.1.log
[2]: http://git.altlinux.org/tasks/archive/done/_156/160265/logs/events.7.1.log

> конструкция, которая успешно выходит из-под проверки
> gb-task-check-noarch, которая иначе бы подсказал, что пакет нужно
> сделать noarch.
>
> В общем, пока придумал сообщение "no ELF binaries":
> https://github.com/svpv/perl-qa-rpmelfsym/commit/5e6a3b59


-- 
Best regards,
Ivan

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Alexey Tourbin]

2016-11-05 18:50 GMT+03:00 Ivan Zakharyaschev <imz@altlinux.org>:
> Здравствуйте!
>
> On Sat, 5 Nov 2016, Alexey Tourbin wrote:
>
>> 2016-11-01 9:41 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
>>>
>>> Здравствуйте Alexey Tourbin
>>>  В сообщении от 1 ноября 2016 вы написали:
>>>>
>>>> То, что эта проверка отработала очень быстро, означает, что ни
>>>> в старом, ни в новом пакете нет ELF файлов. Почему тогда этот
>>>> пакет не noarch?
>>>
>>> А всегда-ли признаком noarch является наличие ELF файлов ?
>>
>> Не всегда. Но это один из главных признаков. Ну и это же питновский
>> модуль. Я его посмотрел, ничего архитектурно-зависимого там не
>> заметил. Если вписать ему "BuildArch: noarch", то он соберется как
>> noarch, с путями /usr/lib вместо /usr/lib64. Очень гуттаперчевая
>
> Не успел сразу ответить с релевантными ссылками.
>
> Про эти питоновские пакеты таким вопросом, бывало, уже задавались люди. Есть
> подозрение, что это сделано из-за особенностей работы namespace packages в
> питоне, когда модуль TOPLEVEL.X должен лежать в файловой системе как-то так:
>
> TOPLEVEL/__init__.py
> TOPLEVEL/X.py

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

Мне все-таки не понятно, как может отработать "make check" в сборочном
каталоге, когда существование какого-то TOPLEVEL мыслится только
гипотетически.

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

Здравствуйте!

On Thu, 8 Dec 2016, Alexey Tourbin wrote:

>>> Не всегда. Но это один из главных признаков. Ну и это же питновский
>>> модуль. Я его посмотрел, ничего архитектурно-зависимого там не
>>> заметил. Если вписать ему "BuildArch: noarch", то он соберется как
>>> noarch, с путями /usr/lib вместо /usr/lib64. Очень гуттаперчевая
>>
>> Не успел сразу ответить с релевантными ссылками.
>>
>> Про эти питоновские пакеты таким вопросом, бывало, уже задавались люди. Есть
>> подозрение, что это сделано из-за особенностей работы namespace packages в
>> питоне, когда модуль TOPLEVEL.X должен лежать в файловой системе как-то так:
>>
>> TOPLEVEL/__init__.py
>> TOPLEVEL/X.py
>
> Мужчина, вы выражаетесь слишком обходительно, то есть к сожалению
> нельзя поставить вам в вину и упрекнуть вас в том, что именно вы всю
> эту глупость придумали.

Из того, как оно раскладывается по пакетам, я мало что придумал.

А причины/предположения о том, при каком размещении оно работать не смогло 
бы, я во многом придумал сначала, подтвердил увиденными примерами, которые 
могли бы быть последствием этих ограничений, и потом чтением кусочков 
около-документации.

> Мне все-таки не понятно, как может отработать "make check" в сборочном
> каталоге, когда существование какого-то TOPLEVEL мыслится только
> гипотетически.

Теперь мне непонятно, что из моего описания (предполагаемых) ограничений 
на размещение файлов, было Вам не очень понятно. Иначе я бы уточнил.

Попробую так. Варианты мест появления TOPLEVEL (например, repoze), которые 
могли встречаться:

/usr/lib/python3/site-packages/TOPLEVEL/
/usr/lib64/python3/site-packages/TOPLEVEL/
/usr/lib/python3.3/site-packages/TOPLEVEL/
/usr/lib64/python3.3/site-packages/TOPLEVEL/

Но чтобы работало, все файлы питоновских подпакетов TOPLEVEL (например, 
repoze.who, repoze.what, etc.) не могут размазываться между разными 
местами. Только одна директория реально должна была использоваться.

Не вижу каких-то особых проблем для make check.

-- 
Best regards,
Ivan

Re: [devel] [#171635] DONE (try 2) python-module-repoze.who.plugins.beaker_tkt.git=0.1-alt6

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Thu, 8 Dec 2016, Ivan Zakharyaschev wrote:

> Попробую так. Варианты мест появления TOPLEVEL (например, repoze), которые 
> могли встречаться:
>
> /usr/lib/python3/site-packages/TOPLEVEL/
> /usr/lib64/python3/site-packages/TOPLEVEL/
> /usr/lib/python3.3/site-packages/TOPLEVEL/
> /usr/lib64/python3.3/site-packages/TOPLEVEL/
>
> Но чтобы работало, все файлы питоновских подпакетов TOPLEVEL (например, 
> repoze.who, repoze.what, etc.) не могут размазываться между разными местами. 
> Только одна директория реально должна была использоваться.
>
> Не вижу каких-то особых проблем для make check.

Теперь сообразил. Ведь make check делается для собранного, а оно в своих 
buildroot-ах, а не в одном из этих системных мест.

В примере была ошибка в make check.

Грубо говоря, не заработали импортируемые во время make check другие 
питоновские "подпакеты" того же пакета, видимо, по причине того, что они 
были размазаны между двумя местами. А может быть, было ещё 
какое-то несоответствие этих путей, не могу быстро сказать без вникания в 
ту ситуацию опять.

-- 
Best regards,
Ivan