►
From YouTube: NixOS Office Hours, 2020-02-21
Description
Today, we are discussing some recent changes related to Flakes in Nix, Nixpkgs, and Hydra.
A
A
A
Yep
go
ahead:
okay,
hello.
Everyone
welcome
to
the
12th
mix
of
us
office
hours.
Today.
Our
format
is
a
little
different.
If
you
couldn't
already
guess
we're
going
to
be
talking
about
hydras
memory
problems,
the
flakes
thought
Nix
merged
the
next
packages
and
the
RFC
process,
we're
joined
by
Elko
Telstra,
the
creator
of
NYX
in
the
offer
of
xrc
analyst
arose
a
shepherd
of
ethics
RFC
and
a
notable
next
packages.
Contributor
Graham.
Could
you
introduce
in
discussion.
B
We
had
some
trouble
with
Hydra
and
the
evaluator,
and
so
the
tested
job
set
for
Nick's
arrest
changed
as
well,
and
a
few
of
these
things
happened
on
the
flakes
branch
of
Nick's
itself,
which
I
have
caused
some
concern,
and
so
we're
going
to
talk
about
that
today.
I
think
people
are
a
bit
concerns
that
flakes
are
being
implemented
into
Nick's
packages,
officially
a
bit
too
fast
or
concerns
that
Nick's
OS
actually
depends
on
flakes
or
Nick's
packages
depends
on
flakes
and
or
even
that
hydra
is
using
flakes
to
build
nicks,
OS
or
unix
packages.
B
C
B
C
There
yeah
I
I,
was
kind
of
just
a
little
nervous
flakes
were
sort
of
being
taken
as
a
given
and
something
that
was
going
to
happen
and
that's
colored.
Some
of
what
happened
later,
which,
from
my
perspective,
was
that
a
week
or
two
ago
code
was
added
to
Knicks
packages.
There
was
a
flake
Dominic's
added
and
some
flake
support
in
the
mix.
C
Rs
rebuild
and
mixer
s
install
I,
think
I'm,
not
sure
about
that,
and
that
was
to
add
compatibility
with
using
mix
mixer
s
and
mix
packages
via
flick,
and
this
was
surprising
to
me
for
a
couple
of
reasons.
One
is
that
this
was
added
the
day
of
branch
off,
and
the
other
thing
that
made
me
concerned
about
it
was
that
this
came
at
a
time
where
we
had
no
movement
on
the
RFC
for
quite
a
while.
Our
last
shepherd's
meeting
was
in
October
and
there's
not
even
being
very
much
discussion
since
then.
C
At
the
same
time,
I
could
see
through
the
minutes
of
the
RFC
steering
committee
meetings
which
happen
every
two
weeks
and
the
minutes
are
published
that
the
flakes
RFP
was
being
covered
by
there's
a
there.
Might
be
a
meeting
soon
that
there's
ongoing
work,
so
this
is
still
moving
along
and
I've
been
assuming
that
that
ongoing
work
meant
work
on
the
RFC.
But
after
having
seen
this
I
became
nervous
that
ongoing
work.
There
actually
meant
ongoing
work
on
flakes
outside
of
the
RFC
process
and.
B
C
B
C
And
even
that
meat
has
made
me
a
bit
nervous
just
because
of
the
fact
that
the
next
arrest
Foundation
and
is
using
this
I
worry
signal.
This
sort
of
this
is
ready
or
that
this
is
something
that
people
keep
each
into
production
and
really
overall.
My
main
concern
is
not
with
flakes
with
their
implementation
and
or
whether
they're
a
good
or
bad
thing
for
the
ecosystem,
but
really
with
the
RFC
process
and
as
Shepherd
on
the
RFC
and
I
felt
through
this
process
that
things
were
going
ahead.
That.
C
So
it
just
felt
like
the
RFC
was
not
moving,
but
still
the
rollout
of
flakes
was
happening
without
an
RFC
process
and
I
think
that
the
RFC
decision-making
process
is
one
of
the
best
things
that
we
have
in
our
community.
I
think
it
let's
submit
really
good,
measured
decisions
and
I'm
for
that
reason
feel
very
protective
of
it
and
I'm.
Quite
wary
of
anything
that
looks
like
it's
going
to
go
against
that
so
yeah.
D
A
On
the
situation
as
a
release
manager
and
as
being
a
member
of
the
RFC
steering
committees,
that's
excellent
right,
yep,
okay,
so
you
did
mention
that,
throughout
on
the
time
you
the
RC
steering
committee,
wasn't
actually
on
talking
about
the
flakes
PR.
It
was
just
that
it
was
just
work
in
progress
and
that
was
it
and
I'm
pretty
sure.
Every
meeting
I
was
able
to
attend
about
the
that
was
for
the
RFC's.
It
was
not
really
mentioned,
so
that
was
really
concerning
to
me
as
well.
A
It
did
seem
very
stalled
for
a
very
long
time,
at
least
to
me
and
a
lot
of
others
and
the
thing
about
the
the
flakes
PRS
I'm.
It
took
me
quite
a
bit
actually
figure
out.
It
was
the
thing
I
think
maybe
on
maybe
two
months
since
it
was
open.
I
actually
sort
actually
noticed
it,
but
it
was
under
my
assumption
that
that
PR
was
not
going
to
be
merged
ever
at
least
until
like
the
RFC
was
on
accepted.
Like
that,
that's
what
I
thought-
and
you
know
the
day.
A
I
was
supposed
to
branch
off,
this
PR
got
merged
and
I
was
really
really
confused,
because
that
has
all
kinds
of
implications
for
me
as
a
release,
manager,
I
just
felt
just
very,
very
confused
and
very
worried
and
concerned
and
sort
of
the
response.
I
got
on
that
RFC
from
people
was
very
frustrated
and
having
a
very
hard
time
figuring
out
what
happened
and
what
was
going
to
happen.
It
wasn't
it
for
Nick's
at
large,
so
that's
pretty
much
I'll
have
to
say.
B
First
about
the
flakes,
NICs,
merge
and
I'm
going
to
try
to
stay
fairly
factual
and
not
make
any
assessments
about
whether
it
was
the
right
thing
or
not,
but
for
pretty
much
as
long
as
as
I
know,
I
don't
know
of
any
time
when
the
Knicks
OS
infrastructure
didn't
use
experimental
features
of
NICs
I.
Believe
it's
effectively
always
used
a
version
of
NICs,
which
was
directed
from
master
or
directly
from
an
experimental
branch,
and
a
lot
of
that
is
is
so
that
we
can
really
intensely
carefully
validate
that
it
works
and
that
it
doesn't
have.
B
It
doesn't
pose
any
regressions
into
the
infrastructure,
especially
with
Hydra
and
our
build
farm.
The
disguise
and
scale
of
that
build
time
is
pretty
great
and
has
a
tendency
to
bring
up,
especially
concurrency,
bugs
if
we
happen
to
have
any
really
early,
and
so
we
I
know
Elko
and
I
personally,
valid,
really
appreciate
that
sort
of
validation
and
so
yeah
in
October
flake
support.
B
At
least
preliminary
flake
support
was
added
to
Nick's
ops
so
that
we
could
put
it
into
the
production
and
make
sure
that
the
format
was
workable
and
make
sure
that
we
could
at
least
deploy
something
that
was
at
least
as
complicated
as
our
infrastructure.
Using
this
this
idea,
and
so
what
that
means
is
we
for
our
production
infrastructure
we
switched
to
the
flakes
branch.
B
C
B
Nothing
about
we've
done
what
we've
done
in
this
is
fixed.
We
could
we
could
undo
and
take
out
flakes
from
all
of
this
tomorrow
and
it
would.
It
would
changed
nothing
effectively
about
how
the
infrastructure
works
or
anything
that
we're
currently
doing.
It's
all
something
that
we
can
do
in
different
ways.
B
The
second
thing
that
happened
in
the
last
few
weeks
is
the
evaluator
and
Hydra
ran
out
of
memory.
Is,
has
been
a
recurring
problem
every
few
months
since
2017
I
believe
and
the
typical
solution
is
that
we
would
go
in
and
increase
the
garbage
collectors.
The
initial
heap
size
by
a
couple
of
gigabytes
every
few
months,
and
it
would
fix
it.
B
But
this
time
was
a
bit
different.
We
recently
had
upgraded
the
server
it
to
have
64
gigabytes
of
RAM
and
I
believe
the
initial
heap
size
was
up
to
34
or
35
gigs
or
so,
and
we
couldn't
easily
increase
the
heap
size
because
of
other
memory
pressure
on
that
system,
and
so
we
didn't
have
the
same
easy
fix
available
to
us.
B
Hilko
proposed
one
fix,
which
I
think
was
universally
not
liked
very
much,
which
was
deleting
almost
all
of
the
tests.
Each
test
and
added
a
significant
amount
of
memory
to
be
required.
Part
of
the
evaluation
and
deleting
almost
all
of
those
tests,
was
a
great
quick,
pragmatic
solution
that
got
rid
of
the
memory
pressure
but
took
away.
One
of
what
I
think
is
one
of
the
most
special
values
special
features
and
incredible
value
adds
that
Nix
is
able
to
do
I.
Think
this
testing
infrastructure
is
incredible.
B
I
think
it's
a
good
thing
to
have
I
think
it's
also
the
wrong
message.
I
think
we
should
be
encouraging
more
people
to
be
writing
more
tests
as
part
of
validating
features
and
packages
and
modules
that
Nix
OS
has
he'll
go
and
I
had
discussed
that,
and
so
he
looked
at
this
alternative
branch.
This
experimental
branch
for
Nix
OS
called
precise
GC,
which
uses
a
different
model
from
a
master
which
uses
a
GC
called
Boehm.
B
B
B
One
of
the
downsides,
or
one
of
the
things
that
happened
as
part
of
this
is
this
change-
happens
on
the
flakes
branch
of
nix,
and
this
wasn't
because
it
depended
on
Nix
or
used
anything
having
to
do
with
Nix.
This
is
just
a
side
effect
of
the
fact
that
flakes
is
the
branch
that
we
deployed
to
production.
B
B
The
change
to
the
evaluation
model
has
opened
up
what
I
believe
to
be
new
new
possibilities
around
how
much
we
can
scale
how
many
tests
we
can
have.
It
makes
it
possible
for
us
to
look
into
seriously
supporting
arm
v7,
L
or
power
9
projects
that
I've
wanted
to
do
for
a
long
time,
but
haven't
been
able
to
because
of
this
fear
of
memory
pressure,
and
the
second
thing
that
I
want
to
make
sure
is
clear.
B
Is
that,
from
my
perspective
and
I
and
from
the
infrastructures
perspective,
the
use
of
flakes
is
purely
just
to
a
validation
of
the
idea
of
the
concept
and
the
file
format,
and
any
changes
that
are
needed
will
be
done
and
with
that
I
guess,
I'd
like
to
pass
it
off
to
he'll,
go
to
provide
his
perspective
on
the
status
of
the
RFC.
Oh.
D
D
So
there
have
been
some
pretty
major
changes
as
a
one
is
that
the
RC
has
been
massively
reduced
in
scope.
So
it's
it's
in
its
current
version.
It
only
talks
about
out
of
the
flake
file
formats
and
the
log
file
formats.
It's
it
doesn't
talk
about
Nick,
CLI
changes
and
things
like
that.
So
yeah,
just
the
scope,
has
been
reduced
quite
a
lot
without
that
also
meant
that
all
the
work
that
was
happening
on
the
implementation,
then
it
actually
require
any
updates
to
the
RFC
anymore.
D
D
D
So
in
my
opinion,
the
RFC
process
is
not
intended
to
preclude
people
from
doing
an
experimental
implementation.
In
fact,
people
doing
an
experimental
implementation
is
a
there's,
a
good
thing.
We
just
don't
want
those
things
to
be
inflicted
on
users
when
it
hasn't
been
accepted.
Yet
so
I
think
that's
the
case
here.
So
the
current
status
of
the
flake
implementation
has
over
two
parts
of
it.
There
is
the
flake
branch
of
NICs
itself,
so
that's
still
branch
nothing
has
been
merged
and
even
on
that
branch,
flake
support
is
hidden
behind
an
experimental
feature
flag.
D
Sheppard's
meetings
fell,
so
we
decided
to
add
this
notion
of
experimental
features
to
Nix,
which
I
think
is
very
helpful,
because
it
allows
us
to
add
all
sorts
of
things
like
recursive
mix,
support
or
content
address
ability,
so
all
sorts
of
things
that
previously
existed
on
an
on
various
experimental
branches.
So
we
can
now
actually
have
these
things
in
principle
on
master
for
people
to
play
with,
but
they
explicitly
have
to
enable
enable
them.
D
D
There's
no
impact
on
you,
it's
yeah,
so
yeah.
So
this
is
the
question:
is:
is
it
okay
to
to
merge
such
a
thing
experimentally,
so
that
file
is
actually
it
has
a
warning
at
the
top,
whether
it's
experimental,
even
if
that's
a
bit
superfluous,
because
the
only
way
that
you
could
use
it
is
via
an
experimental
feature
in
Nix,
but
we
do
want
to
make
it
clear
to
people
that
this
is
experimental.
The
file
format
can
and
probably
will
change.
D
D
Now
yeah,
so
you
could
say
okay,
but
given
that
the
RFC
hasn't
been
accepted
yet,
should
we
have
this
in
next
packages
at
all
and
I
think
the
RFC
process
for
when
it
concerns
the
expect
just
changes
is
primarily
for
things
that
could
have
a
an
actual
impact
on
people.
So,
for
example,
if
you
proposed
a
change
to
the
Knicks
OS
module
system,
that
would
obviously
affect
a
lot
of
people
and
it
would
create
the
possibility,
that's
people
to
start
using
such
features
and
it
creates
backwards
compatibility
issues.
D
C
B
C
B
C
Well,
one
one
thought
I
had
when
I
was
hearing
about
this.
Is
that
this
the
fact
that
it
was
impossible
to
test
out
flake
without
adding
a
flake
dot
next
to
mix
packages
implies
that
we've
missed
a
requirement
in
the
design
of
flakes,
which
is
that
it
should
probably
be
possible
to
have
a
flake
dominic,
not
in
the
same
repository
as
the
expressions
that
is
building
and
which
sounds
like
they
would
have
solved.
That
problem
and
the
other
question
I
had
listening
to.
That
was.
C
D
So
the
answer
to
that
question
is
so
actually
it
has
been,
so
we
have
back
ported
those
changes
to
the
master
branch
of
Hydra
and
yeah.
The
reason
why
I
did
it
on
flakes
first
is
because
that's
what
hydroid
of
Nick's
Westerbork
was
running
and
we
were
under
a
bit
of
time
pressure
to
get
the
channels
working
again,
so
yeah.
D
Right
and
your
first
question
yeah:
what
was
it
possible?
Why
not
add
flake
the
next
Nick's
to
some
external
repos?
There
I
actually
did
consider
that
because
it
it
is
actually
possible,
and
so
you
could
just
have
a
sort
of
wrapper
flake
that
imports
an
external
repository
that
so
flakes
can
actually
depend
on
norm.
Flake
repository,
so
you
could
just
cool
the
next
package
--is.
D
D
Like
but
it
would
make
the
notation
a
bit
more
Yesi,
you
would
have
to
say
something
like
in
Boots
stunts
and
expect
just
repartee
booth
doesn't
expect
it
just
dot.
Revision
is
something
and
okay,
yeah
and,
and
the
dpr
actually
does
make
some
other
changes.
So
it
adds.
Support
for
flakes
to
nix
was
rebuilt
and
an
exhaust
container.
D
C
Don't
understand
why
you
would
have
to
why
we
couldn't
have
a
way
in
the
flake
mix.
To
say
I
mean.
Maybe
maybe
this
is
going
a
bit
too
deep
for
this
calls,
but
why
we
couldn't
have
just
a
way
to
say,
and
we
have
a
repo
that
only
has
the
flake
don't
mix
in
it
and
it
just
says:
grab
things
from
mixer
athletics
packages
under
the
branch,
I
suppose.
D
C
C
C
B
B
D
You
there,
okay,
oh
sorry,
I
was
I,
was
talking
with
a
muted
myself.
Sorry
about
that
yeah,
so
yeah,
absolutely
I
should
have
mentioned
the
the
expected
jizz
be
are
on
the
flake
are
see
anything
that
I
was
going
to
merge
it
I
have,
except
that
the
PR
was
actually
open
for
five
months
and
I
had
actually
mentioned
on
IRC.
That
was
intending
to
do.
Merge
it,
but
obviously
saying
things
on
IRC
is
not
a
very
open
communication.
Medium!
Yes,.
D
But
in
my
defense,
I
will
say
that
a
lot
more
impacting
changes
to
next
packages,
customers
all
the
time,
and
so
this
is
a
change
that
doesn't
really
impact
anybody
if
you're,
not
a
flake
user,
I'm,
not
sure
if
Graham
actually
mentioned
this,
but
so
one
of
the
reasons
why
we
really
did
want
to
mention
this.
We
want
to
merge.
This
is
because
we
were
previously
using
an
expected
juice
fork
and
yeah.
B
B
And
so
my
thinking
is
that
a
good
step
before
we've
gotten
to
here
would
have
been
saying.
I.
Think
this
isn't
in
an
in
spear
mental
phase.
I
think
we
should
merge
this
pull
request
and
I
think
we
should
experiment
with
it
and
leave
this
pori,
because
this
RFC
open
for
some
period
of
time
to
experiment
does
that
sound
right.
D
B
C
Yes,
so
that
was
my
main
concern,
but
also
there
is
an
impact
in
terms
of
this
places.
This
is
something
that
has
to
be
maintained
by
everybody
and
also
that
there's
a
chance
that
this
could
impact
other
people,
even
if
it's
not
intended
to
and
now
the
risk
of
either
of
those
things
in
this
case,
I
think
wasn't
all
that
big,
but
it
was
there
I.
B
B
C
Somebody
came
to
me
a
while
ago,
who
was
concerned
about
PR
the
added
rust
some
rust
into
ethnic,
and
they
felt
that
that
PR
also
had
been
sort
of
open
for
a
while,
not
not
too
much
discussion
merged,
and
but
they
felt
that
it
really
kind
of
wasn't
ready
and
had
some
bugs
or
something
I.
Don't
remember
exactly
the
detail,
but
I
think
that
four
changes
changes
that
are
in
some
way
notable
or
big.
There
needs
to
be
more
communication.
C
Before
things
are
emerged
in
case
people
have
outstanding
concerns
because
a
lot
of
the
time
people
won't
bring
up
things
because
they
think
oh
well,
you
know
I'll
leave
this
to
be
discussed
for
a
few
months
and
see
how
how
it
goes
because
it's
quite
a
way
off
and
giving
them
that
chance
to
like
you
know
if
you
have
any
objections.
Here's
the
time
is
important
for
that
sort
of
big
change.
Yeah.
A
A
Pressure
issues-
it's
just
sort
of
about
the
awareness
of
what's
occurring
in
general
I-
think
that
goes
back
into
the
point
about
announcing
intentions
is
that
for
the
most
part,
I
wasn't
sure
what
was
actually
occurring
at
the
current
moment,
because
of
all
that,
through
this
and
I've
actually
received
this
timeline
I
actually
understand
everything.
You
did
completely
and
I've
actually
sort
of
switched
my
feelings
about
the
situation
entirely,
but
I
feel
like
that
situation.
Conspired
because
there
wasn't
he
was
communicating
exactly
what
was
being
done
so.
C
Yeah
I
didn't,
like
you
know,
as
a
shepherd
I
didn't
need
to
be
involved
in
the
kind
of
real
heavy.
We
have
to
fix
the
evaluations
now
because
the
channels
are
stuck,
but
I
would
have
appreciated
an
explanation
of
what
had
happened
since
it
was
relevant
to
the
work
that
I'd
been
doing
and
until
tonight
I
hadn't
had
one
of
those.
A
B
Like
there's
a
meme,
but
it's
it
sort
of
felt
like
I
fix
it
fix
it
fix
it
kind
of
thing
and
we
definitely
didn't
communicate
as
much
as
we
could
have
on
that
front.
I
think
my
thinking
is
that
the
fact
that
we've
had
this
call
will
help
make
it
clear
the
sorts
of
things
that
need
to
be
established
on
the
RFC,
and
perhaps
some
of
these
things
could
be
changed
in
RFC
process
itself.
I
didn't
do
my
homework.
B
C
B
And
so
I
think,
maybe
for
something
like
this.
It
should
be
able
to
represent
that
I
think
it's
really
positive.
The
agreement
to
more
clearly
and
more
upfront
talk
about
our
intentions
and
changes
that
we're
planning
on
making
requests
that
we'd
like
to
merge
I,
feel
there's
been
a
lot
of
good
progress
and
good
agreement
on
that
front.
Here.
C
Ongoing
related
at
all
to
the
RFC
shows
that
the
steering
committee
needs
to
be
somehow
more
aware
of,
what's
actually
going
on
or
or
and
and
or
be
more
prepared
to
take
action
to
make
sure
that
things
are
actually
not
stuck
and
are
still
going
on,
because
I
think
that,
with
a
couple
of
more
meetings,
the
flakes
the
flit
look,
the
parent
RFC,
which
defines
late
dotnet
and
could
be
accepted.
But
because
of
the
sort
of
confusion
here,
we've
not
actually
made
any
progress
in
that
yeah.
B
C
B
C
D
A
B
C
I
think
that
currently,
my
impression
is
that
not
very
many
people
are
but
the
development
of
NYX,
even
if
we're
not
all
actually
working
on
it,
is
something
that
affects
all
of
us
and
so
I.
Don't
know
what
I,
what
what
I
mean
having
more
more
active
contributors
would
probably
have
helped
here,
because
more
people
would
know
what
was
going
on
and,
yes.
B
B
B
B
B
And
and
to
sum
that
up,
that's
by
the
way,
that's
a
really
great
point,
ELISA
about
the
the
ease
of
contributing
to
Nicks.
So
that's
one.
The
second
is
representing
the
state
in
the
RFC
and
making
sure
that
the
steering
committee
is
is
aware
of
what
ongoing
work
means
and
whether
or
not
that's
actually
not
related
to
the
RFC
itself.
A.
C
B
C
B
C
D
Okay,
for
some
reason,
my
web
browser
stopped
updating,
but
apparently
when
I
click
it
does
register.
Okay,
no
I,
don't
have
much
more
to
say
at
the
moment
that
I
I'm
very
grateful
for
the
the
inputs,
and
probably
we
should
I
I
should
do
better
at
communicating
things.
That's
not
really
my
strongest
suit.
C
A
A
B
I
wasn't
aware
of
that.
Unless
there's,
unless
something
changes,
our
next
office
hours
will
be
March
5th.
If
you'd
like
to
be
a
guest
speaker,
please
get
in
touch
and
symptoms.
Nicks
Fridays
are
on
hold
for
the
time
being,
petty
is
still
streaming
his
Haskell
packaging
updates,
and
you
can
find
him
on
at
original
pet
cbet
I
on
Twitter,
and
that's
all
thank
you
all
so
much
for
coming.
I
hope
this
has
been
really
good.
I
really
appreciate
it.