chore: rename ratatui-org to ratatui

All urls updated to point at https://github.com/ratatui
To update your repository remotes, you can run the following commands:
git remote set-url origin https://github.com/ratatui/ratatui

Only 3 PRs/issues away from #1337


Disable auto-merge when creating deployment

Github automatically creates a merge commit when deploying a branch which is unnecessary.

Thank you @steel


Magic numbers in Android Java Impl and Jupyter Notebook do not match

The file generated by your ipython notebook writes a magic number of:
fout.write(struct.pack("i", 0x74666C74))

The Android Java implementation checks for the presence of 0x5553454e, which is also what is present in the file in the models directory.
https://github.com/nyadla-sys/whisper.tflite/blob/a7c02fdb52b06023da010063c9033152c3f84a77/whisper_android/app/src/main/java/com/whispertflite/utils/WhisperUtil.java#L82

Magic number can be any four character string   like "ABCD". It can be changed to your favourite string. But, need to check same string while loading vocab for validation.


BD Veritor Onboarding – Create Org and Sender Settings

Acceptance Criteria

[x] Added to organization.yml and create yamlitos

[x] Customer status = testing

[ ] Added to prod settings table
[x] Added to staging settings table
[ ] Key exchange

[ ] Token auth

[x] Received public key from sender in staging

[x] Saved public key in keybase

[ ] Received public key from sender in prod

[ ] Saved public key in keybase

[x] Associated public key with sender settings in staging
[ ] Associated public key with sender settings in prod

FYI: this ticket can be completely concurrently with “Validate Test Files” ticket for this API sender
To Do

[ ] RS engineer: update this ticket with comments with every interaction with sender

added public key to bd-veritor in staging


Update configure-unit-tests-by-using-a-dot-runsettings-file2.md

@TinaLiuGirl : Thanks for your contribution! The author, @sharanya-rao, has been notified to review your proposed change.

#please-close


chore(github/release-drafter) add skeleton for release drafter

as per https://github.com/jenkins-infra/helpdesk/issues/4278#issuecomment-2435606001
setup release drafter

Result once merged:

First GHA run for release-drafter was successful: https://github.com/jenkins-infra/docker-geoipupdate/actions/runs/11503328105
The first draft release is available: https://github.com/jenkins-infra/docker-geoipupdate/releases/tag/untagged-9b4d05ed3a3e3e27620a


Piral with Rush

Bug Report
For more information, see the CONTRIBUTING guide.
Prerequisites

[x] Can you reproduce the problem in a MWE?
[x] Are you running the latest version?
[x] Did you perform a search in the issues?

Environment Details and Version
Windows 10, pnpm 7.33.5,  npm 6.14.15, Node.js 18.17.1, Rush 5.122.2
Description
I try to get a working example of Piral with Rush and following the tutorial https://docs.piral.io/guidelines/tutorials/23.2-monorepo-rush I'm not able to get it.
Let's start with NPM as package manager:
NPM
Do the git and rush init. Change to npm in rush.json. Add the shell with the npx piral new ... command. Check the rush.json if the project was added. Use rush update to install packages and finally call rush build.
PS C:\Projekte\piral-npm> rush build

Rush Multi-Project Build Tool 5.112.2 - https://rushjs.io
Node.js version is 18.17.1 (LTS)

Starting "rush build"

...

==[ FAILURE: 1 operation ]=====================================================

--[ FAILURE: app-shell ]-------------------------------------[ 0.08 seconds ]--

node:internal/modules/cjs/loader:1080
  throw err;
  ^

Error: Cannot find module 'C:\Projekte\piral-npm\packages\app-shell\node_modules\piral-cli\lib\piral-cli.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v18.17.1

Operations failed.

rush build (0.10 seconds)

Hmmm, OK, check the node_modules folder. As you can see in the screenshot, it doesn't install the devDependencies in the folder and therefore it's missing piral-cli.

Check the rush temp folder of modules in common\temp\node_modules: This contains the piral-cli but with the way how resolving works for modules, it of course cannot be found there.
Do something you shouldn't do: npm install in the app-shell folder. Now building works.
Add a pilet:
PS C:\Projekte\piral-npm\packages\app-shell> npx pilet new app-shell --no-install --target packages/foo-pilet --npm-client rush
+ piral-cli v1.4.3
✖ [0002] Could not install the package "app-shell@latest" using rush. Make sure rush is correctly installed and accessible: Error: npm WARN deprecated<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:*

...

I mean, things are changing pretty fast but afaik workspace:* is something working only when using pnpm. I double checked and my rush.json and set up was all done with:
  // "pnpmVersion": "7.33.5",

  "npmVersion": "6.14.15",
  // "yarnVersion": "1.9.4",

The two issues are very crucial, so I stopped trying it with npm and changed to pnpm.
PNPM
Everything is working fine until try to build the app-shell:
rush build
...
- Reading configuration ...
- Starting emulator build ...
ℹ Bundle emulator ...
⚠ [0176] Installing default bundler since no bundler has been found.
- Installing piral-cli-webpack5 ...
✖ [0002] Could not install the package "piral-cli-webpack5@^1" using rush. Make sure rush is correctly installed and accessible: Error

No problem just do rush add -p  piral-cli-webpack5 --dev in the app-shell folder and it works.
Now, add a pilet:
npx pilet new app-shell --no-install --target packages/foo-pilet --npm-client rush
+ piral-cli v1.4.3
✖ [0002] Could not get externals from "piral": "Error: Can't resolve 'piral/package.json' in 'C:\Projekte\piral\packages\foo-pilet'
✖ [0002] Could not get externals from "piral-core": "Error: Can't resolve 'piral-core/package.json' in 'C:\Projekte\piral\packages\foo-pilet'
✖ [0002] Could not get externals from "piral-base": "Error: Can't resolve 'piral-base/package.json' in 'C:\Projekte\piral\packages\foo-pilet'
⚠ [0078] Did not find any reference to either piral, piral-core, piral-base. No framework dependencies are shared.
✔ Pilet scaffolded successfully!

Hmmm lots of errors. Let's just try to install the packages:
rush build
Progress: resolved 549, reused 540, downloaded 0, added 0, done
../../packages/foo-pilet postinstall$ pilet declaration
│ + piral-cli v1.4.3
│ Cannot find module 'app-shell/package.json'
│ Require stack:
│ -<EMAIL_ADDRESS>│ -<EMAIL_ADDRESS>│ -<EMAIL_ADDRESS>│ -<EMAIL_ADDRESS>│ -<EMAIL_ADDRESS>│ -<EMAIL_ADDRESS>│ + Find detailed descriptions at https://docs.piral.io/code/search
└─ Failed in 688ms at C:\Projekte\piral\packages\foo-pilet
 ELIFECYCLE  Command failed with exit code 1.

This is a combination of problems in the postinstall script pilet declaration with how resolving packages, pnpm and declarations.js works. declarations.js is calling const path = require.resolve(`${piralInstance}/${constants_1.packageJson}`);
Resolving just traverses recursively the parent dirs and tries to find the module in a node_modules folder. Omitting some user dirs and global, it looks like this for me:
[
<EMAIL_ADDRESS><EMAIL_ADDRESS>
<EMAIL_ADDRESS><EMAIL_ADDRESS>  'C:\\Projekte\\piral\\common\\temp\\node_modules\\.pnpm\\node_modules',
  'C:\\Projekte\\piral\\common\\temp\\node_modules',
  'C:\\Projekte\\piral\\common\\node_modules',
  'C:\\Projekte\\piral\\node_modules',
  'C:\\Projekte\\node_modules',
  'C:\\node_modules',
]

But pnpm symlinks the workspace:* dependencies only to the projects node_modules dir. In this case in packages/foo-pilet/node_modules/app-shell/.
Steps to Reproduce
Just follow the tutorial https://docs.piral.io/guidelines/tutorials/23.2-monorepo-rush
Expected behavior
A working example ;)
Actual behavior
See description.
Possible Origin/Solution
For NPM: It looks like rush is creating the node_modules folder in a wrong way but after that it looks like piral creates a wrong package.json for rush? Don't really know which part of the stack is responsible for it.
For PNPM: First errors when adding, I have no idea. Second error: Maybe piral-cli needs an additional parameter to point to the pilet's folder? That way it would see the symlinked packages pointing to other packages of the monorepo added via workspace:*.

I am not sure if we have the capacity to do that.
Either its picked up by the community or we will abandon Rush. The fact is that Rush was already an outdated solution back then and I am not sure if they managed to have their solution working / what they did in the meantime. That being written if you want to look into it and make it work again it would be superb; otherwise I'd just remove Rush if it stopped working with recent versions.

Thanks for the quick response.
Hmmm I'm looking through various microfrontend frameworks and one of many good reasons for piral is the support for rush as rush is already in use as monorepo.
NPM and rush is nothing really working good together. The way to go is probably remove Rush+NPM and only support Rush+PNPM.
I looked a little bit into the issues:

✖ [0002] Could not install the package "piral-cli-webpack5@^1" using rush. Make sure rush is correctly installed and accessible: Error at the app-shell: The problem is that the standard workflow is to call rush build which just executes the build script defined in the package.json => piral build. During the build it tries to install packages which does not work. It is only allowed to run one rush command in a workspace otherwise you get
Another Rush command is already running in this repository.

That's not 100 % true because there are some commands running without locks. Also custom commands can use safeForSimultaneousRushProcesses.

✖ [0002] Could not get externals from "piral": "Error: Can't resolve 'piral/package.json' in 'C:\Projekte\piral\packages\foo-pilet'
✖ [0002] Could not get externals from "piral-core": "Error: Can't resolve 'piral-core/package.json' in 'C:\Projekte\piral\packages\foo-pilet'
✖ [0002] Could not get externals from "piral-base": "Error: Can't resolve 'piral-base/package.json' in 'C:\Projekte\piral\packages\foo-pilet'

If the packages have been added before into the package.json and properly installed, there would be no need to resolve it by hand because pnpm already takes care of not having package duplicates by symlinking.

Finding the pilet's app-shell is easy patchable by just adding the root path to the modules path.
https://github.com/smapiot/piral/blob/6429391c1b248272ec414462e174144932bc6b3e/src/tooling/piral-cli/src/common/declaration.ts#L147-L157
add module.paths.push(join(root, "node_modules")); where join comes from path.

Something new while playing around with it. If I fix 1-3 by hand, as soon as I add the pilet to the monorepo, the build for the shell doesn't work again. It tries to always installs the bundler. The only thing I have seen that withBundler is not called anymore with the webpack5 string but I don't really know what calls it and how this function is called. Guess something with the inject of the plugin is going wrong.

The only reason for a bundler to be installed is that the / no bundler is not available - being available means it can resolve it / has it installed as a piral cli plugin.
So this will have to do with the structure that Rush makes when using npm (if they would just use npm workspaces the problem would be easily solved, but I think they do something on their own).

being available means it can resolve it / has it installed as a piral cli plugin.

That was the part I'm struggling with. It finds the plugin when only have one project in rush but not when I have two projects in rush. Looking into the README and source for the plugins, it looks like the plugins are found / searched for by using a magic naming convention piral-cli-. Guess it's once again a wrong search path in that case.
This should be fixable.
Just don't know what to do about the part that piral tries to install things during a rush build (which just calls the build scripts of package.json -> piral build). Not the best user experience but I can only think about throwing a message to the user telling that xyz needs to be installed manually via rush add ....

Looking into the README and source for the plugins, it looks like the plugins are found / searched for by using a magic naming convention piral-cli-. Guess it's once again a wrong search path in that case.

Yes, I'll also try to look into it today. Do you have a reproducible / some repo somewhere that simplifies the setup for me? Would be appreciated. Thanks!

https://github.com/KBroichhausen/rush-piral
Probably the thing here needs a different solution to find the dir to also work with rush + pnpm.
https://github.com/smapiot/piral/blob/develop/src/tooling/piral-cli/src/plugin.ts#L116C1-L123C2
For me it searches in<EMAIL_ADDRESS>but it would require to look for it in common\temp\node_modules\.pnpm\ or much better and more convenient in the app's node_modules folder which is packages\app-shell\node_modules

Otherwise it cannot function - which is a worse experience. So I think resolving the plugin lookup will also resolve this one.

Yeah, unless you really have no bundler installed. In that case you can only throw a message to the user.

Well I mean you use pnpm, so the app's node_modules folder is just a bunch of symlinks. Actually, for pnpm we already have a bit of special treatment in there. Let me see with your repo what we can do here to improve this.

Yeah I also now recognize the patch; I think this also needs to be patched in the source (though a bit differently). Currently on that.

With the recent patch (version currently in build) it should work in pnpm and others (npm).

Nice. Thanks a lot!

I am not sure what pilet refers to in your machine / your repo. In the given monorepo its using npm workspaces, so any binary is also available workspace-wide. Either install the Piral CLI in the root already (I don't think Rush allows this / uses this concept) or just start the build from one of the pilets (you can always pilet debug . ../foo ../bar etc.).

I use the version with the recent changes for rush:
pilet --version
1.5.0-beta.6569

pilet is located in %APPDATA%\npm\pilet.ps1
pilet debug . ../foo ../bar doesn't work. It finds the bundler for the . pilet but not for the others like ../foo. That's why I guess the search path is wrong again when passing folders.
Though it works if I add this to the scripts section in a package.json of one pilet and then call it via npm run ... or pnpm ... or rushx ... etc.
Well, it works but as rush, and you already mentioned by yourself, has no concept of a root package.json, you need to add it to one pilet. If it's not easy fixable, then it should go into the Guidelines. I guess I can rewrite and be more precise in some parts of the Guideline and make a PR in the near future for it.

Well this means you installed the Piral CLI globally. Hence you should also have installed a bundler globally.
In general we don't recommend a global installation - but in this case (i.e., using Rush, which, again, is a bit of a problematic / imho not well done monorepo tool) you'd need it to run it from the root.


Modus Alert component - Responsiveness - Alert - with Link - Text is not appropriate when the canvas width is reduced

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have read the contributing guidelines

Describe the issue
Modus Alert component - Responsiveness - Alert-with Link - Text is not appropriate when the canvas width is reduced
Please refer the below screeshot:

Reduced test cases
No response
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome, Firefox, Microsoft Edge
What is the issue regarding ?
@trimble-oss/modus-web-components
What version of npm package are you using ?
No response
Priority
Low
What product/project are you using Modus Components for ?
QA
What is your team/division name ?
QA
Are you willing to contribute ?
None
Are you using Modus Web Components in production ?
No response

Cannot reproduce now
https://codepen.io/ramaraj-trimble/pen/zYbOYPB

This is a bug and it needs to be fixed. Even though we have a guideline to not have more than 5-10 words, the alert should technically accomodate longer sentences as well. The height of the alert should grow as the text.


Avoid adding empty strings

The PhpFunctionsScanner extracts empty strings too (eg echo __('');). So, we risk to generate a .po file like this:
# PO headers
msgid ""
msgstr ""
"Header 1: value\n"
"Header 2: value\n"

# Empty string extracted from code
msgid ""
msgstr ""

...

This is wrong, since the msgid must be unique (and this specific case messes up the gettext headers).

Thank you :)


Completely useless: didn't explain how to set up the file to run so that F5 knows

[Enter feedback here]

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

ID: dbb9adca-2c5c-edff-2c4e-4645579fb907
Version Independent ID: 85cade65-f1b0-61d4-c69e-fb8ca94fefed
Content: Debug a JavaScript or TypeScript app - Visual Studio (Windows)
Content Source: docs/javascript/debug-nodejs.md
Product: visual-studio-windows
Technology: vs-javascript
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@rogerms -- thank you for your feedback.  Please clarify your intended task.  Meanwhile, consider these resources:

Visual Studio on Microsoft Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit

I was looking for instructions on how to debug an existing Nodejs/express project in Visual Studio and that was how I got to that page.
That page basically says: "open the folder and press F5"; but that didn't work.
I assume there is a way to tell Visual Studio where the starting file is located and how to run it,
In my project I use typescript so I need to tell VS to run "ts-node ./src/index.ts" but here are not documentations on how to do that.
Thank you

@rogerms -- thank you for clarifying.
@Mikejo5000 -- please look into this issue.

@rogerms Sorry for the slow response. Were you able to resolve the issue? You can right-click the project node in Solution Explorer (right pane), and choose Properties, and then set the startup file. In most of the JS and TS articles here, assumption is that you started with one of the VS project templates, where startup file is pre-configured. It is difficult to cover all the custom scenarios.

I was looking for instructions on how to debug an existing Nodejs/express
project in Visual Studio and that was how I got to that page.
That page basically says: "open the folder and press F5"; but that didn't
work.
I assume there is a way to tell Visual Studio where the starting file is
located and how to run it,
In my project I use typescript so I need to tell VS to run "ts-node
./src/index.ts" but here are not documentations on how to do that.
Thank you
On Thu, May 19, 2022 at 6:00 PM William Anton Rohm @.***>
wrote:

@rogerms https://github.com/rogerms -- thank you for your feedback.
Please clarify your intended task. Meanwhile, consider these resources:

Visual Studio on Microsoft Q&A
https://docs.microsoft.com/answers/products/vs
Visual Studio MSDN Forum
https://social.msdn.microsoft.com/Forums/vstudio
Stack Overflow
https://stackoverflow.com/search?q="visual+studio"
Reddit https://www.reddit.com/r/VisualStudio

—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/visualstudio-docs/issues/8036#issuecomment-1132310059,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABM2KGMDKHMTUWULWC3PYHDVK3I2TANCNFSM5WLNYP4Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

@rogerms -- thank you for your clear followup.
@Mikejo5000 -- Mike, please look into this potential documentation issue.

Never being able to debug a Node Project in Visual Studio. If you could point me in the right direction I would appreciate it. Thank you

@rogerms I'd recommend either starting with a standard project template for JS or TS (File > New Project) > JavaScript/TypeScript > (One of the Express templates, or the Blank Node.js project), and then porting your code into the template, or you can use File > New Project > JavaScript > From Existing Node.js code, and then choose your project folder. In the new project dialogs, choose to place the Solution and Project in the same folder. I tested the "From Existing Node.js code" template for an existing Node.js Express app, and F5/debug did work from that starting point. My example code did not include TypeScript, however, which can add complications for debugging if sourcemaps are required.
If you have additional questions, please use the Report a Problem tool to report the issue. When you do this, your report becomes part of the work items that are listed in the in the Visual Studio Developer Community, which allows you to engage directly with the engineering team while they address and fix the problem.
I will make a doc update that mentions the "From Existing Node.js code template". Let me know if that works for your TypeScript scenario. In general, VS works more easily with projects that include a Solution and Project file.


JBEHAVE-1135 Run story-level Given stories only if story contains scenarios

Is there any chance to review and merge the changes to the master so that they will be included in the upcoming JBehave 4.1 release?

This patch cannot be applied as it fails the tests

Could you please point which tests fail? I run mvn install -Pexamples, build passes.

Tests run: 16, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec <<< FAILURE! - in org.jbehave.core.steps.StepsBehaviour
shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithNoFailureOccuring(org.jbehave.core.steps.StepsBehaviour)  Time elapsed: 0.003 sec  <<< FAILURE!
java.lang.AssertionError:
Expected: is
but: was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.jbehave.core.steps.StepsBehaviour.shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithNoFailureOccuring(StepsBehaviour.java:178)
shouldProvideStepsToBeNotPerformedAfterScenarioUponOutcome(org.jbehave.core.steps.StepsBehaviour)  Time elapsed: 0 sec  <<< FAILURE!
java.lang.AssertionError:
Expected: is
but: was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.jbehave.core.steps.StepsBehaviour.shouldProvideStepsToBeNotPerformedAfterScenarioUponOutcome(StepsBehaviour.java:204)
shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithFailureOccuring(org.jbehave.core.steps.StepsBehaviour)  Time elapsed: 0.001 sec  <<< FAILURE!
java.lang.AssertionError:
Expected: is
but: was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.jbehave.core.steps.StepsBehaviour.shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithFailureOccuring(StepsBehaviour.java:154)
Results :
Failed tests:
StepsBehaviour.shouldProvideStepsToBeNotPerformedAfterScenarioUponOutcome:204
Expected: is
but: was
StepsBehaviour.shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithFailureOccuring:154
Expected: is
but: was
StepsBehaviour.shouldProvideStepsToBePerformedBeforeAndAfterScenariosWithNoFailureOccuring:178
Expected: is
but: was
Tests run: 544, Failures: 3, Errors: 0, Skipped: 1

@maurotalevi , thank you for your help!
I tried to debug mentioned tests, but changed code is not invoked during run, so looks like these changes is not a reason of test failures.
Then I cloned master branch of jbehave-core repository and tried to build the project several times:
git clone https://github.com/jbehave/jbehave-core.git
cd jbehave-core
mvn install -s settings.xml

3 mentioned tests fail randomly at different runs (pass - fail - pass - pass...). I wasn't able to reproduce the issue in Eclipse IDE.

Yes, you are quite right, seems a random failure even without the patch.  I'll  try to have a look at it.

Closing PR, changes are added to the master


merge from arlac77/template-cli-app,arlac77/template-github

package.json

chore(package): add ^2.0.0 remove ^1.32.1 (devDependencies.rollup)

README.md

docs(README): update from template

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 13.10.1 remove 13.9.0 (jobs.include.node_js)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


I want to add Twitter Application Management link to the gem documentation.

Problem
I did not understand where to get consumer key.
There is no Twitter Application Management link in this documentation.
I have to go looking for other sites.
Solution
After this sentence
Note: oauth_token has been renamed to access_token and oauth_token_secret is now access_token_secret to conform to the terminology used in Twitter's developer documentation.

Add the following sentences and links
"You can get the client key from [here](https://apps.twitter.com/)"

@tono0123 What you've mentioned seems to be present in README.md, in the "Configuration" part:
## Configuration
Twitter API v1.1 requires you to authenticate via OAuth, so you'll need to
[register your application with Twitter][register]. Once you've registered an
application, make sure to set the correct access level, otherwise you may see
the error:

[register]: https://apps.twitter.com/

I did not notice, thank you.

😇


Cannot grab a tuner used by lower priority users

Reproduction Steps
Conditions:

Only one tuner is available
At least two channels are available

On a terminal:
# priority(0)
curl http://localhost:40772/api/channels/GR/26/stream >/dev/null

On another ternimal:
# priority(1)
curl -H 'x-mirakurun-priority: 1' http://localhost:40772/api/channels/GR/27/stream >/dev/null

Both are disconnected.
Logs:
DEBUG mirakc::epg: QueryChannel by GR/26
DEBUG mirakc::tuner: StartStreaming GR/26 to Web(remote="<IP_ADDRESS>:63005" agent="curl/7.64.1") (priority=0)
INFO mirakc::tuner: tuner#0: Activate for GR/26
DEBUG mirakc::command_util: tuner#0: Spawned 8753: `curl -fsSL http://mirakc:40772/api/channels/GR/26/stream`
INFO mirakc::tuner: tuner#0: Activated with GR/26
INFO mirakc::tuner: tuner#0.1: Subscribed: Web(remote="<IP_ADDRESS>:63005" agent="curl/7.64.1") (priority=0)
DEBUG mirakc::broadcaster: tuner#0: Started
DEBUG mirakc::broadcaster: Subscribe with tuner#0.1
INFO mirakc::tuner: tuner#0.1: Started streaming
DEBUG mirakc::epg: QueryChannel by GR/27
DEBUG mirakc::tuner: StartStreaming GR/27 to Web(remote="<IP_ADDRESS>:63007" agent="curl/7.64.1") (priority=1)
INFO mirakc::tuner: tuner#0: Grab tuner, rectivate for GR/27
INFO mirakc::tuner: tuner#0: Deactivated
DEBUG mirakc::command_util: tuner#0: Killed 8753: `curl -fsSL http://mirakc:40772/api/channels/GR/26/stream`
DEBUG mirakc::command_util: tuner#0: Spawned 8762: `curl -fsSL http://mirakc:40772/api/channels/GR/27/stream`
INFO mirakc::tuner: tuner#0: Activated with GR/27
INFO mirakc::tuner: tuner#0.1: Subscribed: Web(remote="<IP_ADDRESS>:63007" agent="curl/7.64.1") (priority=1)
DEBUG mirakc::broadcaster: tuner#0: EOS reached, stop
DEBUG mirakc::broadcaster: tuner#0: Stopped
DEBUG mirakc::broadcaster: tuner#0: Started
INFO actix_web::middleware::logger: <IP_ADDRESS>:63005 "GET /api/channels/GR/26/stream HTTP/1.1"<PHONE_NUMBER>6 "-" "curl/7.64.1" 6.221061
DEBUG mirakc::broadcaster: Subscribe with tuner#0.1
DEBUG mirakc::mpeg_ts_stream: tuner#0.1: Closing...
DEBUG mirakc::tuner: StopStreaming tuner#0.1
INFO mirakc::tuner: tuner#0.1: Stop streaming
INFO mirakc::tuner: tuner#0.1: Unsubscribed: Web(remote="<IP_ADDRESS>:63007" agent="curl/7.64.1") (priority=1)
INFO mirakc::tuner: tuner#0: Deactivated
DEBUG mirakc::command_util: tuner#0: Killed 8762: `curl -fsSL http://mirakc:40772/api/channels/GR/27/stream`
INFO mirakc::tuner: tuner#0.1: Started streaming
DEBUG mirakc::broadcaster: Unsubscribe with tuner#0.1
DEBUG mirakc::mpeg_ts_stream: tuner#0.1: Closing...
INFO actix_web::middleware::logger: <IP_ADDRESS>:63007 "GET /api/channels/GR/27/stream HTTP/1.1" 404 38 "-" "curl/7.64.1" 0.008458
DEBUG mirakc::broadcaster: tuner#0: EOS reached, stop
DEBUG mirakc::broadcaster: tuner#0: Stopped
DEBUG mirakc::tuner: StopStreaming tuner#0.1
INFO mirakc::tuner: tuner#0.1: Stop streaming

The later request grabs the tuner, but its connection is closed quickly due to EOS.

The old tuner session tuner#0.1 is closed and then the new tuner session tuner#0.1 is created when the tuner is grabbed.  Those are identified with the same tuner session ID tuner#0.1. The new tuner session seems to be closed by the streaming close event for the old tuner session.


Backport 1.2.x sensors collect

These already passed tests, don't want to wait 4 hours for all the other merges to get tested before this one.


WIP: Add Password parameter to Get-PfxCertificate cmdlet

PR Summary

Add Password parameter to Get-PfxCertificate cmdlet to allow automatization instead of prompting for password every time.
Fix #3970
Possibly breaking change:
Calling cmdlet without -Password parameter assumes passing empty password instead of prompting for pass as before. In order to avoid breaking change cmdlet can ask for password if Password is missed but it will be more complicated to use empty password string in automated scripts.
Also about tests:
How it's better to create password-protected PFX certificate to test not-null password? Store as raw bytes in certificateCommon.psm1?
PR Checklist
Note: Please mark anything not applicable to this PR NA.

[x] PR has a meaningful title

[x] Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[ ] User facing Documentation needed

[ ] Issue filed - Issue link:

[ ] Change is not breaking
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

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

This will need a user-facing documentation change, see the PR Template.

We need tests for this functionality.  At least:

A test verifying a password works
A test verifying that a bad supplied password fails and does not prompt.

And it would be nice if we could have a test that verified the host ui prompt scenario

We could ignoring UI prompt with -Force for best UX in scripts.

But isn't it an unnatural behaviour of cmdlet? PFX certificates (unlike pem) are designed to be password-protected by default, isn't it better to treat them in such way?

@maybe-hello-world is your comment replying to @iSazonov?  I would agree that we should only support either -Password supplied or prompt for password.

@SteveL-MSFT No, it's more about situation when we get no password from user, try to open pfx cert and in case of exception ask user for password. IMHO in either/or situation it's better to use password parameter and treat it as null if it's missed because:

It doesn't break existing automated scripts (where pfx isn't protected), scripts that works with protected pfx require interaction anyway
Prompt can possibly make it more complex to use cmdlet with GUI that relies on Powershell
It's more intuitive to look for parameter then wait for prompt

But of course it's just IMHO =)

@maybe-hello-world

It's more intuitive to look for parameter then wait for prompt

Except that it has always prompted up to now. Interactive console scripting may rely on that prompt. Replacing the lack of password with an error breaks that flow. In fact. I have CLI that does just that: menu selections for a few PFXs, then something like this
Write-Host "Unlock PFX"
$cert = $null
$attemptsLeft = 3
Do {
    $cert = Get-PfxCertificate -FilePath $pfxChoice -erroraction 'SilentlyContinue'
    $attemptsLeft--
    if (!$cert -and $attemptsLeft -gt 0) {
        Write-Host "Wrong password. Try again (attempts left: $attemptsLeft)"
    }
} While ($null -eq $cert -and $attemptsLeft -gt 0)

I'm not sure how wide spread that kind of usage is, but I'm guessing if I use it, at least one other person may be. 🙂

@maybe-hello-world I do appreciate this contribution and if the existing behavior was not already there, I would perhaps agree with you, but it seems unnecessary to introduce a breaking change.

@SteveL-MSFT Well, you're right. I've changed behaviour to non-breaking so could you review it again?

@PowerShell/powershell-committee reviewed this and agree for the need of a switch to suppress prompting for password and recommends the name of the switch to be "-NoPromptForPassword"

@maybe-hello-world Could you please continue?

@SteveL-MSFT @TravisEz13 Please continue the review.


[Bug Report]  bug in set new value

Element UI version
2.13.0
OS/Browsers version
Chrom 80.0.3987.163, (64 бит)
Vue version
2.6.11
Reproduction Link
https://jsfiddle.net/neo2a170/
Steps to reproduce
When I create 2 'input' components, after entering the value in one input, the value is transferred to the second at the same time. If I understand correctly, this is an error
<el-input @input="changeName"  size="mini" v-model="meta.alias"></el-input>
<el-input @input="changeAlias"  size="mini" v-model="meta.name"></el-input>
What is Expected?
Current input value must be changed
What is actually happening?
The value is assigned to both the first and second <el-input>

Isn't it because of v-model="meta.alias"?

Isn't it because of v-model="meta.alias"?
No, if exclude object meta, the result remains the same
https://jsfiddle.net/rcfL0dan/

Isn't it because of v-model="meta.alias"?
No, if exclude object meta, the result remains the same
https://jsfiddle.net/rcfL0dan/

v-model="meta.alias" will be translated to :value="meta.alias" @input="val => meta.alias = val". Combining with @input="changeName" it will be :value="meta.alias" @input="val => meta.name = meta.alias = val"
See doc for detail

Isn't it because of v-model="meta.alias"?
No, if exclude object meta, the result remains the same
https://jsfiddle.net/rcfL0dan/

v-model="meta.alias" will be translated to :value="meta.alias" @input="val => meta.alias = val". Combining with @input="changeName" it will be :value="meta.alias" @input="val => meta.name = meta.alias = val"
Read the doc for detail: https://vuejs.org/v2/guide/components.html#Using-v-model-on-Components

Thanks, I understood my mistake. Sorry for disturbing


Do not refresh to the starting position when modifying the waveform.

Do not refresh to the starting position when modifying the waveform.
Reference #125

For larger waveforms that extend past the edges of the window, the scroll position resets to the top left each time a change is made to the source and render is performed. It would be nice if the scroll position did not reset. When modifying the large waveforms it is convenient to look at the render as you enter source, but having it jump back to the top left each time makes this a pain.

I also encountered this problem, I hope can optimize as soon as possible. Sincerely hope !!

@bitrocco @nockieboy I have fixed an issue, please try online and I will update desktop App if it works as expected.

@drom  Thank you very much for your update, it works perfectly !

Yes, works perfectly now - thanks for the quick update!


publicPath should be based on url instead of outputPath

Currently when passing a publicPath option it will be based off outputPath instead of the url (result of interpolateName) like webpack file-loader.
This fixes the logic so it matches what webpack file-loader does:

No publicPath option -> publicPath = outputPath (https://github.com/webpack-contrib/file-loader/blob/master/src/index.js#L38)
publicPath option -> publicPath = options.publicPath + url (https://github.com/webpack-contrib/file-loader/blob/master/src/index.js#L44-L48)

Thanks for your contribution, I reviewed your changes and it seems okay to me, I'll merge it.