Debian Package

[narc-Ontakac2]

It was pretty easy to create a working Debian package. If you are interested I would do the details right (which is a bit of work) and create a release workflow that builds a Debian package.

[jziolkowski]

Hi.

TBH I'm on the fence on this one. I'll have to maintain it later, and I think that at some point there will be "why there's no packages for fedora/arch/whatever".

I see little to no gain with distribution packaging when there is easily runnable source and pypi packages.

As a middle ground I can see about creating .appimage or something like that so it can be run standalone on any compatible distro.

[narc-Ontakac2]

Hi.

... I think that at some point there will be "why there's no packages for fedora/arch/whatever".

The easy answer is "do it if if you want it".

I see little to no gain with distribution packaging when there is easily runnable source and pypi packages.

The point with package managers is that there are too many while there actually can be only one. Mine is apt.

As a middle ground I can see about creating .appimage or something like that so it can be run standalone on any compatible distro.

That is not for me. I was suggesting this because I could do it with moderate effort. I just packaged a "good enough for me" solution by installing dh-python and running dh-make followed by debuild.

The TDM application is really nice, I like it very much. Being able to access all Tasmota devices in parallel makes a big difference.

It might be doable to make this an official Debian package. If this is doable I'll go that way.

[jziolkowski]

The point with package managers is that there are too many while there actually can be only one. Mine is apt.

For python there already is, pip :)

After long hiatus, I'm back to work on TDM. It will change rapidly. As for making an official package for debian might be detrimental for the user experience with how long it takes for debian to update packages. So maybe building .deb in CI might be a solution.

If you feel like it, make a PR against my current CI setup, I'll have a look.

[narc-Ontakac2]

As for making an official package for debian might be detrimental for the user experience with how long it takes for debian to update packages.

This depends on the maintainer. If the package is following upstream closely the versions in Ubuntu interim releases (every 6 month) will be quite recent.

It is really good news that you'll be working on TDM.

[jziolkowski]

6 months, yikes. That's a long time. OTOH nothing stops people from installing debs manually, as long as other requirements are met.

[barbudor]

pypi is not a good solution for users. It is for developers but it's hardly usable for users, especially with the move to prevent pip install outside of venv (venv is not usable for "users")
AppImage is a good solution to have a read-to-run and up-to-date package for any user.

[jziolkowski]

(venv is not usable for "users")

couldn't disagree more. Yes, it's an extra step, but still doable. I used it long before I was a developer.

Either way, to not churn through this topic again, exploring other packaging options might not be a bad idea.

@narc-Ontakac2 I assume packaging as .deb makes the application rely on system-available dependencies. Doesn't that lock me out of freely bumping major dependencies, like PyQT (or PySide perhaps one day) or paho-mqtt?

[narc-Ontakac2]

pypi is not a good solution for users.

Agreed (as expected :-) ). To me the point is that as a user you have to know one package manager for every language.

[narc-Ontakac2]

I assume packaging as .deb makes the application rely on system-available dependencies. Doesn't that lock me out of freely bumping major dependencies, like PyQT (or PySide perhaps one day) or paho-mqtt?

Yes, it does. But if you change dependencies that is the packagers problem. In my case the dependencies were automatically detected by dh-python and the resulting package just worked.

[jziolkowski]

pypi is not a good solution for users.

Agreed (as expected :-) ). To me the point is that as a user you have to know one package manager for every language.

I'm so used to it everyday I don't even give it a second thought. That's the way it is. Trying to fight it or work against it is a lost battle.

[Jason2866]

My 2 cents, which "normal" user does use Tasmota Device Manager? This users are so skilled to get Tasmota installed, set up a mqtt broker and get this all together running.
This user should not be able to install TDM from PyPi? Really?

[jziolkowski]

My 2 cents, which "normal" user does use Tasmota Device Manager? This users are so skilled to get Tasmota installed, set up a mqtt broker and get this all together running.
This user should not be able to install TDM from PyPi? Really?

Apparently not 🤷‍♂️

[narc-Ontakac2]

I have started packaging TDM. See

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062335
https://salsa.debian.org/debian-iot-team/tasmota-device-manager

I would however prefer to package a release that already has the configuration files in the new location. Unfortunately
the commit that introduced this is a refactoring that does too much for a patch. Will there be new release within the next weeks?

[jziolkowski]

I still have a few open topics for 0.3, but it will happen eventually, yes. Can't say any definite date as I'm a bit sick right now.

[narc-Ontakac2]

Get well soon.

[narc-Ontakac2]

Unfortunately the icons are not under a free license and can not be included in Debian .

[Jason2866]

Unfortunately the icons are not under a free license and can not be included in Debian

Icons will not be changed.

[jziolkowski]

Wait, icons8 are not free?

[narc-Ontakac2]

Not in the sense of a free license.

[narc-Ontakac2]

https://intercom.help/icons8-7fb7577e8170/en/articles/5534926-universal-multimedia-license-agreement-for-icons8
https://wiki.debian.org/DebianFreeSoftwareGuidelines

This means the icons can not be distributed as part of Debian. So I think I have 3 options:

1. Build and maintain a package that is not distributed by Debian.
2. Build the Debian package with a different icon set (its only about 20 icons).
3. Give up.

[jziolkowski]

Given these circumstances at the moment the sane option would be to provide a .deb from CI releases i guess.

I'm not saying that icons could not be changed ever ever. Just not something I want to do right now.

[narc-Ontakac2]

There is an installable deb package now:
https://www.heute-morgen.de/debian/repo/unstable/main/binary-all/net/tasmota-device-manager_0.2.13-1_all.deb
It installs on bookworm and trixie and adds a menu entry in the network section.

It does have the disadvantages of the 0.2.13 version, which are:

1. It still uses the old location for its config files (~/TDM).
2. It installs its modules directly into /usr/lib/python3/dist-packages/. This comes in my understanding from the use of setup.py, which is removed in the development branch.

[DeusAbsconditus]

The download of the deb package does require a username and password. Wasn't able to get the AppImage to work under Linux Mint Debian Edition so far. I'm relatively new to Linux.

[narc-Ontakac2]

The download of the deb package does require a username and password.

Sorry, it is http://www.heute-morgen.de/debian/repo/unstable/main/binary-all/net/tasmota-device-manager_0.2.13-1_all.deb.

My website currently follows the simple concept that all https requires authentication.

[narc-Ontakac2]

I'm relatively new to Linux.

A local package file should be installable with apt:

sudo apt install <pathname of deb file>

[beren12]

One possibility that a number of projects do is have your own apt source. Simple way is https://askubuntu.com/questions/170348/how-to-create-a-local-apt-repository @narc-Ontakac2 the package is useful thanks but you should remove the .py from tdmgr.py

[narc-Ontakac2]

Thanks, I a maware of that option. I am maintaining the vzlogger Debian packages. We are using a cloudsmith repository for that. Doing that is however a bit of an effort. Having an official Debian package is easier (provided I succeed with that). Currently the Debian package is however blocked by the icons because they have a license that Debian classifies as non-free.

I am aware that the .py is against Debian policy. But since the name of the executable will change anyway (according to the dev branch) I kept it for now.