[CentOS-devel] [EXT] Re: Re: Furthering the evolution of CentOS Stream

Fri Jun 23 19:18:24 UTC 2023
Peter Georg <peter.georg at physik.uni-regensburg.de>

On 23/06/2023 16.39, Brian (bex) Exelbierd wrote:
> Hi,
> 
> I am bex, Brian Exelbierd, the Red Hat liaison that Josh mentioned in 
> another email.
> 
> On Fri, Jun 23, 2023 at 4:07 PM Phil Perry <pperry at elrepo.org 
> <mailto:pperry at elrepo.org>> wrote:
> 
>     On 23/06/2023 13:00, Josh Boyer wrote:
>      > On Fri, Jun 23, 2023 at 7:47 AM Peter Georg
>      > <peter.georg at physik.uni-regensburg.de
>     <mailto:peter.georg at physik.uni-regensburg.de>> wrote:
>      >>
>      >> On 22/06/2023 12.56, Josh Boyer wrote:
>      >>> On Thu, Jun 22, 2023 at 6:51 AM Leon Fauster via CentOS-devel
>      >>> <centos-devel at centos.org <mailto:centos-devel at centos.org>> wrote:
>      >>>>
>      >>>> Hi All,
>      >>>>
>      >>>> I wonder if someone is in the role/position to shed some more
>     light on
>      >>>> the topic as announced here
>      >>>>
>     https://www.redhat.com/en/blog/furthering-evolution-centos-stream
>     <https://www.redhat.com/en/blog/furthering-evolution-centos-stream>
>      >>>>
>      >>>> Any deadlines? Does this target only EL10 or also any current
>     release?
>      >>>
>      >>> It is in effect now for RHEL 8 and 9 and will continue for any
>     future
>      >>> RHEL releases.  The development and source code for all of these
>      >>> releases will continue to happen through the CentOS Stream project.
>      >>>
>      >>> RHEL 7 and CentOS Linux 7 are not affected.
>      >>>
>      >>>> Would be great if some discussion/communication could be
>     happen. Thanks!
>      >>>
>      >>> If you have more questions, please ask and we can try to
>     address them.
>      >>
>      >> I do indeed have a question. The Kmods SIG currently provides
>     artifacts
>      >> for both CentOS Stream and RHEL. To achieve that we have established
>      >> some automation using GitLab CI to avoid human interaction as far as
>      >> possible. For that to work we do need access to the following
>     sources
>      >> from RHEL (version numbers are just examples):
>      >>
>      >> kernel-5.14.0-284.18.1.el9_2.src.rpm
>      >>
>      >> or
>      >>
>      >> linux-5.14.0-284.18.1.el9_2.tar.xz (which is included in the
>     src.rpm).
>      >>
>      >> So far we have downloaded the tarball from
>     git.centos.org/sources <http://git.centos.org/sources>
>      >>
>      >> However, my understanding is that new versions of these files
>     will not
>      >> be provided anymore. In fact the example listed here (current RHEL 9
>      >> kernel) is already not provided anymore.
>      >
>      > Your understanding is correct.
>      >
>      >> Is there any way for a CentOS SIG to access these files? Note
>     that it
>      >> needs to be in a way we can automate the access and even
>     detection of
>      >> new versions added. Both has been possible so far.
>      >>
>      >> In a later stage we also need access to
>      >> kernel-devel-5.14.0-284.18.1.el9_2.{aarch64,ppc64le,x86_64}.rpm
>     which we
>      >> have not been able to retrieve from RHEL directly so far, hence
>     we used
>      >> one of the RHEL rebuilds as a source. With the unknown future of
>     these,
>      >> we'd prefer to also have a way to access these directly from RHEL.
>      >>
>      >> Any help in how we can modify our build automation to continue
>     working
>      >> after the announced changes are very much welcome. In case there
>     are non
>      >> we'll very likely have to stop producing artifacts for RHEL (but
>     not for
>      >> CentOS Stream, obviously).
>      >
>      > Red Hat has a program for Open Source projects to access RHEL
>      > directly.  I've copied the Red Hat liaison who should be able to talk
>      > with the kmod SIG about this program and see if it's suitable.
>      >
>      > We also have EPEL setup to build directly against RHEL, so we may be
>      > able to look into the solution it is using.  I'm not familiar enough
>      > with the infra details to know for sure, but I suspect that would
>      > require some rework of various things.
>      >
>      > josh
>      >
> 
>     Hi Peter,
> 
>     Would it not be easier to build on a RHEL-based build system and then
>     just pull in the Stream specific stuff you need to build against (e.g,
>     Stream kernel / kernel-devel packages) that _are_ publicly available
>     and
>     hence scriptable?
> 
>     As Josh suggests, this is what projects such as EPEL and ELRepo do.
>     Stream isn't really fit for purpose for developing for RHEL, at
>     least in
>     the kernel space.
> 
> 
> ^^ This
> 
> Is the kmod SIG building on CentOS Project infrastructure or external 
> infrastructure?  If it is CentOS Project infrastructure then the Infra 
> team will need to help you ensure you have access to the appropriate 
> RHEL builders.  The CentOS Project, as a sponsored project of Red Hat, 
> already has access to RHEL.

Hi bex,

I already mentioned some of the following in another reply, but let me 
also answer your question:

The kmods SIG is building on CentOS Project infrastructure. We use the 
RHEL builders available in CBS. However this only gives us access to 
RHEL for the build itself, but we already need access to the particular 
files mentioned earlier before the build.

Maybe I'll explain a little more in detail what we need these files for.

kernel-devel-$EVR.{aarch64,ppc64le,x86_64}.rpm:
We need these files to extract the Modules.symvers from to compare these 
to the symbols required by a kernel module. This allows us to detect if 
a kernel module needs to be rebuilt for a new kernel release.

kernel source:
We build several kernel modules which are part of the RHEL kernel but 
with some features deliberately disabled. For these kernel modules we 
extract their source code from the kernel source tarball for every new 
release to ensure that we have the exact same version as provided by 
RHEL. We then add some additional patches or change compilation configs 
to enable features disabled in RHEL. This is especially important for 
kernel modules which have dependencies on other kernel modules or other 
kernel modules depend on, e.g., mlx4_core.

Do you think the ROSI program is an option in this case? At the end all 
we need is access to these files, e.g., by being able to download these 
files from cdn.redhat.com.

Thanks!

Peter

> 
> If you're using external infrastructure, the ROSI program is likely the 
> best way to get you RHEL.  If this is your situation can you email 
> rosi-program at redhat.com <mailto:rosi-program at redhat.com> with your 
> information and situation?  Feel free to keep the devel list CC'ed if 
> you wish.  That email address goes to me and another Red Hatter, Jason 
> Brooks, who admins the program.
> 
> Thank you.
> 
> regards,
> 
> bex
> 
> 
>     Phil
> 
>     _______________________________________________
>     CentOS-devel mailing list
>     CentOS-devel at centos.org <mailto:CentOS-devel at centos.org>
>     https://lists.centos.org/mailman/listinfo/centos-devel
>     <https://lists.centos.org/mailman/listinfo/centos-devel>
> 
> 
> 
> -- 
> Don't rush to reply to this email.  Enjoy work/life balance.  I read 
> email once a day and am in the CE(S)T timezone.  If you have an urgent 
> email, ping me, and consider other mediums for urgent messages in the 
> future.
> 
> Brian "bex" Exelbierd (he/him/his)
> Business Strategist for Communities and Developers
> Linux Business & Ecosystem Strategy, Red Hat Enterprise Linux
> @bexelbie | http://www.winglemeyer.org <http://www.winglemeyer.org>
> bexelbie at redhat.com
> <mailto:bexelbie at redhat.com>
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel