MSI Error 1639: 'Invalid command line argument' during installation

After fresh install on Windows 8.1 (Win32 MSVC Installer), when doing
$ multirust update nightly
I get:
[...]
checksum passed
extracting...

Then a popup from msiexec.exe showing the usage (cmd line flags etc.) with an OK button.
When I click OK, I get:
error: command failed: 'msiexec' (Status: exit code: 1639)
Using SysInternals procexp to find the cmd line args:
msiexec /a "D:\Program Files\.multirust\tmp\u1q7cfw7ur9ke261_file.msi" /qn "TARGETDIR=D:\Program Files\.multirust\tmp\xr8xy3cg51_lssog_dir"
(Btw, my MULTIRUST_HOME is "D:\Program Files\.multirust")
As far as I see it, the issue is the quotes around "TARGETDIR=<path>", shouldn't the quotes be only around the path (like TARGETDIR="<path>")?

I had a similar issue; shown below is a transcript (though not as informative as that from procexp)
C:\Users\nodakai>multirust -v update stable
read metadata version: '2'
info: installing toolchain 'stable'
toolchain directory: 'C:\Users\nodakai\AppData\Local\.multirust\toolchains\stable'
creating temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\fsgx3f4sf6jzk8kw_file
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable.sha256'
deleted temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\fsgx3f4sf6jzk8kw_file
creating temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\h96xbpnesksho_cz_file
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable'
checksum passed
creating temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\qlelbm_wheilv_ls_file
downloading file from: 'https://static.rust-lang.org/dist/rust-1.7.0-x86_64-pc-windows-gnu.msi.sha256'
deleted temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\qlelbm_wheilv_ls_file
no update hash at: 'C:\Users\nodakai\AppData\Local\.multirust\update-hashes\stable'
creating temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\qqfcjqbtji89jt41_file.msi
downloading file from: 'https://static.rust-lang.org/dist/rust-1.7.0-x86_64-pc-windows-gnu.msi'
92.05 MiB / 92.05 MiB (100.00%) 316.80 KiB/s ETA: 0s
checksum passed
deleted temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\h96xbpnesksho_cz_file
extracting...
creating temp directory: C:\Users\nodakai\AppData\Local\.multirust\tmp\l3wd5pgwhvpbmy18_dir
deleted temp directory: C:\Users\nodakai\AppData\Local\.multirust\tmp\l3wd5pgwhvpbmy18_dir
deleted temp file: C:\Users\nodakai\AppData\Local\.multirust\tmp\qqfcjqbtji89jt41_file.msi
error: command failed: 'msiexec' (Status: exit code: 1603)

C:\Users\nodakai>

I'm not an Admin on this machine.

This is a duplicate of #33
The underlying cause, as mentioned there, is a limitation of rust's Command API: rust-lang/rust#29494


kui Failing to build on x86_64

I am trying to build kui on my 64 bit x86 machine with ubuntu bionic setup.
I have followed below steps to build the package:
1.  git clone https://github.com/IBM/kui.git
2.  cd kui
3.  npm ci
4.  npm start

npm ci completes fine, but npm start stucks after some time.
Below are the logs when command stucks:
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/json/json.worker.js] 628 bytes {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/json/jsonWorker.js] 11.2 KiB {main}
[WEBPACK]         + 46 hidden modules
[WEBPACK] Child vs/language/typescript/tsWorker:
[WEBPACK]            Asset      Size  Chunks  Chunk Names
[WEBPACK]     ts.worker.js  10.5 MiB    main  main
[WEBPACK]     Entrypoint main = ts.worker.js
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/arrays.js] 6.71 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/diff/diff.js] 44.6 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/errors.js] 2.65 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/lifecycle.js] 5.14 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/platform.js] 4.33 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/types.js] 4.14 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/uri.js] 20.6 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/base/common/worker/simpleWorker.js] 9.87 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/editor/common/core/position.js] 3.8 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/editor/common/services/editorSimpleWorker.js] 19.2 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/editor/editor.worker.js] 1.02 KiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/typescript/lib/lib.js] 1.47 MiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/typescript/lib/typescriptServices.js] 8.35 MiB {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/typescript/ts.worker.js] 656 bytes {main}
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/typescript/tsWorker.js] 16.9 KiB {main}
[WEBPACK]         + 24 hidden modules
[WEBPACK] ℹ ｢wdm｣: Compiled with warnings.

After this, I am not getting the prompt.....terminal just hangs here.
I just want to build kui on x86_64 machine and generate the binaries. Also, there is no build folder getting created.
Can you please help me where I am getting wrong, or it would be helpful if you can share some documentation.
Looking for a positive response soon :)

Here are my system details:

Howdy! Thanks for the bug report. We have been successful with Ubuntu in travis, Ubuntu 18.04, and most recently Ubuntu 20.04. When you say:

After this, I am not getting the prompt.....terminal just hangs here.

Do you mean that you see a Kui window open, but the window is blank?

Also, have you verified whether (or not) the prebuilt images work for you?

Thank you @starpit for the response.

Do you mean that you see a Kui window open, but the window is blank?

No, kui window does not open. I am still on normal terminal. 'npm start' runs and halts at the logs below:
[WEBPACK]     [./node_modules/monaco-editor/esm/vs/language/typescript/tsWorker.js] 16.9 KiB {main}
[WEBPACK]         + 24 hidden modules
[WEBPACK] ℹ ｢wdm｣: Compiled with warnings.

[WEBPACK] npm run watch:electron exited with code 0

Do you think I am missing something here? I just installed npm via apt-get, then cloned 'kui' and ran 'npm ci' and 'npm start'. Do I need to execute something more here?

Also, have you verified whether (or not) the prebuilt images work for you?

No, I have not used the prebuilt images. Actually I wish to generate my own kui binaries, that's why I am building kui from source. My main motive is to run kui on raspberry after successful testing it on x86_64 system.

@starpit
I have executed the same steps to build kui on raspberry, and getting the same issues. 'npm start' command just halts after logs shared above.
Raspberry uses 64 bit arm processor. So, I also tested kui with 64 bit arm on travis-CI. That has shown below error for chrome not getting started.
Error: unknown error: Chrome failed to start: exited abnormally
(chrome not reachable)
(The process started from chrome location /home/travis/build/buzo/kui/node_modules/spectron/lib/launcher.js is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
(Driver info: chromedriver=78.0.3905.1 (adc3a81bb97a90bf5417e850ea9d612cdbfcdef4-refs/heads/master@{#703739}),platform=Linux 5.3.0-42-generic aarch64)

Earlier I thought it's because chromium does not support arm, but then found that code downloads electron and chromedriver both during npm ci, and both binaries are available for 64 bit arm, as can be seen here https://github.com/electron/electron/releases/tag/v7.3.2. So probably the issue is something else.
Hence, now I have two challenges, one is to build kui on 64 bit x86 machine, and second is to resolve this chrome failure error on arm jobs on Travis.
Can you please provide some pointers here ?...

hello! re: arm64, we have not yet tried arm ourselves. we'll have to look into this to see what is going on.
for x64, could you run running two separate commands:
npm run watch

then, when you see this

[WEBPACK] ℹ ｢wdm｣: Compiled with warnings.

run
npm run open

either in a separate tab, or after backgrounding the watcher. If nothing happens when you do the open, you can also try adding
DEBUG=* npm run open

This is what a normal debug output would emit:
❯ DEBUG=* npm run open
><EMAIL_ADDRESS>open /Users/nickm/git/whisk/nickm/kui
> electron . shell

  main/main loading +0ms
  main/main it looks like this is the main entry point, rather than a require +2ms
  main/main shortcut to graphics +0ms
  main/spawn-electron loading +0ms
  main/spawn-electron getCommand [
  '/Users/nickm/git/whisk/nickm/kui/node_modules/electron/dist/Electron.app/Contents/MacOS/Electron',
  '.',
  'shell'
] +0ms
  main/spawn-electron isShell [ '.', 'shell' ] shell +1ms
  main/spawn-electron using args [ 'shell' ] {} +0ms
  main/spawn-electron initElectron [ 'shell' ] false {} +1ms
  main/spawn-electron loading electron +0ms
  main/main isRunningHeadless false +6ms
  main/main all done here, the rest is async +0ms
  main/spawn-electron loading electron done +0ms
  main/spawn-electron exiting, since we are not the first instance +350ms

hello! re: arm64, we have not yet tried arm ourselves. we'll have to look into this to see what is going on.

Oh!!! ok...I will test it myself and let you know the results.

npm run watch

Yes, I have tried these commands.
npm run watch worked fine and ended at
[WEBPACK] ℹ ｢wdm｣: Compiled with warnings.

After that, I pressed cntl+C.
Now, when I run npm run open, I get following issue
[14823:1009/133947.533017:FATAL:atom_main_delegate.cc(211)] Running as root without --no-sandbox is not supported.

I have checked that --no-sandbox option is already present in common.ts file for chrome.
I am confused here why I am getting this --no-sandbox issue.

Interesting. Thanks for the additional info. Are you running as root? I guess we have never tried that. If you are, we can give it a shot, and see if we can repro this.

@starpit
When I am running (npm run watch) and (npm run open) without root, Both are passing well. Here is the output to (npm run open)
><EMAIL_ADDRESS>open /home/patricke/kui
> electron . shell

After this, I ran (npm run testv2 core). This seems problematic and gave issues to start chrome.
error refreshing in before for fresh start { Error: unknown error: Chrome failed to start: exited abnormally
  (unknown error: DevToolsActivePort file doesn't exist)
  (The process started from chrome location /home/patricke/kui/node_modules/spectron/lib/launcher.js is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

Are there some dependencies that I need to install for the chrome to work properly?

This could be it. Could you try
sudo apt install chromium-browser

Which might be a way to pull in the needed X dependencies? They had seemed to be installed by default on Ubuntu 20, which i just provisioned, fwiw.

Already did that...but that installs newest versions of chromium-browser....85.XX series.
And chromedriver used in kui is 78.XX, as seen from the logs
(The process started from chrome location /home/patricke/kui/node_modules/spectron/lib/launcher.js is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
  (Driver info: chromedriver=78.0.3905.1 (65dc90a9851d018b9423492f01b15f06cc34beba-refs/heads/master@{#703739}),platform=Linux 5.0.0-23-generic x86_64)

But I thought chromium-browser gets installed during npm ci, and I don't require to install it otherwise....Guess I proved wrong here.
And even if I install latest chromedriver...i.e. 86.XX series.....again errored logs show driver version 78.XX.
Is there a way I can update the driver version in kui??

i see. hmm. would it be possible for you to try the browser-based angle? so that we can factor electron out of the equation (for now)?
npm run watch:webpack

and, when the watcher is up, try visiting localhost:9080? we do this in travis, and i just verified it in an ubuntu 20 VM. a few weeks ago, i did this successfully in an ubuntu 18 VM.
if you are able to build and access kui via a browser, at least it'll help to isolate the problem. this will also help you make progress, as you can then have an edit-debug loop. if you are modifying typescript source, make sure also to run:
npm run watch:source

the npm run watch target combines the typescript watcher and webpack watcher; however, at the moment, when  you use the npm run watch:webpack target, it only spawns the webpack watcher.

I think I am not getting what exactly you want to guide here

and, when the watcher is up, try visiting localhost:9080?

If I am not wrong, do you mean to run
npm ci
npm run watch:webpack
npm run open
npm run testv2 core

If yes, then I have tried executing npm run watch:webpack and then npm run open, and it ended well. But again after npm run testv2 core, I got chrome error as before.
However, npm run watch was also ending well earlier, without error, and the chrome problem starts with npm run testv2 core itself.
TBH, I am not clear with this line...

and, when the watcher is up, try visiting localhost:9080?

can you please bother to explain a little more, if possible :)

npm ci
npm run watch:webpack

when that is done, you can try opening up any old web browser, and visiting http://localhost:9080. if that works, then we have isolated the problem to be an issue with electron on your OS/platform.
to run tests against this, you will need a small variant of the test launch. you can see the test:webpack target in package.json. all it does it set two environment variables; these two env vars tell the test rig to initialize a connection independent of electron:
KUI_USE_PROXY=true MOCHA_RUN_TARGET=webpack npm run testv2


Unable to build on NixOS

Background
Following the build instructions doesn't work on NixOS.
Your environment
I'm building the latest commit on master, 6fa93a78c18180a3bc77116b749b3c5e279d5a33. I have go and dep installed.
Steps to reproduce
> # install go and dep
> export GOPATH=~/src/go
> cd ~/src/go
> git clone https://github.com/lightningnetwork/lnd
> cd lnd
> make

Expected behaviour
It should start building.
Actual behaviour
It prints:
Makefile:88: *** target pattern contains no '%'.  Stop.

As far as I can tell this is due to the Makefile expecting GOPATH to be a single path and not a colon-separated list of directories. This is unfortunate since NixOS sets GOPATH itself to point to where go and dep are installed.

you should not clone lnd directly into the gopath, but instead use go get github.com/lightningnetwork/lnd

The build instructions have recently been updated to display the commands run directly by the make file.


Unable to write to Hbase

I am unable to write to Hbase using the example mentioned in readme. Here is a simple code that illustrates my approach and the error I encounter
import org.apache.spark.sql.execution.datasources.hbase._

val input = Seq(
| ("a:1", "null", "null", "3", "4", "5", "6"),
| ("b:1", "2", "3", "null", "null", "5", "6")
)

val df = input.toDF

val TIMELINE_TABLE = "test_timeline"

val timelineCatalog =
  s"""
     "table":{"namespace":"default", "name":""".stripMargin+ TIMELINE_TABLE +"""", "tableCoder":"PrimitiveType"},
                                      |"rowkey":"key",
                                      |"columns":{
                                      |"col0":{"cf":"rowkey", "col":"key", "type":"string"},
                                      |"col1":{"cf":"main", "col":"kx", "type":"string"},
                                      |"col2":{"cf":"main", "col":"ky", "type":"string"},
                                      |"col3":{"cf":"main", "col":"rx", "type":"string"},
                                      |"col4":{"cf":"main", "col":"ry", "type":string"},
                                      |"col5":{"cf":"main", "col":"wx", "type":"string"},
                                      |"col6":{"cf":"main", "col":"wy", "type":"string"}
                                      |}
                                      |}""".stripMargin

val HBASE_CONF_FILE = "/etc/hbase/conf/hbase-site.xml"
df.write.options(Map(HBaseTableCatalog.tableCatalog -> timelineCatalog)).format("org.apache.spark.sql.execution.datasources.hbase").save()

java.lang.ClassCastException: org.json4s.JsonAST$JString cannot be cast to org.json4s.JsonAST$JObject
  at org.apache.spark.sql.execution.datasources.hbase.HBaseTableCatalog$.apply(HBaseTableCatalog.scala:257)
  at org.apache.spark.sql.execution.datasources.hbase.HBaseRelation.<init>(HBaseRelation.scala:77)
  at org.apache.spark.sql.execution.datasources.hbase.DefaultSource.createRelation(HBaseRelation.scala:59)
  at org.apache.spark.sql.execution.datasources.DataSource.write(DataSource.scala:518)
  at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:215)
  ... 50 elided

My Scala version is 2.11.8 (OpenJDK 64-Bit Server VM, Java 1.8.0_131), and I'm on Spark <IP_ADDRESS>.6.0.10-29 and hbase 1.1.2 I am using version 1.1.1-2.1-s_2.11 connector and I am unable to find anything wrong with my data. It is actually a clean version of it. In ideal scenario I would want the string "null" to be actual null. But I couldn't get that to work, so I thought creating strings would at least get it working. Any help would be highly appreciated.

Please println the timelineCatalog to make sure that it is syntactically correct (For sure you miss opening bracket).
Please make sure that column names in your dataframe matches names mentioned in timelineCatalog as
"columns" : { "col0", "col1", "col2",...}. Use for it df.columns method


Device Check

Description of the feature request:
Are you looking to implement device check by chance so there is a possibility to use this in a production environment?
What problem are you trying to solve with this feature?
Wanting to use this in a prod environment in a safe manner without the cost of a server.
Any other information you'd like to share?
No response

The similar product, Vertex AI for Firebase, supports Device Check via Firebase App Check.

Thank you Ill Close this as its no longer needed


add personality generation

Authors could use elizabeth for character information, so I figured to add personality should be included. The personality objects in some of the non-English locales need translation, but the test passes in test_personal.py, and pycodestyle found no errors in the added function.

Current coverage is 99.35% (diff: 100%)

Merging #83 into master will increase coverage by <.01%

@@             master        #83   diff @@
==========================================
  Files            39         39
  Lines          1704       1712     +8
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1693       1701     +8
  Misses           11         11
  Partials          0          0

Powered by Codecov. Last update e5950ac...c4dae14

@aburgd It's done!


Debugging NixOS tests

Two years ago we have reverted a change that gave us a way to enter a VM part of a test due to issues on Hydra.
While there's a way to get into the python session for the test script, it's clumsy to do any kind of real inspection as one would in a terminal.
Maybe there's a way to have a function that hands out the serial terminal port that the driver is using?

Not stale, it would still be nice to get something like a PDB shell on the test script conveniently

One way is to run:
$ nix-build -A driverInteractive && result/bin/nixos-test-driver
[cpython]>>> test_script()

So, that VMs will be started in a new window each, where you can login in console.


The error returned in Azurite is inconsistent with the one in Azure when use queue service SAS to create queue

Error Description:
The error returned in Azurite is inconsistent with the one in Azure when use queue service SAS to create queue.
In Azure, the error is shown as following:

In Azurite, the error is shown as following:

To Reproduce
The demo code is shown as following:
import { QueueServiceClient } from "@azure/storage-queue"
import * as assert from "assert"

async function main() {
  try {
    var queueServiceClient = new QueueServiceClient("https://jacksonstorage1211.queue.core.windows.net/?sv=2020-04-08&st=2020-12-15T06:40:44Z&se=2020-12-15T08:40:44Z&sp=raup&sig=NQHenjCUuSLq%2FnOpCAsV3vQxQSnuLYuO%2FuggG1ddiis%3D");
    var queue = queueServiceClient.getQueueClient("<queue-name>");
    await queue.create();
  } catch (err) {
    assert.ok((err as any).response.parsedBody.Code === "AuthorizationFailure");
  }

  try {
    queueServiceClient = new QueueServiceClient("https://<IP_ADDRESS>:10001/devstoreaccount1/?sv=2020-04-08&st=2020-12-15T06%3A20%3A34Z&se=2020-12-15T08%3A20%3A34Z&sp=raup&sig=4RU5eN6Dhy%2B8MAcK29rt6gsue%2FW1iOl0dqfyKfR8p6s%3D")
    queue = queueServiceClient.getQueueClient("<queue-name>");
    await queue.create();
  } catch (err) {
    assert.ok((err as any).response.parsedBody.Code === "AuthorizationPermissionMismatch");
  }
}

main();

Error Track:
The process code for use queue service SAS to create queue in Azurite is shown as following:
https://github.com/Azure/Azurite/blob/master/src/queue/authentication/QueueSASAuthenticator.ts#L276

Expected Behavior
The error returned in Azurite is consistent with the one in Azure when use queue service SAS to create queue.
@jongio for notification.

Thanks for bringing up this. We should improve this.

Thanks for bringing up this. We should improve this.

azsdk-azurite


Fix issues when there are spaces in --format " table " or --format " raw "

- What I did
This fix tries to address the issue where spaces combined with "table" or "raw" in --format caused incorrect rendering. For example, --format "    table   " for --format "     raw"
The following are examples:
ubuntu@ubuntu:~/docker$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
f183787c2d35        busybox             "top"               About an hour ago   Up About an hour                        kind_wozniak
ubuntu@ubuntu:~/docker$ docker ps --format ' table '
table
ubuntu@ubuntu:~/docker$ docker ps --format ' table {{.ID}} {{.Image}}'
table f183787c2d35 busybox
ubuntu@ubuntu:~/docker$ docker ps --format ' raw  '
raw
ubuntu@ubuntu:~/docker$

The reason with the above incorrect rendering is that, table or raw format checking was not compared after space trimmed.
And IsTable() does not take into consideration the spaces as well.
- How I did it
This fix fixes the issue.
- How to verify it
Additional test cases have been added to cover the changes
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: Yong Tang<EMAIL_ADDRESS>

I'm not sure this change is neccessary. It should be pretty obvious that this is incorrect input, I don't think we should try and clean it up.

@cpuguy83 Thanks for the feedback. I am not so sure as well. Was running into an issue when a prefix'ed space caused formatting issue, think it may worth to take a look.
Let me close this PR for now.


⚠ Jenkins Plugins Artifactory has degraded performance

In 463d64c, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1335 ms

Resolved: Jenkins Plugins Artifactory performance has improved in f245a12 after 12 minutes.


GH-37889: [Java][Doc] Improve JDBC driver documentation

Rationale for this change
Correct inaccuracies and better document how to connect with the Flight SQL JDBC Driver.
What changes are included in this PR?

Correct the user property.
Correct the default for useEncryption.
Elaborate on using the Properties object when connecting and describe the order of precedence.

Are these changes tested?
N/A
Are there any user-facing changes?
Yes

Closes: #37889

@lidavidm @danepitkin

Other than the one comment above, these fixes are helpful


Broken folder? [bug?]

after creating private folder that can viewed only by me and guy that not on keybase,
folder is broken.
with broken folder, now i see rekey window, its annoying for me.
Rekeying not working,
Ignoring folder not working.
Any ideas to fix this?
my log id: a1206709969c4fabc3f2581c

The folder was written by one of your devices about an hour after that device was revoked, according to the timestamps on our servers:
Not trusting revoked verifying key 01207d546f805694a41db8b8226d5965f2632e5d24cb5d412e2b29a9ec1d17ecc3420a for user e141245a42fdee62a386ddb3a2430219 (revoked time: 2017-03-13 07:57:36 +0300 MSK vs. server time 2017-03-13 08:57:46 +0300 MSK, slack=1m0s)

It's suspicious to me that the times are off by exactly an hour. It makes me think that at some point, the clocks on the API server and the KBFS MD server were off by an hour.  @maxtaco do you remember anything weird happening with the API server (or DB) clock back in March?
@iJusty: if you want, I can completely nuke that folder for you, so you stop getting the annoying messages.  If you want that, please run this command on an currently-valid keybase device, and substitute the current date and time where indicated:
keybase sign -m "<DATE_AND_TIME>: Please reset folder /keybase/private/<XXX> because all the devices that have access have been revoked."

and post the results here.  I didn't fill in the folder name since it has the name of another user you might want to keep private, but you should fill it in yourself.  If you prefer to keep that private, you can put the results in /keybase/private/idankexe,strib@github.

Command is executed.
Result:
BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkQiSIQr jdUAOErbfGRyXnR JqW1ULzCzDhKhI2 0JjncTAHTRe9SKI a4cPDjtPXw2KNq2 OSybL0F9AVzq4ld SwzbUjzLFDOlBRS 9mMy9A09cW1YmYc O7QhWifBL6QOWW2 FJpuFrcJkSpcJo6 R1xUAJBI1exf7pJ wUMUE20YnOPxkJv j6FhVzzvyqBbkIx vr3x3RMY7R6Xr7X ONhZ7bZdQ8GhL5Z HSbg80GkE90ogX5 spBBF3DEp7QEn7P ETt3WjgSsPA7ebQ YeaQaVXhoJvefXT 0O2cTFPLRrSxQjM IV431aA7bHRDBo8 14BSvqPE5NYJQD5 xHMfaCHAEcoQTCs Ea3l7tJuShGNKV8 mBI6. END KEYBASE SALTPACK SIGNED MESSAGE.

@iJusty: I deleted the folder from the file system.  You might still see a rekey notification or badge about it until the next time we deploy our server, but it should go away in a day or two.

ok.
seems folder is deleted.
thanks!


What does signout out mean?

When logging out of the Red Hat account, I currently cannot observe an action to be taken.  I think we should consider logging out of registry.redhat.io and also unregister subscription-manager in the VM?  That would feel symmetric to what happens when logging in.

Right now it is just removing session from provider internal in memory storage. User is still logged in in browser.

Right now it is just removing session from provider internal in memory storage. User is still logged in in browser.
Then this is not correct as we are not cleaning up the things properly.

It must handle the complete cleanup, imagine a case where the user has 2 accounts and wants to switch from one to another.
Complete cleanup:

the user should not be able to pull from registry.redhat.io from podman desktop or podman
the browser session must be cleaned
the subscription info in the podman machine must be removed


Adding bold-controller unit tests

Issue #480
Let me know if there are any desired changes and I'll be happy to adapt as needed.

 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.:x: bryce-turner sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

I looks like one of the tests are failing in this PR. Can you take a look when you get a chance and ping me when its ready for review?

We have a big change coming in a future PR #584 that will touch all of the files in the repo. So we would like to merge or close out all the open PRs before merging this. Can we get this PR wrapped up in the next week or two so we can move forward with the eslint/prettier changes? If not you will likely have to handle the merge conflicts or rebase.

@bharney0 My apologies for the delay. On my end, the italic and bold controller tests were failing when ran together (they share nearly identical code). The changes made by the bold controller were still present when the italic controller tests started to run. I see we still are failing the CI, can you let me know what the description of the failure is? I was not able to replicate the word selection failure on my end.
The test cases are passing as far as I can tell:

@bryce-turner looks like theres 4 failing tests, but likely they just need a sleepTime to allow the editor to catch up to the assertion. The failing tests all look like this:
AssertionError: expected 'Body' to equal '**Body**'

Check out this branch/PR I made that adds the changes for sleep timer and some suit setup for telemetry. https://github.com/bryce-turner/vscode-docs-authoring/pull/1

@bryce-turner thank you for the contribution. Changes are approved and merged. 👍


Support dart native

Can you make this package support dart native without flutter?
This will open so many options for this package, and it is already a binding of c++ implementation so it shouldn't be a big change.
Users can choose manually microphone or speakers location on device if needed.

Thanks for submitting this feature request!
I don't think there is a need to use Dart Native here as you can achieve the same thing by just exposing this as a pure Dart library - see https://cjycode.com/flutter_rust_bridge/library/dart_only.html. Going to rename this issue to "Support Pure Dart Library".

Yes, dart standalone without flutter
Should look like this in pub.dev

And as they wrote in flutter_rust_bridge
Native Assets would make it easier, adding a link to this feature to keep track
https://github.com/dart-lang/sdk/issues/50565


doesn't update the last saved location when saving multiple files.

whenever you try to save it when there's more than 1 image, it won't update the last saved location until after all saving is finished, so if you want to save it to a specific folder but didn't just save something else to it right before, you need to navigate to it for every file you're saving.

That is by design.
Are you trying to save the media saved through the extension under a specific folder? For example, all media is stored under the “Fav” folder under Download. Or do you want a folder for each tweet?
In the former case, it can be added as an extension setting through development.

i have multiple specific folders for various things to organize, so i will often change folders.

If the feature raised in this issue https://github.com/Flkalas/TwitterMediaAssist/issues/37 solves the problem, I would like to close this issue.

yeah, it should solve it just fine.


Strings.xml of Spanish translation

Hi, I made a Spanish translation, I share if it can be used in this cool app.
strings-es.zip

Hello, thanks for the contribution. Can you post the transitions here as a code block instead of zip file, please?

I do a pull request please tell me if something is bad.

Everything looks good, thanks for the contribution 😄


[Snyk] Upgrade cloudevents from 7.0.2 to 8.0.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade cloudevents from 7.0.2 to 8.0.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

Warning: This is a major version upgrade, and may be a breaking change.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2023-07-24.

Release notes

Package name: cloudevents

8.0.0 - 2023-07-248.0.0 (2023-07-24)
⚠ BREAKING CHANGES

use string instead of enum for Version (#561) (15f6505)
TypeScript does not consider enum values equivalent, even if the string
representation is the same. So, when a module imports cloudevents and
also has a dependency on cloudevents this can cause conflicts where
the CloudEvent.version attribute is not considered equal when, in
fact, it is.

Miscellaneous

add npm run build:schema to the doc generation action (#557) (fa388f7)
modify release-please to use Signed-Off-By on commits (#559) (089520a)
release 8.0.0 (#563) (1ed43c8)

7.0.2 - 2023-07-117.0.2 (2023-07-05)
Miscellaneous

add the provenance flag when publishing to npm (#556) (a0d8682)
fix the release-please automation script. (#554) (023171d)

    from cloudevents GitHub release notes

Commit messages

Package name: cloudevents

db60220 chore(main): release 8.0.0 (#558)
1ed43c8 chore: release 8.0.0 (#563)
df059e9 BREAKING CHANGE!: use string instead of enum for Version (#562)
15f6505 BREAKING CHANGE: use string instead of enum for `Version` (#561)
089520a chore: modify release-please to use Signed-Off-By on commits (#559)
fa388f7 chore: add `npm run build:schema` to the doc generation action (#557)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
Patch coverage has no change and project coverage change: -0.34% :warning:

Comparison is base (9dc620d) 89.89% compared to head (d9f5c05) 89.56%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #304      +/-   ##
==========================================
- Coverage   89.89%   89.56%   -0.34%
==========================================
  Files           9        9
  Lines         297      297
==========================================
- Hits          267      266       -1
- Misses         30       31       +1

see 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add info on how to retrieve project IDs for Prometheus Federator Application.

Page currently has a line " <!-- add info on retrieving project IDs >" wanting additional information on gathering project IDs. Adding a kubectl command to gather the required info

Will need to be applied to 2.6 as well.


CommandCollection doesn't run the callback from original group

We have plugins that export a click group which we pull into our command line by composing them together with a CommandCollection. However some of the plugins do important setup in their group callbacks and the CommandCollection doesn't run those.
We've fixed this by replacing the CommandCollection's callback with the group's callback in get_command. I don't know Click well enough to know if this is right but it makes sense to me.
    def get_command(self, ctx, cmd_name):
        for source in self.sources:
            cmd = source.get_command(ctx, cmd_name)
            if cmd is not None:
                self.callback = source.callback
                return cmd
        return None

Closing this, as I think it is a duplicate issue of https://github.com/pallets/click/issues/347 .
Thanks for the work around though, that is helpful. Please reopen if I have misunderstood.


Documentation links for Oracle Database 12c R2 Standard Edition 2 and Oracle Database 12c R2 Enterprise Edition lead to 404

I am currently reviewing the Single instance FAQ, and it looks like the links for Oracle Database 12c R2 Standard Edition 2 and Oracle Database 12c R2 Enterprise Edition both lead to 404. Can you fix this to link to the correct sites? I could only Oracle Database 21c but I wasn't sure if these docs would be correct for 12c.

@gvenzl  We might need to update this FAQ as starting 19c the container-registry images do support startup scripts

@yunus-qureshi Nice, are there any docs about how to add startup scripts for 19c?

@yzhan289 it is already documented in the 21c link you have pasted above as part of the docker run command

@yunus-qureshi, yes, the FAQ needs an overhaul indeed.
Can you please have someone take a look at it?


Regression pull request testing

Docs Build status updates of commit 545a12b:
:clock10: Full build: the average full build time is 6 min(s) 6 sec(s), this is based on the last 444 build(s) for this repository.

Docs Build status updates of commit 545a12b:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

docs-ref-conceptual/e2epullrequest.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/e2epullrequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).

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

Docs Build status updates of commit 30b1563:
:clock10: Full build: the average full build time is 6 min(s) 6 sec(s), this is based on the last 446 build(s) for this repository.

Docs Build status updates of commit 30b1563:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

docs-ref-conceptual/TestingPullRequest.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/e2epullrequest.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/TestingPullRequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).

docs-ref-conceptual/e2epullrequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).

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

Docs Build status updates of commit afe13ac:
:clock10: Full build: the average full build time is 6 min(s) 6 sec(s), this is based on the last 448 build(s) for this repository.

Docs Build status updates of commit afe13ac:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

docs-ref-conceptual/TestingPullRequest.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/e2epullrequest.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/TestingPullRequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted1.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted2.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).
Line 10: [Warning] Invalid file link:(~/nonexisted3.md).

docs-ref-conceptual/e2epullrequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
[Warning] the value invalid_type is undefined for metadata content_type
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 7: [Warning] Invalid file link:(~/nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 8: [Warning] Invalid file link:(~/nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).
Line 9: [Warning] Invalid file link:(~/nonexisted3.md).

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


chore: update navigation.json to match config.yml

A suggestion on how to support the request from this community post:
https://community.netlify.com/t/storing-content-in-json-files-with-netlifycms/851/4
The request is to edit an entire JSON file using the CMS using just the code widget

Closing and deleting the fork. Let me know if you want this re-introduced


vdirsyncer: 0.6.0 → 0.7.0

also, add 2 news dependencies of vdirsyncer:
click-log: init at 0.1.1
click-threading: init at 0.1.2

/cc @matthiasbeyer @geerds

Uh, nice!
For the next time: Can you please add each package in one commit? So you'd have three commits for an package update like this, two introducing new packages, one doing the update.
Anyways: Great! Will checkout the changelog now! :+1:

@matthiasbeyer I've just done it. If you like it, please merge.

Who? I thought this PR was already merged. Nice!
I cannot merge, but I'm sure someone will merge this as soon as the travis build doesn't fail anymore. Maybe you can investigate?

Tests releated to timezones fail.

this works locally for me...

I don't understand what travis is doing:
[...]
The invocation of "nix-build -A vdirsyncer -A python35Packages.click-log -A pypyPackages.click-log -A pypyPackages.click-threading -A python35Packages.click-threading -A khard -A khal -A python34Packages.click-threading -A python27Packages.click-threading -A python27Packages.click-log -A python34Packages.click-log /home/travis/.nox/nixpkgs" failed

why does it try to install khard? It is not a dependency of vdirsyncer. And khard is the one failing, not vdirsyncer.

What was the error?

I don't know why nix/nox was trying to build khard. But I fixed the khard pull request and this fixed this one as well :-).


Initial build for 4.1.1 ❄

seal 4.1.1 :snowflake:
Destination channel: Snowflake
Links

PKG-3842
Upstream repository

Explanation of changes:
Completely new feedstock. It doesn't exist on conda-forge. This package is required to build tenseal.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_d1n2gm0xo5/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_24e18vdkag/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_16d2lhk8l6/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_ecrgo_li4a/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_73_7td3i4y/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_a1yaek9p7u/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_3cl7v0yc7g/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:27: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 1 Warning were found


feat: remove internal client

Motivation and Context
The InternalClient has been deprecated for more than 3 months and will now be removed.
Marketing Changelog
The InternalClient has been removed and has been replaced by the new operations client.
See: https://docs.wundergraph.com/docs/upgrade-guides/internal-client-deprecated
Checklist

[ ] run make test
[ ] PR title must follow conventional-commit-standard
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message and code follows the Code of conduct

@fiam it's already documented in the docs for months, also added the link to the migration in the description above for the release notes


android support

Thanks for your plugin, is very complicated to make android support? i want to work on this.

@cinder92 Pl do so quickly :) Waiting for it

@cinder92 you're more than welcome to work on Android. Should be pretty straightforward if you know your ways around Android... :)
LMK if you need any help - will be happy to assist.

Any updates on this?

@LoriKarikari  I started using https://github.com/wix/react-native-zss-rich-text-editor

Android support is available?

yes!


corrected formatting of xml code samples in about-the-connection-group-file51

When viewing the page in Win 10/Edge, the xml code samples stretched across the page, running into the side menu. The lack of line breaks and syntax highlights also made it hard to read.
This update adds line breaks and syntax highlighting, replaces curly double quotes with standard double quotes, and adds a closing tag for the appv:appconnectiongroup tag in each code sample.

@DaniHalfin Would you be able to merge this PR created by a MS contributor? Thanks.


Add dark mode

Added Dark mode to the content that is visible.

I like that, thank you very much!


Overlay on CONTRIBUTING.md page

When accessing the CONTRIBUTING link from the homepage, the redirected page is marred by overlay issues that significantly compromise its professionalism.  These overlays obscure the main content, detracting from the user experience.
link to page -  https://ebookfoundation.github.io/free-programming-books-search/?&sect=docs&file=CONTRIBUTING.md

I have tested the link to the CONTRIBUTING page, and it appears to be working fine on my end without any overlay issues.
It's possible that the problem you're experiencing is related to your browser or some browser extension.
I recommend trying the following steps to troubleshoot the issue:

Clear your browser cache and cookies.
Disable any browser extensions or add-ons that may be interfering with the page.
Try accessing the link in a different browser to see if the issue persists.

works fine for me, too

I still have same issue, but  as you guys mentioned its system specific, and have no issue with #9736 .
yhh I'll try some other ways to fix it in my sys.
and thanks btw.


Descheduler strategies as plugins

Is your feature request related to a problem? Please describe.
The number of strategies is increasing and we still have code of all the strategies under the same directory. Which increases risk of identifier name collisions. It’s also currently impractical to add custom strategies into the Descheduler (in case someone decides to fork the code and integrate e.g. proprietary strategies.).
Evicting pods outside the strategies will free us from passing pod evictor into each strategy. It will also allow us to run the Descheduler as a simulator more easily. E.g. by checking which strategies are evicting the same pods, how one strategy impacts other, etc.
Describe the solution you'd like
Create a factory like initialization of plugins and a new strategy interface with Deschedule method
Describe alternatives you've considered
NONE
What version of descheduler are you using?
Any version
Additional context
Google doc for open discussion: https://docs.google.com/document/d/1VuqbwakL69H4sbsGP8J6C10x1NfEpeAQY_cHibrZY0M/edit#

+1, standardizing an interface for each strategy and moving them into their own packages is at the very least a big improvement for our code organization. I would go even further to say this is more than a feature, but a considerable redesign (and one well worth having).
I'll leave some comments on the doc, thanks for starting this @ingvagabund !
/kind design

This is a great refractor. I would be interested to pick this up as it will give some good understanding of the code base.
Is this in a shape to start? I can take a shot at it and raise doubts here/design doc or via PR as I encounter them
There is another recommendation of converting strategy params to an interface.
Can I attempt both in the same change ?

Can I attempt both in the same change ?

Let's keep different changes to their own PRs. Especially with refactorings like this, if something goes wrong that makes it easier to track down and revert

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle stale

PoC in https://github.com/kubernetes-sigs/descheduler/pull/781

@ingvagabund @damemi @a7i should we close this one? Considering the title, strategies are moved to plugins now

I think it's worth keeping open until we've gotten off of the migration wrapper

The migration wrapper removed through https://github.com/kubernetes-sigs/descheduler/pull/1006.


Integrate code analysis into build

With Roslyn, there came the concept of code analyzers. These static analysis tools can help catch common errors, which is why I think they are a perfect fit for the exercism C# track.
See https://github.com/dotnet/roslyn/pull/18285/files for a reference to the code style package.

@ErikSchierboom have you tried using that analyzer yet? My understanding is that library allows you to write your own anlyzers, but if you want to use some existing ones you have to use something like StyleCop.Analyzers.
I tried integrating StyleCop.Analyzers but couldn't figure out how to customize the list of rules and there are likely some rules that we don't want to enforce such as XML documentation on every method as that tends to be a bit heavy handed.

I haven't yet. These analyzers are still being worked on I think. The StyleCop analyzers might indeed be too strict.

#380 handles this

Are analyzers the only option for linting code?
https://github.com/DotNetAnalyzers/StyleCopAnalyzers
Is there a defacto analyzer?

I'm inclined to close this for now. We can always re-add it later.


update logsumexp

hi @fwilliams,
in recent pytorch versions it has been introduced torch.logsumexp which I think that could be used to replace stabilized_log_sum_exp in your implementation of the sinkhorn algorithm.
found this throw: https://github.com/magicleap/SuperGluePretrainedNetwork/blob/master/models/superglue.py#L143-L172

Thanks for the pointer! I wrote this during a project in 2018 and didn't know this function was available. I'll update this in the next version of the library.


Exception due to shared inline data

Hi,
the attached code raises the following exception:
File "/opt/miniconda/lib/python3.6/site-packages/asdf-1.3.1.dev980-py3.6.egg/asdf/block.py", line 649, in get_block
    raise TypeError("Unknown source '{0}'".format(source))
TypeError: Unknown source '[-1.0, 1.0]'

This is presumably due to the _block attribute being set to None when the inline array is first encountered during writing.
inline_py.txt

@bobpepin thanks for the bug report. I was able to reproduce and will try to get a fix out shortly.


groups properties override individual

Not sure if it is as suppose to be. However it is weird that if you have a group properties and you set a node to that group and put property to different value then it is being overridden with group properties. Node borderWidth is 5 in the following example, however i would expect 1.
    var nodes = new vis.DataSet([
        {
            id: 1,
            label:
                [
                    "I'm an alligator,",
                    "I'm a mama-papa coming for you.",
                    "I'm the space invader,",
                    "I'll be a rock 'n' rollin' bitch for you."
                ].join("\n"),
            x: 0,
            y: 0,
            color: {
                background: "transparent"
            },
            group: "test",
            borderWidth: 1
        }
    ]);

    // create a network
    var container = document.getElementById("mynetwork");
    var data = {
        nodes: nodes,
        edges: []
    };
    var options = {
        groups: {
            test: {
                borderWidth: 5
            }
        }
    };
    var network = new vis.Network(container, data, options);

I also lost multiple hours because of this the other day. Definitively not intuitive.

I've encountered the same issue with image and shape options when I was representing pods in k8s and I wanted to represent all the pods and use one image for them all except the pods running a particular container, which I wanted to have a different image while still belonging to the pod group.
Apparently this also used to be the case with the color option.


Normalize color in theme

I see there are some color implemented in the theme of app but not in the theme of components.
It can create some differences between what is display in the app and the storybook of components
For example, brand 700, 800, 800 are in app but not in components
Related files:

https://github.com/liteflow-labs/nft/blob/main/apps/test/styles/theme.ts
https://github.com/liteflow-labs/nft/blob/main/packages/components/src/baseTheme.ts

I would suggest first:

make sure any color used in the components AND templates packages are defined in theme of components
make sure client's app have the right color and overwrite

And then, more a open question:

Why the test app have a custom colors? What is the point of this?

Closing this issue as this won't be prioritize


[FEATURE] Builder option to copy entire object except for explicitly set fields

Hello, I often need to clone entire objects, except for some fields. This is useful when the POJO goes through some external operation and that update needs to be reflected. I will call this new method fromObject throughout. Another way of describing this is adding a clone method in the @Builder.
Example:
Immutable Foo
// Example object
@Data
@Builder
public Class Foo{
    private final int id;
    private final String name;
}

Proposed feature
final Foo foo = Foo.builder().name("name").build();

try {
    final int assignedId = doStuff(foo) //foo has somehow changed here, maybe an API call or persistence
    return Foo.builder()
        .fromObject(foo) // magic happens here. All foo fields are copied to the new object
        .id(assignedId) //... except for id, which gets explicitly overwritten by the call to the setter
        .build();
} catch(...){}

With current Lombok features:
final Foo foo = Foo.builder().name("name").build();

try {
    final int assignedId = doStuff(foo) //foo has somehow changed here, maybe an API call or persistence
    return Foo.builder()
        .name(foo.getName())
        // more setters here
        .id(assignedId)
        .build();
} catch(...){}

If we only need to change id we can do the above with @Wither, but this becomes tediously repetitive when dealing with multiple setters - both in Foo definition and when using it to copy objects. It would also help code clarity if the fact that foo is being copied is explicitly specified.
I've seen the following with plain Java (and non-final POJOs):
Mutable Foo
// Non-Lombok object with setters
public Class Foo{
    private int id;
    private String name;

    public Foo setId(final int id){ this.id=id; return this;}
    public Foo setName(final String name){ this.name=name; return this;}

}

Vanilla Java with mutable Foo
try {
    final int assignedId = doStuff(foo) //foo has somehow changed here, maybe an API call or persistence
    return foo.setId(assignedId);
} catch(...){}

I hope what I'm trying to get across is clear, of course I'll be happy to clarify as needed. Thank you for your work on Lombok by the way, it kinda took the boring bits out of Java. Looking forward to the response.

I may be missing a point here, but where is the difference to @Builder(toBuilder=true)?

@janrieke Absolutely none. Thanks for pointing it out, I missed it in the documentation. You've made my life slightly easier.


[T4A2][T09-B2]Ashley Ong

Ready for review.

@ashleyyy94  Some comments added. Please close the PR after reading comments.


⚠ Bofrost.at has degraded performance

In cfee092, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 963 ms

Resolved: Bofrost.at performance has improved in 567c098 after 20 minutes.


Use runtime: php if possible

Some directories still have runtime: custom, but we should use runtime: php if possible.

[x] appengine/flexible/symfony
[x] appengine/flexible/drupal8

see https://github.com/GoogleCloudPlatform/php-docs-samples/pull/190

Yay!


Add Hierarchy dump (text/proprietary format) as a test artifact

Detox 17 introduced split log for failures, where the failure reason is always printed, but the hierarchy is now only printed in verbose or trace logging modes.
A better solution would be to collect these hierarchy dumps as artifacts for failing tests.
An even better solution will be to actually capture the hierarchy of Xcode's View hierarchy format (https://github.com/LeoNatan/LNViewHierarchyDumper).
And on Android, to research capturing hierarchy in Layout Inspector's format.

I need JS support. I will send a URL on failure and need the JS to read the file and take it.
We can also offer an API, captureViewHierarchy(name), which will produce the same result on demand. Need JS support for this.


Smoke tests should disable Cosmos DB testing and allocation

Cosmos DB testing is already disabled here but we should add the dependency into the POM file again.


Clarify/improve handling of output pipes (stderr/stdout/null) on windows

description
while documenting basic logging (#13927) it became apparent that some of the ~default (container) configs might not work on windows, and this pointed to an underlying issue in terms of handling those paths and/or documenting something similar
one suggestion that came up  was to have some kind of config identifier "$dev_stdout" eg, that would #justwork on both

@envoyproxy/windows-dev ive shifted the conversation about /dev/null/stdout/stderr to a new ticket

ref #13935

i guess this could also potentially apply to stdin although im not aware of it being used by envoy

one thing im still not clear about is whether the "note" about CON here https://www.envoyproxy.io/docs/envoy/latest/start/quick-start/run-envoy#debugging-envoy (just above the linked title) is correct
im happy to update/remove if it is not

I am proposing the following approach that will be part of filesystem_impl:
This is a runtime best-effort translation of common UNIX paths to Windows. Given that the set of known UNIX paths is small the translation should not add much overhead.
@@ -31,6 +31,14 @@ Api::IoCallBoolResult FileImplWin32::open(FlagSet in) {
     return resultSuccess(true);
   }

+  auto std_handle = toStandardHandle(path);
+  if (std_handle != INVALID_HANDLE) {
+    fd_ = GetStdHandle(std_handle);
+    return;
+  }
+
+  auto translated_path = translateFromUnixPath(path);
+
   auto flags = translateFlag(in);
   fd_ = CreateFileA(path_.c_str(), flags.access_, FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
                     flags.creation_, 0, NULL);
@@ -274,5 +282,9 @@ bool InstanceImplWin32::illegalPath(const std::string& path) {
   return false;
 }

Where we have two different translation types:

Behind the toStandardHandle() function

{
  "/dev/stdout/" -> STD_OUTPUT_HANDLE
  "/dev/fd/1" -> STD_OUTPUT_HANDLE
  "/proc/pid/fd/1" -> STD_OUTPUT_HANDLE
}

(Similarly fd 0 will map to  STD_INPUT_HANDLE and fd 2 will map to STD_ERROR_HANDLE)

Behind the translateFromUnixPath() function (note that this translation is also used in here):

{
   "/dev/console" -> CONOUT
   "/dev/tty" -> CONOUT
   "/dev/tty/nnn"  -> CONOUT
   "CONIN" -> CONOUT
   "CONOUT" -> CONOUT
   "CON" -> CONOUT
   "/dev/null" -> NUL
}

I look for your feedback

I am proposing the following approach that will be part of filesystem_impl:
This is a runtime best-effort translation of common UNIX paths to Windows. Given that the set of known UNIX paths is small the translation should not add much overhead.
@@ -31,6 +31,14 @@ Api::IoCallBoolResult FileImplWin32::open(FlagSet in) {
     return resultSuccess(true);
   }

+  auto std_handle = toStandardHandle(path);
+  if (std_handle != INVALID_HANDLE) {
+    fd_ = GetStdHandle(std_handle);
+    return;
+  }
+
+  auto translated_path = translateFromUnixPath(path);
+
   auto flags = translateFlag(in);
   fd_ = CreateFileA(path_.c_str(), flags.access_, FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
                     flags.creation_, 0, NULL);
@@ -274,5 +282,9 @@ bool InstanceImplWin32::illegalPath(const std::string& path) {
   return false;
 }

Where we have two different translation types:

Behind the toStandardHandle() function

{
  "/dev/stdout/" -> STD_OUTPUT_HANDLE
  "/dev/fd/1" -> STD_OUTPUT_HANDLE
  "/proc/pid/fd/1" -> STD_OUTPUT_HANDLE
}

(Similarly fd 0 will map to  STD_INPUT_HANDLE and fd 2 will map to STD_ERROR_HANDLE)

Behind the translateFromUnixPath() function (note that this translation is also used in here):

{
   "/dev/console" -> CONOUT
   "/dev/tty" -> CONOUT
   "/dev/tty/nnn"  -> CONOUT
   "CONIN" -> CONOUT
   "CONOUT" -> CONOUT
   "CON" -> CONOUT
   "/dev/null" -> NUL
}

I look for your feedback

We might have to do some validation when in service mode that a user doesn't try to use stdout/err as the console functions/GetStdHandle will likely fail, something to test out at least

We might have to do some validation when in service mode that a user doesn't try to use stdout/err as the console functions/GetStdHandle will likely fail, something to test out at least

These should be non-recoverable failures scenarios right? If you run an application as service or as a detached process without a console and you request the output on the console then Envoy is misconfigured and it should fail.

These should be non-recoverable failures scenarios right?

Yeah good point, good enough to make sure we have good error messages etc., though that becomes a little funny with services and redirecting logs etc. 🤔

I think we could also constrain this to just access log output paths as well? I don't see much advantage at all going through the above logic and allowing these sorts of paths for files we're watching for config updates

I think we could also constrain this to just access log output paths as well? I don't see much advantage at all going through the above logic and allowing these sorts of paths for files we're watching for config updates

I think we could also constrain this to just access log output paths as well?

the change above implicitly only affects the access_log_manager since its the only component that is writing to file. As a result it is the only one that goes through the FileImpl.
When we are watching for config updates since this is a read operation we rely on fileReadToEnd which is on the InstanceImpl api.
Since this redirection are only for write and not for read I agree that they only make sense in FileImpl. The only place that I was planning to implement the translation is InstanceImpl is in the fileExists function.

I think we could also constrain this to just access log output paths as well?

the change above implicitly only affects the access_log_manager since its the only component that is writing to file. As a result it is the only one that goes through the FileImpl.
When we are watching for config updates since this is a read operation we rely on fileReadToEnd which is on the InstanceImpl api.
Since this redirection are only for write and not for read I agree that they only make sense in FileImpl. The only place that I was planning to implement the translation is InstanceImpl is in the fileExists function.

I'm trying to understand the goal of this bug and accompanying PR.
Do you want to be able to specify that access logs go to stdout/stderr in a configuration file? Why would you want to do that? For debug only?

I'm trying to understand the goal of this bug and accompanying PR.
Do you want to be able to specify that access logs go to stdout/stderr in a configuration file? Why would you want to do that? For debug only?

I'm trying to understand the goal of this bug and accompanying PR.
Do you want to be able to specify that access logs go to stdout/stderr in a configuration file? Why would you want to do that? For debug only?

See https://github.com/envoyproxy/envoy/blob/a4733f64e2566630a0bd7f1481331d9336af63ee/examples/cors/frontend/front-envoy.yaml#L18
this issue and PR are to allow us to have parity with Linux/macos and enable using the file access logger to output to stdout/error
e.g. in a containerized deployment you often have stdout/error captured by your container runtime etc., without a change of this sort we don’t really have a way to specify that we want this on windows AND you would have to know what platform you’re sending updates to if you are configuring access logging dynamically over xDS if we restricted it to platform specific paths

I'm trying to understand the goal of this bug and accompanying PR.
Do you want to be able to specify that access logs go to stdout/stderr in a configuration file? Why would you want to do that? For debug only?

See https://github.com/envoyproxy/envoy/blob/a4733f64e2566630a0bd7f1481331d9336af63ee/examples/cors/frontend/front-envoy.yaml#L18
this issue and PR are to allow us to have parity with Linux/macos and enable using the file access logger to output to stdout/error
e.g. in a containerized deployment you often have stdout/error captured by your container runtime etc., without a change of this sort we don’t really have a way to specify that we want this on windows AND you would have to know what platform you’re sending updates to if you are configuring access logging dynamically over xDS if we restricted it to platform specific paths

I'm still trying to wrap my arms around why this is a good thing, but it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers  if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.
I'm still not understanding why containers capturing stdout is better than using gRPC to relay to your aggregator.
From an implementation perspective, on Posix I'd still just referencing the already-open stdin/stderr/cerr/cout streams rather than trying to open a new one. You can use OO inheritance to or something to avoid special-casing in the existing FileSystem::File implementations, I think, as you definitely wouldn't want to allow closing stdin/stdout from that interface.

I'm still trying to wrap my arms around why this is a good thing, but it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers  if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.
I'm still not understanding why containers capturing stdout is better than using gRPC to relay to your aggregator.
From an implementation perspective, on Posix I'd still just referencing the already-open stdin/stderr/cerr/cout streams rather than trying to open a new one. You can use OO inheritance to or something to avoid special-casing in the existing FileSystem::File implementations, I think, as you definitely wouldn't want to allow closing stdin/stdout from that interface.

I'm still not understanding why containers capturing stdout is better than using gRPC to relay to your aggregator.

This is probably a separate discussion, I don't think theres any value judgement which is "better" just that file based access logging is a feature that exists in Envoy and is in use so to have parity across platforms we need a solution to do the equivalent logging to stdout/err on Windows.

it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.

Yeah, this is a good question to raise again. We hadn't come to any consensus on what that name would be or gotten much input from outside so the PR went forward to emulate paths on Windows.

From an implementation perspective, on Posix I'd still just referencing the already-open stdin/stderr/cerr/cout streams rather than trying to open a new one. You can use OO inheritance to or something to avoid special-casing in the existing FileSystem::File implementations, I think, as you definitely wouldn't want to allow closing stdin/stdout from that interface.

This is valid, but might be something to do in a separate change targeting non-Windows since we're aiming to only affect Windows codepaths (and the Windows implementation doesn't open new handles to stdout/err, but maybe could use the builtin File *stdout/err instead of what we have today?)
cc @davinci26

I'm still not understanding why containers capturing stdout is better than using gRPC to relay to your aggregator.

This is probably a separate discussion, I don't think theres any value judgement which is "better" just that file based access logging is a feature that exists in Envoy and is in use so to have parity across platforms we need a solution to do the equivalent logging to stdout/err on Windows.

it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.

Yeah, this is a good question to raise again. We hadn't come to any consensus on what that name would be or gotten much input from outside so the PR went forward to emulate paths on Windows.

From an implementation perspective, on Posix I'd still just referencing the already-open stdin/stderr/cerr/cout streams rather than trying to open a new one. You can use OO inheritance to or something to avoid special-casing in the existing FileSystem::File implementations, I think, as you definitely wouldn't want to allow closing stdin/stdout from that interface.

This is valid, but might be something to do in a separate change targeting non-Windows since we're aiming to only affect Windows codepaths (and the Windows implementation doesn't open new handles to stdout/err, but maybe could use the builtin File *stdout/err instead of what we have today?)
cc @davinci26

@ggreenway suggested:

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

I like this better. The advantage is we wouldn't have "special" names for files to trigger different semantics. The main drawback is that we'd have to enumerate the places where we'd want this behavior (maybe just access logs) and add new APIs and code to handle that there.

@ggreenway suggested:

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

I like this better. The advantage is we wouldn't have "special" names for files to trigger different semantics. The main drawback is that we'd have to enumerate the places where we'd want this behavior (maybe just access logs) and add new APIs and code to handle that there.

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

I'm still trying to wrap my arms around why this is a good thing, but it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.

There was a proposal regarding that but IMO I am not sure if bending windows to the UNIX standard makes more sense than introducing an envoy standard.
The reason for that is code samples/examples. We would like to have the work out of the box for Windows and if this is the case we would need to replace /dev/stdout references with envoy/stdout (name is just a sample to explain what I mean). From a user perspective the name envoy/stdout is going to add more mental friction.

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

This one works but then should we have the examples using this enum instead of the access_log path>>

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

I'm still trying to wrap my arms around why this is a good thing, but it would be possible to have special platform-independent syntax for naming stdout/stderr, which is more like this PR. I'd like to ask other @envoyproxy/maintainers if they think it's a great plan to have a special name you could put into any path in a config which is interpreted as stdout/stderr rather than being opened as a file system.

There was a proposal regarding that but IMO I am not sure if bending windows to the UNIX standard makes more sense than introducing an envoy standard.
The reason for that is code samples/examples. We would like to have the work out of the box for Windows and if this is the case we would need to replace /dev/stdout references with envoy/stdout (name is just a sample to explain what I mean). From a user perspective the name envoy/stdout is going to add more mental friction.

I think I'd rather have another field that is an enum, with values for stdout, stderr, and any other special files, and then make the validation allow either a path or this enum (can't retroactively make it oneof)

This one works but then should we have the examples using this enum instead of the access_log path>>

There's not really a Unix standard in play here. It's just a software engineering question of not having a pathname interpreted in a special way, so rather than inferring different semantics from the name, we explicitly put it in the enum.
I didn't totally understand the suggestion about the examples or the references to envoy/stdout, but if we are trying to put the access-log on stdout we'd have something like:
   access_log_destination: stdout

and not specify the path at all. Then if you want it in a file, you could say
  access_log_destination: file
  path: /var/logs/access.log

but the default value of access_log_destination would be file and so you could omit that, which keeps existing configs working, that just specify path.

There's not really a Unix standard in play here. It's just a software engineering question of not having a pathname interpreted in a special way, so rather than inferring different semantics from the name, we explicitly put it in the enum.
I didn't totally understand the suggestion about the examples or the references to envoy/stdout, but if we are trying to put the access-log on stdout we'd have something like:
   access_log_destination: stdout

and not specify the path at all. Then if you want it in a file, you could say
  access_log_destination: file
  path: /var/logs/access.log

but the default value of access_log_destination would be file and so you could omit that, which keeps existing configs working, that just specify path.

I think I did not make my concern clear.
If we go through we the enum approach then we should change all the samples in the current project that use path: /dev/stdout to use  access_log_destination: stdout. I want to make sure that we are all ok with that.

I think I did not make my concern clear.
If we go through we the enum approach then we should change all the samples in the current project that use path: /dev/stdout to use  access_log_destination: stdout. I want to make sure that we are all ok with that.

The goal is to have the config files in the examples directory be platform-agnostic, is that right? So we need to change all those examples. That seems reasonable to me, no?

The goal is to have the config files in the examples directory be platform-agnostic, is that right? So we need to change all those examples. That seems reasonable to me, no?

Just making sure that we are all in agreement since examples are the public facing documentation for our customers (envoy users) and we will be using a new configuration.
Closed the previous PR so I can open a new with the new approach of an ENUM.

Just making sure that we are all in agreement since examples are the public facing documentation for our customers (envoy users) and we will be using a new configuration.
Closed the previous PR so I can open a new with the new approach of an ENUM.

We might have to do some validation when in service mode that a user doesn't try to use stdout/err as the console functions/GetStdHandle will likely fail, something to test out at least

Just to clarify, that shouldn't be (ultimately) necessary. Until any global error log configuration setting modifies the output handle, my implementation of stderr -> Windows Event Logger for service controlled binaries just created a pipe to capture stdout and drop it in as windows events line-by-line. Easily expanded to do this for stdout too (in a different event priority, of course.) The trouble I've always run into is that although most errors go through the application's error logging schema, there will always be exceptions from dependency libraries choosing to write unexpected errors to stderr. Without piping these to the event logger, those get dropped and result in extra confusion.

We might have to do some validation when in service mode that a user doesn't try to use stdout/err as the console functions/GetStdHandle will likely fail, something to test out at least

Just to clarify, that shouldn't be (ultimately) necessary. Until any global error log configuration setting modifies the output handle, my implementation of stderr -> Windows Event Logger for service controlled binaries just created a pipe to capture stdout and drop it in as windows events line-by-line. Easily expanded to do this for stdout too (in a different event priority, of course.) The trouble I've always run into is that although most errors go through the application's error logging schema, there will always be exceptions from dependency libraries choosing to write unexpected errors to stderr. Without piping these to the event logger, those get dropped and result in extra confusion.

yeah, a separate issue for general envoy logs but we could implement something for Service mode where if you don't specify the --log-file parameter logs are output to the windows event log (maybe this isn't the default but an additional flag option instead, idk?)
we could honestly also even add an extension to output the http/tcp Access Logs to the Windows event log as well (analogous to the file and grpc log mechanisms)

yeah, a separate issue for general envoy logs but we could implement something for Service mode where if you don't specify the --log-file parameter logs are output to the windows event log (maybe this isn't the default but an additional flag option instead, idk?)
we could honestly also even add an extension to output the http/tcp Access Logs to the Windows event log as well (analogous to the file and grpc log mechanisms)

we could honestly also even add an extension to output the http/tcp Access Logs to the Windows event log as well (analogous to the file and grpc log mechanisms)

I think that's a great feature to roll out in 1.18.0 - with much more granularity (explicit grouping by type, id, source)!
It wouldn't replace the stderr level logging which we desperately need during startup though, since that extension would be instantiated much later.
For 1.17.0 we should be ok with a blend of --log-file, treating the SCM invocation as "experimental", and focusing on readiness of invocation as a console application under whatever framework the user chooses.

we could honestly also even add an extension to output the http/tcp Access Logs to the Windows event log as well (analogous to the file and grpc log mechanisms)

I think that's a great feature to roll out in 1.18.0 - with much more granularity (explicit grouping by type, id, source)!
It wouldn't replace the stderr level logging which we desperately need during startup though, since that extension would be instantiated much later.
For 1.17.0 we should be ok with a blend of --log-file, treating the SCM invocation as "experimental", and focusing on readiness of invocation as a console application under whatever framework the user chooses.

Addressed in PR #15202, closing


Fix title and add possibility to modify it

Signed-off-by: Sander Lepik<EMAIL_ADDRESS>Currently the  tag for primary template is broken. Trying to fix it, I ended up creating an option to modify it.

you forgot the second  tag and I also added default values if the option is not set in the config. Thanks for the pull request