Bug#832704: RFS: nixnote2/2.0~beta8+20160727+ds-1 [ITP] -- Open Source Evernote client
> I can't sponsor the upload, but I hope the following review is useful to
> you.
Thank you very much for your detailed review. I would like to explain
those problems here for you and anyone who might be interested:
> Since I am not familiar with Java packaging, it would be advisable to
> ask on the Debian java packaging group mailing list for someone to
> review those parts of the package.
OK, I will take a try.
> Must-fixes
> ----------
>
> Is the GitHub repo that this package is based on a fork of Nevernote? I
> think you should change the Homepage: field to point at the GitHub
> repo. Or are they controlled by the same person?
They are controlled by the same person and actually they are the *same
project*. Actually the author is still using nevernote page on
Sourceforge to distribute pre-built nixnote2 packages.
> Your version number indicates that you are packaging a beta release.
> Generally, only full upstream releases are uploaded to Debian unstable,
> rather than testing releases/release candidates. Is there some good
> reason for using this version?
Upstream is keeping "beta" string in version for several years and
there is no sign that he/she will make a "non-beta" release in near
future. However the function of nixnote2 is complete and everything
works well now. Personally I think it is suitable for the release.
> The description of the "exclude opencv linking" doesn't explain why
> opencv support is disabled "for now". Please explain.
In upstream trunk the opencv-related functions are disabled and
removed. The developer intends to make it into a plugin, so I disabled
related builds. What's more, I noticed that Debian is preparing
opencv2-3 transition, so my personal preference is to pack the
opencv-related plugin after the transition is completed.
> Vcs-* should point at your packaging repository, not the upstream git
> repository.
Yes. I am pointing to my packaging repository.
> You should remove the "ignore-branch" and "builder" settings from
> gbp.conf. Those should only be set in ~/.gbp.conf or /etc/gbp.conf.
Thanks. I will fix it later.
> I can't try building and installing this package because I can't get a
> correct orig tarball. The version on mentors seems to be out-of-date,
> and the version the watch file downloads conflicts with your
> <https://github.com/hosiet/nixnote2.git> repo (which is what I'm looking
> at). How can I get the correct orig tarball?
Really sorry I did not try to build from mentors. I will look into it
afterwards.
> Suggested improvements
> ----------------------
>
> There are a lot of build-dependencies. It would be nice to run
> `wrap-and-sort -abst`.
Sure I will fix it.
> README.Debian is meant for users, but what you have written in there is
> only really relevant to Debian contributors. Perhaps rename it to
> README.source, or just remove it. You could also cite the relevant
> section of policy (and the version of policy in which the section had
> that number).
Thanks, I will try.
> The watch file looks like it will only work for the current version,
> because the repack suffix contains a part of the current version
> string. Could it be made more general?
Sure. Will be fixed after next upstream release.
> Could you explain why you Recommends: mimetex and Suggests: cups?
Mimetex is used for latex support of evernote notes, as described by the author.
Cups is needed for note printing, but it is totally fine not to
install it if the user do not need to print.
> You're installing README.md but this file contains no useful
> information. The README.txt file looks more useful. Does that get
> installed to the help/ dir? I couldn't tell without building the
> package, sorry!
I did not install README.txt, since this file mainly describes the situation
of source (not the binary). Should I install it anyway?
> I'm not sure you need to override dh_installchangelogs. It usually
> detects filenames like 'changelog.txt'. But I might be wrong.
>
> At debhelper compat 9, I think that you could remove a lot of lines from
> your rules file. For example, you probably don't need these lines:
>
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
> include /usr/share/dpkg/buildflags.mk
Thanks for these advices, I will try it out.
Reply to: