* [devel] Q: редкие примеры .gear/rules ? @ 2014-06-17 19:42 Igor Vlasenko 2014-06-18 4:45 ` Eugene Prokopiev ` (3 more replies) 0 siblings, 4 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-17 19:42 UTC (permalink / raw) To: devel Господа, не знает ли кто-нибудь примеров gear репозиториев 1) вне kernel-modules-*, в которых в .gear/rules используется директива specsubst: ? 2) в которых в .gear/rules в директивах tar*: diff*: используется опция spec=<альтернативный.spec> потестировать, как с такими репозиториями будет работать библиотечка perl-Gear-Rules. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-17 19:42 [devel] Q: редкие примеры .gear/rules ? Igor Vlasenko @ 2014-06-18 4:45 ` Eugene Prokopiev 2014-06-18 17:53 ` Igor Vlasenko 2014-06-19 7:52 ` Igor Vlasenko 2014-06-18 6:14 ` [devel] Q: редкие примеры .gear/rules ? Anton Farygin ` (2 subsequent siblings) 3 siblings, 2 replies; 34+ messages in thread From: Eugene Prokopiev @ 2014-06-18 4:45 UTC (permalink / raw) To: ALT Linux Team development discussions 17 июня 2014 г., 23:42 Igor Vlasenko написал: > 1) вне kernel-modules-*, в которых в .gear/rules > используется директива specsubst: ? http://git.altlinux.org/people/enp/packages/netxms.git обновлять его роботом (только для Сизифа) было бы очень интересно -- WBR, Eugene Prokopiev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 4:45 ` Eugene Prokopiev @ 2014-06-18 17:53 ` Igor Vlasenko 2014-06-19 7:52 ` Igor Vlasenko 1 sibling, 0 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-18 17:53 UTC (permalink / raw) To: ALT Linux Team development discussions On Wed, Jun 18, 2014 at 08:45:39AM +0400, Eugene Prokopiev wrote: > 17 июня 2014 г., 23:42 Igor Vlasenko написал: > > > 1) вне kernel-modules-*, в которых в .gear/rules > > используется директива specsubst: ? > > http://git.altlinux.org/people/enp/packages/netxms.git О, спасибо! > обновлять его роботом (только для Сизифа) было бы очень интересно первым делом хочу проверить и допилить мои утилиты, чтобы они нормально работали с таким репозиторием. для обновления еше код не написан. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 4:45 ` Eugene Prokopiev 2014-06-18 17:53 ` Igor Vlasenko @ 2014-06-19 7:52 ` Igor Vlasenko 2014-06-19 8:00 ` Eugene Prokopiev 1 sibling, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 7:52 UTC (permalink / raw) To: ALT Linux Team development discussions On Wed, Jun 18, 2014 at 08:45:39AM +0400, Eugene Prokopiev wrote: > > 1) вне kernel-modules-*, в которых в .gear/rules > > используется директива specsubst: ? > > http://git.altlinux.org/people/enp/packages/netxms.git > > обновлять его роботом (только для Сизифа) было бы очень интересно Прошу прощения, пришлите, пожалуйста, из netxms.git еще для опытов .git/config и, если есть что-то в .git/remotes/ (в старом формате), то и их. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-19 7:52 ` Igor Vlasenko @ 2014-06-19 8:00 ` Eugene Prokopiev 2014-06-19 11:08 ` [devel] Gear и внешние VCS Igor Vlasenko 0 siblings, 1 reply; 34+ messages in thread From: Eugene Prokopiev @ 2014-06-19 8:00 UTC (permalink / raw) To: ALT Linux Team development discussions 19 июня 2014 г., 11:52 Igor Vlasenko написал: > Прошу прощения, пришлите, пожалуйста, из netxms.git еще для опытов > .git/config и, если есть что-то в .git/remotes/ (в старом формате), > то и их. Пожалуйста: $ cat git/netxms/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote "svn"] url = https://svn.netxms.org/public/netxms fetch = trunk:refs/remotes/trunk branches = branches/*:refs/remotes/* tags = tags/*:refs/remotes/tags/* [remote "origin"] url = git.alt:packages/netxms fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [remote "upstream"] url = git://git.netxms.org/public/netxms.git fetch = +refs/heads/*:refs/remotes/upstream/* $ ls git/netxms/.git/remotes ls: невозможно получить доступ к git/netxms/.git/remotes: Нет такого файла или каталога Апстрим переехал с svn на git некоторое время назад -- WBR, Eugene Prokopiev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 8:00 ` Eugene Prokopiev @ 2014-06-19 11:08 ` Igor Vlasenko 2014-06-19 11:10 ` Anton Farygin 0 siblings, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 11:08 UTC (permalink / raw) To: ALT Linux Team development discussions На примере netxms расскажу планы по автоматизации работы с VCS - обновляемыми gear репозиториями. Итак, если у нас один VCS - обновляемый gear репозиторий, то проверить, есть ли обновление, тривиально. заходим, запускаем git fetch <upstream>, глазами смотрим, что приехало. Если же у нас 100 gear репозиториев, то, тратя по 20 секунд на репозиторий, их ручная проверка заберет у нас больше, чем пол часа. Хотелось бы в духе unix-way напустить на нашу коллекцию gear репозиториев какой-нибудь умный скрипт, скажем, будущий rpm-uscan, который меньше чем за минуту проверил бы все репозитории, съэкономив бы нам полчаса, и даже эту минуту, пока он работал, можно было бы потратить с пользой, сделав новую чашку кофе. С tarball обновляемыми gear репозиториями справляется и старый rpm-uscan, осталось научиться работать с VCS - обновляемыми gear репозиториями. Там тоже простой алгоритм - руками мы запускаем git fetch <upstream>, глазами смотрим, что приехало. Просмотр робот будет делать так: запускает git tags, фильтрует (по умолчанию будет фильтр ^ v?([0-9\.]+[0-9]) $, если апстрим любит теги в другом формате, к примеру, 1.2-release, то для них надо будет создать специальный файл, скажем, .gear/upstream/tag-filter, формат и опции будут похожи на debian/watch), сравнивает версии из отфильтрованных тегов с текущей, и если найдет бОльшую, то приехало обновление. но, перед просмотром, робот должен знать remote <upstream>. просто просмотреть теги ему достаточно будет git ls-remote --tags <upstream> а для обновления ему понадобится сделать git fetch <upstream>. Соответственно, нужно указать роботу, какой remote использовать. для этого нужен будет специальный файл, скажем, .gear/upstream/remotes. Формат этого файла, думаю, формат git-config(1). в нем должен находиться фрагмент .git/config, который отвечает за текущие используемые remotes. Для netxms .gear/upstream/remotes будет иметь вид: ==== .gear/upstream/remotes ========================= [remote "upstream"] url = git://git.netxms.org/public/netxms.git fetch = +refs/heads/*:refs/remotes/upstream/* ===================================================== если бы использовался мерж в локальную ветвь upstream, то там могло бы быть что-то вроде ==== .gear/upstream/remotes ========================= [remote "upstream"] url = git://git.netxms.org/public/netxms.git fetch = +refs/heads/*:refs/remotes/upstream/* [branch "upstream"] remote = upstream merge = refs/heads/upstream ===================================================== его можно легко создать руками, скопировав туда нужный кусок из .git/config. Обратно восстановить рабочий .git/config в клоне из неполноценной копии на git.alt тоже тривиально: cat .gear/upstream/remotes >> .git/config. Но, конечно, лучше иметь специализированные утилиты gear-store-remotes / gear-restore-remotes. так, gear-restore-remotes сделает backup .git/config, проверит, нет ли уже там тех ключей, и не запустится, если найдет. gear-store-remotes проверит сначала, есть ли .git/remotes/*. если найдется .git/remotes/foo, не указывающий на git.alt, gear-store-remotes посоветует сначала сконвертировать его в новый формат (в .git/config) командой git remote rename foo foo и с таким сообщением завершится. Далее, в случае .git/config для netxms внизу, gear-store-remotes проигнорирует [remote "origin"], так как он указывает на git.alt. Для netxms останется 2 remote: [svn-remote "svn"] и [remote "upstream"]. если бы остался только один, gear-store-remotes его бы молча и выбрал, а также, если есть, связанные с этим remotes бранчи. Поскольку найдено 2 remote, то утилита спросит у майнтайнера, какие из них сохранить. можно ей указать опциями, --all-remotes, или --remotes=upstream, или же она выведет dialog(1) чтобы майнтайнер отметил, какие remotes он светит наружу, для того, чтобы другие майнтайнеры и роботы могли пользоваться его gear репозиторием. Затем утилита записывает выбранный фрагмент конфига в .gear/upstream/remotes и вызывает git add .gear/upstream/remotes. Теперь репозиторий, в котором есть .gear/upstream/remotes, становится полноценным с точки зрения возможности совместной рааботы. Работа с ним выглядит приблизительно так: $ girar-clone-build-commit foo $ cd foo.git $ gear-restore-remotes $ gear-fetch $ fix bugs (например, оформляем апстримный коммит с исправлением как патч) $ srpmnmu -i *.spec $ girar-nmu-helper-git-push-build -c -T $ cd .. $ rm -rf foo.git Соответственно, когда такие утилиты будут готовы, надо будет просить всех майнтайнеров, использующих VCS - обновляемые gear репозитории, создать и опубликовать в этих репозиториях .gear/upstream/remotes, а если есть желание ограничить доступ к своему репозиторию, то делать это с помощью acl, а не сокрытием его служебной информации. On Thu, Jun 19, 2014 at 12:00:08PM +0400, Eugene Prokopiev wrote: > 19 июня 2014 г., 11:52 Igor Vlasenko написал: > > Прошу прощения, пришлите, пожалуйста, из netxms.git еще для опытов > > .git/config и, если есть что-то в .git/remotes/ (в старом формате), > > то и их. > Пожалуйста: > > $ cat git/netxms/.git/config > [core] > repositoryformatversion = 0 > filemode = true > bare = false > logallrefupdates = true > [svn-remote "svn"] > url = https://svn.netxms.org/public/netxms > fetch = trunk:refs/remotes/trunk > branches = branches/*:refs/remotes/* > tags = tags/*:refs/remotes/tags/* > [remote "origin"] > url = git.alt:packages/netxms > fetch = +refs/heads/*:refs/remotes/origin/* > [branch "master"] > remote = origin > merge = refs/heads/master > [remote "upstream"] > url = git://git.netxms.org/public/netxms.git > fetch = +refs/heads/*:refs/remotes/upstream/* > > $ ls git/netxms/.git/remotes > ls: невозможно получить доступ к git/netxms/.git/remotes: Нет такого > файла или каталога > > Апстрим переехал с svn на git некоторое время назад -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 11:08 ` [devel] Gear и внешние VCS Igor Vlasenko @ 2014-06-19 11:10 ` Anton Farygin 2014-06-19 11:55 ` Igor Vlasenko 0 siblings, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 11:10 UTC (permalink / raw) To: devel On 19.06.2014 15:08, Igor Vlasenko wrote: > Соответственно, когда такие утилиты будут готовы, > надо будет просить всех майнтайнеров, использующих > VCS - обновляемые gear репозитории, создать и опубликовать > в этих репозиториях .gear/upstream/remotes, > а если есть желание ограничить доступ к своему репозиторию, > то делать это с помощью acl, а не сокрытием его служебной > информации. я в соседнем письме написал, почему нет смысла использовать для этого .gear/upstream/remotes т.е. - я не хотел бы использовать инструмент, который будет мне предоставлять алгоритм работы другого ментейнра. например, мне привычнее upstream remote держать в бранче не upstream, а source. Как тут быть ? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 11:10 ` Anton Farygin @ 2014-06-19 11:55 ` Igor Vlasenko 2014-06-19 12:10 ` Anton Farygin 0 siblings, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 11:55 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin On Thu, Jun 19, 2014 at 03:10:55PM +0400, Anton Farygin wrote: > On 19.06.2014 15:08, Igor Vlasenko wrote: > >Соответственно, когда такие утилиты будут готовы, > >надо будет просить всех майнтайнеров, использующих > >VCS - обновляемые gear репозитории, создать и опубликовать > >в этих репозиториях .gear/upstream/remotes, > >а если есть желание ограничить доступ к своему репозиторию, > >то делать это с помощью acl, а не сокрытием его служебной > >информации. > > я в соседнем письме написал, почему нет смысла использовать для > этого .gear/upstream/remotes > т.е. - я не хотел бы использовать инструмент, который будет мне > предоставлять алгоритм работы другого ментейнра. > например, мне привычнее upstream remote держать в бранче не > upstream, а source. > > Как тут быть ? Легко :) 2 файла .gear/upstream/tag-filter и .gear/upstream/remotes - это формат, в котором будет храниться служебная информация, которая будет необходима для watch по tag. При этом .gear/upstream/remotes имеет более глубокий смысл - * он позволяет сделать информацию о remotes публичной, * может использоваться независимо от того, нужен ли watch по tag, * крайне нужен NMUшникам. Но из этого совершенно не следует, что если пакет foo одновременно сопровождает 2 майнтайнера A и B, то если один из них создал .gear/upstream/remotes, (например, А), то второй (В) отгребет из этого файла не нужные ему ветви. Ведь никто не заставляет выполнять у себя gear-restore-remotes, и робот тоже не будет этого делать. Я в позапрошлом письме рассматривал алгоритм обновления. Если в gear/rules тег, как в tar:v@version@: . то там достаточно использовать временную служебную ветвь, какой-нибудь gearobersturmbannbranch. Однако, служебная ветвь -- это мусор в репозитории, поэтому умный робот проверит, есть ли в .git/config ветви, описанные в .gear/upstream/remotes, если есть, будет использовать их, чтобы не мусорить, если же нет, создаст свой gearobersturmbannbranch. Если майнтайнер B тоже не хочет, чтобы у него создавался gearobersturmbannbranch, а использовались его собственные, отличные от майнтайнера A названия ветвей, он может добавить файл .gear/upstream/remotes.$USER, который будет иметь приоритет перед .gear/upstream/remotes. А еще можно export GEAR_UPSTREAM_REMOTES_SUFFIX=..smth.., и перекрыть все с помощью .gear/upstream/remotes.$GEAR_UPSTREAM_REMOTES_SUFFIX если вдруг понадобится. Конечно, в gear/rules архив может создаваться не по тегу, а по ветви: tar:upstream: . но тогда от создания у себя ветви upstream никуда не деться, против лома нет приема, она железобетонно прописана в gear/rules, разве что форкать свои .gear/rules. Так хорошо? -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 11:55 ` Igor Vlasenko @ 2014-06-19 12:10 ` Anton Farygin 2014-06-19 12:17 ` Igor Vlasenko 0 siblings, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 12:10 UTC (permalink / raw) To: devel On 19.06.2014 15:55, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 03:10:55PM +0400, Anton Farygin wrote: >> On 19.06.2014 15:08, Igor Vlasenko wrote: >>> Соответственно, когда такие утилиты будут готовы, >>> надо будет просить всех майнтайнеров, использующих >>> VCS - обновляемые gear репозитории, создать и опубликовать >>> в этих репозиториях .gear/upstream/remotes, >>> а если есть желание ограничить доступ к своему репозиторию, >>> то делать это с помощью acl, а не сокрытием его служебной >>> информации. >> >> я в соседнем письме написал, почему нет смысла использовать для >> этого .gear/upstream/remotes >> т.е. - я не хотел бы использовать инструмент, который будет мне >> предоставлять алгоритм работы другого ментейнра. >> например, мне привычнее upstream remote держать в бранче не >> upstream, а source. >> >> Как тут быть ? > > Легко :) > > 2 файла .gear/upstream/tag-filter и > .gear/upstream/remotes - это формат, > в котором будет храниться служебная информация, > которая будет необходима для watch по tag. > > При этом .gear/upstream/remotes имеет более > глубокий смысл - > > * он позволяет сделать информацию о remotes публичной, > * может использоваться независимо от того, нужен ли watch по tag, > * крайне нужен NMUшникам. > > Но из этого совершенно не следует, что если пакет foo > одновременно сопровождает 2 майнтайнера A и B, то > если один из них создал .gear/upstream/remotes, > (например, А), то второй (В) > отгребет из этого файла не нужные ему ветви. следует что каждому мейнтейнеру для каждого своего пакета придётся делать действия, которых можно было бы избежать. > > Ведь никто не заставляет выполнять у себя > gear-restore-remotes, и робот тоже не будет этого > делать. Я в позапрошлом письме рассматривал алгоритм > обновления. Если в gear/rules тег, как в > tar:v@version@: . > то там достаточно использовать временную служебную ветвь, > какой-нибудь gearobersturmbannbranch. > Однако, служебная ветвь -- это мусор в репозитории, > поэтому умный робот проверит, есть ли в .git/config > ветви, описанные в .gear/upstream/remotes, > если есть, будет использовать их, чтобы не мусорить, > если же нет, создаст свой gearobersturmbannbranch. Умный робот мог бы посмотреть, если ли remotes на апстрим, описанный в watch файле и если есть - сделать fetch им, а не в отдельную служебную ветку. > > Если майнтайнер B тоже не хочет, чтобы у него создавался > gearobersturmbannbranch, а использовались его собственные, > отличные от майнтайнера A названия ветвей, > он может добавить файл .gear/upstream/remotes.$USER, > который будет иметь приоритет перед .gear/upstream/remotes. > А еще можно export GEAR_UPSTREAM_REMOTES_SUFFIX=..smth.., > и перекрыть все с помощью > .gear/upstream/remotes.$GEAR_UPSTREAM_REMOTES_SUFFIX > если вдруг понадобится. а что делать, если мейнтейнер не хочет записывать что-то в .gear/upstream (и тем более публиковать это) ? > > Конечно, в gear/rules архив может создаваться не по тегу, > а по ветви: tar:upstream: . > но тогда от создания у себя ветви upstream никуда не деться, > против лома нет приема, она железобетонно прописана в gear/rules, > разве что форкать свои .gear/rules. > > Так хорошо? Нет, плохо. Мне хотелось бы понять, чем не устраивает вариант с созданием веток под "настройки мейнтейнера" а не в соответствии с .gear/upstream/remotes ? Зачем плодить лишние сущности ? сделайте в домашнем каталоге .uupdate-branches и в нём пропишите все необходимые ветки. ну и дефолт в виде upstream upstream ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 12:10 ` Anton Farygin @ 2014-06-19 12:17 ` Igor Vlasenko 2014-06-19 12:49 ` Anton Farygin 0 siblings, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 12:17 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin On Thu, Jun 19, 2014 at 04:10:14PM +0400, Anton Farygin wrote: > >Но из этого совершенно не следует, что если пакет foo > >одновременно сопровождает 2 майнтайнера A и B, то > >если один из них создал .gear/upstream/remotes, > >(например, А), то второй (В) > >отгребет из этого файла не нужные ему ветви. > > следует что каждому мейнтейнеру для каждого своего пакета придётся > делать действия, которых можно было бы избежать. В смысле? я же вроде бы описал, что не нужно никаких действий. Можно на примере? какие придется делать действия? -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 12:17 ` Igor Vlasenko @ 2014-06-19 12:49 ` Anton Farygin 2014-06-19 13:09 ` Anton Farygin 2014-06-19 14:24 ` Igor Vlasenko 0 siblings, 2 replies; 34+ messages in thread From: Anton Farygin @ 2014-06-19 12:49 UTC (permalink / raw) To: devel On 19.06.2014 16:17, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 04:10:14PM +0400, Anton Farygin wrote: >>> Но из этого совершенно не следует, что если пакет foo >>> одновременно сопровождает 2 майнтайнера A и B, то >>> если один из них создал .gear/upstream/remotes, >>> (например, А), то второй (В) >>> отгребет из этого файла не нужные ему ветви. >> >> следует что каждому мейнтейнеру для каждого своего пакета придётся >> делать действия, которых можно было бы избежать. > > В смысле? я же вроде бы описал, что не нужно никаких > действий. > > Можно на примере? какие придется делать действия? Создавать и поддерживать в рабочем состоянии .gear/upstream/* Да, понимаю что это вызов скрипта, но всё-таки - зачем, если можно и без этого обойтись ? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 12:49 ` Anton Farygin @ 2014-06-19 13:09 ` Anton Farygin 2014-06-19 14:38 ` Igor Vlasenko 2014-06-19 14:24 ` Igor Vlasenko 1 sibling, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 13:09 UTC (permalink / raw) To: devel On 19.06.2014 16:49, Anton Farygin wrote: > On 19.06.2014 16:17, Igor Vlasenko wrote: >> On Thu, Jun 19, 2014 at 04:10:14PM +0400, Anton Farygin wrote: >>>> Но из этого совершенно не следует, что если пакет foo >>>> одновременно сопровождает 2 майнтайнера A и B, то >>>> если один из них создал .gear/upstream/remotes, >>>> (например, А), то второй (В) >>>> отгребет из этого файла не нужные ему ветви. >>> >>> следует что каждому мейнтейнеру для каждого своего пакета придётся >>> делать действия, которых можно было бы избежать. >> >> В смысле? я же вроде бы описал, что не нужно никаких >> действий. >> >> Можно на примере? какие придется делать действия? > > Создавать и поддерживать в рабочем состоянии .gear/upstream/* > > Да, понимаю что это вызов скрипта, но всё-таки - зачем, если можно и без > этого обойтись ? Добавлю пример: пакет glusterfs3 склонировал прямо из gears ветка sisyphus смотрим rules: $ cat .gear/rules copy: *.glusterfs copy: *.logrotate copy: *.service copy: *.sysconfig copy: *.init spec: glusterfs3.spec tar: v@version@:. diff: v@version@:. . ага, мейнтейнер собирает по тэгу, отлично. гуглим апстрим. добавляем upstream remote делаю ему fetch прилетает новый тэг. делаю merge с этим тэгом прямо в ветку sisyphus (без upstream бранча, он не нужен вообще когда можно брать тарболл по апстримному тэгу, да и в других случаях его необходимость вещь весьма условная). резолвим конфликты, возникшие при merge и начинаем собирать. Вот зачем мне в этом usecase информация о том, где и в каких ветках Alexei Takaseev хранит апстримы и с чем делает мерж ? Вся недостающая информация - это адрес апстримного гита и формат тэга, который описывает релиз. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 13:09 ` Anton Farygin @ 2014-06-19 14:38 ` Igor Vlasenko 0 siblings, 0 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 14:38 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin On Thu, Jun 19, 2014 at 05:09:26PM +0400, Anton Farygin wrote: > Вот зачем мне в этом usecase информация о том, где и в каких ветках > Alexei Takaseev хранит апстримы и с чем делает мерж ? > > Вся недостающая информация - это адрес апстримного гита и формат > тэга, который описывает релиз. Сорри, только сейчас обратил внимание. да, адрес апстримного гита и формат тэга, который описывает релиз - основная информация, а информация о ветвях - вспомогательная, которую можно не указывать. Вообще, наверное, рано спорить, надо сначала написать код и посмотреть, что ему реально будет нужно. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 12:49 ` Anton Farygin 2014-06-19 13:09 ` Anton Farygin @ 2014-06-19 14:24 ` Igor Vlasenko 2014-06-19 17:02 ` Anton Farygin 1 sibling, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 14:24 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin On Thu, Jun 19, 2014 at 04:49:47PM +0400, Anton Farygin wrote: > Да, понимаю что это вызов скрипта, но всё-таки - зачем, если можно и > без этого обойтись ? Это смотря кому можно обойтись. Майнтайнеру-одиночке, не подпускающего никого к своим пакетам, да, можно без этого обойтись. Но тем самым, не разглашая информацию о своих remotes, такой майнтайнер экономя секунду ввоего времени, забирает в сумме часы у других. > гуглим апстрим. > добавляем upstream remote Вот-вот. гуглим. 5 минут на репозиторий, 100+ репозиториев perl - только склонировать и проставить upstream remotе - это день работы. Поэтому эти репозитории так и стоят протухшие. Слишком затратно по времени с ними возиться. > Вот зачем мне в этом usecase информация о том, где и в каких ветках > Alexei Takaseev хранит апстримы и с чем делает мерж ? Никто же не заставляет ей пользоваться. Alexei Takaseev поделился этой информацией с сообществом, он выполнил свой долг, создав файл .gear/upstream/remotes. Если нет желания смотреть в этот файл, никто ж не мешает сесть и полчаса погуглить. В чем проблема поделиться с коллегами настройками своего репозитория, чтобы они не тратили свое время, пытаясь угадать и воспроизвести эти настройки? -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 14:24 ` Igor Vlasenko @ 2014-06-19 17:02 ` Anton Farygin 2014-06-19 18:20 ` Igor Vlasenko 0 siblings, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 17:02 UTC (permalink / raw) To: devel On 19.06.2014 18:24, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 04:49:47PM +0400, Anton Farygin wrote: >> Да, понимаю что это вызов скрипта, но всё-таки - зачем, если можно и >> без этого обойтись ? > > Это смотря кому можно обойтись. > > Майнтайнеру-одиночке, не подпускающего никого > к своим пакетам, да, можно без этого обойтись. > > Но тем самым, не разглашая информацию о своих remotes, > такой майнтайнер экономя секунду ввоего времени, > забирает в сумме часы у других. Игорь, я же говорю - remotes надо описывать в watch файле. Больше ничего не нужно. > >> гуглим апстрим. >> добавляем upstream remote > > Вот-вот. гуглим. 5 минут на репозиторий, 100+ репозиториев perl - > только склонировать и проставить upstream remotе - это > день работы. Поэтому эти репозитории так и стоят протухшие. > Слишком затратно по времени с ними возиться. > >> Вот зачем мне в этом usecase информация о том, где и в каких ветках >> Alexei Takaseev хранит апстримы и с чем делает мерж ? > > Никто же не заставляет ей пользоваться. > Alexei Takaseev поделился этой информацией с сообществом, > он выполнил свой долг, создав файл .gear/upstream/remotes. Зачем эта информация сообществу ? > > Если нет желания смотреть в этот файл, > никто ж не мешает сесть и полчаса погуглить. > > В чем проблема поделиться с коллегами настройками своего репозитория, > чтобы они не тратили свое время, пытаясь угадать и воспроизвести > эти настройки? В том, что remotes не нужны для публикации. Надо меня услышать: я предлагаю в watch файл писать адрес апстримного git репозитория. Этого достаточно для всего что хочется реализовать. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 17:02 ` Anton Farygin @ 2014-06-19 18:20 ` Igor Vlasenko 2014-06-19 18:35 ` Anton Farygin 2014-06-20 5:01 ` Eugene Prokopiev 0 siblings, 2 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 18:20 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin [-- Attachment #1: Type: text/plain, Size: 2715 bytes --] On Thu, Jun 19, 2014 at 09:02:06PM +0400, Anton Farygin wrote: > Игорь, я же говорю - remotes надо описывать в watch файле. На watch файлы в свое время было много нареканий, что сложный в освоении и запутанный формат. Основная причина, почему я взялся - это много тысяч готовых watch файлов, которые можно скопировать не читая из дистрибутивов, основанных на debian. git+gear -- alt специфический, там нет такой необходимости быть с чем-то совместимым. плюс специфика кода, я много усилий вложил в минимизацию diff с debian в участках кода, работающего с watch файлами, чтобы можно было бесконфликтно мержится с debian. Не хочется опять все ломать. Просто посмотрите на .gear/upstream/remotes, что это такой хитрый watch файл для git tags, а git-config -- это такой у него формат. Прилагаю к письму proof-of-concept скрипт, "watch для gear tags", test-tag-watch. пока поддерживает только стандартные теги v@version@ и @version@, для работы нужно скопировать секцию remote из .git/config в .gear/upstream/remotes. Проверьте у себя, пожалуйста. При запуске в корне gear репозитория должен выдать что-то вроде "Repository is up to date." > >он выполнил свой долг, создав файл .gear/upstream/remotes. > Зачем эта информация сообществу ? Меня тоже надо услышать. Мне лично и прямо сейчас такая информация уже нужна для пакетов perl-*. Я ведь не исключен из сообщества? А по закону больших чисел такая информация понадобится не раз и не два еще не одному десятку майнтайнеров. Да, у нас массовые обновления и исправления пакетов не очень распространены. Но не потому, что не нужны, а потому что требуется слишком много усилий из-за несовершенства инструментов. -- I V [-- Attachment #2: test-tag-watch --] [-- Type: text/plain, Size: 2023 bytes --] #!/usr/bin/perl use strict; use warnings; use RPM::uscan; my $pattern='v?([\d\.]*\d)'; my $pkg_dir='.'; my $debug=0; print 'remotes=', join("\n",get_remotes($pkg_dir)),"\n" if $debug; my @tags=get_tags(); @tags = map {$_->[0]} Devscripts::Versort::upstream_versort(map {[$_,$_]}@tags); print 'tags=', join(" ",@tags),"\n" if $debug; my (undef, $upackage, $uversion) = RPM::uscan::altlinux_guess_package_and_version($pkg_dir); my $version_cmp=Devscripts::Versort::myvercmp($uversion, $tags[0]); if ($version_cmp>1) { print "Oops! local repository ($uversion) is ahead of remote repository ($tags[0]).\n"; } elsif ($version_cmp==0) { print "repository is up to date.\n"; } else { print "New version $tags[0] is available.\n"; } sub get_tags { my @tags; foreach my $remote (&get_remotes($pkg_dir)) { foreach my $tag (&exec2array('git ls-remote --tags '.$remote)) { $tag=~s!^\S+\s+refs/tags/!!; $tag=~s!\^\{\}$!!; #print "testing: $tag\n"; push @tags, $1 if $tag=~/^$pattern$/; } } return @tags; } sub exec2array { my ($cmd)=@_; my @out; my $fn; open ($fn, "$cmd |") or die "$!: can't exec $cmd\n"; local $_; while (<$fn>) { chomp; push @out, $_; } close ($fn); #print 'out=', join(";",@out),"\n"; return @out; } sub get_remotes { my ($pkg_dir)=@_; my @remotes; die "can't find $pkg_dir/.gear/upstream/remotes\n" unless -r $pkg_dir.'/.gear/upstream/remotes'; my $fn; open ($fn, 'git config --file '.$pkg_dir.'/.gear/upstream/remotes --list|') or die "$!: can't open .gear/upstream/remotes\n"; local $_; while (<$fn>) { chomp; next unless /^remote\.([^\.]+)\.url=(\S+)/; my $remote=$1; #my $url=$2; push @remotes, $remote; } close ($fn); my %local_remotes=map{$_=>1} &exec2array('git remote'); foreach my $remote (@remotes) { die "Oops: remote $remote is present in .gear/upstream/remotes, but not in .git/config!\n" unless $local_remotes{$remote}; } return @remotes; } ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 18:20 ` Igor Vlasenko @ 2014-06-19 18:35 ` Anton Farygin 2014-06-19 18:52 ` Igor Vlasenko 2014-06-20 5:01 ` Eugene Prokopiev 1 sibling, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 18:35 UTC (permalink / raw) To: devel On 19.06.2014 22:20, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 09:02:06PM +0400, Anton Farygin wrote: >> Игорь, я же говорю - remotes надо описывать в watch файле. > > На watch файлы в свое время было много нареканий, что сложный в > освоении и запутанный формат. Основная причина, почему я взялся - > это много тысяч готовых watch файлов, которые можно скопировать > не читая из дистрибутивов, основанных на debian. > > git+gear -- alt специфический, там нет такой необходимости > быть с чем-то совместимым. плюс специфика кода, я много > усилий вложил в минимизацию diff с debian в участках кода, > работающего с watch файлами, чтобы можно было бесконфликтно > мержится с debian. Не хочется опять все ломать. не надо всё ломать, уверен, что можно легко определить git или не git в описании и для него вызвать другой обработчик. > > Просто посмотрите на .gear/upstream/remotes, что это такой > хитрый watch файл для git tags, а git-config -- это > такой у него формат. это иллюзия. Мало ли какие remotes я использую для разработки. Я ведь могу мержить свои репозитории и из своих гитов, которые тоже не каким образом не имеют отношения к публичности. Или вот пример: [remote "]jooQueiniweitahki4Boz3ai2zi8Bi"] url = git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git fetch = +refs/heads/*:refs/remotes/upstream/* [remote "rider"] url = git+ssh://git.alt/people/rider/packages/btrfs-progs.git fetch = +refs/heads/*:refs/remotes/rider/* [remote "vet7ahpheachiree7xiRae3xa7Vaiw"] url = git://repo.or.cz/btrfs-progs-unstable/devel.git fetch = +refs/heads/*:refs/remotes/upstream-devel/* легче станет сообществу ? > > Прилагаю к письму proof-of-concept скрипт, > "watch для gear tags", test-tag-watch. > > пока поддерживает только стандартные теги v@version@ и @version@, > для работы нужно скопировать секцию remote из .git/config > в .gear/upstream/remotes. а если таких секций цать ? > > Проверьте у себя, пожалуйста. При запуске в корне gear репозитория > должен выдать что-то вроде "Repository is up to date." > >>> он выполнил свой долг, создав файл .gear/upstream/remotes. >> Зачем эта информация сообществу ? > > Меня тоже надо услышать. Мне лично и прямо сейчас такая информация > уже нужна для пакетов perl-*. Я ведь не исключен из сообщества? Зачем ? Не понимаю, что даст то, что я назвал ветку askjdfaskdhauhkjhasd ? Вы действительно хотите увидеть мои названия веток ? может быть я их называю не совсем приличными словами, ибо в некоторых проектах приличными не получается. > А по закону больших чисел такая информация понадобится не раз и не > два еще не одному десятку майнтайнеров. Да, у нас массовые обновления > и исправления пакетов не очень распространены. Но не потому, что > не нужны, а потому что требуется слишком много усилий из-за > несовершенства инструментов. информация о локальных ветках в секции remotes никому не нужна. Нужна возможность мейнтейнеру указать, где и что искать в апстримном гите. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 18:35 ` Anton Farygin @ 2014-06-19 18:52 ` Igor Vlasenko 2014-06-19 19:08 ` Anton Farygin 0 siblings, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 18:52 UTC (permalink / raw) To: ALT Linux Team development discussions On Thu, Jun 19, 2014 at 10:35:27PM +0400, Anton Farygin wrote: > Я ведь могу мержить свои репозитории и из своих гитов, которые тоже > не каким образом не имеют отношения к публичности. Но ведь их не надо наблюдать? соответственно, не нужно их вносить в .gear/upstream/remotes. только то, что реально внешнее. > Или вот пример: > > [remote "]jooQueiniweitahki4Boz3ai2zi8Bi"] > url = > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > fetch = +refs/heads/*:refs/remotes/upstream/* > [remote "rider"] > url = git+ssh://git.alt/people/rider/packages/btrfs-progs.git > fetch = +refs/heads/*:refs/remotes/rider/* > [remote "vet7ahpheachiree7xiRae3xa7Vaiw"] > url = git://repo.or.cz/btrfs-progs-unstable/devel.git > fetch = +refs/heads/*:refs/remotes/upstream-devel/* > > легче станет сообществу ? (Облизываясь) Если бы perl-* - Мммм! btrfs-progs - еще не сталкивался. Но, думаю, хуже не стало. > >Прилагаю к письму proof-of-concept скрипт, > >"watch для gear tags", test-tag-watch. Как, получилось ли со скриптом test-tag-watch? Достаточно ли > >пока поддерживает только стандартные теги v@version@ и @version@, ? -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 18:52 ` Igor Vlasenko @ 2014-06-19 19:08 ` Anton Farygin 2014-06-19 19:46 ` Igor Vlasenko 0 siblings, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-19 19:08 UTC (permalink / raw) To: devel On 19.06.2014 22:52, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 10:35:27PM +0400, Anton Farygin wrote: >> Я ведь могу мержить свои репозитории и из своих гитов, которые тоже >> не каким образом не имеют отношения к публичности. > > Но ведь их не надо наблюдать? соответственно, не нужно их > вносить в .gear/upstream/remotes. только то, что реально > внешнее. > >> Или вот пример: >> >> [remote "]jooQueiniweitahki4Boz3ai2zi8Bi"] >> url = >> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git >> fetch = +refs/heads/*:refs/remotes/upstream/* >> [remote "rider"] >> url = git+ssh://git.alt/people/rider/packages/btrfs-progs.git >> fetch = +refs/heads/*:refs/remotes/rider/* >> [remote "vet7ahpheachiree7xiRae3xa7Vaiw"] >> url = git://repo.or.cz/btrfs-progs-unstable/devel.git >> fetch = +refs/heads/*:refs/remotes/upstream-devel/* >> >> легче станет сообществу ? > > (Облизываясь) Если бы perl-* - Мммм! > btrfs-progs - еще не сталкивался. Но, думаю, хуже не стало. т.е. - названия бранчей устраивают ? > > >>> Прилагаю к письму proof-of-concept скрипт, >>> "watch для gear tags", test-tag-watch. > > Как, получилось ли со скриптом test-tag-watch? конечно нет: $ ~/test-tag-watch can't find ./.gear/upstream/remotes откуда ж им взяться, если мне эта идея не нравится. поправил на .git/config: $ ~/test-tag-watch Use of uninitialized value $ver in substitution (s///) at /usr/share/perl5/RPM/uscan.pm line 1831. Use of uninitialized value $tags[0] in concatenation (.) or string at /home/rider/test-tag-watch line 23. New version is available. пакет php5 > > Достаточно ли >>> пока поддерживает только стандартные теги v@version@ и @version@, > ? нет, см. php5 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 19:08 ` Anton Farygin @ 2014-06-19 19:46 ` Igor Vlasenko 2014-06-19 19:50 ` Igor Vlasenko 2014-06-20 5:51 ` Anton Farygin 0 siblings, 2 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 19:46 UTC (permalink / raw) To: ALT Linux Team development discussions On Thu, Jun 19, 2014 at 11:08:17PM +0400, Anton Farygin wrote: > >Достаточно ли > >>>пока поддерживает только стандартные теги v@version@ и @version@, > >? > нет, см. php5 Пока не определился с форматом .gear/upstream/tag-filter, прикрепляю новый test-tag-watch, для php5 запускать как test-tag-watch --pattern 'php-([0-9\.]+)' когда станет ясно содержимое .gear/upstream/tag-filter, php-([0-9\.]+) можно будет вписать туда. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 19:46 ` Igor Vlasenko @ 2014-06-19 19:50 ` Igor Vlasenko 2014-06-20 5:51 ` Anton Farygin 1 sibling, 0 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-19 19:50 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin [-- Attachment #1: Type: text/plain, Size: 761 bytes --] On Thu, Jun 19, 2014 at 10:46:26PM +0300, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 11:08:17PM +0400, Anton Farygin wrote: > > >Достаточно ли > > >>>пока поддерживает только стандартные теги v@version@ и @version@, > > >? > > нет, см. php5 > > Пока не определился с форматом .gear/upstream/tag-filter, > прикрепляю новый test-tag-watch, для php5 запускать как > > test-tag-watch --pattern 'php-([0-9\.]+)' > > когда станет ясно содержимое .gear/upstream/tag-filter, > php-([0-9\.]+) можно будет вписать туда. забыл сам скрипт прикрепить - прикрепляю. -- I V [-- Attachment #2: test-tag-watch --] [-- Type: text/plain, Size: 2353 bytes --] #!/usr/bin/perl use strict; use warnings; use RPM::uscan; use Getopt::Long; my $pattern='v?([\d\.]*\d)'; my $pkg_dir='.'; my $debug=0; my ($verbose,$help); my $result = GetOptions ( 'verbose+' => \$verbose, 'q|quiet' => sub {$verbose=0}, 'h|help' => \$help, 'pattern=s' => \$pattern, ); $debug=1 if $verbose; print "pattern=$pattern\n" if $debug; print 'remotes=', join("\n",get_remotes($pkg_dir)),"\n" if $debug; my @tags=get_tags(); die "no tags found that match pattern $pattern\n" unless @tags; @tags = map {$_->[0]} Devscripts::Versort::upstream_versort(map {[$_,$_]}@tags); print 'tags=', join(" ",@tags),"\n" if $debug; my (undef, $upackage, $uversion) = RPM::uscan::altlinux_guess_package_and_version($pkg_dir); my $version_cmp=Devscripts::Versort::myvercmp($uversion, $tags[0]); if ($version_cmp>1) { print "Oops! local repository ($uversion) is ahead of remote repository ($tags[0]).\n"; } elsif ($version_cmp==0) { print "Repository is up to date.\n"; } else { print "New version $tags[0] is available.\n"; } sub get_tags { my @tags; foreach my $remote (&get_remotes($pkg_dir)) { foreach my $tag (&exec2array('git ls-remote --tags '.$remote)) { $tag=~s!^\S+\s+refs/tags/!!; $tag=~s!\^\{\}$!!; print "testing: $tag\n" if $debug; push @tags, $1 if $tag=~/^$pattern$/; } } return @tags; } sub exec2array { my ($cmd)=@_; my @out; my $fn; open ($fn, "$cmd |") or die "$!: can't exec $cmd\n"; local $_; while (<$fn>) { chomp; push @out, $_; } close ($fn); #print 'out=', join(";",@out),"\n"; return @out; } sub get_remotes { my ($pkg_dir)=@_; my @remotes; die "can't find $pkg_dir/.gear/upstream/remotes\n" unless -r $pkg_dir.'/.gear/upstream/remotes'; my $fn; open ($fn, 'git config --file '.$pkg_dir.'/.gear/upstream/remotes --list|') or die "$!: can't open .gear/upstream/remotes\n"; local $_; while (<$fn>) { chomp; next unless /^remote\.([^\.]+)\.url=(\S+)/; my $remote=$1; #my $url=$2; push @remotes, $remote; } close ($fn); my %local_remotes=map{$_=>1} &exec2array('git remote'); foreach my $remote (@remotes) { die "Oops: remote $remote is present in .gear/upstream/remotes, but not in .git/config!\n" unless $local_remotes{$remote}; } return @remotes; } ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 19:46 ` Igor Vlasenko 2014-06-19 19:50 ` Igor Vlasenko @ 2014-06-20 5:51 ` Anton Farygin 2014-06-20 12:23 ` Igor Vlasenko 1 sibling, 1 reply; 34+ messages in thread From: Anton Farygin @ 2014-06-20 5:51 UTC (permalink / raw) To: devel On 19.06.2014 23:46, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 11:08:17PM +0400, Anton Farygin wrote: >>> Достаточно ли >>>>> пока поддерживает только стандартные теги v@version@ и @version@, >>> ? >> нет, см. php5 > > Пока не определился с форматом .gear/upstream/tag-filter, > прикрепляю новый test-tag-watch, для php5 запускать как > > test-tag-watch --pattern 'php-([0-9\.]+)' > > когда станет ясно содержимое .gear/upstream/tag-filter, > php-([0-9\.]+) можно будет вписать туда. > > более сложный пример - пакет curl апстрим:git://github.com/bagder/curl.git мне кажется, что формат watch файлов всё-таки не просто-так стал таким сложным. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-20 5:51 ` Anton Farygin @ 2014-06-20 12:23 ` Igor Vlasenko 0 siblings, 0 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-20 12:23 UTC (permalink / raw) To: ALT Linux Team development discussions On Fri, Jun 20, 2014 at 09:51:00AM +0400, Anton Farygin wrote: > мне кажется, что формат watch файлов всё-таки не просто-так стал > таким сложным. с тегами там 2 задачи - отфильтровать нужные и потом преобразовать их к виду, пригодному для вставки в тег rpm Version:. Это типичная задача-однострочник на sed, awk, perl. Я вот думаю, а зачем вообще изобретать формат. в случае нестандартных тегов майнтайнер создает скрипты .gear/upstream/tag-filter, .gear/upstream/tag-mangle, например, для php - grep /^php-[0-9\.]*$/ и sed -e 's,php-,,' а скрипт скармливает им все теги через pipe и берет с выхода уже отфильтрованные и преобразованные. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-19 18:20 ` Igor Vlasenko 2014-06-19 18:35 ` Anton Farygin @ 2014-06-20 5:01 ` Eugene Prokopiev 2014-06-20 12:11 ` Igor Vlasenko 1 sibling, 1 reply; 34+ messages in thread From: Eugene Prokopiev @ 2014-06-20 5:01 UTC (permalink / raw) To: ALT Linux Team development discussions; +Cc: Anton Farygin 19 июня 2014 г., 22:20 Igor Vlasenko написал: > Меня тоже надо услышать. Мне лично и прямо сейчас такая информация > уже нужна для пакетов perl-*. Я ведь не исключен из сообщества? > А по закону больших чисел такая информация понадобится не раз и не > два еще не одному десятку майнтайнеров. Да, у нас массовые обновления > и исправления пакетов не очень распространены. Но не потому, что > не нужны, а потому что требуется слишком много усилий из-за > несовершенства инструментов. Игорь, можно еще раз? Мне тоже кажется, что чем меньше дополнительной информации в разных местах хранить, тем более чистой и удобной становится сама концепция :) Т.е. раз мы уже используем watch-файлы, то логично в них же хранить ссылку на внешнюю VCS + регэксп для релизных тегов. Тогда для облегчения работы мы могли бы сказать: $ gear-restore-remotes (один раз сразу после git clone для извлечения remotes - но тут нужно дать капризным майнтейнерам возможность задавать имя remotes) $ git remotes fetch $ gear-watch (посмотреть глазами, есть ли новые теги?) $ girar-update-by-upstream-tag (мержит апстримный тег, правит спек, коммитит, может даже ставит теги для сизифа и бранчей) $ gear-hsh ... (собираем теги для сизифа и бранчей) Имена новых утилит, естественно, условные ... По дефолту, наверное, стоит ставить теги и собирать только для сизифа, а в случае присутствия specsubst также и для бранчей (указанных в каком-то специального вида комментарии в спеке, например). Все эти команды я могу дать вручную, а могу и роботу поручить, если пакетов куча. Зачем здесь апстримные бранчи? Можно ведь таким образом собирать те же starman и perl-Mojolicious непосредственно по тегам? И netxms можно было бы. Есть другой вопрос: бывает нужно собирать не апстримные, а собственные теги. Или вот я сам собираю себе freeswitch, т.к. не нашел общего языка с майнтейнером - http://git.altlinux.org/people/enp/packages/freeswitch.git. Мержить можно было бы и апстримные теги, но еще мне нужно вычислять разницу между бранчами upstream/v1.2.stable и patch/ldap - http://git.altlinux.org/people/enp/packages/freeswitch.git?p=freeswitch.git;a=blob;f=.gear/rules;h=a4a4163b4b0ed5bf439d2603c21431edd0466635;hb=f5d4ebe340bcb69df0076a9fa2f28aba5cf45231. Где хранить информацию об этом - тоже в watch-файле? -- WBR, Eugene Prokopiev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-20 5:01 ` Eugene Prokopiev @ 2014-06-20 12:11 ` Igor Vlasenko 2014-06-20 12:20 ` Eugene Prokopiev 0 siblings, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-20 12:11 UTC (permalink / raw) To: ALT Linux Team development discussions Я плохо прошлый раз объяснил, только всех запутал:( Как говорится, чтобы правильно задать вопрос, нужно знать 50% ответа. Вместо этого я завел слушателей во что-то не то. Коротко скажу, что > Зачем здесь апстримные бранчи? и не зачем, и не при чем, и только запутал слушателей и ввел их в заблуждение. У мнея смешались в кучу кони, люди, NMU, наблюдение за тегами и автообновление. Не удивительно, что я всех запутал. Прошу тайм-аут. Возможно, стоит сейчас отложить написание кода, это сейчас менее приоритетная задача, пусть время устаканит концепцию. On Fri, Jun 20, 2014 at 09:01:10AM +0400, Eugene Prokopiev wrote: > 19 июня 2014 г., 22:20 Igor Vlasenko написал: > > > Меня тоже надо услышать. Мне лично и прямо сейчас такая информация > > уже нужна для пакетов perl-*. Я ведь не исключен из сообщества? > > А по закону больших чисел такая информация понадобится не раз и не > > два еще не одному десятку майнтайнеров. Да, у нас массовые обновления > > и исправления пакетов не очень распространены. Но не потому, что > > не нужны, а потому что требуется слишком много усилий из-за > > несовершенства инструментов. > > Игорь, можно еще раз? Мне тоже кажется, что чем меньше дополнительной > информации в разных местах хранить, тем более чистой и удобной > становится сама концепция :) Т.е. раз мы уже используем watch-файлы, > то логично в них же хранить ссылку на внешнюю VCS + регэксп для > релизных тегов. Тогда для облегчения работы мы могли бы сказать: > > $ gear-restore-remotes (один раз сразу после git clone для извлечения > remotes - но тут нужно дать капризным майнтейнерам возможность > задавать имя remotes) > $ git remotes fetch > $ gear-watch (посмотреть глазами, есть ли новые теги?) > $ girar-update-by-upstream-tag (мержит апстримный тег, правит спек, > коммитит, может даже ставит теги для сизифа и бранчей) > $ gear-hsh ... (собираем теги для сизифа и бранчей) > > Имена новых утилит, естественно, условные ... > > По дефолту, наверное, стоит ставить теги и собирать только для сизифа, > а в случае присутствия specsubst также и для бранчей (указанных в > каком-то специального вида комментарии в спеке, например). > > Все эти команды я могу дать вручную, а могу и роботу поручить, если > пакетов куча. > > Зачем здесь апстримные бранчи? Можно ведь таким образом собирать те же > starman и perl-Mojolicious непосредственно по тегам? И netxms можно > было бы. > > Есть другой вопрос: бывает нужно собирать не апстримные, а собственные > теги. Или вот я сам собираю себе freeswitch, т.к. не нашел общего > языка с майнтейнером - > http://git.altlinux.org/people/enp/packages/freeswitch.git. Мержить > можно было бы и апстримные теги, но еще мне нужно вычислять разницу > между бранчами upstream/v1.2.stable и patch/ldap - > http://git.altlinux.org/people/enp/packages/freeswitch.git?p=freeswitch.git;a=blob;f=.gear/rules;h=a4a4163b4b0ed5bf439d2603c21431edd0466635;hb=f5d4ebe340bcb69df0076a9fa2f28aba5cf45231. > Где хранить информацию об этом - тоже в watch-файле? > > -- > WBR, > Eugene Prokopiev > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Gear и внешние VCS. 2014-06-20 12:11 ` Igor Vlasenko @ 2014-06-20 12:20 ` Eugene Prokopiev 0 siblings, 0 replies; 34+ messages in thread From: Eugene Prokopiev @ 2014-06-20 12:20 UTC (permalink / raw) To: ALT Linux Team development discussions 20 июня 2014 г., 16:11 Igor Vlasenko написал: > Не удивительно, что я всех запутал. > Прошу тайм-аут. > > Возможно, стоит сейчас отложить написание кода, > это сейчас менее приоритетная задача, > пусть время устаканит концепцию. Конечно, но нужно бросать - это очень важное и полезное дело -- WBR, Eugene Prokopiev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-17 19:42 [devel] Q: редкие примеры .gear/rules ? Igor Vlasenko 2014-06-18 4:45 ` Eugene Prokopiev @ 2014-06-18 6:14 ` Anton Farygin 2014-06-18 10:30 ` Dmitry V. Levin 2014-06-18 18:30 ` Igor Vlasenko 2014-06-18 9:50 ` Anton V. Boyarshinov 2014-06-18 10:53 ` Sergey V Turchin 3 siblings, 2 replies; 34+ messages in thread From: Anton Farygin @ 2014-06-18 6:14 UTC (permalink / raw) To: devel On 17.06.2014 23:42, Igor Vlasenko wrote: > Господа, > > не знает ли кто-нибудь примеров gear репозиториев > > 1) вне kernel-modules-*, в которых в .gear/rules > используется директива specsubst: ? > насколько я знаю - нигде. А почему-бы кому-то не грепнуть на git.alt ? наверняка там где-то есть склонированные копии всех репозиториев. > 2) в которых в .gear/rules > в директивах tar*: diff*: используется опция spec=<альтернативный.spec> а это реально где-то используется ? я даже и не знал о такой возможности ;) > > потестировать, как с такими репозиториями будет > работать библиотечка perl-Gear-Rules. > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 6:14 ` [devel] Q: редкие примеры .gear/rules ? Anton Farygin @ 2014-06-18 10:30 ` Dmitry V. Levin 2014-06-18 17:54 ` Igor Vlasenko 2014-06-18 18:30 ` Igor Vlasenko 1 sibling, 1 reply; 34+ messages in thread From: Dmitry V. Levin @ 2014-06-18 10:30 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 4365 bytes --] Hi, On Wed, Jun 18, 2014 at 10:14:54AM +0400, Anton Farygin wrote: > On 17.06.2014 23:42, Igor Vlasenko wrote: > > > >не знает ли кто-нибудь примеров gear > >репозиториев > > > >1) вне kernel-modules-*, в которых в .gear/rules > >используется директива specsubst: ? > > насколько я знаю - нигде. А почему-бы > кому-то не грепнуть на git.alt ? наверняка > там где-то есть склонированные копии > всех репозиториев. А почему бы, действительно, было не грепнуть? Тем более, что любой из вас мог бы грепнуть. $ for c in /gears/?; do for d in "$c"/*.git; do (git --git-dir="$d" cat-file blob sisyphus:.gear/rules || git --git-dir="$d" cat-file blob sisyphus:.gear-rules) 2>/dev/null | grep -q 'specsubst[[:space:]]*:' && echo "$d"; done; done /gears/b/blender.git /gears/k/kernel-image-led-vs.git /gears/k/kernel-image-led-ws.git /gears/k/kernel-image-led-xen.git /gears/k/kernel-image-std-def.git /gears/k/kernel-image-std-pae.git /gears/k/kernel-image-un-def.git /gears/k/kernel-modules-accel-ppp-std-def.git /gears/k/kernel-modules-acpi_call-std-def.git /gears/k/kernel-modules-acpi_call-std-pae.git /gears/k/kernel-modules-acpi_call-un-def.git /gears/k/kernel-modules-alx-std-def.git /gears/k/kernel-modules-alx-std-pae.git /gears/k/kernel-modules-bbswitch-std-def.git /gears/k/kernel-modules-bbswitch-std-pae.git /gears/k/kernel-modules-bbswitch-un-def.git /gears/k/kernel-modules-bcmwl-std-def.git /gears/k/kernel-modules-bcmwl-std-pae.git /gears/k/kernel-modules-bcmwl-un-def.git /gears/k/kernel-modules-dahdi-ovz-el.git /gears/k/kernel-modules-dahdi-std-def.git /gears/k/kernel-modules-dahdi-std-pae.git /gears/k/kernel-modules-drbd-el-def.git /gears/k/kernel-modules-emlog-std-def.git /gears/k/kernel-modules-emlog-std-pae.git /gears/k/kernel-modules-emlog-un-def.git /gears/k/kernel-modules-fglrx-el-def.git /gears/k/kernel-modules-fglrx-ovz-el.git /gears/k/kernel-modules-fglrx-std-def.git /gears/k/kernel-modules-fglrx-std-pae.git /gears/k/kernel-modules-fglrx-un-def.git /gears/k/kernel-modules-ipset-std-def.git /gears/k/kernel-modules-ipset-std-pae.git /gears/k/kernel-modules-ipset-un-def.git /gears/k/kernel-modules-ipt_netflow-std-def.git /gears/k/kernel-modules-ipt_netflow-std-pae.git /gears/k/kernel-modules-ipt_netflow-un-def.git /gears/k/kernel-modules-knem-el-def.git /gears/k/kernel-modules-lsadrv-std-def.git /gears/k/kernel-modules-lsadrv-std-pae.git /gears/k/kernel-modules-lsadrv-un-def.git /gears/k/kernel-modules-nvidia-el-def.git /gears/k/kernel-modules-nvidia-hpc-skif.git /gears/k/kernel-modules-nvidia-led-vs.git /gears/k/kernel-modules-nvidia-led-ws.git /gears/k/kernel-modules-nvidia-ovz-el.git /gears/k/kernel-modules-nvidia-std-def.git /gears/k/kernel-modules-nvidia-std-pae.git /gears/k/kernel-modules-nvidia-un-def.git /gears/k/kernel-modules-omnibook-ovz-el.git /gears/k/kernel-modules-omnibook-std-def.git /gears/k/kernel-modules-omnibook-std-pae.git /gears/k/kernel-modules-pf_ring-ovz-el.git /gears/k/kernel-modules-r8168-std-def.git /gears/k/kernel-modules-r8168-std-pae.git /gears/k/kernel-modules-r8168-un-def.git /gears/k/kernel-modules-tp_smapi-ovz-el.git /gears/k/kernel-modules-tp_smapi-std-def.git /gears/k/kernel-modules-tp_smapi-std-pae.git /gears/k/kernel-modules-tp_smapi-un-def.git /gears/k/kernel-modules-vhba-std-def.git /gears/k/kernel-modules-vhba-std-pae.git /gears/k/kernel-modules-vhba-un-def.git /gears/k/kernel-modules-virtualbox-addition-ovz-el.git /gears/k/kernel-modules-virtualbox-addition-std-def.git /gears/k/kernel-modules-virtualbox-addition-std-pae.git /gears/k/kernel-modules-virtualbox-addition-un-def.git /gears/k/kernel-modules-virtualbox-ovz-el.git /gears/k/kernel-modules-virtualbox-std-def.git /gears/k/kernel-modules-virtualbox-std-pae.git /gears/k/kernel-modules-virtualbox-un-def.git /gears/k/kernel-modules-xtables-addons-std-def.git /gears/k/kernel-modules-zfs-el-def.git /gears/n/netxms.git /gears/p/python-module-enchant.git /gears/p/python3-module-enchant.git > >2) в которых в .gear/rules > >в директивах tar*: diff*: используется опция > >spec=<альтернативный.spec> > > а это реально где-то используется ? я даже > и не знал о такой возможности ;) В Сизифе примеров использования не нашлось. Видимо, осталось невостребованным, или не прижилось. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 10:30 ` Dmitry V. Levin @ 2014-06-18 17:54 ` Igor Vlasenko 0 siblings, 0 replies; 34+ messages in thread From: Igor Vlasenko @ 2014-06-18 17:54 UTC (permalink / raw) To: ALT Linux Team development discussions Замечательно, спасибо большое! On Wed, Jun 18, 2014 at 02:30:23PM +0400, Dmitry V. Levin wrote: > Hi, > > On Wed, Jun 18, 2014 at 10:14:54AM +0400, Anton Farygin wrote: > > On 17.06.2014 23:42, Igor Vlasenko wrote: > > > > > >не знает ли кто-нибудь примеров gear > > >репозиториев > > > > > >1) вне kernel-modules-*, в которых в .gear/rules > > >используется директива specsubst: ? > > > > насколько я знаю - нигде. А почему-бы > > кому-то не грепнуть на git.alt ? наверняка > > там где-то есть склонированные копии > > всех репозиториев. > > А почему бы, действительно, было не грепнуть? > Тем более, что любой из вас мог бы грепнуть. > > $ for c in /gears/?; do for d in "$c"/*.git; do (git --git-dir="$d" cat-file blob sisyphus:.gear/rules || git --git-dir="$d" cat-file blob sisyphus:.gear-rules) 2>/dev/null | grep -q 'specsubst[[:space:]]*:' && echo "$d"; done; done > /gears/b/blender.git > /gears/k/kernel-image-led-vs.git > /gears/k/kernel-image-led-ws.git > /gears/k/kernel-image-led-xen.git > /gears/k/kernel-image-std-def.git > /gears/k/kernel-image-std-pae.git > /gears/k/kernel-image-un-def.git > /gears/k/kernel-modules-accel-ppp-std-def.git > /gears/k/kernel-modules-acpi_call-std-def.git > /gears/k/kernel-modules-acpi_call-std-pae.git > /gears/k/kernel-modules-acpi_call-un-def.git > /gears/k/kernel-modules-alx-std-def.git > /gears/k/kernel-modules-alx-std-pae.git > /gears/k/kernel-modules-bbswitch-std-def.git > /gears/k/kernel-modules-bbswitch-std-pae.git > /gears/k/kernel-modules-bbswitch-un-def.git > /gears/k/kernel-modules-bcmwl-std-def.git > /gears/k/kernel-modules-bcmwl-std-pae.git > /gears/k/kernel-modules-bcmwl-un-def.git > /gears/k/kernel-modules-dahdi-ovz-el.git > /gears/k/kernel-modules-dahdi-std-def.git > /gears/k/kernel-modules-dahdi-std-pae.git > /gears/k/kernel-modules-drbd-el-def.git > /gears/k/kernel-modules-emlog-std-def.git > /gears/k/kernel-modules-emlog-std-pae.git > /gears/k/kernel-modules-emlog-un-def.git > /gears/k/kernel-modules-fglrx-el-def.git > /gears/k/kernel-modules-fglrx-ovz-el.git > /gears/k/kernel-modules-fglrx-std-def.git > /gears/k/kernel-modules-fglrx-std-pae.git > /gears/k/kernel-modules-fglrx-un-def.git > /gears/k/kernel-modules-ipset-std-def.git > /gears/k/kernel-modules-ipset-std-pae.git > /gears/k/kernel-modules-ipset-un-def.git > /gears/k/kernel-modules-ipt_netflow-std-def.git > /gears/k/kernel-modules-ipt_netflow-std-pae.git > /gears/k/kernel-modules-ipt_netflow-un-def.git > /gears/k/kernel-modules-knem-el-def.git > /gears/k/kernel-modules-lsadrv-std-def.git > /gears/k/kernel-modules-lsadrv-std-pae.git > /gears/k/kernel-modules-lsadrv-un-def.git > /gears/k/kernel-modules-nvidia-el-def.git > /gears/k/kernel-modules-nvidia-hpc-skif.git > /gears/k/kernel-modules-nvidia-led-vs.git > /gears/k/kernel-modules-nvidia-led-ws.git > /gears/k/kernel-modules-nvidia-ovz-el.git > /gears/k/kernel-modules-nvidia-std-def.git > /gears/k/kernel-modules-nvidia-std-pae.git > /gears/k/kernel-modules-nvidia-un-def.git > /gears/k/kernel-modules-omnibook-ovz-el.git > /gears/k/kernel-modules-omnibook-std-def.git > /gears/k/kernel-modules-omnibook-std-pae.git > /gears/k/kernel-modules-pf_ring-ovz-el.git > /gears/k/kernel-modules-r8168-std-def.git > /gears/k/kernel-modules-r8168-std-pae.git > /gears/k/kernel-modules-r8168-un-def.git > /gears/k/kernel-modules-tp_smapi-ovz-el.git > /gears/k/kernel-modules-tp_smapi-std-def.git > /gears/k/kernel-modules-tp_smapi-std-pae.git > /gears/k/kernel-modules-tp_smapi-un-def.git > /gears/k/kernel-modules-vhba-std-def.git > /gears/k/kernel-modules-vhba-std-pae.git > /gears/k/kernel-modules-vhba-un-def.git > /gears/k/kernel-modules-virtualbox-addition-ovz-el.git > /gears/k/kernel-modules-virtualbox-addition-std-def.git > /gears/k/kernel-modules-virtualbox-addition-std-pae.git > /gears/k/kernel-modules-virtualbox-addition-un-def.git > /gears/k/kernel-modules-virtualbox-ovz-el.git > /gears/k/kernel-modules-virtualbox-std-def.git > /gears/k/kernel-modules-virtualbox-std-pae.git > /gears/k/kernel-modules-virtualbox-un-def.git > /gears/k/kernel-modules-xtables-addons-std-def.git > /gears/k/kernel-modules-zfs-el-def.git > /gears/n/netxms.git > /gears/p/python-module-enchant.git > /gears/p/python3-module-enchant.git > > > >2) в которых в .gear/rules > > >в директивах tar*: diff*: используется опция > > >spec=<альтернативный.spec> > > > > а это реально где-то используется ? я даже > > и не знал о такой возможности ;) > > В Сизифе примеров использования не нашлось. > Видимо, осталось невостребованным, или не прижилось. > > > -- > ldv > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 6:14 ` [devel] Q: редкие примеры .gear/rules ? Anton Farygin 2014-06-18 10:30 ` Dmitry V. Levin @ 2014-06-18 18:30 ` Igor Vlasenko 2014-06-18 18:40 ` Pavel Vainerman 1 sibling, 1 reply; 34+ messages in thread From: Igor Vlasenko @ 2014-06-18 18:30 UTC (permalink / raw) To: ALT Linux Team development discussions On Wed, Jun 18, 2014 at 10:14:54AM +0400, Anton Farygin wrote: > On 17.06.2014 23:42, Igor Vlasenko wrote: > >Господа, > > > >не знает ли кто-нибудь примеров gear репозиториев > >2) в которых в .gear/rules > >в директивах tar*: diff*: используется опция spec=<альтернативный.spec> > > а это реально где-то используется ? я даже и не знал о такой возможности ;) описано в man gear-rules Valid options are: [...] spec=path_to_file Use another file instead of the main spec file to define keyword values. Но, похоже, эту опцию действительно никто не использует. -- I V ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 18:30 ` Igor Vlasenko @ 2014-06-18 18:40 ` Pavel Vainerman 2014-06-18 19:08 ` Anton Farygin 0 siblings, 1 reply; 34+ messages in thread From: Pavel Vainerman @ 2014-06-18 18:40 UTC (permalink / raw) To: ALT Linux Team development discussions > описано в man gear-rules > Valid options are: > [...] > spec=path_to_file > > Use another file instead of the main spec file to define > keyword values. > > Но, похоже, эту опцию действительно никто не использует. У себя во "внутренних" проектах мы используем.. (когда spec лежит не в корне проекта, а в подкаталоге) -- Pavel Vainerman www.etersoft.ru ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-18 18:40 ` Pavel Vainerman @ 2014-06-18 19:08 ` Anton Farygin 0 siblings, 0 replies; 34+ messages in thread From: Anton Farygin @ 2014-06-18 19:08 UTC (permalink / raw) To: devel On 18.06.2014 22:40, Pavel Vainerman wrote: >> описано в man gear-rules >> Valid options are: >> [...] >> spec=path_to_file >> >> Use another file instead of the main spec file to define >> keyword values. >> >> Но, похоже, эту опцию действительно никто не использует. > > У себя во "внутренних" проектах мы используем.. > (когда spec лежит не в корне проекта, а в подкаталоге) Это не то. Спек в .gear/ и я частенько держу. Здесь речь идёт о том, что есть возможность для некоторых директив в gear/rules указывать другой спек. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-17 19:42 [devel] Q: редкие примеры .gear/rules ? Igor Vlasenko 2014-06-18 4:45 ` Eugene Prokopiev 2014-06-18 6:14 ` [devel] Q: редкие примеры .gear/rules ? Anton Farygin @ 2014-06-18 9:50 ` Anton V. Boyarshinov 2014-06-18 10:53 ` Sergey V Turchin 3 siblings, 0 replies; 34+ messages in thread From: Anton V. Boyarshinov @ 2014-06-18 9:50 UTC (permalink / raw) To: Igor Vlasenko; +Cc: devel On Tue, 17 Jun 2014 22:42:00 +0300 Igor Vlasenko wrote: > 1) вне kernel-modules-*, в которых в .gear/rules > используется директива specsubst: ? kernel-image-{std,un}-{def,pae} ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [devel] Q: редкие примеры .gear/rules ? 2014-06-17 19:42 [devel] Q: редкие примеры .gear/rules ? Igor Vlasenko ` (2 preceding siblings ...) 2014-06-18 9:50 ` Anton V. Boyarshinov @ 2014-06-18 10:53 ` Sergey V Turchin 3 siblings, 0 replies; 34+ messages in thread From: Sergey V Turchin @ 2014-06-18 10:53 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 451 bytes --] On Tuesday 17 June 2014 22:42:00 Igor Vlasenko wrote: > Господа, > > не знает ли кто-нибудь примеров gear репозиториев > > 1) вне kernel-modules-*, в которых в .gear/rules > используется директива specsubst: ? Когда http://bugzilla.altlinux.org/29822 , наверняка станет много. [...] -- Regards, Sergey. ALT Linux, http://www.altlinux.ru/ [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-06-20 12:23 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-17 19:42 [devel] Q: редкие примеры .gear/rules ? Igor Vlasenko 2014-06-18 4:45 ` Eugene Prokopiev 2014-06-18 17:53 ` Igor Vlasenko 2014-06-19 7:52 ` Igor Vlasenko 2014-06-19 8:00 ` Eugene Prokopiev 2014-06-19 11:08 ` [devel] Gear и внешние VCS Igor Vlasenko 2014-06-19 11:10 ` Anton Farygin 2014-06-19 11:55 ` Igor Vlasenko 2014-06-19 12:10 ` Anton Farygin 2014-06-19 12:17 ` Igor Vlasenko 2014-06-19 12:49 ` Anton Farygin 2014-06-19 13:09 ` Anton Farygin 2014-06-19 14:38 ` Igor Vlasenko 2014-06-19 14:24 ` Igor Vlasenko 2014-06-19 17:02 ` Anton Farygin 2014-06-19 18:20 ` Igor Vlasenko 2014-06-19 18:35 ` Anton Farygin 2014-06-19 18:52 ` Igor Vlasenko 2014-06-19 19:08 ` Anton Farygin 2014-06-19 19:46 ` Igor Vlasenko 2014-06-19 19:50 ` Igor Vlasenko 2014-06-20 5:51 ` Anton Farygin 2014-06-20 12:23 ` Igor Vlasenko 2014-06-20 5:01 ` Eugene Prokopiev 2014-06-20 12:11 ` Igor Vlasenko 2014-06-20 12:20 ` Eugene Prokopiev 2014-06-18 6:14 ` [devel] Q: редкие примеры .gear/rules ? Anton Farygin 2014-06-18 10:30 ` Dmitry V. Levin 2014-06-18 17:54 ` Igor Vlasenko 2014-06-18 18:30 ` Igor Vlasenko 2014-06-18 18:40 ` Pavel Vainerman 2014-06-18 19:08 ` Anton Farygin 2014-06-18 9:50 ` Anton V. Boyarshinov 2014-06-18 10:53 ` Sergey V Turchin
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git