gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
jtojnar has quit [Quit: jtojnar]
pie_ has quit [Ping timeout: 268 seconds]
markuskowa has quit [Ping timeout: 256 seconds]
<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....
<dtz> :)
<drakonis1> there's logs y'know
jtojnar has joined #nixos-dev
<dtz> <owl> the world will never know </owl>
drakonis1 has quit [Quit: WeeChat 2.2]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
MichaelRaskin has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
jtojnar has quit [Ping timeout: 252 seconds]
<domenkozar> it's errr, quite a beast
<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> That's.. Very true.
<gchristensen> when did that builder failed?
<srhb> gchristensen: 09:36, packet t2-4
<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
<srhb> Agreed.
<angerman> domenkozar: now sure what I screwed up. It finally started pulling some from the cache...
<domenkozar> nix also caches 404s
<angerman> domenkozar: that watch-store trick is neat though :-)
<gchristensen> ^ is this on topic for #nixos-dev?
<domenkozar> we're done :)
<gchristensen> srhb: (see diff)
<srhb> gchristensen: Instead of master?
<domenkozar> gchristensen: sorry for polluting :)
<gchristensen> no worries! it is easy to drift off:)
<gchristensen> srhb: w.r.t. grafana config changes
<srhb> Ooh
<srhb> I thought you meant I should retarget my auto-gc change
<domenkozar> srhb: next year sounds good :)
<gchristensen> ok time to go. god speed, chromiums 1,2,3
<srhb> gchristensen: o/
<andi-> To bad the tests will fail once they are done :/
<srhb> andi-: Oh?
<andi-> latest eval should at least pass
<gchristensen> hyda has an scmdiff api?? :O
<srhb> Yes, it's very useful :P
<srhb> (click the input changes rev1..rev2 link and you get it)
Synthetica has joined #nixos-dev
<{^_^}> docker#5 (by domenkozar, 45 minutes ago, closed): Add bash to the image
<domenkozar> to answer your question at nixcon
<domenkozar> I hope peti proposes we maintain each nix builder user in separate repo
<garbas> domenkozar: not sure which question is that
<domenkozar> the one where we make docker image somewhat useful
<garbas> i can understand the argument of no bash for when you are installing nix with no sandbox
<garbas> but when you enable sandbox you will use bash anyway inside the sandbox
<domenkozar> well once you build a script in the image
<domenkozar> you kind of want to run it with #!/usr/bin/env bash
<garbas> and the root of the problem is actually using dockefile.
<domenkozar> how so?
<garbas> because then you _have_ to be careful what you put into base docker image
<garbas> if we would have a function in nix, then things become more configurable
<domenkozar> you still have to publish that image on hub
<domenkozar> it doesn't really matter how you build it, the final size is X
<garbas> actually it matters how you build it
<garbas> and size is not always the criteria
<domenkozar> well sure, you can have less layers if you use pure nix solution
<garbas> for example i can not use this "official" docker image since it is based on alpine
<garbas> actually you want more layers, so that you can use cache
<domenkozar> anyway I'll maintain my fork, I'm happy if you work with peti on the official image to move it in the direction you want
<garbas> basically i want another function in nixpkgs buildImageWithNix
<garbas> or something similar
aminechikhaoui has quit [Ping timeout: 252 seconds]
<domenkozar> happy to see it happen :)
<garbas> yeah, me too. i found few blockers which i'm slowly trying to fix
<garbas> actually maybe you know.
<garbas> how can i do what "nix-env -i" does but within nix expression?
<garbas> basically i need to generate manifest.nix
<domenkozar> you can't
<domenkozar> that's recursive nix :)
<domenkozar> if you mean inside derivations
<garbas> yeah recursive nix could solve this, but looking the content of manifest.nix it looks like it should be possible
<domenkozar> why do you need nix-env -i?
<garbas> to create initial profile
<garbas> otherwise nix-env does not know how to build uppon what was previously installed
<garbas> that is when there is no manifest.nix
<garbas> if nothing we came up with a script that tests nix installation https://github.com/garbas/nix-docker-nix/blob/master/nix-verify.sh
<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]
drakonis has joined #nixos-dev
<domenkozar> lol, nixos on top of https://news.ycombinator.com/
tilpner has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
<ekleog> (triage) needs merge https://github.com/NixOS/nixpkgs/pull/37365 (I'm cross-posting to #nixos-security as it fixes a cvss3 9.5 issue)
<{^_^}> #37365 (by proteansec, 32 weeks ago, open): bacula: 5.2.13 -> 9.2.1
<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)
<shlevy> simpson: This is only the primitive functionality, but I think it will actually work... https://gist.github.com/shlevy/c50f848bda51f57f285faaa6f45c6a3f
<simpson> shlevy: Ha, interesting.
drakonis has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
lopsided98 has quit [Client Quit]
<gchristensen> clever: what do you want to know?
pie_ has quit [Excess Flood]
lopsided98 has joined #nixos-dev
pie_ has joined #nixos-dev
<clever> gchristensen: ive got most of the code done now for nixops to support packet.net, but there are still a few unknowns left
<clever> gchristensen: i notice that the machines have 2 NIC's in an LACP bond, are they always configured as such?
<clever> gchristensen: and is the main nixos_18_03 OS in the list just ext4 on mdadm raid?, no zfs options at present?
<gchristensen> clever: correct about ext4. your best bet is to always get the .nix files in the packet directory.
<gchristensen> the NICs are not always configured like that
pie_ has quit [Ping timeout: 245 seconds]
<clever> gchristensen: how do i detect when the nic's are in an lacp?
<clever> gchristensen: i'm trying to generate all of those nix files from python, based on the api response
<gchristensen> clever: why wouldn't you just fetch the packet.net nix files?
<gchristensen> yes, why not fetch it
<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
<clever> and then seperate from the backend, you have a way to create a base image of your design (ext4, zfs), that uses that
<gchristensen> sounds great :D
<clever> and then i no longer have your utils pre-generating nixos config on bootup, because i'm just ipxe'ing a different util
<gchristensen> anyway, the metadata to hardware config generator is here https://github.com/grahamc/packet-provision-nixos-ipxe/blob/master/install-tools/metadata2hardware.py but I would really not be thrilled to see it duplicated in nixops, especially as I'll be making more fixes to it for the 18.09 image set
<gchristensen> oh, and, anyway, it requires access to the machine for things like mac-to-nic assignments
<clever> i could probably just PR your repo, to make it possible to run it via nix-build https://example -A foo ; ./result
<clever> and then nixops can run that when not using the base nixos image
<clever> and if it is the base nixos image, i can just copy the files to the nixops state
<clever> then there is only 1 copy of that code to manage
<gchristensen> yeah... but still, it has to actually execute on the host
<clever> yeah, after the ipxe image boots, it can run that, if i choose to go that route
<clever> and then nixops can fetch the config out
<gchristensen> clever: do you need anything from Packet or from me to help you finish the work you've done?
<gchristensen> for example, free credits or something
<clever> currently i'm stuck because i lack permissions within the iohk org on packet.net
<clever> so i cant create any devices or projects
<gchristensen> I can send you an API key?
<gchristensen> orrr
<gchristensen> one minute
<clever> an apikey or an invite works, it would be useful to have the webconsole for garbage collection when nixops fails
<gchristensen> let's PM
ckauhaus has quit [Quit: WeeChat 2.2]
arianvp has quit [Quit: WeeChat 2.2]
arianvp has joined #nixos-dev
jtojnar has quit [Ping timeout: 268 seconds]
hyperfekt has joined #nixos-dev
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 268 seconds]
Drakonis__ has joined #nixos-dev
pie_ has joined #nixos-dev
Drakonis__ has quit [Quit: Leaving]
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #nixos-dev