======================================================
#centos-meeting: CentOS Cloud SIG meeting (2024-04-11)
======================================================
Meeting started by jcapitao at 15:01:03 UTC. The full logs are available
athttps://www.centos.org/minutes/2024/April/centos-meeting.2024-04-11-15.01…
.
Meeting summary
---------------
* roll call (jcapitao, 15:01:29)
* RDO/OpenStack Update (jcapitao, 15:08:43)
* RDO is about to release RDO Caracal/2024.1 in a week or so
(jcapitao, 15:09:36)
* CentOS Stream 8 repos for RDO Releases up to Yoga will be removed
and archived in vault.centos.org (jcapitao, 15:44:30)
* LINK:
https://lists.rdoproject.org/archives/list/dev@lists.rdoproject.org/thread/…
(jcapitao, 15:44:51)
Meeting ended at 15:52:26 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jcapitao (28)
* amoralej (15)
* spotz (10)
* centguard (5)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Hi Everyone,
Our next board meeting will take place at 20:00 UTC tomorrow
`date -d "2024-04-10 20:00 UTC"`
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/r1hmwXxe0
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.
thanks,
--
Thomas 'alphacc' Oulevey
CentOS Board of Directors Secretary
alphacc(a)centosproject.org
Due to a needed upgrade , we'll have to move the existing CentOS
mailman instance (aka https://lists.centos.org) to a new server/host.
Migration is scheduled for """"Tuesday April 8th, 7:00 am UTC time"""".
You can convert to local time with $(date -d '2024-04-08 07:00 UTC')
The expected "downtime" is estimated to ~60 minutes , time needed to :
- take last mailman2 backup
- reimport / convert mailman2 archives to mailman3 DB
- DNS propagation for A/AAAA/MX records
Here are also some important information about the mailman2 => mailman3
migration :
# Renamed lists
Worth knowing that, based on open discussion on the centos-devel list
(see whole thread at
https://lists.centos.org/pipermail/centos-devel/2024-March/165576.html),
existing lists will be *renamed* , so while we'll put aliases for
incoming mails, each list member will start receiving list mails from
new list name. So start updating your filters if you filter on email
address instead of "subject:"
Here is the overview of the new lists names :
arm-dev at centos.org => arm-dev at lists.centos.org
centos at centos.org => discuss at lists.centos.org
centos-devel at centos.org => devel at lists.centos.org
centos-announce at centos.org => announce at lists.centos.org
centos-automotive-sig at centos.org => automotive-sig at lists.centos.org
centos-{cz,de,es,fr,nl,pt-br,zh}(a)centos.org =>
discuss-{cz,de,es,fr,nl,pt-br,zh}(a)lists.centos.org
ci-users at centos.org => ci-users at lists.centos.org
centos-gsoc: => gsoc at lists.centos.org
centos-mirror at centos.org => mirror at lists.centos.org
centos-mirror-announce at centos.org => mirror-announce at lists.centos.org
centos-newsletter at centos.org => newsletter at lists.centos.org
centos-promo at centos.org => promo at lists.centos.org
centos-virt at centos.org => virt at lists.centos.org
# Authentication
Mailman2 had no real concept of authentication so you could just
subscribe to one or more lists, and have a password associated with your
email address for that/these subscription(s).
Mailman3 itself is split into "core" and "webui" components, so when
we'll import mailman2 lists/config into mailman3, your existing
subscriptions will continue to work *but* not your password.
Mailman3 will be configured to support SSO, and so if you already have a
FAS/ACO account (https://accounts.centos.org) you'll be able to login
directly into new webui and manage your settings/subscriptions *if* your
ACO email address of course matches the one you initially subscribed
with for lists.centos.org.
If that's not the case, either create an ACO/FAS account that will match
and you'll be then able to "link" your mailman3 account with FAS and so
manage your settings/subscriptions.
If you don't want to, there is always the documented process :
https://docs.mailman3.org/en/latest/userguide.html#making-a-mailman-account
Thanks for your understanding and patience.
on behalf of the Infra team,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
Just to announce that last week, I replaced (one by one so no downtime
from a rpm builds perspective) the older aarch64 builders we had for
cbs.centos.org pool , with newer ones/faster ones.
In the past, we had a mix of ThunderX/ThunderX2 machines, and these were
replaced by newer Ampere Altra machines (Thanks to Ampere for having
sponsored one machine and Red Hat sponsored the other ones !)
As it was replaced last week, I had a look at some SIGs builds involving
aarch64 architectures and compared needed time builds between older
platform and newer builders
#kernel / kmod SIG
before: https://cbs.centos.org/koji/taskinfo?taskID=3900620 => 30min
now: https://cbs.centos.org/koji/taskinfo?taskID=3901748 => 17min
#samba / storage SIG
before: https://cbs.centos.org/koji/taskinfo?taskID=3836506 => 59min
now: https://cbs.centos.org/koji/taskinfo?taskID=3900306 => 13min
#kernel-automotive / automotive SIG
before: https://cbs.centos.org/koji/taskinfo?taskID=3894668 => 41min
now: https://cbs.centos.org/koji/taskinfo?taskID=3901722 => 13min
Of course, don't take these metrics as "granted" for your future builds
(as it depends on number of other concurrently builds, etc) but at least
it should be faster than before (including also for the Image tasks)
I hope that all SIGs building also for aarch64 will enjoy the new
aarch64 builders !
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
The CentOS Alternative Images SIG[1] has updated their CentOS Stream 9 Live
images this quarter. We also added 4 new Live desktop images.[2] We now
have
* CINNAMON
* GNOME
* KDE
* MATE
* XFCE
* MAX
MAX has all the desktops listed above, plus a few others like IceWM and
Lumina.
All of these live images can be installed on your system.
If there are bugs that are specific to the live images (not just general
CentOS Stream bugs) please file an issue in our spins bug tracker.[3]
Troy
[1] - https://sigs.centos.org/altimages/
[2] - https://mirror.stream.centos.org/SIGs/9-stream/altimages/images/live/
[3] - https://pagure.io/centos-sig-alt-images/spin-bugs/issues
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