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

Переименовал ветку lp:~al-lunev/kicad/GOST-doc-gen в lp:~kicad-gost-committers/kicad/kicad,
а ветку lp:~pcad2kicad-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/pcad2kicad

Добавил в нее участников среди русскоязычных разработчиков.
Если кто-то не хочет быть участником среди добавленных, дайте знать.

Все кто в этом списке, у вас есть доступ на запись в https://code.launchpad.net/~kicad-gost-comm...ers/kicad/kicad

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

Данную ветку рассматриваю альтернативной ветке lp:kicad.
Предлагаю давать возможность работать в ветке lp:~kicad-gost-committers/kicad/kicad по возможности всем желающим, не только ГОСТ-разработчикам.

Планирую ветку lp:~kicad-gost-committers/kicad/pcad2kicad смержить с lp:~kicad-gost-committers/kicad/kicad

Если есть замечания / пожелания, пишите.

Правильно ли я понимаю, что из исходников этой ветки можно будет также собрать полноценный вариант с не-ГОСТ рамкой? И что теперь уже в нее будут периодически вливаться изменения основной ветки, а не наоборот? То есть в нее можно спокойно добавлять улучшения не связанные именно с ГОСТ-документацией?

Да, так.
Насчет ГОСТ рамки предлагаю сделать так, чтобы можно было выбирать вид рамки прямо из меню программы в настройках.

Единственное, может есть смысл все-таки оставить конструкции #ifdef KICAD_GOST #endif с целью сохранить некую границу между lp:kicad и lp:~kicad-gost-committers/kicad/kicad. Это, с моей точки зрения, облегчит работу при слияниях.

Не исключаю, что часть исходников все-таки будет вливаться из lp:~kicad-gost-committers/kicad/kicad обратно в lp:kicad.
Данное действие сможет делать самостоятельно Андрей Федорушков, если нет для этого препятствий. Судя по настрою админов, чувствую препятствия есть. И я пока не знаю мнение Андрея.
Также данное действие смогут делать админы lp:kicad, если вдруг снизойдут до этого.

Если вы поддерживаете сохранить конструкции #ifdef KICAD_GOST #endif, то изменения не касающиеся ГОСТ также предлагаю помещать в эти конструкции. Поскольку любые изменения, не только ГОСТ, сложно протолкнуть в lp:kicad. А конструкция #ifdef KICAD_GOST #endif, как я уже сказал, с моей точки зрения, облегчит нам работу по слиянию. И скорее всего облегчит работу тем, кто будет вливать изменения в lp:kicad.

Поскольку предлагаю помещать любые изменения в #ifdef KICAD_GOST #endif, при условии, что вы согласны и считаете это правильным, возможно имеет смысл переименовать эти дефайны в какое-то более универсальное имя вместо KICAD_GOST.

Очень давно хочется такую возможность. Приходится работать с обоими вариантами и переключать их копированием разных сборок в папку запуска несколько неудобно. Также нужно, чтобы выбор рамки сохранялся в файле платы. Наверное для совместимости лучше сделать сохранение в файле метки"ГОСТ-рамка", а при ее отсутствии включать буржуйскую. Тогда файл с буржуйской рамкой не будет содержать непонятных для основной версии записей.
Да, если этот #define не будет привязан к рамке, то под него можно будет помещать и код, используемый и с другой рамкой.

К сожалению я вовремя не заметил, что есть эта проблема, баг появился начиная с ревизии 4115, где я попытался сделать независимое окно менеджера компонентов, чтобы можно было одновременно работать и в eeschema и в менеджере компонентов.

Поразбирался с этой проблемой, с одной стороны обнаружил, что wxFrame некорректно обрабатывает событие wxEVT_ACTIVATE (фрейм теряет фокус даже, если нажать на ComboBox этого фрейма), с другой стороны я не учел, что при добавлении нового исполнения, выпадет диалоговое окно, и фрейм по нормальной логике потеряет фокус.

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

Это временная мера. Буду дорабатывать этот механизм, чтобы все-таки окно менеджера было независимым окном и было бы можно работать одновременно с eeschema и менеджером компонентов, не закрывая каждый раз окно менеджера компонентов.

По крайней мере сейчас ничего не "падает".

Текущая ревизия 4117 (lp:~kicad-gost-committers/kicad/kicad).

Мне в личном письме Жан-Пьер написал такое, что существенно меняет картину по поддержке ГОСТ.
Я ему "порекомендовал" описать их намерения и видение по этому поводу публично на developer mailing list.
Данные намерения ожидаются в пользу ГОСТ. Как будет на самом деле, посмотрим.

Собрал последнюю ревизию из репозитария lp:~kicad-gost-committers/kicad/kicad
Кроме нее больше ничего не докачивал.

Вылезает окно с ошибкой при попытке сгенерировать перечень: RPC_DOC_IFACE: Unable to load document


Собирал с такими опциями

Что я сделал не так?

А какое наименование дистрибутива Linux? полностью?

Это может быть связано с тем, что я не заполнил таблицу? Хотя по идее "как-то" заполненный документ должен был сформироваться.

Для Ubuntu 13.04 32-bit необходимо было установить пакет python-uno:
sudo apt-get install python-uno

Скорее всего для любой версии Ubuntu данный пакет необходимо установить.
Есть подозрение, что и для других дистрибутивов Linux это будет необходимо. Пока не знаю, нужно собрать статистику.

Однако, судя по ошибке, не похоже, что это из-за неустановленного python-uno.
В любом случае необходимо установить этот пакет (если еще не установлен).
Если не поможет, я сегодня ночью, либо завтра установлю виртуалку с Ubuntu 10.04, посмотрю что не так.

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

На машине нет OpenOffice. Стоит только LibreOffice 4.0. Устанаваливался из deb пакетов.
Еще есть вопрос по русификации самого окна GOST_Tools. Нужно докачать какие-то пакеты или это просто временно так сделано?

LibreOffice тоже поддержан. Как раз в Ubuntu 13.04 выполнялась отладка на базе LibreOffice.
OK, тогда посмотрю на виртуалке что получится.

Руссификация в процессе. Ветку с документацией, соответствующую ветке lp:~kicad-gost-committers/kicad/kicad, создал здесь: lp:~kicad-gost-committers/kicad/doc

Установил Ubuntu 10.04 (http://releases.ubuntu.com/lucid/ubuntu-10.04.4-desktop-i386.iso) на виртуалку.

выполнил:


Пакет python-uno не устанавливал, он уже был установлен. (получается что данный пакет предустановлен по крайней мере в Debian 6 (Squeeze) и Ubuntu 10.04, а вот в Ubuntu 13.04 он не предустановлен почему-то).

У меня все запустилось, работает.
В этом дистрибутиве предустановлен OpenOffice 3.2.0 и системный Python 2.6.5.

Попробую приблизиться к Вашей конфигурации, tema-electric.

Выполнил все обновления, которые предложил Update Manager. Опять все работает.

LibreOffice в репозитории Ubuntu для Ubuntu 10.04 вообще нет.
А LibreOffice 4.0.3 есть в Ubuntu 13.04. Но чувствую, если пытаться установить эти пакеты из репозитория Ubuntu raring, то выполнится апгрейд всего дистрибутива до Ubuntu raring.

Пошел другим путем, скачал http://www.libreoffice.org/DownloadRedirec..._x86_deb.tar.gz
далее:


При запуске генератора перечня выпадает ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
Проверяю системный Python так и остался версии 2.6.5:


А вот в директории /opt/libreoffice4.0/program есть свой Python:


В данном случае понятно откуда ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
В дистрибутивах Debian Squeeze и Ubuntu raring предустановленные офисы идут без своего питона. Питон используется системный.
В GOST-doc-gen пока на это и рассчитывается, что используется системный Python под Linux.
Получается, что при другом способе установки (установка пакетов deb из LibreOffice_4.0.3_Linux_x86_deb.tar.gz) как и в Windows используется Python, идущий в поставке с офисом.
Как данную ситуацию исправить - мне понятно, это доработаем.

А вот все-таки откуда берется ошибка RPC_DOC_IFACE: Unable to load document мне не понятно
tema-electric, есть идеи, почему не получается повторить ситуацию как у Вас?
Также пришлите, пожалуйста, результат выполнения команды:
$ python --version

Open Office вроде штатный шел, но я его снес после уставновки LibreOffice. Сносил культурно через GUI. Не помню, как называется штатная утилита Update Center или Package Center или ....


По питону станет известно только в понедельник. Тачанка на работе .
Есть вероятность, что стоит питон 2.7, но она очень маленькая и там инсталяция была через altinstall. Это точно было на старой системе, а на новой, вроде, не успел еще.


Хорошо бы знать, что именно пытается сделать в это время python.
Может права ограничены? Хотя у меня ubuntu недавно установлена, и много дел в ней я еще не успел наворотить.

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

Да, сначала давайте так и сделаем.

В любом случае добавил поддержку инсталляций OpenOffice/LibreOffice, которые поставляются вместе с Python в случае Linux (это те установочные пакеты, которые можно скачать с сайтов www.openoffice.org и www.libreoffice.org).

текущая ревизия 4119 (lp:~kicad-gost-committers/kicad/kicad)

У меня еще вопрос к Юрию Викулову и Андрею Федорушкову по руссификации (или может тоже кто подскажет). Делаю следующее:
1) bzr branch lp:kicad
2) bzr update -r4115 (на ревизию, для которой в последний раз делался русский перевод)
3) bzr branch lp:~kicad-developers/kicad/doc (текущая ревизия 441)
4) запускаю poedit (версия 1.4.2)
5) открываю File->Open, выбираю файл в хранилище документации: doc/internat/ru/kicad.po
6) открываю Catalog->Settings->Paths, изменяю Base path: с /home/faa/Project/kicad-dev на корневую директорию моего клона lp:kicad
7) нажимаю Catalog->Update from sources. Появляется окошко Update summary, в котором написано, что изменений нет (0 new, 0 obsolete)
8) нажимаю OK
9) нажимаю File->Save, после чего файл internat/ru/kicad.po примерно на 50% отличается от оригинала (пересортица строк по всему файлу).

Из-за чего это может быть? Может влияет версия poedit? Кто подскажет тогда с помощью какой версии poedit был сохранен файл internat/ru/kicad.po (в его содержимом версия poedit не указана).
Не хочется добавлять перевод менеджера компонентов на русский язык, в результате чего появится порядка 20 новых строк, но при этом весь файл internat/ru/kicad.po изменится до неузнаваемости.

Как обещал, влил ветку lp:~kicad-gost-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/kicad
ветку lp:~kicad-gost-committers/kicad/pcad2kicad удалил.

Также добавил в диалоговое окно "о программе" ссылку на этот форум (кто-то помню на этом форуме предлагал это сделать).

Добавил в eeschema пункт меню: Tools->Run pcad2kicadsch converter, чтобы не искать и не запускать конвертер из командной строки.

Я использую poedit 1.4.1 в Windows. Что у Андрея не знаю, он формирует ru/kicad.po/mo.
Предложения по улучшению перевода отсылаю ему или через форум. Исходники давно не сканировал.

В консольке тихо. Никаких записей об ошибках.
Запустил kicad под root, бестолку.
Поставил штатный OpenOffice. Не помогло.
Снес python-uno и установил заново. Не помогло.

Пересобираю последнюю версию. Алгоритм сборки один и тот же всегда.
Хочу обратить внимание, на то что инсталирую в /usr. Помнится, штатный кикад вставал в /usr/local
Установка через checkinstall не всегда заканчивалась хорошо. В таких случаях я использовал sudo dpkg -i --force-all kicad.
Не знаю, на сколько это плохо. С ГОСТовским KiCAD пока еще не применял.
Установка всегда идет поверх существующей версии.


Пересобрал

Все также: RPC_DOC_IFACE: Unable to load document

Прикладываю список пакетов в моей системе. Может у меня чего-то не хватает.
Нажмите для просмотра прикрепленного файла

Удалил я свою предыдущую установку и повторил именно как у Вас:

с параметрами что-то не так: USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY
по идее ж должно -D перед ними. Но это не играет роли сейчас.

В результате установился kicad в /usr и все работает.
Прикладываю свой список пакетов.

Хочу обратить внимание, что в Вашем списке пакетов мне подозрительно место:

То есть часть общих пакетов идут из одной установки, а kicad - из другой.
Предлагаю сделать следующее:


Я попробовал сэмулировать такую же ситуацию как у Вас, но мне не удалось установить пакет, выдалась ошибка конфликта, что логично:

Привычка с винды осталась поверх закатывать. Да и библиотеки вроде в common лежат.
Попробовал. Даже kicad-doc-ru удалил. Бестолку.


ммм, у dpkg есть ключик --force-all, который поставит один кикад поверх другого.

Попробовал многое. Сравнил пакеты с разных систем и доустановил отсутствующие (freeglut3-dev). Еще питон 3.1 поставил на всякий случай.
Пробовал снести весь kicad полностью (apt-get purge kicad) и поставить заново. Заколдованный круг.
Ваш deb пакет подойдет для моей машины или нет? Может проблема в сборке? Что-то где-то не так компилится...

Сегодняшний deb пакет смогу дать поздно вечером только, дома он.

1) Попробуйте выполнить which kicad
Допустим результат будет /usr/local/bin/kicad
2) Далее нужно выполнить ls -la /usr/local/bin/kicad
в списке должно показать директорию GOST-doc-gen
3) Далее нужно выполнить ls -laR /usr/local/share/kicad/GOST-doc-gen

Результат выполнения каждой из 3-х команд, пожалуйста, покажите.

Улучшил диагностику открытия файлов odt в ревизии 4124.
Пересобрал для ревизии 4124 deb файл (прикреплен к сообщению).
Там теперь должна быть ошибка с указанием пути к файлу, который не может открыть через RPC. Пожалуйста, пришлите эту инфу тоже.

Поставил вашу сборку, окошко выпало, соответственно, с другой подписью:

Добавил логирование RPC команд в файл uno_iface.py, приходящих из eeschema.
Нужно выполнить:
1) распаковать прикрепленный архив
2) sudo cp uno_iface.py /share/kicad/GOST-doc-gen/templates/uno_iface.py
3) запустить eeschema, попытаться сгенерировать КД
4) в Вашей HOME директории должен будет появиться файл kicad_uno_iface.log, пожалуйста, пришлите его.

Немного кривой путь ... но я поправил как надо ( /usr/share/kicad/GOST-doc-gen/uno_iface.py).
Содержимое лога.

Еще раз, пожалуйста )

Похоже, что проблема на уровне взаимодействия с офисом. Пока объснения не видно.
Я так понимаю, что выпадает только ошибка и окно офиса не открывается вообще в этот момент?

Приложил еще один вариант скрипта.
1) нужно сделать тоже самое еще раз как в предыдущем сообщении и прислать лог.
2) далее выполнить и прислать результат:

3) далее выполнить soffice из командной строки (именно так, чтобы убедиться, что офис так запускается), должен открыться офис. В меню Help->About... скопировать полную версию офиса и прислать это значение.

Просьба в системе ничего не переустанавливать пока (офис, питон, python-uno).

Нет, офис вообще себя никак не проявляет.


Скрипт будущего Тю-тю.


$ ls /opt
Adobe deadbeef libreoffice4.0


soffice - неа, не работает. Либра запускается иначе ... libreoffice4.0

Эхх, забыл скрипт я приложить ) Уже не дома я, нет его с собой.

/opt/libreoffice4.0/program/python --version
Что пишет?

Я понимаю таким образом же запускается? :
/opt/libreoffice4.0/program/soffice

Если да, то какая версия в Help->About... ?

Help->About Версия 4.0.1.2 (ID сборки: 84102822e3d61eb989ddd325abf1ac077904985)

С версиями все в порядке.

Попробуйте сделать следующее:
1) убедиться, что никакие процессы soffice не запущены:
$ ps aux | grep soffice
a-lunev 17890 0.0 0.0 7548 880 pts/5 S+ 14:59 0:00 grep soffice

(никаких других строк быть не должно)

2) запустить интерпретатор
$ /opt/libreoffice4.0/program/python

3) прямо в окне интерпретатора вбить последовательно строки:
>>> import uno
>>> local = uno.getComponentContext()
>>> resolver = local.ServiceManager.createInstanceWithContext( "com.sun.star.bridge.UnoUrlResolver", local )
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.NoConnectException: Connector : couldn't connect to socket (Success)

Должна появиться ошибка как указано.

4) Не закрывая интерпретатор, выполнить в другом терминале:
$ /opt/libreoffice4.0/program/soffice --invisible "--accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"

5) повторить в интерпретаторе:
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
ошибок быть не должно теперь

6) далее:
>>> desktop = context.ServiceManager.createInstanceWithContext( "com.sun.star.frame.Desktop", context )
>>> document = desktop.loadComponentFromURL( "file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt", "_blank", 0, () )

должен открыться libreoffice с открытым документом

Все получилось. Но прежде чем все получилось я грохнул офис в трее, что стартует по автозапуску, и еще офис по автозапуску для root. Чего он был запущен, я не совсем понял.

Выглядело это так ...


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

Не могу понять откуда такая строка появилась:
"tenzor 2257 0.0 0.5 188196 10664 ? Sl May20 0:02 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager --invisible --accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4"

Насчет закрытия формы, есть сейчас такой нюанс, если форма еще не успела полностью заполниться, и ее закрыть, то начнут выпадать ошибки в окне менеджера компонентов. То есть GOST-doc-gen продолжает заполнять форму, а формы уже нет.
Сейчас нужно либо дожидаться пока КД сгенерируется и заполнится до последнего листа, либо ждать пока доработаю этот момент

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

Мягко говоря, аномалия. Перезапустил тачанку сегодня:

И что самое непонятное, GOST Tools работает. Ему больше ничего не надо. Неужели надо было перезагрузиться?

У GOST Component manager нет пока русификации? Я залил с launchpad вашу ветку kicad/doc.
Поле "Наименование" содержит названия типа Capacitor ... Resistor ...
Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются

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

Спасибо

Насчет перезагрузки, видимо из-за того, что оказались установлены оба типа офиса, да еще и одновременно запущены, были такие глюки. Наверно можно было не перезагружать, а просто сделать sudo kill лишних процессов.

Ветку lp:~kicad-gost-committers/kicad/doc пока только создал, но русский перевод еще не добавил. У меня пока не решенный вопрос с poedit, о котором я писал ранее.

Насчет
"Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются"
так и есть. Изначально я делал все на русском, поскольку бессмысленно делать еще на каком-то другом языке.
Был разговор с Jean-Pierre, он требовал, чтобы GOST-doc-gen был по умолчанию на английском. Согласиться с этим не могу.
Однако, для менеджера компонентов думаю есть смысл поддержки интернационализации, потому что он дает функции, которые будут полезны любому пользователю.
Таким образом, начал адаптировать на английский. А поскольку грамматика у русского и английского разная, то поплыла логика формирования падежей, числа и т.д.
Пока пришел к выводу, что GUI можно делать через интернационализацию, а содержимое выпадающих списков таких как поле "Наименование", надо формировать на основе языка, выбранного где-то в меню.
К примеру, я люблю GUI на английском, но значения в выпадающих списках менеджера компонентов мне нужны только на русском. Также такая опция выбора языка в меню дала бы возможность четко определять логику по формированию языковых конструкций в самом GOST-doc-gen в зависимости от языка. Так что буду это дорабатывать.

Самая острая фаза ремонта моей квартиры миновала и у меня стало появляться немного времени для форума. Первым делом решил потестировать возможность вывода текстовой документации. Поскольку вариант от AVL не требует что-то доустанавливать (а ЛибреОфис у меня и так уже установлен), то я остановился именно на нем. Скачал сборку для винды kicad_ins_gost_docgen_4115 с ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_doc/lunev_set/ и открыл схему проекта. Далее, зашел в «инструменты» и запустил «GOST Tools” и в раскрывшемся окне зашел в “файл» и выбрал генерацию спецификации. После этого запустился ЛибреОфис и показал пустой бланк (нет ни названия схемы, ни компонентов в списке).
Казалось бы, работая с конкретной схемой, можно надеяться, что все ее атрибуты будут автоматически использованы при формировании документа, а у меня что-то ничего не получилось.
Каких-то дополнительных возможностей изменить сложившуюся ситуацию к лучшему в опциях менеджера перечня я не обнаружил, да и хоть какая-то краткая инструкция по использованию GOST Tools мне на глаза тоже не попалась. Делаю вывод, ремонт квартиры совсем меня доканал и я не врубаюсь в то, что очевидно для для остальных форумцев, которые успешно генерят себе текстовую документацию в своих проектах и в ус не дуют.
AVL, подскажите, что нужно сделать, чтобы бланк спецификации был сгенерирован с заполненными полями.

Более актуальная сборка ftp://ftp.kicad.ru/pub/kicad/install/win3...it_bin_4126.zip, рекомендую начать с нее.

К сожалению, я не писал документацию на менеджер компонентов + GOST-doc-gen.
Скорее всего прийдется это сделать.
Пока отвечаю на Ваш вопрос. По умолчанию (если Вы взяли сырую схему) все компоненты имеют не заданные поля "Наименование" (атрибут Title), ну и остальные поля тоже не заданы.
Компонент начинает отображаться в КД после того как будет задано поле "Наименование", например, Конденсатор.
Сделано так для удобства. К примеру в схеме 1000 компонентов. Вы решили поработать и назначили через менеджер компонентов параметры двухстам компонентам, и решили продолжить работать на следующий день. Вы открываете проект, смотрите какие компоненты уже имеют заданное поле "Наименование", а какие имеют пустое поле. И понимаете, что заполнять нужно дальше те компоненты, у которых поле "Наименование" пустое.
Также скоро добавлю иконки напротив каждого компонента, будет нагляднее эта логика.

Также не забывайте про пример корректно заполненной схемы demos/GOST/multivibrator.sch

Конечно же есть ряд правил как нужно работать с менеджером компонентов. Документацию делать надо.


Проверил 1.4.1 под винду. Проблема, к сожалению, не ушла.

Проверил также версии 1.3.9, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.5.5. Безуспешно.

Скачал, установил. Если я правильно понял, то это уже третий вид нумерации сборок в дополнение к стабильной и обычным тестовым.

Да, схема у меня «сырая». Задал у нескольких компонентов в списке поле «наименование» и, о чудо, - спецификация на эти несколько компонентов сформировалась! Это вызвало необычайно бурные эмоции, т. к. наконец-то появилась эта долгожданная возможность вывода текстовой документации! ОГРОМНОЕ ВАМ СПАСИБО!
Кстати, самый первый компонент в моей схеме — кварцевый резонатор, а его в списке наименований нет. Более детальное тестирование продолжу несколько позже, т. к. мой ремонт квартиры еще не закончен, но радость от сегодняшнего события просто огромная дает стимул побыстрее его завершить!

Документацию никто не любит делать, это естественно, т. к. все силы и время съедает написание программы, но все же хотя бы несколько пояснительных предложений стоит сочинить, т. к. только в этом случае созданное приложение будет использоваться с максимальной эффективностью. Хорошая документация, что позолота на добротном изделии.
----------------
И еще, обычно Жан Пьер заканчивает вылизывание стабильной сборки не позже мая месяца, по крайней мере так было раньше. Так вот, возможно версия 4017 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable или какая-то ближайшая как раз этой самой наифинальной и будет. Так вот, хотелось бы иметь стабильную сборку со всеми последними усовершенствованиями в т.ч. и с генератором тектовой документации.

Если Вы имеете в виду попадание менеджера компонентов+GOST-doc-gen в ветку lp:kicad, то боюсь это не реально из-за серьезных разногласий с командой lp:kicad. Если будет время, почитайте, некоторая информация была озвучена на этом форуме.
В первоисточнике и в полном виде об этом можно почитать здесь:
https://code.launchpad.net/~kicad-gost-comm...d/+merge/163239
и здесь:
https://lists.launchpad.net/kicad-developers/msg10412.html

Поэтому была создана ветка lp:~kicad-gost-committers/kicad/kicad

AVL, я, к сожалению, почти не разбираюсь в тонкостях взаимодействия стабильной ветки Кикад со всеми остальными его ветками. По жизни я вынес для себя урок: без крайней необходимости не переходить со стабильной сборки на тестовую, т. к. у меня был досадный случай некоторой порчи проекта при работе на тестовой сборке.
Вот я и стараюсь работать только на стабильных сборках, а тестовыми только иногда для тестирования пользоваться.
Видимо я наивен, т. к. до этого дня считал, что стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности, т. е. «вылизанная». Если к такой сборке прикручивается некий завершенный и стабильный программный код для расширения ГОСТ-функциональности, то, весьма вероятно, что результирующий программный продукт тоже будет стабильным.
Словом, хотелось бы в обозримом будущем иметь такую стабильную сборку со всеми ГОСТ-наворотами, а не тест-сборку, дабы не наступать на старые грабли в виде порчи проекта в самый не подходящий момент.
Хочется верить, что такое пожелание не является не исполнимым и вскоре стабильная сборка «с полным фаршем» будет доступна. Иначе, я перестаю что-либо понимать в логике развития ГОСТ-Кикада - что, теперь стабильных ГОСТ-сборок никогда не будет?

По опыту работы с KiCAD в 2012 году пришел к выводу, что лучше собирать тестовые сборки. Тоже верил в стабильные по началу, пока не отправил герберы с косяками в заказ ... Как мне показалось, стабильные сборки мало кто тестит. А тестовые - наоборот.

Здесь могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.

Лично я не доверяю ни тестовым релизам, ни стабильным. Причем, что кто-то несет ответственность за полную исправность стабильного релиза? Нет, это не так.
Чтобы не испортить проект платы на любом из этапов ее разработки/сохранения на диск, я пользуюсь системой контроля версий. В данный момент использую git. Если становится понятно, что что-то пошло не так, то всегда можно вернуться к предыдущему коммиту и восстановить плату в нормальном виде.
Прежде, чем отдавать плату в производство, я обязательно визуально проверяю все сгенерированные gerber-слои и файлы сверловки. Удобная для этого программа - gerbv,
В случае с KiCad, стабильную сборку не использую никогда. Иначе буду сидеть в прошлом веке. Но это не значит, что так нужно делать всем. Каждый решает для себя сам и определяется с рисками.

P.S.:
NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

На самом деле пока не видел ни одной коммерческой лицензии, где не было бы подобного отказа от ответственности.

Когда в одной из сборок кикада в стабильную версию, да и в тестовую попали косяки с дугами при генерации герберов, то gerbv не показал косячную дугу, увы. Их показал только CAM350 и то когда уже дошло до разборок. Дуги образовывали окружность, и она была гораздо больше платы. Gerbv их просто не прорисовал, почему-то.

Да уж, не повезло. А KiCad GerbView тоже не показывает тот дефект?

Смотрел. Вроде не показал тогда. Сейчас проверил - показывает. Это про кикадовский viewer.
А так я им не пользуюсь. По началу пользовался. Причина проста.
В GerbV все настроено. В файле проекта (*.gvp) достаточно поменять ручками или скриптом имена герберов. Цвета слоев и порядок уже "как надо". Сами платы предпочитаю доводить по герберам. Там меньше лишних графических элементов. В Gerbv есть кнопка обновить ... а в кикадовском вьювере помойму нет.
Имена герберов тоже в кикаде излишне подробные. Для этого скрипт написан, в стиле

AVL
Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:
1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?
2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?
3) dcm-файл можно не формировать.

Ответ перенес в новую тему по pcad2kicad

AVL
А нельзя ли в GOST-doc-gen сборке реанимировать кнопку BOM (или вставить Generate BOM в Component Manager).
После работы с GOST Component Manager компоненты получают новые поля и атрибуты.
Обновленный BOM можно будет использовать разными способами. В частности,
для выпуска карт рабочих режимов ЭРИ (для аппаратуры ВН).