►
From YouTube: CentOS Automotive SIG - April 8 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
And,
of
course,
google
is
now
not
not
participating
with
us
today.
So
in
any
case,
this
is
the
april
centos
sig
meeting
glad
everybody
could
make
it
once
again.
I
apologize
for
this
being
a
friday
afternoon
or
evening
in
europe,
and
it
is
that
was
not
intentional,
but
we
had
two
very
exciting
events.
Go
on
so
go
ahead.
Yes,
red
hat
has
joined
agl.
A
I
don't
know
that
we're
going
to
be
at
the
agl
meeting
in
person,
I'm
planning
to
at
least
dial
in
for
it
it's
going
to
be
at
a
terrible
time
for
my
time,
but
that's
a
good
question.
We
should
actually
bring
that
up.
A
I'm
actually
much
personally,
I'm
much
more
interested
in
the
the
agl
all
meeting
member,
all
member
meeting
in
honolulu
this
summer.
So
if
we
can,
you
know
at
least.
C
D
A
I
will
say
that
red
hat
as
an
organization
hasn't
yet
decided
how
deeply
we're
going
to
be
involved
in
the
day-to-day
with
agl.
I
know
I've
been
on
the
mailing
lists
well
for
10
years
now,
almost
10
years,
but
I
don't
know
what
exactly
we're
going
to
be
doing
from
the
point
of
view
of
the
sig
and
from
the
point
of
view
of
our
product,
a
lot
of
those
things
are
kind
of
still
up
in
the
air
ian.
A
E
E
A
F
A
I
have
a
just
a
very
quick
agenda.
I
don't
actually
have
a
whole
lot.
We
have
plenty
of
room
for
talk
this
time.
I
thought
we
would
dive
in
take
a
look
at
the
actions
that
we
had
set
out
in
march,
create
robust
community
guidelines
and
other
documentation,
and
I'm
happy
to
report
that
some
of
that
has
actually
been
done.
A
The
the
centos
stream
contrib
documentation
and
the
actual
centos
documentation
guide
to
contribute
contribution
guide.
The
only
thing
left
for
us
to
do,
I
think,
is
to
add
a
contributing
file
at
the
top,
which
we
will
do
hopefully
over
the
next
week,
and
then
we
can
actually
call
that
goal
met
for
for
the
spring,
and
I
actually
did
update
the
wiki
page,
the
wikipedia.
There
is
now
a
a
meetings,
page
specific
that
has
all
of
the
different
recordings
from
all
of
the
past
centos
automotive
sig
meetings.
A
If
anybody
has
any
questions
or
issues
with
that,
just
let
me
know-
and
I
would
like
to
continue
building
out
the
wiki
page
as
our
kind
of
central
hub
for
information
about
the
sig
from
an
administrative
point
of
view
and
then,
of
course,
there's
documentation
page
which
has
all
of
the
information
from
a
technical
point
of
view
and
then,
of
course,
the
repo
that
has
the
actual
the
actual
bits
so
doing
good.
A
Let's
dive
real
quick
into
a
technical
status
update
we
last
month
we
announced
the
auto
sd
distribution
availability
as
the
sort
of
output
of
the
sig.
I
think
it's
looking
great.
The
documentation
has
been
really
built
out,
as
we
were
just
saying.
I
know
that
laura
has
put
a
lot
of
work
into
it.
I
think
alex
has
put
a
ton
of
work
into
it
and
a
bunch
of
these
pages
came
from
him,
and
so
please
take
a
look.
The
it's
there's
links
in
most
places.
A
I
love
the
pictures
that
pierre
has
added
to.
I
think
that
it's
it's
really
coming
along
very,
very
well.
A
The
ci
pipeline
is
still
a
work
in
progress.
It
is
progressing.
Actually,
I
should
just
have
this
over
to
pierre
or
ian.
If
one
of
you
guys
want
to
take
a
look,
take
a
take
on
it.
G
I
can
step
in.
I
have
been
away
from
keyboard
for
most
of
the
week,
so
if
things
have
changed
recently,
I
may
not
have
the
latest
news,
but
yeah
jeffrey
has
mentioned
it.
We
have
we've
worked
quite
a
bit
on
the
documentation.
Alex
has
put.
G
Build
so
if
you,
if
you're,
not
from
os3,
so
if
you're
not
familiar
with
s3,
the
recommendation
gives
you
a
good
understanding
of
what
it
is,
what
it
is
capable
of,
and
one
of
the
most
recent
edition
is
also
a
documentation
and
examples
on
how
you
can
have
a
system
that
doesn't
put
properly
automatically
reboot
to
the
previous
to
previous,
commit
to
the
previous
state
of
the
system.
G
So,
since
the
the
way
a3
works,
it's
atomic,
it's
either
your
your
v1
or
v2,
but
you're
nowhere
in
between
there,
so
you
can
reboot
to
v2,
and
if
that
doesn't
work
you
reboot
back
to
v1.
That
is
a
great
piece
of
documentation.
I
still
have
myself
to
to
go
through
it
and
test
it
to
see
to
see
it
live,
but
it
is
a
it's
very
nice
to
see
this
here.
G
The
the
ci
pipeline
is
now
in
is
working
it's
progressing.
We
have
a
change
in
the
methodology
that
we
are
using
so
back
until
I
believe
a
couple
of
days
ago
we
had
we
had
a
change
every
time
that
there
was
a
package
changing
center
stream
built
in
center
stream.
We
would
be
updating
a
file
in
the
automative
repo
and
that
would
trigger
the
ci
run.
G
This
has
led
to
a
number
of
problems,
one
of
them
being
like
if
you,
if
you
update
package
a
and
then
package
b
and
package
b,
depend
on
a
you
with
the
mechanism.
We
add,
you
have
two
different
merge
requests,
one
for
one,
one
for
a
one
for
b
and
there
was
no
way
to
link
to
test
b
on
the
top
of
a
without
merging,
first
a
and
then
b
and
then
doing
the
rebase
another
distance.
So
that
has
led
to
a
number
of
merge
requests
that
were
accumulating.
G
That
was
not
ideal.
So
what
we're
doing
now
is
we're
doing,
instead
of
doing
on
a
on
a
build
we're
doing
on
a
daily
basis
during
the
on
the
center's
compose.
So
we
know
that
we
have
a
set
of
packages
that
fastpass
composed
on
the
center
stream
side.
So
we
are
no
longer
updating
one
package,
but
we
don't
think
we're
doing
a
list
of
packages
at
once
and
the
idea
is
to
have
this
automatically
merge
if
they
pass
ci,
because
there
is
no
way
one
of
us
is
going
to
go.
G
G
The
testing
part
is
still
in
progress,
that
is,
that
is
being
worked
on,
as
well
as
the
downloadable
sample
images.
So,
if
you
go
to
autosd.center.org,
you
see
a
sample
images
folder,
you
see
some
content
in
there,
but
that's
still
not
something
that
we
are
satisfied
with.
One
of
the
thing
that
we
are
dissatisfied
about
it
is:
it's
currently
not
compressed
so
you're
downloading
a
out
of
10
gigs
of
data
just
for
an
image.
G
So
that's
not
something
we
want
to
go
for
there
and
I
believe
the
location
of
these
images
is
due
to
change
in
the
in
the
long
term.
So
once
we
have
something
really
we'll
announce
it
and
probably
through
the
the
weekly
newsletter,
auto
isd.seek.center.org.
G
And
so
once
we
have
something
really,
you
know
we'll
announce
it
and
we'll
probably
leave
it
here,
but
you
you
know
if
you've
seen
it
before.
This
is
what
it
is,
but
don't
assume
that
it
is
the
it
is
the
final
location
or
that
it
is
the
final
content.
It's
we're
not
there.
Yet.
G
E
E
So
pierre,
essentially
for
a
while
we
were,
we
were
looking
at
each
discrete
package,
build
that
was
a
candidate
for
inclusion
in
centos,
9
stream,
which
is
our
primary
source
of
updates
and
those
are
sort
of
backing
up,
and
so
now
you're
saying
at
the
moment,
the
in
the
unit
of
change
that
you're
looking
at
is
based
on
the
nightly
compose
of
centos
nine
stream.
E
Okay,
I
had
thought-
and
there
was
another
there's
another
thing
in
the
running,
which
was
essentially
to
still
look
at
every
single
package,
but
never
gate
essentially
like
leave
open
the
possibility
that
we
would
do
that
at
some
point,
but
essentially
always
pass
to
sort
of
preserve
visibility
into
the
package
by
package
changes.
So
I
asked
about
that
because
actually,
oh
go.
B
G
Sorry,
sorry
that
the
compost
had
a
different
aspect
as
well
was
the
it
was.
It
was
the
the
smallest
step
to
fixing
the
the
the
situation.
It
was
not
the
whole
journey
to
fixing
and
making
it
better,
but
it
was
the
the
smallest
step
we
could
do
to
see.
If
that
was
improving
something.
If
it's
not,
then
we
can,
you
know,
do
unfollowing.
E
Yes,
no,
I
think
it's
I'm
totally
like
far
far
better
to
have
right
now,
an
auto
sd
that
reflects
the
latest
things
that
are
coming
out
of
centos
9
stream
than
to
back
up
on
it
on
a
not
yet
completely
baked
gating
mechanisms.
You
know
that
and
I
was
going
to
tie
it
also
to
the
question.
There
was
a
question
actually
in
the
in
the
pre-formal
meeting,
start
time
about
documentation
and
developer
guide
and
whatnot
and
the
the
next
place
I
was
going
to
take.
That
actually
was.
E
In
that
context,
I
know,
for
example,
it's
now
possible
to
submit
a
pr
against
a
package
in
centos,
9
stream,
whether
you're
a
red
hat,
employee
or
not,
and
I
think
we're
endeavoring
to
to
mirror
to
the
extent
possible
the
workflows
from
stream
incentives
for
the
automotive
product
and
that's
what
auto
sd
is
essentially,
so
I
don't
know
that
we're
in
a
position
really
to
do
that
right
now,
especially
since
we
only
have
one
package,
it's
a
very
important
one,
clark
williams,
but
we
only
it's
only
the
kernel,
so
I
just
tied
back
to
that
as
well.
E
Eventually,
we
will
have
this
interesting
phenomenon
where
we
have
a
stream
of
updates
from
centos
that
aren't
entirely
under
our
control.
We'll
have
another
stream
of
updates
from
packages
that
are
that
red
hat
is
providing
that
are
specific
to
automotive
right
now,
it's
just
the
kernel.
I
mean
you
just
sort
of
synthesize
that
into
something
that
is
a.
It
is
a
down
a
an
evolved
artifact
for
auto
sd
that
incorporates
both
of
them,
so
it'll
be
fun.
G
There
is
one
thing
also
that
has
so:
it
should
have
progressed
a
lot
more,
but
since
I
was
away
from
keyboard
this
week,
it
has
it
has
progressed,
but
not
as
much
as
I
would
have
liked.
It's
the
the
automotive
namespace
under
gitlab,
don't
gitlab.gitlab.com.
B
G
The
automotive
sig
has
volunteered
to
help
the
census
infrastructure
from
the
edges
on
the
the
center's
on
the
use
of
the
santos
namespacing
gitlab,
which
means
we
should
have
everything
we
need
to
actually
create
the
automotive
namespace
on
the
onsens
on
gitlab.com,
centers
and
start
using
it.
There
is
a
there
was.
You
know
there
is
some
good
practices
that
needs
to
be
that
needed
to
be
written.
There
were
some
agreements
on
how
do
we
handle
groups
and
authentication
success
and
all
these
kinds
of
things?
B
G
Out
and
documenting
them
as
we
go
so
basically
we
should
have
the
the
automotive.
We
should
be
able
to
start
using
the
automotive
namespace
under
centers
early
next
week.
That's
I
have
all
the
access.
We
have
all
the
agreements
now,
it's
a
matter
of
actually
creating
the
namespace
linking
it
to
the
sentence,
account
system
and
then
starting
to
create
the.
G
Underneath
it
for
for
our
needs-
and
I
know
francisco-
I
want
it-
was
figure
and
has
been
asking
me
for
feedback
about
this
and
I'm
sorry.
I
didn't
get
back
to
you,
but
it
was
been
a
it's
been
a
that's
a
predictive
freak
on
my
hand.
Let's
put
it
this
way,
but
that
is
that
part
has
progressed.
There
is
hope.
A
I
G
So
currently,
the
automotive
sig
repo
is
under
the
red
hat
name:
space
gitlab.com
redhat,
slash
automotive,
that
namespace
is
only
accessible
to
redact
employee,
but
the
sig
is
a
center's
sake
we
contain
so
can
contain
more
than
just
related
employees,
so
we
want
to
be
able
to
move.
We
basically
want
to
create
probably
the
same
structure,
but
instead
of
being
under
guitar.com,
slash,
red,
slash,
automotive,
it
will
be
gitlab.com
center,
slash,
automotive.
The
difference
is
you're
going
to
have
to
use
ascentos
centos
account
the
centos
account
system.
G
Instead
of
the
redaddacon
system,
we
will
be
able
to
invite
people
that
are
not
read
others.
As
long
as
they
have
a
sentence
account.
We
will
be
all
the
access
control
will
be
done
from
the
centos
account
system,
instead
of
being
the
red,
the
red
hat
held
up
and
all
this
kind
of
thing.
So
the
idea
is
the
same.
We
use
it's.
It
would
be
very
much
like
that
that
the
way
it
works
with
red
hat
currently
the
in
redox,
we
are
told
that
dxs
should
be
handled
by
groups.
G
E
Okay,
good-
and
this
is
a-
I
will
admit
like
like
laura
jean
being
confused
by
this
as
well,
and
it
really
is-
was
down
to
access
rights
and
it
also
overlapped
with
some
challenges
we
had
about
the
package
build
infrastructure
itself,
which
was
not,
which
was
very,
very
detailed
and
technical,
and
not
really.
There
was
no
philosophical
element
to
this
change.
It
was
very
practical.
Yes,
it
isn't.
None
of
this
reflects
a
change
in
the
way
that
we
would
like
the
sig
to
operate
or
what
our
goals
or
mission
are.
E
G
A
I
I
We
don't
know
100
how
to
do
that.
Yet
you
know
because
it's
if
it's
for
auto
sd
we're
not
going
to
be
calling
it
red
hat
in
vehicle
operating
system,
it's
going
to
be
called
auto,
sd
or
automotive,
or
whatever,
whatever
we're
calling
it
on
that
side.
So
you
know
we'd
like
to
have
a
variable
that
changes
it
between
repos
if
we
are
using
the
same
content
and
if
we're
not
using
the
same
content,
I
guess
the
question
would
be
well
why?
I
Just
because
it
it
takes
a
lot
of
time
to
develop
content
and
it's
risky
when
you
have
to
update
it
into
places
if
things
change
so
as
much
reuse
as
possible
as
our
goal
so
yeah,
I
think
we're
going
to
have
to
talk
about
it
more.
Maybe
this
is
not
the
right
time
to
do
that,
but
I'll
talk
to
my
other
tech
writers-
and
I
know
felicia-
is
working
on
something
with
her
tool
chain
group
right
now
to
even
figure
out.
I
You
know
if
the
mirroring
or
the
sinking
and
retaining
variable
definitions
is
even
possible.
She's
working
with
someone
named
juan
hey,
I
have
not
met
that
person,
so
I
don't
know
exactly
what
they've
discussed
and
previewed
those
conversations
yet.
So
I
think
the
short
answer
is
we'll
have
to
continue
talking
about
this.
A
Yeah,
well,
I
think
it's.
This
is
a
having
having
it
come
up
here
in
the
sig
meeting,
where
we
have
some
folks
who
aren't
from
red
hat
is
a
good
option
to
to
discuss
it,
because
it's
great
to
get
some
ideas
about
what
people
do
expect
from
documentation.
Do
you
just
expect?
You
know
essentially
man
pages
and
api
docs,
or
are
you
looking
for
developer,
documentation
and
much
more
esoteric
and
and
a
lot
more
involved,
so
we'd
loved
any
feedback
that
anybody
on?
The
call
would
like
to
provide.
I
Which
I
think,
and
any
of
the
red
hatters
on
the
call,
have
probably
been
invited
by
schweda
to
review
the
documentation
content
plan,
the
customer
content
plan.
So
I
do
urge
you
to
take
a
look
at
that.
I
believe
she
closed
the
window
for
comments
last
week,
but
you
know
nothing
in
docs
is
ever
final
right.
A
A
I
don't
have
a
whole
lot
of
else,
a
whole
lot
else
to
on
the
agenda.
As
far
as
as
content
goes,
we've
got
the
drawings
that
pierre
did
that
I
don't.
I
think
everybody
has
probably
seen
a
couple
of
times
just
explaining
how
auto
sd
works,
and
then
I
just
had
down
here
that
the
the
goals
to
show
some
progress
on
the
goals
that
we
have
set
up
for
2022,
that
we
do
have
some
contribution,
guidelines
now
and
some
some
more
specific
documentation,
which
is
great.
A
A
And
I
can
also
go
over
some
of
the
other
open
source
initiatives
that
red
hat
has
been
involved
with
to
see
where
else
we
intersect
with
some
of
the
other
folks
on
the
column,
the
question
is:
where
does
everybody
want
to
go
with
this
meeting
any
preferences,
any
thoughts
we
can
keep
talking
about
the
technical
aspects
of
the
auto
sd2.
I
I
do
have
one
more
docs
theme
to
bring
up
and
I'm
sorry
I've
let
this
drop,
but
the
rail
developer
guide
has
a
section
about
relatives
upstream
projects
products,
so
the
rivos
folks.
We
folks
need
to
review
that
to
see
how
much
of
that
is
reusable
and
true
for
rivos.
So
I
will
send
another
invitation
to
take
a
look
at
that
to
you
jeffree
ian
pierre
and
anyone
else
on
this
call
who
would
like
to
be
involved
in
that
review.
I
D
So
this
this
is
a
flip
talking,
clearly
one
area
where
we
see
more
and
more
requirements
on
how
we're
going
to
interface
safety
with
security
which
translate
in
having
a
real-time
operating
system
and
a
rich
operating
system.
So
for
us,
linux,
some
open
source
group,
so
coveza
was
used
to
be
named,
genevieve,
okay,
the
chanter
name
recently.
D
The
most
well
known
is
probably
vss,
which
is
a
normalization
of
the
data
within
a
car,
and
this
one
is
about
telemetry
and
is
targeting
on
how
we
can
in
fact
do
safety
at
least
a
low
level
safety
like
a
zlb
within
linux,
which
I
mean
how
we
can
address
the
certification
and
the
audit
of
the
process.
D
D
You
know
using
his
mobile
phone,
so
this
camera
needs
to
take
20
image
per
second
in
order
the
ai
algorithm
to
be
accurate
enough
to
get
an
acceptable
response
from
the
camera.
D
So
this
is
done
within
an
fpga.
I
saw
the
the
ai
algorithm
as
such
run
in
a
completely
separated
hardware,
and
linux
is
in
charge
of
monitoring
that
the
safety
device
is
acting
correctly,
which
means
that
linux
is
in
charge
of
making
sure
that
the
camera
is
effectively
generating
at
20
image
per
second
and
also
is
in
charge
of
collecting
the
high
level
information
like
the
driver
is
not
he's
reading
his
phone,
so
you
have
to
warn-
and
you
have
to,
for
example,
stop
the
autopilot.
D
D
D
But
clearly
there
is
a
there
is
a
demand
here
as
well
as
there
is
a
very
strong
demand
on
how
we
can
certify
in
in
a
repeated
way
and
automated
way,
the
certification,
whether
they
are
safety
or
security
certification,
which
is
one
of
the
big
showstoppers
that
people
have
today
and
in
fact
there
is
a
one
project
that
we
are
looking
at.
That
is
going
in
that
direction,
which
is
a
nist
okay.
So
the
nest
is
that's
a
us
governmental
organization
and
they
are
working
on
on
specifying
a
language
to
describe.
D
You
know
the
safety
and
security
event
in
such
a
manner
that
you
can
do
an
introspection
with
with
an
automatic,
and
the
idea
is
that
you
know
if
you
have
certified
version
one.
If
you
apply
security
patch
for
version
one
one,
then
you
can
re
re-process
the
certification
automatically.
A
I
do
remember
running
across
this.
It
was
very
specific
to
to
automated
control
systems.
D
For
what
I
know,
it
is
the
only
attempt
today
to
have
a
normalized
language
to
describe
the
you
know,
your
rule
and
and
the
outcome
of
the
rule,
but
maybe.
D
A
That
is
certainly
true
and
it's
something
that
that
we've
been
working
on
over
the
last
year
or
so
that's
the
basis
of
red
hat's
relationship
with
xeta
to
try
to
develop
a
methodology
towards
functional
safety.
A
I'm
not
sure
everybody
on
the
call
knows
also
there's
also
a
second
a
a
second
effort
within
the
iso
community
to
make
an
update
to
iso
26262.
It's
called
an
iso
pass
process
and
changing
an
international
standard
takes
a
very
long
time.
Yeah.
A
Very
long,
yeah
yeah-
this
has
actually
been
going
on
for
quite
a
long
time
though,
and
it's
in
draft
mode
at
this
point,
so
I
believe
it
was
we're
just
coming
from
the
elisa
workshop
this
past
week.
I
believe
there
is
a
timeline
now
that
they're
looking
for
the
beginning
of
next
year
to
be
in
final
draft
mode
and
towards
I
think,
august
or
september
next
year,
2023
to
be
to
be
finalized.
A
It's
very
hard
to
actually
book.
You
know
to
be
accurate,
with
a
calendar
around
a
standards
process,
but
that's
the
idea.
D
But
we
see
a
big
shift
and
I
think
that's
quite
recent-
that
device
that
were
used
to
be
purely
safety,
oriented
like
a
leader,
for
example
lidar
in
the
past,
where
running
a
real-time
operating
system,
plus
something
like
qnx
or
you
know
some
kind
of
heavy
posix,
real-time
property
os,
and
now
they
are
willing
to
replace
that
with
linux.
B
D
Clearly,
the
real-time
operating
system
is
still
doing,
like
you
know
the
point
measurement
and
eventually
is
notifying
the
cars
that
it
should
break,
but
all
the
high-level
function
like
recomposing
the
point
to
say
this
is
a
pedestrian.
This
is
a
car.
This
is
a
burst.
This
is
a
track.
This
can
be
done
by
linux.
B
D
A
D
Yes,
I
think
it's
like
any
security,
you
know
constraints,
it
has
good
and
bad
part.
You
also
have
a
lot
of
people
that
try
to
protect
their
business,
and
you
know
when
you
do
a
real
analysis,
a
real
risk
analysis
of
most
of
the
of
the
requirement.
A
huge
part
of
them
can
be
removed
from
the
actual
product
because
they
are
not
justified.
D
So
you
know,
and
clearly
the
german
manufacturer
have
been
very
good
at
adding
you
know,
constraints
on
the
system.
I
think
tesla
has
shown
the
the
way
was
the
past
to
to
make
system
cheaper
by
by
you
know,
really
only
implementing
what
was
necessary,
and
now
everyone
is
going
to
go
through
that
pass
as
well.
So.
D
A
So
it
here's
actually
a
question
for
philip:
do
you
have
you?
I
know
that
everybody's
tracking,
the
real-time
work
going
into
the
mainline
linux
kernel
yeah,
do
you
have
an
impression
that
that
will
make
it
easier
to
do
things
like
functional
safety?
Or
do
you
think
it's
going
to
be
maybe
more
complex.
D
Honestly,
no,
okay,
it's
it's!
It's
not
a
bad
thing.
Okay,
let's
be
clear,
but
to
be
honest,
I
I
we
did
not
really
had
issue
with
real
time
for
quite
a
long
time
now:
okay,
because,
okay,
we
did
not
had
like
a
clean
api
to
solve
the
problem,
but
we've
been
able
to
solve
the
problem
by
by
other
manner
with
you
know,
some
specific
configuration
some
low
level
code,
even
a
specific
kernel
driver.
D
So
I
I
don't
see
like
this,
providing
a
lot
of
new
functionality
for
us.
B
D
So,
honestly,
I
think
it
is
a
good
idea
and
it
is
clearly
necessary
in
any
way,
because
if
you
want
to
go
for
safety,
they're
going
to
request
that,
but
for
me
that
was
not
the
biggest
showstopper
okay,
the
biggest
showstopper
is
more
on
the
audit
side
and
and
we
still
have
strong
requirement
for
running
real-time
operating
system
like
zephy
or
autozar
in
either
dedicated
core
or
a
microcontrollers
that
run
on
the
same
circle,
even
on
a
different
circuit
and
for
political,
and
you
know,
the
organization
is
designed
in
such
a
way
that
the
person
that
is
in
charge
of
the
break
is
not
going
to
run
with
the
same
team
that
is
running
the
avi
so
before
they
they
share.
D
The
same
process
is
going
to
take
a
very
very
long
time
but
yeah.
So
I
I
see
it
as
a
nice
to
have
feature,
I'm
very
happy.
They
made
it
because
you
know
we
we
had
to
maintain
that
patch
and
it
was
not
an
easy
patch
to
maintain.
So
this
problem
is
sold
out,
but
it's
not
going
to
change
the
world
yeah.
It's.
A
Yeah,
I've
actually
thought
over
the
years
that
maybe
real
time
was
was
not
quite
the
right
term
anymore.
I
mean
the
whole
the
value
in
it
is
making
a
system
deterministic.
D
D
Okay,
you
also
have
very
complex
processor
with
multi-core,
and
you
know
you
might
be
luck
for
io,
but
in
a
driver
in
many
different
places.
So,
to
be
honest,
I
think
opti,
you
know
that
help
us
to
provide.
You
know
a
secure
boot
and
a
trusted
chain
of
trust
was
far
more
important
because
that
was
a
a
showstopper.
D
I
I
think
real
time
was
a
shortstop.
You
know
when
I
still
had
you
know
dark
hair,
but
you
know
I
I
can
start
my
camera,
so
people
don't
know
me
will
see
that.
D
Completely
white
hair-
and
I
think
this
problem
has
disappeared
with
the
color
of
my
hair,
okay.
So
no,
but
we
still
have
requirement
on
the
other
end.
You
know
in
the
automotive
sector,
they're
still
very
mean,
and
so
they
still
want
to
run
the
computer
at
90
percent
of
their
hardware
capability,
and
we
had
discussion
recently
with
one
potential
customer
and
we
were
asking
you
know
in
between
one
and
three
percent
of
the
resources
to
implement
virtualization,
and
the
answer
was
that's
too
much.
A
That
is
a
very
specific
economy,
but
but
I'm.
D
Not
sure
that
they
make
they
save
money,
in
fact,
they
may
lose
money
by
doing
that,
but
that's
another
story:
yeah,
no
we're
small
companies.
The
customer
is
always
right.
Okay,
we're
not
going
to
say
the
customer
is
wrong.
Okay,
sure,
if
there
are
any
listening
to
this
talk,
I
agree
with
whatever
they
say.
Okay,.
A
One
other
question
I
was
wondering
about.
As
far
as
the
the
mainline
kernel
work,
I
know
that
the
linotronics
was
the
organization
that
is,
it
was
doing
that
and
they
were
very
recently
acquired
by
intel.
D
G
C
Thomas
thomas
and
I
talked
a
bit.
C
Right
after
it
happened
and
of
course
I
was
giving
him
a
hard
time
because
you
know
we
got
acquired
by
ibm
and
he
gave
me
a
whole
load
of
grief
on
that.
So
I
felt
like
I
had
to
give
him
some
back,
but
I
don't.
I
don't
think,
there's
going
to
be
a
ton
of
direction
given
from
intel.
I
think
they,
it
was
almost
a
an
acquired,
a
higher
sort
of
sort
of
thing.
So
I
don't
I
don't
see.
I
mean
the
the
plan
in
case.
C
Anyone
doesn't
know
is
that
we
should
be
able
to
build
a
preempt
rt
kernel
in
the
5.20
release
and
we're.
B
C
We're
currently
working
on
5.18
now
that,
of
course,
is
dependent
on
a
lot
of
things.
Pre
print
k
reared
its
ugly
head
about
a
year
ago
and
we're
still
dealing
with
the
fallout
of
that
rent.
The
random
driver
is,
is
being
totally
overhauled
and.
E
C
Touches
everything
in
the
crypto
world,
so
yeah
things
could
be
delayed.
I
wouldn't,
I
really
wouldn't
bet
the
farm
on
it
being
5.20,
but
it's
as
close
as
I've
ever
seen
us
get
in
15
years.
So
you
know,
but
to
get
to
your
original
point,
I
don't
necessarily
think
that
the
acquisition
of
lineartronics
is
a
bad
thing.
C
A
C
A
Elenatronics
is
probably
great
for
intel
yeah.
My
concern,
of
course,
is
for
the
community,
but
I
know
that
thomas
has
been
a
pretty
good
steward
of
that
over
the
years.
I
don't
think
that
he
would
yeah
well.
A
A
C
A
C
Continue
funding
so,
but
I
think
this
this
means
that
they'll
take
it
to
the
end,
and
then
the
next
step
is
to
figure
out
how
we
treat
real
time
in
upstream,
a
lot
of
debate
going
on
as
to
whether
that
should
be
a
subsystem,
even
though
it
has
threads
in
just
about
every
piece
of
the
kernel.
C
C
B
Hello,
I
have
a
random
thing.
I
just
wanted
to
jump
in.
B
I
don't
know
if
there's
a
good
place
to
say
this,
but
I'm
so
I've
been
running
a
group
that
is
working
on
improving
fedora
and
raspberry
pi,
among
other
things,
and
so
we
presented
to
mike
mcgrath
a
couple
of
months
ago
and
you
know
about
trying
to
potentially
support
fedora
and
sent
a
stream,
and
you
know
if
we
could
make
the
case
even
rel
on
the
raspberry
pi
and
then
he
had
suggested
supporting
centos
stream
on
the
raspberry
pi
and
in
terms
of
next
steps.
B
He
basically
said,
come
come
over
here,
I'm
pretty
sure.
Okay
and
so
there's
been
some
conflicts
with
this
meeting
and
I
haven't
been
able
to
make
it
over,
but
you
know
now,
I'm
here.
I
think
I
don't
know
if
julia
denim
was
here
with
one
of
these
meetings.
She
was
also-
I
don't
know
if
she
she
said
something
about
this,
but
yeah.
I
mean
we're
here.
There's
some
interest.
You
know
on
that
level
in
terms
of
supporting.
I
know
there
have
been
raspberry
pi's
that
have
been
used.
B
I
don't
know
exactly
what
the
next
steps
would
be
or
who
would
even
be
doing
the
work
or
that
sort
of
thing,
but
I
figured
I
would
give
this
message
and
ask
well
what
does
everyone
think
about
for
the
raspberry
pi
support?
Is
there
any
way
that
we
can
collaborate?
Is
it
at
all
feasible?
Do
we
need
more
resources,
etc?.
E
Oh
and
joel,
thank
you
thank
you
for
coming,
and
I
know
we've
had
some
brief
contact
on
this
a
couple
of
months
ago
and
I'm
glad
you
were
able
to
come.
We've
made
pretty
extensive
use
of
the
raspberry
pi
in
some
of
our
early
testing
with
automotives.
I
think
there's
a
real
possibility
here.
I
don't.
I
won't
rehash
the
challenges
that
raspberry
pi
has
in
the
fedora
and
and
then
downstream
rail
space
beyond,
just
briefly
summarizing
that
it's
a
good.
E
It's
a
good
test
platform
for
automotive
hardware
in
a
sense
because
it
has
the
same
pattern
of
enablement,
runs
ahead
of
upstreaming
of
some
of
the
kernel
content,
and
so
in
that
sense
we,
you
know
it
is
arguably
a
downside
for
something
like
fedora,
where
fedora
tries
to
hue
very
closely
to
the
upstream
kernel,
which
means
that
you
can.
You
can't
do
as
much
with
a
raspberry.
E
Pi,
typically,
is
certainly
right
after
a
new
model
comes
out,
as
you
could
do
with
raspbian
or
some
of
the
essentially
bsp
like
distributions
that
come
with
that,
and
you
know
that
that
continues
to
be
a
challenge,
but
also
you
know
for
some
of
what
we're
looking
at
there's
enough
functionality
there
that
it
works
and,
as
I
say
actually
that
problem
actually
mirrors
a
challenge
that
I
know
we
have
with
all
the
hardware,
that's
potentially
on
deck,
for
automotive
use,
where
it's
often
it
can
run
linux,
but
it
can't
run
upstream
linux
and
that's
usually
a
prerequisite
for
red
hat
involvement
on
a
commercial
basis.
E
So
I
know
pierre
has
has
been
actively
doing
some
work
with
the
raspberry
pi
as
and
I
think
eric
has
done
some
as
well.
Do
you
guys
want
to?
Is
there
anything
you
want
to
highlight
like
what
we're
all
what
is
already
happening
with
raspberry
pi
on
the
automotive
side,
from
our
work.
J
Yeah,
I
think,
there's
there's
probably
at
least
10
people
that
have
been
using
a
raspberry
pi
in
some
form
or
another
yeah
like
you
can
you
can
build
okay,
I
would
know
about
this,
but
you
can
build
auto
sd
for
raspberry
pi
and
it
works
great,
but
there's
there's,
there's
lots,
there's
still
lots
of
things
that
don't
work
so
well
like
one,
for
example,
remember
I
I
have
similar
issues
with
the
camera
stuff,
but
the
player
will
remember
that
we
still
haven't
quite
got
wayland
running
on
it
and
and
the
drivers
are
there
and
yet
long
story
short.
J
We
would
definitely
appreciate
help
there.
I
think,
because
yeah.
E
B
Yeah,
I
do
have
a
raspberry
pi
and
I
I
can
test
things
I
have
tested
the
I
think
I
tested
the
the
rail
kernel.
I
think
I
tested
the
real
time
kernel.
Actually
I
just
I
mean
just
a
boot
test
really
on
the
raspberry
pi
and
it
it
booted.
You
know
I
needed
to
get
some
weird
patch
from
clark
to
make
the
rpm
actually
build,
because
it
doesn't
officially
do
that.
But
but
you
know
it
didn't
crash,
didn't
panic.
That
was
that
was
good,
so
yeah.
E
C
You
probably
did
that
headless.
Didn't
you
joel,
I
don't
think.
B
Is
probably
one
of
the
biggest
pain
points?
Definitely
on
the
user
end
and
I've
been
trying
to
so
I've
been
in
touch
with
someone
in
sales,
alexander
jacox,
who's,
very
enthusiastic
about
raspberry
pies
in
him
he
says:
there's
like
20
other
solution,
architects-
or
you
know,
people
in
the
sales
organization
anyway,
in
north
america
alone,
who
are
very
interested
in
the
raspberry
pi,
is
from
a
business
perspective.
B
In
terms
of
you
know,
trying
to
sell
some
kind
like
basically
many
many
customers
are
interested
in
doing
purchasing
some
kind
of
solution
involving
raspberry
pi's,
a
number
of
like
significant
quantities
too,
and
I'm
not
sure
how
the
product
lineup
works
in
terms
of
what
red
hat
sells
with
regard
to
support
on
fedora,
maybe
they,
you
know,
have
some
some
kind
of
product
related
to
support
or
setting
up
the
infrastructure
there,
I'm
not
really
sure,
but
he's
saying
there.
B
You
know
there
could
be
a
serious
kind
of
business
case
for
that
and
potentially
that's
something
we
could
bring
to
broadcom.
I've
been
trying
to
schedule
something
with
the
broadcom
partner
manager
to
talk
about
this,
but
to
try
and
ask
about
working
on
open
source
drivers
for
the
vc6
chipset.
You
know
the
gpu,
that's
on
the
raspberry
pi
4,
which
I
think
is
like
unique
to
the
raspberry
pi
4
and
the
lack
of
open
source
drivers
there
from
what
I
understand
is
one
of
the
biggest
pain
points.
B
B
Just
overall
I've
been
trying
to
find
different
people
across
the
organization,
different
stakeholders
who
have
an
interest-
you
know
in
furthering
you
know
red
hat
support
on
raspberry
pi
on
raspberry
pi
4,
especially
red
hat
operating
systems
and
raspberry
pi,
and
so
I'm
slowly
starting
to
build
a
list
or
kind
of
a
loose
network.
It's
not
very
formal,
but
it's
it's
definitely
wider
than
I
expected.
E
You
know
we
there's
a
strong
ethos
of
being
clear
about
what
we
can
and
cannot
support
in
red
hat
when
we
think
about
our
commercial
products,
but
there's
also
a
wider
space
of
things
that
that
work
and
there's
people
who
use
rel
or
rel
derivatives
for
something
other
than
production
uses,
and
that
there's
a
clear
slot
for
that
with
the
raspberry
pi
in
in
this
arena
for
sure,
like
it's
the
most
by
far
the
most
easily
obtained
still
well,
I
mean
nothing
is
easily
obtainable
right
now,
but
it
is
still
among
the
most
easily
obtainable
arm
platforms.
E
It's
extremely
affordable,
it's
it's
everywhere.
Everyone
uses
it
and
I
would
like
us
being
able
to
contemplate
use
of
it.
That
is
significant,
but
falls
short
of
it,
for
example,
being
in
a
vehicle
or
in
a
data
center.
I
think,
is
really
useful.
So
just
something
to
keep
in
mind-
and
you
know
perhaps
perhaps
a
slight
overshare,
but
you
know
we're
an
open
company.
So
that's
that's
where
my
head
is
at
with
it.
G
Yeah
I
just
wanted
to
to
point
out
from
the
technical
angle
we
have.
We
have
as
part
of
the
sig
all
the
space.
We
want
to
experiment
with
things
without
having
them
land
on
osd,
because
the
idea
is
that
we
have,
I
mean
if
you
look
at
that's
one
of
the
things
we
did
to
the
readme
of
the
or
the
front
page
I
mean
of
the
the
automotive
sig
documentation
is
that
we
have
three
artifacts.
We
have
sample
images,
we
have
photo
sd
itself,
but
we
also
have
the
rpm,
the
automotive
rpm
the
automatic.
G
How
do
I
phrase
that
the
automotive
sig
repositories,
rpm
repositories,
and
do
these
repositories
are
meant
to
host
anything?
We
seek
want
to
work
on
or
want
to
to
experiment
with
without
having
any
application
as
to
if
that's
going
to
land
on
the
product
down
the
line.
So
we
could
very
well
be.
You
know
developing
support
for
the
raspberry
pi
5
in
the
automotive
sig
repository
and
that
has
no
there's
no
consequences,
whether
auto
sd
and
then
reducting
vehicle
os
down.
G
G
One
of
the
examples
of
I
don't
know
if
we
want
these
changes
to
land
in
auto
sd
versus
the
rpm
repository
repository,
where
we
can
just
play
and
experiment
with
them
we're
in
this
we're
in
a
place
now
where
the
o2sd
is
still
friction
enough,
that
fluid
enough
that
we
we,
I
think,
landed
them
in
the
in
osd
these
changes,
but
down
the
line
there
will
be
place.
There
will
be
times
where
we'll
say
well,
this
branch
is
going
to
be
a
autosd
specific
and
the
changes
that
land
there
aren't
meant
to
go
into.
G
You
know
sd
and
then
the
product
down
the
line-
and
you
know
these
other
branch
here-
are
more
experimental
work
and
more.
You
know
clark,
real-time
kernel,
v2
patch,
and
these
ones
are
experimental.
They
will
come
on
the
on
the
automotive
sig
repo
and
there
is
no
notion
of
supporting
it
from
the
radar
perspective,
but
that
is
a
notion
of
making
it
available
to
anyone
in
our
community.
Who
is
interesting
to
look
at
this.
G
So
if
you
want
to
further
improve
the
the
raspberry
pi
support
using
the
real-time
kernel,
and
you
want
to
use
the
canon
automotive
ico
basic
4d
work
it
we
can
easily
do
that
and
just
leave
that
kernel
leave
in
there
in
the
you
know,
automative
repo,
without
having
necessarily
having
it
impacting
or
to
sd,
and
then
we
can
easily.
You
know,
merge
back
and
forth
changes
that
are
at
the
top
of
interest,
either
from
a
to
sd
into
the
your
raspberry
pi
channel
or
from
the
raspberry
pi
canon
into
a
twist.
If
that's.
B
So
deemed
could
use
that.
Let
me
use
it
as
kind
of
a
like
a
place
to
track.
You
know
issues
with
you
know,
upstream
support
for
the
raspberry
pi
and
like
as
a
staging
ground
for
upstreaming
different
things,
potentially,
because
that's
kind
of
what
I've
noticed
is
that
there's
not
really
the
closest
there
is
to
a
centralized
location
for
upstream
support
for
raspberry
pi
is
like
a
random,
like
github
issue
number
40
on,
like
some
random
person's
repo.
B
That
has
like
a
table
that
isn't
that
frequently
updated,
so
I
mean
just
having
some
kind
of
like
you
know
more
official
place
to
track
these
things
and
maybe
to
to
you,
know
to
try
and
gather
you
know.
Engineers
would
be
a
very
good
good
progress.
I
think
clark
yeah
pierre.
C
I
I
may
have
missed
it
earlier
in
the
presentation,
but
in
in
the
kernel
that
we're
gonna
track
in
the
automotive
sig.
What's
your
upstream
is
it,
do
you
have
multiple,
I
mean,
are
you
pulling
from
linus's
tree
or
are
you
pulling
from
ark.
E
G
E
Is
going
to
be
the
centos
stream
equivalent
for
the
rivas
product
and
then
that
in
that
form,
it's
going
to
have
kernel
automotive,
but
it
can
have
we.
We
have
broadly
way
to
do
other
things
as
long
as
we
don't.
You
know,
use
copyright
code
that
we
don't
have
permission
for
or
run
afoul
of
various
patent
issues
that
are
well
known
to
people
in
the
open
source
space.
So.
E
C
I'm
maintaining
a
a
branch
in
kernel
arc
that
is
basically
us
applying
the
real-time
path
set
to
linus's
head.
It's
a
little
problematic
because
it's
kind
of
a
three-way,
sometimes
four-way,
merge
and
and
you're
trying
to
decide
which
one
is
actually
the
real
one
and
the
latest.
C
C
B
C
C
An
automotive
variant
in
that
already
andrew
heleny
and
I
are
are
kind
of
tag
teaming
that
so
I
just
wanted
to
offer
that
up
and
say
you
know
it
could
be
a
good
upstream
for
you
guys
and
it's
going
to
be
it.
The
upstream
for
arc
is
for
my
branches,
linus
head
and
the
latest
preempt
rt
patch
set
from
kernel.org.
D
This
lead
me
to
a
question
as
today
in-house
we
are
maintaining
a
certain
number
of
automotive
related
package.
We
we
do
that
in
swan,
obs
and-
and
we
maintain
binary
package
for,
for
example,
for
for
federal,
34,
35
or.
D
Does
this
project
intend
to
provide?
You
know
the
capability
to
build
those
package
for
santos
stream
directly
within
your
ci,
for
example,
for
yocto?
We
we
maintain
a
special
layer
to
build
all
those
tools,
but
we
could
we
could
also,
obviously-
and
internally,
we
already
have
it.
So
it's
it's
technically,
it's
not
a
real
problem
for
us,
but,
for
example,
we
on
on
this
one
we
can
see
that
we
we
have
all
the
I'm,
not
sure,
I'm
I'm
sending
a
message
here
I
was.
D
I
was
willing
to
push
something
on
the
present
now
present
now
yeah,
so
it
was
sent
okay.
So
we
maintain
package
for
the
can-
or
you
know
for
you
know,
can
open
or
modbus
or
some
other
stuff.
What
is
going
to
be
the
strategy
for
this
project?
Okay,
do
you
do
should
we
have
like
a
selection
of
of
tools
that
we
want
to
ship
with
with
the
distribution?
So
we
want
to
have
that
built
directly
into
your
ci
or
we
rather
have
some
external
people
running.
E
Well,
let
me
I'll
briefly
observe
that
you
there
are
already
at
least
two
ways
I
know
to
build
packages
that
could
be
used
against
the
auto
sd
or
even
centos
9
stream.
Right
now,
there's
the
community
build
system
which
is
actually
where
we
are
building
kernel,
automotive
and
then
there's
also
copper,
which
is
sort
of
joint
shared
with
fedora.
And
so,
when
philip,
when
you
say,
build
things,
do
you
I
mean?
D
I
think
it's
probably
a
mixed,
you
know
so
you're
right.
You
know
we
don't
have
any
issue
building
the
code
that
we
maintain,
okay
and
in
fact,
we
use
koji
to
to
build
that
or
the
obs
from
susie
it's
one
of
the
other.
We
don't
use
copper,
but
obviously
we
we
maintain
that
for
for
the
different
version,
we
are
supporting
okay,
so
it's
not
like
if
someone
from
the
community
is
willing
to
change
something
and
rebuild
it
or
if
you
have
like
a
nightly
built.
Okay,
we
are
not
going
to
follow
that.
D
Okay,
so,
for
example,
inside
agl.
If,
if
you
put
something
on
on
garrett,
then
agl
and
it
is
approved
by
the
community-
they
just
maintain
the
package,
okay
and
not
that
they
maintain
the
source
code,
but
at
least
they
rebuild
them
and
they
ship
them
on
the
different
versions
that
they
support
and
so
on.
E
D
Just
trying
to
turn
this
into
something
concrete,
yeah
like,
for
example,
the
can
bus
is
a
good
example.
Okay,
how
to
retrieve
canvas.
I
suppose
that
the
audio
could
be
also
a
good
one,
but
we
could.
C
D
All
those
tools
today
are
only
available
as
your
layer,
okay,
which
means
that,
I
would
say,
probably
very
little.
People
have
the
skill
to
recompile
them
with
centos
stream,
okay,
and
so
there
is
a
value
I
think
in
importing
those
projects.
So
for
us,
it's
a
bit
of
different
because
we
already
maintained
the
spec
file
and
everything
so.
D
You
know
it's,
it's
only
a
question
of:
do
we
want
to
make
it
public
or
not,
because
anyway
we
already
do
the
job,
but
if
we
are
talking
about
like
importing
welland
or
compositor,
or
you
know
the
pipe
wire
specific
audio
configuration
for
cars
that
they
have,
then
there
is
a
little
more
work
to
make
that
available
directly
within
this
type
of
of
sake,
yeah.
E
Yeah,
no,
I
think
it's
interesting
right
and
I
mean
it
it's
in
agl,
because
right
now
enough,
people
have
seen
the
value
in
doing
the
additional
effort
and
labor
required
to
manage
the
build
instructions
in
agl.
And
you
know
you
could
look
at
this
both
ways
we
could.
E
What
what
would
lead
people
to
want
to
have
a
growing
set
of
these
packages
maintained
in
such
a
way
that
they
can
be
used
on
top
of
centos,
night
stream
or
auto
sd
and
prior
to
them
being
essentially,
if
we
were
to
then
choose
to
productize
that
inside
of
red
hood
or
maybe
we
never
would
but
they're
still
useful
yeah
in
some
way.
So.
D
But
flooding
is
a
good
example.
Flutter
is
coming
from
sony
because
this
work
was
done
by
sony.
Initially,
then
it
was
spoiled
by
toyota.
You
know
toyota,
to
to
yokto,
but
you
know,
maintaining
a
spec
file
is
not
a
huge
work.
Okay,
that's
the
less
we
can
say,
but
it's
still
a
choice,
because
you
cannot
maintain
everything.
So
you
have
to
select
what
you
want
to
have
in
your
district
right.
E
No,
I
think
like
where
I
see
this
fitting.
In
a
broad
hand,
wavy
sense
is
we've.
Red
hat
has
come
to
this
sig
with
auto
sd,
essentially
so
we're
we
are
composing
regularly
a
view
of
a
sort
of
a
centos
like
equivalent
to
our
automotive
product.
It's
where
we
are
first,
exposing,
for
example,
the
specific
kernel
that
we're
going
to
do
for
it
and
if
we
are
to
add
any
more
software
that
isn't
already
part
of
centos
unreal,
we
would.
E
It
would
be
visible
here
as
well,
but
there's
a
second
category
of
thing
which
is
sort
of
candidates
for
that,
and
I
think
this
happens
already
with
fedora
and
centos
more
broadly.
There
are
repositories
of
software
that
people
want
to
use
enough,
that
they're
maintained
packages
are
maintained
that
can
build,
be
built
or
installed
on
top
of
centos
nine
streamer
on
top
of
center
citro
on
top
of
fedora,
even
if
they
aren't
formally
part
of
that
distribution.
E
And
what
you're
saying
what
you're
talking
about
sounds
vaguely
like.
Where
can
we
put
things
that
maybe
they
aren't
formally
part
of
something
that
red
hat
is
productizing,
but
that
we
want
to
be
able
went
to
show
that
they
can't
they
could
be,
or
they
could
just
be
something
that's
used
with
it?
I
think
we're
seeing
in
other
contexts
we're
seeing
some
interested
in
that
as
well
like
how
it
might
be
if
we
can.
As
a
say,
you
come
up
with
a
way
that
makes
it
clearer
for
yeah
piers
go
ahead.
E
Want
to,
I
want
to
start
maintaining
a
auto
sd,
build
of
something
that
isn't
in
centos
or
auto
sd.
How
do
I
do
it?
That's
the
that
would
be
the
user
story.
As
a
sig
member,
I
would
like
to
start
maintaining
a
package
that
is
new
that
isn't
part
of
centos
and
I'd
like
it
to
continue
to
work
on
top
of
auto
sd.
G
Card
we
need
to
have
documentation
on
that,
because
everything
everything
is
in
place
today.
We
just
are
liking
the
documentation
oriented
to
our
seek,
because
we
can
point
people
to
the
to
the
santos
2006
guide,
which
has
all
the
lists
of
information,
but
having
something
a
little
bit
more
tailored
to
our
sig
would
be
nice,
but
everything
is
in
place
if
you
want
to.
If,
tomorrow
you
come
to
us
with
a
spec
file
and
a
library
that
the
one
concern
is
going
to
be
licensing
it
has
to.
G
It
has
to
respect
the
licenses
that
the
census
project
can
distribute,
build
and
distribute.
So
you
know
free
and
open
source
software,
but
as
if
you
come
tomorrow
with
something
and
we
we
have
the
space,
we
have
the
resources
we
can
build
them
and
make
that
make
them
available
in
rpm
report.
That
is,
for
anyone
in
the
six
to
consume.
H
E
I
was
going
to
ask
the
like
the
I
I
suspect
one
issue
may
hear
here
may
be
that
it's
relatively
simple
for
some
of
us
to
do
this
and
it's
opaque
and
unclear
how
to
do
it.
For
others,
it
gets
to
pierre's
documentation
point,
and
I
also
I'm
going
to
ask
over
like
philip
is
obs.
Does
obs
make
this
really
easy?
Is
it
trivially
simple
to
maintain?
Like
start
adding,
I've
said
my
own.
D
No,
but
you
know
at
least
internally,
we
have
we
have
a
factory
on
top
of
koji,
so
for
us
maintaining
package
on
top
of
koji,
for
the
for,
for
you
know,
red
hat
and
and
santos
is
simple.
Okay,
but
obs
has
a
couple
of
features
that
initially
are
lacking
inside
koji
like,
for
example,
the
notion
of
services
where
you
can
download
npm
before
building
a
package.
Okay,
and
not
wait
for
your
network
to
be
switched
down
when
you
start
building
and
then
your
w
get
fail.
D
So
they
say
it's
it's
not
a
bad
tool,
but
honestly,
it's
not
an
easy
to
use
tool.
Okay,
those
tools
are
never
simple.
Okay,
it's
a
ci
cd
chain,
but
in
this
case
we
we
built
this
with
red
pest
factory.
That
is
a
superset
on
top
of
kogi
and
other
tools.
B
D
Yeah,
all
of
them,
you
know
you
still
have
to
write
the
spec
file,
understand
and-
and
we
cross
compile
everything
in
our
case-
okay
right,
because
we
do
cross
compilation.
So
even
if
we
rewrote
the
macro
in
such
a
way
that
normally
it
is
transparent
when
you
import
and
a
spec
file,
sometimes
you
you
have
some
surprise.
You
know
where
you
know
the
name
of
the
compiler
is
hard
written
or
that
type
of
thing.
B
D
D
Okay
and
today,
I'm
not
sure
how
much
we
have,
but
we
probably
close
of
20,
okay,
four
different
boards
that
include
qualcomm
ti
nxp-
you
know
st
renaissance
and
so
on,
and
we
also
have
the
capability
to
run
santos
stream
on
top
of
that.
Okay.
But
in
this
case,
even
if
we
can
reuse
the
kernel
configuration
of
the
sig
to
make
sure
that
we
share
the
same
functionality
most
of
the
time
you
you
are
luck
in
a
specific
kernel
version
because
of
the
vendor.
D
A
Quite
a
bit
over
time,
but
but
it's
a
great
discussion
and
I
think
that
goodwin,
maybe
this
is
a
good
day,
a
good
time
to
leave
off
and
we
can
meet
pick
it
up
again
in
two
weeks
at
the
next
okay
and
plus
sig
office
hours.
G
A
Very
very
much
a
status
we'll.
E
Offer
one
new
one
new
rpm
build
package
for
every
10
mailing
lists.
D
Thank
you
guy
and
have
a
nice
weekend
and
let's
talk
in
two
weeks,
bye-bye
thanks.