worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
cole-h has quit [Ping timeout: 268 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
bennofs__ has joined #nixos-dev
bennofs_ has quit [Ping timeout: 246 seconds]
adisbladis has quit [Quit: ZNC 1.8.2 -]
adisbladis has joined #nixos-dev
tv has joined #nixos-dev
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":""}
<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
lovesegfault has joined #nixos-dev
cole-h has joined #nixos-dev
<LinuxHackerman> siraben: get a new IP address :>
jonringer has quit [Ping timeout: 245 seconds]
cole-h has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 260 seconds]
<supersandro2000> siraben: for the rate limits
<supersandro2000> well, I could but not really feeling like right now
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
Synthetica has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
<domenkozar[m]> gchristensen: how can I run ofborg eval checks locally?
<domenkozar[m]> or if someone else knows :)
<sterni> domenkozar[m]: ./ofborg/src/outpaths.nix --argstr path /path/to/nixpkgs --arg checkMeta true
<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
<{^_^}> 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?
<sterni> maybe just needs poking again though
<siraben> sterni: is that going to run al the writers?
<siraben> all*
<sterni> gchristensen: ohhh that's bad
<sterni> siraben: yeah but I don't think the thing is too expensive
<sterni> gchristensen: maybe we can circumvent that by using something else for bootstrapping
<siraben> sterni: the haskell writer fails
* sterni puts it on his GHC housekeeping list
<sterni> siraben: yeah I know that so far from hydra, but good to see it also fails elsewhere
<sterni> siraben: try applying this check and try again
<siraben> sterni: patch failed
<siraben> which commit of nixpkgs?
<sterni> haskell-updates
<siraben> sterni: `error: syntax error, unexpected '}', expecting ';'`
<siraben> `pkgs/development/haskell-modules/configuration-nix.nix:871:3:`
<sterni> rebase on origin/haskell-updates should do the trick
<sterni> I did an oopsie
<siraben> Ok, got past the evaluation error.
<siraben> sterni: still getting an error:
<sterni> interesting
<sterni> well I'll have to investigate I guess
plumm has quit [Quit: Textual IRC Client:]
<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, 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
<scott> I can't find any general discussion, but I found a precedent, so I'll go suggest this approach in the above PR:
<{^_^}> hydra#963 (by grahamc, 12 seconds ago, open): Deleting jobsets is extremely slow
<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
<scott> err, not Cargo.toml, but
<cole-h> #[cfg(debug_assertions)] #![deny(warnings)]
<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
<gchristensen> not machine-dependent though
<rmcgibbo[m]> weather dependent? idk.
<samueldr> dependent on git's internals I think
<rmcgibbo[m]> it seems like my desktop, aws, and hydra all disagree on this hash:
<{^_^}> #121950 (by rmcgibbo, 20 minutes ago, open): rippled: unbreak build
<sterni> leaveDotGit only really works because we cache sources
<sterni> at least it tries its best :)
<gchristensen> the important bit is the state of the remote, and how it decided to have its packfiles that day
<gchristensen> at that moment*
<rmcgibbo[m]> maybe it'll build without leaveDotGit. no idea if it's necessary for this package. if it can be avoided, that seems like the right fix.
<qyliss> I wonder if we could just unpack all the packfiles...
<gchristensen> we make an attempt
<qyliss> I see
NinjaTrappeur has joined #nixos-dev
justanotheruser has joined #nixos-dev
<samueldr> when possible (it generally is) try to cheat around the requirement of the .git dir being present
<samueldr> e.g. if it is used in a Makefile to output the hash, add the hash as data to the derivation, patch the makefile to use that
pmy has quit [Ping timeout: 260 seconds]
pmy has joined #nixos-dev
<rmcgibbo[m]> it's a bunch of cmake ExternalProject_Add. i think i'll just give up :(
catern has joined #nixos-dev
tomberek has joined #nixos-dev
NinjaTrappeur has quit [Ping timeout: 260 seconds]
NinjaTrappeur has joined #nixos-dev
cptchaos83 has quit [Quit: - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.8.2 -]
kreisys has joined #nixos-dev
evanjs has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
jonringer has quit [Remote host closed the connection]
<sterni> Ericson2314: do you have any ideas why useLLVM and compiler-rt don't go well anymore together since the llvm output refactor?
<sterni> nix-build -A tests.cross.llvm.hello.gnu64 to reproduce the failure
jonringer has joined #nixos-dev
supersandro2000 has quit [Killed ( (Nickname regained by services))]
supersandro2000 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]