Cant Modify to MS SQL

I could do a model correctly, but when i change in options type of database from Mysql to MS Sql, the code generator doesnt change, so i cant export the correct code to my SQL SERVER DB. How could i change DB Type and that the model could generate code for that DB?

The DB type is stored along with your design, because the DB type influences what column types are available.
This means that your design is bound to a DB and it is not possible to change this later. I am not aware of any way to improve this, because various DBs differ by their (datatype) capabilities.


Enable plan feedback (commenting) on a specific area of the plan

Please complete the following fields as applicable:
What version of the DMPRoadmap code are you running? (e.g. v2.2.0)
Roadmap 3.0.2
Expected behaviour:
Enable ability to highlight text within a plan and comment on it. A bit like the commenting/review functionality in MS Word.
Actual behaviour:
Currently, admins can provide feedback per question, via the Comments facility.
Steps to reproduce:
Provide feedback on a test plan.

This would be a large amount of work. We need to think about the best way to implement.

Comment from one of the users who took part in the usability testing in 2020:
'Having the "feedback comments" in the same frame as guidance is a poor idea. We need the feedback next to the text it relates to, not in the middle of the documentation (ultimately, I ended never using those boxes. Emails and live discussions are 100 times better than writing complicated stuff in a tiny, hardly visible box).'

The latest version of Tinymce has some inline commenting functionality that may be useful for this: https://www.tiny.cloud/tinymce/features/comments/

Thanks @briri , I'll look at this tomorrow afternoon just to get an impression of what it does and whether it is close enough to what people asked for.
Would it be easy to implement?

possibly, the Tinymce editor can be a painful thing to manage. I think that commenting functionality may be part of a paid version (premium) of the editor that incurs an annual cost.


make readahead timeout configurable

Why?

I'm regularly seeking around files that I know are larger than could be read in 100ms and I'd like to cancel the request rather than trying and failing to reuse the connection. Setting the readaheadTimeout to 0ms let's me handle reading ahead vs. reopening the connection above the okhttp layer.

Gotcha. Does Call.cancel() work for you? That’s immediate.

so that's our current workaround, but it means I need to keep the Call around with my Response. It would be great if I could just pass around the response and have close on the body kill the connection immediately.

Any chance you can upgrade your backend to HTTP/2 ? That way you can cancel instantly and you don’t have to pay for a connection setup with each call.
I’m reluctant to add this feature because it guarantees degraded behavior for everyone that uses it.

It's an external service that I don't control, unfortunately. Does a disableReadahead setting to the client sound less error prone?

The setting is leaking an implementation detail. I really don't like the idea of adding a setting that potentially wrecks your performance.
Have you considered using byte ranges in your requests? That would avoid the need to truncate a connection.
Otherwise I think Call.cancel is the best approach here.

Think we're going to have to continue to use Call.cancel. It would be nice if we could cancel the Response directly though.

This will do it:
  ResponseBody cancelOnCloseBody(final Call call, final ResponseBody body) {
    return new ResponseBody() {
      @Override public MediaType contentType() {
        return body.contentType();
      }

      @Override public long contentLength() {
        return body.contentLength();
      }

      @Override public BufferedSource source() {
        return Okio.buffer(new ForwardingSource(body.source()) {
          @Override public void close() throws IOException {
            call.cancel();
            super.close();
          }
        });
      }
    };
  }


Newcomer task: Rails route explorer

One thing some projects do that we could do more of is identifying problems that would be good for newcomers to tackle. We've been really thrilled to see lots of new faces over the past few weeks, and so here is a bouquet toss for an excellent project idea that could get your contribution featured on the Stimulus Reflex Expo site.
Rails routes explorer
Let's offer visitors a demo where they can inspect the routes on the site. It can borrow elements from the Tabular (sorting), Book Search (filtering) and Todos (facets) demos.
You can obtain this data from running rake routes and memoizing it, or from introspecting the Rails routing system directly, if you know how to do that.
The idea is that you could filter by string, sort by name, method, etc, and use checkboxes to turn on/off things like http verb.
Genuinely useful and relevant to developers while showing off a practical use case. Who's interested?

These might prove helpful:
https://gist.github.com/NullVoxPopuli/8c8af217b7404336c72a
https://www.rubydoc.info/docs/rails/ActionDispatch/Routing/RouteSet

I pretty much have this done. Good learning exercise. I'll push up a PR tomorrow.
Half tempted to rip out bootstrap as well :D

That's awesome!
Please don't touch Bootstrap, that would not be ideal.

Ha, no worries, just been awhile since I've used it and I didn't miss it much :)
Being able to implement a select autocomplete field without even making an Ajax endpoint was pretty swell though!


[Enhancement] Expandable step details for script replays

Feature summary
Currently in Figma there's a different layout for test replay results. In it users can also expand steps on the recorder.
Expanding replayed steps is not currently possible.
Current implementation:

Designs:

Why is this feature important?
No response
Linked resources
See Figma (won't add link here as that's internal).
Additional information
Related to: https://github.com/elastic/synthetics-recorder/issues/61

This is part of https://github.com/elastic/synthetics-recorder/issues/131 so we are going to close this issue.


added a new meme

`    @commands.slash_command(name="boners with lewis", description="Boners with lewis")
async def onlyfans(self, inter):
"""Boners with lewis"""
await inter.send(
"https://pbs.twimg.com/media/FhDemilXEAI_CNx.jpg"
)'
Memes.zip

Actually make it a pull request with the files changed instead of putting the code in the description


SAK-34491 Only 2 decimals used in scoring causes loss of points

jonespm commented in pull 5224:
I think we can take this and test it in trunk, it seems better to round this at the end rather than when you're going along.
Maybe related to https://jira.sakaiproject.org/browse/SAK-39952 and this may all need to be replaced with BigDecimal instead of doubles in here.


Autoware architecture.yaml

I'll keep posting the architecture.yaml of Autoware for each version in this issue.
You can download and open it with dear_ros_node_viewer.
dear_ros_node_viewer autoware_ooo.yaml

2024.03

autoware_2024.03.zip

v1.0

autoware_v1.0.zip

2024.01

autoware_2024.01.zip

2023.10

autoware_2023.10.zip

Hello, how is the.YAML file generated?

Thank you for asking!
ROS evaluation tool, named CARET, is used to create a yaml file.

Thank you very much for your reply. Do you have a tutorial on how to use this tool?

This is the tutorial of CARET. You can use this command to create an architecture.yaml. Also, this page explains how to use CARET for Autoware.
CARET is an analysis tool which requires some works to introduce, and the yaml file contains more information than just node structure. If you just want to save a node diagram which runs on you PC, you don't need CARET. You can just click Menu bar -> ROS -> Load Current Graph , while running Autoware in the same PC. Then, temp.dot file will be created. Next time you can open the file without running Autoware ( dear_ros_node_viewer temp.doc)

This work has been moved to https://github.com/orgs/autowarefoundation/discussions/5546


Description
Testing gh actions to accept a story

Warnings

:warning:

It looks like you are attempting to bypass a linter rule, which is not within
security compliance rules.
** Contains a rule that is not in the permitted eslint list. You are free to disable only: (
no-underscore-dangle
,prefer-object-spread
,object-shorthand
,camelcase
,react/jsx-props-no-spreading
,react/destructuring-assignment
,react/forbid-prop-types
,react/prefer-stateless-function
,react/sort-comp
,import/no-extraneous-dependencies
,import/order
,import/prefer-default-export
,import/no-named-as-default
) **
Please remove the bypass code and address the underlying issue. cc: @transcom/Truss-IS3

:warning:
This PR does not include changes to unit tests, even though it affects app code.

Messages

:book:
:link: MB-5827

  Generated by :no_entry_sign: dangerJS against e48c476dab62be3d0af407b671320430e58b5592


Error when no awslogs region is set. It should use the EC2 instance's region instead.

When no awslogs region is set, an error is returned.
But it should use the EC2 instance's region instead.
Acording to the the documentation at:
https://docs.docker.com/engine/admin/logging/awslogs/#awslogs-region
"By default, if your Docker daemon is running on an EC2 instance and no region is set, the driver uses the instance’s region."
docker run -d --name hello_world -p 80:80 --log-driver=awslogs --log-opt awslogs-group=hello_world_logs<PHONE_NUMBER>10.dkr.ecr.us-east-1.amazonaws.com/companyname/hello_world:v74
Unable to find image '012345678910.dkr.ecr.us-east-1.amazonaws.com/companyname/hello_world:v74' locally
v74: Pulling from stylight/hello_world
d42343cab195: Pulling fs layer
a353426643e9: Verifying Checksum
a353426643e9: Download complete
e2b90e988768: Pull complete
(...)
Digest: sha256:3025240327b1ab81406a9314c1dc050c73dd7cee4d2ff381b8d923336a2d3fc0
Status: Downloaded newer image for<PHONE_NUMBER>10.dkr.ecr.us-east-1.amazonaws.com/companyname/hello_world:v74
8d562b5eacb35b7bb16e97ae7e83893851b4af5a165cfe03bd4bd6528e9b335d
Error response from daemon: Cannot start container 8d562b5eacb35b7bb16e97ae7e83893851b4af5a165cfe03bd4bd6528e9b335d: Failed to initialize logging driver: must specify a value for environment variable 'AWS_REGION' or log opt 'awslogs-region'
Here the region was not specified by setting a AWS_REGION environment variable nor passing the --log-opt awslogs-region.
After passing the docker parameter --log-opt awslogs-region to the docker run command, it works fine.
Running docker 1.10.1 on Ubuntu 14.04 (EC2 instance)

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

The EC2 instance was actually running docker 1.9.1, not docker 1.10.1.
After upgrading, it works as expected. I'm closing this issue, it's invalid. Thanks @GordonTheTurtle for asking the extra info.


boto to boto3

Summary
Some of the scripts are still trying to use the boto library. dm-utils
has been updated to use boto3 and create its own S3ResponseError, so
let's update this to do the same.

Grepping boto brings up this - does that need updating too?
scripts/make-g-cloud-live.py:@backoff.on_exception(backoff.expo, (dmapiclient.HTTPError, boto.exception.S3ResponseError, ), max_tries=5)

Ask David 😛

Yes and no.
It likely would if we want to get rid of our boto usage in all our scripts. However we are just going to try and fix this script by moving it to phython 3 as it's broken on jenkins at the moment.
We thought about fixing the other and then were weary that it was probably being run in python2 at the moment and decided not to try and fix that too at this point but hopefully should come up with gcloud is made live...


[4.0.1]: a tags in menus have their hover styles take precedence over their active styles

a tags in menus prioritize hover styles over active styles, resulting in little feedback on click.

@exoRift good catch, thanks for finding this. Fixed with 095425b.

@exoRift I'm not seeing this behavior, at the moment the active style takes precedence over hover. Can you post an example (as well as which browser you're using)?

Set up the following (not sure if the classes are relevant, but I'm copying them from my impl):
return (
  <Navbar className='bg-base-200 sticky top-0 px-4 bg-opacity-80 backdrop-blur-sm z-40'>
    <Navbar.Start>
      <Menu horizontal>
        <Menu.Item>
          some anchor
        </Menu.Item>
      </Menu>
    </Navbar.Start>
  </Navbar>
)

You'll notice that upon clicking on the anchor, there is no change. However, if you use the inspector to force an active state (without hovering over), you'll see that the anchor bg transitions to neutral.
I'm using Chrome on Windows.

@exoRift threw the code you provided into a quick code sandbox with react-daisyui 4.0.2 and everything looks good:
https://github.com/daisyui/react-daisyui/assets/64439681/9de4015e-aeb7-4c78-bc4e-4043da28425d
What theme are you using? It's possible the palette you've chosen/setup has low contrast between hover and active so it's not as noticeable? Or maybe the colors are reversed?

These are the active styles
Overwritten by the hover's !importants

@exoRift !important is neither added in daisyui nor in react-daisyui source code.
It's hard for me to say what's going wrong in your application without any context for the rest of your codebase. Maybe take a look in your globals.cc file and see if some pre-existing CSS is overriding the daisyui styles.

It certainly is odd. I don't have this issue with version 3.1.2 and this specific style seems to be the only one rendered with !importants.

    .dropdown.dropdown-hover:hover .dropdown-content {
        --tw-scale-x: 1;
        --tw-scale-y: 1;
        transform: translate(var(--tw-translate-x),var(--tw-translate-y)) rotate(var(--tw-rotate)) skewX(var(--tw-skew-x)) skewY(var(--tw-skew-y)) scaleX(var(--tw-scale-x)) scaleY(var(--tw-scale-y))
    }

    :where(.menu li:not(.menu-title):not(.disabled)>:not(ul):not(details):not(.menu-title)):not(.active):hover,:where(.menu li:not(.menu-title):not(.disabled)>details>summary:not(.menu-title)):not(.active):hover {
        cursor: pointer;
        background-color: hsl(var(--bc)/.1);
        --tw-text-opacity: 1;
        color: hsl(var(--bc)/var(--tw-text-opacity));
        outline: 2px solid transparent;
        outline-offset: 2px
    }

    :where(.menu li:not(.menu-title):not(.\!disabled)>:not(ul):not(details):not(.menu-title)):not(.active):hover,:where(.menu li:not(.menu-title):not(.\!disabled)>details>summary:not(.menu-title)):not(.active):hover {
        cursor: pointer!important;
        background-color: hsl(var(--bc)/.1)!important;
        --tw-text-opacity: 1!important;
        color: hsl(var(--bc)/var(--tw-text-opacity))!important;
        outline: 2px solid transparent!important;
        outline-offset: 2px!important
    }

    .tab[disabled],.tab[disabled]:hover {
        cursor: not-allowed;
        color: hsl(var(--bc)/var(--tw-text-opacity));
        --tw-text-opacity: 0.2
    }
}

From the built CSS file
I don't have any !importants in my code even remotely related to this.
I have no way to trace it and the only indication I have is globals.css:5 which is just @tailwind components;

Thanks, do let me know if you experience it on the Storybook because that's working as expected for me.
You wouldn't happen to have a browser extension that affects the styles on a page, e.g. recolors them or adds a fake dark mode? That's all I can think of assuming the rest of your project is totally boilerplate.

No, I don't. Just gonna hope this bug manifests elsewhere in some easier-narrowed fashion and gets fixed in some patch.

@benjitrosch I just wanted to let you know that a cause has been identified here and it's most likely a bug with Tailwind


Added Windows CI Tests

Addressed PR notes from:
https://github.com/wetadigital/USDPluginExamples/pull/29

Removed unnecessary set env var commands from CI tests.
Added missing required env vars to ctests
Refactored CI names, extra whitespace.

Previous Comments:

Added Windows Companion to Linux Prebuilt-binary tests
Fixed issue with reversed findPythonInterp and findPythonLibs cmds

Signed-off-by: Cole Clark<EMAIL_ADDRESS>

@colevfx - this looks great!!!


[Question] HowTo fix unstable volumes

Hi,
we are currently migrating our whole infrastructure and services from rancher 1.x to rancher 2.x. At the beginning we felt in love with longhorn.
Unfortunately volumes are stuck in degraded mode or become read-only. If the read-only issue happens some services (for instance gitlab postgres) crashs and we have to restart the workload manually.
Switching "Replica Node Level Soft Anti-Affinity" to enable feels like the "volume stuck degraded" issue become better.
If the "volume stuck degraded" issue happens deleting the lastest snapshot triggers a correct rebuild and the volume become healthy again. But I have to do it manually.
To resolve the "volume read-only" issue I have to restart the workload manually. I know I could build a workaround using readiness but I try to figure out how to make the environment more stable at all.
Before we migrate production services for our customer we want to make sure the environment is stable.
Environment:

Longhorn version: v1.0.2
Kubernetes version:  v1.18.8+k3s1
Rancher version: v2.4.5
Node OS type and version: Debian GNU/Linux 10
3 Nodes

Questions:

I downloaded a "Support bundle" after the gitlab postgresql crash occured. The bundle contains informations like private urls thats why I didn't add it here. What can I do with the bundle?

How can I verify its not a hardware Network or Disk I/O issue?

Is it normal that a new snapshot almost each hour is made?

What else can I do to get a stable environment? Hints?

Let me know if you need more specific logs or informations:
thank you in advance
Darian

@DarianAnjuhal You can send the support bundle to<EMAIL_ADDRESS>and we can take a look.

Thanks for the info, I sent the bundle already.
Yes the high amount of snapshots worried me as well. If its a CPU or network issue hopefully there is a solution without changing the whole hardware/infrastructure.

@yasker
Couldn't reproduce the issue.
Steps to test:

Install k3s v1.18.8+k3s1
Install Longhorn v1.0.2
Create volumes attached to nodes, and other volumes consumed by pods
Write random data to volumes, and compute it's checksum.
Upgrade k3s to v1.19.2+k3s1
Check data checksum
Detach and attach the volumes, and compute data checksum
Write more data to volumes and verify data can be Read/Write
Create new volumes on the upgraded cluster

Volumes, are healthy, and usable in all situations

Hi @DarianAnjuhal
I've checked the support bundle. The problem looks like caused by disconnecting replicas.
How many CPUs you have for each node? What's the level of CPU utilization on your node? And what's the network bandwidth/latency between the nodes?
Regarding the CPU, the result of kubectl top nodes and kubectl -n longhorn-system top pod should be helpful.
Also, there are definitely too many system generated snapshots in our setup. Every time when a replica disconnected, a snapshot will be generated as a part of rebuilding process. You can delete them manually by show hidden snapshots then delete any one of them. You can also clean them up automatically by creating a recurring snapshot e.g. for every day. The system generated snapshots will be cleaned up as a side effect of recurring snapshot or backup.
Once we know the level of CPU utilization and CPU usage of instance managers, we can see if we can raise the GuaranteeEngineCPU level to help with your use case.

Hi @yasker thank for your input.
Regarding the disconnection and the snapshot issue: That is exactly what I was thinking about.
I hope the following infos can help:
kubectl top nodes
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node1   2085m        20%    19264Mi         39%
node2   1278m        21%    17723Mi         55%
node3   1639m        27%    14423Mi         59%

kubectl -n longhorn-system top pod
NAME                                       CPU(cores)   MEMORY(bytes)
csi-attacher-5b4745c5f7-fpb95              1m           10Mi
csi-attacher-5b4745c5f7-g7vkt              1m           6Mi
csi-attacher-5b4745c5f7-rgrth              1m           8Mi
csi-provisioner-57d6dbf5f4-5bw2t           1m           7Mi
csi-provisioner-57d6dbf5f4-8zw57           1m           7Mi
csi-provisioner-57d6dbf5f4-b9ls5           2m           15Mi
csi-resizer-75ff56bc48-2v2xj               1m           6Mi
csi-resizer-75ff56bc48-5xt5d               1m           6Mi
csi-resizer-75ff56bc48-vq5tw               1m           15Mi
engine-image-ei-ee18f965-292z5             5m           19Mi
engine-image-ei-ee18f965-2bc9m             5m           21Mi
engine-image-ei-ee18f965-vm2h9             8m           20Mi
instance-manager-e-0c94fe16                110m         144Mi
instance-manager-e-5630b783                76m          186Mi
instance-manager-e-67361da4                40m          72Mi
instance-manager-r-75c20703                121m         390Mi
instance-manager-r-853cfebd                383m         386Mi
instance-manager-r-b1e1d024                365m         421Mi
longhorn-csi-plugin-27g6q                  1m           21Mi
longhorn-csi-plugin-4pfvn                  1m           18Mi
longhorn-csi-plugin-mwvc8                  1m           19Mi
longhorn-driver-deployer-7fc4667b6-g4m2g   1m           9Mi
longhorn-manager-b6hd6                     343m         297Mi
longhorn-manager-lvpmv                     464m         172Mi
longhorn-manager-n7h2z                     97m          225Mi
longhorn-ui-6fcc8fcb7c-sf6w5               0m           4Mi

More infos about the nodes and the vCPUs:
node1:
RAM 	51539 MB
CPU 	10

node2:
RAM 	34359 MB
CPU 	6

node3:
RAM 	25769 MB
CPU 	6

I used iperf3 and tested the bandwith between the three nodes and  is like 800-950 Mbits/sec.
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   948 Mbits/sec  1881             sender
[  5]   0.00-10.04  sec  1.10 GBytes   941 Mbits/sec                  receiver

If you need more information, let me know.
Thank you for your help

CPU utilization looks fine. Though you still can try to raise the GuaranteedEngineCPU to 750m or 1000m to see if it helps. It means 1.5 to 2 CPUs (750m * 2) per node will be reserved for Longhorn.
However, I think the issue may be due to the network. It's a 1Gb network, which converts to 800Mbits = 100MBytes per second, which is pretty small, considering you have 60 replicas (20 volumes * 3) in the cluster. I am wondering if it's because of network traffic, the latency increased a lot.
You can decrease the replica count to 2 to see if it helps.
Also, in v1.1.0 we will provide a way to clean up system generated snapshot automatically.

Thanks for your hint.
I changed the default replica count to 2 and changed each volume manually to replica count 2 as well.
GuaranteedEngineCPU is still 0,25 because I have to detach each volume before I change this value. I can do that later.
There was the read-only issue today, so I had to restart the minio container manually. Hopefully the new version will solve some issues for me. I am looking forward.

@yasker Thanks, I have changed GuaranteedEngineCPU to 0.75 as you mentioned.
I will see if its getting better. If not you maybe wanna see a new support bundle.
I am looking forward to get a new version.

dmesg on node3 shows:
EXT4-fs error (device sde): ext4_find_entry:1456: inode #2: comm SimpleAsyncTask: reading directory lblock 0
Maybe this information helps
Is this an longhorn issue?

@DarianAnjuhal Do you see the number of incidents reduced once you switch to the guaranteed engine CPU to 0.75?
Also, is it possible to set up a 10G network between the node?
Btw, for v1.1.0 release, we will start to delete the workload pod if the underlying volume experience issues, to allow Kubernetes to recreate the pod and reattach the volume. No need for the liveness probe anymore. #1719

@yasker Thanks for your input.
I guess changing the guaranteed engine CPU to 0,75 doesn't change anything. There are still a lot of read-only issues and the pods (especially mongodb or postgresql) crashes instantly.
In this case its not so easy change the network to 10G but I figure it out.
We are currently using rancher with activated monitoring (prometheus) But I still don't know how to get the informations we need. :-)
I am looking forward for the new version. When can I give it a try? What do you think?

When you encountered e.g. read-only issue on one node, you should have some logs with timestamp in the dmesg.
Then you can check in Rancher/Grafana about the CPU utilization on that node (potentially also the nodes that replica is running), to see if there is any spike of CPU utilization to e.g. 80% above. If that happens, then we know it's likely the CPU.
Can you send us another support bundle along with the dmesg -T collected from every node? We can check if there is anything else might be in play.

Hi @DarianAnjuhal
There is OOM showing in your dmesg
[Thu Oct 22 17:07:23 2020] prometheus invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=985
[Thu Oct 22 17:07:23 2020] prometheus cpuset=26d08f5914482eed4eb5837b64e0945b5a549df244d6b8acd1d86a7a9c09ec73 mems_allowed=0
[Thu Oct 22 17:07:23 2020] CPU: 1 PID: 12769 Comm: prometheus Tainted: G           OE     4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1
[Thu Oct 22 17:07:23 2020] Hardware name: netcup KVM Server, BIOS RS 4000 SAS G8 xRAM 11/23/2018
[Thu Oct 22 17:07:23 2020] Call Trace:
[Thu Oct 22 17:07:23 2020]  dump_stack+0x66/0x90
[Thu Oct 22 17:07:23 2020]  dump_header+0x6b/0x283
[Thu Oct 22 17:07:23 2020]  oom_kill_process.cold.30+0xb/0x1cf
[Thu Oct 22 17:07:23 2020]  out_of_memory+0x1a5/0x450
[Thu Oct 22 17:07:23 2020]  mem_cgroup_out_of_memory+0xbe/0xd0
[Thu Oct 22 17:07:23 2020]  try_charge+0x707/0x780
[Thu Oct 22 17:07:23 2020]  ? __alloc_pages_nodemask+0x112/0x2b0
[Thu Oct 22 17:07:23 2020]  mem_cgroup_try_charge+0x86/0x190
[Thu Oct 22 17:07:23 2020]  mem_cgroup_try_charge_delay+0x1c/0x40
[Thu Oct 22 17:07:23 2020]  wp_page_copy+0x11b/0x700
[Thu Oct 22 17:07:23 2020]  ? mem_cgroup_commit_charge+0x7a/0x560
[Thu Oct 22 17:07:23 2020]  do_wp_page+0x8e/0x5f0
[Thu Oct 22 17:07:23 2020]  __handle_mm_fault+0xb8b/0x1270
[Thu Oct 22 17:07:23 2020]  handle_mm_fault+0xd6/0x200
[Thu Oct 22 17:07:23 2020]  __do_page_fault+0x249/0x4f0
[Thu Oct 22 17:07:23 2020]  ? async_page_fault+0x8/0x30
[Thu Oct 22 17:07:23 2020]  async_page_fault+0x1e/0x30
[Thu Oct 22 17:07:23 2020] RIP: 0033:0x426062
[Thu Oct 22 17:07:23 2020] Code: 40 00 0f 83 84 00 00 00 49 89 f0 48 c1 ee 0d 48 8b 1c c3 4c 8b 4c 24 30 4c 8b 54 24 38 31 c0 eb 16 84 03 49 81 e3 ff 1f 00 00 <4e> 89 94 db 00 00 20 00 49 8d 44 24 01 4c 39 c8 73 3c 4c 8d 1c 06
[Thu Oct 22 17:07:23 2020] RSP: 002b:000000c000fb7e20 EFLAGS: 00010206
[Thu Oct 22 17:07:23 2020] RAX:<PHONE_NUMBER>000000 RBX: 00007f6b58729000 RCX:<PHONE_NUMBER>000001
[Thu Oct 22 17:07:23 2020] RDX:<PHONE_NUMBER>0c7e80 RSI:<PHONE_NUMBER>02d400 RDI:<PHONE_NUMBER>000000
[Thu Oct 22 17:07:23 2020] RBP: 000000c000fb7e30 R08: 000000c05a800000 R09:<PHONE_NUMBER>000001
[Thu Oct 22 17:07:23 2020] R10: 00007f6b58698938 R11:<PHONE_NUMBER>001400 R12:<PHONE_NUMBER>000000
[Thu Oct 22 17:07:23 2020] R13:<PHONE_NUMBER>000040 R14:<PHONE_NUMBER>d6398a R15:<PHONE_NUMBER>000000
[Thu Oct 22 17:07:23 2020] Task in /kubepods/burstable/pod3d119d81-b7a2-409b-9644-53b2d14fe566/26d08f5914482eed4eb5837b64e0945b5a549df244d6b8acd1d86a7a9c09ec73 killed as a result of limit of /kubepods/burstable/pod3d119d81-b7a2-409b-9644-53b2d14fe566/26d08f5914482eed4eb5837b64e0945b5a549df244d6b8acd1d86a7a9c09ec73
[Thu Oct 22 17:07:23 2020] memory: usage 1536000kB, limit 1536000kB, failcnt 75651
[Thu Oct 22 17:07:23 2020] memory+swap: usage 0kB, limit<PHONE_NUMBER>740988kB, failcnt 0
[Thu Oct 22 17:07:23 2020] kmem: usage 9916kB, limit<PHONE_NUMBER>740988kB, failcnt 0
[Thu Oct 22 17:07:23 2020] Memory cgroup stats for /kubepods/burstable/pod3d119d81-b7a2-409b-9644-53b2d14fe566/26d08f5914482eed4eb5837b64e0945b5a549df244d6b8acd1d86a7a9c09ec73: cache:496KB rss:1525432KB rss_huge:0KB shmem:0KB mapped_file:132KB dirty:264KB writeback:0KB inactive_anon:0KB active_anon:1525948KB inactive_file:68KB active_file:68KB unevictable:0KB
[Thu Oct 22 17:07:23 2020] Tasks state (memory values in pages):

It's weird since you have tons of memory available. It seems you've set the Prometheus memory limitation to around 1.5Gb and it was killed due to exceeding that limit.
Also, from the latest support bundle, you have 18 volumes. Since your network bandwidth is 1Gbps = 128MiB, so each volume may have about 7MiB per second bandwidth, which is pretty low. So I still think the network is the cause of frequent disconnection here.
Longhorn v1.1.0 is targeting middle November so it's about half a month from now.

@DarianAnjuhal has reached out to me in slack, mentioned his issue still exists.
One KB article might help: https://longhorn.io/kb/troubleshooting-volume-readonly-or-io-error/
@DarianAnjuhal Can you also fill in the questionnaire below again:
Environment:

Longhorn version:
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of volumes in the system:

@DarianAnjuhal has reached out to me in slack, mentioned his issue still exists.
One KB article might help: https://longhorn.io/kb/troubleshooting-volume-readonly-or-io-error/
@DarianAnjuhal Can you also fill in the questionnaire below again:
Environment:

Longhorn version:
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of volumes in the system:

This problem disappeared once we moved from HDDs to SSDs, however that required spending a lot of money and losing time.

This problem disappeared once we moved from HDDs to SSDs, however that required spending a lot of money and losing time.

@mattcg @DarianAnjuhal Longhorn isn't designed for HDD though. The IOPS of HDD can provide is below what Longhorn requires, so it's hard to provide a stable system in that way. See https://longhorn.io/docs/1.1.0/best-practices/#minimum-recommended-hardware

@mattcg @DarianAnjuhal Longhorn isn't designed for HDD though. The IOPS of HDD can provide is below what Longhorn requires, so it's hard to provide a stable system in that way. See https://longhorn.io/docs/1.1.0/best-practices/#minimum-recommended-hardware

All SSD k8s is a pretty big ask. In my opinion software should be designed around the needs of organisations, and not vice versa...

All SSD k8s is a pretty big ask. In my opinion software should be designed around the needs of organisations, and not vice versa...

@mattcg Sorry to hear that. Supporting the spinning disk is not the design goal of Longhorn. Since the random IOPS is too low with a spinning disk, the software needs to be much more complex just to handle it properly. I suggest looking at other storage solutions that support spinning disk well, to better support your use case.

@mattcg Sorry to hear that. Supporting the spinning disk is not the design goal of Longhorn. Since the random IOPS is too low with a spinning disk, the software needs to be much more complex just to handle it properly. I suggest looking at other storage solutions that support spinning disk well, to better support your use case.

Okay thank you. We are using HDD as well so thats probably why we have issues.

Okay thank you. We are using HDD as well so thats probably why we have issues.


Can we make the error messages be useful?

I have PRs just languishing because the error messages don't make any sense.

Check if #1013 helps!


Latest Version of VS Code (Pylance) Doesn't Recognize Site-Package Import

Type: Bug
Running in a Python virtual environment (venv), the venv have the package installed (in this case Flask), but when the workspace is set to the virtual environment, and try to import that package, Pylance show missing import.
Extension version: 2023.9.11
VS Code version: Code - Insiders 1.83.0-insider (5a400e53e985dc5e24f6ee574b07ab23943841c5, 2023-09-07T17:36:06.641Z)
OS version: Darwin arm64 22.6.0
Modes:

System Info

Item
Value

CPUs
Apple M1 Max (10 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
1, 2, 2

Memory (System)
32.00GB (3.12GB free)

Process Argv
--crash-reporter-id f9036e4b-e00d-411e-91dc-287ea91b369d

Screen Reader
no

VM
0%

This is likely a dupe of #https://github.com/microsoft/pylance-release/issues/4806

This is likely a dupe of ##4806

seems like it or very similar, please feel free to close if it is

just want to confirm that my issue was also fixed with Pylance v2023.9.12.


Abandoned Project

This project has been abandoned, I believe.
No action from the plugin author for 2 years, lots of issues and outstanding pull requests.

This looks like a nice alternative:
https://pub.dev/packages/easy_dynamic_theme

Today I've migrated my app to easy_dynamic_theme and it looks good. It requires less code, changing theme returns void instead of Future (no need to await for the result) and it has three theme options - light, dark and system.

Today I've migrated my app to easy_dynamic_theme and it looks good. It requires less code, changing theme returns void instead of Future (no need to await for the result) and it has three theme options - light, dark and system.

But can you change colors at will like you can with this one?

I'm using https://pub.dev/packages/dynamic_themes.
It's also a nice choice.

I didn’t find any alternative that allows creating new themes during run time, only predefined ones. If a package exists for this use case let me know 🙏


fix various issues in x509_vfy.c and v3_purp.c related to #1418 and the respective documentation

Fixes #1418. See discussion there.

[x] documentation is added or updated
[x] tests are added or updated

The similarity to #7943 is remarkable :smiley:

The similarity to #7943 is remarkable smiley

@bernd-edlinger, indeed the improvement to x509v3_cache_extensions() is essentially the same, except that your code is slightly nicer, so I've adopted it.
If I had been aware of that PR or if it had been finished and merged meanwhile I would not have had to re-discover that fix. On the bright side, you can take my PR as an approval of that portion of your PR ;-)
BTW, I'm not convinced of the other half of PR #7943 (the change you proposed to check_ca()), to which I'll comment there...

This PR should obsolete #7918.

@vdukhovni

Would you please amend the commit message so it is more descriptive? Also it would make sense to squash at this point and/or split the patches if there are multiple unrelated issues fixed.
I suppose we would want a cherry-pick to 1.1.1 branch as well.

@t8m, yep, I'll do a cleanup pass, squashing commits and putting more text in the commit(s) that remain after (at least partly squashing). Hope you saw that there are already descriptions at issue discussion level, in particular https://github.com/openssl/openssl/issues/1418#issuecomment-562850284
I'll also try to separate concerns, which I fear is only partially possible, so likely the new commits each representing a specific (sub-)issue will need to be hierarchical, i.e., not split-able into independent PRs.
@bernd-edlinger, your change request is already fulfilled.

Maybe it's useful to have some self-issued certs that are not self-signed? And one that has a keyUsage without the keyCertSig. And maybe some other variants.

I don't understand the logic behind -partial_chain. If a certificate is trusted, why does it matter that it's self-signed or not? But I guess that's not something this PR should change.

Maybe it's useful to have some self-issued certs that are not self-signed? And one that has a keyUsage without the keyCertSig. And maybe some other variants.

Only with partial_chain. Otherwise, self-issued certs are not trust-anchors. Trust-anchors need to be self-signed.

I don't understand the logic behind -partial_chain. If a certificate is trusted, why does it matter that it's self-signed or not? But I guess that's not something this PR should change.

The logic allows intermediate certificates to be added to the trust store, without them being trusted, they just represent better versions of the issuer for chain construction.
Windows has an "intermediate certificate store" for this, but OpenSSL does not.  We could in principle require all trust-anchors to be stored as "TRUSTED CERTIFICATE" objects with suitable auxiliary trust EKUs, but that's hard to do without major compatibility breakage.

Maybe it's useful to have some self-issued certs that are not self-signed? And one that has a keyUsage without the keyCertSig. And maybe some other variants.

CAs should generally have keyCertSig, whether they're self-issued, cross (intermediate) or self-signed.

Maybe it's useful to have some self-issued certs that are not self-signed? And one that has a keyUsage without the keyCertSig.

We already have an example of such an interesting cert among the test certs: test/certs/ee-ed25519.pem. It is just self-issued (but not self-signed) and has just keyAgreement as its keyUsage.
You may have noticed that in this PR I've extended the so far single test case for it in test/recipes/25-test_verify.t:
    # ED25519 certificate from draft-ietf-curdle-pkix-04
    ok(verify("ee-ed25519", "sslserver", ["root-ed25519"], []),
       "accept ED25519 ee cert signature w trusted ED25519 self-signed cert");

by four further ones:
    ok(!verify("root-ed25519", "sslserver", ["ee-ed25519"], []),
       "fail trusted ED25519-signed self-issued cert non-match");

    ok(verify("root-ed25519", "sslserver", ["root-ed25519"], []),
       "accept trusted ED25519 self-signed cert");

    ok(!verify("ee-ed25519", "sslserver", ["ee-ed25519"], []),
       "fail trusted ED25519-signed self-issued cert");

    ok(verify("ee-ed25519", "sslserver", ["ee-ed25519"], [], "-partial_chain"),
       "accept last-resort direct leaf match ED25519-signed self-issued cert");

where in the last one provides a concrete example of the usefulness of -partial_chain (or X509_V_FLAG_PARTIAL_CHAIN, respectively) and for the hint I added to doc/man3/X509_STORE_CTX_get_error.pod and doc/man1/openssl-verify.pod discussed above:
To enable using trusted self-issued but not self-signed certificates
the B<-partial_chain> option may be set.

Thanks to all how have taken part already in discussing this PR!
I've just finished all action items (including two change requests) that came up this way:

refactored the code to avoid redundancies and increase readability and maintainability
retained the original (partly strange) semantics of the API function X509_check_issued()
improved the wording of the new documentation texts and comments
reverted that part of the changes to build_chain() that did not really make sense and
re-structured the PR into a series of pretty self-contained commits with better descriptions

Moreover, I've

added a small optimization and safety precaution in find_issuer() of x509_vfy.c
added a further test case with a cert by @Forkest demonstrating successful fix of #1418

@bernd-edlinger, since this feature is used twice in v3_purp.c I've meanwhile moved the matching of key algorithm and signature algorithm that you also did in #7943 into a little function of its own:
/* Check that issuer public key algorithm matches subject signature algorithm */
static int check_sig_alg_match(const EVP_PKEY *pkey, const X509 *subject)
{
    int pkey_nid;

    if (pkey == NULL)
        return X509_V_ERR_NO_ISSUER_PUBLIC_KEY;
    if (OBJ_find_sigid_algs(OBJ_obj2nid(subject->cert_info.signature.algorithm),
                            NULL, &pkey_nid) == 0)
        return X509_V_ERR_UNSUPPORTED_SIGNATURE_ALGORITHM;
    if (EVP_PKEY_type(pkey_nid) != EVP_PKEY_base_id(pkey))
        return X509_V_ERR_SIGNATURE_ALGORITHM_MISMATCH;
    return X509_V_OK;
}

Would be nice if you could review also the rest of the code changes I did in this PR to x509_vfy.c and v3_purp.c - in the end these aren't many.
The bulk of this PR ended up being tweaks to the documentation and code comments.

Pondering on the changes done by this PR I realized that it would be beneficial to export
static int apparently_self_signed(X509 *x)

as
int X509_self_signed(X509 *cert, int verify_signature)

which I did in an extra commit,
splitting X509_sign.pod into X509_sign.pod and X509_verify.pod and extending the latter.

int X509_self_signed(X509 *cert, int verify_signature)

I've actually been pondering about copying cert_self_signed() into
a project, using the undocumented X509_check_purpose() function for
the side effects it currently has.

During preparation of this PR I realized that the division between x509_vfy.c and v3_purp.c is sub-optimal (and could be improved also with the help of x509_local.h).
Yet, unless explicitly requested, I'll refrain from further extending this PR and starting further cleanup PRs for a while because the OpenSSL backlog of open PRs is already/still rather long.

Maybe it's useful to have some self-issued certs that are not self-signed? And one that has a keyUsage without the keyCertSig. And maybe some other variants.

Only with partial_chain. Otherwise, self-issued certs are not trust-anchors. Trust-anchors need to be self-signed.

The last sentence "Trust-anchors need to be self-signed." appears too strong.
@vdukhovni, I guess you meant something like this:
"The certs in the trust store are called trust anchors. These are usually self-signed. Yet with the -partial_chain option any certs are acceptable as trust anchors in the trust store." ?

I don't understand the logic behind -partial_chain. If a certificate is trusted, why does it matter that it's self-signed or not? But I guess that's not something this PR should change.

The logic allows intermediate certificates to be added to the trust store, without them being trusted, they just represent better versions of the issuer for chain construction.

@vdukhovni, when -partial_chain is used, does it make any difference for the certs in the trust store to be self-signed or not? If so, this special treatment appears undocumented and I don't understand it.

Windows has an "intermediate certificate store" for this, but OpenSSL does not. We could in principle require all trust-anchors to be stored as "TRUSTED CERTIFICATE" objects with suitable auxiliary trust EKUs, but that's hard to do without major compatibility breakage.

Here I'm becoming uncertain on what is meant by "trust store" in OpenSSL.
Looking at the parameters of int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, STACK_OF(X509) *chain), is it right that store is/becomes the trust store, and chain is an optional list of untrusted certs? Yet then at least at this level OpenSSL also supports some kind of "intermediate certificate store", with the only drawback that it needs to be explicitly provided for each cert verification.

I guess you meant something like this:
"The certs in the trust store are called trust anchors. These are usually self-signed. Yet with the -partial_chain option any certs are acceptable as trust anchors in the trust store." ?

No. OpenSSL has a notion of trusted certificates which are structures wrapped around X.509 certificates that add a list of permitted and rejected (purpose) EKUs. These are trust anchors.
Undecorated certificates in the trust store are NOT trust anchors, but there is a backwards compatibility feature (that's pretty much universally used) that treats self-signed certificates in the trust store that are wrapped as trusted certificates also as trust anchors.
With -partial_chain the implicit designation as a trust anchor is extended to all the certificates in the trust store, whether self-signed or not.
Ideally, OpenSSL would require explicit trusted certificate objects in the trust store, with regular (unwrapped) X.509 certs being mere untrusted intermediates, useful for when a peer did not send a sufficiently complete intermediate CA chain. But that's not what we've trained our users (and OS distributions that bundle trusted root CAs) to do.

Undecorated certificates in the trust store are NOT trust anchors, but there is a backwards compatibility feature (that's pretty much universally used) that treats self-signed certificates in the trust store that are NOT wrapped as trusted certificates also as trust anchors.

See trust_compat() in crypto/x509/x509_trs.c

@vdukhovni do you meant the "TRUSTED CERTIFICATE" PEM marker and data structure?
Does anyone actually use that?

Thanks @vdukhovni for your explanation. Interesting.
I never read of those decorations around X.509 structures, and
I suppose the same holds for nearly all people using OpenSSL.
When reading, e.g., openssl-verify.pod, which does not define what a trust anchor is but contains sentences like

The signature algorithm security level is enforced for all the certificates in the chain except for the chain's trust anchor, which is either directly trusted or validated by means other than its signature.
-trusted file
A file of trusted certificates, which must be self-signed, unless the -partial_chain option is specified. The file contains one or more certificates in PEM format.
With this option, no additional (e.g., default) certificate lists are consulted. That is, the only trust-anchors are those listed in file.
-untrusted file
Parse file as a set of one or more certificates in PEM format. All certificates are untrusted certificates that may be used to construct a certificate chain from the subject certificate to a trust anchor.

one easily arrives at the naive understanding I mentioned above.
If the more sophisticated interpretation you just provided is of any practical relevance
it should be clearly and prominently documented - which is not the case so far.

Do you meant the "TRUSTED CERTIFICATE" PEM marker and data structure?
Does anyone actually use that?

Yes, but obviously not at all common, since the widely distributed CA bundles are just bare certificates, and almost nobody bothers to wrap up the root CAs as trusted certificate objects.
That said, using explicitly trusted certificates (with appropriately narrow EKUs in some cases) is how trust stores should be managed (in the best of all possible worlds).

If the more sophisticated interpretation you just provided is of any practical relevance
it should be clearly and prominently documented - which is not the case so far.

It is certainly of practical relevance to contributors, since we must not break support for trusted certificates, and it is important to understand implicit trust of self-signed certs in the store as a compatibility feature with past current practice that coexists with explicit trust that should be used, but we've not socialized that as a preferred practice, and it may be ETOOHARD to get all but the most meticulous users to do that.  (Unless Kurt wants to fight that fight for Debian).

-trusted file
A file of trusted certificates, which must be self-signed, unless the -partial_chain option is specified. The file contains one or more certificates in PEM format.
With this option, no additional (e.g., default) certificate lists are consulted. That is, the only trust-anchors are those listed in file.

No.  They need not be self-signed. Without -partial_chain, non-self-signed certificates without explicit wrapping with trust EKUs are just preferred untrusted certificates. When we build a chain we look in the trust store first, and only then in the peer's untrusted chain.  As soon as the first issuer is found in the trust store, all further issuers must come from the trust store.  So the -trusted also provides preferred intermediate issuers.

If the more sophisticated interpretation you just provided is of any practical relevance
it should be clearly and prominently documented - which is not the case so far.

It is certainly of practical relevance to contributors, since we must not break support for trusted certificates, and it is important to understand implicit trust of self-signed certs in the store as a compatibility feature with past and current practice that coexists with explicit trust that should be used instead, but we've not socialized that as a preferred practice, and it may be ETOOHARD to get all but the most meticulous users to do that.

I see. But then this should really be documented prominently and clearly!
At least, as I wrote, doc/man1/openssl-verify.pod{,.in} does not do this,
although this man page does document quite a lot regarding certificate verification.
I really wonder why there is no mention of those more advances trust features.
Or is there some other official OpenSSL document describing it?
Then the man page should at least point to it or better copy the most relevant contents.

-trusted file
A file of trusted certificates, which must be self-signed, unless the -partial_chain option is specified. [...]

No. They need not be self-signed.

Please note that I merely quoted this from the existing documentation in openssl-verify.pod.in.
So also this portion of the man page must be corrected/updated, and I wonder why this has not long been done (by whoever implemented the respective feature).

Without -partial_chain, non-self-signed certificates without explicit wrapping with trust EKUs are just preferred untrusted certificates. When we build a chain we look in the trust store first, and only then in the peer's untrusted chain. As soon as the first issuer is found in the trust store, all further issuers must come from the trust store. So the -trusted also provides preferred intermediate issuers.

Makes much sense to me.
Shall I copy this into openssl-verify.pod.in, replacing the wrong/outdated sentence?

On Sun, Dec 29, 2019 at 11:26:30AM -0800, Viktor Dukhovni wrote:

Do you meant the "TRUSTED CERTIFICATE" PEM marker and data structure?
Does anyone actually use that?

Yes, but obviously not at all common, since the widely distributed CA bundles are just bare certificates, and almost nobody bothers to wrap up the root CAs as trusted certificate objects.

No, the CA bundles aren't distributed as bare certificates.
Mozilla's CA bundle is distributed with trust settings, and
various other properties. However, Linux distributions and others
strip that information and turn it into bare certificates because
there is no format that is supported by all libraries that want to
use a CA bundle.

Ping : this PR is falling the limbo ;)

Automated Ping: This issue is in a state where it requires action by @openssl/committers but the last update was 30 days ago

Also move a FIXME comment from x509_vfy.c to v3_purp.c

I have a pr that would fix the fixme but it is being ignored: #10755

Finally I've found the time today to rebase this PR that as been stalled for 2.5 months.
As suspected by @richsalz on Dec 27th: https://github.com/openssl/openssl/pull/10132#discussion_r361717216 this was pretty tedious due to many conflicts in particular with the refactoring of the certificate verification option documentation files that he had submitted on Oct 9th.

@bernd-edlinger, you had requested changes on Dec 8th, which I responded to on Dec 10th.
Would be nice if you could follow up on this any maybe do a formal review.
Pleased to see that your related fix #10755 has been merged two days ago.
I've just rebased this PR on it this morning.

This issue is in a state where it requires action by @openssl/committers but the last update was 30 days ago

Dear reviewers, so much work has been put into this. Please, do your part to end with this pull request.
I've just got to know another man whose hours of work have been consumed by the bug #1418 that this pull request fixes.
@bernd-edlinger, @vdukhovni, I don't know who else should I contact.

@Forkest unfortunately I got the same problem.
I have been unable to find a solution.
They think we are a perpetuum mobile, but such thing do not exist.

@openssl: this PR is staging since 2 years, and the related issue #1418 is 3 years old, with various links to stack-overflow.
@Forkest : this PR needs a rebase at first.
A good news is that @DDvO is now part of the project. but he is currently fully working on his CMP contributions.
May I suggest replace this PR by two : one about refactorings and renaming, the other about fixing the bug.

Hi, everyone.
I try to rebase this branch to help moving-on this issue :
https://github.com/FdaSilvaYY/openssl/tree/fix_x509_vfy_issue_1418
There is two source of conflicts, AFAI see:

the provider usage refactoring in v3_purp.c and x509_vfy.c
X509_verify was split-out from X509_sign.pod , while this pod file was enriched in the master.

So it is better save this branch to ease its backport to 1.1.1, or may be re target this PR.
Bref, I think this fix will not land sooner in the master and so on.
HTH,
Filipe

Ping @Immortalem  : this PR and its issue may be related to one of yours issues.

This PR has continued idling for quite a while because the reviews were still not finished.
Which is certainly also because

the topic is inherently tricky
the implementation originally done in 2000 (see commit 2f043896d14f5b1ced08bcc8bec3e38e7a18d96f) had subtle flaws,
part of which have been cured already but in a non-consistent way,
contains misconceptions (e.g., self-signed vs. self-issued certificates),
and was so far poorly documented (commit 99d63d4662e16afbeff49f29b48f1c87d5558ed0 was insufficient to this end).
I've been fixing the various related issues jointly in this single PR.

Thus several users are still waiting for this (including the fix to #1418) to be merged eventually,
and maintaining this PR has been causing again non-trivial extra work :frowning_face:

Hi Filipe,

I try to rebase this branch to help moving-on this issue :
https://github.com/FdaSilvaYY/openssl/tree/fix_x509_vfy_issue_1418

thanks a lot @FdaSilvaYY for trying to help out here!

There is two source of conflicts, AFAI see:
* the provider usage refactoring in v3_purp.c and x509_vfy.c

* X509_verify was split-out from X509_sign.pod , while this pod file was enriched in master.

Yes.
I think it would have been simpler to squash first the various fixup commits that have accumulated over time
before rebasing. Yet even squashing the commits turned out to be non-trivial.
In any case it was beneficial to have your rebased version as a reference.
Now the PR is current again, and all tests pass (except the unrelated new test reprted in #12246).

@FdaSilvaYY wrote on May 8th:

@openssl: this PR is staging since 2 years, and the related issue #1418 is 3 years old, with various links to stack-overflow.
@Forkest : this PR needs a rebase at first.
A good news is that @DDvO is now part of the project. but he is currently fully working on his CMP contributions.

True. Finally over the last couple of days I found the needed number of hours in a row to rebase this PR.

May I suggest replace this PR by two : one about refactorings and renaming, the other about fixing the bug.

Yes, I'm going to do this ASAP.
Likely toward the end of this week as I have several other pressing things to do...

@vdukhovni wrote above (I cannot place my answer there):

I don't see duplicate suppression here doing any harm. But Bernd is right that if we really wanted duplicate elimination, we'd have do X509_cmp(). So this is doing a quick-n-dirty variant.

Here the motivation was not to eliminate duplicates (where of course pointer equality would not be the right thing to check),
but as I wrote as message in the respective commit:
    Optimization and safety precaution in find_issuer() of x509_vfy.c:
    candidate issuer cert cannot be the same as the subject cert 'x'

Mind you this function is ultimately called by get_issuer, where in 1.1.1 at least the comment above the function says without duplicate elimination, but I don't see anything in the code that depends on that property. So this change looks harmless to me. Please double-check that I did not miss anything...

I've just added the above commit message as a comment to that change in order to make clear that the intention was not duplicate elimination.

Looks pretty good overall, thanks. Just a couple of nits...

Thanks a log @vdukhovni for immediately having a look at this PR again!
I've handled all you comments as stated above.
This strongly feeds hope this non-trivial set of fixes for the long-standing tricky issue #1418 will get approved soon!

Looks OK to me now.

However, my review is for master only. There should be a separate PR for 1.1.1 (if desired), and ideally much smaller. This PR looks much too expansive for a stable release.  If there's a minimal change that's compelling for 1.1.1, I'll consider that.

Looks OK to me now.

Thanks a lot @vdukhovni!
Very glad that this through finally.

However, my review is for master only. There should be a separate PR for 1.1.1 (if desired), and ideally much smaller. This PR looks much too expansive for a stable release. If there's a minimal change that's compelling for 1.1.1, I'll consider that.

I agree. I will come up with a somewhat minimal backport.
According to users' comments not only in #1418 it looks like there is high demand also for a backport to the LTS version.

Pushed - thanks again @vdukhovni and all others who took part discussing this, also on #1418.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

This is already merged.


jest --watch does not respect settings in package.json if .git folder is present

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
npm t,  and node_modules/.bin/jest --watch do not run my test files.

node_modules/.bin/jest --watchAll does find and run my tests

This is a project I had bootstrapped with CRA and then immediately ejected so I could specify a different path for my tests in package.json.  npm t was working fine until my last commit, which gave me this spectacularly fun error:
node[50036] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)

I have since:

Running the commands with the --no-cache flag
Installed watchman via homebrew
Upgraded to the latest version of Jest
Tried explicitly setting jest to ignore .git
Restarted my computer

While the FSEvents error has gone away, Jest still does not find my test files.  The only way that I can make jest --watch work is to remove my .git folder from the project, at which point everything seems to work just fine.
If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.
The project is small, so it shouldn't be much trouble to clone:
https://github.com/PortableStick/reddit-react
What is the expected behavior?
It should begin testing and watch for changes normally.
Please provide your exact Jest configuration
Output of jest --showConfig:
jest-config.txt
Run npx envinfo --preset jest in your project directory and paste the
results here
npx: installed 1 in 2.246s

  System:
    OS: macOS Sierra 10.12.6
    CPU: x64 Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
  Binaries:
    Node: 6.11.1
    Yarn: Not Found
    npm: 5.8.0
  npmPackages:
    jest:
      wanted: 20.0.4
      installed: 20.0.4

I've cloned your projected an ran jest --watch and it checks out. But that seems to be due to Jest using the working directory as ./node_modules/jest../jest-cli, which does not contain tests.
If you run jest --watch . (note the . that specifies the current working directory) it works fine.
I've submitted a pull request to your project fixing this issue. Can you check it out? :)

Very cool.  That FSEvents error came back, but went away again after installing watchman from homebrew.  Thanks a ton for the fix, @rafaelramalho19!  Since there's no problem with Jest here, I guess I'll close the issue.


Distance Calculations and projection correction when used with polygons and circles.

We have a "drop this item within a certain radius" feature in our app.
For example, we try to illustrate how far away from the center point the user can drop something using an L.circle instance, with a radius of x meters. So if a user can drop something within 100km:

The problem is that when we use the click event from the map to obtain the LatLng of where the user has clicked, then use the distanceTo method to determine if the user has clicked within an appropriate distance - the result sometimes does not reflect the illustrated distance shown with the circle.
Demo: http://jsbin.com/falewuqusi/1/edit?html,css,js,output
Try the demo to see what i mean: click anywhere near the edge of the circle in the bottom-right quadrant of the circle itself. It's almost like there's a shifted margin for error.
This works to the opposite if clicking in the top-right quadrant - you can click a certain distance outside the circle and it still registers as a distance measurement within the limit.
I understand this is something to do with the projection and how the circle's radius is altered to adjust for the projection, but does the distance calculation not take into account the same information?
Can someone please let me know if this is a bug, or if there is something i can do to make the distance calculation account for this difference.
PS: Using contains on the circle's bounds also yields false positives for some reason.
Thanks Guys.

the user can drop something using an L.circle instance, with a radius of x meters.

Well, here's the thing: map projections are hard. The earth is round, not even a perfect sphere. And a circle in the default map projection will not cover all the points which are at less than a given (geodetic) distance to a given point.
When you draw a circle in the surface of the geoid, and project that into a cylindrical projection, the result looks closely like a circle but is not, and the deformation is more evident the closer to a pole you are, see for example https://gist.github.com/jsanz/4564f98c197106432f1b8bf8c9d0230e
This is pretty much in line with the fact that straight lines on a geoid are not straight lines on a cylindrical projection.

but does the distance calculation not take into account the same information?

Nope. L.Circle = circles in the map's CRS. distanceTo = haversine formula.
I guess you want to learn to do geodesy right (hint: it's hard). If you need proper calculations, rely on geographiclib. You might want to do like Leaflet.Geodesic and make your "circles" out of a lot of points calculated via a geodetic formula, instead of assuming that cartesian distance works.

Thanks for the answer @IvanSanchez - i can imagine the circle calculated with a lot of points will be a nightmare for performance.
As a workaround - one that might not be accurate, but would provide the effect i'm looking for, could i just attach the click handler to the circle?

I can imagine the circle calculated with a lot of points will be a nightmare for performance

Every computer nowadays has half a dozen cores, and won't even care about a few thousand floating point operations. Unless you're making loads of buffers, you should at least try. If the points and radiuses are known, then calculate all the things server-side once.
The solution is up to you. You'll have to decide whether you want precise but computationally heavy algorithms, or cheap&dirty.

@danmatthews You would probably be interested in leaflet-geodesy plugin.
A nice page that compares Leaflet-geodesy with the standard L.Circle: https://www.mapbox.com/mapbox.js/example/v1.0.0/leaflet-geodesy/
See also: https://stackoverflow.com/questions/33526678/how-to-draw-tissots-ellipse-tissots-indicatrix-in-leaflet/33538895#33538895

Why is @mapbox's leaflet-geodesy plugin not in the plugins registry?


Publish Python library on PyPi?

Hello! I'm very excited about using OpenVDB, but I'm looking for a cross-platform, easy-to-install way of interacting with it. I have successfully compiled but it would be great to be able to install the python library like pip install pyopenvdb. I'm not sure of the challenges to do that, but I thought I would bring it up because having python packages available via pip decreases the startup cost by an order of magnitude, easily. Thoughts?

Hey all, sorry to dig up such an old issue, but I'm interested in being able to install openvdb's python bindings as a package from PYPI as well. I'd be happy to submit a PR with the packaging necessary to publish on PYPI, if the maintainers would accept it. I can also write the github workflows to automate building and publishing the releases. Would this be something the maintainers be okay with?

Hi @peytondmurray - I think this would be great to see! I'm just not sure what exactly this looks like as I haven't worked too much with PYPI. My understanding is that you would be contributing a bunch of scripts to allow us to automate and test the publishing process of a PYPI package from within the OpenVDB repo? I see a number of pyopenvdb packages already published by the community - do you see any issues with us publishing our own with the same name?

My understanding is that you would be contributing a bunch of scripts to allow us to automate and test the publishing process of a PYPI package from within the OpenVDB repo?

Yeah, that's right. Actually, I think there's a way to set up Github actions to automatically publish (not just test) a new version of pyopenvdb on PYPI whenever you make a new release. If we can get that working then the process of publishing to PYPI won't require any extra effort at all when it comes time to make new releases of OpenVDB.

I see a number of pyopenvdb packages already published by the community - do you see any issues with us publishing our own with the same name?

There are indeed issues with publishing our own with the same name, but I think the effort in overcoming them will be worth it. For reference, there are currently two separate projects on PYPI which show up if you search "pyopenvdb", but they're both really the same:

pyopenvdb 0.1.4 is a project for building and packaging pyopenvdb in a docker container. There's a github page which has commits from January 2021, but no PYPI release has been made in 2 years.
pyopenvdb-3.8 0.1.5 has a link to the same github page as the first result.

I'm guessing the author made both projects in the course of figuring out how to publish packages to PYPI (definitely done this myself before...). In any case, the rules governing PYPI package name transfers are clear: the first thing to do is just try to talk to the owner of the packages. There haven't been any releases on either of these projects in two years; if we email the author three times, and we don't get a response within six weeks, then the projects already meet all the requirements for being considered "abandoned." At that point I think we have a good case for transferring ownership of those PYPI packages to the official OpenVDB project maintainers.
Of course, all of that won't be necessary if we can get a hold of the owner of the projects. I hope they'll be willing to give up those projects, especially if we publish the officially supported python packages in their place.

I'll speak to the other maintainers to confirm we'd be happy to support this.

Thank you! I'd also be happy to contact the owner of the existing packages that we'd need to remove on behalf of the OpenVDB project to get the process started, but I'll leave the decision to do that up to you. Let me know how you'd like me to proceed.

Hey @peytondmurray - sorry for the delayed reply. Thanks a lot for outlining the process, this all sounds good to me! I confirmed today with the other maintainers that it would be great to pursue this and we'd happily support your proposal of an automated/CI based system for building and publishing pyopenvdb.
If you're still interested in looking at this please feel free to start the process and e-mail the author of those other published packages on our behalf. We have a public e-mail/lists<EMAIL_ADDRESS>which you can include us on (all messages available here https://lists.aswf.io/g/openvdb-dev/topics) but please let me know if you need anything else!

Awesome, I'll get started on this. Thank you! :tada:

If you need any help I have lots of experience setting this type of thing up, hit me up! I'm also keen on getting my hands on openvdb in the python ecosystem. :)

An update on progress so far, since I know some other people have expressed interest here:

[x] Contacted the current owner of the pyopenvdb package on PyPI (Alex). Alex was super nice, very responsive, and excited that there are other people interested in python packaging for OpenVDB. He agreed to transfer ownership of the pyopenvdb package name to the OpenVDB maintainers, on the proviso that he is credited with writing the original packaging for the python bindings. I said that I thought that this would be fine - we can credit him in the README.md for the python bindings or some other appropriate place (CONTRIBUTORS.md or something, maybe?), as long as the maintainers agree
[x] Fork the repo and started a new branch for python packaging development
[x] Add README.md explaining installation, dependencies, and build toolchain
[x] Add pyproject.toml: specifies python build-time dependencies and options for builds
triggered by CI
[x] Add setup.py, which makes openvdb/openvdb/python a python package that can be installed with pip. I've configured it to use scikit-build as a way of running cmake automatically during the build process, and setuptools_scm to set the appropriate package version string based on the current state of the git index
[ ] Set up github CI to build and publish an sdist for the package. I'm still in the process of testing this by uploading a package to https://test.pypi.org/legacy, but I think this is basically complete. I'm still trying to get wheels to build as part of the same CI pipeline, so I've left this unchecked for now
[ ] Set up cibuildwheel to automatically build wheels for python 3.8, 3.9, 3.10 with manylinux images. This is in progress, and a bit fiddly to get right. Unfortunately the manylinux2014 images (newest ones) are built on CentOS7, which by default only has Boost 1.53. This means I'll have to build Boost 1.70 inside the container, which will be slow, before building OpenVDB. Only then will I be able to build pyopenvdb.

Currently the github workflow on the fork is configured to trigger in two ways:

By a release, in which case it will build wheels and a source distribution for the released tag before uploading to PyPI
Manually, in which case the person who triggers the build can specify a git ref for the build

As it stands, you can go to my fork, go to the python directory and run pip install . and it should build as long as you have the correct dependencies - including Boost, OpenVDB, CMake, and the python build dependencies specified in pyproject.toml.

Hello, Has there been an update on this? Very interested in being able to install OpenVDB bindings with 'pip'


1v1.lol now probably checks if AntiCheat was patched

Hi!, im not sure if it affects NetWareLoader but it probably does since when i patched AntiCheat(by just removing code inside StartDetection Func) yesterday after new update, game stops starting and its stuck at loading 0%, probably because it detects that AC dll signature is invalid or maybe there is other reason?

Try verifing the game files and disabling it again

I've tried it also iirc
On Tue, Mar 26, 2024, 3:38 PM waxnet @.***> wrote:

Try verifing the game files and disabling it again
—
Reply to this email directly, view it on GitHub
https://github.com/waxnet/NetWare/issues/59#issuecomment-2020610447, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APQYMOI4B5C7NIMOHSOMWXLY2F24RAVCNFSM6AAAAABFIZ4AJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGYYTANBUG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

that used to happen to me too some time ago but it sorted out eventually, so i dont think its any detection stuff

that used to happen to me too some time ago but it sorted out eventually, so i dont think its any detection stuff

yeah maybe thats just me, looking at 1v1.lol devs it is small chance that they did anything other than just adding CodeStage to their game, even this took them like 1 year i believe? lmao

Yeah lol, the game is working normally for me so idk


Update custom indexer processor e2e doc

Description
The previous doc content was outdated. I went through the updated tutorials and got the custom indexer processor working.
Everything should checks out now.

Checklist

[] Do all Lints pass?
[x] Have you ran pnpm spellcheck?
[x] Have you ran pnpm fmt?
[x] Have you ran pnpm lint?

Could you run pnpm fmt, pnpm lint, and pnpm spellcheck if you haven't already?

Looks like the spellcheck has some error on other file. Shall we address them in different PR? @gregnazario
Misspelled words in docs/move/prover/prover-guide.md:
dir
VerifiedFunction
VerifiedFunction
AllFunctions
vc
proc
mut

Could you run pnpm fmt, pnpm lint, and pnpm spellcheck if you haven't already?

Looks like the spellcheck has some error on other file. Shall we address them in different PR? @gregnazario
Misspelled words in docs/move/prover/prover-guide.md:
dir
VerifiedFunction
VerifiedFunction
AllFunctions
vc
proc
mut

That's fine, it's more as a helper for you, which is why I haven't put it in the CI
If we add too many things like "mut" "proc" "vc" to the spellcheck, we end up missing things that we actually misspell.

Update

pnpm fmt &pnpm lint
address comment


Add prettier configuration and update eslint config

This is sufficient to auto-run prettier on save, and to ensure that prettier overrules eslint rules so you don't get any linter conflicts.
You may need to do npm install -g eslint prettier to ensure that plugins pick everything up but I think it works with project local versions too.
It seems we are vendoring node_modules. Normally I only save package-lock.json, but the vendoring conversation is bigger than this PR - so this is an aside because I'm curious.

No, I think this is good to go :-)


$wpdb->delete() can't really be cached

Calling $wpdb->delete() is flagged as an uncached query. Of course, a delete operation can't really be cached. Same goes for update and insert. However, I do suppose that in many cases they should perhaps still be accompanied by a cache update.
So perhaps this should be left as it is, but it seems odd to me.
Related #178

The PR was merged and released in 0.3.0. I guess this is fixed.

I'm still getting an error with $wpdb->delete(). I'm using the latest on the develop branch.

Sorry... here's a minimal code example that triggers the error I'm getting:
<?php
/**
 * A demonstration of WPCS failing on $wpdb->delete().
 *
 * @file
 * @package phpcs
 */

$wpdb->delete();

See b7d5416. $wpdb->delete() should probably be accompanied by a wp_cache_delete() or wp_cache_set() depending on the nature of the cache.

So in other words, this was reverted by #400.


Method exercises: Update solution for alphabetical_list method

Because

While both approaches will give the correct result, using uniq before sort (uniq.sort) is generally more efficient, especially as the size of the array increases or if there are many duplicates. For small arrays (like this example), the difference in performance is negligible, but I think it’s a good habit to prioritize efficiency.
This PR

update hint comment with the correct order of methods
update solution with correct methods order

Issue

Closes #XXXXX
Additional Information

Pull Request Requirements

[x] I have thoroughly read and understand The Odin Project Contributing Guide
[x] The title of this PR follows the location of change: brief description of change format, e.g. Data types exercise: Update spec files
[x] The Because section summarizes the reason for this PR
[x] The This PR section has a bullet point list describing the changes in this PR
[ ] If this PR addresses an open issue, it is linked in the Issue section
[ ] If this PR includes changes that needs to be updated on the solutions branch, I have created another PR (and linked it to this PR).

Hi Rachel, thank you
PR for the main branch created as well
https://github.com/TheOdinProject/ruby-exercises/pull/106


Update configurations to reduce the uptime calculations to 30 mins

Run device uptime and device status every 30 minutes
WHAT DOES THIS PR DO?

Schedules the device uptime and device status cron jobs to run every 30 mins

WHAT JIRA STORY/TASK IS RELATED TO THIS PR?

PLAT-1050

HOW DO I TEST OUT THIS PR?

Static code analysis

WHICH ENDPOINTS SHOULD BE READY FOR TESTING?:

n/a

IS THERE ANY JENKINS CONSOLE LINK FOR CODE COVERAGE AND BUILD INFO?
N/A
ARE THERE ANY RELATED PRs?
N/A

The changes we made yesterday to the environment variables to make the jobs run every 30 mins had no impact, thus this PR
cc @ja-odur @NoahNsimbe


Add loader and texts inputs for a better UX

Looks great, one small issue. The "Generating code" spinner should be printed to stderr instead of stdout. In an automated setting, a user may do --quiet generate something > file.tf, but the file they'll get will include a lot of "Generating code..." lines.


Full Wheel Component Menu. Replace Component Menu documentation icon with an edit icon

Add Ellipses on the small Component menu to open the full wheel Component Menu.
Full wheel Component Menu also opens on right click on component

Replace Component Menu documentation icon with an edit icon. Clicking the edit icon puts the node into edit mode. (Equivalent to CTRL-Click today)

Documentation icon moves to the Full Component Menu Wheel

Refinement notes:

The icon for editing may be (temporarily) picked from icons available in figma ("text input" maybe?)


Cannot delete join or table in Query Builder

Description
Hi there,
I am using Version <IP_ADDRESS>112052011 and I use Query Builder to design my queries. The issue I have is I cannot remove a join or table from it. Can you please look into it or what am I missing?
regards
Zolf
DBeaver Version
Version <IP_ADDRESS>112052011
Operating System
Win 11
Database and driver
Mysql 5
Steps to reproduce
Add tables and join tables and then try to remove the join link or table from the query builder view.It does not show any delete option or when I click on delete button on keyboard nothing happens
Additional context
No response

Hello @zolfj
Could you please provide any footage of your issue?

Hello there,
You mean screenshot?
On Mon, 27 Nov 2023 at 12:10, Anastasiya @.***> wrote:

Hello @zolfj https://github.com/zolfj
Could you please provide any footage of your issue?
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1827370444,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6VGTFEX73GPHKKUAHYXA3YGRGWHAVCNFSM6AAAAAA72U3KBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRXGM3TANBUGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Let's start from a screenshot, yes

But please attach it here on this GitHub page, not via e-mail (it will not work via e-mail)

Attached small gif video

Ok, I will try to reproduce.
But first question - what result do you expect after the join deleting? Because it can not be just a table without connection with other tables in the query.

Thanks, you see sometimes I link to the wrong columns in the two table and want to remove it and again reassign the links

Unfortunatelly, I can not reproduce your issue.

Could you please try the latest DBeaver version?

I will try it. Thank you.
On Mon, 27 Nov 2023, 21:22 Anastasiya, @.***> wrote:

Unfortunatelly, I can not reproduce your issue.
2023-11-27.20_42_55-.png (view on web)
https://github.com/dbeaver/dbeaver/assets/45152336/88a990f4-6690-4e6a-a660-c0bc29521370
Could you please try the latest DBeaver version?
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1828336078,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6VGTE4LWQITESOMIYNCXLYGTHMXAVCNFSM6AAAAAA72U3KBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYGMZTMMBXHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

This happens when I start a new SQL script and start writing query manually. Then I click on Query builder to help me continue with my design. Then is issue arises.

https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1827392635 so, you started from the query from this video?
Or do you add something with the Query Builder and after it the "delete" button disappear?

Yes
On Tue, 28 Nov 2023 at 12:50, Anastasiya @.***> wrote:

#21992 (comment)
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1827392635
so, you started from the query from this video?
Or do you add something with the Query Builder and after it the "delete"
button disappear?
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1829409171,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6VGTBZFATKXVAHL4WYYNDYGWUGHAVCNFSM6AAAAAA72U3KBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGQYDSMJXGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

By the way, do you'll have sale season, where I can buy on discount the
latest version
On Tue, 28 Nov 2023 at 12:51, Z.A Jafari @.***> wrote:

Yes
On Tue, 28 Nov 2023 at 12:50, Anastasiya @.***> wrote:

#21992 (comment)
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1827392635
so, you started from the query from this video?
Or do you add something with the Query Builder and after it the "delete"
button disappear?
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1829409171,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6VGTBZFATKXVAHL4WYYNDYGWUGHAVCNFSM6AAAAAA72U3KBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGQYDSMJXGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Could you please provide the log files? You can find instructions here: https://dbeaver.com/docs/wiki/Log-files/. Thank you.
And unfortunately, I do not know anything about our sale season...

It's been a while since no update here. If the issue is still actual please let me know and provide additional information.

Yes, everything is fine.
On Tue, 26 Dec 2023, 23:50 Elizabeth, @.***> wrote:

It's been a while since no update here. If the issue is still actual
please let me know and provide additional information.
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/21992#issuecomment-1869754568,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6VGTGTUUGLY75QWBB7OU3YLMWP7AVCNFSM6AAAAAA72U3KBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZG42TINJWHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


[Refactor] Dotnet Sample App

Description:
This is an Opentelemetry Donet Sampleapp featuring metrics, traces, and context propagation.

[x] Parse config file & use default values
[x] Generate random based metrics
[x] Add request based traces
[x] Add request based metrics

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

The fork workflow showing a successful run https://github.com/Kausik-A/aws-otel-community/actions/runs/4940131799


feat: update the limit of header-max-length from 72 to 100 characters

I'm getting super often this error:
✖   header must not be longer than 72 characters, current length is 74 [header-max-length]

Visible in the case when I use one of the long scopes like date-picker, progress-bar and so on.
So in the case of:
feat(date-picker):<space><commit-message>

I'm losing 19 characters from the commit message just for tagging. And including one input or output name, there are no characters left to do a meaningful sentence. And the messages become a bit cryptic just to get inside the limitation.
I don't suggest to go and try to fill the how 100 character limit, but having some additional characters could be handy.
Also, there is similar open PR for this change inside the commitlint
PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] If applicable, have a visual design approval

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[x] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] clarity.design website / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Currently, we are losing a lot of the message for formating and scoping. So we are left with a little as none space to write something that explains the commit. Also, this is not forcing anyone to go to a full 100 characters. Just giving you more space to write a short message without thinking about how to get that one character more.
In general, the good practice is to go with max 50 characters for the length of the commit message. 72 is the other number that people for some reason like to limit themselves. Both numbers come just from a statistical analyze on git Kernel log. The limits of 72 are line-limit - design to be used into automated mailing systems - so the message is easily visible on old screens that don't have a lot of space in the X-axis. But if we want to promote and use the scope to add context, in the worse case we are having to subtract 21 (feat:(vertical-nav): ) characters from the 50/72 limit - that is letting us with 29/51 characters left.
A better thing that we have to do is using more and more the scope option of the commit message. It's easier to get the quick context of the message just by reading feat/fix/docs(<component-name>):
# Not clear where?
fix: focus trap no longer steals focus when going outside

# Better
fix(datagrid): focus trap no longer steals focus when going outside

On the example above is clear how much additional space is added just to provide the context.
I don't think that someone will abuse this limit and try to write all of his commits to the fullest extent of the rule, but don't see how 72 as a number is making things better. This limit is too conservative to forcing people of writing good messages.
I'm betting that there will be no commit message by the end fo 2020 more than 85 ch.
PS.
Providing Github ID inside the commit message could easily help to find the original issue and related conversations. Especially helpful when generating release notes.

We need to have a dev chat about this before we proceed. I'm not opposed to longer, but we need to be clear as a team about how we want to write messages and generate notes from it.

⧗   input: fix(date-picker): let date-container to be disabled without clrForm wrapper

Signed-off-by: Bozhidar Dryanovski<EMAIL_ADDRESS>✖   header must not be longer than 72 characters, current length is 75 [header-max-length]


feat: Zendesk add Help Center module

Background
Zendesk Support consists of 3 modules:

Ticketing API
Help Center API
Voice API

Changes
This PR introduces Help Center module by adding OpenAPI yaml. The script is modified in such way that schema.json instead of having default empty name module, it is renamed to ticketing while a newly added module is called help center.
Breaking
ZendeskSupport now requires WithModule option to continue working. (Need server follow up PR)
Notes
While it is possible to merge the two API modules since each has universally unique objects without collission, I decided to keep them as separate modules to better reflect the structure of the official documentation.
Semgrep
CI fails and is fixed by https://github.com/amp-labs/connectors/pull/1051

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1041
#1050  👈
#1049
#1048
#1047
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Cobalt0s and the rest of your teammates on  Graphite

@Cobalt0s Please don't forget to update the server as soon as you merge this in!


koord-manager: add prom metrics handler

Ⅰ. Describe what this PR does

Add a koord-manager option for registering the Prometheus metrics handler.
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in make test

As discussed, the controller-runtime's registry will be used in the koord-manager. Metric collectors should register with the Registry in the pkg "sigs.k8s.io/controller-runtime/pkg/metrics".
The PR will be closed.


PropertyGroup interface

Although a Painter may be an object in terms of reflection and scriptability, it is kind of strange I can call methods like this on a Painter:
Painter::toVariant
Painter::fromVariant
Painter::count
Painter::value
Painter::group
Painter::isEmpty
Painter::indexOf
Painter::clear
Painter::forEach*

These are all methods from PropertyGroup. The results / behavior of some methods are extremely hard to understand. For example, I'm confused that clear only clears all properties and no registered functions. Beside that, may a clear method on a Painter could mean something completely different?
The interface from Object is just fine.

This is the exact reason why I'm in favor of precise method names, e.g. clearProperties() instead of clear(). This has been refused with the remark that it would be a "duplication", a class PropertyGroup should have the name clear() and not clearProperties. Unfortunately, this approach does not hold when using inheritance, and something like clear() is especially critical since it is used a lot in different circumstances.

This is a crucial point in designing object oriented classes and interfaces.
I think the (overall, not our specific) goal is to provide an interface to a class, that is minimal (i.e., no redundancy) and understandable. For a class that should be used directly, this means that the class name should not be included in any method name. For a class that should by used by subclassing, this may mean that the class name is relevant in the method names.
Normally, I would prefer composition over inheritance so that both solutions can be provided.
First, the actual class with no class name mentioned in its method names and second, a using class with a delegating interface that adds the class name to the method names.
What we currently have is the subclassing case with no class names in method names (only for PropertyGroup, the Object interface is designed for this use case).
I think a solution may be to design the interface for a painter disregarding the current interfaces of Object and PropertyGroup and ater that, we decide what to do with the superclass interfaces.

I would prefer function names within the context of their class (since this is default for most libraries) and favor composition over inheritance in this case. Since there is probably no further rational here, we could wait/trigger on some more feedback relating this design decision.

This is like saying QObject ought to be used by composition rather than by inheritance, which I find extremely strange. It's much easier to think of reflection as extending an already existing class to expose a reflection interface (by deriving the class from Object), then suddenly it's all much easier to use, because you don't have to manage property groups by yourself and keep track of deleting them, you can reuse existing hierarchies instead of replecating a new one in form of property groups outside the class etc. And I do not say it should be prohibited to use properties that way, I see use cases where it whould make perfectly sense to create and manage property groups dynamically, it just shouldn't be the default. So please don't make the property interface more complicated than it has to be and let's indeed encourage a simple use, not the complicated one that unfortunately has been used so far by most projects.

And for the function names: as often, a middle ground would help here instead of always jumping to the extreme. I completely agree that, e.g. a plugin should have a method getName(), and not getPluginName(), but when managing sub-objects, I rather have the name of what is managed here, e.g. addPlugin() instead of add(). If I have a plugin manager, it's not obvious what add() means, it can be a plugin, or a search path, so I really miss the information there. And with such a default way of naming functions it would also make the problem go away that I have to decide in advance if this class is "intended for inheritance" or "intended for composition" - in fact we should not make that decision at all, but let the user choose what to do and leave as much choice as possible. Which we already had established as a good practice anyway.

I think, from a conceptual point of view, it is kind of strange to say an Object is a PropertyGroup (and therefore also a Property). It is more intuitive to say an Object has Propertys (and Functions), so I would say this is a case for composition and a problem of libzeug, not gloperate. Object could then provide delegating methods for properties and functions.


Fix broken url in docs

Description
Easy navigation and easy reading

I signed it

/check-cla

/check-cla

Hello @saintmalik .
Would you check that you have signed the CLA and that your email used to sign the CLA matches
your email associated with this account. Thanks!

Yeah absolutely, maybe there is some error somewhere else but yeah I signed the CLA and the email is the same

I signed it

@onlydole @celestehorgan Guys, I finally signed the CLA, can you review this

/lgtm

Thanks @saintmalik
/approve


dotfile that are not .file but elsewhere ?

Lot of my dotfiles are in ~/config folder or in my /mail folder or elsewhere. Is ellipsis handle symlink to those file. It seems,for instance, when I add to my package a file in the /mail/.../.../../myfile , it copy file to my home folder, and make a symlink to it. But the file is no longer in its original directory.

Hey psic
A lot of the build in commands to handle files are made with the simplest setups in mind. For more advanced use-cases you'd have to use a custom ellipsis.sh file and do things manually.
You can take a look at one of the example packages from the package index; http://docs.ellipsis.sh/en/master/pkgindex/
Kind regards
Gertjan

@psic
I'm going to close this issue, don't hesitate to reach out again if you have further questions.