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

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

[Dmitry V. Levin]

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

Hi,

Недавно в интерфейс git.alt task была добавлена команда
check-git-inheritance:

$ ssh git.alt task check-git-inheritance --help
usage: girar-task check-git-inheritance <task_id> <subtask_number> disable <commit_sha_id>

Эта команда для подзадания <subtask_number>, входящего в состав задания
<task_id>, и не прошедшего проверку наследования сборки, выключает
обязательность проверки наследования от git-коммита <commit_sha_id>.

Команда предназначена для осознанного обхода проверки наследования в
случаях, когда такой обход необходим, например:
- при переходе на апстримный git-репозиторий без общих коммитов;
- при очистке git-истории от нежелательных git-коммитов;
- при смене формата исходного кода с gear на srpm.


-- 
ldv

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

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
devel-announce mailing list
devel-announce@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-announce

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

[Sergey V Turchin]

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

On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
> Hi,
> 
> Недавно в интерфейс git.alt task была добавлена команда
> check-git-inheritance:
> 
> $ ssh git.alt task check-git-inheritance --help
> usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> <commit_sha_id>
Можно будет посмотреть commit_sha_id чем-нибудь типа
girar-task check-git-inheritance <task_id> <subtask_number> show
?

[...]

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

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

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

[Dmitry V. Levin]

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

On Wed, Oct 19, 2011 at 12:49:16PM +0400, Sergey V Turchin wrote:
> On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
> > 
> > Недавно в интерфейс git.alt task была добавлена команда
> > check-git-inheritance:
> > 
> > $ ssh git.alt task check-git-inheritance --help
> > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > <commit_sha_id>
> Можно будет посмотреть commit_sha_id чем-нибудь типа
> girar-task check-git-inheritance <task_id> <subtask_number> show
> ?

Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
наследования, в состоянии вычислить искомый <commit_sha_id>
самостоятельно.


-- 
ldv

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

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

[Sergey V Turchin]

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

On 19 октября 2011 14:34:54 Dmitry V. Levin wrote:

[...]
> Предполагается, что мейнтейнер, которому нужно обойти проверку
> наследования, в состоянии вычислить искомый <commit_sha_id>
> самостоятельно.
Я так и думал ;-)

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

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

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

[Yuri N. Sedunov]

В Срд, 19/10/2011 в 14:34 +0400, Dmitry V. Levin пишет:
> On Wed, Oct 19, 2011 at 12:49:16PM +0400, Sergey V Turchin wrote:
> > On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
> > > 
> > > Недавно в интерфейс git.alt task была добавлена команда
> > > check-git-inheritance:
> > > 
> > > $ ssh git.alt task check-git-inheritance --help
> > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > <commit_sha_id>
> > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > girar-task check-git-inheritance <task_id> <subtask_number> show
> > ?
> 
> Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> наследования, в состоянии вычислить искомый <commit_sha_id>
> самостоятельно.

А без мартышкиного труда можно обойтись и сделать просто? 
girar-task check-git-inheritance <task_id> disable

В процессе переноса gnome-3.2 в сизиф придется попрощаться с частью
гитов -- вычислять какие-то нумера не продуктивно, а что от чего
наследуется я и так знаю без нумеров.

-- 
Yuri N. Sedunov

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

[Dmitry V. Levin]

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

On Wed, Oct 19, 2011 at 02:46:34PM +0400, Yuri N. Sedunov wrote:
> В Срд, 19/10/2011 в 14:34 +0400, Dmitry V. Levin пишет:
> > On Wed, Oct 19, 2011 at 12:49:16PM +0400, Sergey V Turchin wrote:
> > > On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
> > > > 
> > > > Недавно в интерфейс git.alt task была добавлена команда
> > > > check-git-inheritance:
> > > > 
> > > > $ ssh git.alt task check-git-inheritance --help
> > > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > > <commit_sha_id>
> > > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > > girar-task check-git-inheritance <task_id> <subtask_number> show
> > > ?
> > 
> > Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> > наследования, в состоянии вычислить искомый <commit_sha_id>
> > самостоятельно.
> 
> А без мартышкиного труда можно обойтись и сделать просто? 
> girar-task check-git-inheritance <task_id> disable

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

> В процессе переноса gnome-3.2 в сизиф придется попрощаться с частью
> гитов -- вычислять какие-то нумера не продуктивно, а что от чего
> наследуется я и так знаю без нумеров.

Каждый номер вычисляется одной командой.  Суть не в том, чтобы его
вычислить, а в том, чтобы его зафиксировать.


-- 
ldv

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

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

[Yuri N. Sedunov]

В Срд, 19/10/2011 в 18:44 +0400, Dmitry V. Levin пишет:
> On Wed, Oct 19, 2011 at 02:46:34PM +0400, Yuri N. Sedunov wrote:
> > В Срд, 19/10/2011 в 14:34 +0400, Dmitry V. Levin пишет:
> > > On Wed, Oct 19, 2011 at 12:49:16PM +0400, Sergey V Turchin wrote:
> > > > On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
> > > > > 
> > > > > Недавно в интерфейс git.alt task была добавлена команда
> > > > > check-git-inheritance:
> > > > > 
> > > > > $ ssh git.alt task check-git-inheritance --help
> > > > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
> > > > > <commit_sha_id>
> > > > Можно будет посмотреть commit_sha_id чем-нибудь типа
> > > > girar-task check-git-inheritance <task_id> <subtask_number> show
> > > > ?
> > > 
> > > Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
> > > наследования, в состоянии вычислить искомый <commit_sha_id>
> > > самостоятельно.
> > 
> > А без мартышкиного труда можно обойтись и сделать просто? 
> > girar-task check-git-inheritance <task_id> disable
> 
> Идея в том, чтобы не потерять изменений случайно.  Если, пока вы собирали
> задание <task_id>, кто-то вас обогнал и собрал тот же самый пакет, то
> <commit_sha_id> изменится.

Последняя запись в changelog пакета изменится, которую и надо проверить,
т.е "srpm inheritance check" вполне достаточно для <taskid>, в которых
"gears inheritance check" отменен.

> > В процессе переноса gnome-3.2 в сизиф придется попрощаться с частью
> > гитов -- вычислять какие-то нумера не продуктивно, а что от чего
> > наследуется я и так знаю без нумеров.
> 
> Каждый номер вычисляется одной командой.  Суть не в том, чтобы его
> вычислить, а в том, чтобы его зафиксировать.

Почему бы сборочнице самостоятельно не зафиксировать этот
<commit_sha_id>, если уж она его вычисляет?

-- 
Yuri N. Sedunov

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

[Michael Shigorin]

On Wed, Oct 19, 2011 at 08:36:15PM +0400, Yuri N. Sedunov wrote:
> Почему бы сборочнице самостоятельно не зафиксировать этот
> <commit_sha_id>, если уж она его вычисляет?

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

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

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

[Yuri N. Sedunov]

В Срд, 19/10/2011 в 19:45 +0300, Michael Shigorin пишет:
> On Wed, Oct 19, 2011 at 08:36:15PM +0400, Yuri N. Sedunov wrote:
> > Почему бы сборочнице самостоятельно не зафиксировать этот
> > <commit_sha_id>, если уж она его вычисляет?
> 
> Насколько понимаю, ключевое слово -- "осознанного".
> Попробуй предложить альтернативный вариант проверки?

Проверки чего, "осознанности" принятия решения? 


-- 
Yuri N. Sedunov

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

[Alexey Shabalin]

19 октября 2011 г. 14:46 пользователь Yuri N. Sedunov написал:
> В Срд, 19/10/2011 в 14:34 +0400, Dmitry V. Levin пишет:
>> On Wed, Oct 19, 2011 at 12:49:16PM +0400, Sergey V Turchin wrote:
>> > On 19 октября 2011 03:01:55 Dmitry V. Levin wrote:
>> > >
>> > > Недавно в интерфейс git.alt task была добавлена команда
>> > > check-git-inheritance:
>> > >
>> > > $ ssh git.alt task check-git-inheritance --help
>> > > usage: girar-task check-git-inheritance <task_id> <subtask_number> disable
>> > > <commit_sha_id>
>> > Можно будет посмотреть commit_sha_id чем-нибудь типа
>> > girar-task check-git-inheritance <task_id> <subtask_number> show
>> > ?
>>
>> Нет.  Предполагается, что мейнтейнер, которому нужно обойти проверку
>> наследования, в состоянии вычислить искомый <commit_sha_id>
>> самостоятельно.
>
> А без мартышкиного труда можно обойтись и сделать просто?
> girar-task check-git-inheritance <task_id> disable
>
> В процессе переноса gnome-3.2 в сизиф придется попрощаться с частью
> гитов -- вычислять какие-то нумера не продуктивно, а что от чего
> наследуется я и так знаю без нумеров.

Заранее предупрежу, что я против "попрощатся" с гитами для пакетов gnome.
Как минимум в тех пакетах, в которых я присутствую в changelog.
Самоуправство лидера @gnome еще не повод отказываться от проделанной работы.

-- 
Alexey Shabalin

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

[Michael Shigorin]

On Thu, Oct 20, 2011 at 03:21:46PM +0400, Alexey Shabalin wrote:
> > В процессе переноса gnome-3.2 в сизиф придется попрощаться с частью
> > гитов -- вычислять какие-то нумера не продуктивно, а что от чего
> > наследуется я и так знаю без нумеров.
> Заранее предупрежу, что я против "попрощатся" с гитами для пакетов gnome.
> Как минимум в тех пакетах, в которых я присутствую в changelog.
> Самоуправство лидера @gnome еще не повод отказываться от проделанной работы.

А что там творится-то?

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

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

[Yuri N. Sedunov]

В Чтв, 20/10/2011 в 15:21 +0400, Alexey Shabalin пишет:
> 19 октября 2011 г. 14:46 пользователь Yuri N. Sedunov написал:

> Заранее предупрежу, что я против "попрощатся" с гитами для пакетов gnome.
> Как минимум в тех пакетах, в которых я присутствую в changelog.
> Самоуправство лидера @gnome еще не повод отказываться от проделанной работы.
> 

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

-- 
Yuri N. Sedunov

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

[Sergey V Turchin]

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

On 20 октября 2011 16:52:11 Yuri N. Sedunov wrote:

[...]
> перенести в твои гиты то, что сделано мной, но
> не желаю повторения того печального опыта.
По закону все равно получается виноватее тот, кто не пользуется git.

P.S.
Меня тоже насильно загоняли пользоваться git-ом, о чем я совсем не жалею, 
выработав несколько мелких принципов и приемов, которые мне кардинально 
упрощают жизнь (например, gear-update-tag я не использую вообще).

P.P.S.
Я даже из src.rpm по сейчасному не умею собирать.

-- 
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] @gnome и shaba@ (was: Re: [devel-announce] I: git.alt task check-git-inheritance)

[Yuri N. Sedunov]

В Чтв, 20/10/2011 в 17:03 +0400, Sergey V Turchin пишет:
> On 20 октября 2011 16:52:11 Yuri N. Sedunov wrote:
> 
> [...]
> > перенести в твои гиты то, что сделано мной, но
> > не желаю повторения того печального опыта.
> По закону все равно получается виноватее тот, кто не пользуется git.

Нет такого закона, но это не важно.

> P.S.
> Меня тоже насильно загоняли пользоваться git-ом, о чем я совсем не жалею, 
> выработав несколько мелких принципов и приемов, которые мне кардинально 
> упрощают жизнь (например, gear-update-tag я не использую вообще).
> 

Опубликуй приемы, может пригодятся.

> P.P.S.
> Я даже из src.rpm по сейчасному не умею собирать.

А я и так и сяк умею, когда действительно надо.


-- 
Yuri N. Sedunov

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

[Sergey V Turchin]

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

On 20 октября 2011 17:14:54 Yuri N. Sedunov wrote:

[...]
> Опубликуй приемы, может пригодятся.
Что с ходу вспомнилось:
- чтоб не пользоваться gear-update-tag нужно держать все свое в одной ветке с 
исходниками. При этом .gear/rules будет выглядеть на манер:
copy: altlinux/*
tar: . name=pkgname-@version@
spec: altlinux/pkgname.spec
- смержить в текущее дерево все, что угодно поверх с сохранением истории можно 
прикрепленным волшебным скриптом от sbolshakov@alt. Мне такое пригождается при 
обновлении qt и kde, когда с тэга одной версии не мержиться до другого, т.к. у 
них это разные ветки.

> > P.P.S.
> > Я даже из src.rpm по сейчасному не умею собирать.
> А я и так и сяк умею, когда действительно надо.
Дык, переходи уже совсем, чтоб не мучиться.

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

[-- Attachment #1.2: git-merge-theirs --]
[-- Type: application/x-shellscript, Size: 367 bytes --]

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

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

[Alexey Shabalin]

20 октября 2011 г. 16:52 пользователь Yuri N. Sedunov написал:
> В Чтв, 20/10/2011 в 15:21 +0400, Alexey Shabalin пишет:
>> 19 октября 2011 г. 14:46 пользователь Yuri N. Sedunov написал:
>
>> Заранее предупрежу, что я против "попрощатся" с гитами для пакетов gnome.
>> Как минимум в тех пакетах, в которых я присутствую в changelog.
>> Самоуправство лидера @gnome еще не повод отказываться от проделанной работы.
>>
>
> Ни разу не изъявив желания поучаствовать в подготовке gnome-3.2, ты уже
> попрощался со "своими пакетами" окончательно. Мог бы как и в прошлый раз
> предложить тебе аккуратно перенести в твои гиты то, что сделано мной, но
> не желаю повторения того печального опыта.

Это с каких пор нужно кому-то изъявлять желание сопровождать пакеты,
которые до этого сопровождал?
Я никогда не "переносил" в git пакеты, я сразу готовлю пакеты в git.

Вот такие высказывания я и называю самоуправством.
Группа @gnome создавалась по моей инициативе, во времена когда aris@
временно не участвовал в работе, а ktirf@ был перегружен другими
задачами.
Я по доброте душевно, не представляя чем это может закончится, перевёл
все пакеты, которые поддерживал, на группу gnome@.
После возвращения в команду aris@ и ухода ktirf@, aris@ стал лидером
группы gnome@.
В дальнейшем aris@ исключил меня из группы gnome@, соответственно я
потерял доступ к поддерживаемым пакетам.

Зная о не любви aris@ к git, а тем более зная о фактах удаления им
чужих пакетов (если они доступны для @everybody),
нисколько не сомневаюсь, что он всеми силами будет уничтожать
существующие "git-пакеты".
Пока вижу единственный компромисс, если aris@ отпишет на меня пакеты,
которые я сопровождал раньше.

-- 
Alexey Shabalin

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

[Igor Vlasenko]

On Fri, Oct 21, 2011 at 03:28:11PM +0400, Alexey Shabalin wrote:
> Я никогда не "переносил" в git пакеты, я сразу готовлю пакеты в git.

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

Т.е. то, что лежит на people/shaba/packages, неудобно для
работы -- gear теряет локальные remotes.
В результате бранч upstream есть, а откуда там берутся commits -
непонятно. Это текущий дефект gear, но в результате страдают
люди.

Т.е. было бы правильнее не заставлять Юрия разбираться 
с вашими репозитариями, а либо выслать ему ваши локальные 
настройки, либо импортировать в ваш git его srpm'ы.

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

> Я хотел бы напомнить, что у нас при работе
> с пакетом c помощью git+gear репозиториев
> вылезает грабля в gear, мешающая совместной работе.

> Именно, при клонировании git+gear репозитария,
> который не обновляется из тарболов, а берет коммиты напрямую
> из апстримного SCM, теряется информация, откуда предыдущий
> майнтайнер брал коммиты.

> В результате, чтобы работать с таким репозитарием,
> нужно потратить время, догадаться, откуда с какого сайта
> взялись коммиты и выставить этот сайт локально в remotes,
> в случае git-svn надо еще догадаться, какая там корректная
> конфигурация для git-svn.


-- 

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

[Dmitry V. Levin]

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

On Fri, Oct 21, 2011 at 04:24:57PM +0300, Igor Vlasenko wrote:
> On Fri, Oct 21, 2011 at 03:28:11PM +0400, Alexey Shabalin wrote:
> > Я никогда не "переносил" в git пакеты, я сразу готовлю пакеты в git.
> 
> Извиняюсь, что вклиниваюсь, Всех призываю к миру и дружбе,
> не надо ссориться, надо мириться, 

+1

> и, Алексей, жотел бы сказать, что и вы правы, и Юрий по своему прав,
> а виноват gear.

:)

> Т.е. то, что лежит на people/shaba/packages, неудобно для
> работы -- gear теряет локальные remotes.
> В результате бранч upstream есть, а откуда там берутся commits -
> непонятно. Это текущий дефект gear, но в результате страдают
> люди.

gear - это инструмент для сборки, а не для совместной разработки.
Он предоставляет вам много степеней свободы, в том числе свободу
не публиковать персональный .git/config
Мощный инструмент подразумевает высокую культуру обращения с ним.

> IMHO, никто не виноват, ситуация стала заложником 
> не доделанного технического решения для совместной разработки.

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

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

> > Я хотел бы напомнить, что у нас при работе
> > с пакетом c помощью git+gear репозиториев
> > вылезает грабля в gear, мешающая совместной работе.
> 
> > Именно, при клонировании git+gear репозитария,
> > который не обновляется из тарболов, а берет коммиты напрямую
> > из апстримного SCM, теряется информация, откуда предыдущий
> > майнтайнер брал коммиты.

git это DVCS, коммиты можно взять где угодно.  Иногда апстримный
репозиторий надолго исчезает со своего традиционного места
(вспомним, например, kernel.org).  Человеку обычно не сложно найти
апстрим(ы).  Сложности возникают у полностью автоматических скриптов
(роботов), которых надо специально на эту тему инструктировать.

Напишите $prefix-store-config. :)

> > В результате, чтобы работать с таким репозитарием,
> > нужно потратить время, догадаться, откуда с какого сайта
> > взялись коммиты и выставить этот сайт локально в remotes,
> > в случае git-svn надо еще догадаться, какая там корректная
> > конфигурация для git-svn.

Напишите $prefix-svn. :)


-- 
ldv

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

Re: [devel] gear

[Igor Vlasenko]

On Fri, Oct 21, 2011 at 05:49:53PM +0400, Dmitry V. Levin wrote:
> Если нужен инструмент для организации процесса совместной разработки,
> то не надо думать что gear это искомый инструмент.

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

> Напишите $prefix-store-config. :)
> Напишите $prefix-svn. :)

Хочу... Но чтобы и красиво, и удобно, и естественно...
Пока не могу представить как.

-- 

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

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

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

On Fri, Oct 21, 2011 at 05:49:53PM +0400, Dmitry V. Levin wrote:

DVL> gear - это инструмент для сборки, а не для совместной разработки.
DVL> Он предоставляет вам много степеней свободы, в том числе свободу
DVL> не публиковать персональный .git/config
DVL> Мощный инструмент подразумевает высокую культуру обращения с ним.

Не надо публиковать персональный .git/config. Однако для полноценной
совместной разработки отдельные его части должны быть опубликованы.

Это неправильно enforce'ить, однако предоставить такую возможность
необходимо.

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

Да, я согласен что это не нужно прямо в самом gear -- точно также как не
стоит встраивать внутрь gear куски git'а. Но некий стандартизованный
внутри team способ хранения информации о remotes, и инструментарий его
использующий -- необходимы.

Причем этот инструментарий хоть и не имеет никакого отношения к утилите
gear, но имеет ровно такое же отношение к пакету gear, как gear-update.

Чем инструмент обновления пакета из tar.gz хуже, чем инструмент обновления
из svn/git?

DVL> git это DVCS, коммиты можно взять где угодно.  Иногда апстримный
DVL> репозиторий надолго исчезает со своего традиционного места
DVL> (вспомним, например, kernel.org).  Человеку обычно не сложно найти
DVL> апстрим(ы).  Сложности возникают у полностью автоматических скриптов
DVL> (роботов), которых надо специально на эту тему инструктировать.

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

Кроме того, в случае с конкретно git svn -- знания где лежат commit'ы
мало.

DVL> Напишите $prefix-store-config. :)
DVL> Напишите $prefix-svn. :)

2viy@: а в от с этим я согласен, прежде чем патчить gear, все-таки стоит
сначала сделать это просто рядом с ним :)

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

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

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

Re: [devel] gear

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

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

On Fri, Oct 21, 2011 at 05:44:37PM +0300, Igor Vlasenko wrote:

IV> Хочу... Но чтобы и красиво, и удобно, и естественно...
IV> Пока не могу представить как.

У тебя есть пакеты, в которых апстрим использует git? Надо взять парочку
таких пакетов, и сделать чтобы тривиально было удобно для себя.

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

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

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

Re: [devel] gear

[Igor Vlasenko]

On Sat, Oct 22, 2011 at 04:38:52AM +0400, Денис Смирнов wrote:
> On Fri, Oct 21, 2011 at 05:44:37PM +0300, Igor Vlasenko wrote:
> 
> IV> Хочу... Но чтобы и красиво, и удобно, и естественно...
> IV> Пока не могу представить как.
> 
> У тебя есть пакеты, в которых апстрим использует git? Надо взять парочку
> таких пакетов, и сделать чтобы тривиально было удобно для себя.

Я в таком направлении и думаю.

Хочу сначала закрыть другие направления
(autoports, fedora import, watch.altlinux.org, java, ...)
у меня сейчас слишком много незакрытых задач, чтобы не вышел перегруз.


-- 

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

[Michael Shigorin]

On Fri, Oct 21, 2011 at 05:49:53PM +0400, Dmitry V. Levin wrote:
> > IMHO, никто не виноват, ситуация стала заложником 
> > не доделанного технического решения для совместной разработки.
> Посмотрите архив списка рассылки начиная с апреля 2006 года.
> Там вы увидите, как и зачем был создан gear.
> gear - это специализированный инструмент, в первую очередь
> предназначенный для извлечения, согласно простым правилам, исходного
> кода из git-репозитория в форме, пригодной для сборки.
> 
> Если нужен инструмент для организации процесса совместной разработки,
> то не надо думать что gear это искомый инструмент.

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

О чём с 2006 года и говорил -- видимо, слишком невнятно.

> git это DVCS, коммиты можно взять где угодно.  Иногда апстримный
> репозиторий надолго исчезает со своего традиционного места
> (вспомним, например, kernel.org).  Человеку обычно не сложно найти
> апстрим(ы).

Досадно, когда понятно, что эта информация в машиночитаемом
виде _уже_ зафиксирована, просто недоступна.

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

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

[Sergey Y. Afonin]

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-репозитарий ветвить не хочется что-то...

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

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

[REAL]

05.10.2012 22:27, Sergey Y. Afonin пишет:
> clamav-0.97.6-alt0.M41.1.src.rpm, действительно, сделан из clamav-0.97.6-alt1,
> а не из 0.97.3-alt0.M41.1. Можно, конечно, недостающее скопировать, но правильно
> ли оно ? git-репозитарий ветвить не хочется что-то...

не флейма ради, а понимания для: зачем возвращаться к сборке из srpm, 
затрудняя тем самым взаимодействие с коллегами?

-- 

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

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

[Michael Shigorin]

On Fri, Oct 05, 2012 at 10:37:13PM +0700, REAL wrote:
> не флейма ради, а понимания для: зачем возвращаться к сборке из
> srpm, затрудняя тем самым взаимодействие с коллегами?

Не всегда поддержка в git удобнее.  Особенно когда апстрим
даёт тарболы и всё, что к ним нужно -- это спек.

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

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

[REAL]

05.10.2012 22:42, Michael Shigorin пишет:
> Не всегда поддержка в git удобнее.  Особенно когда апстрим
> даёт тарболы и всё, что к ним нужно -- это спек.

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

так что не будем снова разжигать религиозные войны :)

-- 

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

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

[Sergey Y. Afonin]

On Friday 05 October 2012, REAL wrote:

> > clamav-0.97.6-alt0.M41.1.src.rpm, действительно, сделан из clamav-0.97.6-alt1,
> > а не из 0.97.3-alt0.M41.1. Можно, конечно, недостающее скопировать, но правильно
> > ли оно ? git-репозитарий ветвить не хочется что-то...
> 
> не флейма ради, а понимания для: зачем возвращаться к сборке из srpm, 

А там и не было git у ClamAV, в 4.0/4.1.

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

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

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

On Fri, Oct 05, 2012 at 06:42:15PM +0300, Michael Shigorin wrote:

MS> Не всегда поддержка в git удобнее.  Особенно когда апстрим
MS> даёт тарболы и всё, что к ним нужно -- это спек.

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

См. например репозитории всех ghc*. Они простые и тупые.

Мало того, теперь у меня очень сильно изменился workflow. Когда мне нужно
что-то собрать, я просто запускаю gear-clone из mithraen-build-utils. Он
забирает пакет из gears, и мне остается внести изменения и отправить
сборку. При этом имея под рукой весь нужный инструментарий для просмотра
изменений, и прочих радостей жизни.

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

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

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

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

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

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

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

[REAL]

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

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

-- 

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

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)

[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

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

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

[Sergey V Turchin]

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

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

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

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

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

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

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

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

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

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

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

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

[Sergey V Turchin]

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

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

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

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

[...]

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

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

Re: [devel] [JT] Re: srpm

[REAL]

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

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

-- 

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

Re: [devel] [JT] Re: srpm

[Igor Vlasenko]

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

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

-- 

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


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

Re: [devel] [JT] Re: srpm

[REAL]

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

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

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

-- 

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

Re: [devel] [JT] Re: srpm

[Igor Zubkov]

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

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

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

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

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

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

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

Re: [devel] [JT] Re: srpm

[Igor Vlasenko]

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

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

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

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

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


-- 

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


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

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

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

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

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


-- 
ldv

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

Re: [devel] gear->srpm

[Sergey Bolshakov]

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

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

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

-- 

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

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

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

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

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

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

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

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

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

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

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

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

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

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

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


-- 
ldv

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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Dmitry V. Levin]

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

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

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

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

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


-- 
ldv

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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

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


-- 

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


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

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

[Dmitry V. Levin]

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

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

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


-- 
ldv

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

Re: [devel] cronbuild --email

[Dmitry V. Levin]

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

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

Зачем?

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

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

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


-- 
ldv

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

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

[Igor Vlasenko]

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

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


-- 

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


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

Re: [devel] cronbuild --email

[Igor Vlasenko]

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

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

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

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

-- 

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


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

Re: [devel] cronbuild --email

[Dmitry V. Levin]

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

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

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


-- 
ldv

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

Re: [devel] cronbuild --email

[Igor Vlasenko]

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

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

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

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

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

-- 

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


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

Re: [devel] [JT] Re: srpm

[REAL]

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

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

-- 

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

Re: [devel] gear->srpm

[REAL]

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

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

-- 

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

Re: [devel] people->robots delegation

[Dmitry V. Levin]

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

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

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

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

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

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

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

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


-- 
ldv

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

Re: [devel] people->robots delegation

[Igor Vlasenko]

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

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

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

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


-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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

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

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

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

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

-- 

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


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

Re: [devel] gear->srpm

[Igor Vlasenko]

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

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


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

-- 

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


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

Re: [devel] gear->srpm

[Anton Farygin]

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

Re: [devel] gear->srpm

[Michael Shigorin]

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

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

Re: [devel] cronbuild --email

[Michael Shigorin]

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

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

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

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

[devel] [JT] right to compile

[Michael Shigorin]

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

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

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

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

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

Re: [devel] people->robots delegation

[Michael Shigorin]

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

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

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

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

Re: [devel] gear->srpm

[Michael Shigorin]

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

А что за version?

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

Re: [devel] gear->srpm

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

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

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

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

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

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

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

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

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

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

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

Re: [devel] gear->srpm

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

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

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

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

ssh git.alt task add blind-rebuild pkg

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [devel] gear->srpm

[Vladislav Zavjalov]

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

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

Слава

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

[Michael Shigorin]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделаешь? :)

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

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

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

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

[Sergey V Turchin]

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

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

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

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

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

[...]

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

Re: [devel] gear->srpm

[Anton Farygin]

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

+1

Re: [devel] gear->srpm

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

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

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

Вешайте!

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

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

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

Re: [devel] gear->srpm

[Sergey V Turchin]

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

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

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

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

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

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

[Sergey Afonin]

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

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

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

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

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

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

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

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

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

[Vitaly Chikunov]

Sergey,

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

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

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


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

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

[Sergey Afonin]

On Monday 17 July 2023, Vitaly Chikunov wrote:

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

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

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

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

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

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

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

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

[Dmitry V. Levin]

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

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


-- 
ldv

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

[Sergey Y. Afonin]

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

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

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

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

[Dmitry V. Levin]

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

Нет.


-- 
ldv

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

[Sergey Afonin]

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

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

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

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