<clever>
sshow: other things could also have been corrupted
<clever>
sshow: it will hash the contents of every single file in /nix/store
<clever>
sshow: by default, ext4 is only using the journal to protect metadata, so the FS wont catastrophically fail, but data can be lost
<clever>
lukegb: exactly!
<clever>
lukegb: that will probably do it
<clever>
sshow: ext4 loves to silently truncate files that where not fully written
<clever>
sshow: did you have an improper shutdown recently?
<clever>
oh, empty!!
<clever>
sshow: and `head -n1` on that perl?
<clever>
sshow: what does `head -n1 /nix/store/9la7w2d567cvi71pgiy4ydzhg1lrbhss-nixos-system-prodigy-21.05pre282432.311ceed827f/bin/switch-to-configuration` report?
<clever>
veleiro: all channels on root are global
<clever>
sshow: what is the full path to the switch-to-configuration? what cpu arch are you on?
<clever>
so the thing your linking cant be deleted until your product is first deleted
<clever>
ambroisie: any symlinks in $out create extra runtime dependencies for your build product
2021-04-13
<clever>
exfalso: unicode, it doesnt render on mine
<clever>
sterni: my irc client only pings if my name is at the very start of a msg, like yours is here
<clever>
feathers: run `nix repl` then `:?` and youll see the full help
<clever>
kenran: add preConfigure = "set -x"; to the derivation, there is probably a hook to move things
<clever>
kenran: $lib is for libraries loaded at runtime, $dev is for headers and static libraries only used at build-time, $bin or $out for the binaries you may not need
<clever>
> pkgsStatic.hello
<clever>
remexre: pkgsStatic
<clever>
pie_: anything with networkd in the name
<clever>
pie_: check /etc/systemd/system/ ?
<clever>
pie_: does it have a systemd service? what does the .service file say?
<clever>
yep
<clever>
eacameron: you can also just run: phases="unpackPhase patchPhase configurePhase buildPhase" genericBuild
<clever>
eacameron: your not doing that switching, so your always getting the bash function
<clever>
eacameron: genericBuild will dynamically switch between evaluating $unpackPhase (an env var containing shell code) and running unpackPhase (a bash function by the same name)
<clever>
but stdenvNoCC wont
<clever>
the default stdenv has that
<clever>
$NIX_CC only happens if gcc was in your buildInputs
<clever>
run `echo $NIX_CC` and `ls -l $NIX_CC/nix-support/dynamic-linker` and `cat $NIX_CC/nix-support/dynamic-linker`
<clever>
then you can omit the --set-rpath
<clever>
eacameron: sets the rpath, so ldd can find libs
<clever>
tpw_rules: if the interpreter on an ELF is missing, then executing it claims not found
<clever>
eacameron: what about the interpreter?
2021-04-07
<clever>
then it wont auto-start
<clever>
eggplant: you can also mkForce the wantedBy, so its not wanted by multi-user.target
<clever>
thats what i would expect
<clever>
srhb: what does `which youtube-dl` report inside your `nix shell` ?
<clever>
srhb: one thing that often trips people up, `nix-shell -p youtube-dl` puts youtube-dl into $PATH, while `nix-shell '<nixpkgs>' -A youtube-dl`, gives you a shell suitable for BUILDING youtube-dl
<clever>
__monty__: the default value only gets set when genericBuild is stepping thru phases for you
<clever>
cwpubDJ[m]: -i will search the .name attribute of every package, and install the "best match", while -iA gives an attrpath saying exactly which one to use
2021-04-05
<clever>
ihsan: to get differences, you need to instead use git, which then requires cloning the entire history
<clever>
it was appending to the var at build time
<clever>
yep, because the package never set configureFlags
<clever>
but you can also use configureFlags (the nix var) to have an initial config, that the array will start out with
<clever>
cinimod: preConfigure is a chunk of bash script, that gets ran between the patch phase and configure phase
<clever>
cinimod: its also blank to begin with, so there is nothing to append to
<clever>
> R.configureFlags
<clever>
> builtins.attrNames pkgs.R
<clever>
cinimod: it may just be called configureFlags
<clever>
cinimod: thats what the `old` in `.overrideAttrs (old: {` is for
<clever>
tobiasBora: so, their attempt to fix the same problem nix solves, is making nix's job harder
<clever>
tobiasBora: gtk is using $out/include/gtk, in an attempt to avoid conflicts when you install 2 gtk versions
<clever>
tobiasBora: the stdenv will add the $out/include of everything from buildInputs to the cflags thing, so it magically works
2021-04-04
<clever>
_virkony_: ive not used home-manager much, so i'm not sure whats better for that
<clever>
_virkony_: if you use a channel name starting with nixpkgs, you risk breaking the machine
<clever>
_virkony_: when using nixos, you must always use a channel name starting with nixos
<clever>
its probably in the nixpkgs manual, if its documented
<clever>
thats the raw clang, which doesnt respect NIX_CFLAGS_COMPILE
<clever>
> clang.cc
<clever>
> clang.unwrapped
<clever>
you have to go out of your way to break things
<clever>
> clang
<clever>
tobiasBora: the clang in $PATH is still a cc-wrapper
<clever>
some makefiles will set CFLAGS rather then append
<clever>
$CC is pointing to a copy of cc-wrapper, which will inject $NIX_CFLAGS_COMPILE into the args, so nix doesnt rely on CFLAGS surviving random makefiles
<clever>
$ file $(which $CC)
<clever>
/nix/store/ca37d3qrydh0wpw40kswsx30j8dyzxh2-gcc-wrapper-10.2.0/bin/gcc: a /nix/store/f7jzmxq9bpbxsg69cszx56mw14n115n5-bash-4.4-p23/bin/bash script, ASCII text executable
<clever>
its all handled by cc-wrapper
<clever>
yeah
<clever>
gtk breaks the rules, by trying to solve the same problem nix is already solving
<clever>
and how the sane packages are found
<clever>
this env var is the same way buildInputs sneak into the search path
<clever>
Drakeson: if a nix binary has write access to /nix/store, it wont need nix-daemon running
<clever>
i think so
<clever>
a use-case for the canadian cross, is to build something like an arduino IDE, that runs on the rpi, but use x86 hw to build it
<clever>
so now you have 3 platforms involved!
<clever>
dgpratt: the most complex case (which i dont think nix fully supports) is a canadian cross, where you could for example be building a compiler on x86, but the compiler ultimately runs on arm, and the compiler targets AVR
<clever>
which doesnt make sense when building nix from inside nix, that has to happen later on
<clever>
Drakeson: it was an option, to stop nix from initializing db.sqlite upon `make install`
<clever>
charly79: /usr/bin/env doesnt exist at build-time, run patchShebangs on the perl script
<clever>
also depends on what style of recursion the project is doing
<clever>
but nix likes to clean the intermediates up, so you cant
<clever>
and it will repeat that failure, and fail instantly
<clever>
at least with interactive builds, you can re-run `make -j1` after the failure
<clever>
exactly
<clever>
if its building with -j, it may take longer to fail
<clever>
Tv`: ah yeah, that could work, ../static
<clever>
Tv`: /etc/static allows you to atomicly update every symlink in /etc at once
2021-04-01
<clever>
vandenoever: and the gui editor for ui stuff
<clever>
vandenoever: qmake && make still works in CLI, and has far less fussing, you just loose the IDE
<clever>
things may have changed since then
<clever>
and those files get cleaned up when nix-shell exits
<clever>
it relies on files in /tmp made by the preConfigure hook
<clever>
even worse when i last tried it
<clever>
and it breaks every time you re-open nix-shell
<clever>
i did find qtcreator very painful to make work in nixos
2021-03-30
<clever>
matthewcroughan: never heard of it before, so i cant comment on it
<clever>
find another common example of that, and look at how nix solved it, it happens a lot in python
<clever>
nix doesnt allow that, ever
<clever>
matthewcroughan: you formed a circle
<clever>
matthewcroughan: the problem is that you made macro depend on material, which depends on macro
<clever>
matthewcroughan: it can, pSelf
<clever>
matthewcroughan: you almost always want to use self, except when your overriding an attr with itself, then you need super to break the recursion
<clever>
matthewcroughan: super.pkgs might be doing the same as self
<clever>
matthewcroughan: super.pkgs might be confusing things more
<clever>
matthewcroughan: super.pkgs is also pointless, super and self are both copies of pkgs
<clever>
matthewcroughan: so line 30 wont be taken into account