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

Re: sfcgal package for postgis and others



Hi Sven,

Thanks for your further packaging improvements.

On 06/15/2015 02:17 PM, Sven Geggus wrote:
> I'm still unable to get the lintian pbuilder hook up and running, but I
> don't really care because I can just call lintian manually.

You need to add the hooks when you're creating the chroot, or when you
want to add them to an existing chroot you need to use the --hookdir
option together with the --save-after-login option to store the chroot
changes.

> Out of those I only consider hardening-no-fortify-functions and the spelling
> stuff a showstopper. "P:" means pedantic anyway and "X:" ist just plain
> stupid as it is does perfectly make sense to name CMakeLists.txt the same
> all over the place.

As said before pendantic and extra tags are mostly shown to be aware of
the issues. For large files it makes sense to fix the duplicate files
for example.

Your should strife to fix all info and higher severity tags. Warnings
should be fixed or a comment in the lintian override should explain why
it's not. Errors must be fixed.

There are several lintian issues that will cause automatic rejection of
the upload to the archive. It's therefor important to take lintian
issues seriously, but since it's made by man it is not guaranteed
bug-free. So you'll always need to use your own judgment how to best
handle the issues.

> I don't know why I still have the hardening-no-fortify-functions problem, as
> I added all the stuff from
> https://wiki.debian.org/Hardening#Using_Hardening_Options
> to debian/rulse file and "-D_FORTIFY_SOURCE=2" is handed to the c++ compiler
> during compilation as expected.

This issue is prone to false-positives as documented in the extended
lintian description, see:

https://lintian.debian.org/tags/hardening-no-fortify-functions.html

And the links therein, specifically:

https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_FORTIFY_.28gcc.2Fg.2B-.2B-_-D_FORTIFY_SOURCE.3D2.29

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112#15

lintian uses the hardening-check utility to detect these issues, you can
run it in verbose mode to have it report the issues:

$ hardening-check -v /tmp/libsfcgal1/usr/lib/x86_64-linux-gnu/libSFCGAL.so.1
/tmp/libsfcgal1/usr/lib/x86_64-linux-gnu/libSFCGAL.so.1:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
        unprotected: printf
        unprotected: memcpy
        unprotected: memmove
        unprotected: strncpy
 Read-only relocations: yes
 Immediate binding: no, not found!

Because only unprotected functions are found the lintian issue is
raised. From what I understand this can be caused by compiler
optimization. It's quite common to override this lintian tag if the
build log shows that -D_FORTIFY_SOURCE=2 is used, but the resulting
binary still only has unprotected functions.

See for example:

http://anonscm.debian.org/cgit/pkg-grass/grass.git/tree/debian/grass-core.lintian-overrides

> Concerning the spelling errors my upstream patch has been accepted
> unfortunately without adding a new tag. So what's the best way to include
> this upstream diff?

A quilt patch in the debian/patches/ directory is the easiest way to
start out. You can add an 'upstream' git remote and use `git
format-patch` to create the patch from the upstream commit.

> Ah and something else: I disabled the tests again as they are testing the
> in-system library instead of the just compiled one.

The comments at least make it clear why they're disabled, thanks for that.

Regarding your copyright changes, there are still some more required.
Compare the output of the licensecheck2dep5 command documented in the
Debian GIS Policy and the current copyright file.

 licensecheck --copyright -r * | /usr/lib/cdbs/licensecheck2dep5

http://pkg-grass.alioth.debian.org/policy/policy.html#debian-copyright

There are different licenses & copyright used for the patches, these
need to be documented separately in the copyright file.

The polyhedra files are under the GPL-3+ or commercial license for example.

You should also use stand-alone license paragraphs so you don't need to
repeat LGPL-2+ text.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


Reply to: