[needs-packaging] diodon -- Clipboard manager for GNOME and Unity

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

Status changed to 'Confirmed' because the bug affects multiple users.

I have added a ubuntu package to my ppa ppa:sao/ubuntu-testing for first review.

See here: https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.0-0ubuntu1.dsc

A lintian check reveals some issues that can be fixed:

E: diodon source: source-contains-waf-binary waf
P: diodon source: out-of-date-copyright-format-uri http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
W: diodon source: out-of-date-standards-version 3.9.3 (current is 3.9.4)

Run "lintian-info -t source-contains-waf-binary" and so on for more details.

Thanks for the feedback.

I did the linitian check with an old quantal version.... My bad ;). out-of-date-copyright-format-uri and out-of-date-standards-version should be fixed now.

See here (needed to update version number so the ppa allows me to upload it, still old number in the bzr branch): https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.0-0ubuntu2.dsc

The issue source-contains-waf-binary though is a little bit trickier: It seems that there are some issues with the WAF developers and the Debian developer disagreeing on how source code should be built with waf and what is allowed to be included in a source tar ball. See discussion here http://lists.debian.org/debian-devel/2010/02/msg00714.html

Debian then decided to not allow waf binaries in source tarballs anymore but eventually also not shipping a waf package either.

As I understand does this basically mean that all upstream project using waf won't be able to being accepted as a package to Debian anymore. And Diodon which is using waf as well would fall under this restriction as well.

I was searching for a official statement of Ubuntu whether they want to follow this restriction as well, but could not find any.

What I found though are some packages in the universe repository which are also build with waf and actually therefore have the same issue (e.g. hamster-applet or midori). So the question here is whether Diodon can still be accepted into the repository even though using waf?

Hmm about the waf issue: I have just found this http://wiki.debian.org/UnpackWaf So I see how this works out and will update the package accordingly.

Ubuntu follows the DFSG rules, too. Therefore the same rules apply whether we accept a package in Ubuntu or not.

The problem with waf (besides upstream being hostile against packaging it) is shipping a waf script containing a binary blob. The solution is to replace the waf script with a blob by the (bigger) waf source code script (which is fully editable).

The Vcs-Bzr and Vcs-Browser links should point to the packaging branches. I think the ubuntu:dioden branch should be used (once it's in the archive) and therefore the Vcs-* entries should be removed.

Just a personal remark: Do you have a reason to use cdbs? IMO, the short format dh (version 9) is better than cdbs.

Currently Ubuntu archive has 5 packages which have waf binary.
While ftp-masters rejected such upload in Debian, it does not necessary a requirement in Ubuntu.
After all waf binary self-produces it's own source code on execution and hence is always available.

http://lintian.ubuntuwire.org/quantal/tags/source-contains-waf-binary.html

The Vcs references are deleted in lp:~diodon-team/diodon/ubuntu-packaging

About waf: I have been thinking about this a little bit more. And I came to the conclusion that integrating the whole waf original source code is a good compromise to the issue Debian is having with the waf blob. And having the source code around cannot really hurt either. I therefore included the original source code from waf upstream into lp:diodon.

However I now run into the issue the *.pyc files get generated and included into the debian diff. I have tried to tell dpkg-source to exclude it without passing on a command line parameter (e.g. with the file debian/source/options), have failed so far. Can someone give me a hint on this how this is usually done?

About the choice of cdbs: I have chosen cdbs as it has specific waf support. So this means it ships with several waf defaults and I basically have to change only one variable. I am not aware that this would work with dh as easy as well.

The usual way is to run "find -name '*.pyc' -delete" at the end of the dh_auto_clean or clean target.

Re dh, there seems to be no build system support for waf. Until someone adds waf support, the cdbs rules can be shorter.

OK done. See https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.1-0ubuntu1.dsc

As I would like to keep upstream and packaging close I actually adjusted lp:diodon to include the waf source code. Additionally have I added an apport hook as well and changed the version of diodon to 1.0.1. This version though is not released yet. But when there are no more comments for the packaging which could affect the upstream code as well, I will release it straight away, so the Ubuntu package can be based on an official diodon version as it is required.

Thanks to the comments of hyperair have I added multiarch support and bumped debhelper to verison 9.

Here is the dsc (as before only updated to ubuntu2 to be able to upload to ppa, packaging branch remains with old version):
https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.1-0ubuntu2.dsc

fyi a new updated version: https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.2-0ubuntu1.dsc

I think it makes sense to wait for the initial package to enter the archive (currently waiting for a review by the archive admins [1]). Then a new bug report should be used for the update, because this bug will be closed by the initial release.

[1] https://launchpad.net/ubuntu/raring/+queue

Ahh, did not really know that it is already in the update queue. Yes, makes sense then to wait before updating it.