vmss: Adding an IpConfiguration using a jsonString returns a msrest serialization error

Description
Hello,
I'm trying to add an IpConfiguration to a VMSS using the cli (using the docker image).
using the following command:
az vmss update --name 'vmssName' --resource-group 'resourceGroupName' --add virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations "$jsonData"
$jsonData is set with the following json:
(i also tried to use double quotes instead of single quotes, but same result)
{
    'name':  'nic-internal',
    'subnet':  {
                   'id':  '/subscriptions/subscriptionId/resourceGroups/opisense-backend/providers/Microsoft.Network/virtualNetworks/backend-vnet/subnets/loadbalancer-subnet',
				   'resourceGroup': 'resourceGroupName'
               },
    'applicationGatewayBackendAddressPools':  null,
    'loadBalancerBackendAddressPools':  [
                                            {
                                                'id':  '/subscriptions/subscriptionId/resourceGroups/opisense-backend/providers/Microsoft.Network/loadBalancers/LB-cluster-internal/backendAddressPools/LB-backend',
												'resourceGroup': 'resourceGroupName'
                                            }
                                        ],
    'loadBalancerInboundNatPools':  [
                                        {
                                            'id':  '/subscriptions/subscriptionId/resourceGroups/opisense-backend/providers/Microsoft.Network/loadBalancers/LB-cluster-internal/inboundNatPools/LoadBalancerBEAddressNatPool',
											'resourceGroup': 'resourceGroupName'
                                        }
                                    ],
    'id':  null
}

Then i'm getting a json (de)serialization error

'loadBalancerInboundNatPools'
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/azure/cli/main.py", line 36, in main
    cmd_result = APPLICATION.execute(args)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/core/application.py", line 203, in execute
    result = expanded_arg.func(params)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/core/commands/__init__.py", line 278, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/core/commands/arm.py", line 349, in handler
    raise ex
  File "/usr/local/lib/python3.5/site-packages/azure/cli/core/commands/arm.py", line 332, in handler
    opres = setter(client, **setterargs) if client else setter(**setterargs)
  File "/usr/local/lib/python3.5/site-packages/azure/cli/command_modules/vm/custom.py", line 1496, in vmss_set
    resource_group_name, name, raw=no_wait, **kwargs)
  File "/usr/local/lib/python3.5/site-packages/azure/mgmt/compute/compute/v2016_04_30_preview/operations/virtual_machine_scale_sets_operations.py", line 85, in create_or_update
    body_content = self._serialize.body(parameters, 'VirtualMachineScaleSet')
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 301, in body
    data = _convert_to_datatype(data, data_type, self.dependencies)
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 182, in _convert_to_datatype
    getattr(data, attr), mapconfig['type'], localtypes))
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 182, in _convert_to_datatype
    getattr(data, attr), mapconfig['type'], localtypes))
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 182, in _convert_to_datatype
    getattr(data, attr), mapconfig['type'], localtypes))
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 156, in _convert_to_datatype
    param, data_type[1:-1], localtypes) for param in data
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 156, in <listcomp>
    param, data_type[1:-1], localtypes) for param in data
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 182, in _convert_to_datatype
    getattr(data, attr), mapconfig['type'], localtypes))
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 156, in _convert_to_datatype
    param, data_type[1:-1], localtypes) for param in data
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 156, in <listcomp>
    param, data_type[1:-1], localtypes) for param in data
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 171, in _convert_to_datatype
    localtypes) for key in data
  File "/usr/local/lib/python3.5/site-packages/msrest/serialization.py", line 171, in <dictcomp>
    localtypes) for key in data
KeyError: 'loadBalancerInboundNatPools'

Would you have any idea what's wrong? is the json format invalid or is it simply not supported by the cli?
Thank you,

Environment summary
Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
Answer here: Docker (latest, image id 9521494feb6e)
CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here: 2.0.6
OS Version: What OS and version are you using?
Answer here: Windows 10, but using Azure CLI inside docker
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here: bash (from docker container)

Hi @denisbollinne, I would recommend you try a couple things:

Remove any properties that are null. Omission itself should accomplish that.
Change your keys from "camelCasing" to "snake_casing".  All properties in the SDK use snake casing, which may be why you are getting the KeyError.

Thanks @tjprescott,
I applied your recommendations, and in addition, I had to remove the resource_group elements.
With all these changes, the json was parsed successfully.
But then my journey was not over, so for sake of completeness, here are the different steps i had to do in order to "Add a second IpConfiguration to an existing virtual scale set"
Closing the ticket.

I had to use the command az resource update instead of az vmss update in order to use the latest API version (required to be able to add a second IpConfiguration).
1.1. using az resource update required the json to be changed, because the resources are nested in
properties elements
I had to flag the existing IpConfiguration as 'Primary', this could be achieved with the following command az resource update --id '/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Microsoft.Compute/virtualMachineScaleSets/vmssName'  --resource-group 'resourceGroupName' --set properties.virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].properties.ipConfigurations[0].properties primary=true
Then i tried to use az resource update, but this time it complained with subscription is not registered for feature Microsoft.Network/AllowPublicIpsAndLoadBalancingOnSecondaryIpConfigsInVMScaleSet required to carry out the requested operation.
I could add the feature with this command  az feature register --name 'AllowPublicIpsAndLoadBalancingOnSecondaryIpConfigsInVMScaleSet' --namespace 'Microsoft.Network'

Thanks,


java packaged jar，is supported?

Only java packaged jar, unpack to scan the directory, is this project supported?

Hello @wjp-110, thank you for reaching out. Currently, the tool will look through jar files looking for native method calls and flag them in the report. It can also look at your maven dependencies and point out library versions that need to be updated. It does not currently look at native method calls on Java files, is that something you'd be interested in contributing? We'd gladly hop on a call with you to discuss how to go about it.
Does that help answer your question? If not, please provide more details and we'd be happy to help.

Closing issue. If you have any more questions, feel free to reach out again.


Multi-Threading: Mistake causes freeze

https://github.com/scytheStudio/SCodes/blob/3c9c37c8d55314a429cbb7d56f68834e1bb8cccf/src/SBarcodeScanner.cpp#L76-L86
Note that pauseProcessing() is called on the main thread while the Worker thread is processing an image and afterwards calls continueProcessing().
So I guess the library stops working because: continueProcessing() is called on Worker thread before the pauseProcessing() is called on main thread for the next camera frame.
Have fun 😥

Thanks for noticing this issue.
This code is long overdue for some simplification, you can expect this will be fixed soon. 🙂


add Semester (6 months) time unit

Added the semester time unit
it's a period of 6 month January to June And July to December

Half year is useful when analysing data over a period. I would say it would be nice to have.


Add meteor-webpack

Why not add meteor-webpack to this kickstarter, now that it has reached 1.0? As it's compatible with 1.3, we would only benefit from it :)

That something worth investigating, I will look into it this week


update asynchronous validation example in readme

Changes the asynchronous validation example. With the current example the validation will be run twice, so if you have for example database queries in an async validation rule the validation will take alot longer than needed. Using checkAsync there will only be a single validation

Comments stating that this project is not supported are not accurate.  Before making such a claim, how about speaking to the author first.  Further, what gave you the impression that it is not supported, perhaps the fact that your PR was nor merged immediately.

I cannot check now but pretty sure the last changes were like 10 months ago, anyway this pull request had some unwanted changes in here thats why i closed it and made a seperate one


Update node version of AppVeyor to LTS and latest

We got a rather busy CI pipeline this evening. Probably should will come back later next morning.

Coverage remained the same at 79.31% when pulling 6e8752a8a585b4d55851f3c11ca6fb14fe4d4d64 on update-appveyor-nodejs into fca97b88d2619a26b4e1a77c4e863b20fa17a15b on master.

The reason why the Appveyor/branch test failed is timeout. Since AppVeyor/pr goes through, it merges.


removed the scss on the card component

Removed the styling made with scsss to width, and did same with tailwind classes

transition yok


Recognize .bats as Bash language

I write bats (https://github.com/sstephenson/bats) tests using vscode and every time I open the file I set language to Shell Script (bash) manually.
May be add .bats to the list so that its language is detected automatically?

You can add the file association in the settings.
Check out the "files.associations" setting.

@aeschli
Would it be possible to set that option from an extension?
Basically saying "hey, if you install my extension, all .something files will be "coloured" using bash language"

Yes, you can do that in a extensions. Just declare a 'language' contributions using the same id like the existing 'bash' language configuration (shellscript) and with '.something' in extensions
(all declarations are merged, so you don't need to repeat the other file extensions).
See here for more information on the language configuration point.

@aeschli
Thanks!
Think is that I'd like to give a new name to the language.
Let me elaborate with a practical example:
Swagger is a YAML file after all, but I am performing other operations on that.
I'd like to take advantage of YAML colorisation and still offer new capabilities based on language id
Does that make sense?

If your files are just almost like language X but not 100%, then it's much better to have your own language id. You can copy some of the existing support (e.g. the text mate grammar) but contribute tailored support for it. Check the doc for more information on how to create and publish and extension...

@aeschli Thanks again.
Actually the language X would be 100% the same. Should I copy the definitions anyway?


Zoom issue in webview

Bug description:
When clicking on an input field within the webview, the page zooms in unexpectedly.
To Reproduce:
Link to repository: sorry its private repo
Steps to reproduce:

Open the app containing the webview.
Navigate to the page with the input field.
Click on the input field.

Expected behavior:
The page should not zoom in when focusing on the input field within the webview.
Screenshots/Videos:

Environment:

OS: IOS
OS version: IOS 17.2
react-native version: 0.73.8
react-native-webview version: 13.8.7

I'm also having this issue. Only happens on iOS, not Android

@dmille add below code in head and style tag
// head

   <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0" />

// css file

 @media only screen and (max-device-width: 414px) and (orientation: portrait) and (-webkit-min-device-pixel-ratio: 2) {
            /* Adjust font size for inputs on iOS devices */
            .flex-input {
                font-size: 16px !important;
            }
        }
        @media screen and (-webkit-min-device-pixel-ratio:2) {
            select,
            textarea,
            input {
              font-size: 16px !important;
            }
          }

@SolankiYogesh Thank you!!


ValidationError: Circular dependency due to Tags

I'm submitting a ...

[x] :beetle: bug report
[ ] :rocket: feature request
[ ] :books: construct library gap
[ ] :phone: security issue or vulnerability => Please see policy
[ ] :question: support request => Please see note at the top of this template.

What is the current behavior?
Tags containing a resource names could create a Circular dependency.

What is the expected behavior (or behavior of feature suggested)?
Been able to disable the internal resolver.

What is the motivation / use case for changing the behavior or adding this feature?
Unfortunately It's too much easy to generate circular dependencies.

Please tell us about your environment:

CDK CLI Version: 0.35.0 (build c5e43e2)
Module Version: 0.35.0 (build c5e43e2)
OS: OSX Mojave
Language: TypeScript

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

My Stack:
const vpc = ec2.Vpc.fromVpcAttributes(this, 'vpc', {
  vpcId: 'myid',
  availabilityZones: ['us-west-2a'],
});

const ecsCluster = new ecs.Cluster(this, 'cluster', {
  clusterName: `service-cdk-${this.toosoEnv}`,
  vpc,
});
ecsCluster.node.applyAspect(new cdk.Tag('ResourceName', `ecs/${ecsCluster.clusterName}`));

CF output:
{
  "Resources": {
    "RecsCluster34087BB6": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {
        "ClusterName": "service-cdk-dev",
        "Tags": [
          {
            "Key": "ToosoResource",
            "Value": {
              "Fn::Join": [
                "",
                [
                  "ecs/",
                  {
                    "Ref": "RecsCluster34087BB6"
                  }
                ]
              ]
            }
          }
        ]
      },
      "Metadata": {
        "aws:cdk:path": "service-cdk-dev-us-west-2/Cluster/Resource"
      }
    }
  }
}

CF Error:
service-cdk-dev-us-west-2: deploying...
service-cdk-dev-us-west-2: creating CloudFormation changeset...

 ❌  service-cdk-dev-us-west-2 failed: ValidationError: Circular dependency between resources: [RecsCluster34087BB6]

I don't know if I'm wrong, but this seems to be the expected behavior in CF: you can't create a tag with as value the name of the resource itself - because that name doesn't exist until the end of the creation of the resource itself ... 🤔what do you mean exactly with been able to disable the internal resolver?

You should be able to do the following to avoid self referencing:
const vpc = ec2.Vpc.fromVpcAttributes(this, 'vpc', {
  vpcId: 'myid',
  availabilityZones: ['us-west-2a'],
});

const clusterName = `service-cdk-${this.toosoEnv}`;
const ecsCluster = new ecs.Cluster(this, 'cluster', {
  clusterName,
  vpc,
});
ecsCluster.node.applyAspect(new cdk.Tag('ResourceName', `ecs/${clusterName}`));

Thanks @made2591 & @jogold.
@jogold the solution you've suggested works.
Thanks again.


Update daml 2.10's upgrade documentation with latest changes

Update the doc to mention LF 1.17 instead of 1.16
Update the doc with the latest restrictions wrt to interfaces

I believe these docs also exist in 3.x, do they need the same changes?


Fix links

/previous-versions/windows/desktop/legacy/ms644981(v=vs.85) -> /windows/win32/winmsg/getmsgproc
/previous-versions/windows/desktop/legacy/ms644982(v=vs.85) -> /windows/win32/winmsg/journalplaybackproc
/previous-versions/windows/desktop/legacy/ms644983(v=vs.85) -> /windows/win32/winmsg/journalrecordproc
/previous-versions/windows/desktop/legacy/ms644984(v=vs.85) -> /windows/win32/winmsg/keyboardproc
/previous-versions/windows/desktop/legacy/ms644985(v=vs.85) -> /windows/win32/winmsg/lowlevelkeyboardproc
/previous-versions/windows/desktop/legacy/ms644986(v=vs.85) -> /windows/win32/winmsg/lowlevelmouseproc
/previous-versions/windows/desktop/legacy/ms644987(v=vs.85) -> /windows/win32/winmsg/messageproc
/previous-versions/windows/desktop/legacy/ms644988(v=vs.85) -> /windows/win32/winmsg/mouseproc
/previous-versions/windows/desktop/legacy/ms644991(v=vs.85) -> /windows/win32/winmsg/shellproc
/previous-versions/windows/desktop/legacy/ms644992(v=vs.85) -> /windows/win32/winmsg/sysmsgproc
/previous-versions/windows/desktop/legacy/ms633573(v=vs.85) -> /windows/win32/api/winuser/nc-winuser-wndproc

Still missing actual docs for:
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms644978(v=vs.85) DebugProc
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms644980(v=vs.85) ForegroundIdleProc
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms644977(v=vs.85) CBTProc
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms644975(v=vs.85) CallWndProc

#sign-off

Recommend taking the transformations described in the Description (which is great), and applying them in a writer's own PR. That'll be quicker than eyeballing for correctness every change in the 150 affected files. :)

[like]  Steve White reacted to your message:

From: Jim Walker @.>
Sent: Wednesday, June 21, 2023 10:19:13 PM
To: MicrosoftDocs/win32 @.>
Cc: Steve White @.>; Mention @.>
Subject: Re: [MicrosoftDocs/win32] Fix links (PR #1614)
Merged #1614https://github.com/MicrosoftDocs/win32/pull/1614 into docs.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/win32/pull/1614#event-9599985390, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHOQEB6NMGGHRH7233YDIC3XMNXODANCNFSM6AAAAAAY6BV6WA.
You are receiving this because you were mentioned.Message ID: @.***>


Short Hair Change

About the PR

made eyes look 2 px tall when similar color, old shape was better
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

Make sure to take this Changelog template out of the comment block in order for it to show up.
:cl: Potato1234_x

tweak: Changed shape of short hair to be like the old one.

Giving @Alekshhh a chance to chime in on this.

looks good to me


ZEPPELIN-2189. The order of dynamic forms should be the order that you create them

What is this PR for?
The order of dynamic forms should be the order that you create them. So I made the following 2 changes for this:

change the type of forms in GUI from TreeMap to LinkedHashMap
remove orderBy in paragraph-parameterizedQueryForm.html

Besides, I also did some code refactoring.
What type of PR is it?
[Bug Fix | Improvement | Refactoring]
Todos

[ ] - Task

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-2189

How should this be tested?
Tested manually.
Screenshots (if appropriate)
Before

After

Questions:

Does the licenses files need update?
Is there breaking changes for older versions?
Does this needs documentation?

Yeah I saw this as well. Let me take a look :)

Thanks @AhyoungRyu for review, just fix a code style issue

Tested and it works well now. Thanks for fixing it. LGTM

Change it to WIP for adding test.

LGTM

Merge into master and branch-0.7 if there are no more comments on this.


#82: Remove setup.py and update poetry to 1.4.0

Fixes #82

We decided to fix the AWS CI issues later and rely for the moment on local tests.


About conversion

Unfortunately I had not success with converting to onnx and with trtexec converter from nvidia.
Could you please, @jhl13  share tensorrt model? (realsr Large?)
or someone else if succssed with conversion. Thank you very much in advance

@zelenooki87 I am trying to convert swinir model to onnx and trt file too.  I will be very grateful if you share me your progress.


Could not read configuration

Hi, I've followed the docs to integrate the plugin, but when I run yarn dev (script in package.json that execute vite) it gives me the following error:
error when starting dev server:
Error: [vite:laravel:config] Could not read configuration: Cannot read properties of undefined (reading 'undefined')
    at readConfig (/var/www/html/node_modules/vite-plugin-laravel/dist/index.js:3410:11)
    at Object.config (/var/www/html/node_modules/vite-plugin-laravel/dist/index.js:3433:26)
    at resolveConfig (/var/www/html/node_modules/vite/dist/node/chunks/dep-c9c9d3e5.js:70842:33)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async createServer (/var/www/html/node_modules/vite/dist/node/chunks/dep-c9c9d3e5.js:56354:20)
    at async CAC.<anonymous> (/var/www/html/node_modules/vite/dist/node/cli.js:688:24)
error Command failed with exit code 1.

I think I have found the bug in this line https://github.com/innocenzi/laravel-vite/blob/ef2401481f1140ed8c56f7e5cc03bea08c74edc7/vite-plugin-laravel/src/config.ts#L105
The regexp here seems wrong, it expects a file named vite.[someword].config.ts and if I rename the file like vite.dev.config.ts it works. Can be the regexp changed to not force to call the config file like the example above?

I'm off this week so I can't check, but you can force a config name by using the config option of the laravel plugin
Hope this helps in the meantime

Hey, so I'm back and I just think you don't have the right package version, make sure you have v0.2.0-beta.5, not 0.1.27. Feel free to reopen if that was not the issue.


Modelling different elasto-plastic behaviour in tension and compression

Hi,
I'm trying to model a fibre reinforced concrete beam with different stiffness and stress-strain curve in tension and compression.
How should I implement this model?
Can I simply add the compression with negative values as below: (example numbers)
*plastic
-1200,-1
-100,-0.1
20,0.1
120,1
Thanks in advance for your help and assistance.
Alex

I don't think that this approach will work, because the stress-strain curve is defined in terms of equivalent stress and equivalent strain, which both can't be negative.

Theoretically, a non-symmetric stress-strain curve (yield curve) could be obtained by using kinematic hardening with non-zero initial back stress. This, however, would not affect stiffness.

How about a combination of compression-only and linear elastic material? Essentially, you copy each element and assign the second material to the copies.


Traffic Group - ha-score failoverMethod support

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I am trying to configure a TrafficGroup failoverMethod of ha-score via DO.  Currently only ha-order can be configured via DO.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I would like to be able to configure an ha-group and ha-score for traffic-groups via DO.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I can do this via tmsh, but in order to fully automate deployments, need the capability to configure ha-score failoverMethod for a TrafficGroup.
Additional context
Add any other context, such as the desired tmsh configuration, about the feature request here.
Here is an example of the tmsh commands I am trying to implement via DO:
tmsh create ltm pool ha-db members add { <db_neighbor_ip1>:0 <db_neighbor_ip2>:0 } monitor gateway_icmp tmsh create ltm pool ha-app members add { <intra_app_neighbor_ip1>:0 <intra_app_neighbor_ip2>:0 } monitor gateway_icmp tmsh create ltm pool ha-mib members add { <mib_neighbor_ip1>:0 <mib_neighbor_ip2>:0 } monitor gateway_icmp tmsh create ltm pool ha-outside members add { <outside_neighbor_ip1>:0 <outside_neighbor_ip2>:0 } monitor gateway_icmp
tmsh create sys ha-group ha-pool active-bonus <pool_weight> pools add { ha-db { weight 10 minimum-threshold 1} ha-app { weight 10 minimum-threshold 1} ha-outside { weight 10 minimum-threshold 1} <non_standard_ha_group_command> } tmsh modify cm traffic-group traffic-group-1 failover-method ha-score monitor { ha-group ha-pool}

Thank you for reaching out to us through email. I have created an internal item AUTOTOOL-4466 and added to our product backlog.

Added to sprint 43-1 scheduled for end of September

I am a customer of F5 who uses DO. Its already December. Is this completed ? @mdditt2000 @sunitharonan


bug: Plugin URL reported as changed, displays same old & new URL

Did you check docs and existing issues?

[X] I have read all the lazy.nvim docs
[X] I have searched the existing issues of lazy.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.9.0-dev-839+g3ac55fe083
Operating system/version
Linux
Describe the bug

Hope the image alone illustrates the issue. Happy to provide more information.
Steps To Reproduce
Not entirely sure how to reproduce.
Expected Behavior
Should not throw an error when there isn't a problem with plugin URL.
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Derp, just being an idiot, literally the wrong name.


[stable/jasperreports] Add ingress support

Signed-off-by: Javier J. Salmeron Garcia<EMAIL_ADDRESS>
What this PR does / why we need it:
This PR adds support for ingress rules (disabled by default)
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/ok-to-test
/lgtm


Automatic profile detection for Cmder based on %CMDER_ROOT% variable

Good morning, WT team!
Description of the feature request
I'm looking for a method where Windows Terminal would be able to detect a Cmder installation automatically and add it to the profiles section if it found one. The closest relevant issue I found is #1424, but I did not find a solution for it.
This feature request was original asked by one of our users in the Discussions sections for Cmder + Windows Terminal integration.
Proposed technical implementation details
This feature works in other terminals (such as Tabby's integration with Cmder) based on the existence of the %CMDER_ROOT% environment variable path and some hard coded paths to detect both the Clink-based shell and the customized Shell that Cmder provides. It would be great if Windows Terminal could also do that.
As an alternative and better solution to hard-coded paths, it would be awesome if somehow it was possible to signal a manifest-like file (such as manifest.json) that would include the title, color, name and path for different shells that a package such as Cmder supports. I'm not sure if a feature like this already exist in Windows Terminal.
The current status
Currently, the way that Cmder handles this is by manually adding the Cmder profile and Cmder powershell profile to the list of Windows Terminal profiles. We have to keep a track of these profiles and apply adjustments manually.
Alternatively, a flavor of Cmder is designed to ship with the portable version of Windows Terminal. These are all great approaches, but it would be even better if we could avoid shipping a bundled version of Windows Terminal with each Cmder release in case where one is already installed on the target user's machine, and simply integrate Cmder's shells as Windows Terminal profiles there.
With ❤ , as a Windows Terminal user, thanks for all the great work that you do with this awesome product!

As an alternative and better solution to hard-coded paths, it would be awesome if somehow it was possible to signal a manifest-like file (such as manifest.json) that would include the title, color, name and path for different shells that a package such as Cmder supports. I'm not sure if a feature like this already exist in Windows Terminal.

We do support "fragments" which is similar to what you describe. See here: https://learn.microsoft.com/en-us/windows/terminal/json-fragment-extensions
Is that what you had in mind? Does this lack some features that you'd need? (There are alternative approaches we could take, but fragments are available already and fairly flexible.)

@lhecker Thank you for the information about fragments, it seems this is the intended way for developers to introduce their profiles to WT.
Additionally, I understand this approach is more secure than reading an environment variable, since instead of reading an arbitrary path that could have been set by any program, the actual program in question actually needs to drop fragment.json in either a user-wide or system-wide directory that is controlled by WT.
The only downside is that due to Cmder's default portable nature, there is no post-install proccess going on that could automate placing the fragment file, but this approach is still way better than writing a script to locate the settings.json file, and modify it to add the new profile/color scheme. Ultimately, it's a fair approach to ask the user to execute the functionality of the program that would place the fragment in WT's directory.
I'll do some tests, and in the meantime will close this issue for now. Thank you once again for the guidance and mentioning fragments!


fix: update collect interface

Closes https://github.com/guacsec/guac/issues/32 & fixes a concurrency bug since there was no synchronization on the document collectors before trying to process the results

This looks good! I will review it soon.

@cpendery There's been some update with the logging library, can you rebase and resolve conflicts and this should be good to merge!


Add composer package manager to php dev container

The php dev container doesn't include the now industry standard package manager for php, composer

Resolved with PR #515


Fix #113 Navbar all categories redirect

#113 Made a change in the Navbar.js file in components folder to redirect from All categories->/tag:All instead of All categories->/books

@juitelavane send PR to dev branch

@mtwn105 please take a look

What happened?

@Mrhb787 I have created a new PR from Forked repo to DEV this time instead of Main. please take a look


Configure Ops Server install process to install Portal 10.3.1 HotFix

We are including the hotfix in the 2015 Q4 release, but not automating the installation. A section in the installation guide will be included to instruct the user to install this hotfix using the instructions find in the hotfix documentation.

Added to installation guide. Fix in Esri\ops-server-config v.next. Closing issue.


Add a "country" field and dropdown menu to Projects

Not sure if there is a canonical list of countries or country codes out there, but we'd like to ask projects for a specific country, in addition to the open-ended "Location" field that is there currently. Should be supplemented with "Global" as first option.

Gave this a go based on ISO countries. I based the helper text on the Location field; not sure if that was correct. Looks like this:
Edit view

Edit view with dropdown selected.

@lisamai that's exactly what we're looking for! The one additional change would be to make the country clickable and it'd take you to the list of projects filtered by country.

This is great but we need to think about it a bit more. We have a field called location that asks where volunteers should be from.
We should re-use the location for that, and perhaps build a migration script for the data, from free form to ISO select.
Perhaps also change the text to have it more encompassing: "Does this project target a certain area and wants volunteers only from there?" or something similar.
Another option is to slip it into two: volunteer location, target market. Perhaps that would be better. We still need that migration script, perhaps there are some easy to use NLP libraries out there.

I like the idea of the target market. 👍 I assume that people would want to help out in their local area.
I don't see the need for a migration script though. Imagine you're manufacturing something in Germany (you have the infrastructure there), but your target market is Sweden (where your product is required). We don't know whether the volunteer location is the same as the target market.
The same is true for digital products. You might build a digital product which helps out Austria, but people from all over the world may participate (location == remote).
My suggestion would be to keep the free text field for the location of the volunteers (either a location or remote). Additionally, provide the suggested select list (countries) for the target market.
You could then filter for the target market, which helps out bringing projects from other countries to the platform.

@jamiew @caseypugh looking for input here

Either way is fine with me; I think making this a target market could make sense to differentiate the purposes. Besides that decision, if the country is clickable to filtering, then would we want country to also be one of the filter options at the top? Listing all the countries may be overwhelming.

I'd propose:

we add this country dropdown as a new field projects.country which is tied to ISO, but change the  question to say something like what @sradu proposed: "Is this project only targeting people in a specific country?"
keep the open-ended location field but change question to: "Specific state, province or city within that country?"
migrate the existing data. Delete Global & friends, then manually clean up the rest. I'd be happy to do this part, there aren't many

Here are the Location values for all the current projects:
curl https://helpwithcovid.com/projects.json > projects.json
cat projects.json | jq '.[] .location' | egrep -i -v "(remote|global|nywhere|world)"

=>
https://gist.github.com/74c6c4f5dbc93bb20fe2d5ef94a9b3c6
This list has <50 projects, which is less than 10% of total projects`
I reviewed a handful manually and I believe many project creators are just putting in their own location, rather than their target market, as has been pointed out above.
I also liked the suggestion here of differentiating "where we'd like to source volunteers" and "only working with people in a specific area"
I think project creators would accept volunteers from anywhere – perhaps you're an ex-pat, perhaps you just love that country, whatever. Creators want volunteers.
With this feature we are more interested in enabling filtering down to projects that have an exclusively local impact. For instance, I would personally like to be alerted about projects that are happening where I'm from. I don't necessarily want to be alerted about all projects.

@jamiew because the current wording for location is: 'Do volunteers need to live in a certain location? Write remote otherwise.' we have to be careful about the migration.
The proposed idea here, which I support, would have the location field refer to target market instead of volunteers.
So one migration could be:

rename location to volunteer_location
add target_country & target_location

From a logical point of view keep the _location fields as free form.

Is there a benefit to collecting and storing volunteer_location or is that more just to keep the existing data as-is?

@jamiew the latter - we can drop it if we don't need city/state.

Cool that makes sense to me
Also just realized should maybe have been commenting on #105 instead... @lisamai would you be willing to implement the changes @sradu proposed in his previous comment?

Yep, I should be able to get to implementing the suggested field updates in a day or so @jamiew

Updated screenshots:

Love this. @lisamai can you please style that select with default tailwind. I believe the classes are in the project sort, you can just copy and paste those should be the defaults.

Good call, thanks @sradu! Updated the style and element structure so it's consistent with status.


Peerflix stopped working

For some weird reason, perplex has stopped working for me since just now ..
The error is
      throw er; // Unhandled 'error' event
            ^
Error: EACCES, open '/tmp/torrent-stream/4c09cbf638a45c001a3e91b3bf0b728cbe8d2203.torrent'
    at Error (native)

I updated the version of node on my system to the latest version and even re-installed peerflix ... no luck :(

could it be related to this:
http://stackoverflow.com/questions/9164915/node-js-eacces-error-when-listening-on-most-ports
try running node as root and see what happens.

I don't think it's a sudo problem because it's been working fine without sudo for over a month. However, it seems I have solved the issue after completely deleting the peerflix directory, updating my version of nodejs, and reinstalling peerflix.

@mohitathwani try removing /tmp/torrent-stream and try again? also do you have write access to /tmp/ in general?

Yeah I did delete that directory and yes I do have write permissions to /tmp/.
I think deleting everything and reinstalling again seems to have solved the issue.
—
Mohit  Athwani http://about.me/mohitathwani
On Sat, May 2, 2015 at 1:55 PM, Mathias Buus<EMAIL_ADDRESS>wrote:

@mohitathwani try removing /tmp/torrent-stream and try again? also do you have write access to /tmp/ in general?
Reply to this email directly or view it on GitHub:
https://github.com/mafintosh/peerflix/issues/199#issuecomment-98330339


R2Object.httpEtag contains W/, but R2Bucket.get throws TypeError when etag has W/

Which Cloudflare product does this pertain to?
R2
Existing documentation URL(s)
https://developers.cloudflare.com/r2/examples/demo-worker/
https://developers.cloudflare.com/r2/runtime-apis/#conditional-operations
Section that requires update
Either the demo needs to be updated, or the R2Object.get({…, onlyIf: Headers}) API needs to be fixed or clarified.
What needs to change?
R2Object.httpEtag returns a weak validator prefixed with W/, but R2Object.get does not support reading this header value.
How should it change?
R2Object.get should clarify whether it supports onlyIf Headers from the request.
Additional information
When I tried the R2 worker demo and refreshed the page in the browser, it alternated between a success page an an error page:

When I enabled the Real-time Logs, I observed that the call to MY_BUCKET.get({…, onlyIf: request.headers}) threw a TypeError: “ETag in HTTP header needs to be wrapped in quotes W/"52af2bc97aef22023c97c7874b569d0d").”

The source of the worker module (live, github) contains the following for handling GET requests to R2:
        const object = await env.MY_BUCKET.get(objectName, {
          range,
          onlyIf: request.headers,
        })
        …
        headers.set('etag', object.httpEtag)

If it matters, I used the S3 API to upload the object along with the etag.

R2Object.httpEtag definitely never returns a weak ETag. Any weakening is going to come from Nginx applying decompression automatically based on the request from the client.
That being said, it is accurate that R2Object.get needs to be accepting of weak etags. We have it in our backlog of tasks.

I think we can close the docs issue - this isn't a docs thing but a Workers runtime bug.


React 17 and NextJS 12 Fails to install

Unable to install as normal under React 17. When forcing it, it breaks the page:
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of 'm'.

import dynamic from 'next/dynamic'
import {
  CreatableSelectControl,
  CreatableSelectPreview
} from 'netlify-cms-widget-create-select'

const CMS = dynamic(
  () =>
    import('netlify-cms-app').then(cms => {
      cms.init()
      cms.registerWidget(
        'create-select',
        window.CreatableSelectControl,
        window.CreatableSelectPreview
      )
    }),
  {
    ssr: false
  }
)

const CMSPage: React.FC = () => {
  return (
    <>
      <CMS />
    </>
  )
}
export default CMSPage

Can you try to dynamically importing CreatableSelectControl and CreatableSelectPreview with the dynamic function?
I suspect next.js does not import the CreatableSelectControl elements on the front-end but only on the backend while you are trying to render CMS on the frontend.I suspect that is why window.CreatableSelectControl is undefined. Do you have a repo with this setup?

Just so it is clear for you I would do something along these lines:
const CMS = dynamic(
  async () => {
    const [
      CMS,
      {
        CreatableSelectControl,
        CreatableSelectPreview
      }
    ] = await Promise.all(
      [
        import('netlify-cms-app'),
        import('netlify-cms-widget-create-select')
      ]
    );
    CMS.init()
    CMS.registerWidget(
      'create-select',
      CreatableSelectControl,
      CreatableSelectPreview
    )
  }, {
    ssr: false
  }
)

Thank you, that fixed the loading issue. Now I'm seeing this:
TypeError: Cannot read properties of undefined (reading 'scrollHeight')

Call Stack
t.value
node_modules/netlify-cms-widget-create-select/dist/index.js (10:209198)


[Bug] toolbox.feature.yAxisIndex is not working when series.type is line

Version
5.5.1
Link to Minimal Reproduction
echarts example
Steps to Reproduce
Please check the link for chart options
Current Behavior
I was using dataZoomSelect. When I scale the chart, I only want the y-axis to scale and the x-axis to remain unchanged. But the current situation is that the x-axis and y-axis have changed, which means toolbox.feature.yAxisIndex does not take effect. For example, when I select the following content

it display like this

which is only scale the area I select instead of ignore the y-axis.
Expected Behavior
what I want is this effect

Environment
- OS:
- Browser:
- Framework:

Any additional comments?
No response

In your example you are defining xAxisIndex and yAxisIndex on the wrong level. Here is the corrected example.

In your example you are defining xAxisIndex and yAxisIndex on the wrong level. Here is the corrected example.

@MatthiasMert you are right. Thanks for your help


Fix navigation when one of showCategory or showSearch is false for Single Mode

I've added one more check to make sure we don't reset currentPage when getDerivedStateFromProps is triggered
p.s fixes #12

Hello, any updates?

@swashata  Can you accept this PR please ? :)


1577 license revamp

Summary
Syft currently represents licenses for packages are part of an individual packages metadata. It also limits the expression of licenses as single string values. This metadata approach combined with the limited expression opportunities afforded by a string representation make it hard for downstream intuition tooling to parse, read, and evaluate license compliance for individual packages.
This PR attempts to make the following changes to update the underlying license model to have more expressive capabilities, while also providing some guarantee's surrounding the license values themselves:

Licenses are updated from string -> pkg.License struct with the following fields:

Value required

declared value pulled from the original source of the discovered packages license

SPDXExpression optional

If it's possible to construct, this field will always contain a valid SPDX expression for downstream consumption

Type required

SPDX concluded vs declared

URL optional

URL source of declared/concluded license of online query was used (declared or concluded)

Location optional

syft's internal location representation showing the evidence of WHERE a license was discovered (declared or concluded)

Implementation Notes

Validate SPDX expressions and make licenses immutable on package creation
Remove Licenses data from individual metadata types and make it a first class field on Package
Use https://github.com/github/go-spdx for spdx expression/license validation for SPDXExpression field
Update catalogers to no longer  use metadata as a pass through and instead build more complex constructors for individual package catalogers
Update SPDX && CycloneDX presenters to no longer need to validate/mutate License data (this should be handled at the individual package level)

Schema Diff Notes
62,64d61
<         "license": {
<           "type": "string"
<         },
96d92
<         "license",
139,141d134
<           "type": "string"
<         },
<         "license": {
190d182
<         "license",
607,612d598
<         "licenses": {
<           "items": {
<             "type": "string"
<           },
<           "type": "array"
<         },
753a740,765
>     "License": {
>       "properties": {
>         "value": {
>           "type": "string"
>         },
>         "spdx-expression": {
>           "type": "string"
>         },
>         "type": {
>           "type": "string"
>         },
>         "url": {
>           "type": "string"
>         },
>         "location": {
>           "$ref": "#/$defs/Location"
>         }
>       },
>       "type": "object",
>       "required": [
>         "value",
>         "spdx-expression",
>         "type",
>         "url"
>       ]
>     },
984,989d995
<         "licenses": {
<           "items": {
<             "type": "string"
<           },
<           "type": "array"
<         },
1008d1013
<         "licenses",
1055c1060
<             "type": "string"
---
>             "$ref": "#/$defs/License"
1263a1269,1274
>         },
>         "license": {
>           "items": {
>             "type": "string"
>           },
>           "type": "array"
1272,1277d1282
<           "items": {
<             "type": "string"
<           },
<           "type": "array"
<         },
<         "license": {
1492,1494d1496
<         "license": {
<           "type": "string"
<         },
1527d1528
<         "license",
1625,1627d1625
<         "license": {
<           "type": "string"
<         },
1650d1647
<         "license",

@wagoodman - All unit tests are passing besides the revert we talked about for how fixtures are generated
Integration/CLI tests are failing since it seems we're detecting "new" licenses in older fixtures that are deprecated - I'm going to start taking a look at these and why we're not upgrading them to their semantic valid license that can be found in the latest license list
    utils_test.go:51: out: 	Package at line 52965 invalid: GFDL-1.2 is deprecated. in gcc-9-base
    utils_test.go:51: out: 	Package at line 52965 invalid: LGPL-2.1 is deprecated. in gcc-9-base
    utils_test.go:51: out: 	Package at line 54039 invalid: LGPL-2.1 is deprecated. in libtirpc3
    utils_test.go:51: out: 	Package at line 53901 invalid: LGPL-2.1 is deprecated. in libsmartcols1
    utils_test.go:51: out: 	Package at line 53206 invalid: LGPL-2.1 is deprecated. in libc-bin
    utils_test.go:51: out: 	Package at line 53227 invalid: LGPL-2.1 is deprecated. in libc6
    utils_test.go:51: out: 	Package at line 53655 invalid: LGPL-2.1 is deprecated. in libnsl2
    utils_test.go:51: out: 	Package at line 54204 invalid: LGPL-2.1 is deprecated. in mount
    utils_test.go:51: out: 	Package at line 53965 invalid: LGPL-2.1 is deprecated. in libsystemd0
    utils_test.go:51: out: 	Package at line 53116 invalid: LGPL-2.1 is deprecated. in libattr1
    utils_test.go:51: out: 	Package at line 53623 invalid: LGPL-2.1 is deprecated. in libmount1
    utils_test.go:51: out: 	Package at line 53079 invalid: LGPL-2.1 is deprecated. in libacl1
    utils_test.go:51: out: 	Package at line 53832 invalid: LGPL-2.1 is deprecated. in libselinux1
    utils_test.go:51: out: 	Package at line 53434 invalid: LGPL-2.1 is deprecated. in libgpg-error0
    utils_test.go:51: out: 	Package at line 54055 invalid: LGPL-2.1 is deprecated. in libudev1
    utils_test.go:51: out: 	Package at line 53816 invalid: LGPL-2.1 is deprecated. in libseccomp2
    utils_test.go:51: out: 	Package at line 54278 invalid: LGPL-2.1 is deprecated. in perl-base
    utils_test.go:51: out: 	Package at line 53153 invalid: LGPL-2.1 is deprecated. in libaudit1
    utils_test.go:51: out: 	Package at line 52990 invalid: LGPL-2.1 is deprecated. in gpgv
    utils_test.go:51: out: 	Package at line 53607 invalid: LGPL-2.1 is deprecated. in liblzma5
    utils_test.go:51: out: 	Package at line 54071 invalid: GFDL-1.2 is deprecated. in libunistring2
    utils_test.go:51: out: 	Package at line 53132 invalid: LGPL-2.1 is deprecated. in libaudit-common
    utils_test.go:51: out: 	Package at line 53949 invalid: GFDL-1.2 is deprecated. in libstdc++6
    utils_test.go:51: out: 	Package at line 52924 invalid: GFDL-1.3 is deprecated. in findutils
    utils_test.go:51: out: 	Package at line 53365 invalid: GFDL-1.2 is deprecated. in libgcc-s1
    utils_test.go:51: out: 	Package at line 54018 invalid: LGPL-2.1 is deprecated. in libtirpc-common
    utils_test.go:51: out: 	Package at line 54087 invalid: LGPL-2.1 is deprecated. in libuuid1
    utils_test.go:51: out: 	Package at line 53418 invalid: GFDL-1.3 is deprecated. in libgnutls30
    utils_test.go:51: out: 	Package at line 52940 invalid: GFDL-1.2 is deprecated. in gcc-10-base
    utils_test.go:51: out: 	Package at line 54368 invalid: LGPL-2.1 is deprecated. in util-linux
    utils_test.go:51: out: 	Package at line 53169 invalid: LGPL-2.1 is deprecated. in libblkid1
    utils_test.go:51: out: 	Package at line 53981 invalid: GFDL-1.3 is deprecated. in libtasn1-6
    utils_test.go:51: out: 	Package at line 53981 invalid: LGPL-2.1 is deprecated. in libtasn1-6
    utils_test.go:51: out: 	Package at line 53243 invalid: LGPL-2.1 is deprecated. in libcap-ng0
    utils_test.go:51: out: 	Package at line 52771 invalid: LGPL-2.1 is deprecated. in bsdutils


Some apps don't get START_ROUTER_SERVICE_ACTION broadcast from SdlRouterService

Bug Report
Some apps don't get START_ROUTER_SERVICE_ACTION broadcast from SdlRouterService, which caused the apps not getting registered.
Reproduction Steps
(prerequisite) 0. Run SDLCore, HMI on HU. Run a couple of SDL apps (e.g. hello_sdl_android, etc) on Android device. Make sure the apps get registered and appeared on HU.

Remove some app that does not act as the RouterService (e.g. helllo_sdl_android) from recent list. The app will be killed.
Relaunch the app (e.g. hello_sdl_android)

Expected Behavior
The app gets registered and appear on HU.
Observed Behavior
The app does not get registered.
OS & Version Information

Android Version: Android 9.0 on Pixel
SDL Android Version: commit 7d329a17dc95fe16df557827fead48cb4caa79a2 at develop branch
Testing Against: SDL Core 4.5 + HMI running on our development environment.

Test Case, Sample Code, and / or Example App
I will submit the possible PR with UnitTest later.

Closing as a stale issue.


The entity of  MRS100 are unavailable despite last firmware update

Version of the custom_component

Configuration

Add your logs here.

Describe the bug
A clear and concise description of what the bug is.
Debug log

Add your logs here.

Does someone have the same issue?

Yes


Filter By Regions

I am using the regions in cache. I could verify that is possible to remove all items from a specific region. But looking in documentation I couldn't find a way to filter by region. By example: If a have a set of items, and some itens are in region A, some other in region B, and so on ... I didn't find an efficient way to filter only items from region A.
Are you planning to have someting like this?

Our problem is the same：#227

Simple answer is, there is currently no supported way to do this.
Long answer for filtering and searching keys in Cache:
Caching with multiple layers and especially distributed caches can become pretty complex. That's why most caches don't provide any ways to find keys.
Have a look at System.Runtime.Caching or MS.Extensions.Caching.Memory. There is no way to retrieve all keys or search for keys with prefix or anything.
For example, the implementation of Regions in CacheManager for those two caches uses dependencies to delete all keys in a Region. But there is no way to find all keys of a region.
The Redis implementation uses a lookup key to store a link to all keys stored in a region.
Yes, this could be used and returned to the user of CacheManager. The problem here is, I cannot ensure that list is consistent at all. Keys in that list might already be expired or just other things happend.
In short, there is no way to provide a good consistency in this imlpementation (although CacheManager tries really hard to keep that consistent)
Then, if you use CacheManager for 2 layers of cache, e.g. in-memory+redis, finding everything in a Region would have to retrieve the list from Redis, as the in-memory layer might not even have all keys.
We already tried a few things, like searching for keys (see #161 for example).
So far, I don't have a really good and efficient API concept for this, otherwise I'd have implemented it already ;)
That being said, it is and always was on my list of things I'd like to have, too


vFile: handle swarm node promotion and demotion

Resolves https://github.com/vmware/docker-volume-vsphere/issues/1732
When a node is promoted from worker to manager, the helper thread will join ETCD cluster according to swarm information.
On the other hand, when the node is demoted from manager to worker, the helper thread should stop the watcher, delete itself from ETCD member list, and clean up the ETCD data directory.
This is required since due to the role change, the cluster may eventually run out of original managers, and thus the ETCD cluster.
Manually tested with 4-node swarm cluster and having one of the node promoted/demoted multiple times. Using etcdctl to verify the ETCD service is in correct status according to the node role change.

I am not sure what is the "testbed problem", so I assume this is something preventing you from writing and committing automated tests. In this case IMO this  should be the top priority and top work item - to enable automated testing before doing any (not automatically tested) feature work

@lipingxue
I added a e2e test for this PR.
The new test changes the role of manager and worker in swarm cluster and do volume lifecycle test before and after the role change.
Also some new updates to resolve code conflicts with master branch.
Please review the new changes accordingly. Thank you!


[OS X v10.11.6 'El Capitan'] Linkage Issues Under Homebrew

I'm forking this issue from #739 because the resolution of that issue has not helped me fix Homebrew/homebrew-core#10380.  As logged here, my latest build attempt fails as follows:
⋮
/bin/sh ../libtool  --tag=CXX   --mode=link clang++  -g -O2 -std=c++11 -version-info 3:5 -no-undefined  -L/usr/local/opt/icu4c/lib -o libtesseract.la -rpath /usr/local/Cellar/tesseract/3.05.00/lib  libtesseract_api.la ../ccmain/libtesseract_main.la ../textord/libtesseract_textord.la ../wordrec/libtesseract_wordrec.la ../classify/libtesseract_classify.la ../dict/libtesseract_dict.la ../ccstruct/libtesseract_ccstruct.la ../cutil/libtesseract_cutil.la ../viewer/libtesseract_viewer.la ../ccutil/libtesseract_ccutil.la ../opencl/libtesseract_opencl.la ../cube/libtesseract_cube.la ../neural_networks/runtime/libtesseract_neural.la -llept
libtool: link: clang++ -dynamiclib  -o .libs/libtesseract.3.dylib   -Wl,-force_load,./.libs/libtesseract_api.a -Wl,-force_load,../ccmain/.libs/libtesseract_main.a -Wl,-force_load,../textord/.libs/libtesseract_textord.a -Wl,-force_load,../wordrec/.libs/libtesseract_wordrec.a -Wl,-force_load,../classify/.libs/libtesseract_classify.a -Wl,-force_load,../dict/.libs/libtesseract_dict.a -Wl,-force_load,../ccstruct/.libs/libtesseract_ccstruct.a -Wl,-force_load,../cutil/.libs/libtesseract_cutil.a -Wl,-force_load,../viewer/.libs/libtesseract_viewer.a -Wl,-force_load,../ccutil/.libs/libtesseract_ccutil.a -Wl,-force_load,../opencl/.libs/libtesseract_opencl.a -Wl,-force_load,../cube/.libs/libtesseract_cube.a -Wl,-force_load,../neural_networks/runtime/.libs/libtesseract_neural.a  -L/usr/local/opt/icu4c/lib -llept  -g -O2   -install_name  /usr/local/Cellar/tesseract/3.05.00/lib/libtesseract.3.dylib -compatibility_version 4 -current_version 4.5 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_TIFFCleanup", referenced from:
      OpenclDevice::pixReadStreamTiffCl(__sFILE*, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadMemTiffCl(unsigned char const*, unsigned long, int) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFClientOpen", referenced from:
      OpenclDevice::pixReadMemTiffCl(unsigned char const*, unsigned long, int) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFFdOpen", referenced from:
      OpenclDevice::fopenTiffCl(__sFILE*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFGetField", referenced from:
      OpenclDevice::getTiffStreamResolutionCl(tiff*, int*, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffStreamCl(tiff*) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFGetFieldDefaulted", referenced from:
      OpenclDevice::getTiffStreamResolutionCl(tiff*, int*, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffStreamCl(tiff*) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFReadDirectory", referenced from:
      OpenclDevice::pixReadStreamTiffCl(__sFILE*, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadMemTiffCl(unsigned char const*, unsigned long, int) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFReadRGBAImageOriented", referenced from:
      OpenclDevice::pixReadFromTiffStreamCl(tiff*) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFReadScanline", referenced from:
      OpenclDevice::pixReadFromTiffStreamCl(tiff*) in libtesseract_opencl.a(openclwrapper.o)
  "_TIFFScanlineSize", referenced from:
      OpenclDevice::pixReadFromTiffStreamCl(tiff*) in libtesseract_opencl.a(openclwrapper.o)
  "_clBuildProgram", referenced from:
      OpenclDevice::CompileKernelFile(_GPUEnv*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clCreateBuffer", referenced from:
      allocateZeroCopyBuffer(_KernelEnv, unsigned int*, unsigned long, unsigned long long, int*) in libtesseract_opencl.a(openclwrapper.o)
      allocateIntBuffer(_KernelEnv, unsigned int const*, unsigned long, int*, bool) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::initMorphCLAllocations(int, int, Pix*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixConvertRGBToGrayOCL(Pix*, float, float, float) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clCreateCommandQueue", referenced from:
      populateGPUEnvFromDevice(_GPUEnv*, _cl_device_id*) in libtesseract_opencl.a(openclwrapper.o)
  "_clCreateContext", referenced from:
      populateGPUEnvFromDevice(_GPUEnv*, _cl_device_id*) in libtesseract_opencl.a(openclwrapper.o)
  "_clCreateKernel", referenced from:
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL(int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL(int, int, unsigned int, unsigned int) in libtesseract_opencl.a(openclwrapper.o)
      pixORCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      pixANDCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clCreateProgramWithBinary", referenced from:
      OpenclDevice::CompileKernelFile(_GPUEnv*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clCreateProgramWithSource", referenced from:
      OpenclDevice::CompileKernelFile(_GPUEnv*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clEnqueueCopyBuffer", referenced from:
      OpenclDevice::initMorphCLAllocations(int, int, Pix*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixHollowCL(Pix*, Pix*, int, int, int, int, bool) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixGetLinesCL(Pix*, Pix*, Pix**, Pix**, Pix**, bool, int, int, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
  "_clEnqueueMapBuffer", referenced from:
      mapOutputCLBuffer(_KernelEnv, _cl_mem*, Pix*, Pix*, int, unsigned long long, bool, bool) in libtesseract_opencl.a(openclwrapper.o)
      allocateIntBuffer(_KernelEnv, unsigned int const*, unsigned long, int*, bool) in libtesseract_opencl.a(openclwrapper.o)
      copyIntBuffer(_KernelEnv, _cl_mem*, unsigned int const*, unsigned long, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixConvertRGBToGrayOCL(Pix*, float, float, float) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clEnqueueNDRangeKernel", referenced from:
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL(int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL(int, int, unsigned int, unsigned int) in libtesseract_opencl.a(openclwrapper.o)
      pixORCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      pixANDCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clEnqueueUnmapMemObject", referenced from:
      mapOutputCLBuffer(_KernelEnv, _cl_mem*, Pix*, Pix*, int, unsigned long long, bool, bool) in libtesseract_opencl.a(openclwrapper.o)
      allocateIntBuffer(_KernelEnv, unsigned int const*, unsigned long, int*, bool) in libtesseract_opencl.a(openclwrapper.o)
      copyIntBuffer(_KernelEnv, _cl_mem*, unsigned int const*, unsigned long, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixConvertRGBToGrayOCL(Pix*, float, float, float) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clFinish", referenced from:
      mapOutputCLBuffer(_KernelEnv, _cl_mem*, Pix*, Pix*, int, unsigned long long, bool, bool) in libtesseract_opencl.a(openclwrapper.o)
      allocateIntBuffer(_KernelEnv, unsigned int const*, unsigned long, int*, bool) in libtesseract_opencl.a(openclwrapper.o)
      copyIntBuffer(_KernelEnv, _cl_mem*, unsigned int const*, unsigned long, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixConvertRGBToGrayOCL(Pix*, float, float, float) in libtesseract_opencl.a(openclwrapper.o)
      ...
  "_clGetContextInfo", referenced from:
      OpenclDevice::CompileKernelFile(_GPUEnv*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clGetDeviceIDs", referenced from:
      OpenclDevice::getDeviceSelection() in libtesseract_opencl.a(openclwrapper.o)
  "_clGetDeviceInfo", referenced from:
      populateGPUEnvFromDevice(_GPUEnv*, _cl_device_id*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::getDeviceSelection() in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::BinaryGenerated(char const*, __sFILE**) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::GeneratBinFromKernelSource(_cl_program*, char const*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
  "_clGetPlatformIDs", referenced from:
      OpenclDevice::getDeviceSelection() in libtesseract_opencl.a(openclwrapper.o)
  "_clGetProgramBuildInfo", referenced from:
      OpenclDevice::CompileKernelFile(_GPUEnv*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clGetProgramInfo", referenced from:
      OpenclDevice::GeneratBinFromKernelSource(_cl_program*, char const*) in libtesseract_opencl.a(openclwrapper.o)
  "_clReleaseCommandQueue", referenced from:
      OpenclDevice::ReleaseOpenclEnv(_GPUEnv*) in libtesseract_opencl.a(openclwrapper.o)
  "_clReleaseContext", referenced from:
      OpenclDevice::ReleaseOpenclEnv(_GPUEnv*) in libtesseract_opencl.a(openclwrapper.o)
  "_clReleaseMemObject", referenced from:
      OpenclDevice::releaseMorphCLBuffers() in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::HistogramRectOCL(unsigned char*, int, int, int, int, int, int, int, int*) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::ThresholdRectToPixOCL(unsigned char*, int, int, int*, int*, Pix**, int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      OpenclDevice::pixConvertRGBToGrayOCL(Pix*, float, float, float) in libtesseract_opencl.a(openclwrapper.o)
  "_clReleaseProgram", referenced from:
      OpenclDevice::ReleaseOpenclEnv(_GPUEnv*) in libtesseract_opencl.a(openclwrapper.o)
  "_clSetKernelArg", referenced from:
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL(int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL(int, int, unsigned int, unsigned int) in libtesseract_opencl.a(openclwrapper.o)
      pixORCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      pixANDCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libtesseract.la] Error 1
make: *** [install-recursive] Error 1
⋮

Both I and those other GitHub users who were helping me with this issue downstream thought it was another instance of the aforementioned #739, but I now think that we were mistaken in believing this given how said issue was resolved.  Basically, the crux of the problem is this:  is there something that previous committers have neglected to add to Homebrew's Tesseract build formula other than Homebrew/homebrew-core#10596, or is Tesseract at fault here and does solving this require Homebrew to mirror an upstream patch until the next release?

First of all: provide details (how you build tesseract, configuration output, libraries version etc.)

Whoops; I should have given that to you in the first place, shouldn't I?  Ah, well, here those details are now:

I initially built and installed Tesseract from within Homebrew by running brew install -vd --build-from-source tesseract --with-all-languages --with-opencl --with-serial-num-pack --with-training-tools, update it by running brew upgrade -vd --build-from-source tesseract --with-all-languages --with-opencl --with-serial-num-pack --with-training-tools, and retry doing either procedure when they fail by running brew reinstall -vd --build-from-source tesseract --with-all-languages --with-opencl --with-serial-num-pack --with-training-tools.  Executing either causes Homebrew to process "$(brew --repository homebrew/homebrew-core)/Formula/tesseract.rb" (a GitHub copy of which is available here,) where "$(brew --repository homebrew/homebrew-core)" is /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core (its default, officially supported location,) according to the brew sub-command given, Homebrew's DSL, and the options I provide using the processing defined in the relevant formula.  @JCount confirmed in this comment on my downstream issue that the option causing trouble is --with-opencl, which, as shown on line 94 of the Homebrew Core tap's tesseract.rb formula, corresponds to Tesseract's ./configure's --enable-opencl option.
The output I get from ./configure is present in my most recent Homebrew installation attempt logs as both 02.configure and lines 134–339 of reinstall.out.
The versions of the build and run-time dependencies required by Tesseract under Homebrew I have installed on my machine are as follows:

autoconf v2.69
autoconf-archive v2017.03.21
automake v1.15
GNU libtool v2.4.6, but patched by the Homebrew Core tap to resolve Homebrew/homebrew-core#3056 and Homebrew/homebrew-core#3882.  (Not the libtool provided by Apple as part of its command-line tools suite, which I also have installed.)
pkg-config v0.29.2
Leptonica v1.74.1 (Built with the following dependencies:

pkg-config v0.29.2
libpng v1.6.29
jpeg v8d
LibTIFF v4.0.7, but patched by the Homebrew Core tap to resolve Homebrew/homebrew-core#8639 and Homebrew/homebrew-core#9409.  — Dependencies are as follows:

jpeg v8d
xz v5.2.3

GIFlib v4.2.3 with a dependency as follows:

X11 (supplied by XQuartz v2.7.11)

OpenJPEG v2.1.2 with dependencies as follows:

CMake v3.7.2 with a dependency as follows:

Sphinx v1.5.1

Little-CMS2 v2.8 with dependencies as follows:

jpeg v8d
LibTIFF v4.0.7 as described above for Leptonica itself

LibTIFF v4.0.7 as described above for Leptonica itself
libpng v1.6.29

WebP v0.6.0 with dependencies as follows:

libpng v1.6.29
jpeg v8d
LibTIFF v4.0.7 as described above for Leptonica itself
GIFlib v4.2.3 with a dependency as described earlier.)

Is that everything you need, or do I need to provide anything else?

I am not familiar with building on Mac, but can you please try to install tesseract "by hand" (without homebrew)?
For linking on macos10 "-framework OpenCL" should be used. Your configure log showed it was detected correctly, but I do not see it in your make log.

@zdenop:  Roger, wilco.  That is odd, though, so whatever could have caused that…?

@zdenop:  I keep getting the following error from ./configure despite the fact that I have Cairo installed even when I add -I/usr/local/opt/cairo/include to CPPFLAGS (though should that be CFLAGS instead…?) and -L/usr/local/opt/cairo/lib to LDFLAGS:
checking for cairo... no
configure: WARNING: Training tools WILL NOT be built because of missing cairo library.
configure: WARNING: Try to install libcairo-dev?? package.

⋮

You can not build training tools because of missing dependency.
Check configure output for details.

Should I be worried about this, or can I just ignore this error since the build problem I'm trying to solve is, IIRC, in Tesseract itself?  I was going to try and make my out-of-Homebrew build and install as close to my in-Homebrew one, which was going to include the training tools if it had succeeded, if you're wondering why I'm asking.  I don't want to overwrite my current non-development version of Cairo in the process, so what do I do?

configure uses pkg-config to detect cairo. It can be overridden by setting cairo_CFLAGS and cairo_LIBS, but fixing the installation would be better of course.

First of all - it is a warning, not an error ;-)
Next: it is not related to originally reported issue (opencl build), so please ignore it.

@stweil:  Ah, thanks.

@zdenop:  Heh, whoops; looks like I was mentally applying the conceptual equivalent of -Wwarnings-as-errors, then; my mistake!  In any case, that's what I thought (I just wanted to make sure my judgement was correct by checking with you,) so I'll go ahead and continue this build attempt.

See https://github.com/tesseract-ocr/tesseract/wiki/Compiling for a list of required dependencies. For training tools you need the Dev version of libraries.

@Shreeshrii:  That's what confused me in the first place, as Homebrew seems to be able to build the training tools just fine with the production versions of their dependencies.  Perhaps it implements some sort of hack to make this (mostly) work, but I'd have to check the package manager's Tesseract formula to be sure of that, as I don't remember seeing anything special there before, which is odd…; maybe the difference is further up in the dependency chain and has to do with Homebrew presents some of its nodes to other software packages?  Or perhaps there's a Homebrew shim I don't know about, but I thought I remembered that the package manager only instrumented system-level build tools…

Now that I've kept thinking about this discrepancy for a little bit, maybe it has to do with Homebrew's superenv shim…?

@zdenop:  OK, here are the logs from my attempt to build Tesseract manually outside of Homebrew.  The new failurehttps://github.com/RandomDSdevel/Homebrew-Installation-Logs/blob/master/Tesseract/v3.05.00/Fourth Attempt/make.out#L840-L973 looks identical to the one produced when building inside Homebrew at first glance, and I don't think I see -framework OpenCL anywhere in my build logs, either, which is weird since you say Tesseract's ./configure should add that in where needed.

@zdenop:  Would like me to run another attempt with make's verbosity increased?

@jbarlow83: Can you have a look on this issue? It seems to me problem with linking (OpenCL build on OS X)

When this issue first cropped up in Homebrew, I tried building it outside of Homebrew's framework in a clean VM. I unsuccessfully tried various approaches, which I have of course forgotten, but it always fails with:
      ...
"_clSetKernelArg", referenced from:
      OpenclDevice::pixReadFromTiffKernel(unsigned int*, int, int, int, unsigned int*) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL_55(int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixDilateCL(int, int, int, int) in libtesseract_opencl.a(openclwrapper.o)
      pixErodeCL(int, int, unsigned int, unsigned int) in libtesseract_opencl.a(openclwrapper.o)
      pixORCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      pixANDCL_work(unsigned int, unsigned int, _cl_mem*, _cl_mem*, _cl_mem*) in libtesseract_opencl.a(openclwrapper.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libtesseract.la] Error 1
make: *** [install-recursive] Error 1

Also, I can confirm this is still an issue using Xcode 8.3 on macOS 10.12.4 as well, no magical, mysterious fix with the latest update.

@JCount:  Well, that's not encouraging.  I'd update my environment to Sierra and the latest Xcode myself, but I'm stuck on an unsupported machine for the time being.  Since it doesn't help in this particular instance, however, I guess I shouldn't push myself to worry about that!  😆

@zdenop:  Given that this issue is consistently reproducible both inside and outside of Homebrew, should we perhaps change this issue's title to something more like 'OS X/macOS OpenCL Linkage Errors?'

Maybe it not a macOS issue, but A Clang issue.
Did someone tested 3.05 on Linux with Clang?

@amitdo:  Not that I know of.  I don't have a Linux install available for testing.

Did someone tested 3.05 on Linux with Clang & OpenCL?

I just tested the build, and it worked without any problem using ./configure CXX=clang++-3.8 CXXFLAGS="-g -O2 -Wall" --enable-opencl && make training.

@stweil:  What about Clang 4?  According to Homebrew, that's what I've got installed:
…$ brew info llvm
llvm: stable 4.0.0 (bottled), HEAD [keg-only]
Next-gen compiler infrastructure
http://llvm.org/
/usr/local/Cellar/llvm/4.0.0 (4,450 files, 2GB)
  Built from source on 2017-03-15 at 00:35:00 with: --with-toolchain --with-python --with-graphviz
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/llvm.rb
==> Dependencies
Build: cmake ✔
Recommended: libffi ✔
Optional: graphviz ✔, ocaml ✔
==> Requirements
Optional: python ✔
==> Options
--with-graphviz
	Build with graphviz support
--with-lldb
	Build LLDB debugger
--with-ocaml
	Build with ocaml support
--with-python
	Build bindings against custom Python
--with-shared-libs
	Build shared instead of static libraries
--with-toolchain
	Build with Toolchain to facilitate overriding system compiler
--without-compiler-rt
	Do not build Clang runtime support libraries for code sanitizers, builtins, and profiling
--without-libcxx
	Do not build libc++ standard library
--without-libffi
	Do not use libffi to call external functions
--HEAD
	Install HEAD version
==> Caveats
LLVM executables are installed in /usr/local/opt/llvm/bin.
Extra tools are installed in /usr/local/opt/llvm/share/llvm.
To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"

This formula is keg-only, which means it was not symlinked into /usr/local.

macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have this software first in your PATH run:
  echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.bash_profile

For compilers to find this software you may need to set:
    LDFLAGS:  -L/usr/local/opt/llvm/lib
    CPPFLAGS: -I/usr/local/opt/llvm/include

If you need Python to find bindings for this keg-only formula, run:
  echo /usr/local/opt/llvm/lib/python2.7/site-packages >> /usr/local/lib/python2.7/site-packages/llvm.pth

Scratch that:  now I feel somewhat silly, as, according to Apple's list of Macs that support OpenCL, my machine (a mid-2007 aluminum iMac) is listed as supporting a 'non-applicable' version of the standard — that is, none at all!  This issue may still be relevant if @JCount's still seeing issues with his setup, though, unless he also has an unsupported machine….  The runtime might still be present in my installation, though, as I've seen the Metal binaries just floating somewhere waiting for when I clone this drive's contents into a machine that supports that API, so I'm not entirely sure whether that means I should be seeing link-time errors or not.  With 3.04.01, I was seeing run-time errors, possibly even with return values (can't remember what they were off the top of my head, unfortunately, but I'm pretty sure I still have my old Tesseract installation around, so I can go check.)

I think you need OpenCL 1.2 or higher.

@amitdo:  Well, again, that might explain things…

I have a machine that supports OpenCL 1.2, both with the Intel Iris Pro Graphics 5200 iGPU and the AMD Radeon R9 M370X dGPU.

I am not OS X user, so maybe I am wrong. But from logs it seems that:

configure detect OpenCL framework
make output show there is not linking to against OpenCL framework

Yes, it seems to detect the presence of the OpenCL headers, and therefore framework. The issue seems to be in the linking as you say, and I honestly have no idea what is going wrong there.

@zdenop, @JCount:  Strangely enough, here is the result of a bit of investigation I just did on my end:
…$ ls -@aHhl /System/Library/Frameworks/ | grep OpenCL.framework
drwxr-xr-x    8 root  wheel   272B Dec 13 16:41 OpenCL.framework

So the OpenCL runtime is present on my machine even if it's not doing anything other than just sitting there.  Either this just gets installed with the OS whether your machine supports it or not or the framework's presence is a relic of that one time I tried to install OS X so as to make it bootable on both this iMac and a newer MacBook Pro (can't remember the exact model ATM, sorry…) by first running a clean OS install to this external drive from the latter and then doing an delta install to said drive from the former — though I think I may have once done a clean install to the drive in question just from the iMac, so maybe my earlier hypothesis is correct…?  :man_shrugging:

I got vanilla (no homebrew) Tesseract 3.05 to compile and run. Machine is late 2013 iMac 27" with Sierra and OpenCL 1.2 support.
clang --version
Apple LLVM version 8.1.0 (clang-802.0.38)

./configure --enable-opencl LDFLAGS='-framework OpenCL' LIBS='-ltiff'
make -j

When the explicit LDFLAGS='-framework OpenCL' is removed the build fails. For some reason  --enable-opencl does not enable linking -framework OpenCL everywhere it should. Doing this causes -framework OpenCL to also show up twice sometimes, based on skimming the logs.
Likewise, removing the explicit libtiff linkage will fail.
I don't have a lot of time to investigate the build machinery this week, but hopefully this analysis is enough of a clue to figure what is not working. If nobody bites I will look into it next week.
I did not try building training tools.

@zdenop, @stweil, @JCount, and/or @jbarlow83:  What testing remains to be done with respect to tracking down exactly what's going wrong here?  Might there be anything I could do to help?

@RandomDSdevel In configure.ac there is some logic that says "if we get --enable-opencl and we are only a Mac, set the variable named OPENCL_LDFLAGS="-framework OpenCL", the special argument for Mac frameworks. Other platforms are working fine because they don't have or don't use -framework as far as I know. I actually don't know the details of what it does.
Most likely there is a Makefile.am (probably) that should set its local local_LDFLAGS= $(OPENCL_LDFLAGS) because it uses OpenCL, but does not. Or perhaps it is the main Makefile at the link step.
The lazy way would be to jump back about six months or so to find a version that compiled and git bisect your way to the breaking change, since it did work until recently.

Well, I'm not very fluent in Autoconf, Automake, and/or makefile syntax and have never used git bisect before, but I know bash shell scripting syntax well enough that I think I can at least point others in the right direction to look.  The v3.05 logic in configure.ac that's responsible for handling that script's --enable-opencl option occupies lines 173–248 — specifically, OPENCL_LDFLAGS is set to "-framework OpenCL" on line 223 in the middle of the code (lines 211-225) responsible for setting up the correct OpenCL compilation and linkage flags for use on Darwin-based operating systems like OS X/macOS.  I haven't yet looked for or at a Makefile.am, but I do remember seeing one somewhere in the source code earlier; I'll just have to look for it again (hopefully it's in the repository's root directory or not far from it.)  If that doesn't give us any clues, I'll check this 'main Makefile,' whatever it happens to be called.

@jbarlow83:  I checked in my last local build attempt and neither "$(git rev-parse --show-toplevel)/Makefile.in", "$(git rev-parse --show-toplevel)/Makefile.am", nor "$(git rev-parse --show-toplevel)/Makefile" (the first and third of which are generated by "$(git rev-parse --show-toplevel)/aurogen.sh" and/or "$(git rev-parse --show-toplevel)/configure.ac" —sorry, but I can't exactly remember which script does what at the moment…) mess with any kind of local_LDFLAGS variable.  In fact, I ran find . -type f -print0 | xargs -0 grep "*local_LDFLAGS*" inside my local checkout of the Tesseract repository (still on branch 3.05 with artifacts left over from my last failed out-of-Homebrew/vanilla build) and came up empty — but maybe I was doing something wrong with this command pipeline invocation…?

As I mentioned I can look into this next week, just not now.
The issue is likely that some new code was introduced and the build system was not properly modified so there is no code to search for it. It is the absence of some necessary code that is the trouble. As you're not familiar with autotools my rough problem sketch is probably not helpful. What would help is to run git bisect and find the commit that breaks the build on macOS, since it used to work. That is likely a strong indicator of what kind of fix is needed.

@jbarlow83:  Sorry to bother you with details you probably could have figured out easily enough yourself, then.

@RandomDSdevel, please try pull request #808. It fixes "make training" with OpenCL on macOS for me.

@stweil:  Thanks, but I'm not sure that will help with this issue, as it has to do with not being able to linking Tesseract itself with OpenCL…  As I mentioned before, though, this problem might alos have something to do with the fact that invoking OpenCL functionality on my machine probably only returns responses indicating the fact that the library doesn't work with my graphics card, as Apple never supplied drivers for it.  @JCount, however, has a machine that does support OpenCL and said he's getting similar link-time errors.  IIRC, @jbarlow83 has also reproduced this issue and has said he'd look into trying to fix it some time this week, but I'm not going to invoke him any further than that, as he advised not to badger him too much about it (I've probably already annoyed him enough as it is, what with my overly enthusiastic impatience to get this fixed and all…)

I'm not annoyed, at all, I just have to do the work that pays the bills first. :)

@jbarlow83:  Whoops, look like I was reading a little too much into things, ha-ha…

@jbarlow83:  Just saw your work start popping up in #814.  I have one comment on it, but I'll leave it in the relevant discussion thread.


Set up performance monitoring with vendor

[x] provide info to vendor about requirements
[x] document options
[x] get agreement on tool choice from team
[x] get contract and budget in place to set up monitoring
[x] implement custom KPI monitoring
[x] set up speedcurve

Acceptance Criteria

Continuous monitoring in place for chosen KPI

We decided to go with Speedcurve for performance monitoring. The add-ons team already had an account, so we are piggybacking for now.

Added dashboard here: https://docs.google.com/spreadsheets/d/1e2_481_W3EZV4CNOp34zqSH2Uc8jJf9ynWkYjtnK_38/edit#gid=0

And the overview is here: https://docs.google.com/document/d/1--UkLq4Rf1mCl9DV3R3p4yX3B-bFuJT4X92eCY8PYXg/edit?ts=5b293d95#heading=h.5vz9l4cg8rwk

dashboard on Speedcurve: https://speedcurve.com/mozilla-add-ons/mdn/status/?share=71hfcbvl6zc1j8v1bojr5m6l28doql


Changed form_open() to compare $action against base_url()

Checking for strpos($action, $CI->config->site_url()) === FALSE causes CSRF token to not be added in form_open() output. When site_url()'s first parameter ($uri) is empty, site_url's return value is the base URL plus the $CI->config->item('index_page') value.  form_open() and CodeIgniter's URI routing do not require index.php to be in the URL, so any call to form_open() in which the $action parameter does not have index.php will always return false for the strpos() call.

Can you add this to the changelog please?
By sending this to develop you are sending it to 3.0. You could send it to 2.1 if you like by sending the pull request to 2.1-stable but remember that the user guide for each is different as its being rewritten in 3.0.

 My apologies for not doing so (just noticed that the documentation requirements on the Contribution page request changelog updates, sorry! - my eyes conveniently glanced over that...)  One quick question, though (sorry to be a bother if this information is available elsewhere!): This was my first pull request that I've submitted so I'm not exactly sure what needs to be done for the changelog... Should I just update the changelog.rst file in /user_guide_src?
Is it troublesome for you if I submit the pull request to both, or should I stick with one particular branch? If I should submit the pull request to one particular branch, would you prefer 2.1 or 3.0 for this fix?
Regards,
John

No problems John it's really not any bother :)
So for bug fixes, trivial changes, small improvements etc it makes sense to send it to 2.1-stable.
Then we can merge those changes over and although the user guide will conflict we can just manually move them from the old changelog to the new when we do.
If you send changes to both branches then they will conflict even more next time a merge happens.
 My apologies for not doing so (just noticed that the documentation requirements on the Contribution page request changelog updates, sorry! - my eyes conveniently glanced over that...)  One quick question, though (sorry to be a bother if this information is available elsewhere!): This was my first pull request that I've submitted so I'm not exactly sure what needs to be done for the changelog... Should I just update the changelog.rst file in /user_guide_src?
Is it troublesome for you if I submit the pull request to both, or should I stick with one particular branch? If I should submit the pull request to one particular branch, would you prefer 2.1 or 3.0 for this fix?
Regards,
John

Reply to this email directly or view it on GitHub:
https://github.com/EllisLab/CodeIgniter/pull/703#issuecomment-2862828

Will do.  And for the changelog?

Are you asking what do you put in the changelog? Just look at the others and try to make the wording and syntax match. If it's not great we'll give feedback.

Oh, no! Sorry I wasn't more clear... I was trying to get some clarification regarding this:

This was my first pull request that I've submitted so I'm not exactly sure what needs to be done for the changelog... Should I just update the changelog.rst file in /user_guide_src/source?

Yes, make the changelog change in whichever changelog is appropriate for that branch. 3.0 = user_guide_src/source

Thanks! I will do this right now and submit a pull request for 2.1-stable.


Update the listing for Black Sea

It has been a few years since Black Sea was updated.
update the shipping maps, scenarios and campaigns from the latest module
get the latest scenarios from the depot
update the info from the blitz records too

Fixed just before repo was created.

Update has been depoyed


fix: network ssl setting does not work as written

When tested the documented command fails to enable ssl 1.2, tested with this command and it works.

@alkohli

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off Verified with product SME: Jia Yu that the change is good.


WIP: feat/js/nrs 45/add solid start

We use this PR to solid-start migration.
We need some dependencies from Hope UI, so we need to change the code thinking in that changes.