Help panel: Areas: add Converting a Point to an Area

In the help panel one sees

Points or Areas?
Adding Areas
Modifying Areas
Deleting Areas

Please also add

Converting a Point to an Area
Select both and use the C shortcut.

https://github.com/openstreetmap/iD/issues/839#issuecomment-511093625

Let's not do this.   I don't think there is consensus whether to map every kind of feature as a point or area, and it's hard to explain to new users why they would choose one method over another.


Not able to play .ogg format.

Please follow the issue template and add more info, as the issue is right now, there isn't enough information to guess what is happening.

Closing due inactivity, if there is more info that you can add to the issue, comment here and we can re open the issue.


Release documentation is lacking key steps

The release process for ESMValTool has become quite involved, and needs performing a number of steps that are not currently documented, I will try and document those steps, mainly guiding myself by the flow in https://github.com/ESMValGroup/ESMValTool/issues/2881 - obv not detailing some "sensitive" aspects to privacy (eg VM) but making sure the next RM is not in the thick fog. This is needed even if the RTW will come online by the time of the next release. I will need past RMs like @sloosvel and DKRZ seasoned tenants like @remi-kazeroni and @schlunma to have a look at the PR, please. Also, we need to do something about the data on Levante, that is currently spread in various dirs, something @bouweandela and myself were not all too happy to see :+1:

Awesome, thanks for tackling this V! :rocket:

Also, we need to do something about the data on Levante, that is currently spread in various dirs, something @bouweandela and myself were not all too happy to see +1

This is the only thing I disagree with. We have basically two locations where the data is stored - one is the directory maintained by DKRZ and the other one is our "global" download directory where we store data that is not provided "natively" on Levante. I don't think we need to change something here.
This is what we are using for CMIP6:
CMIP6: [
    /work/ik1017/CMIP6/data/CMIP6,  # "official" DKRZ dir
    /work/bd0854/DATA/ESMValTool2/download/CMIP6,  # our "global" download dir
]

What we could/should change though, is the DRS DKRZ so it includes the facet product (like ESGF), see here and/or make DRS configurable by path (https://github.com/ESMValGroup/ESMValCore/issues/129).

cheers Manu! Well, I had to use multiple dirs for CMIP5/6 last week - how about we give it a short discussion at our next Techy call? I'll add this to the points to discuss list, if that's OK with you :beer:

Another step that is missing is that you need to merge the release branch back into the main branch without squashing after making the release off of it, else the version number in the main branch will be wrong after the release. See ESMValGroup/ESMValCore#1773.

yes, the absolute last step :last_quarter_moon_with_face:

I think an alternative approach would be to not push to the release branch directly (e.g., by increasing the version number in a PR to main before branching off the release branch). This has been done for v2.5 and v2.6 and didn't mess up the version numbers as far is I know.

Yeh, but that's high risk since the actual release might be late - we'd start getting questions from power users about version mismatches. Which we never get anyway 😆

If we follow the procedure that any changes first need to be merged into main and if they are considered critical for the release they can be cherry-picked into the release branch, as described in our making a release documentation, this should also work fine without merging back the release branch into the main branch. Unless changes to main would cause a merge conflict in the release branch of course.


typo error in snipsfile for 4 mic

Hi,
It seems that there is a typp error in snipsfile for 4 mic.
params:
num_led: 12
instead of
params:
- num_led: 12
Without the -   snipsmanager install lead to no rerror but led are still off when hotword detected.
But I don't give up ;o)
Thanks for your skill.

Sorry for the late reply, I will update the skill as soon as possible

Hi urbatecte,
I have updated the snips skill, you don't need anymore to specify the number of led.
The snips skill will autodetect the ReSpeaker 4Hat or 2 hat, if installed


failed calling webhook "mutate-pods.fissile.cloudfoundry.org"

After the cf-operator pod crashes it can not be started again because of:
FailedCreate   ReplicaSet   Error creating: Internal error occurred: failed calling webhook "mutate-pods.fissile.cloudfoundry.org": Post https://<IP_ADDRESS>:2999/mutate-pods?timeout=30s: dial tcp <IP_ADDRESS>:2999: connect: connection refused

To me this looks like a circular dependency, as in to schedule the cf-operator pod, k8s needs to call the cf-operator webhook, which is not available since the pod is not running.

Deleting the webhook configurations will work around this issue:
Check for them and delete the cf-operator ones, or just run this to delete all:
kubectl delete validatingwebhookconfigurations --all
kubectl delete mutatingwebhookconfigurations --all

I found, I'm able to fix this issue by not deploying the cf-operator in the same namespace, the one it is operating on. But this is not supported by the helm chart. Would this be the preferred deployment model or is there an option to make the validatingwebhookconfigurations and mutatingwebhookconfigurations skip the cf-operator pod?

@rkoster as @manno mentioned about, you need to clean up your webhooks configuration if you want to re-install on the same namespace. Reason behind, is that every new deployment of the cf-operator, will generate a new service with a new ClusterIP, so you want your webhooks to point to the right one.
As with any helm installation, you required to do some pre-processing. Cleaning the webhooks is one of them.
The only way to automate this for you, is to use something similar to what I have in this file, it basically use a tool call havener, that runs some pre-processing steps, prior to the helm install.

@rkoster if you can't run helm install --namespace MYCUSTOMNAMESPACE https://s3.amazonaws.com/cf-operators/release/helm-charts/cf-operator-v0.3.1%2B5.gb97ec705.tgz, I think that would be a bug.

For myself and others, to restart cf-operator:
restart() {
  kubectl delete validatingwebhookconfigurations --all
  kubectl delete mutatingwebhookconfigurations --all
  kubectl delete pod -l name=cf-operator -n scf
}

Is there a better way to select just the cf-operator webhooks in the example above?


Panic on invalid number input, possible denial-of-service attack vector

Expected Behavior
Invalid GraphQL number inputs return an Err() result value.
Actual Behavior
Invalid GraphQL number inputs cause a panic, which can be abused to turn invalid input into a DoS attack.
Steps to Reproduce the Problem
Call parse_query() with a GraphQL input with a number that is too large to be fit in an f64, and observe it panic.
Here's an example GraphQL input, courtesy of cargo-fuzz:
{r(a: [4e444])}

The above input causes a panic: failed to parse number: Error("number out of range", line: 1, column: 5) with the following stack trace:
[...]/async-graphql-parser-2.11.2/src/parse/mod.rs:153:31
stack backtrace:
   0: rust_begin_unwind
             at /rustc/936238a92b2f9d6e7afe7dda69b4afd903f96399/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/936238a92b2f9d6e7afe7dda69b4afd903f96399/library/core/src/panicking.rs:106:14
   2: core::result::unwrap_failed
             at /rustc/936238a92b2f9d6e7afe7dda69b4afd903f96399/library/core/src/result.rs:1613:5
   3: async_graphql_parser::parse::parse_number
   4: async_graphql_parser::parse::parse_value
   5: core::iter::adapters::map::map_try_fold::{{closure}}
   6: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
   7: async_graphql_parser::parse::parse_value
   8: async_graphql_parser::parse::parse_arguments::{{closure}}
   9: core::iter::adapters::map::map_try_fold::{{closure}}
  10: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
  11: async_graphql_parser::parse::parse_arguments
  12: async_graphql_parser::parse::utils::parse_if_rule
  13: async_graphql_parser::parse::executable::parse_field
  14: async_graphql_parser::parse::executable::parse_selection
  15: core::iter::adapters::map::map_try_fold::{{closure}}
  16: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
  17: async_graphql_parser::parse::executable::parse_selection_set
  18: async_graphql_parser::parse::executable::parse_operation_definition_item
  19: async_graphql_parser::parse::executable::parse_definition_item
  20: core::iter::adapters::map::map_try_fold::{{closure}}
  21: core::iter::adapters::filter::filter_try_fold::{{closure}}
  22: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
  23: core::iter::adapters::process_results
  24: async_graphql_parser::parse::executable::parse_definition_items
  25: async_graphql_parser::parse::executable::parse_query
  26: rust_fuzzer_test_input
  27: __rust_try
  28: LLVMFuzzerTestOneInput
  29: _ZN6fuzzer6Fuzzer15ExecuteCallbackEPKhm
  30: _ZN6fuzzer10RunOneTestEPNS_6FuzzerEPKcm
  31: _ZN6fuzzer12FuzzerDriverEPiPPPcPFiPKhmE
  32: main
  33: __libc_start_main
  34: _start

That seems to point to the .expect() call here: https://github.com/async-graphql/async-graphql/blob/master/parser/src/parse/mod.rs#L153
Specifications

Version: 2.11.2, on Rust 1.58.0-nightly (936238a92 2021-11-11) in a 2021 edition project
Platform: Ubuntu 20.04.3 LTS running under WSL2 in Windows 10 x64

Thank you for reporting this issue. 🙂

Thanks for looking into it, and for maintaining this awesome library!

I don't know why this problem cannot be reproduced, but I now delete the expect call and return an error when the parsing fails.

I don't know why this problem cannot be reproduced, but I now delete the expect call and return an error when the parsing fails.

Fascinating -- what happens on your end when you call async_graphql_parser::parse_query on the input I gave?
Here's a little program you can run to check:
use async_graphql_parser::parse_query;

fn main() {
    println!("{:#?}", parse_query("{r(a: [4e444])}"));
}

I'm seeing the same issue in both 2.10.3 and 2.11.2.

It has been fixed, thank you! 😁


kali-rolling in crouton error: The '-logfile' option cannot be used with elevated privileges

chronos@localhost / $ sudo edit-chroot -all
name: kali-rolling
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/kali-rolling...
crouton: version 1-20160330180425~master:43e2fca0
release: kali-rolling
architecture: amd64
xmethod: xorg
targets: xfce-desktop,core,cli-extra,keyboard,audio,chrome
host: version 7834.70.0 (Official Build) stable-channel peppy
kernel: Linux localhost 3.8.11 #1 SMP Sat Apr 9 16:08:37 PDT 2016 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/kali-rolling...

Please describe your issue:
When I want to enter the chroot, the error showed:
chronos@localhost / $ sudo startxfce4
Entering /mnt/stateful_partition/crouton/chroots/kali-rolling...
/usr/bin/startxfce4: Starting X server
(EE)
Fatal server error:
(EE) The '-logfile' option cannot be used with elevated privileges.
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE)
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: Connection refused
/usr/bin/xinit: server error
Unmounting /mnt/stateful_partition/crouton/chroots/kali-rolling...
If known, describe the steps to reproduce the issue:
I installed kali-rolling in crouton using xfce-desktop. It was normal when I installed nmap, metasploit,armitage manuelly. But after I installed several packages by the command "apt-get install kali-linux-full" or "apt-get install kali-linux-top10", I could not enter Kali anymore.
Thank you for your help!

Closing. Please update your chroot and try again, re-open if this issue is still a concern.


bug(mat-select):  automatic scrolling of options when height of option is set in css

Reproduction
https://stackblitz.com/edit/components-issue-16pt1s
Expected Behavior
What behavior were you expecting to see?
No scrolling of the options panel when clicking higher numbers in the select list.
Actual Behavior
What behavior did you actually see?
When clicking on items (for instance number 50) the panel starts scrolling down to higher numbers because the height of mat-option is set to 30px instead of 48px.
Environment

Angular: 11.0.2
CDK/Material: 11.0.0
Browser(s): Edge, Chrome
Operating System (e.g. Windows, macOS, Ubuntu):  Windows

The current mat-select implementation assumes that the options and the option panel will have a particular height so changing it yourself won't work. We have a new one in @angular/material-experimental/mdc-select which has the same logic, but slightly different CSS which doesn't have this limitation. You can either switch to it now or we'll eventually merge it into @angular/material/select.

@crisbeto thank you for your reply. do you have a timeline for eventually? Is that 2 weeks? 2 months? 2 years?

Probably within the next year, but it's difficult to say. I think that you can safely use it, if this is something that's blocking you, because both implementation are on top of the same base class and they run the same set of unit tests.


Update readme with VSReuseInstance parameter

With my previous PR, the developer guide was updated but not the readme file. This PR fixes this.

Hi @sailro, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Sebastien Lebreton). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Update request: netcoredbg 2.0.0-895 → 2.2.0-961

Package name: netcoredbg
Latest released version: 2.2.0-961

Current version on the unstable channel: 2.0.0-895
Current version on the stable/release channel: 2.0.0-895

[x] Checked the nixpkgs pull requests

Notify maintainers
@leo60228

For me this update is particularly important as I think the current version that is available in the nixpkgs does not work correctly with dotnet 7. I downloaded netcoredbg manually from their github repo and can run it with no problems on a dotnet 7 project.
Usually I'd just create a PR but this is beyond me currently as I have little idea what happens with the current patches, managed vs unmanaged, and passthrough dependencies :(

Note for maintainers: Please tag this issue in your PR.

Please see the PR mentioned above. I'm able to successfully build the new version in it but cannot run it due to problems with libdbgshim.so which are currently beyond me.


add doubleshine extended route

Adds a new route based on this thread https://discord.com/channels/636001942279159830/1311183173555847228/1311183173555847228
By the way, I just wanted to mention the JSON export for this route did not import properly until I adjusted the format to match those in ./public
It exported as something like
{
"route": [...],
"regions":[]
}

The route would not load/import properly until I trimmed everything besides the route contents

Nice job, thank you I am fixing the exporter issue now


[Bug] Compatibility Issue with Fzzy Config

Coming from fzzyhmstrs/Emi_loot#85, Visual Overhauls "Iconic Buttons" seem to be crashing any Fzzy Config screen on launch, either causing a mod menu error as shown in the EL issue, or a full client crash.
Example log provided in my issue, as well as another example pasted below, that I replicated in my own dev world with a different widget trying to initialize.
Fzzy Config has extremely specialized button widgets with a lot of information attached to them that they use for interacting back with the config. Visual Overhauls injection of the <init> seems to be messing with this. I don't know if there's a way I can have my buttons be excluded from "overhauling", or what. End of the day, I need my actual widgets to exist with all their information intact. They cannot be replaced with another "similar" widget.
latest.log

May be the same issue referenced in #69

Also has come up in fzzyhmstrs/pc#20, and potentially fzzyhmstrs/pc#21