orivej has quit [Quit: No Ping reply in 180 seconds.]
doronbehar has quit [Ping timeout: 240 seconds]
rycee has joined #nixos-dev
orivej has joined #nixos-dev
doronbehar has joined #nixos-dev
ky0ko has quit [Ping timeout: 246 seconds]
domenkozar[m] has quit [Ping timeout: 246 seconds]
jtojnar has quit [Ping timeout: 246 seconds]
colemickens has quit [Ping timeout: 246 seconds]
ma27[m] has quit [Ping timeout: 246 seconds]
alexarice[m] has quit [Ping timeout: 246 seconds]
worldofpeace has quit [Ping timeout: 246 seconds]
Valodim[m] has quit [Ping timeout: 246 seconds]
ky0ko has joined #nixos-dev
Valodim[m] has joined #nixos-dev
alexarice[m] has joined #nixos-dev
ma27[m] has joined #nixos-dev
worldofpeace has joined #nixos-dev
jtojnar has joined #nixos-dev
colemickens has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
alp has quit [Ping timeout: 272 seconds]
orivej_ has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
doronbehar has quit [Ping timeout: 246 seconds]
dtz has quit [Ping timeout: 246 seconds]
ky0ko has quit [Ping timeout: 246 seconds]
ky0ko has joined #nixos-dev
worldofpeace has quit [Ping timeout: 246 seconds]
doronbehar has joined #nixos-dev
jtojnar has quit [Ping timeout: 246 seconds]
colemickens has quit [Ping timeout: 246 seconds]
worldofpeace has joined #nixos-dev
delroth has quit [Quit: WeeChat 2.6]
colemickens has joined #nixos-dev
dtz has joined #nixos-dev
jtojnar has joined #nixos-dev
delroth has joined #nixos-dev
<infinisil>
Interesting: "Currently package builds never get direct network access, as it gets put into an empty network namespace, and instead proxys all ‘fetch’ requests via a unix socket."
<domenkozar[m]>
took that and tweaked it a bit on https://nix.dev/
<manveru>
hmm, that does look interesting indeed :)
<manveru>
though janet looks even more cryptic than guile...
ckauhaus has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<domenkozar[m]>
yeah
<domenkozar[m]>
I think it's really interesting to learn from this project
<domenkozar[m]>
he made a few really cool things
<domenkozar[m]>
like he has 4 pages of docs that cover most common things
<domenkozar[m]>
something we've been unable to put together in 10+ years :)
<JJJollyjim>
I feel like teaching someone what is effectively a good chunk of haskell at the same time as a new package manegment system is a Hard Problem
<domenkozar[m]>
it's not really
alp has joined #nixos-dev
<Valodim>
domenkozar[m]: love that attitude :)
<domenkozar[m]>
you have to watch what are the common things people stumble upon and iterate on that
<domenkozar[m]>
once again, and also how simple to explain
<domenkozar[m]>
once we fix the command line so people don't have to remember these obscure flags, it's going to be a lot better
<Valodim>
I agree, there is loots of untapped potential there
<Valodim>
like a quick way to persist this kind of commandline into a shell.nix
<domenkozar[m]>
that's going to be the next tutorial I write :)
<domenkozar[m]>
I'm currently writing how to pin nixpkgs as reproducability is something I want to teach from day one
<nbp>
My intent with NixOS, was that people do not have to know anything about Nix to use it … So far I do not recall seeing any person introducing NixOS without first mentioning Nix, which is disappointing :(
<nbp>
`{...}: { services.openssh.enable = true; }` Does not have to be introduce as a function containing an attribute set, but simply as expected boiler plate around a list of named options which can be explained later if you need it.
<infinisil>
nbp: I guess a graphical user interface for configuration.nix would help with this
<infinisil>
What a GUI could cover is also about the same what people could do without knowing Nix
<manveru>
god... today's the day of coredumps
<domenkozar[m]>
nbp: but users don't want to use NixOS
<domenkozar[m]>
they want to .. deploy a webserver on AWS
<domenkozar[m]>
while solving some existing pain points with their tooling
<FRidh>
I think an open issue is still how to describe what packages need to be composed in a certain way so a gui can utilize that info. E.g., when a .withPackages is needed. How would a gui discover that? I definitely think more people could/would use Nix(os) on their desktop if they could drag&drop programs in a environment.
<FRidh>
But yea, probably not the user base you want to spend as much time on
<manveru>
FRidh: i don't think `withPackages` is used much, if at all at nixos level.. more something for nix-shell?
<manveru>
anw, we have a graphical editor for nixos config, right?
<domenkozar[m]>
because the new nix ui is experimental
<manveru>
:(
<domenkozar[m]>
we can teach newcomers experimental flags on the first line of the first tutorial
<domenkozar[m]>
can't*
* manveru
silently weeps
<manveru>
i haven't used the old style in years i think...
<manveru>
but yeah, i guess you do need the nix-command feature enabled
<Profpatsch>
agreeing with domenkozar[m] here, the laptop distro-crowd should not be the first target of our docs
<Profpatsch>
The benefit of NixOS is far greater for cloud/deployment stuff than it is for desktop system configuration
<domenkozar[m]>
I'm talking to an editor to help me with tutorials to speed things up
<Profpatsch>
Because the reduction of pain from Archlinux to NixOS is a lot smaller than the reduction of pain going from e.g. puppet to nixos
<Profpatsch>
Or even dockerfiles to nixos
obadz has joined #nixos-dev
obadz has quit [Ping timeout: 260 seconds]
obadz has joined #nixos-dev
<nbp>
I will disagree on one point. Persons who have no puppet/chef core are going to have a simpler journey migrating, than trying to rewrite everything they have to fit NixOS modules.
<nbp>
s/core/code/
<domenkozar[m]>
nbp: we discussed this a while ago, we really want to attract more power users
<domenkozar[m]>
that can contribute back
<domenkozar[m]>
otherwise it can quickly drain energy to support "I want to use my NixOS as Arch but it's harder"
<domenkozar[m]>
not that those aren't power users (we're generalizing here), but most likely less so.
<nbp>
You don't get power users from the beginning. You get users which then learn more and more. Power users are users which were motivated enough to go through all the existing layers of complexity
<domenkozar[m]>
you could argue the opposite, that power users have to start somewhere
<domenkozar[m]>
yeah agreed, but it's a much compelling to target devops audience that is paid to do stuff
<domenkozar[m]>
they have bigger pain points than a desktop user
<nbp>
and also bigger requirements …
<domenkozar[m]>
which is fine
<domenkozar[m]>
we got them covered ;D
<nbp>
except if they switch solutions after 2 years, because all the team knows about docket and no one wants to invest time in Nix (:cough:)
<nbp>
s/docket/docker/
urkk has joined #nixos-dev
<domenkozar[m]>
and that's what's actually happening
<domenkozar[m]>
and we're losing a lot of potential users
<domenkozar[m]>
and the solution is not to pretend they don't need to know, but to teach them!
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
alp has quit [Remote host closed the connection]
Mic92 has joined #nixos-dev
alp has joined #nixos-dev
<Profpatsch>
nbp: right, I also heard many developers switching their laptops to NixOS first and playing around with it before trying to convert their production use-cases
<Profpatsch>
It’s a great low-investment entry point to get sucked in
<Profpatsch>
And then only the second step is to convert production
<Profpatsch>
Because usually it goes “I heard of this nix thing, wonder what that is” -> “It sounded so cool, I switched my distro to it” -> “omg we have to get our deployment migrated to nixos asap”
<domenkozar[m]>
yeah but then installing NixOS on a laptop is a lot harder than deploying it to AWS
<niksnut>
Ericson2314: to be clear, I'm not against the possibility of git hashes for the intensional store, since the whole ca-references stuff is experimental anyway
<niksnut>
so we can still change the hashing scheme without causing a lot of compatibility issues
ryantrinkle has joined #nixos-dev
<gchristensen>
I'm a bit skeptical about moving to git's hashing model at this exact moment in time, when git itself has a major problem on their hands about moving *away* from their current hashing model
<Ericson2314>
niksnut: Oh, actually I was never thinking of using git-objects for non-intensional-store regular derivations, but yes we'll start with only existing caching schemes
<niksnut>
gchristensen: heh
<manveru>
niksnut: any idea what this means? `patchelf: patchelf.cc:1028: void setSubstr(std::string&, unsigned int, const string&): Assertion `pos + t.size() <= s.size()' failed.`
<niksnut>
another issue is that we can't use git's hashing scheme verbatim anyway, since it needs to handle self-references
<niksnut>
manveru: sorry, I swapped out knowledge of patchelf internals a long time ago
<manveru>
:)
<domenkozar[m]>
manveru: do open an issue with a way to reproduce it! :)
<domenkozar[m]>
manveru: are you cross-compiling?
<manveru>
no
<manveru>
trying to get the debug version of electron to work...
<manveru>
it's a fun 1.2GB binary
<domenkozar[m]>
do try latest master
<domenkozar[m]>
I've merged quite a few patches a few days ago
<manveru>
for patchelf?
<domenkozar[m]>
yes
evanjs has quit [Read error: Connection reset by peer]
<manveru>
oh awesome :D
<manveru>
will do
<domenkozar[m]>
nixpkgs.patchelfUnstable will also work
<domenkozar[m]>
if you use nixpkgs two days old
<manveru>
this is from the unstable patchelf, but i'm using nixpkgs-unstable
<manveru>
will try the latest
<domenkozar[m]>
it used to be 0.10
<domenkozar[m]>
now is should be something like 2020-06-03
evanjs has joined #nixos-dev
<Profpatsch>
Okay, now my triage runs have been changed into “is there anything we can do to move this forward?” as an answer to people literally replying “still important to me” to the stale bot …
FRidh has quit [Read error: No route to host]
<Profpatsch>
Which then seems to prompt people to actually think about solutions to these issues that are “still important to them”
<Profpatsch>
Maybe stale bot can automate this part as well …
FRidh has joined #nixos-dev
<gchristensen>
usually if someone replies with "still important" they're feeling annoyed that their ticket is at risk of being discarded without recognizing the work they've put in to reporting and diagnosing the issue
<abathur>
Profpatsch: heh, so, here's the actual message that the stale bot's repo actually uses: "Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?"
teto has quit [Quit: WeeChat 2.8]
<manveru>
domenkozar[m]: `patchelf-2020-06-03` would be right one?
<manveru>
because that still fails anyway
<domenkozar[m]>
manveru: then ideally you could open patchelf issue with how to exactly reproduce it
<manveru>
yeah, working on a demo repo...
<domenkozar[m]>
oh man, patchelf flakes could provide a function to write tests
<domenkozar[m]>
then we can require that for issues :D
<domenkozar[m]>
then we could write a bot that crawls all issues for gists and reruns them with new version of patchelf
<abathur>
domenkozar[m] Profpatsch nbp I'm a little torn on the best intake path. I think there's a risk wrt people who have obligations to be productive dropping Nix or NixOS into the middle of their workflow before they've found their sea legs.
<Profpatsch>
The nice thing about having triaged mid-2018 is that I can just close all issues that haven’t received any reaction on my question.
<manveru>
yeah, i haven't found anything... been trying to debug this thing all day :|
<abathur>
domenkozar[m] Profpatsch nbp started w/ NixOS Feb 2018 when I replaced a desktop (which got displaced by 2013 macbook air as my daily driver). This worked okayish? It was a frustrating few weeks. I think having to figure it out to get the system working was a good mix of sink-or-swim without the risk of flipping out because I couldn't Get Things Done.
<{^_^}>
nix#3549 (by Ma27, 5 weeks ago, open): Merge legacy `fetchGit`-builtin with the generic `fetchTree`-function
<nbp>
niksnut: I am not yet convinced by flakes, as it seems to me that we are loosing the ability to have multiple variants as we have with release.nix, and I fail to see it it would be composed well with Nixpkgs, as the lock file basically prevent to have global mutations with overlays.
<nbp>
niksnut: Also I consider lock files to be a mistake, especially in worlds where we depend on the architecture, such as Nix.
<nbp>
For example that would imply that someone developping on aarch64-linux would get the same lock file as someone developing on aarch64-linux, which makes little sense.
urkk has quit [Ping timeout: 256 seconds]
urkk has joined #nixos-dev
<manveru>
nbp: have you actually tried flakes?
<manveru>
because i don't see any of these issues in practice...
<nbp>
no, only from memory after reading the RFC, and the recent blog post.
<manveru>
then please do give it a try, then we can have a more productive conversation about what is still lacking :)
<abathur>
Profpatsch seems like triage could be incrementally improved in some nice ways by something like stalebot but with multiple rulesets. For example, label `9.needs: reporter feedback` could probably be auto-dismissed if not satisfied in a reasonable timeframe, and `9.needs: maintainer feedback` could probably trigger regular notifications?
<manveru>
domenkozar[m]: i really like nix.dev so far, awesome job on that :)
<manveru>
domenkozar[m]: one thing i'd like to suggest is to expand the dev-env section for different languages, not everyone is interested in python :)
<manveru>
domenkozar[m]: and finding some way to test the code snippets, so it doesn't end up like the pills
<domenkozar[m]>
yeah :)
<domenkozar[m]>
that's the plan
<domenkozar[m]>
first 15 tutorials
<domenkozar[m]>
then perfect it
justan0theruser has quit [Ping timeout: 246 seconds]
<manveru>
do you need any help with that?
* nbp
reading through the code still can't figure how to have multiple shell environment with `nix dev-shell`.
<manveru>
nbp: `nix dev-shell` uses the `devShell` attribute of the flake, same as you'd have a `shell.nix`
<manveru>
there can only be one
<manveru>
what you can do for `nix-shell -p` replacement is `nix shell nixpkgs#binutils nixpkgs#tree`
<domenkozar[m]>
manveru: yeah any help is welcome :)
<manveru>
i can probably write a ruby and crystal dev-env tutorial, and the terraform+aws with terranix would be fun too :)
<manveru>
there doesn't exist a whole lot of material for any of them yet
justan0theruser has joined #nixos-dev
teto has joined #nixos-dev
<Profpatsch>
what I don’t understand is why things in flakes.nix get special treatment, as only they are cached
<Profpatsch>
What hinders us to make this a general property of nix?
<nbp>
manveru: does that implies that there is no way to select a different shell configuration without modifying the file?
cole-h has joined #nixos-dev
<gchristensen>
Profpatsch: maybe it could be made general, but an important property is flakes use pure evaluation by default
<nbp>
manveru: `nix dev-shell -A x86_64-linux.clang` ?
<Profpatsch>
gchristensen: That’s a property that nix should have tbh
<Profpatsch>
Not just flakes
<manveru>
nbp: `nix dev-shell nixpkgs#clang`
<LnL>
even with pure mode caching still has a bunch of problems
<nbp>
manveru: No, this would not build a tool chain properly.
<nbp>
manveru: The use case I have today, is that I can select various versions of compiler and generate a file based on the version of the compiler used to build the shell. The generated file actually reference the compiler.
<nbp>
is that reading the default.nix or the flakes.nix ?
<manveru>
the flakes.nix
<manveru>
sorry, `flake.nix`
<nbp>
ok, then maybe there is a way …
<Profpatsch>
LnL: you left me hanging, what other issues are there with caching pure-mode evaluations in a more general setting than flake attributes?
<Profpatsch>
Maybe it was discussed somewhere and I missed it
<Profpatsch>
Is there a description somewhere how this caching works? Is it over the alpha-normalized form of the expression? Or something more naive, like hashing the input files?
<LnL>
mostly failure caching, it hides tracebacks and doesn't reevaluate in impure mode
ckauhaus has quit [Quit: WeeChat 2.7.1]
<Profpatsch>
“it” being?
<LnL>
"cached failure" isn't particularly useful when debugging an expression
<Profpatsch>
why would you cache something that is not evaluating
<LnL>
not wasting time on eg. hydra makes sense
<Profpatsch>
But even if you do cache failures, you can just cache the stack
<Profpatsch>
LnL: i can’t parse that sentence I’m afraid
<Profpatsch>
Maybe I’m misunderstanding what it means to cache nix expressions
<LnL>
hydra evaluations have lots of broken / disabled packages
<Profpatsch>
dhall caches the alpha-normalized forms of expressions
<LnL>
not trying to evaluate those every time if nothing changes makes that a lot faster
<Profpatsch>
LnL: I’d argue aborting evaluation and using a special evaluator for Hydra is a mistake we should have fixed years ago
<LnL>
not saying this stuff can't be solved, just pointing out that even the current limitations are already tricky to get right
<Profpatsch>
And now we’re hard-coding specific workarounds for the symptoms into new layers
<Profpatsch>
LnL: I’m talking “I have a shell.nix that didn’t change between this branch switch and the next, please save me from reevaluating”
<Profpatsch>
Not “I am hydra and want to evaluate an expression that is not really evaluat-able because it’s full of aborts”
justanotheruser has joined #nixos-dev
<Profpatsch>
So in general it should be feasible to make vanilla nix cache evaluations.
<Profpatsch>
If something fails to evaluate just don’t cache it.
<Profpatsch>
We do the same with builds.
justan0theruser has quit [Ping timeout: 272 seconds]
<LnL>
my point was pure mode
<Profpatsch>
LnL: can’t parse that sentence I’m afraid
<Profpatsch>
LnL: I’m assuming you mean it’s unfeasible to enable pure mode, yet flakes does it.
<Profpatsch>
So unless you explain what you mean I cannot understand your argument herer
<Profpatsch>
But if you don’t want to explain just say so and I can move on to different things.
<gchristensen>
manveru: it strikes me that a little "how to install nix-inclusive" would be helpful for new people to flakess (or an alternative for non-flake users)
<manveru>
yeah... gotta fight some fires first :)
<gchristensen>
haha yeah understood
<manveru>
friday night deploys ftw
<gchristensen>
cool cool cool ...
orivej has joined #nixos-dev
alp has quit [Ping timeout: 246 seconds]
<urkk>
So I use nix-build for the same derivation in two machines and they got the same hash in the store, but their content is different. One has debug symbols and the other one no
<urkk>
I didn't use `enableDebugging`, so I don't know how it happened
<urkk>
result/lib/libmpitrace-3.7.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
<urkk>
result/lib/libmpitrace-3.7.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<risson>
What is a type `merge` ?
<risson>
I am display var._type and I get `merge`
<risson>
s/display/displaying/
<risson>
Does it have to do anything with the fact that the option I'm using has been renamed with mkRenamedOptionModule ?
FRidh has quit [Quit: Konversation terminated!]
<gchristensen>
hrm. somethin on my system is creating /opt/containerd for some reason
<makefu>
mount your rootfs read-only and see which service crashes
<gchristensen>
docker I guess ... hrm
<risson>
gchristensen: same but I'm clearing /opt on boot so...
<gchristensen>
I do too
<risson>
Thanks to your wonderful article btw
<gchristensen>
:)
<gchristensen>
hrm. docker is broken for me for some reason. I don't understand.
<risson>
How broken?
<gchristensen>
---> Running in ed21b06456e1
<gchristensen>
cgroups: cgroup mountpoint does not exist: unknown
<risson>
So I guess that's happening when you're building an image
<gchristensen>
yeah
<risson>
Which step fails?
<gchristensen>
looking in to somethin slightly unrelated ... one sec ...
<gchristensen>
zfs created a bunch of datasets and now all of them are busy and none can be deleted lol
<risson>
Why is it even creating datasets on its own x)
<gchristensen>
dockerd[21842]: time="2020-06-05T15:47:03.698640531-04:00" level=error msg="29280eb6163b47c578dce28d765e7e15ae473bd0f8c09b41c2e995ae27ba8134 cleanup: failed to delete container from containerd: no such container"
<risson>
:D
<gchristensen>
I feel like I've entered in to some parallel universe
<gchristensen>
like is this docker secretly podman ...
<risson>
containerd vanilla ftw
<gchristensen>
I guess I'll reboot and see if erasing / fixes it.
<risson>
We have a saying in French: dans le doute, reboot, which means when in doubt, reboot
<risson>
The only reason it's funny is because it rimes
<risson>
(and because it works)
<gchristensen>
ah ... I was breaking docker. ] ++ (if config.docker.enable then [] else [ "cgroup_no_v1=all" "systemd.unified_cgroup_hierarchy=yes" ]);
<gchristensen>
(this then breaks podman I think)
tv has quit [Quit: WeeChat 2.7.1]
tv has joined #nixos-dev
urkk has quit [Ping timeout: 246 seconds]
urkk has joined #nixos-dev
__monty__ has quit [Quit: leaving]
urkk has quit [Ping timeout: 272 seconds]
urkk has joined #nixos-dev
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
m1cr0man has quit [Read error: Connection reset by peer]
mmlb2 has quit [Ping timeout: 265 seconds]
mmlb22 has joined #nixos-dev
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
kloenk has quit [Remote host closed the connection]
kloenk has joined #nixos-dev
v0|d has joined #nixos-dev
v0|d has quit [Remote host closed the connection]
v0|d has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]