adisbladis has quit [Read error: Connection timed out]
adisbladis has joined #nixos-dev
nbp_ has joined #nixos-dev
edef_ has joined #nixos-dev
edef_ is now known as edef
supersandro2000 has quit [*.net *.split]
copumpkin has quit [*.net *.split]
piegames[m] has quit [*.net *.split]
kaptin has quit [*.net *.split]
puck has quit [*.net *.split]
nbp has quit [*.net *.split]
niksnut has joined #nixos-dev
kaptin has joined #nixos-dev
cransom has joined #nixos-dev
piegames[m] has joined #nixos-dev
appservicebot5 has joined #nixos-dev
copumpkin has joined #nixos-dev
supersandro2000 has joined #nixos-dev
JasonO has joined #nixos-dev
puck has joined #nixos-dev
dongcarl has quit [Ping timeout: 240 seconds]
rajivr has joined #nixos-dev
orivej has joined #nixos-dev
auto-kad has joined #nixos-dev
auto-kad has quit [Quit: Connection closed]
<siraben>
I ran `nix build github:com/...."` and got `{"message":"API rate limit exceeded for XXXXX. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}
<siraben>
(use '--show-trace' to show detailed location information)`, what could I do to fix it?
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
tomberek has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 3.0.1]
<siraben>
supersandro2000: would you be able to re-run that scan where you checked for commit hashes that did not belong to the repository?
<siraben>
or better, maybe it should be an automated thing that is run weekly or something
<sterni>
domenkozar[m]: the readme also has a section on it and recommends GC_INITIAL_HEAP_SIZE=4g
<domenkozar[m]>
sterni: my understanding is that "meta" checks are only about .meta attribute but not all evaluation of packages?
<sterni>
domenkozar[m]: yeah, but meta is also important for evaluation in many cases
<sterni>
you can disable it if you only care about outPaths
<domenkozar[m]>
sure, but I'd like to run all evaluation checks
<sterni>
there is no comprehensive list I think you'd have to look at the source
<sterni>
seems like a different combination of release.nix files and outpaths.nix for different systems
<sterni>
but I would have to check as well
__monty__ has joined #nixos-dev
<domenkozar[m]>
how about we have that as a script in nixpkgs?
<sterni>
well it doesn't really help does it? since it'd be independently maintained from ofborg
<domenkozar[m]>
doesn't ofborg checkout nixpkgs?
<sterni>
yes, but aren't the checks executed independently
<sterni>
but yeah it may be an idea to have them in nixpkgs actually
nyanotech has quit [Ping timeout: 245 seconds]
nyanotech has joined #nixos-dev
thonkpod has joined #nixos-dev
htr has joined #nixos-dev
tomberek has quit [Quit: Connection closed]
orivej has joined #nixos-dev
copumpkin has quit [Ping timeout: 246 seconds]
<gchristensen>
they're not scripts in nixpkgs to avoid arbitrary code execution and also avoid requiring an anything inside of nixpkgs evaluating or building to complete
htr has quit [Quit: working hard]
htr has joined #nixos-dev
<sterni>
you check out master anyways so you could only execute from master
<sterni>
them being checked in in nixpkgs wouldn't necessitate them depending on nixpkgs eval as well
<gchristensen>
that is true
pmy has quit [Ping timeout: 240 seconds]
<sterni>
although wrapping some in individual scripts is not really worth it as well
pmy has joined #nixos-dev
<sterni>
like the eval tests of release.nix files
copumpkin has joined #nixos-dev
__monty__ has quit [Quit: leaving]
dongcarl has joined #nixos-dev
<hexa->
so, staging-next? :D
orivej has quit [Ping timeout: 260 seconds]
<sterni>
:D
<sterni>
siraben: can you test tests.writers on darwin, seems like there is a problem with the haskell writer there
<sterni>
I have an idea what to do but can't access my mac rn
<rmcgibbo[m]>
Quick question: being fairly new to the nix community, this is the first time I'll be seeing a release happen. So all of the acronyms around ZHF and stuff in the release schedule are new to me, but I assume this means that there are expected to be a higher-than-usual rate of PRs shortly.
<rmcgibbo[m]>
Is that correct, and would it be helpful to increase the number of (or speed of) of the r-rmcgibbo machines for the next few weeks?
<Synthetica>
rmcgibbo[m]: Just out of interest, what hardware are you currently running on?
<rmcgibbo[m]>
Fairly puny AWS machines (c5a.large and c6g.large).
<ajs124>
concerning the number of PRs, it might be interesting to look at the last few releases, but we're also doing things different from those releases, after https://github.com/NixOS/rfcs/pull/85
<{^_^}>
rfcs#85 (by jonringer, 14 weeks ago, merged): [RFC 0085] NixOS Release Stabilization: ZHF on master, new timeline
<gchristensen>
I noticed deleting jobsets is super slow on hydra (slow enough that the functionality was disabled via the web UI.) it was slow because deleting builds is very slow, deleting just 10 builds took 4428.743 ms. looking around I was able to make it delete 10 builds in 17.475ms, a reduction of 4418ms. it can delete 10,000 builds in 7901.316 ms now
justanotheruser has quit [Ping timeout: 245 seconds]
<ajs124>
why was it so slow?
<gchristensen>
table scans
Raito_Bezarius has quit [Ping timeout: 248 seconds]
jonringer has joined #nixos-dev
<siraben>
sterni: sure, let me know what you want me to do
Raito_Bezarius has joined #nixos-dev
<siraben>
i may be a bit busy atm, so the more automatic the procedure the better
justanotheruser has joined #nixos-dev
justanotheruser has quit [Quit: WeeChat 2.9]
<sterni>
nix-build -A tests.writers
<sterni>
maybe apply a patch I have and see if it does anything
<sterni>
but it's not urgent I can also do it when I'm home again
cole-h has joined #nixos-dev
<sterni>
what does output exceeded mean
<sterni>
is there a maximum store path size allowed on hydra?
<siraben>
sterni: can't look into it how but let me know again if you want me to apply a patch & test
orivej has joined #nixos-dev
plumm has joined #nixos-dev
teto has joined #nixos-dev
<scott>
Is there a general policy in nixpkgs regarding compile options like `-Werror` in C/C++ or `#[deny(warnings)]` in Rust? It causes unnecessary package breakage like https://github.com/NixOS/nixpkgs/pull/121536, where a Rust 2018→2021 migration warning broke the build. Because Rust edition migration is an explicit human action, there's no reason to
<scott>
break the build over this kind of thing
<{^_^}>
#121536 (by Mindavi, 3 days ago, open): rq: fix compilation by applying patch
<scott>
In general, any Rust stable version bump could cause any deny(warnings) package to break despite not having any real problems, so I'd be tempted to patch out the deny(warnings) rather than anything else
<gchristensen>
scott: I thought the editions meant the rust compiler would operate in the older edition until the project itself opted in to the new edition?
<scott>
gchristensen: that's correct
<gchristensen>
so the upstream project ignored this warning?
<scott>
gchristensen: so, the new warning is just saying "this code will have to change when you manually switch this crate to 2021 edition", and it only breaks the build because this crate uses deny(warnings)
<scott>
i don't think the upstream has ignored the warning — nixpkgs just started building the crate on the new rustc version that adds that warning before upstream did
<gchristensen>
got it
<scott>
so upstream hasn't reacted yet
<gchristensen>
it almost sounds like deny(warnings) should not be unhappy about edition warnings
<scott>
i agree
<scott>
in the meantime the general community consensus that i've seen is that projects simply shouldn't use deny(warnings) in Cargo.toml — they should only use it for development and in CI
<scott>
so the slightly better but less expedient solution would be to convince upstream of this
<ajs124>
gchristensen who would have thought deleting a few rows from a database could be this complicated?
<gchristensen>
hehe
<gchristensen>
why are constraints, even
<ajs124>
I'm sure none of this would have happened with mongodb
<ajs124>
(I'll shut up now)
<gchristensen>
you are certainly correct, hydra would not work very well with mongo
<gchristensen>
a friend showed me a really nice tip to optimise our database: truncate builds cascade
<ekleog>
cole-h: what you mean is probably #![cfg_attr(debug_assertions, deny(warnings))]? though I'd probably go with #![cfg_attr(feature = "deny_warnings", deny(warnings))] or even just a `sed` in the CI that adds it
<cole-h>
yeah, probably. at least you understood the intent :P I don't use many attr macros so I always forget how to write them
<cole-h>
gchristensen++ very nice writeup on that Hydra issue
<{^_^}>
gchristensen's karma got increased to 463
<gchristensen>
:) the work isn't even that extensive actually, even
<gchristensen>
just a little bit fiddly I think
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
<rmcgibbo[m]>
are fetchgit fixed output derivation hashes spooky or machine-dependent when called with `fetchSubmodules = false; leaveDotGit = true;`?
<gchristensen>
fundamentally leaveDotGit is unreliable