<ajs124>
For future reference, if anyone finds this when searching for dm-event.socket and nixos: the upstream unit has DefaultDependencies=no. If you set it Before = sockets.target, it actually starts. If I had to guess, I'd say that redhat starts this in the initrd, but since we don't have a systemd based initrd (yet), we can't do that.
<bdju>
Have we got any gemini browsers packaged yet? I would like it if I could use bombadillo at least. It's a tui program so I've just been using it on another box over ssh in the mean time.
agam has quit [Ping timeout: 256 seconds]
<{^_^}>
[nixpkgs] @peterhoeg opened pull request #88563 → obs-studio: show the actual version instead of 0.0.1 → https://git.io/Jf23r
<bbigras>
Anyone can help figure out why a rust package is not building for aarch64? The error is `error: linker `aarch64-linux-gnu-gcc` not found` could it a problem with the builder? https://github.com/NixOS/nixpkgs/pull/88185
<{^_^}>
[nixos-homepage] @github-actions[bot] pushed commit from @edolstra to master « Update flake.lock and blogs.xml [ci skip] »: https://git.io/Jf2GL
corpix_ has quit [Remote host closed the connection]
cosimone has joined #nixos
cjpbirkbeck has joined #nixos
mac10688 has quit [Quit: WeeChat 2.7.1]
corpix has joined #nixos
shafox has joined #nixos
seku has quit [Ping timeout: 240 seconds]
<ajs124>
freeman42x[m]1: which kind of (emulated?) GPU/environment is that?
mac10688 has joined #nixos
<la-s>
adyatlov: the dynamic linker is really just "${pkgs.glibc}/lib/ld-linux-<arch>.so.1", so you can just do that for the 32-bit package set, which I don't remember how to access, but I do know that there is a way
cosimone has quit [Quit: Quit.]
signaryk has quit [Quit: signaryk]
<freeman42x[m]1>
<ajs124 "freeman42x: which kind of (emula"> I am not sure what you are asking. That is a VirtualBox VM.
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<freeman42x[m]1>
I got it figured out, needed to disable 3D acceleration.
kvda has joined #nixos
kvda has quit [Client Quit]
<freeman42x[m]1>
does anyone know correct way of enabling VirtualBox guest additions into a NixOS VM?
<qyliss>
virtualisation.virtualbox.guest.enable
<evanjs>
hrm. so until #88523 is merged, I'm trying to copy what nixos-generate does but in a nix expression. Getting to the point where I'm building images... but I'm failing on python2.7.18 for some reason
<{^_^}>
ldlework: If you're updating a package file in nixpkgs that starts with something like `{ stdenv, cmake }:`, use `nix-build -A the-package-attribute` in the nixpkgs root with the corresponding package attribute to build it. The mapping from package attributes to package files is in pkgs/top-level/all-packages.nix
<qyliss>
Oh, sorry, that wasn't very helpful
<qyliss>
I was expecting it to cover this case
<qyliss>
ldlework: anyway, what you want is I think nix-build -E 'with import <nixpkgs> {}; callPackage ./.'
<ldlework>
my goal is, i have two local projects. one is a python library. i would like to package it with nix. so that my shell.nix in the second project, can use the first as a python library.
<ldlework>
ah I get a different error now
<qyliss>
anyway i need to go to sleep
<qyliss>
hope you figure it out :)
<ldlework>
no poetry.lock, I can figure that out
<ldlework>
hey thanks
<qyliss>
np :)
drakonis_ has joined #nixos
drakonis2 has joined #nixos
drakonis1 has quit [Read error: Connection reset by peer]
cryptomonad has quit [Remote host closed the connection]
agsdheidjd has joined #nixos
<ldlework>
adisbladis: hello.
drakonis_ has quit [Ping timeout: 260 seconds]
<ldlework>
adisbladis: when I try to use poetry2nix to build my python library it says, Package ‘python2.7-cachetools-4.1.0’ in /nix/store/pj1i450cs7fnq12xd5nd7gypsaci9l2f-nixos-20.09pre225264.683c68232e9/nixos/pkgs/development/tools/poetry2nix/poetry2nix/mk-poetry-dep.nix:89 is marked as broken, refusing to evaluate.
<ldlework>
adisbladis: let's say i have a library and a cli project. i use what you did on the first. i specify my dependency on the library in the cli's pyproject.toml. what do I do then? poetry2nix wont be able to find my library, as it's something i've packaged with nix.
<adisbladis>
ldlework: It doesn't really make sense to package individiual libraries with poetry2nix
<adisbladis>
You'll just call mkPoetryApplication on the CLI app
<ldlework>
i'm developing them both in tandem and am just looking for a faster iteration workflow than docker :(
<ldlework>
how does my library get in there?
<ldlework>
(that's not deployed to pypi, i want to develop it locally in tandem)
<adisbladis>
Poetry2nix will create a derivation for the library
<adisbladis>
It creates derivations for your whole dependency graph, you don't have to package the library individually
opthomasprime has quit [Remote host closed the connection]
opthomasprime has joined #nixos
opthomasprime has quit [Remote host closed the connection]
opthomasprime has joined #nixos
drakonis_ has quit [Read error: Connection reset by peer]
<quinn>
ultranix: i don't think you can set an environment variable for a derivation outside of the build process. if you want to set one inside the build process you should be able to just add SDL_VIDEODRIVER = "wayland" to the attribute set you're passing as an argument for .override. however if you do want to set an environment variable for the whole system, you should add it to your configuration.nix.
<quinn>
and that's something like environment.variables.STDL_VIDEODRIVER = "wayland"; iirc.
drakonis_ has joined #nixos
<ultranix>
quinn: you mean then, that you cant set an env var with an override
<ultranix>
the last part is probably better anyways. i forgot about environment.variables.*. thanks!
<quinn>
if you set an environment variable with an override, you are setting it for the build process of the software, not for your system as it is running when you use it.
<quinn>
ultranix: FYI, i think steam's packaged SDL library isn't compiled with wayland support. adding that flag made shovel knight and gungeon (the only 2 games i tried) not work.
<ultranix>
well ive encountered "Could not initialize video: Wayland support not available"
<ultranix>
thanks for the information about the override, I'm understanding them more
ultranix has quit [Remote host closed the connection]
orcus has joined #nixos
ultranix has joined #nixos
alp has joined #nixos
<energizer>
i'll try it
cartesian-theatr has joined #nixos
<ldlework>
energizer: it's titlecase = "*" in my pyproject.toml
<ldlework>
odd I had it cat out the setup.py
<ldlework>
and I see
<ldlework>
setup_requires=['nose>=1.0'],
<ldlework>
lol wtf
<ldlework>
oh
opthomasprime has left #nixos [#nixos]
<ldlework>
nice
<ldlework>
the actual text was different than what was in github
<ldlework>
now it works
<ldlework>
ok
<ldlework>
so now my question is
<ldlework>
if fabric is one of my dependencies
<cartesian-theatr>
Hello! I'm a newcomer to Nix just evaluating the stack. It looks really neat. Is ARM support for NixOS still being actively worked on? Are there any active ARM distribution channels?
<ldlework>
why is 'fab' not available when i enter into the nix shell?
<energizer>
ldlework: there were some features added in the last couple weeks for that
<ldlework>
energizer: hmm any idea what you're supposed to do?
<pjt_014>
cartesian-theatr: arm support is alright, assuming you aren't compiling anything too heavy. This project is able to compile system images for various arm devices:
<pjt_014>
cartesian-theatr: Only two real problems: it needs its own copy of nixpkgs (and I can't figure out how to selectively update the submodule), and the way to include custom configuration is non-obvious
<energizer>
there was a series of commits about this, infinisil and adisbladis would know the details
medvid has quit [Quit: WeeChat 2.3]
<cartesian-theatr>
pjt_014 you mean "custome configuration" so a package could target multiple platforms?
orivej has joined #nixos
<ldlework>
energizer: hmm it compiled but didn't make fab available
<energizer>
ldlework: you're using .dependencyEnv?
<cartesian-theatr>
Do you think compiling recent nvidia drivers would be challenging on a Tegra platform?
<pjt_014>
cartesian-theatr: No, most simple packages can already be cross built fine, with something like nix build -f channel:nixos-unstable pkgsCross.raspberryPi.nq (don't worry, all that autocompletes after the 1st time)
<pjt_014>
cartesian-theatr: no idea
<cartesian-theatr>
Ohh, didn't understand that right. That's awesome.
<energizer>
ldlework: then i'm not sure
<ldlework>
adisbladis: can you help?
<pjt_014>
If it can be done, most likely the aarch64 target can do it, since it has full upstream support
charukiewicz has quit [Remote host closed the connection]
<{^_^}>
[nixpkgs] @etu opened pull request #88583 → linux-steam-integration: Drop abandoned package that doesn't build → https://git.io/Jf24S
<ldlework>
energizer: I wonder how you can add arbitrary packages to the shell env too
<pjt_014>
cartesian-theatr: I was talking about building a custom iso image with i.e extra packages, preset static ips/ssh keys, etc
<pjt_014>
cartesian-theatr: if you want to do that there's a few specific changes that are needed
<cartesian-theatr>
I'm not so worried about building an ISO
<cartesian-theatr>
Just building binaries for distribution.
<pjt_014>
in that case yeah x-compiling single packages works fine.
<pjt_014>
are you distributing them to systems without nix?
<energizer>
ldlework: i think there are a few different options. for adding a couple packages to the nix-shell one option is to make a shell.nix with `let pkgs = import <nixpkgs> {}; app = pkgs.callPackage ./default.nix {}; in pkgs.mkShell {buildInputs = [app foo bar baz];}`
<pjt_014>
cartesian-theatr: if the target system is nixos (anything with just nix the package manager might work too), then nix-copy-closure --from ip /nix/store/path followed by nix-env -i /nix/store/path will copy over and install something
lsix has joined #nixos
<pjt_014>
if not, there's a tool called nix-bundle that can build fully static binaries
<cartesian-theatr>
pjt_014 Yes potentially. I'm interested in deploying to a small robotic fleet in the field and building out local dev workflows to ease the pain of getting builds onto machines for testing.
<pjt_014>
energizer: real quick do you know how to use the nix shell with a package from unstable? It's something like nix-shell -I nixpkgs=? -p name
<cartesian-theatr>
Nix seems to offer quite a lot in this area.
<pjt_014>
cartesian-theatr: It def. makes building things easier
<ldlework>
energizer: you'd think mkPoetryEnv would make the binaries available by default
<ldlework>
since don't you need the test tools etc?
<adisbladis>
It does
<pjt_014>
cartesian-theatr: My first package I just copied something from another python project and replaced the github url and hashes lol
<pjt_014>
I thought I'd have to write tests or something, but the python building module noticed everything in ./tests and did it for me
<pjt_014>
very clean :))
<ldlework>
adisbladis: so if i want to have a shell where fab tool is available (and has access to my package and it's dependnecies) I should use mkPoetryEnv and have fab in my dev dependencies?
<adisbladis>
ldlework: Would you mind pasting your pyproject.toml/poetry.lock ?
<adisbladis>
ldlework: Yes, either that or (mkPoetryApplication { projectDir = ./.; }).dependencyEnv
codygman has quit [Read error: Connection reset by peer]
<cartesian-theatr>
pjt_014 nice! Have you used the multi-user features? That's another area I'm interested in because we have lots of shared resources.
<adisbladis>
The difference being that mkPoetryEnv is for development and pulls in development dependencies (but doesn't build your application)
codygman has joined #nixos
<adisbladis>
And mkPoetryApplication.dependencyEnv is buildin your app + runtime dependencies and linking all dependencies binaries
mallox has joined #nixos
<ldlework>
I think that's what I want since I'm just a library, and depend on the user to use fabric to run a fabfile.py (which they use my library in)
<ldlework>
in which case, fab would be a runtime dependnecy right?
<ldlework>
if I used mkPoetryApplication?
<ldlework>
OK I'm gonna try the mkPoetryEnv way first
<ldlework>
Add fabric to my dev dependencies, poetry update, to update the lockfile
<ldlework>
then rebuild the shell
<pjt_014>
cartesian-theatr: It's not so much a 'feature' as a side-affect of of how nix is structured. But it is very much better than installing things in home. It *feels* like a security problem at first, but most dangerous tools already require sudo so there's no harm in a normal user installing them
ultranix has quit [Ping timeout: 260 seconds]
<cartesian-theatr>
Yeah exactly, and you can share a lot of structure between users without worrying about collisions.
<cartesian-theatr>
What about creating a private, authenticated distribution channel? Is that supported?
<ldlework>
adisbladis: :( still no fab command in the shell
<cartesian-theatr>
I noticed it looks like it supports http simple auth.
<pjt_014>
cartesian-theatr: something as simple as nix-store --serve will work and give you all the sec properties of ssh, but there are other tools with more fancy
<ldlework>
adisbladis: it would seem none of the dev-dependency tools are available
<ldlework>
adisbladis: when i just run python and import my library, I get ModuleNotFoundError: No module named 'crayons'
<pjt_014>
It does support private repos or can be self-hosted
<ldlework>
i must be doing something very wrong
<pjt_014>
cartesian-theatr: there are some arm caches there too that are very handy
<ldlework>
i don't think the python inside the shell can see any of the dependencies
<cartesian-theatr>
pjt_014 beautiful. And when doing a ssh-copy of the store between two machines can it resolve the diff and only transfer that? Couldn't quite tell from the docs.
<pjt_014>
cartesian-theatr: If a path with a matching hash is already on the other machine, it won't be transfered. It doesn't go to Sub-path or sub-file level; that'd be a *lot* more complexity
<pjt_014>
cartesian-theatr: there is the --gzip and -s flags though
<pjt_014>
and if you really wanted to save space on the transfer, you could probably do some extra magic
<pjt_014>
maybe export a store path as a blob, compress it with zpaq or rzip or lrzip or something, wait a few hours, transfer it over, unpack and install
<adisbladis>
mkPoetryEnv does not create something for you to nix-shell into
<ldlework>
ooo
<ldlework>
lol
codygman has quit [Ping timeout: 256 seconds]
<cartesian-theatr>
pjt_014 I also notice that you can print the "transitive closure" of a Node in the store, but I didn't notice full-fedged feature like `guix pack` that's available in guix.
<adisbladis>
It's analogous to `python.withPackages(ps: [])`
logan12358[m] has joined #nixos
<pjt_014>
cartesian-theatr: just going off the name I think we have that
codygman has joined #nixos
<ldlework>
adisbladis: fab can't see my package
<ldlework>
neither can python
<adisbladis>
ldlework: I can `import crayons` just fine
<ldlework>
same
<ldlework>
but not 'blot'
<cartesian-theatr>
Like tarball with all the deps included and a profile?
<adisbladis>
ldlework: Do you have a directory called blot ?
proofofkeags has quit [Ping timeout: 246 seconds]
<ldlework>
adisbladis: yeah
<pjt_014>
cartesian-theatr: maybe. look in man nix-store under --dump and --export
<ldlework>
adisbladis: i am changing directory once in the shell
<adisbladis>
Probably that's it then
<pjt_014>
/ to search if you didn't know
<ldlework>
over to some "user" directory
<adisbladis>
mkPoetryEnv is for development usage, so it doesn't build your application
<adisbladis>
It depends on it somehow being importable
<adisbladis>
Usually by there being a python package in your working directory
<ldlework>
hrm
<ldlework>
adisbladis: does this mean that I should go the other way, with dependencyEnv?
dongcarl has quit [Read error: Connection reset by peer]
<adisbladis>
=)
<ldlework>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 81
andreas303 has joined #nixos
corpix has joined #nixos
<ldlework>
oh man I'm gonna be able to dev so much faster now
nixbitcoin has joined #nixos
xelxebar has joined #nixos
<cartesian-theatr>
pjt_014 I see, thanks. I have one question about NixOps. Have you (or anyone else) for deployments to essentially highly intermittently available machines? I'd like to push deployments all at once and have them apply as machines come Online and be able to monitor the process as it unfolds.t
<ldlework>
/nix/store/ba8fhbmvfyh439606lni91y420yflmlc-stdenv-linux/setup: line 1300: /nix/store/fwq4pa3dnk5ckrdfp2025srf8chl5wvq-python3-3.7.7-env/bin/fab: No such file or directory
vidbina has joined #nixos
<ldlework>
oh right
<ldlework>
I need to move it to the runtime deps
quinn has quit [Ping timeout: 240 seconds]
smatting has joined #nixos
quinn has joined #nixos
felixfoertsch has joined #nixos
<metheflea>
hey ldlework: i've been struggling to get nvidia prime offloading to work and i found some irc logs of you having the same issue a few days ago - did you ever get it working?
xelxebar has quit [Remote host closed the connection]
xelxebar has joined #nixos
<ldlework>
lol we need live-reload for nix
<srhb>
nil1: It is the right channel. :)
cartesian-theatr has quit [Remote host closed the connection]
<ldlework>
i'm so happy tho woot
<balsoft>
nil1: the next step is to wait...
<{^_^}>
[nixpkgs] @Mic92 opened pull request #88594 → PR to test CI error messages → https://git.io/Jf2EX
<nil1>
ok, thanks, I can wait
<srhb>
nil1: Or alternatively poke someone who has similar interests gently for review. Like, finding something in the same category of software in nixpkgs and asking them to take a look. :)
<srhb>
nil1: But yeah, in general, expect longer waits than one day. ;-)
dansho has quit [Ping timeout: 256 seconds]
<nil1>
srhb: no problem, I just wasn't sure if I had to do anything else...
<balsoft>
(from personal experience, just CC the people that might be interested in this and move on with your life)
<nixbitcoin>
srhb: There must be some way to do this in the nix syntax
jluttine has joined #nixos
<srhb>
nixbitcoin: I don't think there is via serviceConfig, but looking.
dermetfan has quit [Quit: WeeChat 2.7.1]
nil1 has quit [Quit: WeeChat 2.8]
<nixbitcoin>
srh:b Would one need to reimplement the systemd merge logic into nix syntax?
<srhb>
nixbitcoin: I mean you can totally do that, I'm just wondering whether there's a nicer way
maddo has joined #nixos
<nixbitcoin>
srhb: I hope so too. Would be very happy if you found something.
dansho has joined #nixos
<srhb>
nixbitcoin: lol, so simple. Just make the value a list.
<srhb>
nixbitcoin: SystemcallFilter = [ "foo" "bar" ]; will be transformed to SystemCallFilter=foo\nSystemCallFilter=bar
<srhb>
Apologies for the misinformation. :)
<nixbitcoin>
srhb: I thought of that, but I'm using an @system-call-group
<srhb>
nixbitcoin: Why does that matter?
orivej_ has joined #nixos
orivej has quit [Ping timeout: 256 seconds]
asymptotically has joined #nixos
<srhb>
nixbitcoin: To be clear about what I wrote above, in case I wasn't: Each list element will become a separate SystemCallFilter directive, in order.
<srhb>
nixbitcoin: I think that's exactly what you needed?
<srhb>
nixbitcoin: Like, `SystemCallFilter = [ "~not-this not-this-either also-nope" "this-one-is-ok also-this yup-this-too" ]` for a blacklist followed by a whitelist
o1lo01ol1o has joined #nixos
operator-name has joined #nixos
<nixbitcoin>
srhb: kk let me test
<{^_^}>
[nixpkgs] @flokli closed pull request #87116 → nixos/network-interfaces-scripted: fix dhcpcd when mac address set → https://git.io/JfZFe
<{^_^}>
[nixpkgs] @flokli merged pull request #88032 → nixos/scripted-networking: use udev to configure link MACAddress and MTUBytes → https://git.io/JfELp
<angerman>
clever: alright so this is my plan. I can get cpu/mem utilization every second and build a graph. Now I need to correlate the stdout output from hydra-eval-job to that.
<clever>
angerman: every time the heap usage (as tracked by the GC library) goes over a set limit, the child proc will exit, and the parent will fork out a replacement
<clever>
so the heap usage can be wiped clean at regular intervals
<angerman>
clever: so my idea is to just intercept stdin on a line-by-line basis, and inject some timestamp
o1lo01ol1o has joined #nixos
<angerman>
clever: right that would show up in the logs anyway, no?
<clever>
angerman: ive been thinking of adding some profling like that to hydra itself
<clever>
angerman: yeah, it prints that its restarting to stderr i believe
<angerman>
clever: yea, I'm being a peasant trying to bash my way out of it :D
<symphorien>
angerman: use ts from moreutils ?
<angerman>
symphorien: ts? hmm never heard of it.
alp has quit [Remote host closed the connection]
alp has joined #nixos
<angerman>
symphorien: nice. Why do I end up with the same names every time?
<{^_^}>
[nixos-search] @garbas merged pull request #44 → Format and link import script → https://git.io/Jf2gq
<{^_^}>
[nixos-search] @garbas pushed to master « Format and link import script (#44) »: https://git.io/Jf2VJ
<{^_^}>
[nixos-search] @garbas pushed 0 commits to format-import-script: https://git.io/Jf2VU
<balsoft>
I've just had a crazy idea: what if instead of banning builtins.fetchTarball without sha256 in restricted mode during flake eval, we actually performed it and then saved the sha256 to flake.lock? Same with fetchGit without rev
<balsoft>
Is this even an option?
datakurre has joined #nixos
iyzsong has joined #nixos
Acou_Bass has quit [Ping timeout: 272 seconds]
<bqv>
Or, just use flake inputs :p
<{^_^}>
[nixos-search] @garbas pushed to add-index-alias-and-make-import-atomic « implemented index alias to make import atomic »: https://git.io/Jf2wi
<{^_^}>
[nixos-org-configurations] @rbvermaa pushed to master « Disable backup sending to Rob's machine until ZFS raid recovers. »: https://git.io/Jf2wP
<{^_^}>
[nixos-search] @garbas opened pull request #46 → implemented index alias to make import atomic → https://git.io/Jf2wX
orivej has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos
<{^_^}>
[nixos-org-configurations] @rbvermaa pushed 6 commits to master: https://git.io/Jf2wH
shafox has quit [Remote host closed the connection]
shafox has joined #nixos
zupo has joined #nixos
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<clever>
betawaffle: if you lack a src, its common to use pkgs.runCommand
orivej has joined #nixos
<betawaffle>
that reminds me of another question... why are there so many non-packages at the top-level of nixpkgs? shouldn't all of those things be under lib?
<clever>
betawaffle: for example?
<betawaffle>
runCommand for example, umm
<bqv>
I rationalize it as "if it produces a drv, it goes in pkgs
<infinisil>
shreyansh_k: Should be possible with `.overrideAttrs (old: { src = ./.; })`
<tyrion-mx>
Hello, I am trying to compile Python from source, I do `nix-shell -p gcc pkgconfig zlib`, but when I run make it seems Python cannot find zlib. Any hints on what I should do?
<{^_^}>
[nixos-search] @garbas merged pull request #46 → implemented index alias to make import atomic → https://git.io/Jf2wX
<{^_^}>
[nixos-search] @garbas pushed to master « implemented index alias to make import atomic (#46) »: https://git.io/Jf2KL
<{^_^}>
[nixos-search] @garbas pushed 0 commits to add-index-alias-and-make-import-atomic: https://git.io/Jf2Kq
Pidgeotto has quit [Excess Flood]
Pidgeotto has joined #nixos
<balsoft>
bqv: my use-case is stuff that's generated automatically with IFD, where the soure doesn't specify sha256 for the actual package sources (opam, I'm looking at you...)
<shreyansh_k>
infinisil: Thank you very much. It is working. With that out of the way, here is a follow up. Until this point, I understood that `override` is the way to override a package expression, is `override` not recommended anymore and is it deprecated?
<infinisil>
shreyansh_k: .override overrides different things than .overrideAttrs
<{^_^}>
[nixos-search] @garbas merged pull request #47 → import channel script should be idempotent → https://git.io/Jf2K0
<{^_^}>
[nixos-search] @garbas pushed to master « import channel script should be idempotent (#47) »: https://git.io/Jf2Kg
drakonis_ has quit [Ping timeout: 260 seconds]
knupfer has joined #nixos
<{^_^}>
[nixos-search] @garbas pushed 0 commits to skip-importing-if-index-exists: https://git.io/Jf2KV
wnklmnn has quit [Read error: Connection reset by peer]
camsbury has joined #nixos
<camsbury>
hi there - my nix build is locked up with waiting for locks or build slots...
justanotheruser has quit [Ping timeout: 252 seconds]
wnklmnn has joined #nixos
<camsbury>
and restarting doesn't esem to help
<camsbury>
trying to `nix-shell -p clj-kondo`
<camsbury>
for example
vidbina has quit [Ping timeout: 264 seconds]
<{^_^}>
[nixpkgs] @Mic92 opened pull request #88608 → actions/editorconfig: disable until we can combine this with ofborg → https://git.io/Jf2Kb
<Mic92>
zimbatm: ^
D_ has quit [Ping timeout: 244 seconds]
<{^_^}>
[nixos-search] @garbas pushed to run-import-channel-every-hour « run import-channel every hour for last 3 channels »: https://git.io/Jf2KN
<{^_^}>
[nixos-search] @garbas opened pull request #48 → run import-channel every hour for last 3 channels → https://git.io/Jf2KA
<balsoft>
camsbury: This means that either there's a build going on in the background that's building some packages which are a dependency of clj-condo, or something broke
<zimbatm>
Mic92: let's remove the whole file?
<balsoft>
You can try nix-shell -vvvv -p clj-kondo and look at the things that it's waiting for
<balsoft>
You can potentially nix-store --delete them (which is how I fixed such issues in the past)
arjen-jonathan has joined #nixos
andreas303 has joined #nixos
<{^_^}>
[nixos-search] @garbas pushed to run-import-channel-every-hour « run this on PR for testing purpose »: https://git.io/Jf26J
<Mic92>
zimbatm: done
D_ has joined #nixos
<{^_^}>
[nixos-search] @garbas pushed to run-import-channel-every-hour « another test »: https://git.io/Jf26k
qbit has quit [Quit: WeeChat 2.8]
<kraem>
am i misunderstanding if fetchGit is supposed to check my .gitconfig and use the https to git@git substitution defined there to use my ssh-agent when cloning private git repos? right now it's launching seahorse for me to enter username + password which doesn't work when having 2FA enabled on github
davidv7 has quit [Ping timeout: 258 seconds]
<{^_^}>
[nixpkgs] @zimbatm merged pull request #88608 → actions/editorconfig: disable until we can combine this with ofborg → https://git.io/Jf2Kb
<{^_^}>
[nixpkgs] @zimbatm pushed commit from @Mic92 to master « actions/editorconfig: disable until we can combine this with ofborg (#88608) »: https://git.io/Jf26q
MmeQuignon has quit [Ping timeout: 260 seconds]
<{^_^}>
[nixos-search] @garbas pushed to run-import-channel-every-hour « run on the correct repo »: https://git.io/Jf26m
<tyrion-mx>
I am trying to compile Python from its source distribution. I am doing ./configure and make, but it is not finding zlib, even though I am using nix-shell to install it. I really don't know what I am doing wrong, and I didn't manage to find anything online. Could anybody please help?
orivej has quit [Ping timeout: 246 seconds]
orivej_ has joined #nixos
<balsoft>
tyrion: Are you doing nix-shell "<nixpkgs>" -A python3 ?
<tyrion-mx>
balsoft: No, I am downloading the Python source and trying to compile it
<balsoft>
tyrion: Also, if you want to simply apply some patches to python (or build it from a non-standard source), you can use overrideAttrs instead of building it manually
<tyrion-mx>
no, unfortunately now I just need to build Python manually (I need to debug some behaviour of pyenv)
<tyrion-mx>
But this seems to be a basic task (to compile something and have the correct flags), so I am wondering if I am missing something really obious or not
<balsoft>
tyrion: Well, try nix-shell "<nixpkgs>" -A python3 it should drop you in a shell with all the dependencies available
<tyrion-mx>
ah, that is cool, thanks i will try now
<camsbury>
balsoft: okay will do
<balsoft>
(Or nix dev-shell nixpkgs#python3 if you're using nixFlakes)
proofofkeags has joined #nixos
<tyrion-mx>
`nix-shell "" -A python3` this complains that there is no default.nix
<balsoft>
Hmm, is matrix butchering <> again?
<betaboon>
srk: did you ever figure out the compile-problems of systemd for armv7 using cross-system ?
<balsoft>
nix-shell "(nixpkgs)" -A python3 but replace ( with < and ) with > :)
<balsoft>
Sorry for the confusion...
<balsoft>
`nix-shell "<nixpkgs>" -A python3`
ultranix has joined #nixos
* calbrecht
wonders if it is a problem for python packages if their RECORD file is no longer valid after fixupPhase
proofofkeags has quit [Ping timeout: 272 seconds]
<srk>
betaboon: replaced '(if !stdenv.hostPlatform.isEfi ..' with "-Defi=false" in mesonFlags
<srk>
betaboon: there's a PR which has withEFI flag so it's gonna be fine when that lands
arjen-jonathan has quit [Quit: WeeChat 2.8]
<betaboon>
srk: gonna try your workaround on monday. i need to build a rootfs-tarball to use as nfsroot on orangepi :/
<srk>
betaboon: I can publish the patched staging branch if needed but most of the stuff is PRed or merged I think
<tyrion-mx>
balsoft: it worked \o/ thank you. The main difference I see, is that after your command if I run `env | grep zlib` I see CPPFLAGS and LDFLAGS defined, with nix-shell all the variables were prefixed with `NIX_` ... I wonder why?
ohhaimark has joined #nixos
<ohhaimark>
I want to set the CALIBRE_USE_DARK_PALETTE environment variable for calibre with a package override. How would I go about doing that?
<balsoft>
tyrion: no problem! I don't know about NIX_ things, TBH
morgrimm has joined #nixos
<infinisil>
ohhaimark: You mean at runtime?
<infinisil>
Or build time
<ohhaimark>
Yeah
<ohhaimark>
runtime
<infinisil>
Then check out `wrapProgram` and its `--set` argument, you should find lots of usages when searching through nixpkgs
<ohhaimark>
Cool cool, thanks.
<betaboon>
srk: thanks for the headsup. i might come back to your offer :)
<calbrecht>
i mean like there are sha256 hashes in the RECORD file, maybe that's why e.g. psutil is trying to build again even when all libs are already built and present by python.withPackages
<nixbitcoin>
How do I override an option in a module that's already specified somewhere else?
<infinisil>
nixbitcoin: Set it again with a higher priority, e.g. `the.option = lib.mkForce "the-value"`
<evanjs>
infinisil: on a related note, any recommendations for multiline searches across nixpkgs? Like, I always have issues finding things like e.g. virtualisation.virtualbox - where the attribute might be spread across multiple lines, etc
<infinisil>
Not that I know of
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos
<infinisil>
I did have this idea of implementing a nixgrep-like thing that searches for a nix AST node
<evanjs>
*throws rnix at* :P No but I guess that makes sense. Noteverything can be done with regex :P
<infinisil>
evanjs: What this would also allow is to have inter-file searches. E.g. if you had declared `foo = import ./foo.nix` and foo.nix had `{ bar = 10; }`, you could search for `foo.bar = ?` and it would find that
<infinisil>
I guess it wouldn't be AST node search then, but rather expression search
ohhaimark has quit [Remote host closed the connection]
<phnom>
Anyone else have problems with KDE+nvidia? I get a blue overlay when I enable compositing with openGL.
<{^_^}>
[nix-mode] @matthewbauer pushed commit from @dangirsh to master « add README section for nix-prettify-mode (#100) »: https://git.io/Jf2ip
alp has joined #nixos
Henson has joined #nixos
<nixbitcoin>
infinisil: thanks, where is that kind of stuff documented?
<Henson>
Hi everyone. I'm trying to use Nixops and have deployed to a remote system and set up the remote SSH key. Then I realized I made a mistake and reverted the remote system, but nixops doesn't know that. Now I can't connect to the remote system because it's expecting ssh public key auth to work, which it doesn't. Can I disable ssh public key auth and redeploy by using ssh keyboard-interactive?
<hyper_ch>
finally I have KDE file chooser in Thunderbird instead of the GTK one :)
<clever>
Henson: nixops can use any keys in ssh-agent
<hyper_ch>
Henson: I found this: https://phabricator.kde.org/T10189 so I added xdg-desktop-portal and plasma5.xdg-desktop-portal-kde to the system packages. Then I added Exec=GTK_USE_PORTAL=1 to my ~/.profile then I run once Exec=GTK_USE_PORTAL=1 /run/current-system/sw/bin/thunderbird --> that worked
<Henson>
clever: nixops just gives me the error "Permission denied (publickey,password,keyboard-interactive)" and doesn't ask me for the password.
<hyper_ch>
I closed TB again and run it from kicker/kmenu (?) and it still uses kde dialog file chooser
<clever>
Henson: did you start an ssh agent?
<hyper_ch>
haven't restarted though but due to it being also in .profile now I think it will also work after restart
<Henson>
hyper_ch: cool. Does that also work for other programs?
<Henson>
clever: quite possibly yes
* Henson
kills ssh-agent
<clever>
Henson: that will make it worse!
<hyper_ch>
Henson: works also fore firefox.. .
<Henson>
c
* Henson
pauses
<hyper_ch>
don't know any others
<clever>
Henson: you want the ssh agent running, and a key in the agent that can access the machine
<Henson>
clever: ok, so what should I do?
<clever>
Henson: ensure the agent is running, and ssh-add a key to it
<Henson>
clever: right, but Nixops deployed to that machine, sticking its public key into the remote machine. But the remote machine has now been rolled back and doesn't have that key anymore, so nixops can no longer connect. Before the first deployment it would ask me for the password, which is all I need to do to redeploy and fix the problem.
<hyper_ch>
Henson: gimp has its own file chooser that's not affected as it seems
<clever>
Henson: you may need to edit /root/.ssh/authorized_keys first, to ensure you can get in
<puzzlewolf>
Is 19.09 still supported? The Vulnerarbility roundup contains a lot of issues for it. Do we backport security fixes?
<puzzlewolf>
End of support is planned for end of April 2020, handing over to 20.03.
wnklmnn has quit [Read error: Connection reset by peer]
<Henson>
clever: right, but nixops uses a public key that's stored in the nixops database, which I can try extracting, but it seems like this should be an easier problem to overcome.
orivej has quit [Ping timeout: 240 seconds]
<Henson>
hyper_ch: thanks for the tips, I'm going to try that on my system.
horek has quit [Client Quit]
<clever>
Henson: simplest is to add a secondary keypair, with agent and manual editing, to let nixops deploy once
orivej has joined #nixos
<clever>
Henson: after nixops deploys, it will whitelist its own key, and not need the agent anymore
<hyper_ch>
Henson: well, still have to reboot... but since I added that exec thing to the .profile, I think reboot will not interfere
wnklmnn has joined #nixos
<Henson>
hyper_ch: I use thunderbird, too, and one thing that drives me crazy is that in Nix the up and down arrows in the e-mail list scrollbar are missing, and the default behaviour (without editing the GTK3 style file) is to have the scroll bar jump to where you clicked it. So if you have 25,000 e-mails in your inbox (which I do), then it's very difficult to navigate.
<evanjs>
infinisil: okay where is it
<evanjs>
I want it now XD
<hyper_ch>
Henson: it's file choser dialog... e.g. want to save an email or attach a file... it drives me crazy that gtk file choser does not sort folders first and difference between folder and file is barely visible
camsbury has quit [Remote host closed the connection]
<Henson>
hyper_ch: yeah, it drives me crazy too. I was just wondering if you also have the problem of the missing up and down arrows in the scroll bar.
<hyper_ch>
not sure what you mean with missing up and down arrows in the scroll bar
<Henson>
hyper_ch: and when you try to type in the name of a directory to highlight, it instead searches for all files or directories with that name, and gives you a random mash of stuff.
<{^_^}>
[nixpkgs] @Ma27 opened pull request #88610 → wireguard-go: fix executable name → https://git.io/Jf2Pw
<hyper_ch>
Henson: still not sure what you mean.. you mean in the file chosing dialog?
<Henson>
hyper_ch: you know at the top and bottom of a scroll bar there are up and down arrows to move the list by a little bit at a time? In my thunderbird those are gone, it's just a scroll bar.
<hyper_ch>
ah, now I know
leah2 has quit [Ping timeout: 260 seconds]
<Henson>
hyper_ch: yeah, sorry, I'm talking about 2 different things at the same time without clearly separating the two. The search thing was for the file chooser.
<la-s>
I tried just setting the src attribute of ghcHEAD to their github repo, but I had an error, which I didn't record, and it took me hours to get that errors
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
asymptotically has quit [Remote host closed the connection]
<Henson>
clever: do you know how to use Nixops to deploy NixOS containers onto a NixOS machine? I'm trying to define a physical machine with two NixOS containers running on it.
<clever>
Henson: i tend to just use normal declarative containers in the nixos config for the host, and let nixops only deal with the host
<tyrion-mx>
What is the reason not to have all possible python versions installable with nix? Or is it a way to install python 37 by chaning for exaple the "patch" version?
<clever>
Henson: the nixops { key = value; } file, is a set of nixos configs
<clever>
Henson: each value there, is basically the full contents of a configuration.nix, and can do anything configuration.nix could have done
<clever>
including define declarative containers
<Henson>
clever: yes, and when I tried defining the NixOS machines in there it gets upset. I import some NixOS modules into the Nixops configuration. When I define the NixOS containers within a machine, the config that is passed into the container, is not the same config as it used to define the machine, and I am unable to access the custom modules I've imported into the nixops configuration.
<clever>
Henson: how did it get upset? what error did it give?
<Henson>
clever: it was simply unable to find the additional NixOS modules that were overlaid onto the configuration. In the Nixops network definition that modules were present, but you define the NixOS container with a lambda that takes an attribute set as an argument, with one of those arguments being "config". That config used to define the NixOS container did not contain the modules overlaid onto...
<Henson>
clever: the config that was being used by the nixops network definition.
<clever>
Henson: it works the same way outside nixops, the containers are an isolated nixos instance, with their own module set
<Henson>
clever: so there were options I had to specify in the container that I was unable to because those options were not visible in the config that was being passed into the Nix container definition.
<clever>
Henson: you need to add the module to the imports of each container
<Henson>
clever: I'm still stuck on the Nixops password thing. I've added my id_rsa key with ssh-add, and have added it to authorized_keys on the remote system, but it's still not letting me in. It's quite possible that passwordless logins for root are disabled on the machine I'm deploying to. All I need is for nixops to ask me for a password. I'm going to edit the nixops database file to remove the...
<Henson>
clever: state for the remote system.
<clever>
Henson: are you able to `ssh root@ip` with that agent?
<Henson>
clever: no, which is why I think it's disabled in the remote ssh config
<clever>
Henson: what is the contents of sshd_config on the remote machine?
gustavderdrache has joined #nixos
ebopp has joined #nixos
<Henson>
clever: deleting the state from deployments.nix fixed the problem.
<hyper_ch>
Henson: still got kde file choser dialog after reboot
<Henson>
hyper_ch: cool, I'll give that a try on my system later. I've missed the KDE file chooser.
<hyper_ch>
just add teh two packages to system packages, rebuild switch, and set the entry to your .profile
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos
<kraem>
when running `nix-shell -p nix-prefetch-git --run "nix-prefetch-git https://github.com/kraem/private-repo"` it prompts me for username + password for github. but when i run `./nix-prefetch-git https://github.com/kraem/private-repo` directly from a clone of nixpkgs it reads my gitconfig and ssh credentials and downloads the repo fine. why is this even though i didn't provide --pure to nix-shell?
fusion809 has quit [Remote host closed the connection]
<cole-h>
cybertron: As suggested above, you can check https://nixos.org/nixos/options#influxdb, or `man configuration.nix`, or `nixos-option services.influxdb` (the last two in your terminal)
drakonis_ has joined #nixos
<cole-h>
I think another problem is that you're trying to use `cfg.dataDir` in your `dataDir`, but there is no `cfg` anywhere.
teto has quit [Quit: WeeChat 2.8]
<cybertron>
ok stupid example. how I can change the data wal-dir?
<cybertron>
you mean let
<cybertron>
cfg = config.services.influxdb;
<cybertron>
?
zebrag has joined #nixos
<cole-h>
Yeah. That wasn't in the file you posted.
zupo has joined #nixos
justanotheruser has joined #nixos
drakonis has quit [Ping timeout: 246 seconds]
<cybertron>
right, didn'thought that I need that
<cole-h>
Well, then what is `cfg` going to refer to? :P
<cybertron>
I'm not really confirm with nix :/
<cole-h>
Well, think about it from any other language's viewpoint. If you don't have e.g. `int asdf = 0;`, how is your compiler going to know what `int jkl = asdf;` refers to?
<jakobrs>
How am I supposed to reset a configuration option to its default if it's changed by another module?
<jakobrs>
I mean, I know that I can do path.to.option = lib.mkForce options.path.to.option.default
<jakobrs>
but I'm not sure if this is the "correct" way to do it?
MightyJoe has joined #nixos
<balsoft>
jakobrs: Why? It does the right thing and it's not complex enough to deserve a separate function. I always use that, at least :)
cyraxjoe has quit [Ping timeout: 246 seconds]
<jakobrs>
I mean, sure, I just wanted to be sure
morgrimm has joined #nixos
<betawaffle>
when i do `nix-env -iA nixos.something` does that take overlays into account? where does the `nixos` part come from?
<jakobrs>
Completely unrelated question, what decides what polkit agent is used (by systemctl etc)?
<jakobrs>
betawaffle: nixos is the name of the channel
<betawaffle>
so if i have a channel called nixos-unstable, i'd need to do nixos-unstable.something then?
<jakobrs>
yes
<jakobrs>
And if you have nixpkgs-unstable listed as "nixpkgs", you'd do nix-env -iA nixpkgs.something, for example
<balsoft>
Hopefully nix-env is going away. I really can barely wait for nix profile to roll out, it's so much more intuitive.
Cale has joined #nixos
<balsoft>
jakobrs: I think it's basically whatever has the corresponding D-BUS interface?
<balsoft>
I might be mistaken though
<betawaffle>
balsoft: when is that happening?
Neo-- has quit [Ping timeout: 256 seconds]
<jakobrs>
balsoft: Do you happen to know how to ... change that?
betaboon has quit [Ping timeout: 244 seconds]
<betawaffle>
jakobrs: ok, so now how do overlays factor into that?
<jakobrs>
betawaffle: overlays are applied "on top of" the channel, I think
<betawaffle>
so, all channels?
<jakobrs>
I haven't used them much personally, but
<jakobrs>
yes
<jakobrs>
I think
<balsoft>
betawaffle: I hope it's going to be in nix 2.4, which I hope is going to roll out for 20.09. But that's pure speculation, I don't have any official sources.
gxt__ has quit [Ping timeout: 240 seconds]
<jakobrs>
So if you do nix-env -iA channel.pkg, it will build '(import <channel> { overlays = [ list of overlays ]; }).pkg'
<betawaffle>
so i have to wait until mid-september :/
<jakobrs>
as for nix 2.4
<balsoft>
jakobrs: maybe if you describe your issue I'll be able to help.
<jakobrs>
I kinda wish nix-command was enabled by default
<balsoft>
betawaffle: you can switch to it right now
<betawaffle>
:o how?
<jakobrs>
balsoft: I just wanted to try to unset it, to see if I like the more standard console-only polkit agent used by systemctl better
<balsoft>
betawaffle: beware of some stuff: you better add nix.extraOptions = "experimental-features = nix-command flakes"; too or it can get uncomfortable
<balsoft>
jakobrs: I'm afraid you'll have to kill your current agent for that
<jakobrs>
Wow, just tried nix-shell -p nixUnstable -c nix --help and there's
<jakobrs>
well, new stuff
<balsoft>
Yeah, including the fact that nix run is now nix shell and nix app is now nix run
<betawaffle>
jakobrs: huh, nix-shell is complaining that `-c` isn't valid
<jakobrs>
If you set experimental-features = nix-command nix stable will complain that experimental-features is unknown, which is kinda annoying
<jakobrs>
betawaffle: meant `nix run nixpkgs.nixUnstable`, not `nix-shell -p nixUnstable`
<jakobrs>
Also, you need to add --experimental-features nix-command to the end unless you've set that somewhere else
<betawaffle>
how are there not fish completions for nix?
<jakobrs>
betawaffle: Just `exec zsh` to get them working /s
<betawaffle>
i don't normally use fish, but i'm giving it a try on this machine
<betawaffle>
am i doomed?
<jakobrs>
I don't know, I don't use fish myself
<balsoft>
jakobrs: BTW zsh completions are completely broken on unstable nix...
<hyperfekt>
Is there any way to see historical channel refs?
<bqv>
emily: not sure which cli tools you mean, but i just reexport my amended pkgs from nixpkgs as self's legacyPackages, so i can always get system-matching packages from either packages or legacyPackages
MightyJoe has quit [Ping timeout: 256 seconds]
<bqv>
i never use nixpkgs#, only self#
<bqv>
(which is helpful because up until recently i didn't even technically have a nixpkgs#)
<drakonis1>
its for derivations where the output can change every time its run
<calbrecht>
funny enough, just found out why some python packages are non-deterministic
<emily>
bqv: makes sense
<emily>
bqv: I figured out how to do it though: (getFlake "path:/nix/store/nd8w6gkh2jzrzkkkwpmzwk9v5kzzqk68-source?lastModified=1589859699&narHash=sha256-%2fI9KUnlMs+vf0Zb5ZHmfgQFSphtWguJ49wPM7cqjwqw=").inputs.nix.overlay works in pure mode
<bqv>
lmao
<emily>
now I just need to figure out if there's actually a way to generate a self-reference like that from within the flake...
<emily>
there's inputs.self but I'm not sure how you can map to the URL-ish thing from Nix
<bqv>
pretty sure that url is just inputs.self but specific to a particular version
<drakonis1>
one of the main nice things is that now can now have derivations that point towards a master repository
<drakonis1>
you dont have to pin and periodically update it
<balsoft>
emilazy: Can't you just toString it?
<emily>
balsoft: that just returns a raw path
<calbrecht>
this is for __pycache__/*.pyc files when pip-wheels is involved it seems. Like build/pip-unpacked-wheel-k1uxclcw/psutil vs. build/pip-unpacked-wheel-g_9eb570
<emily>
which is probably good enough, but it's not quite the same
<emily>
it could break if I used the metadata somehow
<balsoft>
drakonis1: you can do that with fetchGit though, right?
<balsoft>
emilazy: narHash can probably be generated with IFD and nix-hash...
<emily>
maybe I should deliberately break them by unsetting nixpkgs and see how painful it is
KeiraT has joined #nixos
<{^_^}>
[nixpkgs] @doronbehar opened pull request #88620 → mpv: Move all wrappings to a single wrapper Nix function → https://git.io/Jf2Hv
<emily>
bqv: how do you inherit legacyPackages? inherit (nixpkgs) legacyPackages doesn't work since that's prior to the overlays from your nixos config being applied, right?
<numkem>
is the new buildGoModule with vendorSha256 working for anyone? I get an error saying I don't have the vendor folder but from I can see it's supposed to do it on it's own
<emily>
but I guess it might not be exposed to the user language
<calbrecht>
energizer: nice :)
orivej has joined #nixos
xd1le has quit [Read error: Connection reset by peer]
knupfer has quit [Ping timeout: 244 seconds]
<balsoft>
drakonis1: yes, I know that impure derivations could be immensly useful in some situations, I just think that for most stuff fetchGit is enough
alp has quit [Ping timeout: 272 seconds]
<drakonis1>
haha yikes github gets so slow when there's too many comments
xd1le has joined #nixos
<emily>
bqv: so... do you just have to import nixpkgs twice?
<emily>
bqv: right now I just do inputs.nixpkgs.lib.nixosSystem directly
<emily>
and set my flakes in the NixOS configuration
<emily>
but it seems like to specify overlays or define legacyPackages you have to import nixpkgs from the path directly rather than as a flake input, specifying additional overlays?
<emily>
some parts of the flakes design are so weird...
<bqv>
ah yeah, i do an explicit import of nixpkgs and set overlays in it, and then pass that through when i create host configs
<emily>
which actually means that you're using nixpkgs/default.nix rather than nixpkgs/flake.nix, right?
<emily>
because you do import <the input>, which does toString <the input>, which returns the source directory
<bqv>
for pkgs, yes, for the system no
<bqv>
nixpkgs is a real special snowflake anyway...
<bqv>
pun not intended
<emily>
hmm, I see
<emily>
so you still have overlays set in two places: the flake and the nixos config
<emily>
whereas I have overlays in two places: the nixos config and awful generated stuff
<bqv>
i don't have to set the overlays in the nixos config, they're already applied, i just set config.nixpkgs.pkgs to the already overlayed pkgs
<emily>
where are they supplied? it seems to me you call lib.nixosSystem straight from the master dependency with no overlays applied
<emily>
balsoft: you need { flake = inputs.self; }
<emily>
= inputs.self directly will break
<emily>
but that actually seems like a fairly nice solution, thanks
meh` has quit [Ping timeout: 264 seconds]
<emily>
only problem is you end up evaluating one config on all machines
<energizer>
betawaffle: what would be the purpose?
<energizer>
of avoiding nixpkgs
artistsvoid has joined #nixos
Thra11 has quit [Ping timeout: 240 seconds]
<balsoft>
emilazy: yes, but it's fine in my case because overlays are the same everywhere, so the only issue is that it will take twice as long to eval on my laptops...
<balsoft>
emilazy: hmm, what? I did nix.registry.self.flake = inputs.self which is exactly what you mean, no?
<emily>
oh, sorry, I missed the .flake...
<betawaffle>
energizer: oh idk, nothing I suppose.
<emily>
Nix's autovivification catches me off-guard sometimes
<emily>
languages with autovivification: Perl, Nix, ...
<{^_^}>
[nixpkgs] @Ekleog pushed commit from @Sohalt to master « nottetris2: init at 2.0 (#87028) »: https://git.io/Jf2Hr
* cole-h
googles "autovivification"
<emily>
the thing where setting foo.bar.baz creates foo = { bar = { baz = ... } } } for you
rogue_koder_ has joined #nixos
<emily>
er, with some more ;s in there
<cole-h>
Oh, cool.
rogue_koder has quit [Ping timeout: 256 seconds]
alp has joined #nixos
<emily>
(it makes sense, it's convenient and the only reasonable way for Nix to support setting "structured paths" in what are actually declarative literals, it's just an unusual feature)
<emily>
it's not actually like perl since it's a syntactic feature rather than bizarro mutation behaviour
<energizer>
i've been trying to figure out if there's a difference between those, still can't wrap my head around it
<betawaffle>
When is nix going to get the cool hashing functionality of dhall?
<bqv>
what's that?
<betawaffle>
On my phone, look at the dhall website, the part with diffing
<energizer>
emily: isn't a.b.c=1 just plain ol mutable state?
<gchristensen>
no because it isn't mutation, it is creating a new attrset
<emily>
nix doesn't have mutability
<energizer>
i can't tell the difference
<betawaffle>
There’s a gif that shows an example, bqv
<emily>
your nixos configuration { some.setting = 123; some.other.setting = 456; } is just { some = { setting = 123; }; some = { other = { setting = 456; }; }; }
<emily>
it gets evaluated and merged with other configurations
<emily>
energizer: for instance, there is no ordering of settings in your nixos configuration
<gchristensen>
and you can't mutate it
<emily>
additionally, you cannot access the configuration values with the same names you set them by (the final configuration is available as the config argument, but that's not quite the same thing)
<gchristensen>
> :p { a = 1; a = 2; }
<{^_^}>
error: attribute 'a' at (string):312:10 already defined at (string):312:3
<gchristensen>
:p { some = { setting = 123; }; some = { other = { setting = 456; }; }; }
<gchristensen>
> :p { some = { setting = 123; }; some = { other = { setting = 456; }; }; }
<{^_^}>
{ some = { other = { setting = 456; }; setting = 123; }; }
hplar has joined #nixos
<emily>
bqv: hm. so it turns out that if you do nixpkgs#whatever, it actually ignores <nixpkgs-overlays> entirely
<emily>
which makes sense: flakes are pure and can't look there
<emily>
so your approach or balsoft's is pretty much the only option to get overlays working properly for nix(1)
<energizer>
emily: what do you mean about ordering?
<emily>
you can literally change the order of all the foo = bar; statements in your nixos config and nothing will happen
<emily>
mutable state involves state changing over time, a was 2, you do a=3 and then can observe that a is 3
<energizer>
i see, yeah
Thra11 has joined #nixos
<Henson>
in nixos configuration, if different modules depend on values from other modules, the configuration gets iterated until it reaches a fixed point, so even the ordering in which the files are imported doesn't matter, right?
<gchristensen>
right
<gchristensen>
lists can provide an observable ordering, though
<Henson>
true
<anderson_>
Hello, people! A quick question: how can I intercept SUID in the install phase?
<energizer>
betawaffle: i think the dhall behavior you're talking about is already the behavior of nix drv hashes
<clever>
anderson_: simplest thing is to just patch it out of the install/build scripts
<anderson_>
clever: patching the build system of the software, you say?
<clever>
anderson_: yeah
<betawaffle>
energizer: but that only works for derivations, not stuff in general.
<anderson_>
Oh man, I will be forced to learn cmake!
<bqv>
unless you're using nix for configuration or something, in which case you should probably be using dhall :p
<cole-h>
Just s/ SETUID// and should be good to go.
<anderson_>
Oh, OK, I will try.
<energizer>
emily: if lists have observable ordering then i'm confused again. final result can be determined by import order, right?
<{^_^}>
[nixpkgs] @husseinraoouf opened pull request #88623 → Vscode: Fix "Open in Vscode" in pantheon DE → https://git.io/Jf2Qk
<gchristensen>
Nix does not have mutation
<gchristensen>
the NixOS module system fakes it
<emily>
energizer: yes, import order matters. the most imperative part is the "merging" step, which is basically updating the entire config with new values "as if" it was mutable state, yes, but the actual modules themselves don't have mutation in them
<emily>
well
<emily>
order matters for some things
fendor has quit [Remote host closed the connection]
<emily>
it generally shouldn't matter for nixos modules but it does for overlays and so on
pamplemousse has quit [Ping timeout: 265 seconds]
<emily>
but it doesn't mean that doing { haskellPackages.blah = ...; } inside an overlay is an imperative assignment per se, it's more like you're describing overrides to be performed declaratively
<bqv>
you know the thing that does `:p` in nix repl; is that exposed as a builtin?
<energizer>
unless you do haskellPackages.blah = first mypackageList
<gchristensen>
no, bqv
<bqv>
damn
<{^_^}>
[nix] @cleverca22 opened pull request #3609 → fix segfault and type changing weirdness caused by use-after-free bugs, caused by lack of GC roots → https://git.io/Jf2Qq
fendor has joined #nixos
jkarni_ has joined #nixos
rogue_koder_ has quit [Ping timeout: 260 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
<emily>
gchristensen: oh, it doesn't include the code
jco1 has quit [Client Quit]
<emily>
I ust tried it with (x: x) and it looked sufficiently right
jco1 has joined #nixos
<gchristensen>
ah
jco1 has quit [Client Quit]
zebrag has joined #nixos
jco1 has joined #nixos
jco has quit [Ping timeout: 244 seconds]
inkbottle has quit [Ping timeout: 256 seconds]
cole-h has quit [Quit: Goodbye]
elibrokeit has quit [Quit: A random quit message]
elibrokeit has joined #nixos
cole-h has joined #nixos
cole-h has quit [Client Quit]
<betawaffle>
Nix has a mode that doesn’t involve running a daemon, right?
<MichaelRaskin>
Yes
Vikingman has joined #nixos
<MichaelRaskin>
If you are root or own the store, and $NIX_REMOTE is empty
<gchristensen>
a "single user" mode without the protection of the store
<energizer>
in dhall-nix, how do i refer to expressions that are defined in nixpkgs?
<energizer>
or am i just supposed to not do that
cosimone has quit [Quit: Quit.]
<bqv>
the latter
<betawaffle>
gchristensen: and that would be appropriate for using nix inside a container, right?
jco1 has quit [Quit: WeeChat 2.7]
<energizer>
bqv: how do i say what packages i want?
jco has joined #nixos
<bqv>
you don't?
<bqv>
dhall isn't nix
<bqv>
and doesn't support nixpkgs
<bqv>
and will never support nixpkgs
<energizer>
what use is a configuration language for a package manager if it doesnt have any packages?
<bqv>
dhall isn't a configuration language for a package manager
<bqv>
it's a configuration language
<gchristensen>
betawaffle: I haven't really used nix in a container
<bqv>
nix is a configuration language for a package manager
<gchristensen>
but yeah probably
<bqv>
dhall is not nix :p
<anderson_>
nix is turing-complete, isn't it?
<energizer>
bqv: what's the goal of the dhall-nix project?
<bqv>
energizer: to translate dhall expressions to nix expressions, afaik
<commandocrypto[m>
o
<betawaffle>
anderson_: absolutely.
<commandocrypto[m>
* i'
<energizer>
bqv: just not expressions that refer to packages
<commandocrypto[m>
* i'm al;so wondering what the purpose of the dhall-nix compiler now is - what kind of nix code would you make with it?
<bqv>
you could do anything that you feel is sufficiently complex it warrants typechecking
waleee-cl has joined #nixos
cole-h has joined #nixos
<bqv>
but you'll still need nix at the end of the say, because there's things fundamental to nix that can't be expressed in dhall
<bqv>
trivial example: how would you type builtins.listToAttrs
<energizer>
so if i want to express `environment.systemPackages = [pkgs.vim]` in a type-checked manner, what do i do?
<bqv>
or wherever that function is
<bqv>
energizer: you don't
<bqv>
if you're trying to use dhall for anything involving packages, you're doing it wrong
<energizer>
afaik everything i do with nix involves packages, no?
<betawaffle>
dhall is for data, not logic
cole-h has quit [Client Quit]
<energizer>
betawaffle: fuzzier distinction than it seems
<bqv>
energizer: `nix eval --json --expr '1 + 1'`
<simpson>
energizer: To pick up a thread from the other day, how do you want to handle transactions? How do you want to handle the fact that The Filesystem is inherently unityped?
<bqv>
or the irc version of that:
<bqv>
> 1 + 1
<{^_^}>
2
<bqv>
nix is a language like any other, it just so happens it's mostly involved with package management
<energizer>
bqv: i dont do math in nix
<bqv>
dhall on the other hand, is not
proofofkeags has quit [Remote host closed the connection]
<betawaffle>
energizer: dhall-nix is about getting information out of dhall for use in nix expressions.
<bqv>
obviously you'd still have to generate that string in nix, and you'd have to use the attrset in nix, but dhall has outsourced some computation there for you
shafox has quit [Remote host closed the connection]
<betawaffle>
energizer: you could map over a list of strings from dhall converting them to their respective packages.
meh` has joined #nixos
<betawaffle>
The whole idea of dhall is to have a single source of truth.
fabianhjr has quit [Ping timeout: 246 seconds]
<betawaffle>
And then to automate getting that information to everything that needs it.
<energizer>
except that the packages part of your configuration are specified in the other source of truth
<bqv>
it's end goal is not to be compatible with nix
<betawaffle>
It wouldn’t have to be. You’d just need some glue.
<bqv>
that's just a side benefit
<betawaffle>
energizer: think of it this way... how would you specify what packages to install from a json file?
<energizer>
so define some useful utility functions in dhall, convert them to nix and write the configuration in nix
<energizer>
betawaffle: an array. but bqv is saying that's not a good idea
zupo has joined #nixos
<bqv>
i'm saying it's pointless
<cransom>
using dhall to give me a list of packages to install seems like it would be analogous to having something like vault or a secret store telling me which packages to install. it's just not quite the right layer for it
<betawaffle>
An array of strings, right. The point is, you could do the same with dhall, if you needed to. You just don’t get all the functionality of nix.
<betawaffle>
cransom: it could make sense if you’ve got an existing central user database in dhall, and users can specify some packages they want preinstalled in their profile.
cole-h has quit [Client Quit]
<bqv>
it makes sense to think of it as dhall's output is glorified json. nix's output is ...well i don't even know, json values with side-effects? and dhall and nix can only interop using that json similarity layer
<bqv>
you *could* also write your nixos configuration in json
<betawaffle>
Not terribly useful, unless the dhall is preexisting.
<bqv>
but nobody does that
<bqv>
because again, it's a bit dumb
clever has joined #nixos
clever has quit [Changing host]
clever has joined #nixos
<simpson>
Nix has repeated interactions with the filesystem, and those interactions are basically transactional.
<energizer>
bqv: it's dumb because you can't refer to nixpkgs?
<bqv>
no it's dumb because you're trying to use data as code
<{^_^}>
[nixpkgs] @wamserma opened pull request #88629 → gen-oath-safe: add dependency on file command → https://git.io/Jf2d8
knupfer has quit [Remote host closed the connection]
<das_j>
oof, has anyone managed to evaluate a minimal system with flakes? I dropped everything except the flake.nix and some basic configuation.nix, but fetchpypi from nixpkgs gets called with the wrong fetchurl :/
<{^_^}>
[nixpkgs] @veprbl pushed commit from @r-ryantm to master « fastjet: 3.3.3 -> 3.3.4 »: https://git.io/Jf2dF
<emily>
das_j: why are you setting pkgs like that?
<emily>
I guess because your non-minimal example has more overrides?
proofofkeags has joined #nixos
<emily>
I'm pretty sure if you just remove the pkgs and that additional module it'd work fine
fendor_ has joined #nixos
<das_j>
emily: Yes, for overlays in the future. However, dropping pkgs (in nixosSystem) and the nixpkgs.pkgs module doesn't help
<emily>
oh
<emily>
das_j: no need for the .config.system.build.toplevel
<emily>
nixosConfiguration.<host> should be a nixosSystem { ... } call directly
<{^_^}>
[nixos-homepage] @davidak pushed to footer « Add links to footer and improve style »: https://git.io/Jf2dA
cole-h has quit [Client Quit]
<das_j>
emily: I'm building using nix eval (instead of nixos-rebuild). removing config.system.build.toplevel causes pkgs to be fully evaluated (it seems) which results in broken packages failing to eval
<emily>
I do e.g. ~/etc#nixosConfigurations.renko.config.system.build.toplevel when I want to build from nix(1)
fendor has quit [Ping timeout: 256 seconds]
<emily>
it might not actually be the problem here though, just pointing out it's not the format the nixos stuff expects
<das_j>
this is awesome, maybe that's the little thing I was missing for our deployment rewrite :)
<das_j>
thanks emily++ and clever++
<{^_^}>
clever's karma got increased to 432
<{^_^}>
emily's karma got decreased to 27
<{^_^}>
Wait no, it got *increased* to 29
<das_j>
what?
<emily>
infinisil had way too much fun with {^_^} :p
<das_j>
oh i see :D
<emily>
das_j: fwiw I would suggest trying to avoid importing nixpkgs like 4+ times (I think nixosSystem inherently does it again?), but it's kind of hard to avoid with flakes...
* infinisil
should turn down the frequency a bit
<emily>
I think the fact that flakes need overlays to compose well, but overlays don't integrate with flakes and require importing nixpkgs N times, kind of sucks
<das_j>
emily: Yes, I think two times (once for lib.evalSystem and once for pkgs with overlays) is the minimum amount right now
<anderson_>
Hello, people! Another concern here. TDE installer is trying to create /etc/dbus/system.d . Is there a way to circumvent it?
<emily>
anderson_: probably patch the install script
<emily>
das_j: right now I set nixpkgs.overlays = inputs.self.overlays and re-import nixpkgs to re-export its legacyPackages, but it's kind of a mess... I'm wondering whether I should make a flake for "nixpkgs with all my overlays applied" and then just depend on that to avoid the mass duplication
<emily>
but it feels like flakes probably needs to grow some mechanism to natively handle overlays if this is going to work well...
<anderson_>
Even a cmake script?
<das_j>
I'm currently messing with { nixpkgs.path = input.nixpkgs { overlays = … }} which is the cleanest way I can think of. still not nice but a lot better
cole-h has joined #nixos
ericsagnes has quit [Ping timeout: 260 seconds]
<betawaffle>
anderson_: you can patch anything.
<emily>
anderson_: you could maybe get it to output into $out instead but it sounds like it probably just shouldn't be making this directory at all?
<emily>
most "ensure this directory exists because we need it at runtime" install script stuff mixes badly with cross-compilation, packaging, and so on
<emily>
das_j: input.nixpkgs doesn't take any arguments, does it?
<bqv>
emily: the way i see it, flakes have been designed without the current model of nixpkgs in mind; i feel nixpkgs should change to fit flakes rather than the other way around, and i think that's the current aim. in the mean time, the current hacks work well enough
<das_j>
emily: It does when using import: nixpkgs.pkgs = import inputs.unstable { system = "x86_64-linux"; };
<emily>
bqv: how would you like to see it change? afaict the only nice way to define and export packages across various systems in flakes is to define an overlay and re-export from the overlayed nixpkgs
<betawaffle>
bqv: what sort of changes do you foresee in nixpkgs?
<emily>
das_j: ah, ok, so another import still
<das_j>
yes
<anderson_>
betawaffle: that way, I think it exposes some "flaw" in the install script logic. Maybe the upstream developers would be interested on it
<{^_^}>
[nixpkgs] @badmutex opened pull request #88631 → chefdk: init chef-solo at 15.11.3 → https://git.io/Jf2FW
<{^_^}>
[nixos-homepage] @davidak pushed to footer « Add links to footer and improve style »: https://git.io/Jf2F0
gmr has joined #nixos
<bqv>
emily: nixpkgs is a monolith. if chunks of package dependencies were at the flake level, you don't have to import the entirety of nixpkgs repeatedly, you could just import your forked flake of the part you want to change, and use that
fendor_ has quit [Read error: Connection reset by peer]
<bqv>
that doesn't even necessarily mean not having nixpkgs in one tree, you could have several flake.nix files in one tree
cole-h has quit [Ping timeout: 260 seconds]
<bqv>
but at least, making more behaviour flake-native
<emily>
but even when you're overlaying a new package that isn't in nixpkgs, the best way to define it is as an overlay
<emily>
for instance, it's the only way you can export things for any platform right now
<gchristensen>
fwiw, one of the reasons for the RFC and experimental feature being implemented is exactly so people could try it and report back the problems they find
<gchristensen>
so, I am very hopeful y'all are posting your experiences :)
<emily>
mostly I'd like to have some idea of what a better system would look like before complaining ^^;
<bqv>
emily: there's also the packages attr, you could use a flake itself as an overlay if the source flake was small enough and reexport stuff with small changes
jybs_ has joined #nixos
<das_j>
Is it advisable to inherit nixpkgs packages into my config repo? This way `nix run etc#pkgs.hello` would evaluate even if I didn'T override it
<gchristensen>
you don't need to complain OR give a solution, just report the use case and awkwardness
<emily>
I feel like a decent step would be allowing flakes to take structured arguments so that the nixpkgs flake could be parameterised on overlays, maybe. but that's a big change and there might be a simpler thing
<emily>
bqv: packages attr requires you to enumerate every system upfront
<emily>
and the systems people enumerate in practice are much less than what nix(pkgs) can actually compile things for
<bqv>
i don't see how that's relevant
<emily>
das_j: I do that because it's the only way to get overlays working properly with nix shell
<emily>
das_j: because e.g. nixpkgs#... has no way of reading <nixpkgs-overlays>
<das_j>
yep, that's what I was expecting, okay :/
cr4y1 has joined #nixos
<bqv>
you're set on the idea of overlays as currently implemented. imagine that concept didn't exist, but flakes did. how would you implement a system with modified packages?
<emily>
das_j: welcome to flakes, get ready to write pkgsForSystem and forAllSystems every 5 minutes :P
<bqv>
well, see my use case, where i modify the packages, then reexport them
<emily>
bqv: it's not just about "modified packages", though, which is what I'm trying to explain
<bqv>
in that scenario, my flake is acting as a "pseudo overlay"
<emily>
also, you run into these "importing N times"/"mismatched pkgs" issues even with just nixpkgs config, never mind overlays
<bqv>
yes, which is why i'm saying this solution can't function until nixpkgs is more flake-federal
wucke13 has quit [Ping timeout: 260 seconds]
<emily>
I don't think splitting nixpkgs up really has anything to do with the issues here.
<bqv>
fair, i misread what you just wrote, what issues?
mumuluxi has quit [Ping timeout: 260 seconds]
ericsagnes has joined #nixos
<emily>
basically any kind of adjustment of nixpkgs whatsoever, whether that's config or overlays, leads to weird inconsistencies / potential mixups / slowness of reimports,
<emily>
and in practice, overlays are the only way to declare packages once and export and reuse them in a way that works across all architectures and integrates well with NixOS systems and ...
cr4y1_ has joined #nixos
<bqv>
so what you're saying is, the fact that overlays are fundamentally problematic, is the reason we should definitely keep using overlays :p
<emily>
I guess the latter is the part I haven't convinced you of, but, like, as it is overlay/overlays are the only way to export a package from a flake that isn't attached to a hardcoded system identifier.
<emily>
I didn't say we should keep using overlays.
<emily>
I was unclear, I guess. to be clearer: I think we need a solution to the problems they're solving that integrates properly with flakes.
<emily>
"just drop overlays" doesn't really solve anything
<emily>
another way of putting it: overlays are the only way of exporting packages that don't pre-bake all their dependencies
cr4y1 has quit [Ping timeout: 240 seconds]
<emily>
like, including system, gcc version, etc., we have a billion injected nixpkgs in a billion flakes and no way to consistently control the config / overlays / ... of those
orivej has quit [Ping timeout: 246 seconds]
<emily>
it seems awkward, but then I guess this kind of fractal pinning is the intent of flakes
<emily>
anyway, like I said, overlays is just one part of it; currently there is no reliable way to control nixpkgs configuration across flakes
<emily>
so you'd also have to get rid of nixpkgs configuration entirely to just avoid the problems here
orivej has joined #nixos
morgrimm has quit [Ping timeout: 260 seconds]
<bqv>
makes sense. in my theoretical world, the flake you're trying to overlay would not contain hundreds of packages and wouldn't depend on every package in existence, but only a small subset. you'd have a dependency graph somewhat like nix derivations are, so you can adjust small parts of the tree. that's a change that has to be made to nixpkgs, not flakes. but i do take the point about systems being a
<bqv>
cludgy interface, that's something that should change in flakes, not nixpkgs (though i don't really know how)
<emily>
again, nothing I said was about things that would semantically make sense to be "a patch to / fork of nixpkgs" (adding new packages, adjusting end-user nixpkgs configuration, ...)
<emily>
the problems arise even if you try and avoid doing that entirely
cr4y1_ has quit [Ping timeout: 256 seconds]
<emily>
I do think "forcing you to maintain a fork of nixpkgs just to bump some package that is used as a dependency" kind of sucks though, so I'm not sure I'd go for entirely removing overlays even if there were solutions to the non-monkey-patch-y usecases
<bqv>
i think you're misunderstanding my idea, but it sounds like i'm also misunderstanding you, so maybe i'll just give up and start drinking the wine i've been putting off
cole-h has joined #nixos
<emily>
ha, sorry :p
<emily>
at least we can agree that the status quo is not ideal
<bqv>
yeah
<emily>
I just don't quite see a concrete design that makes everything work out. you can't just remove the system from packages.<system> because it ends up tied to a nixpkgs that assumes a system (I think?)
<emily>
like the whole reason that's a thing is because nixpkgs has to evaluate itself with different system settings to even work
cole-h has quit [Ping timeout: 265 seconds]
hmpffff has joined #nixos
<das_j>
btw, is there a way to ignore inputs? for example, some of our systems use home-manager while the other ones don't. but it seems like nix will always download all inputs
<energizer>
why not just use the things you need?
<{^_^}>
[nixos-homepage] @davidak pushed to footer « Add links to footer and improve style »: https://git.io/Jf2bv
<das_j>
what? our flake.nix needs home-maanger for systemA, but not for systemB (as home-manager is not used there). however, systemB will also download the home-manager flake because it's an input of the shared flake.nix
<energizer>
i havent used flakes, does flakes want you to define configurations for multiple systems in a single flake?
mallox has quit [Quit: WeeChat 2.8]
<evanjs>
lassulus: to clarify — should nixos-generate work inside VMs in general? I’m assuming system-feature “kvm” a requirement?
<bqv>
das_j: the only way for that to work is if you have a separate flake for A and B, otherwise as flakes are implemented right now all inputs will be fetched
<das_j>
yeah, makes sense. I'll go with that
<bqv>
fwiw i don't think it's the end of the world if they are fetched, home-manager doesn't have any flake dependencies so at worst you have an extra few mb on disk, there's no evaluation cost
<bqv>
uh, misspoke, it does obviously depend on nixpkgs, but you can .follows that away
<das_j>
it kinda matters when 20.09 comes out because the flake will have both 20.03 and 20.09 (for systems which are not yet updated), but I think I can live with that ;)
<das_j>
bqv: wait what?
<bqv>
right, so if you have inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs"; in your flake, home-manager's nixpkgs input will now point to your inputs.nixpkgs flake
Cale has quit [Ping timeout: 260 seconds]
tobeportable has joined #nixos
<das_j>
ah right. maybe that's what we should to to prevent the channel mixing the flakes should avoid
<bqv>
almost certainly
<das_j>
still haven't read through the follows stuff, that's not the main priority now
<das_j>
evaluating our systems in pure mode is the first step and it's already incredibly annoying
<bqv>
pure mode is definitely incredibly annoying, yes..
<dmj`>
how do I reference a source path that is two directories higher than what I gave a derivation as the `src`
<das_j>
the host I'm currently working on evals in pure mode, but the <> syntax was really useful. Sadly, I had to add all "channels" to the args, instead of using scopedImport (clever explained how that disables all eval caching)
<das_j>
also, as I wasn't there when he replied I forgot to clever++
<bqv>
interestingly enough i was having an issue frobnicating my shell.nix so it just calls out to my flake even on systens that aren't flakes. builtins.currentSystem saves the day
smatting has joined #nixos
NeoCron has quit [Ping timeout: 260 seconds]
<das_j>
oh I just noticed you're the same person whose github repo serves as an inspiration for my flake.nix :O
<bqv>
i had a feeling it was, when i saw `inputs.unstable`
<bqv>
i wish emily would put up her repo, i'm sure it has far fewer instances of heathen logic
<emily>
I do have a repo I'm trying to migrate stuff over to :p
<das_j>
I especially love fetchPullRequestForSystem btw. Absolutely lovely
<emily>
I mostly need to properly switch to home-manager so I can stop having a bunch of messy and not-ideal-privacy-wise dotfiles checked in
<emily>
honestly though a lot of the reduced complexity is just doing less stuff, I only use the unstable channel
<bqv>
das_j: lmao i hate it, but it's a means to an end
<bqv>
emily: fair enough
<emily>
never really had the desire to mix stable and unstable, I just keep a nixpkgs tree in a state I like
<emily>
I was thinking if I separated out my nixpkgs overlays stuff into a nixpkgs flake then I could also have it export a default.nix for $NIX_PATH compatibility
<emily>
bqv: fwiw, an example of why I can't just get rid of overlays: dwarffs depends on nix via nixpkgs, but I want to override it with the nix flake
<emily>
I think it's a bit silly to say that there should be a fork of nixpkgs that shims in the nix package to always be the latest commit of nix
<emily>
otoh, arguably nix should just be separated out from nixpkgs and dwarffs should depend on it separately
<emily>
but then you run into issues where NixOS really wants to pin a consistent Nix version...
<emily>
it's true that sufficient amounts of ecosystem surgery could reduce this though
o1lo01ol1o has joined #nixos
<bqv>
it's creepy how matrix paces your messages
__monty__ has quit [Quit: leaving]
<bqv>
but yes, you basically made my response for me
<energizer>
emily: how does hm help with privacy?
<emily>
energizer: e.g. right now I have my entire dconf database checked in to git with some sensitive lines filtered out
<emily>
which is nice in some ways, but with home-manager I'd just set the specific stuff I want
<emily>
and not expose as much random system state
<energizer>
oh it's not about the fact that hm does user-specific conf, it's just that hm defines a bunch of dconf options
<emily>
yeah it's just "the way I track config right now is messy and makes it hard to be sure there's no secrets, home-manager would be more structured"
<das_j>
hm. do you have nixpkgs.config inside of your system config, or in the flake, emily and bqv?
cmk_zzz has quit [Quit: cmk_zzz]
<emily>
das_j: I set nixpkgs.config and then get annoyed when it doesn't work in the CLI
<bqv>
as in config.nixpkgs.config? yeah, i have that set in mine
<emily>
I guess I should probably set it in the flake instead
cmk_zzz has joined #nixos
<das_j>
well. for now, I set nixpkgs.pkgs = inputs.nixpkgs { overlays = ....; }; but I can already see that I have to put all nixpkgs.config.* options from all systems into my flake.nix, right?
<emily>
that's going to have to be true if you want e.g. nix shell whatever#unfree-software regardless
<emily>
since a flake can't read from any impure configuration files
<das_j>
okay, so I'll try to put most of them into the flake :/
<bqv>
it will definitely be a pain to not have things in flake.nix, not convinced it's impossible, just not ergonomic to do
orivej has quit [Read error: Connection reset by peer]
<emily>
actually, dwarffs is even weirder than I though
<emily>
it does depend on the nix flake, but then the overlay depends on final.nix anyway
<emily>
so you're just expected to arrange for nix.overlay to also be in your overlays to use the package
<emily>
(the defaultPackage does do that)
<bqv>
that doesn't surprise me, given i had to specialcase it in my flake until i had the nix flake in it too
<emily>
so the nix dependency is "pointless" (but necessary), only used to inject an overlay into what it re-exports
<bqv>
we've entered a new dimension of bugs
hmpffff has quit [Quit: nchrrrr…]
<lassulus>
evanjs: well its not a focus for me, but would be very nice to have
<emily>
I am kind of unconvinced that the thing where every flake pins a random branch of nixpkgs and all its other dependencies forever is going to scale or be good
cole-h has joined #nixos
lsix has quit [Ping timeout: 260 seconds]
<emily>
it seems at least noteworthy that I always override those for all my deps that are actual flakes
andreoss has joined #nixos
globin has quit [Changing host]
globin has joined #nixos
<bqv>
i think it's good to be explicit about these things
<bqv>
at least then you have a tested configuration to fall back on
<bqv>
if your override doesn't work
<emily>
I agree but feel like there's somewhat of a bleed between "known configuration" (flake.lock) and "declarative dependency spec" (flake.nix)
<evanjs>
lassulus: right sure more wanted to clarify how it functions/what the current limitations are at the moment
<evanjs>
In our case, it’d be generating images from a VM on eg an ESXi server, etc
<emily>
explicit is good, which is why I'm not sure that flakes being able to implicitly introduce dependencies for downstreams is a good thing. but then, it depends on whether you think flakes is something to make system deployment nicer or something to turn nix+github into crates.io/npm, I guess
<bqv>
the latter is way more profitable :p
orivej has quit [Quit: No Ping reply in 180 seconds.]
<lassulus>
evanjs: well its limited by what nixos can do, I never checked it on non-nixos so I'm not really sure about the limitations on VMs or non-nixos systems
<emily>
I would really hate the latter. I don't think even eelco wants a world where a basic NixOS system is split between 50 flakes
<{^_^}>
[nixpkgs] @adisbladis pushed 3 commits to release-20.03: https://git.io/Jf2bj
<Valodim>
monorepo 4 life
cole-h_ has joined #nixos
orivej has joined #nixos
<emily>
tbh I think this is a fundamental rift: "nix(pkgs) is good because there's a trusted consistent monorepo and you can fix your whole environment declaratively" vs. "nix(pkgs) is awesome because you can have 500 versions of everything and install whatever without worrying"
<energizer>
emily: those don't seem necessarily in conflict to me. nixpkgs tests that some versions can work together, but you can use some other set of versions if you want to test it yourself
<emily>
energizer: e.g. the latter camp wants to split nixpkgs up / reduce its scope a ton
<bqv>
emily: astonishingly in that rift i think i fit on the pro-imperative side, despite the fact that i avoid imperative management like the plague
<emily>
(eelco has said this is one of his motivations for flakes)
<emily>
the former camp really doesn't want balkanization of the core system (though might accept some reduction in nixpkgs scope, certainly)
jco has quit [Quit: WeeChat 2.7]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos
<bqv>
most people here i've seen have been in the former camp
<simpson>
emily: I'm not sure I understand this split, TBH. To me, nixpkgs is a *ports tree*, and ports trees inherently can contain all of these ideas, and it's kind of the point to be able to do many heterogenous things while relying on the homoousious nature of everything fitting together.
<emily>
I mean if you're going to have a separate overlay repo it makes sense for it to be a flake
evils has quit [Quit: Lost terminal]
evils has joined #nixos
<energizer>
what's the reason for emacs-overlay to be a separate repo?
<emily>
simpson: I think I probably just summarized the camps badly, and perhaps it's arguable whether "in favour of imperative package management / juggling N random not-declaratively-specified versions of nixpkgs" correlates with "wants to split up nixpkgs"
<adisbladis>
energizer: Code churn
<bqv>
yes but he was against flakes in general iirc
<energizer>
bqv: yeah OP got the tone wrong, but the discussion is good
<aleph->
Hey ho. I'll go dive my storage in a few
<evils>
thanks
<bqv>
ooh FRidh is in the latter camp
<colemickens>
the needing to (sometimes) set ulimit to avoid "inf recursion" thing in nix is pretty painful
<bqv>
what
<bqv>
presumably to raise limits? or to lower them? i've never experienced
goodwill has joined #nixos
<adisbladis>
I've been a contributor to a distribution before that was split up like some are suggesting we do with flakes
<adisbladis>
It was a horrid mess
<adisbladis>
Never again
<ma27[m]>
colemickens: just curious since this never happened to me (yet) - when did that happen? :)
alp has quit [Ping timeout: 260 seconds]
<bqv>
adisbladis: i think that sentiment even without context is slightly problematic. I read it as "We screwed up once, let's never try and improve again, the status quo might be poor but it works"
<colemickens>
It first happened after a `git gc` months ago. Went away. Came back yesterday, no idea why. Has to do with how much stuff? is in git?
<adisbladis>
bqv: It makes testing practically impossible, and fixing fallout of your change super hard.
<adisbladis>
Let's say I bump glibc or whatever and that breaks python
<colemickens>
now I run `ulimit -s 100000` when it happens, then my invocation.
<adisbladis>
Python now being in a separate repository means there is now cross-repo syncronisation
<ma27[m]>
Another benefit of a monorepo like nixpkgs is IMHO that you're able to search for whatever you need to know in a single repo.
<MichaelRaskin>
bqv: well, after migration from SVN to git NixOS and Nixpkgs managed to turn out to be separate repositories…
<adisbladis>
And the fix may well break on older glibc
<energizer>
seems like the problems that come from centralization (large repo, etc) are relatively soluble problems
<adisbladis>
Making cross-sync _super_ tricky
<adisbladis>
I'm not even sure I consider huge repo much of a problem tbh
<emily>
nixpkgs isn't even very big as big repos go
<emily>
and you usually don't download the whole git history when you're not doing development
<energizer>
git's been getting a lot of features for making big repos manageable lately
<ma27[m]>
as I'm probably the last contributor who worked on a glibc bump I fully agree with adisbladis here :p
<bqv>
adisbladis: i think that problem isn't one that should be a permanent roadblock, it just needs thought
<emily>
there are better reasons for splitting up than repo size
<adisbladis>
ma27[m]: I've done this before, rather you than me :P
hooo has quit [Quit: Connection closed for inactivity]
<adisbladis>
ma27[m]++
<{^_^}>
ma27[m]'s karma got increased to 17.000000000000007
<{^_^}>
#42379 (by erictapen, 1 year ago, closed): stack overflow (possible infinite recursion) depending on type of git checkout
<MichaelRaskin>
We need better access management
<energizer>
emily: what do you have in mind?
<emily>
personally I think splitting some leaf packaegs out into flakes makes sense but I'd hate to see a move away from a monorepo model for libraries / build dependencies
<pjt_014>
ma27[m]: how'd you get fractional karma?
<MichaelRaskin>
pjt_014: it's random chance, and only formatting
<bqv>
some people have scientific karma
<ma27[m]>
I have absolutely no idea %)
<bqv>
pretty sure i saw someone with imaginary karma
<MichaelRaskin>
Internally karma is still integer
<bqv>
or maybe i was just very very tired
<pjt_014>
huh. sounds like floating point fsckery
<MichaelRaskin>
Nope, just a bit of trolling
<adisbladis>
pjt_014: It's just shenanigans
<MichaelRaskin>
The code chooses the reporting function at random
<pjt_014>
hm. also can one check one's karma?
<bqv>
pjt_014++
<{^_^}>
pjt_014's karma got increased to 4
<energizer>
emily: i use lots of "applications" as dependencies, so i dont see that distinction as being particularly significant
<pjt_014>
that feels a little cheaty
<bqv>
pjt_014--
<gchristensen>
aszlig++
<{^_^}>
aszlig's karma got increased to -666
<pjt_014>
wat
<bqv>
come again
<pjt_014>
????????? ?
<pjt_014>
hm.
<MichaelRaskin>
To get negative karma, one needs to ++ themselves
jkarni_ has joined #nixos
<pjt_014>
nice
<MichaelRaskin>
Well, this allows to decrement, but if one decrements long enough…
<ma27[m]>
can someone post a link to the source of this karma bot?
<{^_^}>
[nixpkgs] @marsam opened pull request #88634 → openldap: fix build on darwin → https://git.io/Jf2AY
<anderson_>
emily: I think it is a bit worse. It is a generated file, it doesn't exist in the unpackPhase
jgeerds_ has quit [Ping timeout: 246 seconds]
<emily>
anderson_: hm, maybe you could share your derivation?
<anderson_>
Yes, I will upload it to a pastebin now.
<ma27[m]>
btw is it a known issue that `rustc` doesn't build on `staging` (currently investigating why all the rust stuff breaks on my `glibc-2.31` branch).
o1lo01ol1o has quit [Read error: Connection reset by peer]
<MichaelRaskin>
Hmm, only the code that is reachable either from NixOS tests or from passthru.tests can be evaluated?
<bqv>
anderson_: as is traditional, your best bet is probably to fork nixpkgs and do your edits in there, because presumably your end goal is to PR this into there anyway
<bqv>
MichaelRaskin: :D
<emily>
Trinity is that KDE3 fork, right? is that like... still actively maintained at all?
<MichaelRaskin>
Once nix#3600 is finished, the overhead of NixOS tests will be pretty small…
<ldlework>
and getting error: Package ‘python2.7-caldavclientlibrary-asynk-asynkdev’ in /nix/store/lcnb1m4f4h3zm8v3b287l5sysqwh33w9-nixos-20.09pre226148.0f5ce2fac0c/nixos/pkgs/development/python-modules/caldavclientlibrary-asynk/default.nix:20 is marked as broken, refusing to evaluate.
<{^_^}>
[nixpkgs] @Ma27 closed pull request #80582 → nixos/nixpkgs: add override/merging capabilities from the module system to the `nixpkgs.config` option → https://git.io/JvBwd
<adisbladis>
If anyone wants to take over maintainership we could move the repo to nix-community
<ldlework>
It is pure nix, I was fearing it was gonna be haskel or something.
<anderson_>
adisbladis: I would love to add Org Mode support to it! *.*
ThomasStone has quit [Quit: Connection closed]
<adisbladis>
Don't hesitate to give me a ping if you're really up for maintaining a fork
<ldlework>
I have been working on a system called Blot, in Python for a few years, which is like a "programmable content pipeline" where you transform arbitrary data and then map it to templates.
<ldlework>
And it's really coming around. But I have been thinking for days "It should really be Nix"
<abathur>
hmm
<ldlework>
Styx isn't as pipeline-y, but it seems to have the arbitrary-data -> disk-targetted templates thing going on. And you can write your own stuff to make the data however you want.
<ldlework>
So it seems ultimately just as flexible.
<anderson_>
bqv: in fact it was my idea initially, but I want to test Nix overlay framework. Maintaining tde in a separated overlay allows me to be a bit more bold in experimentations and not to polluting Nixpkgs with bugs until nixpkgs-tde becomes sufficiently mature.
<abathur>
I've been daydreaming for a bit about a content-building pipeline for a edu company I'm on contract with
<bqv>
yeah, fair enough
<anderson_>
In a foreseeable future, I want TDE as first class citizen of Nixpkgs. But I prefer baby steps and "showing something that really works" first.
<abathur>
it's hard not to think it could be nix, and I've looked a little at the recursive-nix work, but some of the assets are videos and I haven't decided whether it makes sense for them to get copied into the store
<ldlework>
adisbladis: if you make me a maintainer of a Styx fork, I'll at least merge the pull request :P
<ldlework>
adisbladis: I could also go around to any other existing forks and maybe pull in anything else anyone has done in the interim
yutyo[m] has joined #nixos
<anderson_>
Yep, it would be awesome!
<anderson_>
I could put my blogs in Styx, it can be way better than the strange Org Publishing :)
<ldlework>
energizer: they could still point it somewhere else I guess
yutyo[m] has left #nixos ["User left"]
<ldlework>
what does "@args" in "{ styx, ... }@args:" mean?
morgrimm has quit [Ping timeout: 258 seconds]
<energizer>
ldlework: it's like **kwargs
<abathur>
energizer: mostly just logistics/confidence? Small company, fairly large in-house NAS serving video, limited ability to duplicate the entire set around for a build system, can't imagine convincing them to just delete the non-store copy
<adisbladis>
ldlework: It's an attrset with all passed args
<ldlework>
ah even styx?
<adisbladis>
All explicitly passed ones only
<adisbladis>
Not defaults
<adisbladis>
(sadly)
<ldlework>
what i mean is, "styx" is not part of the elipsis
<ldlework>
{ styx, ... }@args:
<ldlework>
does "styx" show up in "args"?
<adisbladis>
Yes, also styx :)
<ldlework>
gotcha
<MichaelRaskin>
_Only_ ellipsis is currently not supported. Yet (?)
<ldlework>
This issue I don't care about as much :)
<adisbladis>
I remember seeing some tool to migrate some repo including issues
justanotheruser has quit [Ping timeout: 240 seconds]
<ldlework>
adisbladis: there's only 6 issues, and 3 pull requests
<ldlework>
as a matter of agreeing to help, i'll at least do as much to get stuff moved over and pull requests merged
<ldlework>
:P
<adisbladis>
ldlework: I want to know how to do this properly for other repos too :)
<ldlework>
ah right on
morgrimm has quit [Ping timeout: 256 seconds]
yutyo[m] has joined #nixos
<anderson_>
Idlework: there is also some other repos as themes and CSS files.
dingenskirchen has quit [Remote host closed the connection]
<anderson_>
ldlework: ops, there are 10 repos in it
<yutyo[m]>
Guys, I am gonna as that again. How is it possible to do global npm installation?
<adisbladis>
yutyo[m]: It's completely counter to the Nix model, the general advice is don't do that
<anderson_>
Global NPM? Sorry,
<ldlework>
anderson_: ah you're right, probably best to automate this if possible :)
<anderson_>
yutyo[m]: "global" and "nixpkgs" are enemies :)
<abathur>
maybe the better starting point is why you want a global npm installation?
<anderson_>
You can do something as I do in emacs: install and forget.
<yutyo[m]>
<abathur "maybe the better starting point "> Its a must have guys.
<ldlework>
One thing I don't like about Styx is the template system
<abathur>
that's not an answer
<yutyo[m]>
I use NixOS since November, and it just wasted my time for 7 months.
<adisbladis>
God damn it... I really can't remember the tool I was looking at last for repo copying...
<ldlework>
Like for the layout, you get just one interpolation.
<ldlework>
what if the page should affect the main site nav, and the page content?
<abathur>
yutyo[m]: why not use any other distro + npm + Nix package manager?
<yutyo[m]>
I came here to rant about NixOS being bad. Global installations of some packages is a thing you need, especially when updating that specific package manager and runing several stuff independent from the system.
<energizer>
yutyo[m]: if you're fighting it like this, you'll end up wasting time
<adisbladis>
yutyo[m]: Your tone is not really appreciated
<yutyo[m]>
NixOS' structure based on its package manager is a big flaw, and the reason why people don't use this distro.
<yutyo[m]>
You can't even install software from their source code like a sane person. Is that a normal thing?
<colemickens>
Those of us here are mostly familiar with this "limitation" and are okay with it. I'm not sure what you're hoping to accomplish. We could help you with the original goal, but you haven't told us what you're trying to do.
<adisbladis>
yutyo[m]: If you're just here to rant, please leave. We can't have a reasonable discussion like this.
<ldlework>
I understand yutyo[m]'s frustration
<anderson_>
yutyo[m]: you can. It isn't just our way to do the things.
<yutyo[m]>
<adisbladis "yutyo: If you're just here to ra"> Sorry but I face problems for months and there weren't any type of help coming from the NixOS side.
<adisbladis>
yutyo[m]: Let's try to find some common ground.
<adisbladis>
yutyo[m]: Not with that attitude..
<ldlework>
yutyo[m]: Why do you think global installations are required?
<yutyo[m]>
The documentation is bad, and its impossible to understand how to use it.
<ldlework>
yutyo[m]: it's to even describe how nix works and what it's value propositions are, even in conversation
<adisbladis>
Let's start here, why do you think you want a global install of anything? That's counter to the Nix model.
<yutyo[m]>
<ldlework "yutyo: Why do you think global i"> Because those particular package managers work that way, that you can update it with global installation of its version and having some cli software being made for global usage.
<ldlework>
i think we're still figuring out the best way to present and document the ideas behind it and how to use it best
<adisbladis>
In fact, if you think Nix is so bad why are you using it in the first place? What was the draw?
<ldlework>
yutyo[m]: i don't quite understand what you're saying
proofofkeags has quit [Remote host closed the connection]
<anderson_>
I will stop talking my small project and try to talk with you.
<yutyo[m]>
For example, let's assume I will install vue-cli to make vue projects.
MmeQuignon has quit [Ping timeout: 260 seconds]
<ldlework>
yutyo[m]: ok
<ldlework>
you have plenty of options
<yutyo[m]>
Its impossible. The very reason vue-cli exist is to be installed globally, not locally. Otherwise its the same logic with directly installing vue.
<adyatlov>
Has anyone ever run into a problem where a wrapped executable tries to open itself and parse its ELF header... but it reads the wrap script instead of the binary
<ldlework>
you can install it into the system packages
<ldlework>
using your configuration.nix
<ldlework>
or you can use nix-env to install it imperatively
<energizer>
yutyo[m]: i agree it is difficult to use nixos simultaneously with other package managers. i decided to surrender to nix and only use its package manaegr instead of the others. that works better for me
<anderson_>
yutyo[m]: in Nix, you could do it via nix-shell. It provides a clean "sandboxed" environment.
<ldlework>
what's the problem?
<adyatlov>
Strace looks fun "read(3, "#! /nix/store/rm1hz1lybxangc8sdl"..., 2048) = 993" that should have been the ELF header
<yutyo[m]>
I am not against to installing vue and making my own structure btw, I can do that but there are stuff that are optimized to be used globally.
<ldlework>
Oh this is about using Nix with other package managers.
<yutyo[m]>
<ldlework "or you can use nix-env to instal"> nix-env just doesn't work properly, many people agree on that.
<quinn>
adyatlov: no i have not, but that is very amusing to consider.
<ldlework>
er what?
<adyatlov>
I recall something about measures being used for some packages in Nixpkgs to redirect filesystem access, ring a bell with anybody?
<ldlework>
I used Nix on OSX with Brew for many months, but ultimately decided I didn't just want a subset of my system to be super reproducable, I wanted the whole thing
<yutyo[m]>
Editing a config file only to install something is ridiculous, and even installing from source makes more sense in that manner but NixOS doesn't let that due to its file hierarchy.
<adisbladis>
adyatlov: libredirect?
<energizer>
adyatlov: buildFHSEnv?
<ldlework>
yutyo[m]: that's the whole point
<redcedar[m]>
you know, you can change where npm looks for "glabal" installs:
<redcedar[m]>
`npm config set prefix '~/.npm-global'` or some folder in your home dir
<ldlework>
yutyo[m]: declarative system configuration
<yutyo[m]>
And the nix store filesystem is read only, that you can't go and change stuff.
<ldlework>
yes, that's what reproducability is about
<adyatlov>
adisbladis: Gonna look that up, thanks!
<ldlework>
not changing stuff by hand
<yutyo[m]>
<ldlework "yutyo: declarative system config"> Why do you guys like that? Do you have a life?
<abathur>
yutyo[m]: NixOS is obviously opinionated; did you read the opinions before jumping in? :)
<adisbladis>
yutyo[m]: Let's start from the point of your use case
<abathur>
just trolling I think
<anderson_>
yutyo[m]: yes, I have a life
ebopp has quit [Remote host closed the connection]
<yutyo[m]>
Nope, I am not trolling. I am angry.
<adisbladis>
What I would recommend is a shell.nix providing nodejs where you install vue-cli as a dev dependency
<anderson_>
yutyo[m]: And it is because I have a life I like Nix.
<yutyo[m]>
<adisbladis "What I would recommend is a shel"> Dude, that is a pain in the ass.
<abathur>
did you ask for help under some other name? there's no IRC history for yutyo before today
* colemickens
is highly confused why someone would use nixos if they don't want declarative system management
<tobeportable>
yutyo[m]: you don't *have to* go all in with nix, I find it best to still run some stuff in containers and avoid the complexity where I won't get a benefit from it yet
<yutyo[m]>
Why would I do a such thing?
<adyatlov>
Confession time: I like Guix better but I need Nonfree xD
<adisbladis>
yutyo[m]: Why are you even running Nix in the first place if you find it such a pain?
<anderson_>
yutyo[m]: I don't like to waste my time compiling a kernel patch via AUR and it fucks my system just because AUR is second-class citizen.
<yutyo[m]>
I mean, dude, that is just a simple goddamnit npm package. Why is it needed to create a file for that?
<ldlework>
yutyo[m]: oh so this is 100% bad faith ok
<ldlework>
yutyo[m]: think about when you manage 5000 compute instances. you don't want engineers logging into them and manually fixing this or that. if something breaks in the future, we don't know if it's because of our main config, or what the engineer did.
<ldlework>
the better you can make the declarative configuration, the more reliably equal your compute instances will be. which means they should have the same problems, or not have the same problems, but they should all be the same
<ldlework>
you wanna fix that problem in the main config, so that all the servers benefit from the fix
<anderson_>
Nothing against Archlinux guys, they are awesome!
<yutyo[m]>
<anderson_ "yutyo: I don't like to waste my "> Dude, AUR is the king. You just go and install the package, that's it. NixOS isn't like that tho.
<quinn>
adyatlov: but it's doing it to itself??
<yutyo[m]>
Even to use nix-env you write -iA etc nıWNKC.ADNCAILUDVI
<adyatlov>
quinn: Apparently
<adisbladis>
yutyo[m]: Seriously, with that attitude please just leave
<abathur>
yutyo[m]: enjoy Arch, then
<colemickens>
yutyo: I get that you're frustrated, but you're spraying FUD everywhere.
<adisbladis>
You clearly just wanna stir up shit
<adisbladis>
You don't want to have a discussion or even technical help
<yutyo[m]>
<abathur "yutyo: enjoy Arch, then"> I enjoy it for 3 days, I am currently liberated from NixOS.
<adisbladis>
Can we collectively ignore this guy?
<anderson_>
yutyo[m]: I was a happy Arch user for three years. I know a thing or two about it
<colemickens>
yup
<adyatlov>
adisbladis: How do I do that
<Henson>
I've come from Debian and Ubuntu to NixOS, and have switched many of my servers over to NixOS. At first I found the Nix way of doing things quite frustrating, but after sticking with it and understanding the motivations and benefits, I enjoy it. I find it much easier to make my own packages for Nix than for Debian.
<yutyo[m]>
<adisbladis "Can we collectively ignore this "> Well, I have said the truth. Please consider your distro.
<adisbladis>
Ahh, /ignore yutyo[m]
<adyatlov>
Grrrr8
<Henson>
if NixOS isn't your thing, then you can use another distribution with the Nix package manager just for installing non-system packages. I do that on my friends' computers to let them use old packages that aren't in Debian or Ubuntu repositories anymore.
<abathur>
yutyo[m]: Cool. Glad you found your happy place :]
<MichaelRaskin>
If you do not have problems with global package conflicts in your setup, and you do not want to version control the setup, then you are not the target audience
<adisbladis>
Don't feed the troll
<anderson_>
yutyo[m]: it isn't "truth", it is just rant.
<tobeportable>
nix is a bit like vim, you need to grok it
<anderson_>
It is like a C++ programmer complaining about Common LISP!
<yutyo[m]>
<adisbladis "Don't feed the troll"> Well, you guys feed yourselves by praising a shitty distro. That distro is shit guys, face it and fix its problems.
<anderson_>
"Oh, why Common Lisp uses a garbage collector? Do you lispers have a life?"
<yutyo[m]>
<anderson_ ""Oh, why Common Lisp uses a garb"> At least its just a language, not an OS.
<yutyo[m]>
It doesn't affect your daily life.
<MichaelRaskin>
Erm, if you use it, it does
<anderson_>
yutyo[m]: Nix is effectively a Turing-complete language. And, well, Lisp/Scheme is used in GUIX...
<yutyo[m]>
Nix is a lang that only Nix guys use.
<yutyo[m]>
And there is no proper documentation.
<tobeportable>
proper eyes to read it
<yutyo[m]>
Literally nothing, nowhere to learn what learns how.
<anderson_>
yutyo[m]: the documentation part is a big pŕoblem, I am the first to admit it.
<MichaelRaskin>
If you are not comfortable reading the Nix manual, you are also very likely not the target audience
<tobeportable>
imagine being forced to use nixos and your only solution was asking people on irc to end your misery
<yutyo[m]>
<MichaelRaskin "If you are not comfortable readi"> Who is the target audience than?
<adyatlov>
Ninjas
mbrgm_ has joined #nixos
<yutyo[m]>
Not the end user, not the programmers, not the sysadmins... Than who remains?
<adyatlov>
NINJAS
<abathur>
yutyo[m]: Why'd you install NixOS? What did you think you were getting?
<bqv>
yutyo[m]: imagine a set of people that doesn't include you. that's the one
<MichaelRaskin>
People who do have problems with package conflicts and do want to version control their setups
KeiraT has quit [Remote host closed the connection]
<anderson_>
yutyo[m]: It is for system management in a reproducible way.
<adyatlov>
I did 15 years of Gentoo btw
qyliss has left #nixos ["Just /ignore the person already, folks, come on."]
<yutyo[m]>
<MichaelRaskin "People who do have problems with"> Is this only a package conflict problem that you couldn't handle? There are more problems at NixOSç
KeiraT has joined #nixos
<yutyo[m]>
> <@freenode_MichaelRaskin:matrix.org> People who do have problems with package conflicts and do want to version control their setups
<yutyo[m]>
* Is this only a package conflict problem that you couldn't handle? There are more problems at NixOS.
<{^_^}>
error: syntax error, unexpected '<', at (string):312:1
<yutyo[m]>
<adyatlov "I did 15 years of Gentoo btw"> That is cool, don't you miss a real GNU/Linux experience?
<quinn>
adyatlov: did you run gentoo on servers?
<adyatlov>
I like to live dangerously
<adyatlov>
quinn: Yeah, why not
<MichaelRaskin>
yutyo[m]: I do not have any problems with Nix as large as with other package managers
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm_ is now known as mbrgm
<quinn>
adyatlov: how did you do builds? i assume you didn't just build the same software for every server
<anderson_>
yutyo[m]: I can just put my /etc/nixos/configuration.nix file in a pendrive, copy it to another machine, fire nixos-rebuild switch and VOILÁ!
<adyatlov>
I don't manage that many servers so...
<anderson_>
I can do it ten times in ten machines and it will work OK ten times.
<quinn>
adyatlov: fair enough.
<adisbladis>
quinn: You can build binary packages with Gentoo
<yutyo[m]>
<anderson_ "yutyo: I can just put my /etc/ni"> Dude, is that the only reason?
<adisbladis>
I used to do that for VMs
<yutyo[m]>
Just go and do a docker image.
<adyatlov>
The thing I started to dislike most is the ever increasing difficulty of the SAT problem of dependency resolution. At some point it was longer than the actual compilation xD
<yutyo[m]>
Does it make sense to add a program to a config file to install it? And you need an Ansible-like manager to rule the server.
<quinn>
adisbladis: i know you can cause i remember reading something about it on hacker news a few years ago, but i forgot how they did it. is there a binary format you can feed portage?
<colemickens>
It's actually more strict than Ansible. It's great. I love it.
<adisbladis>
quinn: I can't remember _any_ details, this was a long, long time ago
<adyatlov>
Yep, binary tarballs are possible
<adisbladis>
It's semi-transparent
<energizer>
adyatlov: that's not really addressed by nix, nix takes resolved versions as inputs
<yutyo[m]>
<colemickens "It's actually more strict than A"> It is hard. Why would some sane people like it?
<quinn>
adisbladis: fair enough.
<MichaelRaskin>
Because it provides guarantees
<adyatlov>
energizer: I know, and that's fine :)
maddo has quit [Quit: See ya]
civodul has quit [Quit: ERC (IRC client for Emacs 26.3)]
<MichaelRaskin>
Reasoning about complicated setups is hard in any case, having some guarantees makes it simpler
<anderson_>
yutyo[m]: I am oldschool in that regard. I was from a time of expensive internet connection in my country. I used the servers of my high scool in order to not pay higher bills in my house :)
proofofkeags has joined #nixos
<colemickens>
nvim, '$isomeapp', `nixup` is barely more work than `apt-get install someapp` and comes with dozens of benefits that matter to me.
<yutyo[m]>
What guarantee? NixOS didn't even support wifi card at me. I needed to install it manually.
<MichaelRaskin>
You do not have needs where Nix is useful
<yutyo[m]>
And it doesn't have anything pre-installed, even commands like tree.ü
<yutyo[m]>
* And it doesn't have anything pre-installed, even commands like tree.
<abathur>
yutyo[m]: why did you install NixOS?
<quinn>
adyatlov: that is very cool. i did not know that.
<yutyo[m]>
<abathur "yutyo: why did you install NixOS"> A guy in my community wanted to make distro project upon that. Normally I was gonna make it upon Arch.
<anderson_>
yutyo[m]: I prefer it that way. I prefer to document everything in my Linux installation.
<yutyo[m]>
I have used that distro for 7 months and it was enough when the pc didn't recognize my mic at an online event.
<energizer>
i wonder if nix would benefit from a standardized version-compatibility specification. instead of each language having its own >=~2.3.4 syntax
<anderson_>
I tried to do it in Arch, but no success.
<multun>
yutyo[m]: nixos is currently targetted at os / system hackers. It's really nice when you have to install some software without containers on an heterogeneous set of servers. it's also super good for packaging / deploying / testing custom software end to end
<yutyo[m]>
<anderson_ "I tried to do it in Arch, but no"> Dude, Arch is literally the easiest thing if you compare it to NixOS. Even Gentoo is way easier than NixOS.
<colemickens>
I have never to configure upower twice. I've never had to configure Sway twice. I've never had to apply that weird PA patch and weird PA config for my system, every single time I reinstall. I've never had to configure anything related to any cloud, yet I can boot my exact system configuration and services in Azure/GCP/AWS in a matter of a minute or two.
<colemickens>
"Arch is easier to configure than NixOS" is something I would openly laugh at and can point at numerous examples of my nixcfg that shows that to be untrue.
<yutyo[m]>
<multun "yutyo: nixos is currently target"> I actually love hacking and tinkering, but not in a system that nothing works and there is no proper documentation.
<multun>
yutyo[m]: nixos just isn't a finished product
<anderson_>
yutyo[m]: maybe my brains are wired in a different way. I think NixOS is way easier to understand than a bunch of loosely related PKGBUILD scripts.
<yutyo[m]>
<colemickens ""Arch is easier to configure tha"> Dude, I laugh to you guys for thinking a distro where you can't install from source, do global installations and need to use strict rules to be easier than Arch, Gentoo and even Linux From Scratch.
<colemickens>
I build from source all the time. You just want to be angry instead of learn. It's really that simple.
<abathur>
yutyo[m]: we can install ~everything from source
proofofkeags has quit [Ping timeout: 256 seconds]
dhess has quit [Remote host closed the connection]
<colemickens>
I mean, literally almost every single thing in nixpkgs are source-built packages, but I don't think thats the answer they want to hear either
<anderson_>
yutyo[m]: yes! I like that strictness of NixOS!
<abathur>
yutyo[m]: sorry you had a bad experience, and even more sorry that you feel the need to vent it at others :/
dhess has joined #nixos
<samueldr>
yutyo[m]: nothing stops you from going back to whatever your preferred distro was
<anderson_>
It is like to work in a RELIABLE environment.
<abathur>
yutyo[m]: hope you have a better time on Arch. No reason to suffer for something you don't want/need or see the benefit in.
<samueldr>
if you prefer using a mutable system, where things are barely reproducible, feel free, you can even continue using nix on there for non-system tasks!
<yutyo[m]>
<abathur "yutyo: we can install ~everythin"> Well, several programs doesn't tho as NixOS doesn't support global installations, some programs like Electron (I know it exists, but you need a long command for it rather than "electron .", that I needed to add to all of my software), and a sane file hierarchy.
<Henson>
one thing that NixOS can do that others can't, which is the whole reason I use NixOS, is upgrade safety. You can do an upgrade and if there are problems, just reboot to go back to the previous state, or do a rollback. Super easy, super safe. No more failed distribution upgrades and manual package installations. No more bricked systems.
<multun>
yutyo[m]: nixos is also a very interesting alternative to maintaining infrastructure with ansible / salt / whatever
<yutyo[m]>
I couldn't work on any of my former projects when I was using NixOS.
codygman has quit [Read error: Connection reset by peer]
codygman has joined #nixos
<yutyo[m]>
The time I lost in 7 months can't be get back.
<multun>
yutyo[m]: there are very specific reasons you may have to use nixos. if you don't have any, you won't like it
<tobeportable>
just run them in docker containers and stop crying about it
<colemickens>
I had the same problem.
<colemickens>
Folks here helped me learn shell.nix.
smatting has quit [Ping timeout: 265 seconds]
<yutyo[m]>
And the entire recent NixOS discussion crumbled my community.