<simpson>
Ah, cool. That explains everything I needed to know, too.
<domenkozar>
a bit weird to merge staging that completely breaks darwin at the time that release should be out :/
<domenkozar>
anyway don't want to discredit hard work :)
<domenkozar>
just to understand why it was done
pxc has quit [Ping timeout: 255 seconds]
<domenkozar>
worldofpeace: hey
<domenkozar>
any reason why gnome-3.32 branch builds darwin?
<domenkozar>
on hydra
<domenkozar>
I've disabled darwin since I don't see a reason :)
<domenkozar>
but let me know if I got it wrong
<worldofpeace>
domenkozardomenkozar There are certain packages that we'd like too see if they build on darwin
<domenkozar>
for some reason it was building 20k darwin package
<domenkozar>
s
<domenkozar>
worldofpeace: maybe enable that before it needs to be merged?
<worldofpeace>
I don't think either me or jtojnar had much control of the jobset, and was set up by gchristensen
<domenkozar>
alright no problem, just trying to get macos builds back to sensible numbers
<worldofpeace>
atm I don't think there would be any reason for that jobset to be doing anything IIRC
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
init_6 has joined #nixos-dev
ajs124 has joined #nixos-dev
<delroth>
cross-compilation question: I'm trying to build u-boot for a board where one of the host tools requires openssl. The u-boot Makefile attempts to use pkg-config to find the host openssl, but it seems like we only put target deps in $PKG_CONFIG_PATH, not host deps. Any idea how to solve this? :-)
<delroth>
e.g. somehow get a "host" pkg-config instead of a "target" one
<delroth>
Apparently the answer is to use depsBuildBuild. I'm sure one day this will make sense to me and I'll be able to cross build without trial and error.
<makefu>
samueldr: maybe we need hydra feature which retries evals on certain errors :) or a bot which uses the hydra api to find these issues and restart
<samueldr>
I don't like those two ideas at all :) at one point it will stop being only at the cusp of being a serious issue* and will always fail
<samueldr>
(it already is an issue that stopped us from setting aarch64 as a supported system for 19.03)
<gchristensen>
samueldr: this same error "fingerprint" has been mostly what you're seeing, right?
<samueldr>
right now it's only "Too many heap sections" with differing amount ot traces before
<gchristensen>
cool
<samueldr>
"right now" being since you tweaked the memory things the other day
<samueldr>
and that was well done
<gchristensen>
eelco did it :)
<samueldr>
let's assume it was the plural "you", addressing to the room and not the singular you addressing you personally :)
<samueldr>
(well done eelco)
orivej has quit [Ping timeout: 268 seconds]
init_6 has quit []
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
orivej has joined #nixos-dev
<manveru>
infinisil: might be better to talk here :)
<infinisil>
Ah yeah
<manveru>
but generally, i think we'll need this at some point anyway, every other programming language does this, so it shouldn't be too surprising if nix ends up needing it as well?
<infinisil>
Hmm I guess
<manveru>
either it's this, or some form of works-some-of-the-time caching
<manveru>
the tricky part is coming up with a good way to transition that supports both styles :)
<manveru>
or somehow changing the nix language itself...
<manveru>
right, i love that proposal... but i don't expect it within the next 1-2 years :|
<infinisil>
Yeah
<infinisil>
Maybe the right way forward is to try to transition to an "include to enable" style module system
<infinisil>
`imports = [ <nixpkgs/nixos/modules/services/foo.nix> ]` is a bit too annoying though, maybe we could make it shorter
<manveru>
sure
<infinisil>
And this would tie users to paths defined in nixpkgs, which means we can't move foo.nix to foo/default.nix (if we wanted to split up the file)
<zimbatm>
how about `foo.enable = true` would import `<nixpkgs/nixos/modules/foo.nix>`
<manveru>
hmm
<manveru>
imports are lazy too, right?
<infinisil>
zimbatm: It's not that easy unfortunately
<infinisil>
manveru: Nope
<zimbatm>
no that's the problem manveru
<manveru>
oh :D
<zimbatm>
not at the moment at least
<zimbatm>
I'm pretty sure the fix-point could be changed to make that possible
<infinisil>
That might work
<zimbatm>
ideally there would be a way to import all the modules for CI purposes
<zimbatm>
otherwise they are going to code-rote pretty quickly
<zimbatm>
code-rot
<infinisil>
We could still just have a list of all modules for that I guess
<manveru>
if the enable option is moved out of the module itself?
<manveru>
then you'd have a lazy conditional for the import
<zimbatm>
yeah or have another top-level like `enableImports = []` that imports and enables the modules, with an attribute path <-> filesystem mapping
<zimbatm>
I'm a big fan of attribute path to filesystem mapping
* infinisil
is too
<infinisil>
Might not work as well with submodules
<infinisil>
But enable options usually aren't in those
<gchristensen>
I'm a fan of grep being directly useful, and having an explicit `foo = import ./foo` makes that helpful
<manveru>
i like it :)
<zimbatm>
do we have a builtin to explore if a thunk has been resolved or not?
<infinisil>
Nope
<zimbatm>
not sure if this is a good idea but it could mean that `foo = import ./foo`, `foo` could stay a thunk
<zimbatm>
when traversing the tree, all the thunks would be skipped
<manveru>
let's see...
<zimbatm>
and when setting `foo.enable = true` it would force the evaluation of the thunk
<gchristensen>
so Nix does do that already, but the NixOS module system is strict so forces it
<LnL>
gchristensen: yeah, I define nixos options as foo.bar.baz = ... for the same reason
<zimbatm>
that's a good life lesson; we're never lazy enough :p
<gchristensen>
LnL: nice!
<LnL>
options are often not structured clear enough to find them otherwise
<zimbatm>
ok I have yet another idea;
<manveru>
seems fine, it doesn't eval the file at least
<zimbatm>
what if we made the distinction between system services and network services
* infinisil
has no idea where this is going
<zimbatm>
a system service is one that configures the system, like users, dhcp resolver, ntp sync, ...
<zimbatm>
a network service is one that runs attached to a port and provides a service like a http server, mail server, ...
<zimbatm>
currently we are trying to find a solution that works for all of those, but maybe it makes things simpler to have a distinction in place
<gchristensen>
what is the end goal of this distinction?
<infinisil>
^^
<infinisil>
No idea how this difference matters for the module system
<manveru>
it'd double the number of modules at least :|
<zimbatm>
system services tend to have deep inter-dependencies and are hard to extract with the moduleName.enable pattern as described above
<manveru>
since most network services also create a user for itself
<gchristensen>
ah
<Taneb>
If we go for one of the "every configuration ever has to change" solutions, I don't think a transition script would be impossible to write
<gchristensen>
some of my systems can't boot (by design) without some network services starting as well
<infinisil>
Taneb: I think you might underestimate the complexity NixOS configs can have
<zimbatm>
for example if you set `network-manager.enable = true` it will set options in other modules, which will break if they are not enabled (since the options are only loaded after they are loaded)
<Taneb>
infinisil: that's almost certainly true
<zimbatm>
s/loaded/available
<infinisil>
zimbatm: They should just recursively enable others modules
<zimbatm>
with network services, an issue is that one might want to start more than one instance of the module per machine
<zimbatm>
for example I might want to start httpd on port 80 and 8080 with different configurations
<gchristensen>
(let's be careful to not squash ideas too early)
<zimbatm>
and this is currently an issue
<zimbatm>
I believe that network services also could benefit from using dynamic users more
<samueldr>
hmm, but that's not necessarily a network service issue? "reusable" modules could also be useful elsewhere I think
<zimbatm>
sure
<zimbatm>
these are broad strokes
<zimbatm>
I'm pretty sure you can find modules that fit both descriptions
<zimbatm>
like dnsmasq
<zimbatm>
anyways, I think making this distinction could be useful, not sure exactly how yet
<zimbatm>
network services tend to be closer to relocatable systemd units
<gchristensen>
I also think this is interesting
<gchristensen>
I think a model where services are not necessarily in nixpkgs/nixos but are more readily available (like chef's cookbooks) is interesting for community scalability
<zimbatm>
nixpkgs/disnix :)
<infinisil>
gchristensen: Like, self-contained service definitions?
<gchristensen>
right
<zimbatm>
those could even run on non-nixos machines
<gchristensen>
hoo boy
<zimbatm>
or potentially inside of containers
<zimbatm>
finger-in-the air I would say that should remove more than 50% of the nixos modules
<LnL>
yeah, modules that are namespaced rather than part of the global config would make a lot more sense for reusability
<infinisil>
How about specifying dependencies of modules like `requires = { systemd = "1.1"; users = "1.4"; }`
<infinisil>
And then you need to have them all in NIX_PATH somehow to make it work
<gchristensen>
Nix Flakes
<LnL>
and being able to instantiate modules multiple times also means that not instantiating it becomes easier
<gchristensen>
(please, everybody, have a better name than Flakes)
<infinisil>
Um, modules?
<gchristensen>
nixos modules?
<infinisil>
Oh wow that sounds great, let's use that
<LnL>
modular modules :p
<gchristensen>
sorry, modules are taken by nixos modules
<zimbatm>
I'm pretty sure we will get used to the name quickly
<samueldr>
they'll be described as flakey :/
<infinisil>
Modules -> Mudoles
<samueldr>
even if only as a pun!
<zimbatm>
sounds good :)
<gchristensen>
"flake" is a gross word
<zimbatm>
what makes it gross gchristensen? I'm missing some english context
<gchristensen>
makes me think of flakes of skin, and an image of a very unhealthy person
<gchristensen>
and people who are flakes
<zimbatm>
it fits some of the criterion for a good name: easy to type with few variations possible, relatively unique
<infinisil>
worldofpeace: I'm +1 for the name "Seborrhoeic Dermatitis"
<gchristensen>
hahaha
<worldofpeace>
It's almost universal
<emily>
flake is fine
<gchristensen>
how about "moons"
<emily>
makes me think of the chocolate sticks in soft-serve ice cream if anything
<emily>
as for the "unreliable person" thing... well, it's not quite "git"
<worldofpeace>
hah
<infinisil>
I think "Module" is fine, but in order to distinguish it with the old modules we should call them "Supermodules"
<worldofpeace>
I love the free thought format that happens in #nixos-dev. Many topics :)
<infinisil>
:D
<infinisil>
We're getting distracted, the original goal was to figure out how to solve the nixos-rebuild performance problem!
<zimbatm>
we can attach our own meaning to the "flakes" word
<zimbatm>
imagine if a company was called Banana, that would be weird no?
<zimbatm>
but Apple seems fine for some reason
<manveru>
well, for the performance problem some rewriting of the module-list.nix to the `foo = import ./some/foo.nix` would work then with minimal disruption for end-users, anyway :)
<gchristensen>
they didn't name anything banana
<gchristensen>
and they have more money in cash than Morocco's entire GDP
<infinisil>
manveru: Minimal disruption would be not having to change anything at all
<infinisil>
(as an end user)
<manveru>
why would an end-user have to change anything with this?
<infinisil>
manveru: Wait how does that `foo = import ./some/foo.nix` work?
<manveru>
well, for example you have `options.hardware.ledger = import ./hardware/ledger.nix`
<infinisil>
Ah
<manveru>
so it's only evaled when you enable it
<zimbatm>
yeah that would be worth a try
<gchristensen>
is that already true? :o
<gchristensen>
hmm no, probably not
<manveru>
right now we have a massive list of paths that are all imported...
<infinisil>
I feel like there's a catch somewhere
<zimbatm>
also modules could be ported gradually
<infinisil>
Oh yeah, what about options that get set from multiple places
<gchristensen>
I think the catch is that the module system is strict and deeply evaluates every attribute
<manveru>
there's a lot of catches for stuff that does things without being enabled i think :)
<gchristensen>
samueldr: I forwarded your last one to niksnut and he said eugh, so hopefully he does something :)
<samueldr>
it looks like a hard™ problem :/ and this is the hydra evaluator, so not directly mapped to the nix one AFAIUI
<samueldr>
though IIRC it did happen in the nix one when adding aarch64 to supported systems
psyanticy has joined #nixos-dev
pxc has joined #nixos-dev
<Mic92>
zimbatm: makefu: we might have the one or the other secret in nix-community, should we have some people that have mutual access to those to drive down the bus factor? In particular there is a heroku account for updating nur and a pypi account.
<gchristensen>
Mic92: what is this regarding?
<gchristensen>
there is a set of credentials that a few select people have access to
<Mic92>
gchristensen: I mean the idea is that if somebody dissappears, we could still move the services to new maintainers in the same way we can give new people access to repositories in https://github.com/nix-community/
<gchristensen>
+1
<gchristensen>
maybe a way for the project members to share access with the foundation?
<gchristensen>
or, better, have the foundation be able to host resources like that
<Mic92>
mhm ok. who is the foundation in terms of people actually?
<gchristensen>
the foundation is officially Rob Vermaas (ikwildrpepper), Eelco, and Armijn Hemmel (armijn)
<gchristensen>
other people involved with foundation-ey things including infrastructure tasks include aminechikhaoui, zimbatm
<gchristensen>
(and me)
coconnor has joined #nixos-dev
pxc has quit [Ping timeout: 245 seconds]
pxc has joined #nixos-dev
<infinisil>
gchristensen: Btw, topic is still outdated
<gchristensen>
w.r.t.?
<infinisil>
release managers
<infinisil>
Oh
<gchristensen>
looks up to date?
<infinisil>
Ahh, I didn't read the full topic
<infinisil>
I can't see 19.03 RMs in my view by default
<gchristensen>
ah
<infinisil>
I don't think we need to keep 18.09 in there
<gchristensen>
I was going to keep them until 19.03 is released
<niksnut>
samueldr: gchristensen: I've tweaked the hydra-evaluator settings a bit more, maybe it will help
<gchristensen>
so f52505fac8c82716872a616c501ad9eff188f97f would be the tag target
<samueldr>
niksnut: isn't it part of hydra? I don't see a change on master
<niksnut>
in nixos-org-configurations
<niksnut>
and I haven't committed it
<niksnut>
I changed the evaluator heap size by another GB
<samueldr>
ah, only the settings, not the evaluator itself; I should try again with the aarch64 added to supportedSystems, but IIRC with that added it wouldn't pass even with ridiculous sizes
<clever>
samueldr: have you seen how to test an eval locally?
<clever>
that will run a given release.nix, without needing postgres configured
<samueldr>
yes, I know, thanks though :)
<clever>
the above script also checks for any errors in the json
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
obadz has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
pxc has quit [Ping timeout: 250 seconds]
drakonis has quit [Ping timeout: 252 seconds]
<clever>
error: Package ‘datadog-0.2.3.0’ in /nix/store/cyi5vdmx5i1w7vr2inl5yxhkwlskz9ib-nixos-19.09pre174426.acbdaa569f4/nixos/pkgs/development/haskell-modules/hackage-packages.nix:62748 is marked as broken, refusing to evaluate.