o1lo01ol1o has quit [Remote host closed the connection]
turona has quit [Ping timeout: 246 seconds]
Guest92090 has quit [Ping timeout: 268 seconds]
shibboleth has quit [Quit: shibboleth]
turona has joined #nixos
mexisme has quit [Ping timeout: 258 seconds]
phreedom has quit [Ping timeout: 240 seconds]
Guest92090 has joined #nixos
o1lo01ol1o has joined #nixos
<jared-w>
gchristensen: Prometheus. Nice :) Didn't know nixos had that steup
<jared-w>
setup*
vidbina_ has joined #nixos
o1lo01ol1o has quit [Ping timeout: 268 seconds]
vidbina has quit [Ping timeout: 258 seconds]
Guest92090 has quit [Ping timeout: 265 seconds]
Guest92090 has joined #nixos
cosimone has quit [Quit: Quit.]
cosimone has joined #nixos
mexisme has joined #nixos
<scheming_around>
Just ran "nix -qa emacs" and got the following warning: "warning: name collision in input Nix expressions, skipping '$HOME/.nix-defexpr/channels_root/nixpkgs'"
<jackdk>
I forgot my password on a nixos machine. I've booted a liveusb, mounted the old disk, run nixos-enter, edited configuration.nix and now my nixos-rebuild boot fails with "error: writing to file: Operation not permitted". What am I doing wrong?
<evanjs>
Welp. Somehow got the taffybar thing working -- now for cleanup.. and I wonder if there's a way to get it to not need a config in $XDG_CONFIG/taffybar/...
selfsymmetric-mu has joined #nixos
<evanjs>
It's basically the same thing as xmonad's config option
drakonis has joined #nixos
<jackdk>
ah, I needed to pass --option sandbox false
tilcreator has joined #nixos
gxt has quit [Ping timeout: 240 seconds]
<scheming_around>
What exactly is nix-darwin?
gxt has joined #nixos
<infinisil>
scheming_around: Did you read the readme?
<scheming_around>
I did, all it says is "Nix modules for darwin, /etc/nixos/configuration.nix for macOS."
Guest92090 has quit [Ping timeout: 260 seconds]
mexisme has quit [Ping timeout: 268 seconds]
<infinisil>
scheming_around: It lets you configure macOS with a declarative Nix config, things like daemons, config files and installed packages
fpletz has joined #nixos
<{^_^}>
[nixpkgs] @aanderse opened pull request #77158 → nixos/mysql: restart systemd service on abort → https://git.io/JejH6
fpletz has joined #nixos
fpletz has quit [Changing host]
mexisme has joined #nixos
nckx has quit [Remote host closed the connection]
<ldlework>
How do I add a native library to a Python install so when it tries to compile a given native extension the dependency is found?
<evanjs>
ahhh this is what infinisil mentioned with runtime compilation (for taffybar). I don't like ittttttt. now, how do I get it to function like xmonad does...
<evanjs>
xmonad has some patches to modify where it checks for ghc but I don't see anything like such that can be changed in taffybar
alex`` has joined #nixos
wildtrees has quit [Quit: Leaving]
judson has quit [Ping timeout: 240 seconds]
dansho has joined #nixos
<{^_^}>
[nixpkgs] @peti pushed to haskell-updates « hackage-packages.nix: automatic Haskell package set update »: https://git.io/JejQL
mexisme has quit [Ping timeout: 260 seconds]
alex`` has quit [Ping timeout: 258 seconds]
mexisme has joined #nixos
ddellacosta has joined #nixos
<jared-w>
gchristensen: aww yeeea, nerd stats. Those look /awesome/
<jared-w>
Is the setup for Prometheus and Grafana available anywhere so I can filch it for our personal setup?
<Netsu>
Hey, buddies! What is the best known way to configure EMACS to use nix-shell as development environment for "sandboxed" projects? E.g. I wish to use OCaml, Haskell and Coq. Ideally it should be common language-independent way
<DigitalKiwi>
direnv/lorri
<Netsu>
There's suggestion to use direnv. But it looks weak (direnv emulate the environment just partially and not purely). Other tried approaches seems even more fragile/hard to maintain.
<gchristensen>
I think aszlig has something for that
pbb has quit [Ping timeout: 260 seconds]
mexisme has quit [Ping timeout: 240 seconds]
<Netsu>
well, I have default.nix for pure dependencies and shell.nix for simple toolchain (with git as well). But editor is too havy to put it there, I would prefer have it on client side, separately. But it would be okay to install lsp-ide-server in the nix-shell
<aszlig>
but that one is quite old, i'd rather use .drvPath instead
mexisme has joined #nixos
jluttine has joined #nixos
<Netsu>
how lazy dependencies supposed to work?
<aszlig>
otoh, .drvPath would still have the issue that you're fetching the closure of the .drv
h0m1 has quit [Ping timeout: 260 seconds]
<gchristensen>
Netsu: it is a hack that we shouldn't be talking about probably :P
<aszlig>
Netsu: i'm building all my machines with hydra, so the corresponding store paths are known during hydra build time
pbb has quit [Quit: No Ping reply in 180 seconds.]
h0m1 has joined #nixos
<jared-w>
gchristensen: well, "knowing" prometheus might be a bit of a stretch. I've squinted at it before at least, but I'll definitely be learning it a lot more over the next few months
<inferencerules>
it seems like it's possible (maybe this is exactly the intended use) to declaratively manage system-wide package set modifications like nix-channels does, using the overlays system; if that's indeed the case, can anyone point me to an example of a configuration.nix where this is done with multiple overlays?
<inferencerules>
specifically, i'm trying to move nixos-hardware, home-manager, and NUR out of nix-channels and into a config file. official docs don't make it perfectly clear how to accomplish this, and there are no types to guide with errors
<{^_^}>
[nixpkgs] @fpletz pushed commit from @r-ryantm to master « mpd: 0.21.17 -> 0.21.18 »: https://git.io/JejdP
mexisme has joined #nixos
justanotheruser has quit [Ping timeout: 265 seconds]
<inferencerules>
ryantm: my question may not be well-formed. I have several variables of the form `var = import (builtins.fetchTarball "some.uri") { inherit pkgs; }` that would normally go individually into nixpkgs.config.packageOverrides = pkgs: { stuff here }. I couldn't figure out how to compose them to pull multiple of these in, and a reddit post suggested that packageOverrides is semi-deprecated now anyway, so
<inferencerules>
I thought I might accomplish this with overlays.
<inferencerules>
previously I had the tarballs as nix-channels, and then added them to my imports list in configuration.nix by <channel-name>, but I want to avoid using nix-channel if possible
<notgne2>
inferencerules: I think you can just add config to the arguments for your channel import
<inferencerules>
or, if it's possible to specify the channels themselves declaratively, that would also work
<ryantm>
inferencerules: I'm still feeling like you are asking something too general without knowing the exact words to say, can we maybe focus on a specific example?
<ptrcmd>
How should I patch firefox?
<ryantm>
inferencerules: Are you trying to make a NixOS configuration?
<ptrcmd>
I tried overriding the firefox package with patches, but it didn't work
<ptrcmd>
it seems that the patches were just not used as a part of the derivation
<ryantm>
ptrcmd: How are you overriding it, and how did you build it?
<inferencerules>
ryantm: I definitely don't know the exact words; I have a working configuration, no problem there. When I run `nix-channel --list` I get back a list of channels I've added, including for example <nixos-hardware> from https://github.com/nixos/nixos-hardware/archive/master.tar.gz. In my configuration.nix I have an imports list containing <nixos-hardware> and the other nix-channels I've added, plus all
<inferencerules>
the other configuration files (I split my configuration.nix into several module-specific files). I want to stop doing `sudo nix-channel --add https://github.com/nixos/nixos-hardware/archive/master.tar.gz nixos-hardware` and instead define all these in my configuration.nix (or ideally in an overlays.nix that I import into configuration.nix)
<inferencerules>
Is that more clear?
<ptrcmd>
ryantm: because firefox takes a long time to build
<ptrcmd>
ryantm: and there is no sign that it's actually compiling anything
lord| has quit [Read error: Connection reset by peer]
lord| has joined #nixos
pbb has quit [Ping timeout: 252 seconds]
pbb has joined #nixos
pbb has quit [Excess Flood]
pbb has joined #nixos
mexisme has joined #nixos
pbb has quit [Client Quit]
<elvishjerricco>
With NixOps, is it possible to access the `config` of a node in a `resources....` definition? Trying to get my ec2 security group to always allow the `allowedTCPPorts` and `allowedUDPPorts` of the machine.
pbb has joined #nixos
<clever>
elvishjerricco: i dont think so
mexisme has quit [Ping timeout: 252 seconds]
selfsymmetric-mu has left #nixos ["gone to the land of dead hiccups and extinguished light bulbs"]
<elvishjerricco>
Darn, yea it doesn't look like it
<elvishjerricco>
Really wish NixOps was a little cleaner...
<zeta_0>
apparently my computer clock is set to the wrong time, how do i change it to the current time in nixos?
<etu>
zeta_0: Have you set the correct timezone?
gagbo_ has quit [Ping timeout: 268 seconds]
<srhb>
zeta_0: usually services.timesyncd.enable is true, so it will only be wrong if you have the wrong timezone, can't talk to the ntp servers or if the current system time is way off. If it's the last one, set it once manually by shutting down timesycd and using date --set
<srhb>
(You should then be able to restart timesyncd and it'll keep your clock correct.)
<{^_^}>
[nixpkgs] @anmonteiro opened pull request #77182 → ocamlPackages.lwt_ppx: use independent source from lwt → https://git.io/Jejb0
<etu>
zeta_0: timedatectl can tell you the current timezone and if you are ntp synced
<{^_^}>
[nixpkgs] @jonringer merged pull request #66234 → pythonPackages.bugwarrior: depend on jira, remove unused test deps → https://git.io/fjQEm
<{^_^}>
[nixpkgs] @jonringer pushed commit from @yurrriq to master « pythonPackages.bugwarrior: depend on jira, remove test deps »: https://git.io/Jejp7
<Tritlo>
I'm trying to install gcc_multi globally, but I can't find the attribute... only the gcc one. I'm on NixOS 19.09, but I'm trying to install it via nix-env -i (due to an issue with cachix)
Netsu has quit [Ping timeout: 260 seconds]
dansho has quit [Ping timeout: 240 seconds]
kqb has joined #nixos
kqb2 has joined #nixos
<Tritlo>
Anyone know how I can proceed?
kqb2 has quit [Client Quit]
<clever>
,libraries Tritlo
<{^_^}>
Tritlo: Don't install libraries through nix-env or systemPackages, use nix-shell instead. See https://nixos.wiki/wiki/FAQ/Libraries for details.
<clever>
same rule applies to gcc, it just wont work right if installed system-wide
FRidh has quit [Quit: Konversation terminated!]
<Tritlo>
Right, but I'm trying to make a package work thats being installed via emacs, which uses gcc :P
<adisbladis>
Tritlo: Which package?
FRidh has joined #nixos
<clever>
Tritlo: it would need to be properly packaged by nix
<Tritlo>
vterm in doom-emacs
<adisbladis>
Tritlo: Do you know we have melpa/elpa/org/whatever in nixpkgs already?
<adisbladis>
Tritlo: We have vterm packaged already
<adisbladis>
Tritlo: Compiling vterm requires more than just the correct gcc
<kqb>
My problem is I have two imports for /etc/nixos/configuration.nix which both affect partially overlapping subsets of networking.interface and I do not know how to merge them.
<clever>
kqb: the merging when you have duplicate entires, is handled by the nixos module framework, and is based on the type of the option your setting
<kqb>
How do I merge sets, where I recursively merge the sets they contain? Do I have to write a recursive function that uses the function builtins.attrNames to get the names then turn the resulting lists into attribute sets so I can intersect them and recursively merge their intersections?
<clever>
Tritlo: and this would run emacs26 instead of the default (which happens to currently be 26)
<clever>
kqb: lib.recursiveUpdate
<clever>
kqb: or if your dealing with nixos options, lib.mkMerge is better
<kqb>
clever: thank your for your quick response, I am reading up on those right now. :)
<Tritlo>
clever: so I can just use emacsWithPackages directly in my configuration.nix, or do I have to put it under something else?
<clever>
Tritlo: yeah, you can just put (emacsWithPackages (ps: [ ps.emacs-libvterm ])) into your systemPackages, and thats it
<{^_^}>
[nixpkgs] @Mic92 pushed to master « linux_5_4: also include fpu patch »: https://git.io/JveU2
<Tritlo>
clever: nice! Again... is there any way to use this without changing configuration.nix? I'm having an issue where `cachix` from unstable doesn't build, and I want to update only this part.
<eoli3n>
Is that ok to use /run/current-system/sw/bin as path for scripts ?
<ptrcmd>
Yaniel: running it in a fhs env doesn't work
<clever>
the FHS env disables setuid
<clever>
so you need a setuid thing, that runs the FHS
<Yaniel>
oh
<clever>
flip it around
<boolman>
is services.xserver.desktopManager deprecated or is it just the default setting?
<ptrcmd>
clever: thanks, will look into them
<Tritlo>
clever: that worked! Thanks a lot :)
alex`` has quit [Ping timeout: 268 seconds]
alex`` has joined #nixos
felixfoertsch has joined #nixos
smatting has joined #nixos
<ptrcmd>
clever: what do you mean when you said "you need a setuid thing that runs the FHS"?
<ptrcmd>
what is the setuid thing that you are referring to
philr has quit [Ping timeout: 265 seconds]
chagra has quit [Ping timeout: 240 seconds]
<ptrcmd>
I am not very familiar with this
cfricke has quit [Quit: WeeChat 2.7]
<duairc>
Does anyone know how to add a package to libsForQt5 in an overlay (such that libsForQt5.callPackage knows about it)? I've done stuff like this for Haskell packages but it seems that every such thing is has slightly different quirks when it comes to composing overlays
<clever>
ptrcmd: you need to use security.wrappers to run a FHS wrapper around your binary, not enter an FHS env then run a setuid copy of the binary
<clever>
ptrcmd: patching it with patchelf would also eliminate the entire need for the FHS, which makes it much much simpler
ee194350 has quit [Read error: Connection reset by peer]
ee194350 has joined #nixos
<ptrcmd>
clever: I don't think I can patch the strings with patchelf
<ptrcmd>
clever: it's not the interpreter or rpath
<{^_^}>
[nixpkgs] @curiousleo closed pull request #77198 → lorri: set version correctly → https://git.io/JejxQ
<kqb>
I am running NixOS 19.09, I have added the package wireguard to my system, but networking.wireguard.enable is said not to exist. How do I solve this?
<kqb>
How do I search for solutions to this?
magnetophon has joined #nixos
<boolman>
evils: thanks
<kqb>
The duckduckgo search "nixos networking.wireguard.enable does not exist" turns up nothing useful within the first 6 results.
<maralorn[m]>
kqb: Just in general. The existence of a config option does never depend on if you have installed a package or not.
shibboleth has joined #nixos
<kqb>
Yaniel: Thank you. That is where I got the option name from, via https://nixos.wiki/wiki/Wireguard . Now running nixos-rebuild switch complains that this option were nonexistant while quielty accepting networking.wireguard.interfaces. So I first thought my NixOS version was bad. It is 19.09. What else can I do to debug this?
<maralorn[m]>
kqb: Can you perhaps paste the error message?
<kqb>
sudo nixos-rebuild switch --upgrade
<kqb>
unpacking channels...
<kqb>
error: The option `networking.wireguard.enable' defined in `/etc/nixos/configuration.nix' does not exist.
<kqb>
building the system configuration...
<kqb>
building Nix...
<kqb>
(use '--show-trace' to show detailed location information)
<gchristensen>
`man configuration.nix` kqb
<clever>
kqb: what does `sudo nix-channel --list` report?
<clever>
kqb: perhaps you simply havent changed channels for 2 years?
<kqb>
In configuration.nix I set system.stateVersion = "19.09";
<maralorn[m]>
kqb: Why do you think, that you are on nixos 19.09?
<clever>
,stateVersion kqb
<{^_^}>
kqb: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<eoli3n>
i did my first install on a physical host : when i boot, i need to wait 1m30 on systemd hanging on DHCP client start
<kqb>
Ahhh, thank you very much. I will go read that.
hyper_ch2 has quit [Remote host closed the connection]
<maralorn[m]>
kqb: You are in for a nice bit of software updates. ;-)
<eoli3n>
strange thing is that, it reach 1min30 max waiting systemd time, and i has networking working
dm9 has quit [Quit: WeeChat 2.7]
<kqb>
What does the partial sentence "determines the NixOS release with which your system is to be compatible" from the documentation of system.stateVersion in configuration.nix mean?
<kqb>
How can it be compatible without changing a channel?
<clever>
kqb: the whole point of stateVersion, is so nixos knows what version your state came from
<clever>
kqb: for example, which postgresql you first ran
<clever>
kqb: if you change the stateVersion, it will upgrade postgresql, and then psql cant read its own database files, and everything breaks
<kqb>
clever: Where can I read up on what goes into the system state? Intuitively it seems, to things like database-contents you mentioned, which "obviously" do not go into the NixOS configuration or Nix store.
<clever>
kqb: you have to read the release nodes, or the nixpkgs source
<kqb>
clever: I think I phrased my question badly. Is it just that every bit of state that my machine tracks as its job that is not in the Nix store or NixOS modules (configuration.nix, etc.) is something I have to watch out for in general and stateVersion is there for helping me communicate to NixOS where to be careful about things it cannot see?
<clever>
kqb: mainly just state that cant be migrated automatically
bbarker has quit [Remote host closed the connection]
kenjis has joined #nixos
kqb has quit [Quit: Leaving]
Naptra has joined #nixos
dansho has joined #nixos
Mateon3 has joined #nixos
Mateon1 has quit [Ping timeout: 258 seconds]
Mateon3 is now known as Mateon1
inferencerules has joined #nixos
remirol has joined #nixos
<catern>
hey #nixos, I have an empty .drv file under /nix/store; when Nix tries to realise it, it reads it and prints an error messaqge "expected string 'Derive(['" and fails. any ideas how this could have happened? (or how to fix it)
eoli3n__ has joined #nixos
eoli3n__ has left #nixos [#nixos]
Guest92090 has quit [Read error: Connection reset by peer]
<tilpner>
catern: Which filesystem? Any sudden shutdowns recently? NixOS? RW-store shenanigans?
<tilpner>
catern: You can try to GC it away, Nix should recreate it properly next time you need it
<catern>
ext4, no sudden shutdowns (it's happened repeatedly, in fact), Nix on Debian 9, store is owned by root and using the Nix daemon
workimer has joined #nixos
lorimer has quit [Ping timeout: 260 seconds]
<tilpner>
catern: Do you regularly use Nix as root?
<ocharles>
Dang. So the "reproduce locally" thing is my best option, and to see what `.drv`s it makes
<ocharles>
Usually from my own hydra I can do `nix-copy-closure`, but that needs SSH access
<duairc>
`nix copy --from https://cache.nixos.org/ /nix/store/zg0hx3c7n1jn4wjk1a2anb0vpwj0jg7p-hspec-2.7.1.drv` would have worked were it not for Hydra not publishing drvs
<evanjs>
Anybody have an idea of how ibus-setup might be declaratively daemonized? I tried just starting ibus-daemon in a service... but it looks like ibus-setup is pretty involved...
<ocharles>
duairc: right, I think I'll have to evaluate the same expression locally
inferenc1rules has quit [Ping timeout: 265 seconds]
inferencerules has quit [Quit: leaving]
<evanjs>
Trying to see how hard it is to make the whole thing a service. I was able to configure some of the "impure" items via dconf from home-manager but the service is still blocking a full impl
<FRidh>
a bit related. I am investigating a pull-based deployment of nixos machines. Because they're not always connected (bit like laptops) configuration needs to be pulled. I could create a channel with configuration per machine, however, I would prefer to avoid fetching expressions. Instead, I prefer to download the system closure and just using switch-to-configuration. Any suggestions for publishing the systems? That is, each machine needs to have a link that
<FRidh>
points to the latest system build.
dsx has joined #nixos
inferencerules has joined #nixos
drakonis has joined #nixos
<ocharles>
FRidh: at work we do this by building machines on Hydra, and then having a systemd timer on the target machines that tries to pull the latest build and then `activate`s it
<ocharles>
so basically what you're saying I guess
<FRidh>
ocharles: right, that's what I was thinking of as well. basically a system.autoUpgrade that does not use nixos-rebuild. But how do you locate the system closure you need?
<FRidh>
ocharles: thank you, this is exactly what I need. Do you also happen to have a roll-back service that would roll-back in case certain conditions are met?
<ocharles>
We don't, no. The machines are used by humans who are able to use grub though
<ocharles>
(We do this to provide VM images for some people in the company)
<FRidh>
with integration tests I would hope we would not need it, but our machines are in the process industry in places all around th e world
<{^_^}>
[nixpkgs] @matthewbauer merged pull request #77218 → androidenv.lldb: Fix libssl not found → https://git.io/JvevF
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/JveLj
sigmundv_ has joined #nixos
inferencerules has quit [Read error: Connection reset by peer]
<earldouglas>
Has anyone had any luck setting dmenu's path in NixOS? I've tried .bash_profile, .bashrc, .profile, .xinitrc, and services.xserver.displayManager.sessionCommands
<earldouglas>
I just want dmenu to include ~/bin.
veske has quit [Quit: This computer has gone to sleep]
<earldouglas>
Interesting: it works with ~/bin, but not ~/foo/bin.
<earldouglas>
I was actually trying to get the latter to work.
jhnn has joined #nixos
<earldouglas>
~/bin seems to be included in PATH by something else -- it's not in any of my own config.
<earldouglas>
However that's being set, dmenu is picking it up.
<evanjs>
earldouglas: I know you asked about dmenu but rofi looks like it has a ton of options via home-manager. Not seeing much in terms of high-level configuration for dmenu on nixos or hm
mehlon has quit [Ping timeout: 268 seconds]
<earldouglas>
I'm not using home-manager, but maybe I ought to start.
<evanjs>
it's pretty great. Especially if you use the nixos submodule
<evanjs>
On another note, it doesn't look like rofi gives me completion for ~/bin, but I can still run commands from it just fine
<jhnn>
hey guys, i am trying to get some clojure bindings to mxnet, which requires an intermediary step of building the scala bindings of mxnet
<jhnn>
when building the scala bindings, i'm seeing this error which reads pretty opaque to me. was hoping to be graced with a debugging tip or two :)
<kahiru>
hey, maybe a stupid question. channels are per user, correct? If so, are root's channels also separate or are they the same as system's?
mbrgm_ has joined #nixos
<__monty__>
Normally they're the same.
<evanjs>
kahiru: they're also listed under it's own profile in /nix/var/nix/profiles/per-user
georges has joined #nixos
<evanjs>
e.g. /nix/var/nix/profiles/per-user/root/channels
lukash_ is now known as lukash_|away
<__monty__>
On nix-darwin the system's channels are more likely to be a user's channels though, for example.
<kahiru>
oh, ok
mbrgm has quit [Ping timeout: 268 seconds]
mbrgm_ is now known as mbrgm
<evanjs>
right, and you can further see the distinction on a NixOS system in e.g. ~/.nix-defexpr -> channels ⇒ /nix/var/nix/profiles/per-user/evanjs/channels channels_root ⇒ /nix/var/nix/profiles/per-user/root/channels
<evanjs>
Man it does get confusing sometimes x_x
<kahiru>
I guess that's why I have issues building a solid mental model for it on my own
takeda has joined #nixos
<evanjs>
It gets easier with time/usage. Definitely not something I looked at and thought "Oh well that's easy" at first
<kahiru>
I should move my primary machine to nixos so I'm having to deal with it daily
<qyliss>
Can I have a nix profile for a group?
<qyliss>
There's no /nix/var/nix/profiles/per-group :P
<{^_^}>
[nixops-hetzner] @edolstra pushed 3 commits to zfs: https://git.io/JvemC
sigmundv_ has quit [Ping timeout: 240 seconds]
civodul has quit [Quit: ERC (IRC client for Emacs 26.3)]
<Ankhers>
I am using Elm 0.18.0 in a project but seem unable to actually build it. I have it listed in my package.json file, I run yarn install and everything seems to install properly, but when I try to build it using webpack, I get an ENOENT for elm-make. Does anyone have any experience with something like this?
<Ankhers>
infinisil: That seems to be the case. Any suggestion on what I can do here?
kenjis has quit [Ping timeout: 248 seconds]
<infinisil>
Ankhers: Check with `strace -f -e trace=process -o out <the command>`, then check where the ENOENT comes from, should be near an exec syscall, then check the elf interpreter of the binary it calls with `patchelf --print-interpreter <path>`
nek0 has joined #nixos
<{^_^}>
[nixpkgs] @jonringer pushed commit from @r-ryantm to master « python37Packages.telethon: 1.10.9 -> 1.10.10 »: https://git.io/JvemS
<Ankhers>
Would anyone using elm be able to tell me how I can install 0.18.0 in a nix shell? It looks like only the most recent version is available in nixpkgs.
<duairc>
Ankhers: I don't know anything about Elm, but you could import an older version of nixpkgs in your shell.nix/
<duairc>
*?
<Ankhers>
That is the problem. I want the latest version of Elixir that the current nixpkgs provides, but I want an older version of Elm. I'm not really sure how I am supposed to deal with something like this.
<Shoubit>
Ankhers, you probably want nixpkgs pinning. You can import old revisions of nixpkgs directly using fetchFromGitHub and similar fetchers, see: https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs
<LnL>
Ankhers: not ideal but you can import nixpkgs multiple times, if it's only the compiler you need overriding the version might work
<Shoubit>
Yeah you can do something like `let oldPkgs = ...; in { buildInputs = [ oldPkgs.elmPackages.elm ]; }`
<kqb>
nix-env --query --installed --description | grep wireguard has zero lines. When I run "sudo nix-env --query --installed --description | grep wireguard" I see "Kernel module" in the descriptions of wireguard-0.0.20200105 . How do I debug this further?
<{^_^}>
[nixos-org-configurations] @edolstra pushed 2 commits to master: https://git.io/Jve3u
<notgne2>
kqb: I think that can happen if you need to reboot onto the newer kernel
<eoli3n_>
is zen kernel stable on nixos ? any user here ?
<misuzu>
is there a way to set NIX_PATH directly in code so i can do something like 'let somepath = <....>; in { imports = [ <somepath/somestuff> ] }; and then run nix-build on it without passing -I arguments?
Guest92090 has joined #nixos
drakonis2 has joined #nixos
<{^_^}>
[nixpkgs] @FRidh pushed 221 commits to staging-next: https://git.io/Jve31
<Ankhers>
Does anyone have experience running the godot engine on NixOS? It freezes my desktop when I try to run it and I'm not really sure how to go about trying to debug it.
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/Jvesn
erictapen has joined #nixos
krkini has quit [Remote host closed the connection]
<kqb>
notgne2: Thank you, rebooting solved the problem.
<tilpner>
Ankhers: Yes, works fine here (intel driver, 2d game). Do other things work well?
<kqb>
I just upgraded to 19.09. How do I debug systemd-timesyncd failing with status=238/STATE_DIRECTORY . Searching "timesyncd status=238/STATE_DIRECTORY" only turned up something about Ubuntu 12 and deleting a systemd file so it can be regenerated as a directory. In NixOS /etc/systemd is read only and nixos-rebuild switch does not seem to clean this up by itself. How can I debug this further?
<{^_^}>
[nixpkgs] @NeQuissimus opened pull request #77254 → Updates to awscli, botocore, boto3 → https://git.io/JvesD
<tilpner>
kbz: Did you "upgrade" by changing stateVersion?
<Ankhers>
tilpner: I just started using bumblebee, rebooted and everything seems to be working fine now. I'm not really sure what to say other than it didn't seem to like my intel driver?
<kqb>
I also changed the state version. It (naively) seemed to me that this particular machine did not have any "state". It is mainly for playing around with NixOS and holds some files. How does timesyncd depend on state version?
<{^_^}>
[nixpkgs] @bjornfor pushed commit from @filalex77 to master « fselect: 0.6.7 -> 0.6.8 »: https://git.io/Jves9
<tilpner>
,stateVersion kqb
<{^_^}>
kqb: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<tilpner>
There is a giant comment above it, telling you not to touch it. It was describing the version of the state (including that of timesyncd), not the version of your nixpkgs sources
cosimone_ has quit [Remote host closed the connection]
<kqb>
tilpner: I already changed the NixOS channel to 19.09 as was suggested to me previously.
<infinisil>
The fact that it looks like a nixpkgs version number needs to be fixed eventually
<kqb>
tilpner sorry
cosimone_ has joined #nixos
<kqb>
tilpner: *facepalm* thank you for pointing out Ctrl-F. I had not thought of doing a text search on the release notes. It turns out that timesyncd has trouble with stateVersion > 19.03 . I will try another ntp solution from https://nixos.wiki/wiki/NTP.
psyanticy has quit [Quit: Connection closed for inactivity]
Neo-- has quit [Ping timeout: 245 seconds]
evernite has joined #nixos
knupfer has quit [Remote host closed the connection]
<{^_^}>
#75247 (by Elyhaka, 4 weeks ago, merged): sway: refactor with a wrapper
<tilpner>
kqb: I don't think timesyncd is generally broken, just if stateVersion was changed
<eoli3n_>
i don't find that "withGAppsWrapper" in nixos options
h0m1 has quit [Quit: WeeChat 2.7]
drakonis_ has joined #nixos
<kqb>
tilpner: I suspect my last message is easy to misunderstand. Let me rephrase: The release notes mention that for timesyncd to work, stateVersion must be 19.03 or *older*. If stateVersion is newer than 19.03, say 19.09, then timesyncd will break.
h0m1 has joined #nixos
<kqb>
tilpner: Thanks again for pointing me to the release notes. I have learned of a case where I did not intuitively do a text search for interesting strings. Thank you for this insight as well.
<infinisil>
kqb: "systemd-timesyncd will no longer work if system.stateVersion is not set correctly"
<{^_^}>
[nixpkgs] @bjornfor merged pull request #76859 → uboot: add ubootBananaPim3 for Banana Pi M3 → https://git.io/JexQj
<{^_^}>
[nixpkgs] @bjornfor pushed commit from @thefloweringash to master « uboot: add ubootBananaPim3 for Banana Pi M3 »: https://git.io/JveGf
drakonis2 has quit [Ping timeout: 260 seconds]
<tilpner>
kqb: No, I still think that interpretation is wrong
drakonis1 has joined #nixos
<kqb>
tilpner: Here is the quote from the release notes: "Because of the systemd upgrade, systemd-timesyncd will no longer work if system.stateVersion is not set correctly. When upgrading from NixOS 19.03, please make sure that system.stateVersion is set to "19.03", or lower if the installation dates back to an earlier version of NixOS." OK, so maybe my understanding of system.stateVersion is still lacking. Should system.stateVersion always be set to
<kqb>
the version of NixOS that was originally installed on a given machine?
<notgne2>
kqb: pretty much
<notgne2>
it should only be modified if you are manually going to migrate all the state data to the new formats
<kqb>
Where is documentation on that? If I do a text search for "stateVersion" on https://nixos.org/nixos/manual/ I get no hits.
<tilpner>
kqb: The key here is "When upgrading from ...". It's not saying that stateVersion always needs to be <=19.03
<maralorn[m]>
kqb: The documentation for this is primarily the comment above stateVersion in the generated configuration.nix.
chloekek has quit [Ping timeout: 260 seconds]
<tilpner>
kqb: It's not an option you should need to touch, and nixos-generate-config generates 3.5 lines of comments above it
<kqb>
# This value determines the NixOS release with which your system is to be
<kqb>
# compatible, in order to avoid breaking some software such as database
<kqb>
# servers. You should change this only after NixOS release notes say you
<kqb>
# should.
<tilpner>
(Still would be nice to have docs about it, but I don't know if there are any)
<kqb>
OK, maybe I can come at this from another direction. When would the release notes say that it *should* be updated?
<kqb>
or "changed"?
<tilpner>
I don't know of a case where they said that
<maralorn[m]>
kqb: To be honest I also didn‘t understand the exact meaning of the variable for quite a while.
Neo-- has quit [Ping timeout: 258 seconds]
<maralorn[m]>
Although the comment actually says what it does, it’s not a trivial concept to understand just from that three lines.
<maralorn[m]>
Perhaps another variable name would help.
<kqb>
I profess to understand that I have no problem with never touching this variable and that it is useful to have a way of nailing down certian specifics that can *only* be handled manually and not by Nix.
<kqb>
From my point of view, the hinges crucially on what "release" and "compatible" are supposed to mean. So, what do they mean in this comment?
<chrisaw>
Does anyone know the config option to set console font as early in boot as possible?
<kqb>
And maybe "system", but I suspect this only means "bunch of hardware in a case that 'runs' this instance of NixOS'.
<maralorn[m]>
My biggest problem is with "system" in that sentence.
<maralorn[m]>
and it talks about "breaking software" but it actually breaks data/state.
<kqb>
How can we refine the comment to be easier to understand?
<infinisil>
The comment could certainly be improved :)
<infinisil>
There's the docs for the option itself too
<kqb>
What does "option" mean as a verb in the sentence "The effect is that NixOS will option defaults corresponding to the specified release..." in the option documentation?
<maralorn[m]>
choose?
<infinisil>
Or a mistake :)
<infinisil>
Maybe it should be "default options" instead of "option defaults"
<kqb>
I think it is a mistake, but I was unsure. And language seems depends on how a group of people interprets it and not just one individual.
<kqb>
Does the documentation also assume that any non-default setting comes from the administrator of this particular NixOS system?
<wacke>
hi all, trying to use nvidiaLegacy340 on my mbp7.1 (geforce 320M) with nixos 19.09, it causes kernel panic: ACPI Warning: \_SB.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20180810/nsarguments-6
<kqb>
How does an administrator find out that a newer package from a future channel cannot talk to the old PostgreSQL database, because its version is too old?
<maralorn[m]>
kqb: Well if you try to use a postgres 9.5 db with postgres 9.6 without running the upgrade script it doesn‘t work. Version changes for programs which are likely to have this problems are always prominently placed in the release notes.
<maralorn[m]>
kqb: But stateVersion is used for different purposes.
<kqb>
maralorn[m]: I think I am starting to grok the bigger picture. So is installing postgres 9.5 and postgres 9.6 ever useful? ... ever useful in a realistic scenario?
<maralorn[m]>
With e.g. postgres the database software used will either be hardcoded by the admin or it will default to the postgres which was stable at the specified stateVersion.
<maralorn[m]>
On the same machine most likely not.
<kqb>
maralorn[m]: With postgres pinned by the sateVersion, does Nix complain when I later install a package from a future channel that needs a different (default) postgres version?
<kqb>
maralorn[m]: Can it happen that I do not know in advance that I need to upgrade postgres for a future package? Or does that only happen during sloppy work?
<maralorn[m]>
(well in practice thats not completely true, I remember from my arch days that if you have e.g. a 9.4 database on your disk you need postgres 9.5 to migrate to 9.5 and the 9.6 to migrate to 9.6. So it would be useful to migrate from 9.4 to 9.6)
<kqb>
So how does nix decide whether to use the default postgres pinned by stateVersion instead of another postgres version I installed in parallel?
<kqb>
... for a given new package I install?
<notgne2>
NixOS doesn't really have so much of a notion of "installed" as you are used to, the service will use a chosen package independent of anything in nix-env or systemPackages
<maralorn[m]>
kqb: The systemd service which starts your postgres daemon always picks the postgres version specified by services.postgresql.package
<notgne2>
you can either override it, or it will be chosed based off stateVersion
<kqb>
I think I understand the store. But it seems to me that the state that is communicated to nixos through stateVersion is *not* in the nix store.
<notgne2>
stateVersion is only really read by modules which enable software to write stuff to /var
<notgne2>
which is normally just services
kapil_ has joined #nixos
<maralorn[m]>
You could of course manually put another postgresql package into your envirnoment path. So then if you use psql on the commandline it might have a problem with talking to the db if that has another version.
<tilpner>
Yes, stateVersion is a promise to the NixOS modules that the state it can't look at really was created with a nixpkgs version from that time
<notgne2>
it won't actually overlay any packages, just means the postgresql service for instance will automatically choose a version based off your stateVersion so you don't have to manually pin the version to avoid things breaking
<maralorn[m]>
(Although I don‘t know if psql 9.5 can talk to a 9.6 server.)
<infinisil>
tilpner: I'm wondering if we should make it be able to look at the state, e.g. by having nixos-rebuild first connect to the target machine to fetch the state version (which would be saved somewhere in /var/lib/nixos)
<infinisil>
Then passing that to the evaluation
<{^_^}>
[nixpkgs] @kamadorueda opened pull request #77255 → pythonPackages.dodgy: init at 0.2.1 → https://git.io/JveG6
wacke has quit [Remote host closed the connection]
<maralorn[m]>
infinisil: Sounds impure.
<kapil_>
hello i tried to install nixos but i cant install it. after installing it dont boot
<maralorn[m]>
I think I‘ll just go ahead and try a pull request against that documentation.
moredhel has quit [Ping timeout: 240 seconds]
<kqb>
kapil_: what more information can you provide us with?
<infinisil>
,dnw
<{^_^}>
Provide as much info as possible on problems. What specifically doesn't work? What command did you run? What's the error? This makes debugging easier and helps getting faster responses
<kapil_>
its a bios system. i followed manual as it is
moredhel has joined #nixos
PlayfulCuriosity has joined #nixos
<kqb>
kapil_: We are not seeing what you are seeing. Which in practice often, sadly, means we have no idea what situation you are in.
<kapil_>
ok thank you for replaying. i will retry fresh install again
wkral has joined #nixos
<kqb>
kapil_: At least no to the extent necessary to give any useful advice whatsoever.
<kqb>
*not
<kapil_>
np thanks
<kqb>
kapil_: For example: What is the output on screen that you conclude from, that the boot failed? Did it get to grub2 or stop *before* that?
<tilpner>
infinisil: I don't really like that. It trades a lot of nice things (building and testing entire systems on hydra, for one) for dubious benefit
<kapil_>
kqb: do i can use nixos on server?
<tilpner>
infinisil: We should switch to opaque integers for state versions that only ever increase. Then people won't be tempted to touch it
<infinisil>
Hm yeah
<kqb>
infinisil: I am unsure whether I understand the ramifications of such a flow of information. What would we gain from it?
<infinisil>
Also per-module state versiosn
<tilpner>
infinisil: And we absolutely could alter generate-config to readFile ./.state_version, though that's ugly too
<tilpner>
(But please no magic fetching in rebuild)
dm9 has quit [Quit: WeeChat 2.7]
<kqb>
kapil_: I use NixOS on a computer I use as a server.
<notgne2>
my personal opinion on stateVersion would be to keep it as a config property, but additionally have config properties per-module
<notgne2>
and have each module by default inherit the one for the system
<infinisil>
kqb: The advantage would be that we won't have to rely on users setting the correct stateVersion, though then it's not easily changeable either which can be problematic
<kapil_>
kqb: oh thank you so much
kenjis1 has quit [Remote host closed the connection]
<infinisil>
notgne2: I don't think it should be a global property, because it serves no purpose if each module has its own (if needed)
<kqb>
At least for me, the comment in configuration.nix was not enough to communicate, that there is seldom a *realistic* reason to touch stateVersion.
rheeseyb has joined #nixos
<infinisil>
notgne2: Also, people won't need to set stateVersion anymore unless they use a module which needs it (with per-module state version)
<kqb>
But that can also have to do with me ostesibly misunderstanding the comment.
<kapil_>
i want to install nixos on hetzner server
<kqb>
kapil_: Sadly I have very little experience with running NixOS on something other than my own hardware. I am still planning on trying it on hetzner later. But that will take at least another half a year.
<notgne2>
infinisil: that would require additional configuration per-module though, if the global property was kept it could retain the functionality of having it automatically embedded, without an infinite growing list of per-module state versions
<kqb>
kapil_: I vaguely remember that Hetzner has some kind documentation on that as well.
<kapil_>
kqb: thanks. I am using arch linux. i am planning to switch to nixos on my own computer
drakonis_ has joined #nixos
<infinisil>
notgne2: Currently only very little modules need a stateVersion, it would just be another option among the others, like `options.services.postgresql.stateVersion = mkStateVersionOption { ... }`
<kqb>
infinisil: I am also unsure whether the proliferation of stateVersion attributes is a good idea from the current standpoint.
<wkral>
Hello, maybe someone is already looking at it, but hydra is very down right now. Was waiting for a fix in the current trunk-combined build.
<notgne2>
infinisil: users would then either have to set it when the module is enabled, or have the "default" state version be impurely defined somewhere
<{^_^}>
#77152 (by grahamc, 20 hours ago, open): 🏗️ ⚠️ Hydra database maintenance will stop builds on 2020-01-07.
<infinisil>
kqb: kapil_: Another problem with the global stateVersion is that you can't just update the stateVersion for one module, you have to do them all at once, whereas with modular ones you can do it for each service separately
<wkral>
Ahh thanks.
<kqb>
kapil_: I am currently only running it on a server and not my laptop, because I am not yet proficient enough yet to just install some "random" binaries from the web (or package them myself) because I currently do not have the opportunity to just focus on NixOS. So for me that was important to consider *before* switching to NixOS on my personal machine.
<infinisil>
notgne2: Yeah they'd have to set it when enabled
<infinisil>
It's a mild inconvenience for what it gets you
<notgne2>
I don't think it's that bad of a cost, but imo it's more for users to worry about unnecesarily when it could be avoided by having a global stateVersion that the per-module stateVersions can default to
<kqb>
How many packages / modules are currently affected by stateVersion? How can I query this information?
<kapil_>
kqb: thank you so much....
<infinisil>
notgne2: There's no reasonable default though
drakonis1 has quit [Ping timeout: 265 seconds]
<notgne2>
infinisil: the reasonable default would be the version of the system when it was installed, and setting that has already been solved by the config generator
<kqb>
infinisil: notgne2: how about the following: Adding a more explicit "do *not* touch" notice to the comment in configuration.nix ?
<simpson>
kapil_: For your second question, there's a section in the nixops manual for Hetzner: https://nixos.org/nixops/manual/#idm140737322418000 For your first question, indeed you'll have to provide details if you want help debugging.
<infinisil>
notgne2: Hm actually there's a problem with this: If modular state versions for foo and bar take shapes 0, 1, 2, ..., then defaulting to a global one doesn't make any sense
mexisme has joined #nixos
<kqb>
\afk
<kqb>
Hmm, does this not work here?
<kapil_>
simpson: oh thanks
<infinisil>
kqb: Feel free to open a PR for a better comment :)
<__monty__>
kqb: Backslash is wrong. But it's often frowned upon in irc communities. Because it unnecessarily spams everyone with your status.
<kqb>
__monty__: I see how that can happen and annoy people. What is a better way to communicate that I am sadly not going to be part of the conversation I am having for a while?
<notgne2>
infinisil: that could still be derived in some way from the nixos version global stateversion
<qyliss>
/away
<kqb>
qyliss: thank you
<__monty__>
kqb: Simply saying "afk" is fine : )
<__monty__>
Anything that changes your status is worse imo. Many people ignore statuses because it's usually spam.
<kapil_>
oh so much work is done on this os!!
<infinisil>
notgne2: Scenario: The default stateVersion for foo is 0 and for bar it's 1, what should the global default be? Now foo gets changed twice, its default stateVersion should now be 2, while bar's is still 1, what should the global default be now?
<jperras>
thanks, infinisil - the error message wasn't very forthcoming on details
<kapil_>
is this os is a rolling release?
<notgne2>
the current global stateVersion is turned into package versions, it could just as easily be turned into module specific stateVersions, something like `if config.stateVersion == "19.03" then 3 else 5` inside the module itself
<infinisil>
notgne2: I guess you could have a mapping, global state version 0 -> { foo: 0, bar: 1 }, global state version 1 -> { foo: 2, bar: 1}
<kqb>
infinisil: I have no problem with doing the work and providing a diff. The implementation snag is that I currently do not have a github account. The last patch somebody wanted, I sent by email.
<__monty__>
kapil_: Though most people track a stable channel.
<infinisil>
kqb: Why not create one? Will be much easier to contribuet
<notgne2>
A global mapping might actually be better too as it would be easier to coordinate software cross compatibility
<infinisil>
notgne2: Can't rely on it though, people can still set per-module stateVersions themselves
erictapen has quit [Quit: leaving]
erictapen has joined #nixos
<infinisil>
notgne2: But yeah if an incompatibility is found, it could be an assertion doing `if bar is enabled, foo's stateVersion needs to be > 1`
<maralorn[m]>
kqb: infinisil I am working right now on a PR to improve that comment. I had the same troubles as kqb at the beginning.
<kqb>
infinisil: I have yet to find a short way to summarize my thoughts on this. I have the illusion that I gave it a lot of thought.
<kapil_>
__monty__: thanks
philr has joined #nixos
<infinisil>
maralorn[m]: Nice!
<infinisil>
notgne2: After some more thinking I think this falling back to the global state version as a default might work nicely
<kqb>
Here is what I propose for the configuration.nix file:
<maralorn[m]>
The problem with a non global stateVersion is (I guess) that a module might not know in advance that it will later need a stateVersion. So then at the point where they introduce one they need it to default to the old state for it to make any sense.
<kqb>
# This value determines the NixOS release with which your system is to be
<infinisil>
maralorn[m]: When it needs it, the option is made mandatory
<kqb>
# compatible, in order to avoid breaking some software such as database
<{^_^}>
[nixpkgs] @bcdarwin opened pull request #77275 → python3Packages.pycm: init at 2.5 → https://git.io/JveZZ
<kqb>
stateVersion is a promise to the NixOS modules that the state it can't look at really was created with a nixpkgs version from that time
<kqb>
<notgne2> it won't actually overlay any packages, just means the postgresql service for instance will automatically choose a version based off your stateVersion so you don't have to manually pin the version to avoid things breaking
<kqb>
Liberally quoting tilpner and notgne2 :
<kqb>
description = ''
<kqb>
data. For instance, if the default version of PostgreSQL
<kqb>
configuration defaults in a way incompatible with stateful
<kqb>
Every once in a while, a new NixOS release may change
<kqb>
changes, the new version will probably be unable to read your
<kqb>
existing databases. To prevent such breakage, you can set the
<kqb>
value of this option to the NixOS release with which you want
<kqb>
to be compatible. The effect is that NixOS will option
<kqb>
defaults corresponding to the specified release (such as using
<kqb>
an older version of PostgreSQL).
<kqb>
The attribute stateVersion is a promise to the NixOS modules
<kqb>
that the state it can't look at really was created with a
<kqb>
nixpkgs version from that time. It won't actually overlay any
<kqb>
packages, e.g. for the postgresql service it will automatically
evernite has quit [Quit: Lost terminal]
Synthetica has quit [Quit: Connection closed for inactivity]
<kqb>
choose a version based off your stateVersion so you don't have
<kqb>
to manually pin the version to avoid things breaking.
<kqb>
yorick has quit [Ping timeout: 246 seconds]
<kqb>
'';
<kqb>
I think I should start using pastebin or something similar.
<qyliss>
we also have https://discourse.nixos.org/c/dev/patches/19 if you don't have a GH account, but it's very fiddly to use because of Discourse. We're working on making it better.
<{^_^}>
[nixpkgs] @edef1c opened pull request #77276 → git-series: update the `url` crate for compiler compatibility → https://git.io/JveZR
<kqb>
I am in favor of most of https://termbin.com/dpj7w . From a newcomers perspective I am still unsure how to naively find the option documentation. Searching for "option" on nixos.org/nixos/manual turns up something in the nav ribbon referring to "Options" and "24.3. Options" where "24. PostreSQL". I am unsure how to communicate better what option documentation is supposed to be.
kenjis has quit [Remote host closed the connection]
<maralorn[m]>
kqb: I am trying really hard to keep it short. The easiest way would be the link. But the recommended way would probably be "man configuration.nix".
<maralorn[m]>
Not sure what to include.
<kqb>
I think https://termbin.com/tggg sounds good. I am still unsure about the discoverability of the option documentation for newcomers. (Just finding out it exists and where it is.)
<{^_^}>
[nixpkgs] @edef1c opened pull request #77277 → google-cloud-sdk: include openssl(1) in PATH → https://git.io/JveZi
<kqb>
maralorn[m]: On my system where I just switched the channel and ran ... --upgrade , I could not find "stateVersion" in man configuration.nix . I was also unaware up to now that the information from the man pages was called the option documentation.
<maralorn[m]>
kqb: Weird. It is in my man configuration.nix.
<maralorn[m]>
I think it would be marvelous to have a tool which could tell you which values in the configuration of a specific system are affected by a set stateVersion.
drakonis1 has quit [Client Quit]
<kqb>
So $ man -K 'appstream' seems to have found configuration.nix . Running $ man -K 'stateVersion' found a useful configuration.nix man page. Side note: there are also hints at services.radicale.package or services.redmine.package exhibiting different behaviour depending system.stateVerion; just to have two concrete examples.
drakonis_ has quit [Ping timeout: 248 seconds]
<kqb>
maralorn[m]: How does this not run into the halting problem?
<kapil_>
Can I run my own c ++ software?
<kqb>
maralorn[m]: There are instances in configuration.nix where this is mentioned in the documentation.
<infinisil>
kapil_: Of course
<kapil_>
Thanks
<infinisil>
No idea why you wouldn't be able to
<maralorn[m]>
kqb: Well the dumbest way would be to build the system twice once with and without the variable and look at the difference. I see no halting problem there.^^
<kapil_>
I want to install qt creator ,how should I install it?
<infinisil>
maralorn[m]: Won't work, there won't be a difference unless the relevant modules are enabled
<infinisil>
kqb: I'm trying to only give as elaborate answers as the questions are :P
<maralorn[m]>
infinisil: Which is exactly my point. It would be very easy to find all mentions of stateVersion in nixpkgs. But I want explicitly all the places where my specific system is affected by it.
<kapil_>
Thanks
<simpson>
kapil_: Doesn't the `qtcreator` name work? I haven't used it myself in years.
<infinisil>
maralorn[m]: Oh I see
<kapil_>
But how-to install qt creator?
<maralorn[m]>
If would kind of be a checklist of what I need to migrate if I want to bump the stateVersion.
<maralorn[m]>
kapil_: qtcreator is packaged for nixos.
<kapil_>
Thanks
<maralorn[m]>
kapil_: You can install it like any other package.
<infinisil>
maralorn[m]: In my vision, stateVersion can be automatically migrated. E.g. where each version bump for each module includes a script to run
<kqb>
infinisil: I also am in favor of doing that in most cases. In the beginning if a newcomer is willing, I am willing to extend a little more help. If it turns out they start looking for documentation themselves, all is well. Otherwise ..., well learning for oneself seems important in this case.
<infinisil>
maralorn[m]: So it would look e.g. like this: `options.services.postgresql.stateVersion = mkStateVersion { versions = { "1" = ''${pkgs.postgresql}/bin/psql UPDATE blabla''; "2" = ...; }; }`
<infinisil>
Or at least allow the user to somehow run these migration scripts on-demand (automatic might not be possible)
<infinisil>
Yeah it involves setting pythonPath in the derivation attributes and adding wrapPython to nativeBuildInputs
<infinisil>
Yeah it involves setting pythonPath in the derivation attributes and adding wrapPython to nativeBuildInputs
<infinisil>
Then calling wrapPythonPrograms yeah
<infinisil>
bgamari: So runCommand with a `mkdir`, `cp` and `wrapPythonPrograms` will probably work
Guest92090 has quit [Ping timeout: 258 seconds]
<bgamari>
hmm
<vaibhavsagar>
I've never tried this, but it looks like this is what fast-downward does if you look at the expression in nixpkgs
joshuagl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<infinisil>
bgamari: Alternatively if you have the script as a nix string you can use `passAsFile = [ "script" ]; script = ''foo bar'';` then use $scriptPath as the path where the script is
<jared-w>
doing pretty good! My life has been pretty crazy the last year or two and a lot has happened lol; I should get back into the ghc dev irc channel at some point but free time is getting harder to find...
<infinisil>
Btw there's #nixos-chat for offtopic convos :)
<bgamari>
ahh, congratulations!
<bgamari>
infinisil, thanks, moving
<jared-w>
simpson: it's a lot of fun! Definitely interesting for me. (I'll move further replies to -chat)
cosimone_ has quit [Quit: Quit.]
Serus has quit [Ping timeout: 260 seconds]
<jared-w>
bgamari: on-topicly, I usually use runCommand as well. The "wrap" script is basically a convenience wrapper around runCommand and adds a few niceties
<bgamari>
right
* bgamari
is for some reason finding that the gobject-introspection setup hook isn't being run
<jared-w>
bgamari: is the gobject-introspection hook for the ghc testsuite?
<bgamari>
nope
<bgamari>
this is for my own desktop environment
gustavderdrache has quit [Quit: Leaving.]
jlv has joined #nixos
<jlv>
Is there an easy way to run another phase in `shellHook`. I tried `eval $configurePhase` like I would do in the shell itself, but that doesn't seem to work.
<jared-w>
jlv: Pretty sure you can just write 'configurePhase' and it'll work.
<jlv>
jared-w: it says "no configure script", but there is a `configurePhase`.
growpotkin has joined #nixos
<jlv>
I can sucessfully run `eval $configurePhase` in a `nix-shell`, so I know it works.
Jackneill has joined #nixos
vld has quit [Ping timeout: 268 seconds]
Serus has joined #nixos
mattwoodyard has joined #nixos
<jared-w>
hmm, while looking for a better answer to jlv, I remembered this page. bgamari, have you seen this? https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats it mentions "wrapping simple python scripts" in there
<mattwoodyard>
is this a good place to ask about nixops?
<jared-w>
sure
<jared-w>
jlv: what does $phases look like in you rshell?
<bgamari>
ahh
<bgamari>
jared-w, indeed that will do
<mattwoodyard>
i have a config using aws and when i nixops destroy -d deploy machinename it hands the elastic ip back - is there away to keep the elastic ip 'stable'?
<bgamari>
I had forgotten about being able to just override unpackPhase
<jared-w>
bgamari: I forget about that too lol; the extent to which you can just rip something out and say "no do this" is ridiculously impressive
<jlv>
jared-w: $phases is empty in `shellHook` and `nix-shell`.
<jlv>
If it helps, I did define my own `configurePhase`.
<jlv>
The error message from `configurePhase` in `shellHook` looks like it may be trying to run the default `configurePhase` instead of the one I defined.
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos
<jared-w>
that's what I'm thinking
<jared-w>
if you echo out what configurePhase is, do you get its definition?
mehlon has quit [Remote host closed the connection]
<jlv>
`echo $configurePhase` gives the correct script, but without newlines, and running `eval $configurePhase` is results in errors consistent with the lack of newlines.
mehlon has joined #nixos
<jared-w>
try eval "$configurePhase" then :p
<jlv>
It works XD I even thought about doing that for a moment, but dismissed it because I don't need the quotes outside of `shellHook` XD
<jlv>
Do you know why the quotes are only need in `shellHook`?
kenjis has quit [Remote host closed the connection]
<jared-w>
no idea. I could conjecture, but between nix, nix string handling, and shoving things in and out of bash with its infamously complicated quoting requirements... who knows lol
<jlv>
Well, I'm just glad it works :)
kenjis has joined #nixos
philr has quit [Ping timeout: 240 seconds]
<jared-w>
(which is actually one of the things that really irks me about Nix. Great concept, but the pervasive usage of bash, make, cmake, etc., certainly makes it quirky)
<jlv>
I guess that's what happens when you make a build tool to encampass every language.
<jared-w>
# this is idempotent trust me \n pkgs.doSomeRandomBashCrap "yolo" ''rm -rf / && mv $stuffs $other/stuffs/yey'';
yl has quit [Ping timeout: 268 seconds]
<jared-w>
jlv: Nix is fine, the store is fine, the whole concept is fine. The design of nixpkgs, stdenv, modules, channels, and NIX_PATH, is... interesting to say the least. It works surprisingly well and, well, surprisingly :p
Jackneill has quit [Remote host closed the connection]
logzet has quit [Ping timeout: 245 seconds]
<noonien>
hello folks
<noonien>
is there any reason why fetchPypi is missing here? http://ix.io/26Le
zeta_0 has joined #nixos
<jlv>
jared-w: It's definitly lightyears ahead of the competion, in my opinion and experience. I recently got a friend to switch to NixOS, because their Manjaro setup failed to boot after trying to update a driver, and I explained that you can just rollback in NixOS.
mehlon has quit [Quit: Leaving]
<jared-w>
jlv: no doubt. But if I tried to explain to someone that there's a modern, cutting edge, highly declarative operating system sitting out there built out of thousands of lines of random bash, a hand rolled programming language, Perl, C++, and duct-tape, they'd probably look at me a little funny
<jared-w>
I mean, I'd look at me a little funny :p
<simpson>
It's not *that* surprising. Nobody's yet created a non-bad general-purpose programming language, so of course folks are going to feel iffy about using software written in what's available.
erictapen has quit [Ping timeout: 268 seconds]
<jlv>
jared-w: I mean, is it really that different with Linux distros? Most Linux distros are a hodgepodge of various open source projects in various languages.
<jared-w>
simpson: That's true. Especially when making build systems, and distros. The amount of janky and weird code that other package managers and distros have is just as bad (if not worse)
<jared-w>
jlv: True, but they don't promise to be a declarative solution the same way Nix does, I suppose
erictapen has joined #nixos
<jared-w>
noonien: Doesn't packageOverrides only take one argument?
<noonien>
it doesn't seem like it
<noonien>
i fixed it, fetchPypi is not in pkgs
<adisbladis>
It is, it's living in the `pythonXPackages ` namespace
mattwoodyard has quit [Remote host closed the connection]
xO1 has quit [Ping timeout: 265 seconds]
<noonien>
yup, sorry, i meant to say, not directly