jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
obadz- has joined #nixos-dev
obadz has quit [Ping timeout: 260 seconds]
obadz- is now known as obadz
sir_guy_carleton has joined #nixos-dev
Ericson2314 has quit [Ping timeout: 276 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
disasm has joined #nixos-dev
Lisanna_ has quit [Quit: Lisanna_]
Drakonis has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 264 seconds]
lassulus_ is now known as lassulus
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
gleber__ has joined #nixos-dev
gleber_ has quit [*.net *.split]
fadenb has quit [*.net *.split]
tv has quit [*.net *.split]
teto has quit [*.net *.split]
capisce has quit [*.net *.split]
gleber__ is now known as gleber_
fadenb has joined #nixos-dev
tv has joined #nixos-dev
thefloweringash has joined #nixos-dev
Drakonis has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 252 seconds]
Dezgeg has joined #nixos-dev
tv has quit [Quit: WeeChat 2.0]
tv has joined #nixos-dev
goibhniu has joined #nixos-dev
<genesis>
for jre apps, platforms = stdenv.lib.platforms.all ?
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
orivej has joined #nixos-dev
grw has joined #nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
lassulus has joined #nixos-dev
<CrystalGamma[m]>
I just created a new RFC about my ppc64le enablement project, so if anyone wants to weigh in on the discussion: https://github.com/NixOS/rfcs/pull/31
<CrystalGamma[m]>
I guess the mailing list referenced on the RFC repo Readme is now a Discourse?
<ekleog>
indeed
<ekleog>
looks like a pretty big offer of build farm from justinlynn, that should be enough to get ppc64(le) builders for ofborg I guess, but not sure we'd want machines owned by non-core-member individuals in hydra? (unless justinlynn has a second github account I can't find any trace of them on the nixpkgs repo)
<CrystalGamma[m]>
should definitely be enough. My dev machine is a single 2x8-core Talos II
<CrystalGamma[m]>
and it builds my full system from scratch in ~3h IIRC
<CrystalGamma[m]>
(including stdenv and all)
<ekleog>
your full system is headless, though, right?
<ekleog>
like, firefox takes by itself as much as all a headless system (don't have actual stats but from my time using gentoo that seems to make sense)
<CrystalGamma[m]>
right now yes, because of Rust.
<ekleog>
to build*
<CrystalGamma[m]>
makes sense that with rust (which uses LLVM) and SpiderMonkey it would take forever
<ekleog>
anyway, if even one of these machines is actually embedded in ofborg|hydra it should be enough, but for hydra that requires quite important trust in the builder, as it'll provide binaries
<ekleog>
(I'm saying only gecko+spidermonkey, and my measurements date from before rust was included in firefox, so it's likely even worse now :°)
<CrystalGamma[m]>
I certainly understand that
<CrystalGamma[m]>
that's why I have posted hosting bootstrap files as an Unresolved Question for example
<CrystalGamma[m]>
(though those can be produced from x86 of course)
Drakonis has joined #nixos-dev
<gchristensen>
CrystalGamma[m]: may I PM?
Drakonis has quit [Ping timeout: 256 seconds]
<CrystalGamma[m]>
sure
Lisanna_ has joined #nixos-dev
{`-`}_ has joined #nixos-dev
{`-`} has joined #nixos-dev
Lisanna_ has quit [Quit: Lisanna_]
<ekleog>
Question before I start writing a RFC: do you think it'd make sense to add, like ~debX, a version number to indicate the security patch version, when we add security patches?
<ekleog>
I think it'd make sense for easily knowing if a vulnerability has been patched already or not and to easily talk of “a package version” like other distros do, but I'd guess it'd have already been discussed?
<andi->
ekleog: don't we have commit hashes for that? Like "until commit 1234123" or "after commit 123123123" affected/fixed?
<andi->
or even channel bump dates/commit hashes for those.
<andi->
I thought about the same a few times...
<ekleog>
the issue is exactly that “after commit 123123123” is non-trivial to check without a local clone of nixpkgs (and even then…)
<ekleog>
for channel bump, there's this second part of nixos-version, but I have no idea what it actually represents
<gchristensen>
commits since branch-off
<infinisil>
What's the problem with just having "Fixes CVE-..." in the commit message?
<gchristensen>
I think the issue is how do operators answer "is my system secure?" or "is this package secure?"
<ekleog>
^
<infinisil>
Same as vulnix I'd say: get version number, check against known CVE's, remove ones that can be found in the commit history
<ekleog>
that's likely going to be helped quite a bit by andi-'s in-development tool, though :)
<andi->
well the operator will need a source that tells it WHAT was fixed anyway. Just that there was (security) release doesn't help much ;)
<infinisil>
(not sure vulnix does the last step though
<ekleog>
also, I'm thinking potentially it could help upstream to know with which patch set a bug has happened, when reporting bugs upstream
<ekleog>
(if it's possible to make finding the patch set easier with the full-version than with the upstream-version-and-nixpkgs-commit)
<ekleog>
oh, and maybe the least unconvincing of all (not really convinced myself by the idea): it'd allow tools like nix-diff to easily display that a derivation has been security-patched
<andi->
For that case just asking $tool (nix repl etc.) for $pkg.src.{url,rev} would be easier?
* ekleog
still hopes for https://github.com/Gabriel439/nix-diff/issues/8 to be solved so that I could have a cron running nix-channel --update && nixos-rebuild build && nix-diff result /run/current-system to know what's going to be updated
<{^_^}>
Gabriel439/nix-diff#8 (by Ekleog, 19 weeks ago, open): Shorten trees consisting only of “These two derivations have already been compared” as the leafs.
drakonis__ has joined #nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
lassulus has joined #nixos-dev
clever has quit [Disconnected by services]
clever has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
<genesis>
i wonder if radare2 could patch hardcoded path instead of using a buildFHSUserEnv
<genesis>
would be another swiss tool .
Cale has quit [Ping timeout: 260 seconds]
<gchristensen>
niksnut: a _very_ early version of the nix install matrix report: http://ix.io/1l2V
Cale has joined #nixos-dev
<niksnut>
gchristensen: cool :-)
goibhniu has quit [Ping timeout: 240 seconds]
<LnL>
is staging-18.03 still used?
<LnL>
niksnut: what do you think about adding a nix command that prints both the current client/daemon versions and maybe some more information like nix-info does?
<gchristensen>
eelco wondered why nix-info wasn't part of nix itself, I didn't want to make it part of Nix because I wanted to be able to evolve it. maybe it is time to just incorporate it.
<LnL>
it's currently a bit tricky to figure out if somebody is using inconsistent versions
<LnL>
it doesn't have to replace it, we can add new stuff to nix-info first and move what's relevant or something
<gchristensen>
yeah
<LnL>
ideally this would be more like brew doctor IMHO, including warnings about potential issues
<gchristensen>
+1!
<LnL>
but figuring out the daemon version isn't really possible without changing the daemon itself I think
<gchristensen>
maybe we can sneak that in to 2.1.) :)
<LnL>
except maybe the protocol version
<LnL>
ok, well I'll give that a try then :D
<gchristensen>
:D
<samueldr>
nix-info outside of nix allows the same script version to run whichever nix version is installed
<samueldr>
(though less instrinsically valuable with how nix works)
<niksnut>
in fact they're no longer called extensible attrsets
<gchristensen>
ooh!
<niksnut>
joepie91: ^
<LnL>
is extends new?
<infinisil>
niksnut: Read through it, very nice!
<gchristensen>
how did you read that so fast :o
<niksnut>
LnL: yes, I think previously the way to extend an attrset was with //
<infinisil>
Skipped a few sentences :P
<LnL>
read it before so tried to resolve the diff from memory :)
<infinisil>
niksnut: 2 concerns: I'm not sure if removing super is alright, although I can't think of an example right now where it's necessary
<LnL>
an example for super would be merging a non mergeable type
<infinisil>
And: having to list all modules in your NixOS configuration really takes away the magic of NixOS of being able to specify just `services.foo.enable = true;` and it just works (tm)
<niksnut>
infinisil: well, now you would just say: my-config = < extends modules.foo >;
<LnL>
and I thought that first, but extend modules.nginx is pretty much the same I think
<LnL>
with this new modules enable would be true by default
<infinisil>
Ohhh I see
<infinisil>
That's really cool
<infinisil>
LnL: What type would be unmergeable?
<LnL>
dunno
<gchristensen>
can you merge a function?
<infinisil>
Because you can define arbitrary merge functions for types
<LnL>
but take name for example, it shouldn't be a merge type but what if I want to suffix the original name?
<LnL>
(I might be totally missing something tho :p)
<infinisil>
LnL: You could do that with `before` and the string type
<niksnut>
LnL: yeah, wrapping functions in lib would be a use case for super
<infinisil>
Or after I mean
<LnL>
ok.. well what if I want to uppercase the name
<LnL>
it's a stupid example, but there's probably a valid usecase somehwere
<infinisil>
Yeah seems like it
<LnL>
the important part here is "Only the initial definition of an option can specify doc, type and example."
<infinisil>
And in any case, the type can only specified at the declaration, so you can't control the merging behaviour at the definition site
<niksnut>
for example, if I wanted to add tracing to lib.unique I would do something like: < lib.unique = list: trace "bla" (super list); >
<LnL>
heh, that's a much better example :)
<infinisil>
Although, that could be done with a function composition merge
<LnL>
was just going to say that, but then the type of the first value is different from the others which might be considered a bit weird
<infinisil>
It is? It would be a merge between (lib.unique) and (trace "bla")
<LnL>
ah no, not if super is a keyword
* infinisil
goes looking for a legitimate usage that needs super
<infinisil>
I mean, the module system doesn't have super and it's been working fine so far
<LnL>
I've used options.foo.bar before, which isn't really correct
<LnL>
to get the default value
<infinisil>
Good point
<simpson>
aaaa
<joepie91>
niksnut: thanks, I'll have a read probably later tonight :)
<simpson>
Thanks SSH~
<joepie91>
possibly tomorrow
<LnL>
something like buildInputs merge = xs: xs ++ [ libfoo ]; could be another solution if necessary
<infinisil>
LnL: So it would first compute the result of all previous modules merged together, then apply this merge function to get the final value of this module?
<LnL>
yeah, I think this would be kind of the same as apply in the current module system
<infinisil>
Looks troublesome, the evaluation would be multistaged in a way, separating all modules before and after that merge function (which isn't really a merge)
<LnL>
not sure, it's not really that different from the merge type or override
<LnL>
or are you thinking about captured variables of the lambda
<infinisil>
It's not a merge because it just takes a single value, not merging anything
<infinisil>
It's more like an apply (as you mentioned)
<infinisil>
LnL: Oh, do you mean that it should behave like a list of functions that gets evaluated at the end before getting the final merged value? So `buildInputs apply = xs: xs ++ [ libfoo ];` and `buildInputs apply = xs: xs ++ [ libbar ];` in modules would both be applied after all values have been merged (from all modules)?
<infinisil>
That doesn't sound too bad
<LnL>
no, same behaviour as override
* infinisil
doesn't quiet follow
<LnL>
buildInputs = [ libbar ]; doesn't happen after all modules, the current module might be extended by something else
drakonis__ has quit [Remote host closed the connection]