Fedora Data Centre Move - What This Means For You
# Fedora Data Centre Move - What it means for you? to: devel-announce@lists.fedoraproject.org subject: Fedora Data Centre Move - What it means for you? Good Morning, As you may have heard in the past few months, most of the Fedora Infrastructure which is currently hosted in a data-center in Phoenix Arizona (USA) will be moving to a new datacenter in Virgina (USA) in just a few weeks now. While we are doing our best to ensure a continuity of service to the project, there will be some consequences of this move. The main issues will be that for several weeks: - *Fedora's build capacity will be significantly reduced*. - A few applications, not directly related to building Fedora, running in the Fedora Infrastructure will be offline (see link below) Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though. As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike). In addition, during the move there will be no staging environment. This will directly impact very few people, but from an infrastructure point of view it also means that we try to avoid as much as possible updating applications (for example deploying a new account system or new releases) during that time. To give you some insight on dates*: - The week of June 8th we will be moving services from one data-center to the other, so there will be ongoing outages as resources are moved from one data center to one with diminished capacity. - We are hoping to continue rebuilding the infrastructure in Virgnia the week of June 22nd as shipped hardware arrives at the new facility. - The target deadline to complete the entire move and return to normal capacity in Fedora Infrastructure is July 28th A couple of final notes: - right after the end of the move, there is a mass-rebuild scheduled, so you could use this as an opportunity to let releng do the builds for you if you prepare everything in dist-git. - Please try to avoid pinging nirik or smooge in the coming weeks so they can focus on this delicate exercise, but if you run into them, I'm sure they will appreciate your support or/and some cookies on irc (nirik++ smooge++)! - Please bare with us while we're working on the move as responses to tickets/requests will likely be slower than usual. A list of the applications that will be impacted by the colo move is available at: https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA Thanks in advance for your understanding and help, Aoife * All the dates are subject to changes, going from networking issues, to servers dying because of the move, to a world-wide pandemic changing the working conditions in the data-center, but these are current estimates. ___ 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
About the Future of Communishift
Good Morning Everyone, I wanted to share with you some information regarding the current state and future of Communishift. The infrastructure team presented on this project back in 2019 during Nest [1] [2], and since then, we have deployed it, started using it and had to shut it down for the colo-move. As a number of people have noted, it has not come back up yet, and during Nest this year, we had hinted that communishift is not going to come back alive looking the same as when we shut it down, and that is unfortunately true. The idea for communishift was to give to anyone in the community a place where they could run any application they wish to provide to the community. This was a proper place where Joe and Jane could offer the service foo to the foo SIG without engaging the infrastructure's team responsibility to keep the service up and running. The infrastructure team would have been able to say: "well the openshift cluster is running, so if the app isn't, talk to the application maintainer, there is nothing we can do about it". Basically, it gave a place where we could experiment with new apps without adding too much work to the infrastructure team. However, the General Data Protection Regulation (GDPR) [3] and the California Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team (and thus Red Hat) responsible for the content hosted by any services running in our infrastructure. In other words, the Fedora Infrastructure team would be responsible to answer all GDPR/CCPA related requests and requirements for any and all services running in communishift (services that the team has 0 knowledge about, that's the whole goal of communishift). For these reasons communishift is not going to come back to life in the same way it was shut down for the colo move. We have not given up on the original idea though (ie: providing a place where community members can deploy applications without adding work on the infrastructure team), however, as with anything involving legal, this is going to be a slow process. We will share any information as soon as we are able. We're sorry for the inconvenience this causes, we really would like the situation to be different but we also appreciate these regulations for what they are (protecting our personal information) so we want to respect them. Hoping this clarifies the situation around communishift a bit. Aoife, Kevin & Pingou - On behalf of the Fedora Infrastructure team [1] https://fedoraproject.org/wiki/Infrastructue/Communishift [2] https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s [3] https://gdpr-info.eu/ [4] https://www.oag.ca.gov/privacy/ccpa [4] https://www.oag.ca.gov/privacy/ccpa -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
Gitlab Ask Me Anything - Sept 10th, 13:30 UTC
Good Morning folks, As you likely remember, a little while ago now, was announced the decision to move dist-git to a gitlab instance. This decision was the results of different factors which included a wish for Red Hat to have a consistent tooling and experience across the different distribution it works on or with, meaning: RHEL, CentOS-Stream, CentOS Linux and Fedora. Since then, a number of technical requirements needed to use gitlab in Fedora, were gathered and a ticket was opened at gitlab to track them [1] but up until now the progress on the Fedora side has been fairly slow. This is mostly due to the feedback from Fedora that followed this decision, leading to a focus on the first two distributions in the list above. However, in order to progress the evaluation of gitlab, we have organized an "Ask Me Anything" (AMA) session with the gitlab folks on Thursday September 10th 2020, at 13:30 UTC on #fedora-meeting-1 on irc.freenode.net. The idea is to have an open floor for anyone in the community to discuss with GitLab the technical merits that GitLab has, as well as the requirements we, the Fedora community, have. In order for this session to be productive, we believe that it may be wise to start gathering questions to GitLab early on, so they can also look into them and prepare their answers (I'm sure we all prefer to have actual answers rather than: "hm, I don't know, let me check and I'll get back to you on this"). Of course, we will still be able to ask question at the last minute or even during the session. Gathering them as early as possible is just a way for GitLab to see what interests us, who may be the right persons to attend this session and overall to make this hour as productive as possible. So there are two ways for you to submit your questions to the GitLab folks on a potential deployment of GitLab as a front-end to our dist-git (ie: src.fedoraproject.org): - A public hackmd document: https://hackmd.io/RW8HahOeR7OJPON1dwuo3w# Underneath each questions you will also be able to vote (simply add a ``+1`` to the ``Votes:`` line), the most popular questions will be asked first. Since this document is public, please be mindful of what previous people entered. - A discussion on forum.gitlab.com at: https://forum.gitlab.com/t/fedora-migration-to-gitlab-ask-me-anything-ama-thursday-september-10-2020/41971 The questions that we will not have time for, or cant be answered during the session, will be answered afterward. The AMA minutes will be sent in the CPE weekly mail, the hackmd will be updated and and summary published on the community blog. Looking forward to the discussion, Aoife [1] https://gitlab.com/gitlab-org/gitlab/-/issues/217350 -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
GitLab AMA Topic Discussion: Permissions & Access
-org/gitlab/-/issues/233379 that could help with this by requiring an additional person approve the deletion & there’s a related issue https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list of authorized approvers for these types of changes (not MRs) that sounds aligned with this ask - Question: How would group membership be sync to GitLab? - Answer: We are still not 100% clear on that, since GitLab supports OpenIDC & we will need to investigate if we could make use of the group scope returned by AAA. Otherwise we will need a solution to sync the groups to GitLab most likely using API calls. - Question:Will there be better support for Podman in CI workflows in GitLab? - Answer: Short term solution might be using a custom executor, long term solution would be getting the Runner executor podman (#4185) feature request issue scheduled and closed. Ultimately product team schedules work, while everyone can contribute MRs or fixes ahead of schedule. In the past, I've seen a lot of enthusiasm from GitLab team members in helping solve problems from Open Source Program members whenever possible. These are all the questions that had answers I could spot from the larger hackmd document, however my apologies if I missed any. next week I will pull in all the questions and answers on 'Message Bus' in a new email and send for discussion. I know there are still some questions unanswered so I will try to chase down answers to these, but it could take some time. If I can get them answered over the next few weeks, I will send a 'misc' topic email at the end of these few weeks worth of emails. I hope you find this helpful and it is going to take some time to work through everything so thank you for your patience and involvement in this, it is very much appreciated. Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
Re: CPE Team Engagement Feedback
Hi Everyone, It has been a little over a month since I have sent this email on changes we have made to our work processes, how we are categorizing work within our team and how we are planning projects in advance, so thank you to everyone who replied to me with your feedback! If you caught the CPE Leadership panel, the feedback was shared there, however here were the suggestions I have received thus far, with my next steps inline: Continue to communicate regularly on projects & updates - Will do, weekly emails have been a bit more sporadic lately as I have had some time off Less acronyms & abbreviations in comms :) - Sure, that's an easy fix on my end and makes sense Publish team members timezone on docs.fpo/cpe to help define our ‘working hours’ - Will do, I hope to get to this by end of August and they will be reflected on docs.fpo/cpe Publish the workflow diagram to docs.fpo/cpe and add filtered versions that are user specific - Same as above, publishing it on docs.fpo/cpe-initiatives Office Hours on IRC are a useful way to contact team Product Owner - Great to hear, please feel free to stop by when you can/want to. They are on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @ 1500 UTC on #centos-meeting Public tracker for bugs - Our team meets twice a day, every day on IRC to review tickets and issues to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on #fedora-admin. These are public meetings so please feel free to attend. As a product owner of a community facing team, it is hugely important to me to understand how you are finding our current process and what amendments/improvements we/I should make to those ways of working for a more transparent relationship. If you would still like to share your suggestions and feedback with me, please feel free to do so at any time either via email, IRC or google chat (if you are/want to use that platform). Our team is also running a survey so you can also submit your feedback through https://fedoraproject.limequery.com/696793?lang=en <https://meet.google.com/linkredirect?authuser=0=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den> . The survey will close on 30th August. Thanks again for your engagement and please do take our survey if you wish to share with us what you like about how we are working, and areas we can still grow and improve in. Kindest regards, Aoife On Wed, Jul 8, 2020 at 10:09 AM Aoife Moloney wrote: > Hi Everyone, > > As we kick off our team's work for Quarter 3 of this year, we would > like to take this opportunity to ask for your feedback on our > engagement over the last few months. > > The CPE has been working on trying to improve our communication with > our communities and increase visibility on how we decide on what to > work on. We have taken many steps to improve our communication such as > IRC Office hours, regular initiative updates on our taiga board, > weekly mail and blog posts on what we achieved in each quarter and > what we are planning to work on next. > We have also had a few discussions before with some Fedora Council and > CentOS Board members on how best to engage with the CPE Team when you > wish to brief in an initiative or need to file a > bug/issue/enhancement, and as time goes by we are refining our > processes. > We would like to share with you our current approaches that we are > using for you to provide feedback on how you feel these are working. > > > > > It is important for our team to feel like their time is protected so > that they are able to enjoy a healthy work-life balance, so we have > categorized work requests that the team responds to into two > categories which we believe benefits both the CPE team and the > communities we serve: > > - Project Teams > - These teams are created based on an initiative that has been: > - Received by our product owner in advance > - The work involved has been scoped, reviewed and accepted to > the backlog by the CPE Review Team > - Prioritized and actioned for work during our teams quarterly > planning sessions by CPE Team Stakeholders and Review Team > > - Sustaining Team > - This team responds to 'lights on work' and requests that come in > on an ad hoc & regular basis such as: > - BAU infra/releng requests > - RFEs > - Bug fixes > > > > ## How we propose to deal with Project Team Initiatives? > > * We have published deadlines for initiatives to be briefed into our > team by for each quarter here: > https://docs.fedoraproject.org/en-US/cpe/time_tables/ > * Project requests that are recieved are then discussed further with > the requestor and relevant team lead(s) with our product owner > * During our monthly quarterly planning sessions, the CPE Review Team > r
CPE Team Engagement Feedback
ackmd, please visit this link https://hackmd.io/xgkPVcv1Swuy9U-wGiKQPw?view Looking forward for your feedback, Aoife ... -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
Data Centre Move Update - Moving Week!
# DataCentre Move Update: 2020-06-17 Hi everyone, I hope you are all having a good week! I would like to give you some updates on the Data Centre Move project that some members of the CPE team have been involved in over the last few months. As you are probably aware at this point, the Fedora hardware has been moving from the current data centre in Phoenix, Arizona to IAD2 in Washington and to facilitate this move, we have been reducing services available in Fedora to what is essential for operations over a 6-8 week period. We are now officially operating in the reduced Fedora service and the final hardware shipment has been packed up and is in transit to its new home! We are expecting to begin re-racking the hardware in the new datacentre from next week, beginning June 22nd. ### Service Bringup Schedule The team intend to prioritize the bringup of the following, but not limited to, services between the period of 22nd June to August 14th: * Builder systems - est by July 3rd * Additional high availability capacity * Staging environment - est by July 28th * CommuniShift (in RDU-CC which was paused in May to allow for the bringup of the reduced Fedora service) - est by July 28th * Remainder of applications for Fedora, such as Nuancier, Fedocal, etc - est by August 12th For a full list of services that are impacted by this move, please see previous hackmnd note https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view ### Additional Communications for Context For additional context, Kevin Fenzi has sent mails last week on a daily basis alerting the community on services as and when they are being brought down. Please see copy of emails sent here: Day 1 https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/WYMAEIYUQSX6NMZ4LHJBBZBGJZCCEUWF/ Day 2 https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/56CHCFO6IKWC2JEOL657KHEGIOOIUAIU/ Day 3 & 4 https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/CC2PHZMZC2EDVVGXRXOK34S5EM5K7DFH/ We also have a 'What this move means for you' email that went to devel-annou...@fedoraproject.org https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/27U6YT73556KYW2RIFJO6J2HYMYVP22U/ ### What can you do to help? We would ask you to please be patient and be aware that at times PR, build requests, and other build items may not work due to resource limitations. Please open tickets when this happens as we may not be able to get to it immediately or know the problem is occurring. We also have a list of services that we are asking for help validating once bringup is complete in IAD2, so if you are able to assist us, please check this hackmd and reach out to Kevin Fenzi (nirik) and/or Stephen Smoogen (smooge) for instruction as the validation process may be different in the new datacentre https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ Thank you for your patience and understanding during this crucial time as we complete the final 9 weeks of this project! Kind regards, Batman, Robin and Alfred :) -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
GitLab AMA Topic Follow Up: Namespace & Issue Tracking
# GitLab AMA Session Topic - Namespace & Issue Tracking Hi everyone, Thanks again for your involvement in the GitLab AMA session on IRC in September. This email discussion thread is on Namespace & Issue Tracking. I have pulled the relevant questions and answers from the original hackmd doc into one email and if you would like to discuss this topic specifically, here might be a good place to do so so your conversations don't go down a 'rabbit hole' :) Here are some links to resources as well: * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w * Chat log from session https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html * AMA Blog post https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 * Here is this email in hackmd if you wish to view it there: https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view ## Namespace & Issue Tracking - Question: Currently dist-git in Fedora has several namespaces: rpms, modules, containers, tests... All namespaces but the ``tests`` namespace have their issue tracker in bugzilla. Would this work in gitlab? Can we selectively enable/disable issue tracking per namespace for the entire instance? (ie: w/o giving the possibility to ``owner`` or ``maintainer`` to toggle that setting.) - Answer: It may need to be checked again, but it appears you can turn on/off the issue tracker at the project level. - Question: Currently dist-git in Fedora has several namespaces: rpms, modules, containers, tests... All namespaces but the ``tests`` namespace have their issue tracker in bugzilla. Would this work in gitlab? Can we selectively enable/disable issue tracking per namespace for the entire instance? (ie: w/o giving the possibility to ``owner`` or ``maintainer`` to toggle that setting.) - Answer: You can turn the GitLab issue tracker on and off by project. See https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions Namespaces map to “group” in GitLab. Here’s more info about them: https://docs.gitlab.com/ee/api/namespaces.html - Question: Fedora, as far as I understand, still plan on using bugzilla as issue tracker. Currently default assignee and the CC are gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc), the other maintainers (who did not ``unwatch issues`` in the project - mechanism for them to opt-out of being in the CC list) and the people having enabled ``Issue watching`` for the project (mechanism for them to opt-in into being in the CC list). Would this work in a GitLab world? - Answer: There are a number of options related to that. For one, users can control their notifications globally and by name space in a fine grained way (see GitLab Notification Emails). - Question: Fedora is part of GitLab’s Open Source program and we have a migration tracker issue that we are using to keep track of feature requests, bugs, etc that are important to Fedora. The Fedora migration team has been working with us at GitLab to maintain that and community members can add relevant issues there so we can track them. It’s also helpful for our product managers to hear about why particular issues are important for the Fedora use case, and to have upvotes, so doing that will help! Where can you submit requests/bugs/report issues? - Answer: Fedora Migration Tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/217350 Feature template: https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal Bug template: https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug Please do review the original questions doc in case I have missed any that relate to namespace and issue tracking and thank you again for your engagement with these emails! The next email topic will be on 'Branches'. Have a good week! Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
GitLab AMA Topic: Message Bus
Hi everyone, I hope you enjoyed the F33 release party this weekend! Getting back to the GitLab topic mail threads, this weeks topic from the GitLab AMA session on September 10th is on Message Bus. As always, here are some links to the resources I have been pulling content from as well: * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w * Chat log from session https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html * AMA Blog post https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 * Here is this email in hackmd if you wish to view it there: https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view ## Topic: Message Bus - Question: Fedora uses a message bus to integrate different parts of its infrastructure. How should we onboard GitLab into this message bus? - Answer: Currently we would need to have a service that proxies GitLab’s events to fedora-messaging something similar to github2fedmsg. There were some concerns raised about the order of events sent by GitLab’s webhooks, these will need to be looked after during a Proof of Concept stage. - Question: How would git push over http work with GitLab? (assuming gitlab does not have Fedora's password since they are stored in FAS) - Answer: GitLab has a good number of authentication options and integrations where the "best" solution usually depends on a team's specific needs and use case. As such, the best way to know and meet Fedora's needs and use cases is to have a conversation and discuss the options with GitLab. How does git push over HTTP work with FAS right now, and what git push (over HTTP) auth requirements/flow would you like to have for your projects in GitLab? These are the only two questions and answers I could gather relating to message bus from the AMA question sheet, however I know there was a lot of discussion regarding this topic during the AMA session itself, so if you would like to resume/kick off that conversation again, please feel free to use this email to discuss. A personal note and for full transparency: the weeks seem to be passing in the blink of an eye lately, I assume it's because I'm busy(?) but it might be just the weird 2020 vibe the world is on nowadays. I really don't know. Whatever the reason, there has been no further discussion with GitLab since early October-ish, but we will be returning to the conversation of how this migration could be technically possible soon, so sincerely thank you all again for engaging with us/me here as I found reading the discussion on permission and access much easier to follow and have been taking notes on your expectations to use that feedback in conversations with GitLab when we pick the discussion back up. I hope you all had a good weekend and will talk to you all next week when the topic of Namespace & Issue Tracking is sent! Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
OUTAGE NOTICE: 2021-03-24 1030 UTC - 2021-03-25 2000 UTC Approx
Hi all, The outage to facilitate the migration and deployment of the new Fedora Accounts system has begun. This outage is due to last until approx 2000 UTC tomorrow. Please check status.fedoraproject.orghttps://status.fedoraproject.org/ <http://status.fedoraproject.org> for affected services & outage ticket for more details https://pagure.io/fedora-infrastructure/issue/9747 Details of what to expect during this outage period can be found here https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/message/JGVRX7CSXSDJ2MV5TJNYPCGVWWI5XSNB/ The team working on this deployment can be contacted on freenode channel #fedora-aaa if you run into any serious issues. Thank you for your patience and understanding over the next two days while we complete this work, and we hope you experience minimal disruption. Kindest regards & many thanks, Aoife & The Fedora Accounts Team -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA <https://www.redhat.com> Communications House Cork Road Waterford <https://www.redhat.com> ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
Wiki https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm == Summary == pam_userdb was built with support for BerkeleyDB, but this project is no longer maintained as open source, so it is replaced by GDBM. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]] [[User:fjanus| Filip Janus]] * Email: ipedr...@redhat.com fja...@redhat.com == Detailed Description == Currently, the Fedora provided BerkeleyDB versions is 5.x, which has been unmaintained upstream for several years. BerkeleyDB v6.x is license incompatible, so moving to that version is not an option. The proposal is to switch to GDBM, which has upstream support and whose license is compatible with Fedora. == Feedback == This proposal contains manual steps to be executed by system administrators in the upgrade path. It is a risky point, as it relies on sysadmins reading the documentation, but it's the best solution so far. The database location is defined in the PAM stack, and the system administrator can set it to any value. Therefore, the only way to automate this would be to embed the database port in the PAM module code. But the port should be handled by libdb as this will allow it to concentrate all the effort on a single binary, which will do this job for other packages as well. An [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/HXK2RS7IBCRRYAQEYP2P66T6W4ONFBAZ/ email thread] was opened in Fedora devel to discuss this topic. Steve Grubb mentioned that this approach was used in the past to update other PAM modules. So even if the solution is not ideal, the best approach is to document the database porting process and let the system administrator run it manually. == Benefit to Fedora == * This change uses a database that is Fedora license compatible. * This changes uses an upstream maintained database version, with new features and bug fixing. pam_userdb controls user authentication, and a bug in the database could lead to a security vulnerability. == Scope == * Proposal owners: ** libdb includes a new subpackage libdb-convert-util, that provides db_converter, a program to port a BerkeleyDB database to GDBM. ** Change PAM database build option to GDBM. * Other developers: N/A * Release engineering: https://pagure.io/releng/issue/11649 * Policies and guidelines: Yes. Opened a [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == === Upgrade === * If the pam_userdb module is used by the system, then the user/sysadmin will have to run the conversion tool. This can't be done automatically because the database location is configurable, and the conversion tool will need manual intervention. === Compatibility === * pam_userdb module is mainly used in vsftpd environments. If this module is used by the system and the database isn't converted, then the user won't be able to authenticate in vsftpd environments. The user would still be able to authenticate using other methods (i.e. su, ssh) and run the conversion tool. == How To Test == * Run `db_converter` to convert the database. Example `db_converter --src /etc/vsftpd/login.db --dest /etc/vsftpd/login.gdbm` * vsftpd login * Check that the user is authenticated == User Experience == Users won't experience any change. == Dependencies == vsftpd depends on this change, but nothing needs to be done in this package. == Contingency Plan == * Contingency mechanism: Postpone to the next release. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. == Release Notes == pam_userdb switches database provider to GDM. [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 Instructions on how to update in the System Administrator’s Guide] -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F40 Change Proposal: Dropping sshd.socket file (Self Contained)
The discussion thread is now available for feedback at https://discussion.fedoraproject.org/t/f40-change-proposal-drop-sshd-socket-self-contained/89604/1 ___ 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: F40 Change Proposal:PHP 8.3 (Self Contained)
The discussion thread to provide feedback on this proposed change can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-php-8-3-self-contained/89611/1 ___ 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 Change Proposal: Drop Delta RPMs (System-Wide)
fications to /etc/dnf/dnf.conf. However, since the repositories will no longer contain Delta RPMs, this configuration change is not strictly required. Alternatively, the default dnf / dnf5 configuration could be changed at the code level instead of changes to configuration files. == How To Test == Users should be able to verify that support for Delta RPMs is disabled in dnf on Fedora 40, for example by checking for deltarpm = 0 in the output of dnf config-manager --dump | grep deltarpm. == User Experience == Users who upgrade their systems with GNOME Software (or other similar tools) should not be affected by this change, other than faster and smaller repository metadata downloads. Users who upgrade via dnf / dnf5 should see a similar improvement. Additionally, there will be no more wasted downloads due to failed reassembly of RPMs from Delta RPMs. == Dependencies == * Release Engineering changes (modifications of the compose process) * dnf / dnf5 package changes (disabling deltarpm support, either via configuration changes, or changing the default from true to false in the code itself) == Contingency Plan == * Contingency mechanism: If the compose configuration cannot be modified to skip generation of Delta RPMs in time for Fedora 40, changing the default configuration in dnf / dnf5 will still cause some of the benefits outlined above (except for those caused by the smaller repository metadata sizes). If the default dnf configuration cannot be changed in time for Fedora 40, the benefits outlined above should still apply in almost all circumstances. If neither changes can be implemented in time, the change can be postponed to the next Fedora release without causing problems. * Contingency deadline: Fedora 40 Beta Freeze * Blocks release? No == Documentation == N/A == Release Notes == As of Fedora 40, package repositories no longer contain Delta RPMs, and package managers (dnf, dnf5) have disabled support for deltarpms by default. They are not useful in many common circumstances (i.e. upgrades via GNOME Software or on OSTree based variants), and often no longer even cause less data to be downloaded for upgrades. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/Passim_P2P_Metadata 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 == Passim is a local caching server that broadcasts specific shared metadata to other clients on your local network to reduce the amount of duplicate data downloaded from the internet. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Much of the software running on your computer that connects to other systems over the Internet needs to periodically download metadata or information needed to perform other requests. Everybody downloads the same file from a CDN, and although a CDN is not super-expensive, it's certainly not free. Everybody on your current network (perhaps thousands of users) has to download the same 1MB blob of metadata from a CDN over a perhaps-expensive internet link. What if we could download the file from the CDN on one machine, and the next machine on the local network that needs it instead downloads it from the first machine? We could put a limit on the number of times it can be shared, and the maximum age so that we don't store yesterday's metadata forever, and so that we don't turn a ThinkPad X220 into a machine distributing 1Gb/s to every other machine in the office. We could cut the CDN traffic by at least one order of magnitude, but possibly much more. This is better for the person paying the cloud bill, the person paying for the internet connection, and the planet as a whole. == Feedback == IPFS is an existing project that's existed for many years and allows sharing with other users not on your local network. It's not packaged in any distributions and not trivial to install correctly. Its main drawback is that it requires an internet to IPFS "gateway" which costs a large amount of money for the LVFS, and that it's not EAR/ITAR compliant. I've asked for feedback already on fedora-devel and have already started making changes and suggestions from that discussion -- for instance splitting out a -libs subpackage. See https://www.spinics.net/lists/fedora-devel/msg315078.html for the discussion. == Benefit to Fedora == Fedora will consume less bandwidth when checking for firmware updates. Per user there is only a 2MB/day saving, but for millions of Fedora users this adds up to a huge amount of saved data (and money) globally. == Scope == The code is already written, tested and ready to go. The passim package is already included in Fedora (although not installed by default) and fwupd needs an upstream release which includes this functionality -- which is scheduled for 2 weeks time. == Upgrade/compatibility impact == Old versions of fwupd will be updated and start sharing metadata with other local users with no changes required. == How To Test == Install two physical machines or VMs with Fedora 40 that are both on the local network. Run `fwupdmgr refresh` on the first, and observe that `passim dump` or `https://localhost:27500/` lists the published metadata file . Then run `fwupdmgr refresh --verbose` on the second machine and see that the file is downloaded from https://localhost:27500 rather than `cdn.fwupd.org`. Avahi needs to be enabled and running, as does `passimd` although both are autostarted as required. == User Experience == Each user will use 2MB less bandwidth per day when there are other users on the local network with the same metadata file. There is no user-visible difference to any operation. == Dependencies == None; fwupd will recommend passim to be installed by default and autolaunch it as required. == Contingency Plan == Change `Recommends: passim` to `Suggests: passim` in the `fwupd.spec` file so that it's not autoinstalled by default. In this case fwupd will fall back to downloading from the CDN every day. == Documentation == * https://github.com/hughsie/passim/blob/main/README.md == Release Notes == Fedora now uses a peer-to-peer service called Passim to reduce the amount of bandwidth used when downloading metadata. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
The discussion thread is now available for feedback on this proposed change here https://discussion.fedoraproject.org/t/f40-change-proposal-switch-pam-userdb-from-berkeleydb-to-gdbm-system-wide/89606/1 ___ 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 Change Proposal:PHP 8.3 (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/php83 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 the PHP stack in Fedora to the latest version 8.3.x == Owner == * Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]] * Email: remi at fedoraproject dot org == Current status == * A testing SCL and a testing module are available in my [https://blog.remirepo.net/post/2023/08/31/PHP-on-the-road-to-the-8.3.0-release repository] * List of [https://github.com/remicollet/remirepo/issues/237 extensions compatibility list] * [https://wiki.php.net/todo/php83 Upstream schedule for 8.3] First RC is planed for August 31th, GA is planed for November 23th. == Detailed Description == Update the PHP stack in Fedora to latest version 8.3.x. Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice for some years: * 2 Fedora cycles for each PHP minor release (exceptions below) * 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time before next major * 1 Fedora cycle for first major (e.g. 7.0 or 8.0) Fedora 37 has PHP 8.1, Fedora 38 and 39 have PHP 8.2. == Benefit to Fedora == Provides the latest PHP version to developers and system administrators. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group] * install and play with your web applications == User Experience == Developers and system administrators will have the great benefit or running the latest PHP version. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING UPGRADING] * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING.INTERNALS UPGRADING.INTERNALS] == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F40 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
The discussion thread for feedback on this change proposal can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-passim-peer-to-peer-metadata-self-contained/89608/1 ___ 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: F40 Change Proposal: Drop Delta RPMs (System-Wide)
The discussion thread is now available a thttps://discussion.fedoraproject.org/t/f40-change-proposal-drop-delta-rpms/89601/1 for feedback ___ 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 Change Proposal: Dropping sshd.socket file (Self Contained)
== Summary == The sshd.socket behavior may cause the remote DoS and require a manual intervention to make the server accepting the ssh connections back. sshd.service doesn't have these downsides == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == A while ago, a dropping the sshd.socket from the openssh package was suggested in [https://bugzilla.redhat.com/show_bug.cgi?id=2025716 BZ#2025716] as there are several shortcomings with this approach that could lead to situations where users would lose access to a system while under DoS or memory pressure. This change was implemented in rawhide & f39 and discussed on the devel list in a [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. This change was reverted in f39 according to the [https://pagure.io/fesco/issue/3062 FESCO decision]. == Feedback == The change as implemented does not include a migration path for existing users of the sshd.socket unit to the sshd.service unit. We need some migration path, also suitable for OSTree This means that systems updating from 38 to 39 and relying on sshd.socket for openssh access to the system will end up unreachable via SSH. This is notably important for Fedora CoreOS where we will automatically update systems to the next Fedora version shortly after the release: https://github.com/coreos/fedora-coreos-tracker/issues/1558 We think this change needs to get more visibility and should go through the change process and be evaluated for inclusion in Fedora 40. See also the mentioned before [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. == Benefit to Fedora == This change will prevent remote DoS in the case the sshd.socket is activated. == Scope == * Proposal owners: the migration scriptlet is the best solution. * Other developers: check the dependencies on sshd.socket * 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 Community Initiatives: N/A == Upgrade/compatibility impact == The worst case the remote access to the system will be lost of sshd.socket is enabled and the system is not switched to using sshd.service before upgrade == How To Test == Enable sshd.socket Upgrade Check remote access over sshd == User Experience == See "Benefit for Fedora" == Dependencies == == Contingency Plan == Reverting the change * 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 == The change should be mentioned in the Release Notes. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Change Proposal: KDE Plasma 6 (System Wide)
fedora-kde/SIG/issue/383 pagureio#fedora-kde/SIG#383]) *** Ensure kwin-x11 is obsoleted by kwin-wayland *** Ensure plasma-workspace-x11 is obsoleted by plasma-workspace-wayland ** Modify select KDE Frameworks 5 packages to be co-installable with KDE Frameworks 6 [https://community.kde.org/Plasma/Plasma_6#Coinstallability per upstream guidance]. ** Enable tracking the Plasma 6 stack in ELN for branching to EPEL 10 once CentOS Stream 10 is available. * Other developers: ** Optional: Packagers with software that can choose to build against either Qt 5 or Qt 6 should make the switch to Qt 6. Community maintenance of Qt 5 will be drastically reduced once KDE Plasma 6 is released. * Release engineering: [https://pagure.io/releng/issue/11669 #11669] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Fedora Linux users using Plasma X11 upgrading to Plasma 6 will find themselves switched to Plasma Wayland automatically as the X11 session will no longer be available. The KDE SIG strives to ensure the upgrade path is smooth for all users. Configuration files will be migrated automatically after first login to Plasma 6. == How To Test == A COPR with pre-release versions of Plasma 6 will be available from the KDE SIG in the near future. At the moment, we have a [https://copr.fedorainfracloud.org/coprs/g/kdesig/kde-nightly-qt6/ KDE Plasma 6 nightly COPR] containing snapshot builds in various states. It is strongly advised that testing is done in a non-production environment using a Fedora spin that doesn't include and use KDE Frameworks at all (such as [https://fedoraproject.org/spins/budgie/ the Fedora Budgie Spin]) as the packages are unstable and are not co-installable with any Qt5+KF5 based environment at all. Once packages are integrated into Rawhide, users should grab [https://openqa.fedoraproject.org/nightlies.html nightly composes] of the Fedora KDE Spin and Fedora Kinoite to try it out. == User Experience == The user experience provided by KDE Plasma 6 will not be significantly different from what users expect from KDE Plasma 5. The main change will be the removal of the X11 session, as everyone will be transitioned to the Wayland experience. == Dependencies == Plasma 6 depends most notably on Qt 6 and KDE Frameworks 6 packages. Qt 6 is already available in Fedora Linux, and KDE Frameworks 6 is in the process of being imported. == Contingency Plan == * Contingency mechanism: KDE SIG will roll back the Plasma Desktop and Plasma Mobile packages to KDE Plasma 5. Doing so will require epoch bumps across the stack. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == There is not yet upstream release notes for Plasma 6.0, as it is not released yet. * [https://community.kde.org/Plasma/Plasma_6 Developer documentation tracking progress on Plasma 6.0] == Release Notes == Fedora Linux now ships KDE Plasma 6.0, a new major version of the KDE user experience from the KDE community. As part of this change, KDE Plasma on Fedora Linux runs on the Wayland display technology. X11 applications are still supported on KDE Plasma. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F40 Change Proposal: KDE Plasma 6 (System Wide)
The discussion thread to provide feedback for this change proposal can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/1 ___ 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 Change Proposal: Ruby 3.3 (System-Wide)
134 == Contingency Plan == * Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 3.3. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 3.2 and its dependencies stays intact. The tag would be merged into F40 after everything is rebuild. * Contingency deadline: Mass Rebuild * Blocks release? No == Documentation == * [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language] * [https://github.com/ruby/ruby/blob/master/NEWS.md Ruby 3.3.0 NEWS] * [https://www.ruby-lang.org/en/news/2023/09/14/ruby-3-3-0-preview2-released/ Ruby 3.3.0-preview2 release announcement] == Release Notes == * The Ruby 3.3 bumps soname, therefore Ruby packages, which use binary extensions, should be rebuilt. Nevertheless, since upstream paid great attention to source compatibility, no changes to your code are needed. https://github.com/ruby/ruby/blob/master/NEWS.md -- 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 Change Proposal: Tuned Replaces Power-profiles-daemon (Self-Contained)
t == Both the tuned and the power panel need to be modified to integrate both. == How To Test == == User Experience == 1. The workstation user can set the power profile through gnome-control-center. Moreover, an advanced power profile dialog will be shown if the users would like to finetune the system. 2. The server users switch the profile through the commandline or GNOME desktop if it is installed. == Dependencies == 1. tuned is written by Python so it depends on python packages and its 40 packages. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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 39 Final is GO
The Fedora Linux 39 Final RC 1.5 compose is GO and will be shipped live on Tuesday, November 7th 2023. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2023-11-02/f39-final-go_no_go-meeting.2023-11-02-17.04.html [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-11-02/f39-final-go_no_go-meeting.2023-11-02-17.04.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
F40 Change Proposal: Build Fedora with DNF5 (Self-Contained)
Wiki Link: https://fedoraproject.org/wiki/Changes/BuildWithDNF5 = Build Fedora with DNF 5 = == Summary == We are proposing to change the Mock configuration in Mock (mock-core-configs), Koji, and Copr to use DNF 5 as Mock's package manager instead of DNF 4. DNF 5 would be used by Mock to install build dependencies into chroots for package builds. This change is related to the build infrastructure and is distinct from changing the default package manager in Fedora. == Owner == * Name: [[User:egoode| Evan Goode]] * Email: ego...@redhat.com * Name: [[User:praiskup| Pavel Raiskup]] * Email: prais...@redhat.com == Detailed Description == DNF 5 is a new package manager intended to replace DNF: https://dnf5.readthedocs.io/en/latest/about.html. It offers significant performance improvements over DNF while achieving lower memory usage and disk footprint. The switch to DNF 5 was originally planned for Fedora 39, but it's been postponed to (likely) Fedora 41: https://pagure.io/fesco/issue/3039. In the meantime, we would like to start building Fedora with DNF 5. The set of package management features that Mock needs for setting up buildroots is small compared to the full capabilities of DNF, so it's a good place to start deploying DNF 5. We will be able to test the stability of DNF 5 at a large scale and gather data about its performance. The Mock developers have been working alongside the DNF 5 developers for a while to ensure Mock can use DNF 5, per this tracking issue: https://github.com/rpm-software-management/mock/issues/894. The two remaining items on that issue are "optional" items that are not blocking this proposed change. == Feedback == == Benefit to Fedora == With the switch to DNF 5 as the default package manager on the horizon, the build infrastructure offers an opportunity to subject a crucial subset of DNF 5's features to heavy testing. This change will let us verify that every build dependency in the distribution is installable by DNF 5. In addition, we expect a substantial performance improvement for package builds that spend a significant portion of their time installing build dependencies. Larger, compilation-heavy packages likely won't see much improvement; the difference will be most apparent when building many smaller packages. Switching the build system over to DNF 5 will let us measure the performance improvement over DNF across a wide variety of install transactions. == Scope == * Proposal owners: The work to support DNF 5 in Mock is done already. This change should be as simple as setting the Mock option `config_opts['package_manager'] = 'dnf5'` in Mock, Koji, and Copr for F40+ builds (Koji config option exists from the `yum -> dnf4` era). The `dnf5` doesn't necessarily have to be installed on building hosts - in such a case, Mock will automatically use `/bin/dnf-3` (DNF4) from the host to install DNF5 into the bootstrap chroot, to further use *that* DNF5 for build chroot installation. * Other developers: * Release engineering: https://pagure.io/releng/issue/11737 * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == There are no special steps needed to test the change after it happens (updated `mock-core-configs` package is installed on your host), just enjoy the installation speedup. There's a way to test this on Fedora 37+ or EPEL8+ host (builder) in advance. Considering you want to build SRCRPM like `mock -r fedora-40-x86_64 your.src.rpm`, you can do this instead: 1. `mock -r fedora-40-x86_64 --scrub=all` (mandatory step to cleanup DNF4 from all caches) 2. `mock -r fedora-40-x86_64 --config-opts=package_manager=dnf5 your.src.rpm` (DNF5 is installed and cached in bootstrap) 3. `mock -r fedora-40-x86_64 --scrub=all` (to invalidate caches again) == User Experience == This change will mostly be invisible to users. The builds, namely the buildroot preparation, will be much faster. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the F40 Mock configuration in Koji and Copr back to using `dnf` (5-minute work). * Contingency deadline: F40 Beta freeze * Blocks release? Yes == Documentation == == 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
F40 Change Proposal: DNFConditionalFilelists (System-Wide)
for filelists level dependencies. == Dependencies == No changes should be required for any package depending on DNF to implement this behavior. == Contingency Plan == * Contingency mechanism: Change the configuration option to download the filelists by default * Contingency deadline: Branch Fedora Linux 40 from Rawhide * Blocks release? No == Documentation == Links to the relevant DNF CLI and API documentation sections will be provided here once the related pull request is created. == 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
F40 Change Proposal: Removing OpenSSL 1.1 package (System-Wide)
Wiki Link: https://fedoraproject.org/wiki/Changes/RemoveOpensslCompat Discussion.fpo Link: https://discussion.fedoraproject.org/t/f40-change-proposal-removing-openssl-1-1-package-system-wide/92899 == Summary == We are going to remove the openssl1.1 package from Fedora 40. == Owner == * Name: [[User:DmitryBelyavskiy| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == In Fedora 36 we switched to OpenSSL 3.0 branch. This is a brand new version with new architecture. We left the openssl1.1 package for the applications that were unable to switch to the new API/architecture, 3rd-party applications, etc. The package was marked as deprecated in F37. OpenSSL 1.1.1 has reached EOL in September 2023. We want to remove it from Fedora. == Feedback == == Benefit to Fedora == This proposal ensures than no new packages in Fedora will use the deprecated OpenSSL version that will cause an overall increase of security/stability. It will also reduce the maintenance burden for the OpenSSL maintainers, especially when new CVEs are published. == Scope == * Proposal owners: provide assistance in migration to other developers. * Other developers: Patch their packages to work with OpenSSL 3.0. * Release engineering: This feature doesn't require coordination with release engineering. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == 3rd-party packages depending on OpenSSL 1.1.1 should be replaced with new versions using new OpenSSL 3.0+. == How To Test == OpenSSL 1.1 should not be available to install from Fedora repository. No packages should depend on OpenSSL 1.1.1. == User Experience == Shouldn't be affected. == Dependencies == We have found at least the following packages depending on OpenSSL 1.1: * gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm * opensmtpd-6.8.0p2-12.fc39.src.rpm * python3.6-3.6.15-20.fc39.src.rpm == Contingency Plan == None. * Contingency mechanism: (What to do? Who will do it?) Package owners should update their packages to remove the dependency * Contingency deadline: beta freeze * Blocks release? Yes == Documentation == Should be mentioned in Release Notes. == Release Notes == openssl1.1 package is removed and should not be used by any packages. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Change Proposal: Update to Pydantic Version 2 (Self-Contained)
Wiki Link: https://fedoraproject.org/wiki/Changes/Update_To_Pydantic_Version_2
Discussion.fpo Link:
https://discussion.fedoraproject.org/t/f40-change-proposal-update-to-pydantic-version-2-self-contained/92894
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 ==
{{package|python-pydantic}}, a Python data validation library, will be
updated from 1.10.z to 2.y.z.
The Change owners will perform a test rebuild and work with package maintainers
and upstreams to port code.
== Owner ==
* Name: Maxwell G; Benjamin Beasley; Python SIG
* Email: maxw...@gtmx.me; c...@musicinmybrain.net;
python-de...@lists.fedoraproject.org
== Detailed Description ==
Pydantic is a Python data validation library.
Recently, upstream released major version 2 with many fixes and performance
improvements but also multiple breaking API changes.
The new release relies on {{package|python-pydantic-core}}, which provides the
core validation and serialization functionality used by pydantic v2.
pydantic-core is a Rust PyO3 Python extension module.
We will update pydantic to version 2 after making sure dependent packages are
accounted for.
=== Porting strategies ===
Pydantic v2 contains some breaking API changes that may require porting if
packages depend on old functionality.
Upstream provides a detailed
[https://docs.pydantic.dev/latest/migration/ Migration Guide] that describes
the breaking API changes.
Projects that are not ready to port to pydantic v2 may use the
pydantic.v1
compatibility module which contains a full copy of the old pydantic v1 code.
https://github.com/matrix-org/synapse/pull/16332 exemplifies this approach.
As shown in the above PR, projects can use conditional imports to import
pydantic.v1 if pydantic v2 is in use and otherwise fall
back to importing
pydantic if pydantic v1 is in use.
Maintaining compatibility for both pydantic v1 and v2 in the same codebase
without the compatibility module is possible but may not be practical for
larger, more complex usecases.
fedrq
[https://git.sr.ht/~gotmax23/fedrq/commit/35d64cd2a8bd0ea8210d8b086e14e3d66611dc06
uses this approach]
and silences pydantic.PydanticDeprecatedSince20 warnings.
Many of these deprecation warnings cannot be resolved without dropping support
for pydantic v1.
== Feedback ==
I did not receive much feedback as of yet, but I expect this change to
be uncontroversial.
== Benefit to Fedora ==
Fedora will have the latest version of pydantic in its repositories.
The new version touts a significant performance boost, amongst other
improvements.
== Scope ==
* Proposal owners:
** Preform an [https://hackmd.io/@python-maint/rJSm5WC9Y impact check]
** Make an inventory of failures or packages that have a hard
dependency on pydantic v1.
** Submit distgit PRs and/or file upstream issues to fix
incompatibilities in dependent packages
** Submit new python-pydantic-settings and python-pydantic-extra-types
packages for review
** Wait two weeks for packagers to review PRs. Those that remain
compatible with pydantic v1 can be merged immediately.
** Build pydantic v2 package and any outstanding PRs in a side tag.
* Other developers:
** Test your package to ensure it still builds and functions with pydantic v2
** Help with package reviews
** Review distgit PRs to fix incompatibilities
== Upgrade/compatibility impact ==
Pydantic version 2 has some breaking API changes.
See upstream's [https://docs.pydantic.dev/latest/migration/ Migration Guide].
== How To Test ==
You can perform test builds like this:
$ copr mock-config gotmax23/pydanticv2-testing fedora-rawhide-x86_64 >
~/.config/pydanticv2.cfg
$ fedpkg --release=rawhide mockbuild --root pydanticv2
== User Experience ==
This isn't a particularly user visible change. Users of Python applications
that utilize Pydantic should notice a performance improvement.
== Dependencies ==
See https://gtmx.me/Wiki/Fedora/pydantic-v2-update/#lists for a list of
dependent packages.
The Change owners will work with these packages' maintainers to ensure the
packages remain functional with the new pydantic version.
== 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 ==
See https://gtmx.me/Wiki/Fedora/pydantic-v2-update/ for the current status and
notes.
== Release Notes ==
python3-pydantic was updated from 1.10.z to 2.y.z. Pydantic v2 brings
performance improvements and an API refactoring, amongst other changes.
See upstream's [https://docs.pydantic.dev/latest/migration/ Migration Guide]
for a full inventory of breaking changes.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterf
F41 Change Proposal: Python3.13 (System-Wide)
be available to
help with fixing issues.
* Release engineering: [https://pagure.io/releng/issue/11728 #11728]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
All the packages that depend on Python 3 must be rebuilt. User written
Python 3 scripts/applications may require a small amount of porting,
but mostly Python 3.12 is forward compatible with Python 3.13.
== How To Test ==
Interested testers do not need special hardware. If you have a
favourite Python 3 script, module, or application, please test it with
Python 3.13 and verify that it still works as you would expect. If the
application you are testing does not require any other modules, you
can test it using {{package|python3.13}} even before this change is
implemented, in Fedora 37, 38, 39 or 40.
In case your application requires other modules, or if you are testing
an rpm package, it is necessary to install the 3.13 version of the
python3 rpm. Right now that rpm is available in copr, along with all
other python packages that build successfully with python 3.13. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/ for
detailed instructions on how to enable Python 3.13 copr for mock.
Once the change is in place, test if your favorite Python apps are
working as they were before. File bugs if they don't.
== User Experience ==
Regular distro users shouldn't notice any change in system behaviour
other than the Python 3 interpreter will be in version 3.13.
== Dependencies ==
4400+ packages depend on Python 3 and ~4000 packages need rebuilding
when Python is upgraded. See scope section.
== Contingency Plan ==
* Blocks release? Yes, we'd like to block Fedora 41 release on at
least 3.13.0rc1
== Documentation ==
[https://peps.python.org/pep-0719/ Python 3.13 Release Schedule]
[https://docs.python.org/dev/whatsnew/3.13.html#what-s-new-in-python-3-13
What's new in 3.13]
[https://docs.python.org/dev/whatsnew/3.13.html#porting-to-python-3-13
Porting to Python 3.13]
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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 Change Proposal: PostgreSQL 16 (Self-Contained)
** pg_repack == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No Revert the changes and provide PostgreSQL 15 only. == Documentation == Upgrade strategy: https://www.postgresql.org/docs/16/upgrading.html N/A (not a System Wide Change) == Release Notes == Release notes for PostgreSQL 16 release: https://www.postgresql.org/docs/16/index.html Overall overview of the changes and improvements: https://www.postgresql.org/docs/16/release-16.html -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Change Propsal: BogofilterSqlite (Self- Contained)
Wiki Link: https://fedoraproject.org/wiki/Changes/BogofilterSqlite Discussion.fpo link: https://discussion.fedoraproject.org/t/f40-change-proposal-switch-bogofilter-to-use-sqlite-self-contained/92809 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 == Switch bogofilter to use SQLite as its database engine, rather than Berkeley DB (libdb). == Owner == * Name: [[User:mikep| W. Michael Petullo]] * Email: m...@flyn.org == Detailed Description == Switch bogofilter to use SQLite as its database engine, rather than Berkeley DB (libdb). Another change (https://fedoraproject.org/wiki/Changes/Libdb_deprecated) marked libdb as deprecated, and that change lists bogofilter as a dependency. Thus this change fixes another application to avoid the deprecated libdb. == Benefit to Fedora == Fedora will have one less dependency on the deprecated libdb package. Additionally, other distributions have already migrated to SQLite, and this will allow sharing word lists with those distributions. For example, perhaps a workstation running Fedora generates wordlist.db before installing it on another computer running Alpine and acting as a server. == Scope == * Proposal owners: Merge pull request https://src.fedoraproject.org/rpms/bogofilter/pull-request/2. This makes the database backend conditional, with SQLite being the default. Support for libdb can be conditionally compiled to create a migration tool capable of migrating existing libdb databases to SQLite. * 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 Community Initiatives: Support [https://fedoraproject.org/wiki/Changes/Libdb_deprecated Mark libdb as deprecated] == Upgrade/compatibility impact == Bogofilter can support only one database backend at a time, and thus a new SQLite bogofilter package will be unable to process libdb data. Thus the new package provides a migration script. == How To Test == This test generates a word list and migrates it to work with the new SQLite backend. Install original bogofilter and add at least one word to its database, for example with: echo abc | bogofilter --bogofilter-dir=/tmp/bftest/ --register-spam Bogofilter will create the directory `/tmp/bftest/`, and it will contain a `wordslist.db` file. To verify the word had been added run: bogoutil -d /tmp/bftest/wordlist.db Install the updated bogofilter and migrate the existing libdb database with: bogomigrate-berkeley /tmp/bftest/wordlist.db This tool will print whether the migration succeeded. Verify the "abc" word is present in the newly created SQLite database with: bogoutil -d /tmp/bftest/wordlist.db == User Experience == == Dependencies == N/A (not needed for this Change) == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == The bogofilter package switched its database engine from Berkeley DB (libdb) to SQLite because Fedora deprecated libdb. Users can migrate their word lists manually with `bogomigrate-berkeley ~/.bogofiler/wordlist.db`. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)
doing "dnf install mysql" (and other sub-packages) '''Drop cross-installation functionality''' * Users relying on this atypical setup don't have any clear upgrade path ** Such cases should only happen on development setups, which is solvable with containers or similar semi-isolation '''Switch to the versioned layout of MariaDB and MySQL packages''' * Nothing I can think of '''Introduce MariaDB 10.11 and MySQL 8.1''' * Nothing I can think of '''Change the default MariaDB version in Fedora from 10.5 to 10.11''' * https://mariadb.com/kb/en/changes-improvements-in-mariadb-106/ ** TokuDB has been removed *** As a result, the sources can be stopped to be modified downstream to strip problematically licensed code, and pure upstream tarball can be used instead ** The utf8 character set (and related collations) is now by default an alias for utf8mb3 rather than the other way around. It can be set to imply utf8mb4 by changing the value of the old_mode system variable * https://mariadb.com/kb/en/changes-improvements-in-mariadb-107/ ** New UUID data type * https://mariadb.com/kb/en/changes-improvements-in-mariadb-108/ * https://mariadb.com/kb/en/changes-improvements-in-mariadb-109/ * https://mariadb.com/kb/en/changes-improvements-in-mariadb-1010/ ** --ssl option set as default for mariadb CLI * https://mariadb.com/kb/en/changes-improvements-in-mariadb-1011/ == How To Test == '''Drop builds for i686 architecture''' * i686 builds doesn't exist anymore '''Rename package 'community-mysql' to 'mysql' ''' and '''Stop providing 'mysql' symbols by package 'mariadb * The package 'mariadb' will no longer be installed preferably instead of package 'mysql' when doing "dnf install mysql" (and other sub-packages) * Using names 'mariadb' and 'community-mysql' leads to the same results as before '''Drop cross-installation functionality''' * Cross-installation not allowed anymore '''Switch to the versioned layout of MariaDB and MySQL packages''' * Test updates, upgrades, re-installs, etc. ** Users should get the same functional results as before with the same names as before, while having differently named packages present on the system '''Introduce MariaDB 10.11 and MySQL 8.1''' * Test upgrades / downgrades between versions '''Change the default MariaDB version in Fedora from 10.5 to 10.11''' * Test upgrades / downgrades between versions == User Experience == '''Drop builds for i686 architecture''' * i686 functionality lost (server only) '''Rename package 'community-mysql' to 'mysql' ''' and '''Stop providing 'mysql' symbols by package 'mariadb * The package 'mariadb' will no longer be installed preferably instead of package 'mysql' when doing "dnf install mysql" (and other sub-packages) ** Otherwise should not be noticeable to the user '''Drop cross-installation functionality''' * Cross-installation functionality lost '''Switch to the versioned layout of MariaDB and MySQL packages''' * Users should get the same functional results as before with the same names as before, while having differently named packages present on the system * Functionality lost by Modularity retirement recovered '''Introduce MariaDB 10.11 and MySQL 8.1''' * New stuff that users wait for, yay \o/ ! '''Change the default MariaDB version in Fedora from 10.5 to 10.11''' * Latest upstream LTS version, awaited by the users ** https://mariadb.com/kb/en/upgrading-from-mariadb-10-5-to-mariadb-10-6/ ** https://mariadb.com/kb/en/upgrading-from-mariadb-10-6-to-mariadb-10-11/ == Dependencies == Only the i686 removal should be blocked by other packages. All other packages should keep working as they do. == Contingency Plan == '''Drop builds for i686 architecture''' * I'll try in F41 again '''Rename package 'community-mysql' to 'mysql' ''' and '''Stop providing 'mysql' symbols by package 'mariadb * Revert '''Drop cross-installation functionality''' * Revert '''Switch to the versioned layout of MariaDB and MySQL packages''' * Revert '''Introduce MariaDB 10.11 and MySQL 8.1''' * I'll try in F41 again '''Change the default MariaDB version in Fedora from 10.5 to 10.11''' * Revert to the MariaDB 10.5 as the system default, but keep MariaDB 10.11 parallel available in the repository. Fix issues and try in F41 again. == Documentation == Let this document and the linked resources be the documentation. == Release Notes == Will be added later in the process, according to the changes applied -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 Final is GO
The Fedora Linux 38 Final RC 1.6 compose is GO and will be shipped on Tuesday, 18 April. For more information please check the Go/No-Go meeting minutes[1][2] or log[3][4]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-13/f38_final_gono-go_meeting.2023-04-13-17.05.html [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-14/f38_final_gono-go_meeting_continued.2023-04-14-00.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-13/f38_final_gono-go_meeting.2023-04-13-17.05.log.html [4] https://meetbot.fedoraproject.org/fedora-meeting/2023-04-14/f38_final_gono-go_meeting_continued.2023-04-14-00.00.log.html -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA <https://www.redhat.com> Communications House Cork Road Waterford <https://www.redhat.com> ___ 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 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
to publish a separate document detailing how to set up and configure a metrics server for testing purposes, how to redirect metrics to the custom server, and how to force the client to immediately submit metrics to ease testing. Although we don't actually expect many community members to seriously run their own metrics servers, we still want to document the steps involved so that interested developers can see exactly how it works. == User Experience == A new metrics collection setting will be added to the privacy page in gnome-initial-setup and also to the privacy page in gnome-control-center. This setting will be a simple toggle that will enable or disable all metrics upload for the entire system. Users who do not want any metrics upload should feel confident that uploading can be disabled with a simple toggle. Fedora users should be confident that Fedora metrics collection respects their privacy and collects only limited, anonymous usage data. == Dependencies == Any package that wishes to collect a metric would need to depend on eos-metrics. For example, if we were to collect statistics on which system settings panels are used most frequently, then 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: We would need to 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? Yes, if the change is incomplete, it will need to be reverted before release. == Documentation == This feature will depend on several different upstream projects with varying amounts of documentation. The client side consists of eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation. The best documentation of eos-metrics available online is its [https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metrics.xml D-Bus interface XML]. eos-metrics also contains normal API documentation that will be built and installed in a docs subpackage, but this is not currently available online. The eos-event-recorder-daemon and eos-metrics-instrumentation components do not appear to have any online documentation. On the server end, the metrics server consists of azafea-metrics-proxy feeding metrics into redis, where they will be pulled by azafea and then added to a Postgres database. Documentation for [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source azafea-metrics-proxy] and [https://github.com/endlessm/azafea/tree/master/docs/source azafea] can be reviewed online. [https://azafea.readthedocs.io/en/latest/events.html Events recognized by the server are documented here.] Note that 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. This change proposal does not propose to enable sending any particular events in Fedora. == Release Notes == Release Notes are not required for initial proposal. We need to write the release notes before change freeze. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Indic Noto fonts (System-Wide)
https://fedoraproject.org/wiki/Changes/Indic_Noto_fonts 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 == Google Noto fonts for Indic (Indian) languages replace the default Lohit fonts == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: * Name: Sudip Shill * Email: == Detailed Description == Currently the Lohit fonts are installed and used by default for Indian languages (Indic scripts). However the Lohit project is essentially inactive and at best in maintenance mode now. So we will change the default to Google's Noto Indic fonts, which are available in both Sans and Serif faces with multiple weights and as variable fonts. This should provide a more flexible modern maintained set of fonts for Indic language scripts. == Feedback == There was some [https://lists.fedoraproject.org/archives/list/fo...@lists.fedoraproject.org/thread/LEFRXQCTXXRENR3GJW3NERVPGQNMYDZZ/ initial discussion on fonts list, etc], which was generally positive. This started with: * comparison screenshots: https://sshil.fedorapeople.org/lohit-vs-noto-comparison.html * a copr repo for testing: http://copr.fedorainfracloud.org/coprs/sshil/indic-fonts-test == Benefit to Fedora == Wider range of Indic (Indian) fonts will be available by default as variable fonts in both sans and serif faces with various weight styles. == Scope == * Proposal owners: ** update Indic langpacks (default-fonts) to use Noto fonts ** update the Noto and Lohit fonts packages so that Noto Indic fonts have higher priority ** change comps @fonts (through default-fonts) from Lohit to the corresponding Noto Indic fonts ** update ostree desktops to use Noto Indic ** update lorax to use Noto for Indic fonts * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/11502 #11502] * 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 == Lohit fonts will continue to be available, but assuming the [https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling default-fonts] Change is implemented users will be moved to use Noto Indic fonts by default on upgrade. Nevertheless advanced users can use `fonts-tweak-tool` to change the priority of one or more Lohit fonts to be higher than Noto if they so wish. == How To Test == * install/test default/Noto fonts on various desktops and their applications * test Noto Indic with and without Lohit fonts installed * test rendering of Indic scripts in applications/websites * test upgrades from Fedora 38 * test if removing Noto Indic (and (re-)installing Lohit) still allows using Lohit as a second default. * (advanced) revert the font priorities using the user fonts-tweak-tool. == User Experience == == Dependencies == Not really a direct dependency, but we currently plan to implement this using the new `default-fonts` metapackages. == Contingency Plan == * Contingency mechanism: Change owners will revert the changes back to using Lohit by default * Contingency deadline: before final freeze * Blocks release? Yes == Documentation == https://sshil.fedorapeople.org/lohit-vs-noto-comparison.html == Release Notes == Google Noto fonts are now installed and used for Indic scripts (Indian language) by default instead of Lohit fonts. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Color Bash Prompt (System Wide)
https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt == Summary == Introduce a default colored prompt for Fedora's default shell bash. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: == Detailed Description == For a long time the Fedora default shell prompt has been monochrome, which makes it difficult to find shell prompt commands between long command outputs when scrolling through terminal shell output. This Change introduces a simple default colored shell prompt, which users can also easily theme themselves. [https://petersen.fedorapeople.org/color-bash-prompt.png screenshot of color bash prompt in gnome-terminal] == Feedback == Initial [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/B5AJS3FIIPMF3KNWM7HRUNI7ISA2AKBR/#B5AJS3FIIPMF3KNWM7HRUNI7ISA2AKBR devel list discussion thread] There seems to be a general desire to have a colored prompt like other popular distros, which commonly use green etc, though some concerns were raised about colorblind users. However given that the original prompt was black & white, and the new one while colored will still be essentially monochromatic, it should be less of a problem and users will easily be able to turn off or change any color introduced. == Benefit to Fedora == Fedora will have a more modern and distinct default shell prompt. == Scope == * Proposal owners: ** update the default bash PS1 to a simple essentially monochromatic prompt (restricted to interactive color terminals). ** like the old default prompt, no external commands or processes will be run by PS1 by default * Other developers: bash and/or setup package maintainers to be consulted on the preferred implementation file location * 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 Community Initiatives: == Upgrade/compatibility impact == No impact for rpm editions, ostree editions may gain the default color prompt if they include its package. == How To Test == * install Fedora and test the new PS1 prompt in various terminals and scenarios ** desktop default terminals should be expected to render the new prompt well * try customizing the prompt theme by setting for example `PROMPT_COLOR='1;33'` (bright/bold yellow), etc A proof of concept can be tested today with https://copr.fedorainfracloud.org/coprs/petersen/bash-color-prompt/ ([https://copr-dist-git.fedorainfracloud.org/cgit/petersen/bash-color-prompt/bash-color-prompt.git/tree/ source git repo]) == User Experience == Fedora users will now benefit from a clear self-colored shell prompt, which should make the separation between command outputs and shell prompts much clearer and they can also easily change the prompt coloring in real-time as they desire. == Dependencies == None == Contingency Plan == * Contingency mechanism: Change owner will revert PS1 back to monochrome prompt * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == [https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters ANSI color attributes] (Wikipedia) == Release Notes == The default shell prompt is now in a distinct color for increased clarity and the theme can be customized. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: GNUToolchainF39 (System-Wide)
/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Any source level changes required for glibc 2.38 will be noted here: https://sourceware.org/glibc/wiki/Release/2.38#Packaging_Changes == How To Test == The GNU Compiler Collection has its own test suite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own test suite which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. The GNU Binutils has its own test suite which is run during the package build and examined by binutils developers before being uploaded. The regression test suite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own test suite which is run during the package build and examined by gdb developers before being uploaded. The regression test suite is run to verify the correct operation of the debugger. == User Experience == == Dependencies == All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 39 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime. == Contingency Plan == * Contingency mechanism glibc: If glibc 2.38 proves too disruptive to compiling the distribution we could revert to 2.37, but given that Rawhide has started tracking glibc 2.38, no show-stopper problems are expected. At this point we can still revert to upstream version 2.37 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism binutils: If binutils 2.40 proves too distruptive to assembling and linking the distribution we could revert to 2.39, but given that Rawhide is using 2.40, no show-stopper problems are expected. At this point we can still revert if insurmountable problems appear, but to do so may require a mass rebuild if the defects involve generated binaries. * Contingency mechanism for gcc: If gcc 13.2 proves too disruptive to compiling the distribution we could revert to gcc 13.1. * Contingency mechanism for gdb: If gdb 13.2 proves too disruptive to debugging the distribution we could revert to gdb 13.1. * Blocks release? ** No, upgrading to gcc 13.2 does not block the release. ** Yes, upgrading to binutils 2.40 does block the release. ** Yes, upgrading to glibc 2.38 does block the release. ** No, upgrading to gdb 13.2 does block the release. == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The binutils manual contains the documentation for the release and doesn't need any more additional work. The glibc manual contains the documentation for the release and doesn't need any more additional work. The gdb manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler Collection version 13 release notes. The GNU C Library version 2.38 will be released at the beginning of August 2023. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD The GNU Binary Utilities version X.Y was released February 2023. The current release notes will be sent to the developer mailing list. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Enable auto-updates by default in Fedora Kinoite (Self-Contained)
https://fedoraproject.org/wiki/Changes/KDEKinoiteAutoUpdateByDefault 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 == On Fedora Kinoite, Plasma Discover supports automatically updating the system in a safe fashion via rpm-ostree staged updates. We want users to benefit from bug fixes and updates in general by default thus we want to enable auto-updates by default. Users will still have the option of disabling that or tuning the frequency at which updates happen. == Owner == * Name: [[User:Siosm|Timothée Ravier]], [[User:Ngompa|Neal Gompa]] * Email: , == Detailed Description == We will enable a setting named "Unattended Updates" in Plasma Discover that will enable background updates by default in new installations and existing installations. This process uses rpm-ostree staged updates support to download and prepare the new version of the system in the background, which is then used on reboot. The user will only be notified to reboot their system once the updates have been applied and once a given amount of time has passed before the last time an update was applied. Pull request for the change: https://pagure.io/workstation-ostree-config/pull-request/393 Bugs related to the change (that the change owner will fix): * https://bugs.kde.org/show_bug.cgi?id=471548 * https://bugs.kde.org/show_bug.cgi?id=454422 == Feedback == None so far. == Benefit to Fedora == Users benefit from updates quickly and by default. Users don't have to worry about updating their system anymore. == Scope == * Proposal owners: Implement and test the change (https://pagure.io/workstation-ostree-config/pull-request/393) * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == All Kinoite systems updated to Fedora 39 will have this setting set by default if the options have not been changed manually before. == How To Test == Run `echo -e "[Global]\nUseUnattendedUpdates=true\n" > /etc/xdg/PlasmaDiscoverUpdates` as `root` and reset the Update setting page to the defaults. The system should now download updates automatically and asks for a reboot once a week. == User Experience == User will not have to manually check for updates, they will be applied automatically in the background. After a week without a reboot, they will be offered to reboot to apply system updates. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Push the change to the next release or undo the change. * Contingency deadline: N/A. Any time before we GA * Blocks release? No == Documentation == None needed. == Release Notes == Update on Fedora Kinoite are now downloaded automatically and applied on the next reboot. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Migrate NetworkManager ifcfg profiles to keyfile (System Wide)
in behavior. The keyfile format supports a superset of the features supported by ifcfg. Furthermore, the migration is done by the NetworkManager daemon using the same code path used to store new connections in keyfile format. Any bug in the migration would also affect the creation of new connections. If users have custom scripts or tools that parse the ifcfg files, those will break and need to be adjusted. One notable example of such tools is in package `initscripts-rename-device`, which provides a udev helper to rename interfaces based on the MAC and interface name found in ifcfg files. Users relying on this mechanism will need to switch to systemd .link files (or udev rules) to perform the renaming. The release notes for the Fedora version shipping this change will mention these aspects. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? no == Documentation == No doc change required. == Release Notes == The change will be mentioned in the Release Notes. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: IBus 1.5.29 (System-Wide)
https://fedoraproject.org/wiki/Changes/IBus_1.5.29 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 == IBus 1.5.29 will work with Plasma Wayland more closely using the Wayland protocol. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * IBus will be able to switch the keyboard layouts with the panel icon menu in Plasma Wayland. * IBus will be able to show the candidate popup window near the input cursor in Plasma Wayland. * IBus will be able to switch the keyboard layouts with the shortcut key in Plasma Wayland. == Feedback == == Benefit to Fedora == IBus will use Wayland input-method protocol in Plasma Wayland and handle the key events and switch keyboard layouts and the position the candidate popup window. == Scope == * Proposal owners: ibus 1.5.29 * Other developers: [[AkiraTagoh| Akira TAGOH]] * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == You need to unset QT_IM_MODULE and GTK_IM_MODULE environment variables in Plasma Wayland desktop only but not Plasma Xorg desktop and follow the Setup section below. == How To Test == === Setup === # Install Plasma Wayland desktop and Log into the desktop session. # Run konsole and type `env` and if you find `QT_IM_MODULE=ibus` or `GTK_IM_MODULE=ibus`, you need to run im-chooser and select "No Input Method" and make sure `QT_IM_MODULE` and `GTK_IM_MODULE` environment variables are not set on konsole. # Run systemsettings5 and open "Input Devices" -> "Virtual Keyboard" and select "IBus Wayland" and press "Apply" button. # Focus on the konsole input context and IBus panel icon will be shown. === Panel Menu === # Run kwrite and open a new document. # Focus on the input context in kwrite and click IBus panel icon to show the panel menu.(May need to click kwrite again to open the menu) # Select a keyboad layout on the panel menu and IBus can switch the keyboard layouts. === Input Method List with Shortcut Key === # Run kwrite and open a new document. # Focus on the input context in kwrite and type Super-space to show the input method engine popup window.(May need to click kwrite again to open the popup) # Select a keyboad layout on the popup window with some space keys pressing Super key and IBus can switch the keyboard layouts. == User Experience == IBus had not supported to switch the keyboard layouts since Plasma Wayland has been integrated in Fedora but now IBus can switch both the keyboard layouts and input method engines and IBus candidate window is now shown near the input cursor and those are useful for the users. == Dependencies == Other IBus packages and KDE packages don't need to be rebuilt. We use systemsettings5 to enable IBus in Plasma wayland as the first implementation. The configuration with imsettings is nice to have in Fedora 39 GA but will be implemented later. == Contingency Plan == * Contingency mechanism: Revert the change to ibus. * Contingency deadline: Beta release * Blocks release? No == Documentation == TBD == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
This proposal has now been submitted to FESCo for voting https://pagure.io/fesco/issue/3005 ___ 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: F39 Change Proposal: No fedora-repos-modular in default installation (System Wide Change)
This proposal has now been submitted to FESCo https://pagure.io/fesco/issue/3007 ___ 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: F39 Change Proposal: Retire AWS CLI version 1 package awscli (System Wide Change)
This proposal has now been submitted to FESCo https://pagure.io/fesco/issue/3006 ___ 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: F39 Change Proposal: Automatic Cloud Reboot on Updates (Self-Contained Change)
This proposal has now been submitted to FESCo https://pagure.io/fesco/issue/3010 ___ 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: F39 Change Proposal: Aspell Depreciation (Self-Contained Change)
This proposal has now been submitted to FESCo https://pagure.io/fesco/issue/3009 ___ 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
This proposal has now been submitted to FESCo https://pagure.io/fesco/issue/3008 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Automatic Cloud Reboot on Updates (Self-Contained Change)
arch 0.7.8-5.fc38 fedora 22 k Transaction Summary === Install 5 Packages Total download size: 547 k Installed size: 2.1 M == Feedback == One of the other ideas was to patch `cloud-init` to run `tracer` directly and avoid the `/var/run/reboot-required` file altogether. That would require a lot of work upstream in `cloud-init` to enable the functionality and we would still need the same set of packages installed in Fedora anyway. 掠 == Benefit to Fedora == This change allows Fedora cloud instances to behave in the same way that Debian-based instances already behave. When users request package updates with a reboot now, `cloud-init` performs the update but never reboots the system. This is an unexpected and confusing result for users who come to Fedora from other distributions. Rebooting automatically could also reduce the attack surface of an instance that just came online since it would immediately reboot to put all package updates into effect on the system. This reduces the time that an unpatched instance is online prior to being fully patched. == Scope == * Proposal owners: This change is fairly isolated and only affects Fedora cloud users who request package updates followed by a reboot in their `cloud-init` metadata. * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Since this change only applies to `cloud-init` on the very first boot of the instance, this wouldn't affect a user upgrading from one version of Fedora to the next. == How To Test == # Ensure you have a cloud image that has an update that needs a reboot (kernel, openssl, etc) # Boot an instance with the following `cloud-init` user data: #cloud-config package_update: true package_upgrade: true package_reboot_if_required: true # Wait for the package updates to finish on the instance and verify that it rebooted after updating == User Experience == First, if a user never uses the `package_upgrade` and `package_reboot_if_required` options in their `cloud-init` user data, they won't be affected by this change. These options are not enabled in `cloud-init` by default. If a user does enable both of these options, they will see their cloud instance come online, apply updates, and reboot if required. Most cloud providers have very fast reboots, so the delay should not be a problem. == Dependencies == Nothing depends on this change. == Contingency Plan == * Contingency mechanism: Push to Fedora 40 if the work cannot be done in time * Contingency deadline: N/A * Blocks release? N/A == Documentation == Guidance for users in a blog post (Fedora Magazine) could be helpful for this change. Many users might not be aware that they had the option to ask for package updates and reboots via `cloud-init` for their Fedora cloud instances. == Release Notes == Fedora cloud instances now automatically reboot when a user requests package updates followed by a reboot on the first boot of the instance. The reboot only occurs if an updated package requires a reboot to go into effect (such as a kernel or critical system library). -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
Wiki Link: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere On Tue, May 30, 2023 at 7:37 PM Aoife Moloney wrote: > 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 is the last step in > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > effort. Jdks in fedora are already static, and we repack portable > tarball into rpms. Currently, the portbale tarball is built for each > Fedora and Epel version. Goal here is to build each jdk > (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and > repack in all live fedoras. > > == Owner == > > * Name: [[User:jvanek| Jiri Vanek]] > * Email: jva...@redhat.com > > > == Detailed Description == > > As described in > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > during last year, packaging of JDKs had changed dramatically. As > described in same wiki page, and individual sub changes and devel > threads, with primary reason this - to lower maintenance and still > keep fedora java friendly. > > * In first system wide change, we had changed JDKs to build properly > as standalone, portable jdk - the wey JDK is supposed to be built. I > repeat, we spent ten years by patching JDK to become properly dynamic > against system libs, and all patches went usptream, but it become > fight which can not be win > > * as a second step we introduced portable rpms, which do not have any > system integration, only builds JDK and pack final tarball in RPM for > free use. > > * In third step - without any noise, just verified with fesco - > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > integrated rpms. Instead of this, normal RPMS BUildRequire portable > rpms and just unpack it, and repack it. > > Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in > oldest live Fedora, and repack everywhere. java-latest-openjdk, which > contains latest STS jdk - currently 20, soon briefly 21 and a bit > alter 22... Should be built in latest live EPEL - epel8 now. We have > verified, that such repacked JDKs work fine. > > == Feedback == > > > == Benefit to Fedora == > > java maintainers will finally some free time... No kidding - > maintenance and *certification* of so much supported JDKs on so much > Fedora versions is brutal. By building once, and repack, we will > regain cycles to continue support Fedora with all LTS and one STS > javas. > > If we fail to build once and repack everywhere, java maintainers will > most likely need to lower the number of JDKs in fedora to system one > only. > > == Scope == > * Proposal owners: Technically all jdks (except 8, where some more > tuning is needed, and epels for java-latest) are prepared, as they > have portable version, and rpms just reapck it. Except tuning up the > jdk8 and epel for latest, scope owners are done. > > > * Other developers: There will be needed significant support from RCM > and maybe senior fedora leadership to help to finish the build in > oldest and enable to repack everywhere Aoife Moloney > > Product Owner > > Community Platform Engineering Team > > Red Hat EMEA > > Communications House > > Cork Road > > Waterford > -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA <https://www.redhat.com> Communications House Cork Road Waterford <https://www.redhat.com> ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Aspell Depreciation (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/AspellDeprecation
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 ==
Deprecating aspell package because there are better-supported spell
checkers like hunspell/enchant2 which could be used instead. It also
has an upstream with almost 4 years of no action.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavo...@redhat.com
== Detailed Description ==
Upstream of the aspell package has been inactive for almost 4 years
now. Most of the packages that have been using aspell in the past did
migrate to the supported [https://github.com/hunspell/hunspell
hunspell package] or any other spell checker.
The plan is simple:
1) Deprecate aspell package.
2) Create Bugzilla tracker to request all packages to be migrated to
the hunspell or any other spell checker (let maintainers choose their
preferred one).
3) After all of the packages have been migrated, create a Change to
retire aspell from Fedora
== Feedback ==
Early feedback from the community is located in this
([https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/YJWK522SSTYGIILBRC5BFVRAU74TQYHB/
Devel list announce])
== Benefit to Fedora ==
Fedora shouldn't maintain a dead package. This change will ensure
Fedora has relevant and upstreamed packages in it's repositories.
== Scope ==
* Proposal owners: Package aspell will be deprecated and the migration
request will be filled as a Bugzilla to all dependent packages
* Other developers: Migrate to hunspell package or any other supported
spellchecker present in Fedora repositories.
* Release engineering: No action required
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
As this is only deprecation change, nothing will need to be handled
manually. The dependent packages will migrate to hunspell or any other
supported spellchecker present in Fedora repositories.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 39
=== Requires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep -v 'src$' | pkgname
eiskaltdcpp-qt
enchant-aspell
enchant2-aspell
kf5-sonnet-core
kf5-sonnet-core
moodle
perl-Code-TidyAll
perl-Text-Aspell
php-pspell
qa-tools
recoll
recoll
xedit
xmlcopyeditor
yagf
=== BuildRequires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep 'src$' | pkgname
eiskaltdcpp
enchant
enchant2
hunspell-az
hunspell-csb
hunspell-de
hunspell-en
hunspell-fa
hunspell-gv
hunspell-ky
ibus-typing-booster
inkscape
kf5-sonnet
logjam
perl-MouseX-ConfigFromFile
perl-MouseX-Types-Path-Class
perl-Text-Aspell
perl-Text-SpellChecker
PHP
recoll
tin
xmlcopyeditor
yagf
== Contingency Plan ==
* Contingency mechanism: No contingency mechanism is required for deprecation.
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change by the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
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 is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. Jdks in fedora are already static, and we repack portable tarball into rpms. Currently, the portbale tarball is built for each Fedora and Epel version. Goal here is to build each jdk (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and repack in all live fedoras. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in same wiki page, and individual sub changes and devel threads, with primary reason this - to lower maintenance and still keep fedora java friendly. * In first system wide change, we had changed JDKs to build properly as standalone, portable jdk - the wey JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went usptream, but it become fight which can not be win * as a second step we introduced portable rpms, which do not have any system integration, only builds JDK and pack final tarball in RPM for free use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated rpms. Instead of this, normal RPMS BUildRequire portable rpms and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latest STS jdk - currently 20, soon briefly 21 and a bit alter 22... Should be built in latest live EPEL - epel8 now. We have verified, that such repacked JDKs work fine. == Feedback == == Benefit to Fedora == java maintainers will finally some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS javas. If we fail to build once and repack everywhere, java maintainers will most likely need to lower the number of JDKs in fedora to system one only. == Scope == * Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Except tuning up the jdk8 and epel for latest, scope owners are done. * Other developers: There will be needed significant support from RCM and maybe senior fedora leadership to help to finish the build in oldest and enable to repack
F39 Change Proposal: Haskell GHC 9.4 and Stackage LTS 21 (Self-Contained)
https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.4_and_Stackage_21 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the GHC Haskell compiler from major version 9.2 to 9.4, and Haskell packages will be updated from Stackage LTS 20 to LTS 21 versions. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: == Detailed Description == For Fedora 39, the [https://www.haskell.org/ghc/ GHC] Haskell compiler will be updated from version [https://www.haskell.org/ghc/download_ghc_9_2_6.html 9.2.6] to the latest stable [https://www.haskell.org/ghc/download_ghc_9_4_5.html 9.4.5] release (rebasing from the [https://www.haskell.org/ghc/download_ghc_9_4_5.html ghc9.4] package). Along with this, Haskell packages in [https://www.stackage.org Stackage] (the stable Haskell source package distribution) will be updated from the versions in [https://www.stackage.org/lts-20 LTS 20] to latest [https://www.stackage.org/lts-21 LTS 21] release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. == Feedback == == Benefit to Fedora == Fedora users will have the latest stable Haskell compiler release, package tools, and current Haskell packages from Stackage LTS. GHC 9.4.5 is the current recommended version of GHC with various enhancements and fixes (see the release notes linked in the Documentation section for more details). == Scope == * Proposal owners: ** update ghc9.2 is build against itself ** rebase ghc to 9.4.5 ** finalize ghc-rpm-macros for F39 ** (refresh packagings with the latest cabal-rpm release if needed) ** update packages to latest [https://www.stackage.org/lts-21 Stackage LTS 21] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order using fbrnch ** push the sidetag through Bodhi * Other developers: no actions should be needed * 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 Community Initiatives: == Upgrade/compatibility impact == Any dropped packages will have obsoletes added. Otherwise there should not be any direct upgrade impact. Users' Haskell projects will get built with ghc-9.4 when they next build them and might need some minor code tweaks (see the release notes linked below). == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad, Agda * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep ; cabal install * install ghc8.10, ghc9.0, ghc9.2, ghc9.6 * test upgrades of F38 Haskell packages to F39 == User Experience == Users will have the most recent stable major version of `ghc` and Haskell libraries and tools available to them. This makes it easier to build the latest versions of Haskell projects. In particular `cabal-install` will also be updated from 3.6 to 3.8. == Dependencies == == Contingency Plan == * Contingency mechanism: ** Change owner will drop the new builds and revert back to the versions in F38 * Contingency deadline: Beta Freeze * Blocks release? N/A (not a System Wide Change) == Documentation == * https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.1-notes.html * https://www.stackage.org/blog/2023/06/announce-lts-21-nightly-ghc9.6 == Release Notes == The Haskell GHC compiler has been updated from 9.2.6 to 9.4.5 with many improvements and Haskell package versions are updated from Stackage LTS 20 to 21. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault 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 == fwupd-refresh systemd service unit & timer are designed to regularly refresh the fwupd metadata and update the MOTD when new firmware updates can be applied on a system. We want to enable the fwupd-refresh.timer by default on IoT, CoreOS & Server editions so that users get reminded about firmware updates. On desktops, firmware updates are generally coordinated by graphical applications such as GNOME Software or Plasma Discover so we will not enable it on those editions. == Owner == * Name:[[User:Siosm| Timothée Ravier]], [[User:ravanelli| Renata Ravanelli]] * Email: trav...@redhat.com, rrava...@redhat.com == Detailed Description == Firmware for hardware devices can have bugs and firmware updates generally help address those. Firmware updates might however need manual interaction, a reboot or device unplug/re-plug so we can not enable firmware update by default. This change thus only enable notifying about new firmware updates, not installing them. With this change, Fedora installations will contact the Linux Vendor Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated metadata but will not send any information about the hardware without user interaction. See the LVFS privacy policy at https://lvfs.readthedocs.io/en/latest/privacy.html. == Feedback == Discussion for each impacted edition: * CoreOS: https://github.com/coreos/fedora-coreos-tracker/issues/1512 (Accepted) * IoT: https://pagure.io/fedora-iot/issue/52 (Accepted) * Server: https://pagure.io/fedora-server/issue/115 (Accepted) == Benefit to Fedora == Knowing when firmware updates can be applied on a system would make systems more reliable. == Scope == * Proposal owners: Do the change required to enable fwupd-refresh.timer by default * Other developers: N/A * Release engineering: N/A [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 Community Initiatives: N/A == Upgrade/compatibility impact == No impact, it is just a refresh to check about new firmware updates. It will be enabled for existing and new systems. == How To Test == Install a system on hardware that has an old firmware and check if you get a notification about a new firmware update on login in the MOTD. == User Experience == User will still have to manually update their firmware. == Dependencies == There are no dependencies == Contingency Plan == * Contingency mechanism: Continue to ship things the way we ship them today * Contingency deadline: N/A * Blocks release? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: LibreOffice 7.6 (Self-Contained)
https://fedoraproject.org/wiki/Changes/LibreOffice_7.6 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 LibreOffice suite to 7.6 == Owner == * Name: [[User:mattia| Mattia Verga]] * Name: [[User:limb| Gwyn Ciesla ]] * libreoffice-SIG * Email: mattia.ve...@protonmail.com, gw...@protonmail.com == Detailed Description == LibreOffice 7.6 is currently in Beta and the first stable release is currently scheduled during F39 development. We aim to bring the latest LibreOffice stable release in F39. At the same time we plan to stop building LibreOffice for i686 architecture. == Benefit to Fedora == Make Fedora be in parity with upstream release, so users are not forced to switch to external Flatpaks. == Scope == * Proposal owners: Update `libreoffice` package to the latest version and make sure the dependencies are updated. This will be the first major update after Libreoffice-SIG take over maintenance from RH, so there might be a few troubles as the former maintainers were also able to contribute to upstream with patches. * 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 Community Initiatives: N/A (not needed for this Change) == Upgrade/compatibility impact == == How To Test == Users running F39 will get LO 7.6 and can use and test any regression from the previous release. == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: LibuserDeprecation (System Wide)
https://fedoraproject.org/wiki/Changes/LibuserDeprecation 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 == Libuser is not actively developed. Most of the depending component have build-time option to work without libuser. == Owner == * Name: [[User:THalman| Tomas Halman]] * Email: == Detailed Description == The libuser provides library and command line utilities to manipulate user and group information. The purpose of the library is/was to hide the differences between users in LDAP and files in etc (passwd, groups...). The support for LDAP is not complete and there is no plan to extend the functionality. The LDAP integration in Fedora is nowadays done by SSSD. In the past, the libuser was used by more component including Fedora installer. Currently the list is short * usermode (Requires development, it is not complicated but the dependency is unconditional) * util-linux (compile time option) * passwd (I suggest to ship passwd utility from shadow-utils instead of passwd and drop passwd package as well) == Feedback == == Benefit to Fedora == The main benefit is to decrease the maintenance and packaging work on library that does not bring much value while the functionality is provided by another components. == Scope == * Proposal owners: Dropping the package, move it to EPEL eventually * Other developers: ** Update usermode code to make libuser dependency configurable. ** Update usermode packaging to compile it without libuser ** Change packaging of util-linux to compile without libuser dependency ** Change packaging of shadow-utils to provide passwd utility * Release engineering: [https://pagure.io/releng/issue/11492] Libuser is part of base image and must be removed. IMO mass rebuild is not required. * Policies and guidelines: Since this is about dropping packages release notes must be updated. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == People who used libuser to manipulate users in LDAP will have to move to SSSD. == How To Test == 0. no special hardware needed 1. remove libuser, passwd, install new shadow-utils, usermod and util-linux 2. try to change password of some user 3. try to modify user using usermod 4. expected results: everything works normally == User Experience == This change should not be visible for users. == Dependencies == * usermod (code modification, packaging to drop libuser dependency) * shadow-utils (packaging to provide passwd utility * util-linux (packaging to drop libuser dependency) * passwd (drop package) == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: final development freeze * Blocks release? No == Documentation == There is no extra documentation for this change except release notes. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
bby review. == Contingency Plan == == Documentation == *https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-sdboot or *https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Golang1.21 (System-Wide)
https://fedoraproject.org/wiki/Changes/golang1.21
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.21 in Fedora 39.
== 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.21 in Fedora
39. Go 1.21 is expected to be released in August 2023. A mass rebuild
of all of the dependent packages is required.
== Feedback ==
No feedback yet.
== 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
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.21
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 39, 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 Community Initiatives: 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.21 from rawhide and use it to build your
application(s)/package(s).
# Scratch build against rawhide.
# Your application/package built using golang 1.21 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.20.X if significant issues are
discovered
* Contingency deadline: Beta freeze
== Documentation ==
https://tip.golang.org/doc/go1.21
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Further reduce Fedora-specific build flags in non-RPM Python extensions (Self Contained)
python3.11])
* Other developers: No requirements apart from welcoming testing their
C extensions
* Release engineering: No mass rebuild required and no releng impact
anticipated.[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)
== Upgrade/compatibility impact ==
Not anticipated. Extension modules (built for the same Python version)
are compatible with the interpreter with or without the removed flags
back and forth.
== How To Test ==
=== For users (Python developers) ===
# build your favorite Python extension module in venv or outside venv
with your favorite build system
# observe the used flags and check that the full set of flags are
'''are not there''' as mentioned in the detailed description, report
bugs for {{package|python3.12}} otherwise (and block our tracking bug)
# check if the extension works as expected
=== For packagers (Fedora contributors) ===
# build your favorite RPM package with Python extension module
# observe the used flags and check that the full set of flags '''are
there''' and not the reduced one, report bugs for that package
otherwise (and block our tracking bug)
# check if the package works as expected
== User Experience ==
See '''Benefit to Fedora''' above.
== Dependencies ==
Changes are required in {{package|redhat-rpm-config}} along with the
Python interpreters.
== Contingency Plan ==
* Contingency mechanism: Change owners can revert the change at any point.
* Contingency deadline: final freeze (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Retire Modularity (Self Contained)
Linux 37/38 to 39/40 with enabled modular streams (from the Fedora repos) is still possible. == User Experience == Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead. == Dependencies == * [[Changes/FlatpaksWithoutModules]] * [[Changes/No_default_fedora-repos-modular]] == Contingency Plan == * Contingency mechanism: Revert the changes * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == Ideally, all references to Fedora-provided modular streams should be removed from docs.fedoraproject.org, except for docs.fedoraproject.org/en-US/modularity which should be clearly marked as obsolete/archived. == Release Notes == Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Sericea and Sway Spin Xorg-less (Self Contained)
https://fedoraproject.org/wiki/Changes/sericea-xorgless 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 == At the moment Sericea and Sway Spin ship with xorg-x11 packages. This proposal aims to remove xorg-x11 packages from such artifacts. == Owner == * Name: [[User:alebastr| Aleksei Bavshin]], [[User:Fale|Fabio Alessandro Locati]], Sway SIG ** Primary contact person: Fabio Alessandro Locati * Email: f...@fedoraproject.org == Detailed Description == At the moment Sericea and Sway Spin require the installation of xorg-x11 due to the use of `sddm-x11`. When we started working on F38 we were not fully convinced on the stability of SDDM-Wayland, so we opted for the safer bet: SDDM-X11. Though, since Sway is Wayland-only, it would make sense for Sericea and Sway Spin to prefer the use of `sddm-wayland-sway`. == Feedback == So far only positive feedback have been provided on this idea. == Benefit to Fedora == This change will allow Sericea and Sway Spin artifacts to ship without xorg-x11. == Scope == * Proposal owners: change the default in comps * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == When the users will update their Fedora installation, the change will occur in their boxes automatically. No direct impact nor configuration change is required. == How To Test == # Install `sddm-wayland-sway` # Reboot and test the login == User Experience == `sddm-wayland-sway` should have a slightly positive experience for users, with less bugs in some edge cases than `sddm-x11`. Majority of users should not be able to notice the difference. == Dependencies == N/A == Contingency Plan == If unexpected issues will be created by this change, we can easily rollback to `sddm-x11` by changing back the comps packages. * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: ibus-anthy 1.5.15 (self contained)
https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.15 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In ibus-anthy 1.5.15, the icon tag will be added to the metainfo, the Japanese era is updated for 2023, the candidate window is enhanced for OSK(On-Screen Keyboard). == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * ibus-anthy already has the icon but it wasn't indicated in the metainfo. Also screenshots and keywords are updated. * ibus-anthy will convert the Japanese era and "2023" mutually * ibus-anthy determines a clicked item on the candidate window but also will commit the clicked item on the candidate window in case of enabling the OSK(On-Screen Keyboard) mode in GNOME Wayland. == Feedback == == Benefit to Fedora == The metainfo data is updated within the ibus-anthy package, Japanese era is updated in a ibus-anthy dictionary file, the OSK mode is available only if the OSK is enabled and ibus-anthy switches the candidate mode. == Scope == * Proposal owners: ibus-anthy * 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 Community Initiatives: == Upgrade/compatibility impact == == How To Test == 1. Enable ibus-anthy 2. Run gnome-text-editor 3. Type "２０２３" or "れいわ５" and space keys 4. The Japanese era and 2023 is converted mutually 1. Enable OSK and ibus-anthy 2. Run gnome-text-editor 3. Click "a" and space x 2 keys in OSK and show the candidate window 4. Click a candidate string on the candidate window 5. The selected candidate string is committed in gnome-text-editor == User Experience == The metainfo data is relative with gnome-software and I hope the ibus-anthy section will be updated. Japanese era has been rarely used in Japanese documents and the ibus-anthy conversion will be useful. The OSK usability will be enhanced with the mouse. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the change to ibus-anthy. * Contingency deadline: Beta release * Blocks release? No == Documentation == N/A == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Improve Default Font Handling with default-fonts metapackages (System-Wide)
https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling 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 aims to make default fonts easier to update and install for all the variants on Fedora and reduce the maintenance costs for them. == Owner == * Name: [[User:Tagoh| Akira TAGOH]] * Email: * Name: [[User:Pnemade|Parag Nemade]] * Email: == Detailed Description == Currently there are multiple sources to manage what font packages should be installed for a Fedora release and spins, such as comps, langpacks, lorax, workstation-ostree-config, and fedora-kickstarts, which makes it complicated to make default default fonts changes. New default-fonts metapackages will be added to langpacks, some of which will replace the default font listed in `@fonts`, etc. Then going forward those lists of metapackages should only need to be changed quite rarely. * `default-fonts` metapackage to pull in: ** `default-fonts-core` metapackage to pull in: *** `default-fonts-core-sans`, `default-fonts-core-serif`, `default-fonts-core-mono`, `default-fonts-core-emoji`, `default-fonts-core-math` Metapackages to pull in the default fonts for Western characters and Emoji ** `default-fonts-cjk` metapackage to pull in: *** `default-fonts-cjk-sans`, `default-fonts-cjk-serif`, `default-fonts-cjk-mono` Metapackages to pull in the default fonts for Chinese, Japanese, and Korean ** `default-fonts-other` metapackage to pull in: *** `default-fonts-other-sans`, `default-fonts-other-serif`, `default-fonts-other-mono` Metapackages to pull in the default fonts for other (non-CJK) languages * `default-fonts-` ** Metapackages to pull in a default fonts for a specific language * `default-fonts-extra-` ** Metapackages to pull in extra fonts for a certain languages if any == Feedback == == Benefit to Fedora == This Change provides the easier way to manage and install our default fonts on Fedora. In current package sets, langpacks offers non-fonts packages to be installed even though one don't want to install them. After this Change, one doesn't need to install those extra dependencies for the purpose of the font installation. == Scope == * Proposal owners: ** update the fedora-comps @fonts group and workstation-ostree-config to use the new default-fonts packages ** fontconfig package default font dependency to be updated ** optionally update lorax to use the new default fonts (if they no longer need to remove many fonts files since most are now variable fonts anyway), otherwise it can be done for Fedora 40. * 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 Community Initiatives: == Upgrade/compatibility impact == Currently installed langpacks packages will pull in the appropriate default-fonts packages when upgrading. Using default-fonts meta-packages means that users will get upgraded to new default fonts seamlessly going forward. This should provide a more reliable font experience since default fonts should have higher fontconfig priority. == How To Test == # Install the above meta packages # See what font packages will be pulled in We have a copr repo for early testing. You can try to install the updated langpacks if you like. https://copr.fedorainfracloud.org/coprs/tagoh/langpacks-v4/ == User Experience == Users will automatically be moved to any new/changed default system fonts when they upgrade to a newer version of Fedora. It will be easier for users to remove CJK or non-core fonts from their system if they really want to, or to add them in minimal installations. == Dependencies == No. Updated langpacks still have compatibility on existing dependencies. This Change can be done in langpacks only. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) ** Change owners will revert the relevant changes. == Documentation == None == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
the ISO built by Image Builder and test if there are any unexpected changes. == User Experience == No change is expected. == Dependencies == The Workstation SIG and the installer team are working on a change to use the new installer web UI for the Workstation live ISO. We are fully aware of this change and have the capability to build ISOs with and without the new UI. As a result, these changes should be independent of each other. Furthermore, the installer and Image Builder teams are closely collaborating, ensuring that any issues that may arise can be addressed with high priority. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Release engineering to revert the change in pungi, so that the old tooling is used instead. * Contingency deadline: Final freeze (the change is trivially revertible) * Blocks release? No == Documentation == N/A == Release Notes == Fedora Workstations ISOs are now built using Image Builder instead of the legacy tooling used before. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Allow Removal of tzdata (System-Wide)
https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata 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 == Allow the removal of tzdata especially on containers in order to minimize size. == Owner == * Name: Patsy Griffin (Franklin) * Email: pa...@redhat.com == Detailed Description == This change will allow the removal of tzdata. When tzdata is removed, the system will default to UTC. In order to reduce overhead, many container installations now remove the data associated with tzdata but cannot fully remove the package due to dependencies by other packages. This results in confusion regarding the expected timezone info. In order for this to work, we need packages that use tzdata at run time to switch from Require'ing tzdata to Recommend'ing tzdata. These packages should also gracefully handle instances where tzdata has been removed. For example, this would require recognizing that tzdata is not present and providing an appropriate error, such as recommending that the user install tzdata. == Feedback == In June of 2021, we proposed creating a new tzdata sub-package that would only provide the UTC timezone. As part of the discussion around this proposal, it was recommended that we completely remove tzdata. We appreciated this input and welcome additional feedback. == Benefit to Fedora == This change will allow tzdata to be removed from containers without leaving inconsistent package remnants. == Scope == * Proposal owners: No changes are needed to tzdata. * Other developers: Some packages need to change their spec files from `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if all packages switched in this way, but it is not required. Supporting optional tzdata installation for as many workloads as possible allows those workloads to minimize their container image size. List of packages which need to be changed: * glibc (glibc-common) * gcc (libstdc++) * python3.XX (3.9, 3.10, 3.11, 3.12) List of packages which would be beneficial to be changed: * python3-dateutil * python3-pytz * libical Upon acceptance of the change request we will file bugs to fix each of these packages for Fedora 39. * Release engineering: No changes needed. * 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 == If tzdata is already installed, then it continues to be installed on the system. Following the Fedora Weak Dependencies Policy dnf will treat the Recommends on tzdata as if it were a Requires and tzdata will always be installed in a default system (https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/) However, the recommends will allow tzdata to be correctly uninstalled in a container build file rather than having to use ‘rm -rf’ to delete the zone files to recover space. == How To Test == Language runtimes were installed and A/B tests carried out with tzdata present and tzdata removed. The intent of these tests was to ensure that the system can use the language frameworks without tzdata present and that when the data was required that meaningful errors were presented to the user. Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11), using their time and date APIs. This testing led to the correction of the libstdc++ implementation as noted here: https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3 Developers can test this by installing Rawhide and uninstalling tzdata and verifying their package operates as expected. If tzdata cannot be uninstalled then we recommend filling a bug against the package that Requires: tzdata and having a discussion with the maintainer to make tzdata optional e.g. Recommends: tzdata. == User Experience == The user can remove tzdata to minimize the container size. With tzdata removed the system is UTC only. == Dependencies == Fixing glibc, gcc, and python3.xx at a minimum to make tzdata Recommends instead of Requires. == Contingency Plan == * Contingency mechanism: Back out the change. Don’t do it. * Contingency deadline: Can be backed out at the last minute since we are only dealing with conversions from Requires to Recommends. * Blocks release? No == Documentation == Document that the tzdata package may be removed if needed to reduce space on containers. With tzdata removed, the system will default to UTC. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le
F39 Change Proposal: LLVM 17 (System-Wide)
. * Contingency deadline: Beta Freeze == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 17: *llvm *clang *lld *lldb *compiler-rt *libomp *llvm-test-suite *libcxx *python-lit *flang *mlir *polly *libclc *llvm-bolt -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
feedback and until resolved use the GTK UI instead. == Documentation == Documentation will be expected especially for custom partitioning replacement but not only that. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Passkey authentication for centrally managed users (Self-Contained Change)
user will be able to log in using the passkey authentication mechanism, and if they are using FreeIPA they will get a Kerberos ticket alongside the authentication. For those using the graphical interface and passkeys for log-in you will notice that the messages aren't completely visible. We are working with GNOME developers to improve overall login experience with passwordless authentication methods. This work is expected to land in Fedora once ready. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: N/A * Contingency deadline: N/A * Blocks release? No == Documentation == # [https://sssd.io/design-pages/passkey_authentication.html SSSD design page for local passkey authentication] # [https://sssd.io/design-pages/passkey_kerberos.html SSSD design page for passkey Kerberos integration] # [https://freeipa.readthedocs.io/en/latest/designs/passkeys.html FreeIPA design page for passkey authentication] == Release Notes == Passkey authentication for centrally managed users. For FreeIPA users a Kerberos ticket is also issued. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
ll be available by dnf install anyway - there may be clash during the build which will cause to repack wrong (newer, non certified) portables d) include SRPM_REBUILD.readme in srpm and generated PORTABLES_INSTALL.readme in RPMs, which will ideally at least contain: - instruction why you need portables - instruction how to find the portables - from SRPM_REBUILD.readme pointing to PORTABLES_INSTALL.readme - generated link to the koji, allowing to download the SRPM - generated link to the koji, allowing to download the binaries - generated instruction how to dnf install used portables I would currently vote for d). If there will be complains about broken SRPM rebuild, or need to install portables without hacking, then fall-back a, b or c via Change Proposal. Once Bodhi allows single build to be tagged to several release, I will move to that. == Feedback == == Benefit to Fedora == Java maintainers will finally have some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS JDK. If we fail to build once and repack everywhere, Java maintainers will most likely need to lower the number of JDKs in fedora to system one only. == Scope == * Proposal owners: Technically all JDKs (except 8, where some more tuning is needed, and EPEL for java-latest) are prepared, as they have a portable version, and RPMs just repack it. Except tuning up the JDK8 and EPEL for latest, scope owners are done. * Other developers: There will be needed significant support from RCM and maybe senior Fedora leadership to help to finish the build in oldest and enable to repack everywhere * '''Release engineering: [https://pagure.io/releng/issue/11438 #11438]''' There will be needed significant support from RCM, where I'm actually unsure what they will have to do to enable this. The mas rebuild will not be needed. * Policies and guidelines: AFAIK none (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: All supported JDKs will remain in Fedora in highest possible quality with full QA and certification, and its packagers will not lose their minds. Note that QA will still run on all live Fedoras, not only on the builder one. == Upgrade/compatibility impact == The change should be completely transparent to any user. == How To Test == `sudo dnf update/install "java*"` will install expected set of working packages. SRPM rebuild of both portables (which were built once) and of any rpms (from this freshly rebuild portbales) have to remain possible == User Experience == The change should be absolutely transparent to any user. == Dependencies == To finish this we will need heavy support from RCM, and maybe others. Although there are precedents with such pacakge, they all bites. From SW point of view, the dependece chain is `normal RPMs build requires portable RPMs` and thats all. == Contingency Plan == * Contingency mechanism: Even if It should be straight forward to revert back to building per OS, it '''may be impossible for current maintainers to save time''' for it. If this change is approved, we will be building '''4-5''' (jdk8,11,17,sts and 21) builds for all fedoras. If this change is not finished in time, we may '''need to orphan some of the JDKs'''. In better case, we will be able to keep living '''one LTS as system JDK, and java-latest-openjdk''' as future system JDK. That is 2*(3-5) builds (rawhide, (forked,), latest live, oldest live (oldest not yet dropped)). '''In worst case''', we may be able to maintain only java-latest-openjdk. On long run changing it to '''rolling system JDK,''' which are the expected 3-5 builds. * Contingency deadline: N/A * Blocks release? No. The change can be introduced even on the fly to live distributions. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)
https://fedoraproject.org/wiki/Changes/LIBFFI34_static_trampolines 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 == Libffi is currently configured to use dynamic trampolines, which require some source of memory which is both writable and executable. This is an obvious security issue, and selinux and system defaults have made it more and more difficult to safely provide this memory to libffi clients. With this change, libffi will be configured to use static trampolines, which do not require such memory, and will not pose those security and administrative risks. == Owner == * Name: [[User:djdelorie| DJ Delorie]] * Email: d...@redhat.com == Detailed Description == The change itself is simple - libffi will no longer be configured with --disable-exec-static-tramp, which changes how closures are generated. Closures, and libffi, are used in many interpreted languages. There are about 145 packages that depend, directly or indirectly, on libffi. I ran the Mass Prebuilder. Of those 145, 10 already FTBFS, and 1 saw a new failure. The Mass PreBuilder has indicated that cjs (Javascript Bindings for Cinnamon) will fail to build with static trampolines. We debugged this a bit and noted that cjs's upstream seems to be behind the gjs upstream (the gjs package builds OK) it tracks, and is missing at least two closure-related changes (although simply adding those two changes proved nontrivial). == Feedback == == Benefit to Fedora == This change is needed to fully secure Fedora systems against attacks that use self-modifying code. The cjs build failure affects the Cinnamon spin. == Scope == * Proposal owners: The change is a single line in the spec file. * Other developers: The cjs package will need to be fixed to build with the new libffi. Other libffi users will need to be aware of this change if they make closure-related changes to their packages, but should not need to take any actions at this time. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] This change does not affect release engineering or any other packaging issues. No mass rebuild is required. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == This change does not change ABI but that assumes clients are not abusing the ABI; the static vs dynamic trampoline change is an internal implementation. == How To Test == Testing static trampolines is the same as testing libffi, with the exception that the tests should pass despite having all writable filesystems locked with selinux such that executable maps cannot be requested. A security context that does not allow the memfd_create() syscall would further isolate this change. == User Experience == Users will be able to follow latest security recommendations without concern for whether interpreters will stop working. == Dependencies == As noted above, the cjs package requires work before this change can go through. They have noted that they'll be rebasing to 5.8.x: https://bugzilla.redhat.com/show_bug.cgi?id=2193287 Note that cjs has rebased to 5.6.1 in the interim, just to fix this bug. I've tested it and it works with static trampolines. == Contingency Plan == Reverting the one line spec file change will revert this change, with no changes needed elsewhere. Not completing this change in time does not negatively impact other package, or Fedora's ability to ship on time. * Contingency mechanism: We can revert the change at any time, without needing to rebuild any other packages. * Contingency deadline: Any time before shipping. * Blocks release? No. == Documentation == This is an internal change that should not need nor affect any documentation. == Release Notes == This change should not require any release notes. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
as reliable as those running directly on the host operating system. If someone installs the Beta or the Final on their host, and creates a Toolbx container using the default [https://src.fedoraproject.org/container/fedora-toolbox fedora-toolbox] image, then, barring exceptions, the host and the container should have the same RPM versions. Just like Workstation and Silverblue are released with the same versions. This will ensure greater consistency in terms of bug-fixes, features and pending updates. == Dependencies == N/A (not needed for this Change) == Contingency Plan == * Contingency mechanism: If there are no up to date [https://src.fedoraproject.org/container/fedora-toolbox fedora-toolbox] images published on [https://registry.fedoraproject.org/ registry.fedoraproject.org] as release-blocking deliverables, then the release-blocking test criteria for the [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs cannot be put into production. In that case this Change cannot be implemented and status quo will be maintained. If the images get published, but the test criteria is absent, then only the first half of the Change will be implemented, and users can still benefit from the more predictably updated images. * Contingency deadline: We need this by the Change completion deadline or before Fedora 39 is branched from Rawhide, whichever is earlier. As per the [https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html schedule], both of those are currently set to happen on the 8th of August 2023. * Blocks release? No == Documentation == * Toolbx basics: https://containertoolbx.org/install/ * Toolbx manuals: https://github.com/containers/toolbox/tree/main/doc -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
rip down bundled packages by setting macros in
the buildopts/rpms/macros section of the
modulemd file. For example, flatpak-common has:
buildopts:
rpms:
macros: |
%_without_mingw 1
%_without_tkinter 1
This is no longer possible, so these changes need to be fed back into
spec files with
'%if 0%{?flatpak}' style conditionalization.
Additionally a couple of packages (evolution-data-services and
tracker-miners) are set up so they can be
built with an application-specific D-Bus prefix. Evolution has:
buildopts:
rpms:
macros: |
%_eds_dbus_services_prefix org.gnome.Evolution
This will need to be redone so that evolution-data-services doesn't
need recompilation
and the prefixing can be done by changing configuration files at
container build time.
== Feedback ==
== Benefit to Fedora ==
The experience for Fedora developers who want to create Flatpaks of
their applications will be improved:
* They no longer need to understand modularity and modulemd files -
instead of a modulemd file *and* a container.yaml, they simply create
a container.yaml.
* Rebuilds are automatically shared between Flatpaks, without having
to get them added to the flatpak-common module.
* Because the local build experience is no longer using the poorly
maintained local-build mode of MBS, it can be more efficient and
easier to understand.
This should result in more Fedora Flatpaks and more up-to-date Fedora Flatpaks.
We also greatly reduce the usage of Module Build Service within Fedora.
This is important because upstream maintenance is currently reduced,
and it's not clear that we'll be able to sustain a deployment indefinitely.
== Scope ==
* Proposal owners:
** Update flatpak-module-tools to be able to work without modularity
** Create changes to fedpkg to add 'rebuild-flatpak-packages'
(implementation likely within flatpak-module-tools)
** Update atomic-reactor to be able to build Flatpaks without modularity
* Other developers:
** Flatpaks will need to be migrated to the new system by Flatpak
packagers. While we could make the new system opt-in for F39, it's
probably easiest to just require all Flatpaks to be moved over. In
many cases, this should consist of just a few minor changes to
container.yaml.
** Changes to fedpkg and atomic-reactor need to be reviewed, and for
atomic-reactor deployed. '''Note''' Fedora is on OSBS 1, which is not
a current release. Backporting changes to OSBS 1 seems more realistic
than upgrading Fedora to OSBS 2 at this point.
* Release engineering: [https://pagure.io/releng/issue/11415 #Releng
issue number]
** Release engineering will need to manually create the tags/targets
for F39 and update the tag maintenance scripts to do this for future
releases.
* Policies and guidelines:
https://docs.fedoraproject.org/en-US/flatpak/ will need to be updated
once we have an initial implementation. No impact to packaging
guidelines is expected.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: No
== Upgrade/compatibility impact ==
The Flatpaks built will look exactly the same as before from a user perspective.
== How To Test ==
Testing here will be done by selecting a few Flatpaks and trying to
rebuild them using the new system,
first locally and then on infrastructure.
The final validation will be when we mass rebuild Flatpaks for F39.
== User Experience ==
This should be largely invisible to users.
Hopefully, by simplifying the developer experience around creating Flatpaks,
more Fedora Flatpaks will be available and they will be kept more up-to-date.
== Dependencies ==
This is unrelated to other Fedora changes or to changes within packages.
== Contingency Plan ==
* Contingency mechanism: The current infrastructure for module-based
builds will be maintained, so that if we can't get this done for F39,
we'll build Flatpaks as modules for F39.
* Contingency deadline: By 2023-08-01 we should have runtimes built
and a number of applications or we'll plan on using modules for F39
Flatpaks.
* Blocks release? No
== Documentation ==
At the moment, this change proposal is standalone documentation of the
change. As noted above, https://docs.fedoraproject.org/en-US/flatpak/
will need to be updated once we have an initial implementation. If you
are interested in getting involved in planning and implementing this
change, please contact the
[https://fedoraproject.org/wiki/SIGs/Flatpak Flatpak SIG] matrix room.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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
F39 Change Proposal: Retire AWS CLI version 1 package awscli (System Wide Change)
see [https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html Breaking changes] in the AWS CLI version 2 User Guide. == Dependencies == No currently known dependencies, but an email was sent to the devel mailing list to provide more visibility for anyone using it actively. == Contingency Plan == In the event that this version is not retired, both versions will be maintained. The awscli2 already includes a `Provides: awscli` directive and that would probably need to be removed to ensure that we distinguish between the two major releases. == Documentation == The AWS CLI v2 provides a [https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html Migration Guide] for users who are moving from the AWS CLI version 1 'awscli' to the AWS CLI version 2 'awscli2'. == Release Notes == The 'awscli' package has been retired and replaced with the awscli2. The awscli2 is the most recent major version of the AWS CLI and supports all of the latest features. Some features introduced in version 2 are not backported to version 1 and you must upgrade to access those features. There are some "breaking" changes from version 1 that might require you to change your scripts. For a list of breaking changes in version 2, see Migrating from AWS CLI version 1 to version 2. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: No fedora-repos-modular in default installation (System Wide Change)
== Summary == No longer include `fedora-repos-modular` in default installations. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: == Detailed Description == The main motivation for this change is to improve the everyday speed of dnf experienced by Fedora users. dnf invocations frequently check for and pull down last repo metadata and the yum modular repos which are seeing less use and content nowadays have been exasperating this problem. The proposed solution is just not to install the Fedora modular repo configurations any more by default. https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular 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. == Feedback == Some initial discussions: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/FOTOBY5IU32NWW6LT24DWUS6747WV4TP/ == Benefit to Fedora == This change will improve the user experience when updating or installing packages since the less-used yum modular repos will no longer be on by default for all users. (cf [https://web.dev/why-speed-matters/ why-speed-matters]) == Scope == * Proposal owners: ** update F39 comps @core group to not install fedora-repos-modular by default ** update fedora-container-base.ks to not install fedora-repos-modular ** update fedora-common-ostree-pkgs.yaml to not install fedora-repos-modular ** propose Fedora coreos also drops fedora-repos-modular * Other developers: ** Spin owners may want to check on any possible impact on their release artifacts * Release engineering: [https://pagure.io/releng/issue/11426 #11426] * 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 == Any existing modular repos will remain in place and updated normally. This is also a reason for not changing the modular.repo files themselves, since disabling the modular repos by default their would cause upgrades to turn off modular repos. == How To Test == * run dnf upgrade commands etc and check that modular repos are not active, ie modular repo metadata not checked/downloaded. * check that fedora-repos-modular is not pre-installed. == User Experience == Users of new Fedora installations will no longer have the Fedora modular repos setup and enabled by default, resulting in a noticeable speed up executing dnf commands. They can install fedora-repos-modular to activate the modular repos on their system. == Dependencies == None == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) ** Change owner(s) will revert the changes and re-enable the modular repos as needed * Contingency deadline: Beta freeze * Blocks release? No == Documentation == None == Release Notes == * The Fedora modular repos are no longer setup in new installations by default as of Fedora Linux 39. * Users can easily enable them with by installing the `fedora-repos-modular` package. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 Change Proposal: Vagrant 2.3 (Self-Contained)
https://fedoraproject.org/wiki/Changes/Vagrant_2.3 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the Vagrant package to the latest version 2.3.4 and the dependencies rubygem-net-ssh, rubygem-net-scp and rubygem-net-sftp to their latest versions. == Owner == * Name: [[ User:Jackorp1| Jarek Prokop ]], [[ User:Pvalena | Pavel Valena ]] * Email: jpro...@redhat.com , pval...@redhat.com == Detailed Description == Update the main Vagrant package to version 2.3.4 to bring the latest bug fixes and new features as well as update mentioned rubygem-net-* packages required for Vagrant runtime. Due to the new rubygem-net-ssh, the updates for mentioned packages will be built and delivered as one unit via the side tag "f39-build-side-67362". == Feedback == == Benefit to Fedora == Fedora will have the latest bug fixes and improvements for Vagrant and the rubygem-net-ssh, further enhancing the support for OpenSSL 3.0. Notable enhancements include: * rsa-sha2 in kex algorithm set to enable in key exchange * Support for VirtualBox 7.0 == Scope == * Proposal owners: ** Review and merge pull requests for components: *** rubygem-net-ssh: https://src.fedoraproject.org/rpms/rubygem-net-ssh/pull-request/14 *** rubygem-net-scp: https://src.fedoraproject.org/rpms/rubygem-net-scp/pull-request/4 *** rubygem-net-sftp: https://src.fedoraproject.org/rpms/rubygem-net-sftp/pull-request/3 *** vagrant: https://src.fedoraproject.org/rpms/vagrant/pull-request/33 and https://src.fedoraproject.org/rpms/vagrant/pull-request/35 ** Preview of the PR contents available in copr: https://copr.fedorainfracloud.org/coprs/jackorp/vagrant-devel/ * Other developers: N/A (not a System Wide Change) * 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 Community Initiatives: N/A == Upgrade/compatibility impact == Everything should keep working. == How To Test == Install latest available packages from copr (https://copr.fedorainfracloud.org/coprs/jackorp/vagrant-devel/), and try them out with new as well as existing Vagrantfiles and workflows. The packages in copr will be continuously updated to match the content in mentioned Pull Requests. == User Experience == Ideally no negative change, as this is mostly an extension of the Vagrant stack capabilities. == Dependencies == N/A (not a system-wide change) == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) == Release Notes == See the upstream CHANGELOG.md file for full release notes: https://github.com/hashicorp/vagrant/blob/986a01734f008d62897bb66085381090e4fcabfc/CHANGELOG.md -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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 Mass Rebuild *finish* delayed
During Monday's FESCo meeting[1][2], 22nd Jan 2024, FESCo approved a request[3] to delay the finish date of the mass rebuild, and all other associated tasks up to and including the start of the Beta Freeze, by one week. The Mass Rebuild is now targeted to be completed by February 20th. The Beta Freeze is now targeted to begin on February 27th. All other milestones remain the same at this time and the published schedule[4] has been updated to reflect these changes. [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-01-22/fesco.2024-01-22-19.30.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-01-22/fesco.2024-01-22-19.30.log.html [3] https://pagure.io/fesco/issue/3145 [4] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
REMINDER: F40 Changes 100% Complete Deadline in one week - Feb 27th
Hi all, Please note that we are approaching the 100% complete deadline for all F40 changes. This deadline is *27th February 2024. *This means that all code required to complete the change is in place, and necessary work is done before the beta freeze. For further information on changes milestones, please visit the documentation[1] page. A full list of F40 changes can be viewed on the change set page[2], and other upcoming release milestones can be found on the release schedule page[3]. Kind regards, Aoife [1] https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process_milestones [2] https://fedoraproject.org/wiki/Releases/40/ChangeSet [3] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html Aoife Moloney Fedora Operations Architect -- ___ 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 Change Proposal: Remove Python Mock Useage (System-Wide)
Wiki -> https://fedoraproject.org/wiki/Changes/RemovePythonMockUsage
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 ==
`python-mock` has been [[Changes/DeprecatePythonMock|deprecated since
Fedora 34]] - 6 releases ago, but is still in use in many packages. We
plan to go through the remaining usages and clean them up, with the
goal of retiring `python-mock` from Fedora.
== Owner ==
* Name: [[User:Salimma|Michel Lind]]
* Email: michel @ michel-slm.name
* Name: [[ User:Gotmax23|Maxwell G]]
* Email: maxwell @ gtmx.me
== Detailed Description ==
`python-mock` has been marked as deprecated since Fedora 34, but many
packages are still using it
Binary packages from 16 source packages require `python3-mock`
$ fedrq whatrequires python3-mock -b rawhide -F source --notsrc | wc -l
16
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock |
grep -v src$ | wc -l
16
$ repoquery -q --repo=rawhide --whatrequires python3-mock --source | wc -l
16
124 source packages require `python3-mock`
$ fedrq whatrequires python3-mock -b rawhide -F source --src | wc -l
124
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock |
grep src$ | wc -l
124
For a combined 134 packages
$ fedrq whatrequires python3-mock -b rawhide -F source | wc -l
134
$ (repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock
| grep src$; repoquery -q --repo=rawhide --whatrequires python3-mock
--source) | pkgname | sort | uniq | wc -l
134
Some of these are false positives - packages not using dynamic build
requirements might still be marked as requiring `python-mock` after
upstream no longer does so. The rest should be easily portable as
described in the previous proposal.
Some packages could be dead upstream and not used by anything else in
Fedora, in which case we can consider removing them.
== Feedback ==
== Benefit to Fedora ==
Eventually, we might be able to no longer maintain a standard library
backport in a separate package.
This will also make branching packages for EPEL easier - there have
been several instances where the Fedora package needs to be modified
to not use `python-mock` because of a policy decision to not bring
`python-mock` into newer EPEL releases (where the default Python
already contains `unittest.mock`).
== Scope ==
* Proposal owners:
** Set up a COPR with a stub package providing `python3-mock` and
rebuild all packages that list python3-mock as a BR. The ones that
successfully build don't actually need it
** Put up PRs for the affected packages. In case the changes are
minimal and no response is heard from the package maintainers the PRs
will be merged after a sufficient time.
** Set up a second COPR to rebuild packages with the PRs applied to
remove `python3-mock`. This will allow us to track progress in one
place
* Other developers:
Package maintainers should review and merge any PRs filed against
their packages, and if necessary forward the patches upstream (e.g. by
filing upstream PRs).
* 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:
Not specifically, but this is in line with Fedora's "First" Foundation
== Upgrade/compatibility impact ==
N/A
== How To Test ==
Package owners who receive a PR should be able to verify that the CI
passes on the PR, and alternatively they can check the provided COPRs
== User Experience ==
No changes
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: defer retiring `python-mock` for another cycle
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
The previous
[[Changes/DeprecatePythonMock#How_to_migrate_to_unittest.mock|howto]]
on migrating to unittest.mock still applies.
Upstream [https://docs.python.org/3/library/unittest.mock.html
unittest.mock documentation]
== 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
F40 Change Proposal: Build Fedora Cloud Edition Images Using Kiwi in Koji (System-Wide)
ted images to be laid out and it caused difficulties when
dealing with certain classes of package upgrades (such as bootloader
or kernel packages). There is also no Koji plugin at this time for
running mkosi builds.
== Benefit to Fedora ==
Most importantly, the kiwi builders eliminate a series of legacy build
tools for Fedora Cloud Base images
Visible to advanced users:
* Allows Fedora Images to be built on many different platforms and
distributions without modification to the runners
* Extends the composition strategies available to users
* Leaves the base image configuration that can be managed to ensure
that it meets standard requirements for local virt installations
* Includes the ability to leverage user-defined scripting in the image
definition.
* Adds a koji builder and image definitions that are simple to update and modify
* Provides increased time for prioritization of features in the Fedora
Images according to user feedback and user requirements
* Supports multiple build types, from ISO to raw disk images, and all
the way to WSL2 and containers.
This also aligns with the Fedora Asahi Remix and its usage of kiwi to
build its images, as this lays the groundwork for those images to
eventually be built in Fedora infrastructure as support for Apple
Silicon Macs gets upstreamed.
== Scope ==
* Proposal owners:
** Build and test [https://pagure.io/fedora-kiwi-descriptions kiwi
definition files]: COMPLETE
** Package {{package|kiwi}}: COMPLETE
** Add configuration to [https://pagure.io/pungi-fedora/ Fedora Pungi
configuration]
* Other developers:
** Enable kiwi plugin in Koji: [https://pagure.io/releng/issue/11726
releng issue #11726]
** Add support for KiwiBuild tasks to {{package|pungi}}:
[https://pagure.io/pungi/issue/1710 pungi issue #1710]
Submit image build requirements as a kiwi descriptions
* Release engineering: [https://pagure.io/releng/issue/11854 #11854]
* Policies and guidelines: Fedora Cloud Edition documentation should
be updated to reflect the usage of the new tooling and how to use and
contribute to it.
* 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 exceptions across other groups in Fedora.
== Upgrade/compatibility impact ==
The previous methodologies for using Fedora Quickstarts for Fedora
Cloud Edition will be retired. The kiwi descriptions will support
builds. We will use Toddler and Ansible to deliver images to the
various public cloud targets (GCP, AWS, Azure, OCI, etc.)
== How To Test ==
Test by working with the various images
# Import the image into a test account for the associated cloud provider(s)
# start an instance from that image
# login to the instance successfully.
== User Experience ==
this provides a simplified method for creating composable image
definitions and overlays.
Users will find that there are additional images supporting targeted
workloads and build methods. They will find that those images are more
readily available.
== Dependencies ==
This Change depends on work in {{package|pungi}} to enable the use of
the KiwiBuild Koji task as part of composes. It also
depends on release engineering to enable the kiwi plugin in Koji.
== Contingency Plan ==
* Contingency mechanism: Revert back to ImageFactory and continue to
support builds using the kickstart (.ks) files for image builds.
* Contingency deadline: Beta freeze
* Blocks release? Yes
== Documentation ==
Documentation for kiwi is available from
[https://osinside.github.io/kiwi the upstream site]. Once the Koji
plugin is enabled, we will create accompanying documentation for SIG
members on using the functionality.
== Release Notes ==
Fedora Cloud Images are now built with the
[https://osinside.github.io/kiwi kiwi] image build tool, using
definitions from the [https://pagure.io/fedora-kiwi-descriptions
fedora-kiwi-descriptions] repository.
This has enabled Fedora Cloud to introduce 64-bit ARM cloud images for
Azure and Google Cloud, as well as 64-bit ARM Vagrant images.
--
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 Change Proposal: LLVM 18 (System-Wide)
m17 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-18. 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-18 update. * Release engineering: [https://pagure.io/releng/issue/11845 #11845] * 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 == This change should not impact upgrades. == 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 18. == User Experience == == Dependencies == Packages that depend on one of the llvm packages will need to be updated to work with LLVM18 or will need to switch to using one of the llvm17 compat packages. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) If there are major problems with LLVM 18, the compatibility package provide a way for other packages to continue using LLVM 17. * Contingency deadline: Final Freeze == Documentation == LLVM sub-projects in Fedora have been updated to version 18: *llvm *clang *lld *lldb *compiler-rt *libomp *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
F40 Change Proposal: Replace Kubernetes 1.28 in Rawhide (F40) with v1.29 (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/Kubernetes-1.29 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 == Replace Kubernetes 1.28 in rawhide (F40) with v1.29. == Owner == * Name: [[User:buckaroogeek| Brad Smith]] * Email: bradley.g.sm...@gmail.com == Detailed Description == The upstream Kubernetes project just released Kubernetes (K8S) v1.29. The upstream k8s team maintains 3 versions concurrently. Fedora provides a target version of Kubernetes with each release. Fedora 38 has k8s v1.26; Fedora 39 has k8s v1.27, and rawhide (F40) currently has k8s v1.28. If approved this change will replace k8s v1.28 with k8s v1.29 in rawhide for the F40 release. See https://src.fedoraproject.org/rpms/kubernetes for the current k8s packages in Fedora. == Feedback == TBD == Benefit to Fedora == Fedora F40 will have the most current Kubernetes version when F40 is released to production. This will enable Fedora users to deploy and maintain current Kubernetes on Fedora Server and Fedora CoreOS using Fedora provided rpms. == Scope == * Proposal owners: Execute communication plan (community blog and mailing list posts) announcing the change. Test and deploy the update (already available in COPR). * Other developers: Coordinate with the CRI-O packager so that they release a compatible version of CRI-O. Kubernetes and CRI-O have the same release cycle and version numbering, i.e kubernetes v1.29 requires cri-0 1.29 (if cri-o is used as the container runtime interface). * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: n/a == Upgrade/compatibility impact == Kubernetes update guidelines do not permit a version skip. For example, if a Kubernetes cluster is currently using Kubernetes v1.27, then in order to update to k8s v1.29, first v1.28 needs to be deployed. Skipping versions, as this proposal does, requires effective communications and an effective replacement. In this instance, Kubernetes v1.28 will be available from COPR. There is another change request in DRAFT form that addresses this problem by shifting to multiple versioned packages of Kubernetes for each release (i.e. the package changes from kubernetes-1.29.f40 to kubernetes1.29-1.29.f40 and so on. The Kubernetes user community is somewhat used to using COPR for past releases. Kubernetes 1.23 was also skipped in Fedora and only available in COPR. Kubernetes 1.25 was initially provided in Fedora 37 but moved to COPR when upstream adopted a version of the go language not available for F37. == How To Test == == User Experience == Users managing kubernetes clusters using Fedora packages on Fedora machines will need to be aware of this change. An unplanned version update can break a cluster, hence rawhide is the best starting point for this update. == Dependencies == None. == Contingency Plan == == 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
F39 Election Results
Hi folks, The elections for the Fedora Linux 39 cycle have completed. ## Fedora Council Akashdeep Dhar is elected to the Fedora Council ## Fedora Engineering Steering Committee (FESCo) The following candidates are elected to FESCo: * Kevin Fenzi * Zbigniew Jędrzejewski-Szmek * David Cantrell * Tomáš Hrčka * Josh Stone ## Fedora Mindshare Committee Luis Bazan is elected to the Fedora Mindshare Committee. Congratulations to all those elected and thank you to the candidates and voters. For more details, see the Community Blog post: https://communityblog.fedoraproject.org/f39-election-results/ Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)
e are already beyond of point to return. We are heading to explore strange new worlds... to boldly go where no man has gone before. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package. == Documentation == [https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ Allowed Licenses] [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used Update existing packages] == Release Notes == In Fedora 40, all core RPM packages use SPDX identifiers as a standard. In total XX percent of packages have been migrated to SPDX identifiers. The remaining packages are estimated to be migrated in upcoming releases of Fedora. -- 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 Change Proposal: Move /var/run selinux-policy entries to /run (Self-Contained)
wiki -> https://fedoraproject.org/wiki/Changes/Move_var_run_selinux_policy_entries_to_run 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 == Actual path for system runtime files moved from /var/run to /run some 10 years ago [1], but the policy has been managed since then in a way that keeps the old entries and have updates still with the incorrect path while the real path is handled by file equivalency feature. This can confuse sysadmins not to be sure which path should be actually used and can also effect in userspace tools not working properly [2]. [1] https://fedoraproject.org/wiki/Features/UsrMove [2] https://bugzilla.redhat.com/show_bug.cgi?id=2241366 == Owner == * Name: Zdenek Pytela * Email: zpyt...@redhat.com == Detailed Description == The change actually means just replacing "/run = /var/run" file-context equivalency rules with "/var/run = /run". While the change as such is quite simple, it can have effect on other components using their own selinux policy with file-context entries. == Feedback == == Benefit to Fedora == Removing technical debt which originated 10 years ago. More straightforward handling of file-context entries in the /run filesystem. == Scope == * Proposal owners: ** Add all relevant patches to upstream repository ** Ensure the system boots with the targeted policy ** Ensure the system boots with the mls policy ** Ensure updates from older releases work, more specifically with custom selinux packages installed. * Other developers: ** Developers of custom selinux policies need to confirm system updates work. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: No update required. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Users can be affected by this change if they use a local policy with file-context entries in /run which occurs quite rarely, but is possible. == How To Test == * Install a new system and check for error messages and audit records. * Update an existing system and check if all updates completed without an error. * Optionally, install and boot the selinux-policy-mls package. * Check for errors reported by dnf or rpm. == User Experience == There should be no visible change for end users. The change should be transparent, without any further action needed on the system. System admins may need to take an action based on compatibility with the changes. == Dependencies == Components with a custom selinux policy: container-selinux pcp cockpit == Contingency Plan == * Contingency mechanism: Revert all changes in case of serious problems with updates. * Contingency deadline: 2024-02-06 (Branch Fedora Linux 40 from Rawhide) * Blocks release? No * Blocks product? No == Documentation == To be added later. == 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
Re: F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)
Correction to title - SPDX Licence Phase 3 -- ___ 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 Change Proposal: Podman 5 (Self-Contained)
Wiki https://fedoraproject.org/wiki/Changes/Podman5 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 == Ship Podman 5 in Fedora 40. == Owner == * Name: [[User:lsm5| Lokesh Mandvekar]], [[User:mohanboddu| Mohan Boddu]] == Detailed Description == == Feedback == == Benefit to Fedora == Podman 5 will: * No longer support cgroups v1 * Deprecate CNI plugins * Deprecate Boltdb * Have passt as the default rootless network service instead of slirp4netns * Support stable `--format` Go template structs * Isolate podman bindings leading to improved usability * Allow better handling of containers.conf == Scope == * Proposal owners: * 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 Community Initiatives: == Upgrade/compatibility impact == Podman 5 will come with breaking changes affecting upgradability: * CGroups v1 environments will be required to switch to CGroups v2 * CNI plugin environemnts will need to switch to netavark * Changes in `--format` Go template structs == How To Test == Probably best handled in a Podman Test Day aligned with Fedora 40 Test Days. * Install Fedora 40 * Install Podman 5 * Run test cases / suite (TBD) == User Experience == Podman 5 will provide better usability of Podman bindings, easier to maintain containers.conf and other configuration files along with database performance improvements and CLI enhancements. == Dependencies == Projects / Packages likely to be affected: * Cockpit * CoreOS * Toolbox * Silverblue / Kinoite * Podman Desktop == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == 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
F40 Change Propsal: Boost 1.83 upgrade (System-Wide)
ust their code if the new Boost release is not source-compatible. == Dependencies == Packages that must be rebuilt: $ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u All clients: $ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F40 with Boost 1.81, which is already in rawhide. * Blocks release? No * Blocks product? None == Documentation == * https://www.boost.org/users/history/version_1_83_0.html (released on 11th August 2023) * https://www.boost.org/users/history/version_1_82_0.html (released on 14th April 2023) * https://www.boost.org/users/history/version_1_81_0.html (released on 14th December 2022) * https://www.boost.org/development/index.html == 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
F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
program or
library itself, which is not trivial. The two mechanisms in this
Proposal are intended for the packages which do not support IFUNCs or
some other equivalent mechanism.
[1]
https://hackweek.opensuse.org/all/projects/support-glibc-hwcaps-and-micro-architecture-package-generation
[2]
https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0002-march.rst
[3] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
[4]
https://blog.centos.org/2023/08/centos-isa-sig-performance-investigation/
[5] https://jasoncc.github.io/gnu_gcc_glibc/gnu-ifunc.html
Glibc-hwcaps together with the new feature in systemd provide a
generic mechanism. It will be up to individual packages to actually
provide code which makes use of it. Individual package maintainers are
encouraged to benchmark their packages after recompilation, and
provide the optimized variants if useful. (I.e. the code in question
is measureably faster '''and''' the program is ran often enough for
this to make a difference.)
The Change Owners will implement the packaging changes for a few
packages while developing the general mechanism and will submit those
as pull requests. Other maintainers are asked to do the same for their
packages.
Optimized variants of programs and libraries MAY be packaged in a
separate subpackage. The general packaging rules should be applied,
i.e. a separate package or packages SHOULD be created if it is files
are large enough.
Available benchmark results [2,4] are narrow and not very convincing.
We should plan an evaluation of results after one release. If it
turns out that the real gains are too small, we can scrap the effort.
On the other hand, we should also consider other architectures. For
example, microarchitecture levels `z{14,15}` for `s390x` or
`power{9,10}` for `ppc64le`. Other architectures are not included in
this Change Proposal to reduce its scope.
== Feedback ==
== Benefit to Fedora ==
The developers who are interested in this kind of optimization work
can perform it within Fedora, without having to build separate
repositories. The users who have the appropriate hardware will gain
performance benefits. Faster code is also more energy-efficient. The
change will be automatic and transparent to users.
Note that other distributions use higher microarchitecture levels. For
example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use
x86-64-v3, and other distros provide optimized variants (OpenSUSE,
Arch Linux). We implement the same change in Fedora in a way that is
scoped more narrowly, but should provide the same performance and
energy benefits.
== Scope ==
* Proposal owners:
** Extend systemd to set the executable search path using the same
criteria as the dynamic linker.
** Implement packaging changes for at least one package with a library
and at least one package with executables and submit this as pull
requests.
** Provide a pull request for the Packaging Guidelines to describe the
changes listed in Description above.
* Other developers:
** Do benchmarking and implement packaging changes for other packages
if beneficial.
* Release engineering: [https://pagure.io/releng/issue/11864 #11864]
* Policies and guidelines: TBD.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
* Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system.
* Install one or more packages which provide optimized code.
* Restart the system or re-login to reinitialize `$PATH`.
* Check that appropriate directories are present in `$PATH`.
* Run some benchmarks and check that the optimized code is indeed faster.
== User Experience ==
There should be no impact for users. If the optimized code is
available and installed for their hardware, various tasks may finish
faster and use less energy.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Undo the changes in packages which introduced
them and recompile.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
== Release Notes ==
Packages which benefit from being compiled for higher AMD64
microarchitecture levels (`x86-64-v2`, `x86-64-v3`, `x86_64-v4`) are
now provided with optimized variants which will be used automatically
on appropriate CPUs. This includes: TBD1, TBD2, TBD3.
--
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:
F40 Change Proposal: GNU Toolchain for F40 (System-Wide)
nges required for glibc 2.39 will be noted here: https://sourceware.org/glibc/wiki/Release/2.39#Packaging_Changes == How To Test == The GNU Compiler Collection has its own test suite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own test suite which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. The GNU Binutils has its own test suite which is run during the package build and examined by binutils developers before being uploaded. The regression test suite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own test suite which is run during the package build and examined by gdb developers before being uploaded. The regression test suite is run to verify the correct operation of the debugger. == User Experience == Upgrading the 4 main GNU Toolchain components (gcc, binutils, glibc, and gdb) ensures that users have an up to date working system compiler, assembler, static linker, core language runtimes (C, C++, etc), dyanmic linker, and debugger. All of these components are being updated to provide support for newer language features, and hardware features; enabling users to make use of these features for their applications. In some cases the components are updated in a synchronized fashion if a feature requires support across the components that constitute the implementation e.g. compiler feature that requires language library support. == Dependencies == All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 40 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime. == Contingency Plan == * Contingency mechanism glibc: If glibc 2.39 proves too disruptive to compiling the distribution we could revert to 2.38, but given that Rawhide has started tracking glibc 2.39, no show-stopper problems are expected. At this point we can still revert to upstream version 2.38 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism binutils: If binutils 2.41 proves too distruptive to assembling and linking the distribution we could revert to 2.40, but given that Rawhide is using 2.41, no show-stopper problems are expected. At this point we can still revert if insurmountable problems appear, but to do so may require a mass rebuild if the defects involve generated binaries. * Contingency mechanism for gcc: If gcc 14 proves too disruptive to compiling the distribution we could revert to gcc 13.2. * Contingency deadline: Fedora mass rebuild on 2024-01-17. * Blocks release? ** Yes, upgrading to gcc 14.0 does block the release. ** Yes, upgrading to binutils 2.41 does block the release. ** Yes, upgrading to glibc 2.39 does block the release. ** No, upgrading to gdb 13+ does not block the release. == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The binutils manual contains the documentation for the release and doesn't need any more additional work. The glibc manual contains the documentation for the release and doesn't need any more additional work. The gdb manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == See https://gcc.gnu.org/gcc-14/changes.html for the GNU Compiler Collection version 14 release notes. The GNU C Library version 2.39 will be released at the beginning of February 2024. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD The GNU Binary Utilities version 2.41 was released August 2023. The current release notes: https://sourceware.org/pipermail/binutils/2023-July/128719.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
F40 Change Proposal: Wifi MAC Randomization (System Wide)
sed. == User Experience == Users will experience an additional layer of privacy without any required action on their part. The change is transparent, with minimal impact on the day-to-day user experience. However, for those with specific network configurations reliant on static MAC addresses, this update may require manual adjustments to network profile settings. Users in such scenarios will need to be aware of the change and how to revert to a fixed MAC address if necessary, ensuring their network connectivity aligns with their requirements. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to previous MAC address handling if significant issues arise. * Contingency deadline: Beta freeze of Fedora 40. * Blocks release? No == Documentation == No documentation change is required. == Release Notes == The change will 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
F40 Change Proposal: Change Firefox Desktop File (System-Wide)
Wiki -> https://fedoraproject.org/wiki/Changes/RenameFirefoxDesktopFile 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 == Recent Firefox desktop file (firefox.desktop) does not comply with DBus/Gnome search provider rules thus Firefox can't provide DBus Gnome search service. We should change Firefox desktop file from firefox.desktop to org.mozilla.firefox.desktop. == Owner == * Name: [[User:stransky| Martin Stransky]] * Email: == Detailed Description == Firefox needs to provide desktop file in expected format to pair DBus service and Gnome search service together to make Gnome search service work. == Feedback == == Benefit to Fedora == We'll fix already broken feature. == Scope == * Proposal owners: Desktop file name is changed in Firefox 121.0. * Other developers: Fedora Workstation needs update Firefox desktop name (hardcoded in gnome-shell) to correctly place Firefox to Gnome taskbar as default application. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] No need to coordinate with rel-eng. * 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 == Should not impact. == How To Test == 1) Open Firefox 2) Type something to Gnome search 3) It works Test also KDE/Plasma it doesn't crash (https://bugzilla.redhat.com/show_bug.cgi?id=2017123) == User Experience == Enabled Gnome shell search provider for Firefox. == Dependencies == None == Contingency Plan == * Revert desktop file name change in Firefox package. * Blocks release? No == Documentation == == 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
F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
tes == 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
F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
ks to `../bin/foo` for every `foo` that is uninstalled from `/usr/sbin`. ** Add a `%posttrans` trigger to `filesystem` package to check that `/usr/sbin` only contains symlinks and do `ln -fs bin /usr/sbin`. (Those scriptlets make it easier to have a smooth transition. At all times, the old paths will still work. After the transition is complete we can drop the scriptlets and provide the `/usr/sbin` symlink in the `filesystem` package.) ** Adjust systemd package to build with `-Dsplit-bin=no`. * Other developers: programs which user consolehelper and install the same name under both directories will need to be adjusted to use a different directory. Some of those packages may be retired instead. See list below. * Packages using usermode with binaries in both directories: ** `anaconda-live` ** `beesu` ** `chkrootkit` ** `hddtemp` ** `mate-system-log` ** `setuptool` ** `subscription-manager` ** `system-switch-java` ** `xawtv` * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_effect_of_the_usrmove_fedora_feature will need to be adjusted (and most likely retitled ;)) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: nope == Upgrade/compatibility impact == The change should be mostly invisible for users. While the transition is ongoing, both sets of paths should work and users should have both directories in `$PATH`. Once the transition is finished, both sets of paths should work, but users will only have `/usr/bin` in `$PATH`. == How To Test == == User Experience == == Dependencies == == Contingency Plan == * If the move of a binary of any specific package causes problems, we can create a compat symlink like `/usr/sbin/foo → ../bin/foo` using a `%postin` scriptlet in that package. * If the change is causing problems in general and needs to be reverted, we'd need to undo the changes to macro definitions in `rpm` and rebuild some or all packages. * Contingency deadline: in principle can be done at any time, but would require a rebuild of some or all affected packages. * Blocks release? no. It is OK if the change is done partially. == Documentation == TBD. == 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
F40 Change Proposal: Golang 1.22 (System-Wide)
Wiki -> https://fedoraproject.org/wiki/Changes/golang1.22
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.22 in Fedora 40.
== 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.22 in Fedora
40. Go 1.22 is expected to be released in February 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 Go language and projects written in
it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.22
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 40, 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 Community Initiatives:
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 ==
1. Install golang 1.22 from rawhide and use it to build your
application(s)/package(s).
2. Scratch build against rawhide.
3. Your application/package built using golang 1.22 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.21.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.22
== 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
F40 Change Proposal: Haskell GHC 9.6 and Stackage LTS 22 (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.6_and_Stackage_22 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the GHC Haskell compiler from major version 9.4 to 9.6 and Haskell packages from Stackage LTS 21 to LTS 22 versions. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: == Detailed Description == For Fedora 40, the main [https://www.haskell.org/ghc/ GHC] Haskell compiler package will be updated from version [https://www.haskell.org/ghc/download_ghc_9_4_5.html 9.4.5] to the latest stable [https://www.haskell.org/ghc/download_ghc_9_6_3.html 9.6.3] or newer bugfix release (rebasing the [https://src.fedoraproject.org/rpms/ghc/ ghc] package with the [https://src.fedoraproject.org/rpms/ghc9.6/ ghc9.6] package). Along with this, Haskell packages in [https://www.stackage.org Stackage] (the stable Haskell source package distribution) will be updated from the versions in [https://www.stackage.org/lts-21 LTS 21] to latest [https://www.stackage.org/lts-22 LTS 22] release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. == Feedback == == Benefit to Fedora == Fedora users will have the latest stable Haskell compiler release, package tools, and current Haskell packages from latest Stackage LTS. GHC 9.6.3 is the current stable version of GHC with various enhancements and fixes (see the release notes linked in the Documentation section for more details about new features and improvements in 9.6). == Scope == * Proposal owners: ** update rawhide ghc9.4 is build against itself ** rebase ghc to 9.6.3 ** refresh packagings with the latest cabal-rpm release if needed ** update packages to latest [https://www.stackage.org/lts-22 Stackage LTS 22] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order using fbrnch ** push the sidetag through Bodhi to rawhide ** deal with obsoleting ghc9.6 if needed * Other developers: no actions should be needed * 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 Community Initiatives: N/A == Upgrade/compatibility impact == Any dropped packages will have obsoletes added. Otherwise there should not be any direct upgrade impact. Users' Haskell projects will get built with ghc-9.6 when they next build them and might need some minor code tweaks (see the release notes linked below). == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad, Agda * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep ; cabal install * install ghc8.10, ghc9.0, ghc9.2, ghc9.4, or ghc*devel * test upgrades of F39 Haskell packages to F40 == User Experience == Users will have the most recent stable major version of `ghc` and Haskell libraries and tools available to them. This makes it easier to build the latest versions of Haskell projects. In particular `cabal-install` will also be updated from 3.8 to 3.10, `pandoc` will be updated to 3.1, and `stack` to 2.13. == Dependencies == == Contingency Plan == * Contingency mechanism: ** Change owner will drop the new builds and revert dist-git back to the versions in F39 * Contingency deadline: Beta Freeze == Documentation == * https://downloads.haskell.org/~ghc/9.6.3/docs/html/users_guide/9.6.1-notes.html == 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 Linux 39 Elections Voting are now Open!
Hi all, The F39 elections voting period has now opened for FESCo <https://elections.fedoraproject.org/about/f39%20fesco%20election>, Mindshare <https://elections.fedoraproject.org/about/f39%20mindshare%20election> and Council <https://elections.fedoraproject.org/about/f39%20council%20election> . Voting closes on Thursday, December 21st. Thanks! Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Java 21 (System-Wide)
Your javac is run with wrong source/tag parameters. [https://duckduckgo.com/?t=ffsb=javac+source+target=web net search will give you quick answer] ** Fixes are: *** [https://src.fedoraproject.org/rpms/CardManager/blob/2d6e0f1e3d23d864c1ed0b20f6076fa4c9a15c21/f/bumpJdk.patch example patch for netbeans generated ant] == 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
F40 Change Proposal: Run Anaconda dir/image installations only in non-interactive text mode (Self-Contained
Wiki -> https://fedoraproject.org/wiki/Changes/Anaconda_dir_and_image_installations_in_automated_text_mode == Summary == Anaconda will require a fully defined kickstart file for installations into an image or a directory and these installations will run only in a non-interactive text-based user interface. == Owner == * Name: [[User:vponcova| Vendula Poncova]] * Email: * Package: anaconda * Name: [[User:bcl| Brian C. Lane]] * Email: * Package: lorax (livemedia-creator) == Detailed Description == The Anaconda installer supports installations into a local image (via the --image cmdline option) or a local directory (via the --dirinstall cmdline option, the directory is usually a mount point of a custom image). These types of installations are supported by two user interfaces (text-based and GTK-based) in fully interactive, partially interactive and non-interactive modes. We believe that there is no strong reason for all these options, so we would like to minimize the scope of this functionality and support only the text-based non-interactive mode (specifically the command-line mode). It means that Anaconda will require a fully defined kickstart file and run only in the text-based user interface (during dir and image installations). == Feedback == == Benefit to Fedora == This is a preliminary step for an eventual deprecation and removal of the Anaconda support for dir and image installations. This functionality is being slowly taken over by [https://www.osbuild.org/ Image Builder] that is explicitly designed for building images and provides a much broader and better support for all kinds of images. Limiting the scope of dir and image installations in Anaconda will allow its developers to focus their resources on more prospective areas. == Scope == * Proposal owners: Will submit a pull request for [https://anaconda-installer.readthedocs.io/en/latest/ anaconda] to run dir and image installations only in the non-interactive text mode and update [https://weldr.io/lorax/livemedia-creator.html livemedia-creator] to reflect these changes if necessary. * Other developers: No impact. * Release engineering: No impact. There should be zero impact on building official Fedora images since these processes are fully automated and use fully defined kickstart files. [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 Community Initiatives: == Upgrade/compatibility impact == == How To Test == == User Experience == It will be still possible to use anaconda and livemedia-creator for installations into a local image or a directory with a fully defined kickstart file. Users can notice the following changes: * If a user requests a dir or image installation, the installer runs in the text mode. * If the user doesn't specify a kickstart file, the installer will report an error and abort. * If the specified kickstart file is incomplete, the installer will report an error and abort. * All options for specifying the user interface will be ignored (for example, --graphical) == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == 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
F40 Change proposal: Bpfman as default eBPF manager (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/DefaultBpfman This is a *proposed* Change for Fedora Linux. This document represents a proposed Change. As part of the [Changes process](https://docs.fedoraproject.org/en-US/program_management/changes_policy/), 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 == bpfman: An eBPF Manager bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. Its notable features encompass: * System Overview: Provides insights into how eBPF is utilized in your system. * eBPF Program Loader: Includes a built-in program loader that supports program cooperation for XDP and TC programs, as well as deployment of eBPF programs from OCI images. * eBPF Filesystem Management: Manages the eBPF filesystem, facilitating the deployment of eBPF applications without requiring additional privileges. We do aim to have this included in Fedora so it becomes the de-facto and easy way to load eBPF programs. == Owner == * Name: [[User:dmellado| Daniel Mellado]] * Email: dmell...@fedoraproject.org * Name: [[davetucker| Dave Tucker]] * Email: datuc...@redhat.com * Name: [[tohojo| Toke Høiland-Jørgensen]] * Email: thoil...@redhat.com == Detailed Description == bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. bpfman is a software stack that aims to make it easy to load, unload, modify and monitor eBPF programs whether on a single host, or in a Kubernetes cluster. bpfman includes the following core components: * bpfman: A system daemon that supports loading, unloading, modifying and monitoring of eBPF programs exposed over a gRPC API. * eBPF CRDS: bpfman provides a set of CRDs (XdpProgram, TcProgram, etc.) that provide a way to express intent to load eBPF programs as well as a bpfman generated CRD (BpfProgram) used to represent the runtime state of loaded programs. * bpfman-agent: The agent runs in a container in the bpfman daemonset and ensures that the requested eBPF programs for a given node are in the desired state. * bpfman-operator: An operator, built using Operator SDK, that manages the installation and lifecycle of bpfman-agent and the CRDs in a Kubernetes cluster. bpfman is developed in Rust and built on top of Aya, a Rust eBPF library. == Feedback = N/A == Benefit to Fedora == bpfman is a software stack simplifying the management of eBPF programs in Kubernetes clusters or on individual hosts. It comprises a system daemon (bpfman), eBPF Custom Resource Definitions (CRDs), an agent (bpfman-agent), and an operator (bpfman-operator). Developed in Rust on the Aya library, bpfman offers improved security, visibility, multi-program support, and enhanced productivity for developers. For Fedora, integrating bpfman would streamline eBPF program loading. It enhances security by restricting privileges to the controlled bpfman daemon, simplifies deployment in Kubernetes clusters, and offers improved visibility into running eBPF programs. This integration aligns with Fedora's commitment to providing efficient and secure solutions, making it easier for users to leverage the benefits of eBPF in their systems. == Scope == * Proposal owners:Submit / review pull-requests and packages to Fedora * Other developers: https://copr.fedorainfracloud.org/coprs/g/ebpf-sig/bpfman-next/ migrate these packages from copr to Fedora alongside proposal owners * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == N/A == How To Test == N/A == User Experience == Users would be able to easily load eBPF programs within Fedora in a way more simpler way than currently using bpfman. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == * https://bpfman.io/main/ == 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
F40 Change Proposal: ibus 1.5.30 (Self-Contained)
Wiki -> https://fedoraproject.org/wiki/Changes/IBus_1.5.30 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. = IBus 1.5.30 = == Summary == IBus 1.5.30 will have some enhancements. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * `ibus start` and `ibus restart` commands will work for Plasma Wayland. (They have worked in Plasma Xorg.) * "Preference" menu item will be shown in IBus activate menu in Plasma Wayland. (The change is not needed in Plasma Xorg since the context menu is also available.) == Feedback == == Benefit to Fedora == This change will enhance the usability in Plasma Wayland. == Scope == * Proposal owners: ibus 1.5.30 * Other developers: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == === `ibus restart` === # Log into Plasma wayland desktop session and confirm ibus-daemon is running # Open konsole # Run `ibus restart` # ibus-daemon is restarted === Panel menu === # Log into Plasma wayland desktop session and confirm ibus-daemon is running # Click on the IBus panel menu # "Preference" menu item is available == User Experience == `ibus restart` command has been useful for users to reload the IBus configurations in non-Plasma Wayland desktop sessions and it will work in Plasma Wayland too. Currently IBus can toggle the activate menu and context menu with clicking the mouse middle button on the panel icon but most users won't have to use the middle clicking after the "Preferences" menu item is shown in the activate menu. == Dependencies == IBus will use D-Bus methods of Plasma Wayland to reload the on-screen keyboard configuration or show the panel menu. == Contingency Plan == * Contingency mechanism: Revert the change to ibus. * Contingency deadline: Beta release == 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
