[devel] I: Sisyphus-20050816 unmets: +7 (102/46)

[devel] I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey M. Tourbin]

	7 NEW unmet dependencies detected:
libevas#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
libevas-examples#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
libgnutls-extra#1.2.6-alt1	libopencdk.so.8(OPENCDK_5)
reiser4progs#1.0.4-alt1 	libaal (= 1.0.4-alt1)
reiser4progs#1.0.4-alt1 	libaal-1.0.so.4
reiser4progs-minimal#1.0.4-alt1	libaal-minimal (= 1.0.4-alt1)
reiser4progs-minimal-devel#1.0.4-alt1	libaal-minimal-devel (= 1.0.4-alt1)

Total 46 packages have 102 unmet dependencies.

Re: [devel] I: Sisyphus-20050816 unmets: +7 (102/46)

[sergey ivanov]

Всем привет,
а я как раз получил протокол несборки reiser4progs#1.0.5 со следующими
строчками:

>checking for aal_device_open in -laal... yes
>checking aal/libaal.h usability... yes
>checking aal/libaal.h presence... yes
>checking for aal/libaal.h... yes
>checking for libaal version = 1.0.5... no

При этом файлы libaal и reiser4progs в incoming залиты были с соблюдением очерёдности:

[skip]
-rw-r--r--      339990 2005/08/12 14:16:56 libaal-1.0.5-alt1.src.rpm
[skip]
-rw-r--r--      816466 2005/08/12 14:34:40 reiser4progs-1.0.5-alt1.src.rpm
[skip]

Мне казалось, что incoming автоматически выбирал более ранние файлы чтобы их собрать раньше, и если другой затем попадался зависящий от него, то нужная часть вытаскивалась не из Сизифа а из результатов предыдущей сборки.

Ну это лирика, а конкретный вопрос: что делать? Просто touch я в incoming/Sisyphus сделал, этого достаточно?
	Сергей.


Alexey M. Tourbin пишет:

>	7 NEW unmet dependencies detected:
>libevas#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
>libevas-examples#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
>libgnutls-extra#1.2.6-alt1	libopencdk.so.8(OPENCDK_5)
>reiser4progs#1.0.4-alt1 	libaal (= 1.0.4-alt1)
>reiser4progs#1.0.4-alt1 	libaal-1.0.so.4
>reiser4progs-minimal#1.0.4-alt1	libaal-minimal (= 1.0.4-alt1)
>reiser4progs-minimal-devel#1.0.4-alt1	libaal-minimal-devel (= 1.0.4-alt1)
>
>Total 46 packages have 102 unmet dependencies.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Devel mailing list
>Devel@altlinux.ru
>https://lists.altlinux.ru/mailman/listinfo/devel
>

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Tourbin]

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

On Mon, Aug 15, 2005 at 04:36:32PM -0400, sergey ivanov wrote:
> Мне казалось, что incoming автоматически выбирал более ранние файлы
> чтобы их собрать раньше, и если другой затем попадался зависящий от
> него, то нужная часть вытаскивалась не из Сизифа а из результатов
> предыдущей сборки.

incominger (робот) переупорядочивает пакеты в очереди на пересборку,
это описано в incominger-0.0.7.3/docs/README (ищите гуглом).  При этом
если робот дает сбой, то последствия могут быть гораздо хуже, чем если
бы оставалось старое правило для упорядочивания по BUILDTIME или st_mtime.

Нужно бы ввести правило, чтобы, вопреки какому-то там закону
термодинамики, количество unmet'ов в главном репозитарии не
увеличивалось.  Если же транзакция увеличивает количество unmet'ов,
то пакеты, которые порождают unmet'ы, исключаются из транзакции и
помещаются в отстойник, до следующей обработки/транзакции.

Только вот как определить пакеты, которые порождают unmet'ы?  Допустим,
в транзакции 100 пакетов, при этом от новой сборки xorg-x11 появляется
unmet у старой сборки ImageMagick.  Можно исключать из транзакции по
одному пакету и смотреть, не уменьшилось ли количество unmet'ов.  Так
в среднем за 50 итераций можно найти xorg-x11.  С другой стороны, в
транзакции могут быть пакеты, который зависят от новой сборки xorg-x11,
так что при исключении из транзакции одного только xorg-x11 количество
unmet'ов не уменьшится.

В общем случае, получается, сначала нужно пробовать исключать по одному
пакету (C(100,1)=100 итераций), потом по два пакета (C(100,2)=4950
итераций), потом по три пакета (C(100,3) итераций) и т.д.  Кажется, это
называется бином Ньютона.  В целом потребуется 2^{100}-1 итераций, т.е.

$ perl -le 'print 2**100-1'
1.26765060022823e+30
$

Мда, астрономично.  Нужен какой-нибудь более хитроумный dependency
solver.  smartpm надо бы поковырять, но там питон. :)

> Ну это лирика, а конкретный вопрос: что делать? Просто touch я в
> incoming/Sisyphus сделал, этого достаточно?

Нет, задним числом пакеты в репозитарии заменять нельзя.
Наверное, робот сможет добавить .1 к релизу.

Кстати, я написал/дописал утилиту для *упрощенного* поиска unmet'ов.
Казалось бы, куда уж проще, но всё же...

$ ./unmets -s m24-sources.list
ant#1.6.2-alt2  j2se-devel (>= 1.2)
bigloo#2.6d-alt1        j2se1.4-blackdown-devel
emacs-xslt-process#2.2-alt9     j2se1.4-blackdown
kernel-modules-slmdm-std-smp#1:2.7.10-alt19.12  kernel-modules-slmdm-data
kernel-modules-slmdm-std-up#1:2.7.10-alt19.12   kernel-modules-slmdm-data
kernel-modules-slmdm-vs-smp#1:2.7.10-alt19.12.1 kernel-modules-slmdm-data
nvclock#0.6.2-alt2      NVIDIA_GLX
trang#0.1.20030619-alt1 j2se1.4-blackdown
uqm-big#0.3-alt3        uqm-voice (= 0.3)
uqm-bin#0.3-alt1        uqm-content (= 0.3)
uqm-maxi#0.3-alt3       uqm-remix-pack1
uqm-maxi#0.3-alt3       uqm-remix-pack2
uqm-maxi#0.3-alt3       uqm-remix-pack3
uqm-maxi#0.3-alt3       uqm-voice (= 0.3)
xml-commons-resolver#1.1-alt2   j2se (>= 1.4.2)
$

Будет в qa-robot-0.2 (для тех, кто в танке, -- в /raid/at/qa/qa-robot).

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

Re: [devel] I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Gladkov]

sergey ivanov пишет:
> 
> Мне казалось, что incoming автоматически выбирал более ранние файлы чтобы их собрать раньше, и если другой затем попадался зависящий от него, то нужная часть вытаскивалась не из Сизифа а из результатов предыдущей сборки.
>

Если восмотреть в начало полного лога вооруженным глазом:

butcher: 2005-08-15 21:49:15 rebuild failed

Preparing packages for installation...

libaal-1.0.5-alt1

libaal-devel-1.0.5-alt1

libaal-minimal-1.0.5-alt1

libaal-minimal-devel-1.0.5-alt1

gcc-c++-common-1.4.6-alt1

libstdc++3.4-3.4.4-alt1

libstdc++3.4-devel-3.4.4-alt1

gcc3.4-c++-3.4.4-alt1

libe2fs-devel-1.37-alt2

Installing reiser4progs-1.0.5-alt1.src.rpm

Building target platforms: i586

Building for target i586

Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.45137

Видно что libaal-1.0.5-alt1 устанавливается в сборочную систему.

Ктоме того:
$ l Sisyphus/files/i586/RPMS/libaal-1.0.5-alt1.i586.rpm
-rw-r--r--  1 copy copy 34558 Авг 15 00:48
Sisyphus/files/i586/RPMS/libaal-1.0.5-alt1.i586.rpm

libaal прошел в сизиф. И попал он туда до сборки reiser4progs.

> Ну это лирика, а конкретный вопрос: что делать? Просто touch я в incoming/Sisyphus сделал, этого достаточно?

Это не лирика, а проза жизни.
Нужно выяснять почему в configure в reiser4progs не проходит проверка.

-- 
Rgrds, legion

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Gladkov]

Alexey Tourbin пишет:
> incominger (робот) переупорядочивает пакеты в очереди на пересборку,
> это описано в incominger-0.0.7.3/docs/README (ищите гуглом).  При этом
> если робот дает сбой, то последствия могут быть гораздо хуже, чем если
> бы оставалось старое правило для упорядочивания по BUILDTIME или st_mtime.

Вот зараза неужели уже за индексировали ?! :)
Сейчас сбои случаются из-за того, что incominger не учитывает версии в
 BuildRequires.

> Нужно бы ввести правило, чтобы, вопреки какому-то там закону
> термодинамики, количество unmet'ов в главном репозитарии не
> увеличивалось.  Если же транзакция увеличивает количество unmet'ов,
> то пакеты, которые порождают unmet'ы, исключаются из транзакции и
> помещаются в отстойник, до следующей обработки/транзакции.

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

> Только вот как определить пакеты, которые порождают unmet'ы?  Допустим,

<skip>

> Мда, астрономично.  Нужен какой-нибудь более хитроумный dependency
> solver.  smartpm надо бы поковырять, но там питон. :)

Если интеграл не берется целиком, его можно попробовать взять по частям.

Все unmets можно классифицировать. После этого можно рассмотреть
каждую группу и принять решение. Это реально сделать.
Вопрос в другом и ты его задал. Сделаю это еще раз: что делать если
неудовлетворенность порождается пакетом от которого зависят другие
пакеты в разобранном инкоминге?
По логике нужно исключить битый пакет и попробовать собрать пакеты без
него. Но это может долгая и бессмысленная работа.

Если же откладывать всех требующих битый пакет, мы можем получить
некоторый ДОС. Но это жертва на которую я готов пойти. Ведь виновника
можно очень просто выявить(до пересборки допускаются только
подписанные пакеты) и дать по мозгу.

> Нет, задним числом пакеты в репозитарии заменять нельзя.
> Наверное, робот сможет добавить .1 к релизу.

В данном случае incominger не виноват. Пакеты он собрал в нужном порядке.

> Кстати, я написал/дописал утилиту для *упрощенного* поиска unmet'ов.
> Казалось бы, куда уж проще, но всё же...
> 
> $ ./unmets -s m24-sources.list

Отлично!
Я предпочитаю пользоваться простой старой табуреткой: aptbox+diff.

-- 
Rgrds, legion

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 03:59:17AM +0400, Alexey Gladkov wrote:
> Сейчас сбои случаются из-за того, что incominger не учитывает версии в
>  BuildRequires.

Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
BuildRequires.  Их просто apt не понимает.

> Сейчас работаю над реализацией этой проверки. В incominger уже давно
> есть скрипт для проверки unmets, но он не использовался из-за того,
> что genbasedir ооооочень медленно работает.

А в sources.list есть метод rpm-dir, он не поможет?  То есть можно
генерировать не полный репозитарий, а оверлейный как надстройку для
данной транзакции.  В общем, я пока до конца не врубаюсь.  Надо ещё
incominger-0.0.7.3 почитать.

> Все unmets можно классифицировать. После этого можно рассмотреть
> каждую группу и принять решение. Это реально сделать.
> Вопрос в другом и ты его задал. Сделаю это еще раз: что делать если
> неудовлетворенность порождается пакетом от которого зависят другие
> пакеты в разобранном инкоминге?
> По логике нужно исключить битый пакет и попробовать собрать пакеты без
> него. Но это может долгая и бессмысленная работа.

Нет, сначала нужно собрать все пакеты "без задней мысли".  Получится
переходный репозатирий.  Переходный репозитарий = главный репозитарий +
оверлей.  Оверлей -- это типа транзакции, --with-stuff, которая содержит
пакеты, которые будут перемещены/заменены в главном репозитарии.

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

> Если же откладывать всех требующих битый пакет, мы можем получить
> некоторый ДОС. Но это жертва на которую я готов пойти. Ведь виновника
> можно очень просто выявить(до пересборки допускаются только
> подписанные пакеты) и дать по мозгу.

Есть два критерия "пакетов, которые требуют битый": 1) жесткий критерий,
то есть версионная зависимость на именно этот битый пакет; 2) мягкий
критерий, в смысле выстраивания очереди на пересборку.

Вопрос: если имеет место быть мягкий критерий, т.е. если группу пакетов
желательно пересобрать с битым, но можно пересобрать и с более ранней
версией битого пакета в главном репозитарии, то что делать?  Если битый
пакет несёт с собой библиотеку с новым soname'ом, то очень плохо.  Но
заранее узнать нельзя.

> > Кстати, я написал/дописал утилиту для *упрощенного* поиска unmet'ов.
> > Казалось бы, куда уж проще, но всё же...
> > 
> > $ ./unmets -s m24-sources.list
> 
> Отлично!
> Я предпочитаю пользоваться простой старой табуреткой: aptbox+diff.

Это и есть wrapper для aptbox, только он переформатирует вывод apt,
чтобы unmet'ы были по одному на строчку.  Такой список уже можно
сортировать или грепать, что немаловажно.  А вместо diff здесь лучше
подходит comm.

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

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Gladkov]

Alexey Tourbin пишет:
> Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
> BuildRequires.  Их просто apt не понимает.

У него другие задачи. Ему это не требуется.

> А в sources.list есть метод rpm-dir, он не поможет?  То есть можно
> генерировать не полный репозитарий, а оверлейный как надстройку для
> данной транзакции.  В общем, я пока до конца не врубаюсь.  Надо ещё
> incominger-0.0.7.3 почитать.

Я выложил новую версию ... incominger-0.0.8.2

> Нет, сначала нужно собрать все пакеты "без задней мысли".  Получится
> переходный репозатирий.  Переходный репозитарий = главный репозитарий +
> оверлей.  Оверлей -- это типа транзакции, --with-stuff, которая содержит
> пакеты, которые будут перемещены/заменены в главном репозитарии.
> 
> Далее сравниваем главный и переходный репозитарии по количеству
> unmet'ов.  Если в переходном репозитарии есть новые unmet'ы, то пробуем
> исключить из оверлея пакеты один за другим, и каждый раз проверяем новые
> unmet'ы.  Если при исключении очередного пакета количество unmet'ов
> уменьшается, то этот пакет помещается в отстойник, поиск врагов
> продолжается на оставшемся оврлее.

incominger-0.0.8.2/data/checkunmets
примерно этим занимается ... если я правильно тебя понял.

> Есть два критерия "пакетов, которые требуют битый": 1) жесткий критерий,
> то есть версионная зависимость на именно этот битый пакет; 2) мягкий
> критерий, в смысле выстраивания очереди на пересборку.

Да.

> Вопрос: если имеет место быть мягкий критерий, т.е. если группу пакетов
> желательно пересобрать с битым, но можно пересобрать и с более ранней
> версией битого пакета в главном репозитарии, то что делать?  Если битый
> пакет несёт с собой библиотеку с новым soname'ом, то очень плохо.  Но
> заранее узнать нельзя.

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

> Это и есть wrapper для aptbox, только он переформатирует вывод apt,

Я знаю ... у же посмотрел. :)

> чтобы unmet'ы были по одному на строчку.  Такой список уже можно
> сортировать или грепать, что немаловажно.  А вместо diff здесь лучше
> подходит comm.

Такой формат удобен для скриптов.

-- 
Rgrds, legion

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Michael Shigorin]

On Tue, Aug 16, 2005 at 03:17:52AM +0400, Alexey Tourbin wrote:
> incominger (робот) переупорядочивает пакеты в очереди на пересборку,
> это описано в incominger-0.0.7.3/docs/README (ищите гуглом).

http://wiki.sisyphus.ru/incominger?

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

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Dmitry V. Levin]

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

On Tue, Aug 16, 2005 at 04:40:31AM +0400, Alexey Tourbin wrote:
> On Tue, Aug 16, 2005 at 03:59:17AM +0400, Alexey Gladkov wrote:
> > Сейчас сбои случаются из-за того, что incominger не учитывает версии в
> >  BuildRequires.
> 
> Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
> BuildRequires.  Их просто apt не понимает.

Разве?


-- 
ldv

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

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Dmitry V. Levin]

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

On Tue, Aug 16, 2005 at 09:49:26PM +0400, Dmitry V. Levin wrote:
> On Tue, Aug 16, 2005 at 04:40:31AM +0400, Alexey Tourbin wrote:
> > On Tue, Aug 16, 2005 at 03:59:17AM +0400, Alexey Gladkov wrote:
> > > Сейчас сбои случаются из-за того, что incominger не учитывает версии в
> > >  BuildRequires.
> > 
> > Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
> > BuildRequires.  Их просто apt не понимает.
> 
> Разве?

Насколько я помню, он так понимает, что иногда кажется, что лучше бы он их
не понимал.


-- 
ldv

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

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 09:49:26PM +0400, Dmitry V. Levin wrote:
> > Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
> > BuildRequires.  Их просто apt не понимает.
> Разве?

Я вот это имел в виду:

----- Forwarded message from Alexey Tourbin <at@altlinux.ru> -----

Date: Sat, 17 Apr 2004 02:24:02 +0400
From: Alexey Tourbin <at@altlinux.ru>
Subject: Re: hasher fails to resolve dependencies

[...]

hasher не умеет разрешать зависимости типа:

BuildPreReq: perl(XML/LibXML) >= 0:%version

Говорит:

...
initroot: created RPM build directory tree.
rebuild: changed working directory to `/home/at/build'
rebuild: perl-XML-LibXSLT-1.57-alt1.src.rpm: calculated dependencies: perl(XML/LibXML.pm)>=0:1.57
libxslt-devel
perl-devel
install: changed working directory to `/home/at/build'
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package perl(XML
install: failed to calculate package file list.
install: failed to generate package file list.
$

----- End forwarded message -----

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

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Dmitry V. Levin]

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

On Tue, Aug 16, 2005 at 10:06:04PM +0400, Alexey Tourbin wrote:
> On Tue, Aug 16, 2005 at 09:49:26PM +0400, Dmitry V. Levin wrote:
> > > Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
> > > BuildRequires.  Их просто apt не понимает.
> > Разве?
> 
> Я вот это имел в виду:
[...]
> hasher не умеет разрешать зависимости типа:
> 
> BuildPreReq: perl(XML/LibXML) >= 0:%version

До сих пор?


-- 
ldv

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

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 10:12:22PM +0400, Dmitry V. Levin wrote:
> > hasher не умеет разрешать зависимости типа:
> > BuildPreReq: perl(XML/LibXML) >= 0:%version
> До сих пор?

at@mash ~ $ hsh --initroot-only /build/at/build
Components: hasher
Processing pkglists... hasher done
Processing srclists...  hasher done
Creating component releases... hasher done
Creating global release file... done
Appending MD5Sum... hasher done
All your base are belong to us!!!
at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML)>=0:1.57'
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package perl(XML
hsh-install: failed to calculate package file list.
hsh-install: Failed to generate package file list.
at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML)'
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package perl(XML
hsh-install: failed to calculate package file list.
hsh-install: Failed to generate package file list.
at@mash ~ $

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

Re: [devel] apt-get strips /

[Dmitry V. Levin]

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

On Tue, Aug 16, 2005 at 10:26:46PM +0400, Alexey Tourbin wrote:
> On Tue, Aug 16, 2005 at 10:12:22PM +0400, Dmitry V. Levin wrote:
> > > hasher не умеет разрешать зависимости типа:
> > > BuildPreReq: perl(XML/LibXML) >= 0:%version
> > До сих пор?
> 
> at@mash ~ $ hsh --initroot-only /build/at/build
> Components: hasher
> Processing pkglists... hasher done
> Processing srclists...  hasher done
> Creating component releases... hasher done
> Creating global release file... done
> Appending MD5Sum... hasher done
> All your base are belong to us!!!
> at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML)>=0:1.57'
> Reading Package Lists...
> Building Dependency Tree...
> E: Couldn't find package perl(XML
> hsh-install: failed to calculate package file list.
> hsh-install: Failed to generate package file list.
> at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML)'
> Reading Package Lists...
> Building Dependency Tree...
> E: Couldn't find package perl(XML
> hsh-install: failed to calculate package file list.
> hsh-install: Failed to generate package file list.
> at@mash ~ $

$ ~/build/aptbox/apt-get -q -y --print-uris install -- 'perl(XML/LibXML)'
Чтение списков пакетов...
Построение дерева зависимостей...
E: Невозможно найти пакет perl(XML

Короче говоря, символ / зарезервирован для какого-то действия, помеченного
в коде apt-get.cc следующим комментарием:
"CNC:2003-11-21 - Try to handle unknown file items."

Реализовать квотирование в apt-get, что ли?


-- 
ldv

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

[devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 10:26:46PM +0400, Alexey Tourbin wrote:
> at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML)'
> Reading Package Lists...
> Building Dependency Tree...
> E: Couldn't find package perl(XML
> hsh-install: failed to calculate package file list.
> hsh-install: Failed to generate package file list.
> at@mash ~ $

Упс.  Я немного лажанулся...

at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML.pm)'
Preparing packages for installation...
perl-XML-NamespaceSupport-1.09-alt1
xml-common-0.6.3-alt11
libxml2-2.6.20-alt1
perl-XML-SAX-0.12-alt5
perl-XML-LibXML-1.58-alt3.1
at@mash ~ $ hsh-install /build/at/build 'perl(XML/LibXML.pm)>=1.570'
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package perl(XML
hsh-install: failed to calculate package file list.
hsh-install: Failed to generate package file list.
at@mash ~ $

Не рискну теперь обобщить. :)

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

[devel] Re: apt-get strips /

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 10:41:49PM +0400, Dmitry V. Levin wrote:
> $ ~/build/aptbox/apt-get -q -y --print-uris install -- 'perl(XML/LibXML)'
> Чтение списков пакетов...
> Построение дерева зависимостей...
> E: Невозможно найти пакет perl(XML
> 
> Короче говоря, символ / зарезервирован для какого-то действия, помеченного
> в коде apt-get.cc следующим комментарием:
> "CNC:2003-11-21 - Try to handle unknown file items."
> 
> Реализовать квотирование в apt-get, что ли?

Лучше apt захачить.  Проблема в виртуальных зависимостях *с версиями*,
то есть 'perl(XML/LibXML.pm)' всё же встает (пакета perl(XML/LibXML)
действительно не существует, нужно добавить .pm).

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

Re: [devel] Re: apt-get strips /

[Dmitry V. Levin]

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

On Tue, Aug 16, 2005 at 10:47:59PM +0400, Alexey Tourbin wrote:
> On Tue, Aug 16, 2005 at 10:41:49PM +0400, Dmitry V. Levin wrote:
> > $ ~/build/aptbox/apt-get -q -y --print-uris install -- 'perl(XML/LibXML)'
> > Чтение списков пакетов...
> > Построение дерева зависимостей...
> > E: Невозможно найти пакет perl(XML
> > 
> > Короче говоря, символ / зарезервирован для какого-то действия, помеченного
> > в коде apt-get.cc следующим комментарием:
> > "CNC:2003-11-21 - Try to handle unknown file items."
> > 
> > Реализовать квотирование в apt-get, что ли?
> 
> Лучше apt захачить.  Проблема в виртуальных зависимостях *с версиями*,
> то есть 'perl(XML/LibXML.pm)' всё же встает (пакета perl(XML/LibXML)
> действительно не существует, нужно добавить .pm).

s/захачить/зафиксить/
Там очевидная ошибка (нестыковка в обработке / и <=>).
Тому, кто реализовал CNC:2003-11-05, надо было отключить обработку / в
случае если указана версия.


-- 
ldv

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

Re: [devel] Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Alexey Gladkov]

Alexey Gladkov пишет:
> Про это я и говорил. Придется заруливать всю группу. Потому что битый
> пакет с большой вероятностью потом попадет в репозиторий и эту группу
> все-равно придется пересобирать ... они его хотят, но не требуют.

Вот только не получается заруливать :(

живой пример:

Пакет kernel-modules-zaptel-std26-up версии 1.0-alt2.132620.3 имеет
неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)
Пакет kernel-modules-ipw2200-std26-smp версии 1.0.6-alt2.132620.3
имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-smp (= 2.6.12-alt3)
 Для установки требует: kernel-modules-ieee80211-std26-smp (=
1.0.2-alt2.132620.3)
Пакет kernel-modules-ipw2100-std26-smp версии 1.1.2-alt2.132620.3
имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-smp (= 2.6.12-alt3)
 Для установки требует: kernel-modules-ieee80211-std26-smp (=
1.0.2-alt2.132620.3)
Пакет kernel-modules-ipw2200-std26-up версии 1.0.6-alt2.132620.3 имеет
неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)
 Для установки требует: kernel-modules-ieee80211-std26-up (=
1.0.2-alt2.132620.3)
Пакет kernel-modules-ipw2100-std26-up версии 1.1.2-alt2.132620.3 имеет
неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)
 Для установки требует: kernel-modules-ieee80211-std26-up (=
1.0.2-alt2.132620.3)
Пакет kernel-modules-zaptel-std26-smp версии 1.0-alt2.132620.3 имеет
неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-smp (= 2.6.12-alt3)
 Для установки требует: kernel-image-std26-smp (= 2.6.12-alt3)
Пакет kernel-modules-amedyn-std26-up версии 20040801-alt5.3 имеет
неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)
 Для установки требует: kernel-image-std26-up (= 2.6.12-alt3)

Кого заруливать ?
Ядро ?

-- 
Rgrds, legion

Re: [devel] I: Sisyphus-20050816 unmets: +7 (102/46)

[Dmitry V. Levin]

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

On Mon, Aug 15, 2005 at 04:36:32PM -0400, sergey ivanov wrote:
[...]
> Ну это лирика, а конкретный вопрос: что делать? Просто touch я в incoming/Sisyphus сделал, этого достаточно?

Если пакет не собрался (а он не собрался), то достаточно сделать touch.
Письмецо от робота эту гипотезу подтверждает.


-- 
ldv

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

Re: [devel] apt-get strips /

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [050816 22:42]:
> E: Невозможно найти пакет perl(XML

> Короче говоря, символ / зарезервирован для какого-то действия,
Это, если не ошибаюсь, аналог apt-get -t для одного пакета.

-- 
Regards, Sir Raorn.
-------------------
>жаль, что ALT пока не выпустил наружу AMD64 репозитарий сизифа...
Этим занимается мышь. Не та, о которой речь пойдет ниже, а mouse@
:)
		-- horror in community@

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

[devel] Re: Re: I: Sisyphus-20050816 unmets: +7 (102/46)

[Anton Farygin]

On Tue, 16 Aug 2005 23:44:35 +0400, Alexey Gladkov wrote:

> Alexey Gladkov пишет:
>> Про это я и говорил. Придется
>> заруливать всю группу. Потому что битый
>> пакет с большой вероятностью потом
>> попадет в репозиторий и эту группу
>> все-равно придется пересобирать ... они
>> его хотят, но не требуют.
> 
> Вот только не получается заруливать :(
> 
> живой пример:
> 
> Пакет kernel-modules-zaptel-std26-up версии 1.0-alt2.132620.3
> имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-std26-up (=
>  2.6.12-alt3) Для установки требует:
>  kernel-image-std26-up (= 2.6.12-alt3)
> Пакет kernel-modules-ipw2200-std26-smp версии
> 1.0.6-alt2.132620.3 имеет неудовлетворенные
> зависимости:
>  Для установки требует: kernel-image-std26-smp (=
>  2.6.12-alt3) Для установки требует:
>  kernel-modules-ieee80211-std26-smp (=
> 1.0.2-alt2.132620.3)
> Пакет kernel-modules-ipw2100-std26-smp версии
> 1.1.2-alt2.132620.3 имеет неудовлетворенные
> зависимости:
>  Для установки требует: kernel-image-std26-smp (=
>  2.6.12-alt3) Для установки требует:
>  kernel-modules-ieee80211-std26-smp (=
> 1.0.2-alt2.132620.3)
> Пакет kernel-modules-ipw2200-std26-up версии
> 1.0.6-alt2.132620.3 имеет неудовлетворенные
> зависимости:
>  Для установки требует: kernel-image-std26-up (=
>  2.6.12-alt3) Для установки требует:
>  kernel-modules-ieee80211-std26-up (=
> 1.0.2-alt2.132620.3)
> Пакет kernel-modules-ipw2100-std26-up версии
> 1.1.2-alt2.132620.3 имеет неудовлетворенные
> зависимости:
>  Для установки требует: kernel-image-std26-up (=
>  2.6.12-alt3) Для установки требует:
>  kernel-modules-ieee80211-std26-up (=
> 1.0.2-alt2.132620.3)
> Пакет kernel-modules-zaptel-std26-smp версии 1.0-alt2.132620.3
> имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-std26-smp (=
>  2.6.12-alt3) Для установки требует:
>  kernel-image-std26-smp (= 2.6.12-alt3)
> Пакет kernel-modules-amedyn-std26-up версии 20040801-alt5.3
> имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-std26-up (=
>  2.6.12-alt3) Для установки требует:
>  kernel-image-std26-up (= 2.6.12-alt3)
> 
> Кого заруливать ?
> Ядро ?

В branch, кстати, все собралось хорошо.

У тебя какие-то грабли с incominger.

Там для ipw2200 не совсем простые зависимости по сборке.

Точнее они простые, но требуют
предварительной сборки одного из
пакетов, отправленных в OUT

Rgds,
Rider

[devel] libevas.so.1

[Alexey Tourbin]

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

On Tue, Aug 16, 2005 at 12:08:12AM +0400, Alexey M. Tourbin wrote:
> 	7 NEW unmet dependencies detected:
> libevas#1:0.9.9-alt0.1_003_20050530	libcairo.so.1

Это ОЧЕНЬ ПЛОХОЙ unmet, который существует уже довольно долгое время.
Из-за него не удается установить ОЧЕНЬ МНОГО пакетов, например:

  e17: Depends: libevas.so.1
  libecore: Depends: libevas.so.1
  libedje: Depends: libevas.so.1
  libemotion: Depends: libevas.so.1
  libengrave: Depends: libevas.so.1
  libesmart: Depends: libevas.so.1
  libetox: Depends: libevas.so.1
  libewl: Depends: libevas.so.1

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

[devel] Re: libevas.so.1

[Alexey Tourbin]

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

On Sat, Sep 03, 2005 at 01:58:05AM +0400, Alexey Tourbin wrote:
> On Tue, Aug 16, 2005 at 12:08:12AM +0400, Alexey M. Tourbin wrote:
> > 	7 NEW unmet dependencies detected:
> > libevas#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
> 
> Это ОЧЕНЬ ПЛОХОЙ unmet, который существует уже довольно долгое время.
> Из-за него не удается установить ОЧЕНЬ МНОГО пакетов, например:
> 
>   e17: Depends: libevas.so.1
>   libecore: Depends: libevas.so.1
>   libedje: Depends: libevas.so.1
>   libemotion: Depends: libevas.so.1
>   libengrave: Depends: libevas.so.1
>   libesmart: Depends: libevas.so.1
>   libetox: Depends: libevas.so.1
>   libewl: Depends: libevas.so.1

А evas-0.9.9-alt0.1_003_20050530.src.rpm не пересобирается:

evas_x_main.c: In function `evas_engine_cairo_x11_window_new':
evas_x_main.c:31: error: too few arguments to function `cairo_create'

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

Re: [devel] Re: libevas.so.1

[Denis Klykvin]

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

On Sat, 3 Sep 2005 02:30:49 +0400
Alexey Tourbin wrote:

> > > libevas#1:0.9.9-alt0.1_003_20050530	libcairo.so.1
> > 
> > Это ОЧЕНЬ ПЛОХОЙ unmet, который существует уже довольно долгое
> > время. Из-за него не удается установить ОЧЕНЬ МНОГО пакетов,
> > например:
> > 
> >   e17: Depends: libevas.so.1
> >   libecore: Depends: libevas.so.1
> >   libedje: Depends: libevas.so.1
> >   libemotion: Depends: libevas.so.1
> >   libengrave: Depends: libevas.so.1
> >   libesmart: Depends: libevas.so.1
> >   libetox: Depends: libevas.so.1
> >   libewl: Depends: libevas.so.1
> 
> А evas-0.9.9-alt0.1_003_20050530.src.rpm не пересобирается:
> 
> evas_x_main.c: In function `evas_engine_cairo_x11_window_new':
> evas_x_main.c:31: error: too few arguments to function `cairo_create'
Его ж вроде murygin@ или davinchi@ забрали?
Я могу пересобрать всё из cvs. Но это ближе к ночеру

-- 
With Best Wishes, Denis Klykvin
JID:	nikon@jabber.ru

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