►
From YouTube: CNB Weekly Working Group: 2021-11-11
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
An
account
that's
associated
with
with
the
the
google
channel,
so
just
send
a
google
account
email
address
and
then
we'll
add
you
to
the
list.
C
B
All
right
reminder
again
to
sign
into
the
document.
If
you
haven't
already
and
we'll
kick
off
with
new
faces,
I
don't
know
aidan
I've
seen
you
before
in
one
of
these.
B
Yes,
I
think
so
I
no
longer
remember
what
I
go
to
and
what
I
don't
go
to
got
it
sorry.
I
wasn't
sure
all
right,
we'll
move
to
release
planning
and
updates.
B
Oh,
I
can
speak
for
implementation.
We
are
trying
to
get
out
the
next
version
of
life
cycle
in
the
next
day
or
two.
I
was
just
trying
to
look
at
all
those
steps
that
need
to
happen
to
cut
the
release
with
natalie
out
and
if
I
can
perform
all
those
without
question,
I
will
try
to
do.
B
A
On
the
platform
side,
I'm
not
I'm
not
sure,
there's
much.
I
believe
we
released
packs
since
the
last
time
we
met,
but
it
was
around
the
same
time
frame.
So
I
apologize.
If
I'm
repeating
myself
there,
the
pack
o
22,
went
out.
C
Don't
think
there's
anything
new
on
the
back
side,
daniel's
been
helping
out
with
the
v2
stuff.
I
think
there's
an
alpha
branch
that
we
merged
this
logging
changes
to,
like,
I
think
you
probably
put
out
an
rfc
for
structured
logging
in
like
in
buildback,
so
that
there's
a
consistent
output
from
buildbacks
in
different
languages
and
different
ecosystems.
B
So
we'll
jump
to
our
first
rfc
to
chat
about
this
week.
Add
images
table
to
project
top.
D
Yeah
we,
I
don't
think
we
do.
I
I
added
this
sort
of
on
their
behalf.
It's
mostly
just
a
nudge
to
take
a
look,
the
folks
that
created
this.
I
worked
them
a
little
bit
on
it,
but
for
the
most
part
they
created
it
they're,
I
think
in
europe
or
something
so
they're
not
gonna,
be
able
to
make
these
meetings
see.
I
just
didn't
just
take
a
look
and
provide
feedback,
so
we
can
work
on
that.
Async.
B
D
Yeah,
I
think
I
think,
there's
two
goals
of
the
rfc
one
is
to
codify
the
image
name,
even
if
you're
just
building
a
single
image
or
tagging
it,
it's
not.
Actually,
it's
not
building
multiple
images.
It's
multiple
image
tags,
but
one
part
is
to
codify
that
so
that
you
don't
have
to
write
it
down
every
time
and
then,
potentially,
you
can
override
just
the
tag.
D
You
know
the
colon
part
of
it
or
the
registry
part
of
it
or
something
like
that,
and
then
the
other
problem
at
solving
is
just
having
multiple
distinct
tags:
labels,
whatever
right
term
is
there.
B
A
So
it's
if
I
wanted
to
essentially
put
it
into
docker
hub
and
also
gcr
the
final
output,
app
image.
D
B
A
Yeah,
I
personally
feel
like
you
should
be
able
to,
though
right.
I
know
that
it's
not
optimal.
B
B
I
think
the
rebuild
case
is
really
interesting
with
multiple
registry,
because
if
you
don't
have
some
of
the
layers
locally,
that
you've
rebuilt
and
they're
only
on
one
registry,
you'd
have
to
pull
the
extra
layers
or,
like
you
know,
stream
them
from
one
registry
to
another.
I
think
ggcr
is
has
some
very
nice
features
around
making
this
easier,
but
it
is.
D
I'm
not
sure
how
important
the
multiple
registries
in
a
single
build
are.
So
maybe
we
should
add
that
as
feedback
on
the
rfc
that
like,
if,
if
that's
not
actually
the
problem,
they're
they're
after
we
can
d
scope
the
rfc
to
be
just
because
I
think
really
what
they're
after
is
like
codifying
the
image
name
and
then
overriding
parts
of
it
specifically
like
the
latest
or
whatever
the
tag.
D
A
Is
it
pack
specific
cause?
I
mean
if
I'm
trying
to
throw
it
into
like,
I
don't
know,
google
cloud
run
or
something
or
git
lab
right.
I
would
expect
this
operation
to
still
be
true
that
these
images
are
created.
D
D
Okay,
I
mean
I
so
like
I
I
care
less
about
whether
it's
pac
specific
and
more
about
like
the
experience
and
for
most
people
like
they're,
using
pac
somewhere
in
their
workflow,
and
it
is,
I
think,
especially
when
you're
specifying
like
really
long
image
names
like
I
know
for
for
us
internally.
We
have
like
these
epic
image
names
with
the
repository
and
everything,
and
you
end
up
just
like
it's
a
bad
experience,
end
up
copying
and
pasting
it
around
and
it'd,
be
nice
to
codify
that
in
the
project
tunnel.
B
I
I
think
it'd
be
helpful
to
see,
even
if
this
is
like
really
a
life
cycle
feature
they're
asking
for
it'd
be
helpful
to
see
what
the
pacquiax
they'd
want
to
accompany.
This
would
be
because
if
it's,
if
it's
like
pack
build
and
then
you
provide
one
registry
or
one
tag
and
then
some
other
tags
get
exported,
that
seems
really
weird.
If
it's
like,
when
you
have
these
fields
in
project
tunnel,
then
pack
doesn't
need
a
name
anymore
and
it
you
know
instead
uses
the
images
table
and
then
what
happens?
B
C
I
think
that's
like
the
general
form
I
have
with
project
descriptor
where
it's
optional,
and
then
you
get
into
this
weird
cases
where,
if
the
platform
is
explicitly
providing
one
of
these
options,
what's
the
precedence,
what
happens
if
there
are
multiple
tags?
What
happens
if
there's
a
single
tag?
You
still
use
the
others
and
then.
A
I
think
to
me
that's
easier
to
solve.
If
you
have
that
sort
of
president
right-
and
I
think
typically,
it's
been
any
user
input,
trump's
any
sort
of
predefined
configuration,
but
I
think
what
stephen
brought
up,
because
I
mean
I'll
step
back
and
say
unpack.
We
already
allow
for
multiple
image
tags,
they
provide
the
name
and
then
they
could
add
additional
tags.
A
So
that
already
exists
and
now
it's
moving
it
into
the
project
descriptor.
But
then
you
know
in
one
of
them:
it's
decomposed
in
the
project
descriptors,
what
they're
proposing
and
on
the
other,
one
it's
not,
and
then
how
do
they
interact
when
one
is
provided
as
a
name,
but
then
there's
additional
images
configured
in
the
project
descriptor.
I
think
that's
an
interesting
case.
B
D
Okay,
yeah,
I'm
kind
of
taking
down
notes
on
some
of
what
you're
talking
about.
I
think
we'll
just
start
with
some
of
the
really
concrete
feedback
like
the
multiple
registries
and
wanting
to
see
the
pack
experience
and
things
like
that
so
but
definitely
add
like
we.
We
have
to
do
this,
one
async,
so
good.
It's
a
good
test
of
our
ability
to
do
that.
So
please
comment
in
there.
B
Thinking
also
we're
about
a
quarter
through
we've
got
four,
so
maybe
we've
begun
to
move
on
yeah
yep.
No,
that's
fine
sounds
good.
Next
one
is
186,
run
images
bomb.
I
think
I
think
I
forget
who
recommended
we
put
this
one
on
here.
I
don't
know
anthony
if
you
have
comments
this
week.
C
E
Hope
you
don't
mind
if
I
speak
on
this.
So
last
time
we
talked
about
this.
There
were
a
couple
outstanding
as
well.
There
were
more
than
a
couple,
but
there
were
two
major
outstanding
issues.
I
do
want
to
cover
the
first
one
here.
I
I
think
steven
expanded
on
it
pretty
well
here.
Basically,
the
idea
is,
you
know,
we're
adding
a
stack
s-bomb
right
and
do
we
want
to
distinguish
between
a
build
and
launch
right,
like
you
know,
theoretically,
somebody
might
want
both
build
and
launch
in
the
final
output.
E
Let's
just
say
you
know
we
live
in
that
world,
but
then
steven
had
an
idea
like
then
you
get
into
the
case
where
you
can't
use
the
same
image
for
build
and
launch
because
you,
you
know
you
have
this
sort
of
distinguishing
thing
here.
So
what
if
we
use
the
first
eight
characters
of
the
digest
instead
right
that
way,
you
know
they
don't
collide
if
you
chose
to
put
them
in
the
same
image,
what
I
just
wanted
to
bring
it
up
to
the
group.
E
If,
if
we
had
strong
opinions
on
this,
I
mean
I
know
at
first
glance,
I
just
thought
it's
a
little
bit
more
work
on
the
author
side.
To
I
don't
know,
just
just
I
mean
it's
possible,
it's
just
you
know
I
I
don't
know
if
it's.
B
I
can
speak
to
my
suggestion
there
a
little
bit
too.
The
part
of
this
was
I
was
thinking
about
the
docker
files
rfc
and
how
this
is
going
to
work
when
you,
you
know,
have
multiple
layers
of
you
know
like
you
built
that
s-bomb
and
then
you're
running
a
docker
file
over
it,
then
you're
going
to
regenerate
the
s-bomb
again
this
way,
every
every
file
generation
is
content
addressed
and
right.
B
You
can
like
afterwards,
you
can
figure
out
exactly
which
you're
never
going
to
get
confused
about
which
s-bomb
mapped
to
which
base
image
during
the
generation
process,
so
that
that
and
that
I
don't
think
we
should
have
a
strong
differentiation
between
a
stack
image.
That
is
just
a
build
image
just
to
run
image
anymore.
B
B
What
do
you
mean
like
like
when
you're
generating
that
s-bomb
layer
right?
You
know
what
image
you
calculated
the
s-bomb
layer
for,
and
so
you
you
know
that
the
thing
that
generates
it
would
would
include
the
digest.
B
It's
the
digest
of
whatever
you're,
taking
an
s
bomb
off
or
like.
If
you
have
a
multi-stage,
build,
there's
still
there's
still
an
image
that
contain
the
software
that
you
are
taking
s
bomb
on.
That
has
a
digest.
B
Like
you
already
can't
use
a
multi-stage
build
for
it
right,
because
you
can't,
I
thought
we
talked
about
this
before
like
there's
in
order
to
attach
the
s-bomb
to
the
image.
You
couldn't
just
use
a
multi-stage
docker
file,
because
you
need
to
attach
a
label
right
that
references,
the
layer,
and
so
you
already
are,
like
you
already
can't
end
up
in
the
final
format
anyways.
So
we
have
to
make
another
tool,
and
so
it
doesn't
seem
like
it's
a
more
of
a
disadvantage.
E
Well,
that
was
actually
the
second
outstanding
question
which
we
didn't
resolve
last
time
we
could
roll
it
up
into
here.
I
don't
know
I
I'm
just
gonna
recall
my
sentiments.
I
think
it
opens
up
a
lot
of
things
that
you
have
to
account
for
right,
like
if
you're
doing
extensions,
then
you
have
to
keep
sliding
the
layer
down.
You
know
it's
just
sure
you
can
make
it
work,
it's
just
it's
just
a
lot
of
extra
code
pass.
I
think
that
you
have
to
code
for
that.
Those
are
my
thoughts.
C
A
But
aren't
there
operations
that
generate
layers
that
may
have
no
impact
or
effect
on
the
s
bomb.
C
Sure
I
I
think
the
only
instruction
I
can
think
of
is
worked.
That's
what
I
was
thinking
about
as
well.
That's
pretty
much
the
only
thing
I
can
think
of
and
generates
layers,
don't
just
just.
A
E
A
B
I
I
think
I
agree
that
it
seems
cleaner
to
keep
the
s-bomb
label
as
the
or
the
s-bomb
layer
as
the
last
layer
or
like
like.
I
don't.
I
don't
have
a
problem
saying
if
it's
not
really
difficult
to
do
that,
but
it's
a
nicer
organization
for
what
the
image
should
look
like
or
something,
but
I
feel
like
it's
too
loose
of
a
contract
to
not
have
a
label
on
it.
That
says
how
to
pull
it.
B
If
that
makes
sense
like
I'm
just
thinking
even
in
ggcr
like,
I
think
it's
not
that
hard
to
get
an
ordered
list
of
the
layers,
but
it's
much
easier
to
just
grab
a
layer
by
its
digest
right
and
it
feels
like
it's.
I
don't
know
I'm
trying
to
think.
If
there's
like
a
some
way,
you
could,
you
know
trick,
like
you
know,
try
to
get
an
extra
layer
of
pen
at
the
end.
That
has
a
wrong
s-bomb
right
that
wouldn't
be
obvious
in
a
build
process
where
a
label
would
be
safer.
B
I
don't
know
it.
It
strikes
me
as
not
not
a
strong
enough
contract,
especially
for
a
security
feature.
If
that
makes
sense
again
really
if
I
were
trying
to
get
the
s-bomb
out
of
an
image,
I'd
really
like
to
see
metadata
on
the
image
like,
I
can
check
the
image
signature
validate
that
find
a
label
that
says
exactly
the
s-bomb
is
encoded
in
exactly
this
digest,
pull
that
you
know
blob.
That
has
you
know
just
that,
digest
in
it
and
then
you
know,
maybe
that's
also
signed
right,
like
the.
B
It
could
be
either
I
actually,
I
was
thinking
about
that
for
this
one
like
if
you're
building
it
with
a
local
docker
demon,
it
might
not,
it
might
be
expensive
to
find
what
the
digest
layer
is,
because
you
have
to
compress
it
first,
since
we
might
want
to
use
a
diff
id,
but
both
are
available.
When
you
look
at
the
image
right
like
you,
can
the
manifest
has
the
digest
and
you
can
pull
the
config
blob
and
then
translate
that
to
a
different
d.
B
E
B
Awesome,
I
think
I
I
recommended
we
use
the
diff
id
for
that
one.
But
then
I
said
digest
on
the
earlier
one
when
I
should
have
said
fid
for
the
name
of
the
file,
because
it's
different
than
what
the
label
points
to,
but
but
yeah.
C
B
It's
it's
also
called
image
id.
That's.
A
B
What
the
the
label
is
for
a
layer
right,
it
tells
you
what
layer
to
go
to
the
the
id
for
this
represents.
What
is
the
like?
What
what's
the
input
of
the
image
right
like
right?
What's
something
representative
of
the
thing
you
took
a
an
s
bomb
of
and
so
that,
when
especially
so
that,
when
you
end
up
with
an
image
in
the
end,
you
can
have
separate
files
for
the
build
to
run.
B
C
So
if
this
is
going
to
be
happening
outside
of
the
container
running
the
image
you
can
like,
the
whatever
tool
creates
the
build
and
run
images
can
just
run
like
create
the
image.
Then
you
do
back
attaches
form
and
point
it
to
a
file
locally
and
to
the
image
and
then
pack,
those
the
rest.
The
only
weird
thing
around
this
whole
thing
is
how
it
interacts
with
your
doctor,
five
rfc,
like
the
gen
packages
stuff.
C
B
So
the
we've
said
that
the
run
image
doesn't
necessarily
correspond
to
the
base
image
of
the
final
image
right,
and
so,
when
you
generate
an
app
image
at
the
end,
we
can
exclude
layers.
I
think
we
do
this
already.
I
think
there's
some
run
image
layers
that
don't
make
it
into
the
final
image,
but
I
forget
which
ones
so
as
long
as
gen
packages
is
a
separate
layer,
then
we
can
guarantee
that
the
gen
packages
itself
doesn't
end
up
in
the
application
image.
So.
A
A
B
C
B
So,
but
before
we
said
that
we
could,
we
were
going
to
include
the
lifecycle
at
the
front
image.
This
is
where
that
came
from
before
we
said
we're
going
to
include
the
lifecycle
in
the
run
image,
so
they
could
run
stack
packs
in
the
run
image,
and
then
we
just
exclude
it
exclude
that
life
cycle
layer
and
export
it
into
the
final
image
and
so
for
gen
packages.
We
could
do
the
same
thing.
B
C
Like
let's
say
you
have
a
scratch
image
and
you
you're
putting
a
couple
of
libraries
on
there.
C
It's
I
don't
know,
I
don't
know
what
kind
of
user
experience
would
it
be
to
like
have
those
like
regardless
like
for
this
rfc.
I
think
what
we
talked
about
makes
sense,
where
the
s
bomb
generation
would
be
an
external
process.
I
don't
see
that
happening.
It
happening
inside
the
container,
that's
running
the
front
image
or
the
build
image.
I
think
it's
most
probably
going
to
be
an
external
process.
B
Yeah
for
this
rfc8,
I
agree,
can
run
inside
of
the
yeah.
You
know
image
and
that's
how
I
imagine
gen
packages
would
usually
work
as
you,
you
throw
sift
and
just
no
script.
That
runs
sift
on
the
base
image,
but
if,
if
the
dockerfile
rfc
needs
to
change
to
do
that
externally,
I'm
not
I'm
not
opposed
to
exploring
it
that
it's
possible
to
do
that
in
a
portable
way.
But
the
portable
part
is
the
challenge.
B
C
C
Yeah,
I
I
don't
think
dawn
can
run
inside
the
image,
but
it
can
mount
like
it
can.
It
can
communicate
while
the
build
is
running,
but
it
still
runs
outside
the
regardless,
like
we,
we
need
a
better
ux
for
the
other
one.
This
one,
I
think,
is
fine.
If
we
just
do
like
a
back
attaches
form
and
have
an
externalized
form
file,
we're
just
attaching
to
the
final
image
for
the
other
one.
I
think
we
still
need
something
better
for
the
run
image
for
the
build
image.
A
And
I
guess
one
more
little
chime
in
for
something
I
was
thinking.
I
think
I'm
liking
a
lot
more.
The
image
digest
side
of
things
or
aspect,
even
though
it
adds
some
complexity
like
we'll
have
to
kind
of
know
that
there's
a
cost
for
the
daemon
use
case
in
which
we
have
to
compute
that
digest.
A
But
I
think
long
term.
We
want
to
get
rid
of
the
the
daemon
functionality
of
the
way
that
it
currently
exists,
but
I,
the
other
benefit
that
I
could
also
see,
is
that
if
we
ever
wanted
to
shift
to
that
sort
of
side,
card
image
or
artifact
kind
of
using
digest
is
what
we
would
do
right
like
it
would
be
predictable
of
where
we
would
find
the
s-bomb
for
any
particular
thing.
So
I
think
that's
pretty
pretty
good.
C
I
think
when
we
move
to
that
case,
where
we
don't
have
the
game
and
at
all,
we
would
probably
be
on
like
the
cosine
or
the
osa
artifacts
case,
where
we
don't
have
to
deal
with
all
of
this.
We
can
just
reference
the
image
in
in
an
annotation
from
the
airspun
artifact.
So
I
I
don't
once
we
get
there
there
it's
much
easier.
I
think
it's
stay
intermediate.
B
You
know
merge,
cosine
s
bomb
or
you
know,
whatever
format
that
we
looked
into
in
the
future
right.
B
C
B
C
C
That's
what
cosine
does
right
now
you
give
it
an
image
in
the
sbom
file
on
disk,
and
it
will
try
to
attach
that
as
form
without
mutating.
The
original
image,
which
is
another
issue
we'll
face
here
like
whenever
we
attach
this
one
we'll
be
mutating
the
original
image.
So
it's
going
to
be
again
harder
to
have
like
guarantees
that
this
s-phone
describes
this
image.
B
E
Figure
out
our
assignment
exactly
sorry,
we
know
we
are
two-thirds
of
the
meeting
here.
You
know
I
just
want
to
make
sure
we
have
room
for
the
other
topics,
but
you
know
I,
you
know
there
was
an
original
question
here
about
you
know
digester
or
not.
E
B
C
C
I
mean
regardless
the
the
two
concerns
I
have
here
are
like
one:
if
we
attach
the
s
form
to
the
image
we'll
be
mutating
its
digest.
So
just
I
don't
know
how
that
place.
That
was
one
of
the
deciding
factors
for
like
small
attachment
on
the
cosine
rfc
and
also
what's
being
proposed
with
those
artifacts
is.
C
How
do
you
attach
these
things
without
mutating
the
image
that
it's
describing,
because
that
might
cause
some
other
security
issues
and
then,
if
you're
generating
it
in
the
image
itself,
then
it's
going
to
be
harder
to
get
rid
of
the
tool
that
generates
the
s
moment
from
the
final
output
image.
So
those
are
the
things
we
should
be
careful
about.
B
We
came
up
with
a
particular
format
that
we
have
to
use
for
the
app
image,
because
the
layers
have
to
move
with
the
the
build
pack
layers
have
to
move
with
the
image
I'm
worried
about,
creating
like
a
lot
of
divergence
and
how
we
store
s
bomb
in
different
cases.
It's
also
very
convenient
if
the
s
bomb
is
already
on
the
run
image
and
the
format
it
needs
to
be.
When
you
do
a
rebase
or
you
know
like
how
do
we
ensure
that
the.
C
I'm
like
for
the
rebase
stuff,
the
cosine
format
might
actually
make
it
easy,
because
it's
just
a
pointer
that
says:
okay,
this,
this
image
is
like
this.
So
if
you,
if
you
update
your
base
image,
we
already
update
the
pointer
to
the
base
image
in
the
output
lifecycle
metadata
and
you
can
derive
the
s
pump
for
the
base
image
from
just
that
pointer.
You
don't
need
any
other
information,
so
in
terms
of
rebase
for
the
lifecycle,
it
doesn't
have
to
do
anything.
B
C
B
Just
need
you're,
saying,
preserve
the
pointer
of
the
the
cosine
sign.
C
I
mean
not
preserved,
like
the
new
image
will
have
a
new
digest
I'll
have
a
new
pointer
to
the
s
bomb.
You
don't
have
to
do
anything
on
the
life
cycle
side
just
do
rebase
as
we
currently
do
it.
It's
just
that
the
cosine
convention
will
automatically
mean
that
whatever
point
we
put
for
the
neuron
image
automatically
has
a
bomb
attached
to
it.
B
B
But,
but
does
the
relocate
thing
account
for
it's
like
it's
like?
If
you,
if
you
relocate
a
signed
image
to
another
registry,
you
look
like
a
lot
of
relocation
tools.
Look
for
the
cosine
signed
artifact
that
corresponds
to
that
app
image
right.
B
But
now,
if
the
app
image
relies
on
a
pointer
to
a
different
image
and
that
images
are
like,
if
you
have
to
find
the
base
image
of
you
in
order
to
find
the
s-bomb
for
your
ab
image,
part
of
it
requires
looking
for
the
a
reference
to
its
previous
base
image
and
finding
the
signature
of
that
based
image.
You
know
in
a
separate
third
image
in
order
to
then
that
wouldn't
get
relocated
with
the
app
image.
C
C
C
C
C
Does
that
make
sense?
So
you,
when
you
add
the
s1
you're,
just
adding
one
file,
so
you
also
have
to
validate
that
that
file
is
the
only
file
in
the
layer.
There's.
No,
no
other
things
added.
That's
part
of
that
last
operation,
because
you
could,
you
could
add
other
random
things
alongside
the
desk
form
that,
like
over
there
on
top
of
the
files
you
had
in
your
original
image,
and
then
you
use
that
right.
B
B
Maybe
we
should
keep
arguing
in
the
issue.
I
don't
want
to
eat
up
all
the
time
on
this.
E
Okay,
I
was
going
to
say
the
same
thing,
but
but
I
do
have
the
issue
pinned
for
next
time,
at
least
or
if
you
guys
want
to
put
it
in
the
issue.
That'd
be
appreciated.
B
Awesome
next
one
is
officially
supported
utility,
build
packs.
D
A
D
Fcp,
so
I
think
I
think
I
put
a
date
on
there.
I
think
I
made
it
two
weeks
accidentally,
though
suppose
fcp
is
one
week
right.
D
C
D
Yeah
I
merged
those.
I
thought
that
was
fine.
I
didn't
think
they
changed
the
spirit
of
it.
Much
I
mean
I
guess
like
so
sam
it
added
should
have
for
latest
api
version
and
a
couple
other
things
which
I
think
is
fine
like
we
don't
like.
D
We
obviously
don't
want
those
things
to
fall
behind,
but
I'm
not
sure
we
need
to
be
in
a
like
when,
when
a
life
cycle
comes
out
or
when
a
new
api
version
comes
out,
I
think
there
will
be
a
like
a
lagging
process
of
bringing
pack
and
everything
up
to
the
latest
version.
So
I
think
that's
why
it's
fine
to
have,
as
opposed
to
must.
D
D
Oh
cool
yeah,
so
it's
in
fcp,
I
think
it
actually
yeah.
It
has
all
the
votes
so
take
the
next
week
to
add
any
final
comments
or
review
review
if
needed.
D
Yeah,
so
the
next
one
is
system
build
packs,
which
is
like
the
follow
up
from
the
officially
supported,
build
packs.
This
is
179
pr.
179
there's
already
been
a
bit
of
discussion
on
this,
but
essentially
the
proposal
is
for
a
new
table
in
builder
tomml,
for
for
builder
image
that
allows
for
system
pre
and
system
post
build
packs,
and
these
are
build
packs.
That
would
be
so
well.
D
All
right,
I
think,
we're
done
then
thanks.
Everybody.