On Tue, Jul 9, 2024 at 3:14 PM Josh Stone <jistone@xxxxxxxxxx> wrote: > > Text Log: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.txt > HTML Log: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.html > Text Minutes: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.txt > HTML Minutes: > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.html > > Meeting summary > --------------- > * TOPIC: Init Process (@jistone:fedora.im, 17:00:24) > * TOPIC: #3231 Update exception request for rust-add-determinism > (@jistone:fedora.im, 17:06:22) > * AGREED: An update exception is explicitly granted to > rust-add-determinism for Fedora <= 40, but not yet for 41+ (+8, 1, -0) > (@jistone:fedora.im, 17:28:55) > * TOPIC: #3232 Change: Mark Fedora KDE AArch64 as Release-Blocking > (@jistone:fedora.im, 17:29:21) The discussion revolved around the proposal to designate Fedora KDE AArch64 disk images as release-blocking for Fedora 41 and potentially subsequent releases. Here are the key topics discussed and decisions made: Proposal Context: The proposal was to elevate Fedora KDE AArch64 disk images to release-blocking status starting from Fedora 41, with concerns about the high failure rate of live ISO images. Failure Rate and Infrastructure: There was acknowledgment of a significant failure rate (~50%) for live ISO images, prompting plans to migrate to a more stable build system (Kiwi) for Fedora 42. Additionally, discussions touched on exploring separate server infrastructure due to funding and support limitations for automated testing. QA and SIG Collaboration: Debate ensued over whether QA resources could handle the additional testing workload, with a suggestion that SIGs (Special Interest Groups) should contribute more actively to testing and bug fixing. ARM SIG Input: There was a consensus that input from the ARM SIG was crucial, given the impact on ARM platforms. Concerns were raised about whether the ARM SIG had the necessary resources and whether they should be involved in decisions regarding blocking status. Decision Making Process: The proposal faced some opposition due to concerns about the practicality and cost-effectiveness of making changes without adequate resources. Ultimately, a decision was deferred pending further input from the ARM SIG. Future Steps: It was agreed to postpone the final decision, gather input from the ARM SIG, and revisit the proposal in the next meeting to ensure all stakeholders' concerns are adequately addressed. In summary, while there was initial support for the proposal to designate Fedora KDE AArch64 disk images as release-blocking, concerns about testing resources, infrastructure limitations, and the need for ARM SIG input led to a decision to delay the final vote and gather more information before proceeding. > * TOPIC: #3233 Change: GIMP version 3 (@jistone:fedora.im, 18:00:57) > * AGREED: FESCo would like to see the proposal reworked. We also > require that GIMP v2 must not be present in Fedora 41+ due to python 2 > removal. (+9, 0, -0) (@jistone:fedora.im, 18:06:27) > * TOPIC: #3234 Change: Replace Nose with Pynose (@jistone:fedora.im, > 18:07:15) > * AGREED: Change: Replace Nose with Pynose (+0, 0, -7) > (@jistone:fedora.im, 18:18:58) > * TOPIC: #3238 Change: Nvidia Driver Installation with Secure Boot > (@jistone:fedora.im, 18:19:22) > * LINK: > https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034#note_2162304 > (@sgallagh:fedora.im, 18:20:36) In the discussion regarding FESCO issue #3238 on July 9, 2024, the main topic centered around enabling Nvidia driver installation with Secure Boot in Fedora. Here are the key points and decisions made: Introduction and Background: The issue was introduced by amoloney, and it aims to address the challenge of installing Nvidia drivers under Secure Boot in Fedora. Concerns and Discussions: Participants expressed concerns about the security implications of allowing locally stored signing keys, which could potentially compromise Secure Boot's integrity. Various approaches and comparisons were made with other distributions like Ubuntu and openSUSE, which handle similar challenges differently. Proposed Compromises: There was a suggestion to improve user experience by making the process of enabling Nvidia drivers sufficiently cautionary to mitigate risks. Discussion included technical challenges such as limitations in UEFI NVRAM for storing keys and potential vulnerabilities in the update process. Decision and Next Steps: Despite extensive discussion, consensus on a solution was not reached during the meeting. It was decided to postpone further discussion to a future meeting due to time constraints and the complexity of the issue. Concerns about potential security risks and the need for a robust solution that doesn't compromise overall system security were highlighted. Overall, the meeting focused on the technical and security implications of the proposed change, with participants leaning towards caution and further exploration of viable solutions. > * TOPIC: Next week's chair (@jistone:fedora.im, 18:43:03) > * ACTION: Michel Lind 🎩 will chair next meeting > (@jistone:fedora.im, 18:44:23) > * TOPIC: Open Floor (@jistone:fedora.im, 18:44:37) > > Meeting ended at 2024-07-09 18:59:01 > > Action items > ------------ > * Michel Lind 🎩 will chair next meeting > > People Present (lines said) > --------------------------- > * @conan_kudo:matrix.org (101) > * @sgallagh:fedora.im (82) > * @jistone:fedora.im (79) > * @zbyszek:fedora.im (57) > * @nirik:matrix.scrye.com (57) > * @salimma:fedora.im (56) > * @zodbot:fedora.im (33) > * @decathorpe:fedora.im (27) > * @adamwill:fedora.im (19) > * @gui1ty:fedora.im (11) > * @dcantrell:fedora.im (11) > * @humaton:fedora.im (8) > * @smooge:fedora.im (8) > * @farchord:matrix.org (8) > * @meetbot:fedora.im (3) > * @marcdeop:matrix.org (2) > * @jnsamyak:matrix.org (1) > * @kparal:matrix.org (1) > > -- > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
