Hi all,
As you're all aware (we sent multiple mails in the last year about
this), CentOS 7 and Stream 8 will go EOL soon :
https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-an…
Let's lists some things that will happen on the CentOS Infrastructure as
we'll be approching (or passed) these dates :
# CentOS 7/8s content itself
Usual process : content will be archived to https://vault.centos.org and
removed from mirror.centos.org completely, with just a simple readme
file dropped here (for example http://mirror.centos.org/centos/8/readme
for already EOL'ed version). Worth knowing that some SIGs are still
building for RHEL8, still supported for SIGs through
https://cbs.centos.org so such kind of content will continue to be
available there as long as SIGs can build against/for it
# CBS/koji (https://cbs.centos.org)
No impact on CBS env itself ( not running centos 7 nor 8s for a long
time now) but the various build tag reflecting centos 7 and 8s will be
locked so that nobody would be able to build content anymore : that
would even be impossible as content itself will have been removed from
mirror.centos.org (internally used for cbs build tags)
# CentOS Forums (https://forums.centos.org) :
still running on centos 7 and even if that's easy to migrate to
newer/supported EL version, it was decided to just shutdown the service
(based on discussion with the actual moderation team). An option (to be
announced on forums.centos.org ?) is to eventually start moving
thread/discussions on Fedora discourse (There is already a CentOS
category there : https://discussion.fedoraproject.org/c/neighbors/centos/71)
So the plan is just to shutdown forums.centos.org and remove A/AAAA
records from DNS
# mirrorlist.centos.org service :
Starting from Stream 9 (and above), deployed CentOS instance ares using
Fedora infra mirrormanager instance for metalink= instead of mirrorlist=
in .repo files. We'll just decommission our mirror crawler (also running
with a mix of perl/python2 code), so not validating any mirror for
legacy/EOL releases. mirrorlist.centos.org A/AAAA records will be
removed in the following weeks after c7 will be EOL'ed.
That means that people still running CentOS 7 or 8-stream will not have
functional yum/dnf stack, except if they point to either vault or have
internal mirror but at least people would be aware that distro itself is
EOL and that they shouldn't expect to receive any update anymore
# CentOS mailing-lists
Currently running on mailman2 stack, on top of CentOS 7 linux : there is
WIP to port everything to up2date mailman3 stack, actually packaged for
EPEL9.
We have successfully imported archives into mailman3 and same for lists
config but let's start a different/separate thread to discuss changes
(like renaming lists, see next coming thread)
Kind Regards,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
As mentioned in previous thread about centos 7 EOL, one of the last
application that was still running on centos linux 7 is mailman, serving
centos lists for a long time now.
Thanks to all the hard work done by community contributors (thanks
Michel, Neal and others having participated !), there is now a fully
functional mailman3 stack available in Epel9.
There are still very minor things to do to be 100% ready for a real
migration, but we should have a stable .stg. instance deployed very
soon. (There is a sandbox instance that is reinstalled / scratched for now)
While importing existing lists/archives from mailman2 to mailman3 test
instance, there was a discussion (in a Matrix room) about eventually
using this migration as an opportunity to rename the lists.
For legacy reasons (don't know why as it was even before I joined the
project :) ) , lists were created on the same box as MX record for
centos.org and so lists were usually called : <lists>@centos.org.
The (usual) method is instead to create a dedicate host/sub-domain that
will hosts mailling lists, like lists.<domain> and so lists.centos.org
(amusingly that's also the hostname we have for the https instance but
not for the existing lists)
As the discussion was just happening in a Matrix room, and more like a
brainstorming session, I thought it would be better (for awareness) to
start a real thread on this list, as it's about the future of the list
itself :)
Some people suggested to rename lists like this : (example):
centos-devel(a)centos.org => devel(a)lists.centos.org
While technically that seems to work (tested on the import from mailman2
to mailman3) , it would need local aliases so that mails sent to
previous address list would just still go to new list (to be tested as I
don't know which checks are done by mailman-core now, and SPF, DMARC,
DKIM, etc if we just create aliases)
This is a RFC (request for comments) thread so let us know what you
think .. ideally before we start migrating the real instance :-)
Kind Regards,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
Hi centos-devel,
Per the subject: I found a repo file in centos-release-kmods-kernel
that references kernel-latest but not -6.1 of -6.6.
Are those repos intended to have centos-release-* files?
Regards
A Alba
Hi Everyone,
Our next board meeting will take place at 21:00 UTC tomorrow
`date -d "2024-03-13 21:00 UTC"`
Given that some of the board members are traveling, we may not achieve
quorum, so we are planning a brief meeting.
If you would like to attend please send me an email to
alphacc(a)centosproject.org ( please do not reply to @centos-devel or use
another email address) and you will receive a link to a meeting
room with a passcode, 1 hour before the meeting takes place.
The agenda can be checked at (work in progress) :
https://hackmd.io/@centosboard/BJ5Xnxapa
As a reminder we will enforce few rules :
* Wait to be recognized by the Chair before speaking
* Respect the Chair when told your time to speak is over - this will
allow us to remain on agenda, and complete the meetings in the
allotted time
* In the event that there are Board-confidential topics, these will be
put at the end of the meeting, in Executive Session, and guests will be
asked to leave. We hope to minimize these items, but they do sometimes
happen. The most common scenarios in which this may happen are personnel
issues, or information that Red Hat wishes to share with the Board, but
is not yet public.
* Muting of participants, or, in extreme situations, ejection from the
meeting, is at the sole discretion of the Chair.
* Meetings will be recorded, and published to YouTube (possibly with
edits/redaction, as approved by the Directors). Thus, by joining the
meeting you consent to have your presence at the meeting, and anything
you say during the meeting, made public.
I hope some of you can join.
Sorry for the late announcement.
thanks,
--
Thomas 'alphacc' Oulevey
CentOS Board of Directors Secretary
alphacc(a)centosproject.org
Hi,
Latest CentOS Stream compose is failing to install ruby.
"dnf install ruby" tries to install modularized
3.1.2-141.module_el9+156+2e0939d1 version and fails with errors:
Error: No available modular metadata for modular package
Workaround is to specify unmodular version:
# sudo dnf install ruby-3.0.4
I've reported it in https://issues.redhat.com/browse/RHEL-28082
Note that if other packages require 3.0 (in RDO case, via automatic dep on
"libruby.so.3.0()(64bit)" i.e.) it will just work.
Best regards,
Alfredo
Does someone sees this behaviour?
$ /usr/bin/flatpak --user remotes
Name Optionen
fedora oci
flathub
$ /usr/bin/flatpak --user search testtest
F: Failed to parse
/srv/home/appuser/.local/share/flatpak/appstream/flathub/x86_64/active/appstream.xml.gz
file: Fehler in Zeile 86745, Zeichen 136: <li> already set 'Protection
against a common misconfiguration that tends to break apps, the ' and
tried to replace with ' development variable'
Is EL9's flatpak compatible with flathub appstream data?
$ rpm -q flatpak appstream
flatpak-1.12.8-1.el9.x86_64
appstream-0.16.1-1.el9.x86_64
Found this: https://github.com/flatpak/flatpak/issues/5434
Workaround (vanishes on next update):
$ sed 's/<em>//' -i active/appstream.xml
$ sed 's/<\/em>//' -i active/appstream.xml
$ sed 's/<\/code>//' -i active/appstream.xml
$ sed 's/<code>//' -i active/appstream.xml
$ gzip -9 -c active/appstream.xml > active/appstream.xml.gz
$ /usr/bin/flatpak --user search testtest
No matches found
--
Leon
Today evening (Sunday), I got zabbix notification that some services
hosted on same hypervisor were down.
A quick investigation showed me that despite running on a hardware raid
controller, said server firware confirm data loss and corruption.
As I'm myself normally on PTO, I still wanted to restore services to
quickly working on trying to redeploy from scratch services, and restore
data from last backup and hope to have news soon ...
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]