Dbz-6484 Added logic to support table name when its passed in this format dbname.tablename

Changed JDBC password to optional.
Added function to split database and table name.

There are some smaller issue (unneeded/unrelated changes), but overall LGTM. Also please a test for it. I guess just a unit test in JdbcSchemaHistoryTest would be sufficient. Thanks!

Hi @vjuranek , please take a look whenever u get a chance.

Thanks @subkanthi , LGTM now. Let's wait for @jpechane if he has any further comments.

Thanks @subkanthi , LGTM now. Let's wait for @jpechane if he has any further comments.

Hi @jpechane , can you please take a look when you get a chance

LGTM, thanks! @subkanthi Could you please rebase it to the latest main as there are conflicts?
@vjuranek Feel free to merge the PR as soon as it is possible to do it.

Thanks, rebased with lates.

hi @subkanthi , GH says there are still conflict. Could you please rebase once again? Thanks!

hi @subkanthi , unfortunately what you did is not a rebase but a merge and there are lots of conflict. Could you please do the rebase so that your commit can be applied cleanly? Thanks!

@subkanthi I could do it myself if there are separate commits, but the main issue is this commit where you merge everything with other changes on which your commit should be rebased. With this is impossible for to get the required commits as they don't exists.

@subkanthi I could do it myself if there are separate commits, but the main issue is this commit where you merge everything with other changes on which your commit should be rebased. With this is impossible for to get the required commits as they don't exists.

Hi @vjuranek , I see a lot of conflicts when I do a rebase, should I just create a new PR with the changes
git pull --rebase origin main
From github.com:ismailsimsek/debezium
 * branch                main       -> FETCH_HEAD
Auto-merging .github/workflows/debezium-workflow.yml
CONFLICT (content): Merge conflict in .github/workflows/debezium-workflow.yml
Auto-merging CHANGELOG.md
CONFLICT (content): Merge conflict in CHANGELOG.md
Auto-merging COPYRIGHT.txt
Auto-merging debezium-bom/pom.xml
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/ChangeStreamPipelineFactory.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/MongoDbConnectorConfig.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/MongoDbConnectorConfig.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/MongoDbSnapshotChangeEventSource.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/MongoDbSnapshotChangeEventSource.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/MongoDbStreamingChangeEventSource.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/ReplicaSetOffsetContext.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/ReplicaSetOffsetContext.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/connection/ConnectionContext.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/connection/ConnectionContext.java
Auto-merging debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/connection/MongoDbConnection.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/main/java/io/debezium/connector/mongodb/connection/MongoDbConnection.java
CONFLICT (modify/delete): debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/AbstractBaseMongoIT.java deleted in HEAD and modified in 3781cf3ec (DBZ-6484 Added logic to split database name and table name for JDBC offset storage).  Version 3781cf3ec (DBZ-6484 Added logic to split database name and table name for JDBC offset storage) of debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/AbstractBaseMongoIT.java left in tree.
Auto-merging debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/AbstractMongoIT.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/AbstractMongoIT.java
Auto-merging debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/junit/MongoDbDatabaseProvider.java
CONFLICT (content): Merge conflict in debezium-connector-mongodb/src/test/java/io/debezium/connector/mongodb/junit/MongoDbDatabaseProvider.java
Auto-merging debezium-connector-mysql/pom.xml
Auto-merging debezium-connector-mysql/src/main/java/io/debezium/connector/mysql/MySqlSnapshotChangeEventSource.java
Auto-merging debezium-connector-mysql/src/test/java/io/debezium/connector/mysql/MySqlParserIT.java
Auto-merging debezium-connector-mysql/src/test/java/io/debezium/connector/mysql/SnapshotParallelSourceIT.java
CONFLICT (content): Merge conflict in debezium-connector-mysql/src/test/java/io/debezium/connector/mysql/SnapshotParallelSourceIT.java
Auto-merging debezium-connector-mysql/src/test/java/io/debezium/connector/mysql/SnapshotSourceIT.java
CONFLICT (content): Merge conflict in debezium-connector-mysql/src/test/java/io/debezium/connector/mysql/SnapshotSourceIT.java
Auto-merging debezium-connector-oracle/pom.xml
Auto-merging debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/OracleConnection.java
Auto-merging debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/OracleConnectorConfig.java
CONFLICT (content): Merge conflict in debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/OracleConnectorConfig.java
Auto-merging debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/OracleValueConverters.java
Auto-merging debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/logminer/LogMinerStreamingChangeEventSource.java
Auto-merging debezium-connector-oracle/src/test/java/io/debezium/connector/oracle/OracleConnectorIT.java
CONFLICT (content): Merge conflict in debezium-connector-oracle/src/test/java/io/debezium/connector/oracle/OracleConnectorIT.java
Auto-merging debezium-connector-postgres/pom.xml
Auto-merging debezium-connector-postgres/src/main/java/io/debezium/connector/postgresql/PostgresValueConverter.java
Auto-merging debezium-connector-postgres/src/test/java/io/debezium/connector/postgresql/AbstractRecordsProducerTest.java
Auto-merging debezium-connector-postgres/src/test/java/io/debezium/connector/postgresql/RecordsStreamProducerIT.java
Auto-merging debezium-connector-postgres/src/test/java/io/debezium/connector/postgresql/spi/CustomActionProvider.java
CONFLICT (add/add): Merge conflict in debezium-connector-postgres/src/test/java/io/debezium/connector/postgresql/spi/CustomActionProvider.java
Auto-merging debezium-connector-sqlserver/src/main/java/io/debezium/connector/sqlserver/SqlServerConnectorConfig.java
CONFLICT (content): Merge conflict in debezium-connector-sqlserver/src/main/java/io/debezium/connector/sqlserver/SqlServerConnectorConfig.java
Auto-merging debezium-core/src/main/java/io/debezium/config/CommonConnectorConfig.java
CONFLICT (content): Merge conflict in debezium-core/src/main/java/io/debezium/config/CommonConnectorConfig.java
Auto-merging debezium-core/src/main/java/io/debezium/config/Configuration.java
Auto-merging debezium-core/src/main/java/io/debezium/metrics/Metrics.java
Auto-merging debezium-core/src/main/java/io/debezium/pipeline/JmxUtils.java
CONFLICT (add/add): Merge conflict in debezium-core/src/main/java/io/debezium/pipeline/JmxUtils.java
Auto-merging debezium-core/src/main/java/io/debezium/pipeline/notification/IncrementalSnapshotNotificationService.java
CONFLICT (add/add): Merge conflict in debezium-core/src/main/java/io/debezium/pipeline/notification/IncrementalSnapshotNotificationService.java
Auto-merging debezium-core/src/main/java/io/debezium/relational/RelationalSnapshotChangeEventSource.java
Auto-merging debezium-core/src/test/java/io/debezium/junit/logging/LogInterceptor.java
CONFLICT (content): Merge conflict in debezium-core/src/test/java/io/debezium/junit/logging/LogInterceptor.java
Auto-merging debezium-core/src/test/java/io/debezium/pipeline/notification/IncrementalSnapshotNotificationServiceTest.java
CONFLICT (add/add): Merge conflict in debezium-core/src/test/java/io/debezium/pipeline/notification/IncrementalSnapshotNotificationServiceTest.java
Auto-merging debezium-ddl-parser/src/main/antlr4/io/debezium/ddl/parser/mysql/generated/MySqlLexer.g4
CONFLICT (content): Merge conflict in debezium-ddl-parser/src/main/antlr4/io/debezium/ddl/parser/mysql/generated/MySqlLexer.g4
Auto-merging debezium-ddl-parser/src/main/antlr4/io/debezium/ddl/parser/mysql/generated/MySqlParser.g4
CONFLICT (content): Merge conflict in debezium-ddl-parser/src/main/antlr4/io/debezium/ddl/parser/mysql/generated/MySqlParser.g4
Auto-merging debezium-ddl-parser/src/main/antlr4/io/debezium/ddl/parser/oracle/generated/PlSqlParser.g4
Auto-merging debezium-ddl-parser/src/test/resources/mysql/examples/ddl_create.sql
Auto-merging debezium-ddl-parser/src/test/resources/oracle/examples/ddl_alter.sql
Auto-merging debezium-embedded/src/test/java/io/debezium/embedded/AbstractConnectorTest.java
CONFLICT (content): Merge conflict in debezium-embedded/src/test/java/io/debezium/embedded/AbstractConnectorTest.java
Auto-merging debezium-embedded/src/test/java/io/debezium/pipeline/notification/AbstractNotificationsIT.java
CONFLICT (content): Merge conflict in debezium-embedded/src/test/java/io/debezium/pipeline/notification/AbstractNotificationsIT.java
Auto-merging debezium-quarkus-outbox-common/deployment/pom.xml
Auto-merging debezium-storage/debezium-storage-jdbc/src/main/java/io/debezium/storage/jdbc/offset/JdbcOffsetBackingStore.java
Auto-merging debezium-testing/debezium-testing-system/pom.xml
CONFLICT (content): Merge conflict in debezium-testing/debezium-testing-system/pom.xml
Auto-merging debezium-testing/debezium-testing-system/src/main/java/io/debezium/testing/system/tools/databases/postgresql/OcpPostgreSqlReplicaController.java
CONFLICT (add/add): Merge conflict in debezium-testing/debezium-testing-system/src/main/java/io/debezium/testing/system/tools/databases/postgresql/OcpPostgreSqlReplicaController.java
Auto-merging debezium-testing/debezium-testing-testcontainers/pom.xml
Auto-merging debezium-testing/debezium-testing-testcontainers/src/main/java/io/debezium/testing/testcontainers/DebeziumContainer.java
Auto-merging documentation/antora.yml
CONFLICT (content): Merge conflict in documentation/antora.yml
Auto-merging documentation/modules/ROOT/pages/configuration/notification.adoc
CONFLICT (add/add): Merge conflict in documentation/modules/ROOT/pages/configuration/notification.adoc
Auto-merging documentation/modules/ROOT/pages/configuration/signalling.adoc
CONFLICT (content): Merge conflict in documentation/modules/ROOT/pages/configuration/signalling.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/db2.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/mongodb.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/mysql.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/oracle.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/postgresql.adoc
Auto-merging documentation/modules/ROOT/pages/connectors/sqlserver.adoc
Auto-merging documentation/modules/ROOT/partials/modules/all-connectors/proc-triggering-an-incremental-snapshot-kafka.adoc
CONFLICT (add/add): Merge conflict in documentation/modules/ROOT/partials/modules/all-connectors/proc-triggering-an-incremental-snapshot-kafka.adoc
Auto-merging documentation/modules/ROOT/partials/modules/all-connectors/proc-triggering-an-incremental-snapshot.adoc
Auto-merging jenkins-jobs/pipelines/release/release-pipeline.groovy
Auto-merging jenkins-jobs/scripts/config/Aliases.txt
CONFLICT (content): Merge conflict in jenkins-jobs/scripts/config/Aliases.txt
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
error: could not apply 3781cf3ec... DBZ-6484 Added logic to split database name and table name for JDBC offset storage
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 3781cf3ec... DBZ-6484 Added logic to split database name and table name for JDBC offset storage

@subkanthi yes, this is what I mentioned above. No need to create new PR, just extract the changes, rebase them on current main branch and force push to ismailsimsek:dbz-6484

@subkanthi yes, this is what I mentioned above. No need to create new PR, just extract the changes, rebase them on current main branch and force push to ismailsimsek:dbz-6484

@vjuranek can u please check now.

@subkanthi Unfortunately, this PR ended in very bad shape given all the merges in the history. I created a new one (https://github.com/debezium/debezium/pull/4739) that contains just the net changes. If tests pass we can merge it.
I am sorry for that but it was the most effective solution right now.


Tow-Boot gets stuck after EFI stub: Exiting boot services...

Hello all,
I can confirm this for the PINE64 RockPro64.
When using Tow-Boot and trying to boot any Linux System, it gets stuck at EFI stub: Exiting boot services...
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

I am unable to boot any Linux system when using Tow-Boot.
The error message may correlate with Tow-Boot being unable to boot into Linux but doesn't cause it.
BSDs are untested.
I get this error when using u-boot from the SPI and also when using it from the SD card.
I also get it when Tow-Boot is on the SPI and I'm trying to boot a Linux system from the SD card.
I do not get that error message with u-boot and am able to boot into Linux when using u-boot.
Many, if not all RockPro64 Tow-Boot users seem to have this issue.
So far, great work on the Tow-Boot project, I want to use it over u-boot in the future.
Thank you all in advance.

I have identified the root cause of the issue
it's CONFIG_USE_PREBOOT=y together with the fact that tow-boot is using an older version of u-boot
I just disconnected every usb-device and Tow-boot booted into Linux.
The EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary also goes away when having all usb devices unplugged.
Please consider to upgrade to the newest u-boot for Tow-Boot if possible.

# if there is no nix installed:
curl -L https://nixos.org/nix/install | sh

# restart your shell.

git clone https://github.com/Tow-Boot/Tow-Boot/ -b development
cd Tow-Boot
git fetch origin pull/178/head
git checkout -b u-boot-2022.07 FETCH_HEAD
env -i nix-build -A pine64-rockpro64

# images are in Tow-Boot/results/ (which is a symlink into the /nix/store/name-of-result-dir/)


Feature/remove catkin

Status
PRODUCTION / DEVELOPMENT
Description
Removed the catkin scripts now that all packages have install() commands (thanks @amc-nu !)

Just want to check: We are able to build cross-releases once these scripts are gone, right? Someone has tested that?

@gbiggs afaik, these are already being used in CI
pipelines

Should be good to go, then. Merge away!

@gbiggs we've been building with the colcon scripts since 1.9 IIRC


Add "predist" to package.json

Remove the previous version output files before run dist.
Because maybe there are other files in the dist folder, so  we shouldn't remove the folder.
Related issues :
https://github.com/pixijs/pixi.js/issues/3403
https://github.com/pixijs/pixify/pull/8
.

Why not delete the entire dist folder?

Because maybe there are other files in the dist folder, so we shouldn't remove the folder.
example:
I put my plugin's  output files in dist folder too, but I don't want to remove & rebuild them.
.

I don't understand why you're adding files to dist. Is this in your fork of pixi.js? If so, I would add a predist script just in your fork. Otherwise, the behavior here is that predist should delete the whole dist folder.

Ok ， I agree with you ， and I've changed the PR. please review again.
Now, use  rimraf dist/*.*.
But please don't remove the entire dist folder.
In some IDE/editors  , remove a folder will take some little problems, even recreate immediately.

Can you be more specific about the error? What IDE/editor has a problem removing the whole folder? I have never had a problem with this on other projects.

Example
in macOS's  Finder  ( it's not an IDE editor), I've opened the dist folder.
If at this moment ，remove the dist folder , the Finder will goto the parent folder.
After  build , I have to find & open dist folder again.
in an IDE (I forget it's name) , remove a folder in a project , it will pop a warning dialog and the IDE will get the focus and be the top window.
in some text editors , remove a folder, will auto remove it from the resource list , but when you create a new one , it won't auto add the folder to the resource list.

Replacing with #3441


Step 8 final sentence typo: "Opening the data cache should should the data stored for each city."

The word "should" was written twice.

Hi!
Thanks for the feedback. I've rewritten the codelab from scratch and believe I have fixed this issue. The code has been updated, and the new guide is now live.
If you find any issues with the new codelab, please let us know!
Thanks!


chore: atbaistack-python-app to 0.0.2

chore: Promote atbaistack-python-app to version 0.0.2

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


What is the project status and what LwM2M versions are supported?

[ ] What is the project status?
[ ] What LwM2M versions are supported?  (LwM2M v1.1  and/or  v1.2 ?)
[ ] What DTLS versions are supported? (1.2, 1.3)
[ ] Is this project still being maintained?

(edited your message so that I can reply to it more easier)

Revival has been started, but going on much slower than anticipated.
At Husqvarna, we took part in the revival because we need Wakaama in an upcoming product. Luckily for us (and bad for Wakaama), we figured that most of our needs could already be served by the existing Wakaama code and therefore our focus shifted to other, more pressing areas. The pendulum is swinging back now however, as we need new features (> LwM2M 1.0) and therefore are, once again, more able and motivated to improve Wakaama.
AFAIR: 1.1 is and 1.2 not at all supported. @mlasch, please correct me.
I do not know, never had a (deep) look at it.
Surely not well maintained as of today, but we (@mlasch, me and others) will try to do more/better in the future. My personal goal was and still is to improve the tooling, documentation and testing, so that new people can join easier and improving the code can be done more safely.

Concerning point 3) about DTLS,
AFAIK, Wakaama core library doesn't depend directly to any DTLS library.
There are some examples in this repo which are using  tinyDTLS and so running DTLS 1.2.
But in theory, you should be able to use any DTLS implementation and so any version of the protocol.
(See some related discussion about it : https://github.com/eclipse/wakaama/issues/623)
By the way, there is a PR about using mbedtls in example too, but never merged, see https://github.com/eclipse/wakaama/pull/626.
At LWM2M level, the specification v1.0 and v1.1 doesn't mention DTLS v1.3.
Asking to OMA it seems this should be doable to use it but for now there is no recommendation provided : see https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/540
In a more general way, DTLS v1.3 is very young. Since 2022 we begin to see some implementation of it but not widely widespread.
At Leshan side, we only support DTLS v1.2.

@sbernard31
@rettichschnidi
Hi!
Thanks for the quick feedback and clarification!

At LWM2M level, the specification v1.0 and v1.1 doesn't mention DTLS v1.3.

No, but LwM2M v1.2 is mentioned, while DTLS 1.3 in a maybe context. Seem to say that DTLS 1.2 is fully supported.
DTLS 1.2 is also mentioned here, but that is not well defined weather, and it seem that DTLS 1.3 is optional.

In a more general way, DTLS v1.3 is very young. Since 2022 we begin to see some implementation of it but not widely widespread.

It was released April 2022 (last year). The point being that nothing will ever be widespread before it's actually available! There are basically no FOSS server implementations (AFAIK) that supports DTLS 1.3 today. This at times when IoT development is going exponential.

About DTLS 1.2 vs. DTLS 1.3
One of the main new features of DTLS 1.3, the Connection ID, is backported to DTLS 1.2 via RFC 9146.
Eclipse/Californium supports DTLS 1.2 CID now for two years. Including graceful restart (really nice on server updates!) and CID load-balancing. In tinydtls a client only implementation is available as feature branch. I use that in a small cellular demonstration project no for more than a year with great success. MbedTLS has also recently updated to the final version of RFC 9146.
The left benefits of DTLS 1.3 are then.

some data saving by a more compact record format (I don't expect that to be a game changer)
improved security and newer crypto functions. Especially, the IETF seems to move forward only for TLS 1.3 based functions, e.g. "subcerts".

(Maybe @hannestschofenig completes the comparison, he's for sure ways more engaged than I.)
Overall my feeling is, that it's more important to demonstrate the benefits of UDP based protocols, and that could be done with CoAP/DTLS 1.2 CID. We will see, if "enough" products are build on that, so that a development of DTLS 1.3 will be possible in Eclipse/Californium. I don't expect to have time for that in the next 18 months.
Alternatively, mbedTLS comes with DTLS 1.3 and maybe it's therefore a great idea to see, if leshan can make use of that via java-coap not only for coap+tcp.

I will answer for Wakaama and  for Leshan too. (as you post same kind of comment at https://github.com/eclipse/leshan/issues/1386#issuecomment-1443878522 )
@eabase, It seems to me that you try to convince us as much it's important to move to DTLS 1.3 and LWM2M 1.2.
Don't worry we know that, and if resources are available we will probably go in that direction in the future.
But currently,
Concerning LWM2M 1.2 :
AFAIK, Leshan and Wakaama project are focus on LWM2M v1.1.
I think it makes sense to first focus on LWM2M v1.1 before to jump in LWM2M v1.2. (especially as LWM2M v1.2 more or less includes LWM2M v1.1)
Resources on those projects are limited. Maybe from the outside it seems we move not fast enough. Sorry about that.
Concerning DTLS 1.3 :
Wakaama and Leshan are LWM2M implementation, not DTLS / TLS implementation. So we are also limited by existing FOSS implementation of DTLS 1.3.
For Wakaama, AFAIK, you "should" be able to use any DTLS library. (and so you can try with few library who supports DTLS 1.3 : mbedtls, wolfssl ?)
For Leshan, AFAIK, there is no pure java implementation of DTLS 1.3 (Eventually, this binding https://github.com/open-coap/kotlin-mbedtls. If someone know others, please share :pray: )
And we will will not implement a DTLS 1.3 library in Leshan.
For now Leshan, strongly depends on Californium /Scandium for DTLS  and it does not support DTLS 1.3.
We are working on abstraction to be able to use different implementation than Cf/Sc but doing this abstraction and propose new implementation based on it will take lot of time.

@boaks
@sbernard31
Hi Guys!  Again, thanks for quick feedback.

One of the main new features of DTLS 1.3, the Connection ID, is backported to DTLS 1.2 via RFC 9146.
... The left benefits of DTLS 1.3 are then. ...

There are several features in DTLS 1.3 that I believe will be regarded as must-haves in the very near future:

Substantial power saving when in deep sleep mode, nearly not possible in 1.2
Substantial security improvements (removing insecure protocols)
Zero touch provision support.

(And I'm not just saying this from opinion, but we have several large customers who are requesting these very functionalities today.) The future is now. 😉
The effect of lacking support, is that now a bunch of companies are hacking their own versions of LwM2M 1.1++ or 1.2++ in order to support some DTLS features here and there, further confusing and obscuring any standard compliance. These hacks are not FOSS, so detrimental to the community as a whole.

To summarize, the differences, in a more clear way:

Hope this helps.
PS. Now, since April 2022, DTLS 1.3 is not longer a "draft", however, it's stated as "proposal", which I have asked to clarify here:
https://github.com/tlswg/dtls13-spec/issues/282

@eabase wrote:

There are basically no FOSS server implementations (AFAIK) that supports DTLS 1.3 today. This at times when IoT
development is going exponential.

Correction: wolfSSL does support DTLS 1.3 since release 5.4.0 (July 11, 2022).
We are still looking for other implementations to set up our interoperability tests.
@boaks wrote:

Alternatively, mbedTLS comes with DTLS 1.3 and maybe it's therefore a great idea to see, if leshan can make use of that
via java-coap not only for coap+tcp.

No, unfortunately there is no support for DTLS 1.3 in mbedTLS yet.

@danielinux

Correction: wolfSSL does support DTLS 1.3 since ...

wolfSSL (corrected link) - is not a server, just an SSL library.
What FOSS servers do you have in mind that is using wolfSSL?

Apologies, I thought we were talking about server side implementation of DTLS 1.3. wolfSSL supports both sides, and any application can create a DTLS 1.3 listening socket using wolfSSL.

I am aware of the difference. I am talking about DTLS 1.3, which as I said is available in wolfSSL since v.5.4.0. AFAIK wolfSSL is still the only C library currently supporting DTLS v1.3

Not sure about LwM2M specifically, but a list of FOSS projects with maintained wolfSSL ports is here:
https://github.com/wolfSSL/osp

If you read the Eclipse Public License V2.0 and some articles about combining that with GPLv2, the main and essential difference is:

the eclipse open source projects support also the commercial usage without additional license fees.
GPL is mainly used as dual-license, where you may either open also your extending functions or pay a license fee.

With that, please ensure with other users, that there is really a benefit in supporting GPLv2 stuff.
If so, AFAIK in order to use the EPLv2.0 / GPL dual-license model, it's required to re-license wakaama. That requires the agreement of all contributors (we would need to ask the Eclipse Foundation about the exact process).
There may be an alternative way, where wolfSSL is only one alternative and other alternatives without GPL are also supported, then AFAIK, it doesn't require CQ (process to include external dependencies in order to ensure the "usability according EPL v2.0".)
ARMs mbedTLS comes also with DTLS 1.3 (and DTLS 1.2 CID) and uses a Apache 2.0 license, which fits the EPL v2.0
Just to mention:
DTLS 1.2 Connection ID is implemented in Eclipse/Californium. Eclipse/tinydtls has currently a feature branch support DTLS 1.2 CID as well.

@eabase
(your comment on the 5. March with the table comparing DTLS 1.2 / DTLSS 1.3)
I'm not sure, if you mix up things.
Why should DTLS 1.2 or 1.3 have any influence on the CBOR encoding?
In my experience, the very larges part of the power-saving stuff is the Connection ID (DTLS 1.3, RFC 9147 or DTLS 1.2, RFC 6347+DTLS 1.2 Connection ID, RFC9146), which eliminates the massive usage of handshakes caused by ip-address changes after sleeping. RFC9146 is implemented in Eclipse/Californium and Eclipse/tinydtls (feature branch).
Also in my experience, it's not too unimportant, that an implementation works reliable. For both eclipse DTLS 1.2 Connection ID implementations I have in the meantime very good experience with mid/long term runtime stability.

Hi @boaks

ARMs mbedTLS comes also with DTLS 1.3

just to clarify, DTLS 1.3 is not supported in the mbedTLS development branch (https://github.com/Mbed-TLS/mbedtls/blob/development/library/ssl_tls.c#L1305). It is possible that it is being worked on in a fork but mainline mbedTLS does not yet support DTLS 1.3
Juliusz

DTLS 1.3 is not supported in the mbedTLS development branch

Thanks!
(A year ago it was DTLS 1.3 on the roadmap for the near future ).

I had written a prototype implementation of DTLS 1.3 for Mbed TLS. Unfortunately, the DTLS functionality had to be removed in order to get protype code incorporated into the mainstream Mbed TLS repo. The code was used for the performance measurements in this paper: https://arxiv.org/abs/2011.12035
I have to search where the code is; it shouldn't be too difficult to add the functionality to Mbed TLS again since the functionality of DTLS 1.3 is (intentionally) kept in sync with TLS 1.3.
Needless to say that it would be important to add DTLS 1.3 also to OpenSSL. We have to check their plans.

FWIW if someone is interested to help writing the DTLS 1.3 functionality, please let me know.

I forgot to talk about the features of DTLS 1.3.
As Achim mentioned, RFC 9147 brings DTLS inline with the TLS 1.3 developments. The list of new features in TLS 1.3 (compared to 1.2) is long. At a high-level the benefits are: improved security, better performance, and extra privacy protection. DTLS 1.3 adds extra over-the-wire improvements to TLS 1.3 with a new header format.
Achim mentioned that the Connection ID feature was back-ported from DTLS 1.3 to DTLS 1.2. It significantly improves the energy efficiency of DTLS. The DTLS 1.3 CID version offers extra privacy protection.
Going forward I believe DTLS 1.3 is unavoidable since the IETF TLS working group will continue the standardization of new features, which will only be available for (D)TLS 1.3.
Of course, it takes time to implement the protocols and the protocol extensions. WolfSSL has been leading the development of commercial TLS/DTLS stacks. Congrats to their work. I hope others follow soon.

@boaks

I'm not sure, if you mix up things. Why should DTLS 1.2 or 1.3 have any influence on the CBOR encoding?

It could very well be, as the table was produced by collecting the info I could find. In regard to CBOR that is still beyond my technical understanding.  Perhaps @hannestschofenig  can answer that?

In my experience, the very larges part of the power-saving stuff is the Connection ID, which eliminates the massive usage of handshakes caused by ip-address changes after sleeping.

This is really a collection of items that all help to reduce handshake and data transfers. Only a real world test with functioning libraries can give specific number of this reduction, but from spec's it seem pretty clear it should be more than significant, for sleeping devices with regular wakeups, that also require the highest reliability/connectivity.

Also in my experience, it's not too unimportant, that an implementation works reliable.

That's a double negation.... :)

CBOR

It is the encoding of the coap-payload. It's something as "binary JSON". But as I wrote, I can't see
a relation to DTLS 1.2/1.3.

This is really a collection of items that all help to reduce handshake and data transfers.

As I wrote, if you start to sort the things in DTLS 1.3 / DTLS 1.2 related and others (as CBOR), you will see, that pretty much of the benefits from DTLS 1.3 already comes with DTLS 1.2 CID.

Only a real world test with functioning libraries can give specific number of this reduction, but from spec's it seem pretty clear it should be more than significant, for sleeping devices with regular wakeups, that also require the highest

Exactly, therefore I created zephyr - coaps-client, which demonstrates CoAP/DTLS 1.2 CID using a LTE-M/NB-IoT modem. A longterm test autumn 2022 showed the efficiency and pretty well reliability. That reliability has been improved since that, but 120 days wasn't that bad.
So, those who like to have a look on what is available may check out DTLS 1.2 CID.
And others may either wait or engage themself.

@boaks

[CBOR] I can't see a relation to DTLS 1.2/1.3.

You are right. Sorry for the confusion.
The table I showed was originally based on a LwM2M comparison.  So CBOR is not related to DTLS in this context. What is related is that LwM2M >= v1.2 does use LwM2M CBOR, whereas previous versions do not, which indirectly means that any LwM2M with DTLS support >= 1.2, also has LwM2M CBOR.


It's 2018....

I think that this should be closed. It was fixed by a4fae4815955e6d6b6f8b83d509dfebc65c13868

I think that this should be closed. It was fixed by a4fae4815955e6d6b6f8b83d509dfebc65c13868


Do we really need to open a new db connection every time we insert a new post?

If sqllite for py isn't entirely different than every other db lib I have worked with:
https://github.com/xXAligatorXx/RepostCheckerBot/blob/b11b397baed745df82ae439aacba0ff9bd430af8/database.py#L709-L719
We can reuse the connection, and it definitely should be closed once we are done with it. Closing the cursor is NOT! enough and you'll eventually run out of allowed connections we can establish

more research: https://stackoverflow.com/questions/9561832/what-if-i-dont-close-the-database-connection-in-python-sqlite . Using contextlib appears to be the best method.

connecting to a db usually is a pretty expensive operation. Keeping a connection alive isn't as awful as it sounds as long as it is handled properly in between threads (e.g. I have db connections open for upwards of a few weeks).
If you want to do some further research take a look at connection pools.

Alright so to make sure I get this right. You are saying I should close the connection everytime I do a database operation, but use connection pools, which will cache connections to make opening them again fast?

I may have to rephrase my answer

You are saying I should close the connection everytime I do a database operation

In this case we have to be a bit careful about terminology.
Opening and closing db connections adds overhead to your application. You absolutely do not want to establish a new connection for every request! If you are working with a fixed (and reasonable) number of threads it is reasonable to keep a connection alive for each, throughout the entire lifetime of your application. In this project you are good to go and use them this way.
Now imagine a webserver, a new user requires access to a db. In this case, once again, creating a new connection simply is to expensive. Best practice is to cache connections (the connection pool), retrieving and giving them back to the pool as required. This may or may not be the same syntax as closing the connection but think about it as just returning the object to the pool. The connections themselves are kept alive and served to the next requester as desired.
A nice explanation can be found here: https://pynative.com/python-database-connection-pooling-with-mysql/


pygame.error: Unable to make GL context current

When I try to run the klondike example, I just get a screen that contains whatever was behind it before it appeared and the following error message in the terminal:
$  python3 ./main.py
pygame 2.1.2 (SDL 2.0.20, Python 3.10.4)
Hello from the pygame community. https://www.pygame.org/contribute.html
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "pygame_cards/pygame_cards/game_app.py", line 33, in run
    pygame.display.flip()
pygame.error: Unable to make GL context current

Here is what I did after a git clone:
cd ./pygame_cards
pip install -e .
cd ../examples/klondike/
python3 ./main.py

System information:
$  git rev-parse HEAD
55363aebb66f81b976ea750c27315409688516a5
$  lsb_release -a
LSB Version:    core-11.1.0ubuntu4-noarch:printing-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy
$  dpkg -l python3-pygame
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=============================================
ii  python3-pygame 2.1.2+dfsg-3 amd64        SDL bindings for games development (Python 3)
$  python3 -c "import pygame; print(pygame.__version__); print(pygame.__file__)"
pygame 2.1.2 (SDL 2.0.20, Python 3.10.4)
Hello from the pygame community. https://www.pygame.org/contribute.html
2.1.2
/usr/lib/python3/dist-packages/pygame/__init__.py

After some reseacrh, I came across this, according to which:

you can't rely on graphics being accessible from multiple threads. You would have to transfer all your drawing to the main thread. You can still have threads running other logic.

So I fixed my problem with this patch (including a problem with the pygame window not closing properly by adding a pygame.quit() call):
diff --git a/pygame_cards/pygame_cards/game_app.py b/pygame_cards/pygame_cards/game_app.py
index d64ef91..aae0c43 100644
--- a/pygame_cards/pygame_cards/game_app.py
+++ b/pygame_cards/pygame_cards/game_app.py
@@ -238,8 +238,9 @@ class GameApp(object, metaclass=abc.ABCMeta):
         for event in pygame.event.get():
             if event.type == pygame.QUIT:
                 self.stopped = True
-                self.render_thread.join()
+                # self.render_thread.join()
                 self.game_controller.cleanup()
+                pygame.quit()
                 sys.exit()
             elif event.type == pygame.MOUSEBUTTONUP:
                 self.process_mouse_event(False, self.is_double_click())
@@ -300,11 +301,15 @@ class GameApp(object, metaclass=abc.ABCMeta):
         """ Runs endless loop where game logic and events processing are executed. """
         while 1:
             self.clock.tick(60)
+
+            self.render()
+            pygame.display.flip()
+
             self.process_events()
             self.execute_game_logic()

     def execute(self):
         """ Initializes game, starts rendering thread and starts game endless loop """
         self.init_game()
-        self.start_render_thread()
+        # self.start_render_thread()
         self.run_game_loop()

It basically disables the separate render thread.
Maybe an option could be added for disabling multithreading?
I suppose it could be GNU/Linux-specific issue or related to graphics drivers, but for now this works for me.


add Download (zip) directory menu option

Fixes #45
Adds a "Download (zip)" menu item for each directory. Performs validation against odd path components (like ..), but not safe against e.g. symlinks which point to files outside of the davros file store. As discussed in #45, this shouldn't pose a security risk (since users who can upload files can also just download the whole grain, and nothing sensitive is stored on the grain's container).
I was confused that this diff doesn't change package.json - my apologies, it looks like the archiver dependency accidentally snuck in as part of #46.

I've been slowly migrating the app towards just becoming a plain webdav server. The ember UI speaks webdav, and the few non-webdav server paths just proxy to the webdav server. The idea is that at some point we could replace the underlying filesystem implementation (for versioning, for instance) and nothing would need to change except the webdav server would have a different backend.
All that being said, having the archiver run through webdav would be extremely inefficient so I like this implementation as it is. But it's something to keep in mind if we ever do swap out the storage layer.


Connect the Dots

Description: A puzzle game where players connect dots in a specific order to reveal a hidden image.
Features: Different difficulty levels, timed challenges, and scoring based on speed and accuracy.

@iamrahulmahato  please assign this to me under GSsoc-ext, hacktoberfest & level-1,2,3


Update environs package

Codecov Report

Merging #182 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #182   +/-   ##
=======================================
  Coverage   69.65%   69.65%
=======================================
  Files          29       29
  Lines        1687     1687
=======================================
  Hits         1175     1175
  Misses        512      512

Impacted Files
Coverage Δ

opwen_email_client/webapp/config.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Support for other energy units

Checklist

[X] I have filled out the template to the best of my ability.
[X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
[X] This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.
I don't have a way to get readouts out of my gas meter, but I do have an entity that monitors if heating is on. Gas consumption is linear, as it would be in a light bulb. Only the unit "m³" doesn't match the unit kWh currently exclusively being used in powercalc.
Describe the solution you'd like
It would be nice to be able to use a different unit than kWh, for example m³ for gas consumption.
Describe alternatives you've considered
Alternatives would include creating it manually with a template sensor in YAML, but that's what powecalc is supposed to avoid doing.
Additional context
It would be nice to have gas consumption in the energy dashboard, in some cases this might be the only way.

I won't implement this as I don't see how. It's not simply a matter of adding an option to change some unit type.
Powercalc strategies (fixed, linear etc) are build around Watt which is an instantaneous measurement value.
These are integrated to kWh using the riemann integral sensor (https://www.home-assistant.io/integrations/integration/), which is a measurent of total W used over time. i.e. when your device is using exactly 1000W constantly for an hour you have used 1 kWh.
kWh is in that sense quite similar to m³ as that's also a metric of total consumption.
However m³ cannot be derived from another unit as W -> Wh kan be


Remove raid leader permissions to use security commands.

Requested by Fungal. Raid leaders (except HRLs) should not be allowed to use the following commands:

/editname
/manualverifymain
/manualverifysection
/purge

do we have commands server-specific or no?


Timeline IDs are not globally unique, fix some code that assumed that.

A timeline ID is only guaranteed to be unique for a particular tenant,
so you need to use tenant ID + timeline ID as the key, rather than just
timeline ID.
The safekeeper currently makes the same assumption, and we should fix that
too, but this commit just addresses this one case in the page server.
In the passing, reorder some function arguments to be more consistent.

Same for safekeeper is at
https://github.com/zenithdb/zenith/pull/1109
I added
pub struct ZClusterId {
    pub tenant_id: ZTenantId,
    pub timeline_id: ZTimelineId,
}

there.

whether we should name fields tenant_id or tenantid

Personally I like tenant_id more. IMO it simplifies reading a bit by separating word timeline or tenant. But not a big deal if we chose other option. Consistency is more important

whether we should name fields tenant_id or tenantid

Personally I like tenant_id more. IMO it simplifies reading a bit by separating word timeline or tenant. But not a big deal if we chose other option. Consistency is more important

I pushed this as it is, with most places using 'tenantid', to minimize the change and be consistent with the surroundings. I agree that tenant_id sounds better, so I wouldn't mind a separate PR to search & replace those.


Pomodoro (Tomato) Timer

What's the Problem?
The Pomodoro Technique is a methodology for reducing eye strain and general health by instituting a series of short (generally five minutes) breaks at regular intervals (traditionally 25 minutes). This is often solved using a desk timer or a digital timer, with many websites available to accomplish the task as well.
Solution/Idea
A simple timer with several features:

A configurable work duration (default to 25 minutes)
A configurable break duration (default to 5 minutes)
A "Start Work" button that starts the timer with the work duration
A "Start Break" button that starts the timer with the break duration
An alarm that sounds and/or a notification that displays when a timer expires

Bonus points for being able to configure the sound that plays when a timer expires

Functionality should be similar to examples like https://pomofocus.io/.
Alternatives
Web-based timers like https://pomofocus.io/ and https://www.toptal.com/project-managers/tomato-timer are available for free. They are fine tools that have no Ads, but require a connection to the internet to load. It would be preferable to have this in a centralized tool like DevToys where notifications could be handled by the OS rather than the browser and could be operated offline.
Priorities

Capability
Priority

Start a "work" timer
Must

Start a "break" timer
Must

Send an OS notification when a timer expires
Must

Starting a timer stops the other time (e.g. starting "work" stops "break")
Must

Play a sound when a timer expires
Should

Configure the work duration
Could

Configure the break duration
Could

Configure the sound that plays when a timer expires
Could

DevToys Version
No response
Comments
No response

Seems to be out of scope of DevToys. There are many apps out there to do that.

Seems to be out of scope of DevToys. There are many apps out there to do that.

I can understand the scope creep. But "many apps out there that do that" describes most tools in DevToys, does it not? Is the point not to bring these common utities into a centralized location?

It does. My point, as you seem to have understood, is that a pomodoro timer is something not only useful for developers but for pretty much anyone using a computer. DevToys tries to fit needs of developers mainly, and maybe a tiny dev ops but that's it. :)


Unknown text encoding error when uploading Nanonis files

SIDAM macro is successfully loaded into Igor Pro (version 9). But when opening any *.sxm, *.dat, *.nsp file, this message appears: 'While executing ConvertTextEncoding, the following error occurred: Unknown text encoding'.
Files are loaded after this message but with no information inside ('NaN' or '0 bytes' files).
Thank you!!

Seems like the same as #66


Add login/logout button to front page

Add login/logout button to nav bar
Button content and href (Log in or Log out) depend on user status

When only updating the text of the button from javascript, I noticed that an empty blue button always shows up before the text is loaded, which is distracting. Therefore, I decided to load the entire button from javascript.


Problem when highlighting syntax in the VimScript file.

Describe the highlighting problem
In my init.vim file, I recognized some weird problems:
Firstly, in some places, especially after an open bracket (like {, ...), strings will not be highlighted unless I have a space between them. And it's so weird because other strings are not affected.
As you can see below, the string branch and do do not be highlighted

But when I add a space between them, it works correctly

And this bracket is not affected

Secondly, like the problem above, comments are not highlighted in some places. This problem only happens with comments in the rest of a line (comment in one line) and after it (in the new line and have a same indentation) have another code (all other lines are fine).

As you see above, comments in the whole line like Theme, Status bar; comments don't have any code in the same indent after them like Better theme for barbar and comments followed by the line of code with different indent like Show information of the last commit is not affected, but comments in rest of the line and have a code with the same indent after them like Git information, Git show changes are not highlighted.
Example snippet that causes the problem
    Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}  " the string 'do' have a problem
    Plug 'nvim-treesitter/nvim-treesitter', { 'do': ':TSUpdate'}  " when I add a space between '{' and 'do', it works well.

Tree-sitter parsing result
user_command [0, 0] - [0, 59] vim
  command_name [0, 0] - [0, 4] vim
  arguments [0, 5] - [0, 59] vim
    command_argument [0, 5] - [0, 38] vim
      string_literal [0, 5] - [0, 38] vim
    command_argument [0, 38] - [0, 39] vim
    command_argument [0, 40] - [0, 46] vim
    command_argument [0, 47] - [0, 58] vim
      string_literal [0, 47] - [0, 58] vim
    command_argument [0, 58] - [0, 59] vim

Example screenshot
My colorscheme is oxocarbon (here is the link: https://github.com/nyoom-engineering/oxocarbon.nvim)
I installed that theme with vim-plug (here is the link: https://github.com/junegunn/vim-plug)
When I use :TSHighlightCapturesUnderCursor for parts that have the problem, it showed a message (the same with comments) No highlight groups found

Expected behavior
All comments and strings will be highlighted correctly.
Output of :checkhealth nvim-treesitter
==============================================================================
nvim-treesitter: require("nvim-treesitter.health").check()

Installation ~
- OK `tree-sitter` found 0.20.7 (b268e412ad4848380166af153300464e5a1cf83f) (parser generator, only needed for :TSInstallFromGrammar)
- OK `node` found v18.12.1 (only needed for :TSInstallFromGrammar)
- OK `git` executable found.
- OK `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
  Version: cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
- OK Neovim was compiled with tree-sitter runtime ABI version 14 (required >=13). Parsers must be compatible with runtime ABI.

OS Info:
{
  machine = "x86_64",
  release = "<IP_ADDRESS>-microsoft-standard-WSL2",
  sysname = "Linux",
  version = "#1 SMP Wed Dec 14 23:16:32 UTC 2022"
} ~

Parser/Features         H L F I J
  - c                   ✓ ✓ ✓ ✓ ✓
  - regex               ✓ . . . .
  - markdown_inline     ✓ . . . ✓
  - help                ✓ . . . ✓
  - query               ✓ ✓ ✓ ✓ ✓
  - diff                ✓ . . . .
  - vim                 ✓ ✓ ✓ . ✓
  - gitignore           ✓ . . . .
  - lua                 ✓ ✓ ✓ ✓ ✓
  - java                ✓ ✓ . ✓ ✓
  - html                ✓ ✓ ✓ ✓ ✓
  - markdown            ✓ . ✓ . ✓
  - cpp                 ✓ ✓ ✓ ✓ ✓
  - bash                ✓ ✓ ✓ . ✓
  - python              ✓ ✓ ✓ ✓ ✓

  Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
         +) multiple parsers found, only one will be used
         x) errors found in the query, try to run :TSUpdate {lang} ~

Output of nvim --version
NVIM v0.8.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by runner@fv-az190-151

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Run :checkhealth for more info

The second problem is a duplicate of #97, please keep issues to one single problem!


Langsi

https://github.com/pterodactyl/panel/actions/runs/8355575198

Hi,
Thanks for using the Look Book site. Can you be more specific with your issue? I will close it and wait for a new one with much more details. Thanks.


Add a way to contribute to environment in loadme script

Example use case: Conan
This may mean that nmk setup shall be invoked as part of the loadme script itself

Deprecated, as loadme script generation is replaced by buildenv


Can't use CLI from a remote client

BUG REPORT
What were you trying to achieve?
Use cli from a remote machine.
I have a mainflux running on some machine (on GCP) and I'd like to interact with it from my laptop or any other client running a compiled mainflux-cli.
What are the expected results?
The doc seems to mention it's possible to run the cli with a -m argument to specify the remote Mainflux URL:
https://docs.mainflux.io/cli/
So I'm running mainflux-cli -m http://my-machine health, or docker run -it --rm mainflux/cli -m http://my-machine health, but both error out.
What are the received results?
error: Get "http://localhost/health": dial tcp <IP_ADDRESS>:80: connect: connection refused
Looks like the "-m" argument is wrong.
Running mainflux-cli from the Mainflux machine works (no -m argument)
In what environment did you encounter the issue?
Server running mainflux 0.13.0 with Go 1.19
Additional information you deem important:
Looks like documentation is not updated. Also, a locally built cli and the cli from the Github release page (0.13.0) don't give the same output when running mainflux-cli help (not quite the same options, and there's no -m option).
So, what's the right way to run a cli from a distant machine?
--Eric

@Sylphe88 Seems like you are using the wrong flag (-m is used for metadata, the example is confusing). Also, running from docker can be tricky because the CLI is not running on the same network as the host. Can you try something like:
docker run --network host -it --rm mainflux/cli -t <YOUR MACHINE> health

where -t sets the URL of the Things service.

@Sylphe88 try out this options. Update us if your issue was fixed
  -a, --auth-url string        Auth service URL (default "http://localhost")
  -b, --bootstrap-url string   Bootstrap service URL (default "http://localhost")
  -s, --certs-url string       Certs service URL (default "http://localhost")
  -p, --http-url string        HTTP adapter URL (default "http://localhost/http")
  -t, --things-url string      Things service URL (default "http://localhost")
  -u, --users-url string       Users service URL (default "http://localhost")

Closing due to inactivity


Are there any benefits specific to SQL on Azure VM, ie that differ from using a data drive on Azure storage?

Regarding the section "Why use": Are there any benefits specific to having database files stored as Azure blobs compared to stored on a data drive in Azure storage for SQL on Azure VM? Most/all of the benefits listed under "Why use" apply the same more or less to using a data drive in Azure storage.

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

ID: fb6076ae-3679-3a8e-6530-5f0db78b3f06
Version Independent ID: 335044f8-f561-6f8d-b878-f3fde1664e19
Content: SQL Server data files in Microsoft Azure - SQL Server
Content Source: docs/relational-databases/databases/sql-server-data-files-in-microsoft-azure.md
Product: sql
Technology: supportability
GitHub Login: @MikeRayMSFT
Microsoft Alias: mikeray

I posed the same question on Stack.

@softwarecraft -- John, thank you for your feedback and for posting your question.
@MikeRayMSFT -- Mike, please look into this issue 2793.

@minetokusaltug  - any thoughts on this one?

@rajeshsetlem

I have an open PR (12907) to resolve. Waiting for PM review.


Support new Blob TX type and deployment in chunks

[!IMPORTANT]

Tasks are prioritized in order.
It is possible to address each one in isolation with a different PR.
Only the third and last one can close this issue; the rest should only mention it.

Tasks:

[x] 1) Change TX error message from invalid to unsupported (source)
[x] 2) Throw error prohibiting deployment of >100kb contracts (source)
[ ] 3) Implement support for >100kb contracts

[ ] Support blob TX type (requirement for contract chunk deployments)
[ ] Deploy contract validation for contracts that exceed the max contract size (taken from consensus parameters)
[ ] Chunk and deploy large contracts via blob tx and store contract IDs
[ ] Generate loader contract
[ ] Call contract functions via the loader contract

[!NOTE]
This is the rationale for the above.

Options analysis:

Keep everything as is for <=100k contracts; throws for bigger ones

✅ Keeps browser compatibility
✅ Doesn't block mainnet
⚠ >100kb contracts must be deployed via forc deploy

Implement new [chunk] deployment mechanism

✅ Keeps browser compatibility
⛔ Blocks mainnet

Use forc deploy under the hood

⛔ Breaks browser compatibility
⛔ Blocks mainnet

Conclusions:

Clear, immediate winner.
May still be considered.
Probably a no-go.

Related PRs:

https://github.com/FuelLabs/fuel-vm/pull/780
https://github.com/FuelLabs/fuel-core/pull/1988
https://github.com/FuelLabs/sway/pull/6250

Specs:

https://github.com/FuelLabs/fuel-specs/issues/589

Can we use a pre-compiled .sw contract (the loader) to deploy using an array of ContractIDs via configurables?
I'm thinking of a single loader .sw script that could be reused by TS/RS.

cc @segfault-magnet

If we compile with the compiler we'd have to provide two function selectors -- one to get to the method of the proxy contract, another to be consumed once we jump into the code loaded from blobs.
I think this needs to be handcrafted.
Even so we're not missing out on much -- even if we wrote it in sway it's going to be almost totally in asm statements anyway.
As to how to write the proxy contract we have two choices:
a) write it to accept any number of blob ids
b) hardcode the blob ids
a)
pros:

compression sometime in the future (there was talk about having reusable scripts for contract calls so that they may be replaced with a flag of some sorts)
we can write it once and store it somewhere to be shared
cons:
it's always going to have the same id so you'd need to change the deployment to include a mandatory salt. But that might not be expected by the user. If you don't make the salt derived from the blob ids (and their order) then every time the user deploys there will be a different contract id, which is not expected behavior normally.

b)
pros:
identical behavior as current contract deployments -- if you change the original contract, you'll change the blob ids and that will change the proxy contract and change its contract id.
cons:
not easily template-able since we're customizing it per each deployment
I'll try out b first and see how it goes.

Ok so approach b tested and it works.
Loader is 26 instructions:
pub fn loader_contract(blob_ids: &[[u8; 32]]) -> Vec<u8> {
    const BLOB_ID_SIZE: u16 = 32;
    let get_instructions = |num_of_instructions, num_of_blobs| {
        [
            // 0x12 is going to hold the total size of the contract
            op::move_(0x12, RegId::ZERO),
            // find the start of the hardcoded blob ids, which are located after the code ends
            op::move_(0x10, RegId::IS),
            // 0x10 to hold the address of the current blob id
            op::addi(0x10, 0x10, num_of_instructions * Instruction::SIZE as u16),
            // loop counter
            op::addi(0x13, RegId::ZERO, num_of_blobs),
            // LOOP starts here
            // 0x11 to hold the size of the current blob
            op::bsiz(0x11, 0x10),
            // update the total size of the contract
            op::add(0x12, 0x12, 0x11),
            // move on to the next blob
            op::addi(0x10, 0x10, BLOB_ID_SIZE),
            // decrement the loop counter
            op::subi(0x13, 0x13, 1),
            // Jump backwards 3 instructions if the counter has not reached 0
            op::jneb(0x13, RegId::ZERO, RegId::ZERO, 3),
            // move the stack pointer by the contract size since we need to write the contract on the stack
            op::cfe(0x12),
            // find the start of the hardcoded blob ids, which are located after the code ends
            op::move_(0x10, RegId::IS),
            // 0x10 to hold the address of the current blob id
            op::addi(0x10, 0x10, num_of_instructions * Instruction::SIZE as u16),
            // 0x12 is going to hold the total bytes loaded of the contract
            op::move_(0x12, RegId::ZERO),
            // loop counter
            op::addi(0x13, RegId::ZERO, num_of_blobs),
            // LOOP starts here
            // 0x11 to hold the size of the current blob
            op::bsiz(0x11, 0x10),
            // the location where to load the current blob (start of stack)
            op::move_(0x14, RegId::SSP),
            // move to where this blob should be loaded by adding the total bytes loaded
            op::add(0x14, 0x14, 0x12),
            // load the current blob
            op::bldd(0x14, 0x10, RegId::ZERO, 0x11),
            // update the total bytes loaded
            op::add(0x12, 0x12, 0x11),
            // move on to the next blob
            op::addi(0x10, 0x10, BLOB_ID_SIZE),
            // decrement the loop counter
            op::subi(0x13, 0x13, 1),
            // Jump backwards 6 instructions if the counter has not reached 0
            op::jneb(0x13, RegId::ZERO, RegId::ZERO, 6),
            // what follows is called _jmp_mem by the sway compiler
            op::move_(0x16, RegId::SSP),
            op::sub(0x16, 0x16, RegId::IS),
            op::divi(0x16, 0x16, 4),
            op::jmp(0x16),
        ]
    };

    let real_num_of_instructions = get_instructions(0, blob_ids.len() as u16).len() as u16;

    let instruction_bytes: Vec<u8> =
        get_instructions(real_num_of_instructions, blob_ids.len() as u16)
            .into_iter()
            .collect();

    let blob_bytes: Vec<u8> = blob_ids.iter().flatten().copied().collect();

    [instruction_bytes, blob_bytes].concat()
}

Basically copied what the Sway compiler does with configurables, they place them after the code.
We then figure out how big the whole contract is, expand the stack and fill it with the contract code and then jump to the first instruction.
I've deployed and successfully executed a 1.8MB contract :partying_face:
Gonna write back if there are any issues with this loader after I adjust all the e2e tests to deploy in chunks (temporarily).

Great work for the above @segfault-magnet!
It's worth noting that for us we can't use the BSIZ and BLDD opcodes until we've had a release of @fuels-vm/asm, which will be once this is merged.

Just a heads up, this has been released in v0.56.0:

https://github.com/FuelLabs/fuel-vm/pull/780

I've changed the loader a bit to adapt to the changes made in the vm:
    fn loader_contract(blob_ids: &[BlobId]) -> Result<Vec<u8>> {
        const BLOB_ID_SIZE: u16 = 32;
        let get_instructions = |num_of_instructions, num_of_blobs| {
            // There are 2 main steps:
            // 1. Load the blob contents into memory
            // 2. Jump to the beginning of the memory where the blobs were loaded
            // After that the execution continues normally with the loaded contract reading our
            // prepared fn selector and jumps to the selected contract method.
            [
                // 1. load the blob contents into memory
                // find the start of the hardcoded blob ids, which are located after the code ends,
                op::move_(0x10, RegId::IS),
                // 0x10 to hold the address of the current blob id
                op::addi(0x10, 0x10, num_of_instructions * Instruction::SIZE as u16),
                // The contract is going to be loaded from the current value of SP onwards, save
                // the location into 0x16 so we can jump into it later on
                op::move_(0x16, RegId::SP),
                // loop counter
                op::movi(0x13, num_of_blobs),
                // LOOP starts here
                // 0x11 to hold the size of the current blob
                op::bsiz(0x11, 0x10),
                // push the blob contents onto the stack
                op::ldc(0x10, 0, 0x11, 1),
                // move on to the next blob
                op::addi(0x10, 0x10, BLOB_ID_SIZE),
                // decrement the loop counter
                op::subi(0x13, 0x13, 1),
                // Jump backwards (3+1) instructions if the counter has not reached 0
                op::jnzb(0x13, RegId::ZERO, 3),
                // 2. Jump into the memory where the contract is loaded
                // what follows is called _jmp_mem by the sway compiler
                // subtract the address contained in IS because jmp will add it back
                op::sub(0x16, 0x16, RegId::IS),
                // jmp will multiply by 4 so we need to divide to cancel that out
                op::divi(0x16, 0x16, 4),
                // jump to the start of the contract we loaded
                op::jmp(0x16),
            ]
        };

        let num_of_instructions = u16::try_from(get_instructions(0, 0).len())
            .expect("to never have more than u16::MAX instructions");

        let num_of_blobs = u32::try_from(blob_ids.len()).map_err(|_| {
            error!(
                Other,
                "the number of blobs ({}) exceeds the maximum number of blobs supported: {}",
                blob_ids.len(),
                u32::MAX
            )
        })?;

        let instruction_bytes = get_instructions(num_of_instructions, num_of_blobs)
            .into_iter()
            .flat_map(|instruction| instruction.to_bytes());

        let blob_bytes = blob_ids.iter().flatten().copied();

        Ok(instruction_bytes.chain(blob_bytes).collect())
    }

Blocked


Add August changelog

How about to list the new ports that we added in August as well?

LGTM, I agree it might be a nice touch to add the new ports explicitly.

Add them explicitly? Are they not listed under "new ports added"?

woops, completely missed that


Cmd settings to config

What I did
Added cmd_settings to project config file
Added Wei.to() to convert wei to other units
Related issue: #486
How I did it
Project settings update network settings on project load
Wei.to() operates with python's Decimal and brownie's Fixed classes
How to verify it
Add cmd_settings to project config file and lauch cmd
Tests and docs coming later
Checklist

[ ] I have confirmed that my PR passes all linting checks
[ ] I have included test cases
[ ] I have updated the documentation
[ ] I have added an entry to the changelog

Codecov Report

Merging #501 into master will decrease coverage by 9.78%.
The diff coverage is 20.83%.

@@            Coverage Diff             @@
##           master     #501      +/-   ##
==========================================
- Coverage   88.36%   78.58%   -9.79%
==========================================
  Files          56       56
  Lines        6104     6126      +22
  Branches     1348     1353       +5
==========================================
- Hits         5394     4814     -580
- Misses        488     1108     +620
+ Partials      222      204      -18

Impacted Files
Coverage Δ

brownie/_config.py
73.83% <0.00%> (-2.67%)
:arrow_down:

brownie/convert/datatypes.py
94.40% <20.00%> (-1.52%)
:arrow_down:

brownie/network/rpc.py
83.33% <33.33%> (-5.34%)
:arrow_down:

brownie/test/managers/__init__.py
0.00% <0.00%> (-100.00%)
:arrow_down:

brownie/test/managers/master.py
0.00% <0.00%> (-93.55%)
:arrow_down:

brownie/test/fixtures.py
0.00% <0.00%> (-92.60%)
:arrow_down:

brownie/test/managers/runner.py
0.00% <0.00%> (-86.09%)
:arrow_down:

brownie/test/managers/base.py
0.00% <0.00%> (-82.11%)
:arrow_down:

brownie/test/plugin.py
0.00% <0.00%> (-81.25%)
:arrow_down:

brownie/test/output.py
16.15% <0.00%> (-75.39%)
:arrow_down:

... and 11 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 8d97627...3664749. Read the comment docs.

Rebasing in #503 should fix the failing tests.


Where can I find hte api definition for the qrcode that is used here?

I have googled with no luck in finding micropython (or python) api docs for the qrcode library.

I ported the QRCode library (https://github.com/nayuki/QR-Code-generator)  to MicroPython and maintain it here: https://github.com/pimoroni/QR-Code-generator/tree/micropython/edge
There are some MicroPython stubs here detailing the API: https://github.com/pimoroni/pimoroni-pico-stubs/blob/main/pimoroni_pico-stubs/qrcode/init.pyi
Beyond what's shown in the examples, it doesn't really do anything much since we only implement a very basic, text-only subset of the libraries features.


Please add get identity by email operation

Sometimes you want to check if certain identity is verified and you don't have their id available. So you have to use get list operation which is not good for performance as you can only get 100 records max per request (I'm having to loop on this request to make sure I'm checking the whole list looking for the given identity).
Please make it available on the API also. Thanks in advance!

@Agathe-Brusset  thanks for the response. The status on the UI unfortunately is not helpful in this case, I have to verify it dynamically in my backend. Looking forward for the new implementations!

Hello @hpsmatheus ! We just implemented this on our API, check it out here. Let me know how it works for you!

@Agathe-Brusset that will be very helpful! thanks for letting me know!


Add a st_distance_in_meters macro

It would be nice to have an analog for the st_dwithin_in_meters for st_distance. I find myself wanting to check not only whether something is within a certain range of a point of interest but also return the distance to be displayed to the user.

Thanks! Sorry I didn't see this until now


feat: add FSE banner

Description

As already mentioned in #ISSUE_NUMBER, this PR tackles:

...
...
...

In particular, the ...
Checklist

[ ] I followed the indications in the CONTRIBUTING
[ ] The documentation related to the proposed change has been updated accordingly (also comments in code).
[ ] Have you written new tests for your core changes, as applicable?
[ ] Have you successfully ran tests with your changes locally?
[ ] Ready for review! :rocket:

Fixes

Fixes #

@tensor5 ho approvato la review ma rimane "required"


Upgrade to Gradle 6

Some of the gradle plugins had to be updated.
Java 11 is required.

@KilianKrause
@jo2
@LauchInterceptor
If everyone is ok with using Java 11, this can be merged.


Cannot find timetable for ranged batches

RegEx cannot parse B10 if the batches in time table is written as B5-12

Ah fuck, did I miss that? Thanks. Let's fix this.


[BUG] longhorn-manager build failed

Describe the bug
Hi, I'm new to longhorn.
I want to build longhorn-manager and deploy it.
When I run make on the longhorn-manager project, I get the following error
$ make
./.dapper ci
...

INFO[0750] docker cp /go/src/github.com/longhorn/longhorn-manager/coverage.out .
Error response from daemon: Could not find the file /go/src/github.com/longhorn/longhorn-manager/coverage.out in container longhorn-manager-xKvZqnH

coverage.out is defined in Dockerfile.dapper as DAPPER_OUTPUT, but the coverage.out file does not exist after running the test.
I solved it by adding the -coverprofile=coverage.out argument when running go tests in the scripts/test file.
Please check if there is another way to do this
Thanks in advance
To Reproduce
$ make
./.dapper ci
...

INFO[0750] docker cp /go/src/github.com/longhorn/longhorn-manager/coverage.out .
Error response from daemon: Could not find the file /go/src/github.com/longhorn/longhorn-manager/coverage.out in container longhorn-manager-xKvZqnH

Expected behavior

Support bundle for troubleshooting

Environment

Longhorn version: master branch

Additional context

@mantissahz The PR from @hookak is merged. Can you help move forward the ticket? Thank you.

Verified: PASS
localhost:~/work/self_fork/longhorn-manager # make
Downloading dapper
.dapper.tmp version v0.6.0
./.dapper ci
[+] Building 0.0s (10/10) FINISHED                                                               docker:default

...

Step 6/6 : CMD ["launch-manager"]
 ---> Running in d423c2be435f
 ---> Removed intermediate container d423c2be435f
 ---> f983f03c1103
Successfully built f983f03c1103
Successfully tagged longhornio/longhorn-manager:8919746d
Built longhornio/longhorn-manager:8919746d

Longhorn Manager image: longhornio/longhorn-manager:8919746d
INFO[0568] docker cp /go/src/github.com/longhorn/longhorn-manager/bin .
Successfully copied 67.1MB to /root/work/self_fork/longhorn-manager/.
INFO[0568] docker cp /go/src/github.com/longhorn/longhorn-manager/coverage.out .
Successfully copied 1.19MB to /root/work/self_fork/longhorn-manager/.
localhost:~/work/self_fork/longhorn-manager #

cc @derekbit

Verified passed on master-head (longhorn-manager a4ebed9d) following https://github.com/longhorn/longhorn/issues/8400#issue-2252525438. The build process run without error.


create a brew service

Good work
Looking for a brew service. It looks easy as I'm following this example https://apple.stackexchange.com/questions/293163/how-do-i-add-tomcat-to-brew-services

I think this belongs in the homebre-core repo: https://github.com/Homebrew/homebrew-core/blob/master/Formula/pgweb.rb
Example service https://github.com/Homebrew/homebrew-core/blob/master/Formula/redis.rb#L42-L48.
I do not maintain the pgweb formula updates, so if you'd like to see the service support in Pgweb, you're welcome to provide the implementation.


Python SDK trace sampling

Related issue https://linear.app/serverless/issue/SC-622/python-sdk-sample-trace-payload-details-in-prod-mode
Description
Sample out 80% of traces in case there are no errors/warnings and debug/dev mode is not active.
Testing done

Unit tested
Integration tested

➜  node git:(sample-traces) ✗ npx mocha test/python/aws-lambda-sdk/integration.test.js
2023-03-17T20:20:05.662Z ℹ test test uid: cihan

  Python: integration
2023-03-17T20:20:05.760Z ℹ test Creating core resources test-python-sdk-cihan
2023-03-17T20:21:03.049Z ℹ test Process function success-v3-8
2023-03-17T20:21:03.051Z ℹ test Process function success-v3-9
2023-03-17T20:21:03.051Z ℹ test Process function success-sampled
2023-03-17T20:21:03.052Z ℹ test Process function error-v3-8
2023-03-17T20:21:03.052Z ℹ test Process function error-v3-9
2023-03-17T20:21:03.053Z ℹ test Process function error_unhandled-v3-8
2023-03-17T20:21:03.053Z ℹ test Process function error_unhandled-v3-9
2023-03-17T20:21:03.053Z ℹ test Process function sdk-v3-8
2023-03-17T20:21:03.053Z ℹ test Process function sdk-v3-9
2023-03-17T20:21:03.810Z ℹ test Function success-sampled already exists, deleting and re-creating
    ✔ success-v3-8 (21471ms)
    ✔ success-v3-9 (12945ms)
    ✔ success-sampled
    ✔ error-v3-8
    ✔ error-v3-9
    ✔ error_unhandled-v3-8
    ✔ error_unhandled-v3-9
    ✔ sdk-v3-8
    ✔ sdk-v3-9 (8173ms)
2023-03-17T20:21:45.678Z ℹ test Cleanup test-python-sdk-cihan
2023-03-17T20:21:46.026Z ℹ test Deleted 7 version of the layer test-python-sdk-cihan-internal
2023-03-17T20:21:47.689Z ℹ test Detached IAM policy arn:aws:iam::692593327170:policy/test-python-sdk-cihan from test-python-sdk-cihan
2023-03-17T20:21:47.905Z ℹ test Deleted IAM role test-python-sdk-cihan
2023-03-17T20:21:48.387Z ℹ test Deleted IAM policy arn:aws:iam::692593327170:policy/test-python-sdk-cihan

  9 passing (2m)

@medikoo ready for review please 🙏


Add retry mechanism into middleware

Hi guys,
I recently faced the case when several retry requests for fetch.crawlera.com helped the spider to work well. As I got from the discussion here https://zytegroup.slack.com/archives/C014HA686ES/p1612975265044000 uncork does 3 retries but not for all failures.
I've implemented this as a temporary fix with retrying requests right in the spider. We could do this customer retry middleware sure, but we will need to add this to every spider/project.
To make things simpler - is it possible to add this right into the CrawleraFetchMiddleware and add meta parameter for retry reasons/retry times along with the existing "skip" parameter?
The reasons for failed responses that I've faced
"crawlera_status":"fail"
"crawlera_status":"ban"
"crawlera_error":"timeout"
Thanks.

Just opened https://github.com/scrapy/scrapy/pull/4993 to make this easier.

Hi @elacuesta thanks for taking care of the request.
I've looked at your PR #4993, it can be useful sure, but it seems that this approach won't solve the issue with this particular CrawleraFetchMiddleware. Two points that I have in mind:

The existing RetryMiddleware is activated only with this condition:
if response.status in self.retry_http_codes:
but in some cases, the response code for "bad" response from CrawleraFetchMiddleware is 200 and this won't be retried even if we need it. "Bad" response means that the response has server_error or json decode error
Also for some cases the request has URL 'http://cm-54.scrapinghub.com/fetch/v2' and the original URL that we need to retry is only in meta. In this case, this will be retried incorrectly.

What do you think about adding something like  existing approach
if self.raise_on_error:

    raise CrawleraFetchException(log_msg) from exc

elif self.retry_on_error:

    raise CrawleraRetryException(log_msg) from exc

else

    logger.warning(log_msg)

return response

and implement this CrawleraRetryException separately.
cc @Gallaecio @noviluni @ogiaquino

Hey @PyExplorer! My idea for subclassing the built-in middleware is actually to take advantage of the private _retry method, which handles several things like stats and maximum retries. One alternative we considered in the OSS meeting is closing https://github.com/scrapy/scrapy/pull/4993 in favour of Adrian's https://github.com/scrapy/scrapy/pull/4902, I will suggest some changes to the latter so we can also have customizable stats and the like.

Hey @elacuesta  I see that  scrapy/scrapy#4902 is merged 🎉   Would be good to leverage that and implement the retry functionality in the middleware since there are growing use cases that warrant it.

Indeed @akshayphilar, my plan is to worki on this next week 👍

Also for some cases the request has URL 'http://cm-54.scrapinghub.com/fetch/v2' and the original URL that we need to retry is only in meta. In this case, this will be retried incorrectly

@PyExplorer why do you need to retry the original url? I would think that if request to uncork API fails we should retry request to uncork API, and not to target website.

re:

The existing RetryMiddleware is activated only with this condition:
if response.status in self.retry_http_codes: but in some cases, the response code for "bad" response from CrawleraFetchMiddleware is 200 and this won't be retried even if we need it. "Bad" response means that the response has server_error or json decode error

I see this as a bug in Uncork API. It should not return 200 if something fails. If there is a failed response, uncork did not bring good results it should return 503 service unavailable, this is what some other products from Zyte are doing e.g. Smart Proxy Manager.
This way we could handle Fetch API 5** codes with default built in Scrapy middleware and there will be no need for separate PR by @elacuesta


create react app tutorial can't be initialized after 5.0.0

Describe the bug
trying to start a react tutorial
https://reactjs.org/tutorial/tutorial.html
instalation fails with
"You are running create-react-app 4.0.3, which is behind the latest release (5.0.0).
We no longer support global installation of Create React App.
Please remove any global installs with one of the following commands:

npm uninstall -g create-react-app
yarn global remove create-react-app

The latest instructions for creating a new app can be found here:
https://create-react-app.dev/docs/getting-started/"
Did you try recovering your dependencies?

npm list -g
/home/ubuntu/.nvm/versions/node/v16.14.0/lib
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>Which terms did you search for in User Guide?

(Write your answer here if relevant.)
Environment

Ubuntu WSL with node 16 installed trough nvm
Steps to reproduce

npx create-react-app React_Tutorial

Expected behavior

Starts the tutorial as fine
Actual behavior

attempting to start throws the error that a package is globally installed when it's not
Reproducible demo

(Paste the link to an example project and exact instructions to reproduce the issue.)

@SsamVendittelli, I used the same thing and it worked. Thanks!

I'm seeing this too, solved it in a similar way:
npx create-react-app@5 my-app

Solved it  by manually deleting the cache folders, not a great solution but it worked...


Where can I see the version number of the corresponding tarsframework code for this image? And this stable?

https://hub.docker.com/r/tarscloud/framework

In tags. The latest version is v2.4.0, corresponding from 2.4.0. Stable is also the latest. Stable should not be 2.4.0, but the difference should be small. It hasn't changed much recently. It is recommended to use tag with version number as much as possible to avoid passive upgrade. In the future, it is recommended to use docker with version number.

在Tags中，最新的版本为v2.4.0，从2.4.0开始对应，stable目前也是最新的。stable应该不是2.4.0的, 但是差别应该也不大了, 最近没怎么改了。建议尽量使用带版本号的Tag，可以避免被动升级。以后建议就用带版本号的docker了。

How does this tar node correspond to the tarsframe version? Do you also push the version corresponding to 2.4.0?

https://hub.docker.com/r/tarscloud/tars-node

这个tars-node跟tarsframe版本怎么对应？是否也推送下对应 2.4.0 的版本？

https://hub.docker.com/r/tarscloud/tars-node

This is not necessary. Node is just the runtime environment. The tarsnode application will be installed automatically after the container starts and successfully connects to the framework, so there is no version concept.

这个不用，node只是运行时环境。TarsNode应用会在容器启动并成功连接Framework后自动安装，所以没有版本概念。


Remove incorrect comment about lazy evaluation of setting sources

Change Summary
It looks like the current implementation always evaluates every source before coalescing them into a single dictionary to pass to BaseModel:
https://github.com/samuelcolvin/pydantic/blob/9d631a3429a66f30742c1a52c94ac18ec6ba848d/pydantic/env_settings.py#L73
So the comment about lazy evaluation in the documentation is incorrect and should be removed.
Related issue number
N/A - minor documentation tweak
Checklist

[x] ~Unit tests for the changes exist~ N/A for documentation
[x] ~Tests pass on CI and coverage remains at 100%~ N/A for documentation
[x] Documentation reflects the changes where applicable
[x] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

please review

thanks so much.


When brew is used, an error is reported：'/usr/local/opt/libyaml/lib/libyaml-0.2.dylib' not found

brew config output
brew
Traceback (most recent call last):
18: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in <main>' 	17: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in require_relative'
16: from /usr/local/Homebrew/Library/Homebrew/global.rb:34:in <top (required)>' 	15: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n.rb:55:in backend'
14: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/config.rb:21:in backend' 	13: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
12: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	11: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/simple.rb:3:in <top (required)>'
10: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 9: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
8: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/base.rb:3:in <top (required)>' 	 7: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
6: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 5: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/yaml.rb:4:in <top (required)>'
4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
2: from /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.rb:13:in <top (required)>' 	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle, 0x0009): dependent dylib '/usr/local/opt/libyaml/lib/libyaml-0.2.dylib' not found for '/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle' - /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle (LoadError)
brew doctor output
brew
Traceback (most recent call last):
18: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in <main>' 	17: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in require_relative'
16: from /usr/local/Homebrew/Library/Homebrew/global.rb:34:in <top (required)>' 	15: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n.rb:55:in backend'
14: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/config.rb:21:in backend' 	13: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
12: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	11: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/simple.rb:3:in <top (required)>'
10: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 9: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
8: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/base.rb:3:in <top (required)>' 	 7: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
6: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 5: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/yaml.rb:4:in <top (required)>'
4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
2: from /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.rb:13:in <top (required)>' 	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle, 0x0009): dependent dylib '/usr/local/opt/libyaml/lib/libyaml-0.2.dylib' not found for '/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle' - /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle (LoadError)

[X] The brew doctor above contains no "Warning" lines.

What were you trying to do (and why)?
I want to use brew install some libs, and I run the brew update-reset
What happened (include all command output)?
brew update-reset
==> Fetching /usr/local/Homebrew...
remote: Enumerating objects: 841, done.
remote: Counting objects: 100% (841/841), done.
remote: Compressing objects: 100% (281/281), done.
remote: Total 841 (delta 535), reused 841 (delta 535)
Receiving objects: 100% (841/841), 398.25 KiB | 2.95 MiB/s, done.
Resolving deltas: 100% (535/535), completed with 175 local objects.
From https://mirrors.ustc.edu.cn/brew
bca8f6aa1..92caaf8c3  master     -> origin/master
==> Resetting /usr/local/Homebrew...
Branch 'master' set up to track remote branch 'master' from 'origin'.
Reset branch 'master'
Your branch is up to date with 'origin/master'.
==> Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask...
remote: Enumerating objects: 467, done.
remote: Counting objects: 100% (467/467), done.
remote: Compressing objects: 100% (183/183), done.
remote: Total 467 (delta 284), reused 467 (delta 284)
Receiving objects: 100% (467/467), 326.78 KiB | 3.05 MiB/s, done.
Resolving deltas: 100% (284/284), completed with 44 local objects.
From https://mirrors.ustc.edu.cn/homebrew-cask
ef7dea366b..3c73a0b893  master     -> origin/master
==> Resetting /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask...
Branch 'master' set up to track remote branch 'master' from 'origin'.
Reset branch 'master'
Your branch is up to date with 'origin/master'.
==> Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core...
remote: Enumerating objects: 6735, done.
remote: Counting objects: 100% (6735/6735), done.
remote: Compressing objects: 100% (647/647), done.
remote: Total 6735 (delta 6088), reused 6735 (delta 6088)
Receiving objects: 100% (6735/6735), 1.87 MiB | 8.00 MiB/s, done.
Resolving deltas: 100% (6088/6088), completed with 4784 local objects.
From https://mirrors.ustc.edu.cn/homebrew-core
8253d9f5e8..0ae3a2e522  master     -> origin/master
==> Resetting /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core...
Updating files: 100% (4920/4920), done.
Branch 'master' set up to track remote branch 'master' from 'origin'.
Reset branch 'master'
Your branch is up to date with 'origin/master'.
brew
brew
Traceback (most recent call last):
18: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in <main>' 	17: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in require_relative'
16: from /usr/local/Homebrew/Library/Homebrew/global.rb:34:in <top (required)>' 	15: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n.rb:55:in backend'
14: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/config.rb:21:in backend' 	13: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
12: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	11: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/simple.rb:3:in <top (required)>'
10: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 9: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
8: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/base.rb:3:in <top (required)>' 	 7: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
6: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 5: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/yaml.rb:4:in <top (required)>'
4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
2: from /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.rb:13:in <top (required)>' 	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle, 0x0009): dependent dylib '/usr/local/opt/libyaml/lib/libyaml-0.2.dylib' not found for '/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle' - /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle (LoadError)
What did you expect to happen?
have no LoadError
Step-by-step reproduction instructions (by running brew commands)
brew
Traceback (most recent call last):
18: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in <main>' 	17: from /usr/local/Homebrew/Library/Homebrew/brew.rb:31:in require_relative'
16: from /usr/local/Homebrew/Library/Homebrew/global.rb:34:in <top (required)>' 	15: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n.rb:55:in backend'
14: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/config.rb:21:in backend' 	13: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
12: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	11: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/simple.rb:3:in <top (required)>'
10: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 9: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
8: from /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/i18n-1.8.7/lib/i18n/backend/base.rb:3:in <top (required)>' 	 7: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
6: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 5: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/yaml.rb:4:in <top (required)>'
4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require' 	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
2: from /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.rb:13:in <top (required)>' 	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle, 0x0009): dependent dylib '/usr/local/opt/libyaml/lib/libyaml-0.2.dylib' not found for '/Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle' - /Library/Ruby/Gems/2.6.0/gems/psych-3.3.0/lib/psych.bundle (LoadError)

Do you still get these errors after doing brew update-reset? What is the output of git -C $(brew --repo) describe?

Running gem uninstall psych will probably fix this. You can reinstall it later if you have a Ruby project that really needs it.
(Not sure if there's a nice way we can make brew ignore system-installed gems.)

This is specific to your machine.

git -C $(brew --repo) describe

git -C $(brew --repo) describe
2.7.4-463-g92caaf8c3
And I still get these errors after doing brew update-reset?

This is specific to your machine.

I used rvm install my ruby when I develop, and now I update brew and find it error, and I cant use rvm reinstall the ruby...

Running gem uninstall psych will probably fix this. You can reinstall it later with a working libyaml if you have a Ruby project that really needs it.
(Not sure if there's a nice way we can make brew ignore user-installed gems.)

Thank, but it don't work
hope brew ignore user-installed gems oneday

There’s a small error in my suggestion: I should have said to use /usr/bin/gem rather than just gem

On 6 Feb 2021, at 14:50, aboutmydreams<EMAIL_ADDRESS>wrote:

Running gem uninstall psych will probably fix this. You can reinstall it later with a working libyaml if you have a Ruby project that really needs it.
(Not sure if there's a nice way we can make brew ignore user-installed gems.)
Thank, but it don't work
hope brew ignore user-installed gems oneday
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

There’s a small error in my suggestion: I should have said to use /usr/bin/gem rather than just gem
…
On 6 Feb 2021, at 14:50, aboutmydreams @.***> wrote:  Running gem uninstall psych will probably fix this. You can reinstall it later with a working libyaml if you have a Ruby project that really needs it. (Not sure if there's a nice way we can make brew ignore user-installed gems.) Thank, but it don't work hope brew ignore user-installed gems oneday — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

thx, its not work
my machine’s problem.


Fix remap redirection with build_error_reponse

Fix: #2197
Fix remap redirection with build_error_reponse.
If we set redirect url in TSRemapDoRemap, we do not following this url unless we set another hook in plugin.

[approve ci autest]

Cherry picked to 7.1.x