Re: RFS: hivex
The patches do not get applied when unpacking the source package, you
are missing a debian/patches/series file.
Since you are patching Makefile.am files, you need to run automake and
clean up afterwards.
In addition, if you can, please be more specific with the forwarded
field in patches. I imagine upstream has mailing list archives, so you
could add the URL to that (or to gmane/etc) in the forwarded field.
On Sat, Apr 3, 2010 at 4:23 AM, TJ <debian@tjworld.net> wrote:
> * INFO: "debian/copyright-questions.txt", "debian/ubuntu-bug-report-needs-packaging.txt" and "debian/Debian-Mentor-RFS-Feedback.txt"
> and other text files are being kept as working notes and records of actions whilst doing the packaging
> and will be removed once the package is ready for the 'real' world.
Fair enough.
> * INFO: lintian override "maintainer-not-full-name" is to make clear I *am* using my *full name* and don't want
> to be told "don't use initials" when I'm not (had that several times in past few years with Ubuntu).
My apologies, I don't come across many folks with a two-letter first
name and no last name, so I thought you were just trying to hide your
real name.
Please add overrides for the binary package warnings too. dh_lintian
can help install them appropriately.
> * ACTION: added dh_install excludes for unwanted Perl library files perllocal.pod and .packlist.
Might be appropriate to send upstream a patch for this.
> * QUESTION: I'm not clear what the expected 'fix' is for libhivex-perl: binary-or-shlib-defines-rpath? I've read about RPATH
> issues (http://wiki.debian.org/RpathIssue) but can't see how it applies in this case. I'm presuming upstream know what they're
> doing setting installation targets for the Perl bindings.
> RESOLVED: Build-depend on chrpath and add override to debian/rules.
Given that the rpath that is added to the perl lib is an absolute path
to the build directory of the library, I'd suggest this is an upstream
bug. rpath is a runtime thing so it never makes sense to set it to a
build directory.
> * QUESTION: Perl Policy 4.2 suggests package name convention "...for module Foo::Bar is libfoo-bar-perl." That suggests
> the package name here should be "libwin-hivex-perl", which doesn't 'feel' correct. Is "libhivex-perl" acceptable?
I'm not sure here, you might want to contact the debian-perl list about it.
> * QUESTION: mis-spelling "reencode" in man files by upstream. I would feel extremely pedantic to raise that with the authors on
> top of the other queries I've been sending their way. Is this something that can be ignored (maybe with an override) ?
As a pedantic-level lintian complaint, it is fine to ignore it.
Overriding it would not be appropriate since it isn't a false positive
that cannot be fixed in lintian. I personally send upstream a patch
and then ignore it on the Debian side. I've never had a problem with
upstream not accepting spelling fixes.
You're installing the hivex manual page in the shared library package.
I'd suggest moving that to the -dev package.
About the symbols file, it looks like upstream is exporting some of
the library's internal and helper functions, I would have thought they
should only be exporting the hivex_* functions. Please point them at
this document:
http://gcc.gnu.org/wiki/Visibility
The package FTBFS when building twice in a row:
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building hivex using existing ./hivex_1.2.1.orig.tar.gz
dpkg-source: error: cannot represent change to
hivex-1.2.1/images/large: binary file contents changed
dpkg-source: error: add images/large in debian/source/include-binaries
if you want to store the modified binary in the debian tarball
dpkg-source: warning: ignoring deletion of file hivex.pc
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b hivex-1.2.1 gave error exit status 2
This is probably to do with your patches not applying or not running automake.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: