<Profpatsch>
hrm. self/super fixpoints are great, but I dislike the namespace cluttering.
<Profpatsch>
The utility functions are in the same namespace (e.g. for haskelPackages), so what happens if somebody uploads a haskell package called “callPackage”.
<Profpatsch>
But I don’t really know how to solve that, except with sub-namespaces like _functions or the like.
<Profpatsch>
Then you get the update problem. lenses for nix? :)
<Profpatsch>
Then again, why would you want to keep utility functions inside the fixpoint, as long as they don’t call each other?
<Profpatsch>
{ fetchgit }: self: super: would essentially make fetchgit a constant.
<Profpatsch>
But maybe that’s not so bad of a deal.
<Profpatsch>
At least in my small local fixpoint?
phreedom has joined joined #nixos-dev
<Profpatsch>
pierron_: fix (extends (_: _: { foo = 42; }) (extends (se: su: { bar = se.foo - 19; }))) is bad style, right?
<Profpatsch>
It works, but it has to cycle through the fixpoint twice, as compared to swapping the two extends layers, I assume?
<Profpatsch>
fix (extends foo (extends bar (_: {})))
<Profpatsch>
as compared to
<Profpatsch>
fix (extends bar (extends foo (_: {})))
<Profpatsch>
dunno, that’s just what my intuition says, haven’t expanded it manually.
<domenkozar>
gchristensen: it's very alpha, but it works :)
<gchristensen>
you mean the current UI?
<gchristensen>
oh, the Elm work
<gchristensen>
yes yes that is fine
<domenkozar>
what's next is elm.compiler and elm.packages
<domenkozar>
and elm.compiler.018.mkDerivation
orivej_ has quit [(Ping timeout: 256 seconds)]
<laggy_wifi>
like does nix have any of its own commands that it itself created, that can accept numbers as arguments, for example "dd" does not count as nix did not make it, nix-env does but idk if it supports numbers as arguments
<Profpatsch>
MoreTea: Which package can I test it with?
<Profpatsch>
I assume native dependencies would have to be provided manually; by default each package is overridable via the self/super mechanism, but I’m not sure how to satisfy the potentially large amount of version numbers that need to be patched.
<Profpatsch>
Hm, maybe it *is* possible, by reimplementing a versioning scheme inside nix.
<gchristensen>
aminechikhaoui: can your colleague describe the practical differences between the existing config and the recommended config?
<gchristensen>
I don't know too much about PAM other than it is easy to accidentally do bad things [insert][links][to][prs][fixing][security][bugs][in][pam] so I believe this is a good improvement
<aminechikhaoui>
gchristensen: donnow, I'll ask him ;)
<aminechikhaoui>
gchristensen: maybe if there was nixos tests for pam we could know if there is a regression somewhere ?
<gchristensen>
there would have to be many many nixos tests for the different combinations, even if we selected just common combinations :) and yes, we probably should have them
<aminechikhaoui>
or maybe that's also hard to test, I'm no expert myself in pam
Sonarpulse has joined joined #nixos-dev
<pierron_>
Profpatsch: Going twice through a fix-point does not matter much, except when we are trying to add semantic to what the top-level function does, and what does that mean to go through it.
vcunat has joined joined #nixos-dev
__Sander__ has quit [(Quit: Konversation terminated!)]
<Profpatsch>
pierron_: Wouldn’t adding a function that is used by inner layers on an outer layer create a round of indirection for each such function call?
<gchristensen>
orivej: did you not wait for grahamcofborg to do eval checks on https://github.com/NixOS/nixpkgs/pull/32721 because you were certain it'd work, or ofborg was being slow, or a different reason? just curious, I can fix one of those problems :)
<orivej>
gchristensen: I'd very much like it to work, but it did not begin evaluation for unusually long so I figured it won't
vcunat has joined joined #nixos-dev
<gchristensen>
i see, ok
<gchristensen>
this weekend I will try to run the evaluator on at least one more server
<gchristensen>
thanks!
orivej has quit [(Ping timeout: 272 seconds)]
<lassulus>
hey, maybe someones here does know, how to get internet inside a nixos-test
<gchristensen>
like during nix-build ?
<lassulus>
yes, that would be the plan i guess
<lassulus>
if there is some other way, I would also try that
<vcunat>
if it's a fixed-output derivation, you should have it
<gchristensen>
I don't think you can, lassulus
<gchristensen>
because nixos tests will never produce the same output
<lassulus>
yes, but this is expected
<lassulus>
i just want to ping something
<gchristensen>
something specific? :)
<lassulus>
on the real internet
<gchristensen>
you can't
<vcunat>
you may have a test with empty output, making it fixed-output
<vcunat>
(and get all results just from the log)
<lassulus>
but i really like the framework and just don't want to reimplement nixos-tests with internet.
<vcunat>
there used to be an undocumented attribute, __chroot or something
<gchristensen>
the framework is excellent, may I ask why you need to ping something on the internet?
<vcunat>
if it's not intended for upstream nixpkgs, you may just turn off sandboxing, too
<gchristensen>
oh yeah I forget about that
<lassulus>
actually I need to test a script witch git fetches something from a predefined place. And I'm really to lazy to mockup git for that test. And it's outside of nixpkgs.
<lassulus>
And i already tried nix-build --option build-use-sandbox true ./mytest.nix
<gchristensen>
you could use nixos' vm test framework support for 2 VMs and have one VM serve the repo and the other fetch it
<lassulus>
aeh false
<lassulus>
well I could emulate the internet in my test I guess. but just having internet would also be nice :D
<vcunat>
`--option build-use-sandbox false` should work, if ran as root, I think
<lassulus>
hmm, running as root might be a problem
<lassulus>
but I see the problem maybe
<simpson>
lassulus: I know that you see a "this would be nice", but we see a "this is a massive gaping hole in our security model".
<lassulus>
yeah, I realized that now
<lassulus>
so getting internet inside a test, without running the test as root, would be considered a bug then?
<simpson>
Getting arbitrary networking is a bug. Getting specific kinds of networking is a thing that Nix sometimes allows.
<lassulus>
would it be possible to fetch packages from the nixos cache inside a test?
<lassulus>
or what would this "specific kinds of networking" be?
<simpson>
Fixed-output derivations, some sorts of recursion using IFD, pulling stuff from cache.nixos.org, that sort of thing.
<lassulus>
alright, that is helpfull, thank you
<MoreTea>
Profpatsch: anything that does something with node-gyp. I'll dig for an example
<jtojnar>
why is nixpkgs-channels a separate repo again?
<jtojnar>
if the branches were in the main repo GitHub could easily show whether the commit already propagated to a channel
<jtojnar>
would not protecting the branches be enough?
<gchristensen>
no
<gchristensen>
that only prevents force pushing I think
<gchristensen>
we could sync back the channel's branches though, that'd allow you to see that data... but I think it would be very confusing for people
<gchristensen>
one option would be to label PRs or something once they are released througha channel
<jtojnar>
Maybe “Require status checks to pass before merging” could be abused with a Travis rule failing unless hydra is pushing
<jtojnar>
but that would require a temporary branch for the status checks to run
<vcunat>
well, we could at least make it a fork of the main repo
<vcunat>
the stats look strange when you have the same commits counted in two "projects"
<vcunat>
IIRC there was also some other reason for a separate repo, but I don't recall what it was.
<samueldr>
(making it a fork will also make it easier to compare branches)