Re: super-drafty F28 and F29 schedules

On 07/13/2017 09:27 AM, Matthew Miller wrote: > On Thu, Jul 13, 2017 at 09:23:58AM -0600, Jeff Law wrote: >>>> Likewise. We should keep this schedule in mind as we work our way >>>> through stage3 into stage4. Ideally Marek would start the test builds >>>

Re: super-drafty F28 and F29 schedules

On 07/13/2017 09:01 AM, Matthew Miller wrote: > On Wed, Jul 12, 2017 at 03:14:24PM -0600, Jeff Law wrote: >>> LGTM. >> Likewise. We should keep this schedule in mind as we work our way >> through stage3 into stage4. Ideally Marek would start the test builds >> prio

Re: super-drafty F28 and F29 schedules

On 07/12/2017 06:10 AM, Jakub Jelinek wrote: > On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote: >> On 07/06/2017 09:15 PM, Matthew Miller wrote: >>> https://fedoraproject.org/wiki/Releases/28/Schedule >> >> I encourage Jeff Law and Jakub Jel

Re: super-drafty F28 and F29 schedules

On 07/12/2017 02:54 PM, Jakub Jelinek wrote: > On Wed, Jul 12, 2017 at 04:45:56PM -0400, Matthew Miller wrote: >> On Wed, Jul 12, 2017 at 04:30:12PM -0400, Matthew Miller wrote: >>> So, "one week earlier than last time" would be January 31st. (Or 30th? >>> Depends if we want that on a Tuesday like

Re: 389-ds-base and freeipa on 32 bit arches

On 02/23/2018 10:29 AM, Alexander Bokovoy wrote: > On pe, 23 helmi 2018, Jeff Law wrote: >> On 02/23/2018 09:58 AM, Randy Barlow wrote: >>> Greetings gcc maintainers! >>> >>> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and >&g

Re: 389-ds-base and freeipa on 32 bit arches

On 02/23/2018 09:58 AM, Randy Barlow wrote: > Greetings gcc maintainers! > > A FESCo issue[0] has been filed due to the dropping of 389-ds-base and > freeipa on 32 bit arches for Fedora 28. This was done without a change > request being filed, so FESCo is trying to decide how best to handle it. >

Re: gcc 10 plans for Fedora 32?

On Wed, 2019-12-11 at 14:53 +0100, Miro Hrončok wrote: > Hello, > > what are the gcc 10 plans for Fedora 32? Will there be a change > proposal for > that? Is Fedora 32 the target for gcc 10? Plan is for gcc-10 to be the compiler for F32. We coordinate with the Fedora leaders on this each year

Re: devel Digest, Vol 190, Issue 187

On Thu, 2019-12-19 at 22:14 +, devel- requ...@lists.fedoraproject.org wrote: Igor, > Send devel mailing list submissions to > > It would be very nice to get more specific analysis data. Like running > some benchmarks of big applications, size comparisons (of binaries and > libraries) and

Re: devel Digest, Vol 190, Issue 186

On Thu, 2019-12-19 at 21:56 +, devel- requ...@lists.fedoraproject.org wrote: > Neal, > > I'm generally happy with this idea. I'm one of the maintainers of > rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE > distributions) and I somewhat saw the development of this feature >

Re: devel Digest, Vol 190, Issue 186

On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote: > On Thu, Dec 19, 2019 at 4:14 PM Jeff Law wrote: > > On Thu, 2019-12-19 at 21:56 +, devel- > > requ...@lists.fedoraproject.org wrote: > > > > Neal, > > > > > > > I'm generally

Re: devel Digest, Vol 190, Issue 186

On Sat, 2019-12-21 at 10:52 -0500, Josh Boyer wrote: > On Thu, Dec 19, 2019 at 5:48 PM Jeff Law wrote: > > On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote: > > > On Thu, Dec 19, 2019 at 4:14 PM Jeff Law wrote: > > > > On Thu, 2019-12-19 at 21

Re: digested list etiquette [ was: devel Digest, Vol 190, Issue 186 ]

On Fri, 2019-12-20 at 12:59 -0500, Robbie Harwood wrote: > Hi, > > When replying to digests, I'd appreciate if you could please make an > effort to have the posts thread properly for the rest of us. Fedora > mailing list guidance on this: >

Re: Fedora 32 System-Wide Change proposal: LTO by default for package builds

On Fri, 2019-12-20 at 11:52 +0100, Miro Hrončok wrote: > On 19. 12. 19 22:41, Ben Cotton wrote: > > https://fedoraproject.org/wiki/LTOByDefault > > > > == Contingency Plan == > > * Contingency mechanism: Revert the LTO flags injection > > * Contingency deadline: Beta freeze, but shooting for

Re: Non-responsive maintainer check for libffi maintainer

On Mon, 2020-02-24 at 13:02 +, devel- requ...@lists.fedoraproject.org wrote: > > Date: Mon, 24 Feb 2020 12:10:49 +0100 > From: Miro Hrončok > Subject: Re: Non-responsive maintainer check for libffi maintainer > To: Anthony Green > Cc: Development discussions related to Fedora > >

Re: Fedora 32 Mass Rebuild

On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote: > On Mon, Jan 27, 2020 at 4:46 PM Jeff Law wrote: > > On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote: > > > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote: > > > > Hi all, > > >

Re: cjdns with gcc-10 in Fedora

On Wed, 2020-01-22 at 16:11 -0700, Jeff Law wrote: > On Wed, 2020-01-22 at 22:03 +, devel- > requ...@lists.fedoraproject.org wrote: > > Send devel mailing list submissions to > > devel@lists.fedoraproject.org > > > > To subscribe or unsubscribe via emai

Re: gcc 10: Default to -fno-common, multiple definitions of

On Thu, 2020-01-23 at 17:23 -0500, Steve Grubb wrote: > On Tuesday, January 21, 2020 1:52:54 PM EST Jeff Law wrote: > > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > > > > time to fix properly. I even volunteered to add t

Re: Fedora 32 Mass Rebuild

On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote: > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote: > > Hi all, > > > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the > > changes: >

Re:gcc-10 Fortran argument mismatch issue

ject.org > Message-ID: <20200121202747.ga5...@sakura.greysector.net> > Content-Type: text/plain; charset=utf-8 > > Hi, Jeff. > > On Tuesday, 21 January 2020 at 21:16, Jeff Law wrote: > > > > So this is another issue that's going to be seen with gcc-10. I'd bee

Re: Re: gcc 10: Default to -fno-common, multiple definitions of ...

> Date: Wed, 22 Jan 2020 07:34:01 -0600 > From: Justin Forbes > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: Development discussions related to Fedora > > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Wed, Jan 22, 2020

Re: cjdns with gcc-10 in Fedora

On Wed, 2020-01-22 at 22:03 +, devel- requ...@lists.fedoraproject.org wrote: > Send devel mailing list submissions to > devel@lists.fedoraproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > devel-requ...@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of

On Tue, 2020-01-21 at 19:16 +0100, Miro Hrončok wrote: > On 21. 01. 20 19:04, Jeff Law wrote: > > > -- > > > > > > > > > Date: Tue, 21 Jan 2020 17:44:37 + > > > From: Pe

Re: gcc 10: Default to -fno-common, multiple definitions of ...

> Date: Tue, 21 Jan 2020 14:00:30 +0100 > From: Miro Hrončok > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: devel@lists.fedoraproject.org, Jakub Jelinek > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > On 21. 01. 20 13:47,

Re: gcc 10: Default to -fno-common, multiple definitions of ...

On Tue, 2020-01-21 at 13:47 +0100, Jakub Jelinek wrote: > On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote: > > I've seen this issue pop up in some other packages, as well. > > > > My elementary-files package is affected, and I think it broke > > rubygem-ffi, too (which is blocking

gcc-10 Fortran argument mismatch issue

So this is another issue that's going to be seen with gcc-10. I'd been hoping to get the time to fix packages correctly, but I think it's ultimately going to have to fall to the package maintainers. gcc has traditionally allowed certain type mismatches for arguments in Fortran code. GCC

Re: gcc 10: Default to -fno-common, multiple definitions of ...

> > > > Date: Tue, 21 Jan 2020 11:05:37 -0500 > From: Steve Grubb > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: devel@lists.fedoraproject.org > Cc: Jakub Jelinek > Message-ID: <4127758.jL2Gs7s9Fr@x2> > Content-Type: text/plain; charset="UTF-8" > >

Re: gcc 10: Default to -fno-common, multiple definitions of

> > -- > > > Date: Tue, 21 Jan 2020 17:44:37 + > From: Peter Robinson > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: l...@redhat.com, Development discussions related to Fedora

Re: gcc 10: Default to -fno-common, multiple definitions of

On Tue, 2020-01-21 at 13:33 -0500, Steve Grubb wrote: > On Tuesday, January 21, 2020 1:16:00 PM EST Miro Hrončok wrote: > > > > > > I proposed a change to redhat-rpm-config to handle this case by > > > > > > > > > > allowing package to add a single line to their .spec file to turn off > > > > >

Re: Fedora 32 System-Wide Change proposal: GCC10

On Thu, 2020-01-02 at 19:48 +, devel- requ...@lists.fedoraproject.org wrote: > Date: Thu, 2 Jan 2020 12:52:03 -0500 > From: Kaleb Keithley > Subject: Re: Fedora 32 System-Wide Change proposal: GCC10 > To: Development discussions related to Fedora > > Message-ID: > >

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

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

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

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 with LTO.  I'

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

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

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 f

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

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

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 workar

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 >

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

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 expect &g

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

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

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 pop up

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

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

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:

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

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

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 pop up

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

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

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

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'

Re: Fedora 32 aarch64 build failures on copr

On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote: > On 7/29/20 4:40 PM, Jeff Law wrote: > > ACK. I don't see msp430-development-tools in the standard fedora repos. > > So I'll > > leave it to you to fix the package in whatever repo it lives in. > > > &

Re: Fedora 32 aarch64 build failures on copr

On Wed, 2020-07-29 at 14:24 -0500, Brandon Nielsen wrote: > On 7/28/20 4:39 PM, Jeff Law wrote: > > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote: > > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote: > > > > If this is a new failure (say in the

Re: Disable LTO for now ?

On Wed, 2020-07-29 at 20:39 +0100, Sérgio Basto wrote: > On Wed, 2020-07-29 at 12:19 -0500, Steven Munroe wrote: > > Jeff Law wrote: > > > > > For ppc64le is that the build was done with p8, but there is one > > > function (__builtin_altivec_vadub) that r

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

On Mon, 2020-08-03 at 17:26 +0100, Daniel P. Berrangé wrote: > On Mon, Aug 03, 2020 at 05:34:47PM +0200, Hans de Goede wrote: > > Hi, > > > > On 8/3/20 5:27 PM, Daniel P. Berrangé wrote: > > > On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote: > > > > * Daniel P. Berrangé: > > > > >

Re: Another possible LTO failure in guestfish (or maybe readline)

On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote: > Hi, > > seeing the amount of fallout from LTO, I really think that this feature > ought to be dropped from F33, and evaluated carefully for F34 (i.e., can it > be done without breaking the build of or miscompiling a large part of the >

Re: Another possible LTO failure in guestfish (or maybe readline)

On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > > > Looks l

Re: Another possible LTO failure in guestfish (or maybe readline)

On Sat, 2020-08-01 at 21:00 +0100, Richard W.M. Jones wrote: > On Sat, Aug 01, 2020 at 01:28:09PM -0600, Jeff Law wrote: > > On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote: > > > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > > > > On

Re: postgis LTO failure

On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote: > Hi > > postgis seems another one suffering from LTO related failures. > > LTO (results in test failures): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 > > LTO disabled (tests pass): >

Re: Another possible LTO failure in guestfish (or maybe readline)

On Sat, 2020-08-01 at 15:26 -0700, Kevin Fenzi wrote: > On Sat, Aug 01, 2020 at 02:03:40PM -0600, Jeff Law wrote: > > On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote: > > > Hi, > > > > > > seeing the amount of fallout from LTO, I really think that thi

Re: What do to about massive # of FTBFS bugs?

On Mon, 2020-08-03 at 18:39 -0500, Richard Shaw wrote: > On Mon, Aug 3, 2020 at 6:12 PM Kevin Fenzi wrote: > > On Mon, Aug 03, 2020 at 10:28:03PM +0100, Richard W.M. Jones wrote: > > > On Mon, Aug 03, 2020 at 04:04:57PM -0500, Richard Shaw wrote: > > > > I'm up to 21 and climbing. Technically two

Re: Arch-specific LTO problems

On Mon, 2020-08-03 at 14:06 -0600, Jerry James wrote: > On Mon, Aug 3, 2020 at 11:33 AM Tom Stellard wrote: > > These are all likely caused by the linker running out of memory and > > getting killed by the OOM killer. > > I see. In that case, I'll try resubmitting each build once and see if >

Re: mpich always injects lto flags

On Thu, 2020-08-06 at 15:59 -0600, Christoph Junghans wrote: > On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans wrote: > > On Wed, Aug 5, 2020 at 2:21 PM Jeff Law wrote: > > > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote: > > > > On 8/5/20 8:4

Re: What do to about massive # of FTBFS bugs?

On Thu, 2020-08-06 at 17:54 +0200, Fabio Valentini wrote: > On Thu, Aug 6, 2020 at 4:51 PM Jeff Law wrote: > > On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote: > > > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini > > > wrote: > > > > I'd say it's

Re: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 20:40 -0600, Orion Poplawski wrote: > On 8/6/20 9:01 AM, Jeff Law wrote: > > On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote: > > > InsightToolkit fails to build with LTO: > > > > > > /usr/bin/ld.gold: fatal error: lto-wrap

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

On Tue, 2020-08-04 at 13:16 +0100, Daniel P. Berrangé wrote: > On Tue, Aug 04, 2020 at 12:02:05PM +0200, Florian Weimer wrote: > > * Daniel P. Berrangé: > > > > > Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923 > > > > Sorry, what would be more interesting is the linker

Re: mame fails to build with LTO enabled

On Fri, 2020-08-07 at 07:19 +0200, Julian Sikorski wrote: > Hi list, > > mame has failed to build with lto enabled due to violation of C++ one > definition rule apparently: > https://koji.fedoraproject.org/koji/taskinfo?taskID=48829086 > I don't really know how to fix it. I am going to disable

Re: What do to about massive # of FTBFS bugs?

On Fri, 2020-08-07 at 17:08 +0200, Dominique Martinet wrote: > Fabio Valentini wrote on Fri, Aug 07, 2020: > > - waypipe / armv7hl: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713 > > See the "arm/neon LTO-related FTBS" thread on the list for that one; I > gave a short recap on

Re: LTO and the F33 mass rebuild

On Mon, 2020-08-10 at 09:59 +0200, Miro Hrončok wrote: > On 09. 08. 20 0:02, Jeff Law wrote: > > For any package which was failing and LTO appeared to be a factor, I've > > assigned > > the package's associated FTBFS BZ to me to address the LTO component. Some > >

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

On Tue, 2020-08-04 at 21:36 +0200, Florian Weimer wrote: > * Jeff Law: > > > Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do > > we > > have more than one build running at a time on those boxes? > > It's a 32-bit build. I as

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

On Tue, 2020-08-04 at 11:34 -0700, Kevin Fenzi wrote: > On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote: > > On 04. 08. 20 18:16, Florian Weimer wrote: > > > * Miro Hrončok: > > > > > > > Hello, I've got this failure I cannot really understand, it happens on > > > > armv7hl only

Re: Arch-specific LTO problems

On Tue, 2020-08-04 at 08:05 -0700, Tom Stellard wrote: > On 8/4/20 11:02 AM, Jerry James wrote: > > On Tue, Aug 4, 2020 at 12:33 AM Jeff Law wrote: > > > If we're blowing up memory on the builder, then we should probably > > > disable LTO on > > > the

Re: Help needed to fix a FTBFS (shaderc)

On Sat, 2020-08-08 at 15:51 -0400, Neal Gompa wrote: > On Sat, Aug 8, 2020 at 3:47 PM Robert-André Mauchin wrote: > > On Saturday, 8 August 2020 17:27:54 CEST you wrote: > > > And so on. > > > Tons of errors regarding undefined reference to glslang::. > > > I don't know if this is due to a new

Re: Help needed to fix a FTBFS (shaderc)

On Sat, 2020-08-08 at 17:27 +0200, Robert-André Mauchin wrote: > Hello, > > shaderc was FTBFS due to the cmake change, however fixing it does not solve > everything. I've got a long list of new errors: > > > === >

Re: Help needed to fix a FTBFS (shaderc)

On Sat, 2020-08-08 at 22:04 +0200, Robert-André Mauchin wrote: > On Saturday, 8 August 2020 21:53:57 CEST Jeff Law wrote: > > More likely it's uninstantiated templates > > I don't know about this, did we change something within Fedora that could > trigger this issue while it

LTO and the F33 mass rebuild

So I've done two passes over the F33 build failures here: https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html For any package which was failing and LTO appeared to be a factor, I've assigned the package's associated FTBFS BZ to me to address the LTO component. Some of those I've

Re: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote: > InsightToolkit fails to build with LTO: > > /usr/bin/ld.gold: fatal error: lto-wrapper failed > collect2: error: ld returned 1 exit status > gmake[2]: *** >

Re: Lost ELF library auto-provides since mass rebuild

On Thu, 2020-08-06 at 17:04 +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > This is in relation to this bug > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > > > The last but one build of libgphoto have auto-provides for the ELF > > libraries: > > > > libgphoto2 =

Re: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote: > On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote: > > No need to file a bug right now. Once we're past the mass rebuild we'll > > review > > everything that's opted out and see what upstream actions need to be

Re: Another possible LTO failure in guestfish (or maybe readline)

On Fri, 2020-07-31 at 11:52 +0100, Richard W.M. Jones wrote: > Here's another one: > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > libguestfs-tools-c-1.43.1-2.fc33.x86_64 > readline-8.0-5.fc33.x86_64 > $ guestfish --version > Segmentation fault (core dumped) > > (gdb) bt >

Re: postgis LTO failure

On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote: > Hi > > postgis seems another one suffering from LTO related failures. > > LTO (results in test failures): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 > > LTO disabled (tests pass): >

Re: Another possible LTO failure in guestfish (or maybe readline)

On Fri, 2020-07-31 at 18:49 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 10:55:15AM -0600, Jeff Law wrote: > > On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote: > > > * Richard W. M. Jones: > > > > > > > Here's another one: > >

Re: Fedora 32 aarch64 build failures on copr

On Fri, 2020-07-31 at 11:44 -0300, Augusto Caringi wrote: > Hi, > > On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton wrote: > > On 7/28/20 4:39 PM, Jeff Law wrote: > > > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote: > > > > On Tue, Jul

Re: ar (binutils) segfaulting in Rawhide - known bug?

On Mon, 2020-07-27 at 18:20 +0200, Nikola Forró wrote: > On Sat, 2020-07-25 at 01:11 -0600, Jeff Law wrote: > > So at a high level ar makes a call to lrealpath. That naturally goes > > through the > > PLT. The PLT stub loads the value out of the GOT and jumps to

Re: Another possible LTO failure in guestfish (or maybe readline)

On Fri, 2020-07-31 at 17:19 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 05:19:15PM +0100, Richard W.M. Jones wrote: > > (It's a bit big so I sent this to you privately) > > Ooops, at least that was what I intended to do. NP. And yes, this is definitely the linker bug. THe

Re: Another possible LTO failure in guestfish (or maybe readline)

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > Looks like it's in the buildroots now. Let me know if that doesn't fix the > > problem. > > Looks as if "ar" is segfaulting again ... >

Re: Another possible LTO failure in guestfish (or maybe readline)

On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote: > * Richard W. M. Jones: > > > Here's another one: > > > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > > libguestfs-tools-c-1.43.1-2.fc33.x86_64 > > readline-8.0-5.fc33.x86_64 > > $ guestfish --version > > Segmentation

Re: Disable LTO for now ?

On Thu, 2020-07-30 at 10:54 +0200, Vitaly Zaitsev via devel wrote: > On 29.07.2020 15:59, Jeff Law wrote: > > In general I want to have a very good indicator the issue is LTO related > > before I > > disable. THe build you referenced doesn't have any good ind

  1   2   3   >