MRE using EonTI Certs

Opening an issue for discussing the creation of an MRE that use EonTI certificates instead of the current self-signed certificates.

@shankari
I have a couple questions related to the MRE.
The EvseSecurity module has several parameters that point to the different certificate bundles. Each of these parameters has a default path which is where I am trying to copy the certs that Tara has just provided.
Here are my questions:
1.) majority of the files that Tara provided are .crt files which, if I'm not mistaken, are signed certificates. However, the EvseSecurity module manifest.yaml is expecting paths to .pem files, which are the public keys. I think that the goal is to put the .pem file and the .crt files in the same directory that the manifest.yaml is pointing to by default, but I wanted to double check if that's a good assumption
2.) I might be getting mixed up with where these certs are supposed to be copied. We have the contract certs and the EVSE certs, but I'm not sure which bundle parameters are the correct ones. The manifest.yaml has the following options:
The v2g_ca_bundle (default: ca/v2g/V2G_ROOT_CA.pem) is used to verify the installation of SECC leaf certificates using the update_leaf_certificate command.
- The csms_ca_bundle (default: ca/v2g/V2G_ROOT_CA.pem) is used to verify the installation of CSMS leaf certificates using the update_leaf_certificate command.
- The mo_ca_bundle (default: ca/mo/MO_ROOT_CA.pem) is used to verify contract certificates provided by the electric vehicle as part of the ISO 15118 Plug & Charge process.
- The mf_ca_bundle (default: ca/mf/MF_ROOT_CA.pem) is used to verify firmware update files.

I've ruled out the mf_ca_bundle because we're not installing firmware. I was thinking that the contract certificates will go where mo_ca_bundle is pointing and EVSE contract will go where v2g_ca_bundle points to, but I wanted to double check with you first.

Although not directed to me, I have some of the answers.

The .crt file is PEM encoded. So, you can just change the extension to .pem. And yes, the are certificates. The .pem files referred in the EvseSecurity module manifest.yaml are also certificates, they are not just public keys. But certificates contain the  public keys. So, basically, you can rename the EonTi certs with .crt extensions to corresponding .pem files in the manifest.yaml.
The bundles are actually just the root certs. So, you can just copy the corresponding roots from the EonTi directories to the EVerest directories. And yes, the root in the CC chain will go to the mo_ca_bundle directory and the root in the EVSE chain will go to the v2g_ca_bundle directory.

Ok, I've copied the both root certs to ca/mo/MO_ROOT_CA.pem and ca/v2g/V2G_ROOT_CA.pem respectively. I also copied the new ca/v2g/V2G_ROOT_CA.pem to the maeve-csms/config/certificates/root-V2G-cert.pem. However, when I go to test everest, I am getting a failed TLS handshake error:
2024-03-28 23:22:24.097905 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 0 certificates
2024-03-28 23:22:24.098003 [INFO] ocpp:OCPP201     :: libocpp: Done updating OCSP cache
2024-03-28 23:22:25.070620 [INFO] ocpp:OCPP201     :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 2
2024-03-28 23:22:25.076471 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-03-28 23:22:25.123439 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 23:22:25.120025 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-28 23:22:25.170845 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 23:22:25.221372 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 8, reason: TLS handshake failed, HTTP response code: 0, category: websocketpp.transport.asio.socket, transport error code: 167772567, Transport error category: asio.ssl

I wanted to check if I perhaps missed a step, such as adding additional certs to maeve. I still haven't replaced any of the other certificates found in cached_certs_correct_name.tar.gz, just the ones in dist/etc/everest/certs/ca/mo and dist/etc/everest/certs/ca/v2g respectively.

Sorry for the late response. What did you do with the leaf certs? EonTi didn't provide leaf cert for the CSMS (MaEVe in this case). So, if you don't have that, OCPP with TLS with EonTi certs will not work. Actually, I was originally doing what you are doing now. I am also waiting for the CSMS cert.

As we were successful with the locally generated certificates, now we are going to test OCPP 2.0.1 with MaEVe using certificates that EonTi provided. I wanted to open a new issue and @shankari agreed to this here. But as this issue is created for the same purpose, lets go with this one.
The solution was supposed to be straight forward. We just needed to copy the EonTi certificate to replace the locally generated ones in proper places. When I did that, I got this following error while establishing TLS between the OCPP server (MaEVe) and client (EVerest):
2024-04-19 17:13:52.167434 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-04-19 17:13:52.183841 [INFO] evse_security:E  :: TPM Key: false
2024-04-19 17:13:52.186571 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-04-19 17:13:52.226964 [INFO] ocpp:OCPP201     :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-04-19 17:13:52.227413 [INFO] ocpp:OCPP201     :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-04-19 17:13:52.271330 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-04-19 17:13:52.366119 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-04-19 17:13:52.319390 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-04-19 17:13:52.451376 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-04-19 17:13:52.515189 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 8, reason: TLS handshake failed, HTTP response code: 0, category: websocketpp.transport.asio.socket, transport error code: 167772567, Transport error category: asio.ssl

MaEVe gateway logs reported this:
2024/04/19 17:13:52 http: TLS handshake error from <IP_ADDRESS>:44978: local error: tls: bad record MAC
2024/04/19 17:13:55 http: TLS handshake error from <IP_ADDRESS>:44982: local error: tls: bad record MAC

Using wireshark, I got this:
TLSv1.3 Record Layer: Alert (Level: Fatal, Description: Bad Certificate)
    Content Type: Alert (21)
    Version: TLS 1.2 (0x0303)
    Length: 2
    Alert Message
        Level: Fatal (2)
        Description: Bad Certificate (42)

When I checked if the certificate chain is valid, I got a positive result.
For CSMS server chain:
Validating that the certificates are set up correctly
config/certificates/csms.pem: OK
Chain:
depth=0: O = "Eonti, Inc", OU = CCMS, CN = USCPIC001LTON4 (untrusted)
depth=1: C = US, O = "DigiCert, Inc.", OU = TEST MO Sub-CA, CN = V2G TEST 1 MO Sub-CA (untrusted)
depth=2: C = US, O = "DigiCert, Inc.", DC = V2G, OU = TEST Root CA, CN = V2G TEST Root CA

For CSMS client chain:
Configured everest certs, validating that the chain is set up correctly
dist/etc/everest/certs/client/csms/CSMS_LEAF.pem: OK
Chain:
depth=0: C = US, O = "DigiCert, Inc.", DC = CPO, CN = valid.evse.leaf (untrusted)
depth=1: C = US, O = "DigiCert, Inc.", CN = CPO TEST P-256 Sub-CA2 (untrusted)
depth=2: C = US, O = "DigiCert, Inc.", DC = V2G, OU = TEST CPO Sub-CA, CN = V2G TEST CPO Sub-CA1 (untrusted)
depth=3: C = US, O = "DigiCert, Inc.", DC = V2G, OU = TEST Root CA, CN = V2G TEST Root CA

My suspicion was that the CN of the CSMS server cert not being host.docker.internal might be the cause. I told Francis from EonTi about this on last Monday. But I am confused because this should have thrown a specific, custom error message, not from an external, well known package.

As @shankari suggested, I tested if changing the CN in the CSMS server certificate creates the same error. So, I took the currently working cert bundle and just replaced the CSMS server cert-key where the CN was host.docker.internal with a paor where the CN is CSMSCert.
Similarly, the certificate chains where validated but ultimately caused the same error:
2024-04-19 17:01:45.103588 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-04-19 17:01:45.151745 [INFO] evse_security:E  :: TPM Key: false
2024-04-19 17:01:45.152203 [INFO] evse_security:E  :: TPM Key: false
2024-04-19 17:01:45.152804 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-04-19 17:01:45.153408 [INFO] ocpp:OCPP201     :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-04-19 17:01:45.153689 [INFO] ocpp:OCPP201     :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-04-19 17:01:45.199226 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-04-19 17:01:45.245640 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-04-19 17:01:45.243213 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-04-19 17:01:45.332854 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-04-19 17:01:45.407118 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 8, reason: TLS handshake failed, HTTP response code: 0, category: websocketpp.transport.asio.socket, transport error code: 167772567, Transport error category: asio.ssl

For CSMS server chain:
Validating that the certificates are set up correctly
config/certificates/csms.pem: OK
Chain:
depth=0: CN = CSMSCert, O = EVerest, C = DE, DC = CPO (untrusted)
depth=1: CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G (untrusted)
depth=2: CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G (untrusted)
depth=3: CN = V2GRootCA, O = EVerest, C = DE, DC = V2G

For CSMS client chain:
Configured everest certs, validating that the chain is set up correctly
dist/etc/everest/certs/client/csms/CSMS_LEAF.pem: OK
Chain:
depth=0: CN = CSMSCert, O = EVerest, C = DE, DC = CPO (untrusted)
depth=1: CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G (untrusted)
depth=2: CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G (untrusted)
depth=3: CN = V2GRootCA, O = EVerest, C = DE, DC = V2G

Here we are using the same chain for both the server and the client, but this is not an issue. We do the same thing for the working scenario. Ideally, they should be two different chains, like the ones provided by EonTi.

@the-bay-kay, I am not sure if you need to use wireshark, but in case you do, there are many instructions on how to use wireshark to view traffic over a docker network (e.g. https://github.com/linuxserver/docker-wireshark or https://superuser.com/questions/1685605/how-to-capture-docker-container-traffic-using-wireshark). If you do end up using wireshark, I would suggest that you change all the docker compose files to include wireshark by default and change the README to include instructions on how to access the wireshark desktop

Hi all!  Just wanted to ask some quick clarifying questions about the certificate replacement process, to make sure I'm on the right track reproducing & debugging this.
As I understand it, I need to replace the following root certs: (all under .../dist/etc/everest/certs/)

ca/mo/MO_ROOT_CA.pem
ca/v2g/V2G_ROOT_CA.pem

Are there any certs I'm missing that I should replace? (I've seen the CSMS_Leaf mentioned a few times in this thread, for example).  And, to that end -- I should replace the entire chain, correct?  Or is replacing the root sufficient?
Assuming I've got the correct list of certs to replace, where exactly in the container (manager-1) should I find replace them?

My guess is /ext/source/build/dist/.../certs/, but I want to double check that's the correct one.  As can be seen above, my '/workspace/dist/directory doesn't have theetc/` directory, as in Sahabulh's Logs).
Finally -- where will I be placing the certs in the MaEVe container?  I see there's a script to fetch certificates (link), but I haven't been able to find where the config directory is within the docker container.
I'll go ahead and start experimenting with my current assumptions -- let me know if there's anything wrong in my understanding of this project!

@the-bay-kay the list of certs and the locations they map to are in the demo script (demo-iso15118-2-ac-plus-ocpp.sh). All the logs above are from running that script. You need to replace all the certs, not just the root. The location of the certs has changed since sahabul's logs due to https://github.com/EVerest/everest-demo/pull/39. You can see the new cert location in the updated script, and the change in the commit history.
As we discussed:

the test works with the self-signed certs
we need to replace the self-signed certs with EonTI certs and get it to work again.

Nothing else needs to change
It should have Just Worked since we are replacing a valid cert chain by another valid cert chain, but it is not working

Running Tests with EoNTI Certs
Just added the certs provided to cert archive, and demo-iso15118-ac-plus-ocpp.sh - more or less as follows...

Manually running the verification shows that the cert chain is OK...

And, when executing this variation of the script, it launches ok -- but, once in the runtime loop, we repeatedly receive the following error...

Interestingly, it seems that things are working correctly when testing the UI...
https://github.com/EVerest/everest-demo/assets/98350084/67ce02ee-e4b4-4606-b1df-b2d614cbc122
Just wanted to post these initial findings, about to start diving into these websocket errors!

And, when executing this variation of the script, it launches ok -- but, once in the runtime loop, we repeatedly receive the following error...

Correct. The "underlying transport error" is what we need to fix. The OCSP error happens in both situations and can be ignored (at least for now).

Would be good to understand what is validating the cert/token if the connection to the CSMS is broken.

It seems that that the network failure behavior is to accept the validation, given that OfflineTxForUnknownIDEnabled is flagged.  For more context, OCPP "Section 2.6, C15 - Offline Authorization", Figure 35

Tracing through from this error...

log_on_fail seems to be getting called on_fail_plain, the fail handler for the client connection_pointer set in connect_plain()... Reading up more on C's client implementation now, to see when the error handler might be called

Enabled debug logging in /ext/source/build/dist/etc/everest/default_logging.cfc -- pipping the output into a file to look at the logs...
cat demo-iso-15118-2-ac-plus-ocpp.sh | bash -s - -r $(pwd) -e 2>&1 | temp.log

Searching for the same error (while ignoring the erroneous characters...)
2024-06-10 16:43:15.255847 [DEBG] ocpp:OCPP201    ocpp::WebsocketPlain::WebsocketPlain(const ocpp::WebsocketConnectionOptions&) :: Initialised WebsocketPlain with URI: ws://localhost:9000/cp001
2024-06-10 16:43:15.256006 [INFO] ocpp:OCPP201     :: Connecting to plain websocket at uri: ws://localhost:9000/cp001 with security profile: 1
2024-06-10 16:43:15.256785 [DEBG] ocpp:OCPP201    void ocpp::WebsocketPlain::connect_plain() :: Connecting with security profile: 1
2024-06-10 16:43:15.256840 [DEBG] ocpp:OCPP201    std::optional<std::__cxx11::basic_string<char> > ocpp::WebsocketBase::getAuthorizationHeader() :: AuthorizationKey present, encoding authentication header
2024-06-10 16:43:15.256869 [DEBG] ocpp:OCPP201    std::optional<std::__cxx11::basic_string<char> > ocpp::WebsocketBase::getAuthorizationHeader() :: Basic Auth header: Basic Y3AwMDE6REVBREJFRUZERUFEQkVFRg==
2024-06-10 16:43:15.257947 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system
2024-06-10 16:43:15.258073 [INFO] ocpp:OCPP201     :: Reconnecting in: 2000ms, attempt: 1
2

Zooming into the new debug logs, and cleaning them up...
ocpp::WebsocketPlain::WebsocketPlain(const ocpp::WebsocketConnectionOptions&) :: Initialised WebsocketPlain with URI: ws://localhost:9000/cp001

void ocpp::WebsocketPlain::connect_plain() :: Connecting with security profile: 1
std::optional<std::__cxx11::basic_string<char> > ocpp::WebsocketBase::getAuthorizationHeader() :: AuthorizationKey present, encoding authentication header
std::optional<std::__cxx11::basic_string<char> > ocpp::WebsocketBase::getAuthorizationHeader() Basic Auth header: Basic Y3AwMDE6REVBREJFRUZERUFEQkVFRg==
void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system

So, we see a few outputs from getAuthorizationHeader() here.   Time to trace back and see what calls this, I'm unsure how hopefull this trail will be...

(An Aside: For those new-ish to Charging Infrastructure Certification, as I was when starting this project -- I found this article particularly helpful when trying to understand the methodology / justification behind Plug-and-Charge network authentication!)

I can't help but wonder, is this certs/client/cso/SECC_LEAF.key file the issue? It doesn't seem to be in the list of certificates we're replacing in the demo script -- and, as we can see, the x509 validation fails on each of the children. Investigating further

We are not replacing it in the demo script, demo script works => it is not used. Feel free to remove it it completely, test with the original demo certs and verify that it works.

demo scripts works => it is not used.

Yup, you were right.  Deleting SECC_LEAF.key and running
cat demo-iso-15118-2-ac-plus-ocpp.sh | bash -s - -r $(pwd) -2 2>&1 | temp_two.log

Gives the logs below, and runs as expected (searching for OfflineTxForUnknownIdLabel comes up empty).  Back to the drawing board!

 No Leaf Key, Profile 2
ERRO ocpp:OCPP201   void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system
INFO ocpp:OCPP201   Reconnecting in: 2000ms, attempt: 1
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS) Registering result handler 0x7fd90478adf8 for command get_v2g_ocsp_request_data on topic everest/evse_security/main/cmd
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS) Subscribing to everest/evse_security/main/cmd
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS) #handler[everest/evse_security/main/cmd] = 1
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::publish(const std::string&, const std::string&, QOS) publishing to everest/evse_security/main/cmd
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) topic everest/evse_security/main/cmd starts with everest/
DEBG evse_security:E void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) topic everest/evse_security/main/cmd starts with everest/
DEBG evse_security:E Everest::Everest::provide_cmd(std::string, std::string, JsonCommand)::<lambda(Everest::json)> Incoming evse_security:EvseSecurity->main:evse_security->get_v2g_ocsp_request_data() for <handler>
INFO evse_security:E Requesting key/pair: V2G
INFO evse_security:E TPM Key: false
DEBG evse_security:E std::filesystem::__cxx11::path evse_security::get_private_key_path_of_certificate(const X509Wrapper&, const std::filesystem::__cxx11::path&, std::optional<std::__cxx11::basic_string<char> >) Key found for certificate at path: "/ext/source/build/dist/etc/everest/certs/client/cso/SECC_LEAF.key"
DEBG evse_security:E static bool evse_security::OpenSSLSupplier::x509_is_child(evse_security::X509Handle*, evse_security::X509Handle*) : Certificate issued by error: unable to get local issuer certificate
DEBG evse_security:E static bool evse_security::OpenSSLSupplier::x509_is_child(evse_security::X509Handle*, evse_security::X509Handle*) : Certificate issued by error: unable to get local issuer certificate
DEBG evse_security:E static bool evse_security::OpenSSLSupplier::x509_is_child(evse_security::X509Handle*, evse_security::X509Handle*) : Certificate issued by error: unable to get local issuer certificate
DEBG evse_security:E static bool evse_security::OpenSSLSupplier::x509_is_child(evse_security::X509Handle*, evse_security::X509Handle*) : Certificate issued by error: unable to get local issuer certificate
WARN evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) : [0m [1;32m [0m: Could not retrieve OCSP Responder URL from certificate
DEBG evse_security:E Everest::Everest::provide_cmd(std::string, std::string, JsonCommand)::<lambda(Everest::json)> RETVAL: {"ocsp_request_data_list":[{"certificate_hash_data":{"hash_algorithm":"SHA256","issuer_key_hash":"b0f060ff18d252c4166679206bf0a19445ed67ddef9d8e0415098043b82b09de","issuer_name_hash":"7f89f3934f0d724ed37e98825f85cb96bb8620f1352550eab3638bff72db293d","serial_number":"303a"},"responder_url":"https://www.example.com/"},{"certificate_hash_data":{"hash_algorithm":"SHA256","issuer_key_hash":"efbd68060fc41382c7b1e344083cb15c2ee6b6a436153a89d806c22f0fdc54a6","issuer_name_hash":"13dac2b50f31854dfa3cf8d41b6f7a2dca4ee20096ef3ba25afe2287ad376e16","serial_number":"303b"},"responder_url":"https://www.example.com/"}]}
DEBG evse_security:E void Everest::MQTTAbstractionImpl::publish(const std::string&, const std::string&, QOS) publishing to everest/evse_security/main/cmd
DEBG evse_security:E void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) topic everest/evse_security/main/cmd starts with everest/
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) topic everest/evse_security/main/cmd starts with everest/2024-06-10 16:43:15.301456 [ [1;30mDEBG [0m] [1;32mcar_simulator_1 [0m [1;36mvoid Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) [0m [1;30m: [0m [1;32m [0m: topic everest/yeti_driver_1/yeti_simulation_control/cmd starts with everest/

DEBG car_simulator_1 Everest::Everest::call_cmd(const Requirement&, const std::string&, Everest::json)::<lambda(Everest::json)> Incoming res "f7b7033d-9627-4e58-b2f9-3f0383712d6f" for yeti_driver_1:JsYetiSimulator->yeti_simulation_control:yeti_simulation_control->setSimulationData()
DEBG car_simulator_1 Everest::json Everest::Everest::call_cmd(const Requirement&, const std::string&, Everest::json) : res future ready2024-06-10 16:43:15.301907 [ [1;30mDEBG [0m] [1;32mocpp:OCPP201   [0m [1;36mEverest::Everest::call_cmd(const Requirement&, const std::string&, Everest::json)::<lambda(Everest::json)> [0m [1;30m: [0m [1;32m [0m: Incoming res "87e02c2f-18de-4dc3-86ec-629966a2edc1" for evse_security:EvseSecurity->main:evse_security->get_v2g_ocsp_request_data()

DEBG car_simulator_1 void Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&) Unregistering handler 0x7ffebbabead0 for everest/yeti_driver_1/yeti_simulation_control/cmd
DEBG ocpp:OCPP201   Everest::json Everest::Everest::call_cmd(const Requirement&, const std::string&, Everest::json) res future ready
DEBG car_simulator_1 void Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&) Unsubscribing from everest/yeti_driver_1/yeti_simulation_control/cmd
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&) Unregistering handler 0x7fd904359b70 for everest/evse_security/main/cmd2024-06-10 16:43:15.302228 [ [1;30mDEBG [0m] [1;32mcar_simulator_1 [0m [1;36mvoid Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&) [0m [1;30m: [0m [1;32m [0m: #handler[everest/yeti_driver_1/yeti_simulation_control/cmd] = None

DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&)  Unsubscribing from everest/evse_security/main/cmd
DEBG ocpp:OCPP201   void Everest::MQTTAbstractionImpl::unregister_handler(const std::string&, const Token&)  #handler[everest/evse_security/main/cmd] = None
INFO ocpp:OCPP201   libocpp: Updating OCSP cache on 2 certificates
WARN ocpp:OCPP201   void ocpp::v201::OcspUpdater::updater_thread_loop() libocpp: Got unexpected message type from CSMS, expected: GetCertificateStatusResponse, got: InternalError, will retry.

My current hunch is, we can rule out everything under get_very_file -- the on_tls_init chain seems to be executing O.K., currently trying to trace where exactly the wss_client performs the initialization.  Starting to look at the calls in WebsocketTLS::connect_tls -- since we're slotting the certs into Profile 2, I think we can start our investigation at 214

Comparing the working and broken debug logs...

 Normal Profile 2
DEBG ocpp:OCPP201    std::optional<std::__cxx11::basic_string<char> > ocpp::WebsocketBase::getAuthorizationHeader()  Basic Auth header: Basic Y3AwMDE6REVBREJFRUZERUFEQkVFRg==
DEBG ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)  Registering result handler 0x7f1fe09f97e8 for command get_v2g_ocsp_request_data on topic everest/evse_security/main/cmd
DEBG ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)  Subscribing to everest/evse_security/main/cmd
DEBG ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)  #handler[everest/evse_security/main/cmd] = 1
DEBG ocpp:OCPP201    void Everest::MQTTAbstractionImpl::publish(const std::string&, const std::string&, QOS)  publishing to everest/evse_security/main/cmd
DEBG ocpp:OCPP201    void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>)  topic everest/evse_security/main/cmd starts with everest/
DEBG evse_security:E void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>)  topic everest/evse_security/main/cmd starts with everest/
DEBG evse_security:E Everest::Everest::provide_cmd(std::string, std::string, JsonCommand)::<lambda(Everest::json)>  Incoming evse_security:EvseSecurity->main:evse_security->get_v2g_ocsp_request_data() for <handler>
INFO evse_security:E   Requesting key/pair: V2G
INFO evse_security:E   TPM Key: false

 Profile 2 + Eonti
DEB  ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)[ Registering result handler 0x7f40571797e8 for command get_v2g_ocsp_request_data on topic everest/evse_security/main/cmd
DEB  ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)[ Subscribing to everest/evse_security/main/cmd
DEB  ocpp:OCPP201    void Everest::MQTTAbstractionImpl::register_handler(const std::string&, std::shared_ptr<TypedHandler>, QOS)[ #handler[everest/evse_security/main/cmd] = 1
DEB  ocpp:OCPP201    void Everest::MQTTAbstractionImpl::publish(const std::string&, const std::string&, QOS)[ publishing to everest/evse_security/main/cmd
DEB  ocpp:OCPP201    void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>)[ topic everest/evse_security/main/cmd starts with everest/
ERR  ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int)[ Failed to connect to websocket server, error_code: 8, reason: TLS handshake failed, HTTP response code: 0, category: websocketpp.transport.asio.socket, transport error code: 167772567, Transport error category: asio.ssl
INF  ocpp:OCPP201    [ Reconnecting in: 2000ms, attempt: 1
DEB  evse_security:E void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>)[ topic everest/evse_security/main/cmd starts with everest/
DEB  evse_security:E Everest::Everest::provide_cmd(std::string, std::string, JsonCommand)::<lambda(Everest::json)>[ Incoming evse_security:EvseSecurity->main:evse_security->get_v2g_ocsp_request_data() for <handler>
INF  evse_security:E [ Requesting key/pair: V2G

There seems to be no discernible differences we can glean from the logs -- the on_mqtt_message calls occur at slightly offset times, but we can ignore that...

Briefly reading up on Asio and WebSocket++'s implementation of the asio_client, just to better understand what's happening when wss_client->connect() is being called...

Fishing for leads, pivoting to trying Wireshark.  I've had some issues with docker-wireshark -- perhaps it's my lack of familiarity with the software, but I haven't been able to monitor any container traffic (see screenshots under fold).  Going to spend a bit of time with Edgeshark, to weigh my options

Docker Wireshark Screenshots
Docker Wireshark
After some exploration, I haven't been able to capture any traffic.  Am I missing something in the GUI / Setup?  I've followed the docker-compose setup pretty closely...

Regular Wireshark
Compare the above to regular wireshark, running on the same Windows Host -- lots of opportunities to capture.

Added Edgeshark and execution details in PR #60 -- will keep the discussion of certificate investigation in this thread, as it contains all of the background information.

TLSv1.3 Record Layer: Alert (Level: Fatal, Description: Bad Certificate)
    Content Type: Alert (21)
    Version: TLS 1.2 (0x0303)
    Length: 2
    Alert Message
        Level: Fatal (2)
        Description: Bad Certificate (42)

So far, I've been unable to capture this alert. I'll absolutely chalk this up to my lack of experience with the software -- just wanted to give some updates on my methods, in case I'm barking up the wrong tree.
Currently, I'm capturing the virtual bridges between for Maeve-CSMS and Everest-Demo, and filtering for TLS (See screenshots under fold).  Doing so captures only the Client Hello handshake record.  Looking at the TCP packets (again, ignoring the handshakes), I see a variety of messages -- most from yeti_driver_1, others from powermeter or other iso-151118_charger.

 Capture Screenshots
Wiring Screenshot

TLS Packets

TCP Packets

Taking a step back to carefully go through the certs provided, some general thoughts on the cert replacement:
Could a mismatch in the MO Root CN be causing issues?  Our current MO has a Subject Name CN of MORootCA -- the EonTi Provided certs do not have the same SN.  Since we aren't replacing any of the other certs in certs/ca/mo, any attempt to validate these from this new root would fail.
Admittedly, I'm somewhat hazy on where in the code this chain would be evaluated.   I understand the maeve setup -- we replace the other the certs with those generated by the makefile, and replace the MO Root in the config, using the patch to update said config.  We may not be transferring the other MO certs, but shouldn't we be replacing them? Will spend some time testing now.

Another point of confusion -- within the given certs, the only CSMS Leaf cert that is viable (e.g., that has a CN of host.docker.internal) depends on a single MO Sub-Certs, _not two CPO Certs, as is currently the case with our self-signed certs.  We certainly can't copy over the chains one-for-one -- will this be an issue?  I'm wishing I new exactly where in the code the certs are verified during runtime.


DO_NOT_MERGE: Update Action Views

WARNING
This visually breaks a number of buttons in Ablii and Connect. I've fixed many of them in this branch and in a local branch, but I'm sure I didn't get all of them. We should be careful about when we merge this because we don't want to be in a situation where we merge this and peg nanopay to a commit past this one before the fixes on the nanopay side are ready.
Changes

Updates foam.u2.ActionView's CSS to match this design system:

Added ButtonSize enum and size property on foam.u2.ActionView
Added ButtonStyle enum and buttonStyle property on foam.u2.ActionView
Added a CSS colour macro for header colour
Replaced a number of hard-coded colours with references to named CSS colour macros
Updated the submenu text so that it's no longer white, which is illegible with the new accent colour, which is a light blue

Changing the CSS for the base ActionView causes a lot of places that were overriding the CSS of actions to break. I fixed a bunch of them here but I'm sure I didn't get them all. Here is a list of the places I've fixed already:

Sign in page
Clear button in ReciprocalSearch pane
Footer buttons/links

I also made use of the new button size support by setting the primary action in the DAO controller to large and actions rendered in table cells to small.
I also replaced all references to nanopay's ActionView with references to foam's newly updated ActionView.
Screenshots

The approach looks good, added a few thoughts that occured to me while reading.

Has a merge conflict.

Has a merge conflict.

@kgrgreer Resolved


issue#91 Update README.md

@ashwani-rathee Please review my pull request

@Simar05519 some minor issues,other than that looks good to me. @geekquad


https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository

System Health details
System Information

version
core-2024.5.3

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.12.2

os_name
Linux

os_version
6.6.29-haos

arch
aarch64

timezone
Europe/Berlin

config_dir
/config

Home Assistant Cloud

logged_in
false

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 12.3

update_channel
stable

supervisor_version
supervisor-2024.05.1

agent_version
1.6.0

docker_version
25.0.5

disk_total
15.0 GB

disk_used
2.9 GB

healthy
true

supported
true

board
generic-aarch64

supervisor_api
ok

version_api
ok

installed_addons

Dashboards

dashboards
2

resources
0

views
0

mode
storage

Recorder

oldest_recorder_run
May 13, 2024 at 5:19 PM

current_recorder_run
May 13, 2024 at 7:19 PM

estimated_db_size
2.97 MiB

database_engine
sqlite

database_version
3.44.2

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
During thee attempt to install I receive message "https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository"
Reproduction steps

I followed  the install instructions up to nr 4 and received thee error message

...
Debug logs
2024-05-13 21:40:12.189 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/thomluther/hacs-anker-solix repository
2024-05-13 21:40:13.019 INFO (MainThread) [supervisor.store.git] Removing custom add-on repository https://github.com/thomluther/hacs-anker-solix
2024-05-13 21:40:13.023 ERROR (MainThread) [supervisor.store] https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository
2024-05-13 21:40:28.845 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/thomluther/hacs-anker-solix repository
2024-05-13 21:40:29.669 INFO (MainThread) [supervisor.store.git] Removing custom add-on repository https://github.com/thomluther/hacs-anker-solix
2024-05-13 21:40:29.672 ERROR (MainThread) [supervisor.store] https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository
2024-05-13 21:42:19.304 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/thomluther/hacs-anker-solix repository
2024-05-13 21:42:20.116 INFO (MainThread) [supervisor.store.git] Removing custom add-on repository https://github.com/thomluther/hacs-anker-solix
2024-05-13 21:42:20.119 ERROR (MainThread) [supervisor.store] https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository
2024-05-13 21:48:25.462 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/thomluther/hacs-anker-solix repository
2024-05-13 21:48:26.329 INFO (MainThread) [supervisor.store.git] Removing custom add-on repository https://github.com/thomluther/hacs-anker-solix
2024-05-13 21:48:26.331 ERROR (MainThread) [supervisor.store] https://github.com/thomluther/hacs-anker-solix is not a valid add-on repository
2024-05-13 21:49:36.073 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token

Diagnostics dump
No response

Hi
I think this error may happen, don't know why it is triggered. I mentioned that also in the installation instructions.

It was observed that when adding the repository to HACS, an error may occur although it was added. You may check if you can find Anker Solix listed as possible HACS integration to be installed. If not, try to add the repository again.


Allow adding "sudo" users that can authenticate via SSH key

We want some way to create regular users that have sudo access on the server. Ideally we can pass in a list of users with one ore more corresponding SSH keys.
This way we can "share" the server with people so they can do emergency maintenance if necessary.

I think this ticket can be closed now, as the PRs is merged in, the feature is implemented. Any additions or changes could go into new issues, not?


1.0 to 1.2 Upgrade Logic

Summary and Scope
Contains all the logic necessary to make BSS have all the 1.2 things from a 1.0 start.
MTL-1429
Issue Type
Adds all the things for the BSS to be the most happy of services.
Prerequisites

[X ] I have included documentation in my PR (or it is not required)
[X ] I tested this on internal system (x) (if yes, please include results or a description of the test)

Idempotency
You can run this as much as you want, it computes the correct values from the beginning and then pushes those in.
Risks and Mitigations
Shouldn't be any real risk, this is all new.

Needs a rebase and some minor linting fixes, but it otherwise looks good to me. Do we have a ticket for removing existing logic for routes/cloud-init updates from the docs-csm upgrade scripts?

No...and that's a good point, that will need to happen.

Needs a rebase and some minor linting fixes, but it otherwise looks good to me.  Do we have a ticket for removing existing logic for routes/cloud-init updates from the docs-csm upgrade scripts?

There is a companion MTL-1429 docs branch that you can build off of.


Add stats reporting for sidecar and telemetry

Allows to collect stats about the fundamental live datastructures of the sidecar. (like amount of apps, metrics stored, etc.)
This should be the goto tool to diagnose high (or runaway) memory usage of the sidecar.

Agree, interface.rs has grown too big. I'll make sure to split it into multiple modules in a future PR.


fix: use keyword(like: group) as table name in sqlite

Codecov Report
Base: 79.56% // Head: 79.61% // Increases project coverage by +0.04% :tada:

Coverage data is based on head (33d6fcb) compared to base (ad737de).
Patch coverage: 100.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2461      +/-   ##
==========================================
+ Coverage   79.56%   79.61%   +0.04%
==========================================
  Files         599      596       -3
  Lines       49777    49438     -339
==========================================
- Hits        39605    39358     -247
+ Misses       8180     8104      -76
+ Partials     1992     1976      -16

Flag
Coverage Δ

go-1.15-386
?

go-1.15-amd64
?

go-1.16-386
79.61% <100.00%> (-0.01%)
:arrow_down:

go-1.16-amd64
?

go-1.17-386
?

go-1.17-amd64
?

go-1.18-386
?

go-1.18-amd64
?

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

Impacted Files
Coverage Δ

contrib/drivers/sqlite/sqlite.go
71.34% <100.00%> (ø)

os/gcron/gcron_schedule_fix.go
81.81% <0.00%> (-9.10%)
:arrow_down:

net/gtcp/gtcp_pool.go
68.88% <0.00%> (-6.67%)
:arrow_down:

os/glog/glog_logger_rotate.go
61.99% <0.00%> (-1.36%)
:arrow_down:

container/gmap/gmap_hash_str_any_map.go
97.00% <0.00%> (-1.00%)
:arrow_down:

contrib/config/kubecm/kubecm_kube.go

contrib/config/kubecm/kubecm.go

contrib/drivers/oracle/oracle.go

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[SPARK-39562][SQL][TESTS][FOLLOWUP] Use Utils.localCanonicalHostName instead of localHostNameForURI for IP v6 testing

What changes were proposed in this pull request?

This is a followup of https://github.com/apache/spark/pull/36961 , to use a different way to get localhost, so that we can run tests in AWS EC2. The reason is already explained in https://github.com/apache/spark/pull/37377
Why are the changes needed?

run tests on cloud
Does this PR introduce any user-facing change?

no
How was this patch tested?

N/A

cc @dongjoon-hyun @HeartSaVioR

I saw https://github.com/apache/spark/pull/36961#discussion_r954804814 . Merged to master. Thank you all!


fix(scripts): support debian kernel flavors other than normal in falco-driver-loader

What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
What this PR does / why we need it:
Support debian rt and cloud flavors.
See https://github.com/falcosecurity/falco/issues/2625 issue for more info.
Basically, kernel-crawler is going to be fixed to properly output flavored debian kernels, see https://github.com/falcosecurity/kernel-crawler/pull/147.
For Falco 0.35.0, we are only supporting the normal (ie: the one without suffix) kernel flavor; with this patch we will support rt and cloud too.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

fix(scripts): fixed falco-driver-loader to manage debian kernel rt and cloud flavors.

/hold

/milestone 0.36.0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, jasondellaluce
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 [FedeDP,jasondellaluce]

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, incertum, jasondellaluce
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 [FedeDP,incertum,jasondellaluce]

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

/unhold


Instructions to run it locally (Linux)

Hey thanks for such a wonderful work i was looking to generate some puzzles for a dun project i was doing but it seems to not run on my machine please add an instruction to set it up on local machine.
I tried running make but failed with an error this error popped up
~/24puzzle -> master !
❯ make
CC	cmd/pdbstats.c
make: clang: No such file or directory
make: *** [Makefile:85: cmd/pdbstats.o] Error 127

also tried running the shell script gave this error
1 ❯ sudo ./genallpdbs.sh
[sudo] password for ashish:
2021-03-21 01:31:39: Generating all PDBs for 6 tiles to /local/bzcclaus/scratch/pdbs
./genallpdbs.sh: line 49: pdbcount: command not found
./genallpdbs.sh: line 28: genpdb: command not found

Any help will be appreciated

You may need to set the environment variable CC to point to a C compiler.  This usually works:
make CC=cc

Please do not run any of the programs or scripts in the project with elevated privileges (i.e. using sudo).  There is nothing in there that requires that and it's a potential risk in case I made a programming error.  I don't think you have any need to run genallpdbs.sh anyway; this script generates over 160 GB of data and takes several days to complete.  The search programs generate the pattern databases they need whenever they need them, so there's no need to generate all PDBs ahead of time.
If you'll let me know what exactly you are trying to achieve, I may be able to give more specific help.  If you want to generate puzzle instances, use cmd/puzzlegen.  But note that as of now, this program is likely to generate unsolvably hard puzzle instances.  I have not implemented logic to support generation of “easy” instances on command, though I suppose such a thing should be easy to add if desired.

Thanks for detailed information, my basic requirement is to create a game out of these and as you suggested now that the puzzlegen script does not create easy levels i would love to see 4 difficulty levels if possible
namely

Easy
Medium
Difficult
Insane

also if one configuration to generate multiple files at once like if i want to generate 100 puzzles of easy  or
n puzzles of  Medium. I don't know how much effort it is from your side a help would make this repo a playable game.

What is your criterion for considering a puzzle “easy,” “medium,” “difficult,” or “insane?”  Sliding tile puzzles are always rather easy to solve for humans.  The thing that is hard is solving them with the minimal amount of moves needed and humans are really bad at that.

got it so basically we can adjust the difficulty by something called shuffle factor which will determine how strongly the matrix would be shiuffled, i don't whether im correct jere or not but the more randomised the matrix is the more it will be difficult to solve in my opinion.
also an option to generate 4x4, 5x5, 6x6 7x7 would be awesome.

The code in this repository is for 5x5 puzzles only.  I am not sure what this “shuffle factor” is supposed to be exactly.  A simple way to generate random puzzles with an adjustable amount of “shuffledness” is to start with the solved puzzle and then perform a sequence of random moves.  The more moves you do, the more shuffled the puzzle ends up being.  This allows you to generate puzzles up to a difficulty of around 140 moves.  Above that, it's difficult to intentionally find harder puzzles.
I recommend you try implementing that yourself.  It's really not hard to do.  And after all, it's going to be your game, so I don't see why I should do the programming work for you.


More county sets

Adding 3-5 additional pages with different sets of 5 counties shown: e.g., a set with 5 SoCal counties, a set of 5 NorCal counties, and a couple of So/Nor county mixes different from we have now.
These would shown up in the drop down menu of under "County Trends"

PR: https://github.com/damonbayer/uci_covid19_dashboard/pull/8


[suggest]Add another argument to make GodrayFilter support non-parallel light.

GodrayFilter is very amazing , I love it.
But I found that some God ray effects are use non-parallel light.
e.g.

So Could you make GodrayFilter support non-parallel light ,please ?
Or Should we need a new AdvancedGodrayFilter ?

You can make non-linear field here: https://github.com/pixijs/pixi-filters/blob/master/filters/godray/src/main.frag#L18
Also, non-linear fade here: https://github.com/pixijs/pixi-filters/blob/master/filters/godray/src/main.frag#L22

@ivanpopelyshev , thanks. But I'm not good at math , so I don't know how to modify them.
Could you give me more advices ? Thank you very much.

I make it be arc ... tears ...

It's still with arc.
I've given up.

I don't think arc is the right way to go, that's not really how light works, but it's getting closer. We need a way to provide an optional focal/perspective point for the rays. If the point isn't provided, the rays should be parallel.

My math is as weak as my english . I can't do anything for this.  waiting for @ivanpopelyshev .
I know I've wrote some filters .
But the filters I wrote is not difficult in math, there is no any complex mathematical formulae in them.

This would be nice to have, but it's lower priority. There are some other useful filters that would be worth getting in before this, like a better outline, radius blur, etc.


Unable to run tests on Manjaro after upgrading git2 to 0.13.22

Tracing the inability to run tests leads me to believe this is a git2 issue.
I've created https://github.com/rust-lang/git2-rs/issues/746 on their end.
This is mostly for tracking and monitoring the issue.

@sassman: I'm tempted to sugest we degrade git2 back to the previous version.
Not only does the current version cause issues in the integration tests (I for one can't run them at all!), but according th #461 some users can't even run cargo-generate anymore.

Patch is released. But let's keep this issue open as a tracking issue for the dependency that has the problem.

Hey folks,
seems this is not completely solved on Arch.
When I use cargo for the installation (cargo install cargo-generate), the error still shows up.
cargo generate --git https://github.com/rustwasm/wasm-pack-template
⚠   Unable to load config file: /home/user/.cargo/cargo-generate.toml
Error: ⛔   Git Error: invalid version 0 on git_proxy_options; class=Invalid (3)

When I delete cargo-generate from $HOME/.cargo/bin and install it with pacman, it works as expected.
Arch 5.10.68-1-lts
cargo 1.55.0 (32da73ab1 2021-08-23)
cargo-generate 0.10.1
git version 2.33.0

seems we got more insights on #461 so will close this as duplicate of the other.


Cyclic reference of Scene and its Script

Godot version:
3.1
Issue description:
Consider a scene SomeScene.tscn and its script SomeScene.gd.
In 3.0 one could write
const SelfScene = preload("res://SomeScene.tscn")

and use scene instancing in code. But now this is forbidden, and the project doesn't work.
I understand that there is real cyclic dependence, but I did not find anything on how to bypass this problem correctly according to code style guide. I don't want to use load instead of preload because it is slower, and really not needed logically. Several scenes can have the same script, but in real life almost every scene has a unique script resource, and it is convenient to be able to address to self scene in script resource using compiler abilities ( preload).
Steps to reproduce:
Create SomeScene.tscn and SomeScene.gd, attach script to scene then add line to .gd file:
const SelfScene = preload("res://SomeScene.tscn")

As I understood, it was not really supposed to work in 3.0 and it was the source of other bugs which are now fixed in 3.1.
You should indeed use load now. Did you measure its speed? IMO it is not slower, the only difference is when loading will happen, but depending on how you instance this scene in your game, there might not be a difference.

I think it is not comfortable to use. In not all cases You can replace
const SelfScene = preload("res://SomeScene.tscn")

with
var SelfScene = load("res://SomeScene.tscn")

What if there are static functions in script that uses instancing? Then You should write the following to work:
const SELF_SCENE_PATH = "res://SomeScene.tscn"

static func create_and_smth_else(params):
    var instance = load(SELF_SCENE_PATH).instance()

It is rather dirty, I think.

If there are static functions you want to use, you can preload the script, not the whole scene.

Closing in favor of https://github.com/godotengine/godot-proposals/issues/460, as feature proposals are now tracked on the Godot proposals repository.


Automatic swagger conf

Is there any feature to create swagger conf directly from the feathers API?

#68 did add some more intelligence to the default created docs, though it did not add any automatic docs. I think that would need to be integrated into each service type (ie: feathers-sequelize, feathers-elasticsearch, etc), as feathers itself does not know about the structure of the data. Personally, I do have a bit of code for my elasticsearch that generates docs based on the index mappings, though I did not integrate it into the feathers-elasticsearch module.
@daffl Would you be open to adding auto-generating docs to the individual modules when feathers-swagger is in use?

I have a snippet which generates swagger definitions from sequelize models which is run in service definitions. I am willing to participate if this is going forward.

There is now the possibility to adjust the generation for different methods.
And also to generate definitions based on the service (and therefor the connected orm model).
There is space for other orm (or jsdoc) related packages, that create docs properties for services before services are consumed by feathers-swagger.


Fix nil point dereference in notifyEvent

Signed-off-by: Chun Chen<EMAIL_ADDRESS>Don't know how the scenarios mentioned in https://github.com/docker/libnetwork/issues/985 happened.
But I think we should prevent daemon crash.

thanks @chenchun . am always supportive of preventive checks. But @mrjana had some good reasons to leave some of these unprotected. Though it is safe to do nil checks, it would be good to understand the scenario which might have triggered it. @mrjana do you have any suggestions ?

@chenchun I did some more investigation and a defensive check in this case will hide the issue rather than solving the root-cause. The correct fix is to make sure the leave processing happen even if the delete endpoint takes place before the Serf gets a chance to distribute the event to the neighbors.
I am working on the proper fix for this. We can close this PR if we are all happy with my upcoming patch.

@mavenugo Thanks. Your fix makes sense.


Open ListView link in new tab/window

Category
[ ] Enhancement
[ ] Bug
[x ] Question
Version
Please specify what version of the library you are using: [  1.19.0      ]
Expected / Desired Behavior / Question
Is there a way to open a link from the ListView component in a new tab/window by default?  I am able to create the link successfully for the list item by using the linkPropertyName in IViewField but it opens in the same tab as my webpart, which is not ideal.
Thanks in advance,
James

@modern-dev-dude many thanks for the input.
@jduysen were you able to resolve this?

@joelfmrodrigues thanks for following up.  It looks like @modern-dev-dude recommendation will be the solution to this question.
Thanks,
James

@jduysen Glad to help, good luck in your implementation!


Parsing of csv file does not work in Linux

[13:33:38 ERR] Unhandled exception
System.AggregateException: One or more errors occurred. (Input string was not in a correct format.)
---> System.FormatException: Input string was not in a correct format.
at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, TypeCode type)
at CsvPowerToTemp.PowerReadingProviders.ReadFromCsvFilesInCurrentFolder.GetPowerReadings(String[] args)
at CsvPowerToTemp.Program.<>c__DisplayClass4_0.<b__1>d.MoveNext() in /home/runner/work/CsvPowerTemperature/CsvPowerTemperature/Program.cs:line 48
Probably caused by cultural  environment values (float)

Note to self: use Path.GetFileName(file).Split("_"); because the file name may contain the whole path

Actual root cause: "_" if the path mixed up the year parsing from file name...


extract_multiple doesn't always extract as many variations as requested

Even if more exist as evidenced by testing via egraph.check. I can try to dig up a MWE if needed.

Ah right, this is a known behavior of egglog's variant extraction. To give some background, the feature is ad hoc and was initially developed to just sample a set of expressions from the database for debugging. AFAIR, the implementation tries to cover a diverse set of represented expressions (for debugging purposes) so it skips some expressions during the extraction, which causes the behavior described in this issue.

Would it be useful to have something that works as I expected it to :D ?

Definitely! It would be cool if extract-variants could recur after exhausting all of the enodes at the top level.


Hide averages and SD when cards have non-numeric names

Atm it shows null which doesn't look as polished

SD and averages are no longer used


changelog_from_git_commits fix from command line

fixes: https://github.com/fastlane/fastlane/issues/10894

@joshdholtz This is ready for review. 👀

@joshdholtz all the comments are addressed. Ready to review again. 👍

Just wanted to explain what we are doing here incase. The between option now takes both array of string and string with comma in it.

Nice one @RishabhTayal!


Patterns: All patterns not required to bind ident

It should be required that all patterns in a series bind the same identifiers. This means that the following should fail to compile because the left pattern is missing the binding b and the right pattern is missing the binding a.
case x {
   a @ 1 | b @ 2 -> a,
}

This should be caught by a step in between parsing and execution.

Fixed as of 45be271e701a3d5fa2b9aed50214f3bbd783a8b2


[Suggestion] Overwatch name revealer

A funtion which allows us to see the name of the suspect in the overwatch case.
I just saw that function in a video of bhop and it was kinda cool to see if the suspect gets banned or nah.

Most of my OW Cases are not players I played against with. Because this is against the independent judgment.
But I saw suspects from my other Accounts where I played against the suspect in a game. But I never judged a game where I played against the suspect myself! This is useless!

You can use wireshark to find their profiles, its also kind of a useless feature tbh.

I've added some prototype revealer. It would be great if you could test it (it is enabled by default).


Make it easier to run the dart executable

Required to run things like source_gen generators.
https://github.com/flutter/flutter/issues/13360 deals with pub run. This is just getting access to the dart command to run things not in the bin directory.
Here's the draft text I've included in json_serializable – which is pretty gnarly.

NOTE: If you're using Flutter, running a Dart script is a bit tricky. You can
find the Dart entry point at $FLUTTER_ROOT/bin/cache/dart-sdk/bin/dart.
You can determine FLUTTER_ROOT by looking at the first few lines of
flutter doctor.
> flutter doctor
[✓] Flutter (on Mac OS X 10.12.6 16G1114, locale en-US, channel master)
    • Flutter at YOUR_FLUTTER_ROOT_HERE
    • Framework revision 235b64ed2f (13 hours ago), 2017-12-14 20:38:39 -0800
...

CC @sethladd @mit-mit

Strawman: flutter cmd <path_to_cli_script> which simply runs the script via the same Dart version that is used in the engine (so the API in docs.flutter.io applies to scripts run via the Flutter cmd line. I don't want "two darts" for Flutter developers, there is one Dart for Flutter developers: the Dart that is documented on docs.flutter.io)
In the meantime, could source_gen ship a generic runner accessible from pub run ?

Strawman: flutter cmd <path_to_cli_script>

SGTM...

In the meantime, could source_gen ship a generic runner accessible from pub run ?

Sadly, no. We're working on a solution w/ pkg/build where there will be a common entry point. Hoping to have that nailed down in Q1.

Would a more idea solution be some way to register (maybe in pubspec.yaml, that flutter should execute some dart "script" during build? Then you wouldn't need to remember to manually run the generators?

That'd be good, too... We'd want to start talking about a real design at
that point...
On Mon, Dec 18, 2017 at 8:10 AM, Michael Thomsen<EMAIL_ADDRESS>wrote:

Would a more idea solution be some way to register (maybe in pubspec.yaml,
that flutter should execute some dart "script" during build? Then you
wouldn't need to remember to manually run the generators?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/13607#issuecomment-352473356,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABCilMzBf-metyvWioaobf2F-clKeQoks5tBo6FgaJpZM4RDynL
.

Closing as pub can run dart scripts, and because we'll likely use a different solution for build_runner integration.

Also, note that I recently added passthrough for all pub commands, so the current shortest way of doing this is:
flutter pub run tool/build.dart


parameter   network-caching   do not function

I have an issue / a question (pick one) about Vlc.DotNet.
I try to insert the parameter following
:network-caching=20
but   do not function, I have a delay about 1000 ms
Generic information

Vlc.DotNet version : 3.1
Vlc.DotNet project used : (WinForms
libvlc version : (/x64)
.net version : 4.7.2
Project language : (C#/VB.net)
Project build architecture : (x86/x64/AnyCPU/AnyCPU (prefer 32bits))
Operating system : (Windows ...) (x86/x64)

Summary
(What happens, when, how? Steps to reproduce (with sample codes))

[x] I confirm that my issue doesn't happen in VLC itself. With VLC with :network-caching=20  I don't feel dalays

This has nothing to do with Vlc.DotNet. Please try with the same VLC version than your libvlc.
VLC 2.x indeed honored that value for very small values of network-caching, but that's not the case with VLC 3.x.
Delays with VLC is a well-known issue.

This has nothing to do with Vlc.DotNet. Please try with the same VLC version than your libvlc.
VLC 2.x indeed honored that value for very small values of network-caching, but that's not the case with VLC 3.x.
Delays with VLC is a well-known issue.

VLC is 3.0.10
libvlc il <IP_ADDRESS>
i think they are really similar, but the behaviour isn't
it is my opinion that the options do not are taken by the software.
can you suggest me an option to use to test  if the functionallity is correct?
In any case I write also the code I wrote to define the VlcMediaplayerOptions :
this.vlcControl1.Text = "vlcControl1";
this.vlcControl1.VlcLibDirectory = null;
this.vlcControl1.VlcMediaplayerOptions = new string[] {
":network-caching=20",
":file-caching=20"};
this.vlcControl1.VlcLibDirectoryNeeded += new System.EventHandler<Vlc.DotNet.Forms.VlcLibDirectoryNeededEventArgs>(this.vlcControl1_VlcLibDirectoryNeeded);
//

VLC is 3.0.10
libvlc il <IP_ADDRESS>
i think they are really similar, but the behaviour isn't
it is my opinion that the options do not are taken by the software.
can you suggest me an option to use to test  if the functionallity is correct?
In any case I write also the code I wrote to define the VlcMediaplayerOptions :
this.vlcControl1.Text = "vlcControl1";
this.vlcControl1.VlcLibDirectory = null;
this.vlcControl1.VlcMediaplayerOptions = new string[] {
":network-caching=20",
":file-caching=20"};
this.vlcControl1.VlcLibDirectoryNeeded += new System.EventHandler<Vlc.DotNet.Forms.VlcLibDirectoryNeededEventArgs>(this.vlcControl1_VlcLibDirectoryNeeded);
//

use -- for VlcMediaPlayerOptions, and IIRC, the key and value must be in two different strings, like "--network-caching", "20",

use -- for VlcMediaPlayerOptions, and IIRC, the key and value must be in two different strings, like "--network-caching", "20",

use -- for VlcMediaPlayerOptions, and IIRC, the key and value must be in two different strings, like "--network-caching", "20",

I tried
var vlc = new VlcControl();
var vlc_options = new string[] { "--demux", "h264", "--udp-caching", "0", "--tcp-caching", "0", "--realrtsp-caching", "0", "--network-caching", "0", "--no-ts-trust-pcr", "--sout-ts-shaping", "10", "sout-ts-dts-delay", "20" };
vlc.Play(new MyStream(socketVideo), vlc_options);

but it not works, always 2s delay

Please read my other statement that VLC 3 doesn't honor the low values of network-caching.
libvlc4 will have a low-delay option (but libvlc4 will not be compatible with vlc.DotNet)
As a rule of thumb, try with VLC and if it doesn't work either, it's not an issue with this project


Cartesian undersampling for 2D

Hi,
I'm an absolute Bart newbie.
I was wondering, whether it is possible with Bart to create 2D cartesian undersampling patterns.
What I mean by that are masks, e.g. like those in Figure 5 in this paper: https://arxiv.org/abs/1811.08839
I am only aware of the tools: poisson & traj. Both seem to have a different purpose.
Could you explain either: How to create such masks or if there is a reason (other than time) why it is not implemented, if not?
Thanks a lot in advance,
Georg
PS:
Also, Idon't know whether this is the most appropriate place to ask such questions. Hint for other ways of asking questions are appreciated as well.

Hi Georg,
such questions are better placed on the mailing list:
https://lists.eecs.berkeley.edu/sympa/info/mrirecon
as a question is not an issue with bart.
As to your question: for regular Cartesian undersampling, there is upat. However, in the paper you linked, they are using random Cartesian undersampling in 1D. For this, I think the only way to do it with bart tools is using poisson with bart poisson -Z1 (so, setting one of the dimensions to 1), and then adding a calibration region by hand.
If you want more specific answers, please use the mailing list.
Best regards,
Christian


Remove all non-boilerplate code

This is to allow the creation of a follow-up PR that re-adds all of this code in order to facilitate a code review.

Closing this because no changes were requested in the review


397 line breaks in md

How we like this?

Sorry I missed this before merge, though one review and David's approval should certainly suffice. If we haven't already done this, we could search through all markdown files in the codebase for HTML tag characters (e.g. the closing </ or a full regex to be more robust) via the command line to ensure we haven't let any slip through the net.


Updated Readme 2.1

@raunakkumar ,Shanbhag, PAVAN Subbayya please review
Added documentation for helm chart upgradation from 2.0.0 to 2.1.0

Submitted a PR here to ensure users won't get ahead of themselves.

Should I close this PR ?

Submitted a PR here to ensure users won't get ahead of themselves.

Should I close this PR ?

If you merge my PR into your private branch you can push the commit into this PR.

Submitted a PR here to ensure users won't get ahead of themselves.

Should I close this PR ?

If you merge my PR into your private branch you can push the commit into this PR.

Done

@Raunak , @datamattsson Please do not merge this PR , till we get confirmation from test team and Pradip

We can merge this PR if looks good
Got confirmation from test team , we can go ahead with this change


Replace template components with spin-off

Fixes #11105
Please check the following:

[ ] Do the tests still pass?[^1]
[ ] Does the code comply with the style guide?

[ ] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?
[ ] For front-end changes: Did you test on all of Wagtail’s supported environments?[^2]

[ ] Please list the exact browser and operating system versions you tested:
[ ] Please list which assistive technologies [^3] you tested:

[ ] For new features: Has the documentation been updated accordingly?

Please describe additional details for testing this change.
This PR replaces the "template components" previously found in wagtail.admin.ui.components and the related template tags in wagtail.admin.templatetags.wagtailadmin_tags with imports from the Laces package. Laces was created to make the "template components" idea available to the wider Django eco-system.
To avoid the need to update all usage locations in Wagtail and save people from having to add Laces to their installed apps, the previous implementations are replaced with imports from Laces.
[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target

Thanks @tbrlpld - I have flagged for review. Looks pretty straight forward, just wondering if it's worth us keeping a simple set of TestComponentTag tests. While we can trust this package we do want to also ensure that the basics keep working with our wrapper.
It might be best for @gasman  to take a look at this one, I have requested a review.

Thanks @tbrlpld - I have flagged for review. Looks pretty straight forward, just wondering if it's worth us keeping a simple set of TestComponentTag tests. While we can trust this package we do want to also ensure that the basics keep working with our wrapper.
It might be best for @gasman to take a look at this one, I have requested a review.

Happy to bring the template tag tests back if that is desired.

As part of the adoption of this, I know there will be a mention in the release notes, but will there also be a deprecation timeline to drop the shadowed names and require implementers to switch to the new paths?

I am not aware of any deprecation plans for the internal names, but maybe someone else can say more here.

I think for now we would keep the internal Wagtail names as part of this PR, if we do consider a deprecation process we would probably start that closer to a 7.0 release. As with any rename, there would be ample time across multiple releases to change any code that uses this.
For this specific case, it may make sense to always keep the template name redirects for convenience.

If we were to switch to using the laces tag library directly rather than 'proxying' it through wagtailadmin_tags, then we'd need everyone to add laces to INSTALLED_APPS - I don't think that's desirable for something that's only used internally within Wagtail.

Merged in 10c1e12285929624aab20207f8afb609b850a886


Error when used with new VS2017 projects

In VS2017 a new .csproj format is introduced, which currently fails to build in sharpDox. I suspect updating the Microsoft.CodeAnalysis packages to v2.0.0 will solve this issue.
Error:
Starting step: "Parsing project file"
Starting step: "Parsing code"
Could not build documentation.
System.AggregateException: One or more errors occurred. ---> Microsoft.Build.Exceptions.InvalidProjectFileException: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Construction.ProjectParser.Parse()
   at Microsoft.Build.Construction.ProjectParser.Parse(XmlDocumentWithLocation document, ProjectRootElement projectRootElement)
   at Microsoft.Build.Construction.ProjectRootElement.Create(XmlReader xmlReader, ProjectCollection projectCollection)
   at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectFileAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<LoadProjectAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<GetOrLoadProjectAsync>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<LoadSolutionInfoAsync>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.<OpenSolutionAsync>d__18.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at SharpDox.Build.Roslyn.RoslynLoader.LoadSolutionFile(String solutionFile)
   at SharpDox.Build.Roslyn.RoslynParser.GetParsedSolution(String solutionFile, ICoreConfigSection sharpDoxConfig, Dictionary`2 tokens, Boolean parseMethodCalls, Boolean ignoreExcludes)
   at SharpDox.Build.Context.Step.ParseCodeStep.RunStep(SDProject sdProject)
   at SharpDox.Build.Context.BuildContext.StartBuild()
---> (Inner Exception #0) Microsoft.Build.Exceptions.InvalidProjectFileException: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Construction.ProjectParser.Parse()
   at Microsoft.Build.Construction.ProjectParser.Parse(XmlDocumentWithLocation document, ProjectRootElement projectRootElement)
   at Microsoft.Build.Construction.ProjectRootElement.Create(XmlReader xmlReader, ProjectCollection projectCollection)
   at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectFileAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<LoadProjectAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<GetOrLoadProjectAsync>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.<LoadSolutionInfoAsync>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.<OpenSolutionAsync>d__18.MoveNext()<---

Thanks for the information! Will try to fix this today!

Having problems with the MSBuild Tools at the moment. As soon as I can fix this, I will release a new version of sharpDox!

I released a new Version of sharpDox today! Please find it here https://github.com/geaz/sharpDox/releases/tag/v1.2.2
Tried a fresh VS2017 Project with no problems 👍


new feature inlineFilter for Grid

you can use
show:
{
showInlineFilter:true
}

Thank you for your contribution, however, I cannot yet accept this commit. Your pull request should only have "src/w2grid.js" files included. The rest are not needed. Plus, there are some "code standards" issues. Like, I want to have spaces after ":" and "if", not double lines, see https://github.com/vitmalina/w2ui/wiki/Contribution-Requirement

Closing due to inactivity


http://ivy.et-engine.com/testing_grounds/import is broken

I don't know how but I might have broken it by defining a new topology :worried:

Did you rename the default topology? It used to be defined in a YAML file, but has apparently been moved into the database and must be called "Default topology".

That's probably what happened yes... I'll fix it tomorrow. Thanks!

Fixed. Closing.


ArduCAM_Mini_5MP_Plus_OV5642_RAW.ino fails to compile/verify

The example ArduCAM/examples/mini/ArduCAM_Mini_5MP_Plus_OV5642_RAW/ArduCAM_Mini_5MP_Plus_OV5642_RAW.ino   fails to compile/verify because the method OV5642_set_RAW_size() does not exist.

@jason66
Hi,
Very sorry for our library's bugs after updated.We are optimizing our library.

Is there an updated library to address this issue?
I'm also looking to get RAW data from OV2640.

@jason66
At present, ArduCAM library has support ov5642 RAW format and don't support OV2640 RAW format.


Improve Ticker lookup functionality (asset type? expense ratio? name?)

Lookup one at a time for entry, and for account import, determine need for one at a time or bulk lookup?

Consider collecting info from community as part of their imports from csv files??


slow notification

hellow!
what can cause the slow delivery of the notifications?
is there somehow to optimize?
sometimes messages don't get delivered on ios device too :(

File a support issue at https://firebase.google.com/support. They can help you figure out what's going on.

thank you @hiranya911


Add API level security options

Still need to add operation level security options as well, can be done in a future PR.

Codecov Report

Merging #60 (95a77ed) into develop (9a19c5d) will increase coverage by 0.87%.
The diff coverage is 88.23%.

@@             Coverage Diff             @@
##           develop      #60      +/-   ##
===========================================
+ Coverage    77.15%   78.03%   +0.87%
===========================================
  Files           37       38       +1
  Lines         1598     1662      +64
===========================================
+ Hits          1233     1297      +64
+ Misses         312      310       -2
- Partials        53       55       +2

Flag
Coverage Δ

unittests
78.03% <88.23%> (+0.87%)
:arrow_up:

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

Impacted Files
Coverage Δ

resources/manager.go
34.54% <ø> (ø)

resources/api.go
81.34% <85.71%> (+11.83%)
:arrow_up:

resources/options.go
100.00% <100.00%> (ø)

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 41f736a...95a77ed. Read the comment docs.


Update slip10

Warning should be nicely rendered on docs.rs, something like that: https://rustdoc.crud.net/imperio/warning-block/foo/struct.Foo.html

What about writing a migration guide? Shouldn't be too big. I can write it if you're busy

We should probably put a guide into m, not into legacy/slip-10 branch?

I think the guide should be in https://docs.rs/slip-10 and on the crates.io page, and github is not as important as it's already one repo

Added a guide @maurges

This is how it's rendered in docs:


Confusing error (or lack thereof) when coordinate and variable share the same name

It probably makes sense to prevent dataset to have variables sharing the names of coordinates (what would dataset.varname return?) but currently
Dataset({"a": DataArray(np.zeros((3, 4)), dims=["a", "b"],
                        coords={"a": list("xyz"), "b": list("xyzt")})})

fails with ValueError: an index variable must be defined with 1-dimensional data, and
Dataset({"a": DataArray(np.zeros(3), coords={"a": list("xyz")})})

actually creates an empty dataset using [0, 0, 0] as values for the a coordinate instead of x y z:
<xray.Dataset>
Dimensions:  (a: 3)
Coordinates:
  * a        (a) float64 0.0 0.0 0.0
Data variables:
    *empty*

Oh my, this certainly does look like a bug (or several).

This is related to #457. In the first case, I think that the error message must be improved, but I do not think that Error is itself is a bug. From the netCDF data model point of view, it does not make sense to define a two dimensional variable sharing the name with a one-dimensional coordinate.
The second example does look like a bug, as it should raise an error too, in my opinion, as the function Dataset is given contradictory information (two different sets of values for the same variable "a"). In netCDF files you cannot have two variables with the same name, and coordinate variables are just regular variables.

Yes, @markelg I think you describe each of these issues correctly. They should each result in more informative errors.

The first example here was fixed in #1539.
The second issue still exists but now requires dims to be specified explicitly.
In [9]: Dataset({"a": DataArray(np.zeros(3), dims='a', coords={"a": list("xyz")})})
   ...:
   ...:
Out[9]:
<xarray.Dataset>
Dimensions:  (a: 3)
Coordinates:
  * a        (a) float64 0.0 0.0 0.0
Data variables:
    *empty*

Do we agree it is safe to say that no key should be repeated between data and coords?

Adding a v confusing error message which my colleague just hit (not exactly the same as this, but thought it wasn't worth a whole new issue):

In [10]: xr.DataArray(
    ...:     data=1,
    ...:     coords={
    ...:         'test':[1]#,
    ...:     },
    ...:     dims=['test']
    ...: )
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-10-41a019d49aae> in <module>
      4         'test':[1]#,
      5     },
----> 6     dims=['test']
      7 )

~/workspace/xarray/xarray/core/dataarray.py in __init__(self, data, coords, dims, name, attrs, encoding, indexes, fastpath)
    228
    229             data = as_compatible_data(data)
--> 230             coords, dims = _infer_coords_and_dims(data.shape, coords, dims)
    231             variable = Variable(dims, data, attrs, encoding, fastpath=True)
    232

~/workspace/xarray/xarray/core/dataarray.py in _infer_coords_and_dims(shape, coords, dims)
     76
     77         for d, s in zip(v.dims, v.shape):
---> 78             if s != sizes[d]:
     79                 raise ValueError('conflicting sizes for dimension %r: '
     80                                  'length %s on the data but length %s on '

KeyError: 'test'

...nothing to do with the test entry, it's that data is a scalar

All given examples work in recent xarray 2024.10.0. Please reopen with updated examples, if this is still an issue.


pyTMD.compute.tide_currents needing both u_* and v_* rather than only u_*

Hi,
following up on my last post, I basically went around by cloning and installing 2.1.1.
Anyway, when I try to use:
pyTMD,compute.tide_currents
it asks for separate u_* and v_* input files (the several ones for the different constituents).
In the database that I have, both the OTIS and netcdf, I only have h_* and u_, and when I asked Dr. Erofeeva, she told me that the u_ contains both the eastward and northward components of the tidal currents, so there should  be no need for two separate input files?
As a patch in the short term, can i simply dubplicate and rename the u_* files into the v_*, or this would mess up something?
And a quick question: the results are in m/s, right?
Many thanks
Maurizio

I believe I that is for backwards compatibility for when TPXO9-atlas models had served the u and v currents in separate files (see #258). I only have access to the binary (OTIS) file type, so I don't know how the netCDF files are currently provided. I can edit the io.model class for TPXO9-atlas-v5 if each netCDF4 file provides both the zonal and meridional currents.
In the compute.tide_currents function, the binary OTIS file type only reads from the u part of the dictionary. So in the mean time, using the binary files should (hopefully) work fine.

Many thanks, @tsutterley , for helping with this.
Unfortunately, I changed the setting to ATLAS_FORMAT='OTIS'. and it is still looking for the "v_*" types as well, more precisely in:
pyTMD\io\model.py:842 in current
I was trying to identify, in the code, where it actually reads the two components of the velocity, but got a bit lost ;).
Many thanks for the help with this.
Kind Regards
Maurizio

you're right that is a problem. It's in the pathfinder function within the io.model class. There's a file check to make sure everything exists. I need to fix this.

I'm working on this now. Can you verify for me that the TPXO9-atlas-v5 netCDF4 files have both components?

I checked, and it seems so.
I quickly did a data = ncinfo('u_2n2_tpxo9_atlas_30_v5.nc') in MATLAB, and in data.Variables I can see:

uRe
uIm
vRe
vIm
so I suppose these are the real and imaginary parts of the u and v velocities.
I'm checking tha tthe same can be seen in python

Perfect thanks! I'll get this in as part of a PR I started earlier and will put out a release today. Thanks for your help on this. I don't really work with the current files.
And, yes. Those are the real and imaginary parts of the current constituents.

Well, you're more than welcome, but it is I that should thank you for the quick reaction!
I suppose the results are in meter per seconds, right?

should be in cm/s

This is all in the recently released v2.1.1. Thanks for your help on this!
-ts

Hi, apologies for the "noob" question - but would be 2.1.1 available through the install mode "conda install -c conda-forge pytmd", or do I need to do the git and then python setup.py install? I tried both, but i do not seem to be able to use the new version....

I think you should be able to do either (depending on your current installation):
conda update pyTMD
or
pip install --upgrade pyTMD
as both of the providers (conda-forge and pypi) are up-to-date with v2.1.1.

Which version of python is necessary?

We test against Python 3.11 and I currently run Python 3.12. But on my old machine I was running an earlier version of python3. I think I have included the imports necessary for earlier versions to work (from 3.6+).

It works! Many thanks.


Add LICENSE file with licensing info to repository

Could you please add a license file, i.e. with MIT License, to the repository so people interested in the paper can safely reference the code?
Thanks :)

Hi,
Thank you for noticing a missing license file.
I have added it to the repo now.
Cheers,
Aakash


Documentation for next('route') with app.use

Hello,
your documentation of app.use says that next('route') can be used with app.use, however, this has no effect. Please change the docs or the behavior (I'd prefer the behavior). This is confusing not only to me.
The API even uses the same sentence for app.use, app.all, app.delete, app.get, app.METHOD, app.post and app.put:

You can provide multiple callback functions that behave just like middleware, except that these callbacks can invoke next('route') to bypass the remaining route callback(s). You can use this mechanism to impose pre-conditions on a route, then pass control to subsequent routes if there is no reason to proceed with the current route.

Another quote from #3133: (actual behavior)

the next() and next('route') have no difference to app.use

If you change the docs, please specifically mention that next('route') doesn't work.

Hi @mik-jozef please file issues for our documentation at https://github.com/expressjs/expressjs.com (and you can even make edits there as well, which we can directly accept).
As for your link to an SO post, the issue there is that was answered in 2013, and the answer is written for Express 3.x, not 4.x, which I assume is what you're using. The semantics around app.use and the underlying router were changed between those versions, making the answer no longer correct for the 4.x series.
As for changing the behavior, the reason for the limitation is because it's not possible to implement without designing the way the whole middleware system works. If you think there is a good way to go about it, please feel free to write up a detailed description for what the implementation would look like or even toss a pull request our way with an implementation :)


@GetAntiXsrfRequestToken()

how to access '@GetAntiXsrfRequestToken()' from external js file?

@pethumishara to access .NET values from an external js file, you generally need to either use MVC to write the value to a JS variable from an MVC view (eg: <script>var token='@GetAntiXsrfRequestToken()'</script>)  or provide an endpoint to access the value (which is not likely to work in this scenario)


Minor edit

Reference Issues/PRs
What does this implement/fix? Explain your changes.

Discord badge added
Minor edits

Any other comments?

Codecov Report

Merging #63 (52fe4ca) into dev (a13bde6) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #63      +/-   ##
==========================================
+ Coverage   96.40%   96.42%   +0.02%
==========================================
  Files           2        2
  Lines         194      195       +1
  Branches       22       22
==========================================
+ Hits          187      188       +1
  Misses          4        4
  Partials        3        3

Impacted Files
Coverage Δ

nafas/functions.py
95.31% <100.00%> (+0.04%)
: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 a13bde6...52fe4ca. Read the comment docs.

@sadrasabouri Please review this PR, if everything is okay Squash/Merge it after approval 🚀

Take a deeper look at the discord links, badges, and server-id


Unable to sign in - the user is not licensed for MAM

Hi,
I signed up for an Intunes trial licence (30 days), and now I'm trying to run this example app but the authentication does not seem to work. I'm getting this error message:
"The operation could not be completed because the user is not licensed for MAM."
The error occurs after this is called in the LoginPage:
IntuneMAMEnrollmentManager.instance().loginAndEnrollAccount(nil)
I double checked in the Microsoft Endpoint Manager Endpoint manager, and the user indeed has an Intune license.
Do you know what else can cause that error message?
Thanks,
Henrik

Ok, my bad. For some reason I missed issue #51. I will try to perform the steps suggested there, and let you know if that works. Kind of a misleading error message though?

Hi Kyle,
For some reason today, it actually started working. Now the problem is that I'm not exactly sure why :/
But earlier, yes I was prompted for credentials.
I'm on a 30 day trial at the moment. Since I started testing the user I'm using has always had a license.
I first started with my own app based on what I could find in the documentation, but then switched to your example (with the same user).
I'm sorry I could not give more specific details.

Hi,
I am also having the same problem and resetting simulator is not helping either.
Details as follows:
The setup:

User has following Intune licenses
** Intune -> Microsoft Intune
** Enterprise Mobility + Security E5 -> Microsoft Intune
The user is on 30 day trial Intune instance
Nuget Package: Microsoft.Intune.MAM.Xamarin.iOS - <IP_ADDRESS>

This is what user actions and observes:

App starting in iOS 15.0 simulator
Click on Login
For very first time, user is prompted for user+password
Upon auth window closing, a message is displayed - "Enrollment Failed", "The operation could not be completed because user is not licensed for MAM"

What I have tried so far but didn't help

I have created a new user with new license applied but still gets the same message
Reset the emulator

Please let me know if I have to report this as a new issue.

I am having the same issue.

Anyone resolved this since?

I am facing the same issue here too.

@Kyle-Reis @msft-neiljac Can this be re-opened or should I open a new support case? It looks like lots of people are encountering the same problem. Thanks


fix(index): do not delete options

The deletion of the options object causes
them to be undefined for subsequent uses
of the loader.
Closes https://github.com/postcss/postcss-loader/issues/207

This also fixes the issue that the postcss.config.js can not be found when setting the path via the options.config.path property.

Thx for quick PR 😛 , but already done in https://github.com/postcss/postcss-loader/commit/c4f006472a85d3bc36ae3f2f0e750291fd732b7b


builder: confd[80]: ERROR exit status 123

This seems to be an issue with the check-repos script after being templated out for the first time. After turning on debug mode for confd, I see:
2015-03-26T18:45:12Z 9ed07977d848 confd[80]: DEBUG Overwriting target config /home/git/check-repos
2015-03-26T18:45:12Z 9ed07977d848 confd[80]: DEBUG Running /home/git/check-repos
2015-03-26T18:45:12Z 9ed07977d848 confd[80]: ERROR exit status 123

So there's probably some precondtion that's causing this exit code, but it seems fine after the first time.

note that the hack in #3408 will probably fix this as well, since check-repos is called on reload: https://github.com/deis/deis/blob/master/builder/image/conf.d/check-repos.toml#L11

note that the hack in #3408 will probably fix this as well

Yes, except in that case it's /home/git/check-repos that has itself as its own check_cmd script. I'll make a similar PR for that one.

In this case, it's because of these lines in check-repos:
docker images | grep $appname | awk '{ print $3 }' | xargs docker rmi -f
docker images --filter "dangling=true" | awk '{ print $3 }' | grep -v IMAGE | xargs docker rmi -f

docker images may return nothing, and docker rmi returns 123 if not given any further arguments. We can fix this by using xargs -r, so that the target command is never run unless there are arguments for it. xargs default is to run once regardless.


Client crash, playing on a server Aof v4.1.1

Shift clicking an item to reveal what the enchant does crashes the client.
Crash report: https://pastebin.com/idcBhawV
All of Fabric version: 4.1.1
Your mod version 1.0.2. (Is 1.0.3 fixing this?)

Doesn't seem to be your mod.


kanidm: 1.2.3 -> 1.3.2

Description of changes
https://github.com/kanidm/kanidm/releases/tag/v1.3.0
https://github.com/kanidm/kanidm/releases/tag/v1.3.1
https://github.com/kanidm/kanidm/releases/tag/v1.3.2

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Looks like the test is broken.

Looks like the test is broken.

No, ofborg just struggles with these tests.
I’m also inclined to remove the security flag since the issue was introduced in 1.3.0 so we’ve yet to ship the affected version.

The test run from x86_64
/nix/store/cf9q5iqz1sfx6h6plqmbrwqmdngl73p2-vm-test-run-kanidm


Core 600S Support

@browningb you need to open an issue using the model from issues -> bug report with the logs from homebridge in order to add support

I made some research and it looks similar to 400S so i can add the support for it, but it will be great if you can provide some logs