<clever>
is it modifying metadata on the ext4 image?
<clever>
arian_: no, all builds must be done without root
<clever>
trikl: --print-rpath i believe
<clever>
rvolosatovs: i just left xorg all on defaults, and the login page is a bit messed up, but xfce does all the multi-monitor setup after login
<clever>
trikl: either somebody did something impure and installed libcurl globally, or they didnt test things well enough when making the latest update
<clever>
it just compiles a single c file directly to $out/bin/nix-repl
<clever>
xificurC: and -static doesnt work out of the box, because nix disables a lot of things needed for static linking
<clever>
xificurC: also, your cd'ing into $src (which is read-only) and then doing gcc -o as-table, which writes to the current dir
<clever>
trikl: and since your referencing ${curl.out} directly, it doesnt have to be in the buildInputs at all
<clever>
trikl: ah, for libcurl, you want to patchelf it to include ${curl.out}/lib/ in the rpath
<clever>
trikl: or modify things to put ${curl.out}/bin into PATH
<clever>
trikl: something in the build process has to embed the result of $(which curl) into the output
<clever>
trikl: buildInputs only controls what $PATH (and a few others) are at build-time, it has no direct effect on what is available at runtime
<clever>
dash: for example, if the editor knows that something is an attrset, can it select the entire attrset and cut/paste without ever causing a syntax error?
<clever>
dash: id also be interested in AST aware editing features
<clever>
if the editor had an ffi
<clever>
and if it was annotated with line/column positions, you can then highlight away
<clever>
then you could reuse the code inside libnixexpr to get an ast
<clever>
to make it into a string->ast->thunk process
<clever>
https://github.com/groxxda/nixexpr i think this project was working on splitting the string->ast apart from the string->thunk logic
<clever>
gchristensen: but it all seems to highlight right
<clever>
but you could copy the whole file to your project, then change it, if you want to avoid modifying nixpkgs
<clever>
simpler to just change the file directly
<clever>
and while you could in theory use .overrideDerivation to change the installPhase on frameworks, you would have to copy/pasta the entire installPhase string, and change every ${sdk} in it
<clever>
the only thing .override can affect, are the arguments passed in on line 1
<clever>
it would have to be rewritten some to allow such an override to work
<clever>
you have to directly modify that file
<clever>
because frameworks and sdk are in the same let block, its imposible to override sdk
<clever>
ah
<clever>
luigy: what part of it do you want to override?
<clever>
but the one in nixpkgs is still perl based, and is technicaly out of date
<clever>
and that buildEnv can be out of sync with the buildEnv in nixpkgs
<clever>
gchristensen: for example, nix-env uses a copy of buildEnv, running on its own perl (the one nix was built against, not the one in the current nixpkgs)
<clever>
LnL: yeah, i feel that a well written package will use absolute paths for everything, and should run with ./result/bin/foo with nothing above the base-system installed
<clever>
when i setup my own channel for the rpi
<clever>
i'm going off info i got back in 2015
<clever>
yeah, if you lack root, then nix will probably either ignore the extra binary cache, or complain about its signature
<clever>
MichaelRaskin: a channel is just an http dir with 2 files, binary-cache-url and nixexprs.tar.xz
<clever>
MichaelRaskin: channels can specify a binary cache
<clever>
that defeats the entire point of nix
<clever>
LnL: i tried to run the latest kdenlive in a nix-shell one day, and tracked the problems down to an older kdenlive already being in nix-env
<clever>
LnL: it relies on propagatedUserEnv stuff, and also conflicts with older kde stuff from another version of itself
<clever>
LnL: that reminds me, kdenlive refuses to run via ./result/bin/kdenlive
<clever>
i currently have 7 glibc's in my ~/.nix-profile/
<clever>
nix-env is the only tool that directly understands channels
<clever>
there is also the weird part about how nix-env will obey $NIX_PATH, but never actualy try to use it by default
<clever>
which just spams the profile and leaves 100's of GC roots behind
<clever>
i also see people using nix-env to test new packages
<clever>
danbst: yeah, thats why i always embed such things in config.nix
<clever>
in the case of unzip, it will magicaly give the default unpackPhase zip support
<clever>
it can then modify bash variables, and add new bash functions
<clever>
gchristensen: as the stdenv goes over everything in buildInputs, it will check for a $foo/nix-support/setup-hook, and if found, it will source it into tbe bash doing the build
<clever>
which can apply mutations to the stdenv
<clever>
MichaelRaskin: yeah, no mention that putting your package into buildInputs makes the hook get sourced
<clever>
it would be better to make them easy to find, and explain how they work, then to try and document the side-effects each one does
<clever>
and a quick search says there are 64 setup-hook.sh's in nixpkgs
<clever>
MichaelRaskin: cmake and unzip are missing, and it doesnt really say how setup hooks work
<clever>
and some things, like setup-hook.sh, i havent seen mentioned anywhere in the documentation
<clever>
pie___: there is also a "systemctl kexec" that reboots via kexec
<clever>
pie___: nixos does have a kexec crashdump handler, but it just reboots nixos with less ram, and you need to manualy run kdump within that if you want to use it
<clever>
Infinisil: a digitalocean module can also be added similarly
<clever>
digitalmentat: and nix enforces that by making you set the env variables for nix-daemon, not nix-build
<clever>
digitalmentat: so the admin has to trust the build hook and the build machines
<clever>
digitalmentat: the build hook provides the raw contents that land in $out, and an attacker could just run nix-build with a fake hook, and provide a fake build of sudo to insert into /nix/store
<clever>
Infinisil: main thing missing is nathan7's DO configuration module
<clever>
Infinisil: nixos-generate-config handles the corecount, sfdisk eats the entire drive if you omit size, and if you just set a rule that the droplet must only have 1 drive, its always vda?
<clever>
Infinisil: in theory, that could be added to the kexec configuration.nix
<clever>
and it pre-installs it into the nixos thats being built
<clever>
Infinisil: this creates a bash script called justdoit, that does a full nixos install (ext4 based in this case)
<clever>
and potentialy any tools that are only needed at compile-time
<clever>
chrishill: and installing it wont fix the compile problems
<clever>
i'm trying to stay up past 2pm
<clever>
uhhh, lol
<clever>
after*
<clever>
the digital ocean droplet only has 500mb of ram, and the initrd is 200mb before compression
<clever>
gchristensen: ah, 500mb of ram isnt enough to kexec
<clever>
can you pm me the user/host/pw?
<clever>
Infinisil: and does the script output anything else when ran?
<clever>
Infinisil: can you gist the contents of /kexec_nixos ?
<clever>
Infinisil: what didnt work with my kexec trick?
<clever>
nix will tell you if its somewhere it doesnt belong
<clever>
yeah, in that one
<clever>
the main { } that spans multiple lines
<clever>
the one right after that
<clever>
its mainly to help remove duplicates, so if your setting 20 different things under services. you can just put them all inside a service = { ... }; instead
<clever>
and also foo = { bar = { baz = true; }; };
<clever>
foo.bar.baz = true; is identical to foo = { bar.baz = true; };
<clever>
so it has to go within the top most {} set