CRASHPLAN_SRV_MAX_MEM environment variable issue

After the latest update to 22.10.4 Crashplan goes into a restart loop after warning that CRASHPLAN_SRV_MAX_MEM needs to be set.  I usually set it to 6112M for a ~5TB dataset but have increased it to 8192M for testing which makes no difference:
crashplan  | [logmonitor     ] ERROR: CrashPlan for Small Business is running out of memory. The application crashed because of lack of memory.  More memory needs to be allocated.  This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.
crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0).
crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'.
crashplan  | [supervisor     ] starting service 'CrashPlanEngine'...
crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0).
crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'.
crashplan  | [supervisor     ] starting service 'CrashPlanEngine'...
crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0).
crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'.
crashplan  | [supervisor     ] starting service 'CrashPlanEngine'...
crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0).
crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'.
crashplan  | [supervisor     ] starting service 'CrashPlanEngine'...
crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0).

Could you provide the full container log ?
docker logs <container name>

Oddly it's not showing exactly the same error, but here's the full output:
crashplan  | [init        ] container is starting... crashplan  | [cont-env    ] loading container environment variables... crashplan  | [cont-env    ] APP_NAME: loading... crashplan  | [cont-env    ] APP_VERSION: loading... crashplan  | [cont-env    ] DISPLAY: executing... crashplan  | [cont-env    ] DISPLAY: terminated successfully. crashplan  | [cont-env    ] DISPLAY: loading... crashplan  | [cont-env    ] DOCKER_IMAGE_PLATFORM: loading... crashplan  | [cont-env    ] DOCKER_IMAGE_VERSION: loading... crashplan  | [cont-env    ] GTK_THEME: executing... crashplan  | [cont-env    ] GTK_THEME: terminated successfully. crashplan  | [cont-env    ] GTK_THEME: loading... crashplan  | [cont-env    ] HOME: loading... crashplan  | [cont-env    ] QT_STYLE_OVERRIDE: executing... crashplan  | [cont-env    ] QT_STYLE_OVERRIDE: terminated successfully. crashplan  | [cont-env    ] QT_STYLE_OVERRIDE: loading... crashplan  | [cont-env    ] TAKE_CONFIG_OWNERSHIP: loading... crashplan  | [cont-env    ] XDG_CACHE_HOME: loading... crashplan  | [cont-env    ] XDG_CONFIG_HOME: loading... crashplan  | [cont-env    ] XDG_DATA_HOME: loading... crashplan  | [cont-env    ] XDG_RUNTIME_DIR: loading... crashplan  | [cont-env    ] container environment variables initialized. crashplan  | [cont-secrets] loading container secrets... crashplan  | [cont-secrets] container secrets loaded. crashplan  | [cont-init   ] executing container initialization scripts... crashplan  | [cont-init   ] 10-certs.sh: executing... crashplan  | [cont-init   ] 10-certs.sh: terminated successfully. crashplan  | [cont-init   ] 10-check-app-niceness.sh: executing... crashplan  | [cont-init   ] 10-check-app-niceness.sh: terminated successfully. crashplan  | [cont-init   ] 10-cjk-font.sh: executing... crashplan  | [cont-init   ] 10-cjk-font.sh: terminated successfully. crashplan  | [cont-init   ] 10-clean-logmonitor-states.sh: executing... crashplan  | [cont-init   ] 10-clean-logmonitor-states.sh: terminated successfully. crashplan  | [cont-init   ] 10-clean-tmp-dir.sh: executing... crashplan  | [cont-init   ] 10-clean-tmp-dir.sh: terminated successfully. crashplan  | [cont-init   ] 10-fontconfig-cache-dir.sh: executing... crashplan  | [cont-init   ] 10-fontconfig-cache-dir.sh: terminated successfully. crashplan  | [cont-init   ] 10-init-users.sh: executing... crashplan  | [cont-init   ] 10-init-users.sh: terminated successfully. crashplan  | [cont-init   ] 10-jwm.sh: executing... crashplan  | [cont-init   ] 10-jwm.sh: terminated successfully. crashplan  | [cont-init   ] 10-nginx.sh: executing... crashplan  | [cont-init   ] 10-nginx.sh: terminated successfully. crashplan  | [cont-init   ] 10-vnc-password.sh: executing... crashplan  | [cont-init   ] 10-vnc-password.sh: terminated successfully. crashplan  | [cont-init   ] 10-web-data.sh: executing... crashplan  | [cont-init   ] 10-x11-unix.sh: executing... crashplan  | [cont-init   ] 10-x11-unix.sh: terminated successfully. crashplan  | [cont-init   ] 10-xdg-runtime-dir.sh: executing... crashplan  | [cont-init   ] 10-xdg-runtime-dir.sh: terminated successfully. crashplan  | [cont-init   ] 15-install-pkgs.sh: executing... crashplan  | [cont-init   ] 15-install-pkgs.sh: terminated successfully. crashplan  | [cont-init   ] 55-crashplan-pro.sh: executing... crashplan  | [cont-init   ] 55-crashplan-pro.sh: setting CrashPlan Engine maximum memory to 1024M crashplan  | [cont-init   ] 55-crashplan-pro.sh: terminated successfully. crashplan  | [cont-init   ] 55-validate_max_mem.sh: executing... crashplan  | [cont-init   ] 55-validate_max_mem.sh: terminated successfully. crashplan  | [cont-init   ] 85-take-config-ownership.sh: executing... crashplan  | [cont-init   ] 85-take-config-ownership.sh: terminated successfully. crashplan  | [cont-init   ] 89-info.sh: executing... crashplan  |     ╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮ crashplan  |     │                                                                      │ crashplan  |     │ Application:           CrashPlan for Small Business                  │ crashplan  |     │ Application Version:   10.4.0                                        │ crashplan  |     │ Docker Image Version:  22.10.4                                       │ crashplan  |     │ Docker Image Platform: linux/amd64                                   │ crashplan  |     │                                                                      │ crashplan  |     ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯ crashplan  | [cont-init   ] 89-info.sh: terminated successfully. crashplan  | [cont-init   ] all container initialization scripts executed. crashplan  | [init        ] giving control to process supervisor. crashplan  | [supervisor  ] loading services... crashplan  | [supervisor  ] loading service 'default'... crashplan  | [supervisor  ] loading service 'app'... crashplan  | [supervisor  ] loading service 'CrashPlanEngine'... crashplan  | [supervisor  ] loading service 'gui'... crashplan  | [supervisor  ] loading service 'certsmonitor'... crashplan  | [supervisor  ] service 'certsmonitor' is disabled. crashplan  | [supervisor  ] loading service 'jwm'... crashplan  | [supervisor  ] loading service 'xvnc'... crashplan  | [supervisor  ] loading service 'nginx'... crashplan  | [supervisor  ] loading service 'logmonitor'... crashplan  | [supervisor  ] all services loaded. crashplan  | [supervisor     ] starting services... crashplan  | [supervisor     ] starting service 'CrashPlanEngine'... crashplan  | [supervisor     ] starting service 'xvnc'... crashplan  | [xvnc           ] Xvnc TigerVNC 1.12.0 - built Oct 29 2022 14:30:50 crashplan  | [xvnc           ] Copyright (C) 1999-2021 TigerVNC Team and many others (see README.rst) crashplan  | [xvnc           ] See https://www.tigervnc.org for information on TigerVNC. crashplan  | [xvnc           ] Underlying X server release 12013000, The X.Org Foundation crashplan  | [xvnc           ] Mon Oct 31 13:59:26 2022 crashplan  | [xvnc           ]  vncext:      VNC extension running! crashplan  | [xvnc           ]  vncext:      Listening for VNC connections on /tmp/vnc.sock (mode 0660) crashplan  | [xvnc           ]  vncext:      Listening for VNC connections on all interface(s), port 5900 crashplan  | [xvnc           ]  vncext:      created VNC server for screen 0 crashplan  | [supervisor     ] starting service 'jwm'... crashplan  | [supervisor     ] starting service 'nginx'... crashplan  | [nginx          ] Listening for HTTP connections on port 5800. crashplan  | [supervisor     ] starting service 'app'... crashplan  | [supervisor     ] starting service 'logmonitor'... crashplan  | [logmonitor     ] Monitoring log file: /config/log/service.log.0 crashplan  | [logmonitor     ] Monitoring status file: /config/log/app.log crashplan  | [supervisor     ] all services started. crashplan  | [logmonitor     ] ERROR: CrashPlan for Small Business is running out of memory. The application c. crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0). crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'. crashplan  | [supervisor     ] starting service 'CrashPlanEngine'... crashplan  | [supervisor     ] service 'CrashPlanEngine' exited (with status 0). crashplan  | [supervisor     ] restarting service 'CrashPlanEngine'. crashplan  | [supervisor     ] starting service 'CrashPlanEngine'...

Looks like the CRASHPLAN_SRV_MAX_MEM environment variable is not set correctly.
What is the output of docker inspect <container name> ?

Yeah it doesn't appear to be processing the memory variable, though it is set in the environment properly:
[
{
"Id": "5e5b3180d5da43b1840d68be39421dfcb60f9350e2cf5a85217d5fa25fc6f3b5",
"Created": "2022-10-31T17:08:29.232663698Z",
"Path": "/init",
"Args": [],
"State": {
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 930671,
"ExitCode": 0,
"Error": "",
"StartedAt": "2022-10-31T17:08:29.727869537Z",
"FinishedAt": "0001-01-01T00:00:00Z"
},
"Image": "sha256:bdbd7b79cdb1ba351024ab5e1bcf488ccdef8280d1770a3e17a28e5bd0a3f9e9",
"ResolvConfPath": "/var/lib/docker/containers/5e5b3180d5da43b1840d68be39421dfcb60f9350e2cf5a852,
"HostnamePath": "/var/lib/docker/containers/5e5b3180d5da43b1840d68be39421dfcb60f9350e2cf5a85217,
"HostsPath": "/var/lib/docker/containers/5e5b3180d5da43b1840d68be39421dfcb60f9350e2cf5a85217d5f,
"LogPath": "/var/lib/docker/containers/5e5b3180d5da43b1840d68be39421dfcb60f9350e2cf5a85217d5fa2,
"Name": "/crashplan",
"RestartCount": 0,
"Driver": "overlay2",
"Platform": "linux",
"MountLabel": "",
"ProcessLabel": "",
"AppArmorProfile": "docker-default",
"ExecIDs": null,
"HostConfig": {
"Binds": [
"/docker/config/crashplan:/config:rw",
"/media:/media:ro",
"/backup:/backups:ro"
],
"ContainerIDFile": "",
"LogConfig": {
"Type": "json-file",
"Config": {}
},
"NetworkMode": "crashplan_default",
"PortBindings": {
"5800/tcp": [
{
"HostIp": "",
"HostPort": "5800"
}
],
"5900/tcp": [
{
"HostIp": "",
"HostPort": "5900"
}
]
},
"RestartPolicy": {
"Name": "unless-stopped",
"MaximumRetryCount": 0
},
"AutoRemove": false,
"VolumeDriver": "",
"VolumesFrom": null,
"CapAdd": null,
"CapDrop": null,
"CgroupnsMode": "private",
"Dns": null,
"DnsOptions": null,
"DnsSearch": null,
"ExtraHosts": [],
"GroupAdd": null,
"IpcMode": "private",
"Cgroup": "",
"Links": null,
"OomScoreAdj": 0,
"PidMode": "",
"Privileged": false,
"PublishAllPorts": false,
"ReadonlyRootfs": false,
"SecurityOpt": null,
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 0,
"Memory": 0,
"NanoCpus": 0,
"CgroupParent": "",
"BlkioWeight": 0,
"BlkioWeightDevice": null,
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 0,
"CpuQuota": 0,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": null,
"DeviceCgroupRules": null,
"DeviceRequests": null,
"KernelMemory": 0,
"KernelMemoryTCP": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"MemorySwappiness": null,
"OomKillDisable": null,
"PidsLimit": null,
"Ulimits": null,
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0,
"MaskedPaths": [
"/proc/asound",
"/proc/acpi",
"/proc/kcore",
"/proc/keys",
"/proc/latency_stats",
"/proc/timer_list",
"/proc/timer_stats",
"/proc/sched_debug",
"/proc/scsi",
"/sys/firmware"
],
"ReadonlyPaths": [
"/proc/bus",
"/proc/fs",
"/proc/irq",
"/proc/sys",
"/proc/sysrq-trigger"
]
},
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/883a7f76dcb8fbd97e273d6723592d3b5a131d776587b11c3,
"MergedDir": "/var/lib/docker/overlay2/883a7f76dcb8fbd97e273d6723592d3b5a131d776587b11c,
"UpperDir": "/var/lib/docker/overlay2/883a7f76dcb8fbd97e273d6723592d3b5a131d776587b11c3,
"WorkDir": "/var/lib/docker/overlay2/883a7f76dcb8fbd97e273d6723592d3b5a131d776587b11c33"
},
"Name": "overlay2"
},
"Mounts": [
{
"Type": "bind",
"Source": "/docker/config/crashplan",
"Destination": "/config",
"Mode": "rw",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/media",
"Destination": "/media",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/backup",
"Destination": "/backups",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
},
{
"Type": "volume",
"Name": "caeb52936217edcbf3648c181297c91eee473a4ebca6d9807e05f006700cc572",
"Source": "/var/lib/docker/volumes/caeb52936217edcbf3648c181297c91eee473a4ebca6d9807e05,
"Destination": "/storage",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
"Config": {
"Hostname": "5e5b3180d5da",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": true,
"AttachStderr": true,
"ExposedPorts": {
"5800/tcp": {},
"5900/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"KEEP_APP_RUNNING:1",
"CRASHPLAN_SRV_MAX_MEM:8192M",
"TZ:Europe/London",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"USER_ID=1000",
"GROUP_ID=1000",
"SUP_GROUP_IDS=",
"UMASK=0022",
"TZ=Etc/UTC",
"KEEP_APP_RUNNING=0",
"APP_NICENESS=0",
"INSTALL_PACKAGES=",
"CONTAINER_DEBUG=0",
"DISPLAY_WIDTH=1920",
"DISPLAY_HEIGHT=1080",
"DARK_MODE=0",
"SECURE_CONNECTION=0",
"SECURE_CONNECTION_VNC_METHOD=SSL",
"SECURE_CONNECTION_CERTS_CHECK_INTERVAL=60",
"WEB_LISTENING_PORT=5800",
"VNC_LISTENING_PORT=5900",
"VNC_PASSWORD=",
"ENABLE_CJK_FONT=0",
"CRASHPLAN_SRV_MAX_MEM=1024M"
],
"Cmd": [
"/init"
],
"Image": "jlesage/crashplan-pro",
"Volumes": {
"/backups": {},
"/config": {},
"/media": {},
"/storage": {}
},
"WorkingDir": "/tmp",
"Entrypoint": null,
"OnBuild": null,
"Labels": {
"com.centurylinklabs.watchtower.enable": "true",
"com.docker.compose.config-hash": "c096a2523202da0820f9bac45317ff11bf689fe316a9859a78a2,
"com.docker.compose.container-number": "1",
"com.docker.compose.depends_on": "",
"com.docker.compose.image": "sha256:bdbd7b79cdb1ba351024ab5e1bcf488ccdef8280d1770a3e17a,
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "crashplan",
"com.docker.compose.project.config_files": "/docker/crashplan/docker-compose.yml",
"com.docker.compose.project.working_dir": "/docker/crashplan",
"com.docker.compose.service": "crashplan-pro",
"com.docker.compose.version": "2.10.2",
"org.label-schema.description": "Docker container for CrashPlan PRO",
"org.label-schema.name": "crashplan-pro",
"org.label-schema.schema-version": "1.0",
"org.label-schema.vcs-url": "https://github.com/jlesage/docker-crashplan-pro",
"org.label-schema.version": "22.10.4"
}
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "6012f56e96658c0b6574a0eee264c91064a10f19087271dddce0500fc8eb3e0a",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"5800/tcp": [
{
"HostIp": "<IP_ADDRESS>",
"HostPort": "5800"
},
{
"HostIp": "::",
"HostPort": "5800"
}
],
"5900/tcp": [
{
"HostIp": "<IP_ADDRESS>",
"HostPort": "5900"
},
{
"HostIp": "::",
"HostPort": "5900"
}
]
},
"SandboxKey": "/var/run/docker/netns/6012f56e9665",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"MacAddress": "",
"Networks": {
"crashplan_default": {
"IPAMConfig": null,
"Links": null,
"Aliases": [
"crashplan",
"crashplan-pro",
"5e5b3180d5da"
],
"NetworkID": "b16283c96ede9da68dd34a9cb13b986ba847f2e41bb797c0d5b50d16922f9fc9",
"EndpointID": "010a02412839cea114a7c132d87937340843d0f68623a11e06c9183350e0c84d",
"Gateway": "<IP_ADDRESS>",
"IPAddress": "<IP_ADDRESS>",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:13:00:02",
"DriverOpts": null
}
}
}
}
]

The problem is that the variable is set 2 times:
...
"CRASHPLAN_SRV_MAX_MEM:8192M",
...
"CRASHPLAN_SRV_MAX_MEM:1024M",
...

How did you create the container ?

I use docker compose, the compose file never changed until I increased the memory after the issue started. Odd.

From: Jocelyn Le Sage @.***>
Sent: Monday, 31 October 2022 17:13
To: jlesage/docker-crashplan-pro
Cc: Alibloke; Author
Subject: Re: [jlesage/docker-crashplan-pro] CRASHPLAN_SRV_MAX_MEM environment variable issue (Issue #389)
The problem is that the variable is set 2 times:
...
"CRASHPLAN_SRV_MAX_MEM:8192M",
...
"CRASHPLAN_SRV_MAX_MEM:1024M",
...
How did you create the container ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Just realized that CRASHPLAN_SRV_MAX_MEM:8192M has a colon instead of the equal character.
It should be, like other variables, CRASHPLAN_SRV_MAX_MEM=8192M instead of CRASHPLAN_SRV_MAX_MEM:8192M.  Probably the variable is not set correctly in your compose file ?

Interesting, that's sorted it.  The docker compose file didn't change, but there was a docker update today.  Thanks for the assist!


MailHog not working when using nginx proxy pass

I am using MailHog as a Docker container (using docker-compose) and for default configuration everything is OK. Unfortunately when I created Nginx proxy pass I get an error in browser console
VM61:35 WebSocket connection to 'ws://mailhog.sf3.dev:81/api/v2/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

I guess it is bad configuration problem but as far as I know there is no option to configure MailHog image for docker-compose.

@Prazmok Add this to your nginx config ...  That should do the trick. You must ensure that your mime.types are well configured
       chunked_transfer_encoding on;
       proxy_set_header X-NginX-Proxy true;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_http_version 1.1;
       proxy_redirect off;
       proxy_buffering off;

More https://www.nginx.com/blog/websocket-nginx/

I've added a note to the configuration section of the docs - it's probably not in the most obvious place, but hopefully it'll help someone out!

Here is the equivalent config for the Apache

<LocationMatch /api/v2/websocket>
    ProxyPass ws://<IP_ADDRESS>:3001/api/v2/websocket
</LocationMatch>

Related comment about Apache proxy configuration https://github.com/mailhog/MailHog/issues/142#issuecomment-316062636

Below block worked for me
  location ^~ /mailhog/ {         chunked_transfer_encoding on;         proxy_set_header X-NginX-Proxy true;         proxy_pass http://localhost:8025/;                 proxy_set_header Upgrade $http_upgrade;         proxy_set_header Connection "upgrade";         proxy_http_version 1.1;         proxy_redirect off;         proxy_buffering off;   } }

Below block worked for me
location ^~ /mailhog/ {
       chunked_transfer_encoding on;
       proxy_set_header X-NginX-Proxy true;
       proxy_pass http://localhost:8025/;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_http_version 1.1;
       proxy_redirect off;
       proxy_buffering off;
 }

I used this inside a new server block together with my rails app configuration, i've put a server_name and only / instead of /mailhog/


Unit support by way of Pint (supporting xarray > Pint > dask data structures)

As raised in https://github.com/xgcm/xgcm/issues/222, it would be great to have some form of unit support in xgcm, and it's a feature I'm especially interested in coming from MetPy, where unit support is a central feature. The current leading library for this in the ecosystem (at least as far as integrations with other libraries go) is Pint, particularly since it fully implements (or at least tries to!) the "nested duck array" approach implied by the type casting hierarchy of NEP-13/18.
In practice, for a library like xgcm, this looks like xarray DataArrays/Datasets containing Pint Quantities, which in turn contain Dask Arrays (order chosen based off of run-time metadata and pickling concerns). Everything needed to make this happen on a basic level is in place thanks to the efforts of @keewis, @rpmanser, myself, and others, but admittedly, the integration is still in its early stages and there are bound to be bugs that have yet to be worked out. Though, I think it would be worth experimenting with it here in xgcm as a way to bring about unit support.
I'd be interested in helping with this (especially as a way to open up integrations between MetPy and xgcm), but I unfortunately don't think I'd have many free cycles to dedicate to this in the near future, so someone else please feel free to take this on!
Related Issues in Upstream/Parallel Libraries
https://github.com/hgrecco/pint/issues/883
https://github.com/pydata/xarray/issues/4208
https://github.com/Unidata/MetPy/issues/1479

Thanks for the great summary @jthielen. I think this would be a worthwhile addition IF (like @rabernat mentioned in #222) we do not sacrifice performance.

This issue is still relevant. It is something I'd like to investigate later this summer when I hopefully have more time available (I'd really like to explore application areas of xgcm with NWP models and use alongside MetPy).

That would be a really amazing contribution @jthielen, I am really excited to see what you come up with.
I marked the issue with keepOpen to keep the bot away.


Error pages: Route back to forms, add a user-friendly message following 500 and 404 messages just in case. Link to support?

This may not happen often but just in case there is an error, we can add links to the homepage and support so it is logged back to us.

PROPOSED/ Section: ERROR Messages
Short term component:
In layout:

Figma file: PROPOSED/Section: ERROR messages

Next step: Review -> Translation

Totally cool to remove the header for these pages.
This would be a short-term solution, there is more we can add to this page to help users find information.

Updated designs with content and translation review completed

DESIGN UPDATE - April 14 2023
Main changes and additions:

404 errors: There will be no header since the page will static
404 and general errors: For an authenticated view, the "Back" button will route the user back to "Your forms", for unauthenticated view, they will be routed to our home marketing page
500 errors: There will be no "Back" or "Support" buttons because it will be an outage on our side. "Please try again later" is all we can do for now
Permission error: a general error if a user doesn't have permissions for a form or a page
Closed/deleted form error: When a form is closed, but the link is still available, it will route end-users to a friendly message the form is closed. (content and design is related to the alert that it comes with

@anikbrazeau basically did most of this 🌷 I just drew the rectangles lol

Getting the groundwork set up for this sprint

For this the groundwork will be setting up an error boundary
See:
https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary
We could also consider using https://github.com/bvaughn/react-error-boundary

I'll start work on the Error Boundary

Formatting for 500 and 404 is quite limiting - Decision to add a simple bilingual message with GC Forms title works for now. These errors are errors we would catch first, if a ticket comes through support regarding these screens, we will iterate from there

PR : https://github.com/cds-snc/platform-forms-client/pull/2089

Support route exists for 404 :) All good to close this ticket

Separate issue for 500 error page created here, to be prioritized into the PB. Will now be closing this issue.


Add a scope option to the query

This PR adds the ability to use the --scope={scope} option on exports.
If you have defined a scope on your model for example:
    public function scopeActive(Builder $query): void
    {
        return $query->where('active', true);
    }

passing --scope=active to the export assures you only export the active models.

@RemiHin this PR is approved and released on v2.2
Thank you for your contribution!


AWS Connection working?

Hi,
is the aWS connection working?
Thank you

Closing, please see https://github.com/bwp91/homebridge-govee/issues/367


SAK-33864: GBNG > improve performance of Gradebook Import process

https://jira.sakaiproject.org/browse/SAK-33864
This PR contains several changes to the back-end code that performs the Gradebook Import:

Reduce the amount of logging performed during the saving routine, change the log level appropriately
** Currently an INFO level log message is produced for each grade, and each comment, for each user in each "sheet" that is processed
** For large imports, this equates to a lot of logging statements, which contributes to log bloat and probably reduces performance on some level
** It also could be argued that it's a security concern to log grades and user identifiers at INFO level OOTB
Bulk save grades and comments per assignment/gradebook item
** The current process saves each grade and each comment for each student in each item serially, and waits for a return code from each save/update
** This slows down the import process immensely; massive improvements in processing time are achieved by saving grades and comments in bulk, one assignment/grade item at a time
** Also, the return value was never being used. I think originally it was designed this way to have real-time feedback in case someone else was editing the same item/grade/comment; however there's no code to actually perform this. Even if we were to implement this, what decision should be made? Does the Import suddenly abort or fail? Does the exact item that was concurrently edited get skipped? In our opinion, concurrent edits don't really matter for the context of an Import; the last saved value should always take precedence and there is always the grade log to see who made changes and when.
** Instead of returning one return code per grade/student/assignment, return one code per saveGradesAndComments() call
Eliminate String->Double conversion where appropriate
Reduce double/triple/etc querying
** There are multiple places where the same data is being re-queried multiple times and then tossed out, rather than being passed down the line for use in other places. Refactoring these places to utilize the already retrieved data correlates to large performance increases
AJAX panel swap the CreateGradeItemStep/GradeImportConfirmationStep panels into place to avoid a page refresh and the associated loading/rendering time between each step
Fixed a bug when navigating back and forwards through the Import wizard, which causes loss of user data:
** To reproduce, import a gradebook item with no points, assign points in the import wizard, hit next, hit back, and see that your points are now missing.
** Also, when going back and forth in the wizard and changing your mind about things like points, you'll be presented with "Title required and must be unique" when you finally try to save, although it does still create your item, but only the first version you set up (ie. if you picked 10 points and then went back to make it 15 points, you'll be presented with the title error but the item will be created with 10 points behind the scenes even if you just leave the wizard.
Fixed a bug where if you import an item with no points possible in the header, grading data would not be imported for this column. The item would be created, but all the grades in the corresponding spreadsheet column would be ignored.
** To reproduce, import a spreadsheet containing one new gradebook item and a corresponding comment column. Do not give the item a points possible value in the header, but give some students both grades and comments. Import the file, notice that the wizard forces you to give the item a points possible value in the next step, finish the wizard; notice the item was created, all comments were imported but none of the grades were imported.

Please see the JIRA ticket for performance metrics and scenario breakdowns.


Add ability to call healthcheck from WorkflowClient

Customer request:

does temporal client have something similar to Ping() ?
c, err := client.NewClient(client.Options{
HostPort: <WRONG_HOSTPORT>,
})
when I start a workflow worker with the above, no error is returned until when you do something — would be nice to have something similar to SELECT 1 in postgres

My proposal is to add ability to call grpc health check endpoint of the frontends.

Make sure API has support to do that in the future.


Example of multi_label classification with unitxt.

Status
IN DEVELOPMENT
Description
Example code to show to integrating unitxt (https://github.com/IBM/unitxt) and IBM GenAI and LM eval harness.
To run , you should also acquire the unfair_tos_train.csv and unfair_tos_test.csv files and place under the unitxt_example folder.
Then use:
poe lm_eval   --model="ibm_genai" --model_args="model_id=google/flan-t5-xl" --task="unitxt_example" --num_fewshot=0 --limit 30 --output output --log_samples
Impacted Areas in Library
Lm eval harness extension
Any special notes for your reviewer?
Joint work with @jezekra1

Checklist

[ ] Automated tests exist
[x ] Updated Package Requirements (if required, and with maintainers' approval)
[ ] Local unit tests performed
[ ] Documentation exists link
[ ] Local pre-commit hooks performed
[ ] Desired commit message set as PR title and description set above
[ ] Link to relevant GitHub issue provided

Closing because you can install an unreleased version into your project using:
poetry add 'git+https://github.com/IBM/ibm-generative-ai.git@add-lm-eval-extension[lm-eval]'

You can then add unitxt tasks and experiments in your own repository


Feature Request : a "Shift Shift" keybinding to open Commands

I would find really cool to have a rapid "shift shift" press to open the command prompt (as it exists for global project search in Idea/IntelliJ products), but this would require a specific key binding
I'm not a Go developer but I can try if someone explains to me where I should start, I've seen some base key bindings in cmd/micro/bindings.go but I'm not sure those hard coded shortcut could help

At the moment micro only supports chords for keybindings and not rapid keypresses.

Ok, I understand that

Also shift shift would not be a possible binding because terminals do not send a separate event for just the shift key.
I'm going to close this because I don't see this being supported in the future (note you can always rebind CommandMode to a normal keybinding so it doesn't have to be CtrlE).


FAQ Maintenance

Weekly check to see if the FAQ needs updating.

Created a Google docs on some questions I am asking. Will update the Wiki FAQ after questions and answers are finalized.
https://docs.google.com/document/d/1lXxVIMbdk4dzEx4k7R-pt17aY3l4cMa9yVUbJAz6S0Y/edit?usp=sharing

Created a Google docs on some questions I am asking. Will update the Wiki FAQ after questions and answers are finalized.
https://docs.google.com/document/d/1lXxVIMbdk4dzEx4k7R-pt17aY3l4cMa9yVUbJAz6S0Y/edit?usp=sharing

This issue is being closed as all documentation is now centralised in ReadTheDocs. For example see here for FAQ.


Fix dependencies to ic repo

I pushed another commit to this PR fixing a few more issues:

Fix feature usage on upgrade methods in api derive macros. Because of wrong cfg statement our canisters' uprade was totally broken (all the state was lost)
Move some of the pair types into the pair module (out of types.rs) to fix build of the AMM pair. It was broken by some long-ago refactoring.
Correct the return type of notify method in api derive macro to fix pair factory build. It has different Result type in scope, so return type without specifying namespace broke the build.


#152124144 backend unit testing

What does this PR do?

sets up unit testing for the backend

Description of Task to be completed?

backend unit testing

How should this be manually tested?

run npm test

Any background context you want to provide?

use Mocha, Supertest and Chai

What are the relevant pivotal tracker stories?
Nil
Screenshots (if appropriate)
Nil
Questions:
Nil

Changes Unknown when pulling f7e9c633836f975fb279f6aad36a17a2204545b1 on chore/152124144/setup-unit-testing into ** on development**.


Fixes incorrect XP values for Urium Remains

This pull request fixes the incorrect XP values for Urium Remains as per the wiki. The correct values are 120.5 and 180.7 XP, with and without the Morytania hard diary.
Fixes #18083

Duplicate of #18086

Added in #18086


Add .NET MAUI support version doc

Description
Added to the requirement that it is available from the Azure DevOps Pipeline version as well as UWP support for the following reasons:

.NET MAUI support is not available in stable as of today, it appears to be available only from the development version of Azure DevOps Pipeline.
Functions related to UWP are specified to use the development version version, but there is no description for Xamarin.Forms

Addresses #1265

@brandonh-msft  you are correct, some bug fixes were pushed but not released, it should roll into the next GA release. Outside of that, there are no new PRs that are being merged in at the moment.

the last PR I added to address a few of the MAUI related issues was : https://github.com/dotnet/upgrade-assistant/pull/1238
This is the one I guess would resolve the problem? Although the problem looks like the current GA doesn't have this last PR code in it? the Nightly build does, so like you mentioned, once we do a next release to GA it should resolve most of this.

Thanks - linked & closed


does not work from sub folder

when using the kit from a sub folder only a blank  page is rendered

@mouhsinelonly Does #880 help?

no it does not work , it worked before removing
const browserHistory = useRouterHistory(createBrowserHistory)({
basename : BASENAME
})

@mouhsinelonly if you need to add a custom basename to the router you can still do so, but it will require importing the history package and configuring the basename as you pointed out above. I removed this explicit dependency as it was superfluous to the majority of use cases.

@davezuko I just tried to get the starter pack up and running hosted on a specific page of my java application. That took me about half an hour of puzzling and debugging WITH the boilerplate already in place. (I'd forked the starter pack before commit 4ecc655) If I hadn't found the BASENAME, I strongly suspect I'd have had to hack it into place, breaking the dev server.
"Just import the history and configure the basename" is nontrivial for someone doing their first deploy.

@davezuko I am trying to achieve the same as you suggested, but it somehow breaks routing. This is what I did:

Create a appHistory.js module where I create my custom history:

const historyConfig = {
  basename: __BASENAME__
};
export const appHistory = useRouterHistory(createBrowserHistory)(historyConfig);
export default appHistory

Set it on Router by passing it as a prop to AppContainer :

  render () {
    const { routes, store, history } = this.props;

    return (
      <Provider store={store}>

          <Router history={history} children={routes} />

      </Provider>
    )
  }

Configured the same history in createStore.js:

import appHistory from '../apphistory'

//...

store.unsubscribeHistory = appHistory.listen(updateLocation(store))

Result: the app runs without errors in console, but the router doesn't seem to work (and thus I get a blank page). Can you spot any mistake in the snippets above? I don't have a lot of experience with history and react-router, so I'm at loss...

Someone got this working so far?

I tried to reimplement it as it used to be in commit https://github.com/davezuko/react-redux-starter-kit/commit/4ecc655ae7c5db83e6c3edffd7456a667191bf2e but my page just stays blank without any errors about routes that do not match.
I do
useRouterHistory(createBrowserHistory)({
 basename : __BASENAME__
})
console.log('basename:', __BASENAME__, browserHistory)

The basename is indeed set but it seems that the routing does not take it into account since any other routes give me a 404.

Is there a complete code base that would demonstrate this config? I would really need this setup working.

@amergin calling useRouterHistory to create a custom history as showed above it's really all there is to it.  Yet in the code above createBrowserHistory is imported by import createBrowserHistory from 'history/lib/createBrowserHistory'? Which specific version of history did you settle on using, that didn't cause you issues?

Also, I'm assuming this approach does not take into account any static resource paths, ie. assets that are in static/ and are used in the html markup?

It seems like the problem is indeed with the version of history i.e. 4.3.0 in my case. Any workaround other than using an older version? And if not how would I use the transitive dependency?

@amergin yes, you import createBrowserHistory from that path.
Then, you create a custom history in a module you create (e.g., apphistory.js):
const historyConfig = {
  basename: __BASENAME__
};

export const appHistory = useRouterHistory(createHistory)(historyConfig);

export default appHistory

Now, you use this history instead of the default one. In AppContainer.js:
import appHistory from '../apphistory'

  render () {

    const { routes, store } = this.props;

    const onError = (error) => {
      console.log('Router error',  error)
    };

    return (
      <Provider store={store}>

          <Router history={appHistory} children={routes} onError={onError}/>

      </Provider>
    )
  }

Don't forget to set __BASENAME__. I set it in my package.json like this:
    "deploy:prod": {
      "command": "npm run deploy",
      "env": {
        "NODE_ENV": "production",
        "DEBUG": "app:*",
        "BASENAME": "/stqts/"
      }
    },

@jenyckee Removing the explicti history listed in the dependencies in package.json did the trick for me. Calling npm list history reports I have installed react-router version 2.8.1 and transitively history version 2.1.2.

Now my app renders but the routing is still broken. The location changes are not preventDefault and tries to access my server. What could this be?

I am facing the same issue while deploying on sub folder. The app loads with blank page. Tried setting basename to '/sub/' and compiler_public_path to '/sub/' but no luck.

@ajainvivek I followed the steps above and it worked for me.  I'll add a couple more steps in case that helps.  I needed to install history 3.2.1, since it was the history referenced from react-router 3.0.2.  Installing latest version of history gives errors like "getCurrentLocation is not a function" (blank page, but console error was helpful!).
src/appHistory.js
Note

The newer version of history doesn't have /lib/)
__BASENAME__is set in package.json "deploy:prod"

import { useRouterHistory } from 'react-router'
import createBrowserHistory from 'history/lib/createBrowserHistory'

const historyConfig = {
  basename: __BASENAME__
}

export const appHistory = useRouterHistory(createBrowserHistory)(historyConfig)

export default appHistory

config/environments.config.js
production : (config) => ({
    compiler_public_path     : '/directory_name_here/',

In AppContainer.js

Remove import for browserHistory from react-router
Add import for appHistory file listed above  If using same file as simonedavico

import appHistory from '../appHistory'

Change Router prop as indicated in previous post by simonedavico

To be honest not sure why this was removed from starter kit, since I would imagine it is helpful for many people.  In my case it was needed for gh-pages, which deploys in a subdirectory.

I had the same issue and can confirm that steps provided by @simonedavico worked. Thanks @brianzinn for the extra explanation, you two saved my night.
@davezuko Are the steps above documented somewhere? Maybe FAQ? I'd be really helpful.
BTW, thanks for such a good starter kit 👍


Deploy working (static) demo app

Can generate fake data for, say, 3 fake courses, and link it with a timeout to emulate the fetching.

https://student-dashboard.netlify.com/


That's what this already does: https://github.com/Jiiks/BetterDiscordApp/blob/master/lib/BetterDiscordT.js

That file makes it pull from a manually updated file in this repo. My fix pulls from the live list on twitchemotes.com which is constantly updated

This was applied with 0.2.6. Thanks :)


ambermini static

So this change, on my machine where I've trashed the file libquadmath.0.dylib from my homebrewed-gfortran, which causes the linker to statically link to libquadmath, produces a static build.
I can upload the binary to binstar.

But this is obviously not portable.

OK.  And so the idea is to just append CUSTOMBUILDFLAGS to LDFLAGS and do manual builds for now?

No, the ambermini makefile uses CUSTOMBUILDFLAGS itself. You don't have to append it to anything. You just need to run this recipe with a carefully-broken version of gfortran installed in the precise location /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/.

Got it

Okay. I uploaded the file to https://binstar.org/omnia/ambermini/files.

What about installing gfortran as a conda package as an alternative?

That sounds like a lot of work...

Compilers are generally the hardest piece of software to compile.

Sounds like a major project.  If that were easy to do, the Continuum people would have done it.

Sounds good, but we probably need to IFDEF that flag so that it doesn't occur on linux:
gfortran: /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.a: No such file or directory
gfortran: /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.a: No such file or directory
make[1]: *** [dasum.o] Error 1
make[1]: Leaving directory `/home/vagrant/miniconda/conda-bld/work/ambermini-v.14.0.1/blas'
make: *** [libs] Error 2
Command failed: /bin/bash -x -e /home/vagrant/rmc/conda-recipes-ambermini/ambermini/build.sh


tooltip for bloodfury inaccurate

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Sim Links and Screenshots
If applicable, add links to your sim settings or screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

The tooltips come directly from wowhead, and wowhead only shows the level 1 version of this tooltip: https://www.wowhead.com/wotlk/spell=33697/blood-fury
So unfortunately there isn't anything we can do here.  :(


Connection pool shut down error while doing graceful shutdown in spring boot

We are using spring boot version "2.3.0.M4" and have set the following parameter "server.shutdown.grace-period=30s". However when we do graceful shutdown(SIGTERM) our endpoint in the end publishes an event and the event listener publishes a message to AWS Message Queue; It successfully serves the HttpRequest however we see the following error on the console while the event listener publishes the message:
java.lang.IllegalStateException: Connection pool shut down
        at org.apache.http.util.Asserts.check(Asserts.java:34)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.requestConnection(PoolingHttpClientConnectionManager.java:269)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.amazonaws.http.conn.ClientConnectionManagerFactory$Handler.invoke(ClientConnectionManagerFactory.java:76)
        at com.amazonaws.http.conn.$Proxy155.requestConnection(Unknown Source)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:176)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
        at com.amazonaws.http.apache.client.impl.SdkHttpClient.execute(SdkHttpClient.java:72)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1258)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1074)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:745)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:719)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:701)

I'm a bit unsure what this has to do with spring cloud. Maybe try spring boot.


Describe database-specific limitations on unlimited string uniqueness

Was not sure whether to describe the limitation here or in case-sensitive-database-behavior

Hi Pavel (@dahfjkg),
I think it would be better in this area of the documentation: https://docs.mendix.com/refguide/data-storage/. There is already a link to https://docs.mendix.com/refguide/case-sensitive-database-behavior/, so I think it would be better to have this information there. But then, I think we need to rename the document to something like Database String Behavior.
What do you think?
@katarzyna-koltun-mx : do you have any thoughts on this?
In the Oracle documentation, we also mention uniqueness: https://docs.mendix.com/refguide/oracle/#34-uniqueness-constraint - but this seems to be a stricter limitation than the one we are talking about here, so I think it needs to stay specific to the Oracle description.

@MarkvanMents That makes sense, but also, we have individual articles on different database types (e.g. https://docs.mendix.com/refguide/mysql/) - maybe this info should be distributed across these articles? I'm thinking a user would typically only need to see the behaviour for their own database type.

@MarkvanMents @katarzyna-koltun-mx I agree. There are more database-specific differences in unlimited string behavior that ability to create a uniqueness constraint. I will create a separate page in data storage and call it Unlimited String Behavior

@MarkvanMents @katarzyna-koltun-mx I've updated the PR and created a separate page with unlimited string behavior per database. Please check the format of the page

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: dahfjkg:x: katarzyna-koltun-mxYou have signed the CLA already but the status is still pending? Let us recheck it.

@dahfjkg Hi Pavel, I've merged your requested change. It should be published tomorrow.


improvement: select list component is better with react windowed select

What:

This PR aims to improve the performance of the SelectList component

Why:

Closes #57

How:

Uses react-windowed-select to not render all the elements at once

Media:

Watch me loom here
Checklist:

[x] Ready to be merged

Love the work here and I think that we should merge this as an improvement for now but I have a concern about how we don't control the version of react-select anymore. Like it'd be nicer if react-select was a peer dependency of react-windowed-select so that we could keep control of that. (because it might contain other performance benefits in the future that we'd want to take advantage of)

@christopherrolfe198 completely agree, however I think we have for ourselves a little time, the library seems to support v4.x as well of react-select. But I agree that it's not a permanent solution, maybe we can raise a request to maintain it as a peer dep 🤷🏻


Sources from remote ?

Hi @triniwiz :-)
Do you think we can imagine add splash screen come from http resources ?
// Get resolution from device here ? : https://github.com/NativeScript/NativeScript/issues/203#issuecomment-104372076
let size = "@x2";
let splash = new SplashScreen(`http://remote.com/images/splashscreen/${size}/twitterIcon.png`, '#4E75E2');

// Then stored in the cache....

that would be awesome. @kefahB  did you ever try to create that?

Hi,
No ! beause I dont now if this plugin still work with NS 6 ? do you try it ?

not yet, maybe in the next weeks :)


[TASK] implement usage of packages/semaphore into unit and functional tests

Overview
Task Checklist

[ ] Implement usage of packages/semaphore onto tests/unit_tests/{SemaphoreVoting.ts,SemaphoreWhistleblowing.ts}
[ ] Implement usage of packages/semaphore onto `tests/cross-chain

unit_tests currently do not need the Semaphore typescript interface. Should integrate the tests with the interface for all unit-tests. Later will change the unit-tests for the SemaphoreVoting and SemaphoreWhistleblowing to its own interfaces but they're not implemented yet.
functional tests test/functional_test/CrossChain.ts are currently failing. Should integrate with https://github.com/webb-tools/webb.js/blob/master/packages/test-utils/src/startGanacheServer.ts and update the interfaces that were used in the test.

closed on https://github.com/webb-tools/semaphore-anchor/pull/10


Cart Chunk and BWF support

Hi!
Here's the support for cart/bext chunks in Reader().  I've yet to refactor the Writer class, to cope with extra subchunks, which is a little tricker as we'd need to define how the fields are set (I'm guessing the opts that are passed in the constructor, like those in the fmt header).  I've also written in a new test, and an example file containing both of these chunks (CC_0101.wav)
One noteworthy change to the behaviour - if Reader encounters an unknown chunk ID, it won't error as it did before - it will emit an "unknown" event with the raw buffer data for that chunk.  I needed this for my application - and not knowing about a chunk isn't technically an error, so it's convenient to have the logical separation between actual errors and things we just don't understand.
Hopefully, all this will make it easier to support other subchunk types in the future - I have my eye on adding "iXML" support too.
I have added one little utility function into reader.js - but this might be better incorporated into the Reader class itself - although there's no real need to.
Hope it's OK!
Cheers,

Fork it!
I've been missing these changes as well, and no development seems to be going on here.

I've recently been added as a maintainer to this repo, I would be happy to assist getting this in 👍
As it is now, there seems to be some conflicts that needs to be resolved...

Cool ! What's required ? Happy to fix.

Rebasing on master should probably give you a few conflicts, just fix those and push up again :)

All conflicts should now be resolved.

Thanks - all those issues should be fixed (2013 me has disappointed 2016 me :) )

I've added linting to our test so if you rebase on master and run npm test you should get all my comments locally :)

I've updated the linting on master again, it would be nice if you could rebase on latest master. As it is now, it seems like the changes on master is showing up in the diff 🤔 a rebase should solve it...


Additional features for review view - warnings and withdraw

Set boarder and text to red on application warnings
Add application withdraw feature
Fix @endunless in the review blade

CooL! This looks good :+1:


Docker Backend: fully support windows container

close #4286
address one bug described in https://github.com/woodpecker-ci/woodpecker/issues/4274
TODO: actuall testing of:

[x] normal steps
[ ] services -> we dont have a service that is packaged for my test host as of my knowing
[x] plugins

look's like it works :)
the only thing is i had to modify the clone plugin:
--- a/plugins/plugin-git/Dockerfile.Windows
+++ b/plugins/plugin-git/Dockerfile.Windows
@@ -1,7 +1,7 @@
 # syntax = docker/dockerfile:1
 # escape=`

-FROM mcr.microsoft.com/windows/servercore:ltsc2022
+FROM mcr.microsoft.com/windows/servercore:1809

 # Busybox Unicode https://github.com/rmyorston/busybox-w32

so yes woodpecker itselve wont support windows container fully ...
... mostly depending on:

https://github.com/woodpecker-ci/autoscaler/issues/202
https://github.com/woodpecker-ci/autoscaler/issues/133 (we need to autoscale a windows host with docker configured to host windows container ...)

PS: I still have no idea why some things work and some are incompatible :/

my test config:
.woodpecker/check.yaml:
labels:
  backend: docker
  platform: windows/amd64

skip_clone: true

depends_on:
    - echo

steps:
    check_echo:
        image: mcr.microsoft.com/windows/servercore:1809
        commands:
            - echo some checks
            - sleep 2s

.woodpecker/echo.yaml:
labels:
  backend: docker
  platform: windows/amd64

when:
  - event: pull_request
  - event: [push, deployment]
    branch:
      - ${CI_REPO_DEFAULT_BRANCH}

clone:
  clone:
    image: woodpecker-windows-git

steps:
    createFile:
        image: mcr.microsoft.com/windows/servercore:1809
        commands:
            - echo FROM alpine:edge >> Dockerfile
            - echo RUN apk update >> Dockerfile

    echo:
        image: mcr.microsoft.com/windows/servercore:1809
        commands:
            - echo buildZ
            - sleep 10s
            - ls
    depl:
        image: bash
        commands: echo deploy
        when:
            - event: deployment
              branch: ${CI_REPO_DEFAULT_BRANCH}

@cduchenoy :point_up: ...?

Hi,
It's excellent!
On Windows, we must take the tag which corresponds to the kernel version
see https://hub.docker.com/r/microsoft/windows-servercore
So I think I should check :)

1809 => Windows server 2016 base
ltsc2019 => Windows server 2019 base
ltsc2022 => Windows server 2022 base
ltsc2025 => Windows server 2025 base

did you also test the agent build?
https://github.com/GECO-IT/woodpecker-windows/blob/main/agent/backend-docker/Dockerfile.Windows

For test a service image, you can use as a base: https://github.com/GECO-IT/woodpecker-windows/blob/main/base/windows-base/Dockerfile.base-chocolatey.Windows
Base image are in docker-hub: https://hub.docker.com/r/gecoit84/woodpecker-windows-base-chocolatey
and add:
choco install mysql

I haven't tried so I don't know if it launches the service correctly

did you also test the agent build?

no as I only wana test if the engine works ... so the deployment of the agent should not alter the test ...

labels:
  backend: docker
  platform: windows/amd64

skip_clone: true

steps:
    create:
        image: mcr.microsoft.com/windows/servercore:1809
        commands:
            - echo some checks > NEW
            - sleep 2s

    curl:
        image: a6543/woodpecker-windows-base-chocolatey:latest
        commands:
            - choco install -y curl
            - curl.exe -I http://caddy:80
            - curl.exe http://caddy:80/NEW

services:
    caddy:
        image: a6543/woodpecker-windows-caddy-static:latest
        ports:
            - 80

services work just fine ...

->  #4464


Optimize foo.bar=foo.bar

This is impossible because it will always be implemented as temp=foo.bar foo.bar = temp


advanced-ip-scanner: Fix checkver

Relates to Excavator checkver not working: https://github.com/ScoopInstaller/Extras/runs/5750830616?check_suite_focus=true#step:3:193

[x] I have read the Contributing Guide.

/verify


Key inputs go missing after pressing caps lock

For a short period of time after pressing the caps lock key subsequent key presses will be ignored.
This can easily be reproduced either at the MOS prompt or a BASIC prompt.  Press the caps lock key and then immediately type a letter, and nothing will show up.
It feels like keyboard input takes about 1s to start working again.

On my Olimex Agon light 2, VDP 1.04 RC1, MOS 1.04 RC1, basic 1.05 , keyboard from Olimex "delux", it works perfectly.

After I posted this I noticed that there has been some new commits made to this repo which appear to affect how the keyboard is handled.  I need to update my MOS and re-test, but that might take me a little while.
Similarly it seems I'm running version 1.05 of BASIC so I'll need to update that too.
At least my VPD is up to date 😀
I'll try to update my MOS and BASIC soon and re-test

Thanks. I'll mark this card as 'Won't Do'


ENH: replace linalg.inv and linalg.pinv by linalg.solve

Problem Description
Some code like https://github.com/shap/shap/blob/master/shap/explainers/_kernel.py#L644-L647 uses the logic
A_inv = np.linalg.inv(A)
x = A_inv @ b

instead of the much more stable and (usually) faster
x = np.linalg.solve(A, b)

Alternative Solutions
No response
Additional Context
Originally spotted by @jjerphan.
Feature request checklist

[X] I have checked the issue tracker for duplicate issues.
[X] I'd be interested in making a PR to implement this feature

Thank you for reporting it, @lorentzenchr!
I would like to work on this, but I unfortunately have enough contributions to track and to commit to.


Refactor test_native/test_cryptolib.py to use BoaConstructor

Summary or solution description
Refactored test_native/test_cryptolib.py files to use BoaTestCase in place of BoaTest for unit testing.

Task linked: CU-86drpnc98 Refactor test_native/test_cryptolib.py to use BoaConstructor

coverage: 92.111%. remained the same
when pulling f0c5fa7acbfc4c72aa199b9c0419f556edeb22ad on CU-86drpnc98
into e184e5b619a45ddb907ff610da6d0422a71e8b64 on development.


[Epic] Cryostat3 test harness

Describe the feature
We want to create a test harness with common test cases to run against Cryostat deployment, with ability to deploy either 2.4 or 3.0 and with varying deployment parameters (report sidecar, other CR properties).

The existing scorecard test suite looks like it could be a candidate to fulfill the criteria, but there are a few things I wonder.

The test cases seem to be hardcoded here: https://github.com/tthvo/cryostat-operator/blob/dbf4f5ef718e73556a4978e1bf33599fc3a81d8c/internal/images/custom-scorecard-tests/main.go#L106 . This works but seems annoying and error-prone to maintain if we want to make this into a test matrix where we can run the same tests against different CRs. Is there a cleaner way to define the test cases?
The Operator will naturally evolve with the Cryostat version, so it will drop the ability to deploy 2.4 instances in favour of the ability to deploy 3.0 instances. I believe it's possible, but must confirm that it's also possible to specify the Operator version to install and which CRs to provide it, so that we can do things like install a 2.4 Operator and deploy Cryostat 2.4, run the suite of tests, then install a 3.0 Operator and Cryostat 3.0 and run the same tests.
What are our options for conditionally enabling certain tests to run only against certain Cryostat versions? For the most part we are aiming for broad API compatibility, but there are a few intentional breaking API changes, so we need a nice way to run tests conditionally against versions, either to simply turn off tests or to provide alternate versions of close equivalent tests.
Is this simply the wrong place to look at adding this test capability? This scorecard test suite will also be used for downstream product builds and will require a pass in the build pipeline. In this scenario tests should only be run against the new version being built so that any sporadic failures in the older versions don't cause the new version's build to fail. We already know that such sporadic failures can occur in some workflows, so multiplying that chance by a run matrix makes this problem worse and makes builds unnecessarily difficult to publish.

Summary of our team call:

use the scorecard test suite as this harness
build out more tests on the main branch here so that we have e2e tests with high API coverage. UI interaction is not tested but the full deployment and API interaction will be
continue using the Cryostat CR (not ClusterCryostat) to parameterize various deployment configurations - the Operator will know how to add default values or perform conversions to accept these old 2.4 CRs into 3.0 CRs as necessary, so the scorecard suite doesn't need to carry CR versioning info
upstream work for deploying Cryostat 3 will target an upstream cryostat3 feature branch instead of main


[ADBDEV-1938] Explain provides wrong rows number when flow is missing

When we ask GPDB to explain a query, it uses flow to scale down rows number, but ORCA generates flow only for those nodes that are Motion's children, so for those nodes which lack flow, gpdb uses segments count, which can be incorrect for those cases when the Motion is singleton. Consider this example:
DROP TABLE IF EXISTS lab1;
CREATE TABLE lab1 (id int, descr text) WITH (appendonly=true) DISTRIBUTED BY (id);
INSERT INTO lab1 SELECT generate_series(1,5000) AS id, md5(random()::text) AS descr;
explain analyze select t1.id, row_number() over (order by t1.id desc) from lab1 t1 join lab1 t2 using(descr);
                                                    QUERY PLAN
-------------------------------------------------------------------------------------------------------------------

WindowAgg  (cost=0.00..8279.15 rows=12500000 width=12) (actual time=7877.140..19003.216 rows=25000000 loops=1)
   Order By: lab1.id
   ->  Gather Motion 2:1  (slice2; segments: 2)  (cost=0.00..8179.15 rows=25000000 width=4) (actual time=7877.092..12694.123 rows=25000000 loops=1)
         Merge Key: lab1.id
         ->  Sort  (cost=0.00..7730.15 rows=12500000 width=4) (actual time=7874.529..9583.758 rows=12730000 loops=1)
               Sort Key: lab1.id
               Sort Method:  external merge  Disk: 195520kB
               ->  Hash Join  (cost=0.00..1046.52 rows=12500000 width=4) (actual time=6.390..1543.301 rows=12730000 loops=1)
                     Hash Cond: (lab1.descr = lab1_1.descr)
                     Extra Text: (seg1)   Hash chain length 5000.0 avg, 5000 max, using 1 of 131072 buckets.
                     ->  Seq Scan on lab1  (cost=0.00..431.07 rows=2500 width=37) (actual time=0.180..2.948 rows=2546 loops=1)
                     ->  Hash  (cost=435.54..435.54 rows=5000 width=33) (actual time=4.338..4.338 rows=5000 loops=1)
                           ->  Broadcast Motion 2:2  (slice1; segments: 2)  (cost=0.00..435.54 rows=5000 width=33) (actual time=0.084..2.978 rows=5000 loops=1)
                                 ->  Seq Scan on lab1 lab1_1  (cost=0.00..431.07 rows=2500 width=33) (actual time=0.167..0.803 rows=2546 loops=1)
 Planning time: 24.088 ms
   (slice0)    Executor memory: 232K bytes.
   (slice1)    Executor memory: 204K bytes avg x 2 workers, 204K bytes max (seg0).
 * (slice2)    Executor memory: 67558K bytes avg x 2 workers, 67558K bytes max (seg0).  Work_mem: 65758K bytes max, 612237K bytes wanted.
 Memory used:  128000kB
 Memory wanted:  1837210kB
 Optimizer: Pivotal Optimizer (GPORCA)
 Execution time: 20194.755 ms
(22 rows)

As we see, WindowAgg has 12500000 rows, when its child plan contains 25000000 rows, and WindowAgg has a number of rows less than expected exactly by the number of segments, which is caused by missing flow.
This patch doesn't rely on flow, it uses gangSize of a current slice which is calculated correctly and always presents. gangSize is a simple and reliable way to get a number of segments which processed some part of a plan. Also, we added a new field to child expressions which holds the number of parent motion's input segments. Previously, if the distribution was replicated or tainted replicated, we just multiplied rows number by the number of segments, but now we use parent motion's input segments number.
However, orca has another peculiarity related with how it calculates rows number. The specialty of orca is that it can return fractional number of rows, and explain should ceil them later. This can lead to a situation when orca returns a wrong rows number, explain ceils it and we get an incorrect answer. For example, such query
create table tcorr1(a int, b int);
create table tcorr2(a int, b int);

insert into tcorr1 values (1,99);
insert into tcorr2 values (1,1);

explain
select *
from tcorr1 out
where out.b in (select coalesce(tcorr2.a, 99)
                from tcorr1 left outer join tcorr2 on tcorr1.a=tcorr2.a+out.a);

will give a plan like this
                                               QUERY PLAN
--------------------------------------------------------------------------------------------------------
 Result  (cost=0.00..1356692026.74 rows=1 width=8)
   Filter: (SubPlan 1)
   ->  Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..431.00 rows=1 width=8)
         ->  Seq Scan on tcorr1  (cost=0.00..431.00 rows=1 width=8)
   SubPlan 1  (slice0)
     ->  Result  (cost=0.00..1324032.56 rows=2 width=4)
           ->  Nested Loop Left Join  (cost=0.00..1324032.56 rows=2 width=4)
                 Join Filter: (tcorr1_1.a = (tcorr2.a + tcorr1.a))
                 ->  Materialize  (cost=0.00..431.00 rows=1 width=4)
                       ->  Gather Motion 3:1  (slice3; segments: 3)  (cost=0.00..431.00 rows=1 width=4)
                             ->  Seq Scan on tcorr1 tcorr1_1  (cost=0.00..431.00 rows=1 width=4)
                 ->  Materialize  (cost=0.00..431.00 rows=1 width=4)
                       ->  Gather Motion 3:1  (slice2; segments: 3)  (cost=0.00..431.00 rows=1 width=4)
                             ->  Seq Scan on tcorr2  (cost=0.00..431.00 rows=1 width=4)
 Optimizer: Pivotal Optimizer (GPORCA)
(15 rows)

As we see, nested loop join has two rows when it can have only one. This happens because orca return 1.2 rows for this node and explain ceils this number to 2.
Initially, the problem was that orca doesn't generate Flow for Motion nodes, implying that the number of segments on which this node is executed is the total number of segments, that's why we changed the way how rows number is calculated for different types of Motion. However, it's not always the case, so it was decided to use the gang size of a slice. This seemed to work, but it turned out that it broke Replicated distribution because orca multiplies rows number by itself. Also, Postgres optimizer filled rows number of Motion's nested nodes incorrectly, so we had to recursively traverse plan tree and reassign them.

When we ask GPDB to explain a query, it uses flow to count rows number, and it can be either a single segment command, acommand can be executed on all segments or a limited number of segments in general cases. But there are cases when the flow is not generated, so GPDB uses segments count by default, what can be incorrect for some nodes, which are executed on a single segment only, for example.

Please clarify this statement to understand that we talk about ORCA. Describe how and why ORCA fills flow.
It seems, you lost changes in your commit 9aa2108. Where are changes on the ORCA side?

When we ask GPDB to explain a query, it uses flow to count rows number, and it can be either a single segment command, acommand can be executed on all segments or a limited number of segments in general cases. But flow is not generated by orca unless it's a Motion node, so GPDB uses segments count by default, what can be incorrect for some nodes, which are executed on a single segment only, for example.

GPDB uses flow to scale tuples per executors not to count. ORCA fills flow not for Motion nodes, but for nodes below them. What is why it's bad idea to rely on flow as far as there are cases when ORCA generates singleton slices (on master or on segment). Desc

As we see, WindowAgg has 12500000 rows ...

Your snippet doesn't contain WindowAgg node.

This patch doesn't rely on flow, it uses gangSize of a current slice which is calculated correctly and always presents. gangSize is a simple and reliable way to get a number of segments which processed some part of a plan.

I think it's a good idea to mention that gang size is calculated from flow below motions. That is why ORCA fill it.

However, orca has another bug related with how it calculates rows number.

If it was a mistake, we should have corrected it. Please reword it to explain row estimation changes.

Previously, if data distribution was replicated, we multiplied the number of rows by the number of segments in a slice in CTranslatorExprToDXL::GetProperties, and the number of segment was recursively passed from the parent Motion node. However, if the Motion is random and sensitive for duplicated (executed on one segment only), it is replaced with Result node and its rows number isn't multiplied by the number of segments which causes incorrect explain output
The last commit checks if the Motion is random and duplicate sensitive. If so, we pass all the segments to that motion which causes the number of rows to be multiplied correctly.
This solution causes a big diff because it changes InputSegments field of RandomMotion nodes. For example, InputSegments="0" is replaced by InputSegments="0,1,2", which can be misleading, as the child node should be executed on a single segment only

All the changed plans are affected by CTranslatorExprToDXL::GetProperties and seem legin to me

If we have a replicated table which needs to be scanned, orca can create a Random Motion for it and use One-Time Filter which will randomly pick a segment this slice will be executed on, then this Motion will be transformed to a Result node when converting from dxl to postgres plan. Normally, such slice should be planned to be executed on all segments and then changed to a slice which will be executed on one segment only during translation from dxl to postgres plan, but there's a trick in orca which sets the number of segments for this slice to 1 on a stage of forming a dxl plan. Previously, this slice's rows number was multiplied by the number of segments on a cluster, but one of commits changed this logic for replicated data, multiplying it on a real number of segments the slice will be executed on. While this works well for other cases, the plan described above won't have the correct rows number because of this orca's thick. We could've removed it, but it would cause a big diff in dxl plans. changing the InputSegments property of such nodes, so we decided to leave it as is. So, the number of rows for such nodes will be scaled down by the number of segments on the cluster, though it should equal to an actual number of rows of the entire table, because the distribution is replicated

Allure report https://allure-ee.adsw.io/launch/54303

How about such small optimization https://github.com/arenadata/gpdb/pull/624 ?

I suggest to separate the ORCA part into another patch https://github.com/arenadata/gpdb/pull/625.

How about such optimizations https://github.com/arenadata/gpdb/pull/628 ?

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/948856

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/948857

Failed job Behave tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/948855

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/948850

Allure report https://allure-ee.adsw.io/launch/61410

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/949365

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/949366

Failed job Build for x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/999329

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/999330

Allure report https://allure-ee.adsw.io/launch/62565

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/999427

Allure report https://allure-ee.adsw.io/launch/62586

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1000136

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1000137

Allure report https://allure-ee.adsw.io/launch/62711

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1005831

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1005832

Allure report https://allure-ee.adsw.io/launch/62774

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1009011

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1009012

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1009003

Allure report https://allure-ee.adsw.io/launch/62869

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1012989

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1012983

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1093896

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1093888

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1093895

Failed job Behave tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1093893

Allure report https://allure-ee.adsw.io/launch/65609

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113206

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113204

Failed job Behave tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113203

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113196

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113198

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113205

Failed job Regression tests with Postgres on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113197

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1113199

Allure report https://allure-ee.adsw.io/launch/65946

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1128481

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1128479

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1128480

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1128474

Allure report https://allure.adsw.io/launch/66078

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1132687

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1132688

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1132682

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1137211

format PR description according to guidelines

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1137212

Allure report https://allure.adsw.io/launch/66407

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1148574

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1148575

Allure report https://allure.adsw.io/launch/66444

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1150039

Allure report https://allure.adsw.io/launch/66467

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1150848

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1150846

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1150847

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1150840

fix linter tests

Allure report https://allure.adsw.io/launch/66492

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1152347

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1152348

Why new scale_factor test passes and without patch?

Why new scale_factor test passes and without patch?

@RekGRpth I ran scale_factor on adb-6.x-dev and got pretty large diff file.

Why new scale_factor test passes and without patch?

@RekGRpth I ran scale_factor on adb-6.x-dev and got pretty large diff file.

I run without patch both with and without optimizer
./pg_regress --load-extension=gp_inject_fault --init-file=init_file scale_factor
...
test scale_factor             ... ok

Allure report https://allure.adsw.io/launch/66891

Failed job Orca unittests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1175396

@dnskvlnk, fix tests, please.

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1175402

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1175403

Allure report https://allure.adsw.io/launch/67479

Failed job Orca unittests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1207390

Failed job Orca unittests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1207391

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1207389

Allure report https://allure.adsw.io/launch/69617

Нахожусь в отпуске с 22.04 - 27.04 с ограниченным доступом к почте. По вопросам продукта Arenadata DB прошу обращаться к Руслану Мусакалимову

Failed job Resource group isolation tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1317264

Failed job Resource group isolation tests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1317265

Allure report https://allure.adsw.io/launch/69622

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1317468

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1317470

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1317471

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1319837

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1320250

Allure report https://allure.adsw.io/launch/69676

Failed job Behave tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1321213

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1321210

Allure report https://allure.adsw.io/launch/69722

Allure report https://allure.adsw.io/launch/69723

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1323588

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1323603

Allure report https://allure.adsw.io/launch/70008

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1341058

Failed job Regression tests with Postgres on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1341059

Allure report https://allure.adsw.io/launch/70169

Failed job Behave tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1353746

Failed job Regression tests with Postgres on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1353740

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1353739

Allure report https://allure.adsw.io/launch/70201

Allure report https://allure.adsw.io/launch/70231

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1365565

Failed job Build for x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1365564

Allure report https://allure.adsw.io/launch/70377

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1378832

Failed job Build for x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1378831

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1380212

Failed job Build for x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1380211

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1387939

Failed job Build for x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1387990

Failed job Build for ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1387991

Allure report https://allure.adsw.io/launch/70825

Failed job ORCA code linter on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1395652

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1395644

Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1395645

Allure report https://allure.adsw.io/launch/70915

Allure report https://allure.adsw.io/launch/71137

@dnskvlnk, reformat PR description

Allure report https://allure.adsw.io/launch/71241

Allure report https://allure.adsw.io/launch/71638

Failed job Behave tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1443063

fix conflicts again

Failed job Orca unittests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1685244

Failed job Orca unittests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1685245

Failed job Behave tests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1685246

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1685240

Allure report https://allure.adsw.io/launch/76036

Failed job Orca unittests on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1686912

Failed job Orca unittests on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1686914

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1686907

Allure report https://allure.adsw.io/launch/76070

Allure report https://allure.adsw.io/launch/76273

Allure report https://allure.adsw.io/launch/78461

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1816841

Allure report https://allure.adsw.io/launch/78524

Allure report https://allure.adsw.io/launch/79719

This patch still too raw to merge. Let's rework it later, according priority.


Error response from daemon: linux init cgroups path: mkdir /init.scope: read-only file system

Description

docker run fails to start the container
Steps to reproduce the issue:

use docker run --rm armhf/hello-world

Describe the results you received:
docker: Error response from daemon: linux init cgroups path: mkdir /init.scope: read-only file system.

Describe the results you expected:
for the container to be run successfully
Additional information you deem important (e.g. issue happens only occasionally):
I think the error is a red herring. I'm not sure how else to debug. starting docker daemon in debug mode doesn't yield anything else. I'm not sure if it is a kernel issue or a docker issue.
I am testing docker 1.13 on LibreELEC. LibreELEC uses a squashfs, read-only file system, however, everything works fine with 1.12
dockerd is run via
/storage/.kodi/addons/service.system.docker/bin/dockerd --exec-opt native.cgroupdriver=systemd --group=root --graph=/storage/.kodi/userdata/addon_data/service.system.docker/docker --storage-driver=overlay2

Output of docker version:
Client:
 Version:      1.13.0-rc4
 API version:  1.25
 Go version:   go1.7.4
 Git commit:   1.13.0-rc4
 Built:        Mon Jan  2 23:56:09 UTC 2017
 OS/Arch:      linux/arm

Server:
 Version:      1.13.0-rc4
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.4
 Git commit:   1.13.0-rc4
 Built:        Mon Jan  2 23:56:09 UTC 2017
 OS/Arch:      linux/arm
 Experimental: false

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 1.13.0-rc4
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862 (expected: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e)
runc version: N/A (expected: 51371867a01c467f08af739783b8beafc154c4d7)
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Kernel Version: 4.9.0
Operating System: LibreELEC (community) - Version: devel-20161213102424-r24950-g2c4fd3c
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 735.7 MiB
Name: LibreELEC
ID: YILE:FLLX:VW3C:SJAZ:LZYR:MX2L:6B6B:MRAQ:PFS2:BYBJ:NFI4:AHCY
Docker Root Dir: /storage/.kodi/userdata/addon_data/service.system.docker/docker
Debug Mode (client): true
Debug Mode (server): false
Username: lrusak
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support
WARNING: No cpuset support
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
uname -a
Linux LibreELEC 4.9.0 #1 SMP Tue Dec 13 10:24:02 PST 2016 armv7l GNU/Linux

Raspberry Pi 2

Error is coming from https://github.com/docker/docker/blob/96a84ed85a010c2cf6dc3308ae30e6594a519e59/daemon/oci_linux.go#L668 (actual error is caused here; https://github.com/docker/docker/blob/1dd941077653bc93ee4141c4d2bac90534678e3f/daemon/daemon_unix.go#L1200-L1204)
Which was added in https://github.com/docker/docker/commit/56f77d5ade945b3b8816a6c8acb328b7c6dce9a7
Looks like at least that path should only be created if that option is set


Add Lambda Expression support for Java Step Implementations

Feature Enhancement Request
Add lambda expression support for Java Step Implmentations
For e.g. we should be able to define our steps like this
@Step({"Open the browser" , () -> {
      System.out.println("Opening the browser");
     .......
    ......
} });

This will enable the people using gauge to write functional code, as supported in Java 8 and above.

Thanks for the suggestion, This is the pattern followed in dynamic languages that gauge supports, ex ruby/javascript.
@Step etc are currently defined as annotations, and thus are expected to be decorated around a method. We'll have to figure out a way to get this in.
PS - Pull requests are most welcome!

Hi Sriv,
I would be happy to contribute :)

@anirudh83 Circling back on this and closing the issue due to inactivity. Please feel free to reach out for any help and will re-open this in that case.


Make use of docker-slim

See https://github.com/docker-slim/docker-slim
This seems to represent a viable option to further reduce our image's size.

Do mumble have some dynamic lib load ?
I think qt have dynamic load.

Idk - I just figured it might be worth a try to see if we can further reduce the image's size :shrug:

FYI: I have worked on another solution (manually building a distroless container for mumble) which is still WIP (only tested it with SQLite so far) in my fork of this repo.
I replaced the entrypoint.sh script with a custom built binary built in Rust (still learning it) to get rid of the shell and copied over the required shared libraries from a compatible debian image. It's not yet fully compatible with the official image here (I disabled some features I personally didn't need).
Once I have rebuilt it with the same feature set as the official build, I'll open a PR here.

Do mumble have some dynamic lib load ? I think qt have dynamic load.

Yes, the database drivers are loaded at runtime. Running ldd on the mumble-server binary does not show them.

Did you guys consider using Alpine?
Something as simple as this:
FROM alpine:3.19

ENV USER murmur
ENV PORT 64738

RUN adduser ${USER} \
    -DHs /sbin/nologin

RUN apk add --no-cache murmur

RUN mkdir /data && \
    chown -R ${USER}:${USER} /data

COPY --chown=${USER}:${USER} ./murmur.ini /data/murmur.ini

VOLUME /data

EXPOSE ${PORT}/tcp
EXPOSE ${PORT}/udp

USER ${USER}
CMD [ "/usr/bin/murmurd", "-ini", "/data/murmur.ini", "-fg"  ]

generates sub 70 MiB image, pretty good.
There are plenty of Alpine-based images on Dockerhub and on Github.
And you can always have a separate tag for Alpine.

Yes we did but there is no support for ZeroC Ice on Alpine (last time I checked at least) which the server uses as a RPC framework.

@Krzmbrzl I see, indeed.
For me it's an okay tradeoff to use a smaller image without ZeroC Ice. Separate tag like mumble-server:alpine with notice about not supporting ZeroC Ice can be an option.

mumble is the first project I see that uses that zeroc. Even in Arch repos I see it being used only for mumble:
https://archlinux.org/packages/extra/x86_64/zeroc-ice/ -> See Required by
It gotta be pretty legacy, all the cool kids use web interfaces now, right? Or unix sockets etc. Also docs for interfacing via pretty confusing, but that's another issue.

Could be done, yeah but would make things for us here more complicated. Not sure this would really be worth it 🤔


AppVeyor configuration as yml

Hi Gaez,
could you provide your build configuration of AppVeyor as yml-file (appveyor.yml)?
This would be easier for us to test our forks with your configuration.

Hi!
Please find attached the current appveyor.yml (in a zip due to Github restrictions).
appveyor.zip

Could u add this as part of your source code management? It should be placed like here. https://github.com/SchwabenCode/QuickIO


Update Jenkinsfile-online

Please don't waste the community members' time to check your meaningless changes. Why do I say it's meaningless? Check the following reasons:

meaningless PR title
you just submit your personal account info