Open Telemetry Support (Cloud Monitoring / Cloud Trace)

Is your feature request related to a problem? Please describe.
We would like to use Open Telemetry on GCP but cannot do so easily due to various issues with open telemetry support for dotnet in Google libraries. This has in a tough spot.

Manually instrument our libraries with the google specific bits knowing fully well that the industry (and google itself) is converging on open telemetry OR
Standardize on open telemetry and find another sink / backend for our logs.

Describe the solution you'd like
Please support open telemetry for the dotnet stack.
Additional context
Mixing and matching libraries has not been successful. Even if we use google libraries for logging and open source libraries for traces (exporting to cloud trace), the trace ids don't match up.

Assigning to Amanda for a more detailed answer, but the TL;DR is that we're aware that this is an area we could do a lot more in, and we'd definitely like to. We're busy with other work at the moment, but this is definitely on our backlog. I know that's not much of a consolation at the moment. I hope that when we eventually get to it, we'll be able to provide a nice solution that provides tracing with all the client libraries "for free" etc.

Thanks, Jon.
Also want to point that we would love to hear about any workarounds / alternative paths that we can use in the mean time. We've recently heard about the Open Telemetry Collector for example, but not sure this is a valid workaround for this.

@mayoatte Will try to get this started/done on the second half of the year, but that's a soft commitent for now. Again I'm sorry this is not a good answer for you at this moment.

Mixing and matching libraries has not been successful. Even if we use google libraries for logging and open source libraries for traces (exporting to cloud trace), the trace ids don't match up.

If the Google libraries that you are using for logging are the Google.Cloud.Diagnostics libraries, then those will attempt to use Google's own trace header by default to extract tracing context to include in the log entry. You can inject a transient Google.Cloud.Diagnostics.Common.ITraceContext that fetches the context from the Open Telemetry tracing context instead, and that will be used to append tracing information to log entries.

Thanks, Amanda.
We will try setting the trace context manually. And look forward to your open telemetry efforts.

Reassigning to @Rishabh-V as he's looking into this.

I'd really like to be able to use the standard OpenTelemetry libraries not only for instrumenting my code, but also for the export format.
I talk more about this desire here: https://github.com/open-telemetry/community/issues/984
Basically, I would like to see a way to do OpenTelemetry without having to install a single google-specific package in my application.  Instead, I should be able to configure the standard otel wire protocol exporter with a hostname that is "well known" on all google compute offerings (Cloud Run!).

@atrauzzi What we do in this repo is Google specific client and instrumentation libraries :), so we are unlikely to be of any help here. I do see where you are coming from with this request, but my point is that it is better suited for Cloud Run, AppEngine Flex etc.
Just to clarify, this issue covers one main aspect: How we are going to instrument the libraries we produce so that the telemetry they emit is OTEL compatible. The current plan is that we'll instrument using .NET standars like System.Diagnostics and Microsoft.Extensions.Logging, etc. This means that we are not inmediately concerned with what exports the telementry or how it is exported.
Let me know if this does not fully adress your comment.

hi @Rishabh-V @amanda-tarafa was just curious if there was any progress on getting opentelemetry working out of the box with Google cloud logging in C#

@bgenidy We are looking into this still. Without making any hard commitments, we expect to have at least some basic support in the next couple of months.

@atrauzzi I'll try to break down in points what I understand from your last comment here and also from the discussion in open-telemetry/community#984 are your main sources of frustration. Then we can discuss each point individually.

On the .NET Google Cloud client libraries instrumentation side, we won't be asking you to use any specific telemetry libraries, OTEL or otherwise. Our instrumentation won't even be OTEL specific. We'll rely on .NET's own standards for capturing client library telemetry (ActivitySource/Activity, ILogger, etc.), and then users of our libraries can decide where to send that telemetry to. There are two steps to this.
"Something" in your application needs to actually capture all the information that the Google Cloud libraries have stored in, say, an Activity, and "translate it" to the telemetry technology you want to use. For OpenTelemetry you would use the OpenTelemetry Nuget package to indicate that the Google Cloud libraries are a source of telemetry. Simplifying much, you'd have something like this in your application:

using OpenTelemetry;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;
...
// When configuring OpenTelemetry...
builder.Services.AddOpenTelemetryTracing(tracerProviderBuilder =>
{
    tracerProviderBuilder.SetResourceBuilder(ResourceBuilder.CreateDefault().AddService(s_serviceName))
        .AddSource("Google.Cloud.*") // Capture telemetry from .NET standard telemetry APIs and use it as an OTEL source.
        .... // All your other OTEL cofiguration, including you application code telemetry sources, etc.
});

The OpenTelemetry SDK also needs to know where to send that information to. And yes, you are right that since Google Cloud does not support native OTLP, you need a Google Cloud specific exporter.
A last issue I gather from your comments is that, when running on Google Cloud, you'd also like runtime telemetry itself to be OTEL exportable/exported.

Does this breakdown seem accurate to you? As I'll now try to identify your pain points on each of these. Note that I'm conscious that one of your pain points is that we don't seem to be working all together to make Google - OTEL integration seemless for users. We are very much working together, but when there are so many puzzle pieces is only natural that priorities and resources are not always necessarily alligned. By breaking these down I'm trying to pinpoint issues that we on the client libraries side can address inmediately, and issues were we need to work with the wider group.
Pain points for you to clarify/confirm:

From, and I quote, "Would I use a package that does some Google magic with the standard .NET abstraction in the interim? Yeah, I'd probably tinker with it." I gather this is not your prefered approach. But I don't understand why. For us this is the best approcha because it keeps the Cloud libraries as indepent as possible from telemetry technologies giving users of our libraries the chance to use whatever they prefer or are already using, and it's not tied to OpenTelemetry remaining an industry standard for ever. We are, yes, assuming that telemetry technologies that aim to be relevant to the .NET community would offer integration with .NET telemetry standards. What are the issues you see with this approach? How would ideal instrumentation look for you?
In principle this would be the minimum required for you to capture .NET Google Cloud libraries telemetry. We are still discussing how granular we want our library sources to be, how much information we'll initially capture, what will our reliance on Grpc.Net.Client own telemetry will be, etc. So I'd expect in reality that you'd have maybe a handful of similar lines of codes but nothing else. What are the issues you see with this approach? How would ideal usage look for you?
I think this is really your main pain point. And I agree with you. @jsuereth is probably in a better position than myself to talk about this point.
I think this is already somewhat possible, althouhg in my experience, what runtime telemetry is exported and how, and what can be configured or not is uneven across runtimes. I'm not certain we could ever get to a fully standardized telemetry experience across runtimes, but what would probably help here is a list of mayor pain points per runtime and/or the most painful disparities across runtimes. That would be helpful for each of the runtimes' teams to evaluate, prioritize and coordinate the work.

Let me know if I'm missunderstanding or missrepresenting your concerns.

@atrauzzi thanks for that. Let me clarify a few points and I think we'll be fully understanding ourselfs.
I think we can now merge summary and pain points:

Good to know that we are on the same page here with standard .NET telemetry abstractions. I think the remaining confusion in "we won't be asking you to use any specific telemetry libraries" it's because when I said "we" I meant .NET Google Cloud client libraries, but you read, and rightly so, just Google. So, my point is just that the .NET Google Cloud client libraries themselves are not making you use anythings OTEL or otherwise specific. For the rest, we have point 3.
Yes, the word "stored" in "all the information that the Google Cloud libraries have stored in, say, an Activity" was a poor choice on my part. I meant what you ultimately understood, "the telemetry information the Google Cloud libraries produce and make available for further consumption through .NET standard telemetry abstractions". But other than that confusion, it seems we are in agreement here as well.
This is definetely your main pain point then, and that's the lack of OTLP support for storing your telemetry in Google Cloud. Here is where you need something Google specific. I agree with you that this is the current situation and that it is less than ideal. Again, I'm not in the best position to give updates here, I'll try to find more about it and see if there are updates to be shared.
My point with 4 is that runtimes themselves (VMs, Cloud Run, etc.) act as producers of telemetry (describing the state of the runtime) and also as exporters of the telemetry they produce. The need for Google specific technology so that runtimes export their own produced telemetry is less of a pain point here, because that technology, as far as my experience goes, is provided by the runtime itself, so you don't have to do anything. But, if you wanted to use the runtime as a source of pure OTEL telemetry (to store telemetry in other than Google Cloud, for instance) you'd probably couldn't. From some of your comments in https://github.com/open-telemetry/community/issues/984 I understood this to be a problem for you. But if it is not, then one less thing to worry about.

There's one last thing I want to clarify. This issue is about OTEL support in .NET Google Cloud Client libraries; this issue is not about OTLP Google support and it is not about OTEL support by Google runtimes. Basically, this issue covers points 1 and 2 from the summary but it does not cover points 3 and 4. This is just because this is the .NET Google Cloud client libraries repo, and it's what we on the .NET Google Cloud client libraries team can address ourselves. For points 3 and 4 (if it were to become a pain point), the responsabilities are spread across a wider group of teams. I will try to get some shareable updates for point 3, but I can't guarantee I will.

I have an update aound Google OTLP support. The expectation is that H2 2024 there should be OTLP support for trace and logs (not yet for metrics). But these are plans, there's not hard guarantees as plans may change at any time and without notice.

Is the idea there that I'll be able to simply point my applications OTLP output to some hostname visible to my Cloud Run app and Google will give me some awesome stuff to see?

Yes, you'll configure your app through standard OTEL library to send telemetry to a Google URI, and then in Google Cloud Traces and Google Cloud Logging you'll see:

All the telemetry your own code is producing.
All the telemetry your OTEL enabled dependenies are producing (like .NET Google Cloud client libraries).
All the telemetry the runtime (Cloud Run, etc.) is producing (this happens already as far as my experience goes).

Is the idea there that I'll be able to simply point my applications OTLP output to some hostname visible to my Cloud Run app and Google will give me some awesome stuff to see?

Yes, you'll configure your app through standard OTEL library to send telemetry to a Google URI, and then in Google Cloud Traces and Google Cloud Logging you'll see:

All the telemetry your own code is producing.
All the telemetry your OTEL enabled dependenies are producing (like .NET Google Cloud client libraries).
All the telemetry the runtime (Cloud Run, etc.) is producing (this happens already as far as my experience goes).

Do you know of any examples of this approach on Github that I could use as a reference?

@david-engelmann see this comment above:

I have an update aound Google OTLP support. The expectation is that H2 2024 there should be OTLP support for trace and logs (not yet for metrics). But these are plans, there's not hard guarantees as plans may change at any time and without notice.

So this is yet to be supported, so there are no examples. .NET Google Cloud libraries may be OTEL enabled sometime in the next couple of months, at that point will provide a couple of examples for configuring .NET libraries. For Google OTLP support examples you'll have to wait until at least H2 2024.

Hi @amanda-tarafa,
I've been working with a simple local .NET backend and an OTEL collector, and the .NET OpenTelemetry library here: https://github.com/open-telemetry/opentelemetry-dotnet/tree/main. I was able to get metrics and traces to show up in Cloud Monitoring/Trace, but have been unable to view logs in Cloud Logging.
Is there any estimated time on when logging might work with GCP, or should it be working at this point and I'm doing something wrong? Thank you!

@mdenend I'm sorry but the maintainers of this repo do not maintain the OTEL library you mention. We cannot speak to what works or not there, or when it will work. We also don't maintain any collectors. You might want to reach out to the maintainers of the library or the collector you are using.

hey, we are in th H2, can we expect that feature in this year?

@IRusio Yes maybe, H2 was always a soft commitment but it is still possible that we make it. We've made progress during the first half of the year, but we still have some way to go. Keep watching this issue for updates.


atuin import should support bash HISTTIMEFORMAT="%F %T "

Setup
This is a common bash config to enable storing timestamps, and is recommended by tools like hstr. It result in a history file looking like
#1627034544
ls
#1627034556
echo <<EOF
multi
line
EOF

Observed
When running atuin import bash, all the timestamps end up imported as actual commands.
Expected
atuin import should at least not confuse timestamps as commands, and ideally parse those timestamps as useful metadata.

This is fixed by #747

It almost fixes it.
The example provided by OP was something I have not considered. Turns out .bash_history can include multi-line history entries when used with here document syntax. Oh Bash, why must you be like this?
It turns out Bash's built-in Ctrl + r search has trouble interpreting this as well which is funny.  So technically my import implementation is "just as broken" as Bash's implementation 😅. (Which I guess makes it okay?)
One last bit of stupidity is that the line feed character at the end of EOF will get recorded in .bash_history too (why Bash, WHY?), so it will create an empty line. I probably should filter that. I'll make a small PR for this.


R98 Argentomagus

dev

[x] rebase once r97 is merged
[x] nsq client 1.2.0
[x] nsq client 1.2.0-M1 -> 1.2.0

qa

[x] cbor
[x] crossdomain
[x] redirect macro
[x] bouncing scheme
[x] raw location header
[x] 22017 collector date
[x] kinesis server side encryption
[x] nsq
[x] load testing

admin tasks

[x] wiki
[ ] blogpost
[ ] dates (wiki, bp, cl)

I love the name!

I don't know wtf is going on with travis but publishing errors out for stream enrich without error messages...
https://travis-ci.org/snowplow/snowplow/jobs/322933438#L3324

mmh same thing happened for spark enrich: https://travis-ci.org/snowplow/snowplow/jobs/315961847#L3998

Similar thing happened for Iglu recently - build was interrupting silently because of exit(1) in script and error message wasn't in logs. Travis disappoints me these days.


Match example ID with kaldi for CHiME6

@sw005320: This PR matches the IDs with kaldi for CHiME 6.
I only changed it for CHiME-6, because I do not want to make a breaking change for CHiME 5.
When jenkins finished testing this PR, I will do the merge.

Jenkins test was successful.


Synchronise the Amule Connection to avoid multiple requests to intersect

:tada: This PR is included in version 1.0.3 :tada:
The release is available on:

GitHub release
v1.0.3

Your semantic-release bot :package::rocket:


Add all parameters to logging

Add all parameters to logging so we can see what parameters were run in the crash log. Once we switch to config files, we need to log those instead/as well.

Resolve in #60


Dead links

All three links in the What's next section in the inline page are dead/broken/not working and show github 404 when clicked

Your link is broken too :D We use those MD files to build https://developer.typeform.com/embed/  and links work there. Maybe we need to better communicate the docs are meant to be read there, but this is not a bug.


Simple way to fix  #158

Signed-off-by: Ru Chern Chong<EMAIL_ADDRESS>

I don't want to pull in both of those dependencies since they're huge.


ISPN-8200 StringBasedStoreMultinodeIT.testFetchState failure

Caused by test logic depending on eviction order.
https://issues.jboss.org/browse/ISPN-8200

http://ci.infinispan.org/job/Infinispan/job/PR-5375/2/testReport/org.infinispan.server.test.cs.jdbc.multinode/StringBasedStoreMultinodeIT/testFetchState/

@tristantarrant I removed most of the eviction ordering logic, but then added a little myself :see_no_evil:. It should be right now

@ryanemerson @tristantarrant TBH I'd remove the eviction check completely, as there should be plenty of tests in core checking that eviction happens correctly, but this is good enough ;)

Pushed to master


feat: update to Debian 12 (bookworm)

closes #937

Issue
Cypress Docker Images are currently built based on debian:bullseye-slim (Debian 11) from https://hub.docker.com/_/debian
https://github.com/cypress-io/cypress-docker-images/blob/b9525720b9e4e44ee7ded7f974dae89cc0dfd6f3/factory/.env#L7-L8

This relies on using Debian 11 codenamed bullseye which is the oldstable release
Debian 12 codenamed bookworm is the current stable release and it was originally released almost one year ago on June 10th, 2023.

The Cypress Docker images need to transition to using the Debian stable release 12 (bookworm).
Changes
In factory/.env:

FACTORY_VERSION is updated to 4.0.0 since it is a major change moving from Debian 11 (bullseye) to Debian 12 (bookworm).
BASE_IMAGE is updated to debian:12-slim (long-term equivalent to debian:bookworm-slim, current equivalent to debian:12.5-slim)
FACTORY_DEFAULT_NODE_VERSION is updated to 20.13.1 LTS, released May 9, 2024 Edit: This version has now been claimed. We have to wait for the next release of Node.js to proceed.
Git version check updated to 2.39.2

Verification
On Ubunu 22.04.4 LTS, Node.js v20.13.1 LTS
Execute:
cd factory
docker compose build factory
docker compose build

and confirm that all images are built without errors or warnings.
Continue with
cd test-project
set -a && . ../.env && set +a
docker compose run test-factory-all-included

and confirm that the image builds without errors or warnings and runs successfully.
References

https://www.debian.org/releases/
https://hub.docker.com/_/debian

Local tests pass 👍🏻

CircleCI test check-factory-versions fails 👎🏻

Version mismatch, git package version: git version 2.30.2 != git version 2.39.2

https://packages.debian.org/search?keywords=git
shows
bullseye (oldstable) (vcs): fast, scalable, distributed revision control system
1:2.30.2-1+deb11u2: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x

bookworm (stable) (vcs): fast, scalable, distributed revision control system
1:2.39.2-1.1: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x

Bump expected git version for Debian 12 to 2.39.2.

Tests exhibit flake
test-image-medium-browsers-test-browsers-edge failed once with the following error. On re-run, it passed.
  Running:  2-advanced-examples/querying.cy.js                                            (13 of 20)
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.

Timed out waiting for the browser to connect. Retrying...
Missing browserCriClient in connectToNewSpec
Error: Missing browserCriClient in connectToNewSpec
    at Object.connectToNewSpec (<embedded>:4407:48611)
    at Object.connectToNewSpec (<embedded>:4407:27043)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async v.relaunchBrowser (<embedded>:4492:37697)

Exited with code exit status 1

Should we proceed with this PR? Are there any other tests needed?

@MikeMcC399 We're going to have @AtofStryker take a look if he has some time this iteration.

@jennifer-shehane

We're going to have @AtofStryker take a look if he has some time this iteration.

Very good!
I'm going to be pushing through a few clean-up PRs in the meantime. They should not affect the Debian 12 PR in content though.

Due to the planned update of Node.js in https://github.com/cypress-io/cypress-docker-images/pull/1059, this PR will need to be rebased, and it will not generate any new release, because the release process does not care about the underlying Debian version.
Putting into draft state for the moment.

I've opened a separate issue https://github.com/cypress-io/cypress/issues/29554 regarding the test flakiness. I don't expect that this can be solved by doing anything with Docker. Possibly an Electron update may help, since this is only happening in a headless environment where Xvfb comes into play.

  Running:  2-advanced-examples/storage.cy.js                                             (15 of 20)

  Local Storage / Session Storage

Too long with no output (exceeded 10m0s): context deadline exceeded

@AtofStryker
What do you think about merging this PR?

@AtofStryker
What do you think about merging this PR?

I should be able to give it a thorough review today. Sorry for the delay!

cypress/factory:4.0.0 has now been published to Docker Hub cypress/factory
The version of Debian is confirmed updated to Debian 12 (bookworm):
docker pull cypress/factory:4.0.0
docker run -it cypress/factory:4.0.0

$ docker run -it cypress/factory:4.0.0
root@14b671476f0a:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

cypress/factory is not intended to be run stand-alone and is the base for building other Cypress Docker images.
By default, any newly generated Cypress Docker images (cypress/base, cypress/browsers and cypress/included) will be based on Debian 12 (bookworm).

@AtofStryker
Thanks for your tests and the merge! It was good to see that the merge into master went without error!


*: update sysinfo version to fix undiscovered disk information

Signed-off-by: crazycs520<EMAIL_ADDRESS>
What problem does this PR solve?
As title said.
Related issue: https://github.com/GuillaumeGomez/sysinfo/issues/295
Related fix: https://github.com/GuillaumeGomez/sysinfo/pull/297
What is changed and how it works?
Related changes

Need to cherry-pick to the release branch

Check List
Tests

No code

Side effects

No

Release note

No.

LGTM

/run-cherry-picker


⚠ BCR Bot has degraded performance

In 2e5396a, BCR Bot (https://bcr.alternativasinteligentes.com/BCRApi/web/chatbot) experienced degraded performance:

HTTP code: 200
Response time: 2947 ms

Resolved: BCR Bot performance has improved in 2aaa596.


Ambient tasks to beta

This issue aims to track small chunks of work to be done to progress ambient to beta.
Using this issue
Each list entry is intended to be a small task that can be picked up by anyone interested in contributing.
These individual entries can be converted into individual issues if they need broader tracking/conversation/etc.
If you are planning to work on an issue, add your name next to it to claim it (or convert to an issue and assign to yourself)
Contributing to Ambient follows the same procedures as contributing to master, but development occurs on https://github.com/istio/istio/commits/experimental-ambient.
Please feel free to add entries by editing this comment
Tasks
Test Infra

[x] Enable branch protection for experimental-ambient (https://github.com/istio/test-infra/blob/master/prow/config.yaml) (owner: @zirain)
[x] Disable release notes test in experimental-* branches in prow configuration (https://github.com/istio/test-infra/blob/master/prow/config/experimental/istio.yaml)
[x] Get ambient integration tests running. owner: @stevenctl

Installation

[x] Split ztunnel daemonset to its own chart (owner: @zirain)
[ ] Tune various ztunnel configurations, including securityContext, rollout strategies, priorityClass, etc.
[ ] Consider running ztunnel in kube-system, or at least make it possible to (to allow priorityClass usage)

Telemetry

[ ] Support Telemetry API on waypoint/ztunnel

[ ] Logging (owner: @zirain ) #41605
[ ] Tracing (owner: @zirain ) #41656
[ ] Metrics

Certificates
Currently, ztunnel fetches certificates by using a mounted kubelet credential from the node, getting a pod's token using TokenRequest, then sending a standard request to the CA.
This has issues since kubelet credential is overly broad privileged and not portable. Additionally, the whole flow has a lot of complexity. Importing k8s libraries into ztunnel also leads to binary bloat.
Instead, we should use ztunnel's own credential to authenticate to the Istiod CA. Then, Istiod can perform the node-local check itself.

[x] Make Istiod CA allow this node-local check (owner: @howardjohn ) https://github.com/istio/istio/pull/41379

[x] CA takes Lister for Pods as input
[x] CA has a user facing config to opt-in specific service accounts to use node authentication. This should default to ztunnel's service account only.
[x] On request, if the CSR is not for "self", check if it is in "node local" auth mode. If so, check all other pods on the same node and verify at least one is running as the SA

[ ] Modify ztunnel to no longer use mount kubelet cert, and instead use its own token for all request. Can remove the TokenRequest deadcode. owner: @howardjohn
[ ] Modify ztunnel templates to no longer mount kubelet cert. owner: @howardjohn
[ ] Modify XDS generation to just encode the identity to request, not the identity+pod UID. owner: @howardjohn
[ ] Ensure no more client-go dependencies in ztunnel to help with binary sizes

CNI

[ ] CNI has been found to use high CPU/memory for small clusters. Investigate why. Likely fixed by https://github.com/istio/istio/pull/42012
[ ] Decide on long term plan for redirection in ambient (owner: @yuval-k)

Rest of the details will likely depend on resolution to ^
Ztunnel

[x] https://github.com/istio/istio/issues/40956

Rest of details will depend on resolution to ^. Once that is complete, this will be filled out
HBONE

[x] Implement HBONE for sidecars and gateways (owner: @howardjohn ) https://github.com/istio/istio/pull/41391
[ ] Make HBONE as performant as traditional Istio mTLS

General

[ ] Design how ztunnel (singleton) will interact with revisions
[ ] Code cleanup - properly use informers, controllers, etc. At some point, much of the added code was doing direct reads instead of through listers, etc

IMHO the most important task is enabling protocol support in regular istio. It doesn't make sense to have two distinct data planes at beta.

IMHO the most important task is enabling protocol support in regular istio. It doesn't make sense to have two distinct data planes at beta.

Ack, Ill add that. I have a PR that is close to being ready so I would expect it to land fairly soon

By support I mean proper evaluation of performance costs and scalability for data path support. It should not be a performance degradation, as an example.

We really should get the ambient integ suite running in CI for this branch. Reached out to @EItanya to see if theres anything special we needed for this.

Can we close this in favor of the project board: https://github.com/orgs/istio/projects/9

Agreed on closing this in favor of the board. Let me check if there is anything in here not captured by the board before closing it

Closing


Difference between ImageIter  and ImageRecordIter

I feed same train.lst and train.rec to ImageIter ImageRecordIter,
val = mx.io.ImageRecordIter(
......
batch_size          = batch_size,
data_shape          = (3, 224, 224),
label_width          = 2,
rand_crop           = True,
rand_mirror         = True)
val = mx.img.ImageIter(
......
batch_size          = batch_size,
data_shape          = (3, 224, 224),
label_width          = 2,
rand_crop           = True ,
rand_mirror         = True)
But Evalutation genetated from ImageRecordIter is extremly better.
I curious about what preprocess ImageRecordIter is doing on  a raw image

I got the similar issue. Have you found any clues?

@mli @piiswrong @tqchen This seems like a bug.............

@apache/mxnet-committers: This issue has been inactive for the past 90 days. It has no label and needs triage.
For general "how-to" questions, our user forum (and Chinese version) is a good place to get help.

@nswamy Please add 'Bug', 'Python' to this topic

@littlelid @melody-rain have you had a chance to try this out on a recent version?
its been a long time, but do you have the dataset/script that you used when you saw the issue?

@littlelid Its difficult to reproduce this issue with little information provided. I tried to reproduce this issue on Caltech dataset. Was not able to do it. Referred:
https://mxnet.incubator.apache.org/tutorials/basic/data.html#using-imagerecorditer
Didn't see any difference between images generated by ImageRecordIter and ImageIter
Used resnet 50 model for inference. Didn't see any major accuracy difference.
I will be closing this issue for now. Please reopen if closed in error or if issue still persists. Please provide script with which you saw this difference.
@sandeep-krishnamurthy Can you please close this issue? Thanks!


Enhancement: Support "+json" suffixed media types per RFC 6839

Summary
Json encoded responses in Litestar must have a media type which starts with "application/json", as can be seen https://github.com/litestar-org/litestar/blob/main/litestar/response/base.py#L388
if media_type.startswith("application/json"):
    return encode_json(content, enc_hook)

I would like this to change so that it supports "application" media types with the "+json" suffix, as described in  RFC 6839. For example, the lines could change to something like
super_type, sub_type = media_type.split("/", 1)
if super_type == "application" and (sub_type.startswith("json") or sub_type.endswith("+json")):
    return encode_json(content, enc_hook)

So that I can set the media type to, e.g., "application/problem+json" (as described here), and then json encoding would still work.
Basic Example
I would like to be able to do something like the below and have the json encoding of the response work. If I run the below app now, the schema look alright, but the endpoint gives a server error because the response encoding fails since the media type does not start with "application/json". (It is clear that this is the problem because if I change the media type to "application/json+problem", it works.)
from typing import Optional
import pydantic
import litestar
import litestar.status_codes

class ProblemDetails(pydantic.BaseModel):
    title: str
    type: str
    status: Optional[int] = None
    detail: Optional[str] = None
    instance: Optional[str] = None

@litestar.get(
    status_code=litestar.status_codes.HTTP_418_IM_A_TEAPOT,
    media_type="application/problem+json",
)
async def problem_endpoint() -> ProblemDetails:
    return ProblemDetails(title="broken", type="bad server")

app = litestar.Litestar(route_handlers=[problem_endpoint])

Drawbacks and Impact
I do not see any drawbacks. If you preserve the behavior for media types which start with "application/json", I think it should all be fine. It just extends the media types which can be encoded in responses, which is very unlikely to be problematic since I doubt many servers rely on response encoding failing.
The "+json" suffix for application media types is not uncommon. For example, the "ProblemDetails" specification is quite common. Since there is an RFC for it (RFC 6839) it is clear that this is a standard worthy to support.
Unresolved questions
No response

[!NOTE]
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard

If you would like to see an issue prioritized, make a pledge towards it!
We receive the pledge once the issue is completed & verified
This, along with engagement in the community, helps us know which features are a priority to our users.

This would be a good feature to have. It seems like you have already identified what code changes would have to be made to support this, would you want to submit a PR for this?

Sure. I would have to familiarize myself a bit with the setup and make sure I have not overlooked anything, but I'll give it a try.

Closed in #3096


Popover inside a Modal box appears behind

Bug report 🐞
Popover inside a modal box.
I'm using a modal to show a simple form. One of those fields has a popover. The problem is the popover appears behind the modal overlay, I tried to fix it modifying z-index manually without result.
Version & Environment

Version of browser: Google Chrome v100.0.4896.127 (Build oficial) (arm64)
Version of geist-ui/core: v2.3.8

Expected Behaviour
Popover inside a modal must be shown over the modal
Actual results (or Errors)
It appears behind...
I got an error:
No error, it's all about css I think...
Video capture
https://user-images.githubusercontent.com/45423661/167891098-18ecf1bb-4d61-4c65-8465-beb3b73380b3.mp4

Setting z-index to 999 in the .backdrop fixes the issue.

I have had no problemas so far


[Deploy] Gridle

Gridle Recipe
Service Name : Gridle
Link to repo   :  https://github.com/fenilgandhi/franz_gridle
Link to application : https://app.gridle.io/

I don't have access to approve pull requests, but I will advise that your repo name doesn't match the convention.
It should be franz-recipe-gridle

Ok, i have updated it. Thanks for pointing out.


Invoice issue in the 'firestore-stripe-payments' extension when setting trial period for product price

Bug report

Extension name: firestore-stripe-payments

Describe the bug
I recently updated the above extension from 0.2.3 to 0.3.2 and I am now getting errors related to invoice.paid,  invoice.payment_succeeded and invoice.upcoming.
The exact errors in firebase console are:
❗[Error]: Webhook handler for Stripe event [*] of type [invoice.payment_succeeded] failed: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string.
❗[Error]: Webhook handler for Stripe event [*] of type [invoice.paid] failed: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string.
❗[Error]: Webhook handler for Stripe event [*] of type [invoice.upcoming] failed: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string.
This is happening because the invoice.paid and invoice.payment_succeeded webhook events do not contain an payment_intent in the object
Its important to note that this occurs in case when there is free trial period with the price.

Any update when this issue will be resolved? Thanks

@jsteele-stripe The issue with invoice.upcoming still exists. The error is same as before:
"❗[Error]: Webhook handler for  Stripe event [evt_1MstlCHo1LnNEW1wIIaQgAVX] of type [invoice.upcoming] failed: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string."

@jsteele-stripe Is this issue still exists. Any help on this please.
Stripe event log says:
{
"error": "Webhook handler failed. View function logs in Firebase."
}
Firebase says
❗[Error]: Webhook handler for  Stripe event [evt_1Ov58AGrlUrEAthFjs5yTvit] of type [invoice.upcoming] failed: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string."

https://github.com/invertase/stripe-firebase-extensions/issues/616#issuecomment-2003764250


[FABG-1008] Permit the msp.SigningIdentity to return the PrivateKey Bytes

This PR is to allow the Signing Identity of an ECDSA Key to return the private key portion.  This is to allow a newly enrolled user to create a new X509 Identity.
This is the same workflow that the fabric-sdk-node follows.
Also, this change follows the same logic of the AES Key, using an exportable flag to verify if the Bytes() method should be supported or not.
This is in response to the jira issue I created: FABG-1008

@pplavetzki Thanks for your contribution. Would it be possible to squash your commits and include [FABG-1008] in your commit description.

@troyronda I tried rebasing to squash, but I think I made a royal mess of this PR.  Any guidance on how to properly do this.  Many thanks, cheers!

It would be good to add some test cases for this new functionality. As for fixing the PR, as the last resort, you can always drop this PR and create a clean one.


Fix template example 8

Description
Some necessary and optional changes to get the template example to work.
Please see the git commit messages for more context.
I kept the commits very small and ordered them in priority, where the first several ones were essential to get the examples to even work, and the later ones were just helpful and could be optional. Feel free to revert or cherry-pick individual commits if necessary (eg. the last one).
Screenshot
The header now also shows a new menu bar entry of "Change Auth" when logged in, which navigates to the shown page:

Thank you for the PR!! I have submitted DEVDOCS-3214 to have our engineering team review your PR.
Thanks again, Larry


foundry hud weblate

hi, is it possible to add your mods to foundry hud weblate for us to translate or update the translation faster? https://weblate.foundryvtt-hub.com/

I've sent through the request forms - thanks for the heads-up, seems like a good initiative.


Dashboard metrics filter popup extends beyond browser window and disappears when I try to scroll the page

When I click a filter button on the "Metrics" page of the Aspire dashboard, it pops up a checkbox list of known values of the attribute.  Depending on the size of the Web browser window and the current scrolling position, it is possible that this checkbox list popup is not fully visible, as part of it extends beyond the bottom of the browser window.  The Web browser shows a scroll bar at the edge of the window (and perhaps another scroll bar at the edge of the checkbox list popup), but when I try to scroll the page by dragging the scroll bar at the edge of the window, the scroll box does not move; and when I release the mouse button on the scroll bar, the checkbox list popup disappears.
Reproduced on Microsoft Edge 123.0.2420.53.

Picture or video?

I'm not able to reproduce this currently @KalleOlaviNiemitalo. However, @vnbaaij I did notice that FluentPopover is not respecting the AutoFocus="false" parameter set on the filter popover in this case (unable to scroll using mouse scroll), which could be causing this issue. Just want to confirm that the behavior I am seeing is an unintended issue with FluentPopover

That is not what the Autofocus parameter does. It is intended to automatically place the focus on the popover so keyboard interaction can take place (when set to true).
A popover uses an Overlay by default and that can indeed makes the background inert.

@vnbaaij is there a way to set the Overlay PreventScroll parameter on the popover, then?

No, there isn't. The FluentOverlay is internal to the FluentPopover.
But I don't think this issue is relevant anymore. I also can't reproduce it. The Filter popover dispalys in the correct location relative to the button basedon the available screen estate (ie button is at bottom of the window->Popover displays above instead of under the button)

@KalleOlaviNiemitalo (Just picked this issue at random) -- I have a question to ask you. Are you comfortable sending me a mail at<EMAIL_ADDRESS>? LMK if you'd rather some other way.

@KalleOlaviNiemitalo (Just picked this issue at random) -- I have a question to ask you. Are you comfortable sending me a mail at<EMAIL_ADDRESS>? LMK if you'd rather some other way.

I will be out on leave shortly so it would be great @KalleOlaviNiemitalo if you could add<EMAIL_ADDRESS> to the mail as well.


can not handle localpushnotification

I have tried to use local BSForegroundNotification to get local push notification. But when I touched the notification, no reaction. I use this code:
_

func application (application: UIApplication, handleActionWithIdentifier identifier: String ?, forLocalNotification notification: UILocalNotification, completionHandler: () -> Void)

_
in my AppDelegate, but it still did not happen anything.
What should I do?
Thanks.

Please read more about delegates in ios. You need to set delegate for your notification. Before you present it.


Wiki update/suggestion

Heyo, fantastic work! I just wanted to try to contribute to the wiki page here: https://github.com/kpine/zwave-js-server-docker/wiki/700-series-Controller-Firmware-Updates-(Linux)#host-update-method
Between steps 2 & 3, these steps should be added or added as one big step:

Add the "testing" branch to your apk repo list: vi /etc/apk/repositories
Press the insert key to enable edit mode in vi
Add a new line after the last line: https://dl-cdn.alpinelinux.org/alpine/edge/testing
Now save and exit vi by pressing the Escape key, and type : followed by wq
Install minicom by issuing: apk add minicom && apk add lrzsz
(former step 3)

Why are those necessary?

The script (zfw-update.sh) requires minicom and minicom depends on lrzsz in order to execute.

Right. I had instructions earlier, which I removed. It's assumed they're installed, but I can add them back. The instructions are not that complex though. https://github.com/kpine/zwave-js-server-docker/wiki/700-series-Controller-Firmware-Updates-(Linux)/f2db0d2fd474e32732bbb437c46a6746ef4fb082#preparation

Gotcha. I'm on the latest version, but these modules aren't installed for me running as a vm. :)

No problem, thanks for the feedback. I had been testing with HAOS, and the script automatically installs it, so I just forgot.

https://github.com/kpine/zwave-js-server-docker/wiki/700-series-Controller-Firmware-Updates-(Linux)/_compare/f38e8a9d21d8a139e7018ed729fac35911d4f296...5a0aee7b20589e05b5640ede05e925523330f428


Feat: Support store events handling to consume repo service Kafka messages

Use Kafka streaming to listen to kafka events and dispatch the events
Support Delete and Update store service events dispatching
Use log-kafka to represent old log(datahub) kafka component

I will try to use kafka streams test-utils to perfect the unit testing part then.

@ligangty thanks for the comments, I've added Deprecated and align the bom version.


Package registration, name, interaction with rest of ecosystem

"GPLikelihoods.jl" is currently not a registered package. This makes it more difficult than necessary for users of this package such as https://github.com/rossviljoen/SparseGPs.jl. It is overdue to register the code inside this repo.

There are concerns about too many small packages - we could move this code into a separate package - what package would that be?
This package currently has no dependency in either direction with AbstractGPs.jl - it is used by SparseGPs.jl, but could also be used e.g. by GLM implementations (such as https://github.com/JuliaStats/GLM.jl) - can we combine forces, and perhaps rename to "just" LikelihoodFunctions.jl (as proposed in https://github.com/JuliaGaussianProcesses/GPLikelihoods.jl/issues/4)?
Update: GLM.jl defines link functions in https://github.com/JuliaStats/GLM.jl/blob/master/src/glmtools.jl

I think that if we name it LikelihoodFunctions.jl, it should not lie in the JuliaGaussianProcesses organisation. But in JuliaStats or something, that would make harder for us to contribute...

Hmm yeah, that does look helpful. They've probably got more dependencies than would be ideal for us, but possibly we could try and sort that out?
It's not obvious to me that their "likelihoods" are quite what we're after.
Regarding naming the package, what about something like "ConditionalDistributions.jl", in recognition of the fact that we are, indeed, defining a load of conditional distributions and functions on them? I don't feel too strongly about the name though.

@st-- @theogf one and a bit weeks on, what are your thoughts on this problem?
My feeling is that the links look quite nice, and probably we want to try and use them, but that we probably still need our likelihoods. My inclination is therefore to go ahead and register this package.
What are your thoughts @st-- @theogf ?

It's getting a bit awkward to develop SparseGPs without this being registered, so I'd definitely be in favour of registering it

That's my inclination -- we should just register it as-is with the current name and everything, and deprecate it later if that becomes necessary for some reason.

Registration PR open: https://github.com/JuliaRegistries/General/pull/40456
If anyone continues to have a strong objection to this, we can cancel it again, but my preference would be for this to get registered and for us to crack on with development.

Did we not agree to rename it to likelihood functions?
On Tuesday, August 3, 2021, willtebbutt @.***> wrote:

Registration PR open: JuliaRegistries/General#40456
If anyone continues to have a strong objection to this, we can cancel it
again, but my preference would be for this to get registered and for us to
crack on with development.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.<
https://ci4.googleusercontent.com/proxy/cFiPKdlQn272uF9ezCqGeq4-R2Q_18apbTY3eD2LjCuP5btcz4ndCEEVd4Ww5nm4gYeloTa9Doxw9NMACV3WqcB4PXrfEeVtb-v-DV79O2IBGQFBX7oCsMQVa-QWnx06v86fedlLKfDqjize3fpC60uh3asd0R15YjG9UjejThxyP1QGaRABjfUAJ04traJX2j8KCbPG9_xZFr1eYq1pXrQBDDgr2dCO8vg7Deyw7Q=s0-d-e1-ft#https://github.com/notifications/beacon/ABL7FDYDHQSQWS3QFS3NHQDT27B6LA5CNFSM5A2BMALKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGUTOAFQ.gif>

Did we not agree to rename it to likelihood functions?

Ah, sorry, I think I understood the discussion differently from you. I thought we were going to rename LikelihoodFunctions if we joined forced with others.
Either way, we can always swap out rebrand to LikelihoodFunctions at a later date if we do generalise.

@st-- @willtebbutt I think this issue can now be closed?

Yup, I'm happy to close.


With() not considering where statement

What steps will reproduce the problem?
Try to make something like this:
Listing::find()
            ->with(['package' => function($query){
            $query->andWhere('price', '0');
            }])
            ->andWhere(['customer_id' => $this->customer_id, 'status' => 'active'])->count();

the resulted query will be like this with(rawSql):
SELECT * FROM `zzz_listing` WHERE (`customer_id`=1) AND (`status`=\'active\')
If you do this:
Listing::find()
            ->innerJoinWith('package')
            ->where(['customer_id' => $this->customer_id, 'status' => 'active', '{{%listing_package}}.price' => 0])
            ->count();

The resulted query would be:
SELECT `zzz_listing`.*
The expected result should be the same with with() as with innerJoinWith.
What do you get instead?
Additional info

Q
A

Yii version
<IP_ADDRESS>

PHP version
5.4.45

Operating system
Centos 7

Why should with and innerJoinWith give same query? They do different things for a reason.
with() is for getting eager loaded relational data for the model. Not to create a innerJoin query - which is a different thing.

@Renkas = It shouldn't. Based on the above, it seems that when calling count() it just ignores the relation and it generates a totally different query than what it suppose to create, i.e: we're expecting to see an inner join and a condition on the inner joined table but we don't.

But it should.  with() and innerJoinWith() are different methods and do different things. They are not aliases. With should not in any way interfere with a query. It's just to eager load relations. Everything is working exactly as it should.
I don't even get how can anyone misinterpret those methods? Should there be clearer documentation? The names themselves are quite self explanatory.

Maybe add a note in the docs, that with is only used to bring back the related records and does not alter the main query at all.
Right now if you look at http://www.yiiframework.com/doc-2.0/yii-db-activequerytrait.html#with()-detail it says nothing about this, moreover, it says Specifies the relations with which this query should be performed. and then gives an example like
Customer::find()->with([     'orders' => function (\yii\db\ActiveQuery $query) {         $query->andWhere('status = 1');     },     'country', ])->all();
Which can be so simply misinterpreted. Nowehere does it says that the callback that modifies the query applies to the relation only but not to the main query.

indeed withand innerJoinWith are very confusing at first contact.
I struggled with the concepts cos the method names are using the same work.
Do we really need the With word in the innerJoin method? for 2.1.x ?! It's confusing...

@twisted1919, are you willing to create pull request with improvements of the docs that are necessary in your opinion?


Incomplete?

There is a "." under Applies to: SharePoint Online
So I believe that means it's incomplete?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7000bfcf-95b0-584e-1a42-b5d5202d82e1
Version Independent ID: 00e03653-1983-a0ba-69c7-61ad80b4245a
Content: Set-SPOBrowserIdleSignOut (SharePointOnlinePowerShell)
Content Source: sharepoint/sharepoint-ps/sharepoint-online/Set-SPOBrowserIdleSignOut.md
Service: sharepoint-powershell
GitHub Login: @trent-green
Microsoft Alias: trgreen

Thanks for reporting @hwkwicre


Example without OpenTok

Is there an example on how to use it without OpenTok? Especially which HTML layout does the library expect in order to work properly. I see it mentioned in the README that it is supposed to work without OpenTok but all the code references seem to be expecting OpenTok

Yeah it should work with any elements. If you just put a bunch of video or image elements inside the container and call layout() then it will work. Do you have any specific issues?

Yeah it should work with any elements. If you just put a bunch of video or image elements inside the container and call layout() then it will work. Do you have any specific issues?


[TASK] Jikan API V4 Migration

Task Context

According to the Jikan API website: V3 is being discontinued from 1st October, 2022..
This task is to migrate the Jikan API version used within this project's code to V4.
Acceptance Criteria

Update the Jikan API call in mya.c to use the V4 API instead of the current V3 API.
Verify whether or not changing the API version requires other changes to be made within the codebase.
For example, certain API endpoints may need to be changed or the JSON payload response may be different for existing endpoints.
If migrating to V4 requires additional changes, those changes should be made such that the program works as intended with different inputs.
Additional Context

Jikan API Website: https://jikan.moe/
V3 Deprecation Doc: https://docs.google.com/document/d/172RQ9wWiXqOnGqjXrV3cxMNceiqwCjxjprSFuyLwQJM/edit?usp=sharing
V4 API Docs: https://docs.api.jikan.moe/
For any questions or discussions, join the Discord to meet and engage with other contributors!

Closing this issue since it actually looks like the Jikan API endpoint for grabbing user anime lists is now deprecated according to https://docs.google.com/document/d/1-6H-agSnqa8Mfmw802UYfGQrceIEnAaEh4uCXAPiX5A/edit
Using the official MAL API will be needed for this project to stay running.


Fix keyboard input

There are several issues with keyboard input:

the keys =-; don't work for Z9001 in the browser (is this a general 32-bit issue, or just in browser, and are there differences between browsers? -> it looks like the key_mask is deleted too early)
the last_ascii and 'AnyKeyPressed' hack in Main.cc, this leads for instance to key-repeat when Shift is keeping pressed, but was necessary to make games work
sometimes the key repeat gets stuck without pressing any keyboard keys
the yakc class needs a proper key-input method, the current method up in Main.cc is hacky and must be repeated in every other project which uses the emulator

I think a clean rewrite of the keyboard input code would make sense.

Interesting observation: in PNaCl, the keys in question (-,=,;) all produce a warning 'unhandled key code' with the key codes 186, 187 and 189, and PNaCl has the same problem in the Z9001 emu as emscripten (but only the Z9001 emu in emscripten and PNaCl has a problem with those 3 keys).

...it works on Windows compiled as 32-bit, so it's not a 64- vs 32-bit problem.

Fixed.


KeyError 'message_sender' while starting zulip_events_message_sender-{0,1,2,3}

After upgrading our Zulip instance on Debian 10 Buster to 3.0, I've encountered two issues, which resulted in Zulip working but producing a high CPU load on every core. I then noticed, that zulip-thumbor and zulip-senders:zulip_events_message_sender-{0,1,2,3} were not running in supervisorctl.
Zulip-Thumbor failed to start with the following error:
Traceback (most recent call last):
  File "/home/zulip/deployments/current/zulip-thumbor-venv/bin/thumbor", line 8, in <module>
    sys.exit(main())
  File "/srv/zulip-venv-cache/093de4c3442c3634d87062bf6faee72b80fc4e80/zulip-thumbor-venv/lib/python3.7/site-packages/thumbor/server.py", line 136, in main
    server_parameters.config_path, server_parameters.use_environment
  File "/srv/zulip-venv-cache/093de4c3442c3634d87062bf6faee72b80fc4e80/zulip-thumbor-venv/lib/python3.7/site-packages/thumbor/server.py", line 45, in get_config
    return Config.load(config_path, conf_name="thumbor.conf", lookup_paths=lookup_paths)
  File "/srv/zulip-venv-cache/093de4c3442c3634d87062bf6faee72b80fc4e80/zulip-thumbor-venv/lib/python3.7/site-packages/derpconf/config.py", line 75, in load
    raise ConfigurationError('Configuration file not found at path %s' % path)
derpconf.config.ConfigurationError: Configuration file not found at path /home/zulip/deployments/current/zthumbor/thumbor.conf

I could mitigate these issues by just creating an empty file in /home/zulip/deployments/current/zthumbor/ named thumbor.conf and setting the ownership to zulip. After doing that, zulip-thumbor spawned without problems.
The output of one of the zulip-events-message-sender processes is this here:
2020-07-22 10:16:10.494 INFO [process_queue/zerver.management.commands.process_queue] Worker 0 connecting to queue message_sender
Traceback (most recent call last):
  File "/home/zulip/deployments/current/manage.py", line 50, in <module>
    execute_from_command_line(sys.argv)
  File "/home/zulip/deployments/2020-07-20-12-32-17/zulip-py3-venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/home/zulip/deployments/2020-07-20-12-32-17/zulip-py3-venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/zulip/deployments/2020-07-20-12-32-17/zulip-py3-venv/lib/python3.7/site-packages/django/core/management/base.py", line 323, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/zulip/deployments/2020-07-20-12-32-17/zulip-py3-venv/lib/python3.7/site-packages/django/core/management/base.py", line 364, in execute
    output = self.handle(*args, **options)
  File "/home/zulip/deployments/2020-07-20-12-32-17/zerver/management/commands/process_queue.py", line 74, in handle
    worker = get_worker(queue_name)
  File "/home/zulip/deployments/2020-07-20-12-32-17/zerver/worker/queue_processors.py", line 128, in get_worker
    return worker_classes[queue_name]()
KeyError: 'message_sender'

This seems more in-depth than the thumbor problem. Any ideas what went wrong here?

Seems that old supervisor configs are the issue here. There were some changes in the update to 3.0 that were overwritten by our config-deployment system. If someone else has these issues, check /etc/supervisor/ first.

Thanks for the follow-up.  We generally recommend that config-deployment systems just manage /etc/zulip/zulip.conf and then let zulip-puppet-apply implement that configuration in order to avoid problems like this when upgrading.


Instagram Behavior

Instagram uses a sliding window loading strategy, about ~8-16 posts rendered in the DOM at once.
This requires a differing approach than FaceBook/Twitter timeline consumption behaviors because they leave all rendered posts in the DOM.
Instagram is a React Redux app and because React embedded the underlying VDOM (components, props etc) in the live DOM tree we can use this to our advantage.
TODO:

[x] extract redux store and listen to fetch events
[x] Traverse timeline

[x] unique visit
[x] each photo in multi photo
[x] video

[ ] highlights

closed via https://github.com/webrecorder/wr-behaviors


Update collect script for dax nvdimm images

osbuilder recently added the ability to create images with a DAX/NVDIMM header [1], however this change broke the data collection script. Update that script to handle images with and without this header.
The data collection script will now assume a header is present. However, if it fails to find the required partition data, it will try again, this time assuming the image does not have a DAX/NVDIMM header.
Fixes #1404.
[1] - https://github.com/kata-containers/osbuilder/pull/236
Signed-off-by: James O. D. Hunt<EMAIL_ADDRESS>

Sample output of the changed collect script section (note the last line):
Image details
---
osbuilder:
  url: "https://github.com/kata-containers/osbuilder"
  version: "unknown"
rootfs-creation-time: "2019-03-20T17:20:21.431783008+0000Z"
description: "osbuilder rootfs"
file-format-version: "0.0.2"
architecture: "x86_64"
base-distro:
  name: "Clear"
  version: "28400"
  packages:
    default:
      - "iptables-bin"
      - "libudev0-shim"
      - "systemd"
    extra:

agent:
  url: "https://github.com/kata-containers/agent"
  name: "kata-agent"
  version: "1.6.0-rc2-a41f322af869fddbed252f51dbcde04076594db5"
  agent-is-init-daemon: "no"
dax-nvdimm-header: "true"

/cc @devimc.

Not sure if it is worth running the CI on this..

/test

thanks @jodh-intel


issue #7397 fixed

Issue Reference
#7397

Fixed alignments for filters of velocity on the listing page.

Issue Reference
#7450

Fixed the header for mobile screen view

@peeyush-webkul
Please resolve the conflicts.

@peeyush-webkul
Create a separate pull request for each and every issue.

I am seeing conflicted codes. Please create separate PR for each issue.


Inbox folder shown twice

I saw #66 but I'm not sure if this is the same thing, because it doesn't seem to be specific to any one mail client. I tried with Roundcube (webmail) and Fair Email (android app) and they both show Inbox twice. It's strange to me because when I manually execute a LIST command over IMAP, I see all the folders once as they should be:
import imaplib
mb = imaplib.IMAP4_SSL('<new server>', 993)
mb.login(...)
for x in mb.list()[1]:
  print(x)

b'(\\Archive) "/" Archive'
b'() "/" Cherished'
b'(\\Drafts) "/" Drafts'
b'() "/" Inbox'
b'(\\Junk) "/" Junk'
b'() "/" Rejects'
b'(\\Sent) "/" Sent'
b'(\\Trash) "/" Trash'

I checked on my old mail server (dovecot) and got this:
b'(\\HasNoChildren \\UnMarked) "/" Cherished'
b'(\\HasNoChildren \\UnMarked) "/" Archive'
b'(\\HasNoChildren \\Trash) "/" Trash'
b'(\\HasNoChildren \\Junk) "/" Junk'
b'(\\HasNoChildren \\UnMarked \\Sent) "/" Sent'
b'(\\HasNoChildren \\UnMarked \\Drafts) "/" Drafts'
b'(\\HasNoChildren) "/" INBOX'

The only difference I see (other than the HasNoChildren and UnMarked flags) is that the Inbox folder is listed as INBOX in all caps. I'm not sure if this would make any difference in the email clients.

Thanks for reporting. I think you've got it diagnosed. I installed roundcube locally for testing (wanted to do that at some point, this nudge helped). If I change the name to "INBOX" in the IMAP response, roundcube no longer shows the duplicate.
I'm pretty sure the INBOX mailbox is very special in IMAP, and has to be treated case-insensitively. I suspect roundcube and Fail Email are not comparing case-insensitively. Ideally, this would be fixed in those clients. But I suppose it is more foolproof to just have INBOX in the IMAP response in mox. I'll see if I can add it somewhat cleanly.
For reference, INBOX being case-insensitive has been the case forever. See the mailbox ABNF syntax at the very old https://datatracker.ietf.org/doc/html/rfc1730#page-58
   mailbox         ::= "INBOX" / astring
                       ;; INBOX is case-insensitive; other names may be
                       ;; case-sensitive depending on implementation.

And the more recent https://datatracker.ietf.org/doc/html/rfc9051#name-formal-syntax
mailbox         = "INBOX" / astring
                    ; INBOX is case insensitive.  All case variants
                    ; of INBOX (e.g., "iNbOx") MUST be interpreted as
                    ; INBOX, not as an astring.  An astring that
                    ; consists of the case-insensitive sequence
                    ; "I" "N" "B" "O" "X" is considered
                    ; to be an INBOX and not an astring.
                    ; Refer to Section 5.1 for further
                    ; semantic details of mailbox names.

In any case it would be good to report this to roundcube and fair email.

I didn't know about Fair Email, but installed it on a test-android device just now. But I'm not seeing a duplicate Inbox folder. I'm not familiar with the application. Where are you seeing this behaviour?

In the hamburger menu you can click on an individual account to see its folders. I did this for one of my accounts and you can see here how Inbox is repeated:

And I will open issues on Roundcube and Fair Email. But I agree that if possible we should change this in mox too, for better compatibility.

Ah, that is where I'm looking to, but I'm not seeing that behaviour.

I'm testing with Fair Email 1.2103a, and essentially mox v0.0.7.
Perhaps there is something else different with our setups. I'll try to get the patch in, perhaps you can then test with Fair Email if it makes the problem go away.

I'm chatting with the FairEmail maintainer and we figured it out. It had to do with my transition from the old IMAP server (dovecot) to the new one (mox). Since it saw "INBOX" before and "Inbox" now, it thought they were two different folders so it showed it twice, but both with the same content (because the mox IMAP server correctly treats them as independent).
So for someone else doing the same thing as me, the patch to make mox say "INBOX" would have fixed the issue, but ultimately I still think it's a bug with FairEmail because it should have compared the old and new Inbox folders case-insensitively and realized that they're actually the same folder.

That's quick, thanks!
I worked on a patch to always output INBOX to clients. But it would cause corner-case buggy behaviour exhibited by mox. Admittedly very corner-case, but mox does already have a test for it. By sending back INBOX, that is the implied canonical name. While the actual canonical name is Inbox. Now when a client tries to match "INBO*", it would at least expect to match "INBOX". But with the approach of translating Inbox to INBOX on IMAP responses only, that path wouldn't match against the canonical Inbox. I don't think there is a requirement for pattern matching to be checked case-insensitively against mailbox names. See https://github.com/mjl-/mox/blob/7dce883097972eccdf19c027bad7766975a5644c/imapserver/list_test.go#L53.
As it also seems this is something that should be fixed by clients, let's try to leave it with them for now.

The FairEmail maintainer made a commit that he believes will fix the issue: https://github.com/M66B/FairEmail/commit/08855c7b64c755351e781e3ef9ea97016314c73e?w=1

Seems roundcube also has a patch merged, https://github.com/roundcube/roundcubemail/issues/9166. Thanks for reporting!


Abbreviations with + do not expand properly

There are multiple abbreviations within https://docs.emmet.io/cheat-sheet/ that end in +, such as ul+.
The current implementation of the expansion algorithm does not allow these abbreviations to work, even if added to the list of snippets within expand-full.js.

Closing as out of scope because the newer Emmet doesn't support these abbreviations anyway.
Workaround: use custom snippets.


Add documentation to point out that UUID is a cct type, not a cc type

In the past people have been confused using UUID's in Transit. Transit-cljs uses a custom cct UUID type, not a native CLJS UUID. It would be good to explicitly point this out in the documentation and show how people can override this behaviour if they want to get CLJS UUID's.
This could be something like:

Transit-cljs returns custom com.cognitect.transit types by default for some values, including UUID's. To override this and return native ClojureScript UUID's, add a custom read handler for u. This will override the default read handler.
(t/reader :json {:handlers {"u" cljs.core/uuid} })

Relates to #11

Another problem and fix.
com.cognitect.transit.types/UUID are equivalent of UUID.
But cljs.core/uuid? not work with com.cognitect.transit.types/UUID.
Fix:
(extend-type ty/UUID
  IUUID)

Fixed in master.


fix(presto,trino): use correct literal dttm separator

SUMMARY
#19917 migrated the convert_dttm functions in the Presto and Trino db engine specs to use the currently recommended literal timestamp type cast over the now deprecated from_iso8601_* functions. However, the new literal casts require the separator to be a blank space instead of the "T" separator:

https://trino.io/docs/current/functions/datetime.html
https://prestodb.io/docs/current/functions/datetime.html

This PR updates the format to correspond with the supported format and updates the unit tests accordingly. In addition, the convert_dttm tests are removed from the legacy integration test suite, as they're already covered by the new unit tests.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

LGTM, though wondering if the same also applies to athena?

Good point, let me check and add Athena, too.

Turns out Athena was already using the space separator, so going to go ahead and merge this.


AGIC ingress resource is not getting IP address

Describe the bug
While deploying AGIC with new application gateway, per instruction described here, ingress resource is not getting IP address. After deploying aspnetapp in AKS cluster, this is printout I have:
kubectl get ingress
NAME        CLASS    HOSTS   ADDRESS   PORTS   AGE
aspnetapp   <none>   *                 80      28m

So, there is no IP. And as consequence application gateway routing rules could not be updated.
I can not see any error, everything seems running fine. But, it's just not working.
To Reproduce
Run the steps from instructions
Ingress Controller details
kubectl describe pod ingress-appgw-deployment-c8c64b4b5-446l8
Name:         ingress-appgw-deployment-c8c64b4b5-446l8
Namespace:    kube-system
Priority:     0
Node:         aks-nodepool1-29955174-vmss000002/<IP_ADDRESS>
Start Time:   Sun, 29 Aug 2021 16:41:59 +0200
Labels:       app=ingress-appgw
             kubernetes.azure.com/managedby=aks
             pod-template-hash=c8c64b4b5
Annotations:  checksum/config: 5e3adada1b78b3aabdbb11a15b71b54611b3480fbb63b8076eb1663cc94d42d9
             cluster-autoscaler.kubernetes.io/safe-to-evict: true
             kubernetes.azure.com/metrics-scrape: true
             prometheus.io/path: /metrics
             prometheus.io/port: 8123
             prometheus.io/scrape: true
             resource-id:
               /subscriptions/efe60155-76ad-4117-899f-ee3e4c63c3cd/resourceGroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/my...
Status:       Running
IP:           <IP_ADDRESS>
IPs:
 IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/ingress-appgw-deployment-c8c64b4b5
Containers:
 ingress-appgw-container:
   Container ID:   containerd://c0d87aad375c8aaec2094a4063924d2006c3459c2ffd3fcdf8debef6516f7e85
   Image:          mcr.microsoft.com/azure-application-gateway/kubernetes-ingress:1.4.0
   Image ID:       sha256:533f2cbe57fa92d27be5939f8ef8dc50537d6e1240502c8c727ac4020545dd34
   Port:           <none>
   Host Port:      <none>
   State:          Running
     Started:      Sun, 29 Aug 2021 16:42:01 +0200
   Ready:          True
   Restart Count:  0
   Limits:
     cpu:     700m
     memory:  100Mi
   Requests:
     cpu:      100m
     memory:   20Mi
   Liveness:   http-get http://:8123/health/alive delay=15s timeout=1s period=20s #success=1 #failure=3
   Readiness:  http-get http://:8123/health/ready delay=5s timeout=1s period=10s #success=1 #failure=3
   Environment Variables from:
     ingress-appgw-cm  ConfigMap  Optional: false
   Environment:
     AZURE_CLOUD_PROVIDER_LOCATION:  /etc/kubernetes/azure.json
     AGIC_POD_NAME:                  ingress-appgw-deployment-c8c64b4b5-446l8 (v1:metadata.name)
     AGIC_POD_NAMESPACE:             kube-system (v1:metadata.namespace)
     KUBERNETES_PORT_443_TCP_ADDR:   mycluster-myresourcegroup-efe601-42a82792.hcp.eastus.azmk8s.io
     KUBERNETES_PORT:                tcp://mycluster-myresourcegroup-efe601-42a82792.hcp.eastus.azmk8s.io:443
     KUBERNETES_PORT_443_TCP:        tcp://mycluster-myresourcegroup-efe601-42a82792.hcp.eastus.azmk8s.io:443
     KUBERNETES_SERVICE_HOST:        mycluster-myresourcegroup-efe601-42a82792.hcp.eastus.azmk8s.io
   Mounts:
     /etc/kubernetes/azure.json from cloud-provider-config (ro)
     /var/run/secrets/kubernetes.io/serviceaccount from ingress-appgw-sa-token-jmr5g (ro)
Conditions:
 Type              Status
 Initialized       True
 Ready             True
 ContainersReady   True
 PodScheduled      True
Volumes:
 cloud-provider-config:
   Type:          HostPath (bare host directory volume)
   Path:          /etc/kubernetes/azure.json
   HostPathType:  File
 ingress-appgw-sa-token-jmr5g:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  ingress-appgw-sa-token-jmr5g
   Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
 Type     Reason            Age                From               Message
 ----     ------            ----               ----               -------
 Warning  FailedScheduling  45m (x2 over 45m)  default-scheduler  no nodes available to schedule pods
 Warning  FailedScheduling  44m                default-scheduler  0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.
 Warning  FailedScheduling  44m                default-scheduler  0/3 nodes are available: 3 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.
 Normal   Scheduled         44m                default-scheduler  Successfully assigned kube-system/ingress-appgw-deployment-c8c64b4b5-446l8 to aks-nodepool1-29955174-vmss000002
 Normal   Pulled            44m                kubelet            Container image "mcr.microsoft.com/azure-application-gateway/kubernetes-ingress:1.4.0" already present on machine
 Normal   Created           44m                kubelet            Created container ingress-appgw-container
 Normal   Started           44m                kubelet            Started container ingress-appgw-container

kubectl logs ingress-appgw-deployment-c8c64b4b5-446l8
....
/managedClusters/mycluster",
-- App Gwy config --        "managed-by-k8s-ingress": "1.4.0/0e9dc17c/2021-02-26-03:29T+0000"
-- App Gwy config --    }
-- App Gwy config --}
I0829 14:46:58.028967       1 mutate_app_gateway.go:177] BEGIN AppGateway deployment
I0829 14:46:58.352454       1 client.go:201] OperationID='062d66b4-f781-4d95-a1a5-25052ef69e01'
I0829 14:47:07.490106       1 mutate_app_gateway.go:185] Applied generated Application Gateway configuration
I0829 14:47:07.490128       1 mutate_app_gateway.go:200] cache: Updated with latest applied config.
I0829 14:47:07.490604       1 mutate_app_gateway.go:204] END AppGateway deployment
I0829 14:47:07.490618       1 controller.go:151] Completed last event loop run in: 9.590574542s

@akshaysngupta  I have been using latest AKS version. But, it turns out that I mixed things up with namespaces, like trying to install app in kube-system namespace. When I install app in default namespace, ingress was managed to get an IP and everything was fine.


Installing Structura on Minecraft Bedrock

Just recently hearing about this, I've looked around for the actual mod that you install on bedrock for the block mentioned in the videos. I don't know where to look, and I already have the .exe downloaded. How can I get Structura blocks on my game now?

I opened the .exe, got on game, did the command and got error.

The exe doesn't interface with the game. Watch the videos
On Wed, Sep 18, 2024, 7:59 AM Wolfknight777 @.***>
wrote:

I opened the .exe, got on game, did the command and got error.
—
Reply to this email directly, view it on GitHub
https://github.com/RavinMaddHatter/Structura/issues/231#issuecomment-2358714379,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUC5FJ2I54FVX5MG6TMT3ZXGIMLAVCNFSM6AAAAABON2I75GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJYG4YTIMZXHE
.
You are receiving this because you commented.Message ID:
@.***>