Throw the E3510 when the policy is not created because of the condition

Is this feature request related to a new rule or cfn-lint capabilities?
No response
Describe the feature you'd like to request
Hello,
We have below use case.
We have a cloudformation template to create Policy as below:
"IngestionCommonResourcesCreateApplicationLoadBalancerupdateAlbRulesLambdaAuthPolicy56A5093E": {
 "Type": "AWS::IAM::Policy",
 "Properties": {
  "PolicyDocument": {
   "Statement": [
    {
     "Action": "secretsmanager:GetSecretValue",
     "Effect": "Allow",
     "Resource": {
      "Ref": "AuthenticationSecretArn"
     }
    }
   ],
   "Version": "2012-10-17"
  },
  "PolicyName": "IngestionCommonResourcesCreateApplicationLoadBalancerupdateAlbRulesLambdaAuthPolicy56A5093E",
  "Roles": [
   {
    "Ref": "IngestionCommonResourcesCreateApplicationLoadBalancerupdateAlbRulesLambdaRole89F8B50D"
   }
  ]
 },
 "Metadata": {
  "aws:cdk:path": "s3-v2enable1/IngestionCommonResources/CreateApplicationLoadBalancer/updateAlbRulesLambdaAuthPolicy/Resource"
 },
 "Condition": "IngestionCommonResourcesCreateApplicationLoadBalancerauthEnableConditionF2B09238"
},

And AuthenticationSecretArn is input parameter as below:
"AuthenticationSecretArn": {
 "Type": "String",
 "Default": "",
 "AllowedPattern": "^$|^arn:aws(-cn|-us-gov)?:secretsmanager:[a-z0-9-]+:[0-9]{12}:secret:[a-zA-Z0-9-/]+$",
 "ConstraintDescription": "AuthenticationSecretArn must match pattern ^$|^arn:aws(-cn|-us-gov)?:secretsmanager:[a-z0-9-]+:[0-9]{12}:secret:[a-zA-Z0-9-/]+$",
 "Description": "The AuthenticationSecretArn of OIDC provider"
},

Now the cfn-lint throw the below error:
E3510 {'Ref': 'AuthenticationSecretArn'} does not match '(^arn:(aws|aws-cn|aws-us-gov):[^:]+:[^:](:(?:\d{12}|\|aws)?:.+|)|\*)$' when 'Ref' is resolved
Our use case is the Policy is controlled by a condition
IngestionCommonResourcesCreateApplicationLoadBalancerauthEnableConditionF2B09238
If the AuthenticationSecretArn is '', condition will be false and policy will not be created.
Could you think about this use case and do some change to support this case?
Thanks,
Mingtong
Describe the solution you'd like
If the AuthenticationSecretArn is '', condition will be false and policy will not be created.
Could you think about this use case and do some change to support this case?
Additional context
No response
Is this something that you'd be interested in working on?

[ ] 👋 I may be able to implement this feature request

Would this feature include a breaking change?

[ ] ⚠ This feature might incur a breaking change

Using the latest version of cfn-lint and this condition I cannot replicate this error.
"IngestionCommonResourcesCreateApplicationLoadBalancerauthEnableConditionF2B09238": {
            "Fn::Not": [
                {
                    "Fn::Equals": [
                        {"Ref": "AuthenticationSecretArn"},
                        ""
                    ]
                }
            ]
        }

I wrote a cloudformation example template as below:
AWSTemplateFormatVersion: '2010-09-09'
Description: A CloudFormation template that creates an IAM policy conditionally.

Parameters:
  enable:
    Type: String
    Description: Parameter to enable or disable the creation of the IAM policy.
    AllowedValues:
      - "Yes"
      - "No"
    Default: "No"

  secretArn:
    Type: String
    Default: ""
    Description: The ARN of the secret to use in the IAM policy.

Conditions:
  CreatePolicy: !Equals [!Ref enable, "Yes"]

Resources:

  MyIAMRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: [lambda.amazonaws.com]
            Action: ['sts:AssumeRole']
      Path: "/"
      Policies:
        - PolicyName: LambdaExecutionPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                Resource: "arn:aws:logs:*:*:*"

  ConditionalIAMPolicy:
    Type: AWS::IAM::Policy
    Condition: CreatePolicy
    Properties:
      PolicyName: ConditionalSecretPolicy
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - secretsmanager:GetSecretValue
            Resource: !Ref secretArn
      Roles:
        - !Ref MyIAMRole

execute:  cfn-lint -e -t ./E3510-test.yaml
got below error:
E3510 {'Ref': 'secretArn'} does not match '(^arn:(aws|aws-cn|aws-us-gov):[^:]+:[^:](:(?:\d{12}|\|aws)?:.+|)|\*)$' when 'Ref' is resolved
E3510-test.yaml:15:5

This is similar to #3378.  The error is coming from the fact that I can leave secretArn empty and have enable as yes.  As it stands those two parameters really have no relationship in the conditions section.
The way we typically see this solved is something like:
!And [!Equals [!Ref enable, "Yes"], !Not [!Equals [!Ref secretArn, ""]]]
or
!Not [!Equals [!Ref secretArn, ""]]


setupMetamask Errors with Electron

EDIT: I might just be dumb, this probably shouldn't work with Electron, right?
Getting the following issue only when running Electron.
The first issue I was getting was with the remote debugger
CypressError: `cy.task('setupMetamask')` failed with the following error:

> request to http://localhost:9222/json/version failed, reason: connect ECONNREFUSED <IP_ADDRESS>:9222

which I fixed by exporting ELECTRON_EXTRA_LAUNCH_ARGS=--remote-debugging-port=9222. I'd suggest some way to handle this internally, or at least a line of documentation.
CypressError: `cy.task('setupMetamask')` failed with the following error:

> Cannot read property 'waitForTimeout' of undefined

It seems like await metamask.initialSetup({ secretWords, network, password }); from the plugin is being called before puppeteer has been been properly set up.
Note that I've configured metamask to use a custom network.

Call stack
> Cannot read property 'waitForTimeout' of undefined

https://on.cypress.io/api/task

Because this error occurred during a `before all` hook we are skipping all of the remaining tests.
      at http://localhost:5000/__cypress/runner/cypress_runner.js:142397:19
      at tryCatcher (http://localhost:5000/__cypress/runner/cypress_runner.js:10798:23)
      at Promise._settlePromiseFromHandler (http://localhost:5000/__cypress/runner/cypress_runner.js:8733:31)
      at Promise._settlePromise (http://localhost:5000/__cypress/runner/cypress_runner.js:8790:18)
      at Promise._settlePromise0 (http://localhost:5000/__cypress/runner/cypress_runner.js:8835:10)
      at Promise._settlePromises (http://localhost:5000/__cypress/runner/cypress_runner.js:8911:18)
      at _drainQueueStep (http://localhost:5000/__cypress/runner/cypress_runner.js:5505:12)
      at _drainQueue (http://localhost:5000/__cypress/runner/cypress_runner.js:5498:9)
      at Async.../../node_modules/bluebird/js/release/async.js.Async._drainQueues (http://localhost:5000/__cypress/runner/cypress_runner.js:5514:5)
      at Async.drainQueues (http://localhost:5000/__cypress/runner/cypress_runner.js:5384:14)
  From Your Spec Code:
      at Context.eval (http://localhost:5000/__cypress/tests?p=node_modules/@synthetixio/synpress/support/index.js:6334:15)

  From Node.js Internals:
    TypeError: Cannot read property 'waitForTimeout' of undefined
        at Object.initialSetup (/home/marcus/tv-balancer-gui/node_modules/@synthetixio/synpress/commands/metamask.js:268:37)
        at processTicksAndRejections (internal/process/task_queues.js:97:5)
        at setupMetamask (/home/marcus/tv-balancer-gui/synpress/plugins/index.js:136:7)

Call stack
> Cannot read property 'waitForTimeout' of undefined

https://on.cypress.io/api/task

Because this error occurred during a `before all` hook we are skipping all of the remaining tests.
      at http://localhost:5000/__cypress/runner/cypress_runner.js:142397:19
      at tryCatcher (http://localhost:5000/__cypress/runner/cypress_runner.js:10798:23)
      at Promise._settlePromiseFromHandler (http://localhost:5000/__cypress/runner/cypress_runner.js:8733:31)
      at Promise._settlePromise (http://localhost:5000/__cypress/runner/cypress_runner.js:8790:18)
      at Promise._settlePromise0 (http://localhost:5000/__cypress/runner/cypress_runner.js:8835:10)
      at Promise._settlePromises (http://localhost:5000/__cypress/runner/cypress_runner.js:8911:18)
      at _drainQueueStep (http://localhost:5000/__cypress/runner/cypress_runner.js:5505:12)
      at _drainQueue (http://localhost:5000/__cypress/runner/cypress_runner.js:5498:9)
      at Async.../../node_modules/bluebird/js/release/async.js.Async._drainQueues (http://localhost:5000/__cypress/runner/cypress_runner.js:5514:5)
      at Async.drainQueues (http://localhost:5000/__cypress/runner/cypress_runner.js:5384:14)
  From Your Spec Code:
      at Context.eval (http://localhost:5000/__cypress/tests?p=node_modules/@synthetixio/synpress/support/index.js:6334:15)

Yeah only getting 1 page showing up in assignWindows
http://localhost:5000/__/#/tests/integration/e2e/specs/example-spec.ts

Hey @marcusnewton, after a quick look I can see that synpress could support Electron (as Electron supports loading Chrome extensions which would be metamask in this case), but it would require more coding before that. I don't think that it's going to work in current state, sorry.

Ok thanks for confirming.

As the error is similar, this may be helpful: #804


address typo on #9184

First PR during fixit @lnhsingh for https://github.com/cockroachdb/docs/issues/9184

Under Subcommands, the third column for ALTER PRIMARY KEY says Yesnes.html) for a table. and seems to have an extra column in the markdown. I think this should just say Yes.

Changes applied to v20.2 and v21.1
Assigning to you for review

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/58a0ea8667fcf6c98b8d33dd4229172eb056f05b/
Edited pages:

v20.2/alter-table.md
v21.1/alter-table.md

Closes #9184


Surprising results for Form::Date.optional

Types::Form::Date works like this:
Types::Form::Date[nil]
# TypeError: no implicit conversion of nil into String
# from /usr/local/opt/rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/dry-types-0.8.1/lib/dry/types/coercions.rb:11:in `parse'

Types::Form::Date['']
#=> ""

Types::Form::Date['2016-01-01']
#=> Fri, 01 Jan 2016

but when we make the type optional in order to accept nil as value, it does no longer accept "invalid" date strings:
Types::Form::Date.optional[nil]
#=> nil

Types::Form::Date.optional['']
# Dry::Types::ConstraintError: "" violates constraints (#<struct Dry::Types::Result::Failure input="", error="\"\" must be an instance of Date">)
# from /usr/local/opt/rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/dry-types-0.8.1/lib/dry/types/sum.rb:40:in `block in call'

Types::Form::Date.optional['2016-01-01']
#=> Fri, 01 Jan 2016

Is this intentional or a bug? What would be the appropriate way to implement an optional Form::Date?

Oh that's interesting, it is intentional since optional helper simply does Types::Strict::Nil | Types::Form::Date but we could make it smarter. For now this will work for you:
irb(main):008:0> (Types::Form::Nil | Types::Form::Date)['']
=> nil
irb(main):009:0> (Types::Form::Nil | Types::Form::Date)['2016-05-04']
=> #<Date: 2016-05-04 ((2457513j,0s,0n),+0s,2299161j)>

The reason why it works like that is that Types::Form::Nil knows that an empty string should be coerced to nil.
Anyhow, I'm gonna leave this open as we could improve Type#optional behavior.

Actually I reported a new issue about this #130

@solnic thanks, but my use case is actually not with empty strings, but rather with invalid user input:
[89] pry(main)> (Types::Form::Nil | Types::Form::Date)['foo']
Dry::Types::ConstraintError: "foo" violates constraints (#<struct Dry::Types::Result::Failure input="foo", error="\"foo\" must be an instance of Date">)
from /usr/local/opt/rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/dry-types-0.8.1/lib/dry/types/sum.rb:40:in `block in call'

whereas
[90] pry(main)> Types::Form::Date['foo']
=> "foo"

In #130 you note that this happens with types that perform nil coercion (I assume from an empty string to nil?) but this is not actually the case here. It will rather return an empty string back:
Types::Form::Date['']
#=> ""

I assume a possible workaround would be:
(Types::Coercible::String | Types::Form::Date).optional

# or

(Types::Form::Nil | Types::Coercible::String | Types::Form::Date).optional

@padde ok so there's another issue here where sum type doesn't behave well for invalid input in a form type. I'll look into this. Seems like a bug.
re coercion, Types::Form::Nil does it, so you need to sum Form::Nil with another one to get a nil back from an empty string.

re coercion, I don't necessarily need/want nil back for an empty string although it would simplify things compared to our current implementation. The actual use case is that we want to display a validation error rather than raising a coercion error with invalid inputs. Still, it should be possible to omit the input (either by not including the field at all or by having the user submit an empty string).

@padde for validation pls use dry-validation...dry-types are not meant to be used for data validation

@solnic currently in the process of migrating from reform 1.x with extensive use of activemodel validations 😉 The validation basically just checks if the supplied value is_a?(Date) which seems to work fine otherwise.
I can live with the workarounds above for now though, again thanks a lot for your help.

@solnic it feels somehow inconsistent that Types::Form::{Date,Time,DateTime} will not accept nil, whereas all other form types do accept it. I realize this is due to the way the core Date.parse etc. methods work.
What's you opinion on that? Is this something that should be changed or is it intentional?

So other types return nil back? We should make this consistent for sure. I wanted Form types to work exclusively with string, hash and array types as potential input and nil should crash in all cases tbh as this is not an expected input with form data parsed by rack. OTOH I was told there are cases where some middleware may add something to params that can have different types (ie an integer, or nil) so we may want to tweak Form types to accept nil or already coerced values

@solnic yeah they do:
Types::Form::Int[nil]
=> nil

this was most probably introduced with https://github.com/dry-rb/dry-types/commit/273e9e8c7631e822bd9a30324e2b120b11dbe9ec if you observe:
[12] pry(main)> Integer(nil)
TypeError: can't convert nil into Integer
from (pry):16:in `Integer'

I also think either all or no form types should accept nil. If all accept nil this would also solve my original problem because then I wouldn't have to make it optional in the first place :)

re already coerced values, I think it makes much sense to accept already coerced values with any type. Although it might not be a frequent use case, I cannot think of a case where this would be hurtful.

I'd accept a patch which makes time/date related Form types fail gracefully and return original input. Is this something you could do?

Cool. Sure, I'll give it a shot!

@solnic

nil should crash in all cases tbh as this is not an expected input with form data parsed by rack

input doesn't alway come from web forms, it can be API or CSV import, where date can be nil or invalid format. In my case its CSV and i'm facing the same issue

@ZombieHarvester of course, but Form::* types shouldn't be used in such cases, we're optimizing them for a very specific use-case which is rack request params.
There's nothing stopping us from adding a more generic (thus much more complex and slower) coercible types, that would support many types of input. I'm more than happy to accept a PR which adds that :)

I checked all described issues on master and everything seems to work fine now so I'm closing this issue, feel free to comment tho.


Include an option in wsl command to force the output to English

Is your feature request related to a problem? Please describe.
When writing programs or script that calls the wsl command and parses the output, it is challenging if it changes depending on the language installed on the PC. For example, now in the WSL Store version if I call wsl --export, depending on the output I must guess the result. Before this change, no output meant success. Now I must parse the output.
Describe the solution you'd like
I want an option to be added like --force-english-output or --force-locale-output XX to the wsl command to output in a language different from the installed one.

@crramirez - I would suggest just keying off the process exit code, which should be 0 on success and nonzero on failure.

OK I didn't know this work for this command. I'll test. This will solve me this punctual problem.
Nevertheless, I would like this should implemented parsing for example wsl --list --verbose is complicated with localization. Also scanning the wsl --help results to guess which wsl capabilities are available.
Thanks for the suggestion

@benhillis checking the exit codes works very well.
@OneBlue the WSL from the Store is not an option for me. It is only available in Windows 11. Windows 10 1909 is still supported and it has a WSL version different from Windows 10 2004 and Windows 11 and also the store version. This is why I scan the wsl --help.

When writing programs or script that calls the wsl command and parses the output

There is another way which doesn't require parsing the output while exporting distro, you-know-how 🤐


Abstract @:resolve and @:op(a.b)

The feature is described in this post: https://haxe.io/releases/3.3.0/
It's not mentioned anywhere in the manual as far as I can tell.

Closed as part of #383. Did not mention @:resolve but I think that's superseded by @op(a.b).


doc: Update contributors and current leadership of project

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.

Just trying to get the about page up-to-date with new folks coming in.

OK, as you are mentioned twice, I left the first one as Dr. Katherine E. Stange, and changed the second to just Katherine Stange. Does that seem OK? Also, I looked and as far as I can see, no code from Clyde is actually merged yet. So the time to add him would be when something is merged (and there is actually an item in the PR checklist for doing that, if we were just taking the time to go through the checklist every time instead of being in such a blazing rush).

I looked and as far as I can see, no code from Clyde is actually merged yet. So the time to add him would be when something is merged (and there is actually an item in the PR checklist for doing that, if we were just taking the time to go through the checklist every time instead of being in such a blazing rush).

The list partially pre-dates the move to github and includes all the students that worked on the project in any capacity, even if they don't have code in the current version right now.  Unless we want to sort that all out retroactively and (re)move some names, I think it's fair to include Clyde, because he is in the same boat at the moment.  These other students who haven't checked in code have contributed in various ways including brainstorming, forming ideas, using numberscope, participating in discussions, creating prototypes etc. etc.  So I want to honour that.  If "contributors" means actual code, then we may need two lists, "code contributors" and "numberscope project contributors" or something.

All good. Definitely no reason to be stingy with credit. I just didn't realize the membership of this list.


Improve open connections management

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?
Description
Currently, in Traefik, HTTP connections stay open until clients decide to close them. This can lead to more open connections and higher memory usage.
Moreover, when you use Traefik with an upstream Load Balancer, this connection management method avoids an efficient traffic distribution when you scale up your Traefik instance. Rather than distributing requests to the newest instances, ensuring a more equitable traffic spread, the Load Balancer will stick to the same instance.
To tackle this, we're thinking of introducing two new options for the entrypoints' transport:

The first option limits the number of requests each client is allowed to make within one connection.
The second option limits the time a client is allowed to keep reusing the same connection for its requests.

Of course, you can use both options together and choose one or the other.
In practice, we believe these options will help spread the incoming traffic to new traffic instances as we scale within a more predictable timeframe.
We'd love to hear your thoughts on this proposal and how it might make Traefik even better.
Timeline
Conversation is time-boxed to one month.
Additional Notes
keepalivemaxrequests
--entrypoints.<name>.transport.keepalivemaxrequests # KeepAlive max requests.

Whenever a client sends a request within an open connection if this request number is greater than the keepalivemaxrequests threshold, Traefik will ask for a connection close (header Connection:close).
keepalivemaxtime
--entrypoints.<name>.transport.keepalivemaxtime # KeepAlive max time.

Whenever a client sends a request within an open connection if the elapsed time between the first request and the current request is greater than the keepalivemaxtime threshold, Traefik will ask for a connection close (header Connection:close`).

Thank you for this! It will be really helpful for our problematic clients that struggle to let go to connections.


Build Chain / agent queue

Hi,
Is there some factor like Demand (Phase 1) , Variable (Variable tab) on particular build I can set to do below:
When one agent have queue lenght (there are more than one build assigned) of 2, run next agent. Meaning, if one agent is doing a build and next build is awaiting, run second agent(vm).
This setup is for VM scaling where private agents runns.
Right now situation is either one agent (on VM1) have many build queued or I need to launch few VMs manually.
But I need VM scaling based on VM1 queue, this way next VMs could launch automatically (auto shutdown/deallocate script does closing job).
Maybe you know easier way (REST API inst giving clear results).
Please advice.
Regards Seb

megoels - you can add the Disable / Enable task we worked on and this could support the requirement.
however, the queue length is a REST call that needs to happen with a listener and i don't think that the place to implement this is a build task. you might need to setup a webApp or use Azure functions or logical apps to perform that queue availability check during the build as a listener while the build is running.
bottom line ... this is not the place to implement it IMHO.
G.

Hi and thank you,
This sounds very useful, i'm agree with grawcho this suppose to be kind of listener to the Agent queue which allocating and deallocating VM's according to usage.
I think it kind of extension which could be added to the Pool queue and allow you to configure and  monitor the queue to allocate/deallocate VM's.
Regarding the Disable/Enable Agents it included on this extension.
Regards.

Ok then,
Should I wait you guys add agent queue feature to this extension?
Cheers

I've suggested new extension which can be developed and as grawcho mentioned it need to be listener,
Nothing to add to this extension which is dedicated to build chain so your suggestion isn't applicable to this extension !


i18n(es): Translated netlify.mdx

What kind of changes does this PR include?

Translated content
Changes to the docs site code

Description

What does this PR change? Give us a brief description.
Translated netlify.mdx to spanish 😄

Gracias por la revisión @Waxer59 🎉


Url encode filename

Encode filename to avoid problems with url encoding on S3 getObject/pubOject actions.
This fixes the Error { NoSuchKey: The specified key does not exist }.
A side effect is to have all the cache files in the same folder and maybe it is ugly for someone, but it is not a technical limitation.

Can you show an example of a URL that would cause a problem with S3 getObject/putObject actions? We haven't run into this problem .

I had problems with any single url, have it arguments or not.
Just cloned yesterday afternoon the repository and started to see NoSuchKey
issues.
Adding the URIEncondeComponent to the key value when setting or getting to
cache was enough to fix it.
--
Iván González Valiente
Systems Developer / AWS Certified Developer
2016-07-15 15:03 GMT+02:00 Todd Hooper<EMAIL_ADDRESS>
Can you show an example of a URL that would cause a problem with S3
getObject/putObject actions? We haven't run into this problem .
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/prerender/prerender/pull/329#issuecomment-232945404,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB-24ymlOlmq-f4M7L_7RG7ikGcuB08cks5qV4UtgaJpZM4JNKmr
.

I had issues with S3 cache with every single url until I added a fix to the
names.
Also I understand this is a change that would mess up an existent cache and
it should only be used on new installations.
Feel free to merge when ever you consider it necessary, if that ever
happens.
Thank you
--
Iván González Valiente
Systems Developer / AWS Certified Developer
2016-07-15 20:10 GMT+02:00 Todd Hooper<EMAIL_ADDRESS>
We haven't had these issues with any URLs. If you were able to provide an
example to reproduce it, that would help. This is a pretty big change that
would change current keys on a lot of caches so it's not something we'd
merge unless it was a big issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/prerender/prerender/pull/329#issuecomment-233026130,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB-24xmwvifBVTnWPeLsp9eMucGUbj7hks5qV80ngaJpZM4JNKmr
.

We'll need some examples of URLs that caused issues because we've saved tens of millions of URLs on our hosted service and haven't run into an issue. It might be that we have things set up differently but I'd like to see some examples before we consider this. Feel free to reopen if you want to share any URLs that cause issues.


Change from_udp_host to create UDP socket in non-blocking mode by default

Like it says, if we create a socket in StatsdClient::from_udp_host, create it in non-blocking mode. We could also potentially support some sort of config object here to pass in. But, I don't think that's really needed since callers can always just use the StatsdClient::from_sink method for more control.

TODO:

Update the actual code in StatsdClient::from_udp_host
Update StatsdClient::from_udp_host docs to indicate that sockets are created in non-blocking mode
Update UdpMetricSink::from docs to indicate that the non-blocking example is done by default in StatsdClient::from_udp_host
Update lib.rs and README.md to indicate that sockets are created in non-blocking mode (maybe remove that section about creating a non-blocking socket?)
Change tests to just use from_udp_host and remove the non-blocking special cases


[SPARK-45362][PYTHON] Project out PARTITION BY expressions before Python UDTF 'eval' method consumes them

What changes were proposed in this pull request?
This PR projects out PARTITION BY expressions before Python UDTF 'eval' method consumes them.
Before this PR, if a query included this PARTITION BY clause:
SELECT * FROM udtf((SELECT a, b FROM TABLE t) PARTITION BY (c, d))

Then the eval method received four columns in each row: a, b, c, d.
After this PR, the eval method only receives two columns: a, b, as expected.
Why are the changes needed?
This makes the Python UDTF TABLE columns consistently match what the eval method receives, as expected.
Does this PR introduce any user-facing change?
Yes, see above.
How was this patch tested?
This PR adds new unit tests.
Was this patch authored or co-authored using generative AI tooling?
No

Seems like the failing tests are not related to the latest commit, and tests passed on the previous commit.

Thanks! merging to master.


Minor allocation optimization

At the moment, for every multiple write operation an iov array buffer is allocated. Which cause some churn when there are high volume of writes. Considering at max there can be Limits.IOV_MAX values, creating the ByteBuf once and re-using it based on the elements in the schedule operation.

Closed as explained in the comment before.


Fix pilot stuck on older processing build

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Description
This makes pilot only wait for the latest upload when waiting for processing, instead of checking for all builds that might be processing
Motivation and Context
Fixes the problem where pilot would get stuck waiting for an older build to finish processing by iTunes Connect
This could happen, for example, with a faulty upload. The only way of fixing this currently is by waiting till an Apple script removes the faulty build
This should fix #6069

We've actually tweaked this a lot in the past, and don't have a central place for it yet. @hjanuschka did some great work on https://github.com/fastlane/fastlane/pull/7386 https://github.com/fastlane/fastlane/pull/7387 and https://github.com/fastlane/fastlane/pull/7388. I'd very much be in favor of merging the 3 PRs into one (now that we're on a mono-gem) and add the changes you proposed to that if they make sense.
@hjanuschka what are your thoughts on it? 👍 The PRs have been open for a while, but I'd love to get this resolved 🚀

Seems good to me
Better to first make the unification of the wait build function and then think about this problem

@KrauseFx  i cleaned up the PR's closing all - only keeping #7386  - still waiting for tests to pass, but it should be ready for review.
@negebauer  maybe you can have a look/test it, and tell me if it works for you.

@hjanuschka I'm kind of new here 😅
On can I run fastlane on your PR?

@negebauer @hjanuschka's PR was merged so we can resume yours.
I have a question: can you explain how repeating the fetching of the processing builds makes sure that we wait for the right build? Is the intent that, in the time frame the build was sent, it will be added to the list of processing builds?
Shouldn't we instead for example:

wait for a very specific build number (the one we just uploaded)
check the processing builds before up uploading and comparing before starting to wait

etc.

@lacostej
The repeating part was how it was done before. I understood from the comments of wait_for_processing_build  here that only when it's the first build of a new app it doesn't go into processing right away. So the last should be the one that was just updated.
What I propose to change is to only wait for one build (the latest) instead of checking if all builds finished processing

@KrauseFx @hjanuschka @lacostej  I had this problem again today

I uploaded the build number 75 binary but pilot is still stuck waiting for build  73
Is it good for merging?

@negebauer any updates on this PR? the build watcher has been reverted

@hjanuschka  I haven't looked at it
So there a multiple watchers now?

Unfortunately the build watcher change introduced multiple regressions so we had to revert the changes for now 😢
Do we still need this PR then?

@KrauseFx According to this
    break if builds.count == 0
    latest_build = builds.last

This PR would still be needed
If you upload a build with pilot, cancel it before it's done and then upload a second one pilot will be stuck waiting for the first one to be processed, which will never happen (apple will actually delete that build at some point)
We would just need to change that for this
    latest_build = builds.last unless latest_build
    break unless builds.include?(latest_build)

@KrauseFx @hjanuschka I actually deleted the fork from where this PR came (yeah, silly me)
I opened a new PR #8640 with the change in the pilot build watcher


How to detect python is running inside Spyder

Problem Description
Is the an "official" way to detect a python session is running as a console inside Spyder?
There are some methods listed in https://stackoverflow.com/questions/53829284/how-to-know-if-a-script-is-running-in-spyder-or-any-other-python-ide, but it is not directly clear whether there is a preferred one.
Also see https://github.com/tqdm/tqdm/pull/1559

Hey @eendebakpt, thanks for reporting. Between the two methods mentioned in the SO question you referenced, I think it's safer to use the second one, i.e.
from IPython import get_ipython

shell_cls_name = get_ipython().__class__.__name__
if shell_cls_name == 'SpyderShell':
    # Do things only for Spyder
    ...

That's because we're considering to remove all env vars we use to start a kernel (the SPY_* ones mentioned there), but SpyderShell is not going to go away.
Let us know if that's enough for the Spyder support you're trying to add to tqdm (and thanks for taking care of that, by the way).

Closing because I saw you followed my suggestion in your tqdm PR.


Download of user-friendly tables with uuid substitution

The table download feature gives a direct representation of the database contents including some columns which are links to rows in other tables. In these columns the entries are opaque identifiers. For some user applications it is better to have the identifiers replaced with a human-readable text derived from the target element.
Example 1: MIP Variable

sn --> sn.title
provmip --> provmip.label
unid --> unid.text

Example 2: Spatial Shape

dimids --> list of dimid.label values.

There is now an option for pretty downloads. By default these use the label of the linked record


models: Make a list of models to be added and create a road map

TODO:

[ ] Curate a list of models that should be added
[ ] Make a roadmap for implementation of those models

Allen NLP has a good collection of models and should be considered as a candidate: https://docs.allennlp.org/main/

https://github.com/abhishekkrthakur/chaii-hindi-tamil-question-answering


Let exceptions propogate from make_request

This prevents a value of None from ever being returned
from make_request.  Previously, exceptions were caught and
after the retry logic would just return a value of None.
Now, if things like ConnectionErrors, socket.errors, etc.
are raised, then this will propogate.  This also fixed the
client interface that expected that a tuple was always returned
from make_request.  This is now the case.
Noticed this while working on another bug fix.  Now instead
of:
  File "t.py", line 10, in <module>
    ContentDisposition="attachment; filename=5小時接力起跑.jpg;")
  File "botocore/botocore/client.py", line 292, in _api_call
    operation_model, request_dict)
TypeError: 'NoneType' object is not iterable

you'll get:
Traceback (most recent call last):
  File "t.py", line 10, in <module>
    ContentDisposition="attachment; filename=5小時接力起跑.jpg;")
  File "botocore/botocore/client.py", line 292, in _api_call
    operation_model, request_dict)
  File "botocore/botocore/endpoint.py", line 109, in make_request
    return self._send_request(request_dict, operation_model)
  File "botocore/botocore/endpoint.py", line 161, in _send_request
    raise exception
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 43: ordinal not in range(128)

Though keep in mind the above traceback is actually also a bug and will be fixed
shortly.
cc @danielgtaylor @kyleknap

Also fixes https://github.com/boto/boto3/issues/63

Looks good. :ship:

Coverage increased (+0.0%) to 94.24% when pulling 360216b91eb57a06abd651a08a4ec6a7facaebb0 on jamesls:endpoint-exceptions into f2621b0a715e4b502efbce56116566765c1c8e9a on boto:develop.


Performance fix to skip retries if there is no error

Performance fix takes care of 2 things in this PR
1.) Detach was doing unnecessary retry for detach API call on success
2.) Retrygap variable was global and not thread safe. So it was in holding unwanted value on each exponential retry for Attach/Detach calls.

Before fix
We retried on non-error condition and also the retry-gap was some global value set by other thread so it was 60 seconds
{"level":"info","ts":"2021-08-25T06:50:25.603Z","caller":"provider/detach_volume.go:38","msg":"Validating basic inputs for detach method...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachmentTemplate":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-08-25T06:50:25.603Z","caller":"provider/detach_volume.go:49","msg":"Checking if volume is already attached ","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:50:25.603Z","caller":"provider/get_volume_attachment.go:34","msg":"Validating basic inputs for GetVolumeAttachment method...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachRequest":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-08-25T06:50:25.603Z","caller":"provider/get_volume_attachment.go:86","msg":"Getting VolumeAttachmentList from VPC provider...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:50:25.603Z","caller":"instances/iks_list_volume_attachments.go:47","msg":"Equivalent curl command and query parameters","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/getAttachmentsList?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","volumeAttachmentTemplate":{"clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-292aac44-44d9-4d32-a154-daafb9c641e5"}},"Operation":{"Name":"ListVolumeAttachment","Method":"GET","PathPattern":"v2/storage/vpc/getAttachmentsList"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678"}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"instances/iks_list_volume_attachments.go:54","msg":"Successfully retrieved the volume attachments","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"provider/get_volume_attachment.go:107","msg":"Successfully found volume attachment","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachment":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc","name":"impound-aspire-preppy-spoils","status":"attached","type":"data","device":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc-6qln9"},"volume":{"id":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","name":"pvc-b56a352d-0950-47d9-8545-529c947599b6"}}}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"provider/get_volume_attachment.go:109","msg":"Successfully fetched volume attachment from VPC provider","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeResponse":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"","vpcVolumeAttachment":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc","name":"impound-aspire-preppy-spoils","type":"data","device_path":"/dev/disk/by-id/virtio-0737-b1a82cb9-a2b9-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"provider/get_volume_attachment.go:48","msg":"Volume attachment response","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachmentResponse":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"","vpcVolumeAttachment":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc","name":"impound-aspire-preppy-spoils","type":"data","device_path":"/dev/disk/by-id/virtio-0737-b1a82cb9-a2b9-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"provider/detach_volume.go:53","msg":"Found volume attachment","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","currentVolAttachment":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"","vpcVolumeAttachment":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc","name":"impound-aspire-preppy-spoils","type":"data","device_path":"/dev/disk/by-id/virtio-0737-b1a82cb9-a2b9-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"provider/detach_volume.go:56","msg":"Detaching volume from VPC provider...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:50:42.391Z","caller":"instances/iks_detach_volume.go:47","msg":"Equivalent curl command and query parameters","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/deleteAttachment?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&volumeAttachmentID=0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","volumeAttachmentTemplate":{"id":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc","clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-292aac44-44d9-4d32-a154-daafb9c641e5"}},"Operation":{"Name":"DetachVolume","Method":"DELETE","PathPattern":"v2/storage/vpc/deleteAttachment"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","volumeAttachmentID":"0737-b1a82cb9-a2b9-4b97-ac94-de86cbda2acc"}
{"level":"info","ts":"2021-08-25T06:50:48.405Z","caller":"instances/iks_detach_volume.go:58","msg":"Successfully deleted the volume attachment","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:50:48.405Z","caller":"provider/util.go:186","msg":"UNEXPECTED RESULT, Re-attempting execution ..","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","attempt..":2,"retry-gap":60,"max-retry-Attempts":10,"stopRetry":false}
{"level":"info","ts":"2021-08-25T06:51:48.406Z","caller":"provider/detach_volume.go:49","msg":"Checking if volume is already attached ","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:51:48.406Z","caller":"provider/get_volume_attachment.go:34","msg":"Validating basic inputs for GetVolumeAttachment method...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachRequest":{"volumeID":"r006-292aac44-44d9-4d32-a154-daafb9c641e5","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-08-25T06:51:48.406Z","caller":"provider/get_volume_attachment.go:86","msg":"Getting VolumeAttachmentList from VPC provider...","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:51:48.406Z","caller":"instances/iks_list_volume_attachments.go:47","msg":"Equivalent curl command and query parameters","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/getAttachmentsList?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678","volumeAttachmentTemplate":{"clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-292aac44-44d9-4d32-a154-daafb9c641e5"}},"Operation":{"Name":"ListVolumeAttachment","Method":"GET","PathPattern":"v2/storage/vpc/getAttachmentsList"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678"}
{"level":"info","ts":"2021-08-25T06:51:49.293Z","caller":"instances/iks_list_volume_attachments.go:54","msg":"Successfully retrieved the volume attachments","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:51:49.293Z","caller":"provider/get_volume_attachment.go:48","msg":"Volume attachment response","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","volumeAttachmentResponse":null,"error":"{Code:VolumeAttachFindFailed, Type:VolumeAttachFindFailed, Description:No volume attachment could be found for the specified volume ID 'r006-292aac44-44d9-4d32-a154-daafb9c641e5' and instance ID 'kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678'., BackendError:no VolumeAttachment Found, RC:400}"}
{"level":"info","ts":"2021-08-25T06:51:49.293Z","caller":"provider/detach_volume.go:60","msg":"No volume attachment found for","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","currentVolAttachment":null,"error":"{Code:VolumeAttachFindFailed, Type:VolumeAttachFindFailed, Description:No volume attachment could be found for the specified volume ID 'r006-292aac44-44d9-4d32-a154-daafb9c641e5' and instance ID 'kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001678'., BackendError:no VolumeAttachment Found, RC:400}"}
{"level":"error","ts":"2021-08-25T06:51:49.293Z","caller":"provider/get_volume_attachment.go:115","msg":"Volume attachment not found","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0"}
{"level":"info","ts":"2021-08-25T06:51:49.293Z","caller":"provider/detach_volume.go:72","msg":"Successfully detached volume from VPC provider","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","resp":{"Status":"","StatusCode":200,"Proto":"","ProtoMajor":0,"ProtoMinor":0,"Header":null,"Body":null,"ContentLength":0,"TransferEncoding":null,"Close":false,"Uncompressed":false,"Trailer":null,"Request":null,"TLS":null}}
{"level":"info","ts":"2021-08-25T06:51:49.293Z","caller":"metrics/metrics.go:73","msg":"Time to complete","RequestID":"5af882cd-2949-4555-8ab7-fdde79759ca0","DetachVolume":83.690189674}

After fix
We now retry exponentially from 10 seconds for Attach/detach API calls.
{"level":"info","ts":"2021-09-03T05:23:19.695Z","caller":"provider/detach_volume.go:44","msg":"Validating basic inputs for detach method...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachmentTemplate":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-09-03T05:23:19.695Z","caller":"provider/detach_volume.go:55","msg":"Checking if volume is already attached ","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:19.695Z","caller":"provider/get_volume_attachment.go:40","msg":"Validating basic inputs for GetVolumeAttachment method...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachRequest":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-09-03T05:23:19.695Z","caller":"provider/get_volume_attachment.go:92","msg":"Getting VolumeAttachmentList from VPC provider...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:19.695Z","caller":"instances/iks_list_volume_attachments.go:47","msg":"Equivalent curl command and query parameters","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/getAttachmentsList?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentTemplate":{"clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4"}},"Operation":{"Name":"ListVolumeAttachment","Method":"GET","PathPattern":"v2/storage/vpc/getAttachmentsList"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850"}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"instances/iks_list_volume_attachments.go:54","msg":"Successfully retrieved the volume attachments","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"provider/get_volume_attachment.go:113","msg":"Successfully found volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","status":"attached","type":"data","device":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4-nb7xh"},"volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","name":"pvc-3245cb67-334d-4e2d-9f69-17ca6d47e662"}}}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"provider/get_volume_attachment.go:115","msg":"Successfully fetched volume attachment from VPC provider","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"provider/get_volume_attachment.go:54","msg":"Volume attachment response","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachmentResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"provider/detach_volume.go:59","msg":"Found volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","currentVolAttachment":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"provider/detach_volume.go:62","msg":"Detaching volume from VPC provider...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:20.832Z","caller":"instances/iks_detach_volume.go:47","msg":"Equivalent curl command and query parameters","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/deleteAttachment?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&volumeAttachmentID=0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentTemplate":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4"}},"Operation":{"Name":"DetachVolume","Method":"DELETE","PathPattern":"v2/storage/vpc/deleteAttachment"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentID":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4"}
{"level":"error","ts":"2021-09-03T05:23:34.515Z","caller":"instances/iks_detach_volume.go:51","msg":"Error occurred while deleting volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","error":"P4050: The 'vpc-gen2' infrastructure operation failed with the message: Conflicting update of instance, please retry request"}
{"level":"info","ts":"2021-09-03T05:23:34.515Z","caller":"instances/iks_detach_volume.go:58","msg":"Successfully deleted the volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:34.515Z","caller":"provider/util.go:188","msg":"UNEXPECTED RESULT, Re-attempting execution ..","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","attempt..":2,"retry-gap":10,"max-retry-Attempts":10,"stopRetry":false,"error":"P4050: The 'vpc-gen2' infrastructure operation failed with the message: Conflicting update of instance, please retry request"}
{"level":"info","ts":"2021-09-03T05:23:44.515Z","caller":"provider/detach_volume.go:55","msg":"Checking if volume is already attached ","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:44.515Z","caller":"provider/get_volume_attachment.go:40","msg":"Validating basic inputs for GetVolumeAttachment method...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachRequest":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-09-03T05:23:44.515Z","caller":"provider/get_volume_attachment.go:92","msg":"Getting VolumeAttachmentList from VPC provider...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:44.515Z","caller":"instances/iks_list_volume_attachments.go:47","msg":"Equivalent curl command and query parameters","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/getAttachmentsList?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentTemplate":{"clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4"}},"Operation":{"Name":"ListVolumeAttachment","Method":"GET","PathPattern":"v2/storage/vpc/getAttachmentsList"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850"}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"instances/iks_list_volume_attachments.go:54","msg":"Successfully retrieved the volume attachments","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"provider/get_volume_attachment.go:113","msg":"Successfully found volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","status":"attached","type":"data","device":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4-nb7xh"},"volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","name":"pvc-3245cb67-334d-4e2d-9f69-17ca6d47e662"}}}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"provider/get_volume_attachment.go:115","msg":"Successfully fetched volume attachment from VPC provider","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"provider/get_volume_attachment.go:54","msg":"Volume attachment response","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachmentResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"provider/detach_volume.go:59","msg":"Found volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","currentVolAttachment":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data","device_path":"/dev/disk/by-id/virtio-0727-bd4e7349-04e4-4"},"iksVolumeAttachment":null,"status":"attached"}}
{"level":"info","ts":"2021-09-03T05:23:47.086Z","caller":"provider/detach_volume.go:62","msg":"Detaching volume from VPC provider...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:23:47.087Z","caller":"instances/iks_detach_volume.go:47","msg":"Equivalent curl command and query parameters","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/deleteAttachment?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&volumeAttachmentID=0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentTemplate":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4"}},"Operation":{"Name":"DetachVolume","Method":"DELETE","PathPattern":"v2/storage/vpc/deleteAttachment"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentID":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4"}
{"level":"info","ts":"2021-09-03T05:23:54.238Z","caller":"instances/iks_detach_volume.go:58","msg":"Successfully deleted the volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"error","ts":"2021-09-03T05:23:54.238Z","caller":"instances/iks_detach_volume.go:51","msg":"Error occurred while deleting volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","error":"P4050: The 'vpc-gen2' infrastructure operation failed with the message: Conflicting update of instance, please retry request"}
{"level":"info","ts":"2021-09-03T05:23:54.238Z","caller":"provider/util.go:188","msg":"UNEXPECTED RESULT, Re-attempting execution ..","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","attempt..":3,"retry-gap":20,"max-retry-Attempts":10,"stopRetry":false,"error":"P4050: The 'vpc-gen2' infrastructure operation failed with the message: Conflicting update of instance, please retry request"}
{"level":"info","ts":"2021-09-03T05:24:14.238Z","caller":"provider/detach_volume.go:55","msg":"Checking if volume is already attached ","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:24:14.238Z","caller":"provider/get_volume_attachment.go:40","msg":"Validating basic inputs for GetVolumeAttachment method...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachRequest":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","vpcVolumeAttachment":null,"iksVolumeAttachment":{"clusterID":"c2q7kk3d0m1ld3ri4f7g"}}}
{"level":"info","ts":"2021-09-03T05:24:14.238Z","caller":"provider/get_volume_attachment.go:92","msg":"Getting VolumeAttachmentList from VPC provider...","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:24:14.238Z","caller":"instances/iks_list_volume_attachments.go:47","msg":"Equivalent curl command and query parameters","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","URL":"https://private.us-south.containers.cloud.ibm.com/v2/storage/vpc/getAttachmentsList?cluster=c2q7kk3d0m1ld3ri4f7g&generation=2&version=2020-07-02&worker=kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850","volumeAttachmentTemplate":{"clusterID":"c2q7kk3d0m1ld3ri4f7g","volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4"}},"Operation":{"Name":"ListVolumeAttachment","Method":"GET","PathPattern":"v2/storage/vpc/getAttachmentsList"},"cluster":"c2q7kk3d0m1ld3ri4f7g","worker":"kube-c2q7kk3d0m1ld3ri4f7g-myclustervp-default-00001850"}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"instances/iks_list_volume_attachments.go:54","msg":"Successfully retrieved the volume attachments","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb"}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"provider/get_volume_attachment.go:113","msg":"Successfully found volume attachment","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","status":"detaching","type":"data","device":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4-nb7xh"},"volume":{"id":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","name":"pvc-3245cb67-334d-4e2d-9f69-17ca6d47e662"}}}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"provider/get_volume_attachment.go:115","msg":"Successfully fetched volume attachment from VPC provider","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data"},"iksVolumeAttachment":null,"status":"detaching"}}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"provider/get_volume_attachment.go:54","msg":"Volume attachment response","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","volumeAttachmentResponse":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data"},"iksVolumeAttachment":null,"status":"detaching"}}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"provider/detach_volume.go:69","msg":"No volume attachment found for","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","currentVolAttachment":{"volumeID":"r006-efbe222e-a7b6-4d49-86c0-413de063c8d4","instanceID":"","vpcVolumeAttachment":{"id":"0727-bd4e7349-04e4-40f1-abd2-620ad27d96d4","name":"uncoated-photo-ranked-citable","type":"data"},"iksVolumeAttachment":null,"status":"detaching"}}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"provider/detach_volume.go:81","msg":"Successfully detached volume from VPC provider","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","resp":{"Status":"","StatusCode":200,"Proto":"","ProtoMajor":0,"ProtoMinor":0,"Header":null,"Body":null,"ContentLength":0,"TransferEncoding":null,"Close":false,"Uncompressed":false,"Trailer":null,"Request":null,"TLS":null}}
{"level":"info","ts":"2021-09-03T05:24:15.106Z","caller":"metrics/metrics.go:73","msg":"Time to complete","RequestID":"ee61bf6e-bb77-496c-95d1-859b49ad2aeb","DetachVolume":55.410961679}


WinRT support

This commit resolves #2.
Sadly, WinRT doesn't seem to have any APIs for resolving relative paths (GetFullPathNameW isn't available and while _wfullpath compiles, it always returns NULL), so this commit only resolves relative paths when on regular Win32.
I've tested this fix under the following compilers and runtimes:

Compiled with Visual Studio 2015

Run on Win10 desktop
Run on Win10 phone
Run on Win8.1 phone

Compiled with Visual Studio 2013

Run on Win7 desktop
Run Win10 desktop

Thanks Aaron!
I changed inclusion of windows.h in order to avoid problems with windows sockets.
From https://msdn.microsoft.com/en-us/library/windows/desktop/ms737629(v=vs.85).aspx
"The Winsock2.h header file internally includes core elements from the Windows.h header file, so there is not usually an #include line for the Windows.h header file in Winsock applications. If an #include line is needed for the Windows.h header file, this should be preceded with the #define WIN32_LEAN_AND_MEAN macro. For historical reasons, the Windows.h header defaults to including the Winsock.h header file for Windows Sockets 1.1. The declarations in the Winsock.h header file will conflict with the declarations in the Winsock2.h header file required by Windows Sockets 2.0. The WIN32_LEAN_AND_MEAN macro prevents the Winsock.h from being included by the Windows.h header."
Could you please confirm if the new version works in Windows RT?

I pulled master and its working for WinRT.  Thanks!


Volatile members

My understanding is that it is correct to call ButtonProcess from a timer. If this is the case, would it be correct for the (non-array) members of the Debouncer struct to be volatile?

Usually, I would call ButtonProcess in the main loop.
I'm an old school programmer who likes to do everything outside of an
interrupt. So, I would (precluding any kind of RTOS) set a volatile flag
inside the interrupt routine of the timer and have the main loop respond by
calling all the needed functions.
The members can be set to volatile if you would like to use the functions
within a timer interrupt, though. That's fine.
It might be good for me to commit a change to the code with some added
documentation on the use of the functions within interrupt routines in
general. Not a bad idea.
On May 19, 2016 9:36 AM, "Dimpl"<EMAIL_ADDRESS>wrote:

My understanding is that it is correct to call ButtonProcess from a timer.
If this is the case, would it be correct for the (non-array) members of the
Debouncer struct to be volatile? I was having an unusual issue, and making
this the case resolved it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/tcleg/Button_Debouncer/issues/1

Hi,
I've used your code (C++) (and modified to support a 16 bit button port - I use PCF8575) and it works great in a polled fasion. I would however like to utilise the interrupt instead but I don't quite understand how to incorporate your code in an interrupt fasion. Before incorporating your code I had my input under interrupt control where the interrupt routine just sets a flag I check in the main loop.
in your other post here aboove you mention you planned to update your exampple with info around interrupt handling - is that something you would do soon?
Thanks for sharing this gr8 code...
Kind Regards
Lars Dahlberg


Fix the issue of poor sampling in the alchemical space

In this PR, we aim to resolve the issue of poor sampling in the alchemical space, assuming there might be bug(s) in the code that contributed to the issue.

Note that the work of this PR was later continued and finished by PR #23.


NSException.raise can't be handled in pure Swift

Swift 2.0 can also not handle NSExceptions. Therefore is the issue #10 still effective und should be reactivated.

In current version I use standard error-handling present in Swift 2.0.


[WIP] Remove go-bits dependency

Required for all non-trivial PRs

[ ] Rebased/mergable
[ ] Tests pass
[ ] CHANGELOG.md updated

Note Should not be merged until we decide to move to Go 1.9.
This PR replaces the github.com/dgryksi/go-bits dependency with the standard library math/bits package.

@jwilder sorry I did run the benchmarks before pushing this, but didn't attach them to the issue. Here are the ones for the Float{Encoder, Decoder}:
⇒  benchstat /tmp/old.txt /tmp/new.txt
name            old time/op    new time/op    delta
FloatEncoder-4    7.15µs ±10%    6.95µs ± 6%    ~           (p=0.119 n=11+10)
FloatDecoder-4    1.89µs ± 7%    1.81µs ± 3%  -4.23%        (p=0.003 n=11+11)

name            old alloc/op   new alloc/op   delta
FloatEncoder-4      624B ± 0%      624B ± 0%    ~     (all samples are equal)
FloatDecoder-4    0.00B ±NaN%    0.00B ±NaN%    ~     (all samples are equal)

name            old allocs/op  new allocs/op  delta
FloatEncoder-4      4.00 ± 0%      4.00 ± 0%    ~     (all samples are equal)
FloatDecoder-4     0.00 ±NaN%     0.00 ±NaN%    ~     (all samples are equal)

Not a huge amount in it; I think the change is fine.
I'll add build tags.

@jwilder I think this is in good shape now. Had to do some fiddly abstractions to ensure that the committed code worked both on Go 1.9 and previous versions. When we commit to Go 1.9 I'll remove the pkg/bits package and directly call into math/bits from the hll and tsm1.


MySQL 8

The documentation seems to only refer to MySQL 5.7. Is MySQL 8 also supported?

Yes. You can use any modern MySQL database.


Add FullPageOfflineBlockingView to ReimbursementAccountPage

@MariaHCD
cc @nkuoch
Details
How about this? I added the header component because I think it aligns with our look that way.
If user navigates to /bank-account, e.g. clicks "Connect bank account" from workspaces settings, we will show the offline view.
Video
https://recordit.co/e4RrCwN3hi

Once they are on the flow, it will follow our originally planned pattern c
Fixed Issues
Part of https://github.com/Expensify/Expensify/issues/226858
Tests

Create user
Create workspace
Go to workspace settings
Go offline
Click "Connect bank account"
Verify that you see a full page blocker view. Verify that all the header buttons work
Go back online, verify that it automatically brings you to the first bank account step

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I included screenshots or videos for tests on all platforms
[ ] I ran the tests on all platforms & verified they passed on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I followed proper code patterns (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I followed the guidelines as stated in the Review Guidelines
[ ] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

 Verify that all the header buttons work
Go back online, verify that it automatically brings you to the first bank account step

[ ] Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Not sure I understand exactly when we want to show the fullPageOffline.
When clicking on Connect online with Plaid, but that's already done.
So, what other cases do you want to handle?
I personally thought that any "form" view should still be displayed when offline (only with a disabled button and offline text).
What else needs a full page in this flow?

If a user clicks "Connect bank account" while offline, they will just see this spinner:

I don't think this is super important, so we can leave it as that

Updated so that it only shows the blocking view if the addReimbursementAccountPage is still loading

If a user clicks "Connect bank account" while offline, they will just see this spinner:
I don't think this is super important, so we can leave it as that

I don't think we should show a spinner. Doesn't the OP clearly show we should show the "you appear to be offline" message?

Discussed quickly with @MariaHCD and @nkuoch 1:1, we will have an offline pattern now. Just for when the reimbursement data is being loaded.
So if we are still waiting on loading the reimbursement data, and user goes offline, then we will show the oflfine message shown in the PR description. If they make it to one of the add VBA steps, they will see the form and it will be handled in a Pattern C fashion.

Ah phew, that sounds more like it! So pattern D for loading and then Pattern C for any of the individual steps. Thanks!

Just to clarify as well, what happens in this scenario?

Go offline
Click into the Workspace settings
Click Connect bank account

This video in the PR description shows you exactly that :) : https://recordit.co/e4RrCwN3hi
The pause right before I click "Connect Bank Account" is me setting the computer to offline

Oh, I missed the link. Perfecto, thanks @ctkochan22!

Great idea. Update: http://recordit.co/fQHWlO3Ea9

🚀 Deployed to staging by @ctkochan22 in version: 1.2.11-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @AndrewGable in version: 1.2.11-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Why Is the Native Check Limited to SU Binary Only?

Hello, I am a beginner developer and I have a question.
Regarding the native check items, is there a specific reason why only the su binary is checked? When looking at the code structure, it seems like it would be easy to add checks for busybox or magisk binaries as well. I am curious why only the su binary undergoes additional checks.

Thanks for the question. Initially su was deemed the more imported binary to check for but we could certinaly add the ability to check for other binaries via the native check.


Fix background color of server "home page" feature

Before:

After:

* The weird bar on the right side is caused by a 10px margin on the .pageWrapper-2PwDoS, .content-1jQy2l, .applicationStore-2nk7Lo classes (here). I'm not entirely sure what the purpose of this is, but I didn't want to mess with it, as I don't know where else the .content-1jQy2l class appears.

On further inspection forum threads are completely unsupported/are broken (I got this theme yesterday lol), I don't plan to fix that myself because I don't use them, I just wanted to make the surface-level stuff fit in 🥴


LD_PRELOAD cannot be preloaded, possible regression with #4312

Describe the bug
On Ubuntu-24.04, when analyzing bitcoin v0.20.1, the logging phase fails.
CodeChecker version
master a6663b3349c54a5d00687bd3d3695ead19b8e060
To Reproduce
# Fresh build of CodeChecker on master
git clone https://github.com/Ericsson/codechecker.git
cd codechecker
make venv package
source venv
export PATH="$PWD/build/CodeChecker/bin:$PATH"
cd ..
# Clone and log bitcoin project
git clone https://github.com/bitcoin/bitcoin.git -b v0.20.1
cd bitcoin
./autogen.sh && ./configure --disable-wallet --disable-static --disable-tests --without-gui
CodeChecker log -b 'make -j' -o compile_commands.json

Results in this error for all TUs:
CXX      lib/libunivalue_la-univalue_get.lo
ERROR: ld.so: object 'ldlogger.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Expected behaviour
I expect the log to produce a compilation database, but it is empty.
Desktop (please complete the following information)

OS: WSL Ubuntu-24.04
Browser: not relevant
Version: not relevant

Additional context
I see that the issue came up in #3858, and I suspect that the regression to this error happened #4312.
I think the change should not just be reverted, but instead, the machine architecture of the TU analyzed should be added to LD_LIBRARY_PATH env variable of the compiler invocation to be logged.

I have tested with the latest master version (already CMake-based) Bitcoin project, and there is no mention of it overriding the LD_LIBRARY_PATH. The issue still holds.
IMO we need this https://github.com/Ericsson/codechecker/pull/3919, but with the modification that ensures we also support a different-architecture binary than the host OS.
Right now, I see 2 ways of doing this:

we detect the architecture of the compiler we use for logging
blindly pass all the shared objects to the binary by adding all of them (maybe multiple absolute path entries for LD_PRELOAD, or just a relative path, and adding all the machine-specific directories to LD_PRELOAD_PATH)

The problem with the solution in #3919 (which was reverted and fixed in  #4314) was that it put the absolute path of the ldlogger.so into to the LD_LIBRARY_PATH. The 32bits version of the ldlogger.so was used on a 32bits host, and the 64bits version on a 64 bits host. Unfortunately this is not correct, as not the architecture type of the host which matters, but the architecture type of the gcc compiler that we logged. So a user reported that logging was not working correctly when he was logging a 32bits gcc on a 64 bits machine as the 64 bits ldlogger was loaded which could not be dynamically linked with the 32bits gcc.
The currently implemented strategy as of #4314 is the following:
The ldlogger.so is placed in
/opt/CodeChecker/ld_logger/lib/i386/ldlogger.so #32 bits
/opt/CodeChecker/ld_logger/lib/x86_64/ldlogger.so #64 bits
We set the LD_LIBRARY_PATH to the directory containing containing dir and the LD_PRELOAD env var to relative ldlogger.so
LD_LIBRARY_PATH=/opt/CodeChecker/ld_logger/lib
LD_PRELOAD=ldlogger.so
then the linux will automatically select the ld_logger/lib/i386 and the ld_logger/lib/x86_64 subdirectories based on the architecture of the logged gcc.
Has this behaviour changed on the newest linux ubunut 24? The current implementation works fine (according to my tests) on ubuntu 20,22, rhel 8,9.

I have created a draft for option 2 since it seemed like the simpler solution.
I have also tested it on Ubuntu24, and the multiple .so files that are possibly reachable due to all of them being added are not an issue, the logger works as expected, and if I remove only the relevant ldlogger.so (x86_64 for my machine), but kept the others, the log command correctly detected that I meet neither the ld-logger nor the intercept-build requirement.
I have also left in the old path, which just includes the lib folder.
PR here: #4394


No Module Named Bleu

Hi, where is the Bleu come from?
I encounter this when run eval
File "src/qg/eval_on_unilm_tokenized_ref.py", line 4, in <module>
    from bleu.bleu import Bleu
ImportError: No module named bleu.bleu

Hi, The file qg/eval_on_unilm_tokenized_ref.py is dependent on the evaluation scripts of Du et al., (2017). You could find the BLEU package at this folder.


Missing numbers in fairminters API

"earned_quantity": null,
"commission": null,
"paid_quantity": null,

fixed here https://github.com/CounterpartyXCP/counterparty-core/pull/2525/commits/ddfffcb4d253c4ccd1283a5297c2fb5e2c7c4be4


Add dynamic DCB configuration to Juniper switches

Implements forwarding classes, classifiers and traffic control profiles.
Applies DCB settings to interfaces dynamically.
Adds scheduler and scheduler map configurations.

lgtm

/cherry-pick 18.0-fr1

/cherry-pick 18.0-fr1


Update tensorflow-probability version range

Loosening the requirements allows for the installation of the newer version 0.25 of tensorflow-probability, enabling the installation of tensorflow 2.18 and consequently numpy 2.0.

Hi @WillianFuks!
Currently setup.py specifies upper version bounds for Pandas and Tensorflow-probilitistic.
IMHO, strict upper bounds can lead to dependency conflicts and make it harder for users to integrate the library with other packages. To improve compatibility and the overall developer experience, it might be helpful to remove these upper version constraints.
This blog post from Henry Schreiner (core maintenair of many scientific building packages) explains the drawbacks of tight version bounds in more detail.
What do you think about loosening these constraints, I can open a PR removing them if you agree :)

Hi @williamjamir
I certainly agree with you, I tried avoiding setting upper bounds for quite a while but then each new release from dependencies that contained backwards incompatible changes kept breaking things up.
It became a problem of finding a balance between avoiding conflicts internally and also externally with the user`s own packages versions installed.
So the strategy taken, in a way, is to keep up-to-date with current releases while protecting the code against new breaking changes. Not sure if that was the best approach, it was what worked at the time.
I'll read your reference article, if there are any ideas on how to remove the upper bounds while avoiding having the code breaking unexpectedly I'm certainly in favor of doing that.


”OCNA SIBIULUI” is listed in the drop-down menu

Description:
"OCNA SIBIULUI" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "OCNA SIBIULUI" in the search bar.

Expected results
The location is listed in the drop-down menu as "Oraș OCNA SIBIULUI, SIBIU".


Feature/jest

I have added jest using npm. To make it work with the npm test command I added the script jest to the package.json.
Note: you cannot run a test from the root directory, you need to inside the directory which has a node modules folder.
Run: npm test bloom.test.js
its a dummy test to see if it works

@diptigandhi24 and @DeveloperMetal please follow the guideline while creating the Pull Request request.
@DeveloperMetal Please ensure that before reviewing the Pull Request.
https://github.com/Bloomstack/erpnext/wiki/Guidelines-for-writing-better-pull-request-description-for-features
https://github.com/Bloomstack/erpnext/wiki/Guidelines-for-writing-better-pull-request-description-for-fixes


fix: update regex chunk filter logic to allow empty chunk names

Summary

fixes #8529 by allowing None chunks to pass the Regex like in JS . This would be a breaking change though.
If this is not ok, than the docs should be updated instead.
Checklist

[x] Tests updated (or not required).
[ ] Documentation updated (or not required).

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

The changes in this PR are not entirely correct. In JavaScript, the regex.test method converts the argument to a string, so regex.test(undefined) behaves the same as regex.test('undefined').

Ah, indeed. Didn't notice because I was using to regex to exclude stuff. It would be better to just mention it in the docs then


Allow using arrays from %azure.execute

This PR allows for arrays to be sent as arguments to the %azure.execute magic command, and to the qsharp.azure.execute function by extension. This PR also adds a new test to prevent regression, and updates to QDK 0.15 packages.

/azp run

/azp run

It looks like the build failure is related to the new IQuota interface; @swernli and @ricardo-espinoza for awareness.

It looks like the build failure is related to the new IQuota interface; @swernli and @ricardo-espinoza for awareness.

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

Fixes #401.

Fixes #401.

@cgranade quick question while I'm reviewing - I'm seeing the addition of a lot of loggers into the code. Was this part of the effort to debug the problem? If so, could you add some quick notes about it either in the README or this PR for posterity?

@cgranade quick question while I'm reviewing - I'm seeing the addition of a lot of loggers into the code. Was this part of the effort to debug the problem? If so, could you add some quick notes about it either in the README or this PR for posterity?

@cgranade quick question while I'm reviewing - I'm seeing the addition of a lot of loggers into the code. Was this part of the effort to debug the problem? If so, could you add some quick notes about it either in the README or this PR for posterity?

Both this and another issue @swernli was dealing with were complicated by that magic commands in e2e tests did not log any errors, but failed with blank error messages. That's somewhat difficult to avoid due to the design of jupyter nbconvert, but as a mitigation, this PR at least logs to the standard logging mechanism that was already in IQ#. The only change needed was to pass those loggers through magic commands, and to allow test harnesses to read from those loggers.

@cgranade quick question while I'm reviewing - I'm seeing the addition of a lot of loggers into the code. Was this part of the effort to debug the problem? If so, could you add some quick notes about it either in the README or this PR for posterity?

Both this and another issue @swernli was dealing with were complicated by that magic commands in e2e tests did not log any errors, but failed with blank error messages. That's somewhat difficult to avoid due to the design of jupyter nbconvert, but as a mitigation, this PR at least logs to the standard logging mechanism that was already in IQ#. The only change needed was to pass those loggers through magic commands, and to allow test harnesses to read from those loggers.

Force merging to restore e2e build.

Force merging to restore e2e build.


The start_yaw control parameter

start_yaw allows me to rotate the image in only one dimension. Is it possible to rotate it in two dimensions, for example rotate 180 degrees horizontally and then rotate 90 degrees vertically ?
Thanks.

Not with yaw. What is your use case?
On Sun, Apr 17, 2016 at 7:19 AM prasannjeet<EMAIL_ADDRESS>wrote:

start_yaw allows me to rotate the image in only one dimension. Is it
possible to rotate it in two dimensions, for example rotate 180 degrees
horizontally and then rotate 90 degrees vertically ?
Thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/google/vrview/issues/4

well, I need to fix the orientation of photospheres I have before I can put it online. start_yaw allows me to do that in one dimension.
Now unless the photo is taken strictly vertical, there are chances that you need to roll your photosphere to fix the orientation. How can that be done? I hope this made sense!

As it stands you'll need to correct for that roll in the image itself, or
modify VR View directly.
On Thu, Jun 16, 2016 at 8:56 AM prasannjeet<EMAIL_ADDRESS>wrote:

well, I need to fix the orientation of photospheres I have before I can
put it online. start_yaw allows me to do that in one dimension.
Now unless the photo is taken strictly vertical, there are chances that
you need to roll your photosphere to fix the orientation. How can that be
done? I hope this made sense!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/vrview/issues/4#issuecomment-226530069, or mute
the thread
https://github.com/notifications/unsubscribe/AAQ8gPC7Kl_HBQwMwE1iLp-iJBAMzIcJks5qMXJEgaJpZM4IJLD1
.


python310Packages.pook: 1.1.0 -> 1.1.1

Diff: https://github.com/h2non/pook/compare/refs/tags/v1.1.0...v1.1.1
Changelog: https://github.com/h2non/pook/blob/v1.1.1/History.rst
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 210931 run on x86_64-linux 1

2 packages marked as broken and skipped:

python310Packages.pytest-ansible
python311Packages.pytest-ansible

24 packages failed to build:

ansible (ansible_2_14 ,python310Packages.ansible-core)
ansible-later (python310Packages.ansible-later)
ansible-lint (python310Packages.ansible-lint)
ansible_2_12
ansible_2_13
kargo
python310Packages.ansible
python310Packages.ansible-compat
python310Packages.ansible-kernel
python310Packages.ansible-runner
ttp (python310Packages.ttp)
python311Packages.ansible
python311Packages.ansible-compat
python311Packages.ansible-core
python311Packages.ansible-kernel
python311Packages.ansible-later
python311Packages.ansible-lint
python311Packages.ansible-runner
python311Packages.geoip2
python311Packages.mocket
python311Packages.parsedmarc
python311Packages.pook
python311Packages.sopel
python311Packages.ttp

5 packages built:

parsedmarc (python310Packages.parsedmarc)
python310Packages.geoip2
python310Packages.mocket
python310Packages.pook
python310Packages.sopel

@ofborg build ansible

test failure might be not reproducible. Let's see.

Result of nixpkgs-review pr 210931 run on x86_64-linux 1

2 packages marked as broken and skipped:

python310Packages.pytest-ansible
python311Packages.pytest-ansible

12 packages failed to build:

python311Packages.ansible
python311Packages.ansible-compat
python311Packages.ansible-core
python311Packages.ansible-kernel
python311Packages.ansible-later
python311Packages.ansible-lint
python311Packages.ansible-runner
python311Packages.geoip2
python311Packages.mocket
python311Packages.parsedmarc
python311Packages.sopel
python311Packages.ttp

17 packages built:

ansible (ansible_2_14 ,python310Packages.ansible-core)
ansible-later (python310Packages.ansible-later)
ansible-lint (python310Packages.ansible-lint)
ansible_2_12
ansible_2_13
kargo
parsedmarc (python310Packages.parsedmarc)
python310Packages.ansible
python310Packages.ansible-compat
python310Packages.ansible-kernel
python310Packages.ansible-runner
python310Packages.geoip2
python310Packages.mocket
python310Packages.pook
python310Packages.sopel
ttp (python310Packages.ttp)
python311Packages.pook

#211995 will help to reduce the amount of failures.