[Bug 1953837] New: perl-PDL-2.040 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1953837 Bug ID: 1953837 Summary: perl-PDL-2.040 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PDL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jakub.jedel...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.040 Current version/release in rawhide: 2.39.0-1.fc35 URL: http://search.cpan.org/dist/PDL/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3205/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: KDE Autostart in F34
Ravindra Kumar wrote: > Hi, > > I hope there are some KDE experts on the list who can help me debug this - > https://bugzilla.redhat.com/show_bug.cgi?id=1953472. > > It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart > script in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work > fine. > > Could you please confirm if KDE supports autostart scripts from > /etc/xdg/autostart dir? If yes, is there a regression in F34? kde plasma on f34 uses systemd user session and systemd-xdg-autostart- generator, so yes, autostart is supported (but this new method has some quirks). I commented in the bug with some debugging steps to try. -- Rex ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Thoughts about packaging a standalone python-PyQt5-sip?
Scott Talbert wrote: > Yes, I got fairly far with porting all PyQt5 SIP consumers (including > calibre) to use SIPv5. I think I then got discouraged at the thought of > making a bunch of PRs and having to nag maintainers to merge them in some > sort of coordinated fashion. > > I guess - if I get everything working, would you be willing to merge a > bunch of related PRs as provenpackager and do rebuilds in a side tag? I'd be able and willing to assist here too, thanks for working on it! As far as sip6 goes, I'd venture the adjustment from v5 to v6 will be smaller than what v4 to v5 was. -- Rex ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1952554] Upgrade perl-Perl-MinimumVersion to 1.40
https://bugzilla.redhat.com/show_bug.cgi?id=1952554 --- Comment #2 from Ralf Corsepius --- (In reply to Paul Howarth from comment #1) > This is going to need a new package for PPIx::Utils. Thanks for the hint. Package submitted for review. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1952554] Upgrade perl-Perl-MinimumVersion to 1.40
https://bugzilla.redhat.com/show_bug.cgi?id=1952554 Ralf Corsepius changed: What|Removed |Added Depends On||1953817 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1953817 [Bug 1953817] Review Request: perl-PPIx-Utils - Utility functions for PPI -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #11 from Fedora Update System --- FEDORA-2021-e3d8833d36 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e3d8833d36` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e3d8833d36 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5b261a2216 nextcloud-client-3.1.3-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c18d19cbdc fluidsynth-2.1.8-3.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0754fdd085 openvpn-2.4.11-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-24ab212ee8 p7zip-16.02-20.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing afpfs-ng-0.8.1-35.el8 bgpq4-0.0.7-1.el8 google-benchmark-1.5.3-1.el8 lua-sec-1.0.1-1.el8 perl-Image-ExifTool-12.16-3.el8 pngcheck-2.4.0-8.el8 python-re-assert-1.1.0-1.el8 waiverdb-1.3.0-1.el8 Details about builds: afpfs-ng-0.8.1-35.el8 (FEDORA-EPEL-2021-a7cac9b814) Apple Filing Protocol client Update Information: modernize spec, push the bugfix to active branches ChangeLog: * Mon Apr 26 2021 Michal Ambroz - 0.8.1-35 - modernize spec, push the bugfix to active branches * Fri Mar 12 2021 Michal Ambroz - 0.8.1-34 - fix issue 1507944 * Mon Jan 25 2021 Fedora Release Engineering - 0.8.1-33 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jul 31 2020 Fedora Release Engineering - 0.8.1-32 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 0.8.1-31 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1507944 - afpcmd may crash on long options parsing https://bugzilla.redhat.com/show_bug.cgi?id=1507944 bgpq4-0.0.7-1.el8 (FEDORA-EPEL-2021-d62bad9a88) Automate BGP filter generation based on routing database information Update Information: bgpq4 0.0.7 === - Replace `AM_CONFIG_HEADER` bysuperseded `AC_CONFIG_HEADERS` - bgpq_expander: Increase the read select timeout to 30 seconds - Respect `-s` when there are no prefix lists - Multiple man page improvements - Arista EOS Support - Remove `select()`, use system default - Remove not-needed `shutdown()` - Revert conditional clauses around XR prefix list generation ChangeLog: * Mon Apr 26 2021 Robert Scheck 0.0.7-1 - Upgrade to 0.0.7 (#1953767) * Tue Jan 26 2021 Fedora Release Engineering - 0.0.6-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 0.0.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1953767 - bgpq4-0.0.7 is available https://bugzilla.redhat.com/show_bug.cgi?id=1953767 google-benchmark-1.5.3-1.el8 (FEDORA-EPEL-2021-ff299b2731) A microbenchmark support library Update Information: Updated to version 1.5.3. ChangeLog: * Mon Apr 26 2021 Vitaly Zaitsev - 1.5.3-1 - Updated to version 1.5.3. * Tue Jan 26 2021 Fedora Release Engineering - 1.5.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Oct 14 2020 Jeff Law - 1.5.2-2 - Fix missing #include for gcc-11 lua-sec-1.0.1-1.el8 (FEDORA-EPEL-2021-a017696c37) Lua binding for OpenSSL library Update Information: LuaSec 1.0.1 * Fix `luaL_buffinit()` can use the stack and broke `buffer_meth_receive()` ChangeLog: * Mon Apr 26 2021 Robert Scheck 1.0.1-1 - Upgrade to 1.0.1 (#1953695) References: [ 1 ] Bug #1953695 - lua-sec-1.0.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1953695
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #10 from Fedora Update System --- FEDORA-EPEL-2021-b308580516 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b308580516 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fe3075d537 wordpress-5.1.9-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-044df87bd4 rust-1.51.0-3.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3c8a5a400b p7zip-16.02-20.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a46e72f139 radare2-5.2.1-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3370d4396b ansible-2.9.20-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-255f12d77d zarafa-7.1.14-5.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing afpfs-ng-0.8.1-35.el7 bgpq4-0.0.7-1.el7 google-benchmark-1.5.3-1.el7 lua-sec-1.0.1-1.el7 perl-Image-ExifTool-12.16-3.el7 pngcheck-2.4.0-8.el7 Details about builds: afpfs-ng-0.8.1-35.el7 (FEDORA-EPEL-2021-0fab0cd8cf) Apple Filing Protocol client Update Information: modernize spec, push the bugfix to active branches ChangeLog: * Mon Apr 26 2021 Michal Ambroz - 0.8.1-35 - modernize spec, push the bugfix to active branches * Fri Mar 12 2021 Michal Ambroz - 0.8.1-34 - fix issue 1507944 * Mon Jan 25 2021 Fedora Release Engineering - 0.8.1-33 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jul 31 2020 Fedora Release Engineering - 0.8.1-32 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 0.8.1-31 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1507944 - afpcmd may crash on long options parsing https://bugzilla.redhat.com/show_bug.cgi?id=1507944 bgpq4-0.0.7-1.el7 (FEDORA-EPEL-2021-ed1bbec328) Automate BGP filter generation based on routing database information Update Information: bgpq4 0.0.7 === - Replace `AM_CONFIG_HEADER` bysuperseded `AC_CONFIG_HEADERS` - bgpq_expander: Increase the read select timeout to 30 seconds - Respect `-s` when there are no prefix lists - Multiple man page improvements - Arista EOS Support - Remove `select()`, use system default - Remove not-needed `shutdown()` - Revert conditional clauses around XR prefix list generation ChangeLog: * Mon Apr 26 2021 Robert Scheck 0.0.7-1 - Upgrade to 0.0.7 (#1953767) * Tue Jan 26 2021 Fedora Release Engineering - 0.0.6-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 0.0.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1953767 - bgpq4-0.0.7 is available https://bugzilla.redhat.com/show_bug.cgi?id=1953767 google-benchmark-1.5.3-1.el7 (FEDORA-EPEL-2021-64a2b2f0e4) A microbenchmark support library Update Information: Updated to version 1.5.3. ChangeLog: * Mon Apr 26 2021 Vitaly Zaitsev - 1.5.3-1 - Updated to version 1.5.3. * Tue Jan 26 2021 Fedora Release Engineering - 1.5.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Oct 14 2020 Jeff Law - 1.5.2-2 - Fix missing #include for gcc-11 lua-sec-1.0.1-1.el7 (FEDORA-EPEL-2021-c2c95de57a) Lua binding for OpenSSL library Update Information: LuaSec 1.0.1 * Fix `luaL_buffinit()` can use the stack and broke `buffer_meth_receive()` ChangeLog: * Mon Apr 26 2021 Robert Scheck 1.0.1-1 - Upgrade to 1.0.1 (#1953695) References: [ 1 ] Bug #1953695 - lua-sec-1.0.1
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #9 from Fedora Update System --- FEDORA-EPEL-2021-b6ffea264a has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b6ffea264a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #8 from Fedora Update System --- FEDORA-2021-88d24aa32b has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-88d24aa32b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-88d24aa32b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1918698] Upgrade perl-Image-ExifTool to 12.15
https://bugzilla.redhat.com/show_bug.cgi?id=1918698 --- Comment #6 from Fedora Update System --- FEDORA-2021-88d24aa32b has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-88d24aa32b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-88d24aa32b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1917309] Please include missing argument files in package
https://bugzilla.redhat.com/show_bug.cgi?id=1917309 --- Comment #10 from Fedora Update System --- FEDORA-2021-88d24aa32b has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-88d24aa32b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-88d24aa32b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #7 from Fedora Update System --- FEDORA-2021-de850ed71e has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-de850ed71e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-de850ed71e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1950578] perl-version-0.9929 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1950578 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-version-0.99.29-1.fc35 |perl-version-0.99.29-1.fc35 |perl-version-0.99.29-1.fc34 |perl-version-0.99.29-1.fc34 ||perl-version-0.99.29-1.fc33 --- Comment #6 from Fedora Update System --- FEDORA-2021-d684a57861 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1950700] perl-Pod-Weaver-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1950700 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Pod-Weaver-4.017-1.fc3 |perl-Pod-Weaver-4.017-1.fc3 |5 |5 ||perl-Pod-Weaver-4.017-1.fc3 ||4 Resolution|--- |ERRATA Last Closed||2021-04-27 00:29:56 --- Comment #8 from Fedora Update System --- FEDORA-2021-e9797584a7 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1950616] perl-Crypt-OpenSSL-ECDSA-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1950616 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Crypt-OpenSSL-ECDSA-0. |perl-Crypt-OpenSSL-ECDSA-0. |10-1.fc35 |10-1.fc35 ||perl-Crypt-OpenSSL-ECDSA-0. ||10-1.fc34 Resolution|--- |ERRATA Last Closed||2021-04-27 00:29:51 --- Comment #8 from Fedora Update System --- FEDORA-2021-00c5e3447d has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1949332] perl-Crypt-OpenSSL-ECDSA-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1949332 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Crypt-OpenSSL-ECDSA-0. |perl-Crypt-OpenSSL-ECDSA-0. |09-1.fc35 |09-1.fc35 ||perl-Crypt-OpenSSL-ECDSA-0. ||10-1.fc34 Resolution|--- |ERRATA Last Closed||2021-04-27 00:29:49 --- Comment #11 from Fedora Update System --- FEDORA-2021-00c5e3447d has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
KDE Autostart in F34
Hi, I hope there are some KDE experts on the list who can help me debug this - https://bugzilla.redhat.com/show_bug.cgi?id=1953472. It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart script in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work fine. Could you please confirm if KDE supports autostart scripts from /etc/xdg/autostart dir? If yes, is there a regression in F34? Thanks, Ravindra ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] please review: PR 4739 - UI - Migrate Server, Security, and Schema tables to PF4
https://github.com/389ds/389-ds-base/pull/4739 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Heads up: no characters visible on console in Rawhide - bug in kbd-2.4.0-3.fc35
It looks like, in openQA and manual VM testing at least, since kbd- 2.4.0-3.fc35 landed in Rawhide, all characters are invisible at the console. They're actually there, you just can't seem them. To work around this, downgrade to kbd-2.4.0-2.fc34 from F34. For more info see https://bugzilla.redhat.com/show_bug.cgi?id=1953782 . -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
On Mon, Apr 26, 2021 at 5:12 PM Andrew Lutomirski wrote: > > On Mon, Apr 26, 2021 at 1:29 PM Justin Forbes wrote: > > > > On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel > > wrote: > > > > > > On 25.04.2021 20:39, Artem Tim wrote: > > > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop > > > > variants. With 5.12 it is possible for user to change it without > > > > efforts if they need this. > > > > > > +1 for this. Significantly reduces X11 input lag in full-screen games. > > > > > > > From a kernel standpoint, I do not think turning on CONFIG_PREEMPT is > > desired. That sets the *default* to PREEMPT, and changes the current > > situation. I plan to keep CONFIG_PREEMPT_VOLUNTARY as the default. > > I'm curious: why do you prefer voluntary as the default instead of full > preempt? It has always been a nice balance for Fedora where we do have a lot of desktop users, but also a lot of server users. And it has been well tested as the Fedora default for quite some time, and the default for RHEL as well. I don't specifically dislike the full preempt, but introducing such a change to rebases on release Fedora is a risk I don't think we should take. I might be willing to make such a change for Fedora 35, where we have plenty of time to test on various workloads, but that doesn't help anyone for a good 6 months. I would much rather get the option for users now (I will even put the patch in 5.12 if I know it is headed upstream). > > The > > code introduced is odd, in that you can choose other options (none, > > voluntary, full) based on that starting point, but it doesn't allow > > you to default to anything else and keep CONFIG_PREEMPT_DYNAMIC on to > > choose more preemption than the default. > > I've pinged the right people. I'll try to make this happen. Thanks. If not I can take a look. The code looks good, it is just an unfortunate lack of options for distros who would like to use dynamic without disrupting defaults. Justin ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
On Mon, Apr 26, 2021 at 1:29 PM Justin Forbes wrote: > > On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel > wrote: > > > > On 25.04.2021 20:39, Artem Tim wrote: > > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop > > > variants. With 5.12 it is possible for user to change it without efforts > > > if they need this. > > > > +1 for this. Significantly reduces X11 input lag in full-screen games. > > > > From a kernel standpoint, I do not think turning on CONFIG_PREEMPT is > desired. That sets the *default* to PREEMPT, and changes the current > situation. I plan to keep CONFIG_PREEMPT_VOLUNTARY as the default. I'm curious: why do you prefer voluntary as the default instead of full preempt? > The > code introduced is odd, in that you can choose other options (none, > voluntary, full) based on that starting point, but it doesn't allow > you to default to anything else and keep CONFIG_PREEMPT_DYNAMIC on to > choose more preemption than the default. I've pinged the right people. I'll try to make this happen. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads-up: RPM 4.17 alpha coming to rawhide near you (broken python-srpm-macros)
On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for new
rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been quite large, and while
it's supposed to be backwards compatible with changes this big it'd be foolish
not to expect some amount of the unexpected. So please pay attention, and don't
be shy about filing bugs.
One known issue is java-11-openjdk updates failing with a message like this:
> error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to
index a nil value (global 'arg')
That is already reported against the java packages as
https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file
duplicates on that. It needs to be addressed in the java packaging.
For more details, see upstream release notes at
https://rpm.org/wiki/Releases/4.17.0
We see a problem with this construct:
Source0:%{pypi_source}
It used to work:
$ rpmspec -P python-asyncpg.spec | grep Source0
Source0:
https://files.pythonhosted.org/packages/source/a/asyncpg/asyncpg-0.22.0.tar.gz
$ rpm --define 'name foo' --define 'version 1.2.3' --eval '%{pypi_source}'
https://files.pythonhosted.org/packages/source/f/foo/foo-1.2.3.tar.gz
$ rpm --showrc | grep pypi_source -A3
-13: pypi_source%{lua:
local src = rpm.expand('%1')
local ver = rpm.expand('%2')
local ext = rpm.expand('%3')
Now we get:
error: Bad source: /builddir/build/SOURCES/%{pypi_source}: No such file or
directory
when building the package.
In mock:
sh-5.1# rpmspec -P python-asyncpg.spec | grep Source0
Source0:%{pypi_source}
sh-5.1# rpm --define 'name foo' --define 'version 1.2.3' --eval
'%{pypi_source}'
%{pypi_source}
sh-5.1# rpm --showrc | grep pypi_source -A3
(empty)
The file is /usr/lib/rpm/macros.d/macros.python-srpm. None of the Lua macros
there seem to be known to RPM, but other macros from that file work fine.
Is it possible that some Lua code there breaks all the other Lua macros from
that file? I see no error, just the macros are not recognized, as if they don't
exist.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Heads-up: RPM 4.17 alpha coming to rawhide near you (broken python-srpm-macros)
On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for new
rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been quite large, and while
it's supposed to be backwards compatible with changes this big it'd be foolish
not to expect some amount of the unexpected. So please pay attention, and don't
be shy about filing bugs.
One known issue is java-11-openjdk updates failing with a message like this:
> error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to
index a nil value (global 'arg')
That is already reported against the java packages as
https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file
duplicates on that. It needs to be addressed in the java packaging.
For more details, see upstream release notes at
https://rpm.org/wiki/Releases/4.17.0
We see a problem with this construct:
Source0:%{pypi_source}
It used to work:
$ rpmspec -P python-asyncpg.spec | grep Source0
Source0:
https://files.pythonhosted.org/packages/source/a/asyncpg/asyncpg-0.22.0.tar.gz
$ rpm --define 'name foo' --define 'version 1.2.3' --eval '%{pypi_source}'
https://files.pythonhosted.org/packages/source/f/foo/foo-1.2.3.tar.gz
$ rpm --showrc | grep pypi_source -A3
-13: pypi_source%{lua:
local src = rpm.expand('%1')
local ver = rpm.expand('%2')
local ext = rpm.expand('%3')
Now we get:
error: Bad source: /builddir/build/SOURCES/%{pypi_source}: No such file or
directory
when building the package.
In mock:
sh-5.1# rpmspec -P python-asyncpg.spec | grep Source0
Source0:%{pypi_source}
sh-5.1# rpm --define 'name foo' --define 'version 1.2.3' --eval
'%{pypi_source}'
%{pypi_source}
sh-5.1# rpm --showrc | grep pypi_source -A3
(empty)
The file is /usr/lib/rpm/macros.d/macros.python-srpm. None of the Lua macros
there seem to be known to RPM, but other macros from that file work fine.
Is it possible that some Lua code there breaks all the other Lua macros from
that file? I see no error, just the macros are not recognized, as if they don't
exist.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
Good to know. I am crossing fingers 爛 and hope you could improve current defaults and this will be upstreamed. So at least users who want PREEMPT could enable it in runtime and not need to rebuild custom kernel every time for this. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, 2021-04-26 at 21:19 +0200, Fabio Valentini wrote: > Hi everybody, > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. > > New versions and even security issues have been piling up for months > (just look at the SIG's taiga board). Other people tried to step up > for the "new" Java SIG (@java-maint-sig), but other than myself, > nobody has been triaging new bugs in Java packages. Java package > maintainers from Red Hat have been exceptionally unhelpful, and have > not substantially contributed to Java packages in Fedora in years. > Even the Modules that were heralded as "the solution" have stagnated. > On the other hand, Mat Booth and two members of the DogTag PKI team > have been really helpful, but Mat is busy fighting the Eclipse > dumpster fire most of the time, and the other two have since both > left > Red Hat for greener pastures. And since I see no way for the > situation > to improve, there's only one honest thing left that I can do: > > I will orphan all Java packages I am the main admin of, later today. > > Since this is the majority of remaining Java software in Fedora (~180 > packages), I expect at a decent amount of dependent packages will be > affected. However, given the utter lack of Java package maintainers > and the pitiful state of the overall language ecosystem, I would > strongly urge affected maintainers to drop dependencies on Java, if > at > all possible. > > Maybe other members of the java-maint-sig will pick up the orphaned > packages, if they're still here. Or maybe it's finally time to let > Java packages die. Nobody seems to care either way. you did an amazing work , thank you . -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, Apr 26, 2021 at 10:26 PM Fabio Valentini wrote: > Hi everybody, > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. > > New versions and even security issues have been piling up for months > (just look at the SIG's taiga board). Other people tried to step up > for the "new" Java SIG (@java-maint-sig), but other than myself, > nobody has been triaging new bugs in Java packages. Java package > maintainers from Red Hat have been exceptionally unhelpful, and have > not substantially contributed to Java packages in Fedora in years. > Even the Modules that were heralded as "the solution" have stagnated. > On the other hand, Mat Booth and two members of the DogTag PKI team > have been really helpful, but Mat is busy fighting the Eclipse > dumpster fire most of the time, and the other two have since both left > Red Hat for greener pastures. And since I see no way for the situation > to improve, there's only one honest thing left that I can do: > > I will orphan all Java packages I am the main admin of, later today. > > Since this is the majority of remaining Java software in Fedora (~180 > packages), I expect at a decent amount of dependent packages will be > affected. However, given the utter lack of Java package maintainers > and the pitiful state of the overall language ecosystem, I would > strongly urge affected maintainers to drop dependencies on Java, if at > all possible. > > Maybe other members of the java-maint-sig will pick up the orphaned > packages, if they're still here. Or maybe it's finally time to let > Java packages die. Nobody seems to care either way. > Thanks for keeping up the Java ecosystem in Fedora in the last few years! This is a task that has burned out many people I know (including me) so I felt your pain. > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > -- Aleksandar Kurtakov Red Hat Eclipse Team ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, Apr 26, 2021 at 09:19:44PM +0200, Fabio Valentini wrote: > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. Oh wow. Thanks for all of your efforts around this -- but you are absolutely right if you're not having fun doing it. You absolutely shouldn't feel guilty -- find something fun to spend your time on! -- Matthew Miller Fedora Project Leader ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/26/21 12:18 PM, Florian Weimer wrote: * Jeff Law: There are cases where Clang is the better choice and other cases where GCC is the better choice. The upstream projects are in the best position to make such decisions for their projects and the Fedora maintainers are in the best position to bring that decision into Fedora. All Clang-preferring upstreams I know use their own build, downloaded when the development environment is set up. The system Clang compiler would still be not blessed by upstream. Given that people who build with the system compiler on Linux are more likely to use GCC than Clang, switching to a system Clang compiler may not actually result in a more-tested build environment. Unless there is a plan to add firefox-clang, chromium-clang packages, but I really can't see that happening. I'm not saying that the proposed Change is wrong, it's just that this particular argument based on upstream preference is not very compelling because upstreams do not actually prefer to use Clang system compilers. I don't really want to get in into a debate about specific packages, but your general point that upstream preference may not be best for Fedora is a good one, and it's why the proposal was changed from "packagers should use upstream preference" to "packagers should use best judgement". Given that the whole point of this proposal is that packagers should make their own decisions, maybe the proposal owners shouldn't be making suggestions for which packages might be better off with a different compiler. I will consider changing this in the proposal. -Tom 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel wrote: > > On 25.04.2021 20:39, Artem Tim wrote: > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop > > variants. With 5.12 it is possible for user to change it without efforts if > > they need this. > > +1 for this. Significantly reduces X11 input lag in full-screen games. > From a kernel standpoint, I do not think turning on CONFIG_PREEMPT is desired. That sets the *default* to PREEMPT, and changes the current situation. I plan to keep CONFIG_PREEMPT_VOLUNTARY as the default. The code introduced is odd, in that you can choose other options (none, voluntary, full) based on that starting point, but it doesn't allow you to default to anything else and keep CONFIG_PREEMPT_DYNAMIC on to choose more preemption than the default. I will see if I can hack something together and get it upstream that would allow us to keep the voluntary default and move to preempt with the command line. Moving forward, if something like that is not accepted, this might be a valid change for F35, but I don't see it reasonable to change preemption in stable releases (and the F34 ship has sailed). Even if I do get such a patch upstream, the default would remain voluntary, and the Desktop SIG could add a preempt= command line by default for F35+. Justin ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, Apr 26, 2021 at 3:26 PM Fabio Valentini wrote: > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. > > (snip) > > I will orphan all Java packages I am the main admin of, later today. > Never feel guilty for not being able to volunteer as much as you'd like. We appreciate the time you give the project. Thank you for all of the effort you've put into the Java ecosystem in Fedora. I hope this gives you a little space to relax. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, 26 Apr 2021 at 15:20, Fabio Valentini wrote: > Hi everybody, > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. > > Thank you for your hard efforts these last couple of years. I know what it is like to feel guilty for not being able to keep up the load but it is an impossible task to do for any length of time. In the 15 years we have tried to integrate Java into Fedora, it has been clear that this language does not meld well with our way of doing things. Thank you also for having a detailed plan for handling this. I think it shows to others that it is ok to let things go when it is no longer fun or fulfilling. > New versions and even security issues have been piling up for months > (just look at the SIG's taiga board). Other people tried to step up > for the "new" Java SIG (@java-maint-sig), but other than myself, > nobody has been triaging new bugs in Java packages. Java package > maintainers from Red Hat have been exceptionally unhelpful, and have > not substantially contributed to Java packages in Fedora in years. > Even the Modules that were heralded as "the solution" have stagnated. > On the other hand, Mat Booth and two members of the DogTag PKI team > have been really helpful, but Mat is busy fighting the Eclipse > dumpster fire most of the time, and the other two have since both left > Red Hat for greener pastures. And since I see no way for the situation > to improve, there's only one honest thing left that I can do: > > I will orphan all Java packages I am the main admin of, later today. > > Since this is the majority of remaining Java software in Fedora (~180 > packages), I expect at a decent amount of dependent packages will be > affected. However, given the utter lack of Java package maintainers > and the pitiful state of the overall language ecosystem, I would > strongly urge affected maintainers to drop dependencies on Java, if at > all possible. > > Maybe other members of the java-maint-sig will pick up the orphaned > packages, if they're still here. Or maybe it's finally time to let > Java packages die. Nobody seems to care either way. > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen J Smoogen. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
The Death of Java (packages)
Hi everybody, Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer. New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do: I will orphan all Java packages I am the main admin of, later today. Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible. Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
* Jeff Law: > There are cases where Clang is the better choice and other cases where > GCC is the better choice. The upstream projects are in the best > position to make such decisions for their projects and the Fedora > maintainers are in the best position to bring that decision into > Fedora. All Clang-preferring upstreams I know use their own build, downloaded when the development environment is set up. The system Clang compiler would still be not blessed by upstream. Given that people who build with the system compiler on Linux are more likely to use GCC than Clang, switching to a system Clang compiler may not actually result in a more-tested build environment. Unless there is a plan to add firefox-clang, chromium-clang packages, but I really can't see that happening. I'm not saying that the proposed Change is wrong, it's just that this particular argument based on upstream preference is not very compelling because upstreams do not actually prefer to use Clang system compilers. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Guardrails for too-short RC-to-Go/No-Go
Hi everyone, In Friday's Go/No-Go meeting, we decided that having 5 hours between the completion of an RC and the start of the Go/No-Go meeting is not the ideal situation. So I got assigned the homework of starting the conversation about how to prevent this in the future. After all, if we don't stop ourselves from doing it, the temptation will be there. Since this is going to multiple mailing lists, I ask that the conversation happen in this Discussion thread to make sure we're all talking in one place: https://discussion.fedoraproject.org/t/guardrails-for-too-short-rc-to-go-no-go/29175 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Thoughts about packaging a standalone python-PyQt5-sip?
On Sat, 24 Apr 2021, Kevin Fenzi wrote: On Tue, Jan 12, 2021 at 10:42:28PM -0500, Scott Talbert wrote: OK, I'm going to make an attempt to move python-qt5 (and its friends) to sip5. I'm planning to build everything in a copr first. Hey Scott. Did you get any further with this? Anything I can do to help? I'd really like to be able to update calibre again. :) Yes, I got fairly far with porting all PyQt5 SIP consumers (including calibre) to use SIPv5. I think I then got discouraged at the thought of making a bunch of PRs and having to nag maintainers to merge them in some sort of coordinated fashion. I guess - if I get everything working, would you be willing to merge a bunch of related PRs as provenpackager and do rebuilds in a side tag? At this point, it might also make sense to go directly to SIPv6 as that's out already. Scott ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953616] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image
https://bugzilla.redhat.com/show_bug.cgi?id=1953616 Product Security DevOps Team changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |UPSTREAM Last Closed||2021-04-26 16:46:35 --- Comment #2 from Product Security DevOps Team --- This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
On 25.04.2021 20:39, Artem Tim wrote: Please provide full PREEMPT mode by default in 5.12 kernel for desktop variants. With 5.12 it is possible for user to change it without efforts if they need this. +1 for this. Significantly reduces X11 input lag in full-screen games. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On Mon, Apr 26, 2021 at 09:51:50AM -0600, Jeff Law wrote: > > On 4/24/2021 8:26 AM, Michael Catanzaro wrote: > > On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek > > wrote: > > > I'll be probably repeating myself, but the two compilers are known to be > > > ABI incompatible in very important ways, none of the > > > https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 > > > > > > bugs have been touched since last time this was discussed and I'm > > > not aware > > > of any ABI compatibility testing between the two compilers. > > > So if some library packages switch compilers and programs using those > > > libraries don't or vice versa, this proposal has quite high risks of > > > introducing hard to debug debugs. > > > > Perhaps this proposal should be revisited in the future when there are > > fewer scary ABI bugs. > > That's not really a scary ABI bug. There's disagreement about a fairly > unusual case involving extension of 8 bit arguments and some issues with 128 There is disagreement on passing all 8-bit and 16-bit arguments by value on x86_64, which in many cases works just by pure luck because GCC often emits the extension even on the caller side where it is not mandated by the psABI, while LLVM relies on an extension the psABI doesn't guarantee. Several packages already ran into this in the past, I don't think we can ignore that one. The va_arg passing bug for __int128 is less important, sure, most packages don't use 128-bit integers and if they do, they rarely pass it through va_arg. But having 8-bit and 16-bit arguments on ABI boundaries is very common. That is one thing and the other one is that the interoperability testing between the two compilers wasn't really performed, so besides those known bugs there can be unknown ones. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
Hi, On Fri, 2021-04-23 at 20:01 +0200, Jakub Jelinek wrote: > On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote: > > The Red Hat tools team believes that LLVM/Clang and GCC should be > > considered equals from > > a Fedora policy standpoint. Selection of one toolchain over the other > > should be > > driven by the packager's preferences not by Fedora specific policy. > > The only policy restriction should be that the compiler must exist in > > Fedora. > > I'll be probably repeating myself, but the two compilers are known to > be > ABI incompatible in very important ways, none of the > https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 > bugs have been touched since last time this was discussed and I'm not > aware > of any ABI compatibility testing between the two compilers. > So if some library packages switch compilers and programs using those > libraries don't or vice versa, this proposal has quite high risks of > introducing hard to debug debugs. So should the policy at least say that this is only allowed for packages that don't provide libraries or other code that might be linked against? > I agree that for open source software and generally for users it is useful > if there are multiple competing implementations, in this case for the > toolchain, and the competition has been IMHO quite fruitful for both GCC and > LLVM over the past years. It is also very useful if open source packages > are made portable or kept portable, so that one can use multiple compilers > to compile them, one can benefit from different diagnostics, instrumentation > etc. But I'm not sure this proposal is a step in the right direction > though, e.g. in the Firefox case that is being used as an example for this > proposal that leads in a completely different direction, a package that has > been formerly portable and supported multiple compilers will turn into a > single compiler only application and will lose its portability. > Google, Apple, BSDs don't really care about toolchain choice and they push > a single toolchain only. I cannot say I like this proposed policy very much. For the packages I work on, elfutils, valgrind, debugedit, etc. we have enough trouble keeping up with gcc versions, new flags, optimizations, etc. I don't think we will have time to debug issues because packages are now also build with another compiler. Leaving the system as a whole in a worse state because of it. I understand there are upstreams which are more aligned with other toolchains, distros or a distribution model where a specific compiler version is mandated. But even if a packages switches compilers it will be the version as packaged in Fedora, and so some porting, testing, etc. (because the version in Fedora will be different anyway) will be necessary. It seem better and more consistent for packages to use the default system compiler (gcc) unless it really cannot be build with it. Cheers, Mark ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/26/2021 9:52 AM, Jakub Jelinek wrote: On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote: On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote: Vít Ondruch wrote: Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clang for e.g. Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1721553 And the reason is not even that upstream favors Clang. The situation is unfortunately not just black and white. Looks like the best solution there is to disable PCH support in the Ruby JIT. FWIW Vit, myself and others have already extensively discussed this situation. Clang is really the best solution in the case of the Ruby JIT given the various constraints in play. Isn't that MIR instead? Hopefully one day. But right now Clang is the best choice for Ruby. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/24/2021 3:10 AM, Kevin Kofler via devel wrote: Tom Stellard wrote: This change was never rejected. It become stalled waiting for the change owners to address some feedback from FESCo. The feedback has been addressed now, which is why it was resubmitted. Ah, then I hereby urge FESCo to finally reject this for real. The mailing list feedback was overwhelmingly negative last time this was brought up. That's not a fair characterization of the discussion. There were concerns raised, but I wouldn't say it was "overwhelmingly negative" It is a distribution choice which compiler produces the best results for the distribution (best optimization, highest security, etc.). If that compiler is GCC, then why would we want to build packages with Clang, unless there is no other way? (Or if Clang is really better, then why do we not build the whole distribution with Clang? But as far as I know, GCC is still the better compiler overall, so there is no point in switching.) There are cases where Clang is the better choice and other cases where GCC is the better choice. The upstream projects are in the best position to make such decisions for their projects and the Fedora maintainers are in the best position to bring that decision into Fedora. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote: > > On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote: > > Vít Ondruch wrote: > > > Kevin, I'd love to support your stance and use GCC. However, there are > > > reasons why we will need to consider Clang for e.g. Ruby: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1721553 > > > > > > And the reason is not even that upstream favors Clang. The situation is > > > unfortunately not just black and white. > > Looks like the best solution there is to disable PCH support in the Ruby > > JIT. > > FWIW Vit, myself and others have already extensively discussed this > situation. Clang is really the best solution in the case of the Ruby JIT > given the various constraints in play. Isn't that MIR instead? Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/24/2021 8:26 AM, Michael Catanzaro wrote: On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek wrote: I'll be probably repeating myself, but the two compilers are known to be ABI incompatible in very important ways, none of the https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 bugs have been touched since last time this was discussed and I'm not aware of any ABI compatibility testing between the two compilers. So if some library packages switch compilers and programs using those libraries don't or vice versa, this proposal has quite high risks of introducing hard to debug debugs. Perhaps this proposal should be revisited in the future when there are fewer scary ABI bugs. That's not really a scary ABI bug. There's disagreement about a fairly unusual case involving extension of 8 bit arguments and some issues with 128 bit types. I wouldn't consider either a show stopper for this proposal. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/26/2021 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote: On 23.04.2021 17:18, Ben Cotton wrote: The goal is to give the packager the ability to use their own technical judgement to choose the best compiler. +1 for this change. Same here. I like the no-nonsense policy of "trust the maintainer" to make the right technical decisions. Exactly. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote: Vít Ondruch wrote: Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clang for e.g. Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1721553 And the reason is not even that upstream favors Clang. The situation is unfortunately not just black and white. Looks like the best solution there is to disable PCH support in the Ruby JIT. FWIW Vit, myself and others have already extensively discussed this situation. Clang is really the best solution in the case of the Ruby JIT given the various constraints in play. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #6 from Fedora Update System --- FEDORA-2021-e3d8833d36 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e3d8833d36 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 --- Comment #4 from Fedora Update System --- FEDORA-2021-de850ed71e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-de850ed71e -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-b308580516 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b308580516 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dynamic preemption support in Linux 5.12 kernel
On Mon, Apr 26, 2021 at 3:31 AM Chris Murphy wrote: > On Sun, Apr 25, 2021 at 12:39 PM Artem Tim wrote: > > Upcoming 5.12 allow building with dynamic preemption support which > allows changing mode at boot/run-time so finally no need to rebuild or make > alternative kernel build anymore[1]. Responsive system is a must have for > gaming and good desktop experience overall, not only for professional > audio. For example difference in input mouse lag is like day and night with > PREEMPT mode. Maybe on cheap mouse this is hard to notice but on 500-1000Hz > mouse really easy. You can test this yourself with experimental kernel > build on COPR[2]. Some Linux distros[3] already using PREEMPT mode by > default for a decent period of time. Fedora kernel build with > CONFIG_PREEMPT_VOLUNTARY but this is not enough for desktop use case. > > > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop > variants. With 5.12 it is possible for user to change it without efforts if > they need this. > > > > I see CONFIG_HAVE_PREEMPT_DYNAMIC=y with kernel > 5.12.0-0.rc8.191.fc35.x86_64+debug. > CONFIG_HAVE_PREEMPT_DYNAMIC only says the architecture supports the feature. This is hard-coded by arch/x86/Kconfig. To actually enable the feature, CONFIG_PREEMPT=y would have to be set. The combination of CONFIG_PREEMPT and CONFIG_HAVE_PREEMPT_DYNAMIC then selects CONFIG_PREEMPT_DYNAMIC. See kernel/Kconfig.preempt. Michal ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
Dne 26. 04. 21 v 16:20 Kevin Kofler via devel napsal(a): Vít Ondruch wrote: Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clang for e.g. Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1721553 And the reason is not even that upstream favors Clang. The situation is unfortunately not just black and white. Looks like the best solution there is to disable PCH support in the Ruby JIT. It is best solution if your objective is to use GCC. The other best solution might be to disable GCC hardening (and that is the current state in Fedora just FTR). But if your objective is hardening as well as fast execution, disabling PCH support has potentially so high performance cost that it turns Ruby JIT slower then the execution without JIT. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Gnome BZ untouched for years #1414539
On Mon, Apr 26, 2021 at 10:44 AM Michal Schorm wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1414539 > > Who to contact? > Who to turn onto ? > I suggest filing it upstream: https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Gnome BZ untouched for years #1414539
在 2021-04-26星期一的 08:17 +0200，Michal Schorm写道： > How many more years can I expect it will take to resolve or at least > seriously examine this following BZ? > > https://bugzilla.redhat.com/show_bug.cgi?id=1414539 Just gone through the thread and it seems to be a selinux problem. Maybe the BZ should be moved to selinux-policy or udisk2? -- Qiyu Yan GPG keyid: 0x4FC914F065F2DF12 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Gnome BZ untouched for years #1414539
On Mon, Apr 26, 2021 at 10:38 AM Michal Schorm wrote: > > How many more years can I expect it will take to resolve or at least > seriously examine this following BZ? > > https://bugzilla.redhat.com/show_bug.cgi?id=1414539 > > Does the maintainer of the utility care ? Does he check the BZ tickets ? > Does the gnome-sig triage the BZs against gnome components at least once a > year? > > Who to contact? > Who to turn onto ? > It is the position of the GNOME maintainer team that all RHBZs basically go to /dev/null unless they're blocker bugs for releases, unfortunately. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Gnome BZ untouched for years #1414539
How many more years can I expect it will take to resolve or at least seriously examine this following BZ? https://bugzilla.redhat.com/show_bug.cgi?id=1414539 Does the maintainer of the utility care ? Does he check the BZ tickets ? Does the gnome-sig triage the BZs against gnome components at least once a year? Who to contact? Who to turn onto ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
fwupd-efi package review
Hi all, I'm wanting to update the fwupd package in Fedora rawhide to the recently released 1.6.0, but this release splits out the EFI binary to a new source package. I've created https://bugzilla.redhat.com/show_bug.cgi?id=1953508 for the new package review process and would appreciate a reviewer if anyone has any time to spare. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
Vít Ondruch wrote: > Kevin, I'd love to support your stance and use GCC. However, there are > reasons why we will need to consider Clang for e.g. Ruby: > > https://bugzilla.redhat.com/show_bug.cgi?id=1721553 > > And the reason is not even that upstream favors Clang. The situation is > unfortunately not just black and white. Looks like the best solution there is to disable PCH support in the Ruby JIT. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-04-26 @ 15:00 UTC - Fedora QA Meeting
Will attend the meeting today ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953616] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing a malicious image
https://bugzilla.redhat.com/show_bug.cgi?id=1953616 Guilherme de Almeida Suckevicz changed: What|Removed |Added Summary|CVE-2021-22204 |CVE-2021-22204 |perl-Image-ExifTool:|perl-Image-ExifTool: |improper neutralization of |improper neutralization of |user data in the DjVu file |user data in the DjVu file |format allows arbitrary |format allows arbitrary |code execution when parsing |code execution when parsing |the malicious image |a malicious image --- Comment #1 from Guilherme de Almeida Suckevicz --- Created perl-Image-ExifTool tracking bugs for this issue: Affects: fedora-all [bug 1953617] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FYI: F32 Calf packages seem to be outdated
Good thing the maintainer reads -devel or she'd have missed this. :) Looks like fluidsynth got updated and calf needs a rebuild. I'll get that out. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, April 26, 2021 4:14 AM, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 26 April 2021 at 10:17, Marius Schwarz wrote: > > > Hi, > > Calf packages seem to need some attention: > > Opening a bugzilla ticket (or checking if one is open already) is much > better than complaining here. If maintainer is not responding to > bugzilla, perhaps the non-responsive maintainer procedure should be > invoked. > > Regards, > Dominik > > - > > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure signature.asc 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953616] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image
https://bugzilla.redhat.com/show_bug.cgi?id=1953616 Guilherme de Almeida Suckevicz changed: What|Removed |Added Depends On||1953617 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1953617 [Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image [fedora-all] -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 Guilherme de Almeida Suckevicz changed: What|Removed |Added Blocks||1953616 (CVE-2021-22204) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1953616 [Bug 1953616] CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953617] New: CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953617 Bug ID: 1953617 Summary: CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image [fedora-all] Product: Fedora Version: 33 Status: NEW Component: perl-Image-ExifTool Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: spo...@gmail.com Reporter: gsuck...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953616] New: CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image
https://bugzilla.redhat.com/show_bug.cgi?id=1953616 Bug ID: 1953616 Summary: CVE-2021-22204 perl-Image-ExifTool: improper neutralization of user data in the DjVu file format allows arbitrary code execution when parsing the malicious image Product: Security Response Hardware: All OS: Linux Status: NEW Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-t...@redhat.com Reporter: gsuck...@redhat.com CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Other Improper neutralization of user data in the DjVu file format in ExifTool versions 7.44 and up allows arbitrary code execution when parsing the malicious image Reference and upstream patch: https://github.com/exiftool/exiftool/commit/cf0f4e7dcd024ca99615bfd1102a841a25dde031#diff-fa0d652d10dbcd246e6b1df16c1e992931d3bb717a7e36157596b76bdadb3800 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote: > On 23.04.2021 17:18, Ben Cotton wrote: > >The goal is to give the packager the ability to use their own > >technical judgement to choose the best compiler. > > +1 for this change. Same here. I like the no-nonsense policy of "trust the maintainer" to make the right technical decisions. Zbyszek ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
On Fri, Apr 23, 2021 at 12:35:34PM -0400, Ben Cotton wrote: > On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard wrote: > > > The proposed changes[1] to the packaging guidelines does require packagers > > document their reasons in bugzilla, but that's it. > > > At the risk of getting too bikesheddy, wouldn't it be better to > document it in the spec file? It seems like that would be easier to > find two years in the future when someone wants to know why a > particular package builds with compilerX instead of gcc. In the spec file, or simply in the git commit message. E.g. if there's a bug that can be put in a comment, that's great. But if the maintainer needs to write a longer explanation, maybe it's not worth putting it in the spec file. I'd just leave it up to the maintainer. > Am I missing a benefit that having a tracking bug would provide? A tracking bug would imply that there's something to be fixed. But e.g. in case of firefox it sounds like the package might switch back and forth over time, depending on the state of the upstream code, without any bugzilla involvement. Mandating a tracking bug seems like unnecessary overhead. Zbyszek ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1952976] perl-List-AllUtils-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1952976 Michal Josef Spacek changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2021-04-26 13:36:53 --- Comment #1 from Michal Josef Spacek --- I created package for 0.19 release and tests. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953146] perl-PDL-2.039 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1953146 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC|caillon+fedoraproject@gmail | |.com, | |jakub.jedel...@gmail.com, | |ka...@ucw.cz, | |lkund...@v3.sk, | |rhug...@redhat.com, | |rstr...@redhat.com, | |sandm...@redhat.com,| |tjczep...@gmail.com | Fixed In Version||perl-PDL-2.39.0-1.fc35 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-04-26 13:11:36 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1761850] perl-Crypt-Rijndael for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761850 Matías Kreder changed: What|Removed |Added Flags|needinfo?(mkre...@gmail.com | |) | |needinfo?(iarn...@gmail.com | |) | -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads-up: RPM 4.17 alpha coming to rawhide near you
On 4/26/21 1:36 PM, Panu Matilainen wrote: It's spring, it's raining sleet where I live, and it's also the season for new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17. The changes to the macro subsystem internals have been quite large, and while it's supposed to be backwards compatible with changes this big it'd be foolish not to expect some amount of the unexpected. So please pay attention, and don't be shy about filing bugs. One known issue is java-11-openjdk updates failing with a message like this: > error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to index a nil value (global 'arg') That is already reported against the java packages as https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file duplicates on that. It needs to be addressed in the java packaging. Hmm, it's actually worse than that: this also occurs on installs, which prevents anything buildrequiring java-11-openjdk-headless from being built ATM, for example https://koji.fedoraproject.org/koji/taskinfo?taskID=66716132 The script that assumes global "arg" is actually in copy-jdk-configs package but now the callers (all the openjdk packages) would need to supply that to the script somehow. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: CompilerPolicy Change (System-Wide Change proposal)
Dne 24. 04. 21 v 11:10 Kevin Kofler via devel napsal(a): Tom Stellard wrote: This change was never rejected. It become stalled waiting for the change owners to address some feedback from FESCo. The feedback has been addressed now, which is why it was resubmitted. Ah, then I hereby urge FESCo to finally reject this for real. The mailing list feedback was overwhelmingly negative last time this was brought up. It is a distribution choice which compiler produces the best results for the distribution (best optimization, highest security, etc.). If that compiler is GCC, then why would we want to build packages with Clang, unless there is no other way? (Or if Clang is really better, then why do we not build the whole distribution with Clang? But as far as I know, GCC is still the better compiler overall, so there is no point in switching.) Kevin, I'd love to support your stance and use GCC. However, there are reasons why we will need to consider Clang for e.g. Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1721553 And the reason is not even that upstream favors Clang. The situation is unfortunately not just black and white. Vít 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-List-AllUtils] PR #1: Package tests
mspacek merged a pull-request against the project: `perl-List-AllUtils` that you are following. Merged pull-request: `` Package tests `` https://src.fedoraproject.org/rpms/perl-List-AllUtils/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 on the list, report it: https://pagure.io/fedora-infrastructure
Heads-up: RPM 4.17 alpha coming to rawhide near you
It's spring, it's raining sleet where I live, and it's also the season for new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17. The changes to the macro subsystem internals have been quite large, and while it's supposed to be backwards compatible with changes this big it'd be foolish not to expect some amount of the unexpected. So please pay attention, and don't be shy about filing bugs. One known issue is java-11-openjdk updates failing with a message like this: > error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to index a nil value (global 'arg') That is already reported against the java packages as https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file duplicates on that. It needs to be addressed in the java packaging. For more details, see upstream release notes at https://rpm.org/wiki/Releases/4.17.0 Have fun, - Panu - ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-List-AllUtils] PR #1: Package tests
mspacek opened a new pull-request against the project: `perl-List-AllUtils` that you are following: `` Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-List-AllUtils/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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)
> On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek > > The new metadata guarantees that the ELF data churns, though. For > example, if I bump the Release in a spec file for something unrelated > to the build, all the ELF blobs change. The current state means that > this is deduplicated in RPM CoW and a very cheap upgrade, since the > binaries weren't all touched. The content of the key:value pairs is entirely under your control though - if you don't want to include the spec release field because of the case where that would be the only change to the binary, then don'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 on the list, report it: https://pagure.io/fedora-infrastructure
Heads-up: RPM 4.17 alpha coming to rawhide near you
It's spring, it's raining sleet where I live, and it's also the season for new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17. The changes to the macro subsystem internals have been quite large, and while it's supposed to be backwards compatible with changes this big it'd be foolish not to expect some amount of the unexpected. So please pay attention, and don't be shy about filing bugs. One known issue is java-11-openjdk updates failing with a message like this: > error: lua script failed: /usr/libexec/copy_jdk_configs.lua:43: attempt to index a nil value (global 'arg') That is already reported against the java packages as https://bugzilla.redhat.com/show_bug.cgi?id=1892224, please don't file duplicates on that. It needs to be addressed in the java packaging. For more details, see upstream release notes at https://rpm.org/wiki/Releases/4.17.0 Have fun, - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210426.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210425.0): ID: 870153 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/870153 ID: 870160 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/870160 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: fatal error: drm.h: No such file or directory
Thanks a lot for this hint and solution. Regards Martin ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1952976] perl-List-AllUtils-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1952976 Michal Josef Spacek changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FYI: F32 Calf packages seem to be outdated
On Monday, 26 April 2021 at 10:17, Marius Schwarz wrote: > Hi, > > Calf packages seem to need some attention: Opening a bugzilla ticket (or checking if one is open already) is much better than complaining here. If maintainer is not responding to bugzilla, perhaps the non-responsive maintainer procedure should be invoked. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: fatal error: drm.h: No such file or directory
Martin Gansser wrote on 2021/04/26 17:37: Hi, when compiling [1] vdr-mpv on fc34, i get this error message: /usr/include/xf86drmMode.h:43:10: fatal error: drm.h: No such file or directory I already opened a buzilla ticket [2] but still no response. I can be solve this error by changing line 43 in /usr/include/xf86drmMode.h: #include to #include [1] https://martinkg.fedorapeople.org/ErrorReports/vdr-mpv.spec [2] https://bugzilla.redhat.com/show_bug.cgi?id=1950273 Regards Martin /usr/include/xf86drmMode.h is in libdrm-devel , so I guess you should add `$ pkg-config --cflags libdrm` to compilation flags. $ pkg-config --cflags libdrm -I/usr/include/libdrm Regards, Mamoru ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
fatal error: drm.h: No such file or directory
Hi, when compiling [1] vdr-mpv on fc34, i get this error message: /usr/include/xf86drmMode.h:43:10: fatal error: drm.h: No such file or directory I already opened a buzilla ticket [2] but still no response. I can be solve this error by changing line 43 in /usr/include/xf86drmMode.h: #include to #include [1] https://martinkg.fedorapeople.org/ErrorReports/vdr-mpv.spec [2] https://bugzilla.redhat.com/show_bug.cgi?id=1950273 Regards Martin ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 26th April (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 26th April (today!) at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.freenode.net/?channels=#fedora-neuro or Matrix/Element: https://matrix.to/#/!xgwUsLNGIoOAXMxGMQ:matrix.org?via=matrix.org=t2bot.io The channel is also bridged to Telegram, so you can also join us there on the @NeuroFedora group: https://t.me/NeuroFedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210426T13=%3A=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-04-12-13.00.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F34/F35: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FYI: F32 Calf packages seem to be outdated
Hi, Calf packages seem to need some attention: Problem 1: package calf-0.90.3-6.fc32.x86_64 requires libfluidsynth.so.1()(64bit), but none of the providers can be installed - cannot install both fluidsynth-libs-2.1.8-3.fc32.x86_64 and fluidsynth-libs-1.1.11-7.fc32.x86_64 - cannot install both fluidsynth-libs-1.1.11-7.fc32.x86_64 and fluidsynth-libs-2.1.8-3.fc32.x86_64 - cannot install the best update candidate for package fluidsynth-libs-1.1.11-7.fc32.x86_64 - cannot install the best update candidate for package calf-0.90.3-6.fc32.x86_64 Problem 2: package lv2-calf-plugins-0.90.3-6.fc32.x86_64 requires calf = 0.90.3-6.fc32, but none of the providers can be installed - package calf-0.90.3-6.fc32.x86_64 requires libfluidsynth.so.1()(64bit), but none of the providers can be installed - cannot install both fluidsynth-libs-2.1.8-3.fc32.x86_64 and fluidsynth-libs-1.1.11-7.fc32.x86_64 - cannot install both fluidsynth-libs-1.1.11-7.fc32.x86_64 and fluidsynth-libs-2.1.8-3.fc32.x86_64 - package fluidsynth-2.1.8-3.fc32.x86_64 requires libfluidsynth.so.2()(64bit), but none of the providers can be installed - package fluidsynth-2.1.8-3.fc32.x86_64 requires fluidsynth-libs(x86-64) = 2.1.8-3.fc32, but none of the providers can be installed - cannot install the best update candidate for package lv2-calf-plugins-0.90.3-6.fc32.x86_64 - cannot install the best update candidate for package fluidsynth-1.1.11-7.fc32.x86_64 the latest build is for F34 only. The F33 version of Calf solves the problem: Workaround: sudo dnf update calf --releasever=33 best regards, Marius Schwarz ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1952877] perl-Prima-1.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1952877 Petr Pisar changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE Last Closed||2021-04-26 07:53:25 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210426.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210425.0): ID: 870083 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/870083 ID: 870090 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/870090 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] 389 DS nightly 2021-04-26 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/04/26/report-389-ds-base-2.0.4-20210426git0a399a2b4.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
