Hey all,
Just making everyone aware of a planned outage for approximately 5 hours
for Bugzilla. Some relevant details are below:
Leigh
> What’s changing for users?
The only functionality change that users will see is that we will be making
> changes to the search returns and default bug list. They will now be
> default set to 200, a maximum of 1000, and need to be offset
> <https://bugzilla.redhat.com/docs/en/html/integrating/api/Bugzilla/WebServic…> to
> get more results in API calls.
OUTAGE TIMING
>
> -
>
> Date: July 31, 2021
> -
>
> Start:
> -
>
> 12:30 UTC
> -
>
> End:
> -
>
> 17:30 UTC
> -
>
> Duration: Approximately 5 Hrs
>
> CUSTOMER IMPACT
>
> Bugzilla will be unavailable, and users will not be able to
> create/view/edit/delete Bugzilla issues during the maintenance window.
>
--
Leigh Griffin
Senior Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
Hello all,
As I announced a month ago[1], the CentOS Hyperscale SIG started
producing an experimental Hyperscale Workstation Spin to showcase the
technologies we're working on to the broader community.
Today, I'm pleased to announce we've made updated images again!
Notably, this refresh not only includes an updated experimental GNOME
Workstation ISO, but now we have an experimental KDE Workstation ISO,
based on the great work that Troy Dawson has done to refresh KDE
Plasma in EPEL[2].
The spins are available here:
* GNOME ISO: https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-GNOME-LIVE-20210724.iso
* KDE ISO: https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-KDE-LIVE-20210724.iso
* SHA512 checksums:
https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-LIVE-20210724-CHECKSUMS
(Apologies for the ugly domain, we've filed a request to fix this with
CentOS infra: https://pagure.io/centos-infra/issue/389)
The changes with this build from last week's[3] (aside from updated
packages and new KDE flavor):
* SELinux denials with systemd-hostnamed and systemd-oomd should no
longer occur. The SELinux policy module for systemd has been refreshed
to resolve this.
* SELinux denials with sssd and useradd should no longer occur.
The other known issues from earlier announcements[1][3] are still
present in this release.
However, for KDE Plasma, there are several known issues:
* The branding is incoherent. SDDM uses the Fedora 31 background in
its theme and Plasma itself reverts to upstream branding instead of
CentOS-specific branding. This is being investigated and will be
resolved in a future release.
* Konsole opens up as a tiny window until you resize it. This is an
upstream bug: https://bugs.kde.org/show_bug.cgi?id=437791
* The application panel opens up in the center instead of on the left,
and sometimes gets its own application icon when opened up. This is
being investigated and will be resolved in a future release.
If you find any other issues, we would definitely love to hear about
them! We have a dedicated issue tracker for Hyperscale spins where we
would appreciate bugs to be reported:
https://pagure.io/centos-sig-hyperscale/spin-bugs
We hope you enjoy it as much as I enjoyed making this!
Thanks and best regards,
Neal (on behalf of the CentOS Hyperscale SIG)
[1]: https://lists.centos.org/pipermail/centos-devel/2021-June/077079.html
[2]: https://lists.centos.org/pipermail/centos-devel/2021-July/077167.html
[3]: https://lists.centos.org/pipermail/centos-devel/2021-July/077156.html
--
真実はいつも一つ!/ Always, there's only one truth!
An updated qt5 in CentOS Stream 8 allowed us to update KDE Plasma Desktop.
I believe everything is in place and ready for use and/or testing.
This is for CentOS Stream 8 only, at this time.
===How to Install [1]
= Install epel-release
dnf install
https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
= Enable PowerTools
dnf config-manager --enable powertools
= Install KDE
dnf group install kde-desktop-environment
or
dnf group install kde-desktop
(Optional) dnf group install kde-apps
(Optional) dnf group install kde-media
(Optional) dnf group install kde-education
(Optional) dnf install okular
(Optional) dnf group install kde-software-development
(Optional) dnf group install kf5-software-development
=== KNOWN PACKAGE ISSUES
== UNINSTALLABLE PACKAGES
* kaccounts-providers - no signon-ui
* kigo - no gnugo
* lokalize - no translate-toolkit , needs rebuilding on python3
== UNBUILT PACKAGES
* polkit-qt5 - need branch and build of polkit-qt-1
* kde-gtk-config - needs sassc
* digikam - can't find opencv despite it being installed
== UN-UPDATED PACKAGES (but still install and run)
* kpmcore - would need a newer util-linux than available in RHEL 8
* kde-partitionmanager - would need a newer kpmcore
Feel free to install and test.
Troy Dawson
[1] - https://fedoraproject.org/wiki/SIGs/KDE/EPEL#Installation
Hello,
I noticed the centos:8 image on Docker Hub is still 8.3.2011, from 7
months ago. Is it planned to push an 8.4 image? Thanks!
Best wishes,
Pierre Riteau
TLDR: CFP is at https://forms.gle/ngbhjPQvLSNZ4VqP8
We will be holding our third online Dojo of 2021 October 7th and 8th
(assuming we get enough submissions).
Details are at https://wiki.centos.org/Events/Dojo/October2021
The call for presentations (CFP) is now open at
https://forms.gle/ngbhjPQvLSNZ4VqP8
We are looking for presentations about CentOS Linux, CentOS Stream,
CentOS SIG work, any work in the CentOS community, or any project you're
running on top of CentOS distributions.
Presentations will be delivered live, using the Hopin online conference
platform. Presentations will be 40 minutes, including any Q&A time you
want to have.
The CFP will close at 00:01 on September 6th.
Hi, folks,
following up from the discussion over the last two weeks about the
CentOS 8 EOL announcement, and specific details of that plan, I wanted
to share with you this DRAFT announcement, for commentary.
It's worth noting that certain aspects of this draft are not negotiable.
Specifically:
* We will not ship further updates after the EOL date
* We will not automatically migrate CentOS Linux 8 users to CentOS Stream 8
However, other suggestions, clarifications, and edits are welcome, with
the goal of removing any ambiguity or misunderstanding that might occur
from a poorly worded message.
-------
DRAFT BEGINS: CentOS 8 EOL messaging
CentOS Linux 8 will reach End Of Life (EOL) on December 31st, 2021.
Here’s what that means.
In line with the EOL of previous releases, we will NOT be automatically
migrating anyone to the next version (which is CentOS Stream 8 in this
case).
We will be shipping a rebuild of Red Hat Enterprise Linux (RHEL) 8.5
once it is released, even if that means that this is released slightly
after the EOL date.
The release of a RHEL point release is often accompanied, immediately
afterwards, by a set of zero-day updates. We will be providing this
content as part of the final CentOS Linux 8 release. There will,
however, be no more updates to the CentOS Linux 8 content after that time.
Additionally, with this deadline falling during a time when many of our
team, as well as many of our users, will be out of the office, we intend
to bend the usual EOL process by keeping this content available until
January 31st.
At that time, or in the event of a serious security bug in this time
window (Defined as anything with a VCSS v3 score of 9 or greater), this
content will be removed from our mirrors, and moved to vault.centos.org
where it will be archived permanently, since we will not be able to
provide updates to the content after the EOL date.
DRAFT ENDS
-----------------
We are considering shipping a dnf plugin that gives informational
messages about the CL8 EOL, and explain the process for moving to CS8,
for users who are not yet aware of the change. There is some concern
around this plan due to anecdotal evidence that some people automate the
capture and parsing of dnf output, and this might break that. Comments
welcome on this topic, but of course if you’re reading this, you’re
already aware of the EOL, making this a challenging issue to get
feedback on.
We welcome your comments on this proposal, and intend to publish this
more widely after a reasonable comment period.
Thanks!
Hi everyone, I had sent a few other updates to the list regarding free RHEL
programs and so I thought I would make sure to link to this one announced
today. For those of you in academic or research institutions, this is the
announcement you've been looking for. Generally, this program has been in
place for some time but you had to know who to reach out to for discussion.
For those who are interested, give it a read.
https://www.redhat.com/en/blog/expanding-red-hat-enterprise-linux-choices-r…
--
Mike McGrath
Linux Engineering - Chicago
Red Hat
mmcgrath(a)redhat.com T: (312)-660-3547
Hello all,
As I announced a few weeks back[1], the CentOS Hyperscale SIG started
producing an experimental Hyperscale Workstation Spin to showcase the
technologies we're working on to the broader community.
Today, I'm pleased to announce that we've made an updated image to
address some issues present in the first release.
Like before, the spin is currently available here:
* ISO: https://ngompa.fedorapeople.org/centos/hyperscale/CS8-HS-WORK-LIVE-LATESTDE…
* SHA512 checksum:
https://ngompa.fedorapeople.org/centos/hyperscale/CS8-HS-WORK-LIVE-LATESTDE…
The changes with this build (aside from updated packages):
* The Anaconda installer icon and other branding is now correctly
present and used. Thanks to Alain Reguera Delgado and Carl George for
getting all this in place!
* "dnf upgrade" works now, as we've refreshed our custom version of
the RPM+DNF stack.
* UDisks2 now has its Btrfs module installed out of the box. GNOME
Disks, Cockpit, and others that use UDisks2 will now be able to
properly detect and work with Btrfs (insomuch as the feature have been
implemented in those tools).
The other known issues from the initial announcement[1] are still
present in this release. However, there is a new known issue:
* Blivet is broken with MD devices with names that look like BIOS
drive numbers, causing Anaconda to crash in the process. This is
caused by the blivet rebase from 3.2.x to 3.4.0 without backporting
the fix for this issue and is present in the CentOS Stream 8 software.
Red Hat Bugzilla bug report (with patch):
https://bugzilla.redhat.com/1983309
If you find any other issues, we would definitely love to hear about
them! We have a dedicated issue tracker for Hyperscale spins where we
would appreciate bugs to be reported:
https://pagure.io/centos-sig-hyperscale/spin-bugs
We hope you enjoy it as much as I enjoyed making this!
Thanks and best regards,
Neal (on behalf of the CentOS Hyperscale SIG)
[1]: https://lists.centos.org/pipermail/centos-devel/2021-June/077079.html
--
真実はいつも一つ!/ Always, there's only one truth!
As we get closer to the CentOS Linux 8 EOL, we're getting more and more
questions about how the EOL is actually going to work. While there tends
to be a great deal of "everybody just knows how it works" among the
people actually on this list, we're getting attention from a much larger
audience now, and they don't know.
To that end, I want to make sure we have clear documentation,
prominently displayed, that sets expectations as we get closer to that
December 31 date,
So ... as I understand, our process is basically:
1. Copy old data to vault.centos.org
2. Update web pages and links to say it is now on vault.centos.org
3. Turn off mirrorlist to that release name (aka all requests to
CentOS-8 will 404)
4. Remove the data from the main mirrors with a file saying look at
vault.centos.org
5. Mirrors pick all that up in 4-8 hours.
Is there more to it than this? Will we do anything different this time
because CL8 is a special case? Am I missing any steps, or have I
misunderstood any of the steps? Is this already documented somewhere
that I simply haven't found yet?
Are there any changes to this process that we *want* to advocate for,
given the special nature of this particular EOL? (No, I absolutely
cannot promise anything, but I can ask.)
Based on the office hour earlier this week, I spent some time
performing scans of the PowerTools repo to see what packages from
BaseOS, AppStream, and EPEL rely on it.
The results of these scans can be found in a repo here:
https://gitlab.com/omenos/crb-depends
I was only able to do x86 based scans, and there will be some dupes of
packages because i686 and x86_64 versions exist. Unfortunately this is
a pretty basic check; I didn't differentiate between package types
during cleanup, so there will be a lot of -devel packages showing up.
Hopefully the data is accurate, I did this fairly late at night :)
--
Mike Rochefort