I just found out by accident that freeipa server and 389-ds-base are dropping support in Fedora 28 for all 32 bit arches. This has not been well communicated. there is a bug https://bugzilla.redhat.com/show_bug.cgi?id=1544386 it howevr skipped the arm team. I think we have two options available.
1) request they add back 32 bit support for f28 and file a change request for f29 to advertise the significant change. 2) Ask that the responsible teams file a system wide change for Fedora 28 and we grant an exception and allow the change to happen in Fedora 28
As sad as I will be since I run freeipa on a 32 bit arm box I think option 2 is the right way to go.
adding @mreynolds @vashirov as they are who I talked to on IRC about it.
i686 has been a secondary arch (approximately, however we're defining that now) for Fedora for quite some time, and the last Fedora release for which a 32-bit Server image was release blocking was Fedora 23 - see https://fedoraproject.org/wiki/Releases/23/ReleaseBlocking and https://fedoraproject.org/wiki/Releases/24/ReleaseBlocking . So personally I'm not sure this merits a big noise on its own. We made a big noise when we made i686 no longer a primary arch...
I for one run freeipa on fedora aserver on 32 bit arm, I think the i686 case is much less important to advertise than the 32 bit arm case is, the packaging needs to be fixed because the changes to disable builds on 32 bit arches left 32 bit arm, it seems teh dev doing it did not understand teh arches in use in Fedora
@adamwill It's not just i686. ARMv7 is also affected.
@ausil I can assure you that @firstyear, @rcritten, @mreynolds and me know what we are doing. 389-DS had to drop 32bit support because atomic data types for atomic reference counting are broken. It's a severe bug that can lead to silent data corruption. You can find more details in https://bugzilla.redhat.com/show_bug.cgi?id=1544386#c3 . Since 389-DS is dropping 32bit support, freeIPA has no other change but drop i686 and ARMv7, too.
I'm strictly against supported 32bit platforms until 389-DS or GCC have fixed the issue. It'd rather not support a platform than to provide packages with serious flaws.
@cheimes sorry, forgot to mention, we have never had a release-blocking 32-bit ARM image for Fedora Server. Fedora Server has always been 'supported' only on Intel arches.
If there's a lot of real-world usage of it on 32-bit ARM, of course, this might be worth taking special care over it, but it would be good to see some more objective evidence of that I guess.
AGREED: Ask the GCC team to try to help find the source of the corruption. Post to the -devel list to let people know the situation. Revisit in two weeks. (+5,0,0)
I've posted to the devel-list and the GCC maintainers:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCHEJMPX3ME7TKUBSFBAEG6AR5RSU4B3/
I've posted our questions from yesterday's meeting on the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1544386#c29
AGREED: FESCo requires that a Change be filed for F28, and involved packagers are otherwise free to sort out the issue (+6, 0, -0) INFO: If the change is accepted, releng changes will be required
Did we ever see an F28 change filed for this? If not, we should push on this again...
I have again requested a change to be filed on both BZs.
This was discussed on 2018-03-23: https://meetbot.fedoraproject.org/sresults/fesco.2018-03-23-15.00.log.html#l-321 bowlofeggs requested the change proposal in https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c8 (tyll, 16:08:12) ACTION: bowlofeggs will make sure a change is written NO MATTER WHAT HAPPENS (bowlofeggs, 16:23:25) ACTION: bowlofeggs will ask them again for a change page and write one for himself if the maintainers do not provide one (tyll, 16:23:36)
The change page has been created and proposed. Is there anything further on this ticket?
Metadata Update from @sgallagh: - Issue close_status updated to: Fixed
Login to comment on this ticket.