23792 2010-07-20 23:48:32 +0400 Обновление mdadm до версии 3.1.4 2012-03-16 14:01:29 +0400 1 1 4 Development Sisyphus mdadm unstable all Linux CLOSED FIXED P3 enhancement --- 1 4alt shaba 4alt evg legion shaba vitty qa-sisyphus oldest_to_newest 110722 0 4alt 2010-07-20 23:48:32 +0400 Очень хотелось бы, чтобы в Альт Линукс 6.0 Кентавр появилась новая версия mdadm (3.1.1). Уж очень там нужные функции по смене уровня RAID появились. 112283 1 legion 2010-09-19 09:54:34 +0400 Из udev были удалены правила для mdadm: http://git.altlinux.org/people/shrek/packages/udev.git?p=udev.git;a=commitdiff;h=c580a1d6aaff3805909f8ac616ffc9e235bd67e6 потому что они теперь находятся и поддерживаются в апстриме mdadm. Вот только mdadm у нас настолько старый, что правил этих в нём нет. 112306 2 ldv 2010-09-20 00:45:17 +0400 (In reply to comment #1) > Из udev были удалены правила для mdadm: > > http://git.altlinux.org/people/shrek/packages/udev.git?p=udev.git;a=commitdiff;h=c580a1d6aaff3805909f8ac616ffc9e235bd67e6 > > потому что они теперь находятся и поддерживаются в апстриме mdadm. Вот только > mdadm у нас настолько старый, что правил этих в нём нет. Очень плохо, что shrek молча удалил эти правила и ничего не сказал об этом своим коллегам. Ответственный мейнтейнер не имеет права так поступать. Он, между прочим, выкинул не только 64-md-raid.rules, но и 64-device-mapper.rules. К сожалению, апстримный mdadm не вполне совместим с тем, что сейчас в Сизифе, и его нельзя обновить, не решив эту проблему. Для решения "проблемы udev" проще и быстрее просто запаковать 64-md-raid.rules. 112307 3 raorn 2010-09-20 00:58:00 +0400 (In reply to comment #2) > Очень плохо, что shrek молча удалил эти правила и ничего не сказал об этом > своим коллегам. Это сделал апстрим в версии 151. С коммитмесаджем "delete outdated packagees rules". > Ответственный мейнтейнер не имеет права так поступать. А ответственный мейнтейнер mdadm имеет право держать в репозитарии протухшую версию пакета? Последнее время если нужно чтобы что-то работало, дешевле и проще собирать это самому. 112310 4 legion 2010-09-20 01:09:04 +0400 (В ответ на комментарий №2) > Очень плохо, что shrek молча удалил эти правила и ничего не сказал об этом > своим коллегам. Я неправильный коммит показал (Валер, извини): v151-52-ga971fb4 > Ответственный мейнтейнер не имеет права так поступать. > Он, между прочим, выкинул не только 64-md-raid.rules, но и > 64-device-mapper.rules. Дим, зря ты судишь не разобравшись. > Для решения "проблемы udev" проще и быстрее просто запаковать 64-md-raid.rules. Нужно ещ 112311 5 legion 2010-09-20 01:12:42 +0400 > > Для решения "проблемы udev" проще и быстрее просто запаковать 64-md-raid.rules. > > Нужно ещ Извините за недописанный пост. Думаю, более правильно было бы запаковать эти старые правила в старый mdadm. Апстрим udev не виноват, что у нас проблемы с обновлением mdadm и если старые правила нам нужны, то давайте их держать в одном старом пакете. 112312 6 ldv 2010-09-20 01:15:31 +0400 (In reply to comment #3) > (In reply to comment #2) > > Очень плохо, что shrek молча удалил эти правила и ничего не сказал об этом > > своим коллегам. > > Это сделал апстрим в версии 151. С коммитмесаджем "delete outdated packagees > rules". Мейнтейнер -- не робот, он _должен_ это отслеживать и отражать в spec-файле, например, в форме межпакетных конфликтов. > > Ответственный мейнтейнер не имеет права так поступать. > > А ответственный мейнтейнер mdadm имеет право держать в репозитарии протухшую > версию пакета? Эта протухшая версия пакета отлично работает, в отличие от апстримной, которая не работает. Точнее говоря, она работает иначе, и надо под неё переписывать обвязку, которая должна будет поддерживать обе семантики. Или ещё что-то придумать, чтобы обновление mdadm в Сизиые стало возможным. Если вы такие остро заинтересованные, то возьмите и решите эту задачу. > Последнее время если нужно чтобы что-то работало, дешевле и проще собирать это > самому. "Собирать самому" может и робот: ничего не стоит, никакой ответственности. 112313 7 raorn 2010-09-20 01:20:26 +0400 В таком случае какой вообще смысл собирать что-то новое? Старое-то всё "прекрасно работает". 112314 8 ldv 2010-09-20 01:24:15 +0400 (In reply to comment #5) > > > Для решения "проблемы udev" проще и быстрее просто запаковать 64-md-raid.rules. > > Думаю, более правильно было бы запаковать эти старые правила в старый mdadm. Я об этом и написал в comment #2. Только надо не забыть поставить конфликт на udev < 151. Если кто-то может сделать это раньше вторника, то не ждите меня, пожалуйста. 112315 9 vitty 2010-09-20 01:34:53 +0400 (В ответ на комментарий №8) > (In reply to comment #5) > > > > Для решения "проблемы udev" проще и быстрее просто запаковать 64-md-raid.rules. > > > > Думаю, более правильно было бы запаковать эти старые правила в старый mdadm. > > Я об этом и написал в comment #2. > Только надо не забыть поставить конфликт на udev < 151. > Если кто-то может сделать это раньше вторника, то не ждите меня, пожалуйста. Я сейчас соберу, если никто не против. 112316 10 legion 2010-09-20 01:35:21 +0400 (В ответ на комментарий №6) > Мейнтейнер -- не робот, он _должен_ это отслеживать и отражать в spec-файле, > например, в форме межпакетных конфликтов. Он может это отслеживать должном уровне, когда созданы определённые условия, либо он поддерживает udev и mdadm. Xочешь мантейнить udev, чтобы всем нам было счастье ? > Если вы такие остро заинтересованные, то возьмите и решите эту задачу. У этого пакета есть мантейнер. Обновление этого пакета его прямая обязанность. Лично мне и своих пакетов хватает. > "Собирать самому" может и робот: ничего не стоит, никакой ответственности. При не обновлении пакета тоже никакой ответственности. 112681 11 repository-robot 2010-09-26 01:53:20 +0400 mdadm-3.1.4-alt1 -> sisyphus: * Mon Sep 20 2010 Vitaly Kuznetsov <vitty@altlinux> 3.1.4-alt1 - Updated to mdadm-3.1.4-2-ga2ce5a1 (closes: #23792). - Packaged README.recipes from Debian (closes: #11518). - Packaged mdmon. - Dropped unused mdassemble. - Cleaned up specfile and startup script.