►
From YouTube: Working Group: September 20th, 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).
B
A
We
start
by
sharing
my
screen.
Oh
just
speak
of
people
trickling
in
could
I
get
a
designated
Note
Taker
for
today.
A
I
can
see
if
I
can
leave
comments.
While
we
go.
A
A
Let's
get
started
there,
I
don't
see
any
new
faces,
but
I'll
leave
a
second
all
right.
Let's
go
ahead
and
get
started
with
outstanding
rfcs.
A
First
up
we
have
decouple
dependencies,
RSC
I've
kind
of
made
like
lateral
Headway
on
this.
Insofar
as
one
of
the
rfcs
that
I
opened
the
RCI
opened
yesterday,
around
standardizing
dependency
metadata
is
sort
of
a
way
to
remove
some
of
the
like
I
guess,
like
complication
from
this
RFC,
because
it's
trying
to
sort
of
tackle
like
how
do
we
do
dependency
metadata
and
how
do
we,
then
you
know
decouple
that
dependency
metadata
from
the
rest
of
the
build
pack.
A
A
After
that,
we
have
a
proposal
to
introduce
new
growl
VM
Bill
pack,
I,
don't
see
anyone
from
the
Java
contingent
here
and
it
sounds
like
there's
some
work
that
is
happening
on
the
Oracle
front,
to
sort
of
get
this
over
the
line,
so
I
think
that
we
can
move
on
from
that
which
leads
to
the
two
new
rfcs,
both
of
which
I
opened
over
this
last
week,
and
so
I
would
like
to
go
over
them.
First
up,
we
have
codifying
the
creation
of
new
maintainer
groups.
A
This
was
spawned
from
a
discussion
that
we
had
a
couple
weeks
ago
with
Ozzie
around
trying
to
potentially
set
up
a
new
maintainer
group
to
maintain
UPI
components,
and
so
he
was
asking
like
well.
How
do
we
set
up
a
new
maintainer
group
and
I
realized?
There
wasn't
process
to
do
so.
So
this
was
my
attempt
at
setting
that
up.
A
There's
some
discussion
here
with
Dan
makuza
already
one
and
one
of
the
sort
of
driving
reasons
with
you
know,
Ozzy
asking
to
be
able
to
potentially
set
up
another
group
to
maintain
several
groups
that
are
across
like
across
different
maintainer
groups.
I
think
Dan
has
some
objection
to
that
idea.
A
A
A
A
It's
pretty
straightforward,
like
the
kind
of
motivation
is
that
we
have
a
couple
of
projects
that
are
going
to
force
us
to
like
update
our
metadata,
in
particular
like
the
introduction
of
arm
and
the
removal
of
stacks,
as
well
as
having
like
discussions
on
like
removing
that
dependency
metadata
from
the
bill
packs
themselves,
and
so
it
seems
like
kind
of
a
good
time
for
us
as
a
Mike
paquetto
project
to
potentially
set
our
own
standard
for
what
dependency
metadata
should
look
like
I'm,
also
hoping
that
this
will
be
like
a
good
first
agreed
thing
for
the
paquetto
project
for
us
to
like
start
building
some
sort
of
set
of
standard
tooling
around.
A
A
It's
pretty
straightforward.
It's
currently
missing
and
Dan
pointed
this
out
and
I
just
haven't
had
the
time
to
add
it.
It's
currently
missing
source
checksums
and
like
Source
Uris
I,
think
that
those
will
Pro
I'm
I'm,
trying
to
figure
out
exactly
where
those
will
end
up
on
the
list.
I
think
they
will
probably
be
optional.
A
However,
I
imagine
most
of
the
optional
things
that
we
have
on
here
will
be
done
by
our
you
know
like
our
project,
so
maybe
it
doesn't
make
100
sense
to
call
them
optional,
but,
like
that's
sort
of
where
I
am
right
now
and
there's
also
some
discussion
around
like
what
would
it
mean
if,
like
like?
What
does
it
mean
by
having
what
to
have
like
the
OS,
be
you
know
the
OSB
required
there's
some
discussion
that,
like
you,
know
certain
Java
jars,
they
don't
care
at
all.
A
What
OS
are
running
on,
because
they're,
you
know
compiled
completely
independent
of
the
operating
system,
so
it
doesn't
really
make
sense.
You
might
still
want
to
be
able
to
have
that
so
there's
some
stuff
going
back
and
forth
in
there
and
then
I
have
some
open,
unresolved
questions
right
now
that
there's
some
already
some
comments
on
as
well.
But
yeah
are
there
any
questions
about
this.
B
Yeah
I
had
two
things.
The
first
one
is
when
you
had
mentioned:
The
Source
URI
field.
B
The
first
thing
that
came
to
mind
was
that
we
should
probably
make
that
required,
because
it's
like
a
very
important,
probably
piece
of
the
like
s-bomb
metadata,
that
we
provide
for
our
dependencies
like
where
they
come
from
upstream
and
those
checksums,
so
I
would
I'm
just
weighing
in
while
I
have
you
rather
than
you
know,
leaving
a
comment
on
the
RFC.
But
definitely
you
think
that
those
fields
should
be
required.
B
B
I
only
gave
this
RFC
a
quick
scan,
but
I
saw
that
maybe
you
had
proposed
potentially
creating
like
a
spec
for
these
changes,
so
that
we
have
like
a
official
place,
that
people
can
go
and
like
see
what
the
set
of
metadata
is,
which
I
think
would
be
a
good
idea,
but
I
guess
related
to
that.
Do
you
have
any
thoughts
on
what
we
would
say?
B
The
timeline
is
for
adopting
this
new
format,
because
I
could
totally
see
us,
like
you,
know,
approving
this
new
metadata
format
and
then
like
not
half
the
project
adhering
to
it
and
then
half
the
project
not
moving
over
to
it,
because
it
requires
a
lot
of
changes
to
you
know
pack
it
and
jam
and
all
of
our
like
different
tooling.
That's
like
caught
up
in
these
different
fields,
so
I'm
just
wondering
if
you
think
that
we
should
include
like
a
definitive
timeline
for
picking
up
this
change.
Yeah.
A
So
I
want
to
I
want
to
address
both
of
those
comments.
The
first
one
around
Source
URI
I,
really
want
to
try
and
be
as
deliberate
as
I
can,
with
the
use
of
optional
here
and
I'm
doing
that,
to
kind
of
like
future
proof,
this
a
little
bit
not
necessarily
like
100
but
like
I,
think
that
once
we
have,
this
format
decided
it's
going
to
be.
A
The
format
that
is
also
used
in
the
decoupled
dependency
and
part
of
the
hope
of
decoupled
dependency
is
allowing
third-party
vendors
to
more
easily
provide
their
own
dependencies
to
build
packs.
So
having
only
the
fields
that,
like
like
I,
agree
with
you
that
something
like
Source
URI
is
incredibly
important
to
our
build
packs
and
what's
why
we
would
keep
them
in
order
to
build
out
s-bombs.
A
But
if
s-bombs
are
less
important
to
you
than
being
able
to
supply
your
own
dependencies,
it
would
might
be
annoying
to
have
to
be
like
oh
I
have
to
post.
Some,
like
you
know,
URI
here,
just
so
that
I
can
get
past.
Like
you
know,
I
can
meet
the
API
for
this
and
then
the
the
second
part
of
your
question
is
a
bit
of
a
two-parter
I
I.
A
Don't
know
that,
like
I
know
that
the
word
spec
has
like
actual
technical
meanings
when
you
go
into
like
projects
and
I'm,
not
100,
confident
on
what
those
are
so
like,
like
like
it's
like
a
specification,
but
for
like
a
lot
of
Open
Source
projects
that
has
like
real
implications
for
the
kind
of
document
that
is
so
I
I.
It's
maybe
more
like
I
think
I
have
here
like
an
API
document
like
like
in
order
to
conform
to
the
best
practice
API
for
paquetto.
A
You
should
look
like
this
or
whatever
I
I,
don't
know
exactly,
but
I
think
that
your
question
around.
How
do
we
actually
like
enforce
this
upgrade
is
an
interesting
one.
I
think
that
we
would
be
able
to
like,
like
on
the
on
the
non
non-java
side.
We
would
be
able
to
do
something
like
Leverage
Jam
to
automatically
convert
a
bunch
of
these
like
billpack
Thomas
to
the
new
format.
A
I
think
that's
something
that
we
could
look
into
for
sure,
but
I.
I
also
think
that
this
is
something
that
a
piece
of
commentary
or
like
a
question
that
Dan
has
asked
like
having
an
actual
implementation
strategy
and
I
I.
Guess
I'm
I'm
a
little
unsure
exactly
how
to
do
this
other
than
like,
like
I,
don't
know
what
to
make
the
forcing
function
and
like
in
some
ways
like
I,
think
that,
like
the
removal
of
stacks,
is
like
a
pretty
strong,
forcing
function.
A
If
we
say
like
hey,
when
you
do
the
stack
removal
work,
you
also
have
to
now
conform
to
the
build
packs,
because
that's
like
this
is
the
only
this
is
now
the
only
build
packs
Tomo
API
that
is
like
has
consideration
for
the
things
that
stack
removal
is
going
to
require,
and
so
I
think
that
that
might
be
like
the
forexing
function,
but
I
need
to
like
sit
and
think
about
how
to
encourage
implementation
more,
which
is
why
I
also
was
was
like.
A
Does
it
maybe
make
sense
for
us
to
build
a
tool
that
uses
this
that,
like
that,
like
uses
this
format
and
then
like?
Try
and
embed
that
tool
into
like
where
it
would
be
needed
in
like
a
jam
and
lib
pack
or
not
Jam
excuse
me
packet
and
lib
pack
so
that,
like
the
way
to
do
this
is
like
merging
those
things
then,
and
then
the
library
is
the
forcing
function
but
I
I
haven't
I,
haven't
quite
figured
that
out
yet.
B
Well,
yeah,
that's
fair!
We
can
engage
in
further
conversation
on
that
on
the
RFC
and
see
what
people
think,
but
on
the
whole
that
sounds
like
a
decent
plan.
I
like
the
coupling
it
with
the
stack
removal
work
potentially
as
well.
A
Yeah
because
I
think
that's
going
to
be
something
that
we're
going
to
have
to
face
soon,
so
we
should
probably
actually
so
someone
should
and
by
saying
someone
I'm.
Probably
volunteering
myself
should
look
into
what
is
actually
entailed
in
doing
a
stack
removal
upgrade
yeah
and
some
of
the
problems
that
might
come
with
that.
C
So
I
had
a
couple
of
other
thoughts.
Firstly,
we
do
say
that
in
our
Roc
is
that
if
you
provide
a
dependency,
you
must
provide
Nussbaum,
so
I
think
we're
like
A-Okay
to
require
you
to
provide
the
source
checks
and
Fields,
or
we
need
to
write
new
RFC
to
midcast
bombs
optional.
C
So
that's
that's
just
like
a
small
thing
as
far
as
the
timeline
in
general,
unless
it's
like
a
really
clear
timeline,
I,
don't
think
we
put
timelines
for
implementation
on
rfcs
like
I,
think
it
was
an
RFC
around
like
deprecating
or
sunsetting,
the
Ubuntu
bionic
stuff,
but
that
had
like
a
very
hard
and
very
well-defined
deadline.
Upstream
in
general,
we
don't
put
deadlines
on
like
implementing
rfcs,
so
I,
don't
think
we
should
treat
this
one
necessarily
differently.
D
E
A
For
sure-
and
we
have
like,
let
me
see
if
I
can
pull
this
up.
A
There
we
go
a
little
slow
this
morning,
no
all
right
hold
on
whatever
there's.
Let
me
pause.
My
screen
share
real,
quick
and
I'll
pull
it
up.
There's
like
the
the
community,
repo,
obviously
and
I,
think
that
in
that
yeah
there's
there
it
is
of
course
it's
like
the
third
thing
that
I
look
for
it
has
this:
it
has
this
style
guide
in
it
right
now,
and
maybe
style
guide
is
like
to
light
of
a
of
a
word
or
or
of
a
structure
for
this,
but
like.
C
I
think
there's
two
things
there
right
like
I
think
this
is
the
style
guide
for,
like
I,
think
I.
Think
after
a
person
is
definitely
I,
think
there
was
value
in
the
spec
Beyond
Bill
pack,
authors
I
think
it's
helpful
for
people
who
are
like
consumers
of
Bill
packs,
maybe
they're
writing
like
s
bomb
browsing
software,
I,
don't
know
right
like
there's
stuff.
C
That
I
think
would
be
really
helpful
to
look
to
be
able
to
reference
in
a
really
like
clear,
paquero.io,
docs
page,
in
addition,
maybe
to
sort
of
like
a
style
guide
or
something
right
anyway.
It's
minor
feedback,
it
wouldn't
block
the
RFC.
We
can
obviously
just
do
it
afterwards.
We
don't
need
an
RFC
to
update
the
documentation.
I
just
wanted
to
like
kind
of
think
about.
Where
can
we
post
this
once
we
call
it
a
spec
right?
Where
can
we
post
that
so
that
it's
useful
for
people?
A
A
A
E
A
Hello,
we
were
just
about
to
close
up
going
over
the
rfcu's.
Is
there
any
update
that
you
is
there
any
update
that
you'd
like
to
give
on
the
multi-arch,
build
packs
or
any
questions
you
have
about
existing
rses.
E
No
I
have
not
made
any
progress
on
the
stacks
work
that
I'm
doing
so.
There's
no
update
there,
but
hopefully
very
soon,
awesome.
A
In
that
case,
then,
we
can
go
into
our
next
item,
which
is
CNB
updates
and
questions.
Only
update
that
I
have
is
pac0.31.0
is
live.
Probably
the
only
interesting
thing
to
anyone
here
is
that
it
allows
you
to
label
build
packages,
so
you
can
add
any
number
of
custom
labels
to
your
build
package.
When
you
do
your
pack
build
pack
create
or
build
package,
create
I,
don't
know
it's
it's
one
of
those
so
yeah,
that's
the
only
big
change
I
can
think
of
for
this
week.
E
Quick
question
I
joined
late,
so
you
might
have
already
talked
about
this,
but
the
standardized
paquetto
depth,
metadata
format
is
that
also
part
of
the
RFC
that
you
opened
it's
at
a
different
RFC.
A
Well,
the
the
like
decoupled
dependency
stuff,
yes,
it
it's
like
it's
like
related
insofar
as
like
a
component
of
that
was
updating
what
the
metadata
format
would
look
like
and
we've,
because
we've
stalled
out
a
little
bit
on
exactly
what
needs
to
happen
in
terms
of
like
distribution
or
how
we
do
X,
Y
or
z,
to
like
I
guess
clarify
that
issue.
A
I've
separated
this
this
RFC
out
from
that
and
I
think
that
we
want
to
solve
that
and
then
remove
that
from
the
other
RFC
to
you
know,
simplify
and
clarify
it
cool
this
as
it
stands
right
now,
it
is,
does
have
consideration
for
the
architecture
you're
running
on
and
like
the
OS
as
well
and
I
believe
that
Dan
has
some
comments
around
like.
A
Let's
see
where
are
we
here
like
having
it
like
right
now,
like
architecture
and
operating
system
are
currently
like
required,
but
like
what
happens
if
something
could
run
on
both
architectures
that
sort
of
thing?
So,
if
you
have
any
comments
on
this
in
terms
of
like
structure
and
what
you
would
feel
would
need
to
happen
for
like
a
really
solid
multi-arch
setup,
the
goal
of
this
is
to
like
set
it
up,
so
that
it
will
be
good
for
multi-arch.
D
E
Something
and
thank
you
for
confirming
it's
something:
I
should
look
at
yeah.
E
Just
a
quick
question:
I
assume
the
work
I'm
doing
is
not
blocking
anything
on
the
stacks
front.
Right,
okay,
cool.
B
Mean
it's
not
like
blocking
anything
like
I.
Guess
we
probably
won't
roll
out.
You
know
arm
64.
to
the
other
Stacks
until
we're
like
fully
done
with
tiny.
So
in
that
way
it's
just
blocking,
but
it's
you
know
not
really,
because
any
progress
you
make
on
the
stack
currently
working
on
is
still
helpful
to
the
entire
thing.
B
E
Yeah,
no,
that's
fine,
yeah
I
just
wanted
to
make
sure
like
if
there
was
if
somebody
was
like,
we
need
this
sooner
than
this.
Just
let
me
know,
but
I'll
I'm
gonna
get
to
it.
I
just
wanted
to
make
sure
I
wasn't
holding
anything
up.
C
There
is
a
slack
thread
which
I
think
you're
in
where
Dan
magusa
is
pointing
out
that
the
spring
boot
Community,
like
is
a
consumer
of
the
tiny
stack
and
the
inability
for
I,
don't
want
to
phrases
the
fact
that
we
now
produce
a
stack
that
works
in
I'm
64,
but
we
don't
have
Bill
packs
and
builders
that
works
and
I'm
64.
C
It's
likely
to
break
this
bring
Brew
community
I
am
still
in
the
position
of
like
I'm
willing
to
like
wait
and
see,
but
I
suspect
when
it
does
kind
of
start
to
hit
the
fan.
It
will
be
like
a
pretty
big
thing,
so
I'm
wondering
and
haven't
fully
formed
this
thought.
So
I
wasn't
going
to
say
it
today,
but
I'm
wondering
like
how
can
we
get
ahead
of
that
problem
in
a
tractable
manner?
Right,
like
I,
was
wondering.
C
Maybe
we
need
to
like
prioritize
getting
64
support
for
the
Java
and
Java
native
buildbacks,
and
then
we
can
get
a
tiny
Builder
out
right
because
the
tiny
and
then
go,
but
girls
should
just
work
on
on
any
Stacks.
That
should
be
fine
and
then
maybe
maybe
the
priority
shifts
becoming
like,
instead
of
like
getting
the
tiny
stack
like
super
100
production
ready.
Maybe
we
need
to
switch
gears
and
be
like.
We
need
to
get
like
a
thin
thread
through
everything
and
get
like
a
non-production,
ready,
Builder
out
I'm,
not
sure.
C
That's
what
I
said.
It's
not
fully
form
thought
I'm,
just
I'm
a
little
worried
that
we're
like
there's
like
a
little
time
bomb
here
and
one
of
our
biggest
like
consumers
that
we
don't
see
because
they
don't
directly
like
give
us
feedback.
They
kind
of
like
sit
like
two
steps
removed
from
us.
They're,
like
seems
pretty
adamant
that
they're
like
about
to
have
a
bad
time
and
I
really
do
not
want
to
revert
the
stack
changes.
I
think
that's
a
bad
idea.
E
Okay,
yeah
I
mean
I,
can
take
a
look,
I
mean
I've
already
built
Builders,
just
not
in
your
with
your
tooling
yep.
So
I
can
take
a
look
at
that,
but
probably
should
I
assume
I
should
finish
the
multi-arch
receipts
stuff
first
and
then
switch
gears
or
should
I
look
at
the
other
thing.
First,.
B
C
Like
I
know,
there's
like
some
sharp
edges
with
the
lack
of
receipts
also
means
that
we're
like
not
rebuilding
64
Stacks
when
there's
changes
to
I'm
64
packages,
specifically
like
the
whole
bunch
of
like
other
aspects
of
the
automation
but
I,
guess,
I'm,
I'm,
wondering
and
I'm,
not
sure
I'm,
even
asserting
this
I'm,
like
wondering,
is
that
good
enough
right
is
that,
like
is
the
existence
of
a
tiny
stack
that
is
generally
mostly
up
to
date
on
arm
64..
C
E
Yeah
I
mean
I
think
the
problem
we're
going
to
run
into
is
all
the
the
testing
is
going
to
start
using
different,
build
packs
and
I
I
think
that
if
we
need
to
provide
a
short-term
solution
so
that,
like
communities
that
are
using
these
like
build
packs
and
Builders
and
stacks,
aren't
you
know
very
unhappy.
We
probably
need
to
just
start
shipping
something
forearm
without
fully
working
out
all
the
testing
and
then
have
that
be
like
the
second
stage
that
we
do.
E
Yeah
I
mean,
like
you,
know,
I'm
working
on
something
internally,
where
we've
just
basically
rebuilt
all
the
paquetto
build
packs
that
we
care
about
as
our
multi-arge
buildbacks.
So
I
I
have
a
little
bit
of
experience.
Dealing
with
this
but
I.
Think
to
your
point.
We
probably
need
to
just
start
producing
a
multi-arch
builder
like
basically
take
the
tiny
multi-charge
Builder.
E
All
the
way
like
we've
got
the
stack,
let's
create
a
builder,
and
then
we
can
look
at
the
build
packs,
which
will
then
require
us
to
start
talking
about
the
dependency
metadata
and
all
that
stuff.
So
yeah
I
mean
like
it
may
be.
Tiny
Builder
is
the
next
thing
I'm
happy
to
look
at
that.
C
Okay,
yeah
I,
think
I
think
that's.
That
sounds
like
the
same
thing,
I'm
saying
so
it
sounds
like
one
same
page.
The
tiny
bow
that
has
three
Bill
packs.
What
four?
C
If
you
include
proc
file,
Java
Japanese,
you
can
go
so
maybe
the
next
step
is
to
try
to
for
you
to
open
source
the
equivalent
of
version
of
your
tooling
to
help
us
build
those
build
packs,
I
think
and
my
course
is
optimistic,
but
all
three
of
those
should
just
work
because
they're
dependence,
none
of
those
dependencies,
are
compiled
for
any
specific
stack
they're.
All
like
Star
stack,
so
I'm
hopeful
that
we
've
been
no
reason:
I'm,
a
tiny
Builder,
probably
it's
inside,
of
java,
okay,
yeah.
E
C
Okay
cool,
it
sounds
like
that's,
maybe
the
the
gear
we
should
switch.
I'll
update
the
slack
thread
that
we
have
just
to
kind
of
like
summarize
this
conversation
and
show
them
acoustic
world,
really
very
happy
to
hear
this
and
I'm
optimistic
that
we
will
head
off
any
potential.
Spring
boot
related
main
points.
E
Yeah
and
just
on
that
note,
I
mean
I.
I
was
going
to
comment
on
the
conversation,
but
I
think
you
both
have
stronger
opinions
than
I.
Do
so
I
just
stayed
quiet,
but
if
we
need
to
create
a
tag
for
like
the
0.1
versions
of
the
stacks,
I
did
think
that
was
actually
not
a
bad
idea,
not
like
we're
maintaining
two
stacks,
but
basically
like
I
guess,
people
would
just
use
the
0.1
tag
and
always
get
AMD
64..
E
C
I
think
my
problem
with
that,
though,
is
like
it's
not
just
like
it's
not
like
a
one
and
done
thing
right.
We
have
to
like
duplicate
all
of
the
automation,
to
keep
that
stack
up
to
date
on
that
release
line
like
otherwise
we'll
just
get
the
other
feedback
from
the
green
blue
Community,
which
is
that,
like
your
Builders
full
of
CVS,
which.
E
C
It's
not
a
multi-charge
image.
Yeah
I'm,
not
trying
to
sound
like
a
no
but
I,
have
also
reservations
about
overwriting
tags.
I
think
that
causes
other
problems
like
we
can
no
longer
use
act
as
an
identifier
for
a
stack
version.
So
when
someone
has
a
problem,
they're
like
hey
I'm
from
the
spring
boo
Community
I
have
like
I'm
using
this
0.1
tag
and
we're
like
cool.
It
could
be
one
of
like
4,
000
images.
C
We
don't
know
which
one
you're
running
like
that
I
that's
I've,
encountered
pain
points
like
that
or
pain
points
from
this
kind
of
situation
in
the
past.
So
you
could
push
to
a
release
Branch,
but
then
you
start
to
tag
and
so
and
then
you
have
to
change
the
type
version
and
at
that
point
we're
like
halfway
through
re-implementing
all
the
ultimate
tune.
Anyway,
like.
C
C
Yeah
yeah
I
mean
I
may
have
blind
spots.
I
am
very
willing
to
accept
that,
and
there
may
be
like
I
may
have
prejudices
and
biases
I'm
just
worried
that,
like
we
have
not
identified
a
solution
that
isn't
sustainable
for
this
team,
but
also
provides
like
a
customer
experience
that
doesn't
then
turn
around
and
buy
anything
else
in
six
months
consuming
my
experience.
C
C
And
and
as
far
as
node
I'm,
not
node,
maintaining
so
I,
don't
want
to
speak
for
folks,
but
like
I,
wonder
if
there's
like
you
know
a
smaller
supported,
I
guess,
hello,
there's
a
small
supported
area
of
like
node.
Maybe
we
could
support
like
just
18
and
Beyond,
then
maybe
there's
pre-compiled
but
like
binaries
for
arm64.
We
don't
have
to
set
up
like
compilation,
I'm,
an
arm64
Runner
and
that
kind
of
thing
I,
don't
know
I'm
just
I'm
wondering
like
that.
D
On
the
Node
front,
it
depends
like
the
community
does
ship
or
in
binaries
that
should
run
on
whatever
Linux
is
as
long
as
the
the
like.
The
kernel
version
is,
is
recent
enough
and
for
the
the
Ubi
ones
the
way
we're
installing
them.
It
should
Autumn.
It
should
just
work
since
we're
dnf,
installing
them
and
Rel
does
or
Ubi
does
support
our.
A
Yeah
taking
a
quick
look,
node
actually
only
compiles
anything
for
or
only
compiled
anything
for
bionic.
So
I
think
that
you
can
get
that
Maybe
for
free.
C
Yeah
a
couple
tracks
with
my
memory-
I
just
didn't-
want
to
like
make
that
session,
so
yeah
I'm
optimistic
that
we
don't
have
to
over,
like
above
the
ocean
and
kind
of
like
invent
I'm,
64
compilation
and
all
that
kind
of
stuff
which
we
will
have
to
do
things
like
python,
but
python
isn't
in
the
tiny
Builder.
So
that's
a
future
problem.
D
One
thing
I'm
not
entirely
sure
about
is
yarn,
I,
just
I
think
it
might
have
some
platform
dependencies,
but
I'm
not
really
sure
on
that.
One.
D
D
E
So,
just
to
make
sure
I
understood
the
artifacts
that
your
that
paquetto
was
hosting
it's
just
a
copy
of
somebody
else's
compiled
like
downloaded
a
compiled
I'm,
AMD,
64.,
node
installation,
and
then
you
just.
A
E
A
Any
other
questions
comments,
concerns.
D
I
guess
just
one
additional
thing
to
add
on
that
front
is
I.
Guess
as
we
add
arm,
it
would
be
great
if
it's
easy
to
add
others,
because,
like
you
know
for
the
Ubi
ones,
we'll
likely
want
to
add
equivalent
for
power
and
s390.,
so
I
I
guess
if
it's
just
the
node
that
we
pull
from
the
the
community,
though
like
that
doesn't
like,
if
it's
just
note
itself,
where
we're
worrying
about
the
platform
versus
any
of
the
other
pieces
that
should
automatically
be
handled
by
the
Ubi
side
of
things
anyway.
D
E
D
And
I
guess
the
testing
part
is
maybe
related
like
I'm.
Currently
looking
at
PR
to
jam
and
I
can
see
it
builds
to
for
some
platforms
but
like
that
would
be
a
case
where
we
would
need
additional
platforms
to
run
the
tests
right.
E
D
E
You
really
want
to
test
on
each
one
and
I.
Don't
know
about
I
guess:
you'd
have
to
test
an
emulation,
I,
don't
know
yeah,
then
you
get
into.
How
do
you
pack
build
and
create
an
image
and
then
test
it?
Then
you
know,
gets
more
complicated,
but
yeah
I'll.
Definitely
keep
that
in
mind
that
use
as
an
architecture.
So
that's
good
to
know.
Thank
you.