Re: [newbies] Права на pid-file в директории /run

[Николай Бурыкин]

09.09.2021 13:58, Michael Shigorin пишет:

On Fri, Aug 27, 2021 at 05:19:05PM +0300, Николай Бурыкин wrote:

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

А теперь?


Теперь отлично работает. Приходят и сообщения и дайджесты.
Спасибо.
На самом деле всё-таки странно.
Опцию "Блокировка отправки копий сообщений" я совершенно точно
включил уже после того как перестал получать сообщения.___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Права на pid-file в директории /run

[Николай Бурыкин]

> И отвечать кнопкой reply на уже имеющиеся письма, а не создавать 
каждый раз новое с тем же сабжем.


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

И нет, в спам они тоже не попадают.

___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Права на pid-file в директории /run

[Николай Бурыкин]

> Нужно делиться найденными ответами ;-)

Это запросто.
На самом деле я ошибся в своём выводе)) По крайней мере отчасти.
Как я понял есть две связанные вещи, влияющие на это:
1. tmpfile.d конфиг
2. sgid на каталоге, в котором будут создаваться pid-файлы.

Применительно к squid  на это 
влияют:
1. Файл squid.tmpfiles, который после установки попадает в 
/lib/tmpfiles.d/squid.conf

2. Строчка %attr(2770,root,%name) %dir %_runtimedir/%name в squid.spec


Если опять заблуждаюсь, просьба поправить :)

___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Права на pid-file в директории /run

[Николай Бурыкин]

Вопрос снят.
Пнул себя в сторону внимательного перечитывания man tmpfiles.d, и как ни 
странно нашёл там ответы)


___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Права на pid-file в директории /run

[Николай Бурыкин]

Добрый день.

Не могу никак понять на каком этапе сборки/конфигурации пакета можно
определить с какими правами будет создаваться pid-file в каталоге tmpfiles.d
после запуска своего сервиса.

Например есть пакет squid 
 . При 
установке этого пакета, и запуске сервиса или init-скрипта,
В каталоге /run/squid или /run создаётся файл squid.pid с владельцем 
root, и группой - squid.
Я не вижу в .service файле или init-скрипте, каких-то специфичных 
настроек, определяющих

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

Заранее спасибо.

___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Удаление Epoch из spec-файла

[Николай Бурыкин]

Нельзя. Epoch - это приставка к версии, а не ещё один суффикс, как 
Release. Для лучшего понимания, полная версия пакета выглядит так: 
Epoch:Version:Release


Спасибо. То есть, если я правильно понял, Epoch единожды добавленный в 
spec-файл,

уже никогда оттуда не удаляется, просто повышается версия, верно?


___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Удаление Epoch из spec-файла

[Николай Бурыкин]

Добрый день.

Взялся за обновление пакета tidy в репозитории, в ходе работы озадачился 
таким вопросом:
Можно ли/нужно ли удалять Epoch если релиз обновляется до следующей 
стабильной версии?
На мой взгляд вроде бы да, нужно удалить. Хотя бы по причине отсутствия 
причин добавления
Epoch, укзанных в статье с рекомендациями по написанию spec-файла 
.
Однако подтверждения этой мысли пока не нашёл, поэтому всё таки решил 
уточнить как будет

правильнее.

Так же добавляю ссылку 
 
на обсуждаемый спек-файл.


___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

[newbies] Заполнение Version в спек файле

[Николай Бурыкин]

Добрый день!

Пытаюсь собрать quickjs. Столкнулся с тем, что автор движка версионирует 
стабильные

релизы просто датой сборки.
То есть например: https://bellard.org/quickjs/quickjs-2021-03-27.tar.xz
Не могу сообразить, как правильно в этом случае будет заполнить поле 
Version в спеке.

Предполагаю, что либо
Version: 2021-03-27 (не смог найти пакетов с подобным обозначением в 
данном поле)

либо
Version 20210327 (такие пакеты нашел, но с учетом того, что 
импортируется тарбол с именем
quickjs-2021-03-27.tar.xz, будет затруднительно воспользоваться макросом 
%version).


Прошу совета, как в таком случае нужно по правильному оформить это поле.

___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [Bug 39461] [3.4] join bne@

[Николай Бурыкин]

Добрый день.

Есть замечания по упаковке документации:

1) Не следует добавлять зависимость на основной пакет:
Requires: %name = %version-%release

Документацию вполне можно установить и читать и без него. Это не
самое распространённое действие, но вполне допустимое: например,
пользователь может захотеть ознакомиться с документацией к пакету
перед его установкой, чтоб решить, нужно ли его вовсе устанавливать.

2) Документацию следует делать noarch:
BuildArch: noarch

3) Примеры (*.ebrc) лучше установить в отдельный пакет examples.
Он тоже должен быть noarch в данном случае.

Так же смотрите рекомендации по упаковке документации и примеров:
https://www.altlinux.org/Package_Splitting#Документация_и_примеры
В общем-то, все вышеуказанные замечания там описаны.

Из правила noarch в редких случаях возможны исключения: например,
когда примеры архитектурно-зависимы. Кроме того у нас были случаи,
когда документация на разных архитектурах генерировалась разная —
но это очень редкая ситуация.

Кроме того, есть замечание по sed: в аргументе подстановки лучше
использовать макрос %_docdir, чем непосредственно указывать путь:
sed -i "s|/usr/share/doc/%name|%_docdir/%name-%version|" CMakeLists.txt

Результат сборки будет тот же, но на случай, если в будущем кому-то
приспичит поменять /usr/share/doc на что-то ещё, будет проще на
уровне дистрибутива всё это исправлять.

В остальном всё хорошо.

Для исправленного варианта тег пересоздайте без инкремента, т.к.
эта версия в Сизиф ещё не попала.

Замечания вроде все исправил. Отправил в новую сборку
http://git.altlinux.org/tasks/index/sisyphus/eperm/269289/

Интересно, мне казалось я перечитал все статьи, касающиеся сборки 
пакетов на вики.
Тем не менее 
https://www.altlinux.org/Package_Splitting#Документация_и_примеры

я как-то пропустил. Вообще на неё не натыкался. За неё отдельное спасибо.
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [Bug 39461] [3.4] join bne@

[Николай Бурыкин]

04.04.2021 14:35, Andrey Savchenko пишет:

On Sun, 4 Apr 2021 13:49:03 +0300 Andrey Savchenko wrote:

On Sun, 4 Apr 2021 12:07:32 +0300 Николай Бурыкин wrote:

Freelan успешно собрался
http://git.altlinux.org/tasks/index/sisyphus/eperm/268926/

Выглядит хорошо. Пропустил.

Есть небольшое косметическое замечание: перед %changelog желательно
оставлять пустую строку; но это не обязательно, больше дело вкуса.


Спасибо.
По поводу %changelog досадная опечатка. Исправлю.
Успешно, без замечаний вчера собрался edbrowse
http://git.altlinux.org/tasks/index/sisyphus/eperm/268951/
Если будет время, посмотрите тоже пожалуйста.
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] Дайджест списка рассылки devel-newbies; том 43, выпуск 2

[Николай Бурыкин]

%
Свойство патчей "отваливаться в случае изменений" - это важное преимущество,
а вовсе не недостаток, как полагают многие.
 -- ldv in devel@
%

Только что осознал, что кроме дайджестов на адрес в домене basealt.ru
других писем из списка рассылки почему-то не получаю, поэтому пропустил 
переписку на тему патчей.

Добавил еще один адрес, для отказоустойчивости.
Сейчас прочитал, и у меня возник вопрос.
А если применять подход с патчами, то как будет правильнее:
Формировать по принципу один патч на одно исправление,
или формировать патч из исправлений, решающих конкретную проблему?
Я подумал, что в моём случае я решаю проблему предупреждений при сборке,
и собрал их в отдельный патч warnings. Но вот теперь задумался на тему 
правильности.
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [join] Проверка корректности пакетирования

[Николай Бурыкин]

Речь про https://github.com/burykinne/edbrowse , верно?

Да, речь о нём.

1) Поправка по лицензии:
- License: GPL and MPL
+ License: GPL-1.0+
Это я недоработал. Исправлю. Надо будет вникнуть в тонкости 
лицензирования свободного ПО.

2) Лучше пользоваться готовыми макросами, поэтому:
- cmake .
+ %cmake_insource
Была мысль, что моя конструкция с "cmake ." неуместна, и так оно и 
оказалось. Вроде и сверялся по Предопределённым макросам 
, 
а всё равно нужный умудрился не заметить. Буду практиковаться, ошибка 
досадная и её можно было избежать.

3) Ещё при таком подходе обнаружились неупакованные файлы:


Понял. Разберусь с этим моментом, и переработаю.

Спасибо за замечания. Есть над чем подумать, и поработать в деле 
восполнения пробелов в знаниях.


___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [join] Проверка корректности пакетирования

[Николай Бурыкин]

Добрый день.
Решил проблемы, мешающие сборке. Поправил заголовочные файлы в исходном 
коде.

Все исправления оформил в патч.
Сейчас наверное нужна только оценка спека, с точки зрения корректности 
написания.
В этот раз делал с оглядкой на 
https://www.altlinux.org/ALT_Packaging_HOWTO, но всё равно мог что-то 
пропустить.
Если не будет проблем, тогда потихоньку буду переходить к плановой 
сборке Fleet.


08.02.2021 15:27, Николай Бурыкин пишет:

Добрый день.
Попытался собрать еще один пакет. https://github.com/burykinne/edbrowse.
В полуручном режиме собрать в итоге удалось. Но автоматизированной 
сборки добиться не получилось.
Столкнулся с тем, что в сборочной среде не находился модуль pcre.h, 
хотя в BuildRequires libpcre-devel есть.

Решил вопрос зайдя в hsh-shell с правами псевдорута и сделав
# ln -s /usr/include/pcre/pcre.h /usr/include/pcre.h

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

И правильно ли я понимаю, что строку
sed -i 's/TidyStyleTags/TidyPreTags/' src/html-tidy.c
лучше оформить как патч?



___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [join] Проверка корректности пакетирования

[Николай Бурыкин]

Добрый день.
Попытался собрать еще один пакет. https://github.com/burykinne/edbrowse.
В полуручном режиме собрать в итоге удалось. Но автоматизированной 
сборки добиться не получилось.
Столкнулся с тем, что в сборочной среде не находился модуль pcre.h, хотя 
в BuildRequires libpcre-devel есть.

Решил вопрос зайдя в hsh-shell с правами псевдорута и сделав
# ln -s /usr/include/pcre/pcre.h /usr/include/pcre.h

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

И правильно ли я понимаю, что строку
sed -i 's/TidyStyleTags/TidyPreTags/' src/html-tidy.c
лучше оформить как патч?



___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [join] Проверка корректности пакетирования

[Николай Бурыкин]

Добрый день!
Попробовал дописать init-скрипт для пакета. Работоспособности вроде 
достиг (проверял в стартерките Xfce с SysV), но в правильности написания 
не уверен.
При написании отталкивался от примера, расположенного в исходниках, в 
каталоге packaging.
Скрипт уже отправил в репозиторий 
, spec файл и gear-rules 
отредактировал в соответствии с изменениями.


Немного завис с попытками изменить в спеке %make_build на scons. Не 
совсем понятно как с его использованием построить структуру аналогичную

%make_build PRODUCT_PREFIX=/ PRODUCT_BIN_PREFIX=%_usr
Пробую провести компиляцию с такой конструкцией:
scons -j%__nprocs PREFIX=/ BIN_PREFIX=%_usr
Компиляция проходит успешно, пакет собирается и устанавливается в ВМ, 
однако при попытке запуска сервера командой freelan 
--security.passphrase "test_pass" служба не может найти конфигурацию, и 
ищет ее по странному пути ..RPM/BUILD...


|2020-12-30T10:40:25.835864 [WARNING] Warning ! No configuration file 
specified and none found in the environment.

2020-12-30T10:40:25.836432 [WARNING] Looked up locations were:
2020-12-30T10:40:25.836485 [WARNING] - "/root/.freelan/freelan.cfg"
2020-12-30T10:40:25.836524 [WARNING] - 
"/usr/src/RPM/BUILD/freelan-2.3/install/etc/freelan/freelan.cfg"


При этом с %make_build PRODUCT_PREFIX=/ 
PRODUCT_BIN_PREFIX=%_usrкомпиляция проходит так же удачно, и при 
запуске сервис использует стандартный конфигурационный файл.||


||2020-12-29T12:36:31.798659 [INFORMATION] Reading configuration file 
at: "/etc/freelan/freelan.cfg"||

||
Особенно странный момент с 
"||/usr/src/RPM/BUILD/freelan-2.3/install/etc/freelan/freelan.cfg". Не 
могу понять, почему бинарник считает, что ему нужно искать 
конфигурационные файлы именно там?||

|||
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

Re: [newbies] [join] Проверка корректности пакетирования

[Николай Бурыкин]

Собрал один из пакетов, придерживаясь рекомендаций с wiki altlinux.org.

А откуда именно?  У нас просто беда, которую упоминал --
есть штуки три "почти написанных" статьи по сборке пакета
с нуля и ни одной завершённой.

Исправлять такое толком получается скорее вдвоём, когда
у одного человека ещё свежо недоумение, а второй понимает,
что именно надо написать для исправления недосказанности.
Как только освоился -- всё, поздно, "и так понятно".


В моём случае порядок чтения статей прошёл следующим образом:
1. В самую первую очередь, чтобы в общих чертах понимать порядок 
действий, я посмотрел лекцию 
 Георгия Курячего в 
которой демонстрируется весь процесс сборки пакета.
1.1. Отдельно после просмотра внимательно пришлось почитать "Руководство 
Hasher" 
, 
там всё написано более чем понятно (по крайней мере у меня все вопросы 
отпали после её прочтения на второй или третий раз).
2. Так же по алгоритму сборки пакета я ориентировался на статью "Сборка 
пакета с РЕАЛЬНОГО НУЛЯ" 
. 
Из этой же статьи позаимствовал подход с tar.gz в .gear/rules
3. Дальше, в попытках осознать смысл своих действий я прочитал "О 
стратегии сборки RPM пакетов" 
. 
Здесь я получил представление о подготовке репозитория Git и написании 
spec файла. К вопросу о том, почему же я тогда не переделал по 
правильному исходный spec? Честно говоря тогда даже мысль такая не 
пришла в голову. Подумалось, что разработчику вероятно виднее чем мне, 
как должен выглядеть спек. В ретроспективе и после объяснений понимаю 
что надо было сесть и внимательно переделать строго с требованиями 
документации ALT. Буду знать.
3.1. В статье "О стратегии сборки" так же упоминается tar.gz в секции 
"Написание .gear/rules" после второго упоминания такого подхода у меня 
не оставалось сомнений, что так и надо делать.
3.2. Момент настройки с созданием gear tags в этой статье, после 
прочтения статьи "Сборка пакета с реального нуля" меня немного ввел в 
ступор (потому что в первой статье есть упоминание git tag, но не gear). 
Но после чтения "Руководство по gear" 
, 
и разъяснений @bircoph о том, что  подходы к ведению репозитория могут 
быть разные, стало более-менее понятно.
Сейчас я бы дополнил этот список крайне внимательным чтением статей 
"Spec:Summary" , и 
"ALT_PAckaging_HOWTO" . 
Вероятно, удели я им немного больше внимания, ошибок было бы намного 
меньше. Ну и наверное в закладках еще стоит держать 
"Spec/Предопределенные макросы" 
.


В  целом ссылки на большую часть полезных статей уже указаны в "Сборка 
пакета с реального нуля". Возможно там не хватает чуть большей 
детализации (например по части tar.gz или gear/git tags).



Репозиторий пока оформил на github - https://github.com/burykinne/freelan.
Собранный пакет и src.rpm приложил к письму.

Достаточно было ссылки, ну и собранный пакет точно незачем
-- ведь надо-то проверить, что из исходников собирается. :)
Хорошо, что я не положил собранный пакет с src.rpm туда же в 
репозиторий, хотя изначально так и планировал. :)

По процессу сборки вроде бы всё было понятно, но, возможно,
не всё было понято правильно.

Сразу бросился в глаза freelan-2.3.tar.gz -- подход с gear
не предназначен для хранения для архивов, предполагается,
что они-то как раз распаковываются в основную ветку либо
по своим, но чтоб работал осмысленным образом git diff:
http://bugzilla.altlinux.org/show_bug.cgi?id=36074#c12

Здесь важно, по возможности прочтите обсуждение там.
Надо понять, что обусловило создание коммита
b4594ab7afbb51aa6c8e03e5bfd8618df4bf7289 --
и исправить документацию.

Как я писал выше, подход с tar.gz мною был позаимствован с Wiki.

После прочтения обсуждения (в частности 
https://bugzilla.altlinux.org/show_bug.cgi?id=36074#c22) сделал вывод 
что так делать не следует (за исключением частных случаев). Хотя 
указание этого метода в двух статьях меня всё таки смущает.
Плюс взял на заметку 
https://bugzilla.altlinux.org/show_bug.cgi?id=36074#c34 . У меня в 
коммитах такая же ошибка. Тоже буду иметь ввиду.



freelan-2.3-alt-make-fix.patch я бы не делал, т.к. "?="
переводится как "задать, если не задано" -- т.е. вызов

   make PRODUCT_PREFIX=/ PRODUCT_BIN_P