K8SPG-75 Add users pass handling

This PR add possibility to manage system users passwords via k8s secret. Draft because e2e-test not ready yet.

Test name
Status

demand-backup
passed

scheduled-backup
passed

init-deploy
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

data-migration-gcs
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/fda8dce9867844e656c35acabf9cd340fdee9218
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-fda8dce9-pgo-deployer

Test name
Status

init-deploy
failed

scaling
failed

recreate
failed

affinity
failed

monitoring
failed

self-healing
failed

operator-self-healing
failed

clone-cluster
failed

tls-check
failed

upgrade
passed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/87c36681e8bc276c4d9f58bf5792461fb02bf72b
image: perconalab/percona-postgresql-operator:PR-146-87c36681-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-87c36681-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-87c36681-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-87c36681-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-87c36681-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-87c36681-pgo-deployer

Test name
Status

demand-backup
passed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

scheduled-backup
passed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/6a673aef147dfbe59cee18402b84d0cf36503104
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-6a673aef-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

scheduled-backup
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/a801eaf62403920d715a79466d369289e7ee812d
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-a801eaf6-pgo-deployer

Test name
Status

demand-backup
passed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

scheduled-backup
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/0ad14b7f1c2cc837914914116dc3ec177514d8a8
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-0ad14b7f-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

scheduled-backup
failed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/95f3fb6bef1ead16a9b0ba4a04bccb61b81a6e7e
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-deployer

Test name
Status

demand-backup
passed

scheduled-backup
passed

init-deploy
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
passed

upgrade
passed

users
passed

data-migration-gcs
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/95f3fb6bef1ead16a9b0ba4a04bccb61b81a6e7e
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-95f3fb6b-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

scheduled-backup
passed

clone-cluster
passed

tls-check
failed

upgrade
failed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/1af1a590d4fd5c99ddea64ac34ae83b4022883f5
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-1af1a590-pgo-deployer

Test name
Status

demand-backup
failed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

scheduled-backup
failed

recreate
passed

affinity
failed

monitoring
passed

self-healing
failed

operator-self-healing
failed

clone-cluster
failed

tls-check
failed

upgrade
failed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/ec860939dc0df377e20135e1b6122a93726568fd
image: perconalab/percona-postgresql-operator:PR-146-ec860939-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-ec860939-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-ec860939-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-ec860939-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-ec860939-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-ec860939-pgo-deployer

Test name
Status

demand-backup
failed

init-deploy
failed

data-migration-gcs
failed

scaling
failed

scheduled-backup
failed

recreate
failed

affinity
failed

monitoring
failed

self-healing
failed

operator-self-healing
failed

clone-cluster
failed

tls-check
failed

upgrade
failed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/853173b721a031e237210d1a8d366c96934cc1d0
image: perconalab/percona-postgresql-operator:PR-146-853173b7-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-853173b7-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-853173b7-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-853173b7-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-853173b7-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-853173b7-pgo-deployer

Test name
Status

demand-backup
failed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

scheduled-backup
passed

tls-check
failed

upgrade
failed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/37eecd082e3b831db9f2f580d4146314c33f2db5
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
failed

data-migration-gcs
passed

upgrade
failed

users
failed

scheduled-backup
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/37eecd082e3b831db9f2f580d4146314c33f2db5
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-37eecd08-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

scheduled-backup
failed

clone-cluster
passed

tls-check
failed

upgrade
failed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/c4b57c4e95e9ebf29f484686978e61281a4bd3df
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-c4b57c4e-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

scheduled-backup
failed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
failed

upgrade
failed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/b28be406d7ac58c7d916e8dedf10c0f14c32188c
image: perconalab/percona-postgresql-operator:PR-146-b28be406-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-b28be406-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-b28be406-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-b28be406-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-b28be406-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-b28be406-pgo-deployer

Test name
Status

demand-backup
passed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
failed

upgrade
failed

users
passed

scheduled-backup
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/27b39207f29bb3429f1fa52f11ac72410c86e096
image: perconalab/percona-postgresql-operator:PR-146-27b39207-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-27b39207-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-27b39207-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-27b39207-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-27b39207-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-27b39207-pgo-deployer

Test name
Status

demand-backup
failed

init-deploy
failed

data-migration-gcs
passed

scaling
failed

scheduled-backup
failed

recreate
failed

affinity
failed

monitoring
failed

self-healing
failed

operator-self-healing
failed

clone-cluster
failed

tls-check
failed

upgrade
failed

users
failed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/e9c0d3d7ead791f687352d23f882e6a769723dfc
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-deployer

Test name
Status

init-deploy
passed

demand-backup
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
failed

tls-check
failed

upgrade
failed

scheduled-backup
failed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/e9c0d3d7ead791f687352d23f882e6a769723dfc
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-e9c0d3d7-pgo-deployer

Test name
Status

demand-backup
passed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

scheduled-backup
passed

affinity
passed

monitoring
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
failed

tls-check
passed

upgrade
failed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/5b56f485fa2367fbdee19e59d9c51d7210a59c97
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-5b56f485-pgo-deployer

Test name
Status

demand-backup
passed

init-deploy
passed

data-migration-gcs
passed

scaling
passed

recreate
passed

affinity
passed

monitoring
passed

scheduled-backup
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
failed

tls-check
passed

upgrade
passed

users
passed

commit: https://github.com/percona/percona-postgresql-operator/pull/146/commits/0176b7096932401d0e81dc5752e7572f3113b6fb
image: perconalab/percona-postgresql-operator:PR-146-0176b709-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-146-0176b709-pgo-event
image: perconalab/percona-postgresql-operator:PR-146-0176b709-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-146-0176b709-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-146-0176b709-postgres-operator
image: perconalab/percona-postgresql-operator:PR-146-0176b709-pgo-deployer


Removed package version

Context

Fix issues when packages are removed from repos causing missing versions #382

Choices

Most packages we're installing are fairly stable so there's not much reason to force a version.

Test instructions

Test that is build

Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I've added documentation about this change to the README.
[x] I've not introduced breaking changes.

Do not agree, let's just change the package versions to the ones that are available. Not pinning the versions introduces more variables into why the server could not work

Do not agree, let's just change the package versions to the ones that are available. Not pinning the versions introduces more variables into why the server could not work

Might run into issues later on then with the ARM image if the repos don't have matching versions.


New fixture - Cameo-LED-Moving-Head-60W-CLMHRGB60W

Original post:
http://www.qlcplus.org/forum/viewtopic.php?f=3&t=8971
Datasheet:
http://www.thomann.de/gb/cameo_moving_head_60.htm

Yes it would :)
When the 4.10.0 storm has passed, I could dedicate some time to various pending things

The catalogue (pdf page 5): http://www.cameolight.com/startseite/?force_sid=l0jhu2d9cqktljdpjuem0980e2 shows the same image. However, there are no matching gobos in the library anyway.

OK, I've had a look and actually we don't have similar matches.
Then there is no solution other than:

leaving them blank
ask Cameo to officially provide their gobos. If you want I can send them an email and see if they reply

For now I would go for the first option

You do first. I can do second option???
Sent from my Samsung device
-------- Original message --------
From: Massimo Callegari<EMAIL_ADDRESS>Date: 29/09/2015  17:34  (GMT+00:00)
To: mcallegari/qlcplus<EMAIL_ADDRESS>Cc: boxy321<EMAIL_ADDRESS>Subject: Re: [qlcplus] New fixture - Cameo-LED-Moving-Head-60W-CLMHRGB60W
(#580)
OK, I've had a look and actually we don't have similar matches.
Then there is no solution other than:
leaving them blank
ask Cameo to officially provide their gobos. If you want I can send them an email and see if they reply
For now I would go for the first option
—
Reply to this email directly or view it on GitHub.

Let's see if tasaei replies in the forum.
Otherwise leave this to me and I'll sort it out.

👍
Sent from my Samsung device
-------- Original message --------
From: Massimo Callegari<EMAIL_ADDRESS>Date: 29/09/2015  19:19  (GMT+00:00)
To: mcallegari/qlcplus<EMAIL_ADDRESS>Cc: boxy321<EMAIL_ADDRESS>Subject: Re: [qlcplus] New fixture - Cameo-LED-Moving-Head-60W-CLMHRGB60W
(#580)
Let's see if tasaei replies in the forum.
Otherwise leave this to me and I'll sort it out.
—
Reply to this email directly or view it on GitHub.


Fix ssh setup

Create ~/.ssh and set perms before creating ~/.ssh/environments.

@colinPL ACK

@colinPL ACK

ok to test

:red_circle: Test failed.
Refer to this link for build results: http://jenkins-beaker.delivery.puppetlabs.net/job/Beaker Combined Smoketest/385/

retest this please

:red_circle: Test failed.
Refer to this link for build results: http://jenkins-beaker.delivery.puppetlabs.net/job/Beaker Combined Smoketest/389/

retest this please

:red_circle: Test failed.
Refer to this link for build results: http://jenkins-beaker.delivery.puppetlabs.net/job/Beaker Combined Smoketest/392/

Failures unrelated to patch.


Avoid prefixing public data members

As discussed in the alpaka VC today, this PR changes the .clang-tidy file to not rewrite public non-static data members of classes to include an m_ prefix.

Vote until 22.06.2021:

type
yes
no (keep old)

public data member
1
0

type
yes
no (keep old)

public data member
2
0

type
yes
no (keep old)

public data member
3
0

type
yes
no (keep old)

public data member
4
0

type
yes
no (keep old)
comment

public data member
5
0
unfortunately, now it is inconsistent again, but I don't see a better solution and better than prefix public members and let the rest wild

type
yes
no (keep old)
comment

public data member
6
0
why only non-static? imo all public members feel awkward with m_


LUIS tutorial needs an update

The interface of cognitive services (especially LUIS) has changed.
Starting from step 6 in the Exercise 3 (Add pre-built entities and phrase lists), it is not possible to add parameters to an Intent.

Closing out old feedback. Jeff and the team tries to keep labs as up-to-date as possible. I believe the LUIS lab has been updated since May, but if it's still an issue, let us know! Azure changes so fast, we appreciate the heads up when things need fixed 👍


configure higher ceph client version

As the old 10.2.3 had been removed from cloud archive repo, we use higher 10.2.6 instead.

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

retest


WIP: implement try_except decorator to ignore items/lines that raise

I just wanted you to know that I am trying to implement that.
There are no tests and no documentation, yet. I am not yet sure, that my approach is good. If you see that this is the wrong direction please let me know.

@edk0 It seems you forgot to add lenses.py:
ImportError while importing test module '/home/ganwell/git/spy/tests/test_decorators.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_decorators.py:2: in <module>
    import lenses
E   ModuleNotFoundError: No module named 'lenses'

Thanks!
That's pretty much the way I was going to go, yeah, modulo style things. I'm not sure about returning None though. I feel like it should either return spy.DROP or a (somehow) settable default. Or maybe the exception itself?

It seems that simple. The project is very nicely structured. I usually check the validity of the testcase, maybe you don't want that or you want it as an extra test. Do you need a cli/integration test?

Coverage increased (+0.0003%) to 99.924% when pulling 299dae4ec4c0630f51a3a5eb650b7ccf3b9b3ff2 on ganwell:d/try into 6ccc3c934723370b8837a9053bf028dcecaf9054 on edk0:master.


Feature/favorite quotes

Codecov Report

Merging #299 (2771d62) into develop (e0aaeb1) will increase coverage by 0.10%.
The diff coverage is 95.55%.

@@             Coverage Diff             @@
##           develop     #299      +/-   ##
===========================================
+ Coverage    98.67%   98.78%   +0.10%
===========================================
  Files           65       62       -3
  Lines         2873     2874       +1
===========================================
+ Hits          2835     2839       +4
+ Misses          38       35       -3

Impacted Files
Coverage Δ

app/main.py
92.45% <86.66%> (-0.41%)
:arrow_down:

app/database/models.py
96.77% <100.00%> (+0.10%)
:arrow_up:

app/internal/daily_quotes.py
100.00% <100.00%> (ø)

app/routers/register.py
100.00% <0.00%> (ø)

app/routers/salary/config.py
100.00% <0.00%> (ø)

app/internal/security/ouath2.py
98.14% <0.00%> (ø)

app/routers/credits.py

app/routers/about_us.py

app/utils/extending_openapi.py

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 e0aaeb1...076ab07. Read the comment docs.


Image Index/Manifestlist is defect if referenced package version is deleted

Description
Hello,
when a package version is deleted, which is referenced by an OCI Image Index (or ManifestList for docker), the image can no longer be fetched by Image Index, if the deleted tag is needed or used.
Create an Image Index:
root@dev # docker pull amd64/alpine
    Using default tag: latest
    latest: Pulling from amd64/alpine
    c158987b0551: Pull complete
    Digest: sha256:c0d488a800e4127c334ad20d61d7bc21b4097540327217dfab52262adc02380c
    Status: Downloaded newer image for amd64/alpine:latest
    docker.io/amd64/alpine:latest
root@dev # docker pull arm64v8/alpine
    Using default tag: latest
    latest: Pulling from arm64v8/alpine
    261da4162673: Pull complete
    Digest: sha256:af06af3514c44a964d3b905b498cf6493db8f1cde7c10e078213a89c87308ba0
    Status: Downloaded newer image for arm64v8/alpine:latest
    docker.io/arm64v8/alpine:latest
root@dev ~ # docker tag arm64v8/alpine gitea-test/test-user/alpine:latest-arm64v8
root@dev ~ # docker tag amd64/alpine gitea-test/test-user/alpine:latest-amd64
root@dev ~ # docker push gitea-test/test-user/alpine:latest-arm64v8
    The push refers to repository [gitea-test/test-user/alpine]
    1b577a8fb8ce: Pushed
    latest-arm64v8: digest: sha256:af06af3514c44a964d3b905b498cf6493db8f1cde7c10e078213a89c87308ba0 size: 528
root@dev ~ # docker push gitea-test/test-user/alpine:latest-amd64
    The push refers to repository [gitea-test/test-user/alpine]
    ded7a220bb05: Pushed
    latest-amd64: digest: sha256:c0d488a800e4127c334ad20d61d7bc21b4097540327217dfab52262adc02380c size: 528
root@dev ~ # docker manifest create gitea-test/test-user/alpine gitea-test/test-user/alpine:latest-amd64 -a gitea-test/test-user/alpine:latest-arm64v8
    Created manifest list gitea-test/test-user/alpine:latest
root@dev ~ # docker manifest push gitea-test/test-user/alpine
    sha256:4a5b8d1fa34a84569d302ab7bddd9c37bad546ee2be6a94d244d8bebb19ded3a

Now delete the container image with version "latest-amd64" via the web interface.
Try to pull the image on an amd64 architecture:
root@dev ~ # docker pull gitea-test/test-user/alpine
latest: Pulling from test-user/alpine
manifest unknown

Before running the package prune, the files are still present:
/data # find packages -type f -exec file {} \;
packages/c1/58/c158987b05517b6f2c5913f3acef1f2182a32345a304fe357e3ace5fadcad715: gzip compressed data, original size modulo 2^32 7337984
packages/49/17/49176f190c7e9cdb51ac85ab6c6d5e4512352218190cd69b08e6fd803ffbf3da: JSON data
packages/4a/5b/4a5b8d1fa34a84569d302ab7bddd9c37bad546ee2be6a94d244d8bebb19ded3a: JSON data
packages/af/06/af06af3514c44a964d3b905b498cf6493db8f1cde7c10e078213a89c87308ba0: JSON data
packages/c0/d4/c0d488a800e4127c334ad20d61d7bc21b4097540327217dfab52262adc02380c: JSON data
packages/26/1d/261da4162673b93e5c0e7700a3718d40bcc086dbf24b1ec9b54bca0b82300626: gzip compressed data, original size modulo 2^32 7745536
packages/d3/15/d3156fec8bcbc7b491a4edc271a7734dcfa186fc73282d4e120eeaaf2ce95c43: JSON data

After the prune they are gone:
/data # find packages -type f -exec file {} \;
packages/4a/5b/4a5b8d1fa34a84569d302ab7bddd9c37bad546ee2be6a94d244d8bebb19ded3a: JSON data
packages/af/06/af06af3514c44a964d3b905b498cf6493db8f1cde7c10e078213a89c87308ba0: JSON data
packages/26/1d/261da4162673b93e5c0e7700a3718d40bcc086dbf24b1ec9b54bca0b82300626: gzip compressed data, original size modulo 2^32 7745536
packages/d3/15/d3156fec8bcbc7b491a4edc271a7734dcfa186fc73282d4e120eeaaf2ce95c43: JSON data

With the docker-registry container the images can still be pulled via the ManifestList, but not via the deleted tag.
In my opinion when deleting the tag, the Image Index should still work. There should at least be a warning if an Image Index references the tag.
With regards
Joniw
Gitea Version
1.17.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Linux
How are you running Gitea?
Test instance in Kubernetes
Database
SQLite

I don't think this is a bug. If you delete something from the web UI you are outside the specific package registry spec and you need to know what you are doing. For this reason most package managers simply disallow deleting of packages. Gitlab for example allows to delete individual files which is even more harmful if you don't take care. The deletion page already warns you about your action.

I agree that this is not necessarily a bug.
On the other side the ImageList references manifests which contain the digests of the packages. Should this not count as a reference?

The deletion of a package version via the UI is a dumb operation. (Currently) the package type and possible implications are not checked. We can leave this issue open but for me, this feature/enhancement has no priority beause the deletion of a package is "unsupported". Lots of package registries simply disallow deletions because other entities may depend on that package and so on.

Hello,
i hoped for a quick fix to reference the ids of the ImageList. If this is not possible, it is OK for me to leave this open as an low priority feature request.
It could even be closed if this behaviour is intended.
With regards
Joniw


Failed setup 400 Bad Request

Version of the custom_component
latest of everything: MM, MM HA integration 1.5.0b5, latest fork of MMM-Remote Control MM module from sindrebroch, HA Core
2024.8.1, Supervisor 2024.08.0, Operating System 13.0
Describe the bug
Since yesterday the integration won't connect to my MM anymore:
Failed setup, will retry: Response not 200 OK <ClientResponse(http://xxxxxxxxxxx:8080/api/brightness) [400 Bad Request]> <CIMultiDictProxy('Access-Control-Allow-Origin': '*', 'Referrer-Policy': 'no-referrer', 'Strict-Transport-Security': 'max-age=15552000; includeSubDomains', 'X-Content-Type-Options': 'nosniff', 'X-DNS-Prefetch-Control': 'off', 'X-Download-Options': 'noopen', 'X-Frame-Options': 'SAMEORIGIN', 'X-Permitted-Cross-Domain-Policies': 'none', 'X-XSS-Protection': '0', 'Content-Type': 'application/json; charset=utf-8', 'Content-Length': '166', 'Etag': 'W/"a6-7TFy9clM9rwQNiht2z4gvOP9Avg"', 'Date': 'Thu, 15 Aug 2024 11:35:57 GMT', 'Connection': 'keep-alive', 'Keep-Alive': 'timeout=5')>
Before it was working. I did not do any changes or updates to MM, HA, modules or integration. Only update I did was HA Operating System from 12.x to 13.0. That coincided with the integration stopping to work. However no idea if the HA Operating system has any impact on the integration, I honestly doubt it.
The usual things like rebooting MM, the MM pi, restarting HA etc. does not help
Interestingly I noticed a while ago that I could not turn the screen on and off via the integration anymore (I opened a separate issue for that a while back). It is interesting as the log mentions the brightness which is part of the monitor entitiy where already the turn on/off was not working, though up to now the brightness slider was working fine. My guess is somehow that is the culprit.
Also important info: The MM itself is up and running and I can access it via the MMM-RemoteControl web interface (outside of home assistant) just fine. So it does not seem to be the module but the HA integration somehow.
Debug log

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 354, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/magicmirror/coordinator.py", line 64, in _async_update_data
    brightness: QueryResponse = await self.api.get_brightness()
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/magicmirror/api.py", line 212, in get_brightness
    return QueryResponse.from_dict(await self.get(API_BRIGHTNESS))
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/magicmirror/api.py", line 108, in get
    return await self.handle_request(get)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/magicmirror/api.py", line 85, in handle_request
    raise Exception(f"Response not 200 OK {resp}")
Exception: Response not 200 OK <ClientResponse(http://xxxxxxxxx:8080/api/brightness) [400 Bad Request]>
<CIMultiDictProxy('Access-Control-Allow-Origin': '*', 'Referrer-Policy': 'no-referrer', 'Strict-Transport-Security': 'max-age=15552000; includeSubDomains', 'X-Content-Type-Options': 'nosniff', 'X-DNS-Prefetch-Control': 'off', 'X-Download-Options': 'noopen', 'X-Frame-Options': 'SAMEORIGIN', 'X-Permitted-Cross-Domain-Policies': 'none', 'X-XSS-Protection': '0', 'Content-Type': 'application/json; charset=utf-8', 'Content-Length': '166', 'Etag': 'W/"a6-7TFy9clM9rwQNiht2z4gvOP9Avg"', 'Date': 'Thu, 15 Aug 2024 11:07:25 GMT', 'Connection': 'keep-alive', 'Keep-Alive': 'timeout=5')>

@sindrebroch  any news?? It is very annoying not being able to control the MM anymore and throws my automations out of wack. Please check the issue. Thanks!

Ok I solved this one by completely deleting the integration and setting it up again.
Yet many other issues persist


fix compass params

due to this additional check.
https://github.com/cohere-ai/cohere-toolkit/pull/602/files#diff-e938e72c3385f521a0f58fc519c9a42068c09e391d3c473f374ed00793a392c3R239-R241

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

Project coverage is 74.99%. Comparing base (e82d73f) to head (8819c01).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #716   +/-   ##
=======================================
  Coverage   74.99%   74.99%
=======================================
  Files         261      261
  Lines       11489    11489
=======================================
  Hits         8616     8616
  Misses       2873     2873

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


Fix execute './gradlew spotlessApply' Command

close #10
Issue
Current ProcessCameraProviderModule broke ktlint rule standard:filename. It is easy to fix to change name of file ProcessCameraProviderModule to CameraProviderBindingModule. So I changed name of file.

ktlint suggestion is clear:
File 'ProcessCameraProviderModule.kt' contains a single class and possibly also extension functions for that class and should be named same after that class 'CameraProviderBindingModule.kt'

and @l2hyunwoo fix is spot on. Tested on latest main d0301a24.


chmod +x gradlew

How on earth Github was able to build without perms, I'll never know

actually actually did it every time it built


Chrome browser libpepflashplayer.so fails to load

I downloaded both the master src and the 0.3.6 release src and built (both produce same results), copied the libfreshwrapper-flashplayer.so to ~/.mozilla/plugins, created ~/.config/freshwrapper.conf and set the path to Chrome pepper flash (which by defaults includes the manifest.json with the version), and loaded Firefox. Firefox sees the fresh wrapper flash player plugin, but when I go to http://www.adobe.com/software/flash/about/ I see the error that libpepflashplayer.so failed to load. The path supplied in the conf file is correct and Chrome uses the same flash just fine. chmod 755 doesn't help... any options?

Hi.
Just to be sure, are you using full path to the libpepflashplayer.so, including file name?
Also, try to run ldd -r -d libpepflashplayer.so in a terminal emulator in the directory where libpepflashplayer.so is located. This command tries to load a library and shows what functions (-r) and exported data (-d) are missing. Something like "not found" or "not defined" in its output means there is something wrong with libraries versions.

ldd for libpepflashplayer.so
	linux-vdso.so.1 (0x00007fffafff3000) 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f6a618ed000) 	librt.so.1 => /lib64/librt.so.1 (0x00007f6a616e5000) 	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f6a6135c000) 	libm.so.6 => /lib64/libm.so.6 (0x00007f6a61053000) 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6a60e3c000) 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6a60c1f000) 	libc.so.6 => /lib64/libc.so.6 (0x00007f6a6085d000) 	/lib64/ld-linux-x86-64.so.2 (0x0000559d4dba2000)
ldd for libfreshwrapper-freshplayer
	linux-vdso.so.1 (0x00007ffd9c1ed000) 	libasound.so.2 => /lib64/libasound.so.2 (0x00007f4126e14000) 	libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f4126a8e000) 	libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f4126883000) 	libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f4126679000) 	libX11.so.6 => /lib64/libX11.so.6 (0x00007f4126338000) 	libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f412612d000) 	libGL.so.1 => /usr/lib64/libglvnd/libGL.so.1 (0x00007f4125ea1000) 	libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f4125c8f000) 	libevent_pthreads-2.0.so.5 => /lib64/libevent_pthreads-2.0.so.5 (0x00007f4125a8c000) 	libevent-2.0.so.5 => /lib64/libevent-2.0.so.5 (0x00007f4125843000) 	libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f4125635000) 	libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f412530c000) 	libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f41250f7000) 	libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f4124eab000) 	libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f4124c59000) 	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f412494b000) 	libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f4124707000) 	libfreetype.so.6 => /usr/lib64/freetype-freeworld/libfreetype.so.6 (0x00007f4124458000) 	libssl.so.10 => /lib64/libssl.so.10 (0x00007f41241e6000) 	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f4123d84000) 	libicuuc.so.56 => /lib64/libicuuc.so.56 (0x00007f41239ec000) 	libicudata.so.56 => /lib64/libicudata.so.56 (0x00007f4122007000) 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f4121e02000) 	librt.so.1 => /lib64/librt.so.1 (0x00007f4121bfa000) 	libpulse.so.0 => /lib64/libpulse.so.0 (0x00007f41219aa000) 	libavcodec.so.57 => /lib64/libavcodec.so.57 (0x00007f41205fc000) 	libavutil.so.55 => /lib64/libavutil.so.55 (0x00007f4120382000) 	libva-x11.so.1 => /lib64/libva-x11.so.1 (0x00007f412017c000) 	libva.so.1 => /lib64/libva.so.1 (0x00007f411ff5b000) 	libvdpau.so.1 => /lib64/libvdpau.so.1 (0x00007f411fd57000) 	libv4l2.so.0 => /lib64/libv4l2.so.0 (0x00007f411fb49000) 	libm.so.6 => /lib64/libm.so.6 (0x00007f411f83f000) 	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f411f4b7000) 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f411f2a0000) 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f411f083000) 	libc.so.6 => /lib64/libc.so.6 (0x00007f411ecc1000) 	/lib64/ld-linux-x86-64.so.2 (0x0000556fce120000) 	libffi.so.6 => /lib64/libffi.so.6 (0x00007f411eab9000) 	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f411e8b4000) 	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f411e641000) 	libz.so.1 => /lib64/libz.so.1 (0x00007f411e42b000) 	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f411e203000) 	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f411dfe9000) 	libXext.so.6 => /lib64/libXext.so.6 (0x00007f411ddd7000) 	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f411dbb4000) 	libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f411d9ae000) 	libGLX.so.0 => /usr/lib64/libglvnd/libGLX.so.0 (0x00007f411d77d000) 	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f411d4c6000) 	libthai.so.0 => /lib64/libthai.so.0 (0x00007f411d2bd000) 	libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f411d0bb000) 	libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f411ce3a000) 	libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f411cb91000) 	libEGL.so.1 => /usr/lib64/libglvnd/libEGL.so.1 (0x00007f411c97e000) 	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f411c74a000) 	libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f411c546000) 	libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f411c33c000) 	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f411c10f000) 	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f411beff000) 	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f411bcb1000) 	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f411b9cb000) 	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f411b7c7000) 	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f411b595000) 	libpulsecommon-8.0.so => /usr/lib64/pulseaudio/libpulsecommon-8.0.so (0x00007f411b317000) 	libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f411b114000) 	libICE.so.6 => /lib64/libICE.so.6 (0x00007f411aef8000) 	libSM.so.6 => /lib64/libSM.so.6 (0x00007f411acf0000) 	libXtst.so.6 => /lib64/libXtst.so.6 (0x00007f411aae9000) 	libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f411aa5f000) 	libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f411a854000) 	libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f411a648000) 	libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007f411a3da000) 	libasyncns.so.0 => /lib64/libasyncns.so.0 (0x00007f411a1d4000) 	libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f4119f83000) 	libcap.so.2 => /lib64/libcap.so.2 (0x00007f4119d7e000) 	libswresample.so.2 => /lib64/libswresample.so.2 (0x00007f4119b62000) 	libva-drm.so.1 => /lib64/libva-drm.so.1 (0x00007f411995e000) 	libxvidcore.so.4 => /lib64/libxvidcore.so.4 (0x00007f411964d000) 	libx265.so.79 => /lib64/libx265.so.79 (0x00007f41190fa000) 	libx264.so.148 => /lib64/libx264.so.148 (0x00007f4118d9b000) 	libvpx.so.3 => /lib64/libvpx.so.3 (0x00007f4118a24000) 	libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007f411877b000) 	libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007f411854e000) 	libtheoraenc.so.1 => /lib64/libtheoraenc.so.1 (0x00007f411830d000) 	libtheoradec.so.1 => /lib64/libtheoradec.so.1 (0x00007f41180f2000) 	libspeex.so.1 => /lib64/libspeex.so.1 (0x00007f4117ed8000) 	libschroedinger-1.0.so.0 => /lib64/libschroedinger-1.0.so.0 (0x00007f4117bf5000) 	libopus.so.0 => /lib64/libopus.so.0 (0x00007f41179a4000) 	libopenjp2.so.7 => /lib64/libopenjp2.so.7 (0x00007f411776d000) 	libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007f41174f6000) 	libmfx.so.0 => /lib64/libmfx.so.0 (0x00007f41172e2000) 	libgsm.so.1 => /lib64/libgsm.so.1 (0x00007f41170d5000) 	libOpenCL.so.1 => /lib64/libOpenCL.so.1 (0x00007f4116eb6000) 	libv4lconvert.so.0 => /lib64/libv4lconvert.so.0 (0x00007f4116c3b000) 	libXau.so.6 => /lib64/libXau.so.6 (0x00007f4116a37000) 	libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f411682e000) 	libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f4116602000) 	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f41163f2000) 	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f41161ee000) 	libbsd.so.0 => /lib64/libbsd.so.0 (0x00007f4115fd8000) 	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4115dd3000) 	libXi.so.6 => /lib64/libXi.so.6 (0x00007f4115bc3000) 	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f411599c000) 	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f4115788000) 	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f41154a2000) 	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f411528d000) 	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f4115074000) 	libFLAC.so.8 => /lib64/libFLAC.so.8 (0x00007f4114e1a000) 	libogg.so.0 => /lib64/libogg.so.0 (0x00007f4114c12000) 	libattr.so.1 => /lib64/libattr.so.1 (0x00007f4114a0d000) 	libsoxr.so.0 => /lib64/libsoxr.so.0 (0x00007f41147aa000) 	liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007f411452c000) 	libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f41142c2000) 	libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f4114093000)

Were those ldd with -r and -d flags? I've seen something like that with PepperFlash from ChromeOS on an older Linux distribution. ChromeOS had newer libc, and PepperFlash depended on newer symbol versions.
By the way, what distribution are you using? What PepperFlash version? Where did you get it?
Some distributions have SELinux policies enabled by default, which can prevent applications from loading libraries from a user's directories.

I have just tested out flash from ChromeOS recovery image with freshplayer. I have a few odd observations which may help.
Since it is a bit confusing, In the following I will call pepper flash that comes with Chrome browser on  Linux (without DRM support) pepper-flash for Linux and the pepper-flash extracted from ChromeOS recovery image ChromeOS flash.

in order for Adobe to pick up ChromeOS flash, it seems that first one must have a  copy of pepper-flash for Linux installed in the system (say by installing Chrome). Then run Firefox once BEFORE editing  freshwrapper.conf to change pepperflash_path to point to ChromeOS flash. Firefox Tools > Addons > Plugins shows flash version to be 26 (version of flash for Linux)

Now close Firefox, edit freshwrapper.conf to change pepperflash_path to point to ChromeOS's libpepflashplayer.so (maybe somewhere in $HOME). Start Firefox, go to Tools > Addons > Plugins. Note that It still shows version 26.
Now go to
http://www.adobe.com/software/flash/about/
and flash is detected and reported as version 25 (version of ChromeOS flash) The message asks you to update flash, just ignore it.  Go to
http://drmtest2.adobe.com:8080/SVP/SampleVideoPlayer_FP.html
to do the DRM test, it works. Right click to check flash version, it is reported as 25

If the system does not have pepper flash for Linux already installed (more about NPAPI flash  later), or if one instalsl freshplayerplugin, then edits freshwrapper.conf  and starts Firefox without running it once with pepperflash_path pointing to a copy of pepper-flash for Linux. Firefox > Tools > Addons > Plugins would show flash version  to be <IP_ADDRESS>, <IP_ADDRESS>. or some such nonsense. Flash still works for some sites (right click video and flash version is reported as 25 on such sites) but adobe's site does not pick it up.
Go to http://www.adobe.com/software/flash/about/  it will tell you to install flash. Likewise the drm testing viewer doesn't open because flash is not present.

On Ubuntu 16.04, if I compile freshplayer from source, then NPAPI flash must not be installed, otherwise Firefox would just use it, and there is no DRM support.

However, if I install freshplayer from webupd8's ppa, then NPAPI flash (adobe-flashplugin) is installed as dependencies and in that case ChromeOS's flash does load correctly. I suppose the webupd8 maintainer must have changed something.

Hello and thanks for this wonderful workaround to still use flash.
Instead of flash animations i get a brown yellow placeholder with failed to load error message. Used Version: 3.0.9. Flash works ok in chrome. freshplayer plugin shows in Firefox plugins.
Full path is set in freshwrapper.conf. Also tried putting libfreshwrapper-flashplayer.so in path /usr/lib/pepperflashplugin-nonfree like mentioned in README.MD.
The ldd -r -d for libpepflashplayer.so and libfreshwrapper-player.so gave no errors.
I'm pretty sure it can find libpepflashplayer.so
Has something fundamentally changed in flash, that the wrapper
doesn't work anymore?

Hmm. PepperFlash still works on my machine. I tested only with Flash from Chrome, but haven't tried Flash from ChromeOS yet.
Have you tried to remove path from freshwrapper.conf? Have you tried the latest freshplayerplugin source? I haven't touched sources for a bit, so forgot what was implemented when. But the latest version seems to be working.

Thanks for your reply.
Without the path it still the same problem. In The default freshwrapper.sh
there if a path, but is commented out.
I use version 3.0.9 downloaded from freshplayerplugin page here on github rigHt now.
Before a fedOra 28 package also freshplayer 3.0.9 with same problem.
Is there a newer one?

Is there a newer one?

There is, from this repository. However I just checked and found no essential changes from 0.3.9 there.
Let's try to figure out which libpepflashplayer.so is loaded. Start Firefox under strace from terminal emulator. You'll need to close Firefox before that, to ensure that whole Firefox runs under strace and not only that part that activates already running copy:
strace -f -e openat,lstat -o log firefox

Navigate to any page with Flash, try to load it. You need to see that placeholder message to ensure that FreshPlayerPlugin is started. Then close Firefox. Search for libpepflashplayer in log file:
grep libpepflashplayer log

There should be list of paths that are tried.


Is it possible to make some improvement

Hello!
There is well known lib to show tables in console: "inspect"
It's very cool because you can pass custom handling function for changing each table in tree, as option.
Let's say, that table has other table, and other table has that first table, it's normal situation when using moonscript's class. Than you got stack overflow on json encoding. In my classes there is method called "as_json" (inspired by Ruby on Rails), wich can throw out all unnecessary from class or instance. Would be great, if libjson could check if table has such option, call it if has and only then do it's work. Or accept function as "inspect", which will check for "as_json" property.
It is not an issue, just wanted option.
But stack overflow is issue, right?

I suppose you can create stack overflows with circular tables. Yes, we could have this option, would you like to make a pull request, and if so, please make it optional and not the default.

I will try!


Sidechain Fork Mitigation (Epic)

This epic emerged from #345 - summarizes the results of those discussions and anchors all the tasks created from it.
Specification
Fork detection

Each validateer should detect forks, even within a parentchain block cycle
Parentchain block determines finalized sidechain blocks and thus the branch that is valid

Needs to be checked at each parentchain block import

When a fork is detected, a validateer remains on its current branch until finalization by the parentchain

This is the 'laziest' approach, minimizes effort (e.g. a 'random' scheme could mean to roll-back and switch branch, but still be wrong in the end)
Alternatives: Random choice of branch, stop production, choose the longest branch

Finality

Parentchain finalizes sidechain blocks
Extrinsic must be extended to include the sidechain block header, not just the block hash

Header contains hash of block payload and hash of parent block

Parentchain determines order of sidechain block

Simple queue, builds order of sidechain blocks - eagerly where possible
Queue size in the order of #sidechain blocks per parentchain block ~40

Logic must be built into the pallet

Execution of logic should be O(1) whenever possible
Optimize for 'write' or mutation

Roll-back

Store snapshot of state after each block

Need some bookkeeping to easily map a block hash to a snapshot
Apply specific snapshot on roll-back

Transactions are marked 'InBlock' and only removed once finalized

For roll-back, see how Substrate does it: Either move 'InBlock' transactions back to 'Ready' or remove entirely from pool

Also linked to #855 for sidechain finality


createLoadBalancerRule does not allow for tcp and udp

ISSUE TYPE

Bug Report

COMPONENT NAME

createLoadBalancerRule API, UI

CLOUDSTACK VERSION

4.14

CONFIGURATION

Advanced Networking, VPC, Loadbalancer
OS / ENVIRONMENT

Ubuntu 16.04
SUMMARY
LoadBalancerRule API does not allow for tcp and udp to be selected as protocol. When a rule is created for a port choosing tcp as protocol, an additional rule cannot be created for udp and a error message stating conflicting rule is thrown.
STEPS TO REPRODUCE

with cloudmonkey:

createLoadBalancerRule algorithm=source name=test privateport=800 publicport=800 networkid=299aace4-a5c5-46f4-9ae7-92c86ded0cea publicipid=2c49bd00-cd6b-44d4-93a5-7082ead298e0 protocol=udp

createLoadBalancerRule algorithm=source name=test privateport=800 publicport=800 networkid=299aace4-a5c5-46f4-9ae7-92c86ded0cea publicipid=2c49bd00-cd6b-44d4-93a5-7082ead298e0 protocol=tcp
throws error message
The range specified, 800-800, conflicts with rule 4214 which has 800-800

EXPECTED RESULTS

either tcp/udp as a selection or being able to create a rule for each
ACTUAL RESULTS

The range specified, 800-800, conflicts with rule 4214 which has 800-800

as discussed with @nlindblo on list at users@ [1] this is different as expected or as portforwarding works, while portforwarding is really not more than loadbalancing over a single backend. I can live with calling this a bug or a feature but really think it should be working as the user asks. It cuts across the whole system right into the VR hence I mark it as major but the solution might be just in the VR scripts or even just in the DAO?!?
[1] https://lists.apache.org/thread.html/rd0e615913601cbdae59d04e32907e1e4b8c995222a31d214ab0fe201%40<users.cloudstack.apache.org>

Since CloudStack uses haproxy as a loadbalancer which doesn't support UDP, it would be a good idea to remove the option from the UI as well as have checks in the backend
https://github.com/haproxy/haproxy/issues/62

Disabled UDP via https://github.com/apache/cloudstack/pull/4501 && https://github.com/apache/cloudstack-primate/pull/871

@nlindblo since HAproxy which is internally used for load balancing does not support udp, an appropriate check has been added. There will only be a conflict in case of tcp rules on the same port.

@nlindblo per this fix, this is now going to be a feature request (if you still want it) I'm closing this. you can reopen, use an alternative to the internal lb or enter a new feature request (which will probably require atr least some functional research and spec effort)


Use more accessible visual elements instead of buttons

This PR intends to close #226, and is currently a work in progress. I shall update the description soon once I have the buttons working the same as they are outside this PR.

Thanks for working on this !


chore: update di dependency

Codecov Report

Merging #51 (a04af78) into main (b9afb91) will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
- Coverage   97.46%   97.37%   -0.09%
==========================================
  Files         181      181
  Lines        5716     5711       -5
  Branches      675      674       -1
==========================================
- Hits         5571     5561      -10
- Misses         98      103       +5
  Partials       47       47

Impacted Files
Coverage Δ

xpresso/dependencies/models.py
100.00% <ø> (ø)

tests/test_docs/advanced/test_websockets.py
92.00% <0.00%> (-8.00%)
:arrow_down:

xpresso/binders/_body/extractors/discriminated.py
70.73% <0.00%> (-2.44%)
:arrow_down:

xpresso/binders/_body/extractors/file.py
96.00% <0.00%> (-2.00%)
:arrow_down:

xpresso/binders/_body/extractors/form.py
95.71% <0.00%> (-1.43%)
:arrow_down:

Codecov Report

Merging #51 (3a9d7b4) into main (b9afb91) will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
- Coverage   97.46%   97.37%   -0.09%
==========================================
  Files         181      181
  Lines        5716     5711       -5
  Branches      675      674       -1
==========================================
- Hits         5571     5561      -10
- Misses         98      103       +5
  Partials       47       47

Impacted Files
Coverage Δ

xpresso/dependencies/models.py
100.00% <ø> (ø)

tests/test_docs/advanced/test_websockets.py
92.00% <0.00%> (-8.00%)
:arrow_down:

xpresso/binders/_body/extractors/discriminated.py
70.73% <0.00%> (-2.44%)
:arrow_down:

xpresso/binders/_body/extractors/file.py
96.00% <0.00%> (-2.00%)
:arrow_down:

xpresso/binders/_body/extractors/form.py
95.71% <0.00%> (-1.43%)
:arrow_down:


rethink how nodes are initialized vs started

Right now initializing nodes is done during the same step than starting them. This leads to problems when trying to bring up complex topologies where we need to start nodes roughly at the same time (ie, within seconds of each other) to avoid triggering catchup.
Specifically, local_process:setup performs a few expensive operations, such as database initialization and history archive initialization.
That code is called by process:run:
    def run
      raise Process::AlreadyRunning, "already running!" if running?
      raise Process::Crash, "process #{name} has crashed. cannot run process again" if crashed?

      setup ##### <<< This is the expensive call
      launch_process
      @launched = true

      wait_for_http
      set_upgrades
    end

The solution is probably to decouple those two steps by:

adding a new boolean field "initialized" (making setup noop if it was already run)
changing commander:start_all_processes to first loop and initialize nodes before calling p.run
there might be a need for forcing setup to do its work (or a way to clear the initialized bool), looking at how process is used, it doesn't seem to be the case though

there might be a need for forcing setup to do its work

We'll add a new method named setup!

adding a new boolean field "initialized" (making setup noop if it was already run)

Let's call it @is_setup to tie it to the setup method and to avoid attachment with the ruby keyword initialize(a constructor)

Other than that, I'm fine with this approach.  It shouldn't compromise horizon's use of scc


An error with map erase that BugTrap seems cannot capture?

`#include <Windows.h>
#include "BugTrap\BugTrap.h"
#include
#pragma comment(lib, "BugTrap\BugTrapU.lib")  // Link to Unicode DLL
void SetupExceptionHandler();
int main()
{
SetupExceptionHandler();
BT_SetTerminate();
std::map<int, int> idMap;
idMap[0] = 1;

idMap.erase(idMap.begin());
idMap.erase(idMap.begin()); // BugTrap cannot capture this exception with my pc and environment
//int* ptr = 0; *ptr = 0; // BugTrap can capture this exception

return 0;

}
void SetupExceptionHandler()
{
BT_InstallSehFilter();
BT_SetFlags(BTF_DETAILEDMODE | BTF_EDITMAIL);
}`

It's not a bug, it's an OS feature :)
Heap exceptions treated as critical errors(that causes process termination) and handled by the kernel itself and didn't dispatched to the user mode.
Such behaviour can't be fixed without dirty, OS specific hacks.


Update frontpage documentation

Nowhere is it specified that Python needs to be installed on the system, or that the process must now be launched with retdec-decompiler.py FILENAME

Hi! Which RetDec release do you use? The retdec-decompiler.py script does no longer exist, which is why it is not mentioned in the README (this is what I believe you have meant by frontpage documentation).

Anyway, here is a README for the latest release: v4.0.

I have created a ticket for re-considering the purpose of the main README: #860. One option is to make it up-to-date with the current release (it is currently up-to-date with master, which is where the development happens). Another option is to mention that it concerns the current master and provide links to READMEs corresponding to releases.
I am closing this ticket. If you have any remarks, feel free to mention them in #860.


Feature Request: Save Theme Songs to Jellyfins Metadata Folder not in Media Folder

Hi,
i using latest stable JellyFin Version on my Synology NAS DS920+ with DSM 7.2
Is it possible to make a new Setting to the Theme Song Plugin to save the Theme Songs not automaticly in the Media Folder, instead in the Metadata Folder of JellyFin itself ?
In my case the Media Folder is always Write Protected and only the Admin can access it with Read/Write Permissions so it would be very nice to save this to Metadata Folder.
Here in my case JellyFin has this Folder:
/volume1/@appdata/jellyfin/data/metadata
In this Folder there are anyway Read/Write Permissions
Big Thanks, Keep the good work up.

Is it just a case of using serie.InternalMetadataPath rather than serie.Path to use the metadata folder rather than the media folder for those?

After a bit of lookup, storing the theme in metadata is trivial (change I suggested) though Jellyfin itself doesn't support themes coming from the metadata folder structure:
https://features.jellyfin.org/posts/1870/store-theme-songs-in-the-metadata-folder-instead-of-the-series-folders


Non-identifier operators

I've talked about this before but I couldn't find an existing issue about it.
Swift requires operators to consist of non-alphanumeric characters, so they aren't valid identifiers. This allows custom operators like infix operator .* for dot multiplication, postfix operator %/postfix operator ° for unit conversion, and more. I've occasionally wanted this myself in Civet code, such as × for Cartesian product or ∘ for function composition.
Given the limitations of JavaScript, this would necessarily involve name mangling. As long as the mangling is consistent and depends only on the source symbol, though, this shouldn't be a problem and should even allow for importing/exporting such operators. (One such operation could be replacing illegal characters with something of the form _uXXXX, like △ becoming _u25B3.)

Somewhat related is operator overloading: https://github.com/DanielXMoore/Civet/discussions/1081
(This used to be an issue but moved to a discussion.)
Related to name mangling is #555's mention of the idea to allow emoji in all Civet identifiers. If we extended this to mathematical operators and much of Unicode space, this would let a user immediately define a lot of custom operators (including e.g. ° and △) using the existing operator functionality.
I think we could extend Civet to allow defining new ASCII operators (that don't conflict with existing operators). Something like:
operator (.*) (a, b)  // inner product
  a.x * b.x + a.y * b.y

We'd need to define a set of ASCII letters that we'd like to allow in such binary operators, then (similar to how custom operators work today) check for them and see if they're defined.
I think we could even allow overriding built-in binary operators, at least to a limited extent, if we checked for this first in the grammar. This would be nice for when we inevitably add more binary operators to Civet.
I see you've also maybe suggested custom prefix and postfix operators. That's in principle doable too...

We'd need to define a set of ASCII letters that we'd like to allow in such binary operators, then (similar to how custom operators work today) check for them and see if they're defined.

Swift's set is ./=-+!*%<>&|^?~, for the record.

Oops, this is #1034


Earthsci preprint matching.2023 nov02

I think it comes down to deciding whether to have the parser doing system-level logic, or whether the parser acts based upon what the controlling code tells it to do.  In this case, the pathnames are definite only at this moment in time, but we're in a transition period where the underlying system architecture or flow control may change.  If we use a calling option like what I've implemented to specify that logic, we're not reliant on the current architecture, and that would be my preference.

I'm pretty sure we had this conversation a few months back and from my perspective nothing has changed, so let me restate what I think we should do:

Unify the format for the input list of records to be matched -- right now for arXiv we read the source DC XML but there is no reason why we could not use the classic metadata files, which have the same format for both eprint and published records. If we do that, we have a single read function that at some point can be swapped out in the future with a read from a database. The input in all cases can simply be the full path of the metadata files.
Implement trivial logic that decides whether the input metadata is for an eprint or not -- right now this is a 2-line function simply checking the bibstem (extracted from the bibcode) and not the pathname, but to further future-proof this for the day when the bibcode/bibstem may not be there we would have a metadata field provide the same information from our ingest data model
There is no 3: if the input is an eprint call the match_to_published function, and vice-versa

If I missed/misunderstood something let's have a chat.

@aaccomazzi
I did not know that the classic format can correctly read arXiv metadata. Then we should remove the arXiv parser and use the classic reader for all input files this way there is no need to identify what kind the input metadata file is. That should solve the issue. Thank you.
@seasidesparrow

@seasidesparrow
I have time today, I can verify that classic parser can read the arXiv file and extract all the information that arXiv parser extracts. Let me know if you want me to do that.

I would need to make some changes to the classic side to have it output paths to the .abs files instead of to the xml files and test it, so this isn't something I would want to deploy before next Tuesday at the earliest.

@seasidesparrow
Let me check it out. I shall let you know what I found out.

@seasidesparrow
I went ahead implemented this and made a release, if you would please check it out.
https://github.com/adsabs/ADSDocMatchPipeline/releases/tag/v3.1.4
Now you can include earth science records among the arXiv records and submit them to pipeline to get matched with publication. Or included them among the pub records and submit them to get matched with arXiv records. You can also submit them separately, for example if earth science records come as eprints during the weekend, you can create eprint.input list and process them then, the same if they come in as pub records at any time, you can create pub.input and process them at once. Very flexible. Please let me know if there is any issue. thank you.
@aaccomazzi

Closed: superseded


Upgrade Yeoman to 4.0 + minor updates

Not sure it will be easy to run generator-jhipster@6 with yo@4.

Not sure it will be easy to run generator-jhipster@6 with yo@4.

I did it on my local, It gave me same error :)


Test restructuring

This PR makes two orthogonal changes to how tests are run and structured.

All test files included in runtests.jl are made into modules, and imports are moved into those modules. runtests.jl now has minimal imports. This cleans up the namespaces in which the individual tests are run, and makes it clearer where various references in tests point to.
Test files can now be included selectively using keyword arguments. If one runs e.g. Pkg.test("Turing", test_args=["optim", "hmc", "--skip", "ext", "nelder"]) then only test files that have the substring "optim" or "hmc" in their path will be run, unless they also have one of the substrings "ext" or "nelder" in their path, in which case they are skipped. By default all tests are run. Substring comparisons are case-insensitive.

Point 2. makes the @turing_testset and @numerical_testset macros unnecessary, and they will be removed.
The selective running of tests is useful for both local development and splitting our CI to run tests for various parts of the Turing.jl in parallel (#2179). I'll try implementing the latter next to see that it goes smoothly.
This is an early draft, I'm opening it to get comments (@yebai, @torfjelde). I've only converted a couple of files to the submodule format, and the selective running lacks documentation. If this is deemed a good design I'll go and finish the implementation.

For the record, optimally I would have liked the selective test running to be based on testset names rather than file paths. I tried a couple of designs for that, but ran into various limitations and complexities in how AbstractTestSet and nesting macros work. This could be revisited later.

I finished the restructuring described in the opening message. I also removed the code coverage part of CI, because it seems to have been broken for the last > 1 year. If we want to reintroduce it I would propose running it as a separate job outside the current test matrix, since it requires running all the tests in one go and only on a single platform.
More work could be done harmonising the way we do imports and qualified references, but I think that could be a separate PR. In this one I avoided touching anything in the actual test code, and only modifying the "header" of each file.
The longest test CI job now takes around 25 minutes, so more could perhaps be done to make tests faster. Either making them more lightweight or splitting some of the heavy test files into several files.

Thanks for the comment @devmotion, happy to discuss this. Here are reasons why I went with ARGS rather than env vars, not in any particular order:

I wanted to have the option to include and exclude multiple test files. This requires some parsing of the input, and doing that for command line arguments is more natural and more standard practice than for env vars, which are usually single values.
Pkg.test has features explicitly for this, which I think is a strong hint that this can be considered the standard way of doing test selection in Julia. Pkg.test docs mention exactly this as an intended use case of test_args.
I find command line arguments handier when running things manually: I'm more used to passing things args than setting env vars when I run things from a terminal. For CI I think both work equally well.

It's also the approach taken throughout the SciML ecosystem and in e.g. Bijectors, DynamicPPL, and DistributionsAD.

That's a fair point that I hadn't considered. At the same time, the ARGS approach is what Julia itself does (I took the name of --skip from the tests of stdlib).

it's much easier to use ENV variables for test GROUPs (similar to what @willtebbutt uses in Tapir it seems) since this does (almost) not require any additional code

I would argue that using ARGS does not require any more extra code in runtests.jl. The only reason why there's any substantial extra code here (still <30 lines + docstrings) is because of parsing of include/exclude tests, which I would like to have regardless of whether we use env vars or ARGS.

you can just update the ENV variable in the julia REPL and (re)run ] test

You can have a similar user experience with ARGS, by doing ARGS .= ["my", "new", "--skip", "args"]; ] test.

I can see these points and I'm sure tests could be structured with ARGS as well - but I think it would be good to follow common practices in the ecosystem and use environment variables.
IMO one of the main problems with the current Turing test setup is that it does not follow common practices in the ecosystem and defines its own macros for structuring the tests. My impression is that this makes it unnecessarily complicated for new contributors to read, modify, and add tests and adds additional maintenance burden on our side. My worry is that with an uncommon practice such as ARGS (I haven't encountered a single Julia package yet that uses it to structure tests) we will still make it more complicated than necessary for new contributors (and the custom parsing requires additional maintenance on our side).

I'm still not convinced (but also don't care too much if everyone else has a different opinion) - I think it's good to adopt improvements even if they are not common practice yet, but I don't see why/how ARGS is superior than ENV and therefore I would go with the more established and more well-known approach.

I don't really have anything to add to my earlier comments on command line arguments vs env vars, except that I don't think the args setup would get in the way when adding/modifying existing tests. By default it runs all tests, and there's no manual grouping of tests so you can add new ones even if you're oblivious that there even is a way to run tests selectively. I appreciate that consistency with related packages has value though. I'm happy to say it's Hong's call, but that's probably because he seems to prefer what I prefer. :)
Regardless of the final design, I'll add a note in the contributing docs page on how to run the tests once this has been merged.
In other news, I took all the files in test/test_utils and either made them into modules that are now imported with relative imports, or, in cases where only one test file was using the utils, merged them into the test file. I also deleted a bunch of code from the utils that wasn't being used anywhere.
There's also test/skipped which is about 900 lines of code not included in runtests.jl. Might these tests be brought back at some point, or are they run manually in some particular situations?

@yebai should this not be a patch version bump? It looks non-breaking

One suggestion for CI setup is that failures of particular CI tasks should not cancel other CI tasks so we can independently identify multiple CI failures in parallel.

Good point, should now be fixed.
Assuming CI passes (the previous error was random, see #2234), I have no other changes in mind that I would like to make. I also don't have merge rights, so someone else needs to make the call on when this is final.

In other words, what would be the env var equivalent of doing Pkg.test("Turing", test_args=["optim", "hmc", "--skip", "ext", "nelder"])?

This is a really good argument :+1: You could of course implement the same parsing of an ENV variable, but I very much agree that it's much, much more natural to do so using ARGS.

Respecting Pkg.test's intended way for selecting tests to run.

I that the the docs mention that this is a use-case for args, but does it specifically recommend that over ENV variables?
I'm am genuinely quite keen on giving this pattern a go, but I'm also somewhat worried about doing this in Turing.jl :confused:
Has there been a similar discussion elsewhere? I.e. what's the reasoning of the rest of the ecosystem going with ENV variables?

This is a really good argument 👍 You could of course implement the same parsing of an ENV variable, but I very much agree that it's much, much more natural to do so using ARGS.

Yeah, I think parsing complicated env vars gets awkward. You could define two env vars though, INCLUDE_TESTS and EXCLUDE_TESTS, both of which could be space separated lists. I don't know if that would satisfy the desire of consistency with SciML practices any more though.

I that the the docs mention that this is a use-case for args, but does it specifically recommend that over ENV variables?

No, I don't think it says anything about environment variables.

The test failures seem unrelated to this PR. They seem to rather be about the recent ADTypes compat change interacting in funky ways with Optimization.jl version bounds when using Julia 1.7. I haven't gotten to the bottom of it yet.

In other words, what would be the env var equivalent of doing

Probably something similar to JULIA_LOADPATH etc. where a single environment variable is split into a vector of paths/arguments based on a delimiter such as : (using e.g. split(ENV["..."], ':')).
Generally, I haven't encountered the need for such complex inclusion/exclusion of tests yet, so I'm a bit skeptic whether the additional complexity (both for users and developers) is worth it. Having the possibility to run all tests (typically the default but not used in CI) and pre-defined groups of tests has been sufficient in all packages I have worked with. For running even smaller chunks of tests or subsets of test files in local development in my experience typically the most convenient approach is to use TestEnv anyway.

Can we parse/extract test options in both TestEnv and ARGS at the start of runtests.jl and push them into an array of test configurations?

Yep, we could definitely have both available. Have e.g. the ARGS parsing implemented as in the current version of this PR and append to the list of included tests the value of an env var called TURING_SELECT_TEST. Would everyone be happy with that?
Regardless of ARGS/env vars choice, I would still like to stick to tests being selected by file path rather than by manually grouping them. Benefits are

No code needed for introducing the groups. File folders should form natural groups anyway.
Can't accidentally have a test that's not within a group, or a group that isn't included in CI.
More granularity and flexibility in test selection.

Consequently calling the env var GROUP doesn't feel right, even though that seems to be what other SciML packages do.

For running even smaller chunks of tests or subsets of test files in local development in my experience typically the most convenient approach is to use TestEnv anyway.

So I've also done the same, but having had experience with testing in other languages, I also do sometimes miss the ability to simply filter tests based on their name or whatever. It's particularly nice to do when you're working on bugfixes, since then there's a particular sub-test-suite you want to run, which then usually requires copy-pasting to another file, using TestEnv.jl, etc.

Can we parse/extract test options in both TestEnv and ARGS at the start of runtests.jl and push them into an array of test configurations?

Both also seems non-ideal, no? :confused: I'd rather have to do that (push onto ARGS) manually than us having to support both.

I'm also slowly coming to terms with the ARGS approach. In hindsight, I'd much prefer to have tried this out in another package, e.g. Bijectors or something, which is "less mission critical". But given the fantastic work @mhauru has done here, it might be worth just giving it a go in Turing.jl :thinking:

Given @yebai and @torfjelde have come around to args and @devmotion said earlier that he's not too bothered if others are happy with this, I'll go and merge. Everyone seems to agree that this is regardless an improvement over the current situation, and if people miss having a SciML-style GROUP env var we can easily add it by building on the mechanisms introduced here.

Even better, in general you can do:
using Pkg
Pkg.test(Pkg.project().name, test_args=ARGS)

though Pkg.project is apparently an experimental feature.

Question is whether we should just have a small script test/testrunner.jl in the actual repo that does this? Almost seems worth it, no?

This seems like a common problem for many Julia packages, is there no standard solution to this? It feels frustrating that julia --project test/runtests.jl -- a b c --skip d e so nearly works. The only reason it doesn't is that it doesn't create a TestEnv.

I'd suggest running
julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- a b c --skip d e

if you don't work in a Julia REPL and want to execute the tests.


extract interface for progress

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

10 of 129 (7.75%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-2.9%) to 51.639%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/export/worker/worker.go
2
13
15.38%

pkg/export/progress/nil.go
8
21
38.1%

pkg/export/progress/mpb.go
0
95
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/export/worker/worker.go
1
41.12%

Totals

Change from base Build<PHONE_NUMBER>0:
-2.9%

Covered Lines:
441

Relevant Lines:
854

💛  - Coveralls


[Feature] Support materialized view for external table (step 2/3)

What type of PR is this：

[ ] BugFix
[x] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

#11116
Problem Summary(Required) ：

This PR support create materialzied view for hive/hudi partitioned table, I will support iceberg partitioned table later.
Major changes:

Materialized view Analyzer for check base table partition column with mv partition
Add partition from hudi/hive table which partition key is value to olap table which partition key is range.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

[FE PR Coverage Check]
:disappointed: fail : 42 / 144 (29.17%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/Table.java
0
2
00.00%
[210, 214]

:large_blue_circle:
com/starrocks/analysis/LiteralExpr.java
0
6
00.00%
[113, 114, 119, 121, 124, 126]

:large_blue_circle:
com/starrocks/external/HiveMetaStoreTableUtils.java
0
32
00.00%
[382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 402, 404, 405, 407, 408, 409, 410, 411, 412, 413, 414, 415, 417]

:large_blue_circle:
com/starrocks/analysis/DateLiteral.java
0
1
00.00%
[176]

:large_blue_circle:
com/starrocks/analysis/IntLiteral.java
0
12
00.00%
[189, 190, 192, 193, 195, 196, 198, 199, 201, 202, 204, 207]

:large_blue_circle:
com/starrocks/analysis/LargeIntLiteral.java
0
4
00.00%
[104, 105, 106, 107]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
22
49
44.90%
[260, 261, 262, 264, 266, 292, 293, 294, 485, 493, 505, 506, 507, 508, 511, 512, 513, 514, 515, 516, 517, 518, 519, 522, 526, 527, 528]

:large_blue_circle:
com/starrocks/sql/analyzer/MaterializedViewAnalyzer.java
17
34
50.00%
[143, 144, 336, 337, 339, 370, 374, 379, 386, 387, 388, 389, 392, 393, 396, 397, 398]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
3
4
75.00%
[118]

[FE PR Coverage Check]
:disappointed: fail : 42 / 144 (29.17%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/Table.java
0
2
00.00%
[210, 214]

:large_blue_circle:
com/starrocks/analysis/LiteralExpr.java
0
6
00.00%
[113, 114, 119, 121, 124, 126]

:large_blue_circle:
com/starrocks/external/HiveMetaStoreTableUtils.java
0
32
00.00%
[387, 388, 389, 390, 391, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 408, 410, 411, 413, 414, 415, 416, 417, 418, 419, 420, 421, 423]

:large_blue_circle:
com/starrocks/analysis/DateLiteral.java
0
1
00.00%
[176]

:large_blue_circle:
com/starrocks/analysis/IntLiteral.java
0
12
00.00%
[189, 190, 192, 193, 195, 196, 198, 199, 201, 202, 204, 207]

:large_blue_circle:
com/starrocks/analysis/LargeIntLiteral.java
0
4
00.00%
[104, 105, 106, 107]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
22
49
44.90%
[260, 261, 262, 264, 266, 292, 293, 294, 485, 493, 505, 506, 507, 508, 511, 512, 513, 514, 515, 516, 517, 518, 519, 522, 526, 527, 528]

:large_blue_circle:
com/starrocks/sql/analyzer/MaterializedViewAnalyzer.java
17
34
50.00%
[143, 144, 336, 337, 339, 370, 374, 379, 386, 387, 388, 389, 392, 393, 396, 397, 398]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
3
4
75.00%
[118]

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 43 / 143 (30.07%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/Table.java
0
2
00.00%
[210, 214]

:large_blue_circle:
com/starrocks/analysis/LiteralExpr.java
0
6
00.00%
[113, 114, 119, 121, 124, 126]

:large_blue_circle:
com/starrocks/external/HiveMetaStoreTableUtils.java
0
32
00.00%
[387, 388, 389, 390, 391, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 408, 410, 411, 413, 414, 415, 416, 417, 418, 419, 420, 421, 423]

:large_blue_circle:
com/starrocks/analysis/DateLiteral.java
0
1
00.00%
[176]

:large_blue_circle:
com/starrocks/analysis/IntLiteral.java
0
12
00.00%
[189, 190, 192, 193, 195, 196, 198, 199, 201, 202, 204, 207]

:large_blue_circle:
com/starrocks/analysis/LargeIntLiteral.java
0
4
00.00%
[104, 105, 106, 107]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
22
49
44.90%
[260, 261, 262, 264, 266, 292, 293, 294, 485, 493, 505, 506, 507, 508, 511, 512, 513, 514, 515, 516, 517, 518, 519, 522, 526, 527, 528]

:large_blue_circle:
com/starrocks/sql/analyzer/MaterializedViewAnalyzer.java
18
33
54.55%
[334, 335, 337, 368, 372, 377, 384, 385, 386, 387, 390, 391, 394, 395, 396]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
3
4
75.00%
[125]

run starrocks_clang-tidy

run starrocks_admit_test


Find a way to add files to TextDocuments from server side

Currently client reads all .css files on activation. We need the server to be able to add docs for, e.g., dependencies not inside the folder. Also for tests.

Got notifications working, which means this is done.


Trivial(?) miscalculations with diff method and months as unit

diff() is sometimes off by a very small margin of error using the monthsunit (and hence also year).
(all example below are using floating point number, as floored results would "fix" the error in most cases)
Diffing 2016-02-29T00:00:00.000Z with 2016-02-28T23:59:59.999Z should yield the same result as 1 / 1000 / 60 / 60 / 24 / 29 (1 ms in a leap month) which is 3.991060025542784e-10, but instead I'm getting 3.7335722819593786e-10
That's the result of a month with 31 days, not 29. Funny enough, if I reverse the order I get the correct result: -3.991060025542784e-10
The same thing happens with 2015-03-29T06:00:00.000Z and 2015-03-28T06:00:00.000Z. Given the longer time span the error is larger, but still trivial. The expected result should yield the same result as 1/31 (1 day in a month with 31 day), which is 0.03225806451612903, but I'm getting 0.034482758620689655 (1/29).
Again, reversing the order yields the correct result.
In this codepen I have compared the results with a custom method (UTC only).

Some notes in "Month and year diffs" : http://momentjs.com/docs/#/displaying/difference/
See also discussion in #571

And #2133  (not sure if docs were updated to reflect that or not)

I think part of the difference could be leap day compensation. moment.utc("2015-02-29").diff("2015-02-28", "years", true) seems to produce "1" (which I still think is a bug since it's not documented).
This still doesn't explain why 2016-02-29T00:00:00.000Z vs 2016-02-25T22:59:59.999Z is 3.0416666782407407 days, but years are not 3.0416666782407407 / 29 and several other differences.

These things are not well defined, and we've made sure with a lot of iterations, bug reports, etc to make it as close to human reasoning as possible (not to math). So its beyond me why you'd diff 2 dates 1ms apart in months, and expect it to make sense. Just do the math yourself, if you know what you're doing, but so far I see no good reason to change the existing code.
We've already made decisions to make things like 5th Jan to 5th Feb to be always one month, and 5th Jan to 4th Feb to be less than a month, no matter what. So this has some implications to the mathematical correctness. Basically the output is for direct human consumption, 3.7335722819593786e-10 is not.

I wrote the reference function for the upcoming date_diff() in ArangoDB, and then used moment to test if my output was right. I expecting the differences to be my bugs, but when I hand-calculated it turned out to be moments. They may not be significant, but they're there.
@ichernev

We've already made decisions to make things like 5th Jan to 5th Feb to be always one month, and 5th Jan to 4th Feb to be less than a month, no matter what. So this has some implications to the mathematical correctness.

I know. I'm doing the same thing. I even rewrote my function in the codepen to be more similar to moment.diff before submitting this issue, so you could more easily duplicate my tests and fix your miscalculation.

So its beyond me why you'd diff 2 dates 1ms apart in months, and expect it to make sense.

This is a strange way of reasoning to me. This was just the diff I got to after narrowing down the error, and I posted that one because I thought it would be more helpful for you to locate the error. It obviously adds up with a longer span (but won't effect the floored value). The link contains more examples, and I posted one in a comment. Here's another example of how it adds up:
var expectedResult = 15/30; // span of 15 days in a month of 30 days
var momentResult = moment("2015-04-16T00:00:00.000Z").diff("2015-04-01T00:00:00.000Z", "months", true);
console.log("Difference in `months` between april 1 and april 16");
console.log("Expected result:", expectedResult);
console.log("Result using moment.js:", momentResult);
console.log("Expected rounded result:", Math.round(expectedResult));
console.log("Rounded moment.js result:", Math.round(momentResult));

Result:

Difference in months between april 1 and april 16
Expected result: 0.5
Result using moment.js: 0.4845222072678331
Expected rounded result: 1
Rounded result using moment.js: 0

Seems I'm not the only one rounding instead of flooring the diff either:

"ichernev closed this 4 days ago"

(Actually Sept 21 6:22 AM GMT+2, hence less than 4 days ago)


fix: Add config builder methods

Signed-off-by: Miroslav Kovar<EMAIL_ADDRESS>

Codecov Report

Merging #389 (ec2f977) into main (b92317c) will decrease coverage by 17.80%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             main     #389       +/-   ##
===========================================
- Coverage   66.35%   48.55%   -17.81%
===========================================
  Files         153      136       -17
  Lines       14454    11993     -2461
  Branches     2861     2386      -475
===========================================
- Hits         9591     5823     -3768
- Misses       2535     4730     +2195
+ Partials     2328     1440      -888

Flag
Coverage Δ

integration-aries-vcx
?

unittests-agency-client
?

unittests-aries-vcx
48.55% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

aries_vcx/src/init.rs
12.28% <0.00%> (-26.32%)
:arrow_down:

aries_vcx/src/libindy/utils/wallet.rs
20.60% <0.00%> (-12.45%)
:arrow_down:

aries_vcx/src/utils/provision.rs
0.00% <0.00%> (-50.00%)
:arrow_down:

...ndlers/proof_presentation/prover/states/initial.rs
0.00% <0.00%> (-100.00%)
:arrow_down:

aries_vcx/tests/utils/devsetup_agent.rs
0.00% <0.00%> (-77.82%)
:arrow_down:

aries_vcx/tests/test_integration.rs
6.00% <0.00%> (-76.60%)
:arrow_down:

aries_vcx/src/libindy/utils/anoncreds.rs
9.20% <0.00%> (-67.84%)
:arrow_down:

...x/src/handlers/proof_presentation/prover/prover.rs
15.66% <0.00%> (-62.01%)
:arrow_down:

..._vcx/src/handlers/proof_presentation/prover/mod.rs
21.42% <0.00%> (-57.15%)
:arrow_down:

aries_vcx/src/libindy/utils/signus.rs
33.33% <0.00%> (-55.56%)
:arrow_down:

... and 95 more

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 b92317c...ec2f977. Read the comment docs.


416 error

any help 5.0.0
`[PLEXDRIVE] [2017-08-06 22:33] DEBUG  : Request
&{GET https://www.googleapis.com/drive/v3/files/0B7b3VlF8exkfNnotMDdnY2ItU28?alt=media HTTP/1.1 1 1 map[Range:[bytes=104857600-115343360]]   0 [] false www.googleapis.com map[] map[]  map[]      }
[PLEXDRIVE] [2017-08-06 22:33] DEBUG  : Response
&{416 Requested Range Not Satisfiable 416 HTTP/2.0 2 0 map[X-Guploader-Uploadid:[AEnB2UrRQOCQhFa0ZZEhWQ065vAsZTPVNVI3Uxkj9ynCq1hj0JY8-XJTe7E12YWJIZzio0f4Yedj8hfGhKJhuqVVZGjyYq5XFw] Expires:[Mon, 07 Aug 2017 02:33:21 GMT] Server:[UploadServer] Alt-Svc:[quic=":443"; ma=2592000; v="39,38,37,36,35"] Content-Range:[bytes */104857600] Vary:[Origin X-Origin] Content-Type:[application/json; charset=UTF-8] Date:[Mon, 07 Aug 2017 02:33:21 GMT] Cache-Control:[private, max-age=0] Content-Length:[225]] 0xc4638b03a0 225 [] false false map[] 0xc47ef70600 0xc420398bb0}
`

https://pastebin.com/6AFrmwEm
can't get git hub to format correctly

means google couldn't get the block you were looking for. Basically something broke on googles side.

its causing plex to crash with a error, anything i can do?

nope, it's a google problem. 400 range errors are server problems, 500 are client.

ok i was looking at https://github.com/dweidenfeld/plexdrive/issues/121
he indicated it should not occur anymore, so i wasn't sure.
is this a common thing?

there is nothing you can do about it, google couldn't get the object you asked for.. is it common, nope does it happen sure... what the system should do is request it again but when you're streaming video it means it has to stop... not sure what else anybody can do if google isn't give you the part you requested.

ok ty


EO4 生成相机坐标系的环境点云报错

Prerequisites
Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

I am running the latest version of GAAS
I checked the Gitbook documentation and found no answer
I checked to make sure that this issue has not already been filed

Context
your gitbook ubuntu mirror
Screenshots

Failure Logs
root@cwb-System-Product-Name:~/GAAS/software/Obstacle_Map# sh run.sh
-------------Brief-----------------
left_img_topic: /gi/simulation/left/image_raw
right_img_topic: /gi/simulation/right/image_raw
calib_file_name: calibration/mynteye2.yml
calib_width: 752
calib_height: 480
out_width: 752
out_height: 480
debug: 0
disparityMax: 20
disparityMin: 2
distanceMax: 10
distanceMin: 0.1
conductStereoRectify: 0
RangeOfDisparity: 16
SizeOfBlockWindow: 7
PreFilterSize: 255
PreFilterCap: 63
SmallerBlockSize: 7
MinDisparity: 7
NumDisparities: 32
TextureThreshold: 255
UniquenessRatio: 115
SpeckleWindowSize: 0
Lambda: 0
SigmaColor: 10
displayImage: 0
double free or corruption (out)
Aborted (core dumped)
root@cwb-System-Product-Name:~/GAAS/software/Obstacle_Map# ./bin/match_pointcloud_and_slam_pose2
using radius: 0.1
using points number: 100
using mean_k: 50
using stdThres: 1
Node initialized as: pointcloud_to_global_frame
sync_pc_callback 2

能帮助解决下吗

I failed to reproduce your problem, Can you determine the error line number by adding log output (etc. use "std::cout") or debugging with gdb?
The source code of the sh run.sh execution file is at Obstacle_Map/src/dense_reconstruction.cpp

SpeckleWindowSize: 0
Lambda: 0
SigmaColor: 10
displayImage: 0
[New Thread 0x7fffcbbd5700 (LWP 7861)]
[New Thread 0x7fffcb3d4700 (LWP 7862)]
[New Thread 0x7fffcabd3700 (LWP 7863)]
[New Thread 0x7fffca3d2700 (LWP 7864)]
double free or corruption (out)
Thread 1 "dense_reconstru" received signal SIGABRT, Aborted.
  Try "help".
(gdb) threads info
Undefined command: "threads".  Try "help".
(gdb) threads inf
Undefined command: "threads".  Try "help".
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0cb6801 in __GI_abort () at abort.c:79
#2  0x00007ffff0cff897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff0e2cb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff0d0690a in malloc_printerr (str=str@entry=0x7ffff0e2e870 "double free or corruption (out)") at malloc.c:5350
#4  0x00007ffff0d0de75 in _int_free (have_lock=0, p=0x555555d25250, av=0x7ffff1061c40 <main_arena>) at malloc.c:4278
#5  __GI___libc_free (mem=0x555555d25260) at malloc.c:3124
#6  0x00007ffff1ae1f93 in cvReleaseMat () from /usr/local/lib/libopencv_core.so.3.4
#7  0x00007ffff1ccfb61 in cv::read(cv::FileNode const&, cv::Mat&, cv::Mat const&) () from /usr/local/lib/libopencv_core.so.3.4
#8  0x000055555558413c in ?? ()
#9  0x0000000042ff0000 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb) thread
[Current thread is 1 (Thread 0x7ffff7f57280 (LWP 7817))]
(gdb)

You get this error because ''GAAS/software/Obstacle_Map/src/dense_reconstruction.cpp'' does not get the file "GAAS/software/Obstacle_Map/calibration/mynteye2.yml" which is a matrices file.
You can solve it by

figure out why it does not get the config file(we refer this matrix file in config.yaml/calib_file_name:...), then rerun the run.sh
you can define the matrices directly in ''GAAS/software/Obstacle_Map/src/dense_reconstruction.cpp'' then rerun the run.sh, i adopted this and it works

You get this error because ''GAAS/software/Obstacle_Map/src/dense_reconstruction.cpp'' does not get the file "GAAS/software/Obstacle_Map/calibration/mynteye2.yml" which is a matrices file.
You can solve it by
Figuring out why it does not get the config file(we refer this matrix file in config.yaml/calib_file_name:...), then rerun the run.sh
OR you can define the matrices directly in ''GAAS/software/Obstacle_Map/src/dense_reconstruction.cpp'' then rerun the run.sh, i adopted this and it works
Thank you!


Dataset labels not working for deployments

When I use a dataset label to mount a dataset to a deployment, nothing happens.
Upon further inspection, it looks like the MutatingWebhookConfiguration does not trigger for deployments, but only for pods. For deployments, the mutate function should do exactly the same changes it does for pods, but work on the /spec/template/spec path instead of /spec.

I have the same issue,
I used PVC instead of labels although it is not recommended, it is what is working for deployments.

I don't know about this, for me it worked (only relevant code of deployment description):
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      labels:
        dataset.0.id: "example-dataset"
        dataset.0.useas: "mount"

Tested it first out with pod as an example, and then added dataset labels into deployment description.