Distro packaging

[kjkent]

Hey there, IMSProg is great; thank you for creating it. I thought it might help others access IMSProg if I packaged it for the AUR, which I've now done: https://aur.archlinux.org/packages/imsprog. You can read the PKGBUILD there, but essentially it just pulls the release tarball from this repo and automates the build/install process. Users get the added benefits of the transactional install & uninstall capabilities.

Perhaps it might help others if a note was added to the README to say Arch users can install with paru imsprog or yay imsprog, or whichever AUR helper they like! If you have any feedback or suggestions for the PKGBUILD please let me know. The only deviation from the build process in the README is that I've used

make -j`nproc`

instead of make -j4, which should give a quicker performance boost on systems with more cores. I haven't timed this, though.

Lastly, it's not mentioned in the README, but the database update script depends on wget and zenity (I've added these to the PKGBUILD depends array), and the .desktop file for the script has the same Name and GenericName (the latter, just the English text) properties as the main IMSProg entry, which leads to ambiguous listings in, e.g., rofi:

If it was something you'd be open to, I'd be happy to submit a couple of PRs for these minor fixes. In any case, thanks!

[bigbigmdm]

Hi. I would welcome any new ways to install the program that would allow new users to use it.

However, Arch is a distro I know nothing about. Please give more detailed recommendations, or pull request what to change in Readme.md for Arch.

[axet]

А что тут не понятного:

Arch users can install IMSProg using package manager:

• sudo pacman -S imsprog

[axet]

И вообще, я бы начал не с Убунты (это коммерческая, корпоративная огранизация ubuntu.COM), а с Debian - не коммерческая орагнизация, созданная людьми и любителями (debian.ORG)

Арч тоже хороший.

Убуну пользоваться можно, она хорошая и красивая, инсталятор там удобный, но вот любить ее нельзя!

[bigbigmdm]

В Дебиан еще тяжелее попасть, хотя, безусловно, это самый правильный шаг. В Убунту опубликовал только-что. С Арч у меня почему-то не срослось. Сам сижу на Mint и Fedora.

[axet]

Можно сказать что я начинал с Федоры. Очень нравился по сравневнию со всеми, rpm, yum, образы были лучше всех. А теперь Debian.

• https://wiki.debian.org/WNPP
• https://wiki.debian.org/RFP

[bigbigmdm]

Здесь меня вежливо послали.
Сегодня так

[axet]

Это нормально. Люди не хотят разбераться в непонятной фигне, которая сделана не по стандартам и никому не нужна.

Другое дело, если вясниться, что это очень полезный открытй, проект. Аналогов которого практически нет. Просто не все выложено и написано так как надо. Вполне себе нормальные замечания, это не отказ, это предложение начать приводить проект в порядок.

sudo build_all.sh - пример того как делать не надо. Причем в самом build_all.sh есть sudo. Вообще компилировать принятно под юзером, а утсанавливать под рутом.

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

Так что, я бы просто прислушался к тому, что они говорят и начал править проект по чуть-чуть.

[bigbigmdm]

Я этим и занимаюсь последние три недели. Первым делом поменял папки в соответствии с их рекомендациями, дальше поправил CMakeLists.txt, немного подружился с lintian - поправил описания пакета, создал html-файл документации на основе README.md. Поправил changelog и несклько других файлов. А build_all.sh - файл, который испорльзуется только для сборки из исходников на конкретной машине (мне так быстрее тестировать). Его можно удалить. Для сборки пакета используется cmake и CMakeLists.txt - это же прописано в debian/rules
Жалко только, что Boyuan Yang (ответивший на запрос из Debian) дал три дельные рекомендации, дальше написал, что ему некогда и перестал отвечать.

[bigbigmdm]

Может залить еще папку debian на GitHub?

[axet]

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

Стоит добавить не просто папку debian/[control,rules,...] но и скрипт соберающий эти пакеты (fakeroot вмето sudo).

[bigbigmdm]

Вопросов еще очень много. Можете ли Вы периодически на них отвечать?

[axet]

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

[bigbigmdm]

Вот и первый вопрос - какие файлы лишние в папке debian?

[axet]

Я так сразу не скажу, вроде бы: copyright control changelog rules

https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html

Создать шаблон можно через вызов debmake.

[bigbigmdm]

Я создавал через dh_make... Пока буду мучить lintian - уменьшать число предупреждений. Только там тоже много непонятного. Например duplicate-key-in-desktop usr/share/applications/IMSProg_editor.desktop:13 Comment - у многих именно так и ничего...

[axet]

dh_make даже лучше.

Потом 'DEB_BUILD_OPTIONS="nocheck" debuild -us -uc -b' для сборки пакетов без исходников и без тестирования.

[bigbigmdm]

Мне исходники нужны для заливки на Launchpad. Там они автоматически в бинарник собираются. Кроме того их ключем gpg подписывать надо. Так что собираю двумя командами - debuild -S -us -uc -sa и
dpkg-buildpackage -rfakeroot -us -uc

[axet]

1. сделать сборку бинарников как в примере выше.
2. сделать сборку с исходниками, подписями и тестами 'debuild --lintian-opts -i' 'debuils -S' чтобы не все сразу...

[bigbigmdm]

Вот самый подробный вывод lintian: lintian -i -I --show-overrides

[axet]

https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.ru.pdf
https://www.debian.org/doc/manuals/maint-guide/
https://www.debian.org/devel/

http://www.debian.org/devel/wnpp "Adding new entries with reportbug". RFP is a wishlist bug filed against "wnpp" with a title beginning "RFP: "

[bigbigmdm]

Спасибо. Где-то из этих ссылок я уже был, а где-то нет...

[axet]

Лично от себя добавлю - базу данных нужно держать в /usr/share, а не в /etc. И скачивать обновления в .config/imsprog/ или текущую рабочую директорию \ директорию с бинарником. При старте программы проверять сначала домашнюю папку, а потом уже системную.

Так же иметь ключ \ опцию приложение указания локации с конфигом:

imsprog --config /home/admin/database.db

Так все приложения под линукс делают. Никто никогда не обновляет системные \ файлы конфигруации из интернета.

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

[bigbigmdm]

Гениально!
'Так все приложения под линукс делают. Никто никогда не обновляет системные \ файлы конфигруации из интернета.' - это просто от незнания. Каюсь. Спасибо за советы. Сейчас доведу репорт lintian до нулевой длины (это потянуло за собой коррекцию файлов рабочего стола, исходников и переводов, переименование скриптов и коррекции debian/control) и займусь. Но будут вопросы... Еще ребята с хабра просят коррекцию таблицы по SPI NOR FLASH - добавить поле SPDF, а это 420 документов просмотреть...

[bigbigmdm]

'Сейчас доведу репорт lintian до нулевой длины' - готово! :)

[axet]

Это хорошая новость!

Наверное, стоит не забывать про man для imsprog. Все программы для линукса содержат хотябы самое простецкое описание по использованию программы. Вместе со всем остальным - это будет уже полноценное линукс приложение.

[kjkent]

Hi there,

А что тут не понятного:

Arch users can install IMSProg using package manager:

* sudo pacman -S imsprog

IMSProg isn't available in the main Arch repos. The AUR is a community-led repo of software not -- in some cases, not yet -- available via pacman directly. With my submission of IMSProg to the AUR, arch users can install with their AUR "package manager" (often just a wrapper around pacman, Arch's actual package manager. The command to do so is similar. Two popular AUR helpers are yay and paru, so the commands would be yay -S imsprog or paru -S imsprog , respectively.

Note, as user packages, these commands are run without sudo, but the user will be prompted for their sudo password once the package is downloaded and built.

[bigbigmdm]

axet, man сделал для каждого из трех компонент.

[axet]

Очень хорошо! Я думаю это примут, можно отправлять на ревизию.

[bigbigmdm]

Да, спасибо. Только я не понимаю как это сделать? Продублировать мое первое письмо?

 Package: IMSProg
 Severity: Request For Package
 IMSProg - Linux IMSProg - I2C, SPI and MicroWire EEPROM/Flash chip
 programmer for CH341a devices.
 It supports 24xxx, 25xxx, 93xxx, and 95xxx series chips. IMSProg -
 software with graphical interface based on QT5.
 Github: https://github.com/bigbigmdm/IMSProg/
 DEB_Package:
 https://github.com/bigbigmdm/IMSProg/tree/main/release/debian_package
 I am the developer of this program. Please add IMSProg to the Debian
 repository.

[bigbigmdm]

Или указать еще репозиторий на Launchpad, поскольку их проверки я прошел?

[Fantu]

As wrote the workaround should not be needed anymore with recent debhelper and using dh, but can be tried adding the lines of point 2 after line of DEB_BUILD_MAINT_OPTIONS
Before 1.4.1 release it would be useful to check the udev rule deep and fix/improve if needed, but I don't think I have enough time, it might still be better to get the help of someone with more experience since the documentation in this regard does not seem complete

[bigbigmdm]

Thank you, @Fantu !
@axet , what do you think about check the udev rule deep and fix/improve if needed... and Pull#99 ?

[axet]

It looks harmless, but can cause other udev issues on different platforms / distros. I do not know udev that good.

[bigbigmdm]

@coldtobi can you join the discussion?

[Fantu]

@bigbigmdm
I fixed d/watch that I saw that consider also Debian revision tags and not only upstream version tags as should be.

About hardening seems already present checking with hardening-check:

hardening-check /usr/bin/IMSProg
/usr/bin/IMSProg:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: yes
 Control flow integrity: yes

About flags missed spotted by blhc I did some fast tests (following Debian wiki) to workaround cmake issue but didn't solve.

[bigbigmdm]

Thank you, @Fantu !

@kjkent , @sund3RRR, @antohami, @Dmitry-Safonov what do you think about check the udev rule deep and fix/improve if needed... and pull #99 ?

[kjkent]

@wucke13 @bigbigmdm hey there - It's my understanding from the above links and prior reading into udev rules, that MODE="0660" is outdated and no-longer encouraged and similarly, GROUP+="plugdev" and TAG+=udev-acl (see plugdev and udev-acl and plugdev.

To summarise, it appears plugdev in particular is a support for older distros and conceptually not appropriate for devices like chip programmers which are used as char devices rather than block devices. Aside from that, potentially it seems to be causing compatibility issues in cases where there is no plugdev group, which seems to be becoming the norm since circa 201X?

#99 seems correct insofar as renaming the udev rule so it's prefixed with a number < 73 (and therefore interpreted before /lib/udev/rules.d/73-seat-late.rules, and in terms of a deeper dive into an appropriate udev rule, I'd suggest:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="5512", TAG+="uaccess"

The TAG+="uaccess" combined with the corrected file naming from @wucke13 should be the closest "best fit" implementing modern recommended practices from the systemd team, and should work out of the box on any recent-ish systemd-based distro. As this encompasses the majority of distros out there, it seems a "sane default", and downstream packagers can patch for old/non-systemd-compatible distros in their packages.

@bigbigmdm If you wanted to cater for people using the CH341a in TTY mode, you could also add the line:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="5523", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

(note the idProduct difference and the addition of the last initialization, which stops ModemManager from claiming the serial device, a commonly encountered issue) --- it seems a harmless addition, though this may be outside the scope of IMSProg

[axet]

Indeed. Arch recommends to have 71 udev rule number for USB external devices preceding /usr/lib/udev/rules.d/73-seat-late.rules.

• https://wiki.archlinux.org/title/Udev#Allowing_regular_users_to_use_devices

[bigbigmdm]

@kjkent , @axet thanks for your responses!

[bigbigmdm]

Hello @Fantu! Can you please tell me: what do I need to do in order for sponsors to update my package? (mentors, bugs) I would very much like to eliminate metadata errors.

[Fantu]

Try to write on IRC on debian-mentors channel

[bigbigmdm]

Thank you, @Fantu !

[bigbigmdm]

@Fantu, I need help! A new comment has been created in mentors. Phil Wyatt asked to remove the warning trailing-whitespace [debian/changelog:26]. I have deleted the blank line number 26 in the debian/changelog file.
What should I do next?
Rebuild 1.4.1 and upload it to mentors (package comments will be automatically removed) or build a new version of 1.4.2?

[Fantu]

Trailing whitespace at the end of file seems of little importance to me, and could wait for a new version (lintian even lists it as pedantic), but given that a potential sponsor is asking for it...
If there is no enough thing for a new upstream version is better don't do it for don't waste time of maintainer with too many (and small release) release. You can do a commit with only trailing whitespace remove and do a new upload to mentors.

[bigbigmdm]

@Fantu wrote: You can do a commit with only trailing whitespace remove and do a new upload to mentors. - I want to do that myself, but in that case you have to delete the old download first, and that will destroy all the package comments. Is that okay?

Is there any way to save package comments when replacing it with mentors?

[bigbigmdm]

@Fantu , can you please tell me how to understand Phil Wyett last comment in the mentors? Is there anything extra I need to do?

[Fantu]

On mentors simply wrote to keep a look to RFS.
On RFS did a partial review and wrote about appstream metadata error spotted by lintian.
I have no experience about and no enough time but from a fast look to https://wiki.debian.org/AppStream/Guidelines probably the validation check can help you for a fast check any changes you will do:

Metadata files can be validated for conformity with the specification using appstreamcli from the appstream package (appstreamcli validate .xml)

[bigbigmdm]

Hello, @Fantu !
Please check my debian/changelog before publishig the version 1.4.2 on the mentors.

[Fantu]

Fix metadata files is not needed as not in Debian packaging but you can keep anyway instead do other change.
Out of that from a fast look seems ok.

Not related to Debian packaging:
I saw that new release is missed (I mean in https://github.com/bigbigmdm/IMSProg/releases), the tag is ok but some distros use release instead tag to check new version

[bigbigmdm]

@Fantu Yes, i now build it.

[Fantu]

about d/copyright issue reported:

• these are recent and seems done by you, so should be changed to GPL3+ (if you want) or added in the list of GPL2+ inside d/copyright:

GPL-3+          | GPL-2+           IMSProg_programmer/dialogsetaddr.cpp
GPL-3+          | GPL-2+           IMSProg_programmer/dialogsetaddr.h

• this is one take from another project with LGPL-2.1 and you wrongly added GPL-3+ header?
  LGPL-2.1 | GPL-3+ IMSProg_programmer/searchdialog.cpp

[bigbigmdm]

Yes, @fabio. I change it.

[bigbigmdm]

Hello @fabio!
Please check the new tag and the debian/changelog file...

[Fantu]

From a very fast look seems ok, only one minor thing where I added a comment in the commit.

Congratulations for inclusion in the official fedora repositories as well, with that and other distros with external maintainers it is now included in many distros

[bigbigmdm]

Thank's, @Fantu !

[bigbigmdm]

@kjkent , please see this bug,

[bigbigmdm]

Dear @Fantu ! Help me please with my new small package - SFP-Master

[RW6HKF]

Михаил, а IMSProg не будет на Fedora COPR repositories?

[bigbigmdm]

@RW6HKF IMSProg уже давно в COPR здесь. Просто я не вижу смысла говорить об этом, так как IMSProg уже в официальных репозиториях Fedora 39, 40,41.

А вот новый программатор для SFP-модулей SFP-Master я в COPR залил на прошлой неделе.