Ночную сборку можно производить автоматически, или полуавтоматически, с помощью fasm. Сборка занимает 1-2 сек. Пример или альфа версию кода я сбросил майку (Mike.dld), так что ждем от него решения.

А можно посмотреть решение? И что мешает делать автоматически?
Еще меня интересует вопрос, как ядро сжать под linux-ом

turbanoff wrote:Еще меня интересует вопрос, как ядро сжать под linux-ом

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

turbanoff wrote:А можно посмотреть решение? И что мешает делать автоматически?

Ссылку сбросил через PM. При добавлении нового файла нужно модифицировать скрипт.
Желательно kpack'ом предварительно сжать все программы, скрипт собирает образ floppy 1.44 из готовых, собранных программ.

От Майка получен положительный отзыв о моей работе. Я надеюсь, в ближайшее время ночные сборки в формате дискеты восстановятся.

Я не понимаю, в чём сложности настройки, которые до сих пор мешают сделать автоматическую сборку образов дискет на сервере. Судя по 404-й странице, отдаваемой сервером kolibrios.org, там стоит Linux. fasm под Linux давно существует, kpack не столь давно, но тоже работает, образ вообще можно собирать встроенными средствами - через mount - а если не устраивает требование прав рута для mount, то есть mtools. Я вчера из интереса посидела пару часов, составила makefile полуавтоматически из содержимого kolibri.img из последней ночной сборки и build_all.bat из исходников её же, ничего сложного не заметила. На случай, если кого-нибудь заинтересует, я выложила результаты в http://ftp.kolibrios.org/users/CleverMouse/imgbuild/ - файл data.7z содержит Makefile и данные, не собираемые из исходников на svn; сборка осуществляется командой make в предположении, что в PATH есть fasm,kpack,mtools, в папке ../repos есть локальная копия репозитория, файл macros.inc также скопирован как MACROS.INC в папке с данными и в ../repos/programs; kolibri.img - результат сборки. Я обращаю внимание, что Makefile - скорее proof-of-concept, он НЕ собирает ядро, он собирает только те программы, исходники которых написаны на fasm и есть на svn - соответственно, в kolibri.img старое ядро и обновлены только указанные программы, - в нём не указаны зависимости. Я просто не хотела тратить слишком много времени на, возможно, ненужную вещь.

Если причиной является нехватка времени, я могу заняться настройкой, если меня пустят на сервер - в смысле выдачи ssh-аккаунта, у которого есть права на запись в какой-нибудь скрипт, вызываемый из post-commit хука svn, и права на запись в какую-нибудь область сайта для выкладывания результатов, в предположении, что на сервере стоит набор gcc/g++/make - тогда остальное из нужного я смогу собрать там сама.

Независимо от вышесказанного я предлагаю обсудить вопрос данных, необходимых для сборки образов. Я считаю разумным, чтобы дополнительные данные мог изменять достаточно широкий круг людей, как и исходные тексты программ. Поэтому я выношу на обсуждение предложение вынести упомянутые данные - конфиги, бинарники, которые сложно собрать автоматически, сборочную программу, будь она makefile'ом, скриптом или специальной программой, - завести на svn либо четвёртой папкой с именем типа data или extra или build в корне основного репозитория, либо завести рядом второй репозиторий на параллельном порту. Что скажете?

CleverMouse wrote:Независимо от вышесказанного я предлагаю обсудить вопрос данных, необходимых для сборки образов. Я считаю разумным, чтобы дополнительные данные мог изменять достаточно широкий круг людей, как и исходные тексты программ. Поэтому я выношу на обсуждение предложение вынести упомянутые данные - конфиги, бинарники, которые сложно собрать автоматически, сборочную программу, будь она makefile'ом, скриптом или специальной программой, - завести на svn либо четвёртой папкой с именем типа data или extra или build в корне основного репозитория, либо завести рядом второй репозиторий на параллельном порту. Что скажете?

Идею считаю разумной. В качестве примера предлагаю вариант с libre.fm: Т.е. код - в одном месте, не_код - в другом. Тем более, что у нас кроме сборочных скриптов есть и такие вещи как скины, обои, шрифты, иконки, в поисках которых приходится лазить по форуму (не всегда успешно, кстати).

В общем, я был бы рад видеть отдельный репозиторий.

Я тоже за отдельный репозиторий для бинарников. Некоторые вещи сложно собрать не разработчику.

CleverMouse wrote:Если причиной является нехватка времени, я могу заняться настройкой, если меня пустят на сервер - в смысле выдачи ssh-аккаунта, у которого есть права на запись в какой-нибудь скрипт, вызываемый из post-commit хука svn, и права на запись в какую-нибудь область сайта для выкладывания результатов, в предположении, что на сервере стоит набор gcc/g++/make - тогда остальное из нужного я смогу собрать там сама.

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

Если кто-то сможет взять её на себя - то я со своей стороны торжественно обещаю, что постараюсь больше не брюзжать по пустякам .

И призываю всех к понижению градуса неконструктивной критики в Новом году.

С наступающим!

Ночная сборка, образ дискеты собирается с помощью fasm. Но решение не допилено, существуют ошибки в образе дискеты. В ближайшее время не могу заняться этой проблемой т.к. загружен на работе.

Архив 550 кб http://filesurf.ru/211766

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

troll mode on Разве основной причиной ухода diamond'а были ночные сборки, а не тенденции "просто почесать языками" и "пописать в нуль-кольце на сях" (c) diamond.kolibrios.org? Интересно, что он сказал бы про оболочку на Delphi над своими ассемблерными mtldr_install и usb_boot...

Why not use a folder on the FTP server to store the binaries?
Everybody can read from it, and registered users can make changes too..

I propose to use the same structure as the SVN server.
Additionally, a script can be made on the server to automatically compile some of the programs on SVN updates.

CleverMouse wrote:<Lrz>, я посмотрела твой архив. Во-первых, там нет поддержки длинных имён файлов. Во-вторых, он занимается только сборкой образа дискеты из готовых файлов, а это только последняя операция в цепочке полной сборки.

Да, поддержка fat12, и только коротких имен (8+3), допилить полные имена пока нет возможности.
Скрипт делает финальную сборку, в принципе никто не мешает предварительно собирать из исходников во временную папку, затем собирать образ. Все по желанию.
На SVN нет всех исходников приложений, которые используются для сборки дистрибутива, только по этому сборка ведется из уже готовых бинарников.

Предложение hidnplayer считаю оптимальным.

hidnplayr, a registered user can make changes only in the corresponding directory, there is no public place writable by all registered users. Anyway, FTP server has also the following disadvantages: most obvious - it doesn't keep the history, which can be useful; also FTP uploads are not atomic operations, and there is no analog of SVN post-commit hook, so there is no obvious way to run the builder immediately after something has changed.