IdFix link takes me to a different page

When I click the IdFix link on:
Use IdFix to identify errors such as duplicates and formatting problems in your directory before you synchronize to Azure AD and Microsoft 365.
It takes me to a page that doesn't talk at all about IdFix, but setup directory synchronization for M365.  https://docs.microsoft.com/en-us/microsoft-365/enterprise/set-up-directory-synchronization?redirectSourcePath=%252farticle%252fInstall-and-run-the-Office-365-IdFix-tool-f4bd2439-3e41-4169-99f6-3fabdfa326ac&view=o365-worldwide

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

ID: 06faa428-c7b6-ca5c-271e-3f98d9536d4f
Version Independent ID: 63adb39a-c4fa-92bb-480d-59bee8e2dc24
Content: Azure AD Connect: Prerequisites and hardware
Content Source: articles/active-directory/hybrid/how-to-connect-install-prerequisites.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@rconiv
Thanks for your feedback! We will investigate and update as appropriate.

@rconiv
Thank you for pointing this out! I've created a PR to update the documentation and it's currently waiting for the author to review and sign off.
PR:
Added new IdFix Link - https://github.com/Microsoft/idfix
Moved current IdFix Link to a different location within the sentence.
I will now close out this issue. Please allow some time for the author to review and the changes to reflect.
Thank you for your time and patience!

@rconiv
Thank you for pointing this out! I've created a PR to update the documentation and it's currently waiting for the author to review and sign off.
PR:
Added new IdFix Link - https://github.com/Microsoft/idfix
Moved current IdFix Link to a different location within the sentence.
I will now close out this issue. Please allow some time for the author to review and the changes to reflect.
Thank you for your time and patience!

Thank you for the help.


[stable/postgresql] Admin password not being set

Is this a request for help?:

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
Helm:
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Kubernetes:
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T19:44:10Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
postgresql
What happened:
Installing the helm chart is not setting the admin password for the postgres user, thus only allowing connections from <IP_ADDRESS>.
What you expected to happen:
The set password would be set, and allow connections
How to reproduce it (as minimally and precisely as possible):
helm install --set postgresqlPassword=<password> stable/postgresql

Get the pod tail the logs, and attempt to connect via the service name:

Welcome to the Bitnami postgresql container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues

nami    INFO  Initializing postgresql
postgre INFO  ==> No injected postgresql.conf file found. Creating default postgresql.conf file...
postgre INFO  ==> No injected pg_hba.conf file found. Creating default pg_hba.conf file...
postgre INFO  ==> Deploying PostgreSQL with persisted data...
postgre INFO  ==> Cleaning stale postmaster.pid file...
postgre INFO  ==> Configuring PostgreSQL...
postgre INFO  ==> Configuring replication parameters...
postgre INFO  ==> Configuring permissions for config files...
postgre INFO
postgre INFO  ########################################################################
postgre INFO   Installation parameters for postgresql:
postgre INFO     Persisted data and properties have been restored.
postgre INFO     Any input specified will not take effect.
postgre INFO   This installation requires no credentials.
postgre INFO  ########################################################################
postgre INFO
nami    INFO  postgresql successfully initialized
INFO  ==> Starting postgresql...
2019-01-26 19:55:22.364 GMT [90] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2019-01-26 19:55:22.364 GMT [90] LOG:  listening on IPv6 address "::", port 5432
2019-01-26 19:55:22.422 GMT [90] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2019-01-26 19:55:22.536 GMT [91] LOG:  database system was interrupted; last known up at 2019-01-26 19:55:12 GMT
2019-01-26 19:55:22.986 GMT [91] LOG:  database system was not properly shut down; automatic recovery in progress
2019-01-26 19:55:23.029 GMT [91] LOG:  invalid record length at 0/15C0C18: wanted 24, got 0
2019-01-26 19:55:23.029 GMT [91] LOG:  redo is not required
2019-01-26 19:55:23.294 GMT [90] LOG:  database system is ready to accept connections
2019-01-26 19:56:26.284 GMT [193] FATAL:  password authentication failed for user "postgres"
2019-01-26 19:56:26.284 GMT [193] DETAIL:  User "postgres" has no password assigned.
	Connection matched pg_hba.conf line 95: "host     all             all             <IP_ADDRESS>/0               md5"

Anything else we need to know:
Setting the password in postgres after the fact makes it work, ie, ALTER USER postgres WITH PASSWORD '<password>';

I am running into the same issue - password is not set.
Tried deleting (helm delete --purge), removing the volume manually and starting from scratch with exactly the same result.
Logs:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
sh: locale: not found
2019-02-07 20:20:37.958 UTC [21] WARNING:  no usable system locales were found
performing post-bootstrap initialization ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
syncing data to disk ... ok

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgresql/data -l logfile start

****************************************************
WARNING: No password has been set for the database.
         This will allow anyone with access to the
         Postgres port to access your database. In
         Docker's default configuration, this is
         effectively any other container on the same
         system.

          Getting started: https://docs.timescale.com/getting-started
         2. API reference documentation: https://docs.timescale.com/api
         3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture

        Note: TimescaleDB collects anonymous reports to better understand and assist our users.
         Getting started: https://docs.timescale.com/getting-started
 2. API reference documentation: https://docs.timescale.com/api
 3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture

Note: TimescaleDB collects anonymous reports to better understand and assist our users.
For more information and how to disable, please see our docs https://docs.timescaledb.com/using-timescaledb/telemetry.

 Getting started: https://docs.timescale.com/getting-started
         2. API reference documentation: https://docs.timescale.com/api
         3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture

        Note: TimescaleDB collects anonymous reports to better understand and assist our users.
         Getting started: https://docs.timescale.com/getting-started
 2. API reference documentation: https://docs.timescale.com/api
 3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture

Note: TimescaleDB collects anonymous reports to better understand and assist our users.
For more information and how to disable, please see our docs https://docs.timescaledb.com/using-timescaledb/telemetry.

CREATE EXTENSION
2019-02-07 20:20:39.052 UTC [42] ERROR:  TimescaleDB background worker connected to template database, exiting

/usr/local/bin/docker-entrypoint.sh: sourcing /docker-entrypoint-initdb.d/001_reenable_auth.sh
2019-02-07 20:20:39.053 UTC [26] LOG:  worker process: TimescaleDB Background Worker Scheduler (PID 42) exited with exit code 1

/usr/local/bin/docker-entrypoint.sh: sourcing /docker-entrypoint-initdb.d/002_timescaledb_tune.sh
Using postgresql.conf at this path:
/var/lib/postgresql/data/postgresql.conf

shared_buffers = 6531MB
effective_cache_size = 19594MB
maintenance_work_mem = 2GB
work_mem = 83604kB
timescaledb.max_background_workers = 4
max_worker_processes = 11
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
Writing backup to:
/tmp/timescaledb_tune.backup201902072020

Recommendations based on 25.51 GB of available memory and 4 CPUs for PostgreSQL 10
wal_buffers = 16MB
min_wal_size = 4GB
max_wal_size = 8GB
default_statistics_target = 500
random_page_cost = 1.1
checkpoint_completion_target = 0.9
max_connections = 20
max_locks_per_transaction = 256
effective_io_concurrency = 200
timescaledb.last_tuned = '2019-02-07T20:20:39Z'
timescaledb.last_tuned_version = '0.3.0'
Saving changes to: /var/lib/postgresql/data/postgresql.conf

waiting for server to shut down....2019-02-07 20:20:39.071 UTC [26] LOG:  received fast shutdown request
2019-02-07 20:20:39.075 UTC [26] LOG:  aborting any active transactions
2019-02-07 20:20:39.075 UTC [33] LOG:  terminating TimescaleDB background worker launcher due to administrator command
2019-02-07 20:20:39.075 UTC [33] FATAL:  terminating connection due to administrator command
2019-02-07 20:20:39.076 UTC [26] LOG:  worker process: TimescaleDB Background Worker Launcher (PID 33) exited with exit code 1
2019-02-07 20:20:39.076 UTC [26] LOG:  worker process: logical replication launcher (PID 34) exited with exit code 1
2019-02-07 20:20:39.077 UTC [38] LOG:  terminating TimescaleDB job scheduler due to administrator command
2019-02-07 20:20:39.077 UTC [38] FATAL:  terminating connection due to administrator command
2019-02-07 20:20:39.077 UTC [26] LOG:  worker process: TimescaleDB Background Worker Scheduler (PID 38) exited with exit code 1
2019-02-07 20:20:39.078 UTC [28] LOG:  shutting down
2019-02-07 20:20:39.124 UTC [26] LOG:  database system is shut down
 done
server stopped

PostgreSQL init process complete; ready for start up.

2019-02-07 20:20:39.182 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2019-02-07 20:20:39.182 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2019-02-07 20:20:39.190 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2019-02-07 20:20:39.329 UTC [51] LOG:  database system was shut down at 2019-02-07 20:20:39 UTC
2019-02-07 20:20:39.337 UTC [1] LOG:  database system is ready to accept connections
2019-02-07 20:20:39.338 UTC [57] LOG:  TimescaleDB background worker launcher connected to shared catalogs
2019-02-07 20:21:09.547 UTC [84] FATAL:  password authentication failed for user "postgres"
2019-02-07 20:21:09.547 UTC [84] DETAIL:  User "postgres" has no password assigned.
        Connection matched pg_hba.conf line 95: "host all all all md5"

It seems you're not using Bitnami PostgreSQL image, are you? Please note that this chart is designed to work with this Docker image that has a series of initialisation scripts that sets PostgreSQL based on the env. variables used on the chart.
Could you share what values are you using myconfig.yaml?

Make sure you don't have any existing PersistentVolumeClaims
kubectl get pvc

Any existing claims will be automatically reattached leaving you with the postgresqlPassword from a previous ly installed helm release.

@mbalaa-spring,
no, always creating from scratch
@nrmitchi
That's true, initially I used none bitnami image. Yet later I tried bitnami based image of timescaledb (timescale/timescaledb :1.2.0-pg10-bitnami) and it gave the same result.

Yet later I tried bitnami based image of timescaledb

That image (TimescaleDB) is not maintained by Bitnami nor based on any Bitnami image. Do you face the same issues when using the bitnami/postgresl image?

I don't like bringing this up again, but I have raised concerns in the past about the Bitnami "ownership" of this community chart, in that it broke compatibility with community maintained charts. In my opinion, if this chart does not work with images based off of the main postgres image, it should be considered a bug in-and-of itself.

@juan131

That image (TimescaleDB) is not maintained by Bitnami nor based on any Bitnami image.

As far as I understand it is based on bitnami:
https://github.com/timescale/timescaledb-docker/blob/master/bitnami/Dockerfile#L99

Hi @cloud-rocket
This other Dockerfile doesn't use Bitnami as base:
https://github.com/timescale/timescaledb-docker/blob/master/Dockerfile
I didn't know they had an alternative image based on Bitnami's one. Are you using that image?

In my opinion, if this chart does not work with images based off of the main postgres image, it should be considered a bug in-and-of itself.

This topic has been extendedly discussed in the past. There were strong reasons for this move (see https://github.com/helm/charts/pull/8004) and the image has been adapted to support all the features existing in the image maintained by Docker Inc plus others that are only supported on Bitnami's one.
IMHO we're moving to a distributed repositories model where everyone can create its own chart repository and include its own charts based on the Bitnami, Docker or any other's company images (even your own images).

Maybe this is the issue:
https://github.com/helm/charts/blob/master/stable/postgresql/templates/statefulset.yaml#L135
We are setting the statefulset env var as POSTGRES_PASSWORD but the bitnami docker image expects:
POSTGRESQL_PASSWORD
https://github.com/bitnami/bitnami-docker-postgresql#setting-the-root-password-on-first-run

I just spent a few hours chasing this too. They have release candidates for updated bitnami images that use the same environment variables as the main postgres image. No idea why https://github.com/helm/charts/pull/10757 was merged before the binami releases...
Anyway using the rc tag worked for me:
  image:
    registry: docker.io
    repository: bitnami/postgresql
    tag: 11.1.0-r62

As @hardbyte mentioned, Bitnami images supports both formats on env. variables as you can check in the link below:
https://github.com/bitnami/bitnami-docker-postgresql#environment-variables-aliases
You should be able to use bot POSTGRESQL_PASSWORD  and POSTGRES_PASSWORD if you're using the latest version of bitnami/postgresql image.

@juan131 I'm not quite sure what you're saying, and just want to confirm:
Was this issue corrected by a fix in the underlying bitnami docker image? If so, have the updates to the underlying image been released yet?
As well, does that imply that any images based off of the previous bitnami/postgres image will continue to be broken until they are rebuilt off of the new version?
Looking at the changes in #10757, this seems to be the second time that these parameters names have been changed in a backwards incompatible fashion (IIRC the first was when Bitnami first took "ownership" of this chart). Is there a reason that a safe update (ie, continuing to use the existing env names, while duplicating with the new name during a transition period) was not used? Is there any way that we can ensure that backwards incompatible changes are not arbitrarily introduced again in the future?

Was this issue corrected by a fix in the underlying bitnami docker image? If so, have the updates to the underlying image been released yet?

The issue with the env. variables format "POSTGRESQL vs POSTGRES" was fixed and released. It doesn't mean it addresses your specific issue. I think the issue in your case is the master pod being restarted before it finishes the initialisation of the container
Could you please share the logs of the pod during the first initialisation?

does that imply that any images based off of the previous bitnami/postgres image will continue to be broken until they are rebuilt off of the new version?

No, it implies that images based on old bitnami/postgres images won't support both env. variables formats.

this seems to be the second time that these parameters names have been changed in a backwards incompatible fashion

AFAIK the changes included in #10757 did not introduce backwards incompatibilities. You should be able to upgrade the chart without any issue since both formats for env. variables are supported.

Is there any way that we can ensure that backwards incompatible changes are not arbitrarily introduced again in the future?

We do not introduce backwards incompatibilities unless there's a strong reason to do so. Of course we are humans and we make mistakes and it's impossible to guarantee that sth like that isn't happening anymore.

I have the same issue with stable/postgresql:11.2.0 image - from what I understand from the thread it should works on it - however it does not.

With image docker.io/bitnami/postgresql:10.7.0  helm delete --purge and deleting the PVC manually o,0 solve the problem. We might need some verification mechanism to avoid this issue?

Chart version 3.11.6

@123BLiN it seems you're using an old version of the MongoDB chart. Please note the latest version is 5.10.0. Can you reproduce the issue using the latest version too?

helm delete --purge and deleting the PVC manually o,0 solve the problem

@zakkg3 were you unable to set the admin password after doing "helm upgrade"?

@juan131 I'm trying postgres, not mongo. Btw if it matters we run it multiple times on the very fresh clusters from Terraform. Could it be that needed environment variables are not in all latests bitnami postgres images?

Sorry @123BLiN ! My fault.. You're right but it's also an old version, isn't it? Latest PostgreSQL version is 3.13.1

@juan131 the problem is the PVC have a stored passwd there. so when you upgrade a chart with postgresql as a requierement, if something changed with posgresql, helm will recreate the pod, and the password... but postgresql will find the PVC with config and the old password there. so the passwd in the secret, the one iam reading for inject in my config to connect to postgresql, is a newone different form the one in the PVC.
I guess some script that check if postgresql found a preexisting config there update the secret so when some other consume this secrets its the actual one will solve this problem.

We discussed this in the past an I suggested using "hooks" to avoid recreating a new secret, see https://github.com/helm/charts/pull/10400
It was rejected since it was considered a too complex solution.
The only way to do the upgrade with the current approach is to ensure you're setting the same password when upgrading (via values.yaml or --set XXX=YYY).

@zakkg3 I dont think this is related to the original issue (postgres not setting a password at all), but the problem you are seeing is a thing in a ton of different charts. To deal with it I've always specified a password manually, in all charts that require it.

I totally agree with @nrmitchi !
It's a good practice to specify the password every-time you run helm install XXX... or helm upgrade YYY...


Work isn't being tracked despite log set to ALL

RT.

Oh wait not on latest update. Sounds like it would fix this issue. I'll keep this open until I test it

Seems to have been fixed by latest patch yeah


SAK-40680 SiteManage Joinable groups should show state of locked groups

https://sakaiproject.atlassian.net/browse/SAK-40680
In this change there is also some cleanup of and removal of static
uses of services in SiteAction.

@ern can we get a screenshot of this?


Manually skip withdrawn for @m365-admin/customizations as the package was malicious.

ref: https://github.com/advisories/GHSA-8646-rr57-mhf6
ref: https://socket.dev/npm/package/@m365-admin/customizations

Added versions to ensure that if the range needs to be removed there is some version detail present.


CDPS-894: Add metadata to ref data physical attributes

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.54%. Comparing base (fc43dba) to head (40f0bdf).

Additional details and impacted files
@@             Coverage Diff              @@
##               main      #53      +/-   ##
============================================
+ Coverage     82.89%   83.54%   +0.64%
- Complexity      364      366       +2
============================================
  Files            56       56
  Lines          1099     1112      +13
  Branches        110      105       -5
============================================
+ Hits            911      929      +18
  Misses          115      115
+ Partials         73       68       -5

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


docs(marker): 优化 marker demo

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 78.562%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2762

Relevant Lines:
3306

💛  - Coveralls


Create "related projects" section for README

English version (Portuguese version here)
What
Create a "related projects" section in the README.md to help new users evaluate if dpckan fits their use case better than other tools in the broader Frictionless and CKAN ecosystem and understand where it is positioned in this space. In the words of ROpenSci software review template

Are there other ~R packages~ tools that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

Why
Understand where a tool fits and what gap it solves is hard and time consuming. We should to the extent possible make it easier for users to make sound decisions in this respect with the minimal effort.
Tools builders are uniquely positioned to do this and open source software from government should create the honest assessment as possible.
How
The section should at least compare and contrast dpckan with the projects

ckanext-datapackager. CKAN extension for importing/exporting Data Packages
frictionless-py CKAN plugin
datapackage-pipelines-ckan. Data Package Pipelines processors for CKAN

It should also explain the essential goal of remote data package synchronization (ie. incremental updates) and the architecture decision to have a tool that can be used with CKAN instances that are not necessarily under control of the dpckan user and/or has support for data packages.
Some links for inspiration here

https://github.com/rstudio/gt#how-gt-fits-in-with-other-packages-that-generate-display-tables
https://github.com/rich-iannone/pointblank#how-pointblank-fits-in-with-other-packages-that-validate-tabular-data
https://github.com/junegunn/fzf/wiki/Related-projects
https://github.com/BurntSushi/ripgrep#why-shouldnt-i-use-ripgrep
https://click.palletsprojects.com/en/8.0.x/why/

Portuguese version #
Inserir na documentação uma discussão com análise de projetos semelhantes e o diferencial do dpckan é uma boa prática pois ajuda a inserir o dpckan no ecossistema e o processo decisório de um novo usuário que está considerando utilizar a biblioteca.
Uma pergunta do ROpenSci que captura essa intenção é

Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

Alguns exemplos concretos de softwares com uma seção para explicação de diferenças/semelhanças

https://github.com/rstudio/gt#how-gt-fits-in-with-other-packages-that-generate-display-tables
https://github.com/rich-iannone/pointblank#how-pointblank-fits-in-with-other-packages-that-validate-tabular-data
https://github.com/junegunn/fzf/wiki/Related-projects
https://github.com/BurntSushi/ripgrep#why-shouldnt-i-use-ripgrep
https://click.palletsprojects.com/en/8.0.x/why/

@fjuniorr, acredito que esquecemos de fechar esse issue, uma vez que arquivo foi criado durante hackathon


testing: test with child process sometimes hangs on 1.10; -timeout not respected

What version of Go are you using (go version)?
go version go1.10 linux/amd64
What operating system and processor architecture are you using (go env)?
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/psanford/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/psanford/projects/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build953969108=/tmp/go-build -gno-record-gcc-switches"

What did you do?
After upgrading to 1.10 we had one test that started to hang intermittently. The test in question starts a child process which it kills by canceling a context object at the end of the test method. It does not do an explicit cmd.Wait().
Here is a minimal test case that demonstrates the problem:
https://play.golang.org/p/8rq41A5Khsm
I can get this to hang consistently by running it in a bash while loop:
$ while true; do go test -timeout 5s -v -count 1 .; sleep 0.1; done
=== RUN   TestOSExecNoWait
start
done
--- PASS: TestOSExecNoWait (0.01s)
PASS
ok      _/tmp   0.012s
=== RUN   TestOSExecNoWait
start
done
--- PASS: TestOSExecNoWait (0.01s)
PASS
ok      _/tmp   0.012s
=== RUN   TestOSExecNoWait
start
done
--- PASS: TestOSExecNoWait (0.01s)
PASS
ok      _/tmp   0.012s
=== RUN   TestOSExecNoWait
start
done
--- PASS: TestOSExecNoWait (0.01s)
PASS

<hangs here indefinitely>

If I explicitly call cmd.Wait() the test does not hang. If I don't attach the child process' Stdout and Stderr to os.Std{out,err} the test does not hang.
On 1.9.4 the test does not hang.
Its also interesting that even though I specified -timeout 5s the test runner hangs forever.

the test runner hangs forever.

It only hangs 60 seconds on my machine.
go test hangs at
https://github.com/golang/go/blob/f6c67813025305c1dfab61b43e416474ca56a45b/src/cmd/go/internal/test/test.go#L1271
And cmd.Wait() is waiting at
https://github.com/golang/go/blob/f6c67813025305c1dfab61b43e416474ca56a45b/src/os/exec/exec.go#L275
This io.Copy() is reading a pipe reader. It won't return until the pipe writer is closed.
The pipe writer will be closed when the sleep 60 exits. So it hangs 60 seconds.
func TestOSExecNoWait(t *testing.T) {
...
	cancel()
}

After the cancel() returns, the main function will also return.
The child process may or may not be killed, so it hangs intermittently.

It only hangs 60 seconds on my machine.

Yes in the example provided it only hangs for 60 seconds because the child process exits.
In the test where I first found this issue the child process never exits so it hangs forever.

I don't think this issue is a regression introduced in Go 1.10.
I can use Go 1.9 to reproduce it but with a different condition.
This difference was introduced in bd95f889cdd241202fac01b29a3f3d7c03131a20.
https://github.com/golang/go/commit/bd95f889cdd241202fac01b29a3f3d7c03131a20#diff-acaf53a9cd478507ebbcf85037940b4dL1080
If the go command needs a bytes.Buffer to save the output, os/exec will open a pipe.
And go will hang until the pipe is closed.
The timeout doesn't work because it isn't handled by go.
There is a testKillTimeout in go, but it also hangs at cmd.Wait().

See also #23019.

@gopherbot please open backport tracking issues. This might be a 1.10 regression, or also a 1.9 issue.

I've encountered the same problem; I was even thinking that our CI was completely broken, as I didn't understand how go test ./..., with a default timeout of 10m, could possibly run for six hours.
I have a way to reproduce this reliably on Linux:
https://play.golang.org/p/nvycpKfjzkL
$ go test -timeout=1s
panic: test timed out after 1s
[...]
[exits]
$ go test -timeout=1s .
[hangs for a long time]

It seems to me like the elements are:

Running go test with arguments, so that the output is buffered for caching etc
The test executes a program which hangs or runs for a long time
The executed program's output is wired to the test's own output

So it seems to be exactly the same bug found previously in this issue. At a conceptual level, this seems fairly straightforward; if the test executable timeout is hit, all children processes should be killed, and any goroutines waiting for their output should be cancelled or stopped. But I assume the actual fix might be a bit tricky.
@bcmills @jayconrod @matloob as owners of cmd/go, any thoughts?

Also, before anyone spends significant time into a fix, I think we could just fix https://github.com/golang/go/issues/23019 instead. It would save far more time in the long run, because it's a change we likely want to do anyway and should fix other cascading bugs. But it's also a bit more controversial.

I'm really not sure about #23019: the copying is a symptom (of child processes left running with open file handles), not the root cause here.
I think the main problem in this case is that the child process is not being terminated when the test process is. I think go test should make a best effort to terminate all subprocesses of the test process, unless they were explicitly started in a way that would suggest otherwise (such as by setting Setpgid in the SysProcAttr field).
However, I'm not sure what the most appropriate way to achieve that would be. I could imagine:

Hooking the os package from the testing package to have it set cmd.SysProcAttr.Pdeathsig implicitly where available (but I think “where available” is only Linux)?
Hooking the os package so that the testing.M.startAlarm callback can enumerate and signal all subprocesses started from the test?
Changing cmd/go to start each test in its own process group, forward signals to that process group explicitly, and signal the whole group on timeout?
Changing testing and/or cmd/go to enumerate child processes using procfs or similar?
Something else that I've missed?

And I'm not even sure where to start on Windows, since I assume there is no procfs there.

I think you're right, we should terminate all children processes. It's a bit alarming that that's not the default behavior, and more so that there doesn't seem to be a portable way to do it.
You could blame this on the written test, since technically I could wrap exec calls with a timeout from testing.T.Deadline. Still, you'd be relying on the tests being written properly that way, which is not very realistic, particularly since that Deadline method is very new.
Shouldn't os/exec have some sort of option to apply this "kill all child processes" logic in the most portable way possible? It seems like such a common source of problems, and I've personally had to implement non-portable hacks like Pdeathsig before.

I don't think the go test behavior should rely on folks using os/exec in any particular way. (I would rather we find a more transparent fix.)

But yes: I think it would be handy for the os package to have some straightforward way to express “send this signal to this process and all of its children”. Maybe that's the process-group solution?

The problem with a general "signal process and its children" mechanism on Unix systems is that the only options are "send signal to process" and "send signal to thread" and "send signal to process group".  And we definitely don't want to start every new process in a different process group, as that will have surprising effects on the use of ^Z from the terminal.  And of course we have no idea what processes a child process may start.
That said we could in principle invoke the ps program or (on GNU/Linux) read the /proc file system to look for all processes, build a process tree, and use that to identify the children of our child process.  But that seems like a rather complex mechanism to implement a standard library function.
For testing specifically, it might be somewhat acceptable for go test to start the test binary in a separate process group, in which case it would be straightforward for the go command to kill the entire test binary process group.

Interesting, I wasn't thinkinf of the implications of doing this in general. I agree that the use case for testing is pretty narrow, especially because I don't think we should ever leak processes or run in the background.

See previously #28039.

This just bit me as well. Ran through a fair few hours of GitHub CI time before I noticed something was wrong. (Tip: set timeout-minutes in your Actions even if you don't need it.)
For those finding this thread and hoping for some code to copy/paste to work around the issue, here's the suggestion from @mvdan above, spelled out.
Change:
cmd := exec.Command("YOUR_PROGRAM")

to something along these lines:
ctx := context.Background()
deadline, ok := t.Deadline()
if ok {
	// Give ourselves 100ms to kill the command before the actual deadline arrives.
	deadline = deadline.Add(-100 * time.Millisecond)
	var cancel func()
	ctx, cancel = context.WithDeadline(ctx, deadline)
	t.Cleanup(cancel)
}
cmd := exec.CommandContext(ctx, "YOUR_PROGRAM")

(@mvdan @bcmills @ianlancetaylor feel free to edit this comment directly if you'd suggest a different formulation)

@josharian, if your subprocess is a Go program I suggest sending SIGQUIT on timeout instead of SIGTERM (so that you get a goroutine dump), but that's currently a bit complicated.
(My proposal #50436 aims to make that somewhat smoother, but the fact that SIGQUIT is not defined on all platforms remains a bit of a rough edge.)

I've been thinking about this some more.
I've added a reproducer (and proposed fix) in https://go.dev/cl/456116.
Notably, it is possible to reproduce this behavior even for a passing test, not just a failing one: the test may start and leak a subprocess, and then return from all of the Test functions, print PASS, and exit with code 0 while the subprocess is still running (and still holding open the pipes).
I don't think tests should be in the habit of orphaning subprocesses, and perhaps we should fail (or terminate the subprocesses) of tests that do so. On the other hand, that's a much harder problem, and programs that start subprocesses that may run indefinitely should arrange for those processes to be terminated anyway — whether by using Pdeathsig, or having the subprocess periodically probe stderr or stdout, or having it exit when stdin is closed.
(Note that in the integration test, I used a periodic write to stderr to terminate the subprocess. It's not perfect — it can leave the orphan running for up to 100ms after everything else has returned — but it at least does eventually clear up on its own.)
So, for now I think we should set a WaitDelay on the test process, and mark the test as failed if that WaitDelay expires (even if it would have passed otherwise).


Remove features

Remove Cirrus & Pan Landsat bands.

Yes, good.  Little bit of extra typing in names can save lots of time in the future.


Fix/external user support

Adding migration dialog
Allowing external user to access the app

Codecov Report
Attention: Patch coverage is 22.72727% with 17 lines in your changes missing coverage. Please review.

Project coverage is 53.88%. Comparing base (9d3d67d) to head (7381270).

Files with missing lines
Patch %
Lines

lib/user/repositories/user_repository.dart
0.00%
10 Missing :warning:

lib/tools/functions.dart
0.00%
3 Missing :warning:

lib/user/providers/user_provider.dart
0.00%
3 Missing :warning:

lib/user/class/user.dart
83.33%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #418      +/-   ##
==========================================
- Coverage   54.04%   53.88%   -0.17%
==========================================
  Files         168      168
  Lines        3708     3723      +15
==========================================
+ Hits         2004     2006       +2
- Misses       1704     1717      +13

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


Setting certificate properties on import requires an issuer

In track 2 setting certificate properties via CertificatePolicy requires passing an issuer, when in track 1 that was not required.
To support import, define a default constructor but leave Issuer, Subject, and SubjectAlternativeNames read-only properties. The parameters in existing constructors should also continue to be asserted. issuer is optional during import, and subject is ignored - obtained from the X509 certificate anyway. We could also loosen restrictions in the future if needs be.
To note: if we did loosen restrictions later and allowed subject or SAN to be null, the service does return a pretty descriptive error that would help customers diagnose the issue:
{
    "error": {
        "code": "BadParameter",
        "message": "Either subjectName or san must be present"
    }
}

@heaths Are we sure we need this in the current milestone which ends tomorrow?

I noted in our Teams channel I was merely adding it in this milestone if it could be done (should be small), but punting it to March is perfectly fine.

Summarizing our conversation:
In TS land the scenario is a bit different:

Issuer is already optional
We do require either subject or SAN

To support import we need to provide a different type that allows users to omit all three when importing a certificate.

Create: Issuer + (SAN | Subject)
Import: everything optional

I think we already GA'd with optional issuer so all we can do now is loosen restrictions on (SAN | Subject) when importing to support this scenario.

@maorleger that sounds good to me!


Doesn't work at all in Chrome

Hey,
this works great in firefox, but using :
Chrome Latest Version 77.0.3865.90 (Build officiel) (64 bits) it doesn't
What i get on the console :
VueRecord.umd.js?6cb0:4158 DOMException
| _callee$ | @ | VueRecord.umd.js?6cb0:4158
  | tryCatch | @ | VueRecord.umd.js?6cb0:2463
  | invoke | @ | VueRecord.umd.js?6cb0:2689
  | prototype. | @ | VueRecord.umd.js?6cb0:2515
  | asyncGeneratorStep | @ | VueRecord.umd.js?6cb0:4080
  | _throw | @ | VueRecord.umd.js?6cb0:4106
  | Promise.then (async) |   |
  | asyncGeneratorStep | @ | VueRecord.umd.js?6cb0:4090
  | _next | @ | VueRecord.umd.js?6cb0:4102
  | eval | @ | VueRecord.umd.js?6cb0:4109
  | F | @ | VueRecord.umd.js?6cb0:2014
  | eval | @ | VueRecord.umd.js?6cb0:4098
  | start | @ | VueRecord.umd.js?6cb0:4169
  | startRecording | @ | VueRecord.umd.js?6cb0:4317
  | invoker | @ | vue.common.js?2371:2029
  | fn._withTask.fn._withTask | @ | vue.common.js?2371:1828
Demo page fails as well on chrome

have you checked that your browser recognizes the media device such as webcam or microphone?
usually DOM Exceptions (for this plugin) means you don't have any microphone/webcam attached when trying to record or that you denied the permission for the browser to access the device

You are right, was initially testing about firefox fine , this doesnt come
to my mind.
Thanks
Cordialement.
D. Buisine
Le dim. 13 oct. 2019 à 05:32, Filippo Conti<EMAIL_ADDRESS>a
écrit :

have you checked that your browser recognizes the media device such as
webcam or microphone?
usually DOM Exceptions (for this plugin) means you don't have any
microphone/webcam attached when trying to record or that you denied the
permission for the browser to access the device
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/codekraft-studio/vue-record/issues/1?email_source=notifications&email_token=ABMMN2YDSWFNLCZPCMPHOFTQOKQEBA5CNFSM4JACWNO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCOFEA#issuecomment-541385360,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMMN2ZIEOTR3YBJHYL52LTQOKQEBANCNFSM4JACWNOQ
.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/95686

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/97415

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/97492

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/110887


Security fixes

Fixes a known security issue in qs. Changes were applied on top of the latest release (v0.6.1) so that this can be released as a separate version (e.g. can't be merged into master) until later changes land (e.g. v0.7.0). Closes https://github.com/gruntjs/grunt-contrib-watch/issues/399. Thanks! :tada:
❯ requiresafe check
Name  Installed           Patched  Location                                 Advisory Details
qs        0.5.6  >=1.0.0, >=1.0.0  grunt-contrib-watch > tiny-lr-fork > qs  https://portal.requiresafe.com/advisories/qs_dos_memory_exhaustion https://portal.requiresafe.com/advisories/qs_dos_extended_event_loop_blocking

Changes

deps: replaced tiny-lr-fork with tiny-lr which closes a security issue in qs

Updated PR, version is now at 0.6.1 again.

nsp cli is also reporting this qs security issue on 0.5.6.

Would love to see this added.

4b1801be531ffc15368b146a66cbcf1bc24c468f (Oct 07, 2014) already changed to<EMAIL_ADDRESS>But it was not released yet :(

@XhmikosR already in master


Package on NPM does not include window.d.ts

There is a reference to window.d.ts in the cs-interface.d.ts file, but the window.d.ts file is not included in the NPM package. In addition, the reference in cs-interface.d.ts points to ../src/window.d.ts instead of ./window.d.ts.
The missing reference is causing build errors for me.

This issue remains in the 0.5.1 release, presumably because the files section in package.json includes only lib: https://github.com/fusepilot/cep-interface/blob/master/package.json#L9-L11


cereal::binary_data() with lvalue

If you pass an lvalue pointer to a const type to cereal::binary_data() the code does not compile with:

include\cereal/details/helpers.hpp(217): error C2440: 'initializing': cannot convert from 'const int *' to 'void *'

Here is  a short code to reproduce the issue:
#include <fstream>

#include <cereal/cereal.hpp>
#include <cereal/archives/binary.hpp>

struct MyVector
{
public:
    const int* data() const { return data_; }
private:
    int data_[3];
};

template<typename Archive>
void save(Archive& ar, const MyVector& v)
{
    auto local_data = v.data();
    ar(cereal::binary_data(local_data, 3)); // fails
    //ar(cereal::binary_data(v.data(), 3)); // works
}

int main(int argc, char* argv[])
{
    std::ofstream file("test.dat", std::fstream::binary);

    cereal::BinaryOutputArchive archive(file);

    MyVector v;
    archive(v);
}

The reason for this is that cereal::binary_data() uses a "universal reference" as first parameter which is forwarded as const int*& in the example above which is afterwards not handled correctly in struct BinaryData

Good catch, I've merged your PR to develop.


Beep when done

Hi, I want to make voice control for build. I wrote something like this below, but it is not working.
Does anybody know how to fix it? :)
It throws this error - http://prntscr.com/6lxpzu
// Compile Sass, autoprefix properties, generate CSS.
gulp.task('sass', function () {
    return sass('src/sass/style.scss', {style: 'compressed'})
        .pipe(autoprefixer())
        .pipe(rename('style.css'))
        .pipe(gulp.dest('src/css/'))
        .pipe(gutil.beep()); // beep when build is done
});

Support questions are better asked on StackOverflow:
http://stackoverflow.com/questions/tagged/gulp
Paste in the link to the question here so others can follow ;)

My question on stackoverflow - http://stackoverflow.com/questions/29300726/gulp-beep-when-done


Generate Documentation

The Ooth public interface is slowly stable enough that it can be documented with jsdocs and a documentaion generated from it.

Done


Set server_hostname automatically when needed

create_connection requires either host or server_hostname if ssl is truthy. If sock is given, host gets unset, so provide server_hostname with the URI host if needed and not already provided by the caller.

Thank you. I added tests & docs for this.


Frappe command + bg colour contrast

Hey,
I have enabled the Frappe theme and I'm finding the contrast between the background and the main command text (highlighted in red) not quite enough for my eyes. I have tried to alter the theme file to change the colour of the command, but any colour I tried had no effect. Do you know which colour I need to change, or if I could override this to just make the blue text a little lighter?

Thanks!

Hmm.. it seems like fish is overriding the colours set by the theme here. I'm not really sure as to why this would happen as I'm not that well versed with fish, but I can't reproduce this issue on my end (using the stock fish experience).
Maybe some setting in your fish.config sets these colours separately?
I'll try to investigate further on my own as well.

Hmm.. it seems like fish is overriding the colours set by the theme here. I'm not really sure as to why this would happen as I'm not that well versed with fish, but I can't reproduce this issue on my end (using the stock fish experience). Maybe some setting in your fish.config sets these colours separately? I'll try to investigate further on my own as well.

If this is a fish issue, you can use catppuccin/fish.
Seen as how this is the setup I use and don't have any issues with the colour getting altered.

Ah.. great point! I totally forgot that we have a fish repo!

Adding the fish theme worked, thanks! I would guess that fish tries to come up with nice colours based on the terminal theme, or something? Who knows, but it looks much nicer now.


Filled out AR User model translations for en.yml

''sign_in_count' and last_sign_in_at' filled out for consistency.

Why? Where would this be used?

I've got a 'profile' page that lists out where/when the user logged in from last.
Oddly enough, I created two different branches (one for the Hebrew fix, one for this), and somehow they both got into the PR.  But then only the Hebrew fix got merged in.


Windows Requirements?

Trying to set up my CI on an nvim-oxi plugin, but linking fails: https://github.com/ModProg/config.nvim/actions/runs/3302333877
I see you have removed windows building from the CI in this repo. But do you know what the requirements for building for windows are?

I'm actually not sure what's the issue with building on Windows. I'm on macOS atm so I have no way to test it, if someone using Windows can chime in that'd be great.

IIRC this was solvable via downloading luajit libraries on windows and specifying the path to them. It is managed automatically on unix via pkg-config. Will try to solve this one soon.

wip

You might have noticed that PR is quite stale. I am having some health issues right now and I just can't get myself to coding at the moment. I will continue working on it once I'm good.

Hmm, the issue stil exists. Link error 1181

All is needed is to add this to your <project>/.cargo/config apparently
https://github.com/noib3/nvim-oxi/pull/85/commits/8cd705710b928efcdbd76362c0ee77fd0339780b

Closed by #149.


[scripts] fix openthread build

This commit fix openthread build that may cause test failures because cmake-build uses OT_COVERAGE=ON.

Codecov Report

Merging #122 (d6da76e) into master (5d4f76d) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #122      +/-   ##
==========================================
- Coverage   49.95%   49.91%   -0.05%
==========================================
  Files          38       38
  Lines        4604     4604
==========================================
- Hits         2300     2298       -2
- Misses       2122     2124       +2
  Partials      182      182

Impacted Files
Coverage Δ

web/web.go
47.61% <0.00%> (-3.18%)
:arrow_down:


version 0.1.2

@JuliaRegistrator register()
Release notes:
Minor changes

move the directory in which the default CCconfig.toml is downloaded from pwd() to homedir(), avoiding problems when Windows loads Julia REPL in C:\Windows\System32 directory.
if CCconfig.toml is not found in pwd(), try to find it at homedir() instead of /etc (non-portable)
silencing warnings for not-found processors and accelerators of instance types
create $HOME/.ssh directory if it does not exist;
check whether MW clusters are supported in deploying and inform the user;
EC2 image pointed at CCconfig.toml updated to Julia 1.11.2.

Registration pull request created: JuliaRegistries/General/121022
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.2 -m "<description of version>" 402a58c3472e98737472a7094b746cde179d6d57
git push origin v0.1.2


Cb1

fixed issues with a bagillion errors in the package-lock.json that wouldnt allow me to merge

merging branch with localhost now running effectively


Add workflow for building and pushing images

@ShyamsundarR @nirs This PR is ready for review now. I did a sample run in https://github.com/raghavendra-talur/recipe/actions/runs/8930166050/job/24529804328


DatetimePrompt NullReferenceException on a specific test case

Version
4.5.2
Describe the bug
If you use a simple date time prompt within your bot, when entering an invalid date value like 'hello', 'anything', the specified RetryPrompt message would be send back to you.
This is not the case for this specific test case: 2019-Aug-01 to today
In this case, the bot crashes with a NullReferenceException on line 109 in DatetimePrompt.cs:
var values = (List<Dictionary<string, string>>)results[0].Resolution["values"];
It seems there's an issue with the Datetime recognition because it expects the day of the month at first not the year (For example if you send 29-Aug-01 it would be resolved correctly to 2001-08-01).
To Reproduce
Steps to reproduce the behavior:

Build a bot with a simple DatetimePrompt.
Run the bot and send 2019-Aug-01 to today when asked to.

Expected behavior
For this specific test case it should be a valid date. If not, it should not crash but give the RetryPrompt message.
[bug]

I'm checking to see if I can reproduce. I'm with you; at the least it shouldn't crash.

Hi @ziad-akiki, I was able to reproduce the issue.
Looking at the behavior (I tested with a LUIS endpoint, using a datetimev2 entity as well as the Timex sample).
What is happening is that the recognizer is giving two results, one of which is a date, and the other is a date range.
"entities": [
{
  "entity": "from 2019-aug-01",
  "type": "builtin.datetimeV2.daterange",
  "startIndex": 28,
  "endIndex": 43
},
{
  "entity": "today",
  "type": "builtin.datetimeV2.date",
  "startIndex": 48,
  "endIndex": 52,
  "resolution": {
	"values": [
	  {
		"timex": "2019-10-01",
		"type": "date",
		"value": "2019-10-01"
	  }
	]
  }
}

But this does not have a valid resolution.
And to contrast, using an utterance like

August 1st 2019 to today

we get one result (as we would expect) with a valid range:
"entities": [
{
  "entity": "from august 1st 2019 to today",
  "type": "builtin.datetimeV2.daterange",
  "startIndex": 28,
  "endIndex": 56,
  "resolution": {
	"values": [
	  {
		"timex": "(2019-08-01,2019-10-01,P61D)",
		"type": "daterange",
		"start": "2019-08-01",
		"end": "2019-10-01"
	  }
	]
  }
}
]

For DateTimePrompt, we can address this with a bug here.
For the resolution aspect, please open a bug in the Recognizers-Text  reposiotry.

Hello @dmvtech, thank you. Please do proceed with opening a bug in Recognizers-Text. You may describe the problem and the reproduction steps there better than I would.

Will do

Fixed via https://github.com/microsoft/Recognizers-Text/pull/1897


add post_rotate_quaternion

Fix the "post_rotate_quaternion is not defined"

@Palmer-JC ok for you?

Yeah.  I see the method was there back on 8/5/2015.  Got somehow removed in one of my refactorings.


Recurring Task: Review, Fix and Track up/down votes feedback

We have voting buttons and freeform feedback fields on the docs site - and get a good amount of feedback from these.  We should on a regular basis review these and either fix or open tracking issues for top pieces of feedback.

As an aside, it would be good if we could somehow come up with a way to mark individual items in these dashboards as "addressed" somehow, or feed this data into some other medium that's a more amenable to this sort of periodic triage work. 🤔


UI: Use regular line-height on frontpage entries

This changes the paragraphs on frontpage to use the default line-heightof 1.4285em instead of 1em which looked cramped and unnatural to me.
Before

After

Codecov Report

Merging #6518 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6518      +/-   ##
==========================================
+ Coverage   40.26%   40.27%   +<.01%
==========================================
  Files         403      403
  Lines       54069    54069
==========================================
+ Hits        21770    21775       +5
+ Misses      29282    29277       -5
  Partials     3017     3017

Impacted Files
Coverage Δ

models/repo_list.go
67.89% <0%> (+1.05%)
:arrow_up:

modules/log/event.go
65.98% <0%> (+1.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Merged for v1.0.0

Merged for v1.0.0 🎉

I was just updating my version and got confused when it said v1.0.0. I caught it within a minute


parse error occurs in ON UPDATE CASCADE ON DELETE CASCADE

It's similar to #77 and #91. I've got parse error when there's both on update and delete like ON UPDATE CASCADE ON DELETE CASCADE.
old.sql
CREATE TABLE IF NOT EXISTS positions (
    positionId SMALLINT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    PRIMARY KEY (positionId)
);

CREATE TABLE IF NOT EXISTS users (
    userId CHAR(50) NOT NULL,
    name VARCHAR(50) CHARACTER SET utf8 NOT NULL,
    PRIMARY KEY (userId),
    CONSTRAINT users_ibfk_1 FOREIGN KEY(positionId) REFERENCES positions(positionId)
);

new.sql
CREATE TABLE IF NOT EXISTS positions (
    positionId SMALLINT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    PRIMARY KEY (positionId)
);

CREATE TABLE IF NOT EXISTS users (
    userId CHAR(50) NOT NULL,
    name VARCHAR(50) CHARACTER SET utf8 NOT NULL,
    PRIMARY KEY (userId),
    CONSTRAINT users_ibfk_1 FOREIGN KEY(positionId) REFERENCES positions(positionId) ON UPDATE CASCADE ON DELETE CASCADE
);

$ schemalex old.sql new.sql
: parse error: expected RPAREN or COMMA at line 11 column 103
    "positions(positionId) ON UPDATE CASCADE " <---- AROUND HERE

I confirmed it works there's only ON UPDATE CASCADE not ON DELETE CASCADE.

I found this issue is expected for this project.
https://github.com/schemalex/schemalex/blob/5105e4d60ee01062e413499ea502307d8d89ae4a/parser.go#L1241-L1242
https://github.com/schemalex/schemalex/blob/5105e4d60ee01062e413499ea502307d8d89ae4a/parser_test.go#L137-L140
It worked fine after I switched ON UPDATE and ON DELETE by following the test cases.


OperationType::RpcYang

Hi,
Would it be possible to add support for OperationType::RpcYang in the Context::parseOp()?
I just tried adding case OperationType::RpcYang: to the Context::parseOp and everything seems to work as it should, but I haven't tried to test it more.
Maybe also add RpcYang to DataNode::parseOp() for completeness, although I personally do not need this case.

just to clarify - it seems that you already wrote that code, so please push what you have. The instructions for Gerrit are in the README, if you hit a problem, feel free to drop me a line or ping me over slack.


T46 lazy bucket properties

Allows the deferral of the buck properties fetch from Riak until (if) it's required.

I think a test for the error condition would be handy, but apart from that, and the comment about superflous/exploratory test:- +1 to merge.
(What about if there is an error, resetting the future task so that you get another bit of the cherry?)

Alrighty, that should do it. If you could glance over this again real quick I'll merge it into master so we can then cut the 1.0.4 release

All good +1


How to create tabs programatically?

I want to use tabs on my application but I cannot figure out, how can I create tabs programatically.
I have a json containing an array of food categories and I want to create a tab for one food category. But in the official documentation, the tabs are added manually and I cannot figure out how can I give an array of data to the Tabs component and render tabs based on the number of elements in that index.

@LorandP This does not fulfil the issue guidelines
This is some sort of discussion, to be specific, may be as per your project requirement
You can put this on Stack Overflow


archive/zip: sporadic checksum errors on s390x target

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

$ go version
go version go1.17.11 linux/amd64

Does this issue reproduce with the latest release?
yes (1.18.3 linux/amd64)
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/runner/.cache/go-build"
GOENV="/home/runner/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd[6](https://github.com/byo/go-s390x-test/runs/7290379650?check_suite_focus=true#step:5:7)4"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/runner/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/runner/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/hostedtoolcache/go/1.1[7](https://github.com/byo/go-s390x-test/runs/7290379650?check_suite_focus=true#step:5:8).11/x64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/hostedtoolcache/go/1.17.11/x64/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.11"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build321[8](https://github.com/byo/go-s390x-test/runs/7290379650?check_suite_focus=true#step:5:9)18[9](https://github.com/byo/go-s390x-test/runs/7290379650?check_suite_focus=true#step:5:10)947=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Created a simple quine in go using statik to embed the source code. Statik uses internally zip compression.
Cross-compiled the binary for linux/s390x OS/ARCH and executed the binary on a linux/amd64 os using qemu-s390x.
What did you expect to see?
Binary running without errors printing its source code.
What did you see instead?
Once in a while the binary fails with the following error message:
error unzipping file "main.go": zip: checksum error

I've also caught different error (captured when using go 1.18) which may indicate that this is not strictly related to the archive/zip package:
runtime: asyncPreemptStack=336
fatal error: async stack too large

goroutine 1 [running, locked to thread]:
runtime.throw({0x19d5ae, 0x15})
        /usr/lib/go-1.18/src/runtime/panic.go:992 +0x70 fp=0xc00003c618 sp=0xc00003c5f0 pc=0x4aa70
runtime.init.4()
        /usr/lib/go-1.18/src/runtime/preempt.go:336 +0xf8 fp=0xc00003c640 sp=0xc00003c618 pc=0x4c068
runtime.doInit(0x283200)
        /usr/lib/go-1.18/src/runtime/proc.go:6222 +0x14a fp=0xc00003c780 sp=0xc00003c640 pc=0x5d24a
runtime.main()
        /usr/lib/go-1.18/src/runtime/proc.go:199 +0x126 fp=0xc00003c7d8 sp=0xc00003c780 pc=0x4d6a6
runtime.goexit()
        /usr/lib/go-1.18/src/runtime/asm_s390x.s:742 +0x2 fp=0xc00003c7d8 sp=0xc00003c7d8 pc=0x7e142

The frequency of the bug seems to be very random and vary between different environments (like ~10% chance on my laptop, 2% on Github actions runners).
A project that shows the issue: https://github.com/byo/go-s390x-test
Example GitHub actions run showing the failure: https://github.com/byo/go-s390x-test/runs/7290506324?check_suite_focus=true

CC @dsnet

Given that zip doesn't use any unsafe or goroutines, I'm having a hard time imagining what zip could be doing that is buggy on s390x but not other architectures.
The only thing I can imagine is that zip uses hash/crc32 which does have a s390x-specific implementation. In that case, the bug lies with hash/crc32 and not with zip.

I can now fully confirm this was indeed a qemu bug. The bogus behavior does not appear anymore with newest qemu version.
Sorry for false report.

Thanks for following up.


Use IPLD Dag instead of CoreAPI

The PR's main goal is to facilitate everything related to IPFS usage by:

Using IPLD Merkle DAG interfaces instead of CoreAPI.
Reworking Data retrieval logic to be based solely on IPLD Dag(optimization)
Use of Dag Sessions(optimization)

DAS timings before 2 above optimizations:
I[2021-05-23|23:12:11.531] Successfully finished DAS sampling           height=629 numSamples=15 elapsedtime=1.015415079s
I[2021-05-23|23:12:11.768] Starting Data Availability sampling          height=630 numSamples=15 squareWidth=16
I[2021-05-23|23:12:12.690] Successfully finished DAS sampling           height=630 numSamples=15 elapsedtime=921.977083ms
I[2021-05-23|23:12:13.060] Starting Data Availability sampling          height=631 numSamples=15 squareWidth=16
I[2021-05-23|23:12:14.801] Successfully finished DAS sampling           height=631 numSamples=15 elapsedtime=1.740647283s
I[2021-05-23|23:12:15.003] Starting Data Availability sampling          height=632 numSamples=15 squareWidth=16

DAS timings after optimizations:
I[2021-05-23|23:13:44.353] Successfully finished DAS sampling           height=648 numSamples=15 elapsedtime=239.112542ms
I[2021-05-23|23:13:44.485] Starting Data Availability sampling          height=649 numSamples=15 squareWidth=16
I[2021-05-23|23:13:44.719] Successfully finished DAS sampling           height=649 numSamples=15 elapsedtime=234.11647ms
I[2021-05-23|23:13:44.853] Starting Data Availability sampling          height=650 numSamples=15 squareWidth=16
I[2021-05-23|23:13:45.095] Successfully finished DAS sampling           height=650 numSamples=15 elapsedtime=242.104799ms
I[2021-05-23|23:13:45.227] Starting Data Availability sampling          height=651 numSamples=15 squareWidth=16

NOTE: Heights in the run with optimization was not DASed before, so light-client didn't have common data before.

Codecov Report

:exclamation: No coverage uploaded for pull request base (ismail/light-mvp@dbea20c). Click here to learn what that means.
The diff coverage is n/a.

@@                 Coverage Diff                 @@
##             ismail/light-mvp     #352   +/-   ##
===================================================
  Coverage                    ?   61.85%
===================================================
  Files                       ?      262
  Lines                       ?    22930
  Branches                    ?        0
===================================================
  Hits                        ?    14184
  Misses                      ?     7251
  Partials                    ?     1495

This looks good. I don't fully understand what makes the big difference in latency possible (yet). Will do a full review after https://github.com/lazyledger/lazyledger-core/pull/352#discussion_r637774071

@liamsi, @evan-forbes, I decided not to close this PR and instead extend it with the requested changes for CoreAPI removal

In follow-up PR I will go even further and will propose our custom interface for network DataAvailavility which works over DAG

race: limit on 8128 simultaneously alive goroutines is exceeded, dying
FAIL	github.com/lazyledger/lazyledger-core/p2p/ipld	16.744s

This is why the race detector hack was there btw.

@liamsi, I guessed that Mock IPFS will decrease the number of goroutines to remove the hack. WIll try something else to fix that

@liamsi, @evan-forbes, after looking deeply into the reasons why the issue above happens, I conclude that we have a goroutine leak that we should fix. With that hack, we just solely ignored the issue, so I don't think taking the hack back makes sense.

I would like to handle this myself as part of this PR, but I am really tired to do that today and it is midnight my time

we don't have to merge this tonight. I'll try limiting the goroutines with this PR and see what happens

Ok, but I already pushed temporary hack to unblock this

While it makes perfect sense to limit that number of go-routines spawned in that method, it's not a go-routine leak. Also note that the error only kicks in when the race-detector is active and the code works fine even with larger blocks without the race detector though.
I think, we can skip that test for now for larger blocks with a note that we should limit the number of go-routines spawned (I'll open an issue). If possible, let's merge this and handle the issue in a separate PR.

it's not a go-routine leak
That's true! Goruitne leak is when goroutine hangs out infinitely without returning, e.g. not calling cancel() for context will introduce one.

My original intuition was that spawning tonnes of routines are like leaking something. Obviously, it's wrong, affects performance, and should be avoided. Idk how to call that properly btw.


Emit dimensions in pixel in resize event

It's often useful to have the dimensions of the placeholder in resize event because it allows us to resize the content when the user is resizing an item in real-time.

Please update the event details in the README as well, thanks!

Ah, sorry for missing it. I updated the README file. I thank you for this great library. :)

Is it gonna be a release for this? Just as a reminder :)

Hey @gmsa, when can we merge this PR?

@gmsa thanks! Can we please release a minor version of this PR?

Thanks a lot!


Archive Android on VS2019

The menu item to "Archive" a android project is not visible anymore on VS2019. Within VS2017 there was no issue.

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

ID: f43472af-a9d3-8bef-0f24-b81f8f6cd2dd
Version Independent ID: 42cfbea5-0b4c-a0a3-4cce-1edf5523f605
Content: Preparing an Application for Release - Xamarin
Content Source: docs/android/deploy-test/release-prep/index.md
Product: xamarin
Technology: xamarin-android
GitHub Login: @conceptdev
Microsoft Alias: crdun

I have just confirmed the Archive menu item appears in Visual Studio 2019, see screenshots below:

Check your install includes the Xamarin Tools (Mobile Development with .NET), and if you continue to have issues use the report a problem feature in Visual Studio 2019.

@conceptdev Thanks for confirming that.
I have created a blank Xamarin Forms solution. Then I have compared both Android .csproj files and then I found that my file had a  <ProductVersion>8.0.30703</ProductVersion>  line inside. After removing this line the Archive button appears.

Glad you got it working - can I ask: was the "problem" project one created with Visual Studio on Windows or Mac, or was it one of our downloaded samples?

No, the project was created with VS2017 by using the Prism Template Pack.
I have tried to reproduce the issue with a new project created by the template pack but even though the ProductVersion line is present the archive button works.
But now everyting works.

Thanks for confirming.


[firebase_crashlytics] keys don't work

I tried fabric.io dashboard (an app with the Androidmanifest and such where crashes are reported) and I tried a firebase crashlytics bug
I tried keys regular places and, just in case, right before sent, string, boolean, int, etc
void main() {
  Crashlytics.instance.enableInDevMode = true;
  Crashlytics.instance.setUserIdentifier("pretend guid");

  // Pass all uncaught errors to Crashlytics.
  FlutterError.onError = (FlutterErrorDetails details) {
    Crashlytics.instance.setString("Key_within_on_error", "test535");
    Crashlytics.instance.onError(details);
  };
  runApp(MyApp());
}

Important note: Crashlytics.instance.log(message) does work and the logs do show up, and userid does work.

@neiljaywarner
The issue at https://github.com/flutter/flutter/issues/31371 has been closed and moved here. Future collaboration on this issue will be done here.

Based on https://github.com/flutter/flutter/issues/31371#issuecomment-538624962 I think it's safe to close the issue.

It is still a problem for me. I have this basic code that works as expected on android, but partially on ios.
On ios, crashes are reported without keys.
I am using the latest firebase_crashlytics version.
  Crashlytics.instance.enableInDevMode = true;
  Crashlytics.instance.setBool('testBool', true);
  Crashlytics.instance.setInt('testInt', 42);
  Crashlytics.instance.setString('testString', 'foobar');
  Crashlytics.instance.setDouble('testDouble', 42.123);
  try {
    throw new Exception("Just a test!");
  } catch (e, stacktrace) {
    print('logging crash to Crashlytics');
    Crashlytics.instance.recordError(e, stacktrace);
  }

@BondarenkoStas I also have a problem with keys on IOS (works fine on Android). The report appears in Crashlytics without keys. I'm using 0.1.2+2 version.
`
Future main() async {
Crashlytics.instance.enableInDevMode = true;
FlutterError.onError = (FlutterErrorDetails details) {
Crashlytics.instance.setString("clientId", "111111");
Crashlytics.instance.onError(details);
};
runZoned<Future>(() async {
runApp(MyApp());
}, onError: Crashlytics.instance.recordError);
}
`

(Re-)Apologize on my side, it appears that it is finally still not working fine on iOS and I was wrong in my last comment https://github.com/flutter/flutter/issues/31371#issuecomment-538624962.
So, to apologize, I've just corrected the bug and sent a PR (https://github.com/FirebaseExtended/flutterfire/pull/1782/)
You can already use it in your project by replacing in the file pubspec.yaml:
firebase_crashlytics: ^0.1.2+4
with
firebase_crashlytics:
    git:
      url: git://github.com/sperochon/flutterfire.git
      ref: firebase_crashlytics-sperochon-patch-ios-keys-1
      path: packages/firebase_crashlytics

I still have the same problem on firebase_crashlytics: ^0.1.2+5. Why is it not getting fixed? I have already reported this a couple of times and everytime someone says it's fixed. Do we even know why prevents it from working?

@BondarenkoStas I don't think it's a good idea to close this as me and some other users still experience this issue.

@behnamsattar The merge conflict is not the problem (not yet ;-)) since there was no conflict when I submit this PR. Even if I correct it, there will be a new conflict every new release... until a reviewer has some time to look at it.

Then I guess I need to bug @collinjackson and @kroikie :)

This issue should be reopened as this problem still exists!

Any update on this? Are you planning to take care of it anytime soon?

this root cause shall be at https://github.com/FirebaseExtended/flutterfire/blob/master/packages/firebase_crashlytics/darwin/Classes/FirebaseCrashlyticsPlugin.m#L56.
you will see the given value of setValue call is from call.arguments, which is wrong.
to whom having this issue, you can simply fork this repo and change the code as workaround to
if ([@"int" isEqualToString:key[@"type"]]) {
        [[Crashlytics sharedInstance] setIntValue:(int)key[@"value"]
                                           forKey:key[@"key"]];
      } else if ([@"double" isEqualToString:key[@"type"]]) {
        [[Crashlytics sharedInstance] setFloatValue:[key[@"value"] floatValue]
                                             forKey:key[@"key"]];
      } else if ([@"string" isEqualToString:key[@"type"]]) {
        [[Crashlytics sharedInstance] setObjectValue:key[@"value"]
                                              forKey:key[@"key"]];
      } else if ([@"boolean" isEqualToString:key[@"type"]]) {
        [[Crashlytics sharedInstance] setBoolValue:[key[@"value"] boolValue]
                                            forKey:key[@"key"]];
      }
    }

For me too setUserName doesn't seems to work, the username doesn't appears on the CrashLytics UI.
await Crashlytics.instance.setUserName(username);

I still don't understand why this PR is not getting reviewed and merged. This issue has been identified for more than a year (was on flutter repo before) and the fix was introduced in a PR about 5 months ago!

@behnam-lum
FlutterFire is currently getting a rework as per the roadmap
We're working through Crashlytics at the moment, where a number of these issues (including this one) have been resolved.  Keep an eye out on the roadmap for a release

A new Crashlytics plugin has now landed on master which should solve this issue.
Checkout the migration guide to get started on upgrading to the new Crashlytics plugin: https://firebase.flutter.dev/docs/migration/


fix: link to section

Description
fix: link to section prologue
cc. https://static.optimism.io/kona/fpp-dev/env.html#full-example

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.6%. Comparing base (e069eb4) to head (47d291b).

Additional details and impacted files

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


Add a wiki: Coral Island Wiki

Link to origin wiki: https://coralisland.fandom.com
Link to destination (independent) wiki: https://coralisland.wiki/wiki/Main_Page

Thanks for the submission! See this issue: https://github.com/KevinPayravi/indie-wiki-buddy/issues/385
The Fandom wiki currently has 2,634 articles, while the independent has 852. Independent one also seems to be unmonitored by active staff as it's been hit by spam articles for the last few weeks.


[SMALLFIX] Fix using object storage for UFS journal

In object stores, successful return from createFile() doesn't imply that exists() will return true, so we need to remove this precondition check.
Tested locally, before this change master can't start up with journal pointed to an S3 folder. After the change runTests passes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20298/Failed Tests: 0
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20304/
Test PASSed.


Question:  Is there documentation on the usage pattern for OkHttpClient?

I'm using OkHttpClient because RingCentral uses that inside their API.  I'm just trying to send and receive FAXes inside a Java enterprise application.
I'm able to use OkHttpClient, but it spawns threads that never die.  I read this issue and see that OkHttpClient spawns its own connection pool and other things.  I tried shutting it down using
 client.dispatcher().executorService().shutdown();
 client.connectionPool().evictAll();
 client.cache().close();

but that last call throws a NullPointerException.
Is there someplace that documents the expected usage pattern for OkHttpClient used inside an enterprise app?  Am I supposed to reuse one instance?  Is there a way to configure and manage the connection pool?

See this?
https://square.github.io/okhttp/3.x/okhttp/okhttp3/OkHttpClient.html

Yes, I saw that, but it doesn't address thread safety, connection management or now to avoid starting new threads.  In an enterprise app, there should be one instance of the connection pool and multiple, thread safe clients.  EJBs should not start new threads.  I don't see anything in the documentation about how to make that work.  Am I missing something?

Creating an OkHttpClient will create threads. Trying to think through how I can better document this without overwhelming.

I understand that creating an OkHttpClient starts threads.  EJBs are not supposed to start threads.
If OkHttpClient can't be used from EJBs, that's OK.  We can write our own REST code using the Apache HTTP client.  OkHttp is just what RingCentral uses in the JAR they provide to developers.

You can probably also find a way to create threads with your EJBs.

The Java Platform Enterprise Edition docs say not to create Thread objects from EJBs.  Managing concurrency inside an enterprise app is more complicated that starting a thread that never dies.

Yeah, those docs are advocating for patterns that make little sense in 2018. The motivation to avoid creating threads was so that an app container could unload an app. Today we solve such problems with load balancers and/or kubernetes.

So, to sum up:

OkHttpClient shouldn't be used in EJBs.  Neither should RingCentral's Java library, since it depends on OkHttpClient.
JPEE products should be abandoned/rewritten because 2018.

Gotcha.

Actually I think you should probably just start threads in your J2EE container and discover that . . . . it just works?

We will use an Apache HTTP client with a connection pool we can configure.  It doesn't start any threads, so there's no risk of threads accumulating as we redeploy apps or their plugin modules.  All the RingCentral library does is hide some REST interaction with their server.

Gotcha. OkHttp also creates threads for async calls, for write timeouts, and for HTTP/2. I assume Apache HTTP either doesn't have these features or somehow implements them without threads.
Doing fancy stuff requires threads; refusing them seems to me like an unnecessary constraint that may make your project worse.

Apache uses the java.util.concurrent package.  If you read the Oracle doc I linked, it explains why it's safe to use java,util.concurrent with JPEE.


Story Recursive Link

I have a situation where I want a user to be able to navigate through a sort of menu system. Like lets say a list of items, user is able to move forward to the next item,  backward to the previous item, and show info on the present item.
After the information is presented, user would be given the option (by utterance) to move forward / move backward and therefore show the same info on the newly selected item.
Think like the menu systems in some of the older C++ command-line executables.
+----+
|    |
|    V
|
|  Start
|    |
|    +--------+-----+--------+
|    |        |     |        |
|   Back     Fwd   Info     Exit
+----+        |     |        |
|             |     |        |
+-------------+     |        |
|                   |        |
+-------------------+        |
			     |
                             +-------> Something Else

So in the story definitions, whilst one story can link to another story, it cannot link to itself (UI prevents that). The scenario above would work perfectly if I could link one or more branches back to the same story, to start over.
To prevent circular loop, only one branch needs to not link at all, or at least link to some other story.
I had actually achieved this in stock-standard rasa via form action, but I think forms are not functioning with Botfront.

That's totally a valid use case. We'll look into it and if it plays well with rasa, we will add it to the app

Great, wonderful.

The modification has been merge.
Just a little detail, you need an "intro story" to enter the loop, e.g : the Get started story could link to the story with the self links
     |
Get started
     |
     |
+----+
|    |
|    V
|
|  Start
|    |
|    +--------+-----+--------+
|    |        |     |        |
|   Back     Fwd   Info     Exit
+----+        |     |        |
|             |     |        |
+-------------+     |        |
|                   |        |
+-------------------+        |
			     |
                             +-------> Something Else

Thanks very much.
Can someone point me in the right direction please. What is the procedure for re-building and installing from git repository, in preference to NPM?
NPM is at version 0.16.2, whereas, the git repository is more advanced, ~0.16.4 or thereabouts.
https://www.npmjs.com/package/botfront
In other words, with respect to the command npm install -g botfront, what achieves the equivalent outcome, yet sourced from git?

Hi !
The npm version is now at botfront 0.17 ! It includes the changes on story linking.
In the future If you want to build from the  repository, you can refer to the developer's guide
#Install : https://docs.botfront.io/developers-guide

Great thanks. Excellent.

Hi @GuillaumeTech
Can we add this to the documentation? .  With quick example.


[BUG] missing RenderWithMaskElementGroup

Describe the bug
I cloned the project into my Ubuntu and tried to compile and the result was an error because could not find RenderWithMaskElementGroup in the context.
To Reproduce
Expected behavior
Well ... be able to compile it
Screenshots

Desktop (please complete the following information):

OS: Ubuntu

Additional context

What's branch you using? Please give a try with 'dev' branch.
By the way there are some issues I do not fix and I have no plan about this library in the near future. If you just take a look at this library, it is no problem.
If you have any other problem with this library, issue is welcome.

I'm using the Master branch ... I will try the "dev" branch then ...
thank you very much for the work you have done and allow people to take a look and use it ...

I will continue to do this work next year. 😄

I still have some issues here ... I tried to open this on VS2022, and I get all these compilation errors:

I need help finding these interfaces in the solution...
In this class, he says he cannot find the CompileGenerator, but the project compiles with no problem.

Maybe this can help fo you to help me make this compile.

I use Source Generator in this project.

You should have .net 2.0 standard sdk in your environment.
The VS version should be higher or equal than 17.4 to compile it.


Added 4 devices

Added

MOES _TZ3000_w8jwkczz (3 Gangs wall remote)
MOES _TZ3000_xabckq1v (4 Gangs wall remote)
Added DIY smart switch _TZ3000_hktqahrq
Blitzwolf _TZ3000_eit7p838  TS0207 Water Leak

Hi, this looks good :) I will merge it once I have updated github with the changes I have made localy. Just have to clean up some code first :)
And yeah.. TS0001 can't possibly be anything else than a 1 gang unit... or Tuya would have totally destroyed their naming strategy ;) :)

yeah was my first though after PR why I added 2 gangs (because 2 switches) if TS0001 :-)
I noticed also a typo in waterleak I added blitwolf it work but it's labeled (when click on device in homey) as Alarm Contact instead of Alarm Water

may be just replace in capabilities
alarm_contact by alarm_water, that's what it's done in aquara xiaomi zigbee :-)

@JohanBendz ok, tested and fixed water leak sensor alarm

@hallard I will have to make some changes, when one wants to change a device from one capability to another one have to add the new capability and set the old one as deprecated, else the device will become broken for those that have it installed already. (contact to water)

@hallard I will have to make some changes, when one wants to change a device from one capability to another one have to add the new capability and set the old one as deprecated, else the device will become broken for those that have it installed already. (contact to water)

Correct, missed that old compatibility one.


[4.0] Sema: Track writes through WritableKeyPaths for mutation warnings.

Explanation: We would erroneously flag a var as not being mutated if the only mutations were through WritableKeyPaths.
Scope: Annoying hard-to-dismiss warning incorrectly raised when using keypaths in common idioms
Issue: Fixes SR-5214 | rdar://problem/32599483
Risk: Low, small bug fix to a QoI diagnostic
Testing: CI, test case from Jira

@swift-ci Please test

@DougGregor Does this look good for 4.0?


Add RabbitMessageChannelBinder#connectionFactory getter

@tzolov commented on Tue Mar 29 2022
The RabbitMessageChannelBinder has an opinionated view about the connectionFactory lifecycle.
For some use-cases a user might want to reset the connection; let's say the primary broker failed and we switched automatically to a secondary broker; later, when the primary broker is available, the user might want to (manually) switch back by resetting the connection to the secondary broker. (Kudos to @garyrussell)

It appears to be duplicate and is resolved so I'll close it


Several inhancements, including Added option to create or publish to organizations.

Hi there. Thanks for making the extension. It will be very helpful for our organization.
I made some changes that I hope you like. See my summary below.

Added option to create or publish to organizations.
Added Connect and Sign Up buttons to ConnectSectionView.xaml and now leaving visible.
Removed password from .Gitea file and pull it from the Credential Manager.
Now storing last path cloned to in the .Gitea file.
Some bug fixes.

Great job.


Error with :help page

After a clan install, when you request for :help page you have the following error:
ERROR:__main__:Exception on /:help [GET]
Traceback (most recent call last):
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/srv/webservices/wttr/wttr.in/bin/srv.py", line 240, in wttr
    return render_template( 'index.html', body=help_ )
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/templating.py", line 128, in render_template
    context, ctx.app)
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/flask/templating.py", line 110, in _render
    rv = template.render(context)
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/jinja2/environment.py", line 989, in render
    return self.environment.handle_exception(exc_info, True)
  File "/srv/webservices/wttr/venv/lib/python2.7/site-packages/jinja2/environment.py", line 754, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/srv/webservices/wttr/home/share/templates/index.html", line 7, in top-level template code
    {{ body }}
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 230: ordinal not in range(128)

It's not (yet) complete synchronized with the code on the server. There is an issue about it.
Do you want to install it locally?

@chubin Yes, I have a small own local server


Windows Server 2019 Support

This page hasn't been updated in a couple of years.  Commentary related to support for Windows Server 2019 should be included.

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

ID: d92acad0-13e9-f009-eff1-a89fad7a08b7
Version Independent ID: 462590b7-1d83-0e32-63d4-79a4726023d0
Content: Using Azure AD Connect Health with AD DS
Content Source: articles/active-directory/hybrid/how-to-connect-health-adds.md
Service: active-directory
GitHub Login: @zhiweiwangmsft
Microsoft Alias: billmath

@dustindortch
Thanks for your feedback! We will investigate and update as appropriate.

I am assigning this to the content author to investigate. @zhiweiwangmsft

GitHub user zhiweiwangmsft has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

Checking with engineering to make sure ADDS for 2019 is now supported with Azure AD Connect Health.

Yes, 2019 is supported.  Thanks!
#please-close


🎉 Docusaurus OpenAPI Docs Showcase!

First of all, thanks for your continued support of the docusaurus-openapi-docs plugin! As mentioned in #464, the community wants to see how you've leveraged it on your site.
Drop a link or two here so the community can show some love. I'll go first:
Docusaurus OpenAPI Docs Demos
https://docusaurus-openapi.tryingpan.dev/category/petstore-api
Palo Alto Networks Developer Docs
https://pan.dev

Resoto Docs API Reference
https://resoto.com/docs/reference/api

Defined Networking API
https://docs.defined.net/api/defined-networking-api/

https://docs.ideal-postcodes.co.uk/docs/api

Unleash's docs

https://docs.sideshift.ai/

https://docs.fuse.io/api-introduction/

https://docs.openremote.io/

https://developers.maxar.com/


Java-based components dependency versions auto-advancing

What is the feature request? What problem does it solve?
Java-based components dependency versions auto-advancing that is compliant to our current python components release, and also effortless to continuously support. The current Dependabot approach performs constant background automated monitoring for release, that needs to be manually supervised for merging in addition by someone explicitly dedicated. It generates one noisy contributors experience towards new PRs activity notifications also.
Suggested solution
We may consider the python components compliant approach, like for example
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
And there is the Gradle way:
https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies
The result is, the release cadence will match the functional changes made, and the PR author will happen to merge transparently with their change, or create a ticket and pin to last version in case needed. Oppositely to a
Additional context

Triaged. Closed as stale.