F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros == Summary == Introduce macros, similar to openSUSE's [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints memory-constraints]), for optionally limiting build parallelism for build-time memory-bound packages == Owner == * Name: [[User:salimma|Michel Alexandre Salim]] * Email: michel AT michel-slm DOT name == Detailed Description == Some source packages have a memory usage per build thread higher than the RAM:CPU ratio available in some of our builders. Further, this ratio can be different for different build server on different architectures. At the moment, such packages ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390 ceph], [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14 chromium], [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82 mcrouter]) have to implement their own logic for determining the safe amount of parallelism, and redefine `_smp_build_ncpus`. When this proposal is implemented, they can instead declaratively specify the amount of RAM needed per build thread, e.g. %limit_build -m 8192 for declaring a build thread should be allocated 8GB of RAM. Since Koji supports [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes setting default values for macros], there will be a macro for the default memory limit (name TBD) that, if set, will be used to cap `_smp_build_ncpus` unless overridden by `%limit_build -m`. 0 I'm proposing to tentatively call the macro package `build-constraints-rpm-macros` to allow the possibility of adding macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678 build timeouts] to the same package. == Benefit to Fedora == This change simplifies maintaining specs for software that are memory-bounded rather than CPU-bounded on our build servers It could potentially improve build reliability for these packages, by reducing the number of jobs failing because of OOM errors, and reduce the need for package maintainers to debug these failures. By keeping the user-facing API aligned with what openSUSE is using, we open up the possibility to collaborate with them and with the upstream RPM project to get such macros upstreamed into RPM itself (see [https://github.com/rpm-software-management/rpm/pull/821 previous attempt]). **note** that is not in scope for this Change. == Scope == * Proposal owners: ** Introduce new macros ** Update known packages to use the new macros, replacing their custom `_smp_build_ncpus` overrides * Other developers: ** The proposal owners might not catch all references of such logic. Individual package maintainers can try refactoring their packages using these new macros * Release engineering: [https://pagure.io/releng/issue/10188 #10188] No mass rebuild needed. Affected packages should be rebuilt using the new macro * Policies and guidelines: Packaging guideline can be updated to recommend using these macros for build-time memory-bound packages * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == No impact, affects package building only. Also, the use of the new macros are optional. == How To Test == 1. Install `build-constraints-rpm-macros` 2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build` 3. Rebuild in koji and make sure it passes on all supported architectures == User Experience == == Dependencies == This can optionally be added as dependencies of `redhat-rpm-config` and `epel-rpm-macros`, depending on how many packages need this == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Revert changed packages to their previous way of capping the number of build jobs * Contingency deadline: beta * Blocks release? No == Documentation == Previous discussion: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU/#GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU openSUSE implementation: https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications == Summary == Enabling third-party repositories will now create a Flathub remote that is a filtered view of Flathub. == Detailed Description == 'Note that this proposal is about user experience, procedures, and technology - the high-level concept has already been discussed and approved by the Fedora Council and FESCO.' Enabling third-party repositories will now create a Flathub remote that is a filtered view of Flathub. This means that applications on Flathub that have been explicitly approved (by a new process proposed here) will be available in GNOME Software and on the flatpak command line. If the user follows following the instructions on https://flatpak.org/setup/Fedora/, then the filter is removed, and the user gets a full view of Flathub. Roughly speaking, the criteria for including software is a) will not cause legal or other problems for Fedora to point to b) does not overlap Fedora Flatpaks or software in Fedora that could easily be made into a Flatpak c) works reasonably well. For Fedora 35, We expect to include all software from the top 50 most popular applications on Flathub that meet these criteria plus selected other software of interest to the Fedora target audience - Fedora community members are welcome to propose additions. Already reviewed: Zoom, Microsoft Teams, Skype, Bitwarden, Postman, Minecraft Other likely software from the top 50: Discord, Anydesk, WPS Office, OnlyOffice, MasterPDFEditor, Slack, UngoogledChromium, Flatseal, WhatsAppQT, GreenWithEnvy The expectation is that many included applications will be things that are hard or impossible to package in Fedora - proprietary applications, Electron-based applications, and so forth. This is consistent with the third-party software policy, and does not reflect a change from what we do currently with third-party repositories. Fedora Workstation Issue: [https://pagure.io/fedora-workstation/issue/108 #108 Add selected Flathub apps to the third-party repos] == Conformance to Fedora policies == The goal here is to be in conformance with the Fedora [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ Third-Party Repository Policy]. The current form of this policy was explicitly written and approved with the filtered view of Flathub being one of the use cases. See https://pagure.io/fesco/fesco-docs/pull-request/34 In detail, this proposal meets [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_key_requirements_for_third_party_repositories Key requirements for third-party repositories]. We consider each application included in the filter as a separate "mini" repository Third-party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, which produces a traceable history for each decision (for example, a ticket or other record). The traceable process is filing a merge request to https://pagure.io/fedora-flathub-filter/ Additionally, repositories included in an edition or spin’s third-party repository list must conform to the following requirements: * Just as with any software hosted by Fedora, third party repositories must not contain material that poses an undue legal risk for the Fedora Project or its sponsors. This risk includes, but is not limited to, software with known patent issues, copyright issues, or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt, confer with Fedora Legal for advice. This is done for each pull request to the `fedora-flathub-filter` repository. * Changes made by one Edition or spin should not impact other Fedora editions or spins. Each spin has the ability to include filtered view of Flathub or not. We do not foresee having *separate* filters for different spins. * Working groups and SIGs should maintain oversight over the software that is made available through third-party repositories, to prevent unvetted software being made available to Fedora users. As part of this, third-party repositories should allow easy auditing by Fedora Legal. This requirement implies that third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default. The filter is a "measure ... to define which packages are made available". == Technical implementation == * The fedora-third-party script added by [[Changes/Third_Party_Software_Mechanism]] will also include support for Flatpak repositories. * A new package fedora-flathub-repository will be added with a configuration file /etc/fedora-third-party.d/flathub.conf and a file /etc/flatpak/filters/fedora-flathub.filter that is
F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism == Summary == Update mechanism for opting-in to "Third-Party Software Repositories" so that the repositories are immediately enabled. == Owner == * Name: [[User:otaylor| Owen Taylor]] * Email: otay...@redhat.com == Detailed Description == ''Note that this proposal is about a change to how third-party repositories are enabled, not about including anything new in Fedora.' Currently, when the user opts in to "Enable Third-Party Software repositories", the` fedora-workstation-repositories` package is installed, but with the repositories disabled. With this change, `fedora-workstation-repositories` will be installed by default (required by `fedora-release-workstation`), and opting in to "Third-party Software Repositories" will actually enable the repositories. Fedora Workstation Issue: [https://pagure.io/fedora-workstation/issue/105 #105 Ship fedora-workstation-repositories on install media] == Conformance to Fedora policies == [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ Third-Party Repository Policy]: The third-party nature of the repository must be apparent to the user when they enable it, as should the non-free status of its content, if such. To ensure this, repository files must initially include the enabled=0 (or equivalent) setting, and the user must explicitly enable third-party repositories to install from them. This proposals is a new implementation of "explictly enable third-party repositories". There is no proposed change to which third-party repostories are shipped - and in particular this change does not include splitting fedora-workstation-repositories to conform to the recommendation of the current guidelines. == Technical implementation == * There is a fedora-third-party package with a fedora-third-party script with enable/disable/refresh/query subcommands. The status is stored in /etc/fedora-third-party.conf * Packages like fedora-workstation-repositories that include third-party repositories will drop config files into /etc/fedora-third-party.d/*.conf. There will be a post-transaction file trigger to run fedora-third-party refresh, which applies the users opt-in status to newly installed repository files. * We add a new page to GNOME Initial Setup that asks a single question, *along the lines of*: '''Enable Third Party Software repositories?''' ☑ Access additional software from selected third party sources. Some of this software is proprietary and therefore has restrictions on use, sharing, and access to source code. [Find out more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories) * If the user leaves the box checked, GNOME Initial setup runs `fedora-third-party enable`. * For upgrades, GNOME Software shows an info-bar with the same question if no status is stored in `/etc/fedora-thirdparty.conf` == Feedback == == Benefit to Fedora == The main benefit of this proposal is the removal of the state where the user has opted in to third party repositories but they are not actually enabled. PackageKit supports the enabled_metadata=1 key in a repository file, which allows applications to be searched in this state, but this is not supported by DNF. The new method is also easily extensible to Flatpaks, where there also no equivalent to enabled_metadata=1, even in GNOME Software. == Scope == * Proposal owners: Create and test proposed fedora-third-party package. Implement the graphical controls for this in GNOME Software and gnome-initial-setup. * Release engineering: [https://pagure.io/releng/issue/10186 #10186] No changes are required. * Policies and guidelines: Third-party Software guidelines will need minor changes to remove references to `enabled_metadata=1`. Pending finalization of technical implementation. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: No real alignment == Upgrade/compatibility impact == Because the "opt-in" status to 3rd party software is currently represented by whether fedora-workstation-repositories is installed, and because fedora-workstation-repositories will become an installed-by-default package, users will need to opt-in again. They can do this either by responding in the infobar that will be displayed in GNOME Software, or by running fedora-third-party enable on the command line. == How To Test == * A fresh install of Fedora Workstation where the user ''does not'' opt-in should have all repositories disabled. * A fresh install of Fedora Workstation where the user ''does'' opt-in should have all 3rd-party repositories enabled. * On an upgrade from F34, if the user opts-out, the enablement status of third-party repositories should be ''unchanged'' (try enabling one before the upgrade) * On an upgrade from F35, if the user opts-in, all 3rd party repositories should be enabled. == User Experience == The user will get less confusing behavior around third-party repositories
F35 Change: IBus 1.5.25 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IBus_1.5.25 == Summary == IBus 1.5.25 will use `transfiletriggerin` script to generate the cache file instead of `posttrans` script in each engine package, support the include directive in the user compose file, IBus compose feature will follow the GTK4 compose pre-edit style, the emoji shortcut key will be changed to `Ctrl-period`, IBus GTK4 module will proceed the key events synchronistically to follow GTK4 specification. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * Each IBus language engine has run `posttrans` script to run `ibus write-cache` to cache their component files in /usr/share/ibus/component whenever the package is installed but `ibus write-cache` will moved to `transfiletriggerin` script in IBus core package and the script will be executed only one time per the Fedora installation. * IBus compose file will support the include directive in the user compose file ($XDG_CONFIG_HOME/ibus/Compose, $XDG_CONFIG_HOME/gtk-3.0/Compose or $HOME/.XCompose) * IBus compose feature will follow the [https://blog.gtk.org/2021/03/24/input-revisited/ GTK4 compose pre-edit style]. * IBus emoji shortcut key is `Ctrl-Shift-e` and it will be changed to `Ctrl-period` to follow the latest GTK while it's customizable with `ibus-setup` utility. * IBus GTK3 module proceeds the key events asynchronistically because some langauge engines spend much time to compose key events and D-Bus process could causes a timeout but now GTK4 does not allow the async events and IBus GTK4 module will proceed the key events synchronistically. == Feedback == * Only one `transfiletriggerin` script is much simpler than many `posttrans` scripts. == Benefit to Fedora == Users can use the include directive in their compose files. IBus GTK4 module can send the application specific keys of Backspace, Enter to the target application to follow GTK4 specification, == Scope == * Proposal owners: Update SPEC file to add `transfiletriggerin` script. Update libibus.so to enhance compose feature. Update org.freedesktop.ibus.gschema.xml for emoji shortcut key. Update libim-ibus.so to fix IBus sync process. * Other developers: Update SPEC files to delete `posttrans` script. * Release engineering: [https://pagure.io/releng/issue/10184 #10184] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == We should avoid regressions with `transfiletriggerin` script in the Fedora installation. == How To Test == # Install ibus and the language engine packages # `ibus read-cache --system` shows the installed engines. # `rpm -q --scripts` does not show `ibus write-cache` in engine packages # `rpm -q --filetriggers` shows `ibus write-cache` in ibus package # Write the line of 'include "%H/foo.compose"' in your $HOME/.XCompose and some compose sequences in $HOME/foo.compose # Run `gnome-control-center keyboard` and configure some IBus language engines besides XKB engines, likes ibus-hangul, ibus-typing-booster # Enable an XKB engine with Super-space or clicking of the keyboard idicator in GNOME # Launch gedit # Confirm your compose sequences in $HOME/foo.compose is reflected # Confirm compose preedit is short # Run `gnome-control-center keyboard` and configure some IBus language engines besides XKB engines, likes ibus-hangul, ibus-typing-booster # Enable an XKB engine with Super-space or clicking of the keyboard idicator in GNOME # Launch gedit # Type Ctrl-period # Confirm emoji pre-edit and lookup table is available # Install gtk4-devel # Run `env GTK_IM_MODULE=ibus gtk4-demo` # Backspace, Enter keys works == User Experience == The emoji shortcut key is changed if users do not customize it but they can customize it with ibus-setup utility. == Dependencies == ibus-anthy, ibus-chewing, ibus-hangul, ibus-input-pad, ibus-kkc, ibus-libpinyin, ibus-rawcode, ibus-sayura, ibus-skk, ibus-table, ibus-typing-booster, mozc (`posttrans` script has already been deleted in each engine package in Fedora rawhide.) == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No == Documentation == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email 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
F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GNUToolchainF35 == Summary == Switch the Fedora 35 GNU Toolchain to gcc 11 (lastest point release), binutils 2.37, and glibc 2.34. The gcc 11 is already included in Fedora 34, but the release will be updated to the latest point release. The glibc 2.34 change will be tracked in this top-level GNU Toolchain system-wide update. Likewise the binutils 2.37 release will be tracked in this top-level GNU Toolchain system-wide update. The gdb 10.2 is already in Fedora 34, but the release will be updated to the latest point release. == Owner == * Name: [[User:codonell|Carlos O'Donell]] * Email: car...@redhat.com == Detailed Description == The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful to transition these components as a complete implementation when making a new release of Fedora. The GNU Compiler Collection has already released version 11 containing many new features documented here: https://gcc.gnu.org/gcc-11/changes.html. The latest point release for gcc 11 will be included in Fedora 35, this will be either 11.1 (already released in April) or 11.2 (released later). The GNU C Library version 2.34 will be released at the beginning of August 2021; we have started closely tracking the glibc 2.34 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 35 will branch after the glibc 2.34 upstream release. However, the mass rebuild schedule means Fedora 35 will mass rebuild (if required) after glibc 2.34 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes. The GNU Binutils version 2.37 will be released near the end of July 2021; The GNU Debugger verion 10.2 is already released. == Benefit to Fedora == Stays up to date with latest features, improvements security and bug fixes from gcc, binutils and glibc upstream. The goal is to track and transition to the latest components of the GNU Toolchain. == Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...) The gcc and glibc teams will need to move their respective upstream projects to a releasable state. For GCC this includes correctly building Fedora rawhide. * Other developers: Developers need to ensure that gcc, binutils, and glibc in rawhide are stable and ready for the Fedora 35 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. An update to GCC 11.2 would be a minimal change with bug fixes. The binutils 2.37 update has the broadest scope for change and generated object files should be reviewed and failures to build analyzed. A mass rebuild is strongly encouraged. The glibc 2.34 release merges libpthread.so into libc.so and it would be important to remove DT_NEEDED on libpthread.so from all distribution binaries. * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora. Some packaging changes may be required for the glibc 2.34 rebase: https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes Some source changes may be required for gcc 11 rebase: https://gcc.gnu.org/gcc-11/changes.html All changes for gcc 11 will have been included in Fedora 34 alraedy. There should be no need for any changes to accommodate the new GNU Binutils release. We fully expect to fix all packaging changes in Fedora Rawhide without impact to the release. == How To Test == The GNU C compiler collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GNU Binary Utilities has its own testsuite which is run during the package build and examined by the binutils developers before being uploaded. The GNU C Library has its own testsuite, 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 may also run the microbenchmark to look for performance regressions. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. == 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 35 cycle. In particular the glibc merge of libpthread into libc will remove the dependency in ELF binaries on libpthread, and that cleanup is valuable for consistency. == Contingency Plan == *
