[devel] I: viy current schedule on perl, python, java.

[devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

Господа,
решил поделиться своими планами.

По perl планирую начать переезд на 5.24.1,
как только он выйдет (сейчас уже v5.24.1-RC5).
тем временем занимаюсь регулярными обновлениями
модулей perl.

По java надо обновить модули и обновить JVM
(в которой накопилось много мелких, но нприятных
проблем -- старая версия, тяжелые зависимости).
Собирался обновляить JVM после обновления модулей,
обновление модулей на 3/4 уже сделано.
К сожалению, вышла со строя машина альтаир,
на которой я тестировал изменения в локальных карманах,
и работу пришлось отложить. 

до возвращения альтаира в строй переключился на питон,
точнее на разработку роботов для его обслуживания.

Питон у нас большой и сильно протухший (больше 60% пакетов
нуждаются в обновлении) обновлялся из git, но данных 
об апстримных git не сохранилось (хороший пример,
почему надо пользоваться gear-remotes !
/ https://www.altlinux.org/Gear/remotes /)

Кроме того, с питоном большой риск надорваться -
если возьмусь за него полностью, то в моей зоне ответственности
станет 7.5 тыс. пакетов (java+perl+python+мои) в Сизифе (44%)
и 30 тыс. пакетов в autoimports.
Как говорится в анекдоте,
обычная награда за хорошо выполненную работу — это еще больше работы.

Поэтому под питон стараюсь не писать новый код,
а переделать существующий так, чтобы он был более функциональным
и универсальным.

В частности, старый обновитель для perl и новый для python
свел в одну кодовую базу, и теперь свожу их в одну кодовую
базу с библиотекой генераторов пакетов.

на этой неделе делаю большое обновление,
в итого около 300 колхозных (acl=@python) пакетов 
будет поставлено на автообновление из pypi.
но это только 10%.

Очень сейчас не хватает генератора пакетов.
починишь и отправишь модуль python в Сизиф, а у 
него unmet на отсутствующий в Сизифе еще один модуль.

Поэтому в первую очередь нужно написать инструменты.


-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Ivan Zakharyaschev]

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


On Thu, 12 Jan 2017, Igor Vlasenko wrote:

> Поэтому под питон стараюсь не писать новый код,
> а переделать существующий так, чтобы он был более функциональным
> и универсальным.
>
> В частности, старый обновитель для perl и новый для python
> свел в одну кодовую базу, и теперь свожу их в одну кодовую
> базу с библиотекой генераторов пакетов.
>
> на этой неделе делаю большое обновление,
> в итого около 300 колхозных (acl=@python) пакетов 
> будет поставлено на автообновление из pypi.
> но это только 10%.
>
> Очень сейчас не хватает генератора пакетов.
> починишь и отправишь модуль python в Сизиф, а у 
> него unmet на отсутствующий в Сизифе еще один модуль.
>
> Поэтому в первую очередь нужно написать инструменты.

А сейчас обновитель питоновских пакетов работает без генератора пакетов? 
Интересно: в чём разница?

-- 
Best regards,
Ivan

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Thu, Jan 12, 2017 at 07:00:17PM +0300, Ivan Zakharyaschev wrote:
> А сейчас обновитель питоновских пакетов работает без генератора пакетов?
> Интересно: в чём разница?

простой обновитель - это робот, который берет
существующий srpm пакет или gear,
обновляет исходники, подправляет 
Source:, Version:, %prep, ставит Release:alt1,
и добавляет %changelog.

генератор пакетов c нуля собирает готовый пакет.
./сгенерировать foo
Written: python-module-foo-1.0-alt1.src.rpm

Вот второго у меня для питона пока нет.


-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Ivan Zakharyaschev]

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

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

On Thu, 12 Jan 2017, Igor Vlasenko wrote:

> On Thu, Jan 12, 2017 at 07:00:17PM +0300, Ivan Zakharyaschev wrote:
>> А сейчас обновитель питоновских пакетов работает без генератора пакетов?
>> Интересно: в чём разница?
>
> простой обновитель - это робот, который берет
> существующий srpm пакет или gear,
> обновляет исходники, подправляет 
> Source:, Version:, %prep, ставит Release:alt1,
> и добавляет %changelog.
>
> генератор пакетов c нуля собирает готовый пакет.

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

Интересно: а можно ли быть увереным, что заменённый старый Source
содержал только коммиты, за которые ответственен upstream? Или там 
собиравшие раньше в Sisyphus могли что-то нахакать в git и делать из этого 
архив для сборки?

-- 
Best regards,
Ivan

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Fri, Jan 13, 2017 at 12:32:49PM +0300, Ivan Zakharyaschev wrote:
> Понятно. Я думал, что, может быть, отправленные на сборку пакеты просто были
> с нуля сгенерированы, раз они не наследуют историю. А оказывается, туда
> более тонко были вставлены новые исходники.

У меня есть рабочий робот для обновления srpm'ов.
Он в сизифе 2 тысячи perl-* обновляет, и его я приспособил и к питону.
Обновлял srpm'ы, поэтому и заливал как srpm'ы, 
пришлось отрывать git.

Есть и робот для обновления git'ов, он более экспериментальный,
и пасется на пакетах crux@, (2 сотни) с его любезного позволения.
он более экспериментальный, геморройный, капризный и т.д.
Это как паровой автомобиль в сравнении с бензиновым.
Усилий шофера требует в 10 раз больше. 
Я его тоже к питону приспособлю, но только для тех
пакетов, где другого выхода не будет.

> Интересно: а можно ли быть увереным, что заменённый старый Source
> содержал только коммиты, за которые ответственен upstream? Или там
> собиравшие раньше в Sisyphus могли что-то нахакать в git и делать из этого
> архив для сборки?

Для такого есть библиотека perl-Gear-Rules,
тот же gear-uupdate на такое проверяет,
но в данном случае я не проверял -- 
вероятность слишком маленькая в силу специфики пакетов
и стиля Евгения Ростовцева. Можно, конечно, робот
проверки написать, но там еще много фальшстартов
и овчинка выделки не стоит.



-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Alexey Shabalin]

13 января 2017 г., 18:31 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Fri, Jan 13, 2017 at 12:32:49PM +0300, Ivan Zakharyaschev wrote:
>> Понятно. Я думал, что, может быть, отправленные на сборку пакеты просто были
>> с нуля сгенерированы, раз они не наследуют историю. А оказывается, туда
>> более тонко были вставлены новые исходники.
>
> У меня есть рабочий робот для обновления srpm'ов.
> Он в сизифе 2 тысячи perl-* обновляет, и его я приспособил и к питону.
> Обновлял srpm'ы, поэтому и заливал как srpm'ы,
> пришлось отрывать git.

Мне кажется, в случае python модулей использование srpm оправдано, и
большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
предполагется их обновление роботом.
И я готов свои python-пакеты вытащить из git. (не все, есть исключения)
Многие вещи, которые делал real@ с python-пакетами для меня остаются загадкой.
Например, pickles подпакеты.

-- 
Alexey Shabalin

Re: [devel] I: viy current schedule on perl, python, java.

[Ivan Zakharyaschev]

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


On Fri, 13 Jan 2017, Alexey Shabalin wrote:

> 13 января 2017 г., 18:31 пользователь Igor Vlasenko
> <vlasenko@imath.kiev.ua> написал:
>> On Fri, Jan 13, 2017 at 12:32:49PM +0300, Ivan Zakharyaschev wrote:
>>> Понятно. Я думал, что, может быть, отправленные на сборку пакеты просто были
>>> с нуля сгенерированы, раз они не наследуют историю. А оказывается, туда
>>> более тонко были вставлены новые исходники.
>>
>> У меня есть рабочий робот для обновления srpm'ов.
>> Он в сизифе 2 тысячи perl-* обновляет, и его я приспособил и к питону.
>> Обновлял srpm'ы, поэтому и заливал как srpm'ы,
>> пришлось отрывать git.
>
> Мне кажется, в случае python модулей использование srpm оправдано, и
> большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> предполагется их обновление роботом.
> И я готов свои python-пакеты вытащить из git. (не все, есть исключения)

В целом, конечно, согласен. Git имеет смысл, по-моему, для каких-то 
отдельных пакетов, где мейнтейнер хочет вытаскивать отдельные коммиты и 
т.п.

> Многие вещи, которые делал real@ с python-пакетами для меня остаются загадкой.
> Например, pickles подпакеты.

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

Я запланировал, чтобы решить и проблему минимизации сборочных зависимостей 
(для массового обновления), и эту неправильность, собирать документацию 
отдельно. (И pickles, возможно.)

Пока был Git, думал, можно будет в тот же спек правила написать, но по 
переменным gear из тега выбирать, собираем ли мы сам пакет или 
документацию.

А так можно будет помимо основных srpm делать просто rebuild srpm-а для 
сборки документации. Версию он подставит из сборочной среды, и править 
srpm не надо будет каждый раз.

-- 
Best regards,
Ivan

[devel] python bootstrap vs python-module-sphinx (was: I: viy current schedule on perl, python, java)

[Michael Shigorin]

On Fri, Jan 13, 2017 at 07:19:03PM +0300, Ivan Zakharyaschev wrote:
> > Многие вещи, которые делал real@ с python-пакетами для меня
> > остаются загадкой.  Например, pickles подпакеты.
> Не знаю толком на счёт pickles, но вот что касается похожей
> штуки, т.е.  генерации документации -- я когда разбирался с
> циклами сборочных зависимостей и применял buildreq, обнаружил
> -- то она неправильно генерируется (иногда) из установленных в
> систему пакетов (предыдущей версии!).
> 
> Я запланировал, чтобы решить и проблему минимизации сборочных
> зависимостей (для массового обновления), и эту неправильность,
> собирать документацию отдельно. (И pickles, возможно.)

Вообще большая человеческая просьба: трогая спеки питоньих
модулей, зависящих по сборке от rpm-macros-sphinx, не лениться
добавлять

%def_with doc

и заворачивать генерацию/упаковку docs и pickles в %if_with doc
примерно таким макаром:

+%if_with doc
 %make_build -C docs html
 %make_build -C docs pickle
+%endif

...

+%if_with doc
 cp -fR docs/_build/pickle %buildroot%python_sitelibdir_noarch/jinja2/
+%endif

...

+%if_with doc
 %files doc
 %doc docs/_build/html/*
 
 %files pickles
 %dir %python_sitelibdir_noarch/jinja2
 %python_sitelibdir_noarch/jinja2/pickle
+%endif

(обоснование: именно with doc до сих пор по большей части и наблюдаю,
разнобой в стороны with docs или enable doc{,s} несколько огорчает)

http://git.altlinux.org/people/mike/packages/?p=python-module-jinja2.git;a=commitdiff;h=f3d01b09b0bc043e6efbda9004055b03c8128e09

или однострочниками вроде таких, если удобней:

-BuildRequires: ctags python-module-sphinx time
+BuildRequires: time
+
+%{?_with_doc:BuildRequires: ctags python-module-sphinx}

...

-make -C docs html
+%{?_with_doc:make -C docs html}

http://git.altlinux.org/people/mike/packages/?p=python-module-polib.git;a=commitdiff;h=5a21fffd7557b80a52df51f54427d98971aa603d

А то эта питонья гуща вокруг python-module-sphinx уже какое-то
вдребезги кружевное бельё напоминает при попытке забутстрапить...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] python bootstrap vs python-module-sphinx (was: I: viy current schedule on perl, python, java)

[Ivan Zakharyaschev]

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

On Sat, 14 Jan 2017, Michael Shigorin wrote:

> On Fri, Jan 13, 2017 at 07:19:03PM +0300, Ivan Zakharyaschev wrote:
>> > Многие вещи, которые делал real@ с python-пакетами для меня
>> > остаются загадкой.  Например, pickles подпакеты.
>> Не знаю толком на счёт pickles, но вот что касается похожей
>> штуки, т.е.  генерации документации -- я когда разбирался с
>> циклами сборочных зависимостей и применял buildreq, обнаружил
>> -- то она неправильно генерируется (иногда) из установленных в
>> систему пакетов (предыдущей версии!).
>> 
>> Я запланировал, чтобы решить и проблему минимизации сборочных
>> зависимостей (для массового обновления), и эту неправильность,
>> собирать документацию отдельно. (И pickles, возможно.)
>
> Вообще большая человеческая просьба: трогая спеки питоньих
> модулей, зависящих по сборке от rpm-macros-sphinx, не лениться
> добавлять

Да. А я вообще плнаирую то, что предлагается оборачивать, вынести в 
отедльный srpm.

> %def_with doc
>
> и заворачивать генерацию/упаковку docs и pickles в %if_with doc
> примерно таким макаром:
>
> +%if_with doc
> %make_build -C docs html
> %make_build -C docs pickle
> +%endif
>
> ...
>
> +%if_with doc
> cp -fR docs/_build/pickle %buildroot%python_sitelibdir_noarch/jinja2/
> +%endif
>
> ...
>
> +%if_with doc
> %files doc
> %doc docs/_build/html/*
> 
> %files pickles
> %dir %python_sitelibdir_noarch/jinja2
> %python_sitelibdir_noarch/jinja2/pickle
> +%endif
>
> (обоснование: именно with doc до сих пор по большей части и наблюдаю,
> разнобой в стороны with docs или enable doc{,s} несколько огорчает)
>
> http://git.altlinux.org/people/mike/packages/?p=python-module-jinja2.git;a=commitdiff;h=f3d01b09b0bc043e6efbda9004055b03c8128e09
>
> или однострочниками вроде таких, если удобней:
>
> -BuildRequires: ctags python-module-sphinx time
> +BuildRequires: time
> +
> +%{?_with_doc:BuildRequires: ctags python-module-sphinx}
>
> ...
>
> -make -C docs html
> +%{?_with_doc:make -C docs html}
>
> http://git.altlinux.org/people/mike/packages/?p=python-module-polib.git;a=commitdiff;h=5a21fffd7557b80a52df51f54427d98971aa603d
>
> А то эта питонья гуща вокруг python-module-sphinx уже какое-то
> вдребезги кружевное бельё напоминает при попытке забутстрапить...
>
> -- 
>  ---- WBR, Michael Shigorin / http://altlinux.org
>   ------ http://opennet.ru / http://anna-news.info
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Fri, Jan 13, 2017 at 06:57:07PM +0300, Alexey Shabalin wrote:
> Мне кажется, в случае python модулей использование srpm оправдано, и
> большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> предполагется их обновление роботом.
> И я готов свои python-пакеты вытащить из git. (не все, есть исключения)
> Многие вещи, которые делал real@ с python-пакетами для меня остаются загадкой.
> Например, pickles подпакеты.

Робот пытается по acl и по способу заливки (srpm,git) делить пакеты на группы.
Пока я с @python пакетами экспериментирую,
а когда все будет готово, то надо будет всем владельцам собраться,
и договориться, кто сам сопровождает, кто отдает на автосопровождение
и как это отразить в acl.

-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Антон Мидюков]

13.01.2017 22:57, Alexey Shabalin пишет:
> Мне кажется, в случае python модулей использование srpm оправдано, и
> большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> предполагется их обновление роботом.
Я хотел свои пакеты python перевести на SRPM и столкнулся с двумя 
проблемами:
1. package update by srpm upload is not possible
То есть мне не позволено переводить пакеты с gear на srpm
2. куча warning: in/пакет.src.rpm: Header V4 RSA/SHA1 Signature, key ID 
289d2295: NOKEY
А это мне непонятно совсем. Подписывал командой
rpm --addsign <package.src.rpm>
Что ему не нравится в моей подписи?

-- 
С уважением Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Wed, Jan 18, 2017 at 08:35:18PM +0700, Антон Мидюков wrote:
> 13.01.2017 22:57, Alexey Shabalin пишет:
> >Мне кажется, в случае python модулей использование srpm оправдано, и
> >большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> >предполагется их обновление роботом.
> Я хотел свои пакеты python перевести на SRPM и столкнулся с двумя
> проблемами:
> 1. package update by srpm upload is not possible
> То есть мне не позволено переводить пакеты с gear на srpm

способ есть, надо дать команду check-git-inheritance.
Самое простое- поставить girar-nmu и выполнить, к примеру,

ssh girar task check-git-inheritance 176054 100 disable `girar-print-build-commit -b sisyphus python-module-appier_extras`

> 2. куча warning: in/пакет.src.rpm: Header V4 RSA/SHA1 Signature, key ID
> 289d2295: NOKEY
> А это мне непонятно совсем. Подписывал командой
> rpm --addsign <package.src.rpm>
> Что ему не нравится в моей подписи?

вместо --addsign пользуйтесь
rpm --resign

прорекламирую

$ alias rpmupload 
rpmupload=girar-nmu-helper-task-for-each-srpm

подписывает и заливает одной командой.

-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Wed, Jan 18, 2017 at 07:47:20PM +0200, Igor Vlasenko wrote:
> > 1. package update by srpm upload is not possible
> > То есть мне не позволено переводить пакеты с gear на srpm
> 
> способ есть, надо дать команду check-git-inheritance.
> Самое простое- поставить girar-nmu и выполнить, к примеру,
> 
> ssh girar task check-git-inheritance 176054 100 disable `girar-print-build-commit -b sisyphus python-module-appier_extras`

и после этого опять 
ssh girar task run

-- 

I V

Re: [devel] I: viy current schedule on perl, python, java.

[Alexey Shabalin]

13 января 2017 г., 18:57 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
> 13 января 2017 г., 18:31 пользователь Igor Vlasenko
> <vlasenko@imath.kiev.ua> написал:
>> On Fri, Jan 13, 2017 at 12:32:49PM +0300, Ivan Zakharyaschev wrote:
>>> Понятно. Я думал, что, может быть, отправленные на сборку пакеты просто были
>>> с нуля сгенерированы, раз они не наследуют историю. А оказывается, туда
>>> более тонко были вставлены новые исходники.
>>
>> У меня есть рабочий робот для обновления srpm'ов.
>> Он в сизифе 2 тысячи perl-* обновляет, и его я приспособил и к питону.
>> Обновлял srpm'ы, поэтому и заливал как srpm'ы,
>> пришлось отрывать git.
>
> Мне кажется, в случае python модулей использование srpm оправдано, и
> большого смысла тащить их в git нет. Тем юолее, если в дальнейшем
> предполагется их обновление роботом.
> И я готов свои python-пакеты вытащить из git. (не все, есть исключения)

Собираю новый openstack и по возможности вытаскиваю пакеты из git.
Сами git репо остануться (мне в них удобнее отслеживать изменения), а
на сборку будут посылаться src.rpm, которые можно будет обновлять
автоматически.


-- 
Alexey Shabalin

Re: [devel] I: viy current schedule on perl, python, java.

[Alexey Shabalin]

12 января 2017 г., 17:43 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> Питон у нас большой и сильно протухший (больше 60% пакетов
> нуждаются в обновлении)

> на этой неделе делаю большое обновление,
> в итого около 300 колхозных (acl=@python) пакетов
> будет поставлено на автообновление из pypi.
> но это только 10%.
Есть пакеты, которые очень не хотелось бы обновлять автоматом.
Точнее не так. Их можно обновлять автоматом, но до нужных версий.
К таким пакетам относится проект openstack(большое количество
взаимосвязанных пакетов), пакеты sqlalchemy,django.

Или, как я просил ранее, надо что-то придумать с переносом openstack в
отдельные репо, где можно организовать несколько
срезов(kilo,mitaka,newton) для разных версий наших бранчей (для
p7,p8,sisyphus) во всех комбинациях.

-- 
Alexey Shabalin

Re: [devel] I: viy current schedule on perl, python, java.

[Igor Vlasenko]

On Thu, Jan 12, 2017 at 09:49:28PM +0300, Alexey Shabalin wrote:
> Есть пакеты, которые очень не хотелось бы обновлять автоматом.
> Точнее не так. Их можно обновлять автоматом, но до нужных версий.
> К таким пакетам относится проект openstack(большое количество
> взаимосвязанных пакетов), пакеты sqlalchemy,django.
 
> Или, как я просил ранее, надо что-то придумать с переносом openstack в
> отдельные репо, где можно организовать несколько
> срезов(kilo,mitaka,newton) для разных версий наших бранчей (для
> p7,p8,sisyphus) во всех комбинациях.

Спасибо, буду помнить.
Только это задел на будущее. Сначала нужно инструменты дожать
и привести питоньи пакеты к виду, пригодному для автообновления
(те, что будут обновляться из git, должны иметь .gear/upstream/remotes
а те что из PyPI - спек привести в соответствие к обновлению
из тарбола.)

Тогда 1й вариант технически можно реализовать так.
Сначала обновить все, чтобы привести к новому виду,
затем через acl выделить нужные подгруппы и запретить
их обновление обычным роботом, а написать специализированного.

Если руками обновлять, то можно и сейчас группы ввести, 
если не страшно, что часть пакетов успела попасть под раздачу.
Тогда кто хочет взяться за связанную группу пакетов,
пишите в devel@ и корректируйте acl c @python на новую группу.

2й вариант -- я могу под него ноды выделить, чтобы сделать наподобие
autoports и autoimports, 
Опять же вопрос, кто будет этим заниматься.

-- 

I V