Red Hat & Fedora -- largely stepping out of this ecosystem

I have no illusions that this message is going to change anything at Red Hat. But I feel I need to get this off my chest. I'm speaking strictly for myself, not for my current or any former employer, not for the GCC project and not for any other group/organization I might have some affiliation

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/19/23 00:26, Benson Muite wrote: Probably each hardware vendor will need to become more involved in creating an RPM distribution for their use case and providing hardware for test builds. A single monolithic Fedora will not work. Having a subset of base packages would be very helpful.

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/19/23 07:46, Florian Weimer wrote: * Jeff Law: Rather than trying to track all the individual extensions and combinations thereof, I would suggest focusing on RVI defined profiles. Essentially they provide a set of mandatory features the architecture must support (to be compliant with

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/15/23 00:25, David Abdurachmanov wrote: On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote: On 4/14/23 20:14, Neal Gompa wrote: We should not screw up with RISC-V in Fedora like RHEL did with ARM. Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to some

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/15/23 00:10, David Abdurachmanov wrote: We have to support SCBs as-is. We even have 64-core OoO (and even dual-socket 128-core) systems coming that are still RVA20 (what I call "a large scale SBC trying to be a server"). I think elsewhere you suggested treating the profile as the subarc

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/14/23 20:14, Neal Gompa wrote: We should not screw up with RISC-V in Fedora like RHEL did with ARM. Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to some degree. We see aspects of this being walked back now as the ecosystem didn't go the way RHEL ARM folks hoped, and

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/12/23 10:08, przemek klosowski via devel wrote: That may rule out certain processors, but it ultimately provides a higher performing baseline architecture for systems that are (hopefully) going to be good performing parts rather than embedded focused parts. Yes, good point, but there

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/12/23 10:57, David Abdurachmanov wrote: We have been focusing and building for RV64GC, which is kinda represented by the RVA20 profile. RVA20 is considered a major profile, but it significantly lacks modern ISA extensions. There is also RVA22, which is considered a "minor" profile. The n

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

On 4/11/23 19:14, przemek klosowski via devel wrote: On 4/4/23 10:28, Dan Čermák wrote: Chris Adams writes: Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a PITA sometimes.  But cramming multiple architectures of core libraries into a single RPM would be bad for disk sp

Re: Risc-V SIG?

On 2/9/23 08:49, David Abdurachmanov wrote: There are two generic issues in Fedora that keep popping up: - Wrong assumption about valgrind. Those are easy to fix, but are in a number of places. Note that valgrind upstreaming will happen relatively soonish too. Yea, but I don't have a high degr

Re: Fedora 38 mass rebuild is finished

On 1/24/23 15:52, Gary Buhrmaster wrote: Had I seen cstdint I like to think that I would have tried a rebuild with gcc 13 earlier to see what (if any) upstream(s) needed some encouragement for support gcc 13. I actually did stuff like this in the past -- build all of Fedora with the new comp

Re: Fedora 38 mass rebuild is finished

On 1/24/23 00:16, Jakub Jelinek wrote: On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote: I have some packages failed. One of them libtins. Problem is that: error: 'uint32_t' is not a member of 'std'; Is it normal? Is it GCC 13 change? See https://gcc.gnu.org/gcc-13/porting_to.html#he

Re: RISC-V -- are we ready for more, and what do we need to do it?

On 1/9/23 07:14, Neal Gompa wrote: It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG. I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL. The Alternative Arch

Re: RISC-V -- are we ready for more, and what do we need to do it?

On 1/6/23 16:19, Jun Aruga (he / him) wrote: I posted the same article on Fedora Discussion.[1] However let me share it again on the devel@ to tell it to many people. This is interesting news about RISC-V this week. Perhaps, it’s time to prepare to add the RISC-V CPU to the Koji build system?

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

On 10/26/22 02:58, Florian Weimer wrote: * Richard W. M. Jones: On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote: Neither change is trivial to implement because introducing errors for these constructs (as required by C99) alters the result of autoconf configure checks. Quite a few s

Re: Help needed: build failure trying to upgrade healpix

On 8/14/2022 6:29 AM, Jarryd Lisher via devel wrote: Hey, I figured out that this is mainly caused by the configure script containing multi-line definitions. So, the hacks only operate on the first part and land up leaving random lines of nonsense in the file. You can fix this by adding the f

Re: Help needed: build failure trying to upgrade healpix

On 8/3/2022 2:00 PM, Kevin Kofler via devel wrote: Jeff Law wrote: That would eliminate the need for those crazy macros. The problem is many packages have configury bits that are ancient and can't be rebuilt with modern autotools. I have a hard time believing that. Well, having been th

Re: Help needed: build failure trying to upgrade healpix

On 8/3/2022 6:55 AM, Richard W.M. Jones wrote: On Sun, Jul 31, 2022 at 03:33:51PM +0200, Kevin Kofler via devel wrote: Jerry James wrote: On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel wrote: What I see is that the hacks that you apply to configure are apparently not working: che

Re: Making Fedora faster (was Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal))

On 7/10/2022 11:36 AM, Gordon Messmer wrote: On 7/10/22 04:38, Vitaly Zaitsev via devel wrote: Have you rebuilt all system packages with -fno-omit-frame-pointer or just tested packages? No.  Early in the thread, Tomasz Torcz posted a link to a Phoronix article as evidence that Fedora's pe

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On 7/6/2022 1:05 PM, Florian Weimer wrote: * Michael Catanzaro: On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law wrote: If I'm understanding things correctly, the original proposal is trying to make a very special case of profiling work better -- a case that 99.9% of Fedora users d

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On 7/6/2022 8:20 AM, Michael Catanzaro wrote: On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law wrote: If I'm understanding things correctly, the original proposal is trying to make a very special case of profiling work better -- a case that 99.9% of Fedora users do not need or care

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On 7/6/2022 7:26 AM, Marek Polacek wrote: On Tue, Jul 05, 2022 at 03:47:26PM -0400, Matthias Clasen wrote: On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek wrote: Maybe not, but even ~1% is still an unacceptable slowdown. It would take about a year for the compiler to catch up. (Un)acceptab

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: 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: 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 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: 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

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: 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: 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: 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 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: 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/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/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/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/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/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 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: 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: 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/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 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: 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: 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: 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: /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: 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/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: /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: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 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: 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: 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/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: 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)

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: 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: Chromium built in rawhide does not render most strings

On 12/20/20 7:45 PM, Kevin Kofler via devel wrote: > Neal Gompa wrote: >> QtWebEngine *is* Chromium, so it would make sense that it exhibits the >> same problem. > To be clear (and I know you know this, but your readers might not know), > QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are

Re: gcc11/kconfig_compiler (was: weird build failure on i686)

On 12/19/20 9:40 PM, Rex Dieter wrote: > Mattia Verga via devel wrote: > >> While trying to build a new kde-partitionmanager release, I get a strange >> build failure which seems related to character encoding: >> >> https://kojipkgs.fedoraproject.org//work/tasks/8985/57428985/build.log >> >> /bui

Re: GCC 11 related build failure

On 12/14/20 4:41 PM, Robert-André Mauchin wrote: > > Hello, > > While building Googletest, I've encourtered this failure: > > >> /builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h: >> In instantiation of 'void >> testing_internal::DefaultPrintNonC

Re: dav1d SONAME bump

On 12/13/20 10:04 PM, Robert-André Mauchin wrote: > >  - VLC: Fails with error: 'numeric_limits' is not a member of 'std' > Reported upstream: > https://trac.videolan.org/vlc/ticket/25325 > I have a patch to try for this. > I have CC RPMFusion. Yea, this is a common problem with the introduction

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

On 12/13/20 9:03 AM, Richard Shaw wrote: > On Sun, Dec 13, 2020 at 9:20 AM Jeff Law <mailto:l...@redhat.com>> wrote: > > > So I've committed fixes for kdelibs.  So you shouldn't have to worry > about that anymore. > > Also note I fixed an

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

On 12/12/20 1:38 PM, Richard Shaw wrote: > On Thu, Dec 10, 2020 at 1:52 PM Richard Shaw > wrote: > > For posterity here's the affected packages as far as I can tell: > > lembic > aqsis > blender > calligra > cinelerra-gg > CTL > darkta

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

On 12/12/20 1:38 PM, Richard Shaw wrote: > On Thu, Dec 10, 2020 at 1:52 PM Richard Shaw > wrote: > > For posterity here's the affected packages as far as I can tell: > > lembic > aqsis > blender > calligra > cinelerra-gg > CTL > darkta

Re: Nothing provides libgnat-10.so()(64bit)

On 12/7/20 1:48 PM, Pavel Zhukov wrote: > Hi Jeff. > Thank you for rebuilding xmlada. I'll continue from there as I want to > use this bootstrap to update packages to newest upstream version > anyway . ACK.  That'll definitely help.  I'll keep my gprbuild bits here (they aren't complete/working a

Re: Nothing provides libgnat-10.so()(64bit)

On 12/7/20 11:07 AM, Jakub Jelinek wrote: > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote: >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): > I'm not a provenpackager, so I'm afraid I can't do that myself. > Perhaps the maintainers can just rebuild the

Re: LTO running out of memory on ARMv7 builders

On 12/1/20 12:05 PM, Richard W.M. Jones wrote: > This Rawhide build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=56536942 > seems to have failed because of LTO running out of memory on armv7. > The error is: > > lto1: out of memory allocating 104 bytes after a total of 2966994944 byte

Re: gcc-11 rawhide mock config?

On 11/25/20 5:41 AM, Gabriel L. Somlo wrote: > Hi, > > Someone dropped a gcc-11 specific patch into a package I > (co-)maintain: > > https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?branch=master > > which really rather belongs upstream. I'd like to test it befo

Re: qemu & LTO

On 11/5/20 8:24 AM, Richard W.M. Jones wrote: > We discovered a few days ago that LTO broke qemu on aarch64. > > The original bug reported was: > > https://bugzilla.redhat.com/show_bug.cgi?id=1893892 > > But actually looking at the build.log[1] we see another assertion > failure in the test suit

Re: Rawhide build failure on strange archs

On 11/7/20 1:38 PM, Orion Poplawski wrote: > On 11/7/20 1:26 PM, Steve Dickson wrote: >> Hello, >> >> I'm getting a build failure on the armv7hl arch >> and the i686 arch, which do not make much sense. >> >> The build is [1] and only those arche are  complaining about an >> sprintf() statement. >>

Re: HEADSUP: libsepol and libsemanage soname bump

On 11/5/20 7:59 AM, Petr Lautrbach wrote: > On Wed, Nov 04, 2020 at 09:47:50AM +0100, Petr Lautrbach wrote: >> Hi, >> >> in order to prevent backward compatibility libsepol and libsemanage used had >> few >> symbols defined twice and used symbol versioning for them. But when LTO was >> enabled th

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

On 11/4/20 2:06 PM, Tom Stellard wrote: > On 11/4/20 3:57 PM, Jakub Jelinek wrote: >> On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote: Well, gcc really should have either weak or strong dependency on make too given that -flto is now used everywhere. >>> >>> The goal of th

Re: ld segfaults on rawhide

On 11/3/20 9:56 AM, Kevin Fenzi wrote: > On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: >> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: >>> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: >>>> >>>> On 10/31/20 9:13 AM, Christo

Re: ld segfaults on rawhide

On 10/31/20 9:13 AM, Christoph Junghans wrote: > Hi, > > I am getting the following error on all archs on rawhide: > collect2: fatal error: ld terminated with signal 11 [Segmentation > fault], core dumped > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 > > any ideas? Given it's

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/28/20 7:29 AM, Jonathan Wakely wrote: > On 28/10/20 13:31 +0100, Florian Weimer wrote: >> * Jonathan Wakely: >> >>> Dropping GCC 11 into rawhide now would mean I can't make certain >>> ABI-breaking changes to the C++20 library in upstream GCC, because it >>> would be landing on real users' m

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/23/20 5:55 AM, Clement Verna wrote: > > > On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova > wrote: > > Hi, all, > > this is the informational message, no action required. > > Upon agreement between gcc maintainers and ELN SIG we would like to > s

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/23/20 8:01 AM, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 23 October 2020 at 14:45, Aleksandra Fedorova wrote: > [...] >> You can blame me for being not clear enough, if you want, but I'd >> rather move on and use the current GCC11 work as an example which >> shows the real power of

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 9:28 AM, Petr Pisar wrote: > On Thu, Oct 22, 2020 at 09:20:28AM -0600, Jeff Law wrote: >> On 10/22/20 8:27 AM, Petr Pisar wrote: >>> On Thu, Oct 22, 2020 at 08:10:02AM -0600, Jeff Law wrote: >>>> I do think we need to make it easier for a Fedora package

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 8:27 AM, Petr Pisar wrote: > On Thu, Oct 22, 2020 at 08:10:02AM -0600, Jeff Law wrote: >> I do think we need to make it easier for a Fedora package maintainer to >> get the gcc-11 bits so that if there's a need to debug a bad interaction >> between gcc

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 8:09 AM, Daniel P. Berrangé wrote: > On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote: >> Hi, Daniel, >> >> On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé >> wrote: >>> On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote: Hi, all,

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 7:00 AM, Daniel P. Berrangé wrote: > On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote: >> Hi, all, >> >> this is the informational message, no action required. >> >> Upon agreement between gcc maintainers and ELN SIG we would like to >> switch ELN buildroot to use GC

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 6:53 AM, Neal Gompa wrote: > On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova > wrote: >> Hi, all, >> >> this is the informational message, no action required. >> >> Upon agreement between gcc maintainers and ELN SIG we would like to >> switch ELN buildroot to use GCC11 ahead of F

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On 10/22/20 7:02 AM, Kalev Lember wrote: > On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa > wrote: > > On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova > mailto:al...@bookwar.info>> wrote: > > > > Hi, all, > > > > this is the informational message

Re: glibc troubles in rawhide?

On 10/20/20 5:14 PM, Adam Williamson wrote: > On Tue, 2020-10-20 at 18:47 -0400, Neal Gompa wrote: >> Can >> we use our gating system to kick back builds that are obviously broken >> that even the package manager stops working? > Theoretically, yes, this is possible. We could add this and any othe

Re: glibc troubles in rawhide?

On 10/20/20 4:47 PM, Neal Gompa wrote: > On Tue, Oct 20, 2020 at 6:44 PM Jeff Law wrote: >> >> On 10/20/20 4:41 PM, Jerry James wrote: >>> On Tue, Oct 20, 2020 at 4:38 PM Fabio Valentini >>> wrote: >>>> Looks like the most recent glibc update in raw

Re: glibc troubles in rawhide?

On 10/20/20 4:41 PM, Jerry James wrote: > On Tue, Oct 20, 2020 at 4:38 PM Fabio Valentini wrote: >> Looks like the most recent glibc update in rawhide broke some stuff, >> including running dnf: > That looks like the same problem I wrote about this morning: > > https://lists.fedoraproject.org/arc

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: 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: 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: 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: 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: 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: 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: 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: 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 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

  1   2   3   >