<matthewcroughan>
I want this personally for myself. It's in master. Could I/should I set up hydra to build nixos master, then add master as a flake input, would I then basically be using nixos on rolling -release?
<sterni>
matthewcroughan: hydra continously updates to master and tries to build this job, if it succeeds, the channel advances to that revision for nixos-unstable: https://hydra.nixos.org/job/nixos/trunk-combined/tested
<sterni>
matthewcroughan: you can check the constituents tab to see what that entails
<sterni>
and you can check the nixos-unstable branch in NixOS/nixpkgs which is always at the revision the channel is currently
<matthewcroughan>
sterni: wow, so hydra is just taking this long to get to my commit?
<sterni>
https://status.nixos.org/ show channel status and as you can see there it is stuck since 4 days
<sterni>
matthewcroughan: nope it has already built that probably, but the channel is not advancing because nixUnstable is broken
grimvar_ has joined #nixos
<matthewcroughan>
When does it choose to advance?
<sterni>
01:02 <sterni> matthewcroughan: hydra continously updates to master and tries to build this job, if it succeeds, the channel advances to that revision for nixos-unstable: h
<judson>
I updated to 20.09 a little while ago, and it broke meld - I get a ton of GTK icon errors, but worse, it doesn't display text in a 3-way merge.
<matthewcroughan>
infinisil: is there any way to change the port that limesurvey listens on?
<matthewcroughan>
virtualHost.listen seems not to have an impact on that, sadly
<infinisil>
matthewcroughan: Yeah lists are pretty bad for that, because you can't refer to other definitions to change them
<infinisil>
matthewcroughan: You'll have to override the list completely instead, which can be done with `listen = lib.mkForce [ ... ]`
<remexre>
is there a way to change builtins.currentSystem? It reports x86_64-darwin on an M1 mac, but I want to build binaries for aarch64-darwin/aarch64e-darwin
<infinisil>
You'll have to just find the file yourself
<matthewcroughan>
infinisil: what do you think of git-lfs for backing up state.
<infinisil>
Never used that
<matthewcroughan>
I think the world would be better off stateless, but you could probably back up /var/lib on git lfs, might be a good use case for it.
<matthewcroughan>
any thoughts on that gchristensen? :D
dbmikus has quit [Ping timeout: 245 seconds]
acarrico has quit [Ping timeout: 256 seconds]
tgunnoe has joined #nixos
slack1256 has joined #nixos
marusich has joined #nixos
stree has joined #nixos
das_j has quit [Quit: Bridge terminating on SIGTERM]
mrpi has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
cheriimoya has quit [Quit: Bridge terminating on SIGTERM]
Scriptkiddi has quit [Quit: Bridge terminating on SIGTERM]
<aforemny>
EdLin: That is the current master branch. I did not notice I copied the commit hash before.
Boomerang has joined #nixos
<Boomerang>
Is there a way to build the documentation for a Rust package (crate) using nix?
<Boomerang>
I'm used to haskell packages where I can just build `.doc`
dbmikus has joined #nixos
<EdLin>
aforemny: 20.3 then? I was thinking of getting a radeon pro card that would be the most affordable 3440x1440 display-card option, but it only is supported by Mesa 21 believe it or not. :(
<EdLin>
I guess it'll be in there later, probably by the time I get it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pinpox>
I've setup nix-serve to have a binary cache I can use from multiple machines. Is it possible to have the cache be a diffent nix store than the host's one?
<pinpox>
I'm tryng to have all my machines read from my http cache when building, and a CI be able to push to the cache on new commits.
<pinpox>
I also read you can use a plain folder served via nginx as binary cache, is that true and if so how?
<clever>
pinpox: this creates a directory full of .narinfo and .nar.xz files, which you can then just host with nginx
<pinpox>
clever: what is the point of nix-serve then, is it just doing the same thing?
<clever>
nix-serve avoids doubling your disk usage, by serving what is in /nix/store, rather then you having to make a copy of everything
Mic92 has quit [Quit: WeeChat 3.1]
<clever>
nix-serve also saves you from having to figure out what to copy and when
Mic92 has joined #nixos
<pinpox>
I see. But if I build outside of the cache server itself, I will have to copy in all cases, right?
beertoagunfight has joined #nixos
<clever>
yeah, but you could leave it in the /nix/store of the cache server
arianvp has quit [Ping timeout: 244 seconds]
<pinpox>
you mean with nix-serve?
<clever>
yeah
is_null has joined #nixos
<pinpox>
My CI spawns a docker container for each build, some of them being nix docker containers. My goal would be to build inside that container (as it already does) but then "push" the result to the cache
mdash has joined #nixos
<clever>
there is also `nix copy --to s3://bucket /nix/store/foo`
<clever>
which will upload to S3 for you
arianvp has joined #nixos
<pinpox>
that's also nice. My main concern/question is how to make it as safe as possible, so that the ci doesn't something like a root key to be able to write to the cache
<pinpox>
I'f I understand correctly, using nix-serve the ssh-key/user that pushes to the cache has to at least be trusted, right? That would be pretty much the same as a root key if I'm not mistaken
<clever>
they can basically write any storepath that doesnt exist yet
<simpson>
You can attenuate the key, but something like a key will be needed in order to enable the write. However, IIUC the writing user doesn't need to be root.
<{^_^}>
[nixpkgs] @FRidh pushed 1000 commits to python-unstable: https://git.io/JYfSk
<clever>
simpson: but you can copy over a malicious build of sudo, and then when you nixos-rebuild --upgrade, "oh, i already have that sudo, no need to DL"
<clever>
simpson: and now that sudo has setuid
<pinpox>
clever: would't using a separate (s3 or http folder) nix store work around that problem?
<simpson>
clever: Yeah. Pick your formalism of choice, and it should be easy to prove that the only way to prevent this problem is to run the build on the cache server, using the same Nix store and build authority.
<pinpox>
So building *on* the server, is safer that building in docker and pushing afterwards?
<clever>
pinpox: the nix-daemon runs as root, and enforces that a given store path was made according to the directions in the .drv file, and hasnt been modified maliciously
zupo has joined #nixos
<simpson>
For this particular threat, yes. Nix stores are not aware of what packages *do* when executed; Nix only knows how to retrieve dependencies and recursively fetch needed packages.
<simpson>
So, as a result, a Nix store can't tell the difference between your CI jobs invoking a key, and some Mallory borrowing that key and invoking it with e.g. clever's sudo example.
<pinpox>
I see, then I'll probably have to build on the server itself. Actually I set up the separation inside docker to improve security, that was the whole point.
<clever>
pinpox: nix creates containers (using the same api as docker) to isolate all builds
Qwerky has joined #nixos
<pinpox>
clever: But a CI job would modify the /nix/store of the host, how is that not a problem?
<pinpox>
It could just delete everything or not?
<simpson>
Oh! Because, on NixOS, installing packages isn't a total system compromise. Think of a water balloon vs. a sponge; both leak when stabbed, but only one loses structural integrity completely.
<simpson>
The CI job can't arbitrarily modify the store. It can add stuff, but it can't remove packages that other folks are using, nor alter packages that are already configured.
<pinpox>
Ok that makes sense. So to sum it up: Instead of running ci jobs inside nix docker images and copying to the store afterwards, just run the jobs natively. That also avoids having to provide the ci containers with an ssh key to copy to the host and makes sure the build result is what I expect it to be and not something that has been tampered with,
<pinpox>
like a rogue sudo. Then use nix-serve to serve the store over http and have all machines use that cache
<clever>
pinpox: there are also things like hydra, which will farm the jobs out to remote hosts, you only need to trust that root hasnt been tampered with on the remote box
<clever>
the remote nix-daemon will enforce the same rules, and only somebody with root can violate them and polute the /nix/store your going to copy over
<pinpox>
clever: I'd have to look at hydra, but I'm already running droneCI which I need for non-nix stuff aswell
<jtojnar>
<yurb "Where is it supposed to be set?"> nixpkgs.config option
Qwerky has quit [Remote host closed the connection]
Qwerky has joined #nixos
respawn is now known as Guest74583
Guest74583 has quit [Killed (weber.freenode.net (Nickname regained by services))]
Qwerky has quit [Remote host closed the connection]
Guest74583 has joined #nixos
<yurb>
Jan Tojnar: thanks!
Chiliparrot has joined #nixos
Qwerky has joined #nixos
jb55 has quit [Ping timeout: 268 seconds]
vidbina has joined #nixos
Qwerky has quit [Ping timeout: 260 seconds]
Qwerky has joined #nixos
apeyroux has joined #nixos
<a12l>
I'm trying to install the Auctex package for Emacs, but I get a 404 error when Nix tries to download the package from GNU's mirror. It seems that it tries do download Auctex 13.0.4, but 13.0.5 is available on the website. So I've decided to try to submit an update of Auctex.
jb55 has joined #nixos
sangoma has quit [Ping timeout: 272 seconds]
<a12l>
I found the Nix expression in `pkgs/tools/typesetting/tex/auctex/default.nix`, but I got some questions. (1) Why is the version defined in the expression 12.3? Is there yet another weird GNU versioning scheme? (2) When I try to build auctex with the command `nix-build -A auctex` (just to check everything) I get the error message `error: cannot auto-call a function that has an argument without a default value ('lib')`.
<s1341_>
I'm trying to modify the aclocal.m4 of xorgserver, and I added autoreconfHook to the nativeBuildInputs, but it seems like autoreconf is overwritting my changes to aclocal.m4....
<s1341_>
supersandro2000: yeah. i ended up patching the produced configure directly.
<o1lo01ol1o>
I have a set of haskell package overlays that i need to combine with an overlay that disables tests on python27.pyopenssl but I don't seem to dealing with the python27 overlay correctly. Can anyone see where the stupid is? https://gist.github.com/o1lo01ol1o/6fccd0352bbdda69aea543ca5407e6b6
cab404[m] has joined #nixos
<cab404[m]>
o hai. anyone knows, whether steering committee has some public calls every now and then?
<cab404[m]>
like ones held in gnunet monthly
<cab404[m]>
* anyone knows, whether steering committee has some public calls every now and then?
<sterni>
drozdziak1: the members of the scope can be overriden individually and members of the scope can take other members of the scope as inputs individually
<infinisil>
amk: And note the `pythonPath =` assignment in the same file for dependencies, and the `nativeBuildInputs = [ python3Packages.wrapPython ]` which is also necessary
<drozdziak1>
sterni Would a scope be viabler f
<infinisil>
And note that it's just a stdenv.mkDerivation
hexagoxel has joined #nixos
<drozdziak1>
sterni sorry, hit enter too soon :P Would a scope be viable for achieving something similar to build-essentials in Ubuntu? Like a multipackage alias?
<Synthetica>
stevenleiva: NixOS or Nix on another distro?
zebrag has joined #nixos
<stevenleiva>
Synthetica: Nix on another distro (mac). I actually found what I was doing wrong. I should be using "nix-env -iA nixpkgs.imagemagick7Big" and instead I was using "nix-env -i imagemagick7Big". I could have sworn that the longer command did not work on other things I tried to install, but that's ok.
is_null has joined #nixos
endformationage has joined #nixos
kaliumxyz has joined #nixos
erasmas has joined #nixos
thc202 has quit [Read error: Connection reset by peer]
wnklmnn has quit [Ping timeout: 240 seconds]
malook has joined #nixos
zupo has joined #nixos
<stevenleiva>
btw - I only use nix as a package manager, but even for that use-case it is pretty awesome.
<jboy>
because they just failed for me with "kexec_load failed: Function not implemented"
<praduca>
hi
<praduca>
anyone know if nixops is being deprecated or something like that? I am asking because it was on my list of things to learn, and it disappeared from nixos.org lol
<yaymukund>
do packages built for a nix-shell invocation (specified in shell.nix) end up in /nix/store/? will they be removed when I next run nix-collect-garbage -d ?
Chiliparrot has quit [Ping timeout: 272 seconds]
<praduca>
should i learn other thing instead?
<praduca>
like terraform or something else
civodul` is now known as civodul
shibboleth has joined #nixos
fendor_ has joined #nixos
rubm has joined #nixos
<simpson>
praduca: The main NixOS site is focusing on Nix, NixOS, and nixpkgs, since those are the core of what everybody uses. Nixops is still a thing, if it fits your needs.
fendor has quit [Ping timeout: 245 seconds]
<simpson>
For example, many folks are using k8s these days, and so perhaps https://github.com/xtruder/kubenix is actually closer to what you want.
<praduca>
ah tks simpson i will see those (and nixops too, if it is still used i will study it)
scheibenkleister has quit [Ping timeout: 268 seconds]
notgne2[m] has quit [Ping timeout: 268 seconds]
Nezha[m] has quit [Ping timeout: 268 seconds]
rschulman has quit [Ping timeout: 268 seconds]
nikola[m] has quit [Ping timeout: 268 seconds]
beardhatcode has quit [Ping timeout: 260 seconds]
scheibenkleister has joined #nixos
Nezha[m] has joined #nixos
_urd[m] has quit [Ping timeout: 268 seconds]
samir420[m] has quit [Ping timeout: 268 seconds]
ero-sennin[m] has quit [Ping timeout: 268 seconds]
petrichor has quit [Ping timeout: 268 seconds]
emily has quit [Ping timeout: 268 seconds]
leons has quit [Ping timeout: 268 seconds]
AlesHuzik[m] has quit [Ping timeout: 268 seconds]
M86ul[m] has quit [Ping timeout: 268 seconds]
mica[m] has quit [Ping timeout: 268 seconds]
leon[m] has quit [Ping timeout: 268 seconds]
unclechu has quit [Ping timeout: 268 seconds]
FreeVariable has quit [Ping timeout: 268 seconds]
sebbadk[m] has quit [Ping timeout: 268 seconds]
omasanori[m] has quit [Ping timeout: 268 seconds]
cemguresci[m] has quit [Ping timeout: 268 seconds]
Yakulu[m] has quit [Ping timeout: 268 seconds]
CRTified[m] has quit [Ping timeout: 260 seconds]
DavHau[m] has quit [Ping timeout: 260 seconds]
bb__ has joined #nixos
bb_ has quit [Ping timeout: 268 seconds]
^x3ro[m] has quit [Ping timeout: 268 seconds]
dev-kcw[m] has quit [Ping timeout: 268 seconds]
wangoe[m] has quit [Ping timeout: 268 seconds]
Antoine01[m] has quit [Ping timeout: 268 seconds]
ma27[m] has quit [Ping timeout: 268 seconds]
v0lde[m] has quit [Ping timeout: 268 seconds]
questaetang[m] has quit [Ping timeout: 268 seconds]
Linus[m]11 has quit [Ping timeout: 268 seconds]
Ke has quit [Ping timeout: 268 seconds]
eliasp[m] has quit [Ping timeout: 268 seconds]
kevin_m02[m] has quit [Ping timeout: 268 seconds]
sk4l[m] has quit [Ping timeout: 268 seconds]
grin[m] has quit [Ping timeout: 268 seconds]
jdnixx[m] has quit [Ping timeout: 268 seconds]
jbarthelmes[m] has quit [Ping timeout: 268 seconds]
jschievink has quit [Ping timeout: 268 seconds]
zipfelsack[m] has quit [Ping timeout: 260 seconds]
M7yd3r[m] has quit [Ping timeout: 268 seconds]
rycee has quit [Ping timeout: 268 seconds]
Valodim[m] has quit [Ping timeout: 268 seconds]
vancoding[m] has quit [Ping timeout: 268 seconds]
bekkvann[m] has quit [Ping timeout: 268 seconds]
kunrooted[m] has quit [Ping timeout: 268 seconds]
mindtree[m] has quit [Ping timeout: 268 seconds]
notgne2[m] has joined #nixos
malik has left #nixos ["ERC (IRC client for Emacs 27.1)"]
linus0[m] has joined #nixos
palo has quit [Quit: WeeChat 2.9]
malbx- has quit [Ping timeout: 264 seconds]
beertoagunfight has joined #nixos
palo has joined #nixos
boredom101 has quit [Quit: Connection closed]
malbx has joined #nixos
dev_mohe has joined #nixos
Qwerky has joined #nixos
<beertoagunfight>
Hi there. I'm trying to package my first derivation and I'm running into hiccups with passing the correct `DESTDIR` to make. I've tried a bunch of things, but I can't seem to get the output to copy to the right destination :-( - https://pastebin.com/8vX6r5BB - Corresponding Makefile https://github.com/jeremija/unipicker/blob/master/Makefile
<Guest1>
why firefox spits so many warnings/errors if launced from terminal?
sebbadk[m] has joined #nixos
<Guest1>
is it same in other distros
Yakulu[m] has joined #nixos
<gchristensen>
it is the same
v0lde[m] has joined #nixos
jschievink has joined #nixos
questaetang[m] has joined #nixos
<beertoagunfight>
sterni: Ah shit yes, line 1 :-)
^x3ro[m] has joined #nixos
ma27[m] has joined #nixos
wangoe[m] has joined #nixos
eliasp[m] has joined #nixos
Ke has joined #nixos
Antoine01[m] has joined #nixos
jdnixx[m] has joined #nixos
dev-kcw[m] has joined #nixos
<beertoagunfight>
sterni: Is there something that I can lookup that allows me to patch it without copy-pastaing the original Makefile?
zipfelsack[m] has joined #nixos
sk4l[m] has joined #nixos
kevin_m02[m] has joined #nixos
<Guest1>
gchristensen I have this weird issue https://github.com/NixOS/nixpkgs/issues/106018 (someone else opened it), xfce4-session command fixes it, any idea what's going behind the scenes?
n-osborne has quit [Remote host closed the connection]
ManiacOfMadness has joined #nixos
<radvendii>
I have a couple of questions about minimizing the closure of a package. First, it seems like nativeBuildInputs are included in the closure. Is that right? Why? The package shouldn't be depending on anything in there at runtime, right?
<radvendii>
cole-h: right, exactly. that's why I'm confused why they show up in the closure
<radvendii>
like, would nix-copy-closure copy over the nativeBuildInputs?
<radvendii>
because nix-store -qR shows the nativeBuildInputs as dependencies
m0rphism has joined #nixos
<tpw_rules>
remember that store paths are considered runtime dependencies iff their hash shows up in the build output
<tpw_rules>
so there is something in the derivation that is doing that. i could make a derivation that's like { nativeBuildInputs = [ cmake ]; installPhase = ''cat ${cmake} > $out/lol.txt''; } and it would make cmake a dependency in the closure even though it's in nativeBuildInputs
<radvendii>
because what I have is {nativeBuildInputs = [ appimagekit ]; buildCommand = ''appimagetool foo; ...''}
<tpw_rules>
afaik this mostly happens when the built derivation remembers things about its build environment. like it writes a log file to the output containing a path to the compiler or whatever
<tpw_rules>
i don't know anything about appimagekit or how that command works, but if nix-store -qR says appimagekit is being retained as /nix/store/<some_hash>-appimagekit-1.23 or whatever, grep all the files in the output directory for your derivation for that hash
<tpw_rules>
then figure out why that is getting written there, and stop it
<radvendii>
O.o
<radvendii>
you're right
<radvendii>
the output is a binary file, but for some reason it contains the hash
<radvendii>
ohh
FRidh has quit [Quit: Konversation terminated!]
<radvendii>
so as part of the compilation process I'm copying all the nix store paths into a local directory so I have "./nix/store/<hash>-<name>/..."
<radvendii>
would that cause it to be considered a runtime dependency?
<tpw_rules>
like i said before, the rule is that if <hash> is present in any file anywhere in the output, then the store path containing that hash is a runtime dependency
tgunnoe has quit [Ping timeout: 245 seconds]
<tpw_rules>
you probably shouldn't be doing that though. that might cause the wrong paths to appear in the output
<radvendii>
gotcha, okay thanks. this helps immensely
gustavderdrache has quit [Quit: Leaving.]
<tpw_rules>
the reason that is the rule is that presumably if the output contains /nix/store/<hash>-<name>/..., the output needs that file at runtime, which is true almost all the time
<tpw_rules>
but conversely if the output contains blah/my_build_dir/nix/store/... then the output won't be able to find that file because blah/my_build_dir doesn't exist at runtime
<tpw_rules>
if it doesn't need it, then the closure is bigger than necessary, but whatever. if it DOES, then the output will be broken
<radvendii>
if I patchelf --shrink-rpath i think it will go away
<cole-h>
radvendii: You have to remember: it's in the closure because it is required to build.
stree has quit [Ping timeout: 268 seconds]
<radvendii>
the closure is everything required to build? not everything required to run?
<cole-h>
it's both, but there's a difference between runtime dependencies as in libraries (e.g. glibc.so), and runtime dependencies as in binaries (e.g. .../bin/bash)
<radvendii>
right, yeah. that makes sense
beertoagunfight has joined #nixos
<cole-h>
if the program `exec`s into another binary, Nix can't discover that unless you replace it in the source
<cole-h>
however, due to the magic of patchelf, Nix *can* discover if it needs to add a dynamic library to the resulting binary's rpath
<cole-h>
(note that, for most packages, the fixupPhase runs patchelf --shrink-rpath on all resulting binaries)
<radvendii>
yeah, this is a bit of a weird case. I just set buildCommand. and actually, in this case I can use --set-rpath "" instead of --shrink-rpath
Lord_of_Life_ has joined #nixos
<radvendii>
i'm building an appimage, so the nix store isn't guaranteed to be around anyways
<radvendii>
(i'm working on building infrastructure so that people can easily convert nix derivations into appimages that can run on other systems)
<tpw_rules>
it wouldn't work for any form of dynamic decompression like squashfs, which that page says appimage uses
<radvendii>
ah, yeah
<radvendii>
So far I have the appimage working on ubuntu 20.10. It doesn't work on older versions, so I need to get everything linking against an older version of glibc
<radvendii>
once i'm done with that, i'm going to try to optimize the output file size
<radvendii>
right now i'm getting ~150M
<tpw_rules>
for firefox?
missionformilk has quit [Ping timeout: 264 seconds]
stree has joined #nixos
dev_mohe has joined #nixos
yoctocell has joined #nixos
dev_mohe has quit [Client Quit]
<radvendii>
haha no. I guess 150M is meaningless because it's for my own project
<radvendii>
I should test it on firefox
yoctocell has left #nixos ["ERC (IRC client for Emacs 28.0.50)"]
<afreakk>
my /boot partition is having issues, could i format a fat-partition on another hdd, and then move fileSystems."/boot" = { device = "/dev/disk/by-uuid/my-newlyformated-drive"; } and run nixos-rebuild again ? or am i missing a important step
<philipp[m]1>
Can somebody explain to me why the libnice headers are not found here and the build fails?
bahamas has quit [Ping timeout: 256 seconds]
<mvnetbiz_>
I wonder if the home-manager module is just broken, it doesn't work for me either
<matthewcroughan>
mvnetbiz_: seems likely :D
<matthewcroughan>
It's worth noting that some other qt apps do not have this same issue.
<matthewcroughan>
like wofi
<radvendii>
tpw_rules: just got it working with firefox. it's 269M, about 3x as big as another AppImage for it I found online (there's no official AppImage for firefox)
ahmedelgabri has joined #nixos
<matthewcroughan>
nvm that's gtk
<unclechu>
hey, if i do something like `pkgs.runCommand "foo" { str = "${pkgs.someapp}/bin/someapp"; } "echo $str > $out"`
<unclechu>
will the `pkgs.someapp` be garbage collected? or will it be a dependency?+
<unclechu>
runtime dependency i mean
<radvendii>
from what i've just learned, it will be a runtime dependency
<tpw_rules>
radvendii: oh, the original nix-bundle came up with 150M
<radvendii>
if the hash of a package appears in the output anywhere, it is counted as a runtime dependency
<unclechu>
radvendii: “not unless” is just “if”, right?
<radvendii>
but that's also true of things in buildInputs I think
zakame has quit [Ping timeout: 264 seconds]
<radvendii>
yeah, if you get the hash into the output, it will be in the output, if you don't, it won't be there. there's nothing about putting a package in nativeBuildInputs that automatically adds it as a runtime dep
<unclechu>
radvendii: i mean `nativeBuildInputs` is supposed to not add stuff to runtime dependencies. it supposed to only provide stuff while building a derivation
<radvendii>
tpw_rules: do you happen to know how to add cflags to the gcc package using an overlay? NIX_CFLAGS_COMPILE isn't doing anything, and i think it has to do with gcc's custom builder, but I can't work out how *to* add cflags
novafacing has joined #nixos
<radvendii>
unclechu: yeah, that's what I thought too, but it's not always the case
<unclechu>
so those dependencies are technically can be garbage collected. if i understand it correctly
<tpw_rules>
unclechu: the set of runtime dependencies is exactly the set of store paths whose hashes appear in the output. you could put the entire nixpkgs collection in nativeBuildInputs, or buildInputs for that matter, and it would generate the same program
<tpw_rules>
(the hash would be different because the inputs are different, so there is an incentive to reduce the number of items to the minimum)
<unclechu>
tpw_rules: sorry, what’s the point of use `nativeBuildInputs` then?
apeyroux has quit [Ping timeout: 256 seconds]
<unclechu>
i’ve been told earlier that i put “build time dependencies” to “nativeBuildInputs” and “runtime dependencies” to “buildInputs”
<tpw_rules>
unclechu: if you are cross-compiling, nix will provide nativeBuildInputs with architecture of the host machine and buildInputs with architecture of the target
<tpw_rules>
i would say it's probably an error if something from nativeBuildInputs appears as a runtime dependency because then the package will break if cross-compiled. but there's nothing strictly stopping it
novafacing has quit [Read error: Connection reset by peer]
novafacing has joined #nixos
<radvendii>
in theory we could check that and error (or at least warning) if it happens, no?
<unclechu>
tpw_rules: so, if i pull a binary program from cache i always have to pull its compiler?
<tpw_rules>
unclechu: no, because the compiler's store path does not appear in the output
<tpw_rules>
unclechu: yes. you've generated an output which uses gcc to build your program when run. so gcc is a runtime dependency of that output
<unclechu>
tpw_rules: so how do i make it to be **not** a runtime dependency? to not appear in the output (it can be not just gcc but whatever, say nim compiler)
<tpw_rules>
unclechu: use some manner to delete it. there is the remove-references-to script in nixpkgs
<tpw_rules>
but for most packages that doesn't happen
<unclechu>
tpw_rules: so by default, whereever you place a dependency, it appears in the output? but there is a helper that gives you ability to remove it from the runtime?
<unclechu>
tpw_rules: but how about the example i’ve shown above, you said gcc is added to the runtime dependencies
<tpw_rules>
by default, none of the dependencies appear in the output. if, during the build process, the hash of a dependency is written to the output in some manner, whether part of a binary, in a config file, a shell script, etc., then that dependency is considered a runtime dependency
<unclechu>
tpw_rules: so does nix parse $out contents (as plain text) and tries to find hashes of the nix store? does it tries to find just hashes or full nix store paths?
<tpw_rules>
yes, that's exactly what nix does. it just searches for the hash part
<unclechu>
tpw_rules: you said about my example: “yes. you've generated an output which uses gcc to build your program when run. so gcc is a runtime dependency of that output”
<unclechu>
to shrink you said that it is a runtime dependency
<unclechu>
and now you are saying that my example is fine and gcc is not a runtime dependency?
<tpw_rules>
runCommand is a derivation which writes a shell script to the store with the contents you specified (then runs it). of course that shell script needs gcc as a dependency, because it calls gcc to compile the program
lsix has joined #nixos
<unclechu>
tpw_rules: yeah, maybe i wasn’t clear. i mean exactly the result of `runCommand`, not the dependencies needed for the `runCommand` to build
<tpw_rules>
presumably you would use the output of gcc in a second derivation. that second derivation would not depend on gcc, or the first derivation, because their hashes don't appear in it
<unclechu>
tpw_rules: what if i do something like this: `runCommand "foo" {} '' mkdir $out; ln -s -- ${file} $out/ ''`
<unclechu>
will nix find it as a hash reference? or the dependency will be GCd?
<tpw_rules>
what dependency?
<unclechu>
and i should always copy files instead of making symlinks?
<unclechu>
tpw_rules: the `file` derivation
<matthewcroughan>
Bah this is confounding ;D
<tpw_rules>
yes it would be
<tpw_rules>
i believe?
<tpw_rules>
i think symlinks between store paths is kind of verboten
<radvendii>
okay i figured out the problem
<radvendii>
i think
<radvendii>
unclechu: tpw_rules
hyiltiz has quit [Ping timeout: 246 seconds]
<radvendii>
i haven't read the last couple messages so maybe you already figured it out
<radvendii>
but if i'm understanding correctly, this is the same problem i was encountering
<radvendii>
runCommand sets it's buildCommand to the string you pass in
<radvendii>
so it bypasses the patchPhase
evils has quit [Ping timeout: 256 seconds]
<radvendii>
which means that it doesn't do patchelf --shrink-rpath
<radvendii>
so you still end up with the gcc libs in the rpath
<radvendii>
which is why it ends up as a runtime dependency
<radvendii>
even though it doesn't need to
<nicolas[m]>
Hi, what is the new way to do `nix flake update --update-input` since `--update-input` has been removed?
cfricke has quit [Ping timeout: 260 seconds]
<radvendii>
^^ I also have that question
<tpw_rules>
maybe use nix flake lock instead?
<unclechu>
tpw_rules: so, it does not matter what dependencies i put either to `buildInputs` or `nativeBuildInputs` or interpolate inside the building script
<unclechu>
the result won’t depend on those derivations unless nix is able to find hashes in the $out?
zebrag has quit [Quit: Konversation terminated!]
<tpw_rules>
unclechu: exactly
<nicolas[m]>
tpw_rules: thanks, that seems to do the trick!
zebrag has joined #nixos
<unclechu>
tpw_rules: thanks, that’s new for me, and clarifies stuff
<tpw_rules>
bear in mind that the hash of the output is a function of the hashes of all the inputs though. so if buildInputs contains stuff that's not used, and that stuff changes, then your thing will be recompiled even though it never uses the input and the output won't change
<radvendii>
tpw_rules: is there no need to be concerned about a hash appearing randomly in some binary file?
<radvendii>
i guess that's kind of the point of hashes? that they would be very unlikely to appear randomly?
zeroability[m] has left #nixos ["User left"]
<tpw_rules>
it searches the base32 string representation, and only of the inputs you specify. so if it does then you've broken SHA-256 and the NSA would like to employ you
<tpw_rules>
or have you offed
<radvendii>
hahaha okay, fair enough
rippla has joined #nixos
<radvendii>
"The NSA would like to know your location"
ManiacOfMadness has joined #nixos
<rippla>
oh no
<tpw_rules>
anyway i gotta run. i think this "searching the output" trick is something that people see once in the beginning of nix and forget about, but it's really a key piece of the magic that is behind truly understanding a lot of nix aspects
<radvendii>
tpw_rules: yeah, thanks for walking through that with us
<unclechu>
tpw_rules: i’m just wondering now, what if i compile a program, and provide some path to a derivation to a preprocessor for instance
<unclechu>
does that mean that nix doesn’t add this hash to the output and the runtime dependency can be GCed?
<unclechu>
but compiled binary that’s saved to $out has that value (path to a runtime dependency) encoded somehow weirdly, say to base64, and nix couldn’t find the hash
fendor_ has quit [Remote host closed the connection]
<radvendii>
correct
<rippla>
How can I find out if systemd timers created by nix will run on next boot if my system was offline during the time the action was planned?
<radvendii>
In building my AppImage, there are a lot of dependency paths that get mashed when the system gets archived, and they don't show up as runtime build inputs
<rippla>
it's about docker.autoPrune in my case
<radvendii>
in my case, that's what I want, but it could screw you up in another situation
fendor has joined #nixos
<unclechu>
radvendii: so i’d just keep that in mind and whenever i have doubts i would add a shell wrapper or whatever where i store the hash in a comment, or in a dummy file, or however else, just to make sure nix can extract that hash as text?
<radvendii>
yeah, that should work
<radvendii>
I don't think it would come up that often though. idk if i would do it "whenever you have doubts"
<radvendii>
you can always check it by compiling the program, GCing, and then seeing if it still runs
<radvendii>
there might be a simpler way, but that's how i would test it
<unclechu>
i don’t want to GC my system too often because i have some `nix-shell`s cached that i don’t want to rebuild too often
<unclechu>
radvendii: i assume nix is able to extract linked *.so libraries from binary executables? otherwise it would be a common problem that the dependencies are missing
pushqrdx has quit [Remote host closed the connection]
simba1 has joined #nixos
hyiltiz has quit [Ping timeout: 260 seconds]
<radvendii>
you can test this in two ways, (1) you can just run `cat /nix/store/<package>/bin/executable | grep <hash>` and it will say "executable matches search" or something like that (2) you can run `patchelf --print-rpath /nix/store/<package>/bin/executable`
<radvendii>
is there any way to modify cc-wrapper with an overlay? it doesn't seem like it because it's called as (import path/to/cc-wrapper) in several places in nixpkgs
<pushqrdx>
this seems to be building a cd of a checkout tho i want to build out of my current system
<pushqrdx>
because i have some overlays that i want to baked in
__monty__ has quit [Quit: leaving]
kini has quit [Remote host closed the connection]
<tpw_rules>
i think you just check out the nixpkgs your config is based on, import that nixos-config module into your config, then pass it as -I nixos-config=myconfig.nix
ddellaco_ has quit [Ping timeout: 264 seconds]
kini has joined #nixos
<pushqrdx>
tpw_rules hmm into what config, i am confused
<tpw_rules>
your config.nix
<tpw_rules>
that you want to turn into an iso
<tpw_rules>
include that minimal-cd module
<rmcgibbo[m]>
if anyone's an expert with pkgsStatic and -fPIC and muscl and stuff like that, https://hydra.nixos.org/build/139776781 might be a good puzzle. i was half able to bisect it to some change in mkDerivation's default treatment of hardening flags, but i wasn't able to figure out how to fix it.
<pushqrdx>
tpw_rules sorry can we rewind a little bit what minimal-cd module :D
<pushqrdx>
nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix
<tpw_rules>
the nix-build command that page provides