Re: [devel] Python 2.6: mass rebuild & git <-> srpm

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Anton Farygin]

19.11.2009 12:16, REAL пишет:
> Привет!
>
> В связи с подготовкой мегазадачи для пересборки питоньих пакетов встал
> такой вопрос. Довольно много пакетов до сих пор собираются из srpm, я же
> все без исключения пакеты собираю из git. Если делать shared task, чтобы
> была возможность у желающих сохранить сборку из srpm (видел тут не
> однажды упорное нежелание некоторых мейнтейнеров сдвигаться с места), мы
> её никогда не соберём: сизиф всё время будет убегать вперёд, из-за чего
> любая попытка сборки будет провалена. Да и лично мне потеря огромного
> количества времени на _неоднократное_ формирование такой задачи совсем
> никуда не упёрлась.

Не надо её неоднократно формировать. Достаточно удалить что-то из задачи 
и добавить заново.

>
> С другой стороны, вариант с удалением пакета и новой заливкой тоже не
> прокатит: по зависимостям слишком много потянется.
>
> А вопрос такой: уже есть возможность заливать из srpm пакеты, собранные
> из git? Если нет, как такую дилемму решать будем?

Нет, и видимо, не будет. Я не вижу тут никакой проблемы - у нас есть 
примеры, когда src.rpm отличным образом заливается в SharedTask.

[devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Привет!

В связи с подготовкой мегазадачи для пересборки питоньих пакетов встал 
такой вопрос. Довольно много пакетов до сих пор собираются из srpm, я 
же все без исключения пакеты собираю из git. Если делать shared task, 
чтобы была возможность у желающих сохранить сборку из srpm (видел тут 
не однажды упорное нежелание некоторых мейнтейнеров сдвигаться с 
места), мы её никогда не соберём: сизиф всё время будет убегать 
вперёд, из-за чего любая попытка сборки будет провалена. Да и лично 
мне потеря огромного количества времени на _неоднократное_ 
формирование такой задачи совсем никуда не упёрлась.

С другой стороны, вариант с удалением пакета и новой заливкой тоже не 
прокатит: по зависимостям слишком много потянется.

А вопрос такой: уже есть возможность заливать из srpm пакеты, 
собранные из git? Если нет, как такую дилемму решать будем?

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 04:16:34PM +0700, REAL wrote:
> Привет!
>
> В связи с подготовкой мегазадачи для пересборки питоньих пакетов встал  
> такой вопрос. Довольно много пакетов до сих пор собираются из srpm, я же 
> все без исключения пакеты собираю из git. Если делать shared task, чтобы 
> была возможность у желающих сохранить сборку из srpm (видел тут не 
> однажды упорное нежелание некоторых мейнтейнеров сдвигаться с места), мы 
> её никогда не соберём: сизиф всё время будет убегать вперёд, из-за чего 
> любая попытка сборки будет провалена. Да и лично мне потеря огромного 
> количества времени на _неоднократное_ формирование такой задачи совсем 
> никуда не упёрлась.
> А вопрос такой: уже есть возможность заливать из srpm пакеты, собранные 
> из git? Если нет, как такую дилемму решать будем?

Не совсем понял вопрос :(

Нет проблем залить пакет из git как srpm.
просто прогнать его через hasher,
и на полученный srpm добавить в task.

У меня есть утилита (прилагаю)
 girar-get-upload-method,
с ее помощью можно определить метод, которым собран
чужой пакет.

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

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

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

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

On Thu, Nov 19, 2009 at 11:19:10AM +0200, Igor Vlasenko wrote:
> У меня есть утилита (прилагаю)
>  girar-get-upload-method,
> с ее помощью можно определить метод, которым собран
> чужой пакет.

Сорри, теперь приложил.

-- 

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


[-- Attachment #2: girar-get-upload-method --]
[-- Type: text/plain, Size: 402 bytes --]

#!/bin/sh

name="$1"
#branch="${2:-sisyphus}"
branch="sisyphus"

#echo git ls-remote -h git://git.altlinux.org/gears/${name:0:1}/${name}.git refs/heads/$branch
commit=`git ls-remote -h git://git.altlinux.org/gears/${name:0:1}/${name}.git refs/heads/$branch 2>/dev/null`
RETVAL=$?
if [ $RETVAL -eq 0 ] && [ -n "$commit" ]; then
    echo gear
    RETVAL=0
else
    echo srpm
    RETVAL=1
fi
exit $RETVAL

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Anton Farygin пишет:
> Не надо её неоднократно формировать. Достаточно удалить что-то из задачи 
> и добавить заново.

При сотнях пакетов нужно будет удалять сам пакет и все последующие, а 
потом добавлять заново (особенно если пакет расположен ближе к началу 
задачи - это не имеет смысла). И потом заново просить мейнтейнеров 
делать task approve (потому что тут уже высказывались люди, не 
желающие выдавать acl или nmu), причём, для новых номеров подзадач. 
Намного проще переформировать задачу заново, так и номера подзадач 
останутся прежними.

Хотя, тут ещё зависит от положения пакета в списке: если он ближе к 
концу, есть варианты.

>> А вопрос такой: уже есть возможность заливать из srpm пакеты, собранные
>> из git? Если нет, как такую дилемму решать будем?
> 
> Нет, и видимо, не будет. Я не вижу тут никакой проблемы - у нас есть 
> примеры, когда src.rpm отличным образом заливается в SharedTask.

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

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
>> А вопрос такой: уже есть возможность заливать из srpm пакеты, собранные 
>> из git? Если нет, как такую дилемму решать будем?
> 
> Не совсем понял вопрос :(
> 
> Нет проблем залить пакет из git как srpm.

Есть проблема: я этого делать не буду.

> У меня есть утилита (прилагаю)
>  girar-get-upload-method,
> с ее помощью можно определить метод, которым собран
> чужой пакет.

Это я и так знаю для каждого пакета (сам ведь делал git clone).

> А менять метод заливки без согласования с владельцем 
> нехорошо.

Вот поэтому я и начал это обсуждение, чтобы высветить как минимум саму 
возможность запустить задачу (НЕтестовую) на сборку. Помнишь, ты сам 
недавно говорил про очень плохую идею shared task при большом числе 
пакетов? Вот это оно и есть.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

REAL пишет:
>>> А вопрос такой: уже есть возможность заливать из srpm пакеты, 
>>> собранные из git? Если нет, как такую дилемму решать будем?
>>
>> Не совсем понял вопрос :(
>>
>> Нет проблем залить пакет из git как srpm.
> 
> Есть проблема: я этого делать не буду.

Хотя... наверно, я что-то не так понял. Что имеется в виду под "залить 
пакет из git как srpm"? Вот если "залить пакет из git как git" 
выглядит как "ssh git.alt build пакет тэг", то как будет выглядеть 
команда для "залить пакет из git как srpm" при фактическом отсутствии 
srpm и моём категорическом отказе пользоваться устаревшим механизмом 
incoming, т.е. при наличии только самого git-репозитория на git.alt?

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 05:34:02PM +0700, REAL wrote:
> Я извиняюсь за такой поток писем, но тема сложная, и хорошо бы все
> вопросы решить ещё до того, как начнётся реальная нервотрёпка...
>
> Igor Vlasenko пишет:
>> А менять метод заливки без согласования с владельцем нехорошо.
>
> Есть ещё один момент: пакеты, собирать которые я имею право уже сейчас
> (т.е. не у меня acl, ибо я такие пакеты уже давно из git собрал, а
> либо пакеты входят в группу @everybody, либо @python), требуется ли
> согласование на сборку из git для таких пакетов? И с кем, если кроме
> группы, в acl никого нет?

Наверное не требуется. То, что вы сейчас делаете - важнее.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
> А менять метод заливки без согласования с владельцем 
> нехорошо.

И вот ещё какой вопрос в связи с ранее сказанным встаёт. Учитывая, что 
пакетов, залитых как srpm, в сизифе очень много, как будем проводить 
такое согласование, если нет способа из git.alt заливать пакеты, 
притворяясь srpm?

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

Так что хотелось бы осуществить сие действо попроще: либо каждый 
мейнтейнер ЗА заливку его пакетов из git, либо ПРОТИВ. Как я понимаю, 
в этой рассылке с этим ничего не выйдет, придётся обращаться личной 
почтой. Итак: что делать в случае, когда мейнтейнер не реагирует (а 
это часто бывает и при вполне живых и активных мейнейнерах)?

PS. Если же способ "залить пакет из git.alt как srpm" всё же есть, а 
просто это я такой тёмный, это письмо, видимо, можно забыть :)

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 05:25:25PM +0700, REAL wrote:
> Igor Vlasenko пишет:
>> А менять метод заливки без согласования с владельцем нехорошо.
> Поясню. Когда тестовая задача будет полностью закончена (что означает:  
> всё соберётся, останутся сбои только из-за обновлённых пакетов в сизифе 
> и/или отсутствия прав на заливку), я дам ссылку на эту задачу, где будет 
> полный список пакетов. Проблема заключается в том, что пакетов очень 
> много, и по каждому отдельному пакету такое согласование проводить очень 
> нехорошо.

Это зависит от выбранного вами метода.
я бы, например, сначала занялся бы сбором acl/nmu,
в течении 15 дней.
если nmu не хватало бы - через 15 дней пошел бы 
к Администратору (Станиславу)
получать nmu принудительно, согласно ACL/NMU policy.
и только получив все разрешения, стал бы формировать задачу.



-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

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

Igor Vlasenko пишет:
> А менять метод заливки без согласования с владельцем 
> нехорошо.

Есть ещё один момент: пакеты, собирать которые я имею право уже сейчас
(т.е. не у меня acl, ибо я такие пакеты уже давно из git собрал, а
либо пакеты входят в группу @everybody, либо @python), требуется ли
согласование на сборку из git для таких пакетов? И с кем, если кроме
группы, в acl никого нет?

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 04:55:59PM +0700, REAL wrote:
> Хотя... наверно, я что-то не так понял. Что имеется в виду под "залить  
> пакет из git как srpm"? Вот если "залить пакет из git как git" выглядит 
> как "ssh git.alt build пакет тэг", то как будет выглядеть команда для 
> "залить пакет из git как srpm" при фактическом отсутствии srpm и моём 
> категорическом отказе пользоваться устаревшим механизмом incoming, т.е. 
> при наличии только самого git-репозитория на git.alt?

не устаревшим incoming (он уже вроде бы не работает), а новым incoming.
предварительно заливаете пересобранные в hasher пакеты 
(вы же их все равно пересоберете в hasher, для проверки)
rsync -v -rlt --partial --stats -e ssh *.src.rpm git.alt: 

а потом в цикле делаете либо
ssh git.alt task add foo.git 1.0-alt1
либо 
ssh git.alt task add srpm foo-1.0-alt1.src.rpm
в зависимости от метода сборки.

это очень просто и легко скриптуется.

if (girar-upload-method $name); then
    ssh git.alt task add $name.git $tag
else
    ssh git.alt task add srpm $name-$tag.src.rpm
fi
-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 04:43:12PM +0700, REAL wrote:
> Я уже говорил, что формировать такую задачу придётся в течение не одного 
> месяца. В общем, я готов сделать исключение для тех пакетов, мейнтейнеры 
> которых могут оперативно (в течение минут) реагировать на сообщения 
> (почтой или жабером), иначе - ни за какие деньги.

Я бы советовал отложить формирование задачи на самый последний момент,
также есть трюки как принудительно закончить задачу, напр.
http://www.altlinux.org/Unmets_Creation_Policy
и возложить решение проблем на тех, кто их создал.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
> Это зависит от выбранного вами метода.
> я бы, например, сначала занялся бы сбором acl/nmu,
> в течении 15 дней.
> если nmu не хватало бы - через 15 дней пошел бы 
> к Администратору (Станиславу)
> получать nmu принудительно, согласно ACL/NMU policy.
> и только получив все разрешения, стал бы формировать задачу.

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

Так что тут надо ещё решить, что лучше и что конкретно делать.

PS. Хотя, наверно, можно развесить запросы на nmu на все пакеты, кроме 
тех, которые висят на aris и/или @gnome. Если не будет возражений, 
видимо, так и сделаю.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 05:51:50PM +0700, REAL wrote:
> Igor Vlasenko пишет:
>> Это зависит от выбранного вами метода.
>> я бы, например, сначала занялся бы сбором acl/nmu,
>> в течении 15 дней.
>> если nmu не хватало бы - через 15 дней пошел бы к Администратору 
>> (Станиславу)
>> получать nmu принудительно, согласно ACL/NMU policy.
>> и только получив все разрешения, стал бы формировать задачу.
>
> Я вот сейчас не знаю, оправдает ли себя такой подход. Раньше думал  
> именно в этом направлении пойти, но недавнее обсуждение здесь показало, 
> что есть мейнтейнеры, которые против выдачи nmu кому-либо.

я специально для таких случаев писал
http://www.altlinux.org/Unmets_Creation_Policy

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 06:10:46PM +0700, REAL wrote:
>> http://www.altlinux.org/Unmets_Creation_Policy
>> и возложить решение проблем на тех, кто их создал.
>
> А это я не знаю даже, каким боком к нашей проблеме. Или имеется в виду, 
> что за время формирования задачи в сизиф проскочат пакеты, которые 
> собираются в этой задачи, породив конфликт версий? Так это, по-моему, не 
> решить никак, только удалением и добавлением по-новой пакетов в задачу. 
> Вряд ли ради этого дела кто-то станет блокировать заливку в сизиф 
> пакетов, это несерьёзно.

Unmets_Creation_Policy -- это механизм, как порождать
в репозитории новые unmets. 

Зачем это нужно, кроме bootstrap? 
Разберем на примере python.
Да, может быть и так, что кто-то не может/не хочет дать acl.
Но даже пусть все дадут с радостью - 
не будем искать чью-то злую волю.
Даже если все майнтайнеры с готовностью согласились -
а все ли 400 пакетов успешно пересоберутся с новым питоном?

Вполне вероятно, что 2-3 пакета отвалятся,
их по хорошему надо будет серьезно переписывать.
А вы не апстрим. 
И эти 2-3 пакета не будут пропускать в сизиф 400.
Чтобы такого не случилось,
подмешайте пакет unmet-dependency-python2.5,
а по окончании задачи попросите администратора его удалить.



-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 06:20:38PM +0700, REAL wrote:
> Зайду с другой стороны: сделать пакет-заглушку для пакетов  
> python2.5(xxx), чтобы не пересобранные пакеты не мешали завершить  
> задачу, а сами эти проблемные пакеты собираю с другим именем (скажем,  
> python-module-%{name}2.6 вместо python-module-%name). Но в таком случае я 
> вообще не понимаю, зачем всё это: репозиторий будет разломан, причём 
> основательно.

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

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
> Я бы советовал отложить формирование задачи на самый последний момент,

Это и так будет в самом конце. Для начала мне нужно будет погонять 
тестовую задачу, чтобы всё собиралось хотя бы. Потом - получить 
возможность все эти пакеты залить (либо acl, либо nmu, либо task 
approve для случая особо злобных мейнтейнеров). И под самый конец - 
собственно формирование задачи, которое упрётся в цикл 
добавления/удаления пакетов из-за обновления их же из других задач.

> также есть трюки как принудительно закончить задачу, напр.
> http://www.altlinux.org/Unmets_Creation_Policy
> и возложить решение проблем на тех, кто их создал.

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

Или речь про bootstrap? Так у меня пока не возникло с этим проблем. 
Есть совсем мало пакетов, которые надо бутстрапить, но это никаких 
анметов не породит.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 06:27:15PM +0700, REAL wrote:
> Пересоберутся все (по крайней мере, я пока не встретил тех, которые не  
> удалось починить, а счёт уже почти дошёл до 500; те, которые не  
> пересобираются, чиню на месте, иначе не вижу смысла даже тестовую задачу 
> начинать), вопрос в том, установятся ли. Вот насчёт установки - да, для 
> этого мне и нужна тестовая задача, она выявит, чего не хватает, включая и 
> те пакеты, которые выпали из поля зрения, т.е. их нужно пересобрать, а в 
> задачу они не попали по тем или иным причинам.

Заскриптуйте создание тестовой задачи,
и будете ее заливать хоть 10 раз на день
(но лучше на ночь :)

а заглушку я советую вставить уже в боевую задачу,
по итогам :)

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
>> Я вот сейчас не знаю, оправдает ли себя такой подход. Раньше думал  
>> именно в этом направлении пойти, но недавнее обсуждение здесь показало, 
>> что есть мейнтейнеры, которые против выдачи nmu кому-либо.
> 
> я специально для таких случаев писал
> http://www.altlinux.org/Unmets_Creation_Policy

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

1. Развешиваю полчища запросов nmu в багзилле
2. Через 15 дней формирую реальную задачу и запускаю на выполнение
3. Пакеты, которые не удаётся залить из-за отсутствия nmu, удаляю из 
задания, заменяя заглушкой unmet-dependency-py26.
4. Заново запускаю задачу.

Иначе не представляю себе, как это полиси применить. Но в нашем случае 
это не работает: не будут собираться пакеты, которые имеют проблемные 
пакеты в качестве BuildRequires.

Зайду с другой стороны: сделать пакет-заглушку для пакетов 
python2.5(xxx), чтобы не пересобранные пакеты не мешали завершить 
задачу, а сами эти проблемные пакеты собираю с другим именем (скажем, 
python-module-%{name}2.6 вместо python-module-%name). Но в таком 
случае я вообще не понимаю, зачем всё это: репозиторий будет разломан, 
причём основательно.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
> Даже если все майнтайнеры с готовностью согласились -
> а все ли 400 пакетов успешно пересоберутся с новым питоном?
> 
> Вполне вероятно, что 2-3 пакета отвалятся,

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

Так что для этого случая unmets creation даже в мыслях не держу.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Igor Vlasenko пишет:
> Заскриптуйте создание тестовой задачи,
> и будете ее заливать хоть 10 раз на день
> (но лучше на ночь :)

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

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Alexey I. Froloff]

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

On Thu, Nov 19, 2009 at 11:21:43AM +0200, Igor Vlasenko wrote:
> #!/bin/sh
         ^^
> commit=`git l...s/${name:0:1}/${name}.git ...l`
                      ^^^^^^^^
Wrong.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Igor Vlasenko]

On Thu, Nov 19, 2009 at 03:03:33PM +0300, Alexey I. Froloff wrote:
> On Thu, Nov 19, 2009 at 11:21:43AM +0200, Igor Vlasenko wrote:
> > #!/bin/sh
>          ^^
> > commit=`git l...s/${name:0:1}/${name}.git ...l`

Согласен, башизм. 
Спасибо, 
исправил на /bin/bash.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

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

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

On Thu, Nov 19, 2009 at 01:12:49PM +0200, Igor Vlasenko wrote:

IV> Заскриптуйте создание тестовой задачи,
IV> и будете ее заливать хоть 10 раз на день
IV> (но лучше на ночь :)

Я не понял чем не подходил удаление/добавление подзадач в один и тот же
task?

Или проблема в том, что необходимо сохранить определенную очередность
сборки пакетов?

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

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

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[REAL]

Денис Смирнов пишет:
> Я не понял чем не подходил удаление/добавление подзадач в один и тот же
> task?
> 
> Или проблема в том, что необходимо сохранить определенную очередность
> сборки пакетов?

Да, проблема именно в этом.

-- 

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

Re: [devel] Python 2.6: mass rebuild & git <-> srpm

[Michael Shigorin]

On Fri, Nov 20, 2009 at 01:13:00PM +0700, REAL wrote:
> >Я не понял чем не подходил удаление/добавление подзадач в один
> >и тот же task?  Или проблема в том, что необходимо сохранить
> >определенную очередность сборки пакетов?
> Да, проблема именно в этом.

Если б можно было при надобности вручную задавать номер subtask,
был бы применим старый подход bindmaster'ов а-ля BASIC:

10   __ 35
20  /
30 L
40

:)

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