Re: RFS: hivex
On Mon, May 10, 2010 at 10:29 PM, TJ <email@example.com> wrote:
> As a matter of interest, would you mind sharing the lintian commands you
> use since it is still something of a mystery to me. I use one command
> against the source package but I'm guessing now you're running it
> against each binary package too? In fact, it'd help me a great deal to
> understand the entire process you go through in doing the review - if I
> can do that before uploading it'd probably make for cleaner, better,
> uploads and less iterations.
I have a pbuilder hook that runs this:
echo -n 'Installing lintian: '
apt-get install -y --force-yes --no-install-recommends lintian libwww-perl
lintian --info --display-info --display-experimental --pedantic
--show-overrides --checksums --color auto /tmp/buildd/*_amd64.changes
Notice I run lintian against the .changes file, which checks
everything, binary and source packages.
As far as review process, usually I use mc to look at each individual
file in the debian/ dir and open another terminal with mc to refer to
other files during that. At the same time I have an email open where I
list issues as I find them. Once I've reviewed the debian/ dir I'll
look at debian/copyright and compare it with the output of
"licensecheck --copyright -r .", if that doesn't find any issues then
I'll review the upstream code for license/copyright stuff as well as
embedded code copies and other stuff. Somewhere in there I'll run a
build through pbuilder, grab any warnings I can see and build it again
to check for double-build errors. As well as debian-policy &
developers-reference, some things I try to take into account are at
the links below:
A lot of this stuff can be automated or semi-automated by asking
people questions during the mentors.d.n upload process, but isn't yet.
When I find time, I'd like to change that with debexpo, the new code
As I've hinted in #576184, I'd also like to expand the scope of
lintian with a package of extra tests that can rely on external
packages, access the network and so on. This would form a useful part
of debexpo too. Unfortunately I need to learn perl before I can make
any progress on that.
>> You may want to look at debhelper 7 instead of cdbs:
> I feel more comfortable with CDBS since I like simple-patchsys, although
> now upstream has incorporated my patches it is no longer used. Reading
> those slides didn't really help and I don't have time to listen to the
> presentation but it mostly made my eyes glaze over :p
The dh manual page is probably a significantly quicker way to get
started with debhelper 7, the video is what convinced me to start
using it though.
>> You may want to look at DEP-5 for the copyright file:
> Crikey, another format to master :p
> I've started on it but it looks to be slightly involved for hivex since
> the current copyright is different for "Makefiles and programs" and
> "libraries and language bindings" - figuring out the patterns for the
> File specifications is going to be 'fun'.
Note that it is only a proposal, not a requirement.
>> Is it nessecary to ship the static library? and the .la file?
> Probably not, but which would be preferred in the -dev package? Looking
> at other -dev packages there doesn't seem to be a clear preference.
In Debian we seem to be moving towards not shipping the static library
and not shipping the .la file.
>> README probably isn't nessecary to ship in libhivex0, possibly the
>> same for libhivex-ocaml and perl packages.
> I think I was enjoying the easy life of not having to figure out/write
> the rules to prevent the installation. I'm finding after a certain point
> the need to find yet more documentation on how to fine-tune the package
> becomes tiresome.
Just use packagename.docs instead of docs. You can check out the
debhelper manual pages for stuff like dh_installdocs / dh_install.