<clever>
Mic92: basically, propagated-user-env-packages will silently collide, and one will just win over the other, leading to fun breakage
<clever>
you have no way of detecting that until after it breaks things, and its not easy to track down what caused qt 5.9.0 to be installed, since nix-env -q says you never asked for it
<Mic92>
clever: yes, for the same reason you can no longer use qt apps in a nix-shell properly
<Mic92>
it used to have a shell wrapper before
<clever>
i feel that any use of propagated-user-env-packages defeats the entire point of nix
<clever>
because you can no longer have conflicting versions of qt co-existing
<Mic92>
`Qt plugins are now installed in a different prefix for each minor version to prevent conflicts`
<clever>
Mic92: oh, i just had a thought
<clever>
the plugins are burried under ~/.nix-profile/lib/qt-5.9/
<clever>
what if they where instead under /lib/qt-5.9.0/ ?
<clever>
one more version element, and the conflicting ones can co-exist
<Mic92>
lib/<hash>-qt-<version>
<clever>
adding a hash makes it harder to provide plugins to everything the user has installed
<clever>
it would only be able to update things built against the exact version the desktop env was built with
<Mic92>
maybe something similar like `texlive.combine`
<clever>
any kind of functional stuff to combine things would pull everything from the same nixpkgs, and it would all be the same version
<clever>
so the problem wouldnt even exist
<Mic92>
but then you can have still mix stuff
<Mic92>
in dependent function
goibhniu has joined joined #nixos-dev
srodal has quit [(Ping timeout: 252 seconds)]
FRidh has quit [(Quit: Konversation terminated!)]
FRidh has joined joined #nixos-dev
srodal has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 246 seconds)]
Mic92 has quit [(Quit: WeeChat 1.9.1)]
Mic92 has joined joined #nixos-dev
jtojnar_ has joined joined #nixos-dev
FRidh has joined joined #nixos-dev
<copumpkin>
niksnut: would you expect the batch binary cache existence check to be slower for S3 binary caches than for HTTP ones? I have a vague sense that it is but haven't done any precise measurements
kuznero has joined joined #nixos-dev
<aminechikhaoui>
niksnut: do you think the queries of valid paths done by nix copy --all for example could be made parallel somehow ? from what I see currently in the threads running, only one thread is doing the queries
<kuznero>
Hi All! I would like to express the desire to become a nixos github org member (eventually).
<niksnut>
aminechikhaoui: yes
<niksnut>
copumpkin: no
<gchristensen>
copumpkin: the only thing about s3 is it is actually a bit slow
srodal has quit [(Ping timeout: 240 seconds)]
<gchristensen>
so maybe s3 is just slower than your other http one
<copumpkin>
maybe that's it, but it's S3 via unauthenticated HTTP vs. S3 authenticated
<copumpkin>
I guess the authentication has some overhead but it doesn't seem like it would affect this much
<copumpkin>
anyway, I'll measure and see if it's substantial
<aminechikhaoui>
niksnut: also does nix copy caches the results in the local disk binary cache ?
<niksnut>
the NAR cache?
<aminechikhaoui>
niksnut: I mean the results of the queries done by nix copy
<aminechikhaoui>
in a way that if I stop the nix copy cmd, it doesn't start over from the beginning and get the queries results direcly from .cache/nix/binary* stuff
<niksnut>
yes, it should be cached
seppellll has joined joined #nixos-dev
<aminechikhaoui>
cool, thanks
<aminechikhaoui>
niksnut: also btw nix copy doesn't seem to respect SIGINT signal and keep running even if I do Ctrl-c
<niksnut>
yeah there are a couple of places with sigint isn't working properly atm
<niksnut>
please make an issue about it
<aminechikhaoui>
sure :)
<gchristensen>
or a PR! :)
<aminechikhaoui>
oh I would love to start with tiny fixes like this as PRs :D maybe I'll try playing with it
<copumpkin>
niksnut: btw, if you need some signal about suitability of 1.12 for release, I've been "testing" 1.12 pretty hard over the past few months and it's been working pretty well for me/my team, apart from the occasional random deadlock ;)
<niksnut>
great :-)
* gchristensen
should switch
<copumpkin>
haven't done too much with the new UI, though
<gchristensen>
that seems like the most hugely important thing to be testing!
<copumpkin>
`nix copy` all over the place but I mostly still use the older tools
<copumpkin>
well, everything else got rewritten in C++ too, plus all the store hierarchy getting redone
<copumpkin>
so still a fair amount of new code being covered :)
<gchristensen>
yeah, true
<copumpkin>
oh, I do occasionally use `nix show-derivation` to explain things
<copumpkin>
:D
<aminechikhaoui>
`nix show-derivation` together with jq is the shit :D
<aminechikhaoui>
(where is the shit == is the best ) :p
<copumpkin>
sure :)
<copumpkin>
aminechikhaoui: does your binary cache have WantMassQuery: 1?
<aminechikhaoui>
copumpkin: not sure what you're trying to do there, why not just nix copy --all --to <s3_uri> ?
<aminechikhaoui>
or is that a different use case
<copumpkin>
I'm saying if the S3 binary cache already has all the stuff in it
<copumpkin>
I don't want to download it all, build, and then have nix copy decide it's not worth uploading it all
<copumpkin>
anyway, I could use --all, but that doesn't really cover my core question
<copumpkin>
right now my internal expressions have a closure of about 15GB
<copumpkin>
so every machine that tries to populate the cache needs to download a decent amount of crap each time for no reason
<aminechikhaoui>
copumpkin: ah I see your point
<copumpkin>
in my case I only use throwaway build machines
<copumpkin>
so they have no real persistent cache
<cransom>
re: random talk around interwebz - i was in a presentation about reproducible builds and my heart fluttered a little bit when they mentioned other projects also working on it, including nix.
FRidh has quit [(Ping timeout: 255 seconds)]
<aminechikhaoui>
hm weird, after a good ~30min of querying I got this
<aminechikhaoui>
AWS error '' (Unable to connect to endpoint), will retry in 0 ms
<aminechikhaoui>
error: AWS error fetching 'zzwpmdxvwag4s9nf3saiaq896wa6hkvg.narinfo': The AWS Access Key Id you provided does not exist in our records.
<aminechikhaoui>
strange, it's like the nix-daemon suddenly ignored the env vars credentials even-though it was querying just fine in the beginning
<copumpkin>
are they temporary creds?
<copumpkin>
like AssumeRole or similar? those expire
<copumpkin>
I didn't think they access key ID changed but I haven't paid close attention
<aminechikhaoui>
copumpkin: nope valid creds passed through systemd.services.nix-daemon.serviceConfig.EnvironmentFile
<copumpkin>
so IAM user creds (just access key and secret key)
<aminechikhaoui>
right yeah
<copumpkin>
not sure then, unless someone revoked your access key :P
<copumpkin>
could also be a weird S3 thing (if you try again, does it work?
<copumpkin>
like this stuff fails for all sorts of unpredictable reasons behind the scenes
<aminechikhaoui>
copumpkin: seems more like an S3 weird thing :P re-running the cmd now and it seems working fine
<aminechikhaoui>
but pretty frustrating if it fails at the end