Re: Fedora Linux 37 is EOL
On 08-01-2024 17:16, Adam Williamson wrote: > Doing it this way was Ben's preference (he wanted to be able to see > that every bug was updated and get a notice from the script for any > single bug change that failed), Historically, the script ran much faster than Bugzilla, which meant after a while, we'd start getting timeouts. This is why there are pauses built into the script. A few years ago, the performance of Bugzilla improved greatly, but I never felt like exploring where the boundaries are. Updating all matching bugs in one transaction is still probably going to result in timeouts, but smaller chunks should work well enough. Of course, that means a transient failure could cause many bugs to need to be re-run instead of just one. That's not to say it can't be done, but it was never a priority for me. On Mon, Jan 8, 2024 at 11:30 AM Sandro wrote: > > I just noticed that some bugs with version '37' were still open while > others were already closed. I'm not saying that's what happened here, but it's not uncommon to see bugs that are closed EOL get re-opened but not have an updated version. For a long time, I never checked that when putting the bug count lists in the Friday's Fedora Facts posts. The first time I did, there were hundreds of bugs across several EOL releases. :-) -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton -- ___ 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: Why I won't run for FESCo
There's a lot to be said for knowing when to step away. You've certainly done more than your share for FESCo — and the broader Fedora community. Thanks for all of your time on FESCo and the friendship you've shown to me and countless others. -- ___ 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: Inactive packager policy for the F39 cycle
On Wed, Aug 30, 2023 at 2:47 PM Kevin Fenzi wrote: > > Might you be willing to also do the provenpackager one? > ( https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ ) > For Mattia (or anyone else who wants to pick this up), you can see my SOP at https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/inactive-provenpackagers/ -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: Does a change approved for f39 need reapproval for f40?
On Fri, Aug 11, 2023 at 2:56 PM Jonathan Wakely wrote: > > This change got approved for f39 but couldn't be done in time: > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB > > Does it need to be re-proposed and approved for f40, or can we just do it > now? (in a side tag, as planned, of course). No, just do it: > Changes that cannot be completed will automatically be deferred to the next > release and do not require re-submission unless substantial revisions are > made. https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process Since there's not a program manager (or the newly-created operations architect) in place, you'll probably want to do the deferral paperwork yourself: https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/changes-defer/ -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: Fedora 39 Mass Rebuild
On Tue, Jul 25, 2023 at 3:58 PM Fabio Valentini wrote: > > As far as I can tell, the toolchain proposal was announced on the devel / > devel-announce lists on July 7 but never submitted to FESCo for a vote. Looks > like the process broke down somewhere along the way. I think it was actually a couple of days before that, but no matter. In either case it was announced more than a week after it was submitted (which happened to be the date of the deadline). So the problem is two-fold: 1. It sat in "ChangeReadyForWrangler" for a week during a rather time-critical part of the cycle 2. It never made it to FESCo I could be salty about this, but I'll refrain. The point is that altering the schedule wouldn't make a difference here because the schedule isn't the problem. It's that there's not someone whose actual job is wrangling Change proposals. amoloney has done a great job picking up many of my former duties while also doing her full time job, but as that sentence implies, there are capacity issues. Of course, earlier submission is better when possible but I don't know if it was possible in this case and it's not clear it would have helped this specific issue. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: proposed change to FESCo voting rules
On Fri, Jul 21, 2023 at 2:03 AM Kevin Kofler via devel wrote: > > Ben Cotton wrote: > > This will be helpful to people who aren't regularly involved in FESCo > > votes. If that's you: the proposal presented here is largely > > clarification. There's not much in the way of substance change. > > Actually, it changes existing practice in that it changes the meaning of the > "0" vote. Thanks for pointing that out. You're right, that part does represent a change in substance, but in a relatively rare case, which is why I said "not much". (I have a sense that the current rule wasn't consistently applied during my time as FPgM, but I don't want to do the archaeology to find out.) To be fully transparent, the reason I said that at all was to mitigate potential "FESCo voting rules are changing in the next big step towards IBM's destruction of all things community" FUD. It's been a silly enough time to be online the last few months already. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: proposed change to FESCo voting rules
On Thu, Jul 20, 2023 at 3:46 PM Zbigniew Jędrzejewski-Szmek wrote: > > Stephen Gallagher proposed a change to FESCo voting rules [1]. This will be helpful to people who aren't regularly involved in FESCo votes. If that's you: the proposal presented here is largely clarification. There's not much in the way of substance change. I did notice that the "fast track" voting mechanism fell out. I think that's worth preserving. Also, the proposal says "eligible voters" a lot. Let's replace it with "FESCo members" to make it more clear that it's not a wide-open vote. If you really want, you can say "eligible FESCo members", but there's not been any case that I'm aware of where a FESCo member was ineligible to vote on something, so adding that word inserts unnecessary complexity. > Change ticket is assumed to be a a formal proposal upon creation. Duplicate "a" > An official vote in a ticket must be one of +1, -1 as defined herein: I suggest striking "as defined herein" for simplicity. Also you may want to include 0 in the sentence since it's in the list that follows. > At the end of one week, if a ticket has at least 3 votes of +1 and no > votes of -1, it is approved and may proceed with implementation. If > there is at least one -1 vote, the ticket must be added to the > upcoming meeting agenda and subject to the Meeting Votes rules. I'd make that "…and is subject…" > A proposal must achieve a majority (at least 51%) of +1 votes from > eligible voters. Votes must be one of +1, 0 or -1 as defined herein: s/as defined herein/g :-) > +1 I am in favor of the proposal as currently written. > > 0 I am electing to remove myself from the list of eligible > voters. This reduces the denominator of the fraction required to > achieve the 51% majority. In effect, I am agreeing to vote with > the remaining majority, whatever they decide. > > -1 I am opposed to the proposal as currently written. This largely duplicates the definitions for in-ticket votes. It might be better to just refer to that and add the special meaning of 0. Something like: A proposal must achieve a majority (at least 51%) of +1 votes from eligible voters. Votes must be one of +1, 0 or -1 as described in Ticket votes. In a meeting vote, a vote of 0 reduces the denominator of the fraction required to achieve the 51% majority. In effect, it says "I am agreeing to vote with the remaining majority, whatever they decide." -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On Mon, Jun 26, 2023 at 10:34 AM Aoife Moloney wrote: > > * Other developers: > Our focus for this change is specifically on Fedora Workstation. > Nevertheless, we are open to collaborating with all spins/SIG to > transition their build pipelines to Image Builder. However, for the > initial switch, we aim to minimize the impact by focusing on a single > artifact. We anticipate that more artifacts will be transitioned in > subsequent releases of Fedora Linux. What's the impact to QA and release processes? Will the Workstation images still be in the regular large compose, or will they be a separate compose that will need to be managed independently? -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: What is Fedora?
On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett wrote: > It has much to do. Fedora is a community apparently Red Hat no longer needs. > The now ELN backend > can satisfy pre testing and could make fedora redundant. ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: What is Fedora?
On Wed, Jun 21, 2023 at 4:07 PM Philip Wyett wrote: > > Let us face it our efforts with the Fedora project are not valued and it is a > means nothing to the > new corporate IBM/Red Hat enterprise systems that we have to struggle to get > access to srpms, to > make a community. What is community now to Red Hat? I'm not particularly inclined to feel favorably toward Red Hat, but I don't see what the availability of RHEL srpms has to do with Fedora. We're upstream of RHEL. On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen wrote: > > My interpretation of the blog post, combined with recent actions > towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as > the new "Fedora" for basing future versions of RHEL. Not really. Fedora is the basis for new RHEL major versions (e.g. RHEL 10). CentOS Stream is the next RHEL minor version (9.X). -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: LibreOffice packages
On Fri, Jun 2, 2023, 9:09 AM Matthew Miller wrote: > I think this sentiment is getting ahead of things. This thread _is_ that effort. Yes, but. In general, a better approach is to say "we plan on orphaning the packages in $timeframe". Even if $timeframe is a week, it shifts the perception to "we are communicating future plans" to "by they way we just dropped this thing, good luck." I know the intent of the original post was the former, but that doesn't mean people don't view it as the latter (particularly when seen in the broader context). Ideally, of course, $timeframe is longer than a week, but that's not always feasible. We all have constraints on our time and effort. Asking people to submit a Change when they want or need to stop > working on something seems... burdensome. (And, uh, what happens if that > change is rejected? There's no _making_ people do things.) > As the world's foremost expert on Fedora's Changes process, I agree. That said, there's value in the cross-functional visibility of a Change proposal. I've long thought we need an "announcement only" process that looks very similar to the current process, but I could never quite convince myself I knew how that should work. (This thread is not the place to discuss it, but maybe I'll start a separate conversation about that later) > ___ 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: employment related packager groups
I'm not necessarily opposed to this, but I'm not sure I'm in favor of it. It certainly beats a company using a shared account against policy to allow for multiple maintainers. On the other hand, what are the practical use cases here? As Kevin and Zbigniew said in https://pagure.io/fesco/issue/2929 , interest-based groups instead of employer-based groups seem like a better approach. Seems like the main place this would be used is when the org is the upstream project, and even then, an interest-based group open to the broader community seems more in the Fedora spirit. So to address the specific questions: > Should such groups require FESCo approval? Yes. These groups should be exceptional cases. > If so, what would be requirements to approve/deny? The group must represent something for with there is no broader community interest. (e.g. I'm interesting in maintaining packages produced by FunnelFiascCorp, but there's no broader FunnelFiasco SIG because it's not a broader thing like weather or program management) > Should we require some documentation? ie, should the group have to make > a doc/wiki page explaining what it's for and how to reach group owners > in case of problems? No, because it won't be maintained. (I'd like to say yes, but I know better) The fact that it's a group means we can see who the group members are and thus can figure out how to contact them if needed. ___ 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: FESCo election nominations are now open
As a reminder, nominations are open through 10 May. There are currently four candidates for four open seats. On Wed, Apr 19, 2023 at 12:43 PM Ben Cotton wrote: > > Now through 10 May, you may nominate candidates for the Fedora > Engineering Steering Committee (FESCo). > > To nominate yourself (or others, if you check with them first), visit > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > > For more information, see the Community Blog post: > https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Re: FESCo election nominations are now open
As a reminder, nominations are open through 10 May. There are currently four candidates for four open seats. On Wed, Apr 19, 2023 at 12:43 PM Ben Cotton wrote: > > Now through 10 May, you may nominate candidates for the Fedora > Engineering Steering Committee (FESCo). > > To nominate yourself (or others, if you check with them first), visit > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > > For more information, see the Community Blog post: > https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Fedora Onyx (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Onyx This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Creation of an official Fedora immutable variant with a Budgie Desktop environment, complementing Fedora Budgie Spin and expanding the immutable offerings of Fedora. == Owner == * Name: [[User:joshstrobl| Joshua Strobl]] * Primary Contact Person: [[User:joshstrobl| Joshua Strobl]] * Email: joshstr...@fedoraproject.org * SIG: [[SIGs/Budgie|Budgie]] == Detailed Description == Fedora Onyx is an immutable desktop operating system, featuring the Budgie Desktop environment. Fedora Onyx leverages the same foundational technologies as other Fedora immutable variants such as Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak, rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are attracted to / find value in the Fedora computing platform and Budgie Desktop environment, but need the robust immutability and atomic capabilities that rpm-ostree provides, which are not be offered through traditional Fedora spins (e.g. Fedora Budgie Spin). Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]] == Feedback == No specific feedback received so far. == Benefit to Fedora == Fedora Onyx will expand Fedora’s existing attractive offerings of immutable operating systems, providing an on-ramp for potential users to the Fedora platform, as well as a desired experience among current Fedora Budgie Spin users that wish to experiment with rpm-ostree or dive into tooling that pairs well with the immutable experience. By actively building on and leveraging technologies adopted by similar immutable variants from Fedora (Kinoite, Sericea, and Silverblue), Fedora Onyx may help to strengthen those variants by putting more contributors behind building and maturing our shared technologies. == Scope == * Proposal owners: ** The Budgie SIG will submit Pungi changes needed to add this new variant to the compose. ** The Budgie SIG will submit the changes to add a new sub-package to fedora-release. ** The Budgie SIG will maintain the Onyx specific rpm-ostree config in the workstation-ostree-config repo. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/11411 #11411] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Submitted as [https://pagure.io/Fedora-Council/tickets/issue/451 #451] * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == N/A. Not a System Wide Change. ostree installations will be able to seamlessly rebase to onyx in the same way they would any other variant. == How To Test == TBA. Instructions will be posted on Fedora Discussion upon landing of the required components such as rpm-ostree config. These instructions will follow similar steps as rebasing for any other rpm-ostree variant. == User Experience == N/A. No changes for existing Fedora users, including those using Fedora Budgie Spin. Users of Fedora Onyx will receive a similar user experience to Fedora Budgie Spin, with a smaller package set to encourage users to more heavily leverage flatpak to curate their own desired experience. == Dependencies == N/A. Not a System Wide Change. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == There may be known issues with other Fedora immutable variants which may be addressed by existing documentation such as the [https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/ Fedora Silverblue Troubleshooting document]. == Release Notes == Fedora Onyx has been introduced as a new immutable variant of Fedora Linux / Fedora Budgie Spin, featuring the Budgie Desktop environment and the same robust technologies as our other variants such as Kinoite, Sericia, and Silverblue (flatpak, rpm-ostree, podman, toolbx). -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Fedora Onyx (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Onyx This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Creation of an official Fedora immutable variant with a Budgie Desktop environment, complementing Fedora Budgie Spin and expanding the immutable offerings of Fedora. == Owner == * Name: [[User:joshstrobl| Joshua Strobl]] * Primary Contact Person: [[User:joshstrobl| Joshua Strobl]] * Email: joshstr...@fedoraproject.org * SIG: [[SIGs/Budgie|Budgie]] == Detailed Description == Fedora Onyx is an immutable desktop operating system, featuring the Budgie Desktop environment. Fedora Onyx leverages the same foundational technologies as other Fedora immutable variants such as Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak, rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are attracted to / find value in the Fedora computing platform and Budgie Desktop environment, but need the robust immutability and atomic capabilities that rpm-ostree provides, which are not be offered through traditional Fedora spins (e.g. Fedora Budgie Spin). Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]] == Feedback == No specific feedback received so far. == Benefit to Fedora == Fedora Onyx will expand Fedora’s existing attractive offerings of immutable operating systems, providing an on-ramp for potential users to the Fedora platform, as well as a desired experience among current Fedora Budgie Spin users that wish to experiment with rpm-ostree or dive into tooling that pairs well with the immutable experience. By actively building on and leveraging technologies adopted by similar immutable variants from Fedora (Kinoite, Sericea, and Silverblue), Fedora Onyx may help to strengthen those variants by putting more contributors behind building and maturing our shared technologies. == Scope == * Proposal owners: ** The Budgie SIG will submit Pungi changes needed to add this new variant to the compose. ** The Budgie SIG will submit the changes to add a new sub-package to fedora-release. ** The Budgie SIG will maintain the Onyx specific rpm-ostree config in the workstation-ostree-config repo. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/11411 #11411] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Submitted as [https://pagure.io/Fedora-Council/tickets/issue/451 #451] * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == N/A. Not a System Wide Change. ostree installations will be able to seamlessly rebase to onyx in the same way they would any other variant. == How To Test == TBA. Instructions will be posted on Fedora Discussion upon landing of the required components such as rpm-ostree config. These instructions will follow similar steps as rebasing for any other rpm-ostree variant. == User Experience == N/A. No changes for existing Fedora users, including those using Fedora Budgie Spin. Users of Fedora Onyx will receive a similar user experience to Fedora Budgie Spin, with a smaller package set to encourage users to more heavily leverage flatpak to curate their own desired experience. == Dependencies == N/A. Not a System Wide Change. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == There may be known issues with other Fedora immutable variants which may be addressed by existing documentation such as the [https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/ Fedora Silverblue Troubleshooting document]. == Release Notes == Fedora Onyx has been introduced as a new immutable variant of Fedora Linux / Fedora Budgie Spin, featuring the Budgie Desktop environment and the same robust technologies as our other variants such as Kinoite, Sericia, and Silverblue (flatpak, rpm-ostree, podman, toolbx). -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Man-pages-ru Retirement (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/ManPagesRuRetirement This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Retiring man-pages-ru because it is already part of the man-pages-l10n. == Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavo...@redhat.com == Detailed Description == Upstream (man-pages-l10n) has integrated Russian translations for man-pages. It means we no longer need to have a specific (man-pages-ru) package for it. [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream commit containing the change] The plan is simple: 1) Deprecate man-pages-ru package 2) Enable 'ru' translations for man-pages-l10n (temporary disabled due to conflicts). [https://src.fedoraproject.org/rpms/man-pages-l10n/c/00a88c237e1fd7cdef9c52665128b155cf14243c?branch=rawhide Commit disabling it] Also add Obsolete and Provides for man-pages-ru package. == Feedback == Early feedback from the community is positive, the feedback is located in this ([https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/WGLMJ7XXB5JUER57GEOZQBFMNKHD5FSZ/ Devel list announce]) == Benefit to Fedora == Fedora shouldn't maintain a redundant package. This change would make it easier for the maintainer as well as for the packages that requires man-pages-l10n and man-pages-ru. == Scope == * Proposal owners: Package man-pages-ru will be retired, and the man-pages-l10n will contain the Russian translations. * Other developers: Change the names of their BuildRequires/Requires accordingly. * Release engineering: No action required * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == When following the plan in Detailed Description there will be no need for manual action. Everything will be handled by the automated dnf upgrade. == How To Test == == User Experience == == Dependencies == List of the packages from Fedora 39 === man-pages-ru === dnf repoquery --whatrequires man-pages-ru | pkgname dnf repoquery --whatrequires '/usr/share/man/ru/*' | pkgname == Contingency Plan == * Contingency mechanism: Remove the man-pages-l10n build with Russian translation enabled. Revert deprecation of the man-pages-ru package. * Contingency deadline: Beta freeze * Blocks release? No ''NOTE: If we don't finish this change by the deadline, it is possible to just complete this change with the next release.'' == Documentation == [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream issue] [https://bugzilla.redhat.com/show_bug.cgi?id=2163421 Bugzilla tracker] [https://sourceforge.net/p/man-pages-ru/discussion/1102373/thread/7dda92a232/ man-pages-l10n upstream discussion with man-pages-ru upstream about this] == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Man-pages-ru Retirement (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/ManPagesRuRetirement This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Retiring man-pages-ru because it is already part of the man-pages-l10n. == Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavo...@redhat.com == Detailed Description == Upstream (man-pages-l10n) has integrated Russian translations for man-pages. It means we no longer need to have a specific (man-pages-ru) package for it. [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream commit containing the change] The plan is simple: 1) Deprecate man-pages-ru package 2) Enable 'ru' translations for man-pages-l10n (temporary disabled due to conflicts). [https://src.fedoraproject.org/rpms/man-pages-l10n/c/00a88c237e1fd7cdef9c52665128b155cf14243c?branch=rawhide Commit disabling it] Also add Obsolete and Provides for man-pages-ru package. == Feedback == Early feedback from the community is positive, the feedback is located in this ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WGLMJ7XXB5JUER57GEOZQBFMNKHD5FSZ/ Devel list announce]) == Benefit to Fedora == Fedora shouldn't maintain a redundant package. This change would make it easier for the maintainer as well as for the packages that requires man-pages-l10n and man-pages-ru. == Scope == * Proposal owners: Package man-pages-ru will be retired, and the man-pages-l10n will contain the Russian translations. * Other developers: Change the names of their BuildRequires/Requires accordingly. * Release engineering: No action required * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == When following the plan in Detailed Description there will be no need for manual action. Everything will be handled by the automated dnf upgrade. == How To Test == == User Experience == == Dependencies == List of the packages from Fedora 39 === man-pages-ru === dnf repoquery --whatrequires man-pages-ru | pkgname dnf repoquery --whatrequires '/usr/share/man/ru/*' | pkgname == Contingency Plan == * Contingency mechanism: Remove the man-pages-l10n build with Russian translation enabled. Revert deprecation of the man-pages-ru package. * Contingency deadline: Beta freeze * Blocks release? No ''NOTE: If we don't finish this change by the deadline, it is possible to just complete this change with the next release.'' == Documentation == [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream issue] [https://bugzilla.redhat.com/show_bug.cgi?id=2163421 Bugzilla tracker] [https://sourceforge.net/p/man-pages-ru/discussion/1102373/thread/7dda92a232/ man-pages-l10n upstream discussion with man-pages-ru upstream about this] == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: mkosi-initrd (Self-Contained Change proposal)
redhat.com/show_bug.cgi?id=2189633) ** verify (and fix if necessary) `mkosi-initrd`/`systemd`/other packages to work with: *** root on a plain partition *** root on LVM2 *** root on LUKS *** root on RAID *** root on NFS *** hibernation ** provide a `kernel-install` plugin that builds an initrd locally ** provide a `kernel-install` plugin that combines this initrd with a kernel binary into a Unified Kernel Image locally ** make dracut not interfere with mkosi-initrd (merge https://github.com/dracutdevs/dracut/pull/1825 or carry downstream patch) ** work with koji developers to allow `mkosi-initrd` to run in koji (stretch goal 1). This requires changing koji to allow access to downloaded rpms during build. ** add a `mkosi-initrd-initrd` (name TBD) package that builds a set of subpackages with initrds (stretch goal 2). (Out of scope: support for root on iSCSI is not planned currently. Our experiments with iSCSI show that the existing tooling is a bunch of terrible scripts that don't work at all outside of dracut.) More items may be added to Scope or listed as not planned based on feedback. * Other developers: ** koji developers: help with the rpms-in-buildroot functionality and ** koji maintainers and releng: deploy changes in koji in Fedora infra ** anyone: Install the new packages to opt-in into testing the new initrds. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This is new functionality that will only impact people who opt-in. == How To Test == * Right now: ** enable the copr and install `mkosi-initrd` (see [https://github.com/systemd/mkosi-initrd/#mkosi-initrd--build-initrd-images-using-distro-packages instructions]) ** adjust configuration:echo 'initrd_generator=mkosi-initrd' >>/etc/kernel/install.conf# Until https://github.com/dracutdevs/dracut/pull/1825 is mergedmkdir -p /etc/kernel/install.dln -s /dev/null /etc/kernel/install.d/50-dracut.install ** Upgrade or reinstall kernel package and reboot * After `mkosi-initrd` has an official build: ** disable the copr and update to the distro package ** Upgrade or reinstall kernel package and reboot * After stretch goal 2: ** Install `mkosi-initrd-initrd-` ** Upgrade or reinstall kernel package and reboot == User Experience == Ideally, there should be no visible change for users. Obviously, when text logs are shown the console, the output is a bit different. After stretch goals 2, installation will be quicker. == Dependencies == Support for UKIs in grub2 was implemented in [[Changes/Unified_Kernel_Support_Phase_1]], but the support for UKIs in grub2 was not merged. This support is a requirement for people who want to use mkosi-initrd UKIs with grub2. == Contingency Plan == * Contingency mechanism: Postpone introduction of features to a later release. If it turns out that initrds are faulty, users who installed them will need to manually switch back to dracut initrds. * Contingency deadline: Any time. * Blocks release? No. == Documentation == https://github.com/systemd/mkosi-initrd/blob/main/docs/fedora.md == Release Notes == Simplified initrds built with `mkosi-initrd` are available for testing. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: mkosi-initrd (Self-Contained Change proposal)
redhat.com/show_bug.cgi?id=2189633) ** verify (and fix if necessary) `mkosi-initrd`/`systemd`/other packages to work with: *** root on a plain partition *** root on LVM2 *** root on LUKS *** root on RAID *** root on NFS *** hibernation ** provide a `kernel-install` plugin that builds an initrd locally ** provide a `kernel-install` plugin that combines this initrd with a kernel binary into a Unified Kernel Image locally ** make dracut not interfere with mkosi-initrd (merge https://github.com/dracutdevs/dracut/pull/1825 or carry downstream patch) ** work with koji developers to allow `mkosi-initrd` to run in koji (stretch goal 1). This requires changing koji to allow access to downloaded rpms during build. ** add a `mkosi-initrd-initrd` (name TBD) package that builds a set of subpackages with initrds (stretch goal 2). (Out of scope: support for root on iSCSI is not planned currently. Our experiments with iSCSI show that the existing tooling is a bunch of terrible scripts that don't work at all outside of dracut.) More items may be added to Scope or listed as not planned based on feedback. * Other developers: ** koji developers: help with the rpms-in-buildroot functionality and ** koji maintainers and releng: deploy changes in koji in Fedora infra ** anyone: Install the new packages to opt-in into testing the new initrds. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This is new functionality that will only impact people who opt-in. == How To Test == * Right now: ** enable the copr and install `mkosi-initrd` (see [https://github.com/systemd/mkosi-initrd/#mkosi-initrd--build-initrd-images-using-distro-packages instructions]) ** adjust configuration:echo 'initrd_generator=mkosi-initrd' >>/etc/kernel/install.conf# Until https://github.com/dracutdevs/dracut/pull/1825 is mergedmkdir -p /etc/kernel/install.dln -s /dev/null /etc/kernel/install.d/50-dracut.install ** Upgrade or reinstall kernel package and reboot * After `mkosi-initrd` has an official build: ** disable the copr and update to the distro package ** Upgrade or reinstall kernel package and reboot * After stretch goal 2: ** Install `mkosi-initrd-initrd-` ** Upgrade or reinstall kernel package and reboot == User Experience == Ideally, there should be no visible change for users. Obviously, when text logs are shown the console, the output is a bit different. After stretch goals 2, installation will be quicker. == Dependencies == Support for UKIs in grub2 was implemented in [[Changes/Unified_Kernel_Support_Phase_1]], but the support for UKIs in grub2 was not merged. This support is a requirement for people who want to use mkosi-initrd UKIs with grub2. == Contingency Plan == * Contingency mechanism: Postpone introduction of features to a later release. If it turns out that initrds are faulty, users who installed them will need to manually switch back to dracut initrds. * Contingency deadline: Any time. * Blocks release? No. == Documentation == https://github.com/systemd/mkosi-initrd/blob/main/docs/fedora.md == Release Notes == Simplified initrds built with `mkosi-initrd` are available for testing. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Lazarus repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F39-Lazarus-repackaging This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Split the `lazarus` package (the Lazarus IDE for Free Pascal) into several sub-packages (built from the same spec file) and enable building the Lazarus Component Library for multiple widget sets, instead of just the default GTK2. == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: == Detailed Description == The `lazarus` package will be split into multiple packages: * `lazarus-doc` - documentation * `lazarus-ide` - the IDE itself * `lazarus-lcl` - base package for the LCL (Lazarus Component Library), containing common LCL parts * `lazarus-lcl-nogui` - components for building non-graphical applications * `lazarus-lcl-gtk` - components for building programs using the GTK2 widget library * `lazarus-tools` - command-line tools shipped with Lazarus, e.g. `lazbuild` The `lazarus` package will become a metapackage - it will not contain any files itself, instead pulling in all the packages mentioned above. Several new packages will also be introduced: * `lazarus-lcl-gtk3` - support for building programs using the GTK3 widget library * `lazarus-lcl-qt` - ditto, for Qt4 * `lazarus-lcl-qt5` - ditto, for Qt5 == Benefit to Fedora == Currently, Lazarus in Fedora only supports building programs with the GTK2 widget set. With this change, Lazarus will gain support for additional widget sets, allowing users to build their applications using GTK3, Qt4 and Qt5. Maintainers of packages depending on Lazarus can switch from BuildRequiring `lazarus` to the following set: * `lazarus-lcl-nogui` (may not be needed, depending on the program) * `lazarus-lcl-gtk2` (or a different widget set, if the maintainer so wishes) * `lazarus-tools` This minimal package set is about ~60MiB smaller than the current Lazarus package. This should make builds slightly faster. == Scope == * Proposal owners: ** Edit `lazarus.spec` as required and rebuild the package, preferably before the Mass Rebuild. * Other developers: No action required. * Release engineering: No action required. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == When upgrading Fedora 39, users who have the `lazarus` package installed should see the following sub-packages pulled in during the process: * `lazarus-doc` * `lazarus-ide` * `lazarus-lcl` * `lazarus-lcl-nogui` * `lazarus-lcl-gtk2` * `lazarus-tools` This set of packages should provide the same files and functionality as the current monolithic `lazarus` package. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/lazarus-split/ copr/suve/lazarus-split]. == User Experience == For users not interested in different widget sets, this Change should not affect their experience. Those wanting to build their programs using GTK3, Qt4 or Qt5 will gain the ability to do so. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `lazarus.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `lazarus` package has been split into multiple sub-packages. Apart from GTK2, the IDE now supports building programs using the GTK3, Qt4 and Qt5 widget sets - available by installing `lazarus-lcl-*` packages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Perl 5.38 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/perl5.38
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: ,
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email
F39 proposal: Lazarus repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F39-Lazarus-repackaging This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Split the `lazarus` package (the Lazarus IDE for Free Pascal) into several sub-packages (built from the same spec file) and enable building the Lazarus Component Library for multiple widget sets, instead of just the default GTK2. == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: == Detailed Description == The `lazarus` package will be split into multiple packages: * `lazarus-doc` - documentation * `lazarus-ide` - the IDE itself * `lazarus-lcl` - base package for the LCL (Lazarus Component Library), containing common LCL parts * `lazarus-lcl-nogui` - components for building non-graphical applications * `lazarus-lcl-gtk` - components for building programs using the GTK2 widget library * `lazarus-tools` - command-line tools shipped with Lazarus, e.g. `lazbuild` The `lazarus` package will become a metapackage - it will not contain any files itself, instead pulling in all the packages mentioned above. Several new packages will also be introduced: * `lazarus-lcl-gtk3` - support for building programs using the GTK3 widget library * `lazarus-lcl-qt` - ditto, for Qt4 * `lazarus-lcl-qt5` - ditto, for Qt5 == Benefit to Fedora == Currently, Lazarus in Fedora only supports building programs with the GTK2 widget set. With this change, Lazarus will gain support for additional widget sets, allowing users to build their applications using GTK3, Qt4 and Qt5. Maintainers of packages depending on Lazarus can switch from BuildRequiring `lazarus` to the following set: * `lazarus-lcl-nogui` (may not be needed, depending on the program) * `lazarus-lcl-gtk2` (or a different widget set, if the maintainer so wishes) * `lazarus-tools` This minimal package set is about ~60MiB smaller than the current Lazarus package. This should make builds slightly faster. == Scope == * Proposal owners: ** Edit `lazarus.spec` as required and rebuild the package, preferably before the Mass Rebuild. * Other developers: No action required. * Release engineering: No action required. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == When upgrading Fedora 39, users who have the `lazarus` package installed should see the following sub-packages pulled in during the process: * `lazarus-doc` * `lazarus-ide` * `lazarus-lcl` * `lazarus-lcl-nogui` * `lazarus-lcl-gtk2` * `lazarus-tools` This set of packages should provide the same files and functionality as the current monolithic `lazarus` package. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/lazarus-split/ copr/suve/lazarus-split]. == User Experience == For users not interested in different widget sets, this Change should not affect their experience. Those wanting to build their programs using GTK3, Qt4 or Qt5 will gain the ability to do so. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `lazarus.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `lazarus` package has been split into multiple sub-packages. Apart from GTK2, the IDE now supports building programs using the GTK3, Qt4 and Qt5 widget sets - available by installing `lazarus-lcl-*` packages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Perl 5.38 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/perl5.38
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: ,
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
F39 proposal: BiggerESP (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/BiggerESP This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The Fedora installer includes an EFI System Partition of between 200MB and 600MB by default, of which the lower size is much too small for firmware updates on modern hardware and also for future bootloader features like UKI. This change will increase the minimum size of the ESP to be 500MB, which is also the same value used by Microsoft for Windows 10 and newer. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Modern hardware has UEFI firmware updates that are more than 64MB in size. The OEMs recommend a ESP free space of double the flash size plus 20MB and fwupd now enforces this requirement to ensure flash success. As the ESP is often shared between Windows and Linux, and also used for firmware updates, and soon to be used by UKIs it's not enough to just allocate a few hundreds of megabytes. Windows 10 and 11 allocates an ESP of at least 500MiB. Arch also specifies a minimum of 512 MiB. == Feedback == There is no alternative -- the ESP has to scale up if we want firmware updates to continue to work and to support UKIs for next-generation bootloaders. == Benefit to Fedora == Firmware updates will work on future hardware, and we can boot the kernel using UKIs using next-generation bootloaders. == Scope == * Proposal owners: We need to change a number in Anaconda: https://github.com/rhinstaller/anaconda/pull/4711 == Upgrade/compatibility impact == We can't grow the ESP in size, and so this change will only affect new installs. This is fine, as this will affect new hardware more than old hardware. == How To Test == Install Fedora and observe that /boot/efi has at least 276MB free space, even when installed alongside Windows. == Dependencies == Anaconda would need to be modified, and Fedora would have a / or /home partition that's ~300MB smaller by default than it is now. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora now defaults to a larger EFI System Partition which allows firmware updates to work on newer hardware, and allows future bootloader and kernel modernizations. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This change aims at increasing the default value of the `vm.max_map_count` sysctl == Owner == * Name: [[User:aleasto| Alessandro Astone]] * Email: ales.ast...@gmail.com == Detailed Description == Increase the vm.max_map_count sysctl default value. The goal is to improve compatibility with Windows games through wine or steam. Read on "Benefit to Fedora" for examples. Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up from `65530` of Fedora; it makes sense to follow their lead and set the same value. == Feedback == This was briefly discussed in #fedora-devel and received positively. Concerns over possible downsides were raised. I am not aware of any, but more input here is desired. == Benefit to Fedora == The following Windows games will work out of the box (through wine or steam): * DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/ * Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510 * Counter Strike 2 (Beta Windows build): https://www.youtube.com/watch?v=i02n_Ak98TA * Any other software that might be invoking a lot of mmaps == Scope == * Proposal owners: Add the new default to `/usr/lib/sysctl.d/` * Other developers: No work will be necessary unless the new default is found breaking some software * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Upgrading to the new Fedora release will seamlessly update the default. No manual intervention is necessary. == How To Test == Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642` Run any of the software listed above to verify that it now works. Or run any other software to verify the change causes no regression. == User Experience == More Windows games will work out-of-the-box (through wine or steam) == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Final Freeze * Blocks release? No == Documentation == The default value is currently hard-coded in the kernel, at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203 . It cannot be changed through the kernel defconfig, instead it must be set through sysctl. == Release Notes == The default value of the vm.max_map_count sysctl is increased -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: BiggerESP (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/BiggerESP This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The Fedora installer includes an EFI System Partition of between 200MB and 600MB by default, of which the lower size is much too small for firmware updates on modern hardware and also for future bootloader features like UKI. This change will increase the minimum size of the ESP to be 500MB, which is also the same value used by Microsoft for Windows 10 and newer. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Modern hardware has UEFI firmware updates that are more than 64MB in size. The OEMs recommend a ESP free space of double the flash size plus 20MB and fwupd now enforces this requirement to ensure flash success. As the ESP is often shared between Windows and Linux, and also used for firmware updates, and soon to be used by UKIs it's not enough to just allocate a few hundreds of megabytes. Windows 10 and 11 allocates an ESP of at least 500MiB. Arch also specifies a minimum of 512 MiB. == Feedback == There is no alternative -- the ESP has to scale up if we want firmware updates to continue to work and to support UKIs for next-generation bootloaders. == Benefit to Fedora == Firmware updates will work on future hardware, and we can boot the kernel using UKIs using next-generation bootloaders. == Scope == * Proposal owners: We need to change a number in Anaconda: https://github.com/rhinstaller/anaconda/pull/4711 == Upgrade/compatibility impact == We can't grow the ESP in size, and so this change will only affect new installs. This is fine, as this will affect new hardware more than old hardware. == How To Test == Install Fedora and observe that /boot/efi has at least 276MB free space, even when installed alongside Windows. == Dependencies == Anaconda would need to be modified, and Fedora would have a / or /home partition that's ~300MB smaller by default than it is now. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora now defaults to a larger EFI System Partition which allows firmware updates to work on newer hardware, and allows future bootloader and kernel modernizations. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This change aims at increasing the default value of the `vm.max_map_count` sysctl == Owner == * Name: [[User:aleasto| Alessandro Astone]] * Email: ales.ast...@gmail.com == Detailed Description == Increase the vm.max_map_count sysctl default value. The goal is to improve compatibility with Windows games through wine or steam. Read on "Benefit to Fedora" for examples. Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up from `65530` of Fedora; it makes sense to follow their lead and set the same value. == Feedback == This was briefly discussed in #fedora-devel and received positively. Concerns over possible downsides were raised. I am not aware of any, but more input here is desired. == Benefit to Fedora == The following Windows games will work out of the box (through wine or steam): * DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/ * Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510 * Counter Strike 2 (Beta Windows build): https://www.youtube.com/watch?v=i02n_Ak98TA * Any other software that might be invoking a lot of mmaps == Scope == * Proposal owners: Add the new default to `/usr/lib/sysctl.d/` * Other developers: No work will be necessary unless the new default is found breaking some software * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Upgrading to the new Fedora release will seamlessly update the default. No manual intervention is necessary. == How To Test == Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642` Run any of the software listed above to verify that it now works. Or run any other software to verify the change causes no regression. == User Experience == More Windows games will work out-of-the-box (through wine or steam) == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Final Freeze * Blocks release? No == Documentation == The default value is currently hard-coded in the kernel, at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203 . It cannot be changed through the kernel defconfig, instead it must be set through sysctl. == Release Notes == The default value of the vm.max_map_count sysctl is increased -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 1:24 AM Benson Muite wrote: > > Thanks, this is helpful. Can you make the scripts/programs you used for > these available to allow for a more detailed analysis? No, because I literally went to each page of the archives and copied the numbers into a spreadsheet. If you want to do a more in-depth analysis, you can download the mbox archive file. On Sat, Apr 22, 2023 at 12:28 PM Zbigniew Jędrzejewski-Szmek wrote: > > Could we have the same graph for discourse (and Fedora telegram and Fedora > matrix)? It'd be interesting to see what percentage of active communicating > users are active on the mailing list. I can't provide that, but someone could do that analysis. The hard part would be mapping the email addresses to Fedora accounts, especially as those may have changed over the years (and there are theoretically people on this list who don't have a Fedora account at all). That speaks to some of the questions that come from the quick graphs I did: how many mailing list threads are of the zero-engagement announcement variety, versus active discussion? And what's the distribution of threads for users? Do most people reply to one or two threads and a handful reply to dozens? -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 4:05 PM Maxwell G wrote: > > What evidence shows that the group is ever shrinking? I often see Self > Introduction posts and new people interacting with project. I suppose > that whether they continue interacting afterwards is another question. I'm glad you asked. Earlier this week I decided to avoid doing other work by putting together some quick charts of devel list participation. Here's the number of unique participants per month from 2004–2022: https://bcotton.fedorapeople.org/images/devel-participation-monthly.png And for a less-noisy version, the median of the monthly numbers per year: https://bcotton.fedorapeople.org/images/devel-participation-mean.png There are a lot of questions left unanswered by this quick analysis, but there's a clear trend in fewer participants over time. In fact, last month had the second smallest participant count (tied with October 2022). Of course, these charts don't show _why_, but they do support the assertion that folks are dropping out of the conversation faster than others are joining. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Fedora Images on Azure (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Azure is a massive public cloud and offering an official Fedora Cloud
image there would expand Fedora's user base. It also gives Fedora
Cloud users more options when selecting public clouds.
== Owner ==
* Name: [[User:mhayden| Major Hayden]], [[User:davdunc| David Duncan]]
* Email: ma...@redhat.com, davd...@amazon.com
== Detailed Description ==
We want to:
* Get Azure images built via the existing Pungi processes
* Publish Azure images via Azure's image gallery
* Test these images during regularly scheduled Fedora Cloud test days
before final release
* Ensure that the Azure URN is linked on the Fedora website in the
cloud downloads section (similar to how AWS images are listed today)
== Feedback ==
Another alternative would be to offer a VHD download option from a
mirror, but that
would require users to download the image and upload it to Azure on
their own. This
could be challenging for users without technical skills to complete
these steps or for
users with slow network connectivity.
== Benefit to Fedora ==
* Expands Fedora's official image public cloud footprint to Azure
(currently just AWS and GCP)
* Allows Azure customers to launch official Fedora images which were
tested before launch
* Raises awareness around Fedora Cloud images
== Scope ==
* Proposal owners: Isolated change that does not affect the OS itself
but does improve its availability in public clouds.
* Other developers: Does not affect other developers or features in Fedora.
* Release engineering: [https://pagure.io/releng/issue/11398 #11398]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a net new offering in a cloud where Fedora was not previously offered.
== How To Test ==
* Verify that the Fedora image appears in Azure's image gallery
* Launch an Azure VM with the new Fedora image
* Complete the usual verification that is done on other clouds during
[https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230418.n.1_Cloud
test days]
== User Experience ==
Customers on Azure will notice that a new Fedora official images is
available to them.
Users of other platforms, such as workstation and server, will not see a change.
Customers of other clouds, such as AWS, will not see a change either.
== Dependencies ==
All dependencies are already packaged and tested. One of the biggest
is the Azure Linux
agent ({{package|WALinuxAgent}}), but it has been packaged in Fedora
for multiple releases and is
verified to work on Azure.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Cloud Edition is now available for use in Microsoft Azure.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Fedora Images on Azure (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Azure is a massive public cloud and offering an official Fedora Cloud
image there would expand Fedora's user base. It also gives Fedora
Cloud users more options when selecting public clouds.
== Owner ==
* Name: [[User:mhayden| Major Hayden]], [[User:davdunc| David Duncan]]
* Email: ma...@redhat.com, davd...@amazon.com
== Detailed Description ==
We want to:
* Get Azure images built via the existing Pungi processes
* Publish Azure images via Azure's image gallery
* Test these images during regularly scheduled Fedora Cloud test days
before final release
* Ensure that the Azure URN is linked on the Fedora website in the
cloud downloads section (similar to how AWS images are listed today)
== Feedback ==
Another alternative would be to offer a VHD download option from a
mirror, but that
would require users to download the image and upload it to Azure on
their own. This
could be challenging for users without technical skills to complete
these steps or for
users with slow network connectivity.
== Benefit to Fedora ==
* Expands Fedora's official image public cloud footprint to Azure
(currently just AWS and GCP)
* Allows Azure customers to launch official Fedora images which were
tested before launch
* Raises awareness around Fedora Cloud images
== Scope ==
* Proposal owners: Isolated change that does not affect the OS itself
but does improve its availability in public clouds.
* Other developers: Does not affect other developers or features in Fedora.
* Release engineering: [https://pagure.io/releng/issue/11398 #11398]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a net new offering in a cloud where Fedora was not previously offered.
== How To Test ==
* Verify that the Fedora image appears in Azure's image gallery
* Launch an Azure VM with the new Fedora image
* Complete the usual verification that is done on other clouds during
[https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230418.n.1_Cloud
test days]
== User Experience ==
Customers on Azure will notice that a new Fedora official images is
available to them.
Users of other platforms, such as workstation and server, will not see a change.
Customers of other clouds, such as AWS, will not see a change either.
== Dependencies ==
All dependencies are already packaged and tested. One of the biggest
is the Azure Linux
agent ({{package|WALinuxAgent}}), but it has been packaged in Fedora
for multiple releases and is
verified to work on Azure.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Cloud Edition is now available for use in Microsoft Azure.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Like many of you, I have built up a lot of workflow around my email. I'm on several dozen Fedora mailing lists, so I heavily filter my inbox. In fact, that's one of the areas where I'm least enthusiastic about a large-scale move to Fedora Discussion. Our tag-based setup makes it very difficult for Gmail (as an email client specifically) to filter alerts the way I want. On the other hand, as someone who often needs to cross-post announcements and the like, the experience for that on Discussion is so much better. And there are a lot of other quality of life improvements, some big and some small, but they add up: * The ability to move threads from "contributor" to "developer" areas and vice versa * Splitting off tangents to a new thread * Editing posts (with visible history, of course) * In-post polls * In-line date/time tags that can render the time in the user's zone Discussion isn't perfect, but it's better on the whole than I thought it would be. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
FESCo election nominations are now open
Now through 10 May, you may nominate candidates for the Fedora Engineering Steering Committee (FESCo). To nominate yourself (or others, if you check with them first), visit https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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 election nominations are now open
Now through 10 May, you may nominate candidates for the Fedora Engineering Steering Committee (FESCo). To nominate yourself (or others, if you check with them first), visit https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Tue, Apr 18, 2023 at 6:00 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2023-04-19 from 10:00:00 to 11:00:00 > America/Indiana/Indianapolis >At fedora-meetin...@irc.libera.chat > > More information available at: > https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ > Source: https://calendar.fedoraproject.org//meeting/10144/ We will discuss the following nominated bugs: * English keyboard layout is erroneously used during initramfs phase (e.g. decrypting encrypted storage devices) instead of native layout, on Silverblue / ostree installs - https://bugzilla.redhat.com/show_bug.cgi?id=1890085 * Cannot copy/paste to/from KDE VMs - https://bugzilla.redhat.com/show_bug.cgi?id=2016563 * Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader - https://bugzilla.redhat.com/show_bug.cgi?id=2049849 * Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards - https://bugzilla.redhat.com/show_bug.cgi?id=2113005 In addition, we'll check in on the following accepted bugs: * It is possible to go through the initial setup without creating a root and without adding a user to the wheel group - https://bugzilla.redhat.com/show_bug.cgi?id=2015490 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Remove webkit2gtk-4.0 API Version (System-Wide Change proposal)
:2.0.2-17.hg2084299dffb6.fc38.1.noarch gthumb-1:3.12.2-7.fc38.x86_64 liferea-1:1.14.1-1.fc38.x86_64 lutris-0:0.5.12-3.fc38.x86_64 marker-0:0.0.2020.04.04-10.fc38.x86_64 meteo-0:0.9.9.1-4.fc38.x86_64 midori-0:9.0-12.fc38.x86_64 minigalaxy-0:1.2.2-3.fc38.noarch notes-up-0:2.0.6-4.fc38.x86_64 osmo-0:0.4.4-2.fc38.x86_64 pdfpc-0:4.6.0-1.fc38.x86_64 perl-Gtk3-WebKit-0:0.06-27.fc38.noarch rednotebook-0:2.29.3-2.fc38.noarch rubygem-webkit2-gtk-0:4.1.2-1.fc38.noarch setzer-0:0.4.8-2.fc38.noarch sugar-0:0.120-2.fc38.noarch sugar-browse-0:207-6.fc38.noarch sugar-toolkit-gtk3-0:0.120-2.fc38.x86_64 surf-0:2.0-15.fc38.x86_64 ulauncher-0:5.15.2-1.fc38.noarch vfrnav-0:20201231-38.fc38.x86_64 webkit2-sharp-0:0-0.17.20170219gita59fd76.fc38.x86_64 webkit2gtk4.0-devel-0:2.40.0-2.fc38.x86_64 webkit2gtk4.0-doc-0:2.40.0-2.fc38.noarch wxGTK-webview-0:3.2.1-5.fc38.x86_64 wxGTK3-webview-0:3.0.5.1-10.fc38.x86_64 xiphos-0:4.2.1-18.fc38.x86_64 xreader-libs-0:3.6.3-1.fc38.x86_64 yad-0:9.3-5.fc38.x86_6 == Contingency Plan == * Contingency mechanism: Bring back the removed subpackages * Contingency deadline: F39 beta freeze * Blocks release? No == Documentation == * [https://webkitgtk.org/reference/webkit2gtk/stable/index.html WebKit2 - 4.1] * [https://webkitgtk.org/reference/webkit2gtk-web-extension/stable/index.html WebKit2WebExtension - 4.1] * [https://webkitgtk.org/reference/jsc-glib/stable/index.html JavaScriptCore - 4.1] * [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Soup - 3.0: Migrating from libsoup 2] == Release Notes == The webkit2gtk4.0 and javascriptcoregtk4.0 packages providing WebKitGTK for GTK 3 and libsoup 2 applications have been removed. Use the webkit2gtk4.1 and javascriptcoregtk4.1 packages instead, providing WebKitGTK for GTK 3 and libsoup 3 applications. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Remove standard storage option from Fedora EC2 images (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2ImagesNoStandardStorage This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == AWS offers multiple [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html types of block storage] depending on the needs of the individual user. Fedora images are uploaded with `standard` and `gp2` currently (`gp3` will replace `gp2` very soon with another [https://fedoraproject.org/wiki/Changes/CloudEC2gp3 approved change]). The `standard` storage is a previous generation storage option with less performance and less consistent performance than the other storage types. It also causes some confusion when AWS customers look through the list of Fedora cloud images in the EC2 console because now they see '''four''' images (aarch64 + x86_64, both with `standard` and `gp2` storage). Removing the `standard` storage option would reduce the amount of images that appear in the console, but AWS customers could still provision Fedora on standard storage during the instance creation process if they really want that storage option. == Owner == * Name: [[User:mhayden| Major Hayden]] * Email: ma...@redhat.com == Detailed Description == The scripts that upload images to AWS will be adjusted so that they do not include the creation of an AMI with standard storage. AWS customers could still choose that option at instance creation time if needed. == Feedback == No alternatives have been proposed yet. == Benefit to Fedora == This would reduce the amount of Fedora AMIs that appear in the EC2 console by half and it would ensure that Fedora lands on AWS' best performing storage (soon to be `gp3`) by default. It avoids a situation where an AWS customer (without a strong knowledge in block storage types) starts a Fedora instance on standard storage and gets a low performance experience. It would have no effect on running instances or existing AMIs. == Scope == * Proposal owners: This is an isolated change that should be made within `fedimg` and it affects only the AMI creation process. * Other developers: Should not require work from other developers. * Release engineering: No work should be required from releng for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: Should make it easier to display Fedora AWS images on the Fedora Cloud page. == Upgrade/compatibility impact == Existing systems will not be affected by this change. Customers launching new instances will get better performing storage by default but will still have the option to select standard storage if they really need it. == How To Test == 1. The updated version of fedimg should create only `gp2` (soon to be `gp3`) AMIs. 2. We can verify that the latest image upload from rawhide (after the fedimg change is made) will only include a gp2/gp3-backed image. == User Experience == AWS customers who are not familiar with different block storage types should always land on high performance storage. They still have the option to choose other storage types at instance creation time. == Dependencies == Only fedimg needs to be updated. There are no other dependencies. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora AMIs for EC2 now default to the latest `gp2/3` storage option. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Remove standard storage option from Fedora EC2 images (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2ImagesNoStandardStorage This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == AWS offers multiple [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html types of block storage] depending on the needs of the individual user. Fedora images are uploaded with `standard` and `gp2` currently (`gp3` will replace `gp2` very soon with another [https://fedoraproject.org/wiki/Changes/CloudEC2gp3 approved change]). The `standard` storage is a previous generation storage option with less performance and less consistent performance than the other storage types. It also causes some confusion when AWS customers look through the list of Fedora cloud images in the EC2 console because now they see '''four''' images (aarch64 + x86_64, both with `standard` and `gp2` storage). Removing the `standard` storage option would reduce the amount of images that appear in the console, but AWS customers could still provision Fedora on standard storage during the instance creation process if they really want that storage option. == Owner == * Name: [[User:mhayden| Major Hayden]] * Email: ma...@redhat.com == Detailed Description == The scripts that upload images to AWS will be adjusted so that they do not include the creation of an AMI with standard storage. AWS customers could still choose that option at instance creation time if needed. == Feedback == No alternatives have been proposed yet. == Benefit to Fedora == This would reduce the amount of Fedora AMIs that appear in the EC2 console by half and it would ensure that Fedora lands on AWS' best performing storage (soon to be `gp3`) by default. It avoids a situation where an AWS customer (without a strong knowledge in block storage types) starts a Fedora instance on standard storage and gets a low performance experience. It would have no effect on running instances or existing AMIs. == Scope == * Proposal owners: This is an isolated change that should be made within `fedimg` and it affects only the AMI creation process. * Other developers: Should not require work from other developers. * Release engineering: No work should be required from releng for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: Should make it easier to display Fedora AWS images on the Fedora Cloud page. == Upgrade/compatibility impact == Existing systems will not be affected by this change. Customers launching new instances will get better performing storage by default but will still have the option to select standard storage if they really need it. == How To Test == 1. The updated version of fedimg should create only `gp2` (soon to be `gp3`) AMIs. 2. We can verify that the latest image upload from rawhide (after the fedimg change is made) will only include a gp2/gp3-backed image. == User Experience == AWS customers who are not familiar with different block storage types should always land on high performance storage. They still have the option to choose other storage types at instance creation time. == Dependencies == Only fedimg needs to be updated. There are no other dependencies. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora AMIs for EC2 now default to the latest `gp2/3` storage option. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Remove webkit2gtk-4.0 API Version (System-Wide Change proposal)
:2.0.2-17.hg2084299dffb6.fc38.1.noarch gthumb-1:3.12.2-7.fc38.x86_64 liferea-1:1.14.1-1.fc38.x86_64 lutris-0:0.5.12-3.fc38.x86_64 marker-0:0.0.2020.04.04-10.fc38.x86_64 meteo-0:0.9.9.1-4.fc38.x86_64 midori-0:9.0-12.fc38.x86_64 minigalaxy-0:1.2.2-3.fc38.noarch notes-up-0:2.0.6-4.fc38.x86_64 osmo-0:0.4.4-2.fc38.x86_64 pdfpc-0:4.6.0-1.fc38.x86_64 perl-Gtk3-WebKit-0:0.06-27.fc38.noarch rednotebook-0:2.29.3-2.fc38.noarch rubygem-webkit2-gtk-0:4.1.2-1.fc38.noarch setzer-0:0.4.8-2.fc38.noarch sugar-0:0.120-2.fc38.noarch sugar-browse-0:207-6.fc38.noarch sugar-toolkit-gtk3-0:0.120-2.fc38.x86_64 surf-0:2.0-15.fc38.x86_64 ulauncher-0:5.15.2-1.fc38.noarch vfrnav-0:20201231-38.fc38.x86_64 webkit2-sharp-0:0-0.17.20170219gita59fd76.fc38.x86_64 webkit2gtk4.0-devel-0:2.40.0-2.fc38.x86_64 webkit2gtk4.0-doc-0:2.40.0-2.fc38.noarch wxGTK-webview-0:3.2.1-5.fc38.x86_64 wxGTK3-webview-0:3.0.5.1-10.fc38.x86_64 xiphos-0:4.2.1-18.fc38.x86_64 xreader-libs-0:3.6.3-1.fc38.x86_64 yad-0:9.3-5.fc38.x86_6 == Contingency Plan == * Contingency mechanism: Bring back the removed subpackages * Contingency deadline: F39 beta freeze * Blocks release? No == Documentation == * [https://webkitgtk.org/reference/webkit2gtk/stable/index.html WebKit2 - 4.1] * [https://webkitgtk.org/reference/webkit2gtk-web-extension/stable/index.html WebKit2WebExtension - 4.1] * [https://webkitgtk.org/reference/jsc-glib/stable/index.html JavaScriptCore - 4.1] * [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Soup - 3.0: Migrating from libsoup 2] == Release Notes == The webkit2gtk4.0 and javascriptcoregtk4.0 packages providing WebKitGTK for GTK 3 and libsoup 2 applications have been removed. Use the webkit2gtk4.1 and javascriptcoregtk4.1 packages instead, providing WebKitGTK for GTK 3 and libsoup 3 applications. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Getting back the old Bugzilla bug entry form
Mea culpa. My understanding was that this would not impact the sorts of use cases that were broken. Clearly that's not the case. Regardless, this should have been better communicated and tested. I take full responsibility for that; I should know better. I'll work with the Bugzilla developers to get this fixed or rolled back if it can't be. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
The current target is the early target date (18 April). Action summary Accepted blockers - 1. shim — Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards — NEW ACTION: kernel upstream to merge NX support Proposed blockers - 1. fedora-release — Fedora 38 Final needs a non-prerelease fedora-release package and fedora-repos with updates-testing disabled — MODIFIED ACTION: QA to verify update FEDORA-2023-ae8bf65eea Bug-by-bug detail = Accepted blockers - 1. shim — https://bugzilla.redhat.com/show_bug.cgi?id=2113005 — NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel, which is still pending upstream. Proposed blockers - 1. fedora-release — https://bugzilla.redhat.com/show_bug.cgi?id=2185122 — MODIFIED Fedora 38 Final needs a non-prerelease fedora-release package and fedora-repos with updates-testing disabled Currently fedora-release and fedora-repos are in a pre-release state. Update https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae8bf65eea contains a candidate fix. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 Final Go/No-Go meeting next week
The Fedora Linux 38 Final Go/No-Go[1] meeting is scheduled for Thursday 13 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Final for the 18 April early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10487/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 38 Final Go/No-Go meeting next week
The Fedora Linux 38 Final Go/No-Go[1] meeting is scheduled for Thursday 13 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Final for the 18 April early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10487/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Thursday's FPC Meeting (2023-04-06 16:00 UTC)
On Wed, Apr 5, 2023 at 9:39 PM James Antill wrote: > > Following is the list of topics that will be discussed in the FPC > meeting Thursday at 2023-04-06 16:00 UTC in #fedora-meeting-1 on > irc.libera.chat. Can you add https://pagure.io/packaging-committee/pull-request/1255 if time permits? This blocks the implementation of the "Rpmautospec by Default" Change. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Tue, Apr 4, 2023 at 6:00 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2023-04-05 from 10:00:00 to 11:00:00 > America/Indiana/Indianapolis >At fedora-meetin...@irc.libera.chat > > More information available at: > https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ > Source: https://calendar.fedoraproject.org//meeting/10144/ There are 0 nominated bugs and the 1 accepted bug is making progress, so I am cancelling the Prioritized Bugs meeting. We'll meet again 19 April. As a reminder, this process exists but it only works if you nominate bugs. See https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/#_nomination for the kinds of bugs to nominate. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
The current target is the early target date (18 April). Action summary Accepted blockers - 1. kernel — anaconda failed to detect the fcoe target(only affects ixgbe) — NEW ACTION: Maintainers to diagnose issue NEEDINFO: lnie 2. plasma-workspace — Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen — NEW ACTION: Maintainers to diagnose issue 3. shim — Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards — NEW ACTION: kernel upstream to merge NX support Proposed blockers - 1. abrt — crash data are erased occasionally — VERIFIED ACTION: (none) 2. Podman — shadow-utils installations fails with “cap_set_file failed” in toolbox/podman on F38 host ACTION: Maintainers to diagnose issue Bug-by-bug detail = Accepted blockers - 1. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=2171350 — NEW anaconda failed to detect the fcoe target(only affects ixgbe) The installer does not detect attached FCOE storage using ixgbe. The device ends up in "NO-CARRIER state DORNMANT". 2. plasma-workspace — https://bugzilla.redhat.com/show_bug.cgi?id=2179591 — NEW Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen In some cases, a race condition prevents a user on a system from logging out successfully. This appears to be an SELinux issue filed as RHBZ 2181010 for which FEDORA-2023-624eb88729 contains a verified fix. It seems that a failure of dbus-:1.2-org.kde.LogoutPrompt@0.service causes the sddm session to not be restarted. 3. shim — https://bugzilla.redhat.com/show_bug.cgi?id=2113005 — NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel, which is still pending upstream. Proposed blockers - 1. abrt — https://bugzilla.redhat.com/show_bug.cgi?id=2177153 — VERIFIED MaxCrashReportsSize claims to be 5000 MB but is 1000 MB abrt is using a smaller size limit than the hard-coded default of 5000 MB. FEDORA-2023-eb09dd6406 containes a verified fix. 2. podman — https://bugzilla.redhat.com/show_bug.cgi?id=2183034 — NEW packages with file capabilities fail to install in podman on F38 host DNF update in a freshly-created f38 toolbox fails. The issue seems to only happen on F38 hosts; shadow-utlis is updatable in an F36 and F37 container and host using podman 4.4.1. Suspected issue is a change in Podman between 4.4.2 -> 4.4.3 or a different config file in F38. This does not appear to be specific to the shadow-utils package. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: RPM 4.19 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RPM-4.19 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.19.0 4.19] release. == Owner == * Name: [[User:ffesti| Florian Festi]] * Email: ffe...@redhat.com == Detailed Description == RPM 4.19 contains various improvements over previous versions. Many of them are internal in nature such as moving from automake to cmake, improvements to the test suite, stripping copies of system functions, splitting translations into a separate project and more. There are still several user facing changes: * New rpmsort(8) utility for sorting RPM versions * x86-64 architecture levels (v2-v4) as architectures * Support for %preuntrans and %postuntrans scriptlets * Creating User and Groups from sysusers.d files including Provides and Requires or Recommends ([https://github.com/rpm-software-management/rpm/pull/2432 PR], [https://github.com/rpm-software-management/rpm/discussions/2277 Discussion]) * [https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html Dynamic Spec generation] ** find_lang now being able to generate language sub packages The 4.19 alpha release is expected in April and the final release is expected in time for the Fedora 39 release cycle as usual. == Feedback == == Benefit to Fedora == This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above. == Scope == * Proposal owners: ** Release RPM 4.19 alpha ** Rebase RPM ** Assist with dealing with incompatibilities ** Integrate new User/Group handling *** Conflicts with the current one including the Provides generation in ''systemd-rpm-macros'' * Other developers: ** Test new release, report issues and bugs * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == * %patch without arguments and options is an error * %patchN syntax is deprecated * File globbing is now more consistent == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == * Deprecated APIs are removed. This may require adjustments to software still using them. * so-name of librpm changes. Packages depending on it are expected to need a re-build * Packages running in the changes mentioned in the ''Upgrade/compatibility impact'' section might need adjusting. This should be relatively rare, though. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.18 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Release notes at https://rpm.org/wiki/Releases/4.19.0 and reference manual at https://rpm-software-management.github.io/rpm/manual/ == Release Notes == https://rpm.org/wiki/Releases/4.19.0 (still work in progress) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: RPM 4.19 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RPM-4.19 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.19.0 4.19] release. == Owner == * Name: [[User:ffesti| Florian Festi]] * Email: ffe...@redhat.com == Detailed Description == RPM 4.19 contains various improvements over previous versions. Many of them are internal in nature such as moving from automake to cmake, improvements to the test suite, stripping copies of system functions, splitting translations into a separate project and more. There are still several user facing changes: * New rpmsort(8) utility for sorting RPM versions * x86-64 architecture levels (v2-v4) as architectures * Support for %preuntrans and %postuntrans scriptlets * Creating User and Groups from sysusers.d files including Provides and Requires or Recommends ([https://github.com/rpm-software-management/rpm/pull/2432 PR], [https://github.com/rpm-software-management/rpm/discussions/2277 Discussion]) * [https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html Dynamic Spec generation] ** find_lang now being able to generate language sub packages The 4.19 alpha release is expected in April and the final release is expected in time for the Fedora 39 release cycle as usual. == Feedback == == Benefit to Fedora == This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above. == Scope == * Proposal owners: ** Release RPM 4.19 alpha ** Rebase RPM ** Assist with dealing with incompatibilities ** Integrate new User/Group handling *** Conflicts with the current one including the Provides generation in ''systemd-rpm-macros'' * Other developers: ** Test new release, report issues and bugs * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == * %patch without arguments and options is an error * %patchN syntax is deprecated * File globbing is now more consistent == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == * Deprecated APIs are removed. This may require adjustments to software still using them. * so-name of librpm changes. Packages depending on it are expected to need a re-build * Packages running in the changes mentioned in the ''Upgrade/compatibility impact'' section might need adjusting. This should be relatively rare, though. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.18 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Release notes at https://rpm.org/wiki/Releases/4.19.0 and reference manual at https://rpm-software-management.github.io/rpm/manual/ == Release Notes == https://rpm.org/wiki/Releases/4.19.0 (still work in progress) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: GitHub.com SSH host key changed
Public service announcement for anyone who uses GitHub: they have changed their SSH host key as a result of an inadvertent disclosure. See their blog for more information: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
load requests. 3. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2180277 — NEW gnome-shell crashes and sysops happens when users logout Logging out sometimes causes a crash. It may be caused by trying to exit with open windows. An upstream MR contains work-in-progress fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2722/ 4. gnome-software — https://bugzilla.redhat.com/show_bug.cgi?id=2181367 — MODIFIED Incorrect priority order of app sources Contrary to FESCo's requirement for the Unfiltered Flathub Change, flatpaks from Flathub sometimes take priority over Fedora RPMs. FEDORA-2023-49b5dec107 contains a candidate fix. 5. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2179591 — NEW Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen In some cases, a race condition prevents the second user on a system from logging out successfully. This appears to be an SELinux issue filed as RHBZ 2181010. An upstream PR contains a candidate fix: https://github.com/fedora-selinux/selinux-policy/pull/1628 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option. This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI. With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI. By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types. == Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2. == Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack. == Scope == * Proposal owners: * Modify the AMI registration call to include `uefi-preferred`, verifying that Fedora AMIs are assembled correctly for booting under UEFI. * Other developers: No changes needed by other developers * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == Once the AMI is registered, verify that the parameter is set, and that instances can be launched for each instance type. Normal testing should cover this. == User Experience == Users will be able to use features in EC2 that require UEFI such as Secure Boot and NitroTPM. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html * https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html == Release Notes == EC2 images are now registered with the `uefi-preferred` boot mode, thus boot in UEFI mode where possible. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option. This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI. With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI. By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types. == Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2. == Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack. == Scope == * Proposal owners: * Modify the AMI registration call to include `uefi-preferred`, verifying that Fedora AMIs are assembled correctly for booting under UEFI. * Other developers: No changes needed by other developers * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == Once the AMI is registered, verify that the parameter is set, and that instances can be launched for each instance type. Normal testing should cover this. == User Experience == Users will be able to use features in EC2 that require UEFI such as Secure Boot and NitroTPM. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html * https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html == Release Notes == EC2 images are now registered with the `uefi-preferred` boot mode, thus boot in UEFI mode where possible. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
with the changes we can revert them in createrepo_c. * Contingency deadline: 2023-08-01 * Blocks release? No == Documentation == Createrepo_c documentation will be updated accordingly. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
with the changes we can revert them in createrepo_c. * Contingency deadline: 2023-08-01 * Blocks release? No == Documentation == Createrepo_c documentation will be updated accordingly. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Register EC2 Cloud Images with IMDSv2-only AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2IMDSv2Only This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In November 2019, AWS launched IMDSv2 (Instance Meta-Data Store version 2 - see https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ ) which provides "belt and suspenders" protections for four types of vulnerabilities that could be used to try to access the Instance Meta-Data Store available to EC2 instances. In that announcement, AWS recommended adopting IMDSv2 and restricting access to IMDSv2 only for added security. This can be done at instance launch time, or ([https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ more recently in October 2022]) by providing a flag when registering an AMI to indicate that the AMI should by default launch with IMDSv1 disabled, and thus require IMDSv2. By enabling this flag for Fedora, we provide a better security posture for Fedora users running in EC2. When an AMI is registered for IMDSv2 it is still possible to launch instances with IMDSv1 enabled by providing the right option to the RunInstances EC2 API call. The flag merely switches the default. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Attached locally to every EC2 instance, the Instance Meta-Data Service runs on a special "link local" IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance. IMDS is the primary data source for `cloud-init` on EC2, and various other utilities will also access it. The [https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ IMDSv2 announcement] gives more details as to the "belt and suspenders" protections it brings for four types of vulnerabilities that could be used to try to access the IMDS. By default, registering and then launching an AMI will launch an EC2 instance where both IMDSv1 and IMDSv2 is enabled. A recent addition to the EC2 API is the ability to register an AMI with a flag that indicates that the default behavior when launching an instance should be to have IMDSv2 enabled, and disable IMDSv1. The proposal is to (starting with Fedora 39), [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration register EC2 AMIs with this flag set as documented in the EC2 User Guide]. == Feedback == While Amazon Linux 2023 (then called AL2022) was in Tech Preview, its AMIs have been registered with this flag the [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ flag was announced in October 2022]. During this time, we have not received any negative feedback about this change. The only user of IMDSv1 calls that we have so far had to migrate to IMDSv2 calls has been some internal test cases run by a service team. == Benefit to Fedora == This change will provide Fedora users on EC2 with an enhanced security posture by default. == Scope == * Proposal owners: Modify AMI registration to include the flag. No other technical work is required. * Other developers: Any remaining code that talks to IMDS that does not use IMDSv2 will need to be adapted to continue to work by default. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No impact for existing EC2 Instances. The AMI flag only affects new instance launches. == How To Test == Testing will not change from any regular Fedora EC2 AMI. The only additional check will need to be that the parameter is set correctly. == User Experience == This change should be transparent to users. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send
F39 proposal: EC2 AMIs default to the gp3 EBS volume type (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2gp3 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In Amazon EC2, Elastic Block Store (EBS) volumes can be one of several types. These can be specified at volume creation time, including for the default volumes that are created on instance launch. An AMI will have default volumes and volume types configured. Fedora currently defaults to the gp2 volume type. This proposal is to switch to gp3 as the default volume type for Fedora. The gp3 volume type is both more flexible than gp2, and can be up to 20% cheaper per GB. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == According to https://aws.amazon.com/ebs/general-purpose/ : : Amazon EBS gp3 volumes are the latest generation of general-purpose SSD-based EBS volumes that enable customers to provision performance independent of storage capacity, while providing up to 20% lower price per GB than existing gp2 volumes. With gp3 volumes, customers can scale IOPS (input/output operations per second) and throughput without needing to provision additional block storage capacity. This means customers only pay for the storage they need. For the default configuration of Fedora 37 AMIs, this means the price per-GB-per-month for the default root volume would be $0.08 rather than $0.10. The default number of provisioned IOPs would increase from 100 with gp2, to 3000 with gp3. For gp2 volumes less than 1TB, they can burst up to 3000 IOPs (see [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp2-performance GP2 volume performance]), while gp3 volumes provide a constant 3000 IOPs rather than only being able to burst to that number before running out of IO credits. == Feedback == Amazon Linux 2023 has switched to gp3 over the Amazon Linux 2 default of gp2, and we have not received any negative feedback on that change. == Benefit to Fedora == The benefit for Fedora users in EC2 is that of cheaper, more predictable, higher base-IOP, and more flexible IO performance by default. Fedora will also be switching to use the latest generation in general purpose EBS volume, fitting the desire of being First. == Scope == * Proposal owners: * Change gp2 to gp3 in AMI registration. * Other developers: N/A * Release engineering: * Policies and guidelines: N/A (not needed for this Change) --> * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No affect on upgrades. Existing volumes remain gp2, and the volume type can be set on instance launch if gp3 is not preferred. == How To Test == No additional testing required beyond normal Fedora testing. == User Experience == This change will be largely transparent to users who take the default configuration, and do not run into IO limits on gp2 volumes today. The change for those users will be purely in reduced costs. For users who hit the burst limits of gp2, this change will improve IOP throughput to a constant 3000 IOPS. With the default volume size there is a slight throughput change when going from gp2 to gp3 (128MB/sec to 125MB/sec). == Dependencies == No dependencies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == EC2 documentation details differences between gp2 and gp3: - https://aws.amazon.com/ebs/general-purpose/ - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Register EC2 Cloud Images with IMDSv2-only AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2IMDSv2Only This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In November 2019, AWS launched IMDSv2 (Instance Meta-Data Store version 2 - see https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ ) which provides "belt and suspenders" protections for four types of vulnerabilities that could be used to try to access the Instance Meta-Data Store available to EC2 instances. In that announcement, AWS recommended adopting IMDSv2 and restricting access to IMDSv2 only for added security. This can be done at instance launch time, or ([https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ more recently in October 2022]) by providing a flag when registering an AMI to indicate that the AMI should by default launch with IMDSv1 disabled, and thus require IMDSv2. By enabling this flag for Fedora, we provide a better security posture for Fedora users running in EC2. When an AMI is registered for IMDSv2 it is still possible to launch instances with IMDSv1 enabled by providing the right option to the RunInstances EC2 API call. The flag merely switches the default. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Attached locally to every EC2 instance, the Instance Meta-Data Service runs on a special "link local" IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance. IMDS is the primary data source for `cloud-init` on EC2, and various other utilities will also access it. The [https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ IMDSv2 announcement] gives more details as to the "belt and suspenders" protections it brings for four types of vulnerabilities that could be used to try to access the IMDS. By default, registering and then launching an AMI will launch an EC2 instance where both IMDSv1 and IMDSv2 is enabled. A recent addition to the EC2 API is the ability to register an AMI with a flag that indicates that the default behavior when launching an instance should be to have IMDSv2 enabled, and disable IMDSv1. The proposal is to (starting with Fedora 39), [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration register EC2 AMIs with this flag set as documented in the EC2 User Guide]. == Feedback == While Amazon Linux 2023 (then called AL2022) was in Tech Preview, its AMIs have been registered with this flag the [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ flag was announced in October 2022]. During this time, we have not received any negative feedback about this change. The only user of IMDSv1 calls that we have so far had to migrate to IMDSv2 calls has been some internal test cases run by a service team. == Benefit to Fedora == This change will provide Fedora users on EC2 with an enhanced security posture by default. == Scope == * Proposal owners: Modify AMI registration to include the flag. No other technical work is required. * Other developers: Any remaining code that talks to IMDS that does not use IMDSv2 will need to be adapted to continue to work by default. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No impact for existing EC2 Instances. The AMI flag only affects new instance launches. == How To Test == Testing will not change from any regular Fedora EC2 AMI. The only additional check will need to be that the parameter is set correctly. == User Experience == This change should be transparent to users. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists
F39 proposal: EC2 AMIs default to the gp3 EBS volume type (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2gp3 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In Amazon EC2, Elastic Block Store (EBS) volumes can be one of several types. These can be specified at volume creation time, including for the default volumes that are created on instance launch. An AMI will have default volumes and volume types configured. Fedora currently defaults to the gp2 volume type. This proposal is to switch to gp3 as the default volume type for Fedora. The gp3 volume type is both more flexible than gp2, and can be up to 20% cheaper per GB. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == According to https://aws.amazon.com/ebs/general-purpose/ : : Amazon EBS gp3 volumes are the latest generation of general-purpose SSD-based EBS volumes that enable customers to provision performance independent of storage capacity, while providing up to 20% lower price per GB than existing gp2 volumes. With gp3 volumes, customers can scale IOPS (input/output operations per second) and throughput without needing to provision additional block storage capacity. This means customers only pay for the storage they need. For the default configuration of Fedora 37 AMIs, this means the price per-GB-per-month for the default root volume would be $0.08 rather than $0.10. The default number of provisioned IOPs would increase from 100 with gp2, to 3000 with gp3. For gp2 volumes less than 1TB, they can burst up to 3000 IOPs (see [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp2-performance GP2 volume performance]), while gp3 volumes provide a constant 3000 IOPs rather than only being able to burst to that number before running out of IO credits. == Feedback == Amazon Linux 2023 has switched to gp3 over the Amazon Linux 2 default of gp2, and we have not received any negative feedback on that change. == Benefit to Fedora == The benefit for Fedora users in EC2 is that of cheaper, more predictable, higher base-IOP, and more flexible IO performance by default. Fedora will also be switching to use the latest generation in general purpose EBS volume, fitting the desire of being First. == Scope == * Proposal owners: * Change gp2 to gp3 in AMI registration. * Other developers: N/A * Release engineering: * Policies and guidelines: N/A (not needed for this Change) --> * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No affect on upgrades. Existing volumes remain gp2, and the volume type can be set on instance launch if gp3 is not preferred. == How To Test == No additional testing required beyond normal Fedora testing. == User Experience == This change will be largely transparent to users who take the default configuration, and do not run into IO limits on gp2 volumes today. The change for those users will be purely in reduced costs. For users who hit the burst limits of gp2, this change will improve IOP throughput to a constant 3000 IOPS. With the default volume size there is a slight throughput change when going from gp2 to gp3 (128MB/sec to 125MB/sec). == Dependencies == No dependencies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == EC2 documentation details differences between gp2 and gp3: - https://aws.amazon.com/ebs/general-purpose/ - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
ound does not appear to work. 7. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2175809 — VERIFIED Session crash when reverting Display settings Applying a change to Display settings and then reverting (or pressing Escape when presented with the revert dialog) results in a crash. Letting the dialog window time out does not crash. FEDORA-2023-6cec60a347 contains a verified fix. 8. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2177982 — VERIFIED Crash when using Win+P shortcut Using Win+P to switch between displays configuration crashes gnome-shell. FEDORA-2023-6cec60a347 contains a verified fix. 9. nautilus — https://bugzilla.redhat.com/show_bug.cgi?id=2176766 — VERIFIED Dragging files is Nautilus doesn't work as expected, quick movements result in a selection box instead In order to successfully drag-and-drop a file, you must first hold the mouse still with the left button pressed for ~half a second. FEDORA-2023-287e6e502b contains a verified fix. 10. openssh — https://bugzilla.redhat.com/show_bug.cgi?id=2172956 — POST Update hostkey migration to support OSTree systems and dynamically detect hostkey location rpm-ostree systems don't run RPM scriptlets on upgrade, which could result in an upgrade locking users out of remote machines. Package pull requests https://src.fedoraproject.org/rpms/fedora-release/pull-request/253 and https://src.fedoraproject.org/rpms/openssh/pull-request/45 contain a candidate fix. 11. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2174563 — NEW Virtual keyboard (on-screen) not working at sddm-wayland-plasma The virtual keyboard at the login screen does not appear when you click the appropriate button. This appears to be a Wayland-specific issue; reverting to X11 allows the keyboard to work as expected. 12. shim — https://bugzilla.redhat.com/show_bug.cgi?id=2113005 — NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel, which is still pending upstream. Proposed blockers - 1. f38-backgrounds — https://bugzilla.redhat.com/show_bug.cgi?id=2178172 — VERIFIED The default wallpaper isn't listed among available wallpapers The default background is correctly applied, but if the users switches to a different wallpaper, the default is not visible in the selection. FEDORA-2023-359dafca1d contains a verified fix. 2. gnome-abrt — https://bugzilla.redhat.com/show_bug.cgi?id=2177153 — NEW crash data are erased occasionally It appears that abrt is removing report data when disk usage exceeds a threshold, but it's not clear why the reporter is expericing this worse than others. There may be some user experience improvements to make. In any case, the vote looks likely to be for rejecting this as a blocker. 3. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2177993 — NEW Crash/Hang when clicking a modified Google event right after editing it (due to the preview popover) Clicking on a remote event immediately after editing it results in either a crash or an unresponsive window. Waiting a few seconds before clicking results in expected behavior. 4. ibus — https://bugzilla.redhat.com/show_bug.cgi?id=2156108 — MODIFIED ibus: XFree(): ibus-x11 killed by SIGABRT Typing is sometimes "sluggish" with frequent pauses. Eventually ibus crashes. FEDORA-2023-e0df9e598e contains a candidate fix. 5. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2178167 — POST Fullscreen mode is broken for many games Many games fail to work in fullscreen and if they launch in fullscreen, they may not be usable at all. Upstream MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2910 contains a candidate fix. 6. xdg-desktop-portal-kde — https://bugzilla.redhat.com/show_bug.cgi?id=2178971 — NEW xdg-desktop-portal-kde is launching and crashing when SDDM launches the Wayland greeter When the greeter launches, xdg-desktop-portal-kde also launches and crashes. This appears to only happen on Wayland. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)
es/list/de...@lists.fedoraproject.org/thread/EXGT34EJPG3G4FJZ4R2SRAI342QDHFOF/ SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NZIFT62REORSNS6MMES446PMCOOSEPSA/ SPDX Change Update] * [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/ SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main|fedora-license-data] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitates efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Prep work: ** poll package maintainers on methods and tools used for license inspection ** create additional guidance (using info from above) ** planning/brainstorming on most efficient way to update packages, especially those that do not have one-to-one identifier update and will need closer inspection * Proposal owners (things sorted by done/todo and by priorities): ** Identify all remaining packages. ** Notify owners of these packages. ** After a grace period, submit PR to a package where the transition is easy. ** Create tracking BZ for packages with unclear transition path ** Submit BZ for packages that cannot migrate in time. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Licensing page will need to be altered. But almost all the work has been done in Phase 1. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We either rollback in Phase 1. Once we will start Phase 2 we will be beyond of point with no return. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package == Documentation == [https://docs.fedoraproject.org/en-US/legal/allowed-licenses/|Allowed Licenses] [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used Update existing packages] == Release Notes == In Fedora 39, RPM packages use SPDX identifiers as a standard. Almost all packages have been migrated to SPDX identifiers. The remaining packages are tracked in this tracking Bugzilla issue. LINK TO BE ADDED -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)
list/devel@lists.fedoraproject.org/thread/EXGT34EJPG3G4FJZ4R2SRAI342QDHFOF/ SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NZIFT62REORSNS6MMES446PMCOOSEPSA/ SPDX Change Update] * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/ SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main|fedora-license-data] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitates efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Prep work: ** poll package maintainers on methods and tools used for license inspection ** create additional guidance (using info from above) ** planning/brainstorming on most efficient way to update packages, especially those that do not have one-to-one identifier update and will need closer inspection * Proposal owners (things sorted by done/todo and by priorities): ** Identify all remaining packages. ** Notify owners of these packages. ** After a grace period, submit PR to a package where the transition is easy. ** Create tracking BZ for packages with unclear transition path ** Submit BZ for packages that cannot migrate in time. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Licensing page will need to be altered. But almost all the work has been done in Phase 1. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We either rollback in Phase 1. Once we will start Phase 2 we will be beyond of point with no return. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package == Documentation == [https://docs.fedoraproject.org/en-US/legal/allowed-licenses/|Allowed Licenses] [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used Update existing packages] == Release Notes == In Fedora 39, RPM packages use SPDX identifiers as a standard. Almost all packages have been migrated to SPDX identifiers. The remaining packages are tracked in this tracking Bugzilla issue. LINK TO BE ADDED -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bugz.fedoraproject.org links
An issue was filed earlier today: https://pagure.io/fedora-infrastructure/issue/11192 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
ot appear to fully undelete it. 7. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2175809 — POST Session crash when reverting Display settings Applying a change to Display settings and then reverting (or pressing Escape when presented with the revert dialog) results in a crash. Letting the dialog window time out does not crash. Upstream MR contains a candidate fix: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901 8. nautilus — https://bugzilla.redhat.com/show_bug.cgi?id=2176766 — NEW Dragging files is Nautilus doesn't work as expected, quick movements result in a selection box instead In order to successfully drag-and-drop a file, you must first hold the mouse still with the left button pressed for ~half a second. 9. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2176782 — NEW SDDM doesn't start in basic graphics mode in BIOS mode In BIOS mode only, sddm results in a blank screen when using basic graphics mode. This may be the result of a SimpleDRM device not being created. 10. totem — https://bugzilla.redhat.com/show_bug.cgi?id=2176726 — NEW totem crashes everytime when users try to delete a video Deleting a video results in an application crash, but only when there is only one video. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 Beta is GO
The Fedora Linux 38 Beta RC1,3 compose[1] is GO and will be shipped live on Tuesday, 14 March. The F38 Final freeze begins Tuesday 4 April. For more information please check the Go/No-Go meeting minutes[2] or log[3]. [1] https://download.fedoraproject.org/pub/alt/stage/38_Beta-1.3/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.log.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] F38 Beta is GO
The Fedora Linux 38 Beta RC1,3 compose[1] is GO and will be shipped live on Tuesday, 14 March. The F38 Final freeze begins Tuesday 4 April. For more information please check the Go/No-Go meeting minutes[2] or log[3]. [1] https://download.fedoraproject.org/pub/alt/stage/38_Beta-1.3/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.log.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: FontAwesome6 (Self-Contained Change proposal)
-guidelines/FontsPolicy/#_dependencies_to_font_packages_in_other_packages the font guidelines]. *** coq *** libgpuarray *** libsemigroups *** python-BTrees *** python-primecountpy *** python-sphinx_rtd_theme * Other developers: Maintainers of the packages listed above will need to review the proposed changes and merge them if they are acceptable. Afterwards, I will build all packages in a side tag and merge to Rawhide once all builds are complete. * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Initiatives: == Upgrade/compatibility impact == Users should not notice this change, except for having fewer bundled copies of the FontAwesome icons on disk. == How To Test == Install packages from the [https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6 the FontAwesome6 COPR]. Launch each one and verify that it displays the expected icons. == User Experience == Users should not see any changes, except for a disk space savings if they have more than one affected package installed. == Dependencies == All dependencies are listed above and will be updated together. If maintainers do not respond to pull requests in a timely manner, then provenpackager privileges can be used to merge the pull requests and do the builds together. The definition of "timely manner" is up for debate. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), == Documentation == N/A (not a System Wide Change) == Release Notes == The fontawesome-fonts package has been upgraded to version 6.3.0, and a compatibility fontawesome4-fonts package has been introduced for applications that still require FontAwesome 4.7.0. For packages that can use the FontAwesome 6.x icons, the changes described in [https://fontawesome.com/docs/changelog/ the FontAwesome changelog] are now available. Packages that use the FontAwesome 4.x icons do not have any user-visible changes. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: FontAwesome6 (Self-Contained Change proposal)
-guidelines/FontsPolicy/#_dependencies_to_font_packages_in_other_packages the font guidelines]. *** coq *** libgpuarray *** libsemigroups *** python-BTrees *** python-primecountpy *** python-sphinx_rtd_theme * Other developers: Maintainers of the packages listed above will need to review the proposed changes and merge them if they are acceptable. Afterwards, I will build all packages in a side tag and merge to Rawhide once all builds are complete. * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Initiatives: == Upgrade/compatibility impact == Users should not notice this change, except for having fewer bundled copies of the FontAwesome icons on disk. == How To Test == Install packages from the [https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6 the FontAwesome6 COPR]. Launch each one and verify that it displays the expected icons. == User Experience == Users should not see any changes, except for a disk space savings if they have more than one affected package installed. == Dependencies == All dependencies are listed above and will be updated together. If maintainers do not respond to pull requests in a timely manner, then provenpackager privileges can be used to merge the pull requests and do the builds together. The definition of "timely manner" is up for debate. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), == Documentation == N/A (not a System Wide Change) == Release Notes == The fontawesome-fonts package has been upgraded to version 6.3.0, and a compatibility fontawesome4-fonts package has been introduced for applications that still require FontAwesome 4.7.0. For packages that can use the FontAwesome 6.x icons, the changes described in [https://fontawesome.com/docs/changelog/ the FontAwesome changelog] are now available. Packages that use the FontAwesome 4.x icons do not have any user-visible changes. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Upcoming summer time changes
As a reminder to the community, we've reached the point in the year where jurisdictions around the world begin or end summer time. Be sure to check your recurring meetings on Fedocal[1] to make sure you know when you're meeting. Some meetings are set to a fixed time UTC and others are set to a particular time zone. A global list of time changes is available by country[2] and by date[3], but here are a few highlights: 13 Mar — summer time begins in Canada, parts of Mexico, and the US 27 Mar — summer time begins in the EU and UK 3 Apr — summer time begins in most of Mexico, summer time ends in Australia [1] https://calendar.fedoraproject.org/ [2] https://www.timeanddate.com/time/dst/2023.html [3] https://www.timeanddate.com/time/dst/2023a.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Upcoming summer time changes
As a reminder to the community, we've reached the point in the year where jurisdictions around the world begin or end summer time. Be sure to check your recurring meetings on Fedocal[1] to make sure you know when you're meeting. Some meetings are set to a fixed time UTC and others are set to a particular time zone. A global list of time changes is available by country[2] and by date[3], but here are a few highlights: 13 Mar — summer time begins in Canada, parts of Mexico, and the US 27 Mar — summer time begins in the EU and UK 3 Apr — summer time begins in most of Mexico, summer time ends in Australia [1] https://calendar.fedoraproject.org/ [2] https://www.timeanddate.com/time/dst/2023.html [3] https://www.timeanddate.com/time/dst/2023a.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
The current target release date is the early target date (2023-03-14). The Go/No-Go meeting will be Thursday! Action summary Accepted blockers - 1. distribution — Workstation boot x86_64 image exceeds maximum size — POST ACTION: gdb maintainers to remove the 'Recommends' for gcc-gdb-plugin from gdb 2. crypto-policies — Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed — NEW ACTION: Upstream to implement MR #129 Proposed blockers - 1. gnome-session — reboot/poweroff/logout from GNOME are 60 seconds delayed without 3D acceleration — NEW ACTION: Maintainers to diagnose issue 2. gnupg2 — revert the RFC4880bis from defaults — NEW ACTION: Maintainers to revert inclusion of RFC4880bis 3. initial-setup — User creation and root password setting do not work on minimal install, so cannot log into installed system — NEW ACTION: Maintainers to diagnose issue 4. kernel — Black screen when amdgpu started during 6.2-rc1 boot with AMD IOMMU enabled — NEW ACTION: Maintainers to package update which includes upstream patches 5. mutter — XWayland apps steal focus — NEW ACTION: Maintainers to build update with upstream merge request 6. sddm — Virtual keyboard (on-screen) not working at sddm-wayland-plasma — NEW ACTION: Maintainers to diagnose issue Bug-by-bug detail = Accepted blockers - 1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2149246 — POST Workstation boot x86_64 image exceeds maximum size Changes to linux-firmware briefly brought the Worktation image below the limit. Removing the recommendation (in gdb) of gcc-gdb-plugin, which is "largely broken", should reduce the image size below limits. 2. crypto-policies — https://bugzilla.redhat.com/show_bug.cgi?id=2170878 — NEW Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed Some third-party repos (including Google Chrome) that sign packages with SHA-1 cannot be uninstalled, which breaks upgrades. This was designated a blocker by FESCo. Work is in progress upstream to allow RPM to permit SHA-1 in the default policy while third-party repos update to a supported hash function: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 Proposed blockers - 1. gnome-session — https://bugzilla.redhat.com/show_bug.cgi?id=2174753 — NEW reboot/poweroff/logout from GNOME are 60 seconds delayed without 3D acceleration On machines (physical and virtual) without 3D acceleration, clicking the reboot/poweroff/logout buttons has no apparent effect for 60 seconds. A second click or using command line commands works immediately. 2. gnupg2 — https://bugzilla.redhat.com/show_bug.cgi?id=2175155 — NEW revert the RFC4880bis from defaults GnuPG 2.4.0 made a potentially-incompatible change. A PR is pending to revert this: https://src.fedoraproject.org/rpms/gnupg2/pull-request/15 3. initial-setup — https://bugzilla.redhat.com/show_bug.cgi?id=2175244 — NEW User creation and root password setting do not work on minimal install, so cannot log into installed system On the Minimial image only, initial-setup silently fails to create a user. This results in a system with no usable user account. 4. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=2156691 — NEW Black screen when amdgpu started during 6.2-rc1 boot with AMD IOMMU enabled Kernel 6.2.0 introduced an issue that causes the system to hang when booting with amdgpu. There are upstream patches targeted for 6.2.2 that contain a candidate fix. 5. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2173985 — NEW XWayland apps steal focus Alt+Tab switching, as well as (sometimes) clicking on windows does not focus the window. This seems to largely affect Wine, Java, and Chromium applications. This may have been introduced by upstream commit a68b8e95. Upstream MR #2841 has a fix for Chrome and Electron apps. 6. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2174563 — NEW Virtual keyboard (on-screen) not working at sddm-wayland-plasma The virtual keyboard at the login screen does not appear when you click the appropriate button. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 Beta Go/No-Go meeting next week
The Fedora Linux 38 Beta Go/No-Go[1] meeting is scheduled for Thursday 9 March at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Beta for the 14 March early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10456/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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 Linux 38 Beta Go/No-Go meeting next week
The Fedora Linux 38 Beta Go/No-Go[1] meeting is scheduled for Thursday 9 March at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Beta for the 14 March early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10456/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 38 Beta Go/No-Go meeting next week
The Fedora Linux 37 Beta Go/No-Go[1] meeting is scheduled for Thursday 9 March at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Beta for the 14 March early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10456/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
Based on feedback, the 30-day auto-revocation is being dropped[1]. The 12-month key lifetime will still apply. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2174291 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
The current target release date is the early target date (2023-03-14). Action summary Accepted blockers - 1. distribution — Workstation boot x86_64 image exceeds maximum size — ASSIGNED ACTION: Workstation WG to reduce image size or increase the limit 2. kwin — kwin_wayland often crashed when used as the sddm Wayland compositor and logging out of Plasma resulting in a black screen — ON_QA ACTION: QA to verify FEDORA-2023-81ff51758d Proposed blockers - 1. gdb — Can't open file anon_inode:i915.gem which was expanded to anon_inode:i915.gem during file-backed mapping note processing — NEW ACTION: Maintainer to diagnose issue 2. pkgconf — Don't depend on system-rpm-config — ON_QA ACTION: QA to verify FEDORA-2023-766817d642 Bug-by-bug detail = Accepted blockers - 1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2149246 — ASSIGNED Workstation boot x86_64 image exceeds maximum size Changes to linux-firmware briefly brought the Worktation image below the limit. However, the Fedora-38-20230216.n.0 went above the limit again. 2. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2168034 — ON_QA kwin_wayland often crashed when used as the sddm Wayland compositor and logging out of Plasma resulting in a black screen Logging out of Plasma sometimes triggers a kwin crash. FEDORA-2023-81ff51758d contains a candidate fix. Proposed blockers - 1. gdb — https://bugzilla.redhat.com/show_bug.cgi?id=2172342 — NEW Can't open file anon_inode:i915.gem which was expanded to anon_inode:i915.gem during file-backed mapping note processing Reporting a bug with gnome-abrt fails because no fram and no thread found in the backtrace that gdb produces. 2. pkgconf — https://bugzilla.redhat.com/show_bug.cgi?id=2172406 — ON_QA Don't depend on system-rpm-config pkgconf pulls in ~22 new packages as a runtime dependency, which don't appear to be strictly necessary. FEDORA-2023-766817d642 contains a candidate fix. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
On Thu, Feb 23, 2023 at 1:42 PM Gary Buhrmaster wrote: > > I seem to recall that some of the Fedora people were > talking about creating a document that would show > what "we" use bugzilla for so that a future issue/bug > tracker solution (whatever that might be) could be > evaluated and any prep work needed to potentially > unhook Fedora's procedures/processes from bugzilla > could be started early (should the eventual chosen > solution not be able to provide those features). > Did that happen, and if so, where is it located? I have a survey prepared that will be opened once the F37 retrospective survey is done. This will give us a basis for evaluating our requirements as we look for possible replacements. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
Yes, as I understand it, this will make abrt difficult to use. Historically, we get about 2500 bug reports via abrt per release. That's roughly a quarter of reports per release on average. On the other hand, we're not particularly good at fixing abrt-reported bugs. Here's the resolution (excluding duplicates) of abrt-reported bugs for F19–34: EOL 32675 ERRATA3565 INSUFFICIENT_DATA 2965 CURRENTRELEASE1162 NOTABUG983 UPSTREAM 823 WORKSFORME 680 WONTFIX529 CANTFIX461 NEXTRELEASE423 RAWHIDE199 That's a ~73% EOL closure rate, compared to roughly 50% for all bugs. Depending on which resolutions you include as "fixed", we fix roughly 14% of abrt-reported bugs. I just found out about this change yesterday. I suspect it's a security-driven requirement, so I don't know how much room there will be for changes. I'll pass this on to the Bugzilla team and see what they say. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Changes to Bugzilla API key requirements
If you did not see the bugzilla-announce-list post[1], there are new requirements for API keys in Red Hat Bugzilla: Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You must replace your API keys at least once a year. Additionally, any API key that is not used for 30 days will be suspended but can be re-enabled on the account's preferences tab. All existing API keys have had their creation date set to 2023-02-19. For more details, see the announcement[1]. [1] https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Changes to Bugzilla API key requirements
If you did not see the bugzilla-announce-list post[1], there are new requirements for API keys in Red Hat Bugzilla: Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You must replace your API keys at least once a year. Additionally, any API key that is not used for 30 days will be suspended but can be re-enabled on the account's preferences tab. All existing API keys have had their creation date set to 2023-02-19. For more details, see the announcement[1]. [1] https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller wrote: > > What we're doing now — as has been the case for several years, already noted > in the previous discussion — has very little end-user value. Also as noted > in that thread (as in the ticket)... that's unfortunate, because it did > bring some real benefits (and could possibly do even more.) The fact that the value of deltas requires frequent updates means that most people don't get the benefit. And since delta RPMs trade bandwidth for CPU, it probably makes things worse for folks in developing countries. So I agree, it's probably not worth keeping deltas as the default. > But, I think it's time to move on. We have ostree and various > container-delta approaches. We should focus on those — and give DeltaRPMs a > sad, fond farewell. Could we do this as a two-step approach? First change the default to not use deltas but still allow people to opt-in to it. Then (assuming we can track this, which maybe we can't) see how much they're used before we decide to pull the plug on producing them. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 Change complete (100% complete) deadline today
As of today, F38 Changes should be 100% complete. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 enters beta freeze today. Any updates that need to land in the beta release will require an approved freeze exception or beta blocker. The current beta target is the early target date of 14 March. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
F38 Change complete (100% complete) deadline today
As of today, F38 Changes should be 100% complete. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 enters beta freeze today. Any updates that need to land in the beta release will require an approved freeze exception or beta blocker. The current beta target is the early target date of 14 March. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: MinGW toolchain update (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39MingwEnvToolchainUpdate This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the MinGW toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 13.x * mingw-binutils to version 2.40 == Benefit to Fedora == Ship the latest available GNU toolchain for MinGW. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: Help with build failures may be requested. * Release engineering: Impact check [https://pagure.io/releng/issue/11299] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest GNU Toolchain will be available to MinGW users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 39 comes with the mingw-gcc-13 and mingw-binutils-2.40. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: MinGW toolchain update (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39MingwEnvToolchainUpdate This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the MinGW toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 13.x * mingw-binutils to version 2.40 == Benefit to Fedora == Ship the latest available GNU toolchain for MinGW. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: Help with build failures may be requested. * Release engineering: Impact check [https://pagure.io/releng/issue/11299] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest GNU Toolchain will be available to MinGW users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 39 comes with the mingw-gcc-13 and mingw-binutils-2.40. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 blocker status summary
The F38 Beta freeze begins on 21 February. The current target release date is the early target date (2023-03-14). Action summary Accepted blockers - 1. distribution — Workstation boot x86_64 image exceeds maximum size — ASSIGNED ACTION: Workstation WG to reduce image size or increase the limit Proposed blockers - 1. glusterfs — libglusterd0 prevents upgrades to Fedora 38 — NEW ACTION: Maintainer to diagnose issue 2. kwin — kwin_wayland often crashed when used as the sddm Wayland compositor and logging out of Plasma resulting in a black screen — NEW ACTION: Maintainer to diagnose issue Bug-by-bug detail = Accepted blockers - 1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2149246 — ASSIGNED Workstation boot x86_64 image exceeds maximum size Changes to linux-firmware briefly brought the Worktation image below the limit. However, the Fedora-38-20230216.n.0 went above the limit again. Proposed blockers - 1. glusterfs — https://bugzilla.redhat.com/show_bug.cgi?id=2169401 — NEW libglusterd0 prevents upgrades to Fedora 38 libglusterd0, which is preinstalled in F37 Workstation, is not provided by anything in the F38 repos, so upgrades fail. 2. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2168034 — NEW kwin_wayland often crashed when used as the sddm Wayland compositor and logging out of Plasma resulting in a black screen Logging out of Plasma sometimes triggers a kwin crash. This may be limited to running in a virtual machine. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Fri, Feb 17, 2023 at 1:48 AM Mattia Verga via devel wrote: > > During the weekend I can write down a script reusing partial code from > the find_inactive_packagers script and purge the ticket list from users > that showed activity in RH bugzilla, let me know if you want me to > proceed. Or I can provide a list of users, but I think that will be a > long list for manual processing... People who were active in Bugzilla will get noticed on the step-two run and not removed, so I don't think it's necessary to go through and clean those up now unless you really want to. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Thu, Feb 16, 2023 at 3:45 PM Mattia Verga via devel wrote: > > This user should not have been detected as inactive if the Bugzilla > check was run. @Ben, maybe you forgot to set the BZ_API_KEY before > running the script? I didn't forget, I intentionally did not. I thought we had already modified the script to use `~/.bugzillarc` via the python-bugzilla library (the scripts for processing Change proposals and handling branch/EOL events does this). But apparently we did not, since https://pagure.io/find-inactive-packagers/issue/5 is still open. I'll prioritize that for next week if the COVID brain fog has lifted by then. I did find it suspicious that the mailing list and Bugzilla count matched exactly, but ...again... brain fog. I'll also knock out #6 (which is #5 except for the Pagure API key) at the same time. This will make the SOP for future me and my successors easier to follow. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Thu, Feb 16, 2023 at 6:29 AM Daniel P. Berrangé wrote: > > I'm a little surprised that the pagure ticket doesn't have the > maintainer to whom it refers added as a subscriber to the ticket. As far as I know, you can't subscribe others to a ticket the way you can add a CC in Bugzilla. We could modify the script to set the person as the assignee, but 1. That's functionally the same as @ing them in the ticket and... > Does pagure.io not have accounts synced for everyone who is a > Fedora packager ? ...2. Not as far as I know. If the person never logged in (which you don't necessarily need to do as a packager), then pagure.io would not know about them. I see that from time to time with Changes tickets to FESCo. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Wed, Feb 15, 2023 at 5:20 PM Paul Wouters wrote: > > How many packages depend _only_ on people from this list? Eg are likely > to be unmaintained ? There's a command in the script that will check the impact, but I'm going to hold off on running it for a bit. It takes a long time to iterate over all of the tickets and the resulting packages, with the result that people have responded by the time the script finishes. In another couple of weeks, the "I'm still here!"s will settle down and the output will be more reliable. I'll share it then. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F37 retrospective survey open through 9 March
In case you missed it on the Community Blog[1], the F37 retrospective survey[2] is open through 9 March. As a reminder, this survey is about the _process_ of creating F37, not the end result. This is the third such survey, so we'll be able to start putting together trends. This survey uses Fedora's LimeSurvey instance. Responses are anonymous. [1] https://communityblog.fedoraproject.org/f37-retrospective-survey-open/ [2] https://fedoraproject.limequery.com/37 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Inactive packager check for F38
In accordance with FESCo's Inactive Packager Policy[1], packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: ### Found 2129 users in the packager group. ### ### Found 914 users with no activity in pagure/src.fp.org over the last year. ### ### Found 845 users which also show no activity in Bodhi over the last year. ### ### Found 812 users which show also no activity in mailing lists over the last year. ### ### Found 812 users which also show no activity in Bugzilla over the last year. ### As we approach [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Inactive packager check for F38
In accordance with FESCo's Inactive Packager Policy[1], packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: ### Found 2129 users in the packager group. ### ### Found 914 users with no activity in pagure/src.fp.org over the last year. ### ### Found 845 users which also show no activity in Bodhi over the last year. ### ### Found 812 users which show also no activity in mailing lists over the last year. ### ### Found 812 users which also show no activity in Bugzilla over the last year. ### As we approach [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Fedora is currently shipping version 2020.3 (released July 10, 2020) of the Thread Building Blocks library. The current upstream version is 2021.8 (released December 22, 2022). The Fedora community has expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 interest] in moving the TBB package to track a more modern version of the upstream. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodg...@redhat.com == Detailed Description == Fedora has shipped with version 2020.3 of the Thread Building Blocks library since Fedora 33. The upstream project made a decision to break backward compatibility after that version was released. As packages move to match the upstream's changes it becomes more difficult to defer updating the Fedora packaging for TBB. The situation is further complicated as there are currently a majority of TBB dependent packages which have not been updated to track a new upstream release, as detailed in this [https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on the tracking issue. This proposal aims to provide a way to modernize the TBB packge version for Fedora while providing stability for those packages which continue to depend on the older TBB library version. It will be possible to install both devel and runtime versions of both TBB packages, however the devel compat package for version 2020.3 will require clients to point to a new include path where the legacy headers will be found. == Feedback == == Benefit to Fedora == Fedora 39 will include a current version of Thread Building Blocks (version 2021.8) while continuing to support clients dependent on an older version of TBB (version 2020.3). Fedora will stay relevant as far as Thread Building Blocks clients are concerned. == Scope == * Proposal owners: ** A compat package based on the current 2020.3 version of the existing TBB package will be created. ** Evaluate TBB dependent packages to identify those which need to move to the compat version of the TBB package. An initial analysis suggests the majority of current TBB clients will need to move to the compat package. ** Post a request for rebuilds to fedora-devel ** Create patches for those packages affected by this change to adjust their includes to point the compat package's headers as necessary, work with affected package owners to update package specs to account for the change. ** When most packages are done, re-tag all the packages in rawhide. ** Watch fedora-devel and assist in rebuilding broken TBB clients. * Other developers: ** Those who depend on Thread Building Blocks will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Release engineering: TODO * Policies and guidelines: N/A (not needed for this Change) ** Apart from scope, this is business as usual, so no new policies, no new guidelines. == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. == How To Test == * No special hardware is needed. * Parallel install of the 2020.3 TBB compat packages and the updated TBB packages and checking that it does not break other packages. == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new TBB packages, and may need to adjust their code to either remain on the compat TBB version or move to the new version supplied by the updated TBB package. == Dependencies == Packages that must be rebuilt: & dnf repoquery -s --releasever=rawhide --whatrequires libtbb\* --enablerepo=fedora | sort -u The tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue's] analysis suggests that only the following packages will be able to move to a newer TBB - * fawkes * gazebo * opencascade * pmemkv * root While the remaining clients of TBB will need to have their spec's include paths adjusted to use the 2020.3 compat package. == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F39 with the existing TBB package, which is already in rawhide. == Documentation == * Notes on the scope of change, motivation, and likely impacts are in the comments on the tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue]. * https://github.com/oneapi-src/oneTBB/releases/tag/v2021.7.0 (Released 2nd October 2022) * https://github.com/oneapi-src/oneTBB/releases/tag/v2020.3 (Released 10th July 2020) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Man
F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Fedora is currently shipping version 2020.3 (released July 10, 2020) of the Thread Building Blocks library. The current upstream version is 2021.8 (released December 22, 2022). The Fedora community has expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 interest] in moving the TBB package to track a more modern version of the upstream. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodg...@redhat.com == Detailed Description == Fedora has shipped with version 2020.3 of the Thread Building Blocks library since Fedora 33. The upstream project made a decision to break backward compatibility after that version was released. As packages move to match the upstream's changes it becomes more difficult to defer updating the Fedora packaging for TBB. The situation is further complicated as there are currently a majority of TBB dependent packages which have not been updated to track a new upstream release, as detailed in this [https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on the tracking issue. This proposal aims to provide a way to modernize the TBB packge version for Fedora while providing stability for those packages which continue to depend on the older TBB library version. It will be possible to install both devel and runtime versions of both TBB packages, however the devel compat package for version 2020.3 will require clients to point to a new include path where the legacy headers will be found. == Feedback == == Benefit to Fedora == Fedora 39 will include a current version of Thread Building Blocks (version 2021.8) while continuing to support clients dependent on an older version of TBB (version 2020.3). Fedora will stay relevant as far as Thread Building Blocks clients are concerned. == Scope == * Proposal owners: ** A compat package based on the current 2020.3 version of the existing TBB package will be created. ** Evaluate TBB dependent packages to identify those which need to move to the compat version of the TBB package. An initial analysis suggests the majority of current TBB clients will need to move to the compat package. ** Post a request for rebuilds to fedora-devel ** Create patches for those packages affected by this change to adjust their includes to point the compat package's headers as necessary, work with affected package owners to update package specs to account for the change. ** When most packages are done, re-tag all the packages in rawhide. ** Watch fedora-devel and assist in rebuilding broken TBB clients. * Other developers: ** Those who depend on Thread Building Blocks will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Release engineering: TODO * Policies and guidelines: N/A (not needed for this Change) ** Apart from scope, this is business as usual, so no new policies, no new guidelines. == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. == How To Test == * No special hardware is needed. * Parallel install of the 2020.3 TBB compat packages and the updated TBB packages and checking that it does not break other packages. == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new TBB packages, and may need to adjust their code to either remain on the compat TBB version or move to the new version supplied by the updated TBB package. == Dependencies == Packages that must be rebuilt: & dnf repoquery -s --releasever=rawhide --whatrequires libtbb\* --enablerepo=fedora | sort -u The tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue's] analysis suggests that only the following packages will be able to move to a newer TBB - * fawkes * gazebo * opencascade * pmemkv * root While the remaining clients of TBB will need to have their spec's include paths adjusted to use the 2020.3 compat package. == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F39 with the existing TBB package, which is already in rawhide. == Documentation == * Notes on the scope of change, motivation, and likely impacts are in the comments on the tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue]. * https://github.com/oneapi-src/oneTBB/releases/tag/v2021.7.0 (Released 2nd October 2022) * https://github.com/oneapi-src/oneTBB/releases/tag/v2020.3 (Released 10th July 2020) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Man
F38 Change complete (100% complete) deadline in one week
As a reminder, F38 Changes should be 100% complete by Tuesday 21 February. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 will enter beta freeze on that date. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
F38 Change complete (100% complete) deadline in one week
As a reminder, F38 Changes should be 100% complete by Tuesday 21 February. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 will enter beta freeze on that date. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 blocker status summary
We've branched F38 from Rawhide, so it's time to start everyone's
favorite Friday email from Ben! The F38 Beta freeze begins on 21
February. The current target release date is the early target date
(2023-03-14).
Action summary
Accepted blockers
-
1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
exceeds maximum size — ASSIGNED
ACTION: Relevant Teams to reduce image size or increase the limit
Proposed blockers
-
1. anaconda — installer fails to boot in text mode or rescue mode with
systemd 253 — MODIFIED
ACTION: Maintainers to build an update that includes upstream PR
2. grub2 — ext4 filessystem support missing — NEW
ACTION: Maintainer to diagnose issue
NEEDINFO: ausil
3. kwin — kwin_wayland often crashed when used as the sddm Wayland
compositor and logging out of Plasma resulting in a black screen — NEW
ACTION: Maintainer to diagnose issue
4. mesa — KDE crashes on start with mesa-23.0.0~rc3-3.fc38 — ASSIGNED
ACTION: Maintainer to diagnose issue
Bug-by-bug detail
=
Accepted blockers
-
1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
exceeds maximum size — ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=2149246
https://bugzilla.redhat.com/show_bug.cgi?id=2151495
https://bugzilla.redhat.com/show_bug.cgi?id=2151497
Image sizes exceed the specified limits. The choices are to either
shrink the image by removing packages or to riase the limits.
Proposed blockers
-
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2165433 — MODIFIED
installer fails to boot in text mode or rescue mode with systemd 253
anaconda is writing systemd units to an unexpected area. Upstream PR
4534 contains a candidate fix:
https://github.com/rhinstaller/anaconda/pull/4534
2. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2166412 — NEW
ext4 filessystem support missing
Between grub2-2.06-76 and grub2-2.06-78, grub2 apparently lost the
ability to detect ext4 filesystems.
3. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2168034 — NEW
kwin_wayland often crashed when used as the sddm Wayland compositor
and logging out of Plasma resulting in a black screen
Logging out of Plasma sometimes triggers a kwin crash. This may be
limited to running in a virtual machine.
4. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=2164667 — ASSIGNED
KDE crashes on start with mesa-23.0.0~rc3-3.fc38
A recent mesa update caused both GNOME and KDE to crash on start.
Update FEDORA-2023-40b973fa06 fixed GNOME, but KDE is still seeing
this issue. The root cause is still uncertain.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Inactive provenpackagers to be removed from group
In accordance with FESCo policy[1], the following provenpackagers will be submitted for removal in two weeks based on a lack of Koji builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you should still be in the provenpackager group. Note that removal from this group is not a "punishment" or a lack of appreciation for the work you have done. The intent of the process is to ensure contributors with distro-wide package privileges are still active and responsive. This process is done regularly at the branch point in each release. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status Checked 134 provenpackagers The following 15 provenpackagers have not submitted a Koji build since at least 2022-08-03 00:00:00: abompard mohanboddu jamatos jwboyer till laxathom torsava dwmw2 oget otaylor jwilson oliver wtogami steve bruno -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Inactive provenpackagers to be removed from group
In accordance with FESCo policy[1], the following provenpackagers will be submitted for removal in two weeks based on a lack of Koji builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you should still be in the provenpackager group. Note that removal from this group is not a "punishment" or a lack of appreciation for the work you have done. The intent of the process is to ensure contributors with distro-wide package privileges are still active and responsive. This process is done regularly at the branch point in each release. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status Checked 134 provenpackagers The following 15 provenpackagers have not submitted a Koji build since at least 2022-08-03 00:00:00: abompard mohanboddu jamatos jwboyer till laxathom torsava dwmw2 oget otaylor jwilson oliver wtogami steve bruno -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
