[devel] Q: python x86_64 (was: [#20176] FAILED srpm=postr-0.12.4-alt1.src.rpm)

[devel] Q: python x86_64 (was: [#20176] FAILED srpm=postr-0.12.4-alt1.src.rpm)

[Dmitry V. Levin]

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

Hi,

On Tue, Feb 16, 2010 at 04:12:45AM +0300, Girar Builder robot wrote:
> http://git.altlinux.org/tasks/20176/task/log
> 
> 2010-Feb-16 04:12:01 :: task #20176 for sisyphus started:
> #1 build postr-0.12.4-alt1.src.rpm
> 2010-Feb-16 04:12:02 :: [x86_64] postr-0.12.4-alt1.src.rpm: build start
> 2010-Feb-16 04:12:02 :: [i586] postr-0.12.4-alt1.src.rpm: build start
> 2010-Feb-16 04:12:35 :: [x86_64] postr-0.12.4-alt1.src.rpm: build OK
> 2010-Feb-16 04:12:45 :: [i586] postr-0.12.4-alt1.src.rpm: build OK
> --- postr-data-0.12.4-alt1.noarch.rpm.i586	2010-02-16 04:12:45 +0300
> +++ postr-data-0.12.4-alt1.noarch.rpm.x86_64	2010-02-16 04:12:45 +0300
> @@ -5,45 +5,30 @@
>  /usr/lib/python2.6/site-packages/postr/AboutDialog.pyc
> -/usr/lib/python2.6/site-packages/postr/AboutDialog.pyo

А куда девались *.pyo на x86_64?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: python x86_64 (was: [#20176] FAILED srpm=postr-0.12.4-alt1.src.rpm)

[Yuri N. Sedunov]

В Втр, 16/02/2010 в 04:27 +0300, Dmitry V. Levin пишет:
> Hi,
> 
> On Tue, Feb 16, 2010 at 04:12:45AM +0300, Girar Builder robot wrote:
> > http://git.altlinux.org/tasks/20176/task/log
> > 
> > 2010-Feb-16 04:12:01 :: task #20176 for sisyphus started:
> > #1 build postr-0.12.4-alt1.src.rpm
> > 2010-Feb-16 04:12:02 :: [x86_64] postr-0.12.4-alt1.src.rpm: build start
> > 2010-Feb-16 04:12:02 :: [i586] postr-0.12.4-alt1.src.rpm: build start
> > 2010-Feb-16 04:12:35 :: [x86_64] postr-0.12.4-alt1.src.rpm: build OK
> > 2010-Feb-16 04:12:45 :: [i586] postr-0.12.4-alt1.src.rpm: build OK
> > --- postr-data-0.12.4-alt1.noarch.rpm.i586	2010-02-16 04:12:45 +0300
> > +++ postr-data-0.12.4-alt1.noarch.rpm.x86_64	2010-02-16 04:12:45 +0300
> > @@ -5,45 +5,30 @@
> >  /usr/lib/python2.6/site-packages/postr/AboutDialog.pyc
> > -/usr/lib/python2.6/site-packages/postr/AboutDialog.pyo
> 
> А куда девались *.pyo на x86_64?


Загадочное явление. Пришлось добавить:
%add_python_compile_include %python_sitelibdir_noarch/postr


-- 
Yuri N. Sedunov

Re: [devel] Q: python x86_64

[Dmitry V. Levin]

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

On Tue, Feb 16, 2010 at 05:23:44AM +0300, Yuri N. Sedunov wrote:
> В Втр, 16/02/2010 в 04:27 +0300, Dmitry V. Levin пишет:
> > On Tue, Feb 16, 2010 at 04:12:45AM +0300, Girar Builder robot wrote:
> > > http://git.altlinux.org/tasks/20176/task/log
> > > 
> > > 2010-Feb-16 04:12:01 :: task #20176 for sisyphus started:
> > > #1 build postr-0.12.4-alt1.src.rpm
> > > 2010-Feb-16 04:12:02 :: [x86_64] postr-0.12.4-alt1.src.rpm: build start
> > > 2010-Feb-16 04:12:02 :: [i586] postr-0.12.4-alt1.src.rpm: build start
> > > 2010-Feb-16 04:12:35 :: [x86_64] postr-0.12.4-alt1.src.rpm: build OK
> > > 2010-Feb-16 04:12:45 :: [i586] postr-0.12.4-alt1.src.rpm: build OK
> > > --- postr-data-0.12.4-alt1.noarch.rpm.i586	2010-02-16 04:12:45 +0300
> > > +++ postr-data-0.12.4-alt1.noarch.rpm.x86_64	2010-02-16 04:12:45 +0300
> > > @@ -5,45 +5,30 @@
> > >  /usr/lib/python2.6/site-packages/postr/AboutDialog.pyc
> > > -/usr/lib/python2.6/site-packages/postr/AboutDialog.pyo
> > 
> > А куда девались *.pyo на x86_64?
> 
> Загадочное явление. Пришлось добавить:
> %add_python_compile_include %python_sitelibdir_noarch/postr

А, тогда всё понятно:

$ rpm --showrc |fgrep -w _python_compile_include
-14: _python_compile_include	%_target_libdir
-14: add_python_compile_include	%global _python_compile_include %_python_compile_include %*

т.е. оно обрабатывает только %_target_libdir, а содержимое
%_target_libdir_noarch (в случае когда оно отличается от %_target_libdir),
остаётся в стороне.

Стало быть, надо исправить дефолтное значение %_python_compile_include
таким образом, чтобы оно включало в себя %_target_libdir_noarch, если
%_target_libdir_noarch != %_target_libdir.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: python x86_64

[Евгений Ростовцев]

> $ rpm --showrc |fgrep -w _python_compile_include
> -14: _python_compile_include	%_target_libdir
> -14: add_python_compile_include	%global _python_compile_include
> %_python_compile_include %*
>
> т.е. оно обрабатывает только %_target_libdir, а содержимое
> %_target_libdir_noarch (в случае когда оно отличается от %_target_libdir),
> остаётся в стороне.
>
> Стало быть, надо исправить дефолтное значение %_python_compile_include
> таким образом, чтобы оно включало в себя %_target_libdir_noarch, если
> %_target_libdir_noarch != %_target_libdir.

Благодарю за объяснения. И, смотрю, Вы уже это реализовали в релизе
alt8. Респект.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: python x86_64

[Dmitry V. Levin]

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

On Tue, Feb 16, 2010 at 04:12:31PM +0700, Евгений Ростовцев wrote:
> > $ rpm --showrc |fgrep -w _python_compile_include
> > -14: _python_compile_include	%_target_libdir
> > -14: add_python_compile_include	%global _python_compile_include
> > %_python_compile_include %*
> >
> > т.е. оно обрабатывает только %_target_libdir, а содержимое
> > %_target_libdir_noarch (в случае когда оно отличается от %_target_libdir),
> > остаётся в стороне.
> >
> > Стало быть, надо исправить дефолтное значение %_python_compile_include
> > таким образом, чтобы оно включало в себя %_target_libdir_noarch, если
> > %_target_libdir_noarch != %_target_libdir.
> 
> Благодарю за объяснения. И, смотрю, Вы уже это реализовали в релизе
> alt8. Респект.

Нет, этого я ещё не реализовал.  Но постараюсь сегодня реализовать, если
никто не сделает этого раньше.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[devel] Q: python default byte-compilation paths list compilation

[Dmitry V. Levin]

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

On Tue, Feb 16, 2010 at 05:55:38PM +0300, Dmitry V. Levin wrote:
> > > $ rpm --showrc |fgrep -w _python_compile_include
> > > -14: _python_compile_include	%_target_libdir
> > > -14: add_python_compile_include	%global _python_compile_include
> > > %_python_compile_include %*
> > >
> > > т.е. оно обрабатывает только %_target_libdir, а содержимое
> > > %_target_libdir_noarch (в случае когда оно отличается от %_target_libdir),
> > > остаётся в стороне.
> > >
> > > Стало быть, надо исправить дефолтное значение %_python_compile_include
> > > таким образом, чтобы оно включало в себя %_target_libdir_noarch, если
> > > %_target_libdir_noarch != %_target_libdir.

Я посмотрел, где, помимо %_target_libdir/python%__python_version и
%_target_libdir_noarch/python%__python_version, у нас в Сизифе
встречаются модули для python, и обнаружил следующее:

- Некоторые модули находятся в экзотических местах, например:
/usr/include/wx-2.8/wx/wxPython/i_files/__init__.py
/usr/share/Tartarus/common/__init__.py
/usr/share/apps/kexi/kross/python/kexiapp/__init__.py
/usr/share/chestnut-dialer/chestnut_dialer/__init__.py
/usr/share/connexion/bus/__init__.py
/usr/share/decibel-audio-player/src/gui/__init__.py
Мне не очевидно, стоит ли автоматически запускаемый
/usr/lib/rpm/python.compileall.py распространять на них (сейчас этого
не происходит).

- Некоторые модули находятся в не менее экзотических местах, например:
/usr/lib/Tartarus/modules/Time/__init__.py
/usr/lib/bakefile/empy/__init__.py
/usr/lib/blender/scripts/bpymodules/colladaImEx/__init__.py
/usr/lib/calibre/calibre/__init__.py
/usr/lib/exaile/xl/__init__.py
/usr/lib/gdesklets/main/__init__.py
/usr/lib/gedit-2/plugins/devhelp/__init__.py
/usr/lib/gnue/__init__.py
/usr/lib/gwyddion/python/Gwyddion/__init__.py
/usr/lib/listen/parse/__init__.py
Мне не очевидно, стоит ли автоматически запускаемый
/usr/lib/rpm/python.compileall.py распространять на них (сейчас это
происходит)

Наконец, мне кажется нелогичным тот факт, что сейчас к
/usr/share/Tartarus/common/__init__.py и
/usr/lib/Tartarus/modules/Time/__init__.py применяются разные умолчания.

Даже если мы когда-нибудь передумаем, и byte-compilation переедет в
post-transaction filetrigger, то этот вопрос всё равно никуда не денется.

Просьба высказывать аргументированные точки зрения на
python default byte-compilation paths list.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: python default byte-compilation paths list compilation

[Евгений Ростовцев]

Привет!

> Я посмотрел, где, помимо %_target_libdir/python%__python_version и
> %_target_libdir_noarch/python%__python_version, у нас в Сизифе
> встречаются модули для python, и обнаружил следующее:

Таких мест много, а разве %add_python_lib_path действует только во
время сборки? Если нет, может быть, имеет смысл завести аналогичных
макрос для рантайма, чтобы отучить юзеров и мейнтейнеров устанавливать
PYTHONPATH? Ведь нестандартные места для питоньих модулей вполне
оправданы: например, у меня есть ряд пакетов, собираемых для
действительных и комплексных чисел (это из-за различного набора фич
PETSc для обоих случаях). Поэтому мне вручную (т.е. скриптом)
приходится обновлять PYTHONPATH (либо %_libexecdir/petsc-real/python,
либо %_libexecdir/petsc-complex/python). Но мой случае - от него
никуда не деться, это ведь переключение контекста, там и
LD_LIBRARY_PATH ещё задействован, и PATH, к примеру.

А вот для единичных реализаций даже не знаю (про это ниже).

> - Некоторые модули находятся в экзотических местах, например:
> /usr/include/wx-2.8/wx/wxPython/i_files/__init__.py
> /usr/share/Tartarus/common/__init__.py
> /usr/share/apps/kexi/kross/python/kexiapp/__init__.py
> /usr/share/chestnut-dialer/chestnut_dialer/__init__.py
> /usr/share/connexion/bus/__init__.py
> /usr/share/decibel-audio-player/src/gui/__init__.py
> Мне не очевидно, стоит ли автоматически запускаемый
> /usr/lib/rpm/python.compileall.py распространять на них (сейчас этого
> не происходит).

Думаю, не стоит. Думаю, лучше мейнтейнерам создавать символические
ссылки внутрь %python_sitelibdir.

> /usr/lib/listen/parse/__init__.py
> Мне не очевидно, стоит ли автоматически запускаемый
> /usr/lib/rpm/python.compileall.py распространять на них (сейчас это
> происходит)

См. мой абзац выше. Давайте всё же окультурим питон и будем его модули
располазать в стандартном месте (нестандартную ситуацию с PETSc я
описал, вот здесь нужно /usr/lib/rpm/python.compileall.py
задействовать обязательно, но только если сам мейнтейнер об этом в
спеке попросит (ещё один макрос?).

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: python default byte-compilation paths list compilation

[Andrey Rahmatullin]

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

On Wed, Feb 17, 2010 at 01:59:15PM +0700, Евгений Ростовцев wrote:
> Таких мест много, а разве %add_python_lib_path действует только во
> время сборки?
+1

> > - Некоторые модули находятся в экзотических местах, например:
> > /usr/include/wx-2.8/wx/wxPython/i_files/__init__.py
> > /usr/share/Tartarus/common/__init__.py
> > /usr/share/apps/kexi/kross/python/kexiapp/__init__.py
> > /usr/share/chestnut-dialer/chestnut_dialer/__init__.py
> > /usr/share/connexion/bus/__init__.py
> > /usr/share/decibel-audio-player/src/gui/__init__.py
> > Мне не очевидно, стоит ли автоматически запускаемый
> > /usr/lib/rpm/python.compileall.py распространять на них (сейчас этого
> > не происходит).
> Думаю, не стоит. Думаю, лучше мейнтейнерам создавать символические
> ссылки внутрь %python_sitelibdir.
Зачем, если и без них всё работает? Только для байт-компиляции?

> См. мой абзац выше. Давайте всё же окультурим питон и будем его модули
> располазать в стандартном месте
Ужасно.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

на самом деле, все равно это не может рассматриваться как средство защиты и
соответственно его обхода не было (а если агент не поддерживает robot
exclusion standart? в протоколе http robots.txt не описан :-)

вот когда baida.ru отдает wget'у 403, и я делаю wget -u Mozilla - это
"взлом" для dmca. потому что server side ограничение.
		-- gns in smoke-room@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] Q: python default byte-compilation paths list

[Dmitry V. Levin]

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

On Wed, Feb 17, 2010 at 01:59:15PM +0700, Евгений Ростовцев wrote:
> > Я посмотрел, где, помимо %_target_libdir/python%__python_version и
> > %_target_libdir_noarch/python%__python_version, у нас в Сизифе
> > встречаются модули для python, и обнаружил следующее:
> 
> Таких мест много, а разве %add_python_lib_path действует только во
> время сборки?

В пакет он, по крайней мере, не зашивается.  Но использовать
%_python_lib_path ещё и для для байт-компиляции -- эта идея
кажется мне правильной.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: python default byte-compilation paths list compilation

[Dmitry V. Levin]

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

On Wed, Feb 17, 2010 at 12:18:12PM +0500, Andrey Rahmatullin wrote:
> On Wed, Feb 17, 2010 at 01:59:15PM +0700, Евгений Ростовцев wrote:
> > Таких мест много, а разве %add_python_lib_path действует только во
> > время сборки?
> +1

По крайней мере, в собранный пакет значение %_python_lib_path не
зашивается.

[...]
> > См. мой абзац выше. Давайте всё же окультурим питон и будем его модули
> > располазать в стандартном месте
> Ужасно.
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs

Я только не понимаю, как мейнтейнер в Debian следит за тем, чтобы, как
написано у них в правилах, "the byte-compiled modules [...] should be
generated in the package's postinst [...] and removed in the prerm"?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: python default byte-compilation paths list compilation

[Andrey Rahmatullin]

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

On Wed, Feb 17, 2010 at 05:01:21PM +0300, Dmitry V. Levin wrote:
> > > См. мой абзац выше. Давайте всё же окультурим питон и будем его модули
> > > располазать в стандартном месте
> > Ужасно.
> > http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
> Я только не понимаю, как мейнтейнер в Debian следит за тем, чтобы, как
> написано у них в правилах, "the byte-compiled modules [...] should be
> generated in the package's postinst [...] and removed in the prerm"?

python-support || python-central

dh_pysupport(1):
OPTIONS
       module dirs
           If your package installs private python modules in non-standard
directories, you can make dh_pysupport check those directories by passing their
names on the command line. By default, it will check /usr/lib/$PACKAGE,
/usr/share/$PACKAGE, /usr/lib/games/$PACKAGE and /usr/share/games/$PACKAGE

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

 * swi вот почетный боянист и не смущается сим фактом прискорбным

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]