samueldr changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 19.09 is released! https://discourse.nixos.org/t/nixos-19-09-release/4306 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite | https://logs.nix.samueldr.com/nixos-dev
drakonis has joined #nixos-dev
orivej_ has quit [Ping timeout: 268 seconds]
ris has quit [Ping timeout: 265 seconds]
drakonis has quit [Ping timeout: 250 seconds]
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-dev
jonringer has joined #nixos-dev
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
<clever> *looks*
<gchristensen> seems like a bug to me
<clever> ln -sfn @udevRules@ /etc/udev/rules.d
<clever> udev rules are pulled in
<clever> but not modprobe conf
<andi-> look at stage-1.nix ~314
<andi-> it would just be another entry there constructed from the configuration in the module system.
<clever> seems simple enough
<andi-> alright, let me file a PR (and test it first)
<gchristensen> do we have differentiation between kernel modules needed for boot, and others not needed for boot?
<clever> gchristensen: there are 2 options for those
<gchristensen> I'm thinking it would be annoynig for a new initrd to be made any time a non-boot-module option was tweaked
<clever> oh, for options, yeah, i can see that being anoying
<andi-> mhm, good point
<clever> i only have enough room on my nas for 2 initrd's
<andi-> Do all bootloaders support chained initrfs yet?
<clever> i think the nixos scripts are just cat'ing them together right now
<clever> maybe the grub one does it, for secret initrd's, but thats it
<clever> the initrd secret stuff has to be cleaned up too
<clever> some of them arent so secret
<clever> and they duplicate the config options
<andi-> You could have yet another tiny one with just that file... (and more in the future?)
<andi-> it sounds really hacky... will have to think about that a bit.. Maybe someone else has an insight before that happens.
<clever> andi-: oh, one idea, what if the modules options where more structured?
<clever> boot.modprobe.zfs.zio_taskq_batch_pct=50;
<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...
<jtojnar> worldofpeace I guess we need to explicitly discourage from adding LD_LIBRARY_PATH to wrappers https://github.com/NixOS/nixpkgs/pull/74874#pullrequestreview-326235285
noonien has joined #nixos-dev
<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.
<kreisys> Hit me up if you end up working on it
<infinisil> Alright :)
<worldofpeace> infinisil: is it fine if I actually suggest people to do https://github.com/NixOS/rfcs/pull/42 in PRs?
<{^_^}> rfcs#42 (by Infinisil, 36 weeks ago, open): [RFC 0042] NixOS settings options
<worldofpeace> ref #73968, where it could be very easy
<{^_^}> https://github.com/NixOS/nixpkgs/pull/73968 (by mat8913, 1 week ago, open): nixos/upower: Allow customization of UPower.conf
<infinisil> worldofpeace: Yeah totally, been doing that for a hwile
<infinisil> The first part of the PR specifically, but hinting at the second one too
<infinisil> Yeah no I've been encouraging both parts actually
<worldofpeace> Hmm, with part 2, this config only has 11 options...
<worldofpeace> so it's actually pretty small IMHO infinisil
<infinisil> worldofpeace: I mean part 2 is flexible
<infinisil> It just says to think about what additional settings from the config get exposed as separate nixos options
<infinisil> Ahh I see now
<infinisil> Just looked at the module, yeah 11 options isn't much
<infinisil> I was thinking of it being 11 options *after* applying part 2
<worldofpeace> infinisil: Do you have like a preferred example in nixpkgs? asking because https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md#an-example isn't implemented.
<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.
<{^_^}> #74814 (by redvers, 1 day ago, open): hpe-ltfs: init at 3.4.2_Z7550-02501
<red[evilred]> hosted in nix-community
<zimbatm> nice!
<zimbatm> red[evilred]: do you have a tape to try it out?
<worldofpeace> oh red[evilred] has the tape :D
<worldofpeace> Quickly reviewed red[evilred]
<red[evilred]> I do!
<red[evilred]> more than a few
<red[evilred]> lol
* red[evilred] uploaded an image: VectorImage_2019-12-03_125039.jpg (118KB) < https://evil.red:8448/_matrix/media/r0/download/evil.red/peqdjPOGbjKhrpDPZZAALhRh >
<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?
<drakonis> yes
<infinisil> Yeah I like that example of the RFC a lot
<drakonis> this reminds me, what about secret management?
<infinisil> In my module I spend like half the lines on implementing some nice acme functionality, while the one in nixpkgs is 90% option declarations
<infinisil> Yeah secret management could be better, in general
<infinisil> Or how do you mean that?
<drakonis> its a recurring complaint
<drakonis> i mean that, yes.
<drakonis> something about secrets being stored at /nix/store
<infinisil> Ah yeah, i talked with rycee about implementing a types.storePath and types.nonStorePath before
<infinisil> Which would alleviate some accidental paths ending up in the store
<infinisil> And passwordFile options are the way to go imo
<infinisil> Probably
<drakonis> it'd be good.
<infinisil> I'm thinking that maybe we need some generalized secret abstraction
<drakonis> esp. with wireguard approaching
<infinisil> what about it?
<Profpatsch> infinisil: round we go: https://github.com/NixOS/nixpkgs/pull/74642
<{^_^}> #74642 (by Profpatsch, 4 days ago, open): pkgs/build-support/trivial-builders: add runCommandLocal
<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... ?
justanotheruser has joined #nixos-dev
<worldofpeace> red[evilred]: meta = { downloadPage = "https://github.com/nix-community/hpe-ltfs";
<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?)
<Profpatsch> infinisil: hm, yeah, maybe
<worldofpeace> red[evilred]: https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes, says to just describe what it does. in the README i see `an open-source tape file system
<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.
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
<worldofpeace> hmm, what is cinnamon's development cycle https://github.com/linuxmint/cjs/issues/80#issuecomment-559626825
<worldofpeace> looks like each linux mint release https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment)#Release_history.
<jtojnar> worldofpeace it would be better if they did just use gjs
<jtojnar> seriously, why would someone even fork that
<jtojnar> I would expect the gjs bump patch for cinnamon will be smaller than spidermonkey one for gjs