[devel] Q: редкие примеры .gear/rules ?

[devel] Q: редкие примеры .gear/rules ?

[Igor Vlasenko]

Господа,

не знает ли кто-нибудь примеров gear репозиториев

1) вне kernel-modules-*, в которых в .gear/rules
используется директива specsubst: ?

2) в которых в .gear/rules
в директивах tar*: diff*: используется опция spec=<альтернативный.spec>

потестировать, как с такими репозиториями будет
работать библиотечка perl-Gear-Rules.

-- 

I V

Re: [devel] Q: редкие примеры .gear/rules ?

[Eugene Prokopiev]

17 июня 2014 г., 23:42 Igor Vlasenko написал:

> 1) вне kernel-modules-*, в которых в .gear/rules
> используется директива specsubst: ?

http://git.altlinux.org/people/enp/packages/netxms.git

обновлять его роботом (только для Сизифа) было бы очень интересно

-- 
WBR,
Eugene Prokopiev

Re: [devel] Q: редкие примеры .gear/rules ?

[Anton Farygin]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Anton V. Boyarshinov]

On Tue, 17 Jun 2014 22:42:00 +0300 Igor Vlasenko wrote:

> 1) вне kernel-modules-*, в которых в .gear/rules
> используется директива specsubst: ?
kernel-image-{std,un}-{def,pae}

Re: [devel] Q: редкие примеры .gear/rules ?

[Dmitry V. Levin]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Sergey V Turchin]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Igor Vlasenko]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Igor Vlasenko]

Замечательно, спасибо большое!

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Igor Vlasenko]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Pavel Vainerman]

> описано в 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

Re: [devel] Q: редкие примеры .gear/rules ?

[Anton Farygin]

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 указывать другой спек.

Re: [devel] Q: редкие примеры .gear/rules ?

[Igor Vlasenko]

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

Re: [devel] Q: редкие примеры .gear/rules ?

[Eugene Prokopiev]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

На примере 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

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

On 19.06.2014 15:08, Igor Vlasenko wrote:
> Соответственно, когда такие утилиты будут готовы,
> надо будет просить всех майнтайнеров, использующих
> VCS - обновляемые gear репозитории, создать и опубликовать
> в этих репозиториях .gear/upstream/remotes,
> а если есть желание ограничить доступ к своему репозиторию,
> то делать это с помощью acl, а не сокрытием его служебной
> информации.

я в соседнем письме написал, почему нет смысла использовать для этого 
.gear/upstream/remotes

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

например, мне привычнее upstream remote держать в бранче не upstream, а 
source.

Как тут быть ?

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

On Thu, Jun 19, 2014 at 04:10:14PM +0400, Anton Farygin wrote:
> >Но из этого совершенно не следует, что если пакет foo
> >одновременно сопровождает 2 майнтайнера A и B, то
> >если один из них создал .gear/upstream/remotes,
> >(например, А), то второй (В)
> >отгребет из этого файла не нужные ему ветви.
> 
> следует что каждому мейнтейнеру для каждого своего пакета придётся
> делать действия, которых можно было бы избежать.

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

Можно на примере? какие придется делать действия?

-- 

I V

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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

Да, понимаю что это вызов скрипта, но всё-таки - зачем, если можно и без 
этого обойтись ?

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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 хранит апстримы и с чем делает мерж ?

Вся недостающая информация - это адрес апстримного гита и формат тэга, 
который описывает релиз.

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

On Thu, Jun 19, 2014 at 05:09:26PM +0400, Anton Farygin wrote:
> Вот зачем мне в этом usecase информация о том, где и в каких ветках
> Alexei Takaseev хранит апстримы и с чем делает мерж ?
> 
> Вся недостающая информация - это адрес апстримного гита и формат
> тэга, который описывает релиз.

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

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

-- 

I V

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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 никому не нужна.

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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

Re: [devel] Gear и внешние VCS.

[Eugene Prokopiev]

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

Re: [devel] Gear и внешние VCS.

[Anton Farygin]

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 файлов всё-таки не просто-так стал таким 
сложным.

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

Я плохо прошлый раз объяснил, только всех запутал:(

Как говорится, чтобы правильно задать вопрос, нужно знать
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

Re: [devel] Gear и внешние VCS.

[Eugene Prokopiev]

20 июня 2014 г., 16:11 Igor Vlasenko написал:

> Не удивительно, что я всех запутал.
> Прошу тайм-аут.
>
> Возможно, стоит сейчас отложить написание кода,
> это сейчас менее приоритетная задача,
> пусть время устаканит концепцию.

Конечно, но нужно бросать - это очень важное и полезное дело

-- 
WBR,
Eugene Prokopiev

Re: [devel] Gear и внешние VCS.

[Igor Vlasenko]

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