F37 Proposal: Node.js 18.x by default (System-Wide Change proposal)
by Ben Cotton
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
https://fedoraproject.org/wiki/Changes/Nodejs18
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
18.x series. As with 16.x, 14.x, 12.x, 10.x and 8.x before it, Fedora
37 will carry 18.x as the default Node.js interpreter for the system.
The 16.x, and 14.x interpreters will remain available as non-default
module streams.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 37 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-18.x and the matching npm
package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
18.x release, Fedora 37 will also have the 16.x and 14.x releases
available as selectable module streams.
== Scope ==
* Proposal owners:
The packages are already built for Fedora 34, 35, and 36 in a
non-default module stream. On June 6th, 2022, the nodejs-18.x packages
will be built in the non-modular repository and thus become the
default in Fedora 37.
* Other developers: N/A (not a System Wide Change)
Any developer with a package that depends on Node.js at run-time or
build-time should test with the 18.x module stream enabled as soon as
possible. Issues should be reported to nodejs(a)lists.fedoraproject.org
* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform any necessary rebuilds before making 18.x
the default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 35 or Fedora 36 with
the non-modular nodejs-16.x packages will be automatically upgraded to
the 18.x packages when they upgrade to Fedora 37, which may cause
compatibility issues. If users are running software known not to
support Node.js 18.x yet, they can switch the system to use 16.x with
'''dnf module''' commands.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 18.x being installed.
* Confirm that upgrading from Fedora 35 or Fedora 36 with nodejs-16.x
installed (non-modular) results in an upgrade to nodejs-18.x
* Confirm that upgrading from Fedora 35 or Fedora 36 with the
`nodejs:16` module enabled does *not* result in an upgrade to 18.x and
still has the `nodejs:16` module enabled on Fedora 37.
* Confirm that upgrading from Fedora 35 or Fedora 36 with the
`nodejs:18` module enabled upgrades successfully and still has the
`nodejs:16` module stream enabled on Fedora 37.
== User Experience ==
Users will have the 18.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:16` stream or else removed from
Fedora 37.
Prior to the switchover date to Node.js 18.x as the default, packagers
are strongly encouraged to test their existing Node modules with 18.x
via the Modular version by running:
<pre>
dnf module reset nodejs
dnf module install nodejs:18/development
</pre>
Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs18.cfg` with the following
contents:
<pre>
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:18/development']
include('templates/fedora-rawhide.tpl')
</pre>
Then call
<pre>
mock -r fedora-rawhide-x86_64-nodejs18 --enablerepo=rawhide-modular nodejs-foo
</pre>
(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])
== Contingency Plan ==
* Contingency mechanism: Revert to Node.js 16.x as the default Node.js
interpreter. This will require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v18.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V18.md
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/
== Release Notes ==
Fedora 37 now ships with Node.js 18.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 16.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:16
</pre>
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2
(System-Wide Change proposal)
by Ben Cotton
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1
== Summary ==
Cryptographic policies will be tightened in Fedora 38-39,
SHA-1 signatures will no longer be trusted by default.
Fedora 37 specifically doesn't come with any change of defaults,
and this Fedora Change is an advance warning filed for extra visibility.
Test your setup with FUTURE today and file bugs so you won't get bit
by Fedora 38-39.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asosedki(a)redhat.com
== Detailed Description ==
Secure defaults are an evermoving target.
Fedora 28 had [[Changes/StrongCryptoSettings|StrongCryptoSettings]].
Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]].
Fedora 39 should have [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]].
The impact of one upcoming change, notably distrusting SHA-1 signatures,
might be so profound we're smoothing the rollout in time
to give developers and maintainers ample time to react:
Fedora 36:
* SHA-1 signatures are distrusted in FUTURE policy (opt-in)
* TEST-FEDORA39 policy is provided
* creating and verifying SHA-1 signatures is logged to ease reporting bugs
'''Fedora 37 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning1]]''':
* (was initially reserved to implement logging of SHA-1 signature operations)
Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning2]]:
* policies are updated, most notably
* SHA-1 signatures are distrusted in DEFAULT policy
* changes are reverted in branched f38 in time for Beta and do not reach users
Fedora 39 [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]:
* changes reach users
The plan is subject to change if it goes sideways somewhere along the way.
By Fedora 39, the policies will be, in TLS perspective:
LEGACY
MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: SHA-1 hash or better (no DSA)
Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES)
Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
DH params size: >=2048
RSA params size: >=2048
TLS protocols: TLS >= 1.2
DEFAULT
MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: with SHA-224 hash or better (not DSA)
Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
DH params size: >= 2048
RSA params size: >= 2048
TLS protocols: TLS >= 1.2
FUTURE
MACs: All HMAC with SHA256 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: SHA-256 hash or better (not DSA)
Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
Key exchange: ECDHE, DHE
DH params size: >= 3072
RSA params size: >= 3072
TLS protocols: TLS >= 1.2
The flagship change this time will be distrusting SHA-1 signatures
on the cryptographic library level, affecting more than just TLS.
OpenSSL will start blocking signature creation and verification by default,
with the fallout anticipated to be wide enough
for us to roll out the change across multiple cycles
with multiple forewarnings.
In Fedora 36, 37 and 38 released distrusting SHA-1 signatures will be opt-in.
In Fedora 38 rawhide and Fedora 39 distrusting SHA-1 signatures
will happen by default.
== Feedback ==
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
A discussion]
has been raised on fedora-devel,
[https://lwn.net/Articles/887832 a summary] is available on LWN.
A change has the potential to prove disruptive and controversial,
with much effort being focused on stretching it out in time.
There seems to be a consensus that the change has to be done eventually,
but the ideal means of implementing it are in no way clear.
The decision to discover code reliant on SHA-1 signatures
by blocking creation/verification has not gathered many fans,
but not many alternative proposals have been raised in return.
A notable one, making the library somehow log the offending operations,
has been incorporated in the proposal,
though the effectiveness of it is yet to be seen in practice.
Another notable takeaway point is the need to call for testing,
which would be done in form of writing four Fedora Changes
and testing SHA-1 signature distrusting during Fedora 37 & 38 Test Days.
The change owner doesn't see the plan as an ideal one
and continues to be open for feedback.
== Benefit to Fedora ==
Fedora 39 will ship with more secure defaults
to better match the everchanging landscape of cryptographic practices.
TLS 1.0 / 1.1 protocol version will be disabled
as they're [deprecated https://datatracker.ietf.org/doc/rfc8996],
minimum key sizes will be raised to keep up with the computational advances etc.
Distrusting SHA-1 signatures specifically is expected to trigger
a topical distribution-wide crackdown
on [https://eprint.iacr.org/2020/014 weak] cryptography,
raising the security of the distribution moving forward.
== Scope ==
* Proposal owners: implement changes described in Summary and
Dependencies sections
* Other developers:
Test your applications with FUTURE policy.
Move away from trusting SHA-1 signatures;
ideally in time for F38 branch-off,
for F39 release at the latest.
Follow [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]:
1. move away from trusting SHA-1 signatures entirely, or
2. distrust them by default and require explicit user opt-in to use a workaround
* Release engineering: Not sure if mass-rebuild is required if we land
the change right after f38 branch-off. Maybe a "preview" mass-rebuild
can be done with a special build in the Fedora 37 timeframe to cut
down on Fedora 38 FTBFS.
* Policies and guidelines: update needed in time for Fedora 38
CryptoPolicies section of the packaging guidelines
will have to be updated to reflect that
SHA-1 signatures must not be trusted by default
and provide guidance for openssl and gnutls.
Components using workaround APIs must not use them without explicit user opt-in
and must be added to a list of applications using a workaround API.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: not with Fedora 37-era ones
== Upgrade/compatibility impact ==
Nothing will change for Fedora 37 by default, the change is opt-in for now.
== How To Test ==
=== Testing actively ===
Install crypto-policies-scripts package and switch to a more restrictive policy
with either `update-crypto-policies --set FUTURE`
or `update-crypto-policies --set TEST-FEDORA39`.
Proceed to use the system as usual,
identify the workflows which are broken by this change.
Verify that the broken functionality works again
if you the policy is relaxed back
with, e.g., `update-crypto-policies --set FUTURE:SHA-1`,
file bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `,
mention this change page, the version of crypto-policies package
and the policies under which your workflow does and does not work.
=== Testing passively ===
Install a special logging tool from
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer
Run it and proceed to use your system.
Once the tool notifies you about
about soon-to-be-blocked SHA-1 signature operations,
identify the component and actions leading to these operations,
verify that repeating them leads to logging more entries.
Ideally also verify that switching to a stricter policy breaks the workflow.
File bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `
and link to this change page.
== User Experience ==
Things will break.
All kinds of things depending on SHA-1 signatures, openly and secretly.
* '''On Fedora 37 they'll break opt-in.'''
* On Fedora 38 rawhide they'll break by default.
* On Fedora 38 released they'll behave like in Fedora 37.
* On Fedora 39 they'll break by default again, including the released version.
== Dependencies ==
While it would be welcome,
no reverse dependencies of openssl have to react in time for Fedora 37,
where the change is opt-in preview only.
For now, test, file bugs and spark discussions.
A small coordinated change with openssl is required.
== Contingency Plan ==
* Contingency mechanism: not needed for F37
* Contingency deadline: not needed for F37
* Blocks release? no
== Documentation ==
Workaround API
should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
Packaging guidelines should be modified accordingly.
== Release Notes ==
https://pagure.io/fedora-docs/release-notes/issue/829
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-04-25.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
erlang-riak_api bowlofeggs, erlang-maint-sig, 1 weeks ago
orphan
erlang-riak_core bowlofeggs, erlang-maint-sig, 1 weeks ago
orphan
forbidden-apis jvanek, orphan 1 weeks ago
gnome-shell-extension-material- atim, orphan 2 weeks ago
shell
golang-github-astaxie-beego go-sig, orphan 2 weeks ago
golang-github-influxdata- go-sig, orphan 1 weeks ago
influxdb
hd-idle atim, orphan 3 weeks ago
jsoup mizdebsk, orphan 0 weeks ago
libcxl orphan 1 weeks ago
mcrcon orphan 3 weeks ago
mustache-d orphan 1 weeks ago
python-django-auth-ldap orphan 0 weeks ago
python-readthedocs-sphinx-ext jjames, orphan, python-sig 0 weeks ago
qt5-qtcanvas3d kde-sig, orphan 5 weeks ago
qt5-qtenginio kde-sig, lupinix, orphan 5 weeks ago
quake2 orphan 1 weeks ago
rubygem-request_store orphan 3 weeks ago
rust-ab_glyph orphan, rust-sig 0 weeks ago
rust-alsa orphan, rust-sig 0 weeks ago
rust-alsa-sys orphan, rust-sig 0 weeks ago
rust-bitreader orphan, rust-sig 0 weeks ago
rust-build-env orphan, rust-sig 0 weeks ago
rust-cgmath orphan, rust-sig 0 weeks ago
rust-chlorine orphan, rust-sig 0 weeks ago
rust-claxon orphan, rust-sig 0 weeks ago
rust-cloudflare-zlib orphan, rust-sig 0 weeks ago
rust-cloudflare-zlib-sys orphan, rust-sig 0 weeks ago
rust-cpal orphan, rust-sig 0 weeks ago
rust-cstr-argument orphan, rust-sig 0 weeks ago
rust-diffus-derive orphan, rust-sig 5 weeks ago
rust-fallible_collections orphan, rust-sig 0 weeks ago
rust-fontconfig-parser orphan, rust-sig 0 weeks ago
rust-genmesh orphan, rust-sig 0 weeks ago
rust-glyph_brush_layout orphan, rust-sig 0 weeks ago
rust-hound orphan, rust-sig 0 weeks ago
rust-image-roll orphan, rust-sig 0 weeks ago
rust-imgui orphan, rust-sig 0 weeks ago
rust-imgui-sys orphan, rust-sig 0 weeks ago
rust-lewton orphan, rust-sig 0 weeks ago
rust-libdeflate-sys orphan, rust-sig 0 weeks ago
rust-libdeflater orphan, rust-sig 0 weeks ago
rust-libsystemd-sys orphan, rust-sig 0 weeks ago
rust-libwebp-sys2 orphan, rust-sig 0 weeks ago
rust-minimp3 orphan, rust-sig 0 weeks ago
rust-minimp3-sys orphan, rust-sig 0 weeks ago
rust-newsblur_api orphan, rust-sig 5 weeks ago
rust-ogg orphan, rust-sig 0 weeks ago
rust-opml orphan, rust-sig 5 weeks ago
rust-pam-client orphan, rust-sig 0 weeks ago
rust-piston orphan 0 weeks ago
rust-piston-float orphan, rust-sig 0 weeks ago
rust-piston- orphan, rust-sig 0 weeks ago
graphics_api_version
rust-piston-viewport orphan, rust-sig 0 weeks ago
rust-pistoncore-event_loop orphan 0 weeks ago
rust-pistoncore-input orphan, rust-sig 0 weeks ago
rust-rental-impl orphan, rust-sig 0 weeks ago
rust-ringbuf orphan, rust-sig 0 weeks ago
rust-systemd orphan, rust-sig 0 weeks ago
rust-utf8-cstr orphan, rust-sig 0 weeks ago
rust-vcpkg orphan, rust-sig 0 weeks ago
rust-zopfli orphan, rust-sig 0 weeks ago
yecht orphan 6 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2022-04-25.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
almac: jsoup
amigadave: python-readthedocs-sphinx-ext
ankursinha: python-readthedocs-sphinx-ext
atim: hd-idle, gnome-shell-extension-material-shell
bowlofeggs: erlang-riak_core, erlang-riak_api
cdorney: jsoup
cfu: jsoup
churchyard: python-readthedocs-sphinx-ext
cicku: python-readthedocs-sphinx-ext
cstratak: python-readthedocs-sphinx-ext
dbhole: jsoup
dchen: jsoup
deamn: jsoup
didiksupriadi41: jsoup
dmsimard: python-readthedocs-sphinx-ext
echevemaster: python-readthedocs-sphinx-ext
eclipse-sig: jsoup
ellert: jsoup
epel-packagers-sig: python-readthedocs-sphinx-ext
erlang-maint-sig: erlang-riak_core, erlang-riak_api
go-sig: golang-github-influxdata-influxdb, golang-github-astaxie-beego
guidograzioli: jsoup
hhorak: jsoup
ignatenkobrain: rust-opml, rust-newsblur_api
infra-sig: python-readthedocs-sphinx-ext
jcapik: jsoup
jerboaa: jsoup
jhuttana: jsoup
jjames: jsoup, python-readthedocs-sphinx-ext
jjelen: jsoup
jmagne: jsoup
jorti: python-readthedocs-sphinx-ext
jvanek: forbidden-apis
kde-sig: qt5-qtcanvas3d, qt5-qtenginio
ke4qqq: jsoup
kni: jsoup
korkeala: jsoup
ksurma: python-readthedocs-sphinx-ext
kubo: python-readthedocs-sphinx-ext
lbalhar: python-readthedocs-sphinx-ext
lupinix: qt5-qtenginio
mbooth: jsoup
mharmsen: jsoup
mhayden: python-readthedocs-sphinx-ext
mikelo2: python-readthedocs-sphinx-ext
mizdebsk: jsoup
mjakubicek: jsoup
mkulik: jsoup
mrunge: python-readthedocs-sphinx-ext
msimacek: jsoup
neuro-sig: python-readthedocs-sphinx-ext
ngompa: python-readthedocs-sphinx-ext
odubaj: jsoup
orion: python-readthedocs-sphinx-ext
pingou: jsoup
pjp: python-readthedocs-sphinx-ext
pnemade: python-readthedocs-sphinx-ext
python-sig: python-readthedocs-sphinx-ext
raphgro: python-readthedocs-sphinx-ext
rust-sig: rust-chlorine, rust-diffus-derive, rust-systemd, rust-zopfli,
rust-imgui, rust-minimp3-sys, rust-minimp3, rust-piston-viewport,
rust-piston-graphics_api_version, rust-imgui-sys, rust-libdeflater,
rust-pam-client, rust-genmesh, rust-alsa-sys, rust-hound, rust-libwebp-sys2,
rust-rental-impl, rust-bitreader, rust-ringbuf, rust-cloudflare-zlib,
rust-lewton, rust-fontconfig-parser, rust-cgmath, rust-utf8-cstr, rust-claxon,
rust-cpal, rust-libdeflate-sys, rust-cstr-argument, rust-libsystemd-sys,
rust-newsblur_api, rust-cloudflare-zlib-sys, rust-build-env, rust-alsa,
rust-piston-float, rust-ab_glyph, rust-opml, rust-pistoncore-input, rust-ogg,
rust-vcpkg, rust-glyph_brush_layout, rust-image-roll, rust-fallible_collections
salimma: python-readthedocs-sphinx-ext
sasiddiq: jsoup
scorreia: rust-vcpkg
smani: python-readthedocs-sphinx-ext
smilner: python-readthedocs-sphinx-ext
spot: jsoup
suve: python-readthedocs-sphinx-ext
tagoh: python-readthedocs-sphinx-ext
thrnciar: python-readthedocs-sphinx-ext
ueno: rust-vcpkg
walters: jsoup
yyang: jsoup
zmiklank: jsoup
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
Report finished at 2022-04-25 17:08:08 UTC
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 7 months
F37 Change: Replace jwhois package with whois for Fedora Workstation
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Replace_jwhois_with_whois_in_Fedor...
== Summary ==
Fedora Workstation product core group includes `jwhois` package.
Replace it with `whois` package which is more actively developed.
== Detailed Description ==
`Fedora Workstation product core` group includes `jwhois` package. Its
last commit is [http://www.gnu.org/software/jwhois/ from 2015]. Users
having issues with certain TLDs and the solution is usually manually
editing the `/etc/jwois.conf` file. `whois` package is
[https://github.com/rfc1036/whois more actively maintained] and
doesn't have those issues.
== Benefit to Fedora ==
Users will have a better experience querying `whois` information for a domain.
== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* 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 ==
== How To Test ==
* Run `rpm -q --whatprovides whois`
* It should print `whois-*`
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* 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)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
F37 Change: Haskell GHC 9.0 & Stackage LTS 19 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.0_%26_Stackage_19
== Summary ==
The GHC Haskell compiler will be updated from major version 8.10 to 9.0,
and Haskell packages will be updated from Stackage LTS 18 to LTS 19 versions.
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: petersen(a)redhat.com
* Name: [[Haskell_SIG|Haskell SIG]]
* Email: haskell(a)lists.fedoraproject.org
== Detailed Description ==
For Fedora 37, the GHC Haskell compiler will be updated from version
8.10.5 to the latest stable 9.0.2 release (rebasing from the ghc9.0
package).
Along with this, Haskell packages in [https://www.stackage.org
Stackage] (the stable Haskell source package distribution) will be
updated from the versions in LTS 18 to latest LTS 19 release.
Haskell packages not in Stackage will be updated to the latest
appropriate version in the upstream [https://hackage.haskell.org
Hackage] package repository.
== Benefit to Fedora ==
Fedora users will have the latest stable Haskell compiler release,
package tools, and current Haskell packages from Stackage LTS.
GHC 9.0 is first major release of the GHC 9 series and features
performance improvements, new language extension features (in
particular Linear types support), and bugfixes (see the release notes
linked in the Documentation section for more details).
== Scope ==
* Proposal owners:
** update ghc8.10 is build against itself
** rebase ghc to 9.0.2
** update ghc-rpm-macros to the final version for F37
** refresh packagings with the latest cabal-rpm release
** update packages to latest [https://www.stackage.org/lts-19 Stackage
LTS 19] versions using cabal-rpm
** build all the packages in a Koji sidetag repo in dependency order
using fbrnch
** push the sidetag through Bodhi to Rawhide before the mass rebuild
* Other developers: no actions should be needed
<!-- * Release engineering:
* 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 ==
Any dropped packages will have obsoletes added.
Otherwise there should not be any direct upgrade impact.
Users' Haskell projects will get built with ghc-9.0 when they next
build them and might need some minor code tweaks.
== How To Test ==
* install ghc and cabal-install
* install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep <favouritepackage>; cabal install <favouritepackage>
* test upgrades of F36 Haskell packages to F37
== User Experience ==
Users will have the most recent stable major version of `ghc` and
Haskell libraries and tools available to them.
This makes it easier to build the latest versions of Haskell projects.
In particular `cabal-install` will also be updated from 3.2 to 3.4.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will drop the new builds and
revert back to the versions in F36.
* Contingency deadline: Beta Freeze
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* https://www.haskell.org/ghc/blog/20210204-ghc-9.0.1-released.html
* https://downloads.haskell.org/~ghc/9.0.2/docs/html/users_guide/9.0.1-note...
* https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html
* https://downloads.haskell.org/~ghc/9.0.2/docs/html/users_guide/9.0.2-note...
== Release Notes ==
The Haskell GHC compiler has been updated from 8.10.5 to 9.0.2 with
many improvements.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf
== Summary ==
A major upgrade of Microdnf is the first step in the evolution of
package management in Fedora. The new microdnf has ambitions to
provide all major features of DNF without losing its minimal
footprint.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The new major Microdnf will provide huge improvements and in some
cases better behavior then DNF. In the future, the new Microdnf will
replace DNF. The new Microdnf will be accompanied by a new library
(`libdnf5`) and a new DNF Daemon.
=== MICRODNF features ===
* Improved user experience
** Improved progress bars
** Improved transaction table
** Transaction progress reports including scriptlets reports
** Support of local rpm for transaction operation
** Great bash completion (better then DNF has)
=== LIBDNF5 features ===
* Fully integrated Modularity in LIBDNF workflows
** Modularity is currently supported in DNF and LIBDNF, but it is not
fully integrated due to limitations in compatibility with other tools
(PackageKit)
** Fully integrated Modularity requires changes in library workflow
* Unified user interface
** DNF/YUM was developed for decades with the impact of multiple
styles and naming conventions (options, configuration options,
commands)
* Plugins
** DNF plugins are not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently to DNF
* New plugins (C++, Python) will be available for all users
** Unified behavior
** Removal of functional duplicates
*** Decrease maintenance cost
* Shared configurations
** In DNF4 the configuration is only partially honored by PackageKit
and Microdnf
* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into the
Desktop
* Additional improvements
** Reports in structure (API)
*** DNF reports a lot of important information only in logs
* Shared cache and improved cache handling (optional, not available in
Fedora 38)
** Microdnf, DNF4, and PackageKit use cached repositories on a
different location with different cache structure
* Performance improvement
** Loading of repositories
** Advisory operation
** RPM query
*** Name filters with a case-insensitive search
** Smart sharing of metadata between dnf, microdnf, daemon (optional,
not available in Fedora 38)
*** Reduce disk and downloads requirements
* Relocation of internal databases into `/usr`
** Make rollback more easy
=== Downsides ===
* Relocation of internal databases and different structure of internal databases
** The transaction performed by the new MICRODNF will be not visible by DNF
** The transaction performed by DNF or PackageKit will be not visible
by the new MICRODNF
** Packages installed by another packager will be handled as userinstalled
*** Consequence => The removal of a package will not trigger removal
of unused dependencies
* Compatibility
** To improve user experience and to unify dnf/microdnf behavior we
were unable to keep 100% compatibility with formal Microdnf in
command-line and in behavior
== Benefit to Fedora ==
The new MICRODNF significantly improves the user experience and in the
future it will provide all important features of DNF. It will also
keep all advantages of the original MICRODNF, like minimal size
required by containers.
The presence of MICRODNF, LIBDNF5, and DNFDAEMON in the distribution
will also allow for a smooth transition of components using `dnf`,
`python3-dnf`, `python3-hawkey`, `libdnf`, `dnfdragora`, and
`python3-dnfdaemon` to a new library.
* Improved progress bars
* Improved transaction table
* Transaction progress reports including scriptlets reports
* Support of local rpm for transaction operation
* Great bash completion (better then DNF has)
* `builddep` command without Python on the system
== Scope ==
* Proposal owners:
The new Microdnf is still in the development and some of the features
or options are not yet available. We still have to finish the
implementation of Modularity, storing internal data related to History
and System State, and also documentation and man pages. The new
Microdnf can be tested from repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's github repository is here -
https://github.com/rpm-software-management/libdnf/tree/dnf-5-devel
* 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:
== Upgrade/compatibility impact ==
== How To Test ==
== User Experience ==
* Improved progress bars
* Improved transaction table
* Transaction progress reports including scriptlets reports
* Support of local rpm for transaction operation
* Great bash completion (better then DNF has)
* New commands and options that are only available with `DNF`
== Dependencies ==
== Contingency Plan ==
* 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), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months