https://fedoraproject.org/wiki/Changes/CGroupsV2
== Summary ==
The kernel has had some support for CgroupsV2 for some time, and yet
no one has used it because it is not on by default. There are lots of
new features and fixes over CgroupsV1 that it is time to reveal to the
user community.
== Owner ==
* Name: [[User:dwalsh| Daniel J Walsh]]
* Email: <dwalsh(a)redhat.com>
== Detailed Description ==
Enablement of the CgroupsV2 by default will allow tools like systemd,
container tools and libvirt to take advantage of the new features and
many fixes in Cgroups V1. A lot of the functionality in VGroups V1
has been rewritten to fix fundamental flaws in its design.
The reason CGroupsV2 by default has been blocked is that the Container
tools and someone the Virtualization tools did not have support. We
believe that the time is right to try to move these tools along to
take advantage of this kernel feature. In order to begin testing these
features more widely we believe we need to have a platform like
Rawhide to test on and get others to test as well.
The main features of CgroupsV2 we would like to take advantage of in
the container world is delegation of cgroup hierarchies. Allowing
tools like podman to be able to use CGroups in rootless mode, would be
a large advance.
== Benefit to Fedora ==
Fedora is known for being a leading platform for the enablement of new
kernel functions, and this would continue its legacy. The world will
eventually move to CGroupsV2 and Fedora should lead the way.
== Scope ==
* Proposal owners:
The largest changes required to make this Change is to get containers
runtimes like RUNC to work with the change. After RUNC has support
for CgroupsV2 we need to move container engines like Podman, CRI-o,
Buildah and Moby into support CgroupsV2.
* Other developers:
We need to find other tools that have built the CGroupsV1 API into
themselves and get them to support CGroupsV2.
Known packages:
- libvirt: The team is already working on this.
- JVM: Uses Cgroups file system to check for allocated memory for
the JVM, will have to use and understand the CgroupV2 mechanism to
discover these sessings.
- Snap package does not run with CGroupV2:
https://bugzilla.redhat.com/show_bug.cgi?id=1438079
- Systemd will need to be modified to set the new default to cgroupv2
* Release engineering: [https://pagure.io/releng/issue/8509 #8509]
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tools or scripts that an administrator used to manually configure
the CGroupsV1 will have to be modified to CGroupsV2. Luckily if these
tools took advantage of systemd interfaces they should not require
changes.
== How To Test ==
Make sure different tools that use cgroups continue to work when
booted into the new system. Make sure containers, virtual machines
and the Jave Virtual Machine still work properly. Convert the VM's of
the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
make sure their test suites completely pass. Will request that the
libvirt team and JVM teams similarly change their test platforms.
== User Experience ==
We believe that at this point their will be no or very little user
experience change, unless he is an administrator looking to modify the
system Cgroups using the cgroupsfs.
One potential problem will be container images that expect to be
running in a CgroupV1 environment. Some container engines leak the
Cgroup Hierarchy into containers so that tools within the container
can look at how much memory the cgroup gives them for example. These
tools might break with the change, but they should be adjusted quickly
over time, and I don't really see a way to avoid this.
== Dependencies ==
Currently there are no known changes to the package requirements for
this change.
== Contingency Plan ==
* Contingency mechanism: If the container tools and virtualization
tools do not work at beta and do not look like they will be ready for
beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
* Contingency deadline: Beta Freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/IBus_1.5.21
== Summary ==
IBus 1.5.21 will extend the current compose typing.
# IBus will extend the compose key sequences less than 255 characters.
# IBus will extend the compose outputs more equal than one characters.
== Owner ==
* Name: [[User:Fujiwara| Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
The current IBus accepts the compose key sequences less than 7
characters due to the internal fixed buffer size, E.g. Multi_key-O-R
are three characters and the sequence can output "®" but
Multi_key-Multi_key-o-i-i-i-n-t are eight characters and the sequence
is not enabled in IBus. This release will extend this limitation to
255 characters.
The current IBus outputs one compose character only and size is
limited in 16bits. E.g. "®" is one character and it can be output and
"🗼" is one character but the size is extended the upper limit of
16bits and the output is not enabled in IBus. This release will delete
the limitation of the character lengths and the size will be extended
to 32bits.
== Benefit to Fedora ==
The users won't have to mind those compose limitations above and X11
compose does not have the limitations.
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8503 #8503]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
# Create `$HOME/.config/ibus/Compose` with the following context [1]
# Restart ibus-daemon
# Launch gedit and type Multi_key-t-o-w-e-r
"🗼" is output.
[1]: <pre>
<Multi_key> <t> <o> <w> <e> <r> : "🗼"
</pre>
== User Experience ==
Users can reuse the user compose file of X11 to IBus.
The X11 system compose file has been loaded by the desktop locale
since the previous IBus version.
== Dependencies ==
This change effects all IBus engines but rebuilds are not needed.
== Contingency Plan ==
* Contingency mechanism: Drop the feature in Fedora 31 and postpone it
to Fedora 32
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Langpacks-core
== Summary ==
Add `langpacks-core-*` subpackages to `langpacks` for easier
installation of minimal core i18n support for a language
(locale, default font, and any default input-method if needed).
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: petersen(a)redhat.com
* Name: [[User:pnemade|Parag Nemade]]
* Email: pnemade(a)redhat.com
* Name: [[User:mfabian|Mike Fabian]]
* Email: mfabian(a)redhat.com
== Detailed Description ==
In Fedora 30 we replaced the remaining Yum language-support groups in
Comps by extending the `langpacks` meta packages to handle the
installation of fonts (and input-methods) required for a language, in
addition to locale and translation package weak dependencies.
However this all or nothing approach can be too heavy for some use
cases, since the old language-support groups did not pull in
translation langpacks.
With this Change we want to refine the approach to allow finer-grained
installation of language support.
So users who only want basic support installed for a language (without
translation langpacks and additional fonts for example)
can install `langpacks-core-XY` to get just the default font,
locale(s) and a weak dependency for any default input method.
Note: in this proposal `XY` stands just for the ISO language code (eg
`es` for Spanish).
Users who want general default Fedora international support should
continue to install `@fonts`, `@input-methods`, and
`glibc-all-langpacks` (as they are already in Fedora Workstation, etc).
Later we may consider whether to separate the input methods into
separate meta langpacks subpackages.
== Benefit to Fedora ==
This allows more flexibility for users who want to do custom
installations/Spins, or starting from minimal images/installs.
They will be able to add basic i18n support for one or more specific
language in a predictable standard way without pulling in
additional langpacks for translations and extra fonts which may not be
required for each added languages.
Users wanting full support for a language can continue to install the
`langpacks-XY` package for their language.
== Scope ==
* Proposal owners:
** Add `langpacks-core-*` subpackages to langpacks for core i18n functionality:
*** default font
*** glibc locale
*** weak dependency on ibus IME if needed
** Other langpacks weak deps and additional fonts will remain in `langpacks-XY`.
** `langpacks-XY` will require `langpacks-core-XY`.
** glibc locales subpackages weak dependencies will be updated to
depend on `langpacks-core-XY`
* Other developers: No other changes should be needed - current
package translation langpacks will continue to depend on
`langpacks-xx`.
** Policies and guidelines: No major changes here
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
No impact - the design is fully backwards compatible: `langpacks-XY`
will pull in the new `langpacks-core-XY`.
== How To Test ==
* dnf list langpacks-*
* dnf install langpacks-core-XY
* dnf install langpacks-XY
== User Experience ==
Fedora users will have more flexibility with installation of i18n
support packages and langpacks.
== Dependencies ==
glibc.spec needs to be updated with `s/langpacks/langpacks-core/` once
`langpacks` has implemented `langpacks-core`.
No other packages should be directly affected by the current proposal.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will revert to F30
`langpacks` and glibc
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
No additional documentation at this stage.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies
== Summary ==
Packages of R libraries will produce a standard
<code>R(packageName)</code> Provides, and Requires on these standard
names will be added from library metadata. Standard provides will use
the unmodified versions from the metadata. Suggested dependencies will
not be automatically added, but can be opted in by the packager.
== Owner ==
* Name: [[User:qulogic| Elliott Sales de Andrade]]
* Email: quantum.analyst(a)gmail.com
== Detailed Description ==
R libraries currently provide metadata indicating runtime requirements on other
libraries in a <code>DESCRIPTION</code> file. Using RPM's file attributes and
dependency generator support, these requirements can be added to packages
automatically. These will use namespaced <code>Provides</code> of
<code>R(packageName) = packageVersion</code> where <code>packageName</code> is
the importable name of the package and <code>packageVersion</code> is the
upstream version (note: upstream versions are often sanitized for Fedora since
RPM cannot use dashes in versions.)
R library metadata includes <code>Depends</code> and <code>Imports</code> which
will be mapped to <code>Requires</code>. Metadata that specifies
<code>Enhances</code> will be mapped directly to <code>Enhances</code>.
Metadata that specifies <code>Suggests</code> will ''not'' be mapped to
anything by default. Oftentimes, suggested libraries are used to indicate
dependencies that are needed at build time only. Packagers who wish to include
any actual runtime <code>Suggests</code> may opt in to adding them using a
(TBD) flag or just continue to add <code>Suggests</code> manually.
== Benefit to Fedora ==
This change provides a standard Provided name for R packages.
This change helps users of R packages by providing the ''original''
version value (as opposed to the sanitized one for RPM.)
This change reduces the amount of work packagers need to do keeping (R
package) dependencies correct.
== Scope ==
* Proposal owners: The automated dependency generator is
[https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R
available], but will need to be updated to provide the opt-in
<code>Suggests</code>. The generator and file attributes will likely
be housed in the RPM organization, and a new package will be created
for it. R packages will need to be rebuilt after the generator is
packaged, in order to ensure that they contain the new
<code>Provides</code>. If the mass rebuild is not sufficient, this
will be carried out in a side tag.
* Other developers: Others are welcome to rebuild their packages once
the generators are available, but it is not a requirement.
* Release engineering: [https://pagure.io/releng/issue/8501 Releng issue 8501]
* Policies and guidelines: R packaging guidelines should be updated to
mention the new generator; this can be done after the implementation
is done.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No impact expected.
== How To Test ==
# Pick any R package in Fedora.
# Attempt to install it.
# Verify that automatic dependencies are correct, i.e., the package
installed without missing dependencies, and the dependencies that were
pulled in are the ones specified in its <code>DESCRIPTION</code> file.
== User Experience ==
Users interested in R may install packages based on upstream's
''real'' version, and missing dependency annotations will be less
likely to occur.
== Dependencies ==
Move of code to RPM organization; it would be preferred to occur as
early as possible, but is not a full blocker.
These packages will need to be rebuilt:
* COPASI
* R-abind
* R-acepack
* R-affy
* R-affydata
* R-affyio
* R-ALL
* R-AnnotationDbi
* R-ape
* R-argon2
* R-ascii
* R-askpass
* R-assertthat
* R-AUC
* R-backports
* R-base64enc
* R-Bessel
* R-BH
* R-biglm
* R-bindr
* R-bindrcpp
* R-Biobase
* R-BiocGenerics
* R-BiocParallel
* R-biomaRt
* R-Biostrings
* R-bit
* R-bit64
* R-bitops
* R-blob
* R-brew
* R-BSgenome
* R-BSgenome.Celegans.UCSC.ce2
* R-BufferedMatrix
* R-BufferedMatrixMethods
* R-Cairo
* R-callr
* R-car
* R-caTools
* R-cellranger
* R-chron
* R-cli
* R-cliapp
* R-clipr
* R-clisymbols
* R-coda
* R-colorspace
* R-combinat
* R-commonmark
* R-corpus
* R-crayon
* R-curl
* R-data.table
* R-date
* R-DBI
* R-dbplyr
* R-debugme
* R-DelayedArray
* R-deldir
* R-desc
* R-dichromat
* R-diffobj
* R-digest
* R-disposables
* R-doParallel
* R-dplyr
* R-dtplyr
* R-DynDoc
* R-ellipsis
* R-errors
* R-evaluate
* R-expm
* R-fansi
* R-farver
* R-fastmatch
* R-fibroEset
* R-filehash
* R-FMStable
* R-foghorn
* R-fontBitstreamVera
* R-fontLiberation
* R-forcats
* R-foreach
* R-formatR
* R-fortunes
* R-fs
* R-fts
* R-futile.logger
* R-futile.options
* R-future
* R-gamlss.dist
* R-gapminder
* R-gdata
* R-gdtools
* R-gee
* R-geepack
* R-generics
* R-GenomeInfoDb
* R-GenomeInfoDbData
* R-GenomicAlignments
* R-GenomicFeatures
* R-GenomicRanges
* R-getPass
* R-ggplot2
* R-ggplot2movies
* R-gh
* R-git2r
* R-globals
* R-glue
* R-gmailr
* R-gmp
* R-gplots
* R-gsl
* R-gss
* R-gtable
* R-gtools
* R-haven
* R-here
* R-hexbin
* R-hgu133acdf
* R-hgu95av2cdf
* R-hgu95av2probe
* R-highlight
* R-highr
* R-hms
* R-htmltools
* R-htmlwidgets
* R-httpuv
* R-httr
* R-hunspell
* R-igraph
* R-import
* R-ini
* R-inline
* R-IRanges
* R-IRdisplay
* R-IRkernel
* R-iterators
* R-itertools
* R-jose
* R-jpeg
* R-jqr
* R-jsonlite
* R-knitr
* R-labeling
* R-lambda.r
* R-later
* R-lazyeval
* R-lintr
* R-listenv
* R-littler
* R-lmodel2
* R-lmtest
* R-lokern
* R-lubridate
* R-maanova
* R-magrittr
* R-mapproj
* R-maps
* R-mAr
* R-markdown
* R-matrixStats
* R-measurements
* R-memoise
* R-microbenchmark
* R-mime
* R-miniUI
* R-mlbench
* R-mnormt
* R-mockery
* R-mockr
* R-msm
* R-multcomp
* R-multtest
* R-munsell
* R-mvtnorm
* R-nanotime
* R-ncdf4
* R-NISTunits
* R-nws
* R-nycflights13
* R-openssl
* R-orcutt
* R-packrat
* R-parsedate
* R-pbdRPC
* R-pbdZMQ
* R-pdftools
* R-pillar
* R-pingr
* R-pkgbuild
* R-pkgconfig
* R-pkgdown
* R-pkgload
* R-plogr
* R-pls
* R-plyr
* R-png
* R-poLCA
* R-polyclip
* R-polynom
* R-praise
* R-preprocessCore
* R-prettycode
* R-prettydoc
* R-prettyunits
* R-processx
* R-progress
* R-promises
* R-ps
* R-purrr
* R-qcc
* R-qpdf
* R-qtl
* R-quadprog
* R-quantities
* R-qvalue
* R-R6
* R-rappdirs
* R-R.cache
* R-rcmdcheck
* R-RColorBrewer
* R-Rcompression
* R-Rcpp
* R-RcppCCTZ
* R-RCurl
* R-R.devices
* R-readr
* R-readxl
* R-rematch
* R-rematch2
* R-remotes
* R-repr
* R-reprex
* R-reshape
* R-reshape2
* R-reticulate
* R-rex
* R-rgdal
* R-rgeos
* R-rhub
* R-RInside
* R-rlang
* R-rlecuyer
* R-RM2
* R-rmarkdown
* R-R.methodsS3
* R-Rmpfr
* R-ROC
* R-RODBC
* R-R.oo
* R-roxygen2
* R-rprintf
* R-rprojroot
* R-R.rsp
* R-Rsamtools
* R-rsconnect
* R-Rsolid
* R-RSQLite
* R-rstudioapi
* R-rsvg
* R-rtracklayer
* R-RUnit
* R-R.utils
* R-rversions
* R-rvest
* R-S4Vectors
* R-sandwich
* R-scales
* R-scatterplot3d
* R-sciplot
* R-selectr
* R-sessioninfo
* R-sfsmisc
* R-shiny
* R-showtext
* R-showtextdb
* R-simmer
* R-snow
* R-sodium
* R-sourcetools
* R-sp
* R-spelling
* R-statmod
* R-statnet.common
* R-stringdist
* R-stringi
* R-stringr
* R-styler
* R-SummarizedExperiment
* R-svglite
* R-sys
* R-sysfonts
* R-systemfit
* R-testit
* R-testthat
* R-tibble
* R-tidyr
* R-tidyselect
* R-tikzDevice
* R-timeDate
* R-timeSeries
* R-tinytest
* R-tinytex
* R-tkrplot
* R-tkWidgets
* R-tufte
* R-tweenr
* R-udunits2
* R-unitizer
* R-units
* R-unix
* R-usethis
* R-utf8
* R-uuid
* R-V8
* R-vctrs
* R-viridisLite
* R-waveslim
* R-wavethresh
* R-webp
* R-webutils
* R-whisker
* R-whoami
* R-widgetTools
* R-withr
* R-xfun
* R-XML
* R-xml2
* R-xopen
* R-xtable
* R-XVector
* R-yaml
* R-zeallot
* R-zoo
* libsbml
* libsedml
* libnuml
* shogun
== Contingency Plan ==
* Contingency mechanism: The side tag will not be merged, or if a side
tag is deemed unnecessary, the generator will not be installed, and
any built packages will be re-built without it.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
See [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
mailing list discussion].
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Features/LimitScriptletUsage
== Summary ==
Remove direct scriptlet calls from "core packages" (those that are
used to build minimal container image). The packages can still affect
changes during installation by placing files in the correct locations
to trigger registered external programs.
== Owner ==
* Name: [[User:james| James Antill]]
== Detailed Description ==
Currently we know how to make an installable OS with packages that
doesn't require the use of scriptlets, indeed rpm-ostree and others
have already done this on a significantly bigger scale. So we plan to
remove direct scriptlets from most (if not all) of the packages in the
main fedora container image for Fedora 31. This means all four of:
%pre/%post/%preun/%postun. After this change it'd be good to have some
kind of temporary exception to be granted before those packages could
add a scriptlet back (post F31 work).
Almost all of the hard work is already done, as rpm can react to files
being dropped in specified places with known actions (Eg. In this way
systemd components can create users or files). There are a few minor
changes needed to packages to move from the old way of doing things
(Eg. calling adduser) to doing the new thing. Note that while a
program will still be run at installation time, those programs will be
few and easily audited (as against the 666 slightly different ways of
adding a user we currently have).
== Benefit to Fedora ==
At the moment all of the packages with scriptlets (and anything
installed with them) are basically opaque programs that happen to also
carry files that are installed, from the point of view of all of the
packaging tools (rpm, ostree, composer, etc.) . After this change the
entire installation of the main container image will be declarative,
and thus. understandable by all of those tools. This should make
things faster, and allow new optimizations and features.
This should also make packagers life easier in the long term, as
packaging becomes less unique.
== Scope ==
Proposal owners:
* James Antill
* 1 needs to get combine.d into the distribution, and then /etc/shells
can use that.
* 2 minor wrangling of package owners to tweak specfiles.
* Other developers:
* Policies and guidelines: We should work toward only allowing new
scriptlets to appear with policy exceptions, in any of the fixed
packages. This needs to be done somewhat carefully, and post F31.
== How To Test ==
All of the following should provide no output on a standard container:
* rpm -a --qf '%{preinprog}'
* rpm -a --qf '%{preunprog}'
* rpm -a --qf '%{postinprog}'
* rpm -a --qf '%{postunprog}'
* rpm -a --qf '%{pretransprog}'
* rpm -a --qf '%{posttransprog}'
== User Experience ==
There should be no significant difference to users, initially,
although package installation should be faster.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Until higher level packaging/installation tooling starts to depend on
the scriptlets not being present it is always possible to just let
those packages which still have scriptlets continue, if it's required.
* Contingency mechanism: Just ship packages with scriptlets, as we
always have done.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
If you have a Change proposal that requires a mass rebuild or are
categorized as a system-wide change, those proposals must be submitted
(i.e. in ChangeReadyForWrangler category) tomorrow, 2 July.
Self-contained change proposals are due on 23 July.
For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis