terraform destroy Failing

Tectonic Version
1.6.2-tectonic.1
Environment
MacOS Sierra Version 10.12.4
terraform v0.9.4
What hardware/cloud provider/hypervisor is being used with Tectonic?
AWS
Expected Behavior
Whe exucuting:
terraform destroy -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws

The command shouldn't fail and it should tell me that all resources were destroyed.
   (ID: sg-8f2b55f1, 10s elapsed)
module.masters.aws_route53_record.api-internal: Still destroying... (ID: Z2WAD4DXNRSVSY_a-api.platform-evolved.connectedfleet.io_A, 10s elapsed)
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 20s elapsed)
module.masters.aws_route53_record.api-internal: Still destroying... (ID: Z2WAD4DXNRSVSY_a-api.platform-evolved.connectedfleet.io_A, 20s elapsed)
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 30s elapsed)
module.masters.aws_route53_record.api-internal: Still destroying... (ID: Z2WAD4DXNRSVSY_a-api.platform-evolved.connectedfleet.io_A, 30s elapsed)
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 40s elapsed)
module.masters.aws_route53_record.api-internal: Still destroying... (ID: Z2WAD4DXNRSVSY_a-api.platform-evolved.connectedfleet.io_A, 40s elapsed)
module.masters.aws_route53_record.api-internal: Destruction complete
aws_route53_zone.tectonic-int: Destroying... (ID: Z2WAD4DXNRSVSY)
module.masters.aws_elb.api-internal: Destroying... (ID: a-api-internal)
module.masters.aws_elb.api-internal: Destruction complete
module.vpc.aws_security_group.api: Destroying... (ID: sg-bf2a54c1)
module.vpc.aws_subnet.master_subnet.2: Destroying... (ID: subnet-4fc67e07)
module.vpc.aws_subnet.master_subnet.0: Destroying... (ID: subnet-dc5a6fb9)
module.vpc.aws_subnet.master_subnet.1: Destroying... (ID: subnet-fe468ad2)
aws_route53_zone.tectonic-int: Destruction complete
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 50s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 10s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 10s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 10s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 10s elapsed)
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 1m0s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 20s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 20s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 20s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 20s elapsed)
module.vpc.aws_security_group.console: Still destroying... (ID: sg-8f2b55f1, 1m10s elapsed)
module.vpc.aws_security_group.console: Destruction complete
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 30s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 30s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 30s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 30s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 40s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 40s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 40s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 40s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 50s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 50s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 50s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 50s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 1m0s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 1m0s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m0s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 1m0s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 1m10s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m10s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 1m10s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 1m10s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 1m20s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 1m20s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m20s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 1m20s elapsed)
module.vpc.aws_subnet.master_subnet.0: Still destroying... (ID: subnet-dc5a6fb9, 1m30s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 1m30s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m30s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying...  (ID: sg-bf2a54c1, 1m40s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 1m40s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m40s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 1m50s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 1m50s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 1m50s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m0s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m0s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m0s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m10s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m10s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m10s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m20s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m20s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m20s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m30s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m30s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m30s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m40s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m40s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m40s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 2m50s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 2m50s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying... (ID: subnet-fe468ad2, 2m50s elapsed)
module.vpc.aws_security_group.api: Still destroying... (ID: sg-bf2a54c1, 3m0s elapsed)
module.vpc.aws_subnet.master_subnet.2: Still destroying... (ID: subnet-4fc67e07, 3m0s elapsed)
module.vpc.aws_subnet.master_subnet.1: Still destroying...  (ID: 2017-05-17 16:08:38.326091094 +0000 UTC)
data.aws_availability_zones.azs: Destruction complete
module.vpc.data.aws_availability_zones.azs: Destroying... (ID: 2017-05-17 16:08:39.555924065 +0000 UTC)
module.vpc.data.aws_availability_zones.azs: Destruction complete
module.vpc.aws_security_group.api: Destruction complete
Error applying plan:

1 error(s) occurred:

* module.vpc.aws_internet_gateway.igw (destroy): 1 error(s) occurred:

* aws_internet_gateway.igw: Error waiting for internet gateway (igw-5a8c263c) to detach: couldn't find resource (31 retries)

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Reproduction Steps

Create a cluster with terraform following the CoreOS Tectonic docs.
Try to destroy it with terraform following the CoreOS Tectonic docs.

Other Information
This looks like a possible bug with Terraform most likely.
Work-Around
Execute this command again.
terraform destroy -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws

@bobhenkel Did you create any load balancers via a service Type=LoadBalancer? Those will need to be manually deleted before running destroy.

@robszumski No I did nothing after my apply.
Well heck I had to think about what I had for breakfast today let alone if a service was deployed with LoadBalance.:)
I tried to re-produce with this and I was NOT able to reproduce on a "un-tainted" cluster:
1 apply
#2 destroy
One interesting thing I did notice is that If I run this repeatably it always destroys 32 resources:
bash-3.2$ terraform destroy -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws
Destroy complete! Resources: 32 destroyed.

I'm guessing if I dug around some of your resources must not be all AWS, but something local?
Docs probably could use a little hint to needing to delete any ELBs that may of been fired up outside of Terraform.
Thanks
Bob

Closing this off unless it shows up again.
Summary of what to do, to avoid this issue:
Make sure any ELBs that were launched for a service(type=LoadBalancer) are deleted before trying to terraform destroy your cluster.


ROM test: Ensure that boot ROM can load a 128k bundle into ICCM (assert ICCM contents in test)

Recommendation to make a large static buffer in RO data to make a big enough runtime image.


Investigate Config Singleton

Config is suppose to be a singleton, but since we have multiple processes, a Config is create and for one. We are not sure if it's handle properly at the moment. It need to be investigate if the config is shared in the right way.

python do a fork. it's okay.


fix(material/list): match leading icon size in M3 to spec

Increase size of the leading icon in M3 List to 24px. Match spec, which has list-item-leading-icon-size of 24px. Current version of tokens (0_161) has 18px.
Does not affect M2 List.

Closing in favor of #28567


Support for unpacking .xz archives

Describe the problem/challenge you have
I'd like to be able to unpack .xz archives in addition to .zip, .tar, and .tgz. .xz is commonly used to compress disk images in the IoT/SBC space.
Describe the solution you'd like
This should work the same way as unpacking currently-supported archive formats
Anything else you would like to add:
N/A

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

not stale

Sorry I didn't pick this up earlier.
I think this is definitely something that can be added as a feature to the tool. Going to accept the feature.
Just a warning, the maintainer team at this point is completely swamped with work which might make it hard for us to pick this issue in the near future. Nevertheless, we are happy to help anyone that is interested in building this feature and PRing it to the code.
Also, let us know how this is impacting your usage of vendir so that we try to prioritize this feature accordingly


Add instructions for TestNet in Korean

@linked0 : Would appreciate a review. I'll leave a couple note, too.

@linked0 : Would appreciate a review. I'll leave a couple note, too.

I'm reviewing and providing translation now.

@linked0 : Thanks, all suggestions applied. Can you check the second commit ? It fixes the need to always update this documentation.


Rename prometheus-operator kube-prometheus

Fixes #9
See https://github.com/prometheus-community/community/issues/28#issuecomment-670406329
This is an initial attempt to rename the chart. It hasn't been tested, but please review. There are a lot of changes, so I'm sure to have missed something. One thing I'm unsure about off the bat is whether the cron job names should remain prometheus-operator or not. Thanks in advance for feedback.
I have also dramatically simplified the README now that helm show values gives all the info a user needs, and makes that the older convention of duplicating these value configurations in the README unnecessary. I'm not sure the upgrading sections are still relevant, but I organized them and left them in case they are useful to end users.

This seems like it will have issues with PVCs that anyone may have created as part of the previous release as well as anyone using this in umbrella charts. Would be nice to give some guidance on how to solve for those issues using some variables. I've had no time to look at this in the last while.

@vsliouniaev Thanks for looking into this. There is a section in the readme under "Persistent Volumes" that I believe addresses this:

If you would like to keep the data of the current persistent volumes, it should be possible to attach existing volumes to new PVCs and PVs that are created using the conventions in the new chart… [EXAMPLE]
The PVC will take ownership of the PV and when you create a release using a persistent volume claim template it will use the existing PVCs as they match the naming convention used by the chart. For other cloud providers similar approaches can be used.

I have not done this myself with this chart, but have helped with migrations by configuring other charts to attach existing claims to the new deployment.

Wow, I didn't even know that prometheus-operator chart is not the prometheus-operator as I wanted to try out the operator soon.
So +1 to rename it.

Once #14 is merged, will will need to rebase this PR. The change to this chart is deprecating the old chart to begin with so it doesn't get indexed until we finish reviewing this PR and un-deprecate it under the new name.

For what it's worth, I think kube-prometheus matches most closely what it was before, and the idea behind it now. It is the overarching chart bringing the sub parts together for kubernetes users.

@scottrigby I messed it up when merging the PR you had approved.

@Xtigyro how about prometheus-operator-kube-prometheus then? That would remove the ambiguity. (to be fair I have the same problem with the prometheus chart being a lot more than just Prometheus, as the "current" prometheus-operator chart)

@brancz That name is very clear. However, isn't it too long? I have no problem with that. I just want a fair choice for you as well so you are happy too. That's why I proposed kube-prometheus-distro.

I guess since it's a chart, we might be able to "omit" kube- completely. How about prometheus-stack?

I want to make it crystal clear that it's based on the upstream kube-prometheus project, I understand that helm sets the kubernetes context, but it's more about association with the "upstream" project.

Personally I admit I had never understood that this chart installs the kube-prometheus project. It appeared to be a generally opinionated wrapper for the prometheus-operator project.
 I have even met with @gianrubio and discussed/installed the stable/prometheus chart in person. So I'm guessing that I was confused, a large percent of the user base is also likely unclear about this. If I understand correctly, this is why @brancz made this naming the primary condition for sponsoring bringing the prometheus charts into the prometheus-community GitHub org.

Because contributors PRs in stable are on hold until this is complete, I would suggest agreeing on the name ASAP.
So where do we stand:

There was one dissenting view about kube-prometheus, by @Xtigyro (concerned end users may mistake kube-prometheus for the prometheus chart he maintains. Fair enough)
@brancz has made clear that kube-prometheus must be clearly part of the name (because of the long-standing issue above. Example prometheus-operator-kube-prometheus or something else containing the project name. Very fair)
Other names suggested: kube-prometheus-distro (@Xtigyro) and prometheus-stack (@mrueg)

Suggestion:
How about we combine the above suggestions to be kube-prometheus-stack?
I just checked and the upstream kube-prometheus project. While there is no reference to "distro", theh README has 5 references to "kube-prometheus stack" (such as "The kube-prometheus stack includes…"), and 13 references to the project "stack" overall (such as "This stack provides…").
@brancz would this be acceptable?

Then just how about prometheus-stack, as it is a prometheus related bundle? We all know it's for k8s by now, no need to carry that in the name, right?

I am happy with kube-prometheus-stack.

"kube-prometheus-stack" sound good to me too.

Very nice - thanks, @brancz!

The name change is pushed. I'm testing this locally myself, and everything seems to be running smoothly.
How you can help
Can others please test this and review? This is the last thing I believe we need before all the stable prometheus charts will have been successfully migrated 😄

CI passed! 👍

I am waiting for this merge. There's a PR Lint and Test Charts / lint-test (pull_request) failure due to this:
https://github.com/prometheus-community/helm-charts/pull/49

I'll resolve the new merge conflict tomorrow.
Also @bismarck said he will test the adopting existing PVCs use case this week. Anyone else is welcome to test that as well, if you'd like to help.
If that tests ok, we will need an approving review by one of the two maintainers in order to merge.

Two small fixes here: https://github.com/prometheus-community/helm-charts/pull/60

@scottrigby @torstenwalter @gianrubio I don't understand what is this failing for in DCO. Can any one of you explain this pls?

I'm sorry! I've been working on other projects in the past year, therefore I could not be involved with supporting the helm charts.
I fully agree with the chart renaming.
One thing that is missing here is a note explaining that this chart can break the compatibility from helm/charts. It's fine to not have a clear migration path from the previous repo as long all users are informed. Hopefully, the community will find an easy way to migrate from there and it will send a PR :)
Finally, thanks for the community for supporting this helm chart!

Ignore the fun new conflicts - will fix those in a bit. Rebased & force-with-lease in order to fix DCO. I'll link the issue later

Fixed DCO. @gkarthiks The reason was the author/signoff in e729fdb.  See https://github.com/probot/dco/issues/134.  I believe in this case I have your permission do do that, but correct me if I'm wrong 🙂
I had to force-push to fix DCO, so some comment connections may be lost in the UI. But @gianrubio I added myself as you suggested. Everything else should be the same as the accepting reviews. The one thing I want o

Ok 👌 tests are passing. DCO fixed. After changes pushed, needs another accepting review from someone in the prometheus-operator maintainers list again - and then we can finally merge this 😅

Nice! We are getting there. Two approvals. @scottrigby you should be the one to do the merge ;-)

I'm not sure why the need to prefix with kube as all Helm charts are by definition associated with kubernetes already. So within that context prefixing with kube is redundant. I prefer the simpler prometheus-stack as it:

Drops the unnecessary prefix
Matches the prefix of every other chart in this repo (e.g. prometheus-)
Clearly differentiates between the separate prometheus-operator and kube-prometheus projects
Reads nicer: Indicates you're installing prometheus plus a stack of other components. You're not installing a "kube".

@steven-sheehy I know a ton of discussion is buried in GitHub collapsed comments, so please read the direct links:

Summary: https://github.com/prometheus-community/helm-charts/pull/1#issuecomment-686495216
Final sponsor approval: https://github.com/prometheus-community/helm-charts/pull/1#issuecomment-687072186

The kube-prometheus project name must be part of the chart name, as an absolute condition of moving this git repo to the prometheus-community org. The maintainers of that chart and prometheus devs (including maintainer of upstream kube-prometheus project) have agreed on the name. That process is now finished.

I believe we've covered all our bases and then some over the past month of this PR. We're now – finally – ready to merge 😅  With that said… Thanks everyone! 🎉 💖 🙌

@scottrigby Thank you, man! Your work has been UNBELIEVABLY VALUABLE! 🥇


[lcms] Update to 2.16

Update lcms to 2.16. Remove outdated patch remove_library_directive.patch.
No feature needs to be tested, the usage test passed on x64-windows (header files found):
The package lcms provides CMake targets:

    find_package(lcms2 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE lcms2::lcms2)

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] ~The "supports" clause reflects platforms that may be fixed by this new version.~
[ ] ~Any fixed CI baseline entries are removed from that file.~
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] When updating the upstream version, the "port-version" is reset (removed from vcpkg.json).
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Coordinate with #36847.


Model Performance?

Hi, I tested the performance on voc2007 test set. And the performance is not as good as yours. My meanAP is only about 0.5851. Do you know what might be wrong?

Hi @Yuliang-Zou ,
How many region proposals you use per image?
You can check it in ./lib/fast_rcnn/test.py.

I've fixed that, thank you so much!
Actually I cannot test the model using test_net.py directly. It always told me that "invalid resource handle". So I wrote my own python script to test it, but forgot to set the thresh as the same as you did.


Study comparison page

The study comparison page is defined by a list of study ids.
Minimal API
The data for this page can be constructed from multiple calls to the search(queryString), studyInfo(studyId) and manhattan(studyId) queries.
Design
Without the overlap table, studies can be compared visually by showing their Manhattan plots side by side in a table. A first draft might look something like the following.

The other feature needed by the user is a way to add new studies and remove those present. This could be done with a delete button per row and a study specific search box.

Added in https://github.com/opentargets/genetics-app/pull/45


Fix and add example snippets

Cleanup useNetwork example, fix marketplace wrong examples, add NftMe…

Related to this https://github.com/thirdweb-dev/docs/pull/128


STREAM-825: Akka stream Source from AWS Kinesis stream

This is to provide a fluent way to create akka-stream Source out of gfc-aws-kinesis client

👍

Ah, I see ... Yeah, makes sense.
Definitely too many config-related bits now, makes sense to consolidate.

@andreyk0 I don't want to put that in the same PR. But I'll do that in the next one

Yep, sounds good.

👎
Please:

Improve encapsulation
Improve decoupling between Kinesis code and deser code
Put some meaningful ScalaDocs on the public types
Avoid to pass fat 'Config' objects but use more focused classes. Passing plain fns into a class ctor is OK.

👍

👍 LGTM


Atomic changes in service registry

Description
Allow policy updates to do atomic changes to the service registry and clean up old registrations.

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "component": "enforcerd",
    "pr-id": "482",
    "commit-sha": "7d7a865bd5c144176432fe977e0d909fc19a3921"
  },
  {
    "component": "trireme-lib",
    "pr-id": "481",
    "commit-sha": "ee8af066ef8e7c9f561c933a828d1086778411c5"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "component": "enforcerd",
    "pr-id": "482",
    "commit-sha": "7d7a865bd5c144176432fe977e0d909fc19a3921"
  },
  {
    "component": "trireme-lib",
    "pr-id": "481",
    "commit-sha": "ee8af066ef8e7c9f561c933a828d1086778411c5"
  }
]


Bottom sheet back navigation from scrim area

The back navigation from a bottom sheet feature by clicking on the scrim area (greyed out area) prevents further navigation afterwards.
The simple sample can be used to demonstrate and debug the issue.
Issue:

Open the bottom sheet by clicking on the "Bottom Sheet" text
Dismiss the bottom sheet by clicking on the grey scrim area
Try to open the bottom sheet again by clicking on the text

=> The bottom sheet doesn't open again. It continues working if you press the back button.
Assumption: The bottom sheet is not cleared from the backstack if you click on the scrim area.

This is a bug in accompanist, specifically what is described in the second part of this comment https://github.com/google/accompanist/issues/1031#issuecomment-1489844606
If you downgrade to to accompanist 0.28.0 (and compose material 1.3.1) the issue goes back to the original description of the linked ticket, meaning that the issue you describe only happens if you dismiss the bottom sheet during the transition.


Skip Redundant Compilation in Analyze Job

Description
This PR updates the Analyze job in CI to skip running a second source and test compilation that happened when running Checkstyle, Javadoc, RevApi, and Spotbugs. The second compilation occurred due to running the verify lifecycle goal which includes running compilation. There is a previous step that runs to compile and install the SDKs being validated. The two new Maven properties are the following:

maven.main.skip: Skips running source code compilation
main.test.skip: Skips running test code compilation

All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

/azp run java - resourcemanager


fix(lucko#1365): run bukkit RCON commands synchronously

bukkit/spigot have an outstanding issue where async messaging does not function over
RCON. this works around the issue until a fix PR is accepted

This looks phenomenal! fixing #1365 has been impossible for a while, but I think that it needs a config option (people hate synchronous operations that they're unaware of) so that people who enable it are aware and willing to use a sync operation regardless of potential downsides

This looks phenomenal! fixing #1365 has been impossible for a while, but I think that it needs a config option (people hate synchronous operations that they're unaware of) so that people who enable it are aware and willing to use a sync operation regardless of potential downsides

(sender instanceof RemoteConsoleCommandSender) limits synchronous operations to just RCON. User commands and console commands will operate asynchronously. There is also WARNING before each response for RCON users that this command could block the game thread. I feel like a feature flag for a bug fix with no breaking changes is an anti pattern.

(sender instanceof RemoteConsoleCommandSender) limits synchronous operations to just RCON. User commands and console commands will operate asynchronously. There is also WARNING before each response for RCON users that this command could block the game thread. I feel like a feature flag for a bug fix with no breaking changes is an anti pattern.

The warning imo is less preferred than a toggle - if you want to use it, having a potential flood of warnings would not be preferable, while if you don't want to use it, rcon commands should be blocked entirely. This isn't exactly a bugfix as it does not correct the source problem, it rather works around the problem by forcing RCON commands to run synchronously. As this is, as I see it, closer to a feature, it may be something users want to entirely disable, and if they want to use it then

Hardcoding a warning in English for a plugin that supports several languages is not preferred
Using it often, with knowledge of what it does, would make many users displeased with the flooded logs of the same warning that they know about and chose to use anyways.

This is just how I see it, Luck has the final say 😄

The warning imo is less preferred than a toggle - if you want to use it, having a potential flood of warnings would not be preferable, while if you don't want to use it, rcon commands should be blocked entirely. This isn't exactly a bugfix as it does not correct the source problem, it rather works around the problem by forcing RCON commands to run synchronously. As this is, as I see it, closer to a feature, it may be something users want to entirely disable, and if they want to use it then

Hardcoding a warning in English for a plugin that supports several languages is not preferred
Using it often, with knowledge of what it does, would make many users displeased with the flooded logs of the same warning that they know about and chose to use anyways.

This is just how I see it, Luck has the final say 😄

You convinced me that the warning is noise and should be removed. Done.
I'm not convinced this is a feature. The problem is lp commands over RCON do not output a response. A response is the only indication of successful or failure on RCON: https://developer.valvesoftware.com/wiki/Source_RCON_Protocol
I'm also not convinced RCON commands should run asynchronously. I couldn't find an RFC to confirm this, but RCON protocol seems to be serial in nature with one (or more) response packets following a command packet. Making this command asynchronous can lead to race conditions when bulk commands are run sequential.
lp creategroup test
lp group test permission set foobar true
lp group test rename test2
lp group test2 permission set foobaz false

The above is contrived, but any bulk set of operations that mutates your permission state should be run in order.
My use case is initializing a docker cluster with all required groups and permissions by piping the commands through RCON. This lets my seed scripts remain agnostic to any database changes, and I just need to watch out on major rev updates.

You convinced me that the warning is noise and should be removed. Done.
I'm not convinced this is a feature. The problem is lp commands over RCON do not output a response. A response is the only indication of successful or failure on RCON: https://developer.valvesoftware.com/wiki/Source_RCON_Protocol
I'm also not convinced RCON commands should run asynchronously. I couldn't find an RFC to confirm this, but RCON protocol seems to be serial in nature with one (or more) response packets following a command packet. Making this command asynchronous can lead to race conditions when bulk commands are run sequential.
lp creategroup test
lp group test permission set foobar true
lp group test rename test2
lp group test2 permission set foobaz false

The above is contrived, but any bulk set of operations that mutates your permission state should be run in order.
My use case is initializing a docker cluster with all required groups and permissions by piping the commands through RCON. This lets my seed scripts remain agnostic to any database changes, and I just need to watch out on major rev updates.

I reckon there should be a setting (something like rcon-sync-operations or whatever, false by default) that if false it blocks the operation and warns the sender instead but if true it just doesn't do that and runs the command unsafely; this would be more like vault-unsafe-lookups when making operations for offline players on the main server thread.

I reckon there should be a setting (something like rcon-sync-operations or whatever, false by default) that if false it blocks the operation and warns the sender instead but if true it just doesn't do that and runs the command unsafely; this would be more like vault-unsafe-lookups when making operations for offline players on the main server thread.

I'm not clear how synchronous execution of a RCON command is unsafe.

I'm not clear how synchronous execution of a RCON command is unsafe.

The issue isn't the RCON command, the issue is that the operation will effectively run on the main server thread and, if the operation takes long time to complete (e.g. load user data, run a heavy database query, bulk operations on text-based storage methods, etc), it will cause lag; that is the reason why vault-unsafe-lookups is false by default and throws a runtime exception.

The issue isn't the RCON command, the issue is that the operation will effectively run on the main server thread and, if the operation takes long time to complete (e.g. load user data, run a heavy database query, bulk operations on text-based storage methods, etc), it will cause lag; that is the reason why vault-unsafe-lookups is false by default and throws a runtime exception.

We have the following requirements:

RCON should run synchronously for consistency/adhere to the protocol
onCommand must complete quickly to avoid blocking the main game thread

Proposed changes:

Add support for integerKey
Include rcon-timeout-seconds defaulted to 5

Commits updated.

We have the following requirements:

RCON should run synchronously for consistency/adhere to the protocol
onCommand must complete quickly to avoid blocking the main game thread

Proposed changes:

Add support for integerKey
Include rcon-timeout-seconds defaulted to 5

Commits updated.

Including a timeout is a great option, but does not solve the main problem - primarily that rcon commands run sync and sync operations are toggleable in LuckPerms. As Fefo brought up, there are even other examples - vault-unsafe-lookups des not have a timeout, but rather a toggle. I believe it is better design to allow a toggle because having a default, limited, timeout will not match some users' specifications, while a toggle allows them the freedom to choose entirely.
I'm thinking here of a user who wants to use the RCON feature and needs it, for whatever reason, to prevent all other operations until it is done. Is this smart? Probably not, but it does not mean that the plugin should choose for the user, the choice should be left with the user entirely. Having a timeout option is fantastic, I suggest, however, that it defaults to 0 and that a toggle is also added. That way, a user can choose to enable it without any timeout, or they can enable it and set whatever timeout they want.

Including a timeout is a great option, but does not solve the main problem - primarily that rcon commands run sync and sync operations are toggleable in LuckPerms. As Fefo brought up, there are even other examples - vault-unsafe-lookups des not have a timeout, but rather a toggle. I believe it is better design to allow a toggle because having a default, limited, timeout will not match some users' specifications, while a toggle allows them the freedom to choose entirely.
I'm thinking here of a user who wants to use the RCON feature and needs it, for whatever reason, to prevent all other operations until it is done. Is this smart? Probably not, but it does not mean that the plugin should choose for the user, the choice should be left with the user entirely. Having a timeout option is fantastic, I suggest, however, that it defaults to 0 and that a toggle is also added. That way, a user can choose to enable it without any timeout, or they can enable it and set whatever timeout they want.

The timeout supports that behavior. Set the timeout to Integer.MAX_VALUE. The pedantic among you will argue that is only a 68 year timeout but I'm willing to wait and see if anyone hits it :trollface:

The timeout supports that behavior. Set the timeout to Integer.MAX_VALUE. The pedantic among you will argue that is only a 68 year timeout but I'm willing to wait and see if anyone hits it :trollface:

Hey, thanks for the PR!
However, I would prefer it if we took a slightly different approach: a boolean config option like rcon-run-commands-sync which defaults to false, but when true, uses the blocking behaviour.
LuckPerms commands are not suited to being ran on the main thread - most of them involve some sort of blocking i/o which will make the server (game) thread lag if executed sync.
The reason for defaulting false - rcon is still perfectly functional at the moment for LP commands (without causing any lag), which imo is better than having cmd feedback + lag.

Hey, thanks for the PR!
However, I would prefer it if we took a slightly different approach: a boolean config option like rcon-run-commands-sync which defaults to false, but when true, uses the blocking behaviour.
LuckPerms commands are not suited to being ran on the main thread - most of them involve some sort of blocking i/o which will make the server (game) thread lag if executed sync.
The reason for defaulting false - rcon is still perfectly functional at the moment for LP commands (without causing any lag), which imo is better than having cmd feedback + lag.

If you'd be happy to make those changes, I will merge the PR. :)
If not, I don't mind making the changes myself, since I agree it would be a useful option to have.

If you'd be happy to make those changes, I will merge the PR. :)
If not, I don't mind making the changes myself, since I agree it would be a useful option to have.

Please feel free to re-open if/when you implement those changes. :)


similar functionality to j.shell

similar functionality to j.shell

IMHO, no need to implement this, pudb is already a development dependency (ipdb can be used too in some cases).
Also, Control + J is supported in case of errors or instruction debugging.


Syncing OCI helm chart with semver version range fails if tag has a v prefix

What steps did you take:
[A clear and concise description steps that can be used to reproduce the problem.]
I tried syncing a helm OCI chart from here: https://github.com/metacontroller/metacontroller/pkgs/container/metacontroller-helm/153598243?tag=v4.11.7
The chart version is published with a v prefix (which is quite common).
I used the following vendir.yml
---
apiVersion: vendir.k14s.io/v1alpha1
kind: Config
directories:
- path: vendor
  contents:
  - path: metacontroller
    helmChart:
      name: metacontroller/metacontroller-helm
      version: ^4.0
      repository:
        url: oci://ghcr.io

What happened:
❯ vendir sync
Fetching: vendor + metacontroller (helm chart from oci://ghcr.io@metacontroller/metacontroller-helm:^4.0)

vendir: Error: Syncing directory 'vendor':
  Syncing directory 'metacontroller' with helm chart contents:
    Helm chart pull: exit status 1 (stderr: Error: Unable to locate any tags in provided repository: oci://ghcr.io/metacontroller/metacontroller-helm

If I change the version to 4.11.7 the sync also fails.
Only case when the sync works is if I explicitly declare the tag with a v prefix like v4.11.7 but then semver rules don't work eg. v4.0.
What did you expect:
I expected the vendir command to resolve the latest version to 4.11.7, sync that, and write that version into the lock file.
Anything else you would like to add:
Environment:

vendir version (execute vendir --version): 0.39.0
OS (e.g. from /etc/os-release): MacOS Sonoma 14.3

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

OTOH this might be a helm issue, so I'll also throw the topic into the project's github.

Opened an issue with the chart maintainer: https://github.com/metacontroller/metacontroller/issues/946


Update - New Settings Design (v0.9.0)

To support the new features and to improve settings navigation, a new design for the settings that is cleaner and more "standard" would be a good addition.

The API has had some gradual changes to help support the drawing of Serialized Properties and other GUI elements. Support will continue but requires a much larger overhaul which will be done for v1.0.
See GUI Drawers for implementation.


nginx -t时提示[emerg] invalid port in resolver

提示在nginx.conf的最后一行有错误。但最后一行明显只有一个右花括号。所以请问一下这是怎么回事。
完整出错信息：nginx: [emerg] invalid port in resolver "2400:8500:1101:698:210:157:3:4" in /usr/local/nginx/conf/nginx.conf:43

Can you give us a dump of nginx.conf 40-45 lines?

Of course.Here it is.
#gzip  on;

include /home/co/main.conf;

}

First 5 lines of /home/co/main.conf is needed also -)

#Auto To www
server{
listen 80;
server_name www.metaworld.xyz;
rewrite ^/.(.*) https://metaworld.xyz/$1 permanent;
}

Maybe there is a IPV6 record in /etc/resolv.conf.
Tengine will parse every record in /etc/resolv.conf as internal resolver by default.

FIXED in tengine-2.1.1.

invalid port in resolver "fd6c:4bb1:87bd::1" in /usr/local/nginx/conf/nginx.conf:123
tengine-2.2.0

check your file /etc/resolv.conf

invalid port in resolver "fd6c:4bb1:87bd::1" in /usr/local/nginx/conf/nginx.conf:123
tengine-2.2.2


Implement a generic class for monitors specifications

This will help getting the dpi or the dots-per-cm for a monitor. It will be useful for the instance of TargetView, when deciding the size of a displayed target according to the true distance from screen and the simulated shooting distance.

Completed, tested. Works!


Initialization error

I have just installed the plugin and I am receiving the following error and homebridge enter's failed state:
. . .
Jul 19 08:54:13 pi homebridge[30072]: [2017-7-19 08:54:13] [Broadlink RM] Initializing BroadlinkRM platform...
Jul 19 08:54:13 pi homebridge[30072]: /usr/lib/node_modules/homebridge-broadlink-rm/node_modules/mkdirp/index.js:90
Jul 19 08:54:13 pi homebridge[30072]: throw err0;
Jul 19 08:54:13 pi homebridge[30072]: ^
Jul 19 08:54:13 pi homebridge[30072]: Error: EACCES: permission denied, mkdir '/home/homebridge'
Jul 19 08:54:13 pi homebridge[30072]: at Object.fs.mkdirSync (fs.js:890:18)
Jul 19 08:54:13 pi homebridge[30072]: at sync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/mkdirp/index.js:71:13)
Jul 19 08:54:13 pi homebridge[30072]: at sync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/mkdirp/index.js:77:24)
Jul 19 08:54:13 pi homebridge[30072]: at sync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/mkdirp/index.js:77:24)
Jul 19 08:54:13 pi homebridge[30072]: at Function.sync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/mkdirp/index.js:77:24)
Jul 19 08:54:13 pi homebridge[30072]: at LocalStorage.parseStorageDirSync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/node-persist/src/local-storage.js:619:20)
Jul 19 08:54:13 pi homebridge[30072]: at LocalStorage.initSync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/node-persist/src/local-storage.js:142:14)
Jul 19 08:54:13 pi homebridge[30072]: at Object.nodePersist.initSync (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/node-persist/src/node-persist.js:37:32)
Jul 19 08:54:13 pi homebridge[30072]: at Object.init (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/homebridge-platform-helper/helpers/persistentState.js:10:15)
Jul 19 08:54:13 pi homebridge[30072]: at BroadlinkRMPlatform.HomebridgePlatform (/usr/lib/node_modules/homebridge-broadlink-rm/node_modules/homebridge-platform-helper/platform.js:14:21)
Jul 19 08:54:13 pi homebridge[30072]: at BroadlinkRMPlatform (/usr/lib/node_modules/homebridge-broadlink-rm/index.js:11:1)
Jul 19 08:54:13 pi homebridge[30072]: at Server._loadPlatforms (/usr/lib/node_modules/homebridge/lib/server.js:294:32)
Jul 19 08:54:13 pi homebridge[30072]: at Server.run (/usr/lib/node_modules/homebridge/lib/server.js:80:36)
Jul 19 08:54:13 pi homebridge[30072]: at module.exports (/usr/lib/node_modules/homebridge/lib/cli.js:40:10)
Jul 19 08:54:13 pi homebridge[30072]: at Object. (/usr/lib/node_modules/homebridge/bin/homebridge:17:22)
Jul 19 08:54:13 pi homebridge[30072]: at Module._compile (module.js:569:30)
Jul 19 08:54:13 pi systemd[1]: homebridge.service: main process exited, code=exited, status=1/FAILURE
Jul 19 08:54:13 pi systemd[1]: Unit homebridge.service entered failed state.
. . .
my config.json has only this:
{
"platform": "BroadlinkRM",
"name": "Broadlink RM"
},
Note that when I remove the platform entry from the config.json there are no errors, but there are no new accessories in the apple home app either.
any help is appreciated.
thanks.

permission error:

I'm having this same issue. Can you tell me how to give homebridge permission?


Update IK and TSID to the latest manif version

This fixes #235.
@traversaro while merging this PR we should update the version of installed manif in superbuild and in conda.
We may probably ask to add a tag in manif

Just to understand, there is any specific reason for updating now? Could it make sense to wait for the next release/tag of manif, and then update after it?

The latest version of manif introduces python bindings that can be used in blf as shown in https://github.com/dic-iit/bipedal-locomotion-framework/pull/238#issuecomment-799435166

Just to understand, there is any specific reason for updating now? Could it make sense to wait for the next release/tag of manif, and then update after it?

Ok, I suspect the answer is related to https://github.com/dic-iit/bipedal-locomotion-framework/pull/238#issuecomment-799435166 .

The latest version of manif introduces python bindings that can be used in blf as shown in #238 (comment)

I think I replied exactly at the same time.

Ok for superbuild, for conda unfortunately we need to wait for a release (not a problem until we tag a new release of blf).

Ok for superbuild, for conda unfortunately we need to wait for a release (not a problem until we tag a new release of blf).

Note that this probably means that we either shut down the conda CI, or we just install manif manually there.

Note that this probably means that we either shut down the conda CI, or we just install manif manually there.

I think we can manually install manif there

Let's wait for https://github.com/artivis/manif/pull/211 before changing the Conda CI and merge the PR

In https://github.com/dic-iit/bipedal-locomotion-framework/pull/239/commits/3c1ec669a36c533093732d617749f87e03c34231 I manually installed manif But I'm not actually sure that it will be installed in a "visible" location

In 3c1ec66 I manually installed manif But I'm not actually sure that it will be installed in a "visible" location

I fixed the problem, the "system" C++ prefixes for conda environments are ${CONDA_PREFIX} on Linux/macOS and ${CONDA_PREFIX}/Library on Windows. I have an idea on how to clean this user experience, but I need to suggest an modification in CMake upstream and this could take time.


[Accessibility]A11y_VSCode_GoToLine_Screenreader: NVDA is reading expanded values of "GotoLine" as blank.

Environment Details:
VSCode Version : 1.24.1
OS Version : Win10
Additional Details:
Screenreader,NVDA[2018.2],MAS1.3.1
Repro Steps:
1.Navigate to Status Bar and select "Go To Line" button.
2.After opening the "GoToLine" the keyboard focus is on editable text field.
3.Navigate to expanded values of gotoline.
3.Observed that,NVDA reading the focused value as blank.
Actual:
The focused selected value nvda is reading it as blank.
such as "Untitled-2" reads as blank.
Expected:
NVDA should read "Untitled-2" as "Untitled-2" instead of blank.
Recommendations:
Refer below link which is repository of bug fixes code snippets:
https://microsoft.sharepoint.com/teams/msenable/mas/Pages/browse-fixes.aspx
User Impact:
User will not understand what value is selected from expanded "GoToLine"
MAS Reference:
MAS1.3.1: https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={54f28d1f-a2d1-4dcd-84e1-5c9b87e8aba4}
Attachment For Reference:
[Accessibility]A11y_VSCode_GoToLine_Screenreader.pptx
Does this issue occur when all extensions are disabled?: Yes
[Accessibility]A11y_VSCode_GoToLine_Screenreader.pptx

Dup of the other quick open items
https://github.com/Microsoft/vscode/issues/52383
and tab wrongly jumps


Create contact feature

I have created spreadsheets with all the contacts I can find by state. Here is one for Arkansas: https://docs.google.com/spreadsheets/d/1hSanXIVMxpuqT02NneRv7hL0KTqPFtcLEv727DnGnxM/edit#gid=0
They are in each state's folder. Should we create one big "Contacts" feature? I broke these out by state so that we can have a few people in the field help us keep this information up-to-date. We could also turn it into one big spreadsheet if that's easier for you.
The idea is to use this info so that anyone can search for a contact, or on a specific page I can say something like, "display contacts from Arkansas at field stations with permits in their title."
Thoughts? Thanks!

@jenmstrick I think it makes sense to put this all in one spreadsheet.  We can still pull data out by state/office, but it would be nice to have one place where this is stored.

Alright done! Well the spreadsheet isn't done, but I've put it all in one place: https://docs.google.com/spreadsheets/d/1hSanXIVMxpuqT02NneRv7hL0KTqPFtcLEv727DnGnxM/edit

Hey! So this info can be used for the "Contact Us" button that's ever-present and sitewide. Again, maybe a filterable list like you did for the social media accounts? Filter by name, keyword, station, state, etc?

Closed via #24.
Open a new ticket if you have suggestions for how to better display the contacts list.


Break docstring if comment is above it

Hi, the comments usually work great, but when there is comment directly above docstring, the docstring is broken, illustrated by this tests:
import ast_comments as ast
import pytest

comment_below = '''
"""
Multiline string
"""
# comment
'''.strip()

def test_this_one_is_fine():
    assert comment_below == ast.unparse(ast.parse(comment_below))

comment_above = '''
# comment
"""
Multiline string
"""
'''.strip()

@pytest.mark.xfail(reason="This one is failing")
def test_this_one_is_failing():
    assert comment_above == ast.unparse(ast.parse(comment_above))

Hello @hovi. I think it's expected behavior.
Docstring is a simple string constant + it's the first Constant node in a Module, FunctionDef, etc. (actually there is no need for a multiline string here. Any string will be considered as a docstring).
When you place a node before a docstring (any node, including Comment node), the string ceases to be a docstring. That's why it's unparsed as a regular string. I'm not sure that Comment nodes should change this rule.
Also, parse-unparse roundtrips with your examples still provide (tree-)equivalent source code.
import test_unparse

test_unparse._test_unparse(comment_below)   # no AssertionError
test_unparse._test_unparse(comment_above)   # no AssertionError


Falha ao entrar no modo de foco

Describe the bug
Please provide as much information as you can.
Did this error occur while using dotnet try or online?

[ ] dotnet-try
[ ] .NET Jupyter Notebook
[X ] online

What kind of error was it?

[ X] User Interface (UI):  For example the output never displayed
[ ] Service Error: For example "The service is temporarily unavailable. We are working on it"
[ ] Other:

Screenshots
If applicable, add screenshots to help explain your problem.

Please complete the following:

OS

[ X] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[X ] Chrome
[ ] Edge
[ ] Safari

Fica carregando e carregando mas nada de funcionar....


No visibility on validation issue deserialization failure in Gallery

See https://github.com/NuGet/NuGetGallery/pull/6105#discussion_r199231938
Basically, the Gallery deserializes ValidationIssues from the validation DB. If the Gallery's references to NuGet.Services.Validation become outdated, the Gallery will fail to deserialize issues and will show invalid issues for a package.
Because we are missing logging/telemetry for ValidationIssue deserialization, we won't be alerted if there are any issues. We should add logging/telemetry for this.

Dupe of https://github.com/NuGet/NuGetGallery/issues/6124


Add rosdep key for gazebo7 in Xenial

@scpeters or @j-rivero or whoever--does this look correct to you?

If you do it like this then you also need an entry for Wily.

Mmkay. It looks like gazebo5 is the version in Wily: https://launchpad.net/ubuntu/wily/+source/gazebo

We've already discussed the fact that a newer version will have to be back ported: https://github.com/ros-infrastructure/rep/pull/106#issuecomment-147841656

ahh, ok thanks. I'll change it

I think it has to be gazebo7 for Wily as well as Xenial.

We also need libgazebo7-dev. Should we make new keys or make the gazebo key point to different versions of gazebo? For jade, we made new keys (#8243). Also, I think wily has gazebo6, but @j-rivero is working on back-porting the gazebo7 from xenial to wily.

2f39a49 adds the libgazebo7-dev key.

Fedora doesn't have gazebo7 yet:

https://apps.fedoraproject.org/packages/gazebo

cc @cottsay @jpgr87

indeed... https://bugzilla.redhat.com/show_bug.cgi?id=1247414
I propose I remove the Fedora entry and add Fedora support later. We need this to start pull request testing gazebo_ros_pkgs on the buildfarm, which doesn't build for Fedora anyway. Does that sound ok?

that's what we did for FCL in #10874, sounds ok to me

Gazebo 7 isn't in Debian Jessie yet, either. Not sure what to do about that (@tfoote, is Gazebo important to you for the Turtlebot stack? I assume you're prioritizing the on-robot software...).

Gazebo 7 isn't in Debian Jessie yet,

Jessie is a released distribution so it won't be in the official distribution.

Jessie is a released distribution so it won't be in the official distribution.

It could be backported or put into a ROS PPA equivalent. I'm not sure what they've done in the past.

It could be backported or put into a ROS PPA equivalent. I'm not sure what they've done in the past.

Gazebo is not present into any released Debian distro. it has been present in current testing (will be the next released distro) and unstable (rolling).

We can probably get Gazebo 7 in Fedora 24 (due out in early June), and definitely get it in Fedora 25+.  We stuck with Gazebo 6 in the current releases so we didn't get too far ahead of the Ubuntu packages, but if there's a case for Gazebo 7 in the F24 time frame we can try to make that happen.


Expose information about publisher presence from the subscriber SDK

The subscriber API should expose the information whether the publisher is present in the channel or not.
Android PR for reference: https://github.com/ably/ably-asset-tracking-android/pull/754
┆Issue is synchronized with this Jira Uncategorised by Unito

@KacperKluka I'm going to start implementing this but I'm a little bit confused about the motivation behind this new API. Would you mind explaining what kind of use case we have in mind for it, and when somebody might wish to use it instead of the existing Subscriber.trackableStates API? I'm particularly confused since the video on https://github.com/ably/ably-asset-tracking-android/pull/754 always shows the trackable state label and the presence label as showing the same value.

It was added in order to enable customers to detect when the publisher is present. They might want to know that because if the publisher is not present they could use some other tracking solutions or perform other fallback logic.
I agree that at the moment the same information could be inferred from the TrackableState object, however, the logic behind TrackableState might change in the future so having this option in the API doesn't seem like a bad idea.


pull request for e2e test at 02/06/2017 00:26:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Publish updates from master

PR to sync updates from master

Needs another approval due to the additional commit. :)


How many decoder layer needs to add in EAGLE?

Thanks for the great work. I find a different between code and paper
In the paper, it say eagle trains a decoder layer.
In the code, cnet.py class Model (https://github.com/SafeAILab/EAGLE/blob/main/model/cnets.py#L491)
self.layers = nn.ModuleList([LlamaDecoderLayer(config, index) for index in range(config.num_hidden_layers)])
It needs to add a decoder layer for every hidden layer.
Please tell me which one is correct.
Best regards

This config is not the config file in your llm directory, check the config.json in your ea_model_path, config.num_hidden_layers should be 1.

Thanks for the response.
If I need to train eagle on different LLM, I think I should prepare different config file.
I just need to copy the config from the LLM I want to train on and change the num_hidden_layers to 1, right?

Not 100% sure, you better check the code in train/main.py

If I need to train eagle on different LLM, I think I should prepare different config file. I just need to copy the config from the LLM I want to train on and change the num_hidden_layers to 1, right?

You are right.

I find a different between code and paper.

Thank you for your interest. As @cyLi-Tiger  mentioned, the configuration of EAGLE is different from the base LLM.


Must field values be non objects/arrays?

This might be a duplicate of #360 and/or #365.
Is it possible to have a field with an object value? It's not deep or nested. I just want to be able to have a field with an object as a value. It works correctly when I return an object on onChange(). The value I get when the form is submitted is an object. But it does not work when I have the value in initialValues.
The following test works where the photo field has an object value. Indicating that it should be possible?
describe('getValues', () => {
  it('should get values from form', () => {
    const form = {
      foo: {value: 'bar'},
      catLives: {value: 9},
      alive: {value: true},
      nullValue: null,
      photo: {value: {alt: 'text', url: '//example.com/img.jpg'}}
    };
    const fields = ['foo', 'catLives', 'alive', 'nullValue', 'photo'];
    expect(getValues(fields, form))
      .toBeA('object')
      .toEqual({
        foo: 'bar',
        catLives: 9,
        alive: true,
        nullValue: null,
        photo: {alt: 'text', url: '//example.com/img.jpg'}
      });
  });
});

But it looks to me like there is a potentially conflicting test intended for deep forms.
https://github.com/erikras/redux-form/blob/master/src/__tests__/initializeState.spec.js#L32-L61
Thanks!

I'm not sure what was wrong with my initialValues but I figured out how to get it to work like I wanted.

@webmasterkai : Could I ask how?

It's possible my code wasn't correctly checking for defaultValue and was only looking at value. Other than that I'm not entirely sure.

Yes, you should be able to have an object or an array as your value, but that is broken at the moment. #360.

same problem~~ after update to v3.1.7

This should be fixed in v4.0.0. Come and get it!


BUG course page saying all assignments are not visible (when some are and some are not)

It is something to do with the AssignmentItem component on the course page /course?courseId=<course id hash>. The AssignmentItem component is likely just missing the visible_to_students field

Course Page: https://github.com/AnubisLMS/Anubis/blob/master/web/src/pages/core/public/Course/Course.jsx
AssignmentItem Component: https://github.com/AnubisLMS/Anubis/blob/master/web/src/components/core/AssignmentItem/AssignmentItem.jsx

Please make sure to follow the contribution guidelines established here: https://github.com/AnubisLMS/Anubis/blob/master/.github/CONTRIBUTING.md


Added support for numeric header names

Hello
As discussed at https://github.com/Nyholm/psr7-server/issues/35, here are some changes that seem to solve the problem.
This may be a premature PR, but it was the easiest way for me to demonstrate a cohesive solution with tests that works. @Zegnat did most of this, I just put it together.

Thank you.
If this library (or the PSR specification) was PHP 7.2+. It would have a type hint for string on withAddedHeader. In fact, the PSR specify that the $header should be a string.
I dont think it is a good idea to convert an integer to a string. I think it is the callee (nyholm/psr7-server in this case) that should make sure it si giving a string to the withAddedHeader function.

Hm.. I see. So if we do ->withAddedHeader('0', 'foo'), we will convert that to an int because it is used as an array key.. hm.

Squashed.

Hey guys
Can we merge this in and update the dev-dependencies of https://github.com/Nyholm/psr7-server/pull/36/files? The tests over there require this component to be updated as psr7-server uses it for tests which fail on that PR because of this.

Yes, This should be merged. Thank you

I just added another test of getHeader() and getHeaderLine() with a value of 0, just to future-proof this edge-case.

Hey guys
Can we get this released so we can complete https://github.com/Nyholm/psr7-server/pull/36? I cannot fix the errors I get in my API without this, unless I switch to a different PSR7 implementation which I would like to avoid having to toy with at the moment.
@Nyholm @Zegnat


Add support for environments in Vault

We want to be able to use a single Vault server for multiple environments. Currently, Dynaconf does not support multiple environments in Vault.
This PR adds the working environment into the path, so that the same Vault server can be used for multiple environments.

Converted os.path.join() to '/'.join() as Vault only uses / and this would cause Dynaconf on Windows to provide an incorrect path to Vault.

Also there is this error on Travis CI https://travis-ci.org/rochacbruno/dynaconf/jobs/500591773

I am curious about this use case, are you guys changing environment on the fly? using settings.setenv/using_env ?
In other scenarios I have only used the variable exporting different path example:
export VAULT_PATH_FOR_DYNACONF=/secret/data/SOMETHINGELSE

Yes, we're changing the environment on the fly using ENV_FOR_DYNACONF. Having do use both ENV_FOR_DYNACONF and VAULT_PATH_FOR_DYNACONF is a bit burdensome (especially if people don't get the Vault path right).
I'm busy looking into the error in Travis. I can reproduce it, but I am not sure why it is happening.

Hello @rsnyman! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file dynaconf/loaders/vault_loader.py:

Line 70:80: E501 line too long (86 > 79 characters)
Line 119:80: E501 line too long (94 > 79 characters)


How do you disable tracing some requests in Rails?

I'm adding the X-Ray SDK to a Rails application, and I'm struggling with understanding how to disable tracing for some requests. I've figured out that you can use the sampling feature for this, for some situations, however not for my case.
We have monitoring that hits the root route of the application, and this creates a lot of noise in X-Ray and we really would prefer to not have those traces at all. What I would need in order to use the sampling feature to disable tracing for these requests is an ability to look at the user agent, but that doesn't seem to be supported.
It seems like an easy fix, and I would be happy to submit a PR for that, but it also seems to me that sampling and disabling are different things. If I didn't use the X-Ray SDK's middleware, I would simply just not start a segment for the requests I didn't want to trace (this is in fact what we do in non-Rails applications where we don't use the X-Ray SDK).
Is sampling really the way to go to solve this, or is there another way I haven't figured out?

The SDK right now can only do sampling rule matching based on http method, path and host. We will take this as a feature request to add user agent as part of sampling rule configuration.
The only workaround is to pass your own sampler that implement the sampler interface https://github.com/aws/aws-xray-sdk-ruby/blob/master/lib/aws-xray-sdk/sampling/sampler.rb. That way you can pass custom rules that contains user agent, and the sampler do the matching based on user agent.
The other possible option is to have a separate path /healthcheck so you can use all the built-in functionality. This has been a go-to solution for a lot of users need to disable tracing on health check. Could you let me know if this is feasible for your use case?

Could you explain more how the workaround would work? It looks to me like the blocker is that the information given to the sampler is fixed (see https://github.com/aws/aws-xray-sdk-ruby/blob/24b478e3261ea4bb4cc3e042a4d7b66c50570217/lib/aws-xray-sdk/facets/rack.rb#L30-L32) and implementing my own sampler wouldn't change that, would it? I understand that I can pass any information I want to the custom sampler when it is created, but the user agent of a request won't be known at the time the sampler is created.
Having a separate path for these checks is not an option unfortunately – there are other monitoring requests that go to a specific path that's easily identifiable and I've already disabled tracing for those using the method you described, but there are monitoring requests where that is not applicable, unfortunately.
Would you be open to a PR that added the Rack env to the information passed to the sampler?

Yes. As long as it doesn't break the sampler functionality for non-Rack applications.


Add parameter to disable profilers

Credit @tommydcjung for the seed of this idea.
This is necessary for two ongoing projects: The network simulator where there are no tiles to bind to, and SAIF generation where the profilers cause VCS to crash.

with regards to #664  can we add a warning somewhere to state that the profiler and saif generation can't be used at the same time. I can also modify my changes to use the new parameter to make sure that saif is disable while profiling

with regards to #664  can we add a warning somewhere to state that the profiler and saif generation can't be used at the same time. I can also modify my changes to use the new parameter to make sure that saif is disable while profiling

yeah, one thing we may want to do is have a parameter that enables saif generation. If both parameters are set, multiple errors/warnings would occur.

yeah, one thing we may want to do is have a parameter that enables saif generation. If both parameters are set, multiple errors/warnings would occur.

We don't want to run VCS with -debug_pp. It's pretty hefty hit for simulation speed.

We don't want to run VCS with -debug_pp. It's pretty hefty hit for simulation speed.

Just to summarize, we discussed, it is better to keep it out of the
Makefiles since it is not machine configuration state and will lead to a
proliferation of files. However we should generate separate binaries (or at
least ones with different names) to avoid accidentally forgetting to blow
away a stale binary with a non current set of params baked in.
On Thu, Jan 14, 2021 at 8:50 AM mrutt92<EMAIL_ADDRESS>wrote:

@mrutt92 commented on this pull request.
In machines/baseline_32_16/Makefile.machine.include
https://github.com/bespoke-silicon-group/bsg_replicant/pull/666#discussion_r557541506
:

@@ -55,6 +55,9 @@ BSG_MACHINE_IO_EP_CREDITS             = 16
BSG_MACHINE_IO_HOST_CREDITS           = $(BSG_MACHINE_IO_EP_CREDITS)
BSG_MACHINE_IO_REMOTE_LOAD_CAP        = $(BSG_MACHINE_IO_EP_CREDITS)

+# (Don't) Instantiate Profilers (needed for SAIF generation, DPI Tile)
+BSG_MACHINE_NOINST_PROFILERS          = 0
Sure. But now that I'm thinking about this, here's an argument for keeping
the flag in the Makefile.machine.include instead of some random option:
People know how to find/use the Makefile.machine.include.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bespoke-silicon-group/bsg_replicant/pull/666#discussion_r557541506,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEFG5ADYJYEPYRCT3HEPTSDSZ4OFFANCNFSM4WBOJILQ
.

Just to summarize, we discussed, it is better to keep it out of the
Makefiles since it is not machine configuration state and will lead to a
proliferation of files. However we should generate separate binaries (or at
least ones with different names) to avoid accidentally forgetting to blow
away a stale binary with a non current set of params baked in.
On Thu, Jan 14, 2021 at 8:50 AM mrutt92<EMAIL_ADDRESS>wrote:

@mrutt92 commented on this pull request.
In machines/baseline_32_16/Makefile.machine.include
https://github.com/bespoke-silicon-group/bsg_replicant/pull/666#discussion_r557541506
:

@@ -55,6 +55,9 @@ BSG_MACHINE_IO_EP_CREDITS             = 16
BSG_MACHINE_IO_HOST_CREDITS           = $(BSG_MACHINE_IO_EP_CREDITS)
BSG_MACHINE_IO_REMOTE_LOAD_CAP        = $(BSG_MACHINE_IO_EP_CREDITS)

+# (Don't) Instantiate Profilers (needed for SAIF generation, DPI Tile)
+BSG_MACHINE_NOINST_PROFILERS          = 0
Sure. But now that I'm thinking about this, here's an argument for keeping
the flag in the Makefile.machine.include instead of some random option:
People know how to find/use the Makefile.machine.include.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bespoke-silicon-group/bsg_replicant/pull/666#discussion_r557541506,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEFG5ADYJYEPYRCT3HEPTSDSZ4OFFANCNFSM4WBOJILQ
.

yep. Good to record our consensus.

yep. Good to record our consensus.


Allow cli build to push images to local container runtime

Closing since it seems not very useful right now


comment inside of empty enum variant payload with explicit discriminant results in invalid syntax after rustfmt run

Example code:
#[repr(u8)]
enum MyEnum {
    MyVariant {
        /* Comment */
    } = 0,
}

This compiles fine.
rustfmt 1.5.2-nightly (50d3ba5 2023-02-04) inserts a line:
#[repr(u8)]
enum MyEnum {
    MyVariant {
        /* Comment */
        } =
    } = 0,
}

This is a syntax error:
error: unexpected closing delimiter: `}`
 --> src/main.rs:7:1
  |
3 |     MyVariant {
  |               - this delimiter might not be properly closed...
4 |         /* Comment */
5 |         } =
  |         - ...as it matches this but it has different indentation
6 |     } = 0,
7 | }
  | ^ unexpected closing delimiter

Thank you for the report!
For anyone interested in working on this, these types of bugs are almost always caused by an incorrect span derivation that only becomes problematic in the presence of comments. In this case it's an empty struct so I'd suggest taking a look in this general vicinity:
https://github.com/rust-lang/rustfmt/blob/5391847ea5a12262704657a0708b1674fb344403/src/items.rs#L1328-L1332
I suspect that the issue is with the construction of that inner span, and the hi value used (the second arg to the mk_sp call) should instead be the hi bytepos from before the last }

@Swiiz thanks for reaching out! That's definitely a bug.
Could you please open up a new issue for that case. Although the result is similar the error is occurring in a different context (struct generics vs enum explicit discriminant) and therefore is a distinct issue.

@Swiiz following up here. The issue that you pointed out is a duplicate of #5358, and the fix was released in rustfmt v1.5.2.


Don't test on ruby 1.9.3

Because Sidekiq does not already support MRI 1.9
https://github.com/mperham/sidekiq/blob/v3.3.4/lib/sidekiq.rb#L3

Coverage decreased (-0.21%) to 91.27% when pulling 0ac90d050f8fc5805cef06f4936694e35e05e382 on sue445:feature/drop_ruby_1_9 into 29d3b879e25f69d0e40addd71fd0011ce49ad5fb on ondrejbartas:master.

:heart:


gadgets: Port trace_fsslower to image-based

This PR ports the fsslower gadget to work as image based one.
Because of performance reasons the fsslower gadget allows to attach to a specific filesystem at once. This is specified by a parameter passed by the user.
This PR uses the following support to make all of it work:

Wasm modules can define and access parameters (#3449)
The attach point of an eBPF program can be set by using an annotation
Wasm modules can set annotations on different objects in the config (#3475)
Because of a "race condition", image operators now support the PreStart and PostStop hooks too

The whole workflow is:

Init(): The wasm module of the gadget defines a new parameter
PreStart(): The wasm module of the gadget reads the parameter and sets the attach_to annotation on the different ebpf programs
Start(): The eBPF operator uses the annotation to attach the programs to the right point

Testing
Use the gadget with different filesystems and verify it's reporting events
Note
Some parts of this PR will be moved to independent PRs. Please review those parts there.

[ ] #3449
[ ] #3475

TODO

[ ] Guide for k8s

Fixes #2994

Discussion
I was taking to @flyth about a possible different implementation for this PR. Let's compare the two different ideas we have now:
Handle parameter in WASM
(This PR + #3449 + #3475)
The parameter is defined in the metadata file (following the discussion in https://github.com/inspektor-gadget/inspektor-gadget/pull/3449#discussion_r1755160160) and then the gadget uses WASM for reading the parameters and setting the annotations on the programs. This is the full program for reference:
package main

import (
	api "github.com/inspektor-gadget/inspektor-gadget/wasmapi/go"
)

type fsConf struct {
	read   string
	write  string
	open   string
	fsync  string
	statfs string
}

var fsConfMap = map[string]fsConf{
	"btrfs": {
		read:   "btrfs_file_read_iter",
		write:  "btrfs_file_write_iter",
		open:   "btrfs_file_open",
		fsync:  "btrfs_sync_file",
		statfs: "btrfs_statfs",
	},
	"ext4": {
		read:   "ext4_file_read_iter",
		write:  "ext4_file_write_iter",
		open:   "ext4_file_open",
		fsync:  "ext4_sync_file",
		statfs: "ext4_statfs",
	},
	"fuse": {
		read:  "fuse_file_read_iter",
		write: "fuse_file_write_iter",
		open:  "fuse_open",
		fsync: "fuse_fsync",
	},
	"nfs": {
		read:   "nfs_file_read",
		write:  "nfs_file_write",
		open:   "nfs_file_open",
		fsync:  "nfs_file_fsync",
		statfs: "nfs_statfs",
	},
	"ntfs3": {
		read:  "ntfs_file_read_iter",
		write: "ntfs_file_write_iter",
		open:  "ntfs_file_open",
		fsync: "generic_file_fsync",
	},
	"xfs": {
		read:   "xfs_file_read_iter",
		write:  "xfs_file_write_iter",
		open:   "xfs_file_open",
		fsync:  "xfs_file_fsync",
		statfs: "xfs_fs_statfs",
	},
}

//export gadgetInit
func gadgetInit() int {
	err := api.NewParam(&api.Param{
		Key:          "filesystem",
		Description:  "Filesystem to trace",
		DefaultValue: "ext4",
		TypeHint:     "string",
		Title:        "Filesystem",
		Alias:        "f",
		IsMandatory:  false,
	})
	if err != nil {
		api.Errorf("failed to create new param: %s", err)
		return 1
	}

	return 0
}

//export gadgetPreStart
func gadgetPreStart() int {
	value, err := api.GetParamValue("filesystem")
	if err != nil {
		api.Errorf("failed to get param value: %s", err)
		return 1
	}

	config, ok := fsConfMap[value]
	if !ok {
		api.Errorf("filesystem %s not supported", value)
		return 1
	}

	api.SetAnnotation("programs.ig_fssl_read_e", "attach_to", config.read)
	api.SetAnnotation("programs.ig_fssl_read_x", "attach_to", config.read)
	api.SetAnnotation("programs.ig_fssl_wr_e", "attach_to", config.write)
	api.SetAnnotation("programs.ig_fssl_wr_x", "attach_to", config.write)
	api.SetAnnotation("programs.ig_fssl_open_e", "attach_to", config.open)
	api.SetAnnotation("programs.ig_fssl_open_x", "attach_to", config.open)
	api.SetAnnotation("programs.ig_fssl_sync_e", "attach_to", config.fsync)
	api.SetAnnotation("programs.ig_fssl_sync_x", "attach_to", config.fsync)
	api.SetAnnotation("programs.ig_fssl_statfs_e", "attach_to", config.statfs)
	api.SetAnnotation("programs.ig_fssl_statfs_x", "attach_to", config.statfs)

	return 0
}

func main() {}

Handle parameters in the matadata file
(https://github.com/inspektor-gadget/inspektor-gadget/tree/mauricio/tracefsslower-option-2 + #3485)
The support in #3485 is used to define the parameters and set the annotations on the programs. This is the parameters definition in the metadata file used by the gadget:
  custom:
    filesystem:
      key: filesystem
      defaultValue: ext4
      description: Filesystem to trace
      title: Filesystem
      alias: f
      values:
        ext4:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: ext4_file_read_iter
              ig_fssl_read_x:
                annotations:
                  attach_to: ext4_file_read_iter
              ig_fssl_wr_e:
                annotations:
                  attach_to: ext4_file_write_iter
              ig_fssl_wr_x:
                annotations:
                  attach_to: ext4_file_write_iter
              ig_fssl_open_e:
                annotations:
                  attach_to: ext4_file_open
              ig_fssl_open_x:
                annotations:
                  attach_to: ext4_file_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: ext4_sync_file
              ig_fssl_sync_x:
                annotations:
                  attach_to: ext4_sync_file
              ig_fssl_statfs_e:
                annotations:
                  attach_to: ext4_statfs
              ig_fssl_statfs_x:
                annotations:
                  attach_to: ext4_statfs
        btrfs:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: btrfs_file_read_iter
              ig_fssl_read_x:
                annotations:
                  attach_to: btrfs_file_read_iter
              ig_fssl_wr_e:
                annotations:
                  attach_to: btrfs_file_write_iter
              ig_fssl_wr_x:
                annotations:
                  attach_to: btrfs_file_write_iter
              ig_fssl_open_e:
                annotations:
                  attach_to: btrfs_file_open
              ig_fssl_open_x:
                annotations:
                  attach_to: btrfs_file_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: btrfs_sync_file
              ig_fssl_sync_x:
                annotations:
                  attach_to: btrfs_sync_file
              ig_fssl_statfs_e:
                annotations:
                  attach_to: btrfs_statfs
              ig_fssl_statfs_x:
                annotations:
                  attach_to: btrfs_statfs
        fuse:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: fuse_file_read_iter
              ig_fssl_read_x:
                annotations:
                  attach_to: fuse_file_read_iter
              ig_fssl_wr_e:
                annotations:
                  attach_to: fuse_file_write_iter
              ig_fssl_wr_x:
                annotations:
                  attach_to: fuse_file_write_iter
              ig_fssl_open_e:
                annotations:
                  attach_to: fuse_open
              ig_fssl_open_x:
                annotations:
                  attach_to: fuse_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: fuse_fsync
              ig_fssl_sync_x:
                annotations:
                  attach_to: fuse_fsync
              #TODO: missing statfs?
        nfs:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: nfs_file_read
              ig_fssl_read_x:
                annotations:
                  attach_to: nfs_file_read
              ig_fssl_wr_e:
                annotations:
                  attach_to: nfs_file_write
              ig_fssl_wr_x:
                annotations:
                  attach_to: nfs_file_write
              ig_fssl_open_e:
                annotations:
                  attach_to: nfs_file_open
              ig_fssl_open_x:
                annotations:
                  attach_to: nfs_file_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: nfs_file_fsync
              ig_fssl_sync_x:
                annotations:
                  attach_to: nfs_file_fsync
              ig_fssl_statfs_e:
                annotations:
                  attach_to: nfs_statfs
              ig_fssl_statfs_x:
                annotations:
                  attach_to: nfs_statfs
        ntfs3:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: ntfs_file_read_iter
              ig_fssl_read_x:
                annotations:
                  attach_to: ntfs_file_read_iter
              ig_fssl_wr_e:
                annotations:
                  attach_to: ntfs_file_write_iter
              ig_fssl_wr_x:
                annotations:
                  attach_to: ntfs_file_write_iter
              ig_fssl_open_e:
                annotations:
                  attach_to: ntfs_file_open
              ig_fssl_open_x:
                annotations:
                  attach_to: ntfs_file_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: generic_file_fsync
              ig_fssl_sync_x:
                annotations:
                  attach_to: generic_file_fsync
              #TODO: missing statfs?
        xfs:
          applyConfig:
            programs:
              ig_fssl_read_e:
                annotations:
                  attach_to: xfs_file_read_iter
              ig_fssl_read_x:
                annotations:
                  attach_to: xfs_file_read_iter
              ig_fssl_wr_e:
                annotations:
                  attach_to: xfs_file_write_iter
              ig_fssl_wr_x:
                annotations:
                  attach_to: xfs_file_write_iter
              ig_fssl_open_e:
                annotations:
                  attach_to: xfs_file_open
              ig_fssl_open_x:
                annotations:
                  attach_to: xfs_file_open
              ig_fssl_sync_e:
                annotations:
                  attach_to: xfs_file_fsync
              ig_fssl_sync_x:
                annotations:
                  attach_to: xfs_file_fsync
              ig_fssl_statfs_e:
                annotations:
                  attach_to: xfs_fs_statfs
              ig_fssl_statfs_x:
                annotations:
                  attach_to: xfs_fs_statfs

I don't have a strong opinion on any of the solutions. I feel WASM is more flexible, but more difficult to implement and to use and the metadata-based solution is less flexible but easier to implement and to use.
Are there any other opinions on this? @alban  since you participated on the other PR.

I prefer the first solution with Wasm too because it is more flexible. For example:

kallsyms: In this fsnotify gadget issue, we need to look at kallsyms from Wasm, and based on the symbols we find, decide which bpf programs to attach. This is not related to a parameter from the gadget metadata.
BTF: In the profile_blockio gadget (program.bpf.c#L119-L129), we could attach the bpf programs differently based on the kernel BTF.
Architecture: the Wasm module could decide to attach the bpf programs differently based on the architecture (arm64 / amd64) like we used to do in the trace-exec gadget (execsnoop.bpf.c#L138-L144). The metadata file is not flexible enough to discriminate on the architecture.

To implement all of the above, we just need to add Wasm helper functions in wasmapi to get kallsyms, btf, the architecture. But all those additions would be independent of each other. If we were to implement the above in the metadata file, I think it would be come quite contrived and complex every time we add something.

Just to be clear: for me this is not a either/or question, I think in the end we should provide both solutions. WASM for complex situations that need decisions to be made at runtime and the metadata approach for easier things that can be done in a more declarative way (presets of configs and such).
I pushed the metadata solution a bit to give a quick solution for this gadget specifically and to buy us some time to think more about the requirements for the WASM API, as there were still some discussions ongoing around it. My general stance, though, is that - whenever possible - we should avoid the overhead of using WASM and opt for the declarative way. But we also need examples for both ways, so I also don't have a strong preference about what to start with.

After thinking more about it, I'd like to go with the wasm support first. It seems there are other uses cases we want to handle now too, so it's time to have that support. Later on we can switch this gadget to use the declarative way if we want to.
We can already review #3475 and #3449, IMHO they are generic enough to be useful for different cases.

@eiffel-fl thanks for the review. Unfortunately I found out that it wasn't working for filesystems like fuse because it doesn't define attach points for some operations. I had to introduce a way to disable attaching some programs. Could you check this again please?
cc @alban perhaps this support is interesting for you as well.

Moreover, I have issues at runtime:

Did you recompile ig?

Tests failures aren't related to this PR.
I'm merging it now, I would handle any more comments on a new PR is needed.


fix(ansible): current duplicated word

Description
This is horrible.
Type of change
Please select the appropriate options:

[ ] Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] I have performed a self-review of my own code

:tada: This PR is included in version 1.4.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Unable to provide model-specific already_authenticated i18n key

en:
  devise:
    failure:
      already_authenticated: "You are already signed in."
      user:
        already_authenticated: ""

The latter with empty string is merely ignored. I wonder if it is a bug. If it's not, I find it useful to make it work in the same way as sessions key (https://github.com/plataformatec/devise#i18n).

Hi @artur-beljajev, thanks for reporting this.
It seems like it's a bug. Inside app/controllers/devise_controller.rb, the flash accessor is being called directly instead of the #set_flash_message helper, which looks for a resource-specific translation key.
It should work if we change it to use the #set_flash_message helper, something like the following:
set_flash_message("already_authenticated", scope: "devise.failure")

Do you want to send us a patch with this fix?

@tegon is something like this?https://github.com/gurgelrenan/devise/commit/0f134f7030edbca0366f2979e9fbe48abe02edd8
I found this test https://github.com/plataformatec/devise/blob/master/test/integration/authenticatable_test.rb#L324
Do you think that I need to change the test?

@tegon is something like this?gurgelrenan@0f134f7

I think so!

Do you think that I need to change the test?

It seems like you don't need to since the test is authenticating the User model. One test that is worth writing is one that instead authenticates an Admin - there's a helper for this too - and then use a different i18n message for it.

Ok @tegon, just send a PR https://github.com/plataformatec/devise/pull/5148


feat: Avoid truncating span descriptions

For database auto-instrumented spans, the description contains potentially long SQL queries that are most useful when not truncated.
Because arbitrarily large events may be discarded by the server as a protection mechanism, we dynamically limit the description length, preserving the most important descriptions/queries.
Performance impact
Preliminary CPU profiling using [1] suggests that uuid4() dominates the execution time for code sending many transactions sequentially.
Preliminary memory profiling using [2] and looking at the max RSS of a benchmark script suggests that the max RSS has no significant change (JSON encoding in CPython is implemented in C).
In any case, we mitigate any increase in memory usage and run time for the majority of cases by avoiding any extra work when the total number of bytes consumed by descriptions do not exceed ~512 KB, which is equivalent to having the standard string truncation applied.
Integrating profiling to the SDK is left for a future PR.
[1]: https://pypi.org/project/zprofile/
[2]: /usr/bin/time -l (macOS)

Related to https://github.com/getsentry/relay/pull/674

if possible I would make this an _experiment flag for now

Could you help me with that?
I guess two if's around serializer.py would do it.


zfs: 2.1.7 → 2.1.8

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.8
2.1.9 staging always just starts at the last version cut.
Description of changes

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, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

cc @eirnym @GGG-KILLER @cole-h

Freshly booted
$ uname -srmo
Linux 6.1.7 x86_64 GNU/Linux
$ zfs --version
zfs-2.1.8-1
zfs-kmod-2.1.8-1

Commit and title are using wrong version numbers. I'd also recommend this be two commits. One to bump the versions, the other to change the default kernel.

Commit and title are using wrong version numbers

How? This is the the commit that moves OpenZFS from v2.1.17 to v2.1.18.

I'd also recommend this be two commits. One to bump the versions, the other to change the default kernel.

There is no existing precedence for this--only Linux kernel drops for when they are deprecated. Part of the 2.1.18 upgrade is support for a later maximum kernel so the version bump should be implied.

How? This is the the commit that moves OpenZFS from v2.1.17 to v2.1.18.

No, it’s 2.1.7 to 2.1.8. You’re adding an extra 1 incorrectly. Your code is correct, your descriptions are not.

No, it’s 2.1.7 to 2.1.8.

I have issues with numbers in my head, but you are 100% correct. I did not catch this.

Extra 10s digit 1 removed.


pod 'Buckets' library for swift 3

Hi ,
I'm trying to update my pod file for swift 3
I need the updated command of pod 'Buckets', '~> 1.1'

Hi,
As you probably know Swift 3 is not backwards compatible with Swift 2. So you can not use this library in swift 3 projects yet. I expect to release an updated version shortly.

waiting for this
thank you
On Wed, Nov 23, 2016 at 9:47 AM, Mauricio Santos<EMAIL_ADDRESS>wrote:

Hi,
As you probably know Swift 3 is not backwards compatible with Swift 2. So
you can not use this library in swift 3 projects yet. I expect to release
an updated version shortly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mauriciosantos/Buckets-Swift/issues/3#issuecomment-262450774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWbeB1orTwULeB-7wW0Vrjdvtw_tY9HVks5rA--hgaJpZM4K0-Ju
.

Hi,
I release an update yesterday which makes the library compatible with Swift 3. This should fix your problem.

Thank you

Thank you

Hey,
I got this problem
[!] Unable to satisfy the following requirements:

Buckets (~> 2.0) required by Podfile

On Sat, Dec 10, 2016 at 12:35 AM, Mauricio Santos<EMAIL_ADDRESS>wrote:

Hi,
I release an update yesterday which makes the library compatible with
Swift 3. This should fix your problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mauriciosantos/Buckets-Swift/issues/3#issuecomment-266142112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWbeB3lATy8Ljp_V4GDS3eLob_ofpd9jks5rGdeugaJpZM4K0-Ju
.

I updated the README file with the coocapods instructions. Please try again.


tf.data.Dataset should support attr classes instances as values

Please make sure that this is a feature request. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template
System information

TensorFlow version (you are using): 2.1.0
Are you willing to contribute it (Yes/No): Yes

Describe the feature and the current behavior/state.
Currently Datasets only support nested structures of tuples, named tuples, and dictionaries, however attr classes are also supported transparently by tf.function. Ideally, to be consistent, these should also be supported by datasets as they are the primary entry point for data in autographed functions.
Will this change the current api? How?
No
Who will benefit with this feature?
Anyone using structured data.
Any Other info.

Code for attr support in tf.function:
https://github.com/tensorflow/federated/blob/master/tensorflow_federated/python/core/utils/computation_utils.py#L47

Code for supported types in Dataset:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/data/util/structure.py#L407

A usage example that should be legit but is not:

import attr
from collections import namedtuple
import tensorflow as tf

@attr.s(frozen=True)
class DataContainer:
    data = attr.ib()

NamedDataContainer = namedtuple('NamedDataContainer', ['data'])

@tf.function
def f(x):
    return x

x = tf.constant(0.)
f(DataContainer(x)) # legit
f(NamedDataContainer(x)) # legit

dataset = tf.data.Dataset.from_tensor_slices([0., 1., 2., 3.])

dataset.map(NamedDataContainer) # legit
dataset.map(DataContainer) # not legit

Hi @jsimsa , Can I work on this?

Shouldn't this issue be closed? Or is it up for grabs still?

Shouldn't this issue be closed? Or is it up for grabs still?


Update online-lfp.rst

Updates documentation for online lfp calculation to more accurately reflect how the weights files are created

Thanks for the changes! I pinged Julian here
https://bbpteam.epfl.ch/project/issues/browse/BBPBGLIB-1100
to review the procedure and give feedback


[CSL] add extra CSL RECEIVE ahead time due to interop issue

Solves issue #8738

Doing some on-device testing.

I've built ot-cli-ftd example app on nrf52840dk and verified CSL transmission with a Nest Wifi Router.
@EskoDijk Do you want to first try the case in #8738  before merging this PR?

@Irving-cl Thanks, I had a look at the code. I think the below existing code part is still not fully clear:
    // CSL receivers would wake up `kCslReceiveTimeAhead` earlier
    // than expected sample window. The value is in usec.
    static constexpr uint32_t kCslReceiveTimeAhead = OPENTHREAD_CONFIG_CSL_RECEIVE_TIME_AHEAD;

It mention "CSL receivers would wake up" which may suggest that the receiver is immediately ready to receive. Also the name kCslReceiveTimeAhead suggests that the radio is ready to receive kCslReceiveTimeAhead us ahead of the start of the expected CSL sampling window which is not the case.  That's because the words "receive" and "ahead" are in there suggesting the receiving starts so many us ahead which is not the case.
Maybe this is more clear:  (I didn't touch the name of the config setting here - better not change that)
    // CSL radio is woken up `kCslRampupTimeAhead` earlier than
    // the radio Rx needs to be ready for the actual CSL sample window. The value is in usec.
    static constexpr uint32_t kCslRampupTimeAhead = OPENTHREAD_CONFIG_CSL_RECEIVE_TIME_AHEAD;

Superseded by #8743