Failed to execute job because missing mist_worker.jar

Context

Stack includes: 1 Spark Master (without mist) + Worker (without mist) + Mist Master
Spark version 2.4.0
Mist version 1.1.0

downtime="3600s"
max-conn-failures=5
max-parallel-jobs=1
precreated=false
run-options=""
spark-conf {
    "spark.master"="spark://spark-master:7077"
    "spark.submit.deployMode"="cluster"
    "spark.dynamicAllocation.enabled"="true"
    "spark.shuffle.service.enabled"="true"
}
streaming-duration="1s"

Log
mist_1           | 2018-11-09 10:59:42,857 INFO  akka.event.slf4j.Slf4jLogger Slf4jLogger started
spark-master_1   | 2018-11-09 10:59:42,937 INFO  org.apache.spark.deploy.master.Master Registering worker 29c1c06e51e3:9099 with 8 cores, 13.7 GB RAM
spark-worker_1   | 2018-11-09 10:59:42,966 INFO  org.apache.spark.deploy.worker.Worker Successfully registered with master spark://spark-master:7077
mist_1           | 2018-11-09 10:59:43,184 INFO  akka.remote.Remoting Starting remoting
mist_1           | 2018-11-09 10:59:43,412 INFO  akka.remote.Remoting Remoting started; listening on addresses :[akka.tcp://mist@<IP_ADDRESS>:2551]
mist_1           | 2018-11-09 10:59:43,521 INFO  org.flywaydb.core.internal.util.VersionPrinter Flyway 4.1.1 by Boxfuse
mist_1           | 2018-11-09 10:59:43,826 INFO  org.flywaydb.core.internal.dbsupport.DbSupportFactory Database: jdbc:h2:file:/opt/mist/data/recovery.db (H2 1.4)
mist_1           | 2018-11-09 10:59:44,014 INFO  org.flywaydb.core.internal.command.DbValidate Successfully validated 2 migrations (execution time 00:00.018s)
mist_1           | 2018-11-09 10:59:44,027 INFO  org.flywaydb.core.internal.command.DbMigrate Current version of schema "PUBLIC": 2
mist_1           | 2018-11-09 10:59:44,027 INFO  org.flywaydb.core.internal.command.DbMigrate Schema "PUBLIC" is up to date. No migration necessary.
mist_1           | 2018-11-09 10:59:44,540 INFO  io.hydrosphere.mist.master.MasterServer$ LogsSystem started
mist_1           | 2018-11-09 10:59:46,042 WARN  org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
mist_1           | 2018-11-09 10:59:46,995 INFO  akka.event.slf4j.Slf4jLogger Slf4jLogger started
mist_1           | 2018-11-09 10:59:47,264 INFO  akka.remote.Remoting Starting remoting
mist_1           | 2018-11-09 10:59:47,601 INFO  akka.remote.Remoting Remoting started; listening on addresses :[akka.tcp://mist-info-provider@<IP_ADDRESS>:40605]
mist_1           | 2018-11-09 10:59:48,197 INFO  io.hydrosphere.mist.master.MasterServer$ FunctionInfoProvider started
mist_1           | 2018-11-09 10:59:48,646 INFO  io.hydrosphere.mist.master.MasterServer$ Main service started
mist_1           | 2018-11-09 10:59:49,686 INFO  io.hydrosphere.mist.master.MasterServer$ Http interface started
mist_1           | 2018-11-09 10:59:49,692 INFO  io.hydrosphere.mist.master.Master$ Mist master started
mist_1           | 2018-11-09 11:00:04,797 INFO  io.hydrosphere.mist.master.execution.ContextFrontend Starting executor k8s-master_96a1ce36-460a-4f3b-b8ba-735ddb2a33fe for k8s-master
mist_1           | 2018-11-09 11:00:04,833 INFO  io.hydrosphere.mist.master.execution.ContextFrontend Context k8s-master - connected state(active connections: 0, max: 1)
mist_1           | 2018-11-09 11:00:04,845 INFO  io.hydrosphere.mist.master.execution.workers.starter.LocalSparkSubmit Try submit local worker k8s-master_96a1ce36-460a-4f3b-b8ba-735ddb2a33fe_1, cmd: /opt/spark/bin/spark-submit --conf spark.eventLog.enabled=true --conf spark.shuffle.service.enabled=true --conf spark.submit.deployMode=cluster --conf spark.master=spark://spark-master:7077 --conf spark.eventLog.dir=/data/spark/events --conf spark.dynamicAllocation.enabled=true --conf spark.eventLog.compress=true --class io.hydrosphere.mist.worker.Worker /opt/mist/mist-worker.jar --master <IP_ADDRESS>:2551 --name k8s-master_96a1ce36-460a-4f3b-b8ba-735ddb2a33fe_1
spark-master_1   | 2018-11-09 11:00:07,315 INFO  org.apache.spark.deploy.master.Master Driver submitted org.apache.spark.deploy.worker.DriverWrapper
spark-master_1   | 2018-11-09 11:00:07,318 INFO  org.apache.spark.deploy.master.Master Launching driver driver-20181109110007-0000 on worker worker-20181109105941-29c1c06e51e3-9099
spark-worker_1   | 2018-11-09 11:00:07,355 INFO  org.apache.spark.deploy.worker.Worker Asked to launch driver driver-20181109110007-0000
spark-worker_1   | 2018-11-09 11:00:07,367 INFO  org.apache.spark.deploy.worker.DriverRunner Copying user jar file:/opt/mist/mist-worker.jar to /opt/spark/work/driver-20181109110007-0000/mist-worker.jar
spark-worker_1   | 2018-11-09 11:00:07,390 INFO  org.apache.spark.util.Utils Copying /opt/mist/mist-worker.jar to /opt/spark/work/driver-20181109110007-0000/mist-worker.jar
spark-worker_1   | 2018-11-09 11:00:07,400 INFO  org.apache.spark.deploy.worker.DriverRunner Killing driver process!
spark-worker_1   | 2018-11-09 11:00:07,404 WARN  org.apache.spark.deploy.worker.Worker Driver driver-20181109110007-0000 failed with unrecoverable exception: java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar
spark-master_1   | 2018-11-09 11:00:07,460 INFO  org.apache.spark.deploy.master.Master Removing driver: driver-20181109110007-0000
spark-master_1   | 2018-11-09 11:00:12,769 INFO  org.apache.spark.deploy.master.Master <IP_ADDRESS>:40290 got disassociated, removing it.
spark-master_1   | 2018-11-09 11:00:12,770 INFO  org.apache.spark.deploy.master.Master <IP_ADDRESS>:42207 got disassociated, removing it.
mist_1           | 2018-11-09 11:00:12,897 ERROR io.hydrosphere.mist.master.execution.workers.ExclusiveConnector Could not start worker connection
mist_1           | java.lang.RuntimeException: Process terminated with error java.lang.RuntimeException: Process exited with status code 255 and out: 2018-11-09 11:00:06,479 WARN  org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library for your platform... using builtin-java classes where applicable;2018-11-09 11:00:12,424 ERROR org.apache.spark.deploy.ClientEndpoint Exception from cluster was: java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar;java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar;	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86);	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102);	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107);	at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:526);	at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253);	at java.nio.file.Files.copy(Files.java:1274);	at org.apache.spark.util.Utils$.org$apache$spark$util$Utils$$copyRecursive(Utils.scala:664);	at org.apache.spark.util.Utils$.copyFile(Utils.scala:635);	at org.apache.spark.util.Utils$.doFetchFile(Utils.scala:719);	at org.apache.spark.util.Utils$.fetchFile(Utils.scala:509);	at org.apache.spark.deploy.worker.DriverRunner.downloadUserJar(DriverRunner.scala:155);	at org.apache.spark.deploy.worker.DriverRunner.prepareAndRunDriver(DriverRunner.scala:173);	at org.apache.spark.deploy.worker.DriverRunner$$anon$1.run(DriverRunner.scala:92)
mist_1           | 	at io.hydrosphere.mist.master.execution.workers.WorkerRunner$DefaultRunner$$anonfun$continueSetup$1$1.applyOrElse(WorkerRunner.scala:39)
mist_1           | 	at io.hydrosphere.mist.master.execution.workers.WorkerRunner$DefaultRunner$$anonfun$continueSetup$1$1.applyOrElse(WorkerRunner.scala:39)
mist_1           | 	at scala.concurrent.Future$$anonfun$onFailure$1.apply(Future.scala:138)
mist_1           | 	at scala.concurrent.Future$$anonfun$onFailure$1.apply(Future.scala:136)
mist_1           | 	at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
mist_1           | 	at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121)
mist_1           | 	at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
mist_1           | 	at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
mist_1           | 	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
mist_1           | 	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Job log
INFO 2018-11-09T11:58:22.53 [bec629b4-7cc4-482e-8ccb-9a7856f701d2] Waiting worker connection
INFO 2018-11-09T11:58:22.534 [bec629b4-7cc4-482e-8ccb-9a7856f701d2] InitializedEvent(externalId=None)
INFO 2018-11-09T11:58:22.534 [bec629b4-7cc4-482e-8ccb-9a7856f701d2] QueuedEvent
ERROR 2018-11-09T11:59:02.636 [bec629b4-7cc4-482e-8ccb-9a7856f701d2] FailedEvent with Error:
 java.lang.RuntimeException: Context is broken
	at io.hydrosphere.mist.master.execution.JobActor$$anonfun$io$hydrosphere$mist$master$execution$JobActor$$initial$1.applyOrElse(JobActor.scala:59)
	at akka.actor.Actor$class.aroundReceive(Actor.scala:517)
	at io.hydrosphere.mist.master.execution.JobActor.akka$actor$Timers$$super$aroundReceive(JobActor.scala:24)
	at akka.actor.Timers$class.aroundReceive(Timers.scala:44)
	at io.hydrosphere.mist.master.execution.JobActor.aroundReceive(JobActor.scala:24)
	at akka.actor.ActorCell.receiveMessage(ActorCell.scala:527)
	at akka.actor.ActorCell.invoke(ActorCell.scala:496)
	at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
	at akka.dispatch.Mailbox.run(Mailbox.scala:224)
	at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
	at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
	at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
	at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: java.lang.RuntimeException: Process terminated with error java.lang.RuntimeException: Process exited with status code 255 and out: 2018-11-09 11:58:56,046 WARN  org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library for your platform... using builtin-java classes where applicable;2018-11-09 11:59:01,870 ERROR org.apache.spark.deploy.ClientEndpoint Exception from cluster was: java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar;java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar;	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86);	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102);	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107);	at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:526);	at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253);	at java.nio.file.Files.copy(Files.java:1274);	at org.apache.spark.util.Utils$.org$apache$spark$util$Utils$$copyRecursive(Utils.scala:664);	at org.apache.spark.util.Utils$.copyFile(Utils.scala:635);	at org.apache.spark.util.Utils$.doFetchFile(Utils.scala:719);	at org.apache.spark.util.Utils$.fetchFile(Utils.scala:509);	at org.apache.spark.deploy.worker.DriverRunner.downloadUserJar(DriverRunner.scala:155);	at org.apache.spark.deploy.worker.DriverRunner.prepareAndRunDriver(DriverRunner.scala:173);at org.apache.spark.deploy.worker.DriverRunner$$anon$1.run(DriverRunner.scala:92)
	at io.hydrosphere.mist.master.execution.workers.WorkerRunner$DefaultRunner$$anonfun$continueSetup$1$1.applyOrElse(WorkerRunner.scala:39)
	at io.hydrosphere.mist.master.execution.workers.WorkerRunner$DefaultRunner$$anonfun$continueSetup$1$1.applyOrElse(WorkerRunner.scala:39)
	at scala.concurrent.Future$$anonfun$onFailure$1.apply(Future.scala:138)
	at scala.concurrent.Future$$anonfun$onFailure$1.apply(Future.scala:136)
	at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
	at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121)
	at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
	at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Local worker log
2018-11-09 11:58:24,154 WARN  org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
2018-11-09 11:58:30,109 ERROR org.apache.spark.deploy.ClientEndpoint Exception from cluster was: java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar
java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:526)
	at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253)
	at java.nio.file.Files.copy(Files.java:1274)
	at org.apache.spark.util.Utils$.org$apache$spark$util$Utils$$copyRecursive(Utils.scala:664)
	at org.apache.spark.util.Utils$.copyFile(Utils.scala:635)
	at org.apache.spark.util.Utils$.doFetchFile(Utils.scala:719)
	at org.apache.spark.util.Utils$.fetchFile(Utils.scala:509)
	at org.apache.spark.deploy.worker.DriverRunner.downloadUserJar(DriverRunner.scala:155)
	at org.apache.spark.deploy.worker.DriverRunner.prepareAndRunDriver(DriverRunner.scala:173)
	at org.apache.spark.deploy.worker.DriverRunner$$anon$1.run(DriverRunner.scala:92)

Suspicious
Seem hard code when using $MIST_HOME for folder path to mist_worker.jar on spark worker
org.apache.spark.deploy.worker.DriverRunner Copying user jar file:/opt/mist/mist-worker.jar to /opt/spark/work/driver-20181109110007-0000/mist-worker.jar
org.apache.spark.deploy.worker.Worker Driver driver-20181109110007-0000 failed with unrecoverable exception: java.nio.file.NoSuchFileException: /opt/mist/mist-worker.jar

Thank for reporting!
Could you check, if there is any additional information in logs directory?  There should be a log file that starts from local-worker.

I added more in description.
Btw, worker is using which log4j.properties. I would like to redirect all to console log

Could you also check if mist-worker.jar exists in $MIST_HOME directory on the node where Mist was run?
I've just tested your setup on my machine and it works.
Actually, logs in local-worker file are stdout from spark-submit that is used to submit mist-worker.

This is command run in worker has mist-worker.jar. It is tricky because I copy manually from Mist to worker.
mist_1           | 2018-11-09 13:26:42,772 INFO  io.hydrosphere.mist.master.execution.workers.starter.LocalSparkSubmit Try submit local worker k8s-master_e0642e8b-a3af-41ee-bc1b-faafb363341e_1, cmd: /opt/spark/bin/spark-submit --conf spark.eventLog.enabled=true --conf spark.shuffle.service.enabled=true --conf spark.submit.deployMode=cluster --conf spark.master=spark://spark-master:7077 --conf spark.eventLog.dir=/data/spark/events --conf spark.dynamicAllocation.enabled=true --conf spark.eventLog.compress=true --class io.hydrosphere.mist.worker.Worker /opt/mist/mist-worker.jar --master <IP_ADDRESS>:2551 --name k8s-master_e0642e8b-a3af-41ee-bc1b-faafb363341e_1
spark-master_1   | 2018-11-09 13:26:45,455 INFO  org.apache.spark.deploy.master.Master Driver submitted org.apache.spark.deploy.worker.DriverWrapper
spark-master_1   | 2018-11-09 13:26:45,458 INFO  org.apache.spark.deploy.master.Master Launching driver driver-20181109132645-0000 on worker worker-20181109120654-c6e613739ff2-9099
spark-worker_1   | 2018-11-09 13:26:45,509 INFO  org.apache.spark.deploy.worker.Worker Asked to launch driver driver-20181109132645-0000
spark-worker_1   | 2018-11-09 13:26:45,529 INFO  org.apache.spark.deploy.worker.DriverRunner Copying user jar file:/opt/mist/mist-worker.jar to /opt/spark/work/driver-20181109132645-0000/mist-worker.jar
spark-worker_1   | 2018-11-09 13:26:45,570 INFO  org.apache.spark.util.Utils Copying /opt/mist/mist-worker.jar to /opt/spark/work/driver-20181109132645-0000/mist-worker.jar
spark-worker_1   | 2018-11-09 13:26:45,813 INFO  org.apache.spark.deploy.worker.DriverRunner Launch Command: "/usr/lib/jvm/java-1.8-openjdk/bin/java" "-cp" "/opt/spark/conf/:/opt/spark/jars/*" "-Xmx1024M" "-Dspark.app.name=io.hydrosphere.mist.worker.Worker" "-Dspark.eventLog.enabled=true" "-Dspark.driver.supervise=false" "-Dspark.shuffle.service.enabled=true" "-Dspark.submit.deployMode=cluster" "-Dspark.jars=file:/opt/mist/mist-worker.jar" "-Dspark.master=spark://spark-master:7077" "-Dspark.eventLog.dir=/data/spark/events" "-Dspark.eventLog.compress=true" "-Dspark.dynamicAllocation.enabled=true" "-Dspark.rpc.askTimeout=10s" "org.apache.spark.deploy.worker.DriverWrapper" "spark://Worker@c6e613739ff2:9099" "/opt/spark/work/driver-20181109132645-0000/mist-worker.jar" "io.hydrosphere.mist.worker.Worker" "--master" "<IP_ADDRESS>:2551" "--name" "k8s-master_e0642e8b-a3af-41ee-bc1b-faafb363341e_1"

Just remind, worker in my failed case has nothing related to Mist, just plain spark, no mist-worker.jar. Does mist support this case?

Actually, logs in local-worker file are stdout from spark-submit that is used to submit mist-worker.
We have 2 logs: one is job-[which id?] and loca-worker-[which id?], these ids doesn't match each other.
As you said, it is from spark-submit but I didn't set any configuration and it should be in console as Spark default behavior. Any configuration to redirect log to console instead of file

Finally, I found out what's going on. I expected that in standalone mode, even for cluster mode, it is enough to provide a local path to mist-worker.jar for spark-submit.
This problem is fixed in #529
About logs. These files job-$id and local-worker-$id are creating by mist. Here local-worker is stdout from a process that mist runs when it runs a new worker. job-$id are logs that mist collets from a spark-driver application during job invocation. Both of them are used for debugging purposes.
Here you may found more information: glossary and invocation

I've just merged #529 into master.
@zero-88, it would be great if you could build mist from the master branch and get feedback if it solved your problem or not.
Feel free to reopen this issue in case if it won't help.

Thank @dos65
I will try today and let you know.
Do you intend to release hotfix version?

I will try today and let you know.
Do you intend to release hotfix version?
Great!
If it works, I'll publish 1.1.1

Awesome, works like a charm.
Please make a new release version when you have a time.
Thanks

@zero-88  Done!


Hadoop 16631: Backport HADOOP-16578 - ABFS: fileSystemExists() should not call container level apis

NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute

cherry-picked HADOOP-16578 to branch-2.


Update deps

yeoman-generator to v.0.20.1
mocha define version instead wildcard

The only dependency that actually needs updating is the generator one and I'd rather just do that when doing other improvements.

Understood :disappointed:

The reason is that I have to manually test it after doing a generator bump, which is some work, and I rather do that when I have to do it anyways because of other changes.

I totally agree with you.
Note: I tested the generator after update the dependencies. No regressions are present. As you know EJS have a similiar syntax to Lodash templating.
The only important point is to use <%= or <%- to escape characters.

Ok, cool. Then feel free to just update the generator dependency directly. But the other ones used ^ so no update needed. And I prefer to keep mocha at * as the version doesn't really matter there.


cancel_order doesn't work

I try to close an order just after i created it to test the method on the base_url="https://testnet.binancefuture.com"
but i have the following issue :
File "D:\Logiciels\Python\lib\site-packages\binance\futures\account.py", line 268, in cancel_order
return self.sign_request("DELETE", url_path, params)
File "D:\Logiciels\Python\lib\site-packages\binance\api.py", line 84, in sign_request
return self.send_request(http_method, url_path, payload, special)
File "D:\Logiciels\Python\lib\site-packages\binance\api.py", line 118, in send_request
self._handle_exception(response)
File "D:\Logiciels\Python\lib\site-packages\binance\api.py", line 171, in _handle_exception
raise ClientError(status_code, err["code"], err["msg"], response.headers)
binance.error.ClientError: (400, -2011, 'Unknown order sent.', {'Content-Type': 'application/json', 'Content-Length': '42', 'Connection': 'keep-alive', 'Date': 'Tue, 12 Apr 2022 16:28:13 GMT', 'Server': 'Bengine', 'X-MBX-USED-WEIGHT-1M': '2', 'x-response-time': '3ms', 'X-Frame-Options': 'SAMEORIGIN', 'X-Xss-Protection': '1; mode=block', 'X-Content-Type-Options': 'nosniff', 'Referrer-Policy': 'origin-when-cross-origin', 'Strict-Transport-Security': 'max-age=31536000; includeSubdomains', 'X-Cache': 'Error from cloudfront', 'Via': '1.1 e832b62df62ac7dea0463212e63d91f6.cloudfront.net (CloudFront)', 'X-Amz-Cf-Pop': 'CDG50-P2', 'X-Amz-Cf-Id': 'HHB4Beib98-164R-Sp-TL_K8MBoDIk_bLYztkzbND6AF9mg2mmeX2w=='})
my cancel_order method call is here :
clientData.cancel_order(
symbol="BTCUSDT",
orderId = orderIdOpen)
where orderIdOpen is a var i get from the new_order method's result

from the error message, it's said the order is not found as in open status, the reasons could be:

order is not found in this account
order is found, but not able to cancel:

order is cancelled
order is filled
order is expired
etc

Hi thanks for the answer. Unfortunately i create the order just before and i take back the orderId . I don’t know if it can help but i use my test account on the testnet future

I have an update i think it's because i used the new_order_test method

go to pure cancel_order function, change 'orderId is None' to 'orderId is not None'


Plugin fails to load with typedoc 0.22.3

output:
$ ./node_modules/.bin/typedoc --version
Error: The plugin typedoc-plugin-merge-modules could not be loaded.
Error: Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/lib/converter' is not defined by "exports" in /home/osesov/tizen/vscode/zplayer/node_modules/typedoc/package.json
    at new NodeError (node:internal/errors:371:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:413:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:652:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at Object.<anonymous> (/home/osesov/tizen/vscode/zplayer/node_modules/typedoc-plugin-merge-modules/dist/plugin.js:4:21)

TypeDoc 0.22.3
Using TypeScript 4.4.2 from ./node_modules/typescript/lib

If that helps - recently the same situation used to be with typedoc-plugin-markdown #249

This is caused by an intentional breaking change in TypeDoc 0.22. A lot of plugins are affected by this as you can see here: https://github.com/TypeStrong/typedoc/issues/1696
It should by easy to fix. I guess we just have to import from another path. I hope I can fix it this weekend or maybe sometime next week.
Also it would probably make sense to change the peerDependency back to not supporting newer TypeDoc versions by default.

Fixed in 3.0.2 🎉


⚠ ClamAV has degraded performance

In 737982b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 80 ms

Resolved: ClamAV performance has improved in 9e184d1.


SOLR-15733: WIP

https://issues.apache.org/jira/browse/SOLR-XXXXX

Description
Please provide a short description of the changes you're making with this pull request.
Solution
Please provide a short description of the approach taken to implement your solution.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:

[ ] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[ ] I have created a Jira issue and added the issue ID to my pull request title.
[ ] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[ ] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[ ] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

I would have waited for after https://github.com/apache/solr/pull/953 potentially but if they are straight moves - might not be an issue. git may just handle it :)

Shouldn't these all be similar to https://github.com/apache/solr/tree/main/solr/solrj-zookeeper? looks like these ended up in modules?

Agreed, modules is not for solrj code, its for server modules. We don't have a solrj folder that hosts sub-folders yet (but we will starting in Solr 10), so it should just be called solrj-streaming. (though I really don't know why streaming expressions live in client code anyways...)

Before I close this PR and start to work on a solrj-streaming PR lets be sure we don't want this to be server module.
The original streaming classes were designed to be a Java API using the decorator pattern to layer on new behaviors. This fit pretty well with the Solrj library which is Java based. So it was placed there.
When streaming expressions came around it became easy to support complex expressions that simply are not practical with the Java API. The /stream handler became the focal point which moved things towards are server side model. At this point I consider Streaming Expressions a server side tool.
My suggestion is that we make it a server side module and we can add Solrj support for sending a Streaming Expression to the stream handler.
The only reason I see to keep it a client side tool is to support existing clients that are using the Java API. Which may be reason enough.
One compromise would be to leave a small subset of TupleStream implementations in Solrj. Then move all the rest of the classes to a server side module.

I have used streaming in just a limited amount client-side. And the number of classes was quite overwhelming. And a bit confusing to have all the backend classes also on the client. To be honest, I ended up using the low-level builders and constructing the expressions as JSON strings in my Java client. But it would be nice to get IDE help building more complex nested streams.
So if it is possible to figure out what Bean classes and builders are needed on the client side, it would be a better end-user experience to get only those classes in solrj-streaming. In that case, the server-side classes could be a module for sure. Do you imagine the module would be enabled by default in 9.x and disabled by default in 10.x?

Ok, I like the idea of keeping a very small workable subset of classes in Solrj and moving the rest along with the /stream handler etc... to a server side module. The best supported TupleStreams Java API classes are the ones that are used by the /sql handler. So I think we can just leave these few class in Solrj. That would move 98% of the classes to a server module.

Another way to split the classes between server and client side module is any class that has a Java API test case can stay in Solrj. 98% of the classes only have streaming expression based test cases and they will be moved to the server side module.

If people are ok with this approach I will keep this PR alive and continue working on the server side module. Once thats done, I'll migrate a small set of classes to solrj-streaming.

As part of the solrj-streaming module I will add documentation for using the Java API. There is a massive amount of documentation for streaming expressions on the server side but nothing for Java API now.

@joel-bernstein for 9.x - I'm pretty sure everything needs to stay client side - so moving stuff should stay in solrj just in a separate artifact solrj-streaming.
For 10.x maybe we can see what it looks like to have a server side only module. The comments I made about solrj stuff being like maven dependencies - only applied to solrj client side. It does NOT apply to server side modules - at least not the same way.

@risdenk, I'm curious why it all needs to stay client?

user is using the streaming solrj client side java classes. - Solr 9.1 user upgrades to Solr 9.x - if all those classes are moved only to a server side module that would break in the point release.

It is possible that people are using a more broad set of classes on the client side. Which would indeed break if they are removed. So I see your point about waiting for 10 for splitting.
I'm ok with a solrj-streaming module.

Yes, similar considerations were made for solrj-zookeeper.
So if you start with the new solrj-zookeeper maven-artifact, moving all IO classes as-is, that should be back-compat with 9.0.
Next, @Deprecate 98% of the classes in the new solrj-zookeeper folder with forRemoval="10.0", so users can continue using them on the client in 9.x. Then I suppose you could COPY those classes to a new server-side module, give them other package names etc, and release the new server-side module in 9.x. Then the server-side /stream handler will use the new backend classes from the module and not the deprecated ones. Is this possible?

For this PR I'll focus on the move to solrj-streaming as that cleans things up in Solrj.
I'll open another ticket to discuss the deprecation and creation of the server side module.

This sounds good to me, although I'm not sure why the streaming expressions stuff would really need to go into a module instead of solr-core. Does it require any dependencies that Solr doesn't already have?

@HoustonPutman, I'll focus on the move to solrj-streaming since thats what is needed for 9x.
For Solr 10 we can decide between a module or solr-core. I'm fine with either approach.


SR-13015: Decimal calculation incorrect on Linux

Fix typo and logic error in the overflow check in integerMultiply(), which was screwing up Decimal calculations under certain conditions.
I was able to reproduce on Android and spent hours tracking this down on there. I'm guessing it only worked on macOS because this code is unused on there.

@swift-ci test

Updated with correct overflow check.

Could you add in the extra tests in https://gist.githubusercontent.com/spevans/a5c9da89e91538abc688c5498fe4ed28/raw/e23ca9cdc21b87e2bcc1880ddafc5e01624bd9ce/sr13015.diff and squash it into one commit for easier back porting

@swift-ci test linux

Sure, will do.

Rather than checking the same Decimal normalization in three different places, I removed my test and added your more extended tests instead.

@swift-ci test linux

@swift-ci test

You mentioned backporting this, should I submit a pull for the 5.3 branch? I presume 5.2 releases are done, or will that take this too?

Lets get a backport for 5.3 going, Im not sure if it will make it into the release or will end up in 5.3.1 but having it ready to go will be useful, thanks.


add into_inner and similar methods to StreamFuture

When selecting on a StreamFuture and other futures, it is useful to be able to recover the underlying Stream if one of the other futures resolves first.
See https://github.com/rust-lang-nursery/futures-rs/issues/633#issuecomment-360932386 for more information.

The latest change as the Option return types and applicable documentation.

Thanks!


Adding ability to restock resources and offload created materials

I found a "Mass Scroll Script" by AreYouKidden here and thought it would be useful in the Inscription trainer script to have a way to auto restock resources based on some minor presetup (documented). If you think I should alter this in some way or maybe submit as a new script entirely I can do so. I am open to suggestions but this is working really well so far. Cheers!  =)

hey @GitBytes! This is super cool! I think the changes are perfect and I'm going to go ahead and merge this. Seems like a big improvement on inscription.
also I just want to celebrate here for a second 🎉  you're the first contributor to this repository which is really neat :) you even have a fancy badge First-time contributor

Thanks for for the great addition, if you find anything else I'd love to add it! Cheers 🍻

@her Excellent, glad to hear you liked the changes! I plan to be contributing more as time goes on. You have a great library going here and I look forward to more content being added or improved in the future. Thanks for the First-time contributor badge opportunity. Have a great one!


[Feature Request] Thumbnail Generation

Hello,
I'm just testing Mango out to move away from Komga, I have everything set-up on a server with an i7 (8000+ bench score, I don't remember the exact generation) and 32GB of RAM.
The web interface is accessed from a simple NGINX reverse proxy in a subdomain virtual host. Everything works properly except browsing the web interface which is extremely slow (Both on Chrome and Firefox).
I have a bunch of very high resolution digital manga (in cbz) (3000h and up in resolution) and sometimes the page stays white for 3-4 seconds to load newer volumes while browsing any specific manga page.
I'm assuming this is because Mango lets my client downscale the pictures instead of preemptively preparing them itself? Is there any way I can mitigate this?
I should also mention that this is remote and not on local network

Hi, thanks for reaching out!

I'm assuming this is because Mango lets my client downscale the pictures instead of preemptively preparing them itself?

Yes, this might be the reason but I am not sure. The web interface lazy loads images, which means it only load and display images when they enter the viewport, so your browser only needs to downscale the visible images.
Could you please find a typical cbz in your collection, and check the file size and resolution of the first page? And how many cbz files do you usually have in a manga folder? I will test and see if I can reproduce the issue.

Hi, thanks for reaching out!

I'm assuming this is because Mango lets my client downscale the pictures instead of preemptively preparing them itself?

Yes, this might be the reason but I am not sure. The web interface lazy loads images, which means it only loads and displays images when they enter the viewport, so your browser only needs to downscale the visible images.
Could you please find a typical cbz in your collection, and check the file size and resolution of the first page? And how many cbz files do you usually have in a manga folder? I will test and see if I can reproduce the issue.

The worst example I have is a folder containing 40 volumes of a digital version of Berserk.
Each file is ranges in size from 800MB (the biggest one) and 200MB (the smallest one), the median is around 450MB per file. They contain about 250 pages per volume, and their cover is 1810x2560 in resolution.
Another exampe is BLAME! containing only 6 volumes, but being AS slow if not more and the resolution of each cover is 2142x3056, these volumes go from 700MB to 1.2GB and they have about 400 pages each.

From the GIF I saw two issues:

The cards are initially blank and the images take some time to load
Sometimes when scrolling, the whole page turns white, and it returns to normal after a few seconds

The first issue is completely normal. As you correctly noted, currently Mango does not generate thumbnails when scanning the library, so high-resolution covers take some time to load. Due to the same reason, in OPDS the covers take longer to download. We do need the thumbnail generation feature before v1.0, but I don't think it's important at this stage.
The second issue is weird and I couldn't reproduce it. I've created a folder containing 1000 cbz files, where each file has a 4928 × 3280 cover image. On my i7 MacBook Pro with 32GB of RAM, both Firefox and Chrome scroll smoothly. I will test it with less powerful devices tomorrow.

From the GIF I saw two issues:

The cards are initially blank and the images take some time to load
Sometimes when scrolling, the whole page turns white, and it returns to normal after a few seconds

The first issue is completely normal. As you correctly noted, currently Mango does not generate thumbnails when scanning the library, so high-resolution covers take some time to load. Due to the same reason, in OPDS the covers take longer to download. We do need the thumbnail generation feature before v1.0, but I don't think it's important at this stage.
The second issue is weird and I couldn't reproduce it. I've created a folder containing 1000 cbz files, where each file has a 4928 × 3280 cover image. On my i7 MacBook Pro with 32GB of RAM, both Firefox and Chrome scroll smoothly. I will test it with less powerful devices tomorrow.

I can confirm that the second issue is my work laptop being a piece of garbage. Admittedly I did not try scrolling on my less powerful devices, on my iPad it scrolls smoothly.
The slower cover imagine loading is a bit annoying, it lags my brain but it's ok to wait for, will keep using the app and see how it is. Most needed feature right now for me would be multi mark read and unread, had to go through 25 volumes of Berserk to mark as read!

Great! The batch marking feature has been requested in #75 and you can subscribe to that issue to get updated. I should be able to work on it soon, after finishing #48.

Great! The batch marking feature has been requested in #75 and you can subscribe to that issue to get updated. I should be able to work on it soon, after finishing #48.

#48 is awesome. Just a generic question that I don't know if I should open an enhancement request yet. Would it be possible to do something like YACServer?
YACServer headless could be run from a docker image like  https://hub.docker.com/r/muallin/yacreaderlibrary-server-docker/ one and I would stream files directly from the server to their iOS app YacReader. Obviously there's no native app for Mango, but my idea is generally avoiding using browsers as much as possible so to have native library view within one app and native page scrolling while reading and also downloading as much, like you can do with OPDS, because that would defeat the purpose of having a server!

I am not sure I understand. Are you requesting for headless mode or native apps?
For Android, we have #33. I hate Java and Kotlin with a passion so I really don't want to work on that :) Hopefully someone will help, and if not I can push myself to do it before v1.0. As for iOS, I am an iOS developer myself, so I can develop and publish a native app when I have the time. Feel free to open a feature request if you want.

I am not sure I understand. Are you requesting for headless mode or native apps?
For Android, we have #33. I hate Java and Kotlin with a passion so I really don't want to work on that :) Hopefully someone will help, and if not I can push myself to do it before v1.0. As for iOS, I am an iOS developer myself, so I can develop and publish a native app when I have the time. Feel free to open a feature request if you want.

Technically YACServer does not support a headless server, it is usually used under Windows with a GUI and then the client connects to the server via the native app. What I was asking for was something kinda like the YACReader app for iOS, where it just connects to your library server and STREAMS pages to your client, without downloading them or going through a browser!

@WiseMMO Just to let you know, the batch marking feature has been added in v0.10.0.

In v0.15.0 Mango generates thumbnails as a background task. Thanks for the feature request!


failed to get processor information with redfish api:/Systems/{identifier}/Processors/{socket}

try to run proboscis with two physical nodes(both quanta d51),
one case failed: Testing GET /Systems/{identifier}/Processors/{socket} .
Then I run the api manually, I also got error.
here is the logs:
onrack@ORA:~$ curl localhost:8080/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors |python -m json.tool
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   456  100   456    0     0  10652      0 --:--:-- --:--:-- --:--:-- 10857
{
<EMAIL_ADDRESS>"/redfish/v1/$metadata#Systems/Links/Members/575ed5a33131496a7ca56a2e/Processors/#entity",
<EMAIL_ADDRESS>"/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors",
<EMAIL_ADDRESS>"#Procssors.1.0.0.ProcessorsCollection",
"Members": [
{
<EMAIL_ADDRESS>"/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors/0"
},
{
<EMAIL_ADDRESS>"/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors/1"
}
],
<EMAIL_ADDRESS>2,
"Name": "Processors Collection",
"Oem": {}
}
onrack@ORA:~$ curl localhost:8080/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors/0 |python -m json.tool
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   696  100   696    0     0  12437      0 --:--:-- --:--:-- --:--:-- 12654
{
<EMAIL_ADDRESS>"/redfish/v1/$metadata#Systems/Links/Members/575ed5a33131496a7ca56a2e/Processors/Members/$entity",
<EMAIL_ADDRESS>"/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors/0",
<EMAIL_ADDRESS>"#Processor.1.0.0.Processor",
"Id": "0",
"InstructionSet": "x86-64",
"Manufacturer": "Intel",
"MaxSpeedMHz": 2300,
"Model": "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz",
"Oem": {},
"ProcessorArchitecture": "x86",
"ProcessorId": {
"EffectiveFamily": "Xeon",
"EffectiveModel": "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz",
"IdentificationRegisters": "F2 06 03 00 FF FB EB BF",
"MicrocodeInfo": "",
"Step": "",
"VendorId": "GenuineIntel"
},
"ProcessorType": "CPU",
"Socket": "SOCKET 0",
"Status": {},
"TotalCores": 10,
"TotalThreads": 20
}
onrack@ORA:~$ curl localhost:8080/redfish/v1/Systems/575ed5a33131496a7ca56a2e/Processors/1 |python -m json.tool
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   716  100   716    0     0   9002      0 --:--:-- --:--:-- --:--:--  9063
{
"error": {
<EMAIL_ADDRESS>[
{
<EMAIL_ADDRESS>"#Message.1.0.0.Message",
"Description": "Indicates that the request failed for an unknown internal error but that the service is still operational.",
"Message": "The request failed due to an internal service error.  The service is still operational.",
"MessageId": "Base.1.0.Messages.InternalError",
"Resolution": "Resubmit the request.  If the problem persists, consider resetting the service.",
"Severity": "Critical"
},
{
"Description": "Contains the detailed error message contents",
"Message": "Unexpected token U",
"MessageId": "RackHD.1.0.DetailedErrorMessage"
}
],
"code": "Base.1.0.GeneralError",
"message": "A general error has occurred. See ExtendedInfo for more information."
}
}

and ipmi sdr show:

bios information:

@PengTian0 this is referencing a PR that you've merged, was this issue resolved with that PR?

@heckj  yes, the PR fixed the issue

@heckj here is the commit link:
https://github.com/RackHD/on-http/commit/55727e8686a3077a58b37e79ab623200dcfbdb92


Write a guide explaining how to use pipelines with internal registry

This would also cover using the OCP internal registry with the external route.

@kvijai82 Hi Vijai, are you on track to completing by the end of the week(friday, May 1st)?

@mingcyu yes I have the first pass done.

The following guide will walk you through the steps needed to run a pipeline to build your application, publish the image to a registry, and optionally deploy the application on your cluster.

Clone the kabanero-pipelines repo.

cd into the pipelines/sample-helper-files directory.

For this guide, we will use the one of the default pipelines, java-ol-build-deploy-pl, that is activated by the Kabanero operator.  You can replace this with any of the other build-deploy-pl or your custom pipeline.
Make sure you have the appropriate storage setup to drive Tekton pipelines.  If you have a dynamic storage provisioner available on your cluster there is nothing to do.  If not you can setup a simple NFS babsed PV using the nfs-pv.yaml sample provided.

Run oc apply nfs-pv.yaml

Create the secret for your github repo. You can skip this step if it's a public repo. For a private repo, follow the steps in Secrets section of https://kabanero.io/guides/working-with-pipelines/#getting-started.
Create the secret for your registry.

If you are using the internal route of the internal registry of your OCP cluster, you do not have to configure a secret as long as the service account you are running the pipeline with has the right permissions.  The kabanero-pipeline service account is setup with the appropriate permissions.
If you are using the external route of the internal registry of your OCP cluster, you do not have to configure a secret also as the pipeline will recognize the URL and translate it to the internal route of the registry automatically.
If you are using a private registry, follow the steps in Secrets section of https://kabanero.io/guides/working-with-pipelines/#getting-started to setup a secret for your registry.

Setup certificates or specify insecure connection for the registry access following the documentation in https://kabanero.io/guides/working-with-pipelines/#transport-layer-security-tls-verification-for-image-registry-access-in-pipelines.
Run the pipeline.  There are multiple ways to do this.  Please reference the https://kabanero.io/guides/working-with-pipelines/#running-pipelines documentation and choose the method you would like to follow to run the pipeline.
Review the status of your run and logs using the documentation provided at https://kabanero.io/guides/working-with-pipelines/#checking-the-status-of-the-pipeline-run
When the pipeline run is complete, you can go to your registry to check if the application image is published.
If you ran the pipeline via the webhook, it will only deploy the application if you initiated the run via a pull request merge. If that's the case, continue to the next step to access your application.
You can run oc get apposodyapplications or check your pods to see your application pod running.
You will have to create a secret for your registy and associate it with the new service account that was created by the appsody application for your application.

If you are using the internal route for the internal registry there is nothing to do as the service account has the necessary permissions.
For private registries and the external route of the internal registry, create the secret for your registry and link to the service account that matches your application name.

If you exposed a route for your application, check the routes (oc get routes for example) and test your application.

@kvijai82 has opened an issue in docs repo for this guide to be updated: https://github.com/kabanero-io/docs/issues/403

Delivered content to doc team


Updated the links in auth.md doc file

Current coverage is 74.41% (diff: 100%)

Merging #653 into master will not change coverage

@@             master       #653   diff @@
==========================================
  Files            28         28
  Lines           559        559
  Methods         542        542
  Messages          0          0
  Branches         17         17
==========================================
  Hits            416        416
  Misses          143        143
  Partials          0          0

Powered by Codecov. Last update ddd4b82...07ac916

Thanks @smirzaei!


Prevent html escaping in documentation

Currently the doc generator doesn't escape html-like tags, and merely inserts them as-is in the final document. This should be fixed, but for now we can avoid that by enclosing tag-like in code/pre tags ourselves.

That was simple! Thanks @ergl.


Add pre-commit hooks

We want to further standardize our code format by including pre-commit hooks. For now, we can just include the standard ones + black + isort.

Can I take this issue? as Hacktoberfest?

Of course, thanks a lot! Dont hesitate to ask questions
El mar., 5 oct. 2021 14:23, Krishna Jalan @.***>
escribió:

Can I take this issue? as Hacktoberfest?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/recognai/rubrix/issues/414#issuecomment-934360246,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOJJZXH6H54WDUOVALXDDUFLU2TANCNFSM5FJYNUVA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Can you assign me this issue?

Done

created a PR

hey, can you add Hacktoberfest to the project topic or hacktoberfest-accepted to the PR label
else this won't be counted in hacktobefest!


do not allow sub second in healthcheck options in Dockerfile

Signed-off-by: allencloud<EMAIL_ADDRESS>This is a follow-up for https://github.com/docker/docker/pull/30203
Since in docker/master, we do not allow docker daemon to validate healthcheck parameter Timeout and Interval to be not less than 1 second. We discussed about that we should not support sub second validation.
Without this PR, if a user specifies Timeout in Dockerfile to be 0.5s(sub second), then the docker build will be OK, and let us call the built image to be built-image. However, the docker run built-image will report error, since PR https://github.com/docker/docker/pull/30203.
- What I did

validate healthcheck parameters Timeout and Interval in Dockerfile options.

ping @cpuguy83 @LK4D4

LGTM ping @cpuguy83  @LK4D4


View TLS version in Details

Is there any way to view TLS version in the Details tab?
I use mitmproxy 0.17.1 and Details tab shows certificate info and TLS timings, but not TLS version. Many sites enforce TLS 1.2 (or 1.1) and finding which version is in use is essential for debugging.
I'm not sure if that is possible, but if client -> proxy connection uses one TLS version and proxy -> server another, please add both versions in Details tab. BTW, this would be a very helpful feature if older clients (i.e. TLS 1.0) are able to connect to newer servers (TLS 1.2).
Thanks,

Thanks for the feedback! This sounds like a useful feature to have.
This is so closely related to #582 that I'll just close this issue here and merge it into the other one if you don't mind. :smiley:


[Async CC] Never map to native explosions.

Previously, when lowering the entry point of an async function, the parameters were lowered to explosions that matched those of sync functions, namely native explosions.  That is incorrect for async functions where the structured values are within the async context.  Here, that error is fixed, by adding a new customization point to NativeCCEntryPointArgumentEmission which behaves as before for sync functions but which simply extracts an argument from the async context for async functions.
rdar://problem/71260972

@swift-ci please test

@swift-ci please test

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - e988047b18ca66ff6ea7b6dc258b996df2cae54a

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 11723ccc55c234632fccde974b1c074129883e26

@swift-ci please test

Merging broke the build: the test's behavior changed after the tests passed.  A PR that fixes the test is here: https://github.com/apple/swift/pull/34748


How to have a good style in the dark mode?

@JiHong88 hi
I implemented Dark mode for my site.
But the editor is not compatible with Dark mode.
this is result of editor in dark mode :

There must be a way to manage colors in the dark.
I think we should be able to choose the equivalent of each color in the dark mode.
Or we can customize the styles

https://huro.cssninja.io/components-plugins-editor-sun.html
Please refer to this site using "suneditor".
In 3.0.0, I plan to improve it so that you can easily change the user theme.

@JiHong88 What is the status of version 3?
I think we should start and solve the problems one by one

@JiHong88, I would be happy to make a pull request to implement this functionality. It would be a simple matter of adding native variables to the css; then a user could update those variables to match their custom light and dark themes.

+1 for Dark Theme mode.


wayout: init at 1.1.3

Description of changes
fixes https://github.com/NixOS/nixpkgs/issues/180946
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@AndersonTorres Thank you for testing it. Disabled build for darwin


Set name for long lived thread

Signed-off-by: Tong Zhigao<EMAIL_ADDRESS>

@hanfei1991 PTAL


Image assets showing on debug but not on release

I have been updating part of my code and changed the image for it but when I build for release the image disappears I have already tried flutter clean and have checked my pubpec.yaml. Did somebody else experience this kind of issue
here is the part of the code:
pubspec.yaml:
  assets:
    - assets/images/

new Image.asset(         'assets/images/toys-1-1.png',         //scale: 1,         width: Get.width / 3,         alignment: Alignment.centerLeft,       ),

Hi @ChristianAdrian
Which platform and device are you testing the issue? Please provide more details
Can you please provide your flutter doctor -v, a complete reproducible minimal code sample, and complete flutter run --release --verbose logs running the minimal code sample?
Thank you

`[✓] Flutter (Channel stable, 1.22.5, on macOS 11.0.1 20B50
darwin-x64, locale en-AE)
• Flutter version 1.22.5 at
/Users/christiandomantay/tools/flutter
• Framework revision<PHONE_NUMBER> (5 months ago),
2020-12-10 11:54:40 -0800
• Engine revision ae90085a84
• Dart version 2.10.4
                                                     [✓] Android toolchain - develop for Android devices (Android
SDK version 30.0.2)
• Android SDK at
  /Users/christiandomantay/Library/Android/sdk
• Platform android-30, build-tools 30.0.2
• Java binary at: /Applications/Android
  Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build
  1.8.0_242-release-1644-b3-6915495)
• All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.5, Build version 12E262
• CocoaPods version 1.10.0
[!] Android Studio (version 4.1)
• Android Studio at /Applications/Android
Studio.app/Contents
✗ Flutter plugin not installed; this adds Flutter
specific functionality.
✗ Dart plugin not installed; this adds Dart specific
functionality.
• Java version OpenJDK Runtime Environment (build
1.8.0_242-release-1644-b3-6915495)
[✓] VS Code (version 1.56.0)
• VS Code at /Applications/Visual Studio
Code.app/Contents
• Flutter extension version 3.22.0
[✓] Connected device (1 available)
• SM G955F (mobile) • ce041714b3ccd12504 • android-arm64
• Android 9 (API 28)
! Doctor found issues in 1 category.`

Hi @ChristianAdrian
You seem to be using an older version of Flutter
Can you please upgrade to the latest  stable and try again
Execute the following commands to upgrade
flutter channel stable
flutter upgrade --force
flutter doctor -v
Which platform and device are you testing the issue with? Please provide more details
Based on your logs, I'd assume It is Samsung device, Is that correct

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Solution discussion for rebuilding federation service controller cache on restart

 Issue by mfanjie
Thursday May 26, 2016 at 02:51 GMT
Originally opened as https://github.com/kubernetes/kubernetes/issues/26329

I am working on federation service controller, and there is a limitation on current cache, after had a call with @quinton-hoole, as it's not a common case, we will leave it as is in v1.3, and I open this issue to track the problem and to find out a more robust solution.
Federation service controller behavior description:

service controller watch federation apiserver for new services, create service map in the form of
fedServiceMap: [serviceName]cachedService: {service info, endpointMap: [clusterName]int, serviceStatusMap: [clusterName]api.LoadBalancerStatus}
endpointMap and serviceStatusMap have no element at this moment.
service controller create the service on all healthy clusters
service controller watches all healthy clusters for services and endpoints.
When new serviceStatus with LB info is returned, add it to serviceStatusMap and service info and update federation apiserver with the new LB info.
when new endpoint info returned, add it to endpoint map with flag 1 which indicates there is reachable endpoints

Problem description:
From above behavior description, we can see that serviceStatusMap is the only place to link clusterName and LB info, it is not persisted anywhere and it will go on service controller down.
So if during service controller down time, the service on any clusters is deleted, and after federation service controller being starts, the service will be rebuild on that cluster again, with different LB info, and as we lost the link between cluster and LB info, we do not know which old LB info in federation service was returned by from that cluster, as a result, we can add the new IP to federation service, but there is no way to remove the old one.
One typical example
Federation service:S1
Clusters: C1, C2
after S1 is created, it will be created in C1 and C2, with LB IP1, and LB IP2 assigned.
So after the a while S1 will changed to S1[LB:{IP1, IP2}]
serviceCache is same S1[LB:{IP1, IP2}]
serviceStatusMap [C1]S1[LB:IP1], [C2]S1[LB:IP2] , most import one, it links Ingress IP and clusters.
endpointMap [C1]1,[C2]1
For the case that LB IP in C1 changed from IP1 to IP3
If we have the cache info, we know IP1 is from C1 previously, so we can remove it and add IP3.
But If Service Controller is restarted, we will lose the old LB IP info, we do not know which IP we should remove from Federation IP, and the ingress info will be changed to S1[LB:{IP1, IP2, IP3}]

 Comment by quinton-hoole
Tuesday Oct 11, 2016 at 16:26 GMT

Provisionally assigning to @mwielgus who has been thinking about similar things.  Some of this is now incorporated into our common federation controller library.  We can close this once we have ported the Federated Service Controller to the common federation controller library (there is an issue for that somewhere), and verified that all of the cases outlined in this issue are addressed by that port.

cc @mfanjie

This issue is irrelevant. We do not maintain separate service cache for backing healthy endpoints and instead update the federated service controller with annotation.
/close


mdmonitor service in 19.09 is misconfigured and fails to start

Describe the bug
When an md device is used (most likely because two or more block
devices are setup in a software RAID configuration) then mdadm package is
installed and it's used especially at bootstrap time to assemble
these block devices and expose the md device.
In the 19.03 even if the version of the tool was the same, there was no
systemd service installed.
In the 19.09 a commit ( #b9b27912 ) explicitly enabled some systemd
service units to be installed, resulting into the mdmonitor.service
unit to be installed in the configuration.
The problem with that commit is that the installed unit has a
completely bogus configuration (i.e. not working in a nixos system),
resulting in a system with a degraded configuration.
The installed unit has the following source:
# systemctl cat  mdmonitor
# /nix/store/108j7v1j85c97xwxfgvz11zak49h78x5-mdadm-4.1/lib/systemd/system/mdmonitor.service
#  This file is part of mdadm.
#
#  mdadm is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=MD array monitor
DefaultDependencies=no

[Service]
Environment=  MDADM_MONITOR_ARGS=--scan
EnvironmentFile=-/run/sysconfig/mdadm
ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh
ExecStart=/nix/store/108j7v1j85c97xwxfgvz11zak49h78x5-mdadm-4.1/sbin/mdadm --monitor $MDADM_MONITOR_ARGS

And the log of the failing service is:
mdadm[5723]: mdadm: No mail address or alert command - not monitoring.
systemd[1]: Starting MD array monitor...
systemd[1]: Started MD array monitor.
systemd[1]: mdmonitor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: mdmonitor.service: Failed with result 'exit-code'.
systemd[1]: Starting MD array monitor...
systemd[6632]: mdmonitor.service: Executable /usr/lib/mdadm/mdadm_env.sh missing, skipping: No such file or directory
systemd[1]: Started MD array monitor.
mdadm[6633]: mdadm: No mail address or alert command - not monitoring.
systemd[1]: mdmonitor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: mdmonitor.service: Failed with result 'exit-code'.

It appears that apart from the clearly wrong path expectancies this
module want some other missing parameters like an email of the person
to contact.
To Reproduce
Steps to reproduce the behavior:
Configure a 19.09 system with a RAID device
Expected behavior
For the monitoring service to run or for its unit to be missing.
Metadata

system: "x86_64-linux"
host os: Linux 5.3.8, NixOS, 19.09pre-git (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-18.09.2526.ce0ec21d6cc"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
  - mdadm
# a list of nixos modules affected by the problem
module:

cc: @abbradar

Can confirm, I just updated the CI server for static-haskell-nix from 19.03 to 19.09 and found that the new service mdmonitor.service fails at startup.

I don't know what mdadm_env.sh typically contains, but it is optional. (I don't need to pass extra env for into the service.)
I've been running with this config since starting to use mdadm, so I have not encountered this issue:
 environment.etc."mdadm.conf".text = ''
    MAILADDR root
  '';

One option is to let NixOS configure /etc/mdadm.conf. But not all systems have email sending capabilities, so it might hide the fact that notifications will not be sent (or received). Another option is to have mdmonitor.service be opt-in. I think I like that best.

Could someone please say what the status with this is? The workaround works, but someone who has an mdraid shouldn't have to go searching the net to find a solution to something that should be working out of the box.

What should be the default behaviour? No monitoring or monitoring with notification to (perhaps effectively) /dev/null? (At least the current behaviour makes it obvious that monitoring is off :-D)
My preferred solution is to opt-in to mdmonitor.service. That also sidesteps the issue of whether NixOS or the user should own /etc/mdadm.conf. The mdmonitor service comes from upstream via systemd.packages = [ pkgs.mdadm ]. I think NixOS has a way to override these, but I don't know how.

@bjornfor You're right and I can see your point, but just letting a service fail without more information is not really user-friendly. Maybe a warning that explicitly points out why the service is failing? Or maybe something in the documentation instead?

Maybe a warning that explicitly points out why the service is failing?

The service says "mdadm: No mail address or alert command - not monitoring." right before exiting. Improving on that message must be done upstream.

"Bjørn" == Bjørn Forsman<EMAIL_ADDRESS>writes:

>> Maybe a warning that explicitly points out why the service is failing?

Bjørn> The service says "mdadm: No mail address or alert command -
Bjørn> not monitoring." right before exiting. Improving on that
Bjørn> message must be done upstream.

what? The issue here is that a Service I cannot configure via Nix gets
setup without a warning and that causes for a system using mdadm to
appear as degraded. The right thing to do in my opinion is to:

add a configuration entry where the service can be disabled
In case it's enabled, it will be necessary to fill-in another attr
for the mail address, at least

@bjornfor While you're correct that the service alerts and fails with that message, it doesn't mean that the NixOS user knows how to solve it unless they go searching for the above solution you provided here in this very Github ticket. The point is that if we want to make NixOS more accessible to people who aren't that "deep" into NixOS (and I can appreciate that "deep" is a relative term here), then we must provide clear hints/pointers to possible issues and their solutions. May it be in the documentation or by alerting the user during eval time.
Since NixOS is so different from other systems I'd argue it is very much our responsibility to provide guidance on how to solve possible issues, upstream or not.

@bjornfor While you're correct that the service alerts and fails with that message, it doesn't mean that the NixOS user knows how to solve it unless they go searching for the above solution you provided here in this very Github ticket. The point is that if we want to make NixOS more accessible to people who aren't that "deep" into NixOS (and I can appreciate that "deep" is a relative term here), then we must provide clear hints/pointers to possible issues and their solutions. Maybe in the documentation or by alerting the user during eval time.
Since NixOS is so different from other systems I'd argue it is very much our responsibility to provide guidance on how to solve possible issues, upstream or not.

Another problem:
When you change e.g. environment.etc."mdadm.conf".text, then mdmonintor.service is not restarted.
Where is the service defined again?

I think we should disable the automatic usage of the upstream systemd unit, defined here:
https://github.com/NixOS/nixpkgs/blob/972748bc311ba1193f9a409658328ad36c7f24ee/pkgs/os-specific/linux/mdadm/default.nix#L14-L15
Because it is seems to be not even very correct (for our use cases): It does not get started as part of multi-user.target, so it is not run on switch-to-configuration or nixops deploy. For an important alerting service like mdadm, that is bad.
Also does anybody know what the NIXOS=1 does?

Do we have means to only pull a NixOS unit in if udev has detected a RAID device but still trigger that detection during activation?
Also we might want to setup a default delivery command or setup local mail delivery for cases like these. We actually miss any kind of way of informing the admin if things are going wrong in the background. We only have the systemd journal that users/admins have to scrape through.

IMO we should just remove this unit for now, as it being on by default is just breakage for lots of people. We may want to reintroduce it with proper configuration as a NixOS module, and maybe even have the NixOS module be auto-activated if things in the configuration that look like a RAID setup are there so that the user is forced to set an email address and doesn't just not know when things go wrong, but… for now this looks like a net liability?
FWIW, the thing I personally use, that doesn't require polluting /etc:
{systemd.services.mdadm-monitor = {
  description = "Monitor RAID disks";
  wantedBy = [ "multi-user.target" ];
  script = "${pkgs.mdadm}/bin/mdadm --monitor -m root /dev/md126 /dev/md127";
};}

I agree the unit file should be removed for now. It fails out of the box and terminate, thus does not even run.

I just ran into this on my personal machine and I think I can work out a patch acceptable with the various interests here. Not sure what the time frame will be, though.

still relevant, needs someone to actually look into it

Alright, so here's a draft to clean this up. I hope I extracted the essentials from this discussion properly. I still need to clean things up, but I guess this is small enough to still get it into 21.05 if we want. Anyone care to weigh in?

FWIW, my stance on the linked PR is that it'll require quite some time to review (I personally will come to it someday hopefully in the next few months, though I definitely hope someone else will review it before). But, more importantly, that it is a much more major PR than should happen just a few days before the release; as mdadm is one of the most central pieces of a system that relies on it, and the problem at hand is overall something that people should be able to live with for one more release.
This being said, it's awesome that you made the PR to fix this, and I hope we can review and land it soon after the release! (FWIW, I'd suggest you undraft the PR, as I know I usually don't review draft PRs and I'd guess other people often do the same — if you followed the suggestions here I think the core idea should probably be OK already, especially with aanderse's review comments handled :))

Thanks for all the efforts, just wanted to drop by and say this is still happening on 22.05. Is the preferred work around still https://github.com/NixOS/nixpkgs/issues/72394#issuecomment-549110501 ?

Thanks for all the efforts, just wanted to drop by and say this is still happening on 22.05. Is the preferred work around still #72394 (comment) ?

I think so.

And in 22.11.
The smartd package does something interesting: if it sees sendmail available, it activates mail notifications automatically (defaulting to root for both From and To).

And in 23.05.

So, I went through this again. The callenge here is that mdadm provides a very elaborate set of udev rules that interact with a small fleet of systemd timers and services that are hard to decipher.
Deactivating the monitor service isn't really easily possible as the udev rules trigger this and we'd have to change those based on system config instead of package config ...
I'm not even sure all the elaborate things the udev rules and services do actually do what they are supposed to do, however, that makes it an even stronger case to at least get the monitoring and notifications right.
Note: from a perspective of our Flying Circus platform, we monitor /proc/mdstat using regular check utilities and do not rely on those. However, on my personal machine I'd rather see an email from the mdadm monitor... I'm also not quite sure whether rebuilds/hot spare activation happen properly if the monitor isn't there ... (I would hope that those low level activities are done in the kernel module and don't rely on userland ..., however looking at the reshape services, I'm not quite sure.)
So. New plan:

[ ] provide option to store an email address. if you don't provide one, you'll still end up with a broken monitor.
[ ] add test coverage to demonstrate this behaviour

Finally closed in #123466

Thank you!

@ctheune Thank you, much appreciated!


Added support for Spanish locale.

Updated fxmanifest.
Added es.lua in locales directory.
Updated README file.
Fixed possible bug: The entry for locales/nl.lua was missing from fxmanifest.

Thank you very much :)


perf: Improve Multiple Chunk Upload Performance

chunkSize uploads should be much faster.  🦕

Overall I think this looks good and since we walked through the code I understand the why/how. I think once the supporting document is a bit more fleshed out with some metrics, I am good with this getting merged / released.


Vanilla

The majority of the functionality of the typescript library has now been translated to vanilla js and refactored along the way. Probably worth getting some feedback on this as it is before committing to the finishing touches.
API changes:

Promises instead of callbacks wherever that makes sense.
The existing "delegate" functionality is basically the same, but I'm proposing we call them "hooks" instead, since it seems like more familiar terminology in the javascript ecosystem.
subscribeToRoom will also join room if you're not already a member
consistent type checking of arguments
chatManager.connect doesn't resolve with the current user object until the full initial state is known (the initial user request has already completed, presence subscription has been established etc)
a smattering of method renamings and "was a room but now a roomId"

See luke's demo modified to use this branch: https://github.com/pusher/chatkit-demo/pull/1
Internal changes:

RIP typescript
rollup instead of webpack, for no real reason other than that it's what I'm familiar with, and the build process was changing anyway with the move away from typescirpt. If this turns out to be a problem (for react native etc) I'm happy to move back to webpack.
abstract a lot of the async logic of "get this thing from the api unless we have it already, in which case just return the one we've already got" in to the user / room / presence store where before it was done case by case
(hopefully) general refactoring and simplifying

Tests
The integration tests that currently exist were super useful for doing the rewrite, and will continue to be useful to know we haven't broken stuff. But they aren't very good at testing failure paths, and won't scale much more (they already take >60s to run!). So we might want to unit test things too? I was loathed to do this immediately, but it might make sense once we've more or less settled on a good internal structure.
Remaining work

[x] cursors support
[x] rich media support
[ ] everything that currently has a TODO in the code
[x] improved logging
[x] ~make sure the error handling is watertight (it certainly isn't at the moment)~ still not, but probably "good enough for now"
[x] a corresponding PR for the docs to reflect the changes to the public API
[ ] react native and worker builds
[ ] allow opt out of presence / cursors, etc
[ ] detailed changelog

Build
yarn lint:build
Run the tests
yarn lint:build:test

"delegate" functionality is basically the same, but I'm proposing we call them "hooks"

+1 for renaming delegate to hooks. 'Delegate' is popular in the  Obj-C/Swift scene, but not as intuitive in the JS world.

Do we need to ship with updateRoom and deleteRoom? I really think this is a server concern (and you can't do either with default permissions). wdyt @hamchapman ?

I'm tempted to keep them because I can see it being something that an admin-type user might want to be able to do from the client.
Is there a reason to remove them other than them requiring permissions elevated from the default?

nah not at all. Just trying to narrow down the list of "final bits and bobs" to do before releasing this. It's a short job to add them :)

updateRoom & deleteRoom changes LGTM 👍

@callum-oakley pretty random but purely out of curiosity, what was the reason to move away from typescript internally? :)
Cheers 🍺


should refresh room data when there is a room event

wechaty version: 0.15.150
should refresh room data when there is the following room event:

[x] join
[x] topic
[x] leave
[x] create

Wechaty Version: 2725f1a4a5f6fe054dbaf796748f6647ffebb589  (commit number over update the cache after room events (#1328))
Bug
Cannot refresh room member and room topic when there is a room event.
Reproduce Step

run example/room-bot.ts and add some log in the code as the following showed:

     /**
       * find room name start with "ding"
       */
      try {
        const dingRoom = await this.Room.find({ topic: /^ding/i })
        if (dingRoom) {
          /**
           * room found
           */
          log.info('Bot', 'onMessage: got dingRoom: %s', dingRoom.topic())

          if (dingRoom.has(from)) {
            /**
             * speaker is already in room
             */
            const topic = await dingRoom.topic()
            log.info('Bot', 'onMessage: sender has already in dingRoom')
            dingRoom.say('no need to ding again, because you are already in ding room', from)
            from.say(`I found you have joined in room ${topic}!`)
            // sendMessage({
            //   content: 'no need to ding again, because you are already in ding room'
            //   , to: sender
            // })

          } else {
            /**
             * put speaker into room
             */
            log.info('Bot', 'onMessage: add sender(%s) to dingRoom(%s)', from.name(), dingRoom.topic())
            from.say('ok, I will put you in ding room!')
            putInRoom(from, dingRoom)
          }

I change the room topic from ding - welcome 李佳芮 to ding - warn 李佳芮
3.Bot remove me form the room
I send ding to bot:

Expect:
join the ding room
Actual:

bot reply me peer to peer,say: I found you have joined in room ding - welcome 李佳芮!
bot send message @李佳芮 no need to ding again, because you are already in ding room in room ding - warn 李佳芮.
ding - welcome 李佳芮 topic didn't refresh to ding - warn 李佳芮

Log
19:00:59 INFO Bot onMessage: got dingRoom: [object Promise]
19:00:59 VERB PuppetPadchat roomMemberList(6350854677@chatroom)
19:00:59 VERB PuppetPadchatManager getRoomMemberIdList(6350854677)
19:00:59 VERB PuppetPadchatManager getRoomMemberIdList(6350854677) length=2
19:00:59 VERB Room topic()
19:00:59 SILL PuppetPadchat roomMemberList()=2
19:00:59 INFO Bot onMessage: sender has already in dingRoom
19:00:59 VERB Room say(no need to ding again, because you are already in ding room, 李佳芮)
19:00:59 VERB PuppetPadchat messageSend({"roomId":"6350854677@chatroom","contactId":"qq512436430"}, @李佳芮 no need to ding again, because you are already in ding room)
19:00:59 SILL PadchatRpc rpcCall(WXSendMsg, ["6350854677@chatroom","@李佳芮 no need to ding again, because you are already in ding room",""])
19:00:59 VERB Contact say(I found you have joined in room ding - welcome 李佳芮!)
19:00:59 VERB PuppetPadchat messageSend({"contactId":"qq512436430"}, I found you have joined in room ding - welcome 李佳芮!)
19:00:59 SILL PadchatRpc rpcCall(WXSendMsg, ["qq512436430","I found you have joined in room ding - welcome 李佳芮!",""])

fix

Awesome.


Add animation check to see if horn can be clicked

This will fix the horn alert (the intrusive one) popping up even though the horn is currently being sounded.
Previously, if the horn was sounding (animating) it would still have the ready class. Now it will prevent the popup if it's ready or animating.

lgtm, thanks


Remove capitilisation from ValidComponentName

I have noticed that we can see inconsistencies between the component diagrams and sequence diagrams where casing may differ.
The Participant object can be used instead to set an alias which is a better way to alter what is displayed on the diagram.
This capitilisation is in ValidComponentName but there may be others areas to visit too..

Turns out that the component diagram just wasn't using the ValidComponentName helper when generating the markup which is why there was an inconsistency. No need to replace capitilisation etc. for now.


Clean makefile

Linux only change.
Simplifies and eliminates old code for Docker images using Ubuntu 16.04.
Ubuntu 16.04 has an older version of GCC, which doesn't support needed C++17 features. As such, the code no longer compiles with the stock GCC compiler on Ubuntu 16.04. The old unmaintained Docker image for this build environment has been removed.

Not sure if anyone wants to review this, or if it should just be merged. I'm guessing other people aren't particularly keen to review Makefiles or Dockerfiles.


Accepted job missing from "bacalhau list" results

Steps to reproduce:

Submit job to bacalhau cluster, e.g. "bacalhau docker run ..." (image attached)

Observe the job is accepted and assigned an ID
Execute command "bacalhau list"

Expected behavior:

Submitted job should appear in the resulting list

Observed behavior:

Submitted job does Not appear in the resulting list
(May be related to internode communication on job state?)

*Note: this behavior occurs intermittently. Raising this issue to track the behavior. Slack discussion reference here.

is this still happening?

@lukemarsden no, I have not seen this issue occur recently


Change the way hpcrun specifies options without frequencies or periods

Options such as BLOCKTIME, OMP_MUTEX, OMP_IDLE don't require periods or frequencies like other events specified using -e. We should use a different syntax, e.g., --blocktime, --omp-mutex, or --omp-idle rather than having them as events.

We should consider a similar adjustment to environment variables used by statically-linked executables. Perhaps adding a HPCRUN_SYNTHETIC_METRICS environment variable with --blocktime, --omp-mutex, or --omp-idle

This repository has moved to GitLab, please continue this issue there.


Problem of using MathJax

Jupyterhub works fine except that it doesn't display mathjax.
Any special installation instruction for doing that?
Ken

Got it working.... sort of.


Update Littleton zoning

Saved here: K:\DataServices\Projects\Current_Projects\Neighborhood_Planning_and_Zoning\Ch_40R\Littleton_40R\Data\Spatial\Littleton_Base_Zoning_October_2013-1611695315084
received Feb 2021

Updated Littleton Zoning attribute table to match other attribute tables in zoning database. Edited Village Common District to match March 2020 re-zoning. Saved zoning shapefile in: \data-001\public\DataServices\Datasets\Town_Data\Littleton\Zoning\Littleton_Zoning_Mar2020.shp


Added Padding within messages

This is related to #1 .

@Jwright707 Perfect !! Thank you for your contribution. Don't forget to add your name in the contributing file. :heart:

@Jwright707 Perfect !! Thank you for your contribution. Don't forget to add your name in the contributing file. :heart:

Thank you @DhairyaBahl , will do 😀

Thank you @DhairyaBahl , will do 😀

@Jwright707 Add the name so that I can merge this PR. You can also look into other issues or can create your own. You can also give me suggestions on this project.

@Jwright707 Add the name so that I can merge this PR. You can also look into other issues or can create your own. You can also give me suggestions on this project.

Let me add name now, and will do. Thank you 👍

Let me add name now, and will do. Thank you 👍

Added my name to the Contributing.md file. Thank you again 👍

Added my name to the Contributing.md file. Thank you again 👍

@Jwright707 Thanks for the contribution :smile:

@Jwright707 Thanks for the contribution :smile:


Unknown desc = error pending plan and plan's name in  the secret are not matched

Hello,
Last week I was starting several Terraform manifest inside GKE and I started received these messages Unknown desc = error pending plan and plan's name in the secret are not matched:
This error has appeared in several Terraform, as you can see here:

Let me share more info just from 1 Terraform manifest, maybe i don't see what is the root of this issue:

terraform
terraform.tar.gz

cm from plan
cm.tar.gz

secret from plan
secret.tar.gz

Let me also describe my environment:

kubernetes in Google, GKE:  Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.10-gke.2300"
FluxCD v0.41.2
Terraform Controller v0.14.0

Could you help me fixing this?
Marc

Let me add I was change the source of all these Terraform object changing the tag referenced from 0.0.1 to 1.1.0 (I just wanted to use the same tag in all my objects, initially was a cosmetic change) but the artifact content (terraform code) and also the plan obtained was the same

After fix my issue with tf-runner image, I checked and this has not been fixed or maybe I'm wrong with some configuration. Let me reming my environment, basically fluxcd running version v2.0.0-rc.1 and tf-controller v0.15.0-rc.1 as you suggested

I'm using tf-controller reading and writing tfstate from a Google bucket , GCS. I detected if there are some change in Terraform code should be applied but the terraform plan is the same, it means no change in cloud vendor in the target i can see this message, TFplan computed in go code from tf-controller is different than the previous applied.  I'm not sure if using tfstate from GCS affect in some way this tfplan computed is different due to I'm using BackendConfig and backendConfigsFrom in Terraform .spec .
This is interesting, if i'm removing the tfstate this error dissapear.

v0.14.2 fixed that for me

I also upgraded to  v2.0.0-rc.5 and tf-controller v0.15.0-rc.5 and it's not fixed for me. I also checked with break-glass and there are no changes in Terraform plan. I guess the new TFPlan computed should change some metadata and it's different in the name of plan-$TAG@sha256:HASH from the previous one....

This issues it's happening several times and this don't help me to convince my colleagues to migrate Terraform jobs to this . My environment is uptodate (v2.0.0-rc.5 and tf-controller v0.15.0-rc.5 ). Let me share more files if this can help me.
tfplan-fluxcd-cloudflare-account-liligo.tar.gz
tf-controller-log-issued.tar.gz
account-liligo.terraform.tar.gz
tfplan-fluxcd-cloudflare-account-liligo.secret.tar.gz
I checked the secret data value in the secret tfplan-fluxcd-cloudflare-account-liligo.secret.tar.gz  is compressed two times, maybe this could be the root cause, could be????
If I launch echo "XXXX" | base64 -d | gunzip -c | gunzip -c i can see this output:
datadogapikey/
"string" 833b14efec6df996d51b9408a27fe964=

account-id/
"string" 9b10dca6d786432ba56af7c0f75c109aM
cloudflareapitoken7
"string"(ctC6AZav6yQutj5TvFpAtPHArh1ESoi5v5hFOGCS2
datadog-ddsource
"string"cloudflare-audit/
datadog-ddtags
tring"liligo_commit_8B7provider["registry.terraform.io/cloudflare/cloudflare"]J
account_id 9b10dca6d786432ba56af7c0f75c109adatasetaudit_logsdestination_confٔdatadog://http-intake.logs.datadoghq.eu/v1/input?header_DD-API-KEY=833b14efec6df996d51b9408a27fe964&ddsource=cloudflare-audit&ddtags=liligo_commit_8enabledæfilterfrequencyhighid256125kindlogpull_optionskfields=ActorID,ActorIP,ID,OwnerID,NewValue,OldValue,OwnerID,ResourceID,ResourceType,When&timestamps=rfc3339nameaudit-logownership_challengezone_id

destination_conf"

destination_confRnullj cloudflare_logpush_job.audit_jobj
gcs
access_tokenbucketedo-tfstate-lab-servicescredentialsencryption_keyimpersonate_service_account%impersonate_service_account_delegateskms_encryption_keyprefix.tf-workspaces/fluxcd-cloudflare/account/liligostorage_custom_endpointfluxcd-cloudflarer1.5.02023-06-29T19:52:13Zgzip: stdin has more than one entry--rest ignored

This issue relates plan ids.

This bug is still on-going, let me try to re-open this issue

We would try to fix this by slightly changing the semantics of force: true to skip the annotation validation.

It seems we can close this as discussed.


[FEATURE]: tagging support on banners

How can the project be improved?
At motive, we want to track clicks on banners. We want to take advantage of the logic already implemented on the x-component side so during the development of this feature we find out that the Banner model accept a tagging structure, but it is not working (there's not a request performed when clicking a banner).
How can this be solved?
As far as we looked into it, we found that there's no wiring connection between the banner click event and the tagging config of each banner.
We were able to found a solution on our side, overriding the tagging wiring config and performing the tagging request on our own.
However, we think that this behaviour may fit on product side, so we will be able to decide wether if we want tagging on banners related to the tagging config of each banner.
Proposed solution
Create a wire in which we can perform a tagging request IF there's a tagging config on the banner clicked.
The event emited to x when clicking a banner is UserClickedABanner.
Customizations supported
No response
Additional information
Our own solution:
export const taggingOptions: XModulesOptions['tagging'] = {
  wiring: {
    ...
    UserClickedABanner: {
      trackBannerWire: filter(
        namespacedWireDispatch('tagging')(
          'track',
          ({ eventPayload: { tagging }, metadata: { location } }) => {
            const taggingInfo: TaggingRequest = tagging['click'];
            taggingInfo.params.location = location as string;
            return taggingInfo;
          }
        ),
        ({ eventPayload: { tagging } }) => !!tagging?.['click']
      )
    }
  }
};

and our banner object mapped has something like:
({
    ...
    tagging: {
      click: {
        url: `URL OF TAGGING SERVICE FOR A BANNER CLICK`,
        params: { ... }
      }
    }
 })

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

I would say that we missed this for both banners and promotions, since the demo  platform API that we are using does not return them.
It is easy to solve. We have some private helpers that are doing what you propose to add, so it should be even easier.
The only point that we need to be cautious about is with the platform adapter implementation, as it is currently mapping invalid tagging objects even if there is no tagging response

https://github.com/empathyco/x/blob/main/packages/x-adapter-platform/src/schemas/models/banner.schema.ts#L13

@javieri-empathy @AdrianArenal I see there is already a Motive PR merged about this topic, could we close this issue?

Which issue do you mean @herrardo? I can't see the banner or promoted tracking working

@herrardo We merged our custom solution so we have the banners tagging structure added on our side, but we would prefer having it by default on each Banner model retrieved by X.

We'll open a Pull  Request soon as ask you to review it ;)
cc @AdrianArenal @fernandossmm


[HIP][MI100] Virtual Memory Management API on MI100?

Does MI100 support the virtual memory management API? (functions hipMemAddressReserve, hipMemMap). I've been following this test case (https://github.com/ROCm-Developer-Tools/hip-tests/blob/094b9af382585a079d13c735fd170e69bea735b6/catch/unit/memory/hipMemVmm.cc), and virtual memory is always unsupported on all of our devices.
I've attached a small test program that queries for support and it always returns 0/false on rocm-5.4.2.
hipDeviceAttributeVirtualMemoryManagementSupported : 0
Is there something wrong with my setup or are these APIs just not supported on these devices?
#include <cstdio>

#include <hip/hip_runtime_api.h>

int main() {
    int vmm = 0;
    hipError_t result = hipDeviceGetAttribute(&vmm, hipDeviceAttributeVirtualMemoryManagementSupported, 0);
    if (result != hipSuccess) {
        return -1;
    }

    std::printf("hipDeviceAttributeVirtualMemoryManagementSupported : %d\n", vmm);
    return 0;
}

Which OS are you running?  For Ubuntu 20.04, you need the HWE stack.  I'm not sure about other distros.

Yup Ubuntu 20.04. Thanks, that makes sense - I'll try switching the kernel.

Switched to the HWE stack and reinstalled, but it's still coming back as not supported. Here's my kernel and package versions:
$dkms status
amdgpu, 5.18.13-1528701.20.04, 5.15.0-58-generic, x86_64: installed

hip-dev/focal,now 5.4.22803.50402-104~20.04 amd64 [installed,automatic]
rocm-dev/focal,now <IP_ADDRESS>402-104~20.04 amd64 [installed]

I do not see here something HIP RT-related:
  case hipDeviceAttributeVirtualMemoryManagementSupported:
    *pi = static_cast<int>(g_devices[device]->devices()[0]->info().virtualMemoryManagement_);
    break;

Looks like HW or HSA RT specifics.
@gargrahul, could you please have a look too?

Hey @gargrahul and @emankov, can we check back on this? Possible for us to get more info on your roadmap here / when it might be available? Email is fine, thanks.    cc: @crozhon

@gargrahul, @mangupta could you please let us know to whom we should address this ticket? We suspect HSA RT/HW.
Thank you in advance!

@crozhon : The ROCm driver does not support Virtual Memory Management and hence HIP runtime reports hipDeviceAttributeVirtualMemoryManagementSupported as 0. The support is being added in a future ROCm release. Please keep an eye out on the ROCm release notes to track this.

@crozhon We have an internal ticket to add support in future ROCm release. Will provide ROCm release info when available. Thanks!

Hi @crozhon, this feature has been implemented since ROCm 6.2.


Listeners using once and many are not able to determine the event type

Example code:
a = new EventEmitter2()

a.once('x',    function(){console.log(this.event);})  // console: undefined
a.many('x', 2, function(){console.log(this.event);})  // console: undefined
a.on('x',      function(){console.log(this.event);})  // console: x

a.emit('x')

I've fixed it on my way to the last pull request (apply this instead of null on line 223).
I see the package has been updated 2 days ago but isn't based on the master, what was the purpose of this update ?

@Marsup, i didn't do this last update, infact i was not even aware of it until now.

Fixed.


 Just restart and it's turned off again.

So this one comes from https://github.com/mickaelistria/eclipse.jdt.ls/blob/c66bab131df45f5e7a861d9c610952d17eecedfb/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JavaLanguageServerPlugin.java#L171 and it looks like there would either be a some preference to pass to the LS in order to not disable it or there would have to be some "if (!eclipse)" kind of guard.

I'm trying with :
if (!JavaLanguageServerPlugin.runInEclipseWorkbench) {
			try {
				Platform.getBundle(ResourcesPlugin.PI_RESOURCES).start(Bundle.START_TRANSIENT);
				IWorkspace workspace = ResourcesPlugin.getWorkspace();
				IWorkspaceDescription description = workspace.getDescription();
				description.setAutoBuilding(false);
				workspace.setDescription(description);
			} catch (BundleException e) {
				logException(e.getMessage(), e);
			}
		}

The submodule of jdt.ls is nice as a bandaid to have smth working but unfortunately I haven't figured out how to contribute to my jdt.ls fork from https://github.com/eclipse/eclipse.jdt.ls and contribute to @mickaelistria fork a PR.
FYI, @rgrunber .

Doing a quick look, autobuild is set on didChangeConfiguration, which should get called as part of initialization. It doesn't look like we set the auto-build on initialization, which is weird to me, but maybe it works because most clients call didChangeConfiguration anyways. Maybe the spec says something about that. Should a client make sure to call that or is it not guaranteed ? The other possibility, is maybe one of the other places that set the auto-build to false is being triggered and it's just a matter of figuring out why.

Spec says "A notification sent from the client to the server to signal the change of configuration settings."; here there are no change of configuration settings, it's still the default changes from initializationOptions that are to be used.
So I think the server shouldn't expect that the clients will necessarily send this notification, ie JDT-LS should probably just set it upon initialization.
Still I don't get fully why those lines are necessary here. If they happen to be necessary, are they always necessary or just in case of JDT-LS run via the application? And if it's the later, is the application running on a clean workspace everytime? If so we may just check that the workspace is empty before changing this configuration?

Found https://github.com/eclipse/eclipse.jdt.ls/pull/2252 . Looks like we do it for performance.
@snjeza, @gayanper, If some clients (eg. jdt.ls.client) want the autobuild to trigger as soon as it's safe to do so (not concerned with startup performance), could we just add some kind of : if (!preferenceManager.getPreferences().deferAutoBuild()) { setAutoBuilding(true); } at https://github.com/eclipse/eclipse.jdt.ls/blob/f704b7a0f27bc7e693ff7fff5aa678f945c5bf5f/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/ProjectsManager.java#L564-L565 ?

Fixed with #21

Happens again with   Java edition support using JDT Language Server Client	<IP_ADDRESS>302231543	.

It doesn't get disabled on startup as far as I see, but it can be disabled "randomly" some times. I suspect there is another place in JDT-LS where auto-build gets disabled for some operation, and not restored to previous value after.

The reason why my patch doesn't always work is that in some cases, on a restart, the JDT-LS plugin will start before the client one, so the client doesn't know about the value of auto-build before JDT-LS starts. https://github.com/eclipse/eclipse.jdt.ls/pull/2503 or similar would be a better fix and would also make things clearer on the LS-side (and progressively allow things like multiple clients in the same JDT-LS process, although hopefully it will never be necessary)

This should now be fixed with https://github.com/eclipse/eclipse.jdt.ls/pull/2503


[Bug]: Profile Picture Upload Not Functional

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
The "Upload Profile pic" button exists, but the functionality to actually upload and update the profile image is not working.
Expected behavior
Users should be able to upload and update their profile picture, with the updated image reflected on their profile page using JS functionality.
Add ScreenShots
No response
On which device are you experiencing this bug?
No response
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@dipexplorer will you be able to do or should i assign it to others

I will raise the PR soon.