<infinisil>
I have written code that can disallow declaring options named `config` and `options`
<infinisil>
Because those are ambiguous: Should `{ options = ...; }` be interpreted as declaring a new option or should it be the same as `{ config.options = ...; }`?
<infinisil>
All well, but there's a problem, namely that fileSystems.<name>.options exists already
<infinisil>
I guess the best option is to add some more code to allow exceptions, such that I don't need to rename this option
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
cransom has joined #nixos-dev
init_6 has joined #nixos-dev
drakonis has quit [Remote host closed the connection]
vcunat has joined #nixos-dev
xeji has joined #nixos-dev
orivej has joined #nixos-dev
vcunat has quit [Ping timeout: 252 seconds]
<LnL>
I'm having trouble figuring out hoe to check whether a store path has a root
<LnL>
isn't there something in the store api to do that?
<vcunat>
I know too little about these things. In general I'd be careful about grub, as that's a special place that can prevent you from rolling back the system (in an easy way).
<gchristensen>
I agree, I think it would be a mistake
<xeji>
After a quick glance I think the tests require more testing, so I wouldn't merge them yet. Risk of channel blocking.
<gchristensen>
we shouldn't compromise on tests on our one weak spot
<samueldr>
in that particular instance, the change is really miminal, I had it tested without-tests as 100% positive on my end
<samueldr>
and the installer tests test the bootloader for non-child-configs
<samueldr>
I have ported their tests to be (imho) cleaner
<samueldr>
though yeah, I understand that it is a iffy situation and will not (which is why I asked)
<samueldr>
vcunat: does the senior or junior RM handle the branch-off?
<vcunat>
When I asked the previous pair, they told me the tradition was for the junior to be the "main one" with the senor providing help, experience, etc. where needed.
<samueldr>
thanks
<vcunat>
I understand that may seem contrary to intuition to some people :-) I'm not opposed to arranging something else if it seems better.
<samueldr>
nah, feels alright, just don't want to have clashes!
<samueldr>
oh... I'll need to setup GPG signing it seems (following the doc!)
<vcunat>
I suppose this all started from the fact that the first manager was on duty for way too long, so he wanted to get relieved as soon as possible.
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
in a way, if the senior does all, the junior becomes a lossy abstraction going forward :)
<vcunat>
Over the past couple years I got into the habit of signing all commits. Only the initial setup seemed relatively complex, and perhaps amending the workflow/habits.
<niksnut>
2.1 release incoming
<gchristensen>
yay!
<gchristensen>
niksnut: what would you think about showing docs for Nix from the 2.1-maintenance branch instead of the current 2.1 release, so docs can be improved and not require a release for them to hit the website?
<samueldr>
oops
<samueldr>
turns out I had garbage tags into my history :/
<samueldr>
should've trusted my instincts and gone with a clean clone
<gchristensen>
at least you didn't push 100 ancient private branches to nixos/nixpkgs.git
<samueldr>
yet
<gchristensen>
an accident which has happened in the past :)
<vcunat>
git push --tags
<vcunat>
Hmm, we should improve that instruction in the manual to be safer.
<gchristensen>
not uncommon on Hydra unfortunately
<samueldr>
gchristensen: for 18.03 there was an aarch64 jobset, just to confirm, there isn't one for 18.09, right?
<gchristensen>
oh there should be probably
<vcunat>
I haven't looked at what's changed about the status. There was a jobset, but nixos tests weren't workable (reportedly), so there wasn't a channel.
<gchristensen>
ah
<vcunat>
Anyway, we can set it up the same and later change it if new information is found.
<aszlig>
samueldr: hm, can we get that PR (#45930) also into 18.09?
<aszlig>
andi-: and i intend to get this in nixpkgs at some point, but i want to rewrite it first to get rid of the c++/c mixture
<aszlig>
andi-: not sure about which language to use... i'm tending towards rust, but i'm not sure about the closure size (eg. if that's to be used during initrd or something like that)
<andi->
lately the colosur esize for some of my rust programs increased to a few hundred megabyte.. probably due to added dependencies and dependencies on linux-headers, binutils etc.. For things used very early I like C since it make accidential dependencies harder :-)
obadz has quit [Ping timeout: 240 seconds]
obadz has joined #nixos-dev
vcunat has quit [Quit: Leaving.]
goibhniu has quit [Ping timeout: 272 seconds]
<aszlig>
hm, otoh i highly doubt it will be used during initrd because it needs nix to query the runtime paths
xeji has quit [Quit: WeeChat 2.1]
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
drakonis_ has quit [Remote host closed the connection]