<sigtrm>
Hey everybody, probably a dumb questions, but I am struggling with getting ssh running on my NixOS install. Sorry if this is obvious, I am just getting to know NixOS
<sigtrm>
So far I've added services.openssh.enable = true; to my configuration.nix file, but I just get errors, am I missing something?
<srk>
sigtrm: are you trying password auth as root?
<sigtrm>
I am logged in as root when I am making changes to the configuration.nix file yes
<srk>
errors during rebuild switch?
<sigtrm>
Yes
<srk>
paste them somewhere
<sigtrm>
Should I be adding it to environment.systemPackages?
<srk>
no, that's not required
dbmikus has joined #nixos
<sigtrm>
OKay, I will have to get another TV, because it only outputs to the TV once every 10th reboot or so, and I can't trigger it now. I will tell you the error
<srk>
modules are self-contained (independent of the environment) and sometimes add stuff to environment as well
<srk>
like if you enable nfs it will install nfs-utils into your env as well
<sigtrm>
Thank you
thc202 has quit [Ping timeout: 244 seconds]
ntqz has quit []
dbmikus has quit [Ping timeout: 265 seconds]
worldofpeace_ has quit [Ping timeout: 256 seconds]
<clever>
you will want to remove the copy in nix-env
<clever>
and yeah, that too
<neonfuz>
oh really, I added it in .config/nixpkgs/config.nix
<clever>
that has to go into nixpkgs.config.virtualbox.enableExtensionPack
<clever>
in configuration.nix
<clever>
i believe
<neonfuz>
so do all things like kernel modules need to be added through nixos and not nix-env?
<clever>
correct
<neonfuz>
okay cool
justan0theruser has joined #nixos
justanotheruser has quit [Ping timeout: 240 seconds]
<{^_^}>
[nixpkgs] @orivej-nixos pushed commit from @orivej to master « gdal: update proj option »: https://git.io/fN9iE
growpotkin has joined #nixos
<growpotkin>
Hooowdy. I am trying to debug an issue with "libinput" and ran into a syntax I am unfarmiliar with in the NixOs module's options. I have a hunch that understanding that line might help me "crack the case"
justan0theruser is now known as justanotheruser
<growpotkin>
instead of the normal config lines that write a file to "etc" the module for libinput does something I have never seen before.
andreabedini has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<growpotkin>
The issue I am having is that after a reboot cycle my "/etc/X11/xorg.conf.d/40-libinput.conf" file is missing. To make it appear I have to manually link the file or rebuild my run "nixos-rebuild switch", then restart X
<growpotkin>
and I imagine that this weird line that is supposed to create that file is probably the culprit
<jtojnar>
Growpotkin: environment.etc has two forms:
<jtojnar>
1) list of sets (target × (source | text))
<jtojnar>
2) attribute set where keys correspond to target
<jtojnar>
nothing special about that
hakujin has joined #nixos
<growpotkin>
okay I suppose this form is just new to me then. :-D
<clever>
Growpotkin: is /boot mounted ?
<growpotkin>
Yes
endformationage has joined #nixos
hakujin has quit [Ping timeout: 256 seconds]
<clever>
Growpotkin: can you pastebin the output of `mount ; ls -l /run/current-system /run/booted-system` ?
<growpotkin>
yeah just a sec
<growpotkin>
i forgot how to dump stderr and stdout into xclip lol
<clever>
all of that should be on stdout
<growpotkin>
oh it's only 2 lines then
<growpotkin>
I had a lot on stderr though
<clever>
the redirect only applies to the 2nd command
<clever>
because of the ;
<growpotkin>
OH good looking out. I need to subshell it and grab all the output
<growpotkin>
You're right, my /boot folder is full. Which is not the same thing...
<clever>
every time you nixos-rebuild, it updates /boot on the / partition
<clever>
and then it boots the old config from the /boot partition
<clever>
and that undoes any changes you had done
<clever>
manually mount it, fix the config in /etc/nixos/, and then nixos-rebuild once more, and all should be perfect
<growpotkin>
Okay will do. I'm imaging I have the boot loader set up incorrectly or maybe an issue with my hardware-config?
<clever>
if you manually mount it and run nixos-generate-config, it will fix hardware-config.nix automatically
<growpotkin>
To give context, I have been running NixOS on my desktop for ages, and just decided to put it on my laptop. So I know there are kinks to work out still.
<growpotkin>
Thank you!
<growpotkin>
Clever, you're the man now dog.
<clever>
i think ive fixed this exact problem 3 or 4 times now, lol
<neonfuz>
hmm, vbox extensions still aren't working...
<growpotkin>
Yeah come to think of it I think I know where this might have come from.
<neonfuz>
is vbox extensions a module?
<clever>
neonfuz: the nixos config will auto-load the modules for you
<clever>
its 1am here though, i need to get to bed, goodnight all :)
<growpotkin>
Thank you clever!
growpotkin has left #nixos [#nixos]
<neonfuz>
man I feel like I'm missing something here
Ericson2314 has joined #nixos
Drakonis has quit [Remote host closed the connection]
<{^_^}>
[nixpkgs] @fpletz pushed commit from @r-ryantm to master « mbedtls: 2.11.0 -> 2.12.0 (#44741) »: https://git.io/fN9yZ
<growpotkin>
Does setting up tmpfiles take a really long time for anyone else? I have NixOS on 3 machines, but for one of them that step takes way way longer than the other machines.
<maerwald>
carlosdagos: but I don't want to pull master.tar.gz, I want a real clone
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to master « angband: 4.1.2 -> 4.1.3 (#44801) »: https://git.io/fN9yM
pie_ has joined #nixos
<carlosdagos>
@maerwald you mean cloning the repo? I think that'd be this one https://github.com/i3/i3status, and if you want to use it in a derivation you can use a function called `fetchFromGitHub` (where you can try to build i3status from master instead of from version 2.12)
<otini>
Hey, I've been trying to compile C files into 32-bit executables on my x86_64 NixOS but without success. Any pointers?
<srhb>
otini: The short version is to use pkgsi686Linux instead of pkgs
<otini>
srhb: Mm I've tried to compile in a `nix-shell -p pkgsi686Linux.gcc pkgsi686Linux.binutils` but it didn't work
<otini>
gcc doesn't find the 32-bit glibc
<srhb>
otini: I suggest writing a proper nix derivation as you would if it were a 64 bit build and then just replacing pkgs for it. You'll need a proper 32 bit stdenv. :)
<otini>
Okay I'll try that
<neonfuz>
yeah I peeked in /etc/nix and saw the cores = 1 line, so I searched and found that
<otini>
How should I write my derivation to use pkgsi686Linux.stdenv instead of stdenv?
<srhb>
otini: Generally you just write it to use stdenv and then call it with { stdenv = pkgsi686Linux.stdenv; }
<srhb>
otini: That way it's completely generic.
Dedalo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<srhb>
(Usually that means calling the entire thing with pkgsi686Linux.callPackage mypackage {};)
<otini>
srhb: And how can I redefine stdenv when I write my derivation in default.nix and use nix-build?
<otini>
srhb: Oh.
<srhb>
May I suggest that you dont? Have an i686.nix that calls your default.nix with the above :)
<srhb>
Leaving the default.nix entirely indifferent of the architecture.
<otini>
I'm not sure what to put in i686.nix and how to call it. As of today I actually have written very few derivations ^^'
noctux has quit [Quit: WeeChat 2.2]
<srhb>
Something like the following
<srhb>
let pkgs = import <nixpkgs> {}; in pkgs.pkgsi686Linux.callPackage ./default.nix {};
<srhb>
That's more or less the thinnest wrapper that does the right thing :)
<srhb>
And then, you can just nix-build i686.nix
<otini>
Ok great I'll try that! Thanks :)
<srhb>
Welcome.
worldofpeace_ has quit [Ping timeout: 256 seconds]
<otini>
Noob question: how can I just build a local C file in a derivation? Nix-build creates an empty build directory and complains that the file is not there.
nwspk has joined #nixos
<srhb>
otini: Assuming that you have a project/ dir, the easy way is to have src = ./.;
<srhb>
Oh, wait, is that right though.. You probably need to override/disable unpackPhase then.. Let me check :)
<srhb>
(Otherwise you could just use unpackPhase to copy the file to cwd, which is the build tree)
<{^_^}>
[nixpkgs] @xeji pushed commit from @colemickens to master « keybase-gui: 2.3.0 -> 2.5.0 (#44705) »: https://git.io/fN9FM
alex`` has quit [Ping timeout: 240 seconds]
Tobba has quit [Remote host closed the connection]
thibaut has joined #nixos
thibaut is now known as thibm
__monty__ has quit [Quit: leaving]
<tilpner>
Hi! I have root ssh access to a NixOS machine, and I would like to use it to build a local derivation, without then copying the outputs back, without global configuration, signing keys, or additional ssh keys. Is this possible?
<tilpner>
I have tried passing --option builders, but there was no output indicating a remote build
<{^_^}>
[nixpkgs] @xeji pushed commit from @8573 to master « vim_configurable: Add `wrapGAppsHook` for GTK 3 (#44645) »: https://git.io/fN9ba
<srhb>
tilpner: Ah, the optimism at the start of a remote building project... :-)
<tilpner>
Well, it didn't before. It's not doing anything yet though
<srhb>
If you're curious what's going on, throw -vvv at it
<srhb>
Or some arbitrary amount of v's at least
<tilpner>
And... it failed
<tilpner>
yay
<tilpner>
It was trying to tar up a directory that doesn't exist locally
andreabedini has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thibm has quit [Quit: WeeChat 2.0]
<srhb>
tilpner: Uh, that sounds a bit weird?
<tilpner>
Seems dependent on my setup, but here's the output: tx0.co/1M
<tilpner>
"tar: /nix/store/nqlg15il8hn0x3xmcvsmscv0dkdfkbyg-source: Cannot open: No such file or directory"
fendor has quit [Ping timeout: 240 seconds]
bennofs has quit [Quit: WeeChat 2.0]
<srhb>
tilpner: Unexpected. Not sure what's causing that.
smolboye has quit [Quit: WeeChat 2.2]
thibm has joined #nixos
smolboye has joined #nixos
mayhewluke has quit [Ping timeout: 240 seconds]
<tilpner>
srhb - Do you know how to remote-build with Nix1 nix-build?
<srhb>
tilpner: The nix-build interface or an _actual_ Nix1 installation?
<tilpner>
The nix-build interface. I'm on Nix2 of course, but not quite happy with the "nix build" interface
<srhb>
Same way.
worldofpeace_ has quit [Ping timeout: 256 seconds]
mayhewluke has joined #nixos
<{^_^}>
[nixpkgs] @markuskowa opened pull request #44813 → Add licenses: libzip, minizip, bzip2, zip → https://git.io/fN9Nq
<srhb>
(eg nix-build file -A attr --store somestore)
sigmundv has joined #nixos
Ariakenom has quit [Quit: Leaving]
<tilpner>
Hmm, same error
Ariakenom has joined #nixos
<srhb>
Can you identify the source in question and how it's included in your project? It seems a surprising error to me, if that doesn't happen on a local build.
phreedom_ has joined #nixos
biopandemic has quit [Ping timeout: 240 seconds]
freeman42x]NixOS has quit [Ping timeout: 244 seconds]
phreedom has quit [Ping timeout: 250 seconds]
pie_ has quit [Ping timeout: 240 seconds]
alex`` has joined #nixos
sophiag has quit [Ping timeout: 244 seconds]
hyper_ch2 has joined #nixos
__monty__ has joined #nixos
<tilpner>
It doesn't give the same error with NIX_PATH=nixpkgs=channel:nixos-unstable, but with that NIX_PATH it takes forever to do anything. It's fetched nixexprs and started unpacking them, and the speed would suggest local nix is doing that remotely (6m on a slow connection just to unpack nixexprs)
vmandela has joined #nixos
<srhb>
tilpner: I think with this approach there's a lot of unnecessary copying to the remote store going on regardless of whether it was necessary. I think there's still a lot of issues here.
<tilpner>
You didn't mention --option builders earlier. Is that something else entirely, or when is it used?
<srhb>
You mentioned that you didn't want to copy back, I think that will always happen when using --builders
<srhb>
And if the path exists locally, nothing will happen on the builder iirc
qknight has quit [Quit: leaving]
<tilpner>
I was hoping --no-build-hook would disable that behaviour
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to master « libbytesize: 1.3 -> 1.4 (#44750) »: https://git.io/fN9AN
<srhb>
Hm, that might be the case, I'm not that knowledgable on the details.
<tilpner>
Oh, maybe that's something else
maerwald has quit [Ping timeout: 268 seconds]
Wharncliffe has joined #nixos
betaboon has joined #nixos
ma27 has joined #nixos
<tilpner>
srhb - The evaluation path of my <nixpkgs> involves a fetchTarball, but I don't see why that would be an issue
aminechikhaoui has joined #nixos
Anton-Latukha has joined #nixos
orivej has joined #nixos
Dedalo has joined #nixos
hakujin has joined #nixos
ma27 has quit [Quit: WeeChat 2.1]
ma27 has joined #nixos
rauno has joined #nixos
simukis has joined #nixos
<sphalerite>
tilpner: yeah this sounds like a case of stuff not being copied over correctly to remote stores
<tilpner>
Yay. So back to scp-ing text files and adjusting paths :/
ma27 has quit [Client Quit]
<sphalerite>
tilpner: it will probably work if you try evaluating it locally first
ma27 has joined #nixos
<tilpner>
No, that doesn't help
hakujin has quit [Ping timeout: 245 seconds]
<sphalerite>
tilpner: the thing is that for IFD (or import-from-fetch*) it tries to access the files on the local machine, but with --store foo it will only download them into the store foo
<tilpner>
shell log: tx0.co/1N
<sphalerite>
tilpner: what if you remove the cache, evaluate it locally, then try building it remotely again?
<tilpner>
By "remove the cache", you mean "rm -rf ~/.cache/nix/tarballs/" on my local machine?
rprije has joined #nixos
<sphalerite>
yes. Although you don't need -f there.
<sphalerite>
tilpner: yes but that's only for chroot stores
<sphalerite>
oh right but then the assertion failure thing is a new bug :p
<tilpner>
The issue title mentioned "alternate stores" :/
<sphalerite>
yeah, see the comments. Basically it's "too hard" to fix for non-chroot stores :p
<tilpner>
I'm aware of "The same problem still exists with ssh-ng though presumably?" "Yes, that's not easy to fix though."
<sphalerite>
right
<tilpner>
But it's still not working even with --store /tmp/nix
<tilpner>
(Though it seems to get further)
<tilpner>
And on the fifth run, it succeeds
<tilpner>
Nothing changed, huh
<tilpner>
sphalerite - So what do you do now? Give up on remote building, or do it manually via ssh?
<MasseR>
I'm thinking of writing a service definition for nixos, but it needs a database. What's the recommended way of making the service file that needs for example psql? (authentication etc.)
<symphorien>
tilpner: remote building with builders instead of remote stores probably works
<tilpner>
Is it? The default for database_user is "matrix-synapse"
<tilpner>
Maybe it's just a buggy module and nobody actually sets database_user
<tilpner>
I think L639 should be { name = cfg.database_user;
<MasseR>
Yeah that could be
<tilpner>
They consistently hard-code "matrix-synapse" all over the place, maybe it was intended and I'm just not seeing why
Maxdamantus has joined #nixos
<tilpner>
Is there any way to tell Nix to not scan an output for dependencies?
<tilpner>
(I can't nuke-refs, I really need store-paths in my output, but the output doesn't depend on them)
<symphorien>
You can zip the output
<rauno>
anyone has had problems with nixops build and The unique option is defined multiple times ?
<{^_^}>
rauno: 10 hours, 45 minutes ago <srk> I've "implemented" a dumb backend for nixops which allows to recover from failures (doesn't use generated keys)
<tilpner>
symphorien - My output is a squashfs containing parts of the nix store, and Nix still finds those paths in it
<rauno>
{^_^}, oh, is this backend code publicly available somewhere ?
<srk>
possibly, check your NIX_PATH and also nix-instantiate --find-file nixpkgs
<symphorien>
tilpner: you can use unsafeDiscardStringContext to remove dependencies
woffs has joined #nixos
<srk>
I've ditched channels completely and just rely on git
alexteves has joined #nixos
<rauno>
i have checkout nixpkgs-channels
ma27 has quit [Quit: WeeChat 2.1]
<rauno>
NIX_PATH=nixkgs=/home/nixops/nixpkgs-channels which seems right but nixpkgs not found :|
<{^_^}>
[nixpkgs] @pSub pushed 10 commits to add-missing-licenses: https://git.io/fNHfp
<srk>
nix(p)kgs
<rauno>
great
v0|d has quit [Remote host closed the connection]
pie_ has joined #nixos
baconicsynergy has joined #nixos
maerwald has joined #nixos
<{^_^}>
[nixpkgs] @pSub pushed 401 commits to add-missing-licenses: https://git.io/fNHJW
<tilpner>
symphorien - I did think of that, but I don't see how to use it here. unsafeDiscard on the squashfs image would remove the image from the runtime closure, when I just want to sever the other dependencies
<Myrl-saki>
lol
<symphorien>
Make a derivation "cp ${unsafeDiscardStringContext image} $out
<srk>
tilpner: 'other dependencies' like what?
<Myrl-saki>
Gotta love those typos. :P
<srk>
:(
* srk
learned hard too many times
<tilpner>
symphorien - But wouldn't it scan the output of that derivation too, and yet again find the paths to nix store and add them as dependencies?
mmercier has joined #nixos
<symphorien>
I think it only looks for derivation inputs
<tilpner>
srk - I build a squashfs from the ghc closure, so I can copy it to a remote server and mount it there in a vm. Nix finds the store paths of ghc in that squashfs, so I end up copying all 2GB to my server
<srk>
interesting
<tilpner>
symphorien - I'll try that
<srk>
maybe I'm hitting something similar with netboots (toplevel is copied for some reason with squashfs images)
arahael1 is now known as ArahaelPi
<srk>
gotta check, wasteful :)
init_6 has quit []
init_6 has joined #nixos
<tilpner>
symphorien - If I do cp ${builtins.unsafeDiscardStringContext drv} $out, it fails with cp: cannot stat '/nix/store/kdb20hx8s4hmmygv17wh8y8imncydp9l-squashfs.img': No such file or directory
<tilpner>
symphorien - Unless I do "inherit drv;", but that adds all the dependencies again
* tilpner
prepares exampel
<srhb>
tilpner: Down that path lay confusion. The string context is usually exactly what ensures that the dependency exists.
alex`` has quit [Quit: WeeChat 2.2]
wgas has joined #nixos
wgas has left #nixos [#nixos]
<tilpner>
srhb - Not Nix scanning the output?
<srhb>
Runtime deps, yeah..
baconicsynergy has quit [Ping timeout: 244 seconds]
<tilpner>
Small testable example: tx0.co/1O
<tilpner>
Ideally I could put allowedReferences = []; in there and have it still work
iyzsong has joined #nixos
<makefu>
tilpner: on a side note, it is not such a good idea to just 'count up' the id in your paste - it may result in the compromise of previously thought private pastes
<tilpner>
makefu - I consider them all public. It's a tradeoff to have them easily pronounceable via voice call
<tilpner>
(It's easy to have another flag to generate longer slugs)
<makefu>
if you have already thought about this trade-off then this is fine of course
<tazjin>
do mergable option types merge with their `default`, or is the default always overridden?
alex`` has joined #nixos
<tilpner>
srk - I suppose walking the input closure and incrementing each hash by one would solve our problem. Everything's still consistent, but no longer matches the store paths
<tilpner>
But I'm not sure if that is possible on the final squashfs, or if it needs to be done on the input. And I wouldn't know how to efficiently do it on the input
<srk>
sounds tricky :)
<srk>
yeah, me neither
<symphorien>
tilpner: I see that there is a builtins.unsafeDiscardOutputDependency (undocumented of course)
<rauno>
hum, about this "multiple defined option", when i add same users to two nixops machines, then it starts to complain somewhy ?!
Wharncliffe has quit [Quit: Lost terminal]
<otini>
srhb: The weird thing with the code I've cross-compiled is that the debug symbols are in DWARF version 2 format. And passing -gdwarf-4 to gcc doesn't change anything…
<otini>
srhb: is this weird stuff due to gcc-wrapper?
<srhb>
otini: I don't know, I've never been that deep into c builds. :)
<srhb>
otini: how do you tell what format they're in?
<symphorien>
tilpner: mmh I was wrong, nix scans for dependencies even on paths which were not inputs
<otini>
srhb: I run `llvm-dwarfdump -debug-info result/test`
<srhb>
otini: Ah, thanks
<otini>
and in the header description there is something like: version 0x002
nD5Xjz_ has joined #nixos
nD5Xjz has quit [Ping timeout: 256 seconds]
<symphorien>
hum no actually it does not
sir_guy_carleton has joined #nixos
ma27 has joined #nixos
otini has left #nixos ["WeeChat 2.2"]
Dedalo has joined #nixos
otini has joined #nixos
rprije has quit [Ping timeout: 240 seconds]
<{^_^}>
[nixpkgs] @Izorkin opened pull request #44815 → libtiff: update url to patch file → https://git.io/fNHYe
ixxie has joined #nixos
davenpcm has joined #nixos
<tilpner>
__monty__ - Yes, words would also be acceptable. Though then you need to know the native language of the recipient, and I guess it's slightly more effort to implement
<tilpner>
(Which... yes, you usually do in voice calls)
<tilpner>
symphorien - It does not? How did you come to that conclusion?
<tilpner>
symphorien - "Sometimes we want to pass a derivation path (i.e. pkg.drvPath) to a builder without causing the derivation to be built (for instance, in the derivation that builds NARs in nix-push, when doing source-only deployment). This primop marks the string context so that builtins.derivation adds the path to drv.inputSrcs rather than drv.inputDrvs."
<tilpner>
^ doc for unsafeDiscardOutputDependency
<__monty__>
tilpner: Could make the url work regardless of the language used I guess, just have to be careful selecting the words so there's no ambiguity. I'm thinking of having both "cat" and "chat" map to `cat` or `5` for lookup.
silver_ has joined #nixos
<tilpner>
Yeah, but that takes more effort than I wanted to invest. Maybe when this solution breaks/gets rewritten :)
<symphorien>
it relies on having a copy of bsdgames with no common deps with your squash image
<tilpner>
Oh god
<ixxie>
Not sure the problem is on the NixOS side, but connecting my android phone to my NixOS laptop doesn't trigger the usual menu asking if I want to grant access to the data
<tilpner>
I... uhm, this wouldn't work with derivations depending on 32-bit glibc, right?
<gchristensen>
what is in these ./config/test-???.nix files?
<rauno>
network conf and env packages
<gchristensen>
if you comment out this line: imports = [ (./config + "/test-cn-${toString (id+1)}.nix") ./config/users.nix ]; does `nixops deploy --build-only` still error?
mayhewluke has joined #nixos
Henson has joined #nixos
trcc has quit [Ping timeout: 255 seconds]
Fare has quit [Ping timeout: 260 seconds]
barchibald has joined #nixos
<rauno>
ahh, sftp sync had double-played me, actually everything was ok with code >.<
kiloreux has quit [Ping timeout: 240 seconds]
<gchristensen>
aye
ixxie has joined #nixos
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
<mikeplus64>
very dumb question. i want a derivation that just copies a folder to $out. is the recommended/idiomatic way to do this just `mkDerivation { ...; src = ./x; installPhase = "cp x $out"; }`?
<tilpner>
Rather buildCommand = ''cp -r $src $out''
<gchristensen>
but also no need!
<gchristensen>
./x is as good as mkDerivation { ...; src = ./x; installPhase = "cp $src $out"; } for almost everything you could possibly want to use it for
<tilpner>
Yes, if it's just that
<mikeplus64>
ahhhhhh
Ariakenom has quit [Quit: Leaving]
kiloreux has joined #nixos
<clever>
only place it doesnt work at is as a direct target of nix-build
Anton-Latukha has quit [Quit: Leaving.]
<gchristensen>
probably should work there, too
Anton-Latukha has joined #nixos
<clever>
nix-build -E './.'
<clever>
error: expression does not evaluate to a derivation (or a set or list of those)
<gchristensen>
I know it doesn't but I think it probably _should_ :)
<clever>
i agree
<clever>
i also cant nix-build a builtins.fetchTarball
<clever>
so i have to throw in IFD and symlink the $out to the dir
reinzelmann has quit [Quit: Leaving]
<clever>
that has caused a hydra eval to take 2 hours before, because it has to build gcc just to symlink nixpkgs
<gchristensen>
lol.
<clever>
hydra is also not aware of the IFD dependencies, and wont create GC roots to protect them
<clever>
so it can even GC that gcc, and wind up in the same place
<clever>
but the jobs typicaly also depend on it indirectly
<mikeplus64>
what's the idiom, if any, for a "bundle" derivation that just merges the outputs of some sub-derivations? atm i have `installPhase = ''mkdir -p $out; cp -r "${foo}/*" $out; cp -r "${bar}/*" $out; cp -r "${baz}/*" $out''`
<clever>
buildEnv
barchibald has quit [Ping timeout: 255 seconds]
<mikeplus64>
ah thanks
<symphorien>
or symlinkJoin
orbekk has joined #nixos
Ariakenom has joined #nixos
mickours has quit [Quit: mickours]
<gchristensen>
hmmm so clever when you make a disk image for a system, Nix thinks it depends on a load of paths inside due to grep. right?
hyper_ch2 has quit [Quit: Page closed]
<clever>
gchristensen: yeah
<tilpner>
gchristensen - I'm currently building a workaround for that (idea by symphorien) (it's just rot26)
<clever>
gchristensen: compression of the image is the only way to break the link
<tilpner>
clever - You don't happen to have any better ideas (than rot13 (rot13 image)) to transfer a squashfs of the ghc closure without transferring ghc uncompressed?
baconicsynergy has joined #nixos
<tilpner>
(Deploying to NixOS by copying closure stops being fun when your upload reaches 100kb/s)
<clever>
tilpner: dont depend on ghc at all
<tilpner>
clever - How do I create a squashfs from ghc without depending on ghc?
<clever>
tilpner: if you build your haskell program with haskell.lib.justStaticExecutables then it wont depend on ghc
<{^_^}>
[cabal2nix] @cdepillabout opened pull request #368 → Add override for the vte system library → https://git.io/fNH4r
<clever>
and then ghc wont be in the squashfs at all
<tilpner>
Heh, but I actually want ghc
<tilpner>
The program isn't known until after build-time
<Henson>
good morning everyone. I have a question about Python package building, specifically the python27Packages.Nuitka derivation in nixpkgs described in the file nixpkgs/pkgs/top-level/python-packages.nix. There seems to be an error in the wrapping of this that is causing problems. The "nuitka" script in the Nix version is renamed to ".nuitka-wrapped" and has a new import line added to the top...
<tilpner>
Yeah, that won't work. At least not with lz4
<Henson>
that is causing the problem. Does anybody know what part of the derivation would be adding this new import line, and how I could go about fixing it?
<clever>
tilpner: why not?
<tilpner>
clever - Nix finds the ghc store path while scanning the compressed squashfs
<clever>
tilpner: why does this need to be inside a squashfs?
<clever>
tilpner: if you didnt have the squashfs, then the remote machine can grab ghc from cache.nixos.org and ignore your upload
<tilpner>
clever - Mounting the squashfs with -drive format=raw is faster than letting virtfs use the hosts ghc
<clever>
ah
<clever>
tilpner: and why is this running under qemu?
<tilpner>
Because it's running completely untrusted code
<clever>
ah
<tilpner>
But I was just checking if you had a better solution at hand. I'll try the double-bitflip hack for now :)
<clever>
another thought is to generate the squashfs on the remote machine
hiroshi has quit [Ping timeout: 240 seconds]
<clever>
so you have a closure in the host store, and it can use the nixos cache, then at service startup, it generates the squashfs
<tilpner>
I tried that too, but I couldn't figure out how to do remote builds
<clever>
just run nix-build inside the prestart script
<tilpner>
But then I need all the .nix files on there too :/
<clever>
not so
<clever>
it could just be a 1 line script like what i pasted above
<makefu>
maybe it is not yet enabled in your currently running kernel
simukis has quit [Quit: simukis]
<{^_^}>
[nixpkgs] @imalsogreg opened pull request #44819 → aws-okta: init at 0.19.0 → https://git.io/fNHET
erasmas has joined #nixos
ryanartecona has joined #nixos
vmandela has quit [Quit: Leaving]
<sigtrm>
So I don't need to add wireguard to systemPackages and extraModulePackages?
<sigtrm>
I am rebooting as we speak so we shall see if it works
endformationage has joined #nixos
<makefu>
sigtrm: yes you should not need the extraModulePackages but it should also not hurt
<sigtrm>
Well I have commented it out, rebooted and now rebuilding, it takes time though so we'll see
Fare has quit [Read error: Connection reset by peer]
<sigtrm>
Hey! A reboot seems to have done it
<sigtrm>
If this works now then I am basically on distro nr 4 and finally gotten wireguard working
Fare has joined #nixos
<makefu>
great to hear
dbmikus has joined #nixos
<__monty__>
sigtrm: I think I have wireguard working on arch. Can't remember any difficulty.
<sigtrm>
I haven't tried arch
<sigtrm>
I tried Alpine and Void, plus another one I can't remember right now
Fare has quit [Ping timeout: 240 seconds]
<sigtrm>
But this is on a rpi so it's more finicky
<__monty__>
Ah, my mistake for assuming. Oh, not a fan of popular distros? : p
rouma has joined #nixos
<sigtrm>
Actully I really wanted a distro that uses musl
<sigtrm>
I used to use Arch on my laptop and Debian on my desktop so I am quite fond of them
<sigtrm>
But for the rpi I really wanted something that used musl, and both Alpine and Void supports wireguard on aarch64, just couldn't get it working
waynr has left #nixos ["WeeChat 2.0-dev"]
<sigtrm>
Though I am happy I gave NixOS a chance, I am enjoying it very much
<gchristensen>
w00t
nwspk has quit [Quit: Quit: *.banana *.split]
Fare has joined #nixos
<sigtrm>
Any chances of making NixOS only use musl?
nwspk has joined #nixos
<tilpner>
... Nooooo, I didn't pass --all to nix why-depends
<tilpner>
I removed the reference from the squashfs, but that wasn't the only place
<Henson>
is there a helper function to adjust the rpaths of executables and libraries for converting a .deb file or some other binary installation into a nix package?
<Henson>
I also figured out the problem with Nuitka. It should have "dontWrapPythonPrograms = true" in its buildPythonPackage arguments. Is this something that should be incorporated into nixpkgs-unstable?
<{^_^}>
[nixpkgs] @michaelpj opened pull request #44820 → redshift/geoclue/localtime: progress in fixing agent confusion → https://git.io/fNH23
<cocreature>
sigtrm: there is some integration with musl https://github.com/NixOS/nixpkgs/pull/34645 but I’m not sure if it’s sufficient to run a full nixos installation as opposed to cross compiling individual packages using musl (also I haven’t tried it personally :))
<Henson>
is there a way to find out which package in nixpkgs contains a certain file? I'm trying to figure out what derivation to include in a call to nix-shell --pure to be able to see libstdc++.so.6
<clever>
,locate libstdc++.so
<{^_^}>
Found in packages: androidndk, gcc-unwrapped.lib, mentorToolchains.armLinuxGnuEabi
halfbit has joined #nixos
<symphorien>
Henson: nix-index is a tool to do this
init_6 has quit [Ping timeout: 240 seconds]
Ariakenom has quit [Ping timeout: 244 seconds]
<Henson>
clever, symphorien: thank you
Ariakenom has joined #nixos
qgwen has quit [Quit: Leaving]
Henson is now known as Henson_lunch
halfbit has quit [Ping timeout: 265 seconds]
<tilpner>
symphorien, srk, gchristensen - There now is nur.repos.tilpner.bitflip.flipTwice if you ever need to clean a disk image of dependencies
nschoe has quit [Remote host closed the connection]
disasm has joined #nixos
nwspk has quit [Quit: Quit: *.banana *.split]
nwspk has joined #nixos
selfsymmetric-pa has quit [Remote host closed the connection]
<tilpner>
It reduced my closure from 2.8G to 922M, but it's probably brittle and costs your disk space
phreedom has joined #nixos
johanot has quit [Quit: Lost terminal]
phreedom_ has quit [Ping timeout: 250 seconds]
ma27 has quit [Quit: WeeChat 2.1]
johnw has quit [Ping timeout: 244 seconds]
__monty__ has quit [Quit: leaving]
orivej has quit [Ping timeout: 268 seconds]
rouma has quit [Remote host closed the connection]
rouma has joined #nixos
__Sander__ has quit [Quit: Konversation terminated!]
<gchristensen>
oy, joepie91, you here?
nwspk has quit [Quit: Quit: *.banana *.split]
nwspk has joined #nixos
ryanartecona has quit [Quit: ryanartecona]
Fare has quit [Ping timeout: 256 seconds]
selfsymmetric-pa has joined #nixos
pie_ has quit [Ping timeout: 244 seconds]
joedevivo has joined #nixos
rouma has quit [Ping timeout: 244 seconds]
vmandela has joined #nixos
<infinisil>
Oh boy 780PR's again..
<infinisil>
I see r-ryantm has ran again :)
<Izorkin>
Qemu-guest agent not work shutdown from host system - error "child process has failed to shutdown"
<Izorkin>
how to fix?
rouma has joined #nixos
nwspk has quit [Quit: Quit: *.banana *.split]
freeman42x]NixOS has joined #nixos
nwspk has joined #nixos
mmercier has joined #nixos
Drakonis has joined #nixos
vandenoever has quit [Ping timeout: 244 seconds]
mickours has quit [Ping timeout: 260 seconds]
<sigtrm>
Thank you cocreature, I guess I will wait until there is more support for musl before trying to run a full NixOS install with musl, if I have understood completely once it's ready all I will have to do is make a change to my configuration.nix file and on the next rebuild it will just replace everything with the musl version, have I understood correctly?
<cocreature>
sigtrm: at least that matches my understanding
vmandela has quit [Read error: Connection reset by peer]
<sigtrm>
Great, the thing I like about NixOS so far is that if I ever want to change something like that I only need to make changes to some files, it's really nice
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to staging « libdrm: 2.4.92 -> 2.4.93 (#44759) »: https://git.io/fNH1f
<mightybyte>
When I build and test my Haskell app with `time nix-shell -A shells.ghc --run "cabal clean && cabal test"`, it takes ~5 min. When I do `time nix-build` it takes like 15+ min. Anyone have any idea what might be going on?
<mightybyte>
It's specifically running the test suite that takes way longer.
<elvishjerricco>
mightybyte: What does your test suite do?
<mightybyte>
I does a good bit of parallel stuff.
<mightybyte>
Forks several threads
<elvishjerricco>
mightybyte: Hm. Watch your CPUs, see if it looks like `cabal test` is using more cores than `nix-build`
<mightybyte>
Yeah. I looked in nixpkgs at generic-builder.nix to figure out that I should try that.
<mightybyte>
Yep...working on that now.
hakujin1 has joined #nixos
ryanartecona has joined #nixos
vmandela_ has joined #nixos
<{^_^}>
[nixpkgs] @yegortimoshenko opened pull request #44824 → prometheus-node-exporter: work around prometheus/node_exporter#870 → https://git.io/fNHMf
<fresheyeball>
I think that should be state verion agnostic no?
<samueldr>
fresheyeball: try sudo -iu instead of sudo -u ?
<elvishjerricco>
fresheyeball: Yea, but if your pg db was created with stateVersion == 17.09, and you've since changed it to 18.03, it'll be inconsistent
<elvishjerricco>
i.e. the pg db will have a root role, but not a postgres role, and having stateVersion == 18.03 will set pg.superUser == postgres
<elvishjerricco>
but stateVersion == 17.09 means pg.superUser = root
<mpickering>
symphorien: I don't understand how that works but it looks more complicated than necessary
<clever>
elvishjerricco: i also recently got surprised by a recent accidental change of stateVersion, the datadir for postgres now contains the version#
<clever>
and as a result, all data just vanished
<fresheyeball>
elvishjerricco: this is a nixops deployment
<elvishjerricco>
clever: Whoa
<elvishjerricco>
Does nixops handle stateVersion for you?
jmiven has quit [Quit: co'o]
<clever>
elvishjerricco: changing the stateVersion back restored the old datadir, and the whole db
<clever>
elvishjerricco: yeah
<fresheyeball>
I am building on a machine with state version 17.03
ma27 has quit [Client Quit]
<elvishjerricco>
So unless the machine was originally provisioned by something other than nixops, this shouldn't be the problem
<fresheyeball>
is there a way to ask what roles exist?
<fresheyeball>
the machine I am building with is stateVersion 17.03 but OS version 18.03
<fresheyeball>
clever: I dont think that is my problem, since I am just trying to setup a new db
<clever>
fresheyeball: ah
<elvishjerricco>
fresheyeball: So pg.superUser == root, right? So you're doing `sudo -u root psql -U root`? That sounds like it ought to work.
<selfsymmetric-pa>
I'm having trouble with my NIX_PATH again. `warning: Nix search path entry '~/foo/configuration.nix'` even though my NIX_PATH has `nixos-config=~/foo/nixos/configuration.nix`.
<selfsymmetric-pa>
Does NixOS strip "nixos" from paths?
<gchristensen>
~ isn't resolved
<fresheyeball>
samueldr: sounds like you know the problem! can you explain, because obviously I dont get it
<elvishjerricco>
samueldr: Oh, that makes sense
<fresheyeball>
SPLAIN!
<fresheyeball>
I must understand this issue!
<elvishjerricco>
fresheyeball: Try adding `local all all ident` to the authentication stuff
hakujin2 has joined #nixos
<fresheyeball>
elvishjerricco: in addition to `local all all trust`?
<elvishjerricco>
fresheyeball: Maybe... Or you could comment out your whole authentication thing and let the nixos default be used, which includes that line
<elvishjerricco>
the ident line, not the trust lie
<elvishjerricco>
line*
<selfsymmetric-pa>
gchristensen: Using `/home/user` gives the same error.
<selfsymmetric-pa>
Can I override to point to a specific `configuration.nix`?
<ij>
Should I generate that configuration.nix for nixos on DO for use with nixos-infect with nixos-generate-config, as usual?
<clever>
selfsymmetric-pa: what does `echo $NIX_PATH` say?
<selfsymmetric-pa>
This is `sudo nixos-rebuild switch --upgrade`.
<mightybyte>
elvishjerricco: Ugh...the RTS flags are the same
<clever>
selfsymmetric-pa: what about `sudo -i` then `nixos-rebuild switch` ?
Dedalo has joined #nixos
<selfsymmetric-pa>
clever: same.
<selfsymmetric-pa>
And setting $NIXOS_CONFIG doesn't work either.
<selfsymmetric-pa>
Oh but when I'm in `sudo -i` the NIX_PATH is wrong.
<clever>
yeah
<selfsymmetric-pa>
So I gotta make sure they're in sync.
<elvishjerricco>
mightybyte: Darn. Even parFlags { nCapabilities }?
<clever>
selfsymmetric-pa: sudo will mess with env vars
<elvishjerricco>
What is that value, actually?
<selfsymmetric-pa>
Okay I think I'm good now. Thank you!
<mightybyte>
Oh, parFlags isn't in there.
<elvishjerricco>
wut
<mightybyte>
Maybe I printed the wrong one
<elvishjerricco>
mightybyte: ParFlags says `Since: base-4.8.0.0` in the haddocks
<Henson>
does anyone have any suggestions as to how I can get libstdc++.so.6 included in a "nix-shell --pure" environment? I can see that libstdc++.so.6 is in /nix/store/*-gcc-7.3.0-lib" which is referred to by the gcc-7.3.0 package which is nixpkgs.gcc-unwrapped, but when I include that as a list of derivations to include in the nix-shell environment, it isn't found by an executable that wants it.
<Henson>
I seem to recall encountering this problem many months ago, and I needed to include ".lib" after the package name, or something unusual.
<Henson>
not this exact problem, but something similar, rather.
<symphorien>
hum it is in the default stdenv
<elvishjerricco>
Henson: What are you building that's not finding libstdc++?
<symphorien>
you shouldn't have to add any argument to nix-shell
<elvishjerricco>
Does he need to use g++ instead of gcc?
<Henson>
elvishjerricco: it's a 3rd party binary library that I'm trying to repackage into a NIX package. It's also to find librt, libdl, libgcc, and several others in the appropriate /nix/store path, but not libstdc++.so.6
vmandela has quit [Ping timeout: 240 seconds]
<symphorien>
are you building from source ?
<Henson>
elvishjerricco: I also can't use "ldconfig -p" to tell me the search path it's using, because it complains about /nix/store/v7hg431d55q30gy7hqlpiji3jnvi8gs3-glibc-2.27/etc/ld.so.cache not existing, but presumably because it's able to find the shared libraries it should have a nix library search path somewhere.
johnw has joined #nixos
<srk>
Henson: I've managed like this last time --set-rpath $cur_rpath:${makeLibraryPath [ libGL libX11 libXrandr libXcursor stdenv.cc.cc.lib ]} $out/${exe}
<Henson>
symphorien: no, it's a closed source executable that I'm trying to unpack from a TGZ file and then repack into a NIX file. I realize I'll probably have to adjust the rpaths of the libraries and executables, and am hoping that nix-shell will help me figure out which ones need to be adjusted. But if the appropriate library directories are brought into scope, I may not have to adjust anything.
<selfsymmetric-pa>
Does anybody have success running isync as a home-manager service?
<selfsymmetric-pa>
I have just been running it as an Emacs idle loop.
<selfsymmetric-pa>
Since cron can't find gpg2, and I think home-manager doesn't have enough auth options.
<selfsymmetric-pa>
Running it as an Emacs idle loop works perfectly but feels a bit like a hack.
<elvishjerricco>
Henson: Ah, I think I see the problem. Adding a lib to your build inputs doesn't add it to anything like `LD_LIBRARY_PATH`.
<elvishjerricco>
You will have to patchelf the thing to use the libs from the nix store, or else use `LD_LIBRARY_PATH` (which is considered bad practice)
<Henson>
elvishjerricco: not that I can see. Within my nix-shell I don't even have a LD_LIBRARY_PATH variable defined.
<elvishjerricco>
Henson: Right. The only way the exe would pick it up automatically would be if it were in the LD_LIBRARY_PATH, but Nixpkgs avoids that in favor of patchelf
<Henson>
elvishjerricco: that's what I thought, but I didn't have to patch it to find the other nix libraries it was able to somehow locate.
<elvishjerricco>
Oh, that is odd...
<elvishjerricco>
Henson: How do you know it located those?
<Henson>
elvishjerricco: no, since ldconfig doesn't work, I don't know how to determine how it did that.
<elvishjerricco>
Henson: I'm not asking how it did locate them. I'm asking why you think it did
<elvishjerricco>
er
<elvishjerricco>
I'm asking what makes you say that it did locate them at all, regardless of how
ng0 has quit [Quit: Alexa, when is the end of world?]
betaboon has quit [Quit: WeeChat 2.1]
<Henson>
elvishjerricco: ahh, I understand what you're asking. Because, when I type "ldd executable_name" it shows me several lines like: libm.so.6 => /nix/store/v7hg431d55q30gy7hqlpiji3jnvi8gs3-glibc-2.27/lib/libm.so.6 (0x00007fd71fa94000)
<elvishjerricco>
Got it. Huh
<elvishjerricco>
Yea I'm not sure then
<Henson>
elvishjerricco: ok. So, I guess the proper thing to do would be to track down all of the shared libraries it uses, then use rpath to tell it to use exactly the versions I want it to use?
<fresheyeball>
elvishjerricco: samueldr ok so you two where right
<fresheyeball>
that auth setting was causing the problem
<fresheyeball>
removing it entirely works just fine
<elvishjerricco>
Henson: I'm thinking that maybe those libs it did find are special for some reason...
<elvishjerricco>
fresheyeball: Cool
<fresheyeball>
now I get psql: could not connect to server: No such file or directory haha
<clever>
fresheyeball: is the process running?
<symphorien>
what does this mean: error: cannot convert a thunk to JSON ?
<clever>
symphorien: try builtins.toJSON instead of --json
<clever>
symphorien: also, try adding --strict
<symphorien>
hum this works
<clever>
what about --strict --json ?
<symphorien>
but everything is quoted
<hyper_ch>
so, got my Tuxedo notebook with 32gb ram... added now my sata ssd and my m2 ssd.... removed that ARC limit for zfs since I should have plenty of ram now for 1-2 VMs :)(
<pie_>
i feel like kde has a lot of minor really annoying issues on nixos
<pie_>
is it just nixos or everywhere?
<pie_>
for some reason firefox has 20 audio sliders and im pretty sure i dont have that many youtube tabs open (not 100% sure) and it keeps pulling my volume lower
<pie_>
ive had other annoying things too but i cant remember off the top of my head
linuxdaemon has joined #nixos
<pie_>
oh yeah, hald the time the little task bar popup thing breaks so that the popup doesnt actually show up and i have to restart plasmashell to get it working again
<mightybyte>
elvishjerricco: Weird. I'm on base 4.9
<{^_^}>
[nixpkgs] @veprbl opened pull request #44833 → img2pdf init at 0.3.1 → https://git.io/fNHAQ
<pie_>
*half the time
mkoenig has quit [Remote host closed the connection]
<infinisil>
The package I'm building right now requires a couple NIX_CFLAGS_COMPILE: "-Wno-error=int-to-pointer-cast" "-Wno-error=pointer-to-int-cast" "-Wno-error=incompatible-pointer-types"
<infinisil>
Only on 32bit though
reinzelmann has quit [Ping timeout: 268 seconds]
<infinisil>
Is this okay?
sigmundv has joined #nixos
ryanartecona has joined #nixos
reinzelmann has joined #nixos
reinzelmann has quit [Client Quit]
<infinisil>
Sounds good to me :)
<{^_^}>
[nixpkgs] @Infinisil pushed to master « trinity: 2017-02-13 -> 2018-06-08, fix build, clean up »: https://git.io/fNHpR
<{^_^}>
[nixpkgs] @vcunat merged pull request #44575 → mesa: add patch to include driver path in cache key → https://git.io/fNM35
Mateon3 has joined #nixos
<mightybyte>
elvishjerricco: Well since I can't print the parFlags...let's just assume that it's only running with one capability. How can I change that?
<elvishjerricco>
Alright. Yea that should be ok then. The only other thing I can think of is cabal's choice of optimization level. Cabal choose a `-O<n>` profile of some sort, and I don't know whether or not it overrides any `-O<n>` in your cabal file's `ghc-options`. If it does, then a higher optimization level might actually cause less things to parallelize since GHC makes attempts to share evaluations sometimes.
bennofs has quit [Quit: WeeChat 2.0]
<elvishjerricco>
i.e. try the `nix-shell` build with `cabal test -O2`
<elvishjerricco>
mightybyte: ^
_cyril_ has quit [Ping timeout: 248 seconds]
<mightybyte>
We have -O3 specified in the ghc-options of every stanza in the cabal file.
<mightybyte>
...including the test suite stanza
<srhb>
There's an O3 now?
<mightybyte>
Yes
ashkitte1 is now known as ashkitten
ng0 has joined #nixos
_cyril_ has joined #nixos
fresheyeball has joined #nixos
<fresheyeball>
so I am trying to add toxiproxy-haskell to a ghc843 project
<fresheyeball>
and it depends on servant
<fresheyeball>
which depends on doctest
<fresheyeball>
which is 0.16 on haskell.packages.ghc843.doctest
<fresheyeball>
but servatnt needs <0.16
<fresheyeball>
so I did an override with lib.callHackage to get 0.15.1
<fresheyeball>
for doctest
<fresheyeball>
but it hits infinite recursion in callCabal2Nix, because it depends on itself
<fresheyeball>
now I am at a loss
<fresheyeball>
how can I get doctest 0.15.1 in my overlay without hitting infinite recursion?
<elvishjerricco>
mightybyte: I believe -O3 is sugar for -O2. Anyway, that's exactly what I'm talking about though; I don't know if cabal's default `-O1` CLI arg overrides anything in your cabal file
<elvishjerricco>
If it does, then the lower optimization level may be allowing more parallelism
<fresheyeball>
elvishjerricco: are you two still trying to get tests to run mutlicore?
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to master « virt-viewer: 6.0 -> 7.0 (#44666) »: https://git.io/fNQfJ
das_j has joined #nixos
<elvishjerricco>
fresheyeball: Well, it's "working" in principle. i.e. we have confirmed that `getNumCapabilities` is returning 8.
<elvishjerricco>
But for some reason the code is only spiking one CPU core
<mightybyte>
elvishjerricco: Oh...I just realized that my info on the capabilities may have been wrong since the output was sent to a file and nix-build sandboxes things. Let me check that again.
<elvishjerricco>
but only when building with `nix-build`. Building with `nix-shell --run "cabal test"` spikes 8 CPUs
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to master « mysql57: 5.7.22 -> 5.7.23 (#44740) »: https://git.io/fNQfm
<das_j>
Hey, I'm using systemd.services.<name>.startAt, but the timer unit doesn't show up in systemctl list-timers. Do I need to set other variables for that to work?
<fresheyeball>
elvishjerricco: how long do the tests take?
<fresheyeball>
could it be that ghc runtime just says we dont need more cores?
<elvishjerricco>
mightybyte said it's like 5min with the cabal build and 15+min with the nix build
<elvishjerricco>
fresheyeball: My thinking (assuming mightybyte comes back saying getNumCapabilities did in fact return 8) is that optimization is causing some thunks to be factored out of threads
mayhewluke has quit [Ping timeout: 244 seconds]
phreedom_ has joined #nixos
<fresheyeball>
could it be that the test code does not explicitly say to run in par?
<{^_^}>
[nixpkgs] @pSub pushed 5 commits to add-missing-licenses: https://git.io/fNQf8
<mightybyte>
hspec
<elvishjerricco>
I think he's using forkIO
<elvishjerricco>
but the work you'd hope to be done in parallel may be pure work rather than IO work, which GHC can factor out
phreedom has quit [Ping timeout: 250 seconds]
ng0 has quit [Quit: Alexa, when is the end of world?]
<elvishjerricco>
I forget which optimization that is... let floating? full laziness?
<mightybyte>
There's a lot of parallelism going on.
<elvishjerricco>
fresheyeball: I'm not sure that matters too much. They're the same between the nix build and the cabal build.
<mightybyte>
That's specified on the test suite in the cabal file.
mayhewluke has joined #nixos
<elvishjerricco>
and yet the nix build is the one that's serial
<mightybyte>
But yes, it doesn't seem like that should be it
<elvishjerricco>
mightybyte: Did you confirm the actual value of getNumCapabilities?
<tobiasBora>
clever: Sorry I missed your last message yesterday. If I've another machine with root on it, what can I do to have my nix store on a usb stick on a computer on which I'm not root?
<mightybyte>
elvishjerricco: Working on it. I just get detoured becuase it didn't have permissions to write to the file that I was writing to.
<elvishjerricco>
mightybyte: Just print it on stdout and check `nix log` for it :P
<tobiasBora>
elvishjerricco: I'm running the command right now, for now it seems to work, but it copies lot's of stuff from my real /nix to my --store folder. Is it normal?
<{^_^}>
[nixpkgs] @Izorkin opened pull request #44836 → qemu: update version and fix working guest-shutdown → https://git.io/fNQfQ
<elvishjerricco>
tobiasBora: that's expected
<tobiasBora>
elvishjerricco: oh really? Funny.
<tobiasBora>
Now, it stops doing that, but it says "copying path '/nix/store/3v92wp5bfdwpsdjgc0vjaz4y3wagf9dx-systemd-238-dev' from 'https://cache.nixos.org'...
<elvishjerricco>
tobiasBora: Yea, using a program in any store expects all its runtime deps to be in the same store. Nix has a one-store mind-set, but can download things from other stores
<elvishjerricco>
Not sure how it chooses between the available substituter stores.
<mightybyte>
elvishjerricco: I can't print it to stdout. The test suite's stdout goes to a file.
<fresheyeball>
mightybyte: shot in the dark
<mightybyte>
...in the sandbox
<elvishjerricco>
mightybyte: stderr too?
<fresheyeball>
but can you try putting quotes around -with-rtsops?
<tobiasBora>
elvishjerricco: ok, so here it seems that copying path '/nix/store/3v92wp5bfdwpsdjgc0vjaz4y3wagf9dx-systemd-238-dev'
<tobiasBora>
elvishjerricco: ok I understand everything now. I ran nix-build vm_build.nix --store local?root=/tmp/nix_test/store --option substituters 'auto https://cache.nixos.org'
<elvishjerricco>
mightybyte: How? If its not in the build log, how are you writing it to a file that doesn't get destroyed?'
<mightybyte>
I'm writing to an absolute path.
<fresheyeball>
elvishjerricco: are you saying if you build in a cabal sandbox outside of nix it works? but doing it with nix fails?
<tobiasBora>
elvishjerricco: and why can't nix do links to local instead of doing hard copy?
<mightybyte>
i.e. /tmp/my-log
<elvishjerricco>
mightybyte: Ah. Impurity. Got it :P
<dhess>
fresheyeball: damn you, I just now hit the exact same cabal2nix issue!
<dhess>
mine is with hpack
<fresheyeball>
dhess: muahahaha
<elvishjerricco>
tobiasBora: It's just thinking in terms of "these are stores. I want data." It's not smart enough to think in terms of links
barchibald has quit [Remote host closed the connection]
<mightybyte>
fresheyeball: Can you paste your nix file? I think I've seen that before but I need to look at actual code to job my memory.
<elvishjerricco>
fresheyeball: He's using `nix-shell` to get an environment with all his haskell deps, and running `cabal test` in there
<elvishjerricco>
For some reason that works, but the `nix-build` doesn't
<tobiasBora>
elvishjerricco: in theory, it could be made clever_ and use links instead of hard copy, or is there any reason for this?
<fresheyeball>
elvishjerricco: oic, so it works in nix-shell, but nix-build is single threading? correct?
<elvishjerricco>
tobiasBora: I'm not sure it'd be desirable. A lot of people use these stores for copying things to other disks to be moved around.
<elvishjerricco>
fresheyeball: Yea
<mightybyte>
We are hypothesizing that nix-build is single-threading.
<mightybyte>
It just takes WAY longer.
<elvishjerricco>
So the only perceivable difference as far as I can tell is the use of cabal
<tobiasBora>
elvishjerricco: maybe not as default then
<elvishjerricco>
mightybyte: I thought you confirmed only one CPU core is spiking?
<mightybyte>
elvishjerricco: Yes, but here's the weird thing...I'm in the big long waiting phase now. But the log I wrote makes it look like the test suite actually finished running.
<fresheyeball>
mightybyte: can you post the nix expression for nix-build?
<tobiasBora>
elvishjerricco: in my case it would be quite usefull to avoid to overpopulate the real /nix
<elvishjerricco>
tobiasBora: The other thing is that it just breaks the abstraction. Each store is not supposed to care about what kind of store any other store is. So when we copy from store A to store B, we're not supposed to care what their types are. Making them symlink requires doing special casing on both at once
<mightybyte>
Here's the last output on my `nix-build` console right now:
<mightybyte>
Linking dist/build/hspec/hspec ...
<mightybyte>
running tests
<mightybyte>
Running 1 test suites...
<mightybyte>
Test suite hspec: RUNNING...
<mightybyte>
Here's a gist with the contents of my debug file
<elvishjerricco>
mightybyte: One thing I'm confused about... why is your stdout being piped to a file? generic-builder doesn't do that by default
<mightybyte>
cabal test does that.
<elvishjerricco>
Really? That's dumb
<mightybyte>
I'm getting output, just not the test suite output.
<mightybyte>
Look at that gist. The "Done" messages happen after the last spec line
<elvishjerricco>
I don't really understand the contents of that gist.
<elvishjerricco>
The timestamps look like everything is happening in less than a second?
<mightybyte>
Yeah!
<mightybyte>
And now the binary is just sitting there!
<fresheyeball>
mightybyte: oooooh
<dhess>
fresheyeball: in my case, I serialized the Nix file for hpack-0.29.6 with `cabal2nix cabal://hpack-0.29.6 > hpack.nix`, and then I `callPackage ./hpack.nix` from haskellPackages.extend. Hacky but it resolves the immediate issue.
<mightybyte>
...or maybe not even the binary. Maybe it's nix that is just sitting around doing who knows what.
<fresheyeball>
dhess: this turned out to be more painful than that
<mightybyte>
Boom, it just finished. nix-build 1.69s user 2.33s system 0% cpu 13:56.35 total
<elvishjerricco>
mightybyte: Keep in mind that measuring the time of the `nix-build` command itself is not useful
<fresheyeball>
toxiproxy-haskell has no version bounds on servant, and even jailbreaked
<elvishjerricco>
That does not include the user or system time of the actual build processes
<mightybyte>
elvishjerricco: I don't really care. I only care about the wall clock time. 5 min vs 13 min
<elvishjerricco>
mightybyte: Right. Just saying the 1.69s user doesn't matter
<mightybyte>
Right. I'm not paying attention to that.
<tobiasBora>
elvishjerricco: Well in this case store A do not need to care about store B after copy/linking (and during copying, we can't avoid to know which kind of store it's). Once it's copied, store A is "independent", and it just appears that some of his folders are soft links.
wrl has joined #nixos
<elvishjerricco>
tobiasBora: But the nix process has to care about the types of both. It can't use the same operation as every other store combination to do what you want; it has to check if A and B are both local and choose a completely different process. It just breaks the abstraction
<mightybyte>
elvishjerricco: The reason I put all those intermediate timestamps in the output was so that I could narrow down what was taking a long time. But it's starting to look like it's not the test suite itself. It's something that nix-build is doing.
<tobiasBora>
elvishjerricco: you mean during copy?
<elvishjerricco>
mightybyte: I'm not sure about that. I'd have to see more code, but if it's nix-build's fault, we wouldn't see the cabal test taking 5m
<elvishjerricco>
tobiasBora: yea
<elvishjerricco>
mightybyte: Again, I think you should investigate the difference in parallelism. If cabal test spikes all your CPUs, it's a dead giveaway that your code is running the entire time, and able to parallelize.
<elvishjerricco>
And in that case, if nix-build spikes only one CPU, then it's definitely some difference between cabal and Setup.hs
sophiag has joined #nixos
<tobiasBora>
elvishjerricco: well wouldn't it be equivalent to define a new kind of store (not ssh, not local, but say, local-linkable), on which the operation to copy is not rsync, not cp, but "ln -s"? And instead of writing --store local?root=/tmp/nix_test/store, one could write --store local-linkable?root=/tmp/nix_test/store
Fare has joined #nixos
<tobiasBora>
hum I messed things
<elvishjerricco>
tobiasBora: No. Because you can't write such a store. Stores receive copies of store paths as a stream of the contents, not some URL (AFAIK).
<mightybyte>
elvishjerricco: When I run it with `cabal test` the tests run very quickly.
<mightybyte>
It's the build that is consuming most of that 5mp
<elvishjerricco>
mightybyte: Ohhhhh
<elvishjerricco>
That makes a lot more sense.
<mightybyte>
So I think this is no longer a question about my tests, but about nix-build.
<elvishjerricco>
mightybyte: Do you have the ability to measure the time of the tests alone with cabal?
<mightybyte>
Yeah, sure
<mightybyte>
Let me try that
<fresheyeball>
mightybyte: have you tried overriding the checkPhase and timing it in there?
<mightybyte>
fresheyeball: What do you mean?
<mightybyte>
Oh, the nix checkPhase?
<{^_^}>
[nixpkgs] @Infinisil opened pull request #44838 → remake: fix build with glibc2.27 → https://git.io/fNQTd
<fresheyeball>
mightybyte: yeah
<mightybyte>
No
<mightybyte>
How do I do that?
<fresheyeball>
take a look at the generic builder
<mightybyte>
That's definitely what I would like to do.
<fresheyeball>
its going to be something liek
<fresheyeball>
.checkPhase = ''./Setup test'';
<fresheyeball>
on your derivation
<elvishjerricco>
mightybyte: Is this in a reflex-platform style `project`?
<mightybyte>
dhess: Yeah, I'm starting to think about just setting up my own local build machine.
<mightybyte>
elvishjerricco: Ok, `time cabal test` gives me "real 0m19.844s"
Lisanna has joined #nixos
<dhess>
mightybyte: I have a couple in my home at the moment, but I'm about to move and considering what to do next.
<elvishjerricco>
mightybyte: Ok, so that's small. Now to test the overridden checkPhase?
<mightybyte>
Working on that now.
<typetetris>
Is nix-copy-closure save for concurrent use? If for example 10 machines try to copy the same closure to machine a at the same time, will that destroy the nix store on a or is it properly synchronised?
<dhess>
MacStadium's prices are pretty silly. After 10 months' worth of payments, you've basically paid for the original cost of the machine you're renting from them.
<niksnut>
typetetris: yes, it's safe
<typetetris>
niksnut: So it uses the nix-daemon on the target machine?
<niksnut>
not necessarily, if you copy to root@remote-machine it probably won't use the daemon
<typetetris>
niksnut: Okay, I can imagine how that works, if the nix-daemon is used, but how can it be safe, if the daemon isn't used on the target machine (which gets written to)? Does it do file locking or some such?
<niksnut>
yes, locking and sqlite
<typetetris>
ah ok
fresheyeball has quit [Quit: WeeChat 2.0]
worldofpeace_ has joined #nixos
<typetetris>
Hmm okay, so to get all machines in my company to sort of use one nix store, I could dedicate a machine running nix-serve and would need to wrap all the nix commands in a way, that they always do a nix-copy-closure to that machine, if they build anything. Is that a stupid idea?
<tobiasBora>
clever: but it looks a bit magic to me, I don't see how ${self.image}/initrd is created, and the same for ${self.image}/kernel
<tobiasBora>
elvishjerricco: not sure to understand this stuff of stream of store paths. But I guess I'm not familiar enough with nix internal representation...
Synthetica has quit [Quit: Connection closed for inactivity]
ma27 has quit [Quit: WeeChat 2.1]
<dhess>
ixxie: me
<dhess>
although maybe not in the way you're thinking. It looks like I deployed it as a "none" target and not as a hetzner target
tertle||eltret has joined #nixos
jtojnar has quit [Ping timeout: 260 seconds]
<dhess>
This is odd. I bumped several of my deployments to the latest nixos-unstable-small release and tons of stuff isn't hitting the cache, including llvm :(
<{^_^}>
[nixpkgs] @xeji merged pull request #44824 → prometheus-node-exporter: work around prometheus/node_exporter#870 → https://git.io/fNHMf
<{^_^}>
[nixpkgs] @xeji pushed commit from @Ma27 to master « opentimestamps-client: fix build (#44844) »: https://git.io/fNQst
<dhess>
ixxie: no, but there's not much to it, except for the fact that Hetzner's network config is static; no DHCP. At least, not on the dedicated boxes.
<ixxie>
dhess: are some cloud providers giving dynamic IPs? Seems odd
<dhess>
ixxie: I may have used clever's kexec stuff to do the install from a recovery boot.
<{^_^}>
[nixpkgs] @xeji pushed commit from @zauberpony to master « hcloud: 1.5.0 -> 1.6.0 (#44845) »: https://git.io/fNQso
sonne has joined #nixos
<dhess>
ixxie: anyway, re: the Hetzner stuff, my Hetnzer NixOps configs (for their dedicated hosts) look just like any other "none" deployment target, except that they also use a static network config rather than DHCP. I don't use any of NixOps's Hetzner backend support and I'm pretty sure I could not get it to work for my particular situation.
<{^_^}>
[nixpkgs] @xeji pushed commit from @Infinisil to master « python3Packages.zeep: fix build (#44843) »: https://git.io/fNQsp
<dhess>
yes, that's right. (Though that's not very helpful documentation.)
<ixxie>
indeed xD
<{^_^}>
[nixpkgs] @Infinisil closed pull request #44322 → nix: Put config builder into pkgs → https://git.io/fNoXO
<ixxie>
so 1. manually setup the VMs on Hetzner; 2. NixOS infect or some other method to convert the machine; 3. use statics IPs and "none" target to deploy with NixOps
<ixxie>
I guess kexec was used for #2?
<ixxie>
dhess*
<dhess>
yes. I believe I did the kexec trick and not nixos-infect
<dhess>
the kexec stuff works really well in my experience.
<dhess>
ixxie: I think I can whip up a gist example, give me a sec.
<ixxie>
thanks dhess!
<dhess>
ixxie: are you doing Hetzner VPS or dedicated?
<ixxie>
VPS
<ixxie>
I wanna experiment with a little Kube cluster
Wharncliffe has joined #nixos
<elvishjerricco>
Is the `shred` tool actually effective anymore? I thought SSDs and most modern file systems avoid overwriting stuff as long as reasonable.
erasmas has quit [Quit: leaving]
<dhess>
elvishjerricco: I have seen the claim that SSDs make recovery of old data on a formatted volume unlikely. For example, recent versions of macOS have removed the "Security Options" dialog from Disk Utility on SSD/nvme Macs because Apple claims you don't need it anymore.
<gchristensen>
something having to do with built-in encryption?
<dhess>
This might have something to do with HFS+ or APFS however. I still run a 1-pass shred from /dev/urandom on Linux box SSDs, myself.
<elvishjerricco>
Interesting. I'd want to read more about this stuff I think
<dhess>
gchristensen: I don't think so. This is indepdenent of the original format, the new format, and the hardware (e.g., even if you don't have a T1 or T2 chip)
<ixxie>
dhess: got a link for docs on how to do a kexec install?
<dhess>
I know because I've recently been prepping Macs for sale/giving away, and I was surprised to see this option removed from macOS 10.12/13 on basically any Mac hardware post-2012
<gchristensen>
dhess: I mean on the level of the SSD's firmware
<dhess>
gchristensen: oh, perhaps. It used to be you had to enable that but it seems with recent SSDs it's on by default.. again, this is only for Macs, so maybe that's why.
<gchristensen>
right
<gchristensen>
does NixOS have a module supporting ACME's / LetsEncrypt's DNS-01 challenge?
<dhess>
elvishjerricco: I agree. Most of the Macs I've been prepping were using FileVault, so I wasn't particularly concerned after a reformat. However, on the one Mac that hadn't been running FileVault, I dropped into Terminal in the macOS installer and ran a secure wipe by hand using diskutil from the command line.
<dhess>
ixxie: hmm let me look, it's in clever's repo somewhere
<dhess>
ixxie: ok, you will still need to add grub details, change IPs and prefixLength's etc. to this, but I believe this is the bare minimum that's needed to work with a Hetzner host with NixOps. https://gist.github.com/dhess/b23d198f7b4842af3b5a031cfb5fdd39
<{^_^}>
[nixpkgs] @LnL7 opened pull request #44848 → vault: make package configurable → https://git.io/fNQZg
<{^_^}>
#44482 (by dhess, 4 days ago, open): haskell: re-enable aarch64, disable parallel builds on that arch.
ma27 has joined #nixos
ma27 has quit [Client Quit]
<dhess>
This fixes ghc on aarch64, which is nice, but building haskellPackages on aarch64 should probably go into a new jobset for reasons outlined in that PR
ma27 has joined #nixos
ma27 has quit [Client Quit]
<ixxie>
dhess: so you can use this kexec to make a permenant install of NixOS?
ng0 has joined #nixos
ma27 has joined #nixos
<ixxie>
because if I read this correctly, it runs NixOS in RAM?
<dhess>
ixxie: yes, it exists chiefly to get you to a NixOS prompt from any other distro so that you can install NixOS on that machine.
nckx has quit [Quit: Updating my GNU GuixSD server — gnu.org/s/guix]
<dhess>
I've found it to be more reliable than nixos-infect, which makes a bunch of assumptions etc.
johnw has quit [Read error: Connection reset by peer]
<dhess>
With this kexec trick you tell Nix to build you something that's customized for the machine you want to install to, you upload the image, kexec it, and bam, you're at the NixOS prompt a few seconds later.
nckx has joined #nixos
<dhess>
nixos-infect is less effort, *if* it works.
ma27 has quit [Client Quit]
kiloreux has quit [Ping timeout: 240 seconds]
<dhess>
Every time I see atlas building, it makes me sad.
<gchristensen>
oh man, atlas :(
<gchristensen>
24rs!
<gchristensen>
dhess: I'm not sure we should create a jobset for this, it adds a lot of work to hydra and for it to be practically useful you'd need it to be sync'd with the channel anyway. given this ticket in GHC is only 13 days old, I'd be inclined to wait to see if a better patch is coming?
Wharncliffe has quit [Quit: Lost terminal]
<infinisil>
I was just trying to debug atlas a bit earlier
<infinisil>
I ain't got no chance though
<infinisil>
Some with some other glibc/binutils breakages
<infinisil>
Same*
<dhess>
gchristensen: Any upstream fix is not going to change anything for ghc843 or ghc822. It will be months before ghc861 is made the default, and that's assuming it can be fixed upstream for that release, anyway.
<dhess>
And I think a lagged set of packages/channel is preferable to nothing at all.
<gchristensen>
this is very frustrating :(
<dhess>
It's less frustrating than before, when it didn't work at all :)
kiloreux has joined #nixos
<gchristensen>
dhess: I'd suggest pinging niksn*t in #nixos-dev about it and explain this stuff :P personally, I'm not thrilled about it but it isn't up to me :)
boomshroom has quit [Quit: WeeChat 2.1]
<dhess>
who is that?
<gchristensen>
niksn<tab> is eelco, and the * means he's not pinged here :)
<dhess>
oh
<dhess>
gchristensen: so on a related question, assuming this doesn't get added to the Nix Hydra, that means I will build it myself for my own work. Currently my Hydra uses a single aarch64 build machine, but I was planning to move that work to the community aarch64 box in the next month or two. I believe you're in charge of that box, yes?
<dhess>
infinisil: atlas on nixos-unstable-small seems to be building OK for me, it's just not cached for some reason that I don't understand.
<dhess>
Along with llvm, which is also strange.
init_6 has joined #nixos
simukis has joined #nixos
aarvar has joined #nixos
<infinisil>
There was a commit on master recently that caused an llvm rebuild
<dhess>
infinisil: I would have thought that nixos-unstable-small wouldn't have advanced until that was finished.
<infinisil>
Next time I see such a commit that rebuilds pretty much everything on master I'll ask to revert it..
justanotheruser has quit [Ping timeout: 256 seconds]
<d1rewolf>
all, on a 4k display using i3 and nixos, certain apps (like qutebrowser, for example) *and* the mouse cursor are way too small. I've set dpi to 220 via ~/.Xresources, but the problem persists. Any ideas how to fix?
<dhess>
To be clear, I'm not complaining, just surprised :)
<infinisil>
I'm complaining! I had to revert that commit a lot in order to be able to do any tests on master
<dhess>
ok :)
justanotheruser has joined #nixos
<dhess>
I think I will also revert my channel bumps because I need to get some work done and I'm just sitting here watching the compiles go.
<d1rewolf>
I've set Xcursor.size in ~/.Xresources, but no luck
<d1rewolf>
does anyone here use i3 + 4k monitor? Could you share your configs so I could explore them? ;)
<mightybyte>
elvishjerricco: Looks like it's something in the test binary.
<mightybyte>
I did this
ng0 has quit [Quit: Alexa, when is the end of world?]
<mightybyte>
checkPhase = "echo ================; time ./Setup test; echo --------------";
<mightybyte>
The equal signs printed, but not the dashes.
ma27 has joined #nixos
<elvishjerricco>
mightybyte: Whoa. So something is killing it, yet the nix-build runs to completion? Are you sure nix-build is exiting successfully? Even if it fails, it'll still leave build output in $out, for some reason. Though I guess checkPhase comes before installPhase, so that shouldn't be relevant
<{^_^}>
[nixpkgs] @orivej-nixos pushed commit from @orivej to master « subversion: default to subversion_1_10 (#44800) »: https://git.io/fNQC5
init_6 has quit []
* infinisil
is done trying to fix builds for today
<gchristensen>
infinisil++
<{^_^}>
infinisil's karma got increased to 18
<infinisil>
^.^
rprije has joined #nixos
<{^_^}>
[nixpkgs] @jbaum98 opened pull request #44850 → lcalc: Add darwin support → https://git.io/fNQCp
mayhewluke has quit [Ping timeout: 240 seconds]
<ixxie>
dhess++
<{^_^}>
dhess's karma got increased to 3
<elvishjerricco>
mightybyte: I wonder if Nix kills builds that have done zero IO for a certain amount of time.
<elvishjerricco>
If your test is reaching a deadlock or something, maybe it'd get killed?
mayhewluke has joined #nixos
<dhess>
gchristensen: so would you object if I ran jobs on the community aarch64 box that built GHC in this way?
<gchristensen>
dhess: absolutely not!
<gchristensen>
go to town :)
<dhess>
ok cool, thanks
<dhess>
just wanted to check first
<elvishjerricco>
mightybyte: Ah, there are two such values in Nix: max-silent-time and timeout
<gchristensen>
if it gets over-used we have a super cool problem and can find ways to solve it from there :P
<elvishjerricco>
max-silent-time The maximum time in seconds that a builer can go without producing any output on stdout/stderr before it is killed. 0 means infinity.
<elvishjerricco>
timeout The maximum duration in seconds that a builder can run. 0 means infinity.
<elvishjerricco>
However both seem to default to 0
Dedalo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jperras has joined #nixos
emacsoma` has joined #nixos
<mightybyte>
elvishjerricco: No, it's not exiting successfully.
<mightybyte>
Could it be that the test suite executable is dying on its own and that the failure there is short-cirtuiting the next echo?
hakujin2 has quit [Ping timeout: 256 seconds]
viric has quit [Quit: leaving]
hakujin2 has joined #nixos
ma27 has quit [Quit: WeeChat 2.1]
papika has quit [Quit: Leaving]
<sigtrm>
Hi everybody, is there any firewall or rules default with NixOS?
<gchristensen>
yeah, it defaults to everything blocked
<samueldr>
(except the exception for ssh)
<sigtrm>
Thank you, can I open a port through configuration.nix?