[devel] Python 2.6: task #16528

[devel] Python 2.6: task #16528

[REAL]

Привет!

Поскольку сборка более 600 пакетов - дело очень долгое (на сборку не 
самых монстроидальных 200 пакетов потребовалось около 12 часов), 
возможно, я попытаюсь в этой задаче всё собирать до упора, таким 
образом, надеюсь, именно она и станет рабочей, из которой в сизиф 
пролезет python 2.6.

Чтобы дело пошло быстрее (сбои ещё будут, т.к. там не все пакеты), 
большая просьба пакеты из задачи пока не обновлять, чтобы потом не 
пришлось начинать сборку заново.

http://git.altlinux.org/tasks/16528/task/log.2

Это пока не относится к пакетам, которые ещё не добавлены (но уже 
обнаружены, и я сейчас снова буду приставать в личке на предмет nmu, 
не считая тех, с мейнтейнерами которых есть договорённость на task 
approve):

libtorrent-rasterbar0.15
SNNS
Tartarus-core
connexion
exo
gnome-applets-extra-deskbar
gtk-vnc
gwyddion
hk_classes
kde4bindings
krb5user
ktoblzcheck
lash
libat-spi
libbeagle
libbtctl
libcomedi
libgpod4
libgsf
libgtkhst
libomniORB
libopensync
libopensync0
libprelude
libpreludedb
libproxy
librapi
librra
libselinux
libtelepathy-farsight
libtunepimp
libzebra_barcode
moin
neatx
nicotine-plus
olpcsound
phatch
qzion
samba
spe
speech-dispatcher
trac
vte
wesnoth
xscript

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 02:12:13PM +0700, REAL wrote:
> Привет!
> 
> Поскольку сборка более 600 пакетов - дело 
> очень долгое (на сборку не самых 
> монстроидальных 200 пакетов 
> потребовалось около 12 часов), возможно, я 
> попытаюсь в этой задаче всё собирать до 
> упора, таким образом, надеюсь, именно она 
> и станет рабочей, из которой в сизиф 
> пролезет python 2.6.

А чем закончилась история с "двумя питонами", ну там на тему
/usr/bin/python2.X и /usr/bin/python2.Y.  Кто кого?

Если от двух питонов решили отказаться, то есть смысл изменить
зависимости вида python2.X(...) на просто python(...).  Потому
что скрипты на питоне по идее не зависят от версии питона.
А модули получат зависимости на версионированный каталог и/или
на версионированный питоновский сонейм.

> Чтобы дело пошло быстрее (сбои ещё будут, 
> т.к. там не все пакеты), большая просьба 
> пакеты из задачи пока не обновлять, чтобы 
> потом не пришлось начинать сборку заново.
> 
> http://git.altlinux.org/tasks/16528/task/log.2

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> А чем закончилась история с "двумя питонами", ну там на тему
> /usr/bin/python2.X и /usr/bin/python2.Y.  Кто кого?

Не знаю, этим sin@ занимался, и вроде как до сих пор занимается на 
git.eter. Впрочем, там и карманы есть, а вот когда они будут на 
git.alt, неизвестно.

> Если от двух питонов решили отказаться, то есть смысл изменить
> зависимости вида python2.X(...) на просто python(...).  Потому
> что скрипты на питоне по идее не зависят от версии питона.
> А модули получат зависимости на версионированный каталог и/или
> на версионированный питоновский сонейм.

Здесь ничего не могу ни сказать, ни сделать. Самим питоном всё-таки 
sin@ занимается, а тут так, погулять вышел да пересобрать пакеты под 
него...

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 03:00:24PM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >А чем закончилась история с "двумя 
> >питонами", ну там на тему
> >/usr/bin/python2.X и /usr/bin/python2.Y.  Кто кого?
> 
> Не знаю, этим sin@ занимался, и вроде как до 
> сих пор занимается на git.eter. Впрочем, там и 
> карманы есть, а вот когда они будут на 
> git.alt, неизвестно.
> 
> >Если от двух питонов решили отказаться, 
> >то есть смысл изменить
> >зависимости вида python2.X(...) на просто 
> >python(...).  Потому
> >что скрипты на питоне по идее не зависят 
> >от версии питона.
> >А модули получат зависимости на 
> >версионированный каталог и/или
> >на версионированный питоновский сонейм.
> 
> Здесь ничего не могу ни сказать, ни 
> сделать. Самим питоном всё-таки sin@ 
> занимается, а тут так, погулять вышел да 
> пересобрать пакеты под него...

В общем получается дискутировать смысла нет -- делай кто что хочешь,
вроде как хуже уже не будет. :)

Собираюсь в rpm-build-python поменять зависимости python2.5(...)
на python(...) вместо python2.6(...).

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> В общем получается дискутировать смысла нет -- делай кто что хочешь,
> вроде как хуже уже не будет. :)

Смотря что и когда делать.

> Собираюсь в rpm-build-python поменять зависимости python2.5(...)
> на python(...) вместо python2.6(...).

Может быть, не сейчас? Я больше недели назад и здесь, и лично 
обращался, но даже nmu не получил на Ваши пакеты. А сейчас, когда 
задача уже в работе, новые правила всё потраченное на сборку время 
коту под хвост пустят. Её ж _полностью_ заново придётся 
переформировывать и пересобирать... Так мы и к весне не управимся, 
если будет в последний момент менять ключевые правила.

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 03:16:36PM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >В общем получается дискутировать смысла 
> >нет -- делай кто что хочешь,
> >вроде как хуже уже не будет. :)
> 
> Смотря что и когда делать.
> 
> >Собираюсь в rpm-build-python поменять 
> >зависимости python2.5(...)
> >на python(...) вместо python2.6(...).
> 
> Может быть, не сейчас? Я больше недели 
> назад и здесь, и лично обращался, но даже 
> nmu не получил на Ваши пакеты. А сейчас, 
> когда задача уже в работе, новые правила 
> всё потраченное на сборку время коту под 
> хвост пустят. Её ж _полностью_ заново 
> придётся переформировывать и 
> пересобирать... Так мы и к весне не 
> управимся, если будет в последний момент 
> менять ключевые правила.

Нет, переформировывать не придётся (но придётся пересобирать, т.е. не
будет "no need to rebuild).  Просто я залью rpm-build-python отдельным
заданием.

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> Нет, переформировывать не придётся (но придётся пересобирать, т.е. не
> будет "no need to rebuild).  Просто я залью rpm-build-python отдельным
> заданием.

Ужасно.

PS. Теперь, получается, двух питонов в сизифе больше никогда не будет? 
ну ладно, не очень и хотелось :)

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 03:22:43PM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >Нет, переформировывать не придётся (но 
> >придётся пересобирать, т.е. не
> >будет "no need to rebuild).  Просто я залью 
> >rpm-build-python отдельным
> >заданием.
> 
> Ужасно.

К сожалению у людишек в спекфайлах закодированы зависимости вида
python%__python_version(...).  Так что наверное отбой.

[at@people specs]$ LC_ALL=C fgrep 'python%__python_version(' *
Tartarus-core.spec:Requires: python%__python_version(sqlite)
Tartarus-core.spec:Requires: python%__python_version(sqlite3)
blender.spec:Provides: python%__python_version(Blender)
bombono-dvd.spec:Provides: python%__python_version(ASettings)
clearsilver.spec:Provides: python%__python_version(neo_cgi)
clearsilver.spec:Provides: python%__python_version(neo_cs)
clearsilver.spec:Provides: python%__python_version(neo_util)
dolfin.spec:Requires: python%__python_version(viper)
eog.spec:Provides: python%__python_version(eog)
epiphany.spec:Provides: python%__python_version(epiphany)
freeorion.spec:Provides: python%__python_version(freeOrionAIInterface)
gDesklets.spec:Requires: python%__python_version(libglade)
gDesklets.spec:Requires: python%__python_version(bonobo)
gDesklets.spec:Requires: python%__python_version(gnomecanvas)
gDesklets.spec:Requires: python%__python_version(gconf)
gDesklets.spec:Requires: python%__python_version(ORBit)
gcompris.spec:Requires: python%__python_version(gnomecanvas) python%__python_version(pygtk) python%__python_version(cairo) python%__python_version(gnome) python%__python_version(pysqlite2)
gcompris.spec:Provides: python%__python_version(_gcompris) python%__python_version(_gcompris_anim) python%__python_version(_gcompris_bonus)
gcompris.spec:Provides: python%__python_version(_gcompris_score) python%__python_version(_gcompris_skin) python%__python_version(_gcompris_sound)
gcompris.spec:Provides: python%__python_version(_gcompris_timer) python%__python_version(_gcompris_utils)
gcompris.spec:Provides: python%__python_version(_gcompris_admin) python%__python_version(gcompris) python%__python_version(DTW)
gjots2.spec:Requires: python%__python_version(libglade) python%__python_version(bonobo)
gnochm.spec:Requires: python%__python_version(libglade)
gnochm.spec:Requires: python%__python_version(bonobo)
gnumeric.spec:Provides: python%__python_version(Gnumeric)
gnumeric.spec:Provides: python%__python_version(gsf)
gogh.spec:Requires: python%__python_version(libglade)
gogh.spec:# python%__python_version(PyXML)
gramps.spec:Requires: python%__python_version(libglade)
gramps.spec:Requires: python%__python_version(bonobo)
gramps.spec:Requires: python%__python_version(gnomecanvas)
gramps.spec:Requires: python%__python_version(gconf)
jokosher.spec:Requires: python%__python_version(libglade)
[at@people specs]$ 

> PS. Теперь, получается, двух питонов в 
> сизифе больше никогда не будет? ну ладно, 
> не очень и хотелось :)

Уж лучше отрастить себе две штуки это самое...

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

Re: [devel] Python 2.6: task #16528

[Andrey Rahmatullin]

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

On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> К сожалению у людишек в спекфайлах закодированы зависимости вида
> python%__python_version(...).  Так что наверное отбой.
Хихихи, ну да, полиси не читали даже тогда, когда оно ещё соответствовало
действительности и у него был автор.

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

>Еще будут категорические заявления? А?
[...] заявления, видимо, будут, поскольку я их делаю,
не всегда обладая полной информацией о том, что они не
могут быть опровергнуты :)
		-- lav in sisyphus@

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 02:33:58PM +0500, Andrey Rahmatullin wrote:
> On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> > К сожалению у людишек в спекфайлах закодированы зависимости вида
> > python%__python_version(...).  Так что наверное отбой.
> Хихихи, ну да, полиси не читали даже тогда, когда оно ещё соответствовало
> действительности и у него был автор.

Кроме того, нашлось два пакета, где закодены зависимости вида
python2.5(...).  Приз зрительских симпатий.

[at@people specs]$ fgrep 'python2.5(' *.spec
moin.spec:Requires: python2.5(locale) python-module-MoinMoin python-module-moin-jabberbot
ocfs2-tools.spec:Provides: python2.5(o2cb), python2.5(ocfs2), python2.5(plist)
python-module-paste.spec:# hack for autocreate "provides python2.5(paste)"
rpm-build-python.spec:  PIL/Image.py provides both python2.5(PIL.Image) due to PIL/__init__.py
rpm-build-python.spec:  and python2.5(Image) due to PIL.pth.
[at@people specs]$ 

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

Re: [devel] Python 2.6: task #16528

[Igor Vlasenko]

On Wed, Nov 25, 2009 at 10:50:34PM +0300, Alexey Tourbin wrote:
> On Wed, Nov 25, 2009 at 02:33:58PM +0500, Andrey Rahmatullin wrote:
> > On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> > > К сожалению у людишек в спекфайлах закодированы зависимости вида
> > > python%__python_version(...).  Так что наверное отбой.
> > Хихихи, ну да, полиси не читали даже тогда, когда оно ещё соответствовало
> > действительности и у него был автор.
> 
> Кроме того, нашлось два пакета, где закодены зависимости вида
> python2.5(...).  Приз зрительских симпатий.
> 
> [at@people specs]$ fgrep 'python2.5(' *.spec
> moin.spec:Requires: python2.5(locale) python-module-MoinMoin python-module-moin-jabberbot
> ocfs2-tools.spec:Provides: python2.5(o2cb), python2.5(ocfs2), python2.5(plist)
> python-module-paste.spec:# hack for autocreate "provides python2.5(paste)"
> rpm-build-python.spec:  PIL/Image.py provides both python2.5(PIL.Image) due to PIL/__init__.py
> rpm-build-python.spec:  and python2.5(Image) due to PIL.pth.
> [at@people specs]$ 

Не будет возражений,
если репокоп станет расстреливать такие пакеты из рогатки?


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Python 2.6: task #16528

[Igor Vlasenko]

On Wed, Nov 25, 2009 at 10:04:09PM +0200, Igor Vlasenko wrote:
> On Wed, Nov 25, 2009 at 10:50:34PM +0300, Alexey Tourbin wrote:
> > On Wed, Nov 25, 2009 at 02:33:58PM +0500, Andrey Rahmatullin wrote:
> > > On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> > > > К сожалению у людишек в спекфайлах закодированы зависимости вида
> > > > python%__python_version(...).  Так что наверное отбой.
> > > Хихихи, ну да, полиси не читали даже тогда, когда оно ещё соответствовало
> > > действительности и у него был автор.
> > 
> > Кроме того, нашлось два пакета, где закодены зависимости вида
> > python2.5(...).  Приз зрительских симпатий.
> > 
> > [at@people specs]$ fgrep 'python2.5(' *.spec
> > moin.spec:Requires: python2.5(locale) python-module-MoinMoin python-module-moin-jabberbot
> > ocfs2-tools.spec:Provides: python2.5(o2cb), python2.5(ocfs2), python2.5(plist)
> > python-module-paste.spec:# hack for autocreate "provides python2.5(paste)"
> > rpm-build-python.spec:  PIL/Image.py provides both python2.5(PIL.Image) due to PIL/__init__.py
> > rpm-build-python.spec:  and python2.5(Image) due to PIL.pth.
> > [at@people specs]$ 
> 
> Не будет возражений,
> если репокоп станет расстреливать такие пакеты из рогатки?

Но за что их расстреливать?
По хорошему надо сначала разжевать
этот случай в Python policy. 
что здесь плохо и как исправить, а потом писать тест :(
Плохо, что питон у нас в беззаконии.
Старое полиси не соблюдается,
а нового не написано.

Кого и за что судить, не понятно :(

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 11:37:40PM +0200, Igor Vlasenko wrote:
> On Wed, Nov 25, 2009 at 10:04:09PM +0200, Igor Vlasenko wrote:
> > On Wed, Nov 25, 2009 at 10:50:34PM +0300, Alexey Tourbin wrote:
> > > On Wed, Nov 25, 2009 at 02:33:58PM +0500, Andrey Rahmatullin wrote:
> > > > On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> > > > > К сожалению у людишек в спекфайлах закодированы зависимости вида
> > > > > python%__python_version(...).  Так что наверное отбой.
> > > > Хихихи, ну да, полиси не читали даже тогда, когда оно ещё соответствовало
> > > > действительности и у него был автор.
> > > 
> > > Кроме того, нашлось два пакета, где закодены зависимости вида
> > > python2.5(...).  Приз зрительских симпатий.
> > > 
> > > [at@people specs]$ fgrep 'python2.5(' *.spec
> > > moin.spec:Requires: python2.5(locale) python-module-MoinMoin python-module-moin-jabberbot
> > > ocfs2-tools.spec:Provides: python2.5(o2cb), python2.5(ocfs2), python2.5(plist)
> > > python-module-paste.spec:# hack for autocreate "provides python2.5(paste)"
> > > rpm-build-python.spec:  PIL/Image.py provides both python2.5(PIL.Image) due to PIL/__init__.py
> > > rpm-build-python.spec:  and python2.5(Image) due to PIL.pth.
> > > [at@people specs]$ 
> > 
> > Не будет возражений,
> > если репокоп станет расстреливать такие пакеты из рогатки?
> 
> Но за что их расстреливать?
> По хорошему надо сначала разжевать
> этот случай в Python policy. 
> что здесь плохо и как исправить, а потом писать тест :(
> Плохо, что питон у нас в беззаконии.
> Старое полиси не соблюдается,
> а нового не написано.

Есть вроде макросы %py_requires и %py_provides.

# py_requires <имя_модуля1> [<имя_модуля2> ...]
#
#	Добавляет зависимость на указанные модули python. Формируемые
# 	зависимости имеют вид: pythonX.Y(имя_модуля1) [pythonX.Y(имя_модуля2)...]
# 	где X.Y - текущая (выбранная) версия python
#
%py_requires() \
%(echo -n "Requires:"; %{expand: %%__python_deps_internal %{*}}) \
%nil

Только мне этот макрос не очень нравится потому что он портит структуру
speс-файла (то есть раскрывается в таг Requires, а не просто подставляет
названия зависимостей).  Это также делает невозможным Requires(pre) и т.п.

> Кого и за что судить, не понятно :(

Лучше всего отказаться от двух питонов и чтобы зависимости имели вид
python(...).  Тогда и судть было бо не за что, потому что нету порочных
вариаций на тему выбора.  Там в общем баталии были нешуточные, в итоге
сказали что у Алексея Турбина непрофессианализм в одном месте.

Надо бо конечно сделать всё по-своему.  Но боюсь у меня теперь стамины
не хватит чтобы из всех сил дрючить питон бесконечное количество времени.

> -- 
> 
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine

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

Re: [devel] Python 2.6: task #16528

[Igor Vlasenko]

On Thu, Nov 26, 2009 at 01:02:37AM +0300, Alexey Tourbin wrote:
> Есть вроде макросы %py_requires и %py_provides.
> 
> # py_requires <имя_модуля1> [<имя_модуля2> ...]
> #
> #	Добавляет зависимость на указанные модули python. Формируемые
> # 	зависимости имеют вид: pythonX.Y(имя_модуля1) [pythonX.Y(имя_модуля2)...]
> # 	где X.Y - текущая (выбранная) версия python
> #
> %py_requires() \
> %(echo -n "Requires:"; %{expand: %%__python_deps_internal %{*}}) \
> %nil
> 
> Только мне этот макрос не очень нравится потому что он портит структуру
> speс-файла (то есть раскрывается в таг Requires, а не просто подставляет
> названия зависимостей).  Это также делает невозможным Requires(pre) и т.п.

Можно ввести правильный макрос, назвать, например, %py_deps


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Thu, Nov 26, 2009 at 11:04:50AM +0200, Igor Vlasenko wrote:
> On Thu, Nov 26, 2009 at 01:02:37AM +0300, Alexey Tourbin wrote:
> > Есть вроде макросы %py_requires и %py_provides.
> > 
> > # py_requires <имя_модуля1> [<имя_модуля2> ...]
> > #
> > #	Добавляет зависимость на указанные модули python. Формируемые
> > # 	зависимости имеют вид: pythonX.Y(имя_модуля1) [pythonX.Y(имя_модуля2)...]
> > # 	где X.Y - текущая (выбранная) версия python
> > #
> > %py_requires() \
> > %(echo -n "Requires:"; %{expand: %%__python_deps_internal %{*}}) \
> > %nil
> > 
> > Только мне этот макрос не очень нравится потому что он портит структуру
> > speс-файла (то есть раскрывается в таг Requires, а не просто подставляет
> > названия зависимостей).  Это также делает невозможным Requires(pre) и т.п.
> 
> Можно ввести правильный макрос, назвать, например, %py_deps

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

С точки зрения "как правильно" мне надо кажется сделать неймспейс
python(...), тогда всё остальное отпадает, а макросы не нужны.

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

Re: [devel] Python 2.6: task #16528

[Igor Vlasenko]

On Thu, Nov 26, 2009 at 12:18:30PM +0300, Alexey Tourbin wrote:
> > Можно ввести правильный макрос, назвать, например, %py_deps
> 
> Можно-то можно, сейчас лучше человека не обламывать чтобы у него
> побыстрее проскочил питон-2.6.  Потому что кто ещё это всё раз захочет.

Конечно.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Python 2.6: task #16528

[Alexey Morsov]

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

On Wed, Nov 25, 2009 at 11:44:19AM +0300, Alexey Tourbin wrote:
> gnumeric.spec:Provides: python%__python_version(Gnumeric)
> gnumeric.spec:Provides: python%__python_version(gsf)
Ошметки.. проглядел. Выгрызу.

-- 
WBR,
Alexey Morsov
программист ЗАО "ИК "Риком-Траст"
Jabber: samurai@www.fondmarket.ru
ALT Linux Team Member

Нет, не забросил. Я его специально не собираю.
		-- rider in devel@

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

Re: [devel] Python 2.6: task #16528

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

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

On Wed, Nov 25, 2009 at 10:54:55AM +0300, Алексей Турбин wrote:

AT> Собираюсь в rpm-build-python поменять зависимости python2.5(...)
AT> на python(...) вместо python2.6(...).

Зачем ломать, если параллельно сейчас ведется работа по поддержке двух
питонов на git.eter?

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 11:23:41AM +0300, Денис Смирнов wrote:
> On Wed, Nov 25, 2009 at 10:54:55AM +0300, Алексей Турбин wrote:
> 
> AT> Собираюсь в rpm-build-python поменять зависимости python2.5(...)
> AT> на python(...) вместо python2.6(...).
> 
> Зачем ломать, если параллельно сейчас ведется работа по поддержке двух
> питонов на git.eter?

Я думаю что эту поддержку хорошо сделать невозможно.

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

Re: [devel] Python 2.6: task #16528

[Michael Shigorin]

On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> Если от двух питонов решили отказаться, то есть смысл изменить
> зависимости вида python2.X(...) на просто python(...).  Потому
> что скрипты на питоне по идее не зависят от версии питона.

Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > Если от двух питонов решили отказаться, то есть смысл изменить
> > зависимости вида python2.X(...) на просто python(...).  Потому
> > что скрипты на питоне по идее не зависят от версии питона.
> 
> Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.

python2.5 -> python2.6 пакеты пересобираются as is.
Почему у отдельно взятого скрипта должны измениться зависимости
на питон, если сам скрипт не изменился?

Фактически же часть пакетов сейчас пересобирается почему?
Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
А в остальном в этих пакетах ничего не меняется.

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

Re: [devel] Python 2.6: task #16528

[Led]

On Sunday, 29 November 2009 02:51:52 Alexey Tourbin wrote:
> On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> > On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > > Если от двух питонов решили отказаться, то есть смысл изменить
> > > зависимости вида python2.X(...) на просто python(...).  Потому
> > > что скрипты на питоне по идее не зависят от версии питона.
> >
> > Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.
>
> python2.5 -> python2.6 пакеты пересобираются as is.
> Почему у отдельно взятого скрипта должны измениться зависимости
> на питон, если сам скрипт не изменился?
>
> Фактически же часть пакетов сейчас пересобирается почему?
> Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> А в остальном в этих пакетах ничего не меняется.

*.pyc меняются

-- 
Led

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Sun, Nov 29, 2009 at 03:14:13AM +0200, Led wrote:
> On Sunday, 29 November 2009 02:51:52 Alexey Tourbin wrote:
> > On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> > > On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > > > Если от двух питонов решили отказаться, то есть смысл изменить
> > > > зависимости вида python2.X(...) на просто python(...).  Потому
> > > > что скрипты на питоне по идее не зависят от версии питона.
> > >
> > > Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.
> >
> > python2.5 -> python2.6 пакеты пересобираются as is.
> > Почему у отдельно взятого скрипта должны измениться зависимости
> > на питон, если сам скрипт не изменился?
> >
> > Фактически же часть пакетов сейчас пересобирается почему?
> > Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> > А в остальном в этих пакетах ничего не меняется.
> 
> *.pyc меняются

Если это очень одинокий скрипт то у него *.pyc нету.
Например /usr/bin/asciidoc.

Сейчас кстати *.pyc вообще не создает зависимостей.  Зато создаются
зависимости на /usr/lib/python2.5/site-packages и libpython2.5.so.1 (для
всех питоновских модулей, которые становятся в стандартный каталог и/или
компилируются).  То есть теперь имеются другие достаточно надёжные
способы обеспечить физическую целостность питновского хозяйства при
миграции на новый питон.  И они включаются как раз тогда когда надо.

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

Re: [devel] Python 2.6: task #16528

[Led]

On Sunday, 29 November 2009 03:32:02 Alexey Tourbin wrote:
> On Sun, Nov 29, 2009 at 03:14:13AM +0200, Led wrote:
> > On Sunday, 29 November 2009 02:51:52 Alexey Tourbin wrote:
> > > On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> > > > On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > > > > Если от двух питонов решили отказаться, то есть смысл изменить
> > > > > зависимости вида python2.X(...) на просто python(...).  Потому
> > > > > что скрипты на питоне по идее не зависят от версии питона.
> > > >
> > > > Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.
> > >
> > > python2.5 -> python2.6 пакеты пересобираются as is.
> > > Почему у отдельно взятого скрипта должны измениться зависимости
> > > на питон, если сам скрипт не изменился?
> > >
> > > Фактически же часть пакетов сейчас пересобирается почему?
> > > Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> > > А в остальном в этих пакетах ничего не меняется.
> >
> > *.pyc меняются
>
> Если это очень одинокий скрипт то у него *.pyc нету.
> Например /usr/bin/asciidoc.
>
> Сейчас кстати *.pyc вообще не создает зависимостей.  Зато создаются
> зависимости на /usr/lib/python2.5/site-packages и libpython2.5.so.1 (для
> всех питоновских модулей, которые становятся в стандартный каталог и/или
> компилируются).  То есть теперь имеются другие достаточно надёжные
> способы обеспечить физическую целостность питновского хозяйства при
> миграции на новый питон.  И они включаются как раз тогда когда надо.

Дело не в зависимостях. Если *.pyc не перекомпилированы, а интерпритатор 
сменил версию (2.5 -> 2.6), то *.pyc превращаются в неиспользуемый балласт 
(AFAIR).

-- 
Led

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Sun, Nov 29, 2009 at 03:38:53AM +0200, Led wrote:
> On Sunday, 29 November 2009 03:32:02 Alexey Tourbin wrote:
> > On Sun, Nov 29, 2009 at 03:14:13AM +0200, Led wrote:
> > > On Sunday, 29 November 2009 02:51:52 Alexey Tourbin wrote:
> > > > On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> > > > > On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > > > > > Если от двух питонов решили отказаться, то есть смысл изменить
> > > > > > зависимости вида python2.X(...) на просто python(...).  Потому
> > > > > > что скрипты на питоне по идее не зависят от версии питона.
> > > > >
> > > > > Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.
> > > >
> > > > python2.5 -> python2.6 пакеты пересобираются as is.
> > > > Почему у отдельно взятого скрипта должны измениться зависимости
> > > > на питон, если сам скрипт не изменился?
> > > >
> > > > Фактически же часть пакетов сейчас пересобирается почему?
> > > > Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> > > > А в остальном в этих пакетах ничего не меняется.
> > >
> > > *.pyc меняются
> >
> > Если это очень одинокий скрипт то у него *.pyc нету.
> > Например /usr/bin/asciidoc.
> >
> > Сейчас кстати *.pyc вообще не создает зависимостей.  Зато создаются
> > зависимости на /usr/lib/python2.5/site-packages и libpython2.5.so.1 (для
> > всех питоновских модулей, которые становятся в стандартный каталог и/или
> > компилируются).  То есть теперь имеются другие достаточно надёжные
> > способы обеспечить физическую целостность питновского хозяйства при
> > миграции на новый питон.  И они включаются как раз тогда когда надо.
> 
> Дело не в зависимостях. Если *.pyc не перекомпилированы, а интерпритатор 
> сменил версию (2.5 -> 2.6), то *.pyc превращаются в неиспользуемый балласт 
> (AFAIR).

Можно контролировать совместимость по *.pyc.  В *.pyc файле содержится
версия питона, для которой он подходит (напр. 2.5 или 2.6).  Тогда для
каждого *.pyс файла можно генерировать зависимость типа
Requires: python-bytecode-version = 2.5 (или 2.6).

Это открывает интересные возможности при миграции на новый питон.
А именно, на первой стадии пересборки новый питон может предоставлять
условную совместимость со старым байткодом:
Provides: python-bytecode-version = 2.5
Provides: python-bytecode-version = 2.6

Это позволяет быстрее провести переехать на новый питон, пересобрав
только те пакеты, которые действительно необходимо пересобрать (как
минимум по сонейму).  На второй стадии совместимость со старым питоном
удаляется, остаётся только
Provides: python-bytecode-version = 2.6

тогда потребуется пересобрать уже все пакеты со старым байткодом.

Можно пойти ещё дальше и попробовать сделать чтобы на первой стадии
новый питон поддерживал старый noarch каталог site-packages.

В любом случае это открывает более интересные возможности, чем просто
пересобрать _все_ пакеты которым _хоть что-то_ нужно от питона.
Даже очень одинокие скрипты.

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> python2.5 -> python2.6 пакеты пересобираются as is.

Не все. Некоторые .py приходится исправлять.

> Фактически же часть пакетов сейчас пересобирается почему?
> Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> А в остальном в этих пакетах ничего не меняется.

А есть те, у кого нужно поменять -lpython2.5 на -lpython2.6. Или 
-I%_includedir/python2.5 на -I%_includedir/python2.6.

В общем, не всё так просто.

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Mon, Nov 30, 2009 at 11:14:42AM +0700, REAL wrote:
> >python2.5 -> python2.6 пакеты пересобираются as is.
> 
> Не все. Некоторые .py приходится 
> исправлять.

То есть они по поиску зависимостей обламываются?  Хм.  Очень хорошо!
Я уже когда-то давно заметил что поиск зависимостей даёт не столько
зависимости сколько проверку синтаксиса при сборке.

В случае несовместимости конечно всё сложнее.  Но полной совместимости
не бывает (бывает только страховой полис).  Сколько пакетов пришлось
исправлять, навскидку?

> >Фактически же часть пакетов сейчас 
> >пересобирается почему?
> >Потому что надо чтобы у них поменялись 
> >зависимости с 2.5 на 2.6.
> >А в остальном в этих пакетах ничего не 
> >меняется.
> 
> А есть те, у кого нужно поменять -lpython2.5 на 
> -lpython2.6. Или -I%_includedir/python2.5 на -I%_includedir/python2.6.

Ну нет, я про что говорю.  Что если бы зависимости были вида python(...)
то были бо возможны более гибкие схемы миграции на новый питон.  На
первой стадии пришось бы пересобрать только то что слинковано с
сонеймом.  Короче долго объяснять.

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

> В общем, не всё так просто.

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> On Mon, Nov 30, 2009 at 11:14:42AM +0700, REAL wrote:
>>> python2.5 -> python2.6 пакеты пересобираются as is.
>> Не все. Некоторые .py приходится 
>> исправлять.
> 
> То есть они по поиску зависимостей обламываются?

Там, где используются ключевые слова (например, "as" или "with") в 
качестве имён.

> В случае несовместимости конечно всё сложнее.  Но полной совместимости
> не бывает (бывает только страховой полис).  Сколько пакетов пришлось
> исправлять, навскидку?

Насчёт ключевых слов? Я не помню, но порядка 10-20.

-- 

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

[devel] трансфёр гарантий

[Alexey Tourbin]

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

On Mon, Nov 30, 2009 at 11:50:36AM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >On Mon, Nov 30, 2009 at 11:14:42AM +0700, REAL wrote:
> >>>python2.5 -> python2.6 пакеты пересобираются as is.
> >>Не все. Некоторые .py приходится 
> >>исправлять.
> >
> >То есть они по поиску зависимостей 
> >обламываются?
> 
> Там, где используются ключевые слова 
> (например, "as" или "with") в качестве имён.

Вот смотрите.  При сборке пакета выполняются некоторые условия
(совместимости).  А когда пакет устанавливается то крайне желательно
чтобы эти зти же самые условия тоже выполнялись.  Но никаких гарантий
что те же самые условия выполняются -- нету.

Зависимости это один из способов (частично) решить проблему.
Если смотреть немного шире то фактически речь идёт о трансфёре
(передаче) гарантий.  При сборке ведь есть какие-то гарантии,
иначе просто не соберётся.  На установку надо "передать" гарантии
согласованности, которые были получены при сборке.

Это уже такой немного философский загон.  Но он может иметь большие
практические последствия.  Короче долго объяснять.  Подумайте.

> >В случае несовместимости конечно всё 
> >сложнее.  Но полной совместимости
> >не бывает (бывает только страховой 
> >полис).  Сколько пакетов пришлось
> >исправлять, навскидку?
> 
> Насчёт ключевых слов? Я не помню, но 
> порядка 10-20.

То есть вы 10-20 штук из 600 пакетов поправили, а остальные
пересобираются as is?  Ну это довольно хорошая совместимость.

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

Re: [devel] трансфёр гарантий

[REAL]

Alexey Tourbin пишет:
>> Насчёт ключевых слов? Я не помню, но 
>> порядка 10-20.
> 
> То есть вы 10-20 штук из 600 пакетов поправили, а остальные
> пересобираются as is?  Ну это довольно хорошая совместимость.

Поправлять пришлось больше, конечно, я чуть ранее уже говорил, почему. 
Но насчёт совместимости по коду в .py файлах да, процент правок 
действительно невелик.

-- 

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

Re: [devel] трансфёр гарантий

[Alexey Tourbin]

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

On Mon, Nov 30, 2009 at 12:13:12PM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >>Насчёт ключевых слов? Я не помню, но 
> >>порядка 10-20.
> >
> >То есть вы 10-20 штук из 600 пакетов 
> >поправили, а остальные
> >пересобираются as is?  Ну это довольно 
> >хорошая совместимость.
> 
> Поправлять пришлось больше, конечно, я 
> чуть ранее уже говорил, почему. Но насчёт 
> совместимости по коду в .py файлах да, 
> процент правок действительно невелик.

Хорошо.  Как нам обеспечить совместимость пакетов?
В широком смысле слова.  Допустим у нас есть несколько пакетов собрано
с питоном 2.5.  Можно ли считать в каком-то смысле что они будут
совместимы с питоном 2.6 (без пересборки, или с пересборкой)?

Есть там random walk theory которая по сути основывается на том что
будущее, вообще говоря, предсказать невозможно.  В частности эта теория
говорит о том что долгосрочные (успешные) спекуляции на рынке невозможны.

Как это относится к пакетам?  Собирая пакеты с питоном 2.5, мы ничего не
можем сказать про свойства этих пакетов в сочетании с питоном 2.6.  Это
приводит к абсурдному выводу, что обратная совместимость невозможна (как
если бо было лучше рассматривать питон 2.5 и 2.6 как два разных языка).

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

Re: [devel] трансфёр гарантий

[REAL]

Alexey Tourbin пишет:
> Хорошо.  Как нам обеспечить совместимость пакетов?
> В широком смысле слова.  Допустим у нас есть несколько пакетов собрано
> с питоном 2.5.  Можно ли считать в каком-то смысле что они будут
> совместимы с питоном 2.6 (без пересборки, или с пересборкой)?

С одной стороны, тут при тестовой пересборке должно быть многое ясно 
(как раз несовместимости по коду .py файлов). Но такое обычно особо 
нет смысла проверять ручной пересборкой, у нас есть хороший инструмент 
для вычисления таких проблем - еженедельная тестовая пересборка всего. 
С другой стороны, такие несовместимости при смене версии питона 
приводят к неработосбособности проблемных пакетов здесь и сейчас, что 
плохо (для тех, кто вместо dist-upgrade практикует точечные обновления).

Но необоходимость пересборки вообще всех пакетов, хоть какое-то 
отношение имеющих к питону, убивает наповал (одна бестолковая 
пересборка openoffice.org чего стоит). Неудивительно, что этим так 
никто и не захотел заниматься за прошедшие пол-года. Здесь всё 
упирается в зависимости вида python2.x(xxx) и 
/usr/lib[64]/python2.x/site-packages. Архитектурно это решение 
оправдано, на мой взгляд, _исключительно_ закладкой на будущее 
сосуществование нескольких питонов одновременно (кстати, похоже, ни 
один ныне существующий в сизифе пакет не будет работать с Python 3, но 
это уже отдельная тема).

То, что линкуется с libpython2.x.so, пересобрать пришлось бы в любом 
случае.

> Как это относится к пакетам?  Собирая пакеты с питоном 2.5, мы ничего не
> можем сказать про свойства этих пакетов в сочетании с питоном 2.6.  Это
> приводит к абсурдному выводу, что обратная совместимость невозможна (как
> если бо было лучше рассматривать питон 2.5 и 2.6 как два разных языка).

Здесь веселуха начинается в контексте рассмотрения питона 2.x и 3.0.

А насчёт 2.5 и 2.6 - изменяется набор пакетов. Если, например, удалить 
пакеты, которые при питоне 2.6 не нужны (стали частью самого питона, 
вроде python-module-simplejson или python-module-ssl), то при 
гипотетическом откате на 2.5 проблем будет много.

-- 

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

Re: [devel] трансфёр гарантий

[Sergey Alembekov]

On 30.11.2009 07:50, Alexey Tourbin wrote:

> То есть вы 10-20 штук из 600 пакетов поправили, а остальные
> пересобираются as is?  Ну это довольно хорошая совместимость.

Учитывайте ещё, что ещё некоторые мантейнеры готовились к переходу на 
2.6 и сами проверили свои пакеты ;)


-- 
Regards, Sergey Alembekov
ALTLinux Team
xmpp: rt@jabber.ru

Re: [devel] Python 2.6: task #16528

[Sergey Y. Afonin]

On Wednesday 25 November 2009, REAL wrote:

> Поскольку сборка более 600 пакетов - дело очень долгое

Мда, это не ClamAV обновить... :-) Может, всё-таки, разрешить
анметы в исключительных случаях ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Python 2.6: task #16528

[REAL]

Sergey Y. Afonin пишет:
>> Поскольку сборка более 600 пакетов - дело очень долгое
> 
> Мда, это не ClamAV обновить... :-) Может, всё-таки, разрешить
> анметы в исключительных случаях ?

В данном случае тут вообще всё разломается. В том смысле, что 
непересобранные пакеты все как один перестанут работать. И 
устанавливаться. Лови их потом по одному, причём, спорадически...

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Wed, Nov 25, 2009 at 02:12:13PM +0700, REAL wrote:
> Поскольку сборка более 600 пакетов - дело 
> очень долгое (на сборку не самых 
> монстроидальных 200 пакетов 
> потребовалось около 12 часов), возможно, я 
> попытаюсь в этой задаче всё собирать до 
> упора, таким образом, надеюсь, именно она 
> и станет рабочей, из которой в сизиф 
> пролезет python 2.6.
> 
> Чтобы дело пошло быстрее (сбои ещё будут, 
> т.к. там не все пакеты), большая просьба 
> пакеты из задачи пока не обновлять, чтобы 
> потом не пришлось начинать сборку заново.
> 
> http://git.altlinux.org/tasks/16528/task/log.2

У нас очень долго выполняется фаза "no need to rebuild", в среднем
не менее минуты на пакет.  Всё это конечно не планировалось что людишки
будут заливать пакеты целыми сотнями.  Но есть то что есть -- мы так
никуда не уедем.

$ GET http://git.altlinux.org/tasks/16528/task/log.4 |grep x86_64 |awk 'function sec(d){match(d,/([0-9][0-9]):([0-9][0-9]):([0-9][0-9])/,a); return a[1]*3600+a[2]*60+a[3] } /build start/{start=sec($2);name=$5} ;/no need to r/&&$5==name{print name,sec($2)-start}' |sort -k2n |tail -20
python-module-fiat.git 67
babel.git 70
petsc.git 70
scribus.git 70
python-module-matplotlib-0.99.0-alt2.1.src.rpm: 71
python-module-Crypto-2.0-alt2.1.1.1.src.rpm: 74
python-module-OpenSSL-0.6-alt2.1.1.1.1.1.src.rpm: 74
python.git 86
petsc.git 90
scons-1.1.0-alt1.1.src.rpm: 91
vim.git 91
postgresql8.3.git 123
libopencv.git 143
dblatex.git 167
slepc4py.git 203
petsc4py-complex-1.0.2-alt8.hg20091030.1.src.rpm: 212
slepc4py-real-1.0.0-alt6.hg20090916.1.src.rpm: 216
petsc4py-real-1.0.2-alt8.hg20091030.1.src.rpm: 228
boost.git 252
texlive.git 300
$ 

Я попробовал запрофилировать почему столько много времени уходит чтобы
просто понять что пакет не надо пересобирать от прошлого запуска; там
короче говоря причины разные, то есть одного узкого места нету.

Поэтому я сделал превентивный хак для girar-builder'а:
http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=586f99e1
Он немного ослабляет требования базовой модели, но не очень сильно.
Тестовая пересборка пакетов, если мы до неё доживём, будет идти по
такой же схеме.

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

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Thu, Nov 26, 2009 at 12:02:45PM +0300, Alexey Tourbin wrote:
> У нас очень долго выполняется фаза "no need to rebuild", в среднем
> не менее минуты на пакет.  Всё это конечно не планировалось что людишки
> будут заливать пакеты целыми сотнями.  Но есть то что есть -- мы так
> никуда не уедем.
> 
> $ GET http://git.altlinux.org/tasks/16528/task/log.4 |grep x86_64 |awk 'function sec(d){match(d,/([0-9][0-9]):([0-9][0-9]):([0-9][0-9])/,a); return a[1]*3600+a[2]*60+a[3] } /build start/{start=sec($2);name=$5} ;/no need to r/&&$5==name{print name,sec($2)-start}' |sort -k2n |tail -20
> python-module-fiat.git 67
> babel.git 70
> petsc.git 70
> scribus.git 70
> python-module-matplotlib-0.99.0-alt2.1.src.rpm: 71
> python-module-Crypto-2.0-alt2.1.1.1.src.rpm: 74
> python-module-OpenSSL-0.6-alt2.1.1.1.1.1.src.rpm: 74
> python.git 86
> petsc.git 90
> scons-1.1.0-alt1.1.src.rpm: 91
> vim.git 91
> postgresql8.3.git 123
> libopencv.git 143
> dblatex.git 167
> slepc4py.git 203
> petsc4py-complex-1.0.2-alt8.hg20091030.1.src.rpm: 212
> slepc4py-real-1.0.0-alt6.hg20090916.1.src.rpm: 216
> petsc4py-real-1.0.2-alt8.hg20091030.1.src.rpm: 228
> boost.git 252
> texlive.git 300
> $ 
> 
> Я попробовал запрофилировать почему столько много времени уходит чтобы
> просто понять что пакет не надо пересобирать от прошлого запуска; там
> короче говоря причины разные, то есть одного узкого места нету.
> 
> Поэтому я сделал превентивный хак для girar-builder'а:
> http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=586f99e1
> Он немного ослабляет требования базовой модели, но не очень сильно.
> Тестовая пересборка пакетов, если мы до неё доживём, будет идти по
> такой же схеме.

Нету эффекта. :(
Либо ещё не вступило в силу либо код не работает.

$ GET http://git.altlinux.org/tasks/16528/task/log.6 |grep x86_64 |awk 'function sec(d){match(d,/([0-9][0-9]):([0-9][0-9]):([0-9][0-9])/,a); return a[1]*3600+a[2]*60+a[3] } /build start/{start=sec($2);name=$5} /no need to r/&&$5==name{print name,sec($2)-start}' |sort -k2n |tail
libopencv.git 138
dblatex.git 168
petsc4py-complex-1.0.2-alt8.hg20091030.1.src.rpm: 201
slepc4py.git 206
slepc4py-real-1.0.0-alt6.hg20090916.1.src.rpm: 210
petsc4py-real-1.0.2-alt8.hg20091030.1.src.rpm: 213
trilinos.git 216
dolfin.git 239
boost.git 250
texlive.git 313
$ 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]

On Thu, Nov 26, 2009 at 08:00:32PM +0300, Alexey Tourbin wrote:
> > Поэтому я сделал превентивный хак для girar-builder'а:
> > http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=586f99e1
> > Он немного ослабляет требования базовой модели, но не очень сильно.
> > Тестовая пересборка пакетов, если мы до неё доживём, будет идти по
> > такой же схеме.
> 
> Нету эффекта. :(
> Либо ещё не вступило в силу либо код не работает.

Во!  Почти в два раза быстрее пошло.

$ GET http://git.altlinux.org/tasks/16528/task/log.6 |grep x86_64 |awk 'function sec(d){match(d,/([0-9][0-9]):([0-9][0-9]):([0-9][0-9])/,a); return a[1]*3600+a[2]*60+a[3] } /build start/{start=sec($2);name=$5} /no need to r/&&$5==name{print sec($2)-start,name}' |stats.pl
min=23 rpmlint.git
max=313 texlive.git
mean=46.3362068965517
medi=34
devi=39.5704082809883
$ GET http://git.altlinux.org/tasks/16528/task/log.7 |grep x86_64 |awk 'function sec(d){match(d,/([0-9][0-9]):([0-9][0-9]):([0-9][0-9])/,a); return a[1]*3600+a[2]*60+a[3] } /build start/{start=sec($2);name=$5} /no need to r/&&$5==name{print sec($2)-start,name}' |stats.pl
min=20 python-module-setuptools-0.6-alt1.c9.1.src.rpm:
max=56 avahi.git
mean=27.6973684210526
medi=26
devi=4.99113335765044
$ 

[-- Attachment #1.2: stats.pl --]
[-- Type: text/plain, Size: 345 bytes --]

#!/usr/bin/perl
use strict;
use bigint;
use Statistics::Descriptive;
my $stat = Statistics::Descriptive::Full->new();
while (<>) {
	chomp;
	$stat->add_data($_);
}
print "min=".$stat->min()."\n";
print "max=".$stat->max()."\n";
print "mean=".$stat->mean()."\n";
print "medi=".$stat->median()."\n";
print "devi=".$stat->standard_deviation()."\n";

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

Re: [devel] Python 2.6: task #16528

[REAL]

Alexey Tourbin пишет:
> Во!  Почти в два раза быстрее пошло.

Ага, я уже заметил ;)

Спасибо.

2all. Завтра я за компьютер вряд ли раньше вечера дорвусь (срочные 
дела в оффлайне), а сегодня будет очередной перезапуск задачи... Так 
что, боюсь, ещё и начало следующей недели захватится сборкой :( , 
учитывая, что до сих пор неясно, какие пакеты прошли мимо внимания, 
хотя я постарался вручную вычислить всё, что мог, да и за время моего 
отсутствия что-то из списка может проскочить в сизиф.

Наверно, добавлю уж сразу и openoffice.org, авось этот запуск дойдёт 
до конца списка, по крайней мере, хотелось бы надеяться...

-- 

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Fri, Nov 27, 2009 at 04:38:26PM +0700, REAL wrote:
> 2all. Завтра я за компьютер вряд ли раньше 
> вечера дорвусь (срочные дела в оффлайне), 
> а сегодня будет очередной перезапуск 
> задачи... Так что, боюсь, ещё и начало 
> следующей недели захватится сборкой :( , 
> учитывая, что до сих пор неясно, какие 
> пакеты прошли мимо внимания, хотя я 
> постарался вручную вычислить всё, что 
> мог, да и за время моего отсутствия что-то 
> из списка может проскочить в сизиф.
> 
> Наверно, добавлю уж сразу и openoffice.org, 
> авось этот запуск дойдёт до конца списка, 
> по крайней мере, хотелось бы надеяться...

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

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Fri, Nov 27, 2009 at 04:38:26PM +0700, REAL wrote:
> 2all. Завтра я за компьютер вряд ли раньше 
> вечера дорвусь (срочные дела в оффлайне), 
> а сегодня будет очередной перезапуск 
> задачи... Так что, боюсь, ещё и начало 
> следующей недели захватится сборкой :( , 
> учитывая, что до сих пор неясно, какие 
> пакеты прошли мимо внимания, хотя я 
> постарался вручную вычислить всё, что 
> мог, да и за время моего отсутствия что-то 
> из списка может проскочить в сизиф.
> 
> Наверно, добавлю уж сразу и openoffice.org, 
> авось этот запуск дойдёт до конца списка, 
> по крайней мере, хотелось бы надеяться...

Я нарисовал костыль называется "local policy".  Предполагается что
когда "очень надо" администратор girar-builder сможет активировать
некоторые временные проверки (например временно не пускать пакеты
с зависимостями python2.5, чтобы они таки пересобрались с python2.6).
http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=d177e84d
http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=d694e4f7

Когда всё уже будет окончательно срастаться можно будет подстраховать.

Можно даже ещё более крутые блокировки выставить, чтобы вообще не
пришлось пересобирать пакетов.  Надо подумать.  Можно заблокировать
'hsh --initroot' чтобы пакеты не попадали в базовую сборочную среду;
и можно заблокировать пакеты по отдельному заданию, которые там сидят
в chroot_base и chroot_BR.

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

Re: [devel] Python 2.6: task #16528

[Alexey Tourbin]

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

On Thu, Nov 26, 2009 at 12:02:45PM +0300, Alexey Tourbin wrote:
> On Wed, Nov 25, 2009 at 02:12:13PM +0700, REAL wrote:
> > Поскольку сборка более 600 пакетов - дело 
> > очень долгое (на сборку не самых 
> > монстроидальных 200 пакетов 
> > потребовалось около 12 часов), возможно, я 
> > попытаюсь в этой задаче всё собирать до 
> > упора, таким образом, надеюсь, именно она 
> > и станет рабочей, из которой в сизиф 
> > пролезет python 2.6.
> > 
> > Чтобы дело пошло быстрее (сбои ещё будут, 
> > т.к. там не все пакеты), большая просьба 
> > пакеты из задачи пока не обновлять, чтобы 
> > потом не пришлось начинать сборку заново.
> > 
> > http://git.altlinux.org/tasks/16528/task/log.2
> 
> У нас очень долго выполняется фаза "no need to rebuild", в среднем
> не менее минуты на пакет.  Всё это конечно не планировалось что людишки
> будут заливать пакеты целыми сотнями.  Но есть то что есть -- мы так
> никуда не уедем.

> Я попробовал запрофилировать почему столько много времени уходит чтобы
> просто понять что пакет не надо пересобирать от прошлого запуска; там
> короче говоря причины разные, то есть одного узкого места нету.

Главный фактор почему медленно работала проверка "no need to rebuild" --
это сама схема проверки: собирается src.rpm пакет и в чрут
устанавливаются все пакеты BuildReqires.  Если содержимое чрута после
этого совпадает, то пакет можно не пересобирать.

Эта схема теперь модифицирована следующим образом: когда имеется src.rpm
пакет от предыдущего запуска, можно замкнуть его список BuildRequires и
получить список пакетов, которые будут установлены.  То есть можно
узнать содержимое чрута без фактической установки пакетов.

Есть ещё два фактора, которые заметно влияют на скорость проверки "no
need to rebuild".

1) hsh --init на репозитарии с полным списком файлов.
Научно установлено, что 'hsh --init' на обычно репозитарии занимает 13
секунд, а на репозитарии с полным списком файлов -- 20 секунд.

2) После сборки каждого очередного пакета хешеру нужно перегенерировать
локальный репозитарий; в том числе прочитать все пакеты и вычислить их
md5 суммы (потому что md5-кеш пакетов на нодах скорее всего не работает).

Я думаю что в хешере можно вообще не генерировать репозитарий и целиком
отказаться от genbasedir, а вместо этого в sources.list использовать
метод доступа "rpm-dir" вместо "rpm" (repo).  Тогда при изменении
каталога rpm-dir apt будет считывать информацию прямо из хедеров
пакетов, которые там лежат.  А это лушче, перечитывать пакеты полностью
(для вычисления md5-сумм).

> Поэтому я сделал превентивный хак для girar-builder'а:
> http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=586f99e1
> Он немного ослабляет требования базовой модели, но не очень сильно.
> Тестовая пересборка пакетов, если мы до неё доживём, будет идти по
> такой же схеме.

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