Cтоит перeсобрать linux-cifs по новой схеме:
http://bugs.etersoft.ru/show_bug.cgi?id=2220

Обратите внимание на http://wiki.etersoft.ru/Etercifs

Я переложил в /var/ftp/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs
сборку всех новых пакетов для linux-cifs...

Нужно пересобрать их под разные
дистрибутивы... Нужно уточнить порядок
пересборки и обновления пакетов для linux-cifs.

Сейчас сделана поддержка для ядер начиная
с 2.6.18 и заканчивая 2.6.25 включительно... Для
2.6.26 порта пока не было, теперь он будет
добавляться путём создания нового пакета
kernel-source-etercifs-2.6.26...

Собрался пакет linux-cifs-1.0-alt5 для ALTLinux 4.1.

Уже есть linux-cifs-1.0-alt6, где исправлена неточность с зависимостями.

Также прошу учитывать, что в спеке закомментирована строка (если вендор - АЛЬТ)

BuildRequires: kernel-headers-modules-std-smp kernel-headers-modules-ovz-smp kernel-headers-modules-std-def

которая (видимо) служила для упрощения сборки на специальной сборочной машине, на которой все хедеры и модули ядер установлены. Я же оставил только 

BuildRequires: kernel-headers-modules-std-def

Посему, если у вас АЛЬТ и ядро не std-def, то надо править спек. Это пользователю не помешает, поэтому решать эту задачу в общем виде я не стал.

Откуда брать 6 релиз? Из гита? Если можно, положите его в /var/ftp/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs к остальным.

а где собственно 1.54 взять? везде лежит максимум 1.52

(In reply to comment #7)
> а где собственно 1.54 взять? везде лежит
> максимум 1.52
> 

1.54 работает нестабильно, поэтому теперь, когда под каждое ядро мы собираем модуль из соответствующих разных исходников, мы берем ту версию, которая находится в соответствующем ядре и её патчим. В дальнейшем, при необходимости, попробуем какие-то функции из более новых версий портировать на старые.

ок. насколько я понимаю, сейчас чтобы использовать etercifs пользователю надо:
-установить минимум 2 (module sources для своего ядра и linux-cifs со скриптами) пакета, максимум 4 (module sources для 2.6.23-2.6.25 и linux-cifs со скриптами)
-сделать /etc/init.d/linux-cifs build
верно?

(In reply to comment #9)
> ок. насколько я понимаю, сейчас чтобы
> использовать etercifs пользователю надо:
> -установить минимум 2 (module sources для своего
> ядра и linux-cifs со скриптами) пакета, максимум
> 4 (module sources для 2.6.23-2.6.25 и linux-cifs со скриптами)
> -сделать /etc/init.d/linux-cifs build
> верно?
> 

В общем случае нет, достаточно просто поставить linux-cifs, ибо

- он зависит от всех существующих исходников для всех ядер (места занимают не так много, но пользователю уже об этом думать не нужно)
- если под ядро пользователя находится исходник ядра, то модуль для этого ядра собирается в процессе установки пакета linux-cifs (см. спек). service linux-cifs build делать уже не надо, все уже сделано и запущено. :)

Дополнение: в нашем будущем дистрибутиве пакет linux-cifs уже есть, так что в этом случае вообще не надо ничего дополнительно делать.

(In reply to comment #7)
> а где собственно 1.54 взять? везде лежит
> максимум 1.52

На деле версионирование cifs - уже фикция... Это такой же модуль ядра, как и любой другой, например ext3. Соответственно, текущая разработка cifs жёстко привязана к той версии ядра, для которого она была создавалась... Так для ядер 2.6.24 и 2.6.25 числится версия 1.52, хотя на самом деле эти модули могут отличаться...

Ситуация с версиями нас не должна смущать до тех пор пока не появится необходимость перенести нововведения из новых ядер на старые...

Такой подход был выбран после того, как ты начали тестировать сборки cifs-1.54 на более старых ядрах и получили проблемы нетривиальные с совместимостью, выражающиеся в проблемах синхронизации во время отмонтирования... Внешне это выглядело как, Segmentation fault, а исправлялось перезагрузкой причём то с бесконечно бегущим Backtrace от ядра...
http://bugs.etersoft.ru/show_bug.cgi?id=2157#c12

Как выяснилось в результате, на виртуальных машинах эта ошибка не проявлялась... Из чего был сделан вывод, что состояние гонки чаще проявляется на многоядерных машинах, где такие ситуации не редкость, в отличие от виртуальных машин, которым предоставлен только один процессор...

> В общем случае нет, достаточно просто
> поставить linux-cifs, ибо
> - он зависит от всех существующих
> исходников для всех ядер (места занимают не
> так много, но пользователю уже об этом
> думать не нужно)
угу. при текущей схеме значит все 4 пакета.

> - если под ядро пользователя находится
> исходник ядра, то модуль для этого ядра
> собирается в процессе установки пакета
> linux-cifs (см. спек). service linux-cifs build делать уже не
> надо, все уже сделано и запущено. :)
> 
это здорово, но как теперь все это портировать на другие ОС...
service %name build && service %name start ||:
этого делать никак нельзя, хотя бы потому что в ubuntu по умолчанию нет команды service.

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

см. ещё http://bugs.etersoft.ru/show_bug.cgi?id=2157#c21

Вопрос: зачем клиентам версия именно 1.54? Что конкретно в ней есть необходимого для данного клиента, чего нет в 1.52. Если действительно, не хватает чего-то важного, то можно попытаться вытащить эту функциональность из более позднего релиза.

(In reply to comment #14)
> см. ещё http://bugs.etersoft.ru/show_bug.cgi?id=2157#c21
> 
> Вопрос: зачем клиентам версия именно 1.54?
> Что конкретно в ней есть необходимого для
> данного клиента, чего нет в 1.52. Если
> действительно, не хватает чего-то важного,
> то можно попытаться вытащить эту
> функциональность из более позднего релиза.
> 
с версией проехали. меня просто смутило название баги.
ps: в #13 /ОС/Дистрибутив/

(In reply to comment #13)
> это здорово, но как теперь все это
> портировать на другие ОС...
> service %name build && service %name start ||:
> этого делать никак нельзя, хотя бы потому
> что в ubuntu по умолчанию нет команды service.

Значит нужно посмотреть, что делает команда service linux-cifs build (а она, как я помню, переходит в нужный каталог и запускает скрипт buildmodule.sh) и вместо старой команды, написать просто запуск этого скрипта. В ubuntu и спека нет, и rpm. Так что не только этот кусок надо переделывать для ubuntu.

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

я еще раз изложу как я вижу то, что получится при текущей схеме:
1) заказ сборки
2) формирования письма со ссылками
3) скачивание wine + 5 cifs пакетов(3 modules sources+1 legacy+1 linux-cifs)
4) установка пакетов wine + установка 5 пакетов cifs с компиляцией модуля

такая схема?
Если компиляция во время установки провалится, пакет вроде как не установится... 

(In reply to comment #17)
> я еще раз изложу как я вижу то, что
> получится при текущей схеме:
> 1) заказ сборки
> 2) формирования письма со ссылками
> 3) скачивание wine + 5 cifs пакетов(3 modules sources+1
> legacy+1 linux-cifs)
> 4) установка пакетов wine + установка 5 пакетов
> cifs с компиляцией модуля
> такая схема?

Да, только кол-во пакетов с сорцами может потом и вырасти.

> Если компиляция во время установки
> провалится, пакет вроде как не
> установится... 
> 

Нет, пакет установится, просто модуль ядра не соберётся. Это проверено. Можно потом руками.

Написал в наш Devel - давайте это там обсудим, чтобы тут не флеймить много.

Собрал linux-cifs-1.0-alt7

Он лежит в боксе (мини-репозитории) etercifs:

ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/

Там заменил в спеке 'service %name' на '%_initdir/%name'

Попробуйте.

Собрал linux-cifs-1.0-alt8

Там в спеке заменил Serial на Epoch по просьбе Бориса.

Верните пожалуйста Serial обратно
И вызов сборки модуля если и делать, то при запуске самого сервиса, а не при установке (при установке нельзя, сломается инсталлятор Альта например)
Для запуска есть макрос
%start_service 

(In reply to comment #21)
> Верните пожалуйста Serial обратно
я против, потому что serial нет как минимум в rpm CentOS

(In reply to comment #21)
> Верните пожалуйста Serial обратно
> И вызов сборки модуля если и делать, то при
> запуске самого сервиса, а не при установке
> (при установке нельзя, сломается
> инсталлятор Альта например)
> Для запуска есть макрос
> %start_service 
> 

Serial в будущем верну, если это нужно. Вы скажите точно, а то пока нет согласия в этом вопросе. :) Пока можно просто брать alt7 - там все то же самое, но ещё пока Serial.

По второму вопросу хотелось бы выяснить поподробнее.

1. С инсталлятором альта при установке linux-cifs "из коробки" ничего не происходит, по крайней мере в Virtualbox. Пользователь без каких-то усилий получает собранный модуль.

2. В строке 

%_initdir/%name build && %_initdir/%name start ||:

не исмользуется %start_service из-за того, что нет подобного макроса для build, а почему мы при старте так не написали я уже не помню. Или были какие-то проблемы или для того, строчки одинаковые были

помимо всего прочего Serial считается устаревшим-)
надо FR на rpmbph, чтобы он подменял, и в спек писать все что угодно

Я думаю что возможно надо вообще переименовать пакет, раз у него сменилось содержание (например, назвать его etercifs).
Если всё же оставлять название, тогда версию пакета сделать 2.0,
и Serial/Epoch не потребуется.

(In reply to comment #25)
> Я думаю что возможно надо вообще
> переименовать пакет, раз у него сменилось
> содержание (например, назвать его etercifs).
> Если всё же оставлять название, тогда
> версию пакета сделать 2.0,
> и Serial/Epoch не потребуется.
> 

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

2. Убрал сборку и запуск сервиса при установке rpm

Теперь при установке rpm выводится сообщение

Committing changes...
Preparing...                 ########################### [100%]
1: linux-cifs                ########################### [100%]
Etersoft CIFS modudule...                               [PASSED]
Done.

из-за того, что %post_service %name - (то есть скрипт /usr/sbin/post_service в альте) не только регистрирует и добавляет в chkconfig, но и пытается рестартануть, но это не получается из-за отсутствие собранного модуля. Думаю это не критично.

После установки linux-cifs теперь следует собрать модуль и его стартануть. В Альте:

service linux-cifs build
service linux-cifs start

TODO: В дальнейшем буду менять rc-скрипт, чтобы он при запуске проверял, есть ли модуль и, если нет, то собирал его. Это полезно будет также и при обновлении ядра (если обновился только релиз, то сработает, а если и версия, то только при наличии сорцов, о чем можно выводить сообщение)

Но тут есть один подводный камень - при установке rpm ведь происходит рестарт службы - может в таком случае начать собираться модуль. А мы этого опасаемся.

3. Поднял версию до 2.0 и убрал сериал. Это повлекло то, что теперь надо этот пакет в систему загнать руками (например rpm -Uhv --oldpackage). Но так как мы это пока не отдавали пользователям, то, думаю, некритично.

То же самое касается пакета kernel-source-etercifs-legacy-1.50c

Он был kernel-source-eterc~50c-alt9.noarch.rpm

а стал kernel-source-eterc~50c-alt1.noarch.rpm

и его тоже надо руками переставить. Но можно это и не делать - он ни на байт не поменялся. Если такая ситуация кажется кривой, то я выделю legacy-сорцы в отдельный srpm.

Собралось. Лежит в var/ftp/pub/Etersoft/EterCIFS/
Есть проблема с BuildRequires(pre): rpm-build-kernel
Этот пакет кладет файл kernel в macros.d, что на большинстве систем не работает. Пришлось руками дописывать нужные макросы в /etc/rpm/macros.

(In reply to comment #27)
> Собралось. Лежит в var/ftp/pub/Etersoft/EterCIFS/
> Есть проблема с BuildRequires(pre): rpm-build-kernel
> Этот пакет кладет файл kernel в macros.d, что на
> большинстве систем не работает. Пришлось
> руками дописывать нужные макросы в
> /etc/rpm/macros.
> 

1. А пакеты с исходниками модуля для остальных дистрибутивов как будут поставляться?

2. В ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/ должны скоро появиться linux-cifs-3.0 и etercifs-3.0. У нас уже с начала недели есть, но на Питерский ftp никак не доедут. linux-cifs - это старая версия, etercifs - новая. В старой версии для Этерсофтовских флагов используются биты 29–31, а в новой – 21–23. В остальном - пакеты такие же, как и в версии 2.0. Плюс ведется работа с исходниками модулей ядра - привносятся изменения из ядерного апстрима в соответствующие ветки.

см. http://wiki.etersoft.ru/Etercifs и спрашивайте меня, если нужно подробно пояснить что-то.

Собрал пакеты kernel-source-etercifs-2.6.26 и kernel-source-linux-cifs-2.6.26
версия cifs там 1.53. Исходники брались из ветки ядра 2.6.26.5. В дальнейшем, как и другие, будут обновляться при обновлении на kernel.org

Зависимости от этих пакетов соответственно в пакетах etercifs и linux-cifs пока не поставил. Хотелось бы потестировать. Пока все, что я смог по тестированию - это на виртуалбоксе поставить на АЛЬТ лакостисовское ядро 2.6.26 и проверить собираемость, запускаемость этих модулей, а также монтирование шары.

Следующая задача - оторвать работу с /proc в пакете etercifs и в исходниках удалить соответствующий код, а также сделать пакет для ядра 2.6.27rc ибо свежая Ubuntu будет выходить именно с ядром 2.6.27 (вроде как).

> для ядра 2.6.27rc ибо свежая Ubuntu будет выходить
> именно с ядром 2.6.27 (вроде как).
а также сусе 11.1 и федора 10

Собраны пакеты

etercifs-3.3-alt1
linux-cifs-3.2-alt1

Теперь исходники пакуются внутрь этих пакетов. Кроме флагов, пакеты различаются тем, что в etercifs не отключаются LinuxExtersions (см. багу 2563 ) и тем, что последнее ядро в linux-cifs - это 2.6.26. В etercifs уже есть 2.6.27

Пакеты kernel-source-..... больше не требуются.

Большая просьба - протестировать эти пакеты под различными системами, и протестировать работу 1c на etercifs.

Хорошо бы комментарий, на каком этапе больше не требуется kernel-source- и как устроено новое решение.

(In reply to comment #32)
> Хорошо бы комментарий, на каком этапе
> больше не требуется kernel-source- и как устроено
> новое решение.
> 

Мы это обсуждали - теперь внутри rpm содержится папка sources, внутри которой находятся папки legacy и несколько папок вида 2.6.2х, содержащих исходники.

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

Распаковываются исходники в %datadir/%name/sources

В остальном сборка - по-прежнему.

см. http://wiki.etersoft.ru/Etercifs - я там что-то поправил в соответствии с реалиями.

(In reply to comment #32)
> на каком этапе больше не требуется kernel-source-

Для

etercifs >= 3.3-alt1
linux-cifs >= 3.2-alt1

не требуется kernel-source-. Все внутри.

Мы говорили про сборочные зависимости, но в таком случае все равно пришлось бы пакетить кучу отдельных пакетов. Это имеет как плюсы, так и минусы. Мы решили копировать исходники из репозитория cifs-2.6 в etercifs и затем пакетить его со всеми доступными исходниками.

Теперь в нашем боксе

ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/

Всего 2 пакета и их достаточно. Собираемость и компиляция модуля проверены для ядра 2.6.25, а для остальных ядер сборка аналогична, так что проблем быть не должно. Работа проведена рутинная, создана база для более удобного внесения дальнейших возможных изменений. Главное - не менять исходники (sources/2.6.2x) в репозитории etercifs. Исходники оставлены нераспакованные для удобства просмотра разницы и удобства запаковки. А _вся_ работа должна происходить в репозитории cifs-2.6. В том числе и работа с обновлением из апстрима.

В новой сборке есть проблема... симлинки для legacy исходников проставлены не верно - во время упаковки не раскрывается макрос %src_legacy_vers

(In reply to comment #36)
> В новой сборке есть проблема... симлинки для
> legacy исходников проставлены не верно - во
> время упаковки не раскрывается макрос
> %src_legacy_vers
> 

Это проблема копирования длинной строки в дурацком редакторе mc!

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

diff --git a/linux-cifs.spec b/linux-cifs.spec
@@ -85,7 +85,7 @@ mkdir -p %buildroot/%etercifs_src
-  ln -s %src_package_name-legacy-%src_legacy_version.tar.bz2 %buildroot/%etercifs_src/%src_package_name-2.6.$N-%src_legacy_vers
+  ln -s %src_package_name-legacy-%src_legacy_version.tar.bz2 %buildroot/%etercifs_src/%src_package_name-2.6.$N-%src_legacy_version.tar.bz2

В etercifs все нормально, в linux-cifs бага.

Завтра сделаю alt2.

Думаю, что по косякам etercifs либо будут создаваться конкретные баги, либо следует писать в 2220.