[devel] procps.git

[devel] procps.git

[Alexey Tourbin]

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

И чо, я сделал патч к procps, куда его теперь коммитить?
В /people/ldv/packages/procps.git писать не дают, а куда тогда?

$ git-push --all git.alt:/people/ldv/packages/procps.git
updating 'refs/heads/master'
  from 25366cd4b1691a887e135a58ab894dff6cbae560
  to   64ef9663bc217c76ee80007a8cda189a3c7e6919
updating 'refs/heads/origin'
  from 0000000000000000000000000000000000000000
  to   25366cd4b1691a887e135a58ab894dff6cbae560
Generating pack...
Done counting 7 objects.
Result has 4 objects.
Deltifying 4 objects.
 100% (4/4) done
Total 4, written 4 (delta 3), reused 0 (delta 0)
Unpacking 4 objects
unable to create temporary sha1 filename ./objects/obj_aObEAo: Permission denied
fatal: failed to write object
unpack unpacker exited with error code
ng refs/heads/master n/a (unpacker error)
ng refs/heads/origin n/a (unpacker error)
$ git-log -p --max-count=1
commit 64ef9663bc217c76ee80007a8cda189a3c7e6919
Author: Alexey Tourbin <at@localhost.localdomain>
Date:   Thu Sep 14 04:42:46 2006 +0400

    Implement the following behaviour:
    
    1) execute a program also when a key is pressed;
    2) but if that key is 'q' then exit instead.
    
    This makes watch look more like an interactive program.

diff --git a/procps/watch.c b/procps/watch.c
index 18ded5e..4abad74 100644
--- a/procps/watch.c
+++ b/procps/watch.c
@@ -20,6 +20,7 @@ #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <sys/ioctl.h>
+#include <sys/select.h>
 #include <time.h>
 #include <unistd.h>
 #include <locale.h>
@@ -227,6 +228,7 @@ main(int argc, char *argv[])
 	nonl();
 	noecho();
 	cbreak();
+	nodelay(stdscr, TRUE);
 
 	for (;;) {
 		time_t t = time(NULL);
@@ -236,6 +238,10 @@ main(int argc, char *argv[])
 		FILE *p;
 		int x, y;
 		int oldeolseen = 1;
+		int key;
+
+		if ((key = getch()) == 'q') 
+			do_exit(0);
 
 		if (screen_size_changed) {
 			get_terminal_size();
@@ -314,7 +320,16 @@ main(int argc, char *argv[])
 
 		first_screen = 0;
 		refresh();
-		usleep(interval * 1000000);
+
+		/* wait until tiemout or until a key press */
+		{
+			fd_set set;
+			int fd = fileno(stdin);
+			struct timeval timeout = { interval, 0 };
+			FD_ZERO(&set);
+			FD_SET(fd, &set);
+			select(fd + 1, &set, NULL, NULL, &timeout);
+		}
 	}
 
 	endwin();
$

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

Re: [devel] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> И чо, я сделал патч к procps, куда его теперь коммитить?
> В /people/ldv/packages/procps.git писать не дают, а куда тогда?

К себе, конечно.  Нет, правда, я хочу понять, почему это не очевидно.


-- 
ldv

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

Re: [devel] procps.git

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 05:06:36AM +0400, Dmitry V. Levin wrote:
> On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> > И чо, я сделал патч к procps, куда его теперь коммитить?
> > В /people/ldv/packages/procps.git писать не дают, а куда тогда?
> 
> К себе, конечно.  Нет, правда, я хочу понять, почему это не очевидно.

К себе это куда?  У меня уже есть. :)  То есть склонировать в
/people/at/packages и закоммитить туда?  Но у меня эпизодический интерес
к procps.  К тому же не ясно, как о факте такого клонирования и
последующего коммита узнает maintainer.

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

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

Re: [devel] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 05:15:03AM +0400, Alexey Tourbin wrote:
> On Thu, Sep 14, 2006 at 05:06:36AM +0400, Dmitry V. Levin wrote:
> > On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> > > И чо, я сделал патч к procps, куда его теперь коммитить?
> > > В /people/ldv/packages/procps.git писать не дают, а куда тогда?
> > 
> > К себе, конечно.  Нет, правда, я хочу понять, почему это не очевидно.
> 
> К себе это куда?  У меня уже есть. :)  То есть склонировать в
> /people/at/packages и закоммитить туда?

За'push'ить туда, комитить ты будешь локально.

> Но у меня эпизодический интерес к procps.

У меня тоже. :)
Потом можно будет применить git-rm-db.

> К тому же не ясно, как о факте такого клонирования и
> последующего коммита узнает maintainer.

Ты можешь поставить его в известность, есть разные способы сделать это.
Сейчас я просто просматриваю все изменения, так что ничего специально
делать не надо.
Можно написать что-нибудь в email-distribution.
Есть git-format-patch и другие способы коммуникации.

> По сути хотелось бы вливать изменения в какой-нибудь incoming 
> мынтейнеровского репозитария с обязательным уведомлением.  И с
> обязательным уведомлением-резолюцией в обратную сторону.

А вот мне бы не хотелось ни того, ни другого. :)


-- 
ldv

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

Re: [devel] procps.git

[Kirill Maslinsky]

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

> > К тому же не ясно, как о факте такого клонирования и
> > последующего коммита узнает maintainer.
> 
> Ты можешь поставить его в известность, есть разные способы сделать это.
> Сейчас я просто просматриваю все изменения, так что ничего специально
> делать не надо.
> Можно написать что-нибудь в email-distribution.
> Есть git-format-patch и другие способы коммуникации.

Кстати, ведь, как говорилось в соседнем треде, список ответственных мантейнеров
по пакетам является легкодоступным и поддаётся обработке grep'ом. Что тогда
мешает всегда автоматически включать в список рассылаемых уведомлений
ответственного мантейнера данного пакета, просто сделав grep по ещё одному 
файлу? Такая логика рассылки кажется разумной: вдруг мантейнер не следит 
за всеми изменениями? А раз он ответственный, то знать об изменениях других 
в своём пакете должен.

> > По сути хотелось бы вливать изменения в какой-нибудь incoming 
> > мынтейнеровского репозитария с обязательным уведомлением.  И с
> > обязательным уведомлением-резолюцией в обратную сторону.
> 
> А вот мне бы не хотелось ни того, ни другого. :)
> 
> 
> -- 
> ldv

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 09:51:06AM +0400, Kirill Maslinsky wrote:
> > > К тому же не ясно, как о факте такого клонирования и
> > > последующего коммита узнает maintainer.
> > 
> > Ты можешь поставить его в известность, есть разные способы сделать это.
> > Сейчас я просто просматриваю все изменения, так что ничего специально
> > делать не надо.
> > Можно написать что-нибудь в email-distribution.
> > Есть git-format-patch и другие способы коммуникации.
> 
> Кстати, ведь, как говорилось в соседнем треде, список ответственных мантейнеров
> по пакетам является легкодоступным и поддаётся обработке grep'ом. Что тогда
> мешает всегда автоматически включать в список рассылаемых уведомлений
> ответственного мантейнера данного пакета, просто сделав grep по ещё одному 
> файлу? Такая логика рассылки кажется разумной: вдруг мантейнер не следит 
> за всеми изменениями? А раз он ответственный, то знать об изменениях других 
> в своём пакете должен.

Логично.  Вот только списка "ответственных мантейнеров по пакетам"
пока ещё нет.


-- 
ldv

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

Re: [devel] procps.git

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Sep 14, 2006 at 09:51:06AM +0400, Kirill Maslinsky wrote:
>>>> К тому же не ясно, как о факте такого клонирования и
>>>> последующего коммита узнает maintainer.
>>> Ты можешь поставить его в известность, есть разные способы сделать это.
>>> Сейчас я просто просматриваю все изменения, так что ничего специально
>>> делать не надо.
>>> Можно написать что-нибудь в email-distribution.
>>> Есть git-format-patch и другие способы коммуникации.
>> Кстати, ведь, как говорилось в соседнем треде, список ответственных мантейнеров
>> по пакетам является легкодоступным и поддаётся обработке grep'ом. Что тогда
>> мешает всегда автоматически включать в список рассылаемых уведомлений
>> ответственного мантейнера данного пакета, просто сделав grep по ещё одному 
>> файлу? Такая логика рассылки кажется разумной: вдруг мантейнер не следит 
>> за всеми изменениями? А раз он ответственный, то знать об изменениях других 
>> в своём пакете должен.
> 
> Логично.  Вот только списка "ответственных мантейнеров по пакетам"
> пока ещё нет.

А как же списки ?

fgrep rider Sisyphus/files/list/list.src.classic

Это разве не то ?

Rgds,
Rider

Re: [devel] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 04:56:11PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Thu, Sep 14, 2006 at 09:51:06AM +0400, Kirill Maslinsky wrote:
> >>>> К тому же не ясно, как о факте такого клонирования и
> >>>> последующего коммита узнает maintainer.
> >>> Ты можешь поставить его в известность, есть разные способы сделать это.
> >>> Сейчас я просто просматриваю все изменения, так что ничего специально
> >>> делать не надо.
> >>> Можно написать что-нибудь в email-distribution.
> >>> Есть git-format-patch и другие способы коммуникации.
> >> Кстати, ведь, как говорилось в соседнем треде, список ответственных мантейнеров
> >> по пакетам является легкодоступным и поддаётся обработке grep'ом. Что тогда
> >> мешает всегда автоматически включать в список рассылаемых уведомлений
> >> ответственного мантейнера данного пакета, просто сделав grep по ещё одному 
> >> файлу? Такая логика рассылки кажется разумной: вдруг мантейнер не следит 
> >> за всеми изменениями? А раз он ответственный, то знать об изменениях других 
> >> в своём пакете должен.
> > 
> > Логично.  Вот только списка "ответственных мантейнеров по пакетам"
> > пока ещё нет.
> 
> А как же списки ?
> 
> fgrep rider Sisyphus/files/list/list.src.classic
> 
> Это разве не то ?

Это ещё не то, это те списки, которые были раньше.


-- 
ldv

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

Re: [devel] procps.git

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Sep 14, 2006 at 04:56:11PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Thu, Sep 14, 2006 at 09:51:06AM +0400, Kirill Maslinsky wrote:
>>>>>> К тому же не ясно, как о факте такого клонирования и
>>>>>> последующего коммита узнает maintainer.
>>>>> Ты можешь поставить его в известность, есть разные способы сделать это.
>>>>> Сейчас я просто просматриваю все изменения, так что ничего специально
>>>>> делать не надо.
>>>>> Можно написать что-нибудь в email-distribution.
>>>>> Есть git-format-patch и другие способы коммуникации.
>>>> Кстати, ведь, как говорилось в соседнем треде, список ответственных мантейнеров
>>>> по пакетам является легкодоступным и поддаётся обработке grep'ом. Что тогда
>>>> мешает всегда автоматически включать в список рассылаемых уведомлений
>>>> ответственного мантейнера данного пакета, просто сделав grep по ещё одному 
>>>> файлу? Такая логика рассылки кажется разумной: вдруг мантейнер не следит 
>>>> за всеми изменениями? А раз он ответственный, то знать об изменениях других 
>>>> в своём пакете должен.
>>> Логично.  Вот только списка "ответственных мантейнеров по пакетам"
>>> пока ещё нет.
>> А как же списки ?
>>
>> fgrep rider Sisyphus/files/list/list.src.classic
>>
>> Это разве не то ?
> 
> Это ещё не то, это те списки, которые были раньше.

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

Rgds,
Rider

Re: [devel] procps.git

[Michael Shigorin]

On Thu, Sep 14, 2006 at 05:06:36AM +0400, Dmitry V. Levin wrote:
> > И чо, я сделал патч к procps, куда его теперь коммитить?
> > В /people/ldv/packages/procps.git писать не дают, а куда тогда?
> К себе, конечно.  Нет, правда, я хочу понять, почему это не очевидно.

Потому что в cvs так не делают?

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

Re: [devel] procps.git

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> $ git-log -p --max-count=1
> commit 64ef9663bc217c76ee80007a8cda189a3c7e6919
> Author: Alexey Tourbin <at@localhost.localdomain>
> Date:   Thu Sep 14 04:42:46 2006 +0400
> 
>     Implement the following behaviour:
>     
>     1) execute a program also when a key is pressed;
>     2) but if that key is 'q' then exit instead.
>     
>     This makes watch look more like an interactive program.
> 
> diff --git a/procps/watch.c b/procps/watch.c
> index 18ded5e..4abad74 100644
> --- a/procps/watch.c
> +++ b/procps/watch.c

Кстати похоже что git глючит.  Здесь должно быть написано

--- a/procps/procps/watch.c
+++ b/procps/procps/watch.c

Просто я сделал коммит в каталоге procps, наверное поэтому git
показывает не полный путь.

> @@ -20,6 +20,7 @@ #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
>  #include <sys/ioctl.h>
> +#include <sys/select.h>
>  #include <time.h>
>  #include <unistd.h>
>  #include <locale.h>

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

Re: [devel] procps.git

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 05:32:03AM +0400, Alexey Tourbin wrote:
> On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> > $ git-log -p --max-count=1
> > commit 64ef9663bc217c76ee80007a8cda189a3c7e6919
> > Author: Alexey Tourbin <at@localhost.localdomain>
> > Date:   Thu Sep 14 04:42:46 2006 +0400
> > 
> >     Implement the following behaviour:
> >     
> >     1) execute a program also when a key is pressed;
> >     2) but if that key is 'q' then exit instead.
> >     
> >     This makes watch look more like an interactive program.
> > 
> > diff --git a/procps/watch.c b/procps/watch.c
> > index 18ded5e..4abad74 100644
> > --- a/procps/watch.c
> > +++ b/procps/watch.c
> 
> Кстати похоже что git глючит.  Здесь должно быть написано
> 
> --- a/procps/procps/watch.c
> +++ b/procps/procps/watch.c

Ой нет я написал глупость.

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

[devel] watch(1)

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
>     Implement the following behaviour:
>     
>     1) execute a program also when a key is pressed;
>     2) but if that key is 'q' then exit instead.
>     
>     This makes watch look more like an interactive program.
> 
> diff --git a/procps/watch.c b/procps/watch.c
> index 18ded5e..4abad74 100644
> --- a/procps/watch.c
> +++ b/procps/watch.c
> @@ -20,6 +20,7 @@ #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
>  #include <sys/ioctl.h>
> +#include <sys/select.h>
>  #include <time.h>
>  #include <unistd.h>
>  #include <locale.h>
> @@ -227,6 +228,7 @@ main(int argc, char *argv[])
>  	nonl();
>  	noecho();
>  	cbreak();
> +	nodelay(stdscr, TRUE);
>  
>  	for (;;) {
>  		time_t t = time(NULL);
> @@ -236,6 +238,10 @@ main(int argc, char *argv[])
>  		FILE *p;
>  		int x, y;
>  		int oldeolseen = 1;
> +		int key;
> +
> +		if ((key = getch()) == 'q') 
> +			do_exit(0);
>  
>  		if (screen_size_changed) {
>  			get_terminal_size();
> @@ -314,7 +320,16 @@ main(int argc, char *argv[])
>  
>  		first_screen = 0;
>  		refresh();
> -		usleep(interval * 1000000);
> +
> +		/* wait until tiemout or until a key press */
> +		{
> +			fd_set set;
> +			int fd = fileno(stdin);
> +			struct timeval timeout = { interval, 0 };
> +			FD_ZERO(&set);
> +			FD_SET(fd, &set);
> +			select(fd + 1, &set, NULL, NULL, &timeout);
> +		}
>  	}
>  
>  	endwin();
> $


В общем затея оказалась небеспроблемная -- select может отвалить или
вернуть раньше времени по самым разным причинам, а входить в
безудержный цикл последнее дело.  Можно конечно проверять на isatty(0),
но мне эта идея почему-то не очень нравится.  Короче окончательный
вариант в git.alt:/people/at/packages/procps.git несколько лучше, чем
этот и несколько последующих.

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

Re: [devel] watch(1)

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 09:23:55AM +0400, Alexey Tourbin wrote:
> В общем затея оказалась небеспроблемная -- select может отвалить или
> вернуть раньше времени по самым разным причинам, а входить в
> безудержный цикл последнее дело.

Почему?  Например, в пакете libpcap есть
libpcap-0.9.4-nmap-alt-owl-linux-honor-timeout.patch
который так себя ведёт.

> Можно конечно проверять на isatty(0),
> но мне эта идея почему-то не очень нравится.  Короче окончательный
> вариант в git.alt:/people/at/packages/procps.git несколько лучше, чем
> этот и несколько последующих.

OK


-- 
ldv

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

Re: [devel] procps.git

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> $ git-push --all git.alt:/people/ldv/packages/procps.git

Кстати там исходники развернуты а патчи лежат отдельно не приложены.
Чего бы их не приложить?  А то я изменения в исходники сделал а вдруг
теперь какой-нибудь патч отвалится?  А мне это проверять влом я сразу
быка за рога типа make watch.

И отдельный подкаталог тогда не нужен.

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

Re: [devel] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 09:40:16AM +0400, Alexey Tourbin wrote:
> On Thu, Sep 14, 2006 at 04:51:44AM +0400, Alexey Tourbin wrote:
> > $ git-push --all git.alt:/people/ldv/packages/procps.git
> 
> Кстати там исходники развернуты а патчи лежат отдельно не приложены.

Так ведь git-srpmimport достаточно консервативен, патчи не прикладывает.

> Чего бы их не приложить?

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

> А то я изменения в исходники сделал а вдруг
> теперь какой-нибудь патч отвалится?  А мне это проверять влом я сразу
> быка за рога типа make watch.

Проверить нетрудно, gear --c --rpm -- rpmbuild -bp.

> И отдельный подкаталог тогда не нужен.

Это дело вкуса.


-- 
ldv

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

Re: [devel] procps.git

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 05:43:13PM +0400, Dmitry V. Levin wrote:
> > И отдельный подкаталог тогда не нужен.
> Это дело вкуса.

Я тогда в каком-нибудь пакете сделаю два подкаталога. :)

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

Re: [devel] [jt] procps.git

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 06:05:59PM +0400, Alexey Tourbin wrote:
> On Thu, Sep 14, 2006 at 05:43:13PM +0400, Dmitry V. Levin wrote:
> > > И отдельный подкаталог тогда не нужен.
> > Это дело вкуса.
> 
> Я тогда в каком-нибудь пакете сделаю два подкаталога. :)

Главное не менять свой вкус слишком часто. :)


-- 
ldv

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