* Alexander Sosedkin: > On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Alexander Sosedkin: >> >> > Since it's a build-time-only change, >> > can it be rolled out under controlled pressure like this? >> > >> > 1. every package explicitly opts out (with some macro in specfile, IDK) >> > 2. switch gets flipped, nothing changes >> > 3. bugs get filed to drop that macro and opt into new behaviour >> > 4. opting in gets resolved at a leisurely pace >> > across as many releases as needed? >> >> Sorry, what's the advantage of doing it this way? > > Spreading out the porting effect =) > > Maybe I'm scarred by my own unsuccessful attempt > to spread out SHA-1 switch flipping across releases, > but this sounds like a switch that'll need maintainers > to not just react, but also coordinate with upstreams, > and Fedora's tight cycle is uncomfortably tight. I think the porting changes here are much more mechanical. There's no need to come up with new configuration options or anything like that. For about an hour, I looked at three random packages (literally, I used Python's random module to pick them) that were flagged by failing rebuilds: kcc, openblas, swift-lang. kcc has no upstream but is easily fixed. I have something I could push to dist-git. We could also build in C89 mode. There's no obvious upstream anymore. Although now we seem to have some generic Koji issues that causes all builds to fail. openblas has *very* *recent* upstream work that we'd need to cherry-pick and then test-build. Martin Kroeker seems to have been working on exactly these kind of fixes. It's slightly time consuming because it's necessary to iterate to be sure to have all fixes, and openblas doesn't exactly build quickly. swift-lang turns out to be a false positive because of failing configure checks that are expected to fail. That's going to be fixed by adjusting the redhat-rpm-config allowed-to-fail function list. So it seems to amount of per-package changes are fairly manageable. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
