drakonis has quit [Remote host closed the connection]
xeji has quit [Quit: WeeChat 2.1]
pxc has quit [Ping timeout: 252 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 252 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 252 seconds]
pxc has joined #nixos-dev
pxc has quit [Quit: WeeChat 2.1]
init_6 has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
joseph-gl has joined #nixos-dev
<lopsided98>
I think something is broken with the fetchurl Nix builtin
<lopsided98>
I am using nix unstable (which was just updated in nixpkgs) and when I tried to start an armv7l mass rebuild it failed with a checksum mismatch for bootstrap-tools
<lopsided98>
It turns out that it is unpacking bootstrap-tools, even though the unpack attribute is not set
<{^_^}>
nixos-channel-scripts#22 (by samueldr, 46 seconds ago, open): Fixes channel going back in time due to incomplete change.
<samueldr>
alternatively, hydra could also provide an URL which represents the newest-change-that-completed; and using it instead of latest-finished (if it even makes sense internally in hydra)
FRidh has joined #nixos-dev
goibhniu has joined #nixos-dev
garbas has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
jtojnar has quit [Ping timeout: 252 seconds]
FRidh has quit [Remote host closed the connection]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
<gchristensen>
samueldr: nice!
<gchristensen>
lopsided98: maybe open a bug on Nix?
orivej has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
<ekleog>
(triage) I think this needs closing https://github.com/NixOS/nixpkgs/pull/41285 ; unless someone tries to make @r-ryantm's errorred updates correct again, people might think it's already being handled while it's not :)
<gchristensen>
samueldr: w.r.t. your PR I really appreciate and value your willingness to get your hands dirty and experiment with fixing problems you can't easily replicate.
init_6 has quit [Ping timeout: 244 seconds]
<samueldr>
gchristensen: ♥ I like how I have the knowledge to actually work on fixing things
<samueldr>
and how the community here makes it a no-brainer to just do it
<samueldr>
no layers of red tape
<samueldr>
and everything is just there, laying, for everyone to look at
<infinisil>
samueldr++
<{^_^}>
samueldr's karma got increased to 13
<infinisil>
samueldr: Very nice effort you're putting into nixpkgs recently, props to you!
<infinisil>
samueldr: Haha I was just reading that and am confused as well
<samueldr>
I mean, they're not necessarily wrong... but don't move the conversation in any way :/
<infinisil>
samueldr: I just hope the PR won't stall because no consensus can be reached. It is a no-brainer in my opinion, but apparently not for everybody
<gchristensen>
I think the changelog is the appropriate place fo rit
<gchristensen>
adding big fat throw strings on removal is not the right way to go
<infinisil>
gchristensen: Tbh, very few people read the changelogs, and even more so for people that would benefit from such errors
<infinisil>
A throw is simple and cheap, no need to keep the old version around, it can be removed, and it is 100 times better UX
<gchristensen>
changelogs are good public records of important changes, and our NixOS changelogs aren't so substantial -- very high value changelogs. we can change the culture around Nix users to be about reading good changelogs.
<gchristensen>
also, I'm not 100% against a throw, but
<gchristensen>
adding big fat throw strings on removal is not the right way to go
<Dezgeg>
so how about we replace nix-repl with a script which is 'echo "nix-repl is deprecated, use 'nix repl'"; exec nix repl "$@"' ?
<gchristensen>
sounds good to me :)
<gchristensen>
with the addendum of adding a >&2 on the echo :)
<samueldr>
gchristensen: I think that's right that fat throw strings are wrong; but the UX for the end-user suffers greatly when it ends up looking like a programming language error instead of a nudge "hey look there's something that changed"
<samueldr>
(which is why I said it'd be interesting to have something semantically more appropriate)
<gchristensen>
also can we make Nix better at this?
<samueldr>
probably!
<samueldr>
but for this I think that as a community the topic has to be brought up in an abstract way
<gchristensen>
yeah
<infinisil>
But when we have such a replacement script, users might only notice at runtime that they can't use nix repl because they're still running nix 1.x
<samueldr>
every time a related issue pops up it feels the contributors and members are hung up on the particular case
<samueldr>
Dezgeg: does `nix repl` work with nix 1.11 as daemon?
<samueldr>
1.11 is still marked as supported for 18.09, which is the source of this head-achy situation
<samueldr>
heache-inducing*
<Dezgeg>
huh, I thought we don't, given that many things (like building ISO images or nixos tests) require nix 2.0
<{^_^}>
nix#2016 (by matthewbauer, 21 weeks ago, open): Multi-user installer (macOS) should support upgrades
<gchristensen>
I wouldn't worry about 2016 for this decision
<samueldr>
(as stated in their comment in the minimal version PR)
<samueldr>
oh
<samueldr>
gchristensen: why isn't it a worry?
<gchristensen>
the upgrade process (as demonstrated by matthewbauer) is not so complicated to be the blocker
<gchristensen>
IMO anyway
<infinisil>
Regarding nix-repl, the state of master right now is not okay imo. Either we add a throw, or a replacement script (not as nice imo). And if nobody is going to open a PR for the latter (along with arguments why it's supposedly better), the former should be merged.
<samueldr>
the only argument for a script vs. throw *that I can think of* is that the script doesn't break automated builds, only the systems relying on such builds
<samueldr>
(assuming `nix repl` isn't structurally compatible in some use cases)
<infinisil>
Ah yes that's an argument, but we need to somehow mention to people they should remove it from their configs, otherwise we could never remove anything
<gchristensen>
I think adding "gone" notices require an RFC
<samueldr>
it does
<gchristensen>
we have a well-known location for "changes you have to make to your configuration for it to keep working" and they're changelogs
<samueldr>
there is one bit of trivia I'd like to ask: how much of the changelog is being changed in-situ with the PRs causing the need for the changeloe update? (I know, this is orthogonal to the issue)
<gchristensen>
on major stuff I think it is commonly done, but not done enough
<samueldr>
:) sorry if it derailed you
<infinisil>
I won't be writing an RFC for a change that obviously increases UX like that. If it doesn't get merged, I'll just wait for the people in IRC complaining about it
<samueldr>
infinisil: the RFC isn't necessarily about the code and implementation, but can be about the *process*, and the requirements to keep the UX right when an attribute vanishes
<gchristensen>
the problem isn't nix-repl, the problem is the next 100, and the next 1,000 packages like this
* samueldr
thinks about gnome2 and gnome 2 accessories
<infinisil>
Ah, i guess this is actually in scope for my rfc im writing right now
<samueldr>
infinisil: that's what I was nudging towards, could be relevant if not directly related
<infinisil>
But that will take some time to finish, and i'd rather not annoy anybody with such errors, a warning really isn't that bit of a deal
<infinisil>
big*
<gchristensen>
they're a fact of life with Nix
<samueldr>
infinisil: fyu I was going to go cunningham's and merge one of the "fix" for the nix-repl attribute before the deadline, even if there was no concensus
<samueldr>
fyi*
<Dezgeg>
BTW I often get nix-copy-closure: src/libstore/local-store.cc:978: virtual void nix::LocalStore::addToStore(const nix::ValidPathInfo&, nix::Source&, nix::RepairFlag, nix::CheckSigsFlag, std::shared_ptr<nix::FSAccessor>): Assertion `info.narHash' failed. when copy-closuring from a Nix 1.11 machine, so I really wonder how well 1.11 still actually works
<gchristensen>
yikes, yeah
<LnL>
the 1.1 <-> 2.0 interactions are not tested very well
* samueldr
likes to sneak edit a grahamcofborg eval
<samueldr>
Dezgeg, LnL, where were you earlier in the month when I was thinking about that PR? :)
<samueldr>
or uh, maybe not a precedent, but at least *an* approach
<infinisil>
I'm mainly focusing on the Nix side of deprecation
<infinisil>
But I do mention these profiles
<samueldr>
no worries, just throwing something I found at you :)
<infinisil>
I'll make a note on it, will want to collect all examples I can find
<samueldr>
:)
<infinisil>
(of deprecation or where it would've been needed)
<infinisil>
The RFC is coming together nicely, but I think I'm being a bit too formal, it looks more and more like a paper haha
<infinisil>
Oh well, will have to remove irrelevant details
<infinisil>
Question: Should we worry about deprecation of function arguments? I don't know of a concrete example of where this was/would've been needed
<infinisil>
I mean of course we wouldn't want to remove the sha256 argument of fetchurl without a throw with a reason, but that won't happen to begin with
<infinisil>
[...] without a (throw with a reason) [...]
<samueldr>
this could be left in an open questions section
<samueldr>
(I don't know)
<infinisil>
Yeah will do that
xeji has joined #nixos-dev
<LnL>
infinisil: there are a number of things that can be considered breaking changes, I think should be a pragmatic balance, which makes it much harder to define