Re: Heads-up: Side-tag rebuild due to minizip-ng soname bump
Am 07.11.22 um 14:49 schrieb Petr Pisar:
V Mon, Nov 07, 2022 at 01:40:18PM +0100, Lukas Javorsky napsal(a):
Hi,
Minizip-ng has changed its soname name from "libminizip.so.3.0" to
"libminizip.so.3" thus we need to rebuild all the packages that are
requiring this soname.
I've listed them with the following command: *dnf repoquery --whatrequires
'libminizip.so.3*' --qf '%{sourcerpm}\t%{name}' | sed -e
's/-[^-]*-[^-]*rpm//' | sort -u | awk '{ print $1 }' | uniq*
And these are the results:
collada-dom
dolphin-emu
libnuml
My listing is missing libnuml. I raised a question of the dependency in
.
-- Petr
Hello,
please may you include my PRs before you start the rebuild?
- https://src.fedoraproject.org/rpms/minizip/pull-request/3
- https://src.fedoraproject.org/rpms/minizip/pull-request/4
In particular the first one as the pkg-config file is not usable without
it. Thank you.
Best regards,
Julian
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2141527] New: perl-CGI-Application-Plugin-ValidateRM-2.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2141527 Bug ID: 2141527 Summary: perl-CGI-Application-Plugin-ValidateRM-2.52 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CGI-Application-Plugin-ValidateRM Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.52 Upstream release that is considered latest: 2.52 Current version/release in rawhide: 2.5-28.fc37 URL: https://metacpan.org/release/CGI-Application-Plugin-ValidateRM 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://docs.fedoraproject.org/en-US/package-maintainers/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/18246/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-CGI-Application-Plugin-ValidateRM -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2141527 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: MobilityPhoshImage (Self-Contained Change proposal)
What is the driver for choosing Phosh over GNOME Shell? Let me first say the amount of work put in by both Purism and the GNOME community into Phosh and other mobile components like libhandy has been critical to Linux mobile space. While mobile friendly GNOME Shell improvements only recently started and is not currently as feature rich as Phosh, the recent focus on it by the GNOME community has lead to some fast and impressive development as seen on the GNOME blog: https://blogs.gnome.org/shell-dev/2022/09/09/gnome-shell-on-mobile-an-update/ Most of the changes in the blog look to be targeting merging upstream in time for 44's release which I believe would be in Fedora 38. Even then though GNOME Shell wouldn't be at feature parity with Phosh. However, the main argument long term for having a mobile image that uses GNOME Shell over Phosh is more resourcing due to mutual benefits on mobile and desktop with things like the new gesture API referenced in the blog. If feature set is the driver, I understand, but as a Librem5 owner and someone with all their boxes imaged with Fedora I'd be curious if there would be any plans to eventually switch to GNOME Shell once feature parity happens. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Kevin Kofler via devel wrote: > Mattia Verga via devel wrote: >> with the current workflow, Bodhi doesn't know when a release is freezed. >> There is support for a "Freeze" state, but it was never used. > > How do we prevent then that pushes to stable actually move forward? If > rel- eng just hits a different button / runs a different script to push > testing only instead of both testing and stable, that is the "can we push > to stable?" property Bodhi needs to check. PS: The "worst mistake" that can happen then is that if we push only testing to a non-frozen release for whatever reason, the update will be included in that testing push, and then move forward to stable in the next stable push. I do not see this as a real issue. Kevin Kofler ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Mattia Verga via devel wrote: > with the current workflow, Bodhi doesn't know when a release is freezed. > There is support for a "Freeze" state, but it was never used. How do we prevent then that pushes to stable actually move forward? If rel- eng just hits a different button / runs a different script to push testing only instead of both testing and stable, that is the "can we push to stable?" property Bodhi needs to check. Kevin Kofler ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On Wed, 2022-11-09 at 19:27 -0500, Demi Marie Obenour wrote: > On 11/9/22 05:21, Dan Horák wrote: > > On Tue, 01 Nov 2022 11:26:13 - > > Daan De Meyer via devel wrote: > > > > > I've added a new section to the proposal with the benchmark > > > results of some benchmarks we performed against a Fedora 37 > > > system built with frame pointers and a regular Fedora 37 system. > > > The impact on most benchmarks seems limited aside from the > > > CPython benchmark suite (pyperformance). See the proposal itself > > > for the details. > > > > what is the impact of the proposed change on non-x86 platforms? I > > assume the proposal focuses on x86, but the distro wide flags are > > shared > > across all platforms in Fedora, it means aarch64, ppc64le and > > s390x. > > With RISC-V waiting behind the door ... > > None, because this proposal is not going to be implemented. but if was implemented what would be the impact ? > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On 11/9/22 05:21, Dan Horák wrote: > On Tue, 01 Nov 2022 11:26:13 - > Daan De Meyer via devel wrote: > >> I've added a new section to the proposal with the benchmark results of some >> benchmarks we performed against a Fedora 37 system built with frame pointers >> and a regular Fedora 37 system. The impact on most benchmarks seems limited >> aside from the CPython benchmark suite (pyperformance). See the proposal >> itself for the details. > > what is the impact of the proposed change on non-x86 platforms? I > assume the proposal focuses on x86, but the distro wide flags are shared > across all platforms in Fedora, it means aarch64, ppc64le and s390x. > With RISC-V waiting behind the door ... None, because this proposal is not going to be implemented. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2140480] perl-Dist-Zilla-6.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2140480 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Dist-Zilla-6.027 is|perl-Dist-Zilla-6.028 is |available |available --- Comment #1 from Upstream Release Monitoring --- Releases retrieved: 6.028 Upstream release that is considered latest: 6.028 Current version/release in rawhide: 6.025-1.fc38 URL: http://search.cpan.org/dist/Dist-Zilla/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/5898/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Dist-Zilla -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2140480 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2141400] New: perl-Catalyst-Runtime-5.90130 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2141400 Bug ID: 2141400 Summary: perl-Catalyst-Runtime-5.90130 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Catalyst-Runtime Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 5.90130 Upstream release that is considered latest: 5.90130 Current version/release in rawhide: 5.90129-2.fc38 URL: https://metacpan.org/release/Catalyst-Runtime/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/5865/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Catalyst-Runtime -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2141400 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
When I’ve been mass-CC’d on irrelevant CVEs, I have been able to determine that it was due to a package-lock.json file, which names and pins the versions of all recursive dependencies, that was included with some example NodeJS project in the source tarball. I’ve had trouble with this on a handful of packages. I don’t recall whether it matters if the file is installed in a -doc subpackage with the other documentation and example files or only present in the sources, but I do remember that removing the package-lock.json file in %prep kept me from getting further irrelevant reports. Obviously, it would be better if the “targeting” of these automated reports were better so that these workarounds weren’t required. When bugs are to be filed for dozens of packages, the standard of care in verifying their applicability should perhaps be a little higher. On Wed, Nov 9, 2022, at 9:28 AM, Vít Ondruch wrote: > Dne 09. 11. 22 v 3:10 Ian McInerney via devel napsal(a): >> On Wed, Sep 7, 2022 at 7:45 PM Ben Cotton wrote: >>> On Wed, Sep 7, 2022 at 2:05 PM Maxwell G via devel >>> wrote: >>> > >>> > Does anyone know how to reach prodsec about this? >>> >>> I'll reach out to the people I know and see what the best way to get >>> them in this conversation is. >>> >> >> Has this conversation been started yet? Because the CVE reporting system >> doesn't seem to have been improved at all - in fact a recent CVE bug >> (https://bugzilla.redhat.com/show_bug.cgi?id=2141029) was filed, had over >> 179 people added to the CC list, and there is no mention at all of which >> applications were identified as being affected or any other tracking bugs >> filed for those affected applications. So as a maintainer, I am then unsure >> why I was CC'd on the bug and which application prod sec wants me to examine >> for the vulnerability (especially since to my knowledge, none of the >> packages I maintain even use electron in any way or have its code contained >> inside of them). > > > Just FTR, when I was last time looking for answers why I was added on > some tracker, and it was probably due to package.json included in > source tarball, I was pointed to this project, which should be behind > creating these trackers: > > https://github.com/RedHatProductSecurity/component-registry > > But hard to tell how it is used in practice :/ > > > > Vít > > > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > Attachments: > * OpenPGP_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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS Meeting Minutes 2022-11-09
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-09/fedora_coreos_meeting.2022-11-09-16.35.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-09/fedora_coreos_meeting.2022-11-09-16.35.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-09/fedora_coreos_meeting.2022-11-09-16.35.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:35:25 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-09/fedora_coreos_meeting.2022-11-09-16.35.log.html . Meeting summary --- * roll call (dustymabe, 16:35:29) * Action items from last meeting (dustymabe, 16:38:40) * there were no action items assigned last meeting! (dustymabe, 16:38:48) * moby-engine (docker) maintenance in Fedora in question (dustymabe, 16:39:31) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1291 (dustymabe, 16:39:36) * LINK: https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/ (dustymabe, 16:48:04) * LINK: https://docs.docker.com/engine/install/fedora/ (travier, 16:49:51) * ACTION: travier will send an email to coreos devel list and cc fedora devel to try to find volunteers to help with moby-engine maintainership in Fedora (dustymabe, 16:55:32) * including audit in Fedora CoreOS (dustymabe, 16:55:42) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/461 (dustymabe, 16:55:50) * we think we're in a better position to include auditd in FCOS now, though there is still some work remaining. travier will enumerate the remaining work and look to find volunteers. (dustymabe, 17:03:37) * open floor (dustymabe, 17:12:36) * We are hoping that the F37 release will happen next week. Please test out the `next` stream today and report issues as that will be coming to `testing` very soon. (dustymabe, 17:13:16) Meeting ended at 17:27:19 UTC. Action Items * travier will send an email to coreos devel list and cc fedora devel to try to find volunteers to help with moby-engine maintainership in Fedora Action Items, by person --- * travier * travier will send an email to coreos devel list and cc fedora devel to try to find volunteers to help with moby-engine maintainership in Fedora * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (82) * travier (55) * jlebon (28) * zodbot (20) * fifofonix (10) * spresti[m] (3) * gursewak_ (1) * gursewak (1) * ravanelli (1) * marmijo (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2137026] perl-Chart-2.403.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2137026 Petr Pisar changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE Last Closed||2022-11-09 16:59:39 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2137026 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2137026] perl-Chart-2.403.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2137026 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-Chart-2.403.8-1.fc38 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2137026 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Wed, Nov 9, 2022 at 2:52 PM Miroslav Suchý wrote: > > Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a): > > What do we do if the SPDX tag is the same as the existing license > tag (eg ISC) though? Do we just add a dummy change/commit entry that > mentions SPDX to confirm we've reviewed it? > > Don't bother. Eventually, we'll re-process all spec files and identify > what to do next anyway. > > Actually... if you add there the dummy changelog entry, it makes my work > easier. Which data source are you using to check changelog contents? For packages that use rpmautospec, you'll need to check changelog contents in the SRPM, not the unprocessed spec file. And if you're querying changelogs from RPMs or SRPMs, adding a dummy changelog entry also won't do anything unless a new build is done in either case. Also note that for Rust packages, conversion to SPDX has been an ongoing process since rust2rpm made SPDX expressions the default with version 22, and the conversion itself was usually just a side product of updating packages to a newer version, and in these cases, the changelog doesn't mention SPDX at all. If you want to include Rust packages which have switched to SPDX in your analysis, you can grep spec files for the string "# Generated by rust2rpm 22" or "# Generated by rust2rpm 23" (since spec files generated by rust2rpm v22+ use SPDX). 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
Dne 09. 11. 22 v 3:10 Ian McInerney via devel napsal(a): On Wed, Sep 7, 2022 at 7:45 PM Ben Cotton wrote: On Wed, Sep 7, 2022 at 2:05 PM Maxwell G via devel wrote: > > Does anyone know how to reach prodsec about this? I'll reach out to the people I know and see what the best way to get them in this conversation is. Has this conversation been started yet? Because the CVE reporting system doesn't seem to have been improved at all - in fact a recent CVE bug (https://bugzilla.redhat.com/show_bug.cgi?id=2141029) was filed, had over 179 people added to the CC list, and there is no mention at all of which applications were identified as being affected or any other tracking bugs filed for those affected applications. So as a maintainer, I am then unsure why I was CC'd on the bug and which application prod sec wants me to examine for the vulnerability (especially since to my knowledge, none of the packages I maintain even use electron in any way or have its code contained inside of them). Just FTR, when I was last time looking for answers why I was added on some tracker, and it was probably due to package.json included in source tarball, I was pointed to this project, which should be behind creating these trackers: https://github.com/RedHatProductSecurity/component-registry But hard to tell how it is used in practice :/ Vít OpenPGP_signature Description: OpenPGP digital 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Reminder: F37 Final Go/No-Go meeting tomorrow
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 10 November at 1700 UTC in #fedora-meeting. Note that depending on your time zone, this may be an hour earlier in your local time than you're used to. At this time, we will determine the status of the F37 Final for the 15 November target date #3[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 1 proposed release blocker bug[4]. [1] https://calendar.fedoraproject.org/meeting/10360/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Wed, Nov 9, 2022 at 1:52 PM Miroslav Suchý wrote: > Actually... if you add there the dummy changelog entry, it makes my work > easier. Does it make sense for your script in some future iteration to add in the capability to check if the license is identical pre/post SPDX if the spec does not have a changelog or commit message mentioning SPDX? Either hard code the cases (not ideal?), or run license-fedora2spdx and compare the results? That (I think) would handle the ISC example. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Reminder: F37 Final Go/No-Go meeting tomorrow
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 10 November at 1700 UTC in #fedora-meeting. Note that depending on your time zone, this may be an hour earlier in your local time than you're used to. At this time, we will determine the status of the F37 Final for the 15 November target date #3[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 1 proposed release blocker bug[4]. [1] https://calendar.fedoraproject.org/meeting/10360/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a): What do we do if the SPDX tag is the same as the existing license tag (eg ISC) though? Do we just add a dummy change/commit entry that mentions SPDX to confirm we've reviewed it? Don't bother. Eventually, we'll re-process all spec files and identify what to do next anyway. Actually... if you add there the dummy changelog entry, it makes my work easier. Miroslav ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
Dne 08. 11. 22 v 11:07 Petr Pisar napsal(a): Could you remove from the listing spec files whose License tag contains capitalized SPDX conjunctions (OR AND WITH)? Cf. perl-Alien-Build. Great idea. Will do. Miroslav ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Wed, Nov 9, 2022 at 7:51 AM Tom Hughes via devel wrote: > > On 07/11/2022 17:46, Miroslav Suchý wrote: > > > 8. > > > > After you migrate your SPEC file, please add the string “SPDX” to > > the entry of the packages’ %changelog. This is the easiest way to > > detect the migration has been done. The second best option is to add > > it to the dist-git commit message. > > What do we do if the SPDX tag is the same as the existing license > tag (eg ISC) though? Do we just add a dummy change/commit entry that > mentions SPDX to confirm we've reviewed it? > Don't bother. Eventually, we'll re-process all spec files and identify what to do next anyway. -- 真実はいつも一つ！/ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 07/11/2022 17:46, Miroslav Suchý wrote: 8. After you migrate your SPEC file, please add the string “SPDX” to the entry of the packages’ %changelog. This is the easiest way to detect the migration has been done. The second best option is to add it to the dist-git commit message. What do we do if the SPDX tag is the same as the existing license tag (eg ISC) though? Do we just add a dummy change/commit entry that mentions SPDX to confirm we've reviewed it? 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 compose report: 20221109.n.0 changes
OLD: Fedora-37-20221108.n.0 NEW: Fedora-37-20221109.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 345.61 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 22.33 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: webkitgtk-2.38.2-1.fc37 Old package: webkitgtk-2.38.1-1.fc37 Summary: GTK web content engine library RPMs: javascriptcoregtk4.0 javascriptcoregtk4.0-devel javascriptcoregtk4.1 javascriptcoregtk4.1-devel javascriptcoregtk5.0 javascriptcoregtk5.0-devel webkit2gtk4.0 webkit2gtk4.0-devel webkit2gtk4.0-doc webkit2gtk4.1 webkit2gtk4.1-devel webkit2gtk4.1-doc webkit2gtk5.0 webkit2gtk5.0-devel webkit2gtk5.0-doc Size: 345.61 MiB Size change: 22.33 KiB Changelog: * Fri Nov 04 2022 Michael Catanzaro 2.38.2-1 - Update to 2.38.2 = DOWNGRADED 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Text-VCardFast] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Text-VCardFast` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Text-VCardFast/pull-request/1 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Building Python 3.12 with no-omit-frame-pointer
tl;dr: Python 3.12 should be built with no-omit-frame-pointer if upstream recommends it. Hello, You might be aware of a Fedora change proposal [0] (discussed on fedora-devel [1] and FESCo [2]) are discussing turning on C compiler flags that help with performance *measurement*, but might hurt performance itself: `-fno-omit-frame-pointer` and `-mno-omit-leaf-frame-pointer`. Apparently there are some benchmarks that make Python look extra slow when the flags are turned on -- which I don't quite understand. Meanwhile, on the upstream side, Python 3.12 (due next year, main Python for Fedora 39 [3]) has support for `perf`. Upstream plans to recommend compiling with these flags when measuring performance [4], and AFAIK, the plan is to recommend *always* compiling with them. The idea is that possible speedups from "allowing anyone to profile/optimize their workflow" are worth the initial slowdown. I'm not much of a performance expert myself, but I do get drawn into the relevant discussions on the CPython side. As far as I can see, performance geeks are enthusiastic for `perf` support, and I'd like to get them to (continue to) use Fedora builds. If CPython upstream does recommend these flags (or makes them default), I'm considering to turn the no-omit options on for Python 3.12 even if Fedora as a whole doesn't. Note that even a 2% slowdown will likely won back by general performance improvements – the Faster CPython team is targeting a 20% average speedup for pure-Python code in 3.12, on top of the ~25% for 3.11. And the people responsible for this speedup have a say in the upstream recommendations. Technically there are three separate places where the flags can be set, I think we should turn them on everywhere: - CPython itself & its standard library - The debug build (/usr/bin/python3-debug) - Default for libraries in Fedora (RPM macros) - Befault for libraries built by users (sysconfig settings) [0]: https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer [1]: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/OOJDAKTJB5WGMOZRXTUX7FTPFBF3H7WE/ [2]: https://pagure.io/fesco/issue/2817 [3]: https://fedoraproject.org/wiki/Changes/Python3.12 [4]: https://docs.python.org/3.12/howto/perf_profiling.html#how-to-obtain-the-best-results ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2138492] perl-DateTime-TimeZone-2.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2138492 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-DateTime-TimeZone-2.56 |perl-DateTime-TimeZone-2.56 |-1.fc38 |-1.fc38 |perl-DateTime-TimeZone-2.56 |perl-DateTime-TimeZone-2.56 |-1.fc36 |-1.fc36 ||perl-DateTime-TimeZone-2.56 ||-1.fc35 --- Comment #8 from Fedora Update System --- FEDORA-2022-84c675319d has been pushed to the Fedora 35 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. https://bugzilla.redhat.com/show_bug.cgi?id=2138492 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2138492] perl-DateTime-TimeZone-2.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2138492 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-DateTime-TimeZone-2.56 |perl-DateTime-TimeZone-2.56 |-1.fc38 |-1.fc38 ||perl-DateTime-TimeZone-2.56 ||-1.fc36 Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2022-11-09 11:20:26 --- Comment #7 from Fedora Update System --- FEDORA-2022-1ee607d850 has been pushed to the Fedora 36 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. https://bugzilla.redhat.com/show_bug.cgi?id=2138492 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221109.n.0 changes
OLD: Fedora-Rawhide-20221108.n.0 NEW: Fedora-Rawhide-20221109.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 4 Dropped packages:2 Upgraded packages: 152 Downgraded packages: 0 Size of added packages: 5.21 MiB Size of dropped packages:169.27 KiB Size of upgraded packages: 2.07 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -134.11 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20221109.n.0.ppc64le.qcow2 Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20221109.n.0.ppc64le.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: perl-Graphics-Toolkit-Color-1.04-1.fc38 Summary: Color palette creation helper RPMs:perl-Graphics-Toolkit-Color perl-Graphics-Toolkit-Color-tests Size:68.37 KiB Package: rnp-0.16.2-4.fc38 Summary: OpenPGP (RFC4880) tools RPMs:librnp librnp-devel rnp Size:2.49 MiB Package: rust-memfd-0.6.1-1.fc38 Summary: Pure-Rust library to work with Linux memfd and sealing RPMs:rust-memfd+default-devel rust-memfd-devel Size:26.81 KiB Package: upx-4.0.0-1.fc38 Summary: Ultimate Packer for eXecutables RPMs:upx Size:2.62 MiB = DROPPED PACKAGES = Package: python-APScheduler-3.8.0-3.fc37 Summary: In-process task scheduler with Cron-like capabilities RPMs:python3-APScheduler Size:152.54 KiB Package: python-pecan-notario-0.0.3-25.fc37 Summary: JSON validation for Pecan with Notario RPMs:python3-pecan-notario Size:16.74 KiB = UPGRADED PACKAGES = Package: anaconda-38.8-1.fc38 Old package: anaconda-38.7-1.fc38 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 19.90 MiB Size change: -108.47 KiB Changelog: * Tue Nov 08 2022 Packit - 38.8-1 - Web UI: Update language selection screen (ozobal) - There are no installation targets if bootloader devices are not set (#2131183) (vponcova) - makebumpver: import bugzilla only if used (vslavik) - Remove the period at the end of the button caption (bramgn) - sync_run_task: Poll proxy state faster (vslavik) - Use more dasbus-ish interface (vslavik) - Web UI: Redesign language selection screen (ozobal) - Add GetCommonLocales to API (ozobal) - network: fix add_connection_sync doc string (rvykydal) - webui: update pixel tests for "Detect disks" updates (rvykydal) - webui: Use 'Detect Disks' instead of 'Discover Disks' (rvykydal) - webui: do not hide checkbox when showing skeleton while rescanning disks (rvykydal) - Add release notes for Fedora 37 (vponcova) - driver_updates: migrate driver_updates.py to pep8 format (jkonecny) - driver_updates: adding tests for the new logging solution (jkonecny) - driver_updates: add lot of debug logs for easier debugging (jkonecny) - driver_updates: extend where we print log messages (jkonecny) - Change screensaver handling to dasbus, drop safe_dbus (vslavik) - webui: improve formatting of a promise (rvykydal) - webui: show alert when there are no discovered disks (rvykydal) - webui: disable bulk selection during disks discovery (rvykydal) - webui: add tooltip to disks discovery button (rvykydal) - webui: replace discovery button spinner with skeleton (rvykydal) - rpm-ostree: set untrusted ostree pull flag (champetier.etienne) Package: andriller-3.3.1-8.fc38 Old package: andriller-3.3.1-8.fc37 Summary: Android Forensic Tools RPMs: andriller Size: 184.92 KiB Size change: -44 B Package: ansible-collection-community-general-6.0.0-1.fc38 Old package: ansible-collection-community-general-6.0.0~a1-1.fc38 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.43 MiB Size change: 7.60 KiB Changelog: * Tue Nov 08 2022 Maxwell G - 6.0.0-1 - Update to 6.0.0. Package: arandr-0.1.10-13.fc38 Old package: arandr-0.1.10-12.fc37 Summary: Simple GTK+ XRandR GUI RPMs: arandr Size: 138.26 KiB Size change: -113 B Changelog: * Tue Nov 08 2022 Frantisek Sumsal - 0.1.10-13 - Fix compatibility with Python 3.11 [BZ#2141076] Package: awscli-1.27.4-1.fc38 Old package: awscli-1.27.3-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.24 MiB Size change: 270 B Changelog: * Tue Nov 08 2022 Gwyn Ciesla - 1.27.4-1 - 1.27.4 Package: binutils-2.39-5.fc38 Old package: binutils-2.39-3.fc38 Summary: A GNU collection of binary utilities RPMs: binutils binutils-devel binutils-gold binutils-gprofng Size: 63.36 MiB Size change: -18.97 MiB Changelog:
[rpms/perl-Text-VCardFast] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Text-VCardFast` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Text-VCardFast/pull-request/1 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Module-Package] PR #1: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-Module-Package` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Module-Package/pull-request/1 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
* Demi Marie Obenour: > On 11/8/22 18:46, Frank Ch. Eigler wrote: >> Demi Marie Obenour writes: >> >>> Three other options I can think of: >>> [...] >> >> Another one: >> >> 4. Speed up out-of-context backtracer(s), possibly consuming >> kernel-perf-ringbuffer stack dumps, or possibly using another >> event source to trigger and work via ptrace and /proc/$pid/mem >> >> - FChE > > Kernel stack dumps will not work for programs (such as OCaml 5.0) > that use segmented stacks. A userspace ptracer might work if it > is only woken up when absolutely necessary, but I suspect it would > be slow due to syscall overhead. That is why I suggested the vDSO > dumper: it would run from the process’s own context. I'm pretty sure most of the sysprof users are not interested in profiling OCaml programs. So that limitation should not block sysprof improvements, I think. 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Module-Package] PR #1: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Module-Package` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Module-Package/pull-request/1 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On Tue, 01 Nov 2022 11:26:13 - Daan De Meyer via devel wrote: > I've added a new section to the proposal with the benchmark results of some > benchmarks we performed against a Fedora 37 system built with frame pointers > and a regular Fedora 37 system. The impact on most benchmarks seems limited > aside from the CPython benchmark suite (pyperformance). See the proposal > itself for the details. what is the impact of the proposed change on non-x86 platforms? I assume the proposal focuses on x86, but the distro wide flags are shared across all platforms in Fedora, it means aarch64, ppc64le and s390x. With RISC-V waiting behind the door ... Thanks, Dan ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On Wed, Nov 09, 2022 at 04:26:23AM +, Naheem Zaffar wrote: > On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, < > devel@lists.fedoraproject.org> wrote: > > > On 08/11/2022 19:53, Naheem Zaffar wrote: > > > Has there been any consideration to turn on frame pointers for atleast > > > dev releases? > > > > Fedora has no dev releases. Mass rebuild is a huge pain for maintainers > > due to FTBFS issues, and doing it multiple times is unacceptable. > > > I think I explained the idea poorly. > > Not all builds in rawhide are release builds. You will get for instance the > whole gnome stack beta releases and rc releases during development. Note it is not a free for all. The rawhide guidelines indicate that FESCO approves the shipping of beta/rc releases for low level components[1]. The pre-release packages are still expected to be of high enough quality that they are usable in the normal way. If anything I'd say that kernel is already not in compliance with the rawhide guidelines. The combination of the large number of debug options enabled has gradually slowed the kernel down enough, that it is no longer usable for some use cases. We don't want to extend this slowdown still further > It's not a silver bullet solution but atleast it starts things off on a > path where profiling can be done in a limited manner compared to the other > proposed alternatives where the tooling doesnt exist and will likely not > ever be written. Rawhide is somewhere to get integrated testing of software setup / combinations we are expecting to ship in the next release. It shouldn't be used to run experiments where we don't have confidence in our intent to ship the result. With regards, Daniel [1] https://docs.fedoraproject.org/en-US/releases/rawhide/ -- |: 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On 11/9/22 10:08, Panu Matilainen wrote:
On 11/8/22 21:45, Adam Williamson wrote:
On Tue, 2022-11-08 at 08:11 -0800, Adam Williamson wrote:
On Tue, 2022-11-08 at 13:32 +0200, Panu Matilainen wrote:
But I don't know the slightest thing about ansible, beyond a very rough
idea of what kind of tool it is. Just understanding what exactly it's
trying to do here would go a long way, I think. But either it's not in
the logs, or I don't know how to read them.
well, to expand on my previous answer, it gets a bit interesting. At
this point in the process the CI system has installed the packages to
be tested and verified that they're installed, which implies RPM does
at least basically work or else that would have failed. you can see
this in these logs:
https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/guest-setup-554c73be-c472-4007-9f14-23eea462c69d/artifact-installation-554c73be-c472-4007-9f14-23eea462c69d/
then it hands off to ansible to actually 'run the tests', and that's
when the error happens. I believe it happens here in ansible's code:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/dnf.py#L1366
so that may help you figure it out. I'd look further but I have to run
out right now...
well, I'm back now. Looking into it a bit further, I think the codepath
we're on compresses to this, where `self.base` is a DNF base object:
self.base.upgrade_all()
try:
self.base.resolve(allow_erasing=self.allowerasing)
[cut internal stuff that couldn't raise a DNF error]
for package in self.base.transaction.install_set:
fail = False
gpgres, gpgerr = self.base._sig_check_pkg(package)
[cut more stuff that couldn't raise the error]
self.base.do_transaction()
except dnf.exceptions.Error as e:
failure_response['msg'] = "Unknown Error occurred:
{0}".format(to_native(e))
self.module.fail_json(**failure_response)
I'm pretty sure that's the path we're on, and "An rpm exception
occurred: package not installed" is the text of a dnf.exceptions.Error
exception that's raised by one of those actions that actually involves
the DNF base object (I cut stuff that doesn't involve it, and one
branch where we'd do something different if we hit a
dnf.exceptions.Error). Next step would be to see why dnf is throwing
that error, I guess. It'd be nice if it said *what* package it thinks
is "not installed"...
Indeed. It is an exceptional situation though.
Anyway, Maxwell G's PR showed that it is indeed a weak signature
someplace (thanks again!), and with clues learned from that I could
debug it further on my own.
https://artifacts.dev.testing-farm.io/a1c1cc94-0f2b-41f0-a0c2-2456dd50359a/work-tests.ymllY4cuv/ansible-output.txt
and the smoking gun is here:
494 python3-koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
495 koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
Despite the fc38 disttag, this is not the koji package from Fedora
rawhide, the real rawhide version is koji-1.30.1-2.fc38 and *that* is
signed with RSA/SHA256. What the heck?
Time to file a ticket someplace. Rel-eng, I suppose?
Filed https://pagure.io/fedora-ci/general/issue/371
- Panu -
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On 09/11/2022 05:26, Naheem Zaffar wrote: Not all builds in rawhide are release builds. You will get for instance the whole gnome stack beta releases and rc releases during development. To achieve the goal, you must rebuild every single package in a dependency tree, including such important packages as glibc, libstdc++, etc. According to tests, this will slow down your system to 2.5%+, which is unacceptable for a general purpose distribution. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On 11/8/22 21:45, Adam Williamson wrote:
On Tue, 2022-11-08 at 08:11 -0800, Adam Williamson wrote:
On Tue, 2022-11-08 at 13:32 +0200, Panu Matilainen wrote:
But I don't know the slightest thing about ansible, beyond a very rough
idea of what kind of tool it is. Just understanding what exactly it's
trying to do here would go a long way, I think. But either it's not in
the logs, or I don't know how to read them.
well, to expand on my previous answer, it gets a bit interesting. At
this point in the process the CI system has installed the packages to
be tested and verified that they're installed, which implies RPM does
at least basically work or else that would have failed. you can see
this in these logs:
https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/guest-setup-554c73be-c472-4007-9f14-23eea462c69d/artifact-installation-554c73be-c472-4007-9f14-23eea462c69d/
then it hands off to ansible to actually 'run the tests', and that's
when the error happens. I believe it happens here in ansible's code:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/dnf.py#L1366
so that may help you figure it out. I'd look further but I have to run
out right now...
well, I'm back now. Looking into it a bit further, I think the codepath
we're on compresses to this, where `self.base` is a DNF base object:
self.base.upgrade_all()
try:
self.base.resolve(allow_erasing=self.allowerasing)
[cut internal stuff that couldn't raise a DNF error]
for package in self.base.transaction.install_set:
fail = False
gpgres, gpgerr = self.base._sig_check_pkg(package)
[cut more stuff that couldn't raise the error]
self.base.do_transaction()
except dnf.exceptions.Error as e:
failure_response['msg'] = "Unknown Error occurred:
{0}".format(to_native(e))
self.module.fail_json(**failure_response)
I'm pretty sure that's the path we're on, and "An rpm exception
occurred: package not installed" is the text of a dnf.exceptions.Error
exception that's raised by one of those actions that actually involves
the DNF base object (I cut stuff that doesn't involve it, and one
branch where we'd do something different if we hit a
dnf.exceptions.Error). Next step would be to see why dnf is throwing
that error, I guess. It'd be nice if it said *what* package it thinks
is "not installed"...
Indeed. It is an exceptional situation though.
Anyway, Maxwell G's PR showed that it is indeed a weak signature
someplace (thanks again!), and with clues learned from that I could
debug it further on my own.
https://artifacts.dev.testing-farm.io/a1c1cc94-0f2b-41f0-a0c2-2456dd50359a/work-tests.ymllY4cuv/ansible-output.txt
and the smoking gun is here:
494 python3-koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
495 koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
Despite the fc38 disttag, this is not the koji package from Fedora
rawhide, the real rawhide version is koji-1.30.1-2.fc38 and *that* is
signed with RSA/SHA256. What the heck?
Time to file a ticket someplace. Rel-eng, I suppose?
- Panu -
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
