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 <mreynolds at redhat dot com> >> >> >> 389-ds-base does not work properly on i686 hardware in regards to >> atomic types. > > Please cite a technical description of the problem, > such as a bugzilla report, blog post, etc. > I'll believe it does not work, but I want to try to understand _why_. The engineer who did "all" the work on this has just left Red Hat unexpectedly, and with him goes all the details on this issue. This is very unfortunate timing, and it is quite frustrating. All I know is that this a real problem for us that only occurs on i686. The previous DS engineer who worked on this insisted it's a bug in i686 arch, while the glibc team insisted it's a bug in our code. Anyway here we are. We know that i686 fails in our tests consistently while on other architectures it does not. We can not back out the atomic work because it's needed to address several issues in our server. It also does not make sense to back it out for a one-off architecture that is not used downstream or by our customers. So... I understand that there is a major lack of detail in this case, and if it's insufficient to officially exclude i686 then so be it. But in that case is there way to flag those i686 builds as "use at your risk/unstable"? > >> == 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. This may lead to thread unsafety and other issues. > > I would appreciate more details about "an issue which causes system > instability". > >> * Release engineering: >> #6894: https://pagure.io/releng/issues/6894 > > That URL gets HTTP error 404 (page not found) as of just now > (2018-03-28T0426). > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
