- automotive-sig - lists.centos.org

Repository request for acrn-hypervisor
by Erico Nunes 27 May '25

27 May '25

I would like to request a new repository to transfer https://gitlab.com/ernunes/acrn-hypervisor-spec to the automotive-sig. It is a .spec file repository for the ACRN hypervisor which can be used with AutoSD. Please note that the package cannot be built as-is, due to how that project works it requires a platform-specific configuration to be added by the user before building the actual RPMs. So I think the appropriate path for now would be src/acrn-hypervisor. This will be referenced in the automotive-sig docs as a followup.

2 1

Re: Copr builds to allow AutoSD and Automotive SIG packages installation on Fedora
by Martin Perina 27 May '25

27 May '25

On Tue, May 27, 2025 at 11:28 AM Pierre-Yves Chibon <pingou(a)redhat.com> wrote: > On Tue, May 27, 2025 at 10:29:39AM +0200, Martin Perina via automotive-sig > wrote: > > On Mon, May 26, 2025 at 3:08 PM Mark Kemel via automotive-sig > > <[1]automotive-sig(a)lists.centos.org> wrote: > > > > Hello all, > > Currently we have two packages, for which we have dedicated COPR > repos > > for release versions: > > [2] > https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/automotive-… > > and > > [3] > https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/osbuild-aut… > . > > These are automatically built with Packit, triggered by GitLab > releases, > > allowing users to run a-i-b on Fedora. > > Following the Slack discussion on auto-boot-check COPR builds, I > want to > > address this here. For packages like auto-boot-check, which are > built > > solely for the AutoSD/Automotive SIG and not intended for Fedora > release > > but should be installable from COPR, we need to decide on the > repository > > structure. Should we create a separate COPR repo for each package > under > > the '@centos-automotive-sig' project, similar to a-i-b and > osbuild-auto, > > or should we group these packages into repos by usage? For instance, > > should auto-boot-check release builds be done within the > > automotive-image-builder repo? > > I'd think it depends how tied together the packages are and if they are > released > together or at different rhythms. > I can see pros and cons to both approaches > > > I think it would be beneficial to have an official repository for > Fedora, > > which will contain releases of the same packages as we have in AutoSD. > > So you're thinking 1 COPR repo for fedora builds of all the AutoSD > packages? > Yeah, that seems to me much easier than having a separate copr repo per package > > Pierre > > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Copr builds to allow AutoSD and Automotive SIG packages installation on Fedora
by Mark Kemel 27 May '25

27 May '25

Hello all, Currently we have two packages, for which we have dedicated COPR repos for release versions: https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/automotive-… <https://www.google.com/url?q=https://copr.fedorainfracloud.org/coprs/g/cent…> and https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/osbuild-aut… <https://www.google.com/url?q=https://copr.fedorainfracloud.org/coprs/g/cent…>. These are automatically built with Packit, triggered by GitLab releases, allowing users to run a-i-b on Fedora. Following the Slack discussion on auto-boot-check COPR builds, I want to address this here. For packages like auto-boot-check, which are built solely for the AutoSD/Automotive SIG and not intended for Fedora release but should be installable from COPR, we need to decide on the repository structure. Should we create a separate COPR repo for each package under the '@centos-automotive-sig' project, similar to a-i-b and osbuild-auto, or should we group these packages into repos by usage? For instance, should auto-boot-check release builds be done within the automotive-image-builder repo? Looking forward to your thoughts on this. Best regards, Mark -- Mark Kemel Senior Software Engineer, RHIVOS Red Hat <https://www.redhat.com> mkemel(a)redhat.com <https://www.redhat.com>

2 1

[NOTICE] autosd.sig.centos.org planned maintenance and upgrades May 13th 2025
by Hubert Stefański 13 May '25

13 May '25

Dear Users, Please be advised that the *autosd.sig.centos.org <http://autosd.sig.centos.org>* web server will undergo maintenance tomorrow *May 13th * starting at *10:00 CEST.*We expect the downtime to last approximately one hour. *Other Popular Timezones:Pacific Daylight Time (PDT):* 01:00 AM *Eastern Daylight Time (EDT):* 04:00 AM *British Summer Time (BST):* 09:00 AM *India Standard Time (IST):* 1:30 PM *China Standard Time (CST):* 4:00 PM *Japan Standard Time (JST):* 5:00 PM *Australian Eastern Standard Time (AEST):* 6:00 PM We'll attempt to upgrade the instance and switch over to AWS CloudFront ahead of Red Hat Summit, The previous upgrade was rolled back as users started reporting issues, however based on our testing earlier today we believe most of these have been resolved. Please report any issues by replying to this thread, or to emailing me directly (hstefans(a)redhat.com) Thanks! Hubert stefański Senior Software Engineer Red Hat In-Vehicle OS Red Hat <https://www.redhat.com/> Remote Poland [image: Red Hat In-Vehicle Operating System logo]

1 3

Request new git repo
by Alexander Larsson 07 May '25

07 May '25

I would like a new repo rpms/gnu-efi-ukiboot. We need this to build a newer gnu-efi for ukiboot, because the one in cs9 doesn't work on aarch64. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl(a)redhat.com alexander.larsson(a)gmail.com

2 1

[NOTICE] Upcoming AutoSD Webserver Downtime
by Hubert Stefański 07 May '25

07 May '25

Hi folks Hubert from the Automotive Toolchain team here, we're the folks that produce and manage the artifacts (and the associated infrastructure) that you can find on the autosd.sig.centos.org web server. We'll be performing a bit of maintenance and an upgrade to that deployment tomorrow *6th May 2025 @ 1300 CEST *see below for a handy reference for your local timezone *[1].* *What's going to change?* We'll no longer be serving the artifacts from local storage attached to the web server instance, instead we'll be using AWS CloudFront. So, instead of downloading the files directly from the web server, you'll be redirected to the relevant file in CloudFront. The aim of this change is to improve download speeds and resiliency at scale for our users. If you're simply browsing the UI through autosd.sig.centos.org you won't really notice anything out of the ordinary, we've kept the index structure as-is, what you will notice is that once you click a file download through the UI, you'll be redirected to https://download.autosd.sig.centos.org/ (with the relevant file key) so don't be surprised, or alarmed by that. However, if you're using recursive wget, or anything of that sort to fetch artifacts from autosd.sig.centos.org, you'll need to be aware that normal page crawling might not be possible, so if you intend to download a whole directory, please use the following: ``` wget autosd.stg.sig.centos.org/AutoSD-9/nightly/download.txt wget -i download.txt ``` The command above will work for all directories, and subdirectories, the download.txt file simply gathers all the file reference keys from the s3 and puts them into a single file. Likewise, if you want to download a file from that web server, all you need to do is replace `autosd.sig.centos.org/<filepath>` with ` https://download.autosd.sig.centos.org/<filepath>` This is still an early experimental version, so If you have any questions, concerns, issues, bugs or feedback, feel free to reach out*, *and we'll do our best to address it ASAP. Thank you! *[1]* Timezone Local Time *UTC (GMT)* 11:00 AM *New York (EDT)* 7:00 AM *Los Angeles (PDT)* 4:00 AM *London (BST)* 12:00 PM (Noon) *Tokyo (JST)* 8:00 PM *Sydney (AEST)* 9:00 PM *India (IST)* 4:30 PM *Dubai (GST)* 3:00 PM *Beijing (CST)* 7:00 PM Hubert stefański Senior Software Engineer Red Hat In-Vehicle OS Red Hat <https://www.redhat.com/> Remote Poland [image: Red Hat In-Vehicle Operating System logo]

1 3

aboot-deploy and aboot-update development repository request
by Ian Mullins 01 May '25

01 May '25

Hello, Can you please create two new repositories in the src namespace as seen below: - https://gitlab.com/CentOS/automotive/src/aboot-update - https://gitlab.com/CentOS/automotive/src/aboot-deploy Both the aboot-deploy and aboot-update projects currently reside in https://gitlab.com/CentOS/automotive/rpms/ , which serves both as development and dist-git repo. The new repositories are required to migrate the development of both projects, leaving the original project repositories as dist-git only. Thank you, Ian

1 0

osbuild-auto development repository request
by Mark Kemel 01 Apr '25

01 Apr '25

Hello, The osbuild-auto project currently resides in https://gitlab.com/CentOS/automotive/rpms/osbuild-auto, which serves both as development and dist-git repo. Requesting a new repository at https://gitlab.com/CentOS/automotive/src/ osbuild-auto to migrate the development of the project to, and leave the original repo as dist-git only. Thank you in advance Mark

2 1

Repository Request
by Leonardo Rossetti 01 Apr '25

01 Apr '25

Hello, I would like to request a new repository creation: https://gitlab.com/CentOS/automotive/autosd-image-score This repository will host AIB files to build an AutoSD image for the Eclipse S-CORE project. Regards, -- Leonardo Rossetti Principal Software Engineer, Red Hat <https://www.redhat.com> lrossett(a)redhat.com <https://www.redhat.com>

2 1

Request for rust-vhost-device-gpu and its deps dist-git repos
by Sandro Bonazzola 25 Mar '25

25 Mar '25

Please create rpm dist-git repos for the following packages: - rust-vhost-device-gpu - gfxstream - aemu Thanks, -- Sandro Bonazzola MANAGER, ENGINEERING Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 3

2025

2024

2023

2022

2021

automotive-sig