<matthewbauer[m]>
But, that was an issue since 18.03
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
averell has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-dev
ckauhaus has quit [Quit: WeeChat 2.2]
<gchristensen>
let's ditch nixpkgs-unstable
<infinisil>
+1
<gchristensen>
infinisil: want to write the RFC with me? :P
<infinisil>
gchristensen: Hmm, yeah why not
<tilpner>
Huh, why that? I like nixpkgs-unstable
<gchristensen>
it is very confusing for newbies
<gchristensen>
LOTS of people ask: "How unstable is the "unstable channel"?" and then we have to have a big discussion about nixos- vs nixpkgs- bla bla bla
<samueldr>
if the argument is "it updates faster than nixos-unstable" the solution is to figure out the issue making the updates slower
<tilpner>
:/
<tilpner>
nix-env is confusing for newbies, let's get rid of that too?
<samueldr>
(which right now is the apparent instability of qemu)
<gchristensen>
yes please!
<infinisil>
Yes, agreed tilpner :)
<tilpner>
I don't think removing things until nobody's confused anymore is the way to go :(
<gchristensen>
I agree
<tilpner>
What other ways are there to avoid that moment of confusion?
<infinisil>
My arguments for getting rid of nixpkgs-unstable are: There's no harm for people to use nixos-unstable instead, and if there's less channels, nixos-unstable can update faster because there's more build power
<tilpner>
Where do they learn of nixpkgs-unstable?
<tilpner>
That's where they should see a link explaining the differences and the meaning of unstable
<gchristensen>
they learn about nixpkgs-unstable after they get someone asking, "sorry, did you mean nixpkgs-unstable or nixos-unstable?"
<tilpner>
infinisil: It's not always a problem of build power
<gchristensen>
it would also help with focused person-power
<tilpner>
How would getting rid of nixpkgs-unstable free up person-power?
<gchristensen>
not free-up, but focus -- since more people would be invested in it advancing
<gchristensen>
(this is a crappy argument)
<infinisil>
Yeah, tbh I think all of nixpkgs is getting a bit big to manage for this little active maintainers/committers we have
<tilpner>
What will Darwin users think about getting rid of nixpkgs-unstable?
<infinisil>
Simplifying stuff in general might be a good idea
<tilpner>
Isn't nixpkgs-unstable the only supported channel for Nix-on-not-NixOS?
<gchristensen>
the darwin users I know will be happy, because finally their stuff will match linux stuff
<samueldr>
nixos-xx.yy is supported IIRC since 18.03 for nix-darwin/darwin usage?
<samueldr>
or suggested?
<samueldr>
or I'm woefully wrong?
<infinisil>
Maybe we should rename the channels, nixos-unstable -> nixpkgs-unstable (NixOS is part of nixpkgs anyways, so that would make sense, it's just gonna be hella confusing, so maybe not..)
<samueldr>
hmm, it's nixpkgs-xx.yy-darwin, disregard me, but would make sense to join them up
<tilpner>
Well, I'm trying to get rid of channel completely in my setup, but I still think removing nixpkgs-unstable would be a loss
<infinisil>
I'd like to hear from people who actually use nixpkgs-unstable
<tilpner>
nixos-unstable vs nixpkgs-unstable seems like an important distinction wrt. what tests get run (are we testing for NixOS to work, or just nixpkgs to work?)
<infinisil>
The only thing it currently provides over nixos-unstable is faster updates
<tilpner>
Which is important, given how nixos-unstable sometimes takes forever to update compares to the release channels
<tilpner>
*compared
<infinisil>
tilpner: As said, NixOS is part of nixpkgs, so I think nixpkgs-unstable meaning to not run NixOS tests doesn't even make sense
<samueldr>
though right now most of the forever is a longstanding issue with the testing infra, which is a bug, not a design of nixos-unstable :/
<tilpner>
infinisil: It's in the same repo, but there are many users who only use the non-NixOS parts
<samueldr>
(longstanding meaning months here)
<tilpner>
Why should they have to wait because NixOS is broken again?
<tilpner>
Maybe I'm underestimating the cost of having nixpkgs-unstable
<samueldr>
nixos tests aren't necessarily nixos-only; some parts of nixpkgs are stressed in ways that may not show otherwise
<tilpner>
So far it seems like some build power and a little confusion. And that seems to be worth paying (IMO)
<infinisil>
You have a point, but I also wonder how many people actually use nixpkgs-unstable
<gchristensen>
nix installations default to it
<infinisil>
Ah
<tilpner>
infinisil: I assume everyone with Nix-on-not-NixOS
<samueldr>
if the goal is to feed the channel faster, maybe nixpkgs-untested, and the nix installer defaults to nixos-rolling?
<gchristensen>
:~)
<samueldr>
(spitballing here)
<tilpner>
I'm not against restructuring (or abandoning) channels, but then it's a much larger task than just dropping nixpkgs-unstable
<infinisil>
Yeah maybe it's a bit of an overreaction
<infinisil>
Our goal should be to fix the hydra failures that prevent nixos-unstable to update
<infinisil>
Once that's settled and made sure channel updates happen regularly, we could make it the default (maybe rename it)
<infinisil>
And then remove nixpkgs-unstable
* samueldr
wonders if the tests started to fail after a qemu upgrade
<tilpner>
Is there another way to accomplish that than "pay lots of attention to failing tests"?
<gchristensen>
improve insight in to patches before they hit master
<tilpner>
Oh, ofborg would run NixOS tests and block merge if they fail?
<gchristensen>
I didn't say that exactly :P
<gchristensen>
(butmaybe)
<tilpner>
Is that feasible to do on the current infrastructure?
<gchristensen>
no
<infinisil>
How about an RFC for making a strategy for figuring out the cause of the failures
<Phillemann>
This is just remotely related, but my problem with test failures is, most of the time they're completely irrelevant to me. I don't use qemu, for example. And if the installer test fails...I don't care. :D
<Phillemann>
But surely this is another discussion.
<samueldr>
though, the installer tests also verify a system should boot successfully using a couple of the bootloaders installs
<samueldr>
a failure of those will be bad for nixos users
<samueldr>
but here maybe you're not a nixos user :/
<Phillemann>
I am, actually. I just thought the installer was something I left behind, so to speak ;)
<Phillemann>
Maybe a bad example on my part.
<samueldr>
gchristensen: would it be a hassle to have someone check the machine for something like bad ram, or cycle through another one?
<gchristensen>
what machine?
<samueldr>
packet-epyc-1
<samueldr>
anecdtodally a high percentage of failures of vm tests are on it, even going months back
<samueldr>
BUT
<samueldr>
it's also a machine that gets a big chunk of the work
<gchristensen>
yikes
<samueldr>
so it might be unlucky!
<gchristensen>
or extra lucky :P
<gchristensen>
I could drop its kvm feature?
<gchristensen>
also, sure, we could take it out and run memtest on it
<samueldr>
not sure it would be kvm at play
<cransom>
packet-epyc-1 has a builtin chaos monkey build feature
<gchristensen>
:(
<samueldr>
at least the chaos monkey you can point a finger to it
<samueldr>
my leading assumptions are that it's one of (hardware failure on packet-epyc-1) (qemu instability) (kvm instability) or combination of the three
<samueldr>
hoping it wouldn't be the first
<gchristensen>
or over previsioned?
<gchristensen>
tbh hoping it is the first :PU
<gchristensen>
easiest to fix
<samueldr>
I'm thinking about all the previous builds it did that may be subtly broken :/
<samueldr>
but yeah, hoping it is, but hoping it isn't :/
<gchristensen>
fair
<gchristensen>
ok, I'll switch laptops and see what I can see