Duplicate photos in "Contributions" page

Summary:
After uploading photos, I see duplicate images in the app's "contributions" screen.
Steps to reproduce:

Upload an image to Wikimedia Commons using this Android App.
Look though your photos in the "contribution" for duplicate images (they may not be adjacent to each other in the image feed).
View your account's "uploads" on https://commons.wikimedia.org and look for any duplicate images.

I see duplicate images on the app but the website shows that the photo uploaded correctly (no duplicates).
System logs:
Logs exported from the app: https://privatebin.net/?6ccdcedda9153900#7YwYwPohymf1LZ6iBuUf8jBQBbj9hDzUjiZcwGvejr4i
Device and Android version:
API level: 29
Android version: 10
Device manufacturer: Google
Device model: Pixel 2
Device: walleye
Network type: wifi
App version name: 2.12.3~dc08a5e88
User name: Mds08011
Commons app version:
App version name: 2.12.3~dc08a5e88
I am currently using the Beta version but this issue occurred on the regular/stable version as well.
Screen-shots:
Duplicate photo in app:

Duplicate photo in app:

"Uplaods" on website showing only single images:

Would you like to work on the issue?
No.  I don't have the technical knowledge to address this.

@mds08011 This  issue already exists #3218

Thank you.  I moved my bug report to the existing issue.  Note that my case is slightly different in that I didn't see any uploading error messages and only one copy of my image uploads commons.wikimedia.org despite the app showing two.

I don't think it is the same issue, actually.
Malcom has not experienced any failed upload, yet duplicate picture show up.
Actually I had the same issue until recently.
I signed up for the alpha, then uninstall and reinstalled, now it is better. Could you please try @mds08011 ? https://github.com/commons-app/apps-android-commons/wiki/Volunteers-welcome!#how-to-install-the-alpha Thanks for your feedback! :-)

I would like to work on this issue @misaochan @mds08011

@GearGit  Please verify if the build still exists over here https://github.com/commons-app/apps-android-commons/wiki/Volunteers-welcome!#how-to-install-the-alpha. If yes, feel free to pick this up

I installed the Alpha release (Version: <IP_ADDRESS>8~fdbe53d) and my issue appears to be fixed.  However, I am suspicious that it was the act of installing and reinstalling the app, not the Alpha release itself, that resolved it.

Hey @mds08011 , Can you try following the steps you have mentioned in the issue, maybe then we can conclude if it's actually fixed or not.

I am still experiencing this issue on Alpha Version: <IP_ADDRESS>9~b13d888

I would like to work on this issue @misaochan @mds08011

@GearGit sounds good, let us know how you get on!

@GearGit Please let us know about your progress :-) Thanks!

Hi @GearGit , any updates on this issue?

Hi @GearGit , any updates on this issue?

I am trying to recreate the issue. I will update on the issue by EOD.

Still happening in <IP_ADDRESS>1~e303491

Hi @GearGit , as this issue is a pretty visible bug, I am bumping its priority.
How are things going with your work on it? If you are actively working on it now, we're happy to keep you assigned to it. Please update us with where exactly you are stuck, and what you have tried, so we can try to help you.
If you are not actively working on it, please let us know so we can assign it to someone else.
Thanks!

@misaochan
I am not able to resolve the issue, please do assign it to someone else.

Picking this up


ci: migrate codebase to use NX (using lerna integration)

Overview

Switch to NX for task caching and package builds, further integration in future updates

Next steps

[ ] convert repo to use nx test utilities & cache in CI
[ ] convert repo to use nx lint utilities & cache in CI

PR Checklist

[ ] Related to designs:
[ ] Related to JIRA ticket: ABC-123
[ ] I have run this code to verify it works
[ ] This PR includes unit tests for the code change
[ ] This PR includes testing instructions tests for the code change
[ ] The alpha package of this PR is passing end-to-end tests in all relevant Codecademy repositories

Testing Instructions
Everything should be the same for the builds, i didn't modify how the packages were being built, just what was building them. you can confirm by comparing the contents of the latest version of the packages with the alpha versions from this PR.
https://unpkg.com/browse/<EMAIL_ADDRESS>https://unpkg.com/browse/<EMAIL_ADDRESS>
PR Links and Envs

Repository
PR Link
PR Env

Monolith
Monolith PR
Monolith Env

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.c246a8.0@codecademy/gamut-icons@7.4.3-alpha.c246a8.0@codecademy/gamut-illustrations@0.28.3-alpha.c246a8.0@codecademy/gamut-kit@0.6.164-alpha.c246a8.0@codecademy/gamut-labs@32.7.7-alpha.c246a8.0@codecademy/gamut-patterns@0.8.9-alpha.c246a8.0@codecademy/gamut-styles@13.4.1-alpha.c246a8.0@codecademy/gamut-tests@4.0.8-alpha.c246a8.0@codecademy/gamut@48.3.0-alpha.c246a8.0@codecademy/macros@3.0.1-alpha.c246a8.0@codecademy/markdown-overrides@0.9.6-alpha.c246a8.0@codecademy/monaco@0.6.59-alpha.c246a8.0@codecademy/styleguide@58.6.0-alpha.c246a8.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.b947b1.0@codecademy/gamut-icons@7.4.3-alpha.b947b1.0@codecademy/gamut-illustrations@0.28.3-alpha.b947b1.0@codecademy/gamut-kit@0.6.164-alpha.b947b1.0@codecademy/gamut-labs@32.7.7-alpha.b947b1.0@codecademy/gamut-patterns@0.8.9-alpha.b947b1.0@codecademy/gamut-styles@13.4.1-alpha.b947b1.0@codecademy/gamut-tests@4.0.8-alpha.b947b1.0@codecademy/gamut@48.3.0-alpha.b947b1.0@codecademy/macros@3.0.1-alpha.b947b1.0@codecademy/markdown-overrides@0.9.6-alpha.b947b1.0@codecademy/monaco@0.6.59-alpha.b947b1.0@codecademy/styleguide@58.6.0-alpha.b947b1.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.ccf430.0@codecademy/gamut-icons@7.4.3-alpha.ccf430.0@codecademy/gamut-illustrations@0.28.3-alpha.ccf430.0@codecademy/gamut-kit@0.6.164-alpha.ccf430.0@codecademy/gamut-labs@32.7.7-alpha.ccf430.0@codecademy/gamut-patterns@0.8.9-alpha.ccf430.0@codecademy/gamut-styles@13.4.1-alpha.ccf430.0@codecademy/gamut-tests@4.0.8-alpha.ccf430.0@codecademy/gamut@48.3.0-alpha.ccf430.0@codecademy/macros@3.0.1-alpha.ccf430.0@codecademy/markdown-overrides@0.9.6-alpha.ccf430.0@codecademy/monaco@0.6.59-alpha.ccf430.0@codecademy/styleguide@58.6.0-alpha.ccf430.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62d865afe673770de3c84bec--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.7b7eab.0@codecademy/gamut-icons@7.4.3-alpha.7b7eab.0@codecademy/gamut-illustrations@0.28.3-alpha.7b7eab.0@codecademy/gamut-kit@0.6.165-alpha.7b7eab.0@codecademy/gamut-labs@33.0.1-alpha.7b7eab.0@codecademy/gamut-patterns@0.8.9-alpha.7b7eab.0@codecademy/gamut-styles@13.4.1-alpha.7b7eab.0@codecademy/gamut-tests@4.0.8-alpha.7b7eab.0@codecademy/gamut@48.3.1-alpha.7b7eab.0@codecademy/macros@3.0.1-alpha.7b7eab.0@codecademy/markdown-overrides@0.9.6-alpha.7b7eab.0@codecademy/monaco@0.6.60-alpha.7b7eab.0@codecademy/styleguide@59.0.1-alpha.7b7eab.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62d9fcfd67db2b24a5a50a79--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.6c28e2.0@codecademy/gamut-icons@7.4.3-alpha.6c28e2.0@codecademy/gamut-illustrations@0.28.3-alpha.6c28e2.0@codecademy/gamut-kit@0.6.165-alpha.6c28e2.0@codecademy/gamut-labs@33.0.1-alpha.6c28e2.0@codecademy/gamut-patterns@0.8.9-alpha.6c28e2.0@codecademy/gamut-styles@13.4.1-alpha.6c28e2.0@codecademy/gamut-tests@4.0.8-alpha.6c28e2.0@codecademy/gamut@48.3.1-alpha.6c28e2.0@codecademy/macros@3.0.1-alpha.6c28e2.0@codecademy/markdown-overrides@0.9.6-alpha.6c28e2.0@codecademy/monaco@0.6.60-alpha.6c28e2.0@codecademy/styleguide@59.0.1-alpha.6c28e2.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62dac0ed8aec3806196f0e9f--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.9bfc43.0@codecademy/gamut-icons@7.4.3-alpha.9bfc43.0@codecademy/gamut-illustrations@0.28.3-alpha.9bfc43.0@codecademy/gamut-kit@0.6.165-alpha.9bfc43.0@codecademy/gamut-labs@33.0.1-alpha.9bfc43.0@codecademy/gamut-patterns@0.8.9-alpha.9bfc43.0@codecademy/gamut-styles@13.4.1-alpha.9bfc43.0@codecademy/gamut-tests@4.0.8-alpha.9bfc43.0@codecademy/gamut@48.3.1-alpha.9bfc43.0@codecademy/macros@3.0.1-alpha.9bfc43.0@codecademy/markdown-overrides@0.9.6-alpha.9bfc43.0@codecademy/monaco@0.6.60-alpha.9bfc43.0@codecademy/styleguide@59.0.1-alpha.9bfc43.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62dae0870571081f39933c43--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.825c81.0@codecademy/gamut-icons@7.4.3-alpha.825c81.0@codecademy/gamut-illustrations@0.28.3-alpha.825c81.0@codecademy/gamut-kit@0.6.165-alpha.825c81.0@codecademy/gamut-labs@33.0.1-alpha.825c81.0@codecademy/gamut-patterns@0.8.9-alpha.825c81.0@codecademy/gamut-styles@13.4.1-alpha.825c81.0@codecademy/gamut-tests@4.0.8-alpha.825c81.0@codecademy/gamut@48.3.1-alpha.825c81.0@codecademy/macros@3.0.1-alpha.825c81.0@codecademy/markdown-overrides@0.9.6-alpha.825c81.0@codecademy/monaco@0.6.60-alpha.825c81.0@codecademy/styleguide@59.0.1-alpha.825c81.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.f24332.0@codecademy/gamut-icons@7.4.3-alpha.f24332.0@codecademy/gamut-illustrations@0.28.3-alpha.f24332.0@codecademy/gamut-kit@0.6.165-alpha.f24332.0@codecademy/gamut-labs@33.0.1-alpha.f24332.0@codecademy/gamut-patterns@0.8.9-alpha.f24332.0@codecademy/gamut-styles@13.4.1-alpha.f24332.0@codecademy/gamut-tests@4.0.8-alpha.f24332.0@codecademy/gamut@48.3.1-alpha.f24332.0@codecademy/macros@3.0.1-alpha.f24332.0@codecademy/markdown-overrides@0.9.6-alpha.f24332.0@codecademy/monaco@0.6.60-alpha.f24332.0@codecademy/styleguide@59.0.1-alpha.f24332.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.25d8b9.0@codecademy/gamut-icons@7.4.3-alpha.25d8b9.0@codecademy/gamut-illustrations@0.28.3-alpha.25d8b9.0@codecademy/gamut-kit@0.6.165-alpha.25d8b9.0@codecademy/gamut-labs@33.0.1-alpha.25d8b9.0@codecademy/gamut-patterns@0.8.9-alpha.25d8b9.0@codecademy/gamut-styles@13.4.1-alpha.25d8b9.0@codecademy/gamut-tests@4.0.8-alpha.25d8b9.0@codecademy/gamut@48.3.1-alpha.25d8b9.0@codecademy/macros@3.0.1-alpha.25d8b9.0@codecademy/markdown-overrides@0.9.6-alpha.25d8b9.0@codecademy/monaco@0.6.60-alpha.25d8b9.0@codecademy/styleguide@59.0.1-alpha.25d8b9.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.868d87.0@codecademy/gamut-icons@7.4.3-alpha.868d87.0@codecademy/gamut-illustrations@0.28.3-alpha.868d87.0@codecademy/gamut-kit@0.6.165-alpha.868d87.0@codecademy/gamut-labs@33.0.1-alpha.868d87.0@codecademy/gamut-patterns@0.8.9-alpha.868d87.0@codecademy/gamut-styles@13.4.1-alpha.868d87.0@codecademy/gamut-tests@4.0.8-alpha.868d87.0@codecademy/gamut@48.3.1-alpha.868d87.0@codecademy/macros@3.0.1-alpha.868d87.0@codecademy/markdown-overrides@0.9.6-alpha.868d87.0@codecademy/monaco@0.6.60-alpha.868d87.0@codecademy/styleguide@59.0.1-alpha.868d87.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.54c5f5.0@codecademy/gamut-icons@7.4.3-alpha.54c5f5.0@codecademy/gamut-illustrations@0.28.3-alpha.54c5f5.0@codecademy/gamut-kit@0.6.165-alpha.54c5f5.0@codecademy/gamut-labs@33.0.1-alpha.54c5f5.0@codecademy/gamut-patterns@0.8.9-alpha.54c5f5.0@codecademy/gamut-styles@13.4.1-alpha.54c5f5.0@codecademy/gamut-tests@4.0.8-alpha.54c5f5.0@codecademy/gamut@48.3.1-alpha.54c5f5.0@codecademy/macros@3.0.1-alpha.54c5f5.0@codecademy/markdown-overrides@0.9.6-alpha.54c5f5.0@codecademy/monaco@0.6.60-alpha.54c5f5.0@codecademy/styleguide@59.0.1-alpha.54c5f5.0<EMAIL_ADDRESS>
📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.b9b96b.0@codecademy/gamut-icons@7.4.3-alpha.b9b96b.0@codecademy/gamut-illustrations@0.28.3-alpha.b9b96b.0@codecademy/gamut-kit@0.6.165-alpha.b9b96b.0@codecademy/gamut-labs@33.0.1-alpha.b9b96b.0@codecademy/gamut-patterns@0.8.9-alpha.b9b96b.0@codecademy/gamut-styles@13.4.1-alpha.b9b96b.0@codecademy/gamut-tests@4.0.8-alpha.b9b96b.0@codecademy/gamut@48.3.1-alpha.b9b96b.0@codecademy/macros@3.0.1-alpha.b9b96b.0@codecademy/markdown-overrides@0.9.6-alpha.b9b96b.0@codecademy/monaco@0.6.60-alpha.b9b96b.0@codecademy/styleguide@59.0.1-alpha.b9b96b.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62db4890509fb631a7dcc6d0--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:eslint-plugin-gamut@2.0.1-alpha.fe86ea.0@codecademy/gamut-icons@7.4.3-alpha.fe86ea.0@codecademy/gamut-illustrations@0.28.3-alpha.fe86ea.0@codecademy/gamut-kit@0.6.165-alpha.fe86ea.0@codecademy/gamut-labs@33.0.1-alpha.fe86ea.0@codecademy/gamut-patterns@0.8.9-alpha.fe86ea.0@codecademy/gamut-styles@13.4.1-alpha.fe86ea.0@codecademy/gamut-tests@4.0.8-alpha.fe86ea.0@codecademy/gamut@48.3.1-alpha.fe86ea.0@codecademy/macros@3.0.1-alpha.fe86ea.0@codecademy/markdown-overrides@0.9.6-alpha.fe86ea.0@codecademy/monaco@0.6.60-alpha.fe86ea.0@codecademy/styleguide@59.0.1-alpha.fe86ea.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62deb23cc82bc23717dd28db--gamut-preview.netlify.appDeploy Logs


fix: update Otel plugin dependencies

The problem is that when installing the OpenTelemetry (Otel) Plugin, some necessary dependencies related to OpenTelemetry are not automatically installed. Even though these dependencies are listed in the pyproject.toml file, which is the same for all plugins in this repo, they still don't get installed as expected. Additionally, the setup.py file, which is for plugin setup, lacks any mention of OpenTelemetry packages under install_requires.
To solve this issue:

The required packages are now explicitly mentioned in a BUILD file under dependencies for the Otel Plugin. This ensures that the necessary packages are included during the plugin setup.

There have been updates to some packages related to OpenTelemetry. Instead of individually installing the API and SDK packages, a new approach involves using the OpenTelemetry Distro package. This Distro package includes all the required components, simplifying the installation process.

Thanks for tracking this down and for the fix!


Add BYO fees to staking

Blocked by #1441

I think it is a lot of work just to integrate our fee estimation approach into this legacy work. The effort used to implement fee estimation into this legacy code, could be used to re work the whole UI.

We'll come back to this when it's been reviewed by UX

Closing this—will be handled as part of the Staking redesign work.


feat(goctl): support go work (#4332)

this PR fixed the error no matched module when using goctl api inside of a go workspace.
in go workspace, command go list -m -f '{{.GoMod}}' only lists modules declared in go.work, so goctl can't can the go.mod path even it's already initilized if the project is not in go.work.
to fix this, goctl should

use go env GOMOD to determine whether the project is a go module.
check if the project is inside of a go workspace, if it does, it will use go work use . to add the project to go.work.

#3420


Delay ADS stream until XDS cluster warming

Currently the ADS stream is started immediately after static load completes:
https://github.com/envoyproxy/envoy/blob/master/source/common/upstream/cluster_manager_impl.cc#L283
When used with STRICT_DNS, this means that the gRPC stream keeps attempting to connect until DNS resolves, which can exacerbate startup delays due to DNS issues: the stream will continuously attempt to connect, building up the retry backoff counter. By the time DNS finally resolves, the next attempt might be scheduled several seconds into the future. As a result, a 5 second DNS delay (eg due to a timeout) might result in delaying startup by >10s.
While this slowdown isn't a major issue, it's caused short-ish DNS issues to cause significant deployment delays for us.
Conceptually the fix sounds like it would be to defer ADS stream start until the associated cluster warms (eg wait for first DNS resolution), but I'm not sure how easy it would be to express that with the current init helper.

@snowp I think you could potentially take advantage of https://github.com/envoyproxy/envoy/blob/master/source/common/upstream/cluster_manager_impl.cc#L208. Shouldn't be too hard I think.

@snowp are you interested in implementing or should we mark as help wanted? It seems a reasonable request.

Yeah I have a half done branch, I'll try to find the time to put it up

Marking help wanted since I don't seem to be able to find the time to work on this

@yanavlasov FYI; not related to your current PR but some context on earlier discussions around ADS and warming.


[GOBBLIN-1198] use DatasetCleanerTask to clean job status

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1198

Description

[x] Here are some details about my PR, including screenshots (if applicable):
use DatasetCleanerTask to clean job status, because the old way, using StateStoreCleanerRunnable, is deprecated

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
trivial changes

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #3044 into master will increase coverage by 0.01%.
The diff coverage is 0.00%.

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


Future improvements

https://www.resume-now.com/
the idea for clickable fields to update specific items.

TODO: convert this to wiki Spike page

TODO: convert this to wiki Spike page


Report Unresponsive Accessories

If I'm understanding pull 556 of HAP-NodeJS correctly it seems that it is now possible to report unresponsive accessories to the Home app.
This isn't a huge priority for me but I would eventually like to be able to support this if possible.

Would be great to have this feature. It is already implemented in homebridge-mqtt plugin: https://github.com/cflurin/homebridge-mqtt/issues/9


Clock output

Hi all,
just wanted to let you know that yesterday Q3 in my performer blew up.
The clock output is usually connected to the input of a 1U Buff Mult in a different case which I tend to switch on before the one with the sequencer in it.
For sure I cannot recover the reasons, but I guess that an additional resistor between collector and jack would help here preventing unwanted current firing directly into the transistor?
As I had no more SMD transistors in house, I replaced with a 2N3904 THT that I had left and which led to a funny patch (see image attached).
However, after reassembly it turned out that the clock output was still not capable to run clock inputs of other gear like PAM or my Doepfer clock divider.
Using the oscilloscope I could measure the clock signal switching from 5V to somewhat 3.5V, only.
Surprisingly enough that the THT version comes with electronically different behaviour (which shouldn't occur according to the datasheets), some maths made the issue more obvious:
With a BE voltage of around 0,7V, R19 is provided with 3.3V - 0.8V = 2.5V and thus .25mA. This seems quite a low base current, isn't it?
In the end, additional to the funny THT transistor on the board now, I replaced R19 with a smaller 1K resistor, leading to more juice on the transistor base and a nice and clean 0V-5V clock signal.
Happy to discuss some thoughts on the topic.
Best,
Oliver

Short update on this one: the clock output transistor blew up again, unfortunately. Next attempt includes additional 100R on collector side. Let's see how that goes.

(Please excuse the blurry image...)


Do not save empty executions in the history of deployments

This is already done in version 1.0.0

This issue is resolved!


Add reject timeout to ttsPromise

This fix will allow us to have a reject in the ttsPromise.
Since it is a websocket, we do not have a response if the Microsoft API does not return the media.

I changed the default timeout from 3 seconds to 10 seconds to ensure that longer texts can also be returned within the default duration.


Add updates to PWA architecture

This is the PR for PWA Architecture under /web/fundamentals/progressive-web-apps/architecture. I've updated this draft to try addressing @petele's feedback from the original review.
Some of Joe's feedback has been addressed, but I think there are overall flow/simplification improvements that could be made. If @jpmedley has time, perhaps this could be tackled separately next (sep PR)?
Assorted notes:

Once this PR lands we will want to also look at what redirects/changes are needed for the PWA>Overview in our TOC to redirect to the current overview content.
This PR was intentionally trying to stick pretty close to the structure of the ILT course content with fixes. It's long as is and I didn't want to include a walk-through of https://github.com/GoogleChrome/application-shell. We might do this in follow-up future work.

@jpmedley - don't bother looking yet, still in flux.

@petele The restructuring you've proposed looks good to me. Summarizing our last convo:

[ ] Simplify large walls of text where we can (add images, lists etc to make it welcoming)
[ ] Migrating needs 3-4 hours of work to properly fill it out
[ ] Architecting: yank out content that better belongs in a codelab. Focus on what folks need to know

Given there are now effectively two doc in here, would you prefer me to flesh out two separate PRs for this content? (aim to get migration in a land-worthy state this week, architecture next). Or keep both in one PR?

@addyosmani - I think two separate PRs make sense, will be easier to land it that way.

Sounds good. I've been taking a detour to flesh out #3459 but will be jumping back on this next.

@addyosmani - please assign to me when this is ready to go.

Closing in favor of a new PR for each of these other parts.


Skip logos not working

With skip logos option enabled, it does this error in the log:
[error] Skip Logos: Pattern scan failed.
Using borderless with reShade active, maybe there is a conflict?

Steam

Same issue for me: [STALKER2Tweak] [error] Skip Logos: Pattern scan failed.

v0.0.6
Steam version
No reShade
Borderless or Fullscreen

Same with cracked steam version
STALKER2Tweak.log
no reshade, fullscreen, no mods

I can confirm that it doesn't work as well.
Had to delete 0.0.6 version temporarily until the issues with it are addressed

on v0.0.5 it's work, except intro about epilepsy

on v0.0.5 it's work, except intro about epilepsy

That doesn't make a lot of sense given that nothing changed with the skip intro patch between v0.0.5 and v0.0.6.

on v0.0.5 it's work, except intro about epilepsy

That doesn't make a lot of sense given that nothing changed with the skip intro patch between v0.0.5 and v0.0.6.

I don't know why, but 0.0.5 is working for me.
STALKER2Tweak.log

v0.05 also mostly works for me, running the GOG version through proton on linux. v0.06 doesn't work at all, while 05 replaces the intro videos with a black screen, though I don't know if it's any shorter.

For those that are having this issue, can you please try this test build?
STALKER2Tweak_v0.0.7_Steam.zip

That's expected. The new method skips every part of the intro sequence up until shader compilation.

In my case, it doesn't skip them, it just replaces them with a black screen. It's not any quicker than if they remained.

Are you using the Steam version of the game?

GOG

For those that are having this issue, can you please try this test build?
STALKER2Tweak_v0.0.7_Steam.zip

it's work for cracked steam 1.0.1 game version!
STALKER2Tweak.log

Version 0.0.7 just hides the logos and shows black screen for ~5 seconds (i think the same waiting time if the logos are shown) before loading into Menu.  Game Version: (Stalker2-Win64-Shipping.exe) <IP_ADDRESS>.
No clue if it was shorter before, I just bought the game.

Alright here's a new version that uses the SDK to skip the intro. Note that the photosensitivity warning can't be skipped as there is indeed some initial loading going on behind these disclaimers/logos.
STALKER2Tweak_v0.0.7_Steam_test.zip

Alright here's a new version that uses the SDK to skip the intro. Note that the photosensitivity warning (and maybe more depending on speed) can't be skipped as there is indeed some initial loading going on behind these disclaimers/logos.
STALKER2Tweak_v0.0.7_Steam_test.zip

I can confirmed, it's work for cracked steam 1.0.1 game version

Fixed in v0.0.7


Fields in oneof not using TypeMapper

I have noticed while adding scalapb-validate to my project that the code emitted by the code generator does not appear to use the TypeMapper for fields that are within a oneof.
A very simple protobuf that exhibits the problem is below

package test;

import "google/protobuf/wrappers.proto";
import "scalapb/scalapb.proto";
import "validate/validate.proto";

message TestMessage {
  TestBigDecimal foo = 1 [(scalapb.field).type = "_root_.scala.math.BigDecimal"];
  oneof value {
    TestBigDecimal bar = 2 [(scalapb.field).type = "_root_.scala.math.BigDecimal"];
  }
}

message TestBigDecimal {}

The code emitted code is as follows.

object TestMessageValidator extends scalapb.validate.Validator[test.test.TestMessage] {
  def validate(input: test.test.TestMessage): scalapb.validate.Result =
    scalapb.validate.Result.optional(input.foo.map(test.test.TestMessage._typemapper_foo.toBase)) { _value =>
      test.test.TestBigDecimalValidator.validate(_value)
    } &&
    scalapb.validate.Result.optional(input.value.bar) { _value =>
      test.test.TestBigDecimalValidator.validate(_value)
    }

}

One can see from the above code that for the bar field, the type mapper has not been used to convert to the base type.
I believe this might be a simple bug in the creation of the accessor in the code referenced below. I believe the bug is that in the final else case (line 117) it does not invoke toBase, but I am not sure.
https://github.com/scalapb/scalapb-validate/blob/16f75aadae6a71abb79c4aeb24f5531a575287a4/code-gen/src/main/scala/scalapb/validate/compiler/CodeGenerator.scala#L110-L120
It could be that I am just doing something wrong as well.

Could you release new version with this fix? 🙏

Released v0.3.4

Thanks!


Add support for additional validation properties

Add support for the following validation properties:

multipleOf
maximum
exclusiveMaximum
minimum
exclusiveMinimum
maxLength
minLength
pattern
maxItems
minItems
uniqueItems
maxProperties
minProperties

Fixes #49

@correl thank you for the contribution LGTM

@p1c2u I hope release comes early,thank you!


localstore's gc_size metric is wrong

Summary
Learning more about and looking at the various metrics, I discovered that the gc_size metric matches the gc_count metric.  Checking the source code revealed that they are both incrementing at the same time.  I believe that gc_size should be SET to the current gcSize and not incremented.
Steps to reproduce
Just look at the /metrics page and see that bee_localstore_gc_size has the same value as bee_localstore_gc_count which makes no sense.
Expected behavior
The two metrics should at least have different values, and gc_count is described as "Number of times the GC operation is done." whereas gc_size is "Number of elements in Garbage collection index."
Actual behavior
The two values are the same.
I have fixed localstore's gc.go to set the gc_size metric when it is looked up in the garbage collector, after the garbage collector runs and when it is updated later in that file.

fixed in https://github.com/ethersphere/bee/pull/1417


Update record field with default value if OAS contains properties have default value

Description:
$Subject
Describe your problem(s)
Describe your solution(s)
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Close this issue since it is duplicate with this issue https://github.com/ballerina-platform/openapi-tools/issues/923


Return profile object including user's display name after registration

Small tweak to return a profile object containing the user's display name after registration.
'displayName' appears to be the correct attribute to use here. It worked with my testing and is documented in the graph API here: http://graph.microsoft.io/en-us/docs/api-reference/beta/resources/user
What do you think @gwhobbs ?

Thanks for the pull request! Sounds like it makes sense. I am out of town currently and will take a look in a couple of days.
On September 18, 2016 at 5:06:01 PM, lachiemurray (notifications@github.com(mailto:notifications@github.com)) wrote:

Small tweak to return a profile object containing the user's display name after registration.
'displayName' appears to be the correct attribute to use here. It worked with my testing and is documented in the graph API here: http://graph.microsoft.io/en-us/docs/api-reference/beta/resources/user
What do you think @gwhobbs(https://github.com/gwhobbs) ?
You can view, comment on, or merge this pull request online at:
https://github.com/gwhobbs/meteor-microsoft/pull/1
Commit Summary
Return profile object including user's display name after registration
File Changes
M server/server.js(https://github.com/gwhobbs/meteor-microsoft/pull/1/files#diff-0) (2)
Patch Links:
https://github.com/gwhobbs/meteor-microsoft/pull/1.patch
https://github.com/gwhobbs/meteor-microsoft/pull/1.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub(https://github.com/gwhobbs/meteor-microsoft/pull/1), or mute the thread(https://github.com/notifications/unsubscribe-auth/AD4iFoTFbgj0fTsmE-ACjQEUkhRmcqrjks5qrUVJgaJpZM4J_6NC).

Merged, thanks! I also added the package to Atmosphere to make it easier to find for others interested in using this endpoint.


[BUG] .NET downloaded but doesn't work

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
I found Bloxstrap recently but whenever I open the file it says I need to download .NET, it already is downloaded and it still wont work. yes I redownloaded Bloxstrap after downloading .NET

Did you download .Net Desktop Runtime 6.0?

Are you still seeing the prompt? Open a Command Prompt window and run this command: dotnet --info
Screenshot what you see then send it here.

You don't have the latest version of .NET 6 installed. Go and download it. Let me know if it doesn't work. https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win11-x64&apphost_version=6.0.16&gui=true

Hey @pizzaboxer why specifically .NET 6? Why not .NET 8?

Hey @pizzaboxer why specifically .NET 6? Why not .NET 8?

because it uses .net sdk 6


Add Filter handler

One thing react-dash lacks is the ability to respond to changes to components that are not tied to a filter. For example if you wanted a universal reset button or have the values from one filter change based off of change from another filter.
This PR adds a filter handler that allows components to respond to an update from another component.
This is partly lacking because there isn't a way to see the full state of the app and update the queries accordingly. Would like to refactor to add that in the future.

@acouch does this need code review?

Yes, speaking with @iris-i tomorrow.


[FLINK-23130][rest] Remove netty 3 reference

Replaces a netty 3 reference with our flink-shaded-netty version. This currently works on master because it uses the netty version provided by akka.

Is there a test covering this case?
I don't fully understand this change: Since no dependency or any other code has been changed, why can we just change the type of the exception? Either e instanceof org.jboss.netty.channel.ChannelException was never true, or after this change it will never be true?

It was never true. I don't know how to force a ChannelException at this place, and it could even be that it doesn't happen at all with netty4. Maybe we should just remove that instanceof check; after all it was ineffective so far so it doesn't seem necessary.


Features

Add the ability to set a password for a paste : the access is restricted
Add autofocus
Completely fix code paster
Remove unsed dependency
Improve code
Fix few bugs


[Feature] Manage doc and test instructions in BLFS

Is your feature request related to a problem? Please describe.
A lot of editing has to be done on BLFS scriptlets because there are instructions for installing doc or for testing, which can only be run when optional dependencies are present. OTOH, removing them completely is not desirable.
Describe the solution you'd like
The solution is twofold: have BLFS signal those kinds of instructions (add remap="doc" or remap="test" attibutes), and treat those attributes in jhalfs (this project is only concerned with the second part).

if building a package without timing/sizing: comment out the instruction in both doc and test case
if building with timing/sizing:

for doc: don't modify the instruction
for test: change make to make -k and add >> $TESTLOG 2>&1 || true (may be tricky for multiline)

Describe alternatives you've considered
if BLFS do not want the remap attributes, then make all the doc/test instructions in <screen><useriput> tags role="nodump". Actually, it might be a good idea to output any <screen><userinput> instruction, and comment out the instruction if it has attribute role="nodump".
Additional context
The logic for test instructions is already implemented in case they are in a <command> tag.

Actually, we are arriving at a point where several changes to the instruction string have to be done, depending on various conditions:

Always remove && at the end of lines, except if the line contains test or[,  then remove trailing spaces
If role="nodump": comment out each line
If role="doc" and the current package is not in list-stat (we should use a global Boolean variable instead of a test each time), comment out each line
If role="test": change make to make -k, and:

If the current package is not in list-stat: comment out each line
else: append >> $TESTLOG 2>&1 || true to each line, except for lines ending with \

In install mode, replace make with make -j1
In install mode, if $wrap-install="y": replace ' with '\''
If role="root" and $sudo="y": escape \, `, and $
In DESTDIR mode: change  / ("space-slash") to  $PKG_DEST/, and >/ to >$PKG_DEST/, make to make DESTDIR=$PKG_DEST, and ninja to DESTDIR=$PKG_DEST ninja

Right now, we use templates which call another template, which calls another template, ..., using mode attributes for treating the various cases. This may become very tricky now that we have many more conditions.
What we could do is the following: start with the string, and test conditions for applying the first template (say "template-1"). If true, pass the string to template-1 and have the output go to variable-1, else set variable-1 equal to the string unchanged. Then test conditions for applying template-2: If true, pass variable-1 to template-2 and have the output go to variable-2, else pass variable-1 into variable-2 unchanged, and so on. Note that the problem is that variables in XSLT are immutable. Otherwise, we could keep the same variable. OTOH, apart from the immutability problem, I think this could be a good algorithm for our future backends in Python, too.

What we could do is the following: start with the string, and test conditions for applying the first template (say "template-1"). If true, pass the string to template-1 and have the output go to variable-1, else set variable-1 equal to the string unchanged. Then test conditions for applying template-2: If true, pass variable-1 to template-2 and have the output go to variable-2, else pass variable-1 into variable-2 unchanged, and so on. Note that the problem is that variables in XSLT are immutable. Otherwise, we could keep the same variable. OTOH, apart from the immutability problem, I think this could be a good algorithm for our future backends in Python, too.

Using variables may not be the best. <param>/<with-param> could be better suited. Actually, we could even try to keep a node set so:
<xsl:call-template name="cook-instructions">
  <xsl:with-param name="nodeset"
     select=".//screen|.//command[contains(string(),'test') or contains(string(),'check')]"/>
  <xsl:with-param name="root-seen" select="boolean(0)"/>
  ...other params...
</xsl:acall-template>
<!-- and the template -->
<xsl:template name="cook-instructions">
  <xsl:param name="nodeset"/>
  <xsl:param name="root-seen"/>
  ...other params...
  <xsl:for-each select="$nodeset[1]"><!-- have to check the syntax -->
    <!-- treat that node -->
    <xsl:call-template name="cook-instructions">
      <xsl:with-param name="nodeset" select="$nodeset[position()>1]"/>
      <xsl:with-param name="root-seen" select="...adjust depending on conditions..."/>
      ...other params...
    </xsl:call-template>
  </xsl:for-each>
</xsl:template>

Of course, I'm open to other suggestions. I've tried various other options, and all seem to lead to complicated, fragile constructs.

Ooops, forgot to write: if $nodeset is empty, we should return from cook-instructions!

Much of this has been implemented on the jhalfs repo at linuxfromscratch.org. Closing here, since the master branch is now using (partly) Python.


feat: Implement new content-utils package

Closes #82

If you are wondering why this types have to be so complicated:
https://github.com/Fryuni/inox-tools/blob/f11436e3a72964e281d6299f8be9db0d8625ca7e/packages/content-utils/src/runtime/fancyContent.ts#L5-L40
BLAME @florian-lefebvre!!

These people that don't export their types...


failure in building Lyra

I am building Lyra on Ubuntu 18.04.1 for Linux.
The bazel version that I have is 4.0.0 (although I have tried with 4.1.0 as well).
The gcc/g++ version that I have is 7.5.0.
The error appears to be that bazel is invoking gcc with -std=c++0x, yet calling in functionalies that are only supported starting C++17.
Any help would be appreciated.
In file included from layer_wrapper.h:29:0,
from conv1d_layer_wrapper.h:27,
from layer_wrappers_lib.h:21,
from causal_convolutional_conditioning.h:28,
from wavegru_model_impl.h:28,
from wavegru_model_impl.cc:15:
layer_wrapper_interface.h: At global scope:
layer_wrapper_interface.h:82:8: error: 'variant' in namespace 'std' does not name a template type
std::variant<FromDisk, FromConstant> from = FromDisk();

Yes, C++17 is definitely needed. Have you tried passing a compiler option to set the standard library?.

Also, let us know how you are calling bazel build.  The standard should be set automatically to -std=gnu++17 from the .bazelrc file.

Hi,
Thank you for the pointer. I was somehow missing the .bazelrc file.
After downloading a clean version, most errors have been resolved. There is still this error
that I am not sure how to handle:
In file included from /usr/include/c++/7/bits/move.h:54:0,
from /usr/include/c++/7/bits/stl_pair.h:59,
from /usr/include/c++/7/bits/stl_algobase.h:64,
from /usr/include/c++/7/memory:62,
from wavegru_model_impl.h:21,
from wavegru_model_impl.cc:15:
/usr/include/c++/7/type_traits: In substitution of 'template<class _Tp, class> static std::true_type std::__do_is_default_constructible_impl::__test(int) [with _Tp = chromemedia::codec::LayerParams::FromDisk;  = ]':
/usr/include/c++/7/type_traits:889:35:   required from 'struct std::__is_default_constructible_implchromemedia::codec::LayerParams::FromDisk'
/usr/include/c++/7/type_traits:143:12:   required from 'struct std::_and<std::_not<std::is_voidchromemedia::codec::LayerParams::FromDisk >, std::__is_default_constructible_implchromemedia::codec::LayerParams::FromDisk >'
/usr/include/c++/7/type_traits:893:12:   required from 'struct std::__is_default_constructible_atomchromemedia::codec::LayerParams::FromDisk'
/usr/include/c++/7/type_traits:914:12:   required from 'struct std::__is_default_constructible_safe<chromemedia::codec::LayerParams::FromDisk, false>'
/usr/include/c++/7/type_traits:920:12:   required from 'struct std::is_default_constructiblechromemedia::codec::LayerParams::FromDisk'
/usr/include/c++/7/type_traits:2979:25:   required from 'constexpr const bool std::is_default_constructible_vchromemedia::codec::LayerParams::FromDisk'
/usr/include/c++/7/variant:889:2:   required from 'class std::variant<chromemedia::codec::LayerParams::FromDisk, chromemedia::codec::LayerParams::FromConstant>'
layer_wrapper_interface.h:82:56:   required from here
/usr/include/c++/7/type_traits:878:48: error: constructor required before non-static data member for 'chromemedia::codec::LayerParams::FromDisk::path' has been parsed
template<typename _Tp, typename = decltype(_Tp())>
^~~~~
/usr/include/c++/7/type_traits:878:48: error: constructor required before non-static data member for 'chromemedia::codec::LayerParams::FromDisk::zipped' has been parsed

That seems like an error compiling a C++7 header file, not part of the Lyra library.

Thank you. when upgrading gcc to 8.4.0 problem solved.


rebase: update minikube to latest version

As minikube 1.17.0 is released and updating the minikube to the latest available version.
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>

/retest all

/test ci/centos/mini-e2e-helm

@mergifyio rebase

@Mergifyio rebase
The logs of the CI jobs have been removed, we will need new logs in order to fix issues.

@Mergifyio rebase
The logs of the CI jobs have been removed, we will need new logs in order to fix issues.

/test ci/centos/mini-e2e-helm

/test ci/centos/mini-e2e-helm

@Mergifyio rebase
The logs of the CI jobs have been removed, we will need new logs in order to fix issues.

@Mergifyio rebase
The logs of the CI jobs have been removed, we will need new logs in order to fix issues.

https://github.com/kubernetes/minikube/tree/v1.17.1 has been released and includes a fix for #1840

/test ci/centos/mini-e2e-helm

/test ci/centos/mini-e2e

/test ci/centos/upgrade-tests-cephfs

The e2e tests seem to fail consistently with the following error:
Feb  1 09:40:18.655: INFO: Waiting up to 10m0s for all daemonsets in namespace 'cephcsi-e2e-3b6671624651' to start
Feb  1 09:40:18.658: INFO: 1 / 1 pods ready in namespace 'cephcsi-e2e-3b6671624651' in daemonset 'csi-cephfsplugin' (0 seconds elapsed)
STEP: check static PVC
Feb  1 09:40:18.665: INFO: ExecWithOptions {Command:[/bin/sh -c ceph fsid] Namespace:rook-ceph PodName:rook-ceph-tools-5455675849-qxgb2 ContainerName:rook-ceph-tools Stdin:<nil> CaptureStdout:true CaptureStderr:true PreserveWhitespace:true Quiet:false}
Feb  1 09:40:18.665: INFO: >>> kubeConfig: /root/.kube/config
Feb  1 09:40:21.320: INFO: ExecWithOptions {Command:[/bin/sh -c ceph fs subvolumegroup create myfs testGroup] Namespace:rook-ceph PodName:rook-ceph-tools-5455675849-qxgb2 ContainerName:rook-ceph-tools Stdin:<nil> CaptureStdout:true CaptureStderr:true PreserveWhitespace:true Quiet:false}
Feb  1 09:40:21.320: INFO: >>> kubeConfig: /root/.kube/config
Feb  1 09:53:13.588: INFO: stdErr occurred: Error EINVAL: Traceback (most recent call last):
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 165, in get_fs_handle
    conn.connect()
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 88, in connect
    self.fs.mount(filesystem_name=self.fs_name.encode('utf-8'))
  File "cephfs.pyx", line 739, in cephfs.LibCephFS.mount
cephfs.Error: error calling ceph_mount: Connection timed out [Errno 110]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/ceph/mgr/mgr_module.py", line 1177, in _handle_command
    return self.handle_command(inbuf, cmd)
  File "/usr/share/ceph/mgr/volumes/module.py", line 426, in handle_command
    return handler(inbuf, cmd)
  File "/usr/share/ceph/mgr/volumes/module.py", line 34, in wrap
    return f(self, inbuf, cmd)
  File "/usr/share/ceph/mgr/volumes/module.py", line 452, in _cmd_fs_subvolumegroup_create
    uid=cmd.get('uid', None), gid=cmd.get('gid', None))
  File "/usr/share/ceph/mgr/volumes/fs/volume.py", line 480, in create_subvolume_group
    with open_volume(self, volname) as fs_handle:
  File "/lib64/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 316, in open_volume
    fs_handle = vc.connection_pool.get_fs_handle(volname)
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 171, in get_fs_handle
    raise VolumeException(-e.args[0], e.args[1])
TypeError: bad operand type for unary -: 'str'

Feb  1 09:53:13.588: FAIL: failed to validate CephFS static pv with error command terminated with exit code 22

Possibly minikube has tightened its network policy and the node-plugin can not connect to the MDS anymore? During e2e testing, we use two different namespaces for the Ceph cluster and to-test ceph-csi services. Maybe that is problematic...

@nixpanic something has changed in minikube 1.17.1 am not able to run ceph fs commands from the toolbox pod.

@nixpanic something has changed in minikube 1.17.1 am not able to run ceph fs commands from the toolbox pod.

The toolbox pod can access the CephFS MDS, I think. Commands like ceph fs status work just fine.
However, when trying to create a subvolume group, the ceph command needs to talk to the CephMgr. Connecting to the CephMgr works as well, the logs of the CephMgr pod show that the command is received.
debug 2021-02-05T08:46:23.577+0000 7fc29d02b700  0 log_channel(audit) log [DBG] : from='client.11024 -' entity='client.admin' cmd=[{"prefix": "fs subvolumegroup create", "vol_name": "myfs", "target": ["mgr", ""], "group_name": "testGroup"}]: dispatch

However, it seems to run into a timeout:
debug 2021-02-05T08:50:14.554+0000 7fc29c82a700  0 [volumes ERROR volumes.module] Failed _cmd_fs_subvolumegroup_create(group_name:testGroup, prefix:fs subvolumegroup create, target:['mgr', ''], vol_name:myfs) < "":
Traceback (most recent call last):
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 165, in get_fs_handle
    conn.connect()
  File "/usr/share/ceph/mgr/volumes/fs/operations/volume.py", line 88, in connect
    self.fs.mount(filesystem_name=self.fs_name.encode('utf-8'))
  File "cephfs.pyx", line 739, in cephfs.LibCephFS.mount
cephfs.Error: error calling ceph_mount: Connection timed out [Errno 110]

Testing communications between toolbox, mds, mgr does not show any restrictions. Installed nc inside the running containers, and run is like this:
[root@rook-ceph-mgr-a-799d4886bd-4gmcs /]# nc -l -p 6902 --verbose
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Listening on :::6902
Ncat: Listening on <IP_ADDRESS>:6902
Ncat: Connection from <IP_ADDRESS>.
Ncat: Connection from <IP_ADDRESS>:49760.
ping

[root@rook-ceph-mds-myfs-a-f474f4b68-c8xxh /]# nc --verbose <IP_ADDRESS> 6902 <<< "ping"
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to <IP_ADDRESS>:6902.
Ncat: 5 bytes sent, 0 bytes received in 0.03 seconds.

I have not been able to identify the issue when running ceph fs subvolumegroup create myfs testGroup, but using the --cni=bridge parameter when starting minikube makes things work.

ci/centos/mini-e2e/k8s-1.20 failed with:
Feb  9 10:20:21.798: INFO: csi-cephfs-demo-pod app  to be deleted (600 seconds elapsed)
Feb  9 10:20:21.798: FAIL: failed to validate CephFS pvc and application  binding with error timed out waiting for the condition

Not sure what the cause is, logs.

/retest ci/centos/mini-e2e/k8s-1.20

ci/centos/mini-e2e-helm/k8s-1.20 timed out after running an hour job 189. It was running fine and progressing... Maybe we need to increase the runtime of the e2e tests?

/retest ci/centos/mini-e2e-helm/k8s-1.20

ci/centos/mini-e2e/k8s-1.20 failed with:
Feb  9 10:20:21.798: INFO: csi-cephfs-demo-pod app  to be deleted (600 seconds elapsed)
Feb  9 10:20:21.798: FAIL: failed to validate CephFS pvc and application  binding with error timed out waiting for the condition

Not sure what the cause is, logs.

Analysis
I0209 10:10:23.315530       1 utils.go:132] ID: 42 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC call: /csi.v1.Node/NodeUnpublishVolume
I0209 10:10:23.315688       1 utils.go:133] ID: 42 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC request: {"target_path":"/var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount","volume_id":"0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3"}
I0209 10:14:06.241861       1 cephcmds.go:59] ID: 42 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 command succeeded: umount [/var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount]
I0209 10:14:06.242222       1 nodeserver.go:277] ID: 42 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 cephfs: successfully unbinded volume 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 from /var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount
I0209 10:14:06.242277       1 utils.go:138] ID: 42 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC response: {}

It took around 4 minutes to umount the targetPath after that the NodePublish is failing with below error
I0209 10:14:31.025118       1 utils.go:132] ID: 56 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC call: /csi.v1.Node/NodeUnpublishVolume
I0209 10:14:31.025255       1 utils.go:133] ID: 56 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC request: {"target_path":"/var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount","volume_id":"0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3"}
I0209 10:14:31.031176       1 cephcmds.go:53] ID: 56 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 an error (exit status 32) occurred while running umount args: [/var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount]
E0209 10:14:31.031215       1 utils.go:136] ID: 56 Req-ID: 0001-0024-c3feb7b7-cf6b-4154-b66f-fb09df8d20b7-0000000000000001-fc81f537-6abe-11eb-9ad3-e6ef196d01c3 GRPC error: rpc error: code = Internal desc = an error (exit status 32) occurred while running umount args: [/var/lib/kubelet/pods/9d150e08-6b25-478d-96a6-03bfd96f907a/volumes/kubernetes.io~csi/pvc-2a3650cd-8454-40e8-ae4b-31a7f6034dec/mount]

as the umount is already done cephcsi should return success not the Internal server error.

ci/centos/mini-e2e/k8s-1.20 failed with a timeout in the test suite again:
Feb  9 11:52:47.562: INFO: rbd-32742 app  is in Pending phase expected to be in Running  state (8 seconds elapsed)

panic: test timed out after 1h0m0s

Will increase the timeout to 90 minutes.

ci/centos/mini-e2e-helm/k8s-1.20 failed with some unexpected error:
Feb  9 13:15:34.629: INFO: Deleting PersistentVolumeClaim csi-cephfs-pvc on namespace cephfs-3274
Feb  9 13:15:34.645: INFO: waiting for PVC csi-cephfs-pvc in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteMany],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},} to be deleted (0 seconds elapsed)
Feb  9 13:15:36.684: INFO: waiting for PVC csi-cephfs-pvc in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteMany],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},} to be deleted (2 seconds elapsed)
[AfterEach] cephfs
  /go/src/github.com/ceph/ceph-csi/vendor/k8s.io/kubernetes/test/e2e/framework/framework.go:175
Feb  9 13:15:36.690: INFO: Waiting up to 3m0s for all (but 0) nodes to be ready

logs

/retest ci/centos/mini-e2e-helm/k8s-1.20

/retest ci/centos/mini-e2e/k8s-1.20

/retest ci/centos/mini-e2e/k8s-1.20

Failed due to #1795

/retest ci/centos/mini-e2e-helm/k8s-1.20

/retest ci/centos/mini-e2e-helm/k8s-1.20

Resizing a CephFS PVC failed:
Feb  9 15:42:41.257: FAIL: failed to resize PVC with error timed out waiting for the condition
...
Feb  9 15:42:41.271: INFO: At 2021-02-09 15:21:29 +0000 GMT - event for cephfs-32740: {kubelet minikube} FailedMount: MountVolume.MountDevice failed for volume "pvc-75f9da6d-8b2e-431c-a5a0-3a191339f8fe" : rpc error: code = DeadlineExceeded desc = context deadline exceeded
Feb  9 15:42:41.271: INFO: At 2021-02-09 15:21:30 +0000 GMT - event for cephfs-32740: {kubelet minikube} FailedMount: MountVolume.MountDevice failed for volume "pvc-75f9da6d-8b2e-431c-a5a0-3a191339f8fe" : rpc error: code = Aborted desc = an operation with the given Volume ID 0001-0024-f047ded8-7850-46dd-abc2-87233fa3069d-0000000000000001-30e2817d-6aea-11eb-a6c4-863f529beb9b already exists
...

Maybe the provisioner got hung or something, but I did not immediately see it in the logs.

/retest ci/centos/mini-e2e-helm/k8s-1.20

/test ci/centos/mini-e2e-helm/k8s-1.20

@nixpanic looks like merging this PR can affect the cephfs e2e testing. When looking at multiple logs, if feel now cephfs is taking a lot of time for each operation. Merging the PR will make the CI flaky.

@mergifyio  rebase

@Mergifyio rebase

/retest ci/centos/mini-e2e-helm/k8s-1.20

/retest ci/centos/mini-e2e-helm/k8s-1.20

Failed to delete a volume, the PVC that needs to be deleted seems to be gone. Looks like a bug in the test case:
Feb 10 07:28:36.559: INFO: waiting for PVC rbd-13182 in state &PersistentVolumeClaimStatus{Phase:,AccessModes:[],Capacity:ResourceList{},Conditions:[]PersistentVolumeClaimCondition{},} to be deleted (600 seconds elapsed)
Feb 10 07:28:36.564: INFO: failed to delete PVC and application (rbd-13182): timed out waiting for the condition
Feb 10 07:28:36.564: FAIL: deleting PVCs and applications failed, 1 errors were logged


Internal consistency error

Running a large number of tests with the thread local executor, the tasks complete with done state, but the log shows (i) an internal consistency error, and (ii) the task logged as launched after it has completed.
That consistency check is probably not actually required to be true, but it is worrying as it should be true.
2018-10-30 16:29:48 parsl.dataflow.dflow:640 [INFO]  Task 0 submitted for App foo, waiting on tasks [
]
2018-10-30 16:29:48 parsl.dataflow.dflow:646 [DEBUG]  Task 0 set to pending state with AppFuture: <Ap
pFuture at 0x7f23a75ac518 state=pending>
2018-10-30 16:29:48 parsl.dataflow.dflow:304 [INFO]  Task 0 completed
2018-10-30 16:29:48 parsl.dataflow.dflow:310 [ERROR]  Internal consistency error: app_fu is not done for task 0
2018-10-30 16:29:48 parsl.dataflow.dflow:447 [INFO]  Task 0 launched on executor threads

Addressing (i):
handle_update is attached to exec_fu, not to app_fu.
I think this is mostly harmless, but it might better belong as a callback on app_fu.


#7981 is a breaking change

Version
2.5.18-beta.0
Reproduction link
https://jsfiddle.net/50wL7mdz/806315/
Steps to reproduce
Change src attributes in HTML to try w/ different versions
What is expected?
isChanged computed property to be true after delay
What is actually happening?
it doesn't get an updated value of isChanged

Let's consider a bit simplified situation of my real one. Suppose I have a DataWrapper which purpose is to tell whether the held data object was changed or not.
This wrapper has 2 properties: isChanged (read-only, boolean, false by default) and data (read-write, any type); and it is initialized w/ some data.
I think it's clear and not a problem that isChanged property should only have a getter, but for the sake of reactivity, it's allowed to have setter be added. Also, in data setter there's a line
try { this.isChanged = true } catch (e) {/*ignore*/}

for this purpose, i.e. if a setter was defined by some reactivity library (built into Vue in our case), we should invoke it before changing the internal state to let it pass the Vue's check and propagate the change across dependent values:
if (newVal === value || (newVal !== newVal && value !== value)) {
    return
}

But then, since we hadn't any setter initially defined for isChanged property, the following check
// #7981: for accessor properties without setter
if (getter && !setter) { return }

, which was added in PR #7981, is failed and the change is not propagated, which is definitely not a desired behavior.
Commenting of this line completely solves the problem.
So I consider this change as a breaking and think it should be reverted to original behavior.

It's working fine with latest release (v2.5.21)

@posva
But the latest version is used in https://jsfiddle.net/50wL7mdz/806315/ and it does not work, isn't it?
isChanged CP did not updated after delay
And you can see that this behavior differs in 2.5.17 if you use it instead of the latest version

Yes, probably no. But my considerations were the following:

#7981 is classified as a refactoring
The behavior of accessors was changed by that PR in all following versions
Reverting that PR's change completely solves the problem in all following versions and restores the original behavior

Well, I see it like this: #7981 was introduced to skip unnecessary obervations:
In a usual scenario, on object property that only has a getter won't be set through a setter, but by other means unknown to Vue - because Vue can only track changes through a setter, which the original object appearantly doesn't use. So there's no use in making this object reactive. 99 times out of a 100, we would otherwise observe an object property that, as far as Vue can tell, won't ever change.
Now, before this PR, we did add this setter, and you are the 1 in a 100 case where the author actively checks for this setter to call it just to accomodate Vue.
I'm not really willing to call this a breaking change as we never made that implementation detail part of our public API contract. And at the same time, have warnings like this one in our docs:

The object must be plain: native objects such as browser API objects and prototype properties are ignored. A rule of thumb is that data should just be data - it is not recommended to observe objects with their own stateful behavior.
source

Hm... Yes, I forgot about this warning in docs... You are right, it wasn't guaranteed to work in my case.
I examined the code more carefully. Indeed, there's no other possibility to comply with my needs w/o reducing performance, which is not the case due to the rarity of the use case.
Thanks for your replies!

Thanks for understanding. I hope you find a good way to solve your issue


Release pipeline should use main and not master

When renaming master to main, it was not a rename, it was a clone and master was not removed, thus the work on updating the build pipelines was not completed. This work item is to track completion of this work.
Readme updated to point to main, which says it was never built. Assuming there should be a nightly build of main, as well as new builds to be triggered when changes are merged in.
Before cloing up, the master branch should be removed. Should not be an issue as everything is now tracked in main.

Master has been renamed to main. Master was deleted, and release 1.9.1, was done out of main.

Thanks, I now see the build pointing to main have a build :)


Upgrade docker-image to Node 6.x

Seems to be some issues related to webpack and the node6-docker image. Needs to be investigated further.

Docker failed the npm install step, with the following error:
> webpack -p

module.js:442
    throw err;
    ^
Error: Cannot find module 'optimist'
    at Function.Module._resolveFilename (module.js:440:15)
    at Function.Module._load (module.js:388:25)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/node_modules/webpack/bin/webpack.js:15:16)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

reloved in #136


EtherCIS - Data tidy up - Christian to provide script to wipe DB to clean state

CC

Done, see documentation @ https://github.com/ethercis/ethercis/blob/master/doc/DB administration.md
Function purge_db() deployed on the test server as well

thanks @ethercis
@freshehr please confirm you're happy for this to be closed
T

That's fine but it would be really helpful to have this exposed as an API
call (separate admin authorisation) - Marand provide a truncate() call
{{openEhrApi}}/ehrscape-manager/rest/domain/{{domainSystemId}}/truncate
as that makes it easier to truncate and re-provision from a service layer.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email<EMAIL_ADDRESS>twitter: @ianmcnicoll
Co-Chair, openEHR Foundation<EMAIL_ADDRESS>Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 16 June 2017 at 10:16, Tony Shannon<EMAIL_ADDRESS>wrote:

thanks @ethercis https://github.com/ethercis
@freshehr https://github.com/freshehr please confirm you're happy for
this to be closed
T
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RippleOSI/Ripple-openEHR/issues/7#issuecomment-308952477,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQ4ReCzn5k44rY2TuEfooUReEZWA_gkks5sEivDgaJpZM4N7f-d
.

I understand what you mean , but this is really a dangerous hack (since nobody does care to do a DB backup before doing the DB purge... pretty usual IMO). I much prefer to keep it for the happy initiated few who are supposed to know what they are doing, hence as an administrative - logged - operation.

ok - understood. Park for now.
Ian

@freshehr - are you ok for this to be closed on that basis.

Agreed - in retrospect ;)
Ian


GraphQLSchema: NoSuchKey / The specified key does not exist.

Describe the bug
Push in latest update 4.21.4 does not work for me:
amplify push fails with odd error messages:
UPDATE_FAILED               GraphQLSchema
AWS::AppSync::GraphQLSchema Fri Jun 19 2020 16:21:23 GMT+1200 (New Zealand Standard Time)
The specified key does not exist.
(Service: Amazon S3; Status Code: 404; Error Code: NoSuchKey; Request ID: E236F3C36A8F008C; S3 Extended Request ID: sYqzOjHDdjjatnRJzSHkRAaynqn7VbOOEsWbflblgyu/vvdjCsQIk9DsKcxRU6sSk99Syj/uxto=)

Amplify CLI Version
4.21.4
To Reproduce
Seems to be 100% reproducible: go to 4.21.4 and it fails, back to 4.21.3 and it works.
Expected behavior
Push working as usual.
Desktop (please complete the following information):

OS: Ubuntu 20.04
Node Version: v12.18.0

Additional context
Rollback to 4.21.3 and everything works.

@berenddeboer
A few questions here

Was the command amplify push --force or amplify push --yes?
Was an update needed before doing the push?
What were the steps taken that lead up to this error?

@berenddeboer thanks for reporting the issue for your case an amplify push --force will provide a workaround to unblock you.
In the meanwhile stay on .3, the recent fix for hashing has a regression which is causing this failure.

Closing this issue as we have deprecated version 4.21.4 due issues with @key. Should you experience any issues related to this in the latest version, as of now v4.21.3. Please comment below.

This issue thread seems more appropriate for my last comment:
https://github.com/aws-amplify/amplify-cli/issues/4232#issuecomment-646690031
One work around I found in v4.21.4 was push an update for both api and storage, which succeeded. For instance I added a space on schema.graphql and modified the storage with group user r/w privileges.
off topic:
fyi complex objects(images, files , etc..) only works when you enable both Auth & User Groups, gives me 'access denied' when using Auth Users only.

Hi @SwaySway
Our CI/CD (appcenter) process for react native fails occasionally, our pre-build script calls npm install -g @aws-amplify/cli and does an amplify push. We eventually resolve by hacking at the schema file and force pushing.
Here is an example of error with request ID if helps.
Reason: The specified key does not exist. (Service: Amazon S3; Status Code: 404; Error Code: NoSuchKey; Request ID: 3A188FA775B43D4F; S3 Extended Request ID: f5Xj2Bp7+fn4CIVmA+XPWp2e0JGj2l2ZyDI9/kZnTIu78+DDZ5D/x2gwvOxroZJvEIYASmWFXfs=; Proxy: null)

Hi @SwaySway
Our CI/CD (appcenter) process for react native fails occasionally, our pre-build script calls npm install -g @aws-amplify/cli and does an amplify push. We eventually resolve by hacking at the schema file and force pushing.
Here is an example of error with request ID if helps.
Reason: The specified key does not exist. (Service: Amazon S3; Status Code: 404; Error Code: NoSuchKey; Request ID: 3A188FA775B43D4F; S3 Extended Request ID: f5Xj2Bp7+fn4CIVmA+XPWp2e0JGj2l2ZyDI9/kZnTIu78+DDZ5D/x2gwvOxroZJvEIYASmWFXfs=; Proxy: null)


druid批量update语句不支持。

详情见https://blog.csdn.net/mrczr/article/details/78903468

Hi @136900923, would you please write this issue in English?

I think this issue belongs https://github.com/alibaba/druid, it should be closed

@136900923 这个问题不属于 Apache Druid 数据库，是关于 Alibaba Druid 连接池框架的。

@zeroro88 @asdf2014 thank you for the checking.

@jihoonson You are welcome.


Incorrect Last Enqueued Date

It seems as though the last enqueued dates are not reflecting the actual last time the job was ran, but rather the time since midnight. Even if I manually enqueue a job the date does not update. Any ideas as to what I could be doing wrong?

The problem is that last enqued time is used internaly for sidekiq-cron to decide if it needs to be added or not.


HWKAPM-732 Replace the 'business' transaction concept with just simpl…

…e 'transaction'

@ammendonca Could you please review?
This PR relates to renaming the concept "business transaction" to simply "transaction" - business txn is more aligned with business transaction management which was the original focus of the proiject, but now the focus is the more broad application performance management, use of the more generic term "transaction" seems more appropriate.

Tested and everything seems to be working fine. There are a few references to *BT (eg: managedBT, ignoredBT, etc) but that may not be an issue ?

@ammendonca Have updated to also change those, if you don't mind checking again. Thanks.

retest this please

LGTM. Seem to have found two unrelated issues (changing the hostname has no effect and if fault is selected as a property on the sidebar, selecting different TXn won't change the available values), but these are also present in master. Will report and address these issues separately.

@ammendonca Thanks!


Add action should have a remove ..

aio app add action makes it simple to add an action to a project.
The developer does not need to know that the tooling added actions/generic-1/ or added test/actions/generic-1.test.js, or that it changed package.json, or manifest.yml .... however, if the developer wants to remove the action, they need to know all these things ...
forgetting to remove the tests/generic-1... will make the tests fail
forgetting to modify manifest.yml will output unclear errors
🔥🐝  aio app build
✖ Building actions
    Error: ENOENT: no such file or directory, lstat 'actions/generic-1/index.js'
    Code: ENOENT

^^^ it is unclear what I need to do to resolve this issue, all I know is that now my app doesn't build
Suggestion: add an aio app remove action [name] command that is the compliment of aio app add action

Duh, this does exist ... it is called aio app delete action [name]

Duh, this does exist ... it is called aio app delete action [name]


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 10:21:29 on 2023.06.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 0, errors out: 0
Original problem ID: 28655
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=28655

Problem has been resolved in 12m 0s at 10:33:29 on 2023.06.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 28655


Accessabitlity

Is our website accessable for everybody

https://developers.google.com/web/fundamentals/accessibility/


os: Stdin.Stat().Size() always returns 0 with GOOS=wasip1 GOARCH=wasm

What version of Go are you using (go version)?

go1.21.0 darwin/arm64

Does this issue reproduce with the latest release?
Yes, but only tested against GOOS=wasp1 GOARCH=wasm
What operating system and processor architecture are you using (go env)?
go env Output
GOOS=wasp1 GOARCH=wasm

What did you do?
read Stdin, check stat.size
stdin := os.Stdin
stat, _ := stdin.Stat()
fmt.Println("size:", stat.Size())

run via wasi runtime, piping input to stdin
echo "input" | wasmer run wasi_binary

What did you expect to see?
size should match contents of stdin
What did you see instead?
size of 0 is always returned

CC @golang/wasm.

Hello @williamwebb, thanks for reporting the issue.
I believe that the behavior you expect is not something that Go can satisfy; the webassembly runtime is in charge of implementing host system calls such as the one involved in getting the size of an open file, the Go standard library (and in particular the os package in this case) only expose what the runtime returns.
in your example, it appears that wasmer returns a zero size for the standard input stream; this behavior will be the same regardless of the original programming language from which the webassembly module was compiled.
That being said, I was curious to explore how other platforms may behave, so I tested your code snippet:

on darwin/arm64

$ echo input | go run main.go
size: 6

on linux/amd64

$ echo input | go run main.go
size: 0

As you can see, programs that rely on the behavior of asking the size of stdin will not be portable across platforms; combinations of operating systems and webassembly runtimes will produce different results.
@dmitshur I believe we can close this issue since Go behaves as expected in this case.

Thanks for investigating this report.


Update build-custom-delegate-images-with-third-party-tools.md

Typos fix
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Preview environment: https://ci.pr.harness.io/pr-585


Bug: OSError Filename too long

I'm using the File backend and I'm passing a relatively large dictionary as a param to the celery task. Is it possible to use a hash or something else instead of the function params to generate the task filename?

Thanks for report, I've submitted a PR with a fix.

@mlaythe this is fixed in version 3.0.0.
Thanks for the fix @xuhcc


GPU CUDA problems

Hello. Just have got an additional old computer with old nvidia geforce 9800 GT. It is not working (for this card last driver is 342.00). Is there something wrong or this card is unacceptable for mining?

Read this https://litecoin.info/Mining_hardware_comparison

same problem. Do u solved it?

No, I think my videocard is very old for mining.


[FEATURE] Support for global keybindings/hotkeys

Like this extension but built in
Hotkeys that can be customized in browser settings that will allow to easily play/pause and next/prev track

Thanks for the suggestion! Seems like a great addition. If anyone is interested in taking on development of this feature, feel free to comment!

I think adding this to manifest
"commands": {
      "play-pause": {
        "suggested_key": {
          "default": "Ctrl+Shift+Space"
        },
        "description": "Play/Pause"
      },
      "next": {
        "suggested_key": {
          "default": "Ctrl+Shift+Right"
        },
        "description": "Next"
      },
      "previous": {
        "suggested_key": {
          "default": "Ctrl+Shift+Left"
        },
        "description": "Previous"
      }
    }

and adding this should work
chrome.commands.onCommand.addListener(command => {
  switch (command) {
    case 'play-pause':
      sendToContent({
        name: MusicControllerMessage.PLAY_PAUSE
      })
      break;
    case 'next':
      sendToContent({
        name: MusicControllerMessage.NEXT
      })
      break;
    case 'previous':
      sendToContent({
        name: MusicControllerMessage.PREVIOUS
      })
      break;
  }
});

That seems like a reasonable quick solution! Do you want to give it a try and send a PR? We'd also want to have a button on the settings page that sends the user to the extension configuration page where those key controls can be configured.

If you mean this, it already exists


drivers: intc: plic: set edge-triggered register address using compat

Define the edge-trigger register base address based on whether the PLIC node in the devicetree has an additional compatible that supports edge-triggered interrupt.
Update the devicetree binding of andes_v5_ae350 and telink_b91 accordingly.
Fixes #64675

please review @amr-sc

Pulling this back as draft as it has a commit from #65847, but feel free to review

@fkokosinski - any general thoughts about this PR?

can someone from Andes confirm that the nceplic100 is present on all types of cores supported by the upstream andes_v5_ae350 platform please? cc @kevinwang821020 @jimmyzhe

Hi @ycsin,
yes, currently andes_v5_ae350 represents ae350 bitstream integrated with NCEPLIC100.
We also have some ae350 bitstreams integrated with standard CLIC instead of PLIC, but they do not yet support Zephyr upstream.


[FEAT] Support conan-based installation of librealuvc dependencies

~Work-in-progress. Do not merge.~  Works great! -John
Hi platforms team! This is Nick from the tracking team (they/them). I wanted to have librealuvc set up for easy building so I could get low-level access to the Rigel camera & images for some hacking/experimental projects.
This PR sets up a conanfile.py for conan to install these dependencies. You can contrast these version numbers against the numbers in build.sh; these were picked to be as close as possible while still pulling from the conan-center repository:

"boost/1.70.0",
"eigen/3.3.7",
"opencv/4.5.0",
"protobuf/3.9.1"

It also modifies the readme to start with conan-based dependency installation instructions. I don't know for sure if my local machine is already set up for other dependencies, but if that's the case, we should just be able to add more libraries to the conanfile to have a proper build configuration.
It also modifies the central CMakeLists.txt to:

Have some explicit structure, added while I was trying to understand what was going on
Add and document the necessary invocations that tie in to the conan setup

I currently think this branch is essentially "done" for having a basic conan build setup; running the commands in the readme now, I can quickly build and successfully run viewer.exe and get Rigel images out. From the readme:
conan install . --install-folder build -r conan-center
conan build . --build-folder build

The -r conan-center part is necessary if you've modified your conan remote setup for building e.g. libtrack by changing your default remote to gitlab. If you don't have conan-center defined you may need to add it:
conan remote add conan-center https://conan.bintray.com

However, librealuvc is important to the libtrack stack, so I expect we'll want to sync a bit before accepting a change like this, since it changes some of the pulled-in dependency versions in order to easily reference available versions in the conan-center package repository.

Hi, this is John from the Tracking Team.   I just added Github Actions Continuous Integration to this PR to help everyone verify that it works (on Windows).  This should make it easier to test and merge new PRs coming down the pipeline.

Thank you, Marin; I hadn't seen the Gitlab Recipes, these are indeed super helpful.
Given that they're all in the private Gitlab space, I see two options:

Have the Github Action pull the gitlab::conan-librealuvc repo, and execute it via secret tokens.
Move the meat of the Gitlab CI process into the public repo, and have the Gitlab process be a thin-shell for executing that.

or I suppose:

Leave it as is and close this since there's already adequate Conan-based CI in Gitlab :grin:

(The primary casualty of this being public access/convenience)
@nickjbenson How do you feel about these options?


$VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList

Something is wrong this part of script.
PS C:> $VnetRoutingConfig = $Spoke1Connection.RoutingConfiguration    # We take $Spoke1Connection as baseline for the future vnet config, all vnets will have an identical config
PS C:> $NoneRT = Get-AzVhubRouteTable -ResourceGroupName $RG -HubName $HubName -Name "noneRouteTable"                  PS C:> $NewPropRT = @{}
PS C:> $NewPropRT.Add('Id', $NoneRT.id)
PS C:> $PropRTList = @()
PS C:> $PropRTList += $NewPropRT
PS C:> $VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList
Exception when defining "Ids": "Cannot convert the value" System.Object [] "of type" System.Object [] "into type
"Microsoft.Azure.Commands.Network.Models.PSResourceId". "
No linha:1 caractere:1

$VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList

  + CategoryInfo          : NotSpecified: (:) [], SetValueInvocationException
  + FullyQualifiedErrorId : ExceptionWhenSetting

Print Screen.

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

ID: 5fe43b05-6297-1bcc-a7d2-6e3ffac5e828
Version Independent ID: b9d85d1e-be9f-ce4e-b3cf-89ba62942b9a
Content: Tutorial: Secure your virtual hub using Azure PowerShell
Content Source: articles/firewall-manager/secure-cloud-network-powershell.md
Service: firewall-manager
GitHub Login: @jomore
Microsoft Alias: victorh

Thanks for bringing this to our attention. We are actively investigating and will get back to you soon.

@evandromalmsteen, Apologies for the delay in response. I see the code works perfectly. There is no issue with the document.

You are doing in Azure Cloud Shell. I will test it too.
I'm doing in azure power shell in Windows 10 build 1909. I Migrated from Windows PowerShell 5.1 to PowerShell 7 and did rollback this module to Az.Network version 3.2.0.

ty.

Hi guys,
I want to let all recorded here, the problem persist in azure powershell only following the prerequisites above in my desktop.
I tested in azure cloud shell and is working fine.
My version PS and PC.

Ty.

Hi guys,
I want to let all recorded here, the problem persist in azure powershell only following the prerequisites above in my desktop.
I tested in azure cloud shell and is working fine.
My version PS and PC.

Ty.

@evandromalmsteen, Glad to hear that your issue has been resolved! We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.

@evandromalmsteen, Glad to hear that your issue has been resolved! We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


doc: [124686] Specify SHA-1 thumbprint

Fix for https://github.com/MicrosoftDocs/azure-docs/issues/124686
Bonus:

Add example
Removed extra space and extra non-printable characters.

@microsoft-github-policy-service agree

@dlepow
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Any update on this ?

@dlepow
Can you review this old PR and determine whether it needs to be closed or merged?
@MicrosoftDocs/public-repo-pr-review-team


Reverse of indexBy

I'm working with data in the following shape:
{ xyz: { title: 'A' },
  abc: { title: 'B' } }

And transforming it into:
[ { id: 'xyz', title: 'A' },
  { id: 'abc', title: 'B' } ]

I'm wondering if this is a general/common enough problem to warrant either a core contribution or cookbook entry, and if so, what a desirable name / API might look like.
Proposal:
deindexBy(id => ({ id }), dataset);

The idea here is to take a function that will transform the keys into objects that will subsequently be merged with their respective values. Thoughts?

It's unquestionably worth putting in the Cookbook.  I'm not so sure about the library itself.
As to the API, can you think of any other useful function besides one that essentially gives a property name to the key?  If not , might this not be a cleaner API?:
deindex('id', dataset);

Yes, in my specific case I have a need to coerce the keys to numbers. Otherwise I agree that I'd prefer that simplicity.

Well, you've already demonstrated a reason for the more sophisticated API.
Again, I can definitely see this in the Cookbook.  If you want to push for its inclusion in the main library, please feel free to try to make the case.  But the Cookbook is simply part of a publicly editable wiki, and you can add it yourself, if you like.

I've this function defined somewhere:
const listFromObject = curry(
    // Don't use assoc, deliberately control the order.
    (keyPropName, obj) => values(mapObjIndexed((v, k) => ({ [keyPropName]: k, ...v }), obj))
);

And even though I had to use it a few times (almost always in quick-and-dirty scripts), I agree that it probably belongs to the cookbook (at least as long as all of Ramda's functions are under a single namespace).

Sounds good. I agree this belongs in the cookbook.
@asaf-romano Nice, I like that solution. Seems more efficient than what I had come up with, which uses juxt with some mergeAll / keys / values noise. Can you expand on the Don't use assoc, deliberately control the order comment?

As mentioned, I use this mainly in scripts, which are all about eye-balling the output, sometimes. Since json output is controlled by js iteration order, here's what happens if you use plain assoc:
{
   oldProp1: 1,
   oldProp2: 1,
   oldProp3: 3,
   allNewProp: "a"
}

And here's what happens if you "assoc" the other way:
{
   allNewProp: "a"
   oldProp1: 1,
   oldProp2: 1,
   oldProp3: 3
}

This solutions works for me:
array = keys(object).map(property=> object[property]);

@guilhermejcgois: That looks to be just values.  The functions here are a bit different.


[FEATURE] Configurable Note Drop-Off Radius

Is your feature request related to a problem? Please describe.
Due to the limited range that notes currently broadcast to players some users are resorting to building note repeaters that re-broadcast the notes they hear to extend the range. This can cause issues because the number of instruments playing at once can quickly exceed the current maximum of 15 and cause notes to start to drop.
Describe the solution you'd like
The ability for:

Servers to configure, via the config file, how far note packets extend when broadcast to players.
Clients to configure, via the config file, the above and how aggressive the volume fall-off for notes is.

Describe alternatives you've considered
N/A
Additional context
N/A

Version 4.1.0 has been release including this feature via the new Relay block!


Ability to control the behavior of attaching scroll parents

This is a bit of a complex issue and I've not been able to create a simple CodePen demo.
I have a React component that acts as a Popper reference that is usable in multiple locations, including in portals. Popper is not able to find the correct element to attach scroll handlers to because the element with overflow scroll is not a parent of the reference element.
Currently I have a hacky way of dealing with this by adding matching DOM attributes at the portal mount point and where the portal is created and then linking them up by patching getParentNode to look for elements with those attributes and then treating the element with the corresponding ID as parent of that node.
function getParentNode(element) {
  if (element.nodeName === 'HTML') {
    return element;
  }
  if (element.hasAttribute('x-popper-element-id')) {
    return document.querySelector(`[x-popper-target-id=${element.getAttribute('x-popper-element-id')}]`);
  }
  return element.parentNode || element.host;
}

Because there's no API to modify this behavior I have to also copy getScrollParent, attachToScrollParents and setupEventListeners.
It would be nice if there was a way to do this without patching a bunch of internal code. I'm not sure what the API would look like.
I can look more into creating a CodePen to reproduce this issue if needed.

A CodePen demo would help a lot to understand what's exactly happening, it would be cool if you could provide it.

Also. Aren't these methods exposed by Popper.Utils by chance?

I'm still working on narrowing this down to the minimal reproducible example.
Those functions are provided by Popper.Utils but since I need to modify the last function in the chain I need to copy+paste all of them and update the reference in getScrollParent to my modified function.

I have 3 CodePens:
Demonstrating the issue
Fixing the issue by rearranging HTML (not possible in my case)
Fixing the issue by adding extra yucky plumbing

You can fix your problem doing this:
https://codepen.io/FezVrasta/pen/zdzQQG


Add warning when not on current version of API docs

Our SEO was bad for qiskit.org, so old versions of qiskit.org API pages are often the top results. Those then get redirected to ibm.com and users don't realize they're on the old version of the docs unless they open up the version selector

We've heard a lot of user complaints about the docs being out-of-date, when really they're only looking at the old version. So we should make it more obvious to users by adding a warning. This is only for API pages.
Example:

Text suggestion:  "This document is for an unsupported version of Qiskit. To view the current documentation, choose the version marked (latest) from the dropdown at the top of the page. "
Maybe @abbycross can think of a way to shorten it, but I do think it's important to tell them HOW to view the current version.

Text suggestion: "This page refers to an unsupported version of Qiskit. To view the current documentation, choose the version marked (latest) from the version menu. "

Just a couple small changes, and changing "top of the page" in case the dropdown ends up not being at the top of the page for mobile users 🤷

Designs are completed for the banner on old API's and can be found here.

@gracelindsell @Vanguardbots @javabster, do we want this dev warning to show up for Qiskit 0.46 when 1.0 is released? What about Qiskit 1.0 when Qiskit 2.0 is released? That is, should we have the notion of "stable" docs versions that aren't "latest" but also don't have a dev warning saying there are newer docs available?
My opinion: this nuance is not necessary. Even when Qiskit 0.46 is released, we do still want to encourage people to switch to Qiskit 1.0. We want them to realize they are not on the latest.

@Eric-Arellano I agree with your opinion. The goal is to have people realize they are not on the latest version and thus to update that language upon release

Added! Thanks @kaelynj and @gracelindsell


Opening room links with ?via does not work and shows no error

When I open a link like:
https://matrix.to/#/!gPiZOnZNGoVDyQhYpG:matrix.org?via=matrix.org
I get asked whether to use the Riot app as expected. However when I do so, a window pops up for a fraction of a second and immediately disappears again. Removing ?via=matrix.org from the url makes it work as expected.
In logcat, I get this:
--------- beginning of system
02-22 18:32:36.174  2382  4348 I ActivityManager: START u0 {act=android.intent.action.VIEW cat=[android.intent.category.BROWSABLE] dat=https://matrix.to/... flg=0x13080000 cmp=im.vector.alpha/im.vector.activity.VectorUniversalLinkActivity (has extras)} from uid 10091 on display 0
02-22 18:32:36.304  2382  2407 I art     : Background partial concurrent mark sweep GC freed 4187(404KB) AllocSpace objects, 1(20KB) LOS objects, 33% free, 18MB/27MB, paused 2.470ms total 104.791ms
02-22 18:32:36.307 30673 30673 D VectorApp: onActivityCreated im.vector.activity.VectorUniversalLinkActivity@870323
02-22 18:32:36.357 30673 30673 D VectorUniversalLinkReceiver: ## onReceive() IN
02-22 18:32:36.357 30673 30673 D VectorUniversalLinkReceiver: ## onReceive() uri getDataString=https://matrix.to/#/!gPiZOnZNGoVDyQhYpG:matrix.org?via=matrix.orgisSessionActive=true isLoginStepDone=true
02-22 18:32:36.358 30673 30673 D VectorUniversalLinkReceiver: ## onReceive() action = BROADCAST_ACTION_UNIVERSAL_LINK
02-22 18:32:36.358 30673 30673 D VectorUniversalLinkReceiver: ## onCreate() intentUri - host=matrix.to path=/ queryParams=null
02-22 18:32:36.359 30673 30673 E VectorUniversalLinkReceiver: ## parseUniversalLink : empty dictionary
02-22 18:32:36.359 30673 30673 E VectorUniversalLinkReceiver: ## onReceive() Path not supported: /
02-22 18:32:36.399 26881  5582 I OpenGLRenderer: Initialized EGL, version 1.4
02-22 18:32:36.528 30673 30673 D VectorApp: onActivityDestroyed im.vector.activity.VectorUniversalLinkActivity@870323
02-22 18:32:36.536 30673 30673 E Memory usage: Active application : onTrimMemory from VectorHomeActivity level=20
02-22 18:32:36.537 30673 30673 E Memory usage: ---------------------------------------------------
02-22 18:32:36.538 30673 30673 E Memory usage: ----------- onTrimMemory -----------------
02-22 18:32:36.539 30673 30673 E Memory usage: ---------------------------------------------------
02-22 18:32:36.539 30673 30673 E Memory usage: usedSize   35 MB
02-22 18:32:36.540 30673 30673 E Memory usage: freeSize   7 MB
02-22 18:32:36.540 30673 30673 E Memory usage: totalSize  43 MB
02-22 18:32:36.540 30673 30673 E Memory usage: ---------------------------------------------------
02-22 18:32:36.542 30673 30673 E Memory usage: availMem   509 MB
02-22 18:32:36.542 30673 30673 E Memory usage: totalMem   1876 MB
02-22 18:32:36.542 30673 30673 E Memory usage: threshold  134 MB
02-22 18:32:36.543 30673 30673 E Memory usage: lowMemory  false
02-22 18:32:36.543 30673 30673 E Memory usage: ---------------------------------------------------
02-22 18:32:37.147  2382  4521 W ActivityManager: Finishing task with all activities already finished
02-22 18:32:37.147  2382  4521 W ActivityManager: Duplicate finish request for ActivityRecord{4051b97 u0 android/com.android.internal.app.ResolverActivity t7395 f}

Note the (somewhat misleading IMHO) onReceive() Path not supported: / message in there.
It seems there are two problems here:

Links with ?via are not supported (I'm not sure how well specified these links are, but this link is generated by Riot web, so I would be nice to support it).
No error message is shown.

It seems all this also applies to riot.im links rather than matrix.org links (though I can't quite remember how I got a riot.im link with a ?via appended, but I did actually send it to myself during testing at some point).

For reference, it seems the ?via option was introduced here: https://github.com/matrix-org/matrix-react-sdk/pull/2250


sig-scale perf/scale tests need to look at virt-handler resource utilization metrics

Is your feature request related to a problem? Please describe:
Resource utilization benchmarks were added for virt-controller, and virt-api pods here, however virt-handler is missing.
This PR needs the virt-handler metrics to understand impact of the change.
Describe the solution you'd like:
In order to get the valuable information from the perf/scale test, the following metrics are needed:

number of VMI scheduled per node in e2e test
avg, min, max of (avg over time of virt-handler) pods

Describe alternatives you've considered:
Create a separate test with 1 node and read virt-handler resource utilization. This was rejected as it will lead to additional test load in CI. It will also create complication of how to merge the metrics from these two test lanes.
Additional context:
None

/label sig-scale

cc @xpivarc since I remember you had some thoughts regarding this.


Confusing incompatibility between "the same type" twice

Consider the following program (cf. https://github.com/dart-lang/sdk/issues/36569 where this came up):
void main() {
  var bar = Bar()..setList();
}

void addItem(List list, Object item) => list.add(item);

abstract class Foo<T> {
  List<T> get list;
  void setList<T>({List<T> value = const <Null>[]});
}

class Bar implements Foo<int> {
  List<int> list;
  void setList<int>({List<int> value = const <Null>[]}) {
    list = value;
  }
}

We get the following response from the dart vm (at the indicated versions):
lang/dart/scratch/201904(master %)$ ~/bin/dart-sdk-2.0.0-dev.63.0/bin/dart n015.dart
lang/dart/scratch/201904(master %)$ ~/bin/dart-sdk-2.0.0-dev.64.0/bin/dart n015.dart
n015.dart:16:12: Error: A value of type 'dart.core::List<#lib1::Bar::setList::int>' can't be assigned to a variable of type 'dart.core::List<dart.core::int>'.
Try changing the type of the left hand side, or casting the right hand side to 'dart.core::List<dart.core::int>'.
    list = value;
           ^

The error seems to be spurious, the types should be the same List<int> in both cases, no matter how that's spelled.
I would assume that this is a front-end issue, so I'll use that label.

Sorry, I misread the code, int is actually the name of a type variable declared by Bar.setList.
This means that 2.0.0-dev.63.0 had a bug (because it did not detect the type error), but that's a long time ago. ;-)
Double-checking, I think everything is working as intended. Hence, I'll close the issue.

As a side note I'll try to make the message be less bad.

Sounds like that would essentially be concerned with the readability of constructs like #lib1::Bar::setList::int? If you know how to read that then the message isn't that bad, I think.

In the above, true, but today the error message is
Error: A value of type 'List<int>' can't be assigned to a variable of type 'List<int>'.
 - 'List' is from 'dart:core'.

OK, that's in need of improvements!


human reads

Right now the part that removes the human reads from the tables is missing, therefore those reads are present in the haybaler tables.

You mean this script, correct ?
bash runbatch_metagen_window_filter.sh
I wonder where the old Wochenende_postprocess removes these human reads (a haybaler section perhaps?),
because reporting uses bam.txt files (unfiltered) and haybaler uses reporting results.

Yeah, I meant that script. Interestingly, it seems to be run after haybaler in the Wochenende_postprocess, so I don't really know how there were no human reads in the haybaler csvs.
So my question is: Should there be human reads in the haybaler  csvs or not? (I remember seeing csvs with them (a year ago) and some without (more recent))

I think Sophia excluded human reads in the python or bash scripts, maybe because she needed the numbers for normalization first, but not sure. Normalization should be done by the reporting steps.
You can see with this search that they are excluded with grep -v for the heatmaps and heat trees.
https://github.com/MHH-RCUG/haybaler/search?q=1_1_1

Ilona will know best if the human info is completely excluded or not and since when.