Description
items with emc and nbt put in projectexpansion:transmutation_interface will last 1
Minecraft Version
1.20.1
ProjectExpansion Version
1.0.0
Forge Version
47.2.19
Reproduction Steps
1 put projectexpansion:transmutation_interface and ae2:storage_bus
2 put items in ae like this Item.of('minecraft:iron_ingot', 64, "{display:{Name:'{"text":"ingot"}'}}")
3 it will be last 1
Crash Report/Logs

crash-2024-02-01_07.01.03-client.txt
latest.log
Other Mods

ATM 9 with projecte and this

1 item and 2 items can't be storged with no disk

Item.of('ae2:item_storage_cell_64k', '{amts:[L;1L],ic:1L,keys:[{"#c":"ae2:i",id:"minecraft:iron_ingot",tag:{display:{Name:'{"text":"ingot"}'}}}]}')

You might need to be a bit more clear about what you mean by "last 1".

last 1 item in ae

you can try yourself

I have no idea what you're getting at here, but I can't find any bug within basic usage of a transmutation interface

/give @p minecraft:iron_ingot{display:{Name:'{"text":"ingot"}'}} 64

I think the bug he's getting at is that the interface doesn't recognize an iron ingot with a different NBT tag as a plain iron ingot, which... isn't a bug, to my knowledge? The game uses NBT tags to differentiate other items like potions, so it makes sense that if you add an NBT tag to an item, it would stop registering that item as the same as one without that tag

If that is the problem, then yes, that's very much intentional
https://github.com/DonovanDMC/ProjectExpansion/wiki/Transmutation-Interface#nbt-filtering

it will be disappear，the num change from 64 to2

https://github.com/DonovanDMC/ProjectExpansion/assets/73775469/48f7e069-ee3c-47e9-ae3a-2ddbb2b69d6d


Release of v1.0.3

Coverage remained the same at 72.3% when pulling 40d952d2bcb2e18183a1c868299a925d81f87bd8 on releases into 8de1ed7bfaaf25e801abf4879a797f536b0b922e on master.


Error building Swift Matter smart light example for ESP32-C6

Hi there,
I'm facing issues while trying to build the smart light matter project. See details below:
System Information
Swift Version

Swift Version: Apple Swift version 6.0-dev
Target: x86_64-apple-macosx14.0

Software Installed

Matter, IDF, etc. installed correctly

Environment Setup

export.sh from IDF and Matter executed successfully
TOOLCHAIN points to the correct version
Running idf.py set-target esp32c6 works fine and confirms the Swift compiler identification as Apple 6.0

Problem Description
When attempting to build the project using idf.py build, I encounter the following error:
Executing action: all (aliases: build)
Running ninja in directory /Users/<usr>/Code/swift-matter-examples/smart-light/build
Executing "ninja all"...
ninja: error: 'esp-idf/main/CMakeFiles/__idf_main.dir/Main.swift.obj', needed by 'esp-idf/main/libmain.a', missing and no known rule to make it
ninja failed with exit code 1, output of the command is in the [...]smart-light/build/log/idf_py_stderr_output_22173 and [...]/smart-light/build/log/idf_py_stdout_output_22173

The logs do not provide further information.
Additional Information

The toolchain is correctly set up and recognized.
Other examples, like the ESP32-IDF Blink example, work without issues.

Request
Any guidance or suggestions to resolve this build issue would be greatly appreciated.
Best regards,
Jannik

I could identify the problem. My terminal targeted the wrong CMake version. I checked it with the which cmake command wich targeted the right version, but something was messed up on my side.
Anyways one thing bothers me: The CMakeLists.txt in the smart light example requires CMake version 3.5. The newest version is 3.30. It seems as if this check is never performed.
Can anybody verify this?

Ah, that's exactly where the problem is, thanks! The minimum CMake requires is 3.29, the "empty-template" and "led-blink" examples have that right, but it seems like the "smart-light" example needs to be updated.

@yaJannik does this resolve it? I think now you should get a clear error if you accidentally use an old CMake.

Yes, it solved the problem or more specific: It helps identifying the problem a lot.
Currently I'm stuck on another problem, but I'll open another issue later. The issue is closed. Thank you for the pull request.

Issues can be re-openened (it's GitHub's behavior to auto-close any issue that's mentioned in a merged PR). But yes, if it's a separate issue, best to open a new one.


added LICENSE

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

@ctot-nondef Pending your acceptance of the CLA I am happy to merge this.

all done, added tests in a different pull request

Looks good to me. Thank you for signing the CLA!


Change categorieId to match the tutorial

Hello, this is a small nitpick error:
On this page of the tutorial, we are given this example query for the Books service:
{
  books {
    authorId
    categoryId  // <-- this is the issue
    id
    title
  }
}

I just wanted to inform you that out of the box, this does not work. The error is because the field in the Book schema is called categorieId, not categoryId. Which might cause some confusion to readers.

Would you create a PR for this change? Thanks!

Would you create a PR for this change? Thanks!

Would it be enough for a PR to just replace all instances of the categorieId string with categoryId? Or do you think it'd require additional code changes @ardatan ?

Updated! Thanks for the feedback!


negative regulation of mRNA deadenylation

Hi
Is poly(A)tail shortening ; GO:0000289 the same as
mRNA deadenylation? I'm annotating a poly(A) binding
protein that prevents the deadenylation of mRNA
molecules to which it's bound, and I couldn't find a
GO term that covers this process precicesly.
If they are the same, could 'mRNA deadenylation'
please be added as a synonym of GO:0000289, and some
regulation (positive and negative) child terms
created.
The negative regulation of poly(A)tail
shortening/deadenylation could also be made a child
of mRNA stabilization ; GO:0048255 I think.
If they're not the same.... then I'll rethink.
Thanks,
Becky
Reported by: beckyfoulger
Original Ticket: "geneontology/ontology-requests/3270":https://sourceforge.net/p/geneontology/ontology-requests/3270

thanks www.movied.org


[Bug] WARN fetch_envelopes_by_sequence{client=1}: imap_client::tasks: skipping invalid fetch (2028 occurrences)

As I was sifting through thousands of mails with himalaya (great tool by the way!), I came across a weird instance where himalaya would report that my inbox only contained a single mail, whereas the ProtonMail web client reported a lot more.
Turning --debug on indicated that there were 2828 WARN fetch_envelopes_by_sequence{client=1}: imap_client::tasks: skipping invalid fetch warnings.
Context (Environment)
I'm using himalaya on a Windows laptop, with ProtonBridge running.
Other than the reported issue, and the occasional error/panic, it mostly works, I was able to create folders, move many mails to those folders, delete folders, etc.
Steps to Reproduce
I want to help pinpoint and troubleshoot this issue, but the logs contain tons of PII that I cannot share.
I was sadly unable to send myself a mail that would reproduce the issue.
I've taken some troubleshooting steps and have been able to eliminate some possible causes:

Envelope format produced by ProtonMail/ProtonBridge does not seem to be the cause, as all mails load fine in ThunderBird through ProtonBridge
Although non-ascii chars were present in the fields of a whooping 2824 out of 2828 envelopes, I was able to rule out this possible cause, as a mail containing "àéèç" in the subject were not affected
The emails come from multiple mail providers, there is no common pattern there, they come from Proton, Gmail, O365, etc.
Attachments are not the cause, as there are many envelopes with and without attachments within the invalid fetches.
Various combinations of --page-size and --page did not produce much difference. To get the 2828 warnings, I used the rather aggressive --page-size 10000

I am struggling to find more useful debugging steps, short of reading the code (which I may do this weekend, but being unfamiliar with IMAP and this codebase, I will probably struggle there too)
Here is one example of an invalid fetch:
2024-12-12T07:22:26.354595Z  WARN fetch_envelopes_by_sequence{client=1}: imap_client::tasks: skipping invalid fetch fetch="* 2829 FETCH (UID 2829 FLAGS (\\Flagged \\Seen) ENVELOPE (\"Sun, 29 May 2022 11:19:52 +0200\" \"[redacted]\" ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((NIL NIL \"[redacted]\" \"[redacted]\")) NIL NIL NIL<EMAIL_ADDRESS>BODYSTRUCTURE ((\"text\" \"html\" (\"charset\" \"utf-8\") NIL NIL \"quoted-printable\" 177 3 NIL NIL NIL NIL)(\"image\" \"jpeg\" (\"filename\" \"20220529_111616.jpg\" \"name\" \"20220529_111616.jpg\") \"<1810f1c27ce83dd33723>\" NIL \"base64\" 4877872 NIL (\"attachment\" (\"filename\" \"20220529_111616.jpg\")) NIL NIL)(\"image\" \"jpeg\" (\"filename\" \"20220529_111537.jpg\" \"name\" \"20220529_111537.jpg\") \"<1810f1c27fb526ec0f04>\" NIL \"base64\" 5090040 NIL (\"attachment\" (\"filename\" \"20220529_111537.jpg\")) NIL NIL)(\"image\" \"jpeg\" (\"filename\" \"20220529_111710.jpg\" \"name\" \"20220529_111710.jpg\") \"<1810f1c27bab86ee1ad2>\" NIL \"base64\" 5711388 NIL (\"attachment\" (\"filename\" \"20220529_111710.jpg\")) NIL NIL)(\"image\" \"jpeg\" (\"filename\" \"20220529_111721.jpg\" \"name\" \"20220529_111721.jpg\") \"<1810f1c27a5ba31d1cd1>\" NIL \"base64\" 5172832 NIL (\"attachment\" (\"filename\" \"20220529_111721.jpg\")) NIL NIL) \"mixed\" (\"boundary\" \"6d7f72d5d329be9d2b25a01e202c148edc6338fbe6d7be0ff33f5b3eff336e7a\") NIL NIL NIL))\r\n"

And here is a shorter one:
2024-12-12T07:45:43.592444Z  WARN fetch_envelopes_by_sequence{client=1}: imap_client::tasks: skipping invalid fetch fetch="* 1941 FETCH (UID 1941 FLAGS (\\Seen) ENVELOPE (\"Mon, 01 Jun 2015 07:46:41 +0000\" \"2.zip\" ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((\"[redacted]\" NIL \"[redacted]\" \"gmail.com\")) ((NIL NIL \"[redacted]\" \"gmail.com\")) NIL NIL NIL<EMAIL_ADDRESS>BODYSTRUCTURE (\"text\" \"html\" (\"charset\" \"utf-8\") NIL NIL \"quoted-printable\" 4781 62 NIL NIL NIL NIL))\r\n"

Is there any step I can make to help pinpoint this?
Expected Behavior
I'd expect himalaya to be able to handle these 2828 mails just fine, as ThunderBird is able to.
Current Behavior
Many WARN fetch_envelopes_by_sequence{client=1}: imap_client::tasks: skipping invalid fetch warnings

I cannot investigate right now, but it may be related to https://github.com/modern-email/defects/issues/38.


Add new helper functions

PR#26 included  code checking . Please accept it

@priyalalK please rebase and update the PR as current work is outdated.

These helpers will be converted in to TypeScript and the JS file will be removed. Any code quality issues will be fixed there..


Move over to yarn workspaces for managing local dependencies

Yarn workspaces seems to be better than Lerna's built-in method of installing shared dependencies in a monorepo.  https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/#managing-dependencies-of-workspaces
As of Lerna 2.0, you can actually integrate workspaces with Lerna pretty seamlessly.  So use yarn workspaces for dependencies and Lerna for publishing.
Yarn workspaces also would give us the option of managing multiple mono repos which we might be able to add to the cli.

It's worth trying.
Something to watch out for, yarn workspaces significantly changes how the node_modules folders are structured.
The new structure can cause issues with peer dependencies in child packages.
For example ESLint plugins are expected to be a sibling/peer of the ESLint CLI that is running them.
Occasionally, one of the peer dependencies will get hoisted to the top level node_modules and the other will be in a child node_modules, when this happens both packages are broken.
Hopefully, that is not something that will come up for wcfactory.

Thanks for the heads up!  Definitely something to be on the lookout for.

@ChristianMurphy might be helpful for debugging if we run into what you just described.

If you’re only making changes to a single workspace, use –focus to quickly install sibling dependencies from the registry rather than building all of them from scratch.

https://yarnpkg.com/lang/en/docs/workspaces/#toc-tips-tricks


Doesn't highlight next prop correctly if the previous prop doesn't end with a semicolon.

Yes, I've read the BP section (https://github.com/y0ssar1an/CSS3#best-practices) that states "End every property declaration with a semicolon."
However there is a minifier CLI utility (https://www.npmjs.com/package/minifier) that formats the code removing semicolons from the last prop and CSS3 doesn't highlight correctly any more:

Is there a way to change this behavior? Some true/false option in config?

Every property must end with a semi-colon. It's in the readme.
https://github.com/y0ssar1an/CSS3#best-practices

Be sure, I read that.
I'm asking is there an option to control it?

There's no option, sorry. The syntax highlighter depends on those semicolons being there to differentiate between selectors and properties. I understand this breaks highlighting for minified CSS, but it would require a major overhaul. I'll try to get minified CSS working with the sublime-syntax rewrite, but no promises.


Support Screens / Shutters in Home Assitant (Casambi)

Is there any chance to support Up and Down screens via Home Assistant and Casambi?
In my Casambi App I don’t have the option to chose the final position it’s just a button Up or Down (see picture). I tried to use them as a light in HA but there is no movement when changing the status

As an alternative I can use the native Casambi App
I don't have developpement skills but will be happy to support you to test or capture any usefull information

Casambi is not supporting this in its api:

Thank you for contacting Casambi support.

If the feature is not mentioned in our developer documentation, then it's unfortunately not supported. The API only offers "limited" functions for lighting control.

Apologies for the inconvenience.

Please create a feature request to casambi, api in question that the integration uses: https://developer.casambi.com/


feat: allow connecting to http localhost nodes

Summary

Closes #7626

...
Changelog
- Please write a list of changes

Testing
Platforms

Please select any platforms where your changes have been tested.

Desktop

[ ] MacOS
[ ] Linux
[ ] Windows

Instructions

Please describe the specific instructions, configurations, and/or test cases necessary to test and verify that your changes work as intended.

...
Checklist

Please tick the following boxes that are relevant to your changes.

[ ] I have followed the contribution guidelines for this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or modified tests that prove my changes work as intended
[ ] I have verified that new and existing unit tests pass locally with my changes
[ ] I have verified that my latest changes pass CI workflows for testing and linting
[ ] I have made corresponding changes to the documentation

I have no idea if this is a place to comment but I firstly dig IOTA,shame I didn't stake on the shimmer choice but that is mine. But, I have seemed to have lost, or misplaced the staked IOTA. Yes, it was backed up by the Stronghold feature, as well as always having a seed phrase.....but it's not there anymore. It is not in my wallet, with the same password and PIN number too. I'm confused and don't have the computer knowledge to kinda understand what has happened. Kind regards Jedd

Good morning! first of all, don't worry, the funds cannot be lost, they exist on the tangle! maybe you have an outdated version of Firefly and need to update it. You can download the latest version on the Firefly website and try restoring your profile with the stronghold file. If the issue persists, it might be best to communicate your problem on the Firefly Discord channel, as it is the official channel for these types of cases, I hope this would help! :pray:


expected subsets ordering on METADATA.pb

This caught my attention today when running fb on Merriweather:
ERROR METADATA.pb subsets are not sorted in alphabetical order: Got ['cyrillic', 'cyrillic-ext', 'latin', 'latin-ext', 'menu'] and expected ['menu', 'cyrillic', 'cyrillic-ext', 'latin', 'latin-ext']

At first I thought that the criteria was to place "menu" as the first item and then all the rest in alphabetical order, but the error above was reported for Merriweather and it seems it is sorting all items and placing "menu" after "latin-ext" instead of as the first item.
Should we accept both ?

The menu first thing was old; I'm not using whatever add_font.py outputs which is true alphabetical, so FB should reflect that:
~/fonts/tools $ python add_font.py ../ofl/merriweather;
~/fonts/tools $ tail -n 5 ../ofl/merriweather/METADATA.pb;
subsets: "cyrillic"
subsets: "cyrillic-ext"
subsets: "latin"
subsets: "latin-ext"
subsets: "menu"

menu and latin should always be present, and if they aren't we should warn

I'm still getting this error.
It is present in 100% of the repos I've come across. I'm using add_font.py to generate METADATA.pb files. I've been ignoring it so far
Does the order really matter?
If it ain't broke, don't fix it comes to mind.
As @davelab6 said, it would be nice to check if 'Menu' and 'Latin' were present.

@davelab6 should the METADATA.pb of all old font projects be fixed to pass this check? Or should the check be dropped ?

It is present in 100% of the old repos I've come across. Yes, add_font.py does make it alphabetical.

Right - the old repos were made at a time when the menu and latin subsets were ordered first, but now that is not the case. They should be updated to be alphabetical.

should the METADATA.pb of all old font projects be fixed to pass this check? Or should the check be dropped ?

Yes, they should; but since it will be a bit of a pain, if you can write a specific fixer for this, I can schedule fixing in the future.

ok, cool! Lets automate that fix .-)

ok, cool! Lets automate that fix .-)

Yes, but later :)

If it ain't broke, don't fix it comes to mind.

@m4rc1e please update the METADATA files that you touch to resolve this

ok

@m4rc1e please update the METADATA files that you touch to resolve this

Ok

Lets automate that fix :-)

So, to resolve this issue, FB should reorder the subsets if a METADATA exists with out-of-order subsets?

yep! That's what I intend to do. If FB detects an unordered list of subsets, then the METADATA.pb file should be rewritten by FB with the correct order.

@m4rc1e do you think we need a singleton tool for this?

@davelab6 I thought about writing this.
Personally, I would prefer FB not to hot fix, unless you explicitly tell it to. Making this auto every time, feels incredibly dangerous.
If we do add this as a hot fix option, there's no need for a standalone script. I'm cool either way.
I'm thinking we need some collection wide fixes in the google/fonts repo. Running the new ttfauothint on all fonts and reordering METADATA.pb, would significantly boost the quality all round.

All autofixing is hidden behind an --autofix arg, but I think it would indeed be better to have all singleton autofix tools and a BFG shell script that can apply them all, and then zero linter-arg-based hotfix functionality.
@felipesanches please make a singleton tool for this.

ok.
what is BFG?

you're talking about this? https://rtyley.github.io/bfg-repo-cleaner/

https://en.wikipedia.org/wiki/BFG_(weapon)

Alrrrriiight !!1 :-)

@felipesanches what is the current status of this?


Update build.sbt

Coverage remained the same at 100.0% when pulling 0003de3817b8cc7fbe04a4ad29689e37a4c97e52 on stream into 80312fb9083d61b0d88534a35afd22b0b3810e7e on master.

Coverage remained the same at 100.0% when pulling dcf097545a33a3df1ed4fc66be664c6b6cfb8a10 on stream into 80312fb9083d61b0d88534a35afd22b0b3810e7e on master.


Fix root index bug

Looks good. You mentioned in passing more you wanted to do on this, I think in the case where there is no filepath. Did you want to go into that in this PR?

I think merge this as-is.
Sorting out how to handle the case of None is tricky as this feature forced a whole bunch of file-specific assumptions into the code and we need this bug fix before we have to to go back and sort that out.


Add GPL API docs

Adds GPL API docs
Adds GPL guides to 1.5 release docs

@agnieszka-m please have a look

Closing, replaced by https://github.com/deepset-ai/haystack-website/pull/343


Translate navigation bar

I want translate Chinese navigation bar to English one using JQuary.

waiting for your new pr. thanks.


Installing via Helm over Installing via Operator - can't see logs, outboundTrafficPolicy is ALLOW_ANY

Bug Description
Due to the Istiio mainteners policy over deprecation of installing istio via operator which I am not happy with I have to migrate to helm for my brand new k8s deployment. OK. But, I can't get the same effect I have got with an operator.
There is an info that helm chart is almost the same as the operator. If yes, why this does not work (It's a terraform code but it's so easy to grasp that I do not even put here values.yaml):
resource "helm_release" "istiod" {
  name       = "istiod"
  repository = "https://istio-release.storage.googleapis.com/charts"
  chart      = "istiod"
  version    = null #the latest
  namespace  = "istio-system"

  set {
    name  = "meshConfig.accessLogFile"
    value = "/dev/stdout"
  }

  set {
    name  = "meshConfig.outboundTrafficPolicy.mode"
    value = "REGISTRY_ONLY"
  }

  //more settings not related to the issue, e.g. global.hub, global.imagePullSecrets... are commented
  //...
}

My istio sidecars do not log traffic and outbout policy is not restrictive. In the doc that is pointed out that this is enough to configure the log, but I do not think so.
What is missing in that config? Any help is appreciated.
P.S. I treat it as a bug, because there is no good doc on that and now there is no stable method of installation in DevOps processes (operator is deprecated, and helm is still in aplpha).
Version
client version: 1.13.2
control plane version: 1.13.3
data plane version: 1.13.3 (9 proxies)

Additional Information
No response

do not reproduce this, maybe somethings error with tf?
root@ecs-istiodev:~# helm install istio-base istio/base -n istio-system
root@ecs-istiodev:~# helm install istiod istio/istiod --namespace istio-system --set meshConfig.accessLogFile=/dev/stdout
root@ecs-istiodev:~# k get cm -nistio-system istio -oyaml | grep accessLog
    accessLogFile: /dev/stdout

do not reproduce this, maybe somethings error with tf?
root@ecs-istiodev:~# helm install istio-base istio/base -n istio-system
root@ecs-istiodev:~# helm install istiod istio/istiod --namespace istio-system --set meshConfig.accessLogFile=/dev/stdout
root@ecs-istiodev:~# k get cm -nistio-system istio -oyaml | grep accessLog
    accessLogFile: /dev/stdout

My releas values after the terraform application:
base:
  enableIstioConfigCRDs: true
global:
  caAddress: ""
  caName: ""
  configCluster: false
  defaultPodDisruptionBudget:
    enabled: true
  defaultResources:
    requests:
      cpu: 10m
  externalIstiod: false
  hub: nexus-docker.opl.tools/istio
  imagePullPolicy: ""
  imagePullSecrets:
  - regcred-nexus
  istioNamespace: istio-system
  istiod:
    enableAnalysis: false
  jwtPolicy: third-party-jwt
  logAsJson: false
  logging:
    level: default:info
  meshID: ""
  meshNetworks: {}
  mountMtlsCerts: false
  multiCluster:
    clusterName: ""
    enabled: false
  network: ""
  omitSidecarInjectorConfigMap: false
  oneNamespace: false
  operatorManageWebhooks: false
  pilotCertProvider: istiod
  priorityClassName: ""
  proxy:
    autoInject: enabled
    clusterDomain: cluster.local
    componentLogLevel: misc:error
    enableCoreDump: false
    excludeIPRanges: ""
    excludeInboundPorts: ""
    excludeOutboundPorts: ""
    holdApplicationUntilProxyStarts: false
    image: proxyv2
    includeIPRanges: '*'
    includeInboundPorts: '*'
    includeOutboundPorts: ""
    logLevel: warning
    privileged: false
    readinessFailureThreshold: 30
    readinessInitialDelaySeconds: 1
    readinessPeriodSeconds: 2
    resources:
      limits:
        cpu: 2000m
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 128Mi
    statusPort: 15020
    tracer: zipkin
  proxy_init:
    image: proxyv2
    resources:
      limits:
        cpu: 2000m
        memory: 1024Mi
      requests:
        cpu: 10m
        memory: 10Mi
  remotePilotAddress: ""
  sds:
    token:
      aud: istio-ca
  sts:
    servicePort: 0
  tag: 1.13.3
  tracer:
    datadog:
      address: $(HOST_IP):8126
    lightstep:
      accessToken: ""
      address: ""
    stackdriver:
      debug: false
      maxNumberOfAnnotations: 200
      maxNumberOfAttributes: 200
      maxNumberOfMessageEvents: 200
    zipkin:
      address: ""
  useMCP: false
istiodRemote:
  injectionPath: /inject
  injectionURL: ""
meshConfig:
  accessLogFile: /dev/stdout
  defaultConfig:
    proxyMetadata:
      ISTIO_META_DNS_CAPTURE: true
  enablePrometheusMerge: true
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  rootNamespace: null
  trustDomain: cluster.local
ownerName: ""
pilot:
  autoscaleEnabled: true
  autoscaleMax: 5
  autoscaleMin: 1
  configMap: true
  configSource:
    subscribedResources: []
  cpu:
    targetAverageUtilization: 80
  deploymentLabels: {}
  enableProtocolSniffingForInbound: true
  enableProtocolSniffingForOutbound: true
  env: {}
  hub: ""
  image: pilot
  jwksResolverExtraRootCA: ""
  keepaliveMaxServerConnectionAge: 30m
  nodeSelector: {}
  plugins: []
  podAnnotations: {}
  podLabels: {}
  replicaCount: 1
  resources:
    requests:
      cpu: 500m
      memory: 2048Mi
  rollingMaxSurge: 100%
  rollingMaxUnavailable: 25%
  serviceAnnotations: {}
  tag: ""
  traceSampling: 1
revision: ""
revisionTags: []
sidecarInjectorWebhook:
  alwaysInjectSelector: []
  defaultTemplates: []
  enableNamespacesByDefault: false
  injectedAnnotations: {}
  neverInjectSelector: []
  objectSelector:
    autoInject: true
    enabled: true
  rewriteAppHTTPProbe: true
  templates: {}
telemetry:
  enabled: true
  v2:
    accessLogPolicy:
      enabled: false
      logWindowDuration: 43200s
    enabled: true
    metadataExchange:
      wasmEnabled: false
    prometheus:
      configOverride:
        gateway: {}
        inboundSidecar: {}
        outboundSidecar: {}
      enabled: true
      wasmEnabled: false
    stackdriver:
      configOverride: {}
      disableOutbound: false
      enabled: false
      logging: false
      monitoring: false
      topology: false

the configuration looks good, how did you verify the accesslog?

The esiest way.
Config part:
k create ns test
k label ns test istio-injection=enabled
k run -i --tty --image=curlimages/curl curl --restart=Never --rm /bin/sh  -n test

Double check part (waiting for warnings for all the components):
istioctl pc log -n test curl
active loggers:
  admin: warning
  alternate_protocols_cache: warning
  ...
  wasm: warning

Testing part (we do not use SNAT in private VPC for our private GKE, we can egressing only via squid ;)):
/ $ curl -vI https://www.onet.pl
*   Trying <IP_ADDRESS>:443...
* Connected to www.onet.pl (<IP_ADDRESS>) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /cacert.pem
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to www.onet.pl:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to www.onet.pl:443

/ $ export https_proxy=[redacted]:3128
/ $ curl -vI https://www.onet.pl
* Uses proxy env variable https_proxy == '[redacted]:3128'
*   Trying <IP_ADDRESS>:3128...
* Connected to [redacted] (<IP_ADDRESS>) port 3128 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to www.onet.pl:443
> CONNECT www.onet.pl:443 HTTP/1.1
> Host: www.onet.pl:443
> User-Agent: curl/7.83.0-DEV
> Proxy-Connection: Keep-Alive
>
* Proxy CONNECT aborted
* CONNECT phase completed
* Closing connection 0
curl: (56) Proxy CONNECT aborted

What curl side-car logs:
proxyAdminPort: 15000                                                                                │
│ serviceCluster: istio-proxy                                                                                │
│ statNameLength: 189                                                                                │
│ statusPort: 15020                                                                                │
│ terminationDrainDuration: 5s                                                                                │
│ tracing:                                                                                │
│   zipkin:                                                                                │
│     address: zipkin.istio-system:9411                                                                                │
│                                                                                │
│ 2022-05-11T08:52:47.854415Z    info    JWT policy is third-party-jwt                                                                                │
│ 2022-05-11T08:52:47.856018Z    error    error in getting aws info for iam/info : unexpected status 404                                                                                │
│ 2022-05-11T08:52:47.856133Z    info    platform detected is GCP                                                                                │
│ 2022-05-11T08:52:47.856512Z    info    CA Endpoint istiod.istio-system.svc:15012, provider Citadel                                                                                │
│ 2022-05-11T08:52:47.856558Z    info    Using CA istiod.istio-system.svc:15012 cert with certs: var/run/secrets/istio/root-cert.pem                                                         │
│ 2022-05-11T08:52:47.856571Z    info    Opening status port 15020                                                                                │
│ 2022-05-11T08:52:47.856694Z    info    citadelclient    Citadel client using custom root cert: var/run/secrets/istio/root-cert.pem                                                         │
│ 2022-05-11T08:52:47.882153Z    info    ads    All caches have been synced up in 37.510378ms, marking server ready                                                                          │
│ 2022-05-11T08:52:47.882740Z    info    sds    SDS server for workload certificates started, listening on "etc/istio/proxy/SDS"                                                             │
│ 2022-05-11T08:52:47.882790Z    info    xdsproxy    Initializing with upstream address "istiod.istio-system.svc:15012" and cluster "Kubernetes"                                             │
│ 2022-05-11T08:52:47.883201Z    info    sds    Starting SDS grpc server                                                                                │
│ 2022-05-11T08:52:47.883411Z    info    starting Http service at <IP_ADDRESS>:15004                                                                                │
│ 2022-05-11T08:52:47.892426Z    info    Pilot SAN: [istiod.istio-system.svc]                                                                                │
│ 2022-05-11T08:52:47.894612Z    info    Starting proxy agent                                                                                │
│ 2022-05-11T08:52:47.894668Z    info    Epoch 0 starting                                                                                │
│ 2022-05-11T08:52:47.894710Z    info    Envoy command: [-c etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --drain-strategy immediate --parent-shutdown-time-s 60 --loc │
│ 2022-05-11T08:52:48.006358Z    info    xdsproxy    connected to upstream XDS server: istiod.istio-system.svc:15012                                                                         │
│ 2022-05-11T08:52:48.034991Z    info    ads    ADS: new connection for node:curl.test-1                                                                                │
│ 2022-05-11T08:52:48.075238Z    info    ads    ADS: new connection for node:curl.test-2                                                                                │
│ 2022-05-11T08:52:48.151416Z    info    cache    generated new workload certificate    latency=268.456048ms ttl=23h59m59.8486046s                                                           │
│ 2022-05-11T08:52:48.151479Z    info    cache    Root cert has changed, start rotating root cert                                                                                │
│ 2022-05-11T08:52:48.151500Z    info    ads    XDS: Incremental Pushing:0 ConnectedEndpoints:2 Version:                                                                                │
│ 2022-05-11T08:52:48.151606Z    info    cache    returned workload trust anchor from cache    ttl=23h59m59.84840185s                                                                        │
│ 2022-05-11T08:52:48.151625Z    info    cache    returned workload certificate from cache    ttl=23h59m59.84837837s                                                                         │
│ 2022-05-11T08:52:48.151843Z    info    cache    returned workload trust anchor from cache    ttl=23h59m59.848176901s                                                                       │
│ 2022-05-11T08:52:48.152317Z    info    ads    SDS: PUSH request for node:curl.test resources:1 size:4.0kB resource:default                                                                 │
│ 2022-05-11T08:52:48.152542Z    info    ads    SDS: PUSH request for node:curl.test resources:1 size:1.1kB resource:ROOTCA                                                                  │
│ 2022-05-11T08:52:48.152640Z    info    cache    returned workload trust anchor from cache    ttl=23h59m59.847366699s                                                                       │
│ 2022-05-11T08:52:48.152686Z    info    ads    SDS: PUSH for node:curl.test resources:1 size:1.1kB resource:ROOTCA                                                                          │
│ 2022-05-11T08:52:48.740215Z    info    Readiness succeeded in 893.930347ms                                                                                │
│ 2022-05-11T08:52:48.741018Z    info    Envoy proxy is ready

Nothing about the traffic. I've got two other clusters installed via istio operator and I've nothing to raise an issue there - logging carries out smoothly.

My follow-up:
If I change log level to debug (only debug) I see the logs:
istioctl pc log -n test curl  --level debug

Then:
2022-05-11T12:19:59.192214Z    debug    envoy conn_handler    [C204] new connection from <IP_ADDRESS>:59636                                                                              │
│ 2022-05-11T12:19:59.192287Z    debug    envoy http    [C204] new stream                                                                                │
│ 2022-05-11T12:19:59.192427Z    debug    envoy http    [C204][S14272335386247744543] request headers complete (end_stream=true):                                                            │
│ ':authority', 'www.onet.pl'                                                                                │
│ ':path', '/'                                                                                │
│ ':method', 'GET'                                                                                │
│ 'user-agent', 'curl/7.83.1-DEV'                                                                                │
│ 'accept', '*/*'                                                                                │
│                                                                                │
│ 2022-05-11T12:19:59.192445Z    debug    envoy http    [C204][S14272335386247744543] request end stream                                                                                │
│ 2022-05-11T12:19:59.192603Z    debug    envoy filter    override with 3 ALPNs                                                                                │
│ 2022-05-11T12:19:59.192648Z    debug    envoy router    [C204][S14272335386247744543] cluster 'PassthroughCluster' match for URL '/'                                                       │
│ 2022-05-11T12:19:59.192681Z    debug    envoy upstream    transport socket match, socket default selected for host with address <IP_ADDRESS>:80                                           │
│ 2022-05-11T12:19:59.192694Z    debug    envoy upstream    Created host <IP_ADDRESS>:80.                                                                                │
│ 2022-05-11T12:19:59.192781Z    debug    envoy router    [C204][S14272335386247744543] router decoding headers:                                                                             │
│ ':authority', 'www.onet.pl'                                                                                │
│ ':path', '/'                                                                                │
│ ':method', 'GET'                                                                                │
│ ':scheme', 'http'                                                                                │
│ 'user-agent', 'curl/7.83.1-DEV'                                                                                │
│ 'accept', '*/*'                                                                                │
│ 'x-forwarded-proto', 'http'                                                                                │
│ 'x-request-id', '004e335d-d30c-424b-bc6b-de1b19a57166'                                                                                │
│ 'x-envoy-peer-metadata', 'ChgKDkFQUF9DT05UQUlORVJTEgYaBGN1cmwKGgoKQ0xVU1RFUl9JRBIMGgpLdWJlcm5ldGVzChkKDUlTVElPX1ZFUlNJT04SCBoGMS4xMy4zCp8BCgZMQUJFTFMSlAEqkQEKDQoDcnVuEgYaBGN1cmwKJAoZc2Vj │
│ 'x-envoy-peer-metadata-id', 'sidecar~<IP_ADDRESS>~curl.test~test.svc.cluster.local'                                                                                │
│ 'x-envoy-attempt-count', '1'                                                                                │
│ 'x-b3-traceid', 'de5685f7c507181afa382fbafef2910f'                                                                                │
│ 'x-b3-spanid', 'fa382fbafef2910f'                                                                                │
│ 'x-b3-sampled', '0'                                                                                │
│                                                                                │
│ 2022-05-11T12:19:59.192797Z    debug    envoy pool    queueing stream due to no available connections                                                                                │
│ 2022-05-11T12:19:59.192801Z    debug    envoy pool    trying to create new connection                                                                                │
│ 2022-05-11T12:19:59.192807Z    debug    envoy pool    creating a new connection                                                                                │
│ 2022-05-11T12:19:59.192858Z    debug    envoy upstream    addHost() adding <IP_ADDRESS>:80

The said thing is it goes over PassthrougCluster not  BlacHkoleCluster. I am shocked and confused :)

can you run istioctl bug-report and share the output? that would help us to debug.

I've excluded a couple of namespaces.
bug-report.tar.gz

@zirain any thoughts?

2022-05-08T03:24:28.663558Z	info	mesh configuration: {
    "proxyListenPort": 15001,
    "connectTimeout": "10s",
    "protocolDetectionTimeout": "0s",
    "ingressClass": "istio",
    "ingressService": "istio-ingressgateway",
    "ingressControllerMode": "STRICT",
    "enableTracing": true,
    "defaultConfig": {
        "configPath": "./etc/istio/proxy",
        "binaryPath": "/usr/local/bin/envoy",
        "serviceCluster": "istio-proxy",
        "drainDuration": "45s",
        "parentShutdownDuration": "60s",
        "discoveryAddress": "istiod.istio-system.svc:15012",
        "proxyAdminPort": 15000,
        "controlPlaneAuthPolicy": "MUTUAL_TLS",
        "statNameLength": 189,
        "concurrency": 2,
        "tracing": {
            "zipkin": {
                "address": "zipkin.istio-system:9411"
            }
        },
        "statusPort": 15020,
        "terminationDrainDuration": "5s"
    },
    "outboundTrafficPolicy": {
        "mode": "ALLOW_ANY"
    },
    "enableAutoMtls": true,
    "trustDomain": "cluster.local",
    "trustDomainAliases": [
    ],
    "defaultServiceExportTo": [
        "*"
    ],
    "defaultVirtualServiceExportTo": [
        "*"
    ],
    "defaultDestinationRuleExportTo": [
        "*"
    ],
    "rootNamespace": "istio-system",
    "localityLbSetting": {
        "enabled": true
    },
    "dnsRefreshRate": "5s",
    "certificates": [
    ],
    "thriftConfig": {

    },
    "serviceSettings": [
    ],
    "extensionProviders": [
        {
            "name": "prometheus",
            "prometheus": {

            }
        },
        {
            "name": "stackdriver",
            "stackdriver": {

            }
        },
        {
            "name": "envoy",
            "envoyFileAccessLog": {
                "path": "/dev/stdout"
            }
        }
    ],
    "defaultProviders": {

    }
}

the MeshConfig seems not changes, looks like some issue with tf.

mostly the follow set not working
 set {
    name  = "meshConfig.accessLogFile"
    value = "/dev/stdout"
  }

  set {
    name  = "meshConfig.outboundTrafficPolicy.mode"
    value = "REGISTRY_ONLY"
  }

mostly the follow set not working
 set {
    name  = "meshConfig.accessLogFile"
    value = "/dev/stdout"
  }

  set {
    name  = "meshConfig.outboundTrafficPolicy.mode"
    value = "REGISTRY_ONLY"
  }

I would be good if it's tf. I'm going to change the approach with application of values.yaml into helm_release and I'll let you know.

@MaciekLeks I try this simple demo, it work as expected.
root@ecs-istiodev:~/GoProjects/src/playground/istio/tf# k get cm istio -nistio-system -oyaml
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    defaultConfig:
      discoveryAddress: istiod.istio-system.svc:15012
      tracing:
        zipkin:
          address: zipkin.istio-system:9411
    enablePrometheusMerge: true
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY
    rootNamespace: null
    trustDomain: cluster.local
  meshNetworks: 'networks: {}'
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: istiod
    meta.helm.sh/release-namespace: istio-system
  creationTimestamp: "2022-05-16T01:30:59Z"
  labels:
    app.kubernetes.io/managed-by: Helm
    install.operator.istio.io/owning-resource: unknown
    istio.io/rev: default
    operator.istio.io/component: Pilot
    release: istiod
  name: istio
  namespace: istio-system
  resourceVersion: "472810"
  uid: 31c4d5ca-195f-4922-983b-4b9abfcd7b69

OK, I found it. The problematic code:
set { #this version works but the previous one which looked the same genereted issued problems
    name  = "meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE"
    value = "true"
  }

I could have some encoding probles or something else but the same effect I got when using the values.yml with bad formatiing:
meshConfig:
  accessLogFile: /dev/stdout
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY #two whitespaces - OK
  defaultConfig:
   proxyMetadata: #bad formatting: only one whitespace - BAD
    ISTIO_META_DNS_CAPTURE: true #bad formatting only one whitespace - BAD

So, bad formatting, bad encoding or whatever brings a big mess because istio says it's OK (even the isio cm seems to be OK) but it's not OK.
Conslusion for other users:

if your istio cm looks OK
your debug trace shows you something different
e.g. you can't see logs or your mesh does not bahave like you expected (e.g. REGISTRY_ONLY outbound traffic policy)
definetly you have problem in your meshSettings: encoding, formatting,...

Suggestion for the maintainers:

add missing key/valus into the default values.yml (e.g. accessLogFile, defaultConfig,...)

@zirain thank you for your help and time - please have a look at my suggestion; I'm not the only one who struggles with this - I found quite simmilar issue on discuss istio forum How to configure global outboundTrafficPolicy with Helm install?](https://discuss.istio.io/t/how-to-configure-global-outboundtrafficpolicy-with-helm-install/10690)


kubectx and fzf selection broken

when i run kubectx or kubens the last option has this weird rgb string as prefix.
i'm using fish.
any ideas?

Please try in bash or zsh see if it happens
Whats your fzf version
Whats your kubectx version (and is it the bash implementation or the Go binary)

Closing due to inactivity but let me know if you have answers then I can reopen.


Encode column names with encoding of context

We detected some behaviour which might lead to some unexpected failures when migrating from the mysql2 Adapter to the trilogy adapter.
In the result set returned by a query, one can access the column names using the fields attribute, however the encoding of these strings is different from the encoding of the database.
Behaviour in mysql2:
When a query is executed via the database adapter (or rather its client), the column names (in the attribute fields of the result) respect the encoding set for the database connection. Running a query on a database with encoding: utf8mb4 specified in the client creation respects this encoding for the column names, returning the strings with Encoding:UTF-8 encoding.
Behaviour in trilogy:
Running the same query on the same database using the trilogy adapter returns the column names encoded with Encoding:US-ASCII, ignoring the database encoding.
This might lead to some unexpected encoding issues when the client uses the names from the query to further process the data.
Tests:
Behaviour with mysql2 Adapter:
client = Mysql2::Client.new(host: '<IP_ADDRESS>', port: 3306, username: 'root', encoding: 'utf8mb4', collation: 'utf8mb4_unicode_520_ci', database: 'mydatabase')

if client.ping
  result = client.query('SELECT * FROM users LIMIT 10')
  puts result.fields.map(&:encoding).join(', ')
end

Result: UTF-8, UTF-8, UTF-8, UTF-8, UTF-8, UTF-8, UTF-8
Behaviour with trilogy 2.9.0:
client = Trilogy.new(host: '<IP_ADDRESS>', port: 3306, username: 'root', encoding: 'utf8mb4', collation: 'utf8mb4_unicode_520_ci', database: 'mydatabase')

if client.ping
  result = client.query('SELECT * FROM users LIMIT 10')
  puts result.fields.map(&:encoding).join(', ')
end

Result: US-ASCII, US-ASCII, US-ASCII, US-ASCII, US-ASCII, US-ASCII, US-ASCII
Behaviour after patch:
client = Trilogy.new(host: '<IP_ADDRESS>', port: 3306, username: 'root', encoding: 'utf8mb4', collation: 'utf8mb4_unicode_520_ci', database: 'mydatabase')

if client.ping
  result = client.query('SELECT * FROM users LIMIT 10')
  puts result.fields.map(&:encoding).join(', ')
end

Result with patch: UTF-8, UTF-8, UTF-8, UTF-8, UTF-8, UTF-8, UTF-8

With this patch, trilogy returns the strings in the same encoding as the database, which matches the behaviour of the previous used mysql2 adapter.
I am not sure whether simply returning the strings in ASCII encoding is a deliberate choice or not, therefore feel free to accept or reject this PR, both is fine, I wanted to bring this to attention.
Let me know if you need any other informations, and I'd appreciate someone looking at my usage of Ruby C-API methods to ensure everything is used in its intended way, as I have only limited experience with the C-API.
The CI passed in my fork, see here and here.
Have a pleasant day!

Looks good to me now, but I'm not a maintainer so I can't merge.

@byroot Great, thanks for reviewing, in that case let's wait for someone from the maintainers to review this as well :)

Makes sense to me. It's still not quite the same as mysql2, which uses the default internal encoding, but that might also be fine—we are not obligated to match mysql2 behavior.

Makes sense to me. It's still not quite the same as mysql2, which uses the default internal encoding, but that might also be fine—we are not obligated to match mysql2 behavior.

Not matching the exact mysql2 behaviour is totally fine, I only mentioned this because it broke some code that relied on non-ascii encoding of column names :)
Let me know if you need me to change anything else for you to be able to accept this PR 😄


Copy error about Campus Experts in /explore

Copy is the same as the open source guides (which I tried to find to send a PR in this repo, but could not discover :/)
Should read:
Join GitHub Campus Experts
Apply to join the training and become a Campus Expert.

Learn community leadership skills
Get hands-on mentorship and advice
Get access to exclusive opportunities

Merci!

Pada tanggal Kam, 20 Des 2018 22.10 Vanessa<EMAIL_ADDRESS>menulis:

[image: screenshot 2018-12-20 10 04 23]
https://user-images.githubusercontent.com/1874003/50292395-fec02700-043e-11e9-8d84-1ac22cde9696.png
Copy is the same as the open source guides (which I tried to find to send
a PR in this repo, but could not discover :/)
Should read:
Join GitHub Campus Experts
Apply to join the training and become a Campus Expert.

Learn community leadership skills
Get hands-on mentorship and advice
Get access to exclusive opportunities

Merci!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/explore/issues/502, or mute the thread
https://github.com/notifications/unsubscribe-auth/Aq_8fHSewJInJ8ciMcFIytuf5W4h7QNxks5u66h1gaJpZM4ZcXkc
.

Oh my, I'm not sure I qualify to help on any of these products/projects.  However, I am willing learn from the ground up, possibly in this case, the basement up.  With that said, please feel free to assign me any type of grunt work and I will be greatful and appreciative.  Thank you all for this opportunity.   Please please please
On Sat, Dec 29, 2018, 2:03 PM skyemorgan0907<EMAIL_ADDRESS>wrote:

change from us to me
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/explore/issues/502#issuecomment-450516534, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AktbLOKRrdOCLYztH4lqn4IC-2VTFpBeks5u98qTgaJpZM4ZcXkc
.

Aún no e podido transaccionar y tengo saldo en cuenta


Get ready for python and js being optional when running test/Base_Tests

Pull Request Description
Let's modify the Base_Tests to be able to succeed without JavaScript being installed - done in 3298b07dca34164bd031df20b26d49c808c37713
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] All code follows the
Scala,
Java,
[x] Unit tests continue to with JavaScript tests in JVM mode
[x] Base_Tests pass in native image mode

I am having "unsolvable" (for a mere human) problems with licenses check. Rather than spending hours on understand where the problem is, let's narrow the scope of this PR down. Let's only introduce the necessary changes to test/Base_Tests to be ready for missing js language.

Adding "ready to merge" label as 99% of changes has already been approved and the catch/throw change in Engine is trivial.


asterisk: 20.9.3 -> 20.11.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for asterisk is: Software implementation of a telephone private branch exchange (PBX)
meta.homepage for asterisk is: https://www.asterisk.org/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 20.11.0 with grep in /nix/store/1m71nwmg1ychi12sg3hkmsb85g2fyvfi-asterisk-20.11.0
found 20.11.0 in filename of file in /nix/store/1m71nwmg1ychi12sg3hkmsb85g2fyvfi-asterisk-20.11.0

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

8 package rebuild(s)

First fifty rebuilds by attrpath

asterisk
asterisk-ldap
asterisk-lts
asterisk-module-sccp
asterisk-stable
asterisk_18
asterisk_20

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1m71nwmg1ychi12sg3hkmsb85g2fyvfi-asterisk-20.11.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A asterisk https://github.com/r-ryantm/nixpkgs/archive/ca0c858a92f5edbafb9b1085f27b99febb95910c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ca0c858a92f5edbafb9b1085f27b99febb95910c#asterisk

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1m71nwmg1ychi12sg3hkmsb85g2fyvfi-asterisk-20.11.0
ls -la /nix/store/1m71nwmg1ychi12sg3hkmsb85g2fyvfi-asterisk-20.11.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 4 packages built:

asterisk (asterisk-stable ,asterisk_20)
asterisk-ldap
asterisk_18 (asterisk-lts)
asterisk-module-sccp

Maintainer pings
cc @auntieNeo @DerTim1 @yorickvP for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Review per https://github.com/NixOS/nixpkgs/tree/a73246e2eef4c6ed172979932bc80e1404ba2d56/pkgs#package-updates
Reviewed points
Everything tested after cherry-picking the commit onto recent nixos-unstable:

[x] package name fits guidelines
[x] package version fits guidelines
[x] package builds on x86-64
[x] executables tested on x86-64
[x] all depending packages build

not touched by this pull request:

[ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
[ ] patches that are remotely available are fetched rather than vendored

more tests:

[x] used asterisk with iaxmodem client to send/receive some faxes
[x] used dialplan functions Busy, Wait, Answer, Playback, Goto, Dial

Comments
Only tested version 18 (this pull request apparently updates all versions supported by nixpkgs).
Looks good, I approve, can be merged!

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/2149

This should probably be backported as well. It also appears to add version 22, which we should test.


Add full paths to post build output of coverage reports

I tested with libocpp main branch, but I couldn't produce the changed comment at all, is there some logging flag to set?

I tested with libocpp main branch, but I couldn't produce the changed comment at all, is there any logging flag to set?

did you try it with
cmake --build build --target ocpp_gcovr_coverage

or which coverage command did you run?

Building with ninja seems to not show the comment, but with make it works :+1:


Update appium-adb module

now adb.getApiLevel call always returns an integer

Published in<EMAIL_ADDRESS>


Corrected Logging Category Descriptions

Corrected logging descriptions as mentioned in https://github.com/MicrosoftDocs/azure-docs/issues/35576.
@anavinahar

@allegradomel : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Verified correction. Thank you.


Monitor/workspace Size doesnt respect reserved layout

Trying to use addreserved command to hyprland monitor config has Nstack layout not respecting the change. happens in eww dock when it tries to use wlr-roots compositor to reserve space
monitor=DP-1,5120x1440@120,0x0,1
monitor=DP-1,addreserved,0,0,48,0
Second line is not respected when it is in other layouts.

Are you using latest source from git? I can't reproduce. Any config section for hyprNStack?

Maybe try latest git. I found one instance of the reserved space not being used, but it would only have applied to certain configurations of reserved+orientation. Maybe you were running into that.

Tried building with the latest git and still have the same issue persisting.
Have noticed that the reserved space does actually get respected from every direction but where i have a EWW bar coming from
my nstack config:
nstack {
layout {
orientation=center
new_on_top=0
new_is_master=0
no_gaps_when_only=0
special_scale_factor=0.8
inherit_fullscreen=0
stacks=4
center_single_master=1
mfact=0.43
}
}
-- Turns out im a dumb ass and thought i already checked my eww config and it not trying to reserve space itself and never conflicted with other layouts i was using until trying the nstack plugin

unable to change orientation to get the windows to respect the screen boundary

not entirely sure whats fixed it but after going through some config changes and swapping to hyprland's official plugin manager seemed to resolve the issue


Build speedup

This PR supercedes #150 with the same commits but GPG signed
This pull request changes the static analysis to use golangci-lint which is 5x faster than using the tools separately and adds a lot more checks and fewer false positives.
I have fixed all the existing problems as separate commit: I had to fix a lot of missing error handling so please pay close attention to that commit
This partially fixes #149 but more investigation is needed to investigate why module downloading has slowed considerably

Found the following bug:
panic: sync /dev/stderr: invalid argument
goroutine 1 [running]:
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand.func1(0xc00000e0c8)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:44 +0x58
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand(0xc0001a7180)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:50 +0x1be
github.com/controlplaneio/simulator-standalone/cmd.newCmdRoot(0x0)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:29 +0x196
github.com/controlplaneio/simulator-standalone/cmd.Execute(0xb, 0xbac7ec)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:124 +0x22
main.main()
/go/src/github.com/controlplaneio/simulator-standalone/main.go:13 +0x26
panic: sync /dev/stderr: invalid argument
goroutine 1 [running]:
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand.func1(0xc00000e0c8)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:44 +0x58
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand(0xc0001a5180)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:50 +0x1be
github.com/controlplaneio/simulator-standalone/cmd.newCmdRoot(0x0)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:29 +0x196
github.com/controlplaneio/simulator-standalone/cmd.Execute(0xb, 0xbac7ec)
/go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:124 +0x22
main.main()
/go/src/github.com/controlplaneio/simulator-standalone/main.go:13 +0x26

Found the following bug just after the "Simulator" red header:
panic: sync /dev/stderr: invalid argument

goroutine 1 [running]:
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand.func1(0xc00000e0c8)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:44 +0x58
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand(0xc0001a7180)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:50 +0x1be
github.com/controlplaneio/simulator-standalone/cmd.newCmdRoot(0x0)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:29 +0x196
github.com/controlplaneio/simulator-standalone/cmd.Execute(0xb, 0xbac7ec)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:124 +0x22
main.main()
    /go/src/github.com/controlplaneio/simulator-standalone/main.go:13 +0x26
panic: sync /dev/stderr: invalid argument

goroutine 1 [running]:
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand.func1(0xc00000e0c8)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:44 +0x58
github.com/controlplaneio/simulator-standalone/cmd.newConfigCommand(0xc0001a5180)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/config.go:50 +0x1be
github.com/controlplaneio/simulator-standalone/cmd.newCmdRoot(0x0)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:29 +0x196
github.com/controlplaneio/simulator-standalone/cmd.Execute(0xb, 0xbac7ec)
    /go/src/github.com/controlplaneio/simulator-standalone/cmd/root.go:124 +0x22
main.main()
    /go/src/github.com/controlplaneio/simulator-standalone/main.go:13 +0x26

https://github.com/uber-go/zap/issues/370 this is a bug in zap and they have no plans to fix it.  We are migrating to logrus imminently so I will just remove the panic for now

https://github.com/kubernetes-simulator/simulator/pull/151/commits/8923de6a664f0f23e844639ca3d126971f9e5628 "fixes" your reported issue @abdullahgarcia
https://github.com/kubernetes-simulator/simulator/pull/151/commits/c351e8bf52667310a4b6e6f1e6b0ffcce857ee4f massively speeds up the build (ran go mod tidy to cleanup dependencies)
I had to force push because I accidentally pushed a broken commit, please delete your local branch and refetch it from origin before testing

Simulator no longer displays the help text once it's done building for me.

@s-irvine that is now fixed... I force pushed after interactively rebasing to drop a broken commit and edit the commit which fixes missing error handling.
@jondkent build times are now sane again
Please delete your local branch and refetch from origin before retesting

This is much better now, and much faster.  LGTM

I've done a simulator infra create, simulator infra destroy and simulator scenario launch and everything looks to be working well atm.


fix: add payable for forceDeploy

What ❔

updated the IContractDeployer interface: made the create2 and forceDeployOnAddresses payable
made the forceDeploy function payable

Why ❔
In the era-system-contracts the ContractDeployer's create2 and forceDeployOnAddresses functions are payable (https://github.com/matter-labs/era-system-contracts/blob/dev/contracts/ContractDeployer.sol), therefore updated the interface and made the forceDeploy function payable.
Checklist

[x] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[x] ~Tests for the changes have been added / updated.~
[x] ~Documentation comments have been added / updated.~
[x] ~Code has been formatted via zk fmt and zk lint.~

While the function did become payable it makes no use of the msg.value. We should pass the msg.value to the forceDeployOnAddresses call

Fixed!


CLI bug on Submit for Arrays

Submitting Array based ARgorithms are leading to TESTING FAILED errors, or APPLICATION ERROR (on server side)
import ARgorithmToolkit

def run(**kwargs):
    algo = ARgorithmToolkit.StateSet()
    arr1 = ARgorithmToolkit.Array(name='arr1', data=[1,2,3], algo=algo)
    arr2 = ARgorithmToolkit.Array(name='arr2', data=[2,5], algo=algo)
    arr1.compare(0,1)
    arr2.swap(0,1)
    return algo

Also resubmitting results in TEST PASSED and file on server changes with the failed tests.
This leads to random behaviour.

@TheForeverLost submitted the same file and got it to work.
POSSIBLE EXPLANATION : Account privileges.
Also, Array assignment doesn't work because of np.integer type being Unserializable. Changes in Toolkit.Array required.

I relogged in as a new account and it worked

[ ] fixing numpy types serialisability by expanding encoder or altering ARgorithmToolkit.Array
https://stackoverflow.com/questions/50916422/python-typeerror-object-of-type-int64-is-not-json-serializable

[ ] Test File reader and configure functionalities dealing with file testing

@yatharthmathur
try installing the testpypi version of toolkit and test if it works better for you
$ pip install -i https://test.pypi.org/simple/ ARgorithmToolkit==0.2.0


[BUG] [VSCode Extension] Not able to import modules outside of the flow directory

Describe the bug
I have 2 flows in my project, both of them need to import project shared code (the project module is lib) outside the flow working directory.
When I do that, the VS code extension always failed to load the Python nodes, with this error message  (ModuleNotFoundError) No module named 'lib'
Trying to set PYTHONPATH to the project workspace folder after clicking "Regenerate with advanced options" in the Python node does not seem to have effects.
This issue is similar to https://github.com/microsoft/promptflow/issues/3209
How To Reproduce the bug

set up the project like this:

lib/
flow1/
flow2/

create a Python node in one of the flows, which does from lib import ...

execute the flow, the ModuleNotFoundError will appear.

Environment Information

Promptflow Package Version using pf -v:
{
"promptflow": "1.12.0",
"promptflow-core": "1.12.0",
"promptflow-devkit": "1.12.0",
"promptflow-tracing": "1.12.0"
}
Operating System: MacOS
Python Version: 3.11
Prompt Flow extension version: 1.20.0

I'm not sure if it's just relating to the extension. I've attempted to add in a few dependencies in the requirements.txt file and manually uploaded the flow to Azure ML, but the compute session does not respect the requirements file, and when I go to deploy, it fails with No module named XXX

@simon-v-swyftx , this is not related to extension. For Azure portal issue, feel free to create a feedback  for it, when filing feedback, please also attach related logs. For your case we'll need the following log

@MingStar let's track the issue in a central place, I've provided a workaround in #3209 , please check if it can help with your case.

@D-W- apologies for the late reply.
The issue is really with the VS Code extension, I think it assumes the flow file is called flow.dag.yaml, and separate flow files have to be in different sub folders. When I refactor the code according to your workarounds, the PromptFlow VS Code extension does not pick up nor display any flows.

Hi @MingStar , you mentioned you added your working directory to PYTHONPATH.
Could you run python -c "import sys; print('\n'.join(sys.path))" in command line to check if the path was added?
If not, you probably need to restart the session to make it take effect.

@D-W- I did try to add the project directory to custom PYTHONPATH after clicking the Regenerate with advanced options button in the PF VSC extension, however, it seems PYTHONPATH was not being set properly.
Adding PYTHONPATH=<project_dict> manually in front of the generated pfutil.py tool -f... command in the command line returned no errors.
that got me thinking it could be a bug in the VSC extension preventing it from setting the custom PYTHONPATH correctly.

and maybe the source code for PF VSC extension should be open sourced (as mentioned in https://github.com/microsoft/promptflow/discussions/360, it is not), so that we can all take a look at how the full pfutil.py tool command is constructed from the VSC extension

Hi, any updates on this?
FYI, this prevents me from promoting PF further to my organisation, as developing with just one flow in a project with VSC is not realistic with many of our use cases.


Relative path leads to ModuleNotFound

Hi there, thanks for making such a rapid framework, I thought it could be used as a drop-in replacement for FastAPI but when I tried to run via root@:/app/app# granian main --workers 8 --port 8001 it just crashed. I had no issues with Uvicorn and socketify in the past.
Any guidance will be appreciated. Thanks a bunch!
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.12/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.12/site-packages/granian/server.py", line 308, in _spawn_rsgi_worker
    target = callback_loader()
             ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/granian/_internal.py", line 58, in load_target
    module = load_module(path)
             ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/granian/_internal.py", line 43, in load_module
    raise RuntimeError(
RuntimeError: While importing 'app.app.main', an ImportError was raised:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/granian/_internal.py", line 40, in load_module
    __import__(module_name)
  File "/app/app/main.py", line 7, in <module>
    from app.api.api_v1.api import api_router
ModuleNotFoundError: No module named 'app.api'

Can you try to go up one level and target app.main? Also, you're missing the --interface parameter that has to be set to asgi.

Can you try to go up one level and target app.main? Also, you're missing the --interface parameter that has to be set to asgi.

Just tried and it's not working still on my Docker environment. Here's the main.py I'm working with. How can I resolve the namespace issue if that works locally but not on Docker?
from fastapi import FastAPI, Request

from app.api.api_v1.api import api_router
from app.core.config import settings

app = FastAPI(
    title=settings.PROJECT_NAME, openapi_url=f"{settings.API_V1_STR}/openapi.json",
)

# Set up CORS
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # Allow only the frontend origin
    allow_credentials=True,
    allow_methods=["*"],  # Allows all methods
    allow_headers=["*"],  # Allows all headers
)

app.include_router(api_router, prefix=settings.API_V1_STR)

@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
    return JSONResponse(
        status_code=500,
        content={"message": "An unexpected error occurred. Please try again later."},
    )
import logging

# Configure logging
logging.basicConfig(level=logging.INFO)
logging.info("Using uvloop as the event loop implementation")

The previous traceback you gave suggests that this import
from app.api.api_v1.api import api_router

can not be resolved.
It seems the app package is known in your environment but does it have an api module (from where you're looking)?
Can you provide your folder structure perhaps? What @gi0baro suggested seems very plausible, since you seem to have your main.py as app/app/main.py. You might actually be intending to have it as app/main.py if you want to import from app/api/api_v1/api.py.
You could isolate this with something like
# some_python_file.py
from app.api.api_v1.api import api_router
print("Hello world.")

but frankly, the error you linked doesn't have anything to do with Granian.
You might also want to look at your Dockerfile, especially if you can confirm that things work locally but not in docker?
Maybe you're mounting things in an unintended way?


aligned items center in mobile view

🛠 Fixes Issue
i have aligned items center in mobile view.....
now it's looking good
📷 Screenshots

Ok ...

will the feedback image  show in mobile view??

Plz tell me...

Yes @codingkush

Ok..

fixed the issue and made responsive get in touch section
screenshot :-------------

Is this okay???


Topic not being created with FirebaseMessaging.getInstance().subscribeToTopic(...)

Hello,
I am able to successfully send notifications to a single device and I am able to send them to a user segment, but in the Firebase Notifications console for my application for Target=Topic it shows "This project does not have any topics" even though I called FirebaseMessaging.getInstance().subscribeToTopic() from my Android application with several different topic names days ago.
The documentation for this is very sparse. Does this call not actually create a new topic? Is an HTTP call required to create the topic before the Android client can subscribe to it through this API?
If this API should indeed create the topic then how long does it take? I have been waiting almost 3 days now for it to appear in the console. I do not see any exceptions or errors generated on the client side when I make the call.
This was from a Samsung Galaxy S6 with Marshmallow.
Thanks,
Thomas

@ThomasSunderland it should create the topic and appear in the console within a few hours, so this is strange.  Can you confirm that you can send messages to the topic and receive them?  You can test this with the HTTP API by sending a request like this:
curl --header "Authorization: key=$API_KEY" \
       --header Content-Type:"application/json" \
       https://fcm.googleapis.com/fcm/send \
       -d "{ \"to\": \"/topics/foo\", \"notification\": { \"title\": \"Test\", \"text\": \"Hello World\" } }"

You can get your $API_KEY value from the google-services.json file.

@samtstern, I haven't run the test noted above yet, but I can say that I am able to run the sample app and create the "news" topic without any issues.
One thing that is different in the other app where the topics are not being created is that the actual topic creation is happening inside of an android library within my solution as opposed to within the main application. Do I need a separate google-services.json file for the library or should I maybe raise a create topic event from the library that the main application which already has the google-services.json file could handle?

I don't think you would need a separate google-services file for the library. As long as all of the necessary receivers are merged into the final AndroidManifest it should work as expected.

@kroikie Everything does appear to work as expected other than subscribing to new topics. The topics never appear in the Firebase console if the call is made from a library. I am, however, able to receive within the library notifications sent to a segment and to a single device without any issues.

@ThomasSunderland thanks for the details, I will take this report to the FCM team and see if there's any diagnostic issue you can provide that would help to debug.

@ThomasSunderland did your topics ever appear?  The FCM backend engineers found a few small bugs in the pipeline and fixed them, maybe that was affecting you.

@samtstern No, they never appeared

Hey all. Have same issue.

@ThomasSunderland Have you tried sending to the topic using the HTTP API? I'm trying to figure out where the issue is that the topic does not get created at all (in which case sending to HTTP should also fail) or if it is an issue of the Firebase console not displaying an existing topic.

@kroikie I get the following when I execute it through cURL:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   230    0   147  100    83     26     15  0:00:05  0:00:05 --:--:--   269

<TITLE>Unauthorized</TITLE>

Unauthorized

Error 401

A couple of quick updates:

Executing through cURL worked fine if I use the server key rather than the API key

With that said this may no longer be an issue for me as I can see today the topics that I created yesterday from my Android display. Perhaps those changes that were mentioned earlier in the thread fixed my issue.

Thank you everyone for your help.
-Thomas Sunderland

@ThomasSunderland I'm very happy you got it working, I think you may have used the API key from the google-services.json file which is an Android API key, and a server API key is needed for sending FCM messages. If so you are not the only person that has made that error and we are updating our docs to make it clearer which API key you should use.

@kroikie  I am having issues, if I manually create a topic via the CURL I can send push notification messages to a topic even when they don't show up on the consoled.
The iOS Library doesn't seem to create this topic or let me push to it, nor do I get APNS.

I am having a similar issue. I was able to successfully generate the message ID. I used FirebaseMessaging.getInstance().subscribeToTopic(InfoTopicName); to create the Topic in my java class. However, when trying to send  notification to the "topic", firebase claims no topics exists.  I used an HTTP curl request to generate the ID. How much time AFTER the ID is generated does it take firebase to create the topic?

@samtstern I have a different issue, In my case device token is generated.And I have subscribed to a topic,everything works while I test it on debug version. When comes to release version device token is registered and I can send notification by device token,it works.But when I sent notification via topic it doesn't work. I can also send from firebase console to a platform. Topic is not even appeared in there, I don't know does anyone has this issue
Thanks

I have the same issue as @saleeh93 . How long does it take for a topic to appear on the console? When I did this earlier, it would happen instantaneously.

@vedantswain It will take about 24 hrs to show up on firebase console, mean time you can try the curl to test

having the same issue when calling this via Android onClick
FirebaseMessaging.getInstance().subscribeToTopic(Config.TOPIC_NEWS);

This is what the documentation says:
Pub/sub mechanism for sending notifications to subscribers. Learn more: Android, iOS. There is up to one day delay between new topic creation and when it becomes available as a target


Added tests to cover 2 reported issues

Added tests to cover 2 reported issues

PR #46
wrote tests to cover this fix

Looks good!


Connected axes for non-linear interpolation

A recent trending topic on Twitter is the idea of using connected axes to implement a type of non-linear interpolation.
Does the designspace format support this?

Since .designspace uses axis names as location identifiers, it may work with non-unique tags. That said, fonttools uses fvar axis tags as axis identifiers all over the place, so there's a bigger challenge there.

Closing in favor of:
https://github.com/fonttools/fonttools/issues/1581
https://github.com/fonttools/fonttools/pull/2113


Changes needed to this doc were sent to Matt through internal mail

Matt, please look at the changes I outlined in an internal mail to you. Thanks!

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

ID: dc538db2-5b34-3668-1e8e-1914b4b18c43
Version Independent ID: 4f4c7701-f73c-ca0b-f7e4-62652a7ae66b
Content: Deploy a Kubernetes cluster to a custom virtual network on Azure Stack Hub - Azure Stack Hub
Content Source: azure-stack/user/kubernetes-aks-engine-custom-vnet.md
Service: azure-stack
GitHub Login: @mattbriggs
Microsoft Alias: mabrigg

@walterov Thanks for the feedback. I have assigned the issue to the content author to evaluate and update as appropriate.

https://github.com/MicrosoftDocs/azure-stack-docs-pr/pull/4542

#in-progress

Resolved. #please-close