Re: вопрос п о http://bugs.debian.org/release-critical/
On Sat, Dec 15, 2007 at 01:06:21AM +0300, Artem Chuprina wrote: Stanislav Maslovski - debian-russian@lists.debian.org @ Fri, 14 Dec 2007 23:12:31 +0300: Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? SM Это удовлетворит как сисадминов, которым достаточно базовой системы SM с набором сервисов, так и пользователей прикладного софта, который SM фиксится, как правило, быстрее в апстриме, чем усилиями SM сопровождающего. Ну, вообще-то такое деление уже есть. Есть stable, который можно апгрейдить без страха, и есть testing, который достаточно свеж и может ставиться на некритичные к если что машины. Мы так будем ходить по кругу. Повторюсь, что при сегодняшней практике длительных фризов, в тестинге периодически наступает час Х, когда ломается многое и сразу. Тестинг - это не более чем сгенерированный скриптами задержанный срез анстейбла, с некоторыми ограничениями на самые очевидные баги пакетирования. Делить же основной дистрибутив на системный и десктопный смысла не видно, ибо десктопные приблуды и десктопное железо все чаще норовят захотеть ядро посвежее и соответствующие околоядерные софты. Каковые ядро и софты - самые что ни на есть системные, системнее не бывает. Это не аргумент, ибо ничто не мешает иметь в дистрибутиве две (или более) версии ядер и настроить зависимости нужным образом. -- Stanislav
Re: вопрос п о http://bugs.debian.org/release-critical/
On Sat, Dec 15, 2007 at 09:08:04AM +0300, Yuri Kozlov wrote: 14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): On Fri, Dec 14, 2007 at 06:27:45PM +0300, Yuri Kozlov wrote: 14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? Это удовлетворит как сисадминов, которым достаточно базовой системы с набором сервисов, так и пользователей прикладного софта, который фиксится, как правило, быстрее в апстриме, чем усилиями сопровождающего. Как я понял, вы предлагаете оставить stable только для базовых пакетов. Но это уже есть? Получается, проблем с этим у сисадминов нет. Если кого-то не устраивает скорость фиксации проблем с безопасностью в stable то, наверное, стоит перейти на платный дистрибутив. Остаются неопытные пользователи. Если по каким-то причинам не устраивает стабильная ветка -- всегда есть Ubuntu, которая решает вопросы с новым софтом. И релиз раз в полгода. Чего ещё нужно? Убунту мало что решает, последний релиз 7.10 это прекрасно продемонстрировал. Я успел вдоволь наплеваться, пока настраивал и устанавливал эту систему своим знакомым (по их просьбе). связать в одну модель такие параметры, как: 1) важность пакета (например, оценить можно по числу зависящих от него, рекурсивно, с весом, пропорциональным их собственной важности) 2) частота выхода новых версий 3) частота багрепортов 4) частота исправлений Далее, сформировать некий критерий и по его значению поделить. Периодически пересчитывать критерий и корректировать списки пакетов. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? По каждому чиху это делать не обязательно. После каждого релиза - можно. Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Это я и хочу уяснить для себя. Но менять из-за этого то, за что, фактически, и любят Debian, мне кажется не стоит. Вера, Любовь и Надежда - три вечных спутницы дебианщика ;) -- Stanislav
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski - debian-russian@lists.debian.org @ Sat, 15 Dec 2007
11:24:58 +0300:
Потому и нужно произвести деление дистрибутива на (грубо говоря)
системный софт + библиотеки и десктопный софт + тулкиты и отказаться
от глобального фриза. Получился бы и не вариант убунты, где
нестабильно
всё подряд, и не текущий вариант, где stable == static.
Что это даст? Какую проблему решит?
SM Это удовлетворит как сисадминов, которым достаточно базовой системы
SM с набором сервисов, так и пользователей прикладного софта, который
SM фиксится, как правило, быстрее в апстриме, чем усилиями
SM сопровождающего.
Ну, вообще-то такое деление уже есть. Есть stable, который можно
апгрейдить без страха, и есть testing, который достаточно свеж и может
ставиться на некритичные к если что машины.
SM Мы так будем ходить по кругу. Повторюсь, что при сегодняшней
SM практике длительных фризов, в тестинге периодически наступает час
SM Х, когда ломается многое и сразу.
Да, но этот час X обычно происходит в тот момент, когда недавно вышел
stable. И если завести себе привычку переходить на новый testing не
сразу, а через месяц-два хотя бы после выхода stable, то все будет
совсем не так страшно.
SM Тестинг - это не более чем сгенерированный скриптами задержанный
SM срез анстейбла, с некоторыми ограничениями на самые очевидные баги
SM пакетирования.
А поскольку на неочевидные баги ты наткнешься не сразу и с достаточно
небольшой вероятностью в числе первых, то на нем вполне можно жить.
Делить же основной дистрибутив на системный и десктопный смысла не
видно, ибо десктопные приблуды и десктопное железо все чаще норовят
захотеть ядро посвежее и соответствующие околоядерные софты. Каковые
ядро и софты - самые что ни на есть системные, системнее не бывает.
SM Это не аргумент, ибо ничто не мешает иметь в дистрибутиве две (или
SM более) версии ядер и настроить зависимости нужным образом.
То есть, как следствие, две или более версий системного софта. И
добиваться, чтобы они уживались надлежащим образом при старте системы -
в частности, чтобы можно было безболезненно экспериментировать с новым
ядром, имея возможность перезагрузиться со старым.
Это очень отдельная развлекуха.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
/итд/почтопосылалка.нстрк (c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
На Sat, 15 Dec 2007 09:08:04 +0300 Yuri Kozlov [EMAIL PROTECTED] записано: Если кого-то не устраивает скорость фиксации проблем с безопасностью в stable то, наверное, стоит перейти на платный дистрибутив. Странное утверждение. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail: [EMAIL PROTECTED] Homepage: http://gq.net.ru signature.asc Description: PGP signature
Re: системный мониторинг в графиках
Oleg Frolkov wrote: Max V. Kotov пишет: В прошлом году решали, чем мониторить оборудование, пробовал zabbix (тогда ещё 1.1). Наилучшую производительность он показал в связка с Postgresql нежели с MySQL. Но, всё же остановились на cacti Spine (cactid) отличается некоторой нестабильностью, но решает текущие задачи мониторинга (по крайней мере у нас) + я использую бесплатную версию zenoss. Вот кстати о zenoss - можно где-то найти пакет собранный под Debian etch или грамотное хауту по интеграции его в etch? А то как-бы смотрю что оно базируется на zope а версия идущая с zenoss и версия в etch разные крайний раз когда я пытался его прикрутить у меня не получилось, а то есть желание посмотреть на этот самый zenoss и сравнить с zabbix. У меня инсталлятор zenoss сам стянул всё, что ему надо в отделиную директорию в которорую он ставился включая новый zope, и старые либы от nagios1.x. Проблем с установкой его на etch у меня не возникло. Возможно ещё будут - пока не всё сконфигурировали из желаемого. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: часы на 945 чипсете
Dmitry E. Oboukhov wrote: Интересный факт, жил до этого на самособранном ядре 2.6.23.9 - всё было хорошо и часы работали как часы :) по некоторой необходимости поставил дистрибутивное ядро - сразу же сбились часы. помогли удаление модуля rtc или обращение к hwclock с ключем --directisa странно всё это .. что же странного? значит в 2.6.23.9 модуль rtc работает со всеми чипсетами, а в более старых еще нет. это не странно а напротив - логично. вот если бы более старое ядро работало а более новое нет тогда бы было странно :) :) поясню - и самосборное и дистрибутивное одной и той же версии. точнее версия дистрибутивного - 2.6.23-1-686-bigmem в чейнджлоге которого в частности написано * Add stable release 2.6.23.9: -- Bye TimHisTeam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по htt p://bugs.debian.org/release-critical/
Stanislav Maslovski - debian-russian@lists.debian.org @ Sat, 15 Dec 2007 11:24:58 +0300: SM Мы так будем ходить по кругу. Повторюсь, что при сегодняшней практике SM длительных фризов, в тестинге периодически наступает час Х, когда ломается SM многое и сразу. Тестинг - это не более чем сгенерированный скриптами SM задержанный срез анстейбла, с некоторыми ограничениями на самые очевидные SM баги пакетирования. 1 месяц задержка после release stable + apt-listbugs для того что бы быть вкурсе что full-upgrade нам готовит. В целом жить можно, кроме ну совсем жутких багов которые только у меня появляются :) -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgppTxoFcS3c2.pgp Description: PGP signature
Re: вопрос по http://bugs.debian.org/release-critical/
15.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Убунту мало что решает, последний релиз 7.10 это прекрасно продемонстрировал. Я успел вдоволь наплеваться, пока настраивал и устанавливал эту систему своим знакомым (по их просьбе). Имеется другой, более положительный опыт. Но в моём случае народ был готов поковыряться. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? По каждому чиху это делать не обязательно. После каждого релиза - можно. Если между релизами останется промежуток в пару лет, то обязательно найдутся люди, которым опять не хватит частоты обновления какого-нибудь пакета в stable. Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Это я и хочу уяснить для себя. Куча ошибок после фриза -- это не баг -- это фича. :) Но менять из-за этого то, за что, фактически, и любят Debian, мне кажется не стоит. Вера, Любовь и Надежда - три вечных спутницы дебианщика ;) И они тоже. -- Regards, Yuri Kozlov
Вопрос по компиляции WI NE
Здравствуйте. Возникла проблема с компиляцией wine 0.9.51. Debian Etch 4.0 r1. Если кто нибудь сталкивался с такой ошибкой, подскажите пожалуйста что я делаю не так. Заранее спасибо. make[2]: Entering directory `/usr/local/src/wine-0.9.51/libs/wpp' bison -p ppy_ -o ppy.tab.c -d ppy.y ppy.y:138 parser name defined to default :parse bison -p ppy_ -o ppy.tab.c ppy.y ppy.y:138 parser name defined to default :parse gcc -c -I. -I. -I../../include -I../../include-Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o ppy.tab.o ppy.tab.c gcc -c -I. -I. -I../../include -I../../include-Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o ppl.yy.o ppl.yy.c ppl.l:167:21: error: ppy.tab.h: No such file or directory ppl.l:233: error: expected declaration specifiers or ‘...’ before ‘YYSTYPE’ ppl.l: In function ‘ppy_lex’: ppl.l:312: error: ‘tINCLUDE’ undeclared (first use in this function) ppl.l:312: error: (Each undeclared identifier is reported only once ppl.l:312: error: for each function it appears in.) ppl.l:314: error: ‘tERROR’ undeclared (first use in this function) ppl.l:315: error: ‘tWARNING’ undeclared (first use in this function) ppl.l:316: error: ‘tPRAGMA’ undeclared (first use in this function) ppl.l:317: error: ‘tPPIDENT’ undeclared (first use in this function) ppl.l:318: error: ‘tUNDEF’ undeclared (first use in this function) ppl.l:319: error: ‘tIFDEF’ undeclared (first use in this function) ppl.l:320: error: ‘tIFNDEF’ undeclared (first use in this function) ppl.l:321: error: ‘tIF’ undeclared (first use in this function) ppl.l:322: error: ‘tELIF’ undeclared (first use in this function) ppl.l:323: error: ‘tELSE’ undeclared (first use in this function) ppl.l:324: error: ‘tENDIF’ undeclared (first use in this function) ppl.l:325: error: ‘tLINE’ undeclared (first use in this function) ppl.l:326: error: ‘tGCCLINE’ undeclared (first use in this function) ppl.l:328: error: ‘tNL’ undeclared (first use in this function) ppl.l:336: error: ‘ppy_lval’ undeclared (first use in this function) ppl.l:336: warning: passing argument 3 of ‘make_number’ makes integer from pointer without a cast ppl.l:336: error: too many arguments to function ‘make_number’ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: вопрос п о http://bugs.debian.org/release-critical/
On Sat, Dec 15, 2007 at 06:29:36PM +0300, Yuri Kozlov wrote: 15.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Убунту мало что решает, последний релиз 7.10 это прекрасно продемонстрировал. Я успел вдоволь наплеваться, пока настраивал и устанавливал эту систему своим знакомым (по их просьбе). Имеется другой, более положительный опыт. Но в моём случае народ был готов поковыряться. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? По каждому чиху это делать не обязательно. После каждого релиза - можно. Если между релизами останется промежуток в пару лет, то обязательно найдутся люди, которым опять не хватит частоты обновления какого-нибудь пакета в stable. Во-порвых, их будет меньше. При правильно выбранном критерии - значительно меньше. Во-вторых, им будет, что ответить. На данный момент ответы сводятся к иррациональному только не трогайте, нам и так хорошо. Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Это я и хочу уяснить для себя. Куча ошибок после фриза -- это не баг -- это фича. :) На мой взгдяд, разумнее было бы проанализировать, почему это так. Свои предположения я высказал, возможные варианты действий - тоже обозначил. Интересно было бы выслушать еще чьи-то идеи/мысли (ессно, кроме тех, что настоящему индейцу завсегда везде ништяк). -- Stanislav
Re: Вопрос по компиляц ии WINE
On Sat, Dec 15, 2007 at 05:40:30PM +0200, Andrey Voronov wrote: Здравствуйте. Возникла проблема с компиляцией wine 0.9.51. Debian Etch 4.0 r1. Если кто нибудь сталкивался с такой ошибкой, подскажите пожалуйста что я делаю не так. Заранее спасибо. Зачем собирать wine руками? -- WBR, Dmitry signature.asc Description: Digital signature
мышь vs ПДУ
Добрый вечер. [EMAIL PROTECTED]:~$ cat /proc/bus/input/devices I: Bus=0011 Vendor=0002 Product=0005 Version= N: Name=ImPS/2 Generic Wheel Mouse P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input4 U: Uniq= H: Handlers=mouse0 event4 ts0 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=103 I: Bus=0018 Vendor= Product= Version= N: Name=BeholdTV P: Phys=i2c-1/1-002d/ir0 S: Sysfs=/class/input/input5 U: Uniq= H: Handlers=kbd event5 B: EV=13 B: KEY=20fc014 b00041 0 0 0 400 0 90 4003 1e 0 0 ffc Проблема в том, что ПДУ и мышь постоянно меняются местами, как это побороть? -- Best regards, Maksim A. Boyko ICQ: 478886172
Re: Вопрос по компиляции WINE
2007/12/15, Andrey Voronov [EMAIL PROTECTED]: Здравствуйте. Возникла проблема с компиляцией wine 0.9.51. Debian Etch 4.0 r1. Если кто нибудь сталкивался с такой ошибкой, подскажите пожалуйста что я делаю не так. Заранее спасибо. Похоже http://bugs.winehq.org/show_bug.cgi?id=6204 -- Regards, Yuri Kozlov
пауза для программ
Добрый вечер. Не подскажете, можно ли реализовать suspend to disk только для одной программы? Т.е. нужна тулза, которая сможет сохранить текущее состояние программы на диск и после перезагрузки продолжить ее выполнение. -- Best regards, Maksim A. Boyko ICQ: 478886172
Re: мышь vs ПДУ
В сообщении от 15 декабря 2007 19:47 Maksim A. Boyko написал(a): Проблема в том, что ПДУ и мышь постоянно меняются местами, как это побороть? Написать правило udev, которое в зависимости от udev-атрибутов (man udevinfo, что-то за что зацепиться можно) будет создавать симлинки, например: /dev/input/MySuperMice и /dev/input/BeholdIR А программы, работающие с этими устройствами, натравливать именно на симлинки. -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: пауза для программ
On Sat, 15 Dec 2007, Maksim A. Boyko wrote: Добрый вечер. Не подскажете, можно ли реализовать suspend to disk только для одной программы? Т.е. нужна тулза, которая сможет сохранить текущее состояние программы на диск и после перезагрузки продолжить ее выполнение. -- Best regards, Maksim A. Boyko Что-то мне кажется, что это принципиально не возможно. К примеру, в начале работы программа загружает с помощью dlopen какие-то библиотеки. Заметим, что те в свою очередь могут захотеть какие-то другие библиотеки и т.д. Таким образом восстановление работы программы потребует загрузки _всех_ библиотек которые были в памяти на момент остановки. Еще хуже дело обстоит с файлами. Кто будет закрывать уже открытые потоки? Где гарантия, что файлы не будут модифицированны в промежутке между? Единственное, что приходит в голову, - запускать на отдельной виртуальной машине, и делать суспенд всей VM. Успехов. Ю.
Re: вопрос по http://bugs.debian.org/release-critical/
15.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Если между релизами останется промежуток в пару лет, то обязательно найдутся люди, которым опять не хватит частоты обновления какого-нибудь пакета в stable. Во-порвых, их будет меньше. При правильно выбранном критерии - значительно меньше. Во-вторых, им будет, что ответить. На данный момент ответы сводятся к иррациональному только не трогайте, нам и так хорошо. На самом деле, действительно неплохо. :) А ответите Вы им в стиле согласно статистической температуре по больнице пакет не может покинуть stable. Чем это лучше. Что есть некие цифры? Ваш вариант -- это такая же проба решить некоторую проблему как и тот, что уже работает. Не факт, что он окажется лучше имеющегося. За исключением того, что да, цифры RC будут ниже за счёт простого _уменьшения_ количества стабилизируемых пакетов. Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Это я и хочу уяснить для себя. Куча ошибок после фриза -- это не баг -- это фича. :) На мой взгдяд, разумнее было бы проанализировать, почему это так. Свои предположения я высказал, возможные варианты действий - тоже обозначил. Интересно было бы выслушать еще чьи-то идеи/мысли (ессно, кроме тех, что настоящему индейцу завсегда везде ништяк). Тогда я бы начал с просмотра программы, которая строит этот график. И поискал бы, из чего сложилась такая вертикальная линия в июнe. -- Regards, Yuri Kozlov
Re: пауза для программ
Единственное, что приходит в голову, - запускать на отдельной виртуальной машине, и делать суспенд всей VM. Я об этом уже думал, но не оч. нравится из-за эмуляции... -- Best regards, Maksim A. Boyko ICQ: 478886172
Re: мышь vs ПДУ
У меня в правилах udev`а лежит
KERNEL==event*,ATTRS{vendor}==0x1131,SYMLINK+=irremote
для создания ссылки /dev/irremote на ИК-порт. Вам надо параметр ATTRS
свой какой-то вставить, выцыганить их можно вот так:
$ udevinfo -a -p `udevinfo -q path -n /dev/input/eventN`
Удачи
Спасибо, то что нужно :-)
--
Best regards, Maksim A. Boyko
ICQ: 478886172
Re: пауза для программ
On Sat, Dec 15, 2007 at 08:00:06PM +0300, Maksim A. Boyko wrote: Добрый вечер. Не подскажете, можно ли реализовать suspend to disk только для одной программы? Т.е. нужна тулза, которая сможет сохранить текущее состояние программы на диск и после перезагрузки продолжить ее выполнение. Вспомнил, что читал о подобном. Всемогущий гугл даже нашел где. http://www.geocities.com/asimshankar/checkpointing/ -- Stanislav
длинные имена в torrente
Приветствую всех. Решил скачать торрент (с помощью KTorrent). Скачал торрент-файл, запустил - и KTorrent (и иные клиенты) выдает ошибку: в этом торренте у файлов длинные имена, соотв. файл на диске создать нельзя. При попытке исключить такой файл из скачивания для этого торрента (т.е. он его, получается, и создавать не должен на диске, тогда) - ошибка длинного имени все равно вылезает на нем же. Локаль RU.UTF-8, соотв. длина имен до 128 символов. Есть какие-либо способы скачать такой торрент? И ессно записать на диск с более коротким именем? (попросить автора перевыложить с короткими именами невозможно). -- С наилучшими, Константин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[D-I Manual] Build log for ru (15 Dec 2007)
A build of the Debian Installer Manual was triggered by an update to SVN.
There were no errors during the build process.
The new version of the manual has been uploaded successfully.
A log of the build is available at:
- http://d-i.alioth.debian.org/manual/logs/ru.log
===
It is possible to use RSS to track changes to the manual.
For more information, see:
http://d-i.alioth.debian.org/manual/translators.html
===
Note: PDF output is not yet supported for some languages; this
is being worked on.
===
If you have any questions about the build or this message, feel
free to contact me at faw_at_funlabs_dot_org.
===
Updated files ('svn up')
Upo/ru/preseed.po
Updated to revision 50478.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
