[Bug 1305382] Review Request: tristripper - Triangle stripification (algorithm by Tanguy Fautre)

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1305382

Denis Fateyev <denis at fateyev.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|fedora-review?              |fedora-review+



--- Comment #12 from Denis Fateyev <denis at fateyev.com> ---
(In reply to Raphael Groner from comment #9)
> Sorry for my long delay of a response. We'd severe issues in rawhide cause
> of the gcc6 mass rebuild, that must be handled with absolute priority.

No problem ;-)

> 1a I can not confirm about coreutils. Responsible people from FPC tell me
> that dependencies are to be considered as good if a package builds in mock
> and mock installs base environment incl. coreutils.

In general, yes, it's hard to realize that mock would go without coreutils.
Though the tendency is that even many base packages that previously were in the
exception list now according the policy should be mentioned in BR. Like gcc-c++
we're discussing below.

This aspect about `coreutils` presence in BRs always raises questions, and some
maintainers currently use it (like we in "perl-sig" do), other don't. I'm not
actually insisting on coreutils in this case.

> 2 Okay also about adding BR: sed, if you really insist on that.

Unlike coreutils, it's a must since neither coreutils nor gcc-c++ nor bash have
"sed" in requires. Without that "exception list" its position is a bit vague. 

> 3 That's in responsibility of upstream to provide a good license text file

Sure thing. But you can ping them to do so, quite often upstreams are
interested in fixing their things, and even do it in a timely manner ;-)

> 6 There's really not any relevance for the review process with those rpmlint
> warnings about macros in comments. TBH, I do not even know why it warns at
> all.

It eliminates the whole amount of warnings, so the package looks neat.
Although, this very case with commented macros is optional.

As for the package description, it's also recommended to replace the French
acute letter there with the common "e".

Otherwise the package is APPROVED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component