devel-announce June 2021

devel-announce@lists.fedoraproject.org

7 participants
34 discussions

F35 Change: Gconv package split in glibc (System-Wide Change proposal)
by Ben Cotton 30 Jun '21

30 Jun '21

https://fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc == Summary == Most Gconv modules with the exception of unicode and similar essential ones have been split into a separate package called glibc-gconv-extra. Currently, the core package glibc has a strong (Requires) dependency on glibc-gconv-extra making this change transparent to users. This proposal is to weaken this dependency to Recommends so that it is possible to remove glibc-gconv-extra from installations that do not need it. == Owner == * Name: [[User:siddhesh| Siddhesh Poyarekar]] * Email: sipoyare(a)redhat.com == Detailed Description == The glibc-gconv-extra package contains all iconv converter plugins except UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 and ANSI_X3.110. A number of minimal installations would typically not need all those plugins and they can be removed without any ill effects to those environments. To achieve this, the glibc dependency on glibc-gconv-extra needs to be weakened from Requires to Recommends. Weakening the dependency of glibc on glibc-gconv-extra implies that glibc-gconv-extra may not be pulled into certain installations by default, e.g. in buildroots for package builds. glibc-gconv-extra is however necessary because a number of packages either run tests that verify conversions between arbitrary character sets or need similar functionality to convert character sets of files in the upstream sources. A method would have to be devised to ensure that glibc-gconv-extra is available in buildroots. One option is to have redhat-rpm-config Require glibc-gconv-extra as a way to ensure that glibc-gconv-extra is in every buildroot, but better ideas are desirable. == Feedback == The change was made assuming that the weak dependency would be sufficient to address compatibility but it was subsequently rolled back when it was discovered that buildroots do not pull in weak dependencies. Since the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… announcement on fedora-devel] the reception to the change idea itself has been positive. There are compatibility concerns with respect to buildroots and backward compatibility, which will be addressed. == Benefit to Fedora == The ability to remove glibc-gconv-extra brings in two main benefits: * Removal can save about 8MB in the installed size, which is an advantage for minimal container images * A number of the infrequently used modules have historically had bugs that have been considered security issues. Removing the glibc-gconv-extra package is thus a hardening opportunity for UTF-8 clean environments. == Scope == * Proposal owners: The change required in glibc is minimal, requiring only spec file changes to change dependencies. * Other developers: To allow glibc-gconv-extra to be installed in minimal koji buildroots, redhat-rpm-config needs to be modified to depend on glibc-gconv-extra. Alternatively, the buildroot definition needs to be altered somehow to include glibc-gconv-extra. If none of the above are feasible, package owners will need to add a BuildRequires on glibc-gconv-extra if they need the extra converter modules. However this is the last option and should ideally be avoided. * Release engineering: [https://pagure.io/releng/issue/10176] * 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 == 1. Update glibc on an older system and verify that glibc-gconv-extra gets updated by default 2. Update glibc on a system that has glibc-gconv-extra removed and verify that glibc-gconv-extra is not pulled in 3. glibc downgrades should also have analogous behaviour 4. Build any package in mock or koji and verify that glibc-gconv-extra is present in the buildroot == User Experience == Minimal, UTF-8-only containers can be reduced by 8MB. == Dependencies == If buildroot issues cannot be resolved through releng or a dependency on redhat-rpm-config, a number of packages will need to be updated to ensure that they build. At this moment that list is unknown. == Contingency Plan == * Contingency mechanism: glibc dependency on glibc-gconv-extra is reverted to Requires * Contingency deadline: 2021/08/24 (Beta freeze) * Blocks release? No == Documentation == Package split and its potential announced and discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

List of long term FTBFS packages to be retired in August
by Miro Hrončok 30 Jun '21

30 Jun '21

Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 35 approximately one week before branching (August 2021). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails… The packages in rawhide were not successfully built at least since Fedora 32. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf… If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build ================================================================================ cardpeek kalev Fedora 32 percona-xtrabackup slaanesh, slankes Fedora 32 php-opencloud-openstack lcts Fedora 32 proxyfuzz psklenar Fedora 32 radamsa huzaifas, mrniranjan Fedora 32 sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr zram pbrobinson Fedora 32 The following packages require above mentioned packages: Depending on: percona-xtrabackup (1), status change: 2020-11-22 (31 weeks ago) holland (maintained by: immanetize, jeffreyness, survient) holland-xtrabackup-1.2.4-2.fc35.noarch requires /usr/bin/xtrabackup Affected (co)maintainers callkalpa: sugar-view-slides chimosky: sugar-view-slides huzaifas: radamsa immanetize: percona-xtrabackup jeffreyness: percona-xtrabackup kalev: cardpeek lcts: php-opencloud-openstack mrniranjan: radamsa pbrobinson: zram, sugar-view-slides psklenar: proxyfuzz slaanesh: percona-xtrabackup slankes: percona-xtrabackup survient: percona-xtrabackup tuxbrewr: sugar-view-slides

1 0

F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
by Ben Cotton 29 Jun '21

29 Jun '21

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/d7454e4e0a98208dc569553b901a49… ceph], [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd1… chromium], [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082… 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-chang… 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/devel@lists.fedoraproject.org… 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

1 0

F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
by Ben Cotton 29 Jun '21

29 Jun '21

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 <code>flatpak</code> 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<br> 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]. We consider each application included in the filter as a separate "mini" repository <blockquote> 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). </blockquote> The traceable process is filing a merge request to https://pagure.io/fedora-flathub-filter/ <blockquote> 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. </blockquote> This is done for each pull request to the `fedora-flathub-filter` repository. <blockquote> * Changes made by one Edition or spin should not impact other Fedora editions or spins. </blockquote> Each spin has the ability to include filtered view of Flathub or not. We do not foresee having *separate* filters for different spins. <blockquote> * 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. </blockquote> The filter is a "measure ... to define which packages are made available". == Technical implementation == * The <code>fedora-third-party</code> script added by [[Changes/Third_Party_Software_Mechanism]] will also include support for Flatpak repositories. * A new package <code>fedora-flathub-repository</code> will be added with a configuration file <code>/etc/fedora-third-party.d/flathub.conf</code> and a file <code>/etc/flatpak/filters/fedora-flathub.filter</code> that is referenced by the <code>flathub</code> remote when created. * The filter is maintained by the scripts and procedures in https://pagure.io/fedora-flathub-filter/ - additions correspond to pull requests. * If the user explicitly installs Flathub, by, for example, following the instructions on https://flatpak.org/setup/Fedora/, then the filter is removed, and the user gets a full view of Flathub. (This is standard behavior already implemented in the Flatpak client) == Benefit to Fedora == Fedora users who opt-in to third-party software repositories will have immediate access to more software out-of-the-box. == Scope == * Proposal owners ** Add flatpak support to the `fedora-third-party` script ** Add a `fedora-flathub-repository` package that is built from the output of `fedora-flathub-filter` and integrates with the `fedora-third-party` repository package. * Other developers: ** No actions needed * Release engineering: [https://pagure.io/releng/issue/10187 #10187] ** No actions needed * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: No significant alignment == Upgrade/compatibility impact == The expectation is that: * If the system already has a flathub remote installed, nothing happens, whether or not the user has opted-in to third-party software. * If the system does not have a flathub remote installed, and the user opts-in to third-party software at upgrade time, then the filtered-in apps are then available. == How To Test == * On a fresh install or upgrade, if the user opts-in to third-party software, applications such as Skype are visible in GNOME Software and `flatpak search`. * On a fresh install or upgrade, if the user does not opt-in to third-party software, applications such as Skype are not visible in GNOME Software and `flatpak search`. * If https://flatpak.org/setup/Fedora/ is followed before upgrade, the remote remains unfiltered. * If https://flatpak.org/setup/Fedora/ is followed after upgrade, the remote becomes unfiltered. == User Experience == Fedora users who opt-in to third-party software repositories will have immediate access to more software out-of-the-box. == Dependencies == This depends on [[Changes/Third_Party_Software_Mechanism]] == Contingency Plan == * Contingency mechanism: remove the dependency of fedora-workstation-release on `fedora-flathub-repository` * Contingency deadline: release candidate * Blocks release? No - the contingency plan could be used at any point == Documentation == The review process is described at https://pagure.io/fedora-flathub-filter/ == Release Notes == With Fedora 35, if the user opts-in to third-party software repositories selected applications from https://flathub.org are now available by default in GNOME Software, in KDE Discover, and on the Flatpak command line. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
by Ben Cotton 29 Jun '21

29 Jun '21

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: otaylor(a)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]: <blockquote> 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. </blockquote> 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 <code>fedora-third-party</code> package with a <code>fedora-third-party</code> script with <code>enable/disable/refresh/query</code> subcommands. The status is stored in <code>/etc/fedora-third-party.conf</code> * Packages like <code>fedora-workstation-repositories</code> that include third-party repositories will drop config files into <code>/etc/fedora-third-party.d/*.conf</code>. There will be a post-transaction file trigger to run <code>fedora-third-party refresh</code>, 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*:<br> '''Enable Third Party Software repositories?''' <br> ☑ 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. <br> [Find out more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Re… * 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 <code>enabled_metadata=1</code> 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 <code>enabled_metadata=1</code>, even in GNOME Software. == Scope == * Proposal owners: Create and test proposed <code>fedora-third-party</code> 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 <code>fedora-third-party enable</code> 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 - enabled will mean enabled and will take affect no matter how they are installing packages. See https://hackmd.io/@owtaylor/fedora-third-party-repos for a detailed description of the *current* experience along with some notes about the desired behavior. == Dependencies == The changes are limited to the following packages: * The new `fedora-third-party` package * `fedora-workstation-repositories` * `gnome-software` * `gnome-initial-setup` * `fedora-release-workstation` and other release packages that will now require fedora-workstation-repositories. This change proposal is a prerequisite for a separate change proposal to add a filtered view of Flathub to the set of third-party repositories. == Contingency Plan == * Contingency mechanism: revert all changes back to the F34 state. (This will also require reverting the filtered-view-of-Flathub change.) * Contingency deadline: beta freeze * Blocks release? Yes - this needs to be finished or reverted == Documentation == '''This should be a link to a man page for the `fedora-third-party` tool''' == Release Notes == Fedora optionally provides repository definitions allowing users to install certain third-party software. This used to be done as a two-step process where when the user asked to enable third-party repositories, the repository definitions were installed but not actually enabled, and they had to be separately enabled. With Fedora 35, this is simplified so that the repository definitions are installed by default, but only enabled if the user opts in. If you are upgrading from an older version of Fedora, you'll need to opt-in again - this can be done by running GNOME Software and accepting the prompt that is shown on the initial page. Alternatively, you can run <code>fedora-third-party enable</code> from the command line. If you do not wish to enable third-party repositories, no action is needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: IBus 1.5.25 (System-Wide Change proposal)
by Ben Cotton 29 Jun '21

29 Jun '21

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

1 0

F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)
by Ben Cotton 29 Jun '21

29 Jun '21

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: carlos(a)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 == * Contingency mechanism: If glibc 2.34 provides too disruptive to compiling the distribution we could revert to 2.33, but given that Rawhide has started tracking glibc 2.34, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.33 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream glibc ABI freeze deadline of 2021-07-01. * Blocks release? Yes, upgrading to the gcc point release blocks the release. Yes, upgrading to binutils 2.37 blocks the release. Yes, upgrading glibc does block the release. We should not ship without a newer binutils and glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations. == 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. == Release Notes == The GNU Compiler Collection version 11 is already released. See https://gcc.gnu.org/gcc-11/changes.html. The GNU Binutils version 2.37 will be released in the middle of July and release notes will be updated at that point. The GNU C Library version 2.34 will be released at the beginning of August 2021. 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 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: Boost 1.76 upgrade (System-Wide Change proposal)
by Ben Cotton 28 Jun '21

28 Jun '21

https://fedoraproject.org/wiki/Changes/F35Boost176 == Summary == This change brings Boost 1.76 to Fedora. This will mean Fedora ships with a recent upstream Boost release. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodgers(a)redhat.com == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is absent from Boost, this entails rebuilding of all dependent packages. This also entails the change owner assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. The equivalent changes for previous releases were [[Changes/F34Boost175]], [[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora 28 Change]], [[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora 25 Change]], [[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23 Change]] and [[Changes/F22Boost158|Fedora 22 Change]]. == Benefit to Fedora == Fedora 35 includes Boost 1.76 Fedora will stay relevant, as far as Boost clients are concerned. Boost 1.76 does not bring any new components but includes many fixes and enhancements to existing components. Boost 1.76 also introduces some breaking changes - * Boost.DLL : boost::dll::import was renamed to boost::dll::import_symbol to avoid collision with C++20 import keyword. * Boost.Math : Drops C++03 support. * Boost.Multiprecision : Explicitly requires C++11 or later. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f35-boost" [https://docs.pagure.org/releng/sop_adding_side_build_targets.html build system tag] ([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html discussion]): https://pagure.io/releng/issue/9474 ** Build boost into that tag (take a look at the [http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493] for inspiration) ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: ** Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Policies and guidelines: ** Apart from scope, this is business as usual, so no new policies, no new guidelines. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. Historically this hasn't been too much of a problem and could always be resolved before deadline. == How To Test == * No special hardware is needed. * Integration testing simply consists of installing Boost packages (`dnf install boost`) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients). == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new Boost packages, and may need to adjust their code if the new Boost release is not source-compatible. * Developers using `bjam` to build their own software will need to switch to using the new name for the tool, `b2` == Dependencies == Packages that must be rebuilt: <code>$ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code> All clients: <code>$ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source</code> == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F34 with Boost 1.73, which is already in rawhide. It would also be possible to ship the 1.74.0 which would still be newer than in current Fedora releases and contains numerous fixes and improvements to existing Boost components. * Blocks release? No * Blocks product? None == Documentation == * https://www.boost.org/users/history/version_1_76_0.html (released on 16 April 2021) * https://www.boost.org/users/history/version_1_75_0.html (released on 11 December 2020) * https://www.boost.org/users/history/version_1_74_0.html (released on 14 August 2020) * https://www.boost.org/users/history/version_1_73_0.html (released on 28 April 2020) * https://www.boost.org/users/history/version_1_72_0.html (released on 11 December 2019) * https://www.boost.org/users/history/version_1_71_0.html (released on 19 August 2019) * https://www.boost.org/users/history/version_1_70_0.html (released on 12 April 2019) * https://www.boost.org/development/index.html == Release Notes ==  -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)
by Ben Cotton 28 Jun '21

28 Jun '21

https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec == Summary == OpenDNSSec' enforcer has a (deprecated) -sha1 CLI option that brings back the old behavior, e.g. include the SHA1 version of the DS. As SHA1 use is deprecated in favour of SHA256, disable the -sha1 CLI knob so that it only displays a warning. == Owner == * Name: [[User:fcami| François Cami]] * Email: fcami(a)redhat.com == Detailed Description == OpenDNSSec changed the default behavior to not include SHA1 DS by default, and added the -sha1 knob as an immediately-deprecated compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By default ‘ods-enforcer key export –ds’ included the SHA1 version of the DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS use the –sha1 flag. This flag is immediately deprecated and will be removed from future versions of OpenDNSSEC." (see ChangeLog: https://www.opendnssec.org/archive/releases/ ). The proposal is to disable the -sha1 knob in Fedora. I will also open an issue upstream to remove all the sha1-related code. Supporting statement [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha… [from ICANN] (2020-1-24): "Now is the time for administrators of zones at all levels of the DNS to stop using SHA-1 and change to algorithms using stronger hashes." == Benefit to Fedora == * This change makes sure OpenDNSSec in Fedora follows ICANN's guidelines and does not propose SHA1 DS. This is is needed given the [https://sha-mbles.github.io/ latest attacks against SHA-1]. More in-depth articles are available [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/ there]. * This change is aligned with previous features: ** [[Features/StrongerHashes]] ** [[Changes/StrongCryptoSettings]] ** [[Changes/StrongCryptoSettings2]] == Scope == * Proposal owners: Patch the enforcer so that bsha1 is not honored anymore: ./enforcer/src/keystate/keystate_export_cmd.c-271- break; ./enforcer/src/keystate/keystate_export_cmd.c-272- case 's': ./enforcer/src/keystate/keystate_export_cmd.c:273: bsha1 = 1; ./enforcer/src/keystate/keystate_export_cmd.c-274- break; ./enforcer/src/keystate/keystate_export_cmd.c-275- default: * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone. This change might break (very old) clients that only recognize SHA-1 but these should already be broken (on the Internet at least) because the root zone is signed with SHA-256 only. == How To Test == == User Experience == OpenDNSSec in Fedora can currently be used to sign zones with SHA1. With this change, this will no longer be possible. The migration from SHA1 is underway anyway. == Dependencies == FreeIPA (freeipa-server-dns) depends on OpenDNSSec. == Contingency Plan == * Contingency mechanism: Keep the current -sha1 knob's behavior (remove the patch). * Contingency deadline: Beta freeze * Blocks release? No, unless the change breaks IPA. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F35 Change: Golang 1.17 (System-Wide Change proposal)
by Ben Cotton 28 Jun '21

28 Jun '21

https://fedoraproject.org/wiki/Changes/golang1.17 == Summary == Rebase of Golang package to upcoming version 1.17 in Fedora 35, including the rebuild of all dependent packages(the pre-release version of Go will be used for the rebuild if released version will not be available at the time of the mass rebuild). == Owner == * Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka| Jakub Čajka]] * Email: asm(a)redhat.com, jcajka(a)redhat.com == Detailed Description == Rebase of Golang package to upcoming version 1.17 in Fedora 35. Golang 1.17 is scheduled to be released in August 2021. Due to Go packages' current nature and state, the rebuild of dependent packages will be required. == Benefit to Fedora == Stay closely behind upstream by providing the latest release of Go, which includes improved support of the risc-v processor architecture and added support for aarch64 based darwin(macOS) machines, among other bug fixes, enhancements and new features. For a complete list of changes, see upstream change notes at https://tip.golang.org/doc/go1.17 . Therefore Fedora will be providing a reliable development platform for Go language and projects written in it. == Scope == * Proposal owners: Rebase Golang package in Fedora 35, help resolve possible issues found during package rebuilds. * Other developers: Fix possible issues, with help from Golang maintainers. * Release engineering: Rebuild of dependent packages as part of planned mass-rebuild. * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None == How To Test == ;0. :a) Install golang 1.17 from rawhide and use it to build your application(s)/package(s). :b) Scratch build against rawhide. ;1. :Your application/package built using golang 1.17 should work as expected. == User Experience == None == Dependencies == <pre> 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 'compiler(golang)' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'go-rpm-macros' </pre> <pre> Omitted due to the number of packages listed ~1600. </pre> Not all of listed require re-build as they might not ship binaries and/or do not use golang compiler during build, but only use Go rpm macros that pull it in to every build root. == Contingency Plan == * Contingency mechanism:Reverting to golang version 1.16.X if significant issues are discovered. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? No == Documentation == https://tip.golang.org/doc/go1.17 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2021