justanotheruser has quit [Ping timeout: 252 seconds]
justanotheruser has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
ajs124 has joined #nixos-dev
cransom has quit [Ping timeout: 268 seconds]
cransom has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
delroth has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
__Sander__ has joined #nixos-dev
atriq is now known as Taneb
delroth has joined #nixos-dev
__monty__ has joined #nixos-dev
justanotheruser has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
<andi->
Are we ignoring module parameters during stage1 on purpose? I'd like to set some ZFS arc settings but apparently I can't because I load the ZFS module in stage1 already (since root is on that).
<clever>
andi-: you can set module params on the kernel cmdline
<andi->
It seems like a two line fix to support custom module parameters during boot
<andi->
clever: but then I have two places where I have to maintain them?
<clever>
71 kernelParams = [
<clever>
76 #"zfs.zio_taskq_batch_pct=50"
<clever>
andi-: i think the ones on the cmdline override at modprobe time also
<clever>
id have to double-check the docs
<clever>
the cmdline also lets you set options for "modules" that are compiled into the kernel (and thus, not actually modules)
<andi->
I am aware of that but that feels like a hack when we could just properly support our module options in stage1
<andi->
how would that help with having non-boot related options rebuild the initrd?
<clever>
then, you filter that down, based on boot.initrd.availableKernelModules and boot.initrd.kernelModules
<andi->
ok
<clever>
so only the modules present in the initrd can have their config in the initrd
<clever>
but, that wont deal with closure stuff
<clever>
boot.initrd.availableKernelModules = ["zfs"] will also give you spl, but the nix layer wont know of spl
<andi->
It sounds like a neat hack but it stays a hack ;-)
<andi->
We could have a builder that inspects the module closure and filters all the parameters in the build phase and just spits out a file to be included in the initrd. Best case the output is the same but that still triggers a rebuild until we have some kind of cut-off.
<clever>
wont work
<clever>
the output hash, is based on the input hash
<clever>
so any filtering it does, wont impact the output hash
<clever>
and it will still rebuild the initrd, if a filtered element changes
<clever>
the filtering has to happen at eval time, before the derivation is made, and you would need IFD to obey the closure
<andi->
with closure of modules I meant to use stuff like `modinfo` to inspect modules in the build phase. You are right about the rebuilds.
<clever>
i think that filtering issue already exists in the initrd
<clever>
if i add something to boot.kernelPackages (such as wireguard), and dont enable it in the initrd
<clever>
the code to generate an initrd will still get new inputs, and have to re-filter the closure based on boot.initrd.availableKernelModules
<clever>
so it would (in an ideal world) produce a bit-identical initrd
<clever>
gchristensen: would that be something your thing could test for?
<gchristensen>
what thing?
<clever>
r13y i think it was spelled
<gchristensen>
oh r13y sure
<clever>
this is a special case where 2 different derivations should produce identical output
<clever>
rather then the same drv producing the same thing each time
<clever>
infinisil: was it you that was doing the modules stuff for nixops?
kreisys has joined #nixos-dev
<clever>
infinisil: kreisys has been working on something similar
<kreisys>
infinisil: plz let me know if there are any good reasons NOT to do this. I kept expecting a brick wall but it never happened. It actually works really beautifully and with almost no code...
<infinisil>
clever: kreisys: I worked on something like that yes
<infinisil>
Recently when I did another test I actually couldn't find anything that didn't work
<infinisil>
With nixos as a submodule
<infinisil>
I previously thought something didn't work
<infinisil>
And I still think something has to not be working, something about options defined in imports defined in config assignments
<kreisys>
infinisil : my approach was potentially less ambitious: I just use a single entry point which calls evalModules, massages it a tiny bit to end up with the format that nixops expects and voila.
<kreisys>
doesn't have to be a single entrypoint either... you can mix and match... nixops doesn't care.
<infinisil>
kreisys: Oh so you're still using nixops to do the evaluation and building?
<kreisys>
yeah I didn't want to change nixops because I wasn't sure it's something that's desirable upstream
<infinisil>
Yeah I don't want that, because it has terrible performance if machines depend on each other. I'm trying to solve this by allowing a single evaluation for all machines (nixops does it separately for each)
<kreisys>
Like show-stopper terrible?
<infinisil>
Yes, with n machines that depend on each other you have n^2 eval time
<infinisil>
And each of them is about a nixos-rebuild switch
<infinisil>
(which is slow already)
<infinisil>
Not a problem with low number of machines, but quickly gets a problem with more
<kreisys>
So at what point that your approach yield back to nixops?
<kreisys>
s/that/does
<kreisys>
each node is a submodule instead of a separate call to eval-config?
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
<infinisil>
kreisys: Yeah
<infinisil>
nixops would have to be changed to use this
<infinisil>
And that's probably not backwards compatible
<infinisil>
So i'd make a separate project for that
avn has quit [Remote host closed the connection]
<kreisys>
Is there code I can try out somewhere? I really don't want to go back to the "old" way
drakonis has joined #nixos-dev
<kreisys>
But n^2 can become a problem at some point 🙄
<worldofpeace>
Jan Tojnar: oh totally ++ Especially for a terminal programs, that's just going to cause a bunch of issues.
<infinisil>
kreisys: Nah sorry don't have anything online I think
<infinisil>
Maybe I'll get to that eventually
<infinisil>
Well it's not usable anyways
<infinisil>
Eh no it kinda is
<infinisil>
But it needs cleaning up and stuff
<infinisil>
And testing
<kreisys>
Well as I said, I really don't want to go back to the old way. I drank the koolaid so I'm very interested in helping with this.
<worldofpeace>
Right, so it's structural settings but those options too.
<infinisil>
Hm, the next step in the RFC I wanted to do is to implement the json types and such
<infinisil>
So we can have some good examples
<infinisil>
Maybe looking at `git log -S settings nixos/modules` gives some examples, recently some have been added
<worldofpeace>
Exactly, those types would make stuff look less manual
<worldofpeace>
Thanks, I'm thinking maybe I can just suggest the `settings` option. but I might have to check if the config is well documented (hint, freedesktop things aren't usually like that for conf's)
<drakonis>
freedesktop things use ini formats don't they?
<drakonis>
oh i read it wrong, carry on.
<drakonis>
badly documented most of the time.
<worldofpeace>
like you read the config in tree and there's comments. but at least that's something.
<worldofpeace>
umm, I might not suggest structural settings. I'm not sure if it's worth to ask for a very simple configuration.
<infinisil>
worldofpeace: As long as there's no extraConfig option it can be introduced later too
<infinisil>
if necessary
<worldofpeace>
Totally infinisil. I'm seeing if/when the RFC gets accepted we'll have a pathway documented so maintainers can migrate their modules over.
<infinisil>
Yeah that might be nice
<infinisil>
There will be a discussion on rfc 42 this thursday, hoping we can push it soon :)
<worldofpeace>
Just thinking ahead for when a trend catches fire. An organized effort is always nice.
<worldofpeace>
I'm pretty pleased with it, it's a great RFC.
<drakonis>
it'll deal with real module issues
red[evilred] has joined #nixos-dev
<red[evilred]>
worldofpeace (IRC): zimbatm (IRC) I think we achieved what we aimed for.
<infinisil>
worldofpeace: drakonis: Glad to hear that :D
<drakonis>
i looked at the murmur module with and without the rfc, jeez.
<drakonis>
i forgot how bad modules look under the hood
<red[evilred]>
worldofpeace (IRC): When you say download page - do you mean the original HP page (which is what I made the homepage) or the github page in nix-community?
<drakonis>
things should look far more presentable now
Jackneill has quit [Read error: Connection reset by peer]
<infinisil>
drakonis: You mean the murmur module in my config?
<infinisil>
Ah you mean just that it would be nice to have good secret management for it?
<drakonis>
yes, not just for it.
<red[evilred]>
nm, just saw it
<red[evilred]>
heh
<infinisil>
Profpatsch: Nit: No parens needed around optionalAttrs
<infinisil>
I think I have an allergy for unnecessary parens
justanotheruser has quit [Ping timeout: 250 seconds]
<Profpatsch>
infinisil: they are great for readability, so I’d leave them.
<infinisil>
Hm alright
<Profpatsch>
Especially when there is a multi-line function application it gets a bit hard to see otherwise.
<infinisil>
Profpatsch: Do we need runCommandCCLocal?
<infinisil>
Is there anything that would want to compile c locally?
<Profpatsch>
infinisil: Good question.
<Profpatsch>
idk
<Profpatsch>
There the problem with `system` could actually be a real one.
<infinisil>
Yeah maybe
<Profpatsch>
But yeah, you really don’t want to have a C compiler in scope all the time.
<infinisil>
Imo we can leave that out (and NoCC too consequently)
<Profpatsch>
gcc is kinda big.
<Profpatsch>
I hear you.
<Profpatsch>
infinisil: pushed a new commit
<red[evilred]>
is downloadPage valid inside fetchGitHub?
<red[evilred]>
It seems to croak at me every time I attempt to use it.
<infinisil>
Profpatsch: On phone right now, but if the *Cc versions are gone I'd be fine with merging
<worldofpeace>
red[evilred]: hi 👋
<worldofpeace>
red[evilred]: oh I see what got mixed up here.
<worldofpeace>
I responded on github
orivej has quit [Ping timeout: 246 seconds]
<NinjaTrappeur>
Quick evening thought: what would it take to store the output hash of a store path in a narinfo and then leverage that information to prevent clients from downloading a store path having a different input hash yet a same output one (due to nix not being CAS)?
<NinjaTrappeur>
Is the narinfo parser backward-compatible?
<gchristensen>
the output hash of a store path is stored in the narinfo
<gchristensen>
NAR files are content-addressed
<NinjaTrappeur>
oh, did not know that, nice!
<infinisil>
Profpatsch: Why not remove `runCommandNoCCLocal`?
<red[evilred]>
worldofpeace (IRC): I have no idea what that means either... ?
<worldofpeace>
manual says "The page where a link to the current version can be found" and the current version is from there.
<worldofpeace>
the homepage as the support url makes sense
<red[evilred]>
okay - gotcha
<red[evilred]>
Doh, I should have gotten that. nm
<red[evilred]>
live and learn
<worldofpeace>
I guess I had a part in that also. we'll just say, me and english today... 🍵
<red[evilred]>
me and english every day apparently
<red[evilred]>
Okay - I think I've covered all your requested changes.
<red[evilred]>
please check my work (I know you will) M3
<red[evilred]>
<3
<worldofpeace>
red[evilred]: heh, it strikes again for me. can you drop `HPE LTO Filesystem (LTFS):` in the description? description doesn't directly state the software's name.
<Profpatsch>
infinisil: Because it’s the same as runCommand, so we should mirror it.
<Profpatsch>
It doesn’t have the CC problem.
<infinisil>
Hm, I'm not sure why anybody would explicitly use the NoCC version. I think runCommand just has it due to history
<red[evilred]>
Well, strictly speaking it's just called "ltfs"
<red[evilred]>
but I wanted to be explicit as to whose ltfs it was
<red[evilred]>
how would you like me to phrase it?
<red[evilred]>
(or is just having the packagename sufficient and I should just call it ltfs in the description?)
<worldofpeace>
implemented on dual partition tape drives`, so if you want to be specific as to who's it can be "HP's open-source tape file system..."
<Profpatsch>
I’m on the edge here.
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined #nixos-dev
<red[evilred]>
Thanks
justanotheruser has quit [Ping timeout: 246 seconds]
<gchristensen>
do we have a nukeReferences, but more of a "tactical nuke", to eliminate references to a specific path?
<tilpner>
gchristensen: See remove-references-to
<gchristensen>
nice!
<worldofpeace>
tilpner++
<{^_^}>
tilpner's karma got increased to 57
<red[evilred]>
I can't believe I missed that
<red[evilred]>
I'm guessing that's one of those "You see what you think is there, not what is actually there" type moments
Jackneill has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
justan0theruser has joined #nixos-dev
justan0theruser has quit [Ping timeout: 250 seconds]
ris has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
justan0theruser has joined #nixos-dev
<ivan>
hidpi users are gonna enjoy konsole 19.08.2 messing up their font sizes
justan0theruser has quit [Read error: Connection reset by peer]
justanotherus3r has joined #nixos-dev
justanotherus3r has quit [Excess Flood]
justanotherus3r has joined #nixos-dev
justanotherus3r has quit [Read error: Connection reset by peer]
ju5tanotheruser has joined #nixos-dev
ju5tanotheruser has quit [Ping timeout: 265 seconds]
mmlb has quit [Quit: Ping timeout (120 seconds)]
ju5tanotheruser has joined #nixos-dev
ju5tanotheruser has quit [Client Quit]
<jtojnar>
worldofpeace I am not sure about cjs
<jtojnar>
even gjs is using abandoned version of spidermonkey
<jtojnar>
blame the incompatible release schedules
<worldofpeace>
yep, that's always an annoyance. and even our release schedule kinda sucks for GNOME. Perhaps the duration the PR is open will bleed into when they make a release with a newer version.
<worldofpeace>
also, maybe cinnamon can keep it a private attribute. No one should be using it.