Re: RFS: Looking for a mentor for my dspdfviewer package
>Well, it is, under the "controls" section. But I guess that's not really
>well-placed, since you didn't find it straight away : )
nope, the manpage is correct, I tried a --help, and I didn't find it
(sorry for the confusion)
>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.
that is something always difficult... Maybe the --help can be more similar to the
good manpage? :)
>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 know this problem :)
>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.
lintian -EvIL +pedantic --profile debian/main ../dspdfviewer_1.13-1_amd64.changes
>Ticket is created, but I can't promise much on the creativity front.
not a problem, maybe a "blank" icon is better than the default one...
anyway, you are the Upstream and the Maintainer, who am I to complain? :D
>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.
they are always suggestions, so feel free to leave it if you think users might benefit
(what about creating a -dbg package? since it is a new package you might benefit from one
trip only in the NEW queue)
>* 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
this is fine
>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.
lol fine ;)
>For the above reasoning, I would really like to pass the "Debian
>version" to the build system.
ok, but instead of relying to the ENV variable, you can still use
override_dh_auto_configure:
dh_auto_configure -- -DVAR
this way you can go in the if @line 75.
This is equivalent actually for Debian (it will allow you to remove 6 lines from the CMakeFile),
but it might be a problem for other Linux based Distro around the globe.
Having one single way to feed the version might be a benefit for everybody
>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)
actually this isn't a problem, just avoding N different methods of having the revision might be a benefit
for you too
>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.
nack there, it is up to you, not to me :)
BTW the new rules file is what I intended previously, and makes lines 91:96 useless now :)
(not asking you to remove, just pointing that to you).
Last thing:
d/rules, lines 2 to 8, I guess you can remove them
>Updated version at
>http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc
Looks good to me
let me know about the last two things (specially for the dbg package, that is something important)
and I'll do the upload
cheers,
G.
Reply to: