[rpms/perl-local-lib] PR #2: Ensure csh syntax is used for C shell even if SHELL env var is unset.
jhein opened a new pull-request against the project: `perl-local-lib` that you are following: `` Ensure csh syntax is used for C shell even if SHELL env var is unset. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-local-lib/pull-request/2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250895] perl-LWP-Protocol-PSGI for EL9
https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-a71533da90 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a71533da90 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. https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250895%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250763] perl-Dist-Zilla-6.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2023-5876e28a48 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5876e28a48` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5876e28a48 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. https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250763%23c4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250763] perl-Dist-Zilla-6.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250763 --- Comment #5 from Fedora Update System --- FEDORA-2023-d72df2749f has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d72df2749f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d72df2749f 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. https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250763%23c5 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2249484] No perl-XMLRPC-Lite for EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2249484 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version||perl-XMLRPC-Lite-0.717-27.e ||l9 Last Closed||2023-11-22 01:52:31 --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-c0fefed09e has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2249484 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202249484%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planned un-retirements of Pantheon DE related packages
With elementary OS / Pantheon desktop upstream having made progress with supporting newer versions of GNOME (i.e. support for newer versions of libsoup, webkitgtk, gcr, etc.), it is now again possible to build the Pantheon desktop components on Fedora 38+ (after I had retired them from Fedora 37+). I am currently working on package re-reviews and un-retirements. Although I don't use Pantheon, I love one of its components, specifically elementary-code. The ability to open any directory as if it were a project can be really useful sometimes (especially ~/bin full of shell scripts). I am still using elementary-code-6.2.0-2.fc37 which interestingly does actually work on 37/38/39 and even Rawhide. Looking forward to an update. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250924] New: perl-Math-BigInt-2.001001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250924 Bug ID: 2250924 Summary: perl-Math-BigInt-2.001001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Math-BigInt Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 2.001001 Upstream release that is considered latest: 2.001001 Current version/release in rawhide: 2.0010.00-1.fc40 URL: https://metacpan.org/dist/Math-BigInt/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/7954/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Math-BigInt -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250924 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250924%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250895] perl-LWP-Protocol-PSGI for EL9
https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2023-a71533da90 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a71533da90 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250895%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Planned un-retirements of Pantheon DE related packages
Hi all, With elementary OS / Pantheon desktop upstream having made progress with supporting newer versions of GNOME (i.e. support for newer versions of libsoup, webkitgtk, gcr, etc.), it is now again possible to build the Pantheon desktop components on Fedora 38+ (after I had retired them from Fedora 37+). I am currently working on package re-reviews and un-retirements. I still have a sliver of hope that future releases of GNOME will be less disruptive than past ones, and that it might indeed be possible *some day* to have an official Pantheon Spin of Fedora (finally). Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250895] New: perl-LWP-Protocol-PSGI for EL9
https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Bug ID: 2250895 Summary: perl-LWP-Protocol-PSGI for EL9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-LWP-Protocol-PSGI Assignee: emman...@seyman.fr Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi Emmanuel, Could you please branch and build perl-LWP-Protocol-PSGI for EL9 ? I verified current rawhide branch rebuilds properly. As always, feel free to add me to the package so I can take care of this by myself. My FAS is xavierb. Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250895 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250895%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Council election nominations are open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Council. To nominate yourself or others, visit https://fedoraproject.org/wiki/Council/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Mindshare Committee election nominations are open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Mindshare Committee. To nominate yourself or others, visit https://fedoraproject.org/wiki/Mindshare/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
FESCo Nominations are now Open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Engineering Steering Committee (FESCo). To nominate yourself or others, visit https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Council election nominations are open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Council. To nominate yourself or others, visit https://fedoraproject.org/wiki/Council/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Mindshare Committee election nominations are open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Mindshare Committee. To nominate yourself or others, visit https://fedoraproject.org/wiki/Mindshare/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
FESCo Nominations are now Open!
Hi folks, Now through November 29th, you may nominate candidates for the open seats on the Fedora Engineering Steering Committee (FESCo). To nominate yourself or others, visit https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations If you are nominating someone else, make sure you get their approval :) For more information, see the Community Blog post https://communityblog.fedoraproject.org/f39-elections-now-open/ Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
On 2023-11-21 04:34, Jiri Konecny wrote: Is Anaconda Initial Setup important for your project or workflow? What functionality is absolutely necessary for you? Do you use the text mode or the graphical mode? Are you aware of any alternatives? Is there anything that would prevent you from migrating to one of the proposed alternatives? Also please feel free to share this mail to any relevant groups. The Fedora Asahi Remix uses initial-setup (in text mode) for our Server and Minimal variants. Cheers Davide -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
All of the Arm disk images use initial-setup to configure the image. There would need to a concrete plan on how to manage the transition to something else. Dennis On Tue, Nov 21, 2023 at 6:35 AM Jiri Konecny wrote: > > Hello everyone, > > We (anaconda team) are considering discontinuation of the Anaconda's > Initial Setup[0] tool, which is not related to Gnome Initial Setup. Here > is a list of the reasons: > > * The relationship between the installer and the Initial Setup is very > fragile. It is easy to break the Initial Setup by changes in the > installer or break the installer while we are trying to fix the support > for the Initial Setup. The shared code is complex as a result and it > complicates development and maintenance of both projects. > > * As we had higher priority items to work on, the codebase is not in an > ideal state and the upstream repository doesn't even have a proper > automated CI. Fixing all these issues would take a lot of our resources > that we would like to spent on improving the installer instead. > > * The Initial Setup tool is unnecessarily complicated. Since it shares > code with the installer, it has to adapt to many limitations and > requirements of the installation environment. It doesn't use the full > potential of the installed system, because the installer can't. It > postpones all actions until the end of the configuration, because the > installer has to. It doesn't offer the best user experience for the > first boot configuration, because it is designed to reuse parts of an > installer. It drags Anaconda into the installed systems. > > * There are already alternatives: Gnome Initial Setup, > systemd-firstboot, and preparation for KDE solution of initial setup. So > the ecosystem changed from the time when Initial Setup was introduced. > We think that these alternatives are able to give you a better solution. > > > Before taking any action, we would like to understand your use-cases to > find out how we can help you to make the transition smoother and also to > find out how much time you would need for migration. > > Is Anaconda Initial Setup important for your project or workflow? What > functionality is absolutely necessary for you? Do you use the text mode > or the graphical mode? Are you aware of any alternatives? Is there > anything that would prevent you from migrating to one of the proposed > alternatives? Also please feel free to share this mail to any relevant > groups. > > [0]: https://github.com/rhinstaller/initial-setup > > Best Regards, > Anaconda 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, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2023-11-22 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@chat.fedoraproject.org The meeting will be about: https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/ -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
On Tue, Nov 21, 2023 at 01:34:43PM +0100, Jiri Konecny wrote: > Hello everyone, > > We (anaconda team) are considering discontinuation of the Anaconda's Initial > Setup[0] tool, which is not related to Gnome Initial Setup. Here is a list > of the reasons: > > * The relationship between the installer and the Initial Setup is very > fragile. It is easy to break the Initial Setup by changes in the installer > or break the installer while we are trying to fix the support for the > Initial Setup. The shared code is complex as a result and it complicates > development and maintenance of both projects. > > * As we had higher priority items to work on, the codebase is not in an > ideal state and the upstream repository doesn't even have a proper automated > CI. Fixing all these issues would take a lot of our resources that we would > like to spent on improving the installer instead. > > * The Initial Setup tool is unnecessarily complicated. Since it shares code > with the installer, it has to adapt to many limitations and requirements of > the installation environment. It doesn't use the full potential of the > installed system, because the installer can't. It postpones all actions > until the end of the configuration, because the installer has to. It doesn't > offer the best user experience for the first boot configuration, because it > is designed to reuse parts of an installer. It drags Anaconda into the > installed systems. > > * There are already alternatives: Gnome Initial Setup, systemd-firstboot, > and preparation for KDE solution of initial setup. So the ecosystem changed > from the time when Initial Setup was introduced. We think that these > alternatives are able to give you a better solution. > > > Before taking any action, we would like to understand your use-cases to find > out how we can help you to make the transition smoother and also to find out > how much time you would need for migration. > > Is Anaconda Initial Setup important for your project or workflow? What > functionality is absolutely necessary for you? Do you use the text mode or > the graphical mode? Are you aware of any alternatives? Is there anything > that would prevent you from migrating to one of the proposed alternatives? > Also please feel free to share this mail to any relevant groups. > > [0]: https://github.com/rhinstaller/initial-setup Hi, I can provide a bit of perspective from a downstream distribution of Fedora - Qubes OS. We use XFCE as the primary desktop environment, and as far as I'm aware, there is no equivalent of Gnome Initial Setup there. Furthermore, we have a Qubes-specific initial-setup addon that finishes installation steps that would be quite complicated to perform during anaconda stage. Those steps are basically starting a bunch of VMs, which requires a few system services running (including xenstored, libvirt daemon and few others) and it's very annoying and fragile to do that from inside chroot. So, we do have a use case for Initial Setup. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab 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, report it: https://pagure.io/fedora-infrastructure/new_issue
superlu_dist update to the release 8.2.0
Hi all. I will update superlu_dist to the release 8.2.0 soon; all related dependencies will be rebuilt. $ fedrq wrsrc superlu_dist amg4psblas-1.1.0-7.fc39.src freefem++-4.13-7.fc40.src hypre-2.24.0-8.fc40.src petsc-3.20.1-2.fc40.src Regards -- --- Antonio Trande Fedora Project https://fedoraproject.org/wiki/User:Sagitter mailto: sagit...@fedoraproject.org GPG key: 0x40FDA7B70789A9CD GPG keys server: https://keys.openpgp.org/ OpenPGP_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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250763] perl-Dist-Zilla-6.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250763 --- Comment #3 from Fedora Update System --- FEDORA-2023-d72df2749f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d72df2749f -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250763%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250763] perl-Dist-Zilla-6.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2023-5876e28a48 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5876e28a48 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250763%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)
On Thu, Nov 16, 2023, 9:05 AM Stephen Smoogen wrote: > > > On Thu, 16 Nov 2023 at 07:46, Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > >> Zbigniew Jędrzejewski-Szmek wrote: >> > This is called "shooting the messenger". >> >> It is not. See my reply to Fabio. >> >> > LSB requires various obsolete interfaces, in particular it requires >> > Python 2 to be available as /usr/bin/python. Comment [1] contains a >> > nice listing. We are not going to bring back Python 2 or old PERL >> > modules to satisfy LSB. >> >> That is exactly the attitude I am complaining about! >> >> It would be very much possible to support the Python 2 parts of the spec, >> without even shipping unmaintained software: Package Tauthon 2.8.4, and >> make >> both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon. >> That > > > 1. It is not clear that would actually be 'valid' for being LSB compliant. > The LSB was written to be very specific in the 'actual' software used. > Substitutes would need approval by the now defunct LSB committee. > 2. The packages in Fedora are put in there by individuals who are > interested in maintaining them. The only things I know of stopping you or > a group of individuals from packing up tauthon or the other 'dead' software > is just the sheer size of the work required. However, that is just the easy > stuff. The perl changes also require similar locked older versions of perl > and module trees so every perl script would also need to now be changed to > refer to specific versions (one being the perl5 approved by LSB and the > other not). > > In the end, the real work needed is getting LSB 'going' again. The last > version was over 10 years old and based on what the state of the 'OS' was > in 2012 (it takes time to standardize so even with the last version being > from 2015, it is going to aim at what is generally available in 2012). It > needs a 'reboot' which either meets what is the state of things are in say > 2019 or newer. Or interested people can make an OS which will stick to > LSB-5.0 forever. > I question whether any of that is actually needed. Evidence from the past decade seems to show we get by just fine without it. I think it's better to just let LSB fade gracefully into the night. josh -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #5: 6.031 bump
mspacek merged a pull-request against the project: `perl-Dist-Zilla` that you are following. Merged pull-request: `` 6.031 bump `` https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/5 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #5: 6.031 bump
mspacek opened a new pull-request against the project: `perl-Dist-Zilla` that you are following: `` 6.031 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/5 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #4: 6.031 bump
mspacek merged a pull-request against the project: `perl-Dist-Zilla` that you are following. Merged pull-request: `` 6.031 bump `` https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250861] New: perl-Data-Clone-0.005 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250861 Bug ID: 2250861 Summary: perl-Data-Clone-0.005 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Data-Clone Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.005 Upstream release that is considered latest: 0.005 Current version/release in rawhide: 0.004-30.fc39 URL: http://search.cpan.org/dist/Data-Clone Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/7043/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Data-Clone -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250861 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250861%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/rt] PR #2: use Droid Sans fonts from distro packages
zbyszek commented on the pull-request: `use Droid Sans fonts from distro packages` that you are following: `` Looks very reasonable. `` To reply, visit the link below https://src.fedoraproject.org/rpms/rt/pull-request/2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
Hi Jiri, On Tue, Nov 21, 2023, at 1:34 PM, Jiri Konecny wrote: > Hello everyone, > > * There are already alternatives: Gnome Initial Setup, > systemd-firstboot, and preparation for KDE solution of initial setup. So > the ecosystem changed from the time when Initial Setup was introduced. How about functionality loss for spins and editions that do not run a desktop environment which provides its own initial setup? Are any of the things (currently) being done by Anaconda Initial Setup unsupported by Gnome Initial Setup or its counterparts? Regards, Simon -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5: Checking signatures of packages installed out of a repository?
On Sun, Nov 05, 2023 at 12:04:09PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Nov 02, 2023 at 09:58:10AM -0400, Christopher wrote: > > On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote: > > > > On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote: > > > > > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote: > > > > > > > > > > > > FWIW, from what I can recall, yum used to check all packages, but > > > > > > this > > > > > > resulted in tons of people complaining because they did not want it > > > > > > to > > > > > > check their local packages. So, a localpkg_gpgcheck option was > > > > > > added and > > > > > > set to false. dnf4 still has this option. > > > > > > > > > > I wasn't aware of that change in behavior. I can't find that option > > > > > documented in the man page for dnf or any other readily available docs > > > > > about dnf in my installation, or present in my dnf.conf file. I don't > > > > > > > > Odd. It's in the dnf.conf man page here in rawhide: > > > > > > > > "localpkg_gpgcheck > > > > boolean > > > > > > > > Whether to perform a GPG signature check on local > > > > packages (packages in a > > > > file, not in a repository). The default is False. This > > > > option is subject to > > > > the active RPM security policy (see gpgcheck for more > > > > details). > > > > " > > > > > > > > Looks like it was added to yum 13 years ago: > > > > https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115 > > > > > > This is pretty badly documented. I'm pretty sure that most people will > > > not guess that any URL qualifies as "in a file". > > > > > > The approach to security nowadays is much stricter than 13 years ago… > > > I think we should revisit this decision. > > > > > > > > remember anybody ever complaining, certainly not "tons of people". > > > > > > > > This was 13-14 years ago. > > > > > > > > > Using local RPMs is a pretty rare thing. I can't imagine too many > > > > > people complaining about this. It was never much of a burden, and to > > > > > the extent that it was, it was a burden that was a worthwhile tradeoff > > > > > for increased security. > > > > > > > > I'm just relaying the history here... > > > > > > > > > It's also not clear when this option would take effect. Would it take > > > > > effect if I did `dnf install /path/to/local/file` or just when I did > > > > > > > > no, because that looks up that file in your repos and downloads the repo > > > > version of the package. > > > > > > > > > `dnf localinstall /path/to/local/file`? What if I did `dnf > > > > > > My vote would be: > > > 'dnf install /path/to/file' default to warn-but-allow (*) > > > > I don't think any "warn-but-allow" option is sufficient. The warning > > comes too late if the transaction is allowed to proceed. By the time > > the user can react, the installation scripts could have already > > corrupted the system due to installing a malicious or corrupted > > package, and possibly in a way that prevents them from reacting at all > > to the warning. > > > > > 'dnf install https://some.url/' default to an enforcing check > > > > > > For files outside of a repo, the current set of keys registered > > > with rpm should be used. A valid-signature-with-unknown-key must be > > > rejected when the check is enforcing. > > > > > > If such fine-grained policy is not possible, then I think > > > defaulting to requiring explicit --nogpgcheck would be better > > > than status quo. > > > > > > (*) I think that 99% of the time when you're doing a local install > > > like that, the package was built by the user and it's convenient > > > to skip the check. > > > > I don't know how common it is for people to create their own RPMs, but > > that's necessarily going to be some subset of all Fedora users. I > > suspect there are many more users who install RPMs downloaded directly > > from others where these checks matter more (GPU drivers, Steam > > repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made > > from Amazon's DEB using alien, Google Chrome initial installation RPM > > that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who > > never build their own RPMs. > > > > However, even for those who build their own RPMs, skipping this check > > is only going to be convenient for those who don't sign their own > > RPMs... which is a good practice and very easy to do. After all, these > > signatures don't just protect by authenticating the source of the > > package, but they also verify the package integrity to protect against > > file corruption. > > > > Whatever inconvenience there is for users who build their own RPMs to > > add an explicit --nogpgcheck to a command-line, I think that's > > negligible compared to the benefit to everybody to verify by default. > > Perhaps the minor
Possible deprecation/removal of Initial Setup from Fedora
Hello everyone, We (anaconda team) are considering discontinuation of the Anaconda's Initial Setup[0] tool, which is not related to Gnome Initial Setup. Here is a list of the reasons: * The relationship between the installer and the Initial Setup is very fragile. It is easy to break the Initial Setup by changes in the installer or break the installer while we are trying to fix the support for the Initial Setup. The shared code is complex as a result and it complicates development and maintenance of both projects. * As we had higher priority items to work on, the codebase is not in an ideal state and the upstream repository doesn't even have a proper automated CI. Fixing all these issues would take a lot of our resources that we would like to spent on improving the installer instead. * The Initial Setup tool is unnecessarily complicated. Since it shares code with the installer, it has to adapt to many limitations and requirements of the installation environment. It doesn't use the full potential of the installed system, because the installer can't. It postpones all actions until the end of the configuration, because the installer has to. It doesn't offer the best user experience for the first boot configuration, because it is designed to reuse parts of an installer. It drags Anaconda into the installed systems. * There are already alternatives: Gnome Initial Setup, systemd-firstboot, and preparation for KDE solution of initial setup. So the ecosystem changed from the time when Initial Setup was introduced. We think that these alternatives are able to give you a better solution. Before taking any action, we would like to understand your use-cases to find out how we can help you to make the transition smoother and also to find out how much time you would need for migration. Is Anaconda Initial Setup important for your project or workflow? What functionality is absolutely necessary for you? Do you use the text mode or the graphical mode? Are you aware of any alternatives? Is there anything that would prevent you from migrating to one of the proposed alternatives? Also please feel free to share this mail to any relevant groups. [0]: https://github.com/rhinstaller/initial-setup Best Regards, Anaconda 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #4: 6.031 bump
mspacek opened a new pull-request against the project: `perl-Dist-Zilla` that you are following: `` 6.031 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #3: 6.031 bump
mspacek merged a pull-request against the project: `perl-Dist-Zilla` that you are following. Merged pull-request: `` 6.031 bump `` https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #3: 6.031 bump
mspacek opened a new pull-request against the project: `perl-Dist-Zilla` that you are following: `` 6.031 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2250763] perl-Dist-Zilla-6.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Michal Josef Spacek --- Changes: 6.031 2023-11-20 19:49:23-05:00 America/New_York - avoid some warnings on platforms without symlinks; (thanks, reneeb!) Fix of warning, for rawhide, f39 and f38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2250763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202250763%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: chromium regression on EL9
Am 20.11.23 um 21:42 schrieb Leon Fauster: Am 20.11.23 um 01:38 schrieb Neal Gompa: On Sun, Nov 19, 2023 at 5:25 PM Leon Fauster via epel-devel wrote: Am 19.11.23 um 14:30 schrieb Neal Gompa: On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel wrote: Just noticed that the current chromium in epel-testing can not be installed on E9 with rpmfusion repo enabled. All versions before did not have this problem. It seems the build pulls a new dep (libavformat-free) that conflicts with ffmpeg-libs of rpmfusion. This results in an incompatibility with rpmfusion repos. Is this intentional? Yes. If you want expanded codec support, install the libavcodec-freeworld overlay package instead. Not sure what scenario is supported now. A common workstation setup has rpmfusion applications installed (ffmpeg, mpv, libavcodec-freeworld). Do I understand it correctly that I must remove ffmpeg-libs to install chromium now? Not sure if the new spec design with "Conflicts: ffmpeg-libs" has more a fedora context in mind. As both packages libavcodec-free and ffmpeg-libs provide the needed lib. Strictly speaking, from a Fedora context, RPM Fusion is not supported beyond limited cases. That said, EPEL has mpv itself too. The "recommended" (as far as recommendations go when it comes to third party repositories) path is to use Fedora's ffmpeg-free stack and then install libavcodec-freeworld on top if there are codecs you are missing that you need. That package overlays a libavcodec build that includes things Fedora cannot ship at this time. Thanks Neal for the overview. The specific issue was addressed now. https://src.fedoraproject.org/rpms/chromium/c/cfac4f7e0f0cae0daffbbad5c4c82b8c83e0c822?branch=epel9 Lets see when its in the repo. JFI - rpmfusion's packages can coexists now. With the full-fledged ffmpeg of rpmfusion the libavcodec-freeworld package is not needed. Thanks to @than the packager! # LANG=C yum update --enablerepo=epel-testing --enablerepo=rpmfusion-free-updates-testing chromium Last metadata expiration check: 0:04:06 ago on Tue Nov 21 12:40:55 2023. Dependencies resolved. === Package Architecture Version Repository Size === Upgrading: chromium x86_64 119.0.6045.159-2.el9 epel-testing 81 M chromium-common x86_64 119.0.6045.159-2.el9 epel-testing 13 M ffmpegx86_64 5.1.4-1.el9 rpmfusion-free-updates-testing 1.7 M ffmpeg-libs x86_64 5.1.4-1.el9 rpmfusion-free-updates-testing 7.8 M libavdevice x86_64 5.1.4-1.el9 rpmfusion-free-updates-testing72 k Transaction Summary === Upgrade 5 Packages -- Leon -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review swaps
On Fri, Nov 17, 2023 at 07:05:35PM +, Richard W.M. Jones wrote: > On Fri, Nov 17, 2023 at 09:16:41AM -0700, Jerry James wrote: > > Who would like to swap package reviews? I've got 4 packages that need to be > > reviewed: > > > > ocaml-ptime: https://bugzilla.redhat.com/show_bug.cgi?id=2242903 > > ocaml-crunch: https://bugzilla.redhat.com/show_bug.cgi?id=2242904 > > ocaml-stdlib-random: https://bugzilla.redhat.com/show_bug.cgi?id=2242905 > > I should be able to look at the OCaml ones, but not til Monday, > so if anyone wants to take them in the meantime please go ahead. I just took these 3. Looking at them right now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unretiring keepass
Hi list, as the CVE (which was not even a problem with keepass in the first place) leading to keepass retirement has been resolved in the meantime, I would like to unretire the package. I have submitted a re-review already: https://bugzilla.redhat.com/show_bug.cgi?id=2250816 Best regards, Julian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS UP] Jasper update with .so name update
Hi, there is a new jasper version (4.1.0) that will be available in Fedora 40+. As this version is bumping it's .so name, the rebuild of the dependent package will be necessary. There is a side tag created for safe rebuild of those packages (f40-build-side-77302) with a new jasper version available. I would like to ask maintainers of affected packages to rebuild their packages using this tag, so I will be able to push the update to f40 once all is done. List of affected packages is: - eccodes-devel - g2clib-devel - grib_api-devel Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20231120.n.0 changes
OLD: Fedora-Rawhide-20231119.n.0 NEW: Fedora-Rawhide-20231120.n.0 = SUMMARY = Added images:5 Dropped images: 1 Added packages: 1 Dropped packages:4 Upgraded packages: 63 Downgraded packages: 0 Size of added packages: 368.59 KiB Size of dropped packages:414.61 KiB Size of upgraded packages: 1.15 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -8.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231120.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231120.n.0.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20231120.n.0.iso Image: Onyx dvd-ostree x86_64 Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231120.n.0.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231120.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231119.n.0.iso = ADDED PACKAGES = Package: tree-sitter-java-0.20.2-1.fc40 Summary: Java grammar for Tree-sitter RPMs:libtree-sitter-java libtree-sitter-java-devel Size:368.59 KiB = DROPPED PACKAGES = Package: rust-hkdf0.11-0.11.0-5.fc39 Summary: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) RPMs:rust-hkdf0.11+default-devel rust-hkdf0.11+std-devel rust-hkdf0.11-devel Size:181.22 KiB Package: rust-inventory0.2-0.2.3-2.fc39 Summary: Typed distributed plugin registration RPMs:rust-inventory0.2+default-devel rust-inventory0.2-devel Size:28.17 KiB Package: rust-memoffset0.8-0.8.0-2.fc39 Summary: Offset_of functionality for Rust structs RPMs:rust-memoffset0.8+default-devel rust-memoffset0.8+unstable_const-devel rust-memoffset0.8-devel Size:30.80 KiB Package: rust-nom4-4.2.3-13.fc39 Summary: Byte-oriented, zero-copy, parser combinators library RPMs:rust-nom4+alloc-devel rust-nom4+default-devel rust-nom4+lazy_static-devel rust-nom4+regex-devel rust-nom4+regexp-devel rust-nom4+regexp_macros-devel rust-nom4+std-devel rust-nom4+verbose-errors-devel rust-nom4-devel Size:174.42 KiB = UPGRADED PACKAGES = Package: ansible-collection-community-general-8.0.2-1.fc40 Old package: ansible-collection-community-general-8.0.0-1.fc40 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.53 MiB Size change: 339 B Changelog: * Sun Nov 19 2023 Maxwell G - 8.0.2-1 - Update to 8.0.2. Fixes rhbz#2247589. Package: bluez-5.70-3.fc40 Old package: bluez-5.70-1.fc40 Summary: Bluetooth utilities RPMs: bluez bluez-cups bluez-deprecated bluez-hid2hci bluez-libs bluez-libs-devel bluez-mesh bluez-obexd Size: 9.54 MiB Size change: 5.99 KiB Changelog: * Mon Oct 02 2023 Sandro Bonazzola - 5.70-2 - Fix access modes for /etc/bluetooth and /var/lib/bluetooth as expected by bluetooth.service. - Resolves: fedora#2144504 * Sun Nov 19 2023 Peter Robinson - 5.70-3 - Fix some input devices disconnecting right after connecting - Explicitly enable Bluetooth BAP/BASS/CSIP/MCP/MICP/VCP profiles Package: cinnamon-control-center-6.0.0-1.fc40 Old package: cinnamon-control-center-5.9.0-1.20231107git7360582.fc40 Summary: Utilities to configure the Cinnamon desktop RPMs: cinnamon-control-center cinnamon-control-center-devel cinnamon-control-center-filesystem Size: 2.17 MiB Size change: 725 B Changelog: * Sun Nov 19 2023 Leigh Scott - 6.0.0-1 - Update to 6.0.0 release Package: cinnamon-desktop-6.0.0-1.fc40 Old package: cinnamon-desktop-5.9.0-1.20231109gitfe21fa8.fc40 Summary: Shared code among cinnamon-session, nemo, etc RPMs: cinnamon-desktop cinnamon-desktop-devel Size: 1.41 MiB Size change: 129 B Changelog: * Sun Nov 19 2023 Leigh Scott - 6.0.0-1 - Update to 6.0.0 release Package: cinnamon-menus-6.0.0-1.fc40 Old package: cinnamon-menus-5.8.0-2.fc39 Summary: A menu system for the Cinnamon project RPMs: cinnamon-menus cinnamon-menus-devel Size: 364.64 KiB Size change: -10 B Changelog: * Sun Nov 19 2023 Leigh Scott - 6.0.0-1 - Update to 6.0.0 release Package: cinnamon-screensaver-6.0.0-1.fc40 Old package: cinnamon-screensaver-5.9.0-1.20231107git9190081.fc40 Summary: Cinnamon Screensaver RPMs: cinnamon-screensaver Size: 807.51 KiB Size change: -24 B Changelog: * Sun Nov 19 2023 Leigh Scott - 6.0.0-1 - Update to 6.0.0 release Package: cinnamon-session-6.0.0-1.fc40 Old package: cinnamon-session-5.9.0-1.20231109git829519b.fc40 Summary: Cinnamon session manager RPMs: cinnamon-session Size: 555.09 KiB Size change: 103 B
Re: DNF5: Checking signatures of packages installed out of a repository?
Dne 20. 11. 23 v 16:40 Neal Gompa napsal(a): On Tue, Nov 14, 2023 at 5:02 PM Leon Fauster via devel wrote: Am 14.11.23 um 22:04 schrieb Christopher: On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro wrote: On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher wrote: I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag. Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail. The failure indicates that the source and integrity of the RPM is uncertain. The fact that the user is expected to make a conscious decision to bypass it when they want to accept that risk, but to be stopped if they don't want to accept that risk, is the whole point. So, yes, the check is expected to fail under those circumstances. As for how common those circumstances are, I just surveyed my Fedora systems, and 100% of the RPMs I've manually installed, including some pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as my own that I've built, all are signed. In my personal experience, it's rare to come across an unsigned RPM. You may have a different experience, but the frequency isn't the point... the point is to provide protection by default and user choice to override and accept the risks. Right now, we have acceptance of risk by default instead of protection. GPG check is just not the right thing to do in this case. I disagree. I think it *is* the right thing to do to check, and offer the option to skip the check. That gives users the choice to be insecure if they want, but leaves the default secure. If we enable GPG checking when not appropriate, I disagree that the failure implies that GPG checking isn't appropriate. I think the fact that an un-bypassed check failed, in response to an RPM from an unknown or untrusted source, is very appropriate. The only time it would not be appropriate, in my opinion, is if the user chose to bypass it. ***we will train users to reflexively ignore GPG errors.*** So, your position is: "don't train users to ignore GPG errors... we'll ignore them for you" ?!?! First, I don't agree that this will happen. I think it's more likely that users who are lax with security will continue to be lax with security, and users who aren't will pay attention to the failures and use that as a signal to inform their acceptance of the risks. But second, even if you're right, the worst case scenario here is the scenario we already have as the default: the check being ignored by the user is nearly the same as the check not being performed at all, which is what's happening today. If you're concerned that GPG errors will be ignored, I don't understand why you're not concerned with the fact that the only reason why users aren't seeing those errors today is because GPG checks aren't running at all! All the same security risks are still there... including the risks for an invalid or fraudulent signature when it is present on a local RPM, in addition to the risks when the signature is missing... they're just being ignored by default. You're worried about a situation where a user *might* ignore security check errors... but I'm worried that they are auto-ignored by the system, before the user even has a chance to take them seriously. (We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.) I don't agree with that either. I verify the signatures of Fedora keys using https://fedoraproject.org/security and the keys of other repos I use, and other users who care about security can do the same. I think Fedora has done as good a job as one can expect, for the most part, in trying to provide good security to those who care. But, of course, users have to care first and do their part as well. GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL. Again, I completely disagree. The check protects against corrupt and/or malicious software, and is one of the few steps the package management system has to proactively prevent harm to the user's system *before* the harm is done. Skipping these checks by default is bad for software supply chain security, regardless of whether the supply chain involves a repo or just an RPM. The signatures are in the RPM, and the keys in the RPM database. The fact that it came from a repo or not is completely irrelevant for good software supply chain security defaults. I completly agree with you.
