[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: Looking for a mentor for my dspdfviewer package



On 05/08/15 13:53, Gianfranco Costamagna wrote:
> maybe that "s" should be put in the manpage somewhere?

Well, it is, under the "controls" section. But I guess that's not really
well-placed, since you didn't find it straight away : )

If you have a suggestion on where to place and/or how to re-word the
manpage, that would be much appreciated. Since I'm more a developer than
a user (and I know the software inside out anyway) its difficult for me
to think from a user perspective.

> BTW another nitpick is the lack of an icon for the application, 
> gnome-shell shows the default "missing icon" icon.

I *would* fix that *if* I had any graphical skills. But I have created
an issue in my souce repository, maybe I can find someone™ to imagine
something nice.

> I: dspdfviewer: hyphen-used-as-minus-sign 
> usr/share/man/man1/dspdfviewer.1.gz:118

That's actually quite a cool diagnostic, I will fix that.

How did you make lintian tell you that? I ran --display-experimental
--fail-on-warnings --info --display-info --pedantic on both
source.changes and amd64.changes (from sbuild) and all I got was the
no-upstream-changelog.

> P: dspdfviewer: no-upstream-changelog

v1.14 and up will have an upstream changelog in the tarball.

> The desktop file works correctly, and it lacks of an icon too (not
> an issue, but it might lead to a bad user experience)

Ticket is created, but I can't promise much on the creativity front.

> 
> other stuff: why do you add ggdb in the cmake file? it should be 
> handled by Debug and RelWithDebInfo (passed by dh IIRC)

I did add that in the very start (and seems to have forgotten about it).
The reason was that on -CMAKE_BUILD_TYPE=Debug it only added -g (without
-ggdb) and thus working with gdb wasnt super useful.

I have removed it, since I can always inject CXXFLAGS=-ggdb on my devel
machine.

> 
> and another "issue", why do you handle the Debian revision in such a 
> complicated way?
> 
> what about just using 1.13 instead of 1.13-1 passed as variable to 
> cmake?

The reason behind the weird "Let the (dist-specific) build system embed
a version number" was to encode as much information about the system as
possible, even if a user just posts dspdfviewer --version to a bug
report, a few examples:

* 1.13: User built from release tarball (unchanged)
* v1.13 or v1.13-xx-gDEADBEEF: user built from a git clone
* 1.13-rc0: User built from git (ie. non-release), but deleted .git dir
* 1.13-1: Official debian package
* 1.13-1~bpo80+: Official debian backport
* 1.13+0~20150804124310.32+sid~1.gbpf1ed24: jenkins-debian-glue

(Launchpads auto-builders use similar long and detailed version numbers)

The last line shows the ultimate Idea behind it: The
jenkins-debian-glue, launchpad etc. scripts all modify the
debian/changelog to add a version tag that (a) makes sure more recent
git versions sort higher, and (b) make sure the debian-revision contains
the git version originally built from. My Idea was to "clone" that magic
into dspdfviewer --version.

OT: With you pointing me to the -rc0 I left in there, I realized that I
actually *added* that (it did say 1.13) before I released 1.13 tarball,
thereby failing to distinguish between 1.13 exact and post-1.13.

Guess I shot my own foot there, but the idea should™ hold up for 1.14.

> BTW instead of the export I would prefer something like 
> dh_auto_configure -- -DYOURVAR=YOURVALUE
> 
> but again, if not necessary you can just use the fallback at line
> 105 I guess. (maybe after updating it!)

For the above reasoning, I would really like to pass the "Debian
version" to the build system.

If there is a standard debian way of doing this, I can of course always
change the method, it's really all about easily™ creating meaningful
bug reports. (If its a problem I can of course remove the stance from
the debian/rules entirely)

As long as a debian user uses reportbug, I guess that doesn't matter. It
is more an issue if I get an email directly, or people post to the
github issue tracker.

So ultimately, I leave the decision to you whether I strip the inclusion
logic.


Updated version at
http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

And I will re-send the RFS template from debian@danny-edel.de, if I read
it correctly they will cross-post to debian-mentors automatically.

-- 
Cheers,

Danny Edel

mail@danny-edel.de
debian@danny-edel.de


Reply to: