[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
1 year, 10 months
Wine MinGW system libraries
by Zebediah Figura
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
[2] https://fedoraproject.org/wiki/Bundled_Libraries
1 year, 11 months
Minizip pull requests
by Julian Sikorski
Hello,
I have created two PRs against minizip which are yet to be merged:
- https://src.fedoraproject.org/rpms/minizip/pull-request/3
- https://src.fedoraproject.org/rpms/minizip/pull-request/4
The first one should be a low risk one and should allow pkg-config using
dependencies like (shameless self-interest plug) to build against system
minizip again.
The second one needs support from a provenpackager. I tried rebuilding
the 18 dependencies of minizip and this is a bit tricky for two reasons:
- libsmbl and libspatialite need to be rebuilt before the other dependencies
- I cannot figure out how to get fedpkg srpm to work with libspatialite,
I am getting a Package already exists: %package debuginfo error from the
%{?mingw_debug_package} line. I am sure this is something someone
familiar with mingw can fix in a shortest amount of time.
Other than that, I can confirm that 13 dependencies can be rebuilt with
no changes. How can we move this forward?
Best regards,
Julian
1 year, 11 months
Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS
by py0xc3
Good everning,
I just experienced that, when setting up a new Fedora, Anaconda (both
"Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64
for disk encryption, even if the hardware does not support AES-NI.
Does it make sense to use xchacha12,aes-adiantum-plain64 by default if
there is no AES-NI in the hardware?
For a general use case, the security advantages of Adiantum can be
neglected; both aes-xts & chacha-adiantum are secure.
But there are big performance disadvantages of AES when there is no
AES-NI (this was the major reason for merging Adiantum into the kernel).
Besides the use of system resources, netbooks and such may have strongly
decreased battery life times with aes-xts (the issue is primarily aes,
not xts).
I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric,
I expect that other Workstation installations tend to the same behavior.
Adjustments would be limited to Anaconda.
Regards & stay safe,
Chris
1 year, 11 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, 11 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, 11 months
OpenJDK and unremoved directories
by Vitaly Zaitsev
Hello.
I have a lot of unremoved directories and files in /usr/lib/jvm/:
$ ls -l /usr/lib/jvm/
total 140
drwxr-xr-x. 5 root root 4096 Sep 10 14:32
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
drwxr-xr-x. 3 root root 4096 Mar 14 2017
java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Apr 21 2017
java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Jan 24 2018
java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2018
java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 2018
java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 18 2018
java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 3 2018
java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jun 18 2018
java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 23 2018
java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Sep 5 2018
java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 4 2018
java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 29 2018
java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 1 2018
java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Jan 14 2019
java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2019
java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Mar 26 2019
java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Jul 31 2019
java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Jan 28 2020
java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Mar 23 2020
java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 4 2020
java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 22 2020
java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 17 2020
java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 28 2020
java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Oct 21 2020
java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64
lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre
lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11
lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk ->
/etc/alternatives/jre_11_openjdk
lrwxrwxrwx. 1 root root 41 Aug 31 18:50
jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 ->
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk ->
/etc/alternatives/jre_openjdk
I think the OpenJDK's scriplets need to be adjusted to remove everything.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 11 months
grub2 BIOS booting iso and code
by Brian C. Lane
A huge thanks to Thomas Schmitt for posting xorrisofs arguments :)
Here is a lorax PR switching to grub2 for BIOS and changing the layout
of the iso as described in his post:
https://github.com/weldr/lorax/pull/1226
And a Fedora 36 iso:
https://bcl.fedorapeople.org/boot-grub2-f36.iso
I've tested this with:
- qemu bios -cdrom
- qemu uefi -cdrom
- qemu bios -hda
- qemu uefi -hda
- USB stick on uefi PC hardware with SB off
- USB stick on UEFI PC hardware with SB on
- USB stick on Apple hardware UEFI
2010 Macbook Air and 2012 Macbook Pro
- Media test works on all of the above
I have not tested it on CD or DVD physical media. I have a stack of
blank discs but apparently have unplugged all my drives to use their
SATA ports for SSDs :)
Brian
--
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
1 year, 11 months
RHEL moving to issues.redhat.com only long term
by Josh Boyer
Hi Fedora, CentOS, and EPEL Communities!
As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon. That means planning for the next release
will start in earnest in the very near future. As some of you may
know, Red Hat has been using both Bugzilla and Jira via
issues.redhat.com for RHEL development for several years. Our
intention is to move to using issues.redhat.com only for the major
RHEL releases after RHEL 9.
What does this mean for Fedora and CentOS? This discussion is in part
to figure that out. Based on some very brief analysis, the following
should hold:
- RHEL customers should continue to file support cases through the Red
Hat Customer portal, which will remain consistent regardless of the
backend tooling used.
- There is no imminent retirement of the Red Hat Bugzilla instance
being planned at this time. RHEL 7, 8, and 9 will continue to use
bugzilla in some form and RHEL 9 has a very long lifecycle.
- Fedora Linux and EPEL have their own Bugzilla product families and
are not directly impacted in their own workflows by the choice to use
only issues.redhat.com for RHEL.
- There will be impacts on existing documentation that provide
guidance on requesting things from RHEL in various places like EPEL.
We will be happy to help adjust these.
- CentOS Stream contribution and bug reporting workflows will be
adjusted to use issues.redhat.com instead of bugzilla in the relevant
places. This should apply to all versions of CentOS Stream for a
unified contributor workflow. This will happen gradually as we
discover the best workflow to use.
If there are other impacts that you can think of, please raise them on
this thread. We’d like to ensure we’re covering as much as possible
as this rolls out.
josh
1 year, 12 months
