17.06 won't deploy stack anymore. no suitable node (unsupported platform on 3 nodes) on armhf docker cluster

Hello,
I have an armhf cluster and since 17.06 installed, I'm getting this error and my stacks doesn't come up, it stays as pending forever. There's no constraint. This was working perfectly on 17.03.
Inspecting the task, I'm getting:
        "Status": {
            "Timestamp": "2017-07-02T12:51:00.556959128Z",
            "State": "pending",
            "Message": "no suitable node (unsupported platform on 3 nodes)",
            "ContainerStatus": {},
            "PortStatus": {}
        },

docker info:
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 17.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local nfs
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: chzqrk30d8aph7ikg60owdbjz
 Is Manager: true
 ClusterID: 1ucdfzovu4whdawkzv8wbfeb6
 Managers: 3
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Root Rotation In Progress: false
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
  <IP_ADDRESS>:2377
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.34-45
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: armv7l
CPUs: 8
Total Memory: 1.949GiB
Name: odroid01.casaams.wsartori.com
ID: DRWB:PHMO:GCXF:GDTK:QXDF:V2WM:6ZAM:MC5G:GYID:7YOH:PBQC:BOYE
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 registry:5000
 <IP_ADDRESS>/8
Live Restore Enabled: false

probably introduced on https://github.com/docker/swarmkit/commit/8edbb9216533e3ccd41e7e0344227af87d8fd51c by @nishanttotla

@trunet can you show the output for service inspect and also what docker info on the nodes looks like?

docker info is on the first comment.
docker service inspect:
[
    {
        "ID": "n0bhpy9ibyiiv2wkux65x1dsv",
        "Version": {
            "Index": 2286
        },
        "CreatedAt": "2017-07-02T21:13:59.560944718Z",
        "UpdatedAt": "2017-07-02T21:13:59.56740151Z",
        "Spec": {
            "Name": "portal_portal",
            "Labels": {
                "com.docker.stack.image": "arm32v7/httpd:latest",
                "com.docker.stack.namespace": "portal"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "arm32v7/httpd:latest@sha256:90fb0d45f7267ac96523f2030ab842d61c77c65999024b5f67771f599ae4bfa8",
                    "Labels": {
                        "com.docker.stack.namespace": "portal"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/mnt/glusterfs/portal",
                            "Target": "/usr/local/apache2/htdocs"
                        }
                    ],
                    "StopGracePeriod":<PHONE_NUMBER>0,
                    "DNSConfig": {}
                },
                "Resources": {},
                "RestartPolicy": {
                    "Condition": "any",
                    "Delay":<PHONE_NUMBER>,
                    "MaxAttempts": 0
                },
                "Placement": {
                    "Platforms": [
                        {
                            "Architecture": "arm",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "jzho3a68yjsqvakajo7b9yqv3",
                        "Aliases": [
                            "portal"
                        ]
                    }
                ],
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 2
                }
            },
            "UpdateConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor":<PHONE_NUMBER>,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "RollbackConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor":<PHONE_NUMBER>,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "EndpointSpec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 80,
                        "PublishedPort": 80,
                        "PublishMode": "ingress"
                    }
                ]
            }
        },
        "Endpoint": {
            "Spec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 80,
                        "PublishedPort": 80,
                        "PublishMode": "ingress"
                    }
                ]
            },
            "Ports": [
                {
                    "Protocol": "tcp",
                    "TargetPort": 80,
                    "PublishedPort": 80,
                    "PublishMode": "ingress"
                }
            ],
            "VirtualIPs": [
                {
                    "NetworkID": "sposg3gl89sjhlhy1hdpqbwt6",
                    "Addr": "<IP_ADDRESS>/16"
                },
                {
                    "NetworkID": "jzho3a68yjsqvakajo7b9yqv3",
                    "Addr": "<IP_ADDRESS>/24"
                }
            ]
        }
    }
]

I see the issue.
It seems like the node reports
OSType: linux
Architecture: armv7l

but the image reports
OSType: linux
Architecture: arm

and that causes scheduling to fail. We will need to add more normalization for architecture names. I'll do that but it would be useful to have a full list of architecture name variations.
cc @thaJeztah @aaronlehmann currently we only do this for x86_64 and amd64: https://github.com/docker/swarmkit/blob/master/manager/scheduler/filter.go#L288

I can think of aarch64 armv7l, but they are completely different architecture, aarch64 is 64-bits, armv7l is 32-bits.

@nishanttotla Is there a way to build the image with armv7l architecture instead of only arm, I didn't find anything on commit, push on build to add this? how docker hub is handling that, I suppose all https://hub.docker.com/r/arm32v7/ should uses armv7l?

@trunet I'm not sure about that, but we'll see what's the best way to resolve this. Until then, you can get around this issue by using the --no-resolve-image flag which will not add platform information to your service spec.

@nicolaka  as I'm using stack, I didn't find the --no-resolve-image equivalent on compose 3.3 reference.

@nicolaka found it on https://docs.docker.com/engine/reference/commandline/stack_deploy/ thanks man

@trunet apologies, yes for stacks you can use --resolve-image=never for now.

We will need to add more normalization for architecture names.

Is there a list of valid architectures in the image's data? (Same for nodes)?
ARM is specifically tricky, as there's a lot of variations, and ways to express them (armhf, armv6, armv7 etc.)
If there's a list of valid values, we can decide to ignore other values

Related: https://github.com/opencontainers/image-spec/issues/661
@trunet I'm working on figuring out what the right fix is for this case.

@tianon Do you know how Config.Architecture is getting set for images in arm32v7? Are these just using GOARCH directly or is there a special build process?

@stevvooe that'd be GOARCH directly -- the builder for those actually used to be a 64bit build (and thus was setting Architecture to arm64), but I'm now using a 32bit build of Docker on a 64bit machine and using linux32 to ensure the kernel claims it's also 32bit (just to help cut down on the types of things that can go wrong when cross-building like this), so they should all be set to arm (which is as specific as an individual image manifest can get without a manifest list, as you know)
I think way back in Docker's history, someone thought it'd be helpful to include "multiarch" metadata on images, and just threw in GOOS and GOARCH as-is, and it hasn't been adjusted since.  IMO that'd be better served by having a full platform object ala manifest lists, but figured for individual non-multiarch images it really didn't make much difference either way (especially for image-spec's 1.0).

In the manifest list pushing code we've got (which again, as you know, isn't deployed to library/ just yet), arm32v7 turns into something like the following:
platform:
  os: linux
  architecture: arm
  variant: v7

Ah, see https://github.com/moby/moby/pull/3298/commits/f9359f59a88f109a7764406c33529a20098b0c7f for where those fields were first populated with GOARCH (appears it was hard-coded to x86_64 before, and no OS info).

@tianon The problem with GOARCH on images, is that we lose variant when assembling Platform from an image configuration: https://github.com/moby/moby/blob/master/api/server/router/distribution/distribution_routes.go#L120.
For the vast number of cases, I think we can assume variant is v7 but I am sure that will break.

Indeed -- I'm 100% with you on GOARCH being insufficient, which is why I wish individual non-list manifests had a full platform object so that this could be set properly. :disappointed:
To give another example that's completely broken, all the images under i386 will have Architecture set to amd64, since I don't build them on real 32bit hardware (and didn't want to compile a custom Docker binary just to do those builds).  They only exist (in my mind) as a rough sanity check for a simple way to test multiarch (since they can build on any amd64 machine as-is), but their metadata being wrong irks me a lot (it'll be correct when they're included in a manifest list, as seen under trollin, but the individual image metadata will be wrong until/unless we get additional support in Docker itself for informing it what it should be putting there).
It's even conceivable to build s390x images on an amd64 daemon, as long as they don't have any RUN lines (ie, FROM scratch, ADD tarball /, etc), or as long as appropriate qemu bits are in the right places somehow.
Here's a more concrete example:
$ manifest-tool inspect trollin/httpd:latest
Name:   trollin/httpd:latest (Type: application/vnd.docker.distribution.manifest.list.v2+json)
Digest: sha256:6f43aac63ceb4fbfee6a724f3d8aeec4366bb83cd7ef37a9905ccf2256ba8557
 * Contains 6 manifest references:
1    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
1       Digest: sha256:8f58a3ef340038615498cead8b83fa3b31e4fe5c16961c6c3635e973ac9303ed
1  Mfst Length: 1780
1     Platform:
1           -      OS: linux
1           - OS Vers:
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant:
1           - Feature:
1     # Layers: 7
         layer 1: digest = sha256:9f0706ba7422412cd468804fee456786f88bed94bf9aea6dde2a47f770d19d27
         layer 2: digest = sha256:47bacf36113fe830a77280f81a8203a228fa4bb4536f145a333709b9da0f7cf7
         layer 3: digest = sha256:56798d8e5a3081371b84de38415c30c0f1ae034e4d57d82383c468a95521fc53
         layer 4: digest = sha256:94b25413538ac04aa893f729c216553d9c86b0ea69318cfe903e16eb078492b7
         layer 5: digest = sha256:97d879f4e260dd8d46a4eaf0c29f253a501fa82337840c30a6274de23227ab6e
         layer 6: digest = sha256:2a4f7e960a3e3b32308101dec9c1525b961a242dca799737d2ad0c3e19350b42
         layer 7: digest = sha256:12f5eb5312902eedee33d3b8d0f2abc7750f3ae7e32733b26547371f8eb6b034

2    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
2       Digest: sha256:90fb0d45f7267ac96523f2030ab842d61c77c65999024b5f67771f599ae4bfa8
2  Mfst Length: 1780
2     Platform:
2           -      OS: linux
2           - OS Vers:
2           - OS Feat: []
2           -    Arch: arm
2           - Variant: v7
2           - Feature:
2     # Layers: 7
         layer 1: digest = sha256:72c70f9f7d679945bc71d954dc0c7de236e0067af495d09e9bea24f497cc79b7
         layer 2: digest = sha256:c3529be5f104abaa0a6777ce5aa3d62a14d637886a4eebc1fc8ed730c4009654
         layer 3: digest = sha256:d8da62524d5de9ecb71f0046c66d3a291e6b2f81496a07d28e30b4e81f04ac51
         layer 4: digest = sha256:7d7da9871d55dac5ea74a2b5f684f5c94bb5ca9b51ff5f2a81330facfcf67122
         layer 5: digest = sha256:c2c771d498cd865c5dff06aa02340b0c859cebcbe6a88246c7e87e287ab70c48
         layer 6: digest = sha256:de5a89172d87cbecee5e7924eb3c003458ad751d51e25eaed5d8a89912ef3ccb
         layer 7: digest = sha256:a922909dfad204174854c24774fc54c9016d96d587480b6d40c0c56ae73612a7

3    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
3       Digest: sha256:21920abf229fd278a820287cb8fbe9db206ecbbb4b5bd8a34aab0af8b9c0f470
3  Mfst Length: 1780
3     Platform:
3           -      OS: linux
3           - OS Vers:
3           - OS Feat: []
3           -    Arch: arm64
3           - Variant: v8
3           - Feature:
3     # Layers: 7
         layer 1: digest = sha256:0dcb325d306f51780dbde5818f38ed8b0e8f478b56132f46bb5c30385f86eaa6
         layer 2: digest = sha256:0a2d58b6ee283f9f76e8f06d3fac65e85b9e289df29ca44dc9314586e055cecc
         layer 3: digest = sha256:eac331a2af3233030fcf1ad5300f9684767ebc08b8447e52b00783cb43de360a
         layer 4: digest = sha256:b382ea768f87d2a04cac208183cd6ee2b487748fb7fe33a9f0e6c4ab0912a029
         layer 5: digest = sha256:313fc6a3542b845ea9d51e727b1b0270de45d71e58a4cbd5e68c427761ce8107
         layer 6: digest = sha256:1a9a6cd7e8894b6345a3d83a4cefba76609c8e096d5163a67c0dee33c7927ffb
         layer 7: digest = sha256:26af40e76c32da3f9b7eac5f62d73ee6d51c30f0b257e37596da4bcbb7e34877

4    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
4       Digest: sha256:261d6c4753982e203308fc5c637a74bdcd986a2edbab7d8aac39a391cae7a683
4  Mfst Length: 1780
4     Platform:
4           -      OS: linux
4           - OS Vers:
4           - OS Feat: []
4           -    Arch: 386
4           - Variant:
4           - Feature:
4     # Layers: 7
         layer 1: digest = sha256:2fa359c89a0e952ec2fe14e3c584ee13d6ec919c73a7dcac34ba320a459e2a62
         layer 2: digest = sha256:19378a3c2be7bef3f223e1ca4a0391c966e6330d8692ed17042471f25509713b
         layer 3: digest = sha256:9e17073700efe44252f1c00a14cf28030458d929d0de85f4873189e23b218530
         layer 4: digest = sha256:38c6ce3cfa9a4835b70425932f1da52dc06e8416369192b5b2fd0768956b907d
         layer 5: digest = sha256:23815ae9a9b769433bf361d90f0654af265d56f7792633aaae368cc17d8af505
         layer 6: digest = sha256:7951cc644f4c9b2aa30c2a8653ce4d2b7ac8390fb72dab2e6f5d3f522bbe738d
         layer 7: digest = sha256:381d02ad82455287029be0a8cf1a1cae9915c26289bac3c24ed7636ba77c6795

5    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
5       Digest: sha256:343ea34611a882700bf162ad929c42259446088d9933991addc64bc90af8f17e
5  Mfst Length: 1780
5     Platform:
5           -      OS: linux
5           - OS Vers:
5           - OS Feat: []
5           -    Arch: ppc64le
5           - Variant:
5           - Feature:
5     # Layers: 7
         layer 1: digest = sha256:a5561821dba4ceb47be1d2f5f108a24b391df9d6a3a764d2c04ea8ac29410625
         layer 2: digest = sha256:39c4390b614987e9576d36928eb4d12a6d5e160fb83b5095198efd400b6b8c5b
         layer 3: digest = sha256:d14c381984db757a959e0f35eb170b4863f5c5e8570702bb7529f4f88998f73a
         layer 4: digest = sha256:90d23acf5ff39880a4a787a1d41e6bc4b204a7e01fc2e60183892c20aa60c5c4
         layer 5: digest = sha256:77e6d79cd73f74c4071006e03344deccab113906c139d8755461d4fd72604b1e
         layer 6: digest = sha256:e3649c2d25a8bf9910fe5f9f940924ef00277ca9a003c5fcaaeb487f116def62
         layer 7: digest = sha256:67e875c10908fb1f66c807700e155e51ccc053f596e93f0d0f1aff26240aa46f

6    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
6       Digest: sha256:3c121d29d5f0c2bb4fdc54fa2e206bb9d6a4b751e29de571b4ef5af7b80c20f6
6  Mfst Length: 1780
6     Platform:
6           -      OS: linux
6           - OS Vers:
6           - OS Feat: []
6           -    Arch: s390x
6           - Variant:
6           - Feature:
6     # Layers: 7
         layer 1: digest = sha256:29420dd727d39cbedfb85562111f49e24b0b96adda04de4663d2099fbbf4f993
         layer 2: digest = sha256:0eb60e029192948c200dc12526bcb19c36747de3cedae3822c3009d6250b95b9
         layer 3: digest = sha256:f2cee80bd07440bd13eb077947699252cbfba9b263af2a43bd94f31378a5c35c
         layer 4: digest = sha256:b628a0b163be3123753102d5269918189e0ff4f2cecc25b8ebb685a7e292435e
         layer 5: digest = sha256:9c67f623c538f560836daac0ea7ab1ffa883c09b87ae7b426fed7e4b828e466b
         layer 6: digest = sha256:0bf51bf880e17e555e66c3af906cd603deae0af6095d1816ffb364b9d16e426d
         layer 7: digest = sha256:16c1cb76b65df18dfffd6e1f23e843c3ddebd950f5e8ea24fd98be6c8b5997ad

(which was built by combining amd64/httpd:latest, arm32v7/httpd:latest, etc)
The info for busybox:latest is likely even better, since it'll have several arm variants:
$ manifest-tool inspect trollin/busybox:latest | grep -A7 'Platform:'
1     Platform:
1           -      OS: linux
1           - OS Vers:
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant:
1           - Feature:
1     # Layers: 1
--
2     Platform:
2           -      OS: linux
2           - OS Vers:
2           - OS Feat: []
2           -    Arch: arm
2           - Variant: v5
2           - Feature:
2     # Layers: 1
--
3     Platform:
3           -      OS: linux
3           - OS Vers:
3           - OS Feat: []
3           -    Arch: arm
3           - Variant: v6
3           - Feature:
3     # Layers: 1
--
4     Platform:
4           -      OS: linux
4           - OS Vers:
4           - OS Feat: []
4           -    Arch: arm
4           - Variant: v7
4           - Feature:
4     # Layers: 1
--
5     Platform:
5           -      OS: linux
5           - OS Vers:
5           - OS Feat: []
5           -    Arch: arm64
5           - Variant: v8
5           - Feature:
5     # Layers: 1
--
6     Platform:
6           -      OS: linux
6           - OS Vers:
6           - OS Feat: []
6           -    Arch: 386
6           - Variant:
6           - Feature:
6     # Layers: 1
--
7     Platform:
7           -      OS: linux
7           - OS Vers:
7           - OS Feat: []
7           -    Arch: ppc64le
7           - Variant:
7           - Feature:
7     # Layers: 1
--
8     Platform:
8           -      OS: linux
8           - OS Vers:
8           - OS Feat: []
8           -    Arch: s390x
8           - Variant:
8           - Feature:
8     # Layers: 1

For building the individual architecture images, I'm not doing anything special or custom beyond docker build, docker tag, docker push.

Indeed -- I'm 100% with you on GOARCH being insufficient

For arm, I should have qualified. All other architectures have sufficient information.
We'll either need this on the manifest or all the way down on the config (not sure if we really want to take that on). Seems, as is, there is no way to resolve the arm properties from the config itself and that the contents of Config.Architecture is generally dubious (at least for cross-builds).
Do we need to file a bug with OCI image-spec?

@tianon ^
As far as a solution, I think we should remove the automatic constraint on architecture unless reporting on a multi-platform image. That will allow swarm to meet the image matching use case for windows/linux.

I think that makes sense, especially since if it's not a manifest list, the notion of it being "multiarch" is kind of bogus anyhow (since the arch information is likely also bogus, or at least misleading).  The OS field might be accurate, but it's hard to say in that case.  These architecture constraints can be directly added by hand, right?
As for filing a bug with the image-spec, I think that makes sense, but I didn't want to try and rock that boat pre-1.0 (since as shown by the commit I linked, it's a real old boat), and hadn't looked to see whether the image config itself was covered by the spec (but it makes sense for it to be). :innocent:

(I have to confess that I haven't tried building FROM scratch on Windows to see if I could cross-build a Linux image that way. :sweat_smile:)

@tianon The image config is covered by the spec, unfortunately. For the cases where cross builds are happening, the image will have to be modified post-build. In the case where we just want to route a workload a host that can run that image, we likely don't have enough information, as that will have to be wrapped in a manifest list (index) to provide the actual platform information in the ARM case.

I ran into the same issue today. I run a manager on amd64 and have a node which is armv6l. It's a raspberrypi model b+. I can run the image on the node itself, but when I want to run it as a swarm service it says:
"Message": "no suitable node (unsupported platform on 4 nodes)"
Btw. I also have two amd64 nodes.
It seems it can't map the arm image on armv6l in the swarm scheduler.

The Scaleway C1 machine shows armv7l, as well as Raspberry Pi 2/3
Raspberry Pi 0/1 show armv6l
Docker images have arm as architecture.
So probably the platformEqual() should have the same normalization as for x86_64 -> amd64:
	switch imgPlatform.Architecture {
	case "x86_64":
		imgPlatform.Architecture = "amd64"
	case "armv6l", "armv7l":
		imgPlatform.Architecture = "arm"
	case "aarch64":
		imgPlatform.Architecture = "arm64"
	}
	switch nodePlatform.Architecture {
	case "x86_64":
		nodePlatform.Architecture = "amd64"
	case "armv6l", "armv7l":
		nodePlatform.Architecture = "arm"
	case "aarch64":
		nodePlatform.Architecture = "arm64"
	}

Something like this?

@nishanttotla any ideas to my comment https://github.com/docker/swarmkit/issues/2294#issuecomment-313954317 to fix platformEqual() for ARM introduced in #2180?
Is this approach a good idea that will get merged having some tests for it?
I have never built swarmkit on RPi/Scaleway to have a dev environment for it, so I ask in advance :-)

@StefanScherer while your suggestion might solve this problem, it might not be the right place to fix it, especially with the large number of arm variants. There is a Docker PR to fix this until we can fix the root cause: https://github.com/moby/moby/pull/34021

@nishanttotla what is the likelihood of that Moby issue being part of the 17.07 release?
If Docker CE ships this way then Swarm and stacks are completely broken for RPi. It would be better not to ship ARM binaries than degrade the experience of anyone who upgrades. It's the issue tracker and community that will be having to explain why it's broken and any work-arounds.

@alexellis I agree. This is not a good situation and I am worried that having these constraints will create mutual incompatibilities.
Could you see if moby/moby#34021 will work?

I have all nodes with Platform: linux armv7l and have to use --no-resolve-image, otherwise swarm services are in constant pending state.
Docker: 17.06.1-ce

@stevvooe the PR by @nishanttotla fixes the issue - I've spent the whole day testing it...  And I had to recreate all services with just docker service create command :(

Just take this PR it fixes everything.

Closing since https://github.com/moby/moby/pull/34021 was merged. A longer term resolution of ARM variants will take time, but it is no longer the case that tasks don't run, so we can consider this issue resolved.

Same problem on 17.09, have to rollback on 17.06

@MLescaudron this should be fixed now. Can you share the output of docker info on one of your worker nodes that has ARM, and the output of docker service inspect <service name> for the service that fails to run?

Docker info (previously I was in 17.09.2-ce)
Containers: 21
 Running: 11
 Paused: 0
 Stopped: 10
Images: 14
Server Version: 17.06.2-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: vjh2cujrci6sjus9lyhjm87po
 Is Manager: true
 ClusterID: b70lb8nciap52uncs76xnfkfl
 Managers: 1
 Nodes: 4
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Root Rotation In Progress: false
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-81-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 14.34GiB
Name: ovh-prod-1
ID: TXNV:VBKT:MFJD:4K7W:G3JH:WDB7:LZZF:3SWD:LVQO:6SFP:WOPE:AN7E
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: nelioapp
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

WARNING: No swap limit support

docker service inspect
[
    {
        "ID": "0rvq0tmowj9nfn2gjgp0hzmyd",
        "Version": {
            "Index": 69574
        },
        "CreatedAt": "2017-09-26T22:31:04.605418562Z",
        "UpdatedAt": "2017-10-02T22:13:46.09779364Z",
        "Spec": {
            "Name": "tech_blog",
            "Labels": {
                "com.docker.stack.image": "ghost:alpine",
                "com.docker.stack.namespace": "tech"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "ghost:alpine@sha256:b7c4fcb9e78518ea85fcba80969f445301b38f76833a6668eb268da7b6e7f3a4",
                    "Labels": {
                        "com.docker.stack.namespace": "tech"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/home/nelio/tech.nelio.io/",
                            "Target": "/var/lib/ghost/content"
                        }
                    ],
                    "StopGracePeriod":<PHONE_NUMBER>0,
                    "DNSConfig": {}
                },
                "Resources": {},
                "RestartPolicy": {
                    "Condition": "any",
                    "Delay":<PHONE_NUMBER>,
                    "MaxAttempts": 0
                },
                "Placement": {
                    "Constraints": [
                        "node.role == manager"
                    ],
                    "Platforms": [
                        {
                            "Architecture": "amd64",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "omgpnj44fbx9y7khp6pxmptq7",
                        "Aliases": [
                            "blog"
                        ]
                    }
                ],
                "LogDriver": {
                    "Options": {
                        "max-size": "50m"
                    }
                },
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 1
                }
            },
            "UpdateConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor":<PHONE_NUMBER>,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "RollbackConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor":<PHONE_NUMBER>,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "EndpointSpec": {
                "Mode": "vip"
            }
        },
        "PreviousSpec": {
            "Name": "tech_blog",
            "Labels": {
                "com.docker.stack.image": "ghost:alpine",
                "com.docker.stack.namespace": "tech"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "ghost:alpine@sha256:b7c4fcb9e78518ea85fcba80969f445301b38f76833a6668eb268da7b6e7f3a4",
                    "Labels": {
                        "com.docker.stack.namespace": "tech"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/home/nelio/tech.nelio.io/",
                            "Target": "/var/lib/ghost/content"
                        }
                    ]
                },
                "Resources": {},
                "Placement": {
                    "Constraints": [
                        "node.role == manager"
                    ],
                    "Platforms": [
                        {
                            "Architecture": "amd64",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "omgpnj44fbx9y7khp6pxmptq7",
                        "Aliases": [
                            "blog"
                        ]
                    }
                ],
                "LogDriver": {
                    "Options": {
                        "max-size": "50m"
                    }
                },
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 1
                }
            },
            "EndpointSpec": {
                "Mode": "vip"
            }
        },
        "Endpoint": {
            "Spec": {
                "Mode": "vip"
            },
            "VirtualIPs": [
                {
                    "NetworkID": "omgpnj44fbx9y7khp6pxmptq7",
                    "Addr": "<IP_ADDRESS>/24"
                }
            ]
        }
    }
]

@MLescaudron your node reports linux/x86_64 and your service placement constraints report linux/amd64. This is a compatible combination, and your service should run. There maybe another reason why it's failing.

Ok, so I have unistall and reinstall docker-ce on each node.
When I launch a service, docker ps return an empty response and the state is on pending mode.
Same problem as @trunet

Same here with 17.09
Docker info: linux aarch64
Docker inspect task: linux arm64
Docker inspect container: linux arm64
Task status: "State": "pending", "Message": "unsupported platform on 1 node"

It seems that #34021 should have excluded more cases in addition to just "arm", like "arm64".
cc @thaJeztah @andrewhsu

This appears to be broken again on ARM64 :-( in particular I have a weird situation where it will work on Dieter's ARM64 RPi image but not on Packet's Qualcomm machine - both are "aarch64" in uname.
Packet:
docker service create --name func_prometheus  luxas/prometheus-arm64:v1.5.2
root@48-cores:~# uname -a
Linux 48-cores 4.10.0-19-generic #21ubuntu+caf.3-Ubuntu SMP Wed May 3 19:00:13 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root@48-cores:~# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                           PORTS
8gv14xs5r0dk        func_prometheus     replicated          0/1                 luxas/prometheus-arm64:v1.5.2
root@48-cores:~# docker run -ti luxas/prometheus-arm64:v1.5.2
INFO[0001] Starting prometheus (version=1.5.2, branch=master, revision=bd1182d29f462c39544f94cc822830e1c64cf55b)  source=main.go:75
INFO[0001] Build context (go=go1.7.5, user=root@a8af9200f95d, date=20170210-15:09:12)  source=main.go:76
INFO[0001] Loading configuration file /etc/prometheus/prometheus.yml  source=main.go:248
INFO[0001] Loading series map and head chunks...         source=storage.go:373

root@48-cores:~# docker service create --name func_prometheus  luxas/prometheus-arm64:v1.5.2
DEBU[2017-10-09T20:36:21.741818950Z] Calling GET /_ping
DEBU[2017-10-09T20:36:21.742930000Z] Calling GET /_ping
DEBU[2017-10-09T20:36:21.746669250Z] Calling GET /v1.32/distribution/luxas/prometheus-arm64:v1.5.2/json
DEBU[2017-10-09T20:36:22.147220750Z] Calling POST /v1.32/services/create
DEBU[2017-10-09T20:36:22.147412700Z] form data: {"EndpointSpec":{"Mode":"vip"},"Labels":{},"Mode":{"Replicated":{}},"Name":"func_prometheus","TaskTemplate":{"ContainerSpec":{"DNSConfig":{},"Image":"luxas/prometheus-arm64:v1.5.2@sha256:7011cf4a94d350cc6719b7a87eaa2cd7cbcc19bcfcf081eae4b9b6ae5f9e00d0"},"ForceUpdate":0,"Placement":{"Platforms":[{"Architecture":"amd64","OS":"linux"}]},"Resources":{"Limits":{},"Reservations":{}}}}
DEBU[2017-10-09T20:36:22.161471000Z] Service hzxpjiytu97jfz931oduom8o8 was scaled up from 0 to 1 instances  module=node node.id=xl2vxso5gh504rosy2u9nyqkc
hzxpjiytu97jfz931oduom8o8
Since --detach=false was not specified, tasks will be created in the background.
In a future release, --detach=false will become the default.
root@48-cores:~# DEBU[2017-10-09T20:36:22.246894100Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=yj0vos4kyogoklebm3dvw50xb
DEBU[2017-10-09T20:36:22.246938550Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=syppv5tnsr77hzst6tahy0imq
DEBU[2017-10-09T20:36:22.336576750Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=syppv5tnsr77hzst6tahy0imq
DEBU[2017-10-09T20:36:22.336625100Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=yj0vos4kyogoklebm3dvw50xb

DEBU[2017-10-09T20:36:36.378193650Z] Calling GET /v1.32/version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:10 2017
 OS/Arch:      linux/arm64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:38:22 2017
 OS/Arch:      linux/arm64
 Experimental: false```

@alexellis Looking at the patch that should have fixed this, it seems like this case is not covered. Although, it seems like the placement constraint clearly reads amd64, from the log message.

OK, there's something funny going on here.
ed$ docker run --rm mplatform/mquery luxas/prometheus-arm64:v1.5.2
Manifest List: No
 Supports: amd64/linux

It looks like @luxas has a prometheus-arm64 image that advertises that it supports amd64/linux.

Looking at the configuration, the architecture is reported as amd64:
$ ctr fetch-object docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126 | jq .
INFO[0000] resolving                                     ref="docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126"
INFO[0001] fetching                                      ref="docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126"
{
  "architecture": "amd64",
...

Were these "cross-built" binaries?

Looks like @luxas has a multiarch image, cf
ed$ docker run --rm mplatform/mquery luxas/prometheus:v2.0.0-rc.0
Manifest List: Yes
Supported platforms:
 - amd64/linux
 - arm/linux (variant: undefined)
 - arm64/linux (variant: undefined)

also
ed$ docker run --rm mplatform/mquery luxas/prometheus:v1.7.1
Manifest List: Yes
Supported platforms:
 - amd64/linux
 - arm/linux (variant: undefined)
 - arm64/linux (variant: undefined)

@vielmetti @stevvooe Yes, I'm crossbuilding everything. That's by far the best way to do things IMO. Don't know if docker lets me set the os/arch (I don't think so?)

@luxas Cross-building won't work unless you re-pack into manifest list or re-write the configuration with the correct architecture.
@vielmetti There is no variant field in the base image config, so it won't be defined. We can add one there if this is a huge problem.

@luxas Cross-building won't work unless you re-pack into manifest list or re-write the configuration with the correct architecture.

@stevvooe Can you point to docs how to mutate OS/arch for a given (non-manifest-list) image? e.g. for luxas/prometheus-arm64

This patch https://github.com/docker/swarmkit/pull/2411 addresses the issue.


Cannot log in to microsoft/mssql-server-linux running in a container

When trying to log into a "microsoft/mssql-server-linux" container running on Ubuntu.  I have tried this on two different machines: one running Ubuntu 16.04 and one running 18.04.
The behavior is identical on both.
From the Sql Server log:
   Login failed for user 'sa'. Reason: An error occurred while evaluating the password.
This happens when I try to run 'sqlcmd' locally on the Ubuntu machine, or remotely from a Windows 10 machine using SQL Server Management Studio.  I get the same error in each case.
The command used to start the SQL Server container is:
sudo docker run -d --name sql -p 1433:1433 -e sa_password=Password1234! -e ACCEPT_EULA=Y microsoft/mssql-server-linux
I have tried several different flavors of encapsulating the password.  With no quotes and with double quotes around the password as:
    "sa_password=Password1234!"
    sa_password="Password1234!"
    sa_password=Password1234!

Same result in all cases.  I have tried several different passwords.
I realize that similar issues have been presented and I apologize for repeating an apparently old issue, however, I have tried to implement the ideas in those other issues with no success.  Although new to Docker, I am not new to SQL Server.

This is likely because you are using sa_password as the env var name instead of SA_PASSWORD.  Linux is case sensitive.  :)


Tasks don't run inside newly created project folder

Describe the problem
I create a project, then I want a task to cd into the newly created projects and do things, such as git init, pnpm install.
Instead those commands run in the folder where I originally called copier. Using cd doesn't help, unless I prepend each individual command with it
_tasks:
  - "echo '1:' && pwd"
  - "cd /put/it/{{project_name}}"
  - "echo '2:' && pwd"
  - "cd /put/it/{{project_name}} && echo '3:' && pwd"

where project_name = 'there'
> cd i/am/here
> copier mytemplate/ put/it/
> Running task 1 of 4: echo '1:' && pwd
1:
 i/am/here
 > Running task 2 of 4: cd put/it/there
 > Running task 3 of 4: echo '2:' && pwd
2:
 i/am/here
 > Running task 4 of 4: cd there && echo '3:' && pwd
3:
/put/it/there

Template
see ☝
To Reproduce

see ☝
Logs
it doesn't error, it just does the wrong thing
Environment

OS: X
Copier version: copier 7.0.1
Python version: 3.11.1
Installation method: pip +pypi

I cannot reproduce the problem on Ubuntu 20.04 with the same Copier and Python versions you've stated, it works as expected for me. This behavior is also tested and the last change to this test file was before the release of v7.0.1:
https://github.com/copier-org/copier/blob/91966047d9741099b4925612c5c0c3a0dbe2490c/tests/test_tasks.py#L23-L27
https://github.com/copier-org/copier/blob/91966047d9741099b4925612c5c0c3a0dbe2490c/tests/test_tasks.py#L34-L36
https://github.com/copier-org/copier/blob/91966047d9741099b4925612c5c0c3a0dbe2490c/tests/test_tasks.py#L39-L45
I've also tried it with Copier v7.1.0a0 and v6.2.0 and both work fine. Can you double-check please?

I also tested it with current master and I cannot reproduce. As @sisp said, this is a tested case. There must be something else that makes it fail. Closing.


Incorrect UDF volume label

*_volDesc.txt currently shows the Volume Labels (Identifiers) from ISO9660 and Joliet filesystems.
It would be useful if DIC output the Volume Labels from other filesystems, such as UDF, HFS, High Sierra, Rock Ridge, etc
Example: A disc with both ISO and UDF partitions (e.g. http://redump.org/disc/77006/) shows up in Windows with the UDF volume label. However this volume label is not mentioned anywhere in DIC logs/output. However, the UDF label in the DIC logs is incorrect.

It would be useful if DIC output the Volume Labels from other filesystems, such as UDF, HFS, High Sierra, Rock Ridge, etc

I dumped a DVD and confirmed the volume label.
========== LBA[000016, 0x00010]: Volume Descriptor ==========
	                       Volume Descriptor Type: 1
	                          Standard Identifier: CD001
	                    Volume Descriptor Version: 1
	                            System Identifier:
	                            Volume Identifier: DVD_VIDEO

UDF
========== LBA[000032, 0x00020]: Primary Volume Descriptor ==========
	Descriptor Tag
		Tag Identifier: 1
		Descriptor Version: 2
		Tag Checksum: 222
		Tag Serial Number: 0
		Descriptor CRC: 2aa0
		Descriptor CRC Length: 496
		Tag Location: 32
	Volume Descriptor Sequence Number: 0
	Primary Volume Descriptor Number: 0
	Volume Identifier: DVD_VIDEO

Example: A disc with both ISO and UDF partitions (e.g. http://redump.org/disc/77006/) shows up in Windows with the UDF volume label. However this volume label is not mentioned anywhere in DIC logs/output.

Could you upload logs?

Ah, I see, UDF volume information is here:
========== LBA[000032, 0x00020]: Primary Volume Descriptor ==========
	Descriptor Tag
		Tag Identifier: 1
		Descriptor Version: 2
		Tag Checksum: 209
		Tag Serial Number: 1
		Descriptor CRC: 7b41
		Descriptor CRC Length: 496
		Tag Location: 32
	Volume Descriptor Sequence Number: 0
	Primary Volume Descriptor Number: 0
	Volume Identifier:

Logs are not mine, but this is the example I used to look for the label:
UDF Example.zip
Unfortunately the Label is just "" which is not the label that Windows sees when it mounts the disc.

I have confirmed with ISOBuster that the disc with logs above has ISO9660 label "BRUTAL" and UDF label "brutal".
DIC, meanwhile, just outputs the non-printable character  (ASCII 0x10, DLE) as the UDF volume identifier

fixed UDF log
DiscImageCreator_test.zip


Nuxt usage exemple

Is your feature request related to a problem? Please describe.
Currently, when using the Vue exemple in a Nuxt project, I get this error:

Hydration class mismatch on
…

rendered on server: class="jos jos-grow"
expected on client: class="jos"
Note: this mismatch is check-only. The DOM will not be rectified in production due to performance overhead.

I don't understand why it says the server render jos jos-grow since clearly I created a client-only plugin jos-animation.client.js:
import JOS from "jos-animation";

export default defineNuxtPlugin(() => {
    console.log('client', process.client)
    console.log('server', process.server)
    JOS.init({
        animation: "grow",
        duration: 0.4,
        rootMargin: "10% 0% 40% 0%",
        debugMode: true,
    });
});

Describe the solution you'd like
It would be nice to have a Nuxt exemple, since there is a Next exemple.
Describe alternatives you've considered
I made a custom plugin, and I was able to bypass the virtual DOM error.
But I'm not 100% sure this is correct:
// plugins/jos-animation.client.js
import JOS from 'jos-animation/dist/jos.js';

export default defineNuxtPlugin((nuxtApp) => {
    const router = useRouter();
    JOS.init({
        passive: true,
        animation: 'fade',
        duration: 0.4,
        rootMargin: '20% 0% 30% 0%',
    });
    nuxtApp.vueApp.directive('jos', {
        mounted(el) {
            el.classList.add('jos');
            JOS.refresh();
        },
    });
    watch(
        () => router.currentRoute.value,
        () => {
            nextTick(() => {
                JOS.refresh();
            });
        }
    );
});

// plugins/jos-animation.server.js
export default defineNuxtPlugin((nuxtApp) => {
    nuxtApp.vueApp.directive('jos', {});
});

// pages/index.vue

      ...

Hey @mrleblanc101, sorry for the late reply.. I'm looking into this rn

Hello @mrleblanc101,

This snippet alone seems to work with Nuxt.js, very similar to how it works in Vue3.js.
About Hyderation class mismatch, you might have to force hard-refresh the site or restart the dev server...

Yeah I've put this code in a Client plugin so it run on every page but I get hydration errors. Which is odd since it runs only on the client side. If I wrap my div using class="jos" in a <ClientOnly> it fix the hydration error, but now the init won't work because the div is not mounted and nextTick() won't suffice. So I added a 100ms timeout, but that's incredibly ugly.


Use daemon-free Buildah instead of Docker to generate OCI containers

The only reason for me to switch from the classic container pipeline to this dependency would be if it would offer an optional Buildah backend option. Currently I would need to install Docker just to use this plugin.
Currently I switched to podman which uses Buildah underneath to build OCI containers.

Hi @loxal,

Currently I would need to install Docker just to use this plugin.

Note Jib doesn't use Docker for building containers. You can still use Jib without Docker if you push an image directly to a registry.
For now, a workaround is use jib:buildTar and then load the tarball to Buildah yourself. That said, what's the exact Buildah command to load and save an OCI/Docker image tarball?

If it does not depend on Docker nor Buildah, it might be even more appealing. I'll take a closer look as I want to get rid of Docker & its daemon altogether.
Can't help you with your question though.

Closing as a non-issue. Jib doesn't depend on Docker.


Build of VSF fails for some people due to lack of dependencies in the container

Current behavior
VSF fails during yarn install for some people due to lack of python2, g++ and make.
The task falls on node-sass, due to the fact that it uses node-gyp underneath in order to compile some packages.
Expected behavior
yarn install should pass in the container
Steps to reproduce the issue
The issue is nondeterministic and affects only some people. It always happens during yarn install however
Repository
Core
Can you handle fixing this bug by yourself?

[X] YES
[ ] NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[ ] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[X] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: N/A
OS: Confirmed for Ubuntu 18.04 and Windows 10
Node: Confirmed for: 8.16.10 and 10.16.0
Code Version: Confirmed for: Develop 1.9 - 1.10 and stable 1.9

Additional information

Logs of failing node-sass in case of python 2.7 issue:
frontend_1       | [5/5] Building fresh packages...
frontend_1       | error /var/www/node_modules/node-sass: Command failed.
frontend_1       | Exit code: 1
frontend_1       | Command: node scripts/build.js
frontend_1       | Arguments:
frontend_1       | Directory: /var/www/node_modules/node-sass
frontend_1       | Output:
frontend_1       | Building: /usr/local/bin/node /var/www/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
frontend_1       | gyp info it worked if it ends with ok
frontend_1       | gyp verb cli [ '/usr/local/bin/node',
frontend_1       | gyp verb cli   '/var/www/node_modules/node-gyp/bin/node-gyp.js',
frontend_1       | gyp verb cli   'rebuild',
frontend_1       | gyp verb cli   '--verbose',
frontend_1       | gyp verb cli   '--libsass_ext=',
frontend_1       | gyp verb cli   '--libsass_cflags=',
frontend_1       | gyp verb cli   '--libsass_ldflags=',
frontend_1       | gyp verb cli   '--libsass_library=' ]
frontend_1       | gyp info using<EMAIL_ADDRESS>frontend_1       | gyp info using<EMAIL_ADDRESS>| linux | x64
frontend_1       | gyp verb command rebuild []
frontend_1       | gyp verb command clean []
frontend_1       | gyp verb clean removing "build" directory
frontend_1       | gyp verb command configure []
frontend_1       | gyp verb check python checking for Python executable "python2" in the PATH
frontend_1       | gyp verb `which` failed Error: not found: python2
frontend_1       | gyp verb `which` failed     at getNotFoundError (/var/www/node_modules/which/which.js:13:12)
frontend_1       | gyp verb `which` failed     at F (/var/www/node_modules/which/which.js:68:19)
frontend_1       | gyp verb `which` failed     at E (/var/www/node_modules/which/which.js:80:29)
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/which/which.js:89:16
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/index.js:42:5
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/mode.js:8:5
frontend_1       | gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:152:21)
frontend_1       | gyp verb `which` failed  python2 { Error: not found: python2
frontend_1       | gyp verb `which` failed     at getNotFoundError (/var/www/node_modules/which/which.js:13:12)
frontend_1       | gyp verb `which` failed     at F (/var/www/node_modules/which/which.js:68:19)
frontend_1       | gyp verb `which` failed     at E (/var/www/node_modules/which/which.js:80:29)
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/which/which.js:89:16
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/index.js:42:5
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/mode.js:8:5
frontend_1       | gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:152:21)
frontend_1       | gyp verb `which` failed   stack: 'Error: not found: python2\n    at getNotFoundError (/var/www/node_modules/which/which.js:13:12)\n    at F (/var/www/node_modules/which/which.js:68:19)\n    at E (/var/www/node_modules/which/which.js:80:29)\n    at /var/www/node_modules/which/which.js:89:16\n    at /var/www/node_modules/isexe/index.js:42:5\n    at /var/www/node_modules/isexe/mode.js:8:5\n    at FSReqWrap.oncomplete (fs.js:152:21)',
frontend_1       | gyp verb `which` failed   code: 'ENOENT' }
frontend_1       | gyp verb check python checking for Python executable "python" in the PATH
frontend_1       | gyp verb `which` failed Error: not found: python
frontend_1       | gyp verb `which` failed     at getNotFoundError (/var/www/node_modules/which/which.js:13:12)
frontend_1       | gyp verb `which` failed     at F (/var/www/node_modules/which/which.js:68:19)
frontend_1       | gyp verb `which` failed     at E (/var/www/node_modules/which/which.js:80:29)
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/which/which.js:89:16
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/index.js:42:5
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/mode.js:8:5
frontend_1       | gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:152:21)
frontend_1       | gyp verb `which` failed  python { Error: not found: python
frontend_1       | gyp verb `which` failed     at getNotFoundError (/var/www/node_modules/which/which.js:13:12)
frontend_1       | gyp verb `which` failed     at F (/var/www/node_modules/which/which.js:68:19)
frontend_1       | gyp verb `which` failed     at E (/var/www/node_modules/which/which.js:80:29)
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/which/which.js:89:16
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/index.js:42:5
frontend_1       | gyp verb `which` failed     at /var/www/node_modules/isexe/mode.js:8:5
frontend_1       | gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:152:21)
frontend_1       | gyp verb `which` failed   stack: 'Error: not found: python\n    at getNotFoundError (/var/www/node_modules/which/which.js:13:12)\n    at F (/var/www/node_modules/which/which.js:68:19)\n    at E (/var/www/node_modules/which/which.js:80:29)\n    at /var/www/node_modules/which/which.js:89:16\n    at /var/www/node_modules/isexe/index.js:42:5\n    at /var/www/node_modules/isexe/mode.js:8:5\n    at FSReqWrap.oncomplete (fs.js:152:21)',
frontend_1       | gyp verb `which` failed   code: 'ENOENT' }
frontend_1       | gyp ERR! configure error
frontend_1       | gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
frontend_1       | gyp ERR! stack     at PythonFinder.failNoPython (/var/www/node_modules/node-gyp/lib/configure.js:484:19)
frontend_1       | gyp ERR! stack     at PythonFinder.<anonymous> (/var/www/node_modules/node-gyp/lib/configure.js:406:16)
frontend_1       | gyp ERR! stack     at F (/var/www/node_modules/which/which.js:68:16)
frontend_1       | gyp ERR! stack     at E (/var/www/node_modules/which/which.js:80:29)
frontend_1       | gyp ERR! stack     at /var/www/node_modules/which/which.js:89:16
frontend_1       | gyp ERR! stack     at /var/www/node_modules/isexe/index.js:42:5
frontend_1       | gyp ERR! stack     at /var/www/node_modules/isexe/mode.js:8:5
frontend_1       | gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:152:21)
frontend_1       | gyp ERR! System Linux 4.15.0-58-generic
frontend_1       | gyp ERR! command "/usr/local/bin/node" "/var/www/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
frontend_1       | gyp ERR! cwd /var/www/node_modules/node-sass
frontend_1       | gyp ERR! node -v v8.16.0
frontend_1       | gyp ERR! node-gyp -v v3.8.0
frontend_1       | gyp ERR! not ok
frontend_1       | Build failed with error code: 1
frontend_1       | info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Good point! Can you prepare a PR with a fix please?

I'm not a fan of adding g++ and python to package.json requirements as it can open some potential security holes in case of production deployments using our docker files. maybe we should just put a note on that to our docs - FAQ section?

@kkdg can you please take care of it - adding a note on this to FAQ?

@pkarw Sure thing, Let me dig it further and update the docs accordingly. Thanks!

Just to make sure, @michaelKurowski Did you use docker? or legacy mode? as in http://localhost:8081/guide/installation/linux-mac.html#install-the-vue-storefront

@pkarw It's not about adding g++, make and python to package.json. I'm not even possible whether it's possible to add them via npm. What I meant was to add them to the Dockerfile.
@kkdg AFAIK it occurs both for people using Docker, and directly calling yarn.

I have the same problem with building vsf using Docker. Why not add these dependencies to Dockerfile?

@andrzejewsky

@michaelKurowski when you call it directly and don't have the native dependencies to build packages there it can only help with adding an entry to the documentation that you need to have like written here like python, make and C/C++ compiler toolchain installed when you are on linux/unix system.
For the docker container can you give me an example of what is not working as for me like native packages that needs to be build there bindings are working in the API docker image.
I have used 1.9,1.10 and no 1.11.0-rc1 in docker and all are working.
When I now how to reproduce it I could try to help fix it.


FileNotFoundError: [WinError 2]

i keep facing  erorrs when triyng to utilize python libraries designed for arabic language prprocessing.
the last one is this error when i tried to use farasapy postagging
File "C:\Users\arwaa\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 1420, in _execute_child     hp, ht, pid, tid = _winapi.CreateProcess(executable, args, FileNotFoundError: [WinError 2] The system cannot find the file specified
is there a possible solution or it would be better if i run python on linux , not windows, because the other errorsi have faced turns out that it has to do with the system and the installation of the packages or the virtual environment  and not with the code itself, the codes are always correct

Hey @arwaa89 , thanks for reaching out and reporting the issue.
I would recomment first to try it on google.colab to check that the error is not from the code itself. Then, you may try to install brand new virtual environment and try again. If you are more interested, you can try WSL, Windows Subsystem for Linux, It may reslolve some of your problems.

closing the issue for inactivity.


This should throw exception UnknownIdentifier: Baz

class Foo {}
class Bar {}
class test {
public void main(char[][] args) {
class Baz b;
}
}

Are you working on this or is this here to have someone else take it up?

Added.


Error = Target script does not exist: run.js

Present on my system (ubuntu trusty) installed following all available documentation.
Also verified as an issue as same thing happens here: https://tonicdev.com/npm/jarvis-bot
I haven't yet found the construct or docs for what is needed in run.js in this particular package.
Any suggestions?

Hey, the npm version is Jarvis v1.0, which is a legacy release (can't be used with v2). Please see the note


Login func has been refactored lines 90-103 where extracted into new …

Description
Lowers cognitive complexity of login function, based on Code Climate analysis.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Change Status

[ ] Complete, tested, ready to review and merge
[x] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

How Has This Been Tested?
May require additional tests, as this is a code refactor.

[x] Previous login function unit test

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

Moving forward we'll make sure that all checks are passing before merging to master.


Sample from truncated normal

Motivation and Context
After some more chats with people, we've decided two things make more sense:

Sample the noise from a truncated normal such that the noise never exceeds 3 sigma
Sample the noise such that robot always moves at least a little bit in its intended direction. i.e. doesn't turn left when it mean to turn right.  I've set this little bit to mean at least 5% of its intended amount as this allows all actuation amounts to still be well defined.  For actuations without too much noise, large actuation amounts will pretty quick get into the 3 sigma regime, so noise will go back to being independent of actuation amount

This involves adding a dependency on scipy as I need to be able to sample from a truncated normal.  I can make this a soft dependency if this feels like to big of a dependency.
How Has This Been Tested
Via tests.  I increased the actuation amount in the unit test as the assumption that the noise is approximately gaussian is now only true for reasonably large actuation amounts.
The rollouts image looks very similar to as before:

Types of changes

Bug fix (non-breaking change which fixes an issue)

What are the red lines outside the boundaries?

When the agent slides along a wall, it can slide around a corner.


[WebToolsE2E][Aspire] Deployment of AspireShop failed with error: error MSB4166: System.ArgumentNullException: Value cannot be null. (Parameter 'value')

INSTALL STEPS

Clean machine: Win11 x64 23h2 ENU
Install VS 17.11.2 [Include Aspire 8.1.0]
Install Docker Desktop for Windows
Install the latest released azd [1.9.6]

REPRO STEPS

Clone aspire-samples repo from main branch [Aspire 8.1.0]
Deploy using azd

Open the samples\AspireShop
solution folder in a Command Prompt
Running azd init, select 'Use code in the current directory' > Confirm and continue initializing my app, type a new environment name, press enter.
Running azd up to deploy to Azure

ACTUAL:
ERROR: error executing step command 'deploy --all': failed deploying service 'catalogdbmanager': publishing container: dotnet publish on project 'C:\Users\V-SHER~1\source\repos\aspire-samples\samples\AspireShop\AspireShop.CatalogDbManager\AspireShop.CatalogDbManager.csproj' failed: exit code: 1, stdout: , stderr: MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\v-sherryfan\AppData\Local\Temp\MSBuildTemp" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
MSBUILD : error MSB4166: C:\Users\v-sherryfan\AppData\Local\Temp\MSBuildTemp\MSBuild_pid-22596_166cf785a8f54b07b6697a80d19216cd.failure.txt:
MSBUILD : error MSB4166: UNHANDLED EXCEPTIONS FROM PROCESS 22596:
MSBUILD : error MSB4166: =====================
MSBUILD : error MSB4166: 8/28/2024 9:36:01 AM
MSBUILD : error MSB4166: System.ArgumentNullException: Value cannot be null. (Parameter 'value')
MSBUILD : error MSB4166:    at System.ArgumentNullException.Throw(String paramName)
MSBUILD : error MSB4166:    at System.IO.BinaryWriter.Write(String value)
MSBUILD : error MSB4166:    at Microsoft.Build.Framework.TelemetryEventArgs.WriteToStream(BinaryWriter writer)
MSBUILD : error MSB4166:    at Microsoft.Build.Shared.LogMessagePacketBase.WriteToStream(ITranslator translator)
MSBUILD : error MSB4166:    at Microsoft.Build.Shared.LogMessagePacketBase.Translate(ITranslator translator)
MSBUILD : error MSB4166:    at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
MSBUILD : error MSB4166: ===================
MSBUILD : error MSB4166:
MSBUILD : error MSB4166:
Build failed. Properties, Items, and Target results cannot be obtained. See details in stderr above.

Note

If you manually update the Aspire version from 8.1 to 8.2, it will still repro.

EXPECTED
Can be published successfully.

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."

@chenshupe I don't seem to have permission.

I've reproduced this with aspire shop sample. Also saw similar issue deploying my own project.

Any updates on this?

https://discord.com/channels/732297728826277939/759125320505884752/1278891265961889804
updating  .net sdk from 8.0.400 to 8.0.401 solved this for me

https://discord.com/channels/732297728826277939/759125320505884752/1278891265961889804 updating .net sdk from 8.0.400 to 8.0.401 solved this for me

Thanks, this workaround is good for me too.

updating the sdk did not solve the problem for me...

updating SDK to 8.0.401 and Aspire to 8.2.0 solved the issue for me .

updating SDK to 8.0.401 and Aspire to 8.2.0 solved the issue for me .

I can't thank you more. I confirm updating SDK to 8.0.401 was the only solution that worked. Thank you!!!

Closed this as not repro on aspire-samples 9.0.0


Support include of code snippets in a document

Some technical specification documents include snippets of code examples or XML elements and the like. Those snippets should remain in source files that can be validated by a language interpreter. Also, source code may be subject to improvements, changes, or corrections over time, but if they are included into a markdown file by copy and paste, they become frozen. Therefore, it would be better to provide a syntax to include snippets dynamically when a Tablature file is processed.
Typically code snippets are bound by markdown fenced code blocks using "```".  Rather than literally copying the code into the fenced block, the block would contain syntax to tell a Tablature processor to include a file or section of a file. The source file would need to be accessible at processing time.

The markdown parser should recognize fenced code blocks as a leaf block type, including info string.
See https://github.github.com/gfm/#fenced-code-blocks

This should be a generic feature of module md-grammar, which is now in its own repository.


Remove the langmeta dependency from semanticdb-scalac

The dependency on langmeta is significantly slowing us down - both performance-wise (because we have to spend time on conversions) and productivity-wise (because new semanticdb features have to be implemented in both semanticdb3 and langmeta). Would be great to get rid of that dependency completely.

Not sure we can escape the dependency immediately, but a good first step would be to stop emitting org.langmeta.Document and go to s.TextDocument directly instead

I haven't prototyped anything yet, so I'm not sure what difficulties we may encounter with getting rid of the dependency. Any thoughts about that?

Diffs in https://github.com/scalameta/scalameta/pull/1218 and https://github.com/scalameta/scalameta/compare/master...olafurpg:perf?expand=1 are my attempts at this and may be a useful source of inspiration. The first attempt failed because of lack of benchmark infrastructure and the second failed by trying to do too much at once (drop langmeta + scalameta).

This is fixed.


Variable expansion with parameter

From document I only see parameter is used for default value.
Is it possible for @key to resolve property key from parameter?
We can use different syntax to that used by current variable expansion feature, like $[param_name]
If parameter can only be used in one place, personally I'd choose to use parameter on key, since users can easily compose the default value by themselves. The interface doesn't really hide parameter resolution logic, users still need to know the value in @DefaultValue and know it'll be used by Formatter. There's no need to delegate to Config when this can be easily achieved by themselves.

The parameters are used not only for the default value but also for the value resolved from the property file.
I've not understood the rest of the question. Please provide some sample code with some sample results to better explain what you are asking.


Bolt can't find target by uri in inventory

Describe the Bug
Bolt returns a target by CLI and in a plan with get_target() or get_targets() whether it could find the target in the inventory or not.
https://www.puppet.com/docs/bolt/latest/inventory_files.html

Similar to name, you can specify an alias as another way to refer to a target. In the following example, you could run a command using the target's uri, name, or alias.

While the documentation is technically true (it indeed does return a target, but not the expected one), this leads to an unexpected behaviour that any customisation is not reflected when getting this target. Any transport configuration, facts, custom vars, ... are not returned/used.
Expected Behavior
CLI commands getting a target as well as bolt plan functions get_target() and get_targets() can find the target in the inventory by uri as well.
Steps to Reproduce

Have a inventory.yaml setup

targets:
  - uri: target1.example.com
    name: target1
    alias: dashboard
    config:
      transport: ssh
  - uri: target2.example.com
    name: target2
    alias: database
    config:
      transport: winrm

Observe the difference between those two commands:

$ bolt inventory show -t target2
Targets
  target2

Inventory source
  /home/dm/.puppetlabs/bolt/inventory.yaml

Target count
  1 total, 1 from inventory, 0 adhoc

$ bolt inventory show -t target2.example.com
Targets
  target2.example.com    (Not found in inventory file)

Inventory source
  /home/dm/.puppetlabs/bolt/inventory.yaml

Target count
  1 total, 0 from inventory, 1 adhoc

Transport config is lost

$ bolt inventory show -t target2 --detail | grep transport
    transport: winrm

$ bolt inventory show -t target2.example.com --detail | grep transport
    transport: ssh

Environment

Version 3.30.0
Platform Debian

Additional Context
A workaround using alias is also not sufficient for my case, as it can only be defined once.
I can see the use case of the current limitation. As you can define multiple targets for the same host (e.g. by using different ports) and thus "target != node".

"When searching for a target's configuration data, Bolt matches a target's URI with its name. Bolt uses depth-first search and uses the first value it finds."

"name	A human-readable name for a target. Required when specifying a target using a hash. Optional if using uri. If you don't specify a name, Bolt uses the uri as the target name."

The definition is unclear to me whether a target name represents its uri or not. If name is not defined, the uri is the name. So are those now considered equal or not?
Right now: If a name is defined a target in the inventory can only be found by name and alias. If no name is defined a target in the inventory can only be found by uri and alias. But you'll have to use two different names (or alias) if you use the same uri in multiple targets with different transport configuration.

uri	The URI of the target. Bolt uses the uri to establish a connection to the target. Required when specifying a target using a hash, unless you specify a name and configure a hostname using host in the target's transport configuration.

That sound right to me, define in transport.hostname any custom adaption of uri and port, but let the target be found by uri
Additional Issue
If I only want a get_target() or get_targets() succeed if it's defined in the inventory, I have no feedback. If not double-checked a command could be executed on the wrong transport target.

In Inventory a Target name is a unique identifier. For this example:
targets:
  - uri: target1.example.com
    name: target1
    alias: dashboard
    config:
      transport: ssh
  - uri: target2.example.com
    name: target2
    alias: database
    config:
      transport: winrm

When you ask for target2.example.com you get a net new target as it does not match the name of any target.
bolt inventory show -t target2.example.com
If you want Target.name and Target.uri to match, just specify uri and omit name from your inventory entreis. That will be the default Target.name.

Got it, unless Target.name is defined in multiple groups, then some merging happens https://www.puppet.com/docs/bolt/latest/inventory_files.html#precedence


Wordpess/bootstrap/sass code to enqueue

Hi all, Trying to include Bootstrap and sass in worpress not sure what version of Bootstrap to use as I want to include sass ,I also what to put in enqueue code but cant get it to work with variations of code below. I also have been using scout/compass.
Also do I need to use ruby on rails for Bootstrap 4 and will I have to move from scout to Gulp and npm to use sass. Thanks in advance for any help.
`<?php
function my_theme_enqueue_styles() {
$parent_style = 'parent-style'; // 2017 style

wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'child-style',
    get_stylesheet_directory_uri() . '/style.css',
    array( $parent_style ),
    wp_get_theme()->get('Version')
);

 wp_enqueue_style(
  'bootstrap',
get_stylesheet_directory_uri() . '/bootstrap/css/bootstrap.min.css');

wp_enqueue_script(
  'bootstrap',
get_stylesheet_directory_uri() . '/bootstrap/js/bootstrap.min.js');

}
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );
?>`

Closing as this doesn't seem to have any relation to Entity Framework. Please find a more appropriate place for these questions.


Updating Firefox status for preload links

Reference : https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content#Browser_compatibility

ah sorry, didn't saw https://github.com/Fyrd/caniuse/pull/3635


Issue: Elevator module stops only lets me label 7 floors

I made about 11 floors with elevators but i can only name 0 to 7    the remaining floors i am unable to label / name.
Unless there is a cmd that lets me label floors past 7  the gui / coding could use an upgrade for the elevator button modules.
Love the mod just figure i would mention this.

Check the gui for the elevator button module. There is a button to enable two colums

hmm will go check again.  i just never noticed a way to name floors past 7
:p
On Thu, Nov 3, 2016 at 3:08 AM, McJty<EMAIL_ADDRESS>wrote:

Check the gui for the elevator button module. There is a button to enable
two colums
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/McJty/RFTools/issues/821#issuecomment-258082802, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARVCAst04waxuEDeKHXTyErq1T427QK1ks5q6ZaOgaJpZM4KoFGz
.

hmm i still do not see a way to name floors past 0-7
my floors go from 0-11     and looking at the gui options of the elevator button module  i don't see an option that lets me name floors 8-11.
O_o  am i missing something?

Check the gui for the elevator button module. There is a button to enable two colums

I remember reading about that somewhere but I just had a look and I can't see it. Only buttons I have are:

Button Color / Current Level Color
Vertical / Large
Lights / Start 1
8 boxes for names

Toggling the Vertical button does result in two columns of buttons being displayed on the screen, but no additional name boxes are offered.
mcjtylib 1.10-2.2.0
rftools 1.10-5.58

Ah for naming. No, that isn't possible yet. The GUI is a bit limited for that so I couldn't find a way to name more then that

Would it be possible to have a button to toggle the boxes between column1_names and column2_names?
Or even add a 1-field GUI to the elevators where you specify the name.
Or name elevators in an Anvil and have it display that!

Next version you will be able to name elevator blocks


Calendar-specific datetime subclasses lose their identity after pickling

After pickling it appears that calendar-specific subclasses of cftime.datetime objects lose their identity.  This causes integration issues between downstream libraries that depend on serialization, e.g. between xarray and distributed (pydata/xarray#5686).
Minimal working example:
>>> import cftime; import pickle
>>> serialized = pickle.dumps(cftime.DatetimeNoLeap(2000, 1, 1))
>>> deserialized = pickle.loads(serialized)
>>> deserialized
cftime.datetime(2000, 1, 1, 0, 0, 0, 0, calendar='noleap', has_year_zero=True)

I would expect deserialized to retain its cftime.DatetimeNoLeap type.  Is there a way to make sure that the type is round-tripped through pickling?
cc: @aidanheerdegen

The serialization happens through the __reduce__ method
    def __reduce__(self):
        """special method that allows instance to be pickled"""
        args, kwargs = self._getstate()
        return (_create_datetime, (args, kwargs))

I suppose we could support serialization of datetime specific instances with a bunch if if-statements here, but on the other hand I thought datetime specfic instances were deprecated anyway (since downstream libs can just check the calendar instance variable instead).

Thanks @jswhit -- I sort of answered my own question -- I have a solution in #252.  We have not yet fully adopted the universal cftime.datetime in xarray, so we still use the subclasses internally (this was motivation for the 1.4.1 release which restored those for the time being).

That's a very nice solution @spencerkclark

closed by PR #252

Thanks for the prompt fix.
Do you have a timeline for the next release? This bug prevents currently used code from working correctly, but we're relying on >1.5 for the latest xarray release I believe.

Sorry to be a pain @jswhit, but this bug is affecting users, so any update on when 1.5.1 will be released?


go starter

python test times out from time to time

I haven't also checked if pattern is a single character, but used ContainsAny instead. It works the same for single character, and returns true if any of characters from pattern are found.
One more check will make it closer to the task, but not closer to the actual grep and will add more code complexity from very beginning.
What do you think, should I add this check just like in the python solution?

I haven't also checked if the pattern is a single character, but I used ContainsAny instead. It works the same for a single character and returns true if any characters from the pattern are found.

One more check will make it closer to the task but not closer to the actual grep and will add more code complexity from the very beginning.

What do you think? Should I add this check just like in the python solution?

The reason we have the check there in the Python solution is that once the user has uncommented & then they attempt the next stage, they'll see a clear error message (something like "unhandled pattern: \d") instead of a silent failure. I think the clear error message is a good property to have, as long as it doesn't complicate code too much. Do you want to try this option and see how it looks?

Looks good! Added one comment tweak suggestion. Once that's done feel free to merge.
And let's continue with other stages in the grep course once done. For now, we only need solutions till stage #8 (end of string anchor)

I've also renamed match -> matchLine so if we want to process multiple lines we won't change the function and just add another one.

Good call on renaming match -> matchLine!


ALSA lib pcm.c:8306:(snd_pcm_recover) overrun occurred

kws_doa.py is crashing after few seconds raising this error on raspbian stretch using the respeaker 4 mic hat for raspberry pi

Increasing VAD_FRAMES to 100 solved the problem without loosing accuracy neither performance.

it's still happening. it is only taking longer

Situation is little better when running with pulseaudio

Hello sir, have you solved this problem?


Move tests for dataserver controllers into controllers subdir

 Separate JS code into classes with some object-oriented practices.

adding @axmb since I know it's late for @attwad

LGTM. I think this organization works -- having a distinct test folder makes excluding the files, e.g. from TS compilation, simple. The other option is to just place test files alongside source files; this avoids the need to sync dir structure between src/test, at the expense of more regex in tsconfig (and perhaps other places).

happy to do this for new but review the structure later if we're not feeling this


fix(RemoveComponent): Add aria-label to remove button

:tada: This PR is included in version 6.4.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix mask and soft-dtw loss

1 fix mask problem when calculating W in LearnUpsampling Module and attention matrix in VaribleLengthAttention module.
2 a new Jacobian matrix of Manhattan distance
3 deal with mel spectrograms of different lengths

Thanks for your contribution :)


(V2) cla-manager-distribution API Endpoint: CLA Manager who has not signed into the EascyCLA application is included in the count of CLA Managers

Background

Fetch the response from https://api-gw.dev.platform.linuxfoundation.org/cla-service/v4/metrics/cla-manager-distribution
Note the counts
Launch Corporate Console
Login as nirupamavmentee3
Click on Company NotSignedInCLAManagerCompTest
Click on Manage Whitelist for project
Click on + icon under CLA Manager section to Add CLA Manager
Enter LFID for e.g nirupamavmentee100 and Click SAVE
CLA Manager is added to the project but status of the user is shown as not signed in
If required execute the cron job to fetch the latest count
Fetch the response from https://api-gw.dev.platform.linuxfoundation.org/cla-service/v4/metrics/cla-manager-distribution

Before Adding CLA Manager

{
"createdAt": "2020-04-06T05:25:56Z",
"fourOrMoreClaManagers": 51,
"oneClaManager": 360,
"threeClaManagers": 88,
"twoClaManagers": 178
}
Before Adding CLA Manager who has not signed in

{
"createdAt": "2020-04-06T05:27:50Z",
"fourOrMoreClaManagers": 51,
"oneClaManager": 360,
"threeClaManagers": 89,
"twoClaManagers": 177
}
Expected Behaviour
CLA Manager who has not signed in should be included in the CLA Manager counts.
After the CLA Manager sign into the EascyCLA app, the count should be included in the CLA Manager counts

Pull Request: https://github.com/communitybridge/easycla/pull/888

Verified and observed that the issue is fixed in both cla-manager-distribution and total-count endpoints

The old v1 console is deprecated and removed.


STY: Dont log info messages by default

When processing things in a loop I get spammed by a lot of:
colormap sequential: [0.00e+00, 9.68e-01, 1.94e+00] (transparent)
colormap sequential: [0.00e+00, 9.68e-01, 1.94e+00] (transparent)
colormap sequential: [0.00e+00, 9.68e-01, 1.94e+00] (transparent)
colormap sequential: [0.00e+00, 9.68e-01, 1.94e+00] (transparent)

I don't think this is very useful for users in general, so by default we probably shouldn't log it.

Argh this does not work, I'll probably just set them to logger.debug instead of logger.info

+100 on this; I have verbose=0 set all over the place.

Just changed all logger.info to logger.debug, then fixed an MNE install error


Malformed Chat Message from External Source Borks Chat

This is a pretty high profile bug, but hard to exploit. If someone sends you a chat message with HTML in it, the app will basically not parse the message and the chat sidebar disappears permanently until you remove the chat message from the DB.
Example chat message body:
  My Site

Welcome to my super lame site.

Copyright (c) foobar

Causes this stack trace
/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatMessage.js:83 Uncaught TypeError: Cannot read property 'forEach' of null
    at findWords (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatMessage.js:83)
    at /Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatMessage.js:93
    at NodeList.forEach (<anonymous>)
    at findWords (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatMessage.js:92)
    at processMessage (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatMessage.js:98)
    at _class.parse (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatHead.js:50)
    at _class.Backbone.Model (/Applications/OpenBazaar2.app/Contents/Resources/app/node_modules/backbone/backbone.js:400)
    at _class (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/BaseModel.js:126)
    at new _class (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/models/chat/ChatHead.js:39)
    at new model (/Applications/OpenBazaar2.app/Contents/Resources/app/prod/collections/ChatHeads.js:75)

Chat sidebar missing now.

@hoffmabc can you post the contents of the database that cause this error?
I'm seeing that sending
test
 is fine, but

test

test

Throws an unhandled exception on line 46 of the ChantMessage model of the sending client.

Once I’m back at my computer I will post a formal paste of the content


Document tzdata dependency

Fixes #4433.

This change is

@bdarnell, is this sufficient, or do we need to explicitly call this out in the install pages and/or the deployment tutorials?

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/fa25f745fec15c78e0d2d49d7cb4676ad482e36d/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/698596db8b972095e6cb7d315e08be9115481010/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/ecdd2b6c3bcf106119fae8b259cf0fb3144406ef/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b8ff369935398bba164951eefa93a692bf168c40/

@bdarnell, PTAL again.
I'm not sure why the build is failing. The anchors it's complaining about are perfectly fine.

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b8ff369935398bba164951eefa93a692bf168c40/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e683b9b4fe9c50db2eeaf41b457698dfc234ff66/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/5a37e6993a3677249230298f294730d6daed8819/


Typescript gets confused with a variable and an imported interface with the same name

TypeScript Version:
1.8.0-1.8.7
Code
import {Key} from 'types'; // Key is an interface
const Key = { test() {} };
Key.test();
export default Key;

Expected behavior:
Key.test();
exports.default = Key;

Actual behavior:
types_1.Key.test();
exports.default = types_1.Key;

We should be issuing a Duplicate Identifier error on Key since we otherwise couldn't emit this correctly in transpile scenarios

Key is an interface though. It doesn't have any value. It shouldn't be a duplicate identifier.

The problem is that when a file gets compiled through ts.transpile, we don't do any module lookup, symbol resolution, etc, so we have no way of knowing that that is the case.

I don't see why this should be fine...
interface Key {}
const Key = {};
export default Key;

...and this should not:
interface.ts
export interface Key {}

key.ts
import {Key} from './interface';
const Key = {};
export default Key;

I see your point...

how about this:
when #transpile sees two duplicate identifiers, it checks if the local definition has a value. if it does (i.e. the local definition is not an interface/type) #transpile uses it. if it doesn't have a value, #transpile uses the imported one.

when #transpile sees two duplicate identifiers, it checks if the local definition has a value.

The meanings of a local declaration could be still sourced in another file. Consider
a1.d.ts
namespace X {
  export interface Y { }
}

a2.d.ts
namespace X {
  export var Y;
}

foo.ts
// might be referencing a1 *or* a2, we can't tell
import Key = X.Y;

in that case both namespaces have the same name X. we don't have a2_1.X. as there's no import.

And you can't have duplicate namespaces I believe.
/// <reference path="a2" />
import {X} from 'a1';

shouldn't work.

IKey, would be nice if there was community acceptable of the I paradigm

I don't want to create new issue even if mine isn't exactly the same as other Duplicate Identifier posts but I can if a moderator or contributor says that I should. But here is my issue with the Duplicate Identifiers.
//*******
// Declare any non typeScript functions here to avoid compile errors
//*******
declare var HeyImGlobal: any;
//*******

export class TsModule extends HTMLElement {
    HeyImGlobal(param1, param2, param3);
}

For my example I have a project that has access to many global variables that are defined elsewhere, in this example it's HeyImGlobal. When creating a new TS file I cannot use that global variable unless I declare it at the top like declare var HeyImGlobal: any; so the code in the same file knows about the variable or else you'll get the "Cannot Find Name" error. Visual Studio will build and compile TypeScript just fine with the code above but VS Code will not even though both will show the same error that the declaration declare var HeyImGlobal: any has a "Duplicate Identifier". I can also use the global variable when it builds and compiles so the code works. But I am blocked from using VS Code because the compiler is finding the variable in another file when declaring it..  I do have the "files": [] property filled out in tsconfig.json with the only three TypeScript files that I have and I thought that would stop the detection in other files but I'm probably misunderstanding that part.
Yes a flag would be great or at least something just to get around what's preventing me from using and compiling with VS Code.

@DanJ210 It sounds like VS Code has found some additional files that the compiler does not when invoked from the command line. But I don't think you have found a bug necessarily, and definitely not the bug from this issue.
I would ask at Stack Overflow or the Typescript gitter channel for help debugging which files VS Code is including in the compilation.

@sandersn I've seen the file. Visual Studio will show where the variable is getting picked up at. If I know the file then what can I do at that point?

Record your file system layout and tsconfig. Then ask a question on SO or TS' gitter, giving that information. You might also try --traceResolution from the command line to see why that file doesn't get picked up.

Should be a duplicate identifier / declaration merge error only in --isolatedModules, but triggers no error today

I think I was wrong about this—if the emit always does the right thing, even in transpilation, and the code makes sense in whole-program compilation, I don’t see why there should be an error. Feel free to comment/reopen if I’m wrong.


Not clear how reconnect effects subscriptions

I've configured my connection to RabbitMQ and set up queues without auto subscription.
      queues: [{
         name: 'device.inbound.q',
         autoDelete: false,
         subscribe: false,
         durable: true,
         noBatch: true,
         deadLetter: 'device.inbound.dead.ex',
         limit: 20,
         exclusive: false,
         noAck: false,
      }]

(I don't auto subscribe because my handlers aren't registered at configuration time)
Sometime later I start a subscription like so:
rabbit.startSubscription('device.inbound.q')

All is working fine until my connection to the RabbitMQ server is lost for whatever reason (in my case usually a restart of the rabbitmq service). At this point my subscription is not re-established and I need to restart my process in order to start receiving messages again.
How should this be handled? Should the subscriptions be automatically restarted? Do I need to keep track of the started subscriptions and restart them?

I figured I'd try to call startSubscription for my queue after it reconnects iff the subscription has been started.
   Rabbit.on('connected', () => {
      if (subscriptionStarted) {
         Rabbit.startSubscription('device.inbound.q')
      }
   })

When adding the rabbit.on('connected', fn) handler it seems to change the behavior of publishing after disconnects. I start receiving this message:
Potentially unhandled rejection [17] Error: Publish took longer than configured timeout
    at null.<anonymous> (/Users/joe/code/wascally-test/node_modules/wascally/src/exchangeFsm.js:76:15)
    at Timer.listOnTimeout (timers.js:92:15)```

@joeandaverde I think this is likely related to issue #119 - wascally really should re-subscribe to any queues that it had subscriptions to during a disconnect. Right now, any queues defined with subscribe set to true already behave this way. Anything you manually start the subscription to doesn't.

I'm using the library rabbus which handles my request-respond queue creation, bindings and the like.
By default it uses subscribe:false for queue settings and I set my replyQueue to use subscribe:true.
I do this after reconnection:
rabbit.connections.default.connection.on( 'aquired', () => {
  // loop through my queues except replyQueue
  loop
    rabbit.startSubscription( <queueName > )
  endOfLopp
} );

it seems to be working fine in my end. I only do startSubscription when I'm sure that rabbit is reconnected and not the first connection. And I didn't have this error below:
``
Potentially unhandled rejection [17] Error: Publish took longer than configured timeout
at null. (/Users/joe/code/wascally-test/node_modules/wascally/src/exchangeFsm.js:76:15)
at Timer.listOnTimeout (timers.js:92:15)

@joeandaverde @yamii - wascally is no longer actively maintained, instead, check out rabbot. Rabbot does "remember" the subscription status when connectivity was last established and try to re-subscribe once the connection and queue are in place.


Count and say

Description
The count-and-say sequence is a sequence of digit strings defined by the recursive formula:
countAndSay(1) = "1"
countAndSay(n) is the way you would "say" the digit string from countAndSay(n-1), which is then converted into a different digit string.
To determine how you "say" a digit string, split it into the minimal number of groups so that each group is a contiguous section all of the same character. Then for each group, say the number of characters, then say the character. To convert the saying into a digit string, replace the counts with a number and concatenate every saying.
For example, the saying and conversion for digit string "3322251":

It is a leetcode medium question. And this question is under string topic.
Domain
Competitive Programming
Type of Contribution
Addition
Code of Conduct

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

/assign


Error when running custom build tool

Just having teething problems getting this project set up. I have a separate class library for the models that I have the Umbraco Core Binaries and ModelsBuilder library installed via NuGet to. I set up the custom tool options but when I run I get this error:
ZbuModelsBuilder: ZbuModelsBuilder failed to generate code: FileNotFoundException: Could not load file or assembly 'System.Web.Http, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Not sure why, I can see System.Web.Http (v4) is present as a reference in the project.
Insights much appreciated!
Alan

I'm not really following the solution in the link. It seems very hacky.
Any chance of a version that with the updated references that installs with out error?

This should be taken care of by 2.0.3.

Thanks.
I've installed the latest extension and 2 new nuget packages. That all went well.
I ran the tool and it has certainly worked and generated some new classes but I got a the error message at the very end.
Running the tool again results in an instant error message.
Is there a log I can look at to see what the error is?
Matt

Damn. The custom tool logs into the output console... in Visual Studio you have to View | Output and pick the right output in Show output from and there should be the exception stack trace.

Hmmm worry not...I went back to it after your information above, ran it again and it worked.
It created the class I expected and my project compiles so hat's all good. Thanks!
Anyway here's my output:
ZbuModelsBuilder: Starting 09/01/2015 14:19:49.
ZbuModelsBuilder: ZbuModelsBuilder failed to generate code: Exception: Response status code does not indicate success (Forbidden)
"API version conflict: client version (<IP_ADDRESS>) is not compatible with server version(<IP_ADDRESS>)."
ZbuModelsBuilder:    at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.EnsureSuccess(HttpResponseMessage result)
at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.ValidateClientVersion()
at Zbu.ModelsBuilder.CustomTool.CustomTool.ZbuModelsBuilder.GenerateRaw(String wszInputFilePath, String wszDefaultNamespace, IntPtr[] rgbOutputFileContents, UInt32& pcbOutput, String& errMsg)
ZbuModelsBuilder: Starting 09/01/2015 14:21:01.
ZbuModelsBuilder: ZbuModelsBuilder failed to generate code: Exception: Response status code does not indicate success (Forbidden)
"API version conflict: client version (<IP_ADDRESS>) is not compatible with server version(<IP_ADDRESS>)."
ZbuModelsBuilder:    at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.EnsureSuccess(HttpResponseMessage result)
at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.ValidateClientVersion()
at Zbu.ModelsBuilder.CustomTool.CustomTool.ZbuModelsBuilder.GenerateRaw(String wszInputFilePath, String wszDefaultNamespace, IntPtr[] rgbOutputFileContents, UInt32& pcbOutput, String& errMsg)
ZbuModelsBuilder: Starting 09/01/2015 14:21:26.
ZbuModelsBuilder: ZbuModelsBuilder failed to generate code: Exception: Response status code does not indicate success (Forbidden)
"API version conflict: client version (<IP_ADDRESS>) is not compatible with server version(<IP_ADDRESS>)."
ZbuModelsBuilder:    at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.EnsureSuccess(HttpResponseMessage result)
at Zbu.ModelsBuilder.AspNet.ModelsBuilderApi.ValidateClientVersion()
at Zbu.ModelsBuilder.CustomTool.CustomTool.ZbuModelsBuilder.GenerateRaw(String wszInputFilePath, String wszDefaultNamespace, IntPtr[] rgbOutputFileContents, UInt32& pcbOutput, String& errMsg)
ZbuModelsBuilder: Starting 09/01/2015 14:31:45.
ZbuModelsBuilder: Done.

That error message sometimes pops when Visual Studio hasn't properly refreshed the extension... ie you have to close all instances of Visual Studio and reopen. Glad that it works!

Thanks for your efforts!