error reading configuration from system.yam

From a clean installation everything looks fine:

database connection is good
tables are created
permissions looks good

system.yaml:
`
shared:
database
type: mssql
driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
url: jdbc:sqlserver://TD0745.res.bec.dk;instanceName=TDSQL0745;databasename=D00011TD00_MKT_ArtifactoryDev;sendStringParametersAsUnicode=false;applicationName=Artifactory
username: ARTIFACTORY
password: xxxxxx
`
and then in the end, this error which makes no sense, since there are several logs stating it can read the database properties just fine:

artifactory-dev    | error reading configuration from system.yaml : reading db properties failed: could not derive db properties from system yaml: Type: , Url: : Could not set db properties to application configuration: could not derive dbname/hostname from jdbc url
artifactory-dev    | goroutine 1 [running]:
artifactory-dev    | runtime/debug.Stack(0x10, 0x10, 0xc000126a40)
artifactory-dev    |    /src/runtime/debug/stack.go:24 +0x9d
artifactory-dev    | jfrog.com/metadata/common/log.(*standardLogger).Panicfc(0xc0000beb78, 0x14f8be0, 0xc000202960, 0x12bb292, 0x31, 0xc000126a40, 0x1, 0x1)
artifactory-dev    |    /src/jfrog.com/metadata/common/log/standard_logger.go:44 +0x6a
artifactory-dev    | jfrog.com/metadata/services/common.(*configBearer).ValidateConfig(0xc00048ecd0, 0x14f8be0, 0xc000202960, 0x1508f00, 0xc0000beb78)
artifactory-dev    |    /src/jfrog.com/metadata/services/common/config_bearer.go:176 +0x245
artifactory-dev    | main.main()
artifactory-dev    |    /src/jfrog.com/metadata/metadata.go:28 +0x349
artifactory-dev    |
artifactory-dev    | panic: error reading configuration from system.yaml : reading db properties failed: could not derive db properties from system yaml: Type: , Url: : Could not set db properties to application configuration: could not derive dbname/hostname from jdbc url
artifactory-dev    | goroutine 1 [running]:
artifactory-dev    | runtime/debug.Stack(0x10, 0x10, 0xc000126a40)
artifactory-dev    |    /src/runtime/debug/stack.go:24 +0x9d

The entire log file:
'
LOG

Attaching to artifactory-dev, nginx-dev
artifactory-dev    | Preparing to run Artifactory in Docker
artifactory-dev    | Running as uid=0(root) gid=0(root)
artifactory-dev    | Dockerfile for this image can found inside the container.
artifactory-dev    | To view the Dockerfile: 'cat /docker/artifactory-pro/Dockerfile.artifactory'.
artifactory-dev    | Resolved shared.database.type (mssql) from /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | Resolved shared.database.url (jdbc:sqlserver://TD0745.res.bec.dk;instanceName=TDSQL0745;databasename=D00011TD00_MKT_ArtifactoryDev;sendStringParametersAsUnicode=false;applicationName=Artifactory) from /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | Waiting for DB mssql to be ready on jdbc/sqlserver///TD0745.res.bec.dk;instanceName=TDSQL0745;databasename=D00011TD00_MKT_ArtifactoryDev;sendStringParametersAsUnicode=false;applicationName=Artifactory for 30 seconds
artifactory-dev    | 2020-05-15T17:25:51.000Z [shell] [INFO ] [] [systemYamlHelper.sh:292       ] [main] - Resolved shared.database.type (mssql) from /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | 2020-05-15T17:25:51.000Z [shell] [INFO ] [] [systemYamlHelper.sh:292       ] [main] - Resolved shared.database.url (jdbc:sqlserver://TD0745.res.bec.dk;instanceName=TDSQL0745;databasename=D00011TD00_MKT_ArtifactoryDev;sendStringParametersAsUnicode=false;applicationName=Artifactory) from /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | 2020-05-15T17:25:51.000Z [shell] [INFO ] [] [systemYamlHelper.sh:292       ] [main] - Resolved shared.database.password (sensitive_key_hidden_) from /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:1162       ] [main] - Checking open files and processes limits
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:1165       ] [main] - Current max open files is 32000
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:1176       ] [main] - Current max open processes is 65535
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:1243       ] [main] - Testing directory /opt/jfrog/artifactory/var has read/write permissions for user id 0
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:1258       ] [main] - Permissions for /opt/jfrog/artifactory/var are good
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:2721       ] [main] - Setting JF_SHARED_NODE_ID to 3762da9ee54b
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:2721       ] [main] - Setting JF_SHARED_NODE_IP to <IP_ADDRESS>
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [installerCommon.sh:2721       ] [main] - Setting JF_SHARED_NODE_NAME to 3762da9ee54b
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [artifactoryCommon.sh:104      ] [main] - Final command: -server -Xms512m -Xmx2g -Xss256k -XX:+UseG1GC -XX:OnOutOfMemoryError="kill -9 %p" --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.text=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.desktop/java.awt.font=ALL-UNNAMED -Dfile.encoding=UTF8 -Djruby.compile.invokedynamic=false -Djruby.bytecode.version=1.8 -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true -Djava.security.egd=file:/dev/./urandom -Dartdist=docker -Djf.product.home=/opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [artifactoryCommon.sh:282      ] [main] - Removing old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_*
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [artifactoryCommon.sh:288      ] [main] - Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/mssql-jdbc-7.4.1.jre11.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_mssql-jdbc-7.4.1.jre11.jar
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [artifactoryCommon.sh:141      ] [main] - Saving /opt/jfrog/artifactory/app/artifactory/tomcat/conf/server.xml as /opt/jfrog/artifactory/app/artifactory/tomcat/conf/server.xml.orig
artifactory-dev    | 2020-05-15T17:25:52.000Z [shell] [INFO ] [] [artifactoryCommon.sh:149      ] [main] - Using Tomcat template to generate : /opt/jfrog/artifactory/app/artifactory/tomcat/conf/server.xml
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${artifactory.port||8081} to default value : 8081
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${artifactory.tomcat.connector.maxThreads||200} to default value : 200
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${artifactory.tomcat.maintenanceConnector.port||8091} to default value : 8091
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${artifactory.tomcat.maintenanceConnector.maxThreads||5} to default value : 5
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${artifactory.tomcat.maintenanceConnector.acceptCount||5} to default value : 5
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${access.http.port||8040} to default value : 8040
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${access.tomcat.connector.maxThreads||50} to default value : 50
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [systemYamlHelper.sh:292       ] [main] - Resolved JF_PRODUCT_HOME (/opt/jfrog/artifactory) from environment variable
artifactory-dev    | 2020-05-15T17:25:53.000Z [shell] [INFO ] [] [artifactoryCommon.sh:700      ] [main] - Resolved ${shared.tomcat.workDir||/opt/jfrog/artifactory/var/work/artifactory/tomcat} to default value : /opt/jfrog/artifactory/var/work/artifactory/tomcat
artifactory-dev    |
artifactory-dev    | ========================
artifactory-dev    | JF Environment variables
artifactory-dev    | ========================
artifactory-dev    |
artifactory-dev    | JF_SHARED_NODE_NAME                 : 3762da9ee54b
artifactory-dev    | JF_SYSTEM_YAML                      : /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | JF_ARTIFACTORY_PID                  : /opt/jfrog/artifactory/app/run/artifactory.pid
artifactory-dev    | JF_PRODUCT_DATA_INTERNAL            : /var/opt/jfrog/artifactory
artifactory-dev    | JF_PRODUCT_HOME                     : /opt/jfrog/artifactory
artifactory-dev    | JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES : jfrt,jfac,jfmd,jffe
artifactory-dev    | JF_SHARED_NODE_IP                   : <IP_ADDRESS>
artifactory-dev    | JF_SHARED_NODE_ID                   : 3762da9ee54b
artifactory-dev    | JF_ARTIFACTORY_USER                 : artifactory
artifactory-dev    | Starting router...
artifactory-dev    | router not running. Proceed to start it up.
artifactory-dev    | router started. PID: 3055
artifactory-dev    | Starting frontend...
artifactory-dev    | frontend not running. Proceed to start it up.
artifactory-dev    | 2020-05-15T17:25:54.051Z [jfrou] [INFO ] [41c378a842bad26d] [bootstrap.go:70               ] [main                ] - Router (jfrou) service initialization started. Version: 1.3.0 Revision: 52dff67afbeb25ab9d5ce3577c420a6562acb89f PID: 3055 Home: /opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:54.053Z [jfrou] [INFO ] [41c378a842bad26d] [bootstrap.go:73               ] [main                ] - JFrog Router IP: <IP_ADDRESS>
artifactory-dev    | 2020-05-15T17:25:54.073Z [jfrou] [INFO ] [41c378a842bad26d] [bootstrap.go:165              ] [main                ] - System configuration encryption report:
artifactory-dev    | shared.database.password: already encrypted
artifactory-dev    | shared.newrelic.licenseKey: does not exist in the config file
artifactory-dev    | shared.security.joinKeyFile: file '/opt/jfrog/artifactory/var/etc/security/join.key' - already encrypted
artifactory-dev    | 2020-05-15T17:25:54.080Z [jfrou] [INFO ] [41c378a842bad26d] [bootstrap.go:78               ] [main                ] - JFrog Router Service ID: jfrou@01e8chmg22a227v4z5zrexmc9m
artifactory-dev    | 2020-05-15T17:25:54.080Z [jfrou] [INFO ] [41c378a842bad26d] [bootstrap.go:79               ] [main                ] - JFrog Router Node ID: 3762da9ee54b
artifactory-dev    | frontend started. PID: 3183
artifactory-dev    | Starting metadata...
artifactory-dev    | JF_METADATA_ACCESSCLIENT_URL: http://localhost:8081/access
artifactory-dev    | metadata started. PID: 3377
artifactory-dev    | [DEBUG] Resolved system configuration file path: /opt/jfrog/artifactory/var/etc/system.yaml
artifactory-dev    | NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
artifactory-dev    | 2020-05-15T17:25:54.788Z [jffe ] [INFO ] [                ] [                              ] [main                ] - frontend (jffe) service initialization started. Version: 1.4.3 Revision: 0.0.0 PID: 3183 Home: /opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:55.245L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol init] - Initializing ProtocolHandler ["http-nio-8081"]
artifactory-dev    | 2020-05-15T17:25:55.271L [tomct] [INFO ] [                ] [org.apache.tomcat.util.net.NioSelectorPool] [org.apache.tomcat.util.net.NioSelectorPool getSharedSelector] - Using a shared selector for servlet write/read
artifactory-dev    | 2020-05-15T17:25:55.287L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol init] - Initializing ProtocolHandler ["http-nio-<IP_ADDRESS>-8091"]
artifactory-dev    | 2020-05-15T17:25:55.288L [tomct] [INFO ] [                ] [org.apache.tomcat.util.net.NioSelectorPool] [org.apache.tomcat.util.net.NioSelectorPool getSharedSelector] - Using a shared selector for servlet write/read
artifactory-dev    | 2020-05-15T17:25:55.290L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol init] - Initializing ProtocolHandler ["http-nio-<IP_ADDRESS>-8040"]
artifactory-dev    | 2020-05-15T17:25:55.291L [tomct] [INFO ] [                ] [org.apache.tomcat.util.net.NioSelectorPool] [org.apache.tomcat.util.net.NioSelectorPool getSharedSelector] - Using a shared selector for servlet write/read
artifactory-dev    | 2020-05-15T17:25:55.303L [tomct] [INFO ] [                ] [org.apache.catalina.core.StandardService] [org.apache.catalina.core.StandardService startInternal] - Starting service [Catalina]
artifactory-dev    | 2020-05-15T17:25:55.303L [tomct] [INFO ] [                ] [org.apache.catalina.core.StandardEngine] [org.apache.catalina.core.StandardEngine startInternal] - Starting Servlet Engine: Apache Tomcat/8.5.41
artifactory-dev    | 2020-05-15T17:25:55.334L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - Deploying configuration descriptor [/opt/jfrog/artifactory/app/artifactory/tomcat/conf/Catalina/localhost/access.xml]
artifactory-dev    | 2020-05-15T17:25:55.334L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - Deploying configuration descriptor [/opt/jfrog/artifactory/app/artifactory/tomcat/conf/Catalina/localhost/artifactory.xml]
artifactory-dev    | 2020-05-15T17:25:55.387L [tomct] [WARNING] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - A docBase [/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/access.war] inside the host appBase has been specified, and will be ignored
artifactory-dev    | 2020-05-15T17:25:55.388L [tomct] [WARNING] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - A docBase [/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/artifactory.war] inside the host appBase has been specified, and will be ignored
artifactory-dev    | 2020-05-15T17:25:58.444Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [o.a.c.h.HaNodeProperties:67   ] [ocalhost-startStop-2] - Artifactory is running in non-clustered mode.
artifactory-dev    | 2020-05-15T17:25:58.552Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [tifactoryHomeConfigListener:70] [ocalhost-startStop-2] - Resolved Home: '/opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:58.640Z [jfrt ] [INFO ] [                ] [o.j.c.w.FileWatchingManager:75] [Thread-6            ] - Starting watch of folder configurations
artifactory-dev    | 2020-05-15T17:25:58.720Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [.a.w.s.BasicConfigManagers:140] [ocalhost-startStop-2] - Artifactory (jfrt) service initialization started. Version: 7.4.3 Revision: 70403900 PID: 3470 Home: /opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:58.747Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [.a.c.ConvertersManagerImpl:142] [ocalhost-startStop-2] - Triggering PRE_INIT conversion, from 7.4.3 to 7.4.3
artifactory-dev    | 2020-05-15T17:25:58.754Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [.a.c.ConvertersManagerImpl:144] [ocalhost-startStop-2] - Finished PRE_INIT conversion, current version is: 7.4.3
artifactory-dev    | 2020-05-15T17:25:58.771Z [jfac ] [INFO ] [b84120ea945bd060] [licationContextInitializer:162] [ocalhost-startStop-1] - Access (jfac) service initialization started. Version: 5.4.6 Revision: 50406900 PID: 3470 Home: /opt/jfrog/artifactory
artifactory-dev    | 2020-05-15T17:25:58.866Z [jfac ] [INFO ] [b84120ea945bd060] [o.j.a.AccessApplication:50    ] [ocalhost-startStop-1] - Starting AccessApplication v5.4.6 on 3762da9ee54b with PID 3470 (/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-5.4.6.jar started by root in /var/opt/jfrog/artifactory)
artifactory-dev    | 2020-05-15T17:25:58.867Z [jfac ] [INFO ] [b84120ea945bd060] [o.j.a.AccessApplication:651   ] [ocalhost-startStop-1] - The following profiles are active: production
artifactory-dev    | 2020-05-15T17:25:59.920Z [jfrt ] [INFO ] [e9aaf4a9de71d141] [.w.ConfigurationManagerImpl:94] [ocalhost-startStop-2] - Starting file sync
artifactory-dev    | 2020-05-15T17:26:00.988Z [jfrt ] [INFO ] [776b025026b3b494] [ctoryContextConfigListener:308] [art-init            ] -
artifactory-dev    |                 _   _  __           _                     _____
artifactory-dev    |      /\        | | ()/ |         | |                   |  __
artifactory-dev    |     /  \   _ | | | | __ _  | | ___  _ __ _   _  | |) | __ ___
artifactory-dev    |    / /\ \ | '_| | |  _/ ` |/ __| / _ | '| | | | |  / '/ _
artifactory-dev    |   / ____ | |  | || | || (| | (| || () | |  | || | | |   | | | () |
artifactory-dev    |  //    __|   _||| _,|___|__/||   _, | ||   ||  _/
artifactory-dev    |  Version:  7.4.3                                   / |
artifactory-dev    |  Revision: 70403900                               |_/
artifactory-dev    |  Artifactory Home: '/opt/jfrog/artifactory'
artifactory-dev    |  Node ID: '3762da9ee54b'
artifactory-dev    |
artifactory-dev    | 2020-05-15T17:26:00.997Z [jfrt ] [WARN ] [776b025026b3b494] [o.a.f.l.ArtifactoryLockFile:65] [art-init            ] - Found existing lock file. Artifactory was not shutdown properly. [/opt/jfrog/artifactory/var/data/artifactory/.lock]
artifactory-dev    | 2020-05-15T17:26:01.146L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - Deployment of configuration descriptor [/opt/jfrog/artifactory/app/artifactory/tomcat/conf/Catalina/localhost/artifactory.xml] has finished in [5,808] ms
artifactory-dev    | 2020-05-15T17:26:01.227Z [jfrt ] [INFO ] [776b025026b3b494] [ifactoryApplicationContext:523] [art-init            ] - Artifactory application context set to NOT READY by refresh
artifactory-dev    | 2020-05-15T17:26:04.185Z [jfac ] [INFO ] [b84120ea945bd060] [s.d.u.AccessJdbcHelperImpl:138] [ocalhost-startStop-1] - Database: Microsoft SQL Server 14.00.3294. Driver: Microsoft JDBC Driver 7.4 for SQL Server <IP_ADDRESS>
artifactory-dev    | 2020-05-15T17:26:04.189Z [jfac ] [INFO ] [b84120ea945bd060] [s.d.u.AccessJdbcHelperImpl:141] [ocalhost-startStop-1] - Connection URL: jdbc:sqlserver://TD0745.res.bec.dk\TDSQL0745:1521;useFmtOnly=false;useBulkCopyForBatchInsert=false;cancelQueryTimeout=-1;sslProtocol=TLS;jaasConfigurationName=SQLJDBCDriver;statementPoolingCacheSize=0;serverPreparedStatementDiscardThreshold=10;enablePrepareOnFirstPreparedStatementCall=false;fips=false;socketTimeout=0;authentication=NotSpecified;authenticationScheme=nativeAuthentication;xopenStates=false;sendTimeAsDatetime=true;trustStoreType=JKS;trustServerCertificate=false;TransparentNetworkIPResolution=true;serverNameAsACE=false;sendStringParametersAsUnicode=false;selectMethod=direct;responseBuffering=adaptive;queryTimeout=-1;packetSize=8000;multiSubnetFailover=false;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=D00011TD00_MKT_ArtifactoryDev;columnEncryptionSetting=Disabled;applicationName=Artifactory;applicationIntent=readwrite;
artifactory-dev    | 2020-05-15T17:26:05.398Z [jfac ] [INFO ] [b84120ea945bd060] [alConfigurationServiceBase:182] [ocalhost-startStop-1] - Loading configuration from db finished successfully
artifactory-dev    | 2020-05-15T17:26:06.106Z [jfac ] [INFO ] [b84120ea945bd060] [.h.AccessNodeIdProviderImpl:69] [ocalhost-startStop-1] - Service id initialized: jfac@01e8chm9tb3dpx11x8t8x909bq
artifactory-dev    | 2020-05-15T17:26:06.703Z [jfac ] [INFO ] [b84120ea945bd060] [j.a.s.s.t.TokenServiceImpl:106] [ocalhost-startStop-1] - Scheduling task for revoking expired tokens using cron expression: 0 0 0/1 * * ?
artifactory-dev    | 2020-05-15T17:26:07.646Z [jfac ] [INFO ] [b84120ea945bd060] [b.AccessServerBootstrapImpl:36] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Starting JFrog Access bootstrap...
artifactory-dev    | 2020-05-15T17:26:07.650Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:108] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Initializing root certificate.
artifactory-dev    | 2020-05-15T17:26:08.085Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:331] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Saved new root certificate at: /opt/jfrog/artifactory/var/etc/access/keys/root.crt
artifactory-dev    | 2020-05-15T17:26:08.097Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:125] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Finished initializing root certificate. Certificate source: DATABASE
artifactory-dev    | 2020-05-15T17:26:08.101Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:108] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Initializing ca certificate.
artifactory-dev    | 2020-05-15T17:26:08.214Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:331] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Saved new ca certificate at: /opt/jfrog/artifactory/var/etc/access/keys/ca.crt
artifactory-dev    | 2020-05-15T17:26:08.226Z [jfac ] [INFO ] [b84120ea945bd060] [CertificateFileHandlerBase:125] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Finished initializing ca certificate. Certificate source: DATABASE
artifactory-dev    | 2020-05-15T17:26:08.344Z [jfac ] [INFO ] [b84120ea945bd060] [b.AccessServerBootstrapImpl:42] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] JFrog Access bootstrap finished.
artifactory-dev    | 2020-05-15T17:26:09.782Z [jfac ] [INFO ] [b84120ea945bd060] [o.j.a.s.r.s.GrpcServerImpl:65 ] [ocalhost-startStop-1] - Starting gRPC Server on port 8045
artifactory-dev    | 2020-05-15T17:26:10.305Z [jfac ] [INFO ] [b84120ea945bd060] [o.j.a.s.r.s.GrpcServerImpl:84 ] [ocalhost-startStop-1] - gRPC Server started, listening on 8045
artifactory-dev    | 2020-05-15T17:26:10.345Z [jfac ] [INFO ] [b84120ea945bd060] [o.j.a.s.s.JoinKeyAccess:166   ] [ocalhost-startStop-1] - Cluster join: Join key loaded successfully (from: /opt/jfrog/artifactory/var/etc/security/join.key)
artifactory-dev    | 2020-05-15T17:26:10.443Z [jfac ] [INFO ] [b84120ea945bd060] [a.s.b.AccessServerRegistrar:62] [ocalhost-startStop-1] - [ACCESS BOOTSTRAP] Starting JFrog Access registrar...
artifactory-dev    | 2020-05-15T17:26:10.494Z [jfac ] [INFO ] [d21a5b7ea0ff63d8] [a.c.RefreshableScheduledJob:53] [ocalhost-startStop-1] - Scheduling heartbeat task to run every 5 seconds
artifactory-dev    | 2020-05-15T17:26:10.498Z [jfac ] [INFO ] [d21a5b7ea0ff63d8] [a.c.RefreshableScheduledJob:53] [ocalhost-startStop-1] - Scheduling federationCleanupService task to run every 1209600 seconds
artifactory-dev    | 2020-05-15T17:26:10.512Z [jfac ] [INFO ] [d21a5b7ea0ff63d8] [a.c.RefreshableScheduledJob:53] [ocalhost-startStop-1] - Scheduling staleTokenCleanup task to run every 3600 seconds
artifactory-dev    | 2020-05-15T17:26:10.534Z [jfac ] [INFO ] [4de62954664561ee] [a.c.RefreshableScheduledJob:53] [ocalhost-startStop-1] - Scheduling loadCertificates task to run every 30 seconds
artifactory-dev    | 2020-05-15T17:26:10.545Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.d.DbServiceImpl:282     ] [art-init            ] - Database: Microsoft SQL Server 14.00.3294. Driver: Microsoft JDBC Driver 7.4 for SQL Server <IP_ADDRESS> Pool: mssql
artifactory-dev    | 2020-05-15T17:26:10.551Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.d.DbServiceImpl:285     ] [art-init            ] - Connection URL: jdbc:sqlserver://TD0745.res.bec.dk\TDSQL0745:1521;useFmtOnly=false;useBulkCopyForBatchInsert=false;cancelQueryTimeout=-1;sslProtocol=TLS;jaasConfigurationName=SQLJDBCDriver;statementPoolingCacheSize=0;serverPreparedStatementDiscardThreshold=10;enablePrepareOnFirstPreparedStatementCall=false;fips=false;socketTimeout=0;authentication=NotSpecified;authenticationScheme=nativeAuthentication;xopenStates=false;sendTimeAsDatetime=true;trustStoreType=JKS;trustServerCertificate=false;TransparentNetworkIPResolution=true;serverNameAsACE=false;sendStringParametersAsUnicode=false;selectMethod=direct;responseBuffering=adaptive;queryTimeout=-1;packetSize=8000;multiSubnetFailover=false;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=D00011TD00_MKT_ArtifactoryDev;columnEncryptionSetting=Disabled;applicationName=Artifactory;applicationIntent=readwrite;
artifactory-dev    | 2020-05-15T17:26:10.662Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.d.v.MssqlValidator:35   ] [art-init            ] - Validating scheme collation for mssql database
artifactory-dev    | 2020-05-15T17:26:12.559Z [jfac ] [INFO ] [4de62954664561ee] [o.j.a.AccessApplication:59    ] [ocalhost-startStop-1] - Started AccessApplication in 15.658 seconds (JVM running for 18.158)
artifactory-dev    | 2020-05-15T17:26:12.610L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDescriptor] - Deployment of configuration descriptor [/opt/jfrog/artifactory/app/artifactory/tomcat/conf/Catalina/localhost/access.xml] has finished in [17,276] ms
artifactory-dev    | 2020-05-15T17:26:12.620L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDirectory] - Deploying web application directory [/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/ROOT]
artifactory-dev    | 2020-05-15T17:26:12.648L [tomct] [INFO ] [                ] [org.apache.catalina.startup.HostConfig] [org.apache.catalina.startup.HostConfig deployDirectory] - Deployment of web application directory [/opt/jfrog/artifactory/app/artifactory/tomcat/webapps/ROOT] has finished in [28] ms
artifactory-dev    | 2020-05-15T17:26:12.663L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol start] - Starting ProtocolHandler ["http-nio-8081"]
artifactory-dev    | 2020-05-15T17:26:12.686L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol start] - Starting ProtocolHandler ["http-nio-<IP_ADDRESS>-8091"]
artifactory-dev    | 2020-05-15T17:26:12.693L [tomct] [INFO ] [                ] [org.apache.coyote.http11.Http11NioProtocol] [org.apache.coyote.AbstractProtocol start] - Starting ProtocolHandler ["http-nio-<IP_ADDRESS>-8040"]
artifactory-dev    | 2020-05-15T17:26:13.253Z [jfrt ] [INFO ] [776b025026b3b494] [ritiesStorageServiceFactory:25] [art-init            ] - Initializing DB-based Priorities Storage Service
artifactory-dev    | 2020-05-15T17:26:15.157Z [jfac ] [INFO ] [54c1d32deb31f11d] [s.r.NodeRegistryServiceImpl:68] [<IP_ADDRESS>-8040-exec-1] - Cluster join: Successfully joined jfrou@01e8chmg22a227v4z5zrexmc9m with node id 3762da9ee54b
artifactory-dev    | 2020-05-15T17:26:15.564Z [jfrou] [INFO ] [41c378a842bad26d] [join_executor.go:181          ] [main                ] - Cluster join: Successfully joined the cluster
artifactory-dev    | 2020-05-15T17:26:15.653Z [jfrou] [INFO ] [                ] [server.go:568                 ] [main                ] - Preparing server api &{Address:localhost:8049 TLS: Redirect: Auth: WhitelistSourceRange:[] WhiteList: Compress:false ProxyProtocol: ForwardedHeaders:0xc00087bda0} with readTimeout=0s writeTimeout=0s idleTimeout=3m0s
artifactory-dev    | 2020-05-15T17:26:15.658Z [jfrou] [INFO ] [                ] [server.go:568                 ] [main                ] - Preparing server external &{Address::8082 TLS: Redirect: Auth: WhitelistSourceRange:[] WhiteList: Compress:false ProxyProtocol: ForwardedHeaders:0xc00087bdc0} with readTimeout=0s writeTimeout=0s idleTimeout=3m0s
artifactory-dev    | 2020-05-15T17:26:15.658Z [jfrou] [INFO ] [                ] [server.go:524                 ] [main                ] - Starting server on localhost:8049
artifactory-dev    | 2020-05-15T17:26:15.659Z [jfrou] [INFO ] [                ] [server.go:568                 ] [main                ] - Preparing server internal &{Address:localhost:8046 TLS: Redirect: Auth: WhitelistSourceRange:[] WhiteList: Compress:false ProxyProtocol: ForwardedHeaders:0xc00087bd80} with readTimeout=0s writeTimeout=0s idleTimeout=3m0s
artifactory-dev    | 2020-05-15T17:26:15.659Z [jfrou] [INFO ] [                ] [server.go:524                 ] [main                ] - Starting server on :8082
artifactory-dev    | 2020-05-15T17:26:15.659Z [jfrou] [INFO ] [                ] [server.go:524                 ] [main                ] - Starting server on localhost:8046
artifactory-dev    | 2020-05-15T17:26:15.659Z [jfrou] [INFO ] [                ] [server.go:420                 ] [main                ] - Starting provider configuration.ProviderAggregator {}
artifactory-dev    | 2020-05-15T17:26:15.659Z [jfrou] [INFO ] [                ] [provider_aggregator.go:103    ] [main                ] - Starting provider *file.Provider {"Watch":true,"Filename":"","Constraints":null,"Trace":false,"TemplateVersion":0,"DebugLogGeneratedTemplate":false,"Directory":"/opt/jfrog/artifactory/var/data/router/traefik/routes","TraefikFile":""}
artifactory-dev    | 2020-05-15T17:26:15.690Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8049
artifactory-dev    | 2020-05-15T17:26:15.690Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on :8082
artifactory-dev    | 2020-05-15T17:26:15.690Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8046
artifactory-dev    | 2020-05-15T17:26:15.691Z [jfrou] [INFO ] [41c378a842bad26d] [main.go:47                    ] [main                ] - Router (jfrou) service initialization completed in 21.666 seconds. Listening on port: 8082
artifactory-dev    | 2020-05-15T17:26:17.276Z [jfrt ] [INFO ] [776b025026b3b494] [actorySchedulerFactoryBean:727] [art-init            ] - Starting Quartz Scheduler now
artifactory-dev    | 2020-05-15T17:26:17.398Z [jfrt ] [INFO ] [776b025026b3b494] [ifactoryApplicationContext:271] [art-init            ] - Artifactory context starting up 58 Spring Beans...
artifactory-dev    | 2020-05-15T17:26:17.691Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8049
artifactory-dev    | 2020-05-15T17:26:17.691Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on :8082
artifactory-dev    | 2020-05-15T17:26:17.691Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8046
artifactory-dev    | 2020-05-15T17:26:17.993Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.a.AccessServiceImpl:408 ] [art-init            ] - Initialized new service id: jfrt@01e8chmvcfm3fw0ys53zjw1brd
artifactory-dev    | 2020-05-15T17:26:18.068Z [jfrt ] [INFO ] [776b025026b3b494] [oryAccessClientConfigStore:592] [art-init            ] - Using Access Server URL: http://localhost:8046/access source: System Config
artifactory-dev    | 2020-05-15T17:26:19.416Z [jfac ] [INFO ] [b84120ea945bd060] [.AccessWithRouterRegistrar:106] [pool-6-thread-1     ] - Access Server successfully registered on Router on URL: http://localhost:8046
artifactory-dev    | 2020-05-15T17:26:19.692Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8049
artifactory-dev    | 2020-05-15T17:26:19.692Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on :8082
artifactory-dev    | 2020-05-15T17:26:19.693Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8046
artifactory-dev    | 2020-05-15T17:26:19.943Z [jfac ] [INFO ] [b84120ea945bd060] [.s.b.AccessServerRegistrar:116] [pool-6-thread-1     ] - [ACCESS BOOTSTRAP] Updating server '3762da9ee54b' private key finger print to: 82ad1c5034e31b558c6748c23d70baaa893ee1a2bca54ea25689496bc7b07c32 ca private key finger print to: 9f22ae424451a17685987385978e966432207ad094f6f69a50deb33d398cf227
artifactory-dev    | 2020-05-15T17:26:19.964Z [jfac ] [INFO ] [b84120ea945bd060] [a.s.b.AccessServerRegistrar:72] [pool-6-thread-1     ] - [ACCESS BOOTSTRAP] JFrog Access registrar finished.
artifactory-dev    | 2020-05-15T17:26:20.194Z [jfac ] [INFO ] [900894d4db7e15c ] [s.r.NodeRegistryServiceImpl:68] [<IP_ADDRESS>-8040-exec-7] - Cluster join: Successfully joined jfrt@01e8chmvcfm3fw0ys53zjw1brd with node id 3762da9ee54b
artifactory-dev    | 2020-05-15T17:26:20.249Z [jfrt ] [WARN ] [                ] [o.j.c.w.ConfigWrapperImpl:536 ] [Thread-6            ] - Detected a change on file /opt/jfrog/artifactory/var/etc/artifactory/security/access/access.admin.token with a timestamp later than the system's current time.  The file's timestamp will be set as the current time.
artifactory-dev    | 2020-05-15T17:26:20.251Z [jfrt ] [INFO ] [776b025026b3b494] [.a.c.AccessClientBootstrap:169] [art-init            ] - Cluster join: Successfully joined the cluster
artifactory-dev    | 2020-05-15T17:26:20.256Z [jfrt ] [INFO ] [776b025026b3b494] [o.j.a.c.g.AccessGrpcClient:74 ] [art-init            ] - Connecting to grpc server on localhost:8046
artifactory-dev    | 2020-05-15T17:26:20.256Z [jfrt ] [INFO ] [                ] [o.j.c.w.ConfigWrapperImpl:504 ] [Thread-6            ] - [Node ID: 3762da9ee54b]  detected local  modify for config 'artifactory.security.access/access.admin.token'
artifactory-dev    | 2020-05-15T17:26:21.382Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.a.AccessServiceImpl:352 ] [art-init            ] - Initialized access service successfully with client id<PHONE_NUMBER>, closing old client id [null]
artifactory-dev    | 2020-05-15T17:26:21.384Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.a.AccessServiceImpl:1247] [art-init            ] - Updating access configuration with password expiration data
artifactory-dev    | 2020-05-15T17:26:21.693Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8049
artifactory-dev    | 2020-05-15T17:26:21.693Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on :8082
artifactory-dev    | 2020-05-15T17:26:21.694Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8046
artifactory-dev    | 2020-05-15T17:26:21.883Z [jfrt ] [WARN ] [776b025026b3b494] [o.a.s.a.AccessServiceImpl:1474] [art-init            ] - Your Artifactory server is configured with the default Admin Credentials. It is highly recommended to change the default admin password. You can change the password from the User Management Page.
artifactory-dev    | 2020-05-15T17:26:22.179Z [jfrt ] [INFO ] [776b025026b3b494] [.c.r.ReplicatorServiceImpl:112] [art-init            ] - initializing Replicator Service
artifactory-dev    | 2020-05-15T17:26:22.180Z [jfrt ] [INFO ] [776b025026b3b494] [.c.r.ReplicatorServiceImpl:332] [art-init            ] - Local Replicator is setting up in non-bundled mode
artifactory-dev    | 2020-05-15T17:26:22.355Z [jfrt ] [ERROR] [776b025026b3b494] [yMetadataClientConfigStore:122] [art-init            ] - Unable to request the Metadata Service Service-Id: Failed executing api/v1/system/service_id, with response code: HTTP/1.1 404 Not Found and response message: Not Found
artifactory-dev    | 2020-05-15T17:26:22.356Z [jfrt ] [WARN ] [776b025026b3b494] [s.MetadataEventServiceImpl:312] [art-init            ] - Unable to init the Metadata client. The Metadata Event pipeline will be disabled: Unable to request the Metadata Service Service-Id
artifactory-dev    | 2020-05-15T17:26:22.356Z [jfrt ] [WARN ] [776b025026b3b494] [s.MetadataEventServiceImpl:316] [art-init            ] - Metadata Client not initialized. Starting Metadata Server Status Probe
artifactory-dev    | 2020-05-15T17:26:22.358Z [jfrt ] [INFO ] [2f53d8604dea84e7] [o.a.e.w.StatusProbeImpl:35    ] [-events-status-probe] - Status probe started (Owner: metadata-operator-events)
artifactory-dev    | 2020-05-15T17:26:22.360Z [jfrt ] [INFO ] [776b025026b3b494] [tegrationCleanupServiceImpl:75] [art-init            ] - Using generated cron 0 21 2 ? * * for jobs table cleanup
artifactory-dev    | 2020-05-15T17:26:23.467Z [jfrt ] [INFO ] [776b025026b3b494] [ifactoryApplicationContext:523] [art-init            ] - Artifactory application context set to READY by refresh
artifactory-dev    | 2020-05-15T17:26:23.581Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.a.AccessServiceImpl:1550] [art-init            ] - Successful register of Artifactory serviceId jfrt@01e8chmvcfm3fw0ys53zjw1brd in Access Federation
artifactory-dev    | 2020-05-15T17:26:23.588Z [jfrt ] [INFO ] [776b025026b3b494] [.s.MetadataMigrationHelper:191] [art-init            ] - No repositories found that correspond to the supported Metadata Migration types. Supported types are [CRAN, Debian, Npm, YUM, Gems, CocoaPods, Chef, Conan, Vagrant, Conda, Pypi, Docker, Bower, SBT, Ivy, Gradle, NuGet, Composer, Puppet, Helm, Go, Opkg, Maven]
artifactory-dev    | 2020-05-15T17:26:23.593Z [jfrt ] [INFO ] [776b025026b3b494] [.s.MetadataMigrationHelper:205] [art-init            ] - Updating existing migration status for 'metadata-service-migration' to finished
artifactory-dev    | 2020-05-15T17:26:23.593Z [jfrt ] [INFO ] [776b025026b3b494] [ionStatusStorageServiceImpl:97] [art-init            ] - Migration for 'metadata-service-migration' has finished.
artifactory-dev    | 2020-05-15T17:26:23.602Z [jfrt ] [INFO ] [2560c5d922795992] [adsFolderCleanupServiceImpl:51] [art-exec-3          ] - Starting docker temp folder cleanup
artifactory-dev    | 2020-05-15T17:26:23.604Z [jfrt ] [INFO ] [776b025026b3b494] [.w.NodeEventTaskManagerImpl:43] [art-init            ] - Event management started on behalf of Event Operator with ID 'metadata-operator-events'
artifactory-dev    | 2020-05-15T17:26:23.609Z [jfrt ] [INFO ] [2560c5d922795992] [adsFolderCleanupServiceImpl:53] [art-exec-3          ] - Docker temp folder cleanup finished, time took: 7 millis
artifactory-dev    | 2020-05-15T17:26:23.618Z [jfrt ] [INFO ] [776b025026b3b494] [o.a.s.s.StorageServiceImpl:425] [art-init            ] - Scheduling CalculateReposStorageSummaryJob to run at '0 1 * ? * *'
artifactory-dev    | 2020-05-15T17:26:23.628Z [jfrt ] [INFO ] [776b025026b3b494] [ctoryContextConfigListener:250] [art-init            ] - Artifactory (jfrt) service initialization completed in 22.661 seconds. Listening on port: 8081
artifactory-dev    | 2020-05-15T17:26:30.430Z [jffe ] [INFO ] [                ] [                              ] [main                ] - setting service id - jffe@000
artifactory-dev    | 2020-05-15T17:26:30.499Z [jfac ] [INFO ] [4c77b332c8b2482f] [s.r.NodeRegistryServiceImpl:68] [<IP_ADDRESS>-8040-exec-3] - Cluster join: Successfully joined jffe@000 with node id 3762da9ee54b
artifactory-dev    | 2020-05-15T17:26:30.507Z [jffe ] [INFO ] [                ] [                              ] [main                ] - Cluster join: Successfully joined the cluster
artifactory-dev    | 2020-05-15T17:26:30.547Z [jffe ] [INFO ] [                ] [                              ] [main                ] - UI service successfully registered on router, serviceId: jffe@000
artifactory-dev    | 2020-05-15T17:26:30.562Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8046
artifactory-dev    | 2020-05-15T17:26:30.562Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on localhost:8049
artifactory-dev    | 2020-05-15T17:26:30.562Z [jfrou] [INFO ] [                ] [server_configuration.go:61    ] [main                ] - Server configuration reloaded on :8082
artifactory-dev    | 2020-05-15T17:26:31.009Z [jffe ] [INFO ] [                ] [                              ] [main                ] - Recurring tasks started
artifactory-dev    | 2020-05-15T17:26:31.570Z [jffe ] [INFO ] [                ] [                              ] [main                ] - frontend (jffe) service initialization completed in 36.78 seconds. Listening on port: port 8070
artifactory-dev    | 2020-05-15T17:26:53.492Z [jfrt ] [INFO ] [b1f1868806de3515] [a.e.EventsLogCleanUpService:53] [art-exec-9          ] - Starting cleanup of old events from event log
artifactory-dev    | 2020-05-15T17:26:53.496Z [jfrt ] [INFO ] [b1f1868806de3515] [a.e.EventsLogCleanUpService:74] [art-exec-9          ] - Cleanup of old events from event log finished
artifactory-dev    | error reading configuration from system.yaml : reading db properties failed: could not derive db properties from system yaml: Type: , Url: : Could not set db properties to application configuration: could not derive dbname/hostname from jdbc url
artifactory-dev    | goroutine 1 [running]:
artifactory-dev    | runtime/debug.Stack(0x10, 0x10, 0xc000126a40)
artifactory-dev    |    /src/runtime/debug/stack.go:24 +0x9d
artifactory-dev    | jfrog.com/metadata/common/log.(*standardLogger).Panicfc(0xc0000beb78, 0x14f8be0, 0xc000202960, 0x12bb292, 0x31, 0xc000126a40, 0x1, 0x1)
artifactory-dev    |    /src/jfrog.com/metadata/common/log/standard_logger.go:44 +0x6a
artifactory-dev    | jfrog.com/metadata/services/common.(*configBearer).ValidateConfig(0xc00048ecd0, 0x14f8be0, 0xc000202960, 0x1508f00, 0xc0000beb78)
artifactory-dev    |    /src/jfrog.com/metadata/services/common/config_bearer.go:176 +0x245
artifactory-dev    | main.main()
artifactory-dev    |    /src/jfrog.com/metadata/metadata.go:28 +0x349
artifactory-dev    |
artifactory-dev    | panic: error reading configuration from system.yaml : reading db properties failed: could not derive db properties from system yaml: Type: , Url: : Could not set db properties to application configuration: could not derive dbname/hostname from jdbc url
artifactory-dev    | goroutine 1 [running]:
artifactory-dev    | runtime/debug.Stack(0x10, 0x10, 0xc000126a40)
artifactory-dev    |    /src/runtime/debug/stack.go:24 +0x9d
artifactory-dev    | jfrog.com/metadata/common/log.(*standardLogger).Panicfc(0xc0000beb78, 0x14f8be0, 0xc000202960, 0x12bb292, 0x31, 0xc000126a40, 0x1, 0x1)
artifactory-dev    |    /src/jfrog.com/metadata/common/log/standard_logger.go:44 +0x6a
artifactory-dev    | jfrog.com/metadata/services/common.(*configBearer).ValidateConfig(0xc00048ecd0, 0x14f8be0, 0xc000202960, 0x1508f00, 0xc0000beb78)
artifactory-dev    |    /src/jfrog.com/metadata/services/common/config_bearer.go:176 +0x245
artifactory-dev    | main.main()
artifactory-dev    |    /src/jfrog.com/metadata/metadata.go:28 +0x349
artifactory-dev    |
artifactory-dev    |
artifactory-dev    | goroutine 1 [running]:
artifactory-dev    | github.com/rs/zerolog.(*Logger).Panic.func1(0xc0000f4380, 0x32b)
artifactory-dev    |    /pkg/mod/github.com/rs/zerolog@v1.17.2/log.go:338 +0x4f
artifactory-dev    | github.com/rs/zerolog.(*Event).msg(0xc000012b40, 0xc0000f4380, 0x32b)
artifactory-dev    |    /pkg/mod/github.com/rs/zerolog@v1.17.2/event.go:146 +0x186
artifactory-dev    | github.com/rs/zerolog.(*Event).Msgf(0xc000012b40, 0xc000037400, 0x34, 0xc000613e40, 0x2, 0x2)
artifactory-dev    |    /pkg/mod/github.com/rs/zerolog@v1.17.2/event.go:126 +0x83
artifactory-dev    | jfrog.com/metadata/common/log.(*standardLogger).logMessage(0xc0000beb78, 0x14f8be0, 0xc000202960, 0xc000012b40, 0xc000037400, 0x34, 0xc000613e40, 0x2, 0x2)
artifactory-dev    |    /src/jfrog.com/metadata/common/log/standard_logger.go:88 +0xbc
artifactory-dev    | jfrog.com/metadata/common/log.(*standardLogger).Panicfc(0xc0000beb78, 0x14f8be0, 0xc000202960, 0x12bb292, 0x31, 0xc000613e40, 0x2, 0x2)
artifactory-dev    |    /src/jfrog.com/metadata/common/log/standard_logger.go:45 +0x1df
artifactory-dev    | jfrog.com/metadata/services/common.(*configBearer).ValidateConfig(0xc00048ecd0, 0x14f8be0, 0xc000202960, 0x1508f00, 0xc0000beb78)
artifactory-dev    |    /src/jfrog.com/metadata/services/common/config_bearer.go:176 +0x245
artifactory-dev    | main.main()
artifactory-dev    |    /src/jfrog.com/metadata/metadata.go:28 +0x349

turned out to be wrong syntax for instance name in jdbc url for sqlserver 14


feat(NumberField/CanonicalEmbedding): add canonicalEmbedding.integralBasis_repr_apply

Prove that the representation on the latticeBasis of the canonical space of the image of an algebraic number is equal to its representation of the integral basis.

Thanks!
bors merge


Switch override checking over to access scopes

Explanation: Swift's access control restricts puts certain requirements on members that are overrides of members in the superclass. This logic hadn't been updated for SE-0025, resulting in incorrect and confusing diagnostics. (This is basically the override version of #4176, which made a similar fix for protocol witnesses.)
There's an extra commit in here from @rintaro; that's mostly to make sure my change applies cleanly (their logic is all replaced), but also includes extra tests.

Scope: Affects all access checking for overrides.

Issue: rdar://problem/27820665

Reviewed by: @rjmccall

Risk: Medium. As has been pointed out this may break existing Swift 3 code that's doing something a little bit invalid that the old logic wasn't checking; I haven't tried to come up with such a case.

Testing: Added compiler regression tests, checked existing tests in this area.

@swift-ci Please test


Is there a way to simulate a connected car when developing?

Great work on this project, I've been toying with the idea of something like this but looks like you beet me to the punch!
Would love to contribute but one issue I'm running into is that my car is parked in an underground garage (no cell reception and quite far from my desktop computer) which means running/debugging the app is going to be a bit of a pain, is there any sort of simulator/test harness to I could use to test some of my code?  I see you have a branch started for voice input which is something I'd be interested in helping out with.

Nvm, found the tests.

Thank you for your interest in contributing! The tests should help a lot with verifying certain aspects of functionality, indeed. I don't have any good automated integration tests, however. I would like to rewrite the tests to make the user event inputs clearer and more succinct, instead of the current verbose mess.
Since the protocol is just talking to an Apache Etch server, you could make a basic car-side implementation of some parts of the protocol. I have one that I use for occasional experiments, but it's not complete enough or accurate enough for me to want to release it.
Please reach out with any further questions or suggestions!

Thanks, just getting a feel for the code now, I've got a WIP branch cleaning up the names of the Spotify custom actions, maybe done in a week or so: https://github.com/hufman/AndroidAutoIdrive/compare/master...kohner86:master


pydoc is not built correctly?

While I was trying to build project that uses shotgun_api3 I found this weird bug:

This example works

import pydoc

However, this one doesn't:

import pydoc
import xmlrpc
import xmlrpc.client
import xmlrpc.server

This is the error message: File "C:\Users<User>\AppData\Local\Temp<Tmp>\xmlrpc\server.py", line 721, in
NameError: name 'pydoc' is not defined
I've tried to build project with Nuitka 2.3.10 and 2.4.8 and in both cases executable fails. I've also tried to  add these options:  --include-module=pydoc, --include-module=xmlrpc, --include-module=xmlrpc.server, but I still get same error message

you'll have to use --noinclude-pydoc-mode=allow as pydoc is generally considered antibloat by nuitka

I am not happy with the looks of this, I think it defaults to warning, and should not make something not work. Probably a dependency in stdlib that is not recognized and not using use_pydoc or something like that.

This has proper config for all I can tell:
- module-name: 'xmlrpc.server' # checksum: 105ff40e
  anti-bloat:
    - replacements_plain:
        'import pydoc': ''
      when: 'not use_pydoc'

Our setup here is probably wrong.
        if noinclude_pydoc_mode != "allow":
            self.handled_modules["pydoc"] = noinclude_pydoc_mode, "pydoc"
        else:
            self.control_tags["use_pydoc"] = True

The default mode is warning which is a form of allowing it, yet for tags, it's treated as if it's not allowed, keeping use_pydoc at false.

It contains this
class ServerHTMLDoc(pydoc.HTMLDoc):
    """Class used to generate pydoc HTML document for a server"""

So, the base class is causing issues. Not sure, why this doesn't help yet
  anti-bloat:
    - description: 'avoid using pydoc'
      replacements_plain:
        'import pydoc': ''
      change_class:
        'ServerHTMLDoc': 'un-usable'
      when: 'not use_pydoc'

Having the tag use_pydoc except for allow is actually as intended btw, so configuration avoids warnings by removing things typically not needed.

Ah, the reason is that it's converted to bytecode from source code, and then change_class is ineffective.

So, the anti-bloat plugin now forces xmlrpc.server to be compiled and I found a few bugs related to when change_class and change_function are used, and the fact that plugin decisions for stdlib modules were ignored. This is a bigger change, and outside of the scope of what I am willing to do for a hotfix, so this is going to be 2.5 material. I am currently catching up on issues, and might continue hotfixing for a bit longer.

Thanks for your report, this is fixed on the factory branch, which is a development version under rapid development. You can try it out by going here: https://nuitka.net/doc/factory.html
Feedback on whether this is working is very welcome. Please do not share plans to do it; only confirm or deny that it is working.

This is part of the current pre-release.

Part of the 2.5 release I just made.


CorsPlugin reflectClientOrigin doesn't work in Before handlers

Actual behavior (the bug)
Hi, I use the CorsPlugin with the following configuration:
javalinConfig.registerPlugin(new CorsPlugin(cors -> cors.addRule(corsRule -> corsRule.reflectClientOrigin = true)));

It works fine for the Endpoint handlers like get, post, etc. However, it doesn't work in Before handlers.
The Access-Control-Allow-Origin header is not being set in the response.
Expected behavior
The Access-Control-Allow-Origin header is present in the Before handlers response.
To Reproduce
Implement a Before handler that will throw any exception, for example, BadRequestResponse.
Send the API request with the Origin header. The response will not include the Access-Control-Allow-Origin header.
Additional context
The issue causes problems with handling errors in the UI application because of missing Access-Control-Allow-Origin response header

Could you have a look here @Playacem ?

The following tests works without issues, can you maybe share your code or a minimal reproduction setup for this issue?
        @Test
        fun `works with throwing before`() = TestUtil.test(Javalin.create { config ->
            config.bundledPlugins.enableCors { cors ->
                cors.addRule { it.reflectClientOrigin = true }
            }
        }.get("/") { it.result("a") }.before { throw BadRequestResponse() }) { _, http ->
            assertThat(
                http.get("/", mapOf(ORIGIN to "https://some-origin")).header(ACCESS_CONTROL_ALLOW_ORIGIN)
            ).isEqualTo(
                "https://some-origin"
            )
        }

Okay, I found the reason why this happens. Basically we register the cors routes later than the user defined before handler.
A possible solution is to use the new beforeMatched handlers as those run after the normal before handlers.
        @Test
        fun `gh-2246`() = TestUtil.test(Javalin.create { config ->
            config.registerPlugin(CorsPlugin { cors ->
                cors.addRule { rule -> rule.reflectClientOrigin = true }
            })
            config.router.mount {
                it.beforeMatched {
                    throw TooManyRequestsResponse()
                }
                it.get("/") {
                    it.result("a")
                }
            }
        }) { _, http ->
            assertThat(http.get("/", mapOf(ORIGIN to "https://some-origin")).header(ACCESS_CONTROL_ALLOW_ORIGIN)).isEqualTo("https://some-origin")
        }

Hi, @Playacem looks like beforeMatched is working for the config.router.mount API only.
However, we are using config.router.apiBuilder and it seems not possible to use beforeMatched but only before handler in the EndpointGroup

You can use both approaches and have the beforeMatched handler using the mount api. The api builder is more for those typical rest apis, leaving the rest to the mount api and the direct stuff on the Javalin instance.

Yes, this is a workable option, but I'm afraid it doesn't work very well for us.
We have a complex EndpointGroup structure that holds all the configurations in one place.
For some of our applications, we have 43 before handlers, and moving them to the config.router.mount will lead to code duplication and worse readability.
For example:
      javalinConfig.router.apiBuilder(() -> {
        path(
            "/api",
            () -> {
              //before handlers common for entire /api path

              path(
                  "/clients",
                  () -> {
                    //before handlers and method handlers for the /api/clients endpoints
                  });

              path(
                  "/notifications",
                  () -> {
                    //before handlers and method handlers for the /api/notifications endpoints
                  });

              path(
                  "/users",
                  () -> {
                    //before handlers and method handlers for the /api/users endpoints
                  });

            //..... another endpoint groups
            });
      });

It would be nice to have beforeMatched available for the EndpointGroups or before handler to work properly and return Origin header.

Hi @YaroslavYakymenko, sorry for my late reply.
I have found a workaround which does not require to switch everything over to the mount api:
You can call CorsPlugin#onStart(JavalinConfig) directly instead of using JavalinConfig.registerPlugin() / JavalinConfig.bundledPlugins.enableCors().
The following testcase works for me:
        @Test
        fun `gh-2246 chaining with andThen works`() {
            val cors = Consumer<JavalinConfig> { config ->

                val corsPlugin = CorsPlugin { cors ->
                    cors.addRule { rule -> rule.reflectClientOrigin = true }
                }
                // Workaround: call onStart directly
                // onStart would otherwise be called on startup if we go the regular route of registerPlugin
                // we register the routes here early so there are chronologically before the other before handlers
                corsPlugin.onStart(config)
            }
            val routesApiBuilder = Consumer<JavalinConfig> { config ->
                config.router.apiBuilder {
                    path("/") {
                        before { _ ->
                            throw TooManyRequestsResponse()
                        }
                        get { ctx ->
                            ctx.result("a")
                        }
                    }
                }
            }

            val corsFirst = Javalin.create(cors.andThen(routesApiBuilder)) // cors is first here!
            TestUtil.test(corsFirst) { _, http ->
                assertThat(http.get("/", mapOf(ORIGIN to "https://some-origin")).header(ACCESS_CONTROL_ALLOW_ORIGIN)).isEqualTo("https://some-origin")
            }
        }

Hope this helps.

I've just checked and this approach works as expected. Thank you


Added yarn lint in travis script

We should run the lint script in travis to make sure there are no any eslint errors.

Coverage remained the same at 94.04% when pulling 958f4fe4684a80fffd85c1685db36d8ab785c38e on feature/travis-eslint into c8e0e6e216dd39f7b26338995fc960f61dac8542 on master.


fix log autoscroll disabling

To reproduce: when log overflows the view, scroll it up - autoscroll should be disabled until view is scrolled down again.
I also added issue in blessed repo (just in case).

Thanks! 👍


RATIS-1082. Netty stream server should forward the data to the other servers in the group

What changes were proposed in this pull request?
Once a stream server has received data from client, it should forward the data to the other servers. For simplicity, a star topology is used in this JIRA. In the future, the star topology will be replaced by pipelines in order to avoid additional cross rack traffic.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/RATIS-1082
How was this patch tested?
UT

R: @szetszwo @runzhiwang
This is the first version of the implementation about stream forwarding messages to peers. I am sure this version needs lots of improvements and I want to hear your feedback and suggestions.
Will also rebase this PR once #212  is merged

Now as RATIS-1081 is merged, I have rebased and start to address comments.

R @szetszwo @runzhiwang
Have rebased this PR and addressed some of the important comments. Can you take a look?

@szetszwo @runzhiwang
addressed all actionable actions so far. Can you take a look?

@amaliujia Thanks the patch. @szetszwo Thanks for review. I have merged it.


Non-retry crash recovery

Prerequisites

[x] I am running the latest version. (up upgrade)
[x] I searched to see if the issue already exists.
[x] Are you an Up Pro subscriber?

Description
When using retries, the up proxy will detect a crash and restart the server. However, when retries are disabled, a crashed server is never restarted. This results in a lambda instance serving 502 responses until traffic lowers enough for the instance to be shut down/collected by AWS.
I think ideally these two would be usable independently.
https://github.com/apex/up/blob/5f16b7f99d6c5bd23289e8bf1927a5cce32e3475/http/relay/relay.go#L178
Steps to Reproduce
https://github.com/courajs/up-crash-example

Make an app that crashes
Disable retries with "proxy": {"retry": false} in up.json
Make http requests to the proxy, you will get consistent 502

Thanks for the report, I'll take a look I agree they're separate cases.

Need to polish it up and QA but should have this fix out tomorrow, I was meaning to remove retries anyway it ended up just causing more confusion overall I think.

921e818


Exceed quota if I click CloudRun Button, but works well on Cloud Shell

Hi Team,
I'm not entirely sure if this is the right place to post my issue, but please feel free to ask any questions if you have them.
I've been attempting to migrate my projects from Heroku using the Cloud Run button. However, sometimes an error occurs indicating that Cloud Run has run out of quota.

(Apologies for the image being in Chinese, but it indicates that I am running out of Cloud Shell quota.)
Interestingly, when I refresh the page, everything seems to work fine again, but the Cloud Run deployment does not continue.
I've checked my "Cloud Shell quota," and it shows that I still have 90% of my quota remaining.

Could anyone please provide suggestions or directions for troubleshooting this issue? Any advice on how to resolve this intermittent quota error with Cloud Run deployments would be greatly appreciated.
Thank you for your assistance!

That does seem like a bug of some sort.  Maybe @glasnt can file this with the Cloud Shell team?

I've hit this one before, but I couldn't work out which quota I was hitting. I experienced this one when I was clicking the cloud run button from the same repo multiple times. If you are trying to run this many times, you could take the approach of using the command that the Cloud Run Button generates in your Cloud Shell, and editing/running that.
For example, using the button github.com/googlecloudplatform/cloud-run-button, Cloud Shell runs the following command:
cloudshell_open --repo_url "https://github.com/GoogleCloudPlatform/cloud-run-hello.git" --page "shell" --force_new_clone

If you re-use this command in the same Cloud Shell instance, you might be able to get multiple iterations before hitting this quota limit.
(Note that this the custom cloud run button image's cloudshell_open as opposed to the standard Cloud Shell image executable, so you'll have to be in a Cloud Run Button-powered Cloud Shell for this approach to work).

I have exactly the same problem. I want to test this button, so I commit my changes to repo, ten click the button, and connot really iterate because od this error that says that quota is exceeded.
I noticed that it also blocks me from starting any cloud shell in ephemeral mode, however standard mode is fine. I cannot ask support because I don't pay for it, and there seems to be nothing about it on stack.
I also noticed that even creating a new project didn't help which was weird.
I would appreciate any help


Gefyra is not running properly on M1 mac

What happened?
Running gefyra up is a bit slow, waiting for the operator to be ready:
[INFO] There was no --endpoint argument provided. Connecting to a local Kubernetes node.
[INFO] Installing Gefyra Operator
[INFO] Created network 'gefyra' (a2bbf4fae3)
[INFO] Pulling image "quay.io/gefyra/operator:0.11.4"
[INFO] Successfully pulled image "quay.io/gefyra/operator:0.11.4" in 8.311726046s
[INFO] Pulling image "quay.io/gefyra/stowaway:0.11.4"
[INFO] Successfully pulled image "quay.io/gefyra/stowaway:0.11.4" in 15.011779716s
[INFO] Operator became ready in 87.6396 seconds
[INFO] Deploying Cargo (network sidecar) with IP <IP_ADDRESS>

The operator has the following error in the log:
[2022-10-18 21:01:34,545] kopf.activities.star [ERROR   ] Activity 'check_gefyra_components' failed with an exception. Will retry.
Traceback (most recent call last):
  File "/usr/lib/python3.9/kopf/_core/actions/execution.py", line 279, in execute_handler_once
    result = await invoke_handler(
  File "/usr/lib/python3.9/kopf/_core/actions/execution.py", line 374, in invoke_handler
    result = await invocation.invoke(
  File "/usr/lib/python3.9/kopf/_core/actions/invocation.py", line 116, in invoke
    result = await fn(**kwargs)  # type: ignore
  File "/app/gefyra/handler/components.py", line 211, in check_gefyra_components
    await aw_wireguard_ready
  File "/app/gefyra/stowaway.py", line 80, in get_wireguard_connection_details
    stream_copy_from_pod(
  File "/app/gefyra/utils.py", line 112, in stream_copy_from_pod
    raise e
  File "/app/gefyra/utils.py", line 107, in stream_copy_from_pod
    member = tar.getmember(source_path.split("/", 1)[1])
  File "/usr/lib/python3.9/tarfile.py", line 1790, in getmember
    raise KeyError("filename %r not found" % name)
KeyError: "filename 'config/peer1/peer1.conf' not found"

And after those, gefyra is not working and running gefyra status indicates it:
{
  "summary": "Gefyra is not running properly",
  "cluster": {
    "connected": true,
    "operator": true,
    "operator_image": "quay.io/gefyra/operator:0.11.4",
    "stowaway": true,
    "stowaway_image": "quay.io/gefyra/stowaway:0.11.4",
    "namespace": true
  },
  "client": {
    "version": "0.11.4",
    "cargo": true,
    "cargo_image": "gefyra-cargo:20221019000235",
    "network": true,
    "connection": false,
    "containers": 0,
    "bridges": 0,
    "kubeconfig": "~/.kube/config",
    "context": "colima",
    "cargo_endpoint": "<IP_ADDRESS>:31820"
  }
}

What did you expect to happen?
No errors
How can we reproduce it (as minimally and precisely as possible)?
on M1 mac:

brew install colima
colima start
gefyra up
gefyra status

What Kubernetes setup are you working with?
k3s ver: v1.23.6+k3s1
OS version
Darwin ventsislavg 22.1.0 Darwin Kernel Version 22.1.0: Tue Sep 27 22:08:45 PDT 2022; root:xnu-8792.41.6~5/RELEASE_ARM64_T6000 arm64
Anything else we need to know?
The current version doesn't support docker contexts.
Check this issue for a workaround: https://github.com/gefyrahq/gefyra/issues/210

I currently don't have a Mac M1 at hand - however my team and I will look into this. Thank you for the brilliant description and all the details!

Could you provide us with the log from the stowaway pod? It's running in the Gefyra namespace.
Are you running the k3s cluster locally? Also on ARM?

@SteinRobert yes, I've specified the versions in Kubernetes Setup and OS version sections.
This is the log from the stowaway:
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing...
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 01-migrations: executing...
[migrations] started
[migrations] no migrations found
[cont-init.d] 01-migrations: exited 0.
[cont-init.d] 02-tamper-check: executing...
[cont-init.d] 02-tamper-check: exited 0.
[cont-init.d] 10-adduser: executing...

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/

Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
WireGuard: https://www.wireguard.com/donations/

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    1000
User gid:    1000
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 40-confs: executing...
  ****
**** No wg0.conf found (maybe an initial install), generating 1 server and 1 peer/client confs ****
grep: /config/peer*/*.conf: No such file or directory
Adding <IP_ADDRESS>/16 to wg0.conf's AllowedIPs for peer 1
PEER 1 QR code:
█████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████
████ ▄▄▄▄▄ █  █▀█ █▀█▀▀ ▄██▀ █▀▀▀██▄▀████▀ ▄██▀▄▄▀▄ ██ ▄▄▄▄▄ ████
████ █   █ █    ▄ ██▀▀▀▄██▀ ▄█▄▄ ▄▄▀▀▀▀ ▀ █▀██▄ ▄▀▄ ██ █   █ ████
████ █▄▄▄█ █▀▀▄▀█ ▀▀█▄▄▀█▄▄█   ▄▄▄ ▄█▄ ▀ █▀▀▀█ ▀▀▀▀▄██ █▄▄▄█ ████
████▄▄▄▄▄▄▄█▄█▄█ ▀▄▀ ▀▄▀ █ ▀▄█ █▄█ █▄█▄▀▄▀ █ ▀▄█▄█▄█ █▄▄▄▄▄▄▄████
████▄▄██ ▄▄▀█ ▄█▀▄█▀▀ ▀▄███  ▄▄ ▄▄▄   ▄█ █▄  █ ▄ ▀ █▄██▄▀▄▄  ████
████▀█▀██▀▄▀▄▄▀▀▀▄ ▀ ▄█ ▀▀█▀█▄▄ ▄ ▀▄    ▄ ▀ ▀ ███ ▄  ▀▄▀▄█▄█▄████
████▄███▄ ▄██▀▀▄▄▀▀█▄▀ ▀█▄▄█  ██▄▄██▀██▀▀█▀ ▄▄▀▄▀▀▄█ ▀▄▄▀█▄▄ ████
█████ ▀  █▄▄  ▀▄▄ ▄ ▄ ▄▄  █▄██▀▀▀▄▀▄▄▄▄ ▄█ ▀█▄ ▄█▄ █▀▀█ ▄▄▀▀▄████
████▄▄ █ ▀▄ ▀ ▀▀▄ ██▀██ ▄█▀█▄▄ ▀▀█    ▀ ▀▀▄▀ ▄▄█ ▀ ▀▄▀▀██▀ ▀▄████
████▀ ██▄█▄▀▀▄▄█▄▀█▄█▄ █▀ ▄▀▀ █ █▄▄▄▀▄▀▀▄██▀   ▀ ▄ ██▀█▄▀█▀▄▀████
█████   ▀▄▄▀▄ ▀█ ▄ ▀▀ █▀ █ █▄▄▄▀▄█▀▄ ▄▀▀██  █▄ █  ▀█▀▄▀ ▄█ █▀████
████ ▀█▀█▀▄███▄▄█▄▄▄█ █▄██▀ ▄█   ▄ ▄▄▀▄▀▄█▀█ ▄▄▄█ ██▀█   ▄▀ █████
█████▄▄ ▀▄▄█▀ ▀ ▄█ ▄▀ █▀██▄▄ ▄ █▀▄▄▄███▄▀█ ▀▀▄█ ▄███▄▀▄ ▄▄██ ████
█████▀█▀ ▄▄▄ ▄▀ ▀▄ ▀▄▀ ▄█▄ ███ ▄▄▄ █▄ ▄█▄▄█ ▀ ██  ▀▄ ▄▄▄ ██ ▄████
████▄██  █▄█ ▄▀█▀ ██▄▄▀█ ▀███  █▄█ █ ▀▄▀▀▀▀▀▄█ ▀▀ █▄ █▄█ ██▄▀████
████▄▀█▀ ▄▄  ▀█ ▀█   ▀ ▀█▄▀█▄▀▄▄ ▄▄▄▀▄█ ▀▀ ▀ █ █▀▄█▀ ▄  ▄▄▀▀▄████
████  ███▄▄ ▄ ▀  ▀██▀█  ▄▄▄▀█▄▄▀▄▄▀▄█▀▄█▀▀ █   ▀▄▄███▄▀ ▄██  ████
████▄█▀ █▀▄▀ ███ ▀ ▄▄ █▀▄▄▀  ▀▄▀▄ █▄█▄ █▄▀▄█ ▄ ▄ ▄▀ █▀ █ ██▄ ████
████ ▄▀  ▄▄█▀▀ ▀▀ ▀▄█  ▄▄▀▄█ ▄███▄█▀▄▄█▄▀▄▄▀ ▄▄▀▄█▀▀    █ ▀▄▀████
████ ▄ ██▄▄▄▀█ ███ ▀ ▀█▀ ▄▀▄▀▀▀▄▄ ▄▄▄▄▄█▄▄▀▄▀ ██▀▄▄ █▀ ▄█ ▀██████
████▀█ ▀██▄ ▄ ██▀▄▄▄ █▄ █▄▀█▀█▀ ▀ ▄  ███ ▀ ▀▀███ ▀▀▄█▄ ▀█▀▄▄▄████
████▄▄▄   ▄█▄▄▀▀▀▄ █ ▄█▄█▀█▀▀██ ▄ █▄   ██▄█▄██▀██▄  ▀▄▀▀▄▄▄▀▄████
████▀█  ██▄██  ▄▄▄▀▄▄▀ ▄▀▄▄█ ██▀█  █▀ █ ▀▄█▀█▄  ▀▀█▄█▄█▀  █▀ ████
████ ▀ ▀▀▄▄▄▀▀▄  ▀▄▀ ▀▀▀▀▀▀▄█ █▄▀▄▀██▄▄▀▄ ▀▀▄  ▄▀▄██▀▄█ █▄▀ █████
██████████▄▄▀▄ ▄▄▀▄█ ▄▄  █ █ ▄ ▄▄▄   █ ██▄▀█ ▄▄▀██▄▀ ▄▄▄ ▀▀▀█████
████ ▄▄▄▄▄ █▀▀ ▀▀ ▄▄█ █▄ █▄▄██ █▄█ ▄█▄ ▀ █ ▄▀ ▀    ▀ █▄█  █ ▄████
████ █   █ █▄▄▄█▄▀ ▀▀█ ▀ ▄ ▀▄▀▄▄ ▄▄ ▄ █▀▀█ ██  ▀ ▀▀▀▄  ▄ █▀▀▀████
████ █▄▄▄█ █▀█▀▀ ▄▀▄█▄▄▄██ ▀ ▀▄ ▀█ █▄ ▄█▄▄█▄ ▀█▄██▀▄ ▄▀▀  ▀██████
████▄▄▄▄▄▄▄█▄█▄█▄▄█▄██▄███▄▄█▄▄▄▄█▄▄█▄▄▄▄▄█▄██▄█▄██▄▄▄█▄█▄▄█▄████
█████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████
[cont-init.d] 40-confs: exited 0.
[cont-init.d] 90-custom-folders: executing...
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2022/10/20 13:17:38 [notice] 388#388: using the "epoll" event method
2022/10/20 13:17:38 [notice] 388#388: nginx/1.20.2
2022/10/20 13:17:38 [notice] 388#388: built by gcc 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)
2022/10/20 13:17:38 [notice] 388#388: OS: Linux 5.15.68-0-virt
2022/10/20 13:17:38 [notice] 388#388: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2022/10/20 13:17:38 [notice] 388#388: start worker processes
2022/10/20 13:17:38 [notice] 388#388: start worker process 414
2022/10/20 13:17:38 [notice] 388#388: start worker process 415
2022/10/20 13:17:38 [notice] 388#388: start worker process 416
2022/10/20 13:17:38 [notice] 388#388: start worker process 418
2022/10/20 13:17:38 [notice] 388#388: start worker process 420
2022/10/20 13:17:38 [notice] 388#388: start worker process 421
2022/10/20 13:17:38 [notice] 388#388: start worker process 422
2022/10/20 13:17:38 [notice] 388#388: start worker process 423
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add <IP_ADDRESS> dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add <IP_ADDRESS>/32 dev wg0
[#] ip -4 route add <IP_ADDRESS>/16 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
.:53
CoreDNS-1.10.0
linux/arm64, go1.19.1, 596a9f9

@ventsislav-georgiev everything here looks pretty normal. Could you provide us with the complete operator log? Sorry for the inconvenience. I tried to reproduce this with an ARM setup - it also failed the first time - however the operator retries to copy the file multiple times, after the 2nd try everything works fine.

We've been able to reproduce this issue. Actually it's a setup issue + we should probably add some more convenience checks/logs in Gefyra.
Your colima VM needs a network address:
colima start --kubernetes --network-address

This networks address is basically also the endpoint for your Kubernetes cluster:
colima list
PROFILE    STATUS     ARCH      CPUS    MEMORY    DISK     RUNTIME       ADDRESS
default    Running    x86_64    2       2GiB      60GiB    docker+k3s    <IP_ADDRESS>

Running gefyra up with this endpoint works as expected:
gefyra up --endpoint=<IP_ADDRESS>:31820

This should resolve the connection issue.
However, from my point of view there are 2 things we could adapt to make this process more smooth:

Actually we have a probe whether the Wireguard connection works (ping). For some reason this exits with 0 which indicates that the connection is working even though it is not. We need to investigate what exactly is happening here.
We try to detect the endpoint automatically (if not provided). This does not seem to work with colima as it does with docker. We're spinning up a container in this case https://github.com/gefyrahq/gefyra/blob/main/client/gefyra/configuration.py#L109 to find out the correct IP address. Colima only provides us with a local address which is wrong in this case. This could be solved by adding a --colima flag to know whether K8s is run within colima (since the docker context is kind of not related to where K8s runs).

Plus we should probably add this to our Getting Started guides in the documentation to help people using Gefyra when working with Colima.
@ventsislav-georgiev would be great if you could try out the given commands. If everything works, please let us know.

Thanks! I will be able to test it next week.

Was just wondering - @ventsislav-georgiev did you have the time to check out my comment?  I've already upgraded to macOS Ventura and colima has issues with exposing network address on it. ref: https://github.com/abiosoft/colima/issues/457

Oh no this is kind of unfortunate. Thank you for the quick update, though.
As long as we cannot connect to the node through the --endpoint Gefyra can't work its magic. It is absolutely necessary to reroute the network traffic accordingly.
Let's keep an eye on this.

Isn't it possible to make it work with <IP_ADDRESS>? Since colima automatically port-forwards anything from the VM on the host. If Gefyra creates a NodePort service in the cluster, the port will be open on localhost on the host.

Hey I'll talk to my colleague on this matter later - however from my understanding it is not possible to resolve <IP_ADDRESS> from inside the cargo container to your machines localhost. I'll get back to you on this though.

Calling the host from the cluster is done in colima via the <IP_ADDRESS> IP. ref: https://github.com/lima-vm/lima/blob/master/docs/network.md#host-ip-19216852

Hey @SteinRobert, unfortunately I was not able to test it the way you described. I've already upgraded to macOS Ventura and colima has issues with exposing network address on it. ref: abiosoft/colima#457

This should be resolved now.

@abiosoft thank you for fixing this and letting us know!


py3.6

UnicodeDecodeError: 'gbk' codec can't decode byte 0x92 in position 24783: illegal multibyte sequence

@CastleDream do you know what example that corresponds to in SST? any way to pinpoint what that byte is?

This problem recurs in Windows(caused by read d3.min.js). The problem can be solved by adding encoding="utf-8" in this line


spinbox issue

Hi,
I'm testing spinbox object with stm32 and ili9341, but results are the same with simulator.
In spinbox digit count and decimal format settings lv_spinbox_set_digit_format:
setting "separator_position" to 0, decimal point is always shown and cursor don't wraps from last digit to first.

@AloyseTech can you have look at it?

@ScarsFun
I pushed some fixes for spinbox. It is working well now?

Hi guys,
Sorry I’m not able to help right now. I have a lot of work on my side.

@AloyseTech No problem, thank you for the feedback!

by setting "separator_position" to 0 decimal point is no more showed but cursor stay fixed an less significative digit.
There is a problem with ranges too: by setting, for example, min to -99 and max to 999, I'm able to set the most significative digit to -1 turning the encoder with cursor on hundreds digit and decreasing from a positive value.

I reviewed the spinbox's core code and made some updates and fixes. I tested with several different settings and it seemed good to me.
The updates are in the master branch.

Works well now.
Thanks!

Awesome!

Thanks @kisvegabor for dealing with this


Power consumption analysis of apps and system design

Summary

We should provide an overlook of the applications power consumption.
Why do we need this ?

To be able to showcase the system power performance.
What is already there? What do you see now?

Power consumption analysis of basic apps and design analysis of battery consuming events.
What is missing? What do you want to see?

Diagrams and Otti power analysis profiles.
How do you propose to document this?

Use Otti arc power analyzer and create some nice gifs and documentation around them.
Can you do this yourself and submit a Pull Request?

All.

@azerimaker anyone who can take this over?


Implement COSE as signing envelope

I'd like to see Notary v2 support CBOR Object Signing and Encryption (COSE) as the signing envelope for content, as it is flexible to support all of the Nv2 signing requirements including IETF draft specs on support for x.509.
Also, COSE has broader alignments across the industry in CoMID/CoSWID, and standards for software manifests and remote attestation including C2PA .
Consider this as an update to Issue #99 .

COSE is based on CBOR literally, which is conciser and faster than JSON.
Here is an comparison on the encoded structure size (based on RFC7049 E.6):
+---------------+-------------------------+
| Format        | [1, [2, 3]]             |
+---------------+-------------------------+
| RFC 713       | c2 05 81 c2 02 82 83    |
|               |                         |
| ASN.1 BER     | 30 0b 02 01 01 30 06 02 |
|               | 01 02 02 01 03          |
|               |                         |
| MessagePack   | 92 01 92 02 03          |
|               |                         |
| BSON          | 22 00 00 00 10 30 00 01 |
|               | 00 00 00 04 31 00 13 00 |
|               | 00 00 10 30 00 02 00 00 |
|               | 00 10 31 00 03 00 00 00 |
|               | 00 00                   |
|               |                         |
| UBJSON        | 61 02 42 01 61 02 42 02 |
|               | 42 03                   |
|               |                         |
| CBOR          | 82 01 82 02 03          |
| JSON          | 5b 31 2c 5b 32 2c 33 5d |
|               | 5d                      |
+---------------+-------------------------+

Since CBOR supports byte strings (major type 2) natively, it does not require base64 encoding family as in JSON. Thus signatures and certificates, which are in binary forms, can have smaller sizes in CBOR than in JSON. Therefore, if we do move signature content from a blob to annotations #123, we can have a much smaller manifest.

Here's the prototype plugin notation-cose for COSE signing and verification.
Using the same key and certificate chain, the COSE signature is much smaller than the JWS signature signing the same content:

COSE signature: 1263 bytes
JWS signature: 1808 bytes

For folks to review and provide feedback, a doc comparing COSE with other signing formats.
https://docs.google.com/document/d/18YVGA4mq45wfUkWrAqWkymzdHRcXxlwINKXnEp86L0w/edit#

COSE work is progressing nicely within the close branch.
Upstream go-cose work is finalizing

The first veraison/go-cose security review is in
go-cose has also completed an rc.1 release, only pending 1.0.0 based on implementation verifications.
As a result, we'd like to bring this into current work efforts.

Thanks for sharing the updates @SteveLasker , I've started looking into the external security review and other details.


All - clean up double blank lines

Textmate + Regex
Find: ^\s*\n\Z
Replace: completely blank
dc36ae4


Fruits Classification

Pull Request for DL-Simplified 💡
Issue Title : Fruits Classification (#15)

Info about the related issue (Aim of the project) :  Create a DL model to classify the images of the fruits given in the dataset.
Name: Valiaparambil Ryan Taffy
GitHub ID: vryan-06
Email ID<EMAIL_ADDRESS>Idenitfy yourself: (Mention in which program you are contributing in. Eg. For a JWOC 2022 participant it's, JWOC Participant)  SSOC - 2022

Closes: #15
Describe the add-ons or changes you've made 📃
Give a clear description of what have you added or modifications made
I have solved the problem using four different approaches(CNN, VGG16, Inception-ResNet, MobileNet).
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Built 4 models that solve the issue

How Has This Been Tested? ⚙
Describe how it has been tested
Describe how have you verified the changes made
Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

Requested changes have been made.
Thank you


Adds support for ESC13

Adds support for detection of ESC13 (https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53)

Hello,
I've got a template for which your PR returns that it is vulnerable to ESC13.
In the output of Certipy, I get the following:
[...]
Issuance Policies                   : <IP_ADDRESS>.4.1.305<IP_ADDRESS>
Linked Groups                       :
[...]
ESC13                             : 'DOM\\Authenticated Users' can enroll, template allows client authentication and issuance policy is linked to group ['']

When reading the blog post of specterops' , I understand that the template should be marked vulnerable if there's a linked group which is not the case here. Therefore I wonder if the PR should return vulnerable this template.

Hello @gbe ,
indeed, it looks like my code makes the assumption that the msDS-OIDToGroupLink attribute is set on the OID object.
However the Microsoft documentation says this attribute is not mandatory.
It would be worth adding a check that this attribute is non-empty, I may do it whenever I find time, otherwise, feel free to provide a patch!
Cheers,
Sylvain

Unfortunately I cannot test and confirm as I no longer have access to the Certificate Authority in question. Thanks a lot for implementing a fix (even if not tested).


Fix ListConfigurations returning empty config objects

Per OSGi standard, ListConfigurations should only return config objects containing properties (i.e. not an empty config).
Signed-off-by: The MathWorks, Inc<EMAIL_ADDRESS>

Codecov Report

Merging #663 (8cbfbc7) into development (47a3f92) will decrease coverage by 0.99%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           development     #663      +/-   ##
===============================================
- Coverage        90.49%   89.49%   -1.00%
===============================================
  Files              249      120     -129
  Lines            13483     8076    -5407
===============================================
- Hits             12201     7228    -4973
+ Misses            1282      848     -434

Impacted Files
Coverage Δ

framework/src/service/ServiceListeners.h
0.00% <0.00%> (-100.00%)
:arrow_down:

util/include/cppmicroservices/util/BundleObjFile.h
0.00% <0.00%> (-100.00%)
:arrow_down:

util/include/cppmicroservices/util/DataContainer.h
0.00% <0.00%> (-100.00%)
:arrow_down:

util/src/BundleObjFile.cpp
71.42% <0.00%> (-28.58%)
:arrow_down:

framework/src/bundle/BundleRegistry.cpp
81.01% <0.00%> (-10.96%)
:arrow_down:

tools/jsonschemavalidator/main.cpp
82.50% <0.00%> (-6.03%)
:arrow_down:

framework/src/service/ServiceRegistrationBase.cpp
76.71% <0.00%> (-5.94%)
:arrow_down:

...mework/src/service/ServiceReferenceBasePrivate.cpp
87.12% <0.00%> (-5.83%)
:arrow_down:

framework/src/service/ServiceListeners.cpp
95.00% <0.00%> (-5.00%)
:arrow_down:

framework/src/bundle/BundleResourceContainer.cpp
90.18% <0.00%> (-4.01%)
:arrow_down:

... and 198 more

yes, I'm looking into it.

missing part of the fix. apparently I wrote the test but didn't actually fix the bug... oops.


"cabal build all"  fails

OS
Your OS:
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Cable version :
cabal-install version <IP_ADDRESS>
compiled using version <IP_ADDRESS> of the Cabal library
ghc version:
The Glorious Glasgow Haskell Compilation System, version 8.10.7
Additional context
I tried these few steps also
1)cabal clean
2)cable build all
3)sudo apt-get install libsodium-dev
4)sudo apt install libscrypt-dev
Problem Report
Installing   regex-pcre-builtin-<IP_ADDRESS>.8.44 (lib)
Completed    regex-pcre-builtin-<IP_ADDRESS>.8.44 (lib)
Installing   Cabal-syntax-<IP_ADDRESS> (lib)
Completed    Cabal-syntax-<IP_ADDRESS> (lib)
Failed to build scrypt-0.5.0. The failure occurred during the configure step.
Build log (
/home/ubuntu/.cabal/logs/ghc-8.10.7/scrypt-0.5.0-9dc7f5056f17df13813f95e91bb667ceed7dc3e60a8b91da16ab03a3c4c8a06b.log
):
Configuring library for scrypt-0.5.0..
cabal-<IP_ADDRESS>: Missing dependency on a foreign library:

Missing (or bad) header file: crypto_scrypt.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.

cabal: Failed to build scrypt-0.5.0 (which is required by test:unit from
cardano-wallet-2023.7.18, exe:mock-token-metadata-server from
cardano-wallet-2023.7.18 and others). See the build log above for details.

I have just built git HEAD with ghc-8.10.7 without seeing that issue. Also,there is no crypto_scrypt.h header file on my system. Not sure what this is all about?

Based on error message - it seems he is compiling cardano-wallet anyways, should be closed here...
He is copy pasting message without proper context across all repos and dev channels without looking at replies to follow threads (not the first time)

@SamirBitzees What package are you compiling?

@SamirBitzees What package/repo are you compiling?

"I am attempting to compile the cardano-wallet package from the cardano-wallet repository. Specifically, I am working with the version labeled as 2023.7.18."

I have just built git HEAD with ghc-8.10.7 without seeing that issue. Also,there is no crypto_scrypt.h header file on my system. Not sure what this is all about?

"It's interesting to note that you didn't encounter this issue, and I appreciate your input. In my case, I'm using ghc-8.10.7 on Ubuntu 22.04.3 LTS, and I did indeed encounter the issue with the missing crypto_scrypt.h header file during the build process. It's possible that this issue is specific to my environment or configuration.
I am using this development guide document "[https://developers.cardano.org/docs/get-started/installing-cardano-wallet]
To provide some additional context, I performed the following steps before attempting the build:
cabal clean
cable build all
Installed system packages libsodium-dev and libscrypt-dev.
Despite these steps, the issue persisted. Any insights or suggestions on how to resolve this would be greatly appreciated."

If you have a problem with cardano-wallet the raise an issue in that repository.


WIP: notebook comments overhaul

Includes:

working message options in diary comments
emoji reactions to diary comments
emoji reactions to notes
refs for note comments
replies for comments (this method could be used for single-message-replies in chat)
setting the comment list order to "oldest" and not showing the dropdown.

still needs:

feels in outlines (we're currently pulling in a note for each DiaryListItem, which makes outlines pointless) from the backend. Might require state transition?
consistent quip times from the backend. they seem to change sporadically.

What's the state of this?

@urcades have you guys settled on whether to include emoji reactions for notes?


Bundler bundles outdated JAR from Maven Builder

Hi everyone!
In my project, I'm having Java modules within an MTA archive. I'm building those with the default Maven builder.
The default config, however, does only run mvn -B package, and not the clean goal. This causes, after a change in the pom version, multiple jar files to be present in the target folder - of which only the first, meaning the one with the lower version number, is copied over to the mtar. The newly built version is not included.
This is bad, as there are many Java services in my MTA (so I don't want to clean each of them individually) and I don't want to deviate from the defaults provided by the MBT too much.
Please consider adapting the default behavior by either

choosing the latest/newest artifact matched by the build-result (in my case the latest target/*.jar), e.g. by the last changed date
adapting the default command to mvn clean package

Thank you very much for your support!
Kind regards
Lukas
Please provide the following info:

MBT Version: 1.0.14
OS Version: Windows 10

Hi Lukas,
As the current maven builder is used by multiple users we cannot change its behavior easily.
Please consider using a 'custom' builder for your module instead and define commands that satisfied your needs as described here: https://sap.github.io/cloud-mta-build-tool/configuration/#configuring-the-custom-builder.
Regards
Natalia

Hi @LukasHeimann,
I have discussed the topic with the experts and we are planning to implement your proposal (adapting the default command to mvn clean package)
Please track the release notes for the update.
Thank you for the idea.
Natalia


Update submodules: vibe-core, eventcore to the latest

Update submodules: vibe-core, eventcore to the latest

clang: error: no such file or directory: 'source/scpp/build/BallotProtocol.o'

Is there really some hidden race condition in our CI?


Modernize examples

This PR updates examples to the currently latest HAL/RTIC crates, making them relevant again. Hopefully, this provides a solid base for later embedded-hal 1.0 updates, too.
As I don't have an STM32F10x, I haven't been able to test them, but I'm confident in everything except the RTIC examples.

Merged into #181


CPP: Constructors in derived classes

Description
I will provide a documentation on constructors in derived classes.
Domain
C/CPP
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

/assign


Document functions in DURCGenerator.php

All of the functions in DURCGenerator.php should be documented..

Is this done? Not done?

They seem to all be documented.


BigQuery connection for location != US

Hi,
I was trying to use TidierDB.jl to connect to a private BigQuery database and I had an error due to the hardcoded location in the collect_gbq() and get_table_metadata() function of GBQExt.jl file (line 50 and line 89) :
    query_data = Dict(
    "query" => query,
    "useLegacySql" => false,
    "location" => "US")

In order to support other locations (EU, us-west1,...) provider by GCP, the location should be a parameter of this function so the user can specify the location of his database. Another way is to delete this part since it works without, but not sure if it's good practice...
Thanks

Hi thanks for bringing this up.
Have you confirmed it works without it ?
If so, I may opt to use that for the time being.
Either way I'll release a new version that should work for you in the next day or so

Well, I haven't done a ton of test but yes, it works for me for different locations if you just don't specify the location 🙂 !

De : Daniel Rizk @.>
Envoyé : lundi 7 octobre 2024 18:20
À : TidierOrg/TidierDB.jl @.>
Cc : Erwan Pierre @.>; Author @.>
Objet : Re: [TidierOrg/TidierDB.jl] BigQuery connection for location != US (Issue #71)
Hi thanks for bringing this up.
Have you confirmed it works without it ?
If so, I may opt to use that for the time being.
Either way I'll release a new version that should work for you in the next day or so
—
Reply to this email directly, view it on GitHubhttps://github.com/TidierOrg/TidierDB.jl/issues/71#issuecomment-2397370289, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKUBEXBQGCZXIJ3O5U33AETZ2KYGPAVCNFSM6AAAAABPQJBA7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJXGM3TAMRYHE.
You are receiving this because you authored the thread.Message ID: @.***>

I changed the GBQ connection to work as follows so that the all underlying function have access to the user specified location. I also improved type mapping when collecting to a dataframe.
conn = connect(gbq(), "json_cred_path", "location")

Before releasing the next version, I have to polish up a few things, but you are welcome to try out the updated version by installing with this line and then if anything else comes up, please do let me know.
using Pkg; Pkg.add(url = "https://github.com/TidierOrg/TidierDB.jl", rev = "catch-a-bug-then-write-a-test")

This should now be fixed in v.5.0 which is heading to the registry, please reopen this issue/start a new one if there continues to be an issue or I can do anything else to improve the GBQ backend


Error in executing ./patch-arch.sh

Required Info

Camera Model
{ L515}

Firmware Version
{librealsense}

Operating System & Version
{Archlinux}

Kernel Version (Linux Only)
{5.9.3)

Hello,
I am trying to install librealsense in my archlinux, but when I executed ./patch-arch.sh,  the following error appears when I am patching:

patch -p1 < ../../realsense-camera-formats.patch

patching file drivers/media/usb/uvc/Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/usb/uvc/Makefile.rej
patching file drivers/media/usb/uvc/uvc_driver.c
Hunk #1 succeeded at 214 with fuzz 2 (offset 66 lines).
patching file drivers/media/usb/uvc/uvcvideo.h
Hunk #1 succeeded at 129 with fuzz 2 (offset 10 lines).
patching file include/uapi/linux/videodev2.h
Hunk #1 FAILED at 621.
1 out of 1 hunk FAILED -- saving rejects to file include/uapi/linux/videodev2.h.rej
The kernel version of my archlinux is Linux 5.9.3-arch1-1 and the downloaded kernel version in the ./patch-arch.sh  for patching is Linux 5.9.3. I read that the problem could be a different kernel version between my version of linux and the patching kernel but in my case that is not true so I do not know what to do....
I will appreciate a lot your help!

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ R200 / F200 / SR300 / ZR300 / D400 }

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
{Win (8.1/10) / Linux (Ubuntu 14/16/17) / MacOS

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC/Raspberry Pi/ NVIDIA Jetson / etc..

SDK Version
{ legacy / 2.. }

Language
{C/C#/labview/nodejs/opencv/pcl/python/unity }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
<Describe your issue / question / feature request / etc..>

Hi @ganglesmunne
Are you still running into this issue with the latest librealsense SDK 2.40?

Hey! I had the same problem, but I solved adding in the lines where there are patch -p1  ----> patch -p1 --fuzz 3 .
I also had more problems which I solved following the instructions of this link:
https://github.com/IntelRealSense/librealsense/issues/4271
In the same time, I needed to run the patch everytime when I reboot the computer. However, surprisely when the kernel of Arch is uptate, then the patch becomes permenet.

Excellent you were able to solve the problem.


[Enhancement] Tablet UI

Is your feature request related to a problem? Please describe.
Tablet UI could be better, it's usable, but not perfect.
Describe the solution you'd like
Navigation rail, like google photos uses, centered settings, info button wouldn't show a popup, but a sidebar
Describe alternatives you've considered
Trying out google photos app for better big screen experience

I've had some trial and error with the navigation rail, but honestly I don't have a tablet right now to properly create the perfect navigation for big screens, but (as requested in another issue) I'll add the option to use the old navigation bar type (+ rail)