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

Bug#841222: Acknowledgement (RFS: patat)

On 2016-10-23 11:51-0700, Sean Whitton wrote:
> You should use "Forwarded: not-needed" (see DEP-3).

This does not seem to work with gbp-pq (see #785274), I propose to add this as
soon as gbp-pq supports DEP-3.

>>> 2. You can fix all of these Lintian tags, except possibly
>>> hardening-no-fortify-functions.  You should definitely deal with the
>>> warnings.
>>> W: patat-dbgsym: debug-file-with-no-debug-symbols
>> I've updated debian/rules to something matching
>> stylish-haskell.
> Okay.  I'll take a proper look soon.


>>> I: patat: spelling-error-in-binary usr/bin/patat Nam Name
>>> I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
>>> I: patat: spelling-error-in-binary usr/bin/patat forward forward
>>> I: patat: spelling-error-in-binary usr/bin/patat upto up to
>>> I: patat: spelling-error-in-binary usr/bin/patat discontigous discontiguous
>>> I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
>>> I: patat: spelling-error-in-binary usr/bin/patat The The
>> Not sure about this one... Is "patat" too generic for lintian? I've
>> added this to debian/lintian-overrides.
> I don't understand.  It is pointing out misspellings, such as
> 'uncomplete', somewhere in the upstream source.  You can add a quilt
> patch to fix them, and forward it upstream.

As I didn't found anything matching these errors in the source, I thought it
was a generic error message concerning the binary name.

Now, that I understood the purpose of this check, I can only found these
mistakes in the binary itself, so I guess these are in the dependencies...

>>> I: patat: hardening-no-bindnow usr/bin/patat I: patat:
>>> hardening-no-pie usr/bin/patat
>>> I think that in order to pass hardening options to gcc, if you're
>>> willing to work on that, you'll need to abandon the CDBS build system
>>> you're using at present.  See the Makefile for keysafe[1] (not yet in
>>> Debian) to see how to pass the options, and the rules file for the
>>> stylish-haskell package to see how to do without CDBS.
>> After reading this Makefile, I'm not sure how keysafe avoids
>> hardening-no-bindnow and hardening-no-pie... Do you have any clue?
> The Makefile propagates LDFLAGS, CFLAGS and CPPFLAGS through to ghc.
> Then you enable all hardening in your d/rules,[1] and the right flags
> get set by debhelper.
> [1] https://wiki.debian.org/Hardening

I would like to wait a little before adding this: the default flags added to
gcc seems quite new, so I propose to have a look again when things stabilize.

>>> 3. Please run upstream's test suite during the package build.
>> Should be done now, I'm not sure about how I run tests... See
>> debian/rules override_dh_auto_test
> Okay, I'll look later.


>> Concerning the last lintian warning (binary-without-manpage), I'm not
>> sure it will add anything to "--help", and it is going to add an
>> overhead to maintain the package... If it's not required I would
>> prefer not to do anything with this.
> Adding manpages is one of the things that Debian does to standardise and
> bring together the different programs that are part of the Debian
> system.  I'd strongly encourage you to be part of this QA effort.
> With regard to maintenance, hopefully you can persuade upstream to adopt
> your manpage, so there wouldn't be any overhead.
> In the meantime, you can use help2man to generate the manpage.  Note
> that you shouldn't run help2man during the package build, as it's a
> notorious source of FTBFS bugs.  Instead, add a target to d/rules to
> generate the manpage.  See the ocrmypdf source package's d/rules.
> If help2man is insufficient, see again stylish-haskell where I use
> asciidoctor.

I'll try to add a manpage using help2man.

Concerning DHG's package-plan, I can't run the tests myself, ghc seems to be
broken in my chroot due to hardening flag -pie (see #712228). So I propose to
add patat later, when things calm down.

Attachment: signature.asc
Description: PGP signature

Reply to: