Distro packaging - Githubissues

kjkent commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

Arch users can install IMSProg using package manager:

sudo pacman -S imsprog

axet commented 7 months ago

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

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

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

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

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

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

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

bigbigmdm commented 7 months ago

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

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

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

dh_make даже лучше.

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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 commented 7 months ago

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

axet commented 7 months ago

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

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

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

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

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

bigbigmdm commented 7 months ago

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

bigbigmdm commented 7 months ago

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

axet commented 7 months ago

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

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

kjkent commented 7 months ago

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 commented 7 months ago

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

axet commented 7 months ago

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

bigbigmdm commented 7 months ago

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

 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 commented 7 months ago

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

axet commented 7 months ago

Вы писали в debian-devel а надо написать в debian-mentors. Если уже писали - ответом на свое письмо.

bigbigmdm commented 7 months ago

Засада, написал повторно - Bug#1057072: Acknowledgement (RFP: IMSProg -- Linux programmer for CH341a devices) Побьют?

axet commented 7 months ago

Дебиан - это простые люди.

axet commented 7 months ago

Не заметил, вы писали RFP, а адо RFS:

https://wiki.debian.org/Diaspora/Packaging/RFS

bigbigmdm commented 7 months ago

Вот их родной пример. Только я не могу понять, что такое upstream.

axet commented 7 months ago

upstream - это вы.

bigbigmdm commented 7 months ago

Как-то так получилось. Что теперь? Периодически смотреть здесь изменения?

axet commented 7 months ago

Выглядит хорошо. Старые обращения закройте: https://www.debian.org/Bugs/Developer#closing

Раз в пол года, можно ответом напоминать о себе.

bigbigmdm commented 7 months ago

alext, помогите разобраться, пожалуйста. Через чат irc.libera.chat #ubuntu-devel нашел сопровождающего, работающего в CANONICAL. Он пообещал спомочь с публикацией в Debian. Сказал, что Lintian я применяю к deb-пакету, а нужно к исходникам. Я убрал еще много ошибок. Отписал ему письмом. В ответ он попросил убрать еще ошибок и отправить запрос ITP. (Bug#1057386: Acknowledgement (Subject: ITP: imsprog -- linux chip programmer for CH341a devices)). Я вижу, что статус запроса изменился. Но я не понимаю, что делать дальше. На последнее письмо он пока не ответил... На debian я код не размещал.

axet commented 7 months ago

Хорошо, что нашелся сопровождающий, думаю просто он немного занят потому и не отвечает сразу. Сам я никогда не использовал lintian. Но судя по 'man lintian' там сказано:

There are two ways to specify binary, udeb or source packages for Lintian to process: by file name (the .deb file for a binary package or the .dsc file for a source package), or by naming a .changes file.

То есть надо dpkg-genchanges создать .changes файл и потом его отдать lintian .changes

bigbigmdm commented 7 months ago

Спасибо. lintian -i -I --show-overrides imsprog_1.1.2-12_source.changes дает максимум информации.

bigbigmdm commented 5 months ago

alext,, пока залито на https://mentors.debian.net/package/imsprog/

Fantu commented 5 months ago

I wrote here instead open new issue, actually there are some issue that I think they cause confusion and difficulties for potential package maintainers. For example, there is a new tag "v1.1.4-2" that is minor of 1.1.5 release previously but with additional commit, this is wrong, should be for example 1.1.6. I would also recommend avoiding including packages in releases here but keeping the packaging separate, also seen that work is underway to include it in the official repositories of other distros. For any builds on old Ubuntu you can use launchpad, as you are doing and mention that also in the releases of new versions, through repositories it is simpler and faster for users. If it will be included in Debian within a month, it should also be included in the next Ubuntu LTS before the feature freeze.

There will be further possible fixes and improvements to the build system to facilitate any package maintainers, but unfortunately I don't have much experience with CMake nor enough time to help you with this, I hope you will find someone else to help you.

bigbigmdm commented 5 months ago

kjkent, please update your AUR package from 1.1.2-1 to 1.1.4-2.

bigbigmdm commented 5 months ago

Dear Fabio! Thank you for helping me so much and for so long. You have taught me a lot. I hope that I will be able to ask you simple questions in the future. With binary packages, it turned out that several people advised me contradictory things. I will take your advice and remove all the binary packages from the releases. Only first I'll need to replace the links to Launchpad on all the sites and forums where the programm is discussed.

This leaves me with three questions:

Is the correct package now posted on mentors.debian? Shouldn't I change d/changelog from Distribution: UNRELEASED to unstable?
What is the correct way to make the UBUNTU / DEBIAN / versions in the programme itself the same? Under which tag to release the latest changes in DEBIAN? (Since it's still a long way away from publishing to DEBIAN, I still consider Launchpad a priority, as a lot of people are getting software updates from there now.)

3- Can you please explain what the gbp-import-ref command does? Does it change the debian/latest branch to match main when executed?

Fantu commented 5 months ago

Sorry for my bad english and I'm not good to explain. Given that you are trying to put it on the official debian/ubuntu repositories but have the official packaging in a single repository, instead of another one (for example on salsa.debian.org) it should be:

main branch where there is software development without packaging and tag on new release that will be "vX.Y.Z" (for X Y Z I mean the number of the version) and not additional package revision. Additional thing in version can be for example for prerelease like -alpha, beta, -rc etc... In case of debian packaging will be converted to be minor (for example https://salsa.debian.org/debian/memtest86plus/-/blob/debian/master/debian/watch?ref_type=heads) https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version However, in order not to complicate things too much, we could only talk about that if there are prereleases.
debian/latest is where official Debian packaging is done, only debian folder must be changed, with gbp import-ref a new upstream version is imported and software (all except debian/) will be updated and will be the same of the imported upstream version, also upstream git history is merged. If software changes are needed "out of the upstream version" changes to software (any out of debian folder) is done using debian/patches, here an example: https://salsa.debian.org/debian/freeipmi/-/commit/e971e226cfa4491339236b9c844e42925715c68f

About mentors upload seems still wrong, I don't understand how is possible, I tried to explain some times. I suggest removing latest wrong tag (v1.1.4-2) and do a new correct like 1.1.6 (remember that all upstream tag must be based on main branch) After, I'll try to update debian/latest and generate source upload to see what is wrong.

I saw upstream changelog in the readme, so I suggest removing of old unofficial packaging changelog (https://github.com/bigbigmdm/IMSProg/blob/main/changelog) or better replace it with good "upstream only changes" for separating it from readme. An example of upstream changelog I suppose can be https://github.com/FreeRDP/FreeRDP/blob/master/ChangeLog Anyway you can be a more minimal one like the actually included in readme.

Official backports to older Ubuntu will be possible only when package will be present in official repository, so for now you can keep launchpad for older and keep it updated (you can keep updated also after inclusion in official repository), as wrote branches in the repository about rebuild for unofficial build is not needed. About Debian all new versions will be uploaded to unstable (or experimental in some cases), after will auto migrate to testing (if no RC bugs or regression in automatic tests present), when reach testing will be possible doing also official backports.

bigbigmdm commented 5 months ago

Fabio, you explain it very well! Let's wait with the new tag for now. First I will change dialogabout.ui to not change translations when changing version, then I will remove the binary packages from the releases, then I will update the tag to 1.1.6 and write to you.

axet commented 5 months ago

Говоря простым языком версия должна быть semantic (помоему это GNU сделали, могу ошибаться):

x.y.z

где x - совместимость между приложениями. y - новые фичи\функции, z - баги, без добавления новых функций.

суффикс "-1", "-2" использоуется ментейнирами для обновления ошибок и опечаток в .deb описании controls, rules и так далее.

https://en.wikipedia.org/wiki/Software_versioning

bigbigmdm commented 5 months ago

axet, тут вопрос (номер 2) именно в том, что писать в d/changelog для debian: imsprog (1.1.5-1) UNRELEASED; urgency=medium или imsprog (1.1.5-1) unstable; urgency=medium.

bigbigmdm commented 5 months ago

axet, периодически на mentors.debian появляется Bastian Germann, делает замечания и Фабио помогает мне их исправить.

bigbigmdm / IMSProg

Distro packaging #19