Just a reminder that builds are currently running for python2 and python3 that
change the meaning of /usr/bin/python from Python 2 to Python 3 in rawhide.
For details, see https://fedoraproject.org/wiki/Changes/Python_means_Python3
I'll be sending e-mails later to package owners who still depend on
/usr/bin/python or who have other tools in /usr/bin/ that should be switched over.
In case of trouble, block the tracker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1729593
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: kevin(a)scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this
line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
== How To Test ==
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Every…
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modul…
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Mo…
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Every…
* Confirm that mock can init a chroot for fedora-i386-31 using the koji
buildroot repository.
== User Experience ==
* Users will get updates and rawhide and rc composes faster.
* Users will not be able to upgrade to a insecure Fedora configuration.
== Contingency Plan ==
i686 trees will just continue to be composed and published. Users can upgrade to
them (with an old kernel from f30).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Planned Outage -pagure.io - 2019-07-12 21:00 UTC
There will be an outage starting at 2019-07-12 21:00 UTC ,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-07-12 21:00UTC'
Reason for outage:
We will be moving pagure.io from one datacenter to another. The time to
sync the data is expected to be around an hour, but we are leaving time
for configuration issues or network problems. We will try and minimize
the downtime as much as possible. Sorry for the short notice on this
outage window.
Affected Services:
https://pagure.iohttps://docs.pagure.org
Ticket Link:
None. :) Since pagure.io will be down.
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
https://fedoraproject.org/wiki/Changes/Mono_5_20
== Summary ==
Update the Mono stack in Fedora from 5.18 to 5.20. It seems we need to
do again a bootstrap build.
== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpokorra(a)fedoraproject.org
== Detailed Description ==
I had hoped, that between minor releases, we could build Mono without
doing a bootstrap. I can build Mono 5.20 fine with a bootstrap, but
not without. I did some experimenting, with the idea of a fake
bootstrap, by using the existing Mono in Fedora, and avoiding the
checks for the mscorlib version. But that ended in compiler errors. I
asked upstream, but have not yet received a reply:
https://github.com/mono/mono/issues/15643
I have successfully built Mono 5.20 without bootstrap, once I have
Mono 5.20 installed.
I would like to request permission to make a one time exception of the
rule for building mono 5.20.1-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
5.18.1-2 using mono-5.18.1-1.
Steps for bootstrapping:
* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 5.x
== Scope ==
* Proposal owners:
Update mono spec and build in koji until is ready.
Members of the Mono SIG can rebuild their packages with Mono 5.20, but
tests with keepass for example show that it works fine without
rebuilding even with Mono 5.20. Rebuild of all packages depending on
Mono can happen during the regular mass rebuild.
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Tests with keepass without rebuilding keepass worked fine on Mono 5.20.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
* https://fedoraproject.org/wiki/Packaging:Mono
* https://github.com/mono/mono
* https://copr.fedorainfracloud.org/coprs/tpokorra/mono-5.20/
* https://github.com/tpokorra/mono-5.x-fedora/tree/master/mono-5.20
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Bundler_2.0
== Summary ==
Upgrade to Bundler 2.0, the latest stable gem version.
== Owner ==
* Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
* Email: pvalena(a)redhat.com, vondruch(a)redhat.com
== Detailed Description ==
Bundler 2 is new major upstream release, that includes many
improvements and bug fixes.
== Benefit to Fedora ==
Keeping with a latest release, Bundler is enabling simple Ruby
application dependency managemenent.
== Scope ==
* Proposal owners:
** Move Bundler 1.16 to rubygem-bundler1 (sub)package.
** Build Bundler 2.0. Current changes:
https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/5
** Work has been done in a Copr repository:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygem-bundler/
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
All applications and Gemfiles that currently work with Bundler 1 will
continue to work with Bundler 2.
Notable changes:
* Dropped support for end of lifed Ruby versions 1.8.7 through 2.2
* Dropped support for end of lifed RubyGems versions 1.3.6 through 2.5
* Moved error messages from STDOUT to STDERR
== How To Test ==
* No special hardware is needed.
* Install Bundler 2
* Run `bundle --version`
* Create new applications as before
* If something doesn't work as it should, let us know.
== User Experience ==
New features that come with Bundler 2.0 will be available. Current
version will be available as rubygem-bundler1.
== Documentation ==
https://bundler.io/docs.html
== Release Notes ==
* https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
* https://bundler.io/blog/2018/11/04/an-update-on-bundler-2.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
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