On Thu, Mar 12, 2015 at 10:55 AM, Moez Roy wrote:
> On Thu, Mar 12, 2015 at 1:46 AM, Tom Hughes wrote:
>> Does anybody have any clue what's going on here:
>>
>> https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log
>>
>> It's an update to libdwarf, but the actual cause appears t
On Thu, Mar 12, 2015 at 1:46 AM, Tom Hughes wrote:
> Does anybody have any clue what's going on here:
>
> https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log
>
> It's an update to libdwarf, but the actual cause appears to be that it
> doesn't like the new hardened build options
Does anybody have any clue what's going on here:
https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log
It's an update to libdwarf, but the actual cause appears to be that it
doesn't like the new hardened build options. It's a glibc symbol that it
seems to be complaing about t
On Sat, Mar 7, 2015 at 12:52 PM, Moez Roy wrote:
> Can you post a link here for that gcc regression bug? Thanks.
There is no regression. The source code invoked undefined behavior.
Under such circumstances, the compiler is free to do anything at all.
Things just happened to work out right with g
On Fri, Mar 6, 2015 at 2:01 PM, Jerry James wrote:
>
> Oops, sorry, got distracted. It is polymake. That package has
> multiple problems.
>
> First, it invokes undefined behavior in one bit of code. That
> happened to work out with gcc 4.x, but gcc 5.x compiles the code a bit
> differently, res
On Thu, Feb 26, 2015 at 11:00 AM, Rex Dieter wrote:
> which package is this again? I can try experimenting a bit.
>
> The one that worked for me was lightdm, fwiw.
Oops, sorry, got distracted. It is polymake. That package has
multiple problems.
First, it invokes undefined behavior in one bit
On 02/24/2015 06:44 PM, Jerry James wrote:
How is this really supposed to be done? If I'm doing it the right
way, then the current method is broken.
%undefine _hardened_build
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Cod
On Saturday, February 28, 2015, Till Maas wrote:
>
> I am going to get this updated once the mass rebuild is done and I got
> the details worked out about what to do best, for example for allowing
> exceptions from this.
You gonna allow many exceptions as some packages on x86_64 failed to build.
On Tue, Feb 24, 2015 at 05:44:18PM -0700, Jerry James wrote:
> Also, http://fedoraproject.org/wiki/Hardened_Packages seems to be
> entirely useless at this point. Perhaps it could be replaced with a
> page that discusses the current state of the hardening flags.
I am going to get this updated on
Jerry James wrote:
> On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter wrote:
>> Mamoru TASAKA wrote:
>>> Does
>>> %undefine _hardened_build
>>> help?
>>
>> that version works for me
>
> Hmmm, am I doing something wrong? I've tried both:
>
> %undefine _hardened_build
>
> and:
>
> %undefine _harden
On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter wrote:
> Mamoru TASAKA wrote:
>> Does
>> %undefine _hardened_build
>> help?
>
> that version works for me
Hmmm, am I doing something wrong? I've tried both:
%undefine _hardened_build
and:
%undefine _hardened_build
%global _hardened_build 0
at the t
Mamoru TASAKA wrote:
> Hello:
>
>> I've got a package that is currently failing to build in Rawhide. It
>> has a home-brewed garbage collector inside, and it appears the GC is
>> confused about which objects are on the stack, and which are on the
>> heap. I want to try building without the hard
On Tue, Feb 24, 2015 at 6:26 PM, Mamoru TASAKA
wrote:
> Does
> %undefine _hardened_build
> help?
Thanks for the suggestion, but regrettably, now %configure does this:
checking C++ compiler ... ok (g++ is GCC 5.0)
determining architecture ... ok (x86_64)
determining compiler flags ... ok
CFLAG
Hello:
> I've got a package that is currently failing to build in Rawhide. It
> has a home-brewed garbage collector inside, and it appears the GC is
> confused about which objects are on the stack, and which are on the
> heap. I want to try building without the hardening flags to see if
> that h
I've got a package that is currently failing to build in Rawhide. It
has a home-brewed garbage collector inside, and it appears the GC is
confused about which objects are on the stack, and which are on the
heap. I want to try building without the hardening flags to see if
that has something to do
> > The earlier a problem is detected, the cheaper it is to fix. If I have
> > understood AutoQA right, it gets involved only after I submit a
> > package to
> > updates-testing.
Kamil Paral wrote:
> Currently we (the AutoQA) are able to run the test either after you submit
> it to Bodhi, or even
> Matthew Garrett wrote:
> > Unless the checking is part of autoqa this simply isn't
> > sufficient. There's a huge benefit to implementing it in the way
> > that's
> > easiest for maintainers.
>
> The earlier a problem is detected, the cheaper it is to fix. If I have
> understood AutoQA right, it
On Tue, Aug 09, 2011 at 04:53:16PM +0200, Björn Persson wrote:
> Matthew Garrett wrote:
> > Unless the checking is part of autoqa this simply isn't
> > sufficient. There's a huge benefit to implementing it in the way that's
> > easiest for maintainers.
>
> The earlier a problem is detected, the
Matthew Garrett wrote:
> Unless the checking is part of autoqa this simply isn't
> sufficient. There's a huge benefit to implementing it in the way that's
> easiest for maintainers.
The earlier a problem is detected, the cheaper it is to fix. If I have
understood AutoQA right, it gets involved
19 matches
Mail list logo
