[devel] [devel-announce] I: git.alt task check-git-inheritance

[devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-18 23:01 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 8:49 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 10:34 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 10:36 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 10:46 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 14:44 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 16:36 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 16:45 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-19 17:13 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-20 11:21 UTC (permalink / raw)]

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[@ 2011-10-20 12:34 UTC (permalink / raw)]

[devel] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[@ 2011-10-20 12:52 UTC (permalink / raw)]

Re: [devel] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[@ 2011-10-20 13:03 UTC (permalink / raw)]

Re: [devel] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[@ 2011-10-20 13:14 UTC (permalink / raw)]

[devel] приемы gear (was: @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance))

[@ 2011-10-20 13:36 UTC (permalink / raw)]

Re: [devel] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[@ 2011-10-21 11:28 UTC (permalink / raw)]

Re: [devel] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[@ 2011-10-21 13:24 UTC (permalink / raw)]

Re: [devel] gear

[@ 2011-10-21 13:49 UTC (permalink / raw)]

Re: [devel] gear

[@ 2011-10-21 14:44 UTC (permalink / raw)]

Re: [devel] gear

[@ 2011-10-22 0:37 UTC (permalink / raw)]

Re: [devel] gear

[@ 2011-10-22 0:38 UTC (permalink / raw)]

Re: [devel] gear

[@ 2011-10-22 19:17 UTC (permalink / raw)]

[devel] [JT] Re: gear

[@ 2011-10-25 14:05 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 15:27 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 15:37 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 15:42 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 15:57 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 16:03 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-05 18:00 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-06 0:58 UTC (permalink / raw)]

Re: [devel] I: git.alt task check-git-inheritance

[@ 2012-10-06 7:14 UTC (permalink / raw)]

[devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 11:12 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 12:42 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 13:11 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 13:15 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 13:16 UTC (permalink / raw)]

[devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:08 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:10 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:26 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:30 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:36 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 14:59 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 15:29 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 15:38 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 15:42 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 15:52 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 16:14 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 21:22 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-08 21:28 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm

[@ 2012-10-09 3:26 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 10:07 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 10:47 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 11:01 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 11:28 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 12:02 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-09 17:04 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm

[@ 2012-10-09 17:09 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm

[@ 2012-10-09 22:45 UTC (permalink / raw)]

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-10 8:56 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[@ 2012-10-10 11:02 UTC (permalink / raw)]

Re: [devel] [JT] Re: srpm

[REAL]

10.10.2012 18:02, Sergey V Turchin пишет:
> Да я гороздо больше понимаю, но это ж не значит, что не нужно выражать здесь
> мнение ;-)

выскажу и я своё. все свои пакеты собираю из gear, а когда приходится 
возиться с чужими, те пакеты, что собирались из srpm, обеспечивают мне 
намного больше хлопот, чем те, что из gear. есть, конечно, простое 
решение: перестать вообще заниматься чем-либо, кроме своих пакетов, но 
не уверен, что это сильно облегчит жизнь остальным из team.

правда, есть и обратные случаи: некоторые пакеты из gear так с 
переподвыподвертом собираются, что браться за них я просто не решаюсь 
(texlive тому типичный пример). ну или те, где каждый даже самый 
мелкий фикс - это отдельный бранч.

надо бы найти какую-то золотую середину: чтобы и сборки из srpm не 
портили настроение (все эти задолбавшие rpm --resign & rsync 
qwewqe.srpm git.alt:), и из gear было что-то более-менее простое. 
лично мне больше всего симпатичен вариант, когда есть два бранча: 
upstream, где держатся исходники, и master, где спеки, фиксы либо 
патчи, ну и сам каталог .gear.

-- 

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

Re: [devel] [JT] Re: srpm

[Igor Vlasenko]

On Wed, Oct 10, 2012 at 07:50:32PM +0700, REAL wrote:
> надо бы найти какую-то золотую середину: чтобы и сборки из srpm не
> портили настроение (все эти задолбавшие rpm --resign & rsync
> qwewqe.srpm git.alt:), 

На всякий, поделюсь своими костылем:
у меня определен 
alias rpmupload=girar-nmu-helper-task-for-each-srpm
на команду из пакета girar-nmu.
этой одной командой можно залить на сборку сразу хоть сотню srpm.

накопилось в ~/hasher/repo/SRPMS.hasher достаточное число пакетов,
делаете cd ~/hasher/repo/SRPMS.hasher;
girar-nmu-helper-task-for-each-srpm *.src.rpm
или просто
rpmupload *m
и 100-200 rpm подписываются и заливаются с максимальной скоростью.

Есть там и удобный костыль для gear,
girar-nmu-helper-git-push-build -c -T
коммитит, делает тег и шлет на сборку.
для разных случаев есть множество разных опций.
girar-nmu-helper-git-push-build -b sisyphus -c -t 1.2-alt1 -k -K

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

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [JT] Re: srpm

[Pavel Vainerman]

10.10.2012 16:59, Igor Vlasenko пишет:
> On Wed, Oct 10, 2012 at 07:50:32PM +0700, REAL wrote:
>> надо бы найти какую-то золотую середину: чтобы и сборки из srpm не
>> портили настроение (все эти задолбавшие rpm --resign & rsync
>> qwewqe.srpm git.alt:),
>
> На всякий, поделюсь своими костылем:
> у меня определен
> alias rpmupload=girar-nmu-helper-task-for-each-srpm
> на команду из пакета girar-nmu.
> этой одной командой можно залить на сборку сразу хоть сотню srpm.
   а есть
rpmsh -u spec  (из etersoft-build-utils)

не пакетная команда.. но зато
сама определяет что у вас src.rpm или git и заливает
(как надо и куда надо)

..вообще думать не надо :)


-- 
Pavel Vaynerman
www.etersot.ru

Re: [devel] [JT] Re: srpm

[Pavel Vainerman]

> rpmsh -u spec  (из etersoft-build-utils)
Опечатался  rpmbsh ...


-- 
Pavel Vaynerman
www.etersot.ru

Re: [devel] [JT] Re: srpm

[Dmitry V. Levin]

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

On Wed, Oct 10, 2012 at 05:05:23PM +0400, Pavel Vainerman wrote:
>   а есть
> rpmsh -u spec  (из etersoft-build-utils)
> 
> не пакетная команда.. но зато
> сама определяет что у вас src.rpm или git и 
> заливает
> (как надо и куда надо)

Скрипт, определяющий источник (/gears или /srpms), должен проверять именно
тот бранч, с которым работает, а не просто наличие репозитория.

Например:

$ git ls-remote -h git://git.altlinux.org/srpms/p/perl-XML-Compile
ac05a7acad2afb12f4b380d9b29a5f46ddf02085	refs/heads/5.1
ac05a7acad2afb12f4b380d9b29a5f46ddf02085	refs/heads/p5
dd1d51b0905760dc757d91d461e36ef8a69df01c	refs/heads/sisyphus
$ git ls-remote -h git://git.altlinux.org/gears/p/perl-XML-Compile
f40b6b42e4385ac7a8516d808e6f924a532447ba	refs/heads/old/sisyphus-task81889
2b1f3797acdb9e4b0bda5489ca9ec738a64b0969	refs/heads/p6
2b1f3797acdb9e4b0bda5489ca9ec738a64b0969	refs/heads/t6

Из этого примера видно, что perl-XML-Compile:
в p5 и 5.1 из srpm,
в p6 и t6 из gear,
в sisyphus снова из srpm.

В etersoft-build-utils такого проверяющего кода вообще не видно.

> ..вообще думать не надо :)

Вообще думать надо. :)


-- 
ldv

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

Re: [devel] [JT] Re: srpm

[Pavel Vainerman]

> Скрипт, определяющий источник (/gears или /srpms), должен проверять именно
> тот бранч, с которым работает, а не просто наличие репозитория.
   Я наверно не совсем верно выразился.. я имел ввиду, что
он "знает" что именно я заливаю...

Впрочем Ваши примеры... возможно поспособствуют его развитию ;)

>> ..вообще думать не надо :)
>
> Вообще думать надо. :)
   как это не противоречиво звучит... я согласен...

-- 
Pavel Vaynerman
www.etersot.ru

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[Sergey V Turchin]

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

On 10 октября 2012 11:56:48 Igor Vlasenko wrote:

[...]
> Далеко за примерами ходить не надо.
> Например, Сергей, у вас самого достаточно
> экстремальный repository layout.
Зато простой и ссылку на патч можно отправить в upstream.

> Выделенной апстримной ветви нет,
Есть. У upstream.

> апстримные и наши коммиты вперемешку,
> с соглашением, что наш контент должен быть ограничен
> ./altlinux/ и .gear/, но без гарантий.
> 
> Такой репозиторий легко случайно засорить своим коммитом
> вне ./altlinux, который затем будет скрыт от глаз
> и погребен в ворохе апстримных коммитов.
Легко, но невозможно, пока я мантейнер этого пакета.
Легко, но только намеренно, что некоторые и делали(не скажу), наплевав на 
layout и мне приходилось переделывать.

> Еще и непрозрачная процедура обновления,
> осуществляемая с помощью внешнего костыля.
Не в курсе, но, полагаю, прозрачнее и проще, чем у некоторых.

> Документировать layout, workflow и костыли
> на wiki, создать в каждый репозиторий README.ALT,
> где указать external git репозитории, откуда берутся
> обновления, сослаться на wiki за описанием workflow
> и где брать необходимые костыли.
Согласен.

> А еще лучше выработать для хранения такой информации
> роботопонимаемый формат.
Мой не сложнее каталога, получаемого после rpm -bp

[...]
> Правильным будет начинать с себя, а не перекладывать
> это бремя на других.
Я, например, свое бремя ни на кого другого никогда не перекладывал.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] srpm (was: git.alt task check-git-inheritance)

[Sergey V Turchin]

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

On 10 октября 2012 11:56:48 Igor Vlasenko wrote:

[...]
> Если бы я выступил с призывом закрутить гайки, чтобы мои
> автоматизированные пакеты обновлялись не иначе как с
> помощью робота, не сочли бы все такой призыв неразумным?
Это к тому, что все равно найдутся недовольные? ;-)

> Ведь тогда бы без знания всей этой робототехники никто
> бы с моими пакетами ничего сделать бы не смог.
За 5 лет можно изучить, если это имеет смысл.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] [JT] Re: srpm

[REAL]

10.10.2012 19:59, Igor Vlasenko пишет:
>> надо бы найти какую-то золотую середину: чтобы и сборки из srpm не
>> портили настроение (все эти задолбавшие rpm --resign&  rsync
>> qwewqe.srpm git.alt:),
>
> На всякий, поделюсь своими костылем:

в том-то и дело, что хотелось бы не костылей, а просто использовать 
то, что привычно: git push --all origin && git push origin --tags && 
ssh git.alt build package tagname

-- 

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

Re: [devel] [JT] Re: srpm

[Igor Vlasenko]

On Wed, Oct 10, 2012 at 09:19:21PM +0700, REAL wrote:
> в том-то и дело, что хотелось бы не костылей, а просто использовать
> то, что привычно: git push --all origin && git push origin --tags &&
> ssh git.alt build package tagname

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

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [JT] Re: srpm

[REAL]

10.10.2012 22:40, Igor Vlasenko пишет:
>> в том-то и дело, что хотелось бы не костылей, а просто использовать
>> то, что привычно: git push --all origin&&  git push origin --tags&&
>> ssh git.alt build package tagname
>
> Всякому разное привычно.
> Было бы хорошо как знак вежливости в чужом пакете
> стараться подстроиться под хозяина,
> а работа над своими пакетами сейчас у каждого своя;

дело не в этом. плохо то, что нельзя просто собрать пакет из gear, а 
потом его же обновить из srpm (без дополнительных танцев с бубном 
вокруг недавно озвученного самостоятельного отказа от наследования), с 
сохранением истории. а то сейчас даже банальный git.alt:/srpms 
приходится вытягивать и подменять им то, что у меня в репозитории было 
раньше (не проходит мерж без конфликтов).

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

-- 

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

Re: [devel] [JT] Re: srpm

[Igor Zubkov]

2012/10/10 REAL:
> 10.10.2012 18:02, Sergey V Turchin пишет:
>>
>> Да я гороздо больше понимаю, но это ж не значит, что не нужно выражать
>> здесь
>> мнение ;-)
>
> выскажу и я своё. все свои пакеты собираю из gear, а когда приходится
> возиться с чужими, те пакеты, что собирались из srpm, обеспечивают мне
> намного больше хлопот, чем те, что из gear. есть, конечно, простое решение:
> перестать вообще заниматься чем-либо, кроме своих пакетов, но не уверен, что
> это сильно облегчит жизнь остальным из team.

Вы не только свои пакеты собираете из gear, но и чужие. К примеру, вы
пересобрали пакет libdbf для set-зависимостей. Вот этот коммит --
http://git.altlinux.org/people/real/packages/?p=libdbf.git;a=commitdiff;h=7a14d131c5d137c853146ea7f7b948e9d33f002b
. И в нагрузку сменили srpm на gear. Зачем? А потом ещё и перевесили
пакет обратно на nobody@.

> правда, есть и обратные случаи: некоторые пакеты из gear так с
> переподвыподвертом собираются, что браться за них я просто не решаюсь
> (texlive тому типичный пример). ну или те, где каждый даже самый мелкий фикс
> - это отдельный бранч.

"Чем меньше фикс и больше бранчей -- тем веселее!"

А вообще, самый-самый репозиторий это kernel-modules.

> надо бы найти какую-то золотую середину: чтобы и сборки из srpm не портили
> настроение (все эти задолбавшие rpm --resign & rsync qwewqe.srpm git.alt:),
> и из gear было что-то более-менее простое. лично мне больше всего симпатичен
> вариант, когда есть два бранча: upstream, где держатся исходники, и master,
> где спеки, фиксы либо патчи, ну и сам каталог .gear.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] [JT] Re: srpm

[Igor Vlasenko]

On Wed, Oct 10, 2012 at 11:04:16PM +0300, Igor Zubkov wrote:
> . И в нагрузку сменили srpm на gear. Зачем? 

Кстати, если надо сменить обратно gear на srpm, 
удобно пользоваться командой girar-print-build-commit 
из пакета girar-nmu.

Пример (сизиф):

$ ssh git.alt task check-git-inheritance 90000 100 disable `girar-print-build-commit perl-Text-vCard`

вариант для t6:
$ ssh git.alt task check-git-inheritance 80000 100 disable `girar-print-build-commit -b t6 asterisk12`


-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

On Wed, Oct 10, 2012 at 11:26:59PM +0300, Igor Vlasenko wrote:
> On Wed, Oct 10, 2012 at 11:04:16PM +0300, Igor Zubkov wrote:
> > . И в нагрузку сменили srpm на gear. Зачем? 
> 
> Кстати, если надо сменить обратно gear на srpm, 
> удобно пользоваться командой girar-print-build-commit 
> из пакета girar-nmu.
> 
> Пример (сизиф):
> 
> $ ssh git.alt task check-git-inheritance 90000 100 disable `girar-print-build-commit perl-Text-vCard`
> 
> вариант для t6:
> $ ssh git.alt task check-git-inheritance 80000 100 disable `girar-print-build-commit -b t6 asterisk12`

Смена gear обратно на srpm должна быть осознанной операцией.  Именно по
этой причине я сделал синтаксис команды check-git-inheritance таким
замысловатым.  Я рассчитывал, что в течение некоторого времени скрипт,
который сможет делать это автоматически, не будет написан.  Но теперь,
когда такой скрипт уже опубликован, смена gear на srpm перестает быть
осознанной операцией, и мне, наверное, придется усложнять синтаксис
команды.

Возможно, check-git-inheritance теперь должен стать интерактивным и
задавать нетривиальные вопросы.


-- 
ldv

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

Re: [devel] gear->srpm

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
[skipped]

 > Возможно, check-git-inheritance теперь должен стать интерактивным и
 > задавать нетривиальные вопросы.

дадад, двачую %triggerpostun-капчу.

-- 

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 12:47:32AM +0400, Dmitry V. Levin wrote:
> Смена gear обратно на srpm должна быть осознанной операцией. 

Тогда для симметрии смена srpm на gear тоже.

Если кто-то неосознанно меняет сборку моих пакетов 
с srpm на gear, это не страшно, пока есть возможность
откатить изменения. Но если возможность откат будет заблокирована,
надо по справедливости блокировать и смену с srpm на gear.

"Аугсбургский мир - чья власть, того и вера".

> когда такой скрипт уже опубликован, смена gear на srpm перестает быть
> осознанной операцией, и мне, наверное, придется усложнять синтаксис
> команды.
> Возможно, check-git-inheritance теперь должен стать интерактивным и
> задавать нетривиальные вопросы.

Если есть время на подобные забавы, хотел бы еще раз
обратить ваше внимание на баг #27637 
"ssh git.alt task run --email <mail addr> option"
Реализовать эту опцию гораздо легче, чем вышеописанную капчу, 
а отсутствие этой опции блокирует всю мою дальнейшую
работу над сервисами cron*.

В настоящее время раз git-ивание является официальной
политикой для пакетов @java (viy@) и @cpan (at@). 
Это четверть Сизифа, и гранаты туда бросать не надо.

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

http://www.howtogeek.com/118264/paying-customers-versus-pirates-how-drm-really-works-humorous-image/

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 01:26:59AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 12:47:32AM +0400, Dmitry V. Levin wrote:
> > Смена gear обратно на srpm должна быть осознанной операцией. 
> 
> Тогда для симметрии смена srpm на gear тоже.

Нет.  gear->srpm это регресс, он должен быть осознанным.

> Если кто-то неосознанно меняет сборку моих пакетов 
> с srpm на gear, это не страшно, пока есть возможность
> откатить изменения. Но если возможность откат будет заблокирована,
> надо по справедливости блокировать и смену с srpm на gear.

Для тех, кто не доверяет, есть acl.

> > когда такой скрипт уже опубликован, смена gear на srpm перестает быть
> > осознанной операцией, и мне, наверное, придется усложнять синтаксис
> > команды.
> > Возможно, check-git-inheritance теперь должен стать интерактивным и
> > задавать нетривиальные вопросы.
> 
> Если есть время на подобные забавы, хотел бы еще раз
> обратить ваше внимание на баг #27637 
> "ssh git.alt task run --email <mail addr> option"

Произвольный email это EWONTFIX, я готов отправлять письма только
зарегистрированным пользователям git.alt, которые предположительно
знали, на что шли.

> В настоящее время раз git-ивание является официальной
> политикой для пакетов @java (viy@) и @cpan (at@). 
> Это четверть Сизифа, и гранаты туда бросать не надо.

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

> И усложнение скриптов ничего не даст -
> те, кто массово пользуется, все равно заскриптуют,

С какой целью пользуются массовым переводом gear->srpm, помимо перевода
пакетов на сопровождение только роботами?


-- 
ldv

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

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> С какой целью пользуются массовым переводом gear->srpm, помимо перевода
> пакетов на сопровождение только роботами?

Например, Евгений Ростовцев часто мне оказывает большую
помощь, пересобирая тот или иной мой пакет с той или иной 
новой библиотекой. Я ему очень благодарен
и не хотел бы мешать ему заливать эти мои пакеты так как
ему удобнее, т.е. из его временного gear.

Потом когда нужно отправить пакет мне,
я его мог при необходимости расконвертировать.
Теперь придется каждый раз обрашаться к администратору Сизифа :(

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> > Если есть время на подобные забавы, хотел бы еще раз
> > обратить ваше внимание на баг #27637 
> > "ssh git.alt task run --email <mail addr> option"
> 
> Произвольный email это EWONTFIX, я готов отправлять письма только
> зарегистрированным пользователям git.alt, которые предположительно
> знали, на что шли.

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

мне нужно только, чтобы псевдопользователь cronbuild
мог переадресовывать сообщения о сборке на <nick>@altlinux.org.

Произвольный e-mail не нужен, <nick>@altlinux.org достаточно.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> > Если кто-то неосознанно меняет сборку моих пакетов 
> > с srpm на gear, это не страшно, пока есть возможность
> > откатить изменения. Но если возможность откат будет заблокирована,
> > надо по справедливости блокировать и смену с srpm на gear.
 
> Для тех, кто не доверяет, есть acl.

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

А если мне станет сложно вернуть пакет назад,
то это обесценит всю его работу.
В результате всем станет хуже,
экономика будет принесена в жертву идеологии.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> Я понимаю, что так выглядит наше светлое будущее, но
> до тех пор, пока еще есть хотя бы один живой мейнтейнер, проверка
> наследования для сопровождаемых им пакетов имеет смысл.

Это напоминает обсуждения о балансе при рассылке писем.
Когда кто-то начинал перегибать палку, цитировалась
"Если вы нам будете писать cron-ом, мы вас будем читать procmail-ом".

Разлочивание в srpm не должно быть сложнее git merge -s ours
и других хаков-заменителей, которые обессмысливают саму идею.

Социальные проблемы не надо рещать техническими средствами.

 
> > И усложнение скриптов ничего не даст -
> > те, кто массово пользуется, все равно заскриптуют,
> 
> С какой целью пользуются массовым переводом gear->srpm, помимо перевода
> пакетов на сопровождение только роботами?
 
Возвращение статус-кво после всякого рода NMU.
Ведь кому-то удобнее gear, но заливка NMU из gear автоматом
залочит пакет на gear, даже против воли лидера пакета.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 02:29:44AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> > С какой целью пользуются массовым переводом gear->srpm, помимо перевода
> > пакетов на сопровождение только роботами?
>  
> Возвращение статус-кво после всякого рода NMU.
> Ведь кому-то удобнее gear, но заливка NMU из gear автоматом
> залочит пакет на gear, даже против воли лидера пакета.

Если для srpm-пакетов неудобно делать всякого рода NMU, то это не значит,
что надо совершенствовать средства исправления последствий проведенного
NMU, уничтожающие историю изменений пакетов.

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

Насколько я понимаю, на данный момент удобного средства проведения ручного
NMU для стороннего srpm-пакета (когда надо немного поковыряться в
исходниках, а не просто применить стандартное изменение) еще нет?


-- 
ldv

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

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 03:44:44AM +0400, Dmitry V. Levin wrote:
> Насколько я понимаю, на данный момент удобного средства проведения ручного
> NMU для стороннего srpm-пакета (когда надо немного поковыряться в
> исходниках, а не просто применить стандартное изменение) еще нет?

Для роботобновляемых пакетов изменения будут автоматом сохранены,
там все замечательно (@cpan).

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

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 03:19:22AM +0300, Igor Vlasenko wrote:
> С роботогенерируемыми пакетами сложнее, они каждый раз 
> генерируются с нуля. Для них исходником является код 
> дополнений к роботу. Для таких надо коммитить патч
> в git-репозиторий робота либо отправить майнтайнеру 
> письмо-уведомление, что были нетривиальные изменения,
> которые нужно втянуть к роботу.

Другими словами, у роботогенерируемых пакетов другой 
workflow. У них из единственного git (не gear) репозитория
собираются сотни пакетов.
Например, у пакетов octave-* это octave-pacage-builder.git.

Совместная работа над пакетами octave-* -- это 
совместная работа над репозиторием octave-pacage-builder.git.

gear репозитории отдельных генерируемых пакетов там никаким боком
неуместны.


-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm->void

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 03:25:43AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 03:19:22AM +0300, Igor Vlasenko wrote:
> > С роботогенерируемыми пакетами сложнее, они каждый раз 
> > генерируются с нуля. Для них исходником является код 
> > дополнений к роботу. Для таких надо коммитить патч
> > в git-репозиторий робота либо отправить майнтайнеру 
> > письмо-уведомление, что были нетривиальные изменения,
> > которые нужно втянуть к роботу.
> 
> Другими словами, у роботогенерируемых пакетов другой 
> workflow. У них из единственного git (не gear) репозитория
> собираются сотни пакетов.
> Например, у пакетов octave-* это octave-pacage-builder.git.
> 
> Совместная работа над пакетами octave-* -- это 
> совместная работа над репозиторием octave-pacage-builder.git.
> 
> gear репозитории отдельных генерируемых пакетов там никаким боком
> неуместны.

Т.е. в Сизифе появился целый класс роботогенерируемых пакетов, исходников
которых по сути нет ни в gears, ни в SRPMS?  Те srpm-пакеты, которые эти
роботы отправляют в Сизиф, по сути такие же промежуточные транспортные
write-only контейнеры, как и те srpm-пакеты, которые получаются во время
работы gear+hasher?  Это все так и было задумано?


-- 
ldv

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

Re: [devel] cronbuild --email

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 02:10:23AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> > > Если есть время на подобные забавы, хотел бы еще раз
> > > обратить ваше внимание на баг #27637 
> > > "ssh git.alt task run --email <mail addr> option"
> > 
> > Произвольный email это EWONTFIX, я готов отправлять письма только
> > зарегистрированным пользователям git.alt, которые предположительно
> > знали, на что шли.
> 
> Ок, хорошо, даже можно ограничивать список пользователей,
> пользующихся этой опцией.

Зачем?

> мне нужно только, чтобы псевдопользователь cronbuild
> мог переадресовывать сообщения о сборке на <nick>@altlinux.org.
> 
> Произвольный e-mail не нужен, <nick>@altlinux.org достаточно.

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

Допустим, что реализован некий интерфейс, позволяющий любому мейнтейнеру
заказать какие-то cronbuild-сборки каких-то пакетов.  Если этот любой
мейнтейнер не входит в ACL этих пакетов, то зачем ему
- заказывать cronbuild-сборки этих пакетов?
- получать письма о cronbuild-сборке этих пакетов?


-- 
ldv

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

Re: [devel] gear->srpm->void

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 05:35:49AM +0400, Dmitry V. Levin wrote:
> исходников которых по сути нет ни в gears, ни в SRPMS?

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


-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] cronbuild --email

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 05:50:20AM +0400, Dmitry V. Levin wrote:
> Это можно, хотя я решительно не понимаю, зачем такое могло бы
> понадобиться, когда адресаты писем и так вычисляются согласно ACL
> собираемых пакетов.  Зачем кому-то могло бы понадобиться получить
> письмо о сборке пакета, если этот кто-то не входит в ACL этого пакета?

acl пакета может быть вида <лидер, ушел из team> @everybody.

опция --email, может некорркетно ее так называть, 
может быть, --task-leader правильнее, это человек,
который заказал какому-то сервису сборку пакета.

Этой опцией убивается 2 зайца:
1) письмо не отсылается на cronbuild@. [ а то робот меня спамит :( ]
2) письмо гарантированно отсылается человеку, 
заказавшему сборку, даже если его явно нет в acl.
(он неявно в <лидер, ушел из team> @everybody).

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] cronbuild --email

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 05:32:50AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 05:50:20AM +0400, Dmitry V. Levin wrote:
> > Это можно, хотя я решительно не понимаю, зачем такое могло бы
> > понадобиться, когда адресаты писем и так вычисляются согласно ACL
> > собираемых пакетов.  Зачем кому-то могло бы понадобиться получить
> > письмо о сборке пакета, если этот кто-то не входит в ACL этого пакета?
> 
> acl пакета может быть вида <лидер, ушел из team> @everybody.
> 
> опция --email, может некорркетно ее так называть, 
> может быть, --task-leader правильнее, это человек,
> который заказал какому-то сервису сборку пакета.
> 
> Этой опцией убивается 2 зайца:
> 1) письмо не отсылается на cronbuild@. [ а то робот меня спамит :( ]
> 2) письмо гарантированно отсылается человеку, 
> заказавшему сборку, даже если его явно нет в acl.
> (он неявно в <лидер, ушел из team> @everybody).

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


-- 
ldv

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

Re: [devel] cronbuild --email

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 06:40:16AM +0400, Dmitry V. Levin wrote:
> > опция --email, может некорркетно ее так называть, 
> > может быть, --task-leader правильнее, это человек,
> > который заказал какому-то сервису сборку пакета.
> > 
> > Этой опцией убивается 2 зайца:
> > 1) письмо не отсылается на cronbuild@. [ а то робот меня спамит :( ]
> > 2) письмо гарантированно отсылается человеку, 
> > заказавшему сборку, даже если его явно нет в acl.
> > (он неявно в <лидер, ушел из team> @everybody).
> 
> Это все выглядит как уход от проблемы устаревания ACL.
> Поскольку ACL - это первичный источник информации для всех типов рассылок,
> связанных с пакетами, давайте лучше подумаем, как решить эту проблему.

Здесь принципиально, что заказчик не обязан _явно_ присутствовать в acl.
Разных сервисов автоматизации уже сейчас много. И будет больше.

Например, заказчик может приказать роботу NMU: "добавь в трвнзакцию
как NMU пересборку всех пакетов, зависящих от моей библиотеки".

Сейчас в gb-task-send-email используется `cat task/owner`.
Хочется
с опцией --email/--task-leader/--recepient/как угодно
__подменять__ task/owner на указанную персону.

Подмена еще хороша тем, что письмо тогда на `cat task/owner` 
(т.е. роботу) высылаться не будет.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [JT] Re: srpm

[REAL]

11.10.2012 03:04, Igor Zubkov пишет:
> Вы не только свои пакеты собираете из gear, но и чужие. К примеру, вы
> пересобрали пакет libdbf для set-зависимостей. Вот этот коммит --
> http://git.altlinux.org/people/real/packages/?p=libdbf.git;a=commitdiff;h=7a14d131c5d137c853146ea7f7b948e9d33f002b
> . И в нагрузку сменили srpm на gear. Зачем? А потом ещё и перевесили
> пакет обратно на nobody@.

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

-- 

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

Re: [devel] gear->srpm

[REAL]

11.10.2012 06:06, Igor Vlasenko пишет:
> Потом когда нужно отправить пакет мне,
> я его мог при необходимости расконвертировать.
> Теперь придется каждый раз обрашаться к администратору Сизифа :(

Ну я чужие (т.е. те, которые не на nobody@) не перевожу с srpm на 
gear. Исключение - пакеты lav@, но он непротив :)

-- 

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

Re: [devel] people->robots delegation

[Dmitry V. Levin]

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

On Thu, Oct 11, 2012 at 06:00:49AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 06:40:16AM +0400, Dmitry V. Levin wrote:
> > > опция --email, может некорркетно ее так называть, 
> > > может быть, --task-leader правильнее, это человек,
> > > который заказал какому-то сервису сборку пакета.
> > > 
> > > Этой опцией убивается 2 зайца:
> > > 1) письмо не отсылается на cronbuild@. [ а то робот меня спамит :( ]
> > > 2) письмо гарантированно отсылается человеку, 
> > > заказавшему сборку, даже если его явно нет в acl.
> > > (он неявно в <лидер, ушел из team> @everybody).
> > 
> > Это все выглядит как уход от проблемы устаревания ACL.
> > Поскольку ACL - это первичный источник информации для всех типов рассылок,
> > связанных с пакетами, давайте лучше подумаем, как решить эту проблему.
> 
> Здесь принципиально, что заказчик не обязан _явно_ присутствовать в acl.
> Разных сервисов автоматизации уже сейчас много. И будет больше.
> 
> Например, заказчик может приказать роботу NMU: "добавь в трвнзакцию
> как NMU пересборку всех пакетов, зависящих от моей библиотеки".

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

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

> Сейчас в gb-task-send-email используется `cat task/owner`.
> Хочется
> с опцией --email/--task-leader/--recepient/как угодно
> __подменять__ task/owner на указанную персону.

Для того, чтобы полностью исключить робота, недостаточно подменить
TASK_ID/task/owner, еще нужно подменить все TASK_ID/gears/*/userid.

> Подмена еще хороша тем, что письмо тогда на `cat task/owner` 
> (т.е. роботу) высылаться не будет.

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


-- 
ldv

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 00:47:32 Dmitry V. Levin wrote:

[...]
> Возможно, check-git-inheritance теперь должен стать интерактивным и
> задавать нетривиальные вопросы.
О, хоть что-то!

P.S.
В systemd уже добавили поддержку libqrencode, значит и туда можно ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 01:38:24 Sergey Bolshakov wrote:
> >>>>> "Dmitry" == Dmitry V Levin <ldv-
u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> [skipped]
> 
>  > Возможно, check-git-inheritance теперь должен стать интерактивным и
>  > задавать нетривиальные вопросы.
> 
> дадад, двачую %triggerpostun-капчу.
Кстати, показать URL страницы с капчей для подтверждения не так уж сложно ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] people->robots delegation

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 03:08:56PM +0400, Dmitry V. Levin wrote:
> > Здесь принципиально, что заказчик не обязан _явно_ присутствовать в acl.
> > Разных сервисов автоматизации уже сейчас много. И будет больше.
> 
> Если робот настолько не при чем, что даже отчет о сборке нужно направлять
> заказчику, то и владельцем задания со всеми подзаданиями следует тогда
> считать заказчика, и все остальные проверки применять к заказчику, а не к
> роботу.

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

Здесь проблема что будет раньше, курица или яйцо.
Опция --email мне и нужна, чтобы начать разработку такой инфраструктуры
(пока со стороны робота). Когда такая инфраструктура будет разработана
и готова, то, возможно, опцию --email можно будет и убрать,
новая инфраструктура ее заменит. 

Но, новой инфраструктуры нет, и чтобы начать под нее писать код,
мне нужна опция --email.


-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

On Thu, Oct 11, 2012 at 02:41:59AM +0400, Dmitry V. Levin wrote:
> до тех пор, пока еще есть хотя бы один живой мейнтейнер, проверка
> наследования для сопровождаемых им пакетов имеет смысл.

С проверкой на наследнование та неприятность, что у нее низкое 
отношение Сигнал/Шум.

Если после срабатывания проверки на наследование 
дополнительно отфильтровывать хотя бы тривиальные NMU
(сделать srpmcmp, и если он имеет вид в точности

--- spec
+++ spec
@@@ rel @@@
 ...
-Release
+Release
 ...
@@@ changelog @@@
 ...
 %changelog
+- bla bla

то наследывать там __по_сути__ нечего)

То от нее было бы больше толку. 
Сейчас же там слишком много шума.
9/10 случаев, что полезных изменений нет,
втягивать нечего, а проверка срабатывает 
и ставит палки в колеса.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Igor Vlasenko]

Другими словами,
хотелось бы, чтобы проверка на наследование
проверяла, есть ли действительно там что-то 
реальное наследывать, а не была формальным
бюрократическим препятствием,

Вроде требования справки из зоопарка, что не верблюд.


On Thu, Oct 11, 2012 at 03:57:06PM +0300, Igor Vlasenko wrote:
> С проверкой на наследнование та неприятность, что у нее низкое 
> отношение Сигнал/Шум.
> 
> Если после срабатывания проверки на наследование 
> дополнительно отфильтровывать хотя бы тривиальные NMU
> (сделать srpmcmp, и если он имеет вид в точности
> 
> --- spec
> +++ spec
> @@@ rel @@@
>  ...
> -Release
> +Release
>  ...
> @@@ changelog @@@
>  ...
>  %changelog
> +- bla bla
> 
> то наследывать там __по_сути__ нечего)
> 
> То от нее было бы больше толку. 
> Сейчас же там слишком много шума.
> 9/10 случаев, что полезных изменений нет,
> втягивать нечего, а проверка срабатывает 
> и ставит палки в колеса.
> 
> -- 
> 
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] gear->srpm

[Anton Farygin]

11.10.2012 16:09, Sergey V Turchin пишет:
>> >  дадад, двачую %triggerpostun-капчу.
> Кстати, показать URL страницы с капчей для подтверждения не так уж сложно;-)

Сейчас модно показывать QR-коды...

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 17:28:56 Anton Farygin wrote:
> 11.10.2012 16:09, Sergey V Turchin пишет:
> >> >  дадад, двачую %triggerpostun-капчу.
> > 
> > Кстати, показать URL страницы с капчей для подтверждения не так уж
> > сложно;-)
> Сейчас модно показывать QR-коды...
Я уже написал об этом ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] gear->srpm

[Michael Shigorin]

On Thu, Oct 11, 2012 at 03:44:44AM +0400, Dmitry V. Levin wrote:
> Если для srpm-пакетов неудобно делать всякого рода NMU, то это
> не значит, что надо совершенствовать средства исправления
> последствий проведенного NMU, уничтожающие историю изменений
> пакетов.

Если NMU -- это blind rebuild, то вся нужная история
сохранена в %changelog.

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 18:38:24 Michael Shigorin wrote:
> On Thu, Oct 11, 2012 at 03:44:44AM +0400, Dmitry V. Levin wrote:
> > Если для srpm-пакетов неудобно делать всякого рода NMU, то это
> > не значит, что надо совершенствовать средства исправления
> > последствий проведенного NMU, уничтожающие историю изменений
> > пакетов.
> 
> Если NMU -- это blind rebuild, то вся нужная история
> сохранена в %changelog.
ssh git.alt blind-rebuild pkg version ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] cronbuild --email

[Michael Shigorin]

On Thu, Oct 11, 2012 at 06:40:16AM +0400, Dmitry V. Levin wrote:
> Поскольку ACL - это первичный источник информации для всех
> типов рассылок, связанных с пакетами, давайте лучше подумаем,
> как решить эту проблему.

Вообще-то это побочный эффект -- piggybacking, так сказать.

Может, рядом с acl завести notify, который можно будет add/rm
и который будет также декларировать интерес в происходящем
с пакетом, но не определять режим доступа к нему?

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

[devel] [JT] right to compile

[Michael Shigorin]

On Thu, Oct 11, 2012 at 03:51:05PM +0400, Sergey V Turchin wrote:
> > Возможно, check-git-inheritance теперь должен стать
> > интерактивным и задавать нетривиальные вопросы.
> О, хоть что-то!

Нет-нет, давайте начнём с hasher.  Или ещё лучше -- gcc.

> P.S.  В systemd уже добавили поддержку libqrencode,

Туда добавили udev, это минус.  Но это уже достало Линуса,
и это плюс. :)

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

Re: [devel] people->robots delegation

[Michael Shigorin]

On Thu, Oct 11, 2012 at 03:16:21PM +0300, Igor Vlasenko wrote:
> Не все еще морально готовы к такому настолько светлому будущему.
> В настоящее время кому-то может показаться удобным через
> контроль acl иметь возможность разрешить заливку человеку,
> но запретить роботу.

Думаю, в сколь угодно светлом будущем (if any) будут ситуации
предсказуемо неавтоматизируемых обновлений, которых заведомо
лучше избежать.  И это скорее тянет на один бит "human only"
(или же на некий "human level", что неплохо себя показывает
на том же stackoverflow.com/serverfault.com), чем на различение
человека и робота по именам в ACL.

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

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

Re: [devel] gear->srpm

[Michael Shigorin]

On Thu, Oct 11, 2012 at 07:44:22PM +0400, Sergey V Turchin wrote:
> > Если NMU -- это blind rebuild, то вся нужная история
> > сохранена в %changelog.
> ssh git.alt blind-rebuild pkg version ;-)

А что за version?

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

Re: [devel] gear->srpm

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

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

On Thu, Oct 11, 2012 at 04:01:58PM +0300, Igor Vlasenko wrote:

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

Сам факт возникновения такого конфликта возникает из-за кривизны workflow.

The Right Way(tm) -- использовать при любых модификациях в качестве основы
не локальный репозиторий, а то, что лежит в /gears или /srpms. Тогда
никаких таких конфликтов быть физически не может (кроме редких race, при
параллельной работе).

Сейчас ограничение этому в том, что внутри gear-репозитория далеко не
всегда находится достаточно информации для работы с ним (см. примеры с
внешними git, а также испоьлзованием git-svn).

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

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] gear->srpm

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

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

On Thu, Oct 11, 2012 at 07:44:22PM +0400, Sergey V Turchin wrote:

>> Если NMU -- это blind rebuild, то вся нужная история
>> сохранена в %changelog.
> ssh git.alt blind-rebuild pkg version ;-)

ssh git.alt task add blind-rebuild pkg

В blind-rebuild NMU никаих version/release, только добавлять .1 к release
автоматом! :)

И это может быть нужно внутри task'ов.


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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

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

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

On Tue, Oct 09, 2012 at 12:28:53AM +0300, Michael Shigorin wrote:

MS> Вот этого "удобнее" замечаю только на спеке, а это негусто.
MS> Возможно, что-то опять пропустил :)

К примеру нужно мне сделать патчик, при использовании такого стиля
репозитория. Делается это так:

- тупо беру и хакаю, прямо в репозитории, используя rpmbb для тестовой
  пересборки.
- добившись того результата, что мне нужно, пишу git diff HEAD >
  somepatch.patch
- git checkout -f package-subdir

Итог: у меня есть готовый проверенный патч.

Кроме того, в репозитории такого типа точно также отслеживается факт
изменения патчей (хотя diff читать и неудобно уже, по сравнению с
нормальным git-repo, но в случае с srpm нельзя никак).

>> packages/ разумнее воспринимать просто как некий 'кэш'. Я
>> сейчас завел практику, при которой я беру репозитории прямо из
>> gears. Это еще и помогает в случае, когда кто-то сделал NMU.
MS> А так проще упустить то, когда у людей есть наработки, которые
MS> ещё не попали в сизиф, но которые стоит учесть.  Это более редкий
MS> случай (особенно по нынешним временам), но его стоит помнить.

В таких случаях все-таки принято следовать принципу "кто первый встал,
того и тапки". Видимо тому, у кого есть не попавшие в Сизиф наработки
придется делать merge или rebase.

Что опять же, при такой стратегии работы, крайне просто.

>> А вообще надо бы нам всем, кто пишет себя тучу хаков собраться
>> -- и стандартизировать свои хаки.
MS> О чём и.  Причём начать стоит с apt.conf+sources.list'ов, IMHO,
MS> вместе со стандартизацией дефолтного предполагаемого места для
MS> репозиториев (предварительно договорились о /srv/public/mirror
MS> по мотивам alterator-mirror, а там уж хоть симлинки, хоть как).

Согласен. И как будем договариваться? :)

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

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

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

On Tue, Oct 09, 2012 at 12:28:53AM +0300, Michael Shigorin wrote:

MS> О чём и.  Причём начать стоит с apt.conf+sources.list'ов, IMHO,
MS> вместе со стандартизацией дефолтного предполагаемого места для
MS> репозиториев (предварительно договорились о /srv/public/mirror
MS> по мотивам alterator-mirror, а там уж хоть симлинки, хоть как).

Ты можешь предложить вариант, который будет принят как минимум в
etersoft-build-utils?

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] gear->srpm

[Vladislav Zavjalov]

On Thu, Oct 11, 2012 at 08:38:48PM +0400, Денис Смирнов wrote:
> On Thu, Oct 11, 2012 at 04:01:58PM +0300, Igor Vlasenko wrote:
> 
> The Right Way(tm) -- использовать при любых модификациях в качестве основы
> не локальный репозиторий, а то, что лежит в /gears или /srpms. Тогда
> никаких таких конфликтов быть физически не может (кроме редких race, при
> параллельной работе).

Кстати, уже очень давно есть пожелание, чтобы ssh git.alt find-package
искал и в gears и в srpms.

Слава

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Thu, Oct 11, 2012 at 08:48:42PM +0400, Денис Смирнов wrote:
> - git checkout -f package-subdir

А, вот ты как.  Спасибо.

> >> packages/ разумнее воспринимать просто как некий 'кэш'. Я
> >> сейчас завел практику, при которой я беру репозитории прямо из
> >> gears. Это еще и помогает в случае, когда кто-то сделал NMU.
> > А так проще упустить то, когда у людей есть наработки, которые
> > ещё не попали в сизиф, но которые стоит учесть.  Это более редкий
> > случай (особенно по нынешним временам), но его стоит помнить.
> В таких случаях все-таки принято следовать принципу "кто первый
> встал, того и тапки". Видимо тому, у кого есть не попавшие в
> Сизиф наработки придется делать merge или rebase.

Это если он сам ещё есть.  Иногда остались одни наработки.

> Согласен. И как будем договариваться? :)

Отдельным тредом. :)

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

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

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

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

On Thu, Oct 11, 2012 at 08:47:44PM +0300, Michael Shigorin wrote:
>> - git checkout -f package-subdir
> А, вот ты как.  Спасибо.

Я очень ленивый, потому люблю такие фокусы :)

Правда сейчас я больше пользуюсь репозиториями с .gear/rules типа:

tar: asterisk name=@name@-@version@ base=@name@-@version@
diff: upstream:asterisk .:asterisk name=@name@-@version@.patch

Но если патчей много, то это как раз репо с большим мегапатчем :(

>> В таких случаях все-таки принято следовать принципу "кто первый
>> встал, того и тапки". Видимо тому, у кого есть не попавшие в
>> Сизиф наработки придется делать merge или rebase.
> Это если он сам ещё есть.  Иногда остались одни наработки.

srpm тут, как ты понимаешь, не поможет. И автоматика никакая тоже. Но из
чужого git repo вполне можно утащить, если он не забыл его опубликовать.

>> Согласен. И как будем договариваться? :)
> Отдельным тредом. :)

Сделаешь? :)

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: srpm (was: git.alt task check-git-inheritance)

[Sergey V Turchin]

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

On 11 октября 2012 20:48:42 Денис Смирнов wrote:

[...]
> Итог: у меня есть готовый проверенный патч.
> 
> Кроме того, в репозитории такого типа точно также отслеживается факт
> изменения патчей (хотя diff читать и неудобно уже,
Само точечное изменение да, не особо, но сам патч удобно прямо через web-
интерфейс.

> по сравнению с нормальным git-repo
В нем видно только точечное изменение, а при rediff это лишь кусок патча. Сам 
патч уже может быть невозможно представить при помощи URL.

> , но в случае с srpm нельзя никак).
Ага.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 19:05:32 Michael Shigorin wrote:
> On Thu, Oct 11, 2012 at 07:44:22PM +0400, Sergey V Turchin wrote:
> > > Если NMU -- это blind rebuild, то вся нужная история
> > > сохранена в %changelog.
> > 
> > ssh git.alt blind-rebuild pkg version ;-)
> 
> А что за version?
Уже одетый стоя писал убегая :-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 11 октября 2012 20:41:46 Денис Смирнов wrote:
> On Thu, Oct 11, 2012 at 07:44:22PM +0400, Sergey V Turchin wrote:
> >> Если NMU -- это blind rebuild, то вся нужная история
> >> сохранена в %changelog.
> > 
> > ssh git.alt blind-rebuild pkg version ;-)
> 
> ssh git.alt task add blind-rebuild pkg
> 
> В blind-rebuild NMU никаих version/release, только добавлять .1 к release
> автоматом! :)
> 
> И это может быть нужно внутри task'ов.
FR повесите или я?

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] gear->srpm

[Anton Farygin]

11.10.2012 21:08, Vladislav Zavjalov пишет:
> Кстати, уже очень давно есть пожелание, чтобы ssh git.alt find-package
> искал и в gears и в srpms.

+1

Re: [devel] gear->srpm

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

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

On Fri, Oct 12, 2012 at 02:30:02PM +0400, Sergey V Turchin wrote:
>> ssh git.alt task add blind-rebuild pkg
>> В blind-rebuild NMU никаих version/release, только добавлять .1 к release
>> автоматом! :)
>> И это может быть нужно внутри task'ов.
> FR повесите или я?

Вешайте!

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

On 12 октября 2012 17:26:56 Денис Смирнов wrote:

[...]
> Вешайте!
http://bugs.altlinux.org/27840

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Sergey Afonin]

On Wednesday 19 October 2011, Dmitry V. Levin wrote:

> > > $ ssh git.alt task check-git-inheritance --help
> > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > <commit_sha_id>
> > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > girar-task check-git-inheritance <task_id> <subtask_number> show
> > ?
> 
> Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> наследования, в состоянии вычислить искомый <commit_sha_id>
> самостоятельно.

Прошло много лет, и встал вопрос:

error: #200: libpcap.git tag `1.9.1-alt2' is not inherited from /gears/l/libpcap.git branch `p8'
2023-Jul-17 11:52:07 :: gears inheritance check FAILED for: #200 
2023-Jul-17 11:52:07 :: task #325063 for p8 FAILED

Желания обновлять libpcap в p8 у меня нет (пока по крайней мере),
хочу просто задание-карман сделать для себя (потому как, вероятно,
там что-то ещё из репозитория пересобрать потребуется).

Мантейнер, может быть, и в состоянии вычислить коммит, но вот вопрос,
какой ценой? Последний коммит в p8 не подходит, последний коммит в p9
не подходит. И надо судорожно вспоминать, какой именно коммит имел ввиду
автор check-git-inheritance, и как именно его в одну команду найти.

Причём задача стоит не Git срочно подучить, а разобраться, почему sflow
не работает совсем в другой системе, и надо просто для p8 по быстрому 
собрать пакет, аналогичный той системе.

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

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Vitaly Chikunov]

Sergey,

On Mon, Jul 17, 2023 at 04:51:25PM +0400, Sergey Afonin wrote:
> On Wednesday 19 October 2011, Dmitry V. Levin wrote:
> 
> > > > $ ssh git.alt task check-git-inheritance --help
> > > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > > <commit_sha_id>
> > > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > > girar-task check-git-inheritance <task_id> <subtask_number> show
> > > ?
> > 
> > Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> > наследования, в состоянии вычислить искомый <commit_sha_id>
> > самостоятельно.
> 
> Прошло много лет, и встал вопрос:
> 
> error: #200: libpcap.git tag `1.9.1-alt2' is not inherited from /gears/l/libpcap.git branch `p8'

Последний commit из репозитория /gears/l/libpcap.git branch p8,
т.е. 805cc2b6de8835d65d2b7a1b2360828a37492bd4

Но установить в check-git-inheritance для p8 вы его не сможете потому
что это может сделать только группа maint. Вот это как раз неудобно.


> 2023-Jul-17 11:52:07 :: gears inheritance check FAILED for: #200 
> 2023-Jul-17 11:52:07 :: task #325063 for p8 FAILED
> 
> Желания обновлять libpcap в p8 у меня нет (пока по крайней мере),
> хочу просто задание-карман сделать для себя (потому как, вероятно,
> там что-то ещё из репозитория пересобрать потребуется).
> 
> Мантейнер, может быть, и в состоянии вычислить коммит, но вот вопрос,
> какой ценой? Последний коммит в p8 не подходит, последний коммит в p9
> не подходит. И надо судорожно вспоминать, какой именно коммит имел ввиду
> автор check-git-inheritance, и как именно его в одну команду найти.
> 
> Причём задача стоит не Git срочно подучить, а разобраться, почему sflow
> не работает совсем в другой системе, и надо просто для p8 по быстрому 
> собрать пакет, аналогичный той системе.
> 
> -- 
> С уважением, Сергей Афонин
> asy@kraft-s.ru
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Sergey Afonin]

On Monday 17 July 2023, Vitaly Chikunov wrote:

> > Прошло много лет, и встал вопрос:
> > 
> > error: #200: libpcap.git tag `1.9.1-alt2' is not inherited from /gears/l/libpcap.git branch `p8'
> 
> Последний commit из репозитория /gears/l/libpcap.git branch p8,
> т.е. 805cc2b6de8835d65d2b7a1b2360828a37492bd4

Хм. То есть так вот частично нельзя?

$ ssh git task check-git-inheritance 325063 200 disable 805cc2b6de883
Enter passphrase for key '/home/asy/.ssh/asy-key-ssh-ed25519':
task check-git-inheritance: invalid commit id.

Действительно, если указать полностью, то ошибка меняется.
Надо тогда в --help написать <commit_sha_full_id>, а то везде
сокращённые работают, а тут нет.

> Но установить в check-git-inheritance для p8 вы его не сможете потому
> что это может сделать только группа maint. Вот это как раз неудобно.

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

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

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Dmitry V. Levin]

On Mon, Jul 17, 2023 at 04:51:25PM +0400, Sergey Afonin wrote:
> On Wednesday 19 October 2011, Dmitry V. Levin wrote:
> 
> > > > $ ssh git.alt task check-git-inheritance --help
> > > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > > <commit_sha_id>
> > > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > > girar-task check-git-inheritance <task_id> <subtask_number> show
> > > ?
> > 
> > Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> > наследования, в состоянии вычислить искомый <commit_sha_id>
> > самостоятельно.
> 
> Прошло много лет, и встал вопрос:
> 
> error: #200: libpcap.git tag `1.9.1-alt2' is not inherited from /gears/l/libpcap.git branch `p8'
> 2023-Jul-17 11:52:07 :: gears inheritance check FAILED for: #200 
> 2023-Jul-17 11:52:07 :: task #325063 for p8 FAILED
> 
> Желания обновлять libpcap в p8 у меня нет (пока по крайней мере),
> хочу просто задание-карман сделать для себя (потому как, вероятно,
> там что-то ещё из репозитория пересобрать потребуется).

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


-- 
ldv

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Sergey Y. Afonin]

On Monday 17 July 2023, Dmitry V. Levin wrote:

> > Желания обновлять libpcap в p8 у меня нет (пока по крайней мере),
> > хочу просто задание-карман сделать для себя (потому как, вероятно,
> > там что-то ещё из репозитория пересобрать потребуется).
> 
> Если коммит задания не планируется, то диагностику про наследование
> коммитов, вообще говоря, можно игнорировать.
 
Так сборка встаёт, если туда надо ещё одно подзадание добавить.
Просто тут ещё не добавил. Но, на самом деле, в данном конкретном 
случае необходимость в группе пакетов уже отпала, так обошёлся.

-- 
С уважением, Сергей Афонин

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Dmitry V. Levin]

On Mon, Jul 17, 2023 at 11:16:40PM +0400, Sergey Y. Afonin wrote:
> On Monday 17 July 2023, Dmitry V. Levin wrote:
> 
> > > Желания обновлять libpcap в p8 у меня нет (пока по крайней мере),
> > > хочу просто задание-карман сделать для себя (потому как, вероятно,
> > > там что-то ещё из репозитория пересобрать потребуется).
> > 
> > Если коммит задания не планируется, то диагностику про наследование
> > коммитов, вообще говоря, можно игнорировать.
>  
> Так сборка встаёт, если туда надо ещё одно подзадание добавить.

Нет.


-- 
ldv

Re: [devel] [devel-announce] I: git.alt task check-git-inheritance

[Sergey Afonin]

On Monday 17 July 2023, Dmitry V. Levin wrote:

> > > Если коммит задания не планируется, то диагностику про наследование
> > > коммитов, вообще говоря, можно игнорировать.
> >  
> > Так сборка встаёт, если туда надо ещё одно подзадание добавить.
> 
> Нет.

И правда. Спасибо. Но подсказку про check-git-inheritance про commit_sha_id
стоит поменять всё же. Баг повесить?

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