►
From YouTube: CentOS Automotive SIG meeting - 2021-10-21
Description
CentOS Automotive SIG meeting - 2021-10-21
E
D
D
A
D
C
A
C
C
D
B
D
B
F
A
Speaking
of
which
let's
go
ahead
and
get
moving
here
because
it
is
getting
late,
so
welcome
to
the
centos
automotive
sig
meeting
for
october.
This
is
the
formal
meeting,
as
everybody
probably
knows.
By
now
we
have
two
meetings
a
month,
there's
a
formal
meeting
and
there's
an
informal
office
hours
as
we
will
see
when
we
go
through
we're
going
to
be
switching
the
times
up
on
these
meetings
a
little
bit
because
we,
I
did
a
poll-
and
I
want
to
thank
everybody
who
responded
to
the
poll.
A
A
A
We
have
talked
about
future
meeting
schedule
and
a
request
for
help
to
develop
contribution
guidelines
as
we
get
further
along
with
developing
the
build
and
test
infrastructure.
That
means
that
we
have
code
and
we
want
to
make
sure
that
everybody,
so
there
will
be
some
people.
I
will
be
roping
in
to
draft
some
contribution
guidelines,
but
if
this
is
a
process,
you'd
like
to
be
involved
and
then
we'll
have
some
open
discussion,
I
apologize.
A
I
may
need
to
leave
a
little
bit
early,
but
ian
will
be
taking
over
and
the
recording
will
continue.
We
should
be
all
set.
So
I
left
the
introductory
slides
in
just
in
case.
Anybody
who
sees
these
slides
or
this
video
later
wants
to
take
a
look
at
them.
I'm
trying
to.
I
can't
really
tell
from
the
the
people
that
there's
19
people
here
it
looks
like
most
of
the
names
look
pretty
familiar.
Does
anybody?
A
Would
anybody
like
me
to
go
through
a
quick
and
a
quick
overview
of
the
stick,
or
are
we
all
pretty
much
in
the
loop
on
everything
or
go
ahead,
and
you
can?
I
guess,
raise
your
hand
if
you'd
like
me
to
do
a
couple
of
minutes
of
introduction
to
the
sig,
or
should
we
just
dive
into
the
technical
update.
A
A
A
D
C
F
So,
based
on
the
discussion
we
had
in
the
last
in
the
last
meeting
and
the
discussion
we
had
on
the
meeting
list,
we
ended
up
picking
gitlab
as
the
place
to
host
our
our
code.
It
is
currently
under
the
red
hat
name
space,
which
means
we
can
only
have
people
from
redoubt
having
commit
access
to
the
code.
Anybody
can
contribute
via
request,
but
only
people
from
that
can
actually
have
commit
access,
but
this
is
actually
temporary.
F
F
It
means
we
have
the
entire
red
automotive
namespace
in
gitlab,
so
if
we
ever
wanted
to
store
the
projects
there,
so
it's
going
to
be
very
easy
to
add
all
the
projects
next
to
this
one
and
then
move
them
along
as
we
want
or
need
to
all
of
them
could
could
of
course
be
migrated
to
the
center's
name
space.
As
soon
as
that
one
is
available.
F
F
F
F
F
You
also
even
have
the
instruction
of
if
you
don't
have
a
raspberry
pi
system,
how
to
get
a
sensor
stream,
raspberry
pi
system
using
the
centos
linux
8
image
and
then
upgrade
it
to
sensor
stream
8.,
and
then
you
can,
which
you
can
then
use
to
to
build,
which
is
you
have?
You
can
see
that
there
is
a
page
that
says
downloading
images.
F
This
is
currently
a
placeholder
we're
working
with
a
team
at
reddit
that
is
looking
at
providing
a
a
ci
kind
of
kind
of
ci
pipeline.
For
for
this
repository,
the
idea
is
that
every
time
we
push,
we
open
a
merge
request
that
is
going
to
trigger
the
pipeline.
That
is
going
to
build
the
image
test
that
it
works
and
let
us
know
how
it
did
in
a
similar
way.
We
will
be.
F
You
will
see
in
the
git
repository
here,
folder
name
package
list
and
that's
the
which
contains
two
two
text:
files,
one
for
center
stream,
eight
user
for
some
stream,
nine
and
basically
the
idea
is
that
every
time
center
stream
changes
they
have
a
service.
That's
going
to
open
a
merge
request
to
this
project
and
by
opening
a
merge
request.
Again
we
trigger
the
pipeline,
which
means
every
time
sensor
stream
changes.
We
have
a
rebuild
of
our
images
and
the
tests
that
they
still
work.
F
So
if
santa
stream
was
to,
for
example,
rebuild
qt,
which
would
then
mean
for
us
that
we
need
to
rebuild
neptune,
we
shouldn't
know
about
this
by
the
in
the
match
request
here.
So
this
is
work
in
progress.
Hopefully
we'll
be
live
soon,
tough
88
there
and
it's
definitely
closed.
You
can
already
see
in
the
we
have
a
few
merch
requests
upon.
You
can
already
see
that
they
are,
the
pipeline
is
being
triggered
and
reporting
is
just
not
peaceful.
F
Yet
the
idea
is
also
that
we
are
likely
not
going
to
provide
images
per
se.
You
know
there
will.
The
images
will
be
available
via
based
on
what
the
dci
pipeline
builds,
be
able
to
directly
download
the
raspberry
images
and
flash
them
onto
an
sd
card
and
put
them
simply
because
the
the
ci
pipeline
will
build
these
images
as
well.
F
Yeah,
the
we
we
want
to
migrate
our
projects
to
the
center's
namespace
on
gitlab.
The
issue
is
that
the
center's
namespace
currently
does
not
use
the
center's
authentication
system,
which
means
you
know
you
could
be
bruce
on
gitlab
and
not
bruce
on
santos
and
that
is
received
by
the
centers
project
as
something
that
they
want
to
solve
that
break.
F
It's
been
discussed
with
gitlab.
It
is
just
it
wasn't
there
yet
for
us
to
to
benefit
from,
but
the
idea
is
that,
as
soon
as
we
move
to
as
soon
as
it
is
available,
then
we
can
migrate
to
the
center's
name
space
and
at
that
point
anyone
with
a
census
account
can
be
added
to
the
to
the
right
groups
and
get
project.
C
To
reiterate
this
is
us
sort
of
stepping
in
is
from
a
red
hat
perspective,
is
one
of
the
early
participants
in
the
sig
and
demonstrating
something
for
it
and
you've
put
it.
I
guess
you
have.
We
grab
the
automotive
sig
project
name
underneath
that,
but
this
by
no
means
limits
the
scope
of
other
things
that
people
might
do
or
contribute
to.
This
is
our
initial
involvement,
which
I'm
grateful
for
this
looks
great.
I'm
excited
really
excited
that
this
is
is
up
and
visible.
So
thank
you.
A
E
A
F
A
G
F
F
F
A
So
I
think
pierre
was
saying
that
the
the
fact
that
git
lab
has
infrastructure
to
do
these
builds
and
that
it
reacts
on
merge
requests
means
that
the
builds
can
be
done
through
gitlab
and
that
isn't
obviously
ideal.
It'd
be
ideal
to
be
able
to
do
a
local
build,
but
there
is
still
a
possibility
for
building
and
then
doing
a
local
test.
C
Normally
that
are
designed
to
interact
with
that
additional
kernel
content
or
that
replacement
kernel.
And
when
I
say
it's
not
unheard
of
in
the
centos
6
base,
the
one
that
I'm
aware
of
anyway
is
the
zen
zig,
where
they
actually
produce
an
alternative
kernel,
albeit
one
that
is
more
closely
related
to
the
mainline
centos
kernel.
G
At
least
on
all
sides:
yes,
clearly,
that's
you're
addressing
the
right
issue,
which
is
how
we
can
address
the
the
diversity
of
bots,
because
even
if
we
support
10
or
20
boards
as
a
reference
board,
it's
not
going
to
be
enough.
We
will
always
have
other
boards
going
on
project,
so
we
need
to
have
a
mechanism
to
create
that
abstraction.
C
I
think
I
think
that's
worth
doing.
I
know
I've.
I've
done
this
on
an
ad
hoc
basis
in
the
past.
It
would
be
nice
to
have
a
more
standardized
way
of
doing
it,
and
I
would
say
the
goal
then
would
be:
would
it
be
possible
for
someone
to
do
what
we
did?
You
know
we?
I
think
we
actually
proved
this
out
alex
earlier
on.
C
Probably
it
has
been
described
as
a
yakuto
recipe
rather
than
as
a
spec
file,
but
we'd
like
it
to
be
possible
to
run
that
harder
hardware
with
the
sample
user
space,
for
example,
that
pierre
just
presented
earlier
so
having
a
acknowledging
that
that's
a
useful
thing
to
do
coming
up
with
some
technic
techniques
to
do
it
and
encouraging
by
providing
even
some
infrastructure
for
it
in
the
sig.
Maybe
that's
worth
doing.
Maybe
that's
worth.
I.
I
Mean
so
one
of
the
main
problems
with
with
bsp
is
that
they're
talked
about
at
as
if
they
were
a
very
specific
thing,
but
they
can
actually
do
whatever
like
the.
They
can
step
deep
into
the
tentacles
of
building
geopsy
and
tweak
some
things,
and
it
might
be
interesting
to
get
a
list
of
all
the
existing
espn's
and
see
what
kind
of
things
are
generally
done
by
people
who
are
like
knowledgeable
in
dsp
layers.
H
D
H
I
think
you
can
get
to
be
honest.
It's
a
it's!
A
jungle.
You
can
get
anything
from
a
let's
say,
clean
bsp,
with
a
kernel
trying
to
follow
the
upstream
and
something
crappy
very
old,
with
strange
drivers
and
firmware.
So
I
don't
expect
anything
to
be
normalized
on
on
here.
I
would
add
a
small
comment
regarding
what
you
call
bsp.
H
Keep
in
mind
that
it's
not
only
the
kernel,
of
course
the
kernel
is
essential,
but
you
have
usually
a
lot
of
patches
on
top
of
it,
you
may
have
a
very
specific
channel,
which
is
not
vanilla
at
all.
Okay,
so
even
if
vendors
try,
I
mean
sock
vendors
try
to
to
push
their
patches
to
kernel.org,
usually
they
still
have
to
to
have
their
own
patches
for
their
their
soc.
I
D
D
E
G
I
think
everyone
agrees
that,
on
the
very
long
run,
your
vision
is
right.
The
question
is
how
we
move
to
that
long-term
vision
and,
as
stefan
said
you
know
here,
we
we
have
boards
that,
where
we
have
500
patch
to
apply
before
even
you
know
being
able
to
recomprise
the
kernel.
This
being
said,
the
world
the
two-day
world
on
bsp
is
far
from
being
perfect,
so
we
don't
have
to
reach
perfection,
but
we
should
have
a
solution.
G
Okay,
and
if
we
don't
have
a
solution,
then
people
clearly
cannot
adopt
a
system,
and
the
first
issue
is
effectively
how
we
separate
the
low-level
stack.
Okay,
because
that's
a
kernel
plus
how
you
boot,
plus,
you
know
a
few
other
things
from
the
userline
world,
where
we
want
to
use
a
standard
packages
and-
and
I
think
you
know-
we
need
to
have
a
story
and
we
need
to
have
a
roadmap
for
people
to
move
from
one
model
to
the
other
one
there
effectively.
G
As
it
was
said,
there
is
no
real
model,
okay
in
in
in-house
here.
What
we
do
typically,
is
we
take
a
bsp
and
we
start
doing
a
huge
cleanup.
That's
the
first
work.
Okay,
as
you
said,
the
bsp
typically
is
far
too
big,
because
the
first
thing
you
want
is
to
minimize
it.
This
being
said
when
it
is
minimized-
and
we
should
have
a-
I
don't
say-
100
automatic
model
to
move
to
to
the
standard
build
system,
but
something
that
is
relatively
automatic
and
standard
which
we
don't
have
today.
D
It's
just
how
you
do
a
knit
and
and
come
up
from
there,
so
I
could
see
as
having
a
couple
of
variants
based
on
what
people
need,
but
it
seems
like
we
could
start
with
two
or
three
basic
root:
fs's
that
get
you
up
to
the
point
of
starting
services
and
then
let
people
tailor
those
as
they
go
forward
to
say:
okay.
Well,
I
need
pin
control
drivers
and
I
need
this.
This
particular
interface
card,
these
wireless
chips,
this
bluetooth,
cause
all
that
to
get
get
loaded
and
set
up.
D
I
just
I
I
came
from
the
embedded
world
about
15
years
ago
and
it
was
just
a
complete
pain
to
generate
root
of
s's
and
and
we
were
always
doing
it
from
source
it.
It
seems
like
if
you
can
find
an
entity,
you
can
trust
like
the
centos
automotive
sig
and
can
pull
packages
from
there
that
at
least
removes
part
of
the
burden
pain
of
setting
up
a
bedded
system
that
we're
talking
about
here.
So
you
know,
if
we
can,
I
know
there
are
some
efforts
in
place
for.
D
C
I
want
to
ask
a
question
because
my
impression
having
and
you
know
I'll
admit,
alex
and
I
both
dipped
our
toe.
I
dipped
my
toe
and
alex
stayed
in
the
octo
and
agl
space
for
quite
a
long
time,
but
my
impression
is
that
it's
not
a
bsp
very
often
still
makes
use
of
most
of
the
user
space
that
comes
with
either
yocto
or
agl,
and
that,
in
fact,
what
the
the
strength
of
yakdo
in
bitbake
is
that
it's
a
mod.
C
So
beyond
the
other
problem,
with
applying
that
approach
to
fedora
or
centos,
which
is
that
we
have
kernel
and
we
want
it
to
be
derived
from
upstream
the
other
challenge,
the
other.
You
know
an
additional
challenge
with
the
bsp
is
even
if
you
did
have
it
upstreamed
or
even
if
we
did
work
out
a
way
to
bring
in
alternative
kernels
and
additional
user
space
components
that
there's
usually
a
little
bit
more
often
in
the
image
building,
which
is
a
comp
which,
for
us,
is
a
completely
different
set
of
tooling.
C
H
I
mean
currently
what
we,
what
we
see
that
anaconda
is,
is
not
the
right
tool
from
our
experience
to
to
build
the
target
images.
In
fact,
you
can
build
your
images,
but
you
have
to
to
run
your
qmu
to
emulate
the
whole
thing,
because
some
some
post-install
steps
need
require
some
some
demons
running
typically,
and
so
you
can
only
emulate
that
it's
so
it's
very
difficult
to
create.
Let's
say
that
anaconda
is
a
tool
where
you
can
create
a
live
image:
okay
or
an
installation
image
for
your
distribution.
H
We
can
address
that
that
issue
where
we
are
working
on
some
some
ideas,
but
nothing
perfect
here.
So
if
we
can
design
something
on
the
imaging
side
on
the
centos
automotive
sig,
I
think
it
would
make
sense
and
solve
many
many
many
problems
in
in
the
automotive
world
and
also
in
the
embedded
world.
More
generally,.
C
Yes,
I
didn't,
I
I
didn't
mean
to
suggest
that
yocto
had
had
completely
solved
that
problem
in
the
general
case,
but
it
at
least
it
provides
a
clear
mechanism
if
you
need
a
customized
solution
for
a
particular
hardware
platform,
it's
very
clear
where,
to
put
it
you
just
you,
have
to
take
over
that
stage
of
the
build
sequence.
You
have
to
write
a
recipe
and
bitpick
will
execute
it
for
you,
but
yeah.
Everything
else,
you
said
makes
makes
sense
to
me.
C
I'm
intimately
familiar
with
the
challenge
of
taking
a
os
that
was
primarily
installed
by
an
on
hardware,
installer
and
then
turning
it
into
something
that,
because
we
encounter
the
same
challenge
when
creating
images
for
use
in
a
cloud
environment
where
there
is
no
installation
step,
there's
an
image
and
it
gets
launched,
and
it
doesn't
want
to
do
something
when
it
starts
up.
So.
H
H
A
few
changes,
I'm
not
talking
about
patches,
but
it's
it's
it's
a
bit
like
if
you
had
a
multiple
fragments
to
compose
the
spec
file,
basically
coming
from
various
locations,
they're
just
cool
those
locations
layers,
all
right,
better
yeah,
that's
that's
the
idea
and
then
at
the
end,
so
you
compose
your
recipes
from
multiple
locations
and
and
and
you
try
to
expect
that
everything
is
harmoniously
built.
But
one
limitation
of
that
is
that
at
some
point,
if
you
add
a
new
layer
that
baby
happens
something
wrong,
then
everything
gets
wrong.
H
C
C
That
is
a
little
less
doctrine
than
the
current
answer,
which
is
as
soon
as
your
platform
runs
on
the
upstream
kernel
and
can
be
imaged
using
our
standard
image
tools.
It
will
be
supported
and
until
then
you're,
essentially
on
your
own,
which
is
very
different
from
the
experience
of
trying
to
integrate
with
yakuto
or
agl,
and
it's
not
going
to
be.
C
C
You
know,
add
your
add
these
patches
to
the
rpm
for
the
kernel
or,
if
necessary,
create
your
own
kernel
rpm,
but
make
sure
that
it
provides
the
same.
You
know
satisfies
the
same
dependencies
as
the
one
in
there
add
your
user
space
components
as
packages
and
then
augment
or
plug
into
the
image
building
tooling.
In
this
way,
does
that
sound
like
it's?
Essentially,
what
is
the
centos
equivalent
of
developing
a
bsp,
and
how
can
we
make
that
a
little
friendlier
than
it
is
right
now?
G
G
So
container
is
another
part
where
they
also
have
some
significant
issue.
Good
time
is
also
something
we
could
talk
about,
but
if,
if
we
address
you
know
also
those
issues,
okay,
then
it
provides
another
added
value
for
people
to
change
and,
for
example,
in
in
the
new
cyber
security
spec,
it
is
enforced
that
you
can
trace
any
assets
that
you
include
in
the
system,
with
the
notation
of
its
cybersecurity
risk
its
dependency
and
what
is
going
to
happen
if
this
asset
is
compromised?
G
A
A
A
C
A
C
E
C
C
E
A
D
D
E
D
D
It
may
be
possible,
I'm
not
ruling
it
out
and
if
we
could
get
you
know
a
half
dozen
or
so
high-end
devel
platforms
and
could
figure
out
a
place
to
put
them
in
a
lab
so
that
they
could
be
remotely
accessible.
That
would
be
fantastic,
but
I
I
wonder
at
the
fees
I
mean
like
I'm
seeing
things
like
I
just
bought
this,
which
is
an
asus
platform
called
the
the
tinker
r
and
it's
a
it's.
It's
a
big
little.
You
know
arm.
C
I
I
D
But
the
fact
is
that
a
raspberry
pi
or
one
of
these
little
single
board
computers
that
that
is
arm
based
the
structure
of
what
has
to
go
on
them
make
them
do
something
is
very
similar
to
what
we
have
to
do
it
just
scales
up
and
and
becomes
a
bit
more,
almost
oriented.
So
you
know
I
mean
I
got
one
of
these
little
high
racer.
That's
got
a
raspberry,
pi
4
on
it
and
don't
ask
me
to
to
make
it
move,
because
I
haven't
even
installed
an
os
on
it.
D
Yet
I
just
got
the
stupid
thing
put
together,
but
the
the
structure
of
what
we're
talking
about
here
is
instead
of
firmware
kernel
that
enables
the
underlying
devices
and
then
a
user
space
that
makes
use
of
that.
We
could
do
a
hell
of
a
lot
of
prototyping
a
lot
of
frameworking
on
these
little
guys.
That,
hopefully,
would
then
scale
up.
I
I
D
C
D
G
This
being
said,
you
know
there
is
a
big
difference,
whether
we
target
two
guy
in
a
garage
in
which
case
raspberry
pi,
is
effectively
fine
or
whether
we
are
targeting
panasonic
or
denzel
developers
when
they
do
a
proof
of
concept.
Okay,
and
if
we
want
to
be
in
a
car
one
day,
we
should
target
the
denzel
and
panasonic.
You
know
advanced
research
and
so
on
and
for
those
people,
if
we
want
them
to
feel
close
enough
of
what
they
do.
I
think
there
are
a
few
things
we
should
support.
G
We
should
support
clearly
one
renaissance
board:
okay,
because
typically
they
have
a
pronunciation
three
on
their
desk.
We
should
support
one
nxp8.
We
don't
have
to
support
all
of
them,
but
we
should
take
one
of
them.
We
should
support
one
nvidia
and
one
qualcomm,
because
at
least,
if
you
do
that,
you
somehow
cover
more
or
less.
You
know
what
those
people
understand.
You
speak
the
same
language
and
I
agree.
G
D
Part
of
it
is
actually
getting
access
to
that
hardware,
and
if
we,
if
we
have
contacts
with
the
some
of
the
manufacturers
of
these
develop
awards,
do
we
think
we
could
work
some
sort
of
deal
where
we
get
remote
access
to
them.
You
know:
do
they?
Would
they
open
up?
They
punch
a
hole
in
the
firewall
and
say:
look:
here's
here's
a
an
ssh
port
to
one
or
two
boxes
that
are
dedicated
to
use
by
centos,
sig
centos.
D
G
A
D
The
problem
is
that
we
have
a
scarce
resource,
it's
expensive,
hard
to
get
a
hold
of
long
lead
times,
so
if
we
can
figure
out
a
way
to
pull
them
into
a
shared
environment
and
make
it
so
it's
usable
for
people
to
say
log
into
some
infrastructure
and
say
build
me
a
environ,
you
know
use
this
recipe
to
build
me.
A
root
file
system
and
a
kernel
that
boots
on
this
particular
platform
and
install
it.
I
D
It
depends
on
how
it's
organized,
but
in
many
cases
you
can
actually
do
the
flashing
from
linux.
Then,
of
course
you
have
to
reboot
and
hope
that
your
firmware
has
the
right.
You
know
the
ability
to
say
oh
what
we
just
flashed
sucks:
let's,
let's
go
from
that
b,
partition
back
to
the
a
partition
and
reboot
from
the
air
and
recover.
C
I
have
to
drop
soon
as
well,
but
I
think
actioning
remote,
board
access
and
and
sort
of
nominating
some
boards.
The
things
that
we
would
like
to
try
and
adapt
the
bsp
from
is
is
worth
considering.
I
think
we
we
might
even
be
able
to
put
some
effort
into
that.
Just
in
the
name
of
fleshing
out
these
problems.
The
board
farm
problem
is,
it
would
benefit
many
people
to
solve.
So
right
seems,
like
you
know,
yeah,
just
like
the
bsp.
We
wouldn't
expect
it
to
be
a
stay.
C
C
A
Winner,
I'm
gonna
maybe
propose
that
we
start
doing
multiple
meetings
going
forward,
but
I
will
go
ahead
and
write.
It
write
this
up
for
the
mailing
list
and
address
it,
so
we
don't
have
to
go
over
here.
Okay,
so
anyway,
I
will
leave
the
the
call
on
and
I'm
gonna
run
off,
and
I
appreciate
everybody's
participation.
I
think
it's
been
a
really
interesting
meeting.
It's
exactly
the
kinds
of
discussions
we
want
to
have.