Debian: fix packaging errors

[amikan]

After checking avocado deb package with lintian tool several issues occurred:

$ lintian -I ../avocado_91.0_amd64.changes --no-tag-display-limit
E: avocado source: source-is-missing optional_plugins/html/avocado_result_html/templates/bootstrap.min.js
E: avocado source: source-is-missing optional_plugins/html/avocado_result_html/templates/datatables.min.js
E: avocado source: source-is-missing optional_plugins/html/avocado_result_html/templates/jquery.min.js
W: avocado source: unused-build-dependency-on-cdbs
W: avocado source: package-needs-versioned-debhelper-build-depends 10
W: avocado source: changelog-should-mention-nmu
W: avocado source: source-nmu-has-incorrect-version-number 91.0
W: avocado source: ancient-standards-version 3.8.4 (released 2010-01-27) (current is 4.3.0)
I: avocado source: testsuite-autopkgtest-missing
W: avocado source: debian-watch-file-in-native-package
E: avocado: description-starts-with-package-name
I: avocado: description-synopsis-might-not-be-phrased-properly "Avocado is a framework for fully automated testing."
E: avocado: extended-description-is-empty
I: avocado: package-contains-documentation-outside-usr-share-doc usr/lib/python3/dist-packages/avocado/etc/avocado/scripts/job/post.d/README
I: avocado: package-contains-documentation-outside-usr-share-doc usr/lib/python3/dist-packages/avocado/etc/avocado/scripts/job/pre.d/README
W: avocado: binary-without-manpage usr/bin/avocado
W: avocado: binary-without-manpage usr/bin/avocado-runner
W: avocado: binary-without-manpage usr/bin/avocado-runner-avocado-instrumented
W: avocado: binary-without-manpage usr/bin/avocado-runner-dry-run
W: avocado: binary-without-manpage usr/bin/avocado-runner-exec-test
W: avocado: binary-without-manpage usr/bin/avocado-runner-noop
W: avocado: binary-without-manpage usr/bin/avocado-runner-python-unittest
W: avocado: binary-without-manpage usr/bin/avocado-runner-requirement-asset
W: avocado: binary-without-manpage usr/bin/avocado-runner-requirement-package
W: avocado: binary-without-manpage usr/bin/avocado-runner-sysinfo
W: avocado: binary-without-manpage usr/bin/avocado-runner-tap
W: avocado: binary-without-manpage usr/bin/avocado-software-manager

Providing fixes to make avocado package satisfy Debian Policy.

[lgtm-com[bot]]

This pull request introduces 4 alerts when merging c23c88745159ba0d82aaadc8e318f2f282763538 into a74bc734330c9c9f2b91df4e796c4422ac57b918 - view on LGTM.com

new alerts:

• 3 for Unsafe jQuery plugin
• 1 for DOM text reinterpreted as HTML

[ana]

Hi @amikan

Thanks for your interest in avocado and in packaging it for Debian, it’s truly appreciated! I have seen the ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993862 and I was hoping you’d reach us.

I’ll comment on your changeset in a different comment. First I’d like to discuss your plans for maintaining avocado in Debian. I get the impression that you want to maintain the packaging directly in our repository, is this the case? There are few cases where this is a good idea and this one isn’t one of them. One of the reasons why this is not a good idea is because your packaging changes aren’t going to align with our release process or reviews and not everybody in the avocado team is following Debian’s policy. It’s way better to create a project in https://salsa.debian.org and maintain it there.

Another reason is because I don’t think what is under contrib/packages/debian should correspond to having the packaging suitable for Debian sid. In upstream we should aim to give the minimum packaging skeleton to allow the package to be built in older Debian releases and derivatives. If you do things like using the latest debhelper compatibility version, this won’t be possible. As mentioned in a past comment to you, I’d like to be able to offer debian package snapshots in github in the future. It might also happen we could entirely remove this directory, FWIW.

All this said, some of your changes that are not about packaging are very welcome independently - for example, the typo fix in the manpage or the bootstrap update, and I'll comment more on this in my second comment.

What do other people from the avocado team think about all this?

[ana]

@amikan 3 quick comments about your changes:

• The debian/watch file shouldn’t be removed. This shouldn’t be a native package in Debian.

• The avocado runners don’t need to have manpages. You can link all the avocado-runner to show avocado’s manpage. Or if you prefer, you can write a manpage for all the runners explaining they’re part of avocado and the differences between them. I'm afraid the current manpages don’t add a lot of value.

• Could you please send a different PR with your changes to man/avocado.rst and optional_plugins/html/… ? They can be commented and merged independently of the packaging discussion!

[amikan]

@ana, thanks for the review. I'm planning to maintain the packaging in Salsa and already put it to https://salsa.debian.org/amikan/avocado, but would like to have as much chages as possible in upstream. So there is no need in having release processes fully aligned. But yes, we need to arrange what to have in upstream, like Debian distribution compatibility.

I've send the first 6 patches separately: https://github.com/avocado-framework/avocado/pull/5048 https://github.com/avocado-framework/avocado/pull/5050

[ana]

Hi @amikan:

Thanks for the two separate PRs! About the changes here, please, update debian/changelog.

More generally, about contributions to upstream (avocado here, but this is speaking in general), from a packaging for Debian (the distribution, not the format) point of view:

1. upstream is usually interested in changes relevant to the source code, things that you would have to carry as patches. This is most of the time changes outside the debian/ folder. Sometimes these changes won't be taken exactly upstream, but a solution can be found. Sometimes it's a different improvement that still makes the life of the packager easier.

2. upstream generally doesn't ship a debian/ folder. In the case of avocado, it's there because years ago someone was using it for building packages in launchpad. As you have seen, it didn't get updated in a lot of time. I personally would like to convert that in a skeleton for building debian packages (the format) from HEAD, the same we do with fedora packages in packit. This would be used for convenience testing and it would be incompatible with a debian/ for packaging in Debian (the distro). However, I consider the priority for installing avocado from HEAD, should be using python tools and I don't consider the debian packages from HEAD a priority. As mentioned above, the scenario where this debian/ folder is removed from the avocado repository is a real possibility.

I hope this makes things more clear.

[richtja]

Hi @amikan since you're already maintaining the downstream repo for this at https://salsa.debian.org/amikan/avocado, do you think that this and #5048 is still relevant for avocado upstream?

[amikan]

Hello @richtja, this one is not relevant. If speaking about #5048, update of the libs can still be useful, but I'm afraid this won't be done properly in near future. So it can be closed also.

[richtja]

Hello @richtja, this one is not relevant. If speaking about #5048, update of the libs can still be useful, but I'm afraid this won't be done properly in near future. So it can be closed also.

@amikan thank you for your response. I am closing this and #5048 then. Feel free to reopen them any time if you need.