fweimer reported a new issue against the project: `releng` that you are following: `` Change Proposal: https://fedoraproject.org/wiki/Changes/HardeningFlags28
This change requires a mass rebuild.
Please let me know if you need additional information.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
mohanboddu added a new comment to an issue you are following: `` RelEng acknowledges the change and we will include this in the mass rebuild. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
fweimer added a new comment to an issue you are following: `` I see three open questions right now:
* Do we want annobin annotations for the gcc/glibc bits which are statically linked into all binaries? If we don't do that, can we easily recognize them in annobin coverage checks?
* We switched to generic tuning for armhfp in redhat-rpm-config only. The gcc defaults still use Cortex-8A tuning.
* What about the hard-coding of build flags in Python/Ruby/…? Does the build order take care of that?
I'll ask around if there are other issues. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
kellin added a new comment to an issue you are following: `` Based on a conversation with @sgallagh @fweimer we are going to just do the mass rebuild and then if needed manual builds may be performed for Python/Ruby and any other interpreted language that also provides the ability to compile native extensions.
We are still waiting to hear back with regard to the armhfp tuning and annobin tuning enablement. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
kellin added a new comment to an issue you are following: `` Requested update in IRC at 9:41PM UTC (4:41pm US Eastern)
Mass rebuilds are on hold pending @fweimer getting the information on armhfp and annobin tuning enablement. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
kellin added a new comment to an issue you are following: `` Spoke to @fweimer today.
The earliest this may get resolved is Tuesday February 6th.
Mass rebuilds still on hold. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
mattdm added a new comment to an issue you are following: `` @jkurik Do you see any schedule impact from this delay? Do you think we'll still be good to branch on 2018-02-20? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
jkurik added a new comment to an issue you are following: ``
@jkurik Do you see any schedule impact from this delay? Do you think we'll still be good to branch on 2018-02-20?
The planning of the mass rebuild contains some "spare time" for issues like this. So, I do not expect we need to reschedule the release. However it would be better if RelEng can confirm.
@mohanboddu : do you see the delay (lets say we start the mass rebuild on Wednesday Feb 7th) as impacting the schedule ? The planned end of the mass rebuild is 2018-Feb-20. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
pbrobinson added a new comment to an issue you are following: ``
We switched to generic tuning for armhfp in redhat-rpm-config only. The gcc defaults still use Cortex-8A tuning.
@fweimer What do we need to do to get the gcc defaults adjusted. I also have an open question around the FPU defaults. I'm not sure if we move to the neon-vfpv3 FPU option if it will use NEON if available and fall back to VFPv3 if it's not available (we have a couple of SoC series that don't have NEON that are still quite widely used). If the neon-vfpv3 will use either/or of those it would likely be worthwhile to move to that too.
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
fweimer added a new comment to an issue you are following: `` @pbrobinson Ping @jakub or file a gcc bug?
Regarding NEON—isn't it single precision only, much like SSE? Then it may not be worth the trouble for Fedora in general. The GCC manual also says that NEON vectorization isn't used by default because it's not IEEE-compliant. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
pbrobinson added a new comment to an issue you are following: ``
@pbrobinson Ping @jakub or file a gcc bug?
For which bit? The gcc options?
Regarding NEON—isn't it single precision only, much like SSE? Then it may not be worth the trouble for Fedora in general. The GCC manual also says that NEON vectorization isn't used by default because it's not IEEE-compliant.
Yes, neon is a SIMD similar in style to SSE, so I tend to agree, a lot of projects (see pixman/opus/libpng as examples) have fast paths for neon if detected. It was more a query around the defaults as it seemed the docs suggested it was the suggested defaults but I found them to not be overly clear in the recommendations. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
fweimer added a new comment to an issue you are following: `` I discussed the gcc change which aligns it with redhat-rpm-config with Jakub and updated `gcc.spec`, so this part is done. The other ARM flag changes should be something for Fedora 29 and probably needs some consideration which boards remain supported etc. (I personally do not want to spend much time on armhfp.)
Regarding the open annobin question, I discussed this with a few toolchain folks, too, and I think we will stick with what we are doing now (no annobin for gcc/glibc), and revisit this for Fedora 29. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
kellin added a new comment to an issue you are following: `` @jakub - are all clear from your perspective? @fweimer seems to have given the all clear and we need your sign off as well. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
jakub added a new comment to an issue you are following: `` The pending bugs I'm aware of are mostly internal compiler errors, which aren't that severe for mass rebuild, worst case something doesn't rebuild and will need to be rebuilt when the compiler is fixed. One exception (for fedora filed rhbzs) is #1542124 which I could have a fix in rpm form tomorrow, the question is how often it can hit other packages (affects only math code with NaNs). ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7220
The status of the issue: `Fedora 28 system-wide change: Hardening Flags Updates` of project: `releng` has been updated to: Closed as Fixed by syeghiay.
rel-eng@lists.fedoraproject.org
-
Florian Weimer -
Jakub Jelinek
-
Jan Kurik
-
Kellin
-
Matthew Miller
-
Mohan Boddu
-
Peter Robinson
-
Suzanne Yeghiayan