Hi all,
I've uploaded the recordings of last week's board meeting:
https://youtu.be/FA0ddn-IWes
If you'd like to discuss any issues with the board, we'll have an open
board office hours this Thursday, October 20, at 14:00 UTC:
https://us06web.zoom.us/j/87623425120
Thanks,
Shaun
When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.
At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it
October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes. They will be in the Fedora archives,
and the mirror managers will point at them.
Question: What will you be dressed as on Halloween?
Answer (Troy): A Penguin
EPEL Steering Committee
[1] - https://pagure.io/epel/issue/198
Gratitude for this e-mail, i'm a software developer, with works C, C++,Lua,
Python
and i hope so much to contribute community
i'm Ramon, and i looking for some experience with linux and software
development
cordially thanks
(I've sent this before, but it seems to have never reached the mailing
list, so re-sending again; although less interesting today, when RHEL 8.7
and 9.1 Beta are already out, yet I believe the thoughts about Stream
concept are worth looking at).
As you likely know, CentOS Stream is a new concept that allows the
community to see what future RHEL brings. Let me touch on a few specific
things that you can test in CentOS Stream 8 and 9 for some time already,
and couldn't see in a released RHEL until recently.
Module streams concept is used in CentOS Stream 8 and 9 (and thus also in
the future RHEL-8.x and RHEL-9.x versions) for delivering alternative
versions of popular stacks for developers (except other components). You
can for example try the latest Node.js version 18, Ruby 3.1, or Maven 3.8.
How? Let's see an example with a CentOS Stream 9 container image:
First, pull the CentOS Stream 9 image using podman and run it:
#> podman pull centos:stream9
#> podman run -ti --rm centos:stream9
Then, use dnf to list available modules
[root@ad0a3f9d2aa3 /]# dnf module list
Here you see a couple of modular streams that are not enabled by default
but are available in the repository in parallel to the default version
(which is 3.0 in the case of Ruby and CentOS Stream 9).
Now, the most important part, enable the latest available version of Ruby
and install some packages:
[root@ad0a3f9d2aa3 /]# dnf -y module enable ruby:3.1
[root@ad0a3f9d2aa3 /]# dnf -y install ruby
And finally, check what version we actually have:
[root@ad0a3f9d2aa3 /]# ruby --version
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
And you can follow a similar pattern for other module streams, that are on
their way to the next RHEL minor release. This way, CentOS Stream and RHEL
users can test the new content earlier than before and provide feedback in
the BZ [2].
[1] https://www.centos.org/centos-stream/
[2]
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20…
Enjoy!
Honza
In OpenStack Kolla project we are building OpenStack components as
container images. And some extra images for infrastructure.
One of components we use is RabbitMQ. For each of supported
distributions (CentOS Stream 9, Debian 11, Ubuntu 22.04) we want to use
the same versions:
- rabbitmq-server 3.10.*
- erlang 25.*
We use upstream provided repositories for each distro/arch as there are
no up-to-date versions provided in distribution repositories.
Are there plans for updating RabbitMQ and Erlang in Messaging SIG repo
to 3.10.* and 25.*?
This would allow us to support CentOS Stream 9 on AArch64 (where we now
have no working builds and consider downgrading to whatever is in CS9
for now).
October 2022 Quarterly report submitted by: Jefro Osier-Mixon, Red Hat -
acting chair
_____________________________________
Membership update
This SIG does not have a formal membership process. The mailing list
currently has 99 subscribers representing at least 31 organizations, though
not all subscribers use corporate emails and some are participating as
individuals.
_____________________________________
Releases in the most recent quarter (or most recent release, if none in
that quarter)
The SIG provides a new distribution: Automotive Stream Distribution
(AutoSD), a CentOS Stream derivative designed specifically around the needs
of an automotive OS, and transparently the upstream project for Red Hat's
eventual in-vehicle OS product. AutoSD has been downloaded and used by many
organizations who have commented or asked for help, so we know it is
getting some traction though of course we don't have exact metrics on usage.
_____________________________________
Health report and general activity narrative
The CentOS Automotive SIG celebrated its first year anniversary in August.
The SIG has typically had 1-2 public meetings per month, one formal and one
informal "office hours", each with 25-40 attendees, with visible
participation from 7-10 separate organizations. The office hours portion
has been on hiatus since July as summer vacations brought attendance to a
crawl, but we intend to start them back up in October.
This SIG is intended to be a community effort with contributions and shared
benefits from all participants. All formal meetings are recorded and posted
on this page:
https://wiki.centos.org/SpecialInterestGroup/Automotive/Meetings
Several Red Hat employees made the initial contributions to the project as
well as the infrastructure required to build and test it. We occupy a
gitlab repository in the CentOS namespace building software regularly using
CI, with build instructions provided on the documentation page at https://
sigs.centos.org/automotive/ . Sample images are present and downloadable
along with customization and build instructions.
This is a high-level summary of activity over our first year as outlined on
the CentOS blog
<https://blog.centos.org/2022/08/centos-automotive-sig-first-year-in-review/>
:
We worked to define what the Automotive SIG is producing and we landed on
three artifacts:
- AutoSD, a CentOS-Stream based linux distribution which is the public,
in-development version of the Red Hat In-Vehicle Operating System (similar
to CentOS Stream for RHEL).
- An Automotive SIG RPM repository that allows the community to expand the
content of AutoSD or experiment with some of its parts.
- Sample images, built using OSBuild, which provide examples of how to
assemble production images based on AutoSD, customized for some hardware,
including container images, based on CoreOS/ostree technologies.
All of this resides in a repository on gitlab, in the CentOS namespace with
the infrastructure to enable CI/CD for a basic distribution. We are
building a set of nightly images for different use-cases, and have a robust
set of documentation at the above link.
Not a lot of high-level features have been introduced over the past few
months due to vacation schedules, but the distro is doing very well and now
supports a SOAFEE implementation along with container support based on
podman and systemd. In addition, we are pleased to have had the first
contribution from outside Red Hat (thanks Volvo!).
_____________________________________
Issues for the board to address, if any
None, keep up the excellent work :)
Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com
Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive