worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
<risson> I mean, even if the `mkPamModule` returns an empty set it fails
<infinisil> Ah I see the problem
<risson> enlighten me
<infinisil> `security.pam = pamLib...`, where pamLib is `config.security.pam.lib`
<infinisil> So you have `security.pam = config.security.pam.lib...`
<risson> Ah yes indeed that won't go well
<infinisil> You should probably put the pam lib in utils
<infinisil> nixpkgs/nixos/lib/utils.nix
<risson> Which is called with lib.utils I'm guessing?
<infinisil> Then you can refer to it by adding `{ utils, ... }` to the arguments
<infinisil> In the module system
<risson> Okay, thank you so much!
<infinisil> :)
<risson> infinisil++
<{^_^}> infinisil's karma got increased to 380
<risson> good bot
__monty__ has quit [Quit: leaving]
<risson> ahhhh it feels so good when it works
<risson> i can go to sleep now
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
alp__ has quit [Ping timeout: 272 seconds]
andi- has quit [Ping timeout: 240 seconds]
andi- has joined #nixos-dev
<supersandro2000> How do we prevent that python updates are merged while they are also in python-staging?
rajivr has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
cole-h has joined #nixos-dev
ris has quit [Ping timeout: 256 seconds]
evils has quit [Ping timeout: 260 seconds]
evils has joined #nixos-dev
v0|d has quit [Remote host closed the connection]
v0|d has joined #nixos-dev
kalbasit has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-dev
sorki has quit [Remote host closed the connection]
sorki has joined #nixos-dev
justanotheruser has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
m1cr0man has quit [Quit: G'luck]
m1cr0man has joined #nixos-dev
orivej has joined #nixos-dev
stigo has quit [Remote host closed the connection]
stigo has joined #nixos-dev
alp__ has joined #nixos-dev
srk has quit [Quit: ZNC - http://znc.in]
sorki is now known as srk
thibm has joined #nixos-dev
lassulus has quit [Ping timeout: 256 seconds]
saschagrunert has joined #nixos-dev
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
lassulus has joined #nixos-dev
lassulus has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
teto has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 265 seconds]
AlwaysLivid has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 3.0]
__monty__ has joined #nixos-dev
lovesegfault has joined #nixos-dev
alp__ has quit [Ping timeout: 272 seconds]
julm has quit [Ping timeout: 256 seconds]
alp__ has joined #nixos-dev
julm has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
alp__ has quit [Ping timeout: 272 seconds]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Read error: Connection reset by peer]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
alp_ has joined #nixos-dev
FRidh has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 264 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
alp_ has quit [Remote host closed the connection]
alp_ has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
ckauhaus has joined #nixos-dev
<michaelpj> anyone got a trick for doing set intersection faster than quadratic complexity in Nix. Using lists is... pretty bad
<gchristensen> yikes
<regnat> michaelpj: attrsets of unit?
<michaelpj> do attrset lookups have sensible complexity?
<qyliss> I think they're linear
<regnat> There's builtins.intesectAttrs, which I'd expect to be faster than anything you could do on the Nix-land
<regnat> But I don't really know how they are implemented, so 🤷
<michaelpj> well, my first step is "can I get away without doing this" :D
<lukegb> import-from-derivation using a small C program for doing set intersection /s
ckauhaus has quit [Quit: WeeChat 2.7.1]
FRidh has joined #nixos-dev
justanotheruser has joined #nixos-dev
<ajs124> regnat: https://github.com/NixOS/nix/blob/master/src/libexpr/primops.cc#L2192 is the intersectAttrs implementation
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<infinisil> michaelpj: Attrset lookup is logarithmic
<infinisil> qyliss: ^
<infinisil> But yeah intersectAttrs is nice if you can use it
<michaelpj> thanks!
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
saschagrunert has quit [Quit: Leaving]
alp_ has quit [Remote host closed the connection]
alp_ has joined #nixos-dev
<gchristensen> ,tell cole-h when you're about, could you rebase https://github.com/NixOS/nixpkgs/pull/104740 to use the v0.5.1 upstream point release of packngo?
<{^_^}> gchristensen: I'll pass that on to cole-h
<gchristensen> thanks, {^_^}!
kalbasit has joined #nixos-dev
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
stigo has quit [Ping timeout: 256 seconds]
stigo has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
red[evilred] has joined #nixos-dev
<red[evilred]> Question - would this be considered a nix bug or a nixos bug?>
<red[evilred]> (I'm guessing nixos)
<red[evilred]> I want to disable sandboxing for a nixos-rebuild
<red[evilred]> which keeps failing because of the sandbox
<red[evilred]> but when I apply the nix.sandbox = false; to configuration.nix - it doesn't apply for that nixos-rebuild
cole-h has joined #nixos-dev
<red[evilred]> so I need to comment out my "errant" configuration
<red[evilred]> rebuild once
<red[evilred]> (which makes it successfully write nix.conf)
<cransom> it's not a bug for either.
<lukegb> ^
<red[evilred]> then bring in my errant, stupid, brain-dead configuration
<red[evilred]> So you wouldn't consider it not disabling the sandbox when nix.sandbox=false; a bug?
<red[evilred]> (because it's dependent on the previous state)
<red[evilred]> that sounds like an additional input to me
<lukegb> It does disable the sandbox... but it does it in the target system configuration
<cransom> that would be a bug, but how you approached it, is not a bug.
<red[evilred]> (In the grand scheme of things I don't really care too much honestly, just seemed like a breach of the normal nix contract)
<lukegb> `nixos-rebuild switch --option sandbox false` might work
<red[evilred]> I'm trying to migrate a stubbon friend of mine from 20.03 to 20.09
* lukegb but I haven't tried it so I can't remember if you can actually... set sandbox like that
<cransom> if you wanted to circumvent nix entirely, you could modify nix.conf directly and do the rebuild, or as lukegb said, which would be the better choice, disable the sandbox as a privileged user with the nixos-rebuild command just for that invocation.
<red[evilred]> What's funny is whhen you go the other way
<red[evilred]> because it "succeeds" on a machine where we know it would fail on any other
<red[evilred]> (since it's just using the cached verison)
<red[evilred]> thanks anywasy
<red[evilred]> I'm going to keep beating my head against how to make this ridiculous requirement work
<lukegb> It's somewhat the same as e.g. changing the networking configuration: that's applied at the end, not before the nix build starts, so it's not like the new config will be used for e.g. fetching things from binary caches
<lukegb> The nixpkgs config in configuration.nix is more hermetic in some senses but that's just nix expressions all the way down :P
<risson> Is it possible to rename from a submodule to a submodule? Smoething like mkRenamedOptionModule [ "old" "*" "oldOption" ] [ "new" "*" "newOption" ] ?
<risson> Same question for mkRemovedModule actually
<risson> I'm not fluent enough in nix/NixOS to fully understand the source code of those
alp_ has quit [Ping timeout: 272 seconds]
<infinisil> risson: Unfortunately not really atm. However it would be possible with https://github.com/NixOS/nixpkgs/pull/97023, which I should probably push forward
<{^_^}> #97023 (by Infinisil, 12 weeks ago, open): Module-builtin assertions, disabling assertions and submodule assertions
stigo has quit [Read error: Connection reset by peer]
stigo has joined #nixos-dev
kalbasit_ has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
<clever> gchristensen: on the main hydra, can you run `journalctl -u hydra-update-gc-roots -t systemd`, and compare the started and stopped time, how long does the service take to run?
pinpox is now known as |^_^|
|^_^| is now known as pinpox
ris has joined #nixos-dev
pinpox is now known as |^_^|
|^_^| is now known as pinpox
<risson> infinisil: ohhh I so want this i wanted to put some assertions in submodules and ended up giving up because I couldn't do it cleanly
<infinisil> I'm actually just trying to work on that PR, hope to have it merged soon :D
<gchristensen> I didn't mean that to be dismissive, but a "actually, check this out" kind of way
<gchristensen> (I'm sorry that it was dismissive)
alp_ has joined #nixos-dev
<hexa-> public data <3
* clever looks
<clever> gchristensen: under 10mins i see, we found it taking 5 days
<risson> infinisil: nice! how about #97392
<{^_^}> https://github.com/NixOS/nixpkgs/pull/97392 (by Infinisil, 12 weeks ago, open): Introduce `types.orderOf`
<infinisil> That one I'm not sure about
<infinisil> Because it's doable without that option
<infinisil> By just using the underlying functions of it directly
<infinisil> It's just a tad less convenient
<clever> gchristensen: hmmm, and do you believe the postgres indexes match the hydra source?
<gchristensen> it isn't guranteed .... but it is probable
<clever> hydra=# create index on public.builds (finished, jobset_id, buildstatus) where finished = 1 and buildstatus in (0,6);
<clever> gchristensen: creating this index got our hydra-update-gc-roots, to go from 5 days of runtime, to 6 minutes
<risson> less convienent, and you have to re-implement the cycle check every time you want to do something like this
<risson> which seems to be a few places in nixpkgs
<infinisil> Hm yeah
<risson> in my opinion, having an option, or a function, any type of abstraction, that is well tested and proven is better than re-doing it in each module that needs it
FRidh has quit [Quit: Konversation terminated!]
<infinisil> risson: Can you argue your points in the PR for reference?
<risson> infinisil: right away
Cale has quit [Ping timeout: 240 seconds]
Cale has joined #nixos-dev
mkaito has quit [Quit: WeeChat 2.9-dev]
alp_ has quit [Remote host closed the connection]
alp_ has joined #nixos-dev
puck has quit [Remote host closed the connection]
puck has joined #nixos-dev
thibm has quit [Quit: WeeChat 2.6]
<infinisil> So I have a PR which needs rebasing to fix conflicts
<infinisil> But by rebasing, I'm also introducing an error, which is not detected by merge conflicts
<infinisil> This means, pretty much all commits of my PR now have a mistake in them and can't be used for e.g. bisecting
<infinisil> Should I prefer merging master into my PR because of that?
<infinisil> I know rebasing is encouraged, but I feel like this might be a case where merging is actually better
<samueldr> add a commit at the start of your PR that fixes that mistake?
<infinisil> Well it's an error introduced over multiple commits. In particular it's https://github.com/NixOS/nixpkgs/pull/101139 which causes the problems
<{^_^}> #101139 (by roberth, 5 weeks ago, merged): lib: Use Nix's static scope checking, fix error message, optimize
<infinisil> My PR assumed all variables were available in the dynamic `with *;` scope, but after rebasing on top of ^^ this isn't the case anymore
<samueldr> if it was a patch-driven development methodology, you'd rewrite each of your commits individually I think
<infinisil> So I'd have to go through each commit, make sure it works, fix any errors by making it refer to `lib.*` variables explicitly
<infinisil> And that's kind of a pain. Whereas merging master would be so much easier, as I could just fix up the merge commit with these changes, and bisection would handle it just fine
<samueldr> but I guess you could also merge and not care for your specific change set, it's not like it would be the first change set that doesn't work when bisected through
<samueldr> it's not like we have a strict rule that all change sets have to be rebased
<infinisil> Yea
<infinisil> I
<infinisil> I think I'll go for merging master into the PR and seeing if anybody complains :)
<samueldr> but yes, I think the "right" way to do it in such a situation would be to handle fixing all of the commits
<samueldr> all of your commits
<infinisil> I'm not sure
<samueldr> in a workflow that's like the kernel, yes it would be
<qyliss> infinisil: I'd fix every commit, but if you don't want to do that the second best would just be a merge commit IMO
<infinisil> I guess #101139 makes this actually pretty nice, since Nix will throw errors of unknown variables immediately when parsing a file
<{^_^}> https://github.com/NixOS/nixpkgs/pull/101139 (by roberth, 5 weeks ago, merged): lib: Use Nix's static scope checking, fix error message, optimize
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<infinisil> So I don't need to test every code path
<infinisil> Oh and here's another reason why a merge would be better: I now needed to fix a whole bunch of merge conflicts only introduced by fixing up intermediate commits
<infinisil> I'll just do a merge next time, this is like a prime example of when a merge is much better than a rebase
<samueldr> with some projects the workflow simply does not allow it
<infinisil> Why is that btw?
<samueldr> thinking about the usual worshipped git through e-mail workflow
<samueldr> you will not have a git branch
<samueldr> you send out patches
<infinisil> Oh, guess that makes sense in that case
<samueldr> so you can't really simply have a git merge commit in there
<samueldr> but yeah, here the tooling allows it so eh
<qyliss> samueldr: well, the maintainer can still make a branch and do a merge
<samueldr> yep, but AFAIK (could be wrong) that's more for merging the maintainer tree's multiple accepted changes together, rather than single contributions, no?
<risson> infinisil: what's the PR?
<{^_^}> #97023 (by Infinisil, 12 weeks ago, open): Module-builtin assertions, disabling assertions and submodule assertions
<qyliss> a/go
<qyliss> whoops
<qyliss> samueldr: yeah, but there's nothing stopping them in principle
<risson> ah yes indeed
<risson> you'll face the same problem with #97392 but it'll be easier as there's only one commit
<{^_^}> https://github.com/NixOS/nixpkgs/pull/97392 (by Infinisil, 12 weeks ago, open): Introduce `types.orderOf`
<risson> however, you could edit your commits one by one and add the missing functions to the inherit statements
<infinisil> Yeah that's what I did now
<infinisil> Well not exactly, I just used lib.*
<risson> works too I guess :D
<risson> wouldn't that make it inconsistent with the way it's done in other functions though?
<infinisil> risson: I guess yeah, but it's just much easier, and using lib.* doesn't get rid of the static scope checking benefits
<risson> okay :)
__monty__ has quit [Quit: leaving]
aminechikhaoui has quit [Read error: Connection reset by peer]
aminechikhaoui has joined #nixos-dev
srk has quit [Ping timeout: 240 seconds]
srk has joined #nixos-dev
<qyliss> > error: a 'aarch64-linux' with features {} is required to build '/nix/store/cwxwjd39kp9mhfynwfg1l7plfw3cz5ra-nixos-manual-combined.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}
<{^_^}> error: syntax error, unexpected $undefined, expecting ')', at (string):440:10
<qyliss> uhhhh
<qyliss> how do I build the manual?
<infinisil> nix-build nixos/release.nix -A manualHTML.x86_64-linux
<qyliss> ah, that's yet another thing that needs to be fixed in the manual then P:
<qyliss> *:P
* infinisil adds it to the 1 meter high stack of doc issues
<qyliss> oh actually that one appears to have been fixed already
* infinisil removes it from the still 1 meter high stack of doc issues
<qyliss> infinisil: want to review a fix for one, and get that pile 1mm smaller? :P
<infinisil> qyliss: Let's goo
<qyliss> infinisil: #105515
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105515 (by alyssais, 2 minutes ago, open): nixos/manual: don't recommend nix-env -iA
<infinisil> Nice
<infinisil> Oh wait
<infinisil> Not recommending -A?
<infinisil> Ah
<infinisil> On NixOS, got it
<infinisil> It is the NixOS manual duh
<ryantm> We still need more shepherd volunteers on https://github.com/NixOS/rfcs/pull/80 please self-nominate. If you want to know what a shepherd does, please look at https://github.com/NixOS/rfcs/blob/master/rfcs/0036-rfc-process-team-amendment.md
<{^_^}> rfcs#80 (by jonringer, 1 day ago, open): [RFC 0080] Change NixOS releases to YY.05,YY.11
immae has quit [Quit: WeeChat 2.9]