-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stdenv setup test #132490
Stdenv setup test #132490
Conversation
(cherry picked from commit bf40c3054db4c552a4f229738d84f11755e9d623)
(cherry picked from commit 32ee9a7)
(cherry picked from commit 213ea52)
(cherry picked from commit f5066a0)
(cherry picked from commit c1b7aa9)
(cherry picked from commit 66d8c2a)
(cherry picked from commit b2490c97b3ba555ca4f76c48d3c8904c1a4775f4)
I have just checked the failure and it seems to be related to aws-c-common
I wonder if there is a change that this test is flaky. @GrahamcOfBorg eval |
f684c60
to
2ae1bd8
Compare
I've seen aws-c-common being flaky too in the last days, or you might've just gotten unlucky. Not sure which it is. It seems to have solved itself on my end though. |
@Mindavi thank you for the comment. |
Hydra: ?compare=1692843
Jobset set up at https://hydra.nixos.org/jobset/nixpkgs/pr-132490 (just x86_64-linux now, low priority) EDIT: direct comparison link https://hydra.nixos.org/eval/1693558?compare=1692843 I'll try to have a closer look at the code, too. |
Thank you so much for this! |
It seems there are 20 new failures but 12 newly passing ones Some of the failures look they are due to time out. @vcunat I'm a little new to this, am I missing something or are those PRs fine to merge ? |
I also locally checked cross-building from Some commits apparently haven't been reviewed by anyone except the author (not even myself so far), so that's the only missing part now, I think. At least some quick review. |
@vcunat If you mean that those commits need more reviews, understood. |
I would certainly prefer that. If noone steps up, I'd hope to have a look during this weekend. |
forceShare=${forceShare:=man doc info} | ||
if [ -z "$forceShare" -o -z "$out" ]; then return; fi | ||
if [[ -z "$forceShare" || -z "$out" ]]; then return; fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, what exactly the first line here is supposed to do? It seems to check if forceShare
is empty, and if so assign man doc info
to it. Twice (once via default value assignment :=
, second via the actual assignment). In any case, can forceShare
ever be empty afterwards?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right here, I've tested everything I could think of, and there is no way (that I could think of) that forceShare could be empty. Let me simplify that condition (I'll do it in the original PR).
if [ -n "${showBuildStats:-}" ]; then | ||
times > "$NIX_BUILD_TOP/.times" | ||
local -a times=($(cat "$NIX_BUILD_TOP/.times")) | ||
if [[ -n "${showBuildStats:-}" ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason for this line change? Sounds like [
is enough here…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was more around trying to have a single way to do conditionals.
As I understand it, you never loose by using [[
instead of [
and there are less pitfalls.
I do understand that it might be controversial. If you prefer [
, I'm happy to try to avoid that change where unecessary in future PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt there is a coherent style guidance on that… this change was just a part of a kind of unrelated (except for adjacency) commit.
(I myself probably lean towards «POSIX except where extension make things much simpler», but I do not change stdenv
much)
local -a times=($(cat "$NIX_BUILD_TOP/.times")) | ||
if [[ -n "${showBuildStats:-}" ]]; then | ||
local -a buildTimesArray | ||
IFS=" " read -r -a buildTimesArray < "$NIX_BUILD_TOP/.times" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, have you just removed the line that created the .times
file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did make a mistake here.
I was originally thinking about combining those steps to not create the file anymore. (I wanted to put the the times command directly as an input). Now that i think about it though, it might not be good to get rid of that file.
My original thought was that since it's echoed, perhaps it's not needed to keep a record.
I'll add it back just in case it is used actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no strong opinion on keeping the file, but in case of debugging functionality I would indeed err on the side of giving more ways to find data.
(I have read the changes till the end) |
@7c6f434c If this gets accepted to merge, I will not include the change around the .times at all. |
This is probably all the reviews this was going to get. I'm going to go ahead and merge those PRs to staging for now. |
This PR was just for testing, so closing this. |
Motivation for this change
@siraben @vcunat
Here is the PR where I've grouped all the changes that I think should pass and would be fairly uncontroversial.
I hope I haven't missed anything.
I didn't know if I should pick master or staging as a base. It seemed intuitive to me to pick master to lower the chance of unrelated failures, let me know if you want me to base it on staging.
The following PRs are included
I'm putting this in a draft stage until someone has a chance to test and make sure it doesn't break anything.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)