Fix packaging

[Fantu]

@clefebvre I started to do packaging improvements (using salsa to use some QA tests of Debian for fast check more issue), here you can see what I did for now. After some fixes the build fails for missed python3-defer that was removed as "unmaintained; RC-buggy": https://tracker.debian.org/news/1458259/removed-106-21-from-unstable/ but from a fast grep seems still used, what you think to do? And dh-translations is missed in Debian but probably is not needed anymore for change you did on translations, can you confirm?

EDIT: I did some other fast try removed python3-defer and remove dh-translations from builddeps and failed with: /usr/bin/msgfmt: cannot locate ITS rules for ../data/org.debian.aptkit.policy.in tried before adding gettext and after intltool but still failed https://salsa.debian.org/fantu/aptkit/-/jobs/6259399

[clefebvre]

Afaik you need gettext to properly parse polkit files. Intltool can only parse XML and uses the old way (using underscores in front of the tag names, which is a problem for meson).

[clefebvre]

I think that's why you bump into the cannot locate ITS rules error.

Gettext is using /usr/share/gettext/its/polkit.its afaik.

[clefebvre]

I've a feeling most of the python build-deps can be removed... I didn't try yet, but there's no actual compilation or python interpretation taking place during the build.

[Fantu]

Yes build-deps and deps need a complete recheck, I started doing something quick last night after I was already tired from the day at work, so I just fixed a few things^^'' When I saw the build error I immediately put gettext but it wasn't enough so I tried intltool, so there is something to fix. If you want check the things done and the result of CI tests: https://salsa.debian.org/fantu/aptkit/-/commits/master/?ref_type=HEADS About python3-defer that result still needed in deps (as used) but was removed in Debian as not maintained and RC-bugged?

[clefebvre]

In the build deps:

libpolkit-gobject-1-dev (or polkitd for older releases) is needed. debconf-i18n dh-python dh-translations pycodestyle python3-all python3-distutils-extra python3-mock xvfb can be removed.

[clefebvre]

Regarding python3-defer we'll need to look into it and see how/if we can rewrite the code using it.

[clefebvre]

The version of python3-defer we're using looks pretty small and was maintained by Sebastian Heinlein and originally written by MIT people in 2001? I'm not sure what's going on upstream with yasyf's version, it looks like a different thing altogether.

What does it mean exactly that python3-defer is "RC bugged"? Was there a specific issue with it?

[Fantu]

Looking in the archive of bugs the RC one not resolved at the time of removal is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997624 (fails to build), is probable the last Ubuntu specific revision (1.0.6-2.1ubuntu1) fixed it or they would have removed it for sure in the latest Ubuntu versions Looking the packaging part is very old, must be updated if want to reintroduce the package in Debian but seems fast to do from a fast look.

[Fantu]

Thinking about the fact that it has already been removed in Debian 12 I wonder in LMDE based on it how did you use it? Did you add it in the mint repo or was it not needed? If not used by other softwares and since it is small maybe it is better to integrate instead have another package to reintroduce and maintain

[clefebvre]

It was needed. Version 1.0.6-2.1ubuntu1 was added to LMDE6.

Since it doesn't have any critical bugs, only packaging issues, I'd rather not maintain it. It's small but it's complicated in terms of copyright history and licensing.

Also if Ubuntu's aptdaemon is to ever get back into Debian, it will also need python3-defer.

[Fantu]

I'm not sure to understand, you don't want to maintain it but the package should be return. To return should be maintained by someone. I don't have much time and for example if I had to maintain it (maybe adding it inside "debian python team") given the little time there should be the upstream or someone who tries to solve the software problems and instead I should only take care of keeping the packaging updated and correct.

---

About license and copyright this is exactly what I mentioned in the other issue, it would be good to keep track of all copyright and license parts. If inside each file it has such information it is better, in the other issue I mentioned that it could also be done via an external file but thinking about it is much better to have it in each file. In fact I have already seen problems on files or parts of files taken from other projects without worrying about copyright/licenses, if they have it in every file even if you copy the entire file keeping it you have the information available, while if you copy only a part or the copied files you do not have them they should be added when you use them to avoid problems later, maybe after years having difficulty finding the information. Not having it in your files exposes you to a greater risk that such information will be lost if someone starts copying files and using them in other projects and therefore this could also be a risk that discourages potential contributors. This obviously does not prevent the use intentionally in contrast with the licenses by other people but at least it limits the problems in cases of use that one does not care to manage due to lack of knowledge or desire but if one copies the entire files with copyright and license it allows to see and manage possible problems by other people.

---

Returning to python3-defer have license/copyright in the source files and you can integrate part with MIT license FWIK. What would be the difficulty you are talking about? I'm not very knowledgeable about licenses either but I know something, for example one thing is can't change GPL-licensed software to MIT license (is not that the case).

[clefebvre]

I disagree on license headers. I don't want to mix legal info with the code and see it duplicated all over the place in every single file. These file headers were useful in the 90s when files were printed or shared via floppy disks without knowing where they came from. But we live in a completely differently world now. Everything is searchable, we've got tools, standards and version control systems to separate the code from the history and author information and project-wise files for licensing.

I'm not comfortable with the licensing of python-defer to copy its files into this project. The headers specifically forbid their own removal. The code is minimal but that gets in the way of future potential refactoring between files.

I don't want to maintain code which has very little value but comes with strings attached like that. I'd rather just use it externally and not maintain it, or if I need to modify it, then rewrite it from scratch entirely.

I really don't see code as an art form, to me it matters very little who wrote it, but it's very important that we're able to maintain it well and without restrictions.

[mtwebster]

If we're able to break client.py api, we can get rid of defer and just use GLib for async calls.

edit: probably even async/await python (though this wouldn't be my first project choice to learn on).

[Fantu]

@clefebvre About not include python-defer I understand about not to integrate it.

About license and copyright in files header you might think that in this era having them in every file is outdated, but unfortunately they are even more needed since fewer and fewer programs are made from scratch, but many parts (or also major or near all) are taken from existing projects. If everyone when they take something would keep track in the header of the file (if not present) or if you do not want to add them at least in external files like d/copyright or reuse there would be less problem, but this often does not happen, and it happens that missing the license in the header they are not considered the original license. You can do research, but it takes time, and you do not always have enough time, or you succeed (with origin that can no longer be found).

But now the license management has been improved thanks to various tools, furthermore with spdx you can indicate the license in the individual files even in just one line when you add it, if you have the exact correspondence of all the extended text of the license. spdx have a big list: https://spdx.org/licenses/ there is also scan-code that have bigger with over 2000 license: https://scancode-licensedb.aboutcode.org/ there are very few licenses that I have not found there, for now only 2 rare ones from the large MIT "family"

If you want an example that seems to me a good project that keep track of license and copyright in file header where mainly use spdx one line license in header is the linux kernel, one file as example: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/block/bdev.c

Everything is searchable, we've got tools, standards and version control systems to separate the code from the history and author information and project-wise files for licensing.

The tools are mainly based on files header and do good and complete job only if them are present and/or are present information at least in external file (if complete and correct) Information in git and similar for recover needed info from history is possible only if is kept full history, including any fork, and without take files of other project out of the that (or adding with them also the necessary information), if missing in the files header. It cannot even guarantee that the contributor has taken that code or part of it in compliance with the licenses.

For example, all fork I saw here (if I remember good) are without history and always with first commit importing all files.

One other example where there is also difficulty in checking licenses and other issue (or can take big amount of time) are icon packages. See for example https://github.com/linuxmint/mint-x-icons/issues/198 and as reported there is also an issue with trademark and non-free logo taken from one theme where it was forked and probably also other icons added after: https://bugzilla.redhat.com/show_bug.cgi?id=1005464 seems to me was forked before this, or I'm wrong? https://github.com/mate-desktop-legacy-archive/mate-icon-theme-faenza/commit/c1478671383a3c7960714b31f2bdc480535e4f98

Sorry if it may seem like I want to waste more time and stress but in truth what I would like is just to make you aware of some possible problems, not necessarily to invest a lot of time in checking/fixing everything but at least to act possibly in the best possible way in future additions and modifications in order to limit the possible problems.

Sorry also if I didn't explain myself well or my english is bad.

[carlosmintfan]

The files in /usr/bin and sbin contain huge license headers for a tiny amount of code; I think they should be removed or replaced by SPDX.

[Fantu]

The full license text in that files can be replaced with: # SPDX-License-Identifier: GPL-2.0-or-later the copyright line it can remain as it is or become: # SPDX-FileCopyrightText: 2008 Sebastian Heinlein <devel@glatzor.de>

[carlosmintfan]

I'm not comfortable with the licensing of python-defer to copy its files into this project. The headers specifically forbid their own removal. The code is minimal but that gets in the way of future potential refactoring between files.

defer is licensed under the MIT license, what's wrong with it? MIT is GPL-compatible. How are the headers forbidding their own removal? Of course, you have to leave the notice somewhere, but it shouldn't harm just putting it into debian/copyright (and possibly only leaving an SPDX-License-Identifier).

[Fantu]

Yes as wrote also in one comment above is compatible and can be integrated, but @clefebvre wrote that prefer don't do it, also for other reason.

Keep attention that MIT licenses are many, if you want to use spdx, the short name used must reference the exact license, you must be sure that the full text of the license matches perfectly; you have to be very careful as it could change even a little and not find a match. When don't match perfectly a license you cannot replace full text in files with one line with spdx FWIK. Also in any case there must be at least one copy of the full license in the software, in these particular cases with packaging it should be reported in debian/copyright while in software without packaging, for example must be added, for example in LICENSES/.

[clefebvre]

Packaging fixes were pushed to master.