Consul module fails to read the aws provider credentials

My configuration file looks like below
provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region     = "eu-west-2"
  version = "~> 1.10"
}

module "consul" {
  source = "hashicorp/consul/aws"
  version = "0.1.2"
  aws_region  = "eu-west-2"
  num_servers = "3"
}

When i run #terraform.exe plan I get the following error on Windows. Note i entered the aws_key and secret_key as part of command line input.

Error: Error refreshing state: 1 error(s) occurred:

module.consul.provider.aws: No valid credential sources found for AWS Provider.
Please see https://terraform.io/docs/providers/aws/index.html for more information on
providing credentials for the AWS Provider

I dont know how to fix this. So far i have tried #terraform.exe init -upgrade to ensure the aws provider and consul module provider are current.

Hm, I believe this is due to some confusion between "modules" and "examples" in the Terraform Registry. The registry requires that each repo has Terraform code in the root, but for complicated modules such as Consul, the actual implementation consists of several submodules in the modules folder. The code in the root is actually example code meant to be cloned and deployed directly, rather than used with the module keyword, which is why it has its own provider block and isn't using yours.
@KFishner What are your thoughts on what to do about this? If we remove the provider block from the root example, it won't work as a standalone example. If we keep the provider block, it doesn't work with the module keyword. All of this weirdness goes away if we just allow complicated modules to not have Terraform code in the root and instead maintain a clear separation between examples in the examples folder, which should be deployed directly and have their own provider blocks, and modules in the modules folder, which are meant to be deployed using the module keyword.

Is there a workaround till this is fixed ?

Copy the code in the root example: https://github.com/hashicorp/terraform-aws-vault/blob/master/main.tf.
Follow the instructions in the comments of the code.
Run terraform init
Run terraform apply

Thank you.

Hey @brikis98, I think this is more of an issue caused by the changes to provider configuration in 0.11 (which as a reminder were to resolve mostly inconsistent relationships between provider configuration and modules). I imagine you know most of the information below but being verbose for readers.
Prior to 0.11, we would've merged those configurations, so both cases you describe would've worked: if you ran it directly or if you configured a provider in a parent consuming this as a module.
In 0.11, a major change we introduced was a consistent approach to provider configuration for modules. A backwards breaking change that is part of this is that provider configurations are never merged anymore. So by the root Terraform configs in this module setting provider, it is overriding the default "aws" provider in the root. For full details, see: https://www.terraform.io/upgrade-guides/0-11.html#interactions-between-providers-and-modules
I believe an easy fix for this would be to up the major version of the module and remove the provider block in the root and remove the aws_region variable completely and switch to using the aws_region data source for resources that may need the region.
The behavior would then be:
1.) Running via the registry instructions (as the poster of this issue did): Any provider configuration, as was done here, would work correctly. They can set the region and the module would load it properly.
2.) Running directly via init -from-module or cloning this repo: Terraform would by default prompt for configuration (via CLI input). Users could set env vars, or use any other form of AWS auth to authenticate.
Both cases would then work, if I'm not mistaken.

@mitchellh Thanks for the explanation with the provider changes. It seems a bummer that you now must write code, or at least set env vars, just to try out the example code. Before, a terraform init and apply would've been enough.
We've discussed it before, but I still find the root folder contain a "standalone example" is confusing many users, who expect it to be a "reusable module." This provider issue is but one minor example of that. The main issue is that, while elegant, the suggested terraform init <repo>/<provider>/<module> or source = <repo>/<provider>/<module> usage sets the expectation that you're using a production-ready module, when for non-trivial modules, it's typically just an example that's optimized for learning and testing.
For example, the Vault, Consul, and Nomad root "modules", to make learning and testing easy, allow connections from all ports, deploy into the default VPC, don't encrypt certs, etc. We've seen that users are surprised by this time and again and often end up with the impression that the code in the Registry is just for learning and couldn't possibly be used in a real production setting.
It just seems more sane to tell users to run terraform init <repo>/<provider>/<module>/examples/<example-name> (e.g., hashicorp/aws/vault/examples/private-cluster) when they want to try out an example and to use source = <repo>/<provider>/<module>/modules/<module-name> (e.g., source = hashicorp/aws/vault/modules/vault-elb) when they want to use a production-ready, reusable module in their code. It avoids all the confusion about examples vs modules, provider configurations, and so on.

You don't need to write code to try it since Terraform should prompt you. I just tried it locally (with the recommendations I noted in my prior comment) and was able to start spinning up clusters without any code at all, I just had to answer the region which was prompted on terraform apply.
Even in the prior unmodified version with TF 0.10.x, I don't see how I could've avoided code or env vars since the auth had to come from somewhere. In the new usage, I suppose you do have to at least tell Terraform the region though (but again, that can come from input via the CLI).
I understand your opinion on the root folder, but I still believe optimizing for repo/provider/module as a default UX is strictly less mental overhead than teaching a new user subfolders (either examples or submodules). And in a few months of private module registry usage (via Terraform Enterprise), simpler reusable modules where submodules are not necessary is the norm, and big complex modules are rarer. That sort of makes sense in a customer environment too where the modules are highly opinionated as designed (versus the public registry where they're instead trying to be overly generic).
Your last paragraph though is exactly right and the current standard module model doesn't invalidate that. That's completely usable today and a reasonable thing to do for a complex module such as Vault, Nomad, Consul. The root folder in that case is just there to do something since users would expect it from simpler modules. And I think as we discussed before the most reasonable thing in my mind is just a highly opinionated example for a quick out-of-box experience, but very likely not production ready.

You don't need to write code to try it since Terraform should prompt you.

Sure, if you don't mind typing in the same thing over and over again :)

And in a few months of private module registry usage (via Terraform Enterprise), simpler reusable modules where submodules are not necessary is the norm, and big complex modules are rarer.

Are you optimizing the registry for private usage or public usage? Because with public usage, I'm guessing what most users are looking for are solutions for the complicated modules they can't do themselves: Vault, VPCs, Kafka, K8, etc.

Sure, if you don't mind typing in the same thing over and over again :)

Of course, I'm just thinking in an "example" or non-production use case. You can get up and running with no code, then write code after if you want to keep it around or terraform destroy (enter the same value again) and destroy it.
For production usage, you'll have to write code but I assume you'll be writing code no matter what so I don't think that should be a usability detractor.

Are you optimizing the registry for private usage or public usage?

Both, we dedicated a few months to building out the private registry but for the past couple months have worked almost exclusively on the public one (and have shipped big improvements like exposing both examples and submodules, more on the way!).
We don't want a fragmented use case. The standard module structure recommended supports both cases of simple and complex module. The complex module can easily satisfy the root requirement by technically having a blank TF file or a TF file that has an output that explains to look elsewhere, but I think a better UX is an opinionated example. It provides a uniform experience: the root will always do something. We never say that the root is always the production-ready module, we were careful when crafting docs and marketing to never say that. It can be, but its best to treat it as a starting off point before digging deeper (whether it has submodules or not).
If we instead said "there is no root, you must use submodules", then the complexity for simple modules is raised significantly for the benefit of complex modules. I think that cost is higher than the alternative, which is a relatively low ask (just call your submodules in an opinionated fashion, OR just put a blank TF file if you really don't want to).
It was a simple exercise to come to this conclusion last year: I wrote down the steps to publish and consume both a simple and complex module (matrix of 4). The spec we chose has the simplest workflows if I recall in every case (or all except 1, but only off by one step on one...).
We've also been monitoring feedback from trainings and customers and we've never heard a complaint about it. We've heard multiple times how "cool" it is that they can spin up complicated clusters by just copying and pasting the module usage text from the public registry. They probably won't use those complicated clusters in production. 😄 But that's the point!
And I want to note that your point about submodules has been extremely well received here. Prior to shipping the registry we made sure the structure documented submodules and we've always parsed them. And just a couple weeks ago, we deployed a new change to the public registry to expose them in the UI, too! They aren't second class citizens by any means.
Hope that helps. If you have any recommendations for improvements I'm happy to hear them, but the one thing we probably won't do at this point is get rid of the root config requirement.

Adding to the above, if you haven't seen, check out the new submodule UI: https://registry.terraform.io/modules/hashicorp/vault/aws/0.3.0/submodules/vault-elb
We have improvements planned including improving the usage instructions for submodules and examples to be even easier. But we wanted to at least expose the data we already had in a user-consumable way. We also include "internal" submodules but they're hidden behind a dropdown, see the submodules dropdown here: https://registry.terraform.io/modules/terraform-aws-modules/security-group/aws/1.15.0

It was a simple exercise to come to this conclusion last year: I wrote down the steps to publish and consume both a simple and complex module (matrix of 4). The spec we chose has the simplest workflows if I recall in every case (or all except 1, but only off by one step on one...).

Number of steps != simple workflow. Clear, consistent, untangled mental model = simple workflow. (Rich Hickey's Simple Made Easy does a great job of distinguishing between these).

we've never heard a complaint about it

We've run into issues with this fairly regularly. E.g., here's one in the Vault repo. I also get questions about this frequently at meetups, talks, and when chatting with customers: e.g., "I tried the Vault module, but it spun up Consul, and I already have a Consul cluster, so I can't really use it..." or "I can't use the Nomad module because it deploys in the default VPC and at my company, everything has to go in our custom VPC..."

We've also been monitoring feedback from trainings

That may be the issue right there. I'm guessing most people who use the registries don't have official training. They just find it from Google, try it out, see it doesn't work immediately, and move on.

And I want to note that your point about submodules has been extremely well received here. Prior to shipping the registry we made sure the structure documented submodules and we've always parsed them. And just a couple weeks ago, we deployed a new change to the public registry to expose them in the UI, too! They aren't second class citizens by any means.

I'm very grateful for that. Your team responds very well to feedback, which is why I'm chancing some more here :)

Adding to the above, if you haven't seen, check out the new submodule UI: https://registry.terraform.io/modules/hashicorp/vault/aws/0.3.0/submodules/vault-elb

👍
Huge improvement. Same with examples. It's made it easier to explain away the confusion, but a simpler mental model might've avoided the confusion in the first place :)

If you have any recommendations for improvements I'm happy to hear them, but the one thing we probably won't do at this point is get rid of the root config requirement.

I share what I can and appreciate the parts you've taken into account.

I suppose we have to agree to disagree on the mental model. I think its simple: root module will always do something, more flexibility comes in submodules if they exist. But that 🚢 is currently sailing. If this ends up being wrong, we can reassess but I don't agree for now.
I hope that the confusion is cleared up by the additional UI elements. They can now be linked from READMEs and such to to better explain to look in certain places. If you have suggestions on how to improve the UI further let us know and we'll take that into account for sure!

Our mental model is that modules go under /modules, examples under /examples, and tests under /tests. I'm not sure it can get any simpler or clearer than that. The structure is consistent (no corner cases or exceptions), extensible (e.g., what happens if a "simple" module in the root becomes complex?), encourages good habits for module creators (you should have examples and tests!), and the "overhead" (if you can call it that?) is negligible.
That said, I understand your perspective. We will continue contributing the to the registry and share more feedback when we can :)

Hi. I'm experiencing the same problem that @SahanaPrabhakar reported. I'm simply following along with the getting started guide here. Maybe the problem is with the documentation. My config looks like this:
`provider "aws" {
access_key  = "${ var.access_key }"
secret_key  = "${ var.secret_key }"
region      = "us-east-1"
}
module "consul" {
source = "hashicorp/consul/aws"
aws_region  = "us-east-1" # should match provider region
num_servers = "3"
}`

@kevinsapp Sorry, this one fell off my radar. The workaround is listed here: https://github.com/hashicorp/terraform-aws-consul/issues/49#issuecomment-368970758. I'm putting together a proper fix in #78.

@mitchellh I just submitted the fix for this in #65, following your comment in https://github.com/hashicorp/terraform-aws-consul/issues/49#issuecomment-369372005. It works OK for this Consul example, but that's only because the entire example uses a single AWS region.
I have another module I'll be adding to the registry soon that has a multi-region example, to demonstrate cross-region replication. To make that work, the example has the following at the top:
provider "aws" {
  alias  = "primary"
  region = "${var.aws_region_primary}"
}

provider "aws" {
  alias  = "replica"
  region = "${var.aws_region_replica}"
}

And then all the resources throughout the example use one provider or the other. If I have to remove the provider blocks to work with the instructions in the Registry, then how do I get this example to work?

@mitchellh Could you share any thoughts on the previous comment? I'd like to add a new module to the Registry, but it's not clear how to do that for examples that use more than one provider (for multiple regions).


Certs async

Can one of the admins verify this patch?

I've opened a new PR with the commit history squashed because there are so many commits here: https://github.com/Azure/azure-sdk-for-python/pull/7076


Add environment variable support for Maven Toolchains parsing

Fixes #24596
Context
There is, as annotated by an inline comment, one thing that does not make sense. I was able to reproducible fail the negative test (no toolchain provided if env variable could not be resolved) unless this "unnecessary" null check is done.
I am not entirely sure whether this deserves mention in the toolchains documentation but will add an item if you want me to.
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation

Hi @Okeanos ,
Thank you for your proposed solution. We ended up using the original issue as an onboarding one for an intern and so collaborated on a fix in #25545.
If you take a look there, you will see that your fix was too simple as it did not account of a substitution with surrounding text or multiple substitutions.

Hi @ljacomet thanks for providing an update (and ultimately fixing the issue)!
I did the bare minimum possible (for my use case) for the initial PR to get a 90% solution out of the way but agree that handling these additional cases is very nice to have so thanks for including that. A review pointing that out + maybe a message saying you'll have an intern working on improving this would have been welcome instead of letting my PR "languish" and giving an update post-fact but overall I am just happy that this has been addressed at all :)


psum_scatter does not allow scatter_dimension to be negative

Description
In jax.lax.psum_scatter, I tried to use -1 as scatter_dimension to indicate that the last dimension should be used. However, this triggers an error: expects scatter_dimension >= 0. Negative indices are normally supported for axes in JAX and Python in general.
System info (python version, jaxlib version, accelerator, etc.)
N/A

Hi @jewillco
Thanks for reporting. There's a related issue reported under #20125  that's still open. It might be helpful to reference it.

Duplicate of #20125

Duplicate of #20125


There is no reactor running, must be called from the context of a Tokio 0.2.x runtime.

Can hyper be used only under Tokio 0.2?The tokio 1.4.0's new feature is used in my service, so I cannot use hyper at the same time?

You are using an out of date version of Hyper.


[ai-form-recognizer] Refactor DocumentModel

Packages impacted by this PR
@azure/ai-form-recognizer
Issues associated with this PR
Closes #20338
Describe the problem that is addressed by this PR
This PR does a handful of related things:
At a very high level, it replaces a lot of complex compile-time abstraction with a simple code generator in bin/ that generates much saner concrete types.

Removes the existing, deprecated PrebuiltModels object.
Removes the deprecated beginReadDocument, beginExtractGeneralDocument, and beginExtractLayout methods.
Adds a beginAnalyzeDocumentFromUrl method, separating URL-based and body-based analysis into two methods.
Refactors the generic, DocumentModel based analysis methods

Unhides the transformResult function. It is no longer behind an internal symbol, but is simply named transformResult.
Changes the transformation function to operator on convenience-layer results instead of generated-layer results.
Makes the analysis method fail with a helpful error message if the client is using a different API version than the input model.
Removes the type-inference based ReifyPrebuiltSchema type constructors (this cleans up the APi surface tremendously)
Introduces an internal code generator that creates high-quality, documented interfaces for prebuilt models (these are now included as samples rather than in the API surface).

Modifies test scripts to use dev-tool for transpilation rather than esm/ts-node. This gives tests the same bells and whistles as samples (such as being able to import from the host package by name.
Re-recorded tests (not sure if this is all that necessary).

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
This design gives us the most flexibility going forward. We don't assume any of the prebuilt models as API surface, and we provide a very simple abstraction that allows a user to insert arbitrary transformations into the analysis pipeline on the client side, encapsulated into a data structure with request information (API version, model ID).
Since we have provided strongly-typed functionality since the first beta of 4.0.0, this design allows us to continue supporting that scenario.
Are there test cases added in this PR? (If not, why?)
Existing test cases are reworked to use the new prebuilt data structures.
Remaining TODOs:

[ ] Rework samples to use the new sample prebuilts (currently they are just deleted)
[ ] Update CHANGELOG.
[ ] Update README to remove references to PrebuiltModels and point to the samples instead.
[ ] Update MIGRATION to remove references to PrebuiltModels and point to the samples instead.
[ ] Rebase this PR onto main, seems the history is a little complicated.

CC @joheredi & @jeremymeng for API review (sorry the api.md diff is so large, but we're getting rid of a lot of unnecessary stuff). CC @xirzec : this PR removes the deprecated API surface we've talked about before.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-form-recognizer


Release/2.7.3

Bugfix release to fix UDA client with SSL authentication enabled.

Can you add a fix for this issue https://github.com/ukaea/UDA/issues/8? (it was previously flagged for 2.7.2 but was not included there)

On Rocky8.5 it looks like the pkgconfig name needs to be "libtirpc" not "tirpc" for the plugins to build with this server version.

Can you add a fix for this issue #8? (it was previously flagged for 2.7.2 but was not included there)

This should be included in the PR now.


Users should be able to rename metadata

Since this is only a metadata update, it should be fast and efficient. Change the series name from one thing to another. Maybe:
rename series "foo" to "bar"

Changing column name:
modify table t1 rename column c1 to c2

Or database:
rename database d1 to d2

Or something like that.

+1

+1

+1

+1

+1

+100
Really a must have. Also been asked before: What is the manual workaround in the meantime?

Should it be:
ALTER TABLE t1 MODIFY c1 to c2

to stay with standard sql convention?

@fxstein Currently I merge the two series in a query select .. from A merge B where .. where A was renamed to B or the other way around.
@corylanou sounds good

@jhausser Thanks for the reply!
I fully understand the SELECT query part but that is not really what I am asking for.  I need to take the two timeseries and permanently merge it into a new one. Otherwise you have to modify all application logic that sits on top of that data. e.g. Grafana dashboards would all have to be rewritten with manual queries that perform the merge for every graph out of that series.
I need to be able to take the select .... merge .... and persist the result into a new or existing series. INSERT SELECT for most databases.
@corylanou ALTER TABLE would be an option, I would even take INSERT SELECT to create a new series, RENAME TABLE would also be an option.

@pauldix -- if a database is renamed, will writes to the older database then start failing (no database exists)? I'm talking about 0.9. We're not talking about any kind of symlink-style functionality, right?

Since the examples @pauldix mentioned in the beginning are probably out of date now, I'm proposing the following
RENAME DATABASE d1 TO d2

RENAME MEASUREMENT "db"."rp"."m1" TO "db"."rp"."m2"

ALTER MEASUREMENT "db"."rp"."m1" RENAME COLUMN "c1" to "c2"

Perhaps these should be broken into separate stories? I think these are in increasing order of importance. Any strong feelings?

+1 It would be great to rename series and other metadata. And not symlink-style functionality.

@toddboom Shouldn't these be called "rename series" and "alter series" instead? I don't think the terms series, table and measurement should be used interchangeably througout influxdb but one should be chosen and then used everywhere consistently.

@dennisjac in 0.9 the Measurement is the string that appears in the SELECT clause. The tags, which define the series within the measurement, appear in the WHERE clause. Therefore this is renaming the measurement, not the series. A series doesn't really have a name, it's just the unique combination of a measurement and a tag set.

It should also be noted that series can be synthetic as well. For instance if you write this data:
cpu,region=uswest,host=serverA value=23.2
cpu,region=useast,host=serverB value=45.9
cpu,region=useast,host=serverB value=33.1

Under the covers that creates three unique series in the data store. However, if you issue this query:
select mean(value) from cpu
where time > now() - 4h
group by region, time(5m)

You'll get two series back, whose keys are cpu,region=uswest and cpu,region=useast. Note that those two series don't explicitly exist under the hood in the database.
Anyway, this is a long way of saying that there's no idea of renaming a series since they are created in many cases on the fly. You either rename measurements, or maybe you rename tag keys.
It should also be noted that given the new underlying structure of how InfluxDB stores data, this would be an incredibly expensive operation. We'll likely punt on this one for a while (post 0.9.1).

decomposed into relevant issues #4154, #4155, #4156, #4157

So after more than 6 years nothing of those splitted feature requests is implemented (one has been auto-closed without a solution/an implementation) - really? I was searching for HOURS to find a way to rename a series. In the end it's still impossible. Unbelievable. This lowers my personal amount of trust in the whole InfluxDB tbh.


Barbs: Z scale origin incorrect

Reproduce:

Open Katrina
Add/enable a barb renderer
Scale the Z axis by 100

Still does not work for 2d renderers

Related to #2755 and the other twoDdata height issues that have been reported.


bug: Installtion steps on the website are not formatted correctly

Checklist:

[X] I've searched for similar issues and couldn't find anything matching
[X] I've included steps to reproduce the bug.
[ ] I've included the version of Kubernetes and k8sgpt.

Subject of the issue

Installtion steps on the website are not formatted correctly and look messed up

Additional context / screenshots

Hi @harshit-mehtaa I am not quite seeing where this is as this is the screenshot from the docs page that you linked above

Could you please provide the link?

@AnaisUrlichs in the earlier versions this was the issue, but doesn't seem to be anymore.
@harshit-mehtaa can you please re-confirm the issue?
I checked it on safari and chrome browser myself :)

Looks like documentation is updated so the issue is resolved
We are good to close the issue


Add Moniker to quick-pick-menu-controller.ts

We have recently added a Docs: Moniker option to the F1 command pallet. However, it is missing in the markdown quick pick that is accessible using Alt + M. We need to add the Moniker option to the markdown quick pick options.
We should use Moniker as the quick pick option title, and the icon should be octicon-project https://octicons.github.com/icon/project/ using $(project)

@JohnTheFarmer


Support for new Rackspace instance types and Cloud Block Storage boot volumes

It looks like Rackspace has changed their cloud server types, adding "Compute" and "Memory" flavors and replacing the performance tiers with "General Purpose" and "I/O". The newer flavors only support using a remote cloud block device as the boot volume. As a result, knife rackspace can't create these, since it seems the API call to create the server now requires the UUID of a cloud block storage volume prepared with an image.
For instance, when I attempt to pass 'compute1-4' as a flavor, I get this error:
ERROR: Fog::Compute::RackspaceV2::ServiceError: [HTTP 403 | req-12b43584-bd39-4a85-9115-4bd42b9ee8f1] Policy doesn't allow compute_flavor:create:image_backed to be performed.
This could also be an issue with Fog, but I'm not entirely sure. It would appear that support was added to Fog for the block_device_mapping attribute on Oct 1st: https://github.com/fog/fog/blob/master/lib/fog/rackspace/requests/compute_v2/create_server.rb

@tdooner Looks like your PR was denied by the CLA bot. I'd love to see these changes merged.

Ping. Any news on this?

#95 appears to be good now, passing the CLA check. I'd love to see it merged! :+1:

Bump, would love to have this!

Just a comment, here:
Device Mapping is still invalid and there needs to be an indication that boot-volume-size is now required (or a workable default plugged in).

@Paladin we should probably open this as a new issue, since this issue is a year old and closed. Could you open an issue and show us the command you're trying to run?


TypeError: Cannot cast ufunc multiply output from dtype('float64') to dtype('int64') with casting rule 'same_kind'

I get a type error when trying to generate image from random noise in the ipython notebook. Numpy seems to have a problem with upcasting the datatypes.
TypeError                                 Traceback (most recent call last)
<ipython-input-48-b06014ec4265> in <module>()
      1 # Create some noise, centered at gray
      2 img_noise = inception.preprocess(
----> 3     (np.random.randint(100, 150, size=(224, 224, 3))))[np.newaxis]
      4 print(img_noise.min(), img_noise.max())

/home/clu/Python/CADL-master/session-4/libs/inception.py in preprocess(img, crop, resize, dsize)
     81 def preprocess(img, crop=True, resize=True, dsize=(299, 299)):
     82     if img.dtype != np.uint8:
---> 83         img *= 255
     84
     85     if crop:
```
`

Will try to include better type checking.  Can you use np.random.randint(100, 150, size=(224, 224, 3), dtype=np.uint8) for now?

Okay, thanks for the quick fix.


build: cleanup cocoapods pods to improve deployment speed

Closes: https://github.com/customerio/issues/issues/8616
There is a chance that these changes will not work. Unfortunately, the only way to test is to try and push pods to cocoapods.
My plan is to get this PR merged and attempt to use the code to make the next v2 deployment of our SDK. If I find that the deployment fails, I will revert these changes that I made and re-do the deployment.
Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

[ ] Assign members of your team to review the pull request.
[ ] Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
[ ] Wait until the pull request has been reviewed and approved by a teammate
[ ] After pull request is approved, and you determine it's ready add the label "Ready to merge" to the pull request. A bot will squash and merge the pull request for you after the label is added.

Going to wait on this PR. It might not be possible with the current implementation. When I run pod spec lint --allow-warnings CustomerIO.podspec on this code, I get build errors:
 -> CustomerIO (1.2.6)
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/Common`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/Tracking`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPush`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPushAPN`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPushFCM`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingInApp`).
    - ERROR | [iOS] unknown: Encountered an unknown error (The `CustomerIO` pod failed to validate due to 6 errors:
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/Common`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/Tracking`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPush`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPushAPN`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingPushFCM`).
    - ERROR | [iOS] attributes: Can't set `module_name` attribute for subspecs (in `CustomerIO/MessagingInApp`).

) during validation.

I propose:

[ ] Add this lint check to the CI server on PRs to make sure that we don't break our cocoapods configuration.
[ ] See if there is a way to fix the errors above.

Closing this PR for now. In the mean time, I have done these changes to improve this process a little bit:

Added --synchronous when pushing to try and speed up the wait time for pushing subspecs
Added lint check to test podspecs to prevent potential issues merging PRs like this one would have caused.


feature: too many cooks (messages)

Currently you are blasted with all the messages from for ever when joining a channel.  It would be nice to be able to page and only see the latest sub set when joining. This could be a great feature to include in Friends golden platinum edition, or potential keep in a roadmap to pitch to investors.

ha! I think there's an open issue to only show the last 500 or so on join (with the intent that the rest are searchable)

there�s no reason why all the messages can�t be stored, but only a subset are presented.
Search for old messages seems obtuse� 500 messages seems overwhelming.

doesn't have to be 500 :) ideally it will work like irccloud/slack/hipchat; you join a channel, see some context (a not-terrible amount of previous messages), and are able to search the history that's replicated to you from peers

+1 @beaugunderson I think latest history with option to load more incrementally all the way back would work great. Ideally there would be an indicator of past mentions/messages you haven't read too (also like irccloud).

I think a setting for how many are displayed makes the most sense at the moment

I believe @mafintosh is working on a DB change so that messages will be sorted by date and we will have total message counts per-room. This will make it easier to change the UI to paginate arbitrarily forwards and backwards in time. Until then I would hesitate to do any major work on this

they were good ideas myles

to be fair to myles I think friends can be safely said to be abandonware, and i bet some folks don't like having zillions of open issues under https://github.com/issues

I was just cleaning house... I left my other issues on here open to gauge response.. we can reopen if people like the issue


Task: return pending keys ids from GET /api/v1/metadata/sign together with metadata

What is the task about?
This task is related to metadata update ceremony at the RSTUF CLI.
One of the key steps there is the authorization part.
Currently, when we do metadata update with full signing, we expect at least threshold number of keys from current root to be loaded.
Now, we cannot do the same as we have allowed our maintainers to initiate bootstrap with DAS.
My suggestion is to follow these steps for metadata DAS:

we load only 1 key from current root to start DAS metadata update
we finish metadata update
we store the new root as UNTRUSTED until
a) there are current_root_threshold amount of keys loaded and signed the new root version
b) there are new_root_threshold amount of keys loaded and signed the new root version
maintainers can sign new root with POST /api/v1/metadata/sign
when requirements 3.a) and 3.b) are met, then initiate a root rotation.

These steps are already implemented at the RSTUF worker by pr:
https://github.com/repository-service-tuf/repository-service-tuf-worker/pull/355.
What I am worried is how our users will understand that they need to call POST /api/v1/metadata/sign with keys not exclusively coming from the new root version.
Imagine this situaiton:

DAS bootstrap ceremony was completed with threshold of 2 and 2 keys defined for root overall.
DAS metadata update is completed and sent to RSTUF API

1 key coming from current root was loaded
new root has threshold of 3
new root has in total 5 keys (2 keys coming from current root and 3 new keys)

New root is stored as UNTRUSTED
Two maintainers call POST /api/v1/metadata/sign with keys coming from NEW ROOT.
And here is the misunderstanding that happens

maintainers think the threshold of 3 was reached and no other keys are needed (1 loaded on step 2 and 2 on step 5)
what actually happens is that root is not considered as trusted as only requirement 3.b) is achieved and not 3.a)

A solution for this could be to make GET /api/v1/metadata/sign return not only metadata requiring signing, but the pending keyids together with root version they come from.
Example:
{
  "pending_keys": {
     {
         "keyid": "1cebe343e35f0213f6136758e6c3a8f8e1f9eeb7e47a07d5cb336462ed31dcb7"
         "root_version": 1,
     },
     {
         "keyid": "800dfb5a1982b82b7893e58035e19f414f553fc08cbb1130cfbae302a7b7fee5"
         "root_version": 2,
     },
   }
  "metadata": {
    "root": {
     ...
      }
}

References

https://github.com/repository-service-tuf/repository-service-tuf/issues/327

Code of Conduct

[X] I agree to follow this project's Code of Conduct

After a conversation with @kairoaraujo and @enyinna1234 we came up to the conclusion that those changes are not required here, but can be directly done in the CLI as it has access to the current root and has TUF installed.


Property 'href' does not exist on SVGUseElement

TypeScript Version:  2.2.2
Code
In React:
Property 'href' does not exist on type 'SVGProps<SVGUseElement>'.

Expected behavior:
The MDN SVGUseElement does not include the href property but I believe it is required to actually 'use' it. If you look here xlink:href was used in the example. However, that has now been deprecated in SVG 2 to drop the xlink namespace, see here.
Actual behavior:
Allow href property

Where is SVGProps defined?

This comes from a definition file
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/354cec620daccfa0ad167ba046651fb5fef69e8a/types/react/index.d.ts
React does not list href as a supported SVG property.
https://facebook.github.io/react/docs/dom-elements.html
See also
http://stackoverflow.com/questions/26815738/svg-use-tag-and-reactjs
It looks like you want xlinkHref instead


Support tracking non-interaction event

Add support to track non-interaction event with custom dimension.
Fix type definition.

Cancelled


[Flaky test] MultipleRequests

Error message
System.IndexOutOfRangeException : Index was outside the bounds of the array.

Stack trace
   at System.Collections.Generic.List`1.Add(T item)
   at Azure.Core.TestFramework.MockTransport.<ProcessCore>d__17.MoveNext() in D:\a\1\s\sdk\core\Azure.Core.TestFramework\src\MockTransport.cs:line 63
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Core.TestFramework.MockTransport.<ProcessAsync>d__16.MoveNext() in D:\a\1\s\sdk\core\Azure.Core.TestFramework\src\MockTransport.cs:line 58
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Core.Pipeline.RequestActivityPolicy.<ProcessNextAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at Azure.Core.Pipeline.RequestActivityPolicy.<ProcessAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Core.Pipeline.ResponseBodyPolicy.<ProcessAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Core.Pipeline.ResponseBodyPolicy.<ProcessAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at Azure.Core.Pipeline.LoggingPolicy.<ProcessAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Core.Pipeline.LoggingPolicy.<ProcessAsync>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.<ProcessCoreAsync>d__8.MoveNext() in D:\a\1\s\sdk\keyvault\Azure.Security.KeyVault.Shared\src\ChallengeBasedAuthenticationPolicy.cs:line 93
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at Azure.Core.Pipeline.RetryPolicy.<ProcessAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Azure.Core.Pipeline.RetryPolicy.<ProcessAsync>d__11.MoveNext()
--- End of stack trace from previous location where

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=445640&view=ms.vss-test-web.build-test-results-tab&runId=11739456&resultId=105558&paneView=debug
cc @heaths

Specifically,
   at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.<ProcessCoreAsync>d__8.MoveNext() in D:\a\1\s\sdk\keyvault\Azure.Security.KeyVault.Shared\src\ChallengeBasedAuthenticationPolicy.cs:line 93

As to why it's throwing an IndexOutOfRangeException in List<T>.Add may indicate a concurrency issue when the internal array is being expanded. The ChallengeBasedAuthenticationPolicy attempts to balance throughput and caching, opting to re-authorize requests on concurrent threads. Write access to the Requests list may need to be synchronized to handle this or any other concurrent scenario.

Haven't seen this in a very long time.


Update README.md

Update to test GitHub PR workflow of copybara. Note to approvers: Please make sure when approving that you re-include the scraped 'internal only' documentation.

Will resubmit


strapi image created under root user

Hello, I am sorry if this is not a problem, it could be me being very expert on strapi (I am evaluating it for a project I have to start) and Docker ( i have used it only a couple of times).
When I run docker-compose up command everything goes well and the environment get set up and run fine my only problem is that the strapi app folder and the db folder are created under the root ownership making it impossible to be opened on an IDE such us Visual studio code in order to modify the project (e.g it is impossible to install a new file uploader provider if not from inside the container).
Again this might me me having done something wrong but I have tried everything and I canot find a solution.
I am running under Linux Ubuntu 18.0.4 docker is not running with sudo but under a docker group which my own user belongs too.
I really appreciate you help and thanks for this repo :)
Regards

“Running a Docker container as a non-root user” by Lucas Wilson-Richter https://link.medium.com/19C6L1OTxV

Thanks I am trying a bit everything but I could not still figure out a way to make thing fully working.
After the creation I change the owner of the volume in the host machine using this command
sudo chown -R $USER
This seems to work  fine the only issue I am having is the host folder the strapi folder under npm module is not present.
This is a problem because i I want to install aws file upload or any other plug in for strapi I have to install it inside the container.
Is this expected?
Is anywhere a procedure I can follow to install the image in the correct way?
Thanks again for your support and for this image :)

HI,
We just released a full rebuild of our docker image 🎉
We are closing the issues and open PRs to start fresh.
If you feel like something is missing or want to add things feel free to open new PRs ! 💯

This issue is not resolved :(
Please see #263

Reopening the original issue and closing the duplicate one #263.
If someone wants to help out on this topic let me know.
Until we find a fix, I would recommend you create a custom Dockerfile and set it up how you actually want it.

Any updates on what could be done to fix this?

temporary solution, @RussellSanders1
First create the application folder, Ex:  app.
run the command below to find out your user id
id -u

change the user value in docker-compose.yml to your user ID.
in my case "user:group" would be 1000:1000
Ex:
version: '3'
services:
  strapi:
    image: strapi/strapi
    environment:
      DATABASE_CLIENT: postgres
      DATABASE_NAME: strapi
      DATABASE_HOST: postgres
      DATABASE_PORT: 5432
      DATABASE_USERNAME: strapi
      DATABASE_PASSWORD: strapi
    user: 1000:1000
    volumes:
      - ./app:/srv/app
    ports:
      - '1337:1337'
    depends_on:
      - postgres

  postgres:
    image: postgres
    environment:
      POSTGRES_DB: strapi
      POSTGRES_USER: strapi
      POSTGRES_PASSWORD: strapi
    volumes:
      - ./data:/var/lib/postgresql/data

did this got fixed? i'm trying to run it and the same error over and over again pops up

I was able to fix it using docker and beanstalk.Sent from Android deviceOn 23 Feb 2022 23:23, Lucas Kaíque @.***> wrote:
did this got fixed? i'm trying to run it and the same error over and over again pops up
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID: @.***>

Not working with any suggestions above..
Strapi uses root as @nckdhl explained
This is stil a issue

Not working with any suggestions above..
Strapi uses root as @nckdhl explained This is stil a issue

what i did was to change ownership from DATA folder, but i agreed it still is a issue


Meanings of Queues

AudioQueue *freeQueue_;         // user
AudioQueue *recQueue_;          // user
AudioQueue *devShadowQueue_;    // owner

play and rec contain audio. What is goal of other queues ?

Conceptually:
  Recorder --> recQueue_ --> Player;  Player --> freeQueue_ -->Recorder

devShadowQueue_: keep track of the buffers for SimpleBufferQueue interface. There are 2: player and  audio driver, recorder and audio driver.
Application creates all of the queues.


python3Packages.boschshcpy: 0.2.20 -> 0.2.23

Motivation for this change
Update to latest upstream release 0.2.23
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 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

[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 137358 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.boschshcpy
python39Packages.boschshcpy


Accessibility issue with chatbot

Encountered using Android TalkBack
When selecting help on the chat box the dialog is broken into two text boxes. Breaks after extra command and also doesn’t read “options.digest” and skips to the next word help, home, etc.

Let me know if this helps: the reader sees this as two text boxes and skips options.digest and picks-up at help.

Yes, it's still doing it.

tested on iPad

Verified - Test PASS


feat: Allow custom context when rendering a view

Description
In the codebase I work on, we use django-cms to manage our blog. In particular we have a BlogView class that calls the details() function to render a blog article. Recently, we wanted to customize the template context of the rendered article (in our case, to add a variable with metadata about an A/B test).
However, the details() function doesn't allow for a custom context to be specified. To allow this, we'd need to parameterize context in the render_page() function. Currently, that function always starts with an empty context = {}. This change maintains that default, but allows the user to specify other variables in the template context.
To work around this limitation, we found that we could intercept the response returned by details() and if it's a TemplateResponse, update the context data. Here's the code:
class BlogView(H2PushView, TemplateView):
    entry_points = ["blog"]

    def get_context_data(self, *args, **kwargs):
        ...

    def get(self, request: HttpRequest, *args, **kwargs):
        slug = request.path.strip("/")
        response = details(request, slug=slug)
        if isinstance(response, TemplateResponse):
            response.context_data.update(self.get_context_data())
        return response

However, this relies on the particular implementation of the details() function, and the fact that TemplateResponse.context_data is a public, writable-field. It would be cleaner if details() itself accepted this context parameter.
Checklist

[x] I have opened this pull request against develop-4
[ ] I have added or modified the tests when changing logic
[x] I have followed the conventional commits guidelines to add meaningful information into the changelog
[ ] I have read the contribution guidelines  and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.

@micahcantor Thank you for this PR! I appreciate the work you've put into this and especially that you are sharing your ideas with the community!!
I have looked at it and come to the conclusion that views.details - django CMS central view function - is not for reusing within other views. Indeed, it may change in structure.
Your use case seems highly unusual in several senses:

django CMS' page tree seems not optimal for blog posts. Many people use djangocms-blog.
Your way of a/b testing will hamper with caching
Your view probably needs only some bits of the details logic. Why not copy those bits from the detail view? It's essentially get_page_from_request and render_page.

Finally, let me point out that your implementation is prone to have side-effects since you use a single {} object to initialize all context objects. This will leave context entries from previous pages displayed as a remainder for other pages.
To implement A/B testing, I'd suggest taking one of the more traditional routes:

Create a custom template tag that can add elements to the context or directly change what is rendered
Add a property to the request object to make a/b selections (available as request in the context)
Add a context processor for A/B selection
Create custom plugins that allow displaying different content (which would also allow editors to change both a and b content!)

@marksweb Do you have any opinion?

@fsbraun Thank you for the quick and detailed reply! I'm not surprised our use case seems unusual, as the codebase in question is ~10 years old and has gone through many iterations before I started 😄 . I also have little-to-no appreciation for how django-cms is used outside of our codebase, this is just something I ran into. Given that, here's some additional context that may help:

django CMS' page tree seems not optimal for blog posts. Many people use djangocms-blog.

That may be true, and I can't speak to why django CMS was chosen for the blog. Probably because we use the CMS on other pages and this reduced implementation complexity.

Your way of a/b testing will hamper with caching

I'm not sure I understand why that would be. Our internal A/B system is also somewhat extensive, and may indeed cover for this.

Your view probably needs only some bits of the details logic. Why not copy those bits from the detail view? It's essentially get_page_from_request and render_page.

That may be true, but even in this case the custom context wouldn't be able to be applied to render_page.

Create a custom template tag that can add elements to the context or directly change what is rendered

This is certainly an option. However, in other views across the site, A/B test data is computed and added to the context in the appropriate view, not in a template tag, so this would add some complexity for other developers.

Add a property to the request object to make a/b selections (available as request in the context)

This would also be possible, but would also deviate from the usual process of having these variables available in the top-level context, which would add a bit of friction for other developers.

Add a context processor for A/B selection

In our case I think this may require fairly significant refactoring of other views.

Create custom plugins that allow displaying different content (which would also allow editors to change both a and b content!)

In this particular case, the A/B content doesn't need to be edit-able, and would add some more friction to the implementation.
In summary, this proposed change is essentially a nice-to-have feature for our particular use case of Django CMS. I couldn't find any other information on this online, and saw that the change required to django-cms is relatively minimal. However, if maintainers believe this added flexibility wouldn't be particularly useful for other developers, then feel free to close this -- no hard feelings!

Yeah this seems rather niche, but the changes aren't drastic. Furthermore, I used to work with a codebase that did something with cms which it really shouldn't - so I understand the situation.
My first thought was that perhaps a context processor or middleware might be more suitable. Failing that you could monkeypatch details, render_pagecontent and render_page to accept your context.
You could probably even do it without monkey-patching. As Fabian said, you could implement the same logic in your application. So looking at BlogView, I might be tempted to setup a class which had it's own version of details and render_page so that they work how you want them to, even if we end up making changes to them.


So, when is compatibility with 1.14 coming?

(ducks when EtlamGit and mrkite start throwing things)
Seriously, thank you, guys!

Is 1.14 out already?
I planned to start with the definition files in next vacation period, which is Easter break.
Hopefully there is no complete storage overhaul again...

Only pre-release snapshots, so I was just kidding....I think the changes are all cosmetic (new NPC mobs, new structures, new weapons, things like that...)
Oh, and I'm Ashtoo on the Minecraft forums.


Fix: Update README to include reference to the docs website

Codecov Report

Merging #87 (2dec18d) into main (505b32b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #87   +/-   ##
=======================================
  Coverage   79.12%   79.12%
=======================================
  Files          16       16
  Lines        1423     1423
=======================================
  Hits         1126     1126
  Misses        231      231
  Partials       66       66

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 505b32b...2dec18d. Read the comment docs.


[Suggestion] Config to disable JEI support of the inscription stamp

Since some people don't want the JEI for that or get confused by it, a simple config option to make it not have JEI support would be nice.
Disclaimer: I don't even know what it is I just made the issue after the discord chat.

Strongly agree since it has confused a lot of my modpack's players.

Yeah I agree, I am trying to integrate it into my modpack but I might remove soot unless I can find a fix for this.


Libelf / libelf.h not found

Hi,
I have installed, using pacman, the libelf package (mingw-w64-x86_64-libelf 0.8.13-3 / mingw-w64-i686-libelf 0.8.13-3 ).
Installation was fine whatever 64 or 32 bits, no errors.
Unfortunately, when compiling my program, the libelf.h is not found by compiler, but I'm able to spot the file when manually searching.
Any idea or track to follow? Do I have miss something?
Regards.

Are you using mingw32 or mingw64 shell and mingw-w64 toolchain?
You verify it with gcc --version.

Thank you for your message.
I'm using mingw64 within msys2 64 bits.
My gcc version is gcc (GCC) 5.3.0

You have to download mingw-w64 gcc:
pacman --needed -S mingw-w64-x86_64-toolchain for 64 bit gcc or/and pacman --needed -S mingw-w64-x86_64-toolchain for 32 bit gcc.

Thank you for this hint.
I have installed these package; unfortunately, I still have the issue but it solved my QT5 stuff includes not found error.
My new version is now: gcc (Rev2, Built by MSYS2 project) 6.2.0
If you have another idea(s), feel free to share them, thanks.


Fetching events for issues and PRs triggers abuse rate limits

When fetching events for issues and PRs, if there are enough of them, github_changelog_generator can trigger the abuse rate limits. We should try following the abuse rate limit guidelines, or wait the respectful amount of time, or something, rather than just dropping the events on the floor.
When I fix error reporting in https://github.com/skywinder/github-changelog-generator/pull/405, I see this:
Can't detect user and name from first parameter: 'changelog' -> exit'
Found 450 tags
Fetching tags dates: 450/450
Sorting tags...
 Please wait a few minutes before you try again.
See: https://developer.github.com/v3/#abuse-rate-limits
Warning: Can't finish operation: GitHub API rate limit exceeded, change log may be missing some issues. You can limit the number of issues fetched using the `--max-issues NUM` argument.
<messages repeat>
...
Fetching events for issues and PR: 1880
Fetching closed dates for issues: Done!
Generating log...

The key here seems to be "Make requests for a single user or client ID serially. Do not make requests for a single user or client ID concurrently."  Following that guideline means removing the thread stuff there.

Oh! I think the reason I'm seeing it and others aren't, is that they allow a certain amount of parallelism but there is a bug in the way we cap our thread count. Will PR.

On my machine, reducing this thread count to 16 fixes the error (and reducing it to 30 is not enough): https://github.com/skywinder/github-changelog-generator/blob/master/lib/github_changelog_generator/fetcher.rb#L169

I have now narrowed the number down a bit: 24 threads does not trigger the issue at all, and 26 triggers it a ton. I bet there is a magic parallelism number they have, and I bet it's 25.

Confirmed! 25 simultaneous requests is OK. 26 is abuse.  Will make PR.


Fix a storage bug

Fixes #878
In the CTU parsing there happened to be a path which goes threw a file
twice, including another file between these two. In the previous
implementation we had a dictionary which contained the files as keys,
but according to the precondition of collect_path_events() function
the keys of this dictionary have to be the file list in the same order
as in the plist file including multiple occurrences.

LGTM


Swift 3

@basvankuijck Could you please fix the indentation to follow the file's convention?

CI failed though.


feat: implement parsing of workflow statements in the experimental parser.

This commit implements parsing of workflow statements in the experimental
parser.
The workflow statements include call statements, scatter statements, and
conditional statements.
With this, the experimental parser should now be capable of fully parsing V1 WDL documents 🎉
Before submitting this PR, please make sure:

[x] You have added a few sentences describing the PR here.
[x] You have added yourself or the appropriate individual as the assignee.
[x] You have added at least one relevant code reviewer to the PR.
[x] Your code builds clean without any errors or warnings.
[x] You have added tests (when appropriate).
[x] You have updated the README or other documentation to account for these
changes (when appropriate).
[x] You have added an entry to the relevant CHANGELOG.md (see
"keep a changelog" for more information).

[x] Your changes are squashed into a single commit (unless there is a really
good, articulated reason as to why there should be more than one).

This PR depends on #43, #46, #47, and #48 to review; when those merge, this will be rebased and marked as ready.


Add public method to retrieve instance id (and other instance metadata)

Describe the feature
You can access the instance-id but it requires using private IMDSFetcher methods:
f = IMDSFetcher()
token = f._fetch_metadata_token()
f._get_request("latest/meta-data/instance-id", None, token=token).text

there's an unfortunately (?) named InstanceMetadataFetcher:
class InstanceMetadataFetcher(IMDSFetcher):
    _URL_PATH = 'latest/meta-data/iam/security-credentials/'
   ...

that sounds like it could be used for arbitrary metadata but it's not.
Use Case
For some ec2/asg methods I need to access my instance id first.
Previously I could make a single request to http://<IP_ADDRESS>/latest/meta-data/instance-id (with some retries/error handling).... whilst a little annoying to be outside of boto3/botocore it was ok.
Now, with IMDSv2, it's quite a bit noisier/requires significantly more boilerplate error handling to use urllib.request or requests (as you can see from the size of IMDSFetcher methods!)
Proposed Solution
Add a public method to IMDSFetcher to fetch specific path e.g.
    def retrieve(self, url_path, retry_func=None):
        token = self._fetch_metadata_token()
        return self._get_request(url_path, retry_func, token=token).text

# use as
IMDSFetcher().retrieve('latest/meta-data/instance-id')

alternatively subclass IMDSFetcher and define a similar method...
Perhaps it makes sense to call this as retrieve_metadata("instance_id") ?
Other Information
No response
Acknowledgements

[X] I may be able to implement this feature request
[ ] This feature might incur a breaking change

SDK version used
boto3
Environment details (OS name and version, etc.)
amazon linux 2023

Hi @hayd thanks for reaching out. This feature request is currently being tracked here in the Boto3 repository: https://github.com/boto/boto3/issues/313. Please feel free to 👍 that issue or add a comment there to share your use case.
However the team does not currently have any plans to expand the functionality of IMDSFetcher as it is not really intended for use and therefore not documented.


FSharpList not correctly deserialized

Is this a bug report?
Yes
Can you also reproduce the problem with the latest version?
Yes. More specifically, it all started with version v5.5.3, this works with v5.5.2 and before.
Environment

Operating system: Window 10 / macOS
Visual Studio version: 2019 / for mac
Dotnet version: 3.0 / F#

Steps to Reproduce
I use this message as sample and just send it through a bus.
It's important to include a list field in the record.
A more complete repro is available here: https://github.com/pchalamet/MassTransitSample - see below for repro steps.
type PurchaseOrder =
    { Id : string
      Components : string list}

Sending and receiving this message fails deserialization and no message can be processed.
Expected Behavior
Message (containing a list) is deserialized and correctly processed as before 5.5.3.
Actual Behavior
Deserialization crashes with following callstack since 5.5.3:
MassTransit.Messages Error: 0 : R-FAULT rabbitmq://localhost/eurodep 2d6e0000-c2bc-3c15-fdd0-08d74c33e195 Value cannot be null. (Parameter 'target'), System.ArgumentNullException: Value cannot be null. (Parameter 'target')
   at Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull(Object value, String parameterName)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Populate(JsonReader reader, Object target)
   at Newtonsoft.Json.Serialization.JsonSerializerProxy.PopulateInternal(JsonReader reader, Object target)
   at Newtonsoft.Json.JsonSerializer.Populate(JsonReader reader, Object target)
   at MassTransit.Serialization.JsonConverters.ListJsonConverter.CachedConverter`1.MassTransit.Serialization.JsonConverters.BaseJsonConverter.IConverter.Deserialize(JsonReader reader, Type objectType, JsonSerializer serializer) in /Users/pierre/src/private/MassTransit/src/MassTransit/Serialization/JsonConverters/ListJsonConverter.cs:line 95
   at MassTransit.Serialization.JsonConverters.BaseJsonConverter.ReadJson(JsonReader reader, Type objectType, Object existingValue, JsonSerializer serializer) in /Users/pierre/src/private/MassTransit/src/MassTransit/Serialization/JsonConverters/BaseJsonConverter.cs:line 15
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.DeserializeConvertable(JsonConverter converter, JsonReader reader, Type objectType, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ResolvePropertyAndCreatorValues(JsonObjectContract contract, JsonProperty containerProperty, JsonReader reader, Type objectType)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObjectUsingCreatorWithParameters(JsonReader reader, JsonObjectContract contract, JsonProperty containerProperty, ObjectConstructor`1 creator, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateNewObject(JsonReader reader, JsonObjectContract objectContract, JsonProperty containerMember, JsonProperty containerProperty, String id, Boolean& createdFromNonDefaultCreator)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)
   at MassTransit.Serialization.JsonConsumeContext.TryGetMessage[T](ConsumeContext`1& message) in /Users/pierre/src/private/MassTransit/src/MassTransit/Serialization/JsonConsumeContext.cs:line 138
   at MassTransit.Context.Converters.ConsumeContextConverterFactory.Converter`1.GreenPipes.Filters.IPipeContextConverter<MassTransit.ConsumeContext,MassTransit.ConsumeContext<T>>.TryConvert(ConsumeContext input, ConsumeContext`1& output) in /Users/pierre/src/private/MassTransit/src/MassTransit/Context/Converters/ConsumeContextConverterFactory.cs:line 38
   at GreenPipes.Filters.OutputPipeFilter`2.GreenPipes.IFilter<TInput>.Send(TInput context, IPipe`1 next)
   at GreenPipes.Filters.DynamicFilter`1.OutputPipe`1.Send(TInput context)
   at GreenPipes.Filters.DynamicFilter`1.Send(TInput context, IPipe`1 next)
   at MassTransit.Pipeline.Filters.DeserializeFilter.Send(ReceiveContext context, IPipe`1 next) in /Users/pierre/src/private/MassTransit/src/MassTransit/Pipeline/Filters/DeserializeFilter.cs:line 49
   at GreenPipes.Filters.RescueFilter`2.GreenPipes.IFilter<TContext>.Send(TContext context, IPipe`1 next)

This used to work before 5.5.3 and messages were correctly deserialized.
The bug happen in ListJsonConverter.cs, line 90 (on master/latest):
                ICollection<T> list = contract.DefaultCreator != null
                    ? contract.DefaultCreator() as ICollection<T>
                    : new List<T>();

Since Microsoft.FSharp.Collections.FSharpList<> does not implement ICollection<>, it's understandable this break... But this used to work before 5.5.3.
Looks like now Newtonsoft json's resolver is not correctly configured (and ICollection<> is unsuitable anyway).
Reproducible Demo
Repo with all sources for F# projects: https://github.com/pchalamet/MassTransitSample
It uses RabbitMQ locally. Run once PurchaseOrderDispatcher (producer) then run Connectivity.Eurodep (consumer). Observe the call stack and deserialization bug here.

Can you confirm with the latest develop packages that this is resolved?

Hello,
Unfortunately this does not fix the regression. FSharpList<> does not implement IList<>. Here is the callstack:
MassTransit.Messages Error: 0 : R-FAULT rabbitmq://localhost/eurodep 7ad00000-0304-54b2-8968-08d74e1fd4f4 Unable to cast object of type 'Microsoft.FSharp.Collections.FSharpList`1[System.Tuple`2[ServiceBus.Messages.PurchaseOrder.Stock,ServiceBus.Messages.PurchaseOrder.Quantities]]' to type 'System.Collections.IList'., System.InvalidCastException: Unable to cast object of type 'Microsoft.FSharp.Collections.FSharpList`1[System.Tuple`2[ServiceBus.Messages.PurchaseOrder.Stock,ServiceBus.Messages.PurchaseOrder.Quantities]]' to type 'System.Collections.IList'.
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Populate(JsonReader reader, Object target)
   at Newtonsoft.Json.Serialization.JsonSerializerProxy.PopulateInternal(JsonReader reader, Object target)
   at Newtonsoft.Json.JsonSerializer.Populate(JsonReader reader, Object target)
   at MassTransit.Serialization.JsonConverters.ListJsonConverter.CachedConverter`1.MassTransit.Serialization.JsonConverters.BaseJsonConverter.IConverter.Deserialize(JsonReader reader, Type objectType, JsonSerializer serializer) in D:\src\oss\MassTransit\MassTransit\src\MassTransit\Serialization\JsonConverters\ListJsonConverter.cs:line 97
   at MassTransit.Serialization.JsonConverters.BaseJsonConverter.ReadJson(JsonReader reader, Type objectType, Object existingValue, JsonSerializer serializer) in D:\src\oss\MassTransit\MassTransit\src\MassTransit\Serialization\JsonConverters\BaseJsonConverter.cs:line 15
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.DeserializeConvertable(JsonConverter converter, JsonReader reader, Type objectType, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ResolvePropertyAndCreatorValues(JsonObjectContract contract, JsonProperty containerProperty, JsonReader reader, Type objectType)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObjectUsingCreatorWithParameters(JsonReader reader, JsonObjectContract contract, JsonProperty containerProperty, ObjectConstructor`1 creator, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateNewObject(JsonReader reader, JsonObjectContract objectContract, JsonProperty containerMember, JsonProperty containerProperty, String id, Boolean& createdFromNonDefaultCreator)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)
   at MassTransit.Serialization.JsonConsumeContext.TryGetMessage[T](ConsumeContext`1& message) in D:\src\oss\MassTransit\MassTransit\src\MassTransit\Serialization\JsonConsumeContext.cs:line 122
   at MassTransit.Context.Converters.ConsumeContextConverterFactory.Converter`1.GreenPipes.Filters.IPipeContextConverter<MassTransit.ConsumeContext,MassTransit.ConsumeContext<T>>.TryConvert(ConsumeContext input, ConsumeContext`1& output) in D:\src\oss\MassTransit\MassTransit\src\MassTransit\Context\Converters\ConsumeContextConverterFactory.cs:line 38
   at GreenPipes.Filters.OutputPipeFilter`2.GreenPipes.IFilter<TInput>.Send(TInput context, IPipe`1 next)
   at GreenPipes.Filters.DynamicFilter`1.OutputPipe`1.Send(TInput context)
   at GreenPipes.Filters.DynamicFilter`1.Send(TInput context, IPipe`1 next)
   at MassTransit.Pipeline.Filters.DeserializeFilter.Send(ReceiveContext context, IPipe`1 next) in D:\src\oss\MassTransit\MassTransit\src\MassTransit\Pipeline\Filters\DeserializeFilter.cs:line 49
   at GreenPipes.Filters.RescueFilter`2.GreenPipes.IFilter<TContext>.Send(TContext context, IPipe`1 next)

OK I've investigated a little bit more and looks like MT is trying to deserialize it self read-only types - that's strange since newtonsoft is able to do this by itself.
Sent PR #1570 for review as this fix deserialization regression for FSharpList.

So the read-only types were added, but they don't work with F# types. Interesting. I'm curious what is trying to cast it to an IList, because it isn't MassTransit. Anyway, I'm not entirely sure I'm fine with this, since a single element won't be deserialized into a list. Hmm. I'll have to look at the history more, since the read-only types were added by a PR.

So, this needs to be smarter. Is it possible to check if the type is an FSharpType and skip it?
bool isFSharpType = false;
            foreach (object attribute in attributes)
            {
                Type attributeType = attribute.GetType();
                if (attributeType.FullName == "Microsoft.FSharp.Core.CompilationMappingAttribute")
                {
                    FSharpUtils.EnsureInitialized(attributeType.Assembly());

                    isFSharpType = true;
                    break;
                }
            }

            if (!isFSharpType)
            {
                return false;
            }

It's a big ugly I must say since newtonsoft does handle this correctly :-( But alas, if that's the best way to handle this, I can't say much.
Btw, I do not really understand why ListJSonConverter exists at all. Looks like primary purpose is to handle non-abstract list, but isn't newtonsoft able to do handle that by itself ? What's the point returning true for CanConvert ?

The default converter does not convert a single element (non-array) to a list.

I added some code that should try to detect the F# type and ignore it, I'll test it with your test harness shortly and see if it resolves the issue.

Yep, your sample works with the latest 6.x develop.


GitHub Actions CI on MacOS and Ubuntu

This pull request integrates GitHub Actions for continuous integration of Boost-for-Android. Currently it only runs build of several libraries: atomic, random, date_time, filesystem, system, thread, chrono for starters but I'd leave it to the authors to decide what they want to test eventually. Build matrix only includes macOS and Ubuntu runners right now because the script works for both of them without much changes. Adding Windows shouldn't be much of a problem, although it will require separate case. I'd rather wait till Microsoft adds support for WSL in GitHub Actions runner to keep the same script everywhere.
Change in the README.md includes a badge for the status of the build, but since it is already pointing to your repository, you won't see it in my latest build in the fork. They don't seem to be supporting fork-independent badges, so I had to hardcode it to the origin. Once this pull request completes, you'll see the badge. It was working properly on my fork before last commit.
The pull request also updates your script to recognize NDK 21.0 since that is the NDK available on GitHub Actions runners.
I had to delay this pull request for few weeks because GitHub Actions runner for MacOS had a [BUG] MacOS runner takes 6 hours to run a 1 minute workflow I filed, which is also tracked by their ticked MacOS runner takes 6 hours to run a 1 minute workflow #430. Yesterday they reported the issue has been resolved and I have validated it on my fork, so it should be good to go now.

Hey @moritz-wundke! Any chance you can look at this pull request?


UK missions conflict with mission starting parameters

When several UK missions are active, the starting parameters sometimes identify the wrong mission as the active one.
Also some inconsistency on the UK Transponder part validation.
Missing aircraft mission incorrectly defines the Vessel key on startup.
[sigh]

New code is for v2.0.5 release

v2.0.5 fixes


Update README.md

We already have a working docker compose file which works out-of-the-box, so I suggest this change.
I understand that this "method" requires the installer to have git on their machine, but I think in the github README it's reasonable to assume.
In our quickstart section of the docs I left it the way it was, we can discuss it down the road.

Codecov Report

Merging #522 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #522   +/-   ##
=======================================
  Coverage   42.15%   42.15%
=======================================
  Files         119      119
  Lines       10235    10235
=======================================
  Hits         4315     4315
  Misses       5434     5434
  Partials      486      486

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f9f10aa...9900a38. Read the comment docs.


feat: Add nbstripout

Motivation
As we have a couple of Jupyter notebooks in the repo now, let's ensure nobody commits the notebooks without clearing the outputs.

Generally LGTM, there seems to be a mypy error from a new mypy version. I wonder whether nbstripout can also be part of the CI? I guess it's better to also enforce this in the CI rather than just use pre commit hooks.

Yep, we can easily run the pre-commit hooks in the CI :) I wanted to wait with this until we enable ruff on the whole code base. Do you intend to merge https://github.com/eth-easl/modyn/pull/487? If yes, I'd rather wait until this is done to avoid conflicts.


Add leon selasi's file

created a branch, created a file and made a commit, and opened a pull request


Update with latest "next"

:tada: This PR is included in version 2.3.0-next.1 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


update(libsinsp): add a way to generate gVisor trace session config file

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature
Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-udig

/area libscap

/area libsinsp

/area tests

/area proposals

What this PR does / why we need it:
For the gVisor support, we need to be able to generate a configuration file on the fly, containing all the syscalls we are interested in and tell gVisor where to connect. To do this, we considered a few alternatives. First of all, we need to take in mind that the generation of the configuration file is so peculiar to gVisor and it is not part of the interface implemented via vtables, of course. For this reason, we could:

add an extra function to scap.c and define it pretty much like scap_open_gvisor_int, using the HAS_ENGINE_GVISOR ifdef. This function could be called from sinsp, and it will internally call another one defined in the gvisor engine, that actually generates the configuration. To make it work, we would also need to add something into sinsp, so that libs consumers can call it. The advantage of this approach would be that the code used to generate the config would be close to the engine. The drawback is that we would need to have a huge tour in libs code, just to print out a configuration string. Does this bring any value? I think it brings only useless complexity.
the second approach is the one we implemented. Since sinsp already contains functions and variables for gVisor, we thought that we could directly generate the config file from there. Libs consumers will be able to call the gvisor config generation function, get the config string as a result, print it and just exit

In any case, I am open to any discussion: if some of the maintainers have better ideas on how to implement this, I am happy to modify this PR 🙂
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Thanks @loresuso for this PR after our discussion in the previous one :rocket: ! I have also thought about it and while it'd be great to have this configuration in the same directory as the scap engine it's not really used by the scap engine but consumed by it and provided by the client (which is sinsp if you think about it...) so it's ok to leave it there. I only have a comment about the namespace structure but I like the implementation overall!

@LucaGuerra: changing LGTM is restricted to collaborators

In response to this:

LGTM

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/approve

LGTM label has been added.  Git tree hash: 36166c29829ebe514fa2bd7ccd7366174657480a

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Have RuleElementPF2e extend DataModel

This includes both RuleElementPF2e getting a DataModel parent as well as initial work on writing schema definitions for subclasses. It makes use of a LaxSchemaField class that doesn't prune unrecognized fields so that the remaining conversion work can be done over time.

Conflicts :(


Create document structure for Miru

Create document structure for Miru

Hey there, can you please assign me this issue.

Hi Kunj, I have raised a PR for this. I will create separate issues to write the documentation. you can pick one up there.


Docs updates - spacing, lists, indents and install instructions

A couple of time-relevant document updates, addition of a new plugin to format lists better, and a number of style and format updates
closes #3420

This still seems to have broken formatting on some pages, such as https://docs.lagoon.sh/administering-lagoon/using-harbor/harbor-settings/
Maybe the plugin is making things worse?

ah, no, the plugin dislikes double-indented lists - eg
* list item
      * list item


Added new test cases for User Login functionality

Added 2 testcases
Updated the test cases excel sheet as well

Fixes #20


certificates - cert and ca chain/intermediate

Hi,
I have my own PKI and I want to add certificate with chain:
CA Cert (trust) -> Intermediate -> Server Cert + Server Cert.Key
But when I am exposing server.cert + server.cert.key as bundle .pem my browser claims that connection is not secure... (CA Trust is added)
How can I add cert chain to show the path to correct CA Trust for browser?
Best Regards
Replay

It's common practice to just concatenate all of those together. Example ...
cat your-cert.pem intermediate-cert.pem ca-cert.pem private-key.pem > combined.pem

and configure the listener with the combined pem file.

hm... I think I did that - but I got error that private key does not match certificate... I will re-try today with this order, maybe this was incorrect...

@aaronhurt Thanks a lot - a messed up with order :/
Now it is working like charm :D


Add support for NDK r19 prebuilt toolchains

This skips the generateToolchains task if it is unnecessary.

why is the generateToolchains task conditional on the NDK revision?

Apologies, I should have been more verbose in the initial PR. Since r19, the Android NDK provides prebuilt toolchains for each of the four supported targets, and make_standalone_toolchain.py is no longer necessary. See the warning at the top of the NDK Standalone Toolchains guide, and the new "other build systems" guide. I originally just removed generateToolchains entirely, but then decided to instead have the plugin support both in case you wanted to maintain backwards-compatibility with pre-r19 NDKs. If that isn't desired, this PR becomes significantly simpler (and the global flag goes away).
This change reduces disk usage during builds (as the toolchains aren't being duplicated), and removes one of the two dependencies on Python (the other being the Cargo linker wrapping introduced in #21).

why is the generateToolchains task conditional on the NDK revision?

Apologies, I should have been more verbose in the initial PR. Since r19, the Android NDK provides prebuilt toolchains for each of the four supported targets, and make_standalone_toolchain.py is no longer necessary. See the warning at the top of the NDK Standalone Toolchains guide, and the new "other build systems" guide. I originally just removed generateToolchains entirely, but then decided to instead have the plugin support both in case you wanted to maintain backwards-compatibility with pre-r19 NDKs. If that isn't desired, this PR becomes significantly simpler (and the global flag goes away).

Mmm, right.  In the Firefox tree we've had endless problems with the pre-built NDKs, so much so that we build our own clang toolchains now, but that's very unlikely to be relevant to folks using this plugin.

This change reduces disk usage during builds for NDK r19+ (as the toolchains aren't being duplicated), and removes one of the two dependencies on Python (the other being the Cargo linker wrapping introduced in #21).

Roger that.  So, rather than making the flag be "r19", let's let the user choose whether to use standalone toolchains.  Expose that flag in the extension DSL but default it to true if we detect r19+.  I still think the cleanest way to do this is to have the Toolchain definitions know if they're using a standalone or if they're using a prebuilt, so can you have a cut at that expression?
Thanks, @str4d!

I've renamed the r19 boolean to prebuilt in the original commit, and exposed it in the DSL. I'll next try experimenting with changes to the Toolchain definitions.

@ncalexan I've pushed commits to switch to using separate ToolchainTypes instead of a prebuilt flag being passed through to CargoBuildTask and Toolchain. I'm not convinced it's a better design, but it works (at least with me testing prebuiltToolchains = true|false in the sample library). Let me know what you think.

Also, FYI I have several subsequent changes I'm considering making PRs here for:

A forceTargets parameter that enables using 64-bit targets with pre-21 minApi (commit)

According to our Android developer, it is common in recent large enterprise applications to target NDK API 16 for 32-bit targets, and API 21 for 64-bit targets. Thus it is currently necessary for us to support this configuration.

A fix for part of #29 (commit).
#23 Variant support (I haven't implemented this yet, but I require it for our library).

So you may not want to immediately cut a new release, or you may want to cut one anyway and leave these to subsequent releases.


Not listed yet: slashdot.org

The website at this url is unlisted: https://slashdot.org/

This website is now in the support list and will be in the next release of the GCM web extension on addons.mozilla.org
Thanks!


Strange crash with EndOfChannel and trio.TooSlowError

What happened
Client crashed with the following error.  It's a little confusing because it looks like the trio.TooSlowError should have been handled...
   ERROR  2020-11-20 17:09:59,797  async_service.Manager  <Manager[Network] flags=SRcfe>: task _manage_routing_table[daemon=True] exited with error:
Traceback (most recent call last):
  File "/home/piper/projects/ddht/ddht/v5_1/dispatcher.py", line 387, in subscribe_request
    yield receive_channel
  File "/home/piper/projects/ddht/ddht/v5_1/client.py", line 379, in find_nodes
    head_response = await subscription.receive()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_channel.py", line 294, in receive
    return await trio.lowlevel.wait_task_rescheduled(abort_fn)
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_core/_traps.py", line 166, in wait_task_rescheduled
    return (await _async_yield(WaitTaskRescheduled(abort_func))).unwrap()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/outcome/_sync.py", line 111, in unwrap
    raise captured_error
trio.EndOfChannel

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
    await task.run()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/async_service/trio.py", line 76, in run
    await self._async_fn(*self._async_fn_args)
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 589, in _manage_routing_table
    nursery.start_soon(_probe_network, random_node_id)
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 555, in _probe_network
    found_enrs = await self.recursive_find_nodes(target_node_id)
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 440, in recursive_find_nodes
    return await common_recursive_find_nodes(self, target)
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 201, in common_recursive_find_nodes
    nursery.cancel_scope.cancel()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 181, in worker
    await adaptive_timeout(*tasks, threshold=1, variance=2.0)
  File "/home/piper/projects/ddht/ddht/_utils.py", line 215, in adaptive_timeout
    nursery.cancel_scope.cancel()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/home/piper/projects/ddht/ddht/_utils.py", line 185, in task_wrapper
    await task_fn(*args)
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 139, in do_lookup
    found_enrs = await network.find_nodes(node_id, distance)
  File "/home/piper/projects/ddht/ddht/v5_1/network.py", line 354, in find_nodes
    responses = await self.client.find_nodes(
  File "/home/piper/projects/ddht/ddht/v5_1/client.py", line 395, in find_nodes
    return responses
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/async_generator/_util.py", line 53, in __aexit__
    await self._agen.athrow(type, value, traceback)
  File "/home/piper/projects/ddht/ddht/v5_1/dispatcher.py", line 392, in subscribe_request
    nursery.cancel_scope.cancel()
  File "/home/piper/python-environments/ddht/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/home/piper/projects/ddht/ddht/v5_1/dispatcher.py", line 390, in subscribe_request
    raise trio.TooSlowError from err
trio.TooSlowError

How to fix
:shrug:

Maybe still a problem
  File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
    await task.run()
  File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 169, in run
    await self.child_manager.run()
  File "/root/env/lib/python3.8/site-packages/async_service/trio.py", line 205, in run
    raise trio.MultiError(
  File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
    await task.run()
  File "/root/env/lib/python3.8/site-packages/async_service/trio.py", line 76, in run
    await self._async_fn(*self._async_fn_args)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 591, in _manage_routing_table
    nursery.start_soon(_probe_network, target_node_id)
  File "/root/env/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 561, in _probe_network
    found_enrs = await self.recursive_find_nodes(target_node_id)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 446, in recursive_find_nodes
    return await common_recursive_find_nodes(self, target)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 207, in common_recursive_find_nodes
    nursery.cancel_scope.cancel()
  File "/root/env/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 183, in worker
    await adaptive_timeout(*tasks, threshold=1, variance=2.0)
  File "/root/env/lib/python3.8/site-packages/ddht/_utils.py", line 265, in adaptive_timeout
    nursery.cancel_scope.cancel()
  File "/root/env/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/root/env/lib/python3.8/site-packages/ddht/_utils.py", line 234, in task_wrapper
    await task_fn(*args)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 139, in do_lookup
    found_enrs = await network.find_nodes(node_id, distance)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 360, in find_nodes
    responses = await self.client.find_nodes(
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/client.py", line 395, in find_nodes
    return responses
  File "/root/env/lib/python3.8/site-packages/async_generator/_util.py", line 53, in __aexit__
    await self._agen.athrow(type, value, traceback)
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/dispatcher.py", line 392, in subscribe_request
    nursery.cancel_scope.cancel()
  File "/root/env/lib/python3.8/site-packages/trio/_core/_run.py", line 741, in __aexit__
    raise combined_error_from_nursery
  File "/root/env/lib/python3.8/site-packages/ddht/v5_1/dispatcher.py", line 390, in subscribe_request
    raise trio.TooSlowError from err
trio.TooSlowError

This is very confusing because this line is wrapped in exception handling for trio.TooSlowError..
 File "/root/env/lib/python3.8/site-packages/ddht/v5_1/network.py", line 139, in do_lookup
    found_enrs = await network.find_nodes(node_id, distance)

So it's unclear to me why that exception isn't being handled.


<IP_ADDRESS> - Mekanism Salt uncraftable

In <IP_ADDRESS> the recipe for Mekanism salt makes fresh water.
The Sodium Chloride Compound recipe is not using the oreDict for salt also, it only uses the Mekanism salt.

make a brine tower and use a chemical crystalizer, and yeah the sodium chloride recipe intentionally uses only mekanism salt as the other methods were much easier.


[5.10] Expose answer content to VoiceOver in Tutorials' Quiz

Explanation: Expose answer content to VoiceOver in Tutorials' Quiz
Scope: Tutorials' Quiz
Issue: rdar://115116964
Risk: Low, minor change for AX
Testing: Added/updated unit tests and manual testing
Reviewer: @dobromir-hristov
Original PR: https://github.com/apple/swift-docc-render/pull/731

@swift-ci test

@swift-ci test