<{^_^}>
→ ebcf2d34 by @Mic92: terraform-provider-libvirt: init at 0.3
<{^_^}>
[nixpkgs] @Chiiruno opened pull request #37954 → bcachefs-tools: Changed install flag from PREFIX to DESTDIR, deleted unneeded Makefile → https://git.io/vxgNC
<{^_^}>
→ 15c744a0 by @Mic92: Merge pull request #37852 from Mic92/terraform-libvirt
Lears has joined #nixos
me1 has quit [Quit: me1]
dan_b has quit [Ping timeout: 260 seconds]
me has joined #nixos
me is now known as Guest69210
spear2 has quit [Ping timeout: 264 seconds]
<{^_^}>
[nixpkgs] @fpletz opened pull request #37955 → nixos/version: fix nixops pre 1.6 compatibility → https://git.io/vxgN9
freeman42x]NixOS has joined #nixos
<mounty_>
Does anyone here have experience of Hydra? I was just beginning to integrate it into my project when someone mentioned (in a context in which I couldn't question him further) that it is incomplete.
<{^_^}>
→ d390ee74 by @ElvishJerricco: Added bionic dynamic linker
<{^_^}>
→ 785c62e8 by @Ericson2314: Merge pull request #37957 from ElvishJerricco/add-bionic-dynamic-linker
ivanivan has joined #nixos
silver has quit [Read error: Connection reset by peer]
alhariel has quit [Ping timeout: 248 seconds]
hariel has joined #nixos
<ivanivan>
I have a Bash script I'd like to install in NixOS as an executable.
<ivanivan>
The script is a thin wrapper around some GNU Stow commands.
<ivanivan>
I can write a derivation, but I'm not sure how symlink it into /run/current-system/sw/bin/
<ivanivan>
Can anyone point me in the right direction?
<ruhatch>
@ivanivan if you put the script in $out/bin in your derivation
<ivanivan>
runhatch: really? just that simple? that's great! kinda embarrassed I didn't just try that
<ruhatch>
Then add the derivation to your configuration.nix in environment.systemPackages
<ivanivan>
thanks
<ruhatch>
Should be that simple yeah!
<ivanivan>
i also wrote a bash completion script for it -- i found some examples of how to link that; looks straightforward
me1 has quit [Quit: me1]
<ruhatch>
FYI: only certain subdirectories are symlinked like this by default
<ruhatch>
You can add other paths that you want symlinked to environment.pathsToLink
<ivanivan>
ah, good to know. thanks again!
<ruhatch>
No worries!
sigmundv has joined #nixos
xcmw has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sigmundv has quit [Remote host closed the connection]
<{^_^}>
[nixpkgs] @erictapen opened pull request #37958 → apache-httpd: fix typo in config servedFiles → https://git.io/vxghW
jrolfs has quit [Ping timeout: 264 seconds]
xcmw has joined #nixos
srdqty1 has quit [Ping timeout: 256 seconds]
sigmundv has joined #nixos
sigmundv has quit [Remote host closed the connection]
srdqty1 has joined #nixos
<ivanivan>
i don't understand the distinction between buildInputs and propogatedBuildInputs
<ivanivan>
i mean, how could a package's runtime dependencies *not* propogate?
<ivanivan>
if pkg-A has a runtime dependency on pkg-B, won't any package with a runtime dependency on pkg-A necessarily have a runtime dependency on pkg-B too?
<ivanivan>
srdqty1: is that you?
<srdqty1>
depends. are you you?
<ivanivan>
i would've thought the name gave it away
xcmw has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nuncanada has quit [Read error: Connection reset by peer]
nuncanada has joined #nixos
jrolfs has joined #nixos
srdqty1 has joined #nixos
srdqty has quit [Ping timeout: 256 seconds]
<mounty_>
Does anyone here have experience of Hydra? I was just beginning to integrate it into my project when someone mentioned (in a context in which I couldn't question him further) that it is incomplete.
<mounty_>
Oh sorry; I see there are answers to my previous asking.
<mounty_>
Apparently it doesn't install properly; you have to do some extra work to fix the installation to make it work fully.
<mounty_>
I have set up a Hydra server but haven't used it seriously yet.
jrolfs has quit [Ping timeout: 240 seconds]
orivej has joined #nixos
pkill9 has quit [Ping timeout: 260 seconds]
Crypt0x has quit [Ping timeout: 256 seconds]
Crypt0x has joined #nixos
jb55 has quit [Ping timeout: 264 seconds]
srdqty1 is now known as srdqty
schoppenhauer has quit [Ping timeout: 276 seconds]
ruhatch has quit [Quit: Connection closed for inactivity]
<vaibhavsagar>
mounty_: I have also set up a personal Hydra
<vaibhavsagar>
it's currently broken because it doesn't play well with some of the newer Nix stuff
<vaibhavsagar>
btw does anyone know how close 18.03 is to being released?
<vaibhavsagar>
I'm asking because I would like it to have GHC 8.4 by default but that's looking unlikely
jrolfs has joined #nixos
pkill9 has joined #nixos
zzamboni has quit [Ping timeout: 246 seconds]
jrolfs has quit [Ping timeout: 248 seconds]
<elvishjerricco>
vaibhavsagar: I thought the default GHC was always the one used by the Stackage resolver the package set is based on. That is currently 8.2.2
<vaibhavsagar>
exactly
<vaibhavsagar>
so if we wait long enough then lts-12 will happen
<elvishjerricco>
Ah. That won't be for a while I'd guess
jrolfs has joined #nixos
<elvishjerricco>
Probably past April
<vaibhavsagar>
:'(
<vaibhavsagar>
my larger concern is that nixpkgs is doomed to have the latest-1 version of GHC as standard
<elvishjerricco>
mounty_: What specifically isn't working?
<vaibhavsagar>
because they're both on 6-month cadences
<elvishjerricco>
vaibhavsagar: There are Linux disrepair still on like 7.8 I think :P
<vaibhavsagar>
and the new LTSs always take so long to come out
<elvishjerricco>
Dostros*
<elvishjerricco>
Agh
<elvishjerricco>
Distros*
<vaibhavsagar>
elvishjerricco: we're not just any linux distro though :)
<vaibhavsagar>
and nixpkgs master will probably upgrade the day after lts-12 comes out
<vaibhavsagar>
so then there's a mismatch between release-* and unstable forever
<elvishjerricco>
Yea I think as long as we're tied to Stackage, we can expect stable nixpkgs to always be one major LTS behind, which is itself going to be one major version behind GHC half the time
<elvishjerricco>
It'd be great if we had upstream support for nightlies in nixpkgs
<vaibhavsagar>
at least the newest release has make-package-set
<elvishjerricco>
In my ideal world we'd have all the LTSes, including nightlies, paired with the latest release of some NixOS channel
nuncanada has quit [Read error: Connection reset by peer]
<vaibhavsagar>
actually no, that's been there for ages
<vaibhavsagar>
elvishjerricco: the current situation is that minus nightlies
<vaibhavsagar>
all you have to do is run a revision of nixpkgs with that package set :)
<elvishjerricco>
vaibhavsagar: Fair enough
<vaibhavsagar>
I think it even caches now, which is pretty cool
<elvishjerricco>
But being forced to use an old nixpkgs kind of sucks
<vaibhavsagar>
yes, I agree
<elvishjerricco>
Though I guess my suggestion has the same problem
<elvishjerricco>
But we can't cache every LTS with every NixOS channel update
<elvishjerricco>
That's just too much work
<vaibhavsagar>
you're right
blonkhart has quit [Quit: WeeChat 1.9.1]
<elvishjerricco>
I guess the solution is stackage2nix + every team uses their own hydra :P
<vaibhavsagar>
that is *a* solution
<elvishjerricco>
I wonder if it would be to much to have a `haskell.packages.nightly` set that's just the latest Stackage nightly
<vaibhavsagar>
IIRC nixpkgs is vehemently against multiple package sets
<vaibhavsagar>
we could have our own overlay like the Rust people do
<elvishjerricco>
I understand having one package set but I think nightlies may be exceptional enough
<elvishjerricco>
Since they should obviously be handled with care
Crypt0x has joined #nixos
jrolfs has quit [Ping timeout: 260 seconds]
Myrl-saki has joined #nixos
semilattice has quit [Ping timeout: 276 seconds]
<Myrl-saki>
How do I set max job with the new nix porcelain?
oahong has quit [Ping timeout: 265 seconds]
srdqty has quit [Ping timeout: 256 seconds]
oahong has joined #nixos
srdqty has joined #nixos
<Myrl-saki>
`nix build --option max-jobs 1`
<Myrl-saki>
I miss -j1
<Myrl-saki>
:(
zzamboni has joined #nixos
rauno has quit [Ping timeout: 276 seconds]
Rusty1_ has quit [Quit: Konversation terminated!]
vidbina has joined #nixos
liori has quit [Remote host closed the connection]
<elvishjerricco>
Myrl-saki: Hm. That's annoying. `--max-jobs 1` still works
oahong has quit [Ping timeout: 264 seconds]
coconnor has joined #nixos
oahong has joined #nixos
aramiscd has joined #nixos
robstr has joined #nixos
jrolfs has joined #nixos
Myrl-saki has quit [Remote host closed the connection]
zzamboni has quit [Ping timeout: 240 seconds]
Myrl-saki has joined #nixos
Myrl-saki has quit [Read error: Connection reset by peer]
roconnor has quit [Quit: Konversation terminated!]
vidbina has joined #nixos
<fearlessKim[m]>
when I use a simple `makeWrapper $orig $out --set XX toto` in home-manager, `I get /nix/store/b3q8ql3my0y3yyvyq06vsz09vnwa1viv-hook/nix-support/setup-hook: line 113: flagsBefore: unbound variable` that is this line
<{^_^}>
[nixpkgs] @fpletz pushed 7 commits to release-18.03: https://git.io/vx2qi
<{^_^}>
→ be798556 by @erictapen: apache-httpd: fix typo in config servedFiles
<{^_^}>
→ b65794b4 by @ryantm: telepathy-gabble: 0.18.3 -> 0.18.4
<{^_^}>
→ b0f5bc0f by @jerith666: openjdk10: minor cleanups
asuryawanshi has quit [Ping timeout: 240 seconds]
jrolfs has quit [Ping timeout: 240 seconds]
<jluttine>
is there any very simple way to wrap executables in order to modify PATH, or do i need to use mkDerivation with name, version, meta, buildInput etc although they are already defined in the package i'm wrapping...
<clever>
jluttine: if its in the same derivation, it will trigger a rebuild
<sphalerite>
jluttine: I'd suggest leaving the original package unmodified, since you don't want to rebuild it every time
<jluttine>
sphalerite: yeah. though it's a very small build, i want to learn to do it correctly, so yes, avoid unnecessary rebuilding
<jluttine>
sphalerite: ok, thanks. i'll check that runCommand
<sphalerite>
which approach is *correct* depends on the situation. If the wrapper is purpose-specific, then yes make a separate derivation using runCommand or similar. If the software doesn't function correctly without the wrapping, it should go in the original derivation
vidbina has quit [Ping timeout: 252 seconds]
Tucky has joined #nixos
<jluttine>
sphalerite: yeah, the package doesn't work without the wrapping because it needs some runtime-only dependencies. but it wouldn't need to be re-compiled if those dependencies change
oahong has quit [Ping timeout: 264 seconds]
blankhart has joined #nixos
oahong has joined #nixos
jrolfs has joined #nixos
<Myrl-saki>
How to use `nix run` to get a build env rather than the package itself?
<sphalerite>
Myrl-saki: not currently possible AFAIK
<sphalerite>
Myrl-saki: continue using nix-shell :)
<Myrl-saki>
sphalerite: Awww. :(
<Myrl-saki>
sphalerite: I miss the curl messages. ; n ;
<Myrl-saki>
Is there a way to get them back with nix-shell?
<sphalerite>
Myrl-saki: nothing neat and integrated, but you could just nix build -f shell.nix first
<Myrl-saki>
sphalerite: Thanks.
jrolfs has quit [Ping timeout: 264 seconds]
reinzelmann has joined #nixos
Myrl-saki has quit [Remote host closed the connection]
<{^_^}>
[nixpkgs] @jluttine opened pull request #37969 → diskrsync: add ssh to PATH → https://git.io/vx2mo
<jluttine>
sphalerite clever: thanks for the help. i made a pull request now
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nixos
Myrl-saki has joined #nixos
jrolfs has joined #nixos
roberth has quit [Ping timeout: 256 seconds]
kitemikaze has quit [Quit: kitemikaze]
kitemikaze has joined #nixos
Myrl-saki has quit [Remote host closed the connection]
<LnL>
note that it can take a long time depending on the size of your store
<Wizek>
LnL: How long? Can you give an estimate, e.g. 1 hour for 10GB?
<LnL>
not really
<nick_l>
I defined an overlay myoverlay config: nodes: pkgs: self: super: {foo = bar config nodes pkgs} and specified nixpkgs.overlays = [(myoverlay config nodes pkgs)]; Then in a module I refer to ${pkgs.foo}/bin/foo, but pkgs.foo doesn't exist according to Nix?
<nick_l>
Missing semi-colon is not the issue.
ottidmes has joined #nixos
<tilpner>
Wizek - It is safe to use nix-store --delete, but you shouldn't rm -rf them
<Wizek>
tilpner: alright. Though what's the problem with rm -rf?
coot has joined #nixos
<tilpner>
Nix wouldn't know that you removed something, /nix/var/nix/db would be out of sync
<nick_l>
tilpner: I specified the overlay as you said, but it doesn't seem to be picked up.
<nick_l>
I.e., "attribute
<tilpner>
nix-store --delete also only actually removes things if it's safe to do so, so it won't let you delete important files
<nick_l>
I.e., "attribute "foo" missing, at <location> (which is ${pkgs.foo}/bin/foo)
<tilpner>
nick_l - I did not say anything in particular about how to install it, I just linked a few options. Which one did you choose?
<tilpner>
Your argument list is unusual, what are you trying to use your overlay for?
<Wizek>
tilpner: alright
<nick_l>
tilpner: I want to do some aws API calls in which I inject the instance id of the machine being deployed.
michas__ has quit [Remote host closed the connection]
<nick_l>
tilpner: i.e. i-<hash> on AWS.
michas__ has joined #nixos
<nick_l>
tilpner: similar for a region argument.
<nick_l>
tilpner: the only way to compute that is dependent on the deployment target environment, which means I need to depend on "nodes".
knupfer has quit [Ping timeout: 240 seconds]
<nick_l>
tilpner: I expect the "pkgs" binding at the top of the module which is in imported in the nixops network description to have a binding for pkgs which has the overlayed pkg also available, but that doesn't seem happen.
<nick_l>
I thought the whole point of overlays was to do that.
<nick_l>
tilpner: in the entirety of nixpkgs there is only one use of the overlays feature and it is not in the definition of a machine directly, but in a module specification.
<tilpner>
In which configuration did you specify nixpkgs.overlays? The one you deploy, or the one you run nixops on?
<nick_l>
tilpner: not sure what you mean. I have a.nix and b.nix. I specified it in a.nix, which doesn't contain the machine hardware specification.
<{^_^}>
→ 7f1201cf by @fpletz: Merge pull request #37972 from ryantm/auto-update/php
<Wizek>
I've just ran `nix-store --check-contents --verify` and it didn't seem to fix the issue
<nick_l>
tilpner: so, b.nix is the network specification. E.g. specifying whether I want to deploy in AWS/GCE/libvirtd, etc.
<nick_l>
tilpner: does that help?
aramiscd has quit [Read error: Connection reset by peer]
<tilpner>
nick_l - Not really. I don't use nixops anymore, but I remember there being issues with my overlays too
<tilpner>
nick_l - You could try testing a simple overlay on your host machine. If you can get that to work there, but not on the to-be-deployed machine, you know the issue is with nixops
<{^_^}>
[nixpkgs] @fpletz pushed commit from @ryantm to release-18.03 « php: 7.2.3 -> 7.2.4 »: https://git.io/vx2lG
<{^_^}>
→ 0935cbf2 by @tiramiseb: gnomeExtensions.system-monitor: fix this package and upgrade to v33
<{^_^}>
→ 058be360 by @tiramiseb: gnomeExtensions.system-monitor: Fix the version number
<{^_^}>
→ a180a52d by @tiramiseb: gnomeExtensions.system-monitor: do not need global sessionPath modification
asuryawanshi has quit [Remote host closed the connection]
<{^_^}>
[nixpkgs] @7c6f434c merged pull request #36411 → gnomeExtensions.impatience: fix the package and upgrade to version 0.4.5 → https://git.io/vAFXW
<nick_l>
tilpner: a simple test seems to work. Phew.
zzamboni has joined #nixos
humanoyd has joined #nixos
<Guanin>
Is there any known php software packaged in nixpkgs that I can use as an example for my own package? I want to package https://github.com/ToeBee/OsmAnd-Tracker as I want to use it today :D
<nick_l>
infinisil: well, I even have gcc-6.4.0 in my store for example.
<TweyII>
I just noticed that whenever I build a package my NIX_BUILD_CORES is set to 1 O.O
<infinisil>
Ohh i missed the "not" part
<infinisil>
Understood you wanted to fill it
<nick_l>
infinisil: so, it seems that the EC2 image is just super big.
<nick_l>
infinisil: i.e. more than 2GB.
<TweyII>
I have 8 logical cores on this machine
<nick_l>
Same with this file n38189zd3pgh9fm2874iva7v894sqfls-xscreensaver.pam
<TweyII>
How do I make Nix set NIX_BUILD_CORES sensibly? (NixOS)
<nick_l>
Don't see why I would ever want to have that on a server.
<nick_l>
Or mgdl06yrwc93vadh9c4sjzy9gvq5aa65-fc-10-subpixel.conf
<{^_^}>
[nixpkgs] @rbvermaa pushed to release-17.09 « nixops: update to 1.6 »: https://git.io/vx2w3
<infinisil>
Yeah some packages have gcc in their closure because either it's badly packaged or their installers make the output reference gcc for some reason
thetet has quit [Quit: Leaving.]
<nick_l>
infinisil: but perhaps I am also holding on to multiple generations?
<nick_l>
infinisil: how do I list all the system generations? nix-env --list-generations returns empty list.
<{^_^}>
[nixpkgs] @rbvermaa pushed to release-18.03 « nixops: update to 1.6 »: https://git.io/vx2wK
<nick_l>
infinisil: ah, got it.
<nick_l>
So the problem is that I run 21 system generations.
<nick_l>
There is probably an option to do something sane.
<infinisil>
You can delete single generations
<{^_^}>
[nixpkgs] @rbvermaa pushed to master « nixops: update to 1.6 »: https://git.io/vx2w1
<nick_l>
infinisil: that should happen automatically.
<nick_l>
Which I think is possible.
<infinisil>
By just going to /nix/var/nix/profiles and deleting the system* ones you don't want
<nick_l>
Nixops should know how big a small machine is and adapt its numbers to that.
<infinisil>
I don't think it happens automatically
<lejonet>
TweyII: nix.buildCores = <int>; in your configuration.nix should do the trick :)
<infinisil>
TweyII: set it to 0 for it to use all cores
ielectric has joined #nixos
ielectric has quit [K-Lined]
<nick_l>
lejonet: the disadvantage of that solution is that it won't apply to the first build.
<TweyII>
Dang
<TweyII>
I never knew
<lejonet>
nick_l: I think you're attributing more intelligence to nixops than it has :P
<TweyII>
I wonder how much time I've wasted
<TweyII>
Thanks
<TweyII>
Is there an equivalent option for non-NixOS?
<lejonet>
nick_l: very true, but its the "correct way" I guess, but iirc there is both a nix cli option and a env var you can set for same effect
<lejonet>
but can't remember the name of either on the top of my head
<nick_l>
lejonet: what is?
<lejonet>
nick_l: setting nix.buildCores in the configuration.nix
<nick_l>
lejonet: I think it is a misdesign.
<lejonet>
nick_l: how so?
<nick_l>
lejonet: every user wants to make those settings apply immediately.
<nick_l>
lejonet: so, some nix variables, should simply be "special".
<lejonet>
nick_l: well, nixos-generate-config sets nix.buildCores to the amount of logical cores it finds when you install the machine in hardware-configuration.nix...
<srhb>
(Which I always reduce somewhat...)
<nick_l>
lejonet: that's called a workaround, not a solution.
<lejonet>
nick_l: Well, nix is lazy afterall ^^
bennofs has joined #nixos
<nick_l>
lejonet: this is my opinion. I cannot force people to do smart things.
<srhb>
:P
silver has joined #nixos
<srhb>
You can perhaps word it a bit less charged though
<ottidmes>
TweyII: The non-NixOS way would probably be to just edit /etc/nix/nix.conf yourself?
<TweyII>
ottidmes: Ah, right. Thanks.
<nick_l>
srhb: how?
<lejonet>
nick_l: start by not implying that its dumb to do it the way it is ;)
<srhb>
nick_l: By attempting not to imply people are nonsmart :-)
<nick_l>
srhb: doing smart things, doesn't mean that they are now doing non smart things.
<srhb>
Good! :)
<nick_l>
srhb: perhaps they are working on the BFR.
<nick_l>
Perhaps they make no money when working on free and open-source stuff.
<nick_l>
So, in that sense it would be stupid for them to work on it, unless as a hobby.
<nick_l>
But, if we are talking whether or not it would be good for the adoption of Nix and making it more userfriendly, then I think it would be "smart".
<nick_l>
And the current way would then, if you wish, not smart.
<srhb>
I wasn't really adding my opinion to the mix, just drawing your attention to the phrasing. :)
<srhb>
Now, my _opinion_ on the subject is that it's tricky.
<srhb>
In some sense, build cores should be part of the input hash.
<srhb>
Because it really isn't invisible in a lot of builds, and sometimes not even in the output.
<lejonet>
Its in one way a chicken-egg problem
<srhb>
But that's extremely impractical.
<srhb>
(We get around it by forcing some builds to use just one core, but that's also very icky)
<lejonet>
srhb: bad build systems are bad, kindof hard to fix them on a package manager/distro level sadly :(
<srhb>
Yes, it is...
<lejonet>
(yes, I'm looking at you OpenOffice)
<srhb>
Clearly we just need smaller units of compilation!
<srhb>
*clearly*
<lejonet>
Nah, we just need moar powwah! xD
<srhb>
4THz cores would solve the whole problem. Get on it, chipmakers.
<lejonet>
It would solve a lot of other issues too, central heating, bad insulation etc etc
<srhb>
:)
<lejonet>
(on a serious note: I actually know of more than 1 instance where people actually use computers compiling instead of other source of heating)
Synthetica has joined #nixos
<srhb>
Well, if the alternative is to waste the heat...
<lejonet>
In one case, it was "merely" the fact that they had a bunch of P4s, and didn't have to pay for electricity, but had to pay for heating (weird studentdorm...)
<srhb>
Heh
<etu[m]>
lejonet: :D
<lejonet>
(yes, gentoo people, so the compiling was actually used to produce "useful" things)
<srhb>
Oh wow, NixOps was bumped :o
<lejonet>
srhb: did they fix nixosVersion -> nixos.version? :O
<srhb>
lejonet: Is that a pun on USE flags? Because in that case I might opine differently :P
<srhb>
lejonet: I would assume so, it was fixed in master quite a while ago.
<srhb>
Or rather, I think it was made compatible with either version.
<lejonet>
srhb: could be... ;)
<etu[m]>
I wanted to try out nixops like a week ago and ran into that issue
<etu[m]>
That was a bit discouraging :p
<lejonet>
srhb: that would be nice, so I don't have to use a dev-shell for using nixops :P
<lejonet>
I wrote a PR for it, that got accidentally merged then reverted, so didn't really bother with opening it again :P
<srhb>
lejonet: I'm pretty sure it was fixed at the same time :)
<srhb>
etu[m]: Yeah :/
<lejonet>
srhb: most likely, which is why I didn't bother with re-opening my PR
<srhb>
Honestly I just defined the other version as a module.
<srhb>
But that's probably not an obvious workaround.
<etu[m]>
srhb: But I've patched it locally to be able to use it. But then I had issues I couldn't figure out why it happened.
zzamboni has quit [Quit: Leaving.]
* srhb
nods
<srhb>
I feel like the way eval-machines injects modules is a bit too spooky.
<etu[m]>
srhb: After a reboot I couldn't connect anymore. Don't know if it's digitaloceans fault. But I don't see how they could mess it up.
<srhb>
In some ways I would prefer to define or import the required stuff myself.
<etu[m]>
So at the moment I have two DO droplets running NixOS which I don't use nixops for. But whenever I get the ropes in Nixops it should be easy to make new machines and migrate them :)
<etu[m]>
I'm very happy with getting rid of my last ubuntu-machine :)
<{^_^}>
[nixops] @rbvermaa pushed to master « Move version to 1.6.1 »: https://git.io/vx2o9
<srhb>
etu[m]: With a low amount of machines, managing them without NixOps isn't too bad at all, for the record.
<srhb>
etu[m]: I mean, it's just a fancy wrapper over ssh and nix-copy-closure (or presumably nix copy, soon)
<nick_l>
etu[m]: congratulations!
<etu[m]>
srhb: Yeah, that's what I've thought as well :)
zzamboni has joined #nixos
<srhb>
etu[m]: And it's very no-nonsense. You understand the process much more. I recommend at least trying it :)
<etu[m]>
nick_l: Sadly I still have two raspberries that has important tasks, and those are debian based. I tried to set up Kodi on a raspberry and didn't have much of luck... :/
vidbina has joined #nixos
<srhb>
What's the important tasks? Just out of curiosity :)
<nick_l>
srhb: watering his plants? ;)
<srhb>
I've been hearing about people using rpis for serious business, but I can only think about fun things
<etu[m]>
srhb: Yeah, I managed to set up a machine with nixops, and get a webserver up and such. But then I changed things in the config, ran it again and then I couldn't connect to it anymore. Don't know what happened :(
<srhb>
nick_l: Heh! I missed a get-together on that topic last sunday :P
<nick_l>
srhb: you are not allowed to do anything really important with a rpi for legal reasons.
<nick_l>
It can still be important relative to a consumer or person, etc.
<hodapp>
srhb: I work in the R&D department of a company that buys Raspberry Pis by the dozen to use for prototypes and demos
<srhb>
Nice :)
<srhb>
nick_l: I find it hard to believe any such clause would be valid here. :P
<etu[m]>
srhb: one runs libreelec and plays video and audio and such. the other one is hooked up to a monitor in my hallway to show the weather and when the subway leaves. I can show a picture of this in ~5 hours or so if you're interested :)
<ottidmes>
etu[m]: You cannot use nixos-rebuild directly on nixops managed machines, unless you make the nixops generated public key persistent (it gets added by nixops, but overwritten when you rebuild) in you configuration.nix
<hodapp>
also contracted at a company which made 3D printers, and they shipped with a Ras Pi inside that had a locked-down OpenWrt on it
<nick_l>
I considered to order 10,000 Pis, but then I found you cannot actually buy them.
<nick_l>
And that they are much more expensive than the lowest price claimed.
<srhb>
hodapp: Huh, why OpenWRT?
<hodapp>
srhb: it made certain juggling of the wireless much easier
<etu[m]>
ottidmes: I didn't run it directly on the machine. But it was a while ago so I don't remember exactly what I did :/
<hodapp>
and it didn't wear out SD cards nearly as fast
<srhb>
Ah, makes sense.
<hodapp>
because it was oriented around a "touch the boot device once, now put everything in RAM and go away" model
<ottidmes>
etu[m]: See `nixops export` if you want to find the keypair that has been generated for each machine
<nick_l>
OpenWRT people have a lot of networking/embedded skill.
<nick_l>
NixWRT would not replicate that.
Guanin has quit [Remote host closed the connection]
<nick_l>
(in the short term)
Guanin has joined #nixos
<lejonet>
srhb: /b 27
<hodapp>
sneaky
<lejonet>
gah... keep forgetting buffers here and there xd
romildo has joined #nixos
<lejonet>
srhb: what I was going to poke you about is not my 27th buffer but the "ceph-mgr" assertion thing, I'm thinking about removing it as an assertion but adding it to warnings if ceph-mon gets enabled, as upstream recommends having a ceph-mgr wherever there is a ceph-mon, whatcha think bout that?
<srhb>
The end of my buffer list is basically Mordor. No one enters there.
<etu[m]>
ottidmes: I will try again some day! :)
<etu[m]>
but at least I got all of the setups on nixos to begin with, which will make the transition easier.
<srhb>
lejonet: I'm kinda lukewarm on warnings.
<srhb>
lejonet: But I agree on the condition.
<{^_^}>
[nixpkgs] @Twey opened pull request #37992 → remove godot_headers in favour of a dev output on godot → https://git.io/vx2Ky
<lejonet>
srhb: how so? Sure, I guess its more up to the user to know this, but I thought that if I put in a warning in the module, atleast they can't say they didn't know :P
<lejonet>
or more correctly, whine at me because they couldn't bother to read the docs... :P
<lejonet>
srhb: seeing as its rather easy to miss the warnings, I'm more thinking that adding it as a warning will inform those looking at the module and the perceptive user :P
<srhb>
I think warnings are easy to miss in a lot of circumstances, hence my reluctance.
<srhb>
I prefer failing or allowing entirely... But I see the edge case here.
<srhb>
Hopefully it will just be made mandatory upstream and there will be no argument :P
<lejonet>
srhb: for >= 12.x it is mandatory :P
<srhb>
Not that they are colocated with monitors.
<lejonet>
Indeed very true, only mandatory of its existence
<srhb>
And I'm actually not sure if anything breaks if they're not there. I don't think so.
<lejonet>
the colocation with monitors is still just a ops-related advice that probably is a good thing to do
<srhb>
Yes.
<lejonet>
clusters get really sad if the ceph-mgr isn't up :(
averell has joined #nixos
<srhb>
They do? I thought I'd tried it with no ill consequences.
<lejonet>
(>= 12.x clusters that is)
<srhb>
Admittedly it's a bit tricky to test every functionality in ceph.
ryanartecona has quit [Ping timeout: 260 seconds]
bennofs has joined #nixos
<lejonet>
I got to experience this the hard way, because I initially didn't plan on adding ceph-mgr to the module, because I didn't know it was mandatory, but nothing worked then, regardless of the OSDs and MONs being up and happy
<srhb>
Oh, interesting.
<srhb>
Perhaps I hadn't switched the knobs entirely to Luminous when I tried upgrading.
<lejonet>
once I started a ceph-mgr instance, stuff started happening, objects were being allocated and such
<srhb>
I see. Interesting. I think there's too little info on exactly what the manager does.
srdqty1 has quit [Ping timeout: 264 seconds]
<srhb>
"By default, the manager daemon requires no additional configuration, beyond ensuring it is running. If there is no mgr daemon running, you will see a health warning to that effect, and some of the other information in the output of ceph status will be missing or stale until a mgr is started."
<srhb>
This does not sound like the cluster should _break_
<srhb>
Anyway, it's mandatory, so moot point. Just annoying :P
<srhb>
I wish they would just get rid of all the python shenanigans.
srdqty1 has joined #nixos
<nick_l>
Does anyone run kubernetes on NixOS (I know there is a presentation about it)?
simukis has quit [Quit: simukis]
<srhb>
I did until last friday. :)
averell has quit [Quit: .]
averell has joined #nixos
<srhb>
nick_l: Why?
orivej has joined #nixos
abrxs has joined #nixos
<gchristensen>
I think I've cracked the cross-linking problem of the nixpkgs <-> nixos docs
abcrawf has quit [Remote host closed the connection]
knupfer has joined #nixos
raynold has quit [Quit: Connection closed for inactivity]
Myrl-saki has quit [Remote host closed the connection]
Myrl-saki has joined #nixos
mahalel_ has joined #nixos
thetet has quit [Quit: Leaving.]
mmercier has joined #nixos
Rusty1_ has joined #nixos
vaninwagen has quit [Ping timeout: 248 seconds]
<tilpner>
I'm struggling to use eval-config.nix's specialArgs properly. I want to pass a path to a module collection, and use that to construct new paths to import, but it always ends up with infinite recursion
<tilpner>
Is there any example of proper usage (that's not modulesPath)?
<{^_^}>
[rfcs] @shlevy opened pull request #28 → [RFC 0028] Nix Release Model → https://git.io/vx2yo
vidbina has quit [Ping timeout: 264 seconds]
asuryawanshi has quit [Ping timeout: 256 seconds]
vidbina has joined #nixos
nuncanada has joined #nixos
srdqty has joined #nixos
Guanin has quit [Quit: Leaving]
<Dezgeg>
abbradar, gchristensen: yes, both ARM and AArch64 support EFI, and on server hardware (e.g. the ThunderX) EFI is typically the only way of booting then
srdqty1 has quit [Ping timeout: 260 seconds]
zzamboni has quit [Quit: Leaving.]
<abbradar>
Dezgeg: hm, and that means we use systemd-boot for that?
<Dezgeg>
if it's binutils them I'm worried what else got broken by new binutils
vidbina has quit [Ping timeout: 248 seconds]
<Dezgeg>
ok, at least the 'nix-build pkgs/stdenv/linux/make-bootstrap-tools.nix -A test' still works on aarch64 (which was broken on binutils 2.29)
zzamboni has joined #nixos
taktoa has joined #nixos
ThatDocsLady has joined #nixos
zzamboni has quit [Ping timeout: 240 seconds]
vidbina has joined #nixos
ma27 has quit [Ping timeout: 246 seconds]
<Dezgeg>
I need to take a closer look because at some point there were some reports on LAKML of of new binutils causing silent miscompilation of kernels on ARM
zzamboni has joined #nixos
<Dezgeg>
but if it's nothing else but systemd-boot that's broken then it should be fine to disable it
spear2 has joined #nixos
<shlevy>
Dezgeg: abbradar: Given there's a mass-rebuild on master, it would be a nice time to merge staging... Are we OK to have aarch64 systemd broken there while we figure this out?
<gchristensen>
is systemd itself broken or just systemd-boot?
<gchristensen>
we can't break systemd totally on master
<shlevy>
systemd itself doesn't build on aarch64
<gchristensen>
dang
<shlevy>
Yeah, that's what I thought ;P
szicari has joined #nixos
<Dezgeg>
uh, if there's some security bug on master definitely don't merge staging
<Dezgeg>
or it will most probably be stuck for weeks again :P
<infinisil>
srhb: i think that might be the root of almost every dependency in nixos
<srhb>
Yes.
<srhb>
The interesting part is definitely not the root :)
<nick_l>
Having different profiles would be useful. Something like a nixHacker module which would do all kinds of stuff like this.
<srhb>
nick_l: Hmm, in what sense?
<nick_l>
Similarly having tooling to remove dependencies automatically.
<infinisil>
nick_l: no idea what you mean
<srhb>
Dependencies are essentially removed automatically.
<srhb>
Er, unused.
<srhb>
I suppose it depends in which context you're thinking :)
<infinisil>
Well if they're unused then they're no dependencies
<nick_l>
srhb: well, now I am specifying that I want systemd.man. I'd like curl/vim/emacs/wget/file/python/haskell/... to all be installed when some kitchensink module would be imported.
<srhb>
Yes... :P
alexteves_ has joined #nixos
<nick_l>
srhb: everyone can write their own kitchensink, but that's not really needed.
<srhb>
nick_l: You mean some predefined environment.systemPackages that has everything everyone needs?
<infinisil>
nick_l: yeah that's what modules can do, just write your own
<infinisil>
nick_l: actually you wrote your own module already, configuration.nix is one
<infinisil>
Just write a module that does what you want then import it
<nick_l>
srhb: yes, defaults for different use cases (like tasksel in Debian)
<srhb>
We have some.
<nick_l>
infinisil: yes, that's what I already have done.
<srhb>
Not that specific one, I can't imagine what it would include.
<nick_l>
srhb: I think it should depend on how much juice the machine has.
<nick_l>
srhb: so, do you have TBs of free disk space? Then install a ton of stuff (if there is also a decent internet connection)
<nick_l>
srhb: i.e., there would be layers of defaults.
<nick_l>
If you are a guy in rural Australia, then you would get less by default.
<srhb>
Hmm. I guess I don't find tasksel very useful. :)
<srhb>
But nothing's preventing a module like that (or several) from existing. Except it sounds like bikeshedding central. :D
<nick_l>
man systemd.directives # no juice
<nick_l>
With systemd.man installed.
<infinisil>
nick_l: totally possible to write modules like you describe
<nick_l>
infinisil: I wasn't discussing possibility. It was more of a "do more people think this is a good idea".
<nick_l>
And apparently, already one thinks it is not :)
<srhb>
I'm ridiculously conservative though, so someone else might :P
<srhb>
Well, in this narrow field at least.
ryantrinkle has joined #nixos
<ryantrinkle>
does anyone have a nixos configuration that includes hosting a PXE server with the nixos installer image?
<infinisil>
nick_l: well nixos is rather minimalistic by default, you add what you need
<ryantrinkle>
i.e.: so that it's very easy to install nixos for anyone on that network
<shlevy>
andi-: Hey, saw your message
<srhb>
ryantrinkle: I had at one point. It's essentially as simple as a tftp enable with an image that you just refer to from the <nixpkgs/nixos> usual build bit
<srhb>
But I think I left it on my work laptop, so it's gone to the aether.
<ryantrinkle>
srhb: there's no configuration of dnsmasq or other dhcp server necessary?
mmercier has quit [Ping timeout: 256 seconds]
<ryantrinkle>
:)
<srhb>
There is, yes
<shlevy>
andi-: IMO if we're skipping staging for a MR it's probably worth a security announcement... I agree it's a shame we haven't kept up with it but I'm not sure if that means we shouldn't do it now when we're thinking of it.
<srhb>
ryantrinkle: Hang on, I was actually inspired by an upstream source, I think I can find it again
<ryantrinkle>
srhb: awesome, thanks :)
<shlevy>
Would definitely be in favor of aconcrete automation implementation for that :)
<gchristensen>
too soft / squishy to automate I think
<shlevy>
gchristensen: andi-'s idea was basically automating the *content* of the message based on commits
<srhb>
There was some other source that was more explicit though...
<shlevy>
Wouldn't cover every case but might cover some of them
<gchristensen>
the content of the message is too complicated, it is important to document the threat and why's and how's and severity and what-not
Z0L1DK3K has joined #nixos
<gchristensen>
but some of it can definitely be templated
<andi->
shlevy, gchristensen: in terms of: Pull the right CVE-numbers, add links to the NVD Database etc.. include the summary from the commits and add dates etc.. so we only have to type the relevant part and remove the "pain"
<gchristensen>
NVD database usually doesn't have useful information at the time of sending the email
<srhb>
ryantrinkle: Damn, I have a bit of salvage here... http://nixpaste.lbr.uno/Br9hEYrr?nix -- what's missing is the bootstrap files in each of the servers, but perhaps it gives an idea
<gchristensen>
but a concrete implementation is not likely to pay off as much as shlevy might hope
<andi->
I think it is kind of ironic that we have that discussion on a MR that fixes something on an arch that we do not support (CVE_2018-0733 only)
<srhb>
(The ipxe image was the interesting one, it "phoned home" to tell its hardware information to a http server which would then respond with the appropriate configuration.nix to apply)
<andi->
shlevy, gchristensen: Wasn't globin working on a tracking platform for security issues on NixOS? That would be a good start to organize the information gathering / publishing.
<gchristensen>
andi-: re nixos/security-advisories, that is for advisories about Nix and Nixpkgs and NixOS themselves, not packages we maintain
<gchristensen>
s/we maintain/we package/
<gchristensen>
at least, that was my intention
<shlevy>
andi-: Why was it merged straight to master then? :)
<andi->
shlevy: we had the discussion in #nixos-security a while ago... the responses where like "just merge it to master" or "it depends but really not"
<shlevy>
Another channel? :o
<gchristensen>
it is such hard work keeping up with the security issues, I'd rather not harp too hard on whether or not going straight to master was the right choice.
<gchristensen>
the analysis and stress and decision making is awful
<ryantrinkle>
srhb: fantastic; thanks so much :)
<srhb>
You're welcome :)
<pstn>
Does anybody have an idea what dep could be missing from baobab that breaks remote scanning? It's neither glib_networking, nor dconf.
<shlevy>
gchristensen: I'm just suggesting that the same considerations should apply to whether to send a notice
<gchristensen>
aye
<andi->
I also having a hard time figuring out what state staging might be in today, what is planned there.. if it will land in master within a reasonable timeframe.. maybe other stuff is still being baked-out and finalized there...
<pstn>
To check if it's really a dep: Could somebody with a full gnome desktop installed try remote scanning in baobab to verify that it's a missing dependency?
<gchristensen>
fwiw the typical process for security patches is always to master
<andi->
shlevy: yes, except for my point about `master`
<andi->
If we start announcing stuff for the master branch we might as well treat it like a proper release.. not sure if that is really done
<shlevy>
Hmm, OK
<shlevy>
Anyway, I'm not too fussed if we don't want an announcement here
<andi->
i've read the new RFC about the release model and I am in favor of having an always releaseable master as you suggested
<shlevy>
I was personally surprised to see a MR on master, and assumed others might want the info as well. But they'll find out one way or another :D
<andi->
I really like the debian approach with that: They provide the information on a best effort pratice for sid (their "master") and annouce for stable/oldstable/oldoldstable..
<andi->
shlevy: I've seen that.. not sure if I am a fan of that.. I wasn't really involved in much staging stuff so far... I think it is good that we are striving for a defined process but not sure how much that will help..
mmercier has joined #nixos
gh0st[m] has joined #nixos
<gchristensen>
additionally the security patching workflow and team is possible one of the most stressful things and stressed teams around
<shlevy>
andi-: If you have thoughts for how we can do it better would definitely appreciate it! The only thing I'm sure about is the status quo is extremely painful :D
<andi->
shlevy: yep, I do not have much more than that right now.. I have been reading it a few times but haven't come up with anything yet
<andi->
shlevy: As long as we've people pushing (untest & breaking) code just into master I do not really think the merge to staging or master is our most important issue
blankhart has joined #nixos
<shlevy>
andi-: We have parallel discussions about branch protection :D
<andi->
gchristensen: agreed... thought the stress that I feel is self-generated.. Not sure if anyone is already being paid for doing that job :-)
<andi->
shlevy: good, i've not really been following things
<shlevy>
andi-: But this is slightly different... The problem is not so much that things break or not. The problem is it takes arbitrarily long to get staging stuff merged in, when everyone is behaving well.
<gchristensen>
no, I think the constant flow of CVEs and critical issues in the same old software is so extremely demoralizing
<shlevy>
I don't think this matters all that much to people who don't care about staging, but those of us who do it's a regular frustration
<gchristensen>
to be honest, I was actually quite relieved when LWN shut down their data source, if for nothing other than a break from the horrors
<andi->
yeah.. I have a backlog in my head about stuff that is still "broken" (as in: known sec. issues)... kubernetes patches and a few others are on my notebook at home while I have to work at $dayjob :/
<gchristensen>
I've always been a "all software sucks" kind of person, it wasn't like being seasoned and seeing for the first time that software isn't that great. it was much worse than that, and I don't think you can really appreciate that until you've done it
<shlevy>
:(
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos
<gchristensen>
this is why we need a robust team of people to do it. we _can_ do it! we _are_ doing it
<andi->
and thats why writing the annoucement must not hurt any further than generating a template, filling in the critical details and the having a +1 person review it before sending it out..
<andi->
:-)
<gchristensen>
yeah
simukis has joined #nixos
<gchristensen>
+1
<shlevy>
Can't we get a robust team of people to rewrite the world in safe/verified languages instead? O:)
<andi->
shlevy: sure
<andi->
shlevy: when will we switch to the coreutils writting in rust? ;-)
<{^_^}>
→ dcaea58e by @dtzWill: git: 2.16.2 -> 2.16.3
<{^_^}>
→ 3d12d78e by @dtzWill: Merge pull request #37672 from dtzWill/update/git-2.16.3
<andi->
we can start with that ^^
<etu[m]>
rycee: You mean the issue I've had setting up the first generation on a system? Sadly I can't try it with your latest master because it "just works" after unstable moved forward :(
<andi->
but safe languages do not protect us against everything.. one of the openssl issues from yesterday was an recursion in an asn.1 parser.. layer8 issue
<shlevy>
I do wonder sometimes how many of those "impossibility" theorems have probabilistic analogues though. Like sure, trusting trust proves I can't ever prove a compiler safe, but is there anything I can do to be X% sure it's safe?
<nick_l>
Step 0. is to become delusional.
<nick_l>
Or perhaps to start a new religion.
<makefu>
nick_l: next step will be to burn all technology and live a good life with your harem
<andi->
Just give up in life... It sucks and one day you die anyway
<nick_l>
shlevy: no, because there is no such thing as a probability in the real world, unless you are counting quantum mechanics.
<andi->
s/in/on/
<gchristensen>
andi-: now you're talking. we should get a beer together.
<makefu>
andi-: depends on your religion i guess
<makefu>
(the one you started before)
<andi->
I have debugged java issues for the last 8h... I am ready for a beer..
<nick_l>
Do you think the Oracle decision will stand?
<andi->
To be exact: shibboleth (in a version still affected by the patches from last year)
jtojnar_ has joined #nixos
acarrico has quit [Ping timeout: 256 seconds]
ryanartecona has joined #nixos
jtojnar has quit [Ping timeout: 252 seconds]
jtojnar_ is now known as jtojnar
<nick_l>
My monitor randomly stops after a couple of hours and then starts again without me doing anything. I have never seen a monitor fail, but is that a common way for one to fail?
knupfer has quit [Remote host closed the connection]
abrxs has joined #nixos
kreisys has joined #nixos
<goibhniu>
nick_l: I've seen monitors do that alright
* goibhniu
would test with another machine too though
vidbina has quit [Ping timeout: 256 seconds]
<pstn>
Does anybody have an idea what dep could be missing from baobab that breaks remote scanning? It's neither glib_networking, nor dconf.
<pstn>
To check if it's really a dep: Could somebody with a full gnome desktop installed try remote scanning in baobab to verify that it's a missing dependency?
<pstn>
I just tride just enableing gnome3, but it kind of broke my whole system due to networking issues, so I don't want to do that again.
<coconnor>
on case insensitive file systems (EG: HFS+ and friends) files like "KPart" and "kpart" will interfere
<coconnor>
so, nix nicely avoids this issue by adding a suffix "nix~case~hack" when required. Potentially breaks the package on case insensitive filesystems. But at least ensures preservation of data
<niksnut>
maybe we should just get rid of the case hack
<niksnut>
iirc, it was once added to allow nixops to run on macos, but I don't know if anybody actually does that
<coconnor>
possibly, I have no real issue with it. Only trying to recover from it being improperly applied
<coconnor>
ahhhh
<Dezgeg>
doesn't APFS allow creating a case-sensitive filesystem?
<coconnor>
Both HFS+ and APFS allow creating case-sensitive filesystems
<LnL>
yes
<coconnor>
however, the default is case preserving but case insensitive
<coconnor>
(to retain compatability with... who knows)
<lambdamu>
There is still a use of placeholder left in pkgs/development/libraries/pipewire/default.nix that breaks evaluation for nix < 2
<{^_^}>
→ f8ed783f by @Ericson2314: meta: Simplify platform check logic
<{^_^}>
→ d5f35637 by @Ericson2314: Merge pull request #37918 from Ericson2314/check-meta-golf
<Biappi>
coconnor: shitty 3rd party software that apple *needs*, like the adobe suite, microsoft office and native instruments software amongs others
<coconnor>
Biappi: I shoudl have guessed it would be due to Adobe or microsoft haha
digitus has joined #nixos
vidbina has joined #nixos
c_wraith has joined #nixos
<tmplt>
I request some help with GNU Octave. When I save a figure as a pdf the program panics and aborts with "support for gl2ps was unavailable or disabled when Octave was built". Is there some Nix option I should override? Nothing in the default.nix seems to be related to it.
<kolb>
I get error: undefined variable ‘kPackages_4_4’
jb55 has joined #nixos
<kolb>
oh NVM I’m dumb
takeda has quit [Quit: leaving]
asuryawanshi has joined #nixos
ThatDocsLady has quit [Ping timeout: 256 seconds]
jrolfs has quit [Read error: Connection reset by peer]
asuryawanshi has quit [Remote host closed the connection]
reinzelmann has quit [Quit: Leaving]
asuryawanshi has joined #nixos
goibhniu has quit [Ping timeout: 248 seconds]
jb55 has quit [Ping timeout: 265 seconds]
<Profpatsch>
gchristensen: Nope, don’t really interact with systemd much.
<Profpatsch>
Only with the bugs I find when I (seldomly) write service files.
<Profpatsch>
It might be a worthwhile project to use the systemd syntax checker and build an executable that can sanity-check the unity files we generate at system build time.
roberth has quit [Ping timeout: 248 seconds]
mmercier has quit [Ping timeout: 260 seconds]
magnetophon has joined #nixos
<tmplt>
I haven't overridden a package's options before. Is adding (octave.override {ghostscript = true;}) to the system package list not correct? Building fails with "build input 1 does not exist".
chreekat has quit [Quit: quitting]
endformationage has joined #nixos
<Neo-->
Hey all, a bit of a weird issue. Running nix-env -f "<nixpkgs>" -qaP | grep chromium returns that latest chromium version is 64, however, despite running nixos-rebuild test & switch and nix-env -u chromium (doesn't do anything), my system still uses chromium 57 . I even checked the /nix/store and I have several versions present (including 64, which would explain why nix-env -u is noop), but for some reason an old version is symlinked to /nix/var/nix/profiles/def
<Neo-->
ault/bin/chromium. Any ideas why this might be happening?
lambdamu has quit [Remote host closed the connection]
<coconnor>
check "which chromium" in command line. See if it returns a .nix-profile path
thetet has joined #nixos
<jtojnar>
pstn: what do you mean by remote scanning? ssh?
<Neo-->
I think what happened was that a year back when I started with nixos I might have installed chromium via nix-env -i instead of via configuration.nix which I usually do and that had priority over configuration.nix one - I now nix-env --uninstall (as root) chromium and now the correct version is shown :)
<Neo-->
I thought "default" was just current user's one :)
<gchristensen>
any nix-on-linux users around brave enough to rm -rf /nix/store for me to try a new nix-on-linux installer? (I'm not read yet, just looking for volunteers :))
<coconnor>
haha easy mistake. I really do think it shoudl be renamed to root. It's both the root profile and the profile of root.
<sphalerite>
coconnor: yeah but it applies to all users
jtojnar has quit [Ping timeout: 264 seconds]
jtojnar_ is now known as jtojnar
Guest75414 has quit [Quit: Guest75414]
<coconnor>
as the root of a hierarchy would
acarrico has joined #nixos
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ariakenom has joined #nixos
peacememories has joined #nixos
ryanartecona has quit [Quit: ryanartecona]
<jtojnar>
is there something like git-shell? I would love to use git shell branch that would just open a shell with the branch checked out
<jtojnar>
I want each shell to be independent, stashing only allows to work on a single branch at a time
jensens has quit [Ping timeout: 256 seconds]
ryanartecona has joined #nixos
zzamboni has quit [Quit: Leaving.]
<Neo-->
jtojnar, I'm not sure if I understand you correctly, but there's git worktree which can checkout more than one branch at a time
<telent[m]>
> NixWRT would not replicate that.
<telent[m]>
Right now, pretty much all the networking/embedded knowledge in nixwrt has been acquired by reading & copying code wholesale from openwrt, so yeah :-)
<{^_^}>
→ 30f8c93a by @jtojnar: shotwell: 0.28.0 → 0.28.1
<{^_^}>
→ 1449a479 by @jtojnar: orca: 3.27.91 → 3.28.0
<{^_^}>
→ 78190d2e by @jtojnar: evince: add comic support
<infinisil>
gchristensen: I can't test it, but I think it should work, bind mounts are pretty opaque to the file API
ryanartecona has quit [Quit: ryanartecona]
<infinisil>
abcrawf: 1. add --show-trace and hope you can stop something relevant 2. Bisection between what you had previously that didn't give that error and your current state
<infinisil>
s/stop/spot
<jtojnar>
infinisil: I think --show-trace is useless for stack overflow
<infinisil>
jtojnar: It helped me sometimes actually
<infinisil>
Oh wait
<gchristensen>
anyone here with a drupal site? (cc: fpletz, globin) some severe security advisories are dropping in 10min.
<infinisil>
It's a stack overflow, never mind
<infinisil>
Yeah just 2. then
<coconnor>
--show-trace has improved WRT infinite recursion
<infinisil>
Well it's always an option
<abcrawf>
Does the stack overflow imply that the derivation has the stack overflow or something internal to nix-env?
<coconnor>
but lazy evaluation makes stack traces a challenge. See GHC's long battle with that haha
tilpner has quit [Remote host closed the connection]
vaninwagen has quit [Ping timeout: 264 seconds]
tilpner has joined #nixos
periklis has quit [Ping timeout: 260 seconds]
<rycee>
etu: If it works then I'm happy :-) If it ever happens again then you should at least get an error message that provides some information about the error state, which should help finding the root cause.
<abbradar>
domenkozar: it doesn't seem we support building it with nss, only with gnutls or openssl
<{^_^}>
[nixpkgs] @bendlas pushed commit from @Ma27 to master « Revert restrictive validation behavior for DM/WM defaults in the X module »: https://git.io/vxazm
<{^_^}>
[nixpkgs] @bendlas pushed commit from @Ma27 to release-18.03 « Revert restrictive validation behavior for DM/WM defaults in the X module »: https://git.io/vxazn
<tobiasBora>
Hello,
jrolfs_ has quit [Quit: WeeChat 2.0]
<tobiasBora>
Any idea why imapnotify is not packaged in nix?
<infinisil>
tobiasBora: nixpkgs doesn't automagically have everything packaged, it takes people effort to do so, and apparently nobody took the time to package imapnotify yet
<tobiasBora>
infinisil: ok thank you. I just wanted to make sure that it was not for a specific reason.
<tobiasBora>
Maybe I could help then ^^
<infinisil>
tobiasBora: But you're free to do so yourself and open a PR to add it, or open an issue to ask for it being packaged
thetet has joined #nixos
shlevy has joined #nixos
<{^_^}>
[nixpkgs] @bendlas closed pull request #37276 → Revert restrictive validation behavior for DM/WM defaults in the X module → https://git.io/vxOEr
<tobiasBora>
infinisil: ok I'll give it a try I think. It is installable using npm, I saw that there is node2nix to deal with that, do you know if it's the cannonical way to proceed?
<infinisil>
(I'm so glad I can link to a readable version of this doc part just like that, you know why? Because it's written in markdown and not xml!)
<{^_^}>
[nixpkgs] @jtojnar pushed commit from @hedning to master « makeDBusConf: Look for .conf files in share/dbus-1/system.d/ too »: https://git.io/vxag4
hotfuzz_ has joined #nixos
hotfuzz has quit [Ping timeout: 256 seconds]
<{^_^}>
[nixpkgs] @jtojnar merged pull request #37994 → Make dbus look for .conf files in share/dbus-1/system.d/ too → https://git.io/vx2X7
<elvishjerricco>
gchristensen: I can spin up a VM to try your installer. Would that help?
jetien has joined #nixos
<gchristensen>
hmm maybe!
<gchristensen>
I'll keep you in mind :)
pkill9 has quit [Ping timeout: 240 seconds]
<{^_^}>
[nixops] @AmineChikhaoui opened pull request #915 → Fix the deployment of machines with a large number of keys. → https://git.io/vxa26
<{^_^}>
[nixpkgs] @rycee pushed commit from @dywedir to master « skypeforlinux: 8.17.0.2 -> 8.18.0.6 »: https://git.io/vxa2S
<infinisil>
gchristensen: Maybe you could even set up a vm test in nixpkgs that checks the nix installer :O
magnetophon has quit [Remote host closed the connection]
<gchristensen>
tbh that part isn't super interesting
jtojnar has joined #nixos
<gchristensen>
I'm wondering about real systems that are configured to do weird stuff by cruft they've accumulated over time
<{^_^}>
[nixpkgs] @LnL7 pushed to master « python-celery: fix darwin build »: https://git.io/vxaav
<{^_^}>
[nixpkgs] @LnL7 pushed to release-18.03 « python-celery: fix darwin build »: https://git.io/vxaaL
magnetophon has joined #nixos
<infinisil>
I see
<ryantm>
Is there something in nixpkgs like writeText with an argument for file permissions?
<magnetophon>
Is anyone else having weird font problems on the latest NixOS unstable? In emacs the fontis way too big, and in ranger the kerning is way off
<tobiasBora>
infinisil: great thank you very much
<infinisil>
ryantm: I thought the nix daemon chown and chmods all files anyways after the build, only executable bit is persisted afaik
<elvishjerricco>
gchristensen: Got it. Curious why you're making a new installer though?
<gchristensen>
so the Nix on Linux installer uses the daemon
knupfer has quit [Remote host closed the connection]
<ryantm>
infinisil: ok, thanks.
<infinisil>
ryantm: Hah, even worse: suspicious ownership or permission on '/nix/store/0priix4p2w9k8nya2ykvhlbmz007g95y-hello'; rejecting this build output
<ryantm>
infinisil: So every file is either 444 or 555?
<infinisil>
ryantm: Ah from the nix source: "/* Check that the output is not group or world writable, as that means that someone else can have interfered with the build. Also, the output should be owned by the build user."
<sphalerite>
is there a canonical place to configure default blanking settings for ttys? I'd like to set a shorter timeout on my laptop which I'm using as a server
<{^_^}>
[nixpkgs] @bjornfor pushed commit from @ryantm to master « babeltrace: 1.5.4 -> 1.5.5 »: https://git.io/vxaVB
<magnetophon>
The font I use is not found, even though it is in my system config. Shouldn't that lead to a failed nixos-rebuild?
<ruhatch>
infinisil: Sometimes, but not usually
rauno has joined #nixos
<ruhatch>
This has been happen for a month, maybe two, and I'm using nixos-unstable
sigmundv has joined #nixos
<ruhatch>
I see this error a fair bit, although sometimes while it is working, so I'm not sure it's relevant: brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-23
alex`` has quit [Quit: WeeChat 2.1]
<foldingcookie>
hi, does anyone have an example config using dnsmasq as a caching resolver only? I tried `services.dnsmasq.enable = true; services.dnsmasq.extraConfig = ""; services.dnsmasq.resolveLocalQueries = true;` but it merely broke DNS entirely (after a reboot and such)
dbe has quit [Ping timeout: 240 seconds]
jetien has quit [Quit: Leaving.]
John882 has quit [Quit: John882]
John882 has joined #nixos
<infinisil>
foldingcookie: If you just have services.dnsmasq.enable = true; try a `dig @127.0.0.1 google.com` to see if it works at all
John882 has quit [Client Quit]
John882 has joined #nixos
<infinisil>
magnetophon: NixOS doesn't check whether the fonts you use are there, since that's pretty stateful in user applications configs
<{^_^}>
[nixpkgs] @dezgeg pushed 3 commits to unstable-aarch64: https://git.io/vxa6T
<{^_^}>
→ f8d38c31 by @shlevy: binutils: Add comment about the limited lifetime of gold-symbol-visibility.patch
<{^_^}>
→ fbe8deb2 by @shlevy: ghc: Use persistent URL for abi-depends determinism patch.
<{^_^}>
→ f2d6702e by @dezgeg: perlPackages.YAMLLibYAML: Remove obsolete build fix
<Ralith>
fontconfig is badly broken for me in 18.03
<foldingcookie>
infinisil: I'll try that when I get a chance, thank you
<magnetophon>
infinisil: Not sure if we are talking about the same thing. Emacs gives an error that it doesn't find the font, and termite also doesn't seem to find it. So I assume it's not installed (correctly). Since I installit inmy system config, I would expect the "nixos-rebuild" to fail.
<foldingcookie>
how do releases of nixOS work? I see mentions of 18.03 and 17.09, but what exactly is being versioned in six-month increments? is there an impending ubuntu-style apocalyptic "upgrade your whole system" event?
<foldingcookie>
I would imagine not but don't really get how things do work yet ;)
<infinisil>
magnetophon: You used the fonts.fonts option? And I don't see a reason why nixos rebuild would fail because of that
<Ralith>
infinisil: I dunno why a routine update would be responsible
robstr has quit [Quit: WeeChat 1.9.1]
John882 has quit [Client Quit]
<Ralith>
fc-cache no longer seems to index pcf fonts at all
<infinisil>
Was just a wild guess ¯\_(ツ)_/¯
<magnetophon>
infinisil: yes, fonts.fonts. Why would that not cause the build to fail? I mean if a systempkg doesn't install properly, that *does* cause a build to fail. Why wouldn't this?
<magnetophon>
Ralith: it's a pcf font, so that seems related
<infinisil>
magnetophon: What do you mean by not properly? Packages just get added to the result, it doesn't matter if they contain the wrong file, they contain whatever files they have, nothing checks that font packages have exactly the files they had previously
<Ralith>
glad it's not just me
<Ralith>
on 18.03, fc-cache -v includes `/nix/store/20170zpm44n74js79wq9vy2gwz0lk7sz-terminus-font-4.46/share/fonts/terminus: skipping, existing cache is valid: 0 fonts, 0 dirs`
John882 has joined #nixos
<Ralith>
on 17.09, it's instead `/nix/store/hwsd0r3rm620xf12zw1dsisa4n8kh3xa-terminus-font-4.46/share/fonts/terminus: skipping, existing cache is valid: 18 fonts, 0 dirs`
<magnetophon>
infinisil: OK, I see. Any ideas on how to troubleshoot this? Maybe related: the upstream urlis down/
ryanartecona has quit [Quit: ryanartecona]
<infinisil>
I should try to finish my url verifier which would prevent stuff like this, or at least detect it
<magnetophon>
Ralith: on unstable: /nix/store/1n4bmj1x1j1lcldj2nlnm97hb09lqcc4-dina-font-2.92: skipping, existing cache is valid: 0 fonts, 1 dirs
<Ralith>
the font is still there, fontconfig is just ignoring it for god knows what reason
<Ralith>
magnetophon: that's normal, you want to look at the share/fonts/whatever subdir
<magnetophon>
Ralith: idk what fontconfig is, or what to tell them, sorry
simukis has quit [Quit: simukis]
simukis has joined #nixos
dingotux has joined #nixos
<neonfuz>
so I was complaining in here earlier that changing a single option in my kernel caused me to need to build my entire kernel, and someone here suggested building an "out of tree" module, and I was wondering exactly how I would do that
<neonfuz>
the source for the module itself is in the linux (kernel) source, I just need to build this one module, and have it override the one from my kernel package if possible
simukis has quit [Client Quit]
simukis has joined #nixos
acarrico has joined #nixos
zybell_ has quit [Ping timeout: 240 seconds]
kolb has left #nixos [#nixos]
ilyaigpetrov has quit [Quit: Connection closed for inactivity]
freeman42x]NixOS has quit [Ping timeout: 256 seconds]
zybell_ has joined #nixos
<MichaelRaskin>
neonfuz: that might have been me
<neonfuz>
I think it was
<neonfuz>
so actually I guess I need to modify an option on an "in tree" module
coot has joined #nixos
coot has quit [Remote host closed the connection]
<MichaelRaskin>
I would look at the module source directory for that specific module, at acpi_call source and expression and see if you can make the former look like the latter
<lostman>
I'm trying to use binary cache over ssh and I'm getting `warning: unknown setting 'ssh-substituter-hosts'`. it is in the latest version of the docs though
<lostman>
did something change?
Neo-- has quit [Ping timeout: 256 seconds]
chisui has joined #nixos
ma27 has joined #nixos
<MichaelRaskin>
I guess Nix 2.0 release…
goibhniu has joined #nixos
<lostman>
yeah, I'm running 2.0. are there new docs somewhere?
<lostman>
I've been looking at nixos.org/nix/manual
davidlt_ has joined #nixos
davidlt has quit [Ping timeout: 260 seconds]
orivej has joined #nixos
davidlt_ is now known as davidlt
<MichaelRaskin>
Hm, interesting question. The manual seems to be the latest version, maybe this part got stale
<lostman>
it seems that extra-binary-caches ssh://user@machine works
<lostman>
that is, it *might* work if I get the machine configured correctly :) it says it can't find nix-store command
<Dezgeg>
my git generates: diff --git a/default.nix b/default2.nix | similarity index 100% | rename from default.nix | rename to default2.nix
<jtojnar>
info patch: "if any files have been renamed between the two versions, make a list of 'rm' and 'mv' commands for the user to execute in the old version directory before applying the patch."
jrolfs has joined #nixos
<jtojnar>
there is a whole shortcomings section in the info pages about it: 18.1.2 Handling Changes to the Directory Structure
<{^_^}>
[nixpkgs] @obadz merged pull request #37949 → zerotier module: add option to join network and open port → https://git.io/vxgSu
<{^_^}>
[nixpkgs] @obadz pushed to master « zerotier module: add option to join networks and open port »: https://git.io/vxaHx
simukis has quit [Ping timeout: 245 seconds]
xy3_ is now known as xy2_
<jtojnar>
apparently, diff-cleaner was at fault
<magnetophon>
infinisil, Ralith: I had dina-font installed, and not dina-font-pcf. Now both emacs and termite can find it... sorry for the noise...
<Ralith>
maybe I'll switch to dina if it's just terminus that's broke
<magnetophon>
Ralith: seems to do the trick. Not sure for how long though, since the upstream url is down..
<Orbstheorem[m]>
How can I install gcc with manpages using nix-env?
<Orbstheorem[m]>
last time I manually installed the /nix/store/....-gcc-man-../ path. but I just ran `nix-env -u` and it got replaced by gcc :(
<elvishjerricco>
Hm. Looks like nixops is moving ahead with a new release. Is it really suitable for release with so many of the options not documented in the manual?
<pbogdan>
sorry to nag again, could I get some feedback on https://github.com/NixOS/nixpkgs/pull/35881 ? (at least in terms of whether it's something worth having in the first place)
<{^_^}>
[nixpkgs] @ryantm opened pull request #38019 → nixos/monit: reload monit if config changes → https://git.io/vxaFm
civodul has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
<ryantm>
infinisil: ^ theres my workaround for my problem with permissions in the nix store, seems kind of hacky though.
jtojnar_ has joined #nixos
jtojnar has quit [Quit: jtojnar]
jtojnar_ has quit [Remote host closed the connection]
xy2_ has quit [Ping timeout: 260 seconds]
<Dezgeg>
sounds like you want restartTriggers = [ config.environment.etc."monitrc".source ]; or something
jtojnar has joined #nixos
acarrico has quit [Ping timeout: 268 seconds]
ryantrinkle has quit [Ping timeout: 252 seconds]
shabius has quit [Remote host closed the connection]
jtojnar has quit [Ping timeout: 260 seconds]
<ryantm>
Dezgeg: Looks good! It would be nice if there was also reloadTriggers, but that seems good enough and better than what I did for sure.
<{^_^}>
[nixpkgs] @obadz pushed commit from @ryantm to master « peek: 1.2.2 -> 1.3.0 »: https://git.io/vxahn
shabius has quit [Ping timeout: 246 seconds]
<ryantm>
!m obadz
<[0__0]>
You're doing good work, obadz!
<obadz>
☺
davidlt_ has joined #nixos
thc202 has quit [Ping timeout: 248 seconds]
jtojnar has quit [Ping timeout: 256 seconds]
jtojnar_ has joined #nixos
jtojnar_ has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 246 seconds]
jensens has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos
hamishmack has quit [Quit: hamishmack]
knupfer has quit [Ping timeout: 240 seconds]
jtojnar has quit [Ping timeout: 240 seconds]
<ryantm>
nix-update seems to have exhausted the low hanging fruit: on it's last run, it only generated 31 pull requests out of 3838 packages that repology.org says are out of date.
<{^_^}>
[nixpkgs] @coreyoconnor opened pull request #38022 → QGIS: 2.18.17 -> 3.0.1 plus required libs → https://git.io/vxajm
<ryantm>
MichaelRaskin: 495 could not prefetch new version source
<ryantm>
MichaelRaskin: "nix-env -q failed to find package name with old version" means it couldn't find the derivation file to update, there are 919 of those.
<elvishjerricco>
joe1: I think all the nodes in a given nixops deployment have to use the same nixpkgs
<ryantm>
MichaelRaskin: "nix build failed" is only 255
<joe1>
thank elvishjerricco, so best to create a new deployment for testing a new pinned version rather than new resources within existing deployment
judson has quit [Ping timeout: 260 seconds]
shabius has joined #nixos
<MichaelRaskin>
ryantm: I wonder how many of the nix-env -q failures just mean that the package has been upgraded in the meantime
erasmas has quit [Quit: leaving]
leo60228 has quit [Quit: Page closed]
<ryantm>
MichaelRaskin: Yeah, its unfortunate that https://nixos.org/nixpkgs/packages-unstable.json.gz is not updated exactly when nixpkgs-unstable is updated, and that nixpkgs-unstable sometimes takes many days to update, because that is how repology.org is getting it's information. Its probably possible to relax the need to have the exact old version repology.org reports.
<MichaelRaskin>
Does repology show the upstream fetch URLs various repos use?
dingotux has quit [Quit: Konversation terminated!]
coconnor has quit [Ping timeout: 276 seconds]
blonkhart has joined #nixos
shabius has quit [Ping timeout: 240 seconds]
jrolfs has quit [Ping timeout: 256 seconds]
pkill9 has joined #nixos
<ryantm>
MichaelRaskin: It has a field called downloads where it can expose that. I'm not sure how often it's populated. https://repology.org/api
abathur has joined #nixos
coconnor has joined #nixos
coconnor has quit [Remote host closed the connection]
jrolfs has joined #nixos
<ryantm>
MichaelRaskin: I just tried the first package that failed `yacas` and it has a downloads entry for v1.6.1. I'll look into doing more with that.