On Sun, May 27, 2012 at 12:54:37AM +0200, Simon Ruderich wrote:
> On Tue, May 22, 2012 at 12:06:38AM +0100, Mark Brown wrote:
> > - Don't make invasive changes to upstream when you don't have to,
> >otherwise you're just making work for the package maintainers.
> I still don't understand why
On Tue, May 22, 2012 at 12:06:38AM +0100, Mark Brown wrote:
> 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
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
On Mon, May 21, 2012 at 04:03:37PM -0500, Jonathan Nieder wrote:
> No, none of us are being paid for this. :)
Hello Jonathan,
> I think everything would have gone more smoothly if you had said
> "Fixing this properly is not my itch --- here's a patch to illustrate
> the problem, and it works for
Hi Simon,
Simon Ruderich wrote:
> 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.
On Sun, May 20, 2012 at 09:45:08PM -0500, Jonathan Nieder wrote:
> I see. In that case I disagree with you. My first impression is that
> patching in LDFLAGS upstream is not simpler than fixing configure and
> adding TEST_LDFLAGS in a few places. The former is a maintainability
> hassle ("how do
On Mon, May 21, 2012 at 08:42:11AM +0100, Mark Brown wrote:
> This isn't a problem at all - it's not like any of the test programs are
> actually shipped. I'm not sure why I bothered even pass it in to be
> honest, I think I was just too mystified as to what your patch was all
> about.
True, they
On Mon, May 21, 2012 at 02:09:56AM +0200, Simon Ruderich wrote:
> The second problem is that TEST_LDFLAGS is not used when
> configuring (./configure lines 765-793) and therefore not passed
> to the Makefile when building. Additionally TEST_LDFLAGS is
> missing in two compiler commands.
This isn'
Simon Ruderich wrote:
>> Simon Ruderich wrote:
>>> I think just patching in LDFLAGS is simpler than fixing configure
>>> and adding TEST_LDFLAGS in a few places.
[...]
> I concur completely, sending those changes to upstream is always
> the best.
I see. In that case I disagree with you. My firs
On Sun, May 20, 2012 at 07:21:10PM -0500, Jonathan Nieder wrote:
> Hi Simon,
>
> Simon Ruderich wrote:
>> I think just patching in LDFLAGS is simpler than fixing configure
>> and adding TEST_LDFLAGS in a few places.
>
> The problem with this approach is that all the distros are going to
> have to m
Hi Simon,
Simon Ruderich wrote:
> I think just patching in LDFLAGS is simpler than fixing configure
> and adding TEST_LDFLAGS in a few places.
The problem with this approach is that all the distros are going to
have to make the same change. If the upstream build rules make this
too inconvenient
On Sun, May 20, 2012 at 04:05:44PM +0100, Mark Brown wrote:
>> Description: Use build flags from environment (dpkg-buildflags).
>> Necessary for hardening flags.
>>
>> example$(EXE): example.o $(STATICLIB)
>> -$(CC) $(CFLAGS) -o $@ example.o $(TEST_LDFLAGS)
>> +$(CC) $(CFLAGS) $(LDFLAGS)
On Sun, May 20, 2012 at 03:42:31PM +0100, Mark Brown wrote:
> Dear Whatever,
Hello Mark,
(Just using the snippet from reportbug, what do you prefer as
address?)
> If you're sending stuff like this please just send a patch that can
> actually be applied to the package, it's much easier than havin
tag 672310 - patch
kthxbye
On Sun, May 20, 2012 at 02:58:28PM +0200, Simon Ruderich wrote:
> The following _and_ the attached patch fixes the issue.
No, this makes no sense.
> Description: Use build flags from environment (dpkg-buildflags).
> Necessary for hardening flags.
> example$(EXE): e
On Sun, May 20, 2012 at 02:58:28PM +0200, Simon Ruderich wrote:
> Dear Maintainer,
Dear Whatever,
> The hardening is not complete due to a typo in debian/rules and
> the buildsystem ignoring some hardening flags. For more hardening
> information please have a look at [1], [2] and [3].
>
> The f
reopen 672310
thanks
Dear Maintainer,
The hardening is not complete due to a typo in debian/rules and
the buildsystem ignoring some hardening flags. For more hardening
information please have a look at [1], [2] and [3].
The following _and_ the attached patch fixes the issue.
diff -Nru zlib-1.2.
On Mon, May 14, 2012 at 01:31:17AM +0200, Moritz M??hlenhoff wrote:
> > On Thu, May 10, 2012 at 12:59:00AM +0300, Touko Korpela wrote:
> > > Severity: important
> > Please file bugs with realistic severities.
> FWIW, bugs for release goals qualify for severity:important.
Well, it's being filed
> On Thu, May 10, 2012 at 12:59:00AM +0300, Touko Korpela wrote:
>
> > Severity: important
>
> Please file bugs with realistic severities.
FWIW, bugs for release goals qualify for severity:important.
> > Hardened build flags are a release goal for Wheezy. I don't know why this
> > isn't report
severity 672310 wishlist
kthxbye
On Thu, May 10, 2012 at 12:59:00AM +0300, Touko Korpela wrote:
> Severity: important
Please file bugs with realistic severities.
> Hardened build flags are a release goal for Wheezy. I don't know why this
> isn't reported before, because zlib qualifies for that
Package: zlib1g
Version: 1:1.2.6.dfsg-2
Severity: important
Hardened build flags are a release goal for Wheezy. I don't know why this
isn't reported before, because zlib qualifies for that goal.
I tested with "hardening-check" script (from hardening-includes) that
versions 1:1.2.6.dfsg-2 and 1:1.2
20 matches
Mail list logo
