Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages
on your own, please do so before Dec 14, which is when I will begin
doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
https://fedoraproject.org/wiki/Changes/RemoveNSCD
== Summary ==
This proposal intends to replace the ''nscd'' cache for named services
with ''systemd-resolved'' for the `hosts` database and the ''sssd''
daemon for everything else.
== Owner ==
* Name: [[User:submachine| Arjun Shankar]]
* Email: arjun(a)redhat.com
== Detailed Description ==
''nscd'' is a daemon that provides caching for accesses of the
`passwd`, `group`, `hosts`, `services`, and `netgroup` databases
through standard libc interfaces (such as `getpwnam`, `getpwuid`,
`getgrnam`, `getgrgid`, `gethostbyname`, etc.). This proposal intends
to replace ''nscd'' in Fedora with ''systemd-resolved'' for the
`hosts` database and the ''sssd'' daemon for everything else.
Accordingly, the `nscd` sub-package of glibc will be removed and
obsoleted.
== Benefit to Fedora ==
While still maintained within the glibc source tree, ''nscd'' has
received less than forty commits in the past three years and has
gathered significant technical debt, and has bugs which are hard to
fix. There are concurrency bugs in the shared mappings, cache
unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues, and more which would
require significant investment to fix in nscd. Such an investment
seems like duplicate effort among our communities given the quality
and state of ''sssd'', and ''systemd-resolved'' which is already
proposed to be enabled by default from [[Changes/systemd-resolved |
Fedora 33 onwards]].
At a high level, sssd and systemd-resolved together provide a caching
solution that has feature parity with nscd, with systemd-resolved
covering the hosts cache and sssd the rest. The removal of nscd from
Fedora will:
* move the user base over to a more modern solution for named services
caching, and
* reduce maintenance work on the Fedora glibc package and the
duplication of effort on nscd upstream.
== Scope ==
* Proposal owners:
The volume of work required is minimal, with the only change being the
removal and obsolescence of the nscd sub-package offered by glibc
which can be achieved by minor changes to the spec file. Since nscd is
not installed by default, the affect on the distribution is minimal.
Users who have installed nscd in an earlier release of Fedora will
need to install and configure sssd instead.
* Other developers: `nss-pam-ldapd` has a weak dependency on nscd that
will need to be removed. `libuser` has a build dependency on nscd that
will also need to be removed.
* Release engineering:
This change does not require coordination with or have impact on
release engineering and does not require a mass rebuild.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Yes, this proposal aligns with the
[https://docs.fedoraproject.org/en-US/project/objectives current
objective] of "Fedora Minimization".
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== User Experience ==
* Most users will be unaffected by this change because nscd is not
installed by default. It is usually used on systems configured with
LDAP, where nscd provides caching of remote queries.
* On a system using nscd that is updated to Fedora 34 from a previous
version, the system administrator will need to install and configure
sssd to replace it after the update. Even when this is not done, the
only visible affect will be slower resolution of named service queries
due to a missing cache.
* Users on a system running sssd and systemd-resolved instead of nscd
shouldn't see any noticeable difference in system behaviour or latency
in resolving named services.
== Dependencies ==
* `nss-pam-ldapd` has a weak dependency on nscd that will need to be removed.
* `libuser` has a build dependency on nscd that will also need to be removed.
Both changes are minimal, requiring a removal of the dependency in the
spec file, and a rebuild.
== Contingency Plan ==
* Contingency mechanism: Revert changes to glibc spec file and
continue to ship nscd. Revert changes to libuser and nss-pam-ldapd
packages; this will need to be done by the respective package
maintainers.
* Contingency deadline: Fedora 34 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? None
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Voting in the Fedora 33 elections is now open. Go to the Elections app
to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 3
December. Don't forget to claim your "I Voted" badge when you cast
your ballot. Links to candidate interviews are in the Elections app
and on the
Community Blog[2].
[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/fedora-33-elections-voting-now-open/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ibus-anthy_for_default_Japanese_IME
== Summary ==
The current default Japanese IME(input method engine) is ibus-kkc and
the default is going to change to ibus-anthy to develop Japanese IME
more effectively.
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
Currently some development plans have been pending because of the
delay of [https://github.com/ueno/ibus-kkc ibus-kkc] [1] which is the
default IME for Japanese and I make the default IME to bring back to
[https://github.com/ibus/ibus-anthy ibus-anthy] now. Originally the
default was changed from ibus-anthy to ibus-kkc because the
[https://osdn.net/projects/anthy/ upstream anthy] is no longer
updated. Recently I got the agreement with the original developer of
anthy and forked it to [https://github.com/fujiwarat/ibus-anthy
anthy-unicode] and start to change the default IME again.
I also considered about [https://github.com/google/mozc ibus-mozc] for
the default but the configuration GUI is based on Qt which has the
different theme from GNOME desktop in Fedora.
[1] https://github.com/ibus/ibus/wiki/GSettingsMigration
== Benefit to Fedora ==
Make the effective developments in the Japanese IME and apply the
latest updates in ibus to each IME more effectively because I'm the
maintainer of both ibus and ibus-anthy.
== Scope ==
* Proposal owners:
* Other developers: gnome-desktop3 for default ja_JP
* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The default installed package will be changed from ibus-kkc to ibus-anthy.
== How To Test ==
Install Fedora with Japanese and the default IME is ibus-anthy.
== User Experience ==
# The Japanese detabase and some keybindings will be changed
# The setting UI is a little different
# The package size and depended packages are different
# The memory usage is a little different
== Dependencies ==
anthy-unicode and kasumi
# comps has to be updated
# gnome-desktop3 has to be updated
== Contingency Plan ==
* Contingency mechanism: Revert comps and gnome-desktop3
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/XwaylandStandalone
== Summary ==
Move Xwayland to a standalone package built from current code upstream
rather than the stable branch.
== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]], [[User:mdaenzer| Michel Dänzer]]
* Email: <ofourdan(a)redhat.com>, <mdaenzer(a)redhat.com>
== Detailed Description ==
Xorg releases upstream are stuck to the current 1.20 branch for years
with no foreseeable future major update.
But Xwayland, the X11 server for Wayland, is receiving quite a lot of
updates upstream.
Xwayland has no device dependent driver loaded at run time, doesn't
load any module, so it is not limited by the Xorg API versioning like
the rest of Xorg.
So technically, there is nothing stopping us from having Xwayland as a
standalone separate package built on git master, while the rest of
xorg-x11-server comes from the stable tree upstream.
This change is about moving Xwayland to a separate package from the
rest of Xorg, built from git snapshots of the current code upstream
rather than the stable branch.
== Benefit to Fedora ==
Xwayland from upstream current code has interesting features missing
from the stable branch, some are backported manually in the current
Fedora package, but some others aren't.
There are also existing COPRs trying to backport those features, but
that can introduce bugs. Using the code from upstream would avoid the
appeal or even the need for such backports.
===XRandR emulation for games===
Those changes from [[User:Jwrdegoede | Hans De Goede]] are already
backported in the current Fedora package for each new release, using
Xwayland from current code upstream would save us from this backport
process, and the potential issues induced by backports.
===Multiple window buffers===
This is basically "tearfree" for Xwayland applications.
===initfd support===
To be able to run Xwayland on demand, the compositor needs a side
channel display where it can run the special X11 clients which need
to complete before the regular clients are started. That feature is
present in Xwayland from current code upstream, and mutter can already
make use of it.
===Xwayland pkgconfig file===
That allows other packages to know about the Xwayland built options
and the Xwayland executable location so that Wayland compositors such
as gnome-shell/mutter can adapt to Xwayland features enabled at build
time.
For example, we could chose to have Xwayland installed in "libexec"
path rather than the common "bindir" path, and mutter could start
Xwayland from there (that requires changes in mutter though, but the
pkg-config for for Xwayland opens for that possibility)
===Maintainability===
With Xwayland receiving most of the attention upstream, that will
allow for new features to be available for Fedora users faster and
more easily.
== Scope ==
* Proposal owners: We would make Xwayland a separate package build
from git snapshots from upstream. That package would provide Xwayland
and Xwayland-devel (for the Xwayland pkg-config file).
The existing Xwayland build would be removed from the xorg-x11-server
package (stable releases branch).
* Other developers: Rebuild Xwayland dependent package if they want to
benefit from the new features exposed from the command line (e.g.
initfd)
* Release engineering: [https://pagure.io/releng/issues/9865 #9865]
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The standalone Xwayland package obsoletes the existing
xorg-x11-server-Xwayland package, so the upgrade would simply replace
xorg-x11-server-Xwayland with standalone Xwayland package.
Xwayland requires no configuration file, nothing needs to be updated
on the user side.
Features are added, not removed.
== How To Test ==
* Xwayland supports EGLStream so it needs non regression testing with
NVidia closed-source driver
* No config file are involved
* Test for non regression with X11 clients as compared with
xorg-x11-server-Xwayland from the stable branch
* Test must include demanding X11 clients such as games for non
regression (Steam?)
To ease testing, a COPR with the standalone package for Fedora 33 and
rawhide is available here:
https://copr.fedorainfracloud.org/coprs/ofourdan/Xwayland/
== User Experience ==
Users should not see any change (it's the same Xwayland program, just
built from a different branch from upstream).
== Dependencies ==
The current packages which list xorg-x11-server-Xwayland as dependency are:
* gamescope
* gnome-session-wayland-session
* kwin-wayland
* plasma-workspace-wayland
* sway
But the standalone Xwayland package would be a drop-in replacement for
xorg-x11-server-Xwayland (i.e. it provides xorg-x11-server-Xwayland)
so there is no impact on those packages.
* mutter would benefit from being rebuilt against the standalone
version of Xwayland to benefit from the initfd option.
== Contingency Plan ==
* Contingency mechanism: Switch back to building Xwayland from the
stable branch (xorg-x11-server-Xwayland).
Rebuild mutter to not use initfd
Downgrading to xorg-x11-server-Xwayland from the stable branch wpuld
require a user action, in case the contingency plan is triggered.
* Contingency deadline: beta freeze
* Blocks release: No
* Blocks product: No
== Documentation ==
There is no documentation change required.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hello all,
Fedora 31 will go end of life for updates and support on 24th of
November 2020. No further updates, including security updates, will be
available for Fedora 31 after the said date. All the updates of Fedora
31 being pushed to stable will be stopped as well.
Fedora 32 will continue to receive updates until approximately one
month after the release of Fedora 34. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.
Regards,
Mohan Boddu.
[0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Sche…
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
https://fedoraproject.org/wiki/Changes/kasumi_unicode
== Summary ==
kasumi-unicode will be generated newly with kasumi.spec in
[https://src.fedoraproject.org/rpms/kasumi kasumi] project.
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
[https://src.fedoraproject.org/rpms/anthy-unicode anthy-unicode] has
been forked from [https://src.fedoraproject.org/rpms/anthy anthy]
since anthy was no longer maintained in upstream.
[https://src.fedoraproject.org/rpms/kasumi kasumi] is one of the
applications which link to the libraries of anthy. In case kasumi
links to anthy, the private dictionary is located in `$HOME/.anthy`
directory. In case kasumi links to anthy-unicode, the private
dictionary is located at `$XDG_CONFIG_HOME/anthy`.
I wish kasumi links to anthy-unicode newly but some other applications
still use anthy.
E.g. ibus-anthy uses anthy-unicode and `$XDG_CONFIG_HOME/anthy`.
fcitx-anthy, scim-anthy, uim-anthy, gcim-anthy uses anthy and
`$HOME/.anthy`.
To keep the back compatibility while *-anthy will migrate to use
anthy-unicode, kasumi.spec is going to generate kasumi twice to
generate two kasumi binaries with different CFLAGS and LDFLAGS between
anthy and anthy-unicode.
kasumi-unicode will be generated to link to anthy-unicode.
anthy-unicode enhances anthy for:
# internal data EUC-JP to UTF-8
# user dic in $HOME/.anthy to $XDG_CONFIG_HOME/anthy
== Benefit to Fedora ==
anthy-unicode saves the user dictionaries in the Freedesktop
configuration directory $XDG_CONFIG_HOME.
Contributers can develop anthy-unicode with UTF-8 words internally.
== Scope ==
* Proposal owners:
* Other developers: [[AkiraTagoh]] (Fedora maintaier of kasumi)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
ibus-anthy will depend on anthy-unicode and kasumi-unicode instead of kasumi.
== How To Test ==
# Enable ibus-anthy in your desktop
# Run /usr/libexec/ibus-setup-anthy
# Run kasumi-unicode from "Dictionary" tab in the dialog
# Register some words with kasumi-unicode
The user dictionary is saved in $XDG_CONFIG_HOME/anthy and ibus-anthy
can use it.
== User Experience ==
Users will run `anthy-unicode-dic-tool --migrate` in case that users
need to migrate the user dictionary in $HOME/.anthy with one in
$XDG_CONFIG_HOME/anthy.
== Dependencies ==
ibus-anthy
== Contingency Plan ==
* Contingency mechanism: Revert the change of kasumi.spec and
ibus-anthy will depends on kasumi.
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? No
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecate…
== Summary ==
Rename `libusb` to `libusb-compat` and `libusbx` to `libusb1`. Do
'''not''' provide an automated update path for the old `libusb` build
dependency as packages should–and likely can–be updated to use
`libusb1`.
== Owner ==
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg(a)redhat.com
== Detailed Description ==
Currently we have two related packages:
* libusb: Containing a compatibility layer of the 0.1 API for libusb 1.0
* libusbx: Containing the libusb 1.0 API, where the name "libusbx"
derives from a fork that existed for a while
To make it clear that "libusb" should not be used anymore and as
"libusbx" does not exist anymore, it makes sense to rename the
packages as follows:
* libusb-compat
* libusb1
In order to ensure that no package is depending on the old `libusb`
(i.e. `libusb-compat`) without a good reason, the plan is to '''not'''
add the corresponding `Provides:` line for the `libusb-compat-devel`
rename.
== Benefit to Fedora ==
* We adhere more closely to the upstream naming scheme for libusb.
* We begin sunsetting `libusb-compat` (i.e. current `libusb`).
== Scope ==
* Proposal owners:
Create new `libusb-compat` and `libusb1` packages based on the current ones.
* Other developers:
Review any package that uses `BuildRequires: libusb-devel`. Many of
them will be able to switch to `libusb1-devel` but some may still
require the compatibility layer, i.e. `libusb-compat-devel`.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact is expected.
== How To Test ==
No further testing is needed.
== User Experience ==
[not provided]
== Dependencies ==
[not provided]
== Contingency Plan ==
Add `Provides: libusb-devel` to `libusb-compat-devel` if too many
packages are not updated.
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
# GitLab AMA Session Topic - Namespace & Issue Tracking
Hi everyone,
Thanks again for your involvement in the GitLab AMA session on IRC in
September. This email discussion thread is on Namespace & Issue
Tracking. I have pulled the relevant questions and answers from the
original hackmd doc into one email and if you would like to discuss
this topic specifically, here might be a good place to do so so your
conversations don't go down a 'rabbit hole' :)
Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_w…
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view
## Namespace & Issue Tracking
- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: It may need to be checked again, but it appears you can
turn on/off the issue tracker at the project level.
- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: You can turn the GitLab issue tracker on and off by
project. See https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions
Namespaces map to “group” in GitLab. Here’s more info about them:
https://docs.gitlab.com/ee/api/namespaces.html
- Question: Fedora, as far as I understand, still plan on using
bugzilla as issue tracker. Currently default assignee and the CC are
gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc),
the other maintainers (who did not ``unwatch issues`` in the project -
mechanism for them to opt-out of being in the CC list) and the people
having enabled ``Issue watching`` for the project (mechanism for them
to opt-in into being in the CC list). Would this work in a GitLab
world?
- Answer: There are a number of options related to that. For one,
users can control their notifications globally and by name space in a
fine grained way (see GitLab Notification Emails).
- Question: Fedora is part of GitLab’s Open Source program and we have
a migration tracker issue that we are using to keep track of feature
requests, bugs, etc that are important to Fedora. The Fedora migration
team has been working with us at GitLab to maintain that and community
members can add relevant issues there so we can track them. It’s also
helpful for our product managers to hear about why particular issues
are important for the Fedora use case, and to have upvotes, so doing
that will help! Where can you submit requests/bugs/report issues?
- Answer:
Fedora Migration Tracker:
https://gitlab.com/gitlab-org/gitlab/-/issues/217350
Feature template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature…
Bug template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug
Please do review the original questions doc in case I have missed any
that relate to namespace and issue tracking and thank you again for
your engagement with these emails! The next email topic will be on
'Branches'.
Have a good week!
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford