Re: Fedora & AI Survey Now Live Until July 16th
Thank you all for the feedback, I hear what you're saying and the best thing to do is to either scrap this initial survey and launch an updated one that reflects people's preferences to not have AI in certain parts of the project, or edit the ranking question to do this and make it more explicit on what people dont want, and not just what they do. I hope limesurvey allows for updating responses, but I'm not sure so I'll need to look into it and will come back to you with a (hopefully) improved survey soon. The main purpose of this survey is to try to understand the sentiment of the Fedora community when it comes to having or using AI in the project, in order to create good guidelines for ourselves. We probably were trying to do too much too quickly with this initial go at an AI survey, so we're going to re-review and clean up the ranking question. For me and the other council members, it's more important to have our community be able to answer this survey comfortably and honestly than keeping this survey around that doesn't suit. I appreciate your patience and genuinely thank you for your time, survey-fatigue is real so I'm glad to hear people are willing to re-complete a new one if we need one, that makes it feel like this is absolutely the right decision to make. My first option is to revise how we have structured the ranking question, and if that fails, I will just do a new survey altogether :) Thanks folks, will be back to you soon! Aoife On Tue, Jul 2, 2024 at 5:57 PM Aaron Rainbolt wrote: > On 7/2/24 04:59, Aoife Moloney wrote: > > I guess how the question is phrased 'where do you feel like AI/ML has the > > best fit in Fedora' assumes the responder will choose where they feel it > > works best as top choice, and least-best (terrible English :) ) as last, > so > > reviewers of the survey would likely assume 'oh the option > > scored lowest, that means people really don't see AI/ML as suiting that > use > > case so we shouldn't focus any energy on this option'. > > > > Like I said, it really is great feedback because the tone of the > question, > > while deliberately trying to be positive because this is such a > > controversial topic in and of itself, didn't raise this issue of needing > a > > 'doesn't fit at all' option when the survey questions were reviewed > before > > going live, and that's something we can take forward for the contributors > > survey too for question structuring. > > > > > > > > The only reluctance I have on scrapping this survey and changing that > > question and then relaunching is that I don't want it to be spammy, > because > > I'm sure a lot of folks have already completed the current one and > there's > > still the contributor survey too to be launched, but if folks are having > a > > terrible that with that question I'm particular, then I will and hope you > > give me another few mins of your day again to fill it back out :) > I personally would be happy to fill it back out if it were redone with > room for more negative feedback. I filled it out and tried to be as > optimistic as possible, but the fact that options like "virtual assistant > in the OS" and "Copilot-ish tooling" were in the list of options was a bit > horrifying to me and I would have liked to have put those in a "please > don't" list. Some of the ideas in there like log analysis and moderation > tooling seemed like a good fit for AI though (both of them if set up > properly are areas where AI is less likely to get things wrong and where > the consequences of it getting things wrong are lower, plus there's less > legal risk with that sort of thing).-- Aaron Rainbolt > > Aoife Moloney > > Fedora Operations Architect > > > > -- > ___ > 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 > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 & AI Survey Now Live Until July 16th
*a terrible time with that question in particular (Sorry, autocorrected and I didn't spot it before hitting send) Aoife Moloney Fedora Operations Architect On Tue, Jul 2, 2024, 10:59 AM Aoife Moloney wrote: > I guess how the question is phrased 'where do you feel like AI/ML has the > best fit in Fedora' assumes the responder will choose where they feel it > works best as top choice, and least-best (terrible English :) ) as last, so > reviewers of the survey would likely assume 'oh the option > scored lowest, that means people really don't see AI/ML as suiting that use > case so we shouldn't focus any energy on this option'. > > Like I said, it really is great feedback because the tone of the question, > while deliberately trying to be positive because this is such a > controversial topic in and of itself, didn't raise this issue of needing a > 'doesn't fit at all' option when the survey questions were reviewed before > going live, and that's something we can take forward for the contributors > survey too for question structuring. > > > > The only reluctance I have on scrapping this survey and changing that > question and then relaunching is that I don't want it to be spammy, because > I'm sure a lot of folks have already completed the current one and there's > still the contributor survey too to be launched, but if folks are having a > terrible that with that question I'm particular, then I will and hope you > give me another few mins of your day again to fill it back out :) > > > > Aoife Moloney > Fedora Operations Architect > > On Tue, Jul 2, 2024, 10:03 AM Luis Correia > wrote: > >> >> >> On Tue, 2 Jul 2024 at 09:45, Neal Gompa wrote: >> >>> On Tue, Jul 2, 2024 at 4:19 AM Daniel P. Berrangé >>> wrote: >>> > >>> > On Mon, Jul 01, 2024 at 08:07:46PM +0100, Aoife Moloney wrote: >>> > > DJ & Tom - thank you for that clarification on how to interpret your >>> > > ranking, and I can assure you and other folks who feel similar about >>> > > answering that question that that is indeed the way we will be >>> analysing >>> > > the results - top ranked being best fit, 5th or last ranked being >>> least or >>> > > worst fit. Also for anyone who has yet to complete the survey, the >>> last >>> > > question is an optional, free format answer so I would suggest using >>> that >>> > > to expand on reasons why you ranked certain areas #1, #2 etc for what >>> > > problems you see AI addressing in those parts of the project. >>> > > >>> > > I would also like to add that we deliberately took a positive tone >>> for this >>> > > survey as it is far too easy to find (many) negatives for AI (and >>> for good >>> > > reason!), and we wanted to try to look at the benefits we could get >>> from AI >>> > > instead if applied properly and wit the best interest of Fedora >>> driving the >>> > > use of AI in parts of the projects ecosystem. >>> > > >>> > > This survey is just trying to understand the preferences and wants >>> of the >>> > > Fedora community when it comes to AI, and not a guarantee that the >>> project >>> > > will be introducing AI in all of the mentioned areas. >>> > >>> > I can't see how this helps understand the Fedora contributor's >>> preferences >>> > about the use of AI, when the survey is restricting the possible >>> answers >>> > to "yes", "definitely yes", "very much yes". I would question the >>> validity >>> > of any actions taken / priorities set in Fedora based on results of >>> this >>> > survey. >>> > >>> >>> Indeed. This creates a skewed dataset because the questions you've >>> asked essentially prevent a set of responses from being captured. The >>> two choices people have are: pick the least worst option or just don't >>> participate in the survey. Neither of which are good things. >>> >>> >>> >> Continuing with a small comment: >> >> this looks like one of those Human Resources surveys where they only want >> to know if their performance is: >> . good >> . great >> . outstanding >> >> And as we know, it's actually none of those >> >> >> Luís >> -- >> ___ >> devel mailing list -- devel@lists.fedoraproj
Re: Fedora & AI Survey Now Live Until July 16th
I guess how the question is phrased 'where do you feel like AI/ML has the best fit in Fedora' assumes the responder will choose where they feel it works best as top choice, and least-best (terrible English :) ) as last, so reviewers of the survey would likely assume 'oh the option scored lowest, that means people really don't see AI/ML as suiting that use case so we shouldn't focus any energy on this option'. Like I said, it really is great feedback because the tone of the question, while deliberately trying to be positive because this is such a controversial topic in and of itself, didn't raise this issue of needing a 'doesn't fit at all' option when the survey questions were reviewed before going live, and that's something we can take forward for the contributors survey too for question structuring. The only reluctance I have on scrapping this survey and changing that question and then relaunching is that I don't want it to be spammy, because I'm sure a lot of folks have already completed the current one and there's still the contributor survey too to be launched, but if folks are having a terrible that with that question I'm particular, then I will and hope you give me another few mins of your day again to fill it back out :) Aoife Moloney Fedora Operations Architect On Tue, Jul 2, 2024, 10:03 AM Luis Correia wrote: > > > On Tue, 2 Jul 2024 at 09:45, Neal Gompa wrote: > >> On Tue, Jul 2, 2024 at 4:19 AM Daniel P. Berrangé >> wrote: >> > >> > On Mon, Jul 01, 2024 at 08:07:46PM +0100, Aoife Moloney wrote: >> > > DJ & Tom - thank you for that clarification on how to interpret your >> > > ranking, and I can assure you and other folks who feel similar about >> > > answering that question that that is indeed the way we will be >> analysing >> > > the results - top ranked being best fit, 5th or last ranked being >> least or >> > > worst fit. Also for anyone who has yet to complete the survey, the >> last >> > > question is an optional, free format answer so I would suggest using >> that >> > > to expand on reasons why you ranked certain areas #1, #2 etc for what >> > > problems you see AI addressing in those parts of the project. >> > > >> > > I would also like to add that we deliberately took a positive tone >> for this >> > > survey as it is far too easy to find (many) negatives for AI (and for >> good >> > > reason!), and we wanted to try to look at the benefits we could get >> from AI >> > > instead if applied properly and wit the best interest of Fedora >> driving the >> > > use of AI in parts of the projects ecosystem. >> > > >> > > This survey is just trying to understand the preferences and wants of >> the >> > > Fedora community when it comes to AI, and not a guarantee that the >> project >> > > will be introducing AI in all of the mentioned areas. >> > >> > I can't see how this helps understand the Fedora contributor's >> preferences >> > about the use of AI, when the survey is restricting the possible answers >> > to "yes", "definitely yes", "very much yes". I would question the >> validity >> > of any actions taken / priorities set in Fedora based on results of this >> > survey. >> > >> >> Indeed. This creates a skewed dataset because the questions you've >> asked essentially prevent a set of responses from being captured. The >> two choices people have are: pick the least worst option or just don't >> participate in the survey. Neither of which are good things. >> >> >> > Continuing with a small comment: > > this looks like one of those Human Resources surveys where they only want > to know if their performance is: > . good > . great > . outstanding > > And as we know, it's actually none of those > > > Luís > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)
Wiki -
https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336
This is a proposed Change for Fedora Linux.
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 proposal adds a new dedicated `flatpak` group, allowing users to
manage system Flatpaks without needing to be in the `wheel` group.
== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org
== Detailed Description ==
Currently, to install, uninstall and modify apps or repositories,
users need to be in the `wheel` group. Removing a user from the wheel
group would interfere with the currently default (systemwide)
configuration of Flatpaks.
All users can add a `user` repository, and manage their own user
Flatpaks. But a dedicated group to manage system flatpaks, without
relying on `wheel` allows more fine grained privileges.
This enables an "admin" permission that is not tied to full root
access on the host system.
It will be a change of the polkit rule `org.freedesktop.Flatpak.rules`
like following:
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.Flatpak.app-install" ||
action.id == "org.freedesktop.Flatpak.runtime-install"||
action.id == "org.freedesktop.Flatpak.app-uninstall" ||
action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
action.id == "org.freedesktop.Flatpak.modify-repo") &&
subject.active == true && subject.local == true && (
subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
return polkit.Result.AUTH_ADMIN;
}
return polkit.Result.NOT_HANDLED;
});
== Feedback ==
none yet
== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the management of Flatpaks, without needing all the other
privileges that `wheel` users have.
== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `flatpak` group
* Other developers: none
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Documentation needs to get an additional
chapter on Flatpak management with the `flatpak` group.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Yes
== Upgrade/compatibility impact ==
The polkit rule will be overwritten, there will be no changes in
behavior. It just enables a new feature.
== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.
This will be preferred over the default rule and you can test if it works.
== User Experience ==
By default, Anaconda puts users into the `wheel` group. There will be no change.
But it enables to manage Flatpaks without being in that privileged group.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Will be added afterwards.
Nonwheel users can be added to the `flatpak` group:
sudo groupadd flatpak
sudo usermod -aG flatpak USERNAME
== Release Notes ==
Permission to manage systemwide flatpaks is now granted to users in
the 'flatpak' group.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List A
F42 Change Proposal: Unprivileged Disk Management (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedDiskManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-disk-management-system-wide/124334
This is a proposed Change for Fedora Linux.
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 proposal adds a new dedicated `diskadmin` group, allowing users
to manage external drives without needing to be in the `wheel` group.
It will also enable wheel users to unlock and mount external drives
without a password prompt.
== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org
== Detailed Description ==
Currently, to mount or (LUKS) unlock external drives, users need to be
in the `wheel` group. Removing a user from the wheel group would
prevent them from using external drives.
This enables an "admin" permission that is not tied to full root
access on the host system.
It will be a change of the polkit rule `org.freedesktop.udisks2.rules`
like following:
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks2.encrypted-unlock-system" ||
action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
subject.active == true && subject.local == true && (
subject.isInGroup("diskadmin") || subject.isInGroup("wheel"))) {
return polkit.Result.YES;
}
});
== Feedback ==
none yet
== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the mounting and unlocking of external drives, without needing
all the other privileges that `wheel` users have.
== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `diskadmin` group on GNOME and KDE
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Documentation needs to get an additional
chapter on disk management with the `diskadmin` group.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Not sure, as it adds a
nonstandard user group.
== Upgrade/compatibility impact ==
The polkit rule will be added, users will not need to enter a password
if they are in these groups. No changes for users outside these
groups.
== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/80-org.freedesktop.udisks2.rules`.
This will be preferred over the default rule and you can test if it works.
== User Experience ==
By default, Anaconda puts users into the `wheel` group. These users
will not need to enter a password when mounting external media or
unlocking them.
It also allows to do these actions without being in the `wheel`
group, by adding a user to the `diskadmin` group.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Will be added afterwards.
Nonwheel users can be added to the `diskadmin` group:
sudo groupadd diskadmin
sudo usermod -aG diskadmin USERNAME
== Release Notes ==
Users in the 'wheel' or 'diskadmin' group can mount and unlock
external drives without a password.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/SELinux_dontaudit_unlabeled_t Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-reduce-the-amount-of-dontaudit-rules-pertaining-to-unlabeled-t-self-contained/124332 This is a proposed Change for Fedora Linux. 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 == Reduce the amount of rules that prevent reporting of SELinux denials pertaining to unlabeled_t. This could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials. == Owner == * Name: [[User:vmojzis| Vít Mojžíš]] * Email: * Name: [[User:mmalik| Miloš Malík]] * Email: == Detailed Description == The SELinux security policy primarily comprises allow rules, which permit specific operations on a confined system. However, there are also SELinux rules featuring the "dontaudit" keyword. In general, these rules signify that the described operation is not allowed and will not be logged as a permission denial in audit logs. The primary purpose of these rules is to hide certain false positives or code defects, such as leaked descriptors. The drawback is that, in certain instances, these rules might obscure hints that could expedite debugging and issue resolution. It is possible to disable all dontaudit rules using "semodule -DB", but this usually leads to large amounts of benign denials being logged and hence is not practical for long term use. The goal of this change is to significantly reduce the amount of dontaudit rules suppressing "unlabeled_t" denials, which are often caused by miss-labeled filesystems and can usually be easily fixed when noticed by the system administrator. The rules will not be completely removed from the policy, only disabled by default, so that the change can be reverted by the admin if needed (# setsebool -P dontaudit_unlabeled_files 1). The change could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials. == Feedback == == Benefit to Fedora == Access denials caused by labeling issues will more likely be reported by SELinux. == Scope == * Proposal owners: Determine which dontaudit rules are safe to disable by default and wrap them in conditional statements in the policy sources -- changes will be limited to SElinux policy (and possibly setroubleshoot) packages * Other developers: Report any unlabeled_t AVCs triggered by their 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 the Fedora Strategy: The change aligns with the "accessibility" goal as it simplifies debugging of some labeling issues == Upgrade/compatibility impact == No functionality impact, no configuration or data migration. The change could influence the amount of SELinux-related logs on some systems. == Early Testing (Optional) == Do you require 'QA Blueprint' support? - No == How To Test == Run your testsuite with SELinux enabled (Enforcing or Permissive mode) and record any AVCs containing unlabeld_t keyword. # ausearch -m AVC,USER_AVC | grep unlabeled_t == User Experience == The change could increase the amount of SELinux-related logs on some systems. == Dependencies == Changes will be limited to SElinux policy (and possibly setroubleshoot) packages. == Contingency Plan == * Contingency mechanism: Do not ship the updated SELinux-policy package * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == Dontaudit rules can be added selectively using audit2allow: # ausearch -m AVC | grep unlabeled_t | audit2allow -D -M dontaudit_unlabeled # semodule -i dontaudit_unlabeled.pp All the disabled rules can be re-enabled by switching the "dontaudit_unlabeled_files" boolean (will be added as part of the change). # setsebool -P dontaudit_unlabeled_files 1 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedorapr
F41 Change Proposal: Retire Python 2.7 (system-wide)
n Python 2 should do so on a
platform that offers support for it. Running applications on
unsupported Python is dangerous.
Developers who still need to test their software on Python 2 can use
containers with older Fedora releases or unsupported CentOS/RHEL
versions.
== Scope ==
* Proposal owners:
** Coordinate closely with the GIMP maintainers.
** `fedpkg retire python2.7` before the beta freeze if GIMP is ready.
** Remove `Recommends: python2.7` from {{package|asv}} and {{package|tox}}.
* Other developers:
** Retire or fix the remaining dependent packages.
* Release engineering: [https://pagure.io/releng/issue/12175 #12175]
* Policies and guidelines: Using Python 2 is already forbidden for
Fedora packages.
* Trademark approval: not needed for this Change
* Alignment with the Fedora Strategy: n/a
== Upgrade/compatibility impact ==
Unless Python 2 stops being installable, we do not plan to Obsolete it.
Users who upgrade to Fedora Linux 41+ from earlier releases with
Python 2 installed, will likely still get it, but they will receive no
support.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Try installing {{package|python2.7}} on Fedora Linux 41+. It should fail.
== User Experience ==
Some users might be unhappy about this, but we decided to do it
anyway. We cannot keep legacy software forever, Fedora Linux is not
that kind of Linux.
== Dependencies ==
* [[Changes/Gimp_3]]
== Contingency Plan ==
* Contingency mechanism: postpone to Fedora 42
* Contingency deadline: A week after Beta Freeze
* Blocks release? No
== Documentation ==
There is no more Python 2 in Fedora Linux 41+.
== Release Notes ==
There is no more Python 2 in Fedora Linux 41+.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)
Wiki -
https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336
This is a proposed Change for Fedora Linux.
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 proposal adds a new dedicated `flatpak` group, allowing users to
manage system Flatpaks without needing to be in the `wheel` group.
== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org
== Detailed Description ==
Currently, to install, uninstall and modify apps or repositories,
users need to be in the `wheel` group. Removing a user from the wheel
group would interfere with the currently default (systemwide)
configuration of Flatpaks.
All users can add a `user` repository, and manage their own user
Flatpaks. But a dedicated group to manage system flatpaks, without
relying on `wheel` allows more fine grained privileges.
This enables an "admin" permission that is not tied to full root
access on the host system.
It will be a change of the polkit rule `org.freedesktop.Flatpak.rules`
like following:
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.Flatpak.app-install" ||
action.id == "org.freedesktop.Flatpak.runtime-install"||
action.id == "org.freedesktop.Flatpak.app-uninstall" ||
action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
action.id == "org.freedesktop.Flatpak.modify-repo") &&
subject.active == true && subject.local == true && (
subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
return polkit.Result.AUTH_ADMIN;
}
return polkit.Result.NOT_HANDLED;
});
== Feedback ==
none yet
== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the management of Flatpaks, without needing all the other
privileges that `wheel` users have.
== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `flatpak` group
* Other developers: none
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Documentation needs to get an additional
chapter on Flatpak management with the `flatpak` group.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Yes
== Upgrade/compatibility impact ==
The polkit rule will be overwritten, there will be no changes in
behavior. It just enables a new feature.
== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.
This will be preferred over the default rule and you can test if it works.
== User Experience ==
By default, Anaconda puts users into the `wheel` group. There will be no change.
But it enables to manage Flatpaks without being in that privileged group.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Will be added afterwards.
Nonwheel users can be added to the `flatpak` group:
sudo groupadd flatpak
sudo usermod -aG flatpak USERNAME
== Release Notes ==
Permission to manage systemwide flatpaks is now granted to users in
the 'flatpak' group.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F42 Change Proposal: Unprivileged Disk Management (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedDiskManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-disk-management-system-wide/124334
This is a proposed Change for Fedora Linux.
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 proposal adds a new dedicated `diskadmin` group, allowing users
to manage external drives without needing to be in the `wheel` group.
It will also enable wheel users to unlock and mount external drives
without a password prompt.
== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org
== Detailed Description ==
Currently, to mount or (LUKS) unlock external drives, users need to be
in the `wheel` group. Removing a user from the wheel group would
prevent them from using external drives.
This enables an "admin" permission that is not tied to full root
access on the host system.
It will be a change of the polkit rule `org.freedesktop.udisks2.rules`
like following:
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks2.encrypted-unlock-system" ||
action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
subject.active == true && subject.local == true && (
subject.isInGroup("diskadmin") || subject.isInGroup("wheel"))) {
return polkit.Result.YES;
}
});
== Feedback ==
none yet
== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the mounting and unlocking of external drives, without needing
all the other privileges that `wheel` users have.
== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `diskadmin` group on GNOME and KDE
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Documentation needs to get an additional
chapter on disk management with the `diskadmin` group.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Not sure, as it adds a
nonstandard user group.
== Upgrade/compatibility impact ==
The polkit rule will be added, users will not need to enter a password
if they are in these groups. No changes for users outside these
groups.
== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/80-org.freedesktop.udisks2.rules`.
This will be preferred over the default rule and you can test if it works.
== User Experience ==
By default, Anaconda puts users into the `wheel` group. These users
will not need to enter a password when mounting external media or
unlocking them.
It also allows to do these actions without being in the `wheel`
group, by adding a user to the `diskadmin` group.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Will be added afterwards.
Nonwheel users can be added to the `diskadmin` group:
sudo groupadd diskadmin
sudo usermod -aG diskadmin USERNAME
== Release Notes ==
Users in the 'wheel' or 'diskadmin' group can mount and unlock
external drives without a password.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/SELinux_dontaudit_unlabeled_t Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-reduce-the-amount-of-dontaudit-rules-pertaining-to-unlabeled-t-self-contained/124332 This is a proposed Change for Fedora Linux. 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 == Reduce the amount of rules that prevent reporting of SELinux denials pertaining to unlabeled_t. This could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials. == Owner == * Name: [[User:vmojzis| Vít Mojžíš]] * Email: * Name: [[User:mmalik| Miloš Malík]] * Email: == Detailed Description == The SELinux security policy primarily comprises allow rules, which permit specific operations on a confined system. However, there are also SELinux rules featuring the "dontaudit" keyword. In general, these rules signify that the described operation is not allowed and will not be logged as a permission denial in audit logs. The primary purpose of these rules is to hide certain false positives or code defects, such as leaked descriptors. The drawback is that, in certain instances, these rules might obscure hints that could expedite debugging and issue resolution. It is possible to disable all dontaudit rules using "semodule -DB", but this usually leads to large amounts of benign denials being logged and hence is not practical for long term use. The goal of this change is to significantly reduce the amount of dontaudit rules suppressing "unlabeled_t" denials, which are often caused by miss-labeled filesystems and can usually be easily fixed when noticed by the system administrator. The rules will not be completely removed from the policy, only disabled by default, so that the change can be reverted by the admin if needed (# setsebool -P dontaudit_unlabeled_files 1). The change could influence the amount of SELinux-related logs on some systems, but will not cause any new permission denials. == Feedback == == Benefit to Fedora == Access denials caused by labeling issues will more likely be reported by SELinux. == Scope == * Proposal owners: Determine which dontaudit rules are safe to disable by default and wrap them in conditional statements in the policy sources -- changes will be limited to SElinux policy (and possibly setroubleshoot) packages * Other developers: Report any unlabeled_t AVCs triggered by their 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 the Fedora Strategy: The change aligns with the "accessibility" goal as it simplifies debugging of some labeling issues == Upgrade/compatibility impact == No functionality impact, no configuration or data migration. The change could influence the amount of SELinux-related logs on some systems. == Early Testing (Optional) == Do you require 'QA Blueprint' support? - No == How To Test == Run your testsuite with SELinux enabled (Enforcing or Permissive mode) and record any AVCs containing unlabeld_t keyword. # ausearch -m AVC,USER_AVC | grep unlabeled_t == User Experience == The change could increase the amount of SELinux-related logs on some systems. == Dependencies == Changes will be limited to SElinux policy (and possibly setroubleshoot) packages. == Contingency Plan == * Contingency mechanism: Do not ship the updated SELinux-policy package * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == Dontaudit rules can be added selectively using audit2allow: # ausearch -m AVC | grep unlabeled_t | audit2allow -D -M dontaudit_unlabeled # semodule -i dontaudit_unlabeled.pp All the disabled rules can be re-enabled by switching the "dontaudit_unlabeled_files" boolean (will be added as part of the change). # setsebool -P dontaudit_unlabeled_files 1 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Retire Python 2.7 (system-wide)
n Python 2 should do so on a
platform that offers support for it. Running applications on
unsupported Python is dangerous.
Developers who still need to test their software on Python 2 can use
containers with older Fedora releases or unsupported CentOS/RHEL
versions.
== Scope ==
* Proposal owners:
** Coordinate closely with the GIMP maintainers.
** `fedpkg retire python2.7` before the beta freeze if GIMP is ready.
** Remove `Recommends: python2.7` from {{package|asv}} and {{package|tox}}.
* Other developers:
** Retire or fix the remaining dependent packages.
* Release engineering: [https://pagure.io/releng/issue/12175 #12175]
* Policies and guidelines: Using Python 2 is already forbidden for
Fedora packages.
* Trademark approval: not needed for this Change
* Alignment with the Fedora Strategy: n/a
== Upgrade/compatibility impact ==
Unless Python 2 stops being installable, we do not plan to Obsolete it.
Users who upgrade to Fedora Linux 41+ from earlier releases with
Python 2 installed, will likely still get it, but they will receive no
support.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Try installing {{package|python2.7}} on Fedora Linux 41+. It should fail.
== User Experience ==
Some users might be unhappy about this, but we decided to do it
anyway. We cannot keep legacy software forever, Fedora Linux is not
that kind of Linux.
== Dependencies ==
* [[Changes/Gimp_3]]
== Contingency Plan ==
* Contingency mechanism: postpone to Fedora 42
* Contingency deadline: A week after Beta Freeze
* Blocks release? No
== Documentation ==
There is no more Python 2 in Fedora Linux 41+.
== Release Notes ==
There is no more Python 2 in Fedora Linux 41+.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: IPU6 camera support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/IPU6_Camera_support Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-ipu6-camera-support-self-contained/124329 This is a proposed Change for Fedora Linux. 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 == Integrate support into Fedora for Intel IPU6 attached MIPI cameras using the IPU6 CSI-receiver (isys) driver which has landed in kernel 6.10 together with libcamwera's 0.3 software ISP support and Firefox' recent support for using cameras through pipewire. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == Many new laptops models have a camera-sensor which is directly attached to the laptops CPU/SoC over a MIPI CSI2 databus instead of using a USB webcam module talking the standard USB UVC protocol. These cameras require a lot of work on the software side to go from the raw Bayer data received over the CSI2 bus to an usable image. This includes both controlling things like exposure and gain settings on the sensor as well as a lot of processing of the raw data, such as debayering and whitebalancing. Adding support for these complex cameras is tricky because: * Applications can no longer directly use /dev/video now * Supporting ISPs (if supported in the kernel) requires ISP model specific knowledge in userspace * Vendor's 3A algorithms for auto-exposure/gain, auto-whitebalance and auto-focus are secret and need to have open-source counterparts written and tuned * Instead of having a single UVC driver this requires CSI-receiver + ISP + sensor drivers in the kernel * Different IPU6 laptop models use different sensors, hw-enablement needs to be done on a laptop by laptop basis * Good image quality requires per sensor/laptop model tuning Parts of these challenges are solved by libcamera. For now the aim is a simple stack with good enough image quality for video-conferencing. The plan is to have a stack consisting of: # Mainline kernel sensor driver (currently supported: ov2740, ov01a10, hi556) # Mainline kernel IPU6 CSI receiver driver # libcamera simplepipeline-handler using software ISP for debayering + 3A # pipewire with pipewire libcamera plugin # pipewire support in Firefox (see [https://jgrulich.cz/tag/pipewire/ Jan Grulich's blog]) == Feedback == No feedback yet. == Benefit to Fedora == Currently IPU6 cameras do not work OOTB in Fedora, with the new libcamera software ISP stack these should work OOTB on laptops with supported camera sensors. == Scope == * Proposal owners: ** The IPU6 CSI receiver has landed in 6.10 and some bugfixes coming to 6.11 have been added as downstream patches ** libcamera needs a couple of small downstream-patches to enable the simple pipeline for the IPU6 ** pipewire libcamera plugin needs to be made part of the default Workstation patch-set * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes (better hw-support should help getting more users) == Upgrade/compatibility impact == The pipewire-plugin-libcamera needs to be automatically added on Fedora workstation updates to ensure things work. Otherwise there is no upgrade impact. == How To Test == Test plan will be filled in as soon as all necessary bits have landed in rawhide. == User Experience == IPU6 cameras on laptops with supported camera sensors should work OOTB after this change, with the caveat that the image quality may be less then ideal. The hope is that image quality will improve over time as the software ISP and its 3A algorithms get improved. With that said it is unrealistic to expect the image quality to become as good as the proprietary stack which has extensive image quality tuning done on a per laptop basis. == Dependencies == IPU6 support not only depends on kernel and libcamera support taken care of by the proposal owner, but also on pipewire camera support and on Firefox pipewire camera support. == Contingency Plan == ATM IPU6 cameras do not work at all. So unless the new kernel driver actually causes regressions outside of the camera functionality no contingency plan is necessary. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora 41 has added support for IPU6 cameras on laptops using ov2740, ov01a10 and hi556 sensors. This support requires using applications which support accessing cameras through pipewire such as Firefox. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list
F41 Change Proposal: IPU6 camera support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/IPU6_Camera_support Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-ipu6-camera-support-self-contained/124329 This is a proposed Change for Fedora Linux. 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 == Integrate support into Fedora for Intel IPU6 attached MIPI cameras using the IPU6 CSI-receiver (isys) driver which has landed in kernel 6.10 together with libcamwera's 0.3 software ISP support and Firefox' recent support for using cameras through pipewire. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == Many new laptops models have a camera-sensor which is directly attached to the laptops CPU/SoC over a MIPI CSI2 databus instead of using a USB webcam module talking the standard USB UVC protocol. These cameras require a lot of work on the software side to go from the raw Bayer data received over the CSI2 bus to an usable image. This includes both controlling things like exposure and gain settings on the sensor as well as a lot of processing of the raw data, such as debayering and whitebalancing. Adding support for these complex cameras is tricky because: * Applications can no longer directly use /dev/video now * Supporting ISPs (if supported in the kernel) requires ISP model specific knowledge in userspace * Vendor's 3A algorithms for auto-exposure/gain, auto-whitebalance and auto-focus are secret and need to have open-source counterparts written and tuned * Instead of having a single UVC driver this requires CSI-receiver + ISP + sensor drivers in the kernel * Different IPU6 laptop models use different sensors, hw-enablement needs to be done on a laptop by laptop basis * Good image quality requires per sensor/laptop model tuning Parts of these challenges are solved by libcamera. For now the aim is a simple stack with good enough image quality for video-conferencing. The plan is to have a stack consisting of: # Mainline kernel sensor driver (currently supported: ov2740, ov01a10, hi556) # Mainline kernel IPU6 CSI receiver driver # libcamera simplepipeline-handler using software ISP for debayering + 3A # pipewire with pipewire libcamera plugin # pipewire support in Firefox (see [https://jgrulich.cz/tag/pipewire/ Jan Grulich's blog]) == Feedback == No feedback yet. == Benefit to Fedora == Currently IPU6 cameras do not work OOTB in Fedora, with the new libcamera software ISP stack these should work OOTB on laptops with supported camera sensors. == Scope == * Proposal owners: ** The IPU6 CSI receiver has landed in 6.10 and some bugfixes coming to 6.11 have been added as downstream patches ** libcamera needs a couple of small downstream-patches to enable the simple pipeline for the IPU6 ** pipewire libcamera plugin needs to be made part of the default Workstation patch-set * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes (better hw-support should help getting more users) == Upgrade/compatibility impact == The pipewire-plugin-libcamera needs to be automatically added on Fedora workstation updates to ensure things work. Otherwise there is no upgrade impact. == How To Test == Test plan will be filled in as soon as all necessary bits have landed in rawhide. == User Experience == IPU6 cameras on laptops with supported camera sensors should work OOTB after this change, with the caveat that the image quality may be less then ideal. The hope is that image quality will improve over time as the software ISP and its 3A algorithms get improved. With that said it is unrealistic to expect the image quality to become as good as the proprietary stack which has extensive image quality tuning done on a per laptop basis. == Dependencies == IPU6 support not only depends on kernel and libcamera support taken care of by the proposal owner, but also on pipewire camera support and on Firefox pipewire camera support. == Contingency Plan == ATM IPU6 cameras do not work at all. So unless the new kernel driver actually causes regressions outside of the camera functionality no contingency plan is necessary. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora 41 has added support for IPU6 cameras on laptops using ov2740, ov01a10 and hi556 sensors. This support requires using applications which support accessing cameras through pipewire such as Firefox. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list
Re: Fedora & AI Survey Now Live Until July 16th
I disagree a little on the results to be meaningless just because the tone or phrasing is positive, particularly with the topic of AI because it is far too easy to list all the negatives associated with AI, and doing that doesn't move the conversation forward. Structuring that question in this ranking way allows for a better conversation on how to use AI in whatever area comes out as the best or one of the better fitting spots for AI in Fedora based on how people ranked them. We want to focus on the potential benefits (or positives) that we could leverage from AI while understanding the preferences of our community with this initial survey. But, having said that, I take your points :) That's good feedback to have for any other surveys we will send on how we structure questions and answering. On Mon, Jul 1, 2024 at 8:45 PM Tom Hughes wrote: > On 01/07/2024 20:07, Aoife Moloney wrote: > > > I would also like to add that we deliberately took a positive tone for > > this survey as it is far too easy to find (many) negatives for AI (and > > for good reason!), and we wanted to try to look at the benefits we could > > get from AI instead if applied properly and wit the best interest of > > Fedora driving the use of AI in parts of the projects ecosystem. > > Well I guess if you're only interested in positive responses then > we can say the survey design is a success - just a shame that the > results will be meaningless. > > I understand why surveys have to use closed form questions with a > fixed set of responses but it should always be possible to opt out > of questions and, ideally, to explicitly indicate that you do not > agree with any of the proposed responses, otherwise you are artificially > restricting the results to the set of concepts that were (either > deliberately or subconsciously) in the mind of the survey creator. > > At the very least the question needs to be changed to not indicate > that two answers are required if five are! > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
hniques [https://desfontain.es/blog/friendly-intro-to-differential-privacy.html Differential privacy] would potentially allow Fedora systems to submit inaccurate data to the metrics server, while ensuring the overall data set is still representative and useful. We would welcome collaboration from Fedora community members interested in improving the metrics collection system to adopt such techniques. == Benefit to Fedora == See “What will the data be used for?” == Scope == * Proposal owners: this change requires substantial technical and nontechnical work from the change owners. This will include: ** Properly packaging eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation for Fedora ** Modifying eos-metrics-instrumentation so that it does not send events that are not approved for use in Fedora ** Creation of the metrics SIG and its various policies and procedures ** Documentation for end users and members of the community * Other developers: Community Platform Engineering (CPE) will need to host the metrics server infrastructure. * Release engineering: [https://pagure.io/releng/issues/11514 #11514] * Policies and guidelines: see "How will data collection be approved?" * Trademark approval: N/A (not needed for this change) * Alignment with objectives: there are currently no [https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora Initiatives]. However, the generated data will be broadly applicable to Fedora community activities. == Upgrade/Compatibility Impact == There are no special technical challenges in this regard. Metrics collection will only be enabled in response to an explicit opt-in by the user, through a UI in either gnome-initial-setup or gnome-control-center. gnome-initial-setup is only shown for new installs, meaning that the only way to enable metrics on an upgraded system would be through gnome-control-center. == How to Test == Testing is not currently possible. Instructions will be provided when this changes. == User Experience== The user experience for the system will consist of: # In initial setup, a UI to choose between metrics collection being on or off. There will be no default in the UI and users will have to explicitly choose one of the two options. # In the privacy Settings, a switch to turn metrics collection on or off # User documentation about the service # A method to view locally collected metrics data == Dependencies == Packages wanting to collect metrics data will need to depend on eos-metrics. For example, to collect statistics about Settings usage, the gnome-control-center package would need to depend on eos-metrics in order to send a metric to eos-event-recorder-daemon. == Contingency Plan == * Contingency mechanism: remove the eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation packages from the workstation-product comps group, and rebuild any packages that gained a dependency on eos-metrics. * Contingency deadline: beta freeze * Blocks release? If the change is incomplete, it will need to be reverted before release. == Documentation == This feature depends on several different upstream projects, each of which have their own documentation. Client side components: * eos-metrics has online docs at [https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metrics.xml D-Bus interface XML]. API documentation is also built and installed in a docs subpackage. * eos-event-recorder-daemon and eos-metrics-instrumentation components do not have online documentation at this time. Server-side documentation: * [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source Azafea-metrics-proxy] * [https://github.com/endlessm/azafea/tree/master/docs/source Azafea] * [https://azafea.readthedocs.io/en/latest/events.html Events recognized by the server] (this documentation is currently focused on use by Endless OS rather than by Fedora, and includes documentation of many events that are no longer sent by Endless OS) == Release Notes == These will be provided if the proposal is approved and successfully implemented. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US
F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
hniques [https://desfontain.es/blog/friendly-intro-to-differential-privacy.html Differential privacy] would potentially allow Fedora systems to submit inaccurate data to the metrics server, while ensuring the overall data set is still representative and useful. We would welcome collaboration from Fedora community members interested in improving the metrics collection system to adopt such techniques. == Benefit to Fedora == See “What will the data be used for?” == Scope == * Proposal owners: this change requires substantial technical and nontechnical work from the change owners. This will include: ** Properly packaging eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation for Fedora ** Modifying eos-metrics-instrumentation so that it does not send events that are not approved for use in Fedora ** Creation of the metrics SIG and its various policies and procedures ** Documentation for end users and members of the community * Other developers: Community Platform Engineering (CPE) will need to host the metrics server infrastructure. * Release engineering: [https://pagure.io/releng/issues/11514 #11514] * Policies and guidelines: see "How will data collection be approved?" * Trademark approval: N/A (not needed for this change) * Alignment with objectives: there are currently no [https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora Initiatives]. However, the generated data will be broadly applicable to Fedora community activities. == Upgrade/Compatibility Impact == There are no special technical challenges in this regard. Metrics collection will only be enabled in response to an explicit opt-in by the user, through a UI in either gnome-initial-setup or gnome-control-center. gnome-initial-setup is only shown for new installs, meaning that the only way to enable metrics on an upgraded system would be through gnome-control-center. == How to Test == Testing is not currently possible. Instructions will be provided when this changes. == User Experience== The user experience for the system will consist of: # In initial setup, a UI to choose between metrics collection being on or off. There will be no default in the UI and users will have to explicitly choose one of the two options. # In the privacy Settings, a switch to turn metrics collection on or off # User documentation about the service # A method to view locally collected metrics data == Dependencies == Packages wanting to collect metrics data will need to depend on eos-metrics. For example, to collect statistics about Settings usage, the gnome-control-center package would need to depend on eos-metrics in order to send a metric to eos-event-recorder-daemon. == Contingency Plan == * Contingency mechanism: remove the eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation packages from the workstation-product comps group, and rebuild any packages that gained a dependency on eos-metrics. * Contingency deadline: beta freeze * Blocks release? If the change is incomplete, it will need to be reverted before release. == Documentation == This feature depends on several different upstream projects, each of which have their own documentation. Client side components: * eos-metrics has online docs at [https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metrics.xml D-Bus interface XML]. API documentation is also built and installed in a docs subpackage. * eos-event-recorder-daemon and eos-metrics-instrumentation components do not have online documentation at this time. Server-side documentation: * [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source Azafea-metrics-proxy] * [https://github.com/endlessm/azafea/tree/master/docs/source Azafea] * [https://azafea.readthedocs.io/en/latest/events.html Events recognized by the server] (this documentation is currently focused on use by Endless OS rather than by Fedora, and includes documentation of many events that are no longer sent by Endless OS) == Release Notes == These will be provided if the proposal is approved and successfully implemented. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora & AI Survey Now Live Until July 16th
DJ & Tom - thank you for that clarification on how to interpret your ranking, and I can assure you and other folks who feel similar about answering that question that that is indeed the way we will be analysing the results - top ranked being best fit, 5th or last ranked being least or worst fit. Also for anyone who has yet to complete the survey, the last question is an optional, free format answer so I would suggest using that to expand on reasons why you ranked certain areas #1, #2 etc for what problems you see AI addressing in those parts of the project. I would also like to add that we deliberately took a positive tone for this survey as it is far too easy to find (many) negatives for AI (and for good reason!), and we wanted to try to look at the benefits we could get from AI instead if applied properly and wit the best interest of Fedora driving the use of AI in parts of the projects ecosystem. This survey is just trying to understand the preferences and wants of the Fedora community when it comes to AI, and not a guarantee that the project will be introducing AI in all of the mentioned areas. If you have any other questions that I can try to help clarify about this, please dont hesitate to reach out. I want folks to be able to answer comfortably and honestly so if I can help at all, just metaphorically shout :) On Mon, Jul 1, 2024 at 7:00 PM DJ Delorie wrote: > > I found the last question disappointing - it required me to rank five > options as to how well they fit in Fedora, without letting my say how > well I think each of them fit in Fedora. There was no way to say > "Doesn't fit" although I would have preferred they all be marked that > way. > > Consider my answer to be "how poorly these fit in Fedora, with the worst > fitting listed last." > > -- > ___ > 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 > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 & AI Survey Now Live Until July 16th
Hi folks, Thank you for contributing to our discussion on what kinds of questions are useful for us to ask our community on the subject of AI in the Fedora ecosystem [1]. We've created a short survey [2] based on the questions that were proposed that we feel are general enough for everyone to feel comfortable answering, and from the answer we receive, the council and other governing bodies of the project can start formalising some AI-related focus areas and develop solid guidelines for the use of AI in the project ecosystem. The deadline is July 16th, it shouldn't take more than a few minutes of your time to complete, and I will be sending some reminders between now and the closing date too. A quick reminder that this is not our annual contributors survey, and that survey will be launching soon with a section around AI too. I want to offer an advance apologies for any survey-related fatigue, but when it comes to creating AI guidelines for the project and understanding how our community is doing and feels about the project, this AI survey and the contributor survey is truly the best way to get that feedback and create actionable stuff 'n' things from your direct responses. Kindest regards, Aoife [1] https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-be-asking/118338 [2] https://fedoraproject.limequery.com/142117?lang=en -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora & AI Survey Now Live Until July 16th
Hi folks, Thank you for contributing to our discussion on what kinds of questions are useful for us to ask our community on the subject of AI in the Fedora ecosystem [1]. We've created a short survey [2] based on the questions that were proposed that we feel are general enough for everyone to feel comfortable answering, and from the answer we receive, the council and other governing bodies of the project can start formalising some AI-related focus areas and develop solid guidelines for the use of AI in the project ecosystem. The deadline is July 16th, it shouldn't take more than a few minutes of your time to complete, and I will be sending some reminders between now and the closing date too. A quick reminder that this is not our annual contributors survey, and that survey will be launching soon with a section around AI too. I want to offer an advance apologies for any survey-related fatigue, but when it comes to creating AI guidelines for the project and understanding how our community is doing and feels about the project, this AI survey and the contributor survey is truly the best way to get that feedback and create actionable stuff 'n' things from your direct responses. Kindest regards, Aoife [1] https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-be-asking/118338 [2] https://fedoraproject.limequery.com/142117?lang=en -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Enabling composefs by default for Atomic Desktops, CoreOS and IoT (Self-Contained)
uarantees. This will align the existing image based variants of Fedora (Atomic Desktops, CoreOS, IoT) to the work that is done as part of the Bootable Containers Initiative. == Scope == * Proposal owners: ** Enable composefs in Atomic Desktops (bootable containers only) ** Enable composefs in CoreOS ** Enable composefs in IoT * Other developers: ** Applications doing disk-full checks on `/` will have to be updated to look at other places as `/` will be small (a few MB) and full (100% used). * 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 the Fedora Strategy 2028: ** Aligns with the goal: "Immutable variants are the majority of Fedora Linux in use" == Upgrade/compatibility impact == To be fleshed out == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Make sure that you do not rely on Dual Boot support * Make sure that you bootloader is recent enough to support BLS configs ** If you don't know, update it using the instructions from https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2048350047 first * Remove `ostree-grub2` from the upcoming deployment: `rpm-ostree override remove ostree-grub2` * Enable composefs: `sudo ostree config set ex-integrity.composefs yes` * Update your system to a new version: `rpm-ostree update` ** Or do a manual (re)deploy of the current version: `sudo ostree admin deploy fedora/39/x86_64/silverblue` * Reboot into the new deployment == User Experience == The main visible change will be that the root filesystem (`/`) is now small and full (a few MB, 100% used). The real root is mounted in `/sysroot` and most of the data is stored in `/var`. == Dependencies == For the Atomic Desktops, this change depends on: * Bootupd support: ** https://gitlab.com/fedora/ostree/sig/-/issues/1 ** https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd CoreOS and IoT already do not depends on `ostree-grub2`. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Undo the change. It's a single line change in a configuration file. * Contingency deadline: Beta Freeze / Release Freeze * Blocks release? No == Documentation == To be written. == Release Notes == To be written once the change is accepted. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Enabling composefs by default for Atomic Desktops, CoreOS and IoT (Self-Contained)
uarantees. This will align the existing image based variants of Fedora (Atomic Desktops, CoreOS, IoT) to the work that is done as part of the Bootable Containers Initiative. == Scope == * Proposal owners: ** Enable composefs in Atomic Desktops (bootable containers only) ** Enable composefs in CoreOS ** Enable composefs in IoT * Other developers: ** Applications doing disk-full checks on `/` will have to be updated to look at other places as `/` will be small (a few MB) and full (100% used). * 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 the Fedora Strategy 2028: ** Aligns with the goal: "Immutable variants are the majority of Fedora Linux in use" == Upgrade/compatibility impact == To be fleshed out == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Make sure that you do not rely on Dual Boot support * Make sure that you bootloader is recent enough to support BLS configs ** If you don't know, update it using the instructions from https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2048350047 first * Remove `ostree-grub2` from the upcoming deployment: `rpm-ostree override remove ostree-grub2` * Enable composefs: `sudo ostree config set ex-integrity.composefs yes` * Update your system to a new version: `rpm-ostree update` ** Or do a manual (re)deploy of the current version: `sudo ostree admin deploy fedora/39/x86_64/silverblue` * Reboot into the new deployment == User Experience == The main visible change will be that the root filesystem (`/`) is now small and full (a few MB, 100% used). The real root is mounted in `/sysroot` and most of the data is stored in `/var`. == Dependencies == For the Atomic Desktops, this change depends on: * Bootupd support: ** https://gitlab.com/fedora/ostree/sig/-/issues/1 ** https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd CoreOS and IoT already do not depends on `ostree-grub2`. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Undo the change. It's a single line change in a configuration file. * Contingency deadline: Beta Freeze / Release Freeze * Blocks release? No == Documentation == To be written. == Release Notes == To be written once the change is accepted. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)
== -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)
== -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Deadlines and other important deadlines!
Hi folks, A quick reminder that for the F41 development cycle[1], the system-wide changes submission deadline is today, June 18th. This does not mean your change has to be accepted, it just means that you need to get your proposal filed by this date[2]. So if you are thinking of proposing a change, even if it's not fully fleshed out, consider submitting it anyway today and make use of our great community to iterate on your proposal in real time. The self-contained change proposal deadline is July 16th It's important to also note that the 'testable' deadline[3] for changes is August 6th, however please be mindful that this is also our branching date from Rawhide so it would be preferable to have your changes landed in rawhide and available for testing before this date. Your change, once approved to F41, landed in Rawhide for branching and testable, must then be 100% code complete[4] before we enter Beta Freeze on 20th August, or it will most likely need to be retargeted to F42. Changes that are not code complete by the Beta Freeze date puts a big strain on the folks involved with each Fedora release, so by adhering to these dates, it helps the overall release process run much smoother, we all benefit from a higher quality release and a slightly less stressful crunch time at the end :) So thank you in advance for getting your changes ready in time for these milestones, it's hugely appreciated. Please dont hesitate to reach out with questions or if I can be of any help. Kindest regards, Aoife [1] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html [2] https://docs.fedoraproject.org/en-US/program_management/changes_policy/ [3][4] https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process_milestones -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/120330 This is a proposed Change for Fedora Linux. 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 == Nvidia Drivers have been removed from GNOME Software because it didn't support Secure Boot which is increasingly often enabled. This change brings the option back with Secure Boot supported. == Owner == * Name: [[User:eischmann|Jiří Eischmann]] * Name: Milan Crha * Email: eischm...@redhat.com * Email: mc...@redhat.com == Detailed Description == The goal is this change is to provide an easy way to install Nvidia drivers in Fedora Workstation. It was removed from GNOME Software because the original mechanism didn't support Secure Boot. When users installed the drivers with Secure Boot enabled, they could not boot the OS. What we're doing this time is using mokutil to create a key for the user to self-sign the drivers. When installing the drivers, the user is asked to provide a password for the key. On the next reboot the user is presented with the mokutil interface to enroll the key. See the [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034 upstream merge request] for more details and screenshots. == Feedback == == Benefit to Fedora == The Nvidia drivers are necessary not only for gaming, but especially for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of Fedora because of their license, but Fedora should offer an easy installation of them to stay relevant in the respective fields. == Scope == * Proposal Owners: The feature will be implemented in GNOME Software 47 and will be shipped in the gnome-software package in Fedora Linux 41. * Other Developers: No work required from other Fedora developers. The only requirement outside of the scope of the proposal owners is to reintroduce AppStream metadata into the Nvidia driver repo on RPMFusion.org. * Release Engineering: * Policies and Guidelines: * Trademark approval: * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact is expected. == How To Test == 1. Open GNOME Software. 2. Search for "nvidia". 3. Choose the Nvidia driver, click Install and follow the prompts. 4. Reboot and enroll the self-signing key in the mokutil tool following <> 5. The OS should boot up with the Nvidia driver enabled. == User Experience == This change aims to improve user experience of installing the proprietary Nvidia driver. == Contingency Plan == If the feature is not implemented on time for Fedora Linux 41, we can simply remove AppStream metadata from the Nvidia driver repo and the driver will not show up in GNOME Software like in Fedora Linux 40. == Documentation == The GNOME Software part is intuitive and doesn't require documentation. The mokutil part is less intuitive and will be documented in the Fedora Workstation section on docs.fedoraproject.org. The docs will be published when the feature lands in Fedora Linux 41. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/120330 This is a proposed Change for Fedora Linux. 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 == Nvidia Drivers have been removed from GNOME Software because it didn't support Secure Boot which is increasingly often enabled. This change brings the option back with Secure Boot supported. == Owner == * Name: [[User:eischmann|Jiří Eischmann]] * Name: Milan Crha * Email: eischm...@redhat.com * Email: mc...@redhat.com == Detailed Description == The goal is this change is to provide an easy way to install Nvidia drivers in Fedora Workstation. It was removed from GNOME Software because the original mechanism didn't support Secure Boot. When users installed the drivers with Secure Boot enabled, they could not boot the OS. What we're doing this time is using mokutil to create a key for the user to self-sign the drivers. When installing the drivers, the user is asked to provide a password for the key. On the next reboot the user is presented with the mokutil interface to enroll the key. See the [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034 upstream merge request] for more details and screenshots. == Feedback == == Benefit to Fedora == The Nvidia drivers are necessary not only for gaming, but especially for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of Fedora because of their license, but Fedora should offer an easy installation of them to stay relevant in the respective fields. == Scope == * Proposal Owners: The feature will be implemented in GNOME Software 47 and will be shipped in the gnome-software package in Fedora Linux 41. * Other Developers: No work required from other Fedora developers. The only requirement outside of the scope of the proposal owners is to reintroduce AppStream metadata into the Nvidia driver repo on RPMFusion.org. * Release Engineering: * Policies and Guidelines: * Trademark approval: * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact is expected. == How To Test == 1. Open GNOME Software. 2. Search for "nvidia". 3. Choose the Nvidia driver, click Install and follow the prompts. 4. Reboot and enroll the self-signing key in the mokutil tool following <> 5. The OS should boot up with the Nvidia driver enabled. == User Experience == This change aims to improve user experience of installing the proprietary Nvidia driver. == Contingency Plan == If the feature is not implemented on time for Fedora Linux 41, we can simply remove AppStream metadata from the Nvidia driver repo and the driver will not show up in GNOME Software like in Fedora Linux 40. == Documentation == The GNOME Software part is intuitive and doesn't require documentation. The mokutil part is less intuitive and will be documented in the Fedora Workstation section on docs.fedoraproject.org. The docs will be published when the feature lands in Fedora Linux 41. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposl: Libvirt Virtual Network NFTables (self-contained)
ker's, and so override the DENY policy docker had created. When libvirt uses its nftables backend, its FORWARD rules end up in a separate table from dockers'. Since nftables requires a packet to be allowed by *all* top level tables, docker's DENY rules will block the libvirt traffic. The possible workarounds are: * Reconfigure libvirt to use iptables when compatibility with docker is required * Use podman instead of docker, since podman does not create problematic iptables rules * TBD: whether libvirt can do something automagic to workaround docker's DENY policy === Known issue: non-firewalld firewall mgmt tools === Libvirt requires the ability to mark traffic from the guest to the host, for DHCP and DNS as permitted. When using iptables kernel modules, libvirt could achieve this by inserting some rules in the INPUT chain to allow DHCP/DNS. When using nftables kernel modules, there are an arbitrary number of application defined top level tables with unknown names. All top level tables must allow a packet in order for it to pass. libvirt must not touch tables created by other applications, thus it is no longer practical to seemlessly allow DHCP & DNS when nftables userspace is used by any component on the system. To address this, when Fedora 32 switched firewall to its nftables backend, libvirt gained ability to install a firewalld zone files to allow guest traffic. Libvirt does not have equivalent integration for any other nftables based firewall mgmt tool, but other tools using iptables remained compatible as long as libvirt also kept using iptables. With libvirt changing to prefer its nftables backend, libvirt is will be incompatible with any other non-firewalld firewall management tools. The compatibility matrix is as follows # Kernel module: iptables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: iptables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround The two main workaround options: * Change /etc/libvirt/network.conf 'firewall_backend' setting to 'iptables' * Manually add rules to the firewall mgmt tool to allow DHCP, DNS & SSH from guests. The long term answer is to enhance libvirt upstream to natively learn about integration for more firewall mgmt tools than just firewalld. eg UFW: https://gitlab.com/libvirt/libvirt/-/issues/644 == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Perform a default libvirt KVM install 'dnf groupinstall @Virtualization' * Create a KVM guest using virt-install, virt-manager, or cockpit, and configure it to use the 'default' virtual network * Boot the KVM guest * Login to the KVM guest graphical console, and attempt to connect to the internet. eg curl https://google.com * Configure the KVM guest to enable SSH (if not already allowed & started) * Attempt to SSH to the guest from the host == User Experience == * Libvirt firewall rules will no longer be present when running 'iptables -L' * A new 'libvirt_network' table will be present when running 'nft list ruleset' == Dependencies == None == Contingency Plan == * Contingency mechanism: Libvirt maintainers to change the libvirt.spec to set 'prefer_nftables' variable to '0' for Fedora 41 * Contingency deadline: Final freeze * Blocks release? No == Documentation == General libvirt network documentation at https://libvirt.org/formatnetwork.html == Release Notes == The libvirt virtual network has been changed to prefer use of the nftables firewall backend instead of iptables. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproje
F41 Change Proposl: Libvirt Virtual Network NFTables (self-contained)
ker's, and so override the DENY policy docker had created. When libvirt uses its nftables backend, its FORWARD rules end up in a separate table from dockers'. Since nftables requires a packet to be allowed by *all* top level tables, docker's DENY rules will block the libvirt traffic. The possible workarounds are: * Reconfigure libvirt to use iptables when compatibility with docker is required * Use podman instead of docker, since podman does not create problematic iptables rules * TBD: whether libvirt can do something automagic to workaround docker's DENY policy === Known issue: non-firewalld firewall mgmt tools === Libvirt requires the ability to mark traffic from the guest to the host, for DHCP and DNS as permitted. When using iptables kernel modules, libvirt could achieve this by inserting some rules in the INPUT chain to allow DHCP/DNS. When using nftables kernel modules, there are an arbitrary number of application defined top level tables with unknown names. All top level tables must allow a packet in order for it to pass. libvirt must not touch tables created by other applications, thus it is no longer practical to seemlessly allow DHCP & DNS when nftables userspace is used by any component on the system. To address this, when Fedora 32 switched firewall to its nftables backend, libvirt gained ability to install a firewalld zone files to allow guest traffic. Libvirt does not have equivalent integration for any other nftables based firewall mgmt tool, but other tools using iptables remained compatible as long as libvirt also kept using iptables. With libvirt changing to prefer its nftables backend, libvirt is will be incompatible with any other non-firewalld firewall management tools. The compatibility matrix is as follows # Kernel module: iptables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: iptables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround The two main workaround options: * Change /etc/libvirt/network.conf 'firewall_backend' setting to 'iptables' * Manually add rules to the firewall mgmt tool to allow DHCP, DNS & SSH from guests. The long term answer is to enhance libvirt upstream to natively learn about integration for more firewall mgmt tools than just firewalld. eg UFW: https://gitlab.com/libvirt/libvirt/-/issues/644 == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Perform a default libvirt KVM install 'dnf groupinstall @Virtualization' * Create a KVM guest using virt-install, virt-manager, or cockpit, and configure it to use the 'default' virtual network * Boot the KVM guest * Login to the KVM guest graphical console, and attempt to connect to the internet. eg curl https://google.com * Configure the KVM guest to enable SSH (if not already allowed & started) * Attempt to SSH to the guest from the host == User Experience == * Libvirt firewall rules will no longer be present when running 'iptables -L' * A new 'libvirt_network' table will be present when running 'nft list ruleset' == Dependencies == None == Contingency Plan == * Contingency mechanism: Libvirt maintainers to change the libvirt.spec to set 'prefer_nftables' variable to '0' for Fedora 41 * Contingency deadline: Final freeze * Blocks release? No == Documentation == General libvirt network documentation at https://libvirt.org/formatnetwork.html == Release Notes == The libvirt virtual network has been changed to prefer use of the nftables firewall backend instead of iptables. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Confidential Virtualization Host with AMD SEV-SNP (self-contained)
. '''ONLY''' if it merges to linus' tree, then proposal owners are to provide Fedora kernel maintainers with a set of backported patches against 6.10 prior to Fedora Beta. Fedora 41 will get 6.11 kernels after GA. === Release engineering === N/A === Policies and guidelines === N/A === Trademark approval === N/A === Alignment with the Fedora Strategy === * Fedora will be demonstrating leading / state of the art integration of SEV-SNP feature into a Linux distribution's virtualization host stack. * Fedora will be providing the fully OSS host-to-guest stack for confidential virtual machines on modern AMD x86_64 EPYC hardware. == Upgrade/compatibility impact == No impact anticipated. Existing users of SEV/SEV-ES technology will keep using it without changes. The new SEV-SNP technology is strictly an opt-in for users with suitably new AMD CPUs. == Early Testing (Optional) == Do you require 'QA Blueprint' support? Y (probably useful?) == How To Test == Use of AMD SEV-SNP technology requires an AMD EPYC CPU with the Zen 3 generation micro-architecture, or newer (Milan, Genoa). These are identified by the 4th digit in the processor model name having the value '3' or greater. eg EPYC7xx3 or EPYC9xx4. See also [https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/58207-using-sev-with-amd-epyc-processors.pdf SEV User Guide (pdf), Chapter 1] for CPU model support guidance. * TBD: document process for configuring host bare metal firmware (if applicable?) * TBD: document process for deploying host software components. Likely should not require any special steps, beyond the normal libvirt + KVM install process. * TBD: document process for creating a guest. Will update existing [https://libvirt.org/kbase/launch_security_sev.html libvirt SEV docs] to cover SEV-SNP * TBD: document process for attesting a running guest. Again, will update above libvirt SEV docs. == User Experience == * Virtualization host owners will be launch confidential virtual machines using AMD SEV-SNP technology * Virtualization host owners will be able to provide a secure virtual TPM to confidential guests, replacing the current non-confidential swtpm solution in the host * Guest owners will be able to prove that their OS is running in a Fedora host confidential virtual machine protected by AMD SEV-SNP, by performing a guest attestation * Guest owners will be able to measure their guest OS software environment using the TPM. Caveat: this is an ephemeral TPM initially, which imposes limits on the ways in which users can take advantage of it. A persistent TPM will be supported at a later date. == Dependencies == * kernel * edk2 * coconut-svsm (new package [https://github.com/coconut-svsm/svsm github upstream]) ** rust-intrusive-collections (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290692 Review Request]) ** rust-packit (new package or include as vendored) * igvm (new package [https://github.com/microsoft/igvm/ github upstream]) ** rust-hmac-sha512 (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290698 Review Request]) ** rust-bitfield-struct (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290696 Review Request]) ** rust-open-enum (new package) ** rust-open-enum-derive (new package) ** rust-range-map-vec (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2282977 Review Request]: Approved) * qemu * libvirt * virt-manager (for virt-install tool) * snphost [https://github.com/virtee/snphost github upstream] * snpguest (new package, [https://github.com/virtee/snpguest github upstream]) == Contingency Plan == * Contingency mechanism: None. All the work is arriving either via rebases to new upstream versions of existing packages, patches to existing packages, or via new package reviews. If the deadline is missed, then whatever has already arrived in Fedora will remain in Fedora and will not harm other existing Fedora functionality. The remaining pieces will wait until the next Fedora dev cycle to be integrated, completing the desired user experience. As such, no contingency action needs to be taken should the Fedora feature completion deadline be missed. * Contingency deadline: N/A * Blocks release? No == Documentation == * Insert link to kernel docs, when available * Insert link to QEMU docs, when available * Insert link to libvirt docs, when available * Write a Fedora wiki page illustrating end-to-end setup and usage example == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list
F41 Change Proposal: Confidential Virtualization Host with AMD SEV-SNP (self-contained)
. '''ONLY''' if it merges to linus' tree, then proposal owners are to provide Fedora kernel maintainers with a set of backported patches against 6.10 prior to Fedora Beta. Fedora 41 will get 6.11 kernels after GA. === Release engineering === N/A === Policies and guidelines === N/A === Trademark approval === N/A === Alignment with the Fedora Strategy === * Fedora will be demonstrating leading / state of the art integration of SEV-SNP feature into a Linux distribution's virtualization host stack. * Fedora will be providing the fully OSS host-to-guest stack for confidential virtual machines on modern AMD x86_64 EPYC hardware. == Upgrade/compatibility impact == No impact anticipated. Existing users of SEV/SEV-ES technology will keep using it without changes. The new SEV-SNP technology is strictly an opt-in for users with suitably new AMD CPUs. == Early Testing (Optional) == Do you require 'QA Blueprint' support? Y (probably useful?) == How To Test == Use of AMD SEV-SNP technology requires an AMD EPYC CPU with the Zen 3 generation micro-architecture, or newer (Milan, Genoa). These are identified by the 4th digit in the processor model name having the value '3' or greater. eg EPYC7xx3 or EPYC9xx4. See also [https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/58207-using-sev-with-amd-epyc-processors.pdf SEV User Guide (pdf), Chapter 1] for CPU model support guidance. * TBD: document process for configuring host bare metal firmware (if applicable?) * TBD: document process for deploying host software components. Likely should not require any special steps, beyond the normal libvirt + KVM install process. * TBD: document process for creating a guest. Will update existing [https://libvirt.org/kbase/launch_security_sev.html libvirt SEV docs] to cover SEV-SNP * TBD: document process for attesting a running guest. Again, will update above libvirt SEV docs. == User Experience == * Virtualization host owners will be launch confidential virtual machines using AMD SEV-SNP technology * Virtualization host owners will be able to provide a secure virtual TPM to confidential guests, replacing the current non-confidential swtpm solution in the host * Guest owners will be able to prove that their OS is running in a Fedora host confidential virtual machine protected by AMD SEV-SNP, by performing a guest attestation * Guest owners will be able to measure their guest OS software environment using the TPM. Caveat: this is an ephemeral TPM initially, which imposes limits on the ways in which users can take advantage of it. A persistent TPM will be supported at a later date. == Dependencies == * kernel * edk2 * coconut-svsm (new package [https://github.com/coconut-svsm/svsm github upstream]) ** rust-intrusive-collections (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290692 Review Request]) ** rust-packit (new package or include as vendored) * igvm (new package [https://github.com/microsoft/igvm/ github upstream]) ** rust-hmac-sha512 (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290698 Review Request]) ** rust-bitfield-struct (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290696 Review Request]) ** rust-open-enum (new package) ** rust-open-enum-derive (new package) ** rust-range-map-vec (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2282977 Review Request]: Approved) * qemu * libvirt * virt-manager (for virt-install tool) * snphost [https://github.com/virtee/snphost github upstream] * snpguest (new package, [https://github.com/virtee/snpguest github upstream]) == Contingency Plan == * Contingency mechanism: None. All the work is arriving either via rebases to new upstream versions of existing packages, patches to existing packages, or via new package reviews. If the deadline is missed, then whatever has already arrived in Fedora will remain in Fedora and will not harm other existing Fedora functionality. The remaining pieces will wait until the next Fedora dev cycle to be integrated, completing the desired user experience. As such, no contingency action needs to be taken should the Fedora feature completion deadline be missed. * Contingency deadline: N/A * Blocks release? No == Documentation == * Insert link to kernel docs, when available * Insert link to QEMU docs, when available * Insert link to libvirt docs, when available * Write a Fedora wiki page illustrating end-to-end setup and usage example == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list
Re: F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
This change is for Fedora Linux 41, and not 411 as the typo in the heading suggests :) -- ___ 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: F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
This change is for Fedora Linux 41, and not 411 as the typo in the heading suggests :) -- ___ 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
F41 Change Proposal: Replace Nose With Pynose (self-contained)
== * 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 == [https://github.com/mdmintz/pynose/blob/master/README.md pynose README] and above == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Replace Nose With Pynose (self-contained)
== * 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 == [https://github.com/mdmintz/pynose/blob/master/README.md pynose README] and above == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: GIMP Version 3 (self-contained)
improvements in the handling of input devices such as tablets and when used on high resolution displays. == Dependencies == A number of third party GIMP plugins are available to be installed as packages on Fedora Linux. With the continued availability of version 2.x of GIMP, these packages can still be installed and used with the old version. Whether or not these plugins will support the new GIMP version very much depends on the particular plugin, or rather the upstream projects for these plugins. Therefore it’s a bit early to make plans for packaging plugins available for both GIMP versions at this point. == Contingency Plan == * Contingency mechanism: Not ship the package, bump “seamless update” measures to be effective in Fedora Linux 42. * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == * https://gimp.org/ * https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap * https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline == Release Notes == This release of Fedora Linux ships version 3 of the GNU Image Manipulation Program, with many new features and improved user experience. The package is called gimp3, the old version will still be available under the old name, gimp for users who need it for existing projects. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: GIMP Version 3 (self-contained)
improvements in the handling of input devices such as tablets and when used on high resolution displays. == Dependencies == A number of third party GIMP plugins are available to be installed as packages on Fedora Linux. With the continued availability of version 2.x of GIMP, these packages can still be installed and used with the old version. Whether or not these plugins will support the new GIMP version very much depends on the particular plugin, or rather the upstream projects for these plugins. Therefore it’s a bit early to make plans for packaging plugins available for both GIMP versions at this point. == Contingency Plan == * Contingency mechanism: Not ship the package, bump “seamless update” measures to be effective in Fedora Linux 42. * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == * https://gimp.org/ * https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap * https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline == Release Notes == This release of Fedora Linux ships version 3 of the GNU Image Manipulation Program, with many new features and improved user experience. The package is called gimp3, the old version will still be available under the old name, gimp for users who need it for existing projects. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_Plasma_Mobile Discussion Thread - https://discussion.fedoraproject.org/t/f411-change-proposal-kde-plasma-mobile-spin-and-fedora-kinoite-mobile-self-contained/120251 This is a proposed Change for Fedora Linux. 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 Fedora Spin using KDE Plasma Mobile and a Fedora Kinoite Mobile Bootable Container image. == Owner == * SIG: [[SIGs/KDE|KDE SIG]] * Name: [[User:tdawson| Troy Dawson]] * Email: tdaw...@redhat.com * Name: [[User:ngompa| Neal Gompa]] * Email: ngomp...@gmail.com * Name: [[User:Siosm| Timothée Ravier]] * Email: trav...@redhat.com == Detailed Description == Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile brings its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. We propose to create a Fedora KDE Plasma Mobile spin and the corresponding Atomic variant: Kinoite Mobile (only Bootable Container images, no classic ostree variant). == Feedback == Feedback has been positive thus far. As KDE Plasma Mobile has taken shape in Fedora, more and more people have asked for a spin so it is easier to setup on their machines. == Benefit to Fedora == KDE Plasma Mobile will give Fedora a strong showing in the mobile market. Many other distributions that targeted the mobile market have concentrated on cellphones. We believe that by targeting all touchscreen devices, we can bring more users into the Fedora community. == Scope == * Proposal owners: ** '''Spin configuration:''' ** '''Work with RelEng to build:''' ** '''Test Day coordination:''' * Other developers: N/A * Release engineering: Will submit issue once this is approved. [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Will submit issue once this is approved. * Alignment with the Fedora Strategy: Yes. == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Proper Fedora KDE Plasma Mobile Spin: 1. Boot the Fedora KDE Plasma Mobile Spin ISO image either on bare-metal or in a virtual machine (V.M.). 2. Confirm successful boot into a configured KDE Plasma Mobile environment with basic packages available. 3. Launch Anaconda installer. 4. Confirm no major issues with windows and display. The installed system uses sddm as the login manager and comes preinstalled with KDE Plasma Mobile as the default desktop environment and with default applications present for most use cases. Repeat with Kinoite Mobile. == User Experience == Users are able to consume KDE Plasma Mobile from https://spins.fedoraproject.org instead of installing another desktop and then manually installing KDE Plasma Mobile after the initial installation. Similarly for Kinoite Mobile. The Spin should remain as minimal as possible and only include small supplements on top of making the default configuration workable. We should make the user experience as easy and simple as possible without defining too many opinions. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Push this off to the next Fedora release * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == This release brings the Fedora KDE Plasma Mobile Spin and its corresponding Atomic variant: Kinoite Mobile. Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile and Kinoite Mobile bring its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https
F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_Plasma_Mobile Discussion Thread - https://discussion.fedoraproject.org/t/f411-change-proposal-kde-plasma-mobile-spin-and-fedora-kinoite-mobile-self-contained/120251 This is a proposed Change for Fedora Linux. 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 Fedora Spin using KDE Plasma Mobile and a Fedora Kinoite Mobile Bootable Container image. == Owner == * SIG: [[SIGs/KDE|KDE SIG]] * Name: [[User:tdawson| Troy Dawson]] * Email: tdaw...@redhat.com * Name: [[User:ngompa| Neal Gompa]] * Email: ngomp...@gmail.com * Name: [[User:Siosm| Timothée Ravier]] * Email: trav...@redhat.com == Detailed Description == Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile brings its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. We propose to create a Fedora KDE Plasma Mobile spin and the corresponding Atomic variant: Kinoite Mobile (only Bootable Container images, no classic ostree variant). == Feedback == Feedback has been positive thus far. As KDE Plasma Mobile has taken shape in Fedora, more and more people have asked for a spin so it is easier to setup on their machines. == Benefit to Fedora == KDE Plasma Mobile will give Fedora a strong showing in the mobile market. Many other distributions that targeted the mobile market have concentrated on cellphones. We believe that by targeting all touchscreen devices, we can bring more users into the Fedora community. == Scope == * Proposal owners: ** '''Spin configuration:''' ** '''Work with RelEng to build:''' ** '''Test Day coordination:''' * Other developers: N/A * Release engineering: Will submit issue once this is approved. [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Will submit issue once this is approved. * Alignment with the Fedora Strategy: Yes. == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Proper Fedora KDE Plasma Mobile Spin: 1. Boot the Fedora KDE Plasma Mobile Spin ISO image either on bare-metal or in a virtual machine (V.M.). 2. Confirm successful boot into a configured KDE Plasma Mobile environment with basic packages available. 3. Launch Anaconda installer. 4. Confirm no major issues with windows and display. The installed system uses sddm as the login manager and comes preinstalled with KDE Plasma Mobile as the default desktop environment and with default applications present for most use cases. Repeat with Kinoite Mobile. == User Experience == Users are able to consume KDE Plasma Mobile from https://spins.fedoraproject.org instead of installing another desktop and then manually installing KDE Plasma Mobile after the initial installation. Similarly for Kinoite Mobile. The Spin should remain as minimal as possible and only include small supplements on top of making the default configuration workable. We should make the user experience as easy and simple as possible without defining too many opinions. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Push this off to the next Fedora release * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == This release brings the Fedora KDE Plasma Mobile Spin and its corresponding Atomic variant: Kinoite Mobile. Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile and Kinoite Mobile bring its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Mark Fedora KDE AArch64 as Release-Blocking (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-aarch64-as-release-blocking-system-wide/120250 This is a proposed Change for Fedora Linux. 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 == Mark Fedora KDE AArch64 deliverables as release-blocking, leveraging the same criteria for Fedora on AArch64 and Fedora KDE on x86_64. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngomp...@gmail.com == Detailed Description == The Fedora KDE SIG already considers Fedora KDE on AArch64 at the same level of importance as Fedora KDE on x86_64, and the SIG wants the Fedora KDE AArch64 deliverables (such as the disk images and ISOs) to be release-blocking alongside existing Fedora KDE x86_64 deliverables. == Feedback == == Benefit to Fedora == This allows the Fedora KDE SIG to reinforce its commitment to the highest quality KDE Plasma experience on Fedora possible on AArch64 like on x86_64, and it lets Fedora better support the larger ecosystem around Fedora leveraging KDE Plasma (of one notable member being the Fedora Asahi Remix). == Scope == * Proposal owners: Update pungi-fedora to mark AArch64 artifacts as release blocking ([https://pagure.io/pungi-fedora/pull-request/1290 pagureio#pungi-fedora#1290]) * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/12165 #12165] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This aligns with expanding and improving Fedora's connections to the larger ecosystem by supporting upstream KDE with our expertise on AArch64 and downstream distributions like the Fedora Asahi Remix using Fedora KDE on AArch64. == Upgrade/compatibility impact == This has no impact on users. == How To Test == Fedora KDE can be tested on AArch64 the same way Fedora Workstation is: * Fedora KDE AArch64 ISO on either QEMU/KVM or a device with UEFI CD boot such as [https://github.com/pftf the Raspberry Pi using UEFI firmware] * Fedora KDE AArch64 raw disk image on existing supported AArch64 devices == User Experience == This does not change anything for the user experience. == Dependencies == There are no extra dependencies. == Contingency Plan == * Contingency mechanism: Revert release-blocking status for Fedora KDE on AArch64 * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == There is no user-facing documentation to update. Fedora QA documentation on release-blocking artifacts will note Fedora KDE AArch64 artifacts as release-blocking. == Release Notes == Not applicable as this is not a user-facing Change. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Mark Fedora KDE AArch64 as Release-Blocking (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-aarch64-as-release-blocking-system-wide/120250 This is a proposed Change for Fedora Linux. 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 == Mark Fedora KDE AArch64 deliverables as release-blocking, leveraging the same criteria for Fedora on AArch64 and Fedora KDE on x86_64. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngomp...@gmail.com == Detailed Description == The Fedora KDE SIG already considers Fedora KDE on AArch64 at the same level of importance as Fedora KDE on x86_64, and the SIG wants the Fedora KDE AArch64 deliverables (such as the disk images and ISOs) to be release-blocking alongside existing Fedora KDE x86_64 deliverables. == Feedback == == Benefit to Fedora == This allows the Fedora KDE SIG to reinforce its commitment to the highest quality KDE Plasma experience on Fedora possible on AArch64 like on x86_64, and it lets Fedora better support the larger ecosystem around Fedora leveraging KDE Plasma (of one notable member being the Fedora Asahi Remix). == Scope == * Proposal owners: Update pungi-fedora to mark AArch64 artifacts as release blocking ([https://pagure.io/pungi-fedora/pull-request/1290 pagureio#pungi-fedora#1290]) * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/12165 #12165] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This aligns with expanding and improving Fedora's connections to the larger ecosystem by supporting upstream KDE with our expertise on AArch64 and downstream distributions like the Fedora Asahi Remix using Fedora KDE on AArch64. == Upgrade/compatibility impact == This has no impact on users. == How To Test == Fedora KDE can be tested on AArch64 the same way Fedora Workstation is: * Fedora KDE AArch64 ISO on either QEMU/KVM or a device with UEFI CD boot such as [https://github.com/pftf the Raspberry Pi using UEFI firmware] * Fedora KDE AArch64 raw disk image on existing supported AArch64 devices == User Experience == This does not change anything for the user experience. == Dependencies == There are no extra dependencies. == Contingency Plan == * Contingency mechanism: Revert release-blocking status for Fedora KDE on AArch64 * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == There is no user-facing documentation to update. Fedora QA documentation on release-blocking artifacts will note Fedora KDE AArch64 artifacts as release-blocking. == Release Notes == Not applicable as this is not a user-facing Change. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
. == User Experience == Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1. Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases. == Dependencies == All reverse dependencies of openssl are potentially affected. == Contingency Plan == * Contingency mechanism: the change is reverted * Contingency deadline: Fedora 41 Beta Freeze * Blocks release? Yes Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild. == Documentation == [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly. == Release Notes == We'll need something to the tune of: OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Missing link for discussion thread https://discussion.fedoraproject.org/t/f41-change-proposal-remove-ifcfg-support-in-networkmanager-system-wide/119455 -- ___ 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
F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
. == User Experience == Some less-than-common use-cases will break. (One example from Fedora 37 test days was interoperability with old Apple devices). The affected users will need to either explicitly opt into the previous, less secure system configuration, or wait until the affected packages are updated to move away from SHA-1. Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (`update-crypto-policies --set FEDORA40`) or per-process (`runcp FEDORA40 command args`, requires a [https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras copr-packaged] tool). FEDORA40 policy will be maintained for several more Fedora releases. == Dependencies == All reverse dependencies of openssl are potentially affected. == Contingency Plan == * Contingency mechanism: the change is reverted * Contingency deadline: Fedora 41 Beta Freeze * Blocks release? Yes Note: with the change being a flip of a switch at heart, there's not much room for creativity in not completing it. Reverting is would be a straightforward ordeal, and would not require a mass rebuild. == Documentation == [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes. Fedora packaging guidelines should be modified accordingly. == Release Notes == We'll need something to the tune of: OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default. Affected users can opt out of the change at the expense of lowering the system's security. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Missing link for discussion thread https://discussion.fedoraproject.org/t/f41-change-proposal-remove-ifcfg-support-in-networkmanager-system-wide/119455 -- ___ 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
F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/RemoveIfcfgSupportInNM Discussion Thread - This is a proposed Change for Fedora Linux. 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 == Remove support for connection profiles stored in ifcfg format in NetworkManager. == Owner == * Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando Fernández Mancera]], [[User:Till| Till Maas]] * Email: , , == Detailed Description == NetworkManager supports different formats to persist connection profiles to disk. The two formats currently in use in Fedora are ''keyfile'' and ''ifcfg''. [https://networkmanager.dev/docs/api/latest/nm-settings-keyfile.html Keyfile] is the native and preferred format. It supports all the connection types and all the features. [https://networkmanager.dev/docs/api/latest/nm-settings-ifcfg-rh.html Ifcfg] is compatible with the old network-scripts. It only supports a limited set of connection types, and it is [https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html deprecated] upstream. This change proposal aims at removing NetworkManager support for ifcfg files in Fedora. This is the last step of a process started several releases ago: * in Fedora 33, the default connection format was changed from ifcfg to keyfile; * in Fedora 36, the plugin that handles ifcfg files was shipped in a separate package and was not included in new installations; * since Fedora 39, the NetworkManager daemon automatically migrates ifcfg files to the keyfile format. == Benefit to Fedora == Since ifcfg support is going to be removed upstream, it must also be removed in Fedora. Keyfile is a valid and better replacement. == Scope == * Proposal owners: drop the following packages: ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin ** `NetworkManager-dispatcher-routing-rules` containing a dispatcher script to apply routing rules in ifcfg format ** `NetworkManager-initscripts-updown` containing alternative ifup/ifdown scripts compatible with initscripts commands, using NetworkManager. * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == At this point no users should have connection profiles stored in ifcfg format, as NetworkManager is automatically migrating them to keyfile since Fedora 39. According to [https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline documentation] , system upgrades are supported only over 2 releases at most (e.g. from 38 to 40); therefore, users upgrading to Fedora 41 must come from Fedora 39 or 40, which have the migration enabled. If some users disabled the migration, they might still have ifcfg files in `/etc/sysconfig/network-scripts`. A “readme-ifcfg-rh.txt” file there warns users that the format is deprecated and is going to be removed. == How To Test == * Try to install the NetworkManager-initscripts-ifcfg-rh package * The package is not available. == User Experience == See the “Upgrade/compatibility impact” section. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? no == Documentation == No documentation change required. == Release Notes == The change needs to be mentioned in the Release Notes. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/RemoveIfcfgSupportInNM Discussion Thread - This is a proposed Change for Fedora Linux. 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 == Remove support for connection profiles stored in ifcfg format in NetworkManager. == Owner == * Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando Fernández Mancera]], [[User:Till| Till Maas]] * Email: , , == Detailed Description == NetworkManager supports different formats to persist connection profiles to disk. The two formats currently in use in Fedora are ''keyfile'' and ''ifcfg''. [https://networkmanager.dev/docs/api/latest/nm-settings-keyfile.html Keyfile] is the native and preferred format. It supports all the connection types and all the features. [https://networkmanager.dev/docs/api/latest/nm-settings-ifcfg-rh.html Ifcfg] is compatible with the old network-scripts. It only supports a limited set of connection types, and it is [https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html deprecated] upstream. This change proposal aims at removing NetworkManager support for ifcfg files in Fedora. This is the last step of a process started several releases ago: * in Fedora 33, the default connection format was changed from ifcfg to keyfile; * in Fedora 36, the plugin that handles ifcfg files was shipped in a separate package and was not included in new installations; * since Fedora 39, the NetworkManager daemon automatically migrates ifcfg files to the keyfile format. == Benefit to Fedora == Since ifcfg support is going to be removed upstream, it must also be removed in Fedora. Keyfile is a valid and better replacement. == Scope == * Proposal owners: drop the following packages: ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin ** `NetworkManager-dispatcher-routing-rules` containing a dispatcher script to apply routing rules in ifcfg format ** `NetworkManager-initscripts-updown` containing alternative ifup/ifdown scripts compatible with initscripts commands, using NetworkManager. * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == At this point no users should have connection profiles stored in ifcfg format, as NetworkManager is automatically migrating them to keyfile since Fedora 39. According to [https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline documentation] , system upgrades are supported only over 2 releases at most (e.g. from 38 to 40); therefore, users upgrading to Fedora 41 must come from Fedora 39 or 40, which have the migration enabled. If some users disabled the migration, they might still have ifcfg files in `/etc/sysconfig/network-scripts`. A “readme-ifcfg-rh.txt” file there warns users that the format is deprecated and is going to be removed. == How To Test == * Try to install the NetworkManager-initscripts-ifcfg-rh package * The package is not available. == User Experience == See the “Upgrade/compatibility impact” section. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? no == Documentation == No documentation change required. == Release Notes == The change needs to be mentioned in the Release Notes. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Separate package for dtrace from systemtap-sdt-devel (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-separate-package-for-dtrace-from-systemtap-sdt-devel-self-contained/119451
This is a proposed Change for Fedora Linux.
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 /usr/bin/dtrace from
systemtap-sdt-devel ({{package|systemtap}}) into a
separate package to optimize many buildroots by removing unnecessary
Python dependencies.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbal...@redhat.com
== Detailed Description ==
The package systemtap-sdt-devel currently contains header
files and the script /usr/bin/dtrace, which is written in
Python and uses pycparser. This results in unnecessary Python and
pycparser installations for many packages that do not need the script
(and many times Python at all), as they only require the header files.
Moreover, some important packages (like perl-devel) require
systemtap-sdt-devel which means hundreds of Perl packages have Python
installed in their buildroots because of the single script they don't
need.
The idea was tested on all packages build-requiring perl-devel but
don't build-requiring python-devel directly - 520 in total. And from
that number:
* 7 failed to build for unrelated reasons
* 3 packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
* 81 packages have python3-libs but not python3-devel (different
reasons than systemtap-sdt-devel)
and finally, the rest - 436 packages - builds fine without the Python
script in systemtap-sdt-devel and therefore without Python at all.
Further testing on packages directly requiring systemtap-sdt-devel
identified the following needing the dtrace script:
* glib2
* sssd
* qemu
* python2.7
* postgresql15
* postgresql16
* perl
* php
* mariadb10.11
* libvirt
Those will depend on a new package to which we move the script.
== Feedback ==
The proposal has been positively received on the
[https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/thread/4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS/#4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS
Fedora devel list].
== Benefit to Fedora ==
By splitting the /usr/bin/dtrace script into a separate
package, we reduce the buildroot size and improve build times for
hundreds of packages that do not require Python.
== Scope ==
* Proposal owners:
# Move the script to a new package systemtap-sdt-dtrace
and update systemtap-sdt-devel to require this new
package for backward compatibility.
# Update affected packages to depend on systemtap-sdt-dtrace.
# Remove the backward-compatible requirement from
systemtap-sdt-devel.
* Other developers: Review and merge proposed changes, and report any bugs.
* 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 the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Package maintainers can proactively prepare their packages after the
first step from the plan above is implemented. Failed builds
identifying packages requiring changes are available in
[https://copr.fedorainfracloud.org/coprs/lbalhar/sdt-devel-no-dtrace/
COPR].
Maintainers can also build and test their packages with the version of
systemtap-sdt-devel from which the script has been removed.
== User Experience ==
Regular distro users shouldn't notice any change.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will revert the change in
{{package|systemtap}}.
* 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 ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https
F41 Change Proposal: Separate package for dtrace from systemtap-sdt-devel (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-separate-package-for-dtrace-from-systemtap-sdt-devel-self-contained/119451
This is a proposed Change for Fedora Linux.
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 /usr/bin/dtrace from
systemtap-sdt-devel ({{package|systemtap}}) into a
separate package to optimize many buildroots by removing unnecessary
Python dependencies.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbal...@redhat.com
== Detailed Description ==
The package systemtap-sdt-devel currently contains header
files and the script /usr/bin/dtrace, which is written in
Python and uses pycparser. This results in unnecessary Python and
pycparser installations for many packages that do not need the script
(and many times Python at all), as they only require the header files.
Moreover, some important packages (like perl-devel) require
systemtap-sdt-devel which means hundreds of Perl packages have Python
installed in their buildroots because of the single script they don't
need.
The idea was tested on all packages build-requiring perl-devel but
don't build-requiring python-devel directly - 520 in total. And from
that number:
* 7 failed to build for unrelated reasons
* 3 packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
* 81 packages have python3-libs but not python3-devel (different
reasons than systemtap-sdt-devel)
and finally, the rest - 436 packages - builds fine without the Python
script in systemtap-sdt-devel and therefore without Python at all.
Further testing on packages directly requiring systemtap-sdt-devel
identified the following needing the dtrace script:
* glib2
* sssd
* qemu
* python2.7
* postgresql15
* postgresql16
* perl
* php
* mariadb10.11
* libvirt
Those will depend on a new package to which we move the script.
== Feedback ==
The proposal has been positively received on the
[https://lists.fedorahosted.org/archives/list/de...@lists.fedoraproject.org/thread/4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS/#4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS
Fedora devel list].
== Benefit to Fedora ==
By splitting the /usr/bin/dtrace script into a separate
package, we reduce the buildroot size and improve build times for
hundreds of packages that do not require Python.
== Scope ==
* Proposal owners:
# Move the script to a new package systemtap-sdt-dtrace
and update systemtap-sdt-devel to require this new
package for backward compatibility.
# Update affected packages to depend on systemtap-sdt-dtrace.
# Remove the backward-compatible requirement from
systemtap-sdt-devel.
* Other developers: Review and merge proposed changes, and report any bugs.
* 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 the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Package maintainers can proactively prepare their packages after the
first step from the plan above is implemented. Failed builds
identifying packages requiring changes are available in
[https://copr.fedorainfracloud.org/coprs/lbalhar/sdt-devel-no-dtrace/
COPR].
Maintainers can also build and test their packages with the version of
systemtap-sdt-devel from which the script has been removed.
== User Experience ==
Regular distro users shouldn't notice any change.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will revert the change in
{{package|systemtap}}.
* 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 ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Wayland-only GNOME Workstation Media (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOMEWorkstationMedia Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-wayland-only-gnome-workstation-media-self-contained/119447 This is a proposed Change for Fedora Linux. 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 == Remove the GNOME X11 packages from the Fedora Workstation media. The packages will remain available in the repositories maintained by the GNOME SIG, but not preinstalled on the media anymore. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngomp...@gmail.com == Detailed Description == As part of the upstream deprecation and effort to remove X11 support from GNOME, Fedora Workstation media will no longer include the GNOME X11 packages. The packages will remain in the repository (maintained by the GNOME SIG/Workstation WG) for users to manually install at this time. == Feedback == == Benefit to Fedora == This aligns us with the effort going on upstream to deprecate and retire the GNOME X11 session. It also partly aligns us with Fedora KDE. Like the Fedora KDE SIG, the Fedora Workstation WG recommends and supports the Wayland platform for graphics. Fedora Workstation has a long history of developing and promoting the Wayland experience for GNOME, and [https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it has been the primary experience for all users (including those with NVIDIA cards) since Fedora Linux 36]. This reaffirms our commitment to the Wayland GNOME experience in furtherance of the goal to provide the highest quality GNOME experience through Fedora Workstation. == Scope == * Proposal owners: Drop the GNOME X11 packages from the GNOME groups in comps and replace them with their Wayland counterparts. Pull request: [https://pagure.io/fedora-comps/pull-request/972 pagureio#fedora-comps#972] * Other developers: N/A (not needed for this Change) * 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 the Fedora Strategy: N/A (not needed for this Change) == Upgrade/compatibility impact == Systems upgrading from older releases of Fedora Workstation will not be impacted, as this only affects new installs. == Early Testing (Optional) == Not applicable to this change. == How To Test == Not applicable to this change, as we're only dropping a non-default experience from the media. == User Experience == Going forward until the X11 session packages are fully dropped, users will need to manually install them from the repository if they need it. == Dependencies == Not applicable for this change. == Contingency Plan == * Contingency mechanism: Revert the comps change * Contingency deadline: Final freeze * Blocks release? Yes. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora Workstation no longer pre-installs the deprecated GNOME X11 session for new installations. Users who wish to add it back can do so by installing the gnome-session-xsession and gnome-classic-session-xsession packages. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Wayland-only GNOME Workstation Media (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOMEWorkstationMedia Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-wayland-only-gnome-workstation-media-self-contained/119447 This is a proposed Change for Fedora Linux. 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 == Remove the GNOME X11 packages from the Fedora Workstation media. The packages will remain available in the repositories maintained by the GNOME SIG, but not preinstalled on the media anymore. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngomp...@gmail.com == Detailed Description == As part of the upstream deprecation and effort to remove X11 support from GNOME, Fedora Workstation media will no longer include the GNOME X11 packages. The packages will remain in the repository (maintained by the GNOME SIG/Workstation WG) for users to manually install at this time. == Feedback == == Benefit to Fedora == This aligns us with the effort going on upstream to deprecate and retire the GNOME X11 session. It also partly aligns us with Fedora KDE. Like the Fedora KDE SIG, the Fedora Workstation WG recommends and supports the Wayland platform for graphics. Fedora Workstation has a long history of developing and promoting the Wayland experience for GNOME, and [https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it has been the primary experience for all users (including those with NVIDIA cards) since Fedora Linux 36]. This reaffirms our commitment to the Wayland GNOME experience in furtherance of the goal to provide the highest quality GNOME experience through Fedora Workstation. == Scope == * Proposal owners: Drop the GNOME X11 packages from the GNOME groups in comps and replace them with their Wayland counterparts. Pull request: [https://pagure.io/fedora-comps/pull-request/972 pagureio#fedora-comps#972] * Other developers: N/A (not needed for this Change) * 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 the Fedora Strategy: N/A (not needed for this Change) == Upgrade/compatibility impact == Systems upgrading from older releases of Fedora Workstation will not be impacted, as this only affects new installs. == Early Testing (Optional) == Not applicable to this change. == How To Test == Not applicable to this change, as we're only dropping a non-default experience from the media. == User Experience == Going forward until the X11 session packages are fully dropped, users will need to manually install them from the repository if they need it. == Dependencies == Not applicable for this change. == Contingency Plan == * Contingency mechanism: Revert the comps change * Contingency deadline: Final freeze * Blocks release? Yes. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora Workstation no longer pre-installs the deprecated GNOME X11 session for new installations. Users who wish to add it back can do so by installing the gnome-session-xsession and gnome-classic-session-xsession packages. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Golang 1.23 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-system-wide/118631
This is a proposed Change for Fedora Linux.
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 of Go (golang package) to the upcoming version 1.23 in Fedora 41.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.23 in Fedora
41. Go 1.23 is expected to be released in
[https://tip.golang.org/doc/go1.23 August 2024]. A mass rebuild of all
of the dependent packages is required.
== Feedback ==
No feedback yet.
There is an
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZQROWTMARIUS45KIQZIUNAA45K3NWLRW/
ongoing conversation] about removing a patch and revert to the
defaults a couple of variables.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features. Therefore, Fedora will be providing a
reliable development platform for the Go language and projects written
in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.23
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 41, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
It doesn't align directly with the current objectives, but it helps
maintain the quality of the project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.23 from rawhide and use it to build your
application(s)/package(s).
# Perform a scratch build against rawhide.
# Your application/package built using golang 1.23 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes.
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed: ~2000.
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.22.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.23
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Golang 1.23 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-system-wide/118631
This is a proposed Change for Fedora Linux.
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 of Go (golang package) to the upcoming version 1.23 in Fedora 41.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.23 in Fedora
41. Go 1.23 is expected to be released in
[https://tip.golang.org/doc/go1.23 August 2024]. A mass rebuild of all
of the dependent packages is required.
== Feedback ==
No feedback yet.
There is an
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZQROWTMARIUS45KIQZIUNAA45K3NWLRW/
ongoing conversation] about removing a patch and revert to the
defaults a couple of variables.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features. Therefore, Fedora will be providing a
reliable development platform for the Go language and projects written
in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.23
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 41, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
It doesn't align directly with the current objectives, but it helps
maintain the quality of the project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.23 from rawhide and use it to build your
application(s)/package(s).
# Perform a scratch build against rawhide.
# Your application/package built using golang 1.23 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes.
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed: ~2000.
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.22.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.23
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Unprivileged updates for Fedora Atomic Desktops (Self-Contained)
; ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
action.id == "org.projectatomic.rpmostree1.cancel" ||
action.id == "org.projectatomic.rpmostree1.cleanup" ||
action.id == "org.projectatomic.rpmostree1.client-management") &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
if ((
action.id == "org.projectatomic.rpmostree1.install-local-packages" ||
action.id == "org.projectatomic.rpmostree1.override" ||
action.id == "org.projectatomic.rpmostree1.deploy" ||
action.id == "org.projectatomic.rpmostree1.rebase" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ) &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.AUTH_ADMIN;
}
});
* Test that normal / unprivileged users can '''only do''' the
following operations '''without a password''':
** Update the system: `rpm-ostree update`
** Refresh the metadata: `rpm-ostree refresh-md`
* Test that admin / privileged users can do the following operations
'''without a password''':
** Install a package from the official Fedora repos: `rpm-ostree install strace`
** Cancel an in-progress transaction: `rpm-ostree cancel`
** Rollback to a previous version: `rpm-ostree rollback`
** Reload the daemon: `rpm-ostree reload`
** Cleanup pending or rollback deployments: `rpm-ostree cleanup`
* Test that admin / privileged users are '''asked a password''' for
the following operations:
** Install a local RPM package: `rpm-ostree install ./foo.rpm`
** Override replace a package: `rpm-ostree override replace vim-x.y.z.rpm`
** Deploy a specific version: `rpm-ostree deploy 40.20240518.1`
** Rebase to any version: `rpm-ostree rebase ...` (try with Kinoite on
Silverblue, etc.)
** Change kernel argments: `rpm-ostree kargs --append=foo=bar`
== User Experience ==
This change should be mostly transparent for users.
If some of the now "password-full" operations were used previously,
they will now ask for a password.
Unprivileged users will be able to update the system.
== Dependencies ==
The rules are shipped as part of the `fedora-release` RPM. There are
no other dependencies.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** We can revert the change to the `fedora-release` package at any time.
** Will be done by the change owners.
* Contingency deadline: Beta freeze or final freeze
* Blocks release? No
== Documentation ==
No additional documentation.
== Release Notes ==
To be written once the change is accepted.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Unprivileged updates for Fedora Atomic Desktops (Self-Contained)
; ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
action.id == "org.projectatomic.rpmostree1.cancel" ||
action.id == "org.projectatomic.rpmostree1.cleanup" ||
action.id == "org.projectatomic.rpmostree1.client-management") &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
if ((
action.id == "org.projectatomic.rpmostree1.install-local-packages" ||
action.id == "org.projectatomic.rpmostree1.override" ||
action.id == "org.projectatomic.rpmostree1.deploy" ||
action.id == "org.projectatomic.rpmostree1.rebase" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ) &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.AUTH_ADMIN;
}
});
* Test that normal / unprivileged users can '''only do''' the
following operations '''without a password''':
** Update the system: `rpm-ostree update`
** Refresh the metadata: `rpm-ostree refresh-md`
* Test that admin / privileged users can do the following operations
'''without a password''':
** Install a package from the official Fedora repos: `rpm-ostree install strace`
** Cancel an in-progress transaction: `rpm-ostree cancel`
** Rollback to a previous version: `rpm-ostree rollback`
** Reload the daemon: `rpm-ostree reload`
** Cleanup pending or rollback deployments: `rpm-ostree cleanup`
* Test that admin / privileged users are '''asked a password''' for
the following operations:
** Install a local RPM package: `rpm-ostree install ./foo.rpm`
** Override replace a package: `rpm-ostree override replace vim-x.y.z.rpm`
** Deploy a specific version: `rpm-ostree deploy 40.20240518.1`
** Rebase to any version: `rpm-ostree rebase ...` (try with Kinoite on
Silverblue, etc.)
** Change kernel argments: `rpm-ostree kargs --append=foo=bar`
== User Experience ==
This change should be mostly transparent for users.
If some of the now "password-full" operations were used previously,
they will now ask for a password.
Unprivileged users will be able to update the system.
== Dependencies ==
The rules are shipped as part of the `fedora-release` RPM. There are
no other dependencies.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** We can revert the change to the `fedora-release` package at any time.
** Will be done by the change owners.
* Contingency deadline: Beta freeze or final freeze
* Blocks release? No
== Documentation ==
No additional documentation.
== Release Notes ==
To be written once the change is accepted.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
41 Change Proposal: Make Tuned the Default Power Profile Management Daemon (System-Wide)
setting should be done through the firmware level. If tuned can replace power-profiles-daemon, they can imagine they can develop the profile in a much more flexible manner. '''The previous discussions''' https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-power-profiles-daemon-self-contained/94995 == Benefit to Fedora == Benefits the user. The user would have more options to tune their system. Benefits the maintainer. Integrate similar software into one software to reduce the maintenance effort. == Scope == * Proposal owners: ** for GNOME: update gnome-control-center weak dependency on power-profile-daemon to tuned-ppd ** for KDE: update powerdevil weak dependency on power-profile-daemon to tuned-ppd ** for Budgie: update budgie-control-center weak dependency on power-profile-daemon to tuned-ppd * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] < * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Since tuned-ppd provides the ppd APIs and features, there is no impact on other applications. == Early Testing (Optional) == Do you require 'QA Blueprint' support? Y/N == How To Test == Remove power-profiles-daemon. $ sudo dnf remove power-profiles-daemon Install tuned and tuned-ppd through the following command $ sudo dnf install tuned $ sudo dnf install tuned-ppd Run gnome-control-center and switch to the power panel and then select one of the three power profiles. Click the top-right corner of the screen and you can see the “Power Mode” shows the profile name that you selected previously. Run the following command to show the active profile. Since tuned-adm shows the tuned profile name, the profile name mapping can be found in /etc/tuned/ppd.conf. $ tuned-adm active == User Experience == The workstation user can set the power profile through the gnome-control-center. The server users switch the profile through the tuned command line. == Dependencies == tuned is written by Python so it depends on python packages and its 40 packages. == Contingency Plan == * Contingency mechanism: Use the original power-profiles-daemon * Contingency deadline: Before F41 beta freeze. * Blocks release? No, tuned-ppd provides all the power-profiles-daemon APIs otherwise the original power-profile-daemon can be used when the plan blocks the release. == Documentation == I have talked with tuned about this information. https://github.com/redhat-performance/tuned/issues/559 == Release Notes == * https://github.com/redhat-performance/tuned/tree/master/tuned/ppd * https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
41 Change Proposal: Make Tuned the Default Power Profile Management Daemon (System-Wide)
setting should be done through the firmware level. If tuned can replace power-profiles-daemon, they can imagine they can develop the profile in a much more flexible manner. '''The previous discussions''' https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-power-profiles-daemon-self-contained/94995 == Benefit to Fedora == Benefits the user. The user would have more options to tune their system. Benefits the maintainer. Integrate similar software into one software to reduce the maintenance effort. == Scope == * Proposal owners: ** for GNOME: update gnome-control-center weak dependency on power-profile-daemon to tuned-ppd ** for KDE: update powerdevil weak dependency on power-profile-daemon to tuned-ppd ** for Budgie: update budgie-control-center weak dependency on power-profile-daemon to tuned-ppd * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] < * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Since tuned-ppd provides the ppd APIs and features, there is no impact on other applications. == Early Testing (Optional) == Do you require 'QA Blueprint' support? Y/N == How To Test == Remove power-profiles-daemon. $ sudo dnf remove power-profiles-daemon Install tuned and tuned-ppd through the following command $ sudo dnf install tuned $ sudo dnf install tuned-ppd Run gnome-control-center and switch to the power panel and then select one of the three power profiles. Click the top-right corner of the screen and you can see the “Power Mode” shows the profile name that you selected previously. Run the following command to show the active profile. Since tuned-adm shows the tuned profile name, the profile name mapping can be found in /etc/tuned/ppd.conf. $ tuned-adm active == User Experience == The workstation user can set the power profile through the gnome-control-center. The server users switch the profile through the tuned command line. == Dependencies == tuned is written by Python so it depends on python packages and its 40 packages. == Contingency Plan == * Contingency mechanism: Use the original power-profiles-daemon * Contingency deadline: Before F41 beta freeze. * Blocks release? No, tuned-ppd provides all the power-profiles-daemon APIs otherwise the original power-profile-daemon can be used when the plan blocks the release. == Documentation == I have talked with tuned about this information. https://github.com/redhat-performance/tuned/issues/559 == Release Notes == * https://github.com/redhat-performance/tuned/tree/master/tuned/ppd * https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Removing network-scripts package (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/NetworkScriptsRemoval Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-removing-network-scripts-package-system-wide/118553 This is a proposed Change for Fedora Linux. 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 == network-scripts package will be removed in Fedora 41. By removing the package, we also remove support for legacy ifup/ifdown network scripts that have been deprecated since 2018. == Owner == * Name: [[User:jamacku| Jan Macku]] * Name: [[User:lnykryn| Lukáš Nykrýn]] * Email: [mailto:jama...@redhat.com jama...@redhat.com] * Email: [mailto:lnyk...@redhat.com lnyk...@redhat.com] == Detailed Description == network-scripts will be removed in Fedora 41. It provides legacy ifup/ifdown scripts as well as network.service. The network-scripts were '''deprecated in 2018''', and since then, upstream has provided only limited support. The main reason for removing network-scripts is that ISC dhcp has not been maintained upstream since the end of 2022. There is [https://fedoraproject.org/wiki/Changes/dhclient_deprecation plan to remove it upcoming Fedora release]. Network scripts heavily depend on the DHCP client, and since Network Scripts are no longer developed, there is no chance of updating them to use an alternative client. == Feedback == == Benefit to Fedora == We don't deliver software that has been deprecated for many years, unmaintained upstream, and for which we don't have resources to maintain downstream. Additionally, it simplifies networking tasks for users and administrators because NetworkManager will be used more uniformly across Fedora environments. == Scope == * Proposal owners: Removing of network-scripts rpm package. * Other developers: Make sure that dependency on network-scripts package is removed (see [[Changes/NetworkScriptsRemoval#Dependencies| #Dependencies]]). * 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 (not needed for this Change) == Upgrade/compatibility impact == ifup/ifdown command are no longer available. Use nmcli connection up/down or networkctl up/down instead. Old ifcfg network configuration should still work thanks to NetworkManager-initscripts-ifcfg-rh package. No migration is needed, but it is recommended to migrate from ifcfg to keyfiles configuration. You can use one of the following articles on how to migrate: * https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/ * https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configuration == How To Test == Networking should work as before the removal of network-scripts package. == User Experience == == Dependencies == RPM packages that depends in some form on network-scripts: * libteam - https://bugzilla.redhat.com/show_bug.cgi?id=2262986 * NetworkManager - https://bugzilla.redhat.com/show_bug.cgi?id=2275295 * openvswitch - https://bugzilla.redhat.com/show_bug.cgi?id=2262982 * ppp - https://bugzilla.redhat.com/show_bug.cgi?id=2262981 Note that this will also affect all users with local custom network-scripts that require functionality from network-scripts package. == Contingency Plan == * Contingency mechanism: Since [https://fedoraproject.org/wiki/Changes/dhclient_deprecation dhcp client is no longer maintained] and is going to be deprecated in Fedora, there is currently no contingency mechanism. * Contingency deadline: beta freeze * Blocks release: No == Documentation == * Upstream Deprecation notice - https://github.com/fedora-sysv/initscripts/commit/b748244cf9905696baf1bc16e0432f85093414c2 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives
F41 Change Proposal: Removing network-scripts package (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/NetworkScriptsRemoval Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-removing-network-scripts-package-system-wide/118553 This is a proposed Change for Fedora Linux. 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 == network-scripts package will be removed in Fedora 41. By removing the package, we also remove support for legacy ifup/ifdown network scripts that have been deprecated since 2018. == Owner == * Name: [[User:jamacku| Jan Macku]] * Name: [[User:lnykryn| Lukáš Nykrýn]] * Email: [mailto:jama...@redhat.com jama...@redhat.com] * Email: [mailto:lnyk...@redhat.com lnyk...@redhat.com] == Detailed Description == network-scripts will be removed in Fedora 41. It provides legacy ifup/ifdown scripts as well as network.service. The network-scripts were '''deprecated in 2018''', and since then, upstream has provided only limited support. The main reason for removing network-scripts is that ISC dhcp has not been maintained upstream since the end of 2022. There is [https://fedoraproject.org/wiki/Changes/dhclient_deprecation plan to remove it upcoming Fedora release]. Network scripts heavily depend on the DHCP client, and since Network Scripts are no longer developed, there is no chance of updating them to use an alternative client. == Feedback == == Benefit to Fedora == We don't deliver software that has been deprecated for many years, unmaintained upstream, and for which we don't have resources to maintain downstream. Additionally, it simplifies networking tasks for users and administrators because NetworkManager will be used more uniformly across Fedora environments. == Scope == * Proposal owners: Removing of network-scripts rpm package. * Other developers: Make sure that dependency on network-scripts package is removed (see [[Changes/NetworkScriptsRemoval#Dependencies| #Dependencies]]). * 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 (not needed for this Change) == Upgrade/compatibility impact == ifup/ifdown command are no longer available. Use nmcli connection up/down or networkctl up/down instead. Old ifcfg network configuration should still work thanks to NetworkManager-initscripts-ifcfg-rh package. No migration is needed, but it is recommended to migrate from ifcfg to keyfiles configuration. You can use one of the following articles on how to migrate: * https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/ * https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configuration == How To Test == Networking should work as before the removal of network-scripts package. == User Experience == == Dependencies == RPM packages that depends in some form on network-scripts: * libteam - https://bugzilla.redhat.com/show_bug.cgi?id=2262986 * NetworkManager - https://bugzilla.redhat.com/show_bug.cgi?id=2275295 * openvswitch - https://bugzilla.redhat.com/show_bug.cgi?id=2262982 * ppp - https://bugzilla.redhat.com/show_bug.cgi?id=2262981 Note that this will also affect all users with local custom network-scripts that require functionality from network-scripts package. == Contingency Plan == * Contingency mechanism: Since [https://fedoraproject.org/wiki/Changes/dhclient_deprecation dhcp client is no longer maintained] and is going to be deprecated in Fedora, there is currently no contingency mechanism. * Contingency deadline: beta freeze * Blocks release: No == Documentation == * Upstream Deprecation notice - https://github.com/fedora-sysv/initscripts/commit/b748244cf9905696baf1bc16e0432f85093414c2 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: LLVM 19 (System-Wide)
ct 1: Fedora f41 Final Freeze.' == Feedback == == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build and test early release candidates of LLVM 19 in COPR. * Other developers: ** Fix build issues found with LLVM-19 or switch their package to use the llvm18 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-19. There should be around 6-8 weeks between when -rc1 lands in the koji side-tag and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-19 update. * Release engineering: [https://pagure.io/releng/issue/12118] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This change should not impact upgrades. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 19. == User Experience == == Dependencies == Packages that depend on one of the llvm packages will need to be updated to work with LLVM19 or will need to switch to using one of the llvm18 compat packages. == Contingency Plan == If there are major problems with LLVM 19, the compatibility package provide a way for other packages to continue using LLVM 18. * Contingency deadline:Final Freeze * Blocks release? No (not a System Wide Change) == Documentation == LLVM sub-projects in Fedora have been updated to version 19: * llvm (now includes clang, lld, compiler-rt, libomp) * lldb * llvm-test-suite * libcxx * python-lit * flang * mlir * polly * libclc * llvm-bolt == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: LLVM 19 (System-Wide)
ct 1: Fedora f41 Final Freeze.' == Feedback == == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build and test early release candidates of LLVM 19 in COPR. * Other developers: ** Fix build issues found with LLVM-19 or switch their package to use the llvm18 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-19. There should be around 6-8 weeks between when -rc1 lands in the koji side-tag and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-19 update. * Release engineering: [https://pagure.io/releng/issue/12118] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This change should not impact upgrades. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 19. == User Experience == == Dependencies == Packages that depend on one of the llvm packages will need to be updated to work with LLVM19 or will need to switch to using one of the llvm18 compat packages. == Contingency Plan == If there are major problems with LLVM 19, the compatibility package provide a way for other packages to continue using LLVM 18. * Contingency deadline:Final Freeze * Blocks release? No (not a System Wide Change) == Documentation == LLVM sub-projects in Fedora have been updated to version 19: * llvm (now includes clang, lld, compiler-rt, libomp) * lldb * llvm-test-suite * libcxx * python-lit * flang * mlir * polly * libclc * llvm-bolt == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Anaconda as native Wayland application (System Wide)
the Anaconda which may result in reduction of installed software to the system when installing from Live ISO where ISO content is copied to the installed system (depends on the spin dependencies). * Switching from VNC to RDP allow users to use remote graphical installations which are more secure and have better performance . == Scope == * Proposal owners: The Anaconda team will implement changes required in the Anaconda project. More specifically: ** Switch Anaconda code to start Wayland environment on boot.iso instead of X11 ** Change keyboard switching logic to use systemd-localed DBus instead of libXklavier ** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD) * Other developers: Fedora SIG owners needs to add support for their environment to listen and use systemd-localed DBus API to reflect current state of the DE/WM or they won’t have support of keyboard layout switching in Anaconda. * Release engineering: [https://pagure.io/releng/issue/12138 #12138] * Policies and guidelines: Yes should be done after the implementation (https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-remote should switch to RDP) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This will impact only Fedora installations so no compatibility or upgrade issues. == Early Testing (Optional) == We will reach Fedora QE to coordinate testing approach. == How To Test == # Download any installation media # Run the installation # Look for breakages during the installation Testing should be especially focused on: * Changing resolution with ''inst.resolution'' kernel boot option * Test new RDP solution (API will be clarified) ** Password can be set to the RDP ** Username can be set to the RDP * Test keyboard layout switching works correctly ** On Live media, Anaconda should react on keyboard layout change in the DE and set that to the installed system ** On Live media, Anaconda should be able to set the keyboard layout changes to the live environment ** In the network installation (boot.iso) Anaconda should correctly reflect keyboard layouts changes so text in the Anaconda is written by the correct layout ** Check if specific keyboard layouts are configured and installed as expected == User Experience == The only visible change to a user should be: * Remote graphical installations will use RDP instead of VNC. * Anaconda will be able to control keyboard layouts in the Wayland environment on Live ISOs. This will improve user experience when installing Fedora Workstation, Fedora KDE, Fedora Sway and other Wayland based environments. == Dependencies == No dependencies of this package related to this change. == Contingency Plan == * Contingency mechanism: Postpone this change to the next Fedora release. Revert landed changes in Anaconda if required. * Contingency deadline: 100% code completion deadline * Blocks release? No == Documentation == No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10: * https://github.com/rhinstaller/anaconda/pull/5463 * https://github.com/rhinstaller/anaconda/pull/5470 * https://github.com/rhinstaller/anaconda/pull/5485 * https://github.com/rhinstaller/anaconda/pull/5498 == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Anaconda as native Wayland application (System Wide)
the Anaconda which may result in reduction of installed software to the system when installing from Live ISO where ISO content is copied to the installed system (depends on the spin dependencies). * Switching from VNC to RDP allow users to use remote graphical installations which are more secure and have better performance . == Scope == * Proposal owners: The Anaconda team will implement changes required in the Anaconda project. More specifically: ** Switch Anaconda code to start Wayland environment on boot.iso instead of X11 ** Change keyboard switching logic to use systemd-localed DBus instead of libXklavier ** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD) * Other developers: Fedora SIG owners needs to add support for their environment to listen and use systemd-localed DBus API to reflect current state of the DE/WM or they won’t have support of keyboard layout switching in Anaconda. * Release engineering: [https://pagure.io/releng/issue/12138 #12138] * Policies and guidelines: Yes should be done after the implementation (https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-remote should switch to RDP) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This will impact only Fedora installations so no compatibility or upgrade issues. == Early Testing (Optional) == We will reach Fedora QE to coordinate testing approach. == How To Test == # Download any installation media # Run the installation # Look for breakages during the installation Testing should be especially focused on: * Changing resolution with ''inst.resolution'' kernel boot option * Test new RDP solution (API will be clarified) ** Password can be set to the RDP ** Username can be set to the RDP * Test keyboard layout switching works correctly ** On Live media, Anaconda should react on keyboard layout change in the DE and set that to the installed system ** On Live media, Anaconda should be able to set the keyboard layout changes to the live environment ** In the network installation (boot.iso) Anaconda should correctly reflect keyboard layouts changes so text in the Anaconda is written by the correct layout ** Check if specific keyboard layouts are configured and installed as expected == User Experience == The only visible change to a user should be: * Remote graphical installations will use RDP instead of VNC. * Anaconda will be able to control keyboard layouts in the Wayland environment on Live ISOs. This will improve user experience when installing Fedora Workstation, Fedora KDE, Fedora Sway and other Wayland based environments. == Dependencies == No dependencies of this package related to this change. == Contingency Plan == * Contingency mechanism: Postpone this change to the next Fedora release. Revert landed changes in Anaconda if required. * Contingency deadline: 100% code completion deadline * Blocks release? No == Documentation == No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10: * https://github.com/rhinstaller/anaconda/pull/5463 * https://github.com/rhinstaller/anaconda/pull/5470 * https://github.com/rhinstaller/anaconda/pull/5485 * https://github.com/rhinstaller/anaconda/pull/5498 == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Release Retrospective Survey - Closes 7th June 2024
Hi all, We are moving swiftly in the F41 release cycle already, so I wanted to get a survey out to you to reflect on and share feedback for the F40 release cycle. I'm very interested to hear your thoughts on anything that can be tweaked/changed/added to improve the release cycle, and what aspects are working really well too. The survey can be found here https://fedoraproject.limequery.com/857364?lang=en , its live now and will remain open until Friday June 7th. Please take some time to share your feedback and thank you in advance for your insights! Kindest regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal: IBus Chewing For Traditional Chinese (Taiwan) Desktop by Default (self contained)
"繁體中文(台灣)" as system locale. Make sure ibus-chewing is usable during system setup. For existing installation: dnf install ibus-chewing and add Chewing as input source from Gnome or KDE settings. i18n test day template should be updated to test ibus-chewing https://fedoraproject.org/wiki/Test_Day:2024-03-05_I18N_Test_Day using this ibus-chewing test case https://fedoraproject.org/wiki/QA:Chewing === For early adopters === For anyone wanting to try: * Rawhide has ibus-chewing 2.0.0 * https://copr.fedorainfracloud.org/coprs/kanru/libchewing-git/ has the upcoming libchewing 0.8 release and future unreleased ibus-chewing and libchewing versions. == User Experience == Newly installed Fedora will use a working and actively maintained input method for zh_TW users. Chewing provides features similar to other IMs you can find on other non-free OSs that zh_TW users are used to. It's available on multiple platforms including Android ports which allows users to reuse their user dictionary or habits on other OSs. == 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 == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: IBus Chewing For Traditional Chinese (Taiwan) Desktop by Default (self contained)
"繁體中文(台灣)" as system locale. Make sure ibus-chewing is usable during system setup. For existing installation: dnf install ibus-chewing and add Chewing as input source from Gnome or KDE settings. i18n test day template should be updated to test ibus-chewing https://fedoraproject.org/wiki/Test_Day:2024-03-05_I18N_Test_Day using this ibus-chewing test case https://fedoraproject.org/wiki/QA:Chewing === For early adopters === For anyone wanting to try: * Rawhide has ibus-chewing 2.0.0 * https://copr.fedorainfracloud.org/coprs/kanru/libchewing-git/ has the upcoming libchewing 0.8 release and future unreleased ibus-chewing and libchewing versions. == User Experience == Newly installed Fedora will use a working and actively maintained input method for zh_TW users. Chewing provides features similar to other IMs you can find on other non-free OSs that zh_TW users are used to. It's available on multiple platforms including Android ports which allows users to reuse their user dictionary or habits on other OSs. == 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 == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: DNF and bootc in Image Mode Fedora variants (system wide)
a package using dnf: `RUN dnf install ` == User Experience == Users of image-based Fedora variants will be able to use the `dnf` command on Container builds and unlocked systems. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Continue to ship without DNF in some or all image-based/ostree variants. * Contingency deadline: Beta freeze. * Blocks release? No == Documentation == * https://dnf5.readthedocs.io/en/latest/ * https://containers.github.io/bootc/ == Release Notes == To be written. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: DNF and bootc in Image Mode Fedora variants (system wide)
a package using dnf: `RUN dnf install ` == User Experience == Users of image-based Fedora variants will be able to use the `dnf` command on Container builds and unlocked systems. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Continue to ship without DNF in some or all image-based/ostree variants. * Contingency deadline: Beta freeze. * Blocks release? No == Documentation == * https://dnf5.readthedocs.io/en/latest/ * https://containers.github.io/bootc/ == Release Notes == To be written. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
I've seen someone in the Red Hat Waterford office be able to claim it no problem so the issue may be individually based as the link is definitely active and claimable. Interested to know too how its working for some nd not others. On Tue, May 21, 2024 at 9:41 AM Sandro wrote: > On 21-05-2024 09:47, Vít Ondruch wrote: > > And it does not work again > > What issue / error are you experiencing? > > It seems to work for others. Looking at the badges front page, the badge > has been awarded as recently as 15 minutes ago. > > -- Sandro > -- > ___ > 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 > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Elections - Voting is now open!
So the wiki page error has been fixed, thanks for letting me know! The badge error, I have created the claim link and my interface says it's valid for 11 more days (set to 31st May). I've also sent it to Kevin who's helping me massively by looking into it on the backend and making sure it's still valid and it seems in working order. I've also added to every active ballot box, the same link, so at this point I am going to hope it will continue to work. For folks who didn't get a badge, can you retry please? And if no success still, just email me directly and I will award you one through that way. Thanks all, Aoife Aoife Moloney Fedora Operations Architect On Mon, May 20, 2024, 6:48 PM Sandro wrote: > On 20-05-2024 19:42, Miro Hrončok wrote: > > On 20. 05. 24 16:37, Aoife Moloney wrote: > >> Hi Folks, > >> > >> After _much_ troubleshooting and some wonderful folks working with me > >> to help resolve the issues that littered the elections today, I am > >> pleased to say all issues have been resolved, or at least I live in > >> hope that they are! :crosses fingers: > >> ... > >> If you have voted in Council and/or Mindshare, and did not have a > >> claim link for your badge, please revisit your vote as the link has > >> been updated and you should be able to access it. If you can't, email > >> me directly and I will manually award this to you (I cant see who > >> voted so I can't do this without knowing who to send it to). > > > > I'm afraid the badge claim link is expired now: > > > > """ > > 410 Gone > > This resource is no longer available. No forwarding address is given. > > > > That invitation is expired. > > """ > > Yes, we are aware. What's not clear is how or why that has happened. > > Either way, the link will be updated again soon. After that we'll know > better. An update will go out once the new link is active. > > -- Sandro > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 End Of Life in one week
The F38 schedule is now updated https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html so this matches the F40 one. Sorry, I completely missed this mis-match, will take more careful note about manually syncing schedules if dates change in one that is linked to another. Thanks @Ben Cotton & @geraldo for your help! On Tue, May 14, 2024 at 10:09 PM Ben Cotton wrote: > On Tue, May 14, 2024 at 3:57 PM Jan Pazdziora > wrote: > > > > Where did the different date of 2024-05-21 come from and where was > > it tracked? > > It comes from the fact that the EOL date for Fedora Linux N is 4 weeks > from the release of the Fedora Linux N+2 final, so it's tracked on the > F40 schedule. Because the schedules are maintained as separate files, > it's easy to forget to update N-2 when the N release date slips, which > is likely what happened here. > > The EOL dates were not on the Fedora Linux N schedules until F38 for > that very reason. > > At any rate, I've opened > https://pagure.io/fedora-pgm/schedule/issue/142 for amoloney to update > the F38 schedule. > > -- > 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 > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Elections - Voting is now open!
Hi Folks, After _much_ troubleshooting and some wonderful folks working with me to help resolve the issues that littered the elections today, I am pleased to say all issues have been resolved, or at least I live in hope that they are! :crosses fingers: If you have voted in either or both FESCo and EPEL elections today, please recast your votes in the new ballot boxes <https://elections.fedoraproject.org/> as the previous ones are corrupted. If you have voted in Council and/or Mindshare, and did not have a claim link for your badge, please revisit your vote as the link has been updated and you should be able to access it. If you can't, email me directly and I will manually award this to you (I cant see who voted so I can't do this without knowing who to send it to). Voting will close at 23:59:59 UTC on 31st May 2024, an extra day has been added and the schedule will be updated accordingly. Thank you again to @Sandro @Miro Hrončok @Michal Konecny @Aurelien Bompard & @Tomas Hrcka for your help, and to everyone for your patience and understanding while I sorted out the chaos that was this election voting opening day! Please let me know if you find any other anomalies and after a short sob, I will fix them :) Kindest regards, Aoife On Mon, May 20, 2024 at 10:53 AM Aoife Moloney wrote: > There seems to be a larger issue at play with the 'claim' link generation > with Badges too, Sandro has kindly opened a ticket for this > https://github.com/fedora-infra/tahrir/issues/495 > > Please be prepared for a restart for EPEL elections and once there is a > claim link for voting available I will update the elections app where you > should be able to claim post-voting and email the lists and topic thread > that its up and running. > > > What a Monday :-/ > > Thank you all for your patience, its very much appreciated. > > Aoife > > On Mon, May 20, 2024 at 10:40 AM Aoife Moloney > wrote: > >> Hi folks, >> >> Apologies for the incorrect badge link. I am working on updating the link >> to the 'Claim' one and will email as soon as it's available. With regards >> to the EPEL election, I will likely need to restart this voting box when >> the issue is resolved. I'm not sure if its FAS related or Wiki related or >> both but have a ticket open with infra to investigate >> https://pagure.io/fedora-infrastructure/issue/11930. >> >> Thanks for your patience all, will update as soon as I have some >> resolution on the issues. >> >> On Mon, May 20, 2024 at 10:02 AM Sandro wrote: >> >>> On 20-05-2024 10:46, Miro Hrončok wrote: >>> > On 20. 05. 24 1:04, Aoife Moloney wrote: >>> >> Hi all, >>> >> >>> >> The F40 elections have now officially opened after a little delay. >>> You >>> >> can find all of the candidate details in the Elections blog post[1]. >>> >> We have open positions in Fedora Council, EPEL Steering Committee, >>> >> Mindshare and Fedora Engineering Steering Committee (FESCo) and the >>> >> voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so >>> >> please do take some time to read the wonderful candidate interviews >>> we >>> >> have received for the various open positions, cast your vote and dont >>> >> forget to claim your Fedora badge too! >>> >> >>> >> >>> >> [1] >>> >> https://communityblog.fedoraproject.org/elections-voting-is-now-open/ >>> >> < >>> https://communityblog.fedoraproject.org/elections-voting-is-now-open/> >>> > >>> > Hello, there is a "None None" candidate to the EPEL Steering Committee. >>> > The link leads to Troy Dawson (tdawson) interview. >>> >>> It seems Troy Dawson has not filled in first and last name in FAS, which >>> is were the information is coming from. >>> >>> -- Sandro >>> >>> -- >>> _______ >>> 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 >>> >> >> >> -- >> >> Aoife Moloney >> >> Fedora Operations Archit
Re: Fedora Elections - Voting is now open!
There seems to be a larger issue at play with the 'claim' link generation with Badges too, Sandro has kindly opened a ticket for this https://github.com/fedora-infra/tahrir/issues/495 Please be prepared for a restart for EPEL elections and once there is a claim link for voting available I will update the elections app where you should be able to claim post-voting and email the lists and topic thread that its up and running. What a Monday :-/ Thank you all for your patience, its very much appreciated. Aoife On Mon, May 20, 2024 at 10:40 AM Aoife Moloney wrote: > Hi folks, > > Apologies for the incorrect badge link. I am working on updating the link > to the 'Claim' one and will email as soon as it's available. With regards > to the EPEL election, I will likely need to restart this voting box when > the issue is resolved. I'm not sure if its FAS related or Wiki related or > both but have a ticket open with infra to investigate > https://pagure.io/fedora-infrastructure/issue/11930. > > Thanks for your patience all, will update as soon as I have some > resolution on the issues. > > On Mon, May 20, 2024 at 10:02 AM Sandro wrote: > >> On 20-05-2024 10:46, Miro Hrončok wrote: >> > On 20. 05. 24 1:04, Aoife Moloney wrote: >> >> Hi all, >> >> >> >> The F40 elections have now officially opened after a little delay. You >> >> can find all of the candidate details in the Elections blog post[1]. >> >> We have open positions in Fedora Council, EPEL Steering Committee, >> >> Mindshare and Fedora Engineering Steering Committee (FESCo) and the >> >> voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so >> >> please do take some time to read the wonderful candidate interviews we >> >> have received for the various open positions, cast your vote and dont >> >> forget to claim your Fedora badge too! >> >> >> >> >> >> [1] >> >> https://communityblog.fedoraproject.org/elections-voting-is-now-open/ >> >> <https://communityblog.fedoraproject.org/elections-voting-is-now-open/ >> > >> > >> > Hello, there is a "None None" candidate to the EPEL Steering Committee. >> > The link leads to Troy Dawson (tdawson) interview. >> >> It seems Troy Dawson has not filled in first and last name in FAS, which >> is were the information is coming from. >> >> -- Sandro >> >> -- >> ___ >> 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 >> > > > -- > > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Elections - Voting is now open!
Hi folks, Apologies for the incorrect badge link. I am working on updating the link to the 'Claim' one and will email as soon as it's available. With regards to the EPEL election, I will likely need to restart this voting box when the issue is resolved. I'm not sure if its FAS related or Wiki related or both but have a ticket open with infra to investigate https://pagure.io/fedora-infrastructure/issue/11930. Thanks for your patience all, will update as soon as I have some resolution on the issues. On Mon, May 20, 2024 at 10:02 AM Sandro wrote: > On 20-05-2024 10:46, Miro Hrončok wrote: > > On 20. 05. 24 1:04, Aoife Moloney wrote: > >> Hi all, > >> > >> The F40 elections have now officially opened after a little delay. You > >> can find all of the candidate details in the Elections blog post[1]. > >> We have open positions in Fedora Council, EPEL Steering Committee, > >> Mindshare and Fedora Engineering Steering Committee (FESCo) and the > >> voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so > >> please do take some time to read the wonderful candidate interviews we > >> have received for the various open positions, cast your vote and dont > >> forget to claim your Fedora badge too! > >> > >> > >> [1] > >> https://communityblog.fedoraproject.org/elections-voting-is-now-open/ > >> <https://communityblog.fedoraproject.org/elections-voting-is-now-open/> > > > > Hello, there is a "None None" candidate to the EPEL Steering Committee. > > The link leads to Troy Dawson (tdawson) interview. > > It seems Troy Dawson has not filled in first and last name in FAS, which > is were the information is coming from. > > -- Sandro > > -- > ___ > 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 > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Elections - Voting is now open!
Hi all, The F40 elections have now officially opened after a little delay. You can find all of the candidate details in the Elections blog post[1]. We have open positions in Fedora Council, EPEL Steering Committee, Mindshare and Fedora Engineering Steering Committee (FESCo) and the voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so please do take some time to read the wonderful candidate interviews we have received for the various open positions, cast your vote and dont forget to claim your Fedora badge too! [1] https://communityblog.fedoraproject.org/elections-voting-is-now-open/ -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)
pecific requirements and needs. == 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 == The Kubernetes section of Fedora Quick Docs (https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/) can be expanded as needed. N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)
pecific requirements and needs. == 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 == The Kubernetes section of Fedora Quick Docs (https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/) can be expanded as needed. N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Elections - Nominations Closing Tomorrow, May 8th!
Hello everyone, A friendly reminder that the Fedora elections nominations for F40 will close tomorrow, May 8th, so it's not too late to nominate yourself or someone you know (with their consent) to be a candidate for one of the following governance bodies of the Fedora Project. Below are the details of each group, with some examples of what elected members can work on during their term and a link to the nominations page for each. - Fedora Council <https://docs.fedoraproject.org/en-US/council/> - two seats - Help shape the Fedora strategy & provide guidance on project policies - Nominations Page <https://fedoraproject.org/wiki/Council/Nominations> - Fedora Mindshare Committee <https://docs.fedoraproject.org/en-US/mindshare-committee/> - one seat - Help with Outreachy, mentorship & ambassador work - Nominations Page <https://fedoraproject.org/wiki/Mindshare/Nominations> - Fedora Engineering Steering Committee <https://docs.fedoraproject.org/en-US/fesco/> (FESCo) - four seats - Provide technical leadership and make technical decisions for Fedora - Nominations Page <https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations> - EPEL Steering Committee <https://docs.fedoraproject.org/en-US/epel/epel-about/> - four seats - Help shape and steer the EPEL overall strategy and provide guidance on EPEL policies - Nominations Page <https://fedoraproject.org/wiki/EPEL/Nominations> The F40 elections schedule <https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html> is available to view for key dates in the cycle, and you can read more about the Fedora elections on the docs page <https://docs.fedoraproject.org/en-US/program_management/elections/>. Any questions, please do reach out. Thanks! Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
Introducing Fedora Change Proposal 'Blueprints' (in association with Fedora QA)
Hi Folks, Sumantro Mukherkjee and I have been working on a concept for the last few weeks on how we could try to bridge the gap between changes for the upcoming release(s) of Fedora being announced and developed, and then tested by QA later in the release cycle. What we have come up with is called a ‘Change Proposal Blueprint’ - a fancy way of saying if a change proposal owner wants some initial testing for their change, Fedora QA will try to support them by helping write and run initial basic tests. This 'blueprint' concept is proposed as an optional step for change proposal owners, with the condition that Fedora QA can provide assistance if available. While QA has shown enthusiasm for the idea, it's important to note that support is likely but not guaranteed. The concept is primarily aimed at System Wide and Mass Rebuild changes. By integrating this option into the change proposal template, proponents hope to enhance proposals, making them clearer and more likely to be accepted by the Fedora community and FESCo. This approach also benefits QA by involving them earlier in changes, particularly those with uncertainties or extensive scopes. By facilitating early feedback and testing, potential issues can be identified sooner, giving developers more time to address them before Beta or Final releases. Additionally, offering a supported method for creating a minimal version of the change for testing enables users to identify potentially hidden breaking dependencies that may only surface during the Rawhide builds.This early detection capability, coupled with the option for preliminary testing, provides developers with more time to address any bugs before reaching the Beta or Final stages. Given the stress typically experienced as release time approaches, providing assistance with early testing at the outset of a change proposal could significantly alleviate pressure on developers and QA teams, making it a worthwhile endeavor to explore. Our change proposal is such a powerful process, so we wanted to leverage this by introducing the option of requesting early testing support by adding it to our change proposal template. You will now see a section in the template called Early Testing (Optional) <https://fedoraproject.org/wiki/Changes/EmptyTemplate#Early_Testing_(Optional)> and instructions on how to reach out to Fedora QA - it's basically send an email to t...@lists.fedoraproject.org with a link to your change proposal and a member of QA (likely Sumantro) will reply to you :) You can also reach out to Sumantro directly too, but preference will be to email the list as this will give you more coverage. Some anti-goals of this idea are not to fully test a change before it goes through the process, nor is it a shortcut to land an un-approved change in Fedora either, but rather an opportunity to bring a quality mindset into the development process much earlier so Fedora can benefit from iterative development backed by quality. We expect changes to be built in a COPR and tested here where possible, and not built in rawhide directly from scratch, as Rawhide is the next Fedora release and we would rather not break that too much :) Sumantro is the lead on this, and I will be supporting him and QA as we work together to see if this helps enhance the project's release cycle. You can reach out to either or both of us if you would like to chat in detail about it, and we would love to hear your feedback on this idea! Kind regards, Aoife & Sumantro -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal: Node.js 22.x by default (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/Nodejs22 Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-node-js-22-x-by-default-system-wide/114740 This is a proposed Change for Fedora Linux. 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 latest release of Node.js to carry a 30-month lifecycle is the 22.x series. As with 20.x, 18.x 16.x, 14.x, 12.x, 10.x and 8.x before it, Fedora 41 will carry 22.x as the default Node.js interpreter for the system. The 20.x, and 18.x interpreters will remain available as parallel-installable options. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@fedoraproject.org * Responsible SIG: Node.js SIG == Detailed Description == Fedora 41 will ship with the latest LTS version of Node.js. '''dnf install nodejs''' will give users Node.js 22.x and the matching npm package. == Benefit to Fedora == Node.js is a popular server-side JavaScript engine. Keeping Fedora on the latest release allows us to continue tracking the state-of-the-art in that space. For those whose applications do not yet work with the 22.x release, Fedora 41 will also have the 20.x and 18.x releases available as selectable module streams. == Scope == * Proposal owners: We will build Node.js 22.x in Rawhide over the next few days as a non-default version (similar to 18.x in Fedora 40). Once this is done, we will announce that the switch will occur on or soon after May 27th, 2024. At that time, we will rebuild Node.js 20.x in non-default mode and rebuild Node.js 22.x as the default "nodejs" package with the appropriate upgrade path. * Other developers: Any developer with a package that depends on Node.js at run-time or build-time should test with the 22.x alternative package as soon as possible. Issues should be reported to nod...@lists.fedoraproject.org. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Users running Fedora 39 or Fedora 40 with the nodejs-20 packages will be automatically upgraded to the 22.x packages when they upgrade to Fedora 41, which may cause compatibility issues. If users are running software known not to support Node.js 22.x yet, they will need to install the nodejs18 compatibility packages and possibly modify their startup scripts to call `/usr/bin/node-18` rather than `/usr/bin/node`. == How To Test == * Confirm that `dnf install nodejs` results in Node.js 22.x being installed. * Confirm that upgrading from Fedora 39 or Fedora 40 with nodejs-20.x installed results in an upgrade to nodejs-22.x * Confirm that upgrading from Fedora 39 or Fedora 40 with the nodejs22 package installed results in an upgrade to the nodejs-22.x package, obsoleting the nodejs22 package. == User Experience == Users will have the 22.x release of Node.js available by default. See the "Upgrade/compatibility impact" section for specific details. == Dependencies == All packages prefixed with `nodejs-` depend on this package. If they do not work with Node.js 22.x, they will need to be updated, or made explicitly dependent upon the `nodejs20` compatibility package or else removed from Fedora 41. Prior to the switchover date to Node.js 22.x as the default, packagers are strongly encouraged to test their existing Node modules with 22.x by installing the nodejs22 forward-compatibility package (which provides `/usr/bin/node-22` == Contingency Plan == * Contingency mechanism: Revert to Node.js 20.x as the default Node.js interpreter. This will require bumping epoch. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? No == Documentation == * https://nodejs.org/dist/latest-v22.x/docs/api/ * https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V22.md * https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ == Release Notes == Fedora 41 now ships with Node.js 22.x as the default Node.js JavaScript server-side engine. If your applications are not yet ready for this newer version, they will need to be modified to depend on the compatibility package nodejs20 and to rely on `/usr/bin/node20` rather than `/usr/bin/node` for operation. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archi
F41 Change Proposal: Node.js 22.x by default (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/Nodejs22 Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-node-js-22-x-by-default-system-wide/114740 This is a proposed Change for Fedora Linux. 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 latest release of Node.js to carry a 30-month lifecycle is the 22.x series. As with 20.x, 18.x 16.x, 14.x, 12.x, 10.x and 8.x before it, Fedora 41 will carry 22.x as the default Node.js interpreter for the system. The 20.x, and 18.x interpreters will remain available as parallel-installable options. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email: sgall...@fedoraproject.org * Responsible SIG: Node.js SIG == Detailed Description == Fedora 41 will ship with the latest LTS version of Node.js. '''dnf install nodejs''' will give users Node.js 22.x and the matching npm package. == Benefit to Fedora == Node.js is a popular server-side JavaScript engine. Keeping Fedora on the latest release allows us to continue tracking the state-of-the-art in that space. For those whose applications do not yet work with the 22.x release, Fedora 41 will also have the 20.x and 18.x releases available as selectable module streams. == Scope == * Proposal owners: We will build Node.js 22.x in Rawhide over the next few days as a non-default version (similar to 18.x in Fedora 40). Once this is done, we will announce that the switch will occur on or soon after May 27th, 2024. At that time, we will rebuild Node.js 20.x in non-default mode and rebuild Node.js 22.x as the default "nodejs" package with the appropriate upgrade path. * Other developers: Any developer with a package that depends on Node.js at run-time or build-time should test with the 22.x alternative package as soon as possible. Issues should be reported to nod...@lists.fedoraproject.org. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Users running Fedora 39 or Fedora 40 with the nodejs-20 packages will be automatically upgraded to the 22.x packages when they upgrade to Fedora 41, which may cause compatibility issues. If users are running software known not to support Node.js 22.x yet, they will need to install the nodejs18 compatibility packages and possibly modify their startup scripts to call `/usr/bin/node-18` rather than `/usr/bin/node`. == How To Test == * Confirm that `dnf install nodejs` results in Node.js 22.x being installed. * Confirm that upgrading from Fedora 39 or Fedora 40 with nodejs-20.x installed results in an upgrade to nodejs-22.x * Confirm that upgrading from Fedora 39 or Fedora 40 with the nodejs22 package installed results in an upgrade to the nodejs-22.x package, obsoleting the nodejs22 package. == User Experience == Users will have the 22.x release of Node.js available by default. See the "Upgrade/compatibility impact" section for specific details. == Dependencies == All packages prefixed with `nodejs-` depend on this package. If they do not work with Node.js 22.x, they will need to be updated, or made explicitly dependent upon the `nodejs20` compatibility package or else removed from Fedora 41. Prior to the switchover date to Node.js 22.x as the default, packagers are strongly encouraged to test their existing Node modules with 22.x by installing the nodejs22 forward-compatibility package (which provides `/usr/bin/node-22` == Contingency Plan == * Contingency mechanism: Revert to Node.js 20.x as the default Node.js interpreter. This will require bumping epoch. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? No == Documentation == * https://nodejs.org/dist/latest-v22.x/docs/api/ * https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V22.md * https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ == Release Notes == Fedora 41 now ships with Node.js 22.x as the default Node.js JavaScript server-side engine. If your applications are not yet ready for this newer version, they will need to be modified to depend on the compatibility package nodejs20 and to rely on `/usr/bin/node20` rather than `/usr/bin/node` for operation. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives
F41 Change Proposal: Perl 5.40 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/perl5.40 Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-perl-5-38-system-wide/114739 This is a proposed Change for Fedora Linux. 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.40'' version brings a lot of changes done over a year of development. Perl 5.40 should be released on May 20th 2024. See [https://metacpan.org/release/PEVANS/perl-5.39.9/view/pod/perldelta.pod perldelta for 5.39.9] for more details about new release. == Owner == * Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal Josef Špaček]] * Email: , === Completed Items === === Items in Progress === === Items to Be Done === * Get dedicated build-root from rel-engs ''f41-perl'' * Upstream to release Perl 5.40 * Define perl_bootstrap in perl-srpm-macros * Rebase perl to 5.40.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 (51 packages) * Rebuild all updated packages * [https://jplesnik.fedorapeople.org/5.40/ Final lists of results] * Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs * Synchronize packages upgraded in ''f41'' build root * Rebuild Perl packages: 0 of 606 done (0.00 %) * Failed packages (0): == Detailed Description == New perl is released every year and updates containing mainly bug fixes follow during the year. The 5.40.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 ''f41-perl'' build-root against perl 5.40.0 and then if no major problem emerges the packages will be merged back to ''f41'' build-root. * Proposal owners: New perl and all packages requiring ''libperl.so'' or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f41-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 ''f41-perl'' build-root inheriting from ''f41'' build-root. After successful finishing the rebuild, they will be asked to merge ''f41-perl'' packages back to ''f41'' build-root. * 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 == Vast majority of functionality will be preserved. Only the packages that failed to build against perl 5.40 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 40 to 41. 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. 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.40 is not suitable for Fedora 41, we will revert back to perl 5.38 and we drop the temporary build-root with already rebuilt packages. * Contingency deadline: branching Fedora 41 from Rawhide. * Blocks release? No. == Documentation == * 5.40.0 perldelta * An announcement on perl-devel mailing list * An announcement on fedora-devel mailing list == Release Notes == TBD, when release candidate appears. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list
F41 Change Proposal: Perl 5.40 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/perl5.40 Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-perl-5-38-system-wide/114739 This is a proposed Change for Fedora Linux. 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.40'' version brings a lot of changes done over a year of development. Perl 5.40 should be released on May 20th 2024. See [https://metacpan.org/release/PEVANS/perl-5.39.9/view/pod/perldelta.pod perldelta for 5.39.9] for more details about new release. == Owner == * Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal Josef Špaček]] * Email: , === Completed Items === === Items in Progress === === Items to Be Done === * Get dedicated build-root from rel-engs ''f41-perl'' * Upstream to release Perl 5.40 * Define perl_bootstrap in perl-srpm-macros * Rebase perl to 5.40.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 (51 packages) * Rebuild all updated packages * [https://jplesnik.fedorapeople.org/5.40/ Final lists of results] * Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs * Synchronize packages upgraded in ''f41'' build root * Rebuild Perl packages: 0 of 606 done (0.00 %) * Failed packages (0): == Detailed Description == New perl is released every year and updates containing mainly bug fixes follow during the year. The 5.40.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 ''f41-perl'' build-root against perl 5.40.0 and then if no major problem emerges the packages will be merged back to ''f41'' build-root. * Proposal owners: New perl and all packages requiring ''libperl.so'' or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f41-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 ''f41-perl'' build-root inheriting from ''f41'' build-root. After successful finishing the rebuild, they will be asked to merge ''f41-perl'' packages back to ''f41'' build-root. * 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 == Vast majority of functionality will be preserved. Only the packages that failed to build against perl 5.40 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 40 to 41. 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. 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.40 is not suitable for Fedora 41, we will revert back to perl 5.38 and we drop the temporary build-root with already rebuilt packages. * Contingency deadline: branching Fedora 41 from Rawhide. * Blocks release? No. == Documentation == * 5.40.0 perldelta * An announcement on perl-devel mailing list * An announcement on fedora-devel mailing list == Release Notes == TBD, when release candidate appears. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list
Re: Fedora 40 Elections are now open!
I nearly had it all correct! One day... :-D Thanks Neal, I have updated the 'protection' on all pages to allow users to edit them, but let me know if you are still having issues. Thanks, Aoife On Wed, Apr 24, 2024 at 4:46 PM Neal Gompa wrote: > > On Wed, Apr 24, 2024 at 11:31 AM Aoife Moloney wrote: >> >> Hello everyone, >> >> I hope you all are enjoying Fedora 40, and this release also marks the start >> of a new election cycle[1]. As of now, the nomination period for positions >> on Fedora Council, Fedora Mindshare, FESCo and EPEL Steering Committee is >> now open! >> >> We have some slight changes to some elections this cycle, with more detail >> available to read on the Elections blog post coming tomorrow as part of the >> Fedora Council hackfest mini-series, but for now the main things you need to >> know are the following: >> >> We are welcoming the EPEL Steering Committee to our elections cycle! There >> are currently four seats available for the EPEL Steering Committee, so if >> you or someone you know would like to serve for a term of 12 months on this >> committee, you can nominate yourself or someone else on their candidate >> nominations page[2]. >> >> >> The Fedora Council is moving to a once-per-year election, and we will be >> electing two new members for this cycle for a 12-month term. If you would >> like to serve on the council, or know someone who would be a great fit, you >> can nominate yourself or other(s) on the council nominations page[3]. >> >> >> The Fedora Engineering Steering Committee (FESCo) will have four seats open >> this cycle, and will remain on the current twice per year elections cadence. >> If you would like to nominate yourself, or someone you know who would be a >> great addition to FESCo, you can nominate yourself or others on their >> nominations page[4]. >> >> >> The Fedora Mindshare Committee has one seat open for this election term, and >> their election schedule will also stay on the twice-per-year cadence. If you >> would like to get involved, or know someone who would be a great person to >> be considered for the Mindshare committee activities like budget management >> with the FCA, ambassador work, outreachy work, etc, you can nominate >> yourself and/or them now on the nominations page[5]. >> >> >> Very Important: Please do not nominate someone for a seat on any of the >> above governance bodies without their explicit consent. >> >> >> The nominations period will be open until Wednesday, May 8th and events >> during the F40 elections period can be found on the schedule[6]. >> >> >> [1] >> https://docs.fedoraproject.org/en-US/program_management/pgm_guide/elections/ >> [2] https://fedoraproject.org/wiki/EPEL/Nominations >> [3] https://fedoraproject.org/wiki/Council/Nominations >> [4] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations >> [5] https://fedoraproject.org/wiki/Mindshare/Nominations >> [6] https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html > > > The nomination pages seem to be locked, I can't edit them? At least not the > Council, FESCo, or Mindshare ones. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
the JVM may be automatically uninstalled as it is possibly not required by anything. It is possible that there are users with only some older JVM installed. The following depends on the decision of each Java application package maintainer, but the general expectation is that the system-wide JVM will be installed and the older JVM will no longer be required by other packages. Users who explicitly installed JVMs of various versions: no change. == Dependencies == * `javapackages-tools` ** This change allows the removal of the `Requires` generator. == Contingency Plan == * Contingency mechanism: ** In case of unexpected problems, the `Requires` generators can be reintroduced into `javapackages-tools` and packages can be rebuilt. * Contingency deadline: Branch Fedora Linux 41 from Rawhide Tue 2024-08-06 * Blocks release? No == Documentation == No documentation outside of this document. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
the JVM may be automatically uninstalled as it is possibly not required by anything. It is possible that there are users with only some older JVM installed. The following depends on the decision of each Java application package maintainer, but the general expectation is that the system-wide JVM will be installed and the older JVM will no longer be required by other packages. Users who explicitly installed JVMs of various versions: no change. == Dependencies == * `javapackages-tools` ** This change allows the removal of the `Requires` generator. == Contingency Plan == * Contingency mechanism: ** In case of unexpected problems, the `Requires` generators can be reintroduced into `javapackages-tools` and packages can be rebuilt. * Contingency deadline: Branch Fedora Linux 41 from Rawhide Tue 2024-08-06 * Blocks release? No == Documentation == No documentation outside of this document. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Fedora Miracle Spin (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-fedora-miracle-spin-self-contained/114182
This is a proposed Change for Fedora Linux.
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 ==
Create an official Fedora Spin shipping the up-and-coming Miracle Window Manager
== Owner ==
* Name: [[User:mattkae| Matthew Kosarek]], [[User:tsimonq2| Simon
Quigley]], [[User:ngompa| Neal Gompa]]
* Email: matt...@matthewkosarek.xyz, si...@tsimonq2.net, ngomp...@gmail.com
== Detailed Description ==
The Miracle Window Manager is a tiling window manager based on the Mir
compositor library. While it is a newer project, it contains many
useful features such as a manual tiling algorithm, floating window
manager support, support for many Wayland protocols, proprietary
Nvidia driver support, and much more. Users are increasingly
interested in using miracle in various systems.
The goal of the miracle spin is to build a complete and elegant tiling
window experience within the Fedora ecosystem.
== Feedback ==
== Benefit to Fedora ==
Miracle will provide Fedora with a high-quality Wayland experience
built with support for all kinds of platforms, including low-end ARM
and x86 devices. On top of this, Fedora will be the first distribution
to provide a Miracle based spin, ensuring that it will become the de
facto distribution for running Miracle.
== Scope ==
* Proposal owners:
** SIG request: [https://pagure.io/fedora-infrastructure/issue/11856 #11856]
** comps: TODO
** fedora-release-miracle: TODO
** kickstart: TODO
** livesys-scripts: TODO
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/12077 #12077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/491 #491]
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a new spin, so there is nothing.
== How To Test ==
{{package|miracle-wm}} is available in Fedora Linux 40, so it can be
installed on top of something like the existing Sway spin and
configured to reuse much of the tools used there.
For Fedora Linux 41, once the spin is produced, people can download
and try the experience intended to be released.
== User Experience ==
The experience will be similar to the Sway spin, though with more
features there may be some different choices on defaults.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Push off to the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This release introduces the Fedora Miracle Spin. The Fedora Miracle
Spin aims to provide the premiere Miracle window manager experience on
top of Fedora Linux, the leading edge platform for developers and
users alike.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Fedora Miracle Spin (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-fedora-miracle-spin-self-contained/114182
This is a proposed Change for Fedora Linux.
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 ==
Create an official Fedora Spin shipping the up-and-coming Miracle Window Manager
== Owner ==
* Name: [[User:mattkae| Matthew Kosarek]], [[User:tsimonq2| Simon
Quigley]], [[User:ngompa| Neal Gompa]]
* Email: matt...@matthewkosarek.xyz, si...@tsimonq2.net, ngomp...@gmail.com
== Detailed Description ==
The Miracle Window Manager is a tiling window manager based on the Mir
compositor library. While it is a newer project, it contains many
useful features such as a manual tiling algorithm, floating window
manager support, support for many Wayland protocols, proprietary
Nvidia driver support, and much more. Users are increasingly
interested in using miracle in various systems.
The goal of the miracle spin is to build a complete and elegant tiling
window experience within the Fedora ecosystem.
== Feedback ==
== Benefit to Fedora ==
Miracle will provide Fedora with a high-quality Wayland experience
built with support for all kinds of platforms, including low-end ARM
and x86 devices. On top of this, Fedora will be the first distribution
to provide a Miracle based spin, ensuring that it will become the de
facto distribution for running Miracle.
== Scope ==
* Proposal owners:
** SIG request: [https://pagure.io/fedora-infrastructure/issue/11856 #11856]
** comps: TODO
** fedora-release-miracle: TODO
** kickstart: TODO
** livesys-scripts: TODO
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/12077 #12077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/491 #491]
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a new spin, so there is nothing.
== How To Test ==
{{package|miracle-wm}} is available in Fedora Linux 40, so it can be
installed on top of something like the existing Sway spin and
configured to reuse much of the tools used there.
For Fedora Linux 41, once the spin is produced, people can download
and try the experience intended to be released.
== User Experience ==
The experience will be similar to the Sway spin, though with more
features there may be some different choices on defaults.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Push off to the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This release introduces the Fedora Miracle Spin. The Fedora Miracle
Spin aims to provide the premiere Miracle window manager experience on
top of Fedora Linux, the leading edge platform for developers and
users alike.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora 40 Elections are now open!
Hello everyone, I hope you all are enjoying Fedora 40, and this release also marks the start of a new election cycle[1]. As of now, the nomination period for positions on Fedora Council, Fedora Mindshare, FESCo and EPEL Steering Committee is now open! We have some slight changes to some elections this cycle, with more detail available to read on the Elections blog post coming tomorrow as part of the Fedora Council hackfest mini-series, but for now the main things you need to know are the following: - We are welcoming the EPEL Steering Committee to our elections cycle! There are currently four seats available for the EPEL Steering Committee, so if you or someone you know would like to serve for a term of 12 months on this committee, you can nominate yourself or someone else on their candidate nominations page[2]. - The Fedora Council is moving to a once-per-year election, and we will be electing two new members for this cycle for a 12-month term. If you would like to serve on the council, or know someone who would be a great fit, you can nominate yourself or other(s) on the council nominations page[3]. - The Fedora Engineering Steering Committee (FESCo) will have four seats open this cycle, and will remain on the current twice per year elections cadence. If you would like to nominate yourself, or someone you know who would be a great addition to FESCo, you can nominate yourself or others on their nominations page[4]. - The Fedora Mindshare Committee has one seat open for this election term, and their election schedule will also stay on the twice-per-year cadence. If you would like to get involved, or know someone who would be a great person to be considered for the Mindshare committee activities like budget management with the FCA, ambassador work, outreachy work, etc, you can nominate yourself and/or them now on the nominations page[5]. *Very Important:* Please do not nominate someone for a seat on any of the above governance bodies without their explicit consent. The nominations period will be open until Wednesday, May 8th and events during the F40 elections period can be found on the schedule[6]. [1] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/elections/ [2] https://fedoraproject.org/wiki/EPEL/Nominations [3] https://fedoraproject.org/wiki/Council/Nominations [4] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [5] https://fedoraproject.org/wiki/Mindshare/Nominations [6] https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 40 Elections are now open!
Hello everyone, I hope you all are enjoying Fedora 40, and this release also marks the start of a new election cycle[1]. As of now, the nomination period for positions on Fedora Council, Fedora Mindshare, FESCo and EPEL Steering Committee is now open! We have some slight changes to some elections this cycle, with more detail available to read on the Elections blog post coming tomorrow as part of the Fedora Council hackfest mini-series, but for now the main things you need to know are the following: - We are welcoming the EPEL Steering Committee to our elections cycle! There are currently four seats available for the EPEL Steering Committee, so if you or someone you know would like to serve for a term of 12 months on this committee, you can nominate yourself or someone else on their candidate nominations page[2]. - The Fedora Council is moving to a once-per-year election, and we will be electing two new members for this cycle for a 12-month term. If you would like to serve on the council, or know someone who would be a great fit, you can nominate yourself or other(s) on the council nominations page[3]. - The Fedora Engineering Steering Committee (FESCo) will have four seats open this cycle, and will remain on the current twice per year elections cadence. If you would like to nominate yourself, or someone you know who would be a great addition to FESCo, you can nominate yourself or others on their nominations page[4]. - The Fedora Mindshare Committee has one seat open for this election term, and their election schedule will also stay on the twice-per-year cadence. If you would like to get involved, or know someone who would be a great person to be considered for the Mindshare committee activities like budget management with the FCA, ambassador work, outreachy work, etc, you can nominate yourself and/or them now on the nominations page[5]. *Very Important:* Please do not nominate someone for a seat on any of the above governance bodies without their explicit consent. The nominations period will be open until Wednesday, May 8th and events during the F40 elections period can be found on the schedule[6]. [1] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/elections/ [2] https://fedoraproject.org/wiki/EPEL/Nominations [3] https://fedoraproject.org/wiki/Council/Nominations [4] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [5] https://fedoraproject.org/wiki/Mindshare/Nominations [6] https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 40 Final is GO
The Fedora Linux 40 Final RC1.14 compose is GO and will be shipped live on Tuesday, 23rd April. For more information please check the Go/No-Go meeting minutes[1] or log[2], and a huge thank you to everyone involved in this release! [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.log.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 40 Final is GO
The Fedora Linux 40 Final RC1.14 compose is GO and will be shipped live on Tuesday, 23rd April. For more information please check the Go/No-Go meeting minutes[1] or log[2], and a huge thank you to everyone involved in this release! [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.log.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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: F41 Change Proposal: Replace Redit with Valkey (system-wide)
Apologies, this title should read *Redis*. -- ___ 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: F41 Change Proposal: Replace Redit with Valkey (system-wide)
Apologies, this title should read *Redis*. -- ___ 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
REMINDER: Fedora Linux 40 Final Go/No-Go Meeting Tomorrow
Hi all, Quick reminder that the Fedora Linux 40 Final Go/No-Go meeting[1] will be held tomorrow, April 18th @ 1700 UTC in #meeting:fedoraproject.org on Matrix. At this time, we will determine the status of the F40 Final for the current target date[2] of Tuesday April 23rd. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10791/ [2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] REMINDER: Fedora Linux 40 Final Go/No-Go Meeting Tomorrow
Hi all, Quick reminder that the Fedora Linux 40 Final Go/No-Go meeting[1] will be held tomorrow, April 18th @ 1700 UTC in #meeting:fedoraproject.org on Matrix. At this time, we will determine the status of the F40 Final for the current target date[2] of Tuesday April 23rd. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10791/ [2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
Fedora Linux 40 Final Blocker Bug Report: 2024-04-12
Hi folks, We are still seeing a few blockers for the Fedora Linux 40 final milestone being filed in the blocker bugs app[1]. Your help in reproducing the bug, suggesting fixes and verifying updates would be greatly appreciated before the next Go/No-Go meeting[2][3] on Thursday April 18th to have these bugs resolved. Please refer to the bugs in bugzilla for more detailed descriptions. Below is an approximation of each bug's activity. == Proposed Blocker == 1. nautilus - [abrt] nautilus: ptr_array_fre(): nautilus killed by SIGABRT - NEW ACTION: Upstream to diagnose issue == Accepted Blockers == 1. gcc - Illegal instruction errors in libQt6Core - MODIFIED ACTION: QA to verify fix https://bodhi.fedoraproject.org/updates/FEDORA-2024-17bcbff3cf 2. khelpcenter - The KDE help center does not show the documentation for KDE applications - ON_QA ACTION: N/A == Accepted Previous Release Blocker == 1. distribution - dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key - NEW ACTION: HELP WANTED to figure out a fix please = Bug by Bug Detail = == Proposed Blockers == 1. nautilus - [abrt] nautilus: ptr_array_free(): nautilus killed by SIGABRT - https://bugzilla.redhat.com/show_bug.cgi?id=2274724 - NEW Nautilus crashes when trying to compress a folder and file together. The issue does not seem to affect creating zip or downloading them and an upstream bug has been filed https://gitlab.gnome.org/GNOME/nautilus/-/issues/3389 == Accepted Blockers == 1. gcc - Illegal instruction errors in libQt6Core - https://bugzilla.redhat.com/show_bug.cgi?id=2272758 - MODIFIED There are Illegal instruction errors in libQt6Core and currently a small number of CPUs with AES-NI are affected. Please review the bug comments for a list of affected models. This bug causes plasma to be unable to boot this, or anything in the boot chain that's linked against qt6 to fail. A fix has been submitted which contains an updated build of gcc in the buildroots and this appears to be resolving the issue, but will await verification from QA https://bodhi.fedoraproject.org/updates/FEDORA-2024-17bcbff3cf 2. khelpcenter - The KDE help center does not show the documentation for KDE applications - https://bugzilla.redhat.com/show_bug.cgi?id=2271837 - ON_QA The KDE Help centre doesnt show, ir is missing, documentation for the KDE applications. A workaround can be found by doing a search for the documentation through the help centre, but there are two links, of which only one currently works. An upstream bug has been filed https://bugs.kde.org/show_bug.cgi?id=484176 and the upstream maintainers are aware of the issue and are working on a fix. == Accepted Previous Release Blocker == 1. distribution - dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key - https://bugzilla.redhat.com/show_bug.cgi?id=2242759 - NEW beta dnf system-upgrade reboot fails on Raspberry Pi 4 (8 gb). Using dnf system-upgrade log --number=-1, an entry like "Signature 10d5 created at Wed Sep 27 16:33:34 2023 invalid: signature is not alive" is generated for each rpm in the upgrade list. Raspberry Pi 4 does not have a hardware real time clock so when the Pi is booting Fedora system time is at some (arbitrary?) date and time. During a normal boot chronyd is executed and will set the clock: "chronyd[571]: System clock wrong by 944623.935135 seconds". If the gpg key used by DNF during the system-upgrade has a valid period more recent than the boot time, system-upgrade will fail. There are various possible workarounds, but none ideal for users to have to implement, so a fix is still required for this bug to be resolved. Anyone with Python experience would be most welcome to give feedback on some of the ideas to fix that have been proposed or come up with a fix. [1] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist [2] https://calendar.fedoraproject.org/meeting/10791/ [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
F41 Change Proposal - Python Built with gcc -03 (self-contained)
* [[Changes/Python_Extension_Flags_Reduction]] landed in Fedora 39 * [[Changes/Python3.13]] is expected to land in Fedora 41. If not, we will apply this on Python 3.12. == Contingency Plan == * Contingency mechanism: revert the change, rebuild Python * Contingency deadline: Final Freeze * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal - Python Built with gcc -03 (self-contained)
* [[Changes/Python_Extension_Flags_Reduction]] landed in Fedora 39 * [[Changes/Python3.13]] is expected to land in Fedora 41. If not, we will apply this on Python 3.12. == Contingency Plan == * Contingency mechanism: revert the change, rebuild Python * Contingency deadline: Final Freeze * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal - Reproducible Package Builds (System-Wide)
lparser` to `python3` (probably conditionalized on `rpm-build`) * Other Developers: ** Test their packages with the additional phase, report problems ** Potentially integrate changes to packages to enable reproducibility * Release Engineering: Ideally we want this to happen before the mass rebuild, but that is not strictly required. * Policies and Guidelines: Fedora Packaging Guidelines should be updated to include information on the add-determinism BuildRoot Policy. User documentation should be amended to include instructions on how to verify reproducibility for a given package, and what packages are known to be non-reproducible, and how to opt-out. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: All software and requests are consistent with the decision process and similar across other groups in Fedora. The Fedora Reproducibility Working group began at Flock 2023 in Cork. == Upgrade/compatibility impact == No impact is expected. == How To Test == To test on the level of individual files: * install `add-determinism` * call `SOURCE_DATE_EPOCH=… add-determinism -v ./path/to/file` To test package builds: * build a local copy of `redhat-rpm-config` with https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/293 * install `add-determinism` * build packages ;) (This can be done on a normal system or in a mock chroot.) == User Experience == No impact is expected. == Dependencies == == Contingency Plan == * Contingency mechanism: ** In case of major problems, disable the change in `redhat-rpm-config`. ** In case of problems with specific packages, opt-out by setting a macro. * Contingency deadline: No limit really. * Blocks release? No. == Documentation == * [https://docs.fedoraproject.org/en-US/reproducible-builds/ Fedora Reproducible Builds] * [https://github.com/keszybz/add-determinism/blob/main/rpm/macros.build-reproducibility add-determinism macros.build-reproducibility] * [https://github.com/keszybz/add-determinism/tree/main?tab=readme-ov-file#build-postprocessor-to-reset-metadata-fields-for-build-reproducibility add-determinism README] == Release Notes == Fedora package builds are now more deterministic, bringing the distribution closer to the goal of achieving fully reproducible builds for all of its packages. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal - Reproducible Package Builds (System-Wide)
lparser` to `python3` (probably conditionalized on `rpm-build`) * Other Developers: ** Test their packages with the additional phase, report problems ** Potentially integrate changes to packages to enable reproducibility * Release Engineering: Ideally we want this to happen before the mass rebuild, but that is not strictly required. * Policies and Guidelines: Fedora Packaging Guidelines should be updated to include information on the add-determinism BuildRoot Policy. User documentation should be amended to include instructions on how to verify reproducibility for a given package, and what packages are known to be non-reproducible, and how to opt-out. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: All software and requests are consistent with the decision process and similar across other groups in Fedora. The Fedora Reproducibility Working group began at Flock 2023 in Cork. == Upgrade/compatibility impact == No impact is expected. == How To Test == To test on the level of individual files: * install `add-determinism` * call `SOURCE_DATE_EPOCH=… add-determinism -v ./path/to/file` To test package builds: * build a local copy of `redhat-rpm-config` with https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/293 * install `add-determinism` * build packages ;) (This can be done on a normal system or in a mock chroot.) == User Experience == No impact is expected. == Dependencies == == Contingency Plan == * Contingency mechanism: ** In case of major problems, disable the change in `redhat-rpm-config`. ** In case of problems with specific packages, opt-out by setting a macro. * Contingency deadline: No limit really. * Blocks release? No. == Documentation == * [https://docs.fedoraproject.org/en-US/reproducible-builds/ Fedora Reproducible Builds] * [https://github.com/keszybz/add-determinism/blob/main/rpm/macros.build-reproducibility add-determinism macros.build-reproducibility] * [https://github.com/keszybz/add-determinism/tree/main?tab=readme-ov-file#build-postprocessor-to-reset-metadata-fields-for-build-reproducibility add-determinism README] == Release Notes == Fedora package builds are now more deterministic, bringing the distribution closer to the goal of achieving fully reproducible builds for all of its packages. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
