On Mon, May 21, 2012 at 08:51:16PM +0200, Simon Ruderich wrote:
> On Mon, May 21, 2012 at 08:42:11AM +0100, Mark Brown wrote:
> And fixing the upstream build system to respect flags from the
> environment sounds like a good idea to me.
That's nice but it's really not the sort of thing you should be doing as
part of something that's supposedly urgent
> > This is a really invasive change to upstream and is going to be fragile
> > going forward, it's fine for drive by people like you who don't care
> > about maintianing the package but it's not helpful to people who have
> > some ongoing interest in the package. Since upstream already provides a
> I don't understand why you are so hostile. I was just trying to
> help fix a problem with your package. Instead of telling me that
> my patch just sucks, why don't you tell me what I should have
> done better so I can provide better patches in the future.
To repeat:
- Provide patches in a more sensible format, sending a single message
containing independant inline and attached patches makes things
needlessly complicated to apply.
- Don't make invasive changes to upstream when you don't have to,
otherwise you're just making work for the package maintainers.
I'd also add (which wasn't mentioned before) that you should actually
describe what the problem you're reporting is directly, just providing a
vauge description and sending a large patch doesn't do this. You just
said that the build system was "ignoring some hardening flags" but
didn't mention which or why.
This all made your report much harder to work with than it needed to be,
the overall impression was "just apply this stuff, you don't need to
understand it".
> And "don't modify the buildsystem" is not enough because in most
> cases the buildsystem of the program is broken and needs to be
> fixed (in zlib's case it works because you can ignore the broken
> test build, but in most packages not only the test flags are
> broken).
Fix the actual problem. Don't introduce random stylistic changes as
part of an "urgent" fix, and the more invasive your changes are the
clearer you need to be about why you're making them.
> > way of doing this we should use it, if you have a burning desire to
> > change the upstream build system you should as Jonathan say speak to
> > them.
> I just wanted to (help) fix the problem and thus provided a
> patch. If you as maintainer don't like it - that's fine of course
> - just implement a different solution (which works).
I also had to reverse engineer what the problem you were trying to
report was - your patch was not only your proposed fix, it was also your
description of the problem.
> But I don't think it's my job to talk to upstream to fix their
> buildsystem just because I provided a patch to fix the package.
> That's your job as maintainer if you don't want to carry a change
> as Debian-only patch or think a proposed patch has a better fix.
It is important that you report problems clearly, by providing your
report in the form that you did what you were saying was that it's
critical that we rewrite to your taste. If you want to do stuff like
that that's fine but you should be separating it out, and ideally do it
directly upstream since it's clearly not the sort of change we should be
making in packages if we don't have to.
> However the following command should help, it displays missing
> flags of all binaries and libraries in the current directory and
> ignores flags not enabled by default:
> find -type f \( -executable -o -name \*.so\* \) -exec hardening-check
> --quiet --nopie --nobindnow {} + 2>/dev/null | grep -vF '(ignored)'
That doesn't error out if hardening-check isn't installed which really
isn't what you want and franly how one is supposed to guess that those
options are appropriate is beyond me...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
