control: owner -1 !
control: tag -1 +moreinfo
Hello,
I can't sponsor the package, but I hope that the following review is
useful to you.
1. You should install the examples to /usr/share/doc/yabar/examples, not
/usr/share/yabar/examples. You can use dh_installexamples to do this.
2. Since you are packaging based on git tags not github tarballs (I'm
looking at force-create in your gbp.conf), you might have the watch file
look for git tags rather than tarballs. Uscan watch file format version
4 can do this. Not a big deal -- just a suggestion.
3. You should remove the export-dir from gbp.conf: this will override
settings in personal ~/.gbp.conf, arbitrarily selecting a different
build area on other developer's machines!
4. Are you sure about Section: misc? How about x11?
5. You have a lot of libs listed as dependencies. These should be
included in ${shlibs:Depends}. Is dh_shlibdeps not generating the
correct list?
6. You have a build-dependency on git-core, presumably because of the
call to git-describe(1) in upstream's Makefile. However, you also set
the VERSION environment variable in debian/rules -- though I think your
VERSION in d/rules includes the Debian revision, which might not be what
you want. Remember that your source package needs to be buildable
outside of a git repository. You should add some comments to the rules
file explaining why you are setting VERSION and please explain in reply
to this e-mail why you need the git-core build-dep :)
7. Could you explain the Suggests: fonts-font-awesome?
8. You could add some paragraph breaks to the extended description.
9. "plain c" in the description should be "plain C"
10. Why priority 'extra' not 'optional'? Do you expect a file conflict?
11. Why the tight dpkg-dev dependency?
12. As I said before, please merge your debian/changelog entries to a
single 0.4.0-1 entry, with only the "Initial release (Closes: #xxxxxx)"
line.
13. Why a 'low' upload urgency? Counterintuitively, this means that you
think the package is more likely than usual to be buggy and so it should
take longer to migrate to testing; it doesn't actually mean "less
important". Unless you think the upload is buggy, you should use
priority=medium.
14. I see you are ignoring .o files in debian/source/options. Since
your clean target deletes .o files, why do you need this? If you don't
need it, it would be less confusing if you just deleted it. Is it
because upstream hasn't merged your fixed clean target patch yet? I
think it would be more readable to the debian/clean file instead of
debian/source/options.
15. Any reason you haven't forwarded d/patches/fix-typos,
d/patches/makefile-ldflags, and d/patches/makefile-version?
16. Are you sure you need all the lines in your rules file? I think
that with debhelper compat level 9, it is enough to export
DEB_BUILD_MAINT_OPTIONS and the rest will happen automatically. Not
sure, though.
17. You could probably add --parallel to the dh invocation.
18. You should install the README (patched to remove the installation
instructions) and the screenshots to /usr/share/doc/yabar. It looks
like useful documentation that a Debian user probably wants.
On Tue, Jul 26, 2016 at 11:08:21AM +0200, Jack Henschel wrote:
> I recently switched from developing on the debian/sid branch to the
> master branch (hence the latter one has more recent commits). gbp by
> default assumes the build branch is 'master' (except specified via
> --git-debian-branch). Since I do not yet have a lot of experience
> with gbp, I am uncertain which work flow is better. (Any
> recommendations?)
You can configure the Debian branch in debian/gbp.conf. Most of us work
on a master branch for unstable, sometimes adding additional branches
for backports etc. It's definitely up to you so long as your
debian/gbp.conf sets things up for other developers to work with the
package.
It's nice just to merge new upstream versions into a master branch: git
merge 1.2.3 or whatever it is tagged.
> For the most recent version of my work, please use the master branch,
> however the version on mentors is still based off the tag 0.4.0-3 on
> debian/sid branch.
For the record, this review was based off the master branch.
> (Sorry for this 'mess'. Michael Stapelberg has just requested
> colab-maint access for me and then things should hopefully be cleaned
> up.)
collab-maint definitely isn't compulsory, just in case you didn't know.
I haven't actually tried to build, install and run the package yet; I
thought this review was long enough that I should hit 'send' :)
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature