doc: Bluetooth: Mesh: Fix line width to 100 in mesh docs

From Codying Style guideline (https://docs.zephyrproject.org/latest/contribute/guidelines.html#coding-style):
The line length is 100 columns or fewer. In the documentation, longer lines for URL references are an allowed exception.

Does this apply to bullet point listing as well? I found around 100 occurences of line being over 100 chars in shell.rst, most of them related to bullet points.

I tried different approaches, but they didn't render correctly. Usually the first line was bold, but the rest text was non-bold and shifted.

@PavelVPV please rebase


how to set default/auto value of a field based on _id

I have a name field that when not specified I would like to have a default value something like base+_id.  If user specifies any value, it should take precedence over the default value
How to achieve this? Tried be below, but it gives _id as 'undefined'
gSchemas.esChartInstances = new SimpleSchema({
    chartName: {
        type: String,
        autoValue: function () { if (this.isInsert) return "chart-" + this.field('_id').value; }
    },
});

It is not giving the "_id" value, rather it is giving "chart-undefined" for all.

Copying in my answer from the other repo:

Collection2 package removes the _id before running autoValues. It's related to some other things that I plan to change eventually, so it can probably be fixed. But it's a collection2 issue, so can you post this over in that repo instead?

With the 2.5.0 release, I think it should now work to do if (this.isInsert) return "chart-" + this.docId; as long as you are calling insert from the client or including a specific _id in the document to be inserted. When https://github.com/aldeed/meteor-collection2/issues/124 is done, this.docId should then always be set.


chore(env) update router default

What this PR does / why we need it:
Changes the router default to expressions.
Notes this as a breaking change in unreleased release notes.
Which issue this PR fixes
Part of https://github.com/Kong/kubernetes-ingress-controller/issues/4719
Special notes for your reviewer:
Ditto open questions in https://github.com/Kong/kubernetes-ingress-controller/pull/4934
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] PR is based off the current tip of the main branch.
[x] Changes are documented under the "Unreleased" header in CHANGELOG.md
[ ] New or modified sections of values.yaml are documented in the README.md
[x] Commits follow the Kong commit message guidelines

Given https://github.com/Kong/kubernetes-ingress-controller/issues/5018#issuecomment-1878003107 we're presumably doing a bit more around this other than just flipping it. Nothing of particular interest here anyway, so just closing this to clean up stale PRs.


Add libgtk3 to base images

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

ok, so here is the difficulty - we don't want to rebuild the Docker images - because it will change the images people are already using! See the mess it caused the last time #78
Hmm, let me try some things locally first. I am thinking if I can take each existing image and just add this libgtk3 library as another layer - and push the Docker image back. This would keep everything the same, but add extra library.

hmm, I am seeing that all different Node versions pass in https://github.com/cypress-io/cypress-test-node-versions already, maybe gtk3 is not necessary

Hey there, can we merge this into the master and rebuild the images? We're having trouble exactly because of this dependency.

@cbarratt is this really necessary? I tested a lot of base images - all work with Cypress v3.3.1 except cypress/base:11.13.0 - because they either have libgtk3 already or do not use --no-install-recommends flag when doing apt-get. Thus the lib is already there.

@bahmutov ahhh, maybe it’s  not needed across the board, this was mostly a presumed change, I was the unlucky one who was trying to use the 11.13.0 base :(

:) sorry about that - like playing the minesweeper with 1 mine and hitting it
Sent from my iPhone

On Jun 3, 2019, at 16:27, Callum Barratt<EMAIL_ADDRESS>wrote:
@bahmutov ahhh, maybe it’s not needed across the board, this was mostly a presumed change, I was the unlucky one who was trying to use the 11.13.0 base :(
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I have rebuilt cypress/base:11.13.0 with additional libraries and pushed it, so the only image that could not run Cypress 3.3.0+ should be fixed now