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 > the same thing happens. Thanks, Tom. If we're blowing up memory on the builder, then we should probably disable LTO on the 32bit platforms. This is something that was expected, though I didn't trip over any in my i686 testing (I have a theory for why, but it's not terribly important). jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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 are failure to install... > > > > > > > > I'm confused if I should even fix these right now due to the various > > > > issues > > > > I've seen on the list. > > > > > > > > Is it safe to do builds right now? > > > > > > Everything is blocked on s390 builders not taking new jobs > > > at the moment ... > > > > Thats me trying to improve things so when they do take jobs they > > actually complete them correctly. > > > > You can submit builds just fine right now and they will be picked up as > > soon as I am done on the builders. > > Ok, I was wondering if there were still LTO/annobin issues going on. If that > was the case I was going to wait a bit. I would expect to see occasional LTO issues, but nothing pervasive. The annobin and binutils stuff should all be sorted out. jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
On Mon, Aug 3, 2020 at 11:45 PM Richard Shaw wrote:
>
> Sometimes you need to get into the build directory, in my case for
> OpenColorIO I use help2man to generate some of the man pages.
>
> I had to rely on the power of Google/Gmail to find Neal's response to one of
> my earlier emails to find the answer again...
>
> %{_vpath_builddir}
>
> But that begs the question, now that we have updated %cmake, and new
> %cmake_build & %cmake_install, why is it %_vpath_builddir and not
> %_cmake_builddir?
>
Because the VPATH macros are intended to be build-tool-agnostic
settings for source and build directories. %_vpath_builddir controls
where the build directory will be, and can be customized if needed
easily enough.
These macros are used by both CMake and Meson now, and the goal is to
use this infrastructure with other build tools as we're able to.
If you need to do things specifically in that directory, the macro is
a reliable way of accessing it.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Need a package review (aml)
it's done - Thanks Aleksei! On Tue, 4 Aug 2020 at 12:02, Bob Hepple wrote: > > Hi, > > The upstream author of wayvnc (a VNC server for Wayland) has split > some code out into a separate tiny package (aml) for which I'm waiting > to get a review request done, since 28th July. > > I'm blocked from packaging the new release wayvnc-0.2.0 until that one > is done and I need to get that new version out as it has a fix for the > FTBFS errors on rawhide/f33. > > Sorry if this is the wrong place to ask for this - I see people > offering review swaps but I don't think I'm authorised to do reviews. > > Anyways, if anyone can do me a review, I'll be ever grateful. It's a > very small, simple package. > > The bugzilla is here: https://bugzilla.redhat.com/show_bug.cgi?id=1861216 > > Thanks > > > Bob ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-08-04 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/04/report-389-ds-base-1.4.4.4-20200803gitb1e4f5f.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
%{_vpath_builddir} needs to be in the Cmake packaging guidelines
Sometimes you need to get into the build directory, in my case for
OpenColorIO I use help2man to generate some of the man pages.
I had to rely on the power of Google/Gmail to find Neal's response to one
of my earlier emails to find the answer again...
%{_vpath_builddir}
But that begs the question, now that we have updated %cmake, and new
%cmake_build & %cmake_install, why is it %_vpath_builddir and not
%_cmake_builddir?
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Need a package review (aml)
Hi, The upstream author of wayvnc (a VNC server for Wayland) has split some code out into a separate tiny package (aml) for which I'm waiting to get a review request done, since 28th July. I'm blocked from packaging the new release wayvnc-0.2.0 until that one is done and I need to get that new version out as it has a fix for the FTBFS errors on rawhide/f33. Sorry if this is the wrong place to ask for this - I see people offering review swaps but I don't think I'm authorised to do reviews. Anyways, if anyone can do me a review, I'll be ever grateful. It's a very small, simple package. The bugzilla is here: https://bugzilla.redhat.com/show_bug.cgi?id=1861216 Thanks Bob ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x builder improvements
On 8/3/20 6:29 PM, Kevin Fenzi wrote: ok. I did what I could with the resources we have right now to improve things on the s390x builders. I've been watching it for the last hour or so and so far 0 failures that I can attribute to s390x cache or builder infra. Hopefully that should make things more stable. Kevin - thank you for your work on this. Fingers crossed... -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1860598] perl-Encode-3.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1860598 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Encode-3.07-457.fc33 |perl-Encode-3.07-457.fc33 ||perl-Encode-3.07-457.fc32 Resolution|--- |ERRATA Last Closed||2020-08-04 01:20:45 --- Comment #5 from Fedora Update System --- FEDORA-2020-cd6601cf55 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
s390x builder improvements
ok. I did what I could with the resources we have right now to improve things on the s390x builders. 1. I noticed that we had the kvm instances oversubscribed on cpus (the host has 32, we had 42 used). So, I lowered all the kvm builders to 3 vcpus from 4. (Those are 15-24). 2. I moved the varnish package cache from 07 (a z/vm guest) to 24 (a kvm guest). I have noticed the z/vm ones (thats 01-14) seem to suffer from slowdowns or high io wait more under high load and/or over a long time. Hopefully moving that to a more stable instance will help with lots of issues people have seen with not being able to download or the like. 3. I switched the cache model on the kvm ones to unsafe, which we had already used on a number of other builders. I think the worst that can happen here is that the vm becomes corrupt if it's abruptly shutdown or killed, but thats fine, we can just spin up a new one. If a build gets messed up, koji would just restart it again on another vm, etc. 4. There was a misconfiguration in kojid where if the cache was not answering it tried directly, but it was trying the wrong url. I have corrected this, so if the primary cache is down it should fall back to trying directly on it's own. 5. I've updated and rebooted them all. They seem to behave much better after reboots and then slowly get slower over time. ;( I've been watching it for the last hour or so and so far 0 failures that I can attribute to s390x cache or builder infra. Hopefully that should make things more stable. If you see problems cropping up again, please do open an infra ticket and we can see what futher we can do. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1842274] perl-Excel-Writer-XLSX-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1842274 --- Comment #8 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Excel-Writer-XLSX-1.06-1.fc32.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=48565151 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1842274] perl-Excel-Writer-XLSX-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1842274 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Excel-Writer-XLSX-1.05 |perl-Excel-Writer-XLSX-1.06 |is available|is available --- Comment #6 from Upstream Release Monitoring --- Latest upstream release: 1.06 Current version/release in rawhide: 1.03-2.fc32 URL: http://search.cpan.org/dist/Excel-Writer-XLSX/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2860/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1842274] perl-Excel-Writer-XLSX-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1842274 --- Comment #7 from Upstream Release Monitoring --- Created attachment 1710246 --> https://bugzilla.redhat.com/attachment.cgi?id=1710246=edit [patch] Update to 1.06 (#1842274) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: What do to about massive # of FTBFS bugs?
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 are failure to install... > > > > > > I'm confused if I should even fix these right now due to the various > issues > > > I've seen on the list. > > > > > > Is it safe to do builds right now? > > > > Everything is blocked on s390 builders not taking new jobs > > at the moment ... > > Thats me trying to improve things so when they do take jobs they > actually complete them correctly. > > You can submit builds just fine right now and they will be picked up as > soon as I am done on the builders. > Ok, I was wondering if there were still LTO/annobin issues going on. If that was the case I was going to wait a bit. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Mon, Aug 3, 2020 at 7:08 PM Orion Poplawski wrote: > > On 7/7/20 12:09 PM, Neal Gompa wrote: > > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote: > >> > >> On 6/15/20 1:47 PM, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > >>> > > >>> == Upgrade/compatibility impact == > >>> Existing packages can (and most likely will) become FTBFS, but > >>> proposal owners will fix as many Fedora packages as possible. However > >>> fixing third-party packages is not possible and out of scope. > >>> Third-party packagers will need to adapt based on the recommendations > >>> noted in this Change. > >> > >> What's the plan for EPEL8/7 compatibility? > >> > > > > I need to talk to EPEL folks about how to handle this. I'm not sure > > exactly what strategy we should take here. I could override the macros > > entirely with epel-rpm-macros, which is probably the easiest way to do > > it. > > > > Any progress here? This is becoming a large pain point for me. > I implemented a hacky solution last week[1][2]. There's a bug to get RH to update CMake and pull in the proper macros into RHEL 8[3]. [1]: https://src.fedoraproject.org/rpms/epel-rpm-macros/c/3d7bea8322f8a7c5bd1b01ec16180c5b036a65a7 [2]: https://src.fedoraproject.org/rpms/epel-rpm-macros/c/e93d8e2f0d0b056349a22d5bef8a93116d469516 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1858941 -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Mon, Aug 3, 2020 at 7:08 PM Orion Poplawski wrote: > > On 7/7/20 12:09 PM, Neal Gompa wrote: > > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote: > >> > >> On 6/15/20 1:47 PM, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > >>> > > >>> == Upgrade/compatibility impact == > >>> Existing packages can (and most likely will) become FTBFS, but > >>> proposal owners will fix as many Fedora packages as possible. However > >>> fixing third-party packages is not possible and out of scope. > >>> Third-party packagers will need to adapt based on the recommendations > >>> noted in this Change. > >> > >> What's the plan for EPEL8/7 compatibility? > >> > > > > I need to talk to EPEL folks about how to handle this. I'm not sure > > exactly what strategy we should take here. I could override the macros > > entirely with epel-rpm-macros, which is probably the easiest way to do > > it. > > > > Any progress here? This is becoming a large pain point for me. > I implemented a hacky solution last week[1][2]. There's a bug to get RH to update CMake and pull in the proper macros into RHEL 8[3]. [1]: https://src.fedoraproject.org/rpms/epel-rpm-macros/c/3d7bea8322f8a7c5bd1b01ec16180c5b036a65a7 [2]: https://src.fedoraproject.org/rpms/epel-rpm-macros/c/e93d8e2f0d0b056349a22d5bef8a93116d469516 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1858941 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On 7/7/20 12:09 PM, Neal Gompa wrote: > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote: >> >> On 6/15/20 1:47 PM, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds >>> >>> == Upgrade/compatibility impact == >>> Existing packages can (and most likely will) become FTBFS, but >>> proposal owners will fix as many Fedora packages as possible. However >>> fixing third-party packages is not possible and out of scope. >>> Third-party packagers will need to adapt based on the recommendations >>> noted in this Change. >> >> What's the plan for EPEL8/7 compatibility? >> > > I need to talk to EPEL folks about how to handle this. I'm not sure > exactly what strategy we should take here. I could override the macros > entirely with epel-rpm-macros, which is probably the easiest way to do > it. > Any progress here? This is becoming a large pain point for me. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On 7/7/20 12:09 PM, Neal Gompa wrote: > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote: >> >> On 6/15/20 1:47 PM, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds >>> >>> == Upgrade/compatibility impact == >>> Existing packages can (and most likely will) become FTBFS, but >>> proposal owners will fix as many Fedora packages as possible. However >>> fixing third-party packages is not possible and out of scope. >>> Third-party packagers will need to adapt based on the recommendations >>> noted in this Change. >> >> What's the plan for EPEL8/7 compatibility? >> > > I need to talk to EPEL folks about how to handle this. I'm not sure > exactly what strategy we should take here. I could override the macros > entirely with epel-rpm-macros, which is probably the easiest way to do > it. > Any progress here? This is becoming a large pain point for me. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 7:04 PM Nicolas Chauvet wrote: > > Le lun. 3 août 2020 à 23:18, Neal Gompa a écrit : > > > > On Mon, Aug 3, 2020 at 3:59 PM Nicolas Chauvet wrote: > > > > > > Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > > > > > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > > > wrote: > > > > > > > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes > > > > > wrote: > > > > > > > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > > > > > From a very cursory scan (not at all scientific), > > > > > some percentage are the cmake macro changes. > > > > > > > > CMake macros are documented in the packaging guidelines: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > > > Here's an example of how to adjust it: > > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > > > Can you show an example that work across all maintained releases ? > > > (aka inclusing epel7). > > > > > > > I don't have a package off-hand that is maintained across EPEL7, > > EPEL8, and Fedora, but the macros are all implemented, provided you > > are using cmake3 for EPEL7. > > > > If you don't care whether it's in-source or out-of-source build, then > > you only need to concern yourself with %cmake, %cmake_build, and > > %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). > > The problem is that I care and usually use out of source build > (manually creating build dir and etc), but having to define > __cmake_in_source_build 1 looks miss-named if already using a > dedicated build sub-directory. > If I'm using %cmake macros without a build sub-directory, then I'm > losing the source tree versus build tree there. This is possible, but > a little backward. > > Or did I miss something ? In Fedora 33 and newer, __cmake_in_source_build is *not defined*, so it defaults to out of source builds. In Fedora 32 and older, including EPEL7 and EPEL8, it *is defined*, so it defaults to in-source builds. Doing "%undefine __cmake_in_source_build" will make the F33+ behavior apply on older Fedora and EPEL8. You'll additionally want to do "%undefine __cmake3_in_source_build" to make this work with EPEL7's cmake3 package. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
Hi Fabio, On Mon, 2020-08-03 at 19:29 +0200, Fabio Valentini wrote: > On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede > wrote: > > Hi, > > > > On 8/3/20 5:53 PM, Kevin Fenzi wrote: > > > On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: > > > > Hi All, > > > > > > > > > > > > I just noticed that a lot my packages got a FTBFS because of > > > > failing to build on s390x. The first set of rebuilds failed > > > > with: > > > > > > > > "BuildrootError: Requested repo (1785390) is DELETED" > > > > > > > > The second set of rebuilds failed with: > > > > > > > > "rpm.error: error reading package header" > > > > > > > > errors. > > > > > > > > The last error was also seen quite a bit during the F32 mass > > > > rebuid ... > > > > > > I'm sorry this is happening, and it makes me very grumpy too. > > > > > > I have some thoughts on improvements we can make to help try and > > > make > > > this better, but I was under the impression it was mostly working > > > ok for > > > the second pass. > > > > > > We went from 4162 to 2833 failures, so it had to have been > > > working at > > > least sometime there? > > > > It seems for me the s390x failures on the second build are limited > > to package names starting with A-Z and "aa*" - "an*" . > > > > Any chance we can get a third mass rebuild for package-names > > starting > > with A-Z and "a*" ? > > > > Or maybe all those where the only failing platform is on s390x ? > > > > (no idea how easy it is to script any of this) > > I am already resubmitting all builds that failed in koji but that > currently pass locally in mock with "--enablerepo local". > So far this has reduced the number of FTBFS packages by almost 100, > and the script is still running. > This should take care of all packages that only failed due to infra > issues. > Could this be why the queue to get an s390x build seems longer than usual today, and is there an ETA for when this script will finish? I have some builds for Eternal Terminal (et) that have all completed on all platforms (even armv7hl) but are still all queued on s390x https://koji.fedoraproject.org/koji/packageinfo?packageID=27370 Thanks, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What do to about massive # of FTBFS bugs?
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 are failure to install... > > > > I'm confused if I should even fix these right now due to the various issues > > I've seen on the list. > > > > Is it safe to do builds right now? > > Everything is blocked on s390 builders not taking new jobs > at the moment ... Thats me trying to improve things so when they do take jobs they actually complete them correctly. You can submit builds just fine right now and they will be picked up as soon as I am done on the builders. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
Le lun. 3 août 2020 à 23:18, Neal Gompa a écrit : > > On Mon, Aug 3, 2020 at 3:59 PM Nicolas Chauvet wrote: > > > > Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > > > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > > wrote: > > > > > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes > > > > wrote: > > > > > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > > > From a very cursory scan (not at all scientific), > > > > some percentage are the cmake macro changes. > > > > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > Here's an example of how to adjust it: > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > Can you show an example that work across all maintained releases ? > > (aka inclusing epel7). > > > > I don't have a package off-hand that is maintained across EPEL7, > EPEL8, and Fedora, but the macros are all implemented, provided you > are using cmake3 for EPEL7. > > If you don't care whether it's in-source or out-of-source build, then > you only need to concern yourself with %cmake, %cmake_build, and > %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). The problem is that I care and usually use out of source build (manually creating build dir and etc), but having to define __cmake_in_source_build 1 looks miss-named if already using a dedicated build sub-directory. If I'm using %cmake macros without a build sub-directory, then I'm losing the source tree versus build tree there. This is possible, but a little backward. Or did I miss something ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FTBFS filed incorrectly and linked to the wrong build
https://bugzilla.redhat.com/show_bug.cgi?id=1865666 links to the latest build, but that's the ELN build (which failed): https://koji.fedoraproject.org/koji/packageinfo?packageID=8391 The latest F33 build did not fail. I believe this bug was filed incorrectly and perhaps the script that files these bugs need updating. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 10:32 AM Jaroslav Skarvada wrote: > > > > - Original Message - > > On 8/3/2020 9:42 AM, Neal Gompa wrote: > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > > wrote: > > >> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes > > >> wrote: > > >> > > >>> Most of those are the libcroco->gettext breakage, no? > > >> From a very cursory scan (not at all scientific), > > >> some percentage are the cmake macro changes. > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > Here's an example of how to adjust it: > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > Indeed, using this example appears to have fixed at least one of my > > packages. > > > > > > Erich Eickmeyer > > Fedora Jam Maintainer > > > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > Most of my FTBFSs are in form: > BuildrootError: Requested repo (1785390) is DELETED > > Wtf? > > E.g.: > https://bugzilla.redhat.com/show_bug.cgi?id=1863168 > https://bugzilla.redhat.com/show_bug.cgi?id=1863196 > https://bugzilla.redhat.com/show_bug.cgi?id=1863197 > https://bugzilla.redhat.com/show_bug.cgi?id=1863273 > These are what I call "transient s390x errors", even though it's not always s390x. I've had a couple, and they just required a rebuild with no changes. I have no idea of the technical reason for the error, just that I was able to successfully rebuild. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied
On Mon, Aug 03, 2020 at 10:42:01PM +0100, Richard W.M. Jones wrote:
> I can't reproduce this locally but it happens in Koji reliably enough:
>
> + /usr/lib/rpm/brp-strip /usr/bin/strip
> /usr/bin/strip: unable to copy file
> '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake';
> reason: Permission denied
> error: Bad exit status from /var/tmp/rpm-tmp.5A3ApT (%install)
After updating to more Rawhide I _am_ able to reproduce it. It seems
to be caused because the binary is installed 0555:
-r-xr-xr-x. 1 rjones rjones 8042912 Aug 3 22:41
/home/rjones/rpmbuild/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake
However nothing has changed in this package for years (last rebase was
in Nov 2017) but apparently strip didn't have a problem before now.
I was able to work around it by adding an explicit
%install
make install \
INSTALL_ROOT=$RPM_BUILD_ROOT
+chmod 0755 $RPM_BUILD_ROOT%{_bindir}/omake
so I guess that "fixes" it, but why?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
/usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied
I can't reproduce this locally but it happens in Koji reliably enough: + /usr/lib/rpm/brp-strip /usr/bin/strip /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied error: Bad exit status from /var/tmp/rpm-tmp.5A3ApT (%install) Any ideas? https://koji.fedoraproject.org/koji/taskinfo?taskID=48555021 https://kojipkgs.fedoraproject.org//work/tasks/5021/48555021/build.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On 03/08/2020 22:32, Alexander Ploumistos wrote: Thanks, going for %define felt like trying to postpone adjusting to the new guidelines. What about any "make target1 target2" between the %cmake* macros? Do they remain as they are? A "make target" can be replaced with "%cmake_build --target target". Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Tue, Aug 4, 2020 at 12:20 AM Neal Gompa wrote: > > On Mon, Aug 3, 2020 at 4:21 PM Alexander Ploumistos > wrote: > > > > Hi Neal, > > > > On Mon, Aug 3, 2020 at 8:37 PM Neal Gompa wrote: > > > > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > So if a spec file is supposed to work on F31 to F33, "%undefine > > __cmake_in_source_build" is all that's required? > > The %undefine will make Fedora 31 and Fedora 32 CMake behave the same > way as Fedora 33 CMake. > > After that, you can switch %make_build and %make_install macros to > %cmake_build and %cmake_install. > > Alternatively, if you %define __cmake_in_source_build 1, this will > make Fedora 33 CMake behave the same way as Fedora 31 and Fedora 32 > CMake, and then the old command flow works as before. > > I recommend using the %undefine behavior and switching to the new > macros, but you can make your own judgement. Thanks, going for %define felt like trying to postpone adjusting to the new guidelines. What about any "make target1 target2" between the %cmake* macros? Do they remain as they are? For the past couple of hours I've been testing every possible combination of the macros while trying to fix liborigin (which has a completely flat tree, save for its documentation) and no matter what I choose, I always end up with a directory or file being inaccessible to cmake. It is driving me crazy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What do to about massive # of FTBFS bugs?
On Mon, Aug 03, 2020 at 04:04:57PM -0500, Richard Shaw wrote: > I'm up to 21 and climbing. Technically two are failure to install... > > I'm confused if I should even fix these right now due to the various issues > I've seen on the list. > > Is it safe to do builds right now? Everything is blocked on s390 builders not taking new jobs at the moment ... Rich. > Most of these are due to the cmake change. I generally agree with it > although I was already doing out of source builds for all of my projects, > but this has created a lot of work for me. Even if I change it back to the > old behavior, I still have to touch every spec file of every affected > package. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning nanomsg and 3 other packages
I created the nanomsg package to support mozilla-iot-gateway. I have orphaned mozilla-iot-gateway because I have not been able to give it the attention it needs. I have decided to orphan nanomsg, and the other supporting packages while I am at it. Below are the packages I am orphaning: nanomsg python-nnpy mozilla-iot-gateway-addon-node mozilla-iot-gateway-addon-python Outside of themselves, there is nothing that depends on these packages. Troy Dawson ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Planned Outage - koji.fedoraproject.org - 2020-08-05 21:00 UTC
Planned Outage - koji.fedoraproject.org - 2020-08-05 21:00 UTC There will be an outage starting at 2020-08-05 21:00 UTC which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-08-05 21:00UTC' Reason for outage: We will be upgrading koji to the recent 1.22.0 upstream release, updating builders to the latest kernel and updates, and doing some database vacuuming. Affected Services: koji.fedoraproject.org - the fedoraproject build system Ticket Link: https://pagure.io/fedora-infrastructure/issue/9194 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
What do to about massive # of FTBFS bugs?
I'm up to 21 and climbing. Technically two are failure to install... I'm confused if I should even fix these right now due to the various issues I've seen on the list. Is it safe to do builds right now? Most of these are due to the cmake change. I generally agree with it although I was already doing out of source builds for all of my projects, but this has created a lot of work for me. Even if I change it back to the old behavior, I still have to touch every spec file of every affected package. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1865207] perl-IO-Async: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865207 --- Comment #2 from Fedora Release Engineering --- Created attachment 1708808 --> https://bugzilla.redhat.com/attachment.cgi?id=1708808=edit root.log file root.log too big, will only attach last 32768 bytes -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1865208] New: perl-Math-ConvexHull-MonotoneChain: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865208 Bug ID: 1865208 Summary: perl-Math-ConvexHull-MonotoneChain: FTBFS in Fedora rawhide/f33 Product: Fedora Version: rawhide Status: NEW Component: perl-Math-ConvexHull-MonotoneChain Assignee: jples...@redhat.com Reporter: rel...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mhron...@redhat.com, perl-devel@lists.fedoraproject.org Blocks: 1803234 (F33FTBFS) Target Milestone: --- Classification: Fedora perl-Math-ConvexHull-MonotoneChain failed to build from source in Fedora rawhide/f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=48349337 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Please fix perl-Math-ConvexHull-MonotoneChain at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, perl-Math-ConvexHull-MonotoneChain will be orphaned. Before branching of Fedora 34, perl-Math-ConvexHull-MonotoneChain will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1803234 [Bug 1803234] (F33FTBFS) - Fedora 33 FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1865207] New: perl-IO-Async: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865207 Bug ID: 1865207 Summary: perl-IO-Async: FTBFS in Fedora rawhide/f33 Product: Fedora Version: rawhide Status: NEW Component: perl-IO-Async Assignee: emman...@seyman.fr Reporter: rel...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, kwiz...@gmail.com, perl-devel@lists.fedoraproject.org Blocks: 1803234 (F33FTBFS) Target Milestone: --- Classification: Fedora perl-IO-Async failed to build from source in Fedora rawhide/f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=48349322 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Please fix perl-IO-Async at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, perl-IO-Async will be orphaned. Before branching of Fedora 34, perl-IO-Async will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1803234 [Bug 1803234] (F33FTBFS) - Fedora 33 FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1865207] perl-IO-Async: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865207 --- Comment #3 from Fedora Release Engineering --- Created attachment 1708809 --> https://bugzilla.redhat.com/attachment.cgi?id=1708809=edit state.log -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1865207] perl-IO-Async: FTBFS in Fedora rawhide/f33
https://bugzilla.redhat.com/show_bug.cgi?id=1865207 --- Comment #1 from Fedora Release Engineering --- Created attachment 1708807 --> https://bugzilla.redhat.com/attachment.cgi?id=1708807=edit build.log -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, 2020-08-03 at 15:39 -0400, Neal Gompa wrote: > On Mon, Aug 3, 2020 at 3:32 PM Peter Robinson > wrote: > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > > > From a very cursory scan (not at all scientific), > > > > some percentage are the cmake macro changes. > > > > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > Here's an example of how to adjust it: > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > The changes should have landed _BEFORE_ mass rebuild, if the change > > owner didn't have the permissions they should have done PRs for all > > the packages rather than having zero direct comms to affected > > package > > owners and having them find out of a change needed post mass > > rebuild > > when they get generic FTBFS bugs. > > > > Now people have even more work to do for the unexpected mess :-( > > For what it's worth, I've spent almost every single weekend > alternating between this change and the Btrfs one. I wound up also > having to implement the EPEL7 and EPEL8 macros (that were out of > scope > of the change, but I did it anyway because people complained). Igor > and myself had been working on doing the updates each weekend we > could, however my internet connectivity to Dist-Git and Koji had been > troublesome for the past few weekends, and that has made working on > it > hard. Thanks for doing the EPEL macros! That was one of the major concerns with the initial change proposal, if I recall the discussion. I'm fixing one of my package now (et) since there's an update for it last week that I want to push out anyway, and being able to use the same macros on EPEL8 is really nice. Regards, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 4:22 PM Miro Hrončok wrote: > > On 03. 08. 20 22:19, Neal Gompa wrote: > > If you don't care whether it's in-source or out-of-source build, then > > you only need to concern yourself with %cmake, %cmake_build, and > > %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). > > Neal, can I safely use this on EPEL7 and Fedora? > > %undefine __cmake_in_source_build > %cmake3 > %cmake3_build > %cmake3_install > > ? You'll need one more for EPEL7: %undefine __cmake3_in_source_build But otherwise, yes, provided you "BuildRequires: cmake3" for EPEL7. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 4:21 PM Alexander Ploumistos wrote: > > Hi Neal, > > On Mon, Aug 3, 2020 at 8:37 PM Neal Gompa wrote: > > > > CMake macros are documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > So if a spec file is supposed to work on F31 to F33, "%undefine > __cmake_in_source_build" is all that's required? The %undefine will make Fedora 31 and Fedora 32 CMake behave the same way as Fedora 33 CMake. After that, you can switch %make_build and %make_install macros to %cmake_build and %cmake_install. Alternatively, if you %define __cmake_in_source_build 1, this will make Fedora 33 CMake behave the same way as Fedora 31 and Fedora 32 CMake, and then the old command flow works as before. I recommend using the %undefine behavior and switching to the new macros, but you can make your own judgement. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On 03. 08. 20 22:19, Neal Gompa wrote: If you don't care whether it's in-source or out-of-source build, then you only need to concern yourself with %cmake, %cmake_build, and %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). Neal, can I safely use this on EPEL7 and Fedora? %undefine __cmake_in_source_build %cmake3 %cmake3_build %cmake3_install ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 3:59 PM Nicolas Chauvet wrote: > > Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > wrote: > > > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > > > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > From a very cursory scan (not at all scientific), > > > some percentage are the cmake macro changes. > > > > CMake macros are documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > Here's an example of how to adjust it: > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > Can you show an example that work across all maintained releases ? > (aka inclusing epel7). > I don't have a package off-hand that is maintained across EPEL7, EPEL8, and Fedora, but the macros are all implemented, provided you are using cmake3 for EPEL7. If you don't care whether it's in-source or out-of-source build, then you only need to concern yourself with %cmake, %cmake_build, and %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Arch-specific LTO problems
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 the same thing happens. Thanks, Tom. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1864879] New: perl-CGI-Compile-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1864879 Bug ID: 1864879 Summary: perl-CGI-Compile-0.25 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CGI-Compile Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.25 Current version/release in rawhide: 0.24-3.fc33 URL: http://search.cpan.org/dist/CGI-Compile Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7854/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 7:32 PM Peter Robinson wrote: > The changes should have landed _BEFORE_ mass rebuild, if the change > owner didn't have the permissions they should have done PRs for all > the packages rather than having zero direct comms to affected package > owners and having them find out of a change needed post mass rebuild > when they get generic FTBFS bugs. > > Now people have even more work to do for the unexpected mess :-( Since the changes did not land before the mass rebuild (which I agree should have been the requirement), I would presume that a responsible change owner, who agreed in the proposal to make the required changes to packages, would also take ownership of each and every related FTBFS bugzilla entry and mark it ASSIGNED (to themselves). They (knowingly) broke it, they own it. And the best way to make the packagers aware the the change owners are taking their responsibilities seriously is update the FTBFS bugzillas. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 3:32 PM Peter Robinson wrote: > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > From a very cursory scan (not at all scientific), > > > some percentage are the cmake macro changes. > > > > CMake macros are documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > Here's an example of how to adjust it: > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > The changes should have landed _BEFORE_ mass rebuild, if the change > owner didn't have the permissions they should have done PRs for all > the packages rather than having zero direct comms to affected package > owners and having them find out of a change needed post mass rebuild > when they get generic FTBFS bugs. > > Now people have even more work to do for the unexpected mess :-( For what it's worth, I've spent almost every single weekend alternating between this change and the Btrfs one. I wound up also having to implement the EPEL7 and EPEL8 macros (that were out of scope of the change, but I did it anyway because people complained). Igor and myself had been working on doing the updates each weekend we could, however my internet connectivity to Dist-Git and Koji had been troublesome for the past few weekends, and that has made working on it hard. Even with all that, we did already fix somewhere close to 500 of the 1469 packages that required updates. Do not insinuate that we are not trying! The sheer number of packages to fix, combined with everybody using CMake slightly differently, has made this not as straightforward as I wanted it to be. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1852232] F33FailsToInstall: perl-perl5i
https://bugzilla.redhat.com/show_bug.cgi?id=1852232 Igor Raits changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|p...@city-fan.org |extras-orphan@fedoraproject ||.org --- Comment #2 from Igor Raits --- This package has been orphaned. You can pick it up at https://src.fedoraproject.org/rpms/perl-perl5i by clicking button "Take". If nobody picks it up, it will be retired and removed from a distribution. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On 03. 08. 20 21:02, Nicolas Chauvet wrote: Can you show an example that work across all maintained releases ? (aka inclusing epel7). https://src.fedoraproject.org/rpms/lib3mf/c/69ac5cb696456d7f5478f47bf2bcf234ab77ba56?branch=master -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1864519] New: F33FailsToInstall: perl-Alien-pkgconf
https://bugzilla.redhat.com/show_bug.cgi?id=1864519 Bug ID: 1864519 Summary: F33FailsToInstall: perl-Alien-pkgconf Product: Fedora Version: rawhide Status: NEW Component: perl-Alien-pkgconf Assignee: ppi...@redhat.com Reporter: igor.ra...@gmail.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 1803235 (F33FailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (ignatenkobr...@fedoraproject.org). Your package (perl-Alien-pkgconf) Fails To Install in Fedora 33: can't install perl-Alien-pkgconf: - nothing provides libpkgconf-devel(x86-64) = 1.7.0 needed by perl-Alien-pkgconf-0.17-4.fc33.x86_64 If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1803235 [Bug 1803235] (F33FailsToInstall) - Fedora 33 Fails To install Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1864520] New: F33FailsToInstall: perl-re-engine-PCRE2
https://bugzilla.redhat.com/show_bug.cgi?id=1864520 Bug ID: 1864520 Summary: F33FailsToInstall: perl-re-engine-PCRE2 Product: Fedora Version: rawhide Status: NEW Component: perl-re-engine-PCRE2 Assignee: ppi...@redhat.com Reporter: igor.ra...@gmail.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 1803235 (F33FailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (ignatenkobr...@fedoraproject.org). Your package (perl-re-engine-PCRE2) Fails To Install in Fedora 33: can't install perl-re-engine-PCRE2: - nothing provides perl(:MODULE_COMPAT_5.30.1) needed by perl-re-engine-PCRE2-0.16-4.fc32.x86_64 - nothing provides libperl.so.5.30()(64bit) needed by perl-re-engine-PCRE2-0.16-4.fc32.x86_64 If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1803235 [Bug 1803235] (F33FailsToInstall) - Fedora 33 Fails To install Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1864486] New: F33FailsToInstall: fpdns
https://bugzilla.redhat.com/show_bug.cgi?id=1864486 Bug ID: 1864486 Summary: F33FailsToInstall: fpdns Product: Fedora Version: rawhide Status: NEW Component: fpdns Assignee: mmcki...@umich.edu Reporter: igor.ra...@gmail.com QA Contact: extras...@fedoraproject.org CC: mmcki...@umich.edu, perl-devel@lists.fedoraproject.org Blocks: 1803235 (F33FailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (ignatenkobr...@fedoraproject.org). Your package (fpdns) Fails To Install in Fedora 33: can't install fpdns: - nothing provides perl(:MODULE_COMPAT_5.30.0) needed by fpdns-0.10.0-20190131.fc31.2.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1803235 [Bug 1803235] (F33FailsToInstall) - Fedora 33 Fails To install Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
Hi Neal, On Mon, Aug 3, 2020 at 8:37 PM Neal Gompa wrote: > > CMake macros are documented in the packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ So if a spec file is supposed to work on F31 to F33, "%undefine __cmake_in_source_build" is all that's required? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > wrote: > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > > > > > Most of those are the libcroco->gettext breakage, no? > > > > From a very cursory scan (not at all scientific), > > some percentage are the cmake macro changes. > > CMake macros are documented in the packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > Here's an example of how to adjust it: > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f Can you show an example that work across all maintained releases ? (aka inclusing epel7). Thanks in advance. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning fst
Hello all, fst is a VST bridge for Windows VST plugins for wine only for i686 and hasn't seen a commit since 2011-01-31[1]. With the F33 mass rebuild, the day finally has come where fst is FTBFS due to bit rot. Since there are newer solutions now, such as Carla, that do a good job of bridging, I don't see any reason for this package to be maintained anymore. Honestly, it should probably be retired. [1] https://repo.or.cz/w/fst.git Erich Eickmeyer Fedora Jam Maintainer pEpkey.asc Description: application/pgp-keys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
Hi, On 8/3/20 7:29 PM, Fabio Valentini wrote: On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote: Hi, On 8/3/20 5:53 PM, Kevin Fenzi wrote: On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: Hi All, I just noticed that a lot my packages got a FTBFS because of failing to build on s390x. The first set of rebuilds failed with: "BuildrootError: Requested repo (1785390) is DELETED" The second set of rebuilds failed with: "rpm.error: error reading package header" errors. The last error was also seen quite a bit during the F32 mass rebuid ... I'm sorry this is happening, and it makes me very grumpy too. I have some thoughts on improvements we can make to help try and make this better, but I was under the impression it was mostly working ok for the second pass. We went from 4162 to 2833 failures, so it had to have been working at least sometime there? It seems for me the s390x failures on the second build are limited to package names starting with A-Z and "aa*" - "an*" . Any chance we can get a third mass rebuild for package-names starting with A-Z and "a*" ? Or maybe all those where the only failing platform is on s390x ? (no idea how easy it is to script any of this) I am already resubmitting all builds that failed in koji but that currently pass locally in mock with "--enablerepo local". So far this has reduced the number of FTBFS packages by almost 100, and the script is still running. Great, thank you. I will stop resubmitting these myself then (I just resubmitted a first batch of 5 pkgs). Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Respinning rawhide images every filesystem update?
Hey list, How do Fedora rawhide images get respun? Every time filesystem updates, it causes `dnf update` to fail in a podman container because filesystem can't be updated in a container. We either need to make sure filesystem updates cause rawhide containers to be rebuilt, or figure out how to ship a container-friendly filesystem package. See: https://bugzilla.redhat.com/show_bug.cgi?id=1548403 https://bugzilla.redhat.com/show_bug.cgi?id=1708249 And I'm sure many other discussions. - Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
> > > Most of those are the libcroco->gettext breakage, no? > > > > From a very cursory scan (not at all scientific), > > some percentage are the cmake macro changes. > > CMake macros are documented in the packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > Here's an example of how to adjust it: > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f The changes should have landed _BEFORE_ mass rebuild, if the change owner didn't have the permissions they should have done PRs for all the packages rather than having zero direct comms to affected package owners and having them find out of a change needed post mass rebuild when they get generic FTBFS bugs. Now people have even more work to do for the unexpected mess :-( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
I finally ran into another issue and used the vim faq. It was ":set cindent" that was causing the crazy indentation in spec file %changelogs. I still consider this a bug as the file doesn't even end in c, cpp, cxx, c++ etc. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
- Original Message - > On Mon, Aug 03, 2020 at 01:30:56PM -0400, Jaroslav Skarvada wrote: > > > > Most of my FTBFSs are in form: > > BuildrootError: Requested repo (1785390) is DELETED > > > > Wtf? > > > > E.g.: > > https://bugzilla.redhat.com/show_bug.cgi?id=1863168 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863196 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863197 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863273 > > > > Jaroslav > > This error is from the very beginning of the mass rebuild (more than a > week ago now). I had kojira deleting repos that were expired for more > than 5min. But of course the f33 repo regenerates all the time so it was > not sufficent for the builds when they got around to building, that repo > was gone. > > However, the fails to build from source bug filing script is mistakenly > adding the first rebuild failure, instead of the second one. ;( > > decathorpes script should resubmit these if they are caused by transient > s390x issues. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > It seems it is not just s390x, but also armv7hl sometimes, maybe more arches, I hadn't time to go through all of them Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 03, 2020 at 01:30:56PM -0400, Jaroslav Skarvada wrote: > > Most of my FTBFSs are in form: > BuildrootError: Requested repo (1785390) is DELETED > > Wtf? > > E.g.: > https://bugzilla.redhat.com/show_bug.cgi?id=1863168 > https://bugzilla.redhat.com/show_bug.cgi?id=1863196 > https://bugzilla.redhat.com/show_bug.cgi?id=1863197 > https://bugzilla.redhat.com/show_bug.cgi?id=1863273 > > Jaroslav This error is from the very beginning of the mass rebuild (more than a week ago now). I had kojira deleting repos that were expired for more than 5min. But of course the f33 repo regenerates all the time so it was not sufficent for the builds when they got around to building, that repo was gone. However, the fails to build from source bug filing script is mistakenly adding the first rebuild failure, instead of the second one. ;( decathorpes script should resubmit these if they are caused by transient s390x issues. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Did check 0.15.x in rawhide break packages' test suites?
On Sun, Aug 2, 2020 at 11:27 AM Jerry James wrote: > You can point the finger of blame at least partly at me for this. > Version 0.15.0 of check introduced the use of > __attribute__((printf)) to check the arguments to some of the > calls. However, upstream didn't do it right, with the result that gcc > warned on pretty much every use of the check macros. I submitted a > patch upstream to fix that, which upstream applied and included in > version 0.15.1. That patch, however, broke other things, such as the > ability to call fail_if() with only one argument. > > I've been working on another patch to fix *that*. It's not too hard > to do for gcc, which makes __VA_OPT__ available to the C compiler, but > not so easy for the Microsoft compiler. I'll attach what I have so > far. Comments or suggestions on how to make it better are much > appreciated. I would like to submit something upstream by tomorrow. > If upstream likes the idea, I'll do another build of check that > includes the patch. Upstream went with a simpler fix. It seems that the fail_* macros are deprecated anyway (your upstreams should switch to using ck_assert* calls instead), so they just added an extra NULL argument to the end. That will make GCC complain about too many arguments for the format string in the case that more than one argument is passed, but will fix the breakage when only one argument is passed. I will add upstream's commit to the our package and rebuild. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Arch-specific LTO problems
On 8/3/20 1:28 PM, Jerry James wrote: I've been going through mass rebuild failures. Several of these look like they might be LTO problems that only manifest on one architecture. libfplll: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575475 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status linbox: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575610 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status mathicgb: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575673 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status primecount: ppc64le https://koji.fedoraproject.org/koji/buildinfo?buildID=1576863 Bad assembly generated on ppc64le only when LTO is active. See https://bugzilla.redhat.com/show_bug.cgi?id=1862181 These are all likely caused by the linker running out of memory and getting killed by the OOM killer. -Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
- Original Message - > On 8/3/2020 9:42 AM, Neal Gompa wrote: > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > wrote: > >> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > >> > >>> Most of those are the libcroco->gettext breakage, no? > >> From a very cursory scan (not at all scientific), > >> some percentage are the cmake macro changes. > > CMake macros are documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > Here's an example of how to adjust it: > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > Indeed, using this example appears to have fixed at least one of my > packages. > > > Erich Eickmeyer > Fedora Jam Maintainer > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Most of my FTBFSs are in form: BuildrootError: Requested repo (1785390) is DELETED Wtf? E.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1863168 https://bugzilla.redhat.com/show_bug.cgi?id=1863196 https://bugzilla.redhat.com/show_bug.cgi?id=1863197 https://bugzilla.redhat.com/show_bug.cgi?id=1863273 Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote: > > Hi, > > On 8/3/20 5:53 PM, Kevin Fenzi wrote: > > On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: > >> Hi All, > >> > >> > >> I just noticed that a lot my packages got a FTBFS because of > >> failing to build on s390x. The first set of rebuilds failed with: > >> > >> "BuildrootError: Requested repo (1785390) is DELETED" > >> > >> The second set of rebuilds failed with: > >> > >> "rpm.error: error reading package header" > >> > >> errors. > >> > >> The last error was also seen quite a bit during the F32 mass rebuid ... > > > > I'm sorry this is happening, and it makes me very grumpy too. > > > > I have some thoughts on improvements we can make to help try and make > > this better, but I was under the impression it was mostly working ok for > > the second pass. > > > > We went from 4162 to 2833 failures, so it had to have been working at > > least sometime there? > > It seems for me the s390x failures on the second build are limited > to package names starting with A-Z and "aa*" - "an*" . > > Any chance we can get a third mass rebuild for package-names starting > with A-Z and "a*" ? > > Or maybe all those where the only failing platform is on s390x ? > > (no idea how easy it is to script any of this) I am already resubmitting all builds that failed in koji but that currently pass locally in mock with "--enablerepo local". So far this has reduced the number of FTBFS packages by almost 100, and the script is still running. This should take care of all packages that only failed due to infra issues. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Arch-specific LTO problems
I've been going through mass rebuild failures. Several of these look like they might be LTO problems that only manifest on one architecture. libfplll: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575475 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status linbox: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575610 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status mathicgb: arm https://koji.fedoraproject.org/koji/buildinfo?buildID=1575673 Link step fails: /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status primecount: ppc64le https://koji.fedoraproject.org/koji/buildinfo?buildID=1576863 Bad assembly generated on ppc64le only when LTO is active. See https://bugzilla.redhat.com/show_bug.cgi?id=1862181 -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ghc-cryptonite LTO failure on s390x
Hi Elliot, thanks for the heads up: On Mon, Aug 3, 2020 at 8:12 AM Elliott Sales de Andrade < quantum.anal...@gmail.com> wrote: > The build for ghc-cryptonite failed in the mass rebuild [1] and a > later rebuild by me [2], but only on s390x. The failure appears to be > LTO related. This doesn't appear to affect many other Haskell > packages. (I've found one seemingly-related failure in > ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard > macros that should pass consistent flags, etc., so I'm not sure what > more information I can provide. > > What happens is that ld.gold warns about mixed LTO/non-LTO: > Yeah this seems to be affecting profiling libraries (ghc-*-prof.s390x). [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236 I opened https://bugzilla.redhat.com/show_bug.cgi?id=1863601 using the output from this build. For now I am going to workaround this by disabling LTO for s390x Haskell packages in ghc-rpm-macros. I think when we move to ghc-8.10 for F34 we can hopefully switch s390x to llvm10 which should make this problem go away. Thanks, Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review swaps
On Mon, Aug 3, 2020 at 9:16 AM Qiyu Yan wrote: > This works, but due to the mass rebuild and the mirrors available for > me didn't get synced. Preparing the buildroot will take unreasonable > long time here, maybe letting others interested to continue. Sure, thank you for the antic review, Qiyu. I appreciate it. The antic package has been built in Rawhide, so that should unblock the e-antic review for anyone interested in a swap for that. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] RIP: Thomas Gilliard (satellit)
On Sun, Aug 02, 2020 at 03:48:41PM -0700, Adam Williamson wrote: > Hi, folks. I'm sad to report that Thomas Gilliard (satellit), who was a > valued member of the QA team for many years, passed away last week. His > wife contacted me with the news. Thomas was a regular and reassuring > presence at QA and blocker review meetings and ran many thousands of > tests since he first joined the team in 2009. He was particularly > dedicated to testing our Sugar builds. We'll miss him. Sorry to hear the bad news, thanks for letting everyone know. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On 8/3/2020 9:42 AM, Neal Gompa wrote: > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > wrote: >> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: >> >>> Most of those are the libcroco->gettext breakage, no? >> From a very cursory scan (not at all scientific), >> some percentage are the cmake macro changes. > CMake macros are documented in the packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > Here's an example of how to adjust it: > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f Indeed, using this example appears to have fixed at least one of my packages. Erich Eickmeyer Fedora Jam Maintainer pEpkey.asc Description: application/pgp-keys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On 8/3/2020 9:38 AM, Gary Buhrmaster wrote: > On Mon, Aug 3, 2020 at 4:24 PM Peter Robinson wrote: > >> There's also a bunch of CMake related ones and I'm not even sure how >> to deal with that. > The proposal owners stated that: > > Existing packages can (and most likely will) become FTBFS, but > proposal owners will fix as many Fedora packages as possible. > > I interpret that as the proposal owners are about to push > a bunch of fixes RSN and rebuild the impacted packages. I certainly hope so. All of my FTBFS packages are due to the cmake issue. This is not good, and I have zero knowledge of how to fix them. - Erich Eickmeyer Fedora Jam Maintainer pEpkey.asc Description: application/pgp-keys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automatic logout due to quota
Steve Grubb writes: > Hello, > > On Saturday, August 1, 2020 1:27:07 PM EDT Steven Grubb wrote: >> I was using my desktop system when I got logged out. After logging back in, >> I found this message in my logs: >> >> Aug 1 13:08:22 x2 journal[1751]: UID 1000 exceeded its 'bytes' quota on >> UID 1000. > > I wrote a script that searched every binary on my system to see what possibly > matches this output. Turns out this cryptic message is from dbus-broker. As > best I can tell, a KDE program is triggering this. And I have no idea how to > reconfigure things to fix it, but the failure is catestrophic when it > shouldn't > be. And its happening with some regularity. > > You are warned... > > -Steve When reporting problems of this kind, could you share a link to the bugzilla you've filed against dbus-broker or this KDE program? Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster wrote: > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > > > Most of those are the libcroco->gettext breakage, no? > > From a very cursory scan (not at all scientific), > some percentage are the cmake macro changes. CMake macros are documented in the packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ Here's an example of how to adjust it: https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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é: > > > > > > > > > Disabling LTO in the RPM spec confirms this and makes things pass > > > > > again. Hacking the makefiles to remove the -fno-lto option when > > > > > building the test suite binaries also fixes things. > > > > > > > > > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > > > > > Fedora feature change page, but I can imagine how it would be. > > > > > > > > LTO should still export the same functions as before, and should not > > > > imply -fno-semantic-interposition by default. The linker plugin > > > > provides the necessary information to GCC. What you are observing could > > > > be the result of a toolchain bug. > > > > > > Libvirt has a test program "qemuhotplugtest". > > > > > > This test links to a shared library libqemutestdriver.so which contains > > > a function "qemuProcessStartManagedPRDaemon". > > > > > > qemuhotplugtest test does not call "qemuProcessStartManagedPRDaemon" > > > directly. It invokes "qemuDomainAttachDeviceDiskLive" which eventually > > > ends up calling "qemuProcessStartManagedPRDaemon" some way further > > > down the stack. > > > > > > > > > Then there is a shared library libqemuhotplugmock.so which contains a > > > replacement "qemuProcessStartManagedPRDaemon" to avoid us spawning > > > external programs. > > > > > > When it starts "qemuhotplugtest" will set LD_PRELOAD=libqemuhotplugmock.so > > > and then execve() itself. > > > > > > So when the test runs, the "qemuProcessStartManagedPRDaemon" impl from > > > the mock library is supposed to be used. > > > > > > If I run with LD_DEBUG=all on a build /without/ LTO, I can see this lookup > > > and override happening: > > > > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > > [0] > > > 381018: binding file > > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > > [0] to > > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > > [0]: normal symbol `qemuProcessStartManagedPRDaemon' > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirhostdevmock.so > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirpcimock.so > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libdomaincapsmock.so > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirprocessmock.so > > > [0] > > > 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in > > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so > > > [0] > > > 381018: binding file > > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > > [0] to > > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so > > > [0]: normal symbol `qemuProcessStartManagedPRDaemon' > > > > > > > > > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups > > > at all for qemuProcessStartManagedPRDaemon. It looks very much like the > > > call was resolved and bound at link time when built with LTO. > > > > Maybe it was not bound at link time, but inlined at compile time? > > > > I think it might be worthwhile to try and mark the > > qemuProcessStartManagedPRDaemon > > implementation which is used normally (no LD_PRELOAD) with some function > > attribute that it may be never inlined. I'm sure Florian and/or Jakub > > can help with what that function attribute should actually look like... > > We usually mark APIs we mock with G_GNUC_NO_INLINE to prevent such > problems. In this case we
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
On Mon, Aug 03, 2020 at 05:40:42PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups > > at all for qemuProcessStartManagedPRDaemon. It looks very much like the > > call was resolved and bound at link time when built with LTO. > > It's possible that the symbol extraction logic is confused by LTO, but > -ffat-lto-objects should prevent that. > > Can you collect all the linker input scripts/command lines after libtool > has done its thing? For the qemuhotplugtest, this should be the gcc line it is running: gcc -DHAVE_CONFIG_H -I. -I../../tests -I.. -I.. -I../.. -I../include -I../../include -I../src -I../../src -I../../src/util -I../../src/conf -I../../src/hypervisor -I../src/rpc -Dabs_builddir="\"/builddir/build/BUILD/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests\"" -Dabs_top_builddir="\"/builddir/build/BUILD/libvirt-6.5.0/x86_64-redhat-linux-gnu\"" -Dabs_srcdir="\"/builddir/build/BUILD/libvirt-6.5.0/x86_64-redhat-linux-gnu/../tests\"" -Dabs_top_srcdir="\"/builddir/build/BUILD/libvirt-6.5.0/x86_64-redhat-linux-gnu/..\"" -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/libnl3 -I/usr/include/libnl3 -I/usr/include/p11-kit-1 -I/usr/include/tirpc -fno-common -W -Wabsolute-value -Waddress -Waddress-of-packed-member -Waggressive-loop-optimizations -Wall -Wattribute-warning -Wattributes -Wbool-compare -Wbool-operation -Wbuiltin-declaration-mismatch -Wbuiltin-macro-redefined -Wcannot-profile -Wcast-align -Wcast-align=strict -Wcast-function-type -Wchar-subscripts -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdangling-else -Wdate-time -Wdeprecated-declarations -Wdesignated-init -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero -Wdouble-promotion -Wduplicated-cond -Wduplicate-decl-specifier -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wformat-zero-length -Wframe-address -Wfree-nonheap-object -Whsa -Wif-not-aligned -Wignored-attributes -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types -Winit-self -Winline -Wint-conversion -Wint-in-bool-context -Wint-to-pointer-cast -Winvalid-memory-model -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op -Wmain -Wmaybe-uninitialized -Wmemset-elt-size -Wmemset-transposed-args -Wmisleading-indentation -Wmissing-attributes -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-parameter-type -Wmissing-profile -Wmissing-prototypes -Wmultichar -Wmultistatement-macros -Wnarrowing -Wnested-externs -Wnonnull -Wnonnull-compare -Wnull-dereference -Wodr -Wold-style-declaration -Wold-style-definition -Wopenmp-simd -Woverflow -Woverride-init -Wpacked-bitfield-compat -Wpacked-not-aligned -Wparentheses -Wpointer-arith -Wpointer-compare -Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wpsabi -Wrestrict -Wreturn-local-addr -Wreturn-type -Wscalar-storage-order -Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument -Wsizeof-pointer-div -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes -Wstringop-truncation -Wsuggest-attribute=cold -Wsuggest-attribute=const -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wsuggest-final-methods -Wsuggest-final-types -Wswitch -Wswitch-bool -Wswitch-unreachable -Wsync-nand -Wtautological-compare -Wtrampolines -Wtrigraphs -Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance -Wvla -Wvolatile-register-var -Wwrite-strings -Walloc-size-larger-than=9223372036854775807 -Warray-bounds=2 -Wattribute-alias=2 -Wformat-overflow=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wnormalized=nfc -Wshift-overflow=2 -Wstringop-overflow=2 -Wunused-const-variable=2 -Wvla-larger-than=4031 -Wno-sign-compare -Wno-cast-function-type -Wjump-misses-init -Wswitch-enum -Wno-format-nonliteral -Wno-format-truncation -Wframe-larger-than=4096 -fstack-protector-strong -fexceptions -fasynchronous-unwind-tables -fipa-pure-const -Wno-suggest-attribute=pure -Wno-suggest-attribute=const -std=gnu99 -Wframe-larger-than=262144 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
[retitled] Fedora wiki and code tags
Richard Shaw writes: > So I wanted to document a ham radio related howto, so I decided that I > would make it an extension of the Amateur Radio SIG wiki, and I've got an > incomplete version created: > > https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat > > How can a wiki not have some kind of tag? > > Most other systems in Fedora support markdown, and I would be a fan of > that. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Hi, there are two documents in the list footer ^ you may wish to review. The Fedora wiki didn't just appear magically one day: your colleagues in Fedora put effort into standing it up and its maintainance, and some have even worked on mediawiki itself. Telling us that it "sucks" is not courteous, polite, considerate, or respectful. I've suggested a more friendly subject in my reply. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 4:24 PM Peter Robinson wrote: > There's also a bunch of CMake related ones and I'm not even sure how > to deal with that. The proposal owners stated that: Existing packages can (and most likely will) become FTBFS, but proposal owners will fix as many Fedora packages as possible. I interpret that as the proposal owners are about to push a bunch of fixes RSN and rebuild the impacted packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
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é: > > > > > > > Disabling LTO in the RPM spec confirms this and makes things pass > > > > again. Hacking the makefiles to remove the -fno-lto option when > > > > building the test suite binaries also fixes things. > > > > > > > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > > > > Fedora feature change page, but I can imagine how it would be. > > > > > > LTO should still export the same functions as before, and should not > > > imply -fno-semantic-interposition by default. The linker plugin > > > provides the necessary information to GCC. What you are observing could > > > be the result of a toolchain bug. > > > > Libvirt has a test program "qemuhotplugtest". > > > > This test links to a shared library libqemutestdriver.so which contains > > a function "qemuProcessStartManagedPRDaemon". > > > > qemuhotplugtest test does not call "qemuProcessStartManagedPRDaemon" > > directly. It invokes "qemuDomainAttachDeviceDiskLive" which eventually > > ends up calling "qemuProcessStartManagedPRDaemon" some way further > > down the stack. > > > > > > Then there is a shared library libqemuhotplugmock.so which contains a > > replacement "qemuProcessStartManagedPRDaemon" to avoid us spawning > > external programs. > > > > When it starts "qemuhotplugtest" will set LD_PRELOAD=libqemuhotplugmock.so > > and then execve() itself. > > > > So when the test runs, the "qemuProcessStartManagedPRDaemon" impl from > > the mock library is supposed to be used. > > > > If I run with LD_DEBUG=all on a build /without/ LTO, I can see this lookup > > and override happening: > > > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > [0] > > 381018:binding file > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > [0] to > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > [0]: normal symbol `qemuProcessStartManagedPRDaemon' > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirhostdevmock.so > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirpcimock.so > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libdomaincapsmock.so > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirprocessmock.so > > [0] > > 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so > > [0] > > 381018:binding file > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so > > [0] to > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so > > [0]: normal symbol `qemuProcessStartManagedPRDaemon' > > > > > > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups > > at all for qemuProcessStartManagedPRDaemon. It looks very much like the > > call was resolved and bound at link time when built with LTO. > > Maybe it was not bound at link time, but inlined at compile time? > > I think it might be worthwhile to try and mark the > qemuProcessStartManagedPRDaemon > implementation which is used normally (no LD_PRELOAD) with some function > attribute that it may be never inlined. I'm sure Florian and/or Jakub > can help with what that function attribute should actually look like... We usually mark APIs we mock with G_GNUC_NO_INLINE to prevent such problems. In this case we forgot to mark qemuProcessStartManagedPRDaemon but it doesn't actually make a difference to the behaviour if we add the missing G_GNUC_NO_INLINE annotation. I think the method impl is large enough that the compiler would not
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: > Hi All, > > > I just noticed that a lot my packages got a FTBFS because of > failing to build on s390x. The first set of rebuilds failed with: > > "BuildrootError: Requested repo (1785390) is DELETED" I have one of those too, but oddly enough another package of mine is failing (only) on s390x in its test suite (using LD_PRELOAD as mentioned in the previous thread - but that wasn't specific to s390x, right?). It would be nice if there was an up-to-date rawhide s390x available to all Fedora packagers for quick debug sessions, where I don't need root or anything special, and it can be safely shared with others. -- Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non responsive packager: rfairley
Addressed in: https://pagure.io/fesco/issue/2460#comment-668868 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
Hi, On 8/3/20 5:53 PM, Kevin Fenzi wrote: On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: Hi All, I just noticed that a lot my packages got a FTBFS because of failing to build on s390x. The first set of rebuilds failed with: "BuildrootError: Requested repo (1785390) is DELETED" The second set of rebuilds failed with: "rpm.error: error reading package header" errors. The last error was also seen quite a bit during the F32 mass rebuid ... I'm sorry this is happening, and it makes me very grumpy too. I have some thoughts on improvements we can make to help try and make this better, but I was under the impression it was mostly working ok for the second pass. We went from 4162 to 2833 failures, so it had to have been working at least sometime there? It seems for me the s390x failures on the second build are limited to package names starting with A-Z and "aa*" - "an*" . Any chance we can get a third mass rebuild for package-names starting with A-Z and "a*" ? Or maybe all those where the only failing platform is on s390x ? (no idea how easy it is to script any of this) Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote: > Hi All, > > > I just noticed that a lot my packages got a FTBFS because of > failing to build on s390x. The first set of rebuilds failed with: > > "BuildrootError: Requested repo (1785390) is DELETED" > > The second set of rebuilds failed with: > > "rpm.error: error reading package header" > > errors. > > The last error was also seen quite a bit during the F32 mass rebuid ... I'm sorry this is happening, and it makes me very grumpy too. I have some thoughts on improvements we can make to help try and make this better, but I was under the impression it was mostly working ok for the second pass. We went from 4162 to 2833 failures, so it had to have been working at least sometime there? I guess I will try and push changes this week to improve things. This may result in off line s390x builders when I reconfigure things, but I will try and keep it as minimal as I can. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: module build: BuildrootError: could not init mock buildroot
On Mon, Aug 03, 2020 at 04:47:39PM +0200, Jun Aruga wrote: ... > So, I suppose previously it tried to build outputed platform (f30). > The other build id 9294 is f32, 9295 is f31, 9296 is f33. Ah, that would do it. I finally was shown the command to retire the f30 eol platform and did so... before it was likely trying to build against it, but those targets are all gone, so nothing was in the build but the mbs macro package. ;( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 5:15 PM Richard Hughes wrote: > > On Mon, 3 Aug 2020 at 14:02, Mohan Boddu wrote: > > Failures can be seen > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Most of those are the libcroco->gettext breakage, no? We're not going > to be rebuilding all affected packages manually are we?! No, at this point, most breakage (~1000 packages) stems from CMake macro changes. Regarding FTBFS issues that were caused by the transient gettext / annobin / binutils issues in the buildroot, I've been resubmitting almost all of those already, and still have a script running that will resubmit the rest of them too. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
* Daniel P. Berrangé: > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups > at all for qemuProcessStartManagedPRDaemon. It looks very much like the > call was resolved and bound at link time when built with LTO. It's possible that the symbol extraction logic is confused by LTO, but -ffat-lto-objects should prevent that. Can you collect all the linker input scripts/command lines after libtool has done its thing? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > Most of those are the libcroco->gettext breakage, no? From a very cursory scan (not at all scientific), some percentage are the cmake macro changes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
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é: Disabling LTO in the RPM spec confirms this and makes things pass again. Hacking the makefiles to remove the -fno-lto option when building the test suite binaries also fixes things. I don't see any mention of LD_PRELOAD being impacted by LTO in the Fedora feature change page, but I can imagine how it would be. LTO should still export the same functions as before, and should not imply -fno-semantic-interposition by default. The linker plugin provides the necessary information to GCC. What you are observing could be the result of a toolchain bug. Libvirt has a test program "qemuhotplugtest". This test links to a shared library libqemutestdriver.so which contains a function "qemuProcessStartManagedPRDaemon". qemuhotplugtest test does not call "qemuProcessStartManagedPRDaemon" directly. It invokes "qemuDomainAttachDeviceDiskLive" which eventually ends up calling "qemuProcessStartManagedPRDaemon" some way further down the stack. Then there is a shared library libqemuhotplugmock.so which contains a replacement "qemuProcessStartManagedPRDaemon" to avoid us spawning external programs. When it starts "qemuhotplugtest" will set LD_PRELOAD=libqemuhotplugmock.so and then execve() itself. So when the test runs, the "qemuProcessStartManagedPRDaemon" impl from the mock library is supposed to be used. If I run with LD_DEBUG=all on a build /without/ LTO, I can see this lookup and override happening: 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] 381018:binding file /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] to /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0]: normal symbol `qemuProcessStartManagedPRDaemon' 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirhostdevmock.so [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirpcimock.so [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libdomaincapsmock.so [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirprocessmock.so [0] 381018:symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so [0] 381018:binding file /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] to /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so [0]: normal symbol `qemuProcessStartManagedPRDaemon' If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups at all for qemuProcessStartManagedPRDaemon. It looks very much like the call was resolved and bound at link time when built with LTO. Maybe it was not bound at link time, but inlined at compile time? I think it might be worthwhile to try and mark the qemuProcessStartManagedPRDaemon implementation which is used normally (no LD_PRELOAD) with some function attribute that it may be never inlined. I'm sure Florian and/or Jakub can help with what that function attribute should actually look like... Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > Disabling LTO in the RPM spec confirms this and makes things pass > > again. Hacking the makefiles to remove the -fno-lto option when > > building the test suite binaries also fixes things. > > > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > > Fedora feature change page, but I can imagine how it would be. > > LTO should still export the same functions as before, and should not > imply -fno-semantic-interposition by default. The linker plugin > provides the necessary information to GCC. What you are observing could > be the result of a toolchain bug. Libvirt has a test program "qemuhotplugtest". This test links to a shared library libqemutestdriver.so which contains a function "qemuProcessStartManagedPRDaemon". qemuhotplugtest test does not call "qemuProcessStartManagedPRDaemon" directly. It invokes "qemuDomainAttachDeviceDiskLive" which eventually ends up calling "qemuProcessStartManagedPRDaemon" some way further down the stack. Then there is a shared library libqemuhotplugmock.so which contains a replacement "qemuProcessStartManagedPRDaemon" to avoid us spawning external programs. When it starts "qemuhotplugtest" will set LD_PRELOAD=libqemuhotplugmock.so and then execve() itself. So when the test runs, the "qemuProcessStartManagedPRDaemon" impl from the mock library is supposed to be used. If I run with LD_DEBUG=all on a build /without/ LTO, I can see this lookup and override happening: 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] 381018: binding file /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] to /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0]: normal symbol `qemuProcessStartManagedPRDaemon' 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirhostdevmock.so [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirpcimock.so [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libdomaincapsmock.so [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirprocessmock.so [0] 381018: symbol=qemuProcessStartManagedPRDaemon; lookup in file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so [0] 381018: binding file /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so [0] to /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so [0]: normal symbol `qemuProcessStartManagedPRDaemon' If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups at all for qemuProcessStartManagedPRDaemon. It looks very much like the call was resolved and bound at link time when built with LTO. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x weirdness during mass rebuild
On 03/08/20 17:16 +0200, Andrea Musuruane wrote: Hi guys, at least one of the packages I maintain was also affected. Fedora I'm seeing the same error for boost on both s390x and armv7hl. Release Engineering has opened a bug against the package for this issue. Can you please avoid that? Moreover, would my package be orphaned in 8 weeks because it cannot be built for a builder issue on s390x? It's unlikely the problem with the builders will not get fixed within the next 8 weeks. https://bugzilla.redhat.com/show_bug.cgi?id=1863133 BR, Andrea On Tue, Jul 28, 2020 at 8:05 AM Guido Aulisi wrote: Il giorno lun 27 lug 2020 alle ore 17:11 Jerry James ha scritto: > > I don't know if this is related to what we saw during the previous > mass rebuild, but on s390x only, the TOPCOM build failed with: > > BuildrootError: Requested repo (1785306) is DELETED I'm having the same issue. https://koji.fedoraproject.org/koji/buildinfo?buildID=1548001 FAS: tartina Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 4:15 PM Richard Hughes wrote: > > On Mon, 3 Aug 2020 at 14:02, Mohan Boddu wrote: > > Failures can be seen > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Most of those are the libcroco->gettext breakage, no? We're not going > to be rebuilding all affected packages manually are we?! There's also a bunch of CMake related ones and I'm not even sure how to deal with that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors
Hi All, I just noticed that a lot my packages got a FTBFS because of failing to build on s390x. The first set of rebuilds failed with: "BuildrootError: Requested repo (1785390) is DELETED" The second set of rebuilds failed with: "rpm.error: error reading package header" errors. The last error was also seen quite a bit during the F32 mass rebuid ... I just checked 3 semi-random packages of the 9 FTBFS bugs filed sofar, still at the later a only and I already got 9! And all 3 have this issue rather then being true FTBFS errors. Now I can try to resubmit these, and resubmit again and resubmit again, until they succeed as I did for a bunch of packages (but not this much) during the previous mass-rebuild, but that seems like a significant waste of mine and other contributors time. With me Red Hat off and my Fedora contributor head on, I really think we need to get these s390x build issues escalated. 99% of the reasons to support s390x is because of a certain downstream derivative of Fedora. If they care so much about this, they really ought to fix these s30-x build issues, which seem to have been plaguing us for at least a full cycle now (at least the second problem mentioned above). Alternatively, maybe we need to re-introduce secondary arches and make s390x build failures non fatal? I dunno but IMHO we need to do something continuing as usual with this is IMHO not a good answer here. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
Many of this are cmake change breakage. пн, 3 авг. 2020 г., 18:15 Richard Hughes : > On Mon, 3 Aug 2020 at 14:02, Mohan Boddu wrote: > > Failures can be seen > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Most of those are the libcroco->gettext breakage, no? We're not going > to be rebuilding all affected packages manually are we?! > > Richard./ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x weirdness during mass rebuild
Hi guys, at least one of the packages I maintain was also affected. Fedora Release Engineering has opened a bug against the package for this issue. Can you please avoid that? Moreover, would my package be orphaned in 8 weeks because it cannot be built for a builder issue on s390x? https://bugzilla.redhat.com/show_bug.cgi?id=1863133 BR, Andrea On Tue, Jul 28, 2020 at 8:05 AM Guido Aulisi wrote: > Il giorno lun 27 lug 2020 alle ore 17:11 Jerry James > ha scritto: > > > > I don't know if this is related to what we saw during the previous > > mass rebuild, but on s390x only, the TOPCOM build failed with: > > > > BuildrootError: Requested repo (1785306) is DELETED > I'm having the same issue. > https://koji.fedoraproject.org/koji/buildinfo?buildID=1548001 > > FAS: tartina > > Ciao > Guido > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > Disabling LTO in the RPM spec confirms this and makes things pass > > again. Hacking the makefiles to remove the -fno-lto option when > > building the test suite binaries also fixes things. > > > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > > Fedora feature change page, but I can imagine how it would be. > > LTO should still export the same functions as before, and should not > imply -fno-semantic-interposition by default. The linker plugin > provides the necessary information to GCC. What you are observing could > be the result of a toolchain bug. Yeah (unless it is Clang which only supports -fno-semantic-interposition and not anything else. LD_PRELOAD will simply not work with it). Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
* Daniel P. Berrangé: > Disabling LTO in the RPM spec confirms this and makes things pass > again. Hacking the makefiles to remove the -fno-lto option when > building the test suite binaries also fixes things. > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > Fedora feature change page, but I can imagine how it would be. LTO should still export the same functions as before, and should not imply -fno-semantic-interposition by default. The linker plugin provides the necessary information to GCC. What you are observing could be the result of a toolchain bug. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: module build: BuildrootError: could not init mock buildroot
> Can you try again now? we fixed a major issue with mbs, which I wouldn't think was related to this, but who knows.. I tried it, and found the cause of the error now. > So isn't this the relevant part of root.log which could give a hint? Yes, possibly it is related to the issue. > https://koji.fedoraproject.org/koji/taskinfo?taskID=48194471 > BuildrootError: could not init mock buildroot, mock exited with status > 20; see root.log for more information > > https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/root.log > => looks ok. > https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/build.log > => empty. The situation is when I got the above error, I got the 4 builds by `fedpkg module-build`. (I am excluding el8 by `platform: [-el8]`) in the module config file ruby.yaml. ``` $ fedpkg module-build Submitting the module build... The builds 9293, 9294, 9295 and 9296 were submitted to the MBS ``` The error happened on build id 9293. But today I got the 3 builds with the same config file except the build id 9293. ``` $ fedpkg module-build Submitting the module build... The builds 9296, 9294 and 9295 were submitted to the MBS ``` I found `ruby-None-None` in the build id 9293. So, I suppose previously it tried to build outputed platform (f30). The other build id 9294 is f32, 9295 is f31, 9296 is f33. ``` $ fedpkg module-build-info 9293 ... Name: ruby NVR:ruby-None-None State: FAILED Koji Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=48194471 ... ``` -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)
I'm trying to understand failures in the libvirt test suite since the Fedora rawhide mass rebuild. Our test suite makes extensive use of mocking to replace functions in the library being tested. We do this either by loading a LD_PRELOAD, or by having the test program define a symbol with the same name as the one in the library to replace it. It appears this is being broken by LTO Disabling LTO in the RPM spec confirms this and makes things pass again. Hacking the makefiles to remove the -fno-lto option when building the test suite binaries also fixes things. I don't see any mention of LD_PRELOAD being impacted by LTO in the Fedora feature change page, but I can imagine how it would be. What is still confusing me is that 40+ of our test programs rely on LD_PRELOAD, but only one of them actually broke from LTO. It seems the LTO is inconsistent is how it affects the test binaries in some way. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review swaps
Robert-André Mauchin 于2020年8月2日周日 上午1:47写道： > > On Saturday, 1 August 2020 05:07:52 CEST Qiyu Yan wrote: > > Jerry James 于 2020年8月1日周六 上午5:24写道： > > > > > I need two packages reviewed to enable some optional functionality in > > > the normaliz package. The second depends on the first: > > > > > > antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862615 > > > > Done for this. > > > > > e-antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862616 > > > > Maybe we should wait the former one to be ready in rawhide, then this? > > > > You can use the -L switch in fedora-review to install packages prior to > testing. For example, you create a "deps" folder, and add bug 1862615 RPM > results in it. Then you pass -L deps to fedora review: > > fedora-review -r fedora-rawhide-x86_64 -L deps theSRPM This works, but due to the mass rebuild and the mirrors available for me didn't get synced. Preparing the buildroot will take unreasonable long time here, maybe letting others interested to continue. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, 3 Aug 2020 at 14:02, Mohan Boddu wrote: > Failures can be seen > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html Most of those are the libcroco->gettext breakage, no? We're not going to be rebuilding all affected packages manually are we?! Richard./ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora flatpaks on non-x86 architectures
On Mon, Aug 3, 2020 at 12:13 pm, John Doe wrote: I am willing to help this, I want flatpaks with sandboxing for more secure desktop with Fedora. Best person to talk to about helping out with Fedora flatpaks would be Owen Taylor . I understand that infrastructure challenges are the main problems here ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Fedora wiki system sucks
On Sat, Aug 1, 2020 at 8:21 PM Richard Shaw wrote: > > On Sat, Aug 1, 2020 at 1:10 PM Adam Williamson > wrote: >> >> If what you're writing falls under the general heading of >> 'documentation', you might want to write it for docs.fedoraproject.org >> rather than the wiki. docs.fp.o is built by a static generator and uses >> the ASCIIDoc markup language. See >> https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/ > > Perhaps... Is docs open? Or is there some process for getting this approved? > I'm heavily making updates right now. I'm somewhat selfishly documenting it > so I remember how I set everything up as I'm sure I won't remember a year > from now :) But figured it's worth documenting for others as well. This sounds like something for the https://docs.fedoraproject.org/en-US/quick-docs/ section, or if you have enough stuff a dedicated HAM section. I suggest you start by submitting PRs to the quick docs repo (https://pagure.io/fedora-docs/quick-docs/pull-requests) regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
