Multus pod fails to come up and "Topology Affinity Error" status is shown

What happend:
We have two k8s worker nodes and topology manager policies enabled in each worker node.
worker - 1 = best-effort
worker - 2 = single-numa-node

When multus daemon set is installed with this command, then multus pod doesn't come up on the worker - 2 node and finally fails with "Topology Affinity Error".
root@dl380-006-ECCD-SUT:~/cnis/multus-cni# kubectl get pods -n kube-system | grep multus
kube-multus-ds-amd64-gzj6x                   0/1     Topology Affinity Error   0          2m42s
kube-multus-ds-amd64-jp45m                   1/1     Running                   0          19m

This happens even though node meets cpu and memory criteria on a single numa socket as provided in
the spec.
Here are the kubelet logs from workers.
worker - 1
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144422   51160 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144444   51160 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144487   51160 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144499   51160 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144506   51160 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000011 true}
Nov 15 10:34:28 dl380-006-ECCD-SUT kubelet[51160]: I1115 10:34:28.144523   51160 topology_manager.go:329] [topologymanager] Topology Affinity for Pod: c3f82663-f3d9-4a7e-b5cf-278b4163ea89 are map[kube-multus:{00000000000000000000000000

worker - 2
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.158757   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.160001   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.160049   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.160068   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.160080   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.203907   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.203931   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.203945   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.203958   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:28 my-centos kubelet[20808]: I1115 10:34:28.203968   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:29 my-centos kubelet[20808]: I1115 10:34:29.238171   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:29 my-centos kubelet[20808]: I1115 10:34:29.238242   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:29 my-centos kubelet[20808]: I1115 10:34:29.238261   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:29 my-centos kubelet[20808]: I1115 10:34:29.238277   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:29 my-centos kubelet[20808]: I1115 10:34:29.238289   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:31 my-centos kubelet[20808]: I1115 10:34:31.271669   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:31 my-centos kubelet[20808]: I1115 10:34:31.271693   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:31 my-centos kubelet[20808]: I1115 10:34:31.271709   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:31 my-centos kubelet[20808]: I1115 10:34:31.271723   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:31 my-centos kubelet[20808]: I1115 10:34:31.271735   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:35 my-centos kubelet[20808]: I1115 10:34:35.304977   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:35 my-centos kubelet[20808]: I1115 10:34:35.305002   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:35 my-centos kubelet[20808]: I1115 10:34:35.305038   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:35 my-centos kubelet[20808]: I1115 10:34:35.305074   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:35 my-centos kubelet[20808]: I1115 10:34:35.305085   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:43 my-centos kubelet[20808]: I1115 10:34:43.339830   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:43 my-centos kubelet[20808]: I1115 10:34:43.339865   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:43 my-centos kubelet[20808]: I1115 10:34:43.339884   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:43 my-centos kubelet[20808]: I1115 10:34:43.339901   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:43 my-centos kubelet[20808]: I1115 10:34:43.339914   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:34:59 my-centos kubelet[20808]: I1115 10:34:59.371315   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:34:59 my-centos kubelet[20808]: I1115 10:34:59.371339   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:34:59 my-centos kubelet[20808]: I1115 10:34:59.371351   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:59 my-centos kubelet[20808]: I1115 10:34:59.371366   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:34:59 my-centos kubelet[20808]: I1115 10:34:59.371380   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:35:31 my-centos kubelet[20808]: I1115 10:35:31.413227   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:35:31 my-centos kubelet[20808]: I1115 10:35:31.413270   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:35:31 my-centos kubelet[20808]: I1115 10:35:31.413303   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:35:31 my-centos kubelet[20808]: I1115 10:35:31.413321   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:35:31 my-centos kubelet[20808]: I1115 10:35:31.413335   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:36:35 my-centos kubelet[20808]: I1115 10:36:35.443328   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:36:35 my-centos kubelet[20808]: I1115 10:36:35.444782   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:36:35 my-centos kubelet[20808]: I1115 10:36:35.444804   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:36:35 my-centos kubelet[20808]: I1115 10:36:35.444823   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:36:35 my-centos kubelet[20808]: I1115 10:36:35.444836   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:38:43 my-centos kubelet[20808]: I1115 10:38:43.473838   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 15 10:38:43 my-centos kubelet[20808]: I1115 10:38:43.473867   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 15 10:38:43 my-centos kubelet[20808]: I1115 10:38:43.473904   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:38:43 my-centos kubelet[20808]: I1115 10:38:43.473923   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 15 10:38:43 my-centos kubelet[20808]: I1115 10:38:43.473936   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 15 10:42:59 my-centos kubelet[20808]: W1115 10:42:59.500969   20808 status_manager.go:545] Failed to update status for pod "kube-multus-ds-amd64-gt5kd_kube-system(6372f768-5793-44b3-9486-6bb245442ae0)": failed to patch status "{}"

From the above logs, it looks none of the hints provider produce any hints for the pod admit request on both nodes and obviously it fails on the worker - 2 node as per the single-numa-node policy.
But this policy works fine for pods created with pod spec with single container. The cpu and device manager provides appropriate hints to topology manager. Hence I'm not sure if dameon set spec is yet to be supported by topology manager.
What you expected to happen:
The Multus pod should be running in each worker nodes if it meets resource criteria provided in the daemon-set spec. If it's a limitation of topology manager, then multus-daemonset.yml has to be changed accordingly.
How to reproduce it (as minimally and precisely as possible):
Enable Topology Manager's single-numa-node policy on a worker node and install multus plugin.
Anything else we need to know?:
When resource's values are changed with requests < limits, then multus pod came up properly on the node.
Environment:

Multus version
  nfvpe/multus                         v3.3                facade0978dd        4 weeks ago         298MB
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Primary CNI for Kubernetes cluster:
Calico
OS (e.g. from /etc/os-release):

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

I believe this is the same issue describe here
which has been fixed via PR.
could you please try with latest kube 1.16?

I'm already using k8 v1.16.2 version, the pod creation is successful for Guaranteed QoS class if it's created from kind: Pod yaml configuration (The topology manager gets appropriate hints from both cpu and device manager).
But multus pod is created with kind: DaemonSet configuration and i don't see any logs in cpu manager while generating the hints. It looks topology manager doesn't have any hint providers in this case and uses the default hints , so multus pod fails because of hint.NUMANodeAffinity.Count() > 1.
Here is the logs when pod is created with kind: Pod vs kind: DaemonSet.
kind: Pod
Nov 28 10:40:19 my-centos kubelet[20808]: I1128 10:40:19.414802   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:40:19 my-centos kubelet[20808]: I1128 10:40:19.414834   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
**Nov 28 10:40:19 my-centos kubelet[20808]: I1128 10:40:19.415063   20808 topology_hints.go:60] [cpumanager] TopologyHints generated for pod 'pod-dpdk-single-2', container 'appcntr3single2': [{00000000000000000000000000000000000000000000**
Nov 28 10:40:19 my-centos kubelet[20808]: I1128 10:40:19.415143   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000001 true}
Nov 28 10:40:19 my-centos kubelet[20808]: I1128 10:40:19.415164   20808 topology_manager.go:329] [topologymanager] Topology Affinity for Pod: e0fe216f-55da-4c6c-b7e4-16421cee2bc7 are map[appcntr3single2:{0000000000000000000000000000000

kind: DaemonSet
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.770014   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.771126   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.771147   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.771162   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.771172   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.813360   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.813380   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.813392   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.813401   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:23 my-centos kubelet[20808]: I1128 10:30:23.813408   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 28 10:30:24 my-centos kubelet[20808]: I1128 10:30:24.849796   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:30:24 my-centos kubelet[20808]: I1128 10:30:24.849836   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 28 10:30:24 my-centos kubelet[20808]: I1128 10:30:24.849849   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:24 my-centos kubelet[20808]: I1128 10:30:24.849867   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:24 my-centos kubelet[20808]: I1128 10:30:24.849879   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 28 10:30:26 my-centos kubelet[20808]: I1128 10:30:26.884814   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:30:26 my-centos kubelet[20808]: I1128 10:30:26.884854   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 28 10:30:26 my-centos kubelet[20808]: I1128 10:30:26.884884   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:26 my-centos kubelet[20808]: I1128 10:30:26.884896   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:26 my-centos kubelet[20808]: I1128 10:30:26.884904   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 28 10:30:30 my-centos kubelet[20808]: I1128 10:30:30.910248   20808 topology_manager.go:308] [topologymanager] Topology Admit Handler
Nov 28 10:30:30 my-centos kubelet[20808]: I1128 10:30:30.910272   20808 topology_manager.go:317] [topologymanager] Pod QoS Level: Guaranteed
Nov 28 10:30:30 my-centos kubelet[20808]: I1128 10:30:30.910286   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:30 my-centos kubelet[20808]: I1128 10:30:30.910299   20808 topology_manager.go:194] [topologymanager] Hint Provider has no preference for NUMA affinity with any resource
Nov 28 10:30:30 my-centos kubelet[20808]: I1128 10:30:30.910306   20808 topology_manager.go:285] [topologymanager] ContainerTopologyHint: {0000000000000000000000000000000000000000000000000000000000000111 true}
Nov 28 10:30:38 my-centos kubelet[20808]: W1128 10:30:38.948591   20808 status_manager.go:545] Failed to update status for pod "kube-multus-ds-amd64-q7w5r_kube-system(845ecda7-6aa1-49c5-8de3-95bc3eeeadc0)": failed to patch status "{}"

The log with ** (from cpu manger while providing hints for the pod) is available only when pod created with kind: Pod and not for kind: DaemonSet.
Does it work for you ?

Hey @pperiyasamy,  this is a legit bug with Topology Manager and single-numa policy.
It's been fixed in the master branch if you want to try that out

@lmdaly Thanks, It works fine with k8s version 1.17.

Closing this issue. It's no more valid in k8 1.17 and 1.18 versions.


how to access each XML node one by one in AL?

My XML Content [XmlText] snippet:
<Access_Token>
<Instance_Url>https://www.mywebsite.com/</Instance_Url>
< YourToken>0_YdG/DRSVGCKyy6fx/fdasdY6avs=</ YourToken>
<Expiration_date>05/28/2019 11:50:14 PM</Expiration_date>
<Refresh_Token>0_i1G4fADRTVRDfdsac4GjD5R5UoOPks</Refresh_Token>
</Access_Token>
Please provide AL code snippet for reading above XML if anybody already wrote code for XML Reading and iteration.
Thanks in Advance!

This repository no longer handles general questions and is only dedicated to bug reports and feature suggestions for the AL compiler and developer tools.
To get help for your question please use one of the following resources:
Business Central Community
mibuso forum
Dynamics User Group


Convert to noarch

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

The used path ${PREFIX}/fonts is generic for osx, win and linux, so the recipe can be noarch: generic without further changes.
See also https://github.com/AnacondaRecipes/aggregate/tree/master/font-ttf-ubuntu-feedstock/recipe

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@jan-janssen Ready for review/merge.

@dbas Usually these fonts are by default installed in commercial operation systems, therefore this package was originally only created for Linux. Is there a specific reason why you do not want to reference the core fonts? I mean in contrast to libraries fonts are rather static.

@bgruening maybe you can also comment on this. Is there any official strategy to handle fonts in conda?

Afaik, those fonts are technically not architecture dependant, as they do not contain any compiled code or any other architecture specific things. Which means that this could be a noarch package, same as the referenced AncondaRecipes font ... If there is any benefit installing it on osx/win is a different question.

@jan-janssen this package is or can become part if our official stradegy. Multiple people currently try to make R font aware and there are different options on the table. That said there is no technical reason to not make this package arch dependent imho and if R will depend on it we need to install on OSX/Win as well - no matter if we assume font on those systems.
:+1: from my side.

Thanks!


Remove obsolete assertions

Required in #6646

jenkins, test this please.

Jenkins CI test (for commit 05d409265437eb64c69c070991d8f7092d8e8ccb, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

Can you rebase now that mixed dtype BatchNorm has been merged?

Rebased.

jenkins, test this please.

Jenkins CI test (for commit bbddc22e43df80d6e0367e348db996d4a86cddc9, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

CI failure seems unrelated. LGTM!


Categories= key missing in Linux desktop file

The etcher.desktop file should include a line
Categories=Utility;

References:

https://travis-ci.org/AppImage/appimage.github.io/builds/313897555#L709
https://github.com/AppImage/appimage.github.io/pull/199#partial-pull-merging

The desktop file is lacking a Categories= entry in the *.desktop file.
According to the menu spec,

By including one of the Main Categories in an application's desktop entry file, the application will be ensured that it will show up in a section of the application menu dedicated to this category. If multiple Main Categories are included in a single desktop entry file, the entry may appear more than once in the menu.

Hence, please add at least one of the following in the Categories= key.

Main Category
Description
Notes

AudioVideo
Application for presenting, creating, or processing multimedia (audio/video)

Audio
An audio application
Desktop entry must include AudioVideo as well

Video
A video application
Desktop entry must include AudioVideo as well

Development
An application for development

Education
Educational software

Game
A game

Graphics
Application for viewing, creating, or processing graphics

Network
Network application such as a web browser

Office
An office type application

Science
Scientific software

Settings
Settings applications
Entries may appear in a separate menu or as part of a 		"Control Center"

System
System application, "System Tools" such as say a log viewer or network monitor

Utility
Small utility application, "Accessories"

In addition, you could specify one or more from the longer list of Additional Categories.
Please test the result with desktop-file-validate and make sure it passes.
electron-builder offers native support for this since v19.22.1.. Please see the category key at https://www.electron.build/configuration/linux-other.

This will be fixed by https://github.com/resin-io/etcher/pull/1905 as our electron-builder config already sets the category to "Utility"


Intersection makes no sense to me.

var greinerHormann = require('greiner-hormann');
var intersection = greinerHormann.intersection([[1,1],[2,1],[2,2],[2,1],[1,1]], [[1,1],[3,2],[2,2],[2,1],[1,1]]);
var out = []
if(intersection){
    if(typeof intersection[0][0] === 'number'){
        out = [intersection]
        console.log("single linear ring")
    }
    console.log("length:"+intersection.length)
    for(var i = 0, len = intersection.length; i < len; i++){
        out.push([intersection[i]])
    }
} else {console.log("no intersection")}
console.log("output"+out)

Gives:
length:1
output2,1.5,2,1,1,1,1,1,2,1,2,2,2,1.5
????

The shapes you've provided make little sense, too. They have collapsed edges. What is the source of those?

So the issue is that I don't understand the required format for polygons. And have no clue what collapsed edges are or how to avoid them. I was just assuming you provide a set of 2d points, in this case, they describe the corner of a rectangle and the other is a rectangle with one point moved out of place.  So e.g. [[1,1],[2,1],[2,2],[2,1],[1,1]] is "start at x=1, y=1. Move to x=2, y=1" and so on through x2y2, x2y1, and finally return to x1y1.
Can you point me at how polygons should be defined?

Ah, nevermind, I see it. The points [2,1] and [2,1] repeated... The second one should be 1,2.


Git: Allow to diff multiple changes at once from the command line

VSCode Version: 1.22.2
OS Version: Windows 10 RS3

Steps to Reproduce:

Run "git difftool -d HEAD~1...HEAD
Expected outcome should be a side by side view of the diff. Or at least show the diff parts in the both files (left and right). The actual outcome is two VSCode instances open, and then you cannot even tell where the diff is/are.

Does this issue occur when all extensions are disabled?: Yes

@ochmist are you seeing something like this as well:

@bpasero Yes, that is exactly what I am seeing. Is that expected?

@ochmist no, I will have to find the bug here.

@ochmist I see what is happening. Git actually creates 2 temporary folders and then asks VS Code to open them. For us it looks like you want to open 2 folders at once, so we just create an untitled workspace adhoc to show them.
I have updated the issue, but it is rather a feature request: to support diffing multiple changes in one window from the command line.
//cc @joaomoreno

@bpasero " to support diffing multiple changes in one window from the command line." is accurate.
I hope multiple people would upvote this request so that this feature can be implemented for those of us migrating from meld and other tools to using VSCode exclusively.

any timelines on when this will be supported?


Provide a description of the wot-rust crates for the Implementation Report

See: https://github.com/w3c/wot-thing-description/pull/1838

Done.


Kiali container doesn't come up

I used the command given in this documentation to install Istio, which has Kiali.enabled as true " --set kiali.enabled=true" , but when run this command,  I see Kiali container doesn't come up. it is looking for kiali secret, which is not there.
I did Kubectl describe pod <kiali-pod> , see the following error flagged:
Events:
Type     Reason     Age                   From                               Message

Normal   Scheduled  12m                   default-scheduler                  Successfully assigned istio-system/kiali-7bf98df4fb-vmh26 to aks-agentpool-19733474-1
Normal   Pulling    12m                   kubelet, aks-agentpool-19733474-1  pulling image "docker.io/kiali/kiali:v0.12"
Normal   Pulled     11m                   kubelet, aks-agentpool-19733474-1  Successfully pulled image "docker.io/kiali/kiali:v0.12"
Warning  Failed     6m52s (x21 over 11m)  kubelet, aks-agentpool-19733474-1  Error: secret "kiali" not found
I think, there is some more config about Kiali required. Please fix this.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 68b5d00d-529b-a8be-47bf-773c967f0e72
Version Independent ID: 0cf044ef-b26f-a8fa-213f-1e3fffaf53d6
Content: Install Istio in Azure Kubernetes Service (AKS)
Content Source: articles/aks/istio-install.md
Service: container-service
GitHub Login: @paulbouwer
Microsoft Alias: pabouwer

Thanks for the feedback! We are currently investigating and will update you shortly.

@pnkjtr I am able to reproduce the issue.
I think its better to open an issue with the istio.
@iainfoulds you comments please.

Looks like secret is not included in the helm chart purposefully.
https://github.com/istio/istio/issues/9392

@jakaruna-MSFT I am not the owner of this doc. @paulbouwer should be able to provide assistance.

@pnkjtr - thanks for reporting this. Looks like there was a change in the Helm chart that has caused this.
@MicahMcKittrick-MSFT @jakaruna-MSFT @iainfoulds
I will have a look into this and update the doc.

@pnkjtr @MicahMcKittrick-MSFT @jakaruna-MSFT @iainfoulds
So from Istio version 1.0.6 onwards, the Istio nested charts for Grafana and Kiali have removed the templates for rendering secrets. You, as the end user, are now required to add the secrets as a separate and out of band step.
This is documented in the Istio Chart README.md currently under the master branch.
Here are the relevant bits and example values, replicated for those reading this issue:
$ NAMESPACE=istio-system

Kiali
$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: kiali
  namespace: $NAMESPACE
  labels:
    app: kiali
type: Opaque
data:
  username: YWRtaW4=
  passphrase: MWYyZDFlMmU2N2Rm
EOF

Grafana
$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: grafana
  namespace: $NAMESPACE
  labels:
    app: grafana
type: Opaque
data:
  username: YWRtaW4=
  passphrase: MWYyZDFlMmU2N2Rm
EOF

I do not agree with this update to the Helm charts. You should be able to add the secrets via the Helm charts if you wish to, or reference existing secrets if you wish to do that - it should be about choice. This is creating friction. I will look to follow this up on the Istio repo.
In the interim, maybe the pragmatic approach is to add a note in the install docs here for customers wanting to look at versions of Istio from 1.0.6 and up to warn them of this new behaviour. It may be worth saving a larger update to the docs for Istio 1.1 which looks imminent.
Thoughts?

@paulbouwer yeah I agree that makes sense. No use in doing multiple minor updates if a larger update might be needed shortly.

@MicahMcKittrick-MSFT - PR 69823 merged for this.


Add like/dislike system

Describe the feature you'd like
Adding like (thumbs up) and unlike (thumbs down) functionality for books/pages/chapter
Describe the benefits this would bring to existing BookStack users
If you have already liked a post/page and now you dislike it, then the old voting will be cancelled and vice-versa. You can reset the settings to default and the like/unlike counts for all/selected posts/pages as well. It comes with two widgets, one to display the most liked posts/pages for a given time range and another to show recently liked posts
Can the goal of this request already be achieved via other means?
no
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?
Under 3 months
Additional context
No response

Thanks for the suggestion @lavelinevgeny.
This is along the same lines as previous issues #1524 and #505. Within those, I've closed them as out of scope, which would be my position here also.
Happy to hear a case for such a feature, but I'd need to understand the benefits this would bring to existing BookStack users. I know you filled this part of the issue form out, but you explained your desired technical implementation, rather than how this would fundamentally benefit existing BookStack users.

@ssddanbrown, sorry, I only looked at similar tasks among open tasks.
I'll try to develop my idea.
I think that the like system will give site users an important characteristic for a specific article/instruction, when it will be clear how much they can trust the information on the current page.
This will be useful even without additional widgets.
If it is possible to display pages with negative reviews (when there are more negative reviews than positive ones), this will give a signal to the author to improve such pages.
You can implement this function optionally so that only those who need it can enable it.

I agree that this has some nice potential use cases: allowing crowd-sourcing data collection could allow an Editor to gauge which content was meeting a minimum standard of quality or needed attention from the editing users. Whether on an internal or public forum these voting systems are popular because they work: most people aren't inclined toward misusing a feature like this, and there is a real benefit to the editor getting that feedback to know where to focus attention. And yes, there are certainly additional emergent features that might come out of this, but a basic tally creating a hierarchy of quality for "essential" pages would definitely be something I would use on my set up


fix: replacement of bootstrap-tagsinput with select2

Fixes #2683
Describe the changes you have made in this PR -
I have replaced the bootstrap-tagsinput with the select2 library.
Screenshots of the changes (If any) -
screen-capture (9).webm
screen-capture (10).webm
Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

@tachyons, There is a problem when we paste multiple tags, it shows "Out of 1 Email(s), 1 was valid and 0 were invalid. 1 user(s) will be invited. No users were already present."
screen-capture.8.webm
Can you please help me to fix this?

It is because we need to fix email parameter in the form, here is how you can fix that for adding members
diff --git a/app/controllers/group_members_controller.rb b/app/controllers/group_members_controller.rb
index 6574492a..65e09998 100644
--- a/app/controllers/group_members_controller.rb
+++ b/app/controllers/group_members_controller.rb
@@ -35,7 +35,7 @@ class GroupMembersController < ApplicationController
     @group = Group.find(group_member_params[:group_id])
     is_mentor = false
     is_mentor = group_member_params[:mentor] == "true" if group_member_params[:mentor]
-    group_member_emails = Utils.parse_mails(group_member_params[:emails])
+    group_member_emails = group_member_params[:emails].select {|email| Devise.email_regexp.match?(email)}

     present_members = User.where(id: @group.group_members.pluck(:user_id)).pluck(:email)
     newly_added = group_member_emails - present_members
@@ -114,7 +114,7 @@ class GroupMembersController < ApplicationController

     # Never trust parameters from the scary internet, only allow the white list through.
     def group_member_params
-      params.require(:group_member).permit(:group_id, :user_id, :emails, :mentor)
+      params.require(:group_member).permit(:group_id, :user_id, :mentor, emails: [])
     end

     # Using different params for update
diff --git a/app/views/groups/_add_member_modal.html.erb b/app/views/groups/_add_member_modal.html.erb
index 1bf80fad..6e35fddb 100644
--- a/app/views/groups/_add_member_modal.html.erb
+++ b/app/views/groups/_add_member_modal.html.erb
@@ -27,7 +27,7 @@

             <%= form.label :emails %>
-            <%= form.select :emails,[ ],{},{ class:'form-select' }%>
+            <%= form.select :emails,[ ],{},{ class:'form-select', multiple: true }%>

             <%= form.submit  class: 'add-members-button btn primary-button' %>
--

@tachyons please review

Great job 👍


[feat] Added setup method to datastore.

Codecov Report

Merging #24 into master will decrease coverage by 1.53%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
- Coverage   83.01%   81.48%   -1.54%
==========================================
  Files           2        2
  Lines         159      162       +3
  Branches       54       54
==========================================
  Hits          132      132
- Misses         27       30       +3

Impacted Files
Coverage Δ

src/server/datastore/ephemeral.ts
76.98% <25.00%> (-1.88%)
:arrow_down:

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 94e291e...c45b5e2. Read the comment docs.


Make header translucent when the user scrolls down

Make header translucent when the user scrolls down. Follow the same design as https://fossasia.org/

I am working on this.


Certified Skype Bot cannot be found anymore

Hey everybody,
our Skype bot has been reviewed and certified successfully, but since today it cannot be reached through its link anymore. It can also not be found by searching for its name in the Skype app. For those who have been in contact with the bot before, it still reacts normally and can also be shared within the Skype app (from one user to another).
In order to solve the problem I have just submitted the bot for review again. Any suggestions what could have caused the problem?
Here is the (not working) bot url: https://join.skype.com/bot/82b2e58f-dec7-4704-89ef-702edfd1aad3
Best Regards
Timo

Hi @herrspiess
We apologize that you've run into this issue.  This is currently affecting all skype join links, and not just your bot.  There is no need to re-submit for review.  The team is aware of this issue, and is actively working to fix it.  I'll report back when we've resolved the underlying problem.


Release plan for 1.1

Anything we need to consider for releasing 1.1 and with that include #37 ?

OK, I finally had a look at why karma was failing under PhantomJS and it turned out to be 3 unrelated issues. Fixed and pushed to the karma branch.
I'm still not a fan of karma, but it seems to work in the current setup.

The test not.toImageDiffEqual should fail under IntegrationSpecRunner.html looks off, i.e. no image shown. I believe this used to work in the past so we might need to look at it.


Add dropdown for changing region

Change titles when changing regions

I have no idea how to fix the CodeQL warnings

Thanks looks good


Allow start on login option to launch a hidden quake window

Description of the new feature/enhancement

Enable Windows Terminal to prepare a hidden quake window on machine startup, preventing the need to first issue the quake mode command from a regular window. Presently, enabling the "launch on machine startup" option only launches a regular window at startup, when it would be nice if the startup behavior prepared a quake window for easy access after startup. Ideally, Windows Terminal should be able to listen to the quake command at machine startup/user login without needing to first start a regular terminal window. Additionally, exiting the shell in the quake terminal (ex via the exit command) requires repeating this process to have a quake terminal available. Ideally, the quake mode command would spawn a new quake window if one doesn't exist.
Proposed technical implementation details (optional)'

Ideally, the Windows Terminal application could be configured so that it's "launch on machine startup" behavior can either A: Launch a regular terminal window as presently implemented, or B: Start a background process that listens to the quake command shortcut, showing the quake window if it already exists, or launching a new one if it does not exist. This process could either be implemented as a service or, probably more ideally, as a user-level background process that creates a tray icon, similar to how PowerToys works to allow it's features to run on startup/login. The system tray icon method is also the same technique that KDE uses for Yakuake on Linux for another project to reference that implements this well.
The use case of this feature, when enabled, would be something like the following: User logs on -> Windows terminal background process/tray process starts on login without showing anything to the screen -> User activates quake command via keyboard -> If quake window currently exists, show it. If not, create the new quake window.
Might be related to #7374, but this feature seems to be a bit larger in scope.

Thanks for the suggestion! We've been using #9996 to track this request (more or less), so please refer to that thread for more discussion.
/dup #9996


[AutoPR iotspaces/resource-manager] Onboarding IoTSpaces.

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/2722

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/1398


Move calculations to a different .py file

What do you think about that @HuyHung1408 ? I would like to move the calculation part of the program to a different .py file, as it is about to get larger. Only an idea tho, i just want to make the code look good. No problem if you dont want it.

I just want to get approval so i can finally start "really" working on this amazing program!

My opinion: good idea since we need to add BODMAS or PEMDAS functions. That might make the project better. Heck, we could also publish it on PyPI if it gets so huge!

Just waitin for @HuyHung1408 's approval

yup, great idea. Sorry for not being online much at this time, my final exams is coming so I have much things to do. Hope that I'll be free when I finished the school

no problem!


enabled nlreturn

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
fixed nlreturn warnings
Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[x] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: #956
What is the new behavior?

Other information

Codecov Report
Attention: 308 lines in your changes are missing coverage. Please review.

Comparison is base (0b4d369) 68.62% compared to head (7c17776) 54.80%.

Files
Patch %
Lines

internal/value/value.go
6.36%
103 Missing :warning:

internal/table/scanner/scan_raw.go
23.68%
29 Missing :warning:

internal/table/scanner/scanner.go
32.43%
25 Missing :warning:

internal/allocator/allocator.go
60.97%
16 Missing :warning:

internal/topic/topicreaderinternal/message.go
15.38%
11 Missing :warning:

internal/xsql/connector.go
41.66%
7 Missing :warning:

table/options/models.go
0.00%
7 Missing :warning:

internal/value/type.go
53.84%
6 Missing :warning:

balancers/balancers.go
0.00%
5 Missing :warning:

internal/coordination/client.go
33.33%
4 Missing :warning:

... and 53 more

Additional details and impacted files
@@             Coverage Diff             @@
##           master    #1027       +/-   ##
===========================================
- Coverage   68.62%   54.80%   -13.82%
===========================================
  Files         252      252
  Lines       24510    25152      +642
===========================================
- Hits        16819    13784     -3035
- Misses       6830    10407     +3577
- Partials      861      961      +100

Flag
Coverage Δ

54.80% <52.02%> (-0.46%)
:arrow_down:

go-1.20.x
54.54% <51.71%> (-13.96%)
:arrow_down:

go-1.21.x
54.71% <51.71%> (-13.79%)
:arrow_down:

integration
54.80% <52.02%> (-0.46%)
:arrow_down:

macOS
?

ubuntu
?

unit
?

windows
?

ydb-22.5
54.80% <52.02%> (-0.20%)
:arrow_down:

ydb-23.1
?

ydb-23.2
?

ydb-23.3
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Always create empty stream context to prevent race condition leading to CN mismatch on TLS enabled connections

Ran into an issue while connecting to both packagist and twitter at the same time. That resulted in the following error:

@DaveRandom jumped on that tweet and came with a repro and work around. This PR applies that workaround to the 0.4 branch, the master branch already has this fix in place. But I'll also test and confirm that to be sure.

Thanks for spotting and filing a fix! :+1:
I'm not sure if this should be considered a bug in PHP or just a documentation issue. Here's the simplest gist I could come up with that demonstrates this issue: https://3v4l.org/cdnV9
I think it makes sense to create an (empty) context for each connection so that setting context parameters does not affect other connections. :+1:
Note that this particular error is the result of a higher level race condition if you concurrently establish multiple TLS connections. I'm okay with not having any tests for this because testing this will likely couple this to our particular implementation.
FWIW: This only affects v0.4.5 (not v0.5.0+ nor v0.4.4) because all other versions actually assign a default context.

Depending who you'd ask it is either a bug in PHP or the intended default behavior. Personally I consider this a bug.
Yeah honestly not 100% sure how to test against this. Unless we're going to include integration
Glad to hear only v0.4.5 is affected, should a comment be added to this and the master branch regarding this? To ensure we don't accidentally remove it again

PHP's behaviour is by design, but the design is wrong.
There will be a fix incoming soon, just as soon as we've figured out exactly what the scope of the fix should be and how/where it should be implemented, and possibly whether some elements may require an RFC - the default stream context has it's fingers in a lot of pies and there are other things internally that may potentially modify a context from a stream reference. Whatever the exact fix turns out to be and whenever it lands, this issue will still persist in historical versions though, and while those versions are supported this approach is still required (so at least until 7.1 is no longer supported, and it's unlikely to land before 7.2.0 at this point).
The long of the short of it is this: if you always explicitly pass in a stream context at the point of stream creation, you won't ever have a problem with this issue. Obviously there are also valid cases where having a shared stream context is valid, but this should still be done explicitly rather than using the magical global state of the default context.
I notice that your UnixConnector currently doesn't pass a context, it would possibly be worth doing it there as well, to head any potential weirdness off at the pass?

As a side note, not everything will use a Connector for stream creation probably, so should probably put big fat warnings all over the docs about this issue as well.

Updated documentation to include a warning about this in the master and v0.4 release branches.
Tagged and released as v0.4.6, as v0.4.5 is the only version affected by this race condition.
Thanks everybody for tracking this down! :+1:


Add structure to solve optimization problems

An optimization problem can be set as follows
    @dataclasses.dataclass
    class SwitchVar(OptimizationObject):
        x: StorageType = default_storage_field(ContinuousVariable)
        y: StorageType = default_storage_field(ContinuousVariable)

        def __post_init__(self):
            self.x = np.zeros(1)
            self.y = np.zeros(1)

    a = 10
    new_problem = OptimizationProblem()
    new_variables = new_problem.generate_optimization_objects(SwitchVar())
    new_problem.add_expression(
        ExpressionType.minimize, a * new_variables.y * new_variables.y
    )
    new_problem.add_expression(
        ExpressionType.subject_to, new_variables.x + new_variables.y == a - 1
    )
    new_problem.add_expression(ExpressionType.minimize, new_variables.x == 5)
    output, cost_value = new_problem.solver().solve()

Note the line
new_problem.add_expression(ExpressionType.minimize, new_variables.x == 5)

Equalities can be cast into a cost. This might simplify the setting of tracking tasks.

Another suggestion would be to add named arguments to have a scaling when passing a costraint and cast it into a cost.

Done in https://github.com/ami-iit/hippopt/pull/4/commits/109859cd371d860eb18993ae3bedd249d5e4ca2c

@diegoferigo I should have addressed your comments (except https://github.com/ami-iit/hippopt/pull/4#discussion_r1154222309 where I am not sure how to continue).
I set the comments to resolved quite arbitrarily, so feel free to "Unresolve" the points that need some further discussion.
Let me know how you would like to proceed :wink:

I will proceed in merging this. Other open points will be addressed in future PRs.


Validate the /usr is read-only.

How to categorize this PR?

/kind test
/area os
/os garden-linux
What this PR does / why we need it:
Validates that the /usr directory is read-only.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

We should probably avoid adding new tests in test_gardenlinux.py and add this within the new feature PyTest structure. This would fit in features/base/tests/.

Hi @marwinski,
we do not really distinguish between unit- and integration tests after switching to PyTest anymore. All tests are based on PyTest. To have a short overview for the process of testing in general (unit, integration, platform tests) you may find a handy chart here: https://github.com/gardenlinux/gardenlinux/tree/main/tests#chart
As a result, it more or less is based on the used fixture if this is interpreted as a unit test (mostly chroot and kvm) or a platform test (ali, azure, gcp, ...) or gets called as an integration test where all of them may get applied if the fixtures are matching. For further information please check https://github.com/gardenlinux/gardenlinux/tree/main/tests#tests - if you're missing information feel free to raise an issue an assign this issue to me. I'll update the docs asap.
However, we still have the legacy part of tests/integration/test_gardenlinux.py and shouldn't add any new tests there even both are still sourced. Instead, we should use the new file structure where tests are placed in a feature's test folder (e.g. base/test/test_mount_usr.py). Next to this, I think this could become a more common test where different filesystems or mounts could get check in the near future. Therefore, we could make use of PyTest's parametrize feature and write something like this:
File: base/test/test_mounts_read_only.py
# Parametrize the test
@pytest.mark.parametrize(
     "mount, read_only",
     [
         ("/usr", True),
         ("/tmp", False)
     ]
 )

# Run the integration test
# Validate that mounts are readonly or not
def test_mounts_read_only(client, mount, read_only, non_chroot, non_kvm):
     do_magic_here(client, mount, read_only)

Maybe the movement from def test_apparmor(client, non_chroot): from the legacy one to the new layout could be helpful from this commit: https://github.com/gardenlinux/gardenlinux/commit/bcd2aa16f59c95cfd215f799b402f8759e523b4c
I hope this helps - feel free to task if anything is still unclear. I think we should shortly move the legacy content to the new style. Therefore, I just created #1222. We may discuss this in our today's weekly meeting.
Thanks,
gyptazy

pushed new version and moved test to features/base/test


Make Travis check formatting with Black

Black has been used to format the source previously. This adds a check and fails the build if the source is not correctly formatted. PR authors can fix the formatting by running black umap.

Hello @tomwhite! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file setup.py:

Line 41:20: E203 whitespace before ':'

This is failing because black isn't being installed, maybe because the build environment is cached?

I'm not really sure -- I have never been that good at this CI stuff. I'll try to look into it when I get some time; I'm kind of swamped with things right now.

If you want to use black, then you should relax the line limit to 88: https://github.com/python/black#line-length.

Try adding "black" to the dependencies in https://github.com/lmcinnes/umap/blob/b3816672c74f7963a79ad69186da60469484c14c/ci_scripts/install.sh#L29

Thanks @jamesmyatt. I'll see if I can get that sorted soon.

Thanks for the suggestion @jamesmyatt. It's getting a bit further now, but is failing one build as black isn't available on Python 2, and another build because the build environment is different in some way. This will need a bit more work...

We should just start ignoring python2. It is going to be end of life soon, and I have no particular desire to support it (and have pledged to drop support for it by Jan 1 2020 anyway, so we certainly do not ahve to provide any support after that).

The black test only needs to be carried out on one of the matrix entries, so one solution is only carrying it out on the coverage entry: it's already got its own branch of the bash script so there's no extra complexity added.
If you go this way, I also suggest doing the black check before the tests, rather than after. This way the check fails faster. Also the coverage checks often falsely fail the build due to negligible negative changes in coverage which would otherwise hide a "true" failure due to a forgotten reformatting.
Finally, I added a section about using black before submitting a PR to https://github.com/lmcinnes/pynndescent/blob/master/CONTRIBUTING.md -- it would probably be helpful to add that to this PR too (everything else in the pynndescent document is copy-and-pasted from UMAP, so this is a trivial change).

Thanks for the suggestions James. Here's another attempt.

Coverage remained the same at 94.544% when pulling f30b867023b85782e230cd5a7759219af6a8948f on tomwhite:enforce-black into 43ef61a681aa6e8caa62adf706025df4131c3ae7 on lmcinnes:master.

Sorry for being slow to get to this, but thanks for all the work people have put it. It is definitely appreciated. Merging now, and thanks again!


running install.sh wipes .zshrc file

Trying to update using install.sh wipes your .zshrc file replacing it with only
# Golang vars
export GOROOT=/usr/local/go
export GOPATH=\$HOME/go
export PATH=\$GOPATH/bin:\$GOROOT/bin:\$HOME/.local/bin:\$PATH

Now this quite possibly could've been something I accidentally done while getting some tools to work, but i'm leaning more towards something that was updated as it happened straight after it said there was an update available and ran the install.sh file.
To Reproduce
Steps to reproduce the behavior:

cd to reconftw folder
Run install file ./install.sh
Notice your terminal is different and it asks you repeatedly to make password for new keyring ( thats possibly once you run reconftw.sh )
Wonder WTF happened and check your .zshrc file to see all your settings etc are gone
Think you had a back up until you realise you don't and end up copy pasting roots .zshrc contents.

Start googling to see if there is a way to get the file back to however it was before it got replaced.
I haven't made it to step 8 yet. Will let you know.

Expected behavior
Running install.sh updates any tools that need updating and doesn't modify/overwrite important files that it doesnt need to touch
Desktop (please complete the following information):
Linux 6.6.9-rt-amd64 #1 SMP PREEMPT_RT Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
Additional
If someone could confirm it is an update that is doing it and not something I done, that would be great.

Something you have done, working fine for me.


Multi-Context Terminology & Concepts

STMicroelectronics contributed this document aiming to define a common set of terms and concepts for describing and managing multiple dependent projects as outlined in issue https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/issues/12
https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/files/7279772/Multi-Context_Concepts_OpenCMSIS.pdf
Proposal: Terminology and definitions shall be reviewed and discussed and added to the glossary once agreed

Hi all,
no comments so far, so can i go ahead with PRs to include it in the glossary ?
Thanks & Regards,
Fred

Important concepts to clarify:

Is the workspace the user's property where he can put whatever he wants ?
Based on that can the worksapce bring flexibility by including projects and layers ?
What flexibility do we really need at solution/application project level ?

Of course this also depends on how you see the tool : single instance multiple projects or multiple instances with 1 project each ?
I am more in favor of the first option to allow moving and copying artefacts between projects : a real "place to work" (workspace)

@fred-r I read again your definition of "Application Project". Unfortunately "Application" is often defined in computing encyclopedia as being only the top part of a software stack or solution stack. For this reason I believe the term "solution" is more adequate in the CMSIS Project Manager scenario similarly to the VS terminology.
Solution stack
In computing, a solution stack or software stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to "run on" or "run on top of" the resulting platform.

@fred-r I read again your definition of "Application Project". Unfortunately "Application" is often defined in computing encyclopedia as being only the top part of a software stack or solution stack. For this reason I believe the term "solution" is more adequate in the CMSIS Project Manager scenario similarly to the VS terminology.
Solution stack In computing, a solution stack or software stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to "run on" or "run on top of" the resulting platform.

Well, I agree that in TCP/IP model/stack for instance we have the application layer.
But, that's why I am not suggesting "Application" alone but "Application Project".
We may call it "application product" if you prefer: https://en.wikipedia.org/wiki/Application_software
What is important to me is this notion of an entity providing a service to the end-user so implementing the use-cases of the final product. To me we are clearly targeting an "Application Product" embedding the applicative part, the system software part and the required hardware to run it.
With solution, I am afraid we are focusing too much on the software only.
And here also we are touching a point of disagreement : to me an "Application Product" is comprising the hardware because it is fully dependent on the HW capabilities.
Your application software will very quickly diverge from one HW to another : not the same drivers, not the same buttons/leds/parts, not the same memory map.
So to me an "Application Project" or "Application product" is really targeting one hardware but it can reuse:

a same software project (or several)
or a same layer within a software project (or several)
from one "Application Project" to another.

This is where we factorize.
If we try factorizing at "Application project" level then we end up with many "profiles" with completely differetn components and settings.
We lose lots of clarity and I am not sure we gain flexibility : the layers and SW projects are there anyhow for this flexibility.
If on top of this we have a Workspace concept which is really the place where the user works then the user can have several "Application Projects" open in parallel and do copy/paste or whatever he wants to have some reuse and factorisation in the end.
Mixing everyhting under one generic term like "solution" would bring mainly confusion in my opinion and I am not sure the flexibility would be better.
Would you manage to keep one software project with low level layers ? Maybe if you implement lots of rules to select a component instead of another or apply a memory mapping instead of another based on...the hardware capabilities.
So, to me, it is easier to factorize the software layers which are generic (same code) but keep different "Application Projects" gathering the HW-dependent choices.

@0Grit and @ilg-ul: Did you have a look at these concepts and terminology ?
Would you agree with it ?

I went through the document until I noticed the red markings with 'ST Confidential'. Since I don't have an NDA with ST, I stopped.

I went through the document until I noticed the red markings with 'ST Confidential'. Since I don't have an NDA with ST, I stopped.

My bad : I forgot to remove this classification...the document is not confidential any more.

https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/pull/63

I would suggest that we review this concept.  From glancing over, looks similar to CMSIS-Zone, might be good to map the concept to CMSIS-Zone (perhaps with a table - see attempt below).  I think it highlights some missing pieces in CMSIS-Zone, for example the Initialization Context, Execution Modules, Execution Groups (concurrent execution).

ST multi-context
CMSIS-Zone
Description / Questions

Execution Context
Project Zone
A collection of resources that are allocated to one (or if no concurrent execution happens) project.

Since this deals also with TrustZone, I think we should map it to TF-M and see if there are gaps.

Regarding the execution context, I agree that it is quite coupled with the resources, you are right.
Besides, in the tool UI it might be overkill to distinguish this concept from the concept of execution domain.
But the intention was:

to have the execution context linking a software project with an HW execution unit
to have the execution context as the top level entity to gather several execution modules if needed
to have the execution context as the top level entity to address an execution domain and shared domain

Having the concepts of execution context and execution domain brings the possibility to define the shared execution domain (used by several execution contexts).
Disclaimer: we think it is good to split in different concepts the elements we need to handle. This allows a clear split of roles and better thinking. Nevertheless, all these concepts will not necessarily be shown to the end-user, the tool may very well abstract them for the sake of simplicity (example: the difference between execution context and execution domain is not needed for the end-user).

Fred are you ok with the terminology that we are today using or should we change anything?
Should we add a Glossary to the documentation?

Hi Reinhard,
we are finalizing an update of the terminology to address both Cortex-A and Cortex-M.
Based on this proposal (to be issued within 2 weeks), I think it would be good to update the glossary.