<clever>
colemickens: a currently running process refers to that path
<clever>
thoughtpolice: and they just didnt want to deal with auditing it for problems, so they just disable it
<clever>
thoughtpolice: from what i heard, its more about adding a large chunk of un-audited code to the kernel
<clever>
but now you rely on both fuse support (which itself has some security problems) and user namespacing (which debian claims has security problems)
<clever>
because a true mounted FS would open the kernel up to buffer overflow exploits in the FS driver, along with things like setuid binaries
<clever>
your only allowed to `mount --bind`
<clever>
i think they are forced to use fuse, because you cant mount actual filesystems when using user namespacing
<clever>
and they added a /proc flag to re-enable it
<clever>
it will likely have the same problems on debian, where a custom kernel patch disables namespacing for non-root users
<clever>
FRidh: i see mention of namespaces, the same stuff nix-user-chroot uses
<clever>
simpson: then i went to the userland side, with zero idea how mesa and opengl where "supposed" to work, and just implemented every function the opengl app was using, lol
<clever>
simpson: i started with kernel code that delt with allocating chunks of memory, letting you mmap them into userland, letting you issue a render action, and waiting for an irq
<clever>
simpson: ive had the fun of writing gpu drivers for the rpi before
<clever>
there is also pkgs.clang.cc, which has some clang libraries, but no libclang.so
<clever>
provides clang by default, and makes sure clang actually works
<clever>
Athas: instead of stdenv.mkDerivation, use clangStdenv.mkDerivation
<clever>
Athas: are you using clangStdenv.mkDerivation?
2019-08-04
<clever>
yep
<clever>
fendor_: and are any weird nix related env vars still set?
<clever>
fendor_: did you bind mount to /nix or /nix/store ?
<clever>
if you lack write access to /nix (or it doesnt exist), the script will use sudo to correct that, then do the rest without root (if doing a single-user install)
<clever>
fendor_: the install.sh script just cares that you own /nix/, it doesnt care how its mounted
<clever>
2019-08-04 12:23:42 < clever> instead of using <nixpkgs>, just directly give it the path to a nixpkgs
<clever>
srid: but that wont work on my machine
<clever>
instead of using <nixpkgs>, just directly give it the path to a nixpkgs
<clever>
srid: or tell your nix expr to use nixpkgs-unstable directly, and ignore what the host system has
<clever>
srid: echo $NIX_PATH
<clever>
srid: a nixos machine gets the nixpkgs from the nixos channel
<clever>
fendor_: you may need to clear the ~/.cache/nix/tarballs dir
<clever>
and a reboot is all you need to apply the systemd update
<clever>
and init-interface-version is a safety, to stop it from breaking the entire system
<clever>
but, for certain version changes, they arent compatible
<clever>
from what ive seen, systemd usually can serialize its state to disk, and then pid 1 will re-execute the new systemd, which will deserialize and restore the state
<clever>
chris__: the git rev is in the storepath, near the end
<clever>
iqubic: yes
<clever>
sphalerit: *doh*, it was in the pocket on the scope the whole time
<clever>
evanjs: my system is setup to copy all of /etc/nixos to /run/current-system/nixcfg/
<clever>
evanjs: not really
<clever>
reminds me of xkcd, "standards"
<clever>
heh
<clever>
lol
<clever>
ive got a cachecache, that can cache a binary cache, but it currently lacks the ability to query a local nix-daemon
<clever>
or haskell
<clever>
thoughtpolice: just rewrite it in c++ :P
<clever>
which lets you act as an untrusted cache
<clever>
so you can repeat upstream sigs, and proove that you didnt do anything nasty to the files
<clever>
thoughtpolice: and `nix copy-sigs` can download the cache.nixos.org signatures, and save them locally
<clever>
thoughtpolice: does eris support nix2.0 signatures in db.sqlite?
<clever>
ivan: strace + curl to see what its doing when frozen
<clever>
ivan: sounds like the client didnt read the reply?
<clever>
ivan: id start with strace and curl, to see what its doing
<clever>
ivan: set restart=always on the unit? find out why its crashing?
<clever>
lambda-11235: are there any qt packages in nix-env ?
<clever>
lambda-11235: you can find out what nixpkgs a generate was made from easily
2019-08-03
<clever>
sphalerite: where did i leave my scope probes...
<clever>
iqubic: first, you need to figure out if those options are controlled via a config file, or if they can be changed by a command after you login
<clever>
kreisys: maybe :D
<clever>
kreisys: but worktrees yeah
<clever>
kreisys: `git archive` gives you a subset that you want
<clever>
kreisys: cloning from the bare repo i think copies the entire .git dir, and then it deletes it
<clever>
kreisys: the release.nix would have to fetch the submodules that ./submodules.json defines, then merge ./. with the submodules
<clever>
(or directory)
<clever>
iqubic: .source is usually a path to a file
<clever>
kreisys: my idea, was to make a json file in the repo, that describes the submodules, and then use runCommand to merge things together, using multiple fetchFromGithub (deepfire/serge has implemented it)
<clever>
kreisys: i think it mainly impacts the name
<clever>
so something as simple as an unrelated branch getting pushed, can result in a different .git
<clever>
the version of git, and the state of unrelated branches, will impact what git puts in .git
<clever>
kreisys: and .git is often a source of impurities
<clever>
kreisys: deep clone is the reverse of shallow clone, its to do with history, not submodules
<clever>
kreisys: i believe only iohk's fork of hydra will fetch submodules
<clever>
kreisys: ah, fetchgit uses a name based on the url, but fetchFromGitHub uses "source"
<clever>
kreisys: on which version of nixpkgs?
<clever>
kreisys: fetchgit or fetchGit?
<clever>
kreisys: and then fetchFromGitHub and friends had to be changed to "source" to match hydra
<clever>
kreisys: the problem is more that hydra doesnt know what the name should be, so it has to fetch it as "source"
<clever>
kreisys: yeah, a bit of messy
<clever>
kreisys: oops, ^^
<clever>
hyper_ch: you want to set name="source"; on the nix function doing the fetch
<clever>
kreisys: the name is part of what gets hashed
<clever>
kreisys: are the names identical?
<clever>
gchristensen: zfs!, zfs!
<clever>
gchristensen: ^^
<clever>
2nd, /bin is empty!, youll want to export PATH=/nix/var/nix/profiles/system/sw/bin/
<clever>
1st, stage-1 will claim /bin/sh doesnt exist (its an absolute symlink, and its testing relative to the wrong root), tell it to continue anyways
<clever>
nixos just has some extra requirements
<clever>
the disk is already mounted to / when it runs "init"
<clever>
no need to
<clever>
then you have root, without systemd, and can do whatever you want
<clever>
(this works in any linux distro, even nixos)
<clever>
if you change the kernel cmdline in grub to `init=/bin/sh` you can force a single-user shell
<clever>
and he had also GC'd older generations, because it was running fine for years
<clever>
then after years of not rebooting, he rebooted, and it failed on bootup
<clever>
he was doing network in his activation script, and hadnt rebooted in years, so it always worked
<clever>
and thats the exact same problem the 1st guy with activation problems had
<clever>
yeah, nixos-rebuild will re-run activation scripts, to apply changes
<clever>
zaninime: cups isnt even running when activation scripts happen, so its more likely to fail 100% of the time
<clever>
zaninime: what is the script doing?
<clever>
zaninime: yeah
<clever>
ever since i helped debug that first guy that lacked systemd, ive been saying, just use a systemd script
<clever>
zaninime: so || exit 0 will make it worse
<clever>
zaninime: i think nixos unstable also wraps every script for you, to prevent problems
<clever>
you want || true
<clever>
oh, yeah, that will do it, lol
<clever>
zaninime: when the activation script fails, it bails out early, before putting systemd in PATH
<clever>
zaninime: it will be at a path like this, check the system symlink to see what the latest is, then look backwards a bit
<clever>
-r-xr-xr-x 1 root root 18346 Dec 31 1969 /nix/var/nix/profiles/system-500-link/activate
<clever>
zaninime: and maybe read the finished activate script in the nix store
<clever>
zaninime: youll need to add `set -x` before it, and see what exactly is failing
<clever>
zaninime: are you still able to boot an older generation? or try removing it
<clever>
zaninime: did you have any custom ones?
<clever>
zaninime: activation scripts can cause that problem if they have an error
<clever>
ahh
<clever>
ToxicFrog: ahh, yeah
<clever>
if its done with env vars, then a setup hook can probably also do it
<clever>
probably
<clever>
Miyu-chan: i think if you have perl int he buildInputs, and use #!/path/to/perl, the fixup phase will fix it for you