[Bug 2153171] New: perl-DateTime-TimeZone-2.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2153171 Bug ID: 2153171 Summary: perl-DateTime-TimeZone-2.57 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-TimeZone Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.57 Upstream release that is considered latest: 2.57 Current version/release in rawhide: 2.56-1.fc38 URL: http://metacpan.org/dist/DateTime-TimeZone/ 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/2801/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-DateTime-TimeZone -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2153171 ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14 libbsd-0.11.7-2.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0b26ab3924 xrdp-0.9.21-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing apptainer-1.1.4-1.el7 gfal2-2.21.2-1.el7 nut-2.8.0-2.el7 rpki-client-8.2-1.el7 voms-api-java-3.3.2-11.el7 Details about builds: apptainer-1.1.4-1.el7 (FEDORA-EPEL-2022-f2ddee605b) Application and environment virtualization Update Information: Update to 1.1.4 ChangeLog: * Tue Dec 13 2022 Dave Dykstra - 1.1.4 - Update to upstream 1.1.4. References: [ 1 ] Bug #2153084 - apptainer-1.1.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=2153084 gfal2-2.21.2-1.el7 (FEDORA-EPEL-2022-d386249793) Grid file access library 2.0 Update Information: Upstream release v2.21.2 ChangeLog: * Tue Dec 13 2022 Mihai Patrascoiu - 2.21.2-1 - Upgrade to upstream release 2.21.2 nut-2.8.0-2.el7 (FEDORA-EPEL-2022-582eba423d) Network UPS Tools Update Information: updated to 2.8.0 nut updated to 2.7.4 ChangeLog: * Tue Dec 6 2022 Michal Hlavinka - 2.8.0-2 - fix STATEPATH location and creation (#2024651) - merged C99 related changes to configure from fedora - trim changelog * Tue Sep 13 2022 Michal Hlavinka - 2.8.0-1 - update to 2.8.0 * Tue Jun 2 2020 Michal Hlavinka - 2.7.4-3 - update nut run directories * Tue May 26 2020 Orion Poplawski - 2.7.4-2 - Drop old udev requires/scriptlet - Add upstream patch for TLS > 1.0 support * Tue May 26 2020 Michal Hlavinka - 2.7.4-1 - nut updated to 2.7.4 References: [ 1 ] Bug #1379382 - nut package is missing nut-scanner binary https://bugzilla.redhat.com/show_bug.cgi?id=1379382 [ 2 ] Bug #1584330 - nut rpm has wrong mode and ownership for /var/run/nut https://bugzilla.redhat.com/show_bug.cgi?id=1584330 [ 3 ] Bug #1618784 - nut-monitor.service references non-existant /etc/tmpfiles.d/nut-run.conf https://bugzilla.redhat.com/show_bug.cgi?id=1618784 [ 4 ] Bug #1837120 - Update nut in EL7 https://bugzilla.redhat.com/show_bug.cgi?id=1837120 [ 5 ] Bug #1876035 - Update nut to latest stable release 2.7.4 https://bugzilla.redhat.com/show_bug.cgi?id=1876035 rpki-client-8.2-1.el7 (FEDORA-EPEL-2022-b460bd1076) OpenBSD RPKI validator to support BGP Origin Validation Update Information: # rpki-client 8.2- Add a new `-H` command line option to create a shortlist of repositories to synchronize to. For example, when invoking `rpki-client -H rpki.ripe.net -H chloe.sobornost.net`, the utility will not connect to any other hosts other than the two specified through the `-H` option. - Add support for validating Geofeed (RFC 9092) authenticators. To see an example download https://sobornost.net/geofeed.csv and run `rpki-client -f geofeed.csv`. - Add support for validating Trust Anchor Key (TAK) objects. TAK objects can be used to produce new Trust Anchor Locators (TALs) signed by and verified against the previous Trust Anchor. See draft-ietf-sidrops-signed-tal for the full specification. - Log lines related to RRDP/HTTPS connection problems now include the IP address of the problematic endpoint (in brackets). - Improve the error message when an invalid filename is encountered in the rpkiManifest field in the Subject Access Information (SIA) extension. - Emit a warning when unexpected X.509 extensions are encountered. - Restrict the ROA ipAddrBlocks field to only allow two ROAIPAddressFamily structures (one per address family). See draft-ietf-sidrops-rfc6482bis. - Check the
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-08012668ea libbsd-0.11.7-2.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-aaf428feb8 xrdp-0.9.21-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing apptainer-1.1.4-1.el8 featherpad-1.3.4-1.el8 gfal2-2.21.2-1.el8 gitqlient-1.6.1-1.el8 nut-2.8.0-3.el8 rpki-client-8.2-1.el8 Details about builds: apptainer-1.1.4-1.el8 (FEDORA-EPEL-2022-0da7c738b0) Application and environment virtualization Update Information: Update to 1.1.4 ChangeLog: * Tue Dec 13 2022 Dave Dykstra - 1.1.4 - Update to upstream 1.1.4. References: [ 1 ] Bug #2153084 - apptainer-1.1.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=2153084 featherpad-1.3.4-1.el8 (FEDORA-EPEL-2022-d73bffc164) Lightweight Qt5 Plain-Text Editor Update Information: update to 1.3.4 ChangeLog: * Mon Dec 12 2022 Jonathan Wright - 1.3.4-1 - Update to 1.3.4 rhbz#2149791 gfal2-2.21.2-1.el8 (FEDORA-EPEL-2022-8e0f3487cc) Grid file access library 2.0 Update Information: Upstream release v2.21.2 ChangeLog: * Tue Dec 13 2022 Mihai Patrascoiu - 2.21.2-1 - Upgrade to upstream release 2.21.2 gitqlient-1.6.1-1.el8 (FEDORA-EPEL-2022-9b4bbf7832) Multi-platform Git client written with Qt Update Information: Update to latest version ChangeLog: * Tue Dec 13 2022 Artem Polishchuk 1.6.1-1 - build: Update to 1.6.1 nut-2.8.0-3.el8 (FEDORA-EPEL-2022-4c006d97d3) Network UPS Tools Update Information: updated to 2.8.0 ChangeLog: * Mon Dec 12 2022 Michal Hlavinka - 2.8.0-3 - apply missing patch * Tue Dec 6 2022 Michal Hlavinka - 2.8.0-2 - fix STATEPATH location and creation (#2024651) - merged C99 related changes to configure from fedora * Tue Sep 13 2022 Michal Hlavinka - 2.8.0-1 - update to 2.8.0 * Tue Jun 2 2020 Michal Hlavinka - 2.7.4-27 - nut user needs tty group for wall (#1774591) References: [ 1 ] Bug #1774591 - Needs the tty group https://bugzilla.redhat.com/show_bug.cgi?id=1774591 [ 2 ] Bug #2024651 - /usr/lib/tmpfiles.d/nut-client.conf specifies /var/run/nut instead of /run/nut https://bugzilla.redhat.com/show_bug.cgi?id=2024651 rpki-client-8.2-1.el8 (FEDORA-EPEL-2022-1378b669e2) OpenBSD RPKI validator to support BGP Origin Validation Update Information: # rpki-client 8.2- Add a new `-H` command line option to create a shortlist of repositories to synchronize to. For example, when invoking `rpki-client -H rpki.ripe.net -H chloe.sobornost.net`, the utility will not connect to any other hosts other than the two specified through the `-H` option. - Add support for validating Geofeed (RFC 9092) authenticators. To see an example download https://sobornost.net/geofeed.csv and run `rpki-client -f geofeed.csv`. - Add support for validating Trust Anchor Key (TAK) objects. TAK objects can be used to produce new Trust Anchor Locators (TALs) signed by and verified against the previous
[EPEL-devel] Re: libssh2 epel vs rhel-8-for-x86_64-appstream-rpms
On Tue Dec 13, 2022 at 16:47 +0100, Leon Fauster via epel-devel wrote: Hi Leon, > I noticed that on a RHEL8 workstation the deprecated and removed package > from EL8.0 - libssh2, does not get substituted by the package from epel: > > libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64 > vs > libssh2-1.9.0-5.el8.x86_64 > > only possible with > > yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst* > > is this intentional? > > yum distrosync > > tries to install the obsolete version 1.8.0 again. > > How to solve this conflict? Its seems not to be a "module" problem > otherwise it would not install the epel version at all, right? Have you tried adding `module_hotfixes=true` [1] to the EPEL repo configuration file (/etc/yum.repos.d/epel.repo IIRC)? [1]: https://dnf.readthedocs.io/en/latest/modularity.html#hotfix-repositories -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a0c828a573 xrdp-0.9.21-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing apptainer-1.1.4-1.el9 farstream02-0.2.9-10.el9 featherpad-1.3.4-1.el9 gfal2-2.21.2-1.el9 gitqlient-1.6.1-1.el9 mujs-1.3.2-1.el9 nut-2.8.0-3.el9 python-authres-1.2.0-6.el9 python-collectd_cvmfs-1.3.3-6.el9 python-stevedore-4.0.2-1.el9 rpki-client-8.2-1.el9 rust-async-stream-0.3.3-1.el9 rust-async-stream-impl-0.3.3-1.el9 rust-curl-sys-0.4.59-1.el9 rust-futures-0.3.25-1.el9 rust-futures-channel-0.3.25-1.el9 rust-futures-core-0.3.25-1.el9 rust-futures-executor-0.3.25-1.el9 rust-futures-io-0.3.25-1.el9 rust-futures-macro-0.3.25-1.el9 rust-futures-sink-0.3.25-1.el9 rust-futures-task-0.3.25-1.el9 rust-futures-test-0.3.25-1.el9 rust-futures-util-0.3.25-1.el9 rust-no-panic-0.1.16-1.el9 rust-parking_lot_core0.8-0.8.6-1.el9 rust-paste-1.0.10-1.el9 rust-ref-cast-1.0.13-1.el9 rust-ref-cast-impl-1.0.13-1.el9 rust-regex-1.7.0-1.el9 rust-regex-syntax-0.6.28-1.el9 rust-serde-1.0.150-1.el9 rust-serde_derive-1.0.150-1.el9 rust-serde_test-1.0.150-1.el9 voms-api-java-3.3.2-11.el9 Details about builds: apptainer-1.1.4-1.el9 (FEDORA-EPEL-2022-316b072dbf) Application and environment virtualization Update Information: Update to 1.1.4 ChangeLog: * Tue Dec 13 2022 Dave Dykstra - 1.1.4 - Update to upstream 1.1.4. References: [ 1 ] Bug #2153084 - apptainer-1.1.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=2153084 farstream02-0.2.9-10.el9 (FEDORA-EPEL-2022-a9b47a999c) Libraries for videoconferencing Update Information: Added epel9 branch ChangeLog: * Sat Dec 10 2022 Stefan Becker - 0.2.9-10 - Rebuilt for gupnp-igd SONAME change (#2152301) * Thu Jul 21 2022 Fedora Release Engineering - 0.2.9-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 0.2.9-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Wed Jul 21 2021 Fedora Release Engineering - 0.2.9-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Sun Apr 4 2021 Stefan Becker - 0.2.9-6 - add BR gtk-doc (#1943073) * Thu Mar 4 2021 Tim Landscheidt - 0.2.9-5 - Fix mangled URL * Tue Jan 26 2021 Fedora Release Engineering - 0.2.9-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild References: [ 1 ] Bug #2101042 - Add farstream02 to epel9 https://bugzilla.redhat.com/show_bug.cgi?id=2101042 featherpad-1.3.4-1.el9 (FEDORA-EPEL-2022-7061872ee4) Lightweight Qt5 Plain-Text Editor Update Information: update to 1.3.4 ChangeLog: * Mon Dec 12 2022 Jonathan Wright - 1.3.4-1 - Update to 1.3.4 rhbz#2149791 gfal2-2.21.2-1.el9 (FEDORA-EPEL-2022-941296526f) Grid file access library 2.0 Update Information: Upstream release v2.21.2 ChangeLog: * Tue Dec 13 2022 Mihai Patrascoiu - 2.21.2-1 - Upgrade to upstream release 2.21.2 gitqlient-1.6.1-1.el9 (FEDORA-EPEL-2022-b3542d80b9) Multi-platform Git client written with Qt Update Information: Update to latest version
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
> Anyway, the effort that > went into that change proposal has established new expectations for any > change that will > impact system performance: the new flags should be benchmarked in an > environment where all > Fedora packages have been rebuilt with the new flags, so we can critique the > change based > on benchmarks that are not representative of real-world usage and reject it > if they show a > 2% performance hit, regardless of value to Fedora. If you don't like the idea > of > rebuilding all packages with the new flags, then maybe it was a mistake to > require > developers to do just that if they want to profile applications successfully. So I was quite upset when I wrote the above mail, seeing a new change proposal that admits it adds register pressure a few days after the frame pointer proposal was rejected for adding register pressure. Probably I should not send mails when angry. I don't actually support requiring the proposal authors to do the above work. `_FORTIFY_SOURCE=3` seems certain to make Fedora users safer. Regardless of what happened to the frame pointer proposal, it wouldn't make sense to block it from benefiting Fedora users. If we were politicians, then it would totally make sense to block Other Team's proposal unless Our Team's proposal gets accepted. (I support Team Frame Pointer. ;) But Fedora change proposals should not operate that way. (We all support Team Fedora here, after all.) This should go through. One more note regarding frame pointers. The `_FORTIFY_SOURCE=3` change proposal says "Per-application performance benchmarks may be useful in understanding the impact for those specific use cases." But this is not useful at all without an actionable way to figure out where performance problems are occurring, which requires functional profiling tools, which require frame pointers. Thank you _very much_ Neal, Fabio, and Zbigniew for your efforts to revisit that decision. ___ 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 10:41 AM Siddhesh Poyarekar wrote: > > On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster > wrote: > > > > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar > > wrote: > > > > > My full comment in that blog post is: > > > > > > "We need a proper study of performance and code size to understand the > > > magnitude of the impact created by _FORTIFY_SOURCE=3 additional > > > runtime code generation. However the performance and code size > > > overhead may well be worth it due to the magnitude of improvement in > > > security coverage." > > > > The key word is *MAY*. That is not considered > > to be a conclusion supported by the evidence > > presented (at least in any scientific paper I > > have reviewed). > > I have added a performance note[1] in the proposal. SPEC2000 and SPEC2017 results with _FORTIFY_SOURCE=2 vs _FORTIFY_SOURCE=3 show practically no difference in performance. I have updated the wiki to note this and the fact that this should alleviate any concerns of a general slowdown. However I do request package maintainers to report any slowdown they experience due to building with _FORTIFY_SOURCE=3 so that we get a better understanding. Always happy to help keep performance up to par even as we improve security mitigations. Thanks, Sid ___ 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
xen soname bump with 4.17.0 release
I have built an update of xen to the 4.17.0 release on rawhide in the f38-build-side-61077 side tag. I believe that the qemu and libvirt packages will need to be rebuilt due to the version change on some of the xen libraries. Michael Young ___ 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 2083148] CVE-2018-25033 slic3r: admesh: heap-buffer-overflow in stl_update_connects_remove_1() of src/connect.c [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2083148 Ben Cotton changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL Last Closed||2022-12-13 17:57:15 --- Comment #3 from Ben Cotton --- Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083148 ___ 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 2083145] CVE-2018-25033 admesh: heap-buffer-overflow in stl_update_connects_remove_1() of src/connect.c
https://bugzilla.redhat.com/show_bug.cgi?id=2083145 Bug 2083145 depends on bug 2083146, which changed state. Bug 2083146 Summary: CVE-2018-25033 admesh: heap-buffer-overflow in stl_update_connects_remove_1() of src/connect.c [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2083146 What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083145 ___ 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-Net-CardDAVTalk] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Net-CardDAVTalk` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Net-CardDAVTalk/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
[EPEL-devel] Re: claws-mail for EPEL-9
On Tue, 13 Dec 2022 09:56:40 -0800 Troy Dawson wrote: > Packages do not automatically get transferred over from epel7 to a newer > epel. People have to request them. > Nobody has requested it for epel9. > https://docs.fedoraproject.org/en-US/epel/epel-package-request/ yeah, I know the process :-) It is an attempt to avoid duplication of efforts in case someone else has been looking into it earlier or if I should start opening the bugs. Dan > > On Tue, Dec 13, 2022 at 9:15 AM Dan Horák wrote: > > > Hi, > > > > isn't anybody already working on getting claws-mail to EPEL-9? My > > initial assessment shows that it shouldn't be difficult > > - add libetpan and ytnef, they are the missing BRs, both build OK from > > fedora spec, neither is in RHEL > > - add claws-mail, with some little tweaks it can use its fedora spec > > > > > > Dan > > ___ > > 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 > > ___ 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 2083145] CVE-2018-25033 admesh: heap-buffer-overflow in stl_update_connects_remove_1() of src/connect.c
https://bugzilla.redhat.com/show_bug.cgi?id=2083145 Bug 2083145 depends on bug 2083148, which changed state. Bug 2083148 Summary: CVE-2018-25033 slic3r: admesh: heap-buffer-overflow in stl_update_connects_remove_1() of src/connect.c [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2083148 What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083145 ___ 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
[EPEL-devel] Re: claws-mail for EPEL-9
Packages do not automatically get transferred over from epel7 to a newer epel. People have to request them. Nobody has requested it for epel9. https://docs.fedoraproject.org/en-US/epel/epel-package-request/ On Tue, Dec 13, 2022 at 9:15 AM Dan Horák wrote: > Hi, > > isn't anybody already working on getting claws-mail to EPEL-9? My > initial assessment shows that it shouldn't be difficult > - add libetpan and ytnef, they are the missing BRs, both build OK from > fedora spec, neither is in RHEL > - add claws-mail, with some little tweaks it can use its fedora spec > > > Dan > ___ > 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 > ___ 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 2064173] CVE-2021-44961 slic3r: specially crafted stl files can exhaust available memory [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2064173 Ben Cotton changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL Last Closed||2022-12-13 17:01:26 --- Comment #3 from Ben Cotton --- Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2064173 ___ 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-Net-CardDAVTalk] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Net-CardDAVTalk` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Net-CardDAVTalk/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: Summary/Minutes for today's FESCo meeting (2022-12-13)
On Tue, Dec 13, 2022 at 12:31:59PM -0500, David Cantrell wrote: > Action Items > > * mhroncok will chair next meeting The next FESCo meeting will be January 3, 2023. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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
Summary/Minutes for today's FESCo meeting (2022-12-13)
=== #fedora-meeting: FESCO (2022-12-13) === Meeting started by dcantrell at 16:59:17 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2022-12-13/fesco.2022-12-13-16.59.log.html -- The agenda email for today's meeting incorrectly listed closed FESCo tickets in the Followups section. These should have been in the Discussed and Voted in the Ticket section and should have included the final vote. Here is the corrected information: = Discussed and Voted in the Ticket = #2909 Change: LLVM 16 https://pagure.io/fesco/issue/2909 APPROVED (+5,0,-0) #2908 Change: Add Fedora Auto Firstboot Services to desktop variants https://pagure.io/fesco/issue/2908 APPROVED (+5,0,-0) #2906 Change: Remove Guile Support from GDB https://pagure.io/fesco/issue/2906 APPROVED (+8, 0, 0) #2901 Change: Build Fedora Silverblue & Kinoite using rpm-ostree unified core mode https://pagure.io/fesco/issue/2901 APPROVED (+3,0,-0) #2883 Change: Ostree Native Container (Phase 2, stable) https://pagure.io/fesco/issue/2883 APPROVED (+4,0,-0) -- Meeting summary --- * init process (dcantrell, 16:59:35) * #2911 Review removal of ncurses-compat-libs (dcantrell, 17:01:53) * Marked as stalled until we can get feedback from the ncurses package maintainer. * Next week's chair (dcantrell, 17:06:29) * ACTION: mhroncok will chair next meeting (dcantrell, 17:08:16) * Open Floor (dcantrell, 17:08:31) Meeting ended at 17:19:24 UTC. Action Items * mhroncok will chair next meeting Action Items, by person --- * mhroncok * mhroncok will chair next meeting People Present (lines said) --- * dcantrell (49) * mhroncok (24) * zodbot (16) * Eighth_Doctor (8) * decathorpe (7) * zbyszek (7) * mhayden (6) * music[m] (4) * nirik (0) * sgallagh (0) * music (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * Son_Goku (0) * King_InuYasha (0) * Sir_Gallantmon (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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] claws-mail for EPEL-9
Hi, isn't anybody already working on getting claws-mail to EPEL-9? My initial assessment shows that it shouldn't be difficult - add libetpan and ytnef, they are the missing BRs, both build OK from fedora spec, neither is in RHEL - add claws-mail, with some little tweaks it can use its fedora spec Dan ___ 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 2064172] CVE-2021-44961 slic3r: specially crafted stl files can exhaust available memory
https://bugzilla.redhat.com/show_bug.cgi?id=2064172 Bug 2064172 depends on bug 2064173, which changed state. Bug 2064173 Summary: CVE-2021-44961 slic3r: specially crafted stl files can exhaust available memory [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2064173 What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2064172 ___ 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 2046373] CVE-2021-45847 slic3r: NULL pointer dereference in 3MF XML via a crafted 3MF input file [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2046373 Ben Cotton changed: What|Removed |Added Resolution|--- |EOL Status|NEW |CLOSED Last Closed||2022-12-13 16:27:58 --- Comment #3 from Ben Cotton --- Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2046373 ___ 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 2046372] CVE-2021-45847 slic3r: NULL pointer dereference in 3MF XML via a crafted 3MF input file
https://bugzilla.redhat.com/show_bug.cgi?id=2046372 Bug 2046372 depends on bug 2046373, which changed state. Bug 2046373 Summary: CVE-2021-45847 slic3r: NULL pointer dereference in 3MF XML via a crafted 3MF input file [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2046373 What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2046372 ___ 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 2152966] New: perl-PPIx-Regexp-0.086 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2152966 Bug ID: 2152966 Summary: perl-PPIx-Regexp-0.086 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PPIx-Regexp Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.086 Upstream release that is considered latest: 0.086 Current version/release in rawhide: 0.085-4.fc38 URL: http://search.cpan.org/dist/PPIx-Regexp/ 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/3288/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-PPIx-Regexp -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2152966 ___ 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 2035341] CVE-2020-16154 perl-App-cpanminus: Bypass of verification of signatures in CHECKSUMS files
https://bugzilla.redhat.com/show_bug.cgi?id=2035341 Bug 2035341 depends on bug 2037407, which changed state. Bug 2037407 Summary: CVE-2020-16154 perl-Menlo-Legacy: perl-App-cpanminus: Bypass of verification of signatures in CHECKSUMS files [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=2037407 What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2035341 ___ 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
F38 proposal: Use mdadm for BIOS RAID Support in Anaconda (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/UseMdadmForBIOSRAIDInAnaconda This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Use mdadm instead of dmraid to support BIOS RAID (Firmware RAID or Fake RAID) during the Fedora installation process. == Owner == * Name: [[User:vtrefny| Vojtech Trefny]] (Blivet) * Email: vtrefny AT redhat.com * Name: [[User:vponcova|Vendula Poncova]] (Anaconda) * Email: vponcova AT redhat.com == Detailed Description == [[Anaconda]] (or to be more precise [[Blivet]], the storage library Anaconda uses) is currently using dmraid to support the BIOS RAID devices (sometimes also called Firmware or BIOS RAID) during installation. We plan to replace dmraid by mdadm, which we are currently using for software RAID management. The main reason is that dmraid is no longer actively maintained. mdadm supports the two major BIOS RAID technologies: Common RAID Disk Data Format (DDF) [https://www.snia.org/tech_activities/standards/curr_standards/ddf standard by SNIA] and [https://www.intel.com/content/www/us/en/support/products/122484/memory-and-storage/datacenter-storage-solutions/intel-virtual-raid-on-cpu-intel-vroc.html Intel Matrix Storage Manager] format. mdadm is missing support for some older BIOS RAID formats that existed before DDF and are still supported by dmraid so by implementing this change, we will remove support for some BIOS RAID formats from the installer. == Feedback == We tried to [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/A6G5HTBXXIDQUMYBCILU264ZLEWF75ND/ get feedback from the community] to find out how many users use BIOS RAID and would be affected by this change (especially by removing support for the older formats). The only response was from the Fedora QA which has an Intel Matrix machine for testing which should be supported by mdadm. == Benefit to Fedora == Replacing a tool/library that is no longer being actively developed and maintained. Because we are replacing it with a tool that is currently used for software RAID management in the installer, this also means removing one dependency from the installer environment and remove the dmraid startup service from the installed system. == Scope == * Proposal owners: Changes to Blivet (replacing dmraid with mdadm for the specified BIOS RAID formats) and Anaconda (removing the `inst.nodmraid` flag) * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change will affect only new installations (the change only changes behaviour of the installer). == How To Test == A hardware with BIOS RAID support (DDF or IMSM) is required. (Creating a "fake" BIOS RAID with mdadm might be possible for testing, we'll add steps for testing without the hardware later (if possible).) Follow the test case for installing on BIOS/Firmware RAID: [[QA:Testcase_install_to_firmware_RAID]]. == User Experience == Users with supported BIOS RAIDs shouldn't notice a change, the installation should work the same for them. Users with older unsupported BIOS RAID formats won't be able to install Fedora on these arrays. For these users we'll recommend switching to software RAID. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the changes and keep using dmraid for all BIOS RAID formats. * Contingency deadline: Beta * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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
F38 proposal: Use mdadm for BIOS RAID Support in Anaconda (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/UseMdadmForBIOSRAIDInAnaconda This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Use mdadm instead of dmraid to support BIOS RAID (Firmware RAID or Fake RAID) during the Fedora installation process. == Owner == * Name: [[User:vtrefny| Vojtech Trefny]] (Blivet) * Email: vtrefny AT redhat.com * Name: [[User:vponcova|Vendula Poncova]] (Anaconda) * Email: vponcova AT redhat.com == Detailed Description == [[Anaconda]] (or to be more precise [[Blivet]], the storage library Anaconda uses) is currently using dmraid to support the BIOS RAID devices (sometimes also called Firmware or BIOS RAID) during installation. We plan to replace dmraid by mdadm, which we are currently using for software RAID management. The main reason is that dmraid is no longer actively maintained. mdadm supports the two major BIOS RAID technologies: Common RAID Disk Data Format (DDF) [https://www.snia.org/tech_activities/standards/curr_standards/ddf standard by SNIA] and [https://www.intel.com/content/www/us/en/support/products/122484/memory-and-storage/datacenter-storage-solutions/intel-virtual-raid-on-cpu-intel-vroc.html Intel Matrix Storage Manager] format. mdadm is missing support for some older BIOS RAID formats that existed before DDF and are still supported by dmraid so by implementing this change, we will remove support for some BIOS RAID formats from the installer. == Feedback == We tried to [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/A6G5HTBXXIDQUMYBCILU264ZLEWF75ND/ get feedback from the community] to find out how many users use BIOS RAID and would be affected by this change (especially by removing support for the older formats). The only response was from the Fedora QA which has an Intel Matrix machine for testing which should be supported by mdadm. == Benefit to Fedora == Replacing a tool/library that is no longer being actively developed and maintained. Because we are replacing it with a tool that is currently used for software RAID management in the installer, this also means removing one dependency from the installer environment and remove the dmraid startup service from the installed system. == Scope == * Proposal owners: Changes to Blivet (replacing dmraid with mdadm for the specified BIOS RAID formats) and Anaconda (removing the `inst.nodmraid` flag) * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change will affect only new installations (the change only changes behaviour of the installer). == How To Test == A hardware with BIOS RAID support (DDF or IMSM) is required. (Creating a "fake" BIOS RAID with mdadm might be possible for testing, we'll add steps for testing without the hardware later (if possible).) Follow the test case for installing on BIOS/Firmware RAID: [[QA:Testcase_install_to_firmware_RAID]]. == User Experience == Users with supported BIOS RAIDs shouldn't notice a change, the installation should work the same for them. Users with older unsupported BIOS RAID formats won't be able to install Fedora on these arrays. For these users we'll recommend switching to software RAID. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the changes and keep using dmraid for all BIOS RAID formats. * Contingency deadline: Beta * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: libssh2 epel vs rhel-8-for-x86_64-appstream-rpms
On Tue, 13 Dec 2022 at 10:47, Leon Fauster via epel-devel < epel-devel@lists.fedoraproject.org> wrote: > I noticed that on a RHEL8 workstation the deprecated and removed package > from EL8.0 - libssh2, does not get substituted by the package from epel: > > libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64 > vs > libssh2-1.9.0-5.el8.x86_64 > > only possible with > > yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst* > > is this intentional? > > yum distrosync > > tries to install the obsolete version 1.8.0 again. > > How to solve this conflict? Its seems not to be a "module" problem > otherwise it would not install the epel version at all, right? > > The package was in 2 module releases virt-devel:rhel:820190828150510:f8e95b4e:x86_64 virt-devel:rhel:820190226174025:9edba152:x86_64 and then removed from all later modules: virt-devel:rhel:8010020190916153839:cdc1202b:x86_64 so by October of 2019, it was no longer in the OS. So I would assume a distrosync would remove it for that reason. The libssh2-1.9.0 was added to EPEL because of the removal of 1.8.0 in RHEL and 1.9.0 being supportable. -- > Leon > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2022-12-14 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/ ___ 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
[EPEL-devel] libssh2 epel vs rhel-8-for-x86_64-appstream-rpms
I noticed that on a RHEL8 workstation the deprecated and removed package from EL8.0 - libssh2, does not get substituted by the package from epel: libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64 vs libssh2-1.9.0-5.el8.x86_64 only possible with yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst* is this intentional? yum distrosync tries to install the obsolete version 1.8.0 again. How to solve this conflict? Its seems not to be a "module" problem otherwise it would not install the epel version at all, right? -- Leon ___ 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 1971453] perl-Crypt-RandPasswd-0.06-17.fc35 FTBFS randomly: t/01-word.t: Use of uninitialized value $last_unit in hash element at Crypt-RandPasswd-0.06/blib/lib/Crypt/RandPasswd.pm line 2205
https://bugzilla.redhat.com/show_bug.cgi?id=1971453 Ben Cotton changed: What|Removed |Added Resolution|--- |EOL Status|NEW |CLOSED Last Closed||2022-12-13 15:25:06 --- Comment #3 from Ben Cotton --- Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1971453 ___ 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: Fedora/CentOS planned outage 2022-12-08 19:00 UTC
On Wed, 7 Dec 2022 at 11:37, Stephen Smoogen wrote: > > Due to some issues, this "lanned" outage has to be delayed to 2022-12-13 > at the same time. > > Due to additional timing issues, the planned outage has been moved to 2023-01-10 at the same time. Updates and more information will be added to https://pagure.io/fedora-infrastructure/issue/11031 > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[rpms/perl-Module-Manifest-Skip] PR #2: Remove obsolete code
mspacek merged a pull-request against the project: `perl-Module-Manifest-Skip` that you are following. Merged pull-request: `` Remove obsolete code `` https://src.fedoraproject.org/rpms/perl-Module-Manifest-Skip/pull-request/2 ___ 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: Fedora/CentOS planned outage 2022-12-08 19:00 UTC
On Wed, 7 Dec 2022 at 11:37, Stephen Smoogen wrote: > > Due to some issues, this "lanned" outage has to be delayed to 2022-12-13 > at the same time. > > Due to additional timing issues, the planned outage has been moved to 2023-01-10 at the same time. Updates and more information will be added to https://pagure.io/fedora-infrastructure/issue/11031 > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. > -- Ian MacClaren > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
Updating python-ezdxf to 1.0.0 in Rawhide with minor breaking changes
In one week (2022-12-20), or slightly later, I will update python-ezdxf to 1.0.0 in Rawhide.[1] This release contains some minor breaking changes[2][3]; the only dependent package is python-trimesh[4], and I have verified it is already compatible with the new release. [1] https://src.fedoraproject.org/rpms/python-ezdxf/pull-request/2 [2] https://github.com/mozman/ezdxf/blob/v1.0.0/NEWS.md#version-100---2022-12-09 [3] https://ezdxf.mozman.at/release-v1-0.html [4] https://src.fedoraproject.org/rpms/python-trimesh ___ 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: python-lockfile deprecation
Deprecating a non-leaf package does technically require a FESCo approved Change[1]. Considering the upstream project has been archived since 2017 and deprecated since 2015, I would certainly favor deprecating python-lockfile in Fedora. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_prerequisites_for_deprecation On 12/13/22 00:06, Carl George wrote: Howdy Python SIG and python-lockfile maintainers, I recently noticed that pylockfile (packaged as python-lockfile in Fedora and EPEL) is no longer maintained upstream (since 2017). https://github.com/openstack-archive/pylockfile I see 10 packages that still (build)require this, so retirement is probably premature, but is anyone opposed to me marking the package as deprecated so that new packages can't (build)require it? https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ ___ 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
[EPEL-devel] Re: 'perl-Net-Domain-TLD' pkg maintainer needed for EPEL9 build
On Mon, Dec 12, 2022 at 7:35 AM Vladimir Pachnik < vladimir.pach...@gooddata.com> wrote: > would anyone be able to take over the build of 'perl-Net-Domain-TLD' package for EPEL9 as per https://bugzilla.redhat.com/show_bug.cgi?id=2144550 ? For those who are wondering, The fedora package builds and installs without any modifications. No extra dependencies to take care of. ___ 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
[rpms/perl-Net-CalDAVTalk] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Net-CalDAVTalk` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Net-CalDAVTalk/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-Manifest-Skip] PR #2: Remove obsolete code
mspacek opened a new pull-request against the project: `perl-Module-Manifest-Skip` that you are following: `` Remove obsolete code `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Module-Manifest-Skip/pull-request/2 ___ 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 35 is End of Life
Hello all, As of the 13th of December 2022, Fedora 35 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 35 after the said date. All the updates of Fedora 35 being pushed to stable will be stopped as well. Fedora 36 will continue to receive updates until approximately one month after the release of Fedora 38. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Regards, Tomas Hrcka Fedora Release Engineering [0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades ___ 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 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
Fedora 35 is End of Life
Hello all, As of the 13th of December 2022, Fedora 35 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 35 after the said date. All the updates of Fedora 35 being pushed to stable will be stopped as well. Fedora 36 will continue to receive updates until approximately one month after the release of Fedora 38. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Regards, Tomas Hrcka Fedora Release Engineering [0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades ___ 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
[rpms/perl-Net-CalDAVTalk] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Net-CalDAVTalk` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Net-CalDAVTalk/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
Strange maven build problem in jackson packages
Hello all! I recently took over maintaining the Jackson serialisation packages in Fedora and I am rebasing them to the latest upstream version in a side-tag: https://koji.fedoraproject.org/koji/builds?userID=ckelley=60533. I am experiencing curious difficulties I am hoping someone may be able to shed light on! Before attempting this update in Rawhide, I performed the update in copr: https://copr.fedorainfracloud.org/coprs/ckelley/pki/packages/ This, after a bit of trial-and-error, was successful - and these packages are now being used successfully in the upstream CI for various packages. All good. Then, I attempted the same in Rawhide. The first 3 packages in the side-tag (FYI first time side-tagging) build fine, but jackson-annotations does not: https://koji.fedoraproject.org/koji/taskinfo?taskID=95305556 The failure is strange as the dep that provides the code to understand bundle packaging is present (and it works in copr). After a bit of frustration I stopped to focus on performing the same update in CentOS 9 Stream, from the same sources. This update too was successful (eventually, first side-tag there too). The spec files are essentially identical between c9s and Rawhide, so I don't see an explanation there. Curiously, I submitted a later update to jackson-annotations in c9s and it now fails with the exact same packaging problem as occurs in Rawhide. That update contained only a RH internal test file, the sources and spec were untouched. My theory is that there is a dependency that was updated in Rawhide, which is problematic for my build, and that dep was recently updated in c9s and is now causing the same problem for me there. Has anyone seen anything like this before? How did you begin to investigate it? Or am I just being a side-tag noob? Any help at all appreciated, thanks! Chris ___ 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 rawhide compose report: 20221213.n.0 changes
OLD: Fedora-Rawhide-20221212.n.0 NEW: Fedora-Rawhide-20221213.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 12 Dropped packages:1 Upgraded packages: 115 Downgraded packages: 0 Size of added packages: 3.02 MiB Size of dropped packages:251.00 KiB Size of upgraded packages: 1.92 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 90.43 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20221213.n.0.s390x.tar.xz = DROPPED IMAGES = Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20221212.n.0.iso = ADDED PACKAGES = Package: oneapi-level-zero-1.8.8-1.fc38 Summary: OneAPI Level Zero Specification Headers and Loader RPMs:oneapi-level-zero oneapi-level-zero-devel Size:249.62 KiB Package: python-langdetect-1.0.9-2.fc38 Summary: Language detection library ported from Google's language-detection RPMs:python3-langdetect Size:898.06 KiB Package: python-oslo-service-3.0.0-6.fc38 Summary: Oslo service library RPMs:python-oslo-service-doc python3-oslo-service python3-oslo-service-tests Size:1.16 MiB Package: python-phply-1.2.5-3.fc38 Summary: PHP parser written in Python using PLY RPMs:python3-phply Size:142.02 KiB Package: python-pypresence-4.2.1-1.fc38 Summary: A Discord Rich Presence Client in Python RPMs:python3-pypresence Size:40.78 KiB Package: rust-dlv-list0.2-0.2.3-1.fc38 Summary: Semi-doubly linked list implemented using a vector RPMs:rust-dlv-list0.2+default-devel rust-dlv-list0.2-devel Size:26.15 KiB Package: rust-idna0.2-0.2.3-1.fc38 Summary: IDNA (Internationalizing Domain Names in Applications) and Punycode RPMs:rust-idna0.2+default-devel rust-idna0.2-devel Size:230.59 KiB Package: rust-libudev0.2-0.2.0-1.fc38 Summary: Rust wrapper for libudev RPMs:rust-libudev0.2+default-devel rust-libudev0.2-devel Size:24.40 KiB Package: rust-memoffset0.6-0.6.5-1.fc38 Summary: Offset_of functionality for Rust structs RPMs:rust-memoffset0.6+default-devel rust-memoffset0.6+unstable_const-devel rust-memoffset0.6-devel Size:29.49 KiB Package: rust-ordered-multimap0.3-0.3.1-1.fc38 Summary: Insertion ordered multimap RPMs:rust-ordered-multimap0.3+default-devel rust-ordered-multimap0.3+serde-devel rust-ordered-multimap0.3-devel Size:40.23 KiB Package: rust-rust-ini0.17-0.17.0-1.fc38 Summary: Ini configuration file parsing library in Rust RPMs:rust-rust-ini0.17+case-insensitive-devel rust-rust-ini0.17+default-devel rust-rust-ini0.17+inline-comment-devel rust-rust-ini0.17+unicase-devel rust-rust-ini0.17-devel Size:49.85 KiB Package: safeint-3.0.27-2.fc38 Summary: Class library for C++ that manages integer overflows RPMs:safeint-devel Size:176.93 KiB = DROPPED PACKAGES = Package: qextserialport-1.2-0.24.beta2.fc37 Summary: Qt interface class for old fashioned serial ports RPMs:qextserialport qextserialport-devel Size:251.00 KiB = UPGRADED PACKAGES = Package: Ri-li-2.0.1-35.fc38 Old package: Ri-li-2.0.1-34.fc37 Summary: Arcade game where you drive a toy wood engine RPMs: Ri-li Size: 57.40 MiB Size change: -2.24 KiB Changelog: * Mon Dec 12 2022 Florian Weimer - 2.0.1-35 - Port configure script to C99 Package: awscli-1.27.28-1.fc38 Old package: awscli-1.27.27-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.25 MiB Size change: 8.79 KiB Changelog: * Mon Dec 12 2022 Gwyn Ciesla - 1.27.28-1 - 1.27.28 Package: axmail-2.9-7.fc38 Old package: axmail-2.9-6.fc37 Summary: UROnode addon - an SMTP mailbox RPMs: axmail Size: 247.51 KiB Size change: -382 B Changelog: * Mon Dec 12 2022 Florian Weimer - 2.9-7 - Port to C99 Package: barcode-0.98-44.fc38 Old package: barcode-0.98-43.fc37 Summary: Generates barcodes from text strings RPMs: barcode barcode-devel Size: 584.43 KiB Size change: 2.35 KiB Changelog: * Mon Dec 12 2022 Florian Weimer - 0.98-44 - Port to C99 Package: bitcoin-core-24.0.1-1.fc38 Old package: bitcoin-core-24.0-1.fc38 Summary: Peer to Peer Cryptographic Currency RPMs: bitcoin-core-desktop bitcoin-core-devel bitcoin-core-libs bitcoin-core-server bitcoin-core-utils Size: 62.94 MiB Size change: 2.59 KiB Changelog: * Mon Dec 12 2022 Simone Caronni - 24.0.1-1 - Update to 24.0.1 Package: callaudiod-0.1.6-1.fc38 Old package: callaudiod-0.1.5-1.fc38 Summary: Daemon for dealing with audio routing during phone calls RPMs: callaudiod callaudiod-devel Size: 355.14 KiB Size change: 2.21 KiB Changelog: * Mon Dec 12 2022 Torrey Sorensen - 0.1.6-1 - Update to 0.1.6 Package: clearsilver-0.10.5-70.fc38 Old package: clearsilver
