On 04/05/2018 03:29 PM, Mark Reynolds wrote:
On 04/05/2018 07:02 AM, Florian Weimer wrote:
On 03/29/2018 10:59 PM, Mark Reynolds wrote:
I believe it's our cmocka tests that occur at rpm package time that
brought this to our attention. So it is easy to reproduce.
Well, I tried, but the
On 04/05/2018 07:02 AM, Florian Weimer wrote:
> On 03/29/2018 10:59 PM, Mark Reynolds wrote:
>> I believe it's our cmocka tests that occur at rpm package time that
>> brought this to our attention. So it is easy to reproduce.
>
> Well, I tried, but the package no longer builds on rawhide, even
On 03/29/2018 10:59 PM, Mark Reynolds wrote:
I believe it's our cmocka tests that occur at rpm package time that
brought this to our attention. So it is easy to reproduce.
Well, I tried, but the package no longer builds on rawhide, even on x86_64:
libtool: error: cannot find the library
On 03/29/2018 04:45 PM, Florian Weimer wrote:
> On 03/29/2018 10:25 PM, Mark Reynolds wrote:
>> We can not back out the atomic work
>> because it's needed to address several issues in our server.
First of all, I updated the request wiki page to answer some of John's
questions.
>
> One thing
On 03/29/2018 10:25 PM, Mark Reynolds wrote:
We can not back out the atomic work
because it's needed to address several issues in our server.
One thing that's still not clear to me: What happens on 32-bit
architectures which do not have 64-bit atomics? Are they buggy in a
different way, and
On 03/28/2018 12:29 AM, John Reiser wrote:
> On 03/27/2018 14:17 UTC, Jan Kurik wrote:
>> = Proposed Self Contained Change: Stop building 389-ds-base on i686 =
>> https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
>>
>>
>> Owner(s):
>> * Mark Reynolds
>>
>>
>> 389-ds-base does not
On 29 March 2018 at 07:00, Tomasz Torcz wrote:
> March 29, 2018 12:06 PM, "Peter Robinson" wrote:
>
>> On Thu, 29 Mar 2018, 16:24 Florian Weimer, wrote:
>>
>>> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>>>
> Note that
March 29, 2018 12:06 PM, "Peter Robinson" wrote:
> On Thu, 29 Mar 2018, 16:24 Florian Weimer, wrote:
>
>> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>>
Note that while GCC produces broken code, this is actually an ABI bug, and
we cannot
On Thu, 29 Mar 2018, 16:24 Florian Weimer, wrote:
> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>
> >> Note that while GCC produces broken code, this is actually an ABI bug,
> and
> >> we cannot change struct layout rules for long long retroactively. Maybe
> we
> >> could
On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
Note that while GCC produces broken code, this is actually an ABI bug, and
we cannot change struct layout rules for long long retroactively. Maybe we
could for _Atomic long long, but that would need a lengthy investigation,
and I strongly believe
On Wed, Mar 28, 2018 at 09:58:13AM +0200, Florian Weimer wrote:
> On 03/28/2018 06:10 AM, Kevin Fenzi wrote:
> > So, is this hardware limitation something that is likely to affect other
> > packages? Is there something we could look for in how they consume
> > atomic types to tell? I would hate
On 03/28/2018 04:46 PM, Stephen John Smoogen wrote:
Just to be clear, when other 32 bit architectures don't support it..
if this code was attempted to be compiled on arm32 the compiler
complains and errors?
Generic 32-bit ARM does not have any 64-bit atomics at all. This is
what I meant:
So, is this hardware limitation something that is likely to affect other
packages? Is there something we could look for in how they consume
atomic types to tell? I would hate for us to ship something else that is
subject to this problem.
<>
The way I read some of the comments on the bugs in
>>> So, is this hardware limitation something that is likely to affect other
>>> packages? Is there something we could look for in how they consume
>>> atomic types to tell? I would hate for us to ship something else that is
>>> subject to this problem.
>>
>>
>> There is lots of fingerpointing,
On 28 March 2018 at 03:58, Florian Weimer wrote:
> On 03/28/2018 06:10 AM, Kevin Fenzi wrote:
>>
>> So, is this hardware limitation something that is likely to affect other
>> packages? Is there something we could look for in how they consume
>> atomic types to tell? I would
On 03/28/2018 06:10 AM, Kevin Fenzi wrote:
So, is this hardware limitation something that is likely to affect other
packages? Is there something we could look for in how they consume
atomic types to tell? I would hate for us to ship something else that is
subject to this problem.
There is lots
On 03/27/2018 14:17 UTC, Jan Kurik wrote:
= Proposed Self Contained Change: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
Owner(s):
* Mark Reynolds
389-ds-base does not work properly on i686 hardware in regards to atomic types.
Please
On 03/27/2018 07:17 AM, Jan Kurik wrote:
...snip...
> == Detailed description ==
> 389-ds project have found an issue which causes system instability on
> all versions of 1.4.x of the server on i686 platform. This is a
> hardware limitation of the platform related to how we consume atomic
> types.
= Proposed Self Contained Change: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
Owner(s):
* Mark Reynolds
389-ds-base does not work properly on i686 hardware in regards to atomic types.
== Detailed description ==
389-ds project have
= Proposed Self Contained Change: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
Owner(s):
* Mark Reynolds
389-ds-base does not work properly on i686 hardware in regards to atomic types.
== Detailed description ==
389-ds project have
20 matches
Mail list logo