Re: RFS: Looking for a mentor for my dspdfviewer package
Hi Gianfranco,
thank you for the input! I had actually not found this introductory page
yet, now I actually have a debian mentors account. Maybe this time the
upload will work : )
Regarding your points:
> Please look e.g. at this one
> https://sources.debian.net/src/s3cmd/1.5.2-4/debian/watch/
>
> it should be good for you too.
>
>
Sadly, it doesn't work for me, they use a slightly different release layout.
My watch-file does something™ (just not sure if I do it the right way),
so I hope I can keep that for now. The main problem is that the source
.tar.gz (autogenerated) is in ...viewer/archive/v1.13.tar.gz while the
.asc (manually generated and uploaded) is in
...viewer/releases/download/v1.13/dspdfviewer-v1.13.tar.gz.asc
However, uscan (at least version 2.15.8) seems to be smart enough to
rename the .asc., so download *and verification* work when I do
uscan --verbose --download-current-version
When I delete both v1.13.tar.gz and dspdfviewer_1.13.orig.tar.gz, it
downloads v1.13.tar.gz and creates dspdfviewer_1.13.orig.tar.gz as a
symlink to v1.13.tar.gz.
This works fine on my system (since there's no other packages in the
directory where I maintain the deb package), but I don't know if its the
official Debian Way (Or more precicely, I don't how I could make uscan
do it the official way.)
> http://mentors.debian.net/intro-maintainers
>
> did you read that?
Thanks for that link! I read quite a bit of documentation, but I
completely missed this nice entry-point. From that page, I actually
found where to put my gpg key. Fingers crossed, but I think I might be
able to mirror to correctly use the mentors service now. A mirror of the
version package from my website succeeded.
>
> d/rules:
>
> export DH_VERBOSE=1 usually is used just for debug, not a problem,
> just make sure you didn't forget it enabled :)
I usually like my build system to tell me every compiler call (including
all the -flags and -DEF="ines", allows me to spot some problems
immediately) so I guess that's why i turned it on initially.
However, with the new debhelper, it seems to pass
-DCMAKE_VERBOSE_MAKEFILE on its own so I don't need it anymore.
Removed.
>
> d/control:
>
> debhelper (>=9) should be good, an updated version is already
> available in oldstable
The point for this exact version is this webpage:
https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
I expect that by depending on the exact version specified, I'll run into
less surprises when I will (try to) backport the package onto stable or
oldstable, and start using the (then hopefully) official debian package
as a base for the ubuntu package rules. Their oldest currently
supported, precise, has 9.20120115.
I'd rather have an immediate stop on satisfy-build-depends than some
surprising unexpected behaviour at runtime, and on debian
oldstable/stable/testing/sid it should work perfectly since they'll all
satisfy the version requirements.
So if it's not a showstopper to depend on exact version number, I'd like
to keep it that way.
> g++ in my opinion can be dropped, for the
> same reason.
No problem, I can drop g++. If any dist has a pre-c++11 compiler that
tries to compile the source, it will fail on build with very familiar
error messages, so I'll get alerted. As long as no "unexpected thing"
compiles through and runs at a user, I'm happy.
As a side-effect, that should™ allow the package to be built by clang++.
> quilt should be dropped too
Dropped.
> you might want to run "wrap-and-sort" to sort the packaging file
> contents.
Done. They're nicely indented now as well : )
>
> Please avoid comments on the control file, tools like wrap-and-sort
> misbehave with them.
I have removed them, since other than the debhelper version nothing
really needed a comment anymore.
And on the debhelper: If one puts the version number (not even the word
debhelper needed) into google, one gets explained the whole cmake
CPPFLAGS issue and that it was fixed this exact version : )
>
> Maybe a README.Debian file might be better instead.
I guess since I've greatly simplified debian/control now, removing weird
dependencies and simply depending on this version of debhelper I don't
really need one. A quick check on http://codesearch.debian.net (simply
putting in the dh version number) confirms that many other packagers use
that without specifying a comment or README.Debian.
An updated version of the package is now at
http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc
(watch out, same version number, different debian/ contents)
Its very nice that it lets me simply overwrite with a same-version
package (my reprepro repository doesn't like that at all).
Since that works so well now, I'll delete the mirror from my website so
there's less confusion about the different packages with the same
version number.
I will also try to file the "Request for sponsor" correctly, as
indicated on the info page
http://mentors.debian.net/sponsors/rfs-howto/dspdfviewer
Thank you both for your input. It improved the quality of my proposed
package by a good amount and I'm getting more confidence in the debian
package already.
--
Danny Edel
mail@danny-edel.de
debian@danny-edel.de
Reply to: