<clever>
jonge: ah, so nixos is fully managing /boot, that makes things simple
<clever>
jonge: id first need to see your current configuration.nix to know how its booting
<clever>
jonge: depends on if nixos is managing config.txt, and where you mounted the fat32 partition
<clever>
but you need to first enable kms in config.txt
<clever>
jonge: there has been recent work in the kernel to get proper kms support, and i think x11 just detects that automatically on startup
<clever>
yep
<clever>
st3r4g: nixos-install is a script to do the rebuild in a chroot for you
2020-11-11
<clever>
srid: it could be that it only loads the tz offset once on startup, and you have to relog for it to notice you changed offset?
<clever>
Henson: let foo = callPackage ./default.nix; in callPackage "${foo}/build.nix" {}
<clever>
Henson: import from derivation
<clever>
axx: youll need to look at your config and whats under fileSystems., and confirm if those devices are still present and setup right
<clever>
axx: did you run nixos-generate-config?
<clever>
axx: that can happen if you didnt configure the filesystems properly, and it cant find what you said to mount at /
<clever>
axx: so the bootloader config is still pointing to the old build
<clever>
axx: it sounds like you didnt configure the bootloader correctly
2020-11-10
<clever>
eyJhb: `ncdu -x /`
<clever>
jbal[m]: yes
<clever>
cant think of any documents that i know of
<clever>
because who would be crazy enough to allow a different libc in every single app? :P
<clever>
nss wants to be able to dynamically shove a lib into any app on the system, and they expect only one libc
<clever>
catern: its due to compatability problems between the libc nix choose, and how nss wants to dynamically load libs into the app for avahi's .local
<clever>
heh
<clever>
pittma: already played with that locally a while back
<clever>
pushqrdx: have a look at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/config/console.nix, what is it doing with console.keyMap?
<clever>
pushqrdx: are you sure you commented it out? can you pastebin the new configuration.nix?
<clever>
Cadey: only put those into the imports list when using a nixops deployment.nix file
2020-11-08
<clever>
asbachb: yeah
<clever>
asbachb: there is also nix-prefetch-url to download it, hash it, and put it in /nix/store/
<clever>
asbachb: when using pkgs.fetchurl, you can just use the plain sha256 of the tar.gz
<clever>
> :p map (x: x*10) [ 1 2 3 ]
<clever>
> map (x: x*10) [ 1 2 3 ]
<clever>
map
2020-11-07
<clever>
and if you later want to put things into nixpkgs, you can copy app.nix over, and just fill in the right src=
<clever>
exactly
<clever>
then you just nix-shell with no args
<clever>
default.nix feeds packages to app.nix
<clever>
other way around
<clever>
its usually better to have an app.nix, and then a default.nix in the root dir, that does callPackage, with the right version of nixpkgs
<clever>
so the ./default.nix will always look at ~/default.nix
<clever>
pushqrdx: nope, relative paths in a .nix file, are relative to where that .nix file lives
<clever>
bot*
<clever>
it is a bit
<clever>
and if you put it into default.nix, it will be the default file nix-shell and nix-build load
<clever>
so you dont have to remember the whole thing
<clever>
but you can also just put that string into a .nix file, and run nix-shell on it
<clever>
if you want to load the default.nix as-is, you need to do what {^_^} said
<clever>
it will try to open a shell with every single package at once
<clever>
if you run `nix-shell '<nixpkgs>'`, then it ignores default.nix
<clever>
the default.nix i gave above, loads wingpanel.nix, and supplies all of the packages it wants
<clever>
nix-shell just loads either shell.nix or default.nix
<clever>
2020-11-07 12:39:44 < clever> pushqrdx: long answer, copy that default.nix to wingpanel.nix, then make a default.nix containing: with import <nixpkgs> {}; callPackage ./wingpanel.nix {}
<clever>
that means you didnt follow the directions
<clever>
what was the error?
<clever>
so you can just `nix-shell`
<clever>
the default.nix loads <nixpkgs> for you
<clever>
it feeds it the packages that are defined in <nixpkgs>
<clever>
pushqrdx: correct, you must use callPackage to fill those in
<clever>
,callPackage
<clever>
supply it with all of the packages it wants, which are listed on the 1st line
<clever>
pushqrdx: long answer, copy that default.nix to wingpanel.nix, then make a default.nix containing: with import <nixpkgs> {}; callPackage ./wingpanel.nix {}
<clever>
pushqrdx: short answer, `nix-shell '<nixpkgs>' -A pantheon.wingpanel`
<clever>
that default.nix has to be loaded with callPackage, neither nix-build nor nix-shell can run it
<clever>
what arguments?
<clever>
and how did you run nix-shell?
<clever>
what are the contents of the default.nix and shell.nix?
<clever>
pushqrdx: run nix-shell on it, instead of nix-build
2020-11-06
<clever>
and the client still thinks its encrypted
<clever>
numkem: then you can packet-sniff the traffic from the nginx->minio
<clever>
numkem: one trick you could maybe do, setup an nginx server, to do https->http proxy_pass
<clever>
alexfmpe: you want to add it to the buildInputs instead
<clever>
alexfmpe: nativeBuildInputs are only for tools ran at build time, not libraries/headers used in the build
<clever>
not really clear why its hanging
<clever>
bqv: 9 reads returned 2805
<clever>
that will capture what nix-daemon is up to when you try the build
<clever>
bqv: find the pid of the main nix-daemon (the one without a pid in its args list), and run `strace -f -p PID` on it, then repeat `nix-build '<nixpkgs>' -A hello` as non-root
<clever>
when ran as root, it wont go thru the unix socket, and we can see the true hang
<clever>
bqv: its most likely the unix socket talking to nix-daemon, ctrl+c that, pkill all nix-daemon's, and then repeat as root
<clever>
bqv: what does `ls -l /proc/75805/fd/3` report?
<clever>
bqv: and the parent is waiting on a futex owned by the child i believe
<clever>
bqv: that thread did a blocking read on fd3, and never returned
<clever>
bqv: at the end, we can see that the main pid (75805) forked out a thread with an id of 78281
<clever>
bqv: run `strace -f nix-build '<nixpkgs>' -A hello`, what is the last thing it did before deadlocking?
<clever>
bqv: if you didnt kill off the old nix-daemons from before the deadlock, those can still be the problem
<clever>
and in this case, each directory cross-compiles to a different cpu, so i just `.${CPU}.${DIR}`
<clever>
there is a default.nix in the root of the project, doing things like `callPackage ./firmware {}`
<clever>
cinimod: usually, i just pull in a mkDerivation from elsehwere, in my shell.nix