samueldr changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 19.09 is released! | | | 19.09 RMs: disasm, sphalerite |
evanjs has quit [Quit: ZNC 1.7.4 -]
evanjs has joined #nixos-dev
evanjs has quit [Client Quit]
evanjs has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 -]
evanjs has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
justanotheruser has joined #nixos-dev
cjpbirkbeck has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 -]
evanjs has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
cjpbirkbeck has quit [Quit: Quitting now.]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
Synthetica has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
tilpner_ is now known as tilpner
__monty__ has joined #nixos-dev
asymmetric has quit [Read error: Connection reset by peer]
asymmetric has joined #nixos-dev
FRidh has joined #nixos-dev
justanotheruser has quit [Ping timeout: 268 seconds]
<qyliss> I've noticed staging PRs being added to a GitHub Project recently. What does that mean? Is there some kind of special process for staging PRs? Should I not be merging them like before?
<gchristensen> probably keep doing your thing, maybe someone is experimenting
<qyliss> okie
<FRidh> qyliss: I started with this recently. It's mostly just for myself to keep track of all the PR's for staging so I don't forget about any
<qyliss> keep track of them for what reason?
<FRidh> qyliss: to get them in in a reasonable time. It's not uncommon they linger when no one pushes for them.
* qyliss nods
<qyliss> I worry that doing this with a project just called "Staging" will make them linger even longer -- people might assume somebody else is taking care of them
<qyliss> Or even, is explicitly claiming responsibility for them.
<qyliss> That's how it felt to me, at least.
averell has quit [Remote host closed the connection]
<FRidh> Maybe. So far the majority of people don't merge them themselves in staging, either because they're not comfortable with it, don't know they're allowed to, forget about it, or indeed think someone will do it for them. Let's see if people comment about it.
<FRidh> I would just like to see more reviewing of these PR's, with an explicit approved. Maybe if they see "needs review" that will trigger them?
<gchristensen> the staging process to me still feels a bit washy
<gchristensen> I mean, I don't understand it
<FRidh> yea, we really need a small staging job
<FRidh> Even without its been a big improvement though. Before it would happen almost all the time that during early stabilisation someone would push another mass-rebuild postponing the whole delivery by another day or two. Now that does not happen anymore.
<hyperfekt> Does anyone have an inkling how much of an effect wrapping the stdenv cp with reflink=auto would have?
<hyperfekt> I keep finding myself using that argument in build scripts but I can't tell if it's actually worth it - or if it is, maybe it should be in nixpkgs....
<gchristensen> what filesystems support that?
<qyliss> I've always understood that I should merge to staging just like I merge to master
<hyperfekt> the CoW ones (ZFS, btrfs, bcachefs, possibly XFS?)
<qyliss> And then ??? somehow those changes end up in master
<qyliss> There's staging-next, and somebody (FRidh?) fixes up all the build failures
<qyliss> And then they arrive in master and there's a new staging-next
<qyliss> That's my understanding.
<gchristensen> zfs doesn't support cp with reflink
<hyperfekt> But auto falls back to normal copy if it's not supported. My understanding is that this only isn't the default behavior because it breaks the expectation of redundancy people have of cp.
<qyliss> But it is not a very solid understanding
<qyliss> I'd love to see a talk on it.
<hyperfekt> gchristensen: Well, I guess ZoL doesn't support a lot of things..
averell has joined #nixos-dev
justanotheruser has joined #nixos-dev
<FRidh> qyliss: there is an rfc on the topic. It's being followed, aside from a hydra job for staging I also added a brief explanation on the channels to the nixpkgs manual recently
<FRidh> though I would prefer a more elaborate section describing not only branches but also the channels
<qyliss> oh, nice, thanks
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
psyanticy has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
<LnL> niksnut: hmm I think the experimental-features option also disables nix repl, is that intentional?
<gchristensen> we can't make functionality released go away :o
<qyliss> gchristensen: we've been talking about this a bit in the flakes shepherding
<qyliss> The Nix 2.0 is theoretically unstable
<qyliss> But that was never made clear enough
<gchristensen> yeah, exactly
<qyliss> So do we now just have to stabilise it? Or do we dig in, and say "No! This is unstable!" and break it.
<LnL> yeah, all of the nix subcommands are marked as experimental
<LnL> I do like the idea of putting them behind a feature flag
<qyliss> I do too
<qyliss> Certainly new ones definitely should be until they pass an RFC
<gchristensen> and yet nixos-install and other tools published use the `nix` commands. the message was so unclear, we can't just make them go away
<LnL> oh? I thought it was a only a builtin that changed and was needed
<qyliss> Nah nixos-install has been doing it for as long as I've been using NixOS
<qyliss> I think I am reluctantly leaning towards we have to stabilise them.
<qyliss> And make ABSOLUTELY SURE this doesn't happen again.
<gchristensen> I don't think we *have to* stablise them, but we cannot simply make them go away
<qyliss> What's the difference?
<qyliss> People are relying on them, presumably. And for them, it either works or it doesn't.
<gchristensen> next release can say "this command will go away in 2020-03-01, use this instead: ..."
<qyliss> Oh, deprecate them?
<qyliss> I hadn't considered that.
<gchristensen> in stderr at every call site
<qyliss> I like that.
<qyliss> "this command will go away in 2020-03-01 *unless you enable experimental-features*"?
<gchristensen> perhaps, sure
<qyliss> I like the sound of that
<qyliss> Even then I think the deprecation period would have to be quite a bit longer, though.
<qyliss> It would have to be deprecated for at least one NixOS release
<qyliss> Or people wouldn't even see the deprecation warning.
<gchristensen> well we can backport the deprecation to 19.09
<qyliss> I suppose
<qyliss> I guess it's not exactly difficult to change 'nix build' to 'nix-build'
<qyliss> (with all the argument differences, etc)
<qyliss> Annoying, though.
<LnL> nix-build + nix build + ? is also going to be confusing and awkward however
<arianvp> Hey gchristensen ofborg seems to be going on a weird spree where it is notifying basically everyone
<{^_^}> #72884 (by fooker, 3 hours ago, open): nixos/networkd: Fix allowed values for IPv6PrefixDelegation
<arianvp> Is this a bug?
<gchristensen> oops
<gchristensen> let's see
<gchristensen> fooker requseted those reviews
<gchristensen> because of codeowners
<lopsided98> That looks like the result of changing the base branch
<gchristensen> exactly
<gchristensen> ofborg has logic to not request a lot of people's reviews to avoid that, but github's codeowners doesn't
<LnL> yeah, perhaps with the actual review implementation now we should just replace it
<gchristensen> I'm very hesitant to add write access to ofborg, but also interesting would be an ofborg merge-base rebase
<LnL> we could post instructions
<qyliss> I've thought about that before
<qyliss> We should have a bot that posts instructions for how to rebase properly if somebody is targeting the wrong base
<gchristensen> that would be basically trivial for ofborg to do as a factoid
<Taneb> qyliss: when would these instructions appear?
<gchristensen> `@ofborg rebase staging` <- ofborg posts instructions to rebase on to staging
<Taneb> So, when someone asks for it
<LnL> or even automatically based on rebuuld count for master->staging specifically
<gchristensen> that has the unfortunate side effect of meaning we need to decide on when it should go to staging :)
<FRidh> 501+
<infinisil> gchristensen: Technically the bot could even do it for them, though I don't think people would like automatic force pushes :)
<gchristensen> infinisil: exactly, I am very hesitant to add write access to ofborg
<LnL> we don't have a hard rule but in general it's pretty clear I think
<gchristensen> FRidh: realy?
<gchristensen> lgtm
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<qyliss> The bot can only do it for them if they checked the appropriate checkbox, anyway
<qyliss> But we don't need heuristics -- we should be able to accurately detect when this has happened.
<gchristensen> if we do it after it has happened, it is too late
<qyliss> If you're proposing merging commits into master that are already in staging, or vice versa, but are also adding new commits, that's almost certainly a bad base.
<qyliss> gchristensen: not necessarily
<qyliss> some code owners get notified when the PR is opened
<qyliss> nothing we can really do about that
<gchristensen> yeah but that is fine
<qyliss> But _even more_ get notified when it's rebased improperly
<gchristensen> right
<qyliss> I'd say most of the notifications I get that I shouldn't get come from it being rebased
<gchristensen> and how do we detect an improper rebase before it happens?
<qyliss> We can't in the general case
<qyliss> But we can detect the case where somebody is trying to merge 300 commits from master into staging
<gchristensen> ah
<qyliss> Which happens a lot and will almost always lead to a bad rebase because of GitHub's terrible UI
<qyliss> This isn't a silver bullet
<qyliss> But a big proportion of the invalid notifications I get would be addressed by this.
<qyliss> Not 100%, or even 50%, but more than 10% I reckon.
<qyliss> It should be a pretty simple bot too.
<qyliss> The other thing we could do is detect invalid rebases and notify people after the fact of how to do it next time
<qyliss> So at least it should only happen once per person.
<FRidh> gchristensen: indeed, those suggestions
<FRidh> gchristensen: by the way...I *really* would like to see a way to give information based on paths that are changed. E.g. , if something in python-packages.nix is changed, the post will contain a snippet with instructions or so about that
<gchristensen> ah right yes
<FRidh> seems quite similar :)
<LnL> heh, relevant question in #nixos
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 240 seconds]
evanjs has quit [Quit: ZNC 1.7.4 -]
evanjs has joined #nixos-dev
evanjs has quit [Client Quit]
evanjs has joined #nixos-dev
orivej_ has quit [Ping timeout: 268 seconds]
<jtojnar> is there __ attribute for // operator?
<gchristensen> I'm scared to ask why
<gchristensen> oh yeah nice
<jtojnar> or better, alias it to mkMerge
<jtojnar> would need to work better than c++ operator methods, otherwise it would still allow attrset // module, though
FRidh has quit [Quit: Konversation terminated!]
justanotheruser has quit [Ping timeout: 268 seconds]
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
ris has joined #nixos-dev
<jtojnar> perhaps adding support for `__mergableAttr : bool` Nix would be enough
psyanticy has quit [Quit: Connection closed for inactivity]
<infinisil> Hmm..
<infinisil> Aw jeeze
<infinisil> jtojnar: Btw you can check `nix-instantiate --parse -E '{} // {}'` vs '1 - 2'
<infinisil> The first returns just ({ } // { }), but the latter returns ((__sub 1) 2)
<infinisil> This is why assigning to __sub works, but __intersectAttrs doesn't
drakonis1 has quit [Quit: WeeChat 2.6]
<jtojnar> thanks, that is cool
drakonis_ has joined #nixos-dev
<tilpner> infinisil: Why does '1 + 2' parse to (1 + 2), but '1 - 2' parses to ((__sub 1) 2), when there's __add?
<infinisil> tilpner: __add can't be overridden, same as with __intersectAttrs
drakonis1 has joined #nixos-dev
<tilpner> Do you know why?
<infinisil> Because of the above
<tilpner> No, why can't __add be overridden?
<infinisil> The parser parses "x + y" as literally "x + y"
<infinisil> Whereas "x - y" as "__sub x y"
<tilpner> Yes, I said that in the question
<infinisil> So changing __sub in a let in makes the variable change
<infinisil> But changing __add doesn't make + change
<tilpner> But I don't understand why the parser does that
<infinisil> I don't either xD
<infinisil> It just does!
<infinisil> Maybe it served some purpose at some time
drakonis has quit [Ping timeout: 268 seconds]
drakonis_ has quit [Ping timeout: 264 seconds]
<tilpner> Huh, (-1) parses as ((__sub 0) 1)
<tilpner> It's weird, -, *, and / all parse as functions, but + doesn't
<infinisil> Ah that's most likely because it's also string concat
<samueldr> yes, exactly
drakonis1 has quit [Ping timeout: 246 seconds]
drakonis1 has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<tilpner> I don't really see why __add couldn't handle different types, except perhaps speed or convenience
<infinisil> Yeah it's probably possible
<infinisil> But being able to even do this with __sub should not be done anyways :P
<samueldr> it's an artifact of the implementation, IIRC from the observation clever and I made
<tilpner> But I don't have a good reason for any of them being overrideable, so...
<infinisil> jtojnar: Oh hey, I figured out a way to make it fail when mkIf ... // mkIf ... is done
<infinisil> The idea is to make `mkIf a b` return a function, because you can't // functions
<infinisil> Then when it needs to be read, just pass some argument to get the actual value
<infinisil> It is a bit hacky though, and a bit backwards incompatible, so I'm not sure if it's upstreamable
<jtojnar> infinisil++
<{^_^}> infinisil's karma got increased to 157
<jtojnar> let's try to change it and see if anyone complains 👾️
<gchristensen> it is a bit ugly since the error is not useful
<infinisil> That too
<infinisil> But a misleading error is better than no error still
drakonis1 has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
<infinisil> jtojnar++ for finding this!
<{^_^}> jtojnar's karma got increased to 14
asymmetric has quit [Changing host]
asymmetric has joined #nixos-dev
drakonis1 has quit [Ping timeout: 250 seconds]
<worldofpeace> Jan Tojnar: preTestScript? not meant to extend the test but a snippet to run for extra setup for the runner
<worldofpeace> jtojnar++
<{^_^}> jtojnar's karma got increased to 15
<worldofpeace> jtojnar++
<{^_^}> jtojnar's karma got increased to 16
<jtojnar> worldofpeace that sounds okay
<worldofpeace> Jan Tojnar: pushed. Didn't respond to the structuredAttrs comment, tbh I forget what this was... (too much stuff to keep up with)
<jtojnar> worldofpeace just that we might want the arguments to be list, though __structuredAttrs will not really be used here
<jtojnar> __structuredAttrs will allow passing arrays to bash directly, instead of as strings:
<{^_^}> #72074 (by globin, 1 week ago, open): stdenv: enable __structuredAttrs
<jtojnar> (well serialized as JSON IIRC, but still structured)
<globin> jtojnar: also bash arrays
<globin> worldofpeace, jtojnar: I'm writing a blog post on how structured attrs works
<globin> as a lot of people aren't really aware of even its existence
<globin> there is also a
<worldofpeace> globin: right, some docs will be needed eventually though. but a blog post will be more accessible atm
<jtojnar> globin++++
<jtojnar> globin++
<{^_^}> globin's karma got increased to 9
<globin> yeah docs are needed when a lot of the work on the branch builds & probably an rfc even berfore that
<globin> but at least I think I'm aware of the issues there are with it and how to fix them now
<jtojnar> I would also like to see some explanation how does `placeholder` actually work
<gchristensen> it writes out special marker bytes which are nulled during hashing
<jtojnar> I am mostly interested in when is the marker rewritten to the actual output path
<gchristensen> ah
<globin> jtojnar: during eval placeholder "out" is replaced by the hash of out ( and then nix-build iterates over all drvs outputs and replaces them back (libstore/, grep for hashPlaceholder in nix for the exact code location
<jtojnar> hmm, that means we cannot really pass placeholder of a package to substituteAll
<clever> > builtins.placeholder "out"
<{^_^}> "/1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9"
<clever> its a constant string, no matter what package its a placeholder for
<clever> and ive found it eratic as to which attrs will even get it replaced in, havent tracked down why
<jtojnar> it would be nice to extend it with derivation argument, but that still would not work for the substituteAll use case, since substituted patch would depend on the package and package on the substituted patch
<clever> in the past, ive wanted to put an absolute path into a .desktop file
<clever> but the function to make the .desktop file is a derivation
<clever> and i cant copy that drv into the thing it has a path to
<clever> infinisil: i would have done { = "foo"; = mkIf "bar"; };
<clever> infinisil: that avoids the // and i believe still behaves the same way
<clever> though your PR to solve the other errors is still good
<infinisil> clever: Ah true, could be done that way in that case
<clever> another thing, is that with mkMerge from your example, nixos cant know what keys exist in some.option, and that may cause infinite recursion
<clever> none of the values in some.option can depend on the others (i think)
<clever> while with ` = mkIf bool "bar"`, it knows that .bar may have a value (which might be default or undefined)
<clever> and lazyness can route around it
<infinisil> Yeah I've had to debug this too at some point
<clever> part of it, is that attribute sets are strict in the key names
<clever> so, you must be able to resolve every key in the set, and create thunks for each value, before you can index into a certain key
<clever> so you must know if .bar is present or not, before you can read .foo
<clever> = mkIf bool "bar"; means that .bar technically does exist
<clever> but if the bool was false, and there is no default, accessing it will throw an exception
<{^_^}> #70138 (by Infinisil, 5 weeks ago, open): lib/types: Introduce lazyAttrsOf
<clever> i think the complication/problem, is that the module system cant inspect .bar lazily, to see if its a thunk or not, and defer things
<clever> ah, i did glance at that when i saw it scroll by
orivej has quit [Ping timeout: 240 seconds]