aszlig has quit [Quit: Kerneling down for reboot NOW.]
andi- has quit [Remote host closed the connection]
aszlig has joined #nixos-dev
andi- has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.5]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis has quit [Read error: Connection reset by peer]
vika_nezrimaya has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
<FRidh>
emily: thoughtpolice: for pypy we have source builds and prebuilt. The prebuilt are there because of issues with the source builds. They also allow for quick iteration when making other changes in the infra that affect the interpreters.
Jackneill has joined #nixos-dev
<FRidh>
gchristensen: darwin is broken again and blocking staging-next
niksnut has joined #nixos-dev
niksnut has quit [Remote host closed the connection]
niksnut has joined #nixos-dev
cransom has quit [Quit: WeeChat 2.4]
<pie__>
gchristensen: is your house getting cold?
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
vcunat has joined #nixos-dev
Shados has quit [Quit: Shados]
justanotheruser has quit [Ping timeout: 258 seconds]
<gchristensen>
pie__: why do you ask?
<gchristensen>
FRidh: looking ...
<pie__>
<gchristensen> the build queue is suspicously empty
<gchristensen>
pie__: none of hydra runs in my basement :)
<gchristensen>
FRidh: like the darwin build? not the darwin builders
justanotheruser has joined #nixos-dev
FRidh has quit [Ping timeout: 245 seconds]
vika_nezrimaya has joined #nixos-dev
FRidh has joined #nixos-dev
<FRidh>
gchristensen: ah sorry yes, builds, not the builders
<gchristensen>
*phew* okay
<FRidh>
I'm quite inclined to go ahead and merge staging-nexti nto master, despite darwin being broken. There are not enough darwin maintainers and we have issues like these continuously.
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 260 seconds]
jtojnar has quit [Read error: Connection reset by peer]
<vcunat>
(they transition into aborted state and thus can't be seen in queue after that)
<gchristensen>
ouch
<vcunat>
I now restarted this one, but current trunk has around 5k of these.
<FRidh>
oh
<gchristensen>
got it
<vcunat>
I expect it's still the same problem I posted about on Friday.
<gchristensen>
yeah, it is just that I thought I fixed it :)
<vcunat>
Oh. I haven't noticed the "attempt" :-) but I don't read all the IRC logs (not even just from this channel).
<gchristensen>
I didn't leave any note in here, so you wouldn't have noticed other than it just working again
<gchristensen>
every time I debug one of these machines I'm reminded that I created a bogus syslog implementation with netcat, and it makes me laugh
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
<gchristensen>
ah I found the problem.
drakonis has joined #nixos-dev
<gchristensen>
okay I found two problems
atriq has joined #nixos-dev
<gchristensen>
(1) the version of nixpkgs was floating on the "nixpkgs-unstable" channel, which is not always appropriate for darwin. switching to nixpkgs-19.03-darwin should help keep this more reliable
<gchristensen>
(2) we do 2 darwin-rebuild switch's on startup, the first one is the initial nix-darwin install, the second one configures the system properly. between the two the nix daemon is restarted, and the second one races with the daemon to start up
Taneb has quit [Read error: Connection reset by peer]
atriq is now known as Taneb
<LnL>
hmm, I've only had daemon restart issues with enableSocketListener, which is false by default
<gchristensen>
I added a silly retry loop. should I try doing some more debugging / research?
<LnL>
could be the same thing since you're probably not fast enough when running interactively
<LnL>
does the client get stuck or fail?
<gchristensen>
it failed
<gchristensen>
I'll paste the log from my bogus netcat :')
<LnL>
ah ok, with socket activation it gets stuck
<gchristensen>
hrm, might should upgrade Nix too
<LnL>
running eg. nix ping-store in a loop before continuing should work then
<gchristensen>
great, preparing the image to deploy
<vcunat>
Maybe "nixpkgs-unstable" isn't really a useful thing, and we should have nixpkgs-unstable-darwin (kinda instead).
<gchristensen>
my preference would be to have just two channels: unstable, stable-yy.mm and they both pass all the rigorous per-platform tests
<vcunat>
Forcing lockstep on darwin with the two linuxes we have... is risky IMO.
<gchristensen>
aye
<gchristensen>
it is just a dream :)
<LnL>
you can argue both ways
<gchristensen>
having aarch64 and x86 and i686 in lockstep would be very good, though, since nixops right now essentially can't work with a mixed architecture deployment
<vcunat>
We do have that, I think.
<gchristensen>
we don't
<vcunat>
Or at least we try.
<gchristensen>
we don't include all three in the same evaluation
<LnL>
having combined jobsets would be less of a problem if hydra could evaluate multiple expressions sequentially instead of in one go
<gchristensen>
that'd be cool
<LnL>
would make it slower, but reduces the memory peak
<vcunat>
Well, yes, I'd find it useful to see impact of commits (or their short ranges) on the full set of platforms we have, including all tests, etc.
<gchristensen>
eyah
<vcunat>
Especially for staging(-next).
orivej has quit [Quit: No Ping reply in 180 seconds.]
<gchristensen>
canarying the new darwin now
orivej has joined #nixos-dev
<vcunat>
For this, I had some preliminary plans to allow darwin in the combined jobsets, i.e. unify this so we can compare the evals better.
<gchristensen>
thanks for pointing outit was still broken. I'm sorry I didn't check up on my fix
<disasm>
we have some patches to get T2 apple nvme support working with a 5.2 kernel. I'd like to upstream them into nixpkgs master. Should these patches be always applied or have a conditional flag to set with them?
orivej has quit [Ping timeout: 244 seconds]
<disasm>
nm, dug into how the kernel patches work and I think it makes more sense to add it to patches.nix but not include it in top-level
justanotheruser has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
<domenkozar[m]>
disasm: btw in my experience 7th September is too late :/
justanotheruser has joined #nixos-dev
<domenkozar[m]>
but we used to do crazy systemd bumps in last minute so maybe it works now :)
<samueldr>
I think the same; I wouldn't push back the freeze date, even though the announcement was a bit late than expected
<gchristensen>
aye
<gchristensen>
though since it is announced, maybe should stick to it?
<samueldr>
that's the main reason I didn't say it first, it's not my release :)
<domenkozar[m]>
since it's fresh I think it can edit it
<domenkozar[m]>
we*
<gchristensen>
people have already received the email though
<vcunat>
Merging some disruptive changes just before 7th wouldn't be good, probably.
<domenkozar[m]>
fail fast or something :)
<domenkozar[m]>
vcunat: it happened with each release, that's what deadlines do
<samueldr>
though I think the only drawback of freezing later is the timeliness of the actual release
<samueldr>
so it's not like it's a huge issue
jtojnar has joined #nixos-dev
<domenkozar[m]>
sure it can be 19.09 incognito but really 19.10
<Taneb>
domenkozar[m]: next time we should announce the cut-off slightly after the fact ;)
<vcunat>
Yes, I agree with Domen that there's always lots of urge to push as much as possible just before the deadline.
<domenkozar[m]>
I guess release being in October is fine
<gchristensen>
release managers can/should say sorry-maybe-nexttime maybe
<gchristensen>
let's not set ourselves up to miss the deadline already, we have a whole 2 months to go for that! :D
<domenkozar[m]>
yup.
<domenkozar[m]>
disasm++
<{^_^}>
disasm's karma got increased to 5
<vcunat>
Taneb: I remember that Greg KH (once) deliberately refused to promise in advance which Linux branch he'll choose as the next LTS.
<vcunat>
*longterm
worldofpeace_ has joined #nixos-dev
<vcunat>
Still, if the real release date gets delayed as a result, I don't expect that will be a big deal. (or the first time)
drakonis has quit [Quit: WeeChat 2.5]
<thoughtpolice>
vcunat: Don't they still do that, I thought?
<thoughtpolice>
Actually, maybe not. I think when 4.19 was announced as LTS, lot of people crammed stuff into that release, which was to be expected.
<worldofpeace_>
jtojnar: do you want to check off on #66147 ?
<vcunat>
Linux longterm: I'm not following these details - I just noticed one instance, as reported by himself retrospectively.
<jtojnar>
worldofpeace: I am not convinced we need everything documented in the manual, IMHO only what we consider a public API should be documented publically. Not sure about mesonWrapMode, mesonBuildType or mesonCrossFlags
<worldofpeace>
jtojnar: well if someone wants to change the mesonBuildType that's how they should do it. I've mostly wrote this so I don't have to direct people to read the setup hook.
<worldofpeace>
I also think it's a good way to document that we use plain buildtype since we do have defaults
<jtojnar>
worldofpeace: I am not sure we want people to change it
<jtojnar>
but exposing defaults is good
<worldofpeace>
jtojnar: I've had cases where things were just broken if I didn't use a certain buildtype (probably a bug). Also what if people are using the setup hook for code external to nixpkgs?
<jtojnar>
worldofpeace: yeah, but in 99.99% cases you will not need it. I am not convinced we should make already bloated manual even more bloated. The setup hooks are usually quite legible and much more informative than the manual so I do not see a problem with linking people there.
<jtojnar>
Though I would like to see more comments in the setup hooks, literate code-style.
<jtojnar>
As for external usage, there are no warranties as we do not maintain a stable setup hook API. I wonder how flakes will handle this.
<worldofpeace>
jtojnar: huh, I tend to dislike having to do that. Frequently I've come to learn that in nixpkgs the documentation can be lacking in some places and the only way to figure out things is to read the source, which isn't exactly friendly. And to document that we have special defaults for meson's wrap mode and buildtype I don't see a way around saying it's a variable in the setup hook.
<worldofpeace>
btw, do you know where CrossFlags is used?
<jtojnar>
worldofpeace: it is used to set the paths to tools during cross-compilation
<worldofpeace>
lol wait, all I had to do was actually read it again
<worldofpeace>
perhaps that one I don't think needs to be mentioned in the manual
<jtojnar>
yeah, that one is undebatably internal
<jtojnar>
though I consider everything but mesonFlags internal and subject to change
<jtojnar>
unfortunately, since it is bash, the changes will lead to silent failures
orivej has joined #nixos-dev
<timokau[m]>
infinisil, flokli: ended up thinking about nix-bisect a bit. I decided that what I actually want is a set of primitives in a sane high-level language that I can combine freely. Much more flexible than trying to cram every possibility in a CLI. A CLI could still be added to cover common cases.