[devel] I: Sisyphus-20050929 unmets: +2 (93/40)

[devel] I: Sisyphus-20050929 unmets: +2 (93/40)

[Alexey M. Tourbin]

	2 NEW unmet dependencies detected:
request-tracker#3.4.4-alt3.svn3881	perl(Cache/Cache.pm)
request-tracker#3.4.4-alt3.svn3881	perl(HTML/Mason.pm)

Total 40 packages have 93 unmet dependencies.

Re: [devel] I: Sisyphus-20050929 unmets: +2 (93/40)

[Vladimir Lettiev]

Alexey M. Tourbin пишет:
> 	2 NEW unmet dependencies detected:
> request-tracker#3.4.4-alt3.svn3881	perl(Cache/Cache.pm)
> request-tracker#3.4.4-alt3.svn3881	perl(HTML/Mason.pm)

Какой-то сбой в работе incoming'а. Модули Cache::Cache и HTML::Mason 
лежат неподвижно в incoming с 24 числа. А request-tracker, который от 
них зависит (Requires) каким-то образом пролез без них, и incoming не 
проверил, что требуемых пакетов нет в репозитории.

По поводу HTML::Mason.
Уже некоторое время я экспериментирую с ним. Поскольку данный модуль 
используется в основном в связке apache+mod_perl, то для его нормального 
функционирования требуется libapreq, который провайдит необходимый 
Apache::Request. Наверно стоит собрать его для Sisyphus и 
подкорректировать HTML::Mason.

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

Re: [devel] I: Sisyphus-20050929 unmets: +2 (93/40)

[Alexey Gladkov]

Vladimir Lettiev пишет:
> Какой-то сбой в работе incoming'а. Модули Cache::Cache и HTML::Mason

Да, вы правы. Сейчас разбираюсь.

> лежат неподвижно в incoming с 24 числа. А request-tracker, который от
> них зависит (Requires) каким-то образом пролез без них, и incoming не
> проверил, что требуемых пакетов нет в репозитории.

Было бы намного хуже если они начнут ползать по incoming/.

lftp
ftp.altlinux.org:/pub/people/incominger/archive/i586/reject/2005/09/26>
l perl*
-rw-r--r--    1 ftp      ftp            99 Sep 26 13:14
perl-Cache-Cache-1.04-alt2.src.rpm.log.bz2
-rw-r--r--    1 ftp      ftp            97 Sep 26 13:14
perl-HTML-Mason-1.3101-alt2.src.rpm.log.bz2
-rw-r--r--    1 ftp      ftp           208 Sep 26 12:05
perl-Class-Data-Inheritable-0.04-alt1.src.rpm.log.bz2

-- 
Rgrds, legion

Re: [devel] I: Sisyphus-20050929 unmets: +2 (93/40)

[Vladimir Lettiev]

Alexey Gladkov пишет:
> 
> Было бы намного хуже если они начнут ползать по incoming/.
> 
> lftp
> ftp.altlinux.org:/pub/people/incominger/archive/i586/reject/2005/09/26>
> l perl*
> -rw-r--r--    1 ftp      ftp            99 Sep 26 13:14
> perl-Cache-Cache-1.04-alt2.src.rpm.log.bz2
> -rw-r--r--    1 ftp      ftp            97 Sep 26 13:14
> perl-HTML-Mason-1.3101-alt2.src.rpm.log.bz2
> -rw-r--r--    1 ftp      ftp           208 Sep 26 12:05
> perl-Class-Data-Inheritable-0.04-alt1.src.rpm.log.bz2

Ошибка сборки [цепочки] пакетов из-за того что в репозитории отсутствует 
perl-IPC-ShareLite. Интересно, куда он пропал?

Странно и то, что src.rpm в наличии на 
ftp://ftp.altli..../Sisyphus/files/SRPMS/ , а больше его нигде нет.

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Alexey Tourbin]

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

On Sat, Oct 01, 2005 at 03:15:24AM +0400, Vladimir Lettiev wrote:
> Ошибка сборки [цепочки] пакетов из-за того что в репозитории отсутствует 
> perl-IPC-ShareLite. Интересно, куда он пропал?

А в orphaned его нету?  Помнится какой-то perl-IPC-* пакет попал
в orphaned из-за проблем с Owl ядром.

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

Re: [devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Vladimir Lettiev]

Alexey Tourbin пишет:
> On Sat, Oct 01, 2005 at 03:15:24AM +0400, Vladimir Lettiev wrote:
> 
>>Ошибка сборки [цепочки] пакетов из-за того что в репозитории отсутствует 
>>perl-IPC-ShareLite. Интересно, куда он пропал?
> 
> 
> А в orphaned его нету?  Помнится какой-то perl-IPC-* пакет попал
> в orphaned из-за проблем с Owl ядром.


Алексей, вспомните. Вы сами в начале сентября говорили Виталию Липатову, 
чтобы он добавил к perl-IPC-ShareLite чейнджлог от старой сборки, 
которая была в orphaned. Он так и сделал, пакет с релизом alt2 был 
зафиксирован в Sisyphus 6 сентября.
http://lists.altlinux.ru/pipermail/sisyphus/2005-September/068460.html

На ядрах с Owl действительно наблюдаются проблемы при запуске тестов 
этого пакета, кажется вот на такой конструкции:

my $share = new IPC::ShareLite( .... some things here ....);
...
$share->store( 0 );

Дальше тест не выполняется, висит, до нажатия Ctrl+C.
На 2.6.x естественно все ок.


-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Alexey Tourbin]

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

On Sat, Oct 01, 2005 at 11:16:54AM +0400, Vladimir Lettiev wrote:
> Алексей, вспомните. Вы сами в начале сентября говорили Виталию Липатову, 
> чтобы он добавил к perl-IPC-ShareLite чейнджлог от старой сборки, 

Наверное, так и есть.

> На ядрах с Owl действительно наблюдаются проблемы при запуске тестов 
> этого пакета, кажется вот на такой конструкции:

Я уже высказывал ценную мысль, что Owl патч должен давить бесхозные IPC
объекты не сразу, а по таймауту?  А таймаут должен устанавливаться через
sysctl.

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

Re: [devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Dmitry V. Levin]

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

On Sat, Oct 01, 2005 at 11:16:54AM +0400, Vladimir Lettiev wrote:
[...]
> Алексей, вспомните. Вы сами в начале сентября говорили Виталию Липатову, 
> чтобы он добавил к perl-IPC-ShareLite чейнджлог от старой сборки, 
> которая была в orphaned. Он так и сделал, пакет с релизом alt2 был 
> зафиксирован в Sisyphus 6 сентября.
> http://lists.altlinux.ru/pipermail/sisyphus/2005-September/068460.html
> 
> На ядрах с Owl действительно наблюдаются проблемы при запуске тестов 
> этого пакета, кажется вот на такой конструкции:
> 
> my $share = new IPC::ShareLite( .... some things here ....);
> ...
> $share->store( 0 );
> 
> Дальше тест не выполняется, висит, до нажатия Ctrl+C.
> На 2.6.x естественно все ок.

Это дело времени. :)


-- 
ldv

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

[devel] [JT] 2.6-ow?

[Michael Shigorin]

On Sat, Oct 01, 2005 at 08:01:54PM +0400, Dmitry V. Levin wrote:
> > На 2.6.x естественно все ок.
> Это дело времени. :)

Это радует, а какого -- до 2.6.20? :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----       visit our conference (Oct 2):
--          http://conference.osdn.org.ua

Re: [devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Vladimir Lettiev]

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

Dmitry V. Levin пишет:
>>На ядрах с Owl действительно наблюдаются проблемы при запуске тестов 
>>этого пакета, кажется вот на такой конструкции:
>>
>>my $share = new IPC::ShareLite( .... some things here ....);
>>...
>>$share->store( 0 );
>>
>>Дальше тест не выполняется, висит, до нажатия Ctrl+C.
>>На 2.6.x естественно все ок.
> 
> Это дело времени. :)

Я сделал патч для IPC::ShareLite.
Как мне показалось проблема в том, что данный модуль сначала делает 
shmdt() и лишь после пытается метить сегмент флагом IPC_RMID. Попробовал 
поменять порядок и вроде как заработало.
Если кто-то может его прокомментировать, welcome.

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[-- Attachment #2: sharelite.diff --]
[-- Type: text/x-patch, Size: 1029 bytes --]

--- sharelite.c~	2000-04-14 14:24:00 +0400
+++ sharelite.c	2005-10-02 14:07:41 +0400
@@ -284,10 +284,10 @@
   /* garbage collection -- remove unused segments */
   if (node->shmaddr->next_shmid >= 0) {
     shmid = node->shmaddr->next_shmid;
-    if (_detach_segments(node->next) < 0) 
-      return -1;
     if (_remove_segments(shmid) < 0) 
       return -1;   
+    if (_detach_segments(node->next) < 0) 
+      return -1;
     node->shmaddr->next_shmid = -1;
     node->next = NULL;
     share->tail = node;
@@ -446,16 +446,18 @@
   }                   
 
   semid = share->head->shmid;
-  if (_detach_segments(share->head) < 0) 
-    return -1;
 
   if (rmid) {
     if (_remove_segments(semid) < 0) 
       return -1;
     semctl_arg.val = 0;
+    if (_detach_segments(share->head) < 0) 
+      return -1;
     if (semctl(share->semid, 0, IPC_RMID, semctl_arg) < 0) 
       return -1;
   } else {
+    if (_detach_segments(share->head) < 0) 
+      return -1;
     if (RM_EX_LOCK(share->semid) < 0) 
       return -1;
   }

Re: [devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Dmitry V. Levin]

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

On Sun, Oct 02, 2005 at 02:19:07PM +0400, Vladimir Lettiev wrote:
> Dmitry V. Levin пишет:
> >>На ядрах с Owl действительно наблюдаются проблемы при запуске тестов 
> >>этого пакета, кажется вот на такой конструкции:
> >>
> >>my $share = new IPC::ShareLite( .... some things here ....);
> >>...
> >>$share->store( 0 );
> >>
> >>Дальше тест не выполняется, висит, до нажатия Ctrl+C.
> >>На 2.6.x естественно все ок.
> >
> >Это дело времени. :)
> 
> Я сделал патч для IPC::ShareLite.
> Как мне показалось проблема в том, что данный модуль сначала делает 
> shmdt() и лишь после пытается метить сегмент флагом IPC_RMID. Попробовал 
> поменять порядок и вроде как заработало.
> Если кто-то может его прокомментировать, welcome.

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


-- 
ldv

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

Re: [devel] Re: I: Sisyphus-20050929 unmets: +2 (93/40)

[Vladimir Lettiev]

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

Dmitry V. Levin пишет:
> On Sun, Oct 02, 2005 at 02:19:07PM +0400, Vladimir Lettiev wrote:
>>Я сделал патч для IPC::ShareLite.
>>Как мне показалось проблема в том, что данный модуль сначала делает 
>>shmdt() и лишь после пытается метить сегмент флагом IPC_RMID. Попробовал 
>>поменять порядок и вроде как заработало.
>>Если кто-то может его прокомментировать, welcome.

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

> Патч без контекста не очевиден, но то, что вы предлагаете сделать, логично
> и, насколько я понимаю, должно работать на всех ядрах.

Сложность в том, что IPC::ShareLite позволяет создавать сегмент, который 
может как удаляться, после отработки программы, так и нет (зачем это 
надо, не знаю). Видимо придётся фиксить также все программы, которые 
захотят использовать последнюю возможность этого модуля.

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

Смысл патча^Wхака в том, чтобы не детачится от сегмента, если число 
подключений меньше двух. И проверять перед унижтожением сегмента, что он 
уже не был уничтожен раньше, чтобы не нервировать shmat().

p.s. Исправленый пакет с этим патчем я уже залил в incoming.

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[-- Attachment #2: perl-IPC-ShareLite-fixOwl.patch --]
[-- Type: text/x-patch, Size: 2304 bytes --]

--- sharelite.c~~	2000-04-14 14:24:00 +0400
+++ sharelite.c	2005-10-03 22:35:59 +0400
@@ -22,12 +22,12 @@
 
 /* --- DEFINE MACROS FOR SEMAPHORE OPERATIONS --- */
 
-#define GET_EX_LOCK(A)    semop((A), &ex_lock[0],    3)
-#define GET_EX_LOCK_NB(A) semop((A), &ex_lock_nb[0], 3)
-#define RM_EX_LOCK(A)     semop((A), &ex_unlock[0],  1)
-#define GET_SH_LOCK(A)    semop((A), &sh_lock[0],    2)
-#define GET_SH_LOCK_NB(A) semop((A), &sh_lock_nb[0], 2)
-#define RM_SH_LOCK(A)     semop((A), &sh_unlock[0],  1) 
+#define GET_EX_LOCK(A)    semtimedop((A), &ex_lock[0],    3, &timeout[0])
+#define GET_EX_LOCK_NB(A) semtimedop((A), &ex_lock_nb[0], 3, &timeout[0])
+#define RM_EX_LOCK(A)     semtimedop((A), &ex_unlock[0],  1, &timeout[0])
+#define GET_SH_LOCK(A)    semtimedop((A), &sh_lock[0],    2, &timeout[0])
+#define GET_SH_LOCK_NB(A) semtimedop((A), &sh_lock_nb[0], 2, &timeout[0])
+#define RM_SH_LOCK(A)     semtimedop((A), &sh_unlock[0],  1, &timeout[0])
 
 /* --- DEFINE STRUCTURES FOR MANIPULATING SEMAPHORES --- */
 
@@ -61,6 +61,10 @@
   { 1, -1, (SEM_UNDO | IPC_NOWAIT) } /* remove shared read lock */
 };                                 
 
+static struct timespec timeout[1] = {
+  { 3, 0 } /* 3 sec timeout */
+};
+
 /* USER INITIATED LOCK */
 
 /* returns 0  on success -- requested operation performed   *
@@ -192,10 +196,14 @@
 
 int _detach_segments(Node *node) {
   Node *next_node;
+  struct shmid_ds shmarg;
 
   while(node != NULL) {
     next_node  = node->next;
-    if (shmdt((char *) node->shmaddr) < 0) return -1;
+    if (shmctl(node->shmid,IPC_STAT, &shmarg) < 0) return -1;
+    if (shmarg.shm_nattch > 1) {
+      if (shmdt((char *) node->shmaddr) < 0) return -1;
+    }
     free(node);
     node = next_node;
   }
@@ -205,12 +213,14 @@
 int _remove_segments(int shmid) {
   int    next_shmid;
   Header *shmaddr;
+  struct shmid_ds shmarg;
 
   while(shmid >= 0) {
+    if (shmctl(shmid, IPC_STAT, &shmarg) < 0 && errno == EIDRM) return 0;
     if ((shmaddr = (Header *) shmat(shmid, (char *) 0, 0)) == (Header *) -1) return -1;
     next_shmid = shmaddr->next_shmid;
-    if (shmdt((char *) shmaddr) < 0) return -1;   
     if (shmctl(shmid, IPC_RMID, (struct shmid_ds *) 0) < 0) return -1;
+    if (shmdt((char *) shmaddr) < 0) return -1;   
     shmid = next_shmid;
   }