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

[Andrey Savchenko]

Добрый вечер!

On Tue, 16 Feb 2021 21:19:22 +0300 Николай Бурыкин wrote:
> > Речь про https://github.com/burykinne/edbrowse , верно?
> Да, речь о нём.
> > 1) Поправка по лицензии:
> > - License: GPL and MPL
> > + License: GPL-1.0+
> Это я недоработал. Исправлю. Надо будет вникнуть в тонкости 
> лицензирования свободного ПО.

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

В данном меня случае насторожило, что GPL и MPL без указания версии
были — такая ситуация необычна, что послужило индикатором того, что
что-то не так.

Вообще, мир лицензий и их взаимодействие друг с другом — не такая
уж простая тема. Пару лет назад я делал в Калуге доклад на эту
тему, что может послужить неплохо вводной:
http://0x1.tv/
Уязвимости_в_лицензиях_СПО_(Андрей_Савченко,_OSSDEVCONF-2018)

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

Кроме wiki есть ещё два полезных источника:

1) rpmbuild --showrc, далее grep/less по вкусу

2) git://git.altlinux.org/people/specbot/public/specs.git
Здесь все спеки Альта, обновляется автоматически, спасибо vt.
Очень полезно когда нужно посмотреть «а как другие это делают».

Best regards,
Andrew Savchenko


pgp3EzPyq99ax.pgp
Description: PGP signature
___
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] Проверка корректности пакетирования

[Andrey Savchenko]

Добрый день!

On Mon, 15 Feb 2021 14:05:16 +0300 Николай Бурыкин wrote:
> Добрый день.
> Решил проблемы, мешающие сборке. Поправил заголовочные файлы в исходном 
> коде.
> Все исправления оформил в патч.
> Сейчас наверное нужна только оценка спека, с точки зрения корректности 
> написания.
> В этот раз делал с оглядкой на 
> https://www.altlinux.org/ALT_Packaging_HOWTO, но всё равно мог что-то 
> пропустить.
> Если не будет проблем, тогда потихоньку буду переходить к плановой 
> сборке Fleet.

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

1) Поправка по лицензии:
- License: GPL and MPL
+ License: GPL-1.0+

Поясню по чему так. Случай сложный, на самом деле.

Давайте посмотрим файл COPYING:

This program is copyright (C) Karl Dahlke, 2000-2014.
It is made available by the author under the terms of the GNU General Public
License (GPL), as articulated by the Free Software Foundation.
http://www.fsf.org/licensing/licenses/gpl.html
It may be used for any purpose, and redistributed,
provided this copyright notice is included.

This program uses libcurl.so for http/ftp access.
This is released under the Mozilla public license (mpl).
I didn't change any of the source; I merely link to these libraries.
However, if you wish to release a version of edbrowse with these shared
libraries included,
or a statically linked executable, you will need to specify both gpl and mpl.

Первая часть говорит просто GPL без указания версии и даёт ссылку.
Пройдём по ней, пункт 14, параграф 2:

If the Program does not specify a version number of the GNU General Public
License, you may choose any version ever published by the Free Software 
Foundation.

В Альте следует указывать одну из лицензий из /usr/share/license*.
В данном случае подходит GPL1.0+ — т.е. любая из существующих
версий GPL.

Вторая часть про линковку с libcurl. Во-первых, эта часть применима
только для статической линковки (а у edbrowse динамическая) или при
совместном распространении с libcurl.so (в Вашем пакете её нет, её
исходников тоже нет, используется системная версия). Во-вторых,
у libcurl поменялась лицензия и комментарий автора edbrowse устарел.
Там сейчас MITX:
  $ rpm -qi libcurl | grep License
  License : MITX
Текст можно посмотреть в /usr/share/license/MITX. С ней можно без
дополнительных ограничений линковать GPL софт.

2) Лучше пользоваться готовыми макросами, поэтому:
- cmake .
+ %cmake_insource

Хотя я бы предпочёл out-of-source build, тогда будет:
%build
%cmake
%cmake_build

%install
%cmakeinstall_std

Обратите внимание, что дополнительные аргументы %cmakeinstall_std
не нужны, т.е spec упрощается.

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

warning: Installed (but unpackaged) file(s) found:
/usr/share/doc/edbrowse/sample.ebrc
/usr/share/doc/edbrowse/sample_fr.ebrc
/usr/share/doc/edbrowse/sample_it.ebrc
/usr/share/doc/edbrowse/usersguide.html
/usr/share/doc/edbrowse/usersguide_fr.html
/usr/share/man/man1/edbrowse.1.xz

Думаю, что man нужно паковать всегда, html-документацию —
в отдельный подпакет doc, *.ebrc — в examples (или в doc,
если считаете частью документации). Можно ещё заморочится
и разложить fr и it в doc-fr и doc-it (или examples-it);
но это дело вкуса.

Ещё есть проблема, что пакет доки в ставит в /usr/share/doc/edbrowse,
а нужно в /usr/share/doc/edbrowse-3.7.7. Это можно исправить в %prep
через sed примерно так (не проверял):
sed -i "s|/usr/share/doc/edbrowse|/usr/share/doc/edbrowse-%version|" 
CMakeLists.txt

4) Устанавливать файл COPYING не нужно, т.к. текст лицензии уже есть
в системе и лицензия указана в rpm пакета. Обычно текст лицензий
вместе с пакетами устанавливать не нужно. Исключение — когда лицензия
требует обязательной упаковки или установки своего текста вместе
с пакетом (это не тот случай, но в будущем такое может быть).

Best regards,
Andrew Savchenko


pgpTKDQCtLEjo.pgp
Description: PGP signature
___
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] Проверка корректности пакетирования

[Andrey Savchenko]

On Tue, 9 Feb 2021 10:27:14 +0300 Michael Shigorin wrote:
> On Mon, Feb 08, 2021 at 11:26:23PM +0300, Andrey Savchenko wrote:
> > > Зависит.  Сам так порой делаю, но патч в случае изменения
> > > контекста хотя бы отвалится (что и морока, и сигнал).
> > Миша правильно сказал, что sed — обоюдоострый меч: этот способ
> > проще автоматизировать при обновлениях, чем файлы с патчами, но он
> > может внезапно выстрелить в ногу, сработав не там где нужно.
> 
> apt-get install fortunes-ALT
> 
> %
> Свойство патчей "отваливаться в случае изменений" - это важное преимущество,
> а вовсе не недостаток, как полагают многие.
> -- ldv in devel@
> %

Зависит от обстоятельств. Бывает, что да, полезно, ловит проблемы.
А бывает, что сверху строчка, которая всё время меняется, на
патченый код не влияет, а diff всё время ломает. 


Best regards,
Andrew Savchenko


pgp3ID4wOnv8i.pgp
Description: PGP signature
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

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

[Michael Shigorin]

On Mon, Feb 08, 2021 at 11:26:23PM +0300, Andrey Savchenko wrote:
> > Зависит.  Сам так порой делаю, но патч в случае изменения
> > контекста хотя бы отвалится (что и морока, и сигнал).
> Миша правильно сказал, что sed — обоюдоострый меч: этот способ
> проще автоматизировать при обновлениях, чем файлы с патчами, но он
> может внезапно выстрелить в ногу, сработав не там где нужно.

apt-get install fortunes-ALT

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

-- 
  WBR, Michael Shigorin / http://altlinux.org
  -- http://opennet.ru / http://anna-news.info
___
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies

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

[Michael Shigorin]

On Mon, Feb 08, 2021 at 03:27:07PM +0300, Николай Бурыкин wrote:
> Попытался собрать еще один пакет. https://github.com/burykinne/edbrowse.
> В полуручном режиме собрать в итоге удалось. Но автоматизированной 
> сборки добиться не получилось.
> Столкнулся с тем, что в сборочной среде не находился модуль pcre.h, хотя 
> в BuildRequires libpcre-devel есть.
> Решил вопрос зайдя в hsh-shell с правами псевдорута и сделав
> # ln -s /usr/include/pcre/pcre.h /usr/include/pcre.h

Я бы проверил на эффективность

%add_optflags -I%_includedir/pcre

...а вообще научить бы их пользоваться pkgconfig, что ли...

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

Зависит.  Сам так порой делаю, но патч в случае изменения
контекста хотя бы отвалится (что и морока, и сигнал).

-- 
  WBR, Michael Shigorin / http://altlinux.org
  -- http://opennet.ru / http://anna-news.info
___
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] Проверка корректности пакетирования

[Andrey Savchenko]

Доброго времени суток!

On Wed, 27 Jan 2021 15:24:56 +0300 Николай Бурыкин wrote:
> Добрый день!
> Попробовал дописать init-скрипт для пакета. Работоспособности вроде 
> достиг (проверял в стартерките Xfce с SysV), но в правильности написания 
> не уверен.

В целом выглядит хорошо. Я бы посоветовал общий код по проверке
конфига в start() и stop() куда-нибудь в checkconfig() засунуть.
Пример можно посмотреть в init для sshd или unbound.

> Немного завис с попытками изменить в спеке %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...

scons не понимает {BIN_,}PREFIX — это переменные, используемые
внутри Makefile пакета. Следует испольовать {bin_,}prefix= как это
делается в Makefile. Например:
scons %_smp_mflags --mode=release apps prefix=/ bin_prefix=%_usr --upnp=yes 
--mongoose=no

Best regards,
Andrew Savchenko


pgpc6hvWMHBx4.pgp
Description: PGP signature
___
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=/