Re: Pinta failed to build on f33/armv7hl

On Fri, 2020-08-14 at 12:03 +0200, Andrea Musuruane wrote: > Hi guys, >I tried to update pinta to the latest upstream version. It built fine > except than on f33/armv7hl: > > https://kojipkgs.fedoraproject.org//work/tasks/1530/49241530/build.log > > I have no idea why. Can someone please hel

LTO and F33

So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of have been resolved (by opting the package out of LTO). I still expect some LTO issues will pop up as packages fix things like missing dependencies, cmake macros, etc. I continue to be available to investigate potent

Re: LTO and F33

On Tue, 2020-08-18 at 17:21 +0100, Tomasz Kłoczko wrote: > On Tue, 18 Aug 2020 at 16:12, Jeff Law wrote: > [..] > > My focus is now turning to the packages with LTO opt-outs. I'll be > > extracting > > bug reports for upstream (primarily GCC), trying simple w

Re: chromium/ffmpeg fails on aarch64 in F33+

On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote: > I don't know aarch64 assembly, but chromium (or more specifically, the ffmpeg > part of chromium) is failing on aarch64 on F33+ (everywhere else it is fine): > > obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function > `ff_prefetch

Re: fedora-review fails due to no annobin in mock

On Wed, 2020-08-19 at 20:15 +, Artur Iwicki wrote: > Recently (happened today and happened a month ago), whenever I try to run > fedora-review for a Review Request that includes a C/C++ program, the mock > build fails immediately due to gcc/g++ not being able to find the annobin > plugin. >

Re: LTO and F33

On Thu, 2020-08-20 at 11:42 +0200, Vitaly Zaitsev via devel wrote: > On 18.08.2020 17:12, Jeff Law wrote: > > So we're at a point where the F33 FTBFS issues related to LTO that I'm > > aware of > > have been resolved (by opting the package out of LTO). I still

Re: GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

On Tue, 2020-08-25 at 10:17 +0100, Daniel P. Berrangé wrote: > On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote: > > I think soon we will have a big boost in Koji performances thanks to > > Giuliano Belinassi and his work on addressing GCC parallelization > > bottlenecks. According

Re: Galera FTBFS in f33, but same build passes in f32

On Thu, 2020-08-27 at 14:21 +0200, Lukas Javorsky wrote: > Hi folks, > > I've run into the compilation problem in the Galera package > This problem occurs only on f33 and higher tho. > > Here is build performed on Fedora 32: > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504 > > An

Re: The case of LTO when produced enlarged binaries

On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > > ignatenkobr...@fedoraproject.org> > > wrote: > > [..] > > > > > Well, I tell what I see :) > > > > > > Compiling kitty with settings b

Re: The case of LTO when produced enlarged binaries

On Mon, 2020-08-31 at 09:17 +0200, Bob Mauchin wrote: > > > On Mon, Aug 31, 2020, 05:32 Jeff Law wrote: > > On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > > > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > > > On Fri, 24 Jul 2020 at 21:

Re: FYI Fedora 34 OCaml 4.11.1 rebuild

On Tue, 2020-09-01 at 17:27 +0100, Richard W.M. Jones wrote: > We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, > something like 170+ packages. Well, a compiler bug was found and > upstream released OCaml 4.11.1. Details here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1870

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

On 9/28/20 8:50 AM, Jan Kratochvil wrote: On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote: If you want to make -fdebug-types-sections the default you really should work with the upstream GCC developers to figure out why they don't want that. I haven't seen that, according to Richard Bi

Re: LTO and F33

On 9/30/20 7:39 AM, Robert-André Mauchin wrote: On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote: So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of have been resolved (by opting the package out of LTO). I still expect some LTO issues will

Re: LTO and F33

On 9/30/20 9:25 AM, Zbigniew Jędrzejewski-Szmek wrote: I pushed the following to fix build of sems: https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master Not my package, and the code is a bit iffy, so it's quite likely that the problem is in the package

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

On 9/29/20 5:59 PM, Neal Gompa wrote: I feel like it's worth giving my perspective here as someone who has done similar work in other distributions. Thanks for that viewpoint.    As a compiler optimizer junkie, I don't really follow things on the RPM side, so hearing about that process has

Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)

On 9/30/20 6:50 AM, Mark Wielaard wrote: Hi Neal, On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote: For the record, Mark has started implementing DWARF-5 support in dwz: https://sourceware.org/git/?p=dwz.git;a=log I think I would rather like to see a Change proposal to switch to DWARF-5 fo

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

On 9/30/20 2:33 AM, Jan Kratochvil wrote: On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote: Why don't you add an lldb-add-index tool to generate LLVM indexes for LLDB? Because doing it separately like GDB does is a wrong thing for edit-compile-debug cycle. When clang (lld for LTO) has all

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

On 9/30/20 2:56 AM, Jan Kratochvil wrote: On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote: On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex Currently the change will affect only packages using: %global toolchain c

Re: LTO and F33

On 9/30/20 7:39 AM, Robert-André Mauchin wrote: On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote: So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of have been resolved (by opting the package out of LTO). I still expect some LTO issues will

Re: LTO and F33

On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote: On 30.09.2020 15:39, Robert-André Mauchin wrote: I have an issue with both Clementine and Strawberry (a fork of Clementine) in F33 and above, users reported that disabling LTO fixes the problem. I have the same issue with Telegram Desktop: h

Re: LTO and F33

On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote: On 30.09.2020 15:39, Robert-André Mauchin wrote: I have an issue with both Clementine and Strawberry (a fork of Clementine) in F33 and above, users reported that disabling LTO fixes the problem. I have the same issue with Telegram Desktop: h

Re: LTO and F33

On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote: On 01.10.2020 22:48, Jeff Law wrote: What you want to do to fix this is force -fPIC into the build flags. That inhibits local symbol resolution and the copy relocs that are so problematical for QT.  You can see examples of how to do this in

Re: LTO and F33

On 10/2/20 10:01 AM, Jeff Law wrote: On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote: On 01.10.2020 22:48, Jeff Law wrote: What you want to do to fix this is force -fPIC into the build flags. That inhibits local symbol resolution and the copy relocs that are so problematical for QT.  You

Re: LTO and F33

On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote: On 01.10.2020 22:48, Jeff Law wrote: What you want to do to fix this is force -fPIC into the build flags. That inhibits local symbol resolution and the copy relocs that are so problematical for QT.  You can see examples of how to do this in

Re: Fedora 33 blocker status

On 10/2/20 12:32 PM, Ben Cotton wrote: Beta is out! Time to focus on Final blockers. Action summary Accepted blockers - 1. firefox — Firefox not using langpacks for localization — ASSIGNED ACTION: firefox maintainers to fix issue 2. sddm — login stuck when

Re: Fedora 33 blocker status

On 10/2/20 12:47 PM, Peter Robinson wrote: On Fri, Oct 2, 2020 at 7:37 PM Jeff Law wrote: On 10/2/20 12:32 PM, Ben Cotton wrote: Beta is out! Time to focus on Final blockers. Action summary Accepted blockers - 1. firefox — Firefox not using langpacks

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

On 10/4/20 2:48 PM, Jan Kratochvil wrote: > On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote: >> I was just discussing that recently with the Hotspot Perf GUI >> maintainer. And we concluded that if .debug files would be compressed >> then we would need an uncompressed cache somewhere. The

Re: readelf seems broken in F33

On 9/16/20 3:44 PM, Steve Grubb wrote: > Hello, > > I was doing some binary analysis of files in F33 and have run across > something odd. > > readelf -s /usr/sbin/auditd | grep GLIBC > > produces a lot of output like: > >182: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.

Re: readelf seems broken in F33

On 10/6/20 3:05 PM, Florian Weimer wrote: > * Steve Grubb: > >> I was doing some binary analysis of files in F33 and have run across >> something odd. >> >> readelf -s /usr/sbin/auditd | grep GLIBC >> >> produces a lot of output like: >> >>182: 0 FUNCGLOBAL DEFAULT UN

Re: ELF section/file compression

On 10/6/20 3:59 PM, Mark Wielaard wrote: > Hi, > > Changing subject because this has nothing to do with that Change > Proposal anymore. > > On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote: >> However, I think it's perfectly valid to discuss zstd if

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

On 9/30/20 3:50 AM, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote: >> But the GCC community >> doesn't really test that option and it's known to be broken with LTO. > I haven't seen any GCC PR for -fdebug-types-section being broken

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 10:37 AM, Michael Catanzaro wrote: On Wed, Oct 13 2021 at 06:06:50 PM +0200, Björn 'besser82' Esser wrote: What you describe as lto requires a lot of memory is caused by building lto along with non-lto in the same object file requires significantly more memory.  For that reason

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 10:06 AM, Björn 'besser82' Esser wrote: Building with lto disabled is a bad idea, as Fedora intentionally enabled lto by default. Yes, but there is nothing inherently wrong with not using LTO.  Many packages opt-out for various reasons. What you describe as lto requires a lot

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 8:51 AM, Björn 'besser82' Esser wrote: Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar: Hi, RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide [3, 4] with this message (memory exhausted). The same build on the same machine (CPU and RAM) succeeds on

Re: LTO objects after build: Rebuilding vs erroring out

On 11/15/2021 6:06 AM, Florian Weimer wrote: In the future, we might want to switch GCC not to generate both object code and LTO representation during the build process. For most packages, dual generation is not necessary because no relocatable object files for static linking are included in t

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 1/2/21 3:13 AM, Florian Weimer wrote: > * Ben Cotton: > >> To ensure that we can identify packages that need the opt-in now and >> in the future, the plan is to pass to brp-strip-lto a flag indicating >> whether or not the package has opted into -ffat-lto-objects. If >> brp-strip-lto finds .o

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

ovements> > > > == Summary == > Currently all packages that are not opted out of LTO include > -ffat-lto-objects in their build flags.  This proposal would remove > -ffat-lto-objects from the default LTO flags and only use it for > packages that actually need it. &

Re: HEADS UP: OpenEXR + ilmbase = (new) openexr

On 1/1/21 7:08 PM, Richard Shaw wrote: > All builds have completed in a side tag with the exception of gmic > which looks to be failing for gcc 11 related issues? But only on > 32-bit arches. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=58753095 >

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 1/4/21 2:27 AM, Florian Weimer wrote: > >>> A lot of the existing RPM post-processing steps detect, report, and >>> ignore errors because the generated RPM package might still be partially >>> useful. >> True, but ignoring the error in this case runs the very real risk that a >> package could

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

their build flags.  This proposal would remove >> -ffat-lto-objects from the default LTO flags and only use it for >> packages that actually need it. >> >> == Owner == >> * Name: [[User:law | Jeff Law]] >> * Email: l...@redhat.com >> >> >> == D

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 1/2/21 10:39 AM, Ian McInerney wrote: > > > On Sat, Jan 2, 2021 at 5:33 PM Jeff Law <mailto:l...@redhat.com>> wrote: > > > > On 12/30/20 3:48 PM, Ian McInerney wrote: > > > > > > On Wed, Dec 30, 2020 at 7:54 PM Ben Cotton

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote: > On 20.01.2021 11:31, Miro Hrončok wrote: >> Right before the mass rebuild. Is this known? > > Fedora 34 will be built again with broken, full of regressions GCC > compiler (just like Fedora 32). Fix for this is already approved upstream and li

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

On 1/20/21 9:17 AM, Miro Hrončok wrote: > On 20. 01. 21 17:03, Jeff Law wrote: >> >> >> On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote: >>> On 20.01.2021 11:31, Miro Hrončok wrote: >>>> Right before the mass rebuild. Is this known? >>> >

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

On 1/20/21 9:08 AM, Vitaly Zaitsev via devel wrote: > On 20.01.2021 17:03, Jeff Law wrote: >> Fix for this is already approved upstream and likely going into a new >> spin of gcc. > > Today I got two new GCC regressions in the same package. Reported to > RHBZ. THen it

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

On 1/20/21 9:29 AM, Miro Hrončok wrote: > On 20. 01. 21 17:21, Jeff Law wrote: >> >> >> On 1/20/21 9:17 AM, Miro Hrončok wrote: >>> On 20. 01. 21 17:03, Jeff Law wrote: >>>> >>>> >>>> On 1/20/21 8:47 AM, Vitaly Zaitsev via devel

Re: Crash, maybe, in packaging scripts on Koji/s390

On 1/20/21 3:53 AM, Richard W.M. Jones wrote: > On Wed, Jan 20, 2021 at 10:52:35AM +, Richard W.M. Jones wrote: >> https://kojipkgs.fedoraproject.org//work/tasks/9457/60089457/build.log >> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=60089433) >> >> ends with ... >> >> Checking f

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

On 1/21/21 8:26 AM, Miro Hrončok wrote: > On 20. 01. 21 17:03, Jeff Law wrote: >> >> >> On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote: >>> On 20.01.2021 11:31, Miro Hrončok wrote: >>>> Right before the mass rebuild. Is this known? >>> >

Re: Fedora 34 Mass Rebuild

On 1/26/21 9:13 AM, Jonathan Wakely wrote: > On 26/01/21 16:52 +0100, Fabio Valentini wrote: >> On Tue, Jan 26, 2021 at 4:47 PM Jonathan Wakely >> wrote: >>> >>> On 25/01/21 15:16 +0100, Fabio Valentini wrote: >>> >On Thu, Jan 21, 2021 at 5:10 PM Jakub Jelinek >>> wrote: >>> >> >>> >> On Wed, J

Re: unrecognized DWARF version in .debug_info at 6

On 1/27/21 5:48 AM, Sandro Mani wrote: > > Hi > > Apitrace is currently failing to build, with [1] > > Test project > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu > Start 1: libbacktrace_btest > 1/6 Test #1: libbacktrace_btest ..

Re: Test failures

On 1/28/21 10:16 AM, Boian Bonev wrote: > Hi, > > I just did a build (new upstream release of iotop-c) and saw a couple > of test errors; they look like segfaults or post errors, so I suppose > that I didn't do some stupid mistake. > > Posting the result here, to keep the relevant team informed;

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 2/2/21 5:03 PM, Ian McInerney wrote: > On Mon, Jan 4, 2021 at 7:28 PM Jeff Law <mailto:l...@redhat.com>> wrote: > > > snip... > > > > What is this macro going to be called?  I would like to get an early > > start on updating m

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

On 2/10/21 11:00 AM, Miro Hrončok wrote: > On 10. 02. 21 18:47, Ben Cotton wrote: >> == Upgrade/compatibility impact == >> Problems during build can appear in multiple packages what can lead to >> build failure, as multiple packages require autoconf-2.69 as their >> upstream dependency. These pro

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

On 2/23/21 4:39 PM, Brian C. Lane wrote: > On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote: >> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/ > Doesn't work, with or without :8080 Not sure what you're referring to, it just worked fine for me. > > parted is failing w

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

On 2/23/21 4:54 PM, Jerry James wrote: > On Tue, Feb 23, 2021 at 4:52 PM Jeff Law wrote: >> On 2/23/21 4:39 PM, Brian C. Lane wrote: >>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote: >>>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoc

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/23/2021 10:32 AM, Tom Stellard wrote: On 4/23/21 8:27 AM, Ben Cotton wrote: On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton wrote: change proposal replaces that policy with one where, given a good technical reason, a packager may: * Choose to build with their package with clang even if the

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/23/2021 9:57 AM, Daniel P. Berrangé wrote: On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/CompilerPolicy == Summary == Fedora has historically forced packages to build with GCC unless the upstream project for the package only supported C

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/23/2021 6:37 PM, Tom Stellard wrote: On 4/23/21 4:55 PM, Kevin Kofler via devel wrote: Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/CompilerPolicy Is the change owners' plan here to resubmit this same rejected change for every single release until people get so fed up that

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote: Vít Ondruch wrote: Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clang for e.g. Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1721553 And the reason is not even that upstream

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/26/2021 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote: On 23.04.2021 17:18, Ben Cotton wrote: The goal is to give the packager the ability to use their own technical judgement to choose the best compiler. +1 for this

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/24/2021 8:26 AM, Michael Catanzaro wrote: On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek wrote: I'll be probably repeating myself, but the two compilers are known to be ABI incompatible in very important ways, none of the https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C1990

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/24/2021 3:10 AM, Kevin Kofler via devel wrote: Tom Stellard wrote: This change was never rejected. It become stalled waiting for the change owners to address some feedback from FESCo. The feedback has been addressed now, which is why it was resubmitted. Ah, then I hereby urge FESCo to f

Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

On 4/26/2021 9:52 AM, Jakub Jelinek wrote: On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote: On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote: Vít Ondruch wrote: Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clan

Re: i686 build OOMing

On 5/18/2021 4:44 PM, David Airlie wrote: https://kojipkgs.fedoraproject.org//work/tasks/3814/68223814/build.log cd /builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers && /usr/bin/g++ -DAPI_NAME=\"Vulkan\" -DVK_ENABLE_BETA_EXTENSIONS -DVK_USE_PLATFORM_WAYLA

Re: F35 mass rebuild is finished

On 7/27/2021 10:31 AM, Björn 'besser82' Esser wrote: Am Dienstag, dem 27.07.2021 um 16:23 +0200 schrieb Tomas Hrcka: Hi all, Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35 on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for: https://fedoraproject.org/wiki/Change

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 8/12/2021 10:09 AM, Vít Ondruch wrote: Just wonder, have somebody inherited this feature after Jeff? And is anybody actually working on the LTO? ~~~ $ grep -R lto | grep -E 'global|define' | grep nil | wc -l 190 I don't think anyone is actively working on reducing that set.   But that t

Re: Any recent changes to the arm builders?

On 8/14/2021 10:19 AM, Kevin Fenzi wrote: On Fri, Aug 13, 2021 at 09:34:11PM -0600, Orion Poplawski wrote: Have there been any recent changes to the arm (32bit) builders? It seems like I'm having much more issues there with builds likely running out of memory or similar. Yes. They were mista

Re: Enable LTO build for crash utility

On 8/17/2021 8:45 PM, lijiang wrote: Hi, In Fedora crash.spec, currently the LTO is disabled as below: +# This package has an internal copy of GDB which has broken configure code for +# INTDIV0_RAISES_SIGFPE and MUST_REINSTALL_SIGHANDLERS +# Updating that code properly seems nontrivial and

<    1   2   3