[devel] Стабильный Сизиф II

[devel] Стабильный Сизиф II

[Fr. Br. George]

[x-post: devel@ community@ sysiphus@]

Здравствуйте, все!

Начинается подготовка к выпуску стабильного Сизифа.

Страница проекта "Стабильный Сизиф":
http://wiki.sisyphus.ru/SisyphusRelease

Страница текущего выпуска:
http://wiki.sisyphus.ru/SisyphusRelease/Uranus

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

В связи с этим -- три задачи, которые в одиночку не может решить никто:
1. Багзилла. Ситуация с ней аховая -- масса заброшенных, годами не
   исправляемых ошибок. Масса мусора (например FIXED/не-CLOSED). В результате
   по bz правтически никто не может составить впечатление о положении дел в
   Сизифе. А хотелось бы, чтобы могли.
2. Список актуальных пакетов и их пользователей.
   http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
   Там, в общем, всё написано. Пакет, имеющий пользователя, который может
   сказать "да, этот пакет работает" -- кандидат в выпуск. Пакет, не имеющий
   пользователей, попадёт туда на основании _отсутствия_ ошибок в bz.
3. Правила допуска обновлений пакета во время Freeze (в т. ч. и NMU)
   http://wiki.sisyphus.ru/SisyphusRelease/FreezePolicy
   Опять-таки, там написано. Чтобы потом не было разборок, надо договориться
   сейчас.

Согласно плану, уже серез неделю нас ожидает стадия Sync -- погоня за
upstream и стабилизация. Очень хотелось бы, чтобы те, кто собпровождает
библиотеки и особо крупных монстров (KDE, OOo и т. п.), начали
задумываться об этом как можно раньше -- ведь от них зависит
стабильность многих сотен пакетов.

P.S.		Не забывайте, что это wiki. Если что-то хотите исправить на
		страничках -- исправляйте. Однако не забывайте, что это -- не
		форум, диалоги лучше устраивать в рассылках и комментариях,
		в т. ч. http://community.livejournal.com/ru_sisyphus

P.P.S.		Он заорал "У вас что, крыши поехали?!" и начал махать руками.
		Но микрофон включили после слова "крыши",
	       	а камеру выключили после первого взмаха...
-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Стабильный Сизиф II

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> Начинается подготовка к выпуску стабильного Сизифа.

Чтобы подготовка к выпуску стабильного сизифа стала вконец возможной,
нужно также адресовать следующие проблемы:

1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE и,
возможно, что-то ещё.  Речь даже шла о том, чтобы до начала более
глубокого фриза пересобрать все бинарные пакеты новым toolchain'ом.

2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
какие нет.  Готовиться к фризу в таком положении означает готовиться к
худшему -- в надежде на лучшее, разумеется.  Плановый цикл повышения
пересобираемости сизифа -- 3 месяца.  За это время пакет либо чинится,
либо уходит в orphaned.  По предварительной оценке, сейчас не собираются
примерно 500 пакетов, т.е. почти 10% от общего числа (если же эти пакеты
удалить, то это не спасет положения, потому что по зависимостям
перестанут собираться другие пакеты и т.д.).

3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
последней платформы.  Это тоже немалый объем работ, который может занять
несколько месяцев.

> Согласно плану, уже серез неделю нас ожидает стадия Sync -- погоня за
> upstream и стабилизация. Очень хотелось бы, чтобы те, кто собпровождает
> библиотеки и особо крупных монстров (KDE, OOo и т. п.), начали
> задумываться об этом как можно раньше -- ведь от них зависит
> стабильность многих сотен пакетов.

Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
в такие сжатые сроки полноценной стабилизации и фриза не будет.

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

[devel] FreezePolicy

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> 3. Правила допуска обновлений пакета во время Freeze (в т. ч. и NMU)
>    http://wiki.sisyphus.ru/SisyphusRelease/FreezePolicy
>    Опять-таки, там написано. Чтобы потом не было разборок, надо договориться
>    сейчас.

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

Как ты себе это представляешь?  Какова процедура получения разрешения
у "пользователей пакета"?

Upstream-версии пакета тоже бывают разными.  Если у версии меняется
последняя цифра, то это, как правило, bugfix release.  Но это только
как правило.  И в других случаях тоже бывает по-разному.  Интуицию
maintainer'а пакета вряд ли стоит выносить на суд широкой публики.

Короче, это не похоже на формальный критерий.  Значит, нужен эксперт,
который будет вручную проверять поступающие пакеты и выносить
беспристрастные суждения.  А кто это будет делать?

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

Re: [devel] Стабильный Сизиф II

[Dmitry V. Levin]

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

On Wed, Aug 23, 2006 at 03:41:01PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> > Начинается подготовка к выпуску стабильного Сизифа.
> 
> Чтобы подготовка к выпуску стабильного сизифа стала вконец возможной,
> нужно также адресовать следующие проблемы:
> 
> 1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE и,
> возможно, что-то ещё.

Как минимум по умолчанию будет включено -D_FORTIFY_SOURCE=2 и
--hash-style=gnu, это не должно потребовать много усилий со стороны
ментейнеров по по исправлению своих пакетов.
Очень желательно включить по умолчанию -fstack-protector, хотя объём
работы по исправлению софта мне пока оценить сложно.
Что касается -fpie/-pie, то здесь объём работы оченить ещё сложнее, думаю
что мы не успеем к оченнему фризу.

> Речь даже шла о том, чтобы до начала более
> глубокого фриза пересобрать все бинарные пакеты новым toolchain'ом.

Ну так помогите мне, тогда новый toolchain будет готов раньше.

Готовность пакетов toolchain'а сейчас такая:
binutils - 100%
gcc - 90%
glibc - 10%
linux-libc-headers - не менее 50%
rpm-build - 99%

> 2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
> 9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
> какие нет.

Это будет исправлено.

> Готовиться к фризу в таком положении означает готовиться к
> худшему -- в надежде на лучшее, разумеется.  Плановый цикл повышения
> пересобираемости сизифа -- 3 месяца.

Это слишком долго.  Надо будет сосредоточиться и управиться за месяц.

> За это время пакет либо чинится,
> либо уходит в orphaned.  По предварительной оценке, сейчас не собираются
> примерно 500 пакетов, т.е. почти 10% от общего числа (если же эти пакеты
> удалить, то это не спасет положения, потому что по зависимостям
> перестанут собираться другие пакеты и т.д.).
> 
> 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку

Предусматривает, конечно.

> последней платформы.  Это тоже немалый объем работ, который может занять
> несколько месяцев.

Надеюсь что меньше.

> > Согласно плану, уже серез неделю нас ожидает стадия Sync -- погоня за
> > upstream и стабилизация. Очень хотелось бы, чтобы те, кто собпровождает
> > библиотеки и особо крупных монстров (KDE, OOo и т. п.), начали
> > задумываться об этом как можно раньше -- ведь от них зависит
> > стабильность многих сотен пакетов.
> 
> Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
> в такие сжатые сроки полноценной стабилизации и фриза не будет.

Придётся форсировать.


-- 
ldv

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

Re: [devel] Стабильный Сизиф II

[Igor Zubkov]

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

В сообщении от 23 августа 2006 13:53 Fr. Br. George написал(a):
> 2. Список актуальных пакетов и их пользователей.
>    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
>    Там, в общем, всё написано. Пакет, имеющий пользователя, который может
>    сказать "да, этот пакет работает" -- кандидат в выпуск. Пакет, не
> имеющий пользователей, попадёт туда на основании _отсутствия_ ошибок в bz.

>Пакты, которые вы сами сопровождаете, сюда писать тоже не надо (исключение: 
пакеты, которые и так всем нужны; такие пакеты заносятся в табличку «Пакеты, 
обязательно входящие в выпуск»).

Слишком расплывчатое определение "пакеты, которые и так всем нужны". К 
примеру, мне нужен phpMyAdmin, amarok, kmail, konqueror... А сомневаюсь, что 
amarok нужен _всем_. Тут нужен другой подход.

В debian перед релизом 3.1 собирали информацию (с разрешения пользователей) 
какие пакеты у них стоят. Может и нам так сделать? С этим я даже могу помочь. 
Скрипт в одну строку:
rpm --queryformat="%{NAME}\n" -qa | mail -s "all packages from my alt linux" 
icesik@altlinux.org

Это грязно, но работает. :)
Дальше, положить это всё в базу и собрать с неё статистику.

-- 
03 Чужой

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

Re: [devel] Стабильный Сизиф II

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 04:23:18PM +0400, Dmitry V. Levin wrote:
> > 1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE и,
> > возможно, что-то ещё.
> 
> Как минимум по умолчанию будет включено -D_FORTIFY_SOURCE=2 и
> --hash-style=gnu, это не должно потребовать много усилий со стороны
> ментейнеров по по исправлению своих пакетов.
> Очень желательно включить по умолчанию -fstack-protector, хотя объём
> работы по исправлению софта мне пока оценить сложно.

Новый toolchain никогда ещё пересобираемости не повышал.
Дело не только в количестве усилий, а также в том, удастся ли в сжатые
сроки приурочить активность maintainer'ов к сабжу.

> Ну так помогите мне, тогда новый toolchain будет готов раньше.

Я не специалист по toolchain'у.  Я могу помочь в других отношениях, но
см. ниже.

> > 2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
> > 9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
> > какие нет.
> 
> Это будет исправлено.
> 
> > Готовиться к фризу в таком положении означает готовиться к
> > худшему -- в надежде на лучшее, разумеется.  Плановый цикл повышения
> > пересобираемости сизифа -- 3 месяца.
> 
> Это слишком долго.  Надо будет сосредоточиться и управиться за месяц.

Проблема в том, что опять предстоит холодный старт.  А для
regression тестирования холодный старт это смерть.

> > 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
> Предусматривает, конечно.
> 
> > последней платформы.  Это тоже немалый объем работ, который может занять
> > несколько месяцев.
> Надеюсь что меньше.

И кто это будет делать?  Я готов помочь, но это предполагает
инфраструктурные изменения.  1) Ввести в incominger'е логику И вместо
ИЛИ для прохождения пакетов; 2) ввести в incominger'е проверку на потерю
NMU; 3) начать регулярные пересборки на x86_64, хотя бы для информации
(без статуса).

Фокус в том, что обсуждать инфраструктурные изменения либо уже поздно,
либо надо сдвигать фриз, либо ещё как-то изворачиваться.

> > Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
> > в такие сжатые сроки полноценной стабилизации и фриза не будет.
> Придётся форсировать.

Кто будет форсировать?  Князь Андрей Болконский? :)

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

Re: [devel] FreezePolicy

[Andrii Dobrovol`s`kii]

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

Alexey Tourbin пишет:
> On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
>> 3. Правила допуска обновлений пакета во время Freeze (в т. ч. и NMU)
>>    http://wiki.sisyphus.ru/SisyphusRelease/FreezePolicy
>>    Опять-таки, там написано. Чтобы потом не было разборок, надо договориться
>>    сейчас.
> 
> "Изменение upstream-версии пакета допускается только с разрешения
> пользователей пакета, если это связано с исправлением грубых ошибок"
> 
> Как ты себе это представляешь?  Какова процедура получения разрешения
> у "пользователей пакета"?
>  
Мне эта формулировка тоже кажется слишком замысловатой. Почему
просто не написать, что допускаются только исправления ошибок без
изменения API/ABI и функциональности.
А в период Sync уже есть возможность поменять почти всё. Я не думаю,
что за отведенный на заморозку месяц, в upstream успеют сильно уйти
вперед.
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************dobrATjabber.iop.kiev.ua************************


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

[devel] Uranus release management

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> 2. Список актуальных пакетов и их пользователей.
>    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages

http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8

"Поскольку очевидно, что подобный процесс (в некоторых кругах именуемый
Release Management :) не может организоваться сам собой, поглядывать за
ним и вовремя оповещать сообщество берусь я, Георгий Курячий. Я же беру
на себя и более сильную ответственность: в случае спорных и/или
конфликтных ситуаций (и только в них) последнее слово по этому выпуску --
за мной."

Э-э, а почему не за мной? :)  "Командовать парадом буду я".

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

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

Re: [devel] FreezePolicy

[Шенцев Алексей Владимирович]

В сообщении от 23 августа 2006 17:18 Andrii Dobrovol`s`kii написал(a):
> Alexey Tourbin пишет:
> > On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> >> 3. Правила допуска обновлений пакета во время Freeze (в т. ч. и NMU)
> >>    http://wiki.sisyphus.ru/SisyphusRelease/FreezePolicy
> >>    Опять-таки, там написано. Чтобы потом не было разборок, надо
> >> договориться сейчас.
> >
> > "Изменение upstream-версии пакета допускается только с разрешения
> > пользователей пакета, если это связано с исправлением грубых ошибок"
> >
> > Как ты себе это представляешь?  Какова процедура получения разрешения
> > у "пользователей пакета"?
>
> Мне эта формулировка тоже кажется слишком замысловатой. 
Не просто замысловатой, а не имеющей чёткой формализации. И мне совершенно не 
понятна. Да, я новичок в Alt Linux Team, но всё же.Привожу пример по пакету 
который я сейчас веду - Beesoft Commander. Фактически я его забрал у gns@ с 
его согласия, последняя его заливка опиралась на мои наработки, но это не 
суть важно. Дело в том, что автор программы сейчас переходит с Qt 3 (3.3.6) 
на Qt 4, и будет очень много кардинальных изменений в программе. Этой 
программой пользуюсь не один я. и как быть в таком случае, если сизиф 
заморожен, а есть новая версия программы? Или я что то не до понимаю?

-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] FreezePolicy

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 06:01:52PM +0400, Шенцев Алексей Владимирович wrote:
> > Мне эта формулировка тоже кажется слишком замысловатой. 
> Не просто замысловатой, а не имеющей чёткой формализации. И мне совершенно не 
> понятна. Да, я новичок в Alt Linux Team, но всё же.Привожу пример по пакету 
> который я сейчас веду - Beesoft Commander. Фактически я его забрал у gns@ с 
> его согласия, последняя его заливка опиралась на мои наработки, но это не 
> суть важно. Дело в том, что автор программы сейчас переходит с Qt 3 (3.3.6) 
> на Qt 4, и будет очень много кардинальных изменений в программе. Этой 
> программой пользуюсь не один я. и как быть в таком случае, если сизиф 
> заморожен, а есть новая версия программы? Или я что то не до понимаю?

Вот, например, cairo 1.2.4 release notes:
http://cairographics.org/news/cairo-1.2.4
Это срочный bugfix release, который было бы преступлением не пропускать
даже на стадии глубокого фриза.

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

С перлом же, с другой стороны, несколько труднее: это не исключительно
bugfix релизы, то есть количество мелких и не столь необходимых фиксов
дает качественно новую неуверенность (но есть, конечно, и критические
bugfix'ы).  5.8.6->5.8.7, 5.8.7->5.8.8 нужно внимательно тестировать.
Но масштаб сломавшегося обычно был небольшим; он обычно ясен после
первой же переcборки сизифа.

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

Re: [devel] FreezePolicy

[Andrei Bulava]

Alexey Tourbin wrote:
> On Wed, Aug 23, 2006 at 06:01:52PM +0400, Шенцев Алексей Владимирович wrote:
>>> Мне эта формулировка тоже кажется слишком замысловатой. 
>> Не просто замысловатой, а не имеющей чёткой формализации. И мне совершенно не 
>> понятна. Да, я новичок в Alt Linux Team, но всё же.Привожу пример по пакету 
>> который я сейчас веду - Beesoft Commander. Фактически я его забрал у gns@ с 
>> его согласия, последняя его заливка опиралась на мои наработки, но это не 
>> суть важно. Дело в том, что автор программы сейчас переходит с Qt 3 (3.3.6) 
>> на Qt 4, и будет очень много кардинальных изменений в программе. Этой 
>> программой пользуюсь не один я. и как быть в таком случае, если сизиф 
>> заморожен, а есть новая версия программы? Или я что то не до понимаю?
> 
> Вот, например, cairo 1.2.4 release notes:
> http://cairographics.org/news/cairo-1.2.4
> Это срочный bugfix release, который было бы преступлением не пропускать
> даже на стадии глубокого фриза.

И самое интересное, никто вам не помешает даже в глубоком анабиозе
Сизифа сваять патч на разницу между "замороженной версией" и любой
другой. Тут жёсткие формальные правила - только вызов пытливому уму
придумать, как их обойти. "Это же не наш метод!" (с)

Насколько уже упёртый в такие вещи RedHat, а и то уже не один раз поднял
upstream-версию MySQL в обновлениях к RHEL 4!

-- 
// AB1002-UANIC

Re: [devel] FreezePolicy

[Konstantin A. Lepikhov]

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

Hi Andrei!

Wednesday 23, at 05:33:15 PM you wrote:

> Alexey Tourbin wrote:
> > On Wed, Aug 23, 2006 at 06:01:52PM +0400, Шенцев Алексей Владимирович wrote:
> >>> Мне эта формулировка тоже кажется слишком замысловатой. 
> >> Не просто замысловатой, а не имеющей чёткой формализации. И мне совершенно не 
> >> понятна. Да, я новичок в Alt Linux Team, но всё же.Привожу пример по пакету 
> >> который я сейчас веду - Beesoft Commander. Фактически я его забрал у gns@ с 
> >> его согласия, последняя его заливка опиралась на мои наработки, но это не 
> >> суть важно. Дело в том, что автор программы сейчас переходит с Qt 3 (3.3.6) 
> >> на Qt 4, и будет очень много кардинальных изменений в программе. Этой 
> >> программой пользуюсь не один я. и как быть в таком случае, если сизиф 
> >> заморожен, а есть новая версия программы? Или я что то не до понимаю?
> > 
> > Вот, например, cairo 1.2.4 release notes:
> > http://cairographics.org/news/cairo-1.2.4
> > Это срочный bugfix release, который было бы преступлением не пропускать
> > даже на стадии глубокого фриза.
> 
> И самое интересное, никто вам не помешает даже в глубоком анабиозе
> Сизифа сваять патч на разницу между "замороженной версией" и любой
> другой. Тут жёсткие формальные правила - только вызов пытливому уму
> придумать, как их обойти. "Это же не наш метод!" (с)
> 
> Насколько уже упёртый в такие вещи RedHat, а и то уже не один раз поднял
> upstream-версию MySQL в обновлениях к RHEL 4!
а debian не поднял. А еще есть такие какашки как php, которые вообще не
ясно как фиксить, т.к. такие понятия как bugfix или release там вообще
неизвесны, все идет там в одной куче и отделить фиксы от фич там иногда не
представляется возможным.

-- 
WBR et al.

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

Re: [devel] FreezePolicy

[Alexey I. Froloff]

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

* Andrei Bulava <abulava@> [060823 18:33]:
> >>> Мне эта формулировка тоже кажется слишком замысловатой. 
> Насколько уже упёртый в такие вещи RedHat, а и то уже не один раз поднял
> upstream-версию MySQL в обновлениях к RHEL 4!
Ну в общем коллективный разум признал сущность, именуемую
"версия", не имеющей никакого смысла, а потому в природе не
существующей.  Изменения API/ABI (частично) контролируются
роботами, как контролировать изменение функционала в пакетах, не
предоставляющих API, типа KDE?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] FreezePolicy

[Alexey I. Froloff]

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

* Konstantin A. Lepikhov <lakostis@> [060823 18:40]:
> А еще есть такие какашки как php, которые вообще не ясно как
> фиксить, т.к. такие понятия как bugfix или release там вообще
> неизвесны, все идет там в одной куче и отделить фиксы от фич
> там иногда не представляется возможным.
От подобных какашек никто в сизифе не зависит (в том смысле что
php-* - это "листья" дерева зависимостей) и автоматическому
тестированию такие поделия не поддаются.  Пусть живут дальше
своей уродливой жизнью со статусом "unsupported".  Невменяемость
апстрима к сожалению не лечится фризами в "каком-то ALT Linux"...
Можно только уповать на опыт и квалификацию мантейнера подобного
кривософта.

P.S. Да, я тоже ненавижу php.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] Uranus release management

[Dmitry V. Levin]

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

On Wed, Aug 23, 2006 at 05:49:25PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> > 2. Список актуальных пакетов и их пользователей.
> >    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
> 
> http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8
> 
> "Поскольку очевидно, что подобный процесс (в некоторых кругах именуемый
> Release Management :) не может организоваться сам собой, поглядывать за
> ним и вовремя оповещать сообщество берусь я, Георгий Курячий. Я же беру
> на себя и более сильную ответственность: в случае спорных и/или
> конфликтных ситуаций (и только в них) последнее слово по этому выпуску --
> за мной."
> 
> Э-э, а почему не за мной? :)  "Командовать парадом буду я".

Потому что он первым вызвался. :)


-- 
ldv

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

Re: [devel] Uranus release management

[Alexey Tourbin]

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

On Wed, Aug 23, 2006 at 07:23:31PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 23, 2006 at 05:49:25PM +0400, Alexey Tourbin wrote:
> > On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> > > 2. Список актуальных пакетов и их пользователей.
> > >    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
> > 
> > http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8
> > 
> > "Поскольку очевидно, что подобный процесс (в некоторых кругах именуемый
> > Release Management :) не может организоваться сам собой, поглядывать за
> > ним и вовремя оповещать сообщество берусь я, Георгий Курячий. Я же беру
> > на себя и более сильную ответственность: в случае спорных и/или
> > конфликтных ситуаций (и только в них) последнее слово по этому выпуску --
> > за мной."
> > 
> > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
> 
> Потому что он первым вызвался. :)

Разруливать кофликты -- это не то же самое, что оповещать сообщество и
координировать работу.  Разруливать конфликты в team -- это не только
ответственность, но и прежде всего право.  Никто такого права Гоше не
давал.  Но я и вообще не думаю, что кто-то один должен разруливать
кофликты.

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

Re: [devel] Uranus release management

[Dmitry V. Levin]

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

On Wed, Aug 23, 2006 at 07:32:18PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 23, 2006 at 07:23:31PM +0400, Dmitry V. Levin wrote:
> > On Wed, Aug 23, 2006 at 05:49:25PM +0400, Alexey Tourbin wrote:
> > > On Wed, Aug 23, 2006 at 02:53:06PM +0400, Fr. Br. George wrote:
> > > > 2. Список актуальных пакетов и их пользователей.
> > > >    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
> > > 
> > > http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8
> > > 
> > > "Поскольку очевидно, что подобный процесс (в некоторых кругах именуемый
> > > Release Management :) не может организоваться сам собой, поглядывать за
> > > ним и вовремя оповещать сообщество берусь я, Георгий Курячий. Я же беру
> > > на себя и более сильную ответственность: в случае спорных и/или
> > > конфликтных ситуаций (и только в них) последнее слово по этому выпуску --
> > > за мной."
> > > 
> > > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
> > 
> > Потому что он первым вызвался. :)
> 
> Разруливать кофликты -- это не то же самое, что оповещать сообщество и
> координировать работу.  Разруливать конфликты в team -- это не только
> ответственность, но и прежде всего право.  Никто такого права Гоше не
> давал.  Но я и вообще не думаю, что кто-то один должен разруливать
> кофликты.

Я думаю, что в случае необходимости мы ему поможем.


-- 
ldv

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

Re: [devel] Стабильный Сизиф II

[Fr. Br. George]

On Wed, Aug 23, 2006 at 03:41:01PM +0400, Alexey Tourbin wrote:
> 1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE
Насколько это её улучшит в плане стабильности?

> 2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
> 9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
> какие нет.
Разумеется. Сейчас ведутся работы по восстановлению регулярности пересборок.

> 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
> последней платформы.  Это тоже немалый объем работ, который может занять
> несколько месяцев.
Выпуск нужен в этом году. Пока по x86_64 ситуация такая: если установщик
будет поддерживать x86_64, будет и выпуск на x86_64, состоящий из
собирающихся пакетов. Не думаю, что в ближайший год мы сможем
организовать эффективное _тестирование_ сколь-нибудь обширной пакетной
базы на x86_64. Какой-то минимум оттестирован будет.

Про "рассинхронизацию" i586 и x86_64 поподробнее можно?

> Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
> в такие сжатые сроки полноценной стабилизации и фриза не будет.
Не будет. Но если её сейчас не сделать, через полгода в такие же сжатые
сроки она будет ещё менее полноценной. А закладывать на _заморозку_
сильно больше полутора месяцев -- невозможно.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] FreezePolicy

[Fr. Br. George]

On Wed, Aug 23, 2006 at 04:10:08PM +0400, Alexey Tourbin wrote:
> "Изменение upstream-версии пакета допускается только с разрешения
> пользователей пакета, если это связано с исправлением грубых ошибок"
> 
> Как ты себе это представляешь?  Какова процедура получения разрешения
> у "пользователей пакета"?
Убедил. Исправлено.

> Короче, это не похоже на формальный критерий.  Значит, нужен эксперт,
> который будет вручную проверять поступающие пакеты и выносить
> беспристрастные суждения.  А кто это будет делать?
Формальный критерий, как показывает практика написания policy, выходит
монструозный и малопонятный. Вопрос в том, что больше нужно: сходящийся
процесс или бесконечные беспристрастные суждения, в беспристрастность
которых всё равно кто-нибудь, да не поверит.

Я не думаю, что эта часть создаст нам много проблем, если только
кто-либо из нас не займётся их выдумыванием. Предполагается, что на
этапе freeze каждый добивается стбильности, а не фичастости. Если
найдётся кто-то, кто на это наплюёт, и со словами "я поправли жуткую
багу" вольёт в Сизиф вместо fooo.2.7 -- foo.3.0.beta, что ж, будет плохо
пользователям его пакетов. Никаких средств, да и желания, как-то
_принуждать_ кого-либо, у нас нет.

Но неповышение версии как _неформальный_ критерий себя оправдывает.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] FreezePolicy

[Fr. Br. George]

On Wed, Aug 23, 2006 at 06:41:17PM +0400, Alexey I. Froloff wrote:
> * Andrei Bulava <abulava@> [060823 18:33]:
> > >>> Мне эта формулировка тоже кажется слишком замысловатой. 
> > Насколько уже упёртый в такие вещи RedHat, а и то уже не один раз поднял
> > upstream-версию MySQL в обновлениях к RHEL 4!
> Ну в общем коллективный разум признал сущность, именуемую
> "версия", не имеющей никакого смысла, а потому в природе не
> существующей.  Изменения API/ABI (частично) контролируются
> роботами, как контролировать изменение функционала в пакетах, не
> предоставляющих API, типа KDE?
Ну так _контролировать_ никто никого не собирается: с какой стати? Что
же касается несуществования в природе сущности по имени "версия"...
если поднапрячься, можно вспомнить, что у некоторых пакетов мы её
всё-таки иногда наблюдаем?

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Стабильный Сизиф II

[Alexey Tourbin]

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

On Fri, Aug 25, 2006 at 03:32:43PM +0400, Fr. Br. George wrote:
> > 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
> > последней платформы.  Это тоже немалый объем работ, который может занять
> > несколько месяцев.
> Выпуск нужен в этом году. Пока по x86_64 ситуация такая: если установщик
> будет поддерживать x86_64, будет и выпуск на x86_64, состоящий из
> собирающихся пакетов. Не думаю, что в ближайший год мы сможем
> организовать эффективное _тестирование_ сколь-нибудь обширной пакетной
> базы на x86_64. Какой-то минимум оттестирован будет.
> 
> Про "рассинхронизацию" i586 и x86_64 поподробнее можно?

Сейчас пакет проходит в репозитарий, если он собрался для i586 ИЛИ
для x86_64.  Т.е. фактически это независимое прохождение для каждой
архитекутры отдельно.

$ comm -12 <(ls i586/SRPMS.classic) <(ls x86_64/SRPMS.classic) |wc -l
2858
$ comm -23 <(ls i586/SRPMS.classic) <(ls x86_64/SRPMS.classic)
AVLTree-devel-0.1.3-alt4.src.rpm
AutoScan-0.99-alt0.1.src.rpm
ElectricFence-2.2.2-alt0.1.src.rpm
FaxMail-2.3-ipl9mdk.src.rpm
LinNeighborhood-0.6.5-alt6.src.rpm
MPlayer-1.0-alt26.20060823.src.rpm
Pcsx-1.5-alt3.src.rpm
PyPanel-2.4-alt1.src.rpm
Pymacs-0.22-alt1.src.rpm
R-base-2.3.1-alt1.src.rpm
Refal-5-000925-alt1.src.rpm
SearchAndRescue-0.8.2-alt2.1.src.rpm
Terminal-0.2.4-alt1.1.1.src.rpm
Xbae-4.60.2-alt1.src.rpm
Zope-2.7.7-alt1.src.rpm
a2ps-4.13-alt2.src.rpm
airsnort-0.2.7e-alt1.src.rpm
ams-1.8.7-alt0.6.src.rpm
anjuta2-2.0.2-alt1.src.rpm
anketdb-1.1-alt2.src.rpm
apachetop-0.12.6-alt1.src.rpm
apmd-3.2.2-alt2.src.rpm
apollon-1.0.2.1-alt2.src.rpm
aqbanking-2.0.0-alt0.1.src.rpm
asterisk-op_panel-0.26-alt2.src.rpm
asterisk1.3-1.3.0-alt1.svn20060818.src.rpm
asterisk1.3-1.3.0-alt1.svn20060820.src.rpm
asterisk1.3-addon-modules-1.3.13-alt1.svn20060818.src.rpm
asterisk1.3-addon-modules-1.3.13-alt1.svn20060820.src.rpm
asterisk1.3-addons-1.3.0-alt1.20060812.src.rpm
asterisk1.3-addons-1.3.0-alt1.20060818.src.rpm
asterisk1.3-addons-1.3.0-alt1.20060820.src.rpm
asterisk1.3-app_conference-1.3.0-alt1.20060818.src.rpm
asterisk1.3-app_conference-1.3.0-alt1.20060820.src.rpm
astmanproxy-1.22-alt0.pre.20060812.src.rpm
astmanproxy-1.22-alt0.pre.20060818.src.rpm
astmanproxy-1.22-alt0.pre.20060820.src.rpm
atanks-1.1.0-alt2.src.rpm
autopano-sift-2.4-alt1.src.rpm
autospeedstep-0.2-alt1.src.rpm
awesfx-0.5.0-alt1d.src.rpm
barcode-0.98-alt2.src.rpm
bazaar-1.4.2-alt1.src.rpm
bbconf-1.10-alt1.src.rpm
beep-alarm-0.6.0-alt1.1.src.rpm
beep-visualization-libvisual-0.2.0-alt1.src.rpm
bibletime-1.5.3-alt2.src.rpm
bibletime-i18n-1.5.3-alt1.src.rpm
bibtex2html-1.54-alt1.src.rpm
biew-5.6.2-alt1.src.rpm
billardgl-1.75-alt5.src.rpm
bk-20041117-alt1.src.rpm
bloom-0.1.1-alt1.src.rpm
bluez-utils-3.3-alt1.src.rpm
bmon-2.1.0-alt1.src.rpm
bugsquish-0.0.6-alt1.src.rpm
camltemplate-0.9.1-alt1.src.rpm
captive-1.1.7-alt3.src.rpm
cdl3-1.2.4-alt1.src.rpm
centericq-4.21.0-alt2.src.rpm
checkinstall-1.6.0-alt2.src.rpm
cheesetracker-0.9.9-alt3.src.rpm
chipmunk-5.61-alt4.src.rpm
chromium-0.9.12-alt8.src.rpm
cinelerra-1.2.2-alt7.src.rpm
circuslinux-1.0.3-alt4.src.rpm
clalsadrv-1.0.0-alt1.1.src.rpm
clip-prg-1.1.15-alt0.1.src.rpm
cmake-2.4.3-alt2.src.rpm
cmt-1.15-alt1.1.src.rpm
collectd-3.9.3-alt1.src.rpm
cpuburn-1.4-alt4.src.rpm
d1x-1.43-alt1.src.rpm
darcs-1.0.5-alt1.src.rpm
dasher-3.99.4-alt0.1.src.rpm
datefudge-1.12-alt2.src.rpm
ddcxinfo-knoppix-0.6-alt2.src.rpm
defendguin-0.0.10-alt1.src.rpm
digikam-0.8.1-alt1.src.rpm
digikam-doc-0.8.0-alt1.src.rpm
dirdiff-2.1-alt2.src.rpm
dirmngr-0.9.3-alt1.1.src.rpm
dissy-1-alt0.1.src.rpm
divxcalc-0.5.1-alt1.src.rpm
dosemu-1.3.2-alt4.src.rpm
drawswf-1.2.7-alt1.src.rpm
driconf-0.9.0-alt1.1.src.rpm
dssi-0.4-alt1.1.src.rpm
dssi-plugins-xsynth-0.1.0-alt1.src.rpm
dvdrip-0.97.6-alt1.src.rpm
dvr-3.2-alt1.src.rpm
dxsamples-4.3.2-alt3.src.rpm
eas-0.1.2-alt0.2v20050207.src.rpm
ecamegapedal-0.4.4-alt1.3.src.rpm
ecasound-2.4.4-alt1.src.rpm
eclipse-3.1.1-alt2.src.rpm
ecore-0.9.9.026-alt1.20060412.src.rpm
eflite-0.3.9-alt1.src.rpm
eggdrop-1.6.17-alt2.src.rpm
ekiga-2.0.1-alt0.2cvs20060520.src.rpm
etherape-0.9.2-alt1.src.rpm
etherboot-5.4.2-alt0.2.src.rpm
evas-0.9.9.026-alt1.20060412.src.rpm
evince-0.5.2-alt0.1.src.rpm
ext2ed-0.2-alt1.1.src.rpm
f-spot-0.1.11-alt1.src.rpm
fceultra-0.98.13-alt1.src.rpm
fftv-0.8.3-alt0.1.src.rpm
fidoconf-1.9.0-alt1.20040614.src.rpm
file-roller-2.14.3-alt1.src.rpm
fmio-2.0.8-alt1.src.rpm
foobillard-3.0-alt1.a.src.rpm
freemind-0_8_0-alt0.1.src.rpm
freewrl-1.08-alt1.src.rpm
frox-0.7.18-alt1.src.rpm
frozen-bubble-1.0.0-alt5.src.rpm
fsmd-0.5-alt2.src.rpm
fsme-1.0.2-alt3.src.rpm
fuse-encfs-1.3.1-alt1.src.rpm
fuse-siefs-0.5-alt5.src.rpm
gaim-guifications-2.12-alt1.src.rpm
gaim-latex-0.3-alt2.src.rpm
gaim-osd-0.6-alt1.src.rpm
gcc2.95-2.95.3-alt7.src.rpm
gcc2.96-2.96-alt7.src.rpm
gedit-2.14.3-alt1.src.rpm
gfax-0.7.4-alt0.1cvs20051223.src.rpm
ghc-6.4.2-alt1.src.rpm
gift-0.11.8-alt3.src.rpm
gift-plugin-ares-0.2.2-alt1.src.rpm
gift-plugin-fasttrack-0.8.9-alt2.src.rpm
gift-plugin-gnutella-0.0.10.0-alt1.src.rpm
gift-plugin-openft-0.2.1.6-alt1.1.src.rpm
gift-plugin-opennap-0.0.1-alt0.cvs20031205.src.rpm
giftui-0.4.2-alt0.cvs20050108.src.rpm
gimp-gap-2.0.2-alt2.src.rpm
gimp2-perl-2.2-alt0.2.src.rpm
gkrellm-aclock-0.3.2-alt3.src.rpm
gkrellm-alltraxclock2-0.2-alt1.src.rpm
gkrellm-countdown-0.1.1-alt2.src.rpm
gkrellm-gift-0.2.2-alt2.src.rpm
gkrellm-gkrelldnet-0.14.2-alt1.src.rpm
gkrellm-gkrellmms-2.1.22-alt1.src.rpm
gkrellm-gkrellmpc-0.1_beta10-alt1.src.rpm
gkrellm-gkrelltop-2.2.6-alt1.src.rpm
gkrellm-gtodo-0.2.4-alt1.src.rpm
gkrellm-hddtemp-0.2-alt0.32.src.rpm
gkrellm-kam-2.0.0-alt3.src.rpm
gkrellm-launch-0.5-alt3.src.rpm
gkrellm-mailwatch-2.4.2-alt1.src.rpm
gkrellm-moon-0.6-alt3.src.rpm
gkrellm-radio-2.0.4-alt1.src.rpm
gkrellm-reminder-2.0.0-alt2.src.rpm
gkrellm-shoot-0.4.1-alt3.src.rpm
gkrellm-ss-2.6-alt1.src.rpm
gkrellm-sun-0.10.6-alt2.src.rpm
gkrellm-timers-1.2-alt3.src.rpm
gkrellm-timestamp-0.1.4-alt2.src.rpm
gkrellm-volume-2.1.13-alt1.src.rpm
gkrellm-weather-2.0.6-alt1.src.rpm
gkrellm-webmon-0.2-alt2.src.rpm
gkrellm-xkb-1.05-alt2.src.rpm
glade-0.6.4-alt3.src.rpm
glaxium-0.5-alt3.src.rpm
gmorgan-0.25-alt1.src.rpm
gnome-applets-2.14.2-alt2.src.rpm
gnome-applets-extra-hardware-monitor-1.3-alt2.src.rpm
gnome-applets-extra-lock-keys-1.0-alt1.1.src.rpm
gnome-applets-extra-netspeed-0.11-alt1.src.rpm
gnome-applets-extra-netstatus-2.10.0-alt1.src.rpm
gnome-applets-extra-teatime-2.6.0-alt2.src.rpm
gnome-applets-gswitchit-plugins-0.5-alt1.src.rpm
gnome-commander-1.1.6-alt2.src.rpm
gnome-control-center-2.14.2-alt2.src.rpm
gnome-media-2.14.2-alt3.src.rpm
gnome-utils-2.14.0-alt1.src.rpm
gnome-volume-manager-1.5.15-alt2.src.rpm
gnormalize-0.49-alt0.1.src.rpm
gnustep-base-1.11.1-alt0.1.src.rpm
gnustep-extensions-0.8.6-alt0.1.src.rpm
gogo-3.13-alt1.src.rpm
grace-5.1.20-alt1.src.rpm
gramps-2.1.90-alt0.1.src.rpm
grub-0.97-alt2.src.rpm
gst-ffmpeg-0.10.1-alt2.src.rpm
gst-plugins-bad-0.10.3-alt2.src.rpm
gst-plugins-good-0.10.3-alt2.src.rpm
gst-plugins-ugly-0.10.3-alt1.src.rpm
gst-polyp-0.9.0-alt1.src.rpm
gtk-engines-cleanice-2.4.0-alt1.src.rpm
gtk-engines-dwerg-0.5-alt1.src.rpm
gtk-engines-wonderland-1.0-alt1.src.rpm
gtk-qt-engine-0.7-alt0.1cvs.src.rpm
gtk2hs-0.9.10-alt2.src.rpm
gtkgep-0.2.3-alt2.src.rpm
gtkstep-2.2-alt4.src.rpm
guarddog-2.4.0-alt1.src.rpm
guile-gnome-platform-2.7.99-alt3.src.rpm
guile14-1.4.1.106-alt1.1.src.rpm
hardinfo-0.4.1-alt0.1.src.rpm
heroes-sdl-0.21-alt0.1.src.rpm
hevea-1.07-alt2.src.rpm
hk_classes-0.8.1a-alt3.src.rpm
hplip-1.6.6a-alt4.src.rpm
hpt-1.9.0-alt1.20040614.src.rpm
ht-0.9.2-alt1.src.rpm
htdig-3.1.6-alt1.1.1.src.rpm
husky-tools-1.9.0-alt1.20040614.src.rpm
hwsetup-1.0-alt3.src.rpm
hydra-4.7-alt1.src.rpm
hydrogen-0.9.3-alt1.src.rpm
i386-mingw32msvc-libflex-2.5.4a-ipl17alt.src.rpm
ical-2.3.1-alt2.1.src.rpm
icebreaker-1.9.5-alt1.src.rpm
iching-0.2-alt3.src.rpm
icukrell-2.0.0-alt2_pre0.1.src.rpm
idcpu-1.0-alt1.src.rpm
inkscape-0.44-alt0.1.src.rpm
ipw3945d-1.7.18-alt2.src.rpm
iquicklauncher-0.1-alt1.src.rpm
ircd-1.0.7-alt5.02.src.rpm
isapnptools-1.26-alt3.src.rpm
isdn4k-utils-3.2p1-alt3.src.rpm
ispell-fr-1.0-ipl15mdk.src.rpm
ispell-ru-rk-1.1-alt5.src.rpm
ispell-uk-0.7-alt1.src.rpm
j2se1.3-sun-1.3.1_18-alt1.src.rpm
j2se1.4-sun-1.4.2_10-alt2.src.rpm
jai-1.1.2-alt1.src.rpm
jakarta-bsf-2.3.0-alt0.1rc1.src.rpm
jamin-0.95.0-alt0.5beta6.src.rpm
jcommon-1.0.0-alt0.1pre2.src.rpm
jed-0.99.16-alt2.src.rpm
jfreechart-1.0.0-alt0.1pre2.src.rpm
jneural-1.05-alt1.1.src.rpm
jpeg-mmx-0.1.6-alt4.src.rpm
jpilot-0.99.9-alt4.pre2.src.rpm
kaconnect-1.1.1-alt0.5.1.src.rpm
kaffeine-0.8.2-alt0.1.beta1.src.rpm
kamix-0.6.5-alt1.src.rpm
kasablanca-0.4.0.2-alt1.src.rpm
kasound-0.5-alt1.b.src.rpm
kbiff-3.8-alt1.src.rpm
kblticker-0.2.1-alt2.src.rpm
kbudget-0.6-alt1.src.rpm
kccmp-0.2-alt1.src.rpm
kcemirror-0.1.4-alt2.src.rpm
kcheckgmail-0.5.3a-alt1.src.rpm
kchm-0.6.5-alt1.src.rpm
kconfigure-2.1-alt2.src.rpm
kcpuload-1.99-alt4.src.rpm
kde-styles-activeheart-kwin-1.1-alt2.src.rpm
kde-styles-activeheart-widgets-1.2.1-alt3.src.rpm
kde-styles-alloy-0.5.3-alt1.src.rpm
kde-styles-comix-1.3.7-alt1.src.rpm
kde-styles-lipstik-2.2-alt1.src.rpm
kde-styles-painting-desktop-0.5.1-alt0.1.src.rpm
kde-styles-polyester-0.7-alt1.src.rpm
kde-styles-softcrystal-widgets-1.0-alt2.src.rpm
kde-styles-thinkeramik-3.2.1-alt2.src.rpm
kde-styles-widgets-tiblit-1.2-alt2.src.rpm
kdissert-1.0.4-alt1.src.rpm
kernel-image-rt26-up-2.6.16-alt1.src.rpm
kernel-image-std-smp-2.4.32-alt1.src.rpm
kernel-image-std-up-2.4.32-alt1.src.rpm
kernel-modules-3c90x-std-smp-1.0.2-alt14.132128.1.src.rpm
kernel-modules-3c90x-std-up-1.0.2-alt14.132128.1.src.rpm
kernel-modules-aksparlnx-std26-up-1.6-alt1.5.src.rpm
kernel-modules-alsa-std-smp-1.0.10-alt5.132128.1.src.rpm
kernel-modules-alsa-std-up-1.0.10-alt5.132128.1.src.rpm
kernel-modules-amedyn-std-smp-20040801-alt6.132128.1.src.rpm
kernel-modules-amedyn-std-up-20040801-alt6.132128.1.src.rpm
kernel-modules-areca-ovz-smp-1.20.0X.13-alt1.132624.3.src.rpm
kernel-modules-areca-std26-smp-1.20.0X.13-alt1.132624.9.src.rpm
kernel-modules-areca-std26-up-1.20.0X.13-alt1.132624.9.src.rpm
kernel-modules-areca-vs26-smp-1.20.0X.13-alt1.132624.8.src.rpm
kernel-modules-areca-wks26-smp-1.20.0X.13-alt1.132624.8.src.rpm
kernel-modules-areca-wks26-up-1.20.0X.13-alt1.132624.8.src.rpm
kernel-modules-at76c503-std-smp-0.11-alt1.132128.1.src.rpm
kernel-modules-at76c503-std-up-0.11-alt1.132128.1.src.rpm
kernel-modules-bcm5700-std-smp-7.3.5-alt2.132128.1.src.rpm
kernel-modules-bcm5700-std-up-7.3.5-alt2.132128.1.src.rpm
kernel-modules-cdfs-ovz-smp-2.6.12-alt1.132624.3.src.rpm
kernel-modules-cdfs-std-smp-2.6.12-alt1.132128.1.src.rpm
kernel-modules-cdfs-std-up-2.6.12-alt1.132128.1.src.rpm
kernel-modules-cdfs-std26-smp-2.6.12-alt1.132624.9.src.rpm
kernel-modules-cdfs-std26-up-2.6.12-alt1.132624.9.src.rpm
kernel-modules-cdfs-vs26-smp-2.6.12-alt1.132624.8.src.rpm
kernel-modules-cdfs-wks26-smp-2.6.12-alt1.132624.8.src.rpm
kernel-modules-cdfs-wks26-up-2.6.12-alt1.132624.8.src.rpm
kernel-modules-cifs-std-smp-1.20-alt1.132128.1.src.rpm
kernel-modules-cifs-std-up-1.20-alt1.132128.1.src.rpm
kernel-modules-cloop-ovz-smp-2.01-alt7.132624.3.src.rpm
kernel-modules-cloop-std-smp-2.01-alt7.132128.1.src.rpm
kernel-modules-cloop-std-up-2.01-alt7.132128.1.src.rpm
kernel-modules-cloop-std26-smp-2.01-alt7.132624.9.src.rpm
kernel-modules-cloop-std26-up-2.01-alt7.132624.9.src.rpm
kernel-modules-cloop-vs26-smp-2.01-alt7.132624.8.src.rpm
kernel-modules-cloop-wks26-smp-2.01-alt7.132624.8.src.rpm
kernel-modules-cloop-wks26-up-2.01-alt7.132624.8.src.rpm
kernel-modules-comedi-std-smp-0.7.70-alt1.132128.1.src.rpm
kernel-modules-comedi-std-up-0.7.70-alt1.132128.1.src.rpm
kernel-modules-dc395-std-smp-141-alt9.132128.1.src.rpm
kernel-modules-dc395-std-up-141-alt9.132128.1.src.rpm
kernel-modules-drbd-std-smp-0.7.20-alt1.132128.1.src.rpm
kernel-modules-drbd-std-up-0.7.20-alt1.132128.1.src.rpm
kernel-modules-drm-std-smp-2005.11.18-alt3.132128.1.src.rpm
kernel-modules-drm-std-up-2005.11.18-alt3.132128.1.src.rpm
kernel-modules-drm-via-std-smp-2004.06.24-alt4.132128.1.src.rpm
kernel-modules-drm-via-std-up-2004.06.24-alt4.132128.1.src.rpm
kernel-modules-dvb-std-smp-20031013-alt7.132128.1.src.rpm
kernel-modules-dvb-std-up-20031013-alt7.132128.1.src.rpm
kernel-modules-em8300-std-smp-1.0.0.13.0.cvs-alt9.132128.1.src.rpm
kernel-modules-em8300-std-up-1.0.0.13.0.cvs-alt9.132128.1.src.rpm
kernel-modules-fglrx-std-smp-1.0.8.27.10-alt1.132128.1.src.rpm
kernel-modules-fglrx-std-up-1.0.8.27.10-alt1.132128.1.src.rpm
kernel-modules-fpix-ovz-smp-20060106-alt2.132624.3.src.rpm
kernel-modules-fpix-std26-smp-svn.r75-alt1.132624.9.src.rpm
kernel-modules-fpix-std26-up-svn.r75-alt1.132624.9.src.rpm
kernel-modules-fpix-vs26-smp-svn.r75-alt1.132624.8.src.rpm
kernel-modules-fpix-wks26-smp-svn.r75-alt1.132624.8.src.rpm
kernel-modules-fpix-wks26-up-svn.r75-alt1.132624.8.src.rpm
kernel-modules-fuse-std-smp-2.4.2-alt1.132128.1.src.rpm
kernel-modules-fuse-std-up-2.4.2-alt1.132128.1.src.rpm
kernel-modules-gatos_km-std-smp-20050716-alt2.132128.1.src.rpm
kernel-modules-gatos_km-std-up-20050716-alt2.132128.1.src.rpm
kernel-modules-hcfpcimodem-std-smp-0.99mbsibeta02123100-alt8.132128.1.src.rpm
kernel-modules-hcfpcimodem-std-up-0.99mbsibeta02123100-alt8.132128.1.src.rpm
kernel-modules-hostap-std-smp-0.4.7-alt1.132128.1.src.rpm
kernel-modules-hostap-std-up-0.4.7-alt1.132128.1.src.rpm
kernel-modules-hpt-std-smp-2004.12.26-alt1.132128.1.src.rpm
kernel-modules-hpt-std-up-2004.12.26-alt1.132128.1.src.rpm
kernel-modules-hsflinmodem-std-smp-5.03.27mbsibeta02122600-alt8.132128.1.src.rpm
kernel-modules-hsflinmodem-std-up-5.03.27mbsibeta02122600-alt8.132128.1.src.rpm
kernel-modules-intel-537-std-smp-2.27.39.0-alt7.132128.1.src.rpm
kernel-modules-intel-537-std-up-2.27.39.0-alt7.132128.1.src.rpm
kernel-modules-intel536ep-std-smp-4.62-alt10.132128.1.src.rpm
kernel-modules-intel536ep-std-up-4.62-alt10.132128.1.src.rpm
kernel-modules-ipw3945-wks26-up-1.0.5-alt1.132624.7.src.rpm
kernel-modules-kqemu-std-smp-0.7.2-alt3.132128.1.src.rpm
kernel-modules-kqemu-std-up-0.7.2-alt3.132128.1.src.rpm
kernel-modules-lirc-std-smp-1.0.0.8.0-alt1.132128.1.src.rpm
kernel-modules-lirc-std-up-1.0.0.8.0-alt1.132128.1.src.rpm
kernel-modules-lm_sensors-std-smp-2.9.2-alt1.132128.1.src.rpm
kernel-modules-lm_sensors-std-up-2.9.2-alt1.132128.1.src.rpm
kernel-modules-ltmodem-std-smp-8.26a9-alt12.132128.1.src.rpm
kernel-modules-ltmodem-std-up-8.26a9-alt12.132128.1.src.rpm
kernel-modules-ltmodem-std26-smp-8.26a9-alt12.132624.9.src.rpm
kernel-modules-ltmodem-std26-up-8.26a9-alt12.132624.9.src.rpm
kernel-modules-ltmodem-vs26-smp-8.26a9-alt12.132624.3.src.rpm
kernel-modules-ltmodem-wks26-smp-8.26a9-alt13.132624.8.src.rpm
kernel-modules-ltmodem-wks26-up-8.26a9-alt13.132624.8.src.rpm
kernel-modules-lufs-std-smp-0.9.7captive8-alt6.132128.1.src.rpm
kernel-modules-lufs-std-up-0.9.7captive8-alt6.132128.1.src.rpm
kernel-modules-madwifi-std-smp-0.9.4.5-alt1.132128.1.src.rpm
kernel-modules-madwifi-std-up-0.9.4.5-alt1.132128.1.src.rpm
kernel-modules-matroxdriver-ovz-smp-1.4.4.2-alt1.132624.4.src.rpm
kernel-modules-matroxdriver-std-smp-1.4.4.2-alt1.132128.1.src.rpm
kernel-modules-matroxdriver-std-up-1.4.4.2-alt1.132128.1.src.rpm
kernel-modules-matroxdriver-std26-smp-1.4.4.2-alt1.132624.9.src.rpm
kernel-modules-matroxdriver-std26-up-1.4.4.2-alt1.132624.9.src.rpm
kernel-modules-matroxdriver-vs26-smp-1.4.4.2-alt1.132624.8.src.rpm
kernel-modules-matroxdriver-wks26-smp-1.4.4.2-alt1.132624.8.src.rpm
kernel-modules-matroxdriver-wks26-up-1.4.4.2-alt1.132624.8.src.rpm
kernel-modules-nvidia-nforce-std-smp-1.0.0261-alt16.132128.1.src.rpm
kernel-modules-nvidia-nforce-std-up-1.0.0261-alt16.132128.1.src.rpm
kernel-modules-nvidia-std-smp-1.0.7676-alt1.132128.1.src.rpm
kernel-modules-nvidia-std-up-1.0.7676-alt1.132128.1.src.rpm
kernel-modules-pctel-std-smp-0.9.6-alt22.132128.1.src.rpm
kernel-modules-pctel-std-up-0.9.6-alt22.132128.1.src.rpm
kernel-modules-pentanet-std-smp-2.3.1-alt11.132128.1.src.rpm
kernel-modules-pentanet-std-up-2.3.1-alt11.132128.1.src.rpm
kernel-modules-ppscsi-std-smp-2001.03.21-alt5.132128.1.src.rpm
kernel-modules-ppscsi-std-up-2001.03.21-alt5.132128.1.src.rpm
kernel-modules-promise-std-smp-2004.12.26-alt1.132128.1.src.rpm
kernel-modules-promise-std-up-2004.12.26-alt1.132128.1.src.rpm
kernel-modules-qla2x00-std-smp-7.03.00-alt1.132128.1.src.rpm
kernel-modules-qla2x00-std-up-7.03.00-alt1.132128.1.src.rpm
kernel-modules-qvm86-ovz-smp-20050904-alt2.132624.4.src.rpm
kernel-modules-qvm86-std-smp-20050904-alt2.132128.1.src.rpm
kernel-modules-qvm86-std-up-20050904-alt2.132128.1.src.rpm
kernel-modules-qvm86-std26-smp-20050904-alt2.132624.9.src.rpm
kernel-modules-qvm86-std26-up-20050904-alt2.132624.9.src.rpm
kernel-modules-qvm86-vs26-smp-20050904-alt2.132624.8.src.rpm
kernel-modules-qvm86-wks26-smp-20050904-alt2.132624.8.src.rpm
kernel-modules-qvm86-wks26-up-20050904-alt2.132624.8.src.rpm
kernel-modules-slicoss-std-smp-1.2.0-alt10.132128.1.src.rpm
kernel-modules-slicoss-std-up-1.2.0-alt10.132128.1.src.rpm
kernel-modules-slmdm-std-smp-2.7.10-alt22.132128.1.src.rpm
kernel-modules-slmdm-std-up-2.7.10-alt22.132128.1.src.rpm
kernel-modules-slmodem-ovz-smp-2.9.11-alt2.132624.3.src.rpm
kernel-modules-slmodem-std-smp-2.9.11-alt1.132128.1.src.rpm
kernel-modules-slmodem-std-up-2.9.11-alt1.132128.1.src.rpm
kernel-modules-slmodem-std26-smp-2.9.11-alt2.132624.9.src.rpm
kernel-modules-slmodem-std26-up-2.9.11-alt2.132624.9.src.rpm
kernel-modules-slmodem-vs26-smp-2.9.11-alt2.132624.8.src.rpm
kernel-modules-slmodem-wks26-smp-2.9.11-alt2.132624.8.src.rpm
kernel-modules-slmodem-wks26-up-2.9.11-alt2.132624.8.src.rpm
kernel-modules-spca5xx-std-smp-0.57.10-alt1.132128.1.src.rpm
kernel-modules-spca5xx-std-up-0.57.10-alt1.132128.1.src.rpm
kernel-modules-subfs-std-smp-0.9-alt6.132128.1.src.rpm
kernel-modules-subfs-std-up-0.9-alt6.132128.1.src.rpm
kernel-modules-svgalib_helper-ovz-smp-1.9.23-alt5.132624.3.src.rpm
kernel-modules-svgalib_helper-std-smp-1.9.23-alt2.132128.1.src.rpm
kernel-modules-svgalib_helper-std-up-1.9.23-alt2.132128.1.src.rpm
kernel-modules-svgalib_helper-wks26-smp-1.9.23-alt5.132624.8.src.rpm
kernel-modules-svgalib_helper-wks26-up-1.9.23-alt5.132624.8.src.rpm
kernel-modules-thinkpad-ovz-smp-5.9-alt1.132624.3.src.rpm
kernel-modules-thinkpad-std-smp-5.8-alt3.132128.1.src.rpm
kernel-modules-thinkpad-std-up-5.8-alt3.132128.1.src.rpm
kernel-modules-thinkpad-std26-smp-5.9-alt1.132624.8.src.rpm
kernel-modules-thinkpad-std26-up-5.9-alt1.132624.9.src.rpm
kernel-modules-thinkpad-wks26-smp-5.9-alt1.132624.8.src.rpm
kernel-modules-thinkpad-wks26-up-5.9-alt1.132624.8.src.rpm
kernel-modules-v4l-std-smp-2005.01.25-alt1.132128.1.src.rpm
kernel-modules-v4l-std-up-2005.01.25-alt1.132128.1.src.rpm
kernel-modules-vt1211-ovz-smp-1.1-alt1.132624.3.src.rpm
kernel-modules-vt1211-std26-smp-1.1-alt1.132624.9.src.rpm
kernel-modules-vt1211-std26-up-1.1-alt1.132624.9.src.rpm
kernel-modules-vt1211-vs26-smp-1.1-alt1.132624.8.src.rpm
kernel-modules-vt1211-wks26-smp-1.1-alt1.132624.8.src.rpm
kernel-modules-vt1211-wks26-up-1.1-alt1.132624.8.src.rpm
kernel-modules-zaptel-ovz-smp-1.3-alt12.132624.2.src.rpm
kernel-modules-zaptel-ovz-smp-1.3-alt13.132624.4.src.rpm
kernel-modules-zaptel-std26-smp-1.3-alt12.132624.9.src.rpm
kernel-modules-zaptel-std26-smp-1.3-alt13.132624.9.src.rpm
kernel-modules-zaptel-std26-up-1.3-alt12.132624.9.src.rpm
kernel-modules-zaptel-std26-up-1.3-alt13.132624.9.src.rpm
kernel-modules-zaptel-vs26-smp-1.3-alt12.132624.8.src.rpm
kernel-modules-zaptel-vs26-smp-1.3-alt13.132624.8.src.rpm
kernel-modules-zaptel-wks26-smp-1.3-alt12.132624.7.src.rpm
kernel-modules-zaptel-wks26-smp-1.3-alt13.132624.8.src.rpm
kernel-modules-zaptel-wks26-up-1.3-alt12.132624.7.src.rpm
kernel-modules-zaptel-wks26-up-1.3-alt13.132624.8.src.rpm
kernel-source-aksparlnx-1.6-alt0.2.src.rpm
kernel-source-dvb-20031013-alt2.1.src.rpm
kfiresaver3d-0.6-alt1.1.src.rpm
kflickr-0.5-alt1.src.rpm
kglwatersaver-0.6-alt1.1.src.rpm
kguitar-0.5-alt2.src.rpm
khttrack-0.11-alt2.src.rpm
kile-1.9-alt1.src.rpm
kink-0.2.1-alt3.1.1.src.rpm
kino-0.9.1-alt0.1cvs20060810.src.rpm
kino-brightcontrast-0.1-alt0.1.src.rpm
kio-apt-0.13-alt1.src.rpm
kipi-plugins-0.1rc1-alt2.src.rpm
kiso-0.8.3-alt1.src.rpm
klear-0.5.4-alt2.src.rpm
kmhtconvert-0.6-alt1.1.src.rpm
kmpio-0.7.0-alt2.src.rpm
kmplayer-0.9.1a-alt2.src.rpm
knetload-2.3-alt2.src.rpm
kniga-0.1.11-alt1.src.rpm
knoda-0.8.1-alt1.src.rpm
kompose-0.5.1-alt0.1.src.rpm
kooldock-0.3-alt2.src.rpm
kpacman-0.3.2-alt7.src.rpm
kpager2-0.6.0-alt2.src.rpm
kphone-4.1.1-alt1.src.rpm
kplayer-0.5.3-alt0.6.src.rpm
kscope-1.3.4-alt0.1.src.rpm
kscreensaver-asciiquarium-0.3.2-alt2.src.rpm
kshowmail-3.1.0-alt2.4.src.rpm
kshutdown-0.4.0-alt1.1.src.rpm
ksi-3.4.2-alt0.1.src.rpm
ksystemlog-0.3.2-alt1.src.rpm
ktail-0.6.1-alt3.src.rpm
ktamaga-0.7.2-alt3.src.rpm
kudzu-knoppix-1.1.3-alt2.src.rpm
kxdocker-0.39-alt1.src.rpm
ladspa-guitar-preamp-1.0-alt1.1.src.rpm
ladspa-guitar-super-60-1.0-alt1.1.src.rpm
ladspa-guitar-unmatched-1.0-alt1.1.src.rpm
ladspa-mcp-plugins-0.3.0-alt0.5.1.src.rpm
ladspa-pvoc-0.1.10-alt1.src.rpm
ladspa-rev-plugins-0.2.1-alt0.5.1.src.rpm
ladspa-swh-plugins-0.4.11-alt1.src.rpm
ladspa-tap-plugins-0.7.0-alt1.src.rpm
ladspa-vco-plugins-0.3.0-alt0.5.1.src.rpm
lamip-control-default-0.0.3-alt0.1.20050910.src.rpm
lamip-control-foobar-0.0.3-alt0.2.20051107.src.rpm
lamip-control-shell-0.0.2-alt0.1.20050209.1.src.rpm
lamip-control-systray-0.0.3-alt0.1.20050514.src.rpm
lamip-input-ac3-0.0.2-alt0.1.20050227.src.rpm
lamip-input-flac-0.0.2-alt0.1.20050226.src.rpm
lamip-input-mp3-0.0.2-alt0.1.20050226.src.rpm
lamip-input-ogg-0.0.2-alt0.1.20050226.src.rpm
lamip-input-playlist-0.0.2-alt0.1.20050226.src.rpm
lamip-input-speex-0.0.2-alt0.2.20050303.src.rpm
lamip-input-wav-0.0.2-alt0.1.20050226.src.rpm
lamip-output-alsa-0.0.2-alt0.1.20050226.src.rpm
lamip-output-libao-0.0.2-alt0.1.20050216.src.rpm
lamip-output-oss-0.0.2-alt0.1.20050309.src.rpm
larswm-7.5.3-alt1.src.rpm
last-exit-2.0-alt1.src.rpm
libareafix-1.9.0-alt1.20040614.src.rpm
libbtctl-0.6.0-alt1.1.src.rpm
libcamlimages-2.2.0-alt4.src.rpm
libcgi-0.5-alt2.src.rpm
libchipcard-0.9.1-alt0.1.src.rpm
libchipcard2-2.1.3-alt0.1.src.rpm
libclip-1.1.15-alt0.1.src.rpm
libdnet-1.11-alt5.src.rpm
libefltk-2.0.5-alt1.src.rpm
libetpan-0.45-alt1.src.rpm
libevolution-sharp-0.10.2-alt2.src.rpm
libezV24-0.1.1-alt1.src.rpm
libfoundation-r135-alt0.2.src.rpm
libgandalf-1.5-alt1.src.rpm
libgecko-sharp2-0.11-alt1.src.rpm
libgmime-2.1.19-alt1.src.rpm
libgnonlin-0.10.3-alt0.1.src.rpm
libgsf-sharp-0.6-alt1.src.rpm
libgtk-sharp2-2.8.2-alt1.src.rpm
libgtksourceview-sharp-0.10-alt2.src.rpm
libguichan-0.4.0-alt0.2.src.rpm
libgwenhywfar-2.2.0-alt0.1.src.rpm
libhptzip-0.1.0-alt1.20040614.src.rpm
libhusky-1.9.0-alt1.20040614.src.rpm
libical-0.24-alt0.2RC4.src.rpm
libinklevel-0.6.3-alt2.src.rpm
libjsw-1.5.6-alt0.1.src.rpm
liblrdf-0.3.7-alt1.1.1.src.rpm
libmidgard-1.5.1-alt0.3cvs20030916.src.rpm
libmikey-0.4.1-alt1.src.rpm
libmnetutil-0.3.1-alt1.src.rpm
libmsip-0.3.1-alt1.src.rpm
libmutil-0.3.1-alt1.src.rpm
libmysql++-2.0.7-alt1.src.rpm
libnss-mysql-1.5-alt1.src.rpm
libobjc-lf2-r135-alt0.2.src.rpm
liboop-1.0-alt1.1.src.rpm
libopensync-plugin-synce-0.05-alt0.2.cvs20060529.src.rpm
libortp-0.7.1-alt1.src.rpm
libpx-0.6.1-alt0.1.src.rpm
libqof-0.6.4-alt0.1.src.rpm
librep-0.16.2-alt2.1.src.rpm
libsigc++1.2-1.2.5-alt2.1.src.rpm
libsmapi-2.5.0-alt1.20040614.src.rpm
libss7-0.0.1-alt1.20060812.src.rpm
libssim-1.7.4-alt1.src.rpm
libtrash-2.4-alt1.src.rpm
libuninameslist-20050712-alt1.src.rpm
libv3d-0.1.14-alt2.src.rpm
libzvt-2.0.2-alt0.2cvs20031020.src.rpm
lightning-1.1.2-alt2.src.rpm
lineak_defaultplugin-0.8.4-alt1.src.rpm
lineak_xosdplugin-0.8.4-alt1.src.rpm
links1-1.00-alt5.src.rpm
liquidwar-5.6.2-alt1.src.rpm
lmms-0.2.0-alt0.src.rpm
logjam-4.5.3-alt2.src.rpm
lout-3.29-alt1.src.rpm
lphdisk-0.9.1-alt4.src.rpm
lrmi-0.10-alt2.src.rpm
lsb-3.0-alt0.1.src.rpm
lsdvd-0.15-alt1.src.rpm
ltxml-1.2.7-alt1.src.rpm
lvmcompat-1.0.8-alt3.src.rpm
lyx-1.4.1-alt0.1.src.rpm
madbomber-0.2.5-alt1.src.rpm
mail-notification-2.0-alt2.src.rpm
mailfromd-1.4-alt1.src.rpm
mairix-0.17.1-alt1.src.rpm
manedit-0.6.1-alt1.src.rpm
mbrowse-0.3.1-alt5.1.src.rpm
mdadm-2.5.3-alt1.src.rpm
memtest86-3.2-alt2.src.rpm
mgetty-1.1.31-alt1.src.rpm
microcode_ctl-1.12-alt2.src.rpm
misdn-0.1-alt6.20060820.src.rpm
mix2005-1.1.0-alt5.src.rpm
mknbi-1.4.4-alt1.src.rpm
mod_midgard-1.5.1-alt0.3cvs20030916.src.rpm
mod_mono-1.1.10-alt1.src.rpm
mon-0.99.2-alt1.src.rpm
monotone-0.22-alt1.src.rpm
moodss-19.3-alt0.1.src.rpm
moto4lin-0.3-alt4.src.rpm
mpgedit-0.71-alt0.6dev.src.rpm
mpich-1.2.4-alt5.src.rpm
mpio-0.7.1_pre2-alt3.1.src.rpm
mtaskbar-0.7-alt2.src.rpm
mtr-0.65-alt1.src.rpm
multisync-0.82-alt1.1.1.src.rpm
mysqlcc-0.9.4-alt2.src.rpm
nautilus-open-terminal-0.6-alt1.src.rpm
nautilus-sendto-0.4-alt1.src.rpm
netams-3.3.2-alt1.src.rpm
newton-0.0.9-alt0.1.src.rpm
nsis-2.18-alt1.src.rpm
nvidia-xconfig-1.0-alt4.src.rpm
nvidia_glx_src_1.0.7174-1.0.7174-alt17.src.rpm
nvidia_glx_src_1.0.7182-1.0.7182-alt1.src.rpm
nvidia_glx_src_1.0.7676-1.0.7676-alt17.src.rpm
nvidia_glx_src_1.0.8178-1.0.8178-alt16.src.rpm
nvidia_glx_src_1.0.8756-1.0.8756-alt17.src.rpm
nvidia_glx_src_1.0.8762-1.0.8762-alt18.src.rpm
nvram-wakeup-0.97-alt2.src.rpm
openobex-apps-1.0.0-alt4.src.rpm
openpref-0.1.0-alt2.src.rpm
openswan-1.0.9-alt1.src.rpm
orpheus-1.6-alt1.src.rpm
pam_encfs-0.1.3-alt1.src.rpm
pam_krb5-2.2.2-alt1.src.rpm
pam_usb-0.3.3-alt1.src.rpm
pango-1.14.2-alt1.src.rpm
panotools-2.6b1-alt3.src.rpm
pari-2.3.0-alt1.src.rpm
pentanet-tools-2.3.1-alt6.src.rpm
pentaval-tools-2.1.10-alt1.src.rpm
perl-AI-jNeural-0.53-alt1.1.src.rpm
perl-Crypt-Rijndael-0.04-alt1.src.rpm
perl-DBD-ODBC-1.13-alt1.src.rpm
perl-DBD-Sybase-1.05-alt1.1.src.rpm
perl-PDL-2.4.2-alt1.1.src.rpm
perl-SDL-2.1.3-alt1.src.rpm
perl-Unicode-Map8-0.12-alt2.src.rpm
php-rrdtool-4.4.2-alt0.cvs20051121.1.src.rpm
php5-dba-5.1.5-alt1.src.rpm
php5-gd2-5.1.5-alt1.src.rpm
php5-openssl-5.1.5-alt1.src.rpm
pilot-mailsync-0.7.1-alt1.1.src.rpm
pingus-0.6.0-alt7.src.rpm
pitivi-0.10.0-alt0.2.src.rpm
plasticfs-1.9-alt1.1.src.rpm
pnetC-0.6.8-alt1.src.rpm
pnetcurses-0.0.2-alt2.src.rpm
pnetlib-0.6.8-alt1.src.rpm
pose-3.5-alt5.src.rpm
powermanga-0.78-alt1.1.src.rpm
powertweak-0.99.5-alt2.src.rpm
pympd-0.05-alt1.src.rpm
python-module-CFG-0.0.2-alt6.src.rpm
python-module-OpenGL-2.0.2.01-alt2.src.rpm
python-module-PyKDE-3.15.2-alt0.snap20060422.src.rpm
python-module-PyLTXML-1.3-alt2.1.src.rpm
python-module-PyQt4-4.0.0-alt0.snap20060408.0.src.rpm
python-module-adns-1.1.0-alt0.2.1.src.rpm
python-module-bibtex-1.2.2-alt1.src.rpm
python-module-gnuplot-1.7-alt1.src.rpm
python-module-gst-0.10.4-alt0.1.src.rpm
python-module-memcached-1.2-alt1.tummy5.src.rpm
python-module-musicbrainz-1.0b3-alt1.src.rpm
python-module-openid-1.0.2-alt0.1.src.rpm
python-module-psyco-1.5.1-alt1.src.rpm
python-module-pyXLWriter-0.4-alt1.a3.src.rpm
python-module-pyXLWriter2-2.0-alt1.a1.src.rpm
python-module-pyclamav-0.3.2-alt0.1.src.rpm
python-module-pyemf-2.0.0-alt0.1.src.rpm
python-module-pygg-0.4-alt0.1.src.rpm
python-module-pygnome-desktop-2.13.3-alt0.2.src.rpm
python-module-pygoogle-0.6-alt0.1.src.rpm
python-module-pyxmpp-1.0.0-alt1.src.rpm
python-module-qt-3.16-alt1.src.rpm
python-module-xlib-0.12-alt0.1.src.rpm
python2.3-2.3.5-alt1.src.rpm
qamix-0.0.6-alt0.5.1.src.rpm
qcad-2.0.5.0-alt3.src.rpm
qdvdauthor-0.0.9-alt1.src.rpm
qsoapman-0.4-alt1.src.rpm
qsynaptics-0.11-alt1.1.src.rpm
qsynth-0.2.5-alt1.src.rpm
qtiplot-0.8.5-alt2.src.rpm
qtscope-0.64-alt1.src.rpm
quake2-0.3.0-alt2.src.rpm
quake3-1.32b-alt1.src.rpm
rhythmbox-0.9.5-alt1.src.rpm
rlog-1.3.6-alt1.src.rpm
root-tail-1.2-alt1.src.rpm
roundup-1.1.2-alt0.1.src.rpm
rox-pager-1.0.1-alt0.cvs20050812.1.src.rpm
rox-system-1.9.0-alt1.src.rpm
rox-tasklist-0.5-alt1.1.src.rpm
rss_glx-0.7.4-alt3.1.2.src.rpm
rte-0.5.6-alt1.src.rpm
ruby-fcgi-0.8.6-alt1.src.rpm
ruby-gnome2-0.14.1-alt3.src.rpm
ruby-libgtksourceview-0.2-alt1.src.rpm
s3switch-0.1-alt2.src.rpm
scheme48-1.3-alt2.src.rpm
scotty-3.0.0-alt3.src.rpm
screen-4.0.2-alt4.src.rpm
scsh-0.6.6-alt3.src.rpm
sdlscav-137-alt3.src.rpm
seahorse-0.9.1-alt1.src.rpm
sedna-0.5.9-alt1.src.rpm
ser-0.9.3-alt2.src.rpm
serveezopt-0.0.3-alt1.1.src.rpm
skencil-0.6.17-alt0.1.src.rpm
skyeye-1.2-alt1.src.rpm
sleezeball-0.6-alt8.src.rpm
slmodemd-2.9.11-alt1.src.rpm
slrn-0.9.8.1-alt8.src.rpm
smbc-1.2.2-alt1.src.rpm
sniffit-0.3.7-alt1.src.rpm
snort-2.4.5-alt2.src.rpm
sound-juicer-2.12.3-alt1.src.rpm
spectrum-fuse-0.7.0-alt2.src.rpm
sqsh-2.1.3-alt5.1.src.rpm
ssldump-0.9b3-alt4.1.src.rpm
stklos-0.71-alt1.1.src.rpm
stunnel-3.26-alt2.src.rpm
swfdec-0.3.6-alt1.src.rpm
swftools-0.6.2-alt1.1.src.rpm
sylpheed-claws-2.2.0.cvs66-alt1.src.rpm
synce-dccm-0.9.1-alt1.src.rpm
synce-kde-0.9.1-alt1.src.rpm
syndigator-0.20.0-alt1.rc2.src.rpm
taskjuggler-2.2.0-alt0.1.src.rpm
tcc-0.9.22-alt1.src.rpm
tcl-tktheme-2.3-alt5.src.rpm
tclock-1.0.1-alt2.src.rpm
tcptrace-6.6.7-alt2.src.rpm
teddy-1.1-alt1.src.rpm
texwiz-1.1.1-alt1.src.rpm
thoggen-0.3.1-alt4.1.src.rpm
tinyerp-client-3.2.1-alt0.1.src.rpm
tinyerp-server-3.2.1-alt0.1.src.rpm
tomboy-0.3.3-alt2cvs20051116.src.rpm
tora-1.3.18-alt1.src.rpm
toshset-1.67-alt1.src.rpm
totem-gstreamer-1.4.1-alt2.src.rpm
tpctl-4.17-alt2.src.rpm
trafshow-linux-1.3-alt4.src.rpm
tsemgr-0.08-alt1.src.rpm
tuxnes-0.75-alt3.src.rpm
tuxracer-0.61-alt9.src.rpm
tuxvsclippy-0.2.4-alt1.1.src.rpm
twinkle-0.7.1-alt0.1.src.rpm
unison-beta-2.17.1-alt1.src.rpm
unison-stable-2.9.1-alt1.src.rpm
ups-monitor-0.6-alt1.src.rpm
vaio-tools-0.0.1-alt5.src.rpm
vdr-1.3.22-alt1.src.rpm
vdr-aide-0.0.2-alt2.src.rpm
vdr-channelscan-0.0.3a-alt1.src.rpm
vdr-channelswitcher-0.0.1b-alt4.src.rpm
vdr-chanorg-0.0.6-alt1.src.rpm
vdr-dvd-0.3.6_b03-alt1.src.rpm
vdr-femon-0.8.6-alt4.src.rpm
vdr-monochannel-0.0.1-alt4.src.rpm
vdr-mp3-0.9.11-alt1.src.rpm
vdr-osdpip-0.0.7.1-alt3.src.rpm
vdr-osdteletext-0.4.2-alt1.src.rpm
vdr-prefermenu-0.6.4-alt4.src.rpm
vdr-rotor-0.1.0-alt1.src.rpm
vdr-sc-0.4.11-alt1.src.rpm
vdr-screenshot-0.0.5-alt4.src.rpm
vdr-sked-0.0.4-alt1.src.rpm
vdr-streamdev-0.3.3-alt5.src.rpm
vdr-submenu-0.0.2-alt1.src.rpm
vdr-subtitles-0.3.7-alt1.src.rpm
vdr-text2skin-1.0-alt1.1.src.rpm
vdr-vcd-0.7-alt1.src.rpm
vdr-vdrcd-0.0.10.1-alt1.src.rpm
vegastrike-0.4.3-alt2.src.rpm
verify_sender-0.1.7-alt4.1.src.rpm
vertex-0.1.15-alt1.1.src.rpm
vobcopy-0.5.13-alt1.1.src.rpm
vt1211-1.0-alt1.src.rpm
wammu-0.13-alt2.src.rpm
warzone2100-2.0.2.3-alt1.src.rpm
webauth-3.3.0-alt1.src.rpm
weechat-0.1.7-alt2.1.src.rpm
wine-20060802-alt0.1.src.rpm
wine-7zip-4.32-alt0.1.src.rpm
wine-kviewer-8-alt0.3.src.rpm
wmcdplay-1.0Beta1-alt2.1.src.rpm
wmpinboard-1.0-alt6.src.rpm
wmsmixer-0.5.1-alt1.1.src.rpm
wordnet-2.1-alt2.src.rpm
wwwoffle-2.9-alt1.src.rpm
x86info-1.18-alt1.src.rpm
xblast-2.10.0-alt1.src.rpm
xbsql-0.11-alt1.1.src.rpm
xcdroast-0.98alpha15-alt6.src.rpm
xclip-0.08-alt1.src.rpm
xdrawchem-1.9.9-alt0.1.src.rpm
xfce4-session-4.2.3-alt1.src.rpm
xfe-0.84-alt3.src.rpm
xfig-3.2.4-alt3.src.rpm
xfishtank-2.1tp-ipl9mdk.src.rpm
xfprint-4.2.3-alt1.src.rpm
xjewel-1.6-ipl12mdk.src.rpm
xmbdfed-4.7-alt1.src.rpm
xmms-eff-defx-0.9.9-alt1.src.rpm
xmms-in-cdparanoia-0.1-alt1.src.rpm
xmms-in-mad-0.8-alt1.src.rpm
xmms-kde-3.1-alt1.src.rpm
xmms-ladspa-0.7-alt1.src.rpm
xmms-mplayer-0.2.1-alt1.src.rpm
xmms-out-arts-0.7.1-alt3.src.rpm
xmms-out-mplayer-0.3.3-alt1.src.rpm
xmms-out-nas-0.2-alt2.src.rpm
xmms-sndfile-1.2-alt1.src.rpm
xmms-status-plugin-0.9-alt1.src.rpm
xpilot-4.5.4-alt3.src.rpm
xpired-1.22-alt5.src.rpm
xsane-0.991-alt2.src.rpm
xsp-1.1.10-alt1.src.rpm
xtoolwait-1.3-ipl6mdk.src.rpm
zapping-0.10-alt0.1.cvs6.src.rpm
$ comm -13 <(ls i586/SRPMS.classic) <(ls x86_64/SRPMS.classic)
R-base-2.3.0-alt1.src.rpm
design-bootloader-Compact-2.9.8-alt1.1.src.rpm
driconf-0.9.0-alt1.src.rpm
ekiga-1.99.1-alt0.1cvs20060228.src.rpm
gmorgan-0.23-alt0.5.1.src.rpm
gnormalize-0.47-alt1.src.rpm
ht-0.9.1-alt2.src.rpm
ipw3945d-1.7.19-alt1.src.rpm
kernel-image-rad26-smp-2.6.14-alt5.src.rpm
kernel-image-std-up-2.4.29-alt5.1.src.rpm
libetpan-0.45-alt1.1.src.rpm
libgmime-2.1.17-alt1.src.rpm
libgtk+2-2.10.2-alt1.src.rpm
libgtop-2.14.2-alt1.src.rpm
libqof-0.6.3-alt1.src.rpm
mdadm-2.5-alt2.src.rpm
nvidia-xconfig-1.0-alt1.src.rpm
nvidia_glx_x8664_1.0.7182-1.0.7182-alt1.src.rpm
nvidia_glx_x8664_1.0.8178-1.0.8178-alt17.src.rpm
nvidia_glx_x8664_1.0.8756-1.0.8756-alt18.src.rpm
nvidia_glx_x8664_1.0.8762-1.0.8762-alt19.src.rpm
orpheus-1.5-alt2.src.rpm
perl-IO-Epoll-0.01-alt1.src.rpm
screen-4.0.2-alt3.1.src.rpm
sylpheed-claws-2.3.1.cvs20-alt1.src.rpm
wwwoffle-2.8e-alt1.src.rpm
xtoolwait-1.3-alt1.src.rpm
$

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

Re: [devel] Стабильный Сизиф II

[Anton Farygin]

Fr. Br. George wrote:
> On Wed, Aug 23, 2006 at 03:41:01PM +0400, Alexey Tourbin wrote:
>> 1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE
> Насколько это её улучшит в плане стабильности?
> 
>> 2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
>> 9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
>> какие нет.
> Разумеется. Сейчас ведутся работы по восстановлению регулярности пересборок.
> 
>> 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
>> последней платформы.  Это тоже немалый объем работ, который может занять
>> несколько месяцев.
> Выпуск нужен в этом году. Пока по x86_64 ситуация такая: если установщик
> будет поддерживать x86_64, будет и выпуск на x86_64, состоящий из
> собирающихся пакетов. Не думаю, что в ближайший год мы сможем
> организовать эффективное _тестирование_ сколь-нибудь обширной пакетной
> базы на x86_64. Какой-то минимум оттестирован будет.

1) Программа установки не зависит от используемой архитектуры.. под 
какую архитектуру её соберёшь - под такой она и будет работать.
2) Эффективное тестирование x86_64 для серверов - вполне реально, и 
насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто 
- я уже почти 8 месяцев работаю на десктопе с x86_64 и 
рассинхронизированным сизифом. Из прсоблем - только вопрос с 
синхронизацией x86_64 и i586 пакетной базы.

> 
> Про "рассинхронизацию" i586 и x86_64 поподробнее можно?

Посмотрите архив списка рассылки incominger на предмет того, какие 
пакеты собрались для i586, но при этом не собрались для x86_64. И 
причину reject'а.

Говоря более коротко:
python и много в gnome нужно чинить. Очень много пакетов собирается без 
проблем для i586 и не собирается для x86_64. Об этом же говорит и 
количество unmet'ов для x86_64.

> 
>> Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
>> в такие сжатые сроки полноценной стабилизации и фриза не будет.
> Не будет. Но если её сейчас не сделать, через полгода в такие же сжатые
> сроки она будет ещё менее полноценной. А закладывать на _заморозку_
> сильно больше полутора месяцев -- невозможно.

Заморозка возможна, если незамедлительно принять меры как минимум к 
синхронизации двух архитектур (я писал о необходимых мерах полгода 
назад) + довести до ума как минимум те пакеты, которые кардинально 
влияют на установку системы. Для последнего - необходимо в ближайшее 
время собрать ISO образ минимального инсталятора и составить список 
вылезших проблем.

Из того, что помню:
- нет установки загрузчика после второй стадии, ибо udev в чруте не 
работает, а устройства отсутствуют. Потенциальное решение - использовать 
  mount --bind или mount --move для /dev/ в чрут с установленной 
системой. Но это надо экспериментально провертья
- apt-cdrom не умеет работать с HAL, в итоге установка пакетов на 
третьей стадии невозможна без наличия /media/cdrom. Решение в виде 
создания /media/cdrom не подходит, ибо вылезет всё та же проблема с 
двумя приводами
- нет нового design-bootloader-<продукт> для нового syslinux/gfxboot. 
Здесь просто нужно садится и делать. По срокам - примерно две недели с 
учётом наличия готового дизайна. Отказываться от gfxboot нереально, ибо 
на него завязаны кусочки первой, второй и третьей стадии инсталятора (по 
моему всё-таки третья не завязана, но надо разбираться).

Это то, что вспомнилось из Major. Всё остальное вылезет при сборке ISO 
образов (минимальный, максимальный, средний (Compact)).

Максимальный образ необходим для проверки функционала установки пакетов 
с учётом конфликтов. Под максимальным образом подразумевается весь 
Sisyphus за исключением unmet'ов. Минимальный образ необходим для 
ускоренния тестирования базовой системы/поддержки железа, средний образ 
- для проверки функционирования поддержки железа в реальной жизни и для 
проверки пакетной базы Compact'а (KDE/OpenOffice и их взаимодействие с 
остальными компонентами системы)

Rgds,
Rider

Re: [devel] Стабильный Сизиф II

[Fr. Br. George]

On Wed, Aug 23, 2006 at 03:41:02PM +0300, Igor Zubkov wrote:
> Слишком расплывчатое определение "пакеты, которые и так всем нужны". К 
> примеру, мне нужен phpMyAdmin, amarok, kmail, konqueror... А сомневаюсь, что 
> amarok нужен _всем_.
Поправил определение. Оно, правда, стало от этого не на много менее
расплывчатым :(.

Поясню, что мною движет. Я хочу собрать таблицу пакетов, обратная связь
по которым исходит не от майнтейнеров, а от пользователей. Потому что
майнтейнер и так знает, рабочий у него пакет или нет. И вполне может
позаботиться о том, чтобы во время freeze этот пракет был особенно
рабочим. Или не был, если майнтейнеру наплевать. Какой у какого пакета
майнтейнер, известно.

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

И вот этой информации нет вообще. А между тем это и есть актуальная (то
есть нужная более, чем одному человеку:) пактная база.

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

А ещё -- пакеты, "нужные всем", то есть такие, по которым необязательно
опрашивать кого-то конкретно. И здесь формальный критерий (кроме "двух
дюжин пользователей" и "пакет входит в инсталлятор") непонятен.

> В debian перед релизом 3.1 собирали информацию (с разрешения пользователей) 
> какие пакеты у них стоят. Может и нам так сделать? С этим я даже могу помочь. 
> Скрипт в одну строку:
> rpm --queryformat="%{NAME}\n" -qa | mail -s "all packages from my alt linux" 
> icesik@altlinux.org
> 
> Это грязно, но работает. :)
> Дальше, положить это всё в базу и собрать с неё статистику.
Отличная идея! Возьмётесь?

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Стабильный Сизиф II

[Fr. Br. George]

On Fri, Aug 25, 2006 at 03:58:49PM +0400, Anton Farygin wrote:
> 2) Эффективное тестирование x86_64 для серверов - вполне реально, и 
> насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто 
> - я уже почти 8 месяцев работаю на десктопе с x86_64 и 
> рассинхронизированным сизифом.
Значит, не всё так плохо :). Знать бы, насколько вас таких много.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Стабильный Сизиф II

[Anton Farygin]

Fr. Br. George wrote:
> On Fri, Aug 25, 2006 at 03:58:49PM +0400, Anton Farygin wrote:
>> 2) Эффективное тестирование x86_64 для серверов - вполне реально, и 
>> насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто 
>> - я уже почти 8 месяцев работаю на десктопе с x86_64 и 
>> рассинхронизированным сизифом.
> Значит, не всё так плохо :). Знать бы, насколько вас таких много.
> 

нас таких мало, ибо работающего инсталятора с x86_64 системой никто ещё 
не видел. То, что я выкладывал - это так, для экспертов, где половину 
нужно делать руками.

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

Но до этого необходимо решить вопросы с пакетной базой для x86_64.

Rgds,
Rider

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 15:58 Anton Farygin написал(a):
> - нет нового design-bootloader-<продукт> для нового syslinux/gfxboot.
Угу, но в сизифе я вижу gfxboot 2.5  не вижу gfxboot 3.2.5 . Или я не на тот 
сизиф смотрю?
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Anton Farygin]

Шенцев Алексей Владимирович wrote:
> В сообщении от 25 августа 2006 15:58 Anton Farygin написал(a):
>> - нет нового design-bootloader-<продукт> для нового syslinux/gfxboot.
> Угу, но в сизифе я вижу gfxboot 2.5  не вижу gfxboot 3.2.5 . Или я не на тот 
> сизиф смотрю?

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

Rgds,
Rider

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

<цитата от="Anton Farygin">
> Fr. Br. George wrote:
>> On Fri, Aug 25, 2006 at 03:58:49PM +0400, Anton Farygin wrote:
>>> 2) Эффективное тестирование x86_64 для серверов - вполне реально, и
>>> насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто
>>> - я уже почти 8 месяцев работаю на десктопе с x86_64 и
>>> рассинхронизированным сизифом.
>> Значит, не всё так плохо :). Знать бы, насколько вас таких много.
>>
>
> нас таких мало, ибо работающего инсталятора с x86_64 системой никто ещё
> не видел. То, что я выкладывал - это так, для экспертов, где половину
> нужно делать руками.
>
> После выкладывания более дружелюбного инсталятора жизнь станет намного
> проще - количество людей, имеющих воможность тестировать под x86_64
> довольно много - это все, кто использует Athlon64, Turion и Opteron.
>
> Но до этого необходимо решить вопросы с пакетной базой для x86_64.
это более важно, чем installer - все последние установки на desktop'ы
лично я без проблем делал через bootstrap на livecd.

PS Надо опять собрать себе новые Live'ы %)

-- 
WBR et al.

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 16:52 Anton Farygin написал(a):
> наверное он туда просто недополз. собственно этот вопрос нужно тоже
> порешать. Но это как раз самое простое, что есть в этом списке.
Самое простое - пакет уже, как минимум, месяц не может доползти до сизифа. И, 
я думаю, это не еденичный случай ...
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

<цитата от="Anton Farygin">
> Шенцев Алексей Владимирович wrote:
>> В сообщении от 25 августа 2006 15:58 Anton Farygin написал(a):
>>> - нет нового design-bootloader-<продукт> для нового syslinux/gfxboot.
>> Угу, но в сизифе я вижу gfxboot 2.5  не вижу gfxboot 3.2.5 . Или я не на
>> тот
>> сизиф смотрю?
>
> наверное он туда просто недополз. собственно этот вопрос нужно тоже
> порешать. Но это как раз самое простое, что есть в этом списке.
а что с того, что он доползет - design-bootloader все равно переписывать
придется.
-- 
WBR et al.

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 16:59 Konstantin A. Lepikhov написал(a):
> а что с того, что он доползет - design-bootloader все равно переписывать
> придется.
Да. Ибо в 3.2.5 есть поддержка jpg и многое другое. Но почему бы не 
переписать, ведь jpeg компактней, чем pcx. И картинки получатся более 
красочными и зрелещными.
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

<цитата от="Шенцев Алексей Владимирович">
> В сообщении от 25 августа 2006 16:59 Konstantin A. Lepikhov написал(a):
>> а что с того, что он доползет - design-bootloader все равно переписывать
>> придется.
> Да. Ибо в 3.2.5 есть поддержка jpg и многое другое. Но почему бы не
> переписать, ведь jpeg компактней, чем pcx. И картинки получатся более
> красочными и зрелещными.
так перепишите ;)

-- 
WBR et al.

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 17:14 Konstantin A. Lepikhov написал(a):
> так перепишите ;)
Дык вот и жду новый gfxboot 3.2.5 что бы поэксперементировать ... :) Антона с 
ним наверное уже достал ... :)
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

<цитата от="Шенцев Алексей Владимирович">
> В сообщении от 25 августа 2006 17:14 Konstantin A. Lepikhov написал(a):
>> так перепишите ;)
> Дык вот и жду новый gfxboot 3.2.5 что бы поэксперементировать ... :)
> Антона с
> ним наверное уже достал ... :)
а в чем проблема собрать его себе заранее? Например, я не понимаю, как
можно держать в сизифе пакеты, которые надо допиливать и которые
разламывают работу других пакетов - т.е.
syslinux/gfxboot/design-bootloader надо было выкладывать одновременно, а
не поодиночке, внося хаос в сборки livecd.

-- 
WBR et al.

Re: [devel] Uranus release management

[Fr. Br. George]

On Wed, Aug 23, 2006 at 07:32:18PM +0400, Alexey Tourbin wrote:
> > > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
Видишь ли, командовать -- не стоит. Community большое, а ты -- один.

> > Потому что он первым вызвался. :)
> Разруливать кофликты -- это не то же самое, что оповещать сообщество и
> координировать работу.  Разруливать конфликты в team -- это не только
> ответственность, но и прежде всего право.  Никто такого права Гоше не
> давал.  Но я и вообще не думаю, что кто-то один должен разруливать
> кофликты.
Ну кто тебе сказал, что "Разруливать конфликты в team -- это прежде
всего право"? Право на что? Получать по морде с обеих сторон и быть с
обеих сторон виноватым? Нефиговенькая привилегия. Ты правда этого
хочешь?

Нет, я не собираюсь "разруливать конфликты в team". Разруливать будем,
как и раньше разруливали, собственными силами. Просто я не верю в
самоорганизацию тупиковых и конфликтных ситуаций. Вот упёлись люди
рогом, что делать? Можно монетку бросить, echo $((RANDOM%2)) сказать.
Можно спросить экспертов, а потом снова упираться рогом, чей эксперт
правильнее.

Но проще спросить у кого-нибудь одного, особенно если он подписался быть
в курсе не вообще "всего", но хотя бы общего состояния дел. Например, у
меня. Я хоть и тупой, но понятливый. И всегда могу спросить, если что.

Да, я тоже надеюь, что ни конфликтных, ни тупиковых ситуаций не будет
:).

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 17:32 Konstantin A. Lepikhov написал(a):
> а в чем проблема собрать его себе заранее? 
У меня не тот уровень клвалификации что бы собрать себе gfxboot 3.2.5. Тем 
более, что в отличии от SuSe у нас не единый пакет графической темы загрузки, 
а несколько пакетов, т.е. отдельно gfxboot, отдельно design-bootloader, 
отдельно design-bootsplash.
> Например, я не понимаю, как можно держать в сизифе пакеты, которые надо
> допиливать и которые разламывают работу других пакетов - т.е.
> syslinux/gfxboot/design-bootloader надо было выкладывать одновременно, а
> не поодиночке, внося хаос в сборки livecd.
А это уже не ко мне ... ;) И почему так с этими пакетами я то же хотел знать.
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

<цитата от="Шенцев Алексей Владимирович">
> В сообщении от 25 августа 2006 17:32 Konstantin A. Lepikhov написал(a):
>> а в чем проблема собрать его себе заранее?
> У меня не тот уровень клвалификации что бы собрать себе gfxboot 3.2.5. Тем
> более, что в отличии от SuSe у нас не единый пакет графической темы
> загрузки,
> а несколько пакетов, т.е. отдельно gfxboot, отдельно design-bootloader,
> отдельно design-bootsplash.
так это правильно, т.к. gfxboot - это компилятор design-bootloader, а
bootsplash - это вообще отдельный патч и функционал.

PS новый gfxboot у меня есть, если вам нужен, могу выложить.

-- 
WBR et al.

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 25 августа 2006 17:53 Konstantin A. Lepikhov написал(a):
> так это правильно, т.к. gfxboot - это компилятор design-bootloader, а
> bootsplash - это вообще отдельный патч и функционал.
Это я понимаю и с таким разделением согласен.
>
> PS новый gfxboot у меня есть, если вам нужен, могу выложить.
А давайте, чем чёрт не шутит ... ;) Всё меньше по инету лазить, вспоминая 
откуда я Антону ссылку на него дал ... Давно руки чешутся его 
опробывать ... :)

-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Uranus release management

[Alexey Tourbin]

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

On Fri, Aug 25, 2006 at 05:38:52PM +0400, Fr. Br. George wrote:
> On Wed, Aug 23, 2006 at 07:32:18PM +0400, Alexey Tourbin wrote:
> > > > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
> Видишь ли, командовать -- не стоит. Community большое, а ты -- один.
> 
> > > Потому что он первым вызвался. :)
> > Разруливать кофликты -- это не то же самое, что оповещать сообщество и
> > координировать работу.  Разруливать конфликты в team -- это не только
> > ответственность, но и прежде всего право.  Никто такого права Гоше не
> > давал.  Но я и вообще не думаю, что кто-то один должен разруливать
> > кофликты.
> Ну кто тебе сказал, что "Разруливать конфликты в team -- это прежде
> всего право"? Право на что? Получать по морде с обеих сторон и быть с
> обеих сторон виноватым? Нефиговенькая привилегия. Ты правда этого
> хочешь?

Право не есть привилегия.  Сошлюсь на конституцию Debian.  Сообщество
делегирует разруливание конфликтов узкой группе специалистов.
Легитимность обретается вследствие демократической процедуры.

Теперь кто-то приходит и говорит: "последнее слово (по этому выпуску) --
за мной".  Тогда делай свой выпуск, как Rider делал Branch-3.0.  Я же
предпочту от этого выпуска дистанцироваться.  К счатью, большая часть
работ, которую предстоит выполнить, на самом деле не специфична для
фриза.

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

Re: [devel] Uranus release management

[Fr. Br. George]

On Fri, Aug 25, 2006 at 06:05:50PM +0400, Alexey Tourbin wrote:
> Право не есть привилегия.  Сошлюсь на конституцию Debian.  Сообщество
> делегирует разруливание конфликтов узкой группе специалистов.
> Легитимность обретается вследствие демократической процедуры.
Ничего "разруливать" я не собираюсь, ведь в психологи-то не нанимался.
Так что давай на этом закроем спор о терминах.

> Я же предпочту от этого выпуска дистанцироваться.  К счатью, большая
> часть работ, которую предстоит выполнить, на самом деле не специфична
> для фриза.
Ну, по крайней мере ты ведь не будешь во время фриза выкладывать
непроверенные обновления и устраивать революции в своих пакетах, правда?
А большего пока и не надо.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Uranus release management

[Alexey Tourbin]

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

On Fri, Aug 25, 2006 at 08:52:44PM +0400, Fr. Br. George wrote:
> > Я же предпочту от этого выпуска дистанцироваться.  К счатью, большая
> > часть работ, которую предстоит выполнить, на самом деле не специфична
> > для фриза.
> Ну, по крайней мере ты ведь не будешь во время фриза выкладывать
> непроверенные обновления и устраивать революции в своих пакетах, правда?
> А большего пока и не надо.

Конечно.  Я даже готов помогать.  Просто выпуск стабильного сизифа --
новый жанр, посмотрим что получится.  Вопросы насчёт процедур и
разрешения конфликтов всё же не кажутся мне пустыми.  В общем статус
этого "выпуска" мне не понятен до конца.  Тем более что единодушного
согласия насчет выпуска достигнуто не было, так что в чем-то он остается
твоей частной инициативой, а не мега-проектом team.  Но, поскольку выпуск
поддерживает Дима, саботировать его нет смысла. :)

А с точки зрения пакетной базы у меня принципиальных вопросов нет.
Здесь интересы "выпуска" и интересы сизифа во многом совпадают.

Совсем уж разломанные пакеты я никогда не выкладываю.  Просто есть
технологический цикл: 1) сборка и предварительное локальное тестирование
пакета; 2) выкладывание в Сизиф; 3) ждем еженедельной пересборки и
смотрим, что сломалось; по результам чиним сам этот пакет и/или другие
пакеты.  Не хотелось бы лишать себя возможности тестировать пакеты на
полной пересборке Сизифа.  Но, может быть, есть смысл потерпеть фриз
месяц или даже два.

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

Re: [devel] Uranus release management

[Fr. Br. George]

On Fri, Aug 25, 2006 at 09:25:56PM +0400, Alexey Tourbin wrote:
> Вопросы насчёт процедур и разрешения конфликтов всё же не кажутся мне пустыми.
Мне тоже, но решать их сейчас я не собираюсь -- не до того. Ведь как-то
же мы их решали раньше? Ну вот и сейчас пока так будем. До Конституции
Дибиан нам пока что далеко...

> В общем статус
> этого "выпуска" мне не понятен до конца.  Тем более что единодушного
> согласия насчет выпуска достигнуто не было, так что в чем-то он остается
> твоей частной инициативой, а не мега-проектом team.
Разумеется. Но без чьей-либо инициативы он не будет ни мега-, ни
милипроектом. А окончательная договорйнность по поводу того, чего ещё не
было -- дело немыслимое. По ходу додумаем, а после ещё разбор полётов
устроим, чтобы понять, как лучше действовать весной.

> Не хотелось бы лишать себя возможности тестировать пакеты на
> полной пересборке Сизифа. Но, может быть, есть смысл потерпеть фриз
> месяц или даже два.
Больше и нельзя. А по поводу полных пересборок ещё думать надо.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] Uranus release management

[Alexey Tourbin]

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

On Fri, Aug 25, 2006 at 10:10:26PM +0400, Fr. Br. George wrote:
> > Не хотелось бы лишать себя возможности тестировать пакеты на
> > полной пересборке Сизифа. Но, может быть, есть смысл потерпеть фриз
> > месяц или даже два.
> Больше и нельзя. А по поводу полных пересборок ещё думать надо.

А какая с ними проблема?

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

Re: [devel] Стабильный Сизиф II

[Anton Gorlov]

Fr. Br. George пишет:

>> 2) Эффективное тестирование x86_64 для серверов - вполне реально, и 
>> насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто 
>> - я уже почти 8 месяцев работаю на десктопе с x86_64 и 
>> рассинхронизированным сизифом.
> Значит, не всё так плохо :). Знать бы, насколько вас таких много.
я пытаюсь сейчас запустить серв на сизифе под x86_64...
но тут появилась более выгодная работа...боюсь это так ин е доведу до конца.

Re: [devel] Стабильный Сизиф II

[Konstantin A. Lepikhov]

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

Hi Шенцев!

Friday 25, at 05:56:02 PM you wrote:

> В сообщении от 25 августа 2006 17:53 Konstantin A. Lepikhov написал(a):
> > так это правильно, т.к. gfxboot - это компилятор design-bootloader, а
> > bootsplash - это вообще отдельный патч и функционал.
> Это я понимаю и с таким разделением согласен.
> >
> > PS новый gfxboot у меня есть, если вам нужен, могу выложить.
> А давайте, чем чёрт не шутит ... ;) Всё меньше по инету лазить, вспоминая 
> откуда я Антону ссылку на него дал ... Давно руки чешутся его 
> опробывать ... :)
http://www.unsafe.ru/lakostis/RPMS/ALTLinux/gfxboot-3.2.27-alt1.src.rpm

-- 
WBR et al.

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

Re: [devel] Стабильный Сизиф II

[Шенцев Алексей Владимирович]

В сообщении от 26 августа 2006 15:19 Konstantin A. Lepikhov написал(a):
> http://www.unsafe.ru/lakostis/RPMS/ALTLinux/gfxboot-3.2.27-alt1.src.rpm
О как, да же 3.2.27, а не 3.2.5 ... Интересно ... :)
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
ICQ: 271053845

Re: [devel] Стабильный Сизиф II

[Anton Farygin]

Шенцев Алексей Владимирович wrote:
> В сообщении от 25 августа 2006 17:14 Konstantin A. Lepikhov написал(a):
>> так перепишите ;)
> Дык вот и жду новый gfxboot 3.2.5 что бы поэксперементировать ... :) Антона с 
> ним наверное уже достал ... :)

Я не возражаю против NMU

Re: [devel] Uranus release management

[Dmitry V. Levin]

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

On Fri, Aug 25, 2006 at 10:30:22PM +0400, Alexey Tourbin wrote:
> On Fri, Aug 25, 2006 at 10:10:26PM +0400, Fr. Br. George wrote:
> > > Не хотелось бы лишать себя возможности тестировать пакеты на
> > > полной пересборке Сизифа. Но, может быть, есть смысл потерпеть фриз
> > > месяц или даже два.
> > Больше и нельзя. А по поводу полных пересборок ещё думать надо.
> 
> А какая с ними проблема?

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


-- 
ldv

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

Re: [devel] тестовые пересборки Сизифа

[Dmitry V. Levin]

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

On Mon, Aug 28, 2006 at 12:56:04PM +0400, Dmitry V. Levin wrote:
> On Fri, Aug 25, 2006 at 10:30:22PM +0400, Alexey Tourbin wrote:
> > On Fri, Aug 25, 2006 at 10:10:26PM +0400, Fr. Br. George wrote:
> > > > Не хотелось бы лишать себя возможности тестировать пакеты на
> > > > полной пересборке Сизифа. Но, может быть, есть смысл потерпеть фриз
> > > > месяц или даже два.
> > > Больше и нельзя. А по поводу полных пересборок ещё думать надо.
> > 
> > А какая с ними проблема?
> 
> 1. Никак не удаётся ввести в строй всё то оборудование, которое по разным
> причинам повыходило из строя за лето.

Вроде удалось восстановить около 45000 bogomips.
Тестовая пересборка Сизифа на i586 заняла около 16 часов,
не пересобралось 409 из 5446 пакетов.

> 2. Никак не удаётся довести скрипты до работоспособности в автономном
> режиме.

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


-- 
ldv

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

Re: [devel] Стабильный Сизиф II

[Michael Shigorin]

On Wed, Aug 23, 2006 at 04:23:18PM +0400, Dmitry V. Levin wrote:
> Очень желательно включить по умолчанию -fstack-protector, хотя
> объём работы по исправлению софта мне пока оценить сложно.
> Что касается -fpie/-pie, то здесь объём работы оченить ещё
> сложнее, думаю что мы не успеем к оченнему фризу.

Может, начать с ручного использования в ответственных сервисах
и задействованных библиотеках, или надо всех сразу?

Я бы попробовал apache подстраховать.

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

Re: [devel] Стабильный Сизиф II

[Michael Shigorin]

On Wed, Aug 23, 2006 at 05:12:05PM +0400, Alexey Tourbin wrote:
> > > последней платформы.  Это тоже немалый объем работ, который
> > > может занять несколько месяцев.
> > Надеюсь что меньше.
> И кто это будет делать?  Я готов помочь, но это предполагает
> инфраструктурные изменения.  1) Ввести в incominger'е логику И
> вместо ИЛИ для прохождения пакетов; 2) ввести в incominger'е
> проверку на потерю NMU; 3) начать регулярные пересборки на
> x86_64, хотя бы для информации (без статуса).

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

Если это в принципе приемлемо на осень, то варианты можно
обдумать:

- "мои пакеты может фиксить кто угодно"
- "эти люди могут фиксить любые пакеты"

(плюс, разумеется, изменения почтой/в bugzilla)

> > > Короче, интуиция мне подсказывает, что при текущем
> > > состоянии сизифа в такие сжатые сроки полноценной
> > > стабилизации и фриза не будет.
> > Придётся форсировать.
> Кто будет форсировать?  Князь Андрей Болконский? :)

Четвёртая танковая армия!

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

Re: [devel] Стабильный Сизиф II

[Michael Shigorin]

On Fri, Aug 25, 2006 at 03:32:43PM +0400, Fr. Br. George wrote:
> > Короче, интуиция мне подсказывает, что при текущем состоянии сизифа
> > в такие сжатые сроки полноценной стабилизации и фриза не будет.
> Не будет. Но если её сейчас не сделать, через полгода в такие
> же сжатые сроки она будет ещё менее полноценной. А закладывать
> на _заморозку_ сильно больше полутора месяцев -- невозможно.

Гоша, "правило буравчика" говорит о том, что оптимистичные планы
просто срываются, а реалистичные сроки -- это пессимистичные
оценки, помноженные на два или три.

Цикл подготовки дистрибутива ALT Linux (Compact, Master)
в последние годы не бывал менее полугода в активной фазе.

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

Re: [devel] Стабильный Сизиф II (installer: /media/cdrom)

[Michael Shigorin]

On Fri, Aug 25, 2006 at 03:58:49PM +0400, Anton Farygin wrote:
> - apt-cdrom не умеет работать с HAL, в итоге установка пакетов
> на третьей стадии невозможна без наличия /media/cdrom. Решение
> в виде создания /media/cdrom не подходит, ибо вылезет всё та же
> проблема с двумя приводами

Можно сделать костыль, который по наличию и содержанию .info
смонтирует подходящий носитель максимального объёма в
/media/cdrom, если это будет блокером.

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

Re: [devel] Стабильный Сизиф II

[Michael Shigorin]

On Fri, Aug 25, 2006 at 05:53:31PM +0400, Konstantin A. Lepikhov wrote:
> PS новый gfxboot у меня есть, если вам нужен, могу выложить.

В дедал кинь.

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

Re: [devel] lease management

[Michael Shigorin]

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

On Wed, Aug 23, 2006 at 07:23:31PM +0400, Dmitry V. Levin wrote:
> > > 2. Список актуальных пакетов и их пользователей.
> > >    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
> > http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8
> > "Поскольку очевидно, что подобный процесс (в некоторых кругах
> > именуемый Release Management :) не может организоваться сам
> > собой, поглядывать за ним и вовремя оповещать сообщество
> > берусь я, Георгий Курячий. Я же беру на себя и более сильную
> > ответственность: в случае спорных и/или конфликтных ситуаций
> > (и только в них) последнее слово по этому выпуску -- за
> > мной."
> > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
> Потому что он первым вызвался. :)

Если правильно помню, то:

- о летнем выпуске объявлял Антон;
- об осенне-зимнем -- ты.

Что собирается выпускать Гоша, при всём уважении никак не пойму.

Твой авторитет в качестве RM'а того, что ты объявил -- принимаю.

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

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

Re: [devel] lease management

[Dmitry V. Levin]

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

On Sat, Sep 02, 2006 at 07:15:21PM +0300, Michael Shigorin wrote:
> On Wed, Aug 23, 2006 at 07:23:31PM +0400, Dmitry V. Levin wrote:
> > > > 2. Список актуальных пакетов и их пользователей.
> > > >    http://wiki.sisyphus.ru/SisyphusRelease/Uranus/SignificantPackages
> > > http://wiki.sisyphus.ru/SisyphusRelease/Uranus?v=hn8
> > > "Поскольку очевидно, что подобный процесс (в некоторых кругах
> > > именуемый Release Management :) не может организоваться сам
> > > собой, поглядывать за ним и вовремя оповещать сообщество
> > > берусь я, Георгий Курячий. Я же беру на себя и более сильную
> > > ответственность: в случае спорных и/или конфликтных ситуаций
> > > (и только в них) последнее слово по этому выпуску -- за
> > > мной."
> > > Э-э, а почему не за мной? :)  "Командовать парадом буду я".
> > Потому что он первым вызвался. :)
> 
> Если правильно помню, то:
> 
> - о летнем выпуске объявлял Антон;
> - об осенне-зимнем -- ты.
> 
> Что собирается выпускать Гоша, при всём уважении никак не пойму.

Это от вас зависит. :)
Я со своей стороны постараюсь ему/вам/нам помочь.


-- 
ldv

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

Re: [devel] Стабильный Сизиф II

[Денис Смирнов]

On Sat, Sep 02, 2006 at 07:04:41PM +0300, Michael Shigorin wrote:

MS> Гоша, "правило буравчика" говорит о том, что оптимистичные планы
MS> просто срываются, а реалистичные сроки -- это пессимистичные
MS> оценки, помноженные на два или три.
MS> Цикл подготовки дистрибутива ALT Linux (Compact, Master)
MS> в последние годы не бывал менее полугода в активной фазе.

"Стабильный Сизиф" и "Дистрибутив" сильно разные вещи. Стабильный Сизиф
перед разморозкой форкается, и далее, уже release manager'ом дистрибутива
допинывается до приличного состояния. Потому как морозить Сизиф на полгода
нельзя. А если форкать просто в любой момент (как было с 3.0), то мы и
получим... э... компакт.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Как меня достал этот mc и libgpm.
Mouse, боюсь что на этот раз ты крайним будешь.
		-- ldv in #3867

Re: [devel] Стабильный Сизиф II

[Денис Смирнов]

On Sat, Sep 02, 2006 at 07:02:55PM +0300, Michael Shigorin wrote:

MS> Если это в принципе приемлемо на осень, то варианты можно
MS> обдумать:
MS> - "мои пакеты может фиксить кто угодно"

А вот это хорошее добавление к Sisyphus notes и вне периодов фриза.
Периодически уходящие в отпуск пишут сюда "фикси кто хочет".

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ПРАВИЛО БАРАХА
 Алкоголик - это тот, кто пьет больше своего врача.

Re: [devel] Стабильный Сизиф II

[Michael Shigorin]

On Sat, Sep 02, 2006 at 09:23:58PM +0400, Денис Смирнов wrote:
> А если форкать просто в любой момент (как было с 3.0), то мы и
> получим... э... компакт.

Там был довольно неплохой момент, как мне сейчас кажется.
Не хуже среднего.

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

Re: [devel] Стабильный Сизиф II

[Денис Смирнов]

On Sun, Sep 03, 2006 at 02:28:40AM +0300, Michael Shigorin wrote:

>> А если форкать просто в любой момент (как было с 3.0), то мы и
>> получим... э... компакт.
MS> Там был довольно неплохой момент, как мне сейчас кажется.
MS> Не хуже среднего.

Таки лучше. Потому что среднее состояние Сизифа -- "кошмар!". Это я
ответственно заявляю, как любитель держать на серверах Сизиф.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<hiddenman> ааа. это прикол
<AMorozov> ... сказал ежик, слазя с кактуса :-)

Re: [devel] Стабильный Сизиф II (installer: /media/cdrom)

[Dmitriy Khanzhin]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Здравствуйте!
Michael Shigorin wrote:
> On Fri, Aug 25, 2006 at 03:58:49PM +0400, Anton Farygin wrote:
>> - apt-cdrom не умеет работать с HAL, в итоге установка пакетов
>> на третьей стадии невозможна без наличия /media/cdrom. Решение
>> в виде создания /media/cdrom не подходит, ибо вылезет всё та же
>> проблема с двумя приводами
> 
> Можно сделать костыль, который по наличию и содержанию .info
> смонтирует подходящий носитель максимального объёма в
> /media/cdrom, если это будет блокером.
> 
Я тут как-то тоже озаботился этой проблемой, в результате появилась
идея:
На второй стадии, скажем, сделать udev-rule, создающее линк /dev/cdrom
на /dev/hd?, с которого идет установка, ибо оно известно.
А apt.conf, использующий это, в аттаче.

- --
С уважением, Дмитрий Ханжин.
ALT Linux Team. Registered Linux user #387627.
Just For Fun!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+lTcOSYE49d5ybgRAh2pAJ9dNSuvF82Ha8udXlbE0fUvJlKuOwCfSEeZ
IuCa3K8HGbvZ30bT68tqYTU=
=ro5z
-----END PGP SIGNATURE-----

[-- Attachment #2: apt.conf --]
[-- Type: text/plain, Size: 579 bytes --]

/*
 * This is the main configuration file for the APT suite of tools,
 * see apt.conf(5) for details.
 */

// See apt-cdrom(8) for details.
Acquire
{
    CDROM
    {
    Copy "true";
    "/media/cdrom/"
	{
	UMount "pumount /dev/cdrom";
	Mount "pmount /dev/cdrom cdrom";
	};
    };
};

RPM 
{
	Allow-Duplicated {
		// Old-style kernels.
		"^(NVIDIA_)?(kernel|alsa)[0-9]*(-adv|-linus)?($|-up|-smp|-secure|-custom|-enterprise|-BOOT|-tape|-aureal)";
		// New-style kernels.
		"^kernel-(image|modules)-.*";
	};
	Hold {
		// Old-style kernels.
		"^(kernel|alsa)[0-9]+-source";
	};
};

Re: [devel] lease management

[Fr. Br. George]

On Sat, Sep 02, 2006 at 07:15:21PM +0300, Michael Shigorin wrote:
> Что собирается выпускать Гоша, при всём уважении никак не пойму.
Гм. Я лично? И что я могу такое выпустить, инея две руки и одну голову?
Речь идёт о выпуске, который -- если захочет -- делает сообщество. Я
лишь вызвался быть крайним в этом процессе. Крайним, но отнюдь не
главным.

Кажется, продолжаешь смешивать "дистрибутив" и Сизиф?
Тут Денис Смирнов, по-моему, удачно всё разметил.

Добавлю только (по секрету), что в ALT Linux таки планируется выпуск
дистрибутива, то есть чего-то в коробке. На codebase выпуска Сизифа.
Вряд ли этот дистрибутив будет сильно от Сизифа отличаться. Даже
обновления для него и для "замороженного ставильного Сизифа", видимо,
будут одни и те же. Но коробки, техподержка, книжки и т. п. -- это всё
нельзя завязать на какой-то репозиторий в Сети, нужен дистрибутив.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru