[devel] [git update] packages/python: heads/master

[devel] [git update] packages/python: heads/master

[Alexey M. Tourbin]

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

Впрочем, хорошо, что специалист по питону есть.  Жаль лишь, что... как
там в Библии...  может быть, он задумался, или занят чем-либо, или в
дороге, а может быть, и спит, так он проснется!

Питон распилен плохо.

Во-первых, пакет python-base нельзя установить "просто так", поскольку
он вытягивает python-strict (или python-relaxed).  Имеет место быть
круговая порука python-base <=> python-strict.

Во-вторых, python-base слишком тощий.  Он не обеспечивает "самого
основного", так что его сущность не вполне совершенна.  По поводу
самого основного см. ниже commit message.

python-strict в свою очередь слишком жирный.

Я уже переместил /usr/bin/python из python-strict в python-base,
стараясь при этом не разламывать many-world интерпретации Андрея Орлова.

В-третьих, в python-base находится /usr/bin/pydoc, а pydoc по
зависимостям вытягивает модуль pydoc.py, который в свою очередь
вытягивает некоторые интроспективные/компиляторные модули, т.к.
ему нужно смотреть в docstring.  Сейчас зависимости в /usr/bin/pydoc
просто не ищутся, но если эту лавочку прикрыть, а мы ее прикроем,
тогда, по сути, придется решать, сделать ли более толстым python-base,
или же запаковать pydoc куда-нибудь отдельно.

Кроме того, некоторые интроспективные/компиляторные модули нужны для
rpm-build-python, и они тоже должны (желательно) находится в
python-base.  В общем, соображения на этот счет мне интересны.

План такой.

1) Я перетасую python, с учетом всех предложений, если таковые поступят.
Потом кто-нибудь должен проверить и отправим на сборку.

2) Потом нужно доделать/пересобрать rpm-build-python с зависимостью на
новый python-base.  Это даст заведомой рабочий rpm-build-python +
python-base в базовой сборочной среде.

3) Дальше я вернусь к rpm-build.


Update of /people/at/packages/python.git

Changes statistics since `2.4.4-alt2-14-g1f6bae6' follows:
 modules-list/base-list                      |    4 ++++
 modules-list/modules/base-list              |   11 -----------
 modules-list/modules/modules-bsddb-list     |    1 -
 modules-list/modules/modules-cgi-list       |    2 --
 modules-list/modules/modules-cmd-list       |    1 -
 modules-list/modules/modules-codecs-list    |    4 ----
 modules-list/modules/modules-compiler-list  |   13 -------------
 modules-list/modules/modules-compress-list  |    4 ----
 modules-list/modules/modules-control-list   |    6 ------
 modules-list/modules/modules-crypt-list     |    3 ---
 modules-list/modules/modules-curses-list    |    1 -
 modules-list/modules/modules-data-list      |    4 ----
 modules-list/modules/modules-dbm-list       |    5 -----
 modules-list/modules/modules-dev-list       |    3 ---
 modules-list/modules/modules-devel-list     |   12 ------------
 modules-list/modules/modules-email-list     |    9 ---------
 modules-list/modules/modules-execute-list   |    3 ---
 modules-list/modules/modules-file-list      |    8 --------
 modules-list/modules/modules-hotshot-list   |    1 -
 modules-list/modules/modules-html-list      |    6 ------
 modules-list/modules/modules-http-list      |   11 -----------
 modules-list/modules/modules-img-list       |    1 -
 modules-list/modules/modules-import-list    |    3 ---
 modules-list/modules/modules-io-list        |    1 -
 modules-list/modules/modules-mac-list       |    2 --
 modules-list/modules/modules-marshal-list   |    2 --
 modules-list/modules/modules-modules-list   |    3 ---
 modules-list/modules/modules-mswin-list     |    2 --
 modules-list/modules/modules-net-list       |   13 -------------
 modules-list/modules/modules-random-list    |    2 --
 modules-list/modules/modules-sound-list     |    8 --------
 modules-list/modules/modules-sre-list       |    4 ----
 modules-list/modules/modules-string-list    |    1 -
 modules-list/modules/modules-user-list      |    3 ---
 modules-list/modules/modules-xmlrpc-list    |    4 ----
 35 files changed, 4 insertions(+), 157 deletions(-)

Changelog since `2.4.4-alt2-14-g1f6bae6' follows:
commit b6244b3fdda2c1ef0107648242c3b7c69453622f
Author: Alexey Tourbin <at@altlinux.ru>
Date:   Thu Mar 15 08:16:40 2007 +0300

    modules-list/base-list: also added time.so
    
    Now python-base provides all most wanted python modules.
    
    $ apt-cache dump |tr ' ' '\n' |fgrep python2.4 |sort |uniq -c |sort -n |tail
         62 python2.4(math)
         65 python2.4(traceback)
         67 python2.4(cStringIO)
         67 python2.4(copy)
         77 libpython2.4.so.1.0
        137 python2.4(types)
        144 python2.4(time)
        161 python2.4(string)
        166 python2.4(re)
        233 python2.4(os)
    $

commit 53c505b10465b21d74e5dcca2fe92d25a2c024a3
Author: Alexey Tourbin <at@altlinux.ru>
Date:   Thu Mar 15 07:21:50 2007 +0300

    modules-list/base-list: added string and re (+ sre* for re)

commit 14ccd1867e6a082a4a99482570f023183d8558a2
Author: Alexey Tourbin <at@altlinux.ru>
Date:   Thu Mar 15 07:06:43 2007 +0300

    removed modules-list/modules/, as it seems to be duplicated and unused

Full diff since `2.4.4-alt2-14-g1f6bae6' follows:
diff --git a/modules-list/base-list b/modules-list/base-list
index 7b64bb1..9d189c8 100644
--- a/modules-list/base-list
+++ b/modules-list/base-list
@@ -2,11 +2,15 @@ UserDict.py
 codecs.py
 copy_reg.py
 lib-dynload/readline.so
+lib-dynload/time.so
 linecache.py
 os.py
 posixpath.py
+re.py
+sre*.py
 site.py
 stat.py
+string.py
 types.py
 warnings.py
 __future__.py

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

Re: [devel] [git update] packages/python: heads/master

[Alexey I. Froloff]

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

* Alexey M. Tourbin <at@> [070315 08:57]:
> Во-вторых, python-base слишком тощий.  Он не обеспечивает "самого
> основного", так что его сущность не вполне совершенна.  По поводу
> самого основного см. ниже commit message.
Самое основное, что должно входить в python-base, это (filereq
зацепил пару левых каталогов):

$ filereq /dev/stdout python -c 1 | fgrep python2.4 | grep -v \\.pyc\$
/usr/lib/libpython2.4.so.1.0                                     
/usr/lib/python2.4
/usr/lib/python2.4/
/usr/lib/python2.4/UserDict.py
/usr/lib/python2.4/codecs.py
/usr/lib/python2.4/copy_reg.py
/usr/lib/python2.4/encodings
/usr/lib/python2.4/encodings/__init__.py
/usr/lib/python2.4/encodings/aliases.py
/usr/lib/python2.4/encodings/koi8_r.py
/usr/lib/python2.4/lib-dynload
/usr/lib/python2.4/lib-tk
/usr/lib/python2.4/linecache.py
/usr/lib/python2.4/os.py
/usr/lib/python2.4/plat-linux2
/usr/lib/python2.4/posixpath.py
/usr/lib/python2.4/site-packages/gtk-2.0
/usr/lib/python2.4/site-packages/wx-2.8-gtk2-unicode
/usr/lib/python2.4/site.py
/usr/lib/python2.4/stat.py
/usr/lib/python2.4/types.py
/usr/lib/python2.4/warnings.py

чтобы можно было линковаться с libpython.

> 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
Должен остаться только один.  Извраты в макросах на тему
поддержки нескольких питонов одновременно (которая поддержка на
самом деле является фикцией) не нужны.  python-strict тоже не
нужен.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] [git update] packages/python: heads/master

[Aleksey Avdeev]

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

Alexey I. Froloff пишет:
> * Alexey M. Tourbin <at@> [070315 08:57]:
> 
...
>>1) Я перетасую python, с учетом всех предложений, если таковые поступят.
> 
> Должен остаться только один.  Извраты в макросах на тему
> поддержки нескольких питонов одновременно (которая поддержка на
> самом деле является фикцией) не нужны.  python-strict тоже не
> нужен.

  Кто нибудь знает, какую политику по донному вопросу проводит Debian?

  Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
несколько python`ов тоже -- то возможно, неспроста они это делают...

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Aleksey Avdeev]

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

Ivan Fedorov пишет:
> Aleksey Avdeev пишет:
> 
>>Alexey I. Froloff пишет:
>>
>>>* Alexey M. Tourbin <at@> [070315 08:57]:
>>>
>>
>>...
>>
>>>>1) Я перетасую python, с учетом всех предложений, если таковые поступят.
>>>
>>>Должен остаться только один.  Извраты в макросах на тему
>>>поддержки нескольких питонов одновременно (которая поддержка на
>>>самом деле является фикцией) не нужны.  python-strict тоже не
>>>нужен.
>>
>>  Кто нибудь знает, какую политику по донному вопросу проводит Debian?
>>
>>  Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
>>несколько python`ов тоже -- то возможно, неспроста они это делают...
> 
> 
> Поддерживают... но по факту еще хуже чем у нас...

  Тогда, может стоит попробовать доработать то что у нас есть, а не
отламывать окончательно?

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

Aleksey Avdeev пишет:
> Alexey I. Froloff пишет:
>> * Alexey M. Tourbin <at@> [070315 08:57]:
>>
> ...
>>> 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
>> Должен остаться только один.  Извраты в макросах на тему
>> поддержки нескольких питонов одновременно (которая поддержка на
>> самом деле является фикцией) не нужны.  python-strict тоже не
>> нужен.
> 
>   Кто нибудь знает, какую политику по донному вопросу проводит Debian?
> 
>   Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
> несколько python`ов тоже -- то возможно, неспроста они это делают...

Поддерживают... но по факту еще хуже чем у нас...

Re: [devel] [git update] packages/python: heads/master

[Mikhail Gusarov]

Twas brillig at 12:14:07 15.03.2007 UTC+03 when Aleksey Avdeev did gyre and gimble:

AA> Кто нибудь знает, какую политику по донному вопросу проводит Debian?

Несколько питонов. В etch дефолтный 2.4. Байткомпиляция в доступные питоны
производится во время инсталляции, сборка модулей - во время сборки, для всех
поддерживаемых на текущий момент питонов.

http://www.debian.org/doc/packaging-manuals/python-policy/

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] [git update] packages/python: heads/master

[Mikhail Gusarov]

Twas brillig at 17:36:59 15.03.2007 UTC+08 when Ivan Fedorov did gyre and gimble:

 IF> Поддерживают... но по факту еще хуже чем у нас...

Факты желательно бы озвучить.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

Alexey M. Tourbin пишет:
> Впрочем, хорошо, что специалист по питону есть.  Жаль лишь, что... как
> там в Библии...  может быть, он задумался, или занят чем-либо, или в
> дороге, а может быть, и спит, так он проснется!
Занят... зарабатыванием денег... знаете-ли иногда хочется кушать.
А спорить с местным комьюнити мне как и cray@ уже надоело.

Тем более учитывая тот факт, что однажды я ВДРУГ перестал быть лидером 
Python Team, мне стало менее интересно поддерживать Python в рамках ALT.

> Питон распилен плохо.
Ууу...
> 
> Во-первых, пакет python-base нельзя установить "просто так", поскольку
> он вытягивает python-strict (или python-relaxed).  Имеет место быть
> круговая порука python-base <=> python-strict.
Да.
> 
> Во-вторых, python-base слишком тощий.  Он не обеспечивает "самого
> основного", так что его сущность не вполне совершенна.  По поводу
> самого основного см. ниже commit message.
Возможно.

> python-strict в свою очередь слишком жирный.
Нет. python-strict вытягивает все пакеты базовой поставки. Этот пакет 
вообще сделан только из-за того, что многим лень было аккуратно 
поставить несколько пакетов.

> Я уже переместил /usr/bin/python из python-strict в python-base,
> стараясь при этом не разламывать many-world интерпретации Андрея Орлова.
Потрясающе... а как это интересно???

> В-третьих, в python-base находится /usr/bin/pydoc, а pydoc по
> зависимостям вытягивает модуль pydoc.py, который в свою очередь
> вытягивает некоторые интроспективные/компиляторные модули, т.к.
> ему нужно смотреть в docstring.  Сейчас зависимости в /usr/bin/pydoc
> просто не ищутся, но если эту лавочку прикрыть, а мы ее прикроем,
> тогда, по сути, придется решать, сделать ли более толстым python-base,
> или же запаковать pydoc куда-нибудь отдельно.
> 
> Кроме того, некоторые интроспективные/компиляторные модули нужны для
> rpm-build-python, и они тоже должны (желательно) находится в
> python-base.  В общем, соображения на этот счет мне интересны.
Вообще-то они должны находиться в python-dev...
> 
> План такой.
> 
> 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
> Потом кто-нибудь должен проверить и отправим на сборку.
> 
> 2) Потом нужно доделать/пересобрать rpm-build-python с зависимостью на
> новый python-base.  Это даст заведомой рабочий rpm-build-python +
> python-base в базовой сборочной среде.
> 
> 3) Дальше я вернусь к rpm-build.

Делайте что хотите... себе и cray@ я и отдельную сборку вести смогу если 
что...

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

Mikhail Gusarov пишет:
> Twas brillig at 17:36:59 15.03.2007 UTC+08 when Ivan Fedorov did gyre and gimble:
> 
>  IF> Поддерживают... но по факту еще хуже чем у нас...
> 
> Факты желательно бы озвучить.
> 
Уже не помню... давно смотрел... они просто тогда давали анонсы, что у 
них все круто, но было все печально.

Re: [devel] [git update] packages/python: heads/master

[Mikhail Gusarov]

Twas brillig at 17:43:58 15.03.2007 UTC+08 when Ivan Fedorov did gyre and gimble:

 >> Факты желательно бы озвучить.

 IF> Уже не помню... давно смотрел... они просто тогда давали анонсы, что у них
 IF> все круто, но было все печально.

Во-первых, давно было давно. Во-вторых, желательно озвучить факты "печальности",
а то какой-то пересказ сплетен получается, а не техническое обсуждение.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

Aleksey Avdeev пишет:

>>>>> 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
>>>> Должен остаться только один.  Извраты в макросах на тему
>>>> поддержки нескольких питонов одновременно (которая поддержка на
>>>> самом деле является фикцией) не нужны.  python-strict тоже не
>>>> нужен.
>>>  Кто нибудь знает, какую политику по донному вопросу проводит Debian?
>>>
>>>  Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
>>> несколько python`ов тоже -- то возможно, неспроста они это делают...
>>
>> Поддерживают... но по факту еще хуже чем у нас...
> 
>   Тогда, может стоит попробовать доработать то что у нас есть, а не
> отламывать окончательно?

Может быть...

Я сейчас буду вести отделный проект на основе этого кода... и не совсем 
уверен, что захочу залить в сизиф результаты своего труда... ибо ХОРОШО 
помню какая была реакция на Python policy.

Re: [devel] [git update] packages/python: heads/master

[Aleksey Avdeev]

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

Ivan Fedorov пишет:
> Aleksey Avdeev пишет:
> 
> 
>>>>>>1) Я перетасую python, с учетом всех предложений, если таковые поступят.
>>>>>
>>>>>Должен остаться только один.  Извраты в макросах на тему
>>>>>поддержки нескольких питонов одновременно (которая поддержка на
>>>>>самом деле является фикцией) не нужны.  python-strict тоже не
>>>>>нужен.
>>>>
>>>> Кто нибудь знает, какую политику по донному вопросу проводит Debian?
>>>>
>>>> Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
>>>>несколько python`ов тоже -- то возможно, неспроста они это делают...
>>>
>>>Поддерживают... но по факту еще хуже чем у нас...
>>
>>  Тогда, может стоит попробовать доработать то что у нас есть, а не
>>отламывать окончательно?
> 
> 
> Может быть...
> 
> Я сейчас буду вести отделный проект на основе этого кода... и не совсем 
> уверен, что захочу залить в сизиф результаты своего труда... ибо ХОРОШО 
> помню какая была реакция на Python policy.

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

PS: После скрещивания нашего apache2 с Debian`овским, в пакете будут
утилиты управления написанные на Python. Тешу себя надеждой, что Python
policy мне поможет обойти часть граблей и запаковать всё это хозяйство
правильно. :-)

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

Aleksey Avdeev пишет:

>>>>>>> 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
>>>>>> Должен остаться только один.  Извраты в макросах на тему
>>>>>> поддержки нескольких питонов одновременно (которая поддержка на
>>>>>> самом деле является фикцией) не нужны.  python-strict тоже не
>>>>>> нужен.
>>>>> Кто нибудь знает, какую политику по донному вопросу проводит Debian?
>>>>>
>>>>> Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
>>>>> несколько python`ов тоже -- то возможно, неспроста они это делают...
>>>> Поддерживают... но по факту еще хуже чем у нас...
>>>  Тогда, может стоит попробовать доработать то что у нас есть, а не
>>> отламывать окончательно?
>>
>> Может быть...
>>
>> Я сейчас буду вести отделный проект на основе этого кода... и не совсем 
>> уверен, что захочу залить в сизиф результаты своего труда... ибо ХОРОШО 
>> помню какая была реакция на Python policy.
> 
>   За других говорить не буду, но для меня это исключительно важный
> документ, т. к. он явным образом формализует требования к
> Python-осодержащим пакетам, понижая порог вхождения в данную тему.
> 
> PS: После скрещивания нашего apache2 с Debian`овским, в пакете будут
> утилиты управления написанные на Python. Тешу себя надеждой, что Python
> policy мне поможет обойти часть граблей и запаковать всё это хозяйство
> правильно. :-)
А я тешу себя надеждой, что кто-нить его полностью (from scratch) 
перепишет, и там не останется упоминаний меня и cray@!

Ибо неблагоданые пользователи уже надоели... и терпеть нападки всякого 
быдла, которое даже читать в школе судя по всему не научилось, мне 
противно. А cray@ благодаря этим нападкам ушел из ALT!

Re: [devel] [git update] packages/python: heads/master

[Alexey Tourbin]

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

On Thu, Mar 15, 2007 at 05:43:13PM +0800, Ivan Fedorov wrote:
> > python-strict в свою очередь слишком жирный.
> Нет. python-strict вытягивает все пакеты базовой поставки. Этот пакет 
> вообще сделан только из-за того, что многим лень было аккуратно 
> поставить несколько пакетов.

Тем не менее зависимость на /usr/bin/python разрешается в python-strict.
Простейший питоновский скрипт будет вытягивать все python-modules-*
пакеты, а это всё же жирно.  Стандартная поставка это не совсем
технический термин, это запудривание мозгов юзерам.  Если поиск
зависимостей работает хорошо, то термин "стандартная поставка" теряет
смысл, т.к. по зависимостям становится нужен /usr/bin/python +
наращивать его модулями, хоть стандартными хоть нет.

> > Я уже переместил /usr/bin/python из python-strict в python-base,
> > стараясь при этом не разламывать many-world интерпретации Андрея Орлова.
> Потрясающе... а как это интересно???
> 
> > В-третьих, в python-base находится /usr/bin/pydoc, а pydoc по
> > зависимостям вытягивает модуль pydoc.py, который в свою очередь
> > вытягивает некоторые интроспективные/компиляторные модули, т.к.
> > ему нужно смотреть в docstring.  Сейчас зависимости в /usr/bin/pydoc
> > просто не ищутся, но если эту лавочку прикрыть, а мы ее прикроем,
> > тогда, по сути, придется решать, сделать ли более толстым python-base,
> > или же запаковать pydoc куда-нибудь отдельно.
> > 
> > Кроме того, некоторые интроспективные/компиляторные модули нужны для
> > rpm-build-python, и они тоже должны (желательно) находится в
> > python-base.  В общем, соображения на этот счет мне интересны.
> Вообще-то они должны находиться в python-dev...

Тем не менее сейчас они не находятся в python-dev.

> > План такой.
> > 
> > 1) Я перетасую python, с учетом всех предложений, если таковые поступят.
> > Потом кто-нибудь должен проверить и отправим на сборку.
> > 
> > 2) Потом нужно доделать/пересобрать rpm-build-python с зависимостью на
> > новый python-base.  Это даст заведомой рабочий rpm-build-python +
> > python-base в базовой сборочной среде.
> > 
> > 3) Дальше я вернусь к rpm-build.
> 
> Делайте что хотите...

Хорошо.

> себе и cray@ я и отдельную сборку вести смогу если 
> что...

Вы уж определитесь, какой аргумент у Вас главный.  То ли времени у Вас
нет, потому что все силы отнимает служение маммоне; то ли кто-то Вашу
полиси не оценил, питон отобрал, в общем, опустил нещадно.

В любом случае, мой интерес к питону связан только с автоматическим
поиском зависимостей.  В соседнем треде я описал несолько проблем,
которые делают этот поиск ненадежным.  Если никто не горит желанием
в ближайшее время адресовать все эти проблемы, то, конечно, мне придется
сделать всё по своему разумению.  Решение от дяди Васи не всегда плохо.
А что -- пришел, покрутил, работает.

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

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> On Thu, Mar 15, 2007 at 05:43:13PM +0800, Ivan Fedorov wrote:
>>> python-strict в свою очередь слишком жирный.
>> Нет. python-strict вытягивает все пакеты базовой поставки. Этот пакет 
>> вообще сделан только из-за того, что многим лень было аккуратно 
>> поставить несколько пакетов.
> 
> Тем не менее зависимость на /usr/bin/python разрешается в python-strict.
> Простейший питоновский скрипт будет вытягивать все python-modules-*
> пакеты, а это всё же жирно.  Стандартная поставка это не совсем
> технический термин, это запудривание мозгов юзерам.
Слушай, а где ты был 3 года назад???
>  Если поиск
> зависимостей работает хорошо, то термин "стандартная поставка" теряет
> смысл, т.к. по зависимостям становится нужен /usr/bin/python +
> наращивать его модулями, хоть стандартными хоть нет.
А в полиси написано, что те, кому не нравится python-strict должны
правильно собрать пакеты.

>>> Кроме того, некоторые интроспективные/компиляторные модули нужны для
>>> rpm-build-python, и они тоже должны (желательно) находится в
>>> python-base.  В общем, соображения на этот счет мне интересны.
>> Вообще-то они должны находиться в python-dev...
> 
> Тем не менее сейчас они не находятся в python-dev.
Мало что сейчас... сейчас и питон никто особо не поддерживает... Даже
Zope3 у меня стоит из тарбола.

>> себе и cray@ я и отдельную сборку вести смогу если 
>> что...
> 
> Вы уж определитесь, какой аргумент у Вас главный.  То ли времени у Вас
> нет, потому что все силы отнимает служение маммоне; то ли кто-то Вашу
> полиси не оценил, питон отобрал, в общем, опустил нещадно.
у меня нет времени чтобы на каждое изменение часами читать потоки негатива!

> В любом случае, мой интерес к питону связан только с автоматическим
> поиском зависимостей.  В соседнем треде я описал несолько проблем,
> которые делают этот поиск ненадежным.
На моих пакетах оно работает вполне надежно... а осмысленных
баг-репортов я давно не видел... была парочка предложений по
улучшению... что-то было даже с патчем... но и только. Даже ты поленился
создать баг!

> Если никто не горит желанием в ближайшее время адресовать все эти проблемы,
> то, конечно, мне придется сделать всё по своему разумению.
Решить-то я их решу - мне поиск зависимостей ОЧЕНЬ критичен... но вот
рискну ли я это заливать в сизиф - вопрос открытый.

Я например сейчас пытаюсь опакетить Zope3 - та еще задачка... но вот
только клиенту оно надо под RHEL, и я подозреваю, что мне в конце концов
просто придется все делать под RHEL.

>  Решение от дяди Васи не всегда плохо.
> А что -- пришел, покрутил, работает.
Угу... а потом все ищут концы... и виноватым за любой косяк все равно
останется cray@...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Alexey Tourbin]

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

On Thu, Mar 15, 2007 at 07:37:40PM +0800, Ivan Fedorov wrote:
> Alexey Tourbin пишет:
> > On Thu, Mar 15, 2007 at 05:43:13PM +0800, Ivan Fedorov wrote:
> >>> python-strict в свою очередь слишком жирный.
> >> Нет. python-strict вытягивает все пакеты базовой поставки. Этот пакет 
> >> вообще сделан только из-за того, что многим лень было аккуратно 
> >> поставить несколько пакетов.
> > 
> > Тем не менее зависимость на /usr/bin/python разрешается в python-strict.
> > Простейший питоновский скрипт будет вытягивать все python-modules-*
> > пакеты, а это всё же жирно.  Стандартная поставка это не совсем
> > технический термин, это запудривание мозгов юзерам.
> Слушай, а где ты был 3 года назад???

Пьянствовал, сидел с ребенком, что-то ещё.  Я же говорю, питон per se
меня не возбуждает, я лишь хочу решить некоторые проблемы на
дистрибутивном уровне.

> >  Если поиск
> > зависимостей работает хорошо, то термин "стандартная поставка" теряет
> > смысл, т.к. по зависимостям становится нужен /usr/bin/python +
> > наращивать его модулями, хоть стандартными хоть нет.
> А в полиси написано, что те, кому не нравится python-strict должны
> правильно собрать пакеты.

Признаться, я не читал policy.  Некоторые проблемы оказались для меня
самоочевидными.  Но, конечно, мне следует прочитать policy.  С другой
стороны, я и не выставляю себе новатором питона on a par с Андреем
Орловым, и по возможности стараюсь не ломать дров и сохранить старые
схемы.

> >>> Кроме того, некоторые интроспективные/компиляторные модули нужны для
> >>> rpm-build-python, и они тоже должны (желательно) находится в
> >>> python-base.  В общем, соображения на этот счет мне интересны.
> >> Вообще-то они должны находиться в python-dev...
> > 
> > Тем не менее сейчас они не находятся в python-dev.
> Мало что сейчас... сейчас и питон никто особо не поддерживает... Даже
> Zope3 у меня стоит из тарбола.

Не могу ничего сказать про Zope3.  По-видимому, это очень сложный пакет
с нетривиальной спецификой.  Сейчас мне лишь хочется разрулить менее
сложные случаи.

> >> себе и cray@ я и отдельную сборку вести смогу если 
> >> что...
> > 
> > Вы уж определитесь, какой аргумент у Вас главный.  То ли времени у Вас
> > нет, потому что все силы отнимает служение маммоне; то ли кто-то Вашу
> > полиси не оценил, питон отобрал, в общем, опустил нещадно.
> у меня нет времени чтобы на каждое изменение часами читать потоки негатива!

Вы, должно быть, слишком серьезно воспринимаете безответственные мнения
толпы.

	И вслед за чинною толпой
	Идти, не разделяя с ней
	Ни общих мнений, ни страстей.

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

git в значительной степени решает эту проблему.  Изменения может вносить
кто угодно, а если они будут конструктивными (например, в духе "Old
behaviour: неправильный результат; New behaviour: правильный
результат"), то их остается только взять.

> > В любом случае, мой интерес к питону связан только с автоматическим
> > поиском зависимостей.  В соседнем треде я описал несолько проблем,
> > которые делают этот поиск ненадежным.
> На моих пакетах оно работает вполне надежно... а осмысленных
> баг-репортов я давно не видел... была парочка предложений по
> улучшению... что-то было даже с патчем... но и только. Даже ты поленился
> создать баг!

Но не поленился его исправить, решив, что выйдет быстрее.  Багзилла мне
не удобна, как и Линусу.  Говорят, что у Эйнштейна болела голова, что-то
у меня тоже иногда голова болит. :)

> > Если никто не горит желанием в ближайшее время адресовать все эти проблемы,
> > то, конечно, мне придется сделать всё по своему разумению.
> Решить-то я их решу - мне поиск зависимостей ОЧЕНЬ критичен... но вот
> рискну ли я это заливать в сизиф - вопрос открытый.

Вы можете хотя бы публиковать свои изменения, git это очень
демократичная система, практически как rcs, остальное это быть
конструктивным и убедительным (но убеждать надо знамо кого, а не
всех подряд).

> Я например сейчас пытаюсь опакетить Zope3 - та еще задачка... но вот
> только клиенту оно надо под RHEL, и я подозреваю, что мне в конце концов
> просто придется все делать под RHEL.

Увы, Вы связаны обязательствами, которые обязывают действовать в
интересах клиента.  А я свободен и действую в интересах Сизифа и
в собственных интересах.  Не буду эту тему развивать.

> >  Решение от дяди Васи не всегда плохо.
> > А что -- пришел, покрутил, работает.
> Угу... а потом все ищут концы... и виноватым за любой косяк все равно
> останется cray@...

Это не конструктивно.  Конструктивно значит существует доказательство.
Давайте пример, или контрпример, или corner case, что именно после моих
изменений будет работать неправильно.

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

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> On Thu, Mar 15, 2007 at 07:37:40PM +0800, Ivan Fedorov wrote:
>> Alexey Tourbin пишет:
>>> On Thu, Mar 15, 2007 at 05:43:13PM +0800, Ivan Fedorov wrote:
>>>>> python-strict в свою очередь слишком жирный.
>>>> Нет. python-strict вытягивает все пакеты базовой поставки. Этот пакет 
>>>> вообще сделан только из-за того, что многим лень было аккуратно 
>>>> поставить несколько пакетов.
>>> Тем не менее зависимость на /usr/bin/python разрешается в python-strict.
>>> Простейший питоновский скрипт будет вытягивать все python-modules-*
>>> пакеты, а это всё же жирно.  Стандартная поставка это не совсем
>>> технический термин, это запудривание мозгов юзерам.
>> Слушай, а где ты был 3 года назад???
> 
> Пьянствовал, сидел с ребенком, что-то ещё.  Я же говорю, питон per se
> меня не возбуждает, я лишь хочу решить некоторые проблемы на
> дистрибутивном уровне.
Полгода назад я тоже хотел.. но у нас же офигенный фриз...

>>>  Если поиск
>>> зависимостей работает хорошо, то термин "стандартная поставка" теряет
>>> смысл, т.к. по зависимостям становится нужен /usr/bin/python +
>>> наращивать его модулями, хоть стандартными хоть нет.
>> А в полиси написано, что те, кому не нравится python-strict должны
>> правильно собрать пакеты.
> 
> Признаться, я не читал policy.
Ну вот... То есть ты даже не удосужился узнать, почему сделано так, а не
иначе и решил что все неправильно! Тебя внести в списки неумеющих читать
или ты хотябы попробуешь прочесть полиси?

>>>>> Кроме того, некоторые интроспективные/компиляторные модули нужны для
>>>>> rpm-build-python, и они тоже должны (желательно) находится в
>>>>> python-base.  В общем, соображения на этот счет мне интересны.
>>>> Вообще-то они должны находиться в python-dev...
>>> Тем не менее сейчас они не находятся в python-dev.
>> Мало что сейчас... сейчас и питон никто особо не поддерживает... Даже
>> Zope3 у меня стоит из тарбола.
> 
> Не могу ничего сказать про Zope3.  По-видимому, это очень сложный пакет
> с нетривиальной спецификой.
Zope3 это клиника. Это пакет, который собран в стиле win32 - он таскает
с собой ВСЁ. При том иногда неизвестных версий!

>>>> себе и cray@ я и отдельную сборку вести смогу если 
>>>> что...
>>> Вы уж определитесь, какой аргумент у Вас главный.  То ли времени у Вас
>>> нет, потому что все силы отнимает служение маммоне; то ли кто-то Вашу
>>> полиси не оценил, питон отобрал, в общем, опустил нещадно.
>> у меня нет времени чтобы на каждое изменение часами читать потоки негатива!
> 
> Вы, должно быть, слишком серьезно воспринимаете безответственные мнения
> толпы.
> 
> 	И вслед за чинною толпой
> 	Идти, не разделяя с ней
> 	Ни общих мнений, ни страстей.
> 
> Но демократия не равна охлократии, а конструктивное не всегда совпадает
> с позитивным, что же тут сделать.  Не будем обсуждать эту философскую
> проблему.
Проблема не в том, что негатива много... а в том, что позива за этим
вообще не видно... я даже с ходу и довольных назвать не могу. Хотя у
меня почему-то все работает!

> git в значительной степени решает эту проблему.  Изменения может вносить
> кто угодно, а если они будут конструктивными (например, в духе "Old
> behaviour: неправильный результат; New behaviour: правильный
> результат"), то их остается только взять.
git это вообще странная система... и не ее децентрализованность, а
вообще вся система!

>>> В любом случае, мой интерес к питону связан только с автоматическим
>>> поиском зависимостей.  В соседнем треде я описал несолько проблем,
>>> которые делают этот поиск ненадежным.
>> На моих пакетах оно работает вполне надежно... а осмысленных
>> баг-репортов я давно не видел... была парочка предложений по
>> улучшению... что-то было даже с патчем... но и только. Даже ты поленился
>> создать баг!
> 
> Но не поленился его исправить, решив, что выйдет быстрее.
Вот только я например мог об этом и не узнать никогда!
> Багзилла мне не удобна, как и Линусу.
А мне вот неудобно жить не на Мальдвских островах...

> Говорят, что у Эйнштейна болела голова, что-то у меня тоже иногда голова болит. :)
Ну у меня она иногда болит с утра и до вечера... и что с того???

>>> Если никто не горит желанием в ближайшее время адресовать все эти проблемы,
>>> то, конечно, мне придется сделать всё по своему разумению.
>> Решить-то я их решу - мне поиск зависимостей ОЧЕНЬ критичен... но вот
>> рискну ли я это заливать в сизиф - вопрос открытый.
> 
> Вы можете хотя бы публиковать свои изменения, git это очень
> демократичная система, практически как rcs, остальное это быть
> конструктивным и убедительным (но убеждать надо знамо кого, а не
> всех подряд).
Я знаете ли пару лет назад дошел до одной истины - если человек хочет
оставаться в неведении и тебе это не мешает, то не надо ему мешать
оставаться в неведении.
> 
>>>  Решение от дяди Васи не всегда плохо.
>>> А что -- пришел, покрутил, работает.
>> Угу... а потом все ищут концы... и виноватым за любой косяк все равно
>> останется cray@...
> 
> Это не конструктивно.  Конструктивно значит существует доказательство.
> Давайте пример, или контрпример, или corner case, что именно после моих
> изменений будет работать неправильно.
Во-первых я не говорил, что что-то обязательно будет работать
неправильно... а во-вторых я так понимаю, что 2 питона уже поставить
неудастся?..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070315 15:48]:
> > Признаться, я не читал policy.
> Ну вот... То есть ты даже не удосужился узнать, почему сделано так, а не
> иначе и решил что все неправильно! Тебя внести в списки неумеющих читать
> или ты хотябы попробуешь прочесть полиси?
Там есть ответ на вопрос, зачем нам серпентарий в репозитарии?

Кстати, указание версии питона в spec'е для "проверки
работоспособности его с новым питоном" это бред.

> а во-вторых я так понимаю, что 2 питона уже поставить
> неудастся?..

"""
Так вот. Мантейнер этого питона всегда был против. Не надо на
меня это вешать.  Я не знаю зачем мы держим все питоны в
дистрибутиве, моими стараниями ни малейшей необходимости в этом
никогда не было, но любая попытка убрать старый питон вызывает
крики возмущения. Так что я держу несколько питонов ни в коем
случае не по своему желанию, а под давлением общественности.
Мало того, как явно заявлено в полиси, старые питоны не
поддерживаются и не рекомендуются к использованию: с точки зрения
технологии они остаются ровно в том состоянии, в котором их
форкнули в боковую ветку.

С моей точки зрения, держать несколько питонов - полный идиотизм,
и я прилагаю массу усилий для того, что бы все пакеты работали
именно с последним питоном.  За что имел немало проблем, в
частности с небезызвестным Zope. И все это действительно
работает.
"""

Угадайте, чья цитата?

P.S. Давайте позовём ту самую "Общественность" и поблагодарим её
за наше счастливое настоящее.


-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] [git update] packages/python: heads/master

[Alexey Tourbin]

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

On Thu, Mar 15, 2007 at 08:47:44PM +0800, Ivan Fedorov wrote:
> > Признаться, я не читал policy.
> Ну вот... То есть ты даже не удосужился узнать, почему сделано так, а не
> иначе и решил что все неправильно! Тебя внести в списки неумеющих читать
> или ты хотябы попробуешь прочесть полиси?

Я уже укорил себя в невежестве, а также ограничил его пределы.
Вряд ли стоит корить меня вновь.

> > Но демократия не равна охлократии, а конструктивное не всегда совпадает
> > с позитивным, что же тут сделать.  Не будем обсуждать эту философскую
> > проблему.
> Проблема не в том, что негатива много... а в том, что позива за этим
> вообще не видно... я даже с ходу и довольных назвать не могу. Хотя у
> меня почему-то все работает!

Позивтив, грубо говоря, не нужен.  Это убунтовское.  Нужен конструктив,
который решает определенные проблемы, посредством примеров и
конрприметров (если полезность не очевдина), в общем, falsifiability.
Только так мы сможем выбраться из дыры.

> > git в значительной степени решает эту проблему.  Изменения может вносить
> > кто угодно, а если они будут конструктивными (например, в духе "Old
> > behaviour: неправильный результат; New behaviour: правильный
> > результат"), то их остается только взять.
> git это вообще странная система... и не ее децентрализованность, а
> вообще вся система!

Она странная, но хорошая.  Во всяком случае, она дает возможность
публиковать изменения с защитой от подтасовок.  Этому несложно
научиться.

> > Говорят, что у Эйнштейна болела голова, что-то у меня тоже иногда голова болит. :)
> Ну у меня она иногда болит с утра и до вечера... и что с того???

Я шучу, прчем сам над собой, это должно быть понятно, и вряд ли стоит
драматизировать по этому поводу. :)

> > Вы можете хотя бы публиковать свои изменения, git это очень
> > демократичная система, практически как rcs, остальное это быть
> > конструктивным и убедительным (но убеждать надо знамо кого, а не
> > всех подряд).
> Я знаете ли пару лет назад дошел до одной истины - если человек хочет
> оставаться в неведении и тебе это не мешает, то не надо ему мешать
> оставаться в неведении.

Вы хотите оставить кого-то в невежестве посредством непубликации
собственной работы?  Это больше похоже на абсурд.

> >>>  Решение от дяди Васи не всегда плохо.
> >>> А что -- пришел, покрутил, работает.
> >> Угу... а потом все ищут концы... и виноватым за любой косяк все равно
> >> останется cray@...
> > 
> > Это не конструктивно.  Конструктивно значит существует доказательство.
> > Давайте пример, или контрпример, или corner case, что именно после моих
> > изменений будет работать неправильно.
> Во-первых я не говорил, что что-то обязательно будет работать
> неправильно... а во-вторых я так понимаю, что 2 питона уже поставить
> неудастся?..

Нет конечно!  Два или три питона можно ставить сколько угодно.
Вот мое главное изменение насчет /usr/bin/python.

commit 4b546b4d14d4e8028a45020793ef101df042e61f
Author: Alexey Tourbin <at@altlinux.ru>
Date:   Wed Mar 14 14:43:26 2007 +0300

    spec: moved /usr/bin/python from python-strict to python-base

diff --git a/python.spec b/python.spec
index 3960a28..bf83c82 100644
--- a/python.spec
+++ b/python.spec
@@ -74,7 +74,6 @@ Conflicts: python22
 Conflicts: python = 2.2
 Conflicts: python23
 Conflicts: python = 2.3
-Provides: %_bindir/%real_name
 Requires: %name-base
 Requires: %name-modules %name-modules-encodings
 Requires: %name-modules-curses %name-modules-xml %name-modules-compiler
@@ -116,6 +115,7 @@ This is a python with relaxed conflicts: using with python22 are allowed.
 Summary: Base python modules and executables
 Group: Development/Python
 Requires: %real_name = %require_ver
+Provides: /usr/bin/python
 Provides: python2.4(os.path)
 Provides: python2.4(pwd)
 Obsoletes: python2.4-base <= 2.4-alt1
@@ -630,6 +630,10 @@ chmod +x python.sh
 mv %buildroot{%_libdir/python2.4/config/libpython2.4.a,%_libdir/libpython2.4.a}
 mv %buildroot{%_mandir/man1/python.1,%_mandir/man1/python2.4.1}
 
+%post base
+[ -e /usr/bin/python ] || ln -snf python2.4 /usr/bin/python
+[ -e /usr/bin/pydoc ] || ln -snf pydoc2.4 /usr/bin/pydoc
+
 %post strict
 ln -sf /usr/bin/python2.4 /usr/bin/python
 ln -sf /usr/bin/pydoc2.4 /usr/bin/pydoc

Это означает ровно следующее: 1) зависимость /usr/bin/python теперь
будет предоставлять python-base.  Это означает, что если есть некоторый
"случайный" питоновский скрипт, который не требует "ничего специального"
от питона, то теперь эта зависимость будет разрешаться в python-base.
2) Если сразу после установки python-base не видит, что /usr/bin/python
куда-то смотрит, то он переводит стрелки на себя.  После установки
python-strict или python-relaxed стрелки переводятся как и раньше.
Всё вместе это означает, что все "неспецифические" зависимости на питон
я хочу свести к *предсказуемому* python-base.  Конфликтов по файлу
/usr/bin/python нет, и возможность many-world интерпретации сохраняется.

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

Re: [devel] [git update] packages/python: heads/master

[Dmitry V. Levin]

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

On Thu, Mar 15, 2007 at 08:47:44PM +0800, Ivan Fedorov wrote:
[...]
> Во-первых я не говорил, что что-то обязательно будет работать
> неправильно... а во-вторых я так понимаю, что 2 питона уже поставить
> неудастся?..

Кстати, про 2 питона есть цитата 2-летней давности:
http://lists.altlinux.org/pipermail/devel/2005-March/019008.html

Моё частное мнение как человека, у которого нет личных предпочтений
при выборе языка разработки "perl или python":
У вас (а точнее говоря, у cray@) получилась неудачная python policy.

Настолько неудачная по сравнению, скажем, с perl policy, что при наличии
выбора perl/python даже я, как правило, выбираю perl из-за преимуществ,
которые даёт perl policy, и неудобств, которые порождает python policy.

Ну и, конечно, тот факт что у perl в Сизифе есть хороший мантейнер, а
у python в Сизифе нет хорошего мантейнера, тоже работает против
python policy.


-- 
ldv

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

Re: [devel] [git update] packages/python: heads/master

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> On Thu, Mar 15, 2007 at 08:47:44PM +0800, Ivan Fedorov wrote:

>>> Вы можете хотя бы публиковать свои изменения, git это очень
>>> демократичная система, практически как rcs, остальное это быть
>>> конструктивным и убедительным (но убеждать надо знамо кого, а не
>>> всех подряд).
>> Я знаете ли пару лет назад дошел до одной истины - если человек хочет
>> оставаться в неведении и тебе это не мешает, то не надо ему мешать
>> оставаться в неведении.
> 
> Вы хотите оставить кого-то в невежестве посредством непубликации
> собственной работы?  Это больше похоже на абсурд.
Да нет... просто я больше никому не буду объяснять, для чего сделанно
именно так, если мне не приведут реальную и конкретную ситуацию, когда
решение не работает.

>> Во-первых я не говорил, что что-то обязательно будет работать
>> неправильно... а во-вторых я так понимаю, что 2 питона уже поставить
>> неудастся?..
> 
> Нет конечно!  Два или три питона можно ставить сколько угодно.
> Вот мое главное изменение насчет /usr/bin/python.

Ну так оно выглядит вполне конструктивно... и работоспособно...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [git update] packages/python: heads/master

[Konstantin A. Lepikhov]

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

Hi Ivan!

Thursday 15, at 05:36:59 PM you wrote:

...
> >   Про python не вкурсе, но несколько ocaml`ов они поддерживают. Если
> > несколько python`ов тоже -- то возможно, неспроста они это делают...
> 
> Поддерживают... но по факту еще хуже чем у нас...
зато у них питон работает, а у нас нет.

-- 
WBR et al.

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

[devel] python-modules-encodings

[Alexey Tourbin]

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

On Thu, Mar 15, 2007 at 12:12:49PM +0300, Alexey I. Froloff wrote:
> Самое основное, что должно входить в python-base, это (filereq
> зацепил пару левых каталогов):

Кстати, filereq из моего rpm-utils.git уже не выводит каталогов.
Правда, там есть ещё над чем подумать.

> $ filereq /dev/stdout python -c 1 | fgrep python2.4 | grep -v \\.pyc\$
> /usr/lib/libpython2.4.so.1.0                                     
> /usr/lib/python2.4
> /usr/lib/python2.4/
> /usr/lib/python2.4/UserDict.py
> /usr/lib/python2.4/codecs.py
> /usr/lib/python2.4/copy_reg.py
> /usr/lib/python2.4/encodings
> /usr/lib/python2.4/encodings/__init__.py
> /usr/lib/python2.4/encodings/aliases.py
> /usr/lib/python2.4/encodings/koi8_r.py

Вот тут есть проблема.
Python/Python/codecs.c:

   834      mod = PyImport_ImportModuleEx("encodings", NULL, NULL, NULL);
   835      if (mod == NULL) {
   836          if (PyErr_ExceptionMatches(PyExc_ImportError)) {
   837              /* Ignore ImportErrors... this is done so that
   838                 distributions can disable the encodings package. Note
   839                 that other errors are not masked, e.g. SystemErrors
   840                 raised to inform the user of an error in the Python
   841                 configuration are still reported back to the user. */
   842              PyErr_Clear();
   843              return 0;
   844          }
   845          return -1;
   846      }

То есть, с одной стороны, питон как бы хорошо работает из без этих
encodings.  С другой стороны, он всегда пытается их загружать.
И в этом коде я не вижу никакого естественного способа отбить у
него эту охоту.  Получается, buildreq будет всегда цеплять
python-modules-encodings.

[...]
> /usr/lib/python2.4/types.py
> /usr/lib/python2.4/warnings.py
> 
> чтобы можно было линковаться с libpython.

Не понял, зачем линковаться с libpython через python-base.
Нужно наверное поставить python-devel и использовать какой-нибудь
стандартный способ линковки с липитоном, если таковой существует
(как в перле).

Или ты просто vim хочешь линковать с либпитоном, не вытаскивая при
этом "полную поставку питона"?

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

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 18:37:20 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:

 AT> То есть, с одной стороны, питон как бы хорошо работает из без этих
 AT> encodings.  С другой стороны, он всегда пытается их загружать.  И в этом
 AT> коде я не вижу никакого естественного способа отбить у него эту охоту.
 AT> Получается, buildreq будет всегда цеплять python-modules-encodings.

А можно ли поправить buildreq, чтобы он откуда-нибудь вычитывал "хинты" типа
"здесь encodings не нужен"? Думаю, для многих случаев пригодится.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Sun, Mar 18, 2007 at 09:41:08PM +0600, Mikhail Gusarov wrote:
>  AT> То есть, с одной стороны, питон как бы хорошо работает из без этих
>  AT> encodings.  С другой стороны, он всегда пытается их загружать.  И в этом
>  AT> коде я не вижу никакого естественного способа отбить у него эту охоту.
>  AT> Получается, buildreq будет всегда цеплять python-modules-encodings.
> 
> А можно ли поправить buildreq, чтобы он откуда-нибудь вычитывал "хинты" типа
> "здесь encodings не нужен"? Думаю, для многих случаев пригодится.

Можно только игнорировать конкретные файлы.
/etc/buildreqs/files/ignore.d/

Ну и потом, в каком виде эти хинты писать, прямо в спекфайле, что ли?
А откуда мы знаем, нужны здесь были encodings или не нужны?  Некоторые
пакеты ведь действительно требуют encodings:

$ apt-cache showpkg 'python2.4(encodings)' |grep '^ ' |sort -u
  gajim,python2.4(encodings)
  imgv,python2.4(encodings)
  mailman,python2.4(encodings)
  python-module-paramiko,python2.4(encodings)
  python-module-pyxmpp,python2.4(encodings)
$

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

Re: [devel] python-modules-encodings

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070318 18:41]:
> Не понял, зачем линковаться с libpython через python-base.
Ну видимо потому, что пакета libpython в природе не существует...

> Нужно наверное поставить python-devel и использовать какой-нибудь
> стандартный способ линковки с липитоном, если таковой существует
> (как в перле).
Такой способ даже в апстриме никак не описан.  А сборочная
зависимость именно на python-devel.

> Или ты просто vim хочешь линковать с либпитоном, не вытаскивая при
> этом "полную поставку питона"?
Да.  А ещё я хочу не #^@#$^ себе мозги вопросом "а какой у нас
сейчас самый кошерный питон".

python-devel должен быть один, последней версии.  Для старых
питонов подойдёт pythonX.Y-devel, принципиальной разницы, где
именно в BuildRequires будет стоять конкретная версия питона, я
не вижу.

-- 
Regards,
Sir Raorn.

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

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 18:47:50 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:

 >> А можно ли поправить buildreq, чтобы он откуда-нибудь вычитывал "хинты" типа
 >> "здесь encodings не нужен"? Думаю, для многих случаев пригодится.

 AT> Ну и потом, в каком виде эти хинты писать, прямо в спекфайле, что ли?

Да, в спекфайле, например, по типу того, что vsu предлагал: %description -l X..,
или специальными комментариями, каким-нибудь #%buildreq:, или чем-нибудь ещё (я,
к сожалению, внутреннюю кухню rpm не сильно хорошо знаю, но раз эти хинты нужны
только на этапе сборки, то не думаю, что будет большой проблемой придумать, где
их разместить).

 AT> А откуда мы знаем, нужны здесь были encodings или не нужны? Некоторые
 AT> пакеты ведь действительно требуют encodings:

Хинты - это исключения. А исключения всегда обрабатываются вручную.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Sun, Mar 18, 2007 at 09:52:42PM +0600, Mikhail Gusarov wrote:
>  AT> А откуда мы знаем, нужны здесь были encodings или не нужны? Некоторые
>  AT> пакеты ведь действительно требуют encodings:
> 
> Хинты - это исключения. А исключения всегда обрабатываются вручную.

Слишком много исключений получается.  При *любом* запуске питона, если
установлен пакет python-modules-encodings, он цепляет эти encodings.
Тут скорее нужно писать исключения типа "encodings были действительно
нужны".

Но, в любом случае, buildreq -- это rough tool, типа запустил и можно
не думать (в большинстве случаев).  Делать механизмы каких-то хинтов
(кроме существующих -- по файлам и по названиям пакетов), по-моему,
никто не собирается.

Просто ещё и хочется, чтобы этот rough tool всегда работал правильно,
в смысле dwim. :)

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

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 18:59:16 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:

 AT> Слишком много исключений получается.  При *любом* запуске питона, если
 AT> установлен пакет python-modules-encodings, он цепляет эти encodings.

Ммм. Я не знаю кухни buildreq: каким образом это скажется? builreq будет
говорить, что всем питоньим пакетам нужен encodings?

 AT> Тут скорее нужно писать исключения типа "encodings были действительно
 AT> нужны".

А вот такой стиль хинтов я себе не могу представить в каком-либо более-менее
общем виде.

 AT> Но, в любом случае, buildreq -- это rough tool, типа запустил и можно не
 AT> думать (в большинстве случаев).  Делать механизмы каких-то хинтов (кроме
 AT> существующих -- по файлам и по названиям пакетов), по-моему, никто не
 AT> собирается.

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

Введение таких хинтов может из rough tool сделать удобный tool, который не
думешь, запускать или нет, а просто запускешь.

 AT> Просто ещё и хочется, чтобы этот rough tool всегда работал правильно, в
 AT> смысле dwim. :)

Всегда бы ещё знать, wim на самом деле :)

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Sun, Mar 18, 2007 at 10:10:24PM +0600, Mikhail Gusarov wrote:
>  AT> Но, в любом случае, buildreq -- это rough tool, типа запустил и можно не
>  AT> думать (в большинстве случаев).  Делать механизмы каких-то хинтов (кроме
>  AT> существующих -- по файлам и по названиям пакетов), по-моему, никто не
>  AT> собирается.
> 
> А я предлагаю подумать. Вот почему: зависимости неплохо бы пересчитывать при
> каждой сборке, и необходимость ручного подправления зависимостей каждый раз
> приведёт к одному из двух вариантов: либо buildreq запускать перестанут, либо на
> "левые" зависимости махнут рукой.

"Левые" зависимости, извлекаемые buildreq'ом, обычно являются отражением
"левых" зависимостей между самими пакетами.  Как и в данном случае: пакет
python-base требует encodings или пакет python-base не требует encodings?
Антиномия чистого разума, практически.

> Введение таких хинтов может из rough tool сделать удобный tool, который не
> думешь, запускать или нет, а просто запускешь.

Он не плох в большинстве случаев.  Практически можно запускать
и не думать.  Иногда только результат получается не слишком красивым.
Вот пример из tig.spec:

# Automatically added by buildreq on Thu Feb 22 2007
BuildRequires: asciidoc libncurses-devel python-modules-encodings xmlto

Тут расклад такой: asciidoc требует питон, а питон при запуске цепляет
encodings.  В результате появляется python-modules-encodings, который
напоминает нам о том, что asciidoc написан на питоне.

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

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 19:21:39 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:

 AT> "Левые" зависимости, извлекаемые buildreq'ом, обычно являются отражением
 AT> "левых" зависимостей между самими пакетами.  Как и в данном случае: пакет
 AT> python-base требует encodings или пакет python-base не требует encodings?
 AT> Антиномия чистого разума, практически.

Да, зависимости есть только в нашем разуме. В коде есть... код. Инструменты,
обрабатывающие код, могут делать только догадки (отсылаю к теореме о
алгоритмической неразрешимости задачи об остановке конечного автомата).

Таким образом фраза "отражение 'левых' зависимостей" не несёт никакого смысла:
нет "левых" зависимостей, есть неверная догадка инструмента о наличии
зависимости, которой нет в природе.

 >> Введение таких хинтов может из rough tool сделать удобный tool, который не
 >> думешь, запускать или нет, а просто запускешь.

 AT> Он не плох в большинстве случаев.

Ну так я и предлагаю сделать ещё лучше ;) Всего лишь научить buildreq
воспринимать те ручные правки, которые майнтайнер делает после buildreq, раз
инструмент (к великому нашему сожалению) не имеет разума, и не может принимать
верные решения.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Michael Shigorin]

On Sun, Mar 18, 2007 at 09:41:08PM +0600, Mikhail Gusarov wrote:
>  AT> То есть, с одной стороны, питон как бы хорошо работает из без этих
>  AT> encodings.  С другой стороны, он всегда пытается их загружать.  И в этом
>  AT> коде я не вижу никакого естественного способа отбить у него эту охоту.
>  AT> Получается, buildreq будет всегда цеплять python-modules-encodings.
> А можно ли поправить buildreq, чтобы он откуда-нибудь вычитывал "хинты" типа
> "здесь encodings не нужен"? Думаю, для многих случаев пригодится.

http://lists.altlinux.org/pipermail/devel/2004-May/011048.html

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] python-modules-encodings

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [070318 19:31]:
> Ну так я и предлагаю сделать ещё лучше ;) Всего лишь научить buildreq
> воспринимать те ручные правки, которые майнтайнер делает после buildreq, раз
> инструмент (к великому нашему сожалению) не имеет разума, и не может принимать
> верные решения.
Поскольку buildreq парсит спек перед обработкой и читает свои
собственные каменты (на тему -bi), можно там же перечислять
подобные ошибочные зависимости:

# Automatically added by buildreq on Tue Jan 23 2007
# Autoignore: linux-libc-headers imake xorg-cf-files
BuildRequires: libXext-devel libXpm-devel

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

-- 
Regards,
Sir Raorn.

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

Re: [devel] python-modules-encodings

[Michael Shigorin]

On Sun, Mar 18, 2007 at 10:29:16PM +0600, Mikhail Gusarov wrote:
>  >> Введение таких хинтов может из rough tool сделать удобный
>  >> tool, который не думешь, запускать или нет, а просто
>  >> запускешь.
>  AT> Он не плох в большинстве случаев.
> Ну так я и предлагаю сделать ещё лучше ;) Всего лишь научить
> buildreq воспринимать те ручные правки, которые майнтайнер
> делает после buildreq, раз инструмент (к великому нашему
> сожалению) не имеет разума, и не может принимать верные
> решения.

Э... да, комментарии рядышком "а это вот мы выкидываем" водятся.

2 at: # buildnoreq: <список>?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Sun, Mar 18, 2007 at 06:37:20PM +0300, Alexey Tourbin wrote:
> Вот тут есть проблема.
> Python/Python/codecs.c:
> 
>    834      mod = PyImport_ImportModuleEx("encodings", NULL, NULL, NULL);
>    835      if (mod == NULL) {
>    836          if (PyErr_ExceptionMatches(PyExc_ImportError)) {
>    837              /* Ignore ImportErrors... this is done so that
>    838                 distributions can disable the encodings package. Note
>    839                 that other errors are not masked, e.g. SystemErrors
>    840                 raised to inform the user of an error in the Python
>    841                 configuration are still reported back to the user. */
>    842              PyErr_Clear();
>    843              return 0;
>    844          }
>    845          return -1;
>    846      }
> 
> То есть, с одной стороны, питон как бы хорошо работает из без этих
> encodings.  С другой стороны, он всегда пытается их загружать.
> И в этом коде я не вижу никакого естественного способа отбить у
> него эту охоту.  Получается, buildreq будет всегда цеплять
> python-modules-encodings.

Кажется, мне дали портфель.  Можно будет прямо в этом месте трахнуть
питон на предмет getenv("__buildreqs") или как-нибудь так.  Правда,
buildreq сейчас ничего не экспортирует, но это дело наживное.  И это
сейчас не первоочередная задача.

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

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Sun, Mar 18, 2007 at 08:00:49PM +0300, Alexey I. Froloff wrote:
> * Mikhail Gusarov <dottedmag@> [070318 19:31]:
> > Ну так я и предлагаю сделать ещё лучше ;) Всего лишь научить buildreq
> > воспринимать те ручные правки, которые майнтайнер делает после buildreq, раз
> > инструмент (к великому нашему сожалению) не имеет разума, и не может принимать
> > верные решения.
> Поскольку buildreq парсит спек перед обработкой и читает свои
> собственные каменты (на тему -bi), можно там же перечислять
> подобные ошибочные зависимости:
> 
> # Automatically added by buildreq on Tue Jan 23 2007
> # Autoignore: linux-libc-headers imake xorg-cf-files
> BuildRequires: libXext-devel libXpm-devel
> 
> Тогда подобную ручную фильтрацию надо будет производить чуть
> более одного раза за время жизни пакета.

Но это получается ещё больше информации в спеке, чем просто лишние
зависимости в BuildRequires (с которыми можно примириться).  Я поэтому
как бы говорю: что бы мы ни делали, ничего проще просто лишнего пакета
в BuildRequires придумать нельзя.  Поэтому проще ничего не делать. :)

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

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

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 21:28:28 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:

 AT> Если серьезно, то, как я уже написал, кривые зависимости, которые дает
 AT> buidlreq, являются отражением кривых зависимостей между пакетами.

Прошу тебя, ВНИМАТЕЛЬНО прочитай следующее:

|Да, зависимости есть только в нашем разуме. В коде есть... код. Инструменты,
|обрабатывающие код, могут делать только догадки (отсылаю к теореме о
|алгоритмической неразрешимости задачи об остановке конечного автомата).

|Таким образом фраза "отражение 'левых' зависимостей" не несёт никакого смысла:
|нет "левых" зависимостей, есть неверная догадка инструмента о наличии
|зависимости, которой нет в природе.

И пойми, что фраза "кривых зависимостей между пакетами" не имеет ни малейшего
смысла.

 AT> Наверное, нужно захачить питон, чтобы он не загружал encodings, если
 AT> запущен под buildreq'ом.

Это грязный хак.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Mikhail Gusarov]

Twas brillig at 18:54:02 18.03.2007 UTC+02 when Michael Shigorin did gyre and gimble:

 MS> http://lists.altlinux.org/pipermail/devel/2004-May/011048.html

Ага, "а воз и ныне там". Багу, что ли, повесить ;)

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] python-modules-encodings

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070318 21:36]:
> Если серьезно, то, как я уже написал, кривые зависимости, которые дает
> buidlreq, являются отражением кривых зависимостей между пакетами.
Да тут не только питон.  Тот же imake, который не используется,
но цепляется тестами configure.

Хотя, ты прав насчёт кривых зависимостей...

$ sudo apt-get remove imake xorg-cf-files
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  imake libdockapp-devel libqt3-devel libqt4-devel xorg-cf-files xorg-x11-compat-devel
  xorg-x11-devel
0 upgraded, 0 newly installed, 7 removed and 2 not upgraded.
Need to get 0B of archives.
After unpacking 18.0MB disk space will be freed.


-- 
Regards,
Sir Raorn.

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

[devel] [JT] python policy и отношение к коллегам

[Michael Shigorin]

On Thu, Mar 15, 2007 at 05:50:44PM +0800, Ivan Fedorov wrote:
> Я сейчас буду вести отделный проект на основе этого кода... и
> не совсем уверен, что захочу залить в сизиф результаты своего
> труда... ибо ХОРОШО помню какая была реакция на Python policy.

Да, -1 майнтейнер.  Скверная история.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] python policy и отношение к коллегам

[Dmitry V. Levin]

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

On Mon, Mar 19, 2007 at 12:10:02AM +0200, Michael Shigorin wrote:
> On Thu, Mar 15, 2007 at 05:50:44PM +0800, Ivan Fedorov wrote:
> > Я сейчас буду вести отделный проект на основе этого кода... и
> > не совсем уверен, что захочу залить в сизиф результаты своего
> > труда... ибо ХОРОШО помню какая была реакция на Python policy.
> 
> Да, -1 майнтейнер.  Скверная история.

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

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

Мне кажется, что Иван не станет писать в своём резюме о том, что
он ушёл из-за того, что его не устроила реакция на Python policy.


-- 
ldv

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

Re: [devel] python-modules-encodings

[Alexey Morsov]

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

On Sun, Mar 18, 2007 at 06:37:20PM +0300, Alexey Tourbin wrote:
>    834      mod = PyImport_ImportModuleEx("encodings", NULL, NULL, NULL);
>    835      if (mod == NULL) {
>    836          if (PyErr_ExceptionMatches(PyExc_ImportError)) {
>    837              /* Ignore ImportErrors... this is done so that
>    838                 distributions can disable the encodings package. Note
>    839                 that other errors are not masked, e.g. SystemErrors
>    840                 raised to inform the user of an error in the Python
>    841                 configuration are still reported back to the user. */
>    842              PyErr_Clear();
>    843              return 0;
>    844          }
>    845          return -1;
>    846      }

Так. А не из-за этого ли (или рядом) в инкаминге теперь строка 
# -*- coding: windows-1251 -*-
считается ошибкой?
Не перекрутили ли гайки?

-- 

С уважением,
Алексей Морсов
системный администратор ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
www.ricom.ru
www.fondmarket.ru

NP: Music is over :(


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

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Mon, Mar 19, 2007 at 07:35:08PM +0300, Alexey Morsov wrote:
> On Sun, Mar 18, 2007 at 06:37:20PM +0300, Alexey Tourbin wrote:
> >    834      mod = PyImport_ImportModuleEx("encodings", NULL, NULL, NULL);
> >    835      if (mod == NULL) {
> >    836          if (PyErr_ExceptionMatches(PyExc_ImportError)) {
> >    837              /* Ignore ImportErrors... this is done so that
> >    838                 distributions can disable the encodings package. Note
> >    839                 that other errors are not masked, e.g. SystemErrors
> >    840                 raised to inform the user of an error in the Python
> >    841                 configuration are still reported back to the user. */
> >    842              PyErr_Clear();
> >    843              return 0;
> >    844          }
> >    845          return -1;
> >    846      }
> 
> Так. А не из-за этого ли (или рядом) в инкаминге теперь строка 
> # -*- coding: windows-1251 -*-
> считается ошибкой?
> Не перекрутили ли гайки?

Нет. :)  Здесь ничего не изменилось.  Мы обсуждали другую пробему:
двусмысленную зависимость python-base от python-modules-encodings.
И отсутствие способа сказать питону "питон, не трогай в этом месте
кодировки, представь себе, что их НЕТ".

Вообще, пишите подробнее, что именно сломалось.

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

Re: [devel] python-modules-encodings

[Alexey Morsov]

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

On Mon, Mar 19, 2007 at 07:39:09PM +0300, Alexey Tourbin wrote:
> 
> Вообще, пишите подробнее, что именно сломалось.
Why:

Preparing packages for installation...
python-base-2.4.4-alt8
ca-certificates-2007.02.06-alt1
libssl6-0.9.8d-alt2
libgdbm-1.8.3-alt3
python-modules-email-2.4.4-alt8
python-modules-compiler-2.4.4-alt8
python-modules-2.4.4-alt8
python-dev-2.4.4-alt8
Installing python-module-pyExcelerator-0.6.3-alt1.a.src.rpm
Building target platforms: i586
Building for target i586
Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.12357
+ umask 022
+ /bin/mkdir -p /usr/src/RPM/BUILD
+ cd /usr/src/RPM/BUILD
+ rm -rf pyExcelerator-0.6.3a
+ echo 'Source #0 (pyExcelerator-0.6.3a.tar.bz2):'
Source #0 (pyExcelerator-0.6.3a.tar.bz2):
+ /bin/bzip2 -dc /usr/src/RPM/SOURCES/pyExcelerator-0.6.3a.tar.bz2
+ /bin/tar -xf -
+ cd pyExcelerator-0.6.3a
+ /bin/chmod -Rf u+rwX,go-w .
Patch #1 (pyExcelerator-0.6.3a-stdout.patch):
+ echo 'Patch #1 (pyExcelerator-0.6.3a-stdout.patch):'
+ /usr/bin/patch -p1
patching file pyExcelerator/CompoundDoc.py
Patch #2 (pyExcelerator-0.6.3a-p23.patch):
+ echo 'Patch #2 (pyExcelerator-0.6.3a-p23.patch):'
+ /usr/bin/patch -p1
patching file pyExcelerator/Column.py
patching file pyExcelerator/Deco.py
patching file pyExcelerator/__init__.py
patching file pyExcelerator/Row.py
patching file pyExcelerator/Workbook.py
patching file pyExcelerator/Worksheet.py
+ exit 0
Executing(%build): /bin/sh -e /usr/src/tmp/rpm-tmp.12357
+ umask 022
+ /bin/mkdir -p /usr/src/RPM/BUILD
+ cd /usr/src/RPM/BUILD
+ cd pyExcelerator-0.6.3a
+ /usr/bin/python2.4 setup.py build
  File "setup.py", line 2
SyntaxError: encoding problem: with BOM

RPM build errors:

Сие сказал мне робот пытавшийся пересобрать pyExcelerator. Ну собственно вторая строка в setup.py
это та самая 
# -*- coding:

Раньше такого не было , потому и подумал что из-за "веяний" новых )
Кстати - может это и глюки роботов но таки такой абзац пришел только для i586 (про x86_64 тишина).

-- 

С уважением,
Алексей Морсов
системный администратор ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
www.ricom.ru
www.fondmarket.ru

NP: Music is over :(


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

Re: [devel] python-modules-encodings

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> Наверное, нужно захачить питон, чтобы он не загружал encodings, если
> запущен под buildreq'ом.

Ну вот такого зверства не надо!!!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-modules-encodings

[Ivan Fedorov]

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

Michael Shigorin пишет:
> On Sun, Mar 18, 2007 at 10:29:16PM +0600, Mikhail Gusarov wrote:
>>  >> Введение таких хинтов может из rough tool сделать удобный
>>  >> tool, который не думешь, запускать или нет, а просто
>>  >> запускешь.
>>  AT> Он не плох в большинстве случаев.
>> Ну так я и предлагаю сделать ещё лучше ;) Всего лишь научить
>> buildreq воспринимать те ручные правки, которые майнтайнер
>> делает после buildreq, раз инструмент (к великому нашему
>> сожалению) не имеет разума, и не может принимать верные
>> решения.
> 
> Э... да, комментарии рядышком "а это вот мы выкидываем" водятся.
> 
> 2 at: # buildnoreq: <список>?

+1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Michael Shigorin пишет:
> On Thu, Mar 15, 2007 at 05:50:44PM +0800, Ivan Fedorov wrote:
>> Я сейчас буду вести отделный проект на основе этого кода... и
>> не совсем уверен, что захочу залить в сизиф результаты своего
>> труда... ибо ХОРОШО помню какая была реакция на Python policy.
> 
> Да, -1 майнтейнер.  Скверная история.
> 
Не спеши меня хоронить. На postgresql стервятники еще не накинулись...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Dmitry V. Levin пишет:
> On Mon, Mar 19, 2007 at 12:10:02AM +0200, Michael Shigorin wrote:
>> On Thu, Mar 15, 2007 at 05:50:44PM +0800, Ivan Fedorov wrote:
>>> Я сейчас буду вести отделный проект на основе этого кода... и
>>> не совсем уверен, что захочу залить в сизиф результаты своего
>>> труда... ибо ХОРОШО помню какая была реакция на Python policy.
>> Да, -1 майнтейнер.  Скверная история.
> 
> Многие пишут код "для внутреннего употребления", немногие из них
> этот код публикуют, и немногие из публикующих могут всерьёз
> рассчитывать на положительный отклик.
> 
> Проблема в том, что люди, которые неправильно поняли, в какой из
> этих групп они находятся, зачастую потом испытывают неудобства.
> 
> Мне кажется, что Иван не станет писать в своём резюме о том, что
> он ушёл из-за того, что его не устроила реакция на Python policy.

Ну блин ваще... живьем закопали!!!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 01:53:24AM +0800, Ivan Fedorov wrote:
> Alexey Tourbin пишет:
> > Наверное, нужно захачить питон, чтобы он не загружал encodings, если
> > запущен под buildreq'ом.
> 
> Ну вот такого зверства не надо!!!

Хорошо.
Я придумал промежуточное решение на уровне rpm-build-python и buildreq.

commit 80cc60b7525cd1fcbb85df6f91a02e2e09ef0a6e
Author: Alexey Tourbin <at@altlinux>
Date:   Mon Mar 19 21:12:54 2007 +0300

    deal with build dependencies on python-modules-encodings
    
    If you run buildreq and if you have python-modules-encodings installed,
    buildreq will always yield python-modules-encodings.  However, if
    python-modules-encodings is missing, that's okay (most of the time).
    
    $ packagereq -o /dev/stdout rpm --eval %__python_version
    2.4
    packagereq: building requires list: python-modules-encodings
    python-modules-encodings
    $
    
    The problem is in the following code:
    
    Python/Python/codecs.c
       834      mod = PyImport_ImportModuleEx("encodings", NULL, NULL, NULL);
       835      if (mod == NULL) {
       836          if (PyErr_ExceptionMatches(PyExc_ImportError)) {
       837              /* Ignore ImportErrors... this is done so that
       838                 distributions can disable the encodings package. Note
       839                 that other errors are not masked, e.g. SystemErrors
       840                 raised to inform the user of an error in the Python
       841                 configuration are still reported back to the user. */
       842              PyErr_Clear();
       843              return 0;
       844          }
       845          return -1;
       846      }
    
    And there's no switch like "assume no encodings available at startup".
    
    Now I still don't want buildreq to yield python-modules-encodings
    only because I evaluate %__python_version macro.
    
    The solution is as follows:
    
    1) everywhere from rpm-build-python run python with LC_ALL=C.
    2) add encoding files loaded under LC_ALL=C to buildreq skiplist.
    
    New behaviour:
    
    $ packagereq -o /dev/stdout rpm --eval %__python_version
    2.4
    packagereq: building requires list: python-base
    python-base
    $

diff --git a/rpm-build-python.spec b/rpm-build-python.spec
index a3da4b1..cf5c5aa 100644
--- a/rpm-build-python.spec
+++ b/rpm-build-python.spec
@@ -39,6 +39,7 @@ subst 's/@PYTHON_VERSION@/%__python_version/g' python
 %install
 install -pD -m644 python %buildroot%_sysconfdir/rpm/macros.d/python
 install -pD -m644 python.env %buildroot%_sysconfdir/rpm/macros.d/python.env
+install -pD -m644 python.buildreq %buildroot%_sysconfdir/buildreqs/files/ignore.d/%name
 install -pD -m755 python.prov %buildroot%_target_libdir/rpm/python.prov
 install -pD -m755 python.prov.py %buildroot%_target_libdir/rpm/python.prov.py
 install -pD -m755 python.prov.files %buildroot%_target_libdir/rpm/python.prov.files
@@ -62,6 +63,7 @@ unset RPM_PYTHON
 %files
 %_sysconfdir/rpm/macros.d/python
 %_sysconfdir/rpm/macros.d/python.env
+%_sysconfdir/buildreqs/files/ignore.d/%name
 %_target_libdir/rpm/python.compileall.py
 %_target_libdir/rpm/python.req
 %_target_libdir/rpm/python.req.py
diff --git a/rpm-build-python/python b/rpm-build-python/python
index 8b49990..af9a622 100644
--- a/rpm-build-python/python
+++ b/rpm-build-python/python
@@ -2,7 +2,7 @@
 # -*- coding: utf-8 -*-
 
 # Override __python_version macro provided by rpm-build 
-%__python_version	%(%__python -c 'import sys; print "%%u.%%u" %% sys.version_info[0:2]' 2>/dev/null || echo @PYTHON_VERSION@)
+%__python_version	%(LC_ALL=C %__python -c 'import sys; print "%%u.%%u" %% sys.version_info[0:2]' 2>/dev/null || echo @PYTHON_VERSION@)
 
 %_python_lib_path	""
 %_python_req_method	slight
diff --git a/rpm-build-python/python.buildreq b/rpm-build-python/python.buildreq
new file mode 100644
index 0000000..4e323a7
--- /dev/null
+++ b/rpm-build-python/python.buildreq
@@ -0,0 +1,3 @@
+^/usr/.*/python.*/encodings/__init__\.py
+^/usr/.*/python.*/encodings/aliases\.py
+^/usr/.*/python.*/encodings/ascii\.py
diff --git a/rpm-build-python/python.prov b/rpm-build-python/python.prov
index cdca9e4..309a1fd 100755
--- a/rpm-build-python/python.prov
+++ b/rpm-build-python/python.prov
@@ -1,2 +1,2 @@
 #!/bin/sh
-exec "${RPM_PYTHON:-python}" "$0".py ${1+"$@"}
+LC_ALL=C exec "${RPM_PYTHON:-python}" "$0".py ${1+"$@"}
diff --git a/rpm-build-python/python.req b/rpm-build-python/python.req
index cdca9e4..309a1fd 100755
--- a/rpm-build-python/python.req
+++ b/rpm-build-python/python.req
@@ -1,2 +1,2 @@
 #!/bin/sh
-exec "${RPM_PYTHON:-python}" "$0".py ${1+"$@"}
+LC_ALL=C exec "${RPM_PYTHON:-python}" "$0".py ${1+"$@"}

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

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070319 21:11]:
> > Да, -1 майнтейнер.  Скверная история.
> Не спеши меня хоронить. На postgresql стервятники еще не
> накинулись...
Дык, спасибо что втянул патчи к инитскрипту.  Нам с ними жить ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Alexey I. Froloff пишет:
> * Ivan Fedorov <ns_alt_devel@> [070319 21:11]:
>>> Да, -1 майнтейнер.  Скверная история.
>> Не спеши меня хоронить. На postgresql стервятники еще не
>> накинулись...
> Дык, спасибо что втянул патчи к инитскрипту.  Нам с ними жить ;-)
> 
Дык возрадуйся, что я на них СЛУЧАЙНО наткнулся! :)

Сидел тут от скуки и смотрел, кто в git.alt мои пакеты насоздавал...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-modules-encodings

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> On Tue, Mar 20, 2007 at 01:53:24AM +0800, Ivan Fedorov wrote:
>> Alexey Tourbin пишет:
>>> Наверное, нужно захачить питон, чтобы он не загружал encodings, если
>>> запущен под buildreq'ом.
>> Ну вот такого зверства не надо!!!
> 
> Хорошо.
> Я придумал промежуточное решение на уровне rpm-build-python и buildreq.

У меня есть еще более интересное предложение - втянуть encodings в base.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 02:42:18AM +0800, Ivan Fedorov wrote:
> Alexey Tourbin пишет:
> > On Tue, Mar 20, 2007 at 01:53:24AM +0800, Ivan Fedorov wrote:
> >> Alexey Tourbin пишет:
> >>> Наверное, нужно захачить питон, чтобы он не загружал encodings, если
> >>> запущен под buildreq'ом.
> >> Ну вот такого зверства не надо!!!
> > 
> > Хорошо.
> > Я придумал промежуточное решение на уровне rpm-build-python и buildreq.
> 
> У меня есть еще более интересное предложение - втянуть encodings в base.

Плюс один мегабайт в python-base, при этом не решается ни одной
проблемы, кроме buildreq.  Надо подумать.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070319 21:42]:
> > Дык, спасибо что втянул патчи к инитскрипту.  Нам с ними жить ;-)
> Дык возрадуйся, что я на них СЛУЧАЙНО наткнулся! :)
Фигассе, заявы!

$ grep pgsql files/list/list.groups
@pgsql  ns mithraen

У твоего товарища по команде они три с половиной месяца в git
лежат.  Потому как он на тот момент был последним сборщиком.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Alexey I. Froloff пишет:
> * Ivan Fedorov <ns_alt_devel@> [070319 21:42]:
>>> Дык, спасибо что втянул патчи к инитскрипту.  Нам с ними жить ;-)
>> Дык возрадуйся, что я на них СЛУЧАЙНО наткнулся! :)
> Фигассе, заявы!
> 
> $ grep pgsql files/list/list.groups
> @pgsql  ns mithraen
> 
> У твоего товарища по команде они три с половиной месяца в git
> лежат.  Потому как он на тот момент был последним сборщиком.
> 
Дык вот не лежат они у него в git... дома он их забыл!..

Возрадуйся - децентрализация с недоделанной сборкой из GIT в полный рост!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-modules-encodings

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> On Tue, Mar 20, 2007 at 02:42:18AM +0800, Ivan Fedorov wrote:
>> Alexey Tourbin пишет:
>>> On Tue, Mar 20, 2007 at 01:53:24AM +0800, Ivan Fedorov wrote:
>>>> Alexey Tourbin пишет:
>>>>> Наверное, нужно захачить питон, чтобы он не загружал encodings, если
>>>>> запущен под buildreq'ом.
>>>> Ну вот такого зверства не надо!!!
>>> Хорошо.
>>> Я придумал промежуточное решение на уровне rpm-build-python и buildreq.
>> У меня есть еще более интересное предложение - втянуть encodings в base.
>
> Плюс один мегабайт в python-base, при этом не решается ни одной
> проблемы, кроме buildreq.  Надо подумать.

Вот уж где мегабайт не страшен, так это в python-base IMHO... ибо если
кому-то понадобится очень компактное решение и с python - ему все равно
придется ОСНОВАТЕЛЬНО поработать ручками... начиная с uClibc...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070319 22:12]:
> > У твоего товарища по команде они три с половиной месяца в git
> > лежат.  Потому как он на тот момент был последним сборщиком.
> Дык вот не лежат они у него в git... дома он их забыл!..
Да что ви гойво`ите!

http://git.altlinux.org/people/mithraen/packages/?p=postgresql8.0.git;a=commit;h=524749c3b3e3c3221f79c1078f358b344edc6390
http://git.altlinux.org/people/mithraen/packages/?p=postgresql8.1.git;a=commit;h=5d7854d86d50a54b56722e7712221765ccde3d5a

> Возрадуйся - децентрализация с недоделанной сборкой из GIT в
> полный рост!
Кругом враги?  Все хотят тебя ущемить?

-- 
Regards,
Sir Raorn.

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

Re: [devel] python-modules-encodings

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 03:12:50AM +0800, Ivan Fedorov wrote:
> >>> Я придумал промежуточное решение на уровне rpm-build-python и buildreq.
> >> У меня есть еще более интересное предложение - втянуть encodings в base.
> >
> > Плюс один мегабайт в python-base, при этом не решается ни одной
> > проблемы, кроме buildreq.  Надо подумать.
> 
> Вот уж где мегабайт не страшен, так это в python-base IMHO... ибо если
> кому-то понадобится очень компактное решение и с python - ему все равно
> придется ОСНОВАТЕЛЬНО поработать ручками... начиная с uClibc...

До alt8 пакет python-base сам по себе вообще не ставился, я же нашел
ему достойное применение (отвязал от него все остальные питоновские
зависимости, сделал чтобы он предоставлял /usr/bin/python, положил
в него несколько дополнительных модулей, чтобы их хватало для
rpm-build-python и вообще).

Я исходил из того, что python-base должен остаться почти таким же
маленьким, как и был, но при этом иметь какую-то самостоятельную
ценность, которой раньше у него не было.  Теперь Вы убеждаете меня,
что в python-base нужно до кучи положить ещё всего побольше.
Надо подумать... :)

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

Re: [devel] python-modules-encodings

[Ivan Fedorov]

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

Alexey Tourbin пишет:
> Я исходил из того, что python-base должен остаться почти таким же
> маленьким, как и был, но при этом иметь какую-то самостоятельную
> ценность, которой раньше у него не было.  Теперь Вы убеждаете меня,
> что в python-base нужно до кучи положить ещё всего побольше.
> Надо подумать... :)

А я исхожу из того, что если уж все равно переделывать, то все и разом...
Ибо лучше сразу отрезать палец, чем отрезать по одной фаланге - мы же не
садисты? %-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Alexey I. Froloff пишет:

>>> У твоего товарища по команде они три с половиной месяца в git
>>> лежат.  Потому как он на тот момент был последним сборщиком.
>> Дык вот не лежат они у него в git... дома он их забыл!..
> Да что ви гойво`ите!
Ну мало ли, что он УЖЕ успел закачать из дома...

>> Возрадуйся - децентрализация с недоделанной сборкой из GIT в
>> полный рост!
> Кругом враги?  Все хотят тебя ущемить?
Я разве говорил, что меня ущемили? Ты опоздал с маханием шашкой - оно
уже закончилось. Извини. Если хочешь, я тебя позову в следующий раз к
началу, если не забуду в пылу спора?..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070319 23:12]:
> >>> У твоего товарища по команде они три с половиной месяца в git
> >>> лежат.  Потому как он на тот момент был последним сборщиком.
> >> Дык вот не лежат они у него в git... дома он их забыл!..
> > Да что ви гойво`ите!
> Ну мало ли, что он УЖЕ успел закачать из дома...

* Denis Smirnov <mithraen@> [061207 09:42]:
> Update of /people/mithraen/packages/postgresql8.1.git

> Changes statistics since `8.1.5-alt2.1' follows:
>  postgresql.init.in |   40 +++++++++++++++++++++-------------------
>  1 files changed, 21 insertions(+), 19 deletions(-)

> Changelog since `8.1.5-alt2.1' follows:
> commit 5d7854d86d50a54b56722e7712221765ccde3d5a
> Author: Sir Raorn <raorn@altlinux.ru>
> Date:   Wed Dec 6 15:54:09 2006 +0300

* Denis Smirnov <mithraen@> [061207 09:42]:
> Update of /people/mithraen/packages/postgresql8.0.git

> Changes statistics since `8.0.9-alt2.1' follows:
>  postgresql.init.in |   40 +++++++++++++++++++++-------------------
>  1 files changed, 21 insertions(+), 19 deletions(-)

> Changelog since `8.0.9-alt2.1' follows:
> commit 524749c3b3e3c3221f79c1078f358b344edc6390
> Author: Sir Raorn <raorn@altlinux.ru>
> Date:   Wed Dec 6 15:49:25 2006 +0300

Слив засчитан?


> >> Возрадуйся - децентрализация с недоделанной сборкой из GIT в
> >> полный рост!
> > Кругом враги?  Все хотят тебя ущемить?
> Я разве говорил, что меня ущемили? Ты опоздал с маханием шашкой - оно
> уже закончилось. Извини. Если хочешь, я тебя позову в следующий раз к
> началу, если не забуду в пылу спора?..
Шёл бы ты с таким отношением куда собирался... :-/

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Денис Смирнов]

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

On Mon, Mar 19, 2007 at 10:16:12PM +0300, Alexey I. Froloff wrote:

>>> У твоего товарища по команде они три с половиной месяца в git
>>> лежат.  Потому как он на тот момент был последним сборщиком.
>> Дык вот не лежат они у него в git... дома он их забыл!..
AIF> Да что ви гойво`ите!
AIF> http://git.altlinux.org/people/mithraen/packages/?p=postgresql8.0.git;a=commit;h=524749c3b3e3c3221f79c1078f358b344edc6390
AIF> http://git.altlinux.org/people/mithraen/packages/?p=postgresql8.1.git;a=commit;h=5d7854d86d50a54b56722e7712221765ccde3d5a

Подтверждаю. Я ламер. Синхронизировался недавно. У меня оказалось
множество несинхронизированых с git.alt пакетов, уже поправил и посыпал
голову пеплом.

>> Возрадуйся - децентрализация с недоделанной сборкой из GIT в
>> полный рост!
AIF> Кругом враги?  Все хотят тебя ущемить?

 - У вас есть враги?
 - Э... Были...

:)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Ой, прелесть какая, сам же теперь могу этот баг и поправить.
		-- ktirf in #5838

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

[devel] buildreq += autoignore

[Michael Shigorin]

On Tue, Mar 20, 2007 at 01:54:03AM +0800, Ivan Fedorov wrote:
> > 2 at: # buildnoreq: <список>?
> +1

Я недочитал тред, у Лёши более сахарно получилось:

# Automatically added by buildreq on Tue Jan 23 2007
# Autoignore: linux-libc-headers imake xorg-cf-files
BuildRequires: libXext-devel libXpm-devel

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] python policy и отношение к коллегам

[Денис Смирнов]

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

On Mon, Mar 19, 2007 at 11:30:34PM +0300, Alexey I. Froloff wrote:

>> Changes statistics since `8.0.9-alt2.1' follows:
>>  postgresql.init.in |   40 +++++++++++++++++++++-------------------
>>  1 files changed, 21 insertions(+), 19 deletions(-)
>> Changelog since `8.0.9-alt2.1' follows:
>> commit 524749c3b3e3c3221f79c1078f358b344edc6390
>> Author: Sir Raorn <raorn@altlinux.ru>
>> Date:   Wed Dec 6 15:49:25 2006 +0300
AIF> Слив засчитан?

С 8.0 у меня точно хрень какая-то в репозитории была, вместо того что
надо.
Как это у меня получилось я не знаю (при том что уже некоторое время
пользуюсь скриптиком который всегда делает git push перед rpmbs), но факт
есть факт -- в репо у меня был бардак. У меня эти выходные были посвящены
наведению порядка и разгребанию мантейнерских ховстов.

Подобные проблемы к счастью будут решены раз и навсегда после появления
сборки прямо из git и кэширующего репозитория.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
"Нет программы -- нет проблемы" (c)
		-- mike in #5012

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

Re: [devel] buildreq += autoignore

[Alexey Tourbin]

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

On Mon, Mar 19, 2007 at 11:25:51PM +0200, Michael Shigorin wrote:
> On Tue, Mar 20, 2007 at 01:54:03AM +0800, Ivan Fedorov wrote:
> > > 2 at: # buildnoreq: <список>?
> > +1
> 
> Я недочитал тред, у Лёши более сахарно получилось:
> 
> # Automatically added by buildreq on Tue Jan 23 2007
> # Autoignore: linux-libc-headers imake xorg-cf-files
> BuildRequires: libXext-devel libXpm-devel

Мужыки, <...>.  Я вам объясню, почему цепляется imake и выносится в
отдельную зависимость.  Потому что любой configure, в котором щупаются
иксовые библиотеки, он будет цеплять xmkmf и imake.  Погрепайте
/usr/share/autoconf.

Соответственно мораль простая: в случае с autotools, а этот случай
довольно типичный, пакеты libX11-devel и imake используются всегда
вместе; но при этом они не сводятся друг ко другу, и buildreq не может
их оптимизировать.

Возможно, что просто есть резон подшить imake в зависимости
к libX11-devel.  Но, насколько я знаю, maintainer этих пакетов
не хочет этого делать.

Короче: buildreq не ошибается.  Как распилили так он и показывает.
What you see is what you get.

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

Re: [devel] buildreq += autoignore

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070320 00:42]:
> Мужыки, <...>.  Я вам объясню, почему цепляется imake и выносится в
> отдельную зависимость.  Потому что любой configure, в котором щупаются
> иксовые библиотеки, он будет цеплять xmkmf и imake.  Погрепайте
> /usr/share/autoconf.
Цепляется он потому, что установлен.  Установлен потому, то по
зависимостям.  Зависимости местами кривоваты, потому и не
сносится.  Или я не понял мысль?

-- 
Regards,
Sir Raorn.

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

Re: [devel] buildreq += autoignore

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 12:56:43AM +0300, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070320 00:42]:
> > Мужыки, <...>.  Я вам объясню, почему цепляется imake и выносится в
> > отдельную зависимость.  Потому что любой configure, в котором щупаются
> > иксовые библиотеки, он будет цеплять xmkmf и imake.  Погрепайте
> > /usr/share/autoconf.
> Цепляется он потому, что установлен.  Установлен потому, то по
> зависимостям.  Зависимости местами кривоваты, потому и не
> сносится.  Или я не понял мысль?

Да подними архивы.  ldv когда-то грозно намекал, что непересобираемость
пакетов из-за отсутствия imake в BR не ведет ко всеобщему счастью.
Равно и наличие imake в BR почему-то кого-то огорчает.

В общем, я не вижу, чего ради тут переделывать buildreq.  Он говорит
правду, а список пакетов в спеке меньше всё равно не станет.  Просто
будет два списка, один из них ignore... но разве от этого легче?

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

Re: [devel] buildreq += autoignore

[Michael Shigorin]

On Tue, Mar 20, 2007 at 01:03:58AM +0300, Alexey Tourbin wrote:
> В общем, я не вижу, чего ради тут переделывать buildreq.  Он
> говорит правду, а список пакетов в спеке меньше всё равно не
> станет.  Просто будет два списка, один из них ignore... но
> разве от этого легче?

Сборочнице может быть чуть легче, если шум тяжелее imake.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Денис Смирнов <mithraen@> [070320 00:32]:
> С 8.0 у меня точно хрень какая-то в репозитории была, вместо
> того что надо.
Ты attribution потерял при квотинге.  Там 061207, 7-е декабря
прошлого года.

-- 
Regards,
Sir Raorn.

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

Re: [devel] buildreq += autoignore

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 12:13:15AM +0200, Michael Shigorin wrote:
> On Tue, Mar 20, 2007 at 01:03:58AM +0300, Alexey Tourbin wrote:
> > В общем, я не вижу, чего ради тут переделывать buildreq.  Он
> > говорит правду, а список пакетов в спеке меньше всё равно не
> > станет.  Просто будет два списка, один из них ignore... но
> > разве от этого легче?
> 
> Сборочнице может быть чуть легче, если шум тяжелее imake.

Ага.  Вспоможение сборочнице.

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

Re: [devel] buildreq

[Dmitry V. Levin]

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

On Mon, Mar 19, 2007 at 02:10:39AM +0600, Mikhail Gusarov wrote:
> Twas brillig at 21:28:28 18.03.2007 UTC+03 when Alexey Tourbin did gyre and gimble:
> 
>  AT> Если серьезно, то, как я уже написал, кривые зависимости, которые дает
>  AT> buidlreq, являются отражением кривых зависимостей между пакетами.
> 
> Прошу тебя, ВНИМАТЕЛЬНО прочитай следующее:
> 
> |Да, зависимости есть только в нашем разуме. В коде есть... код. Инструменты,
> |обрабатывающие код, могут делать только догадки (отсылаю к теореме о
> |алгоритмической неразрешимости задачи об остановке конечного автомата).
> 
> |Таким образом фраза "отражение 'левых' зависимостей" не несёт никакого смысла:
> |нет "левых" зависимостей, есть неверная догадка инструмента о наличии
> |зависимости, которой нет в природе.
> 
> И пойми, что фраза "кривых зависимостей между пакетами" не имеет ни малейшего
> смысла.

Я чувствую, что не все участники обсуждения в достаточной мере знают
матчасть, поэтому напомню некоторые аспекты buildreq.

buildreq -- это инструмент, предназначенный для выявления пакетов, которые
были использованы во время сборки исследуемого пакета.  Этот инструмент не
исследует код, он его трассирует, так что ссылка на теорему об
алгоритмической неразрешимости тут не при чём.

Что касается фразы "кривые зависимости между пакетами", то у неё есть
буквальный смысл: у некоторых пакетов есть неправильные
(неполные, избыточные или неверные) зависимости.

Если пакет A во время сборки каким-то образом использовал другой пакет B,
хотя мог бы и не использовать его с тем же результатом по окончании сборки,
то было бы странным ожидать от инструмента класса buildreq догадок
относительно степени необходимости пакета B для сборки пакета A.


-- 
ldv

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

Re: [devel] [JT] python policy и отношение к коллегам

[Konstantin Pavlov]

20.03.07, Alexey I. Froloff<raorn> написал(а):
> * Денис Смирнов <mithraen@> [070320 00:32]:
> > С 8.0 у меня точно хрень какая-то в репозитории была, вместо
> > того что надо.
> Ты attribution потерял при квотинге.  Там 061207, 7-е декабря
> прошлого года.

gitweb (и git) показывает, когда был сделан тот или иной коммит, а не
время его заливки/опубликования...

Re: [devel] buildreq += autoignore

[Dmitry V. Levin]

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

On Tue, Mar 20, 2007 at 01:21:05AM +0300, Alexey Tourbin wrote:
> On Tue, Mar 20, 2007 at 12:13:15AM +0200, Michael Shigorin wrote:
> > On Tue, Mar 20, 2007 at 01:03:58AM +0300, Alexey Tourbin wrote:
> > > В общем, я не вижу, чего ради тут переделывать buildreq.  Он
> > > говорит правду, а список пакетов в спеке меньше всё равно не
> > > станет.  Просто будет два списка, один из них ignore... но
> > > разве от этого легче?
> > 
> > Сборочнице может быть чуть легче, если шум тяжелее imake.
> 
> Ага.  Вспоможение сборочнице.

Лично мне autoignore не требуется по одной простой причине:
Я последние несколько лет запускаю buildreq только внутри hasher'а, а там
autoignore не нужен: если какая-то сборочная зависимость, выявленная
buildreq'ом, является лишней, то достаточно этот лишний пакет просто
удалить из вычисленного списка сборочных зависимостей, чтобы в следующий
раз он там больше не появился.

Вопрос: а зачем autoignore потребовался вам?


-- 
ldv

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

Re: [devel] buildreq += autoignore

[Michael Shigorin]

On Tue, Mar 20, 2007 at 01:28:36AM +0300, Dmitry V. Levin wrote:
> Вопрос: а зачем autoignore потребовался вам?

"глядя на комментарии в нескольких спеках".

OK, со своей стороны вопрос считаю зарытым до более внятного
обоснования, что там были жуткие по весу и ненужности добавления.
Скорее всего, это навсегда. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] python policy и отношение к коллегам

[Dmitry V. Levin]

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

On Tue, Mar 20, 2007 at 01:20:33AM +0300, Alexey I. Froloff wrote:
> * Денис Смирнов <mithraen@> [070320 00:32]:
> > С 8.0 у меня точно хрень какая-то в репозитории была, вместо
> > того что надо.
> Ты attribution потерял при квотинге.  Там 061207, 7-е декабря
> прошлого года.

Raorn, на этот раз ты не угадал.
Если верить списку рассылки git-update (а чему же ещё верить,
если не фактам), то в каталогах
/people/mithraen/packages/postgresql8.1.git и
/people/mithraen/packages/postgresql8.0.git 17-го марта были заметные
обновления.


-- 
ldv

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

Re: [devel] buildreq += autoignore

[Motsyo Gennadi aka Drool]

Dmitry V. Levin пишет:
> Я последние несколько лет запускаю buildreq только внутри hasher'а, а там
> autoignore не нужен: если какая-то сборочная зависимость, выявленная
> buildreq'ом, является лишней, то достаточно этот лишний пакет просто
> удалить из вычисленного списка сборочных зависимостей, чтобы в следующий
> раз он там больше не появился.

	А можна для расширения кругозора вопросец? Я тоже запускаю buildreq 
внутри хашера, и если зацепил некоторый пакет - значит он был установлен 
в системе и как-то кем-то дергался... Я экспериментировал - удалял некий 
(скажем qt4(3)-settings) из BuildRequires и снова собирал - в списке 
устанавливаемых пакетов он все-равно вылезает.
	Так имеет ли смысл чистка спека, если единственный результат - 
некоторое уменьшение размера пакета за счет 5-10 удаленных букв?

Re: [devel] buildreq += autoignore

[Dmitry V. Levin]

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

On Tue, Mar 20, 2007 at 12:43:16AM +0200, Motsyo Gennadi aka Drool wrote:
> Dmitry V. Levin пишет:
> > Я последние несколько лет запускаю buildreq только внутри hasher'а, а там
> > autoignore не нужен: если какая-то сборочная зависимость, выявленная
> > buildreq'ом, является лишней, то достаточно этот лишний пакет просто
> > удалить из вычисленного списка сборочных зависимостей, чтобы в следующий
> > раз он там больше не появился.
> 
> 	А можна для расширения кругозора вопросец? Я тоже запускаю buildreq 
> внутри хашера, и если зацепил некоторый пакет - значит он был установлен 
> в системе и как-то кем-то дергался... Я экспериментировал - удалял некий 
> (скажем qt4(3)-settings) из BuildRequires и снова собирал - в списке 
> устанавливаемых пакетов он все-равно вылезает.

Относительно свежий buildreq умеет оптимизировать список вычисленных
сборочных зависимостей.  Насколько я понимаю, с ним ваш эксперимент
повторить не получится.


-- 
ldv

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

Re: [devel] buildreq += autoignore

[Motsyo Gennadi aka Drool]

Dmitry V. Levin пишет:
>> 	А можна для расширения кругозора вопросец? Я тоже запускаю buildreq 
>> внутри хашера, и если зацепил некоторый пакет - значит он был установлен 
>> в системе и как-то кем-то дергался... Я экспериментировал - удалял некий 
>> (скажем qt4(3)-settings) из BuildRequires и снова собирал - в списке 
>> устанавливаемых пакетов он все-равно вылезает.
> 
> Относительно свежий buildreq умеет оптимизировать список вычисленных
> сборочных зависимостей.  Насколько я понимаю, с ним ваш эксперимент
> повторить не получится.

	А при чем тут собственно сам buildreq? Если я выбросил скажем тот же 
проклятый qt3/4-settings из BuildRequires и собираю пакет в хашере - apt 
все-равно мне эту приблуду по зависимостям втащит в хашер.

Re: [devel] buildreq += autoignore

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 01:00:06AM +0200, Motsyo Gennadi aka Drool wrote:
> Dmitry V. Levin пишет:
> >> 	А можна для расширения кругозора вопросец? Я тоже запускаю buildreq 
> >> внутри хашера, и если зацепил некоторый пакет - значит он был установлен 
> >> в системе и как-то кем-то дергался... Я экспериментировал - удалял некий 
> >> (скажем qt4(3)-settings) из BuildRequires и снова собирал - в списке 
> >> устанавливаемых пакетов он все-равно вылезает.
> > 
> > Относительно свежий buildreq умеет оптимизировать список вычисленных
> > сборочных зависимостей.  Насколько я понимаю, с ним ваш эксперимент
> > повторить не получится.
> 
> 	А при чем тут собственно сам buildreq? Если я выбросил скажем тот же 
> проклятый qt3/4-settings из BuildRequires и собираю пакет в хашере - apt 
> все-равно мне эту приблуду по зависимостям втащит в хашер.

Давно это было?  buildreq теперь сам должен выбросить этот проклятый
qt-settings, причем (почти) в тех же самых случаях, когда apt "всё
равно" решит его поставить.  buildreq оптимизирует все транзитивные
зависимости, но не более чем через один хоп.  То есть без полного
транзитивного замыкания.  Одного хопа хватает в большинстве разумных
случаев; но не во всех.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070320 01:48]:
> Raorn, на этот раз ты не угадал.
BTW, правильная капитализация - "raorn", даже в начале
предложения ;-)

> Если верить списку рассылки git-update (а чему же ещё верить,
> если не фактам), то в каталогах
> /people/mithraen/packages/postgresql8.1.git и
> /people/mithraen/packages/postgresql8.0.git 17-го марта были заметные
> обновления.
Которые не затрагивали postgresql.init.in и не теряли моих
коммитов.  Что можно проверить посмотрев на строки "commit" и
"Changes statistics since"...  Или я не умею читать git-commits,
или при переписывании коммита он не всегда пишет "since common
ancestor".

Впрочем, спор довольно гнилой.  Меня просто задела фраза "Дык
возрадуйся, что я на них СЛУЧАЙНО наткнулся! :)", пусть даже и со
смайлом.  :-/

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Денис Смирнов]

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

On Tue, Mar 20, 2007 at 02:23:46AM +0300, Alexey I. Froloff wrote:

>> Если верить списку рассылки git-update (а чему же ещё верить,
>> если не фактам), то в каталогах
>> /people/mithraen/packages/postgresql8.1.git и
>> /people/mithraen/packages/postgresql8.0.git 17-го марта были заметные
>> обновления.
AIF> Которые не затрагивали postgresql.init.in и не теряли моих
AIF> коммитов.  Что можно проверить посмотрев на строки "commit" и
AIF> "Changes statistics since"...  Или я не умею читать git-commits,
AIF> или при переписывании коммита он не всегда пишет "since common
AIF> ancestor".

Все веселее. В случае с 8.1 не был сделан вообще git push, видимо.  А вот
с 8.0, так как Иван уже выложил сборку не на базе моей, мне пришлось не
только делать push, но и переписывать историю.

Как оказалось:
 - tags не были залиты чуть ли не для половины моих пакетов
 - просто не были залиты очень многие пакеты. 

Так что в данной ситуации git'ом не умеет пользоваться именно некий mithraen@

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<shulik> что значит в спеке: %force_disable
<Ktirf> shulik: Отключение использования Великой Силы.

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

Re: [devel] [JT] python policy и отношение к коллегам

[Ivan Fedorov]

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

Денис Смирнов пишет:
> On Tue, Mar 20, 2007 at 02:23:46AM +0300, Alexey I. Froloff wrote:
> 
>>> Если верить списку рассылки git-update (а чему же ещё верить,
>>> если не фактам), то в каталогах
>>> /people/mithraen/packages/postgresql8.1.git и
>>> /people/mithraen/packages/postgresql8.0.git 17-го марта были заметные
>>> обновления.
> AIF> Которые не затрагивали postgresql.init.in и не теряли моих
> AIF> коммитов.  Что можно проверить посмотрев на строки "commit" и
> AIF> "Changes statistics since"...  Или я не умею читать git-commits,
> AIF> или при переписывании коммита он не всегда пишет "since common
> AIF> ancestor".
> 
> Все веселее. В случае с 8.1 не был сделан вообще git push, видимо.  А вот
> с 8.0, так как Иван уже выложил сборку не на базе моей, мне пришлось не
> только делать push, но и переписывать историю.
Ээээ... может наоборот? Я 8.0 вообще не трогал!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] [JT] python policy и отношение к коллегам

[Денис Смирнов]

On Tue, Mar 20, 2007 at 05:16:53PM +0800, Ivan Fedorov wrote:

>> Все веселее. В случае с 8.1 не был сделан вообще git push, видимо.  А вот
>> с 8.0, так как Иван уже выложил сборку не на базе моей, мне пришлось не
>> только делать push, но и переписывать историю.
IF> Ээээ... может наоборот? Я 8.0 вообще не трогал!

Ща проверю...

Да, история была переписана для 8.1, а в 8.0 тебя с мая прошлого года не
видно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Чтобы найти библиотеку, надо знать, где ее искать.
		-- wrar in community@

Re: [devel] buildreq += autoignore

[Igor Zubkov]

В сообщении от Tuesday 20 March 2007 00:34:25 Michael Shigorin написал(а):
> On Tue, Mar 20, 2007 at 01:28:36AM +0300, Dmitry V. Levin wrote:
> > Вопрос: а зачем autoignore потребовался вам?
>
> "глядя на комментарии в нескольких спеках".
>
> OK, со своей стороны вопрос считаю зарытым до более внятного
> обоснования, что там были жуткие по весу и ненужности добавления.
> Скорее всего, это навсегда. :)

У меня buildreq зачем-то цепляет ко всем кедовым шишкам kde-i18n-ru и все 
оставльные kde-i18n что установлены в системе. Приходится руками выносить. 
Может их добавить в игнор лист?

-- 
icesik

Re: [devel] buildreq += autoignore

[Alexey Tourbin]

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

On Tue, Mar 20, 2007 at 07:11:46PM +0200, Igor Zubkov wrote:
> В сообщении от Tuesday 20 March 2007 00:34:25 Michael Shigorin написал(а):
> > On Tue, Mar 20, 2007 at 01:28:36AM +0300, Dmitry V. Levin wrote:
> > > Вопрос: а зачем autoignore потребовался вам?
> >
> > "глядя на комментарии в нескольких спеках".
> >
> > OK, со своей стороны вопрос считаю зарытым до более внятного
> > обоснования, что там были жуткие по весу и ненужности добавления.
> > Скорее всего, это навсегда. :)
> 
> У меня buildreq зачем-то цепляет ко всем кедовым шишкам kde-i18n-ru и все 
> оставльные kde-i18n что установлены в системе. Приходится руками выносить. 
> Может их добавить в игнор лист?

Какие именно файлы используются?  Попробуйте собрать мой rpm-uilts.git и
сделать buildreq --trace-package=kde-i18n-ru.  Возможно что там вполне
конкретные файлы цепляются, а не все сразу, тогда можно что-нибудь
положить в /etc/buildreqs/files/ignore.d/.

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

Re: [devel] buildreq += autoignore

[Igor Zubkov]

В сообщении от Tuesday 20 March 2007 19:13:54 Alexey Tourbin написал(а):
> Какие именно файлы используются?  Попробуйте собрать мой rpm-uilts.git и
> сделать buildreq --trace-package=kde-i18n-ru.  Возможно что там вполне
> конкретные файлы цепляются, а не все сразу, тогда можно что-нибудь
> положить в /etc/buildreqs/files/ignore.d/.

Вечером попробую. Нужен только твой свежий rpm-utils? Или ещё что-то надо 
пересобрать?

-- 
icesik

[devel] [FR] buildreq: non-pruned deps as a spec comment

[Michael Shigorin]

On Tue, Mar 20, 2007 at 12:36:12AM +0300, Alexey Tourbin wrote:
> Короче: buildreq не ошибается.  Как распилили так он и показывает.
> What you see is what you get.

Лёш, ещё один фичреквест по buildreq (пока отпиливал libaudio от
TiMidity++, сформулировал).

Возможно ли "сырую" строку зависимостей совать в спек как
комментарий?  Мне пришлось добавить jackit-devel libalsa-devel,
убрав libaudio-devel, за которой прятались и они.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] buildreq: non-pruned deps as a spec comment

[Alexey Tourbin]

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

On Fri, Mar 30, 2007 at 01:26:01AM +0300, Michael Shigorin wrote:
> Лёш, ещё один фичреквест по buildreq (пока отпиливал libaudio от
> TiMidity++, сформулировал).
> 
> Возможно ли "сырую" строку зависимостей совать в спек как
> комментарий?  Мне пришлось добавить jackit-devel libalsa-devel,
> убрав libaudio-devel, за которой прятались и они.

Сырая строка слишком большая, будет как почти как в suse.
С оптимизацией в общем виде нельзя ничего сделать, я уже немного об этом
писал.  Любая корректная оптимизация будет в некоторых случаях слишком
сильной.  По сути нельзя редактировать результат buildreq вручную.

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

Re: [devel] buildreq: non-pruned deps as a spec comment

[Michael Shigorin]

On Fri, Mar 30, 2007 at 02:51:35AM +0400, Alexey Tourbin wrote:
> > Лёш, ещё один фичреквест по buildreq (пока отпиливал libaudio от
> > TiMidity++, сформулировал).
> > Возможно ли "сырую" строку зависимостей совать в спек как
> > комментарий?  Мне пришлось добавить jackit-devel libalsa-devel,
> > убрав libaudio-devel, за которой прятались и они.
> Сырая строка слишком большая, будет как почти как в suse.

Догадываюсь... а с ключиком каким "я-знаю-что-прошу"?

> С оптимизацией в общем виде нельзя ничего сделать, я уже
> немного об этом писал.  Любая корректная оптимизация будет
> в некоторых случаях слишком сильной.  По сути нельзя
> редактировать результат buildreq вручную.

Обычно и дописываю отдельное отдельно, но use case привёл,
когда было бы понятнее |grep jack, чем лезть в contents_index
(это при том, что он под рукой есть).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/