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
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
<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>
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
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>
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