[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:38 UTC (permalink / raw)]

Re: [devel] gear

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

Re: [devel] gear

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

[devel] [JT] Re: gear

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

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

[@ 2023-07-17 12:51 UTC (permalink / raw)]

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

[@ 2023-07-17 13:08 UTC (permalink / raw)]

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

[@ 2023-07-17 13:57 UTC (permalink / raw)]

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

[@ 2023-07-17 16:11 UTC (permalink / raw)]

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

[@ 2023-07-17 19:16 UTC (permalink / raw)]

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

[@ 2023-07-17 19:24 UTC (permalink / raw)]

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

[@ 2023-07-18 8:00 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 18:00 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

[Dmitry V. Levin]

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

On Fri, Oct 05, 2012 at 07:27:25PM +0400, Sergey Y. Afonin wrote:
> On Wednesday 19 October 2011, Dmitry V. Levin wrote:
> 
> > Команда предназначена для осознанного обхода проверки наследования в
> > случаях, когда такой обход необходим, например:
> 
> А вот с таким вариантом что можно сделать ?
> 
> 2012-Oct-05 14:54:15 :: [i586] #300 libclamav-devel: install check OK
> 2012-Oct-05 14:54:16 :: [x86_64] #300 libclamav-devel: install check OK
> 2012-Oct-05 14:54:16 :: gears inheritance check OK
> clamav-0.97.6-alt0.M41.1.src.rpm: missing last changelog entry from clamav-0.97.3-alt0.M41.1.src.rpm:
> * Thu Oct 20 2011       asy@altlinux    0.97.3-alt0.M41.1
> 2012-Oct-06 14:54:16 :: srpm inheritance check FAILED
> 2012-Oct-05 14:54:16 :: task #82017 for 4.1 FAILED
> 
> clamav-0.97.6-alt0.M41.1.src.rpm, действительно, сделан из clamav-0.97.6-alt1,
> а не из 0.97.3-alt0.M41.1. Можно, конечно, недостающее скопировать, но правильно
> ли оно ? git-репозитарий ветвить не хочется что-то...

Сборка из srpm?  Если есть уверенность, что никакие изменения из
0.97.3-alt0.M41.1 не потерялись случайно, можно смержить %changelog.


-- 
ldv

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

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

[Sergey Y. Afonin]

On Saturday 06 October 2012, Dmitry V. Levin wrote:

> Сборка из srpm?

Да.

> Если есть уверенность, что никакие изменения из 0.97.3-alt0.M41.1
> не потерялись случайно,

В данном случае есть: пакет просто не собирается без них. :-)

> можно смержить %changelog.  

Почти так и сделал в итоге, но как-то оно... некомфортно, что ли...

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

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

[Sergey V Turchin]

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

On 6 октября 2012 04:58:37 Dmitry V. Levin wrote:

[...]
> Сборка из srpm?  Если есть уверенность, что никакие изменения из
> 0.97.3-alt0.M41.1 не потерялись случайно
Не конкретно к этому случаю, но у меня есть пример(не скажу), когда мантернер 
намеренно плевал на потерю изменений, потому что "было проще взять srpm".
А известно стало только когда я лично проверил.

P.S.
Я бы уже начал закручивать гайки для srpm. По крайней мере для сизифа.

P.P.S.
По себе знаю: пока не пнут, от 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] srpm (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Mon, Oct 08, 2012 at 03:12:40PM +0400, Sergey V Turchin wrote:
> P.S.  Я бы уже начал закручивать гайки для srpm. По крайней
> мере для сизифа.

Да закручивали уже, не помогает.

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

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

[Sergey V Turchin]

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

On 8 октября 2012 15:42:42 Michael Shigorin wrote:
> On Mon, Oct 08, 2012 at 03:12:40PM +0400, Sergey V Turchin wrote:
> > P.S.  Я бы уже начал закручивать гайки для 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 --]

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

[Michael Shigorin]

On Mon, Oct 08, 2012 at 05:11:19PM +0400, Sergey V Turchin wrote:
> > > P.S.  Я бы уже начал закручивать гайки для srpm. По крайней
> > > мере для сизифа.
> > Да закручивали уже,
> Не замечал.

Когда возврат к srpm был объявлен ретроградским и выполнялся
только вручную "через визиря".

> > не помогает.
> Т.е.? Отправляют в сизиф в обход сборочницы? ;-)

Т.е. оказалось, что не для всего gear repo оптимальны.
Серж, мне они тоже для многого нравятся, но не для всего :)
А для этого многого накостылено у каждого своих скриптов,
что не помогает вводить в курс дела новоприбывших.

-- 
 ---- 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)

[Sergey V Turchin]

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

On 8 октября 2012 17:08:13 Michael Shigorin wrote:
> On Mon, Oct 08, 2012 at 05:11:19PM +0400, Sergey V Turchin wrote:
> > > > P.S.  Я бы уже начал закручивать гайки для srpm. По крайней
> > > > мере для сизифа.
> > > 
> > > Да закручивали уже,
> > 
> > Не замечал.
> 
> Когда возврат к srpm был объявлен ретроградским и выполнялся
> только вручную "через визиря".
Да это вообще уже пора запретить.

> > > не помогает.
> > Т.е.? Отправляют в сизиф в обход сборочницы? ;-)
> Т.е. оказалось, что не для всего gear repo оптимальны.
Не может быть, т.к. их вид более универсален. От вида, как результат gear-
srpmimport, который выглядит почти как тот же srpm, до ветки git, в которую 
можно любое изменение применять из оригинальной ветки.

> Серж, мне они тоже для многого нравятся, но не для всего :)
> А для этого многого
> накостылено у каждого своих скриптов,
> что не помогает вводить в курс дела новоприбывших.
У новоприбывших ничего не накостылено, а переделать костыли для gear не вижу 
особых проблем.

-- 
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 (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Mon, Oct 08, 2012 at 06:26:04PM +0400, Sergey V Turchin wrote:
> > Когда возврат к srpm был объявлен ретроградским и выполнялся
> > только вручную "через визиря".
> Да это вообще уже пора запретить.

Прокрустов репозиторий -- штука неинтересная, поверь.

> > > > не помогает.
> > > Т.е.? Отправляют в сизиф в обход сборочницы? ;-)
> > Т.е. оказалось, что не для всего gear repo оптимальны.
> Не может быть

Ладно, пусть другие выскажутся, ну или sisyphus-cybertalk@
почитай за последние год-два по слову "srpm".  Например,
кучу перловки вернули, т.к. нет смысла в локальном гите
при живом cpan и архиве в /srpms.

> т.к. их вид более универсален.

Ещё раз: он малополезен, кроме как для архива.  По крайней
мере мне.  С патчами мороки прибавляется, помощи при этом
с ними -- никакой.  И для переезда на апстримный гит ничем
не помогает -- всё равно выбрасывать историю и делать заново.

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

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

welcome to devel-newbies@ :)

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

Так они для gear тоже есть -- просто в репо и на вики нет
следующего шага по обобщению опыта поддержки пакетов в gear.

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

Самое лучшее, что мы можем сделать для того, чтобы перетаскивать
людей на gear -- это обобщать скрипты и документацию.
Будет понятно и удобно, сами придут.

-- 
 ---- 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)

[Sergey V Turchin]

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

On 8 октября 2012 17:36:33 Michael Shigorin wrote:
> On Mon, Oct 08, 2012 at 06:26:04PM +0400, Sergey V Turchin wrote:
> > > Когда возврат к srpm был объявлен ретроградским и выполнялся
> > > только вручную "через визиря".
> > 
> > Да это вообще уже пора запретить.
> 
> Прокрустов репозиторий -- штука неинтересная, поверь.
Я не в курсе этой неинтересной штуки, поэтому про нее можно не рассказывать 
;-)

> > > > > не помогает.
> > > > 
> > > > Т.е.? Отправляют в сизиф в обход сборочницы? ;-)
> > > 
> > > Т.е. оказалось, что не для всего gear repo оптимальны.
> > 
> > Не может быть
> 
> Ладно, пусть другие выскажутся, ну или sisyphus-cybertalk@
> почитай за последние год-два по слову "srpm".  Например,
> кучу перловки вернули, т.к. нет смысла в локальном гите
> при живом cpan и архиве в /srpms.
>
> > т.к. их вид более универсален.
> 
> Ещё раз: он малополезен, кроме как для архива.
Для чего конкретно он малополезен? У меня для всего полезен.

> По крайней
> мере мне.  С патчами мороки прибавляется,
Никакой не прибавляется.

> помощи при этом с ними -- никакой. 
Помощь в том, что вреда гораздо меньше.

> И для переезда на апстримный гит ничем
> не помогает -- всё равно выбрасывать историю и делать заново.
А кто сказал, что должно помочь?

> Т.е. для переезда, чтоб осваивать -- да, согласен.
> Для автогенерируемого архива -- тоже замечательно.
> Но это второстепенные задачи.
Я их вообще не имел ввиду.

> > > А для этого многого накостылено у каждого своих скриптов,
> > > что не помогает вводить в курс дела новоприбывших.
> > 
> > У новоприбывших ничего не накостылено
> welcome to devel-newbies@ :)
Ну, перекостылят :-)
 
> > а переделать костыли для gear не вижу особых проблем.
> 
> Так они для gear тоже есть -- просто в репо и на вики нет
> следующего шага по обобщению опыта поддержки пакетов в gear.
> 
> Это не смертельно, просто и так уже из-за слишком жёсткого
> подхода получилось много плохого вследствие использования
> неоправданно сложного инструментария людьми, которые его
> не освоили как следует.
Уже не один год успешно используют возможность "не осваивать" ;-)

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

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

> Будет понятно и удобно, сами придут.
Ага, в убунту. Раздел фантастики на 3-м этаже ;-)

-- 
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 (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Mon, Oct 08, 2012 at 06:59:21PM +0400, Sergey V Turchin wrote:
> > > т.к. их вид более универсален.
> > Ещё раз: он малополезен, кроме как для архива.
> Для чего конкретно он малополезен? У меня для всего полезен.

Рад за тебя, а сам при малейшей возможности стараюсь
патчи отдать в апстрим и локальные держать всё-таки
ветками, чтоб работали merge/rebase/diff ;-)

> > По крайней мере мне.  С патчами мороки прибавляется,
> Никакой не прибавляется.

Как минимум add/commit прибавляется, это если .gear/rules
уже делают copy: *.patch

> > помощи при этом с ними -- никакой. 
> Помощь в том, что вреда гораздо меньше.

Ой не скажи, у меня packages/ всякими NMU захламлены изрядно
и это при том, что их делаю довольно мало.  Правда, этому может
помочь создание рядом nmu/ -- давно хотел попросить ldv@ сделать,
спасибо тебе за пинок :-)

> > И для переезда на апстримный гит ничем не помогает --
> > всё равно выбрасывать историю и делать заново.
> А кто сказал, что должно помочь?

Помнится, как светлое будущее (tm) упоминалось как раз облегчение
перетекания кода из разработки в дистрибутив, но именно насчёт
gear-srpmimport и впрямь никто не обещал.

> > Это не смертельно, просто и так уже из-за слишком жёсткого
> > подхода получилось много плохого вследствие использования
> > неоправданно сложного инструментария людьми, которые его
> > не освоили как следует.
> Уже не один год успешно используют возможность "не осваивать" ;-)

Собсно чего далеко ходить -- смотрим #27775 и понимаем,
что даже на одну из наиболее матёрых старух в околотке
тоже бывает проруха.

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

Посмотри внимательней (хотя бы по документации) на инструментарий
для работы с пакетами и патчами в тех же федоре и дебиане.

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

Например, "забрать пакет" -- мне пришлось накостылить
http://git.altlinux.org/people/mike/packages/?p=girar-utils.git;a=blob;f=girar-download;hb=HEAD

"Отправить" -- делаю Ctrl-R и по месту поправляю:
ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run

"Скопировать" -- опять же хистори:

ssh git.alt task new 5.1; for i in firefox-fireftp firefox-fireget firefox-settings-kdesktop thunderbird-contactssidebar thunderbird-quotecolors; do ssh git.alt task add del $i; done; for i in firefox firefox-be firefox-ru firefox-uk libcairo1 libcairomm1 libpixman0 thunderbird thunderbird-lightning-ru thunderbird-ru xulrunner; do ssh git.alt task add copy $i p5; done

(при этом знаю, что у lav@ и viy@ есть скрипты, но они
предполагают некоторую дополнительную прослойку настроек
-- тех же apt.conf -- которая ни разу не стандартизирована
и у каждого сложилась скорее своя исторически)

> Либо мне они не нужны вообще, либо я ими всегда пользуюсь и не замечаю.

Так когда привык, обтесался и накопил нужное в ~/.*sh_history --
именно что не замечаешь...

Попробуй взять новую виртуалку/контейнер, _не_ брать никаких
своих хистори и скриптиков, "забыть" всё, что знаешь про gear,
и по документации собрать два-три пакета разного плана по патчам.

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

-- 
 ---- 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)

[Mikhail Efremov]

On Mon, 8 Oct 2012 18:29:48 +0300 Michael Shigorin wrote:
> "Отправить" -- делаю Ctrl-R и по месту поправляю:
> ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run

ssh git.alt build -b t6 alsa-lib 1.0.24.1-alt4.M60T.1

-- 
WBR, Mikhail Efremov

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

[Michael Shigorin]

On Mon, Oct 08, 2012 at 07:38:38PM +0400, Mikhail Efremov wrote:
> > "Отправить" -- делаю Ctrl-R и по месту поправляю:
> > ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run
> ssh git.alt build -b t6 alsa-lib 1.0.24.1-alt4.M60T.1

Знаю, просто нередко нужно несколько пакетов в task и вариант
с new/add/run в ~/.zsh_history чаще попадается под руку ;-)

-- 
 ---- 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)

[Mikhail Efremov]

On Mon, 8 Oct 2012 18:42:08 +0300 Michael Shigorin wrote:
> On Mon, Oct 08, 2012 at 07:38:38PM +0400, Mikhail Efremov wrote:
> > > "Отправить" -- делаю Ctrl-R и по месту поправляю:
> > > ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run
> > ssh git.alt build -b t6 alsa-lib 1.0.24.1-alt4.M60T.1
> 
> Знаю, просто нередко нужно несколько пакетов в task и вариант
> с new/add/run в ~/.zsh_history чаще попадается под руку ;-)
> 

ssh git.alt build -b t6 [ несколько пакетов ]

-- 
WBR, Mikhail Efremov

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

[Michael Shigorin]

On Mon, Oct 08, 2012 at 07:52:09PM +0400, Mikhail Efremov wrote:
> ssh git.alt build -b t6 [ несколько пакетов ]
                            ^^^^^^^^^
Спасибо, проморгал.

-- 
 ---- 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)

[Anton V. Boyarshinov]

On Mon, 8 Oct 2012 19:38:38 +0400 Mikhail Efremov wrote:

> On Mon, 8 Oct 2012 18:29:48 +0300 Michael Shigorin wrote:
> > "Отправить" -- делаю Ctrl-R и по месту поправляю:
> > ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run
> 
> ssh git.alt build -b t6 alsa-lib 1.0.24.1-alt4.M60T.1
Я бы даже сказал:
ssh git.alt build -b t6 $(basename $(pwd)) $(git describe)

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

[Michael Shigorin]

On Tue, Oct 09, 2012 at 02:07:36PM +0400, Anton V. Boyarshinov wrote:
> > ssh git.alt build -b t6 alsa-lib 1.0.24.1-alt4.M60T.1
> Я бы даже сказал:
> ssh git.alt build -b t6 $(basename $(pwd)) $(git describe)

`basename $(pwd)` -- да, а вот тег глазами перепроверяю
и ручками ставлю... порой ещё и перепроверив gitk --all.

-- 
 ---- 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: 3632 bytes --]

On Mon, Oct 08, 2012 at 06:29:48PM +0300, Michael Shigorin wrote:

MS> Рад за тебя, а сам при малейшей возможности стараюсь
MS> патчи отдать в апстрим и локальные держать всё-таки
MS> ветками, чтоб работали merge/rebase/diff ;-)

Ты вот что путаешь -- в gear можно держать патчи в отдельных файлах, в
точности как в srpm. Тогда не будет не плюшек git с rebase/merge, ни
проблем с неюзабельными патчами.

Т.е. будет ровно как в srpm.

Никто не запрещает использовать gear с практически идентичным workflow как
при рабтое с srpm. Просто чуточку удобнее.

Сложности возникают когда хочется использовать возможности git на полную
катушку.

Но я категорически не понимаю, почему ты ставишь вопрос как 'gear VS
srpm', а не как 'одни типы репозитория VS другие'. Потому как простейший
репозиторий, который создает gear-srpmimport при работе удобнее чем
собственно srpm.

MS> Ой не скажи, у меня packages/ всякими NMU захламлены изрядно
MS> и это при том, что их делаю довольно мало.  Правда, этому может
MS> помочь создание рядом nmu/ -- давно хотел попросить ldv@ сделать,
MS> спасибо тебе за пинок :-)

packages/ разумнее воспринимать просто как некий 'кэш'. Я сейчас завел
практику, при которой я беру репозитории прямо из gears. Это еще и
помогает в случае, когда кто-то сделал NMU.

См. gear-clone в mithraen-build-utils.

MS> Помнится, как светлое будущее (tm) упоминалось как раз облегчение
MS> перетекания кода из разработки в дистрибутив, но именно насчёт
MS> gear-srpmimport и впрямь никто не обещал.

Тут все сложно из-за отсутствия в .gear метаинформации о внешних
репозиториях. До тех пор, пока нет штатного метода сохранять эту
метаинформацию я предпочитаю работать с tarboll'ами.

MS> Например, "забрать пакет" -- мне пришлось накостылить
MS> http://git.altlinux.org/people/mike/packages/?p=girar-utils.git;a=blob;f=girar-download;hb=HEAD
MS> "Отправить" -- делаю Ctrl-R и по месту поправляю:
MS> ssh git.alt task new t6; ssh git.alt task add repo alsa-lib 1.0.24.1-alt4.M60T.1; ssh git.alt task run

У меня отправка -- один простой скрипт 'build-sisyphus'.
Если нужно отправлять несколько пакетов в одной транзакции, то есть также
очень удобный скрипт task-add (отправляет последний tag текущего
репозтория).

MS> (при этом знаю, что у lav@ и viy@ есть скрипты, но они
MS> предполагают некоторую дополнительную прослойку настроек
MS> -- тех же apt.conf -- которая ни разу не стандартизирована
MS> и у каждого сложилась скорее своя исторически)

Для столь простых задач можно обойтись простыми скриптами без этой
настройки.

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

Как можно работать без etersoft-build-utils я вообще не понимаю :)

MS> Попробуй взять новую виртуалку/контейнер, _не_ брать никаких
MS> своих хистори и скриптиков, "забыть" всё, что знаешь про gear,
MS> и по документации собрать два-три пакета разного плана по патчам.
MS> Не подумай, что издеваюсь или подковыриваю -- просто такой
MS> "сброс кэша" бывает довольно полезным упражнением для понимания
MS> того, как привычное выглядит со стороны.

У меня в новый контейнер mithraen-build-utils (который тянет за собой еще
и etersoft-build-utils) будет поставлен в первую же секунду, как мне
понадоблится что-то собрать.

А history я как раз для поиска не использую -- ибо я тупой ламер, который
не выработал себе навыки эффективного использования history. Поэтому
только скриптики да alias'ы.

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

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)

[Michael Shigorin]

On Tue, Oct 09, 2012 at 01:22:11AM +0400, Денис Смирнов wrote:
> Но я категорически не понимаю, почему ты ставишь вопрос как
> 'gear VS srpm', а не как 'одни типы репозитория VS другие'.
> Потому как простейший репозиторий, который создает
> gear-srpmimport при работе удобнее чем собственно srpm.

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

> > Правда, этому может помочь создание рядом nmu/ -- давно хотел
> > попросить ldv@ сделать, спасибо тебе за пинок :-)
> packages/ разумнее воспринимать просто как некий 'кэш'. Я
> сейчас завел практику, при которой я беру репозитории прямо из
> gears. Это еще и помогает в случае, когда кто-то сделал NMU.

А так проще упустить то, когда у людей есть наработки, которые
ещё не попали в сизиф, но которые стоит учесть.  Это более редкий
случай (особенно по нынешним временам), но его стоит помнить.

> А вообще надо бы нам всем, кто пишет себя тучу хаков собраться
> -- и стандартизировать свои хаки.

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

-- 
 ---- 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: 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)

[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] [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] [JT] Re: srpm

[REAL]

09.10.2012 04:22, Денис Смирнов пишет:
> packages/ разумнее воспринимать просто как некий 'кэш'. Я сейчас завел
> практику, при которой я беру репозитории прямо из gears. Это еще и
> помогает в случае, когда кто-то сделал NMU.

Аналогично, только вот анноят "левые" тэги типа gb-sisyphus-taskXXXXX

-- 

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

Re: [devel] [JT] Re: srpm

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

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

On Tue, Oct 09, 2012 at 10:26:44AM +0700, REAL wrote:

>> packages/ разумнее воспринимать просто как некий 'кэш'. Я сейчас завел
>> практику, при которой я беру репозитории прямо из gears. Это еще и
>> помогает в случае, когда кто-то сделал NMU.
> Аналогично, только вот анноят "левые" тэги типа gb-sisyphus-taskXXXXX

Тем же скриптом, который импортирует с gears можно эти тэги и убивать,
если так уж мешают.

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

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: 4263 bytes --]

On 8 октября 2012 18:29:48 Michael Shigorin wrote:

[...]
> Рад за тебя, а сам при малейшей возможности стараюсь
> патчи отдать в апстрим и локальные держать всё-таки
> ветками, чтоб работали merge/rebase/diff ;-)
Да, это наилучший вариант.

> > > По крайней мере мне.  С патчами мороки прибавляется,
> > 
> > Никакой не прибавляется.
> 
> Как минимум add/commit прибавляется
А откуда еще возмется история, где будет четко указано "ФИО здесь накосячил"?

> , это если .gear/rules
> уже делают copy: *.patch
Можно сразу
copy?: *.patch
или
copy: altlinux/*

> > > помощи при этом с ними -- никакой.
> > 
> > Помощь в том, что вреда гораздо меньше.
> 
> Ой не скажи, у меня packages/ всякими NMU захламлены изрядно
> и это при том, что их делаю довольно мало.  Правда, этому может
> помочь создание рядом nmu/ -- давно хотел попросить ldv@ сделать,
> спасибо тебе за пинок :-)
mkdir NMU
mv nmu* NMU/
srpm курит в сторонке ;-)

[...]
> Собсно чего далеко ходить -- смотрим #27775
Я обычно прикладываю .spec.patch , который и читается так как надо в любой 
момент времени.

> и понимаем,
> что даже на одну из наиболее матёрых старух в околотке
> тоже бывает проруха.
Это ж не показатель, что он слишком рано перешел на gear ;-)

[...]
> Посмотри внимательней (хотя бы по документации) на инструментарий
> для работы с пакетами и патчами в тех же федоре и дебиане.
Еще можно на документацию взглянуть (это все к 3-му этажу ;-) ).

[...]
> > Я вообще не понямаю, о каких скриптах речь?
> 
> Например, "забрать пакет" -- мне пришлось накостылить
[...]
Значит, не видел и не пульзуюсь, т.к. не нужны.

[...]
> ssh git.alt task new 5.1; for i in firefox-fireftp firefox-fireget
[...]
Сюда-то зачем? ;-)

[...]
> -- тех же apt.conf -- которая ни разу не стандартизирована
> и у каждого сложилась скорее своя исторически)
Не вкурсе. Не нужна мне, значит.
 
> Так когда привык, обтесался и накопил нужное в ~/.*sh_history --
> именно что не замечаешь...
У меня свои есть.
В истории только короткое типа
share_network=1 gear-hsh -v --commit --target=i586 --mountpoints=/proc
или
gear-rpm --commit -bc --target=i586 --short-circuit

> Попробуй взять новую виртуалку/контейнер, _не_ брать никаких
> своих хистори и скриптиков, "забыть" всё, что знаешь про gear,
> и по документации собрать два-три пакета разного плана по патчам.
Зачем? Со верменем у любого нарастет.
Или мы уже готовы принимать в мантейнеры совсем кого попало даже без знания 
любого скриптового языка типа bash?

[...]

Если обращал внимание, в devel@ немного обсуждений пользования gear?
Это потому, что все, кому надо, уже пользуют. Остальные без толчка не 
перейдут.

-- 
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 (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Tue, Oct 09, 2012 at 03:01:34PM +0400, Sergey V Turchin wrote:
> Если обращал внимание, в devel@ немного обсуждений пользования gear?
> Это потому, что все, кому надо, уже пользуют. Остальные без толчка не 
> перейдут.

Это ещё и потому, что srpm решили не отменять, IMHO,
и по причине затянувшегося было отсутствия пополнения
команды.  Серж, ещё раз: не надо никаких толчков, и так
хватило уже выше крыши.  Хочешь сделать лучше -- помоги,
а не пинай.

-- 
 ---- 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)

[Sergey V Turchin]

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

On 9 октября 2012 14:28:16 Michael Shigorin wrote:
> On Tue, Oct 09, 2012 at 03:01:34PM +0400, Sergey V Turchin wrote:
> > Если обращал внимание, в devel@ немного обсуждений пользования gear?
> > Это потому, что все, кому надо, уже пользуют. Остальные без толчка не
> > перейдут.
> 
> Это ещё и потому, что srpm решили не отменять,
Естественно. А зря, кстати. Хочешь оставаться в прошлом -- пили пакеты 
вовремя. Неплохой стимул.

> IMHO, и по причине затянувшегося было отсутствия пополнения
> команды.
Уверен, что просто по причине большой лени кого-то со звучным <подставить 
нужное>.

> Серж, ещё раз: не надо никаких толчков, и так хватило уже выше крыши.
Вот и останется все плавать в текущем состоянии по причине "а осадок остался".

> Хочешь сделать лучше -- помоги, а не пинай.
Скрипты на баше не буду помогать писать. Остальное можно узнать в этом списке 
и на wiki(за что отдельное спасибо тем, кто туда вытаскивает инфу отсюда).

-- 
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 (was: git.alt task check-git-inheritance)

[Michael Shigorin]

On Tue, Oct 09, 2012 at 04:02:38PM +0400, Sergey V Turchin wrote:
> > Это ещё и потому, что srpm решили не отменять,
> Естественно. А зря, кстати.
> Хочешь оставаться в прошлом -- пили пакеты вовремя.

Интересный тезис...

> Неплохой стимул.

Если не заметил, с ~2006--2007 был резкий спад в активности
по пакетам и ухудшение баланса по команде (это было видно
и по cybertalk@, и по различным *-owner@lists.altlinux.org).

> > IMHO, и по причине затянувшегося было отсутствия пополнения
> > команды.
> Уверен, что просто по причине большой лени кого-то со звучным
> <подставить нужное>.

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

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

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

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

Re: [devel] [JT] Re: srpm

[Andrew Clark]

On 09.10.2012 21:04, Michael Shigorin wrote:
> Эти хорошо изученные грабли уже проходили бздюки, не стоит брать с них 
> пример. 
С этим лучше на opennet.ru

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

[Sergey V Turchin]

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

On 9 октября 2012 20:04:16 Michael Shigorin wrote:

[...]
> с ~2006--2007 был резкий спад в активности

[...]

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

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

[...]

-- 
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 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] [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

[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] 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

[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

[REAL]

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

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

-- 

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

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] 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] 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] 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] 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] 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] 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/

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] 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] 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] 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

[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

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

[-- 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] 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

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

[-- 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] 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

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

[-- 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

[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] gear->srpm

[Anton Farygin]

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

+1

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 --]

[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] [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] srpm (was: git.alt task check-git-inheritance)

[Sergey Y. Afonin]

On Monday 08 October 2012, Sergey V Turchin wrote:

> > Сборка из srpm?  Если есть уверенность, что никакие изменения из
> > 0.97.3-alt0.M41.1 не потерялись случайно

> Не конкретно к этому случаю, но у меня есть пример(не скажу), когда
> мантернер намеренно плевал на потерю изменений,

Ну я с git на srpm нигде не переходил. Просто с srpm на git менять
тоже не стремлюсь всё подряд.

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

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

[Sergey V Turchin]

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

On 8 октября 2012 17:15:54 Sergey Y. Afonin wrote:
> On Monday 08 October 2012, Sergey V Turchin wrote:
> > > Сборка из srpm?  Если есть уверенность, что никакие изменения из
> > > 0.97.3-alt0.M41.1 не потерялись случайно
> > 
> > Не конкретно к этому случаю, но у меня есть пример(не скажу), когда
> > мантернер намеренно плевал на потерю изменений,
> 
> Ну я с git на srpm нигде не переходил. Просто с srpm на git менять
> тоже не стремлюсь всё подряд.
gear-srpmimport сам всё делает.
Я ж говорю, многих просто подтолкнуть достаточно.

-- 
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)

[Michael Shigorin]

On Mon, Oct 08, 2012 at 05:16:26PM +0400, Sergey V Turchin wrote:
> gear-srpmimport сам всё делает.

В итоге больше мороки с добавлением патчей и ~ноль
толку от собственно гита, разве что изменения спека
отсматривать становится быстрей.  А после не слишком
обдуманного перехода на gear привлекательность альта
как источника патчей за три-четыре года резко упала.

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

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

[Sergey V Turchin]

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

On 8 октября 2012 17:10:09 Michael Shigorin wrote:
> On Mon, Oct 08, 2012 at 05:16:26PM +0400, Sergey V Turchin wrote:
> > gear-srpmimport сам всё делает.
> 
> В итоге больше мороки с добавлением патчей и ~ноль
> толку от собственно гита, разве что изменения спека
> отсматривать становится быстрей.
_Все_ изменения становится осматривать быстрей. Особенно, если их в кучу не 
валить, делая более конкретные коммиты.

> А после не слишком
> обдуманного перехода на gear привлекательность альта
> как источника патчей за три-четыре года резко упала.
Это необдуманные действия таких мантейнеров и отсутствие policy, запрещающего 
такое. Я все патчи держу отдельно, как в Fedora, например, независимо от вида 
репозитория.

-- 
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)

[Igor Vlasenko]

On Mon, Oct 08, 2012 at 03:12:40PM +0400, Sergey V Turchin wrote:
> Я бы уже начал закручивать гайки для srpm. По крайней мере для сизифа.
> По себе знаю: пока не пнут, от srpm не откажешься, но у меня это уже давно 
> произошло и ни разу не жалею.

Не надо портить жизнь ближнему своему ;) Миша правильно сказал,
что у каждого свои удобные ему workflow, которые опираются
на локальные костыли. А со стороны человеку этот workflow
загадочен, костылей у него под рукой нет, а без тайного знания
и инструментов работы с ним все удобства 
превращаются в свою противоположность.

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

Gear репозитории менее сложные, но и они в состоянии
перегрузить стороннего майнтайнера дурной работой -
из-за потерь информации при публикации. 
Напомню, если обновление из svn, то настройки git-svn теряются,
remote branches теряются тоже, поэтому непонятно, из какого
стороннего git брались обновления.

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

И это при том, что srpm хоть какой, но один, а
gear репозиториев и workflow работы с ними сколько, 
столько и майнтайнеров.

Далеко за примерами ходить не надо. 
Например, Сергей, у вас самого достаточно
экстремальный repository layout.
Выделенной апстримной ветви нет,
апстримные и наши коммиты вперемешку,
с соглашением, что наш контент должен быть ограничен
./altlinux/ и .gear/, но без гарантий.

Такой репозиторий легко случайно засорить своим коммитом
вне ./altlinux, который затем будет скрыт от глаз
и погребен в ворохе апстримных коммитов.

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

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

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

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

-- 

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] 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 --]