<samueldr>
the dashboard is lousy with lazy tabs :)
<samueldr>
ideally, I would like to expand the "lazy" paradigm so that the same route will know whether to render the full page or only the lazy tab. From there, instead of using anchors in URLs to distinguish tabs, it would be able to fully render the DOM server-side and be a "real" page
<samueldr>
while still allowing the lazy action to happen
<samueldr>
but I'm 99.9% sure the implementation is "not great"
<gchristensen>
bennofs[m]: deployed, but I can't seem to make it work
pie___ has joined #nixos-dev
<gchristensen>
I'd check logs, but hydra-update-gc-roots is running and that is not a nice time to examine logs
<samueldr>
gchristensen: it works
pie__ has quit [Remote host closed the connection]
<samueldr>
yes, the green bit at the bottom is the important one :/
<gchristensen>
I haven't seen rrd graphs in a hot minute, nice
<samueldr>
so I kinda made the assumption I was looking at the same kind of graph
<samueldr>
I use munin on my machines, seems "worse is better" in my case, no central authority
<gchristensen>
heh, if I use the query: (((node_memory_MemFree_bytes{instance=~"^($instance):.*",role=~"^($role)$"}+node_memory_Buffers_bytes{instance=~"^($instance):.*",role=~"^($role)$"})/node_memory_MemTotal_bytes{instance=~"^($instance):.*",role=~"^($role)$"})) it works fine
<gchristensen>
ohhh nevermind
<gchristensen>
bennofs[m]: that API endpoint took 7min to return, and produced 45.7M of data
<bennofs[m]>
perhaps we can generate the data once per evaluation instead and serve it via the cache, like store-paths.xz?
<gchristensen>
well it is useful for other stuff too, like reporting on evals
<gchristensen>
json may just not be the right tool for the data
<bennofs[m]>
not sure if perl is the right thing to process those amounts of data either
<gchristensen>
perls fine
<gchristensen>
its just 45M / ~50,000 rows
<gchristensen>
anyway, what were you going to use this endpoint for?
<bennofs[m]>
I guess the table isn't sorted by evaluation id?
<bennofs[m]>
would be a nicer way to generate the nix index, without requiring "large" (>4G) amounts of ram for evaluation the jobsets :) also I wouldn't need to ensure everything is the same between hydra & client for nix-index, but instead could point it at an evaluation and index everything built there
<gchristensen>
the evaluation table and build table are joined by a jobsetevalmember table, with a foreign key / index
<bennofs[m]>
oh now it makes sense that it takes long. I thought the build table just had a direct key to the evaluation id
<gchristensen>
well it shouldn't make a big difference, both of those indexes should be clean hits
<gchristensen>
yeah, that query took 7 seconds. the rest of the time was probably in serializing
<gchristensen>
at any rate, we probably shouldn't be having clients hit this API endpoint with regularity
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar has quit [Client Quit]
Lisanna has quit [Remote host closed the connection]
<timokau[m]>
I think skipping the "the" is fine for something headline-y
<ekleog>
just noticed something: 10 calendar days mean the NixOS FCP announcement in NixOS Weekly comes out the day before its end… guess there's little other way to handle it other than make FCPs much longer, though
<ekleog>
(though it's kind of weird, was a nixos weekly delayed? should have been 3 days, or maybe we missed one weekly?)
<domenkozar>
there was a single item last week
<domenkozar>
so I usually don't send the email in that case
<ekleog>
oh, so that's why :)
<ekleog>
makes sense
<domenkozar>
but this is a good proof that maybe I should? :)
<ekleog>
just felt weird reading the FCP announcement and noticing it's actually today (in $timezone)
<ekleog>
I guess we'll soon have an official RFC process \o/
<Synthetica>
Soon ™️
<ekleog>
domenkozar: as for nixos weekly, I guess maybe information that has limited validity in time (eg. FCPs, announcements for eg. the end of the sale of nixcon tickets, etc.) may trigger a weekly even if there is nothing else? and/or keep a log of ~2 non-deadline'd items so that if such an empty week with a deadline'd item comes up it's possible to fill it
ekleog has quit [Quit: back soon]
ekleog has joined #nixos-dev
janneke has joined #nixos-dev
drakonis has joined #nixos-dev
<domenkozar>
ekleog: that makes sense, I would send it out if I noticed the content of the single item :D
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 244 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
pie__ has joined #nixos-dev
pie___ has quit [Remote host closed the connection]
asymmetric has quit [Ping timeout: 250 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
<samueldr>
I'm about to send a PR to re-enable aarch64-linux as supported in nixos/release-combined; but it was reverted more than a year ago due to issues with memory usage on hydra
<samueldr>
anything I can do to check what's up, if it's going to cause issues?
<gchristensen>
just do it and see what happens?
<samueldr>
other than that :)
<gchristensen>
watch hydra to see if it stops evaluating
<samueldr>
(I'll do it anyway, just asking nicely before)
<samueldr>
I want hydra to produce sd_image and iso for aarch64 for nixos-unstable
<gchristensen>
yes please
<samueldr>
(and it does already for 18.09, but not a combined three-platform eval)
<gchristensen>
will this make aarch64 a blocker for the channel?
<samueldr>
hmm, I think it might
<gchristensen>
great
<samueldr>
unless it's added to limitedSupportedSystems
<samueldr>
depending on what's desired :)
<gchristensen>
if we can manage it, everything is much simpler by having aarch64 be part of the channel,
<tilpner>
Is there a reason other than "not overwhelming users with channel selection" for why channels depend on multiple systems?
<samueldr>
right now tests often fail due to failing deps :/
<gchristensen>
tilpner: for one, it is extremely annoying to have your nixops network depend on several versions of nixpkgs
<samueldr>
(e.g. qemu timing out fails all vm tests)
<tilpner>
I would guess many people use just one platform, and only get disadvantages from their channels blocking on multiple platforms
<tilpner>
But of course the granularity of channels offers a lot of space for discussion
<tilpner>
Hmm, I wouldn't know. I deploy my machines separately and without nixops :/
drakonis_ has joined #nixos-dev
<gchristensen>
really though, anything we want to produce very good support for should be a blocker
drakonis has quit [Ping timeout: 252 seconds]
<gchristensen>
even if not everybody uses it
hedning has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
asymmetric has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<samueldr>
right, I'll be finishing that later tonight, there may be an issue with how `tested` is built; where it maps all supported platforms on everything and... a couple tests will fail to eval on aarch64-linux
<samueldr>
(well, not fail to eval, but don't have an aarch64-linux attribute, so *that* will fail to eval)
<gchristensen>
send a simple revert and PR it?
<samueldr>
revert to?
<gchristensen>
or does ofborg not check that... hrm...
<samueldr>
nah, I did eval, and I remember that ~2 weeks ago I tried something that also resulted on seeing the same issue :)
<samueldr>
either tonight I'll add it as a limited supported platform (so it will at least block on sd image and iso failures) or I'll look into what it takes to fix these issues
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
orivej has joined #nixos-dev
pie___ has joined #nixos-dev
pie__ has quit [Ping timeout: 268 seconds]
hedning has quit [Quit: hedning]
asymmetric_ has joined #nixos-dev
asymmetric has quit [Ping timeout: 240 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
sir_guy_carleton has quit [Ping timeout: 250 seconds]
apaul1729 has joined #nixos-dev
boredom101 has joined #nixos-dev
<boredom101>
Just wondering, is there a desire for pull requests that add new options to existing packages?
<simpson>
Sure, the options aren't set in stone. What did you have in mind?
<boredom101>
I was thinking more options for KDE applications.
<boredom101>
is that possible?
<simpson>
Probably. Do you have code for your PR ready?
<boredom101>
no, sorry. But this is somethings I would like to try to do.
boredom101 has quit [Quit: Konversation terminated!]