text:
Tags are showed Signed and sometime not

My Harbor running OK, but when I list a Project Repository in UI some time the Signed Tags are showed and some time not. Clicking in other Project or F5 (refresh page), Tags are changed from "V" (Green) and  "X" (Red) to "?" (black) and "vice-versa". I dont kown what is happen and how can I discover the issue.
My system was Upgraded from version 0.5.0 to v1.1.2 and I have used own CA Certs configuration in UI Registry and Customized Certs with Notary. Docker Commands ("pull " and "push") with Docker Content Trust running OK and Tags are trusted.
Note: I did not upgrade the Registry Data Base, because that did not work for me, the old Data Base work fine.

Can you try to issue the follow API to see what out put will be returned?
https://yourharborserverip/api/repositories/lixo/nginx/tags?detail=1
Please try to execute the URL several time to see if there are any difference.
Also please include the harbor logs when the issue happens.

There you go...
https://yourharborserverip/api/repositories/lixo/nginx/tags?detail=1
[
  {
    "tag": "1.9-trusted",
    "manifest": {
      "schemaVersion": 1,
      "name": "lixo/nginx",
      "tag": "1.9-trusted",
      "architecture": "amd64",
      "fsLayers": [
        {
          "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
        },
        {
          "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
        },
        {
          "blobSum": "sha256:a4335300aa893de13a747fee474cd982c62539fd8e20e9b5eb21125996140b8a"
        },
        {
          "blobSum": "sha256:640c8f3d0eb2b84205cc43e312914c4ae464d433089ee1c95042b893eb7af09b"
        },
        {
          "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
        },
        {
          "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
        },
        {
          "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
        },
        {
          "blobSum": "sha256:51f5c6a04d83efd2d45c5fd59537218924bc46705e3de6ffc8bc07b51481610b"
        }
      ],
      "history": [
        {
          "v1Compatibility": "{\"architecture\":\"amd64\",\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\",\"config\":{\"Hostname\":\"b0cf605c7757\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"ExposedPorts\":{\"443/tcp\":{},\"80/tcp\":{}},\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":[\"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\",\"NGINX_VERSION=1.9.15-1~jessie\"],\"Cmd\":[\"nginx\",\"-g\",\"daemon off;\"],\"Image\":\"aa527287a51f0178662d50479697b53893b65fee9383af889ece937fd02c7c56\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":[],\"Labels\":{}},\"container\":\"b5b9e60402f2a7222d9c26ac26518d443e8dcd5cebda4e6d18abf20bffc4f11c\",\"container_config\":{\"Hostname\":\"b0cf605c7757\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"ExposedPorts\":{\"443/tcp\":{},\"80/tcp\":{}},\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":[\"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\",\"NGINX_VERSION=1.9.15-1~jessie\"],\"Cmd\":[\"/bin/sh\",\"-c\",\"#(nop) CMD [\\\"nginx\\\" \\\"-g\\\" \\\"daemon off;\\\"]\"],\"Image\":\"aa527287a51f0178662d50479697b53893b65fee9383af889ece937fd02c7c56\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":[],\"Labels\":{}},\"created\":\"2016-05-24T04:16:49.228757773Z\",\"docker_version\":\"1.9.1\",\"id\":\"d20e4a0ece43d20ca095ca6bcbaff296641ec62cdb05c2676ec9ccc05835c3c7\",\"os\":\"linux\",\"parent\":\"055ff215a12851ae659069e5cba97810e750a33ebc0666bcfe8ae24a69fa3938\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"055ff215a12851ae659069e5cba97810e750a33ebc0666bcfe8ae24a69fa3938\",\"parent\":\"01c0a8c628bbdaa313c022d6c87d59dc277e16b6d3ed0d32cd36b059352c276e\",\"created\":\"2016-05-24T04:16:48.052193209Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) EXPOSE 443/tcp 80/tcp\"]},\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"01c0a8c628bbdaa313c022d6c87d59dc277e16b6d3ed0d32cd36b059352c276e\",\"parent\":\"8556d4c370a576bf5ec83c6befcd3b2440f82721cd1a263865b2634a8d6f03d4\",\"created\":\"2016-05-24T04:16:46.665763882Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c ln -sf /dev/stdout /var/log/nginx/access.log \\t\\u0026\\u0026 ln -sf /dev/stderr /var/log/nginx/error.log\"]},\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"8556d4c370a576bf5ec83c6befcd3b2440f82721cd1a263865b2634a8d6f03d4\",\"parent\":\"963493e54e682e698aee7ff1dc6ac9eb4234484bf58caccbebd4058619fd7d8d\",\"created\":\"2016-05-24T04:16:42.657465397Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62 \\t\\u0026\\u0026 echo \\\"deb http://nginx.org/packages/mainline/debian/ jessie nginx\\\" \\u003e\\u003e /etc/apt/sources.list \\t\\u0026\\u0026 apt-get update \\t\\u0026\\u0026 apt-get install --no-install-recommends --no-install-suggests -y \\t\\t\\t\\t\\t\\tca-certificates \\t\\t\\t\\t\\t\\tnginx=${NGINX_VERSION} \\t\\t\\t\\t\\t\\tnginx-module-xslt \\t\\t\\t\\t\\t\\tnginx-module-geoip \\t\\t\\t\\t\\t\\tnginx-module-image-filter \\t\\t\\t\\t\\t\\tnginx-module-perl \\t\\t\\t\\t\\t\\tnginx-module-njs \\t\\t\\t\\t\\t\\tgettext-base \\t\\u0026\\u0026 rm -rf /var/lib/apt/lists/*\"]},\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"963493e54e682e698aee7ff1dc6ac9eb4234484bf58caccbebd4058619fd7d8d\",\"parent\":\"968c69f186734255a864498d3e55e0babe7f0c1fd443a81d32303022e1058ab2\",\"created\":\"2016-05-24T04:15:26.367439086Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) ENV NGINX_VERSION=1.9.15-1~jessie\"]},\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"968c69f186734255a864498d3e55e0babe7f0c1fd443a81d32303022e1058ab2\",\"parent\":\"3035387b9e834c466cd957662b14b5548c7b2bed1fc8057a2e80793bddd04d92\",\"created\":\"2016-05-24T04:15:25.236059965Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) MAINTAINER NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"]},\"author\":\"NGINX Docker Maintainers \\\"docker-maint@nginx.com\\\"\"}"
        },
        {
          "v1Compatibility": "{\"id\":\"3035387b9e834c466cd957662b14b5548c7b2bed1fc8057a2e80793bddd04d92\",\"parent\":\"a2295636c7aa7aeaaf8aba834ed7a9863a2a8f3e87464c8ab9bd659d4d668687\",\"created\":\"2016-05-23T22:57:23.255025884Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) CMD [\\\"/bin/bash\\\"]\"]}}"
        },
        {
          "v1Compatibility": "{\"id\":\"a2295636c7aa7aeaaf8aba834ed7a9863a2a8f3e87464c8ab9bd659d4d668687\",\"created\":\"2016-05-23T22:57:20.19311015Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) ADD file:5d8521419ad6cfb6956ed26ab70a44422d512f82462046ba8e68b7dcb8283f7e in /\"]}}"
        }
      ],
      "signatures": [
        {
          "header": {
            "jwk": {
              "crv": "P-256",
              "kid": "6LJN:HCHW:7E4J:3ZRL:BSDL:AMSV:ZECZ:FBNK:EROY:H3KH:DK46:PQFV",
              "kty": "EC",
              "x": "meZyXAZPMvN9MI71LGSWBW5vxlmEYC2ZAg3SS2Xmerc",
              "y": "0d4ma04Q8Glt9mla86VYuHIOG2JmpfGzEaXXUb-qabE"
            },
            "alg": "ES256"
          },
          "signature": "SYBOdrH0oZpl7SNh8p4sthqR005xoZ90rr2iBQ7FoF4zmkxtk_XALtjcKGgr0BFLA3RdLtnu4GzZHAoI24SltA",
          "protected": "eyJmb3JtYXRMZW5ndGgiOjYxMzEsImZvcm1hdFRhaWwiOiJDbjAiLCJ0aW1lIjoiMjAxNy0wOC0xMVQxNDoyMTowMFoifQ"
        }
      ]
    }
  }
]

The last issue lines change from each "Refresh", like this:
      ...
      "signatures": [
        {
          "header": {
            "jwk": {
              "crv": "P-256",
              "kid": "6LJN:HCHW:7E4J:3ZRL:BSDL:AMSV:ZECZ:FBNK:EROY:H3KH:DK46:PQFV",
              "kty": "EC",
              "x": "meZyXAZPMvN9MI71LGSWBW5vxlmEYC2ZAg3SS2Xmerc",
              "y": "0d4ma04Q8Glt9mla86VYuHIOG2JmpfGzEaXXUb-qabE"
            },
            "alg": "ES256"
          },
          "signature": "4JqJeNrHoG7MZyhsrPDpeOokT6DYsiIlTsA5m0zwCYf_ejAsLX_4lVJve5cyyzcj-AgtS6QUeCWi8wGGsZlMFA",
          "protected": "eyJmb3JtYXRMZW5ndGgiOjYxMzEsImZvcm1hdFRhaWwiOiJDbjAiLCJ0aW1lIjoiMjAxNy0wOC0xMVQxNDo0ODo0OFoifQ"
        }
      ]
    }
  }
]

This issue never change:
https://yourharborserverip/api/repositories/lixo/nginx/signatures
[
  {
    "tag": "1.9-trusted",
    "hashes": {
      "sha256": "MR6YQMaNiJ507voYIn0Kb5lbx6dPVFP9zUn+PDNP6yQ="
    }
  }
]

Logs:

notary-server.log (Signed="V" green)

Aug 11 14:46:41 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"bfbb345c-d424-42d4-9489-c57863183db2","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39850","http.request.uri":"/v2/","http.request.useragent":"Go-http-client/1.1","http.response.contenttype":"application/json; charset=utf-8","http.response.duration":"124.132µs","http.response.status":401,"http.response.written":145,"level":"info","msg":"response completed","time":"2017-08-11T17:46:41Z"}
Aug 11 14:46:41 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"966f7938-e08b-4478-b25f-42c2cc9982d8","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39888","http.request.uri":"/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/root.json","http.request.useragent":"Go-http-client/1.1","http.response.duration":"1.613589ms","http.response.status":200,"http.response.written":2413,"level":"info","msg":"response completed","time":"2017-08-11T17:46:41Z"}
Aug 11 14:46:41 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"a0f46d2c-7f59-4db6-93cf-ebac3574d4f6","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39888","http.request.uri":"/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/timestamp.json","http.request.useragent":"Go-http-client/1.1","http.response.duration":"1.361322ms","http.response.status":200,"http.response.written":495,"level":"info","msg":"response completed","time":"2017-08-11T17:46:41Z"}

notary-server.log (Signed="?" black)

Aug 11 14:53:01 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"22a77541-110c-4a6c-b2f9-b1b23358a301","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39888","http.request.uri":"/v2/","http.request.useragent":"Go-http-client/1.1","http.response.contenttype":"application/json; charset=utf-8","http.response.duration":"123.882µs","http.response.status":401,"http.response.written":145,"level":"info","msg":"response completed","time":"2017-08-11T17:53:01Z"}
Aug 11 14:53:01 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"4addb967-ff2b-4765-8cb3-927c757d7e1d","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39920","http.request.uri":"/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/root.json","http.request.useragent":"Go-http-client/1.1","http.response.duration":"1.707545ms","http.response.status":200,"http.response.written":2413,"level":"info","msg":"response completed","time":"2017-08-11T17:53:01Z"}
Aug 11 14:53:01 172.18.0.1 notary-server[860]: {"go.version":"go1.7.3","http.request.host":"notary-server:4443","http.request.id":"c1589d16-4e8c-4cf1-9ca4-6d3e490885ec","http.request.method":"GET","http.request.remoteaddr":"172.21.0.2:39920","http.request.uri":"/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/timestamp.json","http.request.useragent":"Go-http-client/1.1","http.response.duration":"1.487021ms","http.response.status":200,"http.response.written":495,"level":"info","msg":"response completed","time":"2017-08-11T17:53:01Z"}

ui.log (Signed="V" green)

Aug 11 14:46:37 172.18.0.1 ui[860]: 2017/08/11 17:46:37 #033[1;34m[router.go:829][D] | GET        | /harbor/tags/2/lixo/nginx                | 1.142174ms       | match      | /harbor/tags/:id/*                       | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | GET        | /api/systeminfo                          | 5.158937ms       | match      | /api/systeminfo                          | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [WARNING] No user id in session, canceling request
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [WARNING] No user id in session, canceling request
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | GET        | /api/projects/2                          | 1.230149ms       | match      | /api/projects/:id([0-9]+)                | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [authutils.go:46]: scopes: [repository:hub.gs.rce.serpro/lixo/nginx:pull]
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [authutils.go:46]: scopes: [repository:lixo/nginx:pull,push,*]
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [authutils.go:87]: user: , access: &{repository  lixo/nginx [pull]}
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [authutils.go:87]: user: , access: &{repository  hub.gs.rce.serpro/lixo/nginx [pull]}
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [transport.go:50]: 200 | GET http://registry:5000/v2/lixo/nginx/tags/list
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [transport.go:50]: 200 | GET http://registry:5000/v2/lixo/nginx/manifests/1.9-trusted
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | GET        | /api/repositories/lixo/nginx/tags        | 48.47625ms       | match      | /api/repositories/*/tags                 | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [notification.go:102]: receive an event:
Aug 11 14:46:41 172.18.0.1 ui[860]: ----ID: cb146a58-9b73-460c-b23f-fb9932dbffb5
Aug 11 14:46:41 172.18.0.1 ui[860]: ----target: lixo/nginx:1.9-trusted
Aug 11 14:46:41 172.18.0.1 ui[860]: ----digest: sha256:311e9840c68d889e74eefa18227d0a6f995bc7a74f5453fdcd49fe3c334feb24
Aug 11 14:46:41 172.18.0.1 ui[860]: ----action: pull
Aug 11 14:46:41 172.18.0.1 ui[860]: ----mediatype: application/vnd.docker.distribution.manifest.v2+json
Aug 11 14:46:41 172.18.0.1 ui[860]: ----user-agent: Go-http-client/1.1
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | POST       | /service/notifications                   | 207.649µs        | match      | /service/notifications                   | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [transport.go:50]: 200 | GET http://notary-server:4443/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/root.json
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [notification.go:102]: receive an event:
Aug 11 14:46:41 172.18.0.1 ui[860]: ----ID: 3ec764d7-7f4f-494e-8cfa-77e3cbd1c49e
Aug 11 14:46:41 172.18.0.1 ui[860]: ----target: lixo/nginx:
Aug 11 14:46:41 172.18.0.1 ui[860]: ----digest: sha256:c8c29d842c09d6c61f537843808e01c0af4079e9e74079616f57dfcfa91d4e25
Aug 11 14:46:41 172.18.0.1 ui[860]: ----action: pull
Aug 11 14:46:41 172.18.0.1 ui[860]: ----mediatype: application/octet-stream
Aug 11 14:46:41 172.18.0.1 ui[860]: ----user-agent: Go-http-client/1.1
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | POST       | /service/notifications                   | 144.785µs        | match      | /service/notifications                   | #033[0m
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017-08-11T17:46:41Z [DEBUG] [transport.go:50]: 200 | GET http://notary-server:4443/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/timestamp.json
Aug 11 14:46:41 172.18.0.1 ui[860]: 2017/08/11 17:46:41 #033[1;34m[router.go:829][D] | GET        | /api/repositories/lixo/nginx/signatures  | 57.37092ms       | match      | /api/repositories/*/signatures           | #033[0m

ui.log (Signed="?" black)

Aug 11 14:52:57 172.18.0.1 ui[860]: 2017/08/11 17:52:57 #033[1;34m[router.go:829][D] | GET        | /harbor/tags/2/lixo/nginx                | 910.754µs        | match      | /harbor/tags/:id/*                       | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | GET        | /api/systeminfo                          | 3.852077ms       | match      | /api/systeminfo                          | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [WARNING] No user id in session, canceling request
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [WARNING] No user id in session, canceling request
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | GET        | /api/projects/2                          | 1.188834ms       | match      | /api/projects/:id([0-9]+)                | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [base.go:132]: No valid user id in session.
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [authutils.go:46]: scopes: [repository:hub.gs.rce.serpro/lixo/nginx:pull]
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [authutils.go:46]: scopes: [repository:lixo/nginx:pull,push,*]
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [authutils.go:87]: user: , access: &{repository  hub.gs.rce.serpro/lixo/nginx [pull]}
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [authutils.go:87]: user: , access: &{repository  lixo/nginx [pull]}
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [transport.go:50]: 200 | GET http://notary-server:4443/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/root.json
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [transport.go:50]: 200 | GET http://registry:5000/v2/lixo/nginx/tags/list
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [transport.go:50]: 200 | GET http://notary-server:4443/v2/hub.gs.rce.serpro/lixo/nginx/_trust/tuf/timestamp.json
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | GET        | /api/repositories/lixo/nginx/signatures  | 43.838634ms      | match      | /api/repositories/*/signatures           | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [transport.go:50]: 200 | GET http://registry:5000/v2/lixo/nginx/manifests/1.9-trusted
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | GET        | /api/repositories/lixo/nginx/tags        | 47.450899ms      | match      | /api/repositories/*/tags                 | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [notification.go:102]: receive an event:
Aug 11 14:53:01 172.18.0.1 ui[860]: ----ID: 6113ee63-4997-41ca-b4cb-c273bbb849cb
Aug 11 14:53:01 172.18.0.1 ui[860]: ----target: lixo/nginx:1.9-trusted
Aug 11 14:53:01 172.18.0.1 ui[860]: ----digest: sha256:311e9840c68d889e74eefa18227d0a6f995bc7a74f5453fdcd49fe3c334feb24
Aug 11 14:53:01 172.18.0.1 ui[860]: ----action: pull
Aug 11 14:53:01 172.18.0.1 ui[860]: ----mediatype: application/vnd.docker.distribution.manifest.v2+json
Aug 11 14:53:01 172.18.0.1 ui[860]: ----user-agent: Go-http-client/1.1
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | POST       | /service/notifications                   | 183.96µs         | match      | /service/notifications                   | #033[0m
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017-08-11T17:53:01Z [DEBUG] [notification.go:102]: receive an event:
Aug 11 14:53:01 172.18.0.1 ui[860]: ----ID: 1dbda1e1-5e98-4648-a746-7528a6090429
Aug 11 14:53:01 172.18.0.1 ui[860]: ----target: lixo/nginx:
Aug 11 14:53:01 172.18.0.1 ui[860]: ----digest: sha256:c8c29d842c09d6c61f537843808e01c0af4079e9e74079616f57dfcfa91d4e25
Aug 11 14:53:01 172.18.0.1 ui[860]: ----action: pull
Aug 11 14:53:01 172.18.0.1 ui[860]: ----mediatype: application/octet-stream
Aug 11 14:53:01 172.18.0.1 ui[860]: ----user-agent: Go-http-client/1.1
Aug 11 14:53:01 172.18.0.1 ui[860]: 2017/08/11 17:53:01 #033[1;34m[router.go:829][D] | POST       | /service/notifications                   | 173.711µs        | match      | /service/notifications                   | #033[0m

I have installed others Harbor v.1.1.2  with empty Database, and that issue is always present. I think that can be some timeout or a slow environment. I have a Xen VM with CentOS7 with 3 GB RAM and 2 vCPU installed, docker v1.13.1 and docker-compose v1.8.0.
Thanks.

Your have to upgrade DB firstly, please refer to the guide.

The issue always comes up, when an old DB or a new (clean Harbor) DB install.
And also, the migration tool do not work with my old DB from Harbor 0.5.0, many fails has occurred. So I have used this one.

the new harbor cannot run on the old DB scheme. Please upload the error log, make sure you get the latest vmware/harbor-db-migrator:1.2

So, I will open a new issue about DB migration (from 0.5.0 to 1.1.2), but that issue here occurred also in a new and clean environment.

This patch should fix the issue
https://github.com/vmware/harbor/pull/3025
Please try the latest code and let us know if you can still reproduce this issue.

Yeah, it´s working now!
But I could not directly apply this Patch cause my Harbor is v0.5.0, firstly I had to upgrade my Harbor to version 1.2.0-rc1 and also migrate  the Database. Then every thing is ok.

authors: gunboe wy65701436 yixingjia

repo: vmware/harbor


text:
Support applying labels to images from backend API side

Done by #4396.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Updated project publicity API

This patch changes the toggle project publicity API to remove the
existing publicity being passed from the UI to the DAO layer.
This makes the API replicate the toggling functionality, by
switching it from public -> private and vice versa without the need
to know the existing publicity.
References #2313

Coverage decreased (-21.8%) to 33.0% when pulling 5e9acc9e15b0c39f426d2734c19a1403019743c8 on srm912:update-project into 4b05c9eaf1b8063a9d728f6cf6675737e7847a05 on vmware:master.

@srm912 Sorry for the late reply, maybe we didn't communicate this clearly in the issue #2313, we want to put the parameter "publicity" in the body rather than in the path just like the standard REST API does. So the request should be like this:
PUT /api/projects/{project_id}
request body:
{
        "publicity": true,
}

Coverage decreased (-22.05%) to 32.801% when pulling 4d3b53f8501500168f26646fd014655c626f3841 on srm912:update-project into 0a75efbfce082895b7d3b5a2577b1005ea1c3d3e on vmware:master.

Coverage decreased (-22.03%) to 32.828% when pulling 4d3b53f8501500168f26646fd014655c626f3841 on srm912:update-project into 0a75efbfce082895b7d3b5a2577b1005ea1c3d3e on vmware:master.

Coverage decreased (-22.03%) to 32.828% when pulling 4d3b53f8501500168f26646fd014655c626f3841 on srm912:update-project into 0a75efbfce082895b7d3b5a2577b1005ea1c3d3e on vmware:master.

Coverage decreased (-22.02%) to 32.819% when pulling e1bc4379779825a97ac851131457453c613c3904 on srm912:update-project into 9bb6f7e7126036d001d0d689f8a3e5754f954e4e on vmware:master.

Coverage decreased (-22.0%) to 32.828% when pulling 3a39d808c8429d641705751f5be12f6a27b40c5a on srm912:update-project into 609f199c81a43ac1fac7f558047f5d7a313ae055 on vmware:master.

Closing due to inactivity.

source: gharchive/pull-request


text:
[Doc] Add Vagrant init instruction

This PR fix #120 issue.
Add Vagrant init instruction in README.md

@williamtu : does this look fine to you?

LGTM, thanks!

authors: hiroyuki-sato mbudiu-vmw williamtu


text:
feat: add pscredential and securestring

Summary
Enhanced Request-VCFToken and Connect-CloudBuilder by adding a PSCredential parameter set and adding support for SecureString for the Password parameter.
I've tested the following:
SDDC Manager
Request-VCFToken -Fqdn <fqdn> -UserName administrator@vsphere.local -Password <plainTextPassword>

Connects using password provided as a string.
$secureString = Read-Host -AsSecureString 'Password'
Request-VCFToken -Fqdn <fqdn> -UserName administrator@vsphere.local -Password $secureString

Connects using password provided via a SecureString.
Request-VCFToken -Fqdn <fqdn> -UserName administrator@vsphere.local

Will ask for a SecureString as password.
$credential = Get-Credential
Request-VCFToken -Fqdn <fqdn> -Credential $credential

Will connect using the PSCredential variable.
Request-VCFToken -Fqdn <fqdn>

Will ask for a PSCredential (username/password).
Cloud Builder
Connect-CloudBuilder -Fqdn <fqdn> -UserName admin -Password <plainTextPassword>

Connects using password provided as a string.
$secureString = Read-Host -AsSecureString 'Password'
Connect-CloudBuilder -Fqdn <fqdn> -UserName admin -Password $secureString

Connects using password provided via a SecureString.
Connect-CloudBuilder -Fqdn <fqdn> -UserName admin

Will ask for a SecureString as password.
$credential = Get-Credential
Connect-CloudBuilder -Fqdn <fqdn> -Credential $credential

Will connect using the PSCredential variable.
Connect-CloudBuilder -Fqdn <fqdn>

Will ask for a PSCredential (username/password).
Type

[ ] Bugfix
[x] Enhancement or Feature
[ ] Code Style or Formatting
[x] Documentation
[ ] Refactoring
[ ] Chore
[ ] Other
Please describe:

Breaking Changes?

[ ] Yes, there are breaking changes.
[x] No, there are no breaking changes.

Test and Documentation

[x] Tests have been completed.
[x] Documentation has been added or updated.

Issue References
A furthering of #116
Additional Information
N/A

Some changes and comments provided.

Hi @tenthirtyam, let me know if something else needs refinement before this PR is ready to merge 👍🏻

Rebased with origin/develop. Will review next week.

I've force-pushed a couple more changes to ensure each cmdlet uses the same structure and that the documenation is a match. e64714f

authors: erikgraa tenthirtyam


text:
Document the conventional commits

We can do that, but I thought to not diverge from the general practice - ref. https://www.conventionalcommits.org/en/v1.0.0/#summary
In that sense, the spec more or less combines everything dependency related under build.
Originally posted by @rdimitrov in https://github.com/vmware/repository-service-tuf-cli/pull/87#discussion_r999414210

Documentation CONTRIBUTING.rst

repo: vmware/repository-service-tuf

license: MIT


text:
vdk-core: fix flakey test in test checking logs output

Why?
We want to fix intermittent failures in tests. Specifically the described in https://github.com/vmware/versatile-data-kit/issues/1177.
What?
The underlying issue was that test_log_plugin was modifying the log level to warning.
the test test_run_dbapi_connection_no_such_db_type relies on it being INFO to pass.
There are two fixes to prevent this in the future

the log level is explicitly set at the start of the test test_run_dbapi_connection_no_such_db_type.
in the test test_log_plugin we revert the start back to info at the end of it.

How has this been tested?
Before my fix I was getting an error reasonably frequently during runs.
After I added my fix in I ran the pipeline many more times and never encountered the error again.
What type of change are you making?
Bug fix (non-breaking change which fixes an issue) or a cosmetic change/minor improvement
Signed-off-by: murphp15 murphp15@tcd.ie

We currently do not support really contributions from forks
because Gitlab CI is not triggered for forks (until https://github.com/vmware/versatile-data-kit/issues/854)
So you need to

I will now add you to list of maintainers
Create a PR from a branch.

We currently do not support really contributions from forks because Gitlab CI is not triggered for forks (until #854)
So you need to

I will now add you to list of maintainers
Create a PR from a branch.

Cool. How long does it take to add me to the list of maintainers?

repo: vmware/versatile-data-kit


text:
Call a service from an external application

Hi all,
I've a custom Endpoint.cs that do an import of some CSV files. Here is my code:

How can I call that method from an external application (so I have to let the method bypass the Login Authentication) ?
I also tried to call manually the service from my browser (like http://localhost:/Services/Common/Anagrafiche/methodName), but it gives me a 404 Error.
Thanks for your help and your time :)
Chiara

See if this can help you
https://github.com/volkanceylan/Serenity/issues/806
or
https://github.com/volkanceylan/Serenity/issues/1310

Thanks @Estrusco: I took a look at the two tickets and I add this attributes in my code:

But when I call the service from my browser, it still gives me a 404 error and I can't get to the method (there is a breakpoint).
Any ideas ??
Thanks all :)

hm! Maybe you need a controller to run?

Or do a start on the button, like Import from Excel

Thanks for your response @Zahar661 :)
I don't use a button because an external application called the URL that is connected to this method.
End user shoud not see this procedure.
I try to use a controller ...

Pay attention to AccountPage.cs, as the entry point, direct access to the Endpoint, it does not seem to work

A 404 means page is not found, not some server / permission error, make sure you are calling the correct URL

I solved that: I used a Controller with the Index() that call my custom method.
I share my code.

Thanks for your help @Estrusco,  @Zahar661 and @volkanceylan :)
Good Evening :)
Chiara

authors: Estrusco Zahar661 kjaraa volkanceylan

repo: volkanceylan/Serenity

license: mit

license_source: bigquery


text:
[Please Comment]: Serenity as mBaaS solution

Dear @volkanceylan,
I would like to see possibility of utilizing Serenity as Mobile Back-end since it creates API out of the Box
If we could add token authentication, social logins for the API it could become Mobile Backend Service just like Azure Mobile Services,
Although It Need some customization in regards to Offline Sync and Push Notification, Api calls logging per IP, Per User
Just thought, please comment / feedback about Idea

Hi Samdubey,
We are already using Serenity as mobile backend and have no problems. For other nice-to-have features, it could be, there are some plans, but not prioritized and i don't have a timeline.
Serenity will probably have a paid mobile version, though not decided yet.

Thanks for your views

authors: samdubey volkanceylan


text:
AshJason.Extension does not trigger when in use with AshJson API

I wanted to exclude some attributes from my user resource. I added this extension but it is not being triggered.
Here is my jason section in the user's resource
 jason do
    # pick %{sensitive?: false}
    # pick %{private?: false}
    # pick %{exclude: [:hashed_password]}

    customize fn result, _record ->
      IO.inspect(result) //Expect this line to be triggered and print to console
      # result |> Map.put(:custom_key, "custom_value")
      result
    end
  end

and the json api section
json_api do
    type "User"

    routes do
      base "/user"

      get :read
    end
  end

AshJsonApi does not call Jason.encode directly on a resource so it does not use Jason.Encoder implementation. It converts resource record to a map following its own rules and then encodes that map.
If you use AshJsonApi you most likely do not need AshJason. AshJason is when you do your own thing (with controllers or live views) and not relevant when you use apis like AshJsonApi or AshGraphql.
Hope it helps.

Thanks for the clarification

authors: briankariuki vonagam


text:
Entitás attribútumok

Üdvözletem!
A napokban telepítettem ezt a remekbe szabott kiegészítőt; Home Assistant alatt, HACS.-ban.
Home Assistent verzió: 2022.6.5
Kieg. verzió: v1.0.7
Az éppen futó műsort remekül jelzi.
Azonban az entitásokhoz tartozó attribútumok hiányoznak.
Feltételezem a HA verzió váltások okozta változások okozhatják a problémát.
Remélem van mód az integráció frissítésére, hogy a műsorújság is használhatóvá váljon.
Előre is köszönöm!
/Boros László

Szia, köszi hogy jelezted. Javítottam az 1.0.8-as verzióban.

authors: sonycim vorostamas

repo: vorostamas/portHuTV-homeassistant


text:
Added comments in the source code

I have added some comments in the source code (fs.js and mongo.js) from the backends folder. Hopefully this helps, let me know if you need me to change anything. Thank you.

Closing as the comments are pretty redundant and simply describe what each line is doing.
There are some JSDoc comments in the code which also explain usage and context - that's the style to follow.

authors: YuechengWu vot

repo: vot/dbclone


text:
issue with Progrommer Dvorak layout

Собрал по инструкции под Mac OS 10.10.3
Пользуюсь раскладкой Programmer Dvorak
При текущей раскладке pd выдает следующий id:
❯ issw
com.apple.keyboardlayout.Programmer Dvorak.keylayout.ProgrammerDvorak
При листинге:
❯ issw -l
com.apple.keylayout.RussianWin
com.apple.CharacterPaletteIM
com.apple.KeyboardViewer
com.apple.PressAndHold
com.apple.keylayout.US
com.apple.keyboardlayout.Programmer Dvorak
Как видно id для раскладки pd отличаются.
Подозреваю, что из-за этого не переключается раскладка в терминальной версии vim с установленным плагином Vim-xkbswitch
С графическим MacVim все работает

@wbauer, вы можете выбрать этот layout в терминале? К примеру, что в вашей системе вернут команды:
issw 'com.apple.keyboardlayout.Programmer Dvorak'
issw 'com.apple.keyboardlayout.Programmer Dvorak.keylayout.ProgrammerDvorak'

?
Дело в том, что вся эта история с раскладками клавиатуры не такая простая. Программа пытается эмулировать простейшую модель, на которую рассчитывает vim-xkbswitch. В OS X, есть понятие метода ввода и это совсем не раскладка. Как пример, вот, что может получаться:
$ ./Debug/issw -l
com.apple.keylayout.US
com.apple.keylayout.Russian
com.apple.CharacterPaletteIM
com.apple.KeyboardViewer
com.apple.PressAndHold
com.apple.50onPaletteIM
$ ./Debug/issw
com.apple.keylayout.US
$ ./Debug/issw com.apple.KeyboardViewer
com.apple.keylayout.US # <-- выбрали 'com.apple.KeyboardViewer' но показывается экранная клавиатура

Теоретически это не должно мешать плагину xkbswitch правильно работать, тем более, что как вы говорите, в GUI-версии всё работает корректно. Скорее больше похоже на проблему квотинга (т.к. в ID метода ввода присутствует пробел, кстати, ни в одной родной раскладке на MacOS X я пробелов в ID не обнаружил).
Попробуйте выбрать вашу раскладку с консоли как описано выше. Это может помочь понять в чём именно проблема.

@wbauer, судя по всему проблема в устройстве MacVim. Дальше теория, точно проверю в выходные когда время появится. Чтобы работало MacOS X API для получения текущего метода ввода, программа должна гонять стандартный цикл GUI приложения и получать оповещение от системы о сменах раскладки, иначе API (TISCopyCurrentKeyboardInputSource) возвращает инициализированное при старте приложения значение.
При работе в GUI-режиме, MacVim этот цикл запускает. При работе в консольном режиме, похоже, что нет... Поэтому возвращается всё время один и тот-же метод ввода.
Это объясняет всё, что происходит:

Неправильная работа плагина с issw
Переключение c заданными в конфиге языками
Работа с библиотекой от @myshov (т.к. эта библиотека просто вызывает консольную утилиту каждый раз)

Так же, вот немного на StackOverflow: http://stackoverflow.com/questions/26024400/osx-cocoa-input-source-detect-change

@wbauer, проверьте пожалуйста версию 0.3, проблема должна исправиться.

I will close the task because the problem should be fixed now and no further responses occur.

Отвечаю на вопрос от 17 мая:
~/tmp/input-source-switcher/build master
❯ ./issw 'com.apple.keyboardlayout.Programmer Dvorak'
Error: Cant find input source with id=com.apple.keyboardlayout.Programmer Dvorak
Usage: issw [-hlV] []
~/tmp/input-source-switcher/build master
❯ ./issw 'com.apple.keyboardlayout.Programmer Dvorak.keylayout.ProgrammerDvorak'
com.apple.keyboardlayout.Programmer Dvorak.keylayout.ProgrammerDvorak

Подтверждаю с версией 0.3, работает и консольной версии MacVim

@wbauer

Подтверждаю с версией 0.3, работает и с консольной версией MacVim

Спасибо! Значит баг действительно состоял в особенностях работы API выбора источников ввода от Apple.
И из предидущего комментария следует, что выбор работает, раскладка Programmer Dvorak выбирается по id=com.apple.keyboardlayout.Programmer Dvorak.keylayout.ProgrammerDvorak
Большое спасибо за то, что потратили время на описание ошибки и проверку!

authors: vovkasm wbauer

repo: vovkasm/input-source-switcher


text:
[FR] Allow protecting datasets from deletion

Proposal Summary
Similarly to Dataset.persistent which prevents a dataset from being deleted when the database is shutdown, a Dataset.protected which would prevent a dataset from being deleted (e.g. with Dataset.delete()) would be nice.
What areas of FiftyOne does this feature affect?

[ ] App: FiftyOne application
[x] Core: Core fiftyone Python library
[ ] Server: FiftyOne server

Willingness to contribute

[ ] Yes. I can contribute this feature independently
[x] Yes. I would be willing to contribute this feature with guidance from the FiftyOne community
[ ] No. I cannot contribute this feature at this time

Definitely makes sense! So much so that we built a fully fleshed out concept of user roles and dataset permissions into FiftyOne Teams that provides fine-grained control over who can do what, and when 😄
With FiftyOne Open Source, we're targeting individual usage on datasets stored locally. So, while I certainly grok that, even as a team of 1, it can be useful to have a way to protect a dataset from accidental deletion, you'd still have full control to do other large edits:
dataset.clear()
dataset.add_samples(lots_of_samples)
dataset.delete_sample_fields(lots_of_fields)

so protecting deletion specifically feels a bit too close to dataset permissions in FiftyOne Teams.
One potential middle ground that we've discussed adding to FiftyOne Open Source is dataset.read_only = True, which would prevent all edits.


text:
Allow overriding user and group used

Pull Request (PR) description
This PR adds two parameters to the base class, $user and $group, so one can specify which user and group should be used to run Nomad. This would allow one to run the Nomad server with a seperate user, as per upstream's recommendation: https://developer.hashicorp.com/nomad/docs/install/production/requirements#user-permissions
I used root as default for both parameters to not break people's existing workflows.
This Pull Request (PR) fixes the following issues
Fixes #66

I amended my commit and added some tests

can you explain what kind of jobs you run with nomad? I am wondering if it makes sense for the next major release to switch to a nonroot default user.

can you explain what kind of jobs you run with nomad? I am wondering if it makes sense for the next major release to switch to a nonroot default user.

At this moment nothing yet, we're still in the experimental/setup phase :) When reading Nomad's documentation [1], I think client/worker nodes need to be run as root, while the server/scheduler nodes can be run as another user.
[1] https://developer.hashicorp.com/nomad/docs/install/production/requirements#user-permissions

It works quite well , if using for example Docker and adding the nomad user to the docker group. It fails for sure, if you use things like Consul "connect", as it requies iptables etc. pp.

authors: bastelfreak jonasdemoor linuxmail

repo: voxpupuli/puppet-nomad


text:
c3.js was removed from the layout.html template but is required for certain facts

The c3 JS files required to render a graph only get pulled in if DAILY_REPORTS_CHART_ENABLED is set to true: https://github.com/voxpupuli/puppetboard/blob/15e2fc80c09ccf187dc901626dba28b1ec20ceb7/puppetboard/templates/node.html#L8
The facts.html template doesn't care about that and attempts to render the graph if render_graph is set to true: https://github.com/voxpupuli/puppetboard/blob/master/puppetboard/templates/fact.html#L11
render_graph gets set irregardless of the DAILY_REPORTS_CHART_ENABLED setting: https://github.com/voxpupuli/puppetboard/blob/master/puppetboard/app.py#L678
So if DAILY_REPORTS_CHART_ENABLED is not set (the forge module for puppetboard doesn't set this value by default) then going to any of the facts in list of default facts fails to load as c3 doesn't exist.
render_graph should only get set to true if DAILY_REPORTS_CHART_ENABLED is also set to true or including c3 shouldn't rely on DAILY_REPORTS_CHART_ENABLED and just always happen.

Actually I lied, that setting only applies to the node.html template. I wasn't paying attention.
layout.html had c3 removed: https://github.com/voxpupuli/puppetboard/commit/e08ede01c77edb7510f9f3615e5cc6fdf099a506
It is required for these fact pages.

Quick fix is to set GRAPH_FACTS to an empty array.

This appears to be what is causing #520.

I've confirmed that reverting #e08ede0 allows graphs to load.

#519 is the same issue for sure. I did some searching but missed that. Thanks for pointing that out. I shall close this issue.

repo: voxpupuli/puppetboard


text:
Switch, Snackbarを作成

Dstで実装したものを移行しただけですmm
https://deploy-preview-49--ingred-ui.netlify.app/

@noronaoki
このPRでSWITCHにツールチップが追加されるのですが、矢印の位置がnoroさんの意図通りかご確認いただきたく...:bow:
https://deploy-preview-49--ingred-ui.netlify.app/

font-sizeも14pxから12pxに修正してます

@yutaro1031
これも設置場所によってはツールチップの表示位置がいい感じに調整される？（画面縮めたけど勝手に動いてくれなかったけど）

@noronaoki

これも設置場所によってはツールチップの表示位置がいい感じに調整される？（画面縮めたけど勝手に動いてくれなかったけど）

<Switch />ないで書いている<Tooltip />の引数を変えれば動くはずです。

@yutaro1031
なるほど、そしたらLGTMでーす

@yutaro1031
過去に聞いてたら申し訳ないんだけど、そもそもDropdownButtonをPortal経由で出してるのってなんでだっけ？

@kinokoruumu

過去に聞いてたら申し訳ないんだけど、そもそもDropdownButtonをPortal経由で出してるのってなんでだっけ？

は、下記が理由ですね↓

<Portal />を経由しない場合は、後に表示される要素が上にきてしまう

厳密にいうと、<Portal />経由で表示しているのは<DropdownButton />内の<MenuList />ですね。

@yutaro1031

を経由しない場合は、後に表示される要素が上にきてしまう

これって問題あるんだっけ？
Modalとかは全体手前に来ないとだめだからPortal使うんだけど、ButtonのMenuはその上に要素重なっても問題ない気がする

@kinokoruumu
<Portal />経由しないようにして、雑に作ってみました。

          <Flex display="flex" flexDirection="column">
            <DropdownButton
              contents={[
                {
                  text: "メニュー1",
                  onClick: () => {},
                },
                {
                  text: "メニュー2",
                  onClick: () => {},
                },
              ]}
            >
              ボタン
            </DropdownButton>

              <DropdownButton
                contents={[
                  {
                    text: "メニュー1",
                    onClick: () => {},
                  },
                  {
                    text: "メニュー2",
                    onClick: () => {},
                  },
                ]}
              >
                ボタン
              </DropdownButton>

          </Flex>

仮に↑から
を取り除いた場合、問題なく表示されますが、下側の<Icon />は浮いて表示されます。
結構起こりそうな事象なので、必要な気がしているのですが、どうでしょう...:thinking:

relativeを置くなら意図的にlayerを操作してるから大丈夫な気がする
<Icon/>が手前にくるのはIcon側のabsoluteだと思うから別問題かな？
例えばモーダルのz-indexを1000
ドロップダウンのz-indexを2000とした場合、
ドロップダウンを開いた状態でモーダル起動したらMenuだけ浮いてる感じにならないかな？
(まぁこれに関してはClickAwayListenerが入ればおこらなそうだけど)
もしz-indexが逆だとモーダル内でドロップダウンが使えなくなる。

↑どうだろう？
@yutaro1031

authors: kinokoruumu noronaoki yutaro1031

repo: voyagegroup/ingred-ui


text:
i18n: add Chinese and Japanese language support for message box

feat: add Chinese and Japanese language support for message box

Add translations for dialog content in zh-CN and ja-JP
Previously English only

Oh this is great to see, this has been on mine and few other peoples todo list for a long time.

repo: vrcx-team/VRCX


text:
Update Posts “rich-content-with-mdx”

Automatically generated by Netlify CMS

👷 Deploy Preview for gleeful-eclair-104d42 processing.

Name
Link

🔨 Latest commit
9119b47c4388f228b37dfb8b9091b4365b17c907

🔍 Latest deploy log
https://app.netlify.com/sites/gleeful-eclair-104d42/deploys/6437a21eb7dbb200073320f0

repo: vrepsys/decap-cms-blog


text:
Update dependencies

Fixes #2165
Changes proposed:

[x] Fix

PR fixes the issue with the integrity check on Windows by updating nsri. Since we update dependencies I figured we do all.

repo: vscode-icons/vscode-icons


text:
Fix receiving of binary data with unknown length.

This commit adds the ability to receive data in binary format with undefined length. To determine the end of the data block, the character interval is used. This is the most expected behavior when receiving data, because it allows you to receive blocks of data in the format in which they were transmitted. Without this commit, ingestion occurs before the buffer is filled with the expected number of bytes, which is almost always useless. More detailed description is here:
http://unixwiz.net/techtips/termios-vmin-vtime.html

In most embedded applications involving serial ports, I've refrained from and didn't have the luxury of depending on character time to frame messages, and instead relied purely on protocol delimiters or message headers. But this is an interesting feature, and I can imagine it being useful in several contexts (actual TTYs, NMEA, etc.). I'll have to take a closer look, but ideally, I'd like to merge it while preserving as much of the existing functionality and timeout semantics of read() as possible.

You variant does not pass simple test - send data throw serial ports, even they are emulated or hardwired - its splits data blocks on unpredictable way.

I'm curious, aside from an interactive terminal, do you have an example of this kind of application that uses the serial port intercharacter timeout for framing? I thought gpsd might use it, but it appears that even it opens the serial port in O_NONBLOCK, where VTIME and VMIN are ignored, and reads chunks as they arrive.
I'm not aware of pyserial's approach or history with reads, but the current read implementation in python-periphery is no different than what you would find for a stream socket or a Unix pipe, where the application is expected to frame messages by headers or delimiters in the data stream, not by timing. python-periphery is written in the context of interfacing with external peripherals via UART, SPI, I2C, etc. busses on an embedded system, where protocols with such headers and/or delimiters are very common. I'm not sure I follow your comment about the limited range of character code values -- the Serial module should allow reading and writing raw binary data, with the exception of XON/XOFF control codes if software flow control is enabled.
That being said, I still intend to merge this PR into python-periphery, as it is a better and more flexible timeout mechanism, though I will make some modifications to ensure it can be used in a backwards compatible way with the more naive timeout when VTIME and VMIN are not configured.

authors: vsergeev xrombik

repo: vsergeev/python-periphery


text:
Generate imports

This is a related, but different feature than discussed in vshaxe/vshaxe#2. It should be much easier to actually implement.
haxe-sublime-bundle has a neat feature that allows you to type a fully qualified type path, then press a key combo and have an import statement generated at the top of the file:

It does simple text processing trying to guess what to actually import, it supports simple module and type imports and can have a number of false positives, but it's still very useful.
It would be cool to have the same in vshaxe, but to get it right, I'm afraid we need some compiler support. In Haxe we might want to:

import a whole module
import a type from a module
import a static from a class
import everything from a package or all statics from a class (though these use cases are more rare)

To determine what options do we have and what to actually import (e.g. "is this a main module type? a type within a module? a static field of a class?") we need a display query that tries to resolve a given dot-path and gives us info about it.

I just did a refactoring that separates code actions from diagnostics so that we can have different code actions providers. One of those providers could be this feature!

Can this be closed or is there something left to do?

I still haven't looked into what's currently implemented :)

It's missing these two I guess:

import a static from a class
import everything from a package or all statics from a class (though these use cases are more rare)

Can we have this disable by default? :)

@ncannasse Considering that due to being a code action, this is already behind a shortcut, I'm not sure what you'd want to disble here.

@Gama11 most of the IDE do some automatic replacements without code action for this feature

Ah, you mean auto-import. There's another issue for that, and it's not implemented yet: https://github.com/vshaxe/vshaxe/issues/2
I wouldn't want that to be disabled by default when it's implemented though.

I wouldn't want that to be disabled by default when it's implemented though.

I would, that feature is obnoxious...

Moved to https://github.com/vshaxe/vshaxe/issues/97.

authors: Gama11 Simn nadako ncannasse

repo: vshaxe/haxe-languageserver


text:
A design issue

The socket docs state:

The native socket address format of the socket module is an opaque data type returned by getaddrinfo function, which must be used to resolve textual address (including numeric addresses).

The example script re-iterates this:

You must use getaddrinfo() even for numeric addresses

This would seem to have a number of consequences.

On some ports async getaddrinfo may need to provide this opaque data. In every case I've seen the synchronous getaddrinfo returns a dotted quad, but the docs are specific on this. A query to @dpgeorge may be needed to resolve this.
Async getaddrinfr needs to handle dotted quads as input. Currently it fails if passed a dotted quad. The network module does this here.
If async getaddrinfo is to follow this rule it must use sync getaddrinfo which is absurd. This may be another reason to use the network's own DNS server.

The reason for point 2 is as follows. An application (such as async MQTT) reads a config file containing a network address. This is either a dotted quad for a local server or a domain name for a server on the internet. Currently it calls getaddrinfo with the passed address and uses the opaque result to connect.

Implementing aiodns.getaddrinfo via a call to socket.getaddrinfo may actually be a good idea.
In this case address will be resolved to IPv4 or IPv6 string, and then passed to getaddrinfo for final result. It requires further investigation.
From the practical standpoint, I've been able to use aiodns without issues on several ports. I'll update the example so it actually demonstrates the socket connection.

I agree: in every case I tested socket.getaddrinfo produced a dotted quad. However the docs are explicit on this point, and Damien is very thorough. I am convinced there is a good reason for the statement. It does need clarification for anyone writing a replacement.
The reason I am so interested in aiodns is that the need for it has been recognised for years and has been acknowledged by Damien. A few years ago I looked into writing an async DNS but the task defeated me. There may be scope for official adoption of aiodns if it can be made fully compliant with the synchronous version.

On some ports async getaddrinfo may need to provide this opaque data. In every case I've seen the synchronous getaddrinfo returns a dotted quad, but the docs are specific on this.

On the unix port, it returns an opaque binary data blob, eg:
MicroPython v1.24.0-preview.361.g43b05afdf on 2024-09-26; linux [GCC 14.1.1] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import socket
>>> socket.getaddrinfo('micropython.org', 80)
[(2, 1, 6, None, bytearray(b'\x02\x00\x00P\xb0:w\x1a\x00\x00\x00\x00\x00\x00\x00\x00')), (2, 2, 17, None, bytearray(b'\x02\x00\x00P\xb0:w\x1a\x00\x00\x00\x00\x00\x00\x00\x00')), (2, 3, 0, None, bytearray(b'\x02\x00\x00P\xb0:w\x1a\x00\x00\x00\x00\x00\x00\x00\x00'))]

It's anyway good practice to (a) always use getaddrinfo() even if you're just passing in an IP (v4 or v6) address; (b) treat the output of getaddrinfo() as opaque.  Although CPython is more flexible here, this approach is compatible with CPython.  That said, MicroPython does on most (all?) bare-metal ports allow you to pass in dotted-IP notation into, eg, socket.connect(), ie you don't need to use getaddrinfo() there if it's already a resolved IP address.
Anyway, @peterhinch 's point (2) above certainly needs to be followed.
Now that I revisit this issue, I remember that lwIP already includes a non-blocking DNS resolver.  That's actually what MicroPython uses, it's just that, to make it CPython-compatible and blocking, it waits for a result before returning from getaddrinfo():
dns_gethostbyname_addrtype(..., lwip_getaddrinfo_cb, ...);
// lwip_getaddrinfo_cb will set a status when it's called

// in the meantime we just wait for that, ie block
            while (state.status == 0) {
                poll_sockets();
            }

I think we should just expose this lwIP functionality in a non-blocking API to the Python code (because, eg, it uses lwIP's internal address cache).  The hard question then is (as usual) how to design the API for this, what it looks like.  There needs to be some C functions that start the query, poll for it to complete (in a way that can hook into asyncio) and then get the result.

That'd be great, however for now aiodns serves the purpose.
We can easily ditch aiodnw if/when:

async api is provided for the builtin DNS resolver
builtin DNS resolver is able to work with multiple DNS servers (on multiple interfaces)

For me, it just means i should probably settle on the minimalistic implementation (as it is), instead of investing too much time into a module that will get deprecated rather soon.

I believe I have implemented the fix for this issue, and tested it with the Unix port.
Feel free to comment and/or continue the discussion.

And yes, this means we're implementing aiodns.getaddrinfo via some calls to socket.getaddrinfo.
But I think it should be fine :)

@peterhinch WDYT? is it a feasible solution?

Using aioprof is much more simple to setup, I'll try it.
I assume that socket.getaddinfo doesn't need to perform any I/O to resolve the numerical addresses.
Technically even 2+2*2 is a blocking operation..

Blocking

Technically even 2+2*2 is a blocking operation..

Quite: "nonblocking" is a convenient shorthand for minimally blocking. All tasks block in the interval between yielding to the scheduler. The acceptable duration of blocking depends on the application. It's blocking I/O which is the killer as blocking can be lengthy (in the limit the duration of a timeout).

I assume that socket.getaddinfo doesn't need to perform any I/O to resolve the numerical addresses.

If this is correct I'm sure blocking will be minimal (< 5ms max).
Default behaviour
My preference would be for the nonblocking getaddrinfo to return exactly the same results as the blocking version. This implies:

Able to cope with numeric address.
By default it uses only the network DNS server. Allow the user to add servers.

I have written a simple script that uses aiorepl to enable a comparison of the two versions:
--> await dns('google.com',80)
[(2, 1, 0, '', ('172.217.169.46', 80))]
[(2, 1, 0, '', ('142.250.187.238', 80)), (2, 1, 0, '', ('142.250.200.46', 80)), (2, 1, 0, '', ('172.217.169.46', 80))]

--> await dns('hinch.me.uk', 80)
[(2, 1, 0, '', ('217.160.0.225', 80))]
[(2, 1, 0, '', ('217.160.0.225', 80))]

--> await dns('192.168.0.10', 80)
[(2, 1, 0, '', ('192.168.0.10', 80))]
OSError: Failed to resolve 192.168.0.10
--> await dns('alflgh.com', 80)
Site alflgh.com not found.
OSError: Failed to resolve alflgh.com

On my network, where a host can't be resolved, the synchronous version returns an error immediately, whereas the async version pauses for a while.
Script:
import asyncio
import aiodns
import socket
import aiorepl

async def dns(site="micropython.org", port=443):
    try:
        print(socket.getaddrinfo(site, port))
    except OSError:
        print(f"Site {site} not found.")
    info = await aiodns.getaddrinfo(site, port)
    print(info)
    print()

async def main():
    repl = asyncio.create_task(aiorepl.task(globals()))
    dnstask = asyncio.create_task(dns())
    await asyncio.gather(repl, dnstask)

asyncio.run(main())

General note
On past experience I doubt an official version will emerge for a while. This was first discussed several years ago.

I assume that socket.getaddinfo doesn't need to perform any I/O to resolve the numerical addresses.

I've looked into this and I think I know what's going on, the call to socket.getaddrinfo can be considered "blocking" or "non-blocking" depending on the address type and if the address is already cached:

dotted - numerical address e.g. 192.168.1.1 --> non-blocking
www-domain name e.g. www.micropython.org --> blocking first time (DNS query), non-blocking if cached
hostname.local e.g. myserver.local --> blocking first time (mDNS query), non-blocking depending on the port (unix port seems to have mDNS cache, esp32 port does not, so it is blocking every time 😞)

LwIP DNS docs https://www.nongnu.org/lwip/2_0_x/group__dns.html#ga1e040ec38166dc9bfcc3473aab0c799f
Test

import socket
import time

hosts = [
    "192.168.1.1",
    "myserver.local", # change to a local server
    "www.google.com",
    "www.micropython.org",
    "esp32.local", # change to a local device
]

def tzero():
    return time.ticks_us()

def tdiff(t0):
    return time.ticks_diff(time.ticks_us(), t0)

def timed_gaddrinf(hostname):
    _t0 = tzero()
    _addr = socket.getaddrinfo(hostname, 80, 0, socket.SOCK_STREAM)
    _td = tdiff(_t0)
    return (_td / 1e3, hostname)

def run(hosts=hosts):
    results = []
    for host in hosts:
        results.append(timed_gaddrinf(host))

    results.sort()
    for _td, hostname in results:
        print(f"{hostname:<20} --> {_td:6.3f} ms")

if __name__ == "__main__":
    run()

Results
unix
1st
$ micropython test_getaddrinfo.py
192.168.1.1          -->  0.626 ms
www.micropython.org  -->  1.052 ms
www.google.com       --> 34.134 ms
esp32.local          --> 196.107 ms
myserver.local       --> 441.455 ms

2nd
$ micropython test_getaddrinfo.py
esp32.local          -->  0.531 ms
www.google.com       -->  0.560 ms
www.micropython.org  -->  0.587 ms
192.168.1.1          -->  0.866 ms
myserver.local       -->  1.091 ms

esp32
1st
>>> import test_getaddrinfo
>>> test_getaddrinfo.run()
192.168.1.1          -->  1.724 ms
www.google.com       --> 45.815 ms
myserver.local       --> 86.488 ms
www.micropython.org  --> 368.633 ms
esp32.local          --> 403.109 ms

2nd
>>> test_getaddrinfo.run()
www.micropython.org  -->  0.678 ms
www.google.com       -->  0.840 ms
192.168.1.1          -->  1.397 ms
myserver.local       --> 174.854 ms
esp32.local          --> 305.592 ms

In this case lwip DNS resolver supports mDNS queries see (https://docs.espressif.com/projects/esp-idf/en/v5.2.3/esp32/api-reference/kconfig.html#config-lwip-dns-support-mdns-queries)
however esp32/modsocket.c has its own mdns_getaddrinfo following  https://github.com/micropython/micropython/pull/13398

Fixes inconsistency where previously querying mDNS local suffix (.local)
hostnames returned results with socket type 0 (invalid), but all other
queries returned results with socket type SOCK_STREAM (regardless of
'type' argument).

which I guess is why there is no .local name cache. 🤔

aiodns now supports mDNS (Multicast DNS) name resolution. This was surprisingly easy as it basically follows the same protocol (so code increase is negligible)

authors: Carglglz dpgeorge peterhinch vshymanskyy

repo: vshymanskyy/aiodns


text:
Feature Request: allowed-tags

Essentially the opposite of no-restricted-tags; only tags defined in this rule's array can be used.
"allowed-tags": [ "on", { "tags": [ "@foo" ] } ]

@foo
Scenario: This will pass validation

@bar
Scenario: This will fail validation

not sure what you need...

sprry, didnt mean to link to anyone

I think it's ambiguous; do you need...?.

those tags must aply to every scenario
just those tags ara avalaible

For example:
"allowed-tags": [ "on", { "tags": [ "@foo",  "@other_tag"] } ]
Scenario: without tags
1: error, there is no tag "foo", neither "other_tag"
2: success
@foo
Scenario: only with tag foo```
1: error, there is no tag "other_tag"
2: success

@not_listed_tag
Scenario: not listed tag```
1: error, there is no tag "foo", neither "other_tag"
2: error, tag "not_listed_tag" is not a valid tag

@josemenveg My thought was #2; just those tags are available for use (not that they must be used).  I thought it would be easier to maintain a small list of acceptable tags rather than an infinitely expanding list of unacceptable tags.

Released with 2.12.0

authors: ajthesnare bar josemenveg vsiakka

repo: vsiakka/gherkin-lint

license: isc


text:
Updated links

Description

Updated links and removed some outdated libraries

          2 Warnings

:warning:
Too many changes (when adding, please keep it to one project per Pull Request)

:warning:
Found 2 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

4
302
https://triplebyte.com/a/azelHFa/d redirects tohttps://triplebyte.com/

1611
Dupe
https://github.com/facebook/facebook-ios-sdk

  Generated by :no_entry_sign: Danger

authors: danger-awesome-ios lfarah

repo: vsouza/awesome-ios


text:
better convergence of compute_jumps

TLDR: Two passes of compute_jumps() is not sufficient.
Consider the following sequence of instructions (assuming Python 3.6 / wordcode):

Label1:
JUMP_ABSOLUTE Label2
...126 instructions...
Label2:
NOP

On first pass of compute_jumps(), Label2 will be at address 254, so that value encodes into the single byte arg of JUMP_ABSOLUTE.  All is well.
Now imagine instead that one of the intervening "...126 instructions..." needed to have an EXTENDED_ARG prepended to it.  So the initial pass of compute_jumps() will return True (i.e. modified).  So we call compute_jumps() again...
Now during this second pass of compute_jumps(), Label2 is seen to be at address 256, so the offset from "JUMP_FORWARD Label2" is 256 and cannot be encoded in a single byte, so...  we prepend EXTENDED_ARG, remember that we modified that code, return True, and then...
The calling code in to_concrete_bytecode() raises if the second compute_jumps() also has modifications.
Clearly more than two passes can be necessary.
You could arrange this scenario pre-wordcode as well, but since the jumps have 16 bit offsets you need a much larger function before this becomes a problem.
Given the current algorithm of just calling compute_args() until it converges, it needs to be called more than twice.  I'm not sure what the upper limit could be.  But I'm not comfortable with it iterating forever, so I changed the upper limit to 10 passes before it raises.
I think ultimately this should probably have a better algorithm that doesn't need to iterate over every instruction until it converges on a solution, but I haven't read compile.c yet to see how it's done there.

Codecov Report

Merging #27 into master will not change coverage.
The diff coverage is 75%.

@@           Coverage Diff           @@
##           master      #27   +/-   ##
=======================================
  Coverage   93.22%   93.22%
=======================================
  Files          17       17
  Lines        2481     2481
=======================================
  Hits         2313     2313
  Misses        168      168

Impacted Files
Coverage Δ

bytecode/concrete.py
94.29% <75%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d3f9470...246967b. Read the comment docs.

I think I agree with your analysis here, but I would like to see a test for this (even if it is limited to wordcode). Could you add one ?

Not sure how you feel about my addition of _ConvertBytecodeToConcrete.max_compute_jumps_steps.  I prefer to test the failure case, and without polluting the public API with hooks to set up the failures.

Wouldn't be problems with a code like
script = "if x: x\n%selse: %r" % ("elif x: x\n"*100, list(range(128)))

?

@serhiy-storchaka I am not sure it is related. The point of this code is to compute the offset for the relative jumps, that requires multiple passes simply because in some cases the addition of EXTENDED_ARG because some jumps are large can modify the offsets. As a consequence (and as noted in CPython source (https://github.com/python/cpython/blob/master/Python/compile.c#L5274)), it is expected to converge quickly.
@SnoopyLane could you test @serhiy-storchaka case, out of curiosity ?

I agree with your review comments.  But before I push yet another change, let me ask this...
Since compile.c has no limit (as you've pointed out twice now :-), what if I remove the limit from my changes?  Frankly, I'm not fond of that, I think there should be a limit in compile.c.  But git blame says that has been there for at least years.
Removing any limit has the upside of matching the logic in compile.c (arguably just as bad as good), but also simplifying my change to concrete.py, simplifies the test, and of course removes the need to expose a way for the tests to hammer the behavior.
Also, I'm not sure what the theoretical worst case could be.  I'm not convinced that it's not something on the order of (2**offset) / sizeof(jump_instruction).  I.e. 256/2 on wordcode, or 65536/3 on bytecode.  But I confess that I haven't spent time thinking about that case, nor trying to find old discussion around the code in compile.c.   I think, just for fun, I shall attempt to build a bad case later today.

I am not a big fan of the idea of having absolutely no limit. Furthermore sometimes people do surprising things when modifying the bytecode and can encounter cases rarely seen in usual Python code, which could infinitely loop. So I believe it is reasonable to have a limit (in addition we do expect that the process converges quickly in most cases).
However if we worry that we may have set it too low, we could add a keyword-only argument to to_concrete_bytecode to let people easily change the limit. In which case the detailed explanation could be a note in the docstring.

I made changes addressing your review comments, but no more.
Before raising the number, or allowing it to be changed as you suggest, I want to spend some time investigating not just worst theoretical case but also some practical examples.

Make sense. Keep me posted about your progress.

FYI:  I have a new test the demonstrates that there is no limit to the number of passes.  It's limited only by the size of the input code.  I'm going to follow your suggestion of making the number of loops controllable via keyword argument, then push those changes.
I'll also change the default number to something smaller than I currently have (129).
For an additional datapoint, I hacked my copy of cpython to record the number of iterations needed in compile.c, then rm'd all the .pyc files, then run cpython's unittests.  A few tests needed 5 passes, but that was the maximum.  Not that unittests are a torture-test for this kind of thing, but I thought it an interesting datapoint.

I just pushed a set of changes that provide:

Test that requires 385 iterations of compute_jumps.  I think this serves as demonstration that the number of passes is bounded only by the input size.
Control the limit via keyword argument as you suggested earlier.
Doc changes for the keyword argument (separate commit).

I only just saw your comment about documenting the 5 passes needed for unit tests.  Let me ponder the wording for a bit.  That number "5" certainly isn't contractual and I don't want the docs to suggest to somebody that they should base any decisions on that.

I gave a quick look at your changes and they look really good. The number five may be added in the api docs when you mention that it converges quickly most of the time and give the example of the Python test suite.

Final doc tweak pushed with 172199ab.  Unless your review spots problems I would like to put this to get this merged an move on.

Not sure how I missed that in the spell checker.

No problem I will merge later today. Thanks again for your great work on this.

authors: MatthieuDartiailh SnoopyLane codecov-io serhiy-storchaka

repo: vstinner/bytecode


text:
Clang build issue: Undefined symbols for architecture x86_64 _IOPSGetTimeRemainingEstimate

Sorry for spamming issues, but after solving the first two issues and adding openssl include dir to INTERFACE_INCLUDE_DIRECTORIES I get the following:
[ 84%] Linking CXX executable monero-lws-admin
Undefined symbols for architecture x86_64:
  "_IOPSGetTimeRemainingEstimate", referenced from:
      cryptonote::miner::background_worker_thread() in libcryptonote_basic.a(miner.cpp.o)
      cryptonote::miner::on_battery_power() in libcryptonote_basic.a(miner.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/monero-lws-admin] Error 1
make[1]: *** [src/CMakeFiles/monero-lws-admin.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Adding
list(APPEND IMPORTED_MONERO_LIBRARIES "-framework IOKit")

to the CMakeLists file solved this for me.

This worked for me too.

authors: LeoNero selsta

repo: vtnerd/monero-lws


text:
为什么 暗黑模式禁用了???

Question （问题描述）
How to use component s-table paging
为什么 暗黑模式禁用了???   ant design pro。vue
Describe the solution you'd like （你期待的是什么？）
A clear and concise description of what you want to happen.
Additional context（附加信息）
Add any other context or screenshots about the feature request here.

因为没实现

repo: vueComponent/ant-design-vue-pro


text:
npm WARN invalid config loglevel="notice"

I just built a brand new project, and when I run npm run build I get the error below.
Please feel free to close this if it's not the appropriate place to report- maybe it's caused by one of my packages?
npm WARN invalid config loglevel="notice"
npm: 5.6.0
vue-cli: 2.9.1

Google says that "This bug seems to be caused by installing a dependency that depends on an old version of NPM". (source).
Running npm config set loglevel warn might solve the issue, which I think is not related to vue-cli or this template.
Hope it helps!

This does not affect running or build, and it's likely not related to template itself, so closing this for now.

authors: afontcu gtalarico

repo: vuejs-templates/webpack


text:
[BUG]  vModel 修饰符不能动态

🐛 Bug description
 v-model={[dataRef.value, 'value']}

📝 Steps to reproduce
v-model argumens 无法动态，如静态变量承接都会引起 update:XX 函数是 undefined
🏞 Desired result
const xx = 'value'
 v-model={[dataRef.value, xx]}

🚑 Other information

#642

vue-macros already supports dynamic argument

repo: vuejs/babel-plugin-jsx


text:
Uncaught error when using top-level await in

Version
3.2.30
Reproduction link
stackblitz.com
(Uncomment line 11 in App.vue)
Steps to reproduce

Create default Vite + Vue app
Use a top-level await in a component's

Please read the yellow warning box in the docs section that you linked to.
Await is only supported in components that are nested in a Suspense component.

Thanks. Perhaps it would be helpful to use such as the error message in this case, rather than the current encouragement to file an issue on what is "likely a Vue internals bug".  Likewise, the docs example showing the use of top level await could easily include a corresponding example template below that shows a valid use of suspense. By the way, I tried using suspense and it still doesn't seem to work, but I found I could get by for now without the await.

We have an open issue for that, agreed

authors: LinusBorg NoahStahl

repo: vuejs/core


text:
pnpm run build  command failed in local

Vue version
3.4.0-beta.2
Link to minimal reproduction
https://github.com/vuejs/core
Steps to reproduce
run pnpm run build command in terminal
What is expected?
it should build successfully, and generate files in packages/vue/dist folder
What is actually happening?
[!] RollupError: "TriggerOpTypes" is not exported by "packages/reactivity/src/operations.ts", imported by "packages/reactivity/src/effect.ts".
https://rollupjs.org/troubleshooting/#error-name-is-not-exported-by-module
packages/reactivity/src/effect.ts (2:9)
1: import { TrackOpTypes, TriggerOpTypes } from './operations'
2: import { extend, isArray, isIntegerKey, isMap, isSymbol } from '@vue/shared'
^
3: import { EffectScope, recordEffectScope } from './effectScope'
System Info
System:
    OS: macOS 14.1.1
    CPU: (8) arm64 Apple M1
    Memory: 363.48 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.14.2 - ~/.nvm/versions/node/v18.14.2/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.5.0 - ~/.nvm/versions/node/v18.14.2/bin/npm
    pnpm: 7.28.0 - ~/.nvm/versions/node/v18.14.2/bin/pnpm
  Browsers:
    Chrome: 119.0.6045.199
    Safari: 17.1

Any additional comments?
No response

Cannot reproduce on either main or minor branches - make sure you are doing a clean git clone and use an updated version of pnpm (8.12.0)


text:
goto definition in template not working

language-tools version
v1.6.4
vscode insider version
v1.79.0-insider
Steps to reproduce

minimal reproduction
a fresh repo use volar-starter template: https://github.com/edison1105/volar-goto-definition-in-template
What is expected?

CMD + left click HelloWorld will open HelloWorld.vue
CMD + left click msg will open HelloWorld.vue and locate the definition of msg

additional comments
Not sure if it's already supported or a new feature.

Does it work now?

Does it work now?

Not sure. I just switched to WebStorm as u know.

Yeah, in my machine it works now 😃 Close this issue for now!

Hey @danwall, I see you reacted with 👎. Does this issue still exist?

repo: vuejs/language-tools


text:
Strict type checking, TypedDocumentNode and @apollo/client v3

The main purpose of this PR is to use @apollo/client v3. The new cache management system is a huge improvement from v2.
I also noticed that strict was not enabled and therefore nullable types were inaccurate. The codebase is very clean, so migrating to strict was easy.
Finally, I saw that @apollo/client added support for TypedDocumentNode, which unifies document, query type and variable type into a single object. Naturally I couldn't resist adding support for this too.

esModuleInterop is needed for zen-observable, a dependency of @apollo/client
Cannot import directly from @apollo/client because it pulls react. We must import from @apollo/client/<subdir>.

So after adding support for TypedDocumentNode I think this is PR is done, it brings vue on par with react.

Looking forward for this to be merged. I've encountered a small problem with current type for 'useQuery', where result is TResult and not 'TResult | undefined'. And it is fixed here

Hi! Could you please look at those conflicts? Thanks!

Sure, it should be ready now

Thanks for the huge useful PR! 😻

authors: Akryum javiertury tup1tsa

repo: vuejs/vue-apollo


text:
使用Preset选项初始化项目报错 obs.pipe is not a function

Version
3.0.0
Node and OS info
Node v8.11.1 / Yarn 1.6.0 / Windows 10 / MacOS 10.13.5
Steps to reproduce

vue create --preset ./preset my-project

创建所使用的Preset仓库地址：https://github.com/TaroXin/vue-cli-creator-preset.git
What is expected?
项目成功创建
What is actually happening?
得到一个JS错误，错误代码如下
success Saved lockfile.
✨  Done in 84.41s.
🚀  Invoking generators...

Preset options:...
 ERROR  TypeError: obs.pipe is not a function
TypeError: obs.pipe is not a function
    at PromptUI.run (/usr/local/lib/node_modules/@vue/cli/node_modules/inquirer/lib/ui/prompt.js:33:24)
    at Object.promptModule [as prompt] (/usr/local/lib/node_modules/@vue/cli/node_modules/inquirer/lib/inquirer.js:28:22)
    at Creator.resolvePlugins (/usr/local/lib/node_modules/@vue/cli/lib/Creator.js:323:36)
    at Creator.create (/usr/local/lib/node_modules/@vue/cli/lib/Creator.js:154:32)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

你看错文档了，第三方 preset 的 prompt.js 应该返回一个数组，你复制的代码是内置插件用的
https://cli.vuejs.org/zh/dev-guide/plugin-dev.html#第三方插件的对话

authors: TaroXin sodatea

repo: vuejs/vue-cli


text:
Cannot assign to read only property 'Symbol(Symbol.toStringTag)' of object '#'

Version
3.5.1
Environment info
  System:
    OS: macOS 10.14.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
  Binaries:
    Node: 11.11.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.121
    Firefox: 64.0
    Safari: 12.0.3
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0-beta.2
    @vue/babel-plugin-transform-vue-jsx:  1.0.0-beta.2
    @vue/babel-preset-app:  3.5.1
    @vue/babel-preset-jsx:  1.0.0-beta.2
    @vue/babel-sugar-functional-vue:  1.0.0-beta.2
    @vue/babel-sugar-inject-h:  1.0.0-beta.2
    @vue/babel-sugar-v-model:  1.0.0-beta.2
    @vue/babel-sugar-v-on:  1.0.0-beta.2
    @vue/cli-overlay:  3.5.1
    @vue/cli-plugin-babel: ^3.5.0 => 3.5.1
    @vue/cli-plugin-e2e-nightwatch: ^3.5.0 => 3.5.1
    @vue/cli-plugin-eslint: ^3.5.0 => 3.5.1
    @vue/cli-plugin-unit-jest: ^3.5.0 => 3.5.1
    @vue/cli-service: ^3.5.0 => 3.5.1
    @vue/cli-shared-utils:  3.5.1
    @vue/component-compiler-utils:  2.6.0
    @vue/eslint-config-standard: ^4.0.0 => 4.0.0
    @vue/preload-webpack-plugin:  1.1.0
    @vue/test-utils: 1.0.0-beta.29 => 1.0.0-beta.29
    @vue/web-component-wrapper:  1.2.0
    eslint-plugin-vue: ^5.0.0 => 5.2.2
    jest-serializer-vue:  2.0.2
    vue: ^2.6.6 => 2.6.9
    vue-eslint-parser:  5.0.0
    vue-hot-reload-api:  2.3.3
    vue-jest:  3.0.4
    vue-loader:  15.7.0
    vue-router: ^3.0.1 => 3.0.2
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.5.21 => 2.6.9
    vue-template-es2015-compiler:  1.9.1
    vuex: ^3.0.1 => 3.1.0
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce
Create a standard Vue Project with Jest as the unit test framework. The sample test will fail with the following message.
Test suite failed to run
TypeError: Cannot assign to read only property 'Symbol(Symbol.toStringTag)' of object '#<process>'

  at exports.default (node_modules/jest-environment-jsdom/node_modules/jest-util/build/create_process_object.js:15:34)

What is expected?
test to pass
What is actually happening?
Test suite failed to run
TypeError: Cannot assign to read only property 'Symbol(Symbol.toStringTag)' of object '#<process>'

  at exports.default (node_modules/jest-environment-jsdom/node_modules/jest-util/build/create_process_object.js:15:34)

I believe this is related to the newest version of node (11.11.0) and has been addressed by Facebook as part of Jest 24.5.0 release (https://github.com/facebook/jest/commit/800f2f803d01c8ae194d71b251e4965dd70e5bf2)
Also posted in React Git Issue log: https://github.com/facebook/create-react-app/issues/6591

+1
I've also just started experiencing this when trying to run jest in both a Vue CLI project and a NestJS Project shortly after upgrading yarn.

Experiencing the same issue after switching to yarn in my create react app application.

We've exactly the same error, and waiting for an update of the dependencies (node/jest is already updated, which will fix this error)

According to the Jest's github, it's due to a recent bug with Node v11.11.

for those facing this issue: this happened after Node v11.11. the quickest fix is to downgrade Node to 11.10.1 in your CI lock file until further investigation

https://github.com/facebook/jest/issues/8069#issuecomment-470307590

had the same issue, solved when updating node to v11.12.0

Has the same issue: it did appear with image: node:latest in gitlab.yml.
Switching to node:10.15.3 has fixed the issue.

since it works with node 11.12, I'll close it.

authors: Carduelis LinusBorg YoshiYo devnet-uk glazey132 miking-the-viking mustafawm silentgecko


text:
Global configuration of vueJS

Hi,
I'm a beginner in VueJS and, after many times on Google i can't found any solution :
When i want to configure vue-resource in global like that : (app.js file)
Vue.use(VueResource);
Vue.http.options.root = 'http://127.0.0.1:1337';
Vue.http.headers.common['Authorization'] = 'Basic YXBpOnBhc3N3b3Jk';

Webpack don't like me at all, why ?
Thanks for your help !

Same here... I really need a solution for that :(

After all the error it's mine... When we use a '/' in url like that this.$http.get('/post', ...) the root config isn't used... The vue-resource only use the root config when the slash isn't present at first position in the url.

@gil0mendes your are the man!

That seriously needs to be documented somewhere! (Other than this issue)...

Documentation PRs are easy to do! :smile:
Scott

authors: Clebiez dinghua gil0mendes mattjdev smolinari

repo: vuejs/vue-resource


text:
Inconsistent initialization rendering

Version
2.6.11
Reproduction link
https://jsbin.com/teceyip/edit?html,output
Steps to reproduce
Type the following code separately.

A

<!DOCTYPE html>

        <meta charset="utf-8">
        <title></title>

            {{ a }} {{ and }} {{ b }}

B

<!DOCTYPE html>

        <meta charset="utf-8">
        <title></title>

            {{ a }} {{ and }} {{ b }}

What is expected?
A is consistent with B.
What is actually happening?
A is inconsistent with B.
B renders the 'and' attribute, but B should not render it.

This is expected because changing b schedules a re rendering which will use the and that was added

repo: vuejs/vue


text:
take the wrong Ref

Version
2.6.11
Reproduction link
https://jsfiddle.net/huanghanzeng/pvndbycf/
Steps to reproduce
just see the color of Dom , you can see that header is red but not content
What is expected?
div that class is "test-content" is red
What is actually happening?
div that class is "test-header" is red

Because you are manually applying style, Vue reuses the node for the wrong element. Use a key attribute:

      header

      content

      footer

Add different keys to those 3 adjacent divs

authors: Nandiin genaller posva


text:
comparing values when firing "watch"

Version
2.3.3
Reproduction link
https://jsfiddle.net/os7r6kay/11/
Steps to reproduce
hi
i'm new to vue framework. i've been using it for a week or so. this is using the latest vue, 2.3.
I came about this problem when starting from https://vuejs.org/v2/examples/select2.html, and trying to implement "multiple" support.
I then removed select2 from the equation to simplify the "bug".
See the normal/simple select in the following:
https://jsfiddle.net/f4a8fdju/3/
It works as expected and everything is fine
See the following multiple select example:
https://jsfiddle.net/os7r6kay/11/
I have placed a counter to prevent the browser from hitting a javascript lock. If you uncomment the "return" in the change function, it will work because it breaks the infinite recursion. Alternatively, another solution is to uncomment the JSON stringify compares.
I am sure there is a lot more at play here that I am not aware of, being a vue noob. I suspect the issue here is that the watch event is only firing if the value changes. And when the value is an array, if you do ['hello'] == ['hello'], the result will be false, so it's hitting endless recursion between the change event firing and the value watcher.
If this is indeed the case, I don't know enough about vue to know if that, perhaps, the watch should perhaps make use of JSON.stringify() or something to compare the values when using the watch? Perhaps doing this would break other things?
I understand that the endless recursion is the fault of the script, in that it's firing change and then the watch is picking it up. My thought is that perhaps watch should be able to handle arrays (and maybe objects?) and not fire when they match.
Have mercy on me,
A vue noob
What is expected?
endless recursion would not happen
What is actually happening?
endless recursion

i love vue

For what it's worth I wrote a workaround for this in a StackOverflowquestion today. I'm not sure changing the way properties work for arrays/objects is a viable solution for all cases.

Ya, I agree, not sure it's "worth" it either. I just thought it interested that the watch does not fire if the watched variable is "set", but to the same value. Was just curious if someone with more vue experience thought that perhaps the watch should use a more loose comparison for arrays/objects.

Is this a VueJS bug?

The watcher checks whether it should fire using a strict equal === - changing this behavior would be breaking and unlikely to happen.
IMO it's the component's responsibility to avoid this infinite loop - also I think the more appropriate place to check shallow equality is inside your watcher callback.


text:
[Feature request] Different Pages and Image Indexing

Feature request
Description

I tested out the sitemap extension good work but there is a must have feature that sitemap should be divided into different pages after a pages limit see how properly it's divided in WP

Index Image also automatically get the first image and it's data.

<url>
<loc>https://example.com/test.html</loc>
<lastmod>2021-06-20T14:24:12+00:00</lastmod>
<image:image>
<image:loc>https://example.com/image.png</image:loc>
 <image:title><![CDATA[Example]]></image:title>
<image:caption><![CDATA[Example]]></image:caption>
</image:image>
</url>

The sitemap plugin has not been merged yet. For now you'd better leave a comment to #277

ok I think @Mister-Hope will take a look

Hi there, I would like to share some ideas.

The second one is good, and I will support it after the sitemap plugin is merged as an  enhancement.
But actually this feature is not important at all.
Why?
Please notice not all the search engines are supporting that. Most search engines are just regarding sitemps as url maps, and they claw the html content themself, Google is just doing that, so if you are using an seo plugin like @mr-hope/vuepress-plugin-seo, infomation in <meta> tags are much more important and do have a higher preority than sitemaps info. Which means as long as you are providing all the information you wanna provide to search engine in meta tags, you should better not put it in sitemaps for size consideration.

For the first one, it's definately unneeded with VuePress.
Why?

You can provide multiple Sitemap files, but each Sitemap file that you provide must have no more than 50,000 URLs and must be no larger than 50MB (52,428,800 bytes).

It's unpossible for a VuePress project to reach this limit. In my test, a over 1000 pages project already fails on Github Actions using vuepress2 (becuase action machines has 8 GB rams). So the time and memory cost of a project with more than 50000 pages in vuepress is unpossible. So we should leave things simple. One single sitemap files should be enough in most situations.

Hello @Mister-Hope Thanks for the reply ok then I no longer need first one but still need second one as I am using VuePress as a site other than documentation, However you are also right that this feature is not that useful so if you want feel free to close this issue.

Hello @Mister-Hope Thanks for the reply ok then I no longer need first one but still need second one as I am using VuePress as a site other than documentation, However you are also right that this feature is not that useful so if you want feel free to close this issue.

Have you check what search engines are actually reading <image:image>? I am pretty sure google do not support it, because I made some investigation when I am building sitemaps plugin for v1 last year. Why do you actully needs this none standard item?

If you care about SEO. you will probaly need a plugin like https://vuepress-theme-hope.github.io/seo/
If you are using sitemap as feeds, you should probably provide a standard feed using plugins like https://vuepress-theme-hope.github.io/feed/

Actually I am not getting why images are needed in sitemaps. They are just maps describing urls for search engines telling them which pages they need to visit and claw.

Oh sorry, you need to sperate sitemaps?
If you are helding large sites, you should probably sperate them to several VuePress projects, so that you won't need to rebuild them all when you have little changes, so you can just generate a sitemap group by yourself referencing to each sitemap files in your vuepress projects.

Oh sorry, you need to sperate sitemaps?
If you are holding large sites, you should probably sperate them to several VuePress projects, so that you won't need to rebuild them all when you have little changes, so you can just generate a sitemap group by yourself referencing to each sitemap files in your vuepress projects.

Sorry I dont need images feature I just need separate sitemap features I am not using different vuepress installations as my site is once loaded user will have to navigate to several pages and I don't want to reload the browser page with normal link that's the reason.

I am curious how much pages does your site have?

I am curious how much pages does your site have?

For now it's 40 - 60 only but as it's a tutorial type website it will be having too much pages category and different things.

I am not sure if you understand what I am expressing.
You have to rebuild every time your content change, and for a 1000 pages site, the time is already around 10min. You will absolutely take more than 6 hours to build a site ( and GBs output) if your site is around 5w pages. Then vuepress is probably not the tool you should use. You should use tools based on server with database, where each your page is stored in database, and the server generate pages for you if you do needs lots of pages.
You will never reach a single file limit if you are in normal condition usage of VuePress.

I was using wordpress and many other things but I don't like the delay in page load in static site it's instant and in with database server generates site and then it works I like vuepress too much so I am planning to use it and do you mean 30 gb ram or rom ?? Also I am closing this issue I think that no one will make vuepress site like me

RAM, I am not tested that much, but 700 pages is already taking 7.2GB ln Ubuntu 20

RAM, I am not tested that much, but 700 pages is already taking 7.2GB ln Ubuntu 20
(790 pages with lots of content BTW)

OK Then A bit off topic but do you know something that has theme similar to vuepress and navigates to different pages in realtime and it can be easily used without this problems that we are having and it can handle more than 50000 pages

authors: Mister-Hope meteorlxy ramesh-dada

repo: vuepress/vuepress-next


text:
[BUG] Sandbox payment not working on demo site

Describe the bug
I'm trying to finalize a payment via the Paypal Sandbox on the demo site but after the payment there's a redirect to the following address which is obviously not working:
http://10.30.1.16:8000/payment/finalize-transaction

sandbox works now on the demo site

authors: fsavina patzick

repo: vuestorefront/shopware-pwa


text:
CopyHeaders is using http.Header.Add() that capitalizes the headers

It makes oxy incompatible with several clients, like the ones using the Amazon S3 API
See the link below for more information:
https://github.com/golang/go/issues/5022
Could you please use the following approach ?
func CopyHeaders(dst, src http.Header) {
for k, vv := range src {
for _, v := range vv {
dat[k] = v
}
}

sure, this makes sense

I'm not a go person.  Does the approach above preserve the headers in their original state?
I'm trying to use traefik which apparently leverages this under the hood and it's really causing some issues even though headers are supposed to be case-insensitive.

We are also using Traefik, and face the same issue regarding the case sensitivity of headers. Is there a fix for this in oxy ?

https://github.com/containous/traefik/issues/466#issuecomment-535534743

authors: Herz3h cmullendore djannot klizhentas travisghansen

repo: vulcand/oxy


text:
[Payment] FromScript

A FromScript function similar to the existing FromPublicKey one must be added to the payment package in order to return a Payment from an output script and a network.

Taking into account the considerations pointed in https://github.com/vulpemventures/go-elements/issues/12#issuecomment-629326718, the FromScript method actually needs to return a nested payment.
This means that firstly the incoming script should be used to create a redeem payment, then the redeem would be passed to the FromPayment function.
Example:
func FromScript(script []byte) (*Payment, error) {
   redeem := &Payment{Script: script}
   return FromPayment(redeem)
}

In this way, we would be  sure that the returned payment has a non nil Redeem and that the ScriptHash and WitnessScriptHash function would return the correct addresses.

This should NOT be taken before the fix to be done described in #35

authors: altafan tiero

repo: vulpemventures/go-elements


text:
add Pset.estimateVirtualSize method

add a method greatly inspired by ocean's EstimateTxSize function.
The function aims to compute the estimated virtual size of the pset extracted transaction. The function takes into account the possible confidentiality of the outputs even if there aren't blinded.
EDIT: CI is failing at format:ci step but format:ci pass locally, any idea about this?
@altafan please review

nACK.
We should be very careful about making breaking changes to the address submodule since it's widely used in other projects.
This kind of high-level API must be implemented in projects using this lib like LDK.

authors: altafan louisinger

repo: vulpemventures/liquidjs-lib


text:
Add fixer for Go modules

Go 1.11 introduces the "go.mod" file and "go mod edit -fmt" to format
it. This adds a fixer for that.
This requires Go 1.11 to test, and a recently new version of vim-go
which sets the filetype for this file (was merged today). Or you can
stick this in your vimrc:
autocmd BufRead,BufNewFile go.mod set ft=gomod

I'll see if we can get it in the standard runtime files too.

I thought I had merged this already, but I hadn't.
Cheers! :beers:


text:
Add skills component - Front

import React, { useState } from 'react';

const SkillsField = ({ onAddSkill  }) => {
  const [skills, setSkill] = useState('');

  const handleInputChange = (e) => {
    setSkill(e.target.value);
  };

  const handleSkillClick = () => {
    if (skills.trim() !== '') {
      onAddSkill(skills);
      setSkill('');
    }
  };

  return (

      <input
        type="text"
        placeholder="Skill"
        value={skills}
        onChange={handleInputChange}
        id="skills-input"
        tabIndex={5}
        className={styles["skills-input"]}
        //onChange={(event) => setSkills(event.target.value)}
      />

        add

  );
};

export default SkillsField;

const SkillsList = ({ AllSkills }) => {
  return (

      {AllSkills.map((skills, index) => (

          {skills}

      ))}

  );
};

export default SkillsList;

https://chat.openai.com/c/e4f2be7f-da8c-449e-9a3c-9781c7fc6863


text:
F-Droid can't build

ref: https://gitlab.com/fdroid/fdroiddata/-/jobs/4848996785#L1207
/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/d9c79052cd5a3acbeffe8bf221df55420c237002

I found that it was missing a library. I fixed.
https://github.com/wa2c/cifs-documents-provider/commit/3c7cc9a2e7a109bbd4e6a88b256870e0c97ff58a

Update was picked up :+1:

jcifs is not available from a trusted maven repo?
ref: https://github.com/wa2c/cifs-documents-provider/commit/762342ebd22012717bef662fdeea61f2d38bc0f6
ref: https://mvnrepository.com/artifact/org.samba.jcifs/jcifs


text:
Error during deployment of repo

I was trying to deploy the purealoe app with the use of the deploy to SFDX button. But unfortunately it went wrong and asked to log a issue with the following information:
GUID: 7f1baab9-3619-86a6-b619-ecb67ae74720 ▸ autoupdate:: /app/.cache/sfdx/update.lock is locked with an active writer ▸ 'MODULE_NOT_FOUND': Cannot find module 'zip-stream'

3) GUID: 7f1baab9-3619-86a6-b619-ecb67ae74720 ▸ autoupdate:: /app/.cache/sfdx/update.lock is locked with an active writer ▸ 'MODULE_NOT_FOUND': Cannot find module 'zip-stream'
2) Successfully cloned https://github.com/dreamforce17/purealoe.
1) Using .salesforcedx.yaml found in repository.

When running the process again from the button in repo it worked a second time. But maybe this error gives extra insights in possible bugs.

The button worked when I did exactly the same thing the second time.

repo: wadewegner/deploy-to-sfdx


text:
Restructure GGIR vignettes

In the past couple of months Jairo and I have been preparing a restructuring of the vignette documentation.
We now have a github-pages framework that we will fill with narrative chapters to describe everything there is to say about GGIR in an accessible way. As a result, the CRAN pages can be be refocused to have a more practical focus with output and parameters dictionaries, as well as reference tables for cut-points.
I am creating this issue to keep track of outstanding tasks:
Chapters 1-7:

[x] Draft and peer-review among ourselves (offline)
[x] Add to branch
[x] Check all looks good locally
[x] Merge with master branch and check all look good online

Chapters 8-12:

[ ] Draft and peer-review among ourselves (offline)
[ ] Add to branch
[ ] Check all looks good locally
[ ] Merge with master branch and check all look good online
[ ] Add hyperlinks in between chapters and republish.

Update rest of GGIR:

[ ] Add reference from GGIR-package.Rd to github pages.
[ ] Revise main CRAN vignette to become more complementary to the github pages, e.g. structured as a demo(s) with a strong focus on discussing GGIR output and all its variables.
[ ] CRAN displays all vignettes https://cran.r-project.org/web/packages/GGIR/. Can this be turned off to skip vignettes to avoid redundancy?

As this grows we can ask users and collaborators to peer-review.

In https://wadpac.github.io/GGIR/articles/chapter3_QualityAssessment.html#auto-calibration-algorithm
there seems to be a problem with the link backup.cal.coef, see specific documentation on this parameter [here](https://cran.r-project.org/package=GGIR/vignettes/GGIRParameters.html#:~:text=setting%20is%20TRUE.-,backup.cal.coef,-Character%20(default%20%3D%20%E2%80%9Cretrieve).

repo: wadpac/GGIR