<worldofpeace>
I haven't really looked into it, so it could just be a timeout high up in the chain (could then be an aarch64 infra issue)
<samueldr>
there's a lot of timing out around lately for reasons I want to investigate, I have asked but probably due to timezone differences no one took the bait into helping me look into a solution
<samueldr>
the reports thing script I made could help to see if there is a bottleneck in failures
<samueldr>
something that's making a lot of the builds fail as they are dependent
<samueldr>
~6713 are "Dependency failed"
<worldofpeace>
oooh, I think I recall seeing you in here wondering about that.
<samueldr>
7 timed out
<samueldr>
664 simply "Failed"
<samueldr>
how'd I check that?
<samueldr>
curl'd the page source for the fully expanded list, and grepped for title="Failed" and such
<samueldr>
that's basically what the reports thing does
<worldofpeace>
samueldr: if we can't figure out what to do in #nixos-dev be sure to come to the go/no-go so we can "raise a stink" if needed.
<samueldr>
I don't think it's "that" issue though
<samueldr>
anyone ran my reports script recently?
<samueldr>
hm, it'd have to be on _that_ jobset though
<worldofpeace>
samueldr: jonringer has a beeeeffyy machine and I told him about this. I can ask if he can do it on an eval of that jobset
<samueldr>
heh, it's not even requiring a beefy machine :) it's more about time to let it go through the builds (the first time)
<samueldr>
it all relies on hydra serving us pages at an acceptable speed
<hexa->
and not doing too many jobs in parallel, even though the arm machines have lots of cores afair
<worldofpeace>
<samueldr "it all relies on hydra serving u"> right, I believe that was the issue I reported to your repo last time (had to tweak the curl command in the end so it could work)
<{^_^}>
samueldr/nix-review-tools#6 (by worldofpeace, 31 weeks ago, open): fetch.rb:31:in `read': No such file or directory
<worldofpeace>
(or maybe I'm misremembering, it's all a blur at this point)
<samueldr>
ah, no, not really that, that was only when it failed
<samueldr>
(looks like I fixed it)
<samueldr>
what I was saying is that since it will have to go through... thousands of requests to hydra, it'll take a while :)
<samueldr>
Y'ALL, DON'T GET SCARED, it does them serially
<samueldr>
and caches them so when/if you restart it doesn't re-do any of those it already did, and if you run on multiple evals it completes with the new stuff
greizgh_ has joined #nixos-dev
alexarice[m] has quit [*.net *.split]
worldofpeace has quit [*.net *.split]
bennofs[m] has quit [*.net *.split]
arcnmx has quit [*.net *.split]
Ox4A6F has quit [*.net *.split]
bbigras has quit [*.net *.split]
mkg20001 has quit [*.net *.split]
greizgh has quit [*.net *.split]
fadenb has quit [*.net *.split]
stew has quit [*.net *.split]
thoughtpolice has quit [Ping timeout: 246 seconds]
thoughtpolice has joined #nixos-dev
ris has quit [Ping timeout: 264 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
__red__ has quit [Remote host closed the connection]
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
<ghuntley>
I guess the question really is, why not use master@nixpkgs over nixpkgs-channels if one is getting their hands dirty with nix internals.
<ghuntley>
or is it a case of nixpkgs-channels means there's a hydra cache available?
<samueldr>
ghuntley: master could have a commit that renders the workstation unusable
<samueldr>
as in, not bootable
<samueldr>
not "ah, previous generation will work fine" unbootable, but could also wipe your bootloader (though, that's a bit far fetched)
<samueldr>
you really should follow the `nixos-unstable` branch, on the NixOS repo (nixpkgs-channel is semi-deprecated, the branches are on the NixOS repo now too)
<ghuntley>
thx sam. I didn't know nixpkgs-channel was semi deprecated. I'll switch over to nixkgs:nixos-unstable
<ghuntley>
could we maybe get the note about deprecation added to the README at https://github.com/nixos/nixpkgs-channels and/or the description. Specifically with steps to mitigate.
<samueldr>
I said half-deprecated, but there's no official word AFAIK
<samueldr>
it's more that all the features are now active on the main repo, and that's how (IIRC) flakes get channel info by default
evanjs has quit [Read error: Connection reset by peer]
justanotheruser has joined #nixos-dev
evanjs has joined #nixos-dev
<ghuntley>
does systemd have a way to run a command, when another systemd unit is invoked?
<worldofpeace>
And Eelco isn't on vacation anymore is he?
<worldofpeace>
aaron: ✨ 💖
<aanderse>
oh no... never click that link from mobile :S
<worldofpeace>
aaron: discourse or is the when2meet not mobile friendly?
<aanderse>
when2meet
<aanderse>
no problem though, switched to desktop and all good
<worldofpeace>
huh, maybe I should find a better tool. framadate is like the most painful thing to use, and when2meet is basically as "close" to a doodle without being doodle.
<ryantm>
(Note to self: don't compose messages in chat inputs)
<ryantm>
Here's my idea to fix the nodePackages merge conflict hell:
<ryantm>
2. Make script that makes it easy for node maintainers to list a bunch of PRs, drop all their node-packages.nix changes, and then regenerate node-packages.nix on top of that, and make a PR.
<ryantm>
1. make node maintainer team, add code owners for node-packages.nix
<qyliss>
ryantm++
<{^_^}>
ryantm's karma got increased to 18
nschoe has joined #nixos-dev
<infinisil>
ryantm: I think we should have CI run generate.sh on a weekly basis (and when a PR that changes node-packages.json is merged)
<infinisil>
So that people only need to PR the node-packages.json update
<qyliss>
I think that what ryantm is suggesting would also mean people only need to PR node-packages.json
<qyliss>
I'd be a bit nervous about CI having push access
<ryantm>
Yeah, they wouldn't need to PR node-packages.nix, but if they did we'd have a way to ignore it.
<ryantm>
Maybe we could make a CI action that tells people they are wrong to be changing node-packages.nix?
<ryantm>
There's already so many CI actions, I'm not sure people would notice.
<MichaelRaskin>
ryantm: I think the total changes to red, though?
<infinisil>
a github action using that should indicate failure within a couple seconds I'd expect
<worldofpeace>
yeah, we use github actions in nixos-homepage to update flake and whatnot. infinisil is right in that actions can make it *really* simple
cole-h has joined #nixos-dev
<worldofpeace>
wondering if anyone has anything to add for proofreading the release note at #98333
<cole-h>
worldofpeace: Mind meld -- those are all things I would have pointed out :)
<cole-h>
worldofpeace: However, s/timeline/lifetime/ for your first comment
<worldofpeace>
cole-h: I'm noticing I'm really find of terms like "end of life" and "lifetime" when we're talking about software. I've kept them atm though
<cole-h>
find -> fond? ;)
<worldofpeace>
I almost
<worldofpeace>
I almost was proficient at english
<worldofpeace>
sooo close. yeah fond :D
<cole-h>
`timeline` just sounds weird in that context, IMO, especially as the only timeline we really have is "release 20.09 eventually" (and AFAIK nothing concrete/explicit about when we stop supporting version xx.xx)
<worldofpeace>
From all the rm's I've talked to its a month after the new stable release. it might be in the manual. so like 20.09 is released 20.03 is EOL in a month after that
<cole-h>
Then I stand corrected. But lifetime still sounds better in that context, because it's acknowledging that 20.09's life will come to an end eventually (whereas I perceive a timeline as infinitely continuing, with marked events along it)
<cole-h>
Once your suggestions are heeded, those notes should be g2g :D
<worldofpeace>
awesome 👍️
red[evilred] has joined #nixos-dev
bridge[evilred] has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
kloenk has joined #nixos-dev
flokli has quit [Ping timeout: 244 seconds]
flokli has joined #nixos-dev
abathur has joined #nixos-dev
tazjin has quit [Remote host closed the connection]
tazjin has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]