Learn more about these different git repos.
Other Git URLs
We will be using libffi3.1 compat package that is ready to be deployed, and has been tested extensively in a side-tag with libffi 3.4 rebase.
After libffi3.1 lands in the buildroot we will be able to release a libffi updated to 3.4 (new SONAME).
No packages need to be rebuilt.
Eventually it would be good to rebuild everything libffi 3.4 and deprecate libffi3.1 (compat package). This is not a requirement for GA, and we can keep libffi3.1 compat package around as long as we need it to complete the transition.
We want to know if releng thinks there would be any problems with this approach.
I would be good to have a technical review before any scheduled mass rebuild on 2021-07-21 when libffi 3.4 SONAME would start getting picked up by rebuilt packages that use libffi (directly or indirectly).
No longer needed after 2021-08-24 (100% change complete) or if Fesco votes the change down.
If releng cannot complete an evaluation of the risk, then we would still follow Fesco's ruling. If the change is accepted for F35 we would migrate to libffi 3.4, and evaluate any build failures as they arise in order to resolve them before GA.
Metadata Update from @mohanboddu: - Issue tagged with: change-ack, changes, f35, low-gain, low-trouble, ops
Metadata Update from @mohanboddu: - Issue tagged with: mass rebuild
If the libffi 3.4 is released by mass rebuild we will include it as part of mass rebuild, if not we will be using older libffi.
@mohanboddu Thanks for the note. I will follow up with Fesco to look at the schedule of system-wide change reviews.
I have spoken with @bcotton and it appears that the proposal to use libffi 3.4 would not go to fesco for a vote until July 21st, which means we would not meet the requirement to release libffi 3.4 before the mass rebuild. We want fesco's approval for libffi 3.4 in F35 before moving forward.
@mohanboddu Given the useful new features in libffi 3.4, including RISC-V support (which some users have been asking for), Intel CET, AArch64 PAC, etc, would releng consider delaying the mass rebuild until after fesco votes?
Stepping back a bit here, there is no technical reason for libffi to be associated with the mass rebuild, the libffi 3.4 and libffi3.1 packages ensure that we meet our ABI obligations, but we might end up with a mix of two libffi's in the GA release, which isn't as clean as it could be.
@codonell We cannot delay the mass rebuild by a week, how about rebuilding the needed packages in a side after the mass rebuild?
I'm happy with that. They are a small set that is easy to identify.
I made a mistake here.
Like glibc, we had the changes pushed to libffi and libffi3.1, and I intended to use a 'exit 1' in %build to prevent the rebuild, but I failed to push these, which means the mass rebuild included the transition to libffi 3.4.2 and libffi3.1.
I'm sorry for that.
If we can kill these builds that would stop this leak. https://koji.fedoraproject.org/koji/taskinfo?taskID=72392389 https://koji.fedoraproject.org/koji/taskinfo?taskID=72392356
As a side note, pushing a noautobuild file to dit-git is probably a more transparent way to avoid the mass rebuild than exit 1 in the spec.
noautobuild
exit 1
Absolutely! I'd forgotten entirely about noautobuild thank you for the reminder.
Thanks to Tomas Hrcka we got the builds cancelled so we didn't get libffi 3.4.2 or libffi3.1 3.1 into the mass rebuild, and I've blocked them from building. Once the mass rebuild completes I'll start the libffi transition work.
Metadata Update from @humaton: - Issue untagged with: f35 - Issue tagged with: f36
Metadata Update from @humaton: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.