<angerman>
domenkozar: do you happen to have any cachix \w travis/nix instructions for darwin?
<angerman>
I've had this working a few weeks ago, but something with the macos/nix support might(?) have changed? The end result being that nix doesn't query cachix anymore, and rebuilds everything.
drakonis1 has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
xeji has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 244 seconds]
lassulus_ is now known as lassulus
xeji has quit [Quit: WeeChat 2.2]
<ekleog>
does anyone have an opinion on whether it's OK to link to the “secret” gist for extensible attrsets from the nix issue tracker?
* ekleog
would really like a venue to discuss it :(
<drakonis1>
when was that one posted?
jtojnar has joined #nixos-dev
<fpletz>
domenkozar: could you please set the nixpkgs release-18.09 branch to protected? cc samueldr
jtojnar has quit [Client Quit]
<ekleog>
drakonis1: well, the point is exactly it never was officially… but it's basically what eelco said in his talk
<drakonis1>
ah okay i know which gist that is
<emily>
s-secret gists?
<drakonis1>
yes... its a secret, don't tell anyone
orivej has quit [Ping timeout: 240 seconds]
<drakonis1>
didn't eelco talk abot opening a roadmap issue?
<ekleog>
well, there's no issue
* ekleog
wonders if it'd be ok to just open one, but the gist being secret makes me reluctant, even though everyone most likely already knows about through a mean or another :(
<ekleog>
+it
<drakonis1>
why not ping him and ask about it
<ekleog>
because I try my best to not ping him, will do if this second attempt of a ping on #nixos-dev doesn't work :p
<drakonis1>
hmm, alright
<drakonis1>
i do want those changes to come
<drakonis1>
although wouldn't they require a sweeping change to nixpkgs to use it?
<ekleog>
it can potentially be done incrementally by transparently implementing mkDerivation in terms of it
<drakonis1>
i get the impression that it would allow for a gentoo-like experience
<drakonis1>
options that is
<drakonis1>
being able to build a package with certain parameters
<drakonis1>
even if it'd put me outside of the cache
<ekleog>
there are already options, like the `with*` or `enable*` options
<ekleog>
but they're just not discoverable :/
<drakonis1>
if they were discoverable, it would've been a lot easier to achieve it
Synthetica has quit [Quit: Connection closed for inactivity]
<drakonis1>
i've noticed the syntax looks different
<drakonis1>
i'd take this new syntax over the old one
<drakonis1>
looks fairly pleasant
dtz has joined #nixos-dev
<dtz>
eep forgot to rejoin this :(
<dtz>
how many glorious discussions are now forever lost to me....
<domenkozar>
something I want to fix and document soon
<angerman>
oh...
orivej has joined #nixos-dev
<niksnut>
ekleog: I've made the gists public, there wasn't really a reason to mark them secret
<srhb>
domenkozar: fatal error: error in backend: IO failure on output stream: No space left on device; ninja: build stopped: subcommand failed.; builder for '/nix/store/dcs4j91lr7ijn0rzwm6h5jzplcvjj8ii-chromium-70.0.3538.77.drv' failed with exit code 1 -- urgh! :P
<domenkozar>
well that's not build jump fault
<srhb>
No no.
<srhb>
Just really unlucky.
<domenkozar>
we're unlucky with chromium on so many levels I can't even count
<srhb>
And indeed it does look very low.. I'm assuming they're all set to garbage collect automatically in face of low disk space?
* srhb
rugmmages through .org configs
<gchristensen>
look in build-machines-common
<srhb>
Oh they're not...
<srhb>
Let me make a biased PR... :-P
<gchristensen>
please :)
<domenkozar>
srhb: btw you weren't at nixcon right? :)
<gchristensen>
in the meantime I set the gc to run every hour instead of every few hours
<srhb>
domenkozar: I was not :( Next year! Promise.
<angerman>
domenkozar: so my primary issue is that it seems not to pick up on any of the pre-built artifacts in my cachix store :(
<angerman>
I tried to pre-seed the cachix store by building it locally, and then pushing everything into the store; and I could swear that worked about 3weeks ago, but suddenly stopped working for macOS like a week ago or so.
<domenkozar>
did you verify that you get same hashes?
<srhb>
gchristensen: If the stores are quite huge I'm not sure whether it really ought to take the time hit and do a big GC or try to keep it small and fast. It depends how much faster "small gc" really is.
<srhb>
(Hence the debatable)
<domenkozar>
t2-4 is building like 4 chromiums
<domenkozar>
nah, only 3
<srhb>
domenkozar: Looks good for both cpu and memory though
<srhb>
Thank goodness for metrics
<srhb>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 43
<gchristensen>
goodbye, 42
<gchristensen>
:)
<srhb>
damn!
<srhb>
Sorry :(
<gchristensen>
haha it was a joke anyway
<gchristensen>
I'm about to leave for many hours and very much don't want those chromes to fail, so I'll GC a bit extra just in case.
<gchristensen>
don't forget if there are metrics you want but aren't in that grafana graph, http://status.nixos.org/prometheus/ arbitrary queries are ok
<srhb>
Thanks!
<gchristensen>
also we could(should?) turn on user registration for grafana(?)
<srhb>
gchristensen: What's gained? Are we scared of DOS?
<gchristensen>
I have no idea
<srhb>
Personally I'd rather not see anything locked down unless we really need to. It's not easy to contribute help to the org on this side of things, and it's sort of wobbly. :)
<gchristensen>
agreed
<srhb>
Besides, it sounds low risk and quick to fix if we do get hit.
<gchristensen>
"Viewers can edit/inspect dashboard settings in the browser. But not save the dashboard." seems safe
<garbas>
we discovered quite few problems which we assumed
<domenkozar>
if you'd like a pure nix solution, then why support imperative package management?
<garbas>
well i would like both
<domenkozar>
I mean sure, you can mix&match but I think it's totally OK if you have either
<domenkozar>
I think taking some incremental steps like you said at nixcon is pretty good
<domenkozar>
but seems like you're now talking about a giant leap :)
<garbas>
depends how you look at giant leap. i can not use alpine as a base. so that solution is not for me
<garbas>
and that buildImageWithNix works, it just needs to be polished
<domenkozar>
and you also must use imperative package management cli?
<garbas>
at work no, but i imagine we would like to have fully working nix* tools inside docker image which is built with nix
<garbas>
so that we can build tarball for each nix commit on hydra
<domenkozar>
you can still do both
<domenkozar>
use buildImageWithNix for work
<domenkozar>
and use alpine based to docker per each nix commit
<domenkozar>
although I see very little benefit for that
<garbas>
why use alpine based image if you can use buildImageWithNix?
<garbas>
why even bother with dockerfile?
<domenkozar>
I mean if you get nix* tools working sure, but it seems non-trivial work
<garbas>
buildImageWithNix function works, just few details need to be polished
<garbas>
if i'd have a day to work on this (or anybody else) it would be already done
<domenkozar>
I have a list of 100 things that fit in there :P
<garbas>
:)
<domenkozar>
but I'd rather spend 10min on docker and 7h50m on hnix-lsp
<domenkozar>
I do appreciate if you guys get it done :)
__Sander__ has joined #nixos-dev
jtojnar has joined #nixos-dev
<ekleog>
niksnut: is it OK with you if I link to your gist about extensible attrsets from an issue in the nix repo, so as to be able to discuss it?
<ekleog>
(gist comments trigger no notification, so it's not really possible to discuss through that :/)
<niksnut>
sure
<niksnut>
there are a few distinct issues though (like the include mechanism)
<ekleog>
thanks! and yeah, but in the present case I'm interested in commenting mostly on the extensible attrsets proposal (once I'll have written some code to check what I'm going to say) :)
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
<clever>
gchristensen: how does the current packet.net nixos support work?
drakonis has quit [Ping timeout: 252 seconds]
tilpner has quit [Remote host closed the connection]
<ekleog>
(ok I remove the security tag from this, didn't notice we don't actually package bacula-web)
pie_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
phreedom_ has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
drakonis has joined #nixos-dev
<thoughtpolice>
Is it OK to merge master into staging? I know it was merged earlier today but I'd like to pick up my two latest commits, although unfortunately it will imply a rebuild of haskellPackages, etc since that was missed earlier today ;_;
<thoughtpolice>
Hydra hasn't built staging in a while -- was it turned off in favor of only having staging-next?
<thoughtpolice>
Really I should have just pushed these two commits directly to staging, which was my fault. (My intention here is that I'm going to push a large changeset into staging soon, and I would like to get the upstreamable-packages in an already working state)
<thoughtpolice>
*upstreamable-patches
<thoughtpolice>
That way the actual diff I have to maintain for a short while is smaller.
<dtz>
err if it's not building staging--and hasn't for a while-- it probably needs to rebuild more than just haskellPackages, right?
<dtz>
others can confirm but AFAIK master -> staging should "always" be okay, and enabling/embracing that is most of what staging-next is for
<dtz>
I propose new names: staging -> chaos; staging-next = taming-the-chaos
<dtz>
or maybe just "rebuilds-go-here" ;)
<thoughtpolice>
dtz: I mean staging hasn't been built in like over a month, though
<thoughtpolice>
staging-next seems to be chugging along fine, though
<ekleog>
dtz: +1 for the renamings, the order is just so much more clear this way :D
<ekleog>
(also, I wonder if this is not actually the problem staging is going through: people merging to staging-next while it should be to staging)
<ekleog>
(nvm, it's not: staging-next indeed received nothing but merges from master since ~oct 21 and staging's first commit is ~oct 16 so it makes sense… just staging-next that hasn't stabilized)
<clever>
nixops expects to be able to construct the nixos config from the api replies, before ssh'ing into the machine
<gchristensen>
how could that work for hetzner?
<clever>
hetzner shouldnt be at play here
<clever>
i'm using the packet-python library to create the devices
<gchristensen>
well it is relevant, since hetzner's physical spec isn't know by api I think
<gchristensen>
the metadata -> nix generator changes with bug fixes over time, and I wouldn't want to have to update two places, especially with the release speed of nixops
<gchristensen>
so this feels like a not good approach to me
<clever>
how does hetzner related to packet.net?
<gchristensen>
not related, relevant, in that it is a nixops provider which probably doesn't know physical spec at purely by API
<clever>
ah
<clever>
i also had ideas, on how to make nixops more modular
<clever>
for example, each backend could provide a way to run an arbitrary kernel+initrd, packet.net via ipxe, hetzner via kexec on ubuntu