►
From YouTube: CentOS Automotive SIG - June 7, 2023
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
A
So
the
one
of
the
nice
exciting
things
I
wanted
to
announce
is
documentation
on
heritage
heritage,
of
course,
is
our
lightweight
container
orchestration
system.
There
is
now
a
significant
amount
of
documentation
at
heritage.readthedocs.io.
A
It
is
automatically
generated
and
it
looks
gorgeous
so
and
it
has
some
getting
started.
Information
out
there,
so
please
go
have
a
look.
The
other
thing
I
wanted
to
mention
is
that
on
June
16th
this
year
in
what
two
weeks
week
and
a
half
Devcon
dot,
CZ
will
be
happening
in
brno
in
the
Czech
Republic.
There
are
a
number
of
Automotive
talks.
I
believe
they
will
all
be
recorded.
I'm
not
totally
certain
about
that.
A
But
if
you
happen
to
be
in
the
region
and
want
to
go,
it
would
be
an
excellent
place
to
go.
Learn
about
Automotive,
stuff
and
containers
in
cars,
particularly
haircut.
A
B
Okay,
a
taboo
window,
your
entire
screen,
so
a
window
I
suppose,
okay,.
B
Can
see
it
yeah,
okay,
so
I'm
going
to
talk
today
on
how
we
do
the
maintenance
of
board
spot
package
and
especially
the
one
we
are
putting
out
of
yokto
and
how
we
we
maintain
different
embedded
boards
based
on
the
Asante,
has
source
code
and
especially
in
RPM,
using
OG.
So
on
this
picture
you
don't
see
an
automotive
engines.
This
is
a
boat
engine.
B
Okay,
it's
it's
a
100
meter,
Long
Boat,
it's
a
in
fact:
it's
a
tuna
fishing
boat,
so
we
have
a
little
more
space
than
we
typically
have
in
the
car.
Okay,
it's
a
little
bigger,
quick
word
about
us.
We
located
in
Brittany
South
Brittany
on
the
arbor
city,
name
laurion,
which
is
a
very
famous
racing
boat.
B
So,
in
order
to
start
on
how
we
we
are
looking
and
and
working
on,
the
you
know,
migrating
in
between
Santos
and
yocto
and
use
RPM
or
layers,
and
how
we
maintain
all
of
that,
it's
important
to
come
back
on
few
facts.
So
if
we
look
for
Santos
Automotive
today,
it
is
based
on
santoso
stream
9,
which
is
a
rolling
distribution.
A
Linux
kernel
is
a
5.14.
B
We
have
regular
update
with
cbfix
and
you
support
two
architectures
today
in
Thailand.
B
If
we
look
for
the
production
side,
at
least
at
iot
visit
date,
we
derive
from
directly
from
ground
9,
so
it's
more
or
less
the
same
thing,
except
that
we
have
obviously
a
different
roadmap
and
we
have
more
stability,
but
at
the
end
of
the
day,
from
a
coding
point
of
view,
it
is.
It
is
exactly
the
same
thing.
B
B
There
is
a
plan,
obviously
to
move
to
to
next
release
and
current
version
is
going
to
be
end
of
life
roughly
in
one
year
from
now.
Linux
kernel
is
a
5.10
okay,
so
that's
so
we
see.
The
shift
is
not
that
big.
In
fact,
in
between,
you
know
what
we
have
in
Santos
and
what
we
have
in
the
embedded
World,
obviously,
depending
on
the
board,
we
have
different
version
of
Kernel,
but
I
would
say
at
least
for
recent
board.
B
We
rarely
have
a
huge
shift
now
if
we
look
for
what
has
been
modified
okay
and
what
is
going
to
create
us
trouble
when
we
we
want
to
move
to
the
RPM
world.
We
have
two
things:
okay,
the
first
one
is
the
ones
that
are
the
original
recipes
that
we
have
in
YouTube,
so
mostly
in
BB
file
for
some
specific
component
of
the
hardware.
B
Obviously
we
have
the
Linux
kernel,
which
is,
as
I
said,
before,
a
specific
version,
which
is
a
typically
a
line
on
YouTube,
but
we
also
have
some
some
core
tools,
and
especially
we
have
the
arm
trusted
firmware.
We
have
the
u-boot,
we
have
Opti
and
we
have
few
other
things
like
your
U
Dev
rules
as
stress
and
so
on.
B
Most
of
the
graphic
is
also
specific,
especially
the
acceleration
which
is
going
to
impact
a
library
like
Elite,
gbd,
egl
or
GLS,
and
so
on.
So
here
again
it's
not
that
we
have
100
specific
code,
but
we
have
some
specific
plugins
that
we
have
to
to
recompile,
for
those
libraries
under
multimedia
at
Lord
is
a
nightmare
okay,
because
in
multimedia
you
have
a
lot
of
specific
codecs.
You
have
a
lot
of
proprietary
stuff.
You
sometimes
have
some
specific.
B
You
know
accelerator
as
well,
and
very
often
they
are
not
open
source
okay.
So
it's
a
kind
of
mix
where
you
have
a
binary
blob.
That
is
proprietary
and
you
have
to
understand
how
you're
going
to
to
to
to
align
that
with
your
open
source
stuff.
So,
but
at
the
end
of
the
day,
I
would
say
this
part
is
relatively
clean.
Okay,
because
everything
is
in
a
BB
file
and
you
only
touch
really
what
is
specific
to
the
bsp.
So
what
is
necessary
to
run
your
Hardware?
B
You
have
most
different
steps
that
are
kind
of
not
really
part
of
the
bsp
but
are
influenced
by
the
bsp,
and
this
is
everything
that
is
in
between
the
kernel
and
the
user
space
world.
So
things
like
systemd
might
be
one,
but
also
sometimes,
and
curses
QA
new
GCC,
where
you
may
have
some
specific
option
for
your
compiler
and
obviously
connectivity,
and
we
already
talked
about
the
graphic
and
the
multimedia.
B
B
If
we
look
how
we
build
that,
so
we're
using
we're
using
Koji-
and
you
know
all
the
like-
the
red
App
Suite-
that
we
have
integrated
within
a
single
Factory
to
hide
the
complexity
from
users.
But
I
would
say
we
have
main
input
on
the
left.
So,
as
we
said,
we
have
the
Octo
bsps
that
we
use
as
input,
but
we
also
sometimes
have
native
bsp
when
we're
lucky.
Okay.
B
So
in
this
case
we
we
don't
have
a
YouTube,
but
we
have
a
native
bsp
or
we
have
an
Android
bsp
and
typically
we
have
a
lot
of
Upstream
softwares
that
we
have
to
download.
So
you
know
GTC,
gdpc,
MySQL
and
so
on.
B
You
know
also
different
package
sets
that
make
a
Linux,
so
rich,
I
would
say
most
of
the
company
have
some
specific
middleware
that
you
also
have
to
compile
and
you
have
to
tune,
for
you
know
a
specialist
security
model
for
for
your
given
hardware
and
at
the
end
of
the
day
you
have
the
user
application,
and
so
you
want
to
shake
all
of
that
and
you
want
to
maintain
that
automatically
for
10
or
15
years.
Okay,
because
typically,
this
is
what
the
customer
is
asking
for.
B
B
So
the
good
point
is
that
we
see
the
kernel
version
are
not
fully
aligned
but
they're,
very
close,
Okay
and
I
just
wrote:
it's
not
true
for
all
vendors
okay,
because
we
also
have
some
boards
that
are
still
running
version
three
of
Linux,
and
so
it's
a
little
tougher
to
to
move
to
a
modern
kernel.
But
we
have
some
bad
point
and
and
I
would
say
it's
the
hardest
for
us
is
that
some
base,
OS
components
have
been
modified
by
the
vendors.
Okay
and
YouTube
is
very
cool
for
that.
B
Okay,
because
in
YouTube
you
can
change
anything
at
any
time
from
anywhere
or
less
okay.
So
then
you
have
to
track
down
who
made
the
modification
where
it
was
done
when
it
apply
and
I
just
take
one
example.
Typically,
if
you
need
to
have
a
specific
you
Dev
rules
to
support
a
specific
device,
the
clean
way
is
to
create
an
extra
configuration
that
is
specific
to
that
device
without
touching
to
udav3.
B
But
this
is
really
how
people
are
doing
it.
Okay,
most
of
the
time,
what
they're
going
to
do
is
they're
going
to
add
directly
in
the
udav
config
file
from
a
VB
app
and
layer
which
is
making
your
heart
your
life
a
little
harder
when
you
have
to
transfer
stuff
from
one
word
to
another.
One,
okay
and-
and
this
model
obviously
is
a
highly
discouraged
when
you
work
with
a
standard
distribution
like
Santos
and
I,
would
say.
Also
more
and
more
customers
are,
you
know,
forbidden
us
from
doing
so.
B
Okay,
they
want
to
have
a
a
clean
separation
in
between
what
is
standard
and
coming
from
the
main
line,
and
what
is
specific
to
a
given
board
and,
as
I
already
said,
we
have
some
integration,
especially
graphic
multimedia
and
trusted
modules,
that
most
of
the
time
raise
some
specific
issues,
because
you
have
a
property
blob,
and
so
you
have
to
deal
on
how
you're
going
to
to
derivative
this
and
how
you're
going
to
maintain.
You
know
this
binary
blobs
that
typically
never
change
with
everything
else.
B
That's
discharging
not
every
day,
but
very
often,
okay.
So
when
you
you,
you,
you
start
looking
on
how
you're
going
to
move
to
RPM
from
YouTube.
The
first
thing
you
have
to
check
out
is
your
kernel:
config
your
kernel
path,
your
bootload
or
firmware,
and
your
bootloader
patch,
okay,
and
you
have
to
do
a
clear
separation
in
between
what
is
coming
from
the
Upstream
world
and
what
is
specific
to
a
given
board
and
have
a
a
clear
way
to
handle
what
what
is
official
and
what
is
your
custom
pad.
B
And
then
you
have
to
create
a
specific
spec
file
for
that.
So
what
we've
done
at
iot
is
we.
We
started
from
the
the
spec
file
of
Fedora
kernel,
okay,
that
we
simplified
okay,
so
we
we've
done
some
Cleanup
in
there
and
especially
we
moved
everything
that
the
user
has
to
change
into
macro
in
such
a
way
that
when
you
open
your
template,
you
only
have
few
lines
where
you
need
to
edit
and
chance
things.
Okay,
so
we
see.
B
On
the
left
hand,
we
have
the
empty
template
and
on
the
right
hand
we
have
what
we
have
to
to
pull
in
the
template.
So
typically,
we
have
to
obviously
place
the
the
version
put
the
URL
where
we
download
the
kernel
from,
and
so
it's
very
limited
what
you
have
to
do.
In
fact,
you
move
from
the
template
to
the
to
the
spec
file,
so
even
if
you're,
not
a
spec
File
Expert,
normally
it's
relatively
easy
to
do
that.
B
B
Okay,
it's
a
config
file
from
kernel
and
we
see
here
the
different
element
we
have
for
a
kernel,
so
the
service.json
is
a
file
that
allows
you
to
download
everything
you're
going
to
need
to
build
your
kernel
because,
as
I
said,
we
we
have
to
do
that
today,
but
we
should
also
be
able
to
do
it
in
10
years
from
now.
So
you
have
to
make
sure
that
you
have
everything
in
hand
to
rebuild
your
kernel.
Then
you
have
typically
your
kernel
spec.
B
That's
your
spec
file
and
you
have
a
few
configurations
specific
to
your
kernel,
but
I
won't
say
it
is
short
because
if
we
look
for
a
real
example
later
we'll
see
that
we
we
have
few
things
in,
but
it's
not
too
complex
at
the
end
of
the
day,
the
kernel
is
not
a
big
part,
in
fact,
in
in
the
bsp,
at
least
when
you
have
all
the
the
driver
to
support
your
Hardware,
and
when
this
is
done,
then
what
we
do
is
the
the
kernel
is
only
one
specific
application
from
a
project
and
the
project
is
a
bsp
okay,
and
so
when
we
look
for
the
different
application
in
between
double
quotes
that
we
have
in
a
bsp.
B
Obviously
you
have
the
kernel.
You
have
a
the
bsp
repo,
that's
specific
to
our
organizations.
This
is
where
this
is,
where
you
go
to
download
extra
module
for
your
board
when
you
do
update
and
so
on.
So
this
is,
it
could
be
included
somewhere
else,
but
we
we
implement
it
as
a
standard
application,
and
you
have
obviously
The
Trusted
firmware
for
most
of
the
board.
B
You
have
the
configuration
that
is
specific
to
your
board,
so
in
this
case
the
sample
is
a
solid
run
board.
So
this
is
a
nxp
component.
B
B
So
that's
one
element
So,
you
you're
not
willing
to
boot,
a
kernel
that
is
not
signed
correctly
and
also
you
have
to
assign
uboot
with
the
specific
tools
provided
by
the
vendor,
to
make
sure
that
your
board
is
going
to
accept
to
boot
your
uboot
okay,
because
you
you
have
a
two-step
boot.
First,
you
boot
you
boot
and
then
your
boot
is
booting
the
kernel.
Okay.
B
So
that's
for
like
a
quick,
a
quick
Vision
on
how
it
works.
So
now
what
I
propose
is
we
can
go
on
the
on
a
real
example.
So
may
I
share
I'm
going
to
share
a
tab?
Okay,
okay,
so
dashboard.
So
this
is
a
factory.
So
this
is
our
interface
to
Koji,
okay.
So
this
is
a
community
version,
so
you
you
only
need
a
GitHub
account
to
connect
onto
it.
If
I
connect.
B
Okay,
you
see
that
you,
you
just
need
a
GitHub
account
to
connect
and
you're
in
and
I'm
going
to
look
for
my
different
projects.
So
this
is
a
pretty
empty
one,
because
I
I
made
it
for
for
this
talk.
So
the
first
thing
we
see
is
the
template.
So
this
is
what
I
told
you
about
before.
So
that's,
typically
something
you
import
in
your
environment
to
have
an
empty
template
that
you
start
to
to
fulfill
and
from
this
template
you
build
your
own
project.
B
So,
if
I
look
for
my
project,
I
can
see
here
the
different
elements
that
we've
seen
in
the
slide
before
so
I
have
my
firmware.
My
trusted
firmware
I
have
my
u-boot
my
kernel
and
the
repository.
Where
is
you
know
the
different
URL
and
potentially
also,
we
may
have
here
some
initial
certificate
to
enable
the
board
to
to
download
stuff
from
your
repository.
B
Let's
have
a
quick
check
on
what
we
have
here
so
in
in
this
part,
we
see
we
have
very
little
things
I'm
going
to
make
that
bigger.
We
see
that
more
or
less.
This
is
coming
directly
from
nhp
and
we
only
have
very
limited
amount
of
specific
command
to
build
that
this
example
is
relatively
simple
because
in
this
case,
u-boot
is
not
signed
and
there
is
no
test
to
verify
that
you're
allowed
to
load
the
firmware.
B
Obviously,
if
the
firmware
had
to
be
signed
by
some
specific
vendor
tools,
it
would
be
a
little
more
complex.
Okay.
If
we
look
for
the
other
application,
we
talked
about
u-boot.
If
we
look
for
the
different
thing
we
have
in
your
boot,
so
a
new
boot.
Typically,
obviously
we
have
the
spec
file.
We
have
a
u-boot
configuration
some
extra
flag.
We
talked
about
some
binary
blobs
that
need
to
be
included,
because
this
board
is
a
is
an
nxp,
solid,
run
board
and
we
have
some
specific
firmware.
B
We
also
have
a
patch
to
support
smack
okay,
because
in
this
example,
we
are
not
running
SC
Linux,
but
we're
running
smack.
So
if
we
were
running
SC
Linux,
we
would
have
a
patch
for
Acer
Linux
and
we
have
a
correction
for
some
bugs
they
have
okay.
So
typically,
this
is
what
we
have,
and
this
is
the
spec
files
that
we
use.
Okay
and
this
spec
file
when
we
executed
is
going
to
produce
us
some
RPMs
that
we
see
here.
Okay
and
this
RPM
is
something
you
install
obviously
on
on
your
board.
B
Okay,
let's
look
for
the
last
one
that
is
important
to
us,
the
kernel
in
the
kernel.
We
have
different
files.
Obviously
the
most
important
one
is
the
source
code
of
the
kernel
that
is
obviously
extracted
from
git
directly
potentially
most
of
the
time.
You
also
have
some
tags
that
you
have
to
apply,
and
then
you
have
obviously
the
configuration
for
your
your
your
kernel,
which
is
typically
you
know
the
config
xmls
that
we
have
in
a
menu
config
on
Linux,
so
nothing
rocket
science.
There.
B
B
When
you
have
done
your
your
bsp
project,
then
you
have
to
make
something
you
can
Boot
and
for
that
you're
going
to
do
an
image,
and
so
the
image
is
slightly
different,
because
the
image,
in
fact,
is
the
started
from
a
Kickstart.
So
it's
not
a
spec
file,
but
it's
a
Kickstart.
It
is
also
the
red
hat
tooling
that
we
are
using
for
that,
and
so,
if
I
look
in
my
image
and
I
check
for
the
advanced
setting
I
see
that
my
spec
file
is
here.
B
Okay,
so
that's
my
my
initial
Kickstart
example,
and
here
again
you
I
would
say
it's
a
relatively
complex
because,
depending
on
the
board,
the
initial
image
you
have
to
boot
you,
you
always
have
to
do
some
fine
tuning
on
where's
your
partition.
How
you
want
to
to
share
your
disk-
and
you
know
a
lot
of
different
things
like
that,
but
there
is
very
little
maintenance
on
that.
B
Okay,
when
it
is
in
place,
it
does
not
move
okay
and
at
the
end
of
the
day,
obviously,
you
may
have
some
specific
projects.
B
So
here
we
only
have
a
demo
on
on
modbus
and
typically,
what
you're
going
to
do
is
this
application
is
either
going
to
be
included
within
your
image
with
your
bsp,
in
which
case
when
you
build
your
your
bsp,
your
image,
you
take
the
kernel,
the
bsp
and
your
application,
or
you're
going
to
build
this
application
as
a
container
and
you're
going
to
have
more
kind
of
immutable,
operating
system
and
you're
going
to
upload
your
application
as
a
container
okay.
B
So
this
is
when,
when
you
create
a
project,
you
see
you
can
create
either
a
standard
project
like
we
have
for
the
bsp.
You
can
create
an
image
project,
as
we've
seen
in
the
example
where
we
want
to
have
something
bootable
and
you
can
obviously
import
product,
but
we
could
also
create
a
container
project.
One
thing
I
forgot
to
show
you
is
this
in
the
image:
if
I
go
here
and
I,
look
for
the
build
okay
and
I.
B
Look
that
I
see
that
here
we
we
have
effectively
the
the
final
image,
which
is
what
you're
going
to
boot
on
your
boat.
So
bmap
is
a
special
format
that
allow
you
to
to
remove
the
Zero
from
from
your
distribution,
so
it
makes
the
upload
faster.
Okay
from
a
timing
point
of
view,
that's
something
we
did
not
check,
but
that
also
has
some
some
interest.
B
If
I
look
here
for
that
and
I
look
for
my
kernel
and
I
look
for
the
build,
we
see
that
the
build
of
the
kernel
took
20
to
22
minutes.
So
it's
a
pretty
long
operation,
and
this
is
on
the
community
stack.
Obviously,
if
you
build
it
on
a
commercial
stack,
it
might
go
faster
depending
on
you
know
how
powerful
is
your
machine,
but
nevertheless
you
don't
you're
not
willing
to
rebuild
that
every
every
half
an
hour?
B
Okay,
it
takes
a
lot
of
time
and
but,
as
I
said,
we
normally
don't
change
it
much,
except
obviously,
when
we
have
a
new
fix
that
are
coming
from
from
the
main
line,
or
eventually
from
the
vendors,
but
most
of
the
times,
they're
coming
from
the
vendors
okay.
So
that
was
for
the
demo,
let's
finish
very
quickly,
with
the
slide
text
that
I
had
was
here,
so
we
were
here.
B
So
what
is
important
in
fact,
is
not
only
how
you
build
your
initial
kernel,
but
also
how
you're
going
to
maintain
that
for
10
or
15
years,
knowing
that,
whatever
you
do
and
how
generic
you're
willing
to
be,
you
still
have
some
key
components
that
are
going
to
remain
specific
because
of
the
customer
configuration
because
of
the
specific
Hardware
because
of
some
security
constraints,
blah
blah
blah.
So
there
are
thousand
of
reasons
why
you
have
some
specific
things.
B
B
When
your
bsp
is
in
place,
then
you
want
to
use
the
Kickstart
model
or
something
else,
but
we
use
Kickstart
for
that
to
assemble
your
bsp
with
a
version
of
operating
system.
You
want
run
and
potentially
with
some
middleware
as
well.
If
you
have
any
immutable
operating
system,
you
probably
have
some.
You
know
container
engine,
for
example,
that
you
want
to
be
at
that
level
and
also
most
of
the
time
we
have
some
application
at
minimum.
B
We
have
from
security
and
supervision
application,
but
even
very
often
we
have
also
some
other
application
and
from
that
you're
going
to
generate
this
animage
and
you
want
to
have
the
capability
to
update
the
image,
and
so
this
is
the
beauty
of
RPM
and
that's
a
very
strong
point
compared
with
yakto,
because
it's
very
easy
to
build
RPM
and
to
keep
up
to
date.
Your
your
image,
okay.
So
as
a
conclusion
YouTube,
you
have
one
or
more
layers.
You
have
one
more
one
or
more
providers.
B
You
can
modify
everything
at
any
time
from
anywhere
and
there
is
no
long-term
support.
Okay
and
we
could
add
other
things
like
it's.
It's
also
a
very
long
to
rebuild
stuff.
Okay,
because
it's
often
we
build
everything.
If
you
move
to
the
to
the
RPM
world,
you
have
one
project
per
VSP,
so
it's
a
much
cleaner
approach.
You
have
it's
a
standard
user
project,
so
there
is
no
difference
in
between
a
bsp
project,
an
application
project,
a
container
project,
an
image
project.
B
All
of
that
is
underlying
the
same
way.
All
the
modification
are
handle
through
git.
So
you
can
keep
you
know
your
modification
under
control.
Obviously
you
have
a
team
and
user
management,
so
you
can
decide
who
is
allowed
to
read
to
write
to
test,
to
upload,
to
release
and
so
on,
and
you
have
a
long-term
support
with
automatic
update.
I,
don't
say
everything
is
automatic,
okay,
otherwise
we
would
be
more
richer
than
we
are,
but
you
you
can
optimize
the
the
clearly
the
modification
and
the
update.
Okay.
B
This
is
where
we
are
working.
So
we
are
about
to
see.
If,
however,
you
want
to
sell,
don't
hesitate.
Okay,
we
we
have
a
boat,
so
it's
a
always
a
pleasure
to
to
receive
people
and
I
just
had
a
few
links.
As
I
said,
the
community
versions
that
are
I
use
for
my
demonstration
is
publicly
available,
so
you
can
play
with
it.
You
can
run
your
application.
You
can,
by
default
on
the
community
version.
I
think
we
support
to
the
six
boards.
B
So
we
have
running
Stars
nxp
solid,
run
Intel
and
we
also
have
a
lot
of
other
board,
but
there
are.
They
are
much
harder
to
buy
because
they
are
specific
to
some
customers,
so
we
did
not
add
them
into
the
Community
Edition.
But
if
you
have
some
specific
words
you're
interested
in,
let
us
know
we're
going
to
add
TI
pretty
soon
as
well,
because
we've
done
support
for
the
Sitara
board
as
well.
Okay,
so
that's
it
for
me.
B
Yeah
not
only
we
run
or
so
we
we
have
multiple
instance
of
Koji.
We
have
one
that
is
Project
community
that
we
are
running
we
we
have
runs,
that
is,
for
commercial
customers
that
use
a
share
instance,
and
we
also
have
some
private
instant
for
some
customers
that
either
run
in
all
infrastructure
or
directly
on
premises
with
a
customer.
I
would
say
most
of
the
customer
are
a
big
customer.
B
You've
seen
the
name,
okay,
values
talentes
to
tell,
and
those
people
are
not
ready
to
share
a
lot
of
things:
okay,
maybe
in
the
future,
but
not
today.
So
for
that
reason
most
of
them
want
to
have
a
private
instance.
So,
typically,
what
happened
is
during
the
proof
of
concept
phase.
Once
you
do
the
evaluation,
they
often
run
in-house,
so
we
run
the
their
stack
in
all
premises
and
when
they
want
to
go
to
production,
they
want
to
transfer
everything.
In-House
I
would
say:
that's
a
typical
model.
B
Yeah
I'm,
not
sure
it's
going
to
last
for
a
long
time.
Okay,
I
I.
We
see
some
more
and
more
people
wanted
to
run
stuff
on
the
cloud,
but
it's
still
pretty
complex
here.
C
Another
question
be
that
do
we
do
you
manually,
create
just
spec
files,
or
do
you
have
some
kind
of
alternating
tooling,
from
York
to
recipes
to.
B
I
would
say
it's
a
kind
of
in
between
okay.
In
fact,
we
have
two
models
when
we
want
to
integrate
a
bsp
first,
if
we're
willing
to
implement
a
quick
act
going
really
fast
or,
for
example,
we
have
a
bug
in
RPM
and
we
want
to
reproduce
the
burgundy
octo,
because
the
board
is
still
under
a
guarantee,
and
so
we
want
to
send
it
back
to
the
vendor.
Okay,
in
this
case,
what
we
do
is
we
use
doctor
to
produce.
B
We,
we
kill
big
bait
as
the
RPM,
and
we
revise
the
metadata
of
the
YouTube
RPM
to
to
fake
Koji
and
sokoji
things
that
they
produce
it
produce
the
RPM
when
this
fact
is
not
true,
okay,
so
that's
a
kind
of
quick
ad
when
we
are
willing
to
compare
binary
version
produced
by
octo
running
on
your
stack
as
mostly
for
a
quick
test
or
for
bug
report.
B
Okay,
we
have
a
second
element
where
we
we
stop
bit
bake
at
the
early
phase
of
the
bill
so
just
before
it
builds
and
we
retrieve
the
different
parameter
and
options
that
they
would
use
for
building
and
we
wrinkle
pour
that
in.
B
In
the
spec
file,
but
to
be
honest
with
you
all
those
tools
that
we've
wrote
at
the
early
day
of
the
project,
now
that
we
have
this
templated
mechanism
are
not
that
useful,
because
you
know
you,
you
look
inside
so
inside
YouTube
layer
and
you
just
take
the
different
parameters
and
options,
and
you
just
translate
them
in
your
template
and
most
of
the
time
it
is
faster.
Okay,
as
I
say,
because
you
have
to
write
everything
everywhere.
Okay-
and
you
know,
anyone
in
a
BBE
happened-
can
change
the
configuration
of
the
kernel.
B
Okay,
it's
not
like
you
have
the
configuration
at
the
one
single
place.
So
the
only
way
the
only
way
to
really
know
what
YouTube
is
going
to
do
is
by
starting
date
back
and
looking
for
the
final
result.
Okay.
So
so
I
would
say
it's
a
kind
of
semi-manual
process
or
semi-automatic,
depending
on
you
know
whether
you
want
to
look
positive
or
negative
yeah.
One
thing
I
forgot
to
told
you
about
Koji.
B
We
also
modify
Koji
because
we
do
a
crossbuild
okay,
and
so
we
did
not
have
to
modify
the
core
of
Koji
because
Koji
has
plug-in.
So
we
implemented
plugins.
We
had
many
countries
where
that
people
on
that
side,
when,
when
we
did
that-
and
in
fact,
as
today,
none
of
our
customers
are
willing
to
buy
a
arm
server.
Okay,
because
the
ID
is
not
ready
for
that,
and
so
best
case
what
we
can
get
when
we
run
into
a
big
customer
infrastructure.
B
Is
they
give
us
some
VMware
instance,
and
so
we
have
to
run
with
whatever
they
have.
The
second
reason
is
something
I
did
not
talk
about,
but
when
you
develop
application,
people
are
willing
to
develop
not
on
the
factory,
because
that's
a
pretty
long
process.
They
want
to
develop
from
their
laptop
and
typically
the
laptop
or
Intel
machine.
So
you
also
need
to
have
a
crossbuild
for
your
your
your
Intel
laptop
system,
yeah.
So
so.
For
that
reason
we
also
had
to
transfer
G
yeah.
B
I
will
be
honest
with
you
is
not
me
who
produce
plugins,
so
yeah,
yeah,
I,
suppose
this
is
where
they
are
yeah
but
yeah.
It's
not
new,
wrote
them
and
as
we
we
wrote
a
kind
of
a
Gateway
or
front-end.
On
top
of
all
your
Reddit
tools.
Okay,
we
we
have
a
single
API
to
access
all
your
services,
so
we
don't
really
see
a
directly
Koji
and
one
of
the
motivation
for
that
is
Koji
does
not
handle.
B
Well,
the
fact
that
you
have
multiple
users
with
different
access
right
on
who
can
do
what
so
we
had
to
implement
the
access
control
layer
on
top
of
Goji
and
before
Koji.
There
is
also
a
second
of
kind.
Historical
reason
is
that
in
the
past
we
we
were
using
OBS
because
we
also
did
Kaizen.
You
know.
B
Tizen
operating
system
was
built
by
my
team
and
it's
based
on
OBS,
and
so
when
we
shift
it
to
Koji
I
taught
my
guy,
maybe
in
the
future,
we'll
have
to
change
again
and
so
I
don't
want
to
to
be
dependent
on
any
vendor
API.
So
so,
for
that
reason,
I
I
would
say
we
don't
really
see
except
few
guys
that
are
working
at
a
very
low
level.
Most
of
the
people
don't
really
see
Koji
yeah,
even
if
I
would
be
honest
with
you
sometime,
we
have
bergway.
A
Okay,
yes,
thank
you
very
much
Philip.
It
has
been
a
a
really
really
interesting
discussion
to
see
how
all
this
comes
together.
Okay,.
B
Thank
you
for
your
time,
an
operation
yeah,
you
just
try
it
and
if
you
have
issue,
we
have
support
on
metrics
or
on
the
sentos
mailing
list
and
we'll
be
most
unhappy
to
respond.
Yeah.