F37 Change Proposal: libsoup 3: Part One (System-Wide Change)
6.x86_64 srain-0:1.4.0-2.fc36.x86_64 surf-0:2.0-13.fc36.x86_64 switchboard-plug-onlineaccounts-0:6.5.0-1.fc36.x86_64 syncevolution-libs-1:2.0.0-3.fc36.x86_64 syncevolution-libs-akonadi-1:2.0.0-3.fc36.x86_64 taxi-0:2.0.1-2.fc36.x86_64 telepathy-gabble-0:0.18.4-18.fc36.x86_64 telepathy-salut-0:0.8.1-27.fc36.x86_64 uhttpmock-0:0.5.0-15.fc36.x86_64 vfrnav-0:20201231-22.fc36.x86_64 webkit2gtk3-0:2.36.3-1.fc36.x86_64 webkit2gtk3-devel-0:2.36.3-1.fc36.x86_64 xfce4-screenshooter-0:1.9.8-4.fc36.x86_64 xfce4-screenshooter-plugin-0:1.9.8-4.fc36.x86_64 xfce4-weather-plugin-0:0.11.0-3.fc36.x86_64 yelp-libs-2:42.1-1.fc36.x86_64 == Contingency Plan == * Contingency mechanism: We may be required to switch particular packages back to libsoup 2. Due to interdependencies between packages, this could be quite disruptive. * Contingency deadline: Beta freeze * Blocks release? Possibly. Applications that crash on startup will fail the "basic functionality test" release criterion. == Documentation == [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Migrating from libsoup 2] == Release Notes == Many applications and libraries now use libsoup 3, a new version of libsoup that adds support for HTTP/2. -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: Unfiltered Flathub (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 == The flatpak remote for Flathub will have no filtering, making all the Flathub content available in GNOME Software and via the flatpak commandline. == Owner == * Name: Workstation WG * Email: mcla...@redhat.com == Detailed Description == Fedora includes a flatpak repo definition for Flathub in the fedora-flathub-remote package. So far, this remote was filtered by an allowlist that only made a limited subset of software from Flathub available. We've been told that it is ok for us to remove the filtering and make all of Flathub available. The filtering mechanism itself will still be there, and it will be possible for us to reinstate a filter via a package update, should the need arise in the future. The Flathub remote is available to users who opt-in to enabling third-party software repositories in either GNOME Initial Setup or GNOME Software. Users who do not opt in will not see anything from Flathub. In case of overlaps, GNOME Software will prefer Fedora flatpaks over Flathub flatpaks. It is always possible for the user to manually select a different source for individual applications. == Feedback == This change proposal has previously been discussed here: https://pagure.io/fedora-workstation/issue/300 == Benefit to Fedora == More software will be easily available to Fedora users. Additionally, the filtered Flathub has not been popular with users. Users have been confused and displeased that our Flathub remote contains only a small subset of Flathub, rather than the full Flathub. Dropping the filter will resolve this criticism. == Scope == * Proposal owners: Remove the allowlist in /usr/share/flatpak/fedora-flathub.filter, or replace it with one that allows everything * Other developers: GNOME Software developers: Verify that the priorities between repos and packaging formats work out as desired * Release engineering: No work needed * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Existing Fedora installations with a configured Fedora Flathub remote will pick up the new, permissive filter. == How To Test == When third-party software is not enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should not appear in GNOME Software. When third-party software is enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should appear. == User Experience == When opening GNOME Software, all the applications that are available on Flathub will show up in search results. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: Reinstate the filtering we had in Fedora 36 * Contingency deadline: Beta * Blocks release? No == Documentation == * [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md fedora-third-party] * [https://github.com/flathub/flathub/wiki Flathub wiki] * [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes/ Comparison of Fedora Flatpaks and Flathub remotes] == Release Notes == The Fedora Flathub remote now exposes all content from Flathub, instead of only a small subset. Flathub is not enabled by default. To enable software from Flathub, turn on third-party software in GNOME Initial Setup or GNOME Software. -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: IBus 1.5.27 (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 == In IBus 1.5.27, `ibus restart` subcommand will be enhanced to be able to restart ibus-daemon in GNOME desktop, `ibus im-module` subcommand will be added to get internal gtk-im-module value in an GTK instance, ibus-setup will provides custom themes for the IBus candidate window. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * `ibus restart` subcommand will be enhanced to be able to restart ibus-daemon via systemd for GNOME desktop. ibus-daemon is launched via systemd in GNOME desktop. `ibus restart` will restart ibus-daemon with systemd at first and with an IBus API directly at second and it also provides `--help` option to get other option arguments for the subcommand and `--type=direct` and `--type=systemd` subcommands are available. * `ibus im-module` subcommand will be added to get an internal gtk-im-module value from an instance of an GTK instance. Some users would fail to setup IBus and this subcommand will help them to check whether "ibus" is set to the gtk-im-module in the actual process. * ibus-setup will provides custom themes in the "Advanced" tab for IBus candidate window. IBus candidate window is composed by GTK and If the current desktop is composed by GTK likes GNOME, the desktop provides a utility to customize the themes. But if not, this feature is useful for the users. == Benefit to Fedora == Users can restart ibus-daemon with `ibus restart`. When users install new IBus engines, ibus-daemon has to be restarted to load the new engine lists, If users might encounter a bug, users would like to restart ibus-daemon. IM developers also sometimes restart ibus-daemon to debug IBus or the engines. `ibus im-module` subcommand is also useful when a users failed to setup IBus. Providing IBus custom themes is useful for Plasma desktop which theme utility does not change GTK themes. == Scope == * Proposal owners: ibus * Other developers: NONE * Release engineering: * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == `ibus restart` should not have any regressions in any desktops. == How To Test == * IBus restart ** Log into GNOME desktop session ** Run `ibus restart` and then ibus-daemon PID is changed. * IBus im-module ** Run `ibus im-module` and get "ibus" * IBus custom theme ** Log into Plasma desktop session ** Run ibus-setup and configure IM engines in "Input Method" tab, who can show the candidate window likes ibus-libpinyin, ibus-anthy. ** Run ibus-setup and configure custom themes in "Advanced" tab and confirme the theme of the candidate window is changed. == User Experience == `ibus restart` command line interface is available to restart the input method features and ibus-setup provides custom themes for ithe appearance of the input method candidate window. == Dependencies == `ibus restart --type=systemd` requires systemd. `ibus im-module` subcommand requires gtk4 or gtk3 or gtk2. == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No == Documentation == TBD == Release Notes == TBD -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: Firefox Langpacks Subpackage (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 == Firefox langpacks, which have been bundled in the Fedora firefox base package until now, will be moved to a firefox-langpacks subpackage. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: * Name: [[User:Stransky| Martin Stransky]] * Email: == Detailed Description == The firefox packages carries many langpacks containing translations and other localization data for different countries and languages. This Change will move them to a separate subpackage pulled in as a weak dependency by the base package. == Feedback == Initial discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2035178 == Benefit to Fedora == This makes Fedora a little more modular: going forward it will be possible to install firefox without having to have all the langpacks installed too. == Scope == * Proposal owners: ** Update Rawhide firefox to add the langpacks subpackage ([https://src.fedoraproject.org/rpms/firefox/pull-request/43 PR]) * Other developers: none * Release engineering: [https://pagure.io/releng/issue/10858 #10858] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == When upgrading to Fedora 37, firefox's new weak dependency will pull in the firefox-langpacks subpackage, so users should not experience any change by default. == How To Test == * install firefox and check that firefox-langpacks gets pulled in * test that firefox's langpacks are functioning normally * test upgrade from F36 to F37 and ensure that the firefox-langpacks subpackage gets installed. == User Experience == Users will have a new firefox-langpacks subpackage installed by default. If they don't require localization they can remove it and benefit from lighter firefox updates and save about 50MB of diskspace. == Dependencies == None == Contingency Plan == * Contingency mechanism: proposal owners will revert firefox.spec to not subpackage langpacks * Contingency deadline: before final freeze * Blocks release? No == Documentation == None == Release Notes == Firefox's langpacks have been moved to a subpackage for greater install flexibility. -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: MAC Address Policy none (System-Wide Change)
o find out what the Fedora community thinks is the most appropriate default. The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 [rh#1921094]]. == Benefit to Fedora == Pros: - Consistent behavior with RHEL8 and RHEL9. - Avoid race of udev and the tool that creates the interface. - Bridge and bond interfaces can get the MAC addresses from their first port. In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will get a MAC related to one of its physical NIC devices. In the case of provisioning new systems (especially in a large datacenter) information about the server can be used to configure the network environment (DHCP, Firewall, etc) before the server is ever even powered on. This does mean that you may have to update your network environment configuration if you replace a NIC (con), but that you won't have to update your network environment configuration if you re-install your server (pro), which is what you'd have to do now with `MACAddressPolicy=persistent`. Cons: - Deviate from upstream systemd. It is desirable that RHEL and Fedora behaves similar. A possible outcome could be the current behavior stays and RHEL 10 would change behavior. On the other hand, different distributions (or even Fedora spins) have different uses and needs. Deviating might be fine. In the same vein, there is also a desire to stay close to upstream systemd behavior. But the uses of systemd project go beyond Fedora/RHEL, so deviating here may also be fine. == Scope == * Proposal owners: The main goal of this request is to generate productive discussion and find the desired behavior. The implementation/changes are either way very simple. * Other developers: Other projects that wish a certain MAC address are welcome to set it for their devices. Including using udev's MACAddressPolicy. * Release engineering: 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 Objectives: == Upgrade/compatibility impact == After the change, the MAC address for the affected device types changes. == How To Test == 1) Create a software device two times, for example `ip link add type bridge`. Note that the MAC address is either stable or random, depending on the `MACAddressPolicy=`. 2) Note that if the software device has the MAC address set initially, udev does not change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on `/sys/class/net/$dev/addr_assign_type`. 3) Create a bridge/bond interface without setting the MAC address. Note that if `MACAddressPolicy=none`, the MAC address is random at first. Note that attaching the first port will update the controller's MAC address. On the other hand, with `MACAddressPolicy=persistent`, the MAC address of the controller is fixed and not inherited from the port. 4) Run ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done to reproduce the race between a simple tool and udev changing the MAC address. == User Experience == Bond/bridge devices would again get assigned the MAC address of the first NIC added to the device. If we chose to not limit the scope of this change to just bonds/bridges then all software devices would get randomly assigned MAC addresses. == Dependencies == None. == Contingency Plan == If the change is rejected, nothing needs to be done. The change itself will be simple to implement. Contingency deadline: beta freeze Blocks release? No == Documentation == TODO. == Release Notes == -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
" Decision): next release: next release with final Fedora GA content Week 0 (GA release): triple release: testing release promoted from previous next next release contains latest Fedora N content, including Bodhi updates Week 2: triple release: stable release promoted from previous testing, now fully rebased to Fedora N testing and next are now in sync == Contingency Plan == Contingency mechanism: (What to do? Who will do it?) Delay promotion until F38 Contingency deadline: F37 Final release date Blocks release? No == Documentation == https://docs.fedoraproject.org/en-US/fedora-coreos/ -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Stratis 3.1.0 (Self-Contained change)
https://fedoraproject.org/wiki/Changes/Stratis_3.1.0 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 == Stratis 3.1.0 includes significant improvements to the management of the thin-provisioning layers, as well as a number of other user-visible enhancements and bug fixes. == Owner == * Name: ** [[User:dkeefe|Dennis Keefe]] ** [[User:mulhern|Anne Mulhern]] ** [[User:jbaublitz|John Baublitz]] * Email: ** dke...@redhat.com ** amulh...@redhat.com ** jbaubl...@redhat.com == Detailed Description == Stratis 3.1.0 includes significant improvements to the management of the thin-provisioning layers, as well as a number of other user-visible enhancements and bug fixes. Please see this [https://stratis-storage.github.io/thin-provisioning-redesign/ post] for a detailed discussion of the thin-provisioning changes. To support these changes the Stratis CLI has been enhanced to: * allow specifying whether or not a pool may be overprovisioned on creation * allow changing whether or not a pool may be overprovisioned while it is running * allow increasing the filesystem limit for a given pool * display whether or not a pool is overprovisioned in the pool list view Users of the Stratis CLI may also observe the following changes: * A `debug` subcommand has been added to the `pool`, `filesystem`, and `blockdev` subcommands. Debug commands are not fully supported and may change or be removed at any time. * The `--redundancy` option is no longer available when creating a pool. This option had only one permitted value so specifying it never had any effect. stratisd 3.1.0 includes one additional user-visible change: * The minimum size of a Stratis filesystem is increased to 512 MiB. stratisd 3.1.0 also includes a number of internal improvements: * The size of any newly created MDV is increased to 512 MiB. * A pool's MDV is mounted in a private mount namespace and remains mounted while the pool is in operation. * Improved handling of udev events on device removal. * The usual and customary improvements to log messages. Please consult the [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/ stratisd] and [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/ stratis-cli] changelogs for additional information about the 3.1.0 release. == Benefit to Fedora == Users of Fedora will now benefit from Stratis 3.1.0 by: * Change the overprovisioning mode at create time or while running * User can increase the limit of filesystems per pool. The default is 100. * Stratis pool list will display whether or not a pool is overprovisioned * The MDV size is now 512MB, which allows for more filesystems to be created per pool * MDV is now in a private mount namespace, which decreases logging events and user may see faster completion times for commands that required the MDV to be mounted. == Scope == * Proposal owners: ** Update existing stratis-cli package to specify new release ** Update existing stratisd package to specify new release * Other developers: N/A * Release engineering: Self Contained * Policies guidelines: N/A * Trademark approval: N/A == How To Test == * To see the `overprovisioning` field, list the pools `stratis pool list` overprovisioned will equal `OP`, no overprovisioning will equal `~OP` * To set the filesystem limit of a pool: `stratis pool set-fs-limit p1 200` * To see what the filesystem limit is `stratis report engine_state_report` Look for field `fs_limit` in output == User Experience == Other than the changes mentioned above the user experience will be the same. == Dependencies == No new dependencies == Contingency Plan == * Contingency mechanism: * Contingency deadline: N/A * Blocks release? No * Blocks product? No == Documentation == * This content can be viewed on Developer’s [https://stratis-storage.github.io/thin-provisioning-redesign/ blog] for Stratis 3.1 * Thin-provisioning [https://stratis-storage.github.io/thin-provisioning-redesign/ blog] * [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/ stratisd] changelog * [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/ stratis-cli] changelog == Release Notes == [https://stratis-storage.github.io/stratis-release-notes-3-1-0/ Stratis Release Notes] -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the
F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat 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 == We are going to deprecate openssl1.1 package, stop shipping the corresponding devel package, and stop respecting crypto policies in openssl1.1 package itself. == 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. As openssl 1.1 has a predictable EOL, we want to ensure that no new products relying on it will appear in Fedora. == Benefit to Fedora == This proposal ensures than no new packages in Fedora will rely on the deprecated OpenSSL version that will cause an overall increase of security/stability, and will reduce the amount of old packages relying on OpenSSL 1.1 series. It will also reduce the maintenance burden for the OpenSSL maintainers, especially when new CVEs are published. == Scope == * Proposal owners: ** Remove devel package ** eliminate crypto policy support from the main package ** provide assistance in migration to other developers * Other developers: ** Patch their packages to work with OpenSSL 3.0 ** Fedora/RHEL distributions provide some syntax sugar related to https://fedoraproject.org/wiki/Packaging:CryptoPolicies. For the packages still relying to openssl1.1 the syntax provided by crypto policies will no longer be supported. The changes implemented according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies (e.g. using "PROFILE=SYSTEM" as default TLS ciphersuites configuration) should be removed. * 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) == Upgrade/compatibility impact == As Crypto Policy support is removed from openssl1.1, applications will need to adjust the configuration files if they contain the line "PROFILE=SYSTEM" according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies == How To Test == Regular application tests should catch the regressions caught by these changes. == Dependencies == No packages should depend on openssl1.1-devel packages that is eliminated. == Contingency Plan == Revert the shipped configuration Contingency deadline: TBD == Documentation == TBW == Release Notes == TBW -- Vipul Siddharth He/His/Him FPgM team member ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Contributor Tee Shirt Giveaway
On Fri, Apr 22, 2022 at 12:49 PM Leigh Scott wrote: > > Why post something that has expired? Hi leigh, When I shared the email, the giveaway was still active :) given it was just for 24 hours, It had to expire after some time (This is mentioned in the blog) I definitely could have highlighted in the email as well! Hope it was useful to some > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora Contributor Tee Shirt Giveaway
Hey all, As we get ready to release Fedora Linux 36, another anticipated moment has arrived: the Fedora contributor tee shirt giveaway! Sending a huge “THANK YOU!!” to everyone who works to make Fedora the amazing community it is. The Mindshare Committee is excited to be able to share swag with our community to celebrate the latest release of Fedora Linux. Please visit the community blog post[0] to see how to claim yours! [0] https://communityblog.fedoraproject.org/fedora-contributor-tee-shirt-giveaway-claim-yours-today/ On behalf of the Mindshare committee, -- Vipul Siddharth He/His/Him Mentored Project @ Mindshare | DEI advisor @ Fedora Council ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE Weekly Update - Week of January 17th-22nd
including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates --- * epel9 up to 1346 source packages (increase of 188 from last week) * Two talks submitted and accepted for the February CentOS Dojo * State of EPEL * EPEL Packaging Hackfest Kindest regards, -- Vipul Siddharth He/His/Him On behalf of the CPE team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE Weekly Update – Week of December 13th – 17th
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). If you wish to read this in form of a discourse post (or on our commblog), check the post on discussion.fp.o: https://discussion.fedoraproject.org/t/cpe-weekly-update-week-of-december-13th-17th/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative --- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Update -- ### Fedora Infra * Log4j CVE affects our Openshift 3, mitigated via [fix](https://access.redhat.com/solutions/6578441) * Deployed an Openshift Dedicated cluster on AWS still deciding * Lots of spam cleared off mailing lists ### CentOS Infra including CentOS CI * Various activities/preparation for CentOS Linux 8 EOL process * Proposal for SIGs to [switch to RHEL8](https://lists.centos.org/pipermail/centos-devel/2021-December/098779.html) * Preparing needed steps to clear content and remove it from mirrorlist * WIP for Meta group for SIGs, allowing to build+push their -release pkgs (not having to depend on CentOS Stream team for this) * Investigating [openshift template issue](https://pagure.io/centos-infra/issue/555) for newer deployed projects and jenkins * Log4j CVE impact analysis (impacting OCP 4 if Elasticsearch is used, which we are not using) * Stream MVBE infra : renewal process for internal TLS cert ## CentOS Stream Goal of this Initiative --- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates --- * Dealing with a slowdown in rpm signing * Continuing the development Content Resolver enhancements * Various cleanup and docs work at various places ## CentOS Duffy CI Goal of this Initiative --- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates --- * Foundation for background tasks in place * Started work on authentication and the session workflow * CLI polish ## OSCI – Distrobaker monitoring Goal of this Initiative --- This initiative is to improve the Distrobaker monitoring to monitor side-tags and module builds. Distrobaker is a service which rebuilds the CentOS 9 Stream Koji builds for RHEL 9 in Brew. Updates --- * added a barebones implementation of gathering side tag metrics ## EPEL Goal of this initiative --- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates --- * No updates - team on time offs Kindest regards, CPE Team -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE takeover Fedora social hour - today!
Hey folks, The Community Platform Engineering team from Red Hat will join us today for the Fedora Social Hour call. This call would be slightly different from usual ones – as this time we won’t be breaking any rules when you talk $work (like always). We will have both, some from management and some engineers (including me) joining the call. If you have any Infra or CPE questions, we would love to talk and answer (what we do, why we do and what we are going to do are just a few examples). When we are out of questions, expect it to look like a general social hour. If you don't know what Fedora Social hour is, check https://discussion.fedoraproject.org/t/join-us-for-fedora-social-hour-every-week/18869 Looking forward to seeing a lot of you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE Weekly Update - Week of Sept 27th
work on documentation: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/dnf-counting/ Kindest regards & on behalf of the CPE team, -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Kubernetes Development SIG
On Tue, Sep 15, 2020 at 8:26 PM Sumantro Mukherjee wrote: > > > On Tue, Sep 15, 2020 at 7:15 PM Leonardo Rossetti > wrote: > >> Hello all, >> >> I would like to present a Kubernetes Development SIG. >> >> Love the Idea, Leo! count me in :) -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team @ Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Team Engagement Feedback
oops, sent too soon (more like didn't read correctly)! please ignore last email On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote: > > Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > > > Our CPE Review Team > > include: > > * Fedora - mmiller, mnordin, bcotton > > * CentOS - rbowen, bex > > * RHEL - bex, dperpeet, aslobodova > > > Where is EPEL ? > > > > > Remi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team Red Hat w: vipul.dev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Team Engagement Feedback
On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote: > > Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > > > Our CPE Review Team > > include: > > * Fedora - mmiller, mnordin, bcotton > > * CentOS - rbowen, bex > > * RHEL - bex, dperpeet, aslobodova > > > Where is EPEL ? Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL > > > > > Remi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team Red Hat w: vipul.dev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Introductory mail
Hello Everyone, I'm a Computer science student (Christ University, Bangalore, India) and Intern (Fedora QA) at Red Hat. I contribute to the Fedora project (QA) and willing to increase my open source contribution. I recently participated in 'dnf 2.0 testday' and got interested in this project. I would be grateful if someone from you can guide/mentor me. I am familiar with Version control systems and Python. Thanks and regards -- Vipul Siddharth Intern, Red Hat <https://www.facebook.com/siddharthvipul> <https://twitter.com/VipulSiddharth> <https://www.linkedin.com/in/vipul-siddharth-4b96167b/> <https://www.instagram.com/siddharthvipul/> *Mob:* +91 8971357273 <+918971357273> *Web:* vipulsiddharth.blogspot.in/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
