►
From YouTube: CentOS Automotive SIG office hours - 2021-10-01
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).
B
A
C
I
had
not
planned
on
being
here,
but
my
conflict
resolved
itself
by
canceling.
B
C
I
was
you
know,
that's
why
I
asked
brian
to
be
here
was
a
cover
for
me,
but
you
know
now
you
got
double
the
fun.
D
D
D
A
E
E
E
E
More
generally,
so,
basically
keeping
abreast
of
the
changes
that
are
happening
in
what
may
eventually
flow
into
rel,
which
will
also
be
relevant
to
what
we're
doing,
and
then
I
think,
we're
also
on
the
verge
of
demonstrating
a
little
bit
or
bringing
a
little
bit
to
the
table
about
what
we're
thinking
about
the
kernel
configuration
for
for
the
red
hat
automotive
product
anyway,
and
I
could
potentially
put
another
call
participant
on
the
spot
and
ask
for
we
could
go
into
whatever
level
of
detail.
People
want
on
that.
E
A
No
just
kind
of
wanted
to
to
get
a
high-level
picture
of
where
we
are
with
the
infrastructure
and
the
code.
That's
going
to
eventually
go
into
the
infrastructure,
yeah
and
the
problem.
A
C
With
doing
what
what
ian
wants?
Is
that
it's
all
kind
of
wrapped
up
in?
Well,
you
got
to
get
the
configs
right.
You
got
to
change
some
infrastructure
down
there
in
the
packaging
side
of
things.
Make
files
scripts
spec
file
template
that
sort
of
thing.
So
you
know
I'd
like
to
be
we've
got
raspberry.
Pi
is
running
rt
kernels
with
fedora
right
now
with
the
fedora
root
fs
and
you
know,
but
I
really
want
to
get
to
the
point
where
we've
got
a
package.
C
Call
it
kernel-auto,
that's
an
rt
kernel
with
the
you
know
appropriate
configs
that
we
can
then
drop
that
into
the
centos
sig
disket
tree
and
you
know,
generate
quasi-official
sig
bills
or
I
guess
official
sig
bills
with
it.
But
I
don't
what
I
don't
want
to
do
is
drop
in
the
existing
infrastructure
and
start
generating
kernel
dash
rt
packages,
because
that's
that
that
implies
the
difference
that
kernel
dash
rt
is
the
rail.
C
C
I
I
just
wanna,
I
I
don't
want
to
they're
both
going
to
be
real-time
kernels
built
slightly
differently,
but
I
just
don't
want
to
have
the
confusion
of
well.
We
start
out
with
kernel
rt,
and
then
we
have
to
shift
over
to
kernel
auto
so
anyway.
That.
C
E
E
Week
or
so
I
and
I
met
other
others
on
this-
call
me
know
better
than
I,
but
I'm
hoping
that
much
of
what
we
do
here
in
terms
of
building
content,
that's
unique
to
the
sig
will
be
pretty
familiar.
I
know
they're
they're
a
long-running
centos
cigs
that
have
created
alternative
content.
You
know
that
lives
outside
of
what
is
normally
part
of
the
rel
package
set.
E
We
may
have
set
ourselves
up
for
an
interesting
initial
challenge,
because
what
clark
and
the
team
are
hoping
to
do
with
this
kernel
is
have
a
great
deal
essentially
share
the
primary
source
with
the
centos
nine
stream
kernel,
which
I
think
is
there
are
good
reasons
for
that,
but
it
just
happens
to
present
a
bit
of
an
infrastructural
challenge
to
us
that,
frankly,
is
probably
not
of
great
interest
to
the
majority
people
on
this
call.
E
They
just
want
to
see
the
output,
but
it
is,
it
is
real
and
we'll
have
to
work
through
it.
So.
E
Alternatively,
people,
if
people
want
to
go
down
down
the
rabbit
hole
of
how
packages
how
a
bill
becomes
law,
I
think
we
have
an
animated
short
that
we
could
show
about
how
a
package
becomes,
how
a
source
begins.
I'm.
C
C
C
E
E
I
think
you
know
that
this
being
able
to
show
these
things-
and
these
are
really
real,
tangible
things
publicly-
is
going
to
be
an
important
step
for
us
and
I
think,
hopefully,
we'll
will
first
of
all
be
a
model
of
the
kind
of
thing
that
we
would
hope
to
do
in
the
sig
and
a
point
for
further
engagement
with
other
people.
So.
A
I
mean
there's
nothing
wrong
with
driving
deep,
given
that
this
is
a
this
is
a
informal
meeting,
so
we
don't
really
have
a
set
agenda.
The
other
thing
we
could
do
is
upload
up
level
a
little
bit.
I
want
to
make
sure
that
that
everybody
who's
on
the
call
who
is
not
from
red
hat
understands
this
is
not
a
red
hat
show.
This
is
just
the
initial
contribution
that
red
hat
is
making
into
the
centos
sig
show,
and
I'm
totally.
E
C
A
C
Oh
well,
I've
got
my
little
practice
pad
here.
A
little
practice.
C
A
Wouldn't
think
so,
there
was
a
great
story
when,
when
the
pandemic
first
started,
somebody
who
set
up
a
another
screen
in
front
of
the
and
they
had
filmed
themselves
being
on
a
meeting,
they
set
up
another
screen
in
front
of
their
camera
so
that
they
could
go
off
and
do
things
and
it
still
looked
like
they
were.
You
know,
being
in
a
meeting.
E
We're
going
to
use
koji
yeah,
we
have,
we
have
tag
structure
set
up
in
the
in
the
centos
koji
to
do
this,
but
I
was
what
I
was
alluding
to
when
I
said
what
clark's
going
to
do
will
make
people
happy.
That
was
not
actually
true.
What
clark's
going
to
do
will
avoid
making
well
unhappy
is
what
I'm
over
selling
it,
but
yeah
we
have
and
again.
E
This
is
this
is
inside
baseball
and
I
think
not
not
terribly
interesting,
but
we
do
want
to
make
a
clear
distinction
between
packages
that
are
built
in
this
sig
that
are
targeted
towards
automotive
versus
there's,
a
very
specific
set
of
packages
that
are
that
are
now
being
referred
to
as
sent
off
stream.
That
really
are
a
preview
of
what
is
being
contemplated
for
release
in
rel.
That's
one
of
its
key
functions,
and
we
want
to
make
sure
that
that
distinction
is
very
clear.
C
D
C
E
C
E
No
and
there's
some
great-
I
mean
okay,
so
let
me
let
me
up
level
briefly:
we've
no
reason,
there's
no
reason
why
we
wouldn't
also
encourage
p
if
people
are
okay.
So,
let's
be
honest,
we
know
that
the
the
activation
energy,
the
learning
curve
for
building
through
koji
is
a
little
higher
than
some
other
things,
and
we
do
have
a
copper
available
through
the
fedora
and
centos
projects
and
that's
a
much
you
know
a
really
easy
way
to
get.
E
Some
initial
package
builds
going,
so
we
wouldn't
you
know,
that's
not
out
of
bounds
for
anyone
who
wants
to
contribute
to
the
sig
as
well.
It's
just
that,
in
our
case,
we
wanted
to
demo.
We
want
to
from
the
get
go,
demonstrate
a
workflow
that
is
sort
of
comparable
to
what
the
centaur
stream
is
meant
to
be
for
rel,
but
is
also
clearly
distinct
and
reflects
what
we're
going
to
what
we're
contemplating
for
the
automotive
product.
So.
C
If
you
want
to
start
a
fight,
you
can,
just
you
know,
have
a
debate
on
whether
it's
copa
or
copper.
E
E
D
For
me,
the
the
point
is
that
if
you,
if
the
the
sig
wants
to
drain
some
kind
of
adoption,
then
the
the
process
should
be
easy
for
people
I
mean
you
should
know
where
your
sources
are,
what
you
have
to
push
or
where
you
have
to
push
your
spec
file,
where
the
git
package
is
something
which
is
already
documented,
and
I
mean
the
workflow
is
already
known
from
fedora
community
or
southwest
community.
So
we
shouldn't
reinvent
the
wheel
here,
but
obviously
the
components
will
be
a
lot
specific.
E
No
and
I
think
what
I'm
kind
of
orbiting
around
is
there.
There
are
right
and
proper
reasons
why
the
onboarding
of
a
package
into
the
koji
infrastructure
is
a
little
bit
more
complicated
than
building
a
package
in
copper,
and
we
don't
want
to
don't
want
to
discourage
people
from
getting
their
feet
wet
in
copper.
H
H
C
C
No,
it
doesn't,
but
he's
he's
pretty
pretty
animated
and
post
a
link
to
it.
I
guess
it
was.
E
C
E
One
is
purely
that
to
get
a
named
package
and
a
tag
set
in
koji
is
tightly
tied
to
a
package
approval
in
things
like
fedora
and
rel,
which
is
a
pretty
significant
process
and
then
there.
The
second
thing
is
just
that
the
workflow
itself
has
a
slightly
steep
learning
curve.
It's
not
that
complicated,
whereas
copper
is
entirely
self-service.
There's
no.
E
We
have
no
notion,
as
far
as
I
know,
of
a
self-service
addition
of
a
package
to
any
of
the
kogi
build
systems,
because
they're
very
carefully
curated
and
we
tie
a
bunch
of
things
together.
The
creation
of
that
name
package
has
to
have
an
owner.
It
has
to
have
a
life
cycle.
It
implies.
It
also
ties
into
the
reason
why
we're
being
advised
to
be
very
careful
about
whatever
we
build,
making
sure
that
it
doesn't
there's
no
implication
purely
by
where
it
lands
in
koji
that
it's
going
to
end
up
in
rel.
E
H
Within
you
know,
an
official
distribution,
but
if
you're
making
your
own
official
distribution
right,
it's
just
that
it's,
I
think,
there's
two
parts
to
that
right.
The
first
bit
that
you,
you
just
discussed
is
purely
a
documentation
to
to
more
clearly
and
completely
document
what
it
means
to
get
a
package
into.
H
You
know
a
quote-unquote
official
koji
and
then
end
up
with
an
artifact
up
out
the
back
end.
But
then
there's
also,
you
know
the
a
more
approachable,
more
complete
set
of
documentation
for
how
to
stand
up
your
own
environment
and
then
efforts
to
make
you
know
it
easier
to
like
more
push
button
to
stand
up
in
environment
as
well
right.
So
there's
I
think,
there's
a
few
different
efforts
that
could
make
koji
a
lot
more
approachable
and
self-service
and.
E
There's
I
mean
I'll
I'll,
give
it
an
initial
read
on
that
one
thing
we've
talked
about
and
that
steve
some
work,
some
early
work
that
steve
is
looking
at
is
that
we
would
like
to
make
it
easier
to
have
a
sort
of
plug-and-play
package
build
and
curation
solution
that
people
could
use,
and
that
would
be
for
things
that
they
wish
to
keep
internal.
E
E
It's
not
necessarily
that
everyone
would
want
to
do
that,
but
I
would
assume
that
the
workflow
for
people
who
want
to
contribute
stuff
visibly
to
the
sig
would
mirror
what
what
happens
for
people
who
own
and
maintain
packages
in
fedora
or
in
in
apple
or
things
like
that,
where
it's
pretty
typical
that,
if
I
want
to
do,
if
I'm
a
developer
that
has
in
the
zen
sig,
let's
say
I
don't
think
I
have
my
own
koji
associated
with
my
workstation.
E
But
that
doesn't
mean
that
I'm
not
building
packages
that
might
eventually
find
their
way
out
in
the
sig,
but
I'm
just
doing
it
in
the
more
individual
developer
workflow,
and
if
I
want
to
do
it
collaboratively,
I
do
it
in
the
infrastructure
that
the
sig
provides
and
I
want
it
to
be
permanent
or
semi-permanent
I'll,
do
it
there
and
then
we
can
make
it
visible.
So
from
the
sid
context.
That's
that's
what
I
would
hope
to
see.
E
I
think
what
what
steve
is
alluding
to
is
we
we
want
to
make
it
even
easier
to
spend
those
up
easy
enough
that
people
could
even
do
it
on
site
if
they
wanted
to,
but
that
should
pay
dividends
in
our
you
know.
Hopefully,
if
we
do
that
right,
the
experience
we're
having
right
now
of
adding
packages
will
be
even
easier
out
here
as
well.
That's
my
take
on
anyone
I'm
really
kind
of.
As
long
as
we
have.
E
D
D
D
You
need
koji,
because
in
koji,
kochai
and
fungi
and
and
the
rest,
because
you
need
to
assemble
everything
and
ensure
that
everything
is
is
correct
to
deliver
at
the
end
a
kind
of
release
or
snapshot
or
candidate
or
whatever
the
name
is
so
that's.
For.
For
the
I
see
that
as
the
workflow
for
integrators
in
that
case,
koji
is
necessary.
You
you
need
to
have
a
factory
somewhere
in
the
cloud
which,
which
is
shared
amongst
your
population
of
integrators,
but
on
the
other
side
as
a
source
developer,
you
want
to
minimize
the
loop.
D
I
mean
your
development
loop
should
be
only
local.
I
mean,
if
you
look
at
what
your
does
they
ship
an
sdk
which
you're
supposed
to
install
on
your
on
your
laptop
and
you
you
build,
and
you
change
your
sources
with
that
sdk
roughly
you
could.
You
could
be
the
position
where
you
build
an
rpm
and
you
you
want
to
test
the
rpm
on
your
target
right
so
and
you
so
your
loop
is
should
be.
D
In
my
opinion,
it
should
be
only
local,
but
at
the
end
one
thing
which
is
important
is
that
you
should
replicate
locally.
What
is
down
in
the
factory
I
mean
in
in
the
target
on
the
on
the
target,
the
developer
target.
If
you
have
some
containerization
technology,
you
want
to
use
to
isolate.
D
D
You
should
have
a
target
with
the
same,
the
same
setup
as
the
one
you
ship
on
your
factory,
because
at
some
at
some
point,
while
developing
your
source
and
testing
locally,
you
want
to
be
in
the
same
position
as
the
one
you
you
would
have.
If
you
take
the
image
which
is
produced
by
the
factory
at
the
end,
that's
important
because
in
that
case
you
lose
very
quickly
locally.
As
a
developer,
you
validate
your
code,
you
didn't,
have
you
don't
have
to
commit
anything
on
the
git?
D
You
still
deploy
an
rpm
somehow
on
your
target.
You
test
it
and
you
make
your
loop
and
when
you're
happy,
then
you
commit
somehow
the
sources.
Maybe
you
will
push
the
one
step
further
saying
now.
I
want
to
create
a
spec
file
and
integrate,
etc,
but
usually
what
we
see
that
the
spec
file
is
somehow
usually
it's
more
and
more
stupid,
because
you
have
your
cmak
files,
which
probably
do
most
of
the
jobs.
D
E
I
know
why
clark
is
laughing.
It's
like
the
world's
worst
part.
You
want
to
talk
about
an
example
of
bifurcation
like
it
is
curious.
People
are
trying
to
make
the
spec
file
almost
almost
an
automatic
thing.
Yeah
yeah,
where,
yes,
the
the
kernel,
is
the
notable
exception.
B
E
It's
interesting
workflow,
your
your
outline
of
that
workflow
is
really
helpful
and
it's
a
lot
of
it
sounds
familiar.
I
will
say
like
it
reminds
me
that
in
our
experience
you
know
my
limited
experience
with
the
octo.
I
think
it's
probably
still
better
placed
for
a
developer
to
have
higher
confidence
that
the
local
build
they're
doing
is
using
exactly
the
same
set
of
things
as
the
remote
build.
I
think
that's
one
of
its
strengths
and
it's
mostly
by
being
essentially
mono
a
mono
repository
at
the
end
of
the
day
or
just
a
handful
of
them.
E
D
Yeah,
even
if
yeah
you
have
to
they
try
to
do
things
correctly,
but
at
some
point
the
the
sdk
as
it's
as
it's
done
and
built
is
still
fairly
failing
on
some
points
in
my
opinion,
but
the
concepts
are
are
there
and
I
can
tell
you
what
we
did
also
one
thing
which
is
interesting
from
from
our
development
point
of
view.
D
That's
from
our
experience
in
the
in
the
automotive
grade
linux
project,
okay,
they
are
using
yokto,
but
what
we
saw
from
the
beginning
is
that
maybe
you
know
that
as
you
build
you,
you
cross
build
all
the
sources
for
your
target,
but
at
some
point
you
mix
the
native
and
the
target
architectures
and
and
files
etc.
At
the
end,
in
the
past,
there
were
some
pollution
between
the
native
and
the
target
sources,
or
you
may
have
some
pollution
between
both,
and
this
is
something
which
already
it
can.
D
You
can
have
some
pollution
and
it
also
depends
on
the
host
on
the
build
host.
So
it
depends
on
your
distribution,
and
so
what
we
saw
in
the
past
is
that,
whether
you
were
you
with
your
debian
or
ubuntu
or
fedora
on
your
host,
you
get
different
results,
even
if
you
pull
the
exact
same
layers,
okay,
because
the
pollution
can
also
come
from
the
host,
and
so
it
was
a
nightmare
to
debug,
of
course,
and
to
avoid
that
we
pushed
the
id
to
to
have
a
container.
D
D
Okay,
your
raspberry
pi,
you
also
your
qmu
or
whatever,
target,
whether
it's
real
or
virtual,
and
so
at
the
end
you
have
everything
in
the
container
and
as
a
developer,
when
you
are
in
the
ide,
you
just
a
kind
of
plug-in
to
interact
with
that
container
and
build
resources
inside
the
container,
with
rpm
build
and
the
usual
tools
right.
So
you,
if
you
look
at
what
is
inside
the
container,
you
will
see
just
some
some
normal
tools
to
build
rpms.
D
D
What's
the
version
of
the
rpms
which
are
inside
and
so
the
the
bug
reporting
is
clear
and
reproducible
potentially,
so
that's
that's
also
a
strong.
In
my
opinion,
it's
just
a
strong
element
in
the
development
workflow
which
may
not
be
necessary
for
at
the
beginning.
But
to
be
honest,
it's
a
it's
a
big
help
when
the
when
the
project
has
more
and
more
developers,
because
you
know
that
they're
working
on
the
same
platform.
E
D
Yeah
definitely
yeah.
We
have
to
yeah,
we
we
had
to
once
we
had.
We
have
some
plugins
on
top
of
rpm.
We
have.
We
tried
to
do
everything
with
plugins
inside
koji,
I'm
not
the
one
who
would
who
wrote
all
the
code
on
cody's
eye,
but
I
could
ask
my
engineers
what
are
the
parts
we
had
to
to
tweak?
But
as
far
as
I
know,
we
tried
to
do
it
to
do
it
cleanly
because
we
wanted
to.
D
We
didn't
want
to
to
maintain
strong
modifications
inside
koji
and
we
want
to
be
able
to
rebase
easily.
So
I
hope
that
everything
is
done
in
that
way.
F
C
I
think
we're
going
to
have
to
bring
out
the
the
cross
compilation,
macros
and
logic,
because
trying
to
you
know
everybody's
going
to
want
to
be
able
to
do
a
local
build.
I
mean
you're
not
going
to
want
to
have
to
say.
Oh
well,
let
me
package
this
thing
up
and
ship
it
off
to
og
to
build
it.
If
you
may
want
to
say,
I
just
need
to
try
this
one
thing:
build
it
and
trying
to
do
it
on
raspberry,
pi,
4.
C
Okay,
don't
hold
your
breath,
but
I
I
think
I
think
we're
going
to
have
to
make
sure
that
the
process
for
doing
cross
compilation
on
an
x86
64
with
a
arm
64
target
works,
and
I
haven't
done
it
in
a
while.
You
know
I
mean
it's
been
years
since
I
was
seriously
into
the
embedded
world,
and
so
this
is
going
to
be.
C
You
know
what
I'm
working
on
for
the
next
couple
of
weeks
is
saying
all
right:
let's,
let's
take
the
fedora
cross
tool
chain
for
arm
trying
to
start
cranking
out
the
real-time
kernels
that
little
boot
on
a
raspberry
pi
for
yay.
D
In
fact,
cross-building
the
kernel
is
not
maybe
the
most
difficult
part
because
right
you
don't
have
much
dependencies.
One
thing
I
recall
which
maybe
you
guys
are
trying
to
could
help
to
solve
that.
But
one
thing
we
we
have
as
soon
as
you
you
will
cross
build
things.
D
You
will
hit
the
same
issue
as
the
octo,
which
is
somehow
you
need
to
have
some
build
requires
which
are
on
native
dependencies
and
others
which
yes
target
dependencies
in
the
same
specifier
I
mean
right
and
so
in
the
semantic
of
spec
files,
you
don't
make
any
difference
between.
Obviously,
you
have
only
one
one
target.
In
fact
you
are
native,
so
you
don't
make
any
difference
between
your
native
dependencies
and
target
dependencies
and
so
right
now
what
we
did
in
that
desk.
D
We
as
we
one
one
solution,
was
to
make
the
spec
file
format,
evolve
the
schema
and
introduce
something
like
native
build,
require,
or
something
like
that.
Okay,
it
was
too
difficult
for
us
and
too
difficult
to
improve
that
to
any
upstream
project.
So
what
we
did
is
it's
it's
really
stupid,
but
when
you
build
require
something,
then
in
the
in
the
sixth
route,
we
installed
both
packages,
the
next
one
and
the
and
the
target
one
and
so
depending
on
which
one
is
picked.
D
You
always
have
the
one
which
is
right,
which
is
installed,
but
okay,
that's
something
which
is
definitely
missing
in
the
in
the
yeah
in
the
base
architecture
or
the
base
concept,
because
it's
under
some
level
or
at
the
time
where
rpm
was
created
or
designed.
We
were
not
talking
about
cross-compiling
rpms
so
but
yeah.
We,
we
may
have
some
some
some
thoughts
about
that
on
the
long
term.
Maybe
for
now
we
just
have
some
some
work
around
which
works,
but
would
be
better.
D
Yeah
we
had
to
modify
many
macros,
but
at
the
end,
that's
okay.
Hopefully
we
have
rpms
macros,
which
are
mostly
right.
Okay,.
D
And
then,
at
the
end,
to
bootstrap
things
we
had
to
patch,
let's
say
something
like
I
would
say,
800
or
something
like
that
packages.
I
mean
the
best
packages
had
to
be
attached
to
to
build
or
some
packages
don't
use
macros
typically,
but
they
should,
and
so
that's
not
a
big
deal,
but
at
on
the
long
run.
It's
it's
still
an
issue,
because
you
want
to
maintain
your
your
your
patches
on
top
of
the
peg
files
for
four
years
or
so,
but
that's
something
that
could
enter
into
into
webstream.
I
think.
D
Yeah,
I
really
encourage
you
to
take
a
look
at
red
task
and
we
publish
many
many
things
mostly
about
the
distro
by
itself,
not
much
on
the
factory
side,
because
it's
our
our
business
in
fact,
but
we
we
want
to.
We
want
to
upstream
upstream
of
few
things
because
we
don't
we,
we
don't
want
to
be
alone
to
maintain
everything.
D
So
at
some
point
yeah
we
can
open
things
and
and
definitely
centos
automotive
is
probably
the
right
place
to
do
so.
A
One
other
thing
we
could
discuss
is
hardware.
You
know
raspberry
pi
4.
It
seems
to
be
the
one
that
people
keep
coming
back
to
cheap,
cheap
and
ubiquitous
and
readily
available
to
everybody.
E
A
F
C
C
Get
a
truck,
you
know
this
is
a
vehicle
os.
We
can
get
a
truck
into
here
and
it
becomes
sentient
and
decides
to
leave
us.
Then
we've
got
the
the
absolute
best
country
song.
D
E
E
We
have
clark,
has
some
salvaged
hardware
somewhere
in
his
background
or
in
a
storage
closet
right
now
that
was
used
to
try
and
automate
the
process
of
hardware,
bring
up
in
a
collaborative
way,
as
opposed
to
the
way
that
another
person
visible
to
me
al
is
doing
it
with
the
board,
that's
on
his
desk
or
was
doing
the
board
on
his
desk.
So
I
think
you
know
we
if
we
up
level
it
and
zoom
it
out
to
that
broader
problem.
G
So
so
putting
stuff
on
your
desk
is
going
to
be
hard
for.
You
know
for
anything
much
more
than
the
pie,
but
the
other
thing
to
be
aware
of
is
the
graviton
instances
in
aws
are
phenomenal
and
there's
a
very,
very
broad
range
on
those.
So
probably
one
of
the
best
parts
about
it
is
a
lot
of
them
have
isa,
features
that
aren't
necessarily
available
in
in
some
of
these
small
dev
boards
that
we
might
be
seeing
later
on
in
auto.
G
So,
for
example,
you
know
needing
to
cross
compile
something,
maybe
toss
it
out
on
a
graviton
instance,
and
and
have
it
go?
No,
I
don't.
I
don't
know
what
that
means
from
a
centos
side.
Right
I
mean
I,
I
doubt
seriously,
there's
a
centos
account
that
we
can
just
use
and
and
and
freely
use
aws
as
much
as
we
wish,
but.
E
Not
at
an
individual
level,
no,
I
don't
think
no,
no,
which
would
be
nice,
but
no!
No,
I
mean,
incidentally,
because
it
gets
back
to
the
workflow
we're
talking
about.
On
the
other
hand,
as
a
sig
member,
you
can
probably
do
as
many
scratch
builds
on
infrastructure
that
has
native
builders
as
you
want,
but
I
would
draw
that
distinction
like
al.
What
you're
talking
about
is
basically
I
as
a
developer,
who
only
have
x86
hardware,
would
like
a
reasonably
snappy
native
64-bit
arm
or
some
other.
E
You
know
which
would
there's
some
other
architecture
in
play
and
that's
relatively
straightforward.
I
think
yeah,
the
more
the
more
challenging
activity
that's
going
on
here
would
be
hardware
bring
up
yeah.
E
G
The
other
thing
to
consider
is,
you
know,
depending
on
the
extent
to
which
acpi
and
uefi
become
standardized
in
this
space.
G
There
is
a
version
of
qmu
that
does
a
full
server-based
standard
implementation,
so
you
can
actually
experiment
with
those
things
in
qmu
on
your
desktop
and
that's
that's
kind
of
handy
qmu
is
also
very,
very
capable
when
it
comes
to
you
know
all
the
various
and
different
arm
emulations,
so
there's
a
lot
of
potential
there
and
it
wouldn't
hurt.
G
So
I
mean
there's
a
couple
possibilities
but
yeah
it's
it's
if
you
actually
want
real
hardware
to
work
with
there's,
unfortunately,
well
there's
some
nice
imx
options
as
well,
not
as
much
standardized
support
there,
but
renaissance
is
used
quite
a
bit
in
automotive,
so
that
that's
a
potential
in
videos
hard
to
say
that's
going
to
be,
I
think,
more
of
an
issue
of
availability.
G
At
present
there
are
some
dev
boards
that
are
snapdragon
boards.
If
you
want
to
work
with
qualcomm
cpus
now,
will
those
boards
look
anything
like
an
actual
automotive
product?
G
I
don't
know
hard
to
say,
but
there
are
some
nice
socs
out
there
from
like
96
ports
and
some
other
places
they're.
C
G
G
A
A
There
are
a
number
of
those
boards
that
do
have
things
like
canvas
and
other
things
that
are
that
are
interesting.
I
believe
the
new
beagle
boards,
the
latest
beagleboards
blacks,
also
can
bus
support.
I
don't
think
they
have.
I
don't
think
I
think
they
have
the
fires.
I
don't
think
they
have
the
actual
hardware.
D
But
I
can
give
you
some
some
feedbacks
from
from
agile
project
where
they
have
a
few
reference
boards,
and
and
also
they
want
to
introduce
community
boards,
as
renaissance
is
a
big
sponsor
of
a
gm.
Obviously,
the
renaissance
boards
are
are
supported,
not
all
the
boards.
In
fact,
because
you
know
renaissance,
they
sell
some
development
boards,
which
are
quite
expensive
but
full
featured.
D
D
D
I'm
not
sure
how
it's
very
well
tested,
supported
or
whatever,
but
but
still
we
build
a
gel
for
for
for
upboard
or
square
now
I
mean
I
don't
remember,
which
board
was
was
taken
as
a
reference
one,
but
it's
a
small
intel
board
based
on
atom,
which
is
still
a
good
idea
to
have,
even
if
we
know
that
we're
we
probably
want
to
to
build
for
arc64,
but
having
another
architecture
sometimes
helps.
C
From
the
sig
perspective,
it
might
be
nice
if
we
could
come
up
with
a
set
of
recommendations
for
manufacturers
to
say
hey.
You
know,
assuming
that
every
developer
is
going
to
have
a
reference
board
sitting
on
their
desk
is
not
really
realistic
these
days,
and
maybe
they
could
make
their
reference
boards
a
bit
more
remote
access
friendly,
because
I
know
we've
got
some
some
boards
in
house
that
the
only
way
to
reprogram
the
flash
is
to
actually
physically
change
a
dip
switch
to
enable
writing
stupid
thing.
D
Yeah,
so
that's
an
issue,
and
so
just
one
small
comment
regarding
what
what
it
was
albert
that
commented
just
before
from
what
I
see
in
the
embedded
world
you
as
soon
as
you
have
a
board.
You
have
a
specific
bsp
or
somehow,
maybe
they
try
to
to
make
the
same
bsp
for
multiple
boards,
but
you
always
hit
some
limits
and,
and
it
means
that
you,
for
example,
the
ufi
normalization
is,
is
enabled
on
arm
boards,
but
not
all
boards.
D
And
so,
if
you,
if
you
try,
if
you
think
that
you
you
can
unify
things
by
using
the
standard
that
I
think
it's
a
it's
no
way,
because
every
stock
vendor
will
do
what
they
want
for
for
any
given
board.
So.
D
G
D
D
Yeah
we
there
are
plenty
of
of
them
so,
but
what
I
see
is
that
it
is
it's
a
jungle.
Okay
in
in
the
intel
world,
everything
has
been
normalized
and
you
can
do
things
easily
quite
easily,
even
even
for
embedded
stuff
right
because
it
it
derives
from
what
has
been
done
in
the
server
side
and
desktop
side
right,
but
in
in
the
embedded
world
on
arm.
It's
a
it's
a
real
jungle.
D
So
at
some
point
what
we
did
just
a
hint
is
that
we
we
saw
that
the
fastboot
protocol
is
implemented
somehow
in
in
ubud
right.
A
new
boot
is
a
common
denominator
for
all
those
boards.
Even
on
intel
architecture,
you
can
run
ubud
in
in
ufi
mode,
and
so
our
idea
to
flash
the
board
is
to
enable
fastboot
on
a
specific
u-boot
incarnation
for
each
board.
So
that's
a
specific
work
for
each
board,
depending
on
the
bsp
coming
from
the
vendor.
D
But
as
soon
as
you,
you
put
your
your
own
u-boot
with
fastboot
support,
then
you're
done
and
you
can
have
a
uniform
way
of
flashing
your
boards
or
quite
uniform.
It's
not
perfect,
but
that's
the
the
first
result
we
had
very
recently
because
we
made
those
tests
last
week.
In
fact,
and
so
the
conclusion
is
that
using
fastboot
is
a
good
idea.
D
One
thing
is,
which
is
not
perfect,
for
me
is
that
fastboot
could
be
used
with
usb
or
ethernet,
and
the
usb
side
is
very
well
documented,
maintained,
etc,
because
it's
used
everywhere
in
the
mobile
world,
but
the
the
netboot
side
is
or
ethernet
way
of
doing.
Fastboot
is
not
well
maintained.
So,
but
that's
that
would
be
perfect
for
us,
because
you
can
imagine
you're
pull
off
board.
D
You
just
have
to
plug
your
serial
cable,
which
is
varying
from
one
bar
to
another
again,
but
that
that
would
be
the
only
thing
varying
for
the
rest.
You
plug
your
your
rg
45
plugs
and
you're
done.
F
G
D
G
D
G
G
How
do
we
make
sure
that
we
we
can
distribute
all
the
right
pieces
for
the
right
report
right?
C
You
know
part
of
it.
Al
is
the
is
the
functional
safety
side
of
it.
We
can
use
the
exact
same
bits
across
a
wider
selection
of
hardware.
We
have
a
stronger
functional,
so
you
know
if
we
can
use
this
it
I
mean
the
the
the
goal
from
my
perspective
would
be
to
say:
let's
build
an
arc64
kernel,
one
of
them
that'll
boot
on
a
pie
on
you,
know
an
imx
board,
a
beagle
board
or
renaissance
and
and
we
either
use
acpi
or
or
dt
to
to
describe
what
we're
on.
C
G
B
C
Be
one
kernel,
it'll
be
great,
so
so
you
know
I
mean
that's,
that's
to
me
the
the
idea
that
that
that
we
can
share
as
much
is
key
here
and
it
the
more
we
can
do,
the
better.
It
helps
the
functional
safety
story.
That
says:
look.
We've
reviewed
all
this
crap
we've
tested
the
hell
out
of
it.
You
know
it's.
G
Safe,
I
guess
I
guess
the
question
in
my
mind
is
you
know
like
like,
like
stefan
was
suggesting
with
fastboots
right.
You
know
we
can
argue
ad
infinitum
whether
or
not
that's
the
correct
solution,
but
if
we
come
across
a
solution
like
that
in
the
sig
is,
is
that
the
role
of
the
sig
or
the
individuals
to
say
look?
G
We've
got
a
solution
that
solves
this
problem
that
you
know
simplifies
the
jungle
and
at
least
you
know,
cuts
out
some
of
the
larger
trees
and
and
try
to
push
that
in
the
industry
at
large.
D
As
a
position,
which
is
not
the
same
as
the
one
we
have
as
a
single
company,
so
that's
really
the
the
organization
where
you
can
push
something
better
than
a
single
company.
I
think-
and
that
said
I
have
some
good
news
for
you
clark.
We
we
made
some
tests
recently
also,
and
we
have
a
generic-
oh,
not
so
generic
but
let's
say
a
vanilla
kernel
running
on
renaissance
and
imx8.
D
So
that's
the
same
kernel
right
yeah,
but
it
works,
but
I
think
it
can
work.
Yeah
yeah
it
works
definitely,
but
where
we
have
some
limitations
is
that
when
it
comes
to
the
term
support
for
your
kernel
on
the
specific
board,
you
can
take
a
look
at
what
renaissance
is
shipping?
D
Okay,
the
cheaper
youtube
layer,
but
besides
the
octo
layer,
they
also
have
a
kernel
and
the
kernel
with
many
patches
on
top
of
the
veneer
kernel.
In
fact
they
have.
They
have
both
activities.
They
want
to
push
the
patches
into
the
mainstream,
that's
one
of
the
main
contributors
to
the
to
the
kernel
right,
but
on
the
other
side
they
have
to
keep
some
patches
for
them
because
it's
not
accepted
yet
or
because
their
customers
need
the
patches.
But
it's
not
in
the
value
kernel.
So
yeah
you
need.
D
You
have
two
categories
of
patches
and
somehow,
if
you
want
to
go
a
bit
further
with
your
board,
you
will
need
those
specific
patches
in
your
kernel.
So
that's
the
limitation,
but
I
would
say
it
could
be
the
same
for
for
for
intel
architecture.
C
D
So
that's
the
limit,
but
that's
a
good
good
news
still,
because
if
you,
if
you
look
in
the
past,
when
we
were
talking
about
arm
32
bits,
that
was
a
nightmare
right
really
a
nightmare
now
you
can
have
a
single
kernel,
booting,
your
your
single
architecture,
and
you
may
have
maybe
the
gtb
that
changes
from
one
bar
to
another
and
even
in
renaissance,
what
we
managed
to
to
do
very
recently
again
it's
to
have
a
single
kernel
for
a
or
a
family
of
boards,
which
is
already
hard
to
achieve,
but
clearly
on
the
ci
side.
A
Back,
I
don't
know
if
everybody
sees
there's
an
active
discussion
about
hardware
going
on
in
the
chat
as
well
parallel
to
this,
so
I'm
definitely
gonna
hold
on
to
this
and
save
it
so
that
we
can
noodle
on
it
and
maybe
bring
it
up
at
the
formal
meeting
in
a
couple
of
weeks.
C
Sounds
like
we
need
to.
Maybe
next
sig
meeting
come
up
with:
what's
our
chat
platform
or
platforms,
and
so
we
can
carry
these
discussions
over
and
argue,
and
you
know
I
would
vote
for
irc
but
then
again
I'm
an
old,
reactionary,
honey.
C
This
is
the
place
for
us
to
to
continue
the
discussion.
A
Yeah
all
right,
so
let's
aim
for
that
and
keep
talking
about
it
and.