<globin>
if you have any ideas for nice stats fire away
<copumpkin>
niksnut: if I want to use a signed binary cache and an unsigned one (with different priorities), how might I do that? It seems like the `signed-binary-caches` isn't really checked in 1.12 beyond emptiness, and there's a require-sigs parameter on a store URI that looks promising...
<niksnut>
you can't
<Mic92>
zimbatm: I can try to rebuild, or do you want to use your own machine for the rust pr
<zimbatm>
I had 1 successful nox-review, rebasing now
<zimbatm>
Mic92: it's fine, I'm rebuilding
<zimbatm>
Mic92: what do you think of the PR, is it shaping up nicely?
<zimbatm>
there is still stuff I am unhappy with but I think it will be good enough(tm)
<zimbatm>
I wish we had pkgs/lang/<lang> instead of splitting things all over the place
<Mic92>
zimbatm: is the git-stuff still broken?
<zimbatm>
right now it's a mix between all-packages.nix, build-support/<lang> dev/compilers/<lang> dev/<lang>-modules, ...
<gchristensen>
zimbatm: the problem with tree structures is there is no adequate breakdown
<zimbatm>
Mic92: yeah
<zimbatm>
it depends on upstream cargo support I think
<Mic92>
zimbatm: too bad, then I have to pin my terminal emulator
<zimbatm>
alacritty?
<gchristensen>
I think triton's sharding on first-letter makes most sense than a topical breakdown
<Mic92>
zimbatm: but that version in question was released?
<Mic92>
zimbatm: yes, that one
<zimbatm>
yeah alacritty is still broken for now
<zimbatm>
there is also a rust upgrade to do...
<zimbatm>
I'm tempted to merge the PR and do a second-one for the rust+cargo upgrade
<Mic92>
zimbatm: since you kicked cargo local-registry, git should be supported now
<Mic92>
cargo vendor does handle it
<Mic92>
since 0.1.12
<zimbatm>
*should*
<zimbatm>
I'm still getting errors like "error: the lock file needs to be updated but --locked was passed to prevent this"
<Mic92>
ok
<zimbatm>
maybe the --locked argument can be removed
<zimbatm>
as long as it's not doing network access it should be fine
<Mic92>
zimbatm: ah, you have still the old cargo
<Mic92>
so maybe with next version upgrade
<zimbatm>
cargo-vendor is a binary build though
<zimbatm>
yeah maybe
<Mic92>
looks at least less confusing now
<Mic92>
it took my several approaches to understand how buildRustPackages works
<Mic92>
and since cargo-vendor is maintained by a core rust maintainer it will hopefully continue to work in future
<Mic92>
the workload of alexcrichton is insane.
<zimbatm>
yeah, I also think that the cargo-vendor will be successful in other contexts
<zimbatm>
he's a beast
infinisil has joined joined #nixos-dev
<zimbatm>
one thing I think is missing for rust is an easy way to generate -bin releases
<zimbatm>
we should expose the rustBinary builder to the user
<Mic92>
zimbatm: you mean pre-build releases from mozilla?
<zimbatm>
yeah
<Mic92>
zimbatm: rustNightlyBin
<zimbatm>
right, I removed it in the PR :d
<zimbatm>
I don't think that nixpkgs should distribute nightly builds but I'm going to expose the underlying construct
<zimbatm>
that way it's easier for user to pick a specific release and not spend hours re-building rust
FRidh has quit [(Ping timeout: 248 seconds)]
<Mic92>
I think it is also useful to have a nightlies in nixpkgs since some tooling still depends on it, but this might change
<copumpkin>
niksnut: would it make sense to specify "this is the store URI you build on" vs. "these are the store URIs you should use as binary caches"
goibhniu has quit [(Ping timeout: 255 seconds)]
jushur has quit [(Read error: Connection reset by peer)]
<Sonarpulse>
manual tested and ready to go on master
zarel has quit [(Quit: Leaving)]
zarel has joined joined #nixos-dev
zarel has quit [(Quit: Leaving)]
JosW has quit [(Quit: Konversation terminated!)]
florianjacob has joined joined #nixos-dev
<catern>
Anyone else get a chance to look at https://github.com/NixOS/nixpkgs/pull/29785 and express some feelings about what approach I should take, given that it grows the closure a fair bit?